Оценка качества RAG в n8n: как понять, что база знаний отвечает правильно ¶
Обновлено: 2026-05-29
Короткий ответ ¶
RAG нельзя оценивать по ощущению “ответ выглядит умно”. Нужно отдельно мерить retrieval и generation: нашёл ли vector store правильные chunks, использовал ли AI только источники, не придумал ли факт, указал ли актуальные ссылки и отказался ли отвечать при пустом контексте. Минимальный eval-набор для production — 50–100 вопросов с ожидаемыми источниками, правильным ответом, допустимыми отказами и порогами качества.
Что именно оценивать ¶
RAG состоит из двух частей, и каждая ломается по-своему.
| Слой | Что проверять | Типовая ошибка |
|---|---|---|
| Retrieval | релевантные chunks в top-k | найден похожий, но не тот раздел |
| Metadata filter | продукт, язык, регион, версия | ответ взят из устаревшей страницы |
| Context assembly | сколько текста ушло в LLM | нужный chunk обрезан |
| Generation | ответ по источникам | модель додумала деталь |
| Citation | source IDs/URL | ссылка есть, но не подтверждает тезис |
| No-answer policy | отказ при нехватке данных | уверенный ответ без источника |
Если вы измеряете только финальный текст, вы не поймёте, где чинить: chunking, embeddings, metadata или prompt.
Golden dataset ¶
Golden dataset — это таблица тестовых вопросов, на которых вы проверяете RAG после изменений.
Минимальные колонки:
| Поле | Зачем |
|---|---|
question_id |
стабильный ID кейса |
question |
реальный или синтетический вопрос |
expected_source_ids |
какие chunks/страницы должны быть найдены |
expected_answer_points |
факты, которые должны быть в ответе |
must_not_say |
запрещённые утверждения |
expected_behavior |
answer / clarify / refuse / human_review |
language |
язык вопроса |
product_area |
тема или раздел базы |
freshness_required |
важна ли дата источника |
Не делайте dataset только из простых вопросов. Включите конфликтные, неполные, устаревшие и вредные запросы.
Retrieval metrics ¶
Retrieval можно оценивать до вызова LLM, что дешевле и стабильнее.
Практичные метрики:
- top-1 relevance — первый chunk действительно отвечает на вопрос;
- top-k recall — нужный источник есть хотя бы в первых k chunks;
- wrong-source rate — как часто попадает похожая, но неверная статья;
- stale-source rate — доля устаревших источников;
- metadata filter pass — фильтры по языку/региону/продукту сработали;
- empty retrieval accuracy — система правильно не нашла ответ, когда его нет.
Для production полезно хранить retrieved source IDs в execution log. Тогда плохой ответ можно привязать к конкретному поиску.
Generation metrics ¶
Финальный ответ оценивайте по нескольким критериям:
| Метрика | Вопрос |
|---|---|
| Faithfulness | подтверждается ли ответ источниками |
| Completeness | покрыты ли важные пункты |
| Source accuracy | правильные ли ссылки/IDs |
| Refusal quality | отказался ли AI при нехватке данных |
| Actionability | можно ли выполнить рекомендацию |
| Safety | нет ли утечки PII, секретов или опасных советов |
Оценка “нравится/не нравится” не годится. Лучше шкала 0–2: 0 — провал, 1 — частично, 2 — проходит.
No-answer policy ¶
Хороший RAG должен уметь сказать “в базе нет ответа”. Это особенно важно для тарифов, юридических условий, платежей, безопасности и медицинских/финансовых тем.
Правила:
- если top-k не содержит источника — не отвечать из головы;
- если источники конфликтуют — отправить на review или уточнение;
- если источник устарел — отметить это;
- если вопрос вне зоны базы — предложить эскалацию;
- если пользователь просит секреты — отказать.
Отказы тоже нужно тестировать. Иначе RAG будет всегда звучать уверенно, даже когда база молчит.
Freshness и регрессии ¶
После обновления базы знаний качество может ухудшиться: новый документ вытеснил старый, metadata сломалась, chunk стал слишком большим, дубли начали конкурировать в top-k.
Перед деплоем нового индекса проверьте:
- старый eval-набор;
- вопросы по новым документам;
- устаревшие вопросы, где ответ должен измениться;
- конфликты между старыми и новыми источниками;
- долю ответов без источников;
- среднее количество chunks на вопрос;
- стоимость одного ответа.
Индекс должен иметь версию: rag_index_version, embedding_model, chunking_strategy, created_at.
Как встроить eval в n8n ¶
Один из вариантов:
- Manual Trigger или Schedule запускает eval workflow.
- Google Sheets/Postgres даёт список вопросов.
- Для каждого вопроса запускается тот же RAG workflow в test mode.
- Логируются retrieved source IDs, final answer, latency, model, cost proxy.
- Evaluation step считает метрики.
- IF node проверяет пороги.
- При провале отправляется alert владельцу RAG.
Пороги должны быть простыми:
{
"top_k_recall_min": 0.85,
"faithfulness_min": 0.90,
"source_accuracy_min": 0.90,
"no_answer_accuracy_min": 0.80,
"stale_source_rate_max": 0.05
}
FAQ ¶
Сколько вопросов нужно для eval?
Для старта хватит 50–100. Важно, чтобы они покрывали реальные сценарии, а не только удобные вопросы из документации.
Нужно ли оценивать каждый production-запрос?
Можно логировать все, но полную LLM-оценку делать выборочно: например, на sample или на спорных случаях с низким confidence.
Что делать, если retrieval хороший, а ответ плохой?
Чинить prompt, structured output, source-citation rule и no-answer policy. Если retrieval плохой — чинить ingestion, chunking, metadata и embeddings.