Жизненный цикл LLM в роли судьи: разработка, выравнивание и мониторинг в больших масштабах04.09.2026 19:01

Авторы: Эмма Янъян Конг, Джей Джей Тан, Ишан Гупта, Ларс Олдс, Клэр Кэмпбелл, Дэвид Фагнан, Ратна Кавури, Рохан Госайн, Вели Балин, Минсу Джанг, Луи Гарсия

Введение

Любая команда, генерирующая текст с помощью языковых моделей (LLM) в больших масштабах, сталкивается с одной и той же проблемой. Вы не можете оценивать всё вручную. Вы не знаете, какие результаты выдачи великолепны, какие — посредственны, а какие — вредны, потому что физически не в состоянии прочитать их все. Стандартным решением является подход LLM-as-a-Judge («LLM в роли судьи»), когда вторая модель оценивает результат работы первой модели в качестве прокси-заменителя экспертов-людей. Это быстро, дешево и легко развернуть. Однако это порождает новый и критически важный вопрос: Кто оценивает самого судью? Более того, если судья начинает «дрейфовать», незаметно деградировать и одобрять некачественные результаты, ничто на последующих этапах это не зафиксирует.

Эта статья посвящена тому, как мы решаем эту проблему путем создания, выравнивания и непрерывного мониторинга LLM-судей, чтобы они оставались надежными с течением времени. Наш главный принцип прост: LLM-судья никогда не должен работать в одиночку. Он должен опираться на человеческое суждение. Мы сохраняем принцип человека в контуре (human-in-the-loop, HITL) на каждом этапе жизненного цикла. Люди определяют, что означает «хорошо», создают размеченные эталонные датасеты для обучения и валидации судьи, отслеживают его поведение во время работы в системе, а также проверяют и утверждают любые обновления перед их внедрением.

Мы убеждены:

Надежный LLM-судья — это не статический артефакт. У него есть свой жизненный цикл.

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

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

Забавная и трогательная праздничная мелодрама о любви и новых начинаниях, во многом похожая на «Моего тайного Санту».

Качество здесь имеет критическое значение, поскольку вводящее в заблуждение или плохо обоснованное объяснение подрывает то самое доверие, для формирования которого оно и предназначено.

Всё, о чем пойдет речь далее, является результатом серии контролируемых онлайн-экспериментов с участием пользователей, которые мы провели для функции объяснений, включая месячный эксперимент в мобильном приложении Netflix. В этих тестах мы использовали LLM для генерации объяснений (сотни тысяч в неделю в условиях постоянно меняющегося каталога). Ручной просмотр в таком масштабе невозможен, поэтому мы развернули вторую LLM для их оценки.

Понятие качественного объяснения специфично для нашей задачи. Тем не менее, подход к созданию, выравниванию и мониторингу LLM-судьи для оценки таких объяснений должен быть универсальным и применимым к самым разным задачам.

Жизненный цикл вкратце

На рисунке 1 обобщены четыре фазы жизненного цикла нашего LLM-судьи и поток данных между ними.

Рисунок 1. Четыре фазы жизненного цикла LLM-судьи и потоки данных между ними.

Мы начинаем с рождения (создание эталонного датасета), на этапе которого эксперты-люди создают сложные или пограничные примеры, а ассистенты размечают их решениями о прохождении (pass/fail) с текстовыми обоснованиями. Мы дополняем этот набор сгенерированными LLM примерами из «серых зон», чтобы сформировать более богатый бенчмарк.

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

На третьем этапе, развертывании, мы интегрируем судью в систему генерации объяснений как в качестве фильтра (gate), так и в качестве критика. Генератор LLM пишет объяснения, а LLM-судья оценивает их и либо пропускает дальше, либо блокирует, предоставляя обоснование, которое генератор может использовать для самосовершенствования и повторных попыток. Успешно пройденные объяснения показываются пользователям, а низкокачественные блокируются.

