🤖 AI

RAISE: RAG Design as an Architecture Search Problem

Dit artikel introduceert RAISE, een uitgebreid raamwerk en benchmark dat het ontwerpen van RAG formuleert als een architectuurzoekprobleem om systematische, reproduceerbare evaluatie van hyperparameteroptimalisatiemethoden over diverse datasets en taken mogelijk te maken.

Oorspronkelijke auteurs: Zhen Chen, Yibing Liu, Weihao Xie, Yu Liang, Peilin Chen, Shiqi Wang

Gepubliceerd 2026-05-29

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Zhen Chen, Yibing Liu, Weihao Xie, Yu Liang, Peilin Chen, Shiqi Wang

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je probeert het perfecte recept voor een gourmet-sandwich te maken. Je hebt veel ingrediënten om uit te kiezen: het type brood, de dikte van de snee, het type kaas, hoeveel mosterd je gebruikt en of je het roostert.

In de wereld van Kunstmatige Intelligentie wordt deze "sandwich" RAG (Retrieval-Augmented Generation) genoemd. Het is een systeem waarbij een slimme AI (zoals een chatbot) feiten opzoekt in een gigantische bibliotheek voordat hij een vraag beantwoordt. Om de AI goed te laten werken, moet je veel "knoppen" afstellen:

Hoe groot moeten de pagina's van de bibliotheek zijn?
Hoeveel pagina's moet de AI lezen?
Moet hij de vraag eerst herschrijven om hem duidelijker te maken?
Moet hij de pagina's opnieuw rangschikken om de beste te vinden?

Het Probleem: Gissen versus Zoeken

Tot nu toe hebben mensen die deze AI-systemen bouwen voornamelijk gegist. Ze draaien aan de knoppen op basis van ingeving of trial-and-error. Het is alsof je probeert het perfecte gebak te bakken door willekeurig de hoeveelheid suiker en bloem te veranderen, in de hoop dat je geluk hebt. Dit maakt het moeilijk om te weten of één recept echt beter is dan een ander, omdat iedereen verschillende ingrediënten en verschillende ovens gebruikt.

De Oplossing: RAISE (De "Sandwich-Architect")

De auteurs van dit paper introduceren een nieuw hulpmiddel genaamd RAISE (RAG Intelligence Search Engine). Denk aan RAISE als een super-georganiseerde keuken die het bouwen van een AI niet behandelt als een gispartij, maar als een wetenschappelijk zoekprobleem.

In plaats van gewoon willekeurige recepten te proberen, zet RAISE een gecontroleerde omgeving op waar:

De Ingrediënten Vaststaan: Iedereen gebruikt dezelfde bibliotheek met documenten en dezelfde soorten vragen.
Het Budget Vaststaat: Elke methode krijgt hetzelfde aantal "proefpogingen" (bijvoorbeeld 30 pogingen).
De Rechters Eerlijk Zijn: Ze gebruiken een standaard scoresysteem om de sandwiches te beoordelen.

RAISE fungeert als een proefpanel dat 13 verschillende "zoekstrategieën" (verschillende manieren om de knoppen af te stellen) test om te zien welke het snelst het beste recept vindt.

De Grote Ontdekking: "Eén Maat Past Niet Bij Allen"

Het meest verrassende wat het paper ontdekte, is dat er geen enkele "beste" strategie is.

Stel je voor dat je 13 verschillende koks hebt.

Kok A is geweldig in het maken van sandwiches voor een picknick (een specifiek type vraag).
Kok B is de meester van laat-nachtsnacks (een ander type vraag).
Als je Kok A vraagt om een laat-nachtsnack te maken, kan het mislukken. Als je Kok B vraagt om een picknick-sandwich te maken, kan het worstelen.

Het paper toont aan dat een optimalisatiemethode die perfect werkt op één dataset (zoals een triviaquiz) verschrikkelijk kan presteren op een andere (zoals een complexe wetenschappelijke vraag).

De Analogie:
Denk eraan als schoenen.

Je zou geen hardloopschoenen dragen om een berg te beklimmen.
Je zou geen wandelschoenen dragen om in een zwembad te zwemmen.
Je zou geen sandalen dragen om voetballen.

Het paper betoogt dat we niet zomaar een "Leaderboard" moeten maken dat zegt "Kok A is overall de beste". In plaats daarvan moeten we zeggen: "Kok A is de beste voor dit specifieke type vraag, maar Kok B is beter voor die ene."

