Agentic search: Mistral porta l’accuratezza dal 27% all’86%

Mistral ha presentato Agentic Search, un livello di retrieval che non recupera pezzi di testo ma naviga i documenti come farebbe una persona: apre, sfoglia, cerca dentro la pagina. Sui bilanci depositati alla SEC il salto dichiarato è netto, dal 26,7% all’86% circa di accuratezza con lo stesso modello. È il numero che rende leggibile una discussione tecnica che va avanti da mesi, e che riguarda chiunque debba far ragionare un agente sulla documentazione interna di un’azienda.

In questo articolo scoprirai:

• Cos'è l'agentic search: cinque strumenti invece di una query sola
• Dal 26,7% all'86% su FinanceBench: i numeri, e chi li ha misurati
• Perché il chunk singolo si perde: il confronto con il RAG tradizionale
• PDF da duecento pagine, SharePoint, ticket: il caso aziendale vero
• Perché l'agentic search è una scelta architetturale, non una feature

Cos’è l’agentic search: cinque strumenti invece di una query sola

L’agentic search è un retrieval a più passi: l’agente cerca, legge, capisce cosa gli manca e cerca di nuovo, finché ha abbastanza per rispondere. Il RAG classico fa una domanda all’indice, riceve i chunk più simili e passa tutto al modello: un solo giro, deciso prima di sapere cosa c’era dentro. Il glossario di Firecrawl lo definisce esattamente così: «un loop, dove ogni tornata di risultati informa la query successiva», con reformulazione automatica invece che manuale.

I cinque strumenti dell’agentic search di Mistral

Nell’implementazione di Mistral il loop è fatto di cinque strumenti che somigliano in modo sospetto a un file system: search trova i documenti nell’indice esistente, open ne apre uno, navigate si muove tra pagine e sezioni, read legge il punto in cui si trova, grep cerca un pattern dentro il documento aperto. Non è una metafora casuale. È lo stesso repertorio con cui un analista lavora su un PDF di duecento pagine: cerca l’indice, salta al capitolo, scorre la tabella, controlla la nota a piè di pagina.

La differenza sostanziale è quando si decide cosa serve. Nel RAG a chunk singolo la decisione arriva prima della lettura; nell’agentic search arriva durante. Questo cambia la classe di domande a cui il sistema può rispondere: non più «dove si parla di X», ma «quanto è variato X fra due esercizi, e dove è scritto». Il prezzo è latenza e token, e Firecrawl è onesto su questo: per una ricerca secca in cui il primo risultato basta, una chiamata sola resta più veloce ed economica.

Dal 26,7% all’86% su FinanceBench: i numeri, e chi li ha misurati

I dati vengono dall’annuncio di Mistral e vanno attribuiti a Mistral: sono benchmark pubblici, ma la misura è del fornitore. Su FinanceBench, 368 bilanci depositati, 150 domande, che sono il sottoinsieme pubblico annotato a mano delle 10.231 del dataset completo, Mistral Medium 3.5 passa dal 26,7% a circa l’86% di accuratezza. La scomposizione è la parte interessante: il passaggio dal RAG one-shot al loop di sola ricerca vale +47,3 punti percentuali, mentre aggiungere gli strumenti di navigazione ne porta altri +8,7. Su GLM-5.2 lo stesso salto vale +52,6 e +6,7 punti.

Su OfficeQA Pro (696 bollettini del Tesoro, 133 domande) i valori assoluti restano bassi: GLM-5.2 arriva al 51,9%, con un miglioramento di +45,6 punti. Cioè: il metodo funziona, ma metà delle domande resta sbagliata. Vale la pena tenerlo a mente prima di promettere a qualcuno un agente infallibile sui documenti.

Il punto di partenza, però, non è un artificio retorico. Il paper originale di FinanceBench (Islam, Kannappan, Kiela, Qian, Scherrer, Vidgen, 10.231 domande nel dataset completo, di cui le 150 pubbliche valutate a mano su 16 configurazioni) misurava che GPT-4-Turbo con un sistema di retrieval sbagliava o rifiutava di rispondere all’81% delle domande. Il RAG a chunk singolo sui documenti finanziari non è «migliorabile»: è rotto, e lo era prima che qualcuno avesse un prodotto da vendere.

Un dato meno citato riguarda l’efficienza: Mistral dichiara fino al 33,7% di token in meno con gli strumenti di navigazione attivi, e la latenza al 90° percentile che scende da 255 a 154 secondi. Più passi non significa automaticamente più costo, significa leggere meno roba inutile.

Perché il chunk singolo si perde: il confronto con il RAG tradizionale

C’è una ragione strutturale per cui riempire il contesto di chunk non risolve il problema, e la ricerca sul context rot di Chroma l’ha misurata: le prestazioni degradano al crescere dell’input, e a degradare per prima è la comprensione semantica, non il match lessicale. La sintesi indipendente di Hamel Husain la mette in una frase che vale come regola operativa: «avere l’informazione giusta nel contesto non basta: conta come viene presentata». Peggio: più distrattori simili al passaggio corretto, più il modello sbaglia.

È lo stesso fenomeno che chi lavora con gli embedding conosce come vicinanza ingannevole, il motore restituisce la pagina vicina invece di quella giusta, ed è un problema di geometria, non di modello (ne abbiamo scritto in Similarità coseno: perché la ricerca trova la pagina vicina invece di quella giusta). AWS lo osserva dal lato opposto, quello degli attributi: «la ricerca semantica privilegia la somiglianza concettuale sul match esatto degli attributi». Un codice articolo, una data, una voce di bilancio: cose su cui la somiglianza non serve a niente.

