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.

Ранее в этом году я написал статью Your AI product needs evals. Многие из вас спрашивали: «Как начать работу с LLM в роли судьи?» Это руководство обобщает мой опыт помощи более чем 30 компаниям в настройке их систем оценки.

The Problem: AI Teams Are Drowning in Data

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

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:

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

Слишком много метрик: создание множества измерений, которые становятся неуправляемыми. Произвольные системы оценки: использование некалиброванных шкал (например, от 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.

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

Why is finding the right domain expert so important?

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

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

Examples of Principal Domain Experts:

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

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

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.

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

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.

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

Why a Diverse Dataset Matters

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

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

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-приложений:

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

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).

Сценарии — это ситуации, с которыми AI должен справиться (не основанные на результате ответа AI).

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.

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

Generating Data

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

To build your dataset, you can:

Для создания датасета вы можете:

Использовать существующие данные: выбрать реальные взаимодействия пользователей или поведение из вашей AI-системы. Сгенерировать синтетические данные: использовать 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 и базы данных там, где это уместно. Это создаст реалистичные данные и вызовет нужные сценарии. Иногда вам нужно будет написать простые программы для получения этой информации. Именно на это ссылается колонка «Допущения» в примерах ниже.

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:

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

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

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:

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

“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 удивительно хороши в генерации отличных — и разнообразных — примеров пользовательских запросов. Это может быть полезно для функций приложения и, что неожиданно, для построения оценок. Если это звучит так, будто Большая Языковая Змея кусает себя за хвост — я был удивлён не меньше вашего! Могу лишь сказать: это работает, отправляйте в продакшен.» 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: Направьте доменного эксперта на вынесение суждений «зачёт/незачёт» с критиками

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.

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

Why are simple pass/fail metrics important?

Почему важны простые метрики «зачёт/незачёт»?

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

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:

Наряду с бинарным суждением «зачёт/незачёт» важно написать развёрнутую критику сгенерированного LLM выхода. Эти критики:

Фиксируют нюансы: критика позволяет отметить, если что-то было в основном правильным, но имело области для улучшения. Направляют улучшения: детальная обратная связь даёт конкретные идеи о том, как можно улучшить AI. Балансируют простоту и глубину: в то время как «зачёт/незачёт» даёт чёткий вердикт, критика обеспечивает глубину, необходимую для понимания логики суждения.

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.

На практике доменные эксперты могут не полностью интернализировать все критерии оценки. Заставляя их выносить решение «зачёт/незачёт» и объяснять свои рассуждения, вы помогаете им прояснить ожидания и получаете ценные указания для улучшения AI.

“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.

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

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

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

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

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.

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

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.

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

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

Не отклоняйтесь от бинарных суждений «зачёт/незачёт» на начальном этапе

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

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

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:

Типичные возражения против суждений «зачёт/незачёт»:

«Бизнес сказал, что эти 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, они не знают, что ищут. Они просто гадают. Вы должны позволить доменному эксперту вести процесс и выносить суждения «зачёт/незачёт» с критиками, чтобы выяснить, что действительно важно. Стойте на своём.

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:

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

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

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!

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

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.

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

Step 5: Build Your LLM as A Judge, Iteratively

Шаг 5: Итеративно постройте LLM-судью

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.

«Чтобы оценивать выходы, людям нужно экстернализировать и определить свои критерии оценки; однако сам процесс оценки выходов помогает им определить эти самые критерии. Мы называем это явление дрейфом критериев, и оно подразумевает, что невозможно полностью определить критерии оценки до того, как человек начнёт оценивать выходы 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, нам нужен был способ оценить, генерирует ли AI хорошие запросы. Вот как выглядел наш промпт для LLM-судьи, включая few-shot примеры критик от нашего доменного эксперта Phillip:

You are a Honeycomb query evaluator with advanced capabilities to judge if a query is good or not. You understand the nuances of the Honeycomb query language, including what is likely to be most useful from an analytics perspective. Here is information about the Honeycomb query language: {{query_language_info}} Here are some guidelines for evaluating queries: {{guidelines}} Example evaluations: <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.

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

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 Сгенерированный запрос Критика Результат (зачёт или незачёт)

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.

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

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% экземпляров были провалами). Однако использование сырого показателя согласия в общем случае не рекомендуется и может вводить в заблуждение при несбалансированных классах. Вместо этого следует измерять точность и полноту отдельно для более точной картины согласованности судьи.

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 — чрезвычайно популярного агрегатора новостей с высококачественными рекомендациями. Качество AI, обусловленное этим процессом, — причина, по которой продукт получил высокое признание.

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. Мне он нравится, потому что он простой и эффективный. Также не забывайте о подходе непрерывного обучения в контексте, упомянутом ранее — он может быть эффективным при правильной реализации.

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

