Enterprise RAG Challenge 3: lessen uit openbare inzendingen

Viacheslav Dubrov

2026-01-11 · Bijgewerkt 2026-07-15 · 10 min · AI-agenten

Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Enterprise RAG Challenge 3 (ERC3) vroeg agents om bedrijfstaken uit te voeren tegen een gesimuleerde bedrijfs-API. Het bevroren prijzenklassement is ongewoon nuttig, omdat veel deelnemers meer publiceerden dan alleen een score: architectuur, modelmix, kosten en notities over failures.

Ik heb die openbare beschrijvingen bestudeerd om een specifiekere vraag te beantwoorden: welke ontwerpkeuzes kwamen terug in sterke inzendingen, en welke daarvan zijn ook buiten deze benchmark bruikbaar?

Aan het einde zou je deze observaties moeten kunnen vertalen naar design hypotheses voor je eigen agent traces en ze vervolgens kunnen testen tegen je task mix en de kosten van failures.

Wat is de Enterprise RAG Challenge?

De Enterprise RAG Challenge 3 is een grootschalig, crowdsourced onderzoeksproject dat test hoe autonome AI agents complexe bedrijfstaken uitvoeren. In tegenstelling tot statische benchmarks draait ERC3 op de Agentic Enterprise Simulation (AGES), een discrete-event simulation die een realistische enterprise-API beschikbaar stelt.

Wat de benchmark test

Via AGES werken agents binnen een fictief bedrijf met:

• Employee profiles met specifieke vaardigheden en afdelingen
• Projects met teamtoewijzingen en klantrelaties
• Corporate wiki met bedrijfsregels en permission hierarchies
• Time tracking en financiële operaties

Elke task start een geïsoleerde simulation. De bedrijfswiki wordt gedeeld, maar operationele records verschillen per task. Een agent kan de suite dus niet oplossen door één bedrijfstoestand uit het hoofd te leren.

Lees de scores als een momentopname

ERC3 publiceert nu zowel een bevroren competition leaderboard als een openbare benchmark die na het evenement runs bleef ontvangen. Die pagina’s beantwoorden verschillende vragen. De cijfers hieronder beschrijven het prize leaderboard op het competition cutoff, niet de later best presterende sessions:

De live benchmarkpagina kan hogere scores tonen, omdat die latere runs bevat. Voor claims over wat de competitie heeft gewonnen, is het bevroren leaderboard daarom de juiste bron.

Soorten tasks

De tasks bestrijken verschillende skillgebieden:

• Multi-hop reasoning, zoals het matchen van employee skills aan project assignments.
• Permission validation, zoals het blokkeren van ongeautoriseerde salariswijzigingen of data access.
• Ambiguous queries, waaronder meertalige en geparafraseerde verzoeken.
• Strict output compliance, waaronder verplichte entity links in responses.

Wat de inzendingen daadwerkelijk suggereren

De openbare write-ups ondersteunen geen eenduidige conclusie zoals “multi-agent verslaat single-agent”. De inzending op de vierde plaats in het prize leaderboard was expliciet een eenvoudig single-agent-ontwerp. Ze ondersteunen wel vier beperktere observaties:

1. Decomposition was nuttig wanneer die een bekende failure boundary isoleerde. Teams scheidden permission checks, step validation, code execution of response formatting — geen willekeurige “agent roles”.
2. Validation verschoof dichter naar irreversibele acties. Verschillende systemen controleerden permissions vóór execution, beoordeelden individuele steps of beschermden de final response.
3. Trace-driven iteration was belangrijk. De winnaar zette failed runs via een geautomatiseerde loop om in prompt revisions; andere teams documenteerden vergelijkbaar concrete tool- en promptfixes.
4. Context policy was een architectuurkeuze. Teams experimenteerden met distillation, preloading, retrieval en history compression. Hun eigen rapporten verschillen van mening over de vraag of compression hielp, dus er bestaat geen universeel recept.

Vijf informatieve benaderingen

