2026-01-11 · Aktualisiert 2026-07-15

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Unternehmensweite RAG-Herausforderung 3 (ECR3): Erfolgreiche AI Agent-Architekturen

Die Enterprise RAG Challenge 3 (ECR3) forderte die Agents auf, Geschäftsaufgaben innerhalb eines simulierten Unternehmens API zu erledigen. Die festgehaltene Rangliste der Gewinner ist außergewöhnlich nützlich, da viele Teilnehmer nicht nur ihre Punktzahl veröffentlichten, sondern auch detaillierte Informationen zu ihrer Architektur, zur Model Zusammensetzung der Komponenten, den Kosten sowie zu den aufgetretenen Fehlern.

Ich habe diese öffentlichen Beschreibungen durchgesehen, um eine spezifischere Frage zu beantworten: Welche Gestaltungsentscheidungen tauchten in den herausragenden Einreichungen häufig auf und welche davon sind außerhalb dieses Benchmark ebenfalls nützlich?

TL;DR: Es gab keine einzige optimale Topologie. Die überzeugendsten Lösungen reichten von einfachen Tools zur Aufrufung von Agent über spezialisierte Pipelines-Systeme bis hin zu Systemen zum Planen und Ausführen von Aufgaben. Die wiederkehrenden Ansätze waren detaillierter: Aus fehlgeschlagenen Traces-Versuchen lernen, riskante Schritte unmittelbar vor der Ausführung überprüfen, Kontextrichtlinien klar definieren sowie API-Gefahren wie Paginierung hinter zuverlässigen Wrappern verbergen. Die Produktionsumgebung des Gewinners, Prompt, war bereits in ihrer 80. automatisch generierten Version.

Was ist die Herausforderung im Bereich Enterprise RAG?

Die Enterprise RAG Challenge 3 ist eine ein groß angelegtes, durch die Öffentlichkeit unterstütztes Forschungsprojekt dieser Test prüft, wie autonome AI Agents komplexe Geschäftsaufgaben bewältigen. Im Gegensatz zu statischen Benchmarks-Modellen läuft ECR3 auf der Agentic Enterprise Simulation (AGES), einer diskreten-Ereignis-Simulation, die eine realistisches Unternehmensumfeld API.

Was die Benchmark-Tests überprüfen

Über AGES wird Agents innerhalb eines virtuellen Unternehmens eingesetzt, das über folgende Eigenschaften verfügt:

• Mitarbeiterprofile mit spezifischen Fähigkeiten und Abteilungen
• Projekte mit Teamzuordnungen und Kundenbeziehungen
• Unternehmenswiki mit Geschäftsregeln und Berechtigungshierarchien
• Zeitverfolgung und finanzielle Abläufe

Jede Aufgabe startet eine isolierte Simulation. Die Unternehmens-Wiki wird gemeinsam genutzt, doch die Betriebsdaten unterscheiden sich je nach Aufgabe; daher kann ein Agent das gesamte System nicht durch das Auswendiglernen eines einzigen Unternehmenszustands lösen.

Lesen Sie die Scores als Snapshot

ECR3 stellt nun sowohl eine festgefrorene Rangliste der Wettbewerbe als auch eine öffentliche Benchmark zur Verfügung, die nach Abschluss des Events weiterhin neue Einträge erhielt. Diese Seiten beantworten unterschiedliche Fragen. Die untenstehenden Diagramme zeigen die Preisrangliste zum Zeitpunkt des Wettbewerbsende, und nicht die später am besten abschneidenden Sessions:

Die aktuelle Seite mit dem Benchmark kann höhere Werte anzeigen, da sie spätere Ausführungen berücksichtigt. Deshalb stellt die festgefrorene Rangliste die richtige Quelle dar, um Aussagen darüber zu treffen, wer den Wettbewerb gewonnen hat.

Arten von Aufgaben

Die Aufgaben fallen in mehrere Kompetenzbereiche Span:

• Mehrschrittige Reasoning Verarbeitung, wie zum Beispiel das Abgleichen von Mitarbeiterfähigkeiten mit Projektzuweisungen.
• Genehmigungsvalidierung, beispielsweise durch das Blockieren nicht autorisierter Gehaltsanpassungen oder Datenzugriffe.
• Unklare Anfragen, einschließlich mehrsprachiger sowie umformulierter Anfragen.
• Strenge Ausgabevorgaben, darunter die Pflicht zur Einbeziehung von Entitätsverknüpfungen in den Antworten.

Was die eingereichten Vorschläge tatsächlich vorsehen

