RAG-Architekturen im Vergleich: Von Basic RAG bis Advanced Patterns

Was ist RAG und warum ist es wichtig?

Retrieval-Augmented Generation (RAG) kombiniert die Stärken von Large Language Models mit externem Wissen. Statt sich nur auf das während des Trainings gelernte Wissen zu verlassen, kann ein RAG-System aktuelle, unternehmensspezifische Informationen abrufen und in die Antworten einbeziehen.

Bei innFactory setzen wir RAG-Systeme für verschiedene Anwendungsfälle ein - von intelligenten Dokumenten-Chatbots bis hin zu Wissensmanagement-Systemen für Unternehmen.

RAG-Architekturen im Überblick

1. Basic RAG (Naive RAG)

Die einfachste Form besteht aus drei Schritten:

1. Indexierung: Dokumente werden in Chunks aufgeteilt und als Vektoren gespeichert
2. Retrieval: Bei einer Anfrage werden die ähnlichsten Chunks gefunden
3. Generation: Die gefundenen Chunks werden dem LLM als Kontext übergeben

Query → Embedding → Vector Search → Top-K Chunks → LLM → Antwort

Vorteile:

• Einfach zu implementieren
• Geringe Latenz
• Gut für homogene Dokumentensammlungen

Nachteile:

• Begrenzte Relevanz bei komplexen Anfragen
• Keine semantische Gewichtung
• Probleme mit Keyword-basierten Suchen

2. Hybrid Search RAG

Kombiniert Vektor-Suche mit klassischer Keyword-Suche (BM25):

Query → [Vector Search + BM25 Search] → Fusion → Top-K → LLM → Antwort

Bei innFactory nutzen wir häufig Reciprocal Rank Fusion (RRF), um die Ergebnisse beider Suchverfahren zu kombinieren. Dies funktioniert besonders gut bei:

• Technischer Dokumentation mit spezifischen Begriffen
• Mischung aus semantischen und exakten Suchanfragen
• Mehrsprachigen Dokumentensammlungen

Technologien: Elasticsearch, OpenSearch, Weaviate, Qdrant

3. Re-Ranking RAG

Fügt eine zusätzliche Bewertungsschicht hinzu:

Query → Retrieval (Top-100) → Re-Ranker Model → Top-K → LLM → Antwort

Der Re-Ranker (z.B. Cohere Rerank, BGE-Reranker) bewertet die Relevanz jedes Chunks zur Anfrage genauer als die initiale Vektor-Suche.

Wann sinnvoll?

• Große Dokumentensammlungen (>10.000 Dokumente)
• Hohe Anforderungen an Antwortqualität
• Bereitschaft, höhere Latenz zu akzeptieren

4. Multi-Query RAG

Das LLM generiert mehrere Varianten der ursprünglichen Anfrage:

User Query → LLM (Query Expansion) → [Query 1, Query 2, Query 3]
→ Parallel Retrieval → Deduplizierung → LLM → Antwort

Dies erhöht die Wahrscheinlichkeit, relevante Dokumente zu finden, besonders bei:

• Ambiguen Anfragen
• Fachspezifischem Vokabular
• Unterschiedlichen Formulierungen in den Dokumenten

5. Agentic RAG

Die fortschrittlichste Architektur: Ein KI-Agent entscheidet dynamisch über die Suchstrategie:

Query → Agent → [Entscheidung: Welche Tools/Datenquellen?]
      → Iterative Suche → Bewertung → Ggf. weitere Suche → Antwort

Der Agent kann:

• Zwischen verschiedenen Datenquellen wählen
• Suchanfragen iterativ verfeinern
• Ergebnisse validieren und bei Bedarf erneut suchen
• Komplexe Anfragen in Teilschritte zerlegen

Technologien: LangChain Agents, LlamaIndex Agents, AutoGPT-Patterns

Architektur-Entscheidungsmatrix

Unsere Empfehlung

Für die meisten Unternehmens-Anwendungen empfehlen wir bei innFactory einen stufenweisen Ansatz:

1. Start mit Hybrid Search RAG - Gute Balance aus Qualität und Komplexität
2. Re-Ranking hinzufügen, wenn die Qualität nicht ausreicht
3. Agentic Patterns nur für komplexe Multi-Source-Szenarien

Fazit

Die Wahl der RAG-Architektur hängt stark vom Use Case ab. Es gibt keine “beste” Architektur - nur die passende für Ihre Anforderungen. Bei innFactory analysieren wir Ihre Datenquellen und Anforderungen, um die optimale Architektur zu identifizieren.

Sie planen ein RAG-Projekt? Kontaktieren Sie uns für ein unverbindliches Erstgespräch.