Unternehmens-RAG-Architektur: Leitfaden zu Vector-DB, Chunking und Evaluation

In den vergangenen drei Jahren ist RAG (Retrieval-Augmented Generation) zur dominierenden Architektur für KI-Projekte im Unternehmen geworden. Anforderungen wie KVKK-Compliance, Verwaltung sensibler Daten und Arbeit mit unternehmensinternen Wissensbasen haben einen wesentlich praktischeren Weg eröffnet, als offene Modelle nachzutrainieren: Basismodell unverändert lassen, Unternehmens-Dokumente zur Laufzeit einspeisen und die Antwort generieren lassen. Die Parole ist einfach; die fehlende Disziplin in der Umsetzung lässt Projekte verfaulen. Der Unterschied zwischen produktivem RAG und Demo-RAG ist architektonische Qualität — jede Schicht, von der Vector-DB-Auswahl bis zur Chunking-Strategie, von Hybrid Search bis Reranker, vom Evaluation-Framework bis zum Produktions-Monitoring, muss gemessen und getestet sein.

Im Rahmen unserer Dienstleistungen RAG-Systems-Engineering und Vector-Database-Engineering haben wir in den vergangenen 18 Monaten an 12 Unternehmens-RAG-Projekten gearbeitet und betreiben unsere eigene AIGENCY-v4-Plattform auf einer RAG-lastigen Architektur. In diesem Artikel gehen wir sieben kritische Entscheidungen einer Unternehmens-RAG-Architektur der Reihe nach durch: Doc-Store-Auswahl, Chunking-Strategie, Embedding-Modell, Hybrid Search, Reranker-Schicht, Evaluation-Framework und Produktions-Monitoring.

1. Strategische Entscheidung — RAG, Fine-Tuning oder hybrid?

Die erste Frage lautet nicht lasst uns RAG nutzen — sie sollte lauten ist RAG das richtige Werkzeug für dieses Problem?. Drei Ansätze stehen zur Wahl:

• Pure RAG — das Basismodell bleibt unverändert; bei jeder Anfrage werden Unternehmens-Dokumente zur Laufzeit gezogen. Ideal für Szenarien mit häufig aktualisierten Daten, Audit-Anforderungen und Nachvollziehbarkeit (Recht, Kundensupport, Unternehmens-Wissensbasis).
• Fine-Tuning — das Basismodell wird für einen bestimmten Ton, ein Format oder eine Domänenaufgabe spezialisiert. Gut für stabile, eng gefasste Aufgaben (medizinische Berichterstattung, Code-Stil-Transformation, Produktbeschreibungserzeugung).
• Hybrid (RAG + Fine-Tuning) — das fine-getunte Modell trägt das Basiswissen (Domänenterminologie, Format), während RAG die kontinuierlich aktualisierten Daten liefert. Der dominierende Ansatz für komplexe, hochvolumige Unternehmens-Szenarien.

Entscheidungstest: Wenn Wissen sich täglich aktualisiert, RAG; wenn Verhalten/Format gelernt werden muss, Fine-Tuning; wenn beides nötig ist, Hybrid. Etwa 70 Prozent der Unternehmensprojekte starten mit Pure RAG; sobald sie reales Produktionsvolumen erreichen, gehen etwa die Hälfte in Hybrid über. Pures Fine-Tuning ist im Unternehmen eine Minderheit, weil Nachtrainieren bei jeder Wissensänderung kostspielig ist und Audit erschwert.

Zweiter praktischer Punkt: RAG ist kein Allheilmittel. Falsch eingesetzt steigen Halluzinationsraten (das LLM behandelt irrelevante Dokumente als Quellen), Latenz wächst, Kosten explodieren. Richtig eingesetzt sagt das Modell dort Ich weiß nicht, wo es das sollte, und antwortet dort mit Quellenangabe, wo es wirklich weiß. Der Unterschied ist architektonische Disziplin.

2. Doc-Store-Auswahl — pgvector vs. Qdrant vs. Milvus vs. Managed Services

Die Wahl der Vector-Datenbank ist die Skelett-Entscheidung der RAG-Architektur; ein späterer Wechsel bedeutet Migrationsschmerz und monatelanges Reiben. Drei Hauptkategorien:

PostgreSQL + pgvector — als Erweiterung auf vorhandenem PostgreSQL installiert. Eine Datenbank, ein Backup, ein Betrieb. Praktisch bei 100K-500K Embeddings. Vorteile: Metadaten-Filter auf SQL-Ebene, transaktionale Konsistenz, das Werkzeug, das Ihr Team ohnehin kennt. Nachteile: HNSW-Indizierung verlangsamt sich ab 1M+, und Filter + Vector-Search-Kombinationen verlangen besonderes Tuning. Unsere Empfehlung: Standardwahl für kleine bis mittlere Unternehmensprojekte.