Come il loop a più passi aggira la degradazione del contesto

Il loop agentico non elimina il problema, lo aggira: cerca poco per volta, verifica, scarta. Elastic lo implementa con un agente che valuta i documenti recuperati e, se non passano, riscrive la query e riprova, con un contatore di tentativi fermo a 3. Quel contatore è la parte che non fa notizia e che invece decide se il sistema è utilizzabile in produzione. Chi vuole i fondamentali prima di questo strato può partire da cos’è il RAG e come funziona, e dal confronto tra RAG e fine-tuning per casi d’uso enterprise.

PDF da duecento pagine, SharePoint, ticket: il caso aziendale vero

La cronaca si è fermata sui benchmark finanziari, ma il documento eterogeneo è la normalità in azienda, non l’eccezione. Un capitolato in PDF con le tabelle scansionate, la wiki interna, tre anni di ticket di assistenza, il contratto quadro con quattro addenda: nessuno di questi oggetti sopravvive alla frammentazione in chunk da 500 token. Il chunk perde la struttura, e la struttura è metà dell’informazione, quale allegato, quale versione, quale esercizio. Sono anche gli stessi materiali su cui girano gli agenti AI per il back-office.

L’agentic search sopra l’indice aziendale che già esiste

Qui il modello «file system» paga più che sui bilanci. Un agente che può aprire il documento e saltare alla sezione 4.2 non ha bisogno che qualcuno abbia indovinato il chunking giusto sei mesi prima. E il dettaglio industrialmente più rilevante dell’annuncio Mistral non è un numero: è che il livello agentico lavora sopra l’indice che già esiste, con disponibilità sia cloud sia on-premise. Chi ha un motore di ricerca interno e un vincolo di riservatezza sui dati non deve rifare l’indicizzazione per provare il metodo.

Ha una conseguenza anche sul giorno in cui si cambia fornitore: se il loop gira sopra l’indice del cliente, quello che resta al cliente è la parte costosa, i documenti, l’indicizzazione, i permessi, il lavoro di pulizia, perché non è mai uscita da casa sua. Quello che non resta è il tool set: la definizione dei cinque strumenti, i budget di passi e token, i guardrail e i prompt che li governano vanno rifatti sul fornitore nuovo, insieme alla verifica dei risultati sul corpus reale. È un costo di migrazione misurabile in settimane di lavoro, non un ripartire da zero.

Questo però non è un lasciapassare. Se i documenti sono duplicati in tre versioni, se i permessi non sono espressi in modo leggibile da una macchina, se metà dei PDF è priva di testo estraibile, il loop agentico navigherà accuratamente del disordine. È il lavoro noioso che precede qualunque agente e che abbiamo raccontato in data readiness per agenti AI: la qualità della navigazione dipende da quanto è navigabile il corpus. Vale anche a monte, sul processo: conviene misurare se l’azienda è pronta per un agente prima di comprarne uno.

Perché l’agentic search è una scelta architetturale, non una feature

Chi decide di adottare questo pattern non attiva un’opzione: firma tre decisioni. Quali strumenti dare all’agente, cinque come Mistral, quattro come Context-1 di Chroma, che aggiunge prune_chunks per farlo potare il proprio contesto. Quanto budget concedere al loop, in passi, token e secondi. E quali guardrail: dove si ferma, cosa cita, cosa dichiara di non aver trovato. Senza il terzo punto un agente che sbaglia sembra identico a uno che ha ragione.

Agentic search con modelli da 20B: il caso Context-1

La buona notizia è che non serve il modello più grande. Context-1 è un 20B derivato da gpt-oss-20B e, secondo i numeri pubblicati da Chroma, arriva a 0,87 su BrowseComp-Plus contro 0,91 di Opus-4.6, con un costo per configurazione inferiore a una singola chiamata al modello di frontiera e inferenza fino a 10 volte più rapida. Il retrieval agentico, insomma, è alla portata di un’infrastruttura aziendale normale, anche di una che tiene i dati in casa. Sul come si compone questo strato con il resto, restano utili le nostre pagine su come progettare un RAG aziendale su misura con un partner e su cosa sanno fare davvero gli agenti AI.

È anche il motivo per cui, in Mimír AI Agent, l’onboarding assistito non è un accessorio commerciale: le tre decisioni qui sopra si prendono guardando i documenti reali di un’azienda, non un listino. Noi accompagniamo quella fase, scelta del tool set, definizione dei budget, guardrail e verifica dei risultati sui vostri contenuti, perché nell’AI enterprise il servizio conta più del modello. Se avete un corpus difficile e volete capire se l’agentic search vi serve davvero, parlatene con noi: la prima cosa che facciamo è dirvi se il caso regge.

Fonti:

• Mistral AI — Agentic Search: the retrieval layer for complex documents
• FinanceBench: A New Benchmark for Financial Question Answering (arXiv 2311.11944)
• Chroma Research — Context-1: Training a Self-Editing Search Agent
• Hamel Husain — Context Rot (note sulla ricerca Chroma)
• Firecrawl Glossary — What is agentic search?
• Elasticsearch Labs — Developing an agentic RAG news assistant
• AWS — Building intelligent search with Amazon Bedrock and Amazon OpenSearch