Production-RAG-Erfahrungen aus der Verarbeitung von mehr als 5 Millionen Dokumenten

• Im Verlauf eines 8-monatigen RAG-(Retrieval-Augmented Generation)-Projekts wurde klar, welche Methoden tatsächlich wirksam waren und welche sich als Zeitverschwendung erwiesen.
• Anfangs wurde mit Langchain und Llamaindex schnell ein Prototyp gebaut, doch echtes Nutzerfeedback zeigte Leistungsgrenzen auf.
• Als wichtigste Faktoren zur Verbesserung der Dokumentensuche erwiesen sich Query-Generierung, Reranking, Chunking-Strategie, Nutzung von Metadaten und Query-Routing.
• In der Praxis wurde eine Custom-Pipeline aufgebaut, bei der Vektor-Datenbanken, Embeddings, Reranking und LLMs flexibel ausgewählt wurden.
• Alle Erfahrungen und das gesammelte Know-how wurden im Open-Source-Projekt (agentset-ai/agentset) gebündelt und veröffentlicht.

---

Überblick über 8 Monate Aufbau von Production RAG

• Es werden Erfahrungen aus dem Aufbau und Betrieb von RAG-Systemen auf großen Datensätzen geteilt, darunter insgesamt 9 Millionen Seiten (Usul AI) und 4 Millionen Seiten (ein anonymes Legal-AI-Unternehmen).
• Zu Beginn wurde mithilfe von YouTube-Tutorials innerhalb weniger Tage ein Prototyp fertiggestellt, zunächst in Langchain und dann in Llamaindex, doch beim echten Deployment zeigte sich das Problem einer niedrigen Qualität, die nur Nutzer unmittelbar bemerken konnten.
• Über mehrere Monate hinweg wurden einzelne Systemkomponenten schrittweise verbessert, bis die optimale Leistung erreicht war.

Faktoren, die tatsächlich zur Leistungsverbesserung beigetragen haben (nach ROI)

1. Query-Generierung (Query Generation)

   • Da die letzte Nutzeranfrage nicht den gesamten Kontext enthalten kann, wird der Gesprächsverlauf mit einem LLM analysiert, um mehrere semantische und Keyword-basierte Queries zu erzeugen.
   • Diese Queries werden parallel verarbeitet und an den Reranker weitergegeben, wodurch der Suchraum erweitert und Verzerrungen hybrider Suche ausgeglichen werden.

2. Reranking

   • Der Einfluss von Reranking, das sich mit etwa fünf Zeilen Code implementieren lässt, auf die Leistung ist größer als erwartet.
   • Besonders hoher ROI entsteht beim Neuordnen und Auswählen der besten Chunks aus einer größeren Menge von Eingaben (z. B. Top 15 aus 50 Chunks).
   • Reranking allein kann Schwächen einer nicht optimal entworfenen Pipeline in erheblichem Maß kompensieren.

3. Chunking-Strategie (Chunking Strategy)

   • Dieser Bereich nimmt einen großen Teil der gesamten Entwicklungszeit ein.
   • Es ist notwendig, die Datenstruktur und Muster genau zu verstehen, in logischen Einheiten zu chunken und manuell zu prüfen, dass weder Zeichen noch Sätze mitten im Text abgeschnitten werden.
   • Jeder Chunk sollte seine eigenständige Bedeutung bewahren.

4. Nutzung von Metadaten im LLM-Input

   • Statt dem LLM nur den reinen Chunk-Text zu übergeben, werden Metadaten (title, author usw.) ergänzt, was Kontext und Antwortqualität deutlich verbessert.

5. Query-Routing (Query Routing)

   • Für Fragetypen, die mit RAG nicht beantwortet werden können (z. B. Zusammenfassungen von Artikeln oder Anfragen zu Autorinformationen), wird ein leichtgewichtiger Router eingeführt, der solche Queries auf einen API+LLM-Verarbeitungspfad umleitet.

Praxis-Stack (Our stack)

• Vektor-Datenbank: Azure → Pinecone → Turbopuffer (günstig und unterstützt standardmäßig Keyword-Suche)
• Dokumentextraktion: Custom-Ansatz
• Chunking-Tool: standardmäßig Unstructured.io, für Enterprise-Pipelines Custom-Lösung (auch Chonkie hat einen guten Ruf)
• Embedding-Modell: text-embedding-large-3 im Einsatz (andere Modelle nicht getestet)
• Reranker: None → Cohere 3.5 → Zerank (nicht sehr bekannt, aber in der Praxis stark)
• LLM: GPT 4.1 → GPT 5 → GPT 4.1 (hauptsächlich mit Azure-Credits genutzt)

Open Source und Fazit

• Sämtliche Lernergebnisse und Praxiserfahrungen mündeten in das Open-Source-Projekt agentset-ai/agentset.
• Veröffentlichung unter MIT-Lizenz, frei nutzbar und Rückfragen sind möglich (Kontaktinformationen vorhanden).

[GN⁺]

Hacker-News-Kommentare