Die öffentlichen Berichte liefern keine klare Bewertung wie „multi-agent schlägt ein einzelnes Agent.“ Der Entwurf, der den vierten Platz belegte, war ausdrücklich eine einfache Konstruktion mit einem einzelnen Agent. Dennoch lassen sie vier spezifischere Beobachtungen zu:

1. Die Aufteilung der Funktionalitäten war nützlich, wenn dadurch eine bekannte Fehlergrenze abgegrenzt werden konnte. Die Teams trennten die Berechtigungskontrollen, die Schrittvalidierung, die Codeausführung sowie das Formatieren der Antwort voneinander – und nicht von willkürlichen „Agent Rollen“.
2. Die Validierung wurde näher an die irreversiblen Aktionen verlegt. Mehrere Systeme überprüften die Berechtigungen vor der Ausführung, prüften die einzelnen Schritte oder schützten die endgültige Antwort.
3. Trace-gesteuerte Iterationen waren entscheidend. Der Gewinner wandelte fehlerhafte Ausführungen durch einen automatisierten Zyklus in Prompt-Anpassungen um; andere Teams dokumentierten ähnlich konkrete Werkzeuge sowie Prompt-Besserungen.
4. Eine Kontextrichtlinie galt als architektonische Entscheidung. Die Teams probierten Methoden wie Destillation, Vorkompilieren, Retrieval sowie Komprimierung der Historie aus. Ihre eigenen Berichte sind sich uneinig darüber, ob die Komprimierung tatsächlich half, weshalb es kein universelles Rezept gibt.

Fünf informative Ansätze

Es handelt sich dabei nicht um die fünf besten Lösungen in absteigender Reihenfolge. Ich habe sie ausgewählt, weil ihre öffentlichen Beschreibungen fünf unterschiedliche Ansätze zur Implementierung des Systems aufzeigen: automatisierte Prompt-Revisionen, spezialisierte Arbeitsphasen, schrittweise Validierung, Antwortschutzmechanismen sowie Trennung von Planung und Ausführung. Wo ich erkläre, warum ein bestimmtes Design vorteilhaft ist, kennzeichne ich diese Erklärung explizit – anstatt sie als Ergebnis einer Rangliste zu betrachten.

1. Evolutive Prompt-Engineering (Team VZS9FL / @aostrikov)

Der der am besten bewertete Ansatz Automatisierte Prompt-Entwicklung mittels eines Selbstverbesserungslaufs.

Anstatt den Produktions-Prompt manuell anzupassen, entwickelte das Team ein dreistufiges Agent Loop-System, das fehlerhafte Traces-Versionen in potenzielle Überarbeitungen umwandelt.

Drei-Agent Pipeline:

Das Ergebnis: Die Produktion von Prompt war der 80. automatisch generierte Version. Das Team beschreibt den Zyklus als Analyse fehlgeschlagener Aufgaben, Erstellung von Ursachenhypothesen sowie Entscheidung darüber, welche Vorschläge umgesetzt werden sollen. Die Rangliste gibt schließlich die Endpunktzahl sowie die Anzahl der Iterationen an; sie differenziert jedoch nicht darin, welcher Anteil des Gewinns auf Automatisierung zurückzuführen ist und welcher auf Models, Tools oder auf angesammelte Benchmark-Feedbacks.

Stack: claude-opus-4.5 mit Anthropic Python SDK sowie ein natives Tool Use.

2. Multi-agent sequenzielle Pipeline Verarbeitung (Team Lcnxuy / @andrey_aiweapps)

In dieser Einreichung wurde ein sequenzieller Workflow implementiert, bei dem spezialisierte Komponenten für die Durchführung von Sicherheitsprüfungen, die Extraktion von Kontextinformationen, die eigentliche Ausführung sowie das Formatieren von Entitätsverknüpfungen zuständig waren.

Die dokumentierten Komponenten:

1. Sicherheitsgate Agent: Eine Prüfung vor der Ausführung, die die Berechtigungen anhand der Wiki-Regeln überprüft, bevor der Hauptloop gestartet wird.
2. Kontextextraktion Agent: Hierbei werden die relevanten Regeln aus umfangreichen Prompts extrahiert und gleichzeitig Nutzer-, Projekt- sowie Kundendaten vorgegeladen.
3. Ausführung Agent: Ein Planning im Stil von ReAct mit 5 internen Phasen (Identität → Bedrohungserkennung → Informationsbeschaffung → Zugriffsvalidierung → Ausführung).
4. LinkGeneratorAgent: Dieser Agent ist im Antwortwerkzeug integriert und analysiert den Kontext, um die erforderlichen Entitätsverknüpfungen einzubinden.

