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

Большинство AI-фич выходят в прод после проверки на глаз. Продакт гоняет в плейграунде десяток запросов, ответы выглядят прилично, команда ставит дату релиза. Через неделю приходит первая волна жалоб, и выясняется, что модель уверенно обещает клиентам то, чего компания не делает.

Мой тезис: оценка качества AI-фичи — работа продакта, а не ML-инженера. Что считать хорошим ответом, решает продукт. Это вопрос политики компенсаций, тона бренда, юридических рисков и того, какую ошибку пользователь простит. ML-команда может построить пайплайн, но не может за вас решить, что модели запрещено говорить. Аман Хан, директор по продукту в Arize AI, в гостевом тексте для рассылки Ленни Рачицкого в апреле 2025 года написал, что умение писать evals быстро становится базовым навыком для всех, кто строит AI-продукты. Я бы сказал жёстче: если у вас нет своих evals, у фичи нет критериев приёмки.

Ниже фреймворк, которым можно пользоваться без ML-команды, платных платформ и кода. Я называю его «Четыре шлюза»: четыре уровня проверки, у каждого свой артефакт и правило «идём дальше или стоп». Пример сквозной и условный: AI-помощник оператора поддержки в сервисе доставки еды. Клиент пишет «курьер опоздал на 40 минут, суп холодный», модель предлагает оператору черновик ответа и вариант компенсации.

С чем я спорю

Документация вендоров LLM даёт хорошую базу, но написана для команд с инфраструктурой. В руководстве Anthropic по оценкам прямо сказано: лучше больше вопросов с автоматической проверкой, чем меньше вопросов с ручной разметкой, а ручной оценки по возможности избегать. Для зрелой фичи с тысячами примеров это верно. Для первой версии это вредный совет. Пока вы не прочитали ответы сами, вы не знаете, что автоматизировать, и будете измерять не то.

Хамел Хусейн, консультант по AI-продуктам, называет анализ ошибок самым ценным занятием в AI-разработке и предупреждает, что обобщённые метрики хуже, чем бесполезны. По его словам, они мешают прогрессу: создают ложное ощущение, что качество измеряется, и распыляют внимание команды. С этим я согласен полностью. Поэтому первые два шлюза ручные, а автоматизация появляется только на третьем и только там, где её можно сверить с человеком.

Отдельно о том, почему это не задача QA. Тестировщик проверяет, что система делает то, что описано в требованиях. У AI-фичи требований в привычном виде нет, пока их кто-то не сформулирует на примерах. Формулировать их должен тот, кто отвечает за то, что фича даёт пользователю и бизнесу. Обычно это продакт. QA и инженеры подключаются позже, когда критерии уже есть и их нужно встроить в пайплайн.

Шлюз 1. Чтение

Что делает продакт. Собирает 50-100 входов. Лучше всего обезличенные реальные обращения. Если их нет, синтетические, но по заданным измерениям, а не наугад. Хусейн советует начинать синтетические данные с выбора измерений: здесь это тип проблемы (опоздание, недовоз, не тот заказ), тон клиента (спокойный, злой, саркастичный) и контекст заказа (первый заказ, постоянный клиент, крупная сумма). Затем продакт прогоняет все входы через фичу и читает каждый ответ, записывая свободным текстом, что не так. Когда заметок набирается много, он группирует их в режимы ошибок и останавливается, когда новые ответы перестают приносить новые категории.

Артефакт: таблица режимов ошибок. Название, пример, сколько раз встретилось в выборке, насколько это плохо для пользователя и для компании. В нашем примере там окажутся «обещает компенсацию, не зная суммы заказа», «извиняется за то, чего не было», «пересказывает жалобу вместо решения».

Правило шлюза. Если основная задача проваливается в большинстве ответов, дальше не идём. Это значит, что сломан дизайн фичи, а не формулировка промпта. Модель, которая не видит сумму заказа, не может предложить адекватную компенсацию, и никакие evals этого не исправят. Нужно добавить контекст или сузить задачу.

Шлюз 2. Критерии и золотой набор

Что делает продакт. Превращает режимы ошибок в критерии с ответом «да» или «нет». Шкалы от 1 до 5 здесь не работают: два человека по-разному понимают разницу между тройкой и четвёркой. Хусейн пишет, что бинарная оценка заставляет принять ясное решение, достигнута цель или нет, а гайд OpenAI рекомендует попарное сравнение или «прошёл/не прошёл» как более надёжные. Каждый критерий формулируется как проверяемое утверждение. «Ответ называет причину задержки, только если она есть в данных заказа». «Сумма компенсации не выше лимита по политике».

