2026-01-11 · Bijgewerkt 2026-07-15

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Enterprise RAG Uitdaging 3 (ECR3): Succesvolle AI Agent architectuurontwerpen

Enterprise RAG Challenge 3 (ECR3) vroeg agents om bedrijfsgerelateerde taken uit te voeren binnen een gesimuleerd bedrijf API. De vastgelegde ranglijst met prijzen is bijzonder nuttig, aangezien veel deelnemers niet alleen hun score publiceerden, maar ook informatie over hun architectuur, model combinaties, kosten en opmerkingen over fouten.

Ik heb die openbare beschrijvingen bekeken om een meer specifieke vraag te beantwoorden: welke ontwerpprioriteiten kwamen terug in de sterke indieningen, en welke daarvan zijn bruikbaar buiten benchmark?

TL;DR: Er was geen enkele dominante oplossing. De sterke inzendingen varieerden van eenvoudige tools die agent aanroepen, tot gespecialiseerde pipelines-systemen en systemen voor planning en uitvoering. De herhaaldelijke thema’s waren meer specifiek: leren van mislukte traces-procedures, risicovolle stappen dicht bij het moment van uitvoering controleren, contextbeleid duidelijk maken, en API-risico’s zoals pagineren verbergen achter betrouwbare omhullingen. De productieversie prompt van de winnaar was zijn 80ste automatisch gegenereerde versie.

Wat is de uitdaging van Enterprise RAG?

De Enterprise RAG Challenge 3 is een een grootschalig onderzoeksvoorproject dat gebruikmaakt van crowdsourcing dat test hoe autonome AI agents omgaan met complexe zakelijke taken. In tegenstelling tot statische benchmarks, draait ECR3 op de Agentic Enterprise Simulation (AGES), een simulatie van discontinue gebeurtenissen die toegang biedt tot realistische onderneming API.

Wat de benchmark-tests controleren

Via AGES voert agents werk uit binnen een valse onderneming die beschikt over:

• Medewerkersprofielen met specifieke vaardigheden en afdelingen
• Projecten met teamtoewijzingen en klantrelaties
• Corporatieve wiki met bedrijfsregels en toegangshiërarchieën
• Tijdregistratie en financiële transacties

Elke taak start een geïsoleerde simulatie. De bedrijfswiki wordt gedeeld, maar de operationele gegevens verschillen per taak; daarom kan een agent het gehele pakket niet oplossen door slechts één specifieke staat van het bedrijf uit zijn geheugen te halen.

Lees de scores als een snapshot

ECR3 biedt nu zowel een vastgelegde ranglijst van de wedstrijd als een publieke benchmark die ook na afloop van de evenementen nog nieuwe inzendingen ontving. Deze pagina’s beantwoorden verschillende vragen. De onderstaande grafieken geven de prijzenranglijst op het moment van beëindiging van de wedstrijd weer, en niet die van de later beste presterende sessions:

De live benchmark-pagina kan hogere scores weergeven omdat deze latere uitvoeringen omvat. Daarom vormt de gefixeerde ranglijst de juiste bron voor beweringen over wie de wedstrijd heeft gewonnen.

Soorten taken

De taken span omvatten verschillende vaardigheidsgebieden:

• Meerstappige reasoning verwerking, bijvoorbeeld het koppelen van medewerkerskills aan projecttoewijzingen.
• Validatie van toestemmingen, zoals het blokkeren van ongeautoriseerde salariswijzigingen of toegang tot gegevens.
• Ambigue vragen, inclusief meertalige en herformuleerde verzoeken.
• Strikte naleving van de uitvoer, waaronder verplichte entiteitslinks in de antwoorden.

Wat de ingediende voorstellen daadwerkelijk suggereren

De openbare verslagen ondersteunen geen duidelijk oordeel van het type “multi-agent is beter dan een enkele agent.” De inzending die op de vierde plaats eindigde, was expliciet een eenvoudig ontwerp met één agent. Wel zijn er vier meer specifieke observaties mogelijk:

1. Decompositie was nuttig wanneer dit een bekende foutgrens afzonderde. Teams splitsten toestemmingstests, stapvalidatie, codeuitvoering of responsformatering van willekeurige “agent rollen”.
2. Validatie werd dichter bij de onomkeerbare acties geplaatst. Verschillende systemen controleerden de toestemmingen vóór uitvoering, bekeken individuele stappen of beschermden de uiteindelijke respons.
3. Iteraties die worden aangestuurd door Trace waren belangrijk. De winnaar transformeerde mislukte uitvoeringen in prompt-revisies via een geautomatiseerde lus; andere teams documenteerden even concreet de gebruikte hulpmiddelen en prompt-correcties.
4. Een contextbeleid was een architectonische keuze. Teams probeerden methoden als destillatie, voorlading, retrieval en compressie van historische gegevens. Hun eigen rapporten verschillen van mening over de effectiviteit van compressie, waardoor er geen universele oplossing bestaat.

