Using LLM-as-a-Judge For Evaluation: A Complete Guide –

Earlier this year, I wrote Your AI product needs evals. Many of you asked, “How do I get started with LLM-as-a-judge?” This guide shares what I’ve learned after helping over 30 companies set up their evaluation systems.

В начале этого года я написал статью Вашему ИИ-продукту нужны evals. Многие из вас спрашивали: «Как начать работу с LLM-as-a-judge?» В этом руководстве я делюсь тем, что узнал, помогая более чем 30 компаниям выстроить их системы оценки.

The Problem: AI Teams Are Drowning in Data

Проблема: ИИ-команды тонут в данных

Ever spend weeks building an AI system, only to realize you have no idea if it’s actually working? You’re not alone. I’ve noticed teams repeat the same mistakes when using LLMs to evaluate AI outputs:

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

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

The result? Teams end up buried under mountains of metrics or data they don’t trust and can’t use. Progress grinds to a halt. Everyone gets frustrated.

Результат? Команды оказываются погребены под горами метрик или данных, которым они не доверяют и которые не могут использовать. Прогресс останавливается. Все раздражены.

For example, it’s not uncommon for me to see dashboards that look like this:

Например, мне нередко доводится видеть дашборды, которые выглядят так:

Tracking a bunch of scores on a 1-5 scale is often a sign of a bad eval process (I’ll discuss why later). In this post, I’ll show you how to avoid these pitfalls. The solution is to use a technique that I call “Critique Shadowing”. Here’s how to do it, step by step.

Отслеживание кучи оценок по шкале 1-5 часто является признаком плохого процесса оценки (почему — обсужу позже). В этом посте я покажу, как избежать этих ловушек. Решение — использовать технику, которую я называю «Critique Shadowing» (тенью критики). Вот как это делать, шаг за шагом.

Step 1: Find The Principal Domain Expert

Шаг 1: найдите того самого главного эксперта предметной области

In most organizations there is usually one (maybe two) key individuals whose judgment is crucial for the success of your AI product. These are the people with deep domain expertise or represent your target users. Identifying and involving this Principal Domain Expert early in the process is critical.

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

Why is finding the right domain expert so important?

Почему так важно найти правильного эксперта предметной области?

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

Examples of Principal Domain Experts:

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

Психолог для ИИ-ассистента в сфере ментального здоровья. Юрист для ИИ, анализирующего юридические документы. Директор по клиентскому сервису для чат-бота поддержки. Ведущий преподаватель или разработчик учебных программ для образовательного ИИ-инструмента.

In a smaller company, this might be the CEO or founder. If you are an independent developer, you should be the domain expert (but be honest with yourself about your expertise).

В небольшой компании это может быть CEO или основатель. Если вы независимый разработчик, экспертом предметной области должны быть вы сами (но будьте честны с собой относительно своей экспертизы).

If you must rely on leadership, you should regularly validate their assumptions against real user feedback.

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

Many developers attempt to act as the domain expert themselves, or find a convenient proxy (ex: their superior). This is a recipe for disaster. People will have varying opinions about what is acceptable, and you can’t make everyone happy. What’s important is that your principal domain expert is satisfied.

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

Remember: This doesn’t have to take a lot of the domain expert’s time. Later in this post, I’ll discuss how you can make the process efficient. Their involvement is absolutely critical to the AI’s success.

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

Next Steps

Дальнейшие шаги

Once you’ve found your expert, we need to give them the right data to review. Let’s talk about how to do that next.

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

Step 2: Create a Dataset

Шаг 2: создайте датасет

With your principal domain expert on board, the next step is to build a dataset that captures problems that your AI will encounter. It’s important that the dataset is diverse and represents the types of interactions that your AI will have in production.

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

Why a Diverse Dataset Matters

Почему важен разнообразный датасет

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

Dimensions for Structuring Your Dataset

Измерения для структурирования вашего датасета

You want to define dimensions that make sense for your use case. For example, here are ones that I often use for B2C applications:

Вам нужно определить измерения, которые имеют смысл для вашего сценария использования. Например, вот те, которые я часто использую для B2C-приложений:

Функции (Features): конкретные возможности вашего ИИ-продукта. Сценарии (Scenarios): ситуации или проблемы, с которыми ИИ может столкнуться и которые ему нужно обработать. Персоны (Personas): репрезентативные профили пользователей с отличительными характеристиками и потребностями.

Examples of Features, Scenarios, and Personas

Примеры функций, сценариев и персон

Features

Функции

Scenarios

Сценарии

Scenarios are situations the AI needs to handle, (not based on the outcome of the AI’s response).

Сценарии — это ситуации, которые ИИ нужно обработать (не основанные на результате ответа ИИ).

Personas

Персоны

This taxonomy is not universal

Эта таксономия не универсальна

This taxonomy (features, scenarios, personas) is not universal. For example, it may not make sense to even have personas if users aren’t directly engaging with your AI. The idea is you should outline dimensions that make sense for your use case and generate data that covers them. You’ll likely refine these after the first round of evaluations.

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

Generating Data

Генерация данных

