Delen via


Agentgerichte opvragen in Azure AI Search

Opmerking

Deze functie is momenteel beschikbaar als openbare preview-versie. Deze preview wordt geleverd zonder service level agreement en wordt niet aanbevolen voor productieworkloads. Bepaalde functies worden mogelijk niet ondersteund of hebben mogelijk beperkte mogelijkheden. Voor meer informatie, zie Aanvullende Gebruiksvoorwaarden voor Microsoft Azure Previews.

Wat is agentisch ophalen? In Azure AI Search is het ophalen van agents een nieuwe pijplijn met meerdere query's die is ontworpen voor complexe vragen van gebruikers of agents in chat- en copilot-apps. Het is bedoeld voor RAG-patronen (Retrieval Augmented Generation) en agent-naar-agent-werkstromen.

Dit is wat het doet:

  • Maakt gebruik van een LLM (Large Language Model) om een complexe query op te splitsen in kleinere, gerichte subquery's voor een betere dekking van uw geïndexeerde inhoud. Subquery's kunnen chatgeschiedenis bevatten voor extra context.

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

  • Combineert de beste resultaten in een geïntegreerd antwoord dat een LLM kan gebruiken om antwoorden te genereren met uw eigen inhoud.

  • Het antwoord is modulair maar uitgebreid in de wijze waarop het ook een queryplan en brondocumenten bevat. U kunt ervoor kiezen om alleen de zoekresultaten als grondgegevens te gebruiken of de LLM aan te roepen om een antwoord te formuleren.

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

Programmatisch wordt agentisch ophalen ondersteund via een nieuw Knowledge Base-object in de preview-pakketten 2025-11-01 en in Azure SDK Preview-pakketten die de functie bieden. Het antwoord op het ophalen van een knowledge base is ontworpen voor downstreamverbruik door andere agents en chat-apps.

Waarom gebruik maken van op agentschap gebaseerd terughalen

Er zijn twee toepassingsscenario's voor agent retrieval. Ten eerste is het de basis van de Foundry IQ-ervaring in de Microsoft Foundry (nieuwe) portal. Het biedt de kennislaag voor agentoplossingen in Microsoft Foundry. Ten tweede is het de basis voor aangepaste agentische oplossingen die u maakt met behulp van de Azure AI Search-API's.

U moet agentisch ophalen gebruiken wanneer u agents en apps de meest relevante inhoud wilt bieden voor het beantwoorden van moeilijkere vragen, waarbij gebruik wordt gemaakt van chatcontext en uw eigen inhoud.

Het agentische aspect is een redeneringsstap in de verwerking van queryplanning die wordt uitgevoerd door een ondersteund LLM (Large Language Model) dat u aanlevert. De LLM analyseert het volledige chatgesprek om de onderliggende informatiebehoefte te identificeren. In plaats van één algemene query worden samengestelde vragen onderverdeeld in gerichte subquery's op basis van: gebruikersvragen, chatgeschiedenis en aanvraagparameters. De subquery's zijn gericht op uw geïndexeerde documenten (tekst zonder opmaak en vectoren) in Azure AI Search. Deze hybride benadering zorgt ervoor dat zowel trefwoordovereenkomsten als semantische overeenkomsten in één keer worden weergegeven, waardoor de terugroepwaarde aanzienlijk wordt verbeterd.

Het ophaalonderdeel is de mogelijkheid om subquery's tegelijk uit te voeren, resultaten samen te voegen, resultaten semantisch te rangschikken en een driedelig antwoord te retourneren dat grondgegevens bevat voor de volgende gesprekswisseling, verwijzingsgegevens, zodat u de broninhoud kunt inspecteren en een activiteitenplan waarin de stappen voor het uitvoeren van query's worden weergegeven.

Query-uitbreiding en parallelle uitvoering, plus het antwoord op ophalen, zijn de belangrijkste mogelijkheden van agentisch ophalen die het de beste keuze maken voor generatieve AI-toepassingen (RAG).

Diagram van een complexe query met impliciete context en een opzettelijk typefout.

