Риски «долга ИИ» и решения для предприятий
За последние два десятилетия технический долг означал уставшую архитектуру, запутанный код и плохо поддерживаемую документацию. В эпоху искусственного интеллекта это определение уже утратило актуальность, поскольку сбои стали более завуалированными и зачастую нелинейными. Системы ИИ порождают новые пласты технического долга, которые кроются в промптах, моделях и зависимостях данных, из-за чего эти уровни менее заметны, их сложнее измерить, и зачастую они опаснее традиционного долга.
Кризис на виду у всех
Сложности работы систем ИИ и связанные с ними сбои описаны достаточно подробно. Исследование MIT за 2025 год показало, что 95% пилотных проектов в сфере генеративного ИИ не доходят до стадии промышленной эксплуатации или не приносят реальной пользы. Аналогичное исследование S&P Global Market Intelligence выявило, что в 2025 году 42% компаний свернули сразу несколько инициатив в области ИИ — это резкий рост по сравнению с 17% годом ранее. В качестве причин таких неудач называют самые разные факторы, но большинство из них сводится к плохо спроектированным и реализованным системам, которые сложно администрировать и которые имеют множество трудно отслеживаемых точек отказа, что ведет к стремительному накоплению «ИИ-долга».
Традиционный технический долг локализовался в кодовой базе, а баги обычно легко воспроизводились. Следовательно, ошибки можно было без труда выявить в ходе тестов и исправить путем реорганизации кода. Однако долг ИИ распределен гораздо шире: он проявляется в промптах, моделях, конвейерах данных и всей сопутствующей инфраструктуре. Он также носит более спорадический характер: из-за вероятностной природы ИИ системы не всегда реагируют одинаково, что приводит к периодическим сбоям. Из-за этого гораздо сложнее выявлять риски на этапе тестирования, а также возникает потребность в более непрерывном мониторинге даже после развертывания, чтобы предотвратить постепенное отклонение и ухудшение производительности.
Новые формы долга ИИ
Долг ИИ обычно проявляется в четырех новых формах, каждая из которых несет в себе уникальные риски.
Долг промптов — наиболее заметная из них. Представляя собой современную версию «спагетти-кода», он может включать в себя недокументированные изменения запросов, накопившиеся «быстрые исправления», приводящие к несогласованности, заброшенный контроль версий промптов и «набивку промптов» (когда посторонние данные или контекст заталкиваются напрямую в запросы к ИИ). Все это вместе превращает промпты в нетипизированный, нетестируемый код без какого-либо контроля версий, что ведет к повышенной хрупкости и уязвимости.
Долг зависимости от моделей — еще одна набирающая популярность форма ИИ-долга. Большинство предприятий сегодня полагаются на комбинацию внешних моделей, созданных ведущими разработчиками базовых моделей; приложения и агенты строятся поверх вызовов API к этим моделям. В результате логика приложения теперь зависит от моделей, которые находятся за пределами базовой системы и не могут полностью контролироваться. По мере обновления моделей производительность меняется, а воспроизводимость теряется: промпты, настроенные для одной модели, могут давать сбои или работать хуже при переключении на другую модель, будь то обновление от того же или стороннего провайдера.
В большинстве современных корпоративных внедрений ИИ используется дополненная генерация (RAG), которая подтягивает дополнительный контекст из корпоративных репозиториев данных. Долг извлечения данных является следствием того, что в этих хранилищах накапливаются неструктурированные данные, дубликаты документов и устаревшая информация. Из-за этого ИИ выдает технически правильные, но устаревшие и неактуальные ответы, что приводит к сбоям на последующих этапах. В отличие от галлюцинаций, такие ошибки сложнее обнаружить, поскольку формально ответы были верными (возможно, даже еще недавно), а потому они выглядят правильными для любого тестера.
Долг оценки отражает отсутствие стандартизации в тестировании и мониторинге моделей и приложений ИИ. Хотя бенчмарки для ИИ существуют, они, как правило, ориентированы на узкие тесты и отражают результаты лишь в определенный момент времени. Большинству предприятий не хватает последовательных стандартов тестирования, эталонных наборов данных и мониторинга развертываний в реальном времени; аналога непрерывной интеграции и непрерывной доставки (CI/CD) для промптов пока не существует. В результате CIO и CTO не имеют четкого представления о производительности моделей и не могут отслеживать их улучшение или деградацию.
Все это накладывается на традиционные формы технического долга, которые по-прежнему дают о себе знать в инструментах и системах, с которыми взаимодействуют, из которых считывают или в которые записывают данные ИИ-приложения и агенты. Стремительный рост внедрения сгенерированного ИИ кода (часто развертываемого без достаточного тестирования) еще сильнее усугубляет несогласованность и плохую поддерживаемость традиционных кодовых баз.
Новые формы ИИ-долга суммируются с прежними проявлениями технического долга, лавинообразно нарастая и создавая масштабные риски, которые могут привести к катастрофическому отказу целых корпоративных развертываний. Устранение этих рисков осложняется распределенным характером ответственности за ИИ: большинство систем охватывают инженерные, продуктовые, аналитические и бизнес-подразделения, что приводит к размыванию ответственности при обнаружении ошибок.
В результате эти риски выражаются в эскалации затрат на вычисления, неточностях в результатах работы ИИ и росте числа нестандартных ситуаций, требующих вмешательства человека, что часто приводит к застою и провалу проектов из-за неясности окупаемости инвестиций и падения доверия со стороны пользователей.
Как предприятия могут предотвратить ИИ-долг
Долг ИИ не удастся решить с помощью «более совершенных» моделей — показатели сбоев остаются высокими, несмотря на то что модели уже обладают высокой точностью. Решение проблемы ИИ-долга требует более качественного проектирования систем, интеграции, средств контроля и изменения организационной культуры.
Во-первых, к промптам нужно относиться как к коду. Это подразумевает тщательный контроль версий, документирование и строгое тестирование как до, так и после развертывания для всех возможных конфигураций запросов. Лучшие практики из мира традиционного программирования — такие как использование небольших блоков промптов вместо объемных текстов с избытком данных или сокращение применения жестко закодированных параметров — также помогут смягчить проблему ИИ-долга.
Во-вторых, оценка должна быть встроена во весь стек инфраструктуры ИИ. Необходимо наладить конвейеры непрерывной оценки, которые должны отражать самые разные показатели, измеряющие как технические, так и бизнес-метрики. Кроме того, для мониторинга качества результатов, частоты сбоев, дрейфа моделей и данных следует интегрировать системы наблюдаемости ИИ (observability).
В-третьих, прозрачность (объяснимость) должна быть заложена по умолчанию во все результаты работы ИИ, чтобы компенсировать ограниченную воспроизводимость. Происхождение данных (data lineage), используемые модели и пройденные шаги должны быть четко отслеживаемыми, что позволит проводить аудит результатов и вносить исправления в случае любых системных ошибок.
Для этого требуются четкие программы сокращения ИИ-долга и сопутствующие бюджеты, аналогичные прошлым волнам инвестиций в безопасность или облачную модернизацию. Эти процессы должны курироваться на уровне CXO ключевыми руководителями, чтобы в дальнейшем избежать дорогостоящей переработки.
Заключение: Дорога ложка к обеду
Корпоративные развертывания ИИ — это не просто статический код; это живые системы, которые взаимодействуют со всем корпоративным стеком. В результате главной задачей на пути к созданию агентного предприятия станет не создание или развертывание интеллектуальных систем, а их поддержка для обеспечения неизменной надежности в реальных условиях эксплуатации.
Компании, которые стремятся заблаговременно выявлять и минимизировать долг ИИ еще на этапе проектирования, с наибольшей вероятностью создадут устойчивые ИИ-платформы, которые обеспечат значительный долгосрочный прирост производительности всей организации.
Викрам — партнер в Cota Capital, где он инвестирует в компании ранней стадии, занимающиеся корпоративными технологиями и глубокими технологиями (deep tech).
Добро пожаловать в сообщество VentureBeat!
Наша программа гостевых публикаций — это площадка, где технические эксперты делятся инсайтами и представляют нейтральные, непредвзятые обзоры по вопросам ИИ, инфраструктуры данных, кибербезопасности и других передовых технологий, формирующих будущее бизнеса.
Читайте подробнее о нашей программе гостевых постов и ознакомьтесь с нашими правилами, если вы хотите предложить собственную статью!
