Evals: как продакт-менеджеру измерять качество ИИ-продукта вместо гадания

Два года назад слово «evals» не встречалось в описаниях вакансий продакт-менеджеров. Сегодня руководители Anthropic и OpenAI называют этот навык самым востребованным в ИИ-разработке. Речь идёт о системном подходе к измерению качества LLM-приложений — в противовес практике менять промпты интуитивно и смотреть, «стало ли лучше».

Проблема в природе самих языковых моделей. В обычном программировании тест — это проверка конкретного значения: функция должна вернуть 42. LLM стохастична: один и тот же вопрос она может обработать десятью разными способами, иногда галлюцинируя, иногда отвечая грубо, иногда зависая в диалоге. Написать assert a == b здесь невозможно. Именно поэтому нужен отдельный инструментарий — evals.

Практический пример, который разбирают Хамиль Хусейн и Шрея Шанкар в подкасте Ленни Рачицкого: ИИ-ассистент для аренды квартир компании Nurture Boss. Пользователь спрашивает про однокомнатную квартиру, ассистент отвечает «Нету, до свидания». Формально — правда. С точки зрения продукта — потеря лида: нужно было передать диалог живому менеджеру. Без измерений такие случаи остаются невидимыми.

Процесс начинается с ручного анализа логов — так называемого open coding. Продакт или эксперт домена просматривает около 100 примеров цепочек событий и фиксирует типы ошибок: «галлюцинация про виртуальный тур», «завис в цикле», «не предложил альтернативу». Авторы подкаста настаивают: делегировать этот этап самой LLM нельзя — у модели нет продуктового контекста, она оценит вежливый тупик как успех. После накопления заметок их можно кластеризовать с помощью модели: в примере с ассистентом получилось три группы — 45 случаев с неправильной передачей диалога, 17 со сломанной вёрсткой SMS, 10 галлюцинаций. Это и есть приоритеты для работы.

Когда проблема выявлена, но её сложно проверить кодом, подключается LLM-as-a-Judge — другая языковая модель, которая оценивает ответы первой. Ключевое правило: судья должен давать только бинарный вердикт — «провал» или «успех». Шкалы от 1 до 7 дают ненадёжные результаты. Перед использованием судью нужно валидировать: прогнать через него 100 примеров, уже размеченных вручную, и построить матрицу ошибок. Простая метрика accuracy здесь обманчива — если 90% случаев успешны, судья может просто всегда отвечать «ок» и формально иметь 90% точности, оставаясь бесполезным. Смотреть нужно на precision и recall по конкретным классам ошибок.

Отдельный сюжет — дискуссия вокруг «вайб-кодинга». Инженер Claude Code публично заявил, что его команда не делает evals и работает на интуиции. Хусейн и Шанкар объясняют, почему это не противоречие: разработчики — сами доменные эксперты, они мгновенно оценивают сгенерированный код. Для юриста или врача такой подход не работает — они не могут часами потреблять галлюцинации, чтобы выработать чутьё. Кроме того, даже Claude Code обучен на бенчмарках, то есть evals встроены в фундамент модели — просто цикл обратной связи там сокращён.

По трудозатратам: первая итерация занимает 3–4 дня, дальнейший мониторинг — около 30 минут в неделю на выборке из 1000 логов (например, через cron job). Авторы советуют не ждать готового инструмента, а писать собственные утилиты под конкретный продукт — скрыть системный промпт по умолчанию, подсветить ошибки красным, добавить кнопку «Добавить в eval» в один клик. Без таких мелочей аналитики устают и бросают процесс раньше, чем он начинает давать результат.