Почти любая сильная инженерная команда уже способна собрать эффектное AI-демо за считаные недели. Но AI в продакшене живет по другим правилам: там мало впечатлить заказчика на созвоне, нужно пережить грязные данные, нестабильные процессы и вопрос, зачем вообще модель встроена в продукт.
Об этом пишет The New Stack в колонке Эндрю Селлерса, где автор довольно жестко формулирует новый отраслевой вывод: эпоха, когда можно было показать красивый прототип и считать задачу почти решенной, закончилась. Для русскоязычной IT-аудитории это сигнал вполне прикладной. Если у компании до сих пор нет ответа на вопросы про качество данных, интеграцию с внутренними системами и метрики результата, значит, она строит не AI в продакшене, а дорогую презентацию.
Главная мысль материала проста и болезненна одновременно. Сам по себе прототип уже почти ничего не доказывает. Демо можно собрать быстро: подобрать модель, натянуть интерфейс, показать, как ассистент отвечает на пару удачных запросов, и получить одобрение от стейкхолдеров. Проблема начинается в тот момент, когда это нужно подключить к реальным данным компании, встроить в существующие рабочие процессы и заставить работать не на пяти красивых примерах, а на тысячах обычных, скучных и часто неаккуратных сценариев. Именно тут выясняется, что главная сложность не в модели как таковой, а в инфраструктуре данных, в правилах доступа, в свежести контекста, в устойчивости пайплайнов и в том, кто будет отвечать за результат после релиза.
Это хорошо совпадает с тем, что рынок наблюдает последние два года. На первом этапе почти все обсуждали сами модели: у кого точнее ответы, длиннее контекст, ниже цена токена и эффектнее демонстрация. На втором этапе компании начали упираться в куда менее фотогеничные вещи: каталогизацию источников данных, контроль версий промптов, логирование запросов, оценку качества ответов, защиту чувствительной информации и поддержку команд, которые должны все это эксплуатировать. Выяснилось, что запуск AI-функции напоминает не магию, а обычную enterprise-разработку, только с дополнительным слоем неопределенности. И если у классического софта ошибка часто воспроизводима, то у генеративных систем она может зависеть от формулировки запроса, качества retrieved-контекста и десятка внешних факторов.
С практической точки зрения статья бьет по одному из самых популярных корпоративных заблуждений: если демо сработало на пилоте, масштабирование будет вопросом бюджета. На деле между пилотом и реальным внедрением лежит пропасть. Нужно решить, какие данные считать источником истины, как быстро они обновляются, кто имеет право их читать, как система ведет себя при отсутствии нужного контекста и по каким метрикам бизнес вообще поймет, что решение полезно. Для разработчиков это означает смещение центра тяжести от «какую модель выбрать» к «как собрать надежный контур вокруг модели». Для продактов и IT-директоров вывод не менее неприятный: AI в продакшене почти всегда требует пересобрать кусок процесса, а не просто добавить кнопку с умным чатом.
Особенно важен и другой тезис, который в отрасли долго игнорировали. Пользователь обычно не покупает сам факт наличия искусственного интеллекта. Он покупает скорость, снижение рутины, более точный поиск, лучшую поддержку, меньше ручной обработки или более качественное принятие решений. Поэтому в производство доходят не самые зрелищные сценарии, а те, где можно четко измерить ценность и ограничить риски. В этом смысле рынок заметно повзрослел. Если раньше многие проекты продавались через вау-эффект, то теперь выживают системы, которые не обещают невозможное, зато умеют стабильно работать внутри конкретной бизнес-функции. Не универсальный «суперагент на все случаи жизни», а, например, аккуратный помощник для обработки документов, маршрутизации обращений, поиска по внутренней базе знаний или подготовки черновиков в предсказуемом формате.
Для российского и русскоязычного IT-рынка здесь нет никакой экзотики. Местные команды сталкиваются с теми же ограничениями, только часто в более жесткой форме: легаси-системы, разрозненные хранилища, неоднородные права доступа, ручные процессы, требования по безопасности и повышенная чувствительность к ошибкам в корпоративных сценариях. Поэтому разговор про AI в продакшене быстро становится разговором не про нейросети как модный слой, а про зрелость всей инженерной организации. Может ли компания быстро поднять качественный retrieval? Есть ли у нее наблюдаемость для AI-функций? Понимает ли она, где допустима вероятностная ошибка, а где нужен детерминированный ответ? Готова ли команда поддержки разбирать спорные ответы модели так же системно, как она разбирает баги в обычном приложении? Если нет, то даже хороший пилот останется пилотом.
Самый неудобный вопрос после таких материалов звучит не «какую модель внедрять дальше», а «какие AI-сценарии вообще заслуживают продакшена». Похоже, в ближайшее время рынок будет все меньше аплодировать красивым демо и все чаще требовать скучных доказательств: где данные, где контроль, где экономический эффект и кто дежурит, когда система начинает ошибаться не на сцене, а в реальном бизнесе.