Wat Ze Eigenlijk Dedden

Ze bouwden een raamwerk (RAISE) dat onderzoekers toelaat om verschillende zoekalgoritmen in te pluggen.
Ze testten deze algoritmen op 7 verschillende soorten vragen (variërend van simpele trivia tot complexe wetenschap en lange documenten).
Ze voerden de tests drie keer uit met verschillende willekeurige zaden om ervoor te zorgen dat de resultaten niet gewoon geluk waren.
Ze ontdekten dat het "beste" algoritme verandert afhankelijk van de taak. Bijvoorbeeld, sommige taken vereisen dat de AI meer pagina's leest, terwijl andere vereisen dat hij de vraag eerst herschrijft.

De Conclusie

Het paper claimt niet dat ze de "magische kogel" hebben gevonden die alle AI perfect maakt. In plaats daarvan biedt het een eerlijk speelveld (een benchmark) zodat onderzoekers kunnen stoppen met gissen en systematisch kunnen begrijpen welke afstelmethode werkt voor welk specifiek probleem.

Het is een oproep om te stoppen met zoeken naar een universeel "beste" AI-recept en te beginnen met het erkennen dat het beste recept volledig afhangt van wat je probeert te koken.

Technische Samenvatting: RAISE: RAG-ontwerp als een Architectuurzoekprobleem

Probleemstelling
Retrieval-Augmented Generation (RAG)-systemen omvatten talloze gekoppelde ontwerpkeuzes, waaronder query-herformulering, chunking-strategieën, ophaaldiepte, herrangschikkingsmechanismen en contextcompressie. In de praktijk worden deze componenten doorgaans geconfigureerd via heuristieken of trial-and-error-tuning. Deze aanpak belemmert systematische evaluatie, reproduceerbaarheid en eerlijke vergelijking tussen verschillende RAG-systemen. Bestaande inspanningen om RAG-configuraties te optimaliseren (bijv. AutoRAG, Self-RAG, AutoRAG-HP) maken gebruik van uiteenlopende pijplijnen, datasets, zoekruimten en evaluatieprotocollen, waardoor het vakgebied zonder een gedeeld kader blijft om optimalisatiealgoritmen onder gecontroleerde omstandigheden te vergelijken.

Methodologie
De auteurs formuleren RAG-ontwerp als een Architectuurzoek-probleem, waarbij het specifiek wordt behandeld als de selectie van pijplijnconfiguraties die de end-to-end-prestaties optimaliseren binnen een vast evaluatiebudget. Om een gecontroleerde studie mogelijk te maken, introduceren ze RAISE (RAG Intelligence Search Engine), een uitgebreid kader en benchmark.

Kaderarchitectuur: RAISE ontkoppelt het systeem in drie componenten:
1. Pijplijn-abstractie: Een geparametriseerde, modulaire gerichte acyclische graaf (DAG) die de RAG-werkstroom voorstelt. De zoekruimte $\Theta$ is het Cartesisch product van configuratieruimten voor zes modules: Query-herformuleerder, Chunker, Tekst/Visuele Ophaaler, Herrangschikker, Pruner en Generator. Dit ondersteunt zowel tekst-only als multimodale (tekst-visie) pijplijnen.
2. Evaluatielaag: Koppelt configuraties aan taakniveau-beloningen. De doelfunctie is een datasetniveau-gemiddelde van de generatiekwaliteit, met ondersteuning voor lexische (ROUGE-L, BLEU, METEOR, token-F1), semantische en modelgebaseerde metrieken.
3. Controller-interface: Een gestandaardiseerde API waardoor 13 verschillende optimalisatiealgoritmes configuraties ( $\theta_t$ ) voorstellen en beloningen ( $r_t$ ) ontvangen van de omgeving. Dit behandelt RAG-configuratie als een black-box optimalisatieprobleem.
Benchmark-omgevingen: Het kader wordt geïnstantieerd over zeven publieke datasets die diverse RAG-uitdagingen vertegenwoordigen:
- Tekst: TriviaQA (lange documenten), HotpotQA (multi-hop), MS MARCO (ophalen/herrangschikken), SQuAD v2 (extractief/hallucinatiebeheersing), LongBench-MF (lange context/tvrij veld) en LongBench-Qasper (wetenschappelijk redeneren).
- Multimodaal: ScienceQA (visueel-tekstuele gronding).
  Elke omgeving gebruikt een vaste proxy-subset (100 QA-paren) om rekenkundige haalbaarheid te waarborgen terwijl de taakstructuur behouden blijft.
