Пересечение разрыва в агентских возможностях ИИ: реалии реализации по всему спектру автономности

Данные недавнего опроса более 1 250 команд разработки раскрывают поразительную реальность: 55,2% планируют построить более сложные агентские рабочие процессы в этом году, но только 25,1% успешно развернули приложения ИИ в производстве. Этот разрыв между амбициями и реализацией подчеркивает критическую проблему отрасли: как мы можем эффективно строить, оценивать и масштабировать все более автономные системы ИИ?

Вместо того, чтобы обсуждать абстрактные определения “агента”, давайте сосредоточимся на практических проблемах реализации и спектре возможностей, который команды разработки преодолевают сегодня.

Понимание рамок автономности

Аналогично тому, как автономные транспортные средства проходят через определенные уровни возможностей, системы ИИ следуют траектории развития, где каждый уровень строится на предыдущих возможностях. Этот шестоуровневый каркас (L0-L5) предоставляет разработчикам практическую основу для оценки и планирования реализации ИИ.

• L0: Правилобазированный рабочий процесс (Последователь) – Традиционная автоматизация с предопределенными правилами и без истинного интеллекта
• L1: Базовый реагировщик (Исполнитель) – Реактивные системы, которые обрабатывают входные данные, но не имеют памяти или итеративного рассуждения
• L2: Использование инструментов (Актор) – Системы, которые активно решают, когда вызывать внешние инструменты и интегрировать результаты
• L3: Наблюдение, планирование, действие (Оператор) – Многоступенчатые рабочие процессы с возможностями самооценки
• L4: Полностью автономный (Исследователь) – Постоянные системы, которые поддерживают состояние и запускают действия независимо
• L5: Полностью творческий (Изобретатель) – Системы, которые создают новые инструменты и подходы для решения непредсказуемых проблем

Текущая реальность реализации: где находятся большинство команд сегодня

Реалии реализации раскрывают резкий контраст между теоретическими рамками и системами производства. Наши данные опроса показывают, что большинство команд все еще находятся на ранних стадиях зрелости реализации:

• 25% остаются на стадии разработки стратегии
• 21% строят доказательства концепции
• 1% тестируют в бета-средах
• 1% достигли развертывания в производстве

Эта распределение подчеркивает практические проблемы перехода от концепции к реализации, даже на более низких уровнях автономности.

Технические проблемы по уровням автономности

L0-L1: Построение основы

Большинство производственных систем ИИ сегодня работают на этих уровнях, с 51,4% команд, разрабатывающих чат-боты для обслуживания клиентов, и 59,7% фокусирующихся на парсинге документов. Основные проблемы реализации на этой стадии – сложность интеграции и надежность, а не теоретические ограничения.

L2: Текущий рубеж

Это то место, где происходит передовая разработка, с 59,7% команд, использующих векторные базы данных для основы своих систем ИИ в фактической информации. Подходы к разработке сильно различаются:

• 2% строят с помощью внутренних инструментов
• 9% используют платформы разработки ИИ третьих лиц
• 9% полагаются исключительно на инженерную разработку подсказок

Экспериментальный характер разработки L2 отражает эволюционирующие лучшие практики и технические соображения. Команды сталкиваются с значительными препятствиями реализации, с 57,4% цитирующих управление зрелищами как свою главную проблему, за которой следует приоритизация случаев использования (42,5%) и пробелы в технической экспертизе (38%).

L3-L5: Препятствия реализации

Даже с существенными достижениями в возможностях моделей, фундаментальные ограничения блокируют прогресс в сторону более высоких уровней автономности. Текущие модели демонстрируют критическое ограничение: они переобучаются на обучающих данных, а не демонстрируют истинное рассуждение. Это объясняет, почему 53,5% команд полагаются на инженерную разработку подсказок, а не на тонкую настройку (32,5%) для руководства выходными данными моделей.

Соображения технического стека

Технический стек реализации отражает текущие возможности и ограничения:

• Мультимодальная интеграция: Текст (93,8%), файлы (62,1%), изображения (49,8%) и аудио (27,7%)
• Поставщики моделей: OpenAI (63,3%), Microsoft /Azure (33,8%) и Anthropic (32,3%)
• Подходы к мониторингу: Внутренние решения (55,3%), инструменты третьих лиц (19,4%), услуги облачного провайдера (13,6%)

По мере роста сложности систем возможности мониторинга становятся все более критическими, с 52,7% команд, активно мониторящих реализации ИИ.

Технические ограничения, блокирующие более высокую автономность

Даже самые совершенные модели сегодня демонстрируют фундаментальное ограничение: они переобучаются на обучающих данных, а не демонстрируют истинное рассуждение. Это объясняет, почему большинство команд (53,5%) полагаются на инженерную разработку подсказок, а не на тонкую настройку (32,5%) для руководства выходными данными моделей. Независимо от того, насколько совершенна ваша инженерия, текущие модели все еще борются с истинным автономным рассуждением.

Технический стек отражает эти ограничения. Хотя мультимодальные возможности растут – с текстом на 93,8%, файлами на 62,1%, изображениями на 49,8% и аудио на 27,7% – лежащие в основе модели от OpenAI (63,3%), Microsoft/Azure (33,8%) и Anthropic (32,3%) все еще работают с теми же фундаментальными ограничениями, которые ограничивают истинную автономность.

Подход к разработке и будущие направления

Для команд разработки, строящих системы ИИ сегодня, из данных вытекают несколько практических выводов. Во-первых, сотрудничество является необходимым – эффективная разработка ИИ предполагает участие инженеров (82,3%), экспертов предметной области (57,5%), команд продукта (55,4%) и руководства (60,8%). Это межфункциональное требование делает разработку ИИ фундаментально отличной от традиционной разработки программного обеспечения.

Оглядываясь на 2025 год, команды ставят амбициозные цели: 58,8% планируют построить более клиентских приложений ИИ, в то время как 55,2% готовятся к более сложным агентским рабочим процессам. Для поддержки этих целей 41,9% фокусируются на повышении квалификации своих команд, а 37,9% строят организационные ИИ для внутренних случаев использования.

Инфраструктура мониторинга также эволюционирует, с 52,7% команд, мониторящих свои системы ИИ в производстве. Большинство (55,3%) используют внутренние решения, в то время как другие используют инструменты третьих лиц (19,4%), услуги облачного провайдера (13,6%) или открытое программное обеспечение для мониторинга (9%). По мере роста сложности систем возможности мониторинга становятся все более критическими.

Техническая дорожная карта

Когда мы смотрим вперед, прогресс к L3 и далее потребует фундаментальных прорывов, а не инкрементальных улучшений. Тем не менее, команды разработки закладывают основу для более автономных систем.

Для команд, строящих более высокие уровни автономности, области фокуса должны включать:

1. Робустные рамки оценки, которые выходят за рамки ручного тестирования для программной верификации выходных данных
2. Улучшенные системы мониторинга, которые могут обнаруживать и реагировать на неожиданное поведение в производстве
3. Шаблоны интеграции инструментов, которые позволяют системам ИИ взаимодействовать безопасно с другими программными компонентами
4. Методы верификации рассуждений для различения истинного рассуждения и сопоставления с образцом

Данные показывают, что конкурентное преимущество (31,6%) и выигрыши в эффективности (27,1%) уже реализуются, но 24,2% команд сообщают, что не наблюдается измеримого воздействия. Это подчеркивает важность выбора подходящих уровней автономности для своих конкретных технических проблем.

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