Исследование MIT NANDA прошлось по 150 интервью с руководителями, 350 сотрудникам и 300 публичным внедрениям и вынесло цифру, которую с тех пор цитируют все: 95% корпоративных ИИ-пилотов не дают измеримого эффекта на P&L.
Про эту цифру написали много. Почти всё написанное — управленческое: завышенные ожидания, слабое управление изменениями, бизнес подключили поздно. Всё правда. Но у неё есть вторая половина, инженерная, и о ней молчат, потому что писать про неё скучнее.
Скучная половина такая: пилот и рабочая система — это не одна и та же вещь на разных стадиях зрелости. Это два разных объекта. Пилот отвечает на вопрос «модель в принципе справляется?». Система отвечает на вопрос «это можно оставить без присмотра?». Второе не получается из первого дошлифовкой. Его надо строить, и объём работы там больше, чем в самом пилоте.
Ниже — шесть вещей, которых в демо нет. Не потому что автор пилота ленивый: в демо они не нужны. Нужны они начиная примерно с третьей недели эксплуатации, и появляются обычно в виде инцидента.
1. Очередь и ретраи
В демо вызов модели синхронный. Нажали кнопку, подождали шесть секунд, получили ответ. Это нормально, когда на кнопку жмёт автор демо.
В проде у вас поток. Провайдер отвечает 429, отваливается по таймауту, деградирует в час пик. Синхронный вызов в этот момент превращается в зависший запрос пользователя, и дальше по цепочке — в занятый воркер, в переполненный пул соединений, в лежащий бэкенд. Модель при этом ни в чём не виновата.
Значит нужны очередь, идемпотентность задачи, экспоненциальный бэкофф, потолок попыток и мёртвая очередь для того, что не прошло. Ничего экзотического — обычная асинхронная обработка, которую бэкендеры делают двадцать лет. Просто её в пилоте не было.
В Aginx я собираю ролик из четырёх стадий, и каждая ходит к своему внешнему провайдеру. Как только это перестало быть скриптом на один запуск, половина кода стала про то, что делать, когда очередная стадия не ответила.
2. Валидация того, что вернула модель
Самая дорогая иллюзия пилота — что модель возвращает то, что вы просили. На двадцати ручных прогонах возвращает. На двадцати тысячах — нет.
Она вернёт JSON с лишним полем. Вернёт JSON, обёрнутый в markdown-блок. Вернёт число строкой, дату в другом формате, категорию, которой нет в вашем справочнике. Изредка вернёт связный, уверенный, полностью выдуманный ответ.
Лечится это не уговорами в промпте, а схемой. Structured output, Pydantic-модель на выходе, и явное решение о том, что делать с ответом, который в схему не лёг. Обычно — повторить один раз с указанием на ошибку, а потом отдать человеку.
Отдельная строка: у модели должно быть право сказать «не знаю». Если в схеме нет варианта отказа, модель его и не выберет — она выберет самый вероятный ответ. Модель, которая честно отказывается отвечать, дешевле модели, которая уверенно врёт. Второе вы обнаружите не в логах, а в жалобе клиента.
3. Фолбэк на человека
Вопрос, который в пилоте не звучит: а что происходит с теми случаями, где модель не справилась?
Если ответа нет, происходит одно из двух. Либо ответ модели уходит клиенту как есть, и вы узнаёте о проблеме постфактум. Либо задача молча теряется, и вы не узнаёте о ней вообще.
Рабочий контур с самого начала проектируется как разделение потока, а не как замена человека. Часть уходит в автомат, часть — в очередь к оператору, и доля второго — это ваша главная метрика, а не досадный остаток. Она же честно показывает, сработало внедрение или нет.
4. Наблюдаемость решений
В обычном бэкенде лог отвечает на вопрос «что произошло». В контуре с моделью нужен ответ на вопрос «почему она так решила», и это другой лог.
Минимум, который потом спасает: версия промпта, идентификатор модели, вход, сырой выход, результат валидации, стоимость вызова, итоговое решение. Без этого через месяц вы не сможете ответить на вопрос «почему бот написал вот это» — а вопрос прилетит, и прилетит от того, кто подписывал бюджет.
Второе применение того же лога скучнее и полезнее: когда провайдер молча обновит модель, у вас будет с чем сравнить.
5. Счётчик расходов
Токены в пилоте бесплатны в том смысле, что их никто не считает. Двести запросов за время разработки не видно ни в каком бюджете.
В проде это статья расходов, которая растёт вместе с нагрузкой, а не вместе с выручкой. И у неё есть неприятное свойство: она растёт скачком, когда кто-то добавит в промпт побольше контекста «чтобы лучше отвечало».
Считать нужно не общий счёт в конце месяца, а стоимость одной обработанной единицы: заявки, документа, обращения. Только это число можно положить рядом с зарплатой человека, который делал то же самое руками, и получить осмысленный разговор.
Мне это стало понятно на Aginx, когда я довёл счёт до 250 рублей за ролик. Пока цифры не было, обсуждать было нечего. Как только появилась — стало видно, какие стадии дорогие, и что дешевле переделать, чем оптимизировать.
6. Деградация качества
Пилот измеряют один раз. Систему приходится измерять постоянно, потому что качество уезжает само.
Уезжает по трём причинам. Провайдер обновил модель под тем же именем. Изменился характер входных данных: пришёл новый тип клиента, новый формат документа, сезон. Кто-то поправил промпт, чтобы починить один случай, и сломал десять других.
Против этого работает набор из полусотни размеченных примеров, который гоняется по расписанию и на каждый деплой. Это не наука, это регрессионные тесты для недетерминированной штуки. Скучно, обязательно, почти никогда не делается на этапе пилота.
Что со всем этим делать
Первое: перестать считать пилот черновиком системы. Пилот отвечает на вопрос «модель справляется». Он ответил — отлично, дальше начинается отдельная работа, и её надо отдельно оценивать по деньгам и срокам. Ожидание «ну там осталось чуть-чуть допилить» — самый частый источник сорванных сроков в этой области.
Второе: записать метрику до начала работы. Не «стало удобнее», а число. Доля заявок, закрытых без человека. Время от поступления документа до заполненной карточки. Стоимость обработки одного обращения. Если метрику не записать заранее, после запуска вы будете обсуждать ощущения, а ощущения всегда на стороне того, кто громче говорит.
Третье, менее очевидное: искать не задачу для ИИ, а место, где человек уже повторяет одну и ту же операцию руками. Если такого места нет, автоматизировать нечего — сначала надо понять, что вообще должно происходить. Больше половины провалившихся пилотов, которые я видел, начинались с обратного порядка: сначала решили внедрять ИИ, потом искали куда.
В том же исследовании есть цифра, которую цитируют куда реже: проекты с привлечением внешних специалистов доходят до внедрения примерно вдвое чаще, чем сделанные только внутренними силами — 67% против 33%. Мне как человеку, который этим зарабатывает, полагается на этом месте многозначительно замолчать. Но объяснение у неё, кажется, простое и не очень лестное для моего цеха: внешнего человека заставляют назвать срок, цену и критерий успеха до начала работы. Внутреннюю команду — почти никогда.
