Startseite / Artikel

Fortgeschrittene RAG-Technologien in der Praxis: Architektur, Werkzeuge und Kompromisse.

Eine Übersicht über die Produktion von RAG: Eingabe, Parsen, Chunking, Embeddings, Vektorlagern, hybride Suche, Neubewertung, Bewertung und Sicherheit sowie die jeweiligen Kompromisse.

Verlag: REACTAPP.TOP13 Min. Lesezeit3002 Wörter

Quellen: **Advanced RAG: Production-Ready Architecture, Technologies, Key Features & Limitations**

Retrieval-Augmented Generation kombiniert einen Suchschritt mit einem Sprachmodell. Dokumente werden im Voraus eingelesen und indiziert, die relevanten Teile werden bei einem Eingang einer Frage abgerufen und das Modell formuliert seine Antwort anhand dieses Materials. In der Praxis ist RAG jedoch selten nur eine Vektordatenbank zusammen mit einem LLM. Reale Systeme beinhalten außerdem die strukturierte Analyse von Dokumenten, das fragmentbasierte Verarbeiten unter Berücksichtigung der Struktur, die Suche nach dichten Inhalten sowie Schlüsselwörtern, eine Neubewertung der Ergebnisse, die Erstellung von Kontexten, Bewertungen sowie Mechanismen zur Überwachung.

Im Folgenden werden ausschließlich Werkzeuge behandelt, die in realen Systemen weit verbreitet sind, wobei experimentelle Techniken außer Acht gelassen werden.

Überblick über den Prozessablauf

Ein praktischer, fortgeschrittener Pipeline beginnt mit der Eingabe, Analyse und Reinigung der Daten, folgt dann dem Aufteilen in Blöcke, der Erstellung von Metadaten, Embeddings und Indexierung. Bei Abfragen kommen Verständnis der Abfrage, hybride Suchmethoden, Fusion und Neuranking zum Einsatz, anschließend die Kompression des Kontexts, die Erstellung mit Quellenangaben und schließlich die Bewertung sowie die Überwachbarkeit. Die genaue Technologieauswahl hängt von den Dokumenttypen, der Skalierung, den Latenzzielen, den Datenschutzvorschriften, dem Budget sowie den Anforderungen an die Qualität ab.

Eingabe

Lokale Dateien. Python mit den Bibliotheken pathlib, PyPDF, python-docx, openpyxl und pandas ermöglicht kostengünstige Verarbeitung von PDFs, Word-Dateien, Tabellenkalkulationen, CSV-Dateien und Textdateien und eignet sich gut für Batch-Aufgaben. Der Nachteil ist, dass jedes Format seinen eigenen Parser benötigt, gescannte und komplexe PDFs eine spezielle Extraktion erfordern und große Aufgaben Parallelisierung sowie schrittweise Verarbeitung benötigen.

Objektspeicherung. Amazon S3, Google Cloud Storage und Azure Blob Storage bieten zuverlässige, skalierbare Lösungen für große Datensammlungen und eignen sich hervorragend für asynchrone Datenaufnahme. Die Kosten entstehen durch die Cloud-Einrichtung, die Zugriffskontrolle sowie Speicher- und Übertragungskosten, die mit der Skalierung zunehmen.

Web- und API-Quellen. Tools wie requests oder httpx, BeautifulSoup, Playwright und Firecrawl halten eine Wissensdatenbank aktuell, indem sie Websites, APIs und dynamische Seiten abrufen. Websites ändern ihre Struktur, JavaScript-reiche Seiten erfordern Browserautomatisierung, und das Crawlen führt zu Ratebeschränkungen, doppelten Seiten sowie uneinheitlicher Inhaltqualität.

Parsing und Extraktion

Unstructured akzeptiert PDFs, Word-, HTML-, PowerPoint-Dateien, Bilder und vieles mehr und extrahiert Elemente wie Überschriften, Absätze und Tabellen – wodurch es als vielseitige Allzwecklösung geeignet ist. Es ist langsamer als naive Textextraktionen, und ungewöhnliche Dokumente erfordern möglicherweise weitergehende Anpassungen.

PyMuPDF ist schnell bei der Extraktion von Text und Metadaten aus textbasierten PDFs und lässt sich leicht in Python-Code integrieren. Es handelt sich dabei jedoch nicht um ein vollständiges System zur Verarbeitung von Dokumenten, weshalb gescannte Dateien eine OCR-Verarbeitung benötigen und komplexe Layouts oder Tabellen zusätzliche Bearbeitung erfordern.

