Agentisch ophalen in Azure AI Zoeken

In Azure AI Zoeken is agentisch ophalen een pijplijn met meerdere query's die is ontworpen voor complexe vragen van gebruikers of agents in chat- en copilot-apps. Het is bedoeld voor opvraging-versterkte generatie patronen en werkstromen voor agent-naar-agent.

Dit is wat agentgestuurd ophalen van informatie doet:

• Kan een LLM (Large Language Model) gebruiken om een complexe query op te splitsen in kleinere, gerichte subquery's voor een betere dekking ten opzichte van eigen en externe inhoud. Subquery's kunnen chatgeschiedenis bevatten voor extra context.

• Subquery's worden parallel uitgevoerd. Elke subquery wordt semantisch opnieuw gerangschikt om de meest relevante overeenkomsten te promoten.

• Combineert de beste resultaten tot één samenhangend antwoord dat een LLM kan gebruiken om goed onderbouwde antwoorden te genereren.

• Kan bronverwijzingen en een activiteitenlogboek naast de samengevoegde inhoud retourneren, zodat u alleen de grondgegevens kunt gebruiken of aan een LLM kunt doorgeven voor een volledig antwoord.

Deze pijplijn met hoge prestaties helpt u bij het genereren van hoogwaardige grondgegevens of antwoorden voor uw chattoepassing, met de mogelijkheid om snel complexe vragen te beantwoorden.

Waarom agentische gegevensophaling gebruiken?

Agentisch ophalen ondersteunt zowel beheerde als aangepaste ervaringen voor agents en apps. In de Microsoft Foundry-portal wordt Foundry IQ aangestuurd als een beheerde kennislaag voor agents. U kunt ook aangepaste agentische retrievaloplossingen ontwikkelen met behulp van de Azure-portal, de Search Service REST API of een ondersteunde Azure SDK.

Gebruik agentische retrieval wanneer u agents en apps wilt voorzien van de meest relevante content om lastigere vragen te beantwoorden, waarbij gebruik wordt gemaakt van chatcontext, uw eigen bedrijfseigen content en externe bronnen.

Agentisch ophalen voegt latentie toe in vergelijking met een pijplijn met één query, maar verwerkt de complexiteit van query's dat een enkele query niet kan. Het kan bijvoorbeeld het volgende verwerken:

• Vragen met meerdere vragen, zoals "vind me een hotel in de buurt van het strand, met vervoer naar de luchthaven en dat is op loopafstand van vegetarische restaurants."

• Vragen die afhankelijk zijn van eerdere context in het gesprek.

• Query’s die baat hebben bij herformulering, met behulp van synoniemenlijsten en door een LLM gegenereerde parafrases om de dekking van uw content te vergroten.

• Spelfouten.

Architectuur en werkstroom

Het agentische ophaalproces werkt als volgt:

1. Werkstroominitiatie: Uw toepassing roept een knowledge base aan met een ophaalactie die een query- en gespreksgeschiedenis biedt.

2. Queryplanning: Bij de redeneerinspanning voor ophalen van low en medium stuurt de kennisbank uw query en gesprekshistorie naar een LLM, die vervolgens gerichte deelquery's genereert. Bij een inspanning van minimal wordt deze stap overgeslagen en worden query’s rechtstreeks naar kennisbronnen gestuurd. Redeneerinspanning is standaard ingesteld op low en wordt geconfigureerd in de kennisbank.

3. Queryuitvoering: De knowledge base verzendt de subquery's naar uw kennisbronnen. Alle subquery's worden gelijktijdig uitgevoerd en kunnen trefwoorden, vectoren of hybride zoekopdrachten zijn. Elke subquery ondergaat semantische rerankering om de meest relevante overeenkomsten te vinden. Verwijzingen worden geëxtraheerd en bewaard voor bronvermeldingsdoeleinden.

4. Resultaatsynthese: Het systeem combineert alle resultaten in een uniform antwoord. Samengevoegde inhoud wordt altijd geretourneerd. Bronverwijzingen en een uitvoeringsactiviteitenlogboek zijn optioneel.

Components

Voor alle agentische ophaalscenario’s zijn een kennisbank en ten minste één kennisbron vereist. Andere onderdelen zijn optioneel en zijn afhankelijk van uw configuratie.

Integratievereisten

Uw toepassing stuurt de pijplijn aan door de kennisbank aan te roepen en het antwoord te verwerken. De pijplijn retourneert grondgegevens die u aan een LLM kunt doorgeven voor het genereren van antwoorden of rechtstreeks in uw gespreksinterface kunt gebruiken. Zie voor implementatiedetails Zelfstudie: Bouw een end-to-end agentische retrieval-oplossing.

Beschikbaarheid en prijzen

Agentische gegevensophaling is beschikbaar in bepaalde regio's. Kennisbronnen en knowledge bases hebben ook maximale limieten die variëren per prijscategorie en het ophalen van redeneringen.

Facturering

Het ophalen van gegevens door agenten brengt kosten met zich mee voor twee services:

• Azure AI Zoeken rekent kosten voor de tokens die verbruikt worden tijdens het ophalen en de uitvoering van een subquery, alsmede voor semantische rangschikking. Het gratis abonnement (standaard) biedt een maandelijkse tokenvergoeding. Het standaardabonnement maakt betalen per gebruik mogelijk nadat de gratis vergoeding is verbruikt. Zie Facturering voor agentisch ophalen in- of uitschakelen voor meer informatie.

• Azure OpenAI rekent voor invoer- en uitvoertokens die worden gebruikt in LLM-gebaseerde queryplanning en antwoordsynthese. Prijzen zijn altijd betalen per gebruik en op basis van het model dat u aan de Knowledge Base toewijst. Er worden kosten weergegeven op uw Azure OpenAI-factuur. Zie Azure Prijzen voor OpenAI voor tarieven.

De volgende tabel vergelijkt de facturering tussen de klassieke pijplijn met één query en de agentische ophaalpijplijn met meerdere query's. In de klassieke pijplijn is het factureerbare onderdeel semantic ranker.

Voorbeeld: Kosten schatten

In dit voorbeeld ziet u het kostenramingsproces voor het plannen en uitvoeren van query's, maar geen antwoordsynthese. Uw kosten kunnen lager zijn. Zie voor actuele tarieven Azure AI Zoeken prijzen en Azure OpenAI prijzen.

Als u de kosten van het queryplan wilt schatten als betalen per gebruik in Azure OpenAI, gaan we ervan uit dat gpt-4o-mini:

• 15 cent voor 1 miljoen invoertokens.
• 60 cent voor 1 miljoen uitvoertokens.
• 2000 invoertokens voor de gemiddelde grootte van chatgesprekken.
• 350 tokens voor de gemiddelde uitvoerplangrootte.

Geschatte factureringskosten voor het uitvoeren van query's

Als u het aantal agentische ophaaltokens wilt schatten, begint u met een idee van hoe een gemiddeld document in uw index eruitziet. U kunt bijvoorbeeld bij benadering het volgende doen:

• 10.000 segmenten, waarbij elk segment één tot twee alinea's van een PDF is.
• 500 tokens per blok.
• Elke subquery rerankeert maximaal 50 segmenten.
• Gemiddeld zijn er drie subquery's per query-plan.

De prijs van uitvoering berekenen

1. Stel dat we 2000 agentische ophaaltaken maken met drie subquery's per plan. Dit geeft ons ongeveer 6.000 totale query's.

2. Herindelen van 50 segmenten per subquery, wat in totaal 300.000 segmenten is.

3. Het gemiddelde segment is 500 tokens, dus het totale aantal tokens voor opnieuw rangschikken is 150 miljoen.

4. Gezien een hypothetische prijs van 0,022 per token, is $ 3,30 de totale kosten voor rerankering in Amerikaanse dollars.

5. Overstappen op queryplankosten: 2.000 invoertokens vermenigvuldigd met 2.000 agentische ophaalacties is gelijk aan 4 miljoen invoertokens, voor een totaal van 60 cent.

6. Schat de uitvoerkosten op basis van gemiddeld 350 tokens. Als we 350 met 2.000 agentische ophaalwaarden vermenigvuldigen, krijgen we 700.000 uitvoertokens voor een totaal van 42 cent.

Als u alles samenbrengt, betaalt u ongeveer $ 3,30 voor agentisch ophalen in Azure AI Zoeken, 60 cent voor invoertokens in Azure OpenAI en 42 cent voor uitvoertokens in Azure OpenAI, voor $ 1,02 voor het totaal van de queryplanning. De gecombineerde kosten voor de volledige uitvoering zijn $ 4,32.

Tips voor het beheren van kosten

• Bekijk het activiteitenlogboek in het antwoord om erachter te komen welke query's zijn uitgegeven aan welke bronnen en welke parameters zijn gebruikt. U kunt deze query's opnieuw uitvoeren op uw indexen en een openbare tokenizer gebruiken om tokens te schatten en te vergelijken met door API gerapporteerd gebruik. Nauwkeurige reconstructie van een query of antwoord wordt echter niet gegarandeerd. Factoren zijn onder andere het type kennisbron, zoals openbare webgegevens of een externe SharePoint kennisbron die is gebaseerd op een gebruikersidentiteit, die invloed kan hebben op de reproductie van query's.

• Verminder het aantal kennisbronnen (indexen); het consolideren van inhoud kan de fan-out en het volume aan tokens verlagen.

• Verlaag de redenering om het LLM-gebruik te verminderen tijdens het plannen van query's en het uitbreiden van query's (iteratieve zoekopdrachten).

• Organiseer inhoud zodat de meest relevante informatie kan worden gevonden met minder bronnen en documenten (bijvoorbeeld gecureerde samenvattingen of tabellen).

Aan de slag

Als u een oplossing voor het ophalen van agents wilt maken, kunt u de Azure-portal, Microsoft Foundry-portal (nieuwe) portal, REST API's of een equivalent Azure SDK-pakket gebruiken.

Volgende stap