Обучение собственному судье на основе LLM: от PandaLM и JudgeLM до Prometheus
Как создаются тонко настроенные модели оценщиков, от данных и рубрик до контроля предвзятости и метаоценки, а также практический подход к обучению специализированного судьи на основе LLM.
Источники: Finetuning LLM Judges for Evaluation
Как только модель языка может писать эссе, отвечать на запросы поддержки и кратко излагать содержимое контрактов, вопрос «хорош ли этот результат?» уже нельзя ответить просто так. Человеческий аудит считается золотым стандартом, но он медленный и дорогой; традиционные показатели качества едва ли могут отслеживать его на текущем уровне. Попытки заставить собственную модель оценивать результаты работают эффективно лишь тогда, когда ваши критерии схожи с тем, что уже известно этой модели. В данном руководстве рассматриваются исследования по использованию отрегулированных моделей LLM в качестве оценщиков, открытых моделей, обученных специально для оценки и критики других моделей, а также приводится практический алгоритм, который можно использовать для создания инструмента оценки в вашей сфере деятельности.
Почему оценка современных моделей LLM настолько сложна
Два фактора, характерных для современных моделей на основе фундаментальных архитектур, затрудняют их оценку. Первый — это объем задач: от одной модели ожидается, что она будет писать код, переводить тексты, рассуждать, соблюдать правила форматирования, действовать безопасно и вести себя дружелюбно, причем каждое из этих поведений требует отдельной оценки. Второй фактор — отсутствие четкого окончания задачи. Для практически любого запроса существует большое количество приемлемых ответов, отличающихся формулировкой, структурой, длиной и акцентами, поэтому невозможно просто проверить, соответствует ли результат ожидаемой строке. Тщательная оценка даже одной из способностей модели уже является исследовательской задачей, а у производственных моделей их десятки.
Наиболее надежные сигналы по-прежнему поступают от людей, которые читают результаты работы моделей и оценивают их. Проблема заключается в том, что человеческие оценки сопровождаются ошибками, требуют значительных усилий и занимают много времени на сбор, что не соответствует темпам разработки моделей. Команда, которая несколько раз в неделю переобучает или снова задает запросы модели, не может ждать новой кампании аннотации после каждого изменения. Определенный уровень человеческой оценки остается неотъемлемым, но его необходимо дополнять чем-то, что позволяет масштабироваться.
Эта потребность привела к появлению концепции LLM-as-a-Judge, описанной в статье «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena»: вы задаёте запрос мощной собственной модели для оценки результата работы другой модели. Этот подход теперь широко используется в исследованиях, но у него есть слабое место. Продукты, ориентированные на конкретные области, часто учитывают тонкие критерии, такие как сохранение информации о дозировке в медицинском кратком изложении или правильное цитирование соответствующей статьи в юридическом ответе, и у универсальной модели может не хватать способности надёжно оценивать их. В такой ситуации естественным следующим шагом является обучение специализированного «судьи», и понимание того, как это сделать эффективно, является целью остальной части этой статьи.
Инструментарий оценки: люди, метрики и судьи на основе моделей
На практике команды сочетают человеческую оценку с автоматическими метриками. Люди определяют качество в окончательном виде, а автоматические метрики обеспечивают скорость. Поскольку автоматические оценки являются лишь приблизительным отражением мнения людей, их постоянно сравнивают с периодическими человеческими оценками, но между этими проверками можно сравнить гораздо больше вариантов моделей, чем смогли бы просмотреть люди.
Автоматическая оценка современных больших языковых моделей в основном делятся на две категории. Первая — это оценка в стиле тестов на производительность, основанная на вероятности или плекситете; она включает большинство традиционных тестов по обработке естественного языка, таких как MMLU и BIG-bench. Эти тесты похожи на тесты с множественным выбором, проверяющие знания модели. Они полезны, но мало что говорят о том, насколько хорошо модель может написать длинный, стилистически соответствующий ответ на открытый вопрос.
Для длинных, открытых ответов на самом деле существует лишь два пути: либо позволить людям оценивать ответы, либо использовать способный модель для этой цели. Учитывая затраты первого подхода, оценка с использованием моделей стала стандартом. Она не требует эталонного ответа, её легко настроить, и она справляется с самыми разными задачами. В следующих разделах поочередно рассматриваются каждый инструмент из этого набора, начиная с человеческой оценки, поскольку всё остальное сравнивается с ней.
Человеческая оценка является эталоном, но не идеальным
Люди могут определить, что действительно важно в ответе: достаточно ли он краток, творческий ли, подходит ли по тону или учитывает культурные особенности. Именно поэтому человеческий аудит остается эталоном. Аннотаторы могут приходить из самых разных источников. Вы можете использовать коллективное голосование, как это делает Chatbot Arena, нанять специализированную команду или, как это сделал проект Alpaca, позволить разработчикам моделей сами оценивать результаты. Однако использование людей в качестве эталона не означает, что их метки всегда точны. На практике они часто бывают несогласованными, их составление требует усилий, и они подвержены предвзятости.
Согласованность и калибровка
Даже задачи, которые кажутся простыми, часто приводят к удивительно низкому уровню согласия между аннотаторами. Его можно оценить с помощью простого коэффициента совпадений или статистики с коррекцией на случайность, такой как каппа Коэна (два оценщика), каппа Флейсса (множество оценщиков) или альфа Криппендорфа (гибкий метод с учетом отсутствующих меток и различных типов шкал). Коррекция на случайность имеет большое значение: если 80 процентов ответов считаются «хорошими», два оценщика, которые всё отмечают как «хорошее», будут соглашаться в большинстве случаев, не получив никакой новой информации.
Когда уровень согласия низкий, решением является калибровка, то есть обучение аннотаторов выполнять задачу одинаковым образом. Типичным этапом является сессия обзора, в ходе которой оценщики рассматривают элементы, по поводу которых у них были разногласия, обсуждают ситуации и приходят к общему толкованию. Результаты этих обсуждений затем записываются в руководство по выполнению задачи, чтобы следующая партия работ начиналась с более четкой основы.
Руководства по написанию, которые действительно используются
Руководства представляют собой письменный договор для выполнения задачи аннотирования. Как минимум в них должно быть указано, что именно оценивается, то есть критерии, и как следует применять каждый из них. Хорошие руководства сочетают в себе текстовые инструкции с примерами правильных и неправильных меток, которые аннотаторы используют в процессе работы, а не читают лишь один раз. Они способствуют большей последовательности в присвоении меток и значительно сокращают время обучения новых оценщиков. Полезный тест: если аннотатору для правильной маркировки элемента требуются знания, отсутствующие в документе, значит документ неполный.
Руководства также следует рассматривать как динамично развивающиеся документы. Команда InstructGPT, например, описывала постоянную корректировку своих инструкций для маркировщиков на протяжении всего проекта по мере изменения отзывов пользователей, полей метаданных и понимания целевой аудитории, а также исправление фрагментов текста, которые оказывались неоднозначными или противоречивыми. Такой опыт является типичным: задачи, которые кажутся очевидными, обычно скрывают в себе много субъективности, и она проявляется лишь тогда, когда группа людей пытается договориться относительно сотен реальных примеров.
Контроль согласованности со временем
Значительные инвестиции требуются на начальном этапе: разработка критериев, настройка оценщиков и постепенная корректировка до достижения приемлемого уровня согласованности. Только тогда человеческие оценки становятся надежным показателем качества модели. Однако работа на этом не заканчивается. Уровень согласованности может снижаться по банальным причинам: присоединяются новые оценщики, опытные постепенно отходят от прописанных правил или сами руководящие принципы меняются. Постоянный мониторинг согласованности между оценщиками, например путем отправки части заданий нескольким оценщикам, — единственный способ заметить это до того, как оно незаметно испортит ваши данные оценки.
Метрики, основанные на эталонах, и причины их неэффективности
Ранние поколения языковых моделей обычно оценивались с помощью таких метрик, как ROUGE для краткого изложения и BLEU для перевода. Обе они основаны на эталонных решениях: они сравнивают результат работы модели с идеальным ответом, в основном путем подсчёта перекрывающихся n-грамм, и стимулируют те результаты, которые содержат больше слов и фраз из этого эталона.
По мере совершенствования моделей эти метрики потеряли свою актуальность. Исследования результатов работы больших языковых моделей показали, что такие метрики слабо коррелируют с предпочтениями людей, до такой степени, что ни одна из традиционных метрик не способна точно отразить человеческий осмотр. Они сохраняются в основном потому, что их очень легко вычислять. Если у вас уже есть эталонные ответы, они всё ещё могут служить быстрой проверкой качества, например, для выявления регрессии, когда суммаризатор вдруг начинает генерировать пустой или несвязанный с темой текст.
Основная причина их неудачи кроется в структуре. Метрика, основанная на ссылке, по сути представляет собой сложную технику размытого совпадения по отношению к одной-единственной целевой модели. Современные модели имеют открытую структуру: один запрос может дать множество одинаково хороших ответов, которые вряд ли будут содержать много общих n-грамм с исходным текстом. Оценка, которая стимулирует сходство с конкретным ответом, не может отразить весь спектр допустимых решений, поэтому она наказывает совершенно корректные парафразы и может поощрять плавный текст, случайно использующий лексику исходного текста, даже если он неверен.
Судьи на основе запросов к LLM
Недостатки метрик на основе перекрытия побудили сообщество к использованию более гибких методов оценки, основанных на моделях. Самой популярной формой является подход LLM-as-a-Judge: сильная модель привлекается для оценки результатов работы другой модели. Исследования MT-Bench и Chatbot Arena показали, что этот метод хорошо соответствует предпочтениям людей, его легко реализовать с помощью хорошо составленного запроса, он естественно справляется с открытыми форматами ответов и может учитывать множество различных критериев. В этих исследованиях его представляли как масштабируемую и объяснимую аппроксимацию человеческих предпочтений, сбор которых в противном случае требует значительных усилий.
В остальной части этой статьи термин «LLM-as-a-Judge» относится конкретно к использованию готовой коммерческой модели, такой как GPT-4o или Gemini 1.5, в качестве судьи, а термин «доработанный судья» — к модели, которую вы сами обучаете для оценки. Для получения более полной информации об использовании судей, управляемых через вводные команды, полезными источниками являются практическое руководство по созданию судей, способных влиять на бизнес-решения, анализ эффективности оценочных моделей LLM и обзор исследований в области использования LLM-as-a-Judge. Если вы уже используете судью, управляемого через вводные команды, в производственных целях, аспекты его эксплуатации рассмотрены в нашем руководстве по управлению LLM-as-a-Judge как живой производственной системой.
Парная и точечная оценка
Существует два основных способа запроса вердикта у судьи:
- По парам: судья видит задание вместе с двумя кандидатскими ответами и выбирает лучший (часто с опцией ничьей).
- По баллам: судья видит задание и один ответ, после чего присваивает оценку, обычно по шкале Лайкерта от 1 до 5.
Оценивание по баллам также называется прямой оценкой или оцениванием с одним ответом. В обоих случаях можно использовать руководство в виде эталонного ответа, добавляя его к заданию судьи, чтобы тот мог сравнивать свои ответы с ним, а не полагаться только на собственные знания. Популярным примером использования судьи, управляемого заданием, является AlpacaEval — табло лидеров, которое использует LLM-as-a-Judge для прогнозирования предпочтений людей между результатами работы моделей и публикует все свои задания для оценки, включая более ранние версии.
Выбор способа оценивания
Нет универсального решения, подходящего во всех случаях; правильный выбор зависит от конкретного приложения. Парные оценки обычно более стабильны, поскольку сравнение двух объектов проще, чем размещение одного объекта на абсолютной шкале. Недостатком является предвзятость в пользу первого (или второго) результата, а также более низкая масштабируемость: парные результаты показывают лишь порядок относительности выходных данных, и для сравнения множества систем требуется большое количество пар. Оценивание по отдельным пунктам более универсально, поскольку каждый результат получает собственную оценку, которую можно сохранить, средневзвесить и сравнить позже. Однако это сложнее для оценщика, так как ему приходится основывать оценку исключительно на собственном восприятии качества. Предоставление эталонного ответа — распространенный способ сделать оценивание по отдельным пунктам более надежным.
Природа критерия также имеет значение. Объективные свойства, такие как фактичность или соответствие исходному документу, как правило, бинарны: ответ либо верен, либо нет. Вопрос о том, какой из двух ответов является «более верным», плохо определен. Субъективные критерии, такие как полезность, тон или общее предпочтение, позволяют делать относительные оценки, поскольку людям и моделям проще и надежнее сравнивать их, чем ставить абсолютные оценки. Разумным стандартом является поэтапная оценка: бинарная для объективных проверок и сравнения пар ответов для оценки субъективного качества.
Склонности, унаследованные каждым судьей
Независимо от того, какой тип судьи вы используете — стандартный или отрегулированный, — ряд систематических склонностей постоянно проявляются, и большинство методов отрегулирования, описанных далее в этой статье, предназначены для их устранения. Перед дальнейшим чтением полезно знать их названия:
- Предвзятость из-за позиции: в режиме парных сравнений эксперт отдает предпочтение первому или второму варианту независимо от содержания.
- Предвзятость из-за объема: более длинные и подробные ответы получают высокие оценки, даже если дополнительный текст не приносит никакой пользы.
- Предвзятость самоусиления: эксперт предпочитает ответы, написанные им самим или моделями из той же семьи.
- Предвзятость знаний: эксперт не может оценить правильность ответов по темам, в которых он плохо разбирается, и может поощрять уверенные, но неверные ответы.
- Предвзятость формата: эксперт может работать только тогда, когда запрос полностью соответствует тому, для которого он был создан или настроен.
Ни один из этих факторов невозможно полностью исключить, но каждый из них можно измерить. Изменение порядка кандидатов, дополнение ответа безвредным «филлером» или оценка одного и того же контента с использованием двух разных шаблонов запросов — это простые эксперименты, позволяющие выяснить, насколько определенный судья подвержен влиянию факторов, которые не должны иметь значения. Проведение таких экспериментов один раз при выборе судьи и еще раз после любых изменений в его шаблоне запросов или модели является одной из наиболее ценных практик в работе по оценке.
Где проявляются недостатки судей, управляемых через запросы
Использование ИИ-моделей в качестве судей эффективно и широко распространено, но использование эксклюзивных моделей сопряжено с реальными недостатками:
- Модель представляет собой «черный ящик», и передача данных оценки третьей стороне может вызвать проблемы с безопасностью и конфиденциальностью.
Почти все эти проблемы связаны с зависимостью от модели, которую невозможно проверить или изменить. Это поднимает очевидный вопрос: можно ли обучить собственного оценщика. Исследования, приведенные ниже, дают положительный ответ — тщательно настроенный оценщик может предоставлять более детальную и критичную обратную связь, специфичную для конкретной области, при условии инвестиций в соответствующие данные.
Метаоценка: оценка самого судьи
Прежде чем обучить судью, определите, как вы будете понимать, насколько он хорош. Ответом является набор данных для оценки с пометками людей, которым вы полностью доверяете, поскольку они становятся критерием для всех создаваемых вами судей. Метаоценка, то есть оценка того, кто оценивает, подразумевает запуск судьи на этих данных и сравнение его вердиктов с вердиктами людей.
Если судья выдает бинарный результат, такой как выбор между двумя вариантами или оценка «прошел/не прошел», вы можете использовать обычные метрики классификации, такие как точность, чувствительность, полнота и кривая ROC. Поскольку их очень легко интерпретировать, многие специалисты считают, что бинарная оценка является наиболее практичным подходом для судей на основе больших языковых моделей в целом.
Для небинарных оценок, таких как шкала Лайкерта от 1 до 5, необходимо измерить степень корреляции между оценками судей и оценками людей. В качестве эталона в исследовании G-Eval было сообщено, что оценочная система на основе GPT-4 достигла коэффициента корреляции Спирмена 0,514 с результатами людей в тесте на краткое изложение, что в то время значительно превосходило более ранние методы. Коэффициент корреляции рангов Спирмена, вероятно, является наиболее распространенным выбором, но также используются коэффициент тау Кендалла, коэффициент корреляции Пирсона и коэффициент каппа Коэна в качестве показателей согласованности. С ними сложнее работать по сравнению с метриками классификации, поэтому необходимо изучить особенности того показателя, который вы используете. Коэффициент Пирсона измеряет линейную согласованность и чувствителен к аутлайерам; Спирмен и Кендалл учитывают только порядок, поэтому судья, который систематически ставит на один балл выше, все равно может получить идеальные результаты по этим показателям.
Практические привычки метаоценки
Несколько привычек делают метаоценку гораздо более информативной. Сообщайте о согласии по каждому критерию отдельно, а не о едином суммированном показателе, поскольку судья может отлично выявлять фактические ошибки, но плохо оценивать тон, а средний показатель это скрывает. Рассматривайте несоответствия между соседними оценками отдельно от кардинальных различий: ситуация, когда судья ставит 4, в то время как люди — 5, сильно отличается от ситуации, когда он ставит 1. Сравнивайте согласованность между судьей и людьми с согласованностью между самими людьми по тем же пунктам; если два обученных аннотатора соглашаются лишь на 70 процентов случаев, то судья, соглашающийся с ними на 68 процентов, фактически достиг верхнего предела, и стремление к еще большему показателю бессмысленно. Наконец, сохраняйте набор данных для метаоценки строго отдельно от всего, что используется для создания заданий или обучения судьи, иначе цифры будут занижать его реальные способности.
Первое поколение отточенных судей
В начальный период почти все использовали закрытые модели для оценки в стиле судьи, и на это была веская причина. Если вы не предоставляете судье эталонный ответ, модель должна сама уметь решать задачу, чтобы отличить хороший ответ от плохого. Открытые модели долгое время отставали от закрытых, поэтому последние просто лучше справлялись с оценкой. Ситуация изменилась с появлением более мощных открытых базовых моделей, таких как LLaMA и LLaMA-2, когда исследователи начали их дорабатывать в специализированные оценочные инструменты. Приведённые ниже статьи описывают первую волну таких разработок.
Доработанная модель Vicuna в качестве судьи в статье MT-Bench
В той же статье, где был представлен подход с использованием LLM в качестве судьи, был опубликован один из первых экспериментов с отрегулированным под конкретные задачи судьей. Большая часть исследований посвящена использованию стандартных шаблонов для запуска проприетарных моделей с целью прогнозирования предпочтений людей, но в кратком приложении рассматривается возможность обучения открытой модели для выполнения той же функции; в нем был сделан вывод, что отрегулированный Vicuna-13B может стать недорогой открытой альтернативой проприетарным судьям.
Причины, перечисленные в статье, по-прежнему остаются основными аргументами в пользу использования специализированных судей сегодня:
- Использование платных API становится дорогостоящим при масштабировании.
- Проприетарные модели не обеспечивают ни контроля, ни прозрачности.
- Открытые модели постоянно становятся более мощными, поэтому разрыв с проприетарными решениями сокращается.
Если бы отрегулированный открытый судья мог достичь уровня качества проприетарных решений, все три вышеупомянутых проблемы исчезли бы.
В эксперименте использовалась Vicuna-13B, производная от LLaMA. С самого начала она показывала слабые результаты: у неё был высокий уровень ошибок, она часто не соблюдала шаблон оценки или инструкции, а также демонстрировала сильную предвзятость в зависимости от позиции. Точечная настройка существенно изменила ситуацию. Модель обучалась на 20 тысячах голосов людей из Chatbot Arena, каждый из которых сравнивал результаты работы различных моделей; задача была упрощена до трёхкатегорийной классификации: первый ответ выигрывает, проигрывает или заканчивается вничью. После обучения предвзятость снизилась резко, а совпадение с голосами людей значительно улучшилось, хотя модель после настройки всё ещё не достигла уровня GPT-4.
Представление задачи в виде трехсторонней классификации является разумным упрощением. Оно избавляет от необходимости калибровки числовых оценок, напрямую соответствует способу сбора голосов в Arena и позволяет легко вычислять точность по сравнению с голосами людей. Недостаток заключается в том, что судья не дает объяснений, поэтому при несогласии с людьми мы мало что узнаем о причинах.
Вся работа занимает примерно одну страницу, но результаты оказались настолько обнадёживающими, что это стало поводом для начала разработки инструментов открытой оценки.
PandaLM: судья для выбора между чекпоинтами моделей
Частым применением судьи является выбор модели: из нескольких кандидатских моделей какая лучше? Это становится сложным, когда все кандидаты сильные и отличаются лишь незначительно. Люди могут принять решение, но медленно, поэтому судья, способный надёжно выявлять небольшие различия в качестве, очень ценен.
PandaLM был разработан именно для этой цели. Его задача выходит за рамки простого проверения правильности ответа; он также учитывает субъективные критерии, такие как относительная лаконичность, ясность, полнота информации, формальность и соблюдение инструкций. Основное применение — настройка гиперпараметров. Вы тренируете несколько вариантов модели с разными настройками, позволяете PandaLM сравнить их результаты и сохраняете наилучшую конфигурацию. В экспериментах, описанных в статье, каждая модель, настроенная таким образом, показывала лучшие результаты по сравнению с использованием стандартных настроек, что демонстрирует возможность использования оценок для прямого влияния на процесс обучения, а не только для составления отчетов.
Набор данных для обучения содержит более 300 тысяч примеров. Каждый входной элемент представляет собой кортеж (instruction, input, response1, response2), а каждый целевой элемент — кортеж (evaluation result, evaluation rationale). У каждого примера есть эталонный ответ, и в результатах указывается либо лучший ответ, либо объявляется ничья. Команда отточила модели LLaMA различных размеров на этих данных с использованием простого метода предсказания следующего токена и функции потерь кросс-энтропия в стиле «последовательность-в-последовательность», без отдельной головы классификации. Другими словами, вердикт и объяснение — это просто текст, который модель учится генерировать.
Инструкции и входные данные взяты из обучающих данных Alpaca. Пары ответов были сгенерированы несколькими моделями с примерно 7 миллиардов параметров, а именно LLaMA-7B, BLOOM-7B, Cerebras-GPT, OPT-7B и Pythia. Оценки и обоснования для этих пар были синтетически созданы с помощью GPT-4 по принципу Self-Instruct, а затем отфильтрованы с использованием геуристик, таких как ручно разработанные правила и фильтры, удаляющие недействительные или нестабильные оценки. Отдельно человеческие аннотаторы создали более маленький «золотой» набор тестов, предназначенный исключительно для метаоценки.
При сравнении PandaLM с другими оценочными моделями, включая GPT-3.5 и GPT-4, их предпочтения следуют схожим тенденциям: они ранжируют оцениваемые модели в одинаковом порядке. В прямом сравнении с проприетарными оценочными моделями 7B-версия PandaLM показывает конкурентоспособные результаты, а 70B-версия превосходит GPT-4 по результатам оценки, что указывает на то, что способность к оценке, как и большинство других функций, улучшается с увеличением масштаба.
PandaLM также эффективна в специализированных областях. В исследовании она применялась для анализа ответов на вопросы LSAT и к наборам данных для отвечания на биомедицинские вопросы, причем более крупная версия модели показывала особенно хорошие результаты. Поскольку она обучалась именно на данных для оценки, она успешно применяется к задачам оценки в специфических областях, близких к дистрибуции данных её обучения, а не только к общей оценке чатов.
JudgeLM: что на самом деле делает хорошей отрегулированную оценочную модель
Большинство ранних отрегулированных судей почти не говорило о причинах своей работы. JudgeLM был создан для систематического изучения этих факторов, включая:
- количество используемых данных для обучения и их качество и разнообразие;
- размер и качество базовой модели;
- влияние предвзятости на вердикты судьи;
- способность судьи применять свои навыки к другим форматам, таким как многократные диалоги, оценка с одним ответом, парное ранжирование и мультимодальные данные.
Отрегулированный судья может отставать от проприетарного по многим причинам: слабая базовая модель, шумные данные, систематическая предвзятость и т. д. Ценность JudgeLM заключается в том, что он показывает возможность прямого решения этих проблем.
Самым важным компонентом является большой набор данных высокого качества, детализированный и разнообразный; команда JudgeLM прямо заявила, что их набор данных является самым разнообразным и качественным среди имеющихся на тот момент. Он начинается с 105 тыс. исходных инструкций, взятых из общедоступных источников, таких как ShareGPT, а также с версии данных Alpaca с ответами от GPT-4.
Для каждой исходной инструкции ответы генерируются несколькими моделями, включая Alpaca, Vicuna и LLaMA, после чего они сочетаются с первоначальным ответом из исходного набора данных. Таким образом, к каждой инструкции получается несколько вариантов ответа плюс ссылка на источник. Затем случайным образом выбираются пары ответов, GPT-4 оценивает каждую из них и объясняет свои причины. GPT-4 фактически выступает в роли учителя: JudgeLM учится воспроизводить его оценки.
Шаблоны оценки GPT-4 существуют в двух вариантах: с эталонным ответом и без него. Они очень похожи на стандартные запросы для общественных судей, но имеют одно важное отличие — в них прописаны довольно подробные критерии оценки. Это побуждает GPT-4 к более детальной оценке, а последующая настройка модели на основе этих оценок передаёт ту же степень детализации модели JudgeLM.
JudgeLM обучался с параметрами 7B, 13B и 33B на наборах данных от 3,5 тыс. до 100 тыс. примеров с использованием метода настройки по инструкциям с контролируемой доработкой (SFT). Входные данные включают одну инструкцию, два кандидатских ответа и эталонный ответ. Модель выдает отдельную оценку для каждого ответа вместе с обоснованием. Превратить это в парное решение очень просто: побеждает тот ответ, у которого оценка выше, а при равных оценках — ничья. Полезным побочным эффектом такой конструкции является то, что одна и та же модель может служить как оценщиком, так и сравнивателем.
Сокращение предвзятости было центральной целью. JudgeLM нацелен на устранение трех видов предвзятости:
- Предвзятость по позиции: предпочтение той или иной ответной формулировке из-за её местоположения в запросе, а не из-за содержания самого запроса.
- Предвзятость знаний: у базовой модели отсутствуют знания, полученные в ходе предварительной обучения, необходимые для правильной оценки ответа.
- Предвзятость формата: система оценки работает эффективно только тогда, когда запрос соответствует точному формату, использованному во время доработки модели.
У каждого из этих проблем существует довольно прямое решение. Склонность к формату снижается, когда во время обучения судья видит несколько форматов запросов. Склонность к знаниям уменьшается, если предоставить судье эталонный ответ, тем самым избавляя его от необходимости знать факты самостоятельно. Склонность, связанная с порядком, устраняется путем изменения порядка: каждую пару необходимо оценивать в обоих возможных порядках как при создании данных для обучения, так и во время вывода результата. Если вердикт меняется при смене порядка, такая пара обычно считается ничьей. Изменение порядка во время обучения помогает модели сосредотачиваться на содержании, а не на расположении элементов, а изменение порядка при выводе результата снижает любые оставшиеся искажения. Совместное применение этих методов значительно снижает склонность JudgeLM к искажениям.
Стоимость смены позиций в процессе инференса следует учитывать: она удваивает количество вызовов функции оценки для парного сравнения. Для крупных офлайн-оценок это обычно приемлемо; однако для онлайн-использования, чувствительного к задержкам, это может оказаться неприемлемым.
На собственном наборе данных для оценки JudgeLM превосходит PandaLM и GPT-3.5 как с использованием эталонных ответов, так и без них. Такое сравнение склоняет чашу весов в пользу JudgeLM, поскольку он обучался на данных из практически одного и того же набора, но он также показывает хорошие результаты на наборе данных PandaLM. Следует отметить, что большая часть сообщаемой производительности JudgeLM связана с согласованностью с GPT-4 — тем же моделью, которая генерировала его обучающие метки, а не с согласованностью с людьми. В целом модели показывают стабильные результаты, их производительность улучшается по мере увеличения размера, и они более устойчивы к смене позиций по сравнению с альтернативами.
Это указывает на общее ограничение метода дистилляции судей. Когда учебная модель обучается на вердиктах «учителя», точность последнего выступает своего рода верхним пределом, а его слабые стороны и предубеждения передаются вместе с сильными сторонами. Высокая степень согласованности с GPT-4 говорит о том, что процесс дистилляции состоялся; однако это не означает, что «судья» согласен с вашими пользователями. Только тестовый набор с маркировкой людьми может ответить на этот второй вопрос.
Auto-J: основанный на реальных запросах пользователей
Auto-J, описанный в статье «Generative Judge for Evaluating Alignment», — ещё один отточенный инструмент оценки, предназначенный для оценивания в конкретных сценариях в реалистичных условиях. Его отличительные особенности:
- Он поддерживает как двойное сравнение, так и оценку по одному ответу.
- Он делает акцент на хорошо структурированных, качественных комментариях на естественном языке.
В результате получается судья, который является гибким, интерпретируемым и практичным.
Для Auto-J сначала определяются сценарии, каждый из которых имеет своё определение и критерии оценки. В исследовании рассматриваются 58 сценариев, объединённых в восемь более широких категорий. Для каждого сценария собираются реальные запросы пользователей, генерируются ответы, а GPT-4 формирует оценки. GPT-4 руководствуется вручную составленными критериями, специфичными для каждого сценария; результаты дополнительно обрабатываются с помощью эвристических фильтров и нормализации формата для уменьшения шума. Каждый сценарий вносит до 100 примеров, в общей сложности получается около 3 500 примеров.
Запросы в основном поступают из общедоступных источников, основанных на взаимодействии с людьми, таких как Chatbot Arena и WebGPT. Поскольку они отражают вопросы, которые задают люди в реальной жизни, Auto-J специализируется на реалистичной оценке. Метки как для парных, так и для одиночных ответов генерируются с помощью GPT-4, а фильтры удаляют прогнозы, которые несоответствуют действительности или имеют некорректную форматировку.
Auto-J был доработан на основе LLaMA-2-13B-Chat с использованием этого набора данных смешанного формата. Интересным решением при его проектировании стало отсутствие критериев оценки во входных данных. Причиной этого стало мнение, что модель должна косвенно усваивать эти критерии из данных, что сделает её более универсальной. Однако последующие исследования, в частности Prometheus, пришли к противоположному выводу и обнаружили, что важно включать рубрики оценки и другие справочные материалы в данные, поступающие к модели. Чтобы избежать предвзятости, Auto-J использует простой метод дополнения: каждый парный пример копируется с заменой местами двух ответов, а метки «Ответ 1» и «Ответ 2» в оценке также меняются местами.
Набор тестов Auto-J построен аналогично набору для обучения, за исключением того, что все метки присваиваются людьми-аннотаторами. По сравнению с рядом других моделей Auto-J превосходит почти все из них, за исключением GPT-4. Это подтверждает, что специализированный судья, обученный на данных, соответствующих конкретной области, может сравниться, а иногда и превзойти коммерческие судьи в заданных условиях. Однако его абсолютное согласие с людьми в этом наборе данных по-прежнему низкое, что напоминает о том, что качество судей в целом имеет большой потенциал для улучшения.
Критики, верификаторы и генераторы синтетических данных
Параллельно с этими судьями существует близкосвязанная область исследований, в рамках которой модели обучались проверять, критиковать или давать отзывы на результаты работы другой модели. Как и судьи, эти модели оценивают ответы и объясняют свои решения. Разница заключается в том, что критики и проверщики также принимают меры на основании своих выводов: они корректируют ответ или запускают новую попытку, если первоначальный результат не соответствует стандартам качества.
Хорошим примером является SelFee — модель, основанная на LLaMA и обученная на генерациях ChatGPT, отзывах ChatGPT на них и пересмотренных версиях. Получив ответ, SelFee пишет отзыв, а затем переписывает ответ на основе этого отзыва, продолжая процесс до тех пор, пока результат не достигнет установленного порога качества. Это делает её проверщиком, поскольку она анализирует собственный результат, и критиком, поскольку она пишет отзывы и вносит коррективы.
Было предложено множество других методов оценки, включая метод самокоррекции, модели PEER и модели самокритики. Тот же механизм может генерировать и фильтровать синтетические обучающие данные для SFT или настройки предпочтений, как это делается в RLAIF и Constitutional AI.
Если смотреть издалека, все эти системы — судьи, настроенные под конкретные задачи, пайплайны синтетических данных, инструменты оценки и проверки — по сути выполняют одну и ту же функцию: вычисляют оценку и приводят объяснение. Разница заключается в том, как используется эта оценка: для отчета о качестве модели или для определения того, какие примеры попадут в набор обучения. Недавние исследования генеративных инструментов проверки и моделей наград, основанных на оценке, показывают, что по крайней мере некоторые из этих функций можно объединить в одну модель, которая будет выполнять все задачи по оценке.
Семейство Prometheus: настроенные судьи, конкурирующие с GPT-4
Тонко настроенные оценочные модели стали популярными только с появлением Prometheus — модели, созданной для детальной оценки в узкоспециализированных областях. Её методология не является кардинально новой; главное изменение заключается в более сильной отправной точке, предоставляемой LLaMA-2, и тщательно спроектированном наборе данных. Благодаря тому, что она сопоставлялась по качеству оценок со многими коммерческими моделями, она быстро набрала популярность и породила несколько последующих вариантов.
Prometheus: рубрики как первоклассный входной материал
Для использования коммерческой оценочной модели достаточно просто описать критерии и позволить модели работать. Проблемы заключаются в уже упомянутых неконтролируемой версионности и высоких затратах, а также в том, что эти модели в основном применяются к общим критериям, таким как общие предпочтения людей, и могут испытывать трудности с индивидуальными критериями. Prometheus решает эту проблему с помощью тонко настроенного оценщика, который после обучения в конкретной области может соперничать или даже превосходить коммерческие оценочные модели.
Основная идея заключается в том, что Prometheus принимает в качестве входных данных специальную шкалу оценки, что позволяет ему адаптироваться к новым областям и критериям без повторной настройки. Он обучается на наборе данных Feedback Collection — синтетическом наборе, созданном с использованием GPT-4 и охватывающем множество задач оценки. Каждый пример содержит одинаковые компоненты:
- Инструкция: запрос, предоставляемый оцениваемой модели.
- Ответ: ответ данной модели, который и оценивается.
- Шкала оценки: специальные критерии, определяющие, как следует оценивать ответ.
- Идеальный ответ: пример ответа, который получил бы наивысшую оценку.
- Обоснование: объяснение того, почему ответ получил определенную оценку.
- Оценка: балл от 1 до 5 по шкале Ликерта.
Рубрика состоит из двух частей: общего описания критерия и объяснения того, что означает каждый балл от 1 до 5. Использование таких данных позволяет модели оценивать с высокой степенью детализации и применять этот подход к схемам оценивания, которые ранее не встречались. Исследование Prometheus было одним из первых, показавших, насколько для тщательно подготовленного эксперта полезны обширные источники информации в качестве входных данных, особенно примеры правильных ответов.
Создание рубрик начинается с 50 рубрик, написанных людьми, и проходит в трех этапах:
- GPT-4, увидев примеры ручно написанных рубрик, расширяет их до 1 тысячи рубрик.
- Для каждой рубрики GPT-4 пишет 20 инструкций, в итоге получается 20 тысяч инструкций.
- Для каждой инструкции GPT-4 сначала генерирует ответ, затем обратную связь по нему, а после — балл, в таком порядке.
Два приема балансировки делают данные более полезными. Во-первых, GPT-4 генерирует по пять примеров для обучения на каждое указание, по одному для каждой оценки от 1 до 5, что обеспечивает равномерное распределение оценок и предотвращает ситуацию, когда оценщик склоняется ставить высокие баллы. Во-вторых, эти примеры сохраняются одинаковой длины, чтобы оценщик не развивал предубеждение в пользу более длинных ответов, то есть привычку ставить высокие оценки независимо от содержания.
Prometheus был доработан на основе LLaMA-2-13B-Chat с использованием наборов данных Feedback Collection, а также наборов оценки MT-Bench и Vicuna Bench. Благодаря наличию всего необходимого материала в промпте модель обучается с помощью метода SFT так, что сначала она пишет свою оценку, а уже затем указывает балл. Такой порядок выбран намеренно и соответствует подходу fine-tuning с использованием цепочки мыслей: написанная критика становится контекстом, на котором опирается модель при выборе числа, а не просто обоснованием, добавленным позже. Команда Prometheus также рекомендует использовать специальный токен-разделитель [RESULT] между отзывом и баллом, что предотвращает деградацию качества ответов во время инференса и позволяет легко парсить баллы.
Prometheus сравнивали с GPT-3.5, GPT-4 и несколькими открытыми базовыми моделями на различных наборах данных, оценивая как совпадение с результатами людей, так и полезность его обратной связи. Его показатели достигли корреляции Пирсона 0,897 с оценками людей, что сопоставимо с GPT-4 и значительно превосходит показатели GPT-3.5. Следовательно, модель, отточенная с использованием качественных данных оценки для конкретной области, может достичь или даже превзойти уровень согласованности с оценками людей у гораздо более крупных проприетарных моделей.
Отзывы также подтверждают это. В 58,67% сравнений люди-рецензенты отдали предпочтение отзывам Prometheus перед отзывами GPT-4, а в почти 80% случаев — перед отзывами GPT-3.5. Отвечая на вопрос о причинах, рецензенты указали на то, что Prometheus демонстрирует более критичный и конкретный подход. В статье это обобщается как склонность GPT-4 к нейтральности и абстракции по сравнению с Prometheus, который четко высказывает мнение о том, хорош ли ответ. В этом и заключается преимущество специализации: Prometheus — это не универсальный ассистент, обученный быть согласным со всем, а модель, единственная задача которой — критика.
Prometheus 2: одна модель для точечной и парной оценки
Prometheus 2 продолжает традицию, предлагая ещё один открытый, детализированный оценщик, принимающий пользовательские критерии. Он устраняет два недостатка первой версии: согласованность с оценками людей всё ещё требует улучшений, а что более важно, первый Prometheus мог выполнять только прямую оценку. Ранг можно было определить путём сравнения двух пошаговых оценок, но ни Prometheus, ни большинство более ранних открытых оценщиков не могли напрямую сравнивать два ответа. Prometheus 2 объединяет оба режима в одну модель, которая точно отслеживает показатели как людей, так и GPT-4.
Примеры сравнения в Prometheus 2 отличаются от примеров прямой оценки тремя особенностями:
- В исходном материале отсутствует эталонный ответ.
- Он содержит только описание критерия оценки.
- Формат обратной связи отличается.
В режиме парных сравнений обратная связь должна сопоставлять два ответа, указывать места их различий и использовать эти различия для обоснования выбора одного из них. Большинство ранних наборов данных и моделей для парных сравнений опирались на общие критерии и часто давали простое решение без каких-либо пояснений сравнения.
Для тренировки навыка парных сравнений Prometheus 2 вводит механизм сбора предпочтений, основанный на сборе обратной связи. Поскольку в последнем на каждое задание предоставляется по пять ответов, по одному для каждой оценки, можно сформировать все возможные пары между ними: десять пар на каждое задание. Метка для каждой пары формируется непосредственно путем сравнения двух оценок по шкале Лайкерта.
Поскольку пояснительная обратная связь в стиле последовательного мышления является ключевой частью подхода Prometheus, одних лишь меток было недостаточно. GPT-4 просили писать новую обратную связь для каждой пары, сосредотачиваясь на том, что у двух ответов общего и где они отличаются.
Существует несколько способов получить один судью, который будет обрабатывать оба режима оценки:
- Использование подсказок: применение готовой модели с разными подсказками для каждого режима.
- Обучение в одном формате: обучение отдельной модели для каждого режима и использование той, которая подходит.
- Совместное обучение: обучение одной модели на смеси данных обоих типов.
Только совместное обучение позволяет получить одну специализированную модель, охватывающую оба режима; использование подсказок основано на универсальных моделях, а обучение в одном формате приводит к наличию двух моделей. Четвертый вариант — обучение двух моделей в одном формате, а затем их объединение путем слияния моделей, что и делает Prometheus 2. Два оценщика обучаются отдельно: один — для сбора обратной связи, другой — для сбора предпочтений, после чего их веса объединяются с помощью простого линейного слияния, в результате чего формируется одна модель, способная оценивать данные в любом режиме.
Заметным результатом является то, что объединенная модель превосходит как совместно обученную модель, так и модели одного формата. Было протестировано несколько методов объединения, включая арифметическое сложение моделей, методы TIES и DARE. Более сложные методы иногда помогают; например, при использовании Mixtral 8x7B в качестве основы лучше всего сработал метод DARE. Однако простое линейное объединение с коэффициентом 0,5, заключающееся в простом среднем значении весов двух моделей, показывает хорошие результаты в большинстве конфигураций и очень просто в реализации. Одно из объяснений того, почему это работает, заключается в том, что оба процесса обучения начинаются с одной и той же базовой модели и изучают связанные навыки, поэтому их веса остаются в совместимой области, где среднее значение позволяет сочетать способности вместо того, чтобы уничтожать их.
Prometheus 2 был создан на основе Mistral-7B и Mixtral 8x7B: отдельные версии моделей тонко настраиваются для каждого набора данных, после чего объединяются с использованием различных алгоритмов. Полученные модели превосходят все остальные открытые инструменты оценки в тестах прямой оценки и сравнения пар. Их корреляция по Пирсону с проприетарными инструментами оценки улучшается на 0,2 во всех наборах данных, а в тестах парного ранжирования они сокращают разрыв с GPT-4 примерно вдвое.
В режиме парных сравнений преимущества кажутся меньше, но здесь сравнение включает модели оценки вознаграждений наряду с открытыми инструментами оценки. Модели оценки вознаграждения, используемые в методах обучения с усилением на основе обратной связи от людей (RLHF), тренируются исключительно для определения парных предпочтений, не выдают письменной обратной связи и отличаются высокой точностью в парных сравнениях. Prometheus 2 также демонстрирует лучшую согласованность между режимами, чем другие инструменты оценки: ответ, который он предпочитает в парном сравнении, обычно получает более высокую оценку при прямой оценке. Это свойство имеет большое значение на практике, поскольку судью, чьи оценки в разных режимах расходятся, трудно считать надежным в любом из случаев.
Prometheus-Vision: оценка моделей визуального и языкового обработки
Всё, что было сказано до сих пор, касается моделей, работающих только с текстом. Модели визуального и языкового понимания (VLM), которые принимают как изображения, так и текст, стали распространёнными как в закрытых версиях, таких как GPT-4V и Gemini, так и в открытых версиях, таких как LLaVA и визуальные варианты Llama 3.2. Помимо дополнительной модальности ввода, они обучаются и структурируются примерно так же, как текстовые LLM.
VLM генерирует текст на основе изображения и инструкции, а его оценка добавляет дополнительный аспект. Необходимо проверить два момента:
- Соответствует ли ответ инструкции, как и в случае с любым LLM.
- Основан ли ответ на том, что действительно показано на изображении.
Один из способов решения проблемы — преобразовать изображение в текст с помощью модели для генерации подписей или модели, обрабатывающей изображения и текст, а затем передать полученное описание в специальный инструмент для оценки текста, такой как GPT-4 или Prometheus. Однако подобные многоэтапные процессы усугубляют ошибки: всё, что упускает модель генерации подписей, невозможно оценить. Более прямым подходом является использование VLM в качестве инструмента оценки.
Prometheus-Vision — это открытый инструмент для оценки VLM. Проприетарные VLM, такие как GPT-4V, уже использовались для оценки других VLM, но Prometheus-Vision стал первым открытым инструментом, способным оценивать их по детально определённым критериям, заданным пользователем. Благодаря прозрачности и контролю, характерным для открытых моделей, его результаты хорошо согласуются как с оценками людей, так и с оценками проприетарных инструментов, к тому же он способен распознавать тонкие различия, например отличать настоящее произведение искусства от его пародии.
Когда работа была опубликована, не существовало ни данных обратной связи, критики или предпочтений для обучения детализированному оценщику VLM, поэтому команда создала их сама. Коллекция Perception следует принципам проектирования коллекции Feedback, и каждый экземпляр содержит пять частей входных данных:
- Изображение: картинка, которую пользователь передаёт VLM.
- Инструкция: текстовая инструкция от пользователя.
- Ответ: текстовый ответ VLM на изображение и инструкцию.
- Критерии оценки: подробные рекомендации по ставлению баллов, включая описание критериев и каждого балла по шкале от 1 до 5.
- Идеальный ответ: ответ, который получил бы оценку 5, сгенерированный с помощью GPT-4V.
Результатом являются письменное обоснование и оценка от 1 до 5.
Структура соответствует набору текстовых данных. В процессе берутся 5 тыс. изображений из наборов MS-COCO и MMMU, вручную создаются 50 шаблонов оценок, затем с помощью GPT-4 они расширяются до 15 тыс. шаблонов, генерируются 30 тыс. инструкций с соответствующими эталонными ответами, и в конце к каждой инструкции добавляются пять ответов — по одному на каждую оценку — с комментариями обратной связи. По сравнению с методом сбора обратной связи здесь гораздо больше шаблонов оценок (15 тыс. против 1 тыс.), но значительно меньше инструкций на один шаблон (две против 20).
Здесь нельзя использовать модель только с текстовыми данными; обучение должно начинаться с заранее обученного VLM. Prometheus-Vision использует версии LLaVA-1.5 объемом 7 миллиардов и 13 миллиардов параметров. Методика — тот же финтюнинг с использованием подхода цепочки мыслей, что и раньше: SFT обучает модель писать отзывы, а затем ставить оценки. В каждом примере для обучения эти две части разделены фиксированной фразой So the overall score is, которая выполняет ту же функцию, что и токен [RESULT] в текстовой модели. Благодаря наличию рубрик и эталонных ответов во входных данных получается модель, настроенная для индивидуальной, детализированной оценки.
Prometheus-Vision показывает лучшую корреляцию с оценками людей по сравнению с GPT-3.5-Turbo и простой версией Prometheus, однако GPT-4 и GPT-4V в целом более точно совпадают с оценками людей. Самые слабые результаты у него на тесте VisIT-Bench, где много изображений с большим объемом текста. На этом тесте GPT-4 показывает хорошие результаты, даже лучше, чем GPT-4V, поскольку он получает в качестве входных данных текст, извлеченный из изображения, тогда как Prometheus-Vision с трудом его распознает. На других тестах Prometheus-Vision примерно на одном уровне с GPT-4 и GPT-4V, и в некоторых случаях показывает более сильную корреляцию с оценками людей, чем любой из них.
Людские эксперты оценили качество его ответов примерно на уровне GPT-4 и GPT-4V. Команда также изучала распространённые предвзятости оценщиков, такие как предвзятость по длине — склонность к более длинным ответам, и предвзятость самоусиления — склонность к собственным выводам. Они не обнаружили явных признаков ни того, ни другого, отметив при этом, что экспериментальное выявление отдельной предвзятости действительно сложно.
Другие направления в уточнённой оценке
Prometheus — не единственный подход. Множество других проектов тренировали языковые модели для оценки, каждый из них внося свою уникальную идею. Краткий обзор ниже охватывает наиболее релевантные из них, если вы планируете создать собственный механизм оценки.
Языковые модели с саморегулированием
Модели с саморегулированием направлены на автоматизацию выравнивания с помощью внутреннего оценщика. Вместо того чтобы обучать отдельную модель наград на основе предпочтений людей, сама модель, которую необходимо выровнять, обучается оценивать собственные результаты с использованием вопросов в стиле LLM-as-a-Judge, причем эти оценки служат наградой. Применение этого метода к LLaMA-2 привело к получению полезной обратной связи и улучшению самой модели. Концептуально он похож на Prometheus, поскольку модель учится действовать в роли судьи, но результаты работы этого «судьи» сразу же используются в качестве сигнала для обучения той же модели.
LLM-as-a-Meta-Judge
Ограничением моделей с саморегулируемым вознаграждением является то, что ничто не способствует улучшению самих навыков оценки; модель становится лучше в ответах, но качество её оценок остается на прежнем уровне. Модели с метарегулируемым вознаграждением вводят третью роль. Помимо функций исполнителя и оценщика, модель также выступает в роли метоценщика, который оценивает собственные решения, что позволяет генерировать данные для улучшения как процесса оценки, так и самой стратегии. Обе эти способности улучшаются одновременно на протяжении итераций обучения.
Самообучающиеся оценщики
Самообучающиеся оценщики полностью исключают использование данных о человеческих предпочтениях. Сбор таких данных дорог, к тому же они устаревают по мере совершенствования моделей, поэтому этот подход позволяет итеративно генерировать синтетические данные для оценки. На основе набора инструкций большая языковая модель создает пары противоположных результатов, при этом один из них намеренно делается хуже другого, а оценщик обучается оценивать их, пиша объяснения и вердикты. Повторение этого процесса с улучшенным оценщиком позволяет получать более качественные данные для обучения с каждым раундом. Без каких-либо данных с метками от людей было зафиксировано, что полученные оценщики превосходят как GPT-4, используемый в качестве оценщика, так и модели, обученные на данных человеческих предпочтений, по точности оценок.
Очевидным недостатком является цикличность. Суд, который сам формирует свои данные для обучения, может склоняться к тому, что он уже считает правильным, и без внешнего контроля такое смещение остается незаметным. Даже при использовании цикла самообучения лишь небольшой набор данных с метками, добавленными людьми, остается единственным способом подтвердить, что на каждом этапе действительно происходит улучшение, а не просто растет уверенность.
FLAMe: основные авторитеты
Основные модели больших авторитетов (FLAMe) используют противоположный подход к обработке данных: они обучаются на очень большом количестве человеческих оценок — более 5 млн из них по более чем 100 задачам оценки качества. По сравнению с другими оценщиками модели FLAMe лучше обобщаются на незнакомых задачах оценки, демонстрируют меньше предвзятости и служат надежной отправной точкой для дальнейшей настройки в специализированные оценщики. Было зафиксировано, что они постоянно превосходят оценщиков, созданных на основе вариантов GPT-4 и Claude с использованием подсказок, а также оценщиков, настроенных на синтетических данных GPT-4.
Компромисс между обобщаемостью и точностью
Эмпирическое исследование специально настроенных судей, название которого прямо гласит о выводе о том, что «модели судей, пройдшие доработку, являются классификаторами, адаптированными к конкретным задачам», подробно рассмотрело преимущества и недостатки таких моделей по сравнению с проприетарными алгоритмами. Вывод исследования: специально настроенные судьи отлично справляются с задачами внутри своей области применения, иногда превосходя GPT-4 в тестовых наборах, сгенерированных на основе их обучающих данных, однако уступают GPT-4 в способности к обобщению, справедливости оценок, оценке по конкретным аспектам и масштабируемости. Это неудивительно — судья, обученный на определённых данных, усваивает именно эти данные; если задать ему вопросы по другой теме, он будет вести себя как узкий классификатор. Практический вывод заключается в том, что специально настроенного судью следует использовать только для тех задач, для которых он был обучен, а также периодически повторно проверять его с помощью человеческих меток, когда входные данные начинают отклоняться.
Оптимизация предпочтений при прямом суждении
Оптимизация предпочтений на основе прямого суждения применяет метод оптимизации предпочтений к оценщикам, а не только к SFT. Пары предпочтений собираются для трех случаев использования: однократная оценка, парное сравнение и бинарная классификация. Первые два соответствуют обычным подходам с точечной оценкой и парным сравнением; третий рассматривает оценку как вопрос «да/нет», например, существует ли та или иная характеристика в ответе. Также добавляется вспомогательная задача: на основе инструкции и результата оценки модель должна определить, какой ответ подвергался оценке. Для каждого случая использования хорошее и плохое суждение образуют пару предпочтений, и оценщик тренируется с использованием метода прямой оптимизации предпочтений (DPO). Преимущество заключается в том, что оценщик учится не только имитировать хорошие суждения, но и отдавать им предпочтение перед правдоподобными плохими.
Что влияет на оценки судьи?
Уместный вопрос относительно любого судьи на основе больших языковых моделей заключается в том, действительно ли он применяет указанные критерии или просто награждает тексты, похожие на данные его обучения. Анализы судей на основе больших языковых моделей в различных системах оценки показали, что подробные инструкции по оценке в промпте улучшают их суждения лишь незначительно, а оценка на основе понятности, при которой ответ оценивается по степени вероятности его обнаружения моделью, иногда лучше соответствует человеческим оценкам, чем использование промптов, особенно в отношении качества текста.
Это кажется противоречащим выводам Prometheus о том, что исходные материалы имеют огромное значение. Эти два результата легче согласовать, когда понимаешь, что именно измерялось. Анализы, ориентированные на понятность, сосредотачиваются в основном на общем качестве ответов с точки зрения предпочтений людей. Большинство больших языковых моделей обучаются с использованием данных о предпочтениях, поэтому естественно, что они придают высокую вероятность ответам, которые нравятся людям. Prometheus, в отличие от этого, ориентируется на широкий спектр пользовательских критериев, выходящих за рамки обычных предпочтений, и для них четкие критерии оценки содержат информацию, которую модель не может получить только на основе плавности изложения. Если ваши критерии близки к вопросу «Какой ответ нравится людям больше», критерии оценки могут добавить немного; если же они специфичны для вашей области, они становятся необходимыми.
Пошаговая инструкция по созданию собственного оценщика
Учитывая ситуацию в области исследований, полезно представить этот процесс в виде четкой последовательности действий. Работа Prometheus уже содержит набросок такой структуры, а приведенная ниже версия незначительно ее модифицирует с учетом выводов других исследований.
Шаг 1: определение критериев оценки
Прежде чем что-либо делать, точно определите, что именно вы собираетесь оценивать:
- Составьте список конкретных критериев, важных для вашего приложения.
- Напишите подробное описание каждого критерия, включая значение каждого уровня оценки.
Примером такой шкалы оценки может служить раздел сбора обратной связи, где приводятся описания критериев, описание значений для каждой оценки и эталонные ответы. Ожидайте, что критерии придется пересматривать неоднократно. По мере выявления различий во мнениях людей и моделей вы будете совершенствовать и расширять эту шкалу, причем каждая корректировка делает оценку как людьми, так и моделями более согласованной.
Шаг 2: сбор высококачественных человеческих меток
Перед обучением или даже использованием любого судьи вам необходимы надежные данные человеческой оценки. Именно они позволяют определить, насколько точен судья, и должны отражать данные, с которыми он будет сталкиваться в реальных условиях. Если данные предназначены только для метаоценки, например для проверки судьи в формате LLM-as-Judge, обычно достаточно небольшого набора примеров в количестве от 100 до 1 тыс. единиц. Для доработки судьи в стиле Prometheus требуется гораздо больше данных — от 1 тыс. до 100 тыс. примеров.
Сбор данных от людей — сложная задача, и именно здесь команды чаще всего недоинвестируют. Если у участников нет единого мнения относительно задания, невозможно определить, хорошо ли справляется с ней модель, а обучение оценщика на несогласованных метках тратит все усилия впустую. Здесь применимы все правила, описанные выше в разделе оценки человеком: калибруйте оценщиков, соблюдайте руководящие принципы и продолжайте измерять степень согласованности.
Шаг 3: дополнение синтетическими данными
Модели Prometheus демонстрируют, что синтетические данные могут обеспечить качественные результаты: почти весь их тренировочный материал, включая инструкции, ответы, оценки и обратную связь, был сгенерирован GPT-4. Чисто синтетические данные несут риски, поскольку ограничивают возможности модели небольшим набором входных данных и унаследовывают предвзятости модели-учителя. Сочетание данных с ручными метками и синтетических данных обычно дает гораздо лучшие результаты, чем использование любого из них в одиночку. Используйте данные с ручными метками для обеспечения качества, а синтетические — для достижения необходимого объема и охвата при финальной настройке; применяйте также принципы сбалансированности из раздела Сбор обратной связи, такие как равномерное распределение оценок и контролируемая длина ответов, при их генерации.
Шаг 4: сосредоточьтесь на обоснованиях
Конечно, необходимы точные оценки и рейтинги, но обоснования заслуживают не меньшего внимания. Известно, что тонкая настройка — это плохой способ внедрения новых знаний в модель; она хорошо справляется лишь с обучением стилю и формату. Для рецензента основным элементом, который он может контролировать, является формат обратной связи. Конкретные, критические и соответствующие критериям оценки обоснования позволяют получить такие объяснения рецензента, которые действительно полезны, и поскольку модель пишет обоснования перед оценкой, лучшие обоснования, как правило, способствуют получению лучших оценок. Разместите фиксированный разделитель между обратной связью и оценкой, чтобы результаты было легко парсить.
Шаг 5: добавляйте эталонные ответы там, где это возможно
Этот шаг является необязательным, но обычно полезным. Ориентировочные ответы помогают как судьям, получившим задание, так и тем, кто занимается их доработкой. Для судей, чьи модели были доработаны, они помогают устранить предвзятость в знаниях, заполняя пробелы в том, что базовая модель выучила во время предварительной обучения, и делают оценку по отдельным пунктам значительно более точной и стабильной. При выполнении задач, требующих фактических знаний или глубокого понимания конкретной области, ориентировочный ответ часто имеет большее значение, чем формулировка самого запроса.
Шаг 6: обучение и метаоценка
После того как будут загружены данные, а также, по желанию, эталонные ответы, обучите судью с помощью стандартного метода SFT. В репозитории Prometheus представлена полная реализация этого процесса. С самого начала отложите тестовую выборку данных с метками, добавленными людьми, и используйте её для метаоценки: показатели классификации, если результат судьи бинарный, и показатели корреляции для всех остальных случаев. Для пар судей также измеряйте частоту того, сохраняется ли вердикт при смене порядка; судья, чей вердикт меняется при изменении порядка, ещё не готов к работе.
Прежде чем полагаться на судью, выполните несколько дополнительных проверок:
- Оцените его работу на примерах, не относящихся к данной категории, чтобы понять пределы его компетентности.
- Сравните распределение его оценок с распределением оценок людей, чтобы выявить систематическую снисходительность или строгость.
- Напрямую изучите эффекты длины и порядка, изменяя длину ответа и порядок обработки одного и того же контента.
Когда не стоит использовать тонкую настройку
Тонко настроенный оценщик не всегда является подходящим инструментом. Если ваши критерии общего характера, такие как общая полезность, достаточно может быть хорошо настроенного проприетарного оценщика или существующего открытого инструмента оценки, который будет гораздо дешевле в настройке. Если вы не можете собрать надежный набор данных с метками от людей, вы не сможете проверить ни одного оценщика, независимо от того, был ли он тонко настроен или нет, поэтому сначала решите эту проблему. Кроме того, если распределение задач постоянно меняется, специфика оценщиков, настроенных под конкретные задачи, означает, что вам придется часто перенастраивать их. Тонкая настройка оправдывает себя тогда, когда критерии специализированы, объем оценки велик, и вам необходим контроль над версионированием, затратами или конфиденциальностью данных.
Замечание о затратах и операциях
Использование специального судьи лишь переносит затраты, а не устраняет их. Вы обмениваете плату за использование API за каждый запрос на время работы GPU, хостинг модели и инженерные ресурсы, необходимые для поддержания версионности и воспроизводимости судьи. Взамен вы получаете фиксированную версию модели, которая не может измениться без вашего участия, данные оценки, которые никогда не покидают вашу инфраструктуру, и возможность выполнять миллионы оценок без роста счетов. Относитесь к судье как к любой другой производственной модели: фиксируйте её веса, записывайте, какая версия дала те или иные результаты, и храните набор мета-оценок, чтобы в будущем можно было сравнивать процесс переобучения с текущим на равных условиях.
Основные выводы
- Человеческие оценки по-прежнему являются эталоном, но только после калибровки, соблюдения действующих руководящих принципов и постоянного отслеживания согласований они становятся достаточно надежными для сравнения чего-либо с ними.