Home Tecnologia SurrealDB 3.0 vuole sostituire il tuo stack RAG di cinque database con...

SurrealDB 3.0 vuole sostituire il tuo stack RAG di cinque database con uno

13
0

La creazione di sistemi RAG (retrieval-augmented technology) per agenti IA spesso comporta 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 advert agenti necessitano di memoria, a volte definita 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. È una sfida che SurrealDB sta cercando di risolvere.

SurrealDB martedì ha lanciato la versione 3.0 del suo omonimo database insieme a un’estensione di Serie A da 23 milioni di dollari, portando il finanziamento totale a 44 milioni di dollari. L’azienda aveva 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 workforce di ingegneri di OpenAI ha recentemente spiegato in dettaglio come è riuscito a scalare Postgres fino a raggiungere 800 milioni di utenti utilizzando repliche di lettura, un approccio che funziona per carichi di lavoro advert alta intensità di lettura. SurrealDB adotta un approccio diverso: archivia la memoria dell’agente, la logica aziendale e i dati multimodali direttamente all’interno del database. Invece di sincronizzarsi su più sistemi, la ricerca vettoriale, l’attraversamento dei grafici e le question relazionali vengono eseguite tutte a livello transazionale in un unico motore nativo di Rust che mantiene la coerenza.

“Le persone utilizzano DuckDB, Postgres, Snowflake, Neo4j, Quadrant o Pinecone tutti insieme, e poi si chiedono perché non riescono a ottenere una buona precisione nei loro agenti”, ha detto a VentureBeat il CEO e co-fondatore Tobie Morgan Hitchcock. “È perché devono inviare cinque question numerous a cinque database diversi che hanno solo la conoscenza o il contesto di cui si occupano.”

L’architettura ha incontrato il favore degli sviluppatori, con 2,3 milioni di obtain e 31.000 stelle GitHub fino advert oggi per il database. Secondo Hitchcock, le implementazioni esistenti spaziano dai dispositivi edge nelle automobili e nei sistemi di difesa, ai motori di raccomandazione dei prodotti per i principali rivenditori di New York e alle tecnologie di pubblicazione di annunci Android.

Memoria AI agentica inserita nel database

SurrealDB archivia la memoria dell’agente come relazioni grafiche e metadati semantici direttamente nel database, non nel codice dell’applicazione o nei livelli di memorizzazione nella cache esterni.

Il sistema di plugin Surrealism in SurrealDB 3.0 consente agli sviluppatori di definire come gli agenti costruiscono ed interrogano questa memoria; la logica viene eseguita all’interno del database con garanzie transazionali piuttosto che nel middleware.

Ecco cosa significa in pratica: quando un agente interagisce con i dati, crea grafici di contesto che collegano entità, decisioni e conoscenza del dominio come document di database. È possibile interrogare queste relazioni 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 le connessioni grafiche agli incidenti passati correlati, estrarre incorporamenti di vettori di casi simili e unirsi ai dati strutturati del cliente, il tutto in un’unica question transazionale.

“Le persone non vogliono più archiviare solo i dati più recenti”, ha affermato Hitchcock. “Vogliono archiviare tutti quei dati. Vogliono analizzare e fare in modo che l’IA comprenda ed esegua tutti i dati di un’organizzazione negli ultimi due anni, perché questo informa il loro modello, il loro agente AI sul contesto, sulla storia, e può quindi fornire risultati migliori.”

In che modo l’architettura di SurrealDB differisce dagli stack RAG tradizionali

I sistemi RAG tradizionali interrogano i database in base ai tipi di dati. Gli sviluppatori scrivono question separate per la ricerca di similarità vettoriale, l’attraversamento del grafico e i be a part of relazionali, quindi uniscono i risultati nel codice dell’applicazione. Ciò crea ritardi di sincronizzazione poiché le question vanno avanti e indietro tra i sistemi.

Al contrario, Hitchcock ha spiegato che SurrealDB memorizza i dati come documenti con codifica binaria con relazioni grafiche incorporate direttamente accanto advert essi. Una singola question tramite SurrealQL può attraversare relazioni tra grafici, eseguire ricerche di somiglianza vettoriale e unire document strutturati senza uscire dal database.

Questa architettura influisce anche sul modo in cui la coerenza funziona su larga scala: ogni nodo mantiene la coerenza transazionale, anche su scala di oltre 50 nodi, ha affermato Hitchcock. Quando un agente scrive un nuovo contesto sul nodo A, una question sul nodo B vede immediatamente quell’aggiornamento. Nessuna memorizzazione nella cache, nessuna duplicate di lettura.

“Molti dei nostri casi d’uso, molte delle nostre implementazioni prevedono che i dati siano costantemente aggiornati e le relazioni, il contesto, la comprensione semantica o le connessioni grafiche tra tali dati debbano essere costantemente aggiornati”, ha affermato. “Quindi niente memorizzazione nella cache. Non ci sono repliche di lettura. In SurrealDB, ogni singola cosa è transazionale.”

Cosa significa questo per l’IT aziendale

“È importante dire che SurrealDB non è il miglior database per ogni attività. Mi piacerebbe dire che lo siamo, ma non lo è. E non puoi esserlo”, ha detto Hitchcock. “Se hai solo bisogno di analisi su petabyte di dati e non li aggiorni mai realmente, allora sarà meglio utilizzare l’archiviazione di oggetti o un database a colonne. Se hai a che fare solo con la ricerca vettoriale, puoi utilizzare un database vettoriale come Quadrant o Pinecone, e questo sarà sufficiente.”

Il punto di flesso arriva quando sono necessari più tipi di dati insieme. Il vantaggio pratico si manifesta nelle tempistiche di sviluppo. Ciò che prima richiedeva mesi per essere realizzato con l’orchestrazione multi-database ora può essere lanciato in pochi giorni, ha affermato Hitchcock.

fonte

LEAVE A REPLY

Please enter your comment!
Please enter your name here