Enterprise RAG Challenge — eine gewinnende Architektur für dokumentenbasierte Antworten
Eine kompakte technische Fallstudie. Die Architektur, die bei der Enterprise RAG Challenge den ersten Platz belegte, ist dieselbe, die wir für Kunden im Einsatz haben: hybrides Retrieval, strukturiertes Dokumenten-Parsing, schemavalidierte Verweigerung und Query-Dekomposition. Benchmarks, die halluzinierungsfreie Antworten belohnen, ähneln Produktivsystemen, die niemanden in Verlegenheit bringen dürfen.
Kontext
Open Enterprise RAG Challenge — ein öffentlicher Benchmark auf Basis von Enterprise-Finanzdokumenten. Kein Kundenprojekt. Die eingereichte Architektur ist dieselbe, die wir einsetzen, wenn ein Kunde ein dokumentengestütztes Frage-und-Antwort-System für sein Korpus benötigt.
Engagement
4-wöchiger Forschungs-Sprint. Architektur und Evaluierungs-Harness als Open-Source veröffentlicht.
Naive RAG-Basisimplementierungen liefern fehlerhafte Produktivsysteme.
Die Enterprise RAG Challenge prüft, ob ein System präzise Fragen zu einem großen Korpus aus Enterprise-Finanzdokumenten beantworten kann: Jahresberichte, 10-K-Formulare, Investorenpräsentationen. Korrekte Antworten erfordern (1) die richtige Seite zu finden, (2) die richtige Kennzahl zu extrahieren und (3) keine Halluzination zu produzieren, wenn das Dokument die Antwort nicht enthält.
Die naive Basisimplementierung — Chunks embedden, Top-k-Retrieval, in GPT-4o einspeisen — erreicht auf einem repräsentativen Evaluierungsset etwa 55–60 %. Produktivsysteme, die auf dieser Architektur basieren, liefern jede Woche fehlerhafte Ausgaben. Wir haben den Beitrag genauso gebaut, wie wir produktives RAG für Kunden entwickeln — denn die Techniken, die Benchmarks gewinnen, sind dieselben, die in der Produktion standhalten.
Hybrides Retrieval. Strukturiertes Parsing. Schemavalidierte Verweigerung. Query-Dekomposition.
Vier Schichten — jede behebt einen spezifischen Fehlertyp in naivem RAG.
Hybrides Retrieval: BM25 + Dense Embeddings + Reranker. Reines Vektor-Retrieval verfehlt exakte Finanzbegriffe (Ticker-Symbole, Positionsbezeichnungen). Reines BM25 verfehlt paraphrasierte Anfragen. Wir fächern beide Methoden auf und führen anschließend ein Reranking mit bge-reranker-large durch, das jeden Kandidaten gegen die Anfrage bewertet. Die Top-5 nach dem Reranking gehen an den Generator.
Strukturiertes Dokumenten-Parsing statt naivem Chunking. Finanz-PDFs enthalten Tabellen, Fußnoten, Seitenzahlen und eine Abschnittshierarchie. Wir parsen mit Unstructured.io für das Layout und einem eigenen Tabellenextraktions-Pass für Gewinn- und Verlustrechnungen, Bilanzen und Kapitalflussrechnungen. Jeder Chunk enthält strukturierte Metadaten: Seite, Abschnitt, Tabellenname, Zeile. Diese Metadaten bleiben im Kontext des Generators erhalten.
Schemavalidierte Generierung mit Verweigerungspfad. Der Generator (GPT-4o) liefert eine Pydantic-typisierte Antwort mit den Feldern: answer confidence evidence_spans refusal_reason. Wenn die Belege die Antwort nicht stützen, erzwingt das Schema eine Verweigerung — das Modell kann physisch keine Zahl erfinden, die es nicht gesehen hat.
Query-Dekomposition für Multi-Hop-Fragen. Fragen wie „Wie war die Jahresveränderung des Umsatzes in Segment X?" erfordern zwei Retrieval-Schritte. Ein vorgelagerter LLM-Aufruf zerlegt die Frage in atomare Teilanfragen, ruft für jede das Retrieval ab, und der Generator sieht alle Belege, bevor er antwortet.
Evaluierungs-Harness auf einem zurückgehaltenen Testset. Jede Pipeline-Änderung wurde gegen unser eigenes 500-Fragen-Evaluierungsset (nicht das Wettbewerbsset) getestet. Wir kannten unsere Genauigkeit auf 2 Prozentpunkte genau, bevor das öffentliche Ergebnis vorlag.
Architektur (Datenfluss)
Erster Platz. Und, noch wichtiger: null Halluzinationen bei Fragen, die eine Verweigerung erforderten.
Auf der Rangliste
Enterprise RAG Challenge. Ausgewertet gegen das private Frageset der Veranstalter.
Top-5-Trefferquote
Retrieval-Trefferquote auf dem zurückgehaltenen Evaluierungsset — der korrekte Beleg landete nach dem Reranking in den Top 5.
Halluzinationen
Bei 18 % der Fragen, bei denen das Dokument keine Antwort enthielt, verweigerte das System via Pydantic-Schema. Null erfundene Zahlen.
Dekomponiierte Fragen
Multi-Hop-Fragen, bei denen der Decomposer aktiv wurde. Diese Fragen waren es, die naives RAG in unserer Evaluierung scheitern ließ.
Ø pro Antwort
Gesamtkosten: Dekomposition + Retrieval + Reranking + Generierung. Repräsentativ für die Produktionsökonomie.
Zurückgehaltene Evaluierungsfragen
Unser eigenes Evaluierungsset, aus dem Korpus zusammengestellt. Wir kannten unsere Genauigkeit auf 2 Prozentpunkte genau vor der Einreichung.
Die Architektur, die die RAG Challenge gewonnen hat, ist dieselbe, die wir für Kunden einsetzen. Benchmarks, die halluzinierungsfreie Antworten belohnen, ähneln Produktivsystemen, die niemanden in Verlegenheit bringen dürfen.
Vier Entscheidungen, an denen naives RAG in der Produktion scheitert.
1. Hybrides Retrieval ist bei Enterprise-Dokumenten keine Option. Finanzdaten enthalten zu viele Exact-Match-Begriffe, als dass reines Vektor-Retrieval allein gewinnen könnte. BM25 erfasst, was Embeddings übersehen — Ticker-Symbole, Positionsbezeichnungen, Fußnotenverweise.
2. Schemavalidierte Verweigerung schlägt Genauigkeitsoptimierung. Ein RAG-System, das weiß, wann es sagen muss „Das Dokument beantwortet diese Frage nicht", übertrifft eines, das versucht, bei mehrdeutigen Fragen etwas genauer zu sein. Verweigerung ist eine Architekturentscheidung, kein Prompt.
3. Query-Dekomposition vor dem Retrieval, nicht danach. Multi-Hop-Fragen benötigen Teilanfragen vor dem Retrieval. Einmal abzurufen und darauf zu hoffen, dass das LLM mehrere Informationsteile zusammensetzt, ist der häufigste Fehler in produktivem RAG.
4. Evaluierungs-Harness auf einem zurückgehaltenen Set, nicht auf dem Testset. Man optimiert nicht gegen die Rangliste. Man baut sein eigenes 500-Fragen-Set, iteriert dort und reicht einmal ein.
Vier-wöchiger Forschungs-Sprint.
- Woche 1
Korpusanalyse + Basislinie
Pinecone + GPT-4o-Basislinie erreichte 63 % in unserer Evaluierung. Alle Fehlertypen dokumentiert.
- Woche 2
BM25 + Reranking + strukturiertes Parsing
Hybride Retrieval-Schicht → 78 %. Unstructured.io + Tabellenextraktion → 84 %. Retrieval-Fehlerrate kollabierte.
- Woche 3
Query-Dekomposition + schemavalidierte Verweigerung
Multi-Hop-Fragen freigeschaltet. Verweigerungspfad brachte Halluzinationen auf null. >90 % auf dem zurückgehaltenen Evaluierungsset.
- Woche 4
Finale Läufe + Open-Source
Evaluierungs-Harness CI-gesichert. Architektur und Evaluierungs-Harness-Repository veröffentlicht. Einreichung.
Gleiche Architektur, andere Domänen.
Wir können sie in 6–10 Wochen auf Ihren Enterprise-Dokumenten einsetzen.
Bringen Sie Ihren Korpus, Ihr Genauigkeitsziel und Ihr Verweigerungsbudget mit — wir nennen Ihnen, was die Architektur in Entwicklung und Betrieb kostet.