RAG und Wissensabruf

RAG (Retrieval-Augmented Generation) ist derzeit eine der gängigsten LLM-Bereitstellungsarchitekturen.

Die Kernidee von RAG ist:Beim Beantworten von Fragen das LLM zunächst relevanten Inhalt aus einer externen Wissensdatenbank abrufen lassen und dann eine Antwort basierend auf den Abrufergebnissen generieren, anstatt sich nur auf während des Modelltrainings gespeichertes Wissen zu verlassen.

Dies löst zwei zentrale Schmerzpunkte von LLMs: Wissensgrenze (das Modell kennt keine Ereignisse, die nach dem Training eingetreten sind) und Halluzination (das Modell erfindet Antworten, wenn es unsicher ist).

Grundprinzipien von RAG

Ein vollständiges RAG-System besteht aus zwei Pipelines:Offline-Indizierungspipeline(bereitet Dokumente vor und speichert sie in einer Vektordatenbank) undOnline-Abfragepipeline(empfängt Benutzerfragen, ruft ab und generiert).

In der Offline-Phase werden Rohdokumente in kleine Chunks aufgeteilt, über ein Embedding-Modell in Vektoren umgewandelt und in einer Vektordatenbank gespeichert.

In der Online-Phase wird auch die Benutzerfrage in einen Vektor umgewandelt, die ähnlichsten Dokument-Chunks werden aus der Datenbank gefunden, zu einem Kontext zusammengefügt und an das LLM übergeben, um eine Antwort zu generieren.

Die folgende Abbildung zeigt den vollständigen Anfrageablauf von RAG:

Basic RAG Flowchart RAG complete request flow: user questions are converted into query vectors via the Embedding model, similar document chunks are retrieved in the vector database, the question and retrieval results are concatenated into a Prompt, and input to the LLM to generate the final answer. User question Embedding Convert to query vector Vector database Similarity retrieval Top-K Prompt concatenation Question + document chunks LLM generation Answer based on retrieval results Offline indexing (one-time preprocessing) Original documents Chunking / cleaning Embedding Convert to document vectors Write Vector database Online query flow (every request goes through)

Datenvorverarbeitung und Dokumenten-Chunking

Vorausgesetzte Herausforderung: Komplexes Dokumenten-Parsing

Vor dem Chunking steht RAG oft vorFormatparsing-Herausforderungen. Besonders bei Tabellen, Bildern und mehrspaltigen Layouts in PDFs, Word-Dokumenten oder gescannten Dateien kann gewöhnliche Textextraktion leicht zu semantischer Verwirrung führen.

Der derzeitige Mainstream-Ansatz der Branche besteht darin,Dokumenten-Parsing-Engines(wie LlamaParse, Unstructured) oder multimodale Großmodelle einzuführen, komplexe Bilder und Text in strukturiertes Markdown umzuwandeln und so die Grundlage für nachfolgendes hochwertiges Chunking zu legen.

Dokumenten-Chunking-Strategien

Dokumenten-Chunking ist die Grundlage für die Wirksamkeit von RAG; die Chunk-Granularität beeinflusst direkt die Retrieval-Qualität. Zu große Chunks führen zu Rauschen, zu kleine Chunks verlieren den Kontext. Gängige Strategien sind wie folgt:

Chunking-Strategie Anwendbare Szenarien Vorteile Nachteile
Chunking mit fester Größe Allgemeiner Text Einfach zu implementieren, schnell Kann semantisch vollständige Sätze abschneiden
Rekursives Zeichen-Chunking Strukturierter Text (Markdown, Code) Bevorzugt das Aufteilen entlang semantischer Grenzen wie Absätzen und Sätzen Etwas komplexer zu implementieren; erfordert das Festlegen einer sinnvollen Liste von Trennzeichen
Semantisches Chunking Lange Dokumente, Bücher Verwendet Embedding, um die Ähnlichkeit zwischen benachbarten Sätzen zu berechnen und automatisch semantische Wendepunkte für das Chunking zu finden Hoher Rechenaufwand, langsame Vorverarbeitung
Eltern-Kind-Dokumentenabruf
(Small-to-Big)		 Szenarien mit umfassender Abdeckung Verwendet "kleine Chunks" für hochpräzise Vektorsuche und gibt bei einem Treffer den entsprechenden "großen Chunk" (das übergeordnete Dokument) an das LLM zurück, wodurch Retrieval-Präzision und Kontextvollständigkeit ausbalanciert werden. Die Kosten für Datenbankdesign und -wartung verdoppeln sich

In der Praxis ist es üblich, beim ChunkingOverlaphinzuzufügen, d. h., benachbarte Chunks teilen sich mehrere Zeichen, um zu verhindern, dass wichtige Informationen an den Grenzen abgeschnitten werden. Typische Konfiguration: Chunk-Größe 512 Tokens, Overlap 50~100 Tokens.

