La maggior parte dei team assembla ancora la propria prima pipeline di retrieval nello stesso modo. Scelgono un limite di token fisso, magari 512, suddividono i documenti in blocchi uniformi e caricano questi blocchi in un database vettoriale. Su un piccolo dataset con domande semplici, tutto sembra magico. In produzione, tutto crolla.

I contratti legali si riducono in frammenti privi di senso quando una clausola viene tagliata a metà frase. La documentazione API si trasforma in un insieme caotico di informazioni se un singolo chunk ingloba tre funzioni non correlate. I ticket di assistenza clienti perdono ogni filo narrativo in assenza di sovrapposizione tra i segmenti. Il risultato è prevedibile: latenza elevata, recall debole e risposte che costringono il generatore a allucinare.

Abbiamo smantellato il nostro livello di retrieval e lo abbiamo ricostruito da zero. Il risultato è stato un salto della recall dal 78% al 95%, una riduzione della latenza del 62% e una pipeline che finalmente si comporta come una vera infrastruttura invece di un esperimento improvvisato del fine settimana. Ecco cosa ha funzionato davvero.

Smart Chunking: La struttura prevale sui token

Il primo errore è dare per scontato che ogni documento parli la stessa lingua. Un chunk da 512 token ha senso per la prosa narrativa e quasi nient'altro. Siamo passati a una strategia che rispetta l'anatomia della fonte.

Per i documenti legali, utilizziamo il recursive chunking. L'algoritmo prova prima a suddividere in base a confini di alto livello come sezioni e articoli. Se una sezione è ancora troppo lunga, cerca sottosezioni, poi paragrafi e infine frasi. Questo preserva l'annidamento logico delle clausole. Un accordo di non concorrenza rimane intatto. Le definizioni non si mescolano con i termini di indennizzo.

La documentazione API richiede un chunking consapevole della struttura (structure-aware chunking). La firma di una funzione, la sua tabella dei parametri e la sua richiesta di esempio appartengono allo stesso contesto. Suddividere dopo un numero fisso di token spesso lascia i parametri in un chunk e gli esempi in un altro. Invece, suddividiamo per oggetto del documento. Un chunk contiene un endpoint completo o una singola funzione. Il retriever può quindi restituire un riferimento autonomo che risponde effettivamente alla domanda.

I ticket di assistenza si prestano naturalmente al semantic chunking. Invece di tagliare in corrispondenza di un limite di token, rileviamo dove cambia l'argomento. Un ticket che inizia con un reclamo per l'accesso e passa a una domanda sulla fatturazione viene diviso in due parti coerenti. Ogni parte porta con sé i metadati necessari e il modello non deve più indovinare quale problema interessi realmente all'utente.

Le wiki interne sono più disordinate. Mescolano prosa, tabelle, diagrammi e thread incorporati. Per queste, utilizziamo l'agentic chunking. Un piccolo modello linguistico legge in anticipo e decide dove termina un'unità tematicamente completa. Costa un po' di più durante la fase di ingestione, ma elimina il lavoro manuale di affinamento delle regole per ogni nuovo formato di pagina.

Hybrid Retrieval: Coprire ogni fronte

La ricerca vettoriale è eccellente nel catturare significati sfumati. Chiedi informazioni sui caricamenti lenti e restituirà volentieri paragrafi sulla latenza e sulla larghezza di banda. Tuttavia, è nota per rovinare le corrispondenze esatte. Se uno sviluppatore cerca il codice di errore ERR_CONNECTION_REFUSED, gli embedding densi spesso lo tratteranno come rumore generico.

BM25, il classico algoritmo basato su parole chiave, fa l'esatto opposto. Individua con precisione stringhe esatte e termini rari, ma manca le sfumature semantiche. Una query sulla firma dell'accordo potrebbe non far emergere mai contenuti taggati con l'esecuzione del contratto.