To build your dataset, you can:

Чтобы построить датасет, вы можете:

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

Often, you’ll do a combination of both to ensure comprehensive coverage. Synthetic data is not as good as real data, but it’s a good starting point. Also, we are only using LLMs to generate the user inputs, not the LLM responses or internal system behavior.

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

Regardless of whether you use existing data or synthetic data, you want good coverage across the dimensions you’ve defined.

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

Incorporating System Information

Включение информации о системе

When making test data, use your APIs and databases where appropriate. This will create realistic data and trigger the right scenarios. Sometimes you’ll need to write simple programs to get this information. That’s what the “Assumptions” column is referring to in the examples below.

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

Example LLM Prompts for Generating User Inputs

Примеры промптов для LLM для генерации пользовательских вводов

Here are some example prompts that illustrate how to use an LLM to generate synthetic user inputs for different combinations of features, scenarios, and personas:

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

Generating Synthetic Data

Генерация синтетических данных

When generating synthetic data, you only need to create the user inputs. You then feed these inputs into your AI system to generate the AI’s responses. It’s important that you log everything so you can evaluate your AI. To recap, here’s the process:

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

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

How much data should you generate?

Сколько данных нужно генерировать?

There is no right answer here. At a minimum, you want to generate enough data so that you have examples for each combination of dimensions (in this toy example: features, scenarios, and personas). However, you also want to keep generating more data until you feel like you have stopped seeing new failure modes. The amount of data I generate varies significantly depending on the use case.

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

Does synthetic data actually work?

А синтетические данные действительно работают?

You might be skeptical of using synthetic data. After all, it’s not real data, so how can it be a good proxy? In my experience, it works surprisingly well. Some of my favorite AI products, like Hex use synthetic data to power their evals:

Возможно, вы скептически относитесь к использованию синтетических данных. В конце концов, это не реальные данные, так как же они могут быть хорошей заменой? По моему опыту, это работает на удивление хорошо. Некоторые из моих любимых ИИ-продуктов, например Hex, используют синтетические данные для своих evals:

“LLMs are surprisingly good at generating excellent - and diverse - examples of user prompts. This can be relevant for powering application features, and sneakily, for building Evals. If this sounds a bit like the Large Language Snake is eating its tail, I was just as surprised as you! All I can say is: it works, ship it.” Bryan Bischof, Head of AI Engineering at Hex

«LLM на удивление хороши в генерации отличных — и разнообразных — примеров пользовательских промптов. Это может быть полезно как для функций приложения, так и, неожиданно, для построения Evals. Если это звучит немного как Большая Языковая Змея, поедающая собственный хвост, — я был удивлён не меньше вашего! Всё, что я могу сказать: это работает, выкатывайте.» Bryan Bischof, Head of AI Engineering в Hex

Next Steps

Дальнейшие шаги

With your dataset ready, now comes the most important part: getting your principal domain expert to evaluate the interactions.

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

Step 3: Direct The Domain Expert to Make Pass/Fail Judgments with Critiques

Шаг 3: направьте эксперта предметной области выносить суждения pass/fail с критиками

The domain expert’s job is to focus on one thing: “Did the AI achieve the desired outcome?” No complex scoring scales or multiple metrics. Just a clear pass or fail decision. In addition to the pass/fail decision, the domain expert should write a critique that explains their reasoning.

Задача эксперта предметной области — сосредоточиться на одном: «Достиг ли ИИ желаемого результата?» Никаких сложных шкал оценок или множества метрик. Просто чёткое решение pass или fail. В дополнение к решению pass/fail эксперт предметной области должен написать критику, объясняющую его рассуждения.

Why are simple pass/fail metrics important?

Почему важны простые метрики pass/fail?

Ясность и фокус: бинарное решение заставляет всех задуматься о том, что действительно важно. Оно упрощает оценку до единственного, ключевого вопроса. Применимые инсайты: суждения pass/fail легко интерпретировать и действовать на их основе. Они помогают быстро определить, удовлетворяет ли ИИ потребности пользователя. Заставляет формулировать ожидания: когда эксперты предметной области должны решить, проходит взаимодействие или нет, они вынуждены чётко формулировать свои ожидания. Этот процесс раскрывает нюансы и невысказанные предположения о том, как должен вести себя ИИ. Эффективное использование ресурсов: делает процесс оценки управляемым, особенно на старте. Вы избегаете увязания в детальных метриках, которые пока могут не иметь смысла.

The Role of Critiques

Роль критик

Alongside a binary pass/fail judgment, it’s important to write a detailed critique of the LLM-generated output. These critiques:

Наряду с бинарным суждением pass/fail важно написать подробную критику сгенерированного LLM результата. Эти критики:

Улавливают нюансы: критика позволяет отметить, что что-то было в основном правильно, но имело области для улучшения. Направляют улучшения: подробная обратная связь даёт конкретные инсайты о том, как можно усовершенствовать ИИ. Балансируют простоту и глубину: в то время как pass/fail даёт чёткий вердикт, критика предлагает глубину, необходимую для понимания рассуждений, стоящих за суждением.

