2026 beruht die große Mehrheit der im Unternehmen ausgerollten KI-Chatbots auf RAG (Retrieval-Augmented Generation). Dennoch stellen wir in unseren Audits eine riesige Kluft zwischen Projekten, die funktionieren, und solchen, die dahinvegetieren, fest: Es ist fast nie das LLM, das das Problem ist. Es ist die Wissensbasis. Ein und dasselbe GPT-4 Turbo oder ein und dasselbe Mistral Large 2, an zwei unterschiedliche RAG-Pipelines angeschlossen, kann einen brillanten Assistenten oder einen höflichen Halluzinationsgenerator hervorbringen. Der Unterschied entsteht zu 90 % in der Retrieval-Ingenieurkunst.

Dieser Artikel ist ein technischer Leitfaden zum Aufbau eines RAG, das Ihren Chatbot wirklich nützlich macht. Wir detaillieren sechs Schritte: Audit der Quellen, Chunking, Embeddings, Vektordatenbank, Reranking, Evaluation. Jeder Schritt trägt eine konkrete Abwägung mit dokumentierten Trade-offs und Zahlen aus unseren Projekten. Ziel: Ihnen die richtigen Fragen zu liefern, bevor Sie ein RAG-Budget unterschreiben, und die richtigen Signale, um zu erkennen, dass ein bestehendes Projekt entgleist.

Warum RAG 2026 zum entscheidenden Schritt geworden ist

Frontier-LLMs sind massiv besser geworden, aber sie bleiben gegenüber Ihrem Geschäft fundamental unwissend. Ein nützlicher interner Assistent muss auf Basis Ihrer Dokumentation, Ihrer Prozesse, Ihrer Verträge, Ihrer Produkte antworten. Fine-Tuning bleibt aufwendig, kostspielig und wenig agil angesichts wöchentlich wechselnder Quellen. RAG hat sich durchgesetzt, weil es den richtigen Kompromiss bietet: den relevanten Kontext im Moment der Anfrage zu injizieren, ohne das Modell anzufassen, mit nahezu Echtzeit-Aktualisierung.

Aber RAG ist ein komplexes System mit mehreren Stufen. Jede Stufe kann das Ganze degradieren. Eine schlecht bereinigte Quelle, ein grobes Chunking, ein für Französisch ungeeignetes Embedding, eine schlecht konfigurierte Vektordatenbank, das Fehlen von Reranking — und die finale Antwort wird enttäuschend sein, selbst wenn das LLM exzellent ist. Deshalb behandeln wir RAG immer als eigenständige Ingenieursdisziplin mit eigenem Mess- und kontinuierlichem Verbesserungszyklus.

1. Quellen auditieren und bereinigen

Alles beginnt mit dem Korpus. Ein RAG-Chatbot erfindet nichts: Er wählt aus, formuliert um und synthetisiert, was Sie ihm geben. Wenn die interne Dokumentation drei widersprüchliche Versionen einer Prozedur enthält, wird das RAG zufällig eine der drei ausspielen. Wenn ein vergessenes PDF von 2019 in einem SharePoint liegt, wird es letztlich zitiert. Unser erster, systematischer Schritt ist ein Dokumenten-Audit: Quellen kartieren, Duplikate identifizieren, veraltete Inhalte markieren, Widersprüche aufspüren.

Konkret arbeiten wir in Chargen: 200 bis 500 Dokumente, die von einem Tandem aus Fachbereich und Technik durchgegangen werden, mit einem Qualifikationsraster (autoritativ? aktuell? konsistent?). Diese Arbeit ist undankbar, aber ausschlaggebend. Projekte, die diesen Schritt überspringen, holen den Rückstand nie auf: Sie stapeln technische Schichten, um einen kranken Korpus zu kompensieren.

  • Exakte Duplikate und Quasi-Duplikate entfernen
  • Veraltete Inhalte mit einem Ablaufdatum versehen
  • Widersprüche mit dem Fachbereich klären (explizite Validierung)
  • Formate normalisieren (sauberes Markdown statt gescannter PDFs)

2. Eine Chunking-Strategie wählen

