LLM Evals: Everything You Need to Know
Статья представляет собой исчерпывающий FAQ по оценке (evals) LLM-приложений, составленный Hamel Husain и Shreya на основе вопросов от 700+ инженеров и продакт-менеджеров. Центральная идея — анализ ошибок (error analysis) является важнейшей практикой: необходимо вручную просматривать реальные трейсы, выявлять паттерны сбоев и лишь затем строить автоматические оценщики. Авторы рекомендуют бинарные (pass/fail) оценки вместо шкал Ликерта, предостерегают от использования готовых метрик вроде BERTScore и ROUGE, и советуют создавать кастомные инструменты разметки. Для RAG-систем предлагается раздельная оценка поиска (IR-метриками) и генерации (LLM-as-Judge). В проектах авторов 60–80% времени разработки уходит на анализ ошибок и оценку, а не на написание кода. Статья также охватывает синтетические данные, многошаговые агентные сценарии, матрицы переходных отказов и версионирование промптов через Git.
This document curates the most common questions Shreya and I received while teaching 700+ engineers & PMs AI Evals. Warning: These are sharp opinions about what works in most cases. They are not universal truths. Use your judgment.
Этот документ собирает наиболее частые вопросы, которые получали мы с Shreya, обучая более 700 инженеров и продакт-менеджеров оценке ИИ (AI Evals). Предупреждение: это категоричные мнения о том, что работает в большинстве случаев. Это не универсальные истины. Используйте собственное суждение.
👉 Want to learn more about AI Evals? Check out our AI Evals course. It’s a live cohort with hands on exercises and office hours. Here is a 25% discount code for readers. 👈
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Listen to the audio version of this FAQ
Послушайте аудиоверсию этого FAQ
If you prefer to listen to the audio version (narrated by AI), you can play it here.
Если вы предпочитаете послушать аудиоверсию (озвученную ИИ), вы можете воспроизвести её здесь.
Getting Started & Fundamentals
Начало работы и основы
Q: What are LLM Evals?
В: Что такое LLM Evals?
If you are completely new to product-specific LLM evals (not foundation model benchmarks), see these posts: part 1, part 2 and part 3. Otherwise, keep reading.
Если вы совсем новичок в продуктовых LLM-оценках (не в бенчмарках базовых моделей), прочитайте эти статьи: часть 1, часть 2 и часть 3. В противном случае продолжайте чтение.
Your AI Product Needs Eval (Evaluation Systems)
Вашему ИИ-продукту нужны системы оценки (Evaluation Systems)
Contents:
Содержание:
- Level 1: Unit Tests
- Level 2: Human & Model Eval
- Level 3: A/B Testing
- Evaluating RAG
- Fine-Tuning
- Data Synthesis & Curation
- Debugging
Мотивация Быстрая итерация == Успех Кейс: Lucy — ИИ-ассистент для недвижимости Типы оценки Уровень 1: Юнит-тесты Уровень 2: Оценка человеком и моделью Уровень 3: A/B-тестирование Оценка RAG Системы оценки открывают суперспособности Бесплатная дообучение (Fine-Tuning) Синтез и курирование данных Отладка
Contents:
Содержание:
Проблема: ИИ-команды тонут в данных Шаг 1: Найдите главного доменного эксперта Шаг 2: Создайте датасет Шаг 3: Направьте доменного эксперта выносить суждения «пройдено/не пройдено» с критикой Шаг 4: Исправьте ошибки Шаг 5: Итеративно постройте LLM-as-a-Judge Шаг 6: Проведите анализ ошибок Шаг 7: Создайте более специализированных LLM-судей (при необходимости) Резюме теневого критического анализа Ресурсы
Contents:
Содержание:
Как анализ ошибок стабильно выявляет улучшения с наибольшим ROI Почему простой просмотрщик данных — ваша самая важная инвестиция в ИИ Как дать доменным экспертам (не только инженерам) возможность улучшать ваш ИИ Почему синтетические данные эффективнее, чем вы думаете Как поддерживать доверие к вашей системе оценки Почему ваш ИИ-роадмап должен считать эксперименты, а не фичи
Q: What is a trace?
В: Что такое трейс?
A trace is the complete record of all actions, messages, tool calls, and data retrievals from a single initial user query through to the final response. It includes every step across all agents, tools, and system components in a session: multiple user messages, assistant responses, retrieved documents, and intermediate tool interactions.
Трейс — это полная запись всех действий, сообщений, вызовов инструментов и обращений к данным от одного начального запроса пользователя до финального ответа. Он включает каждый шаг по всем агентам, инструментам и системным компонентам в рамках сессии: множество сообщений пользователя, ответы ассистента, извлечённые документы и промежуточные взаимодействия с инструментами.
Note on terminology: Different observability vendors use varying definitions of traces and spans. Alex Strick van Linschoten’s analysis highlights these differences (screenshot below):
Примечание о терминологии: Разные поставщики инструментов наблюдаемости используют различные определения трейсов и спанов. Анализ Alex Strick van Linschoten подчёркивает эти различия (скриншот ниже):
Q: What’s a minimum viable evaluation setup?
В: Какой минимально жизнеспособный набор для оценки?
Start with error analysis, not infrastructure. Spend 30 minutes manually reviewing 20-50 LLM outputs whenever you make significant changes. Use one domain expert who understands your users as your quality decision maker (a “benevolent dictator”).
Начните с анализа ошибок, а не с инфраструктуры. Потратьте 30 минут на ручной просмотр 20–50 выходов LLM при каждом значительном изменении. Используйте одного доменного эксперта, который понимает ваших пользователей, в качестве ответственного за качество — «доброжелательного диктатора».
Use a notebook to review traces and analyze data, or build your own custom annotation interface with an AI coding assistant like Claude or Codex. Either way, you can write arbitrary code, visualize data, and iterate quickly. The video below shows a simple annotation interface built inside a notebook.
Используйте ноутбук для просмотра трейсов и анализа данных, или создайте собственный интерфейс разметки с помощью ИИ-ассистента для кодинга вроде Claude или Codex. В любом случае вы сможете писать произвольный код, визуализировать данные и быстро итерировать. Видео ниже демонстрирует простой интерфейс разметки, построенный внутри ноутбука.
Q: How much of my development budget should I allocate to evals?
В: Какую долю бюджета на разработку следует выделять на оценку?
It’s important to recognize that evaluation is part of the development process rather than a distinct line item, similar to how debugging is part of software development.
Важно понимать, что оценка — это часть процесса разработки, а не отдельная статья расходов, подобно тому как отладка является частью разработки программного обеспечения.
You should always be doing error analysis. When you discover issues through error analysis, many will be straightforward bugs you’ll fix immediately. These fixes don’t require separate evaluation infrastructure as they’re just part of development.
Вы всегда должны проводить анализ ошибок. Когда вы обнаруживаете проблемы в ходе анализа, многие из них окажутся простыми багами, которые вы исправите сразу. Эти исправления не требуют отдельной инфраструктуры оценки — они просто часть разработки.
The decision to build automated evaluators comes down to cost-benefit analysis. If you can catch an error with a simple assertion or regex check, the cost is minimal and probably worth it. But if you need to align an LLM-as-judge evaluator, consider whether the failure mode warrants that investment.
Решение о создании автоматических оценщиков сводится к анализу затрат и выгод. Если ошибку можно отловить простым утверждением (assertion) или регулярным выражением, затраты минимальны и, вероятно, оправданы. Но если требуется настраивать оценщик LLM-as-Judge, подумайте, стоит ли этот режим отказа таких вложений.
In the projects we’ve worked on, we’ve spent 60-80% of our development time on error analysis and evaluation. Expect most of your effort to go toward understanding failures (i.e. looking at data) rather than building automated checks.
В проектах, над которыми мы работали, мы тратили 60–80% времени разработки на анализ ошибок и оценку. Ожидайте, что основная часть усилий уйдёт на понимание сбоев (то есть на изучение данных), а не на создание автоматических проверок.
Be wary of optimizing for high eval pass rates. If you’re passing 100% of your evals, you’re likely not challenging your system enough. A 70% pass rate might indicate a more meaningful evaluation that’s actually stress-testing your application. Focus on evals that help you catch real issues, not ones that make your metrics look good.
Остерегайтесь оптимизации ради высоких показателей прохождения оценок. Если вы проходите 100% оценок — скорее всего, вы недостаточно нагружаете свою систему. Показатель прохождения 70% может говорить о более содержательной оценке, которая действительно тестирует ваше приложение на прочность. Сосредоточьтесь на оценках, помогающих находить реальные проблемы, а не на тех, что делают ваши метрики красивыми.
Q: Will today’s evaluation methods still be relevant in 5-10 years given how fast AI is changing?
В: Будут ли сегодняшние методы оценки актуальны через 5–10 лет, учитывая скорость изменений в ИИ?
Yes. Even with perfect models, you still need to verify they’re solving the right problem. The need for systematic error analysis, domain-specific testing, and monitoring will still be important.
Да. Даже с идеальными моделями вам всё равно нужно проверять, что они решают правильную задачу. Потребность в систематическом анализе ошибок, доменно-специфичном тестировании и мониторинге останется актуальной.
Today’s prompt engineering tricks might become obsolete, but you’ll still need to understand failure modes. Additionally, a LLM cannot read your mind, and research shows that people need to observe the LLM’s behavior in order to properly externalize their requirements.
Сегодняшние приёмы промпт-инжиниринга могут устареть, но вам всё равно нужно будет понимать режимы отказов. Кроме того, LLM не может читать ваши мысли, и исследования показывают, что людям необходимо наблюдать за поведением LLM, чтобы правильно сформулировать свои требования.
For deeper perspective on this debate, see these two viewpoints: “The model is the product” versus “The model is NOT the product”.
Для более глубокого понимания этой дискуссии смотрите две точки зрения: «Модель — это продукт» против «Модель — это НЕ продукт».
“The model is the product”:
«Модель — это продукт»:
“The model is NOT the product”:
«Модель — это НЕ продукт»:
Q: How do I make the case for investing in evaluations to my team?
В: Как убедить команду инвестировать в оценку?
Don’t try to sell your team on “evals”. Instead, show them what you find when you look at the data.
Не пытайтесь продать команде идею «оценок». Вместо этого покажите, что вы находите, когда смотрите на данные.
Start by doing the error analysis yourself. Look at 50 to 100 real user conversations and find the most common ways the product is failing. Use these findings to tell a story with data.
Начните с анализа ошибок самостоятельно. Просмотрите 50–100 реальных пользовательских диалогов и найдите наиболее частые способы, которыми продукт подводит пользователей. Используйте эти находки, чтобы рассказать историю на основе данных.
Present your team with:
Представьте команде:
Список основных режимов отказов, которые вы обнаружили. Метрики, показывающие, как часто случаются серьёзные ошибки. Неожиданные способы взаимодействия пользователей с продуктом. Отчёты о найденных и исправленных багах, поданные как «предотвращённые проблемы в продакшене».
This approach builds trust. Don’t just show dashboards and metrics; tell the story of what you’re finding in the data. By narrating your findings, you teach the team what you’re learning, providing immediate value. When you fix an issue, show how the error rate for that specific problem went down. Soon, your team will see the progress and ask how you’re doing it. Let results instead of methods lead the conversation.
Такой подход выстраивает доверие. Не просто показывайте дашборды и метрики — расскажите историю того, что вы находите в данных. Описывая свои находки, вы обучаете команду тому, что узнаёте, принося немедленную пользу. Когда вы исправляете проблему, покажите, как снизилась частота ошибок для этого конкретного случая. Вскоре команда увидит прогресс и спросит, как вы этого добиваетесь. Пусть результаты, а не методы ведут разговор.
This is similar to classic machine learning projects, where outcomes are speculative and progress is bounded by iterating on experiments. In this situation, it’s important that you share the learnings from each experiment to show progress and encourage investment.
Это похоже на классические проекты машинного обучения, где результаты спекулятивны, а прогресс ограничен итерациями над экспериментами. В такой ситуации важно делиться выводами из каждого эксперимента, чтобы показать прогресс и стимулировать инвестиции.
Error Analysis & Data Collection
Анализ ошибок и сбор данных
Q: Why is "error analysis" so important in LLM evals, and how is it performed?
В: Почему «анализ ошибок» так важен в LLM-оценках и как он проводится?
Error analysis is the most important activity in evals. Error analysis helps you decide what evals to write in the first place. It allows you to identify failure modes unique to your application and data. The process involves:
Анализ ошибок — самая важная деятельность в оценке. Он помогает решить, какие оценки писать в первую очередь. Он позволяет выявить режимы отказов, уникальные для вашего приложения и данных. Процесс включает:
1. Creating a Dataset
1. Создание датасета
Gathering representative traces of user interactions with the LLM. If you do not have any data, you can generate synthetic data to get started.
Соберите репрезентативные трейсы взаимодействий пользователей с LLM. Если у вас нет данных, вы можете сгенерировать синтетические данные для начала.
2. Open Coding
2. Открытое кодирование
Human annotator(s) (ideally a benevolent dictator) review and write open-ended notes about traces, noting any issues. This process is akin to “journaling” and is adapted from qualitative research methodologies. When beginning, it is recommended to focus on noting the first failure observed in a trace, as upstream errors can cause downstream issues, though you can also tag all independent failures if feasible. A domain expert should be performing this step.
Аннотаторы (в идеале — доброжелательный диктатор) просматривают трейсы и пишут свободные заметки, отмечая любые проблемы. Этот процесс сродни «ведению дневника» и заимствован из методологий качественного исследования. В начале рекомендуется фокусироваться на первом обнаруженном сбое в трейсе, так как ошибки на ранних этапах вызывают проблемы далее по цепочке, хотя можно также отмечать все независимые сбои, если это реализуемо. Этот шаг должен выполнять доменный эксперт.
3. Axial Coding
3. Осевое кодирование
Categorize the open-ended notes into a “failure taxonomy.”. In other words, group similar failures into distinct categories. This is the most important step. At the end, count the number of failures in each category. You can use a LLM to help with this step.
Категоризируйте свободные заметки в «таксономию сбоев». Другими словами, сгруппируйте похожие ошибки в отдельные категории. Это самый важный шаг. В конце подсчитайте количество сбоев в каждой категории. Для этого шага можно использовать LLM.
4. Iterative Refinement
4. Итеративное уточнение
Keep iterating on more traces until you reach theoretical saturation, meaning new traces do not seem to reveal new failure modes or information to you. As a rule of thumb, you should aim to review at least 100 traces. My rough heuristic is if ~20 traces don’t turn up a new category, you can stop (but review at least 100 to start). Remember, the goal is to prioritize the failures that actually happen the most, not catch every possible failure (evals are not free, so we need to be pragmatic).
Продолжайте итерировать на новых трейсах, пока не достигнете теоретического насыщения, то есть новые трейсы перестанут выявлять новые режимы отказов или информацию. Как правило, стоит просмотреть не менее 100 трейсов. Мой примерный ориентир: если ~20 трейсов не выявляют новую категорию, можно остановиться (но начните с просмотра минимум 100). Помните, цель — приоритизировать сбои, которые действительно происходят чаще всего, а не отловить каждый возможный (оценки не бесплатны, поэтому нужен прагматизм).
You should frequently revisit this process. There are advanced ways to sample data more efficiently, like clustering, sorting by user feedback, and sorting by high probability failure patterns. Over time, you’ll develop a “nose” for where to look for failures in your data.
Регулярно возвращайтесь к этому процессу. Существуют продвинутые способы более эффективной выборки данных, такие как кластеризация, сортировка по обратной связи от пользователей и сортировка по паттернам с высокой вероятностью сбоев. Со временем у вас выработается «чутьё» на то, где искать ошибки в ваших данных.
Do not skip error analysis. It ensures that the evaluation metrics you develop are supported by real application behaviors instead of counter-productive generic metrics (which most platforms nudge you to use). For examples of how error analysis can be helpful, see this video, or this blog post.
Не пропускайте анализ ошибок. Он гарантирует, что разрабатываемые вами метрики оценки основаны на реальном поведении приложения, а не на контрпродуктивных универсальных метриках (к использованию которых вас подталкивает большинство платформ). Примеры полезности анализа ошибок см. в этом видео или в этом блог-посте.
Here is a visualization of the error analysis process by one of our students, Pawel Huryn - including how it fits into the overall evaluation process:
Вот визуализация процесса анализа ошибок от одного из наших студентов, Pawel Huryn — включая то, как он вписывается в общий процесс оценки:
Q: How do I surface problematic traces for review beyond user feedback?
В: Как обнаружить проблемные трейсы для просмотра помимо обратной связи от пользователей?
While user feedback is a good way to narrow in on problematic traces, other methods are also useful. Here are three complementary approaches:
Хотя обратная связь от пользователей — хороший способ сузить поиск проблемных трейсов, другие методы тоже полезны. Вот три дополнительных подхода:
Start with random sampling
Начните со случайной выборки
The simplest approach is reviewing a random sample of traces. If you find few issues, escalate to stress testing: create queries that deliberately test your prompt constraints to see if the AI follows your rules.
Простейший подход — просмотр случайной выборки трейсов. Если проблем мало, переходите к стресс-тестированию: создайте запросы, которые намеренно проверяют ограничения вашего промпта, чтобы увидеть, следует ли ИИ вашим правилам.
Use evals for initial screening
Используйте оценки для первичного скрининга
Use existing evals to find problematic traces and potential issues. Once you’ve identified these, you can proceed with the typical evaluation process starting with error analysis.
Используйте существующие оценки для поиска проблемных трейсов и потенциальных проблем. После их выявления можно перейти к стандартному процессу оценки, начиная с анализа ошибок.
Leverage efficient sampling strategies
Используйте эффективные стратегии выборки
For more sophisticated trace discovery, use outlier detection, metric-based sorting, and stratified sampling to find interesting traces. Generic metrics can serve as exploration signals to identify traces worth reviewing, even if they don’t directly measure quality.
Для более продвинутого обнаружения трейсов используйте обнаружение выбросов, сортировку по метрикам и стратифицированную выборку для поиска интересных трейсов. Универсальные метрики могут служить сигналами для исследования — помогать находить трейсы, достойные просмотра, даже если они не измеряют качество напрямую.
Q: How often should I re-run error analysis on my production system?
В: Как часто нужно повторять анализ ошибок в продакшен-системе?
Re-run error analysis when making significant changes: new features, prompt updates, model switches, or major bug fixes. A useful heuristic is to set a goal for reviewing at least 100+ fresh traces each review cycle. Typical review cycles we’ve seen range from 2-4 weeks. See this FAQ on how to sample traces effectively.
Повторяйте анализ ошибок при значительных изменениях: новые функции, обновления промптов, смена модели или крупные исправления багов. Полезный ориентир — ставить цель просматривать не менее 100 свежих трейсов за каждый цикл обзора. Типичные циклы обзора, которые мы наблюдали, составляют 2–4 недели. Смотрите этот FAQ о том, как эффективно делать выборку трейсов.
Between major analyses, review 10-20 traces weekly, focusing on outliers: unusually long conversations, sessions with multiple retries, or traces flagged by automated monitoring. Adjust frequency based on system stability and usage growth. New systems need weekly analysis until failure patterns stabilize. Mature systems might need only monthly analysis unless usage patterns change. Always analyze after incidents, user complaint spikes, or metric drift. Scaling usage introduces new edge cases.
Между крупными анализами просматривайте 10–20 трейсов еженедельно, фокусируясь на выбросах: необычно длинных разговорах, сессиях с множеством повторных попыток или трейсах, отмеченных автоматическим мониторингом. Корректируйте частоту в зависимости от стабильности системы и роста использования. Новым системам нужен еженедельный анализ, пока паттерны сбоев не стабилизируются. Зрелые системы могут обойтись ежемесячным анализом, если паттерны использования не меняются. Всегда анализируйте после инцидентов, всплесков жалоб или дрейфа метрик. Масштабирование использования порождает новые пограничные случаи.
Q: What is the best approach for generating synthetic data?
В: Каков лучший подход к генерации синтетических данных?
A common mistake is prompting an LLM to "give me test queries" without structure, resulting in generic, repetitive outputs. A structured approach using dimensions produces far better synthetic data for testing LLM applications.
Распространённая ошибка — попросить LLM "дай мне тестовые запросы" без структуры, что приводит к шаблонным, повторяющимся результатам. Структурированный подход с использованием измерений (dimensions) даёт гораздо лучшие синтетические данные для тестирования LLM-приложений.
Start by defining dimensions: categories that describe different aspects of user queries. Each dimension captures one type of variation in user behavior. For example:
Начните с определения измерений: категорий, описывающих различные аспекты пользовательских запросов. Каждое измерение фиксирует один тип вариации в поведении пользователей. Например:
Для приложения рецептов измерениями могут быть: Диетическое ограничение (веганское, безглютеновое, без ограничений), Тип кухни (итальянская, азиатская, домашняя) и Сложность запроса (простой запрос, многошаговый, пограничный случай). Для бота поддержки клиентов измерениями могут быть: Тип проблемы (биллинг, техническая, общая), Настроение клиента (раздражённый, нейтральный, довольный) и Предыдущий контекст (новая проблема, продолжение, решённая).
Start with failure hypotheses. If you lack intuition about failure modes, use your application extensively or recruit friends to use it. Then choose dimensions targeting those likely failures.
Начните с гипотез о сбоях. Если у вас нет интуиции относительно режимов отказов, активно используйте своё приложение или попросите друзей попробовать его. Затем выберите измерения, нацеленные на вероятные сбои.
Create tuples manually first: Write 20 tuples by hand—specific combinations selecting one value from each dimension. Example: (Vegan, Italian, Multi-step). This manual work helps you understand your problem space.
Сначала создайте кортежи вручную: напишите 20 кортежей от руки — конкретные комбинации, выбирающие одно значение из каждого измерения. Пример: (Веганское, Итальянская, Многошаговый). Эта ручная работа помогает понять пространство вашей задачи.
Scale with two-step generation:
Масштабируйте двухэтапной генерацией:
Генерируйте структурированные кортежи: попросите LLM создать больше комбинаций, таких как (Безглютеновое, Азиатская, Простой) Преобразуйте кортежи в запросы: в отдельном промпте трансформируйте каждый кортеж в естественный язык
This separation avoids repetitive phrasing. The (Vegan, Italian, Multi-step) tuple becomes: "I need a dairy-free lasagna recipe that I can prep the day before."
Такое разделение позволяет избежать повторяющихся формулировок. Кортеж (Веганское, Итальянская, Многошаговый) превращается в: "Мне нужен рецепт лазаньи без молочных продуктов, которую можно подготовить за день до подачи."
Generation approaches
Подходы к генерации
You can generate tuples two ways:
Кортежи можно генерировать двумя способами:
Cross product then filter: Generate all dimension combinations, then filter with an LLM. Guarantees coverage including edge cases. Use when most combinations are valid.
Декартово произведение с фильтрацией: сгенерируйте все комбинации измерений, затем отфильтруйте с помощью LLM. Гарантирует покрытие, включая пограничные случаи. Используйте, когда большинство комбинаций валидны.
Direct LLM generation: Ask the LLM to generate tuples directly. More realistic but tends toward generic outputs and misses rare scenarios. Use when many dimension combinations are invalid.
Прямая генерация LLM: попросите LLM генерировать кортежи напрямую. Более реалистично, но тяготеет к шаблонным результатам и пропускает редкие сценарии. Используйте, когда многие комбинации измерений невалидны.
Fix obvious problems first: Don’t generate synthetic data for issues you can fix immediately. If your prompt doesn’t mention dietary restrictions, fix the prompt rather than generating specialized test queries.
Сначала исправьте очевидные проблемы: не генерируйте синтетические данные для проблем, которые можно исправить немедленно. Если ваш промпт не упоминает диетические ограничения, исправьте промпт, а не генерируйте специализированные тестовые запросы.
After iterating on your tuples and prompts, run these synthetic queries through your actual system to capture full traces. Sample 100 traces for error analysis. This number provides enough traces to manually review and identify failure patterns without being overwhelming.
После итераций над кортежами и промптами прогоните эти синтетические запросы через вашу реальную систему, чтобы собрать полные трейсы. Отберите 100 трейсов для анализа ошибок. Этого количества достаточно для ручного просмотра и выявления паттернов сбоев без перегрузки.
Q: Are there scenarios where synthetic data may not be reliable?
В: Есть ли сценарии, в которых синтетические данные могут быть ненадёжными?
Yes: synthetic data can mislead or mask issues. For guidance on generating synthetic data when appropriate, see What is the best approach for generating synthetic data?
Да: синтетические данные могут вводить в заблуждение или маскировать проблемы. Руководство по генерации синтетических данных, когда это уместно, см. в разделе Каков лучший подход к генерации синтетических данных?
Common scenarios where synthetic data fails:
Типичные сценарии, в которых синтетические данные подводят:
Complex domain-specific content: LLMs often miss the structure, nuance, or quirks of specialized documents (e.g., legal filings, medical records, technical forms). Without real examples, critical edge cases are missed.
Low-resource languages or dialects: For low-resource languages or dialects, LLM-generated samples are often unrealistic. Evaluations based on them won’t reflect actual performance.
When validation is impossible: If you can’t verify synthetic sample realism (due to domain complexity or lack of ground truth), real data is important for accurate evaluation.
High-stakes domains: In high-stakes domains (medicine, law, emergency response), synthetic data often lacks subtlety and edge cases. Errors here have serious consequences, and manual validation is difficult.
Underrepresented user groups: For underrepresented user groups, LLMs may misrepresent context, values, or challenges. Synthetic data can reinforce biases in the training data of the LLM.
Сложный доменно-специфичный контент: LLM часто упускают структуру, нюансы или особенности специализированных документов (например, юридических заявлений, медицинских карт, технических форм). Без реальных примеров критические пограничные случаи остаются незамеченными. Малоресурсные языки или диалекты: для малоресурсных языков или диалектов сгенерированные LLM примеры часто нереалистичны. Оценки на их основе не будут отражать реальную производительность. Когда валидация невозможна: если вы не можете проверить реалистичность синтетических примеров (из-за сложности домена или отсутствия эталона), реальные данные важны для точной оценки. Высокорисковые домены: в высокорисковых доменах (медицина, право, экстренное реагирование) синтетические данные часто лишены тонкостей и пограничных случаев. Ошибки здесь имеют серьёзные последствия, а ручная валидация затруднена. Недопредставленные группы пользователей: для недопредставленных групп LLM могут искажать контекст, ценности или проблемы. Синтетические данные могут усиливать предвзятость обучающих данных LLM.
Q: How do I approach evaluation when my system handles diverse user queries?
В: Как подходить к оценке, когда система обрабатывает разнообразные пользовательские запросы?
Complex applications often support vastly different query patterns—from “What’s the return policy?” to “Compare pricing trends across regions for products matching these criteria.” Each query type exercises different system capabilities, leading to confusion on how to design eval criteria.
Сложные приложения часто поддерживают совершенно разные паттерны запросов — от «Какова политика возврата?» до «Сравните ценовые тренды по регионам для товаров, соответствующих этим критериям». Каждый тип запроса задействует разные возможности системы, что вызывает путаницу при разработке критериев оценки.
Error Analysis is all you need. Your evaluation strategy should emerge from observed failure patterns (e.g. error analysis), not predetermined query classifications. Rather than creating a massive evaluation matrix covering every query type you can imagine, let your system’s actual behavior guide where you invest evaluation effort.
Анализ ошибок — это всё, что вам нужно. Ваша стратегия оценки должна вытекать из наблюдаемых паттернов сбоев (то есть из анализа ошибок), а не из заранее заданных классификаций запросов. Вместо того чтобы создавать огромную матрицу оценки, покрывающую все типы запросов, которые вы можете вообразить, позвольте реальному поведению вашей системы определять, куда инвестировать усилия по оценке.
During error analysis, you’ll likely discover that certain query categories share failure patterns. For instance, all queries requiring temporal reasoning might struggle regardless of whether they’re simple lookups or complex aggregations. Similarly, queries that need to combine information from multiple sources might fail in consistent ways. These patterns discovered through error analysis should drive your evaluation priorities. It could be that query category is a fine way to group failures, but you don’t know that until you’ve analyzed your data.
В ходе анализа ошибок вы, скорее всего, обнаружите, что определённые категории запросов имеют общие паттерны сбоев. Например, все запросы, требующие временно́го рассуждения, могут проваливаться независимо от того, являются ли они простыми поисками или сложными агрегациями. Аналогично запросы, требующие объединения информации из нескольких источников, могут отказывать одинаковым образом. Эти паттерны, обнаруженные через анализ ошибок, должны определять ваши приоритеты в оценке. Возможно, категория запроса окажется хорошим способом группировки сбоев, но вы не узнаете этого, пока не проанализируете свои данные.
To see an example of basic error analysis in action, see this video.
Чтобы увидеть пример базового анализа ошибок в действии, посмотрите это видео.
Q: How can I efficiently sample production traces for review?
В: Как эффективно делать выборку продакшен-трейсов для просмотра?
It can be cumbersome to review traces randomly, especially when most traces don’t have an error. These sampling strategies help you find traces more likely to reveal problems:
Просматривать трейсы случайным образом может быть утомительно, особенно когда в большинстве из них нет ошибок. Эти стратегии выборки помогают находить трейсы, в которых с большей вероятностью обнаружатся проблемы:
Обнаружение выбросов: отсортируйте по любой метрике (длина ответа, задержка, количество вызовов инструментов) и просмотрите экстремальные значения. Сигналы обратной связи от пользователей: приоритизируйте трейсы с негативными отзывами, обращениями в поддержку или эскалациями. Сортировка по метрикам: универсальные метрики могут служить сигналами для исследования при поиске интересных трейсов. Просматривайте и высокие, и низкие значения и трактуйте их как подсказки для исследования. На основе полученных знаний вы сможете построить кастомные оценщики для обнаруженных режимов отказов. Стратифицированная выборка: сгруппируйте трейсы по ключевым измерениям (тип пользователя, функция, категория запроса) и делайте выборку из каждой группы. Кластеризация эмбеддингов: сгенерируйте эмбеддинги запросов и кластеризуйте их для выявления естественных группировок. Берите выборку пропорционально из каждого кластера, но с повышенным весом малых кластеров для пограничных случаев. Единственно правильного способа кластеризации нет — это техника исследования для обнаружения паттернов, которые можно упустить при ручном просмотре.
As you get more sophisticated with how you sample, you can incorporate these tactics into the design of your annotation tools.
По мере развития вашего подхода к выборке вы сможете включить эти тактики в проектирование своих инструментов разметки.
👉 Want to learn more about AI Evals? Check out our AI Evals course. It’s a live cohort with hands on exercises and office hours. Here is a 25% discount code for readers. 👈
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Evaluation Design & Methodology
Дизайн и методология оценки
Q: Why do you recommend binary (pass/fail) evaluations instead of 1-5 ratings (Likert scales)?
В: Почему вы рекомендуете бинарные оценки (пройдено/не пройдено) вместо шкал 1–5 (шкалы Ликерта)?
Engineers often believe that Likert scales (1-5 ratings) provide more information than binary evaluations, allowing them to track gradual improvements. However, this added complexity often creates more problems than it solves in practice.
Инженеры часто считают, что шкалы Ликерта (оценки 1–5) дают больше информации, чем бинарные оценки, позволяя отслеживать постепенные улучшения. Однако на практике эта дополнительная сложность чаще создаёт больше проблем, чем решает.
Binary evaluations force clearer thinking and more consistent labeling. Likert scales introduce significant challenges: the difference between adjacent points (like 3 vs 4) is subjective and inconsistent across annotators, detecting statistical differences requires larger sample sizes, and annotators often default to middle values to avoid making hard decisions.
Бинарные оценки заставляют мыслить чётче и обеспечивают более последовательную разметку. Шкалы Ликерта вносят серьёзные трудности: разница между соседними значениями (например, 3 и 4) субъективна и непостоянна у разных аннотаторов, для выявления статистических различий требуются большие выборки, а аннотаторы часто выбирают средние значения, чтобы избежать сложных решений.
Having binary options forces people to make a decision rather than hiding uncertainty in middle values. Binary decisions are also faster to make during error analysis - you don’t waste time debating whether something is a 3 or 4.
Наличие бинарных вариантов заставляет людей принимать решение, а не прятать неуверенность в средних значениях. Бинарные решения также принимаются быстрее при анализе ошибок — вы не тратите время на споры, это 3 или 4.
For tracking gradual improvements, consider measuring specific sub-components with their own binary checks rather than using a scale. For example, instead of rating factual accuracy 1-5, you could track “4 out of 5 expected facts included” as separate binary checks. This preserves the ability to measure progress while maintaining clear, objective criteria.
Для отслеживания постепенных улучшений рассмотрите возможность измерения отдельных подкомпонентов с собственными бинарными проверками, вместо использования шкалы. Например, вместо оценки фактической точности по шкале 1–5 можно отслеживать «включены 4 из 5 ожидаемых фактов» как отдельные бинарные проверки. Это сохраняет возможность измерять прогресс, поддерживая при этом чёткие, объективные критерии.
Start with binary labels to understand what ‘bad’ looks like. Numeric labels are advanced and usually not necessary.
Начните с бинарных меток, чтобы понять, как выглядит «плохо». Числовые метки — это продвинутый уровень, который обычно не нужен.
Q: Should I practice eval-driven development?
В: Стоит ли практиковать разработку через оценки (eval-driven development)?
Generally no. Eval-driven development (writing evaluators before implementing features) sounds appealing but creates more problems than it solves. Unlike traditional software where failure modes are predictable, LLMs have infinite surface area for potential failures. You can’t anticipate what will break.
В общем случае нет. Разработка через оценки (написание оценщиков до реализации функций) звучит привлекательно, но создаёт больше проблем, чем решает. В отличие от традиционного программирования, где режимы отказов предсказуемы, у LLM бесконечная поверхность потенциальных сбоев. Вы не можете предугадать, что сломается.
A better approach is to start with error analysis. Write evaluators for errors you discover, not errors you imagine. This avoids getting blocked on what to evaluate and prevents wasted effort on metrics that have no impact on actual system quality.
Лучший подход — начать с анализа ошибок. Пишите оценщики для обнаруженных ошибок, а не для воображаемых. Это избавит от ступора с вопросом «что оценивать» и предотвратит напрасные усилия на метрики, не влияющие на реальное качество системы.
Exception: Eval-driven development may work for specific constraints where you know exactly what success looks like. If adding “never mention competitors,” writing that evaluator early may be acceptable.
Исключение: разработка через оценки может работать для конкретных ограничений, где вы точно знаете, как выглядит успех. Если вы добавляете правило «никогда не упоминать конкурентов», создание этого оценщика заранее может быть оправдано.
Most importantly, always do a cost-benefit analysis before implementing an eval. Ask whether the failure mode justifies the investment. Error analysis reveals which failures actually matter for your users.
Главное — всегда проводите анализ затрат и выгод перед реализацией оценки. Спросите себя, оправдывает ли данный режим отказа такие вложения. Анализ ошибок покажет, какие сбои действительно важны для ваших пользователей.
Q: Should I build automated evaluators for every failure mode I find?
В: Нужно ли создавать автоматические оценщики для каждого обнаруженного режима отказа?
Focus automated evaluators on failures that persist after fixing your prompts. Many teams discover their LLM doesn’t meet preferences they never actually specified - like wanting short responses, specific formatting, or step-by-step reasoning. Fix these obvious gaps first before building complex evaluation infrastructure.
Сосредоточьте автоматические оценщики на сбоях, которые сохраняются после исправления промптов. Многие команды обнаруживают, что их LLM не соответствует предпочтениям, которые они на самом деле никогда не формулировали — например, желание кратких ответов, определённого форматирования или пошагового рассуждения. Сначала устраните эти очевидные пробелы, а затем стройте сложную инфраструктуру оценки.
Consider the cost hierarchy of different evaluator types. Simple assertions and reference-based checks (comparing against known correct answers) are cheap to build and maintain. LLM-as-Judge evaluators require 100+ labeled examples, ongoing weekly maintenance, and coordination between developers, PMs, and domain experts. This cost difference should shape your evaluation strategy.
Учитывайте иерархию стоимости различных типов оценщиков. Простые утверждения (assertions) и проверки по эталону (сравнение с известными правильными ответами) дёшевы в создании и поддержке. Оценщики LLM-as-Judge требуют 100+ размеченных примеров, еженедельного обслуживания и координации между разработчиками, продакт-менеджерами и доменными экспертами. Эта разница в стоимости должна формировать вашу стратегию оценки.
Only build expensive evaluators for problems you’ll iterate on repeatedly. Since LLM-as-Judge comes with significant overhead, save it for persistent generalization failures - not issues you can fix trivially. Start with cheap code-based checks where possible: regex patterns, structural validation, or execution tests. Reserve complex evaluation for subjective qualities that can’t be captured by simple rules.
Создавайте дорогие оценщики только для проблем, над которыми вы будете итерировать многократно. Поскольку LLM-as-Judge сопряжён со значительными накладными расходами, приберегите его для устойчивых ошибок обобщения — а не для проблем, которые исправляются тривиально. Начинайте с дешёвых кодовых проверок, где возможно: регулярные выражения, валидация структуры или тесты исполнения. Оставляйте сложную оценку для субъективных качеств, которые невозможно охватить простыми правилами.
Q: Should I use "ready-to-use" evaluation metrics?
В: Стоит ли использовать «готовые» метрики оценки?
No. Generic evaluations waste time and create false confidence. (Unless you’re using them for exploration).
Нет. Универсальные оценки тратят время и создают ложную уверенность. (Если только вы не используете их для исследования.)
One instructor noted:
Один из преподавателей отметил:
“All you get from using these prefab evals is you don’t know what they actually do and in the best case they waste your time and in the worst case they create an illusion of confidence that is unjustified.”1
«Всё, что вы получаете от использования этих готовых оценок — вы не знаете, что они на самом деле делают, и в лучшем случае они тратят ваше время, а в худшем — создают иллюзию уверенности, которая ничем не подкреплена.»1
Generic evaluation metrics are everywhere. Eval libraries contain scores like helpfulness, coherence, quality, etc. promising easy evaluation. These metrics measure abstract qualities that may not matter for your use case. Good scores on them don’t mean your system works.
Универсальные метрики оценки повсюду. Библиотеки оценки содержат показатели вроде полезности, связности, качества и т. д., обещая лёгкую оценку. Эти метрики измеряют абстрактные свойства, которые могут быть нерелевантны для вашего сценария. Хорошие результаты по ним не означают, что ваша система работает.
Instead, conduct error analysis to understand failures. Define binary failure modes based on real problems. Create custom evaluators for those failures and validate them against human judgment. Essentially, the entire evals process.
Вместо этого проведите анализ ошибок, чтобы понять сбои. Определите бинарные режимы отказов на основе реальных проблем. Создайте кастомные оценщики для этих сбоев и валидируйте их относительно человеческих суждений. По сути — весь процесс оценки.
Experienced practitioners may still use these metrics, just not how you’d expect. As Picasso said: “Learn the rules like a pro, so you can break them like an artist.” Once you understand why generic metrics fail as evaluations, you can repurpose them as exploration tools to find interesting traces (explained in the next FAQ).
Опытные практики всё же могут использовать эти метрики, просто не так, как вы ожидаете. Как говорил Пикассо: «Изучите правила как профессионал, чтобы нарушать их как художник». Когда вы поймёте, почему универсальные метрики не работают в качестве оценок, вы сможете перепрофилировать их как инструменты исследования для поиска интересных трейсов (объясняется в следующем FAQ).
Q: Are similarity metrics (BERTScore, ROUGE, etc.) useful for evaluating LLM outputs?
В: Полезны ли метрики сходства (BERTScore, ROUGE и др.) для оценки выходов LLM?
Generic metrics like BERTScore, ROUGE, cosine similarity, etc. are not useful for evaluating LLM outputs in most AI applications. Instead, we recommend using error analysis to identify metrics specific to your application’s behavior. We recommend designing binary pass/fail.) evals (using LLM-as-judge) or code-based assertions.
Универсальные метрики вроде BERTScore, ROUGE, косинусного сходства и т. д. не полезны для оценки выходов LLM в большинстве ИИ-приложений. Вместо них мы рекомендуем использовать анализ ошибок для выявления метрик, специфичных для поведения вашего приложения. Мы рекомендуем проектировать бинарные (пройдено/не пройдено) оценки (с использованием LLM-as-Judge) или кодовые утверждения (assertions).
As an example, consider a real estate CRM assistant. Suggesting showings that aren’t available (can be tested with an assertion) or confusing client personas (can be tested with a LLM-as-judge) is problematic . Generic metrics like similarity or verbosity won’t catch this. A relevant quote from the course:
Для примера рассмотрим CRM-ассистент для недвижимости. Предложение показов, которые недоступны (можно протестировать утверждением), или путаница между персонами клиентов (можно протестировать с LLM-as-Judge) — это проблемы. Универсальные метрики вроде сходства или многословия этого не поймают. Релевантная цитата из курса:
“The abuse of generic metrics is endemic. Many eval vendors promote off the shelf metrics, which ensnare engineers into superfluous tasks.”
«Злоупотребление универсальными метриками носит массовый характер. Многие поставщики инструментов оценки продвигают готовые метрики, которые затягивают инженеров в бесполезную работу.»
Similarity metrics aren’t always useless. They have utility in domains like search and recommendation (and therefore can be useful for optimizing and debugging retrieval for RAG). For example, cosine similarity between embeddings can measure semantic closeness in retrieval systems, and average pairwise similarity can assess output diversity (where lower similarity indicates higher diversity).
Метрики сходства не всегда бесполезны. Они полезны в доменах поиска и рекомендаций (и, следовательно, могут быть полезны для оптимизации и отладки поиска в RAG). Например, косинусное сходство между эмбеддингами может измерять семантическую близость в поисковых системах, а среднее попарное сходство позволяет оценивать разнообразие выходов (где более низкое сходство означает большее разнообразие).
Q: Can I use the same model for both the main task and evaluation?
В: Можно ли использовать одну и ту же модель для основной задачи и для оценки?
For LLM-as-Judge selection, using the same model is usually fine because the judge is doing a different task than your main LLM pipeline. While research has shown that models can exhibit bias when evaluating their own outputs, what ultimately matters is how well your judge aligns with human judgments. The judges we recommend building do scoped binary classification tasks. We’ve found that iterative alignment with human labels is usually achievable on this constrained task.
При выборе модели для LLM-as-Judge использование той же модели обычно допустимо, потому что судья выполняет задачу, отличную от вашего основного LLM-пайплайна. Хотя исследования показали, что модели могут проявлять предвзятость при оценке собственных выходов, в конечном счёте важно, насколько хорошо ваш судья согласуется с человеческими суждениями. Судьи, которых мы рекомендуем создавать, выполняют узкие задачи бинарной классификации. Мы обнаружили, что итеративная настройка согласованности с человеческими метками обычно достижима для такой ограниченной задачи.
Focus on achieving high True Positive Rate (TPR) and True Negative Rate (TNR) with your judge on a held out labeled test set. If you struggle to achieve good alignment with human scores, then consider trying a different model. However onboarding new model providers may involve non-trivial effort in some organizations, which is why we don’t advocate for using different models by default unless there’s a specific alignment issue.
Сосредоточьтесь на достижении высокого показателя истинно положительных (TPR) и истинно отрицательных (TNR) результатов вашего судьи на отложенном размеченном тестовом наборе. Если вам не удаётся достичь хорошей согласованности с человеческими оценками, попробуйте другую модель. Однако подключение нового поставщика моделей может потребовать нетривиальных усилий в некоторых организациях, поэтому мы не рекомендуем использовать разные модели по умолчанию, если нет конкретной проблемы с согласованностью.
When selecting judge models, start with the most capable models available to establish strong alignment with human judgments. You can optimize for cost later once you’ve established reliable evaluation criteria.
При выборе моделей для судьи начинайте с самых мощных доступных моделей, чтобы установить надёжную согласованность с человеческими суждениями. Оптимизировать по стоимости можно позднее, когда вы установите надёжные критерии оценки.
Q: How do we evaluate a model’s ability to express uncertainty or "know what it doesn’t know"?
В: Как оценить способность модели выражать неуверенность или «знать, чего она не знает»?
Many applications require a model that can refuse to answer a question when it lacks sufficient information. To evaluate whether this refusal behavior is well-calibrated, you need to test if the model refuses at the appropriate times without refusing to answer questions it should be able to answer.
Многие приложения требуют модели, способной отказаться отвечать на вопрос, когда информации недостаточно. Чтобы оценить, правильно ли откалибровано такое поведение отказа, нужно проверить, отказывает ли модель в нужные моменты, не отказывая при этом на вопросы, на которые должна уметь ответить.
To do this effectively, you should construct an evaluation set that has the following components:
Для эффективной проверки вам нужно составить набор для оценки со следующими компонентами:
Вопросы с ответом: сценарии, в которых правильный, проверяемый ответ присутствует в предоставленном контексте модели или в её общих знаниях. Вопросы без ответа: сценарии, намеренно провоцирующие модель на галлюцинации. Сюда входят вопросы с ложными предпосылками, запросы об информации, явно отсутствующей в контексте, или темы далеко за пределами её базы знаний.
While the exact proportion isn’t critical, a balanced set with a roughly equal number of answerable and unanswerable questions is a good starting point. The diversity and difficulty of the questions are more important than the precise ratio.
Хотя точная пропорция не критична, сбалансированный набор с примерно равным количеством вопросов с ответом и без ответа — хорошая отправная точка. Разнообразие и сложность вопросов важнее точного соотношения.
The evaluation itself is a binary (Pass/Fail) check of the model’s judgment. A “Pass” requires the model to satisfy two conditions: it must answer the answerable questions while also refusing to answer the unanswerable ones. A failure is defined as providing a fabricated answer to an unanswerable question, which indicates poor calibration.
Сама оценка — это бинарная (пройдено/не пройдено) проверка суждений модели. «Пройдено» требует от модели выполнения двух условий: она должна отвечать на вопросы с ответом и при этом отказываться отвечать на вопросы без ответа. Провал определяется как предоставление выдуманного ответа на вопрос без ответа, что указывает на плохую калибровку.
In the research literature, this capability is known as “Abstention Ability.” To improve this behavior, it is worth searching for this term on Arxiv to understand the latest techniques.
В научной литературе эта способность известна как «Abstention Ability» (способность к воздержанию). Для улучшения этого поведения стоит поискать этот термин на Arxiv, чтобы изучить новейшие методики.
👉 Want to learn more about AI Evals? Check out our AI Evals course. It’s a live cohort with hands on exercises and office hours. Here is a 25% discount code for readers. 👈
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Human Annotation & Process
Человеческая разметка и процесс
Q: How many people should annotate my LLM outputs?
В: Сколько человек должны размечать выходы моего LLM?
For most small to medium-sized companies, appointing a single domain expert as a “benevolent dictator” is the most effective approach. This person—whether it’s a psychologist for a mental health chatbot, a lawyer for legal document analysis, or a customer service director for support automation—becomes the definitive voice on quality standards.
Для большинства малых и средних компаний назначение одного доменного эксперта «доброжелательным диктатором» — наиболее эффективный подход. Этот человек — будь то психолог для чат-бота психологической помощи, юрист для анализа юридических документов или директор клиентского сервиса для автоматизации поддержки — становится решающим голосом по стандартам качества.
A single expert eliminates annotation conflicts and prevents the paralysis that comes from “too many cooks in the kitchen”. The benevolent dictator can incorporate input and feedback from others, but they drive the process. If you feel like you need five subject matter experts to judge a single interaction, it’s a sign your product scope might be too broad.
Один эксперт устраняет конфликты при разметке и предотвращает паралич от «слишком много поваров на кухне». Доброжелательный диктатор может учитывать вклад и обратную связь от других, но именно он ведёт процесс. Если вам кажется, что для оценки одного взаимодействия нужны пять предметных экспертов — это признак того, что охват вашего продукта, возможно, слишком широк.
However, larger organizations or those operating across multiple domains (like a multinational company with different cultural contexts) may need multiple annotators. When you do use multiple people, you’ll need to measure their agreement using metrics like Cohen’s Kappa, which accounts for agreement beyond chance. However, use your judgment. Even in larger companies, a single expert is often enough.
Однако крупные организации или те, что работают в нескольких доменах (например, международная компания с различными культурными контекстами), могут нуждаться в нескольких аннотаторах. Если вы привлекаете нескольких человек, вам нужно измерять их согласованность с помощью метрик вроде каппы Коэна, учитывающей согласие сверх случайного. Тем не менее, используйте здравый смысл. Даже в крупных компаниях одного эксперта часто достаточно.
Start with a benevolent dictator whenever feasible. Only add complexity when your domain demands it.
Начинайте с доброжелательного диктатора, когда это возможно. Добавляйте сложность только тогда, когда этого требует ваш домен.
Q: Should product managers and engineers collaborate on error analysis? How?
В: Должны ли продакт-менеджеры и инженеры совместно проводить анализ ошибок? Как?
At the outset, collaborate to establish shared context. Engineers catch technical issues like retrieval issues and tool errors. PMs identify product failures like unmet user expectations, confusing responses, or missing features users expect.
На начальном этапе сотрудничайте для формирования общего контекста. Инженеры замечают технические проблемы вроде ошибок поиска и сбоев инструментов. Продакт-менеджеры выявляют продуктовые сбои — неоправданные ожидания пользователей, запутанные ответы или отсутствие функций, которых пользователи ожидают.
As time goes on you should lean towards a benevolent dictator for error analysis: a domain expert or PM who understands user needs. Empower domain experts to evaluate actual outcomes rather than technical implementation. Ask “Has an appointment been made?” not “Did the tool call succeed?” The best way to empower the domain expert is to give them custom annotation tools that display system outcomes alongside traces. Show the confirmation, generated email, or database update that validates goal completion. Keep all context on one screen so non-technical reviewers focus on results.
Со временем стоит склоняться к модели доброжелательного диктатора для анализа ошибок: доменного эксперта или продакт-менеджера, понимающего потребности пользователей. Дайте доменным экспертам возможность оценивать фактические результаты, а не техническую реализацию. Спрашивайте «Была ли записана встреча?», а не «Успешно ли прошёл вызов инструмента?». Лучший способ расширить полномочия доменного эксперта — дать ему кастомные инструменты разметки, отображающие результаты системы рядом с трейсами. Покажите подтверждение, сгенерированное письмо или обновление базы данных, подтверждающее выполнение цели. Держите весь контекст на одном экране, чтобы нетехнические рецензенты фокусировались на результатах.
Q: Should I outsource annotation & labeling to a third party?
В: Стоит ли отдавать разметку и маркировку на аутсорс?
Outsourcing error analysis is usually a big mistake (with some exceptions). The core of evaluation is building the product intuition that only comes from systematically analyzing your system’s failures. You should be extremely skeptical of this process being delegated.
Аутсорсинг анализа ошибок — обычно серьёзная ошибка (с некоторыми исключениями). Суть оценки — формирование продуктовой интуиции, которая появляется только при систематическом анализе сбоев вашей системы. К делегированию этого процесса следует относиться крайне скептически.
The Dangers of Outsourcing
Опасности аутсорсинга
When you outsource annotation, you often break the feedback loop between observing a failure and understanding how to improve the product. Problems with outsourcing include:
Когда вы отдаёте разметку на аутсорс, вы часто разрываете обратную связь между наблюдением сбоя и пониманием того, как улучшить продукт. Проблемы аутсорсинга:
Поверхностная разметка: даже чётко определённые метрики требуют нюансированных суждений, которых нет у внешних команд. Критическая ошибка в анализе — исключение доменных экспертов из процесса разметки. Делегирование этой задачи людям без доменной экспертизы, таким как обычные разработчики или ИТ-специалисты, часто приводит к поверхностной или некорректной разметке. Потеря негласных знаний: главный доменный эксперт обладает неявными знаниями и пониманием пользователей, которые невозможно полностью зафиксировать в рубрике. Привлечение таких экспертов помогает раскрыть их предпочтения и ожидания, которые они могут не суметь сформулировать заранее. Конфликты и рассогласование разметки: без общего контекста внешние аннотаторы могут порождать больше разногласий, чем разрешать. Достижение согласованности — проблема даже для внутренних команд, а значит, вы потратите на этот процесс ещё больше времени.
The Recommended Approach: Build Internal Capability
Рекомендуемый подход: развивайте внутренние компетенции
Instead of outsourcing, focus on building an efficient internal evaluation process.
Вместо аутсорсинга сосредоточьтесь на построении эффективного внутреннего процесса оценки.
1. Appoint a “Benevolent Dictator”. For most teams, the most effective strategy is to appoint a single, internal domain expert as the final decision-maker on quality. This individual sets the standard, ensures consistency, and develops a sense of ownership.
1. Назначьте «доброжелательного диктатора». Для большинства команд наиболее эффективная стратегия — назначить одного внутреннего доменного эксперта финальным арбитром качества. Этот человек задаёт стандарт, обеспечивает последовательность и развивает чувство ответственности.
2. Use a collaborative workflow for multiple annotators. If multiple annotators are necessary, follow a structured process to ensure alignment: * Draft an initial rubric with clear Pass/Fail definitions and examples. * Have each annotator label a shared set of traces independently to surface differences in interpretation. * Measure Inter-Annotator Agreement (IAA) using a chance-corrected metric like Cohen’s Kappa. * Facilitate alignment sessions to discuss disagreements and refine the rubric. * Iterate on this process until agreement is consistently high.
2. Используйте совместный рабочий процесс при наличии нескольких аннотаторов. Если несколько аннотаторов необходимы, следуйте структурированному процессу для обеспечения согласованности: * Составьте начальную рубрику с чёткими определениями «пройдено/не пройдено» и примерами. * Пусть каждый аннотатор независимо разметит общий набор трейсов для выявления различий в интерпретации. * Измерьте межаннотаторское согласие (IAA) с помощью метрики, скорректированной на случайность, например каппы Коэна. * Проведите сессии согласования для обсуждения разногласий и уточнения рубрики. * Итерируйте этот процесс, пока согласие не станет стабильно высоким.
How to Handle Capacity Constraints
Как справиться с ограничениями по ресурсам
Building internal capacity does not mean you have to label every trace. Use these strategies to manage the workload:
Развитие внутренних компетенций не означает, что нужно размечать каждый трейс. Используйте эти стратегии для управления нагрузкой:
Умная выборка: тщательно просматривайте небольшую репрезентативную выборку трейсов. Эффективнее проанализировать 100 разнообразных трейсов для поиска паттернов, чем поверхностно разметить тысячи. Протокол «мышления вслух»: чтобы максимально использовать ограниченное время эксперта, применяйте эту технику из юзабилити-тестирования. Попросите эксперта проговаривать свой мыслительный процесс при просмотре нескольких трейсов. Этот метод может раскрыть глубокие инсайты за одну часовую сессию. Создавайте лёгкие кастомные инструменты: создайте кастомные инструменты разметки для ускорения процесса обзора и повышения пропускной способности.
Exceptions for External Help
Исключения для внешней помощи
While outsourcing the core error analysis process is not recommended, there are some scenarios where external help is appropriate:
Хотя аутсорсинг основного процесса анализа ошибок не рекомендуется, есть сценарии, в которых внешняя помощь уместна:
Чисто механические задачи: для высокообъективных, однозначных задач — таких как определение номера телефона или валидация адреса электронной почты — можно привлечь внешних аннотаторов после того, как рубрика определена строгим внутренним процессом. Задачи без продуктового контекста: чётко определённые задачи, не требующие понимания специфических требований вашего продукта, можно передать на аутсорс. Перевод — хороший пример: он требует лингвистической экспертизы, но не глубокого знания продукта. Привлечение предметных экспертов: наём внешних SME для роли ваших внутренних доменных экспертов — это не аутсорсинг, а привнесение необходимой экспертизы в процесс оценки. Например, AnkiHub нанял студентов-медиков 4-го курса для оценки своих RAG-систем для медицинского контента вместо привлечения обычных аннотаторов.
Q: What parts of evals can be automated with LLMs?
В: Какие части оценки можно автоматизировать с помощью LLM?
LLMs can speed up parts of your eval workflow, but they can’t replace human judgment where your expertise is essential. For example, if you let an LLM handle all of error analysis (i.e., reviewing and annotating traces), you might overlook failure cases that matter for your product. Suppose users keep mentioning “lag” in feedback, but the LLM lumps these under generic “performance issues” instead of creating a “latency” category. You’d miss a recurring complaint about slow response times and fail to prioritize a fix.
LLM могут ускорить части вашего рабочего процесса оценки, но не могут заменить человеческое суждение там, где ваша экспертиза незаменима. Например, если вы поручите LLM весь анализ ошибок (то есть просмотр и аннотирование трейсов), вы можете упустить случаи сбоев, важные для вашего продукта. Допустим, пользователи постоянно упоминают «задержки» в обратной связи, но LLM объединяет их в общую категорию «проблемы производительности» вместо создания категории «латентность». Вы пропустите повторяющуюся жалобу на медленное время отклика и не приоритизируете исправление.
That said, LLMs are valuable tools for accelerating certain parts of the evaluation workflow when used with oversight.
Тем не менее LLM — ценные инструменты для ускорения определённых этапов рабочего процесса оценки, когда используются под контролем.
Here are some areas where LLMs can help:
Вот области, в которых LLM могут помочь:
Первичное осевое кодирование: после того как вы сами провели открытое кодирование 30–50 трейсов, используйте LLM для организации ваших сырых заметок о сбоях в предлагаемые группировки. Это помогает быстро находить паттерны, но всегда пересматривайте и уточняйте кластеры самостоятельно. Примечание: если вы не знакомы с осевым и открытым кодированием, см. этот FAQ. Соотнесение аннотаций с режимами отказов: когда вы определили категории сбоев, можно попросить LLM предложить, какие категории применимы к каждому новому трейсу (например: «Учитывая эту аннотацию: [открытая_аннотация] и эти режимы отказов: [список_режимов_отказов], какие подходят?»). Предложение улучшений промптов: когда вы замечаете повторяющиеся проблемы, попросите LLM предложить конкретные изменения ваших промптов. Проверяйте эти предложения перед применением. Анализ данных аннотаций: используйте LLM или ноутбуки с ИИ для поиска паттернов в ваших метках — например, «жалобы на задержки возрастают в 3 раза в часы пиковой нагрузки» или «медленное время отклика чаще всего отмечается пользователями мобильных устройств».
However, you shouldn’t outsource these activities to an LLM:
Однако эти действия не стоит делегировать LLM:
Первичное открытое кодирование: всегда читайте сырые трейсы самостоятельно в начале. Именно так вы обнаруживаете новые типы сбоев, понимаете болевые точки пользователей и вырабатываете интуицию относительно своих данных. Никогда не пропускайте и не делегируйте это. Валидация таксономий сбоев: группировки, созданные LLM, требуют вашего пересмотра. Например, LLM может объединить «приложение падает после входа» и «вход слишком медленный» в одну категорию «проблемы со входом», хотя одна — проблема стабильности, а другая — производительности. Без вашего вмешательства вы упустите, что эти проблемы требуют разных решений. Разметка эталонных данных: для любых данных, используемых для тестирования/валидации оценщиков LLM-as-Judge, вручную проверяйте каждую метку. LLM могут ошибаться, что приводит к ненадёжным бенчмаркам. Анализ первопричин: LLM могут указать на очевидные проблемы, но только ручной просмотр выявит паттерны вроде ошибок, возникающих в определённых рабочих процессах или пограничных случаях — например, баги, проявляющиеся только при вставке данных из Excel.
In conclusion, start by examining data manually to understand what’s actually going wrong. Use LLMs to scale what you’ve learned, not to avoid looking at data.
В заключение: начинайте с ручного изучения данных, чтобы понять, что действительно идёт не так. Используйте LLM для масштабирования того, что вы узнали, а не для того, чтобы избежать работы с данными.
Q: Should I stop writing prompts manually in favor of automated tools?
В: Стоит ли отказаться от ручного написания промптов в пользу автоматизированных инструментов?
Automating prompt engineering can be tempting, but you should be skeptical of tools that promise to optimize prompts for you, especially in early stages of development. When you write a prompt, you are forced to clarify your assumptions and externalize your requirements. Good writing is good thinking 2. If you delegate this task to an automated tool too early, you risk never fully understanding your own requirements or the model’s failure modes.
Автоматизация промпт-инжиниринга может быть соблазнительной, но стоит скептически относиться к инструментам, обещающим оптимизировать промпты за вас, особенно на ранних этапах разработки. Когда вы пишете промпт, вы вынуждены прояснять свои предположения и формализовать свои требования. Хорошее письмо — это хорошее мышление2. Если вы делегируете эту задачу автоматизированному инструменту слишком рано, вы рискуете никогда полностью не понять собственные требования или режимы отказов модели.
This is because automated prompt optimization typically hill-climb a predefined evaluation metric. It can refine a prompt to perform better on known failures, but it cannot discover new ones. Discovering new errors requires error analysis. Furthermore, research shows that evaluation criteria tends to shift after reviewing a model’s outputs, a phenomenon known as “criteria drift” 3. This means that evaluation is an iterative, human-driven sensemaking process, not a static target that can be set once and handed off to an optimizer.
Дело в том, что автоматическая оптимизация промптов обычно выполняет «восхождение на холм» по заранее определённой метрике оценки. Она может улучшить промпт на известных сбоях, но не может обнаружить новые. Обнаружение новых ошибок требует анализа ошибок. Кроме того, исследования показывают, что критерии оценки имеют тенденцию смещаться после просмотра выходов модели — явление, известное как «дрейф критериев»3. Это означает, что оценка — итеративный, управляемый человеком процесс осмысления, а не статическая цель, которую можно задать один раз и передать оптимизатору.
A pragmatic approach is to use LLMs to improve your prompt based on open coding (open-ended notes about traces). This way, you maintain a human in the loop who is looking at the data and externalizing their requirements. Once you have a high-quality set of evals, prompt optimization can be effective for that last mile of performance.
Прагматичный подход — использовать LLM для улучшения промпта на основе открытого кодирования (свободных заметок о трейсах). Так вы сохраняете человека в контуре, который смотрит на данные и формализует свои требования. Когда у вас есть качественный набор оценок, оптимизация промптов может быть эффективна на последнем этапе повышения производительности.
👉 Want to learn more about AI Evals? Check out our AI Evals course. It’s a live cohort with hands on exercises and office hours. Here is a 25% discount code for readers. 👈
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Tools & Infrastructure
Инструменты и инфраструктура
Q: Should I build a custom annotation tool or use something off-the-shelf?
В: Создавать кастомный инструмент разметки или использовать готовое решение?
Build a custom annotation tool. This is the single most impactful investment you can make for your AI evaluation workflow. With AI-assisted development tools like Cursor or Lovable, you can build a tailored interface in hours. I often find that teams with custom annotation tools iterate ~10x faster.
Создавайте кастомный инструмент разметки. Это самая результативная инвестиция, которую вы можете сделать для рабочего процесса оценки ИИ. С помощью инструментов разработки с ИИ, таких как Cursor или Lovable, вы сможете создать адаптированный интерфейс за часы. По моему опыту, команды с кастомными инструментами разметки итерируют примерно в 10 раз быстрее.
Custom tools excel because:
Кастомные инструменты превосходят готовые, потому что:
Они показывают весь контекст из нескольких систем в одном месте Они могут отображать ваши данные в специфичном для продукта виде (изображения, виджеты, markdown, кнопки и т. д.) Они спроектированы под ваш конкретный рабочий процесс (кастомные фильтры, сортировка, индикаторы прогресса и т. д.)
Off-the-shelf tools may be justified when you need to coordinate dozens of distributed annotators with enterprise access controls. Even then, many teams find the configuration overhead and limitations aren’t worth it.
Готовые инструменты могут быть оправданы, когда нужно координировать десятки распределённых аннотаторов с корпоративным контролем доступа. Но даже тогда многие команды считают, что накладные расходы на настройку и ограничения того не стоят.
Isaac’s Anki flashcard annotation app shows the power of custom tools—handling 400+ results per query with keyboard navigation and domain-specific evaluation criteria that would be nearly impossible to configure in a generic tool.
Приложение Isaac для аннотации карточек Anki демонстрирует мощь кастомных инструментов — обработка 400+ результатов за запрос с навигацией по клавиатуре и доменно-специфическими критериями оценки, которые было бы практически невозможно настроить в универсальном инструменте.
Q: What makes a good custom interface for reviewing LLM outputs?
В: Что делает интерфейс для просмотра выходов LLM хорошим?
Great interfaces make human review fast, clear, and motivating. We recommend building your own annotation tool customized to your domain. The following features are possible enhancements we’ve seen work well, but you don’t need all of them. The screenshots shown are illustrative examples to clarify concepts. In practice, I rarely implement all these features in a single app. It’s ultimately a judgment call based on your specific needs and constraints.
Отличные интерфейсы делают ручной просмотр быстрым, наглядным и мотивирующим. Мы рекомендуем создать собственный инструмент разметки, адаптированный к вашему домену. Следующие возможности — это потенциальные улучшения, которые мы видели на практике, но вам не нужны все сразу. Показанные скриншоты — иллюстративные примеры для пояснения концепций. На практике я редко реализую все эти возможности в одном приложении. В конечном счёте это вопрос суждения, исходя из ваших конкретных потребностей и ограничений.
1. Render Traces Intelligently, Not Generically:
1. Отображайте трейсы осмысленно, а не шаблонно:
Present the trace in a way that’s intuitive for the domain. If you’re evaluating generated emails, render them to look like emails. If the output is code, use syntax highlighting. Allow the reviewer to see the full trace (user input, tool calls, and LLM reasoning), but keep less important details in collapsed sections that can be expanded. Here is an example of a custom annotation tool for reviewing real estate assistant emails:
Представляйте трейс интуитивно понятным для домена способом. Если вы оцениваете сгенерированные письма, показывайте их как письма. Если выход — код, используйте подсветку синтаксиса. Дайте рецензенту видеть полный трейс (ввод пользователя, вызовы инструментов и рассуждения LLM), но менее важные детали поместите в сворачиваемые секции. Вот пример кастомного инструмента разметки для обзора писем ИИ-ассистента по недвижимости:
2. Show Progress and Support Keyboard Navigation:
2. Показывайте прогресс и поддерживайте навигацию клавиатурой:
Keep reviewers in a state of flow by minimizing friction and motivating completion. Include progress indicators (e.g., “Trace 45 of 100”) to keep the review session bounded and encourage completion. Enable hotkeys for navigating between traces (e.g., N for next), applying labels, and saving notes quickly. Below is an illustration of these features:
Поддерживайте рецензентов в состоянии потока, минимизируя трение и мотивируя к завершению. Включите индикаторы прогресса (например, «Трейс 45 из 100»), чтобы ограничить сессию просмотра и стимулировать завершение. Добавьте горячие клавиши для навигации между трейсами (например, N — следующий), применения меток и быстрого сохранения заметок. Ниже — иллюстрация этих возможностей:
3. Trace navigation through clustering, filtering, and search:
3. Навигация по трейсам через кластеризацию, фильтрацию и поиск:
Allow reviewers to filter traces by metadata or search by keywords. Semantic search helps find conceptually similar problems. Clustering similar traces (like grouping by user persona) lets reviewers spot recurring issues and explore hypotheses. Below is an illustration of these features:
Позвольте рецензентам фильтровать трейсы по метаданным или искать по ключевым словам. Семантический поиск помогает находить концептуально похожие проблемы. Кластеризация похожих трейсов (например, группировка по персоне пользователя) позволяет рецензентам выявлять повторяющиеся проблемы и исследовать гипотезы. Ниже — иллюстрация этих возможностей:
4. Prioritize labeling traces you think might be problematic:
4. Приоритизируйте разметку трейсов, которые могут быть проблемными:
Surface traces flagged by guardrails, CI failures, or automated evaluators for review. Provide buttons to take actions like adding to datasets, filing bugs, or re-running pipeline tests. Display relevant context (pipeline version, eval scores, reviewer info) directly in the interface to minimize context switching. Below is an illustration of these ideas:
Выделяйте трейсы, отмеченные защитными барьерами, сбоями CI или автоматическими оценщиками. Предусмотрите кнопки для действий — добавления в датасеты, создания багов или повторного запуска тестов пайплайна. Отображайте релевантный контекст (версия пайплайна, оценки оценщиков, информация о рецензенте) прямо в интерфейсе, чтобы минимизировать переключение контекста. Ниже — иллюстрация этих идей:
General Principle: Keep it minimal
Общий принцип: сохраняйте минимализм
Keep your annotation interface minimal. Only incorporate these ideas if they provide a benefit that outweighs the additional complexity and maintenance overhead.
Держите интерфейс разметки минималистичным. Включайте эти идеи только если их польза перевешивает дополнительную сложность и затраты на поддержку.
Q: What gaps in eval tooling should I be prepared to fill myself?
В: Какие пробелы в инструментарии оценки мне придётся заполнять самостоятельно?
Most eval tools handle the basics well: logging complete traces, tracking metrics, prompt playgrounds, and annotation queues. These are table stakes. Here are four areas where you’ll likely need to supplement existing tools.
Большинство инструментов оценки хорошо справляются с базовыми задачами: логирование полных трейсов, отслеживание метрик, песочницы для промптов и очереди для разметки. Это минимум. Вот четыре области, в которых вам, скорее всего, придётся дополнять существующие инструменты.
Watch for vendors addressing these gaps: it’s a strong signal they understand practitioner needs.
Следите за вендорами, которые закрывают эти пробелы: это сильный сигнал того, что они понимают потребности практиков.
1. Error Analysis and Pattern Discovery
1. Анализ ошибок и обнаружение паттернов
After reviewing traces where your AI fails, can your tooling automatically cluster similar issues? For instance, if multiple traces show the assistant using casual language for luxury clients, you need something that recognizes this broader “persona-tone mismatch” pattern. We recommend building capabilities that use AI to suggest groupings, rewrite your observations into clearer failure taxonomies, help find similar cases through semantic search, etc.
После просмотра трейсов, в которых ваш ИИ ошибается, может ли ваш инструментарий автоматически кластеризовать похожие проблемы? Например, если в нескольких трейсах ассистент использует неформальный язык для клиентов премиум-сегмента, вам нужно что-то, что распознает более широкий паттерн «несоответствие персоны и тона». Мы рекомендуем создавать возможности, использующие ИИ для предложения группировок, переформулирования ваших наблюдений в более чёткие таксономии сбоев, помощи в поиске похожих случаев через семантический поиск и т. д.
2. AI-Powered Assistance Throughout the Workflow
2. ИИ-помощь на протяжении всего рабочего процесса
The most effective workflows use AI to accelerate every stage of evaluation. During error analysis, you want an LLM helping categorize your open-ended observations into coherent failure modes. For example, you might annotate several traces with notes like “wrong tone for investor,” “too casual for luxury buyer,” etc. Your tooling should recognize these as the same underlying pattern and suggest a unified “persona-tone mismatch” category.
Наиболее эффективные рабочие процессы используют ИИ для ускорения каждого этапа оценки. При анализе ошибок вам нужен LLM, помогающий категоризировать ваши свободные наблюдения в связные режимы отказов. Например, вы можете аннотировать несколько трейсов заметками вроде «неправильный тон для инвестора», «слишком неформально для покупателя элитной недвижимости» и т. д. Ваш инструментарий должен распознать их как один и тот же глубинный паттерн и предложить объединённую категорию «несоответствие персоны и тона».
You’ll also want AI assistance in proposing fixes. After identifying 20 cases where your assistant omits pet policies from property summaries, can your workflow analyze these failures and suggest specific prompt modifications? Can it draft refinements to your SQL generation instructions when it notices patterns of missing WHERE clauses?
Вам также понадобится ИИ-помощь в предложении исправлений. После выявления 20 случаев, когда ваш ассистент упускает правила содержания домашних животных в описаниях объектов, может ли ваш рабочий процесс проанализировать эти сбои и предложить конкретные изменения промпта? Может ли он подготовить уточнения ваших инструкций по генерации SQL, когда замечает паттерн пропущенных условий WHERE?
Good workflows also help you conduct data analysis of your annotations and traces. I like using notebooks with AI in-the-loop like Julius or Hex. These help me discover insights like “location ambiguity errors spike 3x when users mention neighborhood names” or “tone mismatches occur 80% more often in email generation than other modalities.”
Хорошие рабочие процессы также помогают проводить анализ данных ваших аннотаций и трейсов. Мне нравится использовать ноутбуки с ИИ в контуре, такие как Julius или Hex. Они помогают мне обнаруживать инсайты вроде «ошибки неоднозначности местоположения возрастают в 3 раза, когда пользователи упоминают названия районов» или «несоответствия тона возникают на 80% чаще при генерации писем, чем в других модальностях».
3. Custom Evaluators Over Generic Metrics
3. Кастомные оценщики вместо универсальных метрик
Be prepared to build most of your evaluators from scratch. Generic metrics like “hallucination score” or “helpfulness rating” rarely capture what actually matters for your application—like proposing unavailable showing times or omitting budget constraints from emails. In our experience, successful teams spend most of their effort on application-specific metrics.
Будьте готовы создавать большинство оценщиков с нуля. Универсальные метрики вроде «оценки галлюцинаций» или «рейтинга полезности» редко отражают то, что действительно важно для вашего приложения — например, предложение недоступного времени показа или пропуск бюджетных ограничений в письмах. По нашему опыту, успешные команды тратят основную часть усилий на метрики, специфичные для приложения.
4. APIs That Support Custom Annotation Apps
4. API, поддерживающие кастомные приложения для разметки
Custom annotation interfaces work best for most teams. This requires observability platforms with thoughtful APIs. I often have to build my own libraries and abstractions just to make bulk data export manageable. You shouldn’t have to paginate through thousands of requests or handle timeout-prone endpoints just to get your data. Look for platforms that provide true bulk export capabilities and, crucially, APIs that let you write annotations back efficiently.
Кастомные интерфейсы разметки лучше всего подходят большинству команд. Для этого необходимы платформы наблюдаемости с продуманными API. Мне часто приходится создавать собственные библиотеки и абстракции, чтобы сделать массовый экспорт данных управляемым. Вы не должны пагинировать тысячи запросов или справляться с эндпоинтами, склонными к тайм-аутам, только чтобы получить свои данные. Ищите платформы с настоящими возможностями массового экспорта и, что критически важно, API, позволяющими эффективно записывать аннотации обратно.
Q: What’s your favorite eval vendor?
В: Какой ваш любимый вендор инструментов оценки?
Eval tools are in an intensely competitive space. It would be futile to compare their features. If I tried to do such an analysis, it would be invalidated in a week! Vendors I encounter the most organically in my work are: Langsmith, Arize and Braintrust.
Инструменты оценки находятся в условиях жёсткой конкуренции. Сравнивать их функциональность бессмысленно. Если бы я попытался провести такой анализ, он устарел бы через неделю! Вендоры, с которыми я чаще всего сталкиваюсь естественным образом в своей работе: Langsmith, Arize и Braintrust.
When I help clients with vendor selection, the decision weighs heavily towards who can offer the best support, as opposed to purely features. This changes depending on size of client, use case, etc. Yes - it’s mainly the human factor that matters, and dare I say, vibes.
Когда я помогаю клиентам с выбором вендора, решение в значительной мере определяется тем, кто может предложить лучшую поддержку, а не только функциональностью. Это зависит от размера клиента, сценария использования и т. д. Да — в основном важен человеческий фактор и, осмелюсь сказать, ощущения.
I have no favorite vendor. At the core, their features are very similar - and I often build custom tools on top of them to fit my needs.
У меня нет любимого вендора. По сути, их функциональность очень схожа — и я часто создаю кастомные инструменты поверх них под свои нужды.
Here is a video series that has a live commentary on the relative strengths and weaknesses of the three aforementioned vendors.
Вот серия видео с живым комментарием о сильных и слабых сторонах трёх вышеупомянутых вендоров.
Q: How should I version and manage prompts?
В: Как версионировать и управлять промптами?
There is an unavoidable tension between keeping prompts close to the code vs. an environment that non-technical stakeholders can access.
Существует неизбежное противоречие между хранением промптов рядом с кодом и средой, доступной нетехническим заинтересованным лицам.
My preferred approach is storing prompts in Git. This treats them as software artifacts that are versioned, reviewed, and deployed atomically with the application code. While the Git command line is unfriendly for non-technical folks, the GitHub web interface and the GitHub Desktop app make it very approachable. When I was working at GitHub, I worked with many non-technical professionals, including lawyers and accountants, who used these tools effectively. Here is a blog post aimed at non-technical folks to get started.
Мой предпочтительный подход — хранение промптов в Git. Это превращает их в программные артефакты, которые версионируются, проходят ревью и развёртываются атомарно вместе с кодом приложения. Хотя командная строка Git недружелюбна для нетехнических людей, веб-интерфейс GitHub и десктопное приложение GitHub делают его весьма доступным. Когда я работал в GitHub, я сотрудничал со многими нетехническими специалистами, включая юристов и бухгалтеров, которые эффективно пользовались этими инструментами. Вот блог-пост, ориентированный на нетехнических людей, для начала работы.
Alternatively, most vendors in the LLM tooling space, such as observability platforms like Arize, Braintrust, and LangSmith, offer dedicated prompt management tools. These are accessible for rapid iteration but risk creating additional layers of indirection.
Альтернативно, большинство вендоров в пространстве инструментов для LLM, таких как платформы наблюдаемости Arize, Braintrust и LangSmith, предлагают специализированные инструменты управления промптами. Они удобны для быстрых итераций, но рискуют создать дополнительные уровни косвенности.
Why prompt management tools often fall short: AI products typically involve many moving parts: tools, RAG, agents, etc. Prompt management tools are inherently limiting because they can’t easily execute your application’s code. Even when they can, there’s often significant indirection involved, making it difficult to test prompts with your system’s capabilities.
Почему инструменты управления промптами часто не оправдывают ожиданий: ИИ-продукты обычно включают множество движущихся частей: инструменты, RAG, агенты и т. д. Инструменты управления промптами изначально ограничены, потому что не могут легко выполнять код вашего приложения. Даже когда могут — часто присутствует значительная косвенность, затрудняющая тестирование промптов с возможностями вашей системы.
When possible, a notebook provides a great solution for prompt experimentation If you have Python entry points into your codebase or your codebase is written in Python, Jupyter notebooks are particularly powerful for this purpose. You can experiment with prompts and iterate on your actual AI agents with their full tool and RAG capabilities. This makes it much easier to understand how your system works in practice. Additionally, you can create widgets and small user interfaces within notebooks, giving you the best of both worlds for experimentation and iteration. To see what this looks like in practice, Teresa Torres gives a fantastic, hands-on walkthrough of how she, as a PM, used notebooks for the entire eval and experimentation lifecycle:
Когда возможно, ноутбук — отличное решение для экспериментов с промптами. Если у вас есть Python-точки входа в кодовую базу или она написана на Python, Jupyter-ноутбуки особенно эффективны для этой цели. Вы можете экспериментировать с промптами и итерировать на ваших реальных ИИ-агентах со всеми их возможностями инструментов и RAG. Это значительно облегчает понимание того, как ваша система работает на практике. Кроме того, вы можете создавать виджеты и небольшие пользовательские интерфейсы внутри ноутбуков, получая лучшее из обоих миров для экспериментов и итераций. Чтобы увидеть, как это выглядит на практике, Teresa Torres даёт отличный, практический разбор того, как она, будучи продакт-менеджером, использовала ноутбуки для всего жизненного цикла оценки и экспериментов:
If notebooks are not feasible for your code base, an integrated prompt environment can be effective for experimentation. Either way, I prefer to version and manage prompts in Git.
Если ноутбуки не подходят для вашей кодовой базы, интегрированная среда для промптов может быть эффективной для экспериментов. В любом случае я предпочитаю версионировать и управлять промптами в Git.
👉 Want to learn more about AI Evals? Check out our AI Evals course. It’s a live cohort with hands on exercises and office hours. Here is a 25% discount code for readers. 👈
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Production & Deployment
Продакшен и развёртывание
Q: How are evaluations used differently in CI/CD vs. monitoring production?
В: Чем различается использование оценок в CI/CD и в мониторинге продакшена?
The most important difference between CI vs. production evaluation is the data used for testing.
Самое важное различие между оценкой в CI и в продакшене — данные, используемые для тестирования.
Test datasets for CI are small (in many cases 100+ examples) and purpose-built. Examples cover core features, regression tests for past bugs, and known edge cases. Since CI tests are run frequently, the cost of each test has to be carefully considered (that’s why you carefully curate the dataset). Favor assertions or other deterministic checks over LLM-as-judge evaluators.
Тестовые наборы данных для CI невелики (во многих случаях 100+ примеров) и созданы целенаправленно. Примеры покрывают основные функции, регрессионные тесты для прошлых багов и известные пограничные случаи. Поскольку CI-тесты запускаются часто, стоимость каждого теста необходимо тщательно учитывать (поэтому набор данных нужно тщательно курировать). Предпочитайте утверждения (assertions) или другие детерминированные проверки вместо оценщиков LLM-as-Judge.
For evaluating production traffic, you can sample live traces and run evaluators against them asynchronously. Since you usually lack reference outputs on production data, you might rely more on on more expensive reference-free evaluators like LLM-as-judge. Additionally, track confidence intervals for production metrics. If the lower bound crosses your threshold, investigate further.
Для оценки продакшен-трафика можно делать выборку живых трейсов и запускать оценщики асинхронно. Поскольку для продакшен-данных обычно нет эталонных выходов, приходится больше полагаться на более дорогие безреференсные оценщики вроде LLM-as-Judge. Кроме того, отслеживайте доверительные интервалы для продакшен-метрик. Если нижняя граница пересекает ваш порог — расследуйте подробнее.
These two systems are complementary: when production monitoring reveals new failure patterns through error analysis and evals, add representative examples to your CI dataset. This mitigates regressions on new issues.
Эти две системы дополняют друг друга: когда мониторинг продакшена выявляет новые паттерны сбоев через анализ ошибок и оценки, добавляйте репрезентативные примеры в ваш CI-датасет. Это предотвращает регрессии по новым проблемам.
Q: What’s the difference between guardrails & evaluators?
В: В чём разница между защитными барьерами (guardrails) и оценщиками (evaluators)?
Guardrails are inline safety checks that sit directly in the request/response path. They validate inputs or outputs before anything reaches a user, so they typically are:
Защитные барьеры — это встроенные проверки безопасности, расположенные непосредственно на пути запроса/ответа. Они валидируют входы или выходы до того, как что-либо достигнет пользователя, поэтому обычно:
Быстрые и детерминированные — обычно в рамках нескольких миллисекунд задержки. Простые и объяснимые — регулярные выражения, списки блокировки по ключевым словам, валидаторы схем или типов, лёгкие классификаторы. Нацелены на очевидные, высокоимпактные сбои — утечки PII, ненормативная лексика, запрещённые инструкции, SQL-инъекции, невалидный JSON, неправильный синтаксис кода и т. д.
If a guardrail triggers, the system can redact, refuse, or regenerate the response. Because these checks are user-visible when they fire, false positives are treated as production bugs; teams version guardrail rules, log every trigger, and monitor rates to keep them conservative.
Если защитный барьер срабатывает, система может отредактировать, отклонить или перегенерировать ответ. Поскольку эти проверки видны пользователю при срабатывании, ложные срабатывания рассматриваются как баги продакшена; команды версионируют правила барьеров, логируют каждое срабатывание и мониторят частоту, чтобы держать их консервативными.
On the other hand, evaluators typically run after a response is produced. Evaluators measure qualities that simple rules cannot, such as factual correctness, completeness, etc. Their verdicts feed dashboards, regression tests, and model-improvement loops, but they do not block the original answer.
С другой стороны, оценщики обычно запускаются после генерации ответа. Оценщики измеряют качества, которые простые правила не могут охватить, такие как фактическая корректность, полнота и т. д. Их вердикты наполняют дашборды, регрессионные тесты и циклы улучшения модели, но не блокируют исходный ответ.
Evaluators are usually run asynchronously or in batch to afford heavier computation such as a LLM-as-a-Judge. Inline use of an LLM-as-Judge is possible only when the latency budget and reliability targets allow it. Slow LLM judges might be feasible in a cascade that runs on the minority of borderline cases.
Оценщики обычно запускаются асинхронно или в пакетном режиме, чтобы позволить более тяжёлые вычисления, такие как LLM-as-a-Judge. Встроенное использование LLM-as-a-Judge возможно только тогда, когда бюджет задержки и целевые показатели надёжности это позволяют. Медленные LLM-судьи могут быть оправданы в каскаде, который запускается на меньшинстве пограничных случаев.
Apply guardrails for immediate protection against objective failures requiring intervention. Use evaluators for monitoring and improving subjective or nuanced criteria. Together, they create layered protection.
Применяйте защитные барьеры для немедленной защиты от объективных сбоев, требующих вмешательства. Используйте оценщики для мониторинга и улучшения субъективных или нюансированных критериев. Вместе они создают многоуровневую защиту.
Word of caution: Do not use llm guardrails off the shelf blindly. Always look at the prompt.
Предостережение: не используйте LLM-барьеры из коробки вслепую. Всегда смотрите на промпт.
Q: Can my evaluators also be used to automatically fix or correct outputs in production?
В: Можно ли использовать оценщики для автоматического исправления или корректировки выходов в продакшене?
Yes, but only a specific subset of them. This is the distinction between an evaluator and a guardrail that we previously discussed. As a reminder:
Да, но только определённое подмножество из них. Это различие между оценщиком и защитным барьером, которое мы обсуждали ранее. Напомним:
Оценщики обычно запускаются асинхронно после генерации ответа. Они измеряют качество, но не влияют на непосредственный опыт пользователя. Защитные барьеры запускаются синхронно на критическом пути запроса, до того как выход показывается пользователю. Их задача — предотвращать серьёзные сбои в реальном времени.
There are two important decision criteria for deciding whether to use an evaluator as a guardrail:
Есть два важных критерия для решения о том, использовать ли оценщик как защитный барьер:
Latency & Cost: Can the evaluator run fast enough and cheaply enough in the critical request path without degrading user experience?
Error Rate Trade-offs: What’s the cost-benefit balance between false positives (blocking good outputs and frustrating users) versus false negatives (letting bad outputs reach users and causing harm)? In high-stakes domains like medical advice, false negatives may be more costly than false positives. In creative applications, false positives that block legitimate creativity may be more harmful than occasional quality issues.
Задержка и стоимость: может ли оценщик работать достаточно быстро и дёшево на критическом пути запроса без ухудшения пользовательского опыта? Баланс ошибок: каков баланс затрат и выгод между ложноположительными (блокировка хороших выходов и раздражение пользователей) и ложноотрицательными (пропуск плохих выходов и причинение вреда)? В высокорисковых доменах вроде медицинских рекомендаций ложноотрицательные могут быть дороже ложноположительных. В творческих приложениях ложноположительные, блокирующие легитимное творчество, могут быть вреднее, чем случайные проблемы с качеством.
Most guardrails are designed to be fast (to avoid harming user experience) and have a very low false positive rate (to avoid blocking valid responses). For this reason, you would almost never use a slow or non-deterministic LLM-as-Judge as a synchronous guardrail. However, these tradeoffs might be different for your use case.
Большинство защитных барьеров спроектированы так, чтобы быть быстрыми (чтобы не ухудшать пользовательский опыт) и иметь очень низкий процент ложных срабатываний (чтобы не блокировать валидные ответы). По этой причине вы почти никогда не будете использовать медленный или недетерминированный LLM-as-Judge в качестве синхронного защитного барьера. Однако эти компромиссы могут отличаться для вашего сценария использования.
Q: How much time should I spend on model selection?
В: Сколько времени уделять выбору модели?
Many developers fixate on model selection as the primary way to improve their LLM applications. Start with error analysis to understand your failure modes before considering model switching. As Hamel noted in office hours, “I suggest not thinking of switching model as the main axes of how to improve your system off the bat without evidence. Does error analysis suggest that your model is the problem?”
Многие разработчики зацикливаются на выборе модели как основном способе улучшения LLM-приложений. Начните с анализа ошибок, чтобы понять ваши режимы отказов, прежде чем рассматривать смену модели. Как отметил Hamel на консультации: «Я не рекомендую рассматривать смену модели как основной рычаг улучшения системы без доказательств. Анализ ошибок указывает на то, что проблема в модели?»
Domain-Specific Applications
Доменно-специфичные приложения
Q: Is RAG dead?
В: RAG мёртв?
Question: Should I avoid using RAG for my AI application after reading that “RAG is dead” for coding agents?
Вопрос: стоит ли отказаться от RAG для моего ИИ-приложения после прочтения статьи о том, что «RAG мёртв» для кодинг-агентов?
Many developers are confused about when and how to use RAG after reading articles claiming “RAG is dead.” Understanding what RAG actually means versus the narrow marketing definitions will help you make better architectural decisions for your AI applications.
Многие разработчики не знают, когда и как использовать RAG после прочтения статей, утверждающих «RAG мёртв». Понимание того, что на самом деле означает RAG, в отличие от узких маркетинговых определений, поможет вам принимать лучшие архитектурные решения для ваших ИИ-приложений.
The viral article claiming RAG is dead specifically argues against using naive vector database retrieval for autonomous coding agents, not RAG as a whole. This is a crucial distinction that many developers miss due to misleading marketing.
Вирусная статья, утверждающая, что RAG мёртв, конкретно аргументирует против использования наивного поиска по векторной базе данных для автономных кодинг-агентов, а не против RAG в целом. Это ключевое различие, которое многие разработчики упускают из-за вводящего в заблуждение маркетинга.
RAG simply means Retrieval-Augmented Generation - using retrieval to provide relevant context that improves your model’s output. The core principle remains essential: your LLM needs the right context to generate accurate answers. The question isn’t whether to use retrieval, but how to retrieve effectively.
RAG — это просто Retrieval-Augmented Generation (генерация, дополненная поиском) — использование поиска для предоставления релевантного контекста, улучшающего выход модели. Основной принцип остаётся незаменимым: вашему LLM нужен правильный контекст для генерации точных ответов. Вопрос не в том, использовать ли поиск, а в том, как искать эффективно.
For coding applications, naive vector similarity search often fails because code relationships are complex and contextual. Instead of abandoning retrieval entirely, modern coding assistants like Claude Code still uses retrieval —they just employ agentic search instead of relying solely on vector databases, similar to how human developers work.
Для кодинг-приложений наивный векторный поиск по сходству часто не работает, потому что связи в коде сложны и контекстуальны. Вместо полного отказа от поиска современные кодинг-ассистенты вроде Claude Code по-прежнему используют поиск — просто применяют агентный поиск вместо опоры исключительно на векторные базы данных, подобно тому как работают разработчики-люди.
You have multiple retrieval strategies available, ranging from simple keyword matching to embedding similarity to LLM-powered relevance filtering. The optimal approach depends on your specific use case, data characteristics, and performance requirements. Many production systems combine multiple strategies or use multi-hop retrieval guided by LLM agents.
В вашем распоряжении множество стратегий поиска — от простого поиска по ключевым словам до сходства эмбеддингов и фильтрации релевантности на базе LLM. Оптимальный подход зависит от конкретного сценария, характеристик данных и требований к производительности. Многие продакшен-системы комбинируют несколько стратегий или используют многоходовой поиск, управляемый LLM-агентами.
Unfortunately, “RAG” has become a buzzword with no shared definition. Some people use it to mean any retrieval system, others restrict it to vector databases. Focus on the ultimate goal: getting your LLM the context it needs to succeed. Whether that’s through vector search, agentic exploration, or hybrid approaches is a product and engineering decision.
К сожалению, «RAG» превратился в модное слово без общепринятого определения. Одни используют его для обозначения любой поисковой системы, другие ограничивают векторными базами данных. Сосредоточьтесь на конечной цели: дать вашему LLM контекст, необходимый для успеха. Будет ли это векторный поиск, агентное исследование или гибридный подход — это продуктовое и инженерное решение.
Rather than following categorical advice to avoid or embrace RAG, experiment with different retrieval approaches and measure what works best for your application. For more info on RAG evaluation and optimization, see this series of posts.
Вместо того чтобы следовать категоричным советам избегать или применять RAG, экспериментируйте с различными подходами к поиску и измеряйте, что лучше работает для вашего приложения. Подробнее об оценке и оптимизации RAG см. в этой серии постов.
Q: How should I approach evaluating my RAG system?
В: Как подходить к оценке моей RAG-системы?
RAG systems have two distinct components that require different evaluation approaches: retrieval and generation.
RAG-системы имеют два отдельных компонента, требующих разных подходов к оценке: поиск и генерация.
The retrieval component is a search problem. Evaluate it using traditional information retrieval (IR) metrics. Common examples include Recall@k (of all relevant documents, how many did you retrieve in the top k?), Precision@k (of the k documents retrieved, how many were relevant?), or MRR (how high up was the first relevant document?). The specific metrics you choose depend on your use case. These metrics are pure search metrics that measure whether you’re finding the right documents (more on this below).
Компонент поиска — это задача поиска. Оценивайте его с помощью традиционных метрик информационного поиска (IR). Распространённые примеры: Recall@k (из всех релевантных документов — сколько попало в топ-k?), Precision@k (из k извлечённых документов — сколько релевантных?) или MRR (насколько высоко оказался первый релевантный документ?). Конкретные метрики зависят от вашего сценария. Это чистые поисковые метрики, измеряющие, находите ли вы нужные документы (подробнее ниже).
To evaluate retrieval, create a dataset of queries paired with their relevant documents. Generate this synthetically by taking documents from your corpus, extracting key facts, then generating questions those facts would answer. This reverse process gives you query-document pairs for measuring retrieval performance without manual annotation.
Для оценки поиска создайте датасет запросов, сопоставленных с релевантными документами. Сгенерируйте его синтетически: возьмите документы из вашего корпуса, извлеките ключевые факты, затем сгенерируйте вопросы, на которые эти факты дают ответ. Этот обратный процесс даёт вам пары «запрос–документ» для измерения качества поиска без ручной разметки.
For the generation component—how well the LLM uses retrieved context, whether it hallucinates, whether it answers the question—use the same evaluation procedures covered throughout this course: error analysis to identify failure modes, collecting human labels, building LLM-as-judge evaluators, and validating those judges against human annotations.
Для компонента генерации — насколько хорошо LLM использует полученный контекст, галлюцинирует ли он, отвечает ли на вопрос — применяйте те же процедуры оценки, описанные в этом курсе: анализ ошибок для выявления режимов отказов, сбор человеческих меток, создание оценщиков LLM-as-Judge и валидация этих судей относительно человеческих аннотаций.
Jason Liu’s “There Are Only 6 RAG Evals” provides a framework that maps well to this separation. His Tier 1 covers traditional IR metrics for retrieval. Tiers 2 and 3 evaluate relationships between Question, Context, and Answer—like whether the context is relevant (C|Q), whether the answer is faithful to context (A|C), and whether the answer addresses the question (A|Q).
Статья Jason Liu «Существует только 6 RAG-оценок» предлагает фреймворк, хорошо соответствующий этому разделению. Его уровень 1 покрывает традиционные IR-метрики для поиска. Уровни 2 и 3 оценивают взаимосвязи между вопросом, контекстом и ответом — например, релевантен ли контекст (C|Q), верен ли ответ контексту (A|C) и отвечает ли ответ на вопрос (A|Q).
In addition to Jason’s six evals, error analysis on your specific data may reveal domain-specific failure modes that warrant their own metrics. For example, a medical RAG system might consistently fail to distinguish between drug dosages for adults versus children, or a legal RAG might confuse jurisdictional boundaries. These patterns emerge only through systematic review of actual failures. Once identified, you can create targeted evaluators for these specific issues beyond the general framework.
В дополнение к шести оценкам Jason, анализ ошибок на ваших конкретных данных может выявить доменно-специфичные режимы отказов, заслуживающие собственных метрик. Например, медицинская RAG-система может систематически путать дозировки лекарств для взрослых и детей, а юридическая RAG — путать границы юрисдикций. Эти паттерны проявляются только при систематическом анализе реальных сбоев. Выявив их, вы можете создать целевые оценщики для этих конкретных проблем, выходящие за рамки общего фреймворка.
Finally, when implementing Jason’s Tier 2 and 3 metrics, don’t just use prompts off the shelf. The standard LLM-as-judge process requires several steps: error analysis, prompt iteration, creating labeled examples, and measuring your judge’s accuracy against human labels. Once you know your judge’s True Positive and True Negative rates, you can correct its estimates to determine the actual failure rate in your system. Skip this validation and your judges may not reflect your actual quality criteria.
Наконец, при реализации метрик уровней 2 и 3 Jason не используйте промпты из коробки. Стандартный процесс LLM-as-Judge требует нескольких шагов: анализ ошибок, итерация промптов, создание размеченных примеров и измерение точности вашего судьи относительно человеческих меток. Когда вы знаете показатели True Positive и True Negative вашего судьи, вы можете скорректировать его оценки для определения реальной частоты сбоев в вашей системе. Пропустите эту валидацию — и ваши судьи могут не отражать ваши реальные критерии качества.
In summary, debug retrieval first using IR metrics, then tackle generation quality using properly validated LLM judges.
Резюме: сначала отлаживайте поиск с помощью IR-метрик, затем работайте над качеством генерации с помощью должным образом валидированных LLM-судей.
Q: How do I choose the right chunk size for my document processing tasks?
В: Как выбрать правильный размер чанка для задач обработки документов?
Unlike RAG, where chunks are optimized for retrieval, document processing assumes the model will see every chunk. The goal is to split text so the model can reason effectively without being overwhelmed. Even if a document fits within the context window, it might be better to break it up. Long inputs can degrade performance due to attention bottlenecks, especially in the middle of the context. Two task types require different strategies:
В отличие от RAG, где чанки оптимизируются для поиска, обработка документов предполагает, что модель увидит каждый чанк. Цель — разделить текст так, чтобы модель могла эффективно рассуждать, не перегружаясь. Даже если документ помещается в контекстное окно, может быть лучше его разбить. Длинные входы могут ухудшить производительность из-за узких мест внимания, особенно в середине контекста. Два типа задач требуют разных стратегий:
1. Fixed-Output Tasks → Large Chunks
1. Задачи с фиксированным выходом → Крупные чанки
These are tasks where the output length doesn’t grow with input: extracting a number, answering a specific question, classifying a section. For example:
Это задачи, где длина выхода не растёт с объёмом входа: извлечение числа, ответ на конкретный вопрос, классификация раздела. Например:
«Какой штрафной пункт в этом контракте?» «Какой была зарплата CEO в 2023 году?»
Use the largest chunk (with caveats) that likely contains the answer. This reduces the number of queries and avoids context fragmentation. However, avoid adding irrelevant text. Models are sensitive to distraction, especially with large inputs. The middle parts of a long input might be under-attended. Furthermore, if cost and latency are a bottleneck, you should consider preprocessing or filtering the document (via keyword search or a lightweight retriever) to isolate relevant sections before feeding a huge chunk.
Используйте максимально большой чанк (с оговорками), который с наибольшей вероятностью содержит ответ. Это сокращает число запросов и предотвращает фрагментацию контекста. Однако избегайте добавления нерелевантного текста. Модели чувствительны к отвлекающим факторам, особенно при больших входах. Средние части длинного входа могут получать недостаточно внимания. Кроме того, если стоимость и задержка являются узким местом, стоит рассмотреть предварительную обработку или фильтрацию документа (через поиск по ключевым словам или лёгкий ретривер) для выделения релевантных разделов перед подачей огромного чанка.
2. Expansive-Output Tasks → Smaller Chunks
2. Задачи с расширяемым выходом → Мелкие чанки
These include summarization, exhaustive extraction, or any task where output grows with input. For example:
Сюда входят суммаризация, исчерпывающее извлечение и любые задачи, где выход растёт с объёмом входа. Например:
«Суммаризируйте каждый раздел» «Перечислите все жалобы клиентов»
In these cases, smaller chunks help preserve reasoning quality and output completeness. The standard approach is to process each chunk independently, then aggregate results (e.g., map-reduce). When sizing your chunks, try to respect content boundaries like paragraphs, sections, or chapters. Chunking also helps mitigate output limits. By breaking the task into pieces, each piece’s output can stay within limits.
В этих случаях мелкие чанки помогают сохранить качество рассуждений и полноту выхода. Стандартный подход — обрабатывать каждый чанк независимо, а затем агрегировать результаты (например, map-reduce). При определении размера чанков старайтесь соблюдать границы содержимого — абзацы, разделы или главы. Чанкинг также помогает обойти ограничения на длину выхода. Разбивая задачу на части, выход каждой части может оставаться в пределах лимитов.
General Guidance
Общие рекомендации
It’s important to recognize why chunk size affects results. A larger chunk means the model has to reason over more information in one go – essentially, a heavier cognitive load. LLMs have limited capacity to retain and correlate details across a long text. If too much is packed in, the model might prioritize certain parts (commonly the beginning or end) and overlook or “forget” details in the middle. This can lead to overly coarse summaries or missed facts. In contrast, a smaller chunk bounds the problem: the model can pay full attention to that section. You are trading off global context for local focus.
Важно понимать, почему размер чанка влияет на результаты. Больший чанк означает, что модель должна рассуждать над бо́льшим объёмом информации за раз — по сути, бо́льшая когнитивная нагрузка. У LLM ограничена способность удерживать и сопоставлять детали в длинном тексте. Если упаковать слишком много, модель может отдать приоритет определённым частям (обычно началу или концу) и упустить или «забыть» детали в середине. Это может привести к слишком обобщённым резюме или пропущенным фактам. Напротив, мелкий чанк ограничивает задачу: модель может уделить полное внимание этому фрагменту. Вы обмениваете глобальный контекст на локальный фокус.
No rule of thumb can perfectly determine the best chunk size for your use case – you should validate with experiments. The optimal chunk size can vary by domain and model. I treat chunk size as a hyperparameter to tune.
Никакое эмпирическое правило не может идеально определить лучший размер чанка для вашего сценария — нужно проверять экспериментами. Оптимальный размер чанка может варьироваться в зависимости от домена и модели. Я рассматриваю размер чанка как гиперпараметр для настройки.
Q: How do I debug multi-turn conversation traces?
В: Как отлаживать многоходовые разговорные трейсы?
Start simple. Check if the whole conversation met the user’s goal with a pass/fail judgment. Look at the entire trace and focus on the first upstream failure. Read the user-visible parts first to understand if something went wrong. Only then dig into the technical details like tool calls and intermediate steps.
Начните просто. Проверьте, достигнут ли в ходе разговора цель пользователя, — бинарным суждением «пройдено/не пройдено». Просмотрите весь трейс и сосредоточьтесь на первом сбое в цепочке. Сначала прочитайте части, видимые пользователю, чтобы понять, пошло ли что-то не так. И только потом углубляйтесь в технические детали — вызовы инструментов и промежуточные шаги.
Multi-agent trace logging
Логирование трейсов для мультиагентных систем
For multi-agent flows, assign a session or trace ID to each user request and log every message with its source (which agent or tool), trace ID, and position in the sequence. This lets you reconstruct the full path from initial query to final result across all agents.
Для мультиагентных потоков присвойте каждому запросу пользователя идентификатор сессии или трейса и логируйте каждое сообщение с указанием его источника (какой агент или инструмент), ID трейса и позиции в последовательности. Это позволит восстановить полный путь от начального запроса до финального результата через все агенты.
Annotation strategy
Стратегия аннотирования
Annotate only the first failure in the trace initially—don’t worry about downstream failures since these often cascade from the first issue. Fixing upstream failures often resolves dependent downstream failures automatically. As you gain experience, you can annotate independent failure modes within the same trace to speed up overall error analysis.
Аннотируйте только первый сбой в трейсе на начальном этапе — не беспокойтесь о последующих сбоях, так как они часто каскадно следуют из первого. Исправление ранних сбоев часто автоматически устраняет зависимые последующие. Набравшись опыта, вы сможете аннотировать независимые режимы отказов в одном трейсе для ускорения общего анализа ошибок.
Simplify when possible
Упрощайте при возможности
When you find a failure, reproduce it with the simplest possible test case. Here’s an example: suppose a shopping bot gives the wrong return policy on turn 4 of a conversation. Before diving into the full multi-turn complexity, simplify it to a single turn: “What is the return window for product X1000?” If it still fails, you’ve proven the error isn’t about conversation context - it’s likely a basic retrieval or knowledge issue you can debug more easily.
Обнаружив сбой, воспроизведите его с максимально простым тестовым случаем. Пример: предположим, бот для покупок выдаёт неправильную политику возврата на 4-м ходе разговора. Прежде чем погружаться в многоходовую сложность, упростите до одного хода: «Каков срок возврата для товара X1000?» Если он всё ещё ошибается, вы доказали, что ошибка не связана с контекстом разговора — скорее всего, это базовая проблема поиска или знаний, которую можно отладить проще.
Test case generation
Генерация тестовых случаев
You have two main approaches. First, simulate users with another LLM to create realistic multi-turn conversations. Second, use “N-1 testing” where you provide the first N-1 turns of a real conversation and test what happens next. The N-1 approach often works better since it uses actual conversation prefixes rather than fully synthetic interactions, but is less flexible.
Есть два основных подхода. Первый — имитировать пользователей с помощью другого LLM для создания реалистичных многоходовых разговоров. Второй — использовать «N-1 тестирование»: предоставить первые N-1 ходов реального разговора и протестировать, что происходит дальше. Подход N-1 часто работает лучше, так как использует реальные префиксы разговоров, а не полностью синтетические взаимодействия, но менее гибок.
The key is balancing thoroughness with efficiency. Not every multi-turn failure requires multi-turn analysis.
Ключ — баланс между тщательностью и эффективностью. Не каждый многоходовой сбой требует многоходового анализа.
Q: How do I evaluate sessions with human handoffs?
В: Как оценивать сессии с передачей человеку?
Capture the complete user journey in your traces, including human handoffs. The trace continues until the user’s need is resolved or the session ends, not when AI hands off to a human. Log the handoff decision, why it occurred, context transferred, wait time, human actions, final resolution, and whether the human had sufficient context. Many failures occur at handoff boundaries where AI hands off too early, too late, or without proper context.
Фиксируйте полный путь пользователя в ваших трейсах, включая передачи человеку. Трейс продолжается до тех пор, пока потребность пользователя не будет удовлетворена или сессия не завершится — а не когда ИИ передаёт дело человеку. Логируйте решение о передаче, его причину, переданный контекст, время ожидания, действия человека, итоговое решение и то, получил ли человек достаточный контекст. Многие сбои происходят на границах передачи, когда ИИ передаёт слишком рано, слишком поздно или без должного контекста.
Evaluate handoffs as potential failure modes during error analysis. Ask: Was the handoff necessary? Did the AI provide adequate context? Track both handoff quality and handoff rate. Sometimes the best improvement reduces handoffs entirely rather than improving handoff execution.
Оценивайте передачи как потенциальные режимы отказов в ходе анализа ошибок. Спросите: была ли передача необходима? Предоставил ли ИИ достаточный контекст? Отслеживайте и качество передачи, и её частоту. Иногда лучшее улучшение — полностью сократить число передач, а не улучшить их выполнение.
Q: How do I evaluate complex multi-step workflows?
В: Как оценивать сложные многошаговые рабочие процессы?
Log the entire workflow from initial trigger to final business outcome. Include LLM calls, tool usage, human approvals, and database writes in your traces. You will need this visibility to properly diagnose failures.
Логируйте весь рабочий процесс от начального триггера до конечного бизнес-результата. Включайте вызовы LLM, использование инструментов, одобрения людей и записи в базу данных в ваши трейсы. Вам понадобится эта видимость для правильной диагностики сбоев.
Use both outcome and process metrics. Outcome metrics verify the final result meets requirements: Was the business case complete? Accurate? Properly formatted? Process metrics evaluate efficiency: step count, time taken, resource usage. Process failures are often easier to debug since they’re more deterministic, so tackle them first.
Используйте как метрики результата, так и метрики процесса. Метрики результата проверяют, соответствует ли финальный результат требованиям: полон ли бизнес-кейс? Точен? Правильно отформатирован? Метрики процесса оценивают эффективность: количество шагов, затраченное время, использование ресурсов. Процессные сбои часто легче отлаживать, так как они более детерминированы, поэтому начинайте с них.
Segment your error analysis by workflow stages. Early stage failures (understanding user input) differ from middle stage failures (data processing) and late stage failures (formatting output). Early stage improvements have more impact since errors cascade in LLM chains.
Сегментируйте анализ ошибок по этапам рабочего процесса. Ранние сбои (понимание ввода пользователя) отличаются от сбоев на среднем этапе (обработка данных) и поздних (форматирование выхода). Улучшения на ранних этапах имеют большее влияние, так как ошибки каскадируются в LLM-цепочках.
Use transition failure matrices to analyze where workflows break. Create a matrix showing the last successful state versus where the first failure occurred. This reveals failure hotspots and guides where to invest debugging effort.
Используйте матрицы переходных отказов для анализа мест, где рабочие процессы ломаются. Создайте матрицу, показывающую последнее успешное состояние в сравнении с местом первого сбоя. Это выявляет горячие точки сбоев и подсказывает, куда направить усилия по отладке.
Q: How do I evaluate agentic workflows?
В: Как оценивать агентные рабочие процессы?
We recommend evaluating agentic workflows in two phases:
Мы рекомендуем оценивать агентные рабочие процессы в два этапа:
1. End-to-end task success. Treat the agent as a black box and ask “did we meet the user’s goal?”. Define a precise success rule per task (exact answer, correct side-effect, etc.) and measure with human or aligned LLM judges. Take note of the first upstream failure when conducting error analysis.
1. Сквозной успех задачи. Рассматривайте агента как чёрный ящик и спросите: «достигли ли мы цели пользователя?». Определите точное правило успеха для каждой задачи (точный ответ, правильный побочный эффект и т. д.) и измеряйте с помощью человеческих или настроенных LLM-судей. Отмечайте первый сбой в цепочке при проведении анализа ошибок.
Once error analysis reveals which workflows fail most often, move to step-level diagnostics to understand why they’re failing.
Когда анализ ошибок покажет, какие рабочие процессы отказывают чаще всего, переходите к диагностике на уровне шагов, чтобы понять причины.
2. Step-level diagnostics. Assuming that you have sufficiently instrumented your system with details of tool calls and responses, you can score individual components such as: - Tool choice: was the selected tool appropriate? - Parameter extraction: were inputs complete and well-formed? - Error handling: did the agent recover from empty results or API failures? - Context retention: did it preserve earlier constraints? - Efficiency: how many steps, seconds, and tokens were spent? - Goal checkpoints: for long workflows verify key milestones.
2. Диагностика на уровне шагов. При условии, что вы достаточно инструментировали свою систему с деталями вызовов инструментов и ответов, вы можете оценивать отдельные компоненты: - Выбор инструмента: был ли выбранный инструмент подходящим? - Извлечение параметров: были ли входные данные полными и корректно оформленными? - Обработка ошибок: восстановился ли агент после пустых результатов или сбоев API? - Сохранение контекста: сохранил ли он ранее заданные ограничения? - Эффективность: сколько шагов, секунд и токенов было потрачено? - Контрольные точки цели: для длинных рабочих процессов проверяйте ключевые промежуточные результаты.
Example: “Find Berkeley homes under $1M and schedule viewings” breaks into: parameters extracted correctly, relevant listings retrieved, availability checked, and calendar invites sent. Each checkpoint can pass or fail independently, making debugging tractable.
Пример: «Найти дома в Беркли до $1M и записаться на просмотры» разбивается на: параметры извлечены корректно, релевантные объекты найдены, доступность проверена, приглашения в календарь отправлены. Каждую контрольную точку можно проверить независимо, что делает отладку управляемой.
Use transition failure matrices to understand error patterns. Create a matrix where rows represent the last successful state and columns represent where the first failure occurred. This is a great way to understand where the most failures occur.
Используйте матрицы переходных отказов для понимания паттернов ошибок. Создайте матрицу, где строки представляют последнее успешное состояние, а столбцы — место первого сбоя. Это отличный способ понять, где происходит больше всего отказов.
Transition matrices transform overwhelming agent complexity into actionable insights. Instead of drowning in individual trace reviews, you can immediately see that GenSQL → ExecSQL transitions cause 12 failures while DecideTool → PlanCal causes only 2. This data-driven approach guides where to invest debugging effort. Here is another example from Bryan Bischof, that is also a text-to-SQL agent:
Матрицы переходов превращают неуправляемую сложность агента в практические инсайты. Вместо того чтобы тонуть в просмотре отдельных трейсов, вы сразу видите, что переходы GenSQL → ExecSQL вызывают 12 сбоев, тогда как DecideTool → PlanCal — только 2. Этот подход, основанный на данных, определяет, куда направить усилия по отладке. Вот ещё один пример от Bryan Bischof — тоже для text-to-SQL агента:
In this example, Bryan shows variation in transition matrices across experiments. How you organize your transition matrix depends on the specifics of your application. For example, Bryan’s text-to-SQL agent has an inherent sequential workflow which he exploits for further analytical insight. You can watch his full talk for more details.
В этом примере Bryan показывает вариации матриц переходов по экспериментам. Организация матрицы переходов зависит от специфики вашего приложения. Например, text-to-SQL агент Bryan имеет присущий последовательный рабочий процесс, который он использует для дополнительного аналитического понимания. Полный доклад можно посмотреть для подробностей.
Creating Test Cases for Agent Failures
Создание тестовых случаев для сбоев агентов
Creating test cases for agent failures follows the same principles as our previous FAQ on debugging multi-turn conversation traces (i.e. try to reproduce the error in the simplest way possible, only use multi-turn tests when the failure actually requires conversation context, etc.).
Создание тестовых случаев для сбоев агентов следует тем же принципам, что и наш предыдущий FAQ по отладке многоходовых разговорных трейсов (то есть попытайтесь воспроизвести ошибку максимально простым способом, используйте многоходовые тесты только тогда, когда сбой действительно требует контекста разговора, и т. д.).
👉 Want to learn more about AI Evals? Check out our AI Evals course. It’s a live cohort with hands on exercises and office hours. Here is a 25% discount code for readers. 👈
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Footnotes
Примечания
Eleanor Berger, our wonderful TA.↩︎
Paul Graham, “Writes and Write-Nots”↩︎
Shreya Shankar, et al., “Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences”↩︎
Eleanor Berger, наш замечательный TA.↩︎ Paul Graham, «Writes and Write-Nots»↩︎ Shreya Shankar и др., «Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences»↩︎