Человек и LLM: как построить метрики для оценки моделей

Привет, меня зовут Ирина Барская, и я руководитель службы аналитики и исследований в Яндексе. А это значит, что я и моя команда каждый день думаем, как оценивать качество работы генеративных моделей, какие при этом смотреть метрики, как вообще понять, хорошая ли модель у нас получилась.

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

В этой статье предлагаю найти ответ на вопрос: есть ли универсальный метод оценки работы LLM‑моделей? Для этого я расскажу, какие для этого существуют бенчмарки и почему нельзя полагаться только на них, как работает Chatbot Arena LLM Leaderboard, кто такие AI‑тренеры и может ли одна модель правильно оценить другую.

Бенчмарки для оценки умений генеративной модели

Чтобы составить бенчмарки для генеративной модели, можно использовать как человеческие образовательные тесты ОГЭ, ЕГЭ, AP, GRE, SAT, профессиональные — Uniform Bar Exam, USMLE, Certified Sommelier, так и тесты, созданные специально для для LLM: MMLU, GPQA, ARC и многие другие.

Наверное, ни одна сегодняшняя статья или пресс‑релиз новой версии LLM не обходятся без упоминания этих тестов: GSM8K и MATH, чтобы оценить математические способности, HumanEval для оценки навыка кодинга, DROP и RACE на способность понимать текст и отвечать на вопросы по этому тексту. Но, наверное, самым популярным за последний год стал бенчмарк MMLU как мерило знаний обо всём на свете. Он охватывает всевозможные области человеческих знаний, начиная от школьной математики, заканчивая химией, физикой, маркетингом, юриспруденцией и многим другим. В тесте 57 тем и 16 000 вопросов. Образованный человек, эксперт в соответствующей области, сдаёт тест примерно на 90%.

Кроме того, важно помнить, что в отличие от человека, у LLM‑моделей нет внутренней картины мироустройства, и поэтому им сложнее справиться с вопросами, которые нам кажутся очевидными. Для оценки этого аспекта есть множество бенчмарков на «здравый смысл»: COPA, PIQA, OpenBook, WinoGrande и многие другие.

Если любой из вопросов на картинке выше задать человеку, на вас, скорее всего, посмотрят с недоумением — как можно спрашивать такие глупости? А для модели все эти ответы неочевидны, и эти тесты нужны, чтобы понять, насколько разумна модель.

Помимо вышеперечисленных общих академических бенчмарков можно сделать тест на любой важный для вас навык. Многие IT‑компании для этих целей создают свои внутренние бенчмарки и тестируют свои модели на них. Яндекс в этом смысле не исключение. Поскольку у YandexGPT есть множество внутренних применений — от автоматизации части краудсорс‑разметок и оптимизации поддержки пользователей до рекомендации ecom‑товаров, суммаризации статей и видео — то на каждый из таких навыков мы создаём свой бенчмарк.

Приведу несколько примеров таких «спецбенчей»:

Примеры вопросов из внутренних бенчмарков для генеративных моделей в Яндексе.

1. Знание специальных фактов. Помимо ответов на общепринятые тесты нам важно, чтобы YandexGPT знала важные для нас русскоязычные факты, в том числе и из сферы ecom.

2. Провокации. Для LLM характерно пытаться быть максимально полезными и всегда отвечать на вопросы пользователя, что приводит к ситуации, когда модель уверенно отвечает на неотвечаемые gotcha и галлюцинирует. Для оценки того, насколько наши модели легко поддаются на провокации, мы собрали специальный бенчмарк с провоцирующими русскоязычными вопросами.

3. Следование формату. Есть известный англоязычный тест на следование формату IFEval. Он оценивает, способна ли модель следовать инструкциям, каким должен быть её ответ: например, написать свой ответ в N предложениях чтобы каждое слово начиналось с буквы B. Есть также и автоматически переведённая его версия, но поскольку машинный перевод имеет ошибки, а количество инструкций довольно ограничено и не покрывало все наши продуктовые применения, мы на основе IFEval создали свой продуктово‑расширенный бенчмарк на следование формату.

4. Культурный код. Так как YandexGPT используется для Нейро и Алисы, с которыми каждый день общаются миллионы пользователей, то нам важно, чтобы наша LLM знала «русскую душу»: культурные отсылки, мемы, крылатые фразы. Ведь как иначе общаться с помощником, если он не отличает ватрушку от расстегая, не знает, как продолжить «Слабоумие и…», и не помнит любимые цитаты из рекламы 90-х. Создание этого бенча достойно отдельной подробной статьи, настолько много сил и души мы вложили в него.

Очень важный нюанс — когда мы делаем кастомные бенчмарки, важно их тщательно валидировать. Приведу в пример как раз тот самый бенчмарк культурного кода: когда мы сделали его первую версию, а потом дали прорешать нашим экспертам, оказалось, что результат зависит от года их рождения. То есть у нас получился такой культурный код 30+, и нам пришлось срочно исправляться и разбираться с TikTok‑трендами, чтобы получился тест, репрезентативный соцдему пользователей Алисы.

Итак, бенчмарки легко интерпретировать, легко отслеживать прогресс и сравнивать разные модели, они очень понятны, и их можно сделать под любой конкретный навык. Что может быть не так? К сожалению, довольно многое.

Что не так с бенчмарками

Бенчмарки подвержены протечкам, или benchmark leakage. Когда вы учите модель, часть открытых бенчмарков может попасть к вам в трейн. Получается, что результаты, которые вы в итоге видите, — это не способности модели в чистом виде, а частичная протечка данных из трейна в тест.

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

Поэтому вполне вероятно, что часть информации из самого бенча или какая‑то вспомогательная полезная для ответа на вопрос информация может оказаться на тех веб‑страницах, которые попали в претрейн‑данные. Есть разные подходы к тому, как оценивать степень загрязнения бенчмарка для конкретной модели: например, один из них описан в статье Benchmarking Benchmark Leakage in Large Language Models.

Но факт остаётся фактом — протечкам в разной степени подвержены многие LLM. Мы в Яндексе тоже стараемся внимательно следить за любыми загрязнениями бенчмарков: у нас есть модель, которая находит похожие на известные бенчмарки куски текста и безжалостно вырезает их из претрейн‑датасета. В качестве финальной проверки степени загрязнения мы поднимаем поиск по претрейн‑датасету, и эксперты сами ищут всевозможные переформулировки и полезные для ответа на вопрос из бенчмарка запросы и оценивают степень протечки.

Статические, классические бенчмарки долгое время были золотым стандартом для оценки качества моделей, но сейчас их ограничения становятся всё более очевидными. Помимо проблем с протечками, неустойчивости к способу замера и переобучению на формат тестов, бенчмарки довольно быстро устаревают. Если ещё пару лет назад лучшие LLM решали не больше, чем половину сложных математических задач из бенчмарка MATH, то сейчас многие модели выдают результат 85+, а ещё через год, вероятно, и вовсе потеряют свою актуальность, поскольку многие модели будут выдавать на этом бенчмарке высокий скор.

Но, наверное, самое важное, что нужно помнить, — скор на бенчмарке не тождественно равен интеллекту модели. Так, например, на MMLU‑тесте уже многие модели превосходят человека. Означает ли это, что всех физиков, математиков, юристов и прочих экспертов уже можно заменить на модель?

Но стоит задать самую хайповую задачу этого сентября — спросить у модели, сколько сестёр у брата Алисы — , и она повергает в недоумение большую часть моделей. На рисунке ниже видно, что ни одна из популярных моделей пока не справилась на 100%. Кажется, пока мы всё ещё несколько далеки от AGI.

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

Chatbot Arena LLM Leaderboard для оценки умений генеративной модели 

Итак, у бенчмарков есть свои довольно сильные ограничения. И мы подумали — а что, если в качестве оценки, какая модель лучше, мы будем давать возможность пользователем свободно взаимодействовать с моделью на любую тему и вслепую выбирать, чей ответ лучше? Так у нас появилась LMSYS Chatbot Arena.

Arena Leaderboard устроена просто: есть вопрос и два варианта ответа, за один из которых нужно проголосовать. Дальше примерно та же система, что в шахматном турнире: в случае выигрыша получаете очки, в случае проигрыша — теряете.

Кажется, что теперь мы объективно понимаем, что чем выше скор на лидерборде, тем лучше модель. Что же может пойти не так?

Что не так с Arena Leaderboard 

Как и везде, здесь тоже будут свои «но».

Первое — узкие темы запросов. На Chatbot Arena приходят, в первую очередь, те пользователи, кто интересуется LLM, а значит им интересны чаще всего айтишные вопросы про код. Вряд ли такие посетители дадут задачу на систему разбора отзывов на ресторан по определённым характеристикам да ещё и с примерами реальных отзывов. Исключения бывают, но околоайтишные темы преобладают.

Второе — тип задач, с которыми люди приходят на Arena Leaderboard. Если человека попросить дать задачу LLM, скорее всего, первое, что придёт в голову, — задать модели какой‑то вопрос либо попросить её что‑нибудь придумать. Мало кто задаст вопрос: «У меня есть такая задача по разметке данных {инструкция на 2 страницы}, выполни её на {множество реальных данных}, пожалуйста».

Ещё одна проблема — смещение в формат. Её подсветил не так давно разгоревшийся спор: GPT-4o mini побеждает Claude. Люди в X возмущены: «Claude решает все мои задачи, а GPT-4o mini ничего не может для меня сделать!» Создателям Arena Leaderboard пришлось даже опубликовать семпл датасета, чтобы люди могли посмотреть, как так вышло.

А произошло вот что: людям важно не только, что вы говорите, но и как вы это говорите. Это же правило работает и с ответами LLM.

Людям нравятся длинные, аккуратно оформленные ответы со множеством отсылок, даже если где‑то в ответе ошибка, даже если ответ менее качественный. Как попытка хотя бы отчасти смягчить такую субъективность, в Arena Leaderboard появилась поправка на стиль. Как раз после дебайеса на стиль ответа и попытки разделить содержание и форму, видим, что Claude резко поднимается наверх, а GPT-4o mini драматически падает.

Итак, пользователи Arena Leaderboard не обязаны проводить всестороннюю оценку: выбирать темы равномерно и задавать вопросы по всевозможным навыкам и задачам. Не обязаны они и разбираться в теме, в которой голосуют, и проводить детальный фактчек. Они вольны выбирать тот ответ, который им просто нравится. Что же делать? Можно попробовать решить эти проблемы с помощью внешней контролируемой разметки качества ответов на заданные вопросы.

Экспертная разметка для оценки умений генеративной модели 

Сначала мы использовали асессорские разметки для оценки качества наших моделей. Однако на текущем уровне развития LLM качество разметки получалось недостаточным.

Так, например, наши асессоры склонны были выбирать более «красивый» ответ, в котором больше Markdown‑разметки, и пропускать фактологические ошибки или проблемы с подтверждённостью в вопросах типа closed QA. Отчасти эту проблему удалось решить многоступенчатой системой обучений, экзаменов и сложной системой контроля качества с привлечением более экспертных разметчиков, а также компенсациями за дополнительное время, потраченное на более тщательную разметку. Сейчас мы используем асессорские разметки как один из этапов отбора кандидатов моделей, но он не является финальным.

Чтобы получить более качественную разметку, мы пришли к тому, что нанимаем экспертов — AI‑тренеров. Это специалисты в разных областях, которых мы отбираем сначала с помощью специально разработанных тестов (одним из важных навыков, который мы тестируем, — способность фактчекать любую информацию), а затем по результатам собеседований.

Система мотивации AI‑тренеров устроена так, что им гораздо выгоднее размечать меньшее количество задач, но делать это более внимательно. Так, например, для оценки пяти ответов модели на один вопрос у AI‑тренера уходит от 40 минут до часа.

Что особенно важно в случае тестирования генеративной модели с помощью экспертной оценки?

Зафиксировать валидационное множество заданий, на которых вы собираетесь оценивать модель. Это могут быть задания и на логику, и на работу с текстом, и на креатив. В Яндексе мы называем эти множества «корзинки». Важно проконтролировать разнообразие тем, их сложность, процент бизнес‑задач и любые другие стратификации, которые будут важны конкретно для вас. В общем, надо следить, чтобы ваша корзинка была достаточно сложной и одновременно достаточно репрезентативной вашим задачам.

Наши первые корзинки довольно сильно были похожи на типичные вопросы из Chatbot Arena Leaderboard, но стратифицированные по типам задач (задача экстракта данных, open QA, closed QA, суммаризация и т. д.). Со временем немалую долю стали занимать практические приложения YandexGPT как внутри компании, так и под задачи наших клиентов в Yandex Cloud.

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

Для разметки ответов LLM мы используем похожий по своей сути на предложенный в статье интерфейс. Мы оцениваем сразу несколько ответов различных кандидатов на один вопрос. Это позволяет более эффективно тратить время AI‑тренеров, ведь каждая задача из корзинки требует немало времени, чтобы ознакомиться с темой, понять, как должен выглядеть идеальный ответ.

После ознакомления с задачей эксперт сначала должен оценить отдельно каждый вариант ответа LLM по пятибалльной шкале, а также по множеству бинарных пунктов (нарушения безопасности, неследование ограничениям вывода, логические ошибки, фактологические ошибки, неподтверждённые предложения в случае closed QA и т. д.).

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