Chunking ist die Operation, die jedes Dokument in indexierbare Fragmente zerlegt. Drei Parameter zählen: Größe, Overlap und Strategie. Zu klein (unter 200 Tokens) verlieren die Chunks ihren Kontext, und das Retrieval bringt inkohärente Fragmente. Zu groß (über 1500 Tokens) werden die Chunks unscharf, und das Embedding mittelt zu viele unterschiedliche Ideen. Unsere Standardspanne: 512 Tokens mit einem Overlap von 64 bis 128 Tokens. Dieser Wert ist aber nie heilig: Wir kalibrieren ihn am Golden Dataset.

Die Strategie zählt ebenso wie die Größe. Ein fixed-Chunking (alle N Tokens) ist schnell umzusetzen, aber brutal bei strukturierten Dokumenten. Ein semantic-Chunking (basierend auf Satz-Embeddings) respektiert die Sinneinheiten besser. Ein structure-aware-Chunking (das HTML-Tags, Markdown-Titel, PDF-Struktur nutzt) ist bei technischer Dokumentation fast immer überlegen. Auf einer E-Commerce-Website muss ein Produktblatt ein Chunk bleiben. Bei einem technischen Handbuch bildet jeder H2- oder H3-Abschnitt einen natürlichen Chunk.

3. Embeddings auswählen

Embeddings verwandeln jeden Chunk in einen Vektor. Sie sind das Suchorgan des RAG. Die Wahl hängt von drei Kriterien ab: Qualität in Ihrer Sprache (Französisch wird von rein englischen Modellen weiterhin schlecht abgedeckt), Dimension (512 bis 3072 je nach Modell, direkter Einfluss auf Speicherkosten und Latenz) und Kosten. Unsere vier wiederkehrenden Kandidaten 2026: OpenAI text-embedding-3-large (3072 Dimensionen, exzellente multilinguale Qualität, ~0,13 € pro Million Tokens), Cohere Embed v3 (1024 Dimensionen, sehr gut multilingual, unterstützt typisierte semantische Suche), BGE-M3 Open-Source (1024 Dimensionen, beachtliche Performance, self-hostable) und spezialisierte französische Modelle wie Solon oder CamemBERT-large für stark frankophone Korpora.

Unsere Methode: mindestens zwei Embedding-Modelle am Golden Dataset des Kunden testen. Recall@5 und Recall@10 messen. Die Differenz ist manchmal spektakulär — wir haben gesehen, wie BGE-M3 OpenAI auf einem sehr spezifischen französischen Rechtskorpus geschlagen hat, und umgekehrt auf einem multilingualen Technikkorpus. Kein Modell ist universell besser.

4. Die Vektordatenbank wählen

Die Vektordatenbank speichert die Embeddings und führt die Ähnlichkeitssuche aus (Cosinus, Dot-Product, L2). Fünf Optionen dominieren. Pinecone managed bleibt unschlagbar in der Time-to-Market: wenige Codezeilen, automatisches Scaling, aber wiederkehrende Kosten und Abhängigkeit von einem US-Anbieter. Qdrant Open-Source, self-hostable, performant, in Rust geschrieben: unsere Standardwahl, wenn Souveränität zählt. pgvector, falls Sie bereits Postgres haben: kein zusätzlicher Service nötig, perfekt bis zu einigen Millionen Vektoren. Weaviate für reiche Schemata und fortgeschrittene hybride Suche. Chroma für schnelle lokale POCs.

Richtkosten: 50 bis 500 € pro Monat je nach Volumen und Modus (managed vs. self-host). Über 10 Millionen Vektoren oder bei strengen Souveränitätsanforderungen wird Self-Host nahezu zwingend. Wir raten davon ab, mehrere Werkzeuge zu verketten: ein gut beherrschter Vector Store ist mehr wert als drei schlecht integrierte.

5. Reranking einrichten

Reranking ist der am stärksten unterschätzte Schritt im RAG. Das initiale Retrieval liefert typischerweise eine Top-20- oder Top-50-Liste von Chunk-Kandidaten nach Vektorähnlichkeit. Aber die Embedding-Ähnlichkeit ist eine grobe Annäherung an die reale Relevanz. Ein Reranker — ein schwereres Modell vom Typ Cross-Encoder — ordnet diese Kandidaten neu, indem er jedes Paar (Frage, Chunk) fein bewertet. In unseren Projekten bringt das Hinzufügen eines Rerankings 10 bis 15 % mehr Präzision auf die Top 3, also genau das, was in den finalen Prompt injiziert wird.

