Chi porta un sistema di recupero in produzione risponde a tre domande davanti a chi lo finanzia: perché non basta caricare tutto nel contesto, quanto costa sbagliare il recupero, e come si dimostra che una risposta viene dal documento giusto. Sono decisioni di architettura, e precedono la scelta del motore di ricerca.

Prima decisione: se la pipeline serva davvero

Anthropic mette una soglia esplicita prima di qualsiasi discussione su chunk e indici: «If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt with no need for RAG». Sotto quella dimensione il prompt caching rende il corpus un prefisso riutilizzabile, e si evitano indice, reindicizzazione, monitoraggio e chi li presidia. È l’argomento più solido in una riunione di budget: la pipeline si giustifica se il corpus non entra nel contesto, se cambia troppo spesso, o se va segmentato per permessi — non perché «si fa così».

Se serve davvero, la metrica da mettere nel documento di progetto non è la similarità media ma il tasso di fallimento del recupero: la quota di domande in cui il passaggio che contiene la risposta non compare fra i chunk restituiti.

Chunking e indicizzazione: leve con effetto misurato

Il punto di partenza è granulare: «Break down the knowledge base (the “corpus” of documents) into smaller chunks of text, usually no more than a few hundred tokens». Le leve sono dichiarate: «The choice of chunk size, chunk boundary, and chunk overlap can affect retrieval performance». Un chunk troppo grande diluisce il segnale dell’embedding, uno troppo piccolo perde il contesto che rende la frase interpretabile: è questa perdita che l’arricchimento contestuale compensa.

Sull’indicizzazione la scelta non è fra lessicale e semantico, ma fra tenerne uno o due. BM25 «is a ranking function that uses lexical matching to find precise word or phrase matches»; gli embedding cercano vicinanza di significato. Il pattern documentato li combina: «Use BM25 to find top chunks based on exact matches; Use embeddings to find top chunks based on semantic similarity; Combine and deduplicate results using rank fusion techniques».

Gli effetti misurati sono la parte difendibile in riunione. I soli embedding contestuali «reduced the top-20-chunk retrieval failure rate by 35%»; con BM25 contestuale la riduzione arriva al 49%, e aggiungendo il reranking al 67%. Anche quanti chunk consegnare è stato misurato: «We tried delivering 5, 10, and 20 chunks, and found using 20 to be the most performant». Ogni gradino ha un prezzo — l’arricchimento costa una passata di generazione sull’intero corpus, il reranking una chiamata in più per query — quindi va presentato come decisione a sé.

Adattare il recupero alla forma del dato e al pattern di query

Una scelta è obbligata: «Anthropic does not offer its own embedding model». L’embedding è un acquisto di terze parti, con criteri dichiarati — dimensione e specificità del dataset di addestramento, prestazioni in inferenza, personalizzazione — e con modelli specializzati per codice, ambito legale, finanza e contenuti multimodali. Un corpus di contratti e uno di sorgenti non si indicizzano con lo stesso modello: è un vincolo di fornitura, non un dettaglio implementativo.

Il pattern di query decide il resto. Domande con identificatori esatti — codici prodotto, numeri di errore, nomi di funzione — premiano il matching lessicale, quelle in linguaggio naturale la ricerca semantica; il costo del secondo indice si giustifica mostrando quali query oggi falliscono.

Quando i dati sono già navigabili — un repository, un file system — la pre-indicizzazione può essere superflua. La guida al context engineering descrive l’alternativa: «Rather than pre-processing all relevant data up front», l’agente tiene identificatori leggeri e li usa per caricare i dati «dynamically load data into context at runtime», perché «Folder hierarchies, naming conventions, and timestamps all provide important signals». Le due strade non si escludono: «In certain settings, the most effective agents might employ a hybrid strategy, retrieving some data up front for speed, and pursuing further autonomous exploration at its discretion». E se un indice esiste già, la documentazione suggerisce di non duplicarlo ma di esporlo come strumento MCP «so Claude queries it instead of reading files directly».

Rendere verificabile la risposta

Un sistema di recupero si difende mostrando la provenienza. La Messages API ha un blocco pensato per questo: «Search result content blocks let Claude cite your own content the same way it cites web search results: each citation carries the source and title you provided». Si usa dai risultati di uno strumento, per un recupero dinamico, oppure come contenuto di primo livello.

{
  "type": "search_result",
  "source": "https://example.com/article",
  "title": "Article Title",
  "content": [
    { "type": "text", "text": "The actual content of the search result..." }
  ],
  "citations": { "enabled": true }
}

Anche la granularità della citazione è una scelta di progetto: il testo semplice viene spezzato in frasi, mentre per i documenti a contenuto personalizzato «Your provided content blocks are used as-is and no further chunking is done». La regola operativa è esplicita: «if you want Claude to be able to cite specific sentences from your RAG chunks, you should put each RAG chunk into a plain text document». Il costo va dichiarato insieme al beneficio: «Enabling citations incurs a slight increase in input tokens because of system prompt additions and document chunking». È il prezzo più basso che si paghi per rendere auditabile una risposta.