RAG in a box: document Q&A

RAG (retrieval-augmented generation) — паттерн, при котором модель отвечает не «из головы», а по фрагментам ваших документов, найденным под конкретный вопрос. Это решает две проблемы LLM: незнание внутренних данных компании и галлюцинации.

В n8n RAG — это ДВА независимых workflow, и путать их не стоит.

Ingestion (наполнение): документы → разбиение на чанки → превращение чанков в embeddings (числовые векторы смысла) → запись в vector store. Запускается при появлении новых документов.

Retrieval (ответы): вопрос пользователя → поиск ближайших по смыслу чанков в store → LLM формулирует ответ, опираясь на найденное. Запускается на каждый вопрос.

Выбор vector store: Simple Vector Store живёт в памяти инстанса — данные исчезают при рестарте, только для прототипов; production-варианты — Qdrant, Pinecone, PGVector, Supabase. Embeddings-модель задаётся sub-нодой (например, Embeddings OpenAI с text-embedding-3-small).

Железное правило: в ingestion и retrieval должна использоваться ОДНА И ТА ЖЕ embeddings-модель. Векторы разных моделей несравнимы — поиск будет возвращать мусор, причём без ошибок, молча. Это самый частый и самый незаметный баг RAG-систем.

Ingestion-workflow начинается с любого триггера: n8n Form Trigger с полем загрузки файла, Google Drive Trigger на новые файлы в папке, Schedule Trigger для регулярной пересборки.

Дальше — нода vector store в режиме Insert Documents с двумя sub-нодами:

• Default Data Loader — принимает бинарные данные (PDF, txt, markdown, JSON, CSV) и превращает их в документы; здесь же добавляются metadata;
• Recursive Character Text Splitter — режет документ на чанки.

Стартовые параметры сплиттера:

{ "chunkSize": 1000, "chunkOverlap": 200 }

Интуиция: меньше чанк — точнее попадание поиска, но меньше контекста достаётся модели; больше чанк — наоборот. Перекрытие спасает мысли, разрезанные по границе чанков: конец предыдущего повторяется в начале следующего.

Metadata — недооценённая часть ingestion. Добавьте source (имя файла), section, version, updatedAt — и получите три возможности: фильтровать поиск, показывать пользователю ссылку на источник и вычищать старые версии документов при обновлении.

После первого прогона откройте execution и проверьте фактуру: сколько чанков получилось, как выглядит их текст, не разрезало ли таблицы посередине. Кривой чанкинг не чинится никаким промптом на стороне retrieval.

Самый практичный retrieval-паттерн в n8n: Chat Trigger → AI Agent с подключённым Vector Store Tool, внутри которого — ваш vector store и ТЕ ЖЕ embeddings, что в ingestion.

Два параметра решают почти всё.

Первый — description инструмента. Агент вызывает поиск не всегда, а когда решит, что он нужен, и решает по описанию. Пишите конкретно, ЧТО лежит в базе: «База знаний продукта Vorcl: тарифы, интеграции, инструкции по настройке, FAQ». С описанием «поиск по документам» агент будет то забывать про базу, то дёргать её на «привет».

Второй — Limit (top K): сколько чанков вернуть, обычно 3-5. Меньше — риск не найти нужное; больше — шум и лишние токены в контексте.

В system message агента добавьте правило честности: «Отвечай только по фрагментам из инструмента. Если ответа в них нет — так и скажи, не выдумывай». Это главный рычаг против галлюцинаций поверх RAG.

Если не нужны ни диалог, ни инструменты — берите Question and Answer Chain: вопрос → поиск → ответ, дешевле и предсказуемее агента. Правило то же, что в уроке 2: агент — когда нужны решения, chain — когда нужен конвейер.

Когда Q&A «отвечает мимо», не крутите все параметры сразу — диагностируйте по слоям.

Слой 1: поиск не находит нужный чанк. Проверьте напрямую: выполните поиск по store с вопросом пользователя и посмотрите на top-5 результатов. Если нужного фрагмента нет — уменьшайте chunkSize, добавляйте заголовки разделов в текст чанков, проверьте, что embeddings-модель адекватна языку документов.

Слой 2: чанк найден, но ответ его игнорирует. Это промпт-проблема: ужесточайте system message («отвечай ТОЛЬКО по фрагментам»), снижайте temperature до 0-0.2.

Слой 3: ответы устарели. Пересобирайте индекс по расписанию, храните в metadata версию и дату, при обновлении документа удаляйте его старые чанки — иначе поиск будет выдавать обе версии вперемешку.

Частые антипаттерны: Simple Vector Store в production (рестарт инстанса — база пуста, а рестартует n8n регулярно); чанки на 4000+ токенов «чтобы всё влезло» — поиск теряет точность; один store для разнородных доменов без metadata-фильтров.

И главное: соберите тестовый набор из 10-20 пар «вопрос → ожидаемый источник» и прогоняйте его после каждого изменения параметров. Без него тюнинг RAG — гадание на кофейной гуще.