Optimalisatiealgoritmes: De studie evalueert 13 algoritmes gegroepeerd in zeven families: Random Search, Lokale Traject (Greedy, Coördinaatafdaal, Gesimuleerde Aanneming, Iteratieve Lokale Zoek), SMBO/Bayesiaans (TPE), Schatting-van-Distributie (Cross-Entropy-methode), Evolutionair (Geregulariseerde Evolutie), Bandit (Thompson Sampling, UCB) en RL-achtig (GRPO, Dr. GRPO, Reinforce++).

Belangrijkste Resultaten
De auteurs voerden een gecontroleerde evaluatie uit met drie willekeurige zaden en een budget van 30 configuratie-evaluaties per algoritme per omgeving.

Interactie Optimalisator-omgeving: Geen enkel optimalisatiealgoritme domineert in alle omgevingen. De prestaties zijn sterk taakafhankelijk. Zo presteerde Greedy Search het beste op HotpotQA en TriviaQA, terwijl de Cross-Entropy-methode (CEM) leidde op MS MARCO en Random Search concurrerend was op ScienceQA. Aggregatierangschikkingen geven geen universele superioriteit weer; in plaats daarvan moeten resultaten worden geïnterpreteerd als interacties tussen de zoekstrategie en de specifieke RAG-omgeving.
Modulegevoeligheid: Ablatiestudies onthullen dat de impact van specifieke pijplijnmodules varieert per taakstructuur.
- TriviaQA (lange documenten) is het meest gevoelig voor query-herformulering en pruning.
- HotpotQA (multi-hop) is sterk afhankelijk van ophaaldiepte.
- LongBench-MF is zeer gevoelig voor ophaal top-k-instellingen.
  Dit bevestigt dat optimale pijplijnkeuzes niet globaal overdraagbaar zijn, maar afhankelijk zijn van de bewijsstructuur van de taak.
Zoeken versus Willekeurig: Onder gelijke budgetten presteren expliciete optimalisatiemethoden over het algemeen beter dan willekeurige steekproeven, hoewel de winsten vaak bescheiden zijn. Adaptieve methoden (bijv. Bandit, RL-achtig) neigen in latere trials beter te presteren door zich te richten op veelbelovende configuraties.
Proxy-stabiliteit: De studie vond dat proxy-taakgroottes van 100–200 voorbeelden voldoende stabiliteit bieden voor het rangschikken van optimalisatoren, met afnemende meerwaarde voor grotere subsets.

Betekenis en Claims
Het artikel beweert dat RAISE een gemeenschappelijk experimenteel substraat biedt voor eerlijk, reproduceerbaar en systematisch onderzoek naar RAG-hyperparameteroptimalisatie. Door de controller, zoekruimte en omgeving te scheiden, reduceert RAISE verwarring gerelateerd aan pijplijnimplementatie en evaluatieprotocollen.

De auteurs betogen dat RAG-architectuurzoek moet worden gerapporteerd als optimizer-omgevinginteracties in plaats van via een enkele universele leaderboard. Zij stellen dat het vakgebied gestandaardiseerde benchmarks nodig heeft, vergelijkbaar met HPOBench of YAHPO Gym, om het begrip te bevorderen van hoe verschillende zoekbias presteren onder specifieke RAG-beperkingen. Het kader is ontworpen om uitbreidbaar te zijn, waardoor nieuwe optimalisatiealgoritmes en benchmarktaken kunnen worden geïntegreerd zonder de kernpijplijnimplementatie te wijzigen.

Beperkingen
De auteurs erkennen dat hun experimenten een vaste zoekruimte instantiëren over specifieke modellen (Qwen3-serie) en discrete waarden. Alternatieve modelfamilies, ophaalbackends of continue zoekruimten kunnen het algoritmegedrag veranderen. Bovendien faciliteert de afhankelijkheid van lichtgewicht proxy-omgevingen en een vast budget (30 trials) een brede vergelijking, maar vervangt dit niet volledige-dataset- of groot-budgetstudies. De primaire doelstelling maakt gebruik van een gelijkwaardig lexisch en token-niveau-aggregaat, waarbij semantische en modelgebaseerde metrieken worden behandeld als auxiliaire signalen.