Работает, но не готово: definition of done для ИИ-систем

Три моих ИИ-проекта живут в проде от полугода до двух лет. Месяц назад я попробовал ответить, готов ли хоть один, и не смог.

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

Оказалось, что нет. Я не знал, сколько агент стоит в месяц. Точность ассистента последний раз мерили для версии, которой уже не существует. Каждый проект держится на том, что я помню, как он устроен.

Знакомая штука: проект живёт до вау-эффекта на демо, все хлопают, а дальше он не завершается и не умирает. Висит. У этого есть имя, demo-driven development, термин не мой. Болезнь массовая, MIT NANDA насчитали 95% корпоративных ИИ-пилотов без измеримого эффекта на P&L. К их методологии есть вопросы (выборка на интервью), но порядок величины сходится с тем, что я вижу вокруг.

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

Дисклеймер обычный: кейсы реальные, детали изменены, цифры компании округлены, метрики аудитов точные. Все три проекта мои личные инициативы рядом с основной работой команды, так что и спрос с меня.

Почему старое «готово» не работает

Сначала я думал, что дело в дисциплине. Не дожал, отвлёкся, ушёл в следующий проект.

Потом дошло. Я применяю к ИИ-системам definition of done от обычного софта: фича готова, когда работает для всех случаев. В детерминированном коде это нормально, там граница возможностей это баг, его чинят.

С LLM так не выйдет. Мой SQL-агент берёт 75% простых запросов и 30% сложных. Сколько итераций ни делай, «работает всегда» не будет, это свойство технологии. Требовать от вероятностной системы детерминированного DoD значит записать её в вечную бету навсегда. Не потому что лень доделать. Потому что «доделать» не определено.

Дальше цифры, которые меня успокоили. По S&P Global, в 2025-м 42% компаний свернули большинство ИИ-инициатив, годом раньше таких было 17%. Gartner среди причин называет слабый контроль рисков и неясную бизнес-ценность. Половина этого списка про одно и то же: неизвестно, что система делает на краю и кому она нужна.

Определение, к которому я пришёл: готовая ИИ-система это та, у которой граница возможностей проведена, записана и обслуживается. Умение всё делать в определение не входит.

Чек-лист

Рубрики готовности для ML придумали давно, у Google с 2017 лежит ML Test Score на 28 тестов. Мне нужен был вариант полегче, под LLM-фичи и на один вечер.

0. Гейт. Вы сами, без модели, отличаете правильный ответ от неправильного и можете объяснить как? Если нет, это не ИИ-проект, а молитва «зальём данные, оно само поймёт». Не поймёт. LLM автоматизируют то, что можно проверить, непроверяемое имитируют. Провалили гейт, вердикт красный независимо от остального.

1. Точность измерена по классам задач и записана цифрами.

2. Список того, чего система не умеет, существует и виден пользователям. Хватит плашки: «по вопросам X и Y бот не консультирует, зовите человека».

3. На задаче вне возможностей система отказывает или эскалирует. Проверено вопросами-ловушками.

4. Есть сигнал о тихих ошибках. Команда узнаёт о неверных ответах раньше пользователей.

5. У системы есть владелец. Одно имя, а не «автор, когда вспомнит».

6. Поменяли модель или промт, перегнали eval, записали дельту.

7. Цена запроса и месяца известна, есть порог «дальше улучшать не окупается».

8. Известно, кто пользуется и какую метрику это двигает.

К седьмому пункту приписка про цену потолка. Экономика ИИ-системы всегда подбита под конкретную модель. Прогоните eval на модели классом выше, прежде чем месяц докручивать харнес. Бывает, что потолок покупается деньгами, а вы пробиваете его головой.

Счёт простой: «да» балл, «частично» половина. 7–8 готово, система переживёт ваш отпуск. 4–6.5 граница оформляется, по моим планам это две-шесть недель. Ниже красная зона, система живёт ровно столько, сколько живёт энтузиазм автора.

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

Проект первый: внутренняя ИИ-платформа. 3.0 из 8

Самый развитый мой проект. Отвечает на вопросы по коду и базе, обновляет базу знаний из дневных коммитов (Confluence мы после этого выключили), генерирует пользовательские инструкции, кормит бота поддержки. Больше половины исследовательских запросов аналитиков закрывается без разработчиков. Про его SQL-часть я писал отдельную статью с бенчмарком.

Счёт: шесть «частично», два «нет». Три вещи, которые меня зацепили.

Стоимость бенчмарка я знаю до копейки: 370 рублей за 614 прогонов. Сколько платформа стоит в месяц в проде, сказать не мог. Usage приходит с каждым ответом модели, складывается в счётчик и выбрасывается. Ни в базу, ни в лог.

Дальше хуже. Одну из функций не запускали пять недель, за это время её сломало чужое изменение на стенде. Узнать было неоткуда: таймера нет, алерта нет, кнопки «не помогло» нет. Я запустил функцию руками по другому поводу и увидел, что она падает.

