Fine-Tuning vs. RAG: Wann man welches verwendet

Die Debatte um Fine-Tuning vs. RAG (Retrieval-Augmented Generation) wird oft durch die Voreingenommenheit von Anbietern und missverstandene Kompromisse verzerrt. Wenn Sie LLM-Anwendungen für die Produktion entwickeln, können Sie es sich nicht leisten, diese architektonische Entscheidung falsch zu treffen. Der falsche Weg bedeutet verschwendete GPU-Zyklen, veraltete Daten und halluzinationsanfällige Systeme.

Dieser Beitrag räumt mit dem theoretischen Rauschen auf. Wir werden den genauen Problemraum untersuchen, die Architektur von RAG und Modell-Fine-Tuning analysieren und Ihnen einen klaren Entscheidungsrahmen an die Hand geben, wann Sie welchen Ansatz wählen sollten.

Das Problem

Large Language Models (LLMs) sind in der Zeit eingefroren. Ein im Jahr 2024 trainiertes Modell weiß nichts über die proprietäre Codebasis, die Ihr Team gestern geschrieben hat, und versteht auch nicht die vor einer Stunde veröffentlichten Echtzeit-API-Schema-Updates. Wenn Sie ein Basismodell bitten, über interne Dokumente oder private Unternehmensdaten nachzudenken, wird es entweder selbstbewusst halluzinieren oder die Antwort verweigern.

Sie verfügen über domänenspezifische Daten. Sie müssen das LLM dazu bringen, diese zu nutzen. Das ist das grundlegende Problem.

Warum es schwierig ist

Die Lücke zwischen statischen LLM-Gewichten und dynamischen, privaten Daten zu schließen, bringt erhebliche technische Herausforderungen mit sich. Sie können nicht einfach eine 50 MB große PDF-Datei in ein Prompt-Kontextfenster laden - selbst bei Modellen, die Kontextfenster von über 1 Million Token unterstützen, leiden lange Kontexte unter dem Phänomen „Lost in the Middle“, massiver Latenz und exorbitanten Token-Kosten.

Wenn Sie sich entscheiden, die Gewichte des Modells anzupassen (Fine-Tuning), betreten Sie den chaotischen Bereich des verteilten Trainings, der Datensatz-Kuration und des katastrophalen Vergessens (Catastrophic Forgetting). Trainings-Pipelines brechen ab, Datenformate erfordern eine aggressive Standardisierung und die Beurteilung, ob sich ein feinabgestimmtes Modell tatsächlich verbessert hat, erfordert teure, manuelle Evaluierungs-Frameworks.

Architektur: RAG vs. Fine-Tuning

Retrieval-Augmented Generation (RAG)

RAG lässt die Gewichte des LLMs unberührt. Stattdessen ändert es den Prompt dynamisch zur Inferenzzeit. Sie konvertieren Ihre proprietären Daten in hochdimensionale Vektoren, speichern diese in einer Vektordatenbank und führen eine semantische Ähnlichkeitssuche durch, sobald eine Abfrage eingeht. Die abgerufenen Dokumente werden dann in den Kontext des Prompts injiziert.

RAG ist ein Datenabruf-Problem, das sich als KI-Problem maskiert. Die Architektur sieht normalerweise so aus:

1. Datenaufnahme-Pipeline (Text aus PDFs, Confluence usw. extrahieren)
2. Chunking-Strategie (Text in Blöcke von 512-1024 Token aufteilen)
3. Einbettungsmodell (Embedding Model, z. B. text-embedding-3-small)
4. Vektorspeicher (Vector Store, z. B. Pinecone, Qdrant, pgvector)
5. Generierungsmodell (z. B. GPT-4, Claude 3 Opus)

Fine-Tuning

Fine-Tuning verändert die Gewichte des neuronalen Netzes dauerhaft. Sie nehmen ein vortrainiertes Modell (wie Llama-3-8B) und trainieren es auf einem kuratierten Datensatz von Prompt-Completion-Paaren weiter. Dadurch werden das Wissen oder das Verhalten direkt in die Modellparameter eingebrannt.