• Der Hinweis zur Generierung synthetischer Queries ist wirklich wichtig; in der Praxis geben Nutzer ihre Suchanfragen oft sehr ungenau ein. Anfangs erstellt daher ein LLM eine synthetische Query, aber je nach jeweils erzeugter synthetischer Query schwanken die Ergebnisse stark. Deshalb werden mit einem einzigen LLM-Aufruf drei unterschiedliche Versionen der Query erzeugt, diese parallel durchsucht und anschließend mit Reciprocal Rank Fusion zu einer starken Ergebnisliste kombiniert. Für die Suche wird ein hybrides Verfahren aus dense + sparse BM25 verwendet; nur dense ist bei Fachbegriffen schwach. Mit einem zusätzlichen Reranker lassen sich die meisten Suchprobleme lösen.
  • Interessant ist der Einsatz eines hybriden Ansatzes (BM25 + dense search), um die Schwäche dichter Modelle bei Fachbegriffen auszugleichen. v3-Modelle wie SPLADE, die semantische und lexikalische Suche gut ausbalancieren, wirken ebenfalls leistungsstark, und es bleibt die Frage, ob sie durch eine einfachere Lösung ersetzt werden können.
  • Es wird betont, dass sich letztlich Anbieter von RAG-Lösungen wie Amazon, Microsoft und OpenAI um solche Details der Query-Generierung und -Optimierung kümmern sollten.
  • Diese Methoden sind zwar aktuell Best Practice, aber es bleibt ein gewisses Gefühl, dass noch etwas fehlt, etwa zusätzliche Strategien, um die Leistung weiter zu steigern, wie selektives Routing bei Embedding-Modellen oder verschiedene Kombinationen von Rerankern.
  • Als letzter Tipp wird vorgeschlagen, den Nutzern zusammen mit den Ergebnissen mitzuteilen, wie das LLM ihre Suchabsicht interpretiert hat, damit sie selbst prüfen können, ob das Verständnis des LLM korrekt ist.
• Es herrscht Verwirrung über die self-hosted-Option; in der zugehörigen Dokumentation heißt es, dass mindestens sechs Konten bei Drittanbietern nötig seien, was stark von der eigentlichen Bedeutung von self-hosted abweiche.
  • Es wird erklärt, dass sich der betreffende Code selbst hosten lässt. Für den Begriff „self-hosted“ gebe es wohl keinen klaren offiziellen Maßstab. Wenn ein self-hosted-Dienst zum Beispiel Offsite-Backups hat, bleibt er dennoch self-hosted und ist einfach gut entworfen.
  • Solches self-hosted-Marketing mag auf gewisse Weise nachvollziehbar sein, aber da das ursprüngliche Geschäftsmodell des Anbieters im Verkauf einer gehosteten Version liegt, besteht keine Pflicht, ein vollständig unabhängiges self-hosted-Produkt anzubieten.
  • Es wird Erfahrung aus eingeschränkten Netzwerkumgebungen geteilt: In den letzten 20 Jahren wurde in vollständig abgeschotteten internen Netzwerken gearbeitet, wodurch möglicherweise viele aktuelle Technologiewellen verpasst wurden. YouTube werde kaum genutzt, außer für Autoreparaturen, und gegenüber Technologietrends mit zwingender Online-Anbindung bestehe eine gewisse Zurückhaltung.
  • Die Open-Source-Version werde persönlich sehr zufriedenstellend genutzt; wenn man keine Hosting-Abhängigkeiten wolle, könne man pragmatisch einfach alles selbst in Rust schreiben.
• Große LLM-basierte Reranker (etwa Qwen3-reranker) liefern inzwischen die Leistung, die man sich früher von Cross-Encodern gewünscht hat, daher lohne sich ein Versuch unbedingt. Der Rechenaufwand ist allerdings beträchtlich. Metadaten und Tabelleninformationen sind für Menschen selbstverständlich, werden in Text-Chunks aber oft nicht wiederholt; wenn man sie in den LLM-Input einspeist, wirkt das Modell deutlich „intelligenter“. Bei komplexen Queries, die sich mit einfachem RAG schlecht verarbeiten lassen (z. B. Zusammenfassungen der neuesten 20 Dokumente), ist Vorsicht geboten. Deshalb wird die UI auf Suche fokussiert, mit weniger Chat-UX, und der Nutzer sieht nur die Informationen, die das Modell tatsächlich sieht.
  • Es wird voll zugestimmt, dass es aus Nutzersicht sehr schwer ist, die Struktur der Kontextverarbeitung eines LLM richtig zu vermitteln. Öffentliche Beispiele jenseits klassischer Chat-UX sind selten, und es gibt Zweifel, ob große Unternehmen entsprechende Versuche wirklich mangels Erfolg aufgegeben haben. In großen Consumer-Apps sind Kontext- und Inferenzkosten ein wesentlicher Kostenfaktor, der kontrolliert werden muss; deshalb scheint eine context-explicit UI wenig Zuspruch gefunden zu haben. Interne RAG-Systeme haben dagegen geringeren Kostendruck, weshalb dort erfahrungsgemäß deutlich stärker auf Ergebnisqualität und Zeitersparnis für Mitarbeitende geachtet wird.
  • Technische Optimierung ist wichtig, aber noch interessanter wären konkrete Praxisbeispiele dazu, wie stark sich die Arbeitsabläufe von Kunden tatsächlich verbessert haben. Sonst bleibt es nur ein weiterer Techniktrend.
