Uzņēmuma AI aģenti mūsdienās saskaras ar būtisku laika noteikšanas problēmu: viņi nevar viegli rīkoties kritiskos biznesa notikumos, jo viņi ne vienmēr tos apzinās reāllaikā.
Izaicinājums ir infrastruktūra. Lielākā daļa uzņēmuma datu atrodas datu bāzēs, kuras baro ar ekstrakta-pārveidošanas-slodzes (ETL) uzdevumiem, kas darbojas katru stundu vai katru dienu — galu galā pārāk lēni aģentiem, kuriem jāreaģē reāllaikā.
Viens no iespējamiem veidiem, kā risināt šo izaicinājumu, ir nodrošināt aģentu tiešo saskarni ar straumēšanas datu sistēmām. Viena no galvenajām mūsdienās izmantotajām pieejām ir atvērtais avots Apache Kafka un Apache Flink tehnoloģijas. Uz šīm tehnoloģijām ir balstītas arī vairākas komerciālas ieviešanas, Saplūstošskuru vada sākotnējie veidotāji aiz Kafkas, kas ir viens no tiem.
Šodien Confluent ievieš reāllaika konteksta dzinēju, kas paredzēts šīs latentuma problēmas risināšanai. Tehnoloģija balstās uz Apache Kafka — izplatīto notikumu straumēšanas platformu, kas tver datus notikumu laikā, un atvērtā koda Apache Flink — straumēšanas apstrādes dzinēju, kas šos notikumus pārveido reāllaikā.
Uzņēmums arī izlaiž atvērtā pirmkoda sistēmu Flink Brokers, kas izstrādāta sadarbībā ar Alibaba Cloud, LinkedIn un Ververica. Ietvars nodrošina uz notikumiem balstītas AI aģenta iespējas tieši Apache Flink, ļaujot organizācijām izveidot aģentus, kas pārrauga datu straumes un aktivizējas automātiski, pamatojoties uz apstākļiem, neuzņemoties saistības ar Confluent pārvaldīto platformu.
"Mūsdienās lielākā daļa uzņēmumu AI sistēmu nevar automātiski reaģēt uz svarīgiem notikumiem uzņēmumā, ja kāds tos vispirms nepamudina," Šons Falkoners, Confluenta AI vadītājs, pastāstīja VentureBeat. "Tas noved pie ieņēmumu zaudēšanas, neapmierinātiem klientiem vai papildu riska, ja maksājums neizdodas vai tīkla darbības traucējumi."
Nozīme pārsniedz Confluent specifiskos produktus. Nozare atzīst, ka AI aģentiem ir nepieciešama atšķirīga datu infrastruktūra nekā tradicionālajām lietojumprogrammām. Aģenti ne tikai izgūst informāciju, kad tiek lūgts. Viņiem ir jānovēro nepārtrauktas biznesa notikumu plūsmas un jārīkojas automātiski, kad apstākļi to prasa. Tam nepieciešama straumēšanas arhitektūra, nevis pakešu cauruļvadi.
Partijas pret straumēšanu: kāpēc ar RAG vien nepietiek
Lai izprastu problēmu, ir svarīgi atšķirt dažādas pieejas datu pārvietošanai caur uzņēmuma sistēmām un to, kā tās var izveidot savienojumu ar aģentu AI.
Pakešapstrādē dati uzkrājas avota sistēmās, līdz tiek izpildīts ieplānotais darbs. Šis darbs izvelk datus, pārveido tos un ielādē tos mērķa datu bāzē vai datu noliktavā. Tas var notikt katru stundu, katru dienu vai pat katru nedēļu. Šī pieeja labi darbojas analītiskām slodzēm, taču tā rada latentumu starp brīdi, kad biznesā kaut kas notiek, un brīdi, kad sistēmas var rīkoties atbilstoši tam.
Datu straumēšana apvērš šo modeli. Tā vietā, lai gaidītu ieplānotos darbus, straumēšanas platformas, piemēram, Apache Kafka, fiksē notikumus, tiklīdz tie notiek. Katrs datu bāzes atjauninājums, lietotāja darbība, darījums vai sensora nolasījums kļūst par notikumu, kas publicēts straumē. Pēc tam Apache Flink apstrādā šīs straumes, lai pievienotos, filtrētu un apkopotu datus reāllaikā. Rezultātā tiek apstrādāti dati, kas atspoguļo pašreizējo uzņēmējdarbības stāvokli, un tie tiek pastāvīgi atjaunināti, kad tiek saņemti jauni notikumi.
Šī atšķirība kļūst kritiska, ja ņem vērā, kāda veida konteksts AI aģentiem patiesībā ir nepieciešams. Liela daļa pašreizējo uzņēmumu AI diskusiju ir vērsta uz izguves paplašināto paaudzi (RAG), kas veic semantisko meklēšanu zināšanu bāzēs, lai atrastu atbilstošu dokumentāciju, politiku vai vēsturisko informāciju. RAG labi darbojas tādiem jautājumiem kā "Kāda ir mūsu atmaksas politika?" kur atbilde pastāv statiskajos dokumentos.
Taču daudzos uzņēmumu lietošanas gadījumos ir nepieciešams tas, ko sauc Falconer "strukturālais konteksts" — precīza, atjaunināta informācija no vairākām operētājsistēmām, kas apvienota reāllaikā. Apsveriet iespēju izmantot darba ieteikumu aģentu, kam nepieciešami lietotāja profila dati no HR datu bāzes, pārlūkošanas darbība pēdējā stundā, meklēšanas vaicājumi pirms dažām minūtēm un pašreizējās atvērtās pozīcijas vairākās sistēmās.
"Daļa, ko mēs piedāvājam uzņēmumiem, ir spēja būtībā apkalpot to strukturālo kontekstu, kas nepieciešams, lai nodrošinātu jaunāko versiju," Falconer teica.
MCP savienojuma problēma: novecojuši dati un sadrumstalots konteksts
Izaicinājums nav vienkārši savienot AI ar uzņēmuma datiem. Modeļa konteksta protokols (MCP), ko Anthropic ieviesa šī gada sākumā, jau standartizēja, kā aģenti piekļūst datu avotiem. Problēma ir tā, kas notiek pēc savienojuma izveides.
Lielākajā daļā mūsdienu uzņēmumu arhitektūru AI aģenti, izmantojot MCP, savienojas ar datu ezeriem vai noliktavām, ko baro pa partijas ETL cauruļvadiem. Tas rada divas būtiskas kļūmes: dati ir novecojuši, atspoguļojot vakardienas realitāti, nevis pašreizējos notikumus, un tie ir sadrumstaloti vairākās sistēmās, tāpēc ir nepieciešama ievērojama iepriekšēja apstrāde, lai aģents varētu tos efektīvi apsvērt.
Alternatīva — MCP serveru novietošana tieši pirms operatīvajām datu bāzēm un API — rada dažādas problēmas. Šie galapunkti nebija paredzēti aģentu patēriņam, kas var radīt augstas pilnvaru izmaksas, jo aģenti apstrādā pārmērīgus neapstrādātus datus un vairākas secinājumu cilpas, mēģinot izprast nestrukturētas atbildes.
"Uzņēmumiem ir dati, taču tie bieži ir novecojuši, sadrumstaloti vai bloķēti formātos, kurus mākslīgais intelekts nevar izmantot efektīvi," Falconer paskaidroja. "Reāllaika konteksta dzinējs to atrisina, apvienojot datu apstrādi, atkārtotu apstrādi un apkalpošanu, pārvēršot nepārtrauktas datu plūsmas tiešā kontekstā viedākiem, ātrākiem un uzticamākiem AI lēmumiem."
Tehniskā arhitektūra: trīs slāņi reāllaika aģenta kontekstam
Confluent platforma ietver trīs elementus, kas darbojas kopā vai tiek pieņemti atsevišķi.
Re-time konteksta dzinējs ir pārvaldītais datu infrastruktūras slānis pakalpojumā Confluent Cloud. Notikumu laikā savienotāji pārņem datus Kafka tēmās. Flink jobs apstrādā šīs straumes "atvasinātās datu kopas" — materializēti skati, kas savienojas ar vēsturiskiem un reāllaika signāliem. Klientu atbalstam tas var apvienot konta vēsturi, pašreizējo sesijas darbību un krājumu statusu vienā vienotā konteksta objektā. Dzinējs to atklāj, izmantojot pārvaldītu MCP serveri.
Straumēšanas aģenti ir Confluent patentēta sistēma mākslīgā intelekta aģentu izveidei, kas sākotnēji darbojas uz Flink. Šie aģenti uzrauga datu straumes un aktivizē automātiski, pamatojoties uz nosacījumiem — viņi negaida uzvednes. Ietvars ietver vienkāršotas aģentu definīcijas, iebūvētu novērojamību un vietējo Kloda integrāciju no Anthropic. Tas ir pieejams atvērtā priekšskatījumā Confluent platformā.
Flink aģenti ir atvērtā pirmkoda ietvars, kas izstrādāts ar Alibaba Cloud, LinkedIn un Ververica. Tas nodrošina uz notikumiem balstītas aģenta iespējas tieši Apache Flink, ļaujot organizācijām izveidot straumēšanas aģentus, neizmantojot Confluent pārvaldīto platformu. Viņi paši risina darbības sarežģītību, taču izvairās no pārdevēja bloķēšanas.
Konkurence uzkarst par aģentiem gatavu datu infrastruktūru
Confluent nav vienīgais, kurš atzīst, ka AI aģentiem ir nepieciešama atšķirīga datu infrastruktūra.
Dienu pirms Konfluenta paziņojuma, sāncensis Redpanda ieviesa savu aģentu datu plakni, kas apvieno straumēšanu, SQL un pārvaldību, kas īpaši paredzēta AI aģentiem. Redpanda iegādājās Oxla izplatīto SQL dzinēju, lai aģentiem nodrošinātu standarta SQL galapunktus datu vaicāšanai kustībā vai miera stāvoklī. Platformā ir uzsvērta MCP savienojamība, pilnīga aģentu mijiedarbības novērojamība un tā saucamās darbības "aģenta piekļuves kontrole" ar smalkgraudainiem, īslaicīgiem žetoniem.
Arhitektūras pieejas atšķiras. Confluent uzsver straumes apstrādi ar Flink, lai izveidotu aģentiem optimizētas atvasinātas datu kopas. Redpanda uzsver apvienoto SQL vaicāšanu dažādos avotos. Abi atzīst aģentiem ir nepieciešams reāllaika konteksts ar pārvaldību un novērojamību.
Papildus tiešās straumēšanas konkurentiem Databricks un Snowflake pamatā ir analītiskas platformas, kas pievieno straumēšanas iespējas. To stiprā puse ir sarežģīti vaicājumi lielām datu kopām ar straumēšanu kā uzlabojumu. Confluent un Redpanda to apvērš otrādi: straumēšana ir pamats, jo analītiskā un AI darba slodze ir balstīta uz kustībā esošiem datiem.
Kā straumēšanas konteksts darbojas praksē
Confluent sistēmas lietotāju vidū ir transporta pakalpojumu sniedzējs Busie. Uzņēmums veido modernu operētājsistēmu čarterreisu autobusu kompānijām, kas palīdz tām pārvaldīt cenas, braucienus, maksājumus un vadītājus reāllaikā.
"Datu straumēšana padara to iespējamu," Louis Bookoff, Busie līdzdibinātājs un izpilddirektors pastāstīja VentureBeat. "Izmantojot Confluent, mēs nekavējoties pārvietojam datus starp dažādām mūsu sistēmas daļām, nevis gaidām atjauninājumus vai pakešu pārskatus. Tādējādi viss tiek sinhronizēts un palīdz mums ātrāk piegādāt jaunas funkcijas.
Bookoff atzīmēja, ka tas pats pamats ir tas, kas padarīs gen AI vērtīgu viņa klientiem.
"Mūsu gadījumā katra darbība, piemēram, nosūtīts citāts vai piešķirts draiveris, kļūst par notikumu, kas nekavējoties tiek straumēts caur sistēmu," teica Bookoff. "Šī tiešā informācijas plūsma ļaus mūsu AI rīkiem reaģēt reāllaikā ar zemu latentumu, nevis tikai apkopot jau notikušo."
Tomēr izaicinājums ir, kā izprast kontekstu. Kad sistēmā katru minūti plūst tūkstošiem tiešraides notikumu, AI modeļiem ir nepieciešami atbilstoši, precīzi dati, nepārslogojot.
"Ja dati nav balstīti uz to, kas notiek reālajā pasaulē, AI var viegli izdarīt nepareizus pieņēmumus un, savukārt, veikt nepareizas darbības," teica Bookoff. "Straumes apstrāde to atrisina, nepārtraukti validējot un saskaņojot reāllaika datus ar darbībām Busie."
Ko tas nozīmē uzņēmuma AI stratēģijai
Skonteksta arhitektūra norāda uz būtiskām izmaiņām tajā, kā AI aģenti patērē uzņēmuma datus.
AI aģentiem ir nepieciešams nepārtraukts konteksts, kas apvieno vēsturisko izpratni ar reāllaika izpratni — viņiem ir jāzina, kas notika, kas notiek un kas varētu notikt tālāk, visu uzreiz.
Uzņēmumiem, kas novērtē šo pieeju, sāciet ar lietošanas gadījumu identificēšanu, kad datu novecošanās sabojā aģentu. Krāpšanas atklāšana, anomāliju izmeklēšana un klientu iejaukšanās reāllaikā neizdodas, izmantojot pakešus, kas tiek atsvaidzināti katru stundu vai katru dienu. Ja jūsu aģentiem ir jārīkojas ar notikumiem dažu sekunžu vai minūšu laikā pēc to rašanās, straumēšanas konteksts kļūst nepieciešams, nevis neobligāts.
"Ja veidojat lietojumprogrammas uz pamatu modeļiem, jo tie pēc būtības ir ticami, jūs izmantojat datus un kontekstu, lai virzītu modeli tādā virzienā, kurā vēlaties iegūt kādu rezultātu," Falconer teica. "Jo labāk jūs to varat izdarīt, jo ticamāks un labāks rezultāts."
