---
title: "Оценка качества RAG в n8n: как понять, что база — Nodbot"
source_url: "https://nodbot.ru/ai/rag-evaluation/"
canonical_url: "https://nodbot.ru/ai/rag-evaluation/"
language: "ru"
content_type: "AIGuide"
section: "ai"
generated_at: "2026-05-30"
word_count_source: 937
---

# Оценка качества RAG в n8n: как понять, что база знаний отвечает правильно

## AI summary

AI-гайд для n8n: Оценка качества RAG в n8n: как понять, что база знаний. Архитектура workflow, ограничения, проверки качества, безопасность и cost control.

## Best used for

Страница объясняет «Оценка качества RAG в n8n: как понять, что база — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Короткий ответ
- Что именно оценивать
- Golden dataset
- Retrieval metrics
- Generation metrics
- No-answer policy
- Freshness и регрессии
- Как встроить eval в n8n

## Source outline

# Оценка качества 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 | язык вопроса

Не делайте 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.

## Контроль качества AI-workflow

AI-workflow по теме «Оценка качества RAG в n8n» должен иметь измеримый контракт: что модель получает, какие действия ей разрешены, какой JSON она обязана вернуть и при каких условиях включается human review. Без этого качество нельзя отличить от удачного демо.

Отдельно фиксируйте версию prompt, модель, источники контекста и причину fallback. Главный риск — получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry.

- Слой | Что зафиксировать | Зачем
- Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам
- Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Оценка качества RAG в n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "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": []
  }
}
```

### Критерий готовности

- определён JSON-контракт ответа и validation step после модели
- опасные действия проходят через approval или создают только draft
- логируются prompt_version, model, sources, cost и fallback_reason
- есть eval-набор минимум для happy path, low confidence и prompt injection

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.