Продвинутые RAG-паттерны в n8n

Я собрал свой первый RAG-бот по всем канонам. Взял Google Sheets с базой знаний в формате «Вопрос-Ответ», прикрутил Supabase для векторного хранения, а в центре поставил n8n, чтобы связать все это воедино. Запустил.

Первые два ответа — успех. Бот мгновенно находил нужную информацию и давал четкие, релевантные ответы. Я уже предвкушал, как эта штука закроет 80% рутинных вопросов для вымышленного отдела технической поддержки. А на третьем вопросе, чуть более сложном, система поплыла... Он взял кусок из одного документа, кусок из другого и синтезировал уверенный, но абсолютно неверный ответ.

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

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

Базовая механика RAG (Retrieval-Augmented Generation) проста и состоит из четырех шагов:

В нашем workflow из n8n это блок «Simple RAG». Цепочка выглядит так: Chat Input → Embeddings → Search in Supabase → Basic LLM Chain.

У этого подхода есть три врожденных дефекта:

Чтобы это исправить, нам нужно прокачать нашего бота, добавив ему несколько новых «модулей» в его пайплайн. Если вы ещё не успели создать векторную базу в Supabase, можете воспользоваться готовым SQL шаблоном (у n8n есть особые требования к формату векторов внутри базы Supabase).

Я разберу четыре паттерна, которые превращают нашего «ленивого» бота в толкового ассистента.

Проблема: Семантический разрыв, о котором мы говорили выше. Пользователи формулируют мысли по-разному, используя сленг, синонимы или просто неточные выражения.

Решение: Вместо того чтобы сразу отправлять «сырой» запрос пользователя на поиск, мы сначала отдаем его LLM с простой задачей: переформулируй. Мы заставляем LLM поработать «переводчиком» с человеческого на язык, более понятный для векторного поиска. Новый модуль преобразует нечеткий запрос в несколько канонических, точных формулировок.

Цепочка немного меняется: User Input → LLM Chain (Query Transformation) → Search in Supabase.

Prompt для первой LLM-ноды: «Вы искусственный интеллект, задача которого переформулировать запросы пользователей для улучшения поиска... Перефразируйте его, чтобы он был более точным, подробным...». Так, запрос «оплата не пашет» превратится в «как исправить ошибку при проведении платежа», что с гораздо большей вероятностью найдет нужный документ.

Проблема: Пользователь задает не один вопрос, а несколько. Например: «Как мне обновить подписку, какие есть способы оплаты и где найти чек после этого?»

Решение: Учим LLM не отвечать, а декомпозировать. То есть разбивать один сложный вопрос на несколько простых, самодостаточных под-вопросов. А уже потом мы ищем ответы на каждый из них по отдельности и собираем весь найденный контекст вместе для финального ответа.

Это блок «Query Decomposition (RAG)». Пайплайн здесь становится заметно сложнее: LLM Chain (Query Decomposition) → Split Out → Loop → Aggregate → Basic LLM Chain.

Проблема: Векторный поиск всегда что-то находит. Даже если вопрос пользователя максимально далек от всего, что есть в базе знаний, алгоритм все равно вернет N-ное количество чанков, которые, по его мнению, наиболее близки. И этот нерелевантный мусор отправится в LLM, провоцируя его на галлюцинации.

Решение: Ввести простой, но эффективный контроль качества. Каждый документ, который возвращает векторный поиск, имеет score — числовой показатель его релевантности запросу. Мы можем просто установить порог и отсекать все, что не дотягивает до нужного уровня уверенности.

Это самый простой в реализации, но один из самых важных апгрейдов. Смотрим на блок «... + Score Filter». Сразу после ноды Search in Supabase мы добавляем ноду Filter. В ее настройках мы прописываем простое условие: пропускать дальше только те документы, у которых {{ $json.score }} больше, чем 0.5 (или 0.7 — это значение нужно подбирать экспериментально под вашу базу).

Если после фильтра не осталось ни одного документа, мы можем сразу выдать ответ «Извините, я не нашел информации по вашему вопросу», а не отправлять пустой контекст в LLM.

Проблема: Иногда сам по себе чанк текста слишком узкий и вырван из контекста. Например, кусок текста: «Для этого необходимо перейти в раздел «Профиль» и нажать кнопку «Сменить тариф»». Поиск по запросу «Как оплатить подписку?» может не найти этот чанк, потому что в нем нет слов «оплата» или «подписка».

Решение: Улучшить не процесс поиска, а процесс загрузки данных. Для каждого чанка, который мы загружаем в базу, мы можем с помощью LLM сгенерировать дополнительную мета-информацию: краткое саммари, список ключевых слов или гипотетические вопросы, на которые этот чанк отвечает.

Для этого используется отдельная ветка workflow «Supabase Vector Creates + Context Generator».Get Data → LLM Chain (Context) → Supabase Vector Store.

Обычно такие подходы дают +10-30% к качеству (цифры на основе моего датасета). Звучит здорово, но за все приходится платить. Эти апгрейды – не бесплатные.

Создание по-настояшему умного RAG-ассистента – это не про выбор самой «умной» LLM на рынке. Это про построение правильного пайплайна обработки запроса. Простой RAG – подходит для простых и примитивных систем. Если хотите что-то более сложное – нужны доработки и дополнительные модули. Именно они превращают «примитивный» поисковик в ассистента, который действительно пытается понять, что от него хотят.

Следующий логический шаг в этой эволюции – создание умного роутера. Это еще одна LLM-нода в самом начале, которая анализирует входящий вопрос и сама решает, по какому из наших пайплайнов его отправить. Если вопрос простой – по базовому пути. Если сложный и составной – по пути с декомпозицией. Это позволяет добиться баланса между скоростью, стоимостью и качеством ответа. Но об этом – как-нибудь в следующий раз.