La realizzazione di sistemi RAG (Access Augmented Manufacturing) per agenti IA spesso implica l’utilizzo di più livelli e tecnologie per dati strutturati, vettori e informazioni grafiche. Negli ultimi mesi è diventato sempre più chiaro che i sistemi di intelligenza artificiale delle agenzie richiedono memoria, a volte chiamata memoria contestuale, per funzionare in modo efficace.
La complessità e la sincronizzazione derivanti dalla presenza di diversi livelli di dati per abilitare il contesto possono portare a problemi di prestazioni e precisione. Questa è una sfida che SurrealDB sta cercando di risolvere.
SurrealDB martedì ha lanciato la versione 3.0 del suo omonimo database con un’estensione di Serie A da 23 milioni di dollari, portando il finanziamento totale a 44 milioni di dollari. L’azienda ha adottato un approccio architettonico diverso rispetto ai database relazionali come PostgreSQL, ai database vettoriali nativi come Pinecone o a un database a grafo come Neo4j. Il team di ingegneri di OpenAI ha recentemente spiegato come hanno scalato Postgres fino a 800 milioni di utenti utilizzando repliche di lettura; Questo è un approccio che funziona per carichi di lavoro pesanti in lettura. SurrealDB adotta un approccio diverso: archivia la memoria dell’agente, la logica aziendale e i dati multimodali direttamente nel database. Invece della sincronizzazione su più sistemi, la ricerca vettoriale, l’attraversamento dei grafici e le query relazionali vengono tutte eseguite a livello transazionale su un singolo motore nativo di Rust, mantenendo la coerenza.
"Le persone utilizzano DuckDB, Postgres, Snowflake, Neo4j, Quadrant o Pinecone tutti insieme e si chiedono perché non riescono a ottenere una buona precisione sui loro broker." Il CEO e co-fondatore Tobie Morgan Hitchcock ha detto a VentureBeat. "Questo perché devono inviare cinque query diverse a cinque database diversi che contengono solo le informazioni o i contenuti a cui sono interessati."
L’architettura ha attirato l’interesse degli sviluppatori, con 2,3 milioni di download e 31.000 stelle GitHub per il database fino ad oggi. Secondo Hitchcock, le implementazioni attuali includono dispositivi all’avanguardia nelle automobili e nei sistemi di difesa, motori di raccomandazione dei prodotti per i principali rivenditori di New York e tecnologie di pubblicazione di annunci Android.
Memoria dell’intelligenza artificiale dell’agenzia aggiunta al database
SurrealDB archivia la memoria dell’agente direttamente nel database come relazioni grafiche e metadati semantici, anziché nel codice dell’applicazione o in livelli di memorizzazione nella cache esterni.
Il sistema di plug-in Surrealism in SurrealDB 3.0 consente agli sviluppatori di definire il modo in cui gli agenti creano ed interrogano questa memoria; La logica viene eseguita all’interno del database con garanzie di transazione piuttosto che nel middleware.
Ciò significa in pratica che quando un agente interagisce con i dati, crea grafici di contesto che collegano entità, decisioni e conoscenza del dominio come record di database. Queste relazioni possono essere interrogate tramite la stessa interfaccia SurrealQL utilizzata per la ricerca vettoriale e i dati strutturati. Un agente che chiede informazioni sul problema di un cliente può attraversare collegamenti grafici a eventi storici rilevanti, estrarre sovrapposizioni vettoriali di casi simili e combinarli con dati strutturati del cliente; può fare tutto questo in un’unica query transazionale.
"Le persone non vogliono più archiviare solo i dati più recenti," disse Hitchcock. "Vogliono archiviare tutti questi dati. Vogliono analizzare e fare in modo che l’intelligenza artificiale comprenda e riveda tutti i dati di un’organizzazione degli ultimi due anni, poiché ciò fornisce ai loro modelli e agli agenti di intelligenza artificiale informazioni dettagliate sul contesto e sulla storia e può quindi fornire risultati migliori."
In cosa differisce l’architettura SurrealDB dagli stack RAG tradizionali?
I sistemi RAG tradizionali interrogano i database in base ai tipi di dati. Gli sviluppatori scrivono query separate per la ricerca di similarità vettoriale, l’attraversamento del grafico e i join relazionali e quindi combinano i risultati nel codice dell’applicazione. Ciò causa ritardi nella sincronizzazione quando le query viaggiano avanti e indietro tra i sistemi.
Al contrario, ha spiegato Hitchcock, SurrealDB memorizza i dati come documenti in codice binario con relazioni grafiche incorporate direttamente accanto ad essi. Attraverso SurrealQL, una singola query può attraversare relazioni tra grafici, eseguire ricerche di somiglianza vettoriale e unire record strutturati senza uscire dal database.
Questa architettura influisce anche sul modo in cui la coerenza funziona su larga scala: ogni nodo mantiene la coerenza delle transazioni anche su una scala di oltre 50 nodi, ha affermato Hitchcock. Quando un broker scrive un nuovo contenuto sul nodo A, una query sul nodo B vede immediatamente quell’aggiornamento. Nessuna memorizzazione nella cache, nessuna copia di lettura.
"La maggior parte dei nostri casi d’uso, la maggior parte delle nostre implementazioni, si verificano in cui i dati vengono costantemente aggiornati e le relazioni, il contesto, la comprensione semantica o le connessioni grafiche tra tali dati devono essere costantemente aggiornati." ha detto. "Quindi niente memorizzazione nella cache. Nessuna copia letta. In SurrealDB, tutto è transazionale."
Cosa significa questo per l’IT aziendale?
"È importante dire che SurrealDB non è il miglior database per ogni attività. Vorrei dire che lo siamo, ma non lo siamo. E non puoi esserlo" disse Hitchcock. "Se hai bisogno solo di analisi su petabyte di dati e non aggiorni mai effettivamente tali dati, è meglio optare per l’archiviazione di oggetti o un database a colonne. Se ti occupi solo della ricerca vettoriale, puoi utilizzare un database vettoriale come Quadrant o Pinecone e questo sarà sufficiente."
Il punto critico si verifica quando sono necessari più tipi di dati insieme. Il vantaggio pratico arriva nelle tempistiche di sviluppo. Ciò che prima richiedeva mesi per essere creato con l’orchestrazione multi-database può ora essere lanciato in pochi giorni, ha affermato Hitchcock.