Why Write Critiques?:

Зачем писать критики?

In practice, domain experts may not have fully internalized all the judgment criteria. By forcing them to make a pass/fail decision and explain their reasoning, they clarify their expectations and provide valuable guidance for refining the AI.

На практике эксперты предметной области могут не до конца усвоить все критерии суждения. Заставляя их принимать решение pass/fail и объяснять свои рассуждения, вы помогаете им прояснить их ожидания и предоставить ценные ориентиры для доработки ИИ.

“But my problem is complex!” Trust me—starting simple forces you to focus on what truly matters. You can introduce more complexity later if needed.

«Но моя задача сложная!» Поверьте мне — начало с простого заставляет вас сосредоточиться на том, что действительно важно. Вы можете добавить больше сложности позже, если потребуется.

Examples of Good Critiques

Примеры хороших критик

To illustrate how simple pass/fail judgments combined with detailed critiques work in practice, here’s a table showcasing examples of user interactions with an AI assistant. The table includes both passes and fails, with critiques explaining why the AI received that judgment. In cases where the AI passed despite critical issues, the critique highlights these aspects and justifies why it still passed overall. For failed interactions, the critique explains the critical elements that led to the failure.

Чтобы проиллюстрировать, как на практике работают простые суждения pass/fail в сочетании с подробными критиками, вот таблица с примерами пользовательских взаимодействий с ИИ-ассистентом. Таблица включает как проходы (passes), так и отказы (fails), с критиками, объясняющими, почему ИИ получил такое суждение. В случаях, когда ИИ прошёл, несмотря на критические проблемы, критика выделяет эти аспекты и обосновывает, почему он всё же прошёл в целом. Для проваленных взаимодействий критика объясняет критические элементы, которые привели к отказу.

These examples demonstrate how the AI can receive both “Pass” and “Fail” judgments. In the critiques:

Эти примеры показывают, как ИИ может получить суждения как «Pass», так и «Fail». В критиках:

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

Most importantly, the critique should be detailed enough so that you can use it in a few-shot prompt for a LLM judge. In other words, it should be detailed enough that a new employee could understand it. Being too terse is a common mistake.

Самое важное: критика должна быть достаточно подробной, чтобы вы могли использовать её в few-shot-промпте для LLM-судьи. Иными словами, она должна быть настолько подробной, чтобы её мог понять новый сотрудник. Излишняя краткость — распространённая ошибка.

Note that the example user interactions with the AI are simplified for brevity - but you might need to give the domain expert more context to make a judgement. More on that later.

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

At this point, you don’t need to perform a root cause analysis into the technical reasons behind why the AI failed. Many times, it’s useful to get a sense of overall behavior before diving into the weeds.

На этом этапе вам не нужно проводить анализ первопричин технических причин того, почему ИИ потерпел неудачу. Часто полезно получить представление об общем поведении, прежде чем погружаться в детали.

Don’t stray from binary pass/fail judgments when starting out

Не отклоняйтесь от бинарных суждений pass/fail на старте

A common mistake is straying from binary pass/fail judgments. Let’s revisit the dashboard from earlier:

Распространённая ошибка — отклонение от бинарных суждений pass/fail. Давайте вернёмся к дашборду из начала статьи:

If your evaluations consist of a bunch of metrics that LLMs score on a 1-5 scale (or any other scale), you’re doing it wrong. Let’s unpack why.

Если ваши оценки состоят из кучи метрик, которые LLM оценивает по шкале 1-5 (или любой другой шкале), вы делаете это неправильно. Давайте разберём, почему.

Это неприменимо на практике: люди не знают, что делать с тройкой или четвёркой. Не сразу очевидно, чем это число лучше двойки. Вам нужно иметь возможность сказать «это взаимодействие прошло, потому что…» и «это взаимодействие провалилось, потому что…». Чаще всего эти метрики не имеют значения. Каждый раз, когда я анализировал данные о суждениях экспертов предметной области, они, как правило, не коррелировали с такого рода метриками. Когда эксперт предметной области выносит бинарное суждение, вы можете понять, что действительно важно.

This is why I hate off the shelf metrics that come with many evaluation frameworks. They tend to lead people astray.

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

Common Objections to Pass/Fail Judgments:

Распространённые возражения против суждений pass/fail:

«Бизнес сказал, что важны эти 8 измерений, поэтому нам нужно оценивать их все». «Нам нужно иметь возможность сказать, почему взаимодействие прошло или провалилось».

I can guarantee you that if someone says you need to measure 8 things on a 1-5 scale, they don’t know what they are looking for. They are just guessing. You have to let the domain expert drive and make a pass/fail judgment with critiques so you can figure out what truly matters. Stand your ground here.

Я гарантирую вам: если кто-то говорит, что нужно измерять 8 вещей по шкале 1-5, он не знает, что именно ищет. Он просто гадает. Вы должны позволить эксперту предметной области вести процесс и выносить суждение pass/fail с критиками, чтобы вы могли понять, что действительно важно. Стойте на своём здесь.

Make it easy for the domain expert to review data