Architektur für das Fine-Tuning (speziell LoRA/QLoRA):

1. Datensatzvorbereitung (JSONL-Format von Anweisungen und Antworten)
2. Auswahl des Basismodells
3. PEFT-Adapter (Parameter-Efficient Fine-Tuning)
4. Verteiltes Trainings-Cluster
5. Evaluierungsschleifen
6. Inferenz-Server mit zusammengeführten Adaptern

Fine-Tuning vs. RAG: Die klare Gegenüberstellung

Verwenden Sie RAG, wenn das Modell Fakten kennen muss. Verwenden Sie Fine-Tuning, wenn das Modell ein Format, einen Tonfall oder ein Verhalten lernen soll.

Versuchen Sie nicht, ein Modell per Fine-Tuning auf die HR-Richtlinien Ihres Unternehmens abzurichten. Es wird Details vergessen, Zahlen halluzinieren und muss komplett neu trainiert werden, sobald sich die Richtlinie ändert. Verwenden Sie dafür RAG.

Verwenden Sie umgekehrt RAG nicht, um einem Modell beizubringen, wie es hochspezifische, komplexe, proprietäre JSON-Schemata ausgibt oder Code in einer stark angepassten internen DSL schreibt. Das Kontextfenster wird mit Few-Shot-Beispielen überlaufen und die Latenz wird Ihre Anwendung unbrauchbar machen. Nutzen Sie dafür Fine-Tuning.

Implementierung

Aufbau der RAG-Pipeline

Für RAG verwenden wir Python 3.11, LlamaIndex 0.10.x und Qdrant.

# requirements.txt
# llama-index==0.10.15
# llama-index-vector-stores-qdrant==0.1.2
# qdrant-client==1.7.3

import qdrant_client
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext
from llama_index.vector_stores.qdrant import QdrantVectorStore

# 1. Vektorspeicher initialisieren
client = qdrant_client.QdrantClient(location=":memory:")
vector_store = QdrantVectorStore(client=client, collection_name="internal_docs")
storage_context = StorageContext.from_defaults(vector_store=vector_store)

# 2. Dokumente laden
documents = SimpleDirectoryReader("./data").load_data()

# 3. Index erstellen
index = VectorStoreIndex.from_documents(
    documents,
    storage_context=storage_context,
)

# 4. Abfrage
query_engine = index.as_query_engine()
response = query_engine.query("What is the new API rate limit?")
print(response)

Aufbau der Fine-Tuning-Pipeline

Für das Fine-Tuning verwenden wir Unsloth 2024.4 für 2-mal schnelleres Training und geringeren VRAM-Bedarf.

# requirements.txt
# unsloth[cu121-ampere] @ git+https://github.com/unslothai/unsloth.git
# trl==0.8.1

from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments
from datasets import load_dataset

# 1. Basismodell und LoRA-Adapter laden
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/llama-3-8b-bnb-4bit",
    max_seq_length = 2048,
    load_in_4bit = True,
)

