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

Альбина начинает с ремарки: стандартных PRD в ML-команды не приносили никогда — продукт недетерминирован, и evals для неё не новость, просто теперь тема острее. Восемь лет назад бизнес приносил задачу, а ML-инженер сам раскладывал её на кубики, выбирал метрику и собирал датасет. Изменилось другое: появились API моделей и coding agents, поэтому продакт способен собрать прототип сам, а инженер всё чаще занимается не моделью, а тем, как встроить её в бизнес-процесс. Роли схлопнулись, и где проходит граница, по её словам, уже не совсем понятно. Как продукт работает и какую ценность приносит, зашито в evals — это и есть точка управления, и тот, кто ими владеет, больше всех отвечает за результат. Раньше ответственность делили продакт и аналитик, единственного владельца качества не было. Александр добавляет: обвязки вокруг чёрной коробки отчасти коммодитизировались, а укрощение самой коробки — нет, и у автономного продукта нет human-in-the-loop, который есть у внутренних автоматизаций.

Альбина пришла в компанию восемь лет назад стажёром и была одной из первых десяти ML-инженеров — тогда ни в индустрии, ни внутри не понимали, что это за зверь. Первой задачей стал прогноз наличности в банкоматах: деньги должны быть во всей сети, но не в избытке: фондирование стоит дорого. Главный урок был не про модель: решить её хорошо можно было, только разобравшись в бизнес-процессе, и ошибок она сделала много. Инженер был сам себе аналитиком и менеджером, деплоил и собирал датасеты сам, поэтому итераций выходило мало. Из этих задач выросла AutoML-платформа Этна, а фреймворк для прогноза временных рядов команда выложила в open source: звёзды на GitHub, комьюнити, упоминания в чужих статьях. Александр вспоминает переводную книгу о прогнозировании, где на обложке, по его памяти, соседствовали Этна и известная зарубежная библиотека; Альбина уточняет, что та библиотека тогда называлась Facebook Prophet. Примерно тогда Альбина и поняла: делать удобное для других ей интереснее, чем оставаться ML-инженером.

Александр просит конкретный пример: фича помогает начинающему инвестору разобраться с индивидуальным инвестиционным счётом и не даёт индивидуальных рекомендаций. Альбина разворачивает это в рабочий цикл. Берутся свежие логи с прода — пары «запрос — ответ» RAG-ассистента, — и продакт смотрит трафик глазами и пишет заметки: здесь не прислали ссылку на источник, здесь подставили неактуальную цифру, здесь соврали, а здесь ответили на вопрос про шопинг, хотя должны были отправить пользователя в другую сторону. Смотрит не один: команда и эксперты размечают тоже, но главное — самому чувствовать трафик, иначе кластеризовать ошибки будет сложно. Дальше заметки отдают модели, она кластеризует, и берётся самый большой кластер: не хватает данных в индексе — добавить данные, страдает актуальность — подключить поиск, ломается tone of voice — перестать отвечать новичкам как зрелым трейдинговым инвесторам. Чинить каждую ошибку отдельно нельзя: вырастет каскад правил без обобщающей способности.

Хороший eval, по Альбине, свежий и с регрессом: что работало — должно продолжать работать, что починили — не ломаться снова; сотня на неподвижном датасете означает переобучение, а не готовый продукт, поэтому в набор постоянно доливают новые логи. На разметке команда не сходится в категориях, а бинарные классы проще шкалы. Свои evals 2023 года собирали эмпирически: модели были сильно тупее, привычных метрик ещё не было, и ошибок в сборе набора сделали столько, что качество страдало. Проверки развели по цене: детерминированный ответ закрывает обычный тест, рассуждение — LLM-as-a-judge по заранее написанным критериям, бытовую уместность отдают платформам разметки, а самое дорогое — эксперты из инвестиций и их поддержки, знающие новые законы. Всё это стоит денег, поэтому прогоны ставят на расписание. Онлайн держат гардрейлы: дисклеймер про отсутствие инвестиционной рекомендации ставили везде, решив не рисковать, а в детском ассистенте после генерации работают фильтрующие модели и словари стоп-слов. Альбина вспоминает Gemini, который генерирует ответ и в конце извиняется, что ответить не может: заглушек лучше больше, но за скоростью надо следить.

Зачем резать ассистентов по доменам? Ответ короткий: разделяй и властвуй, в продакшене так проще. Общему ассистенту нужна сильная технологическая база на старте, а свои хорошие модели дорого делать и поддерживать. Общий ассистент в компании был ещё до эпохи LLM: первая болталка училась на ответах с mail.ru и на вопрос про владельца банка называла чужого банкира. Первые версии, по её памяти, появились между 2017 и 2019 годом, и ожиданий пользователей ассистент не вытягивал. В 2023 году запустили вселенную из шести специализированных ассистентов, среди них шопинг, путешествия, детский, финансовый и инвестиционный. Домены выбирали без скоринговой таблицы: широкая аудитория, явная боль и комплементарность банку — ассистента для стройки делать смысла не было. Минус честный: пользователю приходится думать, в какую вкладку идти. Зато инвестору и ребёнку нужны разные гардрейлы и tone of voice — доменная экспертиза и делает продукт хорошим.

Александр спрашивает про «горький урок»: не проигрывает ли доменная экспертиза модели побольше. Альбина отвечает опытом: с 2023 года они много вкладывались в промпт-инженерию, а с поумневшими моделями обвязок нужно меньше — задачу достаточно сформулировать, дальше модель сама раскладывает шаги. Так же было в машинном переводе, где десятилетия работы над архитектурами обесценились с приходом LLM. Вывод двойной: думать, переживёт ли сделанное следующий класс моделей, и всё равно строить только необходимые обвязки. AI Product Builder — концепт, ещё не устоявшийся во всех командах: наполовину ML-инженер, наполовину менеджер, который идёт от потребности к прототипу и решению, настраивает цикл улучшений и отвечает за результат. Команда из одного человека не выходит, но пять-шесть эффективнее десяти-пятнадцати, где всё съедают коммуникации; в «Empowered» Марти Кагана, напоминает она, дело не в сборе топ-перформеров, а в размытых границах ролей. Продакту она советует собирать прототипы и ускорять discovery, ML-разработчику — идти к пользователю и бизнес-процессу. Александр добавляет: билдеру нужны гейты — дизайн-система, тесты, shift-left от безопасников, GitOps-пайплайн, — тогда те же правила проверит и агент.