Agentisch ophalen voegt latentie toe aan het verwerken van query's, maar het maakt het goed door deze mogelijkheden toe te voegen:

  • Leest de chatgeschiedenis in als invoer voor de haalpijplijn.
  • Het deconstrueert een complexe query die meerdere 'vragen' bevat in componenten. Bijvoorbeeld: "vind me een hotel in de buurt van het strand, met vervoer naar de luchthaven en dat is op loopafstand van vegetarische restaurants."
  • Hiermee herschrijft u een oorspronkelijke query in meerdere subquery's met behulp van synoniemenkaarten (optioneel) en door LLM gegenereerde parafrasering.
  • Corrigeert spelfouten.
  • Hiermee worden alle subquery's tegelijk uitgevoerd.
  • Voert een uniform resultaat uit als één tekenreeks. U kunt ook delen van het antwoord voor uw oplossing extraheren. Metagegevens over het uitvoeren van query's en referentiegegevens worden opgenomen in het antwoord.

Agentic retrieval roept de volledige queryverwerkingspijplijn meerdere keren aan voor elke subquery, maar doet dit parallel, waarbij de efficiëntie en prestaties behouden blijven die nodig zijn voor een goede gebruikerservaring.

Opmerking

Het opnemen van een LLM in de queryplanning voegt latentie toe aan een querypijplijn. U kunt de effecten beperken met behulp van snellere modellen, zoals gpt-4o-mini, en het samenvatten van de berichtthreads. U kunt latentie en kosten minimaliseren door eigenschappen in te stellen die LLM-verwerking beperken. U kunt LLM-verwerking ook helemaal uitsluiten voor alleen tekst en hybride zoekopdrachten en uw eigen logica voor queryplanning.

Architectuur en werkstroom

Agentieve retrieval is ontworpen voor gespreksmatige zoekervaringen die een LLM gebruiken om complexe query's op intelligente wijze op te splitsen. Het systeem coördineert meerdere Azure-services om uitgebreide zoekresultaten te leveren.

Diagram van de workflow voor agentisch ophalen met behulp van een voorbeeldquery.

Hoe het werkt

Het agent-georiënteerde ophaalproces werkt als volgt:

  1. Werkstroominitiatie: uw toepassing roept een knowledge base aan met een actie ophalen die een query- en gespreksgeschiedenis biedt.

  2. Queryplanning: Een knowledge base verzendt uw query- en gespreksgeschiedenis naar een LLM, waarmee de context wordt geanalyseerd en complexe vragen worden opgesplitst in gerichte subquery's. Deze stap is geautomatiseerd en kan niet worden aangepast.

  3. Queryuitvoering: de knowledge base verzendt de subquery's naar uw kennisbronnen. Alle subquery's worden gelijktijdig uitgevoerd en kunnen trefwoorden, vectoren en 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 met drie delen: samengevoegde inhoud, bronverwijzingen en uitvoeringsdetails.

Uw zoekindex bepaalt de uitvoering van query's en eventuele optimalisaties die optreden tijdens het uitvoeren van query's. Als uw index doorzoekbare tekst- en vectorvelden bevat, wordt een hybride query uitgevoerd. Als het enige doorzoekbare veld een vectorveld is, wordt alleen pure vectorzoekopdrachten gebruikt. De semantische indexconfiguratie, plus optionele scoreprofielen, synoniemenkaarten, analysefuncties en normalizers (als u filters toevoegt) worden allemaal gebruikt tijdens het uitvoeren van query's. U moet benoemde standaardwaarden hebben voor een semantische configuratie en een scoreprofiel.

Vereiste onderdelen

Onderdeel Dienst Rol
LLM Azure OpenAI Hiermee maakt u subquery's op basis van gesprekscontext en gebruikt u later grondgegevens voor het genereren van antwoorden
Knowledge base Azure AI Search De pijplijn organiseren, verbinding maken met uw LLM en queryparameters beheren
Kennisbron Azure AI Search Verpakt de zoekindex met eigenschappen die betrekking hebben op het gebruik van knowledge base
Zoekindex Azure AI Search Slaat uw doorzoekbare inhoud (tekst en vectoren) op met semantische configuratie
Semantische rangschikking Azure AI Search Vereist onderdeel waarmee resultaten voor relevantie opnieuw worden gerankt (L2-herrankering)

Integratievereisten

Uw toepassing stuurt de pijplijn aan door de kennisbank aan te roepen en de respons te verwerken. De pijplijn retourneert grondgegevens die u doorgeeft aan een LLM voor het genereren van antwoorden in uw gespreksinterface. Zie Handleiding: Een end-to-end agentgerichte ophaaloplossing bouwen voor implementatiedetails.

Opmerking

