Recupero agentico in Azure AI Search

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

Ecco cosa fa:

• Può usare un modello di linguaggio di grandi dimensioni (LLM) per suddividere una query complessa in sottoquery più piccole e incentrate per una migliore copertura su contenuto proprietario ed esterno. 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 fondate.

• Può restituire riferimenti all'origine e un log attività insieme al contenuto unito, in modo da poter usare solo i dati di base o passarli a un LLM per una risposta completa.

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

Perché usare il recupero agentico?

Esistono due casi d'uso per il recupero agentico. Prima di tutto, consente a Foundry IQ nel portale di Microsoft Foundry di fornire il livello di conoscenza per le soluzioni agente. In secondo luogo, è la base per le soluzioni agentiche personalizzate compilate usando le API Azure AI Search.

Usa il retrieval agentico quando vuoi fornire ad agenti e app i contenuti più pertinenti per rispondere a domande più complesse, attingendo al contesto della chat, ai tuoi contenuti proprietari e a fonti esterne.

Il recupero agentico introduce latenza rispetto a una pipeline basata su una singola query, ma gestisce query complesse che una singola query non è in grado di gestire. Ad esempio, può gestire:

• Domande con più richieste, come "trovami un hotel vicino alla spiaggia, con servizio di trasporto da/per l'aeroporto e raggiungibile a piedi da ristoranti vegetariani."

• Domande che dipendono dal contesto precedente nella conversazione.

• Query che beneficiano della riformulazione, utilizzando mappe di sinonimi e parafrasi generate da LLM per ampliare la copertura nell’insieme dei contenuti.

• Errori di ortografia.

Architettura e flusso di lavoro

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: Con un livello di sforzo di ragionamento per il recupero di low e medium la base di conoscenza invia la tua query e la cronologia della conversazione a un LLM, che genera sottoquery mirate. Con un livello di impegno minimal, questo passaggio viene saltato e le query vengono inoltrate direttamente alle fonti di conoscenza. Il livello di ragionamento è predefinito su low e viene configurato nella base di conoscenza.

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 o 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. Il contenuto unito viene sempre restituito. I riferimenti all'origine e un log attività di esecuzione sono facoltativi.

Components

Per tutti gli scenari di recupero agentico, sono necessarie una base di conoscenza e almeno una fonte di conoscenza. Gli altri componenti sono facoltativi e dipendono dalla configurazione.

Requisiti di integrazione

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

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 query e la pipeline di recupero agentico a più query. Nella pipeline classica il componente fatturabile è il ranker semantico.

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, iniziare con un'idea delle caratteristiche di un documento medio nell'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 piano. In questo modo vengono fornite circa 6.000 query totali.

2. Riclassificare 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. Passando ai costi del piano 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.

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 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); 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).

Come iniziare

Per creare una soluzione di recupero agentico, è possibile usare il portale di Azure, Microsoft portale Foundry (nuovo), le API REST o un pacchetto Azure SDK equivalente.

Passaggio successivo