Агентные ИИ-системы становятся частью рабочих процессов: они анализируют данные, взаимодействуют с пользователями и автоматизируют рутинные операции. Но в реальных условиях их работа часто ограничивается не моделью, а техническими узкими местами — прежде всего инфраструктурой. В статье разбираем, почему доступ к данным важнее параметров модели, как устроены современные архитектуры под ИИ и что нужно менять, чтобы системы действительно работали в продакшене, а не оставались демонстрацией возможностей.
Агентный ИИ без инфраструктуры
Компании уже научились обучать ИИ под конкретные задачи. У них есть мощные модели, заточенные под бизнес-процессы, отрасли, сценарии принятия решений. Но когда дело доходит до практики, выясняется, что модель — не главное. Главная проблема — в инфраструктуре, которая должна поставлять данные быстро, стабильно и в нужном объеме. Без этого агентный ИИ остается изолированной схемой, способной только имитировать работу.
«Сегодня компании стремятся обучать ИИ под конкретные задачи. Но без гибкого, управляемого и разрешенного потока данных агентный ИИ работать не сможет», — сообщает Стюарт Эбботт, управляющий директор Vast Data в Великобритании и Ирландии. И с этим сложно спорить: никакой интеллект не может принять решение, если он не знает, на чем оно должно быть основано.
По сути, агентный ИИ — это система, которая действует самостоятельно, получает команды, анализирует окружение и выбирает, что делать дальше. Но для этого ей нужен постоянный, оперативный доступ к данным. Причем не просто «в теории возможный», а согласованный, безопасный и масштабируемый.
Суть проблемы — в инфраструктуре. Чтобы агент действительно работал, одной модели недостаточно. Нужен живой, надежный канал к данным, причем: в режиме реального времени, с возможностью масштабирования, а также в рамках прозрачных и соблюдаемых политик доступа.
В отчете The State of AI in 2025 эксперты McKinsey подчеркивают: большинство компаний по-прежнему используют фрагментированные архитектуры, в которых данные разложены по системам, интеграции несовместимы, а процессы обмена работают с перебоями. Даже если модель укомплектована, ее невозможно встроить в операционный контур — она остается на периферии.
Эбботт формулирует три базовых условия, без которых нормальная работа агентной системы невозможна. Первое — скорость. Если модель ждет данные дольше, чем нужно для принятия решения, никакой автоматизации не получится. Второе — масштаб. Инфраструктура должна выдерживать рост: больше агентов, больше данных, больше сценариев. Третье — доверие. Результаты ИИ можно использовать в бизнесе только тогда, когда ясно, откуда пришли данные и кто имел на них доступ.
Сейчас даже крупные компании признают: в нужный момент у ИИ просто нет доступа к актуальной информации. В результате агент, который должен был упростить процесс, только усложняет его или не используется вовсе.
Пока эта проблема не решена, агентный ИИ останется концептом. Чтобы он начал работать вживую, нужно перестроить сам подход к работе с данными — и сделать это не на уровне красивых дашбордов, а в архитектуре.
RAG: скорость или торможение?
Большинство корпоративных ИИ-систем сегодня строятся по принципу RAG — Retrieval-Augmented Generation. Модель не хранит все знания у себя, а при каждом запросе подтягивает внешние данные: документы, базы, контекст. Это дает более точный и свежий результат, особенно в тех сценариях, где важно учитывать внутренние источники информации.
Но у подхода есть издержки. Каждый запрос запускает цепочку действий: система ищет документ, проверяет доступ, извлекает нужный фрагмент и только после этого формирует ответ. Если хотя бы один элемент работает нестабильно — вся система замедляется.
RAG чувствителен к качеству инфраструктуры. Задержка на стороне хранилища, неактуальные данные, неоптимальные политики доступа — все это бьет по скорости и надежности. ИИ может быть обучен хорошо, но если он не успевает добраться до нужной информации, его эффективность стремительно падает. Это особенно критично в задачах, где важна скорость — в клиентском сервисе, в аналитике, в операционной автоматизации.
В некоторых случаях задержка между токенами может достигать 11 секунд — слишком долго, чтобы на выходе получать оперативный результат.
В таких условиях даже быстрая модель на мощном железе не спасает. GPU не могут компенсировать проблемы в потоке данных. Задержки в ответах накапливаются, и агентная система, призванная ускорить бизнес-процессы, начинает их тормозить.
Как улучшить работу ИИ-агентов
Чтобы агентные ИИ-системы реагировали быстро и работали стабильно под нагрузкой, недостаточно просто обучить модель. Основное ограничение сегодня — не в параметрах нейросети, а в скорости доступа к информации. И здесь критична не только пропускная способность железа, но и то, как организован сам процесс извлечения контекста.
Ускорение начинается с устранения задержек на этапе инференции — особенно в тех точках, где модель постоянно обращается к одним и тем же данным. Уже сейчас появляются технологии, которые позволяют это сделать:
KV-caching (кэширование ключ-значение)
Модель не пересчитывает каждый раз одни и те же фрагменты, а запоминает уже обработанный контекст. Это особенно важно в чатах и повторяющихся задачах — например, когда агент несколько раз обращается к одной и той же базе или формирует типовые ответы.
vLLM
Это оптимизированная инфраструктура инференции, разработанная специально под языковые модели. Позволяет эффективно обрабатывать длинные контексты, параллелить запросы и снижать задержки без потери производительности.
На практике это значит, что один сервер может обслуживать большее количество одновременных пользователей, сохраняя стабильную скорость отклика.
LMCache
LMCache — расширение для серверной части, позволяющее кэшировать не только входные данные, но и уже сгенерированные фрагменты текста — от типовых подсказок до целых блоков. Повторное использование таких фрагментов снижает нагрузку на модель и ускоряет ответ.
GPU Direct Storage
Новая технология от Nvidia позволяет передавать данные напрямую из хранилища в память видеокарты, минуя процессор. Это критично при работе с объемными или неструктурированными наборами данных — например, PDF-архивами, логами, технической документацией. С помощью инструмента сокращается один из самых медленных этапов цепочки, и модель быстрее начинает обработку.
Сочетание этих решений позволяет снизить время до первого токена — то есть момент, когда ИИ начинает формировать ответ — с 8–11 секунд до 1,5 секунды и ниже.
Старые системы — главный враг быстрого ИИ
Однако данные — не единственная проблема качества работы ИИ-агентов, многие компании до сих пор используют устаревшие подходы и технологии. Среди них: традиционные ETL-конвейеры (извлечение, преобразование, загрузка), разрозненные векторные базы данных и статичный контроль доступа без гибкой авторизации.
По данным Gartner, 61% организаций вынуждены пересматривать архитектуру данных и аналитики из‑за ИИ, а 38% планируют полностью перестроить свою D&A‑архитектуру в ближайшие 12–18 месяцев
Такие решения не готовы к требованиям современных ИИ-агентских систем, потому что в них отсутствует поддержка семантического поиска в реальном времени, идентификационно-привязанный доступ и многошаговый вывод при высокой частоте запросов.
Будущее: инфраструктура, ориентированная на ИИ
Сегодня от ИИ ждут не генерации текста, а участия в реальных процессах — от анализа данных до принятия решений. Но без быстрой, прозрачной и устойчивой инфраструктуры эта задача не решается. Модель может быть обучена на миллиардах токенов, но если она ждет данные по 10 секунд — она бесполезна.
Компании переходят к архитектуре, где хранилище, вычисления и доступ к данным работают как единая система. Такой подход позволяет запускать ИИ-агентов в продакшен, а не в демо. В отчете Google Cloud за 2025 год 45 % опрошенных компаний подтвердили, что уже строят инфраструктуру, где обучение, инференс и работа с данными связаны в единую платформу.
На практике это дает понятный результат: меньше задержек, стабильная работа под нагрузкой, предсказуемое поведение моделей. Все это напрямую влияет на производительность ИИ-систем, а значит — на скорость процессов и качество решений в бизнесе.
Для того, чтобы ИИ-агенты работали в связке с сотрудниками уже сейчас нужно:
- Проверить, сколько времени проходит между запросом и первым токеном. Если больше 2–3 секунд — инфраструктура не справляется.
- Оптимизировать поток данных. Использовать KV-кэши, LMCache, vLLM, GPU Direct Storage — в зависимости от задач.
- Строить архитектуру не по слоям, а как цельный механизм. Учитывать, как данные двигаются, где происходят задержки, и как это отражается на реакции ИИ.
- Держать под контролем доступ и обновляемость данных. Если информация устарела или недоступна — агент не будет работать так, как нужно.
Пока эти условия не выполняются, ИИ остается ограниченным в своих возможностях. Не из-за модели, а из-за того, как она встроена в инфраструктуру.