Оценка качества LLM одной метрикой скрывает реальную причину ошибки: как разделить поиск и генерацию

Два исследования 2024 года вскрыли проблему, которую разработчики ИИ-сервисов часто игнорируют. Первое, «Large Language Models Sensitivity to The Order of Options in Multiple-Choice Questions», показало: если просто поменять местами варианты ответа в тесте, результат модели заметно меняется, хотя сам вопрос и содержание вариантов остаются прежними. Второе, «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena», описало, что модель-судья (LLM-as-a-Judge, когда одна модель оценивает ответ другой) тоже необъективна: она предпочитает более подробные ответы и зависит от позиции варианта в списке. Для исследователей это интересный эффект, для команды, которая выпускает ИИ-функцию в продакт, это инженерная задача с конкретными инструментами.

Почему одной оценки мало?

Обычный код проверяется просто: функция расчёта скидки получила 1000 и 10 процентов, вернула 900, всё верно. Вернула 850, тест упал. С языковой моделью так не работает.

В документации компании написано: «Заявку на отпуск нужно создать минимум за 14 дней». Модель отвечает: «Подайте заявку не позднее чем за две недели до начала отпуска». Точное совпадение строк (Exact Match) покажет ошибку, хотя смысл сохранён.

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

• Correctness (корректность): верны ли факты.
• Completeness (полнота): достаточно ли информации в ответе.
• Relevance (релевантность): отвечает ли модель на заданный вопрос, а не на свой.
• Faithfulness (верность источнику): опирается ли ответ на предоставленный контекст, без выдуманных деталей.
• Instruction Following (следование инструкциям): выполнены ли требования к формату и поведению.

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

Где ломается RAG и как это найти?

RAG (Retrieval-Augmented Generation, генерация ответа с опорой на найденные документы) ломается в нескольких точках, и только раздельное тестирование поиска и генерации позволяет понять, какую часть системы чинить.

Пользователь спрашивает внутреннего ИИ-ассистента о сроке возврата товара. В базе есть документ, где указано 14 дней. Ассистент отвечает «30 дней». Первая реакция: «модель галлюцинирует» (галлюцинация, когда ИИ уверенно выдумывает то, чего не было). Но причин может быть пять:

• Нужный документ не попал в результаты поиска.
• Поисковый модуль (retriever) нашёл устаревшую версию документа.
• Нужный фрагмент потерялся при разбивке документа на части (chunking).
• Правильный контекст попал в промпт, но модель его проигнорировала.
• Модель добавила утверждение, которого в контексте не было.

Первые три случая относятся к поиску (retrieval), последние два к генерации. Для пользователя разницы нет: ответ неправильный. Для разработчика разница огромная: исправлять придётся разные части системы.

Для поиска применяют отдельные метрики: Recall@K (нашёл ли поисковый модуль нужный документ среди K первых результатов), Hit Rate (доля запросов, где нужный документ вообще попал в выдачу) и MRR (насколько высоко нужный документ оказался в списке). Такое разделение retrieval и generation лежит в основе фреймворка RAGAS.

Как собрать тестовый набор?

Оценка качества LLM начинается не с выбора метрики, а с набора тестовых примеров (dataset). Один тестовый кейс может выглядеть так:

{
  "input": "Могу ли я отменить бронирование?",
  "expected_behavior": "Запросить тариф или условия бронирования",
  "category": "cancellation",
  "risk": "medium"
}

Здесь нет эталонного ответа, и он не обязателен. Есть ожидаемое поведение: система не должна угадывать условия отмены, а должна запросить недостающие данные. В набор стоит постепенно собирать:

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

Код, человек и модель-судья: три уровня проверки

Всё, что можно проверить кодом, проверяйте кодом. Валидность JSON, правильный вызов инструмента, корректная валюта: детерминированная проверка дешевле, быстрее и воспроизводимее, чем вызов отдельной модели.

Для смысловых критериев подключают LLM-as-a-Judge: модель-судья получает вопрос и ответ тестируемой системы, оценивает корректность по шкале от 1 до 5, возвращает оценку и обоснование. Но судью тоже нужно тестировать: разметить небольшую выборку силами экспертов, прогнать через судью и сравнить оценки. Если судья систематически расходится с людьми на определённом классе вопросов, проблема уже не в тестируемой модели. Также полезно менять порядок сравниваемых ответов, чтобы убрать то самое позиционное смещение, описанное в исследовании.

Что это значит для вас?

Авторам Дзена и копирайтерам. Если вы используете ИИ-ассистента для проверки фактов или подбора данных, помните: модель может уверенно назвать срок «30 дней» вместо «14 дней», и это не всегда проблема самой модели, а иногда сбой поиска по базе. Проверяйте факты по первоисточнику, а не по ответу ассистента.

Маркетологам и владельцам чат-ботов. Если клиентский бот ошибается в ответах о регламентах, сроках возврата или условиях доставки, не спешите менять модель целиком. Сначала проверьте retrieval-метрики (попадает ли нужный документ в контекст), и только потом generation (правильно ли модель интерпретирует найденное). В РФ подобные RAG-системы строят на базе YandexGPT и GigaChat, и принцип декомпозиции одинаков для любой модели.

Предпринимателям и руководителям. Требуйте от команды разработки не одну общую оценку качества ИИ-сервиса, а раздельные метрики по поиску и генерации. Без этого разделения невозможно понять, куда вкладывать ресурсы: в улучшение поисковой части, в дообучение (обучение модели на ваших примерах под узкую задачу) или в доработку промптов (промпт, текстовая инструкция для модели).

Разделение метрик поиска и генерации не требует сложных фреймворков на старте: достаточно двадцати размеченных кейсов и двух отдельных таблиц с результатами, одной для retriever, другой для модели. Кто начнёт с этого, перестанет гадать, почему бот «опять галлюцинирует», и начнёт чинить конкретное звено.

По данным исследований «Large Language Models Sensitivity to The Order of Options in Multiple-Choice Questions» и «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena»