Жизненный цикл LLM-as-a-Judge: разработка, согласование и мониторинг в масштабе04.09.2026 19:01

[не удалось получить полный текст]

Авторы: Emma Yanyang Kong, JJ Tan, Ishan Gupta, Lars Olds, Claire Campbell, David Fagnan, Ratna Kavuri, Rohan Gosain, Veli Balin, Minsu Jang, Louis Garcia

Введение

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

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

Мы убеждены:

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

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

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

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

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

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

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

Жизненный цикл в общих чертах

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

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

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

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

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

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

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

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

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

Фаза I. Рождение: определение эталонных оценок

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

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

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

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

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

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

Фаза II. Обучение: согласование судьи с людьми

Тип ошибки: верный ответ, неверная причина

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

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

• метку (например, PASS/FAIL); и
• краткое обоснование на естественном языке для этой метки.

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

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

Настройка критериев с учётом рассуждений

Для настройки LLM-судьи по каждому критерию мы используем процедуру под названием настройка критериев с учётом рассуждений (RART). Как было сказано выше в описании компонентов системы, судья, метасудья и рефлексор — отдельные компоненты. Судья оценивает объяснение по заданным критериям и приводит обоснование, метасудья сравнивает это обоснование с написанным человеком, а рефлексор редактирует сами критерии. RART объединяет эти три компонента в цикл обучения.

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

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

В общих чертах каждая итерация RART проходит так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фаза III. Развёртывание: применение судьи на практике

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

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

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

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

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

Ограниченное число повторных попыток: почему мы отбрасываем, а не показываем

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

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

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

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

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

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

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

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

Еженедельная проверка людьми

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

Порог с учётом расхождений между людьми

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

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

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

Выход за пределы диапазона по любой паре «метрика — критерий» считается событием дрейфа и запускает повторную настройку (возврат к фазе II) на дополненном контрольном наборе. Перенастроенные критерии никогда не внедряются автоматически. Кто-то из команды изучает предложенные изменения и одобряет их до того, как они попадут в работающий конвейер; предыдущие критерии сохраняются для мгновенного отката.

Что выявляет проверка людьми, но не метрики

Еженедельная проверка отвечает не только на вопрос, согласуется ли судья по-прежнему с оценщиками. Она помогает ответить и на второй: всё ли ещё требуют от него действующие инструкции?

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

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

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

• Мониторинг дрейфа помогает судье соответствовать актуальным критериям.
• Постоянная проверка людьми помогает критериям соответствовать тому, что действительно полезно пользователям.

Наши выводы

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

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

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

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

В этой статье кратко изложена наша исследовательская работа »Жизненный цикл LLM в роли судьи: создание, настройка и мониторинг объяснений рекомендаций в большом масштабе, » в которой подробно описаны методология, метрики и абляционные эксперименты.

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

Жизненный цикл LLM в роли судьи: создание, настройка и мониторинг в большом масштабе впервые опубликована в Netflix TechBlog на Medium, где читатели продолжают обсуждение этой истории, отмечая её фрагменты и отвечая на них.

© Netflix Tech Blog