Recupero agentico in Azure AI Search

Nota

Alcune funzionalità di recupero agentic sono generalmente disponibili nella versione dell'API REST 2026-04-01 tramite accesso programmatico. Il portale di Azure e il portale Foundry di Microsoft continueranno a fornire l'accesso in anteprima a tutte le funzionalità di recupero agentico. Per indicazioni sulla migrazione, tra cui una suddivisione delle funzionalità disponibili a livello generale e di ciò che rimane in anteprima, consultare Eseguire la migrazione del codice di recupero agentico alla versione più recente.

In Azure AI Search, recupero agentico è una pipeline multi-query progettata per domande complesse poste da utenti o agenti nelle app chat e copilot. È progettato per i modelli di generazione aumentata dal recupero (RAG) e i flussi di lavoro agente-agente.

Ecco cosa fa:

  • Usa un modello di linguaggio di grandi dimensioni (LLM) per suddividere una query complessa in sottoquery più piccole e incentrate per una migliore copertura sul contenuto indicizzato. Le sottoquery possono includere la cronologia delle chat per un contesto aggiuntivo.

  • Esegue sottoquery in parallelo. Ogni sottoquery viene riclassificata semanticamente per promuovere le corrispondenze più rilevanti.

  • Combina i risultati migliori in una risposta unificata che un LLM può usare per generare risposte con il contenuto proprietario.

  • La risposta è modulare ma completa nel modo in cui include anche un piano di query e documenti di origine. È possibile scegliere di usare solo i risultati della ricerca come dati di base oppure richiamare LLM per formulare una risposta.

Questa pipeline ad alte prestazioni consente di generare dati di base di alta qualità (o una risposta) per l'applicazione di chat, con la possibilità di rispondere rapidamente a domande complesse.

A livello di codice, il recupero agentico è supportato tramite un oggetto base di conoscenza nella versione stabile più recente (2026-04-01) e anteprima (2025-11-01-preview), oltre ai pacchetti Azure SDK equivalenti delle API REST. La risposta di recupero di una knowledge base è progettata per l'utilizzo downstream da parte di altri agenti e app di chat.

Perché usare il recupero agentico

Esistono due casi d'uso per il recupero agentico. In primo luogo, è la base dell'esperienza di Foundry IQ nel portale Microsoft Foundry (nuovo). Fornisce il livello di conoscenza per le soluzioni per agenti in Microsoft Foundry. In secondo luogo, è la base per soluzioni agentiche personalizzate create usando le API Azure AI Search.

È consigliabile usare il recupero agentico quando si desidera fornire agli agenti e alle app il contenuto più pertinente per rispondere a domande più difficili, sfruttando il contesto di chat e il contenuto proprietario.

L'aspetto agente è un passaggio di ragionamento nell'elaborazione della pianificazione delle query eseguito da un modello di linguaggio di grandi dimensioni (LLM) supportato. LLM analizza l'intero thread di chat per identificare le informazioni sottostanti necessarie. Invece di una singola query catch-all, l'LLM suddivide le domande composte in sottoquery incentrate in base a: domande utente, cronologia chat e parametri nella richiesta. Le sottoquery hanno come destinazione i documenti indicizzati (testo normale e vettori) in Azure AI Search. Questo approccio ibrido consente di visualizzare contemporaneamente corrispondenze di parole chiave e analogie semantiche, migliorando notevolmente il richiamo.

Il componente di recupero è la possibilità di eseguire contemporaneamente sottoquery, unire i risultati, classificare semanticamente i risultati e restituire una risposta in tre parti che include i dati di base per il turno di conversazione successivo, i dati di riferimento in modo da poter esaminare il contenuto di origine e un piano di attività che mostra i passaggi di esecuzione delle query.

L'espansione delle query e l'esecuzione parallela, oltre alla risposta di recupero, sono le funzionalità principali del recupero agentico che lo rendono la scelta migliore per le applicazioni di intelligenza artificiale generativa (RAG).

Diagramma di una query complessa che mostra come il recupero agentico gestisce il contesto implicito e un errore di digitazione intenzionale.

Il recupero agentico aggiunge latenza all'elaborazione delle query, ma ne costituisce la soluzione aggiungendo queste funzionalità:

  • Legge la cronologia delle chat come input per la pipeline di recupero.
  • Decostruisce una query complessa che contiene più "richieste" nelle parti del componente. Ad esempio: "trovami un hotel vicino alla spiaggia, con il trasporto aeroportuale, e questo è a pochi passi da ristoranti vegetariani".
  • Riscrive una query originale in più sottoquery tramite mappe di sinonimi (facoltative) e parafrasi generate da LLM.
  • Corregge gli errori di ortografia.
  • Esegue tutte le sottoquery contemporaneamente.
  • Restituisce un risultato unificato come singola stringa. In alternativa, è possibile estrarre parti della risposta per la soluzione. I metadati relativi all'esecuzione delle query e ai dati di riferimento sono inclusi nella risposta.

