Un vector database trova ciò che somiglia. Un knowledge graph trova ciò che è collegato. Molti problemi aziendali richiedono entrambi.
La scelta tra le due rappresentazioni viene spesso presentata come alternativa tecnologica. È più utile leggerla come una domanda sul tipo di interrogazioni che il sistema dovrà sostenere, perché è quella a determinare l’architettura.
Come funziona la ricerca per similarità
Un vector database conserva i contenuti in forma numerica. Ogni porzione di documento viene trasformata in una sequenza di numeri che ne rappresenta il significato: contenuti dal senso affine ricevono rappresentazioni vicine tra loro.
Un’analogia quotidiana rende l’idea. Immaginate di collocare ogni paragrafo dei vostri documenti in un enorme spazio, disponendoli in modo che i testi che parlano di cose simili finiscano vicini. Quando arriva una domanda, la si colloca nello stesso spazio e si guarda che cosa le sta intorno.
Da qui derivano le proprietà utili. La ricerca funziona anche quando le parole non coincidono: “recesso anticipato” e “risoluzione del contratto” finiscono vicini. Funziona su archivi molto ampi con tempi di risposta contenuti. E non richiede una classificazione preventiva dei contenuti.
E derivano i limiti. La ricerca restituisce ciò che somiglia, non necessariamente ciò che è corretto. Non distingue tra un documento vigente e uno superato, se nulla nel testo lo segnala. Ed è imprecisa sui riferimenti letterali: un codice articolo o un numero di protocollo si cercano meglio con una ricerca testuale tradizionale, ed è la ragione per cui in ambito aziendale si adottano quasi sempre soluzioni ibride.
Come funziona un grafo di relazioni
Un knowledge graph rappresenta le entità e i legami tra loro. Non conserva testo: conserva affermazioni strutturate.
Il modello è quello dell’elenco di fatti. Il prodotto A monta il componente B. Il componente B è fornito dall’azienda C. La procedura D si applica al prodotto A. La circolare E modifica la circolare F. La società G controlla la società H al sessanta per cento.
La costruzione richiede due decisioni preliminari: quali tipi di entità rappresentare e quali relazioni tracciare. È un lavoro di modellazione, non di indicizzazione, e va fatto con chi conosce il dominio.
Le proprietà utili sono tre. Le risposte sono esatte, perché derivano da relazioni dichiarate e non da somiglianza. È possibile attraversare più passaggi: da un componente risalire a tutti i prodotti che lo montano e da questi a tutti i clienti che li hanno acquistati. E le incoerenze diventano rilevabili, perché una relazione contraddittoria è visibile nella struttura.
I limiti sono altrettanto netti. La costruzione e la manutenzione hanno un costo rilevante. Il grafo copre solo ciò che è stato modellato: una domanda su un aspetto non rappresentato non trova risposta. E non gestisce il linguaggio libero, perché non è un archivio di testo.
Quando la sola similarità fallisce
Il caso tipico è la domanda che richiede di seguire relazioni attraverso più passaggi.
“Quali clienti hanno ricevuto prodotti che montano il componente oggetto della segnalazione di non conformità.”
Una ricerca per similarità recupera i documenti che parlano di quel componente e i documenti che parlano di non conformità. Non collega i due insiemi, perché nessun documento contiene la risposta: la risposta esiste solo come catena di relazioni tra dati distinti.
Lo stesso vale in altri contesti. Ricostruire una catena partecipativa societaria su più livelli. Individuare tutte le circolari che modificano una disposizione, e quali di queste sono a loro volta state modificate. Stabilire quali procedure sono impattate dalla revisione di una norma.
Il criterio generale: se la domanda contiene un “quali… che…” con più di un passaggio, la sola similarità non basta.
Vale anche il contrario. Per domande del tipo “come si esegue questa procedura” o “che cosa prevede la normativa in questo caso”, il grafo non aggiunge nulla e la ricerca semantica è la soluzione appropriata.
Architetture ibride
Nella maggior parte dei progetti reali le due rappresentazioni convivono, con una divisione dei compiti definita.
Il grafo conserva le entità strutturate e le loro relazioni: prodotti, componenti, pratiche, soggetti, norme, versioni. Il vector database conserva i contenuti testuali: manuali, procedure, atti, corrispondenza.
Il collegamento tra i due avviene tramite identificatori: ogni porzione di documento indicizzata riporta a quali entità del grafo si riferisce.
Una domanda complessa viene allora scomposta. Il grafo individua l’insieme di entità rilevanti attraversando le relazioni; la ricerca semantica recupera i contenuti testuali associati a quelle entità; il modello costruisce la risposta su quel materiale, citando le fonti.
Il grafo porta un beneficio ulteriore, spesso decisivo: consente di applicare i filtri di vigenza e di permesso in modo strutturato, invece di dedurli dal testo.
Sul quando adottare l’architettura ibrida, il criterio è pratico. Se le domande previste richiedono di attraversare relazioni, se esiste un dominio con entità stabili e ben identificabili, e se la vigenza o le versioni sono un tema rilevante, il grafo giustifica il suo costo. Altrimenti conviene partire dalla sola ricerca ibrida testuale e semantica, e valutare l’estensione dopo aver osservato le domande reali.
Che cosa nessuna delle due risolve
Nessuna delle due crea informazione assente. Se la relazione tra un componente e un prodotto non è registrata in nessun sistema, il grafo non può rappresentarla.
Nessuna delle due sostituisce la qualità dei dati di origine. Un grafo costruito su anagrafiche incoerenti produce relazioni errate, con l’aggravante che appaiono precise.
E nessuna delle due elimina la valutazione. Il sistema va misurato su casi reali prima del rilascio, qualunque sia la rappresentazione scelta.
In chiusura
La domanda da porre all’inizio non è quale tecnologia adottare, ma quali interrogazioni il sistema dovrà sostenere. Raccogliere venti domande reali dagli utenti previsti è un esercizio di poche ore che determina l’architettura con più affidabilità di qualsiasi valutazione tecnologica astratta.
Se state progettando un sistema di questo tipo, siamo disponibili a un confronto sul vostro caso: quali entità esistono nel vostro dominio, quali relazioni sono già registrate nei sistemi e quali domande dovreste poter porre.
