RAG e knowledge engineering: dalla conoscenza aziendale agli agenti AI

Nei progetti di AI agentiva enterprise, i problemi che emergono più frequentemente in fase di test non riguardano la logica degli agenti né la qualità del modello linguistico. Riguardano la conoscenza: un agente che risponde in modo contraddittorio perché ha trovato due versioni dello stesso documento, uno che non riesce a contestualizzare una richiesta perché non ha accesso ai dati operativi del cliente, uno che cita una policy aggiornata sei mesi fa come se fosse ancora valida.

Questi problemi hanno una causa comune: la knowledge base su cui opera il sistema non è stata progettata con la stessa cura dedicata all’architettura degli agenti.

Vediamo cosa significa costruire una base di conoscenza aziendale adeguata a supportare sistemi agente, come funziona la pipeline RAG che la rende accessibile ai modelli, e perché le scelte fatte in questa fase hanno implicazioni che riguardano anche la governance e la tracciabilità del sistema.

La conoscenza aziendale per alimentare il RAG

La conoscenza aziendale esiste già in quasi tutte le organizzazioni: è distribuita tra documenti di policy, contratti, SLA, manuali operativi, FAQ interne, procedure di processo, e dati strutturati nei sistemi applicativi come CRM, ERP e sistemi di ticketing. Il problema non è la mancanza di conoscenza: è che nella forma in cui esiste oggi quella conoscenza non è accessibile a un agente AI in modo affidabile.

Un modello linguistico non può consultare un documento Word su una cartella di rete, interrogare direttamente un database ERP o navigare una intranet aziendale. Per poterlo fare ha bisogno che quella conoscenza venga trasformata in una forma che può essere recuperata in modo efficiente a partire da una query in linguaggio naturale. Questo processo di trasformazione è ciò che viene chiamato knowledge engineering, e richiede decisioni progettuali che hanno impatto diretto sulla qualità delle risposte degli agenti.

Il primo ordine di decisioni riguarda quali fonti includere e con quale priorità. Non tutta la conoscenza aziendale è ugualmente rilevante per un dato caso d’uso agente, e non tutta è ugualmente affidabile. Una policy approvata dal team legale ha un peso diverso rispetto a una nota informale condivisa su Teams. Una procedura aggiornata tre mesi fa è più affidabile di una versione precedente che non è stata rimossa dai sistemi. Definire le fonti autoritative — quelle la cui versione corrente è la sola che un agente dovrebbe consultare — è un prerequisito per costruire una knowledge base che produca output verificabili.

Il secondo ordine di decisioni riguarda come integrare dati strutturati e non strutturati. La maggior parte dei sistemi RAG gestisce bene documenti testuali. Quello che spesso viene sottovalutato è la necessità di integrare anche dati strutturati e operativi: lo stato di un contratto nel sistema di contract management, la storia degli interventi su un cliente nel CRM, i dati di fatturazione nel sistema billing. Un agente di customer service che non ha accesso a queste informazioni contestuali risponde in modo generico anche quando dispone di un’ottima knowledge base documentale.

La Pipeline RAG: le cinque fasi sequenziali

La Retrieval-Augmented Generation è una tecnica che migliora l’accuratezza delle risposte di un modello linguistico fornendogli, al momento della risposta, i documenti o frammenti di conoscenza più rilevanti per la domanda ricevuta. In luogo di affidarsi esclusivamente a ciò che il modello ha appreso durante l’addestramento — conoscenza statica, con una data di taglio e senza accesso alle informazioni specifiche dell’organizzazione — il sistema recupera in tempo reale le informazioni pertinenti dalla knowledge base aziendale e le include nel contesto della richiesta.

La pipeline che rende possibile questo recupero si articola in cinque fasi sequenziali.

La prima fase è l’ingestion del corpus: i documenti dalle fonti selezionate — file system, SharePoint, Confluence, database, API applicative — vengono raccolti e normalizzati in un formato processabile. In questa fase vengono anche applicate le prime regole di selezione: documenti obsoleti, duplicati o privi di valore informativo per il caso d’uso vengono filtrati prima di entrare nella pipeline.