И да, у этого метода тоже будут свои «но»:

1. В какой‑то момент эксперт неизбежно достигает предела своей компетентности.

2. Нужна постоянная система контроля качества. Наша команда каждый день переживает: «А хорошая ли у нас разметка, а не ерунду ли она показывает?» Чтобы контролировать качество, мы выстроили достаточно сложную иерархическую систему — эксперты объединены в группы по 10–12 человек, и у них есть руководитель, а у руководителя есть руководитель, и у этого руководителя… На каждом этапе руководители оценивают некоторый процент разметки и выносят вердикт качества работы соседней команды, к качеству привязана система мотивации AI‑тренеров. Помимо этого, мы регулярно подмешиваем в разметку контрольные задания, на которых известен вердикт, проводим дополнительные обучения и экзамены. Всё это позволяет удерживать хороший уровень качества разметки и обеспечивать одинаковое понимание задачи у довольно большой команды.

3. Работать с людьми — сложно. Когда вы выстраиваете такую экспертную систему, вам приходится уже работать не только аналитиком‑разработчиком, но и эйчаром. Я и моя команда продумываем системы компенсации, грейдирования, процессы ревью, тимбилдинги и мероприятия для нашей команды AI‑тренеров.

4. Работать с экспертами — дорого. Содержание такого экспертного штаба обходится нам в довольно внушительные суммы.

5. Как только вы решаете, что вашей модели нужен какой‑то новый навык, вам приходится заново подстраивать систему. Например, если вы захотите улучшать модель в области математики или физики, вам придётся нанять экспертов в этих областях. Надо подумать, как их нанимать, какие тестовые задачи, какая у них система контроля качества — и всё по новой.

6. Если вы выстроили прекрасную систему разметки с высоким качеством, не факт, что она будет отражать то, что именно ожидают пользователи от модели. Приведу пример из нашего соседнего проекта — разметки для YandexART. Мы продумали и выстроили стабильную, качественную side‑by‑side‑разметку на асессорах. Одним из ключевых аспектов выбора была дефектность, то есть наличие в изображении видимых дефектов (искажённые лица, не то количество пальцев). Но в ходе А/Б‑экспериментов мы выяснили, что пользователям более важно разнообразие изображений и их эстетичность, а на аспект дефектности они смотрят в меньшей степени.

Отдельно здесь хочется упомянуть про довольно популярное направление LLM‑as‑a-Judge. Принцип тот же: вы фиксируете множество запросов, определяете «правила игры», как определить, какой ответ лучше, какой хуже, но вместо экспертной оценки используете мощную LLM (например, GPT-4o) или даже ансамбль качественных моделей. Это сильно экономит бюджет: оценка 1000 заданий обойдётся меньше чем $10, к тому же это намного быстрее и вам не придётся выстраивать сложную систему контроля и операционного управления.

По этому принципу сделаны бенчмарки MT и Arena‑Hard. К тому же у этого способа довольно высокая согласованность с человеческими предпочтениями (89,1% для Arena‑Hard‑Auto‑v0.1 GPT-4–1106-Preview Judge), что позволяет довольно хорошо разделять близкие по качеству модели (87,4% Separability для Arena‑Hard‑Auto). По сравнению с классическими статическими бенчмарками, которые быстро устаревают, «протекают» или становятся слишком простыми для современных моделей, такой подход позволяет быстро и дёшево оценивать качество модели довольно близко к предпочтениям пользователей. Но и тут не все розовые пони и единороги.

Во‑первых, модели‑судьи склонны к «нарциссической предвзятости»: они предпочитают свои ответы или ответы моделей, обученных на выходы модели‑судьи, ответам моделей‑конкурентов. Это справедливо абсолютно для всех моделей.

Во‑вторых, модели‑судьи, как и человек, смещены на стиль ответа (так называемый verbosity bias). Модели предпочитают более длинные, структурированные и подробные ответы, даже если в них может закрасться незамеченной ошибка.

В‑третьих, — самое главное и болезненное для меня как для аналитика — LLM не самый хороший фактчекер. Если модель не может уверенно отличить правду от вымысла, её оценки рискуют быть поверхностными или вводящими в заблуждение. Когда мы полагаемся на LLM в качестве арбитра, важно помнить, что её «уверенность» в ответах не всегда равна фактической точности.

Выводы

Всё просто

К сожалению, нет никакой «серебряной пули», нет единого «правильного» решения, как оценивать LLM. Не получится избежать того, что вам придётся постоянно смотреть в данные, сомневаться, исследовать и регулярно размечать самим.

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