Облегчите эксперту предметной области проверку данных

Finally, you need to remove all friction from reviewing data. I’ve written about this here. Sometimes, you can just use a spreadsheet. It’s a judgement call in terms of what is easiest for the domain expert. I found that I often have to provide additional context to help the domain expert understand the user interaction, such as:

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

Метаданные о пользователе, такие как его местоположение, тарифный уровень подписки и т. д. Дополнительный контекст о системе, такой как текущее время, уровни запасов и т. д. Ресурсы, чтобы вы могли проверить правильность ответа ИИ (например, возможность искать в базе данных и т. п.)

All of this data needs to be presented on a single screen so the domain expert can review it without jumping through hoops. That’s why I recommend building a simple web app to review data.

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

How many examples do you need?

Сколько примеров вам нужно?

The number of examples you need depends on the complexity of the task. My heuristic is that I start with around 30 examples and keep going until I do not see any new failure modes. From there, I keep going until I’m not learning anything new.

Количество необходимых примеров зависит от сложности задачи. Моё эвристическое правило: я начинаю примерно с 30 примеров и продолжаю до тех пор, пока не перестаю видеть новые виды отказов. С этого момента я продолжаю, пока не перестаю узнавать что-то новое.

Next, we’ll look at how to use this data to build an LLM judge.

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

Step 4: Fix Errors

Шаг 4: исправьте ошибки

After looking at the data, it’s likely you will find errors in your AI system. Instead of plowing ahead and building an LLM judge, you want to fix any obvious errors. Remember, the whole point of the LLM as a judge is to help you find these errors, so it’s totally fine if you find them earlier!

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

If you have already developed Level 1 evals as outlined in my previous post, you should not have any pervasive errors. However, these errors can sometimes slip through the cracks. If you find pervasive errors, fix them and go back to step 3. Keep iterating until you feel like you have stabilized your system.

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

Step 5: Build Your LLM as A Judge, Iteratively

Шаг 5: стройте свой LLM-as-a-judge итеративно

The Hidden Power of Critiques

Скрытая сила критик

You cannot write a good judge prompt until you’ve seen the data. The paper from Shankar et al., “Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences” summarizes this well:

Вы не можете написать хороший промпт для судьи, пока не увидели данные. Статья Shankar et al. «Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences» хорошо это резюмирует:

to grade outputs,people need to externalize and define their evaluation criteria; however, the process of grading outputs helps them to define that very criteria. We dub this phenomenon criteria drift, and it implies thatit is impossible to completely determine evaluation criteria prior to human judging of LLM outputs.

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

Start with Expert Examples

Начните с примеров от эксперта

Let me share a real-world example of building an LLM judge you can apply to your own use case. When I was helping Honeycomb build their Query Assistant feature, we needed a way to evaluate if the AI was generating good queries. Here’s what our LLM judge prompt looked like, including few-shot examples of critiques from our domain expert, Phillip:

Позвольте поделиться реальным примером построения 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: <examples> <example-1> <nlq>show me traces where ip is 10.0.2.90</nlq> <query> { "breakdowns": ["trace.trace_id"], "calculations": [{"op": "COUNT"}], "filters": [{"column": "net.host.ip", "op": "=", "value": "10.0.2.90"}] } </query> <critique> { "critique": "The query correctly filters for traces with an IP address of 10.0.2.90 and counts the occurrences of those traces, grouped by trace.trace_id. The response is good as it meets the requirement of showing traces from a specific IP address without additional complexities.", "outcome": "good" } </critique> </example-1> <example-2> <nlq>show me slowest trace</nlq> <query> { "calculations": [{"column": "duration_ms", "op": "MAX"}], "orders": [{"column": "duration_ms", "op": "MAX", "order": "descending"}], "limit": 1 } </query> <critique> { "critique": "While the query attempts to find the slowest trace using MAX(duration_ms) and ordering correctly, it fails to group by trace.trace_id. Without this grouping, the query only shows the MAX(duration_ms) measurement over time, not the actual slowest trace.", "outcome": "bad" } </critique> </example-2> <example-3> <nlq>count window-hash where window-hash exists per hour</nlq> <query> { "breakdowns": ["window-hash"], "calculations": [{"op": "COUNT"}], "filters": [{"column": "window-hash", "op": "exists"}], "time_range": 3600 } </query> <critique> { "critique": "While the query correctly counts window-hash occurrences, the time_range of 3600 seconds (1 hour) is insufficient for per-hour analysis. When we say 'per hour', we need a time_range of at least 36000 seconds to show meaningful hourly patterns.", "outcome": "bad" } </critique> </example-3> </examples> For the following query, first write a detailed critique explaining your reasoning, then provide a pass/fail judgment in the same format as above. <nlq>{{user_input}}</nlq> <query> {{generated_query}} </query> <critique>

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: show me traces where ip is 10.0.2.90 { "breakdowns": ["trace.trace_id"], "calculations": [{"op": "COUNT"}], "filters": [{"column": "net.host.ip", "op": "=", "value": "10.0.2.90"}] } { "critique": "The query correctly filters for traces with an IP address of 10.0.2.90 and counts the occurrences of those traces, grouped by trace.trace_id. The response is good as it meets the requirement of showing traces from a specific IP address without additional complexities.", "outcome": "good" } show me slowest trace { "calculations": [{"column": "duration_ms", "op": "MAX"}], "orders": [{"column": "duration_ms", "op": "MAX", "order": "descending"}], "limit": 1 } { "critique": "While the query attempts to find the slowest trace using MAX(duration_ms) and ordering correctly, it fails to group by trace.trace_id. Without this grouping, the query only shows the MAX(duration_ms) measurement over time, not the actual slowest trace.", "outcome": "bad" } count window-hash where window-hash exists per hour { "breakdowns": ["window-hash"], "calculations": [{"op": "COUNT"}], "filters": [{"column": "window-hash", "op": "exists"}], "time_range": 3600 } { "critique": "While the query correctly counts window-hash occurrences, the time_range of 3600 seconds (1 hour) is insufficient for per-hour analysis. When we say 'per hour', we need a time_range of at least 36000 seconds to show meaningful hourly patterns.", "outcome": "bad" } For the following query, first write a detailed critique explaining your reasoning, then provide a pass/fail judgment in the same format as above. {{user_input}} {{generated_query}}

