Чому пілотні проекти корпоративного штучного інтелекту застряють перед виробництвом: це не модель, а упряжка

Модель ніколи не була складною частиною. Зсередини побудови виробництво виграється або програється в шарі навколо неї: пошук, прив’язка, маршрутизація та оцінка.

Кожен великий опитування корпоративного штучного інтелекту тепер описує одну й ту ж перешкоду: організації можуть отримувати доступ до моделей, запускати пілотні проекти та демонструвати щось вражаюче, але майже нічого з цього не досягає виробництва. Звіти описують цю прогалину ззовні, через виконавців, які відповідають на запитання. Це погляд з іншого боку: зсередини побудов, де пілотні проекти або переходять у виробництво, або тихо помирають.

Прогалина, яку всі вимірюють

Цифри стали знайомі. Звіт Deloitte про стан штучного інтелекту в корпорації виявив, що доступ до штучного інтелекту тепер майже універсальний, але лише близько чверті організацій отримують навіть 40% своїх експериментів у виробництво, і близько однієї п’яти звітують про зрілу систему управління автономними агентами. Проект NANDA MIT висловив це більш прямо: серед сотень розгортань, абсолютна більшість не дала жодної вимірної фінансової віддачі. Gartner прогнозує, що велика частина проектів зі штучним інтелектом буде припинена після стадії доведення концепції, посилаючись на погану якість даних, зростаючі витрати та невиразну бізнес-ціль.

Якщо поєднати ці результати, то з’являється одна форма. Бутлянка не полягає в доступі до здатних моделей. Ця проблема вже вирішена. Бутлянка полягає в відстані між моделлю, яка працює в демонстрації, та системою, яка працює у виробництві, завжди, для кожного користувача, під реальною навантаженням, з реальними наслідками за помилки.

Зауваження, яке варто виразити явно: багато пілотних проектів ніколи не виходять у виробництво через причини, які не мають нічого спільного з інженерними: немає реальної бізнес-цілі, немає використовних даних, немає виконавчого спонсора або загальної вартості, яку ніхто не моделював. Відкладіть ці випадки. Що далі, це про велику і розчаровуючу кількість пілотних проектів, які є технічно реальними, демонструють переконливо та мають справжню бізнес-ціль за ними, і все одно застряють на шляху до виробництва. Для цих випадків вирішальною причиною майже ніколи не є модель.

Того, чого не можуть сказати дані опитування, це що саме закриває цю відстань. Ця відповідь не живе в запитанні. Вона живе в інженерних рішеннях, прийнятих після того, як демонстрація вражає всіх, і до того, як система буде довірена реальним клієнтам.

Причина: вирішальна зміна майже ніколи не є моделлю

У корпоративних проектах зі штучним інтелектом, про які ми можемо говорити, існує постійний шаблон: коли застряглий пілотний проект нарешті досяг виробництва, зміна, яка його туди привела, рідко була кращою моделлю. Це був шар навколо моделі: як інформація витягується та прив’язується, як виводи перевіряються до того, як вони досягнуть користувача, як робота маршрутизується до правильної моделі, а не до найбільш потужної, і як все це оцінюється безперервно.

Ми називаємо це шаром упряжки. Агент, у практичному сенсі, є моделлю з доступом до інструментів, а упряжка – це все, що керує тим, як ця модель витягує контекст, використовує ці інструменти та підзвітна за те, що вона виробляє: пошук, прив’язка, маршрутизація, обмежувачі та оцінка. Ці компоненти не працюють у ізоляції. Вам потрібно їх поєднати, свідомо, для конкретного випадку використання. Ця поєднана дисципліна називається упряжкою агента, і саме тут насправді виграється або програється виробництво.

Це переформулює пастку доведення концепції. Команди застряють, оскільки вони продовжують оптимізувати частину, яка вже працює. Вони міняють новішу модель, переробляють промпти та чекають на наступний реліз, тоді як справжні точки відмови сидять у шарі системи, який демонстрація ніколи не нагружає.

Прив’язка, а не розумніша модель, робить агента достатньо безпечним для виходу у виробництво

Розгляньте рекомендаційний та консультативний асистент, який ми побудували в страховому секторі, області, де впевнена неправильна відповідь не є глюком, а відповідальністю. Перший інстинкт у таких випадках – дістати найздатнішу доступну модель та припустити, що здатність купує безпеку. Це не так. Більш виразна модель виробляє більш переконливі галюцинації, які в регульованому контексті гірші, а не кращі.

Тим, що зробило систему придатною для виходу у виробництво, була упряжка: пошукова конструкція, яка витягувала тільки з керованих, безпечних джерел; прив’язка, яка перевіряла згенеровані заяви проти цих джерел до того, як вони досягли користувача; і крок верифікації, який радше утримувався, ніж затверджував щось недопустиме. Результатом стала виміряна зниження галюцинацій на 80-90% проти базової моделі LLM, з точністю прив’язки понад 95%, зберігаючи при цьому суб-двосекундну затримку P95, так що шар безпеки ніколи не робив систему повільною.

