Using LLM-as-a-Judge For Evaluation: A Complete Guide –
Хамел Хусейн делится опытом настройки систем оценки ИИ-продуктов, накопленным при работе с более чем 30 компаниями, и описывает технику, которую называет «Critique Shadowing» (тенью критики). Главная мысль: команды тонут в множестве метрик по шкалам 1-5, которым нельзя доверять, тогда как нужен один ключевой эксперт предметной области, выносящий бинарные вердикты pass/fail с подробными критиками. Процесс состоит из семи шагов: найти главного эксперта, собрать разнообразный (в том числе синтетический) датасет, получить от эксперта суждения pass/fail с критиками, исправить ошибки, итеративно построить LLM-судью на few-shot-примерах критик, провести анализ ошибок и при необходимости создать специализированных судей. На примере Honeycomb и их домен-эксперта Phillip автору удалось за три итерации достичь более 90% согласия между LLM-судьёй и человеком. Главный вывод: настоящую ценность создаёт не сам судья, а внимательное изучение собственных данных — шаг, который большинство пропускает.
В начале этого года я написал статью Вашему ИИ-продукту нужны evals. Многие из вас спрашивали: «Как начать работу с LLM-as-a-judge?» В этом руководстве я делюсь тем, что узнал, помогая более чем 30 компаниям выстроить их системы оценки.
Проблема: ИИ-команды тонут в данных
Случалось ли вам тратить недели на создание ИИ-системы и в итоге понимать, что вы понятия не имеете, работает ли она на самом деле? Вы не одиноки. Я заметил, что команды повторяют одни и те же ошибки, когда используют LLM для оценки результатов работы ИИ:
Слишком много метрик: создание множества измерений, которыми невозможно управлять. Произвольные системы оценок: использование некалиброванных шкал (например, 1-5) по нескольким измерениям, где разница между баллами неясна и субъективна. Что делает что-то «тройкой», а не «четвёркой»? Никто не знает, и разные оценщики часто трактуют эти шкалы по-разному. Игнорирование экспертов предметной области: невовлечение людей, которые глубоко понимают предмет. Невалидированные метрики: использование измерений, которые на самом деле не отражают то, что важно для пользователей или бизнеса.
Результат? Команды оказываются погребены под горами метрик или данных, которым они не доверяют и которые не могут использовать. Прогресс останавливается. Все раздражены.
Например, мне нередко доводится видеть дашборды, которые выглядят так:
Отслеживание кучи оценок по шкале 1-5 часто является признаком плохого процесса оценки (почему — обсужу позже). В этом посте я покажу, как избежать этих ловушек. Решение — использовать технику, которую я называю «Critique Shadowing» (тенью критики). Вот как это делать, шаг за шагом.
Шаг 1: найдите того самого главного эксперта предметной области
В большинстве организаций обычно есть один (может быть, два) ключевой человек, чьё суждение критично для успеха вашего ИИ-продукта. Это люди с глубокой экспертизой в предметной области или те, кто представляет вашу целевую аудиторию. Выявить и вовлечь этого главного эксперта предметной области на раннем этапе процесса крайне важно.
Почему так важно найти правильного эксперта предметной области?
Они задают стандарт: этот человек не только определяет, что приемлемо с технической точки зрения, но и помогает вам понять, создаёте ли вы то, чего пользователи действительно хотят. Улавливание невысказанных ожиданий: вовлекая их, вы раскрываете их предпочтения и ожидания, которые они, возможно, не могут полностью сформулировать заранее. В процессе оценки вы помогаете им прояснить, как выглядит «приемлемое» взаимодействие с ИИ. Постоянство в суждениях: люди в вашей организации могут иметь разные мнения о работе ИИ. Фокус на главном эксперте гарантирует, что оценки последовательны и согласованы с самыми важными стандартами. Чувство сопричастности: вовлечение эксперта даёт ему долю в разработке ИИ. Он чувствует себя причастным, потому что приложил руку к его созданию. В итоге он с большей вероятностью одобрит ИИ.
Примеры главных экспертов предметной области:
Психолог для ИИ-ассистента в сфере ментального здоровья. Юрист для ИИ, анализирующего юридические документы. Директор по клиентскому сервису для чат-бота поддержки. Ведущий преподаватель или разработчик учебных программ для образовательного ИИ-инструмента.
В небольшой компании это может быть CEO или основатель. Если вы независимый разработчик, экспертом предметной области должны быть вы сами (но будьте честны с собой относительно своей экспертизы).
Если вам приходится полагаться на руководство, вам следует регулярно проверять их предположения на соответствие реальной обратной связи пользователей.
Многие разработчики пытаются сами выступить в роли эксперта предметной области или находят удобную замену (например, своего начальника). Это рецепт катастрофы. У людей будут разные мнения о том, что приемлемо, и угодить всем невозможно. Важно, чтобы был доволен ваш главный эксперт предметной области.
Помните: это не обязательно отнимет много времени у эксперта предметной области. Далее в этом посте я расскажу, как сделать процесс эффективным. Их вовлечённость абсолютно критична для успеха ИИ.
Дальнейшие шаги
Как только вы нашли своего эксперта, нам нужно дать ему правильные данные для проверки. Давайте поговорим о том, как это сделать, дальше.
Шаг 2: создайте датасет
Когда главный эксперт предметной области на борту, следующий шаг — построить датасет, который охватывает проблемы, с которыми столкнётся ваш ИИ. Важно, чтобы датасет был разнообразным и представлял те типы взаимодействий, которые ваш ИИ будет иметь в продакшене.
Почему важен разнообразный датасет
Всестороннее тестирование: гарантирует, что ваш ИИ оценивается в широком спектре ситуаций. Реалистичные взаимодействия: отражает реальное поведение пользователей для более релевантных оценок. Выявление слабых мест: помогает обнаружить области, где ИИ может испытывать трудности или допускать ошибки.
Измерения для структурирования вашего датасета
Вам нужно определить измерения, которые имеют смысл для вашего сценария использования. Например, вот те, которые я часто использую для B2C-приложений:
Функции (Features): конкретные возможности вашего ИИ-продукта. Сценарии (Scenarios): ситуации или проблемы, с которыми ИИ может столкнуться и которые ему нужно обработать. Персоны (Personas): репрезентативные профили пользователей с отличительными характеристиками и потребностями.
Примеры функций, сценариев и персон
Функции
Сценарии
Сценарии — это ситуации, которые ИИ нужно обработать (не основанные на результате ответа ИИ).
Персоны
Эта таксономия не универсальна
Эта таксономия (функции, сценарии, персоны) не универсальна. Например, может не иметь смысла вообще иметь персоны, если пользователи не взаимодействуют с вашим ИИ напрямую. Идея в том, что вам следует выделить измерения, которые имеют смысл для вашего сценария использования, и сгенерировать данные, которые их охватывают. Скорее всего, вы доработаете их после первого раунда оценок.
Генерация данных
Чтобы построить датасет, вы можете:
Использовать существующие данные: брать выборку реальных взаимодействий или поведения пользователей из вашей ИИ-системы. Генерировать синтетические данные: использовать LLM для создания реалистичных пользовательских вводов, охватывающих различные функции, сценарии и персоны.
Часто вы будете использовать комбинацию обоих подходов, чтобы обеспечить всестороннее покрытие. Синтетические данные не так хороши, как реальные, но это хорошая отправная точка. Также мы используем LLM только для генерации пользовательских вводов, а не ответов LLM или внутреннего поведения системы.
Независимо от того, используете ли вы существующие данные или синтетические, вам нужно хорошее покрытие по тем измерениям, которые вы определили.
Включение информации о системе
При создании тестовых данных используйте свои API и базы данных там, где это уместно. Это создаст реалистичные данные и запустит правильные сценарии. Иногда вам нужно будет написать простые программы, чтобы получить эту информацию. Именно на это ссылается колонка «Предположения» (Assumptions) в примерах ниже.
Примеры промптов для LLM для генерации пользовательских вводов
Вот несколько примеров промптов, которые иллюстрируют, как использовать LLM для генерации синтетических пользовательских вводов для разных комбинаций функций, сценариев и персон:
Генерация синтетических данных
При генерации синтетических данных вам нужно создать только пользовательские вводы. Затем вы подаёте эти вводы в свою ИИ-систему, чтобы сгенерировать ответы ИИ. Важно логировать всё, чтобы вы могли оценить свой ИИ. Подытожим, вот процесс:
Сгенерируйте пользовательские вводы: используйте промпты для LLM, чтобы создать реалистичные пользовательские вводы. Подайте вводы в вашу ИИ-систему: введите пользовательские взаимодействия в ваш ИИ в том виде, в каком он существует сейчас. Зафиксируйте ответы ИИ: запишите ответы ИИ, чтобы сформировать полные взаимодействия. Организуйте взаимодействия: создайте таблицу для хранения пользовательских вводов, ответов ИИ и релевантных метаданных.
Сколько данных нужно генерировать?
Здесь нет правильного ответа. Как минимум, вам нужно сгенерировать достаточно данных, чтобы у вас были примеры для каждой комбинации измерений (в этом игрушечном примере: функции, сценарии и персоны). Однако вам также стоит продолжать генерировать данные, пока вы не почувствуете, что перестали видеть новые виды отказов. Объём данных, который я генерирую, существенно варьируется в зависимости от сценария использования.
А синтетические данные действительно работают?
Возможно, вы скептически относитесь к использованию синтетических данных. В конце концов, это не реальные данные, так как же они могут быть хорошей заменой? По моему опыту, это работает на удивление хорошо. Некоторые из моих любимых ИИ-продуктов, например Hex, используют синтетические данные для своих evals:
«LLM на удивление хороши в генерации отличных — и разнообразных — примеров пользовательских промптов. Это может быть полезно как для функций приложения, так и, неожиданно, для построения Evals. Если это звучит немного как Большая Языковая Змея, поедающая собственный хвост, — я был удивлён не меньше вашего! Всё, что я могу сказать: это работает, выкатывайте.» Bryan Bischof, Head of AI Engineering в Hex
Дальнейшие шаги
Когда ваш датасет готов, наступает самая важная часть: заставить вашего главного эксперта предметной области оценить взаимодействия.
Шаг 3: направьте эксперта предметной области выносить суждения pass/fail с критиками
Задача эксперта предметной области — сосредоточиться на одном: «Достиг ли ИИ желаемого результата?» Никаких сложных шкал оценок или множества метрик. Просто чёткое решение pass или fail. В дополнение к решению pass/fail эксперт предметной области должен написать критику, объясняющую его рассуждения.
Почему важны простые метрики pass/fail?
Ясность и фокус: бинарное решение заставляет всех задуматься о том, что действительно важно. Оно упрощает оценку до единственного, ключевого вопроса. Применимые инсайты: суждения pass/fail легко интерпретировать и действовать на их основе. Они помогают быстро определить, удовлетворяет ли ИИ потребности пользователя. Заставляет формулировать ожидания: когда эксперты предметной области должны решить, проходит взаимодействие или нет, они вынуждены чётко формулировать свои ожидания. Этот процесс раскрывает нюансы и невысказанные предположения о том, как должен вести себя ИИ. Эффективное использование ресурсов: делает процесс оценки управляемым, особенно на старте. Вы избегаете увязания в детальных метриках, которые пока могут не иметь смысла.
Роль критик
Наряду с бинарным суждением pass/fail важно написать подробную критику сгенерированного LLM результата. Эти критики:
Улавливают нюансы: критика позволяет отметить, что что-то было в основном правильно, но имело области для улучшения. Направляют улучшения: подробная обратная связь даёт конкретные инсайты о том, как можно усовершенствовать ИИ. Балансируют простоту и глубину: в то время как pass/fail даёт чёткий вердикт, критика предлагает глубину, необходимую для понимания рассуждений, стоящих за суждением.
Зачем писать критики?
На практике эксперты предметной области могут не до конца усвоить все критерии суждения. Заставляя их принимать решение pass/fail и объяснять свои рассуждения, вы помогаете им прояснить их ожидания и предоставить ценные ориентиры для доработки ИИ.
«Но моя задача сложная!» Поверьте мне — начало с простого заставляет вас сосредоточиться на том, что действительно важно. Вы можете добавить больше сложности позже, если потребуется.
Примеры хороших критик
Чтобы проиллюстрировать, как на практике работают простые суждения pass/fail в сочетании с подробными критиками, вот таблица с примерами пользовательских взаимодействий с ИИ-ассистентом. Таблица включает как проходы (passes), так и отказы (fails), с критиками, объясняющими, почему ИИ получил такое суждение. В случаях, когда ИИ прошёл, несмотря на критические проблемы, критика выделяет эти аспекты и обосновывает, почему он всё же прошёл в целом. Для проваленных взаимодействий критика объясняет критические элементы, которые привели к отказу.
Эти примеры показывают, как ИИ может получить суждения как «Pass», так и «Fail». В критиках:
Для проходов мы объясняем, почему ИИ преуспел в удовлетворении основной потребности пользователя, даже если были критические аспекты, которые можно улучшить. Мы выделяем эти области для улучшения, обосновывая при этом общее проходное суждение. Для отказов мы выявляем критические элементы, которые привели к провалу, объясняя, почему ИИ не достиг главной цели пользователя или поставил под угрозу важные факторы, такие как пользовательский опыт или безопасность.
Самое важное: критика должна быть достаточно подробной, чтобы вы могли использовать её в few-shot-промпте для LLM-судьи. Иными словами, она должна быть настолько подробной, чтобы её мог понять новый сотрудник. Излишняя краткость — распространённая ошибка.
Обратите внимание, что примеры пользовательских взаимодействий с ИИ упрощены для краткости — но вам может потребоваться дать эксперту предметной области больше контекста для вынесения суждения. Об этом — позже.
На этом этапе вам не нужно проводить анализ первопричин технических причин того, почему ИИ потерпел неудачу. Часто полезно получить представление об общем поведении, прежде чем погружаться в детали.
Не отклоняйтесь от бинарных суждений pass/fail на старте
Распространённая ошибка — отклонение от бинарных суждений pass/fail. Давайте вернёмся к дашборду из начала статьи:
Если ваши оценки состоят из кучи метрик, которые LLM оценивает по шкале 1-5 (или любой другой шкале), вы делаете это неправильно. Давайте разберём, почему.
Это неприменимо на практике: люди не знают, что делать с тройкой или четвёркой. Не сразу очевидно, чем это число лучше двойки. Вам нужно иметь возможность сказать «это взаимодействие прошло, потому что…» и «это взаимодействие провалилось, потому что…». Чаще всего эти метрики не имеют значения. Каждый раз, когда я анализировал данные о суждениях экспертов предметной области, они, как правило, не коррелировали с такого рода метриками. Когда эксперт предметной области выносит бинарное суждение, вы можете понять, что действительно важно.
Вот почему я ненавижу готовые метрики, которые поставляются со многими фреймворками оценки. Они склонны сбивать людей с пути.
Распространённые возражения против суждений pass/fail:
«Бизнес сказал, что важны эти 8 измерений, поэтому нам нужно оценивать их все». «Нам нужно иметь возможность сказать, почему взаимодействие прошло или провалилось».
Я гарантирую вам: если кто-то говорит, что нужно измерять 8 вещей по шкале 1-5, он не знает, что именно ищет. Он просто гадает. Вы должны позволить эксперту предметной области вести процесс и выносить суждение pass/fail с критиками, чтобы вы могли понять, что действительно важно. Стойте на своём здесь.
Облегчите эксперту предметной области проверку данных
Наконец, вам нужно убрать любые препятствия при проверке данных. Я писал об этом здесь. Иногда можно просто использовать электронную таблицу. Это вопрос здравого смысла — что окажется проще всего для эксперта предметной области. Я обнаружил, что мне часто приходится предоставлять дополнительный контекст, чтобы помочь эксперту предметной области понять пользовательское взаимодействие, например:
Метаданные о пользователе, такие как его местоположение, тарифный уровень подписки и т. д. Дополнительный контекст о системе, такой как текущее время, уровни запасов и т. д. Ресурсы, чтобы вы могли проверить правильность ответа ИИ (например, возможность искать в базе данных и т. п.)
Все эти данные должны быть представлены на одном экране, чтобы эксперт предметной области мог их проверить без лишних усилий. Вот почему я рекомендую построить простое веб-приложение для проверки данных.
Сколько примеров вам нужно?
Количество необходимых примеров зависит от сложности задачи. Моё эвристическое правило: я начинаю примерно с 30 примеров и продолжаю до тех пор, пока не перестаю видеть новые виды отказов. С этого момента я продолжаю, пока не перестаю узнавать что-то новое.
Далее мы рассмотрим, как использовать эти данные для построения LLM-судьи.
Шаг 4: исправьте ошибки
После изучения данных вы, вероятно, обнаружите ошибки в своей ИИ-системе. Вместо того чтобы мчаться вперёд и строить LLM-судью, вам стоит исправить любые очевидные ошибки. Помните, что весь смысл LLM-as-a-judge в том, чтобы помочь вам найти эти ошибки, поэтому совершенно нормально, если вы найдёте их раньше!
Если вы уже разработали evals Уровня 1, как описано в моём предыдущем посте, у вас не должно быть повсеместных ошибок. Тем не менее, эти ошибки иногда могут проскальзывать. Если вы найдёте повсеместные ошибки, исправьте их и вернитесь к шагу 3. Продолжайте итерации, пока не почувствуете, что стабилизировали свою систему.
Шаг 5: стройте свой LLM-as-a-judge итеративно
Скрытая сила критик
Вы не можете написать хороший промпт для судьи, пока не увидели данные. Статья Shankar et al. «Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences» хорошо это резюмирует:
чтобы оценивать результаты, людям нужно экстернализировать и определить свои критерии оценки; однако сам процесс оценки результатов помогает им определить эти самые критерии. Мы называем это явление дрейфом критериев (criteria drift), и оно подразумевает, что невозможно полностью определить критерии оценки до того, как человек начнёт оценивать результаты LLM.
Начните с примеров от эксперта
Позвольте поделиться реальным примером построения LLM-судьи, который вы можете применить к своему сценарию. Когда я помогал Honeycomb создавать их функцию Query Assistant, нам нужен был способ оценивать, генерирует ли ИИ хорошие запросы. Вот как выглядел наш промпт для 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) в тегах
В промпте выше примеры критик зафиксированы. Более продвинутый подход — включать примеры динамически в зависимости от элемента, который вы оцениваете. Подробнее можно узнать в этом посте о Continual In-Context Learning.
Продолжайте итерировать промпт до схождения с экспертом предметной области
В этом случае я использовал низкотехнологичный подход для итерации над промптом. Я отправил Phillip электронную таблицу со следующей информацией:
NLQ Сгенерированный запрос Критика Итог (pass или fail)
Затем Phillip заполнял свою собственную версию таблицы своими критиками. Я использовал это для итеративного улучшения промпта. Таблица выглядела так:
Я также отслеживал уровень согласия (agreement rate) с течением времени, чтобы убедиться, что мы сходимся к хорошему промпту.
В этом примере мы использовали согласие между моделью и оценщиком-человеком, потому что наш датасет был примерно сбалансирован (около 50% случаев были отказами). Однако использование простого согласия (raw agreement) в целом не рекомендуется и может вводить в заблуждение при несбалансированных классах. Вместо этого вам обычно следует измерять precision и recall по отдельности, чтобы получить более точную картину согласованности вашего судьи.
Нам понадобилось всего три итерации, чтобы достичь более 90% согласия между LLM и Phillip. Ваши результаты могут отличаться в зависимости от сложности задачи. Например, Swyx проводил похожий процесс сотни раз для AI News, чрезвычайно популярного новостного агрегатора с высококачественными рекомендациями. Качество ИИ, обусловленное этим процессом, и есть причина того, что этот продукт получил признание критиков.
Как оптимизировать промпт LLM-судьи?
Обычно я подгоняю промпты вручную. Мне не особо везло с оптимизаторами промптов вроде DSPy. Однако мой друг Eugene Yan только что выпустил многообещающий инструмент под названием ALIGN Eval. Он мне нравится, потому что он прост и эффективен. Также не забывайте про подход continual in-context learning, упомянутый ранее — он может быть эффективен при правильной реализации.
В редких случаях я мог бы дообучить (fine-tune) судью, но предпочитаю этого не делать. Подробнее об этом я говорю в разделе FAQ.
Человеческая сторона процесса
Во время этого процесса произошло нечто неожиданное. Phillip Carter, наш эксперт предметной области в Honeycomb, обнаружил, что просмотр критик от LLM помог ему более чётко сформулировать собственные критерии оценки. Он сказал:
«Наблюдение за тем, как LLM раскладывает свои рассуждения, заставило меня осознать, что я был непоследователен в том, как оценивал некоторые краевые случаи».
Это паттерн, который я наблюдал неоднократно — процесс построения LLM-судьи часто помогает стандартизировать критерии оценки.
Более того, поскольку этот процесс заставляет эксперта предметной области внимательно изучать данные, я всегда обнаруживаю новые инсайты о продукте, возможностях ИИ и потребностях пользователей. Получаемая выгода часто ценнее, чем создание самого LLM-судьи!
Как часто следует проводить оценку?
Я провожу этот человеческий review через регулярные интервалы и всякий раз, когда происходит что-то существенное. Например, если я обновляю модель, я запускаю процесс заново. Я не подхожу к этому слишком научно; вместо этого я полагаюсь на своё лучшее суждение. Также отмечу, что после первых двух итераций я склонен больше фокусироваться на ошибках, чем на случайной выборке. Например, если я нахожу ошибку, я ищу больше примеров, которые, как мне кажется, могут вызвать ту же ошибку. Тем не менее, я всегда делаю и немного случайной выборки.
Что, если это не сработает?
Я видел, как этот процесс терпит неудачу, когда:
ИИ слишком широко спроектирован: пример — чат-бот в SaaS-продукте, который обещает сделать всё, что угодно. Процесс не соблюдается правильно: не используется главный эксперт предметной области, не пишутся надлежащие критики и т. д. Ожидания относительно согласованности нереалистичны или недостижимы.
В каждом из этих случаев я стараюсь устранить первопричину, а не пытаться насильно добиться согласованности. Иногда вы можете не суметь достичь желаемой согласованности и вам придётся больше опираться на человеческую разметку. Тем не менее, следуя описанному здесь процессу, вы получите метрики, которые помогут понять, насколько вы можете доверять LLM-судье.
Ошибки, которые я замечал в промптах LLM-судей
Большинство ошибок, которые я видел в промптах LLM-судей, связаны с тем, что не предоставляются хорошие примеры:
Не предоставляются вообще никакие критики. Пишутся чрезвычайно краткие критики. Не предоставляется внешний контекст. Ваши примеры должны содержать ту же информацию, которую вы используете для оценки, включая внешнюю информацию, такую как метаданные пользователя, информация о системе и т. д. Не предоставляются разнообразные примеры. Вам нужно широкое разнообразие примеров, чтобы гарантировать, что ваш судья работает для широкого разнообразия вводов.
Иногда вы можете столкнуться с трудностями в том, чтобы уместить всё необходимое в промпт, и вам, возможно, придётся проявить изобретательность в структурировании примеров. Однако это становится всё меньшей проблемой благодаря расширяющимся контекстным окнам и кэшированию промптов (prompt caching).
Шаг 6: проведите анализ ошибок
После того как вы создали LLM-as-a-judge, у вас будет датасет пользовательских взаимодействий с ИИ и суждений LLM. Если ваши метрики показывают приемлемое согласие между экспертом предметной области и LLM-судьёй, вы можете применить этого судью к реальным или синтетическим взаимодействиям. После этого вы можете рассчитать частоту ошибок для разных измерений ваших данных. Вам следует рассчитывать ошибку только на невиданных ранее данных, чтобы убедиться, что вы не получаете смещённых результатов.
Например, если вы сегментировали данные по персоне, сценарию, функции и т. д., ваш анализ данных может выглядеть так:
Частота ошибок по ключевым измерениям
Классифицируйте трейсы
Как только вы знаете, где находятся ошибки, вы можете провести анализ ошибок, чтобы добраться до их первопричины. Мой любимый способ — посмотреть на примеры каждого типа ошибок и классифицировать их вручную. Я рекомендую использовать для этого электронную таблицу. Например, трейс для отслеживания заказа (Order tracking), где нет совпадений для новых пользователей, может выглядеть так:
В этом примере трейса пользователь предоставляет недействительный номер заказа. ИИ правильно определяет, что номер заказа недействителен, но даёт бесполезный ответ. Если вы не знакомы с логированием LLM-трейсов, обратитесь к моему предыдущему посту про evals.
Обратите внимание, что этот трейс отформатирован для удобства чтения.
{ "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 и итерируйте, пока не будете удовлетворены. Обратите внимание, что каждый раз, когда вы исправляете ошибку, вам стоит попытаться написать для неё тест-кейс. Иногда это может быть assertion в вашем наборе тестов, но в других случаях вам, возможно, придётся создать более «специализированного» LLM-судью для этих отказов. Об этом мы поговорим далее.
Чтобы делать это хорошо, нужна грамотность в работе с данными
Исследование ваших данных на практике гораздо сложнее, чем я изобразил это в этом посте. Это требует чутья на данные, которое приходит только с практикой. Также помогает базовое знакомство со статистикой и инструментами анализа данных. Мой любимый пост о грамотности в работе с данными — вот этот от Jason Liu и Eugene Yan.
Шаг 7: создайте более специализированных LLM-судей (при необходимости)
Теперь, когда у вас есть представление о том, где находятся проблемы в вашем ИИ, вы можете решить, где и стоит ли вкладываться в более целевых LLM-судей. Например, если вы обнаружите, что ИИ испытывает трудности с правильным цитированием источников, вы можете создать целевой eval для этого. Для некоторых ошибок вам, возможно, даже не понадобится LLM-судья (а вместо этого можно использовать assertion на основе кода).
Ключевой вывод: не переходите сразу к использованию специализированных LLM-судей, пока вы не прошли этот процесс critique shadowing. Это поможет вам обосновать, куда вкладывать своё время.
Резюме Critique Shadowing
Использование LLM в роли судьи может упростить ваш процесс оценки ИИ, если подойти к нему правильно. Вот визуальная иллюстрация процесса (под диаграммой также есть описание процесса):
Процесс Critique Shadowing итеративен, с петлями обратной связи. Перечислим шаги:
Найдите главного эксперта предметной области. Создайте датасет. Сгенерируйте разнообразные примеры, охватывающие ваши сценарии использования. Включите реальные или синтетические пользовательские взаимодействия. Эксперт предметной области проверяет данные. Эксперт выносит суждения pass/fail. Эксперт пишет подробные критики, объясняющие его рассуждения. Исправьте ошибки (если найдены). Устраните любые проблемы, обнаруженные во время review. Вернитесь к review эксперта, чтобы проверить исправления. Вернитесь к шагу 3, если найдены ошибки. Постройте LLM-судью. Создайте промпт, используя примеры эксперта. Протестируйте на суждениях эксперта. Дорабатывайте промпт, пока согласие не станет удовлетворительным. Проведите анализ ошибок. Рассчитайте частоту ошибок по разным измерениям. Выявите паттерны и первопричины. Исправьте ошибки и вернитесь к шагу 3 при необходимости. Создайте специализированных судей по мере необходимости.
Этот процесс по-настоящему никогда не заканчивается. Он повторяется периодически или когда происходят существенные изменения.
Ценность создал, в конце концов, не судья
Настоящая ценность этого процесса — в изучении ваших данных и тщательном анализе. Хотя ИИ-судья может быть полезным инструментом, именно прохождение этого процесса приводит к результатам. Я бы даже сказал, что создание LLM-судьи — это приятный «хак», который я использую, чтобы заставить людей внимательно посмотреть на их данные!
Именно так. Настоящая бизнес-ценность приходит от изучения ваших данных. Но что ж, хоть горшком назови.
Действительно ли вам это нужно?
Уф, это выглядит как куча работы! Действительно ли вам это нужно? Что ж, смотря по обстоятельствам. Есть случаи, когда можно срезать путь в этом процессе. Например, скажем:
Вы независимый разработчик, который к тому же является экспертом предметной области. Вы работаете с тестовыми данными, которые уже доступны (твиты и т. п.). Изучение данных не затратно (например, вы можете вручную просмотреть достаточно данных за несколько часов).
В этом сценарии вы можете сразу перейти к чему-то похожему на шаг 3 и тут же начать изучать данные. Также, поскольку изучение данных не так затратно, вероятно, нормально просто провести анализ ошибок без судьи (по крайней мере, поначалу). Вы можете сразу же включить то, что узнали, обратно в свою основную модель. Этот пример не исчерпывающий, но даёт представление о том, как можно адаптировать этот процесс под свои нужды.
Однако вы никогда не сможете полностью исключить изучение ваших данных! Это именно тот шаг, который большинство людей пропускают. Не будьте таким человеком.
FAQ
Я получил много вопросов на эту тему. Вот ответы на самые частые из них:
Если у меня есть хороший LLM-судья, разве это не тот же LLM, который я и хотел бы использовать?
Эффективные судьи часто используют более крупные модели или больше вычислений (через более длинные промпты, chain-of-thought и т. д.), чем системы, которые они оценивают.
Однако если стоимость самой мощной LLM не запретительна и латентность не является проблемой, то, возможно, стоит подумать о том, чтобы по-другому распределить свои усилия. В этом случае может иметь смысл вложить больше усилий в специализированных LLM-судей, assertion на основе кода и A/B-тестирование. Тем не менее, вам всё равно следует пройти процесс изучения данных и критики выводов LLM, прежде чем вы примете на вооружение специализированных судей.
Рекомендуете ли вы дообучать (fine-tune) судей?
Я предпочитаю не дообучать LLM-судей. Я бы лучше потратил усилия на дообучение самой LLM. Тем не менее, дообучение guardrails или других специализированных судей может быть полезным (особенно если это небольшие классификаторы).
В качестве смежного замечания: вы можете использовать LLM-судью для курирования и преобразования данных для дообучения вашей основной модели. Например, вы можете использовать судью, чтобы:
Устранять плохие примеры для дообучения. Генерировать более качественные выводы (опираясь на критику). Симулировать качественные chain-of-thought с помощью критик.
Использование LLM-судьи для улучшения данных для дообучения ещё более привлекательно, когда вы пытаетесь дистиллировать большую LLM в меньшую. Детали дообучения выходят за рамки данного поста. Если вам интересно узнать больше, см. эти ресурсы.
Что не так с готовыми LLM-судьями?
Строго говоря, с ними нет ничего плохого. Просто многих людей они сбивают с пути. Если вы дисциплинированы, вы можете применить их к своим данным и посмотреть, говорят ли они вам что-то ценное. Однако я обнаружил, что они, как правило, вызывают больше путаницы, чем приносят пользы.
Как вы оцениваете самого LLM-судью?
Вы соберёте метрики согласия между экспертом предметной области и LLM-судьёй. Это говорит вам о том, насколько вы можете доверять судье и в каких сценариях. Вашему эксперту предметной области не нужно проверять каждый отдельный пример — вам нужна лишь репрезентативная выборка, чтобы иметь надёжную статистику.
Какую модель вы используете для LLM-судьи?
Для того типа судьи, что описан в этом посте, я предпочитаю использовать самую мощную модель, которую могу себе позволить в рамках своего бюджета по стоимости/латентности. Этот бюджет может отличаться от бюджета моей основной модели, в зависимости от количества примеров, которые мне нужно оценить. Это может существенно варьироваться в зависимости от сценария использования.
А как насчёт guardrails?
Guardrails — это отдельная, но смежная тема. Это способ не дать LLM сказать/сделать что-то вредное или неуместное. Этот пост сосредоточен на том, чтобы помочь вам создать судью, согласованного с бизнес-целями, особенно на старте.
Я использую LLM в роли судьи и получаю огромную пользу, но я не следовал этому подходу.
Я вам верю. Этот пост — не единственный способ использовать LLM в роли судьи. На самом деле я видел, как люди используют LLM в роли судьи самыми разными творческими способами, включая ранжирование, классификацию, выбор модели и так далее. Я сосредоточен на подходе, который хорошо работает, когда вы только начинаете, и помогает избежать ловушек запутывающего разрастания метрик. Тем не менее, общий процесс изучения данных по-прежнему остаётся центральным, независимо от того, какого рода судью вы строите.
Как выбрать между традиционными методами ML, LLM-as-a-judge и человеческой разметкой?
Ответ на этот (и многие другие) вопрос таков: делайте самое простое, что работает. И простое не всегда означает традиционные методы ML. В зависимости от вашей ситуации может оказаться проще использовать LLM API в качестве классификатора, чем обучать модель и развёртывать её.
Можно ли делать судей из небольших моделей?
Да, потенциально. Я использовал для судей только более крупные модели. Ответ на этот вопрос вам нужно основывать на данных (то есть на согласии с экспертом предметной области).
Как обеспечить постоянство при обновлении вашей LLM-модели?
Вам нужно снова пройти процесс и измерить результаты.
Как постепенно убрать человека из контура, чтобы масштабировать это?
Вам не нужно, чтобы эксперт предметной области оценивал каждый отдельный пример. Вам нужна лишь репрезентативная выборка. Я не думаю, что можно полностью исключить людей, потому что LLM всё равно нужно с чем-то согласовывать, и это что-то обычно человек. По мере того как ваша система оценки становится лучше, она естественным образом снижает объём требуемых человеческих усилий.
Ресурсы
Вот некоторые из ресурсов, которые я рекомендую для более глубокого изучения этой темы:
Your AI Product Needs Evals: этот пост — предшественник данного, он даёт обзор высокого уровня по 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 Evals с некоторыми дополнительными инструментами, на которые стоит взглянуть. 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. Ранний доступ к новому контенту. Никакого спама — только честные мысли и открытия.