Dit zijn niet de vijf hoogst gerangschikte inzendingen. Ik heb ze geselecteerd omdat hun openbare beschrijvingen vijf verschillende manieren laten zien om het systeem te bouwen: geautomatiseerde prompt revision, specialist stages, per-step validation, response guards en plan-execute-isolation. Waar ik interpreteer waarom een ontwerp hielp, markeer ik dat als interpretatie in plaats van het als leaderboard-bevinding te presenteren.

1. Evolutionary prompt engineering (Team VZS9FL / @aostrikov)

De aanpak met de hoogste score automatiseerde prompt engineering via een self-improvement-loop.

In plaats van de production prompt handmatig te tunen, bouwde het team een drie-agent-loop die failed traces omzette in kandidaat-revisies.

Three-agent pipeline:

De production prompt was de 80e auto-generated version. Het team beschrijft de loop als een proces dat failed tasks analyseert, oorzaken voorstelt en beslist welke suggesties worden overgenomen. Het leaderboard bevestigt de final score en het aantal iteraties. Het maakt niet afzonderlijk inzichtelijk hoeveel van de verbetering afkomstig was van automation in plaats van de models, tools of verzamelde benchmark feedback.

Stack: claude-opus-4.5 with Anthropic Python SDK en native Tool Use.

2. Multi-agent sequential pipeline (Team Lcnxuy / @andrey_aiweapps)

Deze inzending bouwde een sequential workflow waarin specialistische componenten verantwoordelijk waren voor security checks, context extraction, execution en entity-link formatting.

De gedocumenteerde componenten:

1. Security Gate Agent: Pre-execution-check die permissions valideert aan de hand van wiki rules voordat de main loop start.
2. Context Extraction Agent: Haalt de belangrijkste regels uit massive prompts en preloadt user-, project- en customerdata.
3. Execution Agent: ReAct-style planning met 5 interne phases (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
4. LinkGeneratorAgent: Ingebouwd in de response tool; parseert context om de vereiste entity links op te nemen.

De LinkGeneratorAgent is het meest overdraagbare onderdeel. Door die in de response tool te plaatsen, wordt een benchmarkvereiste (verplichte entity links) een eigenschap van de interface in plaats van nog een instructie die het execution model kan vergeten.

Stack: atomic-agents- en instructor-frameworks met gpt-5.1-codex-max, gpt-4.1 en claude-sonnet-4.5.

3. Schema-guided reasoning with step validation (Team NLN7Dw / Ilia Ris)

Dit team combineerde SGR met snelle inference en een validator voor elke voorgestelde step. Het ontwerp maakt revision goedkoop: wijs een gebrekkige step af voordat die een tool call wordt en laat de main flow die met de opmerkingen van de validator herwerken.

Belangrijkste componenten:

Het team rapporteerde dat het gpt-oss-120b on Cerebras draaide met maximaal ongeveer 3.000 tokens per seconde. Het team combineerde validation met high-throughput inference, wat de latencykosten mogelijk heeft verlaagd. Het openbare resultaat maakt dat effect niet afzonderlijk inzichtelijk.

Stack: gpt-oss-120b on Cerebras, met een aangepaste SGR NextStep-implementatie.

4. Enricher and guard system (Team J8Gvbi / @mishka)

Deze inzending voegde non-blocking hints en een tiered guard system toe aan een SGR-basis. Wanneer API responses binnenkwamen, inspecteerden enrichers die en voegden ze operationele guidance toe aan de latere context.

Meer dan 20 enrichers inspecteerden API responses en injecteerden contextual hints:

RoleEnricher: "You are LEAD of this project, proceed with update."
PaginationHintEnricher: "next_offset=5 means MORE results! MUST paginate."

Three-mode guard system:

Hybrid RAG wiki: Drie search streams (regex, semantic en keyword) behandelden verschillende queryvormen tegen de bedrijfswiki.

Stack: qwen/qwen3-235b-a22b-2507 op het LangChain SGR-framework.

5. Plan-execute REPL (Team key_concept_parallel)

Deze architectuur plaatste een harde scheiding tussen planning en execution en gebruikte een code-generating loop. De inzending stond op het bredere Ultimate leaderboard, niet in de top vijf van het bevroren prize leaderboard. De openbare beschrijving is toch nuttig, omdat die een andere vorm van decomposition laat zien: isolatie per execution phase in plaats van per business role.

Verschillende models behandelden verschillende taken: één plande, één schreef Python en een afzonderlijk decision model koos na elke step wat er moest gebeuren.

Multi-model setup:

De step-completion REPL:

1. De planner maakt een high-level step.
2. Het code-gen model werkt in een fresh model context en schrijft er een Python script voor.
3. Het script draait in een task-scoped REPL waarvan de variabelen tussen steps persistent blijven.
4. Het decision model bekijkt het resultaat en kiest: doorgaan, afbreken of replannen.

Het replan path is het herbruikbare idee. Wanneer een step gedeeltelijk faalt, kan het decision model afgerond werk behouden en alleen het resterende plan herschrijven.

Patronen die in meerdere inzendingen terugkwamen

De implementaties verschilden, maar verschillende engineering concerns kwamen herhaaldelijk terug in de openbare beschrijvingen.

Context management was expliciet

Geen enkel team kon elke regel, elk record en elke eerdere step aan het model geven zonder een beleidskeuze te maken. Het interessante verschil was waar elk systeem informatie filterde.

Trade-off: NLN7Dw comprimeerde oudere turns, terwijl f1Uixf rapporteerde dat history compression zijn experimenten verslechterde en de volledige conversation behield. Behandel compression als een gemeten keuze, niet als default.

Guardrails werden op verschillende failure boundaries geplaatst

Verschillende teams plaatsten checks vóór, tijdens of na de main loop. Deze mechanismen adresseerden verschillende risico’s en mogen niet worden samengevoegd tot één generieke “critic agent.”

Tool wrappers

Verschillende teams bouwden abstraction layers rond de raw API:

• Auto-pagination: Wrappers lopen door elke page en retourneren de volledige dataset.
• Fuzzy normalization: “Willingness to travel” wordt vertaald naar het veld will_travel van de API.
• Specialized reasoning tools: think-, plan- en critic-tools voor gecontroleerde deliberation.

Failure modes en de structurele fixes die teams rapporteerden

De write-ups noemen herhaaldelijk failures op API- en policy boundaries. De meest herbruikbare fixes verplaatsten de vereiste naar code of naar een dedicated validation step:

Een praktische adoptievolgorde

ERC3 is één gesimuleerd bedrijf, geen algemene agent ablation study. Gebruik de resultaten als bron van design hypotheses en test die hypotheses vervolgens tegen je eigen traces. Een verstandige adoptievolgorde is:

1. Maak API correctness eerst deterministisch. Pas auto-pagination toe op list endpoints, normaliseer fuzzy fields, valideer schemas en genereer verplichte links in de response tool.
2. Voeg checks toe op echte risk boundaries. Verifieer identity en permission vóór mutation; valideer een step vóór execution alleen als de extra model call failures opvangt die de kosten ervan rechtvaardigen.
3. Leg een context policy vast. Bepaal wat wordt preloaded, retrieved, compressed of letterlijk behouden. Meet de policy per task slice, niet alleen op basis van het aantal tokens.
4. Maak van failed traces regression cases. Classificeer de failure, wijzig één mechanisme en voer de getroffen slice opnieuw uit. Automatiseer prompt revision pas nadat deze loop betrouwbaar is.
5. Decompose wanneer ownership duidelijker wordt. Een afzonderlijke component is gerechtvaardigd als die een constraint kan beheren, een ander model of tool kan gebruiken of onafhankelijk kan worden getest — niet simpelweg omdat “multi-agent” capabeler klinkt.

In deze write-ups maakten betrouwbare inzendingen verborgen operationele vereisten zichtbaar in tools, validators en evaluation loops.

References

• Enterprise RAG Challenge 3 - Official Site
• ERC3 Leaderboards
• Benchmark: erc3-prod
• Release Notes