Articolo
La retrieval ha bisogno di un contratto
Il brief di molte automazioni AI sembra semplice: colleghiamo i nostri documenti a un modello, così le persone possono fare domande.
Il prototipo di solito funziona. Si carica un manuale di supporto, qualche nota prodotto, forse una cartella di policy interne. Le prime domande sono prevedibili. Le risposte sembrano abbastanza buone da creare entusiasmo.
È qui che la scelta tra RAG e CAG diventa operativa, non solo architetturale. Il pattern di retrieval conta, ma il contratto intorno conta di più.
Poi arriva l’uso reale.
Una persona del customer success chiede una policy cambiata il mese scorso. Il team sales fa una domanda di pricing che dipende da area geografica e tipo di contratto. Il product team cerca la definizione aggiornata di una feature, ma nella knowledge base convivono una bozza di roadmap, un memo di lancio e una FAQ vecchia. La risposta è sicura nel tono, ma non è affidabile.
A quel punto molti team danno la colpa al modello. A volte il modello contribuisce al problema. Più spesso, però, il livello di retrieval non ha mai ricevuto un contratto.
La documentazione di OpenAI descrive la retrieval come ricerca semantica sui propri dati, con i vector store usati come indici. Mostra anche che i risultati possono includere chunk rilevanti, punteggi di similarità, file di origine, attributi per filtrare, opzioni di ranking e configurazioni di chunking. Non sono dettagli puramente tecnici. Sono decisioni operative. (developers.openai.com)
L’artefatto mancante non è un altro database
Un vector database può archiviare e cercare contenuti trasformati in embedding. Non può decidere quali documenti siano autorizzati a rispondere a una domanda sul payroll. Non può sapere quando un memo legale è diventato vecchio. Non può scegliere da solo se dire “non lo so” invece di cucire insieme due passaggi deboli.
Questo è il ruolo di un contratto di retrieval.
Un contratto di retrieval è un breve accordo operativo per un workflow di conoscenza basato su AI. Definisce cosa il sistema può recuperare, come deve trattare anzianità e autorevolezza delle fonti, cosa deve fare quando la retrieval è debole, chi possiede la qualità delle fonti e come il team verifica se il sistema sta migliorando.
Senza quel contratto, “colleghiamo i documenti all’AI” resta una speranza vaga. Con quel contratto, la retrieval diventa un sottosistema governato.
Cosa deve contenere il contratto
1. Perimetro delle fonti
Si parte nominando le fonti ammesse.
Per esempio: articoli pubblicati nell’help center, materiali sales approvati, documentazione prodotto corrente e policy firmate. Poi si nominano le fonti escluse: bozze, note di meeting, vecchie proposte, export personali, thread Slack e qualsiasi contenuto senza owner.
Questo conta perché i sistemi di retrieval sono letterali. Se viene indicizzato materiale vecchio o non ufficiale, il sistema può recuperarlo. Se due file si contraddicono, il modello può sintetizzare una risposta elegante basata su input disordinati.
Il perimetro deve includere anche una gerarchia. Se la documentazione pubblica e una bozza interna dicono cose diverse, quale fonte vince? Se una pagina di policy e una macro di supporto sono in conflitto, quale è autorevole?
2. Regole di freschezza
Ogni workflow di conoscenza ha bisogno di una policy di aggiornamento.
Alcuni contenuti possono restare validi per mesi. Una procedura di sicurezza, una pagina prezzi o una regola di compliance possono richiedere una revisione più stretta. Il contratto deve dire ogni quanto viene aggiornata ciascuna categoria di fonti, quali metadati sono obbligatori e cosa succede quando un file supera la data di revisione.
La freschezza non è solo una questione di sync tecnico. È una questione di responsabilità. Qualcuno deve sapere che ciò che viene recuperato è ancora sicuro da usare.
3. Comportamento della retrieval
Il team dovrebbe decidere come deve funzionare la retrieval prima di discutere della qualità delle risposte.
Il sistema deve cercare in tutte le fonti o filtrare per dipartimento, area geografica, lingua, linea di prodotto o segmento cliente? Deve preferire corrispondenza esatta, similarità semantica o un approccio ibrido? Deve usare soglie più severe sui temi ad alto rischio e una ricerca più ampia per attività esplorative a basso rischio?
La guida di OpenAI mostra che gli attributi possono restringere la ricerca prima della retrieval semantica e che le opzioni di ranking possono regolare soglie di rilevanza ed equilibrio tra matching semantico e testuale. Il punto operativo è semplice: queste impostazioni dovrebbero riflettere decisioni di prodotto, non default nascosti. (developers.openai.com)
4. Comportamento di fallback
Un sistema affidabile deve sapere quando non rispondere.
Il contratto deve definire cosa succede quando la retrieval restituisce evidenza debole, evidenza in conflitto, evidenza assente o evidenza vecchia. I fallback possibili includono:
- fare una domanda di chiarimento
- dire che la risposta non è disponibile nelle fonti approvate
- mostrare la migliore fonte disponibile senza sintetizzare una risposta finale
- inoltrare la domanda a un owner umano
- creare un ticket di revisione per documentazione mancante o contraddittoria
Qui molti sistemi RAG falliscono. Sono ottimizzati per rispondere, non per essere corretti in condizioni di incertezza.
5. Ownership
La qualità della retrieval ha degli owner.
Engineering può possedere ingestione, chunking, metadati e configurazione della ricerca. Product può possedere esperienza utente e casi d’uso accettati. Operations o i lead di funzione possono possedere la qualità delle fonti. Legal, security o finance possono possedere le regole di approvazione sui temi sensibili.
Se nessuno possiede la fonte, nessuno possiede la risposta.
Un buon contratto nomina l’owner responsabile per ogni categoria di fonte e la persona che può decidere se una fonte va aggiunta, rimossa, archiviata o declassata.
6. Valutazione e ciclo di revisione
Non aspettare che siano gli utenti a lamentarsi.
Crea un piccolo set di valutazione prima del lancio. Includi domande frequenti, domande ambigue, trappole legate a fonti vecchie, domande che attraversano più fonti e domande a cui il sistema dovrebbe rifiutarsi di rispondere. Per ognuna, definisci come deve apparire una buona retrieval: quale fonte deve comparire, quale fonte non deve comparire e quale fallback è accettabile.
Poi rivedi le query reali con una cadenza precisa. Cerca pattern: documenti mancanti, metadati deboli, chunk troppo ampi, chunk troppo stretti, ownership poco chiara o domande che rivelano un processo rotto fuori dal sistema AI.
L’obiettivo non è rendere la retrieval perfetta. L’obiettivo è rendere gli errori visibili e correggibili.
Il test pratico
Prima di rilasciare un assistente AI per la conoscenza interna, fai sei domande:
- Quali fonti sono autorizzate a rispondere a questo caso d’uso?
- Quale fonte vince quando due documenti si contraddicono?
- Quanto deve essere fresca la fonte?
- Cosa deve fare il sistema quando la retrieval è debole?
- Chi possiede ogni fonte e ogni failure mode?
- Quali domande campione dimostrano che il workflow è abbastanza sicuro da usare?
Se il team non sa rispondere, il prossimo passo non è una demo migliore. È un contratto di retrieval.
Un contratto trasforma il prototipo in workflow
L’affidabilità di un RAG non è solo un problema di modello. È un problema di prodotto e operations intorno all’evidenza.
I migliori sistemi AI di knowledge management non sono quelli con più documenti collegati. Sono quelli con confini chiari, fonti mantenute, fallback espliciti e un ciclo di revisione che intercetta la realtà quando cambia.
Un vector database rende le informazioni cercabili. Un contratto di retrieval rende quella ricerca utilizzabile in un workflow aziendale reale.
Questa è la differenza tra un prototipo impressionante e uno strumento interno di cui le persone possono fidarsi.
Se il workflow usa anche automazioni, lo stesso contratto deve collegarsi alla governance n8n in produzione. La retrieval decide quale evidenza entra nella risposta. La governance del workflow decide cosa succede dopo che quella risposta è stata prodotta.