Notice how each example includes:

Обратите внимание, что каждый пример включает:

Запрос на естественном языке (NLQ) в тегах Сгенерированный запрос в тегах Критику и итог в тегах

In the prompt above, the example critiques are fixed. An advanced approach is to include examples dynamically based upon the item you are judging. You can learn more in this post about Continual In-Context Learning.

В промпте выше примеры критик зафиксированы. Более продвинутый подход — включать примеры динамически в зависимости от элемента, который вы оцениваете. Подробнее можно узнать в этом посте о Continual In-Context Learning.

Keep Iterating on the Prompt Until Convergence With Domain Expert

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

In this case, I used a low-tech approach to iterate on the prompt. I sent Phillip a spreadsheet with the following information:

В этом случае я использовал низкотехнологичный подход для итерации над промптом. Я отправил Phillip электронную таблицу со следующей информацией:

NLQ Сгенерированный запрос Критика Итог (pass или fail)

Phillip would then fill out his own version of the spreadsheet with his critiques. I used this to iteratively improve the prompt. The spreadsheet looked like this:

Затем Phillip заполнял свою собственную версию таблицы своими критиками. Я использовал это для итеративного улучшения промпта. Таблица выглядела так:

I also tracked agreement rates over time to ensure we were converging on a good prompt.

Я также отслеживал уровень согласия (agreement rate) с течением времени, чтобы убедиться, что мы сходимся к хорошему промпту.

In this example, we used agreement between the model and human evaluator because our dataset was roughly balanced (about 50% of instances were failures). However, using raw agreement is generally not recommended and can be misleading when classes are imbalanced. Instead, you should typically measure precision and recall separately to get a more accurate picture of your judge’s alignment.

В этом примере мы использовали согласие между моделью и оценщиком-человеком, потому что наш датасет был примерно сбалансирован (около 50% случаев были отказами). Однако использование простого согласия (raw agreement) в целом не рекомендуется и может вводить в заблуждение при несбалансированных классах. Вместо этого вам обычно следует измерять precision и recall по отдельности, чтобы получить более точную картину согласованности вашего судьи.

It took us only three iterations to achieve > 90% agreement between the LLM and Phillip. Your mileage may vary depending on the complexity of the task. For example, Swyx has conducted a similar process hundreds of times for AI News, an extremely popular news aggregator with high quality recommendations. The quality of the AI owing to this process is why this product has received critical acclaim.

Нам понадобилось всего три итерации, чтобы достичь более 90% согласия между LLM и Phillip. Ваши результаты могут отличаться в зависимости от сложности задачи. Например, Swyx проводил похожий процесс сотни раз для AI News, чрезвычайно популярного новостного агрегатора с высококачественными рекомендациями. Качество ИИ, обусловленное этим процессом, и есть причина того, что этот продукт получил признание критиков.

How to Optimize the LLM Judge Prompt?

Как оптимизировать промпт LLM-судьи?

I usually adjust the prompts by hand. I haven’t had much luck with prompt optimizers like DSPy. However, my friend Eugene Yan has just released a promising tool named ALIGN Eval. I like it because it’s simple and effective. Also, don’t forget the approach of continual in-context learning mentioned earlier - it can be effective when implemented correctly.

Обычно я подгоняю промпты вручную. Мне не особо везло с оптимизаторами промптов вроде DSPy. Однако мой друг Eugene Yan только что выпустил многообещающий инструмент под названием ALIGN Eval. Он мне нравится, потому что он прост и эффективен. Также не забывайте про подход continual in-context learning, упомянутый ранее — он может быть эффективен при правильной реализации.

In rare cases, I might fine-tune a judge, but I prefer not to. I talk about this more in the FAQ section.

В редких случаях я мог бы дообучить (fine-tune) судью, но предпочитаю этого не делать. Подробнее об этом я говорю в разделе FAQ.

