Product Growth: мастер-класс по AI evals — самый важный новый навык для product managers в 2026 году

Что охватывает видео

Этот мастер-класс был опубликован 19 февраля 2026 года на канале Product Growth Аакаша Гупты и посвящён AI-оценкам (evals): как product managers должны проектировать, внедрять и масштабировать системы тестирования, которые проверяют, работают ли AI-функции так, как задумано, — до и после запуска. Гостем выступает Анкит Шукла, основатель HelloPM.

Исходная посылка такова: большинство сбоев AI-функций восходит к единому разрыву — команды запускают AI без надёжного способа измерить качество выходных данных. Традиционное QA и A/B-тестирование недостаточны для недетерминированных систем, где один и тот же входной запрос может давать разные ответы. Evals заполняют этот разрыв: они определяют, как выглядит «хороший» результат, и систематически проверяют соответствие этому определению.

Для кого это видео

Для product managers, которые создают или владеют AI-функциями, — вне зависимости от технического бэкграунда. Материал практический, а не теоретический: каждая концепция сопровождается пошаговым подходом к реализации. Особенно полезно для PM, которым нужно выстроить процессы оценки с нуля или определить стандарты качества для AI-системы без предыдущего опыта в этой области.

Ключевые выводы

1. Evals делятся на три категории, каждая из которых решает свою задачу. Офлайн-evals запускаются до релиза на кураторских тестовых датасетах; онлайн-evals мониторят production-трафик в реальном времени; человеческие evals обеспечивают периодические точечные проверки качества выходных данных. Каждый тип закрывает слепые зоны, которые другие не покрывают, и опираться только на один тип — недостаточно для AI-функций со значимыми последствиями для пользователей.

2. Полезная рубрика для оценки начинается со сценариев, а не метрик. Процесс начинается с определения конкретных пользовательских сценариев, затем для каждого создаётся 4–6 категорий оценки с эталонными примерами, иллюстрирующими, как выглядят оценки 1, 3 и 5 на практике. Тест на согласованность оценщиков — когда два человека независимо выставляют оценки одним и тем же выходным данным и сравнивают результаты — проверяет, что рубрика даёт стабильные результаты у разных ревьюеров.

3. Правильная метрика зависит от типа задачи. Системы извлечения информации — поиск, рекомендации — требуют измерений precision и recall. Открытая генерация текста лучше поддаётся оценке через семантические метрики сходства, такие как BERTScore. Узкоспециализированные задачи могут требовать кастомных метрик, привязанных к конкретным результатам, а не к общим прокси качества.

4. LLM-судьи позволяют автоматизировать оценку в масштабе после калибровки. LLM-судья использует языковую модель для оценки выходных данных другой модели. Калибровка означает сравнение оценок судьи с размеченным людьми бейслайном для подтверждения соответствия, а затем регулярное тестирование для обнаружения дрейфа. Некалиброванный LLM-судья создаёт иллюзию строгости оценки без её содержательной части.

5. Мониторинг в production требует трёх отдельных уровней отслеживания. Системные метрики охватывают задержку и частоту ошибок. Метрики качества отслеживают автоматические оценки на живых выходных данных. Бизнес-метрики фиксируют успешность выполнения задач и удовлетворённость пользователей. Автоматические алерты и очереди человеческой проверки для помеченных выходных данных завершают контур мониторинга — без всех трёх уровней проблемы в одном измерении могут оставаться незамеченными, пока остальные выглядят благополучно.

Стоит смотреть, если…

Вы готовитесь к запуску AI-функции и не имеете формального процесса оценки, или если ваша команда затрудняется определить, как выглядит «хороший результат» для конкретного сценария использования. Также полезно при подготовке бизнес-кейса для инфраструктуры оценки, поскольку описанные фреймворки достаточно конкретны для прямого перевода в разговор об ресурсах.