Глава 5.5 — Оценка

Содержание

1. Вопрос, от которого зависят утверждения всех предыдущих глав
2. Почему оценка — наиболее слабо проработанная часть конвейера
3. Наборы бенчмарков и что на самом деле измеряет MMLU
4. Два способа, которыми бенчмарки незаметно перестают означать то, что означали раньше
5. LLM-как-судья: масштабирование оценки за пределы человеческих оценщиков
6. Честный вывод: ни одна цифра сама по себе не заслуживает доверия
7. Взгляд с точки зрения интервью
8. Вопросы для самопроверки
9. Источники

1. Вопрос, от которого зависят утверждения всех предыдущих глав

Каждая глава этой части книги утверждала, что та или иная способность улучшилась: рассуждение стало лучше благодаря вычислениям на этапе инференса, извлечение информации снизило галлюцинации, мультимодальные архитектуры позволили моделям воспринимать изображения, агентные циклы позволили моделям действовать в мире. Каждое из этих утверждений опирается на какой-то способ измерить, реально ли это улучшение: выросла оценка на бенчмарке, увеличилась доля успешного выполнения задачи, человек или автоматизированный судья предпочёл вывод одной модели выводу другой. Эта глава посвящена именно этому измерительному слою, и она заслуживает отдельной главы, а не абзаца, добавленного к каждой главе о способностях, потому что оценка оказывается на удивление слабым звеном относительно изощрённости всего того, что ей поручено проверять.

2. Почему оценка — наиболее слабо проработанная часть конвейера

Стоит сказать прямо, потому что это легко упустить из виду: главы об архитектурах описывают тщательно выстроенные математические объекты с чётко определённой механикой, главы об обучении описывают процедуры оптимизации с точными функциями потерь и свойствами сходимости, а затем, в самом конце конвейера, вопрос о том, сработало ли всё это на самом деле, зачастую решается числом точности на бенчмарке, показателем попарных предпочтений или местом в рейтинге — измерительными инструментами, которые относительно строгости остального конвейера сравнительно грубы. Это не критика какого-то конкретного метода оценки, а скорее наблюдение о природе проблемы: измерить «насколько хорош вывод этой модели» принципиально труднее точно специфицировать, чем «снизились ли потери при обучении», потому что для большинства интересных задач нет единой, недвусмысленной истины, как это есть для цели предсказания следующего токена. У математической задачи может быть единственный правильный финальный ответ, но у открытой генерации — резюме, объяснения, общей траектории многошаговой агентной задачи — часто вообще нет одного канонического «правильного» вывода, только диапазон более удачных и менее удачных вариантов, и точная спецификация понятия «лучше» сама по себе является нерешённой измерительной проблемой.

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

3. Наборы бенчмарков и что на самом деле измеряет MMLU

Hendrycks и др. (2020) представили MMLU (Massive Multitask Language Understanding) как попытку измерить широкие знания и способность к рассуждению по огромному диапазону академических и профессиональных предметов — от элементарной математики до права и профессиональной медицины — с использованием вопросов с несколькими вариантами ответа, взятых из реальных экзаменов и учебников. Привлекательность такого формата — именно в его простоте: вопросы с несколькими вариантами ответа имеют однозначный правильный ответ, тривиально оцениваются автоматически и легко масштабируются на десятки предметов и тысячи вопросов при сравнительно небольших затратах на разметку, поскольку «метки» уже существуют в исходных экзаменах. MMLU быстро стал одним из стандартных заглавных показателей, приводимых для любой новой передовой модели, именно потому что его дёшево прогонять и он даёт единственное, сопоставимое во времени и между моделями скалярное число.

Стоит точно понимать, как именно оценивается ответ на вопрос, поскольку это вовсе не свободная генерация: модель не просят написать «A», «B», «C» или «D», а затем распарсить результат. Вместо этого стандартный харнесс оценки подаёт модели вопрос и все четыре варианта ответа как контекст, а затем считывает собственные вероятности модели для следующего токена, ограниченные лишь горсткой токенов, соответствующих буквам вариантов (либо, в некоторых харнессах, вероятности целых вариантов ответа, оцененных как продолжение), и выбирает тот, которому модель приписала наибольшую вероятность. Это ровно тот же самый механизм, который вся остальная книга называет базовой компетенцией языковой модели, — распределение вероятностей по следующему токену, — просто считанное в одной-единственной позиции и сравненное между четырьмя кандидатами, а не сэмплированное из него; ничто в этом не требует, чтобы модель реально порождала текст.

