Проверить качество базы

Один неправильный ответ — разные причины§

Система может точно пересказать устаревший документ. Может найти правильную инструкцию, но потерять исключение. Может ответить правильно по существу, раскрыв недоступный пользователю материал. Такие ошибки требуют разных исправлений.

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

Оценка должна отражать рабочее решение§

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

Учебный пример. Для вопроса о процедуре на прошивке 4.1 корректный результат может быть запросом уточнения или сообщением об отсутствии утверждённой процедуры. Красивый уверенный ответ не получает высокий балл только за подробность.

Автоматические оценки полезны в своих границах§

RAGAs разделяет несколько измерений оценки RAG, включая найденный контекст и опору генерации на него. Такая декомпозиция помогает быстрее искать проблемное место. Однако согласованность ответа с неверным источником не превращает его в истинный.

Для дорогих ошибок сохраняйте экспертную проверку и отдельные обязательные условия. Средняя оценка может скрыть единичное раскрытие данных или применение опасного исключения. Эти случаи нужно видеть по отдельности.

Карточка проверочного случая§

Оцените по слоям§

Сохраняйте исходный вопрос, найденные записи, ответ и вердикт с причиной. Это позволит отличить случайный удачный ответ от воспроизводимого поведения и повторить проверку после изменения системы.

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

Выберите несколько понятных показателей§

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

Числа учебного пилота не становятся обещанием качества на всех будущих вопросах. Сохраните отдельную часть случаев для проверки после настройки. Добавляйте новые случаи из реальных ошибок, не забывая перепроверять исходные сценарии.

Эксперимент должен отвечать на один вопрос§

Зафиксируйте корпус, версию индекса, конфигурацию поиска, модель и набор проверок. Меняйте один существенный компонент либо явно описывайте пакет изменений. Иначе улучшение нельзя уверенно связать с конкретным решением.

Сравнивайте варианты на одинаковых вопросах. Для недетерминированной системы рассмотрите повторные прогоны и показывайте разброс. Если оценка получена на небольшой удобной выборке, не выдавайте её за точность для всех пользователей и процессов.

Проверьте самого оценщика§

Если ответы оценивает LLM, подготовьте часть примеров с экспертным вердиктом. Проверьте, замечает ли оценщик неверную версию, неподдержанное утверждение и пропущенное исключение. Запишите его модель, инструкцию и входные данные.

Автоматический оценщик удобен для регулярного сравнения, но способен разделять систематическую ошибку с генератором. Случаи разногласия с экспертом полезно сохранять как диагностический набор, а не скрывать за общим средним.

Обязательные условия и постепенный выпуск§

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

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