LLM Fine-Tuning in der Bildung: Kostenfallen und Zeitfresser

Genau an diesem Punkt wird die Architekturentscheidung relevant: Wissen in ein Sprachmodell eintrainieren oder es zur Laufzeit aus einem geprüften Dokumentenbestand abrufen?

Die Debatte um LLM Fine-Tuning vs. RAG in der Bildungsforschung wird oft zu grob geführt. Fine-Tuning gilt als maßgeschneidert, RAG als schnell und günstig. Beides ist nur halb richtig. Fine-Tuning und Retrieval-Augmented Generation lösen unterschiedliche technische Probleme. Wer sie als austauschbare Produktoptionen behandelt, verschiebt Kosten, Latenz und Fehlerrisiken lediglich in andere Teile des Systems.

Für Bildungseinrichtungen ist die zentrale Trennlinie einfach: Verändert sich das benötigte Wissen regelmäßig, gehört es normalerweise nicht in die Modellgewichte. Soll sich dagegen das Verhalten eines Modells wiederholbar ändern – Ausgabeformat, Tonalität, Bewertungsschema, Aufgabenklassifikation –, kann Fine-Tuning sinnvoll sein. Die Betonung liegt auf „kann". Davor stehen Datenarbeit, Evaluation und Datenschutzprüfung.

Die Architekturentscheidung: Wissen abrufen oder Verhalten trainieren

RAG erweitert ein Sprachmodell um einen externen Wissensspeicher. Bei einer Anfrage zerlegt das System die Frage, sucht passende Textsegmente im Index und übergibt diese als Kontext an das Modell. Das Modell formuliert seine Antwort also nicht nur aus seinen vortrainierten Gewichten, sondern mit einem konkreten, abrufbaren Dokumentenausschnitt.

Fine-Tuning verändert dagegen die Modellparameter anhand eines Trainingsdatensatzes. Das Modell soll nach dem Training bestimmte Aufgaben oder Antwortmuster zuverlässiger ausführen. Es ist kein sauberer Ersatz für eine Wissensdatenbank.

Eine vergleichende EMNLP-Studie zeigt den Kern des Problems: Neue Fakten lassen sich durch unbeaufsichtigtes Fine-Tuning nur schwer stabil in ein Sprachmodell schreiben. Mehrere unterschiedliche Formulierungen desselben Fakts können helfen, beseitigen das Grundproblem aber nicht. Ein Modell kann eine Information während des Trainings gesehen haben, sie später dennoch unvollständig, falsch kontextualisiert oder gar nicht abrufen.

Für den Bildungsbetrieb hat das konkrete Folgen. Ein Fine-Tuning auf die Prüfungsordnung des laufenden Schuljahres wirkt zunächst elegant. Nach einer Änderung bei Nachteilsausgleichen, Bewertungsrichtlinien oder Kursangeboten ist das Wissen jedoch in den Modellgewichten veraltet. Die Korrektur bedeutet: Datenbestand überarbeiten, Trainingsdatei neu erzeugen, Trainingslauf starten, Regressionen prüfen, Freigabe wiederholen. Bei RAG wird dagegen das betreffende Dokument ersetzt, erneut segmentiert und indexiert. Das ist nicht kostenlos, aber operativ deutlich kontrollierter.

RAG ist damit kein „Chatbot mit PDF-Anhang". Ein belastbares System braucht eine Dokumentenpipeline: Auswahl, Bereinigung, Metadaten, Segmentierung, Indexierung und regelmäßige Aktualisierung. Wenn diese Pipeline schwach ist, ruft auch ein leistungsfähiges Modell den falschen Absatz ab oder erhält gar keinen relevanten Kontext.

RAG verschiebt die Arbeit aus dem Modelltraining in die Wissenspipeline. Es entfernt sie nicht.