Qdrant — in Rust geschrieben, vector-first-Datenbank. Hervorragende HNSW-Performance, nativer Payload-Filter, REST- und gRPC-APIs. Sweet Spot bei 1-50 Mio. Embeddings. Self-hosted oder als Managed Cloud. In Unternehmensprojekten seit 2023 populär geworden. In unserer AIGENCY-Pipeline halten wir 8 Mio. Embeddings in einem Qdrant-Cluster.

Milvus — verteilte Architektur, entworfen für sehr große Skalen (10 Mio.-1 Mrd.+ Embeddings). Hoher Betriebsaufwand (Kubernetes, etcd, MinIO als Komponenten); ohne dediziertes DevOps im Team schwer. Vorteil: GPU-beschleunigte Indizierung und fortgeschrittene Index-Optionen (IVF/HNSW/DiskANN).

Pinecone / Weaviate Cloud / Zilliz Cloud — Managed Services. Kein Betriebsaufwand, in Minuten produktionsbereit. Kosten: monatlich USD 70-1.500 für kleine bis mittlere Last, USD 3.000-15.000 für Enterprise-SLA. Aus KVKK-Sicht ist Datenstandort kritisch — Pinecone hat eine EU-Region, Weaviate bietet Self-Hosting oder AWS Frankfurt; ein DPA (Data Processing Agreement) ist im Vertrag Pflicht.

Entscheidungsmatrix:

Kriterium	pgvector	Qdrant	Milvus	Managed
Sweet-Spot-Skala	<500K	1M-50M	10M-1B+	Jede Skala
Betriebsaufwand	Niedrig	Mittel	Hoch	Keiner
Monatliche Infrastrukturkosten	TRY 500-3.000	TRY 3.000-15.000	TRY 10.000-40.000	USD 70-15.000
KVKK-Kontrolle	Voll	Voll	Voll	Vertragsabhängig
Hybrid Search	Manuell	Nativ	Nativ	Nativ
Latenz p95	30-100 ms	10-50 ms	5-30 ms	20-100 ms

Empfehlung: mit pgvector starten. Mit Annäherung an die 500K-Embedding-Grenze eine Qdrant-Migration planen. Ab 10 Mio. Milvus oder Managed Service in Betracht ziehen. Der Versuch, gleich groß zu wählen, erzeugt in den meisten Projekten Betriebs-Müdigkeit und unnötige Kosten.

3. Chunking-Strategie — Fixed Size reicht nicht

Der wichtigste einzelne Faktor der RAG-Qualität ist die Chunking-Strategie. Schlechte Chunks vergeuden selbst das weltweit beste Embedding-Modell. Drei Kernmuster:

Fixed-Size-Chunking — das Dokument wird in eine feste Tokenzahl aufgeteilt (z. B. 500 Tokens, 15 Prozent Overlap). Am einfachsten, am schnellsten; für Freitext (E-Mails, Chat-Logs) akzeptabel. Nachteil: Schnitte können mitten in Absätzen oder Sätzen landen; semantische Grenzen verschieben sich.