Il recupero agentico richiama l'intera pipeline di elaborazione delle query più volte per ogni sottoquery, ma lo fa in parallelo, mantenendo l'efficienza e le prestazioni necessarie per un'esperienza utente ragionevole.

Nota

L'inclusione di un LLM nella pianificazione delle query aggiunge latenza a una pipeline di query. È possibile attenuare gli effetti usando modelli più veloci, ad esempio gpt-4o-mini e riepilogando i thread di messaggio. È possibile ridurre al minimo la latenza e i costi impostando proprietà che limitano l'elaborazione LLM. Puoi anche escludere del tutto l'elaborazione LLM e utilizzare solo la ricerca testuale ed ibrida, insieme alla tua logica di pianificazione delle query.

Architettura e flusso di lavoro

Il recupero agentico è progettato per esperienze di ricerca conversazionali che usano un LLM per suddividere in modo intelligente query complesse. Il sistema coordina più servizi Azure per offrire risultati di ricerca completi.

Diagramma del flusso di lavoro di recupero agentico usando una query di esempio.

Come funziona

Il processo di recupero agentico funziona nel modo seguente:

  1. Avvio del flusso di lavoro: l'applicazione chiama una Knowledge Base con un'azione di recupero che fornisce una cronologia di query e conversazioni.

  2. Pianificazione delle query: una knowledge base invia la cronologia di query e conversazioni a un LLM, che analizza il contesto e suddivide le domande complesse in sottoquery incentrate. Questo passaggio è automatizzato e non personalizzabile.

  3. Esecuzione di query: la Knowledge Base invia le sottoquery alle origini delle informazioni. Tutte le sottoquery vengono eseguite contemporaneamente e possono essere parole chiave, vettore e ricerca ibrida. Ogni sottoquery viene sottoposta a un riordinamento semantico per individuare le corrispondenze più rilevanti. I riferimenti vengono estratti e conservati a scopo di citazione.

  4. Sintesi dei risultati: il sistema combina tutti i risultati in una risposta unificata con tre parti: contenuto unito, riferimenti all'origine e dettagli di esecuzione.

L'indice di ricerca determina l'esecuzione delle query e le ottimizzazioni che si verificano durante l'esecuzione delle query. In particolare, se l'indice include campi di testo e vettore ricercabili, viene eseguita una query ibrida. Se l'unico campo ricercabile è un campo vettoriale, viene usata solo la ricerca vettoriale pura. La configurazione semantica dell'indice, oltre ai profili di punteggio facoltativi, alle mappe sinonimiche, agli analizzatori e ai normalizzatori (se si aggiungono filtri) vengono tutti usati durante l'esecuzione della query. È necessario avere valori predefiniti denominati per una configurazione semantica e un profilo di punteggio.

Componenti obbligatori

Componente Servizio Ruolo
LLM Azure OpenAI Crea sottoquery dal contesto della conversazione e successivamente usa i dati di base per la generazione di risposte
Knowledge Base Azure AI Search Orchestra la pipeline, collegandosi al tuo LLM e gestendo i parametri di query
Origine delle conoscenze Azure AI Search Esegue il wrapping dell'indice di ricerca con le proprietà relative all'utilizzo della Knowledge Base
Indice di ricerca Azure AI Search Archivia il contenuto ricercabile (testo e vettori) con la configurazione semantica
Ranker semantico Azure AI Search Usato internamente dalla pipeline di recupero agente per il riordinamento dei risultati in base alla pertinenza (riordinamento L2)

Requisiti di integrazione

L'applicazione guida la pipeline chiamando la Knowledge Base e gestendo la risposta. La pipeline restituisce dati di base passati a un LLM per la generazione di risposte nell'interfaccia di conversazione. Per informazioni dettagliate sull'implementazione, consultare Esercitazione: Creare una soluzione completa di recupero dati agentico.

Nota

Per la pianificazione delle query sono supportati solo i modelli gpt-4.1 e gpt-5. È possibile usare qualsiasi modello per la generazione di risposte finale.

Disponibilità e prezzi

Il recupero agentico è disponibile nelle aree selezionate. Le fonti di conoscenza e le knowledge base hanno anche limiti massimi che variano in base al piano tariffario e allo sforzo di ragionamento nel recupero.

Fatturazione

