Q: Why is “error analysis” so important in LLM evals, and how is it performed? – Hamel’s Blog - Hamel Husain

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:

Анализ ошибок — самая важная деятельность в evals. Анализ ошибок помогает вам решить, какие 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. Открытое кодирование (Open Coding)

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. Осевое кодирование (Axial Coding)

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, — в том числе того, как он встраивается в общий процесс оценки:

↩︎ Back to main FAQ

↩︎ Назад к основному FAQ

This article is part of our AI Evals FAQ, a collection of common questions (and answers) about LLM evaluation. View all FAQs or return to the homepage.

Эта статья — часть нашего AI Evals FAQ, сборника частых вопросов (и ответов) об оценке LLM. Посмотреть все FAQ или вернуться на главную.