Apache Tika unterstützt eine sehr breite Palette an Formaten sowie ausgereifte Werkzeuge zur Extraktion von Text und Metadaten aus gemischten Datensammlungen. Es ist weniger auf ein modernes, layoutorientiertes Verständnis ausgelegt, wodurch komplexe visuelle Layouts zusätzliche Tools erfordern.

OCR und auf Bilderkennung basierende Extraktion

Tesseract ist Open Source, läuft lokal und erweist sich bei gewöhnlichem gedrucktem Text als sehr zuverlässig. Handschriftliche Texte sowie komplexe Layouts verringern die Genauigkeit, und grobe Scans benötigen eine Vorverarbeitung.

PaddleOCR bietet ein leistungsstarkes Verfahren für die Texterkennung und -analyse in vielen Sprachen, das sich besonders für gescannte Dokumente sowie die strukturierte Extraktion eignet. Komplexe Dokumente können dennoch eine Nachverarbeitung des Layouts erfordern, und bei der Implementierung können zusätzliche Modellabhängigkeiten hinzukommen.

Vision- und Sprachmodelle wie Modelle der GPT-4-Klasse, Gemini sowie die Qwen-VL-Familie verstehen Texte, Bilder, Diagramme und Seitenlayouts – was hilft, wenn allein die OCR-Technologie den visuellen Kontext verliert, und ermöglicht eine multimodale RAG-Anwendung. Sie sind teurer als klassische OCR-Tools, reagieren langsamer und liefern nicht-deterministische Ergebnisse, die überprüft werden sollten.

Chunking

