I team dati aziendali che trasferiscono l’intelligenza artificiale delle agenzie in produzione stanno raggiungendo un costante punto di fallimento a livello di dati. I broker basati su un archivio vettoriale, un database relazionale, un archivio di grafici e una Lakehouse necessitano di pipeline di sincronizzazione per mantenere aggiornato il contesto. Sotto il peso della produzione, questo contesto diventa stantio.
Oracle, la cui infrastruttura di database gestisce i sistemi di transazione del 97% delle aziende Fortune Global 100, secondo i dati della società, sta ora sostenendo in modo diretto sull’architettura che il database è il posto giusto per risolvere questo problema.
Oracle ha annunciato una serie di annunci questa settimana Funzionalità AI dell’agenzia per Oracle AI DatabaseÈ stato costruito attorno a una controargomentazione architettonica diretta a questo modello.
Il nucleo della versione è Unified Memory Core, un singolo motore di calcolo ACID (Atomicità, Coerenza, Isolamento e Durabilità) che elabora dati vettoriali, JSON, grafici, relazionali, spaziali e colonnari senza un livello di sincronizzazione. Inoltre, Oracle ha annunciato Vector on Ice per l’indicizzazione vettoriale nativa nelle tabelle Apache Iceberg, un servizio autonomo di database vettoriale AI autonomo e un server MCP di database AI autonomo per l’accesso diretto dell’agente senza codice di integrazione personalizzato.
La notizia non è solo che Oracle sta aggiungendo nuove funzionalità, ma riguarda anche il più grande fornitore di database al mondo che si rende conto che le cose stanno cambiando nel mondo dell’intelligenza artificiale e vanno oltre ciò che offre il suo database omonimo.
"Anche se vorrei dire che oggi tutti archiviano tutti i propri dati in un database Oracle, tu ed io viviamo nel mondo reale." Maria Colgan, Vice President of Product Management for Mission Critical Data and AI Engines di Oracle, ha dichiarato: VentureBeat. "Sappiamo che questo non è vero."
Quattro talenti, una scommessa architettonica contro un mucchio di agenti frammentato
La versione di Oracle include quattro funzionalità interconnesse. Insieme, sostengono l’argomentazione architettonica secondo cui un motore di database unificato costituisce una base migliore per l’intelligenza artificiale mediata dalla produzione rispetto a un insieme di strumenti proprietari.
Nucleo di memoria unificato. Gli agenti che ragionano su più formati di dati contemporaneamente (vettoriali, JSON, grafici, relazionali, spaziali) necessitano di pipeline di sincronizzazione quando questi formati risiedono in sistemi separati. Unified Memory Core inserisce tutto in un unico motore di elaborazione ACID. È fondamentalmente un livello API sopra il motore di database Oracle; Ciò significa che la coerenza ACID si applica a ogni tipo di dati senza un meccanismo di coerenza separato.
"Facendo in modo che la memoria risieda nello stesso posto dei dati, possiamo controllare a cosa può accedere, proprio come controlliamo i dati all’interno del database." Ha spiegato Colgan.
Vettori sul ghiaccio. Per i team che utilizzano architetture Data Lakehouse nel formato di tabella open source Apache Iceberg, Oracle ora crea un indice vettoriale all’interno del database che fa direttamente riferimento alla tabella Iceberg. L’indice si aggiorna automaticamente man mano che i dati sottostanti cambiano e funziona con le tabelle Iceberg gestite da Databricks e Snowflake. I team possono combinare la ricerca vettoriale di Iceberg con dati relazionali, JSON, spaziali o grafici archiviati in Oracle in un’unica query.
Database vettoriale AI autonomo. Un servizio di database vettoriale completamente gestito e gratuito, basato sul motore Oracle 26ai. Il servizio è progettato come punto di ingresso per gli sviluppatori che offre un percorso di aggiornamento con un solo clic al database AI autonomo completo quando i requisiti del carico di lavoro aumentano.
Server MCP del database AI autonomo. Consente ad agenti esterni e client MCP di connettersi al database AI autonomo senza codice di integrazione personalizzato. I controlli di accesso a livello di riga e di colonna di Oracle vengono applicati automaticamente quando un agente si connette, indipendentemente da ciò che l’agente richiede.
"Anche se stai effettuando la stessa chiamata API standard che faresti con altre piattaforme, i privilegi che l’utente continua a invocare quando LLM pone queste domande sono:" disse Colgan.
I database vettoriali indipendenti sono un punto di partenza, non una destinazione
L’Autonomous AI Vector Database di Oracle entra in un mercato che include servizi vettoriali appositamente creati come Pinecone, Qdrant e Weaviate. La distinzione tracciata da Oracle riguarda ciò che accade quando il vettore da solo non è sufficiente.
"Una volta che hai finito con i vettori, non hai davvero altra scelta," Steve Zivanic, vicepresidente globale del marketing di prodotto, database e servizi autonomi di Oracle, ha dichiarato a VentureBeat. "Con questo puoi ottenere grafici, spaziali, serie temporali, tutto ciò di cui hai bisogno. Questo non è un vicolo cieco."
Holger Mueller, analista principale di Constellation Research, ha affermato che l’argomentazione relativa all’architettura è certamente credibile perché altri fornitori non saranno in grado di raggiungere questo obiettivo senza prima spostare i dati. Altri fornitori di database richiedono che i dati delle transazioni vengano spostati in un data Lake prima che gli agenti possano utilizzarli. A suo avviso, il patrimonio consolidato di Oracle conferisce un vantaggio strutturale difficile da replicare senza una ricostruzione completa.
Non tutti vedono il set di funzionalità come diverso. Steven Dickens, CEO e principale analista di HyperFRAME Research, ha dichiarato: VentureBeat la ricerca vettoriale, l’integrazione RAG e il supporto Apache Iceberg sono ora requisiti standard nei database aziendali; Postgres, Snowflake e Databricks offrono tutti funzionalità comparabili.
"La mossa di Oracle di etichettare il database stesso come database AI è principalmente un rebranding della sua strategia di database integrato per adattarsi all’attuale ciclo di hype." Dickens ha detto. A suo avviso, la vera differenziazione rivendicata da Oracle è a livello di architettura, non a livello di funzionalità, e l’Unified Memory Core è il punto in cui tale argomento o si regge o si rompe.
Dove le implementazioni degli agenti aziendali si interrompono davvero
Le quattro funzionalità rilasciate da Oracle questa settimana rispondono a una modalità di fallimento della produzione specifica e ben documentata. Le distribuzioni degli agenti aziendali non vengono interrotte a livello del modello. Si guastano a livello di dati, dove gli agenti integrati in sistemi frammentati soffrono di latenza di sincronizzazione, contenuti obsoleti e controlli di accesso incoerenti non appena i carichi di lavoro aumentano.
Matt Kimball, vicepresidente e principale analista di Moor Insights and Strategy, ha dichiarato: VentureBeat Il livello dati è il luogo in cui sorgono innanzitutto i vincoli di throughput.
"La lotta li fa lavorare nella produzione," Kimball ha detto. "Il divario si nota quasi immediatamente a livello di dati (accesso, gestione, latenza e coerenza). Tutte queste diventano restrizioni."
Dickens inquadra la disarmonia fondamentale come un problema asituazionale e situazionale. La maggior parte dei framework di agenti aziendali archiviano la memoria come un elenco semplice di interazioni passate; Ciò significa che gli agenti sono effettivamente stateless mentre i database su cui interrogano sono stateful. Il ritardo tra i due è il punto in cui le decisioni vanno male.
"I team dati sono stanchi della fatica della frammentazione," Dickens ha detto. "Gestire un archivio vettoriale, un database a grafo e un sistema relazionale separati solo per alimentare un agente è un incubo DevOps."
Questa frammentazione è esattamente ciò che Unified Memory Core di Oracle è progettato per eliminare. La questione del piano di controllo segue direttamente.
"In un modello applicativo tradizionale, il controllo risiede nel livello dell’applicazione." Kimball ha detto. "Il controllo degli accessi si interrompe abbastanza rapidamente nei sistemi ad agenti perché gli agenti creano azioni in modo dinamico e necessitano di un’applicazione coerente delle policy. Trasferendo tutto questo controllo al database, tutto può essere implementato in modo più uniforme."
Cosa significa questo per i team dati aziendali?
La questione su dove risieda il controllo nello stack di intelligenza artificiale mediato dall’azienda rimane irrisolta. Molte organizzazioni stanno ancora costruendo su sistemi frammentati e le decisioni architetturali prese ora (quale motore ancora la memoria del broker, dove vengono implementati i controlli di accesso, come i dati Lakehouse vengono inseriti nel contesto del broker) saranno difficili da annullare su larga scala.
Il problema dei dati distribuiti è ancora il vero test.
"I dati sono sempre più distribuiti su piattaforme SaaS, Lakehouse e sistemi basati sugli eventi, ciascuno con il proprio piano di controllo e modello di governance." Kimball ha detto. "Ora l’opportunità è quella di estendere questo modello ai domini di dati più ampi e distribuiti che definiscono molti degli ambienti aziendali odierni."
