Удачная демонстрация на одном вопросе показывает отдельный ответ. Для решения о внедрении нужен повторяемый набор проверок: что система нашла, чем обосновала вывод и как поступила при недостатке данных. Сначала фиксируют рабочие сценарии и критерии, затем сравнивают версии. Иначе привлекательный ответ может скрыть неверную редакцию, пропущенное исключение или недоступный пользователю источник.
Подготовьте контрольный набор
Попросите специалиста, который знает документы, составить вопросы из реального процесса. Для каждого укажите допустимый ответ, документ и редакцию, нужный фрагмент, роль пользователя и существенные условия. Включите простые запросы, вопросы по нескольким документам, сокращения и неоднозначные формулировки. Отдельно нужны случаи, где ответа нет, документы противоречат друг другу или доступ к материалу запрещён.
Набор для итоговой проверки следует отделить от примеров, по которым настраивают систему. Искусственные вопросы допустимы как дополнение после проверки специалистом. Сохраняйте список документов и их версии: результат на одной редакции корпуса нельзя автоматически переносить на другую. Такой протокол — предлагаемый порядок приёмки проекта, а не опубликованный результат испытаний НЬЮ-ССТ.
Оценивайте поиск и ответ отдельно
Если нужный фрагмент не найден, проблема отличается от ситуации, когда модель получила правильный источник, но исказила его смысл. Haystack предусматривает оценку компонентов и всей цепочки; Ragas выделяет метрики поиска, релевантности и обоснованности ответа.
Для практической приёмки предлагаем такую таблицу:
| Проверка | Что считать |
|---|---|
| Поиск основания | Долю вопросов, для которых нужный фрагмент вошёл в первые пять результатов |
| Подтверждённый ответ | Долю вопросов, где существенные утверждения подтверждены указанными источниками |
| Ссылка на источник | Долю проверенных ссылок, ведущих к нужному документу, редакции и фрагменту |
| Недостаток данных | Число корректных отказов от необоснованного ответа среди специально отобранных случаев |
| Доступ | Число случаев раскрытия запрещённого материала в ответе, ссылке или доступном пользователю журнале |
| Скорость | Медиану и 95-й процентиль времени полного ответа при заданной нагрузке |
Для каждой доли сохраняйте числитель и знаменатель. Не объединяйте в один процент качество поиска, итогового ответа и безопасность доступа: эти показатели отвечают на разные вопросы.
Пример измеримых критериев
Допустим, стороны согласовали 20 контрольных вопросов. В проекте можно установить ориентир: нужное основание найдено среди первых пяти результатов минимум для 18 из 20 вопросов. Для всех выданных существенных утверждений требуется проверяемое основание; при его отсутствии система должна обозначить неопределённость. Отдельный тест закрытого документа должен завершаться без раскрытия содержания и его фрагментов.
Эти числа — иллюстрация критериев для согласования, а не достигнутые показатели или условия существующего коммерческого этапа. Размер набора, пороги и допустимую задержку определяют до проверки с учётом риска. Прохождение 20 вопросов не даёт гарантии для любого будущего запроса. Отчёт должен содержать ошибки и ограничения вместе с успешными примерами.
Проверяйте изменения как новую версию
Сохраняйте идентификаторы модели, весов, среды запуска, шаблона запроса, модели поиска и корпуса. Запись «используется последняя версия» недостаточна для повторения результата. Например, Hugging Face Hub позволяет обращаться к конкретной ревизии, в том числе полному хешу коммита.
Перед обновлением предлагаем сравнивать кандидата с принятой версией на неизменном контрольном наборе и добавлять случаи, затронутые изменением. Замена модели поиска может потребовать перестроения индекса; обновление документов — повторной проверки связанных ответов. Решение о выпуске принимают по протоколу, сохраняя предыдущую совместимую конфигурацию для отката. Откат тоже проверяют: старый файл модели без подходящего индекса и настроек ещё не означает готовое восстановление.
Где нужен человек
Автоматическая оценка помогает обрабатывать много примеров. Если оценщиком служит языковая модель, фиксируют её версию и настройки. Ошибки, спорные случаи и существенные решения проверяет специалист. Документы также могут содержать инструкции, пытающиеся изменить поведение помощника. OWASP описывает такие косвенные атаки и рекомендует ограничивать привилегии, разделять недоверенное содержимое и проверять границы доступа. Поисковому помощнику не нужны самостоятельные полномочия отправлять документы или менять записи.
НЬЮ-ССТ предлагает начать обсуждение с процесса и способа приёмки. Результатом согласованного этапа должны стать понятные материалы: контрольный набор, таблица ответов с источниками, перечень ошибок и решение о следующем шаге. Обсудить проверку: опишите тип вопросов, пользователей и последствия неверного ответа; закрытые документы для первоначального обращения не требуются.