«Вроде стало лучше» не метрика. Ответы модели вероятностные и длинные, поэтому оценка LLM-систем отдельная дисциплина: на собесе мидла и сеньора её спрашивают почти всегда.
Оценочный набор
Основа всего: золотой набор примеров с ожидаемым результатом.
- Источники: реальные запросы из логов (обезличенные), примеры от экспертов, краевые случаи, известные провалы из прода.
- Размер: десятки примеров для быстрого цикла разработки, сотни для решений о выкатке.
- Разметка: эталонный ответ, список фактов, которые должны прозвучать, релевантные документы для поиска, ожидаемый класс или вызов инструмента.
- Набор живёт: каждый найденный в проде провал добавляется в него как регрессионный тест.
Не учите и не подбирайте промпт на тех же примерах, на которых меряете: держите отдельную тестовую часть.
Метрики поиска
Если в системе есть ретривер, меряйте его отдельно:
- Recall@k: доля релевантных документов, попавших в топ-k. Для RAG главная: не нашли, значит, не ответим.
- Precision@k: доля релевантных среди топ-k.
- MRR (mean reciprocal rank): среднее по запросам от
1 / позиция первого релевантного. Хороша, когда нужен один правильный документ. - nDCG@k: учитывает градации релевантности и позицию с логарифмическим дисконтом.
- Hit rate@k: доля запросов, где в топ-k есть хотя бы один релевантный.
Метрики генерации
- Точное совпадение и классификационные метрики там, где ответ дискретный: класс, число, JSON-поле. Accuracy, precision, recall, F1.
- Лексические метрики (BLEU, ROUGE) сравнивают слова с эталоном. Для свободных ответов коррелируют с качеством слабо: правильный ответ можно сказать другими словами.
- Семантическое сходство с эталоном через эмбеддинги. Лучше лексики, но не ловит фактические ошибки в похожей формулировке.
- Специфичные для RAG: верность контексту (faithfulness: каждое утверждение подкреплено найденным контекстом), релевантность ответа вопросу, полнота.
- Программные проверки: валидный JSON, нет запрещённых слов, ссылки на существующие документы, длина в рамках.
LLM-as-judge
Другая модель оценивает ответ по рубрике: «оцени от 1 до 5 полноту», «какой из двух ответов лучше». Масштабируется дешевле людей, но у судьи есть известные искажения:
- Позиционное: в попарном сравнении судья предпочитает ответ на определённой позиции (часто первый). Лечится прогоном в обоих порядках и учётом только согласованных побед.
- Многословность: длинные ответы оцениваются выше. Рубрика должна явно штрафовать воду.
- Самопредпочтение: модель выше оценивает ответы своей семьи моделей.
- Неустойчивость шкалы: оценки 1-10 плавают; бинарные вопросы («есть ли в ответе утверждение без опоры на контекст: да или нет») надёжнее.
- Слабость в фактах: судья может не знать, верен ли факт; давайте ему эталон или контекст.
Обязательный шаг: калибровка судьи на ручной разметке. Размечаете 100-200 примеров людьми, меряете согласие судьи с людьми (accuracy, каппа Коэна), итеративно правите рубрику. Только после этого судье можно доверять на масштабе, и то с выборочной проверкой.
Онлайн-оценка
Офлайн-набор не покрывает всего. В проде:
- Явные сигналы: лайки и дизлайки, оценки, жалобы.
- Неявные: переформулировал ли пользователь вопрос, скопировал ли ответ, перешёл ли к оператору, вернулся ли.
- A/B-тест: часть трафика получает новую версию, сравниваем продуктовые метрики (доля решённых обращений, конверсия) с заранее выбранной главной метрикой и метриками-ограничителями (стоимость, задержка, жалобы). Важно заранее посчитать нужный размер выборки и не подглядывать с досрочной остановкой.
Подводные камни
- Сравнивать версии на разных наборах или с разными настройками температуры.
- Смотреть только на среднее: новая версия может выиграть в среднем и провалиться на важной категории.
- Не учитывать дисперсию: при ненулевой температуре прогоняйте несколько раз или фиксируйте температуру 0.
- Утечка тестовых данных в промпт или в обучение.
Что спросят на собесе
- Как собрать оценочный набор, если разметки нет.
- Recall@k, MRR и nDCG: определения и когда какая.
- Почему BLEU и ROUGE плохи для чат-ответов.
- LLM-as-judge: искажения и как калибровать судью.
- Как провести A/B новой версии промпта или модели.