Il problema non è solo recuperare i documenti giusti. Nei sistemi di retrieval-augmented generation, una domanda può sembrare chiara nel contesto del dialogo e rivelarsi ambigua solo quando viene messa a confronto con i documenti recuperati. Oppure può essere ambigua fin dall'inizio, con riferimenti poco chiari alle battute precedenti. Riconoscere questi casi prima che il modello generi una risposta è il nodo che il gruppo IBM Research affronta con ClariEdge, un dataset di circa 3.900 esempi ora disponibile su Hugging Face.

ClariEdge non documenta soltanto query ambigue. Include anche esempi negativi che non richiedono chiarimento, e qui sta il primo segnale tecnico: la qualità della separazione dipende dagli hard negative. Una query può apparire ambigua ma essere risolvibile dal contesto precedente; senza esempi difficili, un classificatore tende a chiedere chiarimenti anche quando non servono. Il dato riportato è che un LoRA leggero ottenuto con fine-tuning raggiunge il 96,6% di accuratezza nella classificazione e supera le baseline di modelli più grandi, sia nel riconoscere i casi ambigui sia nella qualità delle richieste di chiarimento generate.

L'aspetto meno visibile è che lo stesso LoRA funziona in due punti distinti della pipeline RAG: prima del retrieval e dopo il retrieval. Questo cambia la prospettiva rispetto all'idea che serva un unico modello, il più grande possibile, per governare l'intero flusso. Un componente specializzato e leggero può fare da filtro in punti critici, lasciando al modello generativo il compito di produrre la risposta finale. Per chi opera stack self-hosted o con vincoli di VRAM, un adattatore LoRA è un elemento più semplice da mantenere in locale rispetto a un modello di grandi dimensioni; può intercettare l'input ambiguo senza doverlo inviare a servizi esterni, riducendo l'esposizione dei dati e il consumo di token prima della generazione. Per chi valuta deployment on-premise, questi trade-off tra controllo locale e complessità operativa sono il tipo di analisi che AI-RADAR affronta in /llm-onpremise.

C'è anche un costo. Inserire un controllo aggiuntivo in due punti della pipeline introduce un componente in più da addestrare, versionare e monitorare. Il fine-tuning non elimina la necessità di governare i dati di addestramento: ClariEdge rende esplicito che la separazione tra ambiguità reale e ambiguità apparente è un problema di dataset prima che di architettura. Chi adotta questo schema deve quindi investire nella cura degli esempi negativi, non solo nella scelta del modello.

La direzione strutturale è chiara: il mercato si sta spostando verso componenti modulari e specializzati per la RAG, dove il controllo del flusso non spetta per forza al modello più grande. ClariEdge non propone un nuovo modello generativo, ma un pezzo di infrastruttura che decide quando fermarsi e chiedere. È un segnale per chi costruisce stack locali: il valore può concentrarsi in un LoRA addestrato su un compito ristretto, con costi di esecuzione contenuti e una supervisione più diretta sui dati. Resta da capire quanto bene il filtro si comporti fuori dalla distribuzione del dataset, ma il fatto che il dataset sia pubblico consente di testarlo senza dipendere da benchmark chiusi.