The Human Side of the Process

Человеческая сторона процесса

Something unexpected happened during this process. Phillip Carter, our domain expert at Honeycomb, found that reviewing the LLM’s critiques helped him articulate his own evaluation criteria more clearly. He said,

Во время этого процесса произошло нечто неожиданное. Phillip Carter, наш эксперт предметной области в Honeycomb, обнаружил, что просмотр критик от LLM помог ему более чётко сформулировать собственные критерии оценки. Он сказал:

“Seeing how the LLM breaks down its reasoning made me realize I wasn’t being consistent about how I judged certain edge cases.”

«Наблюдение за тем, как LLM раскладывает свои рассуждения, заставило меня осознать, что я был непоследователен в том, как оценивал некоторые краевые случаи».

This is a pattern I’ve seen repeatedly—the process of building an LLM judge often helps standardize evaluation criteria.

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

Furthermore, because this process forces the domain expert to look at data carefully, I always uncover new insights about the product, AI capabilities, and user needs. The resulting benefits are often more valuable than creating a LLM judge!

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

How Often Should You Evaluate?

Как часто следует проводить оценку?

I conduct this human review at regular intervals and whenever something material changes. For example, if I update a model, I’ll run the process again. I don’t get too scientific here; instead, I rely on my best judgment. Also note that after the first two iterations, I tend to focus more on errors rather than sampling randomly. For example, if I find an error, I’ll search for more examples that I think might trigger the same error. However, I always do a bit of random sampling as well.

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

What if this doesn’t work?

Что, если это не сработает?

I’ve seen this process fail when:

Я видел, как этот процесс терпит неудачу, когда:

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

In each of these cases, I try to address the root cause instead of trying to force alignment. Sometimes, you may not be able to achieve the alignment you want and may have to lean heavier on human annotations. However, after following the process described here, you will have metrics that help you understand how much you can trust the LLM judge.

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

Mistakes I’ve noticed in LLM judge prompts

Ошибки, которые я замечал в промптах LLM-судей

Most of the mistakes I’ve seen in LLM judge prompts have to do with not providing good examples:

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

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

Sometimes, you may encounter difficulties with fitting everything you need into the prompt, and may have to get creative about how you structure the examples. However, this is becoming less of an issue thanks to expanding context windows and prompt caching.

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

Step 6: Perform Error Analysis

Шаг 6: проведите анализ ошибок

After you have created a LLM as a judge, you will have a dataset of user interactions with the AI, and the LLM’s judgments. If your metrics show an acceptable agreement between the domain expert and the LLM judge, you can apply this judge against real or synthetic interactions. After this, you can you calculate error rates for different dimensions of your data. You should calculate the error on unseen data only to make sure your aren’t getting biased results.

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

For example, if you have segmented your data by persona, scenario, feature, etc, your data analysis may look like this

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

Error Rates by Key Dimensions

Частота ошибок по ключевым измерениям

Classify Traces

Классифицируйте трейсы

Once you know where the errors are now you can perform an error analysis to get to the root cause of the errors. My favorite way is to look at examples of each type of error and classify them by hand. I recommend using a spreadsheet for this. For example, a trace for Order tracking where there are no matches for new users might look like this:

Как только вы знаете, где находятся ошибки, вы можете провести анализ ошибок, чтобы добраться до их первопричины. Мой любимый способ — посмотреть на примеры каждого типа ошибок и классифицировать их вручную. Я рекомендую использовать для этого электронную таблицу. Например, трейс для отслеживания заказа (Order tracking), где нет совпадений для новых пользователей, может выглядеть так:

In this example trace, the user provides an invalid order number. The AI correctly identifies that the order number is invalid but provides an unhelpful response. If you are not familiar with logging LLM traces, refer to my previous post on evals.

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

Note that this trace is formatted for readability.

Обратите внимание, что этот трейс отформатирован для удобства чтения.

{ "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." }

{ "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." }

In this case, you might classify the error as: Missing User Education. The system retrieved new user context and format information but failed to include it in the response, which suggests we could improve our prompt. After you have classified a number of errors, you can calculate the distribution of errors by root cause. That might look like this:

В этом случае вы можете классифицировать ошибку как: Missing User Education (отсутствие информирования пользователя). Система извлекла контекст нового пользователя и информацию о формате, но не включила это в ответ, что наводит на мысль, что мы могли бы улучшить наш промпт. После того как вы классифицировали ряд ошибок, вы можете рассчитать распределение ошибок по первопричинам. Это может выглядеть так:

Root Cause Distribution (20 Failed Interactions)

Распределение первопричин (20 проваленных взаимодействий)

Now you know where to focus your efforts. This doesn’t have to take an extraordinary amount of time. You can get quite far in just 15 minutes. Also, you can use a LLM to help you with this classification, but that is beyond the scope of this post (you can use a LLM to help you do anything in this post, as long as you have a process to verify the results).

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

An Interactive Walkthrough of Error Analysis

Интерактивный разбор анализа ошибок

