Agentic RAG

Wat is agentic RAG?

Agentic RAG is retrieval-augmented generation met een planstap ervoor. Bij klassieke RAG gaat je vraag rechtstreeks naar de zoekindex, komen de best passende stukken terug, en schrijft het model daar een antwoord uit. Bij agentic RAG kijkt een model eerst naar je vraag en beslist het hoe het antwoord gezocht moet worden.

De reden dat dit bestaat, is dat één zoekopdracht niet één vraag dekt. Neem iets als "zoek een hotel aan het strand, met een shuttle naar de luchthaven, en op wandelafstand van een vegetarisch restaurant". Dat zijn drie aparte eisen in één zin. Eén zoekopdracht op je index matcht op een deel van de woorden en mist de rest. Splits je ze in drie zoekopdrachten, dan kan je de vraag wel beantwoorden.

Hetzelfde geldt voor vragen die steunen op wat er eerder in het gesprek gezegd is, en voor vragen met een tikfout erin. Een agent die het hele gesprek leest voor hij gaat zoeken, kan "en die andere dan" herschrijven tot een zoekopdracht die effectief iets vindt.

Wat de agent toevoegt aan gewoon zoeken

Azure AI Search heeft dit als een benoemde pijplijn ingebouwd, en de vier stappen die daar draaien zijn een goede beschrijving van wat agentic RAG overal betekent.

1. De zoekopdracht plannen
   Je vraag en de gespreksgeschiedenis gaan naar een taalmodel, dat een reeks gerichte deelvragen schrijft. Hier wordt een samengestelde vraag uit elkaar gehaald en hier wordt context uit eerdere beurten mee ingebakken.

2. Alles tegelijk uitvoeren
   Alle deelvragen gaan tegelijk naar je kennisbronnen. Elke deelvraag kan een zoekopdracht op trefwoorden zijn, een vectorzoekopdracht, of een combinatie van de twee. Je zit dus niet vast aan één zoekstijl voor de hele vraag.

3. Herrangschikken
   Bij elke deelvraag worden de resultaten op relevantie herschikt voor er iets doorgaat. Dat telt, want een deelvraag die vijftig kandidaten vindt, helpt je pas als de goede bovenaan komen te staan.

4. Samenvoegen
   Het systeem trekt alles samen tot één set materiaal om het antwoord op te baseren. Je kan er ook de bronverwijzingen en een activiteitenlog bij vragen, zodat je kan zien welke zoekopdrachten naar welke bron gestuurd zijn.

Dat laatste punt verdient aandacht. Die activiteitenlog is wat agentic RAG van een zwarte doos in iets verandert dat je kan debuggen. Als een antwoord fout is, kan je het zoekplan bekijken en zien of het model de verkeerde vraag stelde, of dat je inhoud het antwoord gewoon niet bevatte. Dat zijn twee totaal verschillende problemen met twee totaal verschillende oplossingen.

Sommige opstellingen zetten er nog een stap achter waarin het model zijn eigen antwoord bekritiseert en opnieuw gaat zoeken als het niet goed genoeg is. Daar verdient het woord agentic zichzelf pas echt: het systeem beslist zelf dat het nog niet klaar is.

Hoe het zich verhoudt tot klassieke RAG

Klassieke RAG is één vraag, één zoekopdracht, één antwoord. Het is snel, het is goedkoop, het valt makkelijk te doorgronden, en het is de juiste keuze voor de meeste rechttoe rechtaan opzoekingen. Als je gebruikers vragen "wat is onze garantietermijn op product X", dan heb je geen planstap nodig.

Agentic RAG pakt de vragen aan waar klassieke RAG stilletjes op faalt: meerdere eisen in één zin, een vervolgvraag die enkel in context betekenis heeft, of een vraag waarvan het antwoord verspreid zit over meerdere documenten die geen enkele zoekopdracht samenbrengt.

De ruil is helder. Agentic RAG voegt wachttijd toe tegenover een pijplijn met één zoekopdracht, en het voegt kosten toe, want je betaalt nu een model om te plannen bovenop het zoeken zelf. Microsoft zet dat gewoon zo in de eigen documentatie. Wat je ervoor terugkrijgt, is dat je een soort complexiteit aankan die met één zoekopdracht niet lukt.

Wat het kost

Er verandert iets aan de manier waarop je begroot, en daar worden mensen door verrast. Klassiek zoeken rekent per zoekopdracht af, met een voorspelbare kost per opdracht. Agentic retrieval rekent per token af, en de kost per vraag hangt af van hoeveel het model erover nadenkt.

In de opstelling van Azure krijg je twee facturen. De zoekdienst rekent de tokens aan die tijdens de deelvragen en het herrangschikken verbruikt worden, en Azure OpenAI rekent de input- en outputtokens aan van het model dat de zoekopdrachten plant. Je kost inschatten betekent dus tokenvolume inschatten en geen zoekopdrachten tellen.

Er zijn drie knoppen om dat onder controle te houden, en die zijn de moeite om te kennen voor je bouwt.

• Hoeveel het model mag nadenken. De pijplijn heeft niveaus. Op de laagste stand wordt de planstap volledig overgeslagen en gaat je vraag rechtstreeks naar de bronnen, waardoor het geheel gewoon weer klassiek zoeken wordt. Hogere standen kopen je meer planning en meer uitbreiding van de zoekopdracht.

• Het aantal kennisbronnen. Elke extra bron verbreedt de waaier, dus je inhoud samenbrengen verlaagt je tokenvolume rechtstreeks.

• Hoe je inhoud georganiseerd staat. Als het antwoord op een veelgestelde vraag in één samenvatting staat in plaats van verspreid over veertig documenten, dan vindt de pijplijn het met minder deelvragen.

Waar moet je op letten bij agentic RAG

Het repareert slechte inhoud niet. Een planstap maakt je zoeken slimmer en je documenten niet beter. Als er in je index drie tegenstrijdige versies van hetzelfde beleid staan, dan vindt agentic RAG ze alle drie sneller.

De wachttijd is voelbaar. Plannen, meerdere zoekopdrachten en herrangschikken duren langer dan één opzoeking. Achter een chatvenster waar iemand zit te wachten, merk je dat verschil. Denk dus na of de moeilijke vragen het waard zijn om de makkelijke trager te maken, of dat je eenvoudige vragen langs een goedkoper pad stuurt.

De rechten moeten de waaier overleven. Meerdere deelvragen op meerdere bronnen betekent meerdere kansen om iets terug te geven dat de gebruiker niet mag zien. Dat filteren moet bij de bron gebeuren en niet in het eindantwoord.

Lees de activiteitenlog voor je aan de prompt sleutelt. Als de kwaliteit tegenvalt, is de reflex om instructies te herschrijven. Kijk eerst welke deelvragen er effectief gegenereerd zijn. Heel vaak was het plan redelijk en zat het probleem in de inhoud.

De kost schaalt met de moeilijkheid en niet met het gebruik. Tweehonderd eenvoudige vragen kunnen minder kosten dan twintig ingewikkelde. Elke begroting die je op een gemiddelde kost per vraag bouwt, klopt in beide richtingen niet.