Daniel Reyes, YuSMP Group
Daniel Reyes Principal Engineer (AI/ML), YuSMP Group · LLM-Systeme, RAG und Fine-Tuning für den Produktivbetrieb

Die Antwort in zwei Zeilen

Wenn sich Ihr Wissen schneller als einmal pro Quartal ändert, nutzen Sie RAG. Wenn Sie ein bestimmtes Ausgabeformat, Latenz unter 200 ms oder domänenspezifische Argumentation benötigen, die das Basismodell nicht zuverlässig erzeugen kann, fine-tunen Sie. Ernsthafte Produkte nutzen beides: ein fine-getuntes kleines offenes Modell als Argumentations-Engine, mit RAG, das frische, zitierfähige Fakten liefert. Das ist die langweilige, richtige Antwort im Jahr 2026 und die, die wir in 9 von 10 Fällen für Kunden unserer RAG-as-a-Service-Practice ausliefern.

Der Entscheidungsrahmen 2026

Die Debatte zwischen RAG und Fine-Tuning wurde durch ein Jahr Marketing vernebelt. Long-Context-Modelle (Claude 4.6 Sonnet mit 1M Tokens, Gemini 2.5 Pro mit 2M) führten dazu, dass manche Teams behaupteten, „RAG ist tot". Es ist es nicht und wird es nicht sein. Langer Kontext verschiebt die Grenze; er löscht sie nicht aus. Der Rahmen, den wir zur Entscheidung nutzen:

  1. Wie aktuell muss die Antwort sein? Wenn sich Fakten zwischen den Trainings-Cuts und der Inferenz ändern, können Sie sie nicht hinein-fine-tunen. RAG oder Tool-Nutzung ist die einzige ehrliche Antwort.
  2. Wie groß ist der Korpus? Unter ~50.000 Tokens stabilen Wissens ist In-Context-Prompting in Ordnung. Darüber beginnt sich RAG auszuzahlen.
  3. Wie spezifisch ist die Ausgabe? Wenn Sie striktes JSON, eine eigene DSL, einen Ton oder Domänen-Argumentationsketten benötigen, lohnt sich Fine-Tuning.
  4. Wie sehen Ihre Unit Economics aus? Unter 5 Mio. Tokens/Tag gewinnen gehostete geschlossene Modelle. Über 50 Mio. Tokens/Tag bei einer stabilen Last ist ein fine-getuntes 8–13B-Modell auf Ihrer eigenen GPU dramatisch günstiger.
  5. Welche Latenz benötigen Sie? Ein selbst gehostetes fine-getuntes 8B-Modell auf einer H200 läuft mit 80–120 Tokens/s für einen einzelnen Nutzer bei einer First-Token-Latenz unter 150 ms. Claude 4.6 Sonnet über API liegt bei 600–900 ms First-Token aus der EU.

RAG: Was es 2026 tatsächlich ist und warum es weiterhin dominiert

Retrieval-Augmented Generation ist 2026 nicht mehr die naive „Embed, suchen, in den Prompt stopfen"-Pipeline von 2023. Ein Produktiv-RAG-System hat 2026 mindestens sechs Komponenten, hinter jeder steckt eine echte Engineering-Entscheidung:

KomponenteStandards 2026Warum es wichtig ist
Ingestion / ChunkingLlamaIndex- / Unstructured- / Haystack-Pipelines, semantisches Chunking bei 400–800 Tokens90 % der RAG-Fehler sind Chunking-Fehler
EmbeddingsVoyage-3, OpenAI text-embedding-3-large, BGE-M3 (offen)Voyage-3 führt das MTEB-Leaderboard an; BGE-M3 ist die beste offene Option
VektorspeicherQdrant, Weaviate, pgvector, Pinecone serverlessUnter 100M Vektoren ist pgvector auf dem Postgres, das Sie ohnehin betreiben, schwer zu schlagen
Hybrid-RetrievalBM25 + Dense + Metadaten-Filter, per RRF fusioniertReines Dense-Retrieval verliert bei Enterprise-Korpora weiterhin gegen Hybrid
Re-RankingCohere Rerank 3, BGE-reranker-v2, Voyage Rerank-2Fügt 50–80 ms hinzu, steigert aber die Top-3-Präzision um 15–30 Prozentpunkte
GenerierungClaude 4.6 Sonnet, GPT-4o, Gemini 2.5 Pro oder ein selbst gehostetes Fine-TuneNach Latenz und Kosten auswählen, nicht nach „bestem Benchmark"

Was sich in den letzten 18 Monaten geändert hat: strukturiertes Retrieval. Reine semantische Suche über Chunks verliert gegen mehrstufige Pipelines, die BM25, Dense-Retrieval, Metadaten-Filter und einen Re-Ranker kombinieren. Wir sehen, wie Precision@5 auf demselben Korpus von 0,62 (naives Dense) auf 0,88 (Hybrid + Rerank) springt, und das übersetzt sich direkt in weniger halluzinierte Antworten weiter unten in der Pipeline.

Fine-Tuning: Was es 2026 tatsächlich bedeutet

