Una knowledge base non migliora documenti disordinati
Prima di indicizzare qualsiasi documento, esaminiamo il patrimonio informativo dell’azienda. Questo passaggio è fondamentale perché la qualità delle fonti determina la qualità delle risposte: versioni superate, duplicati, scansioni incomplete e documenti senza una chiara responsabilità editoriale sono tra le cause più comuni di risposte contraddittorie. Un modello non può stabilire autonomamente quale procedura sia ancora valida se l’archivio non contiene questa informazione.
Per questo, per ogni fonte valutiamo:
- formato e qualità del testo estratto;
- versione, data di validità e stato di pubblicazione;
- struttura di titoli, paragrafi, tabelle e allegati;
- reparto, prodotto, cliente o ambito a cui si riferisce;
- livello di riservatezza e gruppi autorizzati alla consultazione;
- frequenza e modalità di aggiornamento.
Questi metadati diventano parte della ricerca. Permettono, per esempio, di limitare la ricerca alle sole procedure pubblicate per una determinata sede, oppure ai manuali relativi alla versione del prodotto indicata dall’utente.
Dal documento all'indice:
scelte che influenzano ogni risposta
I file vengono acquisiti, convertiti e suddivisi in segmenti. Una segmentazione troppo piccola perde il contesto; una troppo ampia introduce informazioni non pertinenti e aumenta il consumo di risorse.
La dimensione ottimale dipende dalla struttura del documento: una procedura, una scheda tecnica e una tabella non vanno trattate allo stesso modo.
Ogni segmento viene rappresentato tramite embedding, una forma numerica che consente di confrontare il significato della domanda con quello dei contenuti. Un database vettoriale, come Qdrant quando adatto all'architettura, permette di recuperare i segmenti più vicini per significato, applicando anche filtri sui metadati.
La sola somiglianza semantica non basta sempre. Codici prodotto, sigle, numeri di norma o termini molto specifici possono beneficiare della ricerca testuale tradizionale. Per questo possiamo combinare ricerca vettoriale e lessicale, per poi riordinare i risultati con criteri aggiuntivi. L'obiettivo non è utilizzare più componenti, ma recuperare le informazioni giuste con il minor rumore possibile.
IL PERCORSO DI UNA DOMANDA
01 – COMPRENSIONE DEL CONTESTO
Il sistema considera domanda, ruolo dell’utente ed eventuale prodotto o pratica corrente.
02 – COSTRUZIONE DELLA RICERCA
La richiesta può essere riscritta o scomposta se contiene più quesiti.
03 – APPLICAZIONE DEI PERMESSI
Le fonti non autorizzate vengono escluse prima del recupero.
04 – SELEZIONE DELLE EVIDENZE
Ricerca e riordinamento individuano i passaggi più pertinenti alla domanda.
05 – GENERAZIONE CONTROLLATA
Il modello risponde usando il contenuto recuperato, seguendo istruzioni coerenti con il caso d’uso.
06 – CITAZIONE
La risposta collega le affermazioni alle pagine o sezioni consultabili dall’utente.
07 – GESTIONE DELL’INCERTEZZA
Se le fonti sono insufficienti o discordanti, il sistema lo dichiara e propone un percorso alternativo.
Un RAG affidabile non dipende
solo dal modello
Le prestazioni di un sistema RAG derivano dall'equilibrio tra architettura, qualità dei dati e processi di gestione. Citazioni verificabili, permessi coerenti, aggiornamento controllato dell'indice e test continui consentono di ottenere risposte affidabili e mantenere il controllo sulla conoscenza aziendale.
Le citazioni delle fonti devono consentire una verifica reale
Mostrare il nome di un documento a fondo pagina non garantisce che supporti la risposta. Conserviamo il legame tra segmento, file, pagina o sezione e lo restituiamo nell’interfaccia. In questo modo l’utente può aprire il punto preciso e controllare il contesto.
Le istruzioni date al modello richiedono di distinguere chiaramente ciò che proviene dalle fonti da eventuali spiegazioni aggiuntive. Nei casi in cui la tracciabilità è essenziale, la risposta può essere limitata alle sole informazioni esplicitamente supportate dai documenti. Se due documenti validi sono in conflitto, il sistema non dovrebbe scegliere in autonomia e senza segnalarlo, quale seguire.
Questo comportamento aumenta la fiducia e rende più semplice correggere l’archivio. Una risposta incompleta può rivelare che manca un contenuto; una risposta discordante può evidenziare una procedura non aggiornata.
I permessi devono seguire l'utente fino alla ricerca
Nascondere un documento nell’interfaccia ma lasciarlo comunque disponibile all’indice non è sufficiente. L’autorizzazione deve essere applicata già durante il recupero delle informazioni, prima che il testo raggiunga il modello. Possiamo integrare ruoli, reparti, organizzazioni o permessi provenienti dall’applicazione esistente.
In scenari multi-azienda, i dati di ciascun cliente devono rimanere isolati anche nella cache, nei log e nei processi di indicizzazione. Nei sistemi interni, invece, una procedura generale può essere condivisa mentre contratti e pratiche restano visibili solo agli utenti autorizzati.
Aggiornare l'indice senza perdere il controllo
Una base di conoscenza è utile se riflette lo stato attuale delle fonti. Per questo progettiamo il ciclo di inserimento, modifica e rimozione dei contenuti: il sistema identifica i documenti cambiati, aggiorna i segmenti interessati e impedisce che una versione eliminata continui a comparire nelle risposte.
È possibile prevedere anche una fase di approvazione prima dell’indicizzazione, stati di “bozza” e “pubblicato”, una pianificazione degli aggiornamenti e un registro degli errori. Per grandi archivi, l’elaborazione avviene in coda e può riprendere dopo un’interruzione senza ricominciare tutto.
Anche il modello di embedding, le regole di segmentazione e la struttura dei metadati vengono versionati. Se cambiano, pianifichiamo una nuova indicizzazione e confrontiamo i risultati prima di sostituire l’indice in uso.
Valutare separatamente ricerca e risposta
Quando una risposta risulta errata, occorre capire se il problema è nella ricerca (il sistema non ha trovato la fonte) o nella generazione (il modello l’ha interpretata male). Prepariamo un insieme di domande rappresentative con documenti attesi, gli elementi che la risposta deve contenere e casi in cui non esiste una risposta.
Per la ricerca misuriamo se i passaggi utili compaiono tra i risultati e quanto contenuto irrilevante viene recuperato. Per la generazione valutiamo aderenza alle fonti, completezza, correttezza delle citazioni e capacità del sistema di non rispondere senza evidenze.
Il gruppo di test include formulazioni diverse della stessa domanda, termini interni, domande ambigue, versioni di prodotto diverse e tentativi di accedere a contenuti non autorizzati. Questo set viene riutilizzato quando cambiano modelli, prompt o indice, così le decisioni non dipendono da impressioni occasionali.
Dove un RAG
può produrre valore
Ogni scenario ha una propria soglia di rischio, un proprio livello di profondità della risposta e una diversa necessità di intervento umano. Non esiste una configurazione RAG valida per ogni archivio.
ASSISTENZA tecnica
Consulta manuali e bollettini relativi al prodotto corretto
OPERATORI
Cercano una procedura interna e ne verificano la versione
NUOVI COLLABORATORI
Interrogano documentazione autorizzata durante l'inserimento in azienda
CLIENTI
Trovano risposte nella propria area riservata, senza vedere contenuti altrui
UFFICI COMMERCIALI
Recuperano caratteristiche e condizioni da fonti approvate
SOFTWARE ESISTENTI
Aggiungono ricerca semantica e risposta documentale tramite API