Наконец, на последнем этапе, выравнивании при участии человека и мониторинге дрейфа (HITL), мы поддерживаем согласованность судьи с людьми с течением времени. Принцип «человек в контуре» здесь означает, что человек напрямую вовлечен в принятие решений, а не просто изучает результаты постфактум. Мы проводим бенчмаркинг судьи по сравнению с обученными оценщиками, и человек одобряет каждое изменение перед его выкатыванием в систему. Во время каждого теста мы еженедельно отбирали набор объяснений (как прошедших, так и заблокированных, с акцентом на более новый контент), привлекали оценщиков-людей для их проверки с выставлением меток и обоснований, а затем сравнивали оценки судьи с оценками людей. Если дрейф превышал пороговое значение, мы запускали повторное обучение и дополнение бенчмарк-данных. Это замыкает цикл, возвращая новые размеченные людьми данные и обновленные сигналы обратно на этапы бенчмаркинга и разработки.

Компоненты системы

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

• Генератор: создает текст объяснения, при необходимости используя прошлые обоснования судьи и трассировки в своем промпте для доработки.
• Судья: оценивает объяснение и возвращает метку прохождения (pass/fail) вместе с письменным обоснованием. В развернутом пайплайне он выступает одновременно как защитный барьер (отсеивающий плохие результаты) и как критик (предоставляющий обратную связь для самосовершенствования).
• Рефлектор: пересматривает рубрикатор судьи, когда тот совершает ошибки. Он обновляет рубрикатор на основе несоответствующих примеров, человеческих обоснований и опорных примеров. Он настраивает рубрикатор и не оценивает объяснения напрямую.
• Мета-судья: проверяет, отклонил ли судья объяснение по правильной причине, сравнивая обоснование судьи с обоснованием оценщика-человека.
• Эксперты и оценщики-люди: эксперты, которые определяют критерии качества; оценщики, по меткам и письменным обоснованиям которых настраивается и измеряется судья; рецензенты, которые контролируют судью во время его работы и явно одобряют любые изменения до их выкатывания в продакшн.

Фаза I, Рождение: Создание эталона (Ground Truth)

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

Почему мы создали собственный бенчмарк

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

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

Две важные детали

• Бенчмарк не является статичным. Мониторинговый пайплайн (Фаза IV) еженедельно добавляет новую порцию оцененных людьми объяснений, поэтому в ходе теста бенчмарк отслеживал текущий каталог и новые паттерны использования, а не устаревал.
• Каждая метка «непрохождение» (fail) сопровождается текстовым обоснованием, объясняющим, почему объяснение не прошло проверку. На первый взгляд это незначительная деталь учета, но на самом деле она критически важна для следующего фазы, поскольку именно эти обоснования мы используем для настройки и аудита логики судьи.

Фаза II, Обучение: Выравнивание судьи по людям

Тип сбоя: правильный ответ, неверная причина

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

Поэтому для нас важна не только согласованность меток, но и согласованность рассуждений (reasoning alignment). В нашей системе судью всегда просят выдать:

• метку (например, PASS / FAIL — ПРОШЛО / НЕ ПРОШЛО), и
• короткое обоснование на естественном языке для этой метки.

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

Метка (FAIL) верна, и указанная причина на первый взгляд кажется разумной. Но она оказывается неполной таким образом, который простая проверка согласованности меток обнаружить не может, как мы покажем ниже.

Настройка рубрикатора с учетом согласованности рассуждений (RART)

Мы настраиваем LLM-судью для каждого критерия с помощью процедуры, которую называем Reasoning-Aligned Rubric Tuning (RART). Как упоминалось в разделе системных компонентов выше, Судья, Мета-судья и Рефлектор являются отдельными компонентами. Судья оценивает объяснение по рубрикатору и дает обоснование, Мета-судья сравнивает это обоснование с написанным человеком, а Рефлектор редактирует сам текст рубрикатора. RART — это метод объединения всех трех компонентов в обучающий цикл.

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

R_i — текущий текст рубрикатора, y_J (x) — метка, r_J (x) — обоснование.

На высоком уровне каждая итерация RART выглядит следующим образом.

1. Оценка обучающих данных с помощью текущего рубрикатора.
2. Оценка взвешенных метрик соответствия на отложенном (held-out) валидационном наборе. Если все метрики по каждому из критериев превышают пороговые значения, процесс останавливается.
3. В противном случае формируется управляемый ошибками фокусный набор примеров с расхождениями, который передается Рефлектору, предлагающему пересмотренный рубрикатор.

