RAG в n8n: как сделать базу знаний, которая отвечает по источникам ¶

Обновлено: 2026-05-29

Короткий ответ ¶

RAG в n8n нужен, когда AI должен отвечать не “из головы”, а по вашим документам: базе знаний, регламентам, тарифам, инструкциям, FAQ или внутренней wiki. Качественный RAG — это не только vector store и embeddings, а полный процесс: подготовить документы, правильно нарезать chunks, добавить metadata, настроить retrieval, показывать источники, проверять ответы на тестовом наборе и регулярно обновлять индекс. Если пропустить хотя бы один слой, агент будет звучать уверенно, но ссылаться на устаревшие или нерелевантные данные.

Когда RAG действительно нужен ¶

RAG подходит, если ответ зависит от приватных или часто меняющихся знаний: внутренних регламентов, цен, инструкций, условий продукта, статей поддержки. Он не нужен для простых задач вроде классификации текста, извлечения email или генерации короткого summary — там достаточно LLM без базы знаний.

Архитектура RAG workflow ¶

Типовой RAG в n8n состоит из двух разных workflow: ingestion и answering.

Ingestion workflow:

1. забирает документы из Notion, Google Drive, сайта, Git, PDF или базы;
2. очищает HTML/markdown от меню, footer и мусора;
3. режет текст на chunks;
4. добавляет metadata;
5. создаёт embeddings;
6. записывает chunks в vector store;
7. логирует версию индекса.

Answering workflow:

1. получает вопрос пользователя;
2. нормализует язык, продукт, тариф, регион;
3. делает retrieval по vector store;
4. фильтрует источники по metadata;
5. передаёт найденные chunks в AI Agent или QA chain;
6. требует ответ со ссылками на source IDs;
7. отправляет review, если источники слабые или конфликтуют.

Разделение важно: если ingestion и answering смешаны, вы не сможете понять, проблема в документах, embeddings, retrieval или prompt.

Подготовка документов ¶

Плохой документ для RAG — это страница, где вперемешку меню, реклама, хлебные крошки, кнопки, похожие FAQ и устаревший текст. Перед embedding нужно оставить только смысловой контент.

Минимальная очистка:

• удалить навигацию, footer, “читать дальше”, cookie banners;
• сохранить заголовки H2/H3 как часть контекста;
• добавить source_url, title, updated_at;
• пометить deprecated-страницы;
• разбить большие таблицы на осмысленные блоки;
• убрать дубли между языковыми/print-версиями.

Если база знаний изначально хаотичная, RAG не исправит её. Он только сделает хаос быстрее доступным.

Chunking: где чаще всего ошибка ¶

Слишком короткие chunks теряют смысл, слишком длинные тащат лишний шум. Начинайте с логического chunking по разделам, а не просто по 1000 символов.

Добавляйте overlap только там, где разделы реально зависят друг от друга. Большой overlap увеличивает стоимость и делает retrieval более шумным.

Metadata: главный способ снизить hallucination ¶

Metadata помогает не искать “во всех документах сразу”. Для Nodbot-подобного сайта полезны:

{
  "source_url": "/ai/rag/",
  "title": "RAG в n8n",
  "section": "chunking",
  "product": "n8n",
  "language": "ru",
  "audience": "developer",
  "updated_at": "2026-05-29",
  "status": "current"
}

Для customer support добавьте plan, region, product_line, version, visibility. Если клиент спрашивает про тариф в РФ, retrieval не должен подмешивать старый англоязычный документ для другого рынка.

Как проверять качество retrieval ¶

Не оценивайте RAG только по красоте финального ответа. Сначала проверьте, какие chunks возвращаются.

Тестовый набор должен включать:

• точные вопросы, где источник очевиден;
• вопросы с синонимами;
• вопросы с устаревшей информацией;
• вопросы без ответа в базе;
• конфликтующие документы;
• вопросы на другом языке;
• короткие запросы из 2–3 слов.

Для каждого вопроса храните expected source IDs. Если retrieval не достал правильный источник, prompt уже не спасёт.

Ответ должен показывать источники ¶

Production RAG должен возвращать не только текст, но и список источников.

{
  "answer": "...",
  "sources": [
    {"source_url":"/ai/rag/", "section":"Metadata", "confidence":0.84}
  ],
  "needs_human_review": false,
  "missing_information": []
}

Если sources пустые, запрещайте уверенный ответ. Лучше честно сказать, что в базе знаний нет подтверждения, чем сгенерировать “правдоподобный” ответ.

Обновление индекса ¶

RAG устаревает тихо: документы обновили, а embeddings остались прежними. Нужен refresh-процесс.

Проверяйте:

• изменился ли updated_at источника;
• удалены ли deprecated chunks;
• не задвоились ли chunks после re-index;
• сохраняется ли версия embedding model;
• есть ли smoke test после обновления базы;
• кто владелец документа.

Для критичных баз знаний обновление индекса лучше запускать по событию изменения документа, а не только вручную.

FAQ ¶

Можно ли собрать RAG без vector store?
Для маленькой базы можно передавать несколько документов прямо в prompt, но это быстро упирается в context window и стоимость. Vector store нужен, когда документов много и нужен поиск по смыслу.

Что важнее: embeddings или prompt?
Для RAG сначала важны документы, chunking и retrieval. Prompt не исправит ситуацию, когда в контекст попал неправильный источник.

Почему RAG даёт плохие ответы, хотя документы есть?
Чаще всего из-за плохой очистки документов, слишком крупных chunks, отсутствия metadata, устаревшего индекса или слабого тестового набора.