Отдельно выписываются красные линии, то есть то, чего не должно быть ни в одном ответе: обещание сверх политики, персональные данные курьера, обвинение клиента. Красные линии никогда не усредняются с остальными критериями.

Золотой набор состоит из 80-150 входов, которые покрывают измерения из первого шлюза и краевые случаи. В примерах тестовых наборов из гайда Anthropic такие случаи размечены прямо в коде: сарказм, опечатки, длинный сумбурный вопрос, несколько тем в одном обращении, резкая смена темы. Для каждого входа записывается ожидаемое поведение, а не эталонный текст: «извиниться, предложить компенсацию в пределах лимита, не обещать сроки».

Артефакт: таблица золотого набора и лист критериев с красными линиями.

Правило шлюза. Продакт и эксперт предметной области, например руководитель поддержки, независимо размечают одни и те же 30 ответов. Если они часто расходятся, критерии двусмысленные и их нужно переписать. Идём дальше, когда расхождения редкие и каждое можно объяснить.

Шлюз 3. Прогон и пороги

Что делает продакт. До прогона записывает пороги и согласует их со стейкхолдерами. По красным линиям допустим только ноль нарушений. По основным критериям фиксируется доля «да», ниже которой фича не выходит. Нужна и базовая линия: как на тех же входах справляется текущий процесс, например операторы с шаблонами ответов. Пороги фиксируют заранее, потому что после прогона всем захочется сдвинуть планку к полученному результату.

Потом продакт прогоняет золотой набор и размечает ответы. Сотню ответов по пяти бинарным критериям реально разметить за пару часов. LLM-судью можно подключать, только когда есть ручная разметка, с которой его сверить. И OpenAI, и Хусейн настаивают, что автоматического оценщика сначала калибруют по людям: в гайде OpenAI сказано, что масштабировать судью стоит, когда он стабильно совпадает с человеческой разметкой. Без этого у вас появляется вторая модель, в качестве которой вы тоже не уверены.

Артефакт: оценочная карта по критериям и одностраничное решение о запуске с подписями.

Правило шлюза. Ноль нарушений красных линий и выполненные пороги. Если пороги выполнены, но фича проигрывает базовой линии, это повод не запускать её, а переупаковать. Например, черновик видит только оператор и сам решает, отправлять ли его клиенту.

Шлюз 4. Тень

Что делает продакт. Запускает фичу в теневом режиме или на небольшую долю трафика. Модель генерирует, решение принимает человек. В лог пишутся вход, контекст, ответ модели и действие оператора: принял, исправил, отклонил. Гайд OpenAI советует логировать всё уже в процессе разработки, чтобы потом доставать из логов хорошие случаи для набора. Раз в неделю продакт читает выборку боевых ответов, и каждый новый режим ошибки попадает в золотой набор. Набор, который перестал расти, через пару месяцев проверяет уже не ту фичу, что работает в проде.

Доля черновиков, которые операторы правят, даёт самый честный сигнал качества, и он бесплатный. Его не нужно размечать, он появляется сам.

Артефакт: журнал недельных разборов и правило отката. В правиле заранее записано, при каком событии фича выключается и кто это делает.

Правило шлюза. Расширяем аудиторию, если доля «да» на боевой выборке сопоставима с офлайн-прогоном, нарушений красных линий нет, а защитная бизнес-метрика не просела. Для поддержки это время решения обращения и доля повторных обращений.

Шлюзы на одной странице

1. Чтение: 50-100 ответов прочитаны вручную. Артефакт: таблица режимов ошибок. Стоп, если основная задача проваливается в большинстве ответов.

2. Критерии: бинарные критерии, красные линии, золотой набор на 80-150 входов. Артефакт: таблица набора и лист критериев. Стоп, если продакт и эксперт часто расходятся в разметке.

3. Прогон: пороги записаны до запуска, есть базовая линия. Артефакт: оценочная карта и решение о запуске. Стоп при любом нарушении красной линии или проигрыше базовой линии.

4. Тень: ограниченный запуск, логи, еженедельный разбор, правило отката. Артефакт: журнал разборов. Расширяем, только если боевое качество не хуже офлайн-прогона.

Сколько это стоит

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

Чаще всего этот процесс ломается в четырёх местах. Золотой набор собран из одних «счастливых» сценариев. Вместо бинарных критериев считают среднюю оценку «4,2 из 5». LLM-судью никто не сверял с людьми. Набор заморозили в день релиза.

Если начинать завтра, начните с первого шлюза: 50 входов, 50 ответов, заметки на полях. После этого разговор с командой о качестве фичи пойдёт на языке конкретных ошибок, а не впечатлений. Набор evals и есть PRD для AI-фичи, только написанный примерами.

Иван Лапа, продакт-менеджер в Uzum Tezkor (Ташкент)