Ключевое отличие от стандартного цикла заключается в том, как мы определяем «ошибку». Большинство циклов самосовершенствования рассматривают только расхождения в метках. RART добавляет второй класс ошибок. Мета-судья изучает случаи, когда и судья, и человек оба сказали «не прошел», и сравнивает заявленную судьей причину с обоснованием человека. Когда они расходятся, это ошибка из категории «правильный ответ, неверная причина», и она также передается Рефлектору. Конкретно, фокусный набор, передаваемый Рефлектору, представляет собой объединение двух классов ошибок:

• Несоответствия меток: примеры, где метка судьи отличается от метки человека.
• Правильная метка, неверная причина: примеры, где и судья, и человек выдали FAIL, но Мета-судья обнаруживает, что их обоснования не совпадают.

Таким образом, Рефлектор пересматривает рубрикатор на основе обоих типов ошибок: обычных ошибок в метках и ошибок типа «правильная метка, неверная причина». Этот второй компонент лежит в основе RART. Судью подталкивают не просто к совпадению с человеческими решениями, но к их обоснованию таким образом, который Мета-судья признает соответствующим человеческой логике рассуждений.

Возвращаясь к предыдущему примеру, LLM-судья вынес вердикт FAIL, и человек вынес FAIL, поэтому простая проверка только меток зафиксировала бы согласие. Сопоставление двух причин бок о бок показывает, что именно такая проверка упускает.

RART направляет этот кейс в фокусный набор, поэтому следующее обновление рубрикатора должно учитывать его.

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

Метрики согласованности

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

• Специфичность (полнота обнаружения сбоев, fail-recall): как часто судья корректно отклоняет плохие объяснения. Это то, о чем мы заботимся больше всего, поскольку проскочившее сквозь фильтр плохое объяснение бьет по доверию.
• Полнота (pass-recall): как часто он корректно пропускает хорошие объяснения, что поддерживает высокую пропускную способность и низкие затраты на доработку.
• Согласованность рассуждений: для отклоненных обоими объяснений — как часто они отвергаются по одной и той же причине.

У судьи каждого критерия есть свои собственные три метрики, и одна из них может быть в норме, пока другая проседает. Именно поэтому фильтр строг. Объяснение должно пройти каждый обязательный критерий, чтобы его можно было использовать.

Абляционное исследование: помогает ли сигнал рассуждений?

Чтобы изолировать влияние сигнала рассуждений, мы сравниваем RART с в остальном идентичным циклом, который использует только несоответствия меток. Мы называем этот бейзлайн vanilla (базовый): тот же Рефлектор, тот же Судья, те же данные, но без Мета-судьи и без использования человеческих обоснований.

Рисунок 2. Улучшение по сравнению с исходным рубрикатором для каждого критерия при настройке с учетом рассуждений (RART) и настройке только по меткам (vanilla).

На рисунке 2 показан результат. По двум из трех обязательных критериев vanilla и RART приходят к одному и тому же результату, поскольку исходный рубрикатор уже был близок к потолку, и у метрик было очень мало пространства для роста. По третьему критерию метод vanilla (только по меткам) деградирует. Рефлектор в базовом цикле переписывает рубрикатор в дегенеративные формы, а специфичность и согласованность рассуждений падают с каждой итерацией, оказываясь хуже исходного рубрикатора. RART остается стабильным по тому же критерию и улучшает оба показателя, демонстрируя при этом небольшой прирост полноты. Причина заключается в том, что оптимизатор на основе только меток может прийти к правильной метке через неверные рассуждения, а неверные рассуждения не масштабируются на новые данные. Опора сигнала на обоснование предотвращает это. Выравнивание по рассуждениям помогает там, где есть потенциал для роста, и не вредит там, где его нет.

Фаза III, Развертывание: Судья в деле

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

Две роли для одного судьи

Как только мы выравниваем LLM-судью по людям, мы используем его повторно в двух различных ролях для каждого сгенерированного объяснения:

• Роль 1, фильтр (gate). Судья оценивает каждое объяснение по обязательным критериям и отклоняет всё, что не проходит проверку.
• Роль 2, критик. Когда объяснение не проходит проверку, мы не просто выбрасываем его. Текст причины от судьи добавляется к промпту генератора, и генератор делает новую попытку.

Вторая роль превращает пайплайн в цикл генерация → оценка судьей → доработка, где критика судьи направляет каждую итерацию.

