LLM-судья: как LLM отсекает правду от лжи?

Оценивать сгенерированные тексты сложно, будь то «простой» саммари или диалог с чат-ботом. Метрики типа accuracy плохо работают, поскольку «правильный» ответ может быть сформулирован множеством способов, не обязательно совпадающих с образцом. Кроме того, стиль или тон — субъективные характеристики, которые сложно формализовать.

Люди способны учитывать такие нюансы, но ручная проверка каждого ответа плохо масштабируется. В качестве альтернативы появилась техника LLM-as-a-judge: для оценки сгенерированных текстов используются сами LLM. Интересно, что LLM одновременно являются и источником проблемы, и её решением!

В этой статье мы рассмотрим:

• Как работает LLM-as-a-judge и почему этот метод эффективен.
• Типы LLM-судей для офлайн- и онлайн-оценки.
• Как создать оценщик на основе LLM и грамотно составить промпт.
• Плюсы, минусы и альтернативы использования LLM для оценки.

Хотя существует много качественных исследований на эту тему (мы приведем некоторые из них), данное руководство носит прежде всего практический характер. Оно предназначено для всех, кто занимается разработкой продуктов на основе LLM и размышляет, подойдет ли им этот подход.

Коротко: LLM-as-a-Judge — это подход, при котором LLM используются для оценки текстов, сгенерированных ИИ, на основе пользовательских критериев, заданных в оценочном промпте.

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

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

LLM-as-a-judge — это метод оценки, который подходит для всех этих сценариев. Его идея проста: попросите LLM «оценить» текстовые ответы, используя критерии, которые вы определяете сами.

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

• Вежливость: является ли ответ уважительным и тактичным?
• Предвзятость (Bias): проявляется ли в ответе предубеждение к определенной группе?
• Тон: является ли тон формальным, дружелюбным или разговорным?
• Сентимент (Sentiment): положительные, отрицательные или нейтральные эмоции выражены в тексте?
• Галлюцинации: соответствует ли ответ заданному контексту?

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

Главное преимущество подхода — автоматическая оценка текстовых ответов с учетом индивидуальных критериев, специфичных именно для вашей задачи.

Например, вы можете указать LLM оценивать, насколько полезны ответы вашего чат-бота. (Примечание: все промпты в этом руководстве приводятся только для иллюстрации).

Упрощённый промпт: «Даны ВОПРОС и ОТВЕТ. Оцени, полезен ли данный ответ. Полезные ответы ясные, релевантные и дают возможность действовать. Неполезные ответы расплывчаты, не по теме или недостаточно детализированы. Верни метку: 'полезный' или 'неполезный'.»

Если вы запустите его на ответах вашего чат-бота, LLM-судья выставит оценку каждому ответу.

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

Речь идёт не только о разовом анализе: такие оценки можно проводить непрерывно на реальных данных. Это позволит отслеживать, насколько хорошо работает чат-бот, и оперативно выявлять проблемы, например, резкий рост «неполезных» ответов.

Хотите оценить другие свойства ответов? Просто напишите новый промпт!

Стоит отметить, что LLM-as-a-judge — это не метрика оценки в том же смысле, что accuracy, precision или NDCG. В машинном обучении метрика — это четко определенная объективная мера: она точно количественно выражает, насколько предсказания модели соответствуют истинным данным (ground truth).

Напротив, LLM-as-a-judge — это общий подход, при котором вы используете LLM для приближенной имитации человеческой оценки. Когда вы просите LLM оценить такие качества, как «соответствие исходному тексту» (faithfulness to source), «корректность» (correctness) или «полезность» (helpfulness), вы сами определяете значения этих терминов в оценочном промпте, полагаясь на семантические взаимосвязи, усвоенные моделью из обучающих данных.

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

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

Прежде чем перейти к деталям, давайте обсудим очевидный вопрос: как так получилось, что вы используете LLM для оценки работы «самой себя»? Разве это не читерство?

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

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

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

Делая внешний вызов LLM с четко сфокусированным оценочным промптом, вы задействуете другие возможности модели. Часто модель используется в роли простого классификатора текста, который должен выполнить одну конкретную инструкцию.

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

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

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

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