Но важно точно понимать, что такой бенчмарк на самом деле измеряет, а что нет. Высокий балл MMLU показывает, что модель способна выбрать правильный ответ среди небольшого набора вариантов по широкому кругу фактических и близких к рассуждению вопросов; он сравнительно мало говорит о качестве открытой генерации, о поведении модели в многоходовом диалоге, о её надёжности при выполнении долгосрочных агентных задач (глава 5.4) или о калибровке — модель может быть чрезвычайно хороша в распознавании правильного ответа среди нескольких вариантов и при этом оставаться ненадёжной при порождении того же знания без подсказки, в свободном тексте, без костыля в виде правильного варианта, лежащего прямо среди четырёх альтернатив для сравнения. У формата с несколькими вариантами ответа есть и специфический, хорошо известный артефакт: модель иногда может выбрать правильный ответ методом исключения или поверхностного сопоставления шаблонов между вопросом и вариантами ответа, не обладая тем самым рассуждением, которое призван проверить вопрос, что дополнительно сужает то, что реально удостоверяет высокий балл.

Пробел, который MMLU оставляет открытым, — надёжность агентности и трудное, многошаговое рассуждение — это ровно то, что призван измерять отдельный, более новый класс бенчмарков, и его стоит назвать отдельной категорией, а не считать «бенчмарк» синонимом теста знаний с несколькими вариантами ответа. SWE-bench оценивает способность модели действовать как агент для написания кода (глава 5.4) на реальных, неотредактированных issue из GitHub: имея настоящий репозиторий и реальный баг-репорт или запрос на новую функцию, взятые из его истории, модель должна произвести патч кода, который независимо проверяется по собственному реальному набору тестов этого репозитория, — что делает задачу долгосрочной, открытой и оцениваемой по подлинной функциональной корректности, а не по единственному выбору из вариантов ответа. GPQA (Graduate-Level Google-Proof Q&A) вместо этого нацелен на «трудную» половину пробела — рассуждение: его вопросы написаны и проверены экспертами в предметной области специально так, чтобы противостоять правильному ответу от того (или того, что), кто просто просматривает результаты поиска или сопоставляет поверхностные признаки, — стремясь изолировать подлинное экспертное рассуждение в узкой области от того рода широкого, но поверхностного фактического вспоминания, которое в основном и вознаграждает MMLU. Оба бенчмарка — прямой ответ на ту же самую лежащую в основе критику, к которой вёл этот раздел: формат бенчмарка должен реально задействовать ту способность, которую вы хотите измерить, а ни надёжность долгосрочной агентности, ни по-настоящему трудное экспертное рассуждение хорошо не задействуются вопросом с четырьмя вариантами ответа, сколь бы сложно ни звучала тема этого вопроса.

4. Два способа, которыми бенчмарки незаметно перестают означать то, что означали раньше

Помимо ограничений, специфичных для формата, статические бенчмарки вроде MMLU со временем деградируют двумя связанными, но различными способами, которые строгому практику необходимо уметь называть по отдельности. Первый — насыщение бенчмарка (benchmark saturation): по мере улучшения моделей они приближаются к потолку бенчмарка — как только большинство передовых моделей набирают низкие-средние 90-е баллы на бенчмарке с максимумом 100, бенчмарк перестаёт значимо различать модели разного качества, потому что почти не остаётся запаса, чтобы отличить действительно лучшую модель от чуть лучшей или даже статистически неразличимой с учётом шума измерений. Полезность бенчмарка для ранжирования моделей напрямую связана с тем, сколько его динамического диапазона ещё не использовано; после насыщения продолжение представлять его как заглавную метрику создаёт ложное ощущение, что прогресс всё ещё чисто измеряется, тогда как на самом деле у метрики закончился запас, чтобы показать значимую разницу.

