Недостающее звено данных в корпоративном ИИ: почему агентам нужен потоковый контекст, а не просто лучшие промпты
Корпоративные ИИ-агенты сегодня сталкиваются с фундаментальной проблемой синхронизации по времени: им трудно оперативно реагировать на критические бизнес-события, поскольку они не всегда узнают о них в реальном времени.
Проблема кроется в инфраструктуре. Большинство корпоративных данных хранится в базах данных, наполняемых с помощью заданий извлечения, трансформации и загрузки (ETL), которые выполняются ежечасно или ежедневно — что в конечном итоге слишком медленно для агентов, которым необходимо реагировать в режиме реального времени.
Один из потенциальных способов решить эту задачу — обеспечить прямой интерфейс между агентами и системами потоковой передачи данных. Среди основных подходов, используемых сегодня, выделяются технологии с открытым исходным кодом Apache Kafka и Apache Flink. Существует также множество коммерческих реализаций на базе этих технологий, включая компанию Confluent, которую возглавляют первоначальные создатели Kafka.
Сегодня компания Confluent представляет движок контекста в реальном времени, разработанный для решения этой проблемы задержек. Технология опирается на Apache Kafka, распределенную платформу потоковой передачи событий, которая захватывает данные по мере их возникновения, и движок потоковой обработки с открытым исходным кодом Apache Flink, который преобразует эти события в реальном времени.
Компания также выпускает фреймворк с открытым исходным кодом Flink Agents, разработанный в сотрудничестве с Alibaba Cloud, LinkedIn и Ververica. Этот фреймворк переносит возможности управляемых событиями ИИ-агентов непосредственно в Apache Flink, позволяя организациям создавать агентов, которые отслеживают потоки данных и автоматически срабатывают на основе заданных условий, не привязываясь к управляемой платформе Confluent.
«Сегодня большинство корпоративных систем искусственного интеллекта не могут автоматически реагировать на важные события в бизнесе без предварительного запроса со стороны человека, — рассказал VentureBeat Шон Фалконер (Sean Falconer), руководитель направления ИИ в Confluent. — Это приводит к потере доходов, недовольству клиентов или дополнительным рискам при сбое платежа или неполадках в сети».
Значение этого шага выходит за рамки конкретных продуктов Confluent. Индустрия осознает, что ИИ-агентам требуется иная инфраструктура данных, чем традиционным приложениям. Агенты не просто извлекают информацию по запросу. Им необходимо наблюдать за непрерывными потоками бизнес-событий и действовать автоматически при наступлении определенных условий. Для этого требуется потоковая архитектура, а не пакетные конвейеры (batch pipelines).
Пакетная обработка против потоковой: почему одного RAG недостаточно
Чтобы понять суть проблемы, важно различать разные подходы к передаче данных через корпоративные системы и то, как они могут подключаться к агентному ИИ.
При пакетной обработке данные накапливаются в исходных системах до запуска запланированного задания. Это задание извлекает данные, преобразует их и загружает в целевую базу данных или хранилище данных. Данный процесс может происходить ежечасно, ежедневно или даже еженедельно. Такой подход хорошо работает для аналитических нагрузок, но создает задержку между моментом происходящего в бизнесе события и моментом, когда системы могут на него отреагировать.
Потоковая передача данных переворачивает эту модель. Вместо ожидания запланированных заданий такие платформы, как Apache Kafka, фиксируют события по мере их возникновения. Каждое обновление базы данных, действие пользователя, транзакция или показание датчика превращаются в событие, публикуемое в потоке. Затем Apache Flink обрабатывает эти потоки, объединяя, фильтруя и агрегируя данные в реальном времени. В результате получаются обработанные данные, отражающие текущее состояние бизнеса и непрерывно обновляющиеся по мере поступления новых событий.
Это различие становится критически важным, если учесть, какой именно контекст действительно необходим ИИ-агентам. Значительная часть текущих обсуждений корпоративного ИИ сосредоточена на генерации с дополненным извлечением (RAG), которая выполняет семантический поиск по базам знаний для нахождения соответствующей документации, политик или исторической информации. RAG отлично справляется с такими вопросами, как «Какова наша политика возврата средств?», когда ответ содержится в статических документах.
Но многие корпоративные сценарии использования требуют того, что Фалконер называет «структурным контекстом» — точной, актуальной информации из нескольких операционных систем, объединенной в реальном времени. Рассмотрим агента по подбору персонала, которому требуются данные профиля пользователя из базы данных отдела кадров, история просмотров за последний час, поисковые запросы минутную давность и текущие открытые вакансии в нескольких системах.
«Мы предоставляем бизнесу возможность по существу формировать этот структурный контекст, необходимый для выдачи самой свежей версии», — отметил Фалконер.
Проблема подключения MCP: устаревшие данные и фрагментированный контекст
Задача заключается не просто в подключении ИИ к корпоративным данным. Протокол контекста модели (Model Context Protocol, MCP), представленный компанией Anthropic в начале этого года, уже стандартизировал способы доступа агентов к источникам данных. Проблема заключается в том, что происходит после установления соединения.
В большинстве современных корпоративных архитектур ИИ-агенты подключаются через MCP к озерям данных (data lakes) или хранилищам, наполняемым пакетными ETL-конвейерами. Это приводит к двум критическим сбоям: данные оказываются устаревшими (они отражают вчерашние реалии, а не текущие события) и фрагментированными между несколькими системами, что требует серьезной предварительной обработки, прежде чем агент сможет эффективно их анализировать.
Альтернатива — размещение серверов MCP напрямую перед операционными базами данных и API — создает другие проблемы. Эти конечные точки не были предназначены для потребления агентами, что может привести к высоким затратам на токены по мере обработки агентами избыточных необработанных данных, а также к множественным циклам инференса при попытке разобраться в неструктурированных ответах.
«У предприятий есть данные, но они часто устарели, фрагментированы или заблокированы в форматах, которые ИИ не может эффективно использовать, — пояснил Фалконер. — Движок контекста в реальном времени решает эту проблему путем унификации обработки, репроцессинга и предоставления данных, превращая непрерывные потоки данных в живой контекст для более умных, быстрых и надежных ИИ-решений».
Техническая архитектура: три слоя для контекста агентов в реальном времени
Платформа Confluent включает в себя три элемента, которые работают совместно или могут применяться по отдельности.
Движок контекста в реальном времени (The real-time context engine) — это управляемый слой инфраструктуры данных на Confluent Cloud. Коннекторы подтягивают данные в топики Kafka по мере возникновения событий. Задания Flink обрабатывают эти потоки в «производные наборы данных» (derived datasets) — материализованные представления, объединяющие исторические и текущие сигналы. Для службы поддержки клиентов это может объединять историю учетной записи, текущее поведение в сеансе и статус инвентаря в один унифицированный объект контекста. Движок предоставляет к нему доступ через управляемый сервер MCP.
Потоковые агенты (Streaming agents) — это проприетарный фреймворк Confluent для создания ИИ-агентов, работающих нативно на Flink. Эти агенты отслеживают потоки данных и срабатывают автоматически в зависимости от условий — они не ждут подсказок. Фреймворк включает в себя упрощенные описания агентов, встроенную наблюдаемость и нативную интеграцию с Claude от Anthropic. Он доступен в формате открытого превью на платформе Confluent.
Flink Agents — это фреймворк с открытым исходным кодом, разработанный совместно с Alibaba Cloud, LinkedIn и Ververica. Он переносит возможности управляемых событиями агентов непосредственно в Apache Flink, позволяя организациям создавать потоковые агенты без привязки к управляемой платформе Confluent. Они самостоятельно справляются с операционной сложностью, но избегают привязки к конкретному вендору.
Усиливается конкуренция за готовую к работе с агентами инфраструктуру данных
Confluent не одинока в понимании того, что ИИ-агентам нужна другая инфраструктура данных.
За день до анонса Confluent ее конкурент Redpanda представила собственную плоскость данных для агентов (Agentic Data Plane), объединяющую потоковую передачу, SQL и функции управления специально для ИИ-агентов. Redpanda приобрела распределенный SQL-движок компании Oxla, чтобы предоставить агентам стандартные конечные точки SQL для запроса данных в движении или в состоянии покоя. Платформа делает акцент на подключении с поддержкой MCP, полной наблюдаемости взаимодействий агентов и том, что она называет «агентским контролем доступа» с мелкомодульными токенами с коротким сроком жизни.
Архитектурные подходы различаются. Confluent делает упор на потоковую обработку с помощью Flink для создания производных наборов данных, оптимизированных для агентов. Redpanda делает акцент на федеративных SQL-запросах по разрозненным источникам. Обе компании признают, что агентам необходим контекст в реальном времени с поддержкой управления и наблюдаемости.
Помимо прямых конкурентов в сфере потоковой передачи, Databricks и Snowflake представляют собой фундаментально аналитические платформы, добавляющие возможности потоковой обработки. Их сильная сторона — сложные запросы к большим наборам данных, где потоковая передача выступает в роли дополнения. Confluent и Redpanda поступают наоборот: потоковая передача является фундаментом, поверх которого строятся аналитические и ИИ-нагрузки.
Как потоковый контекст работает на практике
Одним из пользователей системы Confluent является транспортная компания Busie. Компания создает современную операционную систему для чартерных автобусных компаний, которая помогает им управлять котировками, поездками, платежами и водителями в режиме реального времени.
«Именно потоковая передача данных делает это возможным, — рассказал VentureBeat соучредитель и генеральный директор Busie Луис Букофф (Louis Bookoff). — Используя Confluent, мы мгновенно передаем данные между различными частями нашей системы вместо того, чтобы ждать ночных обновлений или пакетных отчетов. Это поддерживает синхронизацию всего и помогает нам быстрее выпускать новые функции».
Букофф отметил, что эта же основа сделает генеративный ИИ ценным для его клиентов.
«В нашем случае каждое действие, такое как отправленная котировка или назначенный водитель, становится событием, которое немедленно передается через систему, — сказал Букофф. — Этот поток информации в реальном времени позволит нашим ИИ-инструментам реагировать в режиме реального времени с низкой задержкой, а не просто суммировать то, что уже произошло».
Однако проблема заключается в понимании контекста. Когда каждую минуту через систему проходят тысячи живых событий, моделям искусственного интеллекта требуются релевантные и точные данные, чтобы не быть перегруженными.
«Если данные не основаны на том, что происходит в реальном мире, ИИ может легко сделать неверные предположения и, в свою очередь, совершить неверные действия, — подчеркнул Букофф. — Потоковая обработка решает эту проблему путем непрерывной проверки и сопоставления живых данных с активностью в Busie».
Что это значит для стратегии корпоративного ИИ
Архитектура потокового контекста сигнализирует о фундаментальном сдвиге в том, как ИИ-агенты потребляют корпоративные данные.
ИИ-агентам требуется непрерывный контекст, объединяющий историческое понимание с осведомленностью в реальном времени — им нужно знать, что произошло, что происходит и что может произойти дальше, и все это одновременно.
Предприятиям, оценивающим этот подход, стоит начать с выявления сценариев использования, где устаревание данных ломает логику агента. Обнаружение мошенничества, расследование аномалий и оперативное вмешательство в дела клиентов терпят неудачу при использовании пакетных конвейеров, обновляющихся ежечасно или ежедневно. Если вашим агентам необходимо действовать на основе событий в течение секунд или минут после их возникновения, потоковый контекст становится не опциональным, а необходимым.
«Когда вы создаете приложения поверх базовых моделей, поскольку они по своей сути вероятностные, вы используете данные и контекст, чтобы направить модель в нужном направлении для достижения определенного результата, — резюмировал Фалконер. — Чем лучше вы можете это сделать, тем надежнее и лучше будет результат».