model = FastLanguageModel.get_peft_model(
    model,
    r = 16,
    target_modules = ["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_alpha = 16,
    lora_dropout = 0, 
    bias = "none",
    use_gradient_checkpointing = "unsloth",
)

# 2. Datensatz vorbereiten
dataset = load_dataset("json", data_files="internal_dsl_dataset.jsonl", split="train")

def format_prompts(examples):
    instructions = examples["instruction"]
    outputs      = examples["output"]
    texts = []
    for instruction, output in zip(instructions, outputs):
        text = f"Instruction: {instruction}\nOutput: {output}<|end_of_text|>"
        texts.append(text)
    return { "text" : texts }

dataset = dataset.map(format_prompts, batched = True)

# 3. Trainieren
trainer = SFTTrainer(
    model = model,
    tokenizer = tokenizer,
    train_dataset = dataset,
    dataset_text_field = "text",
    max_seq_length = 2048,
    args = TrainingArguments(
        per_device_train_batch_size = 2,
        gradient_accumulation_steps = 4,
        max_steps = 60,
        learning_rate = 2e-4,
        fp16 = not torch.cuda.is_bf16_supported(),
        bf16 = torch.cuda.is_bf16_supported(),
        logging_steps = 1,
        output_dir = "outputs",
    ),
)

trainer.train()

Fallstricke

RAG-Fallstricke

1. Blindes Chunking: Das wahllose Schneiden von Text alle 512 Token zerschneidet Sätze in der Mitte und zerstört die semantische Bedeutung. Sie müssen semantisches Chunking oder rekursives Zeichen-Splitting verwenden.
2. Ignorieren von Metadaten: Die Vektorähnlichkeitssuche ist von Natur aus „dumm“. Wenn Sie nach „Q3-Umsatz“ suchen, ruft das Embedding möglicherweise ein Dokument aus dem Jahr 2021 ab, weil es mathematisch ähnlich aussieht. Filtern Sie immer nach Metadaten (Datum, Autor, Kategorie), bevor Sie die Vektorsuche durchführen.
3. Lost in the Middle: Das Einspeisen von 20 abgerufenen Dokumenten in das Kontextfenster führt oft dazu, dass das LLM die mittleren Dokumente ignoriert. Verwenden Sie Re-Ranking-Tools (wie Cohere Rerank), um die relevantesten Dokumente ganz am Anfang und am Ende des Kontextfensters zu platzieren.

Fine-Tuning-Fallstricke

1. Garbage In, Garbage Out: Fine-Tuning verstärkt die Qualität Ihres Datensatzes. Wenn Ihre Trainingsdaten Formatierungsfehler, Halluzinationen oder Widersprüche enthalten, wird Ihr feinabgestimmtes Modell genau diese Fehler fortlaufend produzieren.
2. Overfitting (Überanpassung): Zu langes Training auf einem kleinen Datensatz zerstört die allgemeinen Argumentationsfähigkeiten des Modells. Es lernt, die Trainingsdaten wortwörtlich aufzusagen, scheitert aber spektakulär bei neuen Eingaben.
3. Katastrophales Vergessen (Catastrophic Forgetting): Während das Modell Ihre spezifische Aufgabe lernt, vergisst es unweigerlich andere Informationen. Ein Modell, das stark auf das Schreiben von SQL-Abfragen feinabgestimmt wurde, kann plötzlich extrem schlecht darin werden, Python-Code zu schreiben oder Texte zusammenzufassen.

Ergebnis

Hören Sie auf, Fine-Tuning vs. RAG als Entweder-Oder-Entscheidung zu betrachten. Sie lösen unterschiedliche Probleme.

RAG liefert externen Kontext. Fine-Tuning sorgt für internes Verhalten.

Wenn Ihre Anwendung Argumentation über dynamische, private Wissensdatenbanken erfordert, bauen Sie eine robuste RAG-Pipeline. Wenn Ihre Anwendung erfordert, dass das Modell konsistent komplexe Strukturen ausgibt, in einer hochspezifischen Markenstimme spricht oder effizient auf kleineren, kostengünstigeren Open-Source-Modellen läuft, müssen Sie ein Fine-Tuning durchführen.

Die fortschrittlichsten Unternehmensarchitekturen nutzen beides. Sie stimmen ein kleines, günstiges Modell (wie Llama 3 8B) fein ab, damit es ihr spezifisches JSON-Ausgabeschema und die Absichten der Benutzer perfekt versteht. Anschließend verbinden sie dieses feinabgestimmte Modell mit einer großen RAG-Pipeline, um die tatsächlichen Fakten abzurufen, die zum Befüllen dieses Schemas erforderlich sind.

Treffen Sie die architektonische Entscheidung basierend auf der Geschwindigkeit Ihrer Datenänderungen und Ihren Ausgabeanforderungen, nicht basierend auf dem neuesten Twitter-Hype. Entwickeln Sie entschlossen, evaluieren Sie unnachgiebig und verstehen Sie die Kernmechanismen Ihres Stacks.