Eigenes Wissen ins KI-Modell: RAG, Fine-Tuning oder langes Kontextfenster?

Warum dein LLM deine Daten nicht kennt

Ein großes Sprachmodell wie Claude oder GPT ist auf riesigen Mengen öffentlicher Texte trainiert worden. Es kennt Wikipedia, Foren, Fachliteratur — aber es kennt nicht dein internes Wiki, deine Angebote von letzter Woche oder die Preisliste, die gestern aktualisiert wurde. Zwei Grenzen stoßen hier zusammen: Das Modell hat einen Wissensstichtag (den Zeitpunkt, an dem das Training endete) und es hat nie Zugriff auf nicht-öffentliche Daten gehabt.

Fragst du trotzdem nach internem Wissen, passiert das Gefährlichste, was ein LLM tun kann: Es rät. Solche Halluzinationen — plausibel klingende, aber falsche Antworten — sind kein seltener Fehler, sondern die Standardreaktion eines Modells, das eine Lücke füllen soll. Für ein Unternehmen ist eine selbstbewusst formulierte Falschauskunft schlimmer als ein ehrliches „Weiß ich nicht“.

Die eigentliche Frage lautet also: Wie bekommst du dein Wissen zuverlässig ins Modell? Dafür gibt es drei etablierte Wege — und sie schließen sich nicht aus.

Weg 1: Wissen direkt in den Prompt geben

Der einfachste Ansatz heißt In-Context Learning: Du packst die relevanten Informationen einfach mit in die Anfrage. Statt „Fasse unsere Rückgabebedingungen zusammen“ schickst du den kompletten Text der Bedingungen plus die Frage. Das Modell arbeitet nur mit dem, was im Kontextfenster steht — dem Arbeitsspeicher des Modells für eine einzelne Anfrage.

Moderne Modelle haben hier enorm aufgeholt. Die Kontextfenster reichen inzwischen von mehreren hunderttausend bis rund einer Million Token bei einigen Modellen (ein Token ist grob ein Wortteil; 1.000 Token entsprechen etwa 750 Wörtern). Damit passen ganze Handbücher oder Vertragssammlungen in eine einzige Anfrage.

Die Vorteile:

• Kein technischer Aufbau nötig — du brauchst keine zusätzliche Infrastruktur
• Das Modell sieht die Daten vollständig und im Zusammenhang
• Ideal für einmalige oder kleine Wissensmengen, etwa ein Dokument analysieren

Die Grenzen:

• Kosten: Du bezahlst jeden Token in jedem Request. Schickst du 100.000 Token Kontext bei jeder Anfrage mit, zahlst du diese 100.000 Token auch jedes Mal — bei tausenden Anfragen wird das teuer.
• Kontextlimit: Deine gesamte Wissensbasis ist irgendwann größer als jedes Fenster. Ein Konzern-Wiki mit zehntausenden Seiten passt nicht hinein.
• Lost in the Middle: Studien über mehrere Modellfamilien zeigen, dass die Trefferquote einbricht, wenn die entscheidende Information in der Mitte eines langen Kontexts steht. Die Genauigkeit ist am höchsten am Anfang und Ende, in der Mitte fällt sie messbar ab. Ein volles Fenster ist also nicht automatisch ein gut genutztes Fenster.

Prompt Caching als Ergänzung

Gegen das Kostenproblem hilft Prompt Caching. Wenn ein großer, gleichbleibender Textblock — etwa ein Handbuch — bei vielen Anfragen identisch am Anfang steht, speichert der Anbieter dessen berechneten Zustand zwischen und muss ihn nicht jedes Mal neu verarbeiten. Bei Anthropic sinken die Kosten für zwischengespeicherte Eingaben dadurch deutlich, typischerweise um rund 90 Prozent gegenüber der frischen Verarbeitung. Caching löst aber weder das Kontextlimit noch das Lost-in-the-Middle-Problem — es macht den In-Context-Weg nur bezahlbarer, solange die Wissensmenge ins Fenster passt.

Weg 2: RAG — nur das Relevante nachschlagen

Retrieval-Augmented Generation (RAG) dreht den Spieß um: Statt alles in den Prompt zu kippen, wird vor jeder Antwort automatisch nur der passende Ausschnitt aus deiner Wissensbasis herausgesucht und mitgegeben. Das Modell bekommt also nicht das ganze Handbuch, sondern die drei relevanten Absätze zur konkreten Frage.

So funktioniert RAG

Der Ablauf besteht aus zwei Phasen. Einmalig baust du eine durchsuchbare Wissensbasis auf:

• Chunking: Deine Dokumente werden in kleinere Häppchen (Chunks) zerlegt — etwa Absätze oder Sinnabschnitte.
• Embeddings: Jeder Chunk wird in einen Embedding-Vektor umgerechnet, eine lange Zahlenreihe, die die Bedeutung des Textes abbildet. Inhaltlich ähnliche Texte bekommen ähnliche Vektoren.
• Vektordatenbank: Diese Vektoren landen in einer Vektordatenbank, die blitzschnell nach Bedeutungsähnlichkeit suchen kann.

Bei jeder Anfrage läuft dann das Retrieval: Die Frage des Nutzers wird ebenfalls in einen Vektor umgerechnet, die Datenbank liefert die inhaltlich nächsten Chunks, und diese werden zusammen mit der Frage an das Modell gegeben. Das Modell antwortet also mit frisch nachgeschlagenem Kontext — inklusive der Möglichkeit, die Quelle mitzuliefern.

Wann RAG ideal ist

• Große Wissensbasis: Egal ob hundert oder hunderttausend Dokumente — es wird immer nur der relevante Ausschnitt geladen, nicht alles.
• Aktualität: Neue Informationen fügst du der Datenbank hinzu, ohne das Modell neu zu trainieren. Die Preisliste von heute ist morgen abrufbar.
• Quellenangaben: Weil jede Antwort auf konkreten Chunks basiert, kannst du sagen, aus welchem Dokument sie stammt — entscheidend für Nachvollziehbarkeit und Compliance.
• Kostenkontrolle: Du bezahlst pro Anfrage nur die wenigen tausend Token des Ausschnitts, nicht die gesamte Wissensbasis.

Die Tücken von RAG

RAG ist kein Selbstläufer. Die Qualität der Antworten steht und fällt mit dem Retrieval — findet die Datenbank die falschen Chunks, bekommt das Modell die falsche Grundlage und die Antwort ist trotzdem falsch. Drei Stellschrauben sind kritisch:

• Chunking-Strategie: Zu kleine Häppchen reißen Zusammenhänge auseinander, zu große verwässern die Suche. Die richtige Größe hängt vom Dokumenttyp ab.
• Retrieval-Qualität: Nicht jede gut klingende Frage findet die passenden Chunks. Rückt die Datenbank das Falsche heraus, hilft das beste Modell nichts.
• Datenpflege: Eine Wissensbasis veraltet. Werden Dokumente geändert oder gelöscht, müssen die Embeddings nachgezogen werden — sonst zitiert dein System veraltete Stände.

Weg 3: Fine-Tuning — das Modell weitertrainieren

Fine-Tuning geht anders vor: Statt Wissen zur Laufzeit mitzugeben, trainierst du das Modell mit vielen eigenen Beispielen weiter und veränderst dadurch seine Gewichte dauerhaft. Du zeigst ihm hunderte oder tausende Beispiel-Paare aus Eingabe und gewünschter Ausgabe, bis es das Muster verinnerlicht.

Wofür Fine-Tuning stark ist

• Stil und Ton: Das Modell soll konsequent in deiner Markensprache oder in einem festen Tonfall antworten.
• Format: Immer dasselbe Ausgabeschema, etwa ein bestimmtes JSON-Format oder eine feste Dokumentstruktur.
• Verhalten und Spezialaufgaben: Eine eng umrissene, wiederkehrende Aufgabe — etwa Support-Tickets klassifizieren — die das Modell nach dem Training zuverlässig und ohne lange Anweisungen erledigt.

Wofür Fine-Tuning nicht taugt

Der häufigste und teuerste Irrtum: Fine-Tuning als Wissensspeicher zu missbrauchen. Es ist kein zuverlässiger Weg, dem Modell neue Fakten einzupflanzen. Forschung zeigt, dass das Anlernen neuer Fakten per Fine-Tuning Halluzinationen sogar begünstigen kann und dass das Modell dabei bereits vorhandene Fähigkeiten verlernt — ein Effekt, der als katastrophales Vergessen (catastrophic forgetting) bekannt ist. Das Modell überschreibt beim Lernen neuer Muster ungewollt altes Können.

Dazu kommt das Aktualitätsproblem: Ein feingetuntes Modell ist ein Standbild vom Zeitpunkt des Trainings. Ändert sich dein Wissen, musst du erneut trainieren. Und Fine-Tuning ist aufwendig — es braucht sauber aufbereitete, qualitativ hochwertige Trainingsdaten in ausreichender Menge, Rechenzeit und Fachwissen. Merke: Fine-Tuning formt, wie das Modell antwortet — nicht, was es weiß.

Der direkte Vergleich: fünf Kriterien

Statt einer abstrakten Empfehlung hilft der Blick auf die Kriterien, die in der Praxis den Ausschlag geben:

