RAG & Dokumentenverarbeitung

Bedarfssignatur

Was es ist & Reifegrad

RAG (Retrieval-Augmented Generation) kombiniert eine Vektorsuche über ein Dokumentkorpus mit einem LLM-Generierungsschritt. Dabei wird jeder Textabschnitt („Chunk") per Embedding-Modell in einen Vektor (Embedding, eine Zahlenliste mit z. B. 768 oder 1536 Dimensionen) übersetzt; diese Vektoren liegen in einem Vektor-Index/einer Vektor-DB (Vektor-Datenbank), über die per ANN (Approximate Nearest Neighbor) die ähnlichsten Chunks zu einer Anfrage gefunden werden. Anwendungen: Enterprise-Suche, interne Wissensdatenbanken, KI-Suche (Perplexity-artig), Dokumentenextraktion und Intelligente Dokumentenverarbeitung (IDP) — also OCR (Optical Character Recognition), Klassifikation und Extraktion strukturierter Daten aus Rechnungen, Verträgen und Formularen.

Reifegrad (Einschätzung): RAG skaliert breit und ist produktiv in Unternehmensumgebungen, aber Qualität und Verlässlichkeit variieren stark je nach Implementierung, Chunk-Strategie und Modellwahl. IDP ist bereits ein etabliertes Marktsegment mit eigenen Anbietern (laut Grand View Research 2024 rund 2,3 Mrd. USD Marktvolumen).

Stand der Dinge / Dynamik

Beim nächsten Review hier aktualisieren — das ist der lebende Teil der Seite.

• RAG als Standard-Pattern: RAG ist das dominante Muster für Enterprise-KI-Anwendungen — ermöglicht dem LLM Zugriff auf proprietäre Daten ohne erneutes Training/Finetuning. Der Markt für Vektor-Datenbanken (das technische Rückgrat) wird von MarketsandMarkets für 2025 auf rund 2,65 Mrd. USD und für 2030 auf 8,95 Mrd. USD geschätzt (CAGR ca. 27,5 % — Sekundärquelle/Prognose).
• Vektor-Datenbanken: Wachsendes Ökosystem spezialisierter Anbieter (u. a. Pinecone (kein Dossier), Weaviate (kein Dossier), Qdrant (kein Dossier), Milvus (kein Dossier), pgvector als PostgreSQL-Erweiterung) neben nativen Vektor-Funktionen in bestehenden Datenbanken. Belege u. a. Pinecone-Doku und Qdrant-Capacity-Planning.
• Hybride Suche + Reranking: Trend zu Kombination aus Vektorsuche und lexikalischer Suche (BM25, klassisches Wort-Ranking) plus LLM-basiertem Reranking für bessere Ergebnisqualität. (Sekundärinfo, zu belegen.)
• „Lange Kontexte vs. RAG": Debatte, ob sehr lange Kontextfenster (1 Mio.+ Tokens) RAG ersetzen — gegenläufige Kräfte: Kontextkosten vs. Retrieval-Präzision. (Sekundärinfo/Einschätzung, zu belegen.)
• IDP-Adoption: IDP automatisiert Dokument-Workflows in Branchen mit hohem Dokumentaufkommen (Versicherung, Finanzen, Recht). Marktvolumen laut Grand View Research 2024 rund 2,3 Mrd. USD, Prognose bis 2030 ca. 12,35 Mrd. USD (CAGR ca. 33,1 % — Sekundärquelle/Prognose).

Markt- und Prognosezahlen sind Sekundärquellen (Marktforschung); technische RAM-/Speicher-Zahlen sind primär (Anbieter-Doku, Benchmark) bzw. nach Anbieter-Formel berechnet — siehe Abschnitt Kennzahlen. Aussagen ohne Link bleiben Einschätzungen und werden vor Verwendung in der These gehärtet.

Treiber-Mechanik → Hardware

Warum RAG & Dokumentenverarbeitung primär DRAM und Storage zieht:

RAM-Bedarf eines In-Memory-Vektor-Index je 1 Mio. Vektoren nach Embedding-Dimension

Zeitraum: 2026 · Einheit: GB DRAM je 1 Mio. Vektoren · inkl. Overhead-Faktor 1,5 (HNSW-Graph + Metadaten) nach Qdrant-Capacity-Planning-Formel N × dim × 4 Byte × 1,5. Berechnete Werte (eigene Anwendung der Anbieter-Formel).

Quelle: Qdrant — Capacity Planning (Formel und 1,5-Overhead); Plausibilisierung der Rohvektor-Größe (N × dim × 4 Byte) über Pinecone — Pod-Sizing (1 Mio. × 768 Dim. ≈ 3 GB roh). Rohdaten: assets/data/rag-vektor-index-ram.csv. 768 Dim. = OpenAI/typisch kleine Modelle, 1536 = text-embedding-3-small, 3072 = text-embedding-3-large (OpenAI).

In-Memory (DRAM) vs. On-Disk (NAND): RAM-Bedarf für 1 Mio. Vektoren (Qdrant-Benchmark)

Zeitraum: Qdrant-Benchmark · Einheit: MB RAM für 1 Mio. Vektoren · reported. Der Trade-off entscheidet, ob die Last auf DRAM oder NAND fällt.

Quelle: Qdrant — Minimal RAM to serve a million vectors. Lesart: Die On-Disk-Variante senkt den DRAM-Bedarf um ~90 % (1200 → 135 MB), kostet aber massiv Durchsatz (780 → 0,33 Anfragen/s) und macht lokale SSD/NAND statt Netzwerk-Storage kritisch (ca. 10x Durchsatz). Genau diese Architekturwahl verschiebt die Last zwischen DRAM und NAND. Rohdaten: assets/data/rag-inmemory-vs-disk.csv.

Kennzahlen

Quantitative Anker. Spalte „Art" trennt reported (Anbieter-Benchmark) von berechnet (eigene Anwendung der Anbieter-Formel) und Sekundärquelle/Prognose (Marktforschung).

Rohdaten in assets/data/rag-vektor-index-ram.csv, rag-inmemory-vs-disk.csv, rag-markt.csv — mit dieser Tabelle synchron halten. Marktprognosen sind Sekundärquellen (alternative Schätzungen anderer Häuser weichen ab) und keine harten Zahlen.

Edge vs. Datacenter

Überwiegend Datacenter: Enterprise-RAG läuft auf Cloud-Diensten oder on-premises Servern — Vektorindizes und Dokumentkorpora sind zu groß für Edge-Deployment. Ein kleiner Anteil (lokale Assistenten, On-Device-Suche) existiert, ist aber für die Hardware-These vernachlässigbar. Dieser Use Case zählt daher praktisch vollständig für Datacenter-DRAM und -Storage.

Bedeutung für die Speicher-/Storage-These

Beobachten / offene Fragen

• Entwicklung der „lange Kontexte vs. RAG"-Debatte — ob sehr große Kontextfenster Retrieval teilweise ersetzen und damit den DRAM-Treiber abschwächen.
• In-Memory- vs. On-Disk-Vektorindizes: Verlagerung zu Disk-basierten ANN-Indizes würde den DRAM-Bedarf senken, den Storage-Bedarf heben.
• Wachstum der Enterprise-Datenmengen (unstrukturierte Daten in der Cloud) als struktureller Kapazitätstreiber.
• IDP-Adoption in regulierten Branchen und die damit verbundene Datenspeicherpflicht.

Quellen & Update-Log

Primärquellen (Anbieter-Doku, Benchmark) vor Sekundärquellen (Marktforschung). Technische RAM-Werte sind nach Anbieter-Formel berechnet bzw. reported; Marktgrößen sind Sekundär-Prognosen.

Update-Log