Un prototipo di RAG può essere assemblato rapidamente: alcuni documenti, un indice vettoriale, un modello di linguaggio e un'interfaccia di conversazione. Le prime dimostrazioni impressionano quando il sistema recupera un'informazione precisa. Esse dicono poco sul suo comportamento di fronte a documenti contraddittori, ai diritti, agli aggiornamenti, alle domande ambigue e alle migliaia di utenti.
Passare alla produzione consiste nel trasformare questa catena in un servizio governato. Il sistema deve sapere quali fonti utilizza, spiegare le sue risposte, misurare i suoi errori, proteggere i dati e funzionare anche quando uno dei suoi componenti rallenta.
Definire la promessa e i limiti
Un assistente documentale non deve essere descritto come capace di « rispondere a tutto ». La promessa deve precisare:
- corpi coperti ;
- popolazioni autorizzate ;
- tipi di domande ;
- livello di freschezza ;
- lingua ;
- decisioni che restano umane;
- comportamento fuori perimetro;
- prove attese.
Una promessa limitata, come ritrovare e sintetizzare le procedure interne con citazioni, è più testabile di un assistente esperto generalista.
Costruire un inventario di fonti
Ogni fonte possiede un proprietario, un livello di sensibilità, una data, una versione, una lingua e una regola di conservazione. I documenti obsoleti, bozza o duplicati devono essere identificati prima dell'indicizzazione.
Il sistema deve conservare la provenienza fino al passaggio utilizzato: identificativo del documento, versione, sezione, diritti e data e ora. Senza questa tracciabilità, una citazione visiva non garantisce che la risposta si basi sulla fonte corretta.
Progettare l’ingestione come una pipeline di dati
L'ingestione non si limita a estrarre testo. Deve:
- recuperare il contenuto in modo autenticato;
- rilevare il formato e gli errori;
- estrarre struttura, tabelle e metadati;
- normalizzare senza cancellare il senso;
- tagliare ;
- arricchire ;
- indicizzatore ;
- convalidare ;
- gestire aggiornamento e cancellazione.
Ogni fase è idempotente e osservabile. Un errore su un file non blocca l'intero lotto, ma è visibile e attribuito.
Il montaggio influenza la risposta
Un frammento troppo corto perde le definizioni e le eccezioni. Un frammento troppo lungo diluisce i termini utili e consuma il contesto. La suddivisione deve seguire la struttura: titoli, paragrafi, articoli, procedure, tabelle e allegati.
I metadati del genitore sono mantenuti. Per alcune domande, un passaggio recuperato deve essere arricchito dal suo titolo, dalla sua sezione o dai paragrafi vicini. Diverse strategie possono coesistere a seconda del tipo di documento.
Combinare i metodi di ricerca
La ricerca vettoriale trova le formulazioni simili. Il testo completo resta superiore per riferimenti, nomi, acronimi e citazioni esatte. I filtri strutturati applicano lingua, data, tipo, entità e diritti.
Una catena robusta può combinare:
- candidati lessicali;
- candidati vettoriali;
- fusione dei ranghi;
- riordinamento
- diversificazione ;
- soglia di pertinenza;
- recupero del contesto vicino.
La sofisticazione ha valore solo se migliora un vero gioco di domande.
I diritti devono intervenire prima della generazione
Un utente non deve venire a sapere dell’esistenza di un documento vietato tramite un estratto, una citazione o una risposta. I permessi devono essere riprodotti nell’indice o applicati durante il recupero, con una strategia affidabile di aggiornamento.
Un filtraggio dopo il recupero può fallire quando i primi risultati sono vietati. Il motore deve cercare abbastanza candidati autorizzati. Le cache sono segmentate per politica, non solo per testo della query.
Costruire un gioco di valutazione prima di ottimizzare
Un gioco utile contiene domande frequenti, rare, ambigue, fuori ambito, contraddittorie e sensibili. Per ogni caso, si conservano le fonti di riferimento e gli elementi che una buona risposta deve includere.
È necessario valutare separatamente:
- recupero : i passaggi corretti sono stati trovati?
- generazione : la risposta rispetta i passaggi?
- citazione : le referenze supportano davvero l'affermazione?
- utilità: la risposta aiuta a completare il compito?
- rifiuto : il sistema sa non rispondere?
Ciclo di miglioramento di un RAG basato su un insieme di domande, l'analisi degli errori e i test di regressione.
Progettare una risposta basata sulle prove
Il prompt di generazione deve ricordare il perimetro, imporre l'uso del contesto e richiedere un rifiuto quando mancano gli elementi. Deve distinguere citazione, ragionamento e suggerimento.
Una risposta può indicare:
- sintesi;
- fonti utilizzate;
- data o versione ;
- punti incerti ;
- azione seguente;
- limite del sistema.
Le citazioni devono rimandare al passaggio consultabile dall’utente, nel rispetto dei suoi diritti. Un collegamento a un documento di cento pagine senza indicazione della posizione non è sufficiente.
Gestire le fonti contraddittorie
Due procedure possono contraddirsi perché una versione è vecchia, perché riguardano ambiti diversi o perché esiste un errore. Il RAG non deve arbitrare silenziosamente.
La strategia può favorire la versione in vigore, segnalare la divergenza, citare le due fonti e invitare a una validazione. Le regole di priorità sono documentate e testate.
Sapere dire di no
Il sistema rifiuta quando il corpo non contiene prove sufficienti, quando la domanda è vietata, quando richiede una decisione al di fuori della responsabilità o quando i diritti non consentono di rispondere.
Un rifiuto utile spiega il limite e propone una via sicura: riformulare, scegliere un perimetro, consultare una fonte o contattare un responsabile. Non inventa una risposta generica per riempire il vuoto.
Proteggere contro le istruzioni contenute nei documenti
Un documento può contenere una frase che chiede al modello di ignorare le regole o di estrarre informazioni. Il contenuto recuperato deve essere trattato come dato non affidabile, mai come istruzione di sistema.
Gli strumenti e le azioni sono separati dal RAG documentario. I formati sono puliti, i link e gli script neutralizzati e i comportamenti anomali testati. I documenti pubblici e interni possono essere isolati in indici o politiche distinti.
Scegli il modello per ruolo
Lo stesso modello non è necessario per embeddings, reranking e generazione. La scelta dipende dalla lingua, dal dominio, dalla latenza, dal costo e dai vincoli di distribuzione.
Un'architettura può instradare le domande semplici verso un modello più leggero e i riepiloghi complessi verso un modello più capace. Il cambiamento di modello richiede una campagna di regressione, poiché le risposte e i rifiuti possono evolversi.
Gestire il contesto e il costo
Aggiungere ulteriori passaggi non migliora sempre la risposta. Il contesto deve essere pertinente, deduplicato, ordinato e limitato. I documenti lunghi possono essere trattati a tappe o riassunti con tracciabilità.
Il costo si segue per richiesta e per compito riuscito: embedding, ricerca, reranking, token, archiviazione e calcolo. Una cache può riutilizzare risultati stabili a condizione di rispettare i diritti e la freschezza.
Osservabilità
Ogni richiesta genera un identificatore di correlazione. I registri possono contenere intenzione, documenti recuperati, punteggi, versione dei prompt e modelli, latenza, errori e feedback, con una politica rigorosa di minimizzazione.
I cruscotti monitorano:
- tasso di successo ;
- richieste senza prove;
- citazioni aperte ;
- rifiuto;
- latenza ;
- costo;
- errori di ingestione;
- ritardo nell'aggiornamento;
- casi critici derivanti dai riscontri.
Feedback dell'utente e convalida umana
Un pulsante utile non si limita a pollice in alto o in basso. Permette di indicare fonte errata, risposta incompleta, informazione obsoleta o problema di accesso. Il feedback alimenta una coda di smistamento e il set di valutazione.
Per usi a rischio, la risposta è una bozza. Una persona valida, modifica e assume la decisione. Il sistema mantiene la distinzione tra suggerimento e azione approvata.
Distribuire progressivamente
Un pilota deve coprire una popolazione e un corpus limitati, con un supporto identificato. I criteri per il passaggio alla scala sono definiti: qualità, sicurezza, costo, adozione, tasso di escalation e capacità operativa.
Il lancio pubblico avviene dopo i test di autorizzazione, di carico, di iniezione di prompt, di eliminazione dei documenti e di ripresa dell'indice.
Governare il ciclo di vita
Le fonti cambiano, i modelli evolvono e gli usi si spostano. Ogni modifica al pipeline, al modello, al prompt o alla politica riceve una versione e una valutazione. Gli indici possono essere ricostruiti e la vecchia versione conservata il tempo di un ritorno.
Un comitato di prodotto arbitra i nuovi corpus, il livello di rischio e le richieste di azione. Il RAG diventa così una capacità controllata, non una dimostrazione isolata.
Dalla risposta impressionante al servizio affidabile
La produzione richiede meno magia e più prove: corpus governati, ricerca valutata, diritti, rifiuti, osservabilità e sfruttamento. È questa disciplina che trasforma un LLM in uno strumento di lavoro.
Partitech sviluppa catene RAG, integrazioni di modelli e componenti open source intorno a PHP, Mistral e PostgreSQL/pgvector. L'accompagnamento può coprire la definizione del progetto, il prototipo, la valutazione, la sicurezza e la messa in produzione.
Parliamo del tuo progetto
Inquadrare o industrializzare il tuo assistente documentale con Partitech. Contatta Partitech.