Evals: Doing Error Analysis Before Writing Tests – Hamel’s Blog - Hamel Husain
Хамел Хусейн разбирает на 20-минутной консультации по LLM-evals случай Али, который оценивает SMS-приложение для неоплачиваемых сиделок, ухаживающих за пожилыми родителями или детьми с инвалидностью. Архитектура Али включает Twilio, FastAPI, Chroma, Mem0, Azure OpenAI и Helicone, но он не знал, с какой части начать оценку, и склонялся к юнит-тестам и готовым метрикам Azure AI Foundry вроде coherence, fluency и relevance. Главный совет: не начинать с метрик и тестов, а проводить анализ ошибок на реальных диалогах с помощью простой таблицы, выявляя закономерности. Готовые метрики критикуются — изменение оценки с 3.72 до 4.2 ничего не говорит о реальном улучшении системы. После понимания реальных режимов отказа можно добавлять синтетические данные, но начинать с малого — 1-2 кейса на проблему. Ключевая мысль: изучение данных кажется рутиной, но это «самое высокорычажное, что можно сделать».
Это заметки с моих открытых консультаций по LLM Evals, где я разбираю реальные проблемы, с которыми компании сталкиваются при оценке. Каждая сессия длится 20 минут.
Я поговорил с Али об оценке SMS-приложения для неоплачиваемых сиделок — людей, ухаживающих за членами семьи, например за пожилыми родителями или детьми с инвалидностью. Его опыт высветил типичную трудность: с чего начать оценку LLM-приложения, когда возможных подходов так много?
Смотрите запись консультации
Вот видео полного обсуждения (20 минут):
Проблема: начинать с метрик, не посмотрев на данные
Али пришёл подготовленным, с продуманным анализом архитектуры своего приложения и потребностей в оценке. Его приложение состояло из следующих компонентов:
Twilio для SMS, бэкенд на FastAPI, Chroma для векторного хранилища, Mem0 для памяти, Azure OpenAI в качестве LLM, Helicone для наблюдаемости.
Он уже начал исследовать подходы к оценке, в том числе:
Написание юнит-тестов на ожидаемое поведение, использование инструментов оценки Azure AI Foundry, отслеживание метрик вроде связности (coherence), беглости (fluency) и релевантности (relevance).
Однако, как и многие команды, он не был уверен, что это правильная точка старта: «Я не знаю, какую часть моего приложения оценивать, ведь частей так много».
Подход «сначала данные»
Желание начать с метрик и тестов понятно — они кажутся конкретными и применимыми. Нам хочется иметь чёткие числа для отслеживания прогресса и автоматические тесты для отлова регрессий. Но такой подход «сверху вниз» часто заставляет нас измерять то, что легко измерить, а не то, что действительно важно для пользователей.
Вместо того чтобы сразу переходить к метрикам или тестам, начните с создания простой таблицы для анализа реальных диалогов. Вот пример того, как можно структурировать анализ ошибок:
Цель не в том, чтобы охватить всё, — а в том, чтобы начать замечать закономерности. Такой анализ сам собой подсказывает, на чём сосредоточить усилия по оценке.
Почему не стоит использовать готовые метрики?
Ключевой момент нашего разговора возник при обсуждении готовых метрик из Azure AI Foundry. Хотя такие инструменты предлагают метрики вроде «связности» (coherence) или «беглости» (fluency), они часто не отражают того, что действительно важно для вашего конкретного случая использования.
Как я сказал Али: «Если сегодня вы получаете оценку 3.72, а завтра 4.2, значит ли это, что ваша система действительно стала лучше? Мы не знаем. В этом и проблема обобщённых метрик».
Вместо этого сосредоточьтесь на метриках, которые напрямую связаны с потребностями ваших пользователей.
Начинайте с малого, используя синтетические данные
Как только вы поймёте свои реальные режимы отказа, вы сможете использовать синтетические данные для расширения тестового покрытия. Но начинайте с малого:
Сгенерируйте 1–2 тест-кейса для каждой выявленной проблемы, прогоните их через вашу систему, проанализируйте результаты, постепенно расширяйте охват на основе того, что узнали.
Главное — не дать себя перегрузить. Как заметил Али: «Думаю, это снимает большую часть тревоги, которую я испытывал, размышляя об evals».
Ключевые выводы
Начинайте с анализа реальных диалогов, а не с написания тестов; используйте простую таблицу или похожие инструменты, чтобы отслеживать и категоризировать проблемы; позвольте закономерностям в данных направлять вашу стратегию оценки; пишите тесты под конкретные, наблюдаемые режимы отказа; используйте синтетические данные для расширения покрытия, но начинайте с малого.
Помните: разглядывание данных может казаться канцелярской рутиной, но, как мы обсуждали, это часто «самое высокорычажное, что вы можете сделать».