Вторая, более коварная проблема — контаминация данных (data contamination): поскольку вопросы этих бенчмарков (а часто и ответы) существуют где-то в открытом интернете — исходные экзамены, форумы, где их разбирают, другие работы, дословно цитирующие вопросы бенчмарков, — а обучающие корпуса собираются путём скрапинга огромных участков веба (об этом говорилось при обсуждении данных для предобучения в части IV), вполне возможно, что вопросы бенчмарка или их близкие перефразировки просачиваются напрямую в обучающие данные модели. Модель, которая, по сути, запомнила ответ на вопрос бенчмарка во время предобучения, наберёт по этому вопросу высокий балл не потому, что рассуждениями пришла к ответу, а потому, что вспоминает нечто ближе к заученному факту, — а это значит, что балл бенчмарка больше не отражает ту базовую способность, которую он был призван измерить, и сравнения между моделями с разными (и часто нераскрытыми) обучающими данными становятся ненадёжными способами, которые трудно обнаружить со стороны.

Golchin и Surdeanu (2023) стоит знать как конкретный пример того, как область активно борется с этой проблемой, а не игнорирует её: их подход к обнаружению контаминации проверяет, способна ли модель дословно завершить формулировку экземпляра бенчмарка (или воспроизвести его характерные поверхностные детали) способом, который был бы неправдоподобен, если бы модель не видела именно этот экземпляр или что-то очень близкое к нему во время обучения, — по сути, тестируя на подозрительно точное запоминание текста, специфичного для бенчмарка, а не на обобщаемую компетентность в задаче. Само существование целого направления исследований, посвящённого обнаружению контаминации, и есть важный вывод: это сигнализирует, что область признаёт — статические, собранные из веба бенчмарки несут внутренний, трудноустранимый до конца риск измерять запоминание, а не способность, и что к любому отдельному баллу бенчмарка стоит относиться с некоторым скептицизмом, если контаминация не была активно проверена.

5. LLM-как-судья: масштабирование оценки за пределы человеческих оценщиков

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

Zheng и др. (2023) предложили и валидировали LLM-как-судью (LLM-as-judge) как масштабируемую замену: вместо человека-оценщика используется сильная LLM для оценки или сравнения выводов моделей — либо оценивая один ответ по рубрике, либо сравнивая два ответа лицом к лицу и высказывая предпочтение. Их работа представила MT-Bench — набор сложных, открытых многоходовых вопросов, призванных проверить способность к диалогу и следованию инструкциям способами, недоступными бенчмаркам с несколькими вариантами ответа, оцениваемых через суждение LLM, — и Chatbot Arena, живую, краудсорсинговую систему попарных сравнений, где реальные пользователи взаимодействуют с двумя анонимизированными моделями бок о бок и голосуют за то, какой ответ они предпочитают, порождая рейтинг в стиле Эло по множеству моделей. Их центральная эмпирическая валидация состоит в том, что предпочтения сильного LLM-судьи хорошо коррелируют с предпочтениями людей на этих открытых задачах, а значит LLM-как-судья может служить достаточно верным, но при этом гораздо более масштабируемым заменителем того тонкого сравнительного суждения, которое раньше требовало человека-оценщика на каждой итерации.

Эта валидация сопровождается важными, хорошо задокументированными оговорками, которые опытный инженер должен уметь сформулировать точно, а не проглатывать. Наиболее часто упоминаемая — предвзятость к самому себе (self-preference bias): LLM-судья склонен оценивать выводы, порождённые похожими на него самого моделями (или им самим), более благосклонно, чем действительно эквивалентные выводы другой модели, что смещает сравнения в пользу «семейства» судьи. Другая — позиционная предвзятость (position bias): в попарных сравнениях предпочтение модели-судьи может зависеть от того, какой ответ представлен первым, а какой вторым, независимо от реального качества, из-за чего аккуратные протоколы LLM-как-судьи прогоняют сравнения в обоих порядках и проверяют согласованность. Есть и общий риск того, что LLM-судья, как и любая модель, может быть обманут беглым, уверенным, хорошо отформатированным текстом, который по существу неверен или поверхностен, вознаграждая стиль вместо корректности так, как не сделал бы эксперт-человек в предметной области. Ни одна из этих оговорок не означает, что LLM-как-судья бесполезен — валидация Zheng и др. по корреляции с человеческими предпочтениями реальна, — но они означают, что этот подход стоит применять с явным протоколом смягчения предвзятостей (рандомизация порядка, разнообразие судей, выборочная сверка с человеческими оценщиками), а не воспринимать как неоспоримую истину только потому, что он хорошо масштабируется.