Error analysis has been around in Machine Learning for quite some time. This video by Andrew Ng does a great job of walking through the process interactively:

Анализ ошибок существует в машинном обучении уже довольно давно. Это видео Andrew Ng отлично проводит через процесс в интерактивном формате:

Fix Your Errors, Again

Снова исправьте ошибки

Now that you have a sense of the errors, you can go back and fix them again. Go back to step 3 and iterate until you are satisfied. Note that every time you fix an error, you should try to write a test case for it. Sometimes, this can be an assertion in your test suite, but other times you may need to create a more “specialized” LLM judge for these failures. We’ll talk about this next.

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

Doing this well requires data literacy

Чтобы делать это хорошо, нужна грамотность в работе с данными

Investigating your data is much harder in practice than I made it look in this post. It requires a nose for data that only comes from practice. It also helps to have some basic familiarity with statistics and data analysis tools. My favorite post on data literacy is this one by Jason Liu and Eugene Yan.

Исследование ваших данных на практике гораздо сложнее, чем я изобразил это в этом посте. Это требует чутья на данные, которое приходит только с практикой. Также помогает базовое знакомство со статистикой и инструментами анализа данных. Мой любимый пост о грамотности в работе с данными — вот этот от Jason Liu и Eugene Yan.

Step 7: Create More Specialized LLM Judges (if needed)

Шаг 7: создайте более специализированных LLM-судей (при необходимости)

Now that you have a sense for where the problems in your AI are, you can decide where and if to invest in more targeted LLM judges. For example, if you find that the AI has trouble with citing sources correctly, you can created a targeted eval for that. You might not even need a LLM judge for some errors (and use a code-based assertion instead).

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

The key takeaway is don’t jump directly to using specialized LLM judges until you have gone through this critique shadowing process. This will help you rationalize where to invest your time.

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

Recap of Critique Shadowing

Резюме Critique Shadowing

Using an LLM as a judge can streamline your AI evaluation process if approached correctly. Here’s a visual illustration of the process (there is a description of the process below the diagram as well):

Использование LLM в роли судьи может упростить ваш процесс оценки ИИ, если подойти к нему правильно. Вот визуальная иллюстрация процесса (под диаграммой также есть описание процесса):

The Critique Shadowing process is iterative, with feedback loops. Let’s list out the steps:

Процесс Critique Shadowing итеративен, с петлями обратной связи. Перечислим шаги:

Найдите главного эксперта предметной области. Создайте датасет. Сгенерируйте разнообразные примеры, охватывающие ваши сценарии использования. Включите реальные или синтетические пользовательские взаимодействия. Эксперт предметной области проверяет данные. Эксперт выносит суждения pass/fail. Эксперт пишет подробные критики, объясняющие его рассуждения. Исправьте ошибки (если найдены). Устраните любые проблемы, обнаруженные во время review. Вернитесь к review эксперта, чтобы проверить исправления. Вернитесь к шагу 3, если найдены ошибки. Постройте LLM-судью. Создайте промпт, используя примеры эксперта. Протестируйте на суждениях эксперта. Дорабатывайте промпт, пока согласие не станет удовлетворительным. Проведите анализ ошибок. Рассчитайте частоту ошибок по разным измерениям. Выявите паттерны и первопричины. Исправьте ошибки и вернитесь к шагу 3 при необходимости. Создайте специализированных судей по мере необходимости.

This process never truly ends. It repeats periodically or when material changes occur.

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

It’s Not The Judge That Created Value, After all

Ценность создал, в конце концов, не судья

The real value of this process is looking at your data and doing careful analysis. Even though an AI judge can be a helpful tool, going through this process is what drives results. I would go as far as saying that creating a LLM judge is a nice “hack” I use to trick people into carefully looking at their data!

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

That’s right. The real business value comes from looking at your data. But hey, potato, potahto.

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

Do You Really Need This?

Действительно ли вам это нужно?

Phew, this seems like a lot of work! Do you really need this? Well, it depends. There are cases where you can take a shortcut through this process. For example, let’s say:

Уф, это выглядит как куча работы! Действительно ли вам это нужно? Что ж, смотря по обстоятельствам. Есть случаи, когда можно срезать путь в этом процессе. Например, скажем:

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

In this scenario, you can jump directly to something that looks like step 3 and start looking at data right away. Also, since it’s not that costly to look at data, it’s probably fine to just do error analysis without a judge (at least initially). You can incorporate what you learn directly back into your primary model right away. This example is not exhaustive, but gives you an idea of how you can adapt this process to your needs.

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

However, you can never completely eliminate looking at your data! This is precisely the step that most people skip. Don’t be that person.

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

FAQ

FAQ

I received a lot of questions about this topic. Here are answers to the most common ones:

Я получил много вопросов на эту тему. Вот ответы на самые частые из них:

If I have a good judge LLM, isn’t that also the LLM I’d also want to use?

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

Effective judges often use larger models or more compute (via longer prompts, chain-of-thought, etc.) than the systems they evaluate.

Эффективные судьи часто используют более крупные модели или больше вычислений (через более длинные промпты, chain-of-thought и т. д.), чем системы, которые они оценивают.

