Context engineering per il RAG: dalla domanda grezza a campi tipizzati che guidano retrieval e generation

Quando si parla di context engineering nel RAG si pensa quasi sempre a come recuperare il contesto giusto da un documento: selezione dei chunk, hybrid search, reranking, retrieval consapevole del sommario. È solo metà della storia. L’altra metà è che anche la domanda dell’utente è context che il modello vedrà, e merita lo stesso trattamento del passaggio recuperato.

L’esempio dell’articolo è una domanda di un analista assicurativo: qual è l’importo massimo di copertura, da non confondere con la franchigia che spesso compare accanto. Una sola stringa contiene quattro segnali diversi (un tema, un indizio negativo, una forma attesa, un suggerimento strutturale), ciascuno destinato a uno step downstream diverso. Passata così com’è a un top-k su similarità coseno, nessuno di questi segnali finisce dove dovrebbe: l’embedding richiama righe che parlano di franchigia, la generation sceglie il primo numero plausibile e il trace non spiega nulla. Non è un fallimento del retrieval né della generation, ma un errore di context engineering sul lato domanda.

Il parser legge e scrive context

Il question parsing è l’unico blocco della pipeline che è insieme consumatore di context (fa una chiamata LLM propria) e produttore di context (la riga tipizzata che genera alimenta tre chiamate successive). Come consumatore, la sua finestra è assemblata da slot fissi: un system prompt cachato a livello di modulo, un JSON compatto con i fatti a livello di documento, un blocco di few-shot stabile e la sola domanda grezza come payload per chiamata. Niente testo del documento, niente output di retrieval, niente memoria: il parser sta prima del retrieval, quindi quel contesto non esiste ancora.

Quattro strategie, quattro pezzi tipizzati

Letto come produttore, il parser incarna le quattro strategie canoniche di context engineering formalizzate da LangChain (write, compress, select, isolate), ognuna in un pezzo diverso:

• Write: la riga ParsedQuestion con campi nominati diventa un contratto. I nomi dei campi sono il contratto: un test downstream può verificare che, se è presente un pages_hint, il brief di retrieval lo includa.
• Compress: il brief di retrieval è più piccolo di ParsedQuestion perché omette la forma della risposta, il model tier e la richiesta di chiarimento. Non è risparmio di token, è disaccoppiamento: ogni campo omesso è un accoppiamento che non si formerà mai.
• Select: il brief di generation raccoglie le decisioni che il dispatcher ha già preso in modo deterministico in Python (chunk_strategy, suggested_model, i flag di attivazione), così il modello non deve inventare nulla.
• Isolate: quando il parser non riesce a risolvere intento, forma o scope con sicurezza, non forza un’ipotesi ma scrive un ClarificationRequest e mette in pausa la pipeline, evitando di avvelenare il retrieval con un filtro sbagliato.

Perché non un unico payload

La tentazione è mettere tutti i campi in un unico oggetto e lasciare che ogni ricevente prenda ciò che serve. L’articolo argomenta il contrario per motivi operativi: un payload unico rompe la separazione tra le strategie (il retrieval potrebbe iniziare a leggere la forma della risposta), collassa i confini di cache (ogni chiave diventa “per stringa grezza”) e fa trapelare l’ambiguità, perché costringe a inviare qualcosa a ogni ricevente anche quando il parse è parziale. Restano ammessi gli helper che assemblano i pezzi quando servono insieme.

• La domanda va trattata come context da progettare, non come stringa da passare grezza al retrieval.
• Separare l’output del parser in pezzi tipizzati mantiene piccolo il raggio d’impatto di una modifica di schema e rende auditabili le decisioni.
• Il clarification loop è il pattern isolate applicato all’output del parser stesso: meglio chiedere che indovinare.

Fonte: Context Engineering for RAG Question Parsing: From a Raw Question to Typed Fields That Steer Retrieval and Generation — https://towardsdatascience.com/context-engineering-for-rag-question-parsing-from-a-raw-question-to-typed-fields-that-steer-retrieval-and-generation/