В этой статье
Главная мысль
Убедительная демонстрация не доказывает надёжность. Проверяйте, находит ли система доказательства, верно ли использует их и корректно ли действует без ответа. Сохраняйте экспертную проверку наряду с автоматическими оценками.
Создайте случаи, способные выявить ошибку системы
Начните с вопросов будущих пользователей. Для каждого запишите роль пользователя, редакцию источника, нужные доказательства и приемлемый результат. Некоторые вопросы не должны иметь ответа в коллекции. Другие требуют уточнить продукт, дату или юрисдикцию. Это полезные проверки, а не неудобные исключения.
Отделите оценочную коллекцию от примеров настройки промптов. Включите конкурирующие версии, противоречивые фрагменты и правдоподобные неверные названия продуктов. Попросите бизнес-эксперта объяснить приемлемость ответа внутреннего ассистента. Объяснение станет критерием для другого проверяющего вместо расплывчатого «выглядит хорошо».
Оценивайте поиск и генерацию отдельно
Ragas перечисляет точность и полноту контекста, релевантность ответа и верность источникам. Это полезные направления оценки. Сначала проверьте, найдены ли необходимые фрагменты. Затем — правильно ли ответ использовал их и действительно ли ответил на вопрос. Один общий балл затрудняет диагностику разных ошибок.
Автоматические оценщики — доказательства, а не окончательные судьи. Разбирайте расхождения с людьми, особенно в отраслевой терминологии и франкоязычных вопросах. Фиксируйте версии модели-оценщика и критериев, чтобы смену оценки не принять за улучшение приложения. При близких результатах изучайте ошибки, а не объявляйте небольшую числовую разницу решающей.
Три проверки перед доверием к ответу
Определите причину ошибки до изменения системы.
Найдены ли доказательства?
Проверьте выбранные фрагменты и недостающие источники.
Соответствует ли ответ доказательствам?
Проверьте фактические утверждения и подтверждающие цитаты.
Полезен ли результат?
Обсудите ответ, уточнение или передачу задачи с ответственным за процесс.
Явно проверяйте ссылки, отказы и права
Ссылка полезна, только если фрагмент подтверждает утверждение и читатель может его открыть. Проверяйте сломанные ссылки, удалённые документы и ответы из нескольких источников. Отмечайте неподтверждённые факты отдельно от стилистики. Красивый ответ с выдуманным условием допуска должен провалить проверку.
Добавьте отрицательные тесты для информации вне коллекции и вне прав пользователя. Проверьте враждебные инструкции внутри документов: найденный текст — материал для оценки, а не полномочие менять правила приложения. Задайте ожидаемые отказ, уточнение или передачу человеку. Не награждайте ассистента просто за постоянную выдачу ответа.
Включите оценку в каждый выпуск
Повторяйте сравнение при смене модели, эмбеддингов, разбиения, фильтров или коллекции источников. Сохраняйте базовый результат и изучайте различия по категориям. В значимом процессе регрессия прав должна блокировать выпуск даже при росте среднего балла. Критерии приёмки согласуйте с владельцем до получения результатов.
В эксплуатации сочетайте выборочную проверку людьми с метриками: временем ответа, ошибками загрузки, сообщениями о неподтверждённых ответах и стоимостью завершённой задачи. Не храните чувствительные диалоги только ради удобства панели. Практическая поставка включает отчёт оценки, примеры ошибок и процедуру восстановления. Так «ИИ стал лучше» превращается в проверяемое и обратимое изменение.
Создайте проверяемую коллегой запись теста
Для каждого случая храните вопрос, профиль доступа, применимую редакцию и ожидаемое поведение. «Правильный ответ» слишком расплывчато. Для вопроса о правилах укажите утверждение и подтверждающий фрагмент. Для запрещённого источника — отсутствие конфиденциального текста и названия. Для вопроса без ответа — ожидаемое уточнение или передачу.
Отделите эталонный набор от примеров настройки промптов. Включите обычные и сложные запросы, записав назначение каждого случая. При провале сохраняйте результаты поиска и ответ согласно политике хранения. Это даёт проверяющим доказательства вместо красного балла с недоступной причиной.
Небольшой реестр оценок
Пример структуры тестов. Ожидаемые результаты должен проверить владелец документов.
Прокрутите по горизонтали, чтобы прочитать таблицу →
| Случай | Ожидаемый результат | Что проверить в доказательствах |
|---|---|---|
| Известное правило, пользователь с доступом | Подтверждённый ответ по применимой редакции | Утверждение и подтверждающий фрагмент |
| Нет применимого правила | Уточнение или явная передача человеку | Никаких выдуманных правил |
| Источник с ограниченным доступом | Без конфиденциального текста и названия | Поиск, ответ, ссылки и кеши |
| Противоречивые редакции | Противоречие явно показано | Даты действия и владельцы источников |
Смотрите на размер выборки и последствия ошибок
Условные 18 верных ответов из 24 — это шесть ошибок, а не доказанная доля успеха в эксплуатации. Разберите безобидные различия формулировок, неподтверждённые утверждения и нарушения доступа. Повторяйте нестабильные случаи и показывайте состав выборки, чтобы успех на простых вопросах не скрывал слабую критическую категорию.
Автоматические метрики помогают находить проблемы и расставлять приоритеты проверки; калибруйте их по экспертным оценкам типичных ответов. Выпуск можно блокировать при любом обнаруженном нарушении доступа, отдельно оценивая поиск и пользу. Расширяйте внедрение постепенно и после анализа добавляйте реальные сбои в набор. Офлайн-тесты обосновывают выпуск, но не отменяют наблюдение в эксплуатации.
Источники и дополнительное чтение
Документация проверена .
ВОПРОСЫ / РЕШЕНИЯ
Частые вопросы
Есть ли единый целевой балл для промышленного RAG?+
Нет. Ошибки помощника для черновиков и ассистента по правилам имеют разные последствия. Определяйте пороги по типу ошибки и влиянию на бизнес, затем изучайте конкретные случаи.
Может ли LLM-оценщик заменить проверку человеком?+
Он помогает масштабировать отбор, но решения нужно калибровать по экспертной проверке. Сохраняйте участие людей в неоднозначных, чувствительных и значимых случаях.