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

Источник: https://www.youtube.com/watch?v=8fNP4N46RRo
Канал: Stanford Online
Опубликовано: 02.12.2025

---

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

## 🎯 Проблема субъективности и человеческая разметка
[[JUMP:04:40]]

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

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

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

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

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

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

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

*   **METEOR:** метрика для оценки перевода, учитывающая порядок слов и штрафующая за его нарушение [21:06]. Она включает параметры точности (precision) и полноты (recall), а также использует гиперпараметры для настройки веса штрафов [22:02].
*   **BLEU (Bilingual Evaluation Understudy):** популярная в машинном переводе метрика, сфокусированная на точности совпадения n-грамм [25:20]. Она включает штраф за краткость (brevity penalty), чтобы модели не получали высокие баллы за слишком короткие, но точные обрывки фраз [25:52].
*   **ROUGE:** набор метрик, чаще используемый для задач суммаризации (краткого изложения текста) [26:23].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### 💻 Код и агенты

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

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

*   **HarmBench:** тест на генерацию вредоносного контента, нарушение авторских прав и токсичность [1:38:09]. Оценка здесь часто проводится отдельным классификатором, так как ответы могут быть открытыми [1:40:16].

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

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

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

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

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