Zwei Optionen dominieren. Cohere Rerank v3 ist ein exzellenter managed Service, multilingual, etwa 1 € pro 1 000 Anfragen. BGE-reranker ist Open-Source, self-hostable, fast genauso leistungsfähig, ideal im souveränen Kontext. Der Aufwand ist minimal — wenige Stunden Integration, einige zehn Millisekunden Latenz — für einen Qualitätsgewinn, der einen LLM-Wechsel weit übertrifft.

6. Kontinuierlich evaluieren

Ein RAG ohne Evaluation ist eine Black Box, die stillschweigend driftet. Unser Standard: bereits im Scoping einen internen Golden Dataset von 50 bis 100 vom Fachbereich validierten Frage-Antwort-Paaren aufbauen und bei jeder Iteration die strukturierenden Metriken mit RAGAS messen: Faithfulness (haftet die Antwort an den Quellen?), Answer Relevance (beantwortet sie die Frage?), Context Precision, Context Recall. Diese vier Metriken zeichnen die gesamte Pipeline nach und erlauben, präzise zu lokalisieren, wo eine Regression auftritt.

Hinzu kommt die Evaluation in der Produktion: Nutzerfeedback (Daumen hoch/runter mit Kommentar), Monitoring von Fragen ohne zufriedenstellende Antwort, A/B-Testing zwischen zwei Konfigurationen (zum Beispiel Chunking 512 vs. 768, mit oder ohne Reranker). LangChain und LlamaIndex bieten inzwischen native Instrumentierungs-Hooks für diese Messungen, und Werkzeuge wie Langfuse oder Phoenix von Arize aggregieren sie sauber.

Die Fallen, die ein RAG scheitern lassen

Vier Fehler kehren systematisch in unseren Audits wieder. Erstens, ein zu feines oder zu grobes Chunking, einmal festgelegt und nie neu kalibriert. Zweitens, standardmäßig gewählte Embeddings ohne Test auf Französisch, obwohl die Sprache bei manchen Korpora einen großen Unterschied macht. Drittens, das Fehlen von Reranking — der rentabelste Schritt der Pipeline, doch regelmäßig ausgelassen. Viertens, das Fehlen einer Update-Pipeline: Die Wissensbasis ist auf den Deployment-Zeitpunkt eingefroren, und der Chatbot antwortet auf Fragen zu Produkten, die nicht mehr existieren.

Zu diesen technischen Fallen kommt eine methodische Falle: ein RAG „nach Augenmaß“ zu beurteilen. Ohne Golden Dataset, ohne RAGAS, ohne A/B ist jede Qualitätsdiskussion subjektiv und damit unkontrollierbar. Wir setzen die Messung ab der ersten Iteration durch, denn man verbessert nur, was man misst.

Wie geht es weiter?

Ein leistungsstarkes RAG ist kein Projekt von wenigen Tagen. Es ist ein System, das konzipiert, gemessen und gepflegt wird. Aber genau diese Investition macht den Unterschied zwischen einem Chatbot, den Ihre Teams wirklich nutzen, und einem nach drei Wochen aufgegebenen Gadget. Bei DevHighWay behandeln wir RAG als das Rückgrat jedes ausgelieferten Chatbots: auditierte Quellen, kalibriertes Chunking, getestete Embeddings, eingebauter Reranker, kontinuierliche Evaluation.

Wenn Sie nur eine Idee aus diesem Artikel mitnehmen: Die Qualität eines RAG-Chatbots entscheidet sich nicht in der Wahl des LLM, sondern in der Retrieval-Ingenieurkunst. Die hier beschriebenen sechs Schritte sind nicht optional, sie bilden ein System. Einen davon zu überspringen, heißt eine systemische Qualitätsverschlechterung zu akzeptieren. Sie ernsthaft, mit Methode und Messung anzugehen, heißt sich die Mittel zu geben, einen Assistenten zu liefern, den Ihre Teams täglich nutzen werden — und der mittelfristig zu einem strategischen Asset Ihrer Organisation wird.