6. Честный вывод: ни одна цифра сама по себе не заслуживает доверия

Собирая всё воедино, честный вывод на уровне практика состоит в том, что ни одна отдельная метрика оценки — ни насыщенный бенчмарк с несколькими вариантами ответа, ни показатель предпочтений LLM-судьи, ни изолированная метрика продакшн-A/B-теста — не должна восприниматься как самодостаточное подтверждение того, что модель или система хороша. Строгая стратегия оценки реальной системы сочетает несколько несовершенных, по-разному смещённых сигналов: статические бенчмарки (проверенные на контаминацию и воспринимаемые с должным скептицизмом по мере приближения к насыщению) — для широкого, дёшево измеряемого охвата знаний и рассуждения; оценку LLM-как-судья (с явным смягчением предвзятостей) — для масштабируемой оценки качества открытой генерации в ходе итеративной разработки; целевую оценку людьми, особенно экспертами в предметной области, — для наиболее рискованных или наиболее тонких суждений, которым автоматизированные методы доверяют меньше всего; и продакшн-метрики — реальное поведение пользователей, выполнение задач, деловые результаты в дальнейшем — как окончательного арбитра того, действительно ли система полезна, поскольку ни один из вышестоящих суррогатов не предсказывает реальную ценность идеально. Дисциплина, которую это требует, состоит в том, чтобы держать все эти сигналы в уме одновременно и оставаться скептичным к любому из них по отдельности, особенно к одиночному числу в рейтинге, приведённому без оговорок, а не воспринимать растущий балл бенчмарка как самоочевидное свидетельство того, что модель стала лучше в том смысле, который действительно важен.

Этим завершается материал о передовых способностях в этой части книги. Главы 5.1–5.5 последовательно рассмотрели: как модель можно заставить думать дольше и эффективнее на этапе инференса, как её можно снабдить доступом к внешнему и актуальному знанию, как её можно расширить для восприятия модальностей помимо текста, как её можно превратить в нечто, действующее в мире через инструменты, и, наконец, как — и насколько несовершенно — любое из этих заявленных улучшений на самом деле измеряется. Но архитектура, обучение и эти передовые способности на данный момент всё ещё остаются отдельными кусками понимания; ничто из этого само по себе не описывает, как на самом деле собрать из них работающий продукт в условиях реальных ограничений по задержке, стоимости и надёжности и честно оценить получившуюся систему от начала до конца. Прежде чем переходить к этой сборке, остаётся закрыть ещё один пробел: сколь бы способной ни была модель, окружающая система может опираться на её вывод только тогда, когда этот вывод надёжно принимает форму, которую система способна разобрать, — этому посвящена следующая глава. А сама задача сборки — замыкание цикла между всем, что охватила эта книга, — это то, к чему книга обращается уже после неё.

7. Взгляд с точки зрения интервью

Вопрос: Новая модель показывает балл выше, чем у действующей, на MMLU. Достаточно ли этого, чтобы заменить действующую модель в продакшне? Сильный ответ говорит «нет» и объясняет это по двум отдельным основаниям: формат MMLU с несколькими вариантами ответа измеряет узкий срез способностей (распознавание среди вариантов, а не открытую генерацию, надёжность в диалоге или выполнение агентных задач), а сам балл может отражать контаминацию данных, а не подлинное улучшение, если он не проверен на контаминацию. Ответ должен завершиться тем, что реально оправдало бы замену — сочетанием бенчмаркинга с учётом контаминации, LLM-как-судья или человеческой оценки на задачах, представительных для реального продакшн-сценария использования, и в идеале живым A/B-тестом на реальном трафике.

Вопрос: Как бы вы определили, был ли бенчмарк, на который вы полагаетесь, контаминирован обучающими данными модели? Сильный ответ описывает подход в стиле Golchin и Surdeanu на концептуальном уровне: проверить, способна ли модель воспроизвести характерные, дословные или иначе неправдоподобно точные детали конкретных экземпляров бенчмарка (точная формулировка, необычная фразировка, конкретные варианты-отвлекатели) способом, который был бы крайне маловероятен, если бы модель не запомнила именно этот экземпляр, в отличие от обобщаемой компетентности в базовом типе задачи.

