LLM Evals: Everything You Need to Know – Hamel’s Blog - Hamel Husain
Hamel Husain и Shreya Shankar собрали FAQ по оценке (evals) LLM-приложений на основе вопросов от 700+ инженеров и продакт-менеджеров. Центральная идея — анализ ошибок (error analysis) важнее любой инфраструктуры: нужно вручную просматривать 100+ трейсов, выявлять паттерны сбоев и лишь затем строить автоматические оценщики. Авторы рекомендуют бинарные (pass/fail) оценки вместо шкал Ликерта, назначение «доброжелательного диктатора» — единственного доменного эксперта — для аннотации, а также создание кастомных инструментов разметки вместо готовых решений. Отдельные разделы посвящены генерации синтетических данных через комбинации измерений, оценке RAG-систем (метрики извлечения отдельно от генерации), отладке многошаговых и агентных воркфлоу с помощью матриц переходных ошибок. В проектах авторов 60–80% времени разработки уходит на анализ ошибок и оценку, а не на построение автоматических проверок.
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 Системы оценки открывают суперспособности Бесплатный файн-тюнинг Синтез и курирование данных Отладка
Contents:
Содержание:
Проблема: ИИ-команды тонут в данных Шаг 1: Найдите главного доменного эксперта Шаг 2: Создайте датасет Шаг 3: Направьте доменного эксперта на вынесение суждений «Пройдено/Не пройдено» с критикой Шаг 4: Исправьте ошибки Шаг 5: Постройте LLM-as-a-Judge итеративно Шаг 6: Проведите анализ ошибок Шаг 7: Создайте более специализированных LLM-судей (при необходимости) Итоги Critique Shadowing Ресурсы
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.
Решение о создании автоматических оценщиков сводится к анализу затрат и выгод. Если ошибку можно поймать простым утверждением или регулярным выражением, затраты минимальны и, скорее всего, оправданы. Но если нужно калибровать оценщик 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.
Остерегайтесь оптимизации ради высоких показателей прохождения eval'ов. Если вы проходите 100% eval'ов, скорее всего, вы недостаточно нагружаете свою систему. Показатель прохождения в 70% может свидетельствовать о более содержательной оценке, реально стресс-тестирующей ваше приложение. Сосредоточьтесь на eval'ах, помогающих ловить реальные проблемы, а не на тех, которые улучшают метрики.
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.
Не пытайтесь продать команде идею «eval'ов». Вместо этого покажите им то, что вы находите, когда смотрите на данные.
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:
Анализ ошибок — самая важная деятельность в оценке. Анализ ошибок помогает решить, какие eval'ы писать в первую очередь. Он позволяет выявить режимы сбоев, уникальные для вашего приложения и данных. Процесс включает:
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). Помните: цель — приоритизировать сбои, которые действительно происходят чаще всего, а не ловить каждый возможный (eval'ы не бесплатны, поэтому нужен прагматизм).
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
Используйте eval'ы для первичного скрининга
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.
Используйте существующие eval'ы для поиска проблемных трейсов и потенциальных проблем. Обнаружив их, можно переходить к стандартному процессу оценки, начиная с анализа ошибок.
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 "дай мне тестовые запросы" без структуры, получая обобщённые, повторяющиеся результаты. Структурированный подход с использованием измерений даёт гораздо более качественные синтетические данные для тестирования 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.
Самое важное — всегда проводите анализ затрат и выгод перед реализацией eval'а. Спросите себя, оправдывает ли данный режим сбоя инвестиции. Анализ ошибок показывает, какие сбои действительно важны для ваших пользователей.
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.
Учитывайте иерархию стоимости различных типов оценщиков. Простые ассёрты и проверки по эталону (сравнение с известными правильными ответами) дёшевы в создании и сопровождении. Оценщики 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
«Всё, что вы получаете от использования этих готовых eval'ов — вы не понимаете, что они на самом деле делают, и в лучшем случае они тратят ваше время, а в худшем — создают иллюзию уверенности, которая ничем не обоснована.»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.
Обобщённые метрики оценки повсюду. Библиотеки eval'ов содержат такие оценки, как полезность, связность, качество и т.д., обещая лёгкую оценку. Эти метрики измеряют абстрактные качества, которые могут не иметь значения для вашего сценария. Хорошие оценки по ним не означают, что ваша система работает.
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 в большинстве ИИ-приложений. Вместо них мы рекомендуем использовать анализ ошибок для выявления метрик, специфичных для поведения вашего приложения. Мы рекомендуем проектировать бинарные pass/fail eval'ы (с использованием LLM-as-judge) или кодовые ассёрты.
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.”
«Злоупотребление обобщёнными метриками носит эндемический характер. Многие поставщики eval'ов продвигают готовые метрики, втягивая инженеров в лишнюю работу.»
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.
Сосредоточьтесь на достижении высокого True Positive Rate (TPR) и True Negative Rate (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:
Хотя аутсорсинг основного процесса анализа ошибок не рекомендуется, есть сценарии, в которых внешняя помощь уместна:
Чисто механические задачи: для высокообъективных, однозначных задач — таких как определение номера телефона или валидация email-адреса — внешних аннотаторов можно привлечь после того, как рубрика определена в ходе строгого внутреннего процесса. Задачи без продуктового контекста: чётко определённые задачи, не требующие понимания специфических требований вашего продукта, можно аутсорсить. Перевод — хороший пример: он требует лингвистической экспертизы, но не глубокого знания продукта. Привлечение внешних экспертов: найм внешних предметных экспертов для роли ваших внутренних доменных экспертов — это не аутсорсинг, а привлечение необходимой компетенции в ваш процесс оценки. Например, AnkiHub нанял студентов-медиков 4-го курса для оценки своих RAG-систем по медицинскому контенту вместо привлечения неспециализированных аннотаторов.
Q: What parts of evals can be automated with LLMs?
В: Какие части eval'ов можно автоматизировать с помощью 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 предложить, какие категории применимы к каждому новому трейсу (например, «Учитывая эту аннотацию: [open_annotation] и эти режимы сбоев: [list_of_failure_modes], какие подходят?»). Предложение улучшений промптов: когда вы замечаете повторяющиеся проблемы, попросите 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 для улучшения промптов на основе открытого кодирования (свободных заметок о трейсах). Таким образом вы сохраняете человека в контуре, который смотрит на данные и формализует свои требования. Когда у вас есть качественный набор eval'ов, оптимизация промптов может быть эффективна для финальной доводки.
👉 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 или автоматическими оценщиками. Предоставьте кнопки для действий — добавления в датасеты, создания багов или перезапуска тестов пайплайна. Отображайте релевантный контекст (версию пайплайна, оценки eval'ов, информацию о ревьюере) прямо в интерфейсе, чтобы минимизировать переключение контекста. Ниже — иллюстрация этих идей:
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 Desktop делают его вполне доступным. Когда я работал в 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-тесты запускаются часто, стоимость каждого теста нужно тщательно контролировать (поэтому вы тщательно курируете датасет). Отдавайте предпочтение ассёртам или другим детерминированным проверкам перед оценщиками 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.
Эти две системы дополняют друг друга: когда мониторинг продакшена выявляет новые паттерны сбоев через анализ ошибок и eval'ы, добавляйте репрезентативные примеры в CI-датасет. Это предотвращает регрессии по новым проблемам.
Q: What’s the difference between 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:
Гардрейлы — это встроенные проверки безопасности, находящиеся непосредственно на пути запроса/ответа. Они валидируют входы или выходы до того, как что-либо достигнет пользователя, поэтому обычно они:
Быстрые и детерминированные — обычно несколько миллисекунд бюджета на задержку. Простые и объяснимые — регулярные выражения, списки блокировки ключевых слов, валидаторы схем или типов, лёгкие классификаторы. Нацеленные на очевидные, высокоимпактные сбои — утечки персональных данных, нецензурная лексика, запрещённые инструкции, 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-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 «There Are Only 6 RAG Evals» предлагает фреймворк, хорошо соотносящийся с этим разделением. Его Уровень 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.
В дополнение к шести eval'ам 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 Rate и True Negative Rate вашего судьи, вы можете скорректировать его оценки для определения реальной частоты сбоев в системе. Пропустите эту валидацию — и ваши судьи могут не отражать реальные критерии качества.
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 сессии или трейса каждому запросу пользователя и логируйте каждое сообщение с указанием источника (какой агент или инструмент), 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, наш замечательный ассистент преподавателя.↩︎ Paul Graham, «Writes and Write-Nots»↩︎ Shreya Shankar и др., «Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences»↩︎