Афшин и Шервин об эволюции оценки LLM: от человеческой разметки до агентов-симуляторов

Стэндфордский курс CME295 продолжает погружение в мир больших языковых моделей, посвящая восьмую лекцию критически важной теме — оценке (evaluation) качества ответов LLM. Лекторы Афшин (Afshine) и Шервин (Shervine) подробно разбирают методы измерения производительности: от классических программных метрик и человеческой разметки до современных подходов «LLM-как-судья» (LLM-as-a-Judge) и специализированных бенчмарков для ИИ-агентов.

🎯 Проблема субъективности и человеческая разметка 4:40

Оценка LLM — сложная задача, так как эти модели генерируют текст в свободной форме: от естественного языка до математических доказательств и программного кода . Афшин отмечает, что идеальным сценарием была бы оценка каждого ответа человеком, но это крайне дорого и медленно .

Главной проблемой человеческой оценки является субъективность. Афшин приводит пример: если спросить LLM о подарке на день рождения и получить ответ «Плюшевый мишка — это всегда мило», один разметчик сочтет это полезным, а другой — нет, так как не указаны детали . Для решения этой проблемы используются метрики согласия разметчиков:

• Agreement Rate: простая доля случаев, когда два разметчика дали одинаковый балл .
• Коэффициент каппа Коэна (Cohen's kappa): более продвинутая метрика, которая учитывает вероятность случайного совпадения ответов .
• Альфа Криппендорфа и каппа Флейса: расширения для случаев, когда разметчиков больше двух .

По словам Афшина, если уровень согласия низкий, компании проводят «сессии выравнивания» (agreement sessions), чтобы уточнить инструкции для разметчиков и сделать оценки последовательными .

📏 Программные метрики: BLEU, METEOR и ROUGE 19:04

Чтобы избежать постоянных трат на людей, используются метрики на основе правил, которые сравнивают ответ модели с «эталоном» (reference), написанным экспертом .

Основные инструменты:

• METEOR: метрика для оценки перевода, учитывающая порядок слов и штрафующая за его нарушение . Она включает параметры точности (precision) и полноты (recall), а также использует гиперпараметры для настройки веса штрафов .
• BLEU (Bilingual Evaluation Understudy): популярная в машинном переводе метрика, сфокусированная на точности совпадения n-грамм . Она включает штраф за краткость (brevity penalty), чтобы модели не получали высокие баллы за слишком короткие, но точные обрывки фраз .
• ROUGE: набор метрик, чаще используемый для задач суммаризации (краткого изложения текста) .

Афшин утверждает, что у этих методов есть два фундаментальных недостатка: они не допускают стилистических вариаций (синонимы часто игнорируются) и плохо коррелируют с реальным человеческим восприятием качества .

⚖️ LLM-as-a-Judge: модель оценивает модель 28:16

Современным стандартом становится использование мощной модели (например, GPT-4o) для оценки ответов более слабых моделей. Этот подход называется LLM-as-a-Judge .

Ключевые особенности метода:

1. Наличие обоснования (Rationale): в отличие от формул, LLM может сначала написать текст с объяснением, почему ответ хорош или плох, а только потом поставить оценку .
2. Цепочка рассуждений: требование сначала выдать обоснование, а затем балл — это трюк, который эмпирически улучшает качество самой оценки, аналогично технике Chain of Thought .
3. Структурированный вывод: для автоматизации парсинга результатов Афшин рекомендует использовать режим Structured Outputs (в API OpenAI или Gemini), передавая JSON-схему с полями rationale и score .

Существует две основные схемы судейства: Pointwise (оценка одного ответа по шкале) и Pairwise (сравнение двух ответов — какой лучше) .

Критические ошибки «судейских» моделей 38:40

Афшин выделяет три типа когнитивных искажений, которым подвержены LLM-судьи:

• Position Bias (ошибка позиции): в парных сравнениях модели склонны выбирать первый вариант просто потому, что он идет первым. Решение — менять варианты местами и проводить повторную оценку .
• Verbosity Bias (ошибка многословия): модели предпочитают более длинные и детальные ответы, даже если они содержат меньше сути. Решение — жесткие инструкции в промпте и штрафы за длину .
• Self-enhancement Bias (самовлюбленность): модель склонна ставить более высокие баллы текстам, стиль которых похож на её собственный. Поэтому Афшин рекомендует не использовать для оценки ту же модель, которая генерировала ответ .

🔍 Оценка фактологичности (Factuality) 54:06

Фактологичность нельзя оценивать бинарно («да/нет»), так как в тексте может быть пять верных утверждений и одно ложное. Афшин описывает современный многоступенчатый процесс оценки :

1. Извлечение атомарных фактов: LLM разбивает длинный ответ на список отдельных утверждений .
2. Проверка каждого факта: каждое утверждение проверяется через RAG (поиск по базе знаний) или веб-поиск .
3. Взвешенная агрегация: каждому факту присваивается вес важности ($\alpha_i$). Например, ошибка в дате рождения президента важнее, чем ошибка в цвете его галстука. Итоговый балл рассчитывается как средневзвешенное .

🤖 Оценка ИИ-агентов и инструментов (Tool Use) 1:00:11

Шервин (Shervine) переходит к специфике оценки агентов, работающих в цикле Observe-Plan-Act . Здесь ошибки могут возникать на каждом этапе вызова инструментов.

Типичные режимы отказа (failure modes):

• Punt (отказ): модель имеет нужный инструмент, но не использует его, отвечая «Я не знаю». Часто это ошибка «роутера» инструментов, который не включил нужную функцию в контекст .
• Tool Hallucination: модель пытается вызвать функцию, которой не существует (например, find_bear вместо find_teddy_bear). Шервин считает это признаком либо слишком слабой модели, либо плохо написанной документации API .
• Неверные аргументы: модель вызывает правильный инструмент, но с абсурдными параметрами (например, координаты 0,0 для поиска места рядом с пользователем) .
• Ошибки синтеза: инструмент вернул верные данные (например, «медведь найден в 1 миле»), но модель в финальном ответе говорит: «Я ничего не нашла». Это происходит, когда вывод инструмента слишком зашумлен лишней информацией .

Шервин дает важный совет разработчикам: всегда возвращайте пустой JSON {}, если инструмент не нашел результатов, вместо значения None. Для модели пустой объект — это содержательный сигнал об отсутствии данных, а None может быть интерпретирован как системная ошибка .

📊 Глобальные бенчмарки: что они измеряют? 1:23:30

Шервин разбирает основные категории тестов, которые мы видим в отчетах OpenAI, Google и Anthropic.

🧠 Знания и рассуждения

• MMLU (Massive Multitask Language Understanding): 57 задач в разных областях (медицина, право, история). Это тест на «эрудицию», полученную во время предобучения .
• AIME (American Invitational Mathematics Examination): сложнейшие задачи математических олимпиад. Тестирует способность к длительному рассуждению (Chain of Thought) .
• PIQA (Physical Interaction QA): проверка «здравого смысла» в физическом мире (например, как достать упавшую вещь из-под шкафа) .

💻 Код и агенты

• SWE-bench: оценка способности модели решать реальные GitHub-issue. Модели выдают патч (код), который затем проверяется автоматическими тестами .
• tau-bench: бенчмарк для агентов в сфере ритейла и авиаперевозок. Здесь оценивается не просто ответ, а изменение состояния базы данных после действий агента . Шервин упоминает метрику pass^k — вероятность того, что все k попыток агента будут успешными, что критично для надежности бизнеса .

🛡️ Безопасность

• HarmBench: тест на генерацию вредоносного контента, нарушение авторских прав и токсичность . Оценка здесь часто проводится отдельным классификатором, так как ответы могут быть открытыми .

📈 Прагматичный подход к выбору моделей 1:46:14

В завершение лекции Шервин отмечает, что ни один бенчмарк не дает полной картины. Он вводит понятие Парето-фронтира (Pareto Frontier): зависимости качества от цены и скорости .

Его личные рекомендации:

• Claude 3.5 Sonnet: лучший выбор для написания кода .
• Gemini Flash: оптимальна, когда нужны скорость и низкая стоимость .

Лекторы предупреждают о «законе Гудхарта»: как только метрика становится целью, она перестает быть хорошей метрикой . Модели могут быть переобучены под бенчмарки (data contamination), поэтому лучшим тестом всегда остается проверка на собственных специфических данных проекта .