Это не означает, что оценочные LLM «лучше» вашей основной модели. Просто перед ними стоит более простая и чётко сфокусированная задача.

Давайте рассмотрим несколько типов LLM-судей, которые вы можете реализовать.

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

Вы можете использовать LLM-оценщики в нескольких сценариях:

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

Парное сравнение обычно выполняется офлайн: вам необходимо сгенерировать несколько ответов и затем их сравнить. Прямая оценка (scoring) работает как офлайн, так и онлайн для непрерывного мониторинга.

Одним из первых применений техники LLM-as-a-judge стало парное сравнение, при котором LLM анализирует два ответа и определяет, какой из них лучше. Этот метод был описан, например, в этом блоге, а также получил официальное название "judge" в статье “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (Zheng et al., 2023). MT-Bench и Chatbot Arena являются примерами бенчмарков для оценки LLM.

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

В упомянутом исследовании авторы использовали GPT-4 в качестве оценочной модели и сравнили его решения с краудсорсинговыми оценками людей. Совпадение оценок LLM и человеческих аннотаторов превысило 80%, что сопоставимо с уровнем согласованности между самими экспертами.

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

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

Способность LLM совпадать с человеческими предпочтениями при сравнении двух ответов выглядит многообещающе. Однако более распространённый способ использования LLM-оценщиков среди разработчиков LLM-продуктов ещё проще — это прямое оценивание (direct scoring) отдельных ответов.

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

Например, LLM-оценщики могут проверять такие аспекты, как тон, ясность, соответствие формату, лаконичность, вежливость, наличие персонально идентифицируемой информации (PII) и другие параметры.

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

LLM-модели эффективны в задачах классификации, связанных с языком и семантикой. Оценку можно организовать как бинарную классификацию (например, «соответствует» / «не соответствует») либо использовать рейтинговую шкалу – например, шкалу Лайкерта от 1 до 5.

Упрощённый промпт: "Оцените следующий текст по критерию лаконичности. Лаконичный ответ чётко и прямо передаёт основную мысль без лишних слов. Верните один из следующих ярлыков: 'Concise' (лаконичный) или 'Verbose' (размытый, избыточный)."

Использование LLM для автоматической оценки рассматривается в следующих работах:

• “Can Large Language Models Be an Alternative to Human Evaluation?” (Chiang et al., 2023) – сравнивает оценки LLM с человеческими аннотациями при использовании одинаковых инструкций.
• “GPTScore: Evaluate as You Desire” (Fu et al., 2023) – анализирует 22 различных аспектов оценки.
• “Is ChatGPT a Good NLG Evaluator? A Preliminary Study” (Wang et al., 2023) – исследует оценку LLM в разрезе конкретных задач и аспектов.

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

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

Примеры оценки диалогов:

• Обнаружение отказов: Отказывался ли агент выполнить задачу в какой-либо момент?
• Выявление повторов: Приходилось ли пользователю повторять свой запрос?
• Определение пользовательского раздражения: Проявляет ли пользователь негативные эмоции?
• Проверка решения проблемы: Была ли проблема пользователя решена к концу диалога?

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

Упрощённый промпт: "Прочитайте диалог и оцените, был ли запрос пользователя решён. 'Resolved' означает, что проблема была устранена, и пользователь либо подтвердил это, либо выразил удовлетворение. Верните один из следующих ярлыков: 'Resolved' (решено) или 'Not Resolved' (не решено)."

В оценке на основе эталона LLM анализирует не только сгенерированный ответ, но и дополнительный контекст для проверки его качества. Вот несколько примеров таких дополнительных входных данных:

• Ответ + Эталонный ответ – полезно, если у вас есть правильный ответ (ground truth) для сравнения.
• Ответ + Вопрос – распространено в чат-ботах и системах Q&A, где важно проверить, соответствует ли ответ заданному вопросу.
• Ответ + Извлеченный контекст или Вопрос + Извлеченный контекст – используется в Retrieval-Augmented Generation (RAG), когда поиск предоставляет дополнительную информацию для обоснования ответа.