Das Chunking bestimmt, was zu einer abrufbaren Einheit wird. Schlechtes Chunking trennt relevante Informationen voneinander oder bringt unverwandte Inhalte zusammen.

  • Rekursives Zeichensegmentieren (LangChain’s RecursiveCharacterTextSplitter) ist eine zuverlässige Grundlage, die versucht, Absatz- und Satzgrenzen einzuhalten, und leicht anzupassen ist. Es arbeitet nach Syntax und nicht nach Bedeutung, weshalb eine feste Größe nicht für jedes Dokument geeignet ist.
  • Tokelbasiertes Segmentieren teilt die Inhalte nach Modelltokeln auf, was bei den Grenzen des Kontextfensters hilft. Die Ränder der Tokel stimmen nicht unbedingt mit den semantischen Grenzen überein.
  • Semantisches Chunking sucht nach thematischen Wechseln mithilfe von Ähnlichkeitsmessungen, sodass kohärente Ideen besser zusammenbleiben als bei fester Größe. Es erfordert mehr Rechenleistung, benötigt Embeddings und hängt von einem von Ihnen festgelegten Schwellenwert ab.
  • Eltern-Kind-Chunking erfasst kleine Kind-Chunks, erweitert sie jedoch zu größeren Eltern-Chunks zum besseren Kontext, wodurch die Präzision verbessert wird, ohne dass der umliegende Kontext verloren geht. Die Verknüpfungen zwischen Indexen und Metadaten werden komplizierter, und der größere Kontext erhöht die Kosten pro Token.
  • strukturbezogenes Chunking folgt Überschriften, Abschnitten, Tabellen und Paragraphen, was sich bei technischen und Unternehmensdokumenten auszahlt. Es setzt eine zuverlässige Parsing-Funktion voraus, und unterschiedliche Dokumenttypen erfordern unterschiedliche Regeln.
  • Metadaten

    Zu den typischen Feldern gehören die Dokument-ID, der Dateinamen, die Seitenzahl, der Abschnitt, der Autor, das Zeitstempel, die Dokumentart, der Mieter oder Benutzer, die Zugriffsrechte, die Quell-URL und die Version. Gute Metadaten ermöglichen das Filtern vor oder während der Abfrage, unterstützen Zitierungen und den Zugriffskontrollmechanismus sowie die Genauigkeit. Andererseits verringern schwache Metadaten direkt die Qualität der Abfrage, und Schemata sind in gemischten Quellen schwerer zu warten.

    Embeddings

    Embeddings wandeln Text in Vektoren um, die die Bedeutung erfassen.

    • OpenAI Embeddings sind gut verwaltet, von hoher Qualität und einfach zu aufrufen; sie bieten eine starke Allzweckfunktion für die Abfrage. Nachteile sind die API-Kosten, die Abhängigkeit vom Anbieter sowie die Tatsache, dass das Senden von Daten in sensiblen Umgebungen ungeeignet sein kann.
  • BGE ist eine leistungsstarke Open-Source-Retrieval-Familie, die man selbst hosten kann, mit Varianten für dichte Retrieval-Verfahren und Neubewertung. Das Selbsthosting erfordert Infrastruktur, und die Wahl des Modells sowie die Dimensionalität beeinflussen Speicherbedarf und Latenzzeit.
  • E5 ist eine beliebte Open-Source-Familie mit solider allgemeiner Retrieval-Funktionalität sowie Varianten, die auf Anweisungen oder Präfixen basieren. Einige Varianten erfordern sorgfältiges Formatieren von Abfragen und Dokumenten, und das Eigenbetreiben verursacht zusätzliche Verarbeitungsaufwände.
  • Cohere Embed ist eine verwaltete API mit guter multilingualer und unternehmensorientierter Retrieval-Funktionalität, je nach Modellversion, und sie lässt sich leicht einsetzen. Allerdings entstehen API-Kosten sowie externe Abhängigkeiten.
  • Jina Embeddings sind auf Retrieval ausgerichtete Modelle, von denen einige lange Kontexte und mehrere Sprachen unterstützen. Die Funktionalitäten variieren je nach Version, und offene Modelle benötigen Infrastruktur zum Hosten.
  • Vektordatenbanken

    • pgvector fügt PostgreSQL Vektorabfragen hinzu und bringt relationale Daten, Metadaten sowie Vektoren an einem Ort zusammen – was hervorragend ist, wenn die Anwendung bereits Postgres verwendet. Sehr große Vektorarbeitslasten erfordern möglicherweise spezialisierte Systeme, und das Skalieren wird bei hohem Volumen schwieriger.
    • Pinecone ist eine verwaltete Vektordatenbank, die ohne Infrastrukturarbeit skaliert und ein für die Produktion geeignetes Filtern bietet. Man zahlt für den Service, ist vom Anbieter abhängig und gibt etwas Kontrolle auf.
    • Qdrant ist als Open Source oder in der Cloud verfügbar, filtert Metadaten effektiv, unterstützt dichte sowie hybride Suchverfahren und eignet sich für selbst gehostete RAG-Lösungen. Selbst Hosting bedeutet Betriebsaufwand, und verteilt eingerichtete Systeme erfordern sorgfältige Kapazitätsplanung.
  • Weaviate bietet umfangreiche Suchfunktionen, hybride Suche sowie Filterung von Metadaten – sowohl in Cloud- als auch in selbst gehosteter Form. Mehr Funktionen können zu größerer Systemkomplexität führen, und große Arbeitslasten erfordern Anpassungen.
  • Chroma eignet sich gut für Entwickler und ist praktisch für Prototypen sowie kleinere Anwendungen, da es eine einfache Integration mit Python bietet. Es ist in der Regel nicht die erste Wahl für sehr große Unternehmensumgebungen, bei denen Skalierbarkeit und Betriebshandhabung wichtiger sind.
  • FAISS ist eine äußerst beliebte Bibliothek für schnelle Ähnlichkeitssuche sowie lokale Experimente ohne externe Datenbank. Es handelt sich dabei um eine Suchbibliothek und nicht um eine verteilte Datenbank; daher erfordern Persistenz, Filterung, Multi-Tenancy und Verteilung zusätzliche ingenieurtechnische Lösungen.
  • Auswertung der Suchergebnisse

    Dichte Vektorabfrage verbindet eine Vektordatenbank mit einem Embedding-Modell und findet semantisch ähnlichen Inhalt, wobei sie Paraphrasen besser handhabt als Schlüsselwörter. Sie kann genaue Identifikatoren, seltene Begriffe, Codes und Zahlen übersehen, und die Qualität hängt stark vom Embedding-Modell sowie der Aufteilung in Blöcke ab.

    BM25 ist eine starke lexikalische Methode, die sich hervorragend für genaue Begriffe, Namen, IDs und technische Schlüsselwörter eignet und zudem einfach sowie interpretierbar ist. Sie erfasst keine semantische Ähnlichkeit, wodurch Synonyme und Paraphrasen durchdringen können.

    Hybride Abfrage kombiniert in der Regel BM25 mit dichten Suchverfahren, um lexikalische Präzision mit semantischem Umfang zu verbinden und so zuverlässigere Ergebnisse bei gemischten Abfruktypen zu erzielen. Dafür sind Score- oder Rangfusionsverfahren sowie mehr Infrastruktur und Feinabstimmung erforderlich als bei einem einzelnen Suchmechanismus.

    Abfrumwandlung

    • Abfragen umformulieren wandelt gesprochene oder vage Eingaben in etwas um, das für die Suche geeignet ist, was bei nachfolgenden Fragen hilft. Eine schlechte Umformulierung kann wichtige Informationen verlieren und zudem zu höherer Latenz sowie höheren Kosten beim LLM führen.
    • Mehrfachabfragesuche lässt das Modell mehrere alternative Abfragen erstellen und für jede davon suchen, wodurch die Trefferquote verbessert wird und unterschiedliche Formulierungen abgedeckt werden. Dadurch entstehen mehr Suchaufrufe, höhere Latenz und Kosten sowie gelegentlich irrelevante Ergebnisse.
    • HyDE (Hypothetical Document Embeddings) erzeugt eine erfundene Antwort und embeddet diese zur Suche, was bei schwierigen Abfragen oder Fällen hilfreich sein kann, in denen das Vokabular der Frage stark vom der Dokumente abweicht. Dafür ist ein zusätzlicher LLM-Aufruf notwendig, und eine schlechte hypothetische Dokumentdarstellung kann die Ergebnisse verfälschen.

    Fusion

    Reciprocal Rank Fusion fügt die Ranglisten mehrerer Suchmaschinen zusammen. Sie ist einfach, zuverlässig und eignet sich gut für dichte sowie BM25-Methoden; außerdem sind keine vergleichbaren Werte aus verschiedenen Systemen erforderlich. Dabei wird eine zusätzliche Rangierungsstufe hinzugefügt, doch es gibt weiterhin Parameter, die angepasst werden müssen.

    Weighted score fusion weist dichten, spärlichen oder anderen Signalen unterschiedliche Bedeutung zu, was nützlich ist, wenn die Suchmaschinen unterschiedliche Stärken aufweisen. Die Score-Skalen müssen normalisiert werden, und die Gewichte hängen von der Arbeitslast ab.

    Reranking

    Die erste Suchstufe sollte die Vollständigkeit fördern. Das Reranking erhöht anschließend die Genauigkeit auf einer kleineren Auswahl an Kandidaten.

    Cross-Encoder Reranker wie BGE Reranker, Cohere Rerank und Jina Reranker bewerten jedes Abfragen-Dokument-Paar gemeinsam, erzielen in der Regel bessere Ergebnisse als reine Embedding-Similarity-Methoden und funktionieren gut nach hybrider Suche. Sie sind teurer als Vektorabfragen, daher sollten sie nur auf einer begrenzten Liste von Kandidaten eingesetzt werden.

    LLM-Reranking lässt ein Modell die Relevanz beurteilen und kann komplexe Kriterien berücksichtigen, ist jedoch langsam, ressourcenintensiv und weniger deterministisch als speziell entwickelte Reranker.

    Maximum Marginal Relevance (MMR) balanciert Relevanz und Vielfalt aus, indem es Duplikate entfernt, wenn die top-k Ergebnisse nahezu identische Abschnitte sind. Dabei wird ein Vielfaltsparameter hinzugefügt – zu viel Vielfalt kann jedoch relevante Informationen ausschließen, die zufällig wiederholt auftauchen.

    Kontextkompression

    Extraktive Kompression behält nur relevante Sätze oder Abschnitte bei, wodurch Tokens eingespart und die ursprüngliche Formulierung bewahrt werden, doch sie kann den für das Verständnis eines Textes notwendigen Kontext entfernen. Kompression auf Basis von LLMs fasst das abgerufte Material zusammen und kann den Kontext bei großen Dokumenten erheblich reduzieren, was jedoch zu höheren Kosten und Verzögerungen führt sowie das Risiko birgt, dass durch die Kompression selbst Informationen verloren gehen oder Fehlinformationen entstehen.

    Generierung

    Häufige Produktionslösungen sind OpenAI-Modelle, Anthropic Claude, Google Gemini, Meta Llama und Qwen. Sie verfügen über starke Schlussfolgerungsfähigkeiten, und Anfragen können je nach Kosten, Verzögerung und Aufwand verteilt werden. API-Modelle bedeuten Kosten und Abhängigkeit vom Anbieter, offene Modelle benötigen Infrastruktur, und größere Modelle erhöhen die Verzögerung sowie die Berechnungskosten.

    Frameworks

    LangChain verfügt über ein umfangreiches Ökosystem an Ladeverfahren, Suchmechanismen, Integrationen zu Vektorlagern sowie Modell-Schnittstellen, die dabei helfen, Pipelines schnell zusammenzustellen. Abstraktionen können jedoch kompliziert werden, und Produktivsysteme funktionieren oft besser mit einem schlichten, eindeutigen Anfragenweg.

    LlamaIndex konzentriert sich auf die Eingabe, Indexierung und Suche sowie auf nützliche Abstraktionen für dokumentenzentrierte RAG-Anwendungen. Er erhöht die Komplexität des Frameworks, weshalb einige fortgeschrittene Systeme letztendlich auf niederschwelligere SDKs wechseln.

    LangGraph eignet sich für statebasierte, verzweigte sowie agierende Workflows mit iterativer Suche und Ausführung von Tools. Er bietet mehr Funktionalität, als ein einfacher Pipeline benötigt, und erfordert sorgfältige Handhabung von Zuständen sowie Fehlern.

    Fortgeschrittene Muster

    • Korrigierendes RAG bewertet den abgerufenen Kontext und kann weitere Abfragen auslösen, schwache Ergebnisse erkennen sowie eine Ersatzsuche ermöglichen – auf Kosten von Latenz und Komplexität.
    • Selbstständiges RAG lässt das Modell selbst entscheiden, wann Daten abgerufen werden sollen, und beurteilt die zurückgegebenen Ergebnisse. Es passt sich an, um unnötige Abfragen zu vermeiden, doch die Steuerlogik ist komplexer und erfordert sorgfältige Bewertung sowie Modellunterstützung.
    • Agentenbasiertes RAG verfügt über einen Agenten, der Suchanfragen plant, Tools aufruft, iterativ Daten abruft und diese überprüft; es kann damit komplexe, mehrschrittige Fragen aus verschiedenen Quellen bearbeiten. Zu erwarten sind höhere Latenzzeiten und Kosten, mehr Fehlermöglichkeiten sowie schwierigere Fehlersuche.
  • Graph RAG kombiniert ein Wissensgraphen mit der Informationsabruffunktion, wodurch Beziehungen zwischen Entitäten sowie mehrstufige Fragen bewältigt werden können, die herkömmliche Vektoren überspringen. Der Aufbau des Graphen ist aufwendig, die Entitätenextraktion führt zu Fehlern und es sind zusätzliche Infrastrukturen erforderlich.
  • Multimodal RAG ruft Informationen aus Texten, Bildern, Tabellen und Diagrammen ab und führt Überlegungen damit durch – geeignet für Berichte, Scans und Diagramme – wobei die Datenaufnahme und -indizierung aufwändiger ist und die Kosten für visuelle Modelle höher ausfallen.
  • Gestrukturierte Daten

    Text-to-SQL ermöglicht es dem Modell, Fragen in natürlicher Sprache in Abfragen gegen gestrukturierte Datenbanken umzuwandeln, was hervorragend für Analysen an aktuellen Daten geeignet ist. Die erzeugten SQL-Abfragen können fehlerhaft oder unsicher sein, weshalb ein Abruf des Schemas, Validierung sowie Zugriffskontrolle notwendig sind.

    Hybrider Text- und SQL-RAG nutzt Vektor- oder Schlüsselwortabfragen für unstrukturiertes Wissen sowie SQL für strukturierte Fakten und umfasst damit PDFs, Dokumente, CSV-Dateien sowie Datenbanken in einem einzigen Design. Er erfordert eine Steuerung zwischen den verschiedenen Modi und erschwert somit Tests sowie die Sicherheitssicherung.

    Bewertung

    Ein Produktivsystem benötigt eine Bewertung sowohl auf der Ebene der Abfrage als auch auf der Ebene der Erstellung.

    Abfragemetriken (Recall@K, Precision@K, MRR, NDCG und Trefferquote) beurteilen, ob der Abfragesystem die richtigen Belege gefunden hat. Erstellungsmetriken (Treue, Relevanz der Antwort, Richtigkeit der Antwort, Kontextrelevanz, Kontextgenauigkeit und Kontextrecall) prüfen, ob das Modell diese Belege ordnungsgemäß verwendet hat.

    Ragas ist für die RAG-Bewertung konzipiert, umfasst beide Ebenen und eignet sich für Regressionstests. Viele seiner Metriken stützen sich auf LLMs oder Embedding-Bewerter, wodurch die Ergebnisse die menschliche Prüfung nicht vollständig ersetzen können und die Bewertungsmodelle Voreingenommenheiten aufweisen mögen. Menschliche Bewertung ist am besten geeignet, um qualitativ hochwertige Ergebnisse für spezifische Bereiche zu gewährleisten und das zu erkennen, was automatische Metriken übersehen, doch sie ist teuer, langsam und erfordert einheitliche Richtlinien.

    Beobachtbarkeit

    LangSmith verfolgt Ketten, Abrufaufrufe, Anfragen und Ausgaben und hilft dabei, Pipelines zu debuggen sowie Experimente zu vergleichen. Es handelt sich um eine verwaltete Plattform mit Berücksichtigungen hinsichtlich Kosten und Privatsphäre. Langfuse bietet Tracking, Anfragemanagement sowie Metriken in Form einer Open-Source-Lösung für selbst gehostete Systeme oder die Cloud – wobei die Selbsthosting-Lösung in Ihrer Verantwortung liegt und Instrumentierung erfordert. OpenTelemetry ist der offene Standard für Tracking, Metriken und Logs und ermöglicht es, RAG in bestehende Infrastrukturen zu integrieren, allerdings mit höherem Aufwand im Vergleich zu einer fertig konfigurierten Plattform.

    Caching und Leistung

    Ein semantischer Cache wiederverwendet Antworten für ähnliche Abfragen und reduziert dadurch wiederholte Aufrufe des LLM, die Latenz sowie die Kosten. Allerdings können ähnliche Fragen bei Datenänderungen unterschiedliche Antworten erfordern, wobei eine Invalidation schwierig ist. Ein Embedding-Cache vermeidet die erneute Berechnung von Vektoren für wiederholten Text – ein einfacher Vorteil, der jedoch jedes Mal invalidiert werden muss, wenn sich das Embedding-Modell ändert. Asynchrone und parallele Abfragen führen unabhängige Abfrageverfahren gleichzeitig aus und verkürzen die Gesamtlatenz, wobei die Fehlerbehandlung komplexer wird und die Backend-Systeme einen koncurrenten Lastaufkommen standhalten müssen.

    Sicherheit

    • Prompt-Injection. Abgerufene Dokumente können Anweisungen enthalten, die dazu dienen, das Modell zu manipulieren.
    • Zugriffskontrollierte Abfragen. Benutzer sollten nur die Dokumente erhalten, für die sie autorisiert sind.
  • Verarbeitung personenbezogener Daten. Personenbezogene Daten müssen gefunden und maskiert werden oder anderweitig geregelt, bevor sie im Index landen.
  • Trennung der Nutzer. Bei mehreren Nutzern benötigen Abfragen metadatenbasierte Filter, die auf den jeweiligen Nutzer Rücksicht nehmen, und die Datenbank selbst muss getrennt werden.
  • Datenverfälschung. Dokumente aus unzuverlässigen Quellen können absichtlich eingefügt werden, um in die Irre zu führen.
  • Niemandes Anweisung löst alle Sicherheitsprobleme. Es sind Kontrollmaßnahmen in allen Phasen erforderlich – von der Eingabe über die Speicherung, das Abrufen, die Autorisierung bis hin zur Ausführung und Erstellung von Tools.

    Einsatz

    Häufig verwendete Bausteine sind FastAPI für die API-Schicht, Docker zur Verpackung, Kubernetes für die Skalierung der Orchestrierung, Redis zum Caching, PostgreSQL für relationale Metadaten, S3, GCS oder Azure Blob für Objektspeicherung, Prometheus zur Erfassung von Metriken, Grafana für Dashboards, OpenTelemetry zum Tracking sowie MLflow zur Erfassung von Experimenten. Ziel ist ein RAG-System, das reproduzierbar, überwachbar, skalierbar und wartbar ist – nicht eines, das lediglich in einer Notebook-Datei korrekt erscheint.

    Eine praktische Technologieauswahl

    Ein solides, allgemein einsetzbares Design kann recht einfach bleiben. Dokumente durchlaufen zunächst Unstructured, PyMuPDF oder PaddleOCR, anschließend eine strukturorientierte oder rekursive Aufteilung in Blöcke, danach Embeddings von OpenAI, BGE, E5 oder Cohere, gefolgt von pgvector, Qdrant oder Pinecone. Die Suche erfolgt mithilfe von BM25 in Kombination mit dichter Suche, kombiniert mit RRF, neu geordnet durch einen Cross-Encoder, komprimiert und an das LLM übergeben, wobei Zitate zur Verifizierung bereitgestellt werden. Ragas sowie menschliche Überprüfungen bewerten die Qualität, während LangSmith, Langfuse oder OpenTelemetry den Laufzeitverbrauch überwachen.

    Nicht jedes System benötigt alle Komponenten. Eine kleine interne Wissensdatenbank kann mit PostgreSQL, pgvector, Embeddings und einem LLM auskommen. Hybride Suchverfahren, Neuranking, agierende Schleifen, grafbasierte Suche sowie multimodales Verarbeiten sollten erst hinzugefügt werden, wenn eine Bewertung zeigt, dass das einfachere Design unzureichend ist.

    Die richtige Werkzeugwahl

    • Einfacher PDF-Text: PyMuPDF. Gemischte Dokumenttypen: Unstrukturiert. Scans: PaddleOCR. Visuell komplexe Seiten: ein Vision-Language-Modell.
    • Grundlegende Aufteilung in Blöcke: ein rekursiver Splitter. Semantische Grenzen: semantische Aufteilung in Blöcke. Eltern- und Kindkontext: Abfrage nach Eltern- und Kindelementen.
    • Verwaltete Embeddings: OpenAI oder Cohere. Offene Embeddings: BGE oder E5.
    • Bereits in PostgreSQL enthalten: pgvector. Verwalteter Vektor-Speicher: Pinecone. Selbsterhostet: Qdrant. Prototypen: Chroma oder FAISS.
    • Suchfunktion basierend auf Bedeutung: dichte Vektoren. Genaue Schlüsselwörter: BM25. Zuverlässige Abdeckung: hybride Methode. Zusammenführung der Ranglisten: RRF. Höhere Präzision: ein Cross-Encoder-Reranker. Weniger Duplikate: MMR.
    • Komplexe, mehrstufige Fragen: agiler RAG. Entity-Beziehungen: Graph RAG. Tabellen und Datenbanken: Text-zu-SQL.
  • Bewertung: Ragas. Nachverfolgung: LangSmith oder Langfuse. Standard-Telemetrie: OpenTelemetry. Hochskalierende API: FastAPI mit Docker oder Kubernetes.
  • Fangen Sie klein an

    Der größte architektonische Fehler besteht darin, das LLM als das gesamte System zu betrachten. Qualität entsteht von der Informationsbeschaffung über den Kontext bis zur Generierung und weiterhin durch Bewertung und Überwachbarkeit. Ein größeres Modell kann fehlende Informationen nicht zuverlässig ausgleichen.

    Ein nützlicher Verbesserungskreislauf besteht aus Festlegung eines Baseline-Werts, Bewertung, Erkennung des fehlerhaften Schritts, Änderung eines Komponenten, erneuter Bewertung, Bereitstellung und Überwachung. Für die meisten Produktionsysteme sollten zunächst solide Parsing-Verfahren sowie strukturbewusstes Aufteilen in Blöcke, gute Embeddings, hybride Informationsbeschaffungsmethoden und ein Reranker eingesetzt werden, anschließend kommen grounded Generation und Bewertung hinzu. Aggressive Informationsbeschaffungsverfahren, Graph RAG, multimodale Pipelines, Korrekturläufe oder Feinabstimmungen sollten nur eingeführt werden, wenn messbare Anforderungen deren Kosten und Komplexität rechtfertigen.

    Gute RAG-Engineering-Praxis bedeutet weniger, jede mögliche Technologie zu sammeln, sondern vielmehr die kleinste Architektur auszuwählen, die Ihre Anforderungen hinsichtlich Qualität, Latenz, Kosten, Sicherheit und Wartbarkeit erfüllt.