Prima di iniziare vorrei ringraziare gli organizzatori del come to code: è bello poter giocare in casa e parlare di qualcosa che mi interessa.
Infatti oggi parleremo di RAG, questo pattern architetturale per l'IA e come interagisce con un altro pattern il Change Data Capture.
Slide di rito: Mi chiamo Giovanni e lavoro per IBM come Senior Software engineer nel dipartimento di java runtimes and integration.
Per integration si intende anche data Streaming e quindi Debezium.
In Debezium sono core team member e ultimamente mi sto occupando di debezium server e dell'engine.
In particolare dell'engine mi occupo anche delle sue emanazioni come le Quarkus Extensions.
Last but not least, sono maintaner dell'opentelemetry sdk per zig
Qui una mia foto con una gallina per abbassare le aspettative che avete per il mio talk di oggi.
Premetto che sono un uomo di principi: preferisco parlare di principi alla base dell'IT perchè tendenzialmente non cambiano mai.
Le tecnologie cambiano, i brand ma i pricipi no.
Infatti inizieremo con parlare un po' di change data capture questo data integration pattern per poi passare ad accenni ai vector database.
A quel punto passeremo all'argomento principe che è rag per poi passare a come debezium risolve delle cose in rag.
Da lì una demo veloce e le conclusioni.
Change data capture è un data integration pattern che ha come scopo quello di catturare l'evoluzione dei cambiamenti dei dati che avvengono in un data source,
nella forma di insert, update e delete per poi inviarli ad un sistema terzo
insert update & deletes, siamo negli anni 90? il CDC come pattern è stato introdotto durante l'esplosione del datawarehouse dove era nata la necessita'
di catturare informazioni da differenti sorgenti e per questo motivo si inventaro tanti modi per farlo come:
- colonne aggiuntive
- database trigger
- audit table
oggi pero' la soluzione preferita è l'utilizzo del CDC log based cioè leggere i cambiamenti al database dal transaction log. I benefici sono molteplici:
- si minimizza l'impatto di performance sulla sorgente di dati
- consistenza nella transazionalita' del sistema poichè il log per definizione risolve la transazionalita' in un sistema concorrente
permettendo di ottenere l'ordine e l'integrita'
ok voi direte: ma ho mongodb in produzione.
Si, anche se il cdc è associato a sistemi convenzionali, quali i database relazionali, CDC è un patter più ad alto livello dove l'idea di fondo è quello di osservare
o propagare i cambiamenti di stato di un sistema nel tempo
e questi cambiamenti di stato cosa sono? Non sono altro che dati: una rappresentazione digitale dell'informazione.
E il dato non è la colonna portante dell'IA che oggi è un onda che ci sta travolgendo e sta trainando la ricerca di nuovi formati e modi di poter
gestire i dati in modo da poter reggere le relative sfide.
e in questo contesto il CDC è il modo più efficiente di muovere dati da un sistema ad un altro facendo delle considerazione sui formati, convenzioni e semantica
che sono d'obbligo in questa costellazione di sistemi eterogenei.
e la semantica è la chiave per definire i vector database
I vector database che rispetto ad un database convenzionale dove il contenuto della base dati contiene una rappresentazione digitale del dato senza una sua rappresentazione semantica, i vector database invece permettono di poter avere nel dato il significato semantico utile per gli llm.
e questo significato semantico è catturato dall'embeddings, questa struttura dati che non è altro che un vettore numerico che contiene l'informazione che permette alle macchine di effettuare comparazioni di concentti similari da un punto di vista semantico invece di una comparazione esatta sul termine come in un full text search
Indexing è il processo di transformazione dei documenti in input in una struttura di ricerca efficiente chiamata indice invertito. Tokenizzi il testo, lo normalizzi ma alla fine vuoi una mappa: una struttura data fortemente ottimizzata che mappa le parole ai loro posting IDs (una lista di document IDs che contengono quel termine).
Nella fase di query ottieni il risultato in maniera efficiente effettuando una semplice intersezione.
In un vector database è concettualmente simile: invece di effettuare una semplice normalizzazione e tokenizazione andiamo a crare gli embeddings,
che dovrebbero riflettere il contenuto del documento. Anche in questo caso si va a creare in fase di indexing questa data structure fortemente ottimizzata per la fase di ricerca che è tipicamente un grafo che può essere navigato in fase di query per individuare rapidamente i vettori più vicini secondo una metrica di distanza o similarità, come la distanza euclidea.
e quando si passa da livello semantico ad un altro, è sempre necessario effettuare una trasformazione che in questo caso è matematica attraverso una funzione chiamata embedding function che va a convertire un dato non strutturato come il testo in un vettore insierito in uno spazio ad alta dimensionalita'
e quando si parla di alta dimensionalita' chiaramente parliamo di llm: otteniamo questa trasformazione tramite un embedding model servito localmente attraverso un inference engine oppure caricato su un server con il quale interagiamo con un inference server oppure con un cloud provider.
quando parliamo di interazione tra entita' stiamo andando a definire uno schema di comunicazione
questo schema di comunicazione tecnicamente viene chiamato pattern e llm in questo caso è l'attore protagonista: negli llm pattern andiamo a definre come gli llm dialognao con :
- sorgenti di informazione
- tools
- utenti
esistono tanti pattern e rag è uno di questi
rag definisce come un llm può ottenere delle informazioni rilevanti per poter arricchire il proprio contesto per poter generare una risposta. Le fasi del pattern sono principalmente due:
- retrieval
- generation
retrieval non è altro che la fase in cui un modello ottiene informazioni rilevati
generation invece è quella in cui viene generata una risposta attraverso queste informazioni
Questo pattern nella sua semplicita' omette tante punti. Uno tra questi è come sia possibile scrivere all'interno della base di dati dell'llm: nel pattern si definisce la lettura ma non la scrittura che puo' avvenire in vari modi, uno tra questi è con la creazione di una pipeline di ingestion.
Questa pipeline di ingestion ha la responsabilita' di caricare di informazioni rilevanti la base di dati del modello che puo' utilizzare nel suo ciclo di vita attraverso dati operazioni da database convenzionali verso database vettoriali.
e per caricare i dati nel database vettoriale deve esserci questa fase di trasformazione negli embeddings per poter effettuare ricerca semantica
il CDC permette di poter effettuare delle data ingestion pipeline che possono copiare dati operativi verso database vettoriali attaverso una fase intermedia di trasformazione
i benefici principali sono sempre quelli del CDC e quindi:
- basso impatto sulla sorgente dati
- la possibilita' di avere la base dati dell'llm aggiornata in near real time
- sincronizzazione consistente tra dati operativi e l'indice dei vettori
- last but not least, ridurre l'indeterminsmo dell'llm ad esempio rimuovendo dati sensibili ottenuti da un database operativo