Вопрос: В чём разница между насыщением бенчмарка и контаминацией данных и почему их нужно называть двумя отдельными проблемами? Сильный ответ чётко формулирует, что насыщение — проблема диапазона/различимости: большинство сильных моделей скапливаются у потолка, и бенчмарк перестаёт значимо их различать, — тогда как контаминация — проблема валидности: балл вообще перестаёт измерять предполагаемую способность, поскольку может отражать запоминание. Балл модели на бенчмарке может быть неразличающим из-за насыщения даже без всякой контаминации, а может быть контаминирован даже на бенчмарке, далёком от насыщения; смешение этих двух ведёт к неверной диагностике того, почему метрика перестала быть полезной.

Вопрос: Каковы известные сбои использования LLM в качестве судьи и как бы вы смягчали их в реальном конвейере оценки? Сильный ответ конкретно называет предвзятость к самому себе (судья благоприятствует выводам похожих на него самого или идентичных ему моделей) и позиционную предвзятость (чувствительность к порядку представления в попарных сравнениях), а также описывает конкретные меры смягчения: рандомизацию или уравновешивание порядка ответов, использование модели-судьи из другого семейства, чем оцениваемые модели, где это возможно, и периодическую сверку предпочтений судьи с меньшим набором человеческих оценок, чтобы проверить, что корреляция, зафиксированная Zheng и др., по-прежнему сохраняется для вашего конкретного распределения задач.

Вопрос: Если бы вам нужно было с нуля разработать стратегию оценки для новой продакшн-функции на базе LLM, как бы она выглядела? Сильный ответ выстраивает многоуровневый подход: широкие, дешёвые, проверенные на контаминацию статические бенчмарки — для базовой проверки на здравый смысл; LLM-как-судья со смягчением предвзятостей — для быстрой итерации по качеству открытой генерации в ходе разработки; целевая оценка людьми, особенно для наиболее рискованных выводов или предметно-специфической корректности, которым автоматизированные судьи доверяют меньше всего; и продакшн-метрики из реального использования — как окончательный, наиболее надёжный сигнал, — явно оговаривая, что ни один из них не должен быть единственным основанием для решения о запуске.

8. Вопросы для самопроверки

1. Почему справедливо сказать, что оценка сравнительно менее проработана инженерно, чем предшествующий ей конвейер обучения и архитектуры?
2. Что конкретно демонстрирует высокий балл MMLU о модели, а что явно не демонстрирует?
3. Дайте отдельные определения насыщения бенчмарка и контаминации данных и объясните, почему они требуют разных диагностических подходов.
4. Опишите своими словами, как проверка контаминации в стиле Golchin и Surdeanu отличает запоминание от подлинной компетентности в задаче.
5. Что на самом деле валидировали работы Zheng и др. по MT-Bench и Chatbot Arena в отношении LLM-как-судьи и какие конкретные предвзятости эта валидация не устраняет?
6. Почему рандомизация порядка ответов в попарном сравнении LLM-как-судья важна для надёжности результата?
7. Почему глава заключает, что ни один сигнал оценки не должен восприниматься изолированно с полным доверием, и какие четыре категории сигналов сочетает строгая стратегия?

9. Источники

• Hendrycks, D., Burns, C., Basart, S., et al. (2020). Measuring Massive Multitask Language Understanding (MMLU). ICLR 2021. arXiv:2009.03300. https://arxiv.org/abs/2009.03300
• Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. arXiv:2306.05685. https://arxiv.org/abs/2306.05685
• Golchin, S., & Surdeanu, M. (2023). Time Travel in LLMs: Tracing Data Contamination in Large Language Models. arXiv:2308.08493. https://arxiv.org/abs/2308.08493
• Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., & Narasimhan, K. (2023). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024. arXiv:2310.06770. https://arxiv.org/abs/2310.06770
• Rein, D., Hou, B. L., Stickland, A. C., et al. (2023). GPQA: A Graduate-Level Google-Proof Q&A Benchmark. arXiv:2311.12022. https://arxiv.org/abs/2311.12022