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 кейса на проблему. Ключевая мысль: изучение данных кажется рутиной, но это «самое высокорычажное, что можно сделать».
These are notes from my open office hours on LLM Evals, where I troubleshoot real issues companies are having with their evals. Each session is 20 minutes.
Это заметки с моих открытых консультаций по LLM Evals, где я разбираю реальные проблемы, с которыми компании сталкиваются при оценке. Каждая сессия длится 20 минут.
I spoke with Ali about evaluating an SMS-based caregiving app for unpaid caregivers - people taking care of family members like elderly parents or disabled children. His experience highlighted a common challenge: how do you start evaluating an LLM application when there are many potential approaches?
Я поговорил с Али об оценке SMS-приложения для неоплачиваемых сиделок — людей, ухаживающих за членами семьи, например за пожилыми родителями или детьми с инвалидностью. Его опыт высветил типичную трудность: с чего начать оценку LLM-приложения, когда возможных подходов так много?
Watch The Office Hours
Смотрите запись консультации
Here is the video of the full discussion (20 minutes):
Вот видео полного обсуждения (20 минут):
The Issue: Starting with Metrics Before Looking at Data
Проблема: начинать с метрик, не посмотрев на данные
Ali came prepared with a thoughtful analysis of his application’s architecture and evaluation needs. His App had the following components:
Али пришёл подготовленным, с продуманным анализом архитектуры своего приложения и потребностей в оценке. Его приложение состояло из следующих компонентов:
Twilio для SMS, бэкенд на FastAPI, Chroma для векторного хранилища, Mem0 для памяти, Azure OpenAI в качестве LLM, Helicone для наблюдаемости.
He had already begun exploring evaluation approaches, including:
Он уже начал исследовать подходы к оценке, в том числе:
Написание юнит-тестов на ожидаемое поведение, использование инструментов оценки Azure AI Foundry, отслеживание метрик вроде связности (coherence), беглости (fluency) и релевантности (relevance).
However, like many teams, he wasn’t sure if this was the right place to start: “I don’t know what part of my application to evaluate since there are many different parts”.
Однако, как и многие команды, он не был уверен, что это правильная точка старта: «Я не знаю, какую часть моего приложения оценивать, ведь частей так много».
The Data-First Approach
Подход «сначала данные»
The instinct to start with metrics and tests is understandable - they feel concrete and actionable. We want clear numbers to track improvement and automated tests to catch regressions. But this top-down approach often leads us to measure what’s easy to measure, not what actually matters to users.
Желание начать с метрик и тестов понятно — они кажутся конкретными и применимыми. Нам хочется иметь чёткие числа для отслеживания прогресса и автоматические тесты для отлова регрессий. Но такой подход «сверху вниз» часто заставляет нас измерять то, что легко измерить, а не то, что действительно важно для пользователей.
Instead of immediately jumping to metrics or tests, start by creating a simple spreadsheet to analyze real conversations. Here’s an example of how you might structure your error analysis:
Вместо того чтобы сразу переходить к метрикам или тестам, начните с создания простой таблицы для анализа реальных диалогов. Вот пример того, как можно структурировать анализ ошибок:
The goal isn’t to be comprehensive - it’s to start seeing patterns. This analysis naturally suggests where to focus your evaluation efforts.
Цель не в том, чтобы охватить всё, — а в том, чтобы начать замечать закономерности. Такой анализ сам собой подсказывает, на чём сосредоточить усилия по оценке.
Why Not Use Off-the-Shelf Metrics?
Почему не стоит использовать готовые метрики?
A key moment in our conversation came when discussing off-the-shelf metrics from Azure AI Foundry. While these tools offer metrics like “coherence” or “fluency”, they often don’t capture what actually matters for your specific use case.
Ключевой момент нашего разговора возник при обсуждении готовых метрик из Azure AI Foundry. Хотя такие инструменты предлагают метрики вроде «связности» (coherence) или «беглости» (fluency), они часто не отражают того, что действительно важно для вашего конкретного случая использования.
As I mentioned to Ali: “If you get a score of 3.72 today and a score of 4.2 tomorrow, does it really mean your system is better? We don’t know. That’s the problem with generic metrics.”
Как я сказал Али: «Если сегодня вы получаете оценку 3.72, а завтра 4.2, значит ли это, что ваша система действительно стала лучше? Мы не знаем. В этом и проблема обобщённых метрик».
Instead, focus on metrics that directly tie to your users’ needs.
Вместо этого сосредоточьтесь на метриках, которые напрямую связаны с потребностями ваших пользователей.
Starting Small with Synthetic Data
Начинайте с малого, используя синтетические данные
Once you understand your real failure modes, you can use synthetic data to expand your test coverage. But start small:
Как только вы поймёте свои реальные режимы отказа, вы сможете использовать синтетические данные для расширения тестового покрытия. Но начинайте с малого:
Сгенерируйте 1–2 тест-кейса для каждой выявленной проблемы, прогоните их через вашу систему, проанализируйте результаты, постепенно расширяйте охват на основе того, что узнали.
The key is to avoid getting overwhelmed. As Ali reflected: “I think that eases a lot of anxiety I had just thinking about evals.”
Главное — не дать себя перегрузить. Как заметил Али: «Думаю, это снимает большую часть тревоги, которую я испытывал, размышляя об evals».
Key Takeaways
Ключевые выводы
Начинайте с анализа реальных диалогов, а не с написания тестов; используйте простую таблицу или похожие инструменты, чтобы отслеживать и категоризировать проблемы; позвольте закономерностям в данных направлять вашу стратегию оценки; пишите тесты под конкретные, наблюдаемые режимы отказа; используйте синтетические данные для расширения покрытия, но начинайте с малого.
Remember that looking at data might feel like a clerical task, but as we discussed, it’s often “the highest leverage thing you can do.”
Помните: разглядывание данных может казаться канцелярской рутиной, но, как мы обсуждали, это часто «самое высокорычажное, что вы можете сделать».