Fine-Tuning vs RAG: Wanneer Gebruik Je Wat?

Het debat rond fine-tuning vs RAG wordt vaak vervuild door partijdige standpunten van leveranciers en verkeerd begrepen afwegingen. Als je LLM-applicaties in productie bouwt, kun je het je niet veroorloven om deze architectonische beslissing verkeerd te nemen. Het kiezen van het verkeerde pad betekent verspilde GPU-cycli, verouderde gegevens en systemen die vatbaar zijn voor hallucinaties.

Dit artikel rekent af met de theoretische ruis. We onderzoeken het exacte probleemgebied, bekijken de architectuur van zowel Retrieval-Augmented Generation (RAG) als model-fine-tuning, en geven je een concreet kader voor wanneer je wat gebruikt.

Het Probleem

Large Language Models (LLM's) zijn bevroren in de tijd. Een model dat in 2024 is getraind, weet niets over de propriëtaire codebase die je team gisteren heeft geschreven, en begrijpt evenmin de real-time updates van het API-schema die een uur geleden zijn doorgevoerd. Wanneer je een basismodel vraagt om te redeneren over interne documenten of private bedrijfsgegevens, zal het ofwel vol zelfvertrouwen hallucineren of weigeren te antwoorden.

Je hebt domeinspecifieke gegevens. Je hebt de LLM nodig om deze te gebruiken. Dat is het fundamentele probleem.

Waarom Het Moeilijk Is

Het overbruggen van de kloof tussen statische LLM-gewichten en dynamische, private gegevens brengt aanzienlijke technische uitdagingen met zich mee. Je kunt niet zomaar een PDF van 50MB in een prompt context window proppen-zelfs met modellen die context windows van 1M+ tokens ondersteunen, hebben lange contexten last van het "lost in the middle"-fenomeen, enorme latentie en exorbitante tokenkosten.

Als je besluit de gewichten van het model bij te werken, betreed je de chaotische wereld van gedistribueerde training, het cureren van datasets en catastrofaal vergeten (catastrophic forgetting). Trainingspijplijnen breken, gegevensformaten vereisen agressieve standaardisatie en het evalueren of een gefine-tuned model daadwerkelijk is verbeterd vereist kostbare, handmatige evaluatiekaders.

Architectuur: RAG vs Fine-Tuning

Retrieval-Augmented Generation (RAG)

RAG laat de gewichten van de LLM ongemoeid. In plaats daarvan wijzigt het de prompt dynamisch op het moment van inference. Je converteert je propriëtaire gegevens naar hoogdimensionale vectoren, slaat ze op in een vector-database en voert semantische gelijkeniszoekopdrachten uit wanneer er een query binnenkomt. De opgehaalde documenten worden vervolgens in de context van de prompt geïnjecteerd.

RAG is een probleem van data-retrieval dat zich voordoet als een AI-probleem. De architectuur ziet er meestal als volgt uit:

1. Data-ingestie pijplijn (tekst extraheren uit PDF's, Confluence, etc.)
2. Chunking-strategie (tekst opsplitsen in blokken van 512-1024 tokens)
3. Embedding-model (bijv. text-embedding-3-small)
4. Vector-store (bijv. Pinecone, Qdrant, pgvector)
5. Generatiemodel (bijv. GPT-4, Claude 3 Opus)

Fine-Tuning

Fine-tuning wijzigt de gewichten van het neurale netwerk permanent. Je neemt een vooraf getraind model (zoals Llama-3-8B) en traint het verder op een gecureerde dataset van prompt-completion paren. Dit bakt de kennis of het gedrag rechtstreeks in de modelparameters.

Architectuur voor Fine-Tuning (specifiek LoRA/QLoRA):

1. Datasetvoorbereiding (JSONL-formaat van instructies en reacties)
2. Selectie van het basismodel
3. PEFT-adapters (Parameter-Efficient Fine-Tuning)
4. Gedistribueerd trainingscluster
5. Evaluatieloops
6. Inference-server met samengevoegde adapters

Fine-Tuning vs RAG: De Praktische Verdeling

Gebruik RAG wanneer het model feiten moet weten. Gebruik fine-tuning wanneer het model een formaat, toon of gedrag moet leren.

Fine-tune een model niet om het HR-beleid van je bedrijf uit het hoofd te leren. Het zal details vergeten, getallen hallucineren en een volledige hertraining vereisen wanneer het beleid wijzigt. Gebruik hiervoor RAG.

Gebruik geen RAG om een model te leren hoe het zeer specifieke, complexe, propriëtaire JSON-schema's moet retourneren of code moet schrijven in een diep op maat gemaakte interne DSL. Het context window zal overlopen met few-shot voorbeelden, en de latentie zal je applicatie de das omdoen. Fine-tune hiervoor.

Implementatie

Het Bouwen van de RAG-pijplijn

Voor RAG gebruiken we Python 3.11, LlamaIndex 0.10.x en 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. Initialize Vector Store
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. Load Documents
documents = SimpleDirectoryReader("./data").load_data()

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

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

Het Bouwen van de Fine-Tuning-pijplijn

Voor fine-tuning gebruiken we Unsloth 2024.4 voor 2x snellere training en minder VRAM-gebruik.

# 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. Load Base Model and LoRA Adapters
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. Prepare Dataset
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. Train
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()

Valkuilen

RAG-valkuilen

1. Blind Chunking: Het lukraak afsnijden van tekst om de 512 tokens splitst zinnen in tweeën en vernietigt de semantische betekenis. Je moet semantische chunking of recursieve karakter-splitsing gebruiken.
2. Metadata Negeren: Semantisch zoeken is van nature contextblind. Als je zoekt op "Q3 omzet", kan de embedding een document uit 2021 ophalen omdat het er wiskundig vergelijkbaar uitziet. Filter altijd op metadata (datum, auteur, categorie) voordat je de vectorzoekopdracht uitvoert.
3. Lost in the Middle: Het invoeren van 20 opgehaalde documenten in het context window resulteert er vaak in dat de LLM de middelste documenten negeert. Re-rank je opgehaalde documenten (met tools zoals Cohere Rerank) om de meest relevante items helemaal aan het begin en het einde van het context window te plaatsen.

Fine-Tuning-valkuilen

1. Garbage In, Garbage Out: Fine-tuning versterkt de kwaliteit van je dataset. Als je trainingsdata opmaakfouten, hallucinaties of tegenstrijdigheden bevat, zal je gefine-tunede model die exacte fouten agressief reproduceren.
2. Overfitting: Te veel epochs trainen op een kleine dataset vernietigt het algemene redeneervermogen van het model. Het leert de trainingsdata letterlijk te reproduceren, maar faalt spectaculair bij nieuwe invoer.
3. Catastrophic Forgetting: Terwijl het model je specifieke taak leert, zal het onvermijdelijk andere informatie vergeten. Een model dat intensief is gefine-tuned op het schrijven van SQL-queries kan plotseling heel slecht worden in het schrijven van Python of het samenvatten van tekst.

Resultaat

Stop met het behandelen van fine-tuning vs RAG als een of/of-beslissing. Ze lossen verschillende problemen op.

RAG biedt externe context. Fine-tuning zorgt voor intern gedrag.

Als je applicatie redeneren over dynamische, private kennisbronnen vereist, bouw dan een robuuste RAG-pijplijn. Als je applicatie vereist dat het model consistent complexe structuren uitvoert, spreekt in een specifieke merkidentiteit, of efficiënt draait op kleinere, goedkopere open-source modellen, dan moet je fine-tunen.

De meest geavanceerde enterprise-architecturen gebruiken beide. Ze fine-tunen een klein, goedkoop model (zoals Llama 3 8B) om hun specifieke JSON-outputschema en gebruikersintenties perfect te begrijpen, en koppelen dat gefine-tunede model vervolgens aan een omvangrijke RAG-pijplijn om de daadwerkelijke feiten op te halen die nodig zijn om dat schema te vullen.

Maak de architectonische keuze op basis van je datasnelheid en outputvereisten, niet op basis van de waan van de dag. Bouw doelgericht, evalueer onophoudelijk en begrijp de werking van je stack.