Ограниченные попытки и причина отбрасывания вместо показа

Мы ограничиваем количество повторных попыток. Каждая итерация требует дополнительных затрат вычислительных ресурсов на генерацию и оценку, а прирост быстро сходит на нет. На рисунке 3 показано, что на самом деле дает этот цикл для 1,000 сгенерированных объяснений, прошедших до 12 итераций с четырьмя генераторами. Каждая кривая ползет вверх, что доказывает эффективность критики судьи, но крутой подъем происходит на раннем этапе, а разрыв между генераторами очевиден. Итерация усиливает способный генератор, а не спасает слабый. В наших тестовых прогонах мы использовали бюджет в 3 попытки с нашим сильнейшим генератором, и если объяснение все равно не проходило проверку после этого, оно отбрасывалось, а не показывалось пользователю.

Рисунок 3. Совокупная доля объяснений, прошедших проверку судьей по мере увеличения числа итераций, для четырех моделей-генераторов.

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

Помогают ли одобренные судьей объяснения пользователям?

Успешное прохождение проверки судьей доказывает, что объяснение является хорошим по нашим меркам, но это не доказывает, что одобренные судьей объяснения полезны для пользователей. Чтобы проверить эту связь, мы провели разовый контролируемый эксперимент в мобильном приложении Netflix: сравнили вариант с объяснениями и без них на странице с подробной информацией о контенте в течение примерно месяца. За этот период пайплайн генерировал и оценивал сотни тысяч объяснений в неделю.

Пользователи, видевшие объяснения, перенаправляли свои просмотры на те названия, которые они раньше не смотрели, и больший процент их сессий просмотра завершался осознанным воспроизведением контента. Оба эффекта были статистически значимыми, и за время теста мы не зафиксировали ни одного инициированного пользователями удаления или жалобы на качество объяснений. Результат, который стоит вынести из этого, заключается вовсе не в размере эффекта. Дело в том, что офлайн-согласованность с нашими оценщиками была необходима для того, чтобы эти объяснения работали, но никогда не была достаточной для доказательства их пользы для пользователей. Только онлайн А/Б-тест смог подтвердить, что выравненные по судье объяснения не просто соответствуют требованиям качества, но и действительно полезны.

Фаза IV, Мониторинг: Поддержание согласованности судьи

Судья, отлично выровненный на момент запуска, не останется таковым навсегда. Каталог меняется, как и то, что считается высоким качеством. Жизненный цикл должен замыкать кольцо обратной связи.

Еженедельный обзор с участием людей

Каждую неделю работы теста мы отбирали примерно 300 сгенерированных объяснений для экспертной оценки людьми. Выборка стратифицировалась по решениям судьи (показано, доработано, отброшено) с акцентом на более новые элементы каталога, где дрейф наиболее вероятен. Стратификация оставалась неизменной из недели в неделю, поэтому последовательные недели были сопоставимы. Панель, состоящая как минимум из трех оценщиков, проверяла каждое объяснение, а мажоритарная метка принималась за эталон (ground truth). Эти метки выполняли две задачи: они показывали нам, не снижается ли согласие между судьей и людьми, и пополняли бенчмарк.

Установка планки с помощью человеческих разногласий

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

Возьмем один критерий и одну из его метрик, M. Выборка этой недели дает одно значение M (J) для судьи и набор значений M (H) для каждого из трех или более оценщиков панели. Мы требуем, чтобы

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

Падение ниже допустимого диапазона по любой паре метрика-критерий считается событием дрейфа, которое запускает повторное обучение (возврат к Фазе II) на расширенном бенчмарке. Перенастроенный рубрикатор никогда не переходит в продакшн автоматически. Кто-то из команды изучает предложенные изменения и подписывает их перед отправкой в работающий конвейер, при этом мы сохраняем предыдущий рубрикатор для мгновенного отката.

Что выявляет ручная проверка, чего не могут метрики

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

