RAG en TRACE lossen verschillende problemen op. RAG is een softwareontwerp dat tekst ophaalt voor een AI-model voordat het antwoordt. TRACE is een onderzoeksmethode die toetst wat de bronnen bewijzen voordat iemand handelt. RAG werkt binnen een product, bij elke vraag. TRACE werkt rond één besluit. Je kunt ze samen gebruiken, en de meeste verwarring ontstaat als je aanneemt dat de een het werk van de ander doet.
Wat is RAG, in gewone taal?
RAG staat voor retrieval-augmented generation. Stel je een vraag, dan doorzoekt het systeem eerst een documentverzameling (een bedrijfswiki, een beleidsbibliotheek, een map met contracten), kiest het de passages die het meest relevant lijken en geeft het die aan een taalmodel, dat er het antwoord mee schrijft.
De naam komt uit een onderzoeksartikel uit 2020 van Patrick Lewis en collega’s, dat een tekstgenerator koppelde aan een doorzoekbare index van Wikipedia. Wat is RAG? gaat dieper op de methode in.
Wat is TRACE, in gewone taal?
TRACE is een methode in vijf stappen om onderzoek te controleren voordat er een besluit valt. De methode komt uit De geverifieerde research-loop van Len P. van der Hof, verkrijgbaar in het Nederlands en het Engels. Je hebt het boek niet nodig om ermee te werken.
- Target: koppel de vraag aan een besluit en formuleer de precieze claim die je moet toetsen.
- Retrieve: haal de bronnen zelf binnen, geen fragmenten of samenvattingen.
- Assess: beoordeel wat elke bron voor deze claim kan bewijzen. Elke bron krijgt een van de vier rollen (Primair, Secundair, Pleitend of Grijs), en geen van die rollen is een oordeel.
- Cross-check: vergelijk de bronnen per claim en herleid elke bron tot haar oorsprong. Drie artikelen die één persbericht herhalen, tellen als één oorsprong.
- Export: lever een gedateerde memo die onderscheid maakt tussen wat onderbouwd is en wat nog openstaat, met een eigenaar voor elk gat.
Wat is het verschil, naast elkaar gezet?
| RAG | TRACE | |
|---|---|---|
| Wat het is | Een softwareontwerp | Een onderzoeksmethode |
| Wie het uitvoert | Een systeem, automatisch, bij elke vraag | Een mens (met of zonder hulp van AI), voor één besluit |
| Hoofdvraag | Welke passages moet het model zien? | Wat bewijzen de bronnen, en mogen we ernaar handelen? |
| Resultaat | Een gegenereerd antwoord, liefst met bronvermelding | Een claimregister en een gedateerde besluitmemo |
| Typische fout | Ontbrekende, verouderde of verkeerde passage; het antwoord dwaalt af van de passage | Claim breder dan het bewijs; één oorsprong geteld als meerdere |
| Klaar als | Elke zin wordt gedekt door de passages die het model kreeg | Elke belangrijke claim heeft een status en elk gat een eigenaar |
| Framework op deze site | GRAIN | TRACE |
Hoe kan het document kloppen en de conclusie niet?
Een verzonnen voorbeeld. Een operationsteam vraagt zijn interne assistent: “Wat staat er in het incidentrapport over de oorzaak van de storing van dinsdag?” Het RAG-systeem haalt het actuele rapport op en antwoordt correct, met de juiste passage: een time-out bij een externe betaalprovider. Het ophalen deed zijn werk.
Een week later schrijft iemand in een planningsdocument: “Deze provider veroorzaakt het merendeel van onze mislukte betalingen.” De schrijver verwijst naar hetzelfde antwoord en stelt voor om van provider te wisselen.
De bronvermelding is echt. De passage klopt. Maar één incidentrapport kan niet vertellen wat het merendeel van de mislukte betalingen veroorzaakt. Daarvoor heb je een afgebakende periode nodig, een telling van alle mislukte betalingen, de oorzaak van elk geval en een blik op bewijs dat een andere kant op wijst.
RAG heeft die vraag nooit gekregen, dus kon het die ook niet fout beantwoorden. Bij TRACE wordt de bredere claim wél getoetst:
- Target formuleert de echte vraag: “Aandeel van de mislukte betalingen per oorzaak, afgelopen 90 dagen.”
- Retrieve verzamelt de betaallogs en alle incidentrapporten over die periode, niet alleen dat van dinsdag.
- Assess noteert dat het rapport van dinsdag primair bewijs is voor één incident, en voor niets meer.
- Cross-check vindt geen enkele bron voor “het merendeel”.
- Export legt de bevinding over het incident vast als onderbouwd, de claim over “het merendeel” als Unresolved, en zet de overstap op HOLD. Dat is het TRACE-woord voor: deze actie wacht tot een bij naam genoemde persoon het gat dicht of het risico formeel aanvaardt.
Welke van de twee heb ik nodig?
- Je bouwt een assistent die antwoordt op basis van je eigen documenten: RAG, gebouwd en gedebugd met GRAIN.
- Je moet iets besluiten op basis van externe bronnen (een markt, een concurrent, regelgeving, een leverancier): TRACE. AI-tools, RAG-systemen inbegrepen, kunnen helpen bij de Retrieve-stap.
- Mensen handelen naar de antwoorden van je RAG-assistent: allebei. RAG zorgt dat de juiste passage in het antwoord belandt. Een controle in de geest van TRACE bepaalt of dat antwoord de actie rechtvaardigt.
- Je hebt één document en één vraag: geen van beide. Open het document en lees het. Wanneer RAG gebruiken beschrijft wanneer het bouwen van RAG de verkeerde klus is.
Waar hoort GRAIN thuis?
GRAIN is het bijbehorende framework aan de kant van RAG. Het komt uit De RAG-engineer, ook verkrijgbaar in het Nederlands en het Engels, en benoemt de vijf plekken waar een retrievalsysteem kan haperen. De stapnamen blijven ook in de Nederlandse editie Engels:
- Gather corpora: welke documenten de doorzoekbare verzameling in mogen, met hun rechten en versies.
- Rank and rerank: kandidaat-passages vinden en ze daarna ordenen voor de vraag die echt gesteld is.
- Assemble context: kiezen welke passages naar het model gaan, in welke volgorde, binnen de invoerlimiet.
- Inspect failures: een onjuist antwoord herleiden tot de stap die het veroorzaakte.
- Navigate freshness: de verzameling actueel houden en laten zien hoe oud een antwoord kan zijn.
Wat is GRAIN? vertelt er meer over. In één zin: GRAIN controleert de pijplijn, TRACE controleert de claim.
Klopt een antwoord niet: wiens probleem is dat?
Benoem de kapotte stap voordat je iets repareert.
| Wat je ziet | Waar het misging | Wiens werk |
|---|---|---|
| Het antwoord leunt op een verouderd rapport | De verzameling is niet bijgewerkt | RAG-kant: Navigate freshness |
| Het juiste rapport is opgehaald, maar het antwoord laat een voorwaarde weg | De zin klopt niet met de passage | RAG-kant: Assemble context en antwoordcontrole |
| Meerdere bronvermeldingen gaan terug op één verslag | De bronnen hebben één oorsprong | TRACE: Cross-check |
| Een onopgeloste claim wordt gebruikt om een besluit te rechtvaardigen | Het besluit liep vooruit op het bewijs | TRACE: Export, met een eigenaar en HOLD |
Welke misverstanden kom je vaak tegen?
- “Onze AI noemt zijn bronnen, dus het antwoord is gecontroleerd.” Een bronvermelding is een weg terug naar het bewijs. Iemand moet nog nagaan of de passage precies die zin dekt, inclusief reikwijdte en datum. Wat is LLM-grounding? legt die controle uit.
- “Voor TRACE heb je een AI-systeem nodig.” Nee. Een browser en een spreadsheet zijn genoeg.
- “RAG maakt het antwoord waar.” RAG maakt het antwoord afhankelijk van specifieke passages. Daardoor kun je het controleren; een garantie dat het klopt, is het niet.
- “Wie TRACE afrondt, heeft de conclusie bewezen.” TRACE laat zien wat het bewijs onderbouwt en waar het ophoudt. Het boek zegt uitdrukkelijk dat niet is aangetoond dat TRACE onderzoek nauwkeuriger of sneller maakt.
Probeer het vandaag (10 minuten)
Neem één AI-antwoord waarnaar je team heeft gehandeld, of op het punt staat te handelen. Schrijf er drie regels onder:
- Passage: uit welke tekst komt het antwoord, en kun je die openen?
- Zin: dekt die tekst de zin precies, inclusief reikwijdte en datum?
- Besluit: rechtvaardigt de zin de voorgestelde actie?
Het eerste “nee” vertelt je waar het werk ligt. Regel 1 en 2 horen bij wie het RAG-systeem beheert. Regel 3 hoort bij de eigenaar van het besluit, en daar begint TRACE.
Citeer deze pagina:TRACE versus RAG: de een haalt de tekst op, de ander toetst wat die bewijst.Len P. van der Hof. https://lenvanderhof.com/nl/blog/trace-versus-rag/ ·