Ihr KI-Chatbot beantwortet Kundenfragen selbstbewusst, aber die Hälfte der Antworten ist falsch, weil das Modell Ihre interne Dokumentation nie gesehen hat. Kommt Ihnen das bekannt vor? Jedes Unternehmen, das mit großen Sprachmodellen experimentiert, stößt auf dieselbe Hürde: Standardmodelle kennen Ihr Geschäft nicht. Die Frage ist nicht, ob Sie das beheben sollten, sondern wie. Retrieval-Augmented Generation (RAG) und Fine-Tuning sind die beiden dominierenden Strategien, und die falsche Wahl kann Sie Monate an Entwicklungszeit und ein Budget kosten, das Sie nicht zurückbekommen.
Dieser Leitfaden erklärt, was jeder Ansatz technisch tatsächlich leistet, wann er die Nase vorn hat, was er realistisch kostet und wie Sie für Ihr konkretes Projekt die richtige Entscheidung treffen.
Wie RAG unter der Haube funktioniert
RAG verändert das Modell überhaupt nicht. Stattdessen gibt es dem Modell zur Abfragezeit Zugriff auf externes Wissen. Die Architektur besteht aus drei Phasen:
- Indexierung, Ihre Dokumente (PDFs, Wikis, Datenbanken, Confluence-Seiten) werden in Chunks aufgeteilt, in Vektor-Embeddings umgewandelt und in einer Vektordatenbank wie Pinecone, Weaviate oder pgvector gespeichert.
- Retrieval, Wenn ein Benutzer eine Frage stellt, wandelt das System die Abfrage in ein Embedding um, führt eine Ähnlichkeitssuche im Vektor-Store durch und ruft die relevantesten Chunks ab.
- Generierung, Die abgerufenen Chunks werden als Kontext in den Prompt des LLM eingefügt. Das Modell generiert eine Antwort, die auf Ihren tatsächlichen Daten basiert.
Hier ist eine minimale RAG-Pipeline in Python mit LangChain und OpenAI:
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.chains import RetrievalQA
from langchain_community.document_loaders import DirectoryLoader
# 1. Load and chunk documents
loader = DirectoryLoader("./company_docs/", glob="**/*.md")
documents = loader.load()
splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
chunks = splitter.split_documents(documents)
# 2. Create vector store
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./chroma_db")
# 3. Build retrieval chain
llm = ChatOpenAI(model="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
retriever=vectorstore.as_retriever(search_kwargs={"k": 5}),
return_source_documents=True
)
# 4. Query
result = qa_chain.invoke({"query": "What is our refund policy for enterprise clients?"})
print(result["result"])
for doc in result["source_documents"]:
print(f"Source: {doc.metadata['source']}")
Der entscheidende Vorteil: Sie können Ihre Wissensbasis sofort aktualisieren. Ändern Sie ein Richtliniendokument, indizieren Sie neu, und die nächste Abfrage spiegelt die neuen Informationen wider. Kein erneutes Training erforderlich.
Die entscheidende Einschränkung: Die Denkfähigkeit des Modells ändert sich nicht. Wenn Ihre Aufgabe erfordert, dass das Modell einen bestimmten Ton annimmt, ein komplexes internes Format einhält oder sich anders verhält (nicht nur mehr weiß), werden Sie mit RAG allein nicht ans Ziel kommen.
Wie Fine-Tuning ein Modell tatsächlich verändert
Fine-Tuning nimmt ein vortrainiertes Modell und trainiert es mit Ihren eigenen Daten weiter. Die Gewichte des Modells werden angepasst, sodass es Muster aus Ihrem Datensatz verinnerlicht, Ihre Terminologie, Ihren Schreibstil, Ihre Klassifikationslogik, Ihr domänenspezifisches Denken.
Mit der Fine-Tuning-API von OpenAI bereiten Sie eine JSONL-Datei mit Trainingsbeispielen vor:
{"messages": [{"role": "system", "content": "You are a support agent for Acme Corp. Always classify tickets into: billing, technical, feature-request, or account."}, {"role": "user", "content": "I was charged twice for my subscription last month"}, {"role": "assistant", "content": "Classification: billing\n\nI understand you were double-charged for your subscription. I'm escalating this to our billing team. You should see a refund within 3-5 business days. Reference: billing-duplicate-charge."}]}
{"messages": [{"role": "system", "content": "You are a support agent for Acme Corp. Always classify tickets into: billing, technical, feature-request, or account."}, {"role": "user", "content": "Can you add dark mode to the dashboard?"}, {"role": "assistant", "content": "Classification: feature-request\n\nGreat suggestion! I've logged dark mode for the dashboard as a feature request. Our product team reviews these monthly. You'll be notified if it's prioritized."}]}
Dann starten Sie das Training:
from openai import OpenAI
client = OpenAI()
# Upload training file
file = client.files.create(file=open("training_data.jsonl", "rb"), purpose="fine-tune")
# Start fine-tuning job
job = client.fine_tuning.jobs.create(
training_file=file.id,
model="gpt-4o-mini-2024-07-18",
hyperparameters={"n_epochs": 3}
)
print(f"Fine-tuning job started: {job.id}")
Nach Abschluss des Trainings (das je nach Datensatzgröße zwischen Minuten und Stunden dauern kann) erhalten Sie einen dedizierten Modell-Endpoint. Jeder Aufruf dieses Modells spiegelt nun die Muster Ihrer Trainingsdaten wider, ohne dass Sie Kontext in den Prompt packen müssen.
Was Ihnen Fine-Tuning bietet, was RAG nicht bietet:
- Konsistentes Ausgabeformat und Klassifikationsverhalten
- Domänenspezifische Denkmuster (z. B. medizinische Triage-Logik, Auslegung von Rechtsklauseln)
- Kleinere Prompts (keine Notwendigkeit, die Aufgabe bei jedem Aufruf neu zu erklären)
- Ein Modell, das „wie Ihr Unternehmen klingt"
Was Ihnen Fine-Tuning nicht bietet:
- Zugriff auf Wissen, das nicht in den Trainingsdaten enthalten war
- Einfache Aktualisierungen (jede Datenänderung bedeutet erneutes Training)
- Transparenz darüber, warum das Modell eine bestimmte Antwort gegeben hat (RAG kann Quellen angeben; ein feinabgestimmtes Modell kann nicht auf ein bestimmtes Dokument verweisen)
Entscheidungsrahmen: RAG vs. Fine-Tuning
Die richtige Wahl hängt davon ab, welches Problem Sie tatsächlich lösen. Hier ist ein Rahmen basierend auf der Kernaufgabe:
Wählen Sie RAG, wenn
- Ihr Wissen sich häufig ändert. Produktdokumentation, Preise, Richtlinien, interne Verfahren, alles, was wöchentlich oder monatlich aktualisiert wird. Mit RAG können Sie in Minuten neu indizieren; Fine-Tuning erfordert einen neuen Trainingslauf.
- Sie Quellenangaben benötigen. Wenn Benutzer oder Compliance-Teams überprüfen müssen, woher eine Antwort stammt, kann RAG das genaue Dokument und die Passage zurückgeben. Ein feinabgestimmtes Modell kann das nicht.
- Ihre Daten umfangreich und vielfältig sind. Wenn Sie Tausende von Dokumenten über Abteilungen hinweg haben, ist es unpraktisch, alles in Modellgewichte zu kodieren. RAG skaliert mit Ihrem Dokumenten-Store, nicht mit Ihrem GPU-Budget.
- Sie einen Wissensassistenten oder Q&A-Bot bauen. Das ist RAGs Kernkompetenz, das allgemeine Denkvermögen des Modells ist bereits gut genug; es braucht nur Zugriff auf die richtigen Informationen.
Wählen Sie Fine-Tuning, wenn
- Sie konsistentes Verhalten benötigen, nicht nur Wissen. Klassifikationsaufgaben, strukturierte Ausgabegenerierung, Einhaltung bestimmter Töne/Formate, das sind Verhaltensmuster, keine Fakten. Fine-Tuning verankert sie im Modell.
- Ihre Domäne eine spezialisierte Sprache hat. Medizinische, juristische, industrielle oder finanzielle Terminologie, die das Basismodell nur schlecht beherrscht. Fine-Tuning mit domänenspezifischen Beispielen lehrt das Modell, „Ihre Sprache zu sprechen".
- Sie die Kosten pro Abfrage minimieren müssen. Ein feinabgestimmtes kleineres Modell (wie GPT-4o-mini) kann ein größeres Basismodell bei Ihrer spezifischen Aufgabe erreichen oder übertreffen, zu einem Bruchteil der Token-Kosten. Das ist bei Skalierung entscheidend.
- Latenz kritisch ist. RAG fügt Retrieval-Zeit hinzu (typischerweise 200-500 ms für die Vektorsuche) plus den Overhead größerer Prompts. Ein feinabgestimmtes Modell mit kompaktem Prompt kann schneller antworten.
Ziehen Sie einen Hybrid-Ansatz in Betracht, wenn
Die meisten ausgereiften Enterprise-KI-Systeme kombinieren am Ende beides. Ein gängiges Muster:
- Fine-Tuning des Modells, um die Terminologie Ihrer Domäne zu verstehen, Ihr Ausgabeformat einzuhalten und Eingaben korrekt zu klassifizieren.
- RAG verwenden, um aktuelles, faktisches Wissen einzubringen, das sich im Laufe der Zeit ändert.
Das gibt Ihnen Verhaltenskonsistenz und aktuelles Wissen. Das feinabgestimmte Modell übernimmt das „Wie antworten", während RAG das „Was sagen" übernimmt.
Kostenaufschlüsselung: Was jeder Ansatz tatsächlich kostet
Schauen wir uns realistische Kostenspannen an. Diese basieren auf öffentlich verfügbaren Preisen und typischen Projektumfängen, Ihre tatsächlichen Kosten variieren je nach Datenvolumen, Abfrageverkehr und Infrastrukturentscheidungen.
RAG-Kostenkomponenten
Wichtigster Kostenhebel: Prompt-Caching und Kontextoptimierung können Ihre Token-Ausgaben drastisch reduzieren. Wir haben praktische Techniken dafür in unserem Leitfaden zum Senken der Produktions-RAG-Kosten um 80 % beschrieben.
Fine-Tuning-Kostenkomponenten
Die versteckten Kosten: Evaluierung
Beide Ansätze erfordern eine gründliche Evaluierung, aber die Art unterscheidet sich:
- RAG-Evaluierung konzentriert sich auf die Retrieval-Qualität (werden die richtigen Chunks abgerufen?) und die Treue (basiert die Antwort auf dem abgerufenen Kontext?). Sie messen dies mit Metriken wie recall@k und menschlich bewerteten Treue-Scores.
- Fine-Tuning-Evaluierung konzentriert sich auf Aufgaben-Genauigkeit und Verhaltenskonsistenz. Sie halten einen Testsatz zurück und messen, ob das feinabgestimmte Modell Ihre Qualitätsanforderungen erfüllt, bevor Sie es bereitstellen.
Die Evaluierung zu überspringen ist der teuerste Fehler im Enterprise-KI-Umfeld. Die Bereitstellung eines Modells, das selbstbewusst halluziniert, untergräbt das Vertrauen der Benutzer schneller als gar keine KI. Das hängt mit einem breiteren Muster zusammen, das wir beobachtet haben: Die meisten Enterprise-KI-Initiativen scheitern an der Orchestrierungskluft, gerade weil sie die Evaluierungs- und Iterationsphase überspringen.
Praxisbeispiel: Aufbau eines Unternehmens-Wissensassistenten
Gehen wir ein konkretes Szenario durch. Ein mittelständisches Fertigungsunternehmen (200 Mitarbeiter) möchte einen internen KI-Assistenten, der Fragen zu HR-Richtlinien, IT-Verfahren und Produktspezifikationen beantwortet. Die Wissensbasis umfasst etwa 150 Dokumente mit insgesamt rund 500 Seiten.
Ansatz A: Nur RAG
Setup:
- Die 150 Dokumente in ~2.000 Chunks aufteilen (je 1.000 Token mit 200-Token-Überlappung)
- Embeddings in einer verwalteten Vektordatenbank speichern
- GPT-4o für die Generierung mit Top-5-Retrieval verwenden
Laufende Kosten (monatlich, bei ~500 Abfragen/Tag):
- Vektordatenbank-Hosting: ~70 $ (Einstiegstarif)
- Embedding-Neu-Indexierung: vernachlässigbar (nur bei Dokumentänderungen)
- LLM-Inferenz: ~500 Abfragen × 30 Tage × ~3.000 Eingabe-Token pro Abfrage (Kontext + Frage) = ~45 M Token/Monat. Bei GPT-4os 2,50 $/1 M Eingabe-Token sind das grob 112 $/Monat allein für Eingaben, plus Ausgabe-Token.
Stärken für dieses Szenario: Wissen wird sofort aktualisiert, wenn HR eine Richtlinie ändert. Benutzer können sehen, aus welchem Dokument die Antwort stammt. Das Setup ist schnell, ein funktionierender Prototyp in unter zwei Wochen.
Schwächen: Das Modell liefert manchmal inkonsistente Formatierungen. Wenn mehrere Dokumente überlappende Informationen enthalten, kann das Retrieval widersprüchliche Chunks abrufen, was zu verwirrenden Antworten führt.
Ansatz B: Fine-Tuning
Setup:
- 500+ Beispiel-Q&A-Paare aus den 150 Dokumenten erstellen
- GPT-4o-mini mit diesen Beispielen feinabstimmen
- Den feinabgestimmten Modell-Endpoint bereitstellen
Laufende Kosten:
- Training: einmalige Kosten basierend auf der Datensatzgröße
- Inferenz: GPT-4o-mini ist pro Token deutlich günstiger als GPT-4o
- Retraining: erforderlich, wenn sich Dokumente wesentlich ändern
Stärken für dieses Szenario: Konsistentes Antwortformat bei jeder Abfrage. Niedrigere Inferenzkosten pro Abfrage. Schnellere Antworten (kein Retrieval-Schritt).
Schwächen: Wenn sich eine Richtlinie ändert, müssen Sie die Trainingsdaten aktualisieren und neu trainieren. Das Modell kann keine bestimmten Dokumente zitieren. Wenn ein Benutzer nach etwas fragt, das in den Trainingsdaten nicht gut repräsentiert ist, kann das Modell selbstbewusst halluzinieren.
Ansatz C: Hybrid (für dieses Szenario empfohlen)
Stimmen Sie GPT-4o-mini fein ab, um Antwortformatierung und Domänenterminologie zu übernehmen, und legen Sie dann RAG für den faktischen Abruf darüber. Das feinabgestimmte Modell lernt, „Basierend auf dem HR-Richtlinienhandbuch, Abschnitt 4.2..." zu sagen, während RAG den tatsächlichen Inhalt von Abschnitt 4.2 liefert.
Dieser Ansatz bietet Ihnen konsistentes Verhalten, Quellenangaben und einfache Wissensaktualisierungen, das Beste aus beiden Welten.
5 Best Practices für Ihre RAG-vs.-Fine-Tuning-Entscheidung
1. Beginnen Sie mit RAG, es sei denn, Sie haben ein klares Verhaltensproblem. RAG ist schneller einzurichten, einfacher zu iterieren und erfordert keine Kuratierung von Trainingsdaten. Wenn Ihr Kernproblem ist, dass „das Modell unser Wissen nicht kennt", löst RAG das. Wechseln Sie erst dann zu Fine-Tuning, wenn Sie bestätigt haben, dass das Problem verhaltensbezogen (Formatierung, Klassifikation, Ton) und nicht informationsbezogen ist.
2. Investieren Sie stark in Ihre Chunking-Strategie. Die Qualität Ihres RAG-Systems steht und fällt damit, wie Sie Dokumente aufteilen. Naives Chunking mit fester Größe (z. B. alle 500 Zeichen) zerstört Kontext. Verwenden Sie semantisches Chunking, respektieren Sie die Dokumentstruktur (Überschriften, Absätze, Tabellen) und testen Sie die Retrieval-Qualität mit echten Benutzerabfragen, bevor Sie etwas anderes optimieren.
3. Bauen Sie einen Evaluierungsdatensatz auf, bevor Sie etwas anderes bauen. Sammeln Sie 50-100 echte Fragen, die Ihre Benutzer stellen würden, zusammen mit den richtigen Antworten und Quelldokumenten. Das wird Ihr Benchmark für jede Iteration, ob Sie Retrieval-Parameter abstimmen, Prompts anpassen oder ein feinabgestimmtes Modell evaluieren.
4. Überwachen Sie Token-Kosten von Tag eins an. RAG-Prompts können schnell aufblähen, wenn Sie 5 große Chunks in jede Abfrage einfügen. Verfolgen Sie Ihre durchschnittlichen Token pro Abfrage und richten Sie Budget-Warnungen ein. Techniken wie SAPs dreistufiges Token-Kostenmodell bieten einen nützlichen Rahmen, um KI-Ausgaben bei der Skalierung planbar zu halten.
5. Führen Sie kein Fine-Tuning auf Daten durch, die Sie abrufen können. Wenn sich Informationen ändern oder wachsen, gehören sie in Ihren Vektor-Store, nicht in die Modellgewichte. Reservieren Sie Fine-Tuning für stabile Verhaltensmuster: wie klassifiziert wird, wie formatiert wird, wie über Ihre Domäne gedacht wird. Diese Trennung macht Ihr System langfristig wartbar.
Wann Sie einen Partner hinzuziehen sollten
Wenn Ihr Team über fundierte ML-Erfahrung und Kapazitäten verfügt, sind beide Ansätze intern umsetzbar. Aber die meisten Unternehmen unterschätzen zwei Dinge: den Engineering-Aufwand, um die RAG-Retrieval-Qualität richtig hinzubekommen (es ist nie „einfach LangChain einstecken"), und den Datenkuratierungsaufwand für Fine-Tuning (saubere, repräsentative Trainingsdaten sind 80 % der Arbeit).
Teams, die das nicht von Grund auf neu aufbauen möchten, holen sich oft einen KI-Lösungspartner ins Boot, der solche Systeme bereits ausgeliefert hat. Bei ProjectMakers haben wir RAG-Pipelines, feinabgestimmte Modelle und Hybrid-Architekturen für Kunden aus verschiedenen Branchen gebaut, und der größte Wert, den wir einbringen, ist nicht der Code, sondern das Wissen, welcher Ansatz zu Ihren spezifischen Rahmenbedingungen passt, bevor Sie drei Monate in die falsche Richtung investieren.
Das Fazit
RAG und Fine-Tuning sind keine Konkurrenten, sie sind Werkzeuge für unterschiedliche Probleme. RAG gibt Ihrer KI Zugriff auf Ihr Wissen. Fine-Tuning gibt Ihrer KI Ihr Verhalten. Die meisten Produktionssysteme profitieren von beidem, bewusst eingesetzt für die Teile des Problems, die jeder Ansatz am besten löst.
Beginnen Sie mit RAG. Messen Sie, wo es an Grenzen stößt. Fügen Sie Fine-Tuning nur dort hinzu, wo Verhalten, nicht Wissen, der Engpass ist. Und was auch immer Sie tun: Bauen Sie zuerst Ihren Evaluierungsdatensatz auf, er ist der Kompass, der das gesamte Projekt auf Kurs hält.
Bereit herauszufinden, welcher Ansatz zu Ihrem Anwendungsfall passt? Entdecken Sie, wie wir KI-Integrationsprojekte angehen.
Quelle: RAG oder KI-Finetuning?