How a product manager can assess AI product quality: a guide to evals

Evals — оценка качества LLM-продукта — внезапно стали самым обсуждаемым навыком среди продактов в AI-компаниях. Топ-менеджеры Anthropic и OpenAI открыто называют умение строить системы оценки ключевой компетенцией для любого продакт-менеджера, работающего с языковыми моделями. В подкасте Ленни Рачицкого исследователи Хамиль Хусейн и Шрея Шанкар разобрали, как именно PM должен подходить к оценке AI-продукта — и почему интуиция здесь не работает.

Что такое eval и зачем он нужен Eval — это систематическая проверка того, насколько хорошо языковая модель справляется с конкретной задачей в конкретном контексте вашего продукта. В отличие от классического software testing, где ответ либо правильный, либо нет, в LLM-продуктах ответ почти всегда находится где-то посередине. Один и тот же запрос может дать десятки разных, но равно приемлемых ответов — и задача PM понять, какой из них лучше для конкретного пользователя в конкретной ситуации.

Большинство команд на старте оценивают модели субъективно: смотрят несколько примеров и делают вывод. Это работает для простых функций, но полностью ломается при масштабировании. Когда у продукта миллион обращений в сутки, ручной просмотр невозможен — нужна система, которая работает автоматически и воспроизводимо.

Три уровня оценки AI-продукта Эксперты предлагают выстраивать eval в три последовательных слоя. Первый — определение критериев успеха. Прежде чем что-то измерять, PM должен ответить на вопрос: что значит «хороший ответ» для нашего продукта?

Это может быть точность фактов, соответствие тону бренда, длина, структура, отсутствие токсичности или безопасность. Без этого шага любые метрики бессмысленны — вы будете измерять не то, что важно пользователю. Второй уровень — сборка «золотого набора».

Это коллекция примеров запросов с идеальными ответами, созданными вручную или отобранными из реальных данных. Именно против этого набора тестируется модель при каждом обновлении. Качество золотого набора напрямую определяет качество всей системы оценки — в этом и заключается главная сложность и главная ответственность PM.

Третий уровень — автоматизация оценки. На этом этапе команда строит пайплайн: новая версия модели или промпта прогоняется через золотой набор, результаты сравниваются с эталонами — автоматически или с помощью judge-модели, то есть другого LLM, который оценивает ответы. Регрессия сразу видна в цифрах, а не обнаруживается в отзывах пользователей через неделю после релиза.

Почему PM не может делегировать это инженерам Соблазн передать evals технической команде велик, но это ошибка. Evals — это продуктовые решения: что важно пользователю, что он считает хорошим ответом, какими компромиссами мы готовы жертвовать ради скорости или стоимости. Инженер не знает, почему пользователь предпочитает краткий ответ развёрнутому или почему тон «дружелюбный, но профессиональный» важнее на три процента более точного ответа.

Именно PM строит связь между метриками evals и реальными бизнес-результатами. Если модель стала на пять процентов точнее, но удовлетворённость пользователей не изменилась — что-то не так с самим критерием оценки. Найти и исправить это несоответствие — продуктовая задача, не инженерная.

Что это означает для рынка и карьеры Два года назад слово «evals» встречалось в основном в академических статьях. Сегодня это стандартная часть roadmap любого серьёзного AI-продукта. Компании, которые научились систематически измерять качество своих LLM-решений, получают устойчивое конкурентное преимущество: они быстрее обнаруживают регрессии, точнее сравнивают модели между собой и принимают решения об обновлениях на основе данных, а не субъективных ощущений команды.

Для карьеры продакта вывод прямолинейный: если вы работаете с AI-продуктами и не умеете строить evals — вы проигрываете коллегам, которые умеют. Этот навык стал таким же обязательным, как умение работать с воронкой продаж или проводить A/B-тесты.