However, If the cost of the most powerful LLM is not prohibitive, and latency is not an issue, then you might want to consider where you invest your efforts differently. In this case, it might make sense to put more effort towards specialist LLM judges, code-based assertions, and A/B testing. However, you should still go through the process of looking at data and critiquing the LLM’s output before you adopt specialized judges.

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

Do you recommend fine-tuning judges?

Рекомендуете ли вы дообучать (fine-tune) судей?

I prefer not to fine-tune LLM judges. I’d rather spend the effort fine-tuning the actual LLM instead. However, fine-tuning guardrails or other specialized judges can be useful (especially if they are small classifiers).

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

As a related note, you can leverage a LLM judge to curate and transform data for fine-tuning your primary model. For example, you can use the judge to:

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

Устранять плохие примеры для дообучения. Генерировать более качественные выводы (опираясь на критику). Симулировать качественные chain-of-thought с помощью критик.

Using a LLM judge for enhancing fine-tuning data is even more compelling when you are trying to distill a large LLM into a smaller one. The details of fine-tuning are beyond the scope of this post. If you are interested in learning more, see these resources.

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

What’s wrong with off-the-shelf LLM judges?

Что не так с готовыми LLM-судьями?

Nothing is strictly wrong with them. It’s just that many people are led astray by them. If you are disciplined you can apply them to your data and see if they are telling you something valuable. However, I’ve found that these tend to cause more confusion than value.

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

How Do you evaluate the LLM judge?

Как вы оцениваете самого LLM-судью?

You will collect metrics on the agreement between the domain expert and the LLM judge. This tells you how much you can trust the judge and in what scenarios. Your domain expert doesn’t have to inspect every single example, you just need a representative sample so you can have reliable statistics.

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

What model do you use for the LLM judge?

Какую модель вы используете для LLM-судьи?

For the kind of judge articulated in this blog post, I like to use the most powerful model I can afford in my cost/latency budget. This budget might be different than my primary model, depending on the number of examples I need to score. This can vary significantly according to the use case.

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

What about guardrails?

А как насчёт guardrails?

Guardrails are a separate but related topic. They are a way to prevent the LLM from saying/doing something harmful or inappropriate. This blog post focuses on helping you create a judge that’s aligned with business goals, especially when starting out.

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

I’m using LLM as a judge, and getting tremendous value but I didn’t follow this approach.

Я использую LLM в роли судьи и получаю огромную пользу, но я не следовал этому подходу.

I believe you. This blog post is not the only way to use a LLM as a judge. In fact, I’ve seen people use a LLM as a judge in all sorts of creative ways, which include ranking, classification, model selection and so-on. I’m focused on an approach that works well when you are getting started, and avoids the pitfalls of confusing metric sprawl. However, the general process of looking at the data is still central no matter what kind of judge you are building.

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

How do you choose between traditional ML techniques, LLM-as-a-judge and human annotations?

Как выбрать между традиционными методами ML, LLM-as-a-judge и человеческой разметкой?

The answer to this (and many other questions) is: do the simplest thing that works. And simple doesn’t always mean traditional ML techniques. Depending on your situation, it might be easier to use a LLM API as a classifier than to train a model and deploy it.

Ответ на этот (и многие другие) вопрос таков: делайте самое простое, что работает. И простое не всегда означает традиционные методы ML. В зависимости от вашей ситуации может оказаться проще использовать LLM API в качестве классификатора, чем обучать модель и развёртывать её.

Can you make judges from small models?

Можно ли делать судей из небольших моделей?

Yes, potentially. I’ve only used the larger models for judges. You have to base the answer to this question on the data (i.e. the agreement with the domain expert).

Да, потенциально. Я использовал для судей только более крупные модели. Ответ на этот вопрос вам нужно основывать на данных (то есть на согласии с экспертом предметной области).

How do you ensure consistency when updating your LLM model?

Как обеспечить постоянство при обновлении вашей LLM-модели?

You have to go through the process again and measure the results.

Вам нужно снова пройти процесс и измерить результаты.

How do you phase out human in the loop to scale this?

Как постепенно убрать человека из контура, чтобы масштабировать это?

You don’t need a domain expert to grade every single example. You just need a representative sample. I don’t think you can eliminate humans completely, because the LLM still needs to be aligned to something, and that something is usually a human. As your evaluation system gets better, it naturally reduces the amount of human effort required.

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

Resources

Ресурсы

These are some of the resources I recommend to learn more on this topic:

Вот некоторые из ресурсов, которые я рекомендую для более глубокого изучения этой темы:

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, с акцентом на важность оценки.

Stay Connected

Оставайтесь на связи

I’m continuously learning about LLMs, and enjoy sharing my findings. If you’re interested in this journey, consider subscribing.

Я непрерывно изучаю LLM и с удовольствием делюсь своими находками. Если вам интересно это путешествие, подумайте о подписке.

What to expect:

Чего ожидать:

Периодические письма с моими свежими инсайтами о LLM. Ранний доступ к новому контенту. Никакого спама — только честные мысли и открытия.