Die systematische Übersicht zu RAG in der Bildung, die 50 Studien aus den Jahren 2021 bis 2025 auswertete, passt zu dieser Einordnung. RAG wurde besonders für Frage-Antwort-Systeme, personalisiertes Lernen und Tutoringsysteme eingesetzt. Berichtet wurden Verbesserungen bei Genauigkeit, Relevanz und Personalisierung. Offene Baustellen bleiben Retrieval-Genauigkeit, Schlussfolgern über mehrere Quellen und die Integration in bestehende Systeme.

Das ist eine brauchbare, aber keine automatische Erfolgsgarantie. Ein Assistent, der zuverlässig den falschen Abschnitt aus einem Curriculum findet, produziert präzise klingenden Unsinn mit Quellenbezug.

Die eigentlichen Kosten liegen vor dem Trainingsjob

Bei der Frage nach den Kosten für das Anpassen von Sprachmodellen wird meist zuerst auf GPU-Stunden oder API-Preise geschaut. Das ist die sichtbare Rechnung. In Bildungsprojekten liegt der größere Zeitaufwand häufig davor: beim Aufbau eines Datensatzes, der fachlich konsistent, rechtlich nutzbar und technisch trainierbar ist.

Für überwachtes Fine-Tuning über eine API muss die Trainingsdatei im JSONL-Format vorliegen und mit dem Zweck „fine-tune" hochgeladen werden. Diese Formalität ist nicht das Problem. Der Aufwand beginnt bei den Beispielen selbst: Welche Eingabe soll welche Ausgabe erzeugen? Wie viele Varianten braucht dieselbe Regel? Wie werden widersprüchliche Lehrmaterialien behandelt? Welche Antworten gelten als fachlich korrekt, welche nur als sprachlich akzeptabel?

Die Kostenstruktur besteht aus mindestens fünf Blöcken:

1. Dateninventur und Rechteklärung. Lehrmaterialien, Musterlösungen, Bewertungsraster und interne Handreichungen haben unterschiedliche Urheber-, Nutzungs- und Datenschutzlagen. Ein technisch vorhandener Ordner ist kein freigegebener Trainingskorpus.

2. Kuration und Bereinigung. Dubletten, alte Fassungen, unvollständige Aufgabenstellungen, Formatfehler und widersprüchliche Musterlösungen müssen entfernt oder markiert werden. Ohne Versionslogik trainiert das Modell auf institutionelle Altlasten.

3. Annotation und Qualitätsstandard. Wenn Lehrkräfte Antworten als „gut" markieren, reicht das nicht als Trainingssignal. Es braucht definierte Kriterien: fachliche Richtigkeit, Quellenbindung, angemessene Hilfestufe, Sprache, Umgang mit Unsicherheit und zulässige Ablehnung.

4. Training und Parameterwahl. Batchgröße, Lernratenmultiplikator und Epochenzahl beeinflussen Kosten und Ergebnis. Eine Epoche ist ein vollständiger Durchlauf durch den Trainingsdatensatz. Mehr Epochen bedeuten nicht automatisch bessere Generalisierung; sie können Überanpassung verstärken.

5. Evaluation und Betrieb. Ein Modell wird nicht mit dem erfolgreichen Trainingsstatus produktionsreif. Es braucht Tests gegen Referenzfälle, Grenzfälle, neue Aufgabenformate und unerwünschte Ausgaben. Danach folgen Monitoring, Aktualisierung und Incident-Prozesse.

Gerade der vierte Block wird überschätzt, der fünfte unterschätzt. Reinforcement Fine-Tuning kann bei einzelnen Anbietern nach Trainingszeit abgerechnet werden. Für o4-mini-2025-04-16 werden 100 US-Dollar pro Stunde der Kerntrainingszeit genannt; bei Modell-Graders kommen Tokenkosten hinzu. Das ist eine klare Zahl, aber keine Projektkalkulation. Sie sagt nichts über die Personentage aus, die nötig waren, um eine brauchbare Bewertungsfunktion und belastbare Trainingsbeispiele zu erzeugen.