Beispiel: Rekursives Chunking mit LangChain

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,        # Maximale Anzahl von Tokens pro Chunk
    chunk_overlap=50,      # Anzahl überlappender Tokens zwischen benachbarten Chunks, um Informationsverlust an den Grenzen zu verhindern
    separators=["\n\n", "\n", "。", ".", " ", ""]  # Bevorzugt nach Absätzen und Sätzen aufteilen
)

chunks = splitter.split_text(document_text)
print(f"Aufgeteilt in {len(chunks)} Dokument-Chunks")

Vektorabruf

Embedding-Modelle

Embedding-Modelle wandeln Text in dichte Vektoren um (normalerweise 768- oder 1536-dimensionale Float-Arrays). Semantisch ähnliche Texte liegen im Vektorraum näher beieinander, was die mathematische Grundlage der Ähnlichkeitssuche ist.

Vergleich gängiger Embedding-Modelle:

Modell Dimensionen Unterstützte Sprachen Funktionen
text-embedding-3-small（OpenAI） 1536 Mehrsprachig Hohe Kosteneffizienz, geeignet für groß angelegte Indexierung
text-embedding-3-large（OpenAI） 3072 Mehrsprachig Höchste Genauigkeit, höhere Kosten
BAAI/bge-m3 1024 Chinesisch und Englisch Open Source, hervorragende chinesische Leistung, unterstützt mehrere Sprachen
sentence-transformers/all-MiniLM-L6-v2 384 Englisch Kleine Größe, hohe Geschwindigkeit, geeignet für extrem leichtgewichtige lokale Bereitstellung

Ähnlichkeitsberechnung und ANN-Algorithmen

Der Kern des Retrievals ist die Distanzmessung. Am häufigsten verwendet wirdKosinus-Ähnlichkeit, die den Kosinus des Winkels zwischen zwei Vektoren berechnet, mit einem Bereich von [-1, 1]; je näher an 1, desto ähnlicher. Darüber hinaus gibt es Skalarprodukt und Euklidische Distanz (L2-Distanz).

Um eine Retrieval auf Millisekundenebene unter Millionen von Vektoren zu erreichen, verwenden Datenbanken typischerweiseApproximate Nearest Neighbor (ANN)-Algorithmen(wieHNSW, IVF). HNSW ist derzeit der Mainstream-Algorithmus. Er baut ein mehrschichtiges Skip-Graph-Netzwerk auf und opfert sehr wenig Genauigkeit für eine Verbesserung der Suchgeschwindigkeit um eine Größenordnung.

Advanced RAG (Fortgeschrittene Architektur)

Die Basisarchitektur (Naive RAG) sieht sich oft mit Problemen wie ungenauem Retrieval und "Context Flooding" durch redundante Informationen konfrontiert. Advanced RAG begegnet diesen durchPre-Retrieval-Optimierung → Retrieval-Fusion → Post-Retrieval-Optimierungmithilfe einer dreistufigen Architektur zu lösen.

1. Pre-Retrieval: Query-Optimierung

Die ursprünglichen Fragen der Benutzer sind oft nicht präzise:

  • Query Rewriting: Verwenden Sie ein LLM, um umgangssprachliche Anfragen in standardisierte Retrieval-Begriffe umzuschreiben.
  • HyDE（Hypothetical Document Embedding）: Lassen Sie das LLM zunächst eine hypothetische Antwort "blind erraten". Da die generierte Antwort normalerweise mehr Branchen-Terminologie als die ursprüngliche Frage enthält, ruft die Verwendung des Vektors dieser hypothetischen Antwort für das Retrieval oft qualitativ hochwertigere Dokumente ab.

2. Hybride Suche

werdenVektor-Retrieval(versteht Semantik, hohe Fehlertoleranz) undKeyword-RetrievalDie Ergebnisse werden gewichtet fusioniert. Dies ist besonders wichtig bei Eigennamen, Produktmodellen und Code-Schnipseln, da herkömmliches Vektor-Retrieval bei bestimmten Eigennamen leicht "versagt".

3. Post-Retrieval-Optimierung: Reranking

Dies ist einCoarse Ranking → Fine Rankingzweistufiges Design. Obwohl Vektor-Retrieval schnell ist, ist seine Bewertung nicht präzise genug. Reranking führtCross-Encoder-Modell(wie `bge-reranker`) ein, das "Frage"- und "Dokument"-Paare in das Modell für gemeinsame Inferenz und Bewertung eingibt. Es ist rechenintensiv und nur dafür zuständig, die Top-20 auf Top-5 herunter auszuwählen.

Beispiel: Pseudocode für Reranking-Pipeline

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

# 1. Grobes Ranking: Vektorsuche ruft schnell Top-50 ab
candidates = vector_store.similarity_search(query, k=50)

# 2. Feines Ranking: [Frage, Dokument]-Paare für präzise Bewertung erstellen
pairs = [[query, doc.page_content] for doc in candidates]
scores = reranker.predict(pairs)

