I staff dati aziendali che trasferiscono l’intelligenza artificiale in produzione stanno raggiungendo un punto di fallimento costante a livello di dati. Gli agenti basati su un archivio vettoriale, un database relazionale, un archivio di grafici e una Lakehouse richiedono pipeline di sincronizzazione per mantenere aggiornato il contesto. Sotto carico di produzione, quel contesto diventa obsoleto.
Oracle, la cui infrastruttura di database gestisce i sistemi di transazione del 97% delle aziende Fortune International 100 secondo i calcoli dell’azienda stessa, sta ora sostenendo in modo diretto sull’architettura che il database è il posto giusto per risolvere questo problema.
Oracle questa settimana ha annunciato una serie di Funzionalità AI agenti per Oracle AI Databasecostruito attorno a una controargomentazione architettonica diretta a quel modello.
Il nucleo della versione è l’Unified Reminiscence Core, un singolo motore transazionale ACID (Atomicità, Coerenza, Isolamento e Durabilità) che elabora dati vettoriali, JSON, grafici, relazionali, spaziali e colonnari senza un livello di sincronizzazione. Oltre a ciò, Oracle ha annunciato Vector on Ice per l’indicizzazione vettoriale nativa sulle 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 il più grande fornitore di database al mondo che si rende conto che le cose sono cambiate nel mondo dell’intelligenza artificiale e vanno oltre ciò che forniva il suo database omonimo.
“Per quanto mi piacerebbe dirti che oggi tutti archiviano tutti i propri dati in un database Oracle, tu ed io viviamo nel mondo reale”, ha detto Maria Colgan, Vice President, Product Administration for Mission-Crucial Information and AI Engines, presso Oracle VentureBeat. “Sappiamo che non è vero.”
Quattro funzionalità, una scommessa architetturale contro lo stack di agenti frammentato
La versione di Oracle comprende quattro funzionalità interconnesse. Insieme costituiscono la tesi architettonica secondo cui un motore di database convergente costituisce una base migliore per l’intelligenza artificiale degli agenti di produzione rispetto a una serie di strumenti specializzati.
Nucleo di memoria unificato. Gli agenti che ragionano su più formati di dati contemporaneamente (vettoriali, JSON, grafici, relazionali, spaziali) richiedono pipeline di sincronizzazione quando tali formati risiedono in sistemi separati. L’Unified Reminiscence Core li inserisce tutti in un unico motore transazionale ACID. Sotto il cofano c’è un livello API sul motore di database Oracle, il che 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 in cui si trovano i dati, possiamo controllare a cosa ha accesso nello stesso modo in cui controllereremmo i dati all’interno del database”, ha spiegato Colgan.
Vettori sul ghiaccio. Per i staff che utilizzano architetture Information Lakehouse sul formato di tabella open supply Apache Iceberg, Oracle ora crea un indice vettoriale all’interno del database che fa riferimento direttamente 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 staff possono combinare la ricerca vettoriale di Iceberg con dati relazionali, JSON, spaziali o grafici archiviati in Oracle in un’unica question.
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 con un percorso di aggiornamento con un clic al database AI autonomo completo quando i requisiti del carico di lavoro aumentano.
Server MCP del database AI autonomo. Consente agli agenti esterni e ai consumer 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 si applicano automaticamente quando un agente si connette, indipendentemente da ciò che l’agente richiede. “Anche se stai effettuando la stessa chiamata API normal che faresti con altre piattaforme, i privilegi che l’utente ha continuato advert acquisire quando LLM pone queste domande”, ha affermato Colgan.
I database vettoriali autonomi sono un punto di partenza, non una destinazione
L’Autonomous AI Vector Database di Oracle entra in un mercato occupato da servizi vettoriali appositamente realizzati, tra cui Pinecone, Qdrant e Weaviate. La distinzione che Oracle traccia riguarda ciò che accade quando il vettore da solo non è sufficiente.
“Una volta che hai finito con i vettori, non hai davvero altra scelta”, ha detto a VentureBeat Steve Zivanic, Vicepresidente globale, Database e servizi autonomi, Product Advertising and marketing di Oracle. “Con questo, puoi ottenere serie grafiche, spaziali e temporali: tutto ciò di cui potresti aver bisogno. Non è un vicolo cieco.”
Holger Mueller, analista principale di Constellation Analysis, ha affermato che l’argomento architetturale è credibile proprio perché altri fornitori non possono farcela senza prima spostare i dati. Altri fornitori di database richiedono che i dati transazionali vengano spostati in un knowledge Lake prima che gli agenti possano ragionarci sopra. L’eredità convergente di Oracle, a suo avviso, gli conferisce un vantaggio strutturale difficile da replicare senza una ricostruzione da zero.
Non tutti vedono il set di funzionalità come differenziato. Lo ha detto Steven Dickens, CEO e principale analista di HyperFRAME Analysis VentureBeat che la ricerca vettoriale, l’integrazione RAG e il supporto di Apache Iceberg sono ora requisiti normal in tutti i 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 convergente per adattarsi all’attuale ciclo di hype”, ha affermato Dickens. A suo avviso, la vera differenziazione rivendicata da Oracle non è a livello di funzionalità ma a livello di architettura – e l’Unified Reminiscence Core è il luogo in cui story argomento o regge o cade a pezzi.
Dove le distribuzioni degli agenti aziendali effettivamente si interrompono
Le quattro funzionalità fornite da Oracle questa settimana rappresentano una risposta a una modalità di errore di produzione specifica e ben documentata. Le distribuzioni degli agenti aziendali non si interrompono a livello del modello. Si stanno deteriorando a livello di dati, dove gli agenti creati su sistemi frammentati incontrano latenza di sincronizzazione, contesto obsoleto e controlli di accesso incoerenti nel momento in cui i carichi di lavoro aumentano.
Lo ha detto Matt Kimball, vicepresidente e principale analista di Moor Insights and Technique VentureBeat il livello dati è il luogo in cui emergono per primi i vincoli di produzione.
“La difficoltà è farli funzionare in produzione”, ha detto Kimball. “Il divario si nota quasi immediatamente a livello di dati: accesso, governance, latenza e coerenza. Tutti questi diventano vincoli.”
Dickens inquadra il disallineamento fondamentale come un problema di contrapposizione tra stateless e stateful. La maggior parte dei framework di agenti aziendali archiviano la memoria come un elenco semplice di interazioni passate, il che significa che gli agenti sono effettivamente senza stato mentre i database su cui interrogano sono con stato. Il ritardo tra i due è il punto in cui le decisioni vanno male. “I knowledge staff sono esausti a causa della fatica dovuta alla frammentazione”, ha affermato Dickens. “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 Reminiscence 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’app”, ha affermato Kimball. “Con i sistemi advert agenti, il controllo degli accessi viene meno rapidamente perché gli agenti generano azioni in modo dinamico e necessitano di un’applicazione coerente delle coverage. Trasferendo tutto questo controllo nel database, tutto può essere applicato in modo più uniforme.”
Cosa significa questo per i staff dati aziendali
La questione di dove risieda il controllo in uno stack di intelligenza artificiale agente aziendale non è risolta. La maggior parte delle organizzazioni sta ancora costruendo su sistemi frammentati e le decisioni architetturali che vengono prese ora (quale motore ancora la memoria dell’agente, dove vengono applicati i controlli di accesso, come i dati Lakehouse vengono inseriti nel contesto dell’agente) saranno difficili da annullare su larga scala.
La sfida dei dati distribuiti è ancora il vero check. “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”, ha affermato Kimball. “L’opportunità ora è quella di estendere quel modello ai patrimoni di dati più ampi e distribuiti che definiscono oggi la maggior parte degli ambienti aziendali.”