Die Forschung zu Fine-Tuning-Strategien für RAG zeigt zudem ein typisches Infrastrukturmuster: Mehrere Strategien können bei Exact Match und F1 ähnliche Verbesserungen erreichen, dabei aber deutlich unterschiedliche Rechenkosten verursachen. Ausschlaggebend sind unter anderem bereits vorhandene Kontextlabels im Datensatz und die Frage, ob für Einbettungs- und Generatormodell eine Lernraten-Grid-Search notwendig wird.

Das ist der Punkt, an dem viele Pilotprojekte in eine Kostenfalle laufen. Das Team optimiert ein Modell, bevor es den Fehlerort gemessen hat. Schlechte Antworten können aus fehlerhaftem Retrieval, mangelhaften Dokumenten, zu langen Prompts, unklaren Systemanweisungen oder einer ungeeigneten Nutzerführung stammen. Fine-Tuning behebt diese Ursachen nicht zuverlässig.

Chunking ist keine Nebensache der Wissensdatenbank

Bei RAG entscheidet die Segmentierung der Dokumente mit darüber, ob ein System brauchbar antwortet. Zu kleine Textsegmente verlieren Kontext. Zu große Segmente erhöhen die Tokenlast, verschlechtern die Trennschärfe des Retrievers und belasten die Latenz. Ein Modulhandbuch ist kein homogener Text: Zugangsvoraussetzungen, Prüfungsform, Lernziele und Fristen sollten nicht als unstrukturierter Block im Vektorindex landen.

Als OpenAI-spezifische Standardeinstellung für statisches Chunking gilt eine maximale Chunkgröße von 800 Token mit 400 Token Überlappung. Zulässig sind dort 100 bis 4.096 Token; die Überlappung darf höchstens die Hälfte der maximalen Chunkgröße betragen. Diese Werte sind keine universelle Empfehlung. Sie zeigen nur, wie stark die Segmentierung den Index formt.

Für Bildungsdaten sollte die Chunking-Strategie aus der Dokumentenstruktur abgeleitet werden, nicht aus einer Default-Einstellung:

• Regelwerke und Satzungen: Abschnitte entlang von Paragraphen, Unterpunkten und Geltungsbereichen schneiden. Eine Frist ohne zugehörige Ausnahme ist kein brauchbarer Retrieval-Chunk.
• Lehrmaterialien: Kapitelüberschrift, Lernziel und Begriffsdefinition als Metadaten speichern. Der Abruf muss zwischen „Definition erklären" und „Aufgabe lösen" unterscheiden können.
• Aufgabenbanken: Aufgabenstellung, Jahrgang, Fach, Kompetenzbereich, Lösungshinweis und Schwierigkeitsgrad getrennt erfassen. Sonst wird eine Aufgabe aus Klasse 10 als Vorlage für ein Grundschulniveau geliefert.
• Interne FAQ: Fragen und verbindliche Antworten als atomare Einheiten halten. Lange Protokolle sind für den Abruf meist schlechter als gepflegte, versionierte Antwortartikel.
• Mehrsprachige Bestände: Sprache als Metadatum führen und Retrieval je nach Nutzereingabe filtern. Ohne diese Trennung können ähnliche Begriffe falsche Sprachfassungen nach oben ziehen.

Die technischen Messgrößen sind überschaubar, müssen aber tatsächlich erhoben werden: Trefferquote relevanter Chunks, Anteil unbelegter Antworten, Antwortlatenz, Tokenverbrauch pro Anfrage und Fehlerrate bei definierten Testfällen. Für ein Hochschulportal mit Prüfungsfragen ist eine hohe Retrieval-Genauigkeit wichtiger als eine kreative Formulierung. Für ein automatisiertes Feedbackwerkzeug kann dagegen ein stabiles Ausgabeformat wichtiger sein als ein großer Wissensindex.

Ein Modell ohne Messprotokoll ist kein Bildungswerkzeug. Es ist ein Demo-Interface mit Restunsicherheit.