Alleen gpt-4o-, gpt-4.1- en gpt-5-seriemodellen worden ondersteund voor het plannen van query's. U kunt elk model gebruiken voor het genereren van definitieve antwoorden.

Aan de slag

Als u een oplossing voor agentische opvraging wilt maken, kunt u het Azure portal, de nieuwste preview REST API's of een preview Azure SDK-pakket gebruiken dat de functionaliteit biedt.

Op dit moment biedt de portal alleen ondersteuning voor het maken van zoekindex- en blobkennisbronnen. Andere typen kennisbronnen moeten programmatisch worden gemaakt.

Beschikbaarheid en prijzen

Agentgerichte gegevensopvraging is beschikbaar in geselecteerde regio's. Kennisbronnen en knowledge bases hebben ook maximale limieten die variëren per servicelaag.

Het heeft een afhankelijkheid van Premium-functies. Als u de semantische rangschikking voor uw zoekservice uitschakelt, schakelt u in feite de agentische opvraging uit.

Plannen Description
Gratis Een zoekservice op gratis niveau biedt 50 miljoen gratis agentredeneringstokens per maand. Op hogere lagen kunt u kiezen tussen het gratis abonnement (standaard) en het standaardabonnement.
Standaard Het standaardabonnement hanteert betalen naar gebruik zodra het maandelijkse gratis quotum is gebruikt. Nadat het gratis quotum is gebruikt, worden er extra kosten in rekening gebracht voor elk extra 1 miljoen agentische redeneringstokens. U ontvangt geen melding wanneer de overgang plaatsvindt. Zie de pagina met prijzen voor Azure AI Search voor meer informatie over kosten per valuta.

Facturering op basis van tokens voor op LLM gebaseerde queryplanning en antwoordsynthese (optioneel) is betalen per gebruik in Azure OpenAI. Het is een token dat is gebaseerd op zowel invoer- als uitvoertokens. Het model dat u aan de Knowledge Base toewijst, is het model waarvoor kosten voor tokengebruik in rekening worden gebracht. Als u bijvoorbeeld gpt-4o gebruikt, worden de tokenkosten weergegeven in de factuur voor gpt-4o.

Facturering op basis van tokens voor agentgebaseerd ophalen is het aantal tokens dat door elke subquery wordt geretourneerd.

Kenmerk Klassieke pijplijn met één query Pijplijn voor agentgestuurd ophalen van meerdere query's
Unit Queries (1.000 queries) per eenheid van valuta Op basis van tokens (1 miljoen tokens per valuta-eenheid)
Kosten per eenheid Uniforme kosten per query Uniforme kosten per token
Kostenschatting Schat aantal query's Tokengebruik schatten
Gratis laag 1.000 gratis zoekopdrachten 50 miljoen gratis tokens

Voorbeeld: Kosten schatten

Agentisch ophalen heeft twee factureringsmodellen: facturering van Azure OpenAI (queryplanning en, indien ingeschakeld, antwoordsynthese) en facturering van Azure AI Search voor agentisch ophalen.

In dit prijsvoorbeeld wordt antwoordsynthese weggelaten, maar wordt het schattingsproces geïllustreerd. Uw kosten kunnen lager zijn. Zie prijzen voor Azure OpenAI voor de werkelijke prijs van transacties.

Geschatte factureringskosten voor queryplanning

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 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 agentgerichte verzoeken maken met drie subvraag per plan. Dit geeft ons ongeveer 6.000 totale query's.

  2. Herindelen van 50 segmenten per subquery, wat 300.000 segmenten in totaal 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. Verdergaand met queryplankosten: 2 000 invoertokens vermenigvuldigd met 2 000 agentische opvragingen komt overeen met 4 miljoen invoertokens voor een totaal van 60 cent.

  6. Schat de uitvoerkosten op basis van gemiddeld 350 tokens. Als we 350 vermenigvuldigen met 2.000 agent-gestuurde ophaalacties, krijgen we in totaal 700.000 uitvoertokens voor 42 cent.

Als u alles samenbrengt, betaalt u ongeveer $3,30 voor agentische opvraging in Azure AI Search, 60 cent voor invoertokens in Azure OpenAI en 42 cent voor uitvoertokens in Azure OpenAI, voor een totaal van $1,02 voor 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 van invloed kan zijn op de reproductie van query's.

  • Verminder het aantal kennisbronnen (indexen); het consolideren van inhoud kan de fan-out en het tokenvolume 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).