Enterprise RAG Challenge 3: Erkenntnisse aus öffentlichen Entries

Viacheslav Dubrov

2026-01-11 · Aktualisiert 2026-07-15 · 9 Min. · KI-Agenten

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Bei der Enterprise RAG Challenge 3 (ERC3) sollten Agents Business-Aufgaben gegen eine simulierte Unternehmens-API erledigen. Das eingefrorene Prize-Leaderboard ist ungewöhnlich nützlich, weil viele Teilnehmer mehr als nur einen Score veröffentlicht haben: Architektur, Model-Mix, Kosten und Hinweise zu Fehlern.

Ich habe diese öffentlichen Beschreibungen ausgewertet, um eine engere Frage zu beantworten: Welche Designentscheidungen tauchten in starken Submissions wiederholt auf, und welche davon sind auch außerhalb dieses Benchmarks nützlich?

Am Ende sollten Sie diese Beobachtungen in Design-Hypothesen für Ihre eigenen Agent-Traces übersetzen und sie anschließend anhand Ihres Task-Mix und der Kosten von Fehlern testen können.

Was ist die Enterprise RAG Challenge?

Die Enterprise RAG Challenge 3 ist ein groß angelegtes, von der Community getragenes Forschungsprojekt, das testet, wie autonome AI Agents komplexe Business-Aufgaben bearbeiten. Anders als statische Benchmarks läuft ERC3 auf der Agentic Enterprise Simulation (AGES), einer Discrete-Event-Simulation, die eine realistische Enterprise-API bereitstellt.

Was der Benchmark testet

In AGES arbeiten Agents innerhalb eines fiktiven Unternehmens mit:

• Mitarbeiterprofilen mit spezifischen Skills und Abteilungen
• Projekten mit Teamzuordnungen und Kundenbeziehungen
• Corporate Wiki mit Geschäftsregeln und Berechtigungshierarchien
• Zeiterfassung und Finanzprozessen

Jeder Task startet eine isolierte Simulation. Das Unternehmens-Wiki wird geteilt, die operativen Datensätze unterscheiden sich jedoch je nach Task. Ein Agent kann die Suite daher nicht lösen, indem er lediglich einen einzigen Unternehmenszustand auswendig lernt.

Scores als Snapshot lesen

ERC3 stellt inzwischen sowohl ein eingefrorenes Competition-Leaderboard als auch einen öffentlichen Benchmark bereit, der nach dem Event weiterhin Runs erhalten hat. Diese Seiten beantworten unterschiedliche Fragen. Die folgenden Zahlen beziehen sich auf das Prize-Leaderboard zum Competition-Cutoff, nicht auf später erzielte Best-Performing-Sessions:

Die Live-Benchmark-Seite kann höhere Scores anzeigen, weil sie spätere Runs enthält. Für Aussagen darüber, was den Wettbewerb gewonnen hat, ist daher das eingefrorene Leaderboard die richtige Quelle.

Task-Typen

Die Tasks decken mehrere Skill-Bereiche ab:

• Multi-Hop-Reasoning, etwa die Zuordnung von Mitarbeiter-Skills zu Projektaufgaben.
• Berechtigungsvalidierung, etwa das Blockieren nicht autorisierter Gehaltsänderungen oder Datenzugriffe.
• Ambiguous Queries, einschließlich mehrsprachiger und paraphrasierter Anfragen.
• Strikte Output-Compliance, einschließlich obligatorischer Entity-Links in Responses.

Was die Submissions tatsächlich nahelegen

Die öffentlichen Berichte stützen kein eindeutiges Urteil wie „Multi-Agent schlägt Single-Agent“. Der Prize-Entry auf Platz vier war ausdrücklich als einfaches Single-Agent-Design umgesetzt. Sie stützen jedoch vier engere Beobachtungen:

1. Decomposition war nützlich, wenn sie eine bekannte Fehlergrenze isolierte. Teams trennten Permission Checks, Step-Validation, Code-Ausführung oder Response-Formatierung – nicht beliebige „Agent-Rollen“.
2. Validation rückte näher an irreversible Aktionen. Mehrere Systeme prüften Berechtigungen vor der Ausführung, überprüften einzelne Schritte oder schützten die finale Response.
3. Trace-getriebene Iteration war wichtig. Der Prize-Gewinner übersetzte fehlgeschlagene Runs über einen automatisierten Loop in Prompt-Revisionen; andere Teams dokumentierten ähnlich konkrete Fixes an Tools und Prompts.
4. Die Context-Policy war eine Architekturentscheidung. Teams erprobten Distillation, Preloading, Retrieval und History Compression. Ihre eigenen Berichte widersprechen sich darin, ob Compression geholfen hat – eine universelle Lösung gibt es daher nicht.

Fünf informative Ansätze

