PRD == evals: как AI сближает продакта и ML-инженера

В классическом ML бизнес приносил задачу, а инженер раскладывал её на части, выбирал метрику и собирал датасет. Стандартный PRD плохо описывал недетерминированный результат, поэтому ответственность делили продакт, аналитик и ML-инженер — без единственного владельца качества. API моделей и coding agents изменили баланс: продакт способен сам собрать прототип, а инженер всё чаще решает, как встроить готовую модель в бизнес-процесс. Граница ролей размывается там, где определяется приемлемое поведение системы.

Формула PRD == evals не означает заменить документ таблицей вопросов. Eval фиксирует сценарии, критерии хорошего ответа, запреты и регрессии, становясь точкой управления продуктом. Для инвестиционного RAG-ассистента команда берёт свежие пары «запрос — ответ» из промышленного трафика, отмечает и кластеризует ошибки. Крупнейшей проблемой могут оказаться устаревшие данные, отсутствие источника, неверная цифра, неподходящий тон или запрос для другого домена. Исправленные кейсы остаются в регрессионном наборе, а новые логи пополняют проверку. Сто процентов на неподвижном наборе скорее сигнализируют о переобучении, чем о безупречном продукте.

Построение eval-набора требует продуктового и доменного суждения. Разметчики расходятся в категориях ошибок и шкалах, поэтому команда согласует рубрику, калибруется и предпочитает понятные бинарные критерии. Обычные тесты проверяют детерминированную структуру, LLM-as-a-judge — смысл, общие разметчики — повседневную уместность, а дорогие специалисты из инвестиционного бизнеса и поддержки — правила и сложные ответы. Частота прогонов определяется стоимостью людей, инференса и риска ошибки.

Офлайн-оценки дополняют эксплуатационные ограничения. Инвестиционный ассистент не должен выдавать индивидуальные рекомендации, поэтому команда выбрала дисклеймер во всех ответах и guardrails. Для детского ассистента нужны другие фильтры, словари и постпроверки; каждый слой повышает безопасность, но добавляет задержку. В 2023 году команда строила RAG-ассистента до зрелых методик вроде RAGAS и ошибалась в сборе и сопровождении evals. Поэтому быстрый MVP не доказывает готовность: промышленный продукт требует свежих данных, маршрутизации, прав, инструментов, памяти, безопасности и владельцев качества.

Универсальный ассистент поднимает ожидания выше возможностей системы. Ранний Олег, появившийся до LLM, показывал ловушку: пользователи ожидали помощи с любым вопросом, а ограниченные данные и навыки давали непредсказуемые ответы. Поэтому «вселенная ассистентов» Т-Банка разделила задачи по доменам, выбирая широкую аудиторию, выраженную проблему и знакомую банку область. Специализация улучшает качество и позволяет назначить разные evals и guardrails для инвестора, ребёнка или путешественника, хотя заставляет выбирать помощника.

AI Product Builder проходит путь от потребности и прототипа до решения и цикла улучшения, отвечая за качество и ценность. Это не обязательно новая клетка оргструктуры или одиночка: аналитика, интеграции и предметные риски требуют специалистов. Но команда из пяти-шести человек меньше теряет на передачах работы. Продакту полезно научиться прототипировать, синтезировать интервью и строить evals; ML-инженеру — понимать пользователя, процесс и экономику внедрения. Сильные модели обесценивают часть prompt engineering и эвристик, но не доменное суждение, проверочные наборы и инфраструктуру с явными политиками, тестами и безопасным путём в production.