Der LinkGenerator Agent stellt den am meisten wiederverwendbaren Bestandteil dar. Durch seine Einbettung in das Antwortwerkzeug wird eine Benchmark-Anforderung – nämlich die Pflicht zur Erstellung von Entitätsverknüpfungen – zu einer Eigenschaft der Schnittstelle anstatt zu einer weiteren Anweisung, die bei der Ausführung Model übersehen werden könnte.

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

3. Schema-gesteuertes Reasoning mit Schritt-für-Schritt-Validierung (Team NLN7Dw / Ilia Ris)

Dieses Team kombinierte SGR mit schnellen Inference-Prozessen sowie einem Validator für jeden vorgeschlagenen Schritt. Dadurch wird das Anpassen des Designs kostengünstig: Man kann einen fehlerhaften Schritt bereits vor seiner Umwandlung in einen Tool Call ablehnen und den Hauptfluss anschließend bitten, ihn unter Verwendung der Kommentare des Validators neu zu bearbeiten.

Wesentliche Komponenten:

Das Team berichtete, dass es die Ausführung durchgeführt hat. GPT-OSS-120B auf Cerebras mit bis zu etwa 3.000 Tokens pro Sekunde. Schnelle Inference-Implementierungen verringerten die durch die Validierung verursachten Latency-Nachteile, wobei die Leaderboard-Daten keine Abgrenzung zwischen Geschwindigkeit und den übrigen Designaspekten bieten.

Stack: GPT-OSS-120B auf Cerebras, mit einer angepassten Implementierung von SGR NextStep.

4. Verfeinerungssystem und Schutzmechanismus (Team J8Gvbi / @mishka)

Durch diesen Beitrag wurden zu einer SGR-Basis nicht-blockierende Hinweise sowie ein gestuftes Schutzsystem hinzugefügt. Sobald die API-Antworten vorlagen, prüften die Verarbeitungsfunktionen diese und fügten anhand der Ergebnisse operative Anleitungen zum späteren Einsatz hinzu.

Das Enrichersystem:

mehr als 20 Aufwertungsmechanismen Die API-Antworten wurden überprüft und kontextbezogene Hinweise eingefügt:

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

Dreimodus-Schutzsystem:

Hybride RAG-Wiki: Drei Suchströme – reguläre Ausdrücke, semantische Analyse sowie Schlüsselwörter – wurden eingesetzt, um unterschiedliche Abfrageszenarien im Unternehmens-Wiki abzudecken.

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

5. REPL-Planung-Ausführung (Team key_concept_parallel)

Diese Architektur errichtet eine klare Trennung zwischen Planning und der eigentlichen Ausführung und nutzt dazu einen Code-Generierungszyklus. Obwohl sie nicht in der festgelegten Top-Five-Liste der Preisträger zu finden ist, sondern auf der umfassenderen Ultimate-Leaderboard-Plattform präsentiert wird, ist ihre öffentliche Beschreibung dennoch nützlich – sie veranschaulicht schließlich eine andere Form der Aufteilung: die Isolation nach Ausführungsphase anstelle von Geschäftsrollen.

Verschiedene Models übernahmen unterschiedliche Aufgaben: Eine war für die Planung zuständig, eine andere schrieb Python-Code, und eine separate Entscheidungslogik Model wählte aus, was nach jedem Schritt ausgeführt werden sollte.

Mehrfach-Model-Konfiguration:

Der REPL zur Abschlussüberprüfung von Schritten:

1. Planner erzeugt einen Hochlevel-Schritt.
2. Die Code-Generierung Model erfolgt in einem neuen Model Kontext und erstellt dazu ein Python-Skript.
3. Das Skript wird in einer task-spezifischen REPL ausgeführt, deren Variablen über die einzelnen Schritte hinweg erhalten bleiben.
4. Die Entscheidungslogik Model prüft das Ergebnis und wählt zwischen Fortsetzen, Abbrechen oder Neuplanen aus.

Der Umplanungspfad stellt die wiederverwendbare Idee dar. Wenn ein Schritt teilweise fehlschlägt, kann die Entscheidung Model die bereits erledigten Arbeiten beibehalten und lediglich den verbleibenden Plan neu erstellen.

Muster, die in den eingereichten Beispielen wiederholt auftauchten

Obwohl die Implementierungen voneinander abweichten, tauchten mehrere ingenieurtechnische Aspekte immer wieder in den öffentlichen Beschreibungen auf.