Diese Ansätze sind nicht nach Rang sortiert. Ich habe sie ausgewählt, weil ihre öffentlichen Beschreibungen fünf unterschiedliche Möglichkeiten zeigen, ein System zu bauen: automatisierte Prompt-Revision, spezialisierte Stages, Step-Validation, Response-Guards und Plan-Execute-Isolation. Wo ich interpretiere, warum ein Design geholfen haben könnte, kennzeichne ich das als Interpretation und nicht als Leaderboard-Ergebnis.

1. Evolutionary Prompt Engineering (Team VZS9FL / @aostrikov)

Der Ansatz mit dem höchsten Score automatisierte Prompt Engineering über einen Self-Improvement-Loop.

Statt den Production-Prompt manuell zu optimieren, baute das Team einen Drei-Agenten-Loop, der aus fehlgeschlagenen Traces Kandidaten für Revisionen erzeugte.

Drei-Agenten-Pipeline:

Der Production-Prompt war die 80. automatisch generierte Version. Das Team beschreibt den Loop als Prozess, der fehlgeschlagene Tasks analysiert, Ursachen vorschlägt und entscheidet, welche Vorschläge übernommen werden. Das Leaderboard belegt den finalen Score und die Anzahl der Iterationen. Es isoliert jedoch nicht, wie viel des Zugewinns auf die Automation und wie viel auf Models, Tools oder das akkumulierte Benchmark-Feedback entfiel.

Stack: claude-opus-4.5 mit Anthropic Python SDK und nativem Tool Use.

2. Multi-Agent Sequential Pipeline (Team Lcnxuy / @andrey_aiweapps)

Diese Submission implementierte einen sequenziellen Workflow, in dem spezialisierte Komponenten Security Checks, Context Extraction, Execution und Entity-Link-Formatierung übernahmen.

Dokumentierte Komponenten:

1. Security Gate Agent: Pre-Execution Check, der Berechtigungen anhand der Wiki-Regeln validiert, bevor der Main Loop startet.
2. Context Extraction Agent: Extrahiert kritische Regeln aus umfangreichen Prompts und lädt User-, Projekt- und Kundendaten vorab.
3. Execution Agent: ReAct-basiertes Planning mit fünf internen Phasen (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
4. LinkGeneratorAgent: In das Response-Tool eingebettet; parst den Context, um die erforderlichen Entity-Links einzufügen.

Der LinkGeneratorAgent ist der am leichtesten übertragbare Teil. Durch die Einbettung in das Response-Tool wird eine Benchmark-Anforderung – obligatorische Entity-Links – zu einer Eigenschaft des Interfaces und nicht zu einer weiteren Instruktion, die das Execution Model vergessen kann.

Stack: atomic-agents und instructor Frameworks mit gpt-5.1-codex-max, gpt-4.1 und claude-sonnet-4.5.

3. Schema-Guided Reasoning mit Step-Validation (Team NLN7Dw / Ilia Ris)

Dieses Team kombinierte SGR mit schneller Inference und einem Validator für jeden vorgeschlagenen Schritt. Das Design macht Revisionen kostengünstig: Einen fehlerhaften Schritt zurückweisen, bevor er zu einem Tool Call wird, und anschließend den Main Flow mit den Kommentaren des Validators zur Überarbeitung auffordern.

Zentrale Komponenten:

Das Team berichtete, gpt-oss-120b auf Cerebras mit bis zu ungefähr 3.000 Tokens pro Sekunde auszuführen. Es kombinierte Validation mit High-Throughput-Inference, wodurch sich die Latency-Kosten möglicherweise reduzierten. Das öffentliche Ergebnis isoliert diesen Effekt nicht.

Stack: gpt-oss-120b auf Cerebras mit einer angepassten SGR-NextStep-Implementierung.

4. Enricher- und Guard-System (Team J8Gvbi / @mishka)

Diese Submission ergänzte eine SGR-Basis um nicht blockierende Hints und ein abgestuftes Guard-System. Sobald API-Responses eintrafen, untersuchten Enricher diese und fügten operative Hinweise zum späteren Context hinzu.

Mehr als 20 Enricher untersuchten API-Responses und injizierten kontextbezogene Hinweise:

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

Drei-Modi-Guard-System:

Hybrid-RAG-Wiki: Drei Search-Streams (Regex, semantisch und Keyword) deckten unterschiedliche Query-Formen gegenüber dem Unternehmens-Wiki ab.

Stack: qwen/qwen3-235b-a22b-2507 auf dem LangChain-SGR-Framework.

5. Plan-Execute-REPL (Team key_concept_parallel)

Diese Architektur trennte Planning und Execution durch eine harte Grenze und verwendete einen codegenerierenden Loop. Sie erschien auf dem umfassenderen Ultimate-Leaderboard, nicht unter den Top Five des eingefrorenen Prize-Leaderboards. Ihre öffentliche Beschreibung ist dennoch nützlich, weil sie eine andere Form der Decomposition zeigt: Isolation nach Execution-Phase statt nach Business-Rolle.

Unterschiedliche Models übernahmen unterschiedliche Aufgaben: Eines plante, eines schrieb Python, und ein separates Decision Model entschied nach jedem Schritt, was zu tun war.

Multi-Model-Setup:

Die Step-Completion-REPL:

1. Der Planner erstellt einen High-Level-Schritt.
2. Das Code-Gen-Model arbeitet in einem frischen Model Context und schreibt dafür ein Python-Script.
3. Das Script wird in einer taskbezogenen REPL ausgeführt, deren Variablen über mehrere Schritte hinweg persistent bleiben.
4. Das Decision Model prüft das Ergebnis und wählt: fortfahren, abbrechen oder replannen.

Der Replan-Pfad ist die wiederverwendbare Idee. Wenn ein Schritt teilweise fehlschlägt, kann das Decision Model die abgeschlossene Arbeit beibehalten und nur den verbleibenden Plan neu schreiben.

Wiederkehrende Patterns in den Submissions

Die Implementierungen unterschieden sich, doch in den öffentlichen Beschreibungen tauchten mehrere Engineering-Themen wiederholt auf.

Context Management war explizit

Kein Team konnte dem Model jede Regel, jeden Datensatz und jeden vorherigen Schritt übergeben, ohne eine Policy-Entscheidung zu treffen. Der interessante Unterschied lag darin, wo die einzelnen Systeme Informationen filterten.

Trade-off: NLN7Dw komprimierte ältere Turns, während f1Uixf berichtete, dass History Compression in seinen Experimenten schadete, und deshalb die vollständige Conversation beibehielt. Behandeln Sie Compression als gemessene Entscheidung und nicht als Default.

Guardrails wurden an unterschiedlichen Fehlergrenzen platziert

Mehrere Teams platzierten Checks vor, während oder nach dem Main Loop. Diese Mechanismen adressierten unterschiedliche Risiken und sollten nicht zu einem generischen „Critic Agent“ zusammengefasst werden.

Tool-Wrapper

Mehrere Teams bauten Abstraktionsschichten um die Raw-API:

• Auto-Pagination: Wrapper iterieren über jede Seite und liefern den vollständigen Datensatz zurück.
• Fuzzy Normalization: „Willingness to travel“ wird in das API-Feld will_travel übersetzt.
• Specialized Reasoning Tools: think-, plan- und critic-Tools für kontrolliertes Deliberation.

Failure Modes und die von Teams berichteten strukturellen Fixes

In den Berichten werden wiederholt Fehler an API- und Policy-Grenzen erwähnt. Die am besten wiederverwendbaren Fixes verlagerten die Anforderung in Code oder in einen dedizierten Validation-Schritt:

Eine praxisnahe Einführungsreihenfolge

ERC3 ist ein einzelnes simuliertes Unternehmen und keine allgemeine Agent-Ablation-Studie. Nutzen Sie die Ergebnisse als Quelle für Design-Hypothesen und testen Sie diese anschließend anhand Ihrer eigenen Traces. Eine sinnvolle Reihenfolge ist:

1. Stellen Sie zuerst die API-Korrektheit deterministisch sicher. Paginieren Sie List-Endpoints automatisch, normalisieren Sie fuzzy Felder, validieren Sie Schemas und generieren Sie erforderliche Links innerhalb des Response-Tools.
2. Fügen Sie Checks an echten Risikogrenzen hinzu. Prüfen Sie Identity und Permission vor Mutations; validieren Sie einen Schritt vor der Ausführung nur dann, wenn der zusätzliche Model Call Fehler abfängt, deren Kosten er rechtfertigt.
3. Dokumentieren Sie eine Context-Policy. Legen Sie fest, was preloaded, retrieved, compressed oder unverändert beibehalten wird. Messen Sie die Policy nach Task-Slice und nicht nur anhand der Token-Anzahl.
4. Machen Sie fehlgeschlagene Traces zu Regression Cases. Klassifizieren Sie den Fehler, ändern Sie genau einen Mechanismus und führen Sie den betroffenen Slice erneut aus. Automatisieren Sie Prompt-Revision erst, wenn dieser Loop zuverlässig funktioniert.
5. Führen Sie Decomposition ein, wenn Zuständigkeiten klarer werden. Eine separate Komponente ist dann gerechtfertigt, wenn sie einen Constraint besitzt, ein anderes Model oder Tool verwenden oder unabhängig getestet werden kann – nicht bloß, weil „Multi-Agent“ leistungsfähiger klingt.

Über diese Berichte hinweg machten zuverlässige Submissions verborgene operative Anforderungen in Tools, Validators und Evaluation-Loops sichtbar.

Referenzen

• Enterprise RAG Challenge 3 – Offizielle Website
• ERC3-Leaderboards
• Benchmark: erc3-prod
• Release Notes