Articolo
RAG: contratti di retrieval, non finestre più grandi
Una workflow RAG non diventa affidabile solo perché il modello può leggere più token. Diventa affidabile quando il team sa dire quali evidenze può recuperare, chi le possiede, quanto possono essere vecchie, cosa succede quando sono deboli e come viene misurata la qualità prima di mettere il workflow davanti a clienti, sales, support o operations.
Questo è il contratto di retrieval.
Per un product leader o un operations leader, il punto è molto concreto. La maggior parte degli errori RAG non si presenta come un disastro evidente. La risposta sembra ben scritta. La fonte magari esiste davvero. Il sistema sta anche usando una qualche forma di retrieval. Eppure il workflow può dare al supporto una vecchia regola di rimborso, al commerciale una condizione di prezzo superata, o al team legal una clausola non più valida. Il sintomo visibile è una risposta AI. La causa operativa è un sistema di retrieval non specificato.
La documentazione della Retrieval API di OpenAI descrive retrieval attraverso semantic search, vector store, attributi per filtrare, opzioni di ranking, soglie di score e controlli per la ricerca ibrida. Non sono dettagli tecnici secondari. Sono leve che dovrebbero rappresentare un accordo di business su cosa il workflow può sapere e quando deve fermarsi. La documentazione Retrieval API di OpenAI rende esplicita la catena: i file vengono spezzati in chunk, trasformati in embedding, indicizzati, filtrati, ordinati e restituiti.
L’articolo di Anthropic su Contextual Retrieval aggiunge un punto fondamentale: nelle implementazioni RAG tradizionali il contesto utile può perdersi quando i documenti vengono divisi in chunk. Per questo propone di migliorare la retrieval con chunk contestualizzati, BM25 più embedding, reranking ed eval, invece di pensare che una finestra di contesto più grande risolva automaticamente il problema. L’articolo di Anthropic su Contextual Retrieval riconosce che un prompt lungo può essere una soluzione semplice per basi di conoscenza piccole, ma quando il corpus cresce la qualità della retrieval diventa il vincolo operativo.
La risposta vale quanto l’evidenza recuperata
Quando un workflow AI lavora su conoscenza interna, il modello non è l’unica superficie di prodotto. Il corpus è una superficie di prodotto. I filtri sono una superficie di prodotto. Il messaggio di fallback è una superficie di prodotto. La regola di freschezza è una superficie di prodotto.
Un copilota per il customer support non sta solo generando testo. Sta scegliendo evidenze dentro un sistema vivo fatto di pagine help center, macro interne, eccezioni regionali, note di rilascio e regole di escalation. Se queste fonti vengono mescolate senza ownership, il copilota può recuperare una FAQ pubblica quando serve una policy interna, una regola globale quando serve un’eccezione locale, o una pagina archiviata solo perché è semanticamente simile alla domanda.
Per questo la soluzione istintiva, “usiamo una finestra di contesto più grande”, è rischiosa. Più contesto può ridurre alcuni vuoti, ma può anche nascondere il fatto che nessuno ha deciso quali documenti sono autorevoli. Può portare nel prompt più testo irrilevante, rendere più difficile la review e complicare il debug. Il team vede meno risposte vuote e pensa di aver migliorato il sistema, mentre magari aumenta le risposte fluenti ma debolmente fondate.
È lo stesso tema discusso in Allucinazioni LLM: spesso il retrieval è il problema. Se il sistema recupera l’evidenza sbagliata, il modello può produrre una risposta convincente per una realtà sbagliata. E, come in L’automazione AI ha bisogno di classi di errore, ripetere un’operazione rotta non è resilienza. Un workflow RAG deve distinguere se ha fallito perché manca la fonte, perché le fonti si contraddicono, perché i metadata sono incompleti, o perché la risposta richiede una decisione umana.
Cosa deve contenere un contratto di retrieval?
Un contratto di retrieval è un artefatto operativo breve, non un documento accademico. Deve essere comprensibile dal responsabile del workflow, dall’esperto di dominio e da chi costruisce la soluzione tecnica. Definisce le regole che stanno tra la domanda dell’utente e la risposta.
Il primo elemento è lo scope del corpus. Quali collezioni sono ammesse per questo workflow? Un assistente per il supporto può usare contenuti help center approvati, policy correnti e macro interne di escalation. Non dovrebbe usare bozze di lancio, export di Slack o deck commerciali, a meno che ci sia una ragione esplicita per considerarli fonti rispondibili.
Poi serve l’ownership delle fonti. Ogni collezione ha bisogno di un owner nominativo, non solo di un reparto. Se la policy sui rimborsi è sbagliata, chi la corregge? Se un’eccezione regionale scade, chi la rimuove? Senza ownership, la RAG diventa lo specchio dell’ambiguità organizzativa.
La freschezza viene subito dopo. Alcune informazioni possono restare valide per anni, per esempio linee guida di tono del brand. Altre cambiano rapidamente, come prezzi, promozioni, note legali o status di incidenti. Il contratto dovrebbe definire l’età accettabile per tipo di fonte e cosa deve fare il workflow quando una fonte è troppo vecchia.
Metadata e filtri non sono opzionali. La documentazione OpenAI mostra l’attribute filtering come modo per restringere i risultati in base agli attributi dei file prima della ricerca semantica. In termini operativi significa decidere quali metadata contano: paese, linea prodotto, segmento cliente, lingua, livello di confidenzialità, data di validità, stato del documento o tipo di fonte. Se il workflow deve rispondere solo da policy italiane approvate per clienti enterprise, questa è prima una regola di contratto e poi un parametro tecnico.
Anche ranking e reranking vanno esplicitati. Qual è la soglia minima di rilevanza? Quanti chunk possono arrivare al modello? Serve ricerca ibrida perché gli utenti cercano SKU, codici errore, numeri di clausola o acronimi interni? Qui l’articolo di Anthropic è utile perché mostra perché gli embedding semantici da soli possono non bastare e perché chunk contestualizzati, keyword retrieval e reranking possono fare la differenza.
Infine serve il fallback. Il sistema non deve improvvisare quando l’evidenza manca. Deve dire cosa non ha potuto verificare, fare una domanda di chiarimento, passare a una persona o creare un task per l’owner della fonte. Un fallback non è un fallimento dell’esperienza. È l’esperienza che sceglie di non mentire.
Quando una finestra più grande smette di aiutare?
Una finestra più grande aiuta quando l’evidenza corretta esiste, è abbastanza piccola da includere ed è facile da usare per il modello. Aiuta molto meno quando il problema è la governance delle fonti.
Se un documento è obsoleto, una finestra più grande può includere più testo obsoleto. Se due policy si contraddicono, una finestra più grande può includerle entrambe senza decidere quale prevale. Se il corpus non ha metadata, una finestra più grande non distingue in modo affidabile pubblico da interno, Italia da Stati Uniti, corrente da archiviato, bozza da approvato. Se il confine del chunk taglia via la definizione di un termine, una finestra più grande può solo portare più frammenti.
La domanda migliore non è “quanti token possiamo inserire?” La domanda migliore è “cosa deve essere vero prima che questo workflow sia autorizzato a rispondere?”
Un assistente commerciale, per esempio, può avere bisogno di tre condizioni prima di rispondere a una domanda di pricing: il documento recuperato deve appartenere alla collezione prezzi approvata, la data di validità deve coprire l’offerta in corso e il segmento cliente deve corrispondere all’account. Se queste condizioni non sono soddisfatte, il comportamento corretto non è una risposta più lunga. È un rifiuto, una domanda di chiarimento o un’escalation.
È la stessa logica operativa di RAG o CAG: la scelta operativa prima dell’architettura. L’architettura dovrebbe seguire il pattern della conoscenza. Se la knowledge base è piccola, stabile e riutilizzata spesso, un approccio con contesto in cache può avere senso. Se invece la conoscenza è ampia, mutevole, permissioned e piena di eccezioni, il contratto di retrieval diventa il centro del design.
Come testare la retrieval prima di scalarla
Testare un workflow RAG leggendo dieci risposte convincenti non basta. Serve un eval set che rappresenti le domande che il workflow deve reggere davvero.
Un eval set pratico dovrebbe includere domande normali, edge case, trappole con fonti obsolete, domande regionali, lookup esatti, termini ambigui e domande a cui il sistema dovrebbe rifiutarsi di rispondere. Ogni test dovrebbe definire il comportamento atteso sulle fonti, non solo la risposta finale. Il sistema ha recuperato la policy corrente? Ha evitato la pagina archiviata? Ha messo l’eccezione regionale sopra la regola globale? Ha chiesto il segmento cliente mancante?
Il contratto di retrieval dà forza a questi eval. Senza contratto, i reviewer discutono se una risposta “sembra buona”. Con il contratto, possono verificare se il workflow ha seguito le regole di evidenza concordate.
Un audit leggero su un singolo workflow può partire così:
- Elenca le 30 domande reali più importanti.
- Mappa le collezioni approvate per quelle domande.
- Aggiungi metadata obbligatori e regole di freschezza.
- Definisci ranking, reranking e fallback.
- Costruisci eval con fonti attese, non solo testo atteso.
- Classifica gli errori: fonte mancante, fonte vecchia, filtro sbagliato, chunking debole, ranking debole o fallback assente.
Non è burocrazia. È il modo in cui un’automazione AI diventa governabile.
Parti da un contratto più piccolo dell’ambizione
Il primo contratto di retrieval non deve coprire tutta l’azienda. Deve coprire un workflow: una escalation di supporto, un assistente sales, un bot per policy interne, una FAQ procurement. Scrivilo in linguaggio semplice. Poi configura la retrieval per rispettarlo.
La tesi è semplice: le automazioni RAG hanno bisogno di contratti di retrieval, non di finestre di contesto più grandi. Le finestre più grandi possono essere utili, ma non sostituiscono scope delle fonti, ownership, freschezza, filtri, ranking, fallback ed eval. Se il workflow non sa dire quali evidenze considera affidabili, non è pronto per rispondere su scala.