В редких случаях я могу дообучить судью, но предпочитаю этого не делать. Подробнее об этом в разделе 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!

Более того, поскольку этот процесс заставляет доменного эксперта внимательно смотреть на данные, я всегда обнаруживаю новые инсайты о продукте, возможностях AI и потребностях пользователей. Получаемые выгоды часто более ценны, чем создание самого 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.

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

What if this doesn’t work?

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

I’ve seen this process fail when:

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

AI имеет слишком широкий охват: например, чат-бот в 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.

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

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-судьи у вас будет датасет пользовательских взаимодействий с AI и суждения 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:

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

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.

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

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 и итерируйте, пока не будете удовлетворены. Обратите внимание: каждый раз при исправлении ошибки стоит написать тест-кейс для неё. Иногда это может быть assert в вашем тестовом наборе, но в других случаях может потребоваться создать более «специализированного» 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).

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

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 в роли судьи может оптимизировать процесс оценки AI при правильном подходе. Вот визуальная иллюстрация процесса (описание процесса также приведено под диаграммой):

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

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

Найдите главного доменного эксперта Создайте датасет Сгенерируйте разнообразные примеры, покрывающие ваши сценарии использования Включите реальные или синтетические пользовательские взаимодействия Доменный эксперт анализирует данные Эксперт выносит суждения «зачёт/незачёт» Эксперт пишет развёрнутые критики с объяснением своих рассуждений Исправьте ошибки (если найдены) Устраните проблемы, обнаруженные при обзоре Вернитесь к обзору эксперта для верификации исправлений Вернитесь к шагу 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!

Настоящая ценность этого процесса — в анализе данных и тщательном исследовании. Хотя AI-судья может быть полезным инструментом, именно прохождение этого процесса приносит результаты. Я бы даже сказал, что создание 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.

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

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-судей, проверки на уровне кода и A/B-тестирование. Тем не менее, вы всё равно должны пройти процесс анализа данных и критики выходов LLM, прежде чем применять специализированных судей.

Do you recommend fine-tuning judges?

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

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-судью для курирования и трансформации данных для дообучения основной модели. Например, судью можно использовать чтобы:

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

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-судьёй и человеческой разметкой?

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-методы. В зависимости от ситуации может быть проще использовать API LLM в качестве классификатора, чем обучать модель и деплоить её.

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: эта статья — предшественник данной и даёт общий обзор оценок для продуктов на базе LLM. Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences: эта статья Shreya Shankar et al. даёт хороший обзор проблем оценки LLM и важности правильного процесса. Align Eval: новый инструмент Eugene Yan, который помогает строить LLM-судей, следуя правильному процессу. Также прочитайте его сопроводительную статью. Evaluating the Effectiveness of LLM-Evaluators (aka LLM-as-Judge): отличный обзор различных сценариев использования и подходов к LLM-судьям, также от Eugene Yan. Enhancing LLM-As-A-Judge with Grading Notes от Yi Liu et al. Описывает подход, очень похожий на описанный в этой статье, и даёт другой взгляд на полезность написания критик (они называют их grading notes). Custom LLM as a Judge to Detect Hallucinations with Braintrust от Ankur Goyal и Shaymal Anadkt — сквозной пример построения LLM-судьи; для описанного случая авторы нашли, что подход на основе классификации надёжнее числовых рейтингов (что согласуется с данной статьёй). Techniques for Self-Improving LLM Evals от Eric Xiao из Arize показывает хороший подход к построению LLM-оценок с дополнительными инструментами, которые стоит изучить. How Dosu Used LangSmith to Achieve a 30% Accuracy Improvement with No Prompt Engineering от Langchain показывает хороший подход к построению промптов для LLM с динамическими примерами. Идея проста, но эффективна. Я адаптирую её для своих случаев, включая LLM-судей. Вот видеоразбор подхода. What We've Learned From A Year of Building with LLMs: отличный обзор множества практических аспектов разработки с LLM с акцентом на важности оценки.

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 Ранний доступ к новому контенту Без спама, только честные мысли и открытия