• Aktualität: RAG gewinnt klar — neue Daten sind sofort verfügbar. Langer Kontext ist ebenfalls aktuell, aber nur für das, was du gerade mitschickst. Fine-Tuning ist am Trainingsstand eingefroren.
• Kosten: RAG hält die Kosten pro Anfrage niedrig. Langer Kontext wird bei großen, wiederkehrenden Wissensmengen teuer (Prompt Caching mildert das). Fine-Tuning hat hohe Einmalkosten fürs Training, danach günstige Anfragen.
• Aufwand: Langer Kontext ist am schnellsten startklar. RAG erfordert einen mittleren Aufbau (Chunking, Vektordatenbank, Pflege). Fine-Tuning ist am aufwendigsten (Datenaufbereitung, Training, Evaluierung).
• Quellen und Nachvollziehbarkeit: RAG kann Quellen mitliefern. Langer Kontext theoretisch auch, sofern die Dokumente drin stehen. Fine-Tuning kann es nicht — das Wissen ist in den Gewichten verschmiert.
• Verhalten und Stil: Hier ist Fine-Tuning das stärkste Werkzeug. RAG und langer Kontext beeinflussen den Stil nur über Anweisungen im Prompt.

In der Praxis: kombinieren statt entscheiden

Die drei Wege sind keine Entweder-oder-Entscheidung. Praxistaugliche Systeme kombinieren sie gezielt. Die häufigste und robusteste Kombination lautet: RAG für das Wissen, Fine-Tuning oder gutes Prompting für das Verhalten.

Ein Beispiel: Ein Support-Assistent soll immer im höflichen, knappen Ton deines Unternehmens antworten (Verhalten) und dabei stets die aktuellen Produktdaten nutzen (Wissen). Den Ton bringst du über sauberes Prompting oder — bei sehr hohem Volumen — über Fine-Tuning ein. Die Produktdaten kommen per RAG dazu, damit sie jederzeit aktuell und mit Quelle belegt sind. Fine-Tuning würde hier für den Wissensteil scheitern, RAG allein trifft den Ton nicht so konsistent. Zusammen ergeben sie ein System, das richtig und markengerecht antwortet.

Für viele Anwendungsfälle reicht sogar die einfachste Kombination: RAG plus gutes Prompting. Ein präziser Systemprompt regelt Ton und Regeln, RAG liefert das Wissen — ganz ohne den Aufwand eines eigenen Trainings.

Empfehlung für den Mittelstand

Wenn du im Mittelstand ein KI-Projekt startest, das internes Wissen nutzen soll, gilt eine klare Reihenfolge — vom Einfachen zum Aufwendigen:

• Erst Kontext testen: Ist die Wissensmenge klein oder der Anwendungsfall einmalig, gib die Daten direkt in den Prompt. So validierst du in Tagen, ob KI dein Problem überhaupt löst — ohne Infrastruktur.
• Dann RAG: Sobald die Wissensbasis größer wird, sich häufig ändert oder Quellenangaben nötig sind, ist RAG der Standardweg. Für die allermeisten Mittelstandsfälle — Wissensdatenbank, Support, interne Recherche — ist RAG die richtige Antwort.
• Fine-Tuning nur selten: Greif erst dazu, wenn ein sehr spezifisches Verhalten, ein festes Format oder ein hohes, gleichförmiges Anfragevolumen es rechtfertigt — und nie, um Wissen zu speichern.

Der teuerste Fehler ist, mit Fine-Tuning zu beginnen, weil es nach der „richtigen“ KI-Anpassung klingt. In neun von zehn Mittelstandsprojekten ist es unnötig — RAG oder schlicht ein gut gebauter Kontext lösen das Problem schneller, günstiger und transparenter.

Fazit

Einem LLM eigenes Wissen zu geben ist keine Frage des einen richtigen Werkzeugs, sondern der passenden Zuordnung. Langer Kontext ist der schnelle Einstieg für kleine oder einmalige Wissensmengen, mit Prompt Caching bezahlbar, aber durch Kosten und das Lost-in-the-Middle-Problem begrenzt. RAG ist das Arbeitspferd für große, sich ändernde Wissensbasen mit Quellenpflicht — und für den Mittelstand meist die richtige erste Wahl. Fine-Tuning formt Stil, Format und Verhalten, ist aber kein Wissensspeicher und selten der Startpunkt. Wer diese Rollen sauber trennt, spart Geld, vermeidet Halluzinationen und baut ein System, dem die Fachabteilung wirklich vertraut. Merke dir die Faustregel: RAG für das, was das Modell wissen soll — Fine-Tuning für das, wie es antworten soll.