Q: Why is “error analysis” so important in LLM evals, and how is it performed? – Hamel’s Blog - Hamel Husain
Hamel Husain объясняет, почему «анализ ошибок» (error analysis) — самая важная деятельность в оценке LLM: именно он подсказывает, какие eval-метрики вообще писать, и помогает выявить характерные для вашего приложения и данных режимы сбоев. Процесс состоит из четырёх шагов: сбор датасета репрезентативных трейсов (при отсутствии данных — генерация синтетических), открытое кодирование (доменный эксперт-«благожелательный диктатор» делает заметки о трейсах, фиксируя прежде всего первый сбой), осевое кодирование (группировка заметок в «таксономию сбоев» с подсчётом частот) и итеративное уточнение до «теоретического насыщения». Как эмпирическое правило, стоит просмотреть минимум 100 трейсов и останавливаться, если ~20 трейсов не дают новой категории. Цель — приоритизировать наиболее частые сбои, а не ловить все возможные, поскольку eval'ы не бесплатны. Автор приводит визуализацию процесса от своего студента Pawel Huryn и ссылки на видео и блог-пост с примерами.
Анализ ошибок — самая важная деятельность в evals. Анализ ошибок помогает вам решить, какие eval'ы вообще стоит писать. Он позволяет выявить режимы сбоев, уникальные для вашего приложения и ваших данных. Процесс включает:
1. Создание датасета
Сбор репрезентативных трейсов взаимодействий пользователей с LLM. Если у вас совсем нет данных, можно сгенерировать синтетические данные, чтобы начать.
2. Открытое кодирование (Open Coding)
Аннотатор(ы)-человек (в идеале — благожелательный диктатор) просматривают трейсы и пишут свободные заметки о них, отмечая любые проблемы. Этот процесс сродни «ведению дневника» и заимствован из методологий качественных исследований. На старте рекомендуется сосредоточиться на фиксации первого сбоя, наблюдаемого в трейсе, поскольку ошибки выше по цепочке могут вызывать проблемы ниже по цепочке, — хотя, если это выполнимо, вы можете помечать и все независимые сбои. Этот шаг должен выполнять доменный эксперт.
3. Осевое кодирование (Axial Coding)
Сгруппируйте свободные заметки в «таксономию сбоев». Иными словами, объедините схожие сбои в отдельные категории. Это самый важный шаг. В конце подсчитайте число сбоев в каждой категории. Для этого шага можно привлечь LLM.
4. Итеративное уточнение
Продолжайте итерировать по новым трейсам, пока не достигнете теоретического насыщения — то есть пока новые трейсы перестанут открывать вам новые режимы сбоев или новую информацию. Как ориентир, стоит просмотреть как минимум 100 трейсов. Моя грубая эвристика: если ~20 трейсов не дают новой категории, можно остановиться (но для начала просмотрите хотя бы 100). Помните, что цель — приоритизировать те сбои, которые реально случаются чаще всего, а не выловить каждый возможный сбой (eval'ы не бесплатны, поэтому нужно быть прагматичными).
К этому процессу стоит часто возвращаться. Существуют продвинутые способы эффективнее отбирать данные — например, кластеризация, сортировка по обратной связи пользователей и сортировка по паттернам сбоев с высокой вероятностью. Со временем у вас выработается «нюх» на то, где искать сбои в ваших данных.
Не пропускайте анализ ошибок. Он гарантирует, что разрабатываемые вами метрики оценки опираются на реальное поведение приложения, а не на контрпродуктивные обобщённые метрики (которые большинство платформ подталкивают вас использовать). Примеры того, чем полезен анализ ошибок, см. в этом видео или в этом блог-посте.
Вот визуализация процесса анализа ошибок от одного из наших студентов, Pawel Huryn, — в том числе того, как он встраивается в общий процесс оценки:
Эта статья — часть нашего AI Evals FAQ, сборника частых вопросов (и ответов) об оценке LLM. Посмотреть все FAQ или вернуться на главную.