Идея использовать искусственный интеллект для проверки другого искусственного интеллекта, известная как LLM-as-a-Judge, на первый взгляд кажется странной. В эпоху, когда даже простые вещи продвигают с помощью ИИ, легко принять это за очередной рекламный трюк в бурно развивающейся сфере.
Но на деле подход имеет солидную основу. Чтобы понять суть, стоит вспомнить ключевую диаграмму, которую полезно держать в уме специалистам по данным и машинному обучению: она отражает связь между сложностью задачи, объемом обучающих данных и уровнем производительности модели.
Для простых задач небольшой набор данных обычно не мешает. В крайних случаях хватает даже базовых правил. Когда сложность растет, высоких результатов можно добиться с большим и разнообразным набором примеров.
Проблемы возникают с сложными задачами без полноценного набора данных. Тут нет универсального решения: требуются эксперты, ручной сбор информации и тщательная проверка. В тяжелых случаях на создание надежных меток уходят месяцы или годы.
Это положение дел существовало до появления больших языковых моделей.
Парадигма LLM-as-a-Judge
Большие языковые модели предлагают доступ к экспертизе уровня доктора наук по множеству тем через один вызов API. Можно спорить о настоящей "интеллектуальности" этих систем. Накопленные данные указывают, что они скорее мощные инструменты для распознавания шаблонов и поиска информации, чем полноценные разумные агенты. Стоит посмотреть
Однако отрицать одно сложно: для сложных, трудно формализуемых задач без готового набора данных большие языковые модели оказываются очень полезными. Они обеспечивают рассуждения высокого уровня и знания по теме на лету, задолго до того, как удастся собрать и разметить данные для традиционной модели.
Вернемся к проблемной зоне на диаграмме. Предположим, есть трудная задача и лишь грубая первая версия модели. Возможно, она обучена на малом наборе или это готовая модель без доработки, вроде BERT или другой модели встраиваний.
В таких условиях большую языковую модель можно задействовать для оценки работы этой версии. Модель выступает в роли проверяющего или судьи для прототипа, предоставляя быстрый отзыв без большого размеченного набора или огромных усилий.
Это открывает несколько полезных применений:
- Оценка состояния первой версии и ее результатов.
- Формирование набора для обучения и улучшения модели.
- Мониторинг текущей модели или ее доработанной версии после предыдущего шага.
Теперь разберем, как это реализовать.
LLM-as-a-Judge в производстве
Ложно кажется, что поскольку большие языковые модели не требуют обучения и удобны в интерфейсах вроде ChatGPT, Anthropic или Gemini, то создание системы на их базе просто. На практике это не так.
Если цель выходит за рамки базовой вставки, нужно серьезно поработать, чтобы модель была надежной, точной и минимизировала галлюцинации. Система должна корректно справляться с ошибками, когда они случаются, а не если.
Чтобы создать готовую к производству систему LLM-as-a-Judge, рассмотрим ключевые аспекты.
- Проектирование системы.
Определим роль модели, ее поведение и перспективу или "персону" для оценки. - Примеры с малым количеством образцов.
Предоставим модели конкретные случаи, показывающие, как оценивать разные тесты. - Запуск цепочки рассуждений.
Попросим модель генерировать заметки, промежуточные выводы и уровень уверенности, чтобы активировать надежную цепочку мыслей. Это побуждает модель действительно "думать". - Пакетная оценка.
Для снижения затрат и задержек отправим несколько входов сразу, повторно используя один промт для пачки примеров. - Форматирование вывода.
Применяем Pydantic для принудительного структурированного схемы и передаем ее модели, что упрощает интеграцию и делает систему безопасной для производства.
Переходим к коду.
Код
Полный код доступен на GitHub по ссылке https://github.com/PieroPaialungaAI/LLMAsAJudge.git. Далее разберем основные части.
1. Настройка
Начнем с базовой подготовки. Основная работа выполняется с помощью OpenAI и обертки llm_judge. Импортировать нужно следующий блок:
Примечание: потребуется ключ API OpenAI с сайта https://platform.openai.com/api-keys.
Вся кодовая база для производства размещена на сервере. Продолжим.
2. Случай использования
Предположим, есть модель классификации настроений, которую нужно проверить. Она анализирует отзывы клиентов и выдает: Положительный, Отрицательный или Нейтральный.
Вот примеры данных, классифицированных моделью:
Для каждого предсказания важно выяснить:
– Правильный ли вывод?
– Насколько в этом уверены?
– Почему правильный или нет?
– Как оценить качество?
Здесь на помощь приходит LLM-as-a-Judge. Обратите внимание: ground_truth в реальном наборе данных отсутствует, именно поэтому используется большая языковая модель.
Его наличие здесь только для демонстрации случаев слабой работы исходной модели (индексы 2 и 3).
Примечание: в этом примере имитируется слабая модель с ошибками. В реальности так бывает с малыми моделями или недоработанными глубокими сетями.
3. Определение роли
Как и в любой инженерии промтов, четко задайте:
1. Кто судья? Модель будет имитировать, так что укажите экспертизу и фон.
2. Что оценивать? Конкретную задачу для проверки.
3. Какие критерии применять? Что модель должна делать, чтобы решить, хорош ли вывод.
Вот как это задается:
Советы: давайте четкие указания. Укажите, что делать модели (не что избегать). Будьте очень точны в процедуре оценки.
4. Парадигма ReAct
Шаблон ReAct (рассуждение + действие) встроен в фреймворк. Каждое суждение включает:
1. Оценка (0-100): Количественная проверка качества.
2. Вердикт: Двоичный или категориальный вывод.
3. Уверенность: Степень убежденности судьи.
4. Рассуждение: Объяснение по цепочке мыслей.
5. Заметки: Дополнительные наблюдения.
Это позволяет:
– Прозрачность: Видно, почему принят каждый вердикт.
– Отладку: Выявление шаблонов ошибок.
– Человека в цикле: Перенаправление низкоуверенных случаев на ручную проверку.
– Контроль качества: Отслеживание работы судьи со временем.
5. Примеры с малым количеством образцов
Теперь добавим примеры, чтобы модель получила контекст для оценки реальных ситуаций:
Эти примеры включаются в промт, чтобы модель училась на них выполнять задачу.
Советы: охватите разные сценарии: правильные, неправильные и частично верные. Покажите калибровку оценок (100 для идеала, 20-30 для явных ошибок, 60 для спорных). Объясните рассуждения подробно. Ссылайтесь на конкретные слова или фразы из входа.
6. Определение судьи LLM
Вся конструкция упакована в следующий блок кода:
Всего 10 строк. Теперь используем это.
7. Запуск
Вот как выполнить вызов API LLM Judge:
Сразу видно, что судья правильно оценивает работу модели. В частности, он выявляет ошибки в последних двух выводах, как и ожидалось.
Хотя это демонстрирует работоспособность, в производстве вывод нельзя просто печатать в консоль: нужно сохранять его и стандартизировать формат. Так это делается:
Вот как выглядит результат.
Примечание: здесь применяется пакетная обработка, то есть отправка нескольких входов сразу. Это экономит средства и время.
8. Бонус
Теперь представьте другую задачу, например, оценку ответов чат-бота. Весь код перестраивается несколькими строками:
Поскольку разные судьи отличаются только промтами, изменения между оценками минимальны.
Выводы
LLM-as-a-Judge — простая концепция с большой практической ценностью. Когда модель сырая, задача сложная, а размеченных данных нет, большая языковая модель помогает проверять выводы, разбираться в ошибках и ускорять итерации.
В итоге создана:
- Четкая роль и персона для судьи.
- Примеры с малым количеством образцов для направления поведения.
- Рассуждения по цепочке мыслей для прозрачности.
- Пакетная оценка для экономии времени и средств.
- Структурированный вывод с Pydantic для производства.
Получился гибкий движок оценки, который переиспользуется для задач с малыми доработками. Это не замена человеческой проверке, но надежная основа до сбора нужных данных.