Быстрая модель пишет код, умная чинит логику: как собрать поиск на n8n и PostgreSQL

Про топовые модели пишут много, а вот про то, как разделить роли между быстрой и «думающей» моделью на реальной задаче, почти нет. Автор разбора взял рабочий проект и проверил этот подход на практике.

Задача и почему без LLM в рантайме

Нужен поиск по каталогу авторских изделий из камней. Специалист на закрытой странице Tilda отмечает сферы (любовь, деньги, здоровье и так далее) и выбирает дизайн: женский, мужской или универсальный. В ответ он получает до пяти карточек из таблицы PostgreSQL на 1684 записи.

Соблазн поставить между формой и базой модель, которая «понимает запрос», автор отверг по трём причинам. Первая — задержка: ради поиска по 1684 строкам сетевой вызов не нужен. Вторая — стоимость и вариативность: правила поиска можно записать явно. Третья — источник истины: SQL возвращает только то, что есть в каталоге, а модель могла бы добавить правдоподобное, но выдуманное свойство. Поэтому LLM работают только на этапе разработки.

Роли такие. Particle-1 в Cline была «руками»: писала SQL и код для нод n8n, чинила кавычки и имена полей. GPT-6 Luna Pro была «мозгом»: её звали, когда проблема была уже не в синтаксисе, а в диагностике. Запуски, проверку HTTP-ответа и продуктовые решения автор оставил за собой.

Оговорка важна: это не A/B-тест. Сессии разные по объёму, поэтому 0,49 у.е. против 0,04 у.е. сравнивать как цену решения одной задачи нельзя. Данные OpenRouter по задержке тоже лишь ориентир на конкретную дату.

Пять граблей по порядку

1. Оператор &. Для подсчёта общих тегов модель поставила & для text[], которого в PostgreSQL нет. Оператор && только отвечает «есть ли пересечение», но не считает. Решение: && в WHERE для отбора кандидатов, а совпадения считает подзапрос с unnest.

2. Syntax error near undefined. Code-нода отдавала поле sql_query, а Postgres-нода читала другое имя. Code-нода при этом горела зелёным. Вывод: сверяйте реальный OUTPUT предыдущей ноды с INPUT следующей, а не красивое выражение в параметрах.

3. Литерал массива. Нужны два уровня кавычек: внутри двойные для элементов, снаружи одинарные для SQL-строки. Модель потеряла внешний слой. Параметризовать массив через $1 автору не удалось, но он честно не утверждает, что n8n так не умеет. Для нового продакшена он бы сначала добился параметризованного запроса.

4. Пять строк в SQL, одна карточка на сайте. Respond to Webhook по документации выполняется один раз на первом item. Помогает режим All Incoming Items. Диагностику запутывало ещё и то, что наверху оказывалась широкая универсальная запись с восемью тегами, и казалось, будто SQL всегда возвращает одно и то же.

5. Женский пол: одна запись из 1684. Фильтр не сломан, перекошены данные: почти всё попало в unisex. Автор не стал править алгоритм, а зафиксировал продуктовое правило: женский запрос допускает female и unisex, при равенстве точное совпадение по полу выше. Решить, ошибка ли это импорта, модель не могла.

Дыра, которую модели не заметили

На финальном ревью автор спросил не «почему падает», а «что будет в обход формы». Экранировались обратный слеш и двойная кавычка, но не одинарная, а литерал оборачивался именно в одинарные. Через curl можно было сломать строку и изменить запрос. Пароль на странице Tilda защищает только HTML, но не запросы к n8n. API-ключ в клиентском JS тоже ничего бы не дал. Исправили на сервере: белый список значений spheres и gender плюс корректное экранирование обоих уровней.

Что из этого забрать

Разделение «быстрый исполнитель плюс медленный диагност» работает, если вы сами определяете момент переключения: ошибка в синтаксисе или в поведении системы. Зелёный статус ноды не доказывает согласованность контура. Ранжирование по cardinality(tags) не запрещает широкой записи побеждать. А пустой список сфер молча отключает фильтр, и в публичном API лучше возвращать 400. Security review остаётся человеческой работой: в этом кейсе обе модели инъекцию не подсветили.