Fine-Tuning teilt sich 2026 sauber in zwei Lager:

  • Closed-Model-Adapter-Tuning. OpenAI bietet Fine-Tuning für GPT-4o und o3-mini an; Google bietet Tuning für Gemini 2.5 Flash an; Anthropic bietet für AWS-Bedrock-Kunden Fine-Tuning von Claude 4.6 Haiku an. Sie laden ein JSONL mit Beispielen hoch, zahlen pro Trainings-Token und nutzen es über dieselbe API.
  • Open-Weight-Fine-Tuning. LoRA oder QLoRA auf Llama 4 (8B, 70B, 405B), Mistral Large 3, Mixtral 8×22B, Qwen 3 oder DeepSeek V3. Sie besitzen die Gewichte, Sie kontrollieren die Inferenz, und die Stückkosten sinken im großen Maßstab dramatisch.

Worin Fine-Tuning gut ist: Format, Stil, Domänen-Vokabular und Argumentationsketten, die das Basismodell gesehen, aber nicht zuverlässig reproduzieren kann. Llama 4 8B, fine-getunt auf 30.000 Beispiele Ihres Medical-Coding-Workflows, schlägt Claude 4.6 Sonnet Zero-Shot bei diesem Workflow — und läuft dabei zu 3 % der Kosten.

Worin Fine-Tuning schlecht ist: das Beibringen neuer Fakten. Trotz einem Jahrzehnt voller Paper bleibt das parametrische Einfügen von Wissen per Fine-Tuning unzuverlässig. Modelle merken sich manche Fakten, generalisieren andere schlecht und konfabulieren an den Rändern. Wenn Sie fine-tunen, um dem Modell Ihren Produktkatalog „beizubringen", verbringen Sie drei Monate damit, Edge-Cases hinterherzujagen, die eine RAG-Pipeline in einer Woche löst.

Benchmarks, die beim Vergleich zählen

Öffentliche Benchmarks sind zu einem schlechten Stellvertreter für die Produktivleistung geworden, aber einige helfen noch beim Vergleich von Basismodellen, die Sie fine-tunen wollen:

  • MMLU und MMLU-Pro: allgemeine Wissensbreite. Claude 4.6 Opus und GPT-4o liegen beide über 90; Llama 4 70B um die 84; Mistral Large 3 um die 82.
  • GPQA Diamond: Argumentation auf Graduierten-Niveau. o3 führt mit ~88; Claude 4.6 Opus ~85; Gemini 2.5 Pro ~83.
  • SWE-bench Verified: reale Softwareentwicklung. Claude 4.6 Sonnet führt mit ~72 %; o3 ~70 %; Gemini 2.5 Pro ~65 %.
  • HumanEval+, LiveCodeBench: Programmieren unter Kontaminationskontrolle.
  • Ihr eigenes Eval-Set. Immer. Kein öffentlicher Benchmark sagt die Leistung auf Ihren Daten voraus.

Kosten: echte Zahlen für 2026

Hier ist, was wir im Mai 2026 tatsächlich zahlen, pro 1M Tokens, für die gängigsten Produktivmodelle:

ModellInput / 1MOutput / 1MKontext
Claude 4.6 Opus$15$751M
Claude 4.6 Sonnet$3$151M
Claude 4.6 Haiku$0.80$4200k
GPT-4o$2.50$10128k
o3$10$40200k
Gemini 2.5 Pro$1.25$52M
Gemini 2.5 Flash$0.15$0.601M
Llama 4 70B (selbst gehostet, 8×H200)~$0.40~$0.60128k
Llama 4 8B fine-getunt (1×H200)~$0.10~$0.15128k
DeepSeek V3 (API)$0.27$1.10128k

Fine-Tuning-Kosten 2026, was wir tatsächlich zahlen:

  • Llama 4 8B LoRA auf 50.000 Beispiele: 200–600 $ pro Durchlauf auf einer gemieteten H200 (8–24 Stunden zu 3–5 $/Stunde).
  • Llama 4 70B LoRA auf 50.000 Beispiele: 1.500–4.000 $ auf 4×H200 über 18–36 Stunden.
  • Llama 4 70B vollständiges Fine-Tune: 4.000–12.000 $ auf 8×H200.
  • GPT-4o-Fine-Tuning: ~25 $/1M Trainings-Tokens über die OpenAI-API.
  • Gemini-2.5-Flash-Tuning: ~8–12 $/1M Trainings-Tokens.

Rechnen Sie 30–50 % für den Aufbau des Eval-Sets und 2–3 Iterationen bis zur Konvergenz hinzu.

Das Hybrid-Muster, das die meisten Produktiv-Stacks nutzen

Für mittlere bis große Enterprise-Deployments ist unsere Standardarchitektur:

  1. Generator: ein LoRA-getuntes Llama 4 8B oder ein Mistral-7B-Derivat, trainiert auf 20–80k Beispiele der Domänen-Argumentation und des Ausgabeformats des Kunden. Auf einer einzelnen H200 gehostet oder für den Durchsatz mit vLLM aufgeteilt.
  2. Retriever: Hybrid aus pgvector + BM25, mit Metadaten-Filtern und Cohere Rerank 3.
  3. Router: ein winziger Claude-4.6-Haiku-Aufruf entscheidet, ob aus dem vorherigen Kontext geantwortet, Retrieval angestoßen oder zu einem stärkeren Modell eskaliert wird.
  4. Eskalation: Claude 4.6 Sonnet oder o3 für die 5–10 % der Queries, die tiefere Argumentation benötigen.
  5. Klebeschicht: DSPy für die Prompt-Optimierung, MCP-Server für saubere Tool-Grenzen, Anthropic SDK für den Eskalations-Client.

