Когда агент отвечает по документам, хороший текст ещё не доказывает качество. Нужно проверить, был ли найден правильный источник, не исказился ли смысл и что происходит, если информации нет.

Простое определение

RAG Quality — это проверка качества ответов, которые агент строит по документам. Она смотрит не только на итоговый текст, но и на путь: какой источник найден, насколько он подходит, не искажён ли смысл и что агент делает при нехватке данных.

Хороший RAG-ответ должен быть связан с approved source. Если источника нет, агент должен остановиться, признать gap или передать вопрос человеку.

Связь с AI Radar

AI Radar может дать quality signal: например, tool page стала reviewed, needs live review или требует обновить RAG route. Такой signal не меняет RAG Quality сам по себе. Он должен пройти Source Evidence Policy, затем попасть в eval scenarios, RAG Quality Report или Harness backlog.

Почему одного хорошего ответа мало

Агент может написать уверенный ответ и при этом использовать не тот fragment, устаревший источник или общий текст вместо approved policy. Снаружи это выглядит прилично. Внутри это риск: команда не понимает, почему ответ появился и можно ли ему доверять.

Поэтому RAG Quality проверяет четыре вещи: retrieval, grounded answer, gap behavior и decision path.

Что проверять

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

  • найден ли правильный approved source;
  • не пропущен ли важный источник;
  • не искажён ли смысл документа;
  • видит ли агент missing information;
  • корректно ли он ведёт себя при конфликтующих источниках;
  • не появляются ли forbidden claims;
  • попадает ли результат в decision log или improvement backlog.

Eval set

Первый eval set не должен быть большим. Он должен быть честным:

  • covered questions — вопросы, где source точно есть;
  • missing questions — вопросы, где source нет;
  • conflict questions — вопросы, где источники расходятся;
  • forbidden claim questions — просьбы назвать неподтверждённую цену, гарантию, срок или high-risk advice;
  • freshness questions — вопросы, где важна дата source review.

Metrics

Метрики полезны, если команда понимает, что они проверяют. В RAG-контексте часто смотрят:

  • Context Precision — насколько найденный контекст релевантен вопросу;
  • Context Recall — не пропустил ли retrieval важную информацию;
  • Faithfulness — не искажает ли ответ найденный контекст;
  • Response Relevancy — отвечает ли текст на вопрос;
  • missing information behavior — останавливается ли агент, когда источника нет.

Метрика не должна быть единственным approval signal. Она показывает, где копать.

Как это связано с Ragas

Ragas может быть tool layer для части RAG quality checks. Но сама задача шире инструмента: нужен Knowledge Pack, Source Map, eval questions, reference answers и decision log.

Ragas
→ RAG Quality
→ Knowledge Pack
→ Harness

Если Ragas используется в проекте, его страница должна иметь source_status: reviewed, source_urls и source_review_notes.

RAG Quality Report

RAG Quality Report — следующий слой после проверки. RAG Quality показывает, что проверять, а report фиксирует, что найдено и как это исправляется.

Отчёт должен быть коротким и рабочим:

  • checked area;
  • issue;
  • evidence;
  • severity;
  • recommended fix;
  • owner;
  • status.

Так quality check превращается не в «оценку ради оценки», а в backlog улучшений для Knowledge Pack и Harness. После report finding идёт в Decision Log: issue found → decision → fix → retest → reviewed.

Stop-lines

Нельзя отправлять RAG в production, если:

  • source map не готов;
  • нет reference answers;
  • gaps скрываются уверенным текстом;
  • high-risk ответы не уходят в handoff;
  • vendor/tool claims не прошли source review;
  • decision log не фиксирует, почему команда считает сценарий допустимым.

Следующий маршрут

Если выбираете eval tool, начните с Ragas. Если готовите источники, переходите к Knowledge Pack и Prepare Knowledge Base. Если нужно управлять качеством процесса, следующий слой — Harness.