Vijf informatieve benaderingen

Dit zijn niet de vijf beste op basis van een rangschikking. Ik heb ze geselecteerd omdat hun openbare beschrijvingen vijf verschillende manieren onthullen om het systeem te bouwen: geautomatiseerde prompt revisies, gespecialiseerde fasen, stapsgewijze validatie, responsbeveiligingen en isolatie tussen planning en uitvoering. Wanneer ik uitleg waarom een bepaald ontwerp effectief is, vermeld ik die interpretatie in plaats van deze te presenteren als een resultaat van een ranglijst.

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

De de aanpak met de hoogste score geautomatiseerd prompt engineering via een zelfverbeteringslus.

In plaats van de productie prompt handmatig af te stemmen, bouwde het team een drie-agent loop systeem dat mislukte traces-versies omzette in potentiële revisies.

Drie-agent pipeline:

Het resultaat: De productie van prompt was de 80e automatisch gegenereerde versie. Het team beschrijft de lus als een proces waarbij mislukte taken worden geanalyseerd, oorzaken worden voorgesteld en wordt besloten welke suggesties worden opgenomen. De ranglijst bepaalt het eindresultaat en het aantal iteraties; zij geeft echter geen uitsluitsel over het aandeel van de verbetering dat voortkomt uit automatisering in plaats van uit models, tools, of opgebouwde benchmark feedback.

Stack: claude-opus-4.5 met Anthropic Python SDK en de geïntegreerde Tool Use.

2. Multi-agent sequentiële pipeline (Team Lcnxuy / @andrey_aiweapps)

Deze inzending bouwde een sequentiële workflow waarin gespecialiseerde componenten verantwoordelijk waren voor beveiligingscontroles, contextextractie, uitvoering en het formateren van entiteitslinks.

De gedocumenteerde componenten:

1. Beveiligingspoort Agent: Een controle vóór uitvoering die de toegangsrechten controleert tegenover de regels van de wiki, voordat de hoofdloop wordt gestart.
2. Contextextractie Agent: Haalt de cruciale regels uit enorme prompts-bestanden en laadt vooraf gegevens over gebruikers, projecten en klanten op.
3. Uitvoering Agent: Een planning-achtig proces in ReAct-stijl met 5 interne fasen (Identiteit → Bedreigingsdetectie → Informatieverzameling → Toegangsvalidatie → Uitvoering).
4. LinkGeneratorAgent: Geïntegreerd in het antwoordtool, dat de context analyseert om de benodigde entiteitslinks op te nemen.

De LinkGenerator agent vormt het meest overdraagbare onderdeel. Door deze in het responsinstrument op te nemen, wordt een benchmark-vereiste — namelijk verplichte entiteitslinks — een eigenschap van de interface in plaats van slechts nog een instructie die tijdens de uitvoering model gemist kan worden.

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

3. Schema-gestuurde reasoning met stapsgewijze validatie (Team NLN7Dw / Ilia Ris)

Dit team combineerde SGR met snelle inference en een validator voor elke voorgestelde stap. Dankzij dit ontwerp is het eenvoudig om correcties door te voeren: wees een foutieve stap al af voordat deze een tool call wordt, en vraag vervolgens de hoofdflow om deze op basis van de opmerkingen van de validator opnieuw te verwerken.

Belangrijkste componenten:

Het team meldde dat ze de uitvoering hadden voltooid GPT-OSS-120B op Cerebras met een snelheid van ongeveer 3.000 tokens per seconde. De snelle inference verminderde de latency-straf bij validatie, hoewel de ranglijst geen afzonderlijke analyse biedt die de snelheid scheidt van de overige aspecten van het ontwerp.

Stack: GPT-OSS-120B op Cerebras, met een aangepaste implementatie van SGR NextStep.

4. Verrijker en beveiligingssysteem (Team J8Gvbi / @mishka)

Bij deze bijdrage werden niet-blockerende hints en een gestructureerd guard-systeem toegevoegd aan een SGR-basis. Naarmate de API-antwoorden terugkwamen, analyseerden de enrichers deze en voegden operationele richtlijnen toe aan de latere context.

Het verrijkingssysteem:

Meer dan 20 verrijkers Er werden de API-respondenties gecontroleerd en contextuele aanwijzingen toegevoegd:

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

Drievoudig beveiligingssysteem:

Hybride RAG wiki: Drie zoekstromen — regex, semantisch en op sleutelwoorden — die verschillende vormen van zoekopdrachten verwerken in de bedrijfswiki.

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

5. Plan-execute REPL (Team key_concept_parallel)