Протирічне урок для тих, хто все ще ототожнює безпеку з вибором моделі: шар прив’язки та верифікації є керуванням. Політичні документи та комітети затвердження мають значення, але вони не зупиняють модель від вигадування факту під час висновку. Шар пошuku та верифікації зупиняє. У наших розгортаннях технічний шар прив’язки є справжнім механізмом керування: місце, де “штучний інтелект не повинен вигадувати речі” перестає бути принципом і стає примусовою властивістю системи.

Маршрутизація моделі, а не вибір моделі, визначає вартість штучного інтелекту

Друге місце, де пілотні проекти помирають, – це бюджетний огляд. Система може працювати прекрасно та все одно бути скасованою, коли економіка за токен, помножена на тисячі користувачів та десятки випадків використання, перетворюється на проблему загальної вартості володіння, яку ніхто не моделював заздалегідь.

І тут інстинкт, вибрати одну сильну модель та маршрутизувати через неї все, є помилкою. Більшість корпоративних робочих навантажень являють собою суміш: велика частина запитів є рутинними, а мала частина є справжnio складними. Надсилання кожного запиту до моделі-фронтенду означає сплату фронтендових цін за роботу тріажу, яку менша, дешева модель обробляє цілком добре.

У міграції, яку ми провели з API третього боку LLM на Amazon Bedrock, виграші прийшли від перепроектування шару моделі, а не від заміни моделі. Маршрутизація кожної задачі до відповідного рівня моделі, у поєднанні з контролями вартості та керування Bedrock, дала 42% зниження вартості інфраструктури штучного інтелекту та 60% швидшу генерацію контенту, що відповідає вимогам, без перебудови застосування.

Поширення цього принципу та його підсумки. Тірована “радник” архітектура, дешеві моделі, які тріажують та обробляють більшу частину запитів, моделі-фронтенди, зарезервовані для випадків, які їм真正но потрібні, перетворює маршрутизацію з одноразової економії у структуру.

Цей шаблон знизив вартість корпоративного штучного інтелекту на 60-80% для операцій агентів та на 85% у деяких розгортаннях. Суть не в заголовній процентній ставці; суть у тому, що вартість системи штучного інтелекту визначається її архітектурою, а не тим, яку модель ви обрали.

Чому це невидиме в даних опитування

Нічого з цього не видно чітко в опитуванні, оскільки опитування запитують виконавців про результати, а не інженерів про механізми. “Чи досяг ваш пілотний проект виробництва?” – це питання, на яке виконавець може відповісти. “Що саме привело його туди?” – це питання, на яке тільки команда побудови може відповісти, і відповідь рідко “ми знайшли кращу модель”. Це майже завжди якась версія “ми виправили шар навколо моделі”.

Ця невідповідність пояснює дивну тривалість пастки доведення концепції. Індустрія продовжує діагностувати проблему моделі та купувати рішення моделі, тоді як справжня обмеження сидить у пошuku, прив’язці, маршрутизації та оцінці: у непоказній сантехніці, яку жодна демонстрація не демонструє та жодний запуск моделі не рекламує.

Це також пояснює, чому керування та швидкість доставки не є протилежностями, як їх вважають. Загальний нарратив розглядає керування як гальмо на виході у виробництво. У нашому досвіді це ближче до протилежності: робота прив’язки та верифікації, яка робить систему керованою, є тією ж роботою, яка робить її довіреною достатньо, щоб поставити її перед реальними користувачами. Виконана на рівні упряжки, керування не є тим, що сповільнює побудову. Це те, що дозволяє побудові вийти у виробництво взагалі.

Що це означає, якщо ваш пілотний проект застряг

Якщо у вас є проект зі штучним інтелектом, який сидить у лімузі доведення концепції, найкорисніша річ, яку ви можете зробити, – це опиратися бажанню дивитися на модель спочатку. Модель – це частина, яка найімовірніше вже достатньо хороша. Дивіться замість цього на шар навколо неї:

• Пошук та прив’язка: чи система відповідає з керованих, верифікованих джерел, чи імпровізує з тренувальних даних?
• Верифікація: чи щось перевіряє вивід перед тим, як користувач його побачить, чи впевненість моделі йде прямо?
• Маршрутизація: чи кожен запит платить фронтендові ціни, чи робота відповідна до найбільш дешевої моделі, яка може її добре виконати?
• Оцінка: чи якість вимірюється безперервно проти ваших власних бенчмарків, чи вона була валідована один раз у демонстрації та ніколи знову?

Організації, які переходять від пілотного проекту до виробництва у 2026 році, – це не ті, які мають доступ до найкращих моделей. У всіх їх є. Це ті, хто зрозумів, що модель ніколи не була складною частиною, і хто вклав інженерні зусилля у упряжку, де насправді виграється виробництво.