Ein sinnvoller Ablauf startet deshalb nicht mit Fine-Tuning, sondern mit einer Fehlerklassifikation. Bei 100 repräsentativen Anfragen sollte das Team markieren: Hat der Retriever die richtige Quelle gefunden? War die Quelle vollständig? Hat das Modell den Kontext korrekt genutzt? War die Antwort didaktisch zulässig? Erst dann lässt sich entscheiden, ob ein Fine-Tuning überhaupt den Engpass adressiert.

Datenschutz: Datenminimierung ist eine Architekturvorgabe

Custom LLMs im Bildungssektor tragen ein besonderes Risiko, weil die nützlichsten Daten oft zugleich die sensibelsten sind. Lernverläufe, Leistungsstände, Förderbedarfe, Fehlzeiten, Beratungsnotizen oder individuelle Arbeitsproben können Personenbezug besitzen oder mit überschaubarem Zusatzwissen wieder personenbeziehbar werden.

Die DSGVO verlangt nach Artikel 5 unter anderem Zweckbindung sowie Datenminimierung. Daten müssen angemessen, erheblich und auf das für den jeweiligen Zweck notwendige Maß beschränkt sein. Daraus folgt keine pauschale Freigabe für „anonymisierte Bildungsdaten". Es folgt zunächst eine Prüfpflicht: Braucht das System diese Daten wirklich? Können synthetische Beispiele, abstrahierte Fehlermuster oder pseudonymisierte Inhalte denselben technischen Zweck erfüllen?

Für RAG und Fine-Tuning gelten unterschiedliche Risikoprofile:

• Beim RAG-System liegt das Risiko vor allem im Dokumentenbestand, in Zugriffsrechten, Metadatenfiltern und der Ausgabe. Ein Assistent darf einer Lehrkraft nicht versehentlich Informationen aus einem anderen Kursraum liefern, nur weil der semantische Treffer gut war.
• Beim Fine-Tuning kommt das Risiko der langfristigen Einprägung hinzu. Selbst wenn ein Modell personenbezogene Trainingsinhalte nicht wortgleich ausgibt, ist die Nachweis- und Kontrolllage deutlich komplexer als bei einem abrufbaren Dokument, das entfernt werden kann.
• Bei beiden Ansätzen sind Speicherfristen, Rollenrechte, Auftragsverarbeitung, Protokollierung und ein Verfahren für Korrektur oder Löschung Teil der Systemarchitektur. Sie sind keine Ergänzung nach dem Pilotbetrieb.

UNESCO empfiehlt für generative KI in Bildung und Forschung unter anderem Datenschutzvorgaben, Transparenz gegenüber Lernenden über erhobene und verwendete Daten sowie Mechanismen zur Prüfung von Verzerrungen. Für Infrastrukturteams lässt sich das nüchtern übersetzen: Ohne Datenlandkarte, Berechtigungskonzept und dokumentierten Freigabeprozess gibt es keinen produktiven Roll-out.

Besonders problematisch sind Trainingsdaten aus echten Lehrkraft-Lernenden-Interaktionen. Sie enthalten oft genau die Formulierungen, die ein Assistenzsystem später nachbilden soll. Sie enthalten aber auch Namen, Diagnosen, Konflikte, Leistungsurteile und implizite Zuschreibungen. Die technische Verfügbarkeit ist keine Rechtsgrundlage und keine Qualitätsfreigabe.

Evaluation muss fachliche und operative Fehler trennen

Ein Bildungsassistent wird häufig mit einer einzigen Kennzahl bewertet: „Wie gut sind seine Antworten?" Das ist zu unscharf. Ein Modell kann fachlich korrekt, aber regelwidrig antworten. Es kann eine hilfreiche Erklärung liefern, aber die falsche Prüfungsordnung zitieren. Es kann eine Antwort verweigern, obwohl die Information im freigegebenen Material vorhanden ist.

Die Evaluation sollte daher mindestens vier Schichten abdecken:

1. Fakten- und Quellenprüfung. Stimmt die Aussage mit dem freigegebenen Korpus überein? Wurde die richtige Dokumentversion verwendet? Fehlt ein relevanter Vorbehalt?

2. Retrieval-Prüfung. Wurde der passende Chunk unter den ersten Treffern geliefert? Ist der Kontext ausreichend, oder wurde nur ein isolierter Halbsatz abgerufen?

3. Ausgabeprüfung. Folgt das Modell dem gewünschten Format? Kennzeichnet es Unsicherheit? Erfindet es keine Quellen, Fristen oder institutionellen Zuständigkeiten?

4. Pädagogische und organisatorische Prüfung. Passt die Hilfestufe zur Zielgruppe? Wird eine Musterlösung zu früh ausgegeben? Werden sensible Inhalte angemessen behandelt? Ist die Antwort für die Rolle des Nutzers freigegeben?

Für diese Tests braucht es einen eingefrorenen Referenzsatz. Wer nach jedem Prompt-Update neue Einzelfälle improvisiert, kann Verbesserungen nicht von Zufall unterscheiden. Der Testsatz sollte normale Anfragen, Mehrdeutigkeiten, absichtlich falsche Prämissen, veraltete Dokumente, Zugriffsgrenzen und fachübergreifende Fragen enthalten.

Eine brauchbare Betriebsregel lautet: Jeder produktive Use Case erhält eine akzeptierte Fehlerrate und eine Eskalationslogik. Bei unverbindlichen Orientierungstexten kann ein Hinweis auf Unsicherheit ausreichend sein. Bei Prüfungsfristen, Zulassungsentscheidungen oder Förderempfehlungen ist das nicht genug. Dort muss das System entweder belastbar quellengebunden antworten oder an eine zuständige Person verweisen.

Die Halluzinationsrate lässt sich dabei nicht als abstrakte Modelleigenschaft behandeln. Sie ist immer an Aufgabe, Quellenlage und Nutzerrolle gebunden. Wer Halluzinationen mit einer pauschalen Prozentzahl beziffern will, misst das Falsche. Aussagekräftig wird der Wert erst im Verhältnis zu einer konkreten Fehlerklasse, einer dokumentierten Schwelle und einer definierten Eskalation.

In der Praxis zeigt sich das etwa an drei häufigen Fehlertypen. Erstens: faktisch korrekte Aussagen mit falscher Quellenangabe. Zweitens: plausibel klingende Antworten auf Fragen, zu denen das System keine freigegebene Information hat – ein klassischer Fall für eine sauber programmierte Verweigerung mit Verweis auf eine Beratungsstelle. Drittens: formal korrekte, aber didaktisch ungeeignete Antworten, etwa eine vollständig ausformulierte Musterlösung bei einer Aufgabe, die nur Hilfestellung verlangt.

Qualitätssicherung in der pädagogischen Anwendung ist keine Modellmetrik. Sie ist eine Institutionsroutine.

Genau hier unterscheidet sich ein Bildungsprojekt von einer Produktdemo. Es reicht nicht, dass ein Modell überzeugend formuliert. Es muss in eine Freigabe-, Monitoring- und Korrekturstruktur eingebettet sein, die Verantwortliche, Rollen und Zeitfenster benennt. Fine-Tuning kann diese Struktur ergänzen, aber nicht ersetzen. Und RAG entlastet sie nur, wenn die Dokumentenpflege als kontinuierliche Aufgabe verstanden wird – nicht als einmaliger Datenimport.

Wer vor der Architekturentscheidung steht, sollte drei Fragen ehrlich beantworten: Wie schnell ändert sich das relevante Wissen? Wer darf eine Antwort in welcher Rolle freigeben? Welche Fehlerklasse ist im konkreten Use Case am schädlichsten? Aus diesen Antworten ergibt sich die Reihenfolge der nächsten Schritte fast von selbst – und in vielen Fällen steht am Ende kein Fine-Tuning, sondern eine bessere Pipeline.