RAG отвечает неправильно: runbook для n8n ¶

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

Intent: runbook RAG bad answers: плохие ответы RAG, retrieval, chunking, metadata filters, stale index, reranking, citations и eval questions
H1: RAG в n8n отвечает неправильно: как найти проблему в индексе, retrieval и prompt
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 655
New word count: 740

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

Если RAG в n8n отвечает неправильно, не начинайте с переписывания prompt. Сначала проверьте, попал ли нужный документ в vector store, как он разбит на chunks, есть ли metadata filters, свежий ли индекс и какие chunks реально вернул retrieval. Только после этого настраивайте top_k, reranking, prompt и правило ответа “не найдено в базе”. Большинство плохих RAG-ответов возникает не в LLM, а на этапе ingestion или retrieval.

Когда применять этот runbook ¶

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

Симптомы:

• пользователь спрашивает про известный документ, а AI отвечает “не знаю”;
• ответ есть, но относится к другому продукту/региону;
• RAG ссылается на старую версию политики;
• agent использует общий ответ вместо источников;
• retrieval возвращает нерелевантные chunks;
• top result похож по словам, но не по смыслу;
• после обновления документа ответ не изменился;
• модель уверенно дописывает то, чего нет в базе.

Цель — разделить проблему на четыре слоя: ingestion, index, retrieval, generation.

1. Проверить, есть ли документ в индексе ¶

Начните с конкретного вопроса и ожидаемого источника.

Запишите:

question = "Как клиенту поменять тариф?"
expected_doc = "billing-policy-v3.md"
expected_section = "Смена тарифа"
expected_answer = "..."

Проверьте ingestion:

• документ был загружен;
• парсер не потерял таблицы/заголовки;
• chunk содержит нужный фрагмент;
• metadata включает doc_id, version, product, locale, updated_at;
• старые версии не конкурируют с новой;
• refresh workflow действительно обновляет vector store.

Если нужный chunk отсутствует, prompt не поможет: модели просто нечего извлекать.

2. Проверить chunking ¶

Неправильная нарезка ломает даже хорошую базу знаний.

Для инструкций, тарифов и runbook-ов важно сохранять заголовок раздела и источник. Часто полезно добавлять в metadata не только URL, но и section_title, version, audience, status.

3. Посмотреть реальные retrieved chunks ¶

Не оценивайте только итоговый ответ. Нужно увидеть, что retrieval вернул до LLM.

Для каждого тестового вопроса сохраните:

• query;
• top_k chunks;
• score, если доступен;
• document ID;
• metadata;
• snippet;
• final answer;
• expected source;
• verdict: good / partial / wrong / stale.

Если в top_k нет правильного источника, проблема в retrieval или metadata. Если правильный источник есть, но ответ плохой, проблема в prompt/generation/format.

4. Исправить metadata filters ¶

Многие RAG-сбои происходят потому, что один vector store хранит разные продукты, языки, версии и аудитории.

Полезные фильтры:

Если фильтры слишком жёсткие, RAG ничего не найдёт. Если слишком мягкие, он найдёт “примерно похожее” и сгенерирует ошибку.

5. Настроить prompt для grounded answer ¶

После проверки retrieval можно чинить generation.

Добавьте правила:

• отвечай только по retrieved context;
• если источника нет, скажи “не найдено в базе”;
• указывай source_url или doc_id;
• не смешивай разные версии;
• не придумывай лимиты, цены и сроки;
• для конфликтующих источников показывай конфликт;
• коротко объясняй, какие документы использованы.

Для клиентского бота лучше дать safe fallback: “Я не нашёл точный ответ в базе, передам вопрос оператору”. Это лучше, чем уверенная галлюцинация.

6. Собрать RAG eval set ¶

Минимальный набор:

• 20 популярных вопросов;
• 10 вопросов по свежим документам;
• 10 “ловушек”, где ответа нет;
• 10 вопросов с похожими продуктами;
• 5 конфликтующих/устаревших источников;
• 5 вопросов с таблицами или тарифами.

Каждый тест должен проверять не только текст ответа, но и источник. RAG без source validation — это обычный чат с иллюзией базы знаний.

FAQ ¶

Почему RAG отвечает старой информацией после обновления документа?
Часто старая версия осталась в vector store или refresh workflow не удалил/не перезаписал chunks.

Что важнее: prompt или chunking?
Для RAG сначала ingestion/chunking/retrieval, потом prompt. Если нужный chunk не найден, prompt не спасёт.

Сколько chunks давать модели?
Достаточно, чтобы покрыть вопрос, но не настолько много, чтобы смешать контекст. Начинайте с малого top_k и проверяйте реальные retrieved chunks.

Нужен ли reranking?
Он полезен, если retrieval находит много похожих chunks, но порядок плохой. Но reranking не исправит отсутствие нужного документа в индексе.

{
  "request_id": "req_demo_001",
  "prompt_version": "2026-05-29",
  "input": "краткое нормализованное сообщение пользователя",
  "allowed_actions": ["read", "draft", "classify"],
  "forbidden_actions": ["send_without_review", "change_payment"],
  "expected_output": {
    "intent": "technical|support|sales|unknown",
    "confidence": 0.0,
    "needs_human_review": true,
    "sources": []
  }
}