Il recupero agentico comporta addebiti per due servizi:

  • Azure AI Search addebita per i token di recupero consumati durante l'esecuzione della sottoquery e la classificazione semantica. Il piano gratuito (di default) fornisce un quota di token mensile. Il piano standard abilita i prezzi con pagamento in base al consumo dopo l'utilizzo della quota gratuita. Per ulteriori informazioni, vedere Abilitare o disabilitare la fatturazione agentica.

  • Azure OpenAI fattura per i token di input e output usati nella pianificazione delle query basata su LLM e nella sintesi delle risposte. I prezzi sono sempre con pagamento in base al consumo e in base al modello assegnato alla knowledge base. Gli addebiti vengono visualizzati nella fattura Azure OpenAI. Per le tariffe, vedere prezzi Azure OpenAI.

La seguente tabella confronta la comparazione dei costi tra la pipeline classica a singola interrogazione e la pipeline di recupero agentico a multi-interrogazione. Nella pipeline classica il componente fatturabile è il ranker semantico.

Aspetto Pipeline classica Recupero agentico
Unità Basato su query Basato su token
Costo per unità Costo uniforme per ogni query Costo variabile per token (dipende dal ragionamento)
Stima dei costi Stimare il numero di query Stimare l'utilizzo dei token
Indennità gratuita Indennità di query gratuita mensile Assegnazione mensile gratuita di token

Esempio: Stimare i costi

Questo esempio illustra il processo di stima dei costi per la pianificazione delle query e l'esecuzione di query, ma non per la sintesi delle risposte. I costi potrebbero essere inferiori. Per le tariffe correnti, vedere i prezzi di Azure AI Search e i prezzi di Azure OpenAI.

Per stimare i costi del piano di interrogazione a consumo in Azure OpenAI, si supponga che gpt-4o-mini:

  • 15 centesimi per 1 milione di token di input.
  • 60 centesimi per 1 milione di token di output.
  • 2.000 token di input per dimensioni medie della conversazione di chat.
  • 350 token per le dimensioni medie del piano di output.

Costi stimati di fatturazione per l'esecuzione di query

Per stimare i conteggi token di recupero agentico, iniziate con un'idea delle caratteristiche di un documento medio nel vostro indice. Ad esempio, è possibile approssimare:

  • 10.000 blocchi, dove ogni blocco è uno o due paragrafi di un PDF.
  • 500 tokeni per blocco.
  • Ogni sottoquery riordina fino a un massimo di 50 blocchi.
  • In generale, sono presenti tre sottoquery per piano di interrogazione.

Calcolo del prezzo di esecuzione

  1. Supponiamo di effettuare 2.000 recuperi agentici con tre sottoquery per schema. In questo modo vengono fornite circa 6.000 query totali.

  2. Rerank 50 blocchi per sottoquery, cioè 300.000 blocchi totali.

  3. Il blocco medio è di 500 token, quindi il totale dei token per il riordinamento è di 150 milioni.

  4. Dato un prezzo ipotetico di 0,022 per token, $3,30 è il costo totale per il riordino in dollari statunitensi.

  5. Passaggio ai costi della strategia di interrogazione: 2.000 token di input moltiplicati per 2.000 recuperi agentici pari a 4 milioni di token di input per un totale di 60 centesimi.

  6. Stimare i costi di uscita basandosi su una media di 350 token. Se moltiplichiamo 350 per 2.000 recuperi agentici, otteniamo un totale di 700.000 token di output per 42 centesimi.

Mettendo tutto insieme, si pagherà circa $3,30 per il recupero agentico in Azure AI Search, 60 centesimi per i token di input in Azure OpenAI e 42 centesimi per i token di output in Azure OpenAI, per $1,02 per il totale della pianificazione delle query. Il costo combinato per l'esecuzione completa è $4,32.

Suggerimenti per controllare i costi

  • Esaminare il registro delle attività nella risposta per esaminare quali query sono state emesse a quali sorgenti e i parametri utilizzati. È possibile eseguire nuovamente tali query sugli indici e usare un tokenizer pubblico per stimare i token e confrontare l'utilizzo segnalato dall'API. La ricostruzione precisa di una query o di una risposta non è tuttavia garantita. I fattori includono il tipo di origine delle informazioni, ad esempio dati Web pubblici o un'origine di conoscenza remota SharePoint basata su un'identità utente, che può influire sulla riproduzione delle query.

  • Ridurre il numero di fonti di conoscenza (indici); consolidare contenuti può ridurre il volume di fan-out e di token.

  • Ridurre lo sforzo di ragionamento per ridurre l'utilizzo di LLM durante la pianificazione delle query e l'espansione delle query (ricerca iterativa).

  • Organizzare il contenuto in modo che le informazioni più rilevanti possano essere trovate con un minor numero di origini e documenti (ad esempio, riepiloghi o tabelle curati).

Come iniziare

Per creare una soluzione di recupero agentico, è possibile usare il portale di Azure, le API REST o un pacchetto Azure SDK che fornisce la funzionalità.

Passaggio successivo