Зачем оценивать качество LLM?
Оценка качества LLM нужна, чтобы объективно понять, действительно ли модель стала лучше после обучения или доработки, и безопасна ли она для реальных пользователей — без такой проверки решение о запуске принимается «на глаз». Отдельная оценка также помогает найти, в каких сценариях модель ошибается чаще всего, и решить, какие данные добавить на следующей итерации.
Тестировать модель важно не только перед первым запуском, но и после каждого значимого изменения — обновления промпта, дообучения или смены версии базовой модели: даже небольшая правка может улучшить одни сценарии и незаметно ухудшить другие. Особенно это критично для моделей с доступом к внешним инструментам или данным пользователей: цена необнаруженной ошибки там значительно выше, чем в обычном чат-боте без доступа к действиям.
Что такое бенчмарки для оценки LLM?
Бенчмарки — это стандартизированные наборы задач и вопросов с заранее известным правильным ответом, на которых автоматически измеряют точность модели: от общих знаний и логики до кода и математики. Они дают быстрый и воспроизводимый сигнал для сравнения версий модели между собой, но плохо отражают качество в узком домене или живом диалоге.
Публичные бенчмарки удобны для сравнения базовых моделей между собой, но для прикладной задачи — техподдержки, юридических документов, медицинских консультаций — почти всегда нужен собственный набор тестовых вопросов, отражающий реальные сценарии использования модели. Кроме того, результаты на популярных публичных бенчмарках со временем становятся менее показательными: часть таких вопросов попадает в обучающие корпуса новых моделей, поэтому высокий балл не всегда означает реальное умение решать задачу, а не узнавание знакомого примера.
Что такое human evaluation и LLM-as-judge?
Human evaluation — это оценка ответов модели живыми людьми по заранее согласованным рубрикам: полезность, точность, безопасность, стиль. LLM-as-judge — более быстрый и дешёвый вариант, где роль оценщика частично берёт на себя другая модель; результат обычно перепроверяют людьми на выборке и в спорных случаях, чтобы не унаследовать ошибки модели-судьи.
На практике эти два подхода комбинируют: LLM-as-judge закрывает основной объём типовых сравнений, а люди — сложные, чувствительные и специализированные случаи, где цена ошибки высока. Такой баланс масштабирует оценку без потери качества там, где это критично. Полезная практика — фиксировать не только итоговую оценку, но и краткое обоснование, почему ответ получил именно такой балл: это упрощает разбор спорных случаев и калибровку рубрики между разными оценщиками.
Что такое red teaming языковой модели?
Red teaming — это целенаправленный поиск уязвимостей модели: провокационных запросов, попыток обойти ограничения (джейлбрейков), утечки чувствительных данных и предвзятых ответов. Команда экспертов имитирует злоумышленника и тестирует модель adversarial-сценариями, а найденные проблемы классифицируют по критичности перед передачей разработчикам.
В отличие от бенчмарков, red teaming не измеряет общую точность, а целенаправленно ищет худшие случаи поведения модели — те самые единичные, но опасные ответы, которые редко всплывают при обычном тестировании, но дорого обходятся в продакшене. Сильный red teaming строится не только на типовых атаках, известных по другим моделям, но и на сценариях, специфичных для домена заказчика — например, попытках выманить конфиденциальные данные клиента через окольные формулировки запроса.
Какие метрики используют при оценке LLM?
В отчёт по оценке LLM обычно включают win-rate в парных сравнениях с предыдущей версией, долю фактических ошибок по факт-чеку, оценку безопасности по категориям риска и согласованность экспертов между собой (IAA). Числовые метрики позволяют увидеть измеримую динамику качества между версиями модели, а не только общее впечатление.
| Метрика | Что показывает |
|---|---|
| Win-rate | Доля вопросов, где новая версия ответила лучше базовой |
| Доля фактических ошибок | Процент ответов с недостоверными утверждениями |
| Оценка безопасности | Доля ответов с нарушением политики по категориям риска |
| Согласованность экспертов (IAA) | Насколько независимые оценщики сходятся в оценке одного ответа |
Помимо перечисленных метрик, отдельно отслеживают долю отказов модели отвечать (refusal rate): слишком высокое значение означает, что модель излишне осторожна и теряет полезность на безобидных запросах, а слишком низкое — что порог безопасности занижен и часть рискованных запросов проходит без отказа.
Какую роль играет человеческая разметка в оценке LLM?
Человеческая разметка остаётся опорной точкой оценки LLM: именно люди задают рубрики, по которым потом судят автоматические метрики и модели-судьи, и именно люди проверяют спорные и высокорисковые случаи, где ошибка автоматики недопустима. Без калибровки на человеческих оценках любая автоматическая метрика со временем расходится с реальным качеством ответов.
Похожая логика лежит в основе RLHF — метода, где человеческие оценки ответов напрямую используются для обучения модели, а не только для контроля качества после. Подробнее о том, как это устроено, — в статье «RLHF: что это простыми словами», а о том, какие данные вообще нужны на разных этапах обучения LLM — в материале «Какие данные нужны для обучения LLM».