Feintuning

„Dann trainieren wir das Modell eben auf unsere Daten.“ Der Satz fällt in fast jedem Projekt, meistens nach der dritten Antwort, die nicht passt. Selten ist er falsch. Fast immer ist er verfrüht.

Was du vorher probiert haben solltest

Drei Stellschrauben hast du, und sie kosten sehr unterschiedlich viel:

1. Der Systemprompt. Ein paar Sätze Anweisung, zehn Minuten Arbeit, sofort wieder änderbar. Wie weit das trägt, steht im Baustein System-Prompt.
2. RAG. Du legst dem Modell die richtigen Unterlagen in den Kontext, statt darauf zu hoffen, dass es sie kennt. Aufwand: ein Nachmittag für die erste Fassung.
3. Feintuning. Du änderst die Gewichte. Dafür brauchst du einen Datensatz, eine GPU-Stunde oder mehr, und danach eine zweite Sache, die vorher niemand auf dem Zettel hat: eine Prüfbank, an der du siehst, ob es besser geworden ist.

Warum diese Reihenfolge? Weil die ersten beiden Schritte reversibel sind und der dritte es nicht ist: Ein Systemprompt, der nichts gebracht hat, wird gelöscht und ist damit erledigt, während ein Feintune, der nichts gebracht hat, dich zwei Tage gekostet hat und trotzdem im Betrieb bleibt, weil ihn hinterher niemand mehr anfassen will. Und weil die ersten beiden Schritte oft schon reichen. Ein erstaunlich großer Teil der Fälle, in denen jemand nachtrainieren will, sind in Wahrheit Kontext-Probleme.

Form und Verhalten, kein Wissen

Hier liegt das häufigste Missverständnis. Feintuning fühlt sich an wie Beibringen, und so wird es meistens verkauft. Wir füttern die Firmendokumente hinein, danach kennt das Modell unsere Firma. So funktioniert es nicht.

Was tatsächlich gut funktioniert:

• Format. Immer JSON, immer diese Felder, nie ein einleitender Satz davor.
• Ton. Kurz, sachlich, ohne Entschuldigungen.
• Auswahlverhalten. Aus vierzig Werkzeugen das richtige greifen. Oder eben keins.
• Eine feste Aufgabe. Aus einer E-Mail die vier Felder ziehen, die dein Ticketsystem braucht.

Was schlecht funktioniert, ist das Einspeisen von Fakten. Gekhman et al. haben das 2024 untersucht (arXiv:2405.05904) und einen unbequemen Befund mitgebracht. Beispiele mit Wissen, das im Vortraining nicht vorkam, lernt ein Modell deutlich langsamer als bekanntes. Und je mehr davon im Datensatz stehen, desto häufiger erfindet es auch anderswo etwas. Wer Fakten nachreichen will, nimmt also RAG. Wer Verhalten festzurren will, nimmt Feintuning. Wer beides braucht, macht beides.

Die Faustregel dazu ist kurz. Steht die Antwort in einem Dokument, das du dem Modell mitschicken könntest, dann ist Feintuning das falsche Werkzeug.

Alles trainieren oder nur eine Schicht dazu?

Beim vollständigen Feintuning werden alle Gewichte angepasst. Für ein 8B-Modell heißt das, dass Gewichte, Gradienten und Optimierer-Zustände gleichzeitig im Speicher liegen müssen, und damit reden wir über deutlich mehr als hundert Gigabyte VRAM. Das ist Rechenzentrums-Arbeit. Und du bekommst am Ende ein komplettes zweites Modell, das du von da an auch komplett verwalten, versionieren und ausliefern musst, mit allem, was an einem Modell dranhängt.

Die andere Bauform heißt LoRA und ist der Grund, warum Feintuning heute überhaupt für kleine Teams infrage kommt. Die Idee stammt von Hu et al. (2021, arXiv:2106.09685). Die Basisgewichte bleiben eingefroren, trainiert wird nur ein kleines, niedrigrangiges Zusatzstück, das im Betrieb auf die Ausgabe der jeweiligen Schicht addiert wird. Im Paper sank die Zahl der trainierbaren Parameter dadurch um mehrere Größenordnungen, bei vergleichbarer Qualität auf den geprüften Aufgaben.

QLoRA (Dettmers et al., 2023, arXiv:2305.14314) treibt das weiter, indem es das eingefrorene Basismodell zusätzlich auf 4 Bit quantisiert. Damit passt das Training eines sehr großen Modells auf eine einzelne dicke GPU. Für die Modellgrößen, um die es bei lokalen Agenten meistens geht, reicht deutlich weniger.

Und was ist so ein Adapter nun?

Das Ergebnis eines LoRA-Laufs ist eine Datei neben dem Modell. Nicht darin. Ein paar Dutzend Megabyte, je nach gewähltem Rang auch mal deutlich weniger, und daneben liegen mehrere Gigabyte Basisgewichte, die sich nie geändert haben und die du deshalb auch nicht noch einmal herunterladen, speichern oder verteilen musst.

Was ändert dieses Größenverhältnis? Fast alles. Du kannst mehrere Adapter für dasselbe Basismodell vorhalten und einen davon beim Start zuschalten, morgen einen anderen. Du kannst ihn versionieren wie Code. Du kannst ihn wegwerfen. Wie das im Serverbetrieb aussieht, welche Engine welchen Schalter dafür hat und was mehrere Adapter gleichzeitig kosten, steht in der Deep-Dive-Stufe.

Feintuning ist die dritte Stellschraube, nicht die erste. Prompt, dann Kontext, dann Gewichte - und die ersten beiden lösen erfahrungsgemäß den größeren Teil der Fälle.

Es bringt einem Modell Form und Verhalten bei, kein Wissen. Fakten gehören in den Kontext, Verhalten in die Gewichte.

Und es passiert heute fast nie als vollständiges Training. Der Normalfall ist ein LoRA-Adapter, ein kleines Zusatzstück, das neben dem Basismodell liegt und zugeschaltet wird.