Das landet typischerweise bei 0,30–0,80 $ pro 1.000 Nutzerinteraktionen all-in, gegenüber 1,50–4,00 $ für eine reine Claude-4.6-Sonnet-Pipeline, die dieselbe Arbeit erledigt — und gibt Ihnen ein Modell, das Sie tatsächlich besitzen.

Referenz-Stack, den wir ausliefern

  • Ingestion: LlamaIndex + Unstructured (PDFs, DOCX, Folien, gescannte Formulare), Haystack für die Pipeline-Orchestrierung, wenn die Graph-Verarbeitung aufwendig ist.
  • Vektor-DB: pgvector (unter 100M Vektoren), Qdrant (über 100M oder Multi-Tenant), Weaviate, wo Graph + Vektor wichtig ist.
  • Embeddings: Voyage-3 (geschlossen, MTEB-Spitzenreiter) oder BGE-M3 (offen).
  • Re-Ranker: Cohere Rerank 3 (API) oder BGE-reranker-v2-m3 (selbst gehostet).
  • Prompt- + Programm-Schicht: DSPy für optimierbare Programme; LangChain weiterhin akzeptabel, aber zunehmend abgelöst.
  • Agenten-Surface: MCP-Server stellen Retrieval, Tools und Datenquellen sauber für einen oder viele LLM-Clients bereit.
  • Eval: Ragas, TruLens plus unser eigenes zurückgehaltenes Gold-Set pro Kunde.
  • Observability: Langfuse, Helicone, Datadog LLM Observability.

Wenn Sie einen Referenz-Build möchten, sehen Sie sich unsere GenAI-Integration-Leistung und die parallele Seite KI/ML & Data Engineering an.

Fünf teure Fehler

  1. Fine-Tuning, um Fakten „beizubringen". Das funktioniert nicht zuverlässig. Nutzen Sie RAG.
  2. Die Evaluierung überspringen. Wenn Sie die Korrektheit auf einem zurückgehaltenen Set nicht messen können, können Sie sich nicht verbessern. Bauen Sie das Eval vor dem Modell.
  3. Direkt zu einem Frontier-Modell greifen, wenn Sie Durchsatz brauchen. Claude 4.6 Opus auf einer internen Last mit hohem Volumen verbrennt Geld, das Sie für Entwickler ausgeben könnten. Beginnen Sie mit Haiku oder Gemini Flash und eskalieren Sie nur, wenn die Genauigkeit es verlangt.
  4. Naives Chunking. Chunks fester Größe zerschneiden Tabellen und Code. Nutzen Sie semantisches + strukturelles Chunking. Testen Sie ab dem ersten Tag mit echten Dokumenten.
  5. Die EU-KI-Verordnung ignorieren. Wenn Sie in der EU deployen, unterliegen Ihre RAG- und Fine-Tuning-Pipelines ab August 2026 neuen Nachvollziehbarkeitspflichten. Wir behandeln das ausführlich unter EU-KI-Verordnung-Compliance.

FAQ

Ist RAG immer günstiger als Fine-Tuning?

Für sich änderndes Wissen ja. Über ~50M Tokens/Tag bei stabilen Lasten ist ein fine-getuntes offenes 8–13B-Modell pro Inferenz günstiger.

Macht langer Kontext RAG überflüssig?

Nein. 1M Tokens pro Anfrage hineinzustopfen kostet bei Claude 4.6 Sonnet etwa 3 $ und fügt 30–90 s Latenz hinzu. RAG hält Kosten und Latenz niedrig.

Wann gewinnt Fine-Tuning eindeutig?

Bei spezifischen Ausgabeformaten, Domänen-Argumentation, die das Basismodell nicht zuverlässig ausgeben kann, oder Latenz unter 200 ms bei hohem Durchsatz.

Was ist der Standard-Stack für 2026?

LlamaIndex + pgvector oder Qdrant + Cohere Rerank 3 + Claude 4.6 Sonnet, mit DSPy für die Prompt-Optimierung und MCP für Tool-Grenzen.

Wie viel kostet ein Llama-4-Fine-Tune?

200–600 $ für ein 8B-LoRA auf 50k Beispiele; 4–12k $ für ein vollständiges 70B-Fine-Tune auf 8×H200.

Lassen sich RAG und Fine-Tuning kombinieren?

Ja, und für ernsthafte Produkte ist es der Produktiv-Standard: fine-getunte Argumentation + abgerufene Fakten.

Zuletzt aktualisiert am 26. Mai 2026. Preise und Benchmarks entsprechen den Rate Cards der Anbieter und öffentlichen Leaderboards mit Stand Mai 2026.