Strukturbewusstes Chunking — Aufteilung nach Dokumentstruktur: nach Markdown-Überschrift (#, ##), nach HTML-Section/Article-Tag, im PDF nach Schriftwechsel oder Bullet Points. Für technische Dokumente, Rechtstexte und Produkt-Specs ergibt sich 2-3-mal besserer Recall. Implementierung: fertige Parser in Unstructured.io, in LlamaIndex Node Parsers, in LangChain Text Splitters.

Semantisches Chunking — embedding-bewusste Aufteilung; ein neuer Chunk beginnt, wenn die Cosine-Distance zwischen zwei aufeinanderfolgenden Sätzen einen Schwellenwert überschreitet. Am ausgefeiltesten, aber rechenintensiv (zusätzlicher Embedding-Pass pro Dokument). Echter Mehrwert für komplexe, lange Texte (Fachartikel, Berichte).

Optimale Chunk-Größe ist domänenabhängig:

Dokumenttyp	Empfohlener Chunk	Overlap	Strategie
Vertrag, Rechtstext	600-900 Tokens	20 %	Strukturbewusst (Artikel/Absatz)
Technische Dokumentation	400-600 Tokens	15 %	Strukturbewusst (Überschriften)
Kundensupport-FAQ	200-400 Tokens	10 %	Q-A-Paar als ein Chunk
E-Mail, Chat-Log	300-500 Tokens	15 %	Fixed + Sliding Window
Fachartikel	500-800 Tokens	20 %	Semantisch
Code-Datei	Funktion als Ganzes	0	AST-bewusst (Tree-sitter)

In unserer AIGENCY-Pipeline klassifiziert zunächst ein Doc-Type-Classifier das Dokument (Vertrag / E-Mail / FAQ / Log / Artikel) und führt dann einen typspezifisch spezialisierten Chunker aus. Dieser Ansatz hat den Top-5-Recall im Vergleich zu einheitlichem Fixed-Chunking um 35 Prozent gehoben.

Dritter praktischer Punkt: Metadaten-Anreicherung. Heften Sie an jeden Chunk nicht nur Text, sondern auch Dokumenttitel, Section-Überschrift, Dokumenttyp, Source-URL, Sprache, Last-Updated-Datum und Autor. Bei der Retrieval ist diese Metadaten Gold für Filter (z. B. nur Dokumente der letzten 6 Monate); bei der Generierung ist sie Gold für die Quellenattribution.

4. Embedding-Modell — multilingual, dense, sparse, hybrid

Die Qualität des Embedding-Modells ist die Obergrenze der Retrieval-Qualität. Mit dem falschen Modell liefert auch das beste Chunking niedrigen Recall. Stand 2026 vier praktische Familien:

OpenAI text-embedding-3-large — 3072 Dimensionen, stark in Englisch, Türkisch und Arabisch, ca. USD 0,00013 pro Anfrage. In der Produktion populär, aber jede Anfrage geht zu OpenAI — aus KVKK-Sicht kann dies ein Datenstandort-Problem schaffen und erfordert einen DPA im Vertrag.

Cohere embed-multilingual-v3 — 1024 Dimensionen, 100+ Sprachen; in Türkisch und Arabisch etwas schwächer als OpenAI, aber dennoch stark. Cohere's EU-Region-Angebot ist ein Vorteil für KVKK. Kosten nah an OpenAI.

Open Source: BGE-M3, mE5-large, multilingual-MiniLM — self-hosted, läuft auf GPU. BGE-M3 kann in Dense-, Sparse- und Multi-Vector-Modi arbeiten (ähnlich Cohere's patentiertem Ansatz). Vorteile: volle KVKK-Kontrolle, keine Per-Query-Kosten, fine-tuning möglich. Nachteile: GPU-Betriebsaufwand; Roh-Latenz kann 2-5-mal höher sein als bei OpenAI/Cohere.

Domänenspezifisch fine-getunt — die Organisation fine-tuned BGE oder E5 contrastive auf eigenem Korpus. Training über 1-3 Epochen auf 5K-50K Query-Positive-Doc-Paaren hebt den Recall um 10-25 Prozent. Echter Mehrwert für domänenspezifische Sprache (Recht, Finanzen, Medizin).

Empfehlung: OpenAI oder Cohere für Piloten und PoCs; BGE-M3 self-hosted für KVKK-kritische Unternehmen; fine-getuntes BGE oder mE5 für reales Volumen und domänenspezifische Präzision. Ein Wechsel des Embedding-Modells verlangt das gesamte Korpus neu zu embedden — diese Kosten und Zeit gleich zu Beginn einkalkulieren (1 Mio. Dokumente × 2 Stunden Re-Embed × GPU-Stunden-Kosten).

5. Hybrid Search — Vector + BM25 + RRF

Reine Vector-Suche verfehlt bestimmte Anfragen:

• Exakter Keyword-Treffer nötig (Produktcode XR-2050-A, Gesetz 5651)
• Personen- und Ortsnamen (Embedding-Modelle repräsentieren Eigennamen schwach)
• Akronyme und Fachbegriffe (KVKK, MASAK, TS 13638)
• Negation (Systeme nicht KVKK-konform — Embeddings handhaben Negation schwach)

Lösung Hybrid Search: BM25 (sparse) + Vector (dense) laufen zusammen, Ergebnisse werden zusammengeführt. Zwei Merging-Ansätze:

Reciprocal Rank Fusion (RRF) — der Rang eines Dokuments in jedem System wird durch 1/(k+rank) geführt (k=60 Standard) und die zwei Scores werden summiert. Keine Score-Normalisierung nötig, robust. Standardwahl in Produktion.

Gewichteter Score — BM25-Score und Vector-Score werden separat normalisiert und anschließend mit Gewichten (z. B. 0,4 BM25, 0,6 Vector) verschmolzen. Gewichte müssen pro Domäne getuned werden; flexibler, aber tuning-intensiv.

Implementierung:

Vector-DB	Hybrid-Unterstützung
pgvector	Manuell (ts_vector + Cosine, im Code zusammengeführt)
Qdrant	Nativ (Fusion-API)
Weaviate	Nativ (Hybrid-Query)
Milvus	Nativ (BM25 + Vector + RRF)
Elasticsearch	Nativ (knn + match query)

In unseren Messungen hat Hybrid Search den Top-5-Recall um 18-32 Prozent und die Top-1-Genauigkeit (bestes Ergebnis) um 25-40 Prozent gegenüber reiner Vector-Suche gehoben. Außerhalb von PoCs behandeln wir es für jede produktive RAG als verpflichtend.

6. Reranker — der Präzisionsfilter der Pipeline

Die Retrieval-Phase ist schnell + breit (top-50, top-100 Dokumente); der Reranker ist langsam + präzise (ein Cross-Encoder bewertet jedes Query-Dokument-Paar einzeln und kürzt auf top-5). Die Mathematik des zweistufigen Ansatzes ist einfach: ein Bi-Encoder-Embedding wandelt Query und Dokument in getrennte Vektoren um und berechnet danach die Cosine-Distance — Information geht verloren. Ein Cross-Encoder gibt Query und Dokument dem Modell gemeinsam und erzeugt einen präziseren Score; weil aber jedes Query-Dokument-Paar einen separaten Modell-Call erfordert, ist er langsamer.

Praktischer Ablauf:

1. Query → Embedding → Vector-DB-Top-100-Retrieval (10-50 ms)
2. Top-100 → Reranker-Modell → Score pro Paar (50-300 ms für 100 Dokumente)
3. Top-5 / Top-10 → in LLM-Context platziert
4. LLM produziert die Antwort

Beliebte Reranker:

• Cohere Rerank v3 — Managed API, USD 0,001-0,002 pro Anfrage, 100 ms Latenz. EU-Region für KVKK. Die häufigste Wahl in Produktion.
• BGE Reranker (open source) — self-hosted, 50-150 ms auf GPU. Volle KVKK-Kontrolle, keine Per-Query-Kosten. Varianten: base/large/v2-m3.
• ColBERT v2 — Late-Interaction-Architektur, Score pro Query-Token pro Dokument-Token. Am präzisesten, aber operativ komplex. Nur für sehr hohe Präzisions-Use-Cases.
• Cross-Encoder ms-marco-MiniLM — kleines Modell, schnell (vertretbar selbst auf CPU), begrenzter Recall-Gewinn.

In AIGENCY nutzen wir Cohere Rerank v3 mit self-hosted BGE Reranker als Fallback. Automatischer Fallback bei Cohere-Ausfall hält das Latenz-Budget intakt.

Beweis des Reranker-Werts: in einem 200-Query-Benchmark lieferte Retrieval + LLM allein 62 Prozent Genauigkeit, Retrieval + Rerank + LLM stieg auf 84 Prozent. Für produktive RAG ist der Reranker nicht mehr optional — er wird als verpflichtende Schicht behandelt.

7. Evaluation-Framework — woher wissen Sie, dass das System wirklich funktioniert?

Der am häufigsten übersprungene Schritt in produktiver RAG ist die Evaluation. Das System geht in Produktion, weil die Demo funktioniert; drei Monate später beginnen die Klagen: warum sagt unser Modell Ich weiß nicht?. Lösung: kontinuierliche, dreischichtige Evaluation.

Schicht 1 — Retrieval-Evaluation. Ein Golden Dataset (50-200 manuell gelabelte Query-Positive-Doc-Paare) wird vorbereitet; das System liefert Top-K pro Query; Metriken:

• Recall@K: liegt das richtige Dokument in Top-K?
• MRR (Mean Reciprocal Rank): bei welchem Durchschnittsrang liegt das richtige Dokument?
• NDCG: stufenbewertete Ranking-Qualität.

Automatisiert: Ragas, TruLens, Phoenix (Arize) und DeepEval-Frameworks liefern fertige Retrieval- und Generation-Eval-Patterns. Wöchentliche automatisierte Läufe + Dashboard sind der Mindeststandard in Unternehmensprojekten.

Schicht 2 — Generation-Evaluation. Qualität der LLM-Antwort:

• Faithfulness: ist die Antwort treu zum Retrieved Context (keine Halluzination)?
• Answer Relevance: antwortet die Antwort auf die Query?
• Context Precision/Recall: wurde der nötige Kontext genutzt?

Das LLM-as-judge-Muster (GPT-4o oder Claude Opus wird gefragt bewerte die Quellentreue dieser Antwort, 1-5) ist schnell und skalierbar; aber subjektiv — quartalsweise menschliche Kalibrierung ist Pflicht (50-100 Sample manuelle Labels).

Schicht 3 — Produktions-Monitoring. Bei echten Nutzeranfragen:

• Latenz-Verteilung (p50, p95, p99) — Retrieval-, Rerank- und LLM-Stufen getrennt.
• Kosten pro Query — Token-Verbrauch und Vector-DB-Query-Kosten.
• Daumen-rauf/runter-Feedback-Rate — Nutzerfeedback.
• Ich-weiß-nicht / Clarification Rate — ist das Modell zu unsicher oder zu aggressiv?
• Halluzinations-Spot-Check — wöchentlich manuelle Überprüfung von 20-50 zufälligen Queries.

Ohne dass alle drei Schichten zusammenlaufen, dauert die Erkennung einer RAG-Degradation Monate. Ein Embedding-Modell-Upgrade, eine Chunking-Parameter-Anpassung, ein Vector-DB-Index-Rebuild — all das kann die Qualität still senken. Die Integration einer Eval-Suite in die CI/CD-Pipeline (Retrieval-Eval-Lauf bei jedem PR, Block bei Regression) ermöglicht eine disziplinierte RAG-Evolution.

Unser AI-Governance-Rahmen erläutert, wie diese Evaluation-Schichten mit den Audit-Anforderungen des Unternehmens verzahnt werden. In Kombination mit der KVKK-Datenverantwortlichen-Pflicht dient diese Eval zugleich als rechtlicher Nachweis — eine dokumentierte Antwort auf wie funktioniert unser Modell, welcher Quelle ist es treu.

Praktische Zusammenfassung — Startcheckliste

Die richtige Reihenfolge für Ihr erstes produktives RAG-Projekt:

1. Ist RAG tatsächlich richtig? — wenn sich Wissen selten aktualisiert, eher Fine-Tuning; wenn kein Verhalten gelernt wird, eher RAG; wenn beides, Hybrid.
2. Doc Store: mit pgvector starten (<500K Embeddings); bei Volumenwachstum zu Qdrant migrieren. Managed Service nur wenn KVKK-DPA vorliegt.
3. Chunking: Doc-Type-Classifier + pro-typ spezialisierter Chunker. Fixed-Size nur für Freitext. Strukturbewusst wann immer möglich als Standard.
4. Embedding: mit OpenAI/Cohere starten (PoC); für Produktion BGE-M3 self-hosted oder domänenspezifisch fine-getunt in Betracht ziehen.
5. Hybrid Search: BM25 + Vector + RRF. Außerhalb von PoCs immer.
6. Reranker: Cohere Rerank oder BGE Reranker. In Produktion verpflichtend.
7. Evaluation: Golden Dataset → Retrieval-Eval → LLM-Judge → Produktions-Monitoring. Alle drei, automatisiert wöchentlich.
8. Metadaten: heften Sie Dokumenttitel, Section, Typ, Source-URL, Datum und Sprache an jeden Chunk. Gold für Filter und Attribution.
9. KVKK: Datenstandort (Modell, Vector-DB, Logs), DPA, Aufbewahrungspolitik, Nachvollziehbarkeit von aus Nutzerdaten abgeleiteten Daten.
10. Kontinuierliche Verbesserung: Feedback-Loop schließen — Produktions-Queries mit niedriger Bewertung analysieren, Golden Dataset aktualisieren, Chunker/Embedding/Reranker iterieren.

Diese Liste ist die Mindestdisziplin. Darüber hinaus kommen domänenspezifische Anforderungen (Zitate für Legal-RAG, Confidence-Threshold für Medical-RAG, Eskalations-Muster für Customer-Support-RAG). Um echten Wert aus RAG in Produktion zu ziehen, muss man von die Demo funktioniert zu das Evaluation-Framework läuft wöchentlich und alarmiert beim Bruch übergehen.

Unser Team in Şanlıurfa Karaköprü hat diese Disziplin verinnerlicht, indem es unsere AIGENCY-v4-Plattform auf einer RAG-lastigen Architektur betreibt und Enterprise-RAG-Systems-Engineering liefert. Für ein Unternehmens-RAG-Pilot, eine Vector-DB-Auswahl oder eine Bewertung einer produktionsreifen RAG-Architektur erreichen Sie uns über das Kontaktformular — das erste Bewertungsgespräch ist kostenlos.

---

eCloud Tech — Ein in Şanlıurfa (Türkei) ansässiges Team für Unternehmenssoftware, KI, Blockchain und Cybersicherheit. Building Tomorrow.