Baue eine KI, die auf deinen eigenen Dokumenten antwortet – Schritt für Schritt erklärt.
Wie du mit Retrieval Augmented Generation (RAG) eine KI baust, die auf deinen eigenen Dokumenten antwortet – von der Theorie bis zur ersten funktionierenden Pipeline.
Stell dir vor, du hast 500 interne Dokumente – Handbücher, Policies, Meeting-Protokolle – und willst, dass eine KI Fragen dazu beantwortet. Du könntest alles in den Prompt packen, aber selbst große Kontextfenster (100.000+ Token) reichen für viele Dokumentensammlungen nicht aus. 500 Dokumente à 10 Seiten? Das sind locker 2 Millionen Token. Zu teuer, zu langsam, zu unzuverlässig.
Die Alternative: RAG – Retrieval Augmented Generation. Statt alles in den Prompt zu laden, suchst du erst die relevanten Passagen heraus und gibst dem LLM nur diese. Das Ergebnis: präzisere Antworten, niedrigere Kosten, und das System bleibt aktuell ohne Retraining.
RAG ist heute die Standardarchitektur für dokumentenbasierte KI-Anwendungen – von internen Wissensdatenbanken über Kundenservice-Bots bis zu Code-Assistenten.
Dokumente → [1. Chunking] → [2. Embedding] → [3. Vektordatenbank]
↓
Nutzerfrage → [2. Embedding] → [4. Retrieval] → relevante Chunks
↓
[5. Generation] → AntwortBevor Dokumente in eine Vektordatenbank kommen, müssen sie in kleinere Einheiten aufgeteilt werden. Die Chunk-Größe ist einer der wichtigsten Parameter:
| Chunk-Größe | Vorteil | Nachteil | Geeignet für |
|---|---|---|---|
| Klein (128–256 Token) | Präzises Retrieval | Verliert Kontext | FAQs, kurze Fakten |
| Mittel (512 Token) | Gute Balance | – | Technische Docs, Artikel |
| Groß (1024+ Token) | Viel Kontext | Rauschen im Retrieval | Narrative Texte, Bücher |
Overlap ist entscheidend: Ein Overlap von 10–20% stellt sicher, dass Informationen an Chunk-Grenzen nicht verloren gehen.
Token vs. Zeichen: Viele Splitter messen standardmäßig in Zeichen, nicht in Token.
chunk_size=512bedeutet dann 512 Zeichen ≈ 100–150 Token – viel kleiner als erwartet. Für token-genaues Chunkingtiktokenalslength_functionübergeben.
from langchain.text_splitter import RecursiveCharacterTextSplitter
import tiktoken
enc = tiktoken.encoding_for_model("gpt-5")
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=50,
length_function=lambda t: len(enc.encode(t)), # Token, nicht Zeichen
separators=["\n\n", "\n", ". ", " "]
)
chunks = splitter.split_documents(documents)PDF-Ingestion: Clean-up zuerst
PDFs sind der häufigste Schmerzpunkt. Vor dem Chunking bereinigen:
re.sub(r'(\w+)-\n(\w+)', r'\1\2', text))Fortgeschrittene Strategien:
Jeder Chunk wird durch ein Embedding-Modell in einen Vektor umgewandelt – eine Liste von Zahlen, die die semantische Bedeutung repräsentiert.
from openai import OpenAI
client = OpenAI()
def embed(text: str) -> list[float]:
response = client.embeddings.create(
model="text-embedding-3-small", # 1536 Dimensionen, günstig
input=text
)
return response.data[0].embeddingModell-Vergleich:
| Modell | Dimensionen | Kosten | Qualität |
|---|---|---|---|
text-embedding-3-small | 1536 | $0.02/1M Token | ★★★★☆ |
text-embedding-3-large | 3072 | $0.13/1M Token | ★★★★★ |
nomic-embed-text (lokal) | 768 | kostenlos | ★★★★☆ |
bge-m3 (lokal, multilingual) | 1024 | kostenlos | ★★★★★ |
Für deutsche Dokumente: bge-m3 oder multilingual-e5-large sind oft besser als OpenAI-Modelle.
Die Vektordatenbank speichert Chunks + ihre Embeddings und ermöglicht schnelle Ähnlichkeitssuche.
import chromadb
client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection("meine_docs")
# Chunks einpflegen
collection.add(
documents=[chunk.page_content for chunk in chunks],
embeddings=[embed(chunk.page_content) for chunk in chunks],
metadatas=[chunk.metadata for chunk in chunks],
ids=[f"chunk_{i}" for i in range(len(chunks))]
)Bei einer Nutzerfrage wird die Frage ebenfalls eingebettet und die ähnlichsten Chunks gesucht.
Reine Vektorsuche findet semantisch ähnliche Chunks, versagt aber bei exakten Begriffen (Produktnummern, Namen).
Hybrid Search kombiniert Vektorsuche mit BM25 (klassische Keyword-Suche). In den meisten Produktionsszenarien schlägt sie reine Vektorsuche – besonders bei exakten Begriffen wie Produktnummern, Gesetzesparagraphen oder Namen. Bei sehr homogener, sauber strukturierter Dokumentation (z.B. internes Wiki mit einheitlicher Terminologie) kann pure Dense Search ausreichen.
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
# Vektorsuche
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
# BM25 Keyword-Suche
bm25_retriever = BM25Retriever.from_documents(chunks)
bm25_retriever.k = 5
# Hybrid: 60% Vektor, 40% BM25
ensemble = EnsembleRetriever(
retrievers=[vector_retriever, bm25_retriever],
weights=[0.6, 0.4]
)Reranking als zweiter Schritt ist in der Praxis oft der größte Hebel nach solidem Chunking – in vielen Setups bringt es spürbar bessere Antworten bei wenig Mehrkosten:
from langchain.retrievers import ContextualCompressionRetriever
from langchain_cohere import CohereRerank
compressor = CohereRerank(model="rerank-multilingual-v3.0", top_n=3)
reranking_retriever = ContextualCompressionRetriever(
base_compressor=compressor,
base_retriever=ensemble
)Die gefundenen Chunks werden in den Prompt eingebettet und das LLM generiert die Antwort. Wichtig: Kontext und Regeln sauber trennen.
from openai import OpenAI
def rag_answer(question: str, chunks: list[dict]) -> str:
# Chunks mit IDs für Quellen-Zitation
context_blocks = []
for i, chunk in enumerate(chunks):
context_blocks.append(f"[Quelle {i+1}: {chunk['source']}]\n{chunk['text']}")
context = "\n\n---\n\n".join(context_blocks)
# Context Budget: max. ~2000 Token Kontext, nicht einfach k erhöhen
# Lieber weniger, dafür hochwertige Chunks (nach Reranking)
response = client.chat.completions.create(
model="gpt-5-mini",
messages=[
{
"role": "system",
"content": "Du bist ein hilfreicher Assistent. Antworte präzise und sachlich."
" Wenn der Kontext widersprüchlich ist, weise darauf hin."
},
{
"role": "user", # Kontext als eigene Message, nicht im System-Prompt
"content": f"""KONTEXT:
{context}
FRAGE: {question}
Regeln:
- Antworte ausschließlich basierend auf dem Kontext oben.
- Gib pro Aussage die Quellen-ID an (z.B. [Quelle 1]).
- Wenn die Antwort nicht im Kontext steht, sage: "Diese Information liegt mir nicht vor."""""
}
]
)
return response.choices[0].message.contentContext Budget statt k erhöhen: Erhöhe nicht einfach
kbis das Modell verwirrt ist. Budgetiere stattdessen den Kontext (z.B. max. 1500–3000 Token) und nimm die bestbewerteten Passagen nach dem Reranking. Qualität schlägt Quantität.
Nach solidem Chunking und Retrieval ist Query Transformation der nächste große Hebel:
from langchain.retrievers.multi_query import MultiQueryRetriever
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-5-mini", temperature=0)
multi_retriever = MultiQueryRetriever.from_llm(
retriever=vectorstore.as_retriever(),
llm=llm
)
# Generiert automatisch mehrere Frage-Varianten und merged die ErgebnisseDiagnose: Teste Retrieval isoliert – stelle Fragen und prüfe manuell ob die zurückgegebenen Chunks relevant sind.
Ursachen und Lösungen:
k erhöhen (z.B. von 3 auf 8)Diagnose: Faithfulness-Score mit RAGAS messen.
Lösungen:
Ursache: Chunks enthalten zu wenig spezifische Information.
Lösung: Metadaten in Chunks einbetten (Dokumentname, Datum, Abschnitt) und im Prompt referenzieren lassen.
Ohne Evaluation weißt du nicht ob dein RAG gut ist. RAGAS ist der Standard:
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision
# Testdatensatz: Fragen + erwartete Antworten + abgerufene Chunks
dataset = {
"question": ["Was ist die Rückgabefrist?", ...],
"answer": [rag_answer(q) for q in questions],
"contexts": [retrieve_chunks(q) for q in questions],
"ground_truth": ["30 Tage ab Kaufdatum", ...]
}
results = evaluate(
dataset,
metrics=[faithfulness, answer_relevancy, context_precision]
)
print(results)
# faithfulness: 0.87 ← Antwortet das LLM nur mit Kontext-Infos?
# answer_relevancy: 0.79 ← Beantwortet die Antwort die Frage?
# context_precision: 0.82 ← Sind die abgerufenen Chunks relevant?Zielwerte als Orientierung (team- und datensatzabhängig):
Wichtig: Absolute Zielwerte sind weniger entscheidend als ein stabiler Eval-Workflow. Baue ein “Golden Set” von 20–50 repräsentativen Fragen mit erwarteten Antworten und führe Regression-Tests bei jeder Änderung durch. Shadow Evaluation im Monitoring (Produktionsfragen automatisch bewerten) zeigt Qualitätsprobleme früh.
Ein funktionierender Prototyp ist ein guter Anfang – aber Produktion stellt andere Anforderungen:
Baue einen FAQ-Bot für eine PDF-Dokumentation
Nimm eine beliebige PDF-Dokumentation (z.B. ein Produkthandbuch oder eine Firmen-Policy) und baue damit eine RAG-Pipeline, die Fragen dazu beantworten kann.
Für dokumentenbasierte Fragen ist RAG fast immer besser: günstiger, aktualisierbar, nachvollziehbar. Fine-Tuning lohnt sich wenn du den Stil, die Tonalität oder domänenspezifisches Verhalten ändern willst – nicht für Faktenwissen.
Faustregel: 256–512 Token mit 10–20% Overlap. Für technische Dokumentation eher kleiner (256), für narrative Texte eher größer (512–1024). Wichtiger als die Größe: semantische Kohärenz – ein Chunk sollte eine abgeschlossene Idee enthalten.
Für Prototypen: Chroma (lokal, einfach). Für Produktion mit <1M Vektoren: Qdrant oder Weaviate. Für Enterprise mit Millionen Vektoren: Pinecone oder pgvector in PostgreSQL. Wenn du schon PostgreSQL nutzt: pgvector ist oft die einfachste Wahl.
Mit RAGAS: Faithfulness (Antwortet das LLM nur mit dem was im Kontext steht?), Answer Relevancy (Beantwortet die Antwort die Frage?), Context Precision (Sind die abgerufenen Chunks relevant?). Ziel: Faithfulness > 0.8, Answer Relevancy > 0.7.
Erst prüfen: Retrieval-Problem oder Generation-Problem? Wenn die richtigen Chunks gefunden werden aber die Antwort falsch ist → System-Prompt verschärfen ('Antworte nur basierend auf dem Kontext'). Wenn die falschen Chunks gefunden werden → Chunking und Embedding verbessern.