Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Enterprise RAG Challenge 3 (ECR3): Erfolgreiche AI-Agent-Architekturen
Die Enterprise RAG Challenge 3 (ECR3) ist gerade zu Ende gegangen. 524 Teams, mehr als 341.000 Agent-Runs, und nur 0,4 % der Teams erreichten die volle Punktzahl. Da Leaderboard und Write-ups jetzt öffentlich sind, habe ich mir die Gewinnerlösungen angesehen, um herauszufinden, was die Top-Teams anders gemacht haben.
Dieser Beitrag erklärt, was ECR3 ist, wie die Aufgaben aussahen und welche Muster ich in den funktionierenden Architekturen immer wieder gesehen habe.
Kurzfassung: Multi-Agent-Pipelines schlugen monolithische Ansätze. Das Top-Team nutzte evolutionäres Prompt Engineering über mehr als 80 automatisierte Iterationen. Die Gewinner investierten erheblichen Aufwand in Guardrails (Security-Checks vor der Ausführung, Validatoren in der Schleife, Schutzmechanismen nach der Ausführung) und in die Kontextstrategie. Entscheidend war nicht die Menge des Kontexts, sondern was darin enthalten war.
Was ist die Enterprise RAG Challenge?
Die Enterprise RAG Challenge 3 ist ein groß angelegtes, crowdsourcetes Forschungsprojekt, das testet, wie autonome AI-Agents komplexe Business-Aufgaben bearbeiten. Anders als statische Benchmarks läuft ECR3 auf der Agentic Enterprise Simulation (AGES), einer Discrete-Event-Simulation, die eine realistische Enterprise-API bereitstellt.
Warum ECR3 wichtig ist
Über AGES arbeiten Agents innerhalb eines fiktiven Unternehmens mit:
- Mitarbeiterprofilen mit spezifischen Fähigkeiten und Abteilungen
- Projekten mit Teamzuweisungen und Kundenbeziehungen
- Corporate-Wiki mit Geschäftsregeln und Berechtigungshierarchien
- Zeiterfassung und Finanzprozessen
Jede Aufgabe startet ihre eigene Simulation mit frischen Daten, sodass Agents zwischen den Runs nichts auswendig lernen können.
Die Schwierigkeit
Das Leaderboard ist hart:
| Metrik | Wert |
|---|---|
| Registrierte Teams | 524 |
| Agent-Runs gesamt | 341.000+ |
| Verfügbare Aufgaben | 103 einzigartige Business-Aufgaben |
| Volle Punktzahl (100,0) | Nur 0,4 % der Teams |
| Score ≥ 0,9 | Nur 1,1 % der Teams |
Aufgabentypen
Die Aufgaben decken mehrere Fähigkeitsbereiche ab:
- Multi-Hop-Reasoning: Mitarbeiter-Skills mit Projektzuweisungen abgleichen
- Berechtigungsvalidierung: Nicht autorisierte Gehaltsänderungen oder Datenzugriffe verhindern
- Mehrdeutige Anfragen: Mehrsprachige und paraphrasierte User-Anfragen verarbeiten
- Strikte Output-Compliance: Verpflichtende Entity-Links in Antworten aufnehmen
Was tatsächlich gewonnen hat
Vier Muster tauchten an der Spitze des Leaderboards immer wieder auf:
- Multi-Agent-Pipelines schlugen monolithische Agents. Die Aufteilung der Arbeit funktionierte besser als ein großer Agent, der alles gleichzeitig versucht.
- Die autonomsten Agents waren am stärksten eingeschränkt. Guardrails waren kein nachträglicher Zusatz.
- Automatisierte Prompt-Evolution schlug manuelles Engineering. Die besten Prompts durchliefen mehr als 80 Generationen.
- Die Kontextstrategie erledigte den Großteil der Arbeit. Nicht mehr Kontext, sondern der richtige Kontext.
Top-Gewinneransätze
Die fünf Architekturen unten gehen in sehr unterschiedliche Richtungen, von vollautomatisierter Prompt-Evolution bis zu hybridem Retrieval. Jede davon enthält Bausteine, die man übernehmen sollte.
1. Evolutionäres Prompt Engineering (Team VZS9FL / @aostrikov)
Der Ansatz mit dem höchsten Score automatisierte Prompt Engineering über eine Self-Improvement-Schleife.
Statt Prompts manuell feinzujustieren, baute das Team eine Schleife mit drei Agents, in der der Agent aus seinen eigenen Fehlern lernt.
Drei-Agent-Pipeline:
| Agent | Rolle |
|---|---|
| Main Agent | Führt den Benchmark aus, protokolliert alle Aktionen und Fehler |
| Analyzer Agent | Prüft fehlgeschlagene Aufgaben und formuliert Hypothesen zu den Ursachen |
| Versioner Agent | Erzeugt eine neue Prompt-Version, die die Erkenntnisse integriert |
Das Ergebnis: Der Produktions-Prompt war die 80. automatisch erzeugte Version. Jede Version behob ein spezifisches Fehlermuster, das in den Logs des vorherigen Runs auftauchte. Die meisten davon waren Edge Cases, die man normalerweise erst nach einer Stunde Analyse eines fehlgeschlagenen Traces bemerkt.
Stack: claude-opus-4.5 mit Anthropic Python SDK und nativer Tool Use.
2. Sequentielle Multi-Agent-Pipeline (Team Lcnxuy / @andrey_aiweapps)
Dieser Ansatz verwarf den monolithischen Agent und baute stattdessen eine sequentielle Pipeline aus Spezialisten, von denen jeder klein genug war, um in seiner Aufgabe wirklich gut zu sein.
Die 4-Stufen-Pipeline:
- Security Gate Agent: Prüft vor der Ausführung Berechtigungen gegen Wiki-Regeln, bevor die Hauptschleife startet.
- Context Extraction Agent: Zieht die kritischen Regeln aus großen Prompts heraus und lädt User-, Projekt- und Kundendaten vorab.
- Execution Agent: ReAct-artige Planung mit 5 internen Phasen (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
- LinkGeneratorAgent: Im Response-Tool eingebettet, parst den Kontext, um die erforderlichen Entity-Links einzufügen.
Der LinkGenerator-Agent ist der interessante Teil. Er behebt einen der häufigsten Fehlermodi: ein Agent, der die richtige Antwort gibt, aber die verpflichtenden Referenzlinks vergisst.
Stack: atomic-agents und instructor Frameworks mit gpt-5.1-codex-max, gpt-4.1 und claude-sonnet-4.5.
3. Schema-geführtes Reasoning mit Schrittvalidierung (Team NLN7Dw / Ilia Ris)
Dieses Team kombinierte SGR mit sehr schneller Inferenz und einem Echtzeit-Validator. Die Wette: viele schnelle, validierte Entscheidungen schlagen eine langsame, gründlich ausformulierte Antwort.
Kernkomponenten:
| Komponente | Funktion |
|---|---|
| StepValidator | Prüft jeden vorgeschlagenen Schritt. Wenn etwas nicht stimmt, geht er mit Kommentaren zur Überarbeitung zurück. |
| Context Management | Vollständiger Plan aus dem vorherigen Turn plus komprimierte Historie für ältere Turns |
| Dynamic Enrichment | Zieht User-Profil, Projekte, Kunden automatisch; LLM filtert, um nur aufgabenrelevante Daten zu injizieren |
| Auto-pagination Wrappers | Alle List-Endpunkte liefern automatisch vollständige Ergebnisse |
Der Geschwindigkeitsvorteil kommt vom Betrieb auf Cerebras mit ungefähr 3.000 Tokens pro Sekunde. In diesem Tempo kann der Agent es sich leisten, einen Schritt neu zu überdenken, statt sich auf eine langsame erste Antwort eines schwereren Modells festzulegen.
Stack: gpt-oss-120b auf Cerebras, mit einer angepassten SGR-NextStep-Implementierung.
4. Enricher- und Guard-System (Team J8Gvbi / @mishka)
Dieser Ansatz setzte auf einer SGR-Basis auf und ergänzte sie um nicht blockierende „intelligente Hinweise“ sowie ein abgestuftes Guard-System. Wenn API-Antworten zurückkommen, prüfen Enricher sie und geben dem Agent still Hinweise darauf, worauf er achten sollte.
Das Enricher-System:
Mehr als 20 Enricher prüften API-Antworten und injizierten kontextuelle Hinweise:
RoleEnricher: "You are LEAD of this project, proceed with update."
PaginationHintEnricher: "next_offset=5 means MORE results! MUST paginate."
Guard-System mit drei Modi:
| Modus | Verhalten |
|---|---|
| Hard block | Unmögliche Aktionen werden dauerhaft blockiert |
| Soft block | Riskante Aktionen werden beim ersten Versuch blockiert, bei Wiederholung erlaubt |
| Soft hint | Anleitung ohne Blockierung |
Hybrides RAG-Wiki: Drei parallele Suchströme (Regex, semantisch, Keyword), wobei je nach Abfragetyp der beste gewinnt.
Stack: qwen/qwen3-235b-a22b-2507 auf dem LangChain-SGR-Framework.
5. Plan-Execute-REPL (Team key_concept_parallel)
Diese Architektur zog eine harte Grenze zwischen Planung und Ausführung und nutzte eine codegenerierende Schleife. Effektiv ein REPL: Der Agent plant einen Schritt, generiert Code, führt ihn aus und entscheidet dann, was als Nächstes zu tun ist.
Unterschiedliche Modelle für unterschiedliche Aufgaben: Ein Planner plant, ein Code-Gen-Modell schreibt Python, und ein kleineres Entscheidungsmodell bestimmt nach jedem Schritt das weitere Vorgehen.
Multi-Model-Setup:
| Phase | Modell |
|---|---|
| Planung | openai/gpt-5.1 |
| Code Generation | deepseek/deepseek-v3.2 |
| Entscheidung nach Schritt | openai/gpt-4.1 |
| Finale Antwort | openai/gpt-4.1 |
Das REPL zur Schrittvervollständigung:
- Der Planner erstellt einen High-Level-Schritt.
- Das Code-Gen-Modell schreibt dafür ein Python-Skript.
- Das Skript wird in einem isolierten Kontext ausgeführt.
- Das Entscheidungsmodell bewertet das Ergebnis und wählt: fortfahren, abbrechen oder neu planen.
Der Replan-Pfad ist der Punkt, an dem dieses Design seinen Wert zeigt. Wenn ein Schritt teilweise fehlschlägt, kann das Entscheidungsmodell den Rest des Plans umschreiben, statt stumpf im kaputten Plan weiterzulaufen.
Muster, die überall auftauchten
Über die einzelnen Architekturen hinaus zogen sich einige Vorgehensweisen durch fast jede Top-Einreichung.
Kontextmanagement erledigte den Großteil der Arbeit
Die Top-Teams verstanden, dass die Kontextqualität die Obergrenze dafür ist, wie gut ein Agent sein kann.
| Strategie | Ansatz | Am besten geeignet für |
|---|---|---|
| Regeldestillation | Wiki per LLM in eine Zusammenfassung mit ~320 Tokens vorverarbeiten | Schlanke Prompts, schneller Start |
| Aggressives Preloading | User-/Projekt-/Kundendaten vor der Ausführung laden | Minimierung von Tool-Calls |
| Hybrides RAG | Regex- + semantische + Keyword-Suchströme | Komplexe Retrieval-Anforderungen |
| Historienkomprimierung | Aktuelle Turns vollständig halten, ältere Historie komprimieren | Lange Konversationen |
Trade-off: Die Teams Kc7F2N und f1Uixf stellten fest, dass Kontextqualität wichtiger ist als Quantität. f1Uixf sah sogar, dass Historienkomprimierung die Performance verschlechterte, und behielt deshalb die vollständige Historie bei und setzte stattdessen auf Long-Context-Modelle.
Guardrails: Je autonomer der Agent, desto mehr braucht er sie
Die Agents mit den höchsten Scores hatten gleichzeitig die strengsten Einschränkungen. Das klingt zunächst widersprüchlich, ist es aber nicht. Ein autonomer Agent hat mehr Möglichkeiten, Fehler zu machen, also braucht er mehr Stellen, an denen man ihn stoppen kann.
| Typ von Guardrail | Wann | Beispiel |
|---|---|---|
| Pre-Execution Gates | Bevor die Hauptschleife startet | Security Gate Agent validiert Berechtigungen gegen Wiki-Regeln |
| In-Loop Validators | Während des Reasonings | StepValidator prüft jede vorgeschlagene Aktion und erzwingt Überarbeitung bei Fehlern |
| Post-Execution Guards | Vor der finalen Abgabe | Guard-System mit drei Modi validiert die Vollständigkeit der Antwort |
Smarte Tool-Wrapper
Top-Teams bauten Abstraktionsschichten um die rohe API:
- Auto-pagination: Wrapper iterieren über alle Seiten und liefern den vollständigen Datensatz zurück.
- Fuzzy Normalization: „Willingness to travel“ wird in das API-Feld
will_travelübersetzt. - Spezialisierte Reasoning-Tools: Tools wie
think,planundcriticfür kontrollierte Deliberation.
Häufige Fehlermodi und wie die Gewinner sie behoben
Selbst die besten Agents hatten dieselben blinden Flecken. Die Lösungen waren strukturell, nicht bloß Prompt-Tuning:
| Fehlermodus | Beschreibung | Architektonische Lösung |
|---|---|---|
| Permission Bypass | Ausführung eingeschränkter Aktionen ohne Prüfung der User-Berechtigungen | Security Gate Agent vor der Ausführung; verpflichtende Sequenz Identity → Permissions → Execution |
| Missing Entity Links | Korrekte Textantwort, aber ohne die erforderlichen Referenzlinks | Eingebetteter LinkGeneratorAgent im Response-Tool |
| Pagination Exhaustion | Verarbeitung nur der ersten Seite von List-Ergebnissen | Auto-pagination-Wrapper für alle List-Endpunkte |
| Tool-Calling Loops | Hängt in wiederholten Aufrufen desselben Tools mit kleinen Variationen fest | Turn-Limits; reasoning-fokussierte Modelle (Qwen3) |
| Context Overloading | Füllt den Kontext mit irrelevanten Wiki-Abschnitten | Regeldestillation; dynamische Kontextfilterung |
Was man daraus mitnehmen sollte
Wenn du Agents baust und das anwenden willst:
- Nutze Multi-Agent-Pipelines. Monolithische Agents verloren. Top-Teams setzten 3 bis 5 Spezialisten für Security, Kontextextraktion, Planung und Ausführung ein.
- Automatisiere die Prompt-Iteration. Der Gewinner-Prompt war Version 80. Eine Schleife findet Fehlermuster, auf die du selbst nie gekommen wärst.
- Investiere ernsthaft in Guardrails. Security-Checks vor der Ausführung, Kritiker in der Schleife und Schutzmechanismen nach der Ausführung. Die am autonomsten wirkenden Agents waren am stärksten eingegrenzt.
- Verpacke deine Tools in Wrapper. Pagination, Datenanreicherung und Fuzzy Matching gehören in Wrapper. Ein Team baute mehr als 20 Enricher, die API-Antworten live überwachten.
- Nimm die Kontextstrategie ernst. Regeldestillation (~320-Token-Zusammenfassungen), Preloading und dynamische Filterung. Geschwindigkeit hilft ebenfalls. Ein Team lief mit ~3.000 Tokens pro Sekunde und konnte sich deshalb häufiges Replanning leisten.