В ходе еженедельного процесса рецензенты выявляли проблемы, которые не отражались в метриках согласия судьи и оценщиков. Объяснение может использовать точные атрибуты и при этом преувеличивать степень реального сходства двух произведений. Одиночное расплывчатое прилагательное («захватывающий», «веселый», «эмоциональный») может технически удовлетворять рубрикатору, не говоря при этом практически ничего. Иногда проблемой становится само эталонное произведение — то, которое пользователь вообще не стал бы считать сопоставимым названием, поэтому сравнение выглядит странно, как бы ни выстраивались атрибуты. Некоторые жанры демонстрируют ту же проблему в масштабе. Стендап-выступления могут иметь схожие теги метаданных, но совершенно различаться по тону и культурному контексту, поэтому сравнение может выглядеть обоснованным на бумаге, быть не настолько плохим, чтобы получить от оценщика FAIL, и при этом неудачно восприниматься пользователями. А некоторые объяснения отвечают абсолютно всем обязательным критериям и при этом читаются как бессвязный набор слов («word soup»), который не сильно помогает пользователю.

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

Обнаружение дрейфа фиксирует момент, когда судья перестал соглашаться с людьми. Только непрерывное экспертное ревью подсказывает нам, когда наше определение «хорошего объяснения» оказывается слишком узким или неполным. Нам нужны оба подхода.

• Обнаружение дрейфа поддерживает согласованность судьи с текущим рубрикатором.
• Непрерывное экспертное ревью поддерживает согласованность рубрикатора с тем, что действительно работает для пользователей.

Чему мы научились

Пять выводов, которые, на наш взгляд, применимы к любой команде, запускающей LLM-судью:

1. Инвестируйте в бенчмарк до создания судьи. Скромный бенчмарк с аннотированными обоснованиями превосходит крупный набор данных, содержащий только метки. Именно эти записанные обоснования делают возможной настройку с учетом согласованности рассуждений. Вы не сможете исправить логику судьи, если никогда не фиксировали рассуждения человека.
2. Настраивайте на основе рассуждений, а не только меток. Судья может прийти к правильному вердикту по неверной причине, что хорошо выглядит на дашборде, но дает вводящую в заблуждение обратную связь и не выдерживает проверки на новых данных. В нашем абляционном исследовании цикл настройки только по меткам ухудшил рубрикатор, который цикл с учетом согласованности рассуждений сохранил стабильным.
3. Один выровненный судья может выполнять множество ролей. Повторное использование одного и того же судьи как в качестве фильтра, так и в качестве критика амортизирует затраты на выравнивание и обеспечивает согласованность поведения в продакшене для разных ролей. Выравнивание — самая дорогая часть, поэтому сделайте одного судью правильно и используйте его больше одного раза.
4. Планируйте мониторинг с первого дня. Элементы и пользователи рекомендательной платформы не перестают меняться, поэтому LLM-судья, как и любая модель машинного обучения, требует наблюдения и перенастройки при необходимости, а не просто разового запуска с последующим забвением.
5. Включайте людей в контур по замыслу, а не в качестве исключения. Автоматизация оценки не означает делегирование ответственности за нее. В нашем жизненном цикле люди задают стандарты (Фаза I), предоставляют обоснования, по которым выравнивается судья (Фаза II), принимают консервативное решение отбрасывать сомнительные результаты вместо их показа (Фаза III), а также проверяют постоянную выборку живых решений и одобряют любые изменения рубрикатора перед их выкатыванием в продакшн (Фаза IV). Эти контрольные точки гораздо сложнее внедрить задним числом, когда судья уже принимает решения самостоятельно. Постоянное ревью также показывает нам, чего не хватает нашему рубрикатору, а не только то, когда судья начал ошибаться.

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

Благодарности

Эта статья обобщает нашу исследовательскую работу «Жизненный цикл LLM-в-роли-судьи для крупномасштабных объяснений рекомендаций» (The Lifecycle of LLM-as-a-Judge for Large-Scale Recommendation Explanations), в которой представлена полная методология, метрики и абляционные исследования.

Мы выражаем признательность внутренним авторам текста и экспертам по ревью, которые определили, что такое хорошее объяснение, и поддерживают эти инструкции в актуальном состоянии; нашей команде Human Data Operations и обучаемым ими оценщикам, чьи метки и письменные обоснования служат ориентиром для настройки судей; инженерам всей команды, которые создали и обслуживают пайплайн;, а также нашим партнерам по UI-инженерии, которые создали ориентированные на пользователей интерфейсы, доставляющие эти объяснения на главную страницу.

© Netflix Tech Blog