Демо RAG-системы убеждает кого угодно. Продакшен убивает доверие за неделю: ассистент уверенно цитирует несуществующий пункт регламента, и пользователь перестаёт открывать систему. Разница между демо и эксплуатацией – измеримое качество. Ниже разбираем, какие метрики действительно отделяют рабочую систему от опасной, и как зафиксировать их в приёмке проекта.

Разделяйте поиск и генерацию

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

Метрики поиска:

  • Context Recall – доля случаев, когда нужный фрагмент попал в выдачу. Падает – значит, проблема в индексе, чанкинге или эмбеддингах, а не в LLM.
  • Context Precision – насколько релевантны поданные в контекст фрагменты. Низкая precision раздувает промпт мусором и провоцирует выдумки.

Метрики генерации:

  • Faithfulness – каждое утверждение ответа подтверждается поданным контекстом. Это ключевой барьер против галлюцинаций: модель не имеет права добавлять факты «от себя».
  • Answer Relevance – ответ отвечает на вопрос, а не пересказывает соседнюю тему.

Считать faithfulness вручную на масштабе невозможно. Рабочий подход – LLM-as-judge: отдельная модель разбивает ответ на атомарные утверждения и проверяет каждое против контекста. Метод не идеален, поэтому судью калибруют на размеченной экспертами выборке и периодически перепроверяют.

Стройте golden set под предметную область

Универсальных бенчмарков для корпоративных и государственных данных нет. Нужен свой набор из 150–300 пар «вопрос – эталонный ответ – источник», собранный вместе с предметными экспертами заказчика. Без участия юристов, методологов или профильных специалистов golden set измеряет не то, что важно бизнесу.

Включайте в набор не только типовые запросы, но и провокации: вопросы вне базы знаний, противоречивые формулировки, запросы на устаревшие редакции документов. Для госсектора это критично – цена уверенной выдумки в ответе про норму закона несопоставима с ошибкой в маркетинговом чат-боте. Здесь полезен опыт изоляции данных, который мы разбирали в материале про RAG в закрытом контуре: метрики качества и контур безопасности проектируются совместно, а не по очереди.

Отдельная метрика – доля корректных отказов. Хорошая система обязана говорить «в базе знаний нет ответа», а не сочинять. Считайте, как часто на вопросы-ловушки приходит честный отказ вместо галлюцинации. Для многошаговых сценариев добавьте контроль на уровне агентов – подход к декомпозиции мы описывали в статье про мультиагентные системы.

Фиксируйте пороги в приёмке

Метрики без порогов – украшение дашборда. В договоре и приёмочных тестах закрепляйте конкретные значения: например, faithfulness не ниже 0,9 и доля корректных отказов не ниже 0,85 на согласованном golden set. Это превращает «нравится / не нравится» в проверяемый критерий сдачи.

Контроль не заканчивается на приёмке. Базы знаний меняются, выходят новые редакции документов, дрейфует распределение запросов. Поэтому golden set прогоняют регулярно – при каждом обновлении индекса или модели и логируют живые ответы для офлайн-разметки. Если система работает на мобильных устройствах сотрудников, метрики качества дополняют требованиями к управлению доступом, как в кейсе по мобильному доступу в госсекторе.

Вывод

Качество RAG – не «ощущение от демо», а набор измеримых величин: recall и precision поиска, faithfulness и relevance генерации, доля корректных отказов. Соберите golden set с экспертами, зафиксируйте пороги в приёмке и прогоняйте их на каждом релизе. Так ИИ-ассистент остаётся инструментом, которому доверяют. Измеримость и контроль галлюцинаций закладываются ещё на этапе проектирования ИИ-приложения под предметную область, а не дорабатываются после запуска.