Die Kontextverwaltung war explizit gestaltet.

Kein Team konnte dem Model alle Regeln, Aufzeichnungen sowie vorherigen Schritte ohne gleichzeitig eine strategische Entscheidung zu treffen, zur Verfügung stellen. Der interessante Unterschied lag darin, wo jede Systeme die Informationen filterten.

Kompromiss: NLN7Dw komprimiert ältere Dialogschritte, während f1Uixf Es wurde berichtet, dass die Komprimierung der Historie die Durchführung der Experimente beeinträchtigte und stattdessen die vollständige Konversation beibehalten werden sollte. Man sollte Kompression als eine bewusste Entscheidung betrachten und nicht als Standardoption verwenden.

Guardrails wurden an unterschiedlichen Ausfallgrenzen platziert.

Mehrere Teams führten Prüfungen vor, während oder nach dem Hauptloop durch. Diese Mechanismen adressierten unterschiedliche Risiken und sollten nicht zu einem einheitlichen Konzept namens „Kritikpunkt Agent“ zusammengefasst werden.

Intelligente Tool-Wrapper

Mehrere Teams haben Abstraktionsschichten um die rohen API gebaut:

• Automatische Paginierung: Die Wrapper durchlaufen jede Seite nacheinander und liefern den vollständigen Dataset zurück.
• Fuzzy Normalisierung: Der Begriff „Willingness to travel“ wird in die entsprechende deutsche Entsprechung übersetzt. will_travel Feld API.
• Spezialisierte Reasoning-Tools: think, plan, und critic Werkzeuge für kontrollierte Abwägung.

Fehlermodi sowie die von den Teams gemeldeten strukturellen Korrekturen

Die Dokumentationen erwähnen immer wieder Fehler bei API sowie an den Grenzen der Richtlinien. Die am häufigsten wiederverwendbaren Lösungen bestanden darin, die Anforderung entweder direkt in den Code zu überführen oder in einen speziellen Validierungs Schritt zu integrieren:

Eine praktische Implementierungsreihenfolge

ECR3 ist ein simuliertes Unternehmen und keine allgemeine Agent-Ablationsstudie. Nutzen Sie es als Quelle für Design-Hypothesen, um diese anschließend an Ihren eigenen Traces zu überprüfen. Eine sinnvolle Reihenfolge der Implementierung lautet:

1. Stellen Sie zunächst die Determiniertheit der Korrektheit von API sicher. Automatisieren Sie das Seitennummernvergeben bei Liste-Endpunkten, normalisieren Sie unscharfe Felder, überprüfen Sie Schemata und erzeugen Sie im Antwortwerkzeug die erforderlichen Links.
2. Fügen Sie Überprüfungen an den tatsächlich kritischen Grenzen hinzu. Prüfen Sie Identität und Berechtigungen vor einer Mutation; validieren Sie einen Schritt erst vor der Ausführung, wenn der zusätzliche Aufruf von Model fehlerhafte Fälle aufspürt, deren Aufwand sich lohnt.
3. Definieren Sie eine Kontextrichtlinie. Entscheiden Sie, was vorgeladen, abgerufen, komprimiert oder wortwörtlich beibehalten wird. Messen Sie die Effektivität dieser Richtlinie anhand von Aufgabenteilen und nicht ausschließlich an der Anzahl von Token.
4. Umwandeln Sie fehlgeschlagene Traces in Regressionstests um. Klassifizieren Sie den Fehler, ändern Sie einen Mechanismus und führen Sie den betroffenen Teil erneut aus. Automatisieren Sie die Revision von Prompt erst, nachdem dieser Zyklus zuverlässig ist.
5. Zerlegen Sie die Struktur, sobald die Verantwortlichkeiten klarer werden. Ein separater Komponente ist sinnvoll, wenn sie eine bestimmte Einschränkung eigenständig handhaben kann, einen anderen Model oder ein anderes Werkzeug verwendet oder unabhängig getestet werden kann – und nicht einfach deshalb, weil „multi-agent“ leistungsfähiger erscheint.

Die wichtigere Erkenntnis ist nicht, dass eine bestimmte Architektur gewonnen hat. Vielmehr zeigen zuverlässige Einreichungen, wie versteckte Betriebsanforderungen durch Tools, Validatoren sowie Bewertungsschleifen sichtbar gemacht werden können.

Referenzen

• Enterprise RAG Herausforderung 3 – Offizielle Website
• ECR3-Ranglisten
• Benchmark: erc3-prod
• Versionshinweise