Почему демонстрация почти всегда выглядит лучше системы

Корпоративный RAG легко показать на пяти удобных вопросах. Разработчик знает формулировки, нужные документы свежие, а в базе нет дубликатов и противоречий. Модель отвечает уверенно, ссылка открывается — кажется, что решение готово к работе.

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

Поэтому RAG нужно экзаменовать как минимум по трём независимым контурам:

1. нашёл ли поиск нужные доказательства;
2. опирается ли ответ только на найденные доказательства;
3. умеет ли система остановиться, когда доказательств недостаточно или они конфликтуют.

Такое разделение соответствует логике RAGAS: фреймворк содержит отдельные метрики для качества контекста, чувствительности к шуму, релевантности ответа и faithfulness — соответствия ответа найденному контексту. Одна цифра удобна для слайда, но бесполезна для ремонта конвейера.

Тест №1: поиск и ранжирование

Сначала генератор следует отключить. Для каждого вопроса тестовый набор должен хранить идентификаторы документов или фрагментов, которые эксперт считает достаточными для ответа. Затем проверяется только выдача retriever и reranker.

Минимальный набор показателей:

  • **context recall** — все ли необходимые доказательства попали в выдачу;
  • **context precision** — не забита ли верхняя часть выдачи нерелевантными фрагментами;
  • позиция первого полезного документа;
  • доля запросов, где соблюдены фильтры подразделения, продукта, даты и прав доступа;
  • чувствительность к опечаткам, сокращениям и разговорным формулировкам.

Если нужный регламент не попал в top-k, смена промпта генератора проблему не исправит. Нужно разбираться с разбиением документов, метаданными, эмбеддингами, гибридным поиском, reranker или актуальностью индекса.

Отдельно проверьте версии. В тесте с двумя редакциями инструкции поиск должен поднять действующую, а старую либо исключить фильтром, либо явно пометить как архивную. Для закрытых документов критерий ещё строже: фрагмент, недоступный пользователю, не должен попадать в контекст вообще. Это не «ошибка качества», а инцидент доступа.

Тест №2: ответ и опора на источники

После того как поиск стабилен, подключается генератор. На этом слое оценивается не красота текста, а связь каждого существенного утверждения с контекстом.

Полезны четыре раздельных вопроса:

  • отвечает ли текст на исходный запрос;
  • поддерживается ли каждое фактическое утверждение найденными фрагментами;
  • ведут ли ссылки к тем местам, которые действительно подтверждают вывод;
  • не потерял ли ответ важное ограничение, срок, исключение или единицу измерения.

Faithfulness не равна фактической истине во всём мире. Она показывает, следует ли ответ переданному контексту. Если в базе лежит устаревший документ, модель может быть идеально «верной» плохому источнику. Поэтому владельцу знаний всё равно нужны дата актуальности, ответственный за документ и процесс удаления или архивирования старых версий.

Автоматический LLM-судья ускоряет прогон сотен примеров, но не является нейтральным измерительным прибором. Его версия, промпт и температура должны фиксироваться. Часть выборки регулярно проверяет человек, а спорные результаты сохраняются вместе с объяснением. Для локального контура судью можно запустить внутри периметра, однако совпадение генератора и судьи по модели повышает риск одинаковых слепых зон.

Тест №3: правильный отказ

Самая недооценённая часть набора — вопросы без ответа. EnterpriseRAG-Bench моделирует около 500 тысяч корпоративных документов из девяти типов источников и 500 вопросов, включая поиск по нескольким документам, конфликты и распознавание отсутствующей информации. Это ближе к рабочей базе, чем коллекция чистых FAQ.

Добавьте в собственный набор как минимум четыре класса отрицательных примеров:

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

Корректное поведение различается. При отсутствии данных система сообщает, чего не хватает, и предлагает маршрут эскалации. При конфликте показывает обе версии и просит владельца процесса выбрать источник истины. При запрете доступа не раскрывает даже содержание скрытого фрагмента. Универсальная фраза «не знаю» безопасна, но мало полезна; выдуманный ответ удобен ровно до первого решения на его основе.

Для отказа нужны собственные показатели: доля корректных отказов, доля ложных отказов на вопросах с ответом и доля опасных ответов без достаточного подтверждения. Последний показатель обычно важнее среднего балла по стилю.

Как собрать золотой набор без исследовательской лаборатории

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

Разделите набор по сценариям:

  • простой факт из одного документа;
  • ответ из нескольких документов;
  • таблица, приложение или скан;
  • новая и старая редакции;
  • синонимы, аббревиатуры и опечатки;
  • ограничение по роли или подразделению;
  • конфликт источников;
  • отсутствие ответа.

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

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

Минимальная архитектура измерений

Каждый запрос должен оставлять трассу между компонентами:

`вопрос → фильтры доступа → найденные фрагменты → reranker → контекст модели → ответ → ссылки → решение об отказе`.

В журнал оценки записываются идентификатор версии индекса, модель эмбеддингов, параметры top-k, версия reranker, модель и промпт генератора, задержка, использованные фрагменты и результат проверок. Без этой информации команда видит падение качества, но не может связать его с изменением.

Нужны два цикла:

1. **Офлайн-регрессия.** Золотой набор запускается при изменении документов, парсера, chunking, модели, промпта или параметров поиска. Новая версия сравнивается с предыдущей по каждому классу вопросов.
2. **Контроль эксплуатации.** Небольшая обезличенная выборка реальных диалогов регулярно уходит предметным экспертам. Отслеживаются новые темы, ложные отказы, устаревшие документы и запросы, которые тестовый набор не покрывает.

Российский рынок движется в ту же сторону. В апреле CNews описал обновление «Нейросаппорта» с песочницей, где администратор проверяет типовые ответы до их появления в клиентских диалогах. Цифра о возможном качестве 80% и выше приведена по внутреннему тестированию поставщика и не должна переноситься на другой процесс без собственного набора и критериев. Важнее сам принцип: изменения базы знаний сначала проходят проверку вне боевого канала.

Порог запуска зависит от риска

Универсального «достаточно 85%» не существует. Ошибка в подсказке по навигации и ошибка в инструкции по оплате имеют разную цену. Сначала определите классы риска, затем назначьте пороги и реакцию.

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

Экономика тестирования тоже считается. Автоматические судьи расходуют токены или локальные GPU, экспертная разметка — рабочее время. Сократите расходы каскадом: дешёвые детерминированные проверки запускайте на всей выборке, LLM-судью — на содержательных метриках, человека — на рисковых и спорных примерах. Стоимость такого контура сравнивайте не с нулём, а со стоимостью неверных ответов, повторной работы и потери доверия.

План на десять рабочих дней

  • Дни 1–2: выбрать один процесс и собрать 80 вопросов восьми типов.
  • Дни 3–4: эксперт размечает источники, обязательные факты и правильные отказы.
  • День 5: зафиксировать текущую конфигурацию и снять базовую линию поиска.
  • Дни 6–7: подключить метрики ответа и вручную проверить минимум 20% примеров.
  • День 8: изменить только один компонент — например, chunking или reranker — и сравнить с базовой линией.
  • День 9: прогнать закрытую контрольную часть и проверить права доступа.
  • День 10: принять решение о пилоте, записать ограничения и настроить регулярный регрессионный запуск.

Первый управленческий артефакт такого проекта — не чат и не список моделей, а таблица вопросов, источников, рисков и критериев приёмки. Если команда не может показать, где сломался поиск, где генерация и где отказ, RAG пока нельзя безопасно улучшать: любую замену модели придётся оценивать на глаз.