Come teniamo gli agenti ancorati: ontologie, knowledge graph e zero allucinazioni

Un LLM che inventa non è un'opzione per finanza e legal. Ecco come, con ontologie e knowledge graph, ancoriamo ogni risposta ai dati dell'azienda.

Gli LLM sono fluenti, e la fluenza è pericolosa: un modello afferma una cosa falsa con la stessa sicurezza con cui ne afferma una vera. Dentro una banca o uno studio legale, una risposta plausibile ma sbagliata è peggio di nessuna risposta. Per questo la vera domanda ingegneristica non è mai "quanto è bravo il modello", ma "come gli impediamo di inventare".

Grounding: ogni risposta legata a una fonte

Grounding significa che l'agente non risponde dalla memoria del modello. Risponde dai tuoi documenti e dai tuoi sistemi, e cita da dove viene ogni affermazione. Se non trova un appoggio, lo dice invece di tirare a indovinare. Questa singola regola, rispondere solo da ciò che puoi citare, è la differenza tra una demo e qualcosa che un team regolamentato può davvero usare.

Perché il RAG da solo non basta

Il RAG a vettori recupera passaggi semanticamente simili alla domanda. Aiuta, ma è cieco alla struttura. Non sa che questa clausola appartiene a quel contratto, che vincola questa controparte, la cui obbligazione scade in quella data. Restituisce testo che sembra pertinente, e mette insieme volentieri frammenti che si somigliano ma descrivono cose diverse. La somiglianza non è la verità.

Le ontologie: dare una struttura al dominio

Un'ontologia è un modello formale di un dominio: le entità che esistono (contratto, clausola, obbligazione, controparte, strumento), le loro proprietà e le regole che le collegano. È la differenza tra un mucchio di PDF e un sistema che sa cos'è una controparte e cosa implica un'obbligazione. Quando la logica del dominio è esplicita, un'obbligazione ha una scadenza, una clausola può prevalere su un'altra, uno strumento ha un emittente, estrazione e ragionamento diventano precisi invece che approssimativi.

I knowledge graph: dai documenti a un grafo di fatti

Guidati dall'ontologia, trasformiamo i documenti in un knowledge graph: i nodi sono le entità reali, gli archi le relazioni, e ogni fatto porta con sé il collegamento al passaggio di origine esatto. Così l'agente può percorrere connessioni precise, "quali obbligazioni della controparte X scadono nel terzo trimestre, e in quale contratto", invece di sperare che siano stati recuperati i paragrafi giusti. Ragiona sui fatti, non sulle somiglianze.

Come Hoplo tiene un agente ancorato

• Estrazione guidata dall'ontologia, entità e relazioni vengono estratte rispetto al modello di dominio, non a forma libera.
• Retrieval ibrido, il grafo per la struttura precisa, la ricerca vettoriale per le sfumature, insieme.
• Rispondere solo dal contesto, l'agente è vincolato a ciò che è stato recuperato, con una citazione per ogni affermazione.
• Astenersi, non inventare, se il grafo non sostiene una risposta, l'agente dice "non lo so" o passa la mano a una persona.
• Controlli sui vincoli, le risposte sono validate rispetto alle regole dell'ontologia (una scadenza non può precedere una firma) prima di essere mostrate.
• Audit trail, ogni risposta risale alle sue fonti, così una persona può verificarla in pochi secondi.

Il risultato: risposte verificabili

Il risultato non è un chatbot che suona brillante, ma un agente in cui ogni risposta è ancorata, citata e verificabile. È la base dietro Amaril, il nostro layer di intelligenza per la finanza, e DocZoom, la nostra AI documentale on-premise: i team in ambienti regolamentati si fidano dell'output perché possono risalirne le fonti. Tenere un agente ancorato è ingegneria, non fortuna, un modello esplicito del dominio, un grafo di fatti reali e guardrail che rendono "non lo so" una risposta valida. È così che impediamo agli agenti di allucinare.