La seconda fase è il chunking: ogni documento viene suddiviso in frammenti più piccoli e coerenti dal punto di vista semantico. La dimensione e la strategia di chunking hanno un impatto diretto sulla qualità del recupero: frammenti troppo brevi perdono il contesto necessario per essere compresi correttamente; frammenti troppo lunghi diluiscono il segnale rilevante e aumentano il rumore nel contesto fornito al modello. La strategia ottimale dipende dal tipo di contenuto: un contratto legale si chunka in modo diverso rispetto a una FAQ tecnica o a una scheda prodotto.

La terza fase è l’embedding: ogni frammento viene convertito in una rappresentazione numerica vettoriale — un embedding — che cattura il suo significato semantico in uno spazio ad alta dimensionalità. Due frammenti che trattano lo stesso argomento con parole diverse produrranno embedding vicini nello spazio vettoriale; due frammenti su argomenti distinti produrranno embedding lontani. Questa rappresentazione è ciò che permette di cercare per significato piuttosto che per corrispondenza lessicale.

La quarta fase è l’indicizzazione e storage: gli embedding vengono caricati in un vector database — Weaviate, Pinecone, Milvus e simili — insieme ai metadati associati a ogni frammento (fonte, data di aggiornamento, categoria, versione del documento). L’indice vettoriale viene ottimizzato per permettere ricerche di similarità efficienti anche su corpus di grandi dimensioni.

La quinta fase, quella che avviene a ogni richiesta dell’agente, è il recupero e l’augmentation: la query dell’agente viene convertita in embedding con lo stesso modello usato per i documenti, vengono recuperati i frammenti più vicini semanticamente, e questi vengono inclusi nel prompt inviato al modello insieme alla domanda originale. Il modello genera la risposta basandosi sia sulla sua conoscenza pregressa sia sui frammenti recuperati, che costituiscono il contesto specifico e verificabile per quella risposta.

RAG vs Fine-Tuning: quando scegliere uno piuttosto che l’altro

Quando si affronta il problema di specializzare un modello linguistico su conoscenza aziendale specifica, esistono due approcci principali: il RAG e il fine-tuning. Il fine-tuning consiste nell’addestrare ulteriormente il modello su dati aziendali specifici, in modo che quella conoscenza venga incorporata nei parametri del modello stesso. Il RAG, come descritto, recupera la conoscenza esternamente al momento della risposta senza modificare il modello.

Per la maggior parte dei casi d’uso enterprise, il RAG è l’approccio preferibile, per ragioni che riguardano sia i costi che la gestibilità nel tempo. Il fine-tuning richiede dataset di addestramento significativi, competenze tecniche specializzate, infrastruttura di training, e deve essere ripetuto ogni volta che la conoscenza aziendale cambia in modo rilevante. Aggiornare una policy, pubblicare nuovi SLA, inserire un nuovo prodotto nel catalogo: con il fine-tuning ogni cambiamento richiede un nuovo ciclo di addestramento. Con il RAG è sufficiente aggiornare la knowledge base.

Esistono casi in cui il fine-tuning è lo strumento appropriato: quando il dominio richiede un adattamento dello stile e del registro linguistico (ad esempio per sistemi che devono rispettare un tono molto specifico), quando si lavora con terminologia altamente tecnica e specialistica non presente nei dati di preaddestramento del modello, o quando si ottimizza un modello open-source di dimensioni ridotte per un deployment on-premise con risorse limitate. In questi scenari i due approcci possono anche essere combinati: fine-tuning per adattare il modello al dominio, RAG per fornire conoscenza contestuale aggiornata.

Nella pratica dei progetti enterprise, il fine-tuning viene spesso considerato nelle fasi iniziali di valutazione e poi accantonato una volta compresa la complessità operativa che comporta. Costruire una pipeline RAG robusta richiede più lavoro progettuale iniziale, ma produce un sistema significativamente più manutenibile nel medio termine.