Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Annotazioni
Questa funzionalità è attualmente disponibile in anteprima pubblica. Questa anteprima viene fornita senza un contratto di servizio e non è consigliata per i carichi di lavoro di produzione. Alcune funzionalità potrebbero non essere supportate o potrebbero presentare funzionalità limitate. Per altre informazioni, vedere le Condizioni supplementari per l'uso delle anteprime di Microsoft Azure.
Che cos'è il recupero agentico? In Azure AI Search il recupero agentico è una nuova pipeline multi-query progettata per domande complesse poste da utenti o agenti nelle app chat e Copilot. È destinato a modelli di Generazione Aumentata dal Recupero (RAG) e flussi di lavoro tra agenti.
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 query secondarie in parallelo. Ogni query secondaria viene riclassificata semanticamente per promuovere le corrispondenze più pertinenti.
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 nuovo oggetto Knowledge Base nell'anteprima 2025-11-01 e nei pacchetti di anteprima di Azure SDK che forniscono la funzionalità. 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
È 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 agentico è un passaggio di ragionamento nell'elaborazione della pianificazione delle query eseguita da un modello LLM (Large Language Model) supportato. LLM analizza l'intero thread di chat per identificare le informazioni sottostanti necessarie. Invece di una singola query generica, l'LLM suddivide le domande composte in sottoquery mirate in base a: le domande degli utenti, la cronologia della chat e i parametri della richiesta. Le sottoquery hanno come destinazione i documenti indicizzati (testo normale e vettori) in Ricerca di intelligenza artificiale di Azure. 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).
Il recupero agentico aggiunge latenza all'elaborazione delle query, ma ne costituisce la soluzione aggiungendo queste funzionalità:
- Utilizza la cronologia delle chat come input per la pipeline di recupero.
- Decostruisce una query complessa che contiene più "richieste" nelle parti componenti. 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 utilizzando 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.
Annotazioni
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. È possibile escludere completamente l'elaborazione LLM per utilizzare solo la ricerca di testo e ibrida e la propria logica di pianificazione delle query.
Architettura e flusso di lavoro
Il recupero agentico è progettato per esperienze di ricerca conversazionali che utilizzano un LLM per suddividere intelligentemente le query complesse. Il sistema coordina più servizi di Azure per offrire risultati completi della ricerca.
Come funziona
Il processo di recupero agentico funziona nel modo seguente:
Avvio del flusso di lavoro: l'applicazione chiama una Knowledge Base con un'azione di recupero che fornisce una cronologia di query e conversazioni.
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.
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 riordinamento semantico per trovare le corrispondenze più rilevanti. I riferimenti vengono estratti e conservati a scopo di citazione.
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 | Ricerca di intelligenza artificiale di Azure | Orchestra la pipeline, si connette al tuo LLM e gestisce i parametri di query. |
| Fonte delle informazioni | Ricerca di intelligenza artificiale di Azure | Esegue il wrapping dell'indice di ricerca con le proprietà relative all'utilizzo della Knowledge Base |
| Indice di ricerca | Ricerca di intelligenza artificiale di Azure | Archivia il contenuto ricercabile (testo e vettori) con la configurazione semantica |
| Classificatore semantico | Ricerca di intelligenza artificiale di Azure | Componente obbligatorio che classifica i risultati per pertinenza (reranking 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, vedere Esercitazione: Costruire una soluzione agentica di recupero end-to-end.
Annotazioni
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.
Come iniziare
Per creare una soluzione di recupero agentico, è possibile usare il portale di Azure, le API REST di anteprima più recenti o un pacchetto di anteprima Azure SDK che fornisce la funzionalità.
Attualmente, il portale supporta solo la creazione di un indice di ricerca e fonti di conoscenza blob. È necessario creare altri tipi di fonti di conoscenza programmaticamente.
- Guida introduttiva: Usare il recupero agentico nel portale di Azure
- Guida introduttiva: Usare il recupero agentico in Ricerca di intelligenza artificiale di Azure (C#, Java, JavaScript, Python, TypeScript, REST)
Disponibilità e prezzi
Il recupero agentico è disponibile nelle aree selezionate. Le origini delle conoscenze e le knowledge base hanno anche limiti massimi che variano in base al livello di servizio.
Ha una dipendenza dalle funzionalità Premium. Se si disabilita il classificatore semantico per il servizio di ricerca, si disabilita effettivamente il recupero agentico.
| Plan | Description |
|---|---|
| Gratuito | Un servizio di ricerca di livello gratuito offre 50 milioni di token di ragionamento agentico gratuiti al mese. Nei livelli superiori è possibile scegliere tra il piano gratuito (impostazione predefinita) e il piano standard. |
| Normale | Il piano standard è con pagamento in base al consumo dopo l'utilizzo della quota gratuita mensile. Una volta usata la quota gratuita, viene addebitata una tariffa aggiuntiva per ogni milione di token di ragionamento agentico aggiuntivi. Non si riceve una notifica quando si verifica la transizione. Per altre informazioni sugli addebiti in base alla valuta, vedere la pagina dei prezzi di Ricerca di intelligenza artificiale di Azure. |
La fatturazione basata su token perper la pianificazione delle query basata su LLM e la sintesi delle risposte (facoltativa) è con pagamento in base al consumo in Azure OpenAI. è basata su token sia per i token di input che per i token di output. Il modello assegnato alla Knowledge Base è quello addebitato per l'utilizzo dei token. Ad esempio, se si usa gpt-4o, l'addebito del token viene visualizzato nella fattura per gpt-4o.
La fatturazione basata su token per il recupero agentico corrisponde al numero di token restituiti da ogni sottoquery.
| Aspetto | Pipeline a query singola classica | Pipeline di recupero agentica multiquering |
|---|---|---|
| Unità | Basata su query (1.000 query) per unità di valuta | Basato su token (1 milione di token per unità di valuta) |
| Costo per unità | Costo unitario per query | Costo uniforme per token |
| Stima dei costi | Stimare il numero di query | Stimare l'utilizzo dei token |
| Livello gratuito | 1.000 query gratuite | 50 milioni di token gratuiti |
Esempio: Stimare i costi
Il recupero agentico ha due modelli di fatturazione: fatturazione da Azure OpenAI (pianificazione delle query e, se abilitata, sintesi delle risposte) e fatturazione da Ricerca di intelligenza artificiale di Azure per il recupero agentico.
Questo esempio di prezzi omette la sintesi delle risposte, ma illustra il processo di stima. I costi potrebbero essere inferiori. Per il prezzo effettivo delle transazioni, vedere Prezzi di Azure OpenAI.
Costi di fatturazione stimati per la pianificazione delle query
Per stimare i costi del piano di query con pagamento in base al 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 delle query
Per stimare il conteggio dei token di recupero agentico, inizia con un'idea dell'aspetto di un documento medio nell'indice. Ad esempio, è possibile approssimare:
- 10.000 blocchi, dove ogni blocco è uno o due paragrafi di un PDF.
- 500 token per blocco.
- Ogni sottoquery viene riclassificata fino a 50 blocchi.
- In media, sono presenti tre sottoquery per piano di query.
Calcolo del prezzo di esecuzione
Si supponga di effettuare 2.000 recuperi agentici con tre sottoquery per piano. In questo modo vengono fornite circa 6.000 query totali.
Riclassificare 50 blocchi per sottoquery, ovvero 300.000 blocchi totali.
Il blocco medio è di 500 token, quindi il totale dei token per il riordinamento è 150 milioni.
Dato un prezzo ipotetico di 0,022 per token, $3,30 è il costo totale per il riordino in dollari USA.
Passaggio ai costi del piano query: 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.
Stimare i costi di produzione in base a una media di 350 token. Moltiplicando 350 per 2.000 recuperi agentici otteniamo un totale di 700.000 token di output per un totale di 42 centesimi.
Combinando tutti questi elementi, si pagheranno circa 3,30 USD per il recupero agente 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 un totale di 1,02 USD per la pianificazione delle query. Il costo combinato per l'esecuzione completa è $4,32.
Suggerimenti per controllare i costi
Esaminare il registro delle attività nella risposta fornita per scoprire quali query sono state eseguite a quali origini e i parametri usati. È 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 fonti di conoscenza, come i dati web pubblici o una fonte di conoscenza SharePoint remota basata su un'identità utente, che può influire sulla riproduzione delle query.
Ridurre il numero di fonti di conoscenza (indici); il consolidamento del contenuto può ridurre il fan-out e il volume 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).