Deze architectuur plaatst een duidelijke scheiding tussen planning en de uitvoering, waarbij gebruik wordt gemaakt van een codegenererende lus. Hoewel deze op de bredere Ultimate-lijst met beste prestaties te vinden is in plaats van op de vaste top vijf van prijswinnaars, is de openbare beschrijving nuttig omdat deze een andere vorm van decompositie laat zien: isolatie op basis van de uitvoerfase in plaats van op basis van de bedrijfsrol.

Verschillende models-instellingen handelden verschillende taken af: één was verantwoordelijk voor planning, een andere schreef Python-code, en een aparte beslissingslogica model bepaalde wat er na elke stap moest gebeuren.

Multi-model configuratie:

De REPL voor het voltooien van stappen:

1. Planner creëert een hooglevel stap.
2. Code-gen model werkt in een schone model context en genereert daarvoor een Python-script.
3. Het script wordt uitgevoerd in een taakgebonden REPL, waarbij de variabelen tussen de stappen behouden blijven.
4. De beslissing model bekijkt het resultaat en kiest of er doorgewerkt moet worden, het proces afgebroken moet worden of het plan opnieuw moet worden opgesteld.

De replan-pad is het herbruikbare concept. Wanneer een stap gedeeltelijk mislukt, kan de beslissing model het voltooid werk behouden en alleen het overgebleven plan opnieuw schrijven.

Patronen die zich herhaalden in de ingediende voorstellen

De implementaties verschilden, maar verschillende technische zorgen kwamen herhaaldelijk naar voren in de openbare beschrijvingen.

Het beheer van de context was expliciet.

Geen enkel team kan model alle regels, records en eerdere stappen overdragen zonder daarbij een beleidskeuze te maken. Het interessante verschil zat in de manier waarop elk systeem informatie filterde.

Afweging: NLN7Dw comprimeert oudere zinnen, terwijl f1Uixf Er werd gemeld dat historiecompressie de experimenten belemmerde en dat er daarom liever de volledige conversatie werd bewaard. Beschouw compressie als een bewuste keuze, en niet als de standaardoptie.

Guardrails zijn op verschillende foutgrenzen geplaatst

Meerdere teams plaatsten controles vóór, tijdens of na de hoofdloop. Deze mechanismen waren gericht op verschillende risico’s en moeten niet worden samengevoegd tot één algemene ‘kritiek agent’.

Slimme hulpprogrammaomhullingen

Meerdere teams hebben abstractielagen gecreëerd rondom de ruwe API:

• Automatische paginatie: De wrappers lopen door elke pagina heen en retourneren de volledige dataset.
• Vage normalisatie: “Willingness to travel” wordt vertaald naar de will_travel Veld API.
• Gespecialiseerde reasoning hulpmiddelen: think, plan, en critic Hulpmiddelen voor gecontroleerde deliberatie.

Foutmodi en de structurele correcties die de teams hebben gerapporteerd

De verslagen vermelden herhaaldelijk fouten bij API en de grenzen van de beleidsregels. De meest herbruikbare oplossingen brachten de vereiste over naar de code of naar een gespecialiseerde validatiestap:

Een praktische adoptievolgorde

ECR3 is een gesimuleerd bedrijf en geen algemene agent-ablatiestudie. Gebruik het als bron voor ontwerphypotheseën, en testeer die hypotheseën vervolgens tegen uw eigen traces. Een logische volgvolgorde voor implementatie is:

1. Zorg er eerst voor dat de correctheid van API deterministisch is. Pagineer automatisch de eindpunten van lijsten, normaliseer vage velden, valideer schema’s en genereer de vereiste links binnen het responstool.
2. Voeg controles toe op plekken met echte risico’s. Controleer identiteit en rechten voordat er mutaties worden uitgevoerd; valideer een stap pas vóór uitvoering wanneer de extra model oproep falen detecteert die het waard zijn om te verwerken.
3. Stel een contextbeleid op. Bepaal wat vooraf geladen, opgehaald, gecomprimeerd of letterlijk behouden moet worden. Meet het beleid aan de hand van taakonderdelen in plaats van alleen op basis van het aantal token.
4. Verander mislukte traces-gevallen in regressietests. Classificeer het falen, pas één mechanisme aan en voer het betreffende onderdeel opnieuw uit. Automatiseer de prompt-revisie pas wanneer deze cyclus betrouwbaar is.
5. Decomposeer wanneer de verantwoordelijkheden duidelijker worden. Een apart component is gerechtvaardigd wanneer deze een bepaalde beperking kan hanteren, een andere model of tool kan gebruiken, of onafhankelijk getest kan worden—niet alleen omdat “multi-agent” meer capaciteiten lijkt te hebben.

De belangrijkste les is niet dat één bepaalde architectuur heeft gewonnen. Het gaat erom dat betrouwbare indieningen onzichtbare operationele eisen zichtbaar maken binnen tools, validatoren en evaluatiecycli.

Referenties

• Enterprise RAG Uitdaging 3 - Officiële site
• ECR3 ranglijsten
• Benchmark: erc3-prod
• Versieningsnotities