• Es wird ein Überblicksartikel geteilt, der vor anderthalb Jahren zum RAG-Processing von Millionen Seiten, insbesondere technischer Dokumentation, geschrieben wurde: https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • Auch ein RAG-System für technische Suche wurde im Vorjahr aufgebaut, und vieles daran wirkt selbst heute noch nahezu identisch.
• Aus Sicht von jemandem, der ein solches RAG-System aufbauen oder einführen möchte, stellt sich die Frage, ob es praktikabel wäre, Dokumente per API in Google-Workspace-Ordner hochzuladen und sie anschließend über die Google AI search API durchsuchen zu lassen, getrennt nach unterschiedlichen Ordnern pro Nutzer. Alternativ wird überlegt, ob sich etwas Vergleichbares auch mit Azure umsetzen ließe.
• Es wird nach Methoden für Embedding-Versionierung gefragt: Wie geht man mit Datenupdates um, wie legt man bestimmte Versionen offen oder filtert nach Datum? Es wird sogar erwogen, dem Chunk am Anfang eine Kontextversion hinzuzufügen.
  • Man könne einfach den Originaltext und Metadaten einschließlich Versionsinformationen zusammen im Vector Store speichern. Bei turbopuffer sei etwa das Filtern über Attribute bequem; dazu wird die Dokumentation verlinkt.
  • Schon die Frage selbst wird als sehr nützlich und wichtig empfunden.
• Es wirkt merkwürdig, dass die Reihenfolge der verwendeten LLM-Versionen GPT 4.1 → GPT 5 → wieder GPT 4.1 war und dass dies nicht zu den Versionen anderer Komponenten im Stack (z. B. text-embedding-large-3) passt.
  • Antwort des OP: GPT-5 wurde direkt nach Veröffentlichung ausprobiert, schnitt aber bei viel Kontextinput (bis zu 100.000 Token) schlechter ab als GPT-4.1, weshalb wieder zu 4.1 zurückgekehrt wurde. Konkret: a) schwächeres Instruction Following, also geringere Befolgung des System Prompts, b) zu ausschweifende Antworten, die die UX deutlich verschlechtern, c) ein Kontextfenster-Limit von 125.000 Token, wodurch sehr große Inputs zu Fehlern führen. Diese Probleme traten besonders bei „RAG“ mit vielen übergebenen Chunks auf; für allgemeinere Aufgaben könnte GPT-5 dennoch besser sein.
• Auch ohne AWS-Verfechter zu sein, wird betont, dass S3 Vectors in diesem Bereich aktuell state of the art seien. In Verbindung mit Bedrock Knowledge Base werde auch Discovery/Rebalance einfach, sodass dies die schlichteste Lösung am Markt sein könnte. Nach dem offiziellen Release könnte sie die meisten Wettbewerber deutlich übertreffen.
  • Es wird scherzhaft korrigiert, dass nicht „schlep“, sondern „shill“ das richtige Wort sei.
  • Es wird hinterfragt, warum S3 Vectors SOTA sein sollen; am Ende seien sie doch auch nur ein Vector Store, oder nicht?
• Embedding-basiertes RAG ist in der Praxis nicht unbedingt die beste Methode. Für einzelne Tasks oder Demos ist es gut, stößt in realen Szenarien aber oft an Grenzen.
  • Dem wird aus eigener Erfahrung teilweise widersprochen. Das Produkt Query Assistant von Honeycomb, an dem gearbeitet wurde, basierte seit 2023 ebenfalls auf Daten-Queries, und gerade weil die Funktion auf einen einfachen Zweck zugeschnitten war, wirkte sie wie eine ideale Richtung für LLM-basierte Produkte. Eine Kombination mit non-LLM-Verarbeitung sei sinnvoll.
  • RAG wird ständig neu interpretiert und hat viele Einsatzmöglichkeiten. Es wurde als Werkzeug in agentic search integriert und zugleich mit Echtzeitsuche in Quellen sowie klassischem Chunking kombiniert. Mit den bald verfügbaren großen Kontextfenstern dürfte es sogar möglich werden, komplette Dokumente in eine einzelne Anfrage zu packen.
  • Es wird gefragt, welche Alternative konkret empfohlen wird — ob dabei die Query-Generierung gemeint ist.
  • Auch ChatGPT nutzt RAG effektiv, um aktuelle Informationen zu erhalten; dieser praktische Nutzen sei genau der Grund, warum inzwischen alle großen Anbieter so etwas anbieten.
  • Es wird nachgefragt, worauf sich der Vergleich genau bezieht.
• Es wurde gesagt, dass viel Zeit und Aufwand in die Strategie zur Auswahl der Chunks fließt; dazu würde man gern mehr Details über die konkret verwendete Strategie hören.