Как измерить то, чего нет.
у задачи сложения есть правильный ответ. у задачи «напиши хорошее письмо» — нет. оценка LLM — это проблема измерения качества, когда качество субъективно, многомерно и контекстуально.
| тема | оценка LLM · метрики качества · эксперименты |
| читать | ~8 минут |
| связано | A/B тестирование · байесовский вывод · аукционы |
У задачи сложения есть правильный ответ. 2 + 2 = 4. Модель ответила 4 — правильно. 5 — неправильно. Это автоматическая оценка. Легко масштабировать. У задачи «объясни квантовую механику пятилетнему ребёнку» нет единственного правильного ответа. Один ответ точнее. Другой понятнее. Третий короче. Какой лучше — зависит от цели. Это фундаментальная проблема оценки LLM.
BLEU (2002) — насколько n-граммы совпадают с эталоном1. ROUGE — для суммаризации. F1 по токенам — для QA. Проблема: метрики коррелируют с качеством на простых задачах и перестают работать на сложных. Модель может получить высокий BLEU, написав шаблонный ответ. Модель может получить низкий BLEU, написав лучший ответ — другими словами.
Люди оценивают ответы: 1–5, попарное сравнение, аннотация ошибок. Дорого. Медленно. Не воспроизводимо. Inter-annotator agreement (IAA) — мера согласия аннотаторов: каппа Коэна, альфа Криппендорфа4. Если аннотаторы не согласны друг с другом — непонятно, чему учить модель.
Попарное сравнение лучше абсолютных оценок. «A лучше B» надёжнее, чем «A = 4». Рейтинговые системы: Elo (из шахмат), Bradley–Terry модель. LMSYS Chatbot Arena — тысячи пользователей сравнивают модели2. Проблема: coverage bias. Люди задают удобные задачи. Трудные edge-cases недопредставлены.
Не всё, что измеримо, важно. Не всё, что важно, измеримо. — приписывается Эйнштейну (реально — Уильям Брюс Кэмерон, 1963)
Использовать сильную модель для оценки слабой. GPT-4 оценивает ответы GPT-3.5. Быстро. Дёшево. Масштабируемо. Проблемы3:
- position bias — модель предпочитает первый ответ;
- verbosity bias — длинные ответы кажутся лучше;
- self-enhancement bias — модель предпочитает свои ответы;
- calibration — насколько оценки судьи коррелируют с human eval?
Это измеримо. Meta-evaluation: сравнить LLM-judge с human judge — correlation, rank correlation (Spearman), agreement rate. Хороший LLM-judge воспроизводит human eval на 80–85%.
Для продуктовых фич специфика другая. Не «какая модель лучше», а «эта фича помогает пользователю?». Proxy-метрики: completion rate, edit distance после генерации, time-to-action, user rating (thumbs up/down). Проблема суррогатных метрик: оптимизируешь прокси — теряешь цель. Модель научилась генерировать короткие ответы — completion rate вырос, качество упало.
Офлайн: бенчмарки, фиксированные датасеты. Воспроизводимо. Быстро. Онлайн: A/B-тест с реальными пользователями. Медленно. Дорого. Истинно. Разрыв между офлайн и онлайн — постоянная проблема. Модель побеждает на бенчмарке — проигрывает в проде.
- определить задачу чётко: что значит «хорошо» для этой фичи;
- собрать evaluation set из реальных пользовательских запросов (не синтетических);
- установить baseline — текущая модель, правило или human performance;
- выбрать метрики: автоматические + человеческая валидация подмножества;
- измерить inter-annotator agreement; если < 0.6 — задача не определена;
- LLM-judge как ускоритель — но валидировать на human eval регулярно;
- онлайн-эксперимент как финальный арбитр.
Нет идеального способа оценить LLM. Есть набор несовершенных инструментов. Задача — комбинировать их так, чтобы решение было лучше, чем каждый по отдельности. Это и есть измерение того, чего нет.