Метод по-прежнему предполагает прямую оценку ответа, но вместо одного входного текста в промпт передаются два или более фрагментов, и модель анализирует их взаимосвязь.

1. Оценка корректности на основе эталонного ответа

Это оффлайн-оценка, в рамках которой LLM сравнивает ответ с «золотым» эталоном. Такой подход отлично подходит для оценки модели на экспериментальном этапе (при итерациях над архитектурой системы), а также для регрессионного тестирования после обновлений модели или промпта.

Например, в системе вопросов и ответов LLM-судья может проверить, насколько новый ответ соответствует ранее одобренному ответу на тот же самый вопрос.

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

Упрощённый промпт: Сравни сгенерированный ОТВЕТ с эталонным РЕФЕРЕНСОМ. Оцени, передаёт ли сгенерированный ответ тот же смысл, даже если формулировка отличается. Верни один из двух ответов: ‘Correct’ или ‘Incorrect’.

Например, в посте в блоге Segment описывалось, как они использовали LLM-оценку для сравнения сгенерированных моделью SQL-запросов с ранее одобренными запросами для того же ввода. Аналогично, Wix использует LLM-судей для проверки корректности ответов в Q&A-системах, сопоставляя их с ground truth.

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

Например, в системах вопросов и ответов можно оценивать ответ вместе с вопросом по следующим критериям:

• Полнота: Охватывает ли ответ все аспекты вопроса?
• Релевантность: Является ли ответ напрямую связанным с заданным вопросом?

Эти типы оценок можно использовать для постоянного мониторинга качества.

Упрощённый промпт: Оцените следующий ОТВЕТ на основе данного ВОПРОСА. Полный ответ — это тот, который полностью охватывает все части вопроса. Верните один из следующих лейблов: ‘Complete’ или ‘Incomplete’.

Retrieval-Augmented Generation (RAG) — это особый случай архитектуры LLM-продуктов.

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

• Насколько хорошо система извлекает релевантные документы.
• Насколько качественен итоговый ответ.

Для первой части — оценки качества поиска — можно использовать метрики ранжирования, такие как NDCG или precision at K. Эти метрики позволяют количественно оценить, насколько хорошо система находит и сортирует документы, которые помогают ответить на запрос. Такие оценки обычно проводятся офлайн при настройке параметров, например, разных стратегий поиска.

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

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

Упрощённый промпт: Оцените релевантность текста для ответа на ВОПРОС. Релевантный текст содержит информацию, которая помогает ответить на вопрос, даже если частично. Верните один из следующих лейблов: ‘Relevant’ или ‘Irrelevant’.

Например, этот метод описан в статье “Large Language Models Can Accurately Predict Searcher Preferences” (Thomas et al., 2023).

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

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

Упрощённый промпт: Оцените, насколько ОТВЕТ соответствует КОНТЕКСТУ. Достоверный ответ должен включать только информацию, присутствующую в контексте, избегать придумывания новых деталей и не противоречить исходным данным. Верните один из следующих лейблов: ‘Faithful’ или ‘Not Faithful’.

Например, в блоге DoorDash о RAG-основанном агенте поддержки они упоминали использование LLM-судей для оценки согласованности ответа с контекстом.

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

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

Рассмотрим некоторые ключевые практики.

Коротко: Создание LLM-судьи — это небольшой ML-проект. Начните с размеченного датасета, который отражает желаемые критерии оценки, затем разработайте и уточните evaluation prompt, чтобы обеспечить соответствие разметке.

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

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

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

Вот описание общего процесса:

Шаг 1. Определите сценарий оценки.

Сначала решите, что именно должен оценивать LLM-судья. Вы проверяете корректность, тон, лаконичность или что-то другое? Можно оценивать только сгенерированный ответ, сравнивать несколько входных данных или анализировать полный транскрипт диалога. Начните с постановки цели, а затем подумайте, как формализовать процесс оценки.

Совет: Не плодите лишнего. Не пытайтесь оценивать слишком много параметров одновременно. Если вам нужно проверить несколько аспектов (например, тон и точность), разделите их на отдельные оценки. По возможности используйте четкие бинарные критерии (например, «правильно» или «неправильно»).