# 3. Die endgültigen Top-5 filtern, um sie an das LLM zu übergeben
ranked_docs = sorted(zip(scores, candidates), reverse=True)
final_docs = [doc for _, doc in ranked_docs[:5]]

4. Self-RAG und CRAG (Corrective RAG)

Ein Selbstreflexionsmechanismus wird hinzugefügt. Beispielsweise lässt CRAG (Corrective RAG) nach dem Abrufen der Abrufergebnisse zuerst das LLM als "Richter" fungieren, um sie zu bewerten. Wenn die lokale Wissensbasis kein passendes Dokument enthält oder die Qualität extrem niedrig ist, löst das System automatisch Web Search (z. B. Google API) als Ergänzung aus, wodurch Halluzinationen stark reduziert werden.

GraphRAG: Wissensgraph + Retrieval-Integration

Traditionelles RAG behandelt die Wissensbasis als unabhängige Textfragmente und kann Fragen wie "finde alle Unternehmen, die vom aktuellen CEO gegründet wurden und einen Marktwert von über 100 Milliarden haben" nicht beantworten, diedokumentübergreifendes, mehrstufiges Schlussfolgern erfordernkomplexe Probleme.GraphRAGFührt einen Wissensgraphen ein, um Entitäten und Beziehungen explizit zu modellieren.

GraphRAG architecture diagram GraphRAG fuses vector retrieval with the knowledge graph: the user question triggers both vector retrieval and graph retrieval, and the results of the two paths are fused and fed into the LLM to generate an answer. User question Vector retrieval Relevant document chunks Graph retrieval Entity-relationship subgraph Context fusion Document chunks + graph paths Entity A → Relationship → Entity B Entity B → Relationship → Entity C

GraphRAG-Kernschritte

  1. Wissenskonstruktion: In der Offline-Phase LLM verwenden, um Tripel (Subjekt, Beziehung, Objekt) aus Dokumenten zu extrahieren und sie in Graphdatenbanken wie Neo4j zu schreiben.
  2. Dual-Path-Retrieval: Für Entitäten in der Anfrage wird nicht nur traditionelle Vektorsuche durchgeführt, sondern auch eine Graphdurchquerung im Wissensgraphen ausgelöst, um mehrstufige Beziehungsketten zu extrahieren.
  3. Graph-Text-Fusionsgenerierung: Die durch Vektorsuche abgerufenen "Chunks" und die durch Graphsuche abgerufenen "Pfadstrukturen" in den Prompt einfügen, wodurch das LLM sowohl eine globale Sicht als auch spezifische Details erhält.

GraphRAG-Inhaltsreferenz:https://www.example.com/ai-agent/graphrag-usage.html

Empfehlungen zur Technologie- und Datenbankauswahl

Datenbank-/Tool-Auswahl Type Empfohlene Implementierungsszenarien
Pinecone / Zilliz Cloud Vollständig verwalteter Cloud-Dienst Sofort einsatzbereit, keine Infrastrukturwartung erforderlich. In Kombination mit Cohere Rerank + GPT-4o ist es die schnellste kommerzielle Lösung.
Qdrant Open Source + Managed In Rust geschrieben, exzellentes Speichermanagement, extrem hohe Leistung. Geeignet für private Bereitstellung auf Unternehmensebene.
Weaviate / Elasticsearch Open Source + Managed Verfügt über eine extrem ausgereifte BM25- + Vektor-Hybridsuche (Hybrid Search) und ist die erste Wahl für Szenarien mit vielen Eigennamen.
Milvus Open Source, verteilt Geeignet für unternehmensweite Retrieval-Plattformen in extrem großem Maßstab im Milliarden- bis Zehnmilliarden-Bereich.
Chroma / FAISS Lokale Bibliothek/Eingebettet Extrem leichtgewichtig, kein separater Dienst muss bereitgestellt werden. Sehr geeignet für lokale Entwicklung und Validierung persönlicher Wissensbasisprojekte.

RAG-Evaluierungsmetriken (RAGAS-Framework)

Die Bewertung eines RAG-Systems kann nicht allein auf Intuition beruhen; sie verwendet hauptsächlichRAGASein Framework für automatisierte quantitative Tests aus den beiden Dimensionen "Retrieval" und "Generierung":

  • Kontext-Recall: Welcher Anteil der Informationen in der Standardantwort kann abgerufen werden.
  • Kontext-Präzision: Welcher Anteil der abgerufenen Dokumente ist tatsächlich relevant.
  • Treue (Faithfulness/Halluzinations-Metrik): Ob die generierten Antworten alle durch die abgerufenen Dokumente gestützt werden.
  • Antwortrelevanz: Ob die generierte Antwort tatsächlich auf die Frage des Benutzers eingeht und irrelevante Antworten vermeidet.
Andere Erweiterungen