Третья история самая стыдная. В том самом бенчмарке я измерил: на вопросах, где данных в базе нет, агент вместо признания уверенно сочиняет. Измерил, написал об этом статью, оставил в проде как было. При этом в соседней подсистеме той же платформы проблема давно решена: модель выбирает из закрытого списка или возвращает «не найдено», пять ловушек аудита она прошла без единой выдумки. Готовое решение лежало в том же репозитории. Перенести его скучно, вот и не перенёс. Теперь это первая строчка плана, два-три дня.

Вердикт аудитора без купюр: «Система не выглядит небрежной. Красный цвет даёт не низкое качество мышления, а разрыв: измеряется то, что исследуется, и не измеряется то, что работает в проде».

Проект второй: SaaS для генерации контента. 1.5 из 8, гейт провален

Самый молодой. Платформа учит партнёров компаний вести соцсети и генерирует им черновики постов. Ранний этап, но не бумажный, первые пользователи есть.

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

Сразу оговорюсь. Гонять чек-лист ИИ-готовности по системе без модели это тест рамки на прочность, а не полноценная треть выборки. Счёт 1.5 сложился из трёх «частично» при проваленном гейте.

Гейт провален вот почему. Определения правильного ответа нет нигде: ни в документах, ни в промтах. Самое близкое к критерию, что нашлось, это фраза из описания «скорость без потери качества». Что такое годный пост и кто это решает, не написано нигде. Про шаблонизатор я знал, про отсутствие критерия узнал от аудита.

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

План до зелёного: четыре недели плюс пилот, первые четыре дня снимают гейт. Или закрыть проект, чек-лист делает и этот выбор видимым.

Проект третий: ассистент поддержки. 3.5 из 8

Самый зрелый по замыслу. Оператор получает черновик ответа клиенту и сам решает, отправить или переписать. Автономных ответов клиенту нет. За первую декаду двести с лишним подсказок, 571 юнит-тест, шесть детекторов безопасности.

Гейт пройден на полный балл, и этим я горжусь. 70 реальных вопросов клиентов, к каждому эталонный ответ от самого отдела поддержки, шкала расхождений и записанное правило: уверенная неправда опаснее отказа, отказ оператор увидит, а выдумку может отправить клиенту.

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

Отметки операторов, главный сигнал качества, молчат 34 дня, оборвалось на стороне смежной системы. Детектор этой тишины построен и работает. Пишет ERROR в лог, потому что канала доставки алертов в проекте нет. Токены, как и в первом проекте, считаются и выбрасываются.

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

Что повторилось во всех трёх

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

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

Качества моделей в этом списке нет. Валится операционная половина, та, которую скучно делать и которую не покажешь на демо. Свой SQL-эксперимент я исследовал до копейки, потому что исследовать интересно. Прод не измерял, потому что измерять рутинно.

На уровне кода то же самое. GitClear в отчёте по 623 миллионам изменений насчитал рост на 47% за три года у конструкций, которые маскируют ошибки: широкие catch, safe-navigation, стабы. Код выглядит надёжным, потому что глушит сигналы тревоги. У меня то же самое случилось этажом выше, в ответах системы и в дисклеймере поверх опасного текста. GitClear продаёт метрики кода, поправку на это делайте, но причину они формулируют точнее меня: агенты сфокусированы на задаче и не делают побочных квестов. Закрыл тикет и ушёл.

Что я поменял у себя

Гейт и владелец до первого коммита. Новый ИИ-проект не стартует, пока письменно не отвечен вопрос «как мы отличаем правильный ответ» и не названо имя владельца. Два дня разговоров на старте дешевле, чем узнать про проваленный гейт через два года.

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

Поменял модель или промт, перегнал набор. Без исключений. Стоит один запуск скрипта, а оба случая «точность измерена для мёртвой версии» выросли из его отсутствия.

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

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

И главное, ради чего я всё это писал. «Готово» для ИИ-системы это не событие, а состояние, которое обслуживается, пока система жива. Пункты про сигнал, пересмотр и владельца закрыть навсегда нельзя. Зато теперь понятно, что именно обслуживать и почём.

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

Ограничения

Чек-лист собран на моём опыте и трёх аудитах, это не стандарт индустрии, за полным вариантом идите в ML Test Score. Пункты в счёте равновесные, в жизни нет: отсутствие владельца убивает быстрее, чем отсутствие документа об ограничениях, так что счёт это грубая линза. Аудиты делал агент, местами по коду, к которому сам приложил руку, конфликт он задекларировал, но человек результаты не перепроверял. Для ресёрч-фаз и ранних стадий рамка строгая, самый молодой проект я прогнал через неё сознательно, чтобы посмотреть на дно шкалы. И выборка: три проекта одного руководителя, который решил проверить себя жёстче, чем проверял бы чужих.