Шаг 2. Подготовьте датасет для оценки.

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

Объем датасета не обязательно должен быть большим, но он должен включать разнообразные примеры, особенно те, которые ставят под сомнение ваши критерии оценки.

Шаг 3. Разметьте этот датасет.

Вот ключевой момент: вам нужно вручную разметить датасет так, как это будет делать LLM-судья. Этот размеченный набор данных станет вашей «эталонной правдой» (ground truth) и поможет измерить качество работы модели.

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

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

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

Детали могут отличаться в зависимости от ваших задач!

Вы, конечно, можете пропустить этот шаг: просто напишите лучший возможный prompt, затем посмотрите и исправьте метки, сгенерированные LLM, чтобы создать утвержденный тестовый датасет. Однако часто начинать с ручной разметки полезнее — это помогает улучшить ваш изначальный prompt.

Шаг 4. Создайте промпт для оценки.

Когда вы точно знаете, что хотите оценивать, пора составить промпт для LLM-судьи.

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

Мы поделимся дополнительными советами по написанию промптов в следующем разделе.

Шаг 5. Оценка и итерации.

Когда ваш промпт готов, примените его к оценочному датасету и сравните выводы LLM-судьи с вашей вручную размеченной эталонной правдой (ground truth).

Для бинарных классификаций можно использовать метрики, такие как precision и recall, чтобы измерить, насколько хорошо работает LLM-судья, особенно если фокусировка идёт на определённый класс.

Например, если приоритет — обнаружение «некорректных» ответов, даже ценой некоторых ошибок в классификации «корректных» ответов, тогда recall будет ключевой метрикой качества.

Если результаты не соответствуют вашим ожиданиям, можно скорректировать промпт и повторно запустить оценку. В идеале стоит выделить часть размеченного вручную датасета в "held-out" набор, который будет использоваться только для финального тестирования промпта.

Важно понимать, что LLM-судья не обязан быть идеальным — достаточно, чтобы он был "достаточно хорош" для ваших целей. Даже человеческие эксперты делают ошибки!

Привлекайте экспертов предметной области

Нетеxнические специалисты — такие как продакт-менеджеры или эксперты в предметной области — играют ключевую роль в настройке оценочных критериев. Они помогают определить, какие аспекты поведения или темы должен фиксировать LLM, формируют рекомендации для промптов и тестируют их соответствие ожиданиям. Благодаря no-code инструментам этот процесс можно сделать коллаборативным.

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

В статье “Who Validates the Validators?” (Shankar et al., 2024) авторы обсуждают дрейф критериев (criteria drift), когда ручная разметка выходных данных LLM помогает пользователям уточнять свои ожидания на основе конкретных ошибок и паттернов, обнаруженных в ответах модели.

Коротко: Пишите собственные промпты. Используйте вопросы с ответами «да/нет» и разбивайте сложные критерии. Запрос объяснения помогает повысить качество оценки и упростить отладку.

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

Помните, что промпты ведут себя по-разному в разных моделях. Одна и та же инструкция для оценки может давать разные результаты на GPT-4.0 mini и GPT-4.0. Критически важно тестировать их в сравнении с ожидаемыми результатами.

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

Существует несколько техник промптинга, которые могут повысить точность и согласованность вашего LLM-оценщика. Они аналогичны тем, что применяются при разработке LLM-продуктов, например, chain of thought prompting. Просьба к LLM оценить текст не отличается от других задач, которые вы ему поручаете — те же методики работают и здесь.

Вот несколько подходов, которые стоит рассмотреть.

Бинарные оценки, такие как «вежливый» vs. «невежливый», обычно более надежны и согласованы как для LLM, так и для человеческих оценщиков. Гораздо проще получить точные результаты при выборе из двух простых категорий, чем пытаться определить, соответствует ли ответ 73 или 82 баллам по шкале «вежливости».

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

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

2. Объясняйте значение каждой оценки

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

Если ваша цель — отметить все пограничные случаи, а не упустить их, можно задать более строгие инструкции: «Если есть сомнения, лучше считать текст токсичным».

Четкое определение классов особенно важно при использовании 5-балльной шкалы. В чём разница между 3 и 4? Если это неочевидно, то и LLM, и человеческие аннотаторы будут испытывать трудности с консистентностью оценок.

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

Чтобы снизить вариативность, можно использовать множественные оценки, а затем агрегировать их методами max voting (голосование большинством) или усреднения. Например, см. работу “Replacing Judges with Juries” (Verga et al., 2024).

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

Если необходимо оценить несколько аспектов, таких как полнота, точность и релевантность, лучше разнести их на отдельные метрики. Это делает процесс более структурированным и сфокусированным.

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

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

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

Промпт может начинаться с общего объяснения (например, «Хорошо» означает…, «Плохо» означает…), а затем содержать примеры как хороших, так и плохих ответов. Такие примеры помогают LLM лучше понять, как применять критерии — особенно в случае менее мощных моделей.

Этот метод называется few-shot learning. Подробнее о нём можно прочитать в статье “Language Models are Few-Shot Learners” (Brown et al., 2020).

Однако важно протестировать, как добавление примеров влияет на работу модели. Несбалансированные или предвзятые примеры могут искажать её решения.

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

Дополнительные исследования на эту тему приведены в статье “Calibrate Before Use: Improving Few-Shot Performance of Language Models” (Zhao et al., 2021), где показано, что результаты few-shot обучения зависят от таких факторов, как формат промпта и порядок примеров.

Как и в других задачах, если попросить LLM «размышлять» над процессом перед тем, как дать окончательный ответ (подход, известный как Chain of Thought (CoT)), это может значительно повысить качество результатов.

Идея добавления этапа рассуждения в промпт подробно исследуется в статье “Chain-of-Thought Prompting” (Wei et al., 2022), а также в работе “Large Language Models are Zero-Shot Reasoners” (Kojima et al., 2022).

Вы можете использовать тот же подход в своем evaluation prompt: попросите модель объяснить своё рассуждение или думать шаг за шагом, фактически реализуя Zero-Shot-CoT. В этом случае модель будет выдавать как обоснование, так и итоговый результат в одном ответе. Дальнейшие исследования показывают, что это значительно повышает качество оценок.

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

Multi-turn Chain of Thought: Некоторые исследователи изучают более сложные подходы к CoT. Например, одна из методик — G-Eval (см. Liu et al., 2023) — использует процесс, в котором ИИ сначала определяет задачу, затем планирует шаги, а потом заполняет форму оценки. Однако дальнейшие исследования показывают, что такая автоматически сгенерированная CoT-логика не всегда дает лучшие результаты. Напротив, простой запрос к LLM на объяснение или анализ зачастую превосходит этот метод (см. Chiang et al., 2023).

6. Установите низкую температуру

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

7. Используйте более мощную модель

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

8. Получайте структурированные выходные данные

Наконец, всегда стремитесь к структурированному формату вывода, например, JSON. Это значительно упрощает разбор и дальнейший анализ результатов оценки.

Итоги. Подытожим основные рекомендации по написанию evaluation prompts:

• Используйте бинарные или низкоточные оценки.
• Разбивайте сложные критерии на отдельные метрики.
• Чётко определяйте значение каждой оценки или метки, добавляйте примеры.
• Просите LLM думать шаг за шагом и объяснять свою логику.
• Устанавливайте низкую температуру.
• Используйте более мощную модель, если это возможно.

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

Для более глубокого обзора исследований по теме LLM-as-a-judge рекомендуем отличные материалы Cameron Wolfe и Eugene Yan.

Коротко: LLM observability помогает отслеживать производительность системы в продакшене. Настройте tracing для сбора live-данных, запланируйте оценки, в которых части этих данных оцениваются LLM-судьями, и используйте дашборд для мониторинга трендов, таких как разочарование пользователей и галлюцинации модели.

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

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

Этот мониторинг нужен не только для контроля качества — он также даёт ценные инсайты о том, как пользователи взаимодействуют с вашим инструментом, какие задачи и темы встречаются чаще всего.

Как настроить процесс:

1. Tracing

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

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

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

2. Планирование оценок

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

Например, если у вас работает чат-бот для клиентской поддержки, можно оценивать 10% диалогов на предмет признаков фрустрации пользователя, повторяющихся вопросов или запросов без выполнения. Регулярное проведение таких оценок (например, каждый час, день или после X диалогов) позволит вам оперативно отслеживать производительность системы.

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

3. Создание дашборда

Для удобного отслеживания производительности вам понадобится дашборд.

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

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

4. Анализируйте свои данные!

Мониторинг и отладка всегда идут рука об руку. Например, если вы замечаете рост пользовательской фрустрации, стоит пересмотреть конкретные проблемные диалоги. Можно экспортировать примеры для fine-tuning модели или создать тестовый набор, чтобы скорректировать промты и устранить проблему.

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

Коротко:

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

LLM-судьи — это практичное и масштабируемое решение для оценки выходных данных ИИ, но они имеют свои компромиссы. Вот их основные плюсы и минусы.

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

Риски bias'ов. LLM обучаются на огромных наборах данных, что может вносить bias в их оценки. Например, если попросить классифицировать текст как «профессиональный» или «непрофессиональный» без чётких критериев, модель будет полагаться на предположения из обучающих данных. В парных оценках известны следующие bias'ы (см. Zheng, L., 2023):

• Позиционный bias: предпочтение ответов в зависимости от их расположения (например, первого или последнего).
• Болтливость (verbosity bias): склонность отдавать предпочтение более длинным ответам, даже если они не точнее.
• Эффект самопреумножения (self-enhancement bias): предпочтение текстов, сгенерированных тем же самым LLM.

Эти bias'ы можно минимизировать, меняя порядок ответов или используя систему прямого скоринга, вместо того чтобы просить LLM выбрать «лучший» ответ.

Конфиденциальность данных. Использование сторонних LLM API для оценки означает передачу данных внешним сервисам. Хотя это часто допустимо (учитывая, что ответы уже генерируются через LLM), важно учитывать вопросы приватности и безопасности, особенно если работа ведётся с чувствительными данными.

Не мгновенно. Хотя LLM работают быстрее людей, они всё же медленнее и дороже по сравнению с rule-based проверками или более лёгкими ML-моделями. Это делает их менее подходящими для задач типа guardrails, где необходимо мгновенно валидировать ответ во время генерации.

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

Требует настройки. Развернуть эффективного LLM-судью — это работа. Нужно чётко определить критерии, разработать промпты для оценки и разметить датасеты. Это не решение в стиле set-it-and-forget-it — потребуется периодическая проверка и настройка, чтобы судья продолжал работать качественно.

Коротко: Другие варианты включают ручную разметку, сбор пользовательской обратной связи, использование специализированных ML-моделей и rule-based проверок. Если доступен эталонный ответ, можно применять метрики вроде ROUGE. Оптимальный подход обычно сочетает несколько методов.

Хотя LLM-судьи — это мощный инструмент, они не единственный способ оценивать выходные данные ИИ. Вот несколько альтернативных методов:

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

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

Специализированные ML-модели. Для чётко определённых задач традиционные модели машинного обучения могут быть весьма эффективными. Доступно множество предобученных моделей для таких задач, как анализ тональности или детекция персональных данных (PII). Также можно использовать embedding-модели для сравнения семантического сходства текстов, что особенно полезно для регрессионного тестирования при сравнении старых и новых ответов.

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

Метрики оценки генеративного качества. Для офлайн-оценки структурированных задач, таких как суммаризация и машинный перевод, можно использовать метрики вроде ROUGE и BLEU, которые объективно измеряют качество ответа, сравнивая его с эталонными текстами. Эти метрики основаны на совпадении n-грамм и оценивают, насколько близок выходной текст к идеальному ответу.

Оценка на основе правил. Иногда самые простые методы оказываются наиболее эффективными. Использование правил, например, поиск определенных ключевых слов или фраз (таких как "cannot" или "apologies" для отказа, а также списка нецензурных выражений), позволяет быстро выявлять очевидные ошибки. Этот метод быстрый, дешевый и простой, а главное — детерминированный, так что его результаты полностью предсказуемы.

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