Using LLM-as-a-Judge For Evaluation: A Complete Guide
Статья представляет пошаговое руководство по созданию системы оценки AI-продуктов с использованием LLM в роли судьи — методику «Critique Shadowing». Автор, консультировавший более 30 компаний, описывает типичные ошибки команд: избыток метрик, произвольные шкалы 1–5, игнорирование доменных экспертов. Процесс включает семь шагов: поиск ключевого доменного эксперта, создание разнообразного датасета, получение бинарных оценок pass/fail с развёрнутыми критиками, исправление ошибок, итеративную настройку промпта судьи до >90% согласия с экспертом, анализ ошибок по корневым причинам и создание специализированных судей при необходимости. Главный тезис — настоящая ценность процесса не в самом LLM-судье, а в систематическом анализе данных и формализации критериев качества.
Ранее в этом году я написал статью Your AI product needs evals. Многие из вас спрашивали: «Как начать работу с LLM в роли судьи?» Это руководство обобщает мой опыт помощи более чем 30 компаниям в настройке их систем оценки.
Проблема: AI-команды тонут в данных
Бывало ли, что вы тратите недели на создание AI-системы, а потом понимаете, что понятия не имеете, работает ли она на самом деле? Вы не одиноки. Я заметил, что команды повторяют одни и те же ошибки при использовании LLM для оценки AI-выходов:
Слишком много метрик: создание множества измерений, которые становятся неуправляемыми. Произвольные системы оценки: использование некалиброванных шкал (например, от 1 до 5) по нескольким измерениям, где разница между баллами неясна и субъективна. Что делает результат тройкой, а не четвёркой? Никто не знает, и разные оценщики часто интерпретируют эти шкалы по-разному. Игнорирование доменных экспертов: неучастие людей, глубоко разбирающихся в предметной области. Невалидированные метрики: использование измерений, которые на самом деле не отражают того, что важно для пользователей или бизнеса.
Результат? Команды оказываются погребены под горами метрик или данных, которым не доверяют и не могут использовать. Прогресс останавливается. Все разочарованы.
Например, нередко я вижу дашборды, которые выглядят вот так:
Отслеживание кучи оценок по шкале от 1 до 5 — часто признак плохого процесса оценки (позже объясню почему). В этой статье я покажу, как избежать этих ловушек. Решение — использовать методику, которую я называю «Critique Shadowing» (теневое критикование). Вот как это делается, шаг за шагом.
Шаг 1: Найдите главного доменного эксперта
В большинстве организаций обычно есть один (максимум два) ключевых человека, чьё суждение критически важно для успеха вашего AI-продукта. Это люди с глубокой экспертизой в предметной области или представляющие вашу целевую аудиторию. Определить и вовлечь этого главного доменного эксперта на ранней стадии — критически важно.
Почему так важно найти правильного доменного эксперта?
Они задают стандарт: этот человек не только определяет, что приемлемо технически, но и помогает понять, строите ли вы то, что действительно нужно пользователям. Фиксируют невысказанные ожидания: вовлекая их, вы раскрываете их предпочтения и ожидания, которые они, возможно, не смогут полностью сформулировать заранее. Через процесс оценки вы помогаете им прояснить, как выглядит «приемлемое» взаимодействие с AI. Последовательность суждений: у разных людей в организации могут быть разные мнения о работе AI. Фокус на главном эксперте обеспечивает согласованность оценок и соответствие наиболее критичным стандартам. Чувство причастности: вовлечение эксперта даёт ему долю ответственности за развитие AI. Он чувствует вовлечённость, потому что участвовал в формировании продукта. В итоге он с большей вероятностью одобрит результат.
Примеры главных доменных экспертов:
Психолог для AI-ассистента в сфере ментального здоровья. Юрист для AI, анализирующего юридические документы. Директор клиентского сервиса для чат-бота поддержки. Ведущий преподаватель или разработчик учебных программ для образовательного AI-инструмента.
В небольшой компании это может быть CEO или основатель. Если вы независимый разработчик, доменным экспертом должны быть вы сами (но будьте честны с собой относительно своей экспертизы).
Если вам приходится полагаться на руководство, регулярно проверяйте их предположения на реальной обратной связи от пользователей.
Многие разработчики пытаются сами выступать в роли доменного эксперта или находят удобного заместителя (например, своего руководителя). Это путь к катастрофе. У людей будут разные мнения о том, что приемлемо, и вы не сможете угодить всем. Важно, чтобы ваш главный доменный эксперт был удовлетворён.
Помните: это не обязательно займёт много времени доменного эксперта. Далее в статье я расскажу, как сделать процесс эффективным. Их участие абсолютно критично для успеха AI.
Дальнейшие шаги
Когда вы нашли эксперта, нужно предоставить ему правильные данные для анализа. Давайте поговорим о том, как это сделать.
Шаг 2: Создайте датасет
Когда главный доменный эксперт на борту, следующий шаг — создать датасет, который охватывает проблемы, с которыми столкнётся ваш AI. Важно, чтобы датасет был разнообразным и представлял типы взаимодействий, которые ваш AI будет иметь в продакшене.
Почему важен разнообразный датасет
Всестороннее тестирование: обеспечивает оценку AI в широком спектре ситуаций. Реалистичные взаимодействия: отражает реальное поведение пользователей для более релевантных оценок. Выявление слабых мест: помогает обнаружить области, где AI может ошибаться или давать сбои.
Измерения для структурирования датасета
Вам нужно определить измерения, которые имеют смысл для вашего случая. Например, вот те, которые я часто использую для B2C-приложений:
Функции: конкретные возможности вашего AI-продукта. Сценарии: ситуации или проблемы, с которыми AI может столкнуться и должен справиться. Персоны: репрезентативные профили пользователей с различными характеристиками и потребностями.
Примеры функций, сценариев и персон
Функции
Сценарии
Сценарии — это ситуации, с которыми AI должен справиться (не основанные на результате ответа AI).
Персоны
Эта таксономия не универсальна
Эта таксономия (функции, сценарии, персоны) не универсальна. Например, может не иметь смысла создавать персоны, если пользователи не взаимодействуют с вашим AI напрямую. Идея в том, что вы должны определить измерения, подходящие для вашего случая, и сгенерировать данные, покрывающие их. Скорее всего, вы уточните их после первого раунда оценок.
Генерация данных
Для создания датасета вы можете:
Использовать существующие данные: выбрать реальные взаимодействия пользователей или поведение из вашей AI-системы. Сгенерировать синтетические данные: использовать LLM для создания реалистичных пользовательских вводов, покрывающих различные функции, сценарии и персоны.
Часто вы будете использовать комбинацию обоих подходов для обеспечения полного покрытия. Синтетические данные не так хороши, как реальные, но это хорошая отправная точка. Кроме того, мы используем LLM только для генерации пользовательских вводов, а не ответов LLM или внутреннего поведения системы.
Независимо от того, используете ли вы существующие или синтетические данные, вам нужно хорошее покрытие по определённым вами измерениям.
Включение системной информации
При создании тестовых данных используйте свои API и базы данных там, где это уместно. Это создаст реалистичные данные и вызовет нужные сценарии. Иногда вам нужно будет написать простые программы для получения этой информации. Именно на это ссылается колонка «Допущения» в примерах ниже.
Примеры промптов для LLM для генерации пользовательских вводов
Вот несколько примеров промптов, иллюстрирующих, как использовать LLM для генерации синтетических пользовательских вводов для различных комбинаций функций, сценариев и персон:
Генерация синтетических данных
При генерации синтетических данных вам нужно создать только пользовательские вводы. Затем вы подаёте эти вводы в свою AI-систему для генерации ответов AI. Важно логировать всё, чтобы можно было оценить ваш AI. Подведём итог, вот процесс:
Сгенерируйте пользовательские вводы: используйте промпты для LLM для создания реалистичных пользовательских вводов. Подайте вводы в вашу AI-систему: введите пользовательские взаимодействия в ваш AI в его текущем виде. Зафиксируйте ответы AI: запишите ответы AI для формирования полных взаимодействий. Организуйте взаимодействия: создайте таблицу для хранения пользовательских вводов, ответов AI и соответствующих метаданных.
Сколько данных нужно сгенерировать?
Однозначного ответа нет. Как минимум, вы хотите сгенерировать достаточно данных, чтобы иметь примеры для каждой комбинации измерений (в этом игрушечном примере: функции, сценарии и персоны). Однако вы также хотите продолжать генерировать данные, пока не перестанете видеть новые типы ошибок. Объём генерируемых мной данных значительно варьируется в зависимости от случая.
Работают ли синтетические данные на самом деле?
Возможно, вы скептически относитесь к использованию синтетических данных. В конце концов, это не реальные данные — как они могут быть хорошим приближением? По моему опыту, это работает удивительно хорошо. Некоторые из моих любимых AI-продуктов, например Hex, используют синтетические данные для своих оценок:
«LLM удивительно хороши в генерации отличных — и разнообразных — примеров пользовательских запросов. Это может быть полезно для функций приложения и, что неожиданно, для построения оценок. Если это звучит так, будто Большая Языковая Змея кусает себя за хвост — я был удивлён не меньше вашего! Могу лишь сказать: это работает, отправляйте в продакшен.» Bryan Bischof, Head of AI Engineering в Hex
Дальнейшие шаги
Когда датасет готов, наступает самая важная часть: получение оценки взаимодействий от вашего главного доменного эксперта.
Шаг 3: Направьте доменного эксперта на вынесение суждений «зачёт/незачёт» с критиками
Задача доменного эксперта — сосредоточиться на одном вопросе: «Достиг ли AI желаемого результата?» Никаких сложных шкал оценки или множественных метрик. Просто чёткое решение «зачёт» или «незачёт». В дополнение к решению, эксперт должен написать критику с объяснением своего обоснования.
Почему важны простые метрики «зачёт/незачёт»?
Ясность и фокус: бинарное решение заставляет всех задуматься о том, что действительно важно. Оно упрощает оценку до единственного ключевого вопроса. Практичные выводы: суждения «зачёт/незачёт» легко интерпретировать и использовать. Они помогают быстро определить, удовлетворяет ли AI потребности пользователя. Заставляет формулировать ожидания: когда доменные эксперты должны решить, прошло ли взаимодействие или нет, они вынуждены чётко сформулировать свои ожидания. Этот процесс раскрывает нюансы и невысказанные предположения о том, как AI должен себя вести. Эффективное использование ресурсов: сохраняет процесс оценки управляемым, особенно на начальном этапе. Вы избегаете увязания в детальных метриках, которые могут быть ещё не осмысленными.
Роль критик
Наряду с бинарным суждением «зачёт/незачёт» важно написать развёрнутую критику сгенерированного LLM выхода. Эти критики:
Фиксируют нюансы: критика позволяет отметить, если что-то было в основном правильным, но имело области для улучшения. Направляют улучшения: детальная обратная связь даёт конкретные идеи о том, как можно улучшить AI. Балансируют простоту и глубину: в то время как «зачёт/незачёт» даёт чёткий вердикт, критика обеспечивает глубину, необходимую для понимания логики суждения.
Зачем писать критики?
На практике доменные эксперты могут не полностью интернализировать все критерии оценки. Заставляя их выносить решение «зачёт/незачёт» и объяснять свои рассуждения, вы помогаете им прояснить ожидания и получаете ценные указания для улучшения AI.
«Но моя задача сложная!» Поверьте — начало с простого заставляет сфокусироваться на том, что действительно важно. Позже при необходимости можно добавить сложность.
Примеры хороших критик
Чтобы проиллюстрировать, как простые суждения «зачёт/незачёт» в сочетании с развёрнутыми критиками работают на практике, вот таблица с примерами пользовательских взаимодействий с AI-ассистентом. Таблица включает как зачёты, так и незачёты, с критиками, объясняющими, почему AI получил такое суждение. В случаях, когда AI получил зачёт несмотря на критические проблемы, критика выделяет эти аспекты и обосновывает, почему в целом результат всё же засчитан. Для проваленных взаимодействий критика объясняет критические элементы, приведшие к незачёту.
Эти примеры демонстрируют, как AI может получать суждения как «зачёт», так и «незачёт». В критиках:
Для зачётов мы объясняем, почему AI успешно удовлетворил основную потребность пользователя, даже если есть критические аспекты, которые можно улучшить. Мы выделяем эти области для улучшения, обосновывая общее положительное суждение. Для незачётов мы определяем критические элементы, приведшие к провалу, объясняя, почему AI не достиг основной цели пользователя или нарушил важные факторы, такие как пользовательский опыт или безопасность.
Самое важное — критика должна быть достаточно детальной, чтобы её можно было использовать в few-shot промпте для LLM-судьи. Другими словами, она должна быть достаточно подробной, чтобы новый сотрудник мог её понять. Слишком краткие критики — распространённая ошибка.
Обратите внимание, что примеры пользовательских взаимодействий с AI упрощены для краткости — но вам может потребоваться предоставить доменному эксперту больше контекста для вынесения суждения. Подробнее об этом позже.
На этом этапе не нужно проводить анализ корневых причин технических проблем, из-за которых AI провалился. Часто полезно сначала получить общее представление о поведении, прежде чем углубляться в детали.
Не отклоняйтесь от бинарных суждений «зачёт/незачёт» на начальном этапе
Распространённая ошибка — отклонение от бинарных суждений «зачёт/незачёт». Давайте вернёмся к дашборду, который мы видели ранее:
Если ваши оценки состоят из кучи метрик, которые LLM оценивает по шкале от 1 до 5 (или любой другой шкале), вы делаете это неправильно. Давайте разберём почему.
Это не практично: люди не знают, что делать с тройкой или четвёркой. Не очевидно, чем это число лучше двойки. Вы должны иметь возможность сказать «это взаимодействие прошло, потому что…» и «это взаимодействие провалилось, потому что…». Чаще всего эти метрики не имеют значения. Каждый раз, когда я анализировал данные суждений доменных экспертов, они не коррелировали с такого рода метриками. Бинарное суждение эксперта позволяет выяснить, что действительно важно.
Вот почему я не люблю готовые метрики, которые идут со многими фреймворками оценки. Они, как правило, уводят людей в сторону.
Типичные возражения против суждений «зачёт/незачёт»:
«Бизнес сказал, что эти 8 измерений важны, значит мы должны оценивать их все.» «Нам нужно уметь объяснить, почему взаимодействие прошло или провалилось.»
Я гарантирую: если кто-то говорит, что нужно измерять 8 вещей по шкале от 1 до 5, они не знают, что ищут. Они просто гадают. Вы должны позволить доменному эксперту вести процесс и выносить суждения «зачёт/незачёт» с критиками, чтобы выяснить, что действительно важно. Стойте на своём.
Упростите эксперту работу с данными
Наконец, нужно убрать всё трение из процесса просмотра данных. Я писал об этом здесь. Иногда достаточно обычной таблицы. Это вопрос суждения — что проще для доменного эксперта. Я обнаружил, что часто приходится предоставлять дополнительный контекст, чтобы помочь эксперту понять взаимодействие пользователя, например:
Метаданные о пользователе: местоположение, уровень подписки и т.д. Дополнительный контекст о системе: текущее время, уровень запасов и т.д. Ресурсы для проверки корректности ответа AI (например, возможность поиска в базе данных и т.д.)
Все эти данные нужно представить на одном экране, чтобы доменный эксперт мог просмотреть их без лишних переключений. Поэтому я рекомендую создать простое веб-приложение для просмотра данных.
Сколько примеров нужно?
Количество необходимых примеров зависит от сложности задачи. Моя эвристика — начинать примерно с 30 примеров и продолжать, пока не перестану видеть новые типы ошибок. После этого продолжаю, пока не перестану узнавать что-то новое.
Далее мы рассмотрим, как использовать эти данные для построения LLM-судьи.
Шаг 4: Исправьте ошибки
После анализа данных вы, скорее всего, обнаружите ошибки в вашей AI-системе. Вместо того чтобы двигаться дальше и строить LLM-судью, стоит исправить очевидные ошибки. Помните, весь смысл LLM в роли судьи — помочь вам находить эти ошибки, так что абсолютно нормально, если вы обнаружите их раньше!
Если вы уже разработали оценки уровня 1, как описано в моей предыдущей статье, у вас не должно быть массовых ошибок. Однако они иногда проскальзывают. Если вы найдёте массовые ошибки, исправьте их и вернитесь к шагу 3. Итерируйте, пока не почувствуете, что система стабилизировалась.
Шаг 5: Итеративно постройте LLM-судью
Скрытая сила критик
Вы не можете написать хороший промпт для судьи, пока не увидите данные. Статья Shankar et al. «Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences» хорошо резюмирует это:
«Чтобы оценивать выходы, людям нужно экстернализировать и определить свои критерии оценки; однако сам процесс оценки выходов помогает им определить эти самые критерии. Мы называем это явление дрейфом критериев, и оно подразумевает, что невозможно полностью определить критерии оценки до того, как человек начнёт оценивать выходы LLM.»
Начните с примеров эксперта
Позвольте поделиться реальным примером построения LLM-судьи, который вы можете применить к своему случаю. Когда я помогал Honeycomb создать функцию Query Assistant, нам нужен был способ оценить, генерирует ли AI хорошие запросы. Вот как выглядел наш промпт для LLM-судьи, включая few-shot примеры критик от нашего доменного эксперта Phillip:
You are a Honeycomb query evaluator with advanced capabilities to judge if a query is good or not. You understand the nuances of the Honeycomb query language, including what is likely to be most useful from an analytics perspective. Here is information about the Honeycomb query language: {{query_language_info}} Here are some guidelines for evaluating queries: {{guidelines}} Example evaluations:
Обратите внимание, что каждый пример включает:
Запрос на естественном языке (NLQ) в тегах
В промпте выше примеры критик фиксированы. Продвинутый подход — включать примеры динамически в зависимости от оцениваемого элемента. Подробнее можно узнать в этой статье о непрерывном обучении в контексте.
Продолжайте итерировать промпт до сходимости с доменным экспертом
В данном случае я использовал низкотехнологичный подход для итерации промпта. Я отправил Phillip таблицу со следующей информацией:
NLQ Сгенерированный запрос Критика Результат (зачёт или незачёт)
Phillip заполнял свою версию таблицы со своими критиками. Я использовал это для итеративного улучшения промпта. Таблица выглядела так:
Я также отслеживал процент согласия во времени, чтобы убедиться, что мы сходимся к хорошему промпту.
В этом примере мы использовали согласие между моделью и человеком-оценщиком, потому что наш датасет был примерно сбалансирован (около 50% экземпляров были провалами). Однако использование сырого показателя согласия в общем случае не рекомендуется и может вводить в заблуждение при несбалансированных классах. Вместо этого следует измерять точность и полноту отдельно для более точной картины согласованности судьи.
Нам потребовалось всего три итерации, чтобы достичь >90% согласия между LLM и Phillip. Ваши результаты могут отличаться в зависимости от сложности задачи. Например, Swyx провёл аналогичный процесс сотни раз для AI News — чрезвычайно популярного агрегатора новостей с высококачественными рекомендациями. Качество AI, обусловленное этим процессом, — причина, по которой продукт получил высокое признание.
Как оптимизировать промпт LLM-судьи?
Обычно я корректирую промпты вручную. Мне не особенно везло с оптимизаторами промптов вроде DSPy. Однако мой друг Eugene Yan недавно выпустил многообещающий инструмент под названием ALIGN Eval. Мне он нравится, потому что он простой и эффективный. Также не забывайте о подходе непрерывного обучения в контексте, упомянутом ранее — он может быть эффективным при правильной реализации.
В редких случаях я могу дообучить судью, но предпочитаю этого не делать. Подробнее об этом в разделе FAQ.
Человеческая сторона процесса
В процессе произошло нечто неожиданное. Phillip Carter, наш доменный эксперт в Honeycomb, обнаружил, что анализ критик LLM помог ему чётче сформулировать собственные критерии оценки. Он сказал:
«Видя, как LLM разбирает свои рассуждения, я понял, что сам не был последователен в оценке некоторых пограничных случаев.»
Это паттерн, который я наблюдаю регулярно — процесс построения LLM-судьи часто помогает стандартизировать критерии оценки.
Более того, поскольку этот процесс заставляет доменного эксперта внимательно смотреть на данные, я всегда обнаруживаю новые инсайты о продукте, возможностях AI и потребностях пользователей. Получаемые выгоды часто более ценны, чем создание самого LLM-судьи!
Как часто следует проводить оценку?
Я провожу этот человеческий обзор через регулярные промежутки и при любых существенных изменениях. Например, если я обновляю модель, я запускаю процесс заново. Я не подхожу к этому слишком научно — полагаюсь на своё лучшее суждение. Также замечу, что после первых двух итераций я, как правило, больше фокусируюсь на ошибках, а не на случайной выборке. Например, если я нахожу ошибку, я ищу ещё примеры, которые, по моему мнению, могут вызвать ту же ошибку. Однако я всегда делаю и немного случайной выборки.
Что если это не работает?
Я видел, как этот процесс проваливается когда:
AI имеет слишком широкий охват: например, чат-бот в SaaS-продукте, который обещает делать всё что угодно. Процесс не соблюдается правильно: не используется главный доменный эксперт, не пишутся надлежащие критики и т.д. Ожидания согласованности нереалистичны или невыполнимы.
В каждом из этих случаев я пытаюсь устранить корневую причину, а не пытаюсь принудительно добиться согласованности. Иногда вам не удастся достичь желаемой согласованности, и придётся больше полагаться на человеческую разметку. Однако, пройдя описанный здесь процесс, у вас будут метрики, помогающие понять, насколько можно доверять LLM-судье.
Ошибки, которые я замечал в промптах LLM-судей
Большинство ошибок, которые я видел в промптах LLM-судей, связаны с отсутствием хороших примеров:
Отсутствие каких-либо критик. Написание чрезмерно кратких критик. Отсутствие внешнего контекста. Ваши примеры должны содержать ту же информацию, которую вы используете для оценки, включая внешнюю информацию — метаданные пользователей, системную информацию и т.д. Отсутствие разнообразных примеров. Вам нужно широкое разнообразие примеров, чтобы судья работал для широкого спектра входных данных.
Иногда вы можете столкнуться с трудностями, пытаясь вместить всё необходимое в промпт, и вам придётся подойти творчески к структурированию примеров. Однако это становится менее проблематичным благодаря расширяющимся контекстным окнам и кэшированию промптов.
Шаг 6: Проведите анализ ошибок
После создания LLM-судьи у вас будет датасет пользовательских взаимодействий с AI и суждения LLM. Если метрики показывают приемлемое согласие между доменным экспертом и LLM-судьёй, вы можете применить этого судью к реальным или синтетическим взаимодействиям. После этого можно рассчитать частоту ошибок по разным измерениям данных. Рассчитывать ошибки следует только на невиданных данных, чтобы результаты не были смещёнными.
Например, если вы сегментировали данные по персонам, сценариям, функциям и т.д., ваш анализ данных может выглядеть так:
Частота ошибок по ключевым измерениям
Классификация трейсов
Когда вы знаете, где ошибки, можно провести анализ ошибок для выявления корневых причин. Мой любимый способ — просмотреть примеры каждого типа ошибки и классифицировать их вручную. Рекомендую использовать таблицу для этого. Например, трейс для отслеживания заказов, где нет совпадений для новых пользователей, может выглядеть так:
В этом примере трейса пользователь указывает невалидный номер заказа. AI правильно определяет, что номер заказа невалиден, но даёт бесполезный ответ. Если вы не знакомы с логированием трейсов LLM, обратитесь к моей предыдущей статье об оценках.
Обратите внимание, что этот трейс отформатирован для удобства чтения.
{ "user_input": "Where's my order #ABC123?", "function_calls": [ { "name": "search_order_database", "args": {"order_id": "ABC123"}, "result": { "status": "not_found", "valid_patterns": ["XXX-XXX-XXX"] } }, { "name": "retrieve_context", "result": { "relevant_docs": [ "Order numbers follow format XXX-XXX-XXX", "New users should check confirmation email" ] } } ], "llm_intermediate_steps": [ { "thought": "User is new and order format is invalid", "action": "Generate help message with format info" } ], "final_response": "I cannot find that order #. Please check the number and try again." }
В данном случае ошибку можно классифицировать как: Missing User Education (отсутствие обучения пользователя). Система получила контекст для нового пользователя и информацию о формате, но не включила её в ответ, что указывает на возможность улучшения промпта. После классификации ряда ошибок можно рассчитать распределение ошибок по корневым причинам. Это может выглядеть так:
Распределение корневых причин (20 проваленных взаимодействий)
Теперь вы знаете, на чём сосредоточить усилия. Это не обязательно займёт много времени. За 15 минут можно продвинуться довольно далеко. Также можно использовать LLM для помощи с этой классификацией, но это выходит за рамки данной статьи (вы можете использовать LLM для любого этапа в этой статье, если у вас есть процесс верификации результатов).
Интерактивное пошаговое руководство по анализу ошибок
Анализ ошибок существует в машинном обучении довольно давно. Это видео Andrew Ng отлично проводит через процесс в интерактивном формате:
Исправьте ошибки, снова
Теперь, когда у вас есть представление об ошибках, можно вернуться и исправить их снова. Вернитесь к шагу 3 и итерируйте, пока не будете удовлетворены. Обратите внимание: каждый раз при исправлении ошибки стоит написать тест-кейс для неё. Иногда это может быть assert в вашем тестовом наборе, но в других случаях может потребоваться создать более «специализированного» LLM-судью для этих провалов. Об этом поговорим далее.
Для этого нужна грамотность в работе с данными
Исследование данных на практике гораздо сложнее, чем я описал в этой статье. Для этого нужно чутьё на данные, которое приходит только с практикой. Также помогает базовое знакомство со статистикой и инструментами анализа данных. Моя любимая статья о грамотности в работе с данными — вот эта от Jason Liu и Eugene Yan.
Шаг 7: Создайте более специализированных LLM-судей (при необходимости)
Теперь, когда вы понимаете, где проблемы вашего AI, можно решить, куда и стоит ли инвестировать в более целевых LLM-судей. Например, если вы обнаружите, что AI плохо справляется с корректным цитированием источников, можно создать целевую оценку для этого. Для некоторых ошибок вам может вообще не понадобиться LLM-судья (а достаточно assert в коде).
Ключевой вывод: не переходите сразу к специализированным LLM-судьям, пока не пройдёте процесс Critique Shadowing. Это поможет обосновать, куда инвестировать время.
Итоги Critique Shadowing
Использование LLM в роли судьи может оптимизировать процесс оценки AI при правильном подходе. Вот визуальная иллюстрация процесса (описание процесса также приведено под диаграммой):
Процесс Critique Shadowing итеративен, с обратными связями. Перечислим шаги:
Найдите главного доменного эксперта Создайте датасет Сгенерируйте разнообразные примеры, покрывающие ваши сценарии использования Включите реальные или синтетические пользовательские взаимодействия Доменный эксперт анализирует данные Эксперт выносит суждения «зачёт/незачёт» Эксперт пишет развёрнутые критики с объяснением своих рассуждений Исправьте ошибки (если найдены) Устраните проблемы, обнаруженные при обзоре Вернитесь к обзору эксперта для верификации исправлений Вернитесь к шагу 3, если найдены ошибки Постройте LLM-судью Создайте промпт с использованием примеров эксперта Протестируйте на суждениях эксперта Улучшайте промпт до достижения удовлетворительного согласия Проведите анализ ошибок Рассчитайте частоту ошибок по разным измерениям Выявите паттерны и корневые причины Исправьте ошибки и вернитесь к шагу 3 при необходимости Создайте специализированных судей по мере необходимости
Этот процесс никогда по-настоящему не заканчивается. Он повторяется периодически или при существенных изменениях.
В конечном счёте ценность создал не судья
Настоящая ценность этого процесса — в анализе данных и тщательном исследовании. Хотя AI-судья может быть полезным инструментом, именно прохождение этого процесса приносит результаты. Я бы даже сказал, что создание LLM-судьи — это удобный «хак», который я использую, чтобы заставить людей внимательно смотреть на свои данные!
Именно так. Настоящая бизнес-ценность — в анализе данных. Но ладно, как ни назови.
Вам действительно это нужно?
Ого, это выглядит как много работы! Вам действительно это нужно? Зависит от ситуации. Есть случаи, когда можно срезать путь через этот процесс. Например, допустим:
Вы независимый разработчик, который также является доменным экспертом. Вы работаете с тестовыми данными, которые уже доступны (твиты и т.д.). Просмотр данных не затратен (например, вы можете вручную просмотреть достаточно данных за несколько часов).
В этом сценарии можно сразу перейти к чему-то похожему на шаг 3 и начать смотреть на данные. Кроме того, поскольку просмотр данных не затратен, вероятно, можно просто провести анализ ошибок без судьи (хотя бы на начальном этапе). Вы можете сразу внедрять узнанное обратно в основную модель. Этот пример не исчерпывающий, но даёт представление о том, как адаптировать процесс под свои нужды.
Однако вы никогда не сможете полностью исключить просмотр данных! Именно этот шаг большинство людей пропускают. Не будьте таким человеком.
FAQ
Я получил множество вопросов по этой теме. Вот ответы на самые частые:
Если у меня есть хороший LLM-судья, разве это не тот же LLM, который я хотел бы использовать?
Эффективные судьи часто используют более крупные модели или больше вычислений (через более длинные промпты, цепочку рассуждений и т.д.), чем системы, которые они оценивают.
Однако если стоимость самого мощного LLM не запретительна и задержка не является проблемой, стоит подумать, куда направить усилия. В этом случае может иметь смысл больше инвестировать в специализированных LLM-судей, проверки на уровне кода и A/B-тестирование. Тем не менее, вы всё равно должны пройти процесс анализа данных и критики выходов LLM, прежде чем применять специализированных судей.
Рекомендуете ли вы дообучать судей?
Я предпочитаю не дообучать LLM-судей. Лучше потратить усилия на дообучение самого LLM. Однако дообучение guardrails или других специализированных судей может быть полезным (особенно если это небольшие классификаторы).
В связи с этим, можно использовать LLM-судью для курирования и трансформации данных для дообучения основной модели. Например, судью можно использовать чтобы:
Отфильтровать плохие примеры для дообучения. Сгенерировать более качественные выходы (на основе критики). Симулировать качественную цепочку рассуждений с критиками.
Использование LLM-судьи для улучшения данных дообучения ещё более убедительно, когда вы пытаетесь дистиллировать большой LLM в меньший. Детали дообучения выходят за рамки этой статьи. Если вас интересует подробная информация, см. эти ресурсы.
Что не так с готовыми LLM-судьями?
С ними нет ничего принципиально неправильного. Просто многих людей они уводят в сторону. Если вы дисциплинированы, можете применить их к своим данным и посмотреть, говорят ли они что-то ценное. Однако, по моему опыту, они чаще вызывают путаницу, чем приносят пользу.
Как оценить LLM-судью?
Вы будете собирать метрики согласия между доменным экспертом и LLM-судьёй. Это скажет вам, насколько можно доверять судье и в каких сценариях. Доменному эксперту не нужно проверять каждый пример — достаточно репрезентативной выборки для надёжной статистики.
Какую модель вы используете для LLM-судьи?
Для типа судьи, описанного в этой статье, мне нравится использовать самую мощную модель, которую я могу позволить в рамках бюджета на стоимость и задержку. Этот бюджет может отличаться от бюджета основной модели в зависимости от количества примеров, которые нужно оценить. Это может существенно варьироваться в зависимости от случая.
А что насчёт guardrails?
Guardrails — отдельная, но связанная тема. Это способ предотвратить высказывание или совершение LLM чего-то вредного или неуместного. Эта статья сфокусирована на создании судьи, согласованного с бизнес-целями, особенно на начальном этапе.
Я использую LLM в роли судьи и получаю огромную ценность, но не следовал этому подходу.
Я вам верю. Эта статья — не единственный способ использовать LLM в роли судьи. На самом деле, я видел, как люди используют LLM-судью самыми разными творческими способами, включая ранжирование, классификацию, выбор модели и так далее. Я сфокусирован на подходе, который хорошо работает на старте и позволяет избежать ловушек запутанного разрастания метрик. Однако общий процесс анализа данных остаётся центральным независимо от того, какого судью вы строите.
Как выбрать между традиционными ML-методами, LLM-судьёй и человеческой разметкой?
Ответ на этот (и многие другие вопросы): делайте самое простое, что работает. И простое — не всегда означает традиционные ML-методы. В зависимости от ситуации может быть проще использовать API LLM в качестве классификатора, чем обучать модель и деплоить её.
Можно ли делать судей из маленьких моделей?
Да, потенциально. Я использовал только крупные модели для судей. Ответ на этот вопрос нужно основывать на данных (т.е. на согласии с доменным экспертом).
Как обеспечить консистентность при обновлении LLM-модели?
Нужно снова пройти процесс и замерить результаты.
Как убрать человека из цикла для масштабирования?
Доменному эксперту не нужно оценивать каждый пример. Достаточно репрезентативной выборки. Я не думаю, что можно полностью исключить людей, потому что LLM всё равно должен быть согласован с чем-то, и это что-то обычно — человек. По мере улучшения системы оценки она естественным образом снижает объём необходимых человеческих усилий.
Ресурсы
Вот некоторые ресурсы, которые я рекомендую для более глубокого изучения этой темы:
Your AI Product Needs Evals: эта статья — предшественник данной и даёт общий обзор оценок для продуктов на базе LLM. Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences: эта статья Shreya Shankar et al. даёт хороший обзор проблем оценки LLM и важности правильного процесса. Align Eval: новый инструмент Eugene Yan, который помогает строить LLM-судей, следуя правильному процессу. Также прочитайте его сопроводительную статью. Evaluating the Effectiveness of LLM-Evaluators (aka LLM-as-Judge): отличный обзор различных сценариев использования и подходов к LLM-судьям, также от Eugene Yan. Enhancing LLM-As-A-Judge with Grading Notes от Yi Liu et al. Описывает подход, очень похожий на описанный в этой статье, и даёт другой взгляд на полезность написания критик (они называют их grading notes). Custom LLM as a Judge to Detect Hallucinations with Braintrust от Ankur Goyal и Shaymal Anadkt — сквозной пример построения LLM-судьи; для описанного случая авторы нашли, что подход на основе классификации надёжнее числовых рейтингов (что согласуется с данной статьёй). Techniques for Self-Improving LLM Evals от Eric Xiao из Arize показывает хороший подход к построению LLM-оценок с дополнительными инструментами, которые стоит изучить. How Dosu Used LangSmith to Achieve a 30% Accuracy Improvement with No Prompt Engineering от Langchain показывает хороший подход к построению промптов для LLM с динамическими примерами. Идея проста, но эффективна. Я адаптирую её для своих случаев, включая LLM-судей. Вот видеоразбор подхода. What We've Learned From A Year of Building with LLMs: отличный обзор множества практических аспектов разработки с LLM с акцентом на важности оценки.
Оставайтесь на связи
Я постоянно учусь новому о LLM и с удовольствием делюсь находками. Если вам интересен этот путь, рассмотрите подписку.
Чего ожидать:
Периодические письма с моими последними инсайтами о LLM Ранний доступ к новому контенту Без спама, только честные мысли и открытия