Fine-Tuning offener Modelle auf eigenen Daten

Large Language Models werden auf riesigen Teilen des öffentlichen Internets vortrainiert. Diese Breite macht sie beeindruckend vielseitig - aber vielseitig bedeutet nicht dasselbe wie Experte. Wenn Ihr Unternehmen ein Modell benötigt, das Ihre interne Taxonomie versteht, in Ihrem Hausstil schreibt oder über proprietäre Prozesse nachdenkt, eröffnen sich drei Anpassungswege: Prompt-Engineering, Retrieval-Augmented Generation (RAG) und Fine-Tuning. Jeder hat seinen Platz, und die richtige Wahl - oder die richtige Kombination - kann den Unterschied zwischen einem Prototyp und einem Produktionssystem ausmachen. Privonis hilft europäischen Organisationen, diese Wahl zu treffen und sie vollständig innerhalb ihrer eigenen Infrastruktur umzusetzen.

Drei Wege zur Domänenanpassung

Prompt-Engineering kostet nichts außer Versuch und Irrtum, stößt aber an eine harte Grenze: Man kann nur so viel Kontext in ein Fenster packen, und dem Modell fehlt möglicherweise schlicht das Domänenwissen, das man benötigt. RAG umgeht das Kontextlimit, indem es zur Abfragezeit relevante Chunks aus einer Wissensbasis abruft und dem Modell übergibt. Es ist leistungsstark und überraschend kostengünstig, aber die Retrieval-Qualität begrenzt die Antwortqualität - wenn der richtige Chunk nicht gefunden wird, kann das Modell nicht darüber nachdenken.

Fine-Tuning verfolgt einen anderen Ansatz: Es aktualisiert die Gewichte des Modells auf Ihrem kuratierten Datensatz, sodass Domänenwissen intrinsisch wird. Das Ergebnis ist ein Modell, das aus internalisierter Expertise antwortet, nicht aus abgerufenen Snippets. Es übertrifft typischerweise bei stilsensitiven Aufgaben, strukturierten Ausgaben und latenz-kritischen Pipelines, bei denen man sich keinen zusätzlichen Retrieval-Round-Trip leisten kann. Der Nachteil sind Kosten - sowohl GPU-Zeit als auch Datenvorbereitung -, sodass es sich lohnt, daran zu denken, wenn die anderen beiden Methoden ein Plateau erreicht haben.

Wann Fine-Tuning die richtige Wahl ist

• Ihre Ausgaben müssen einem präzisen Format folgen (klinische Notizen, rechtliche Klauseln, strukturiertes JSON), das Prompt-Vorlagen nicht zuverlässig erzwingen können.
• Dem Modell fehlt konsequent Domänenvokabular, Akronyme oder Produktnamen, die nie in seinem Vortrainingskorpus aufgetaucht sind.
• Latenzanforderungen schließen einen Retrieval-Hop bei jeder Anfrage aus.
• Sie möchten einen komplexen Multi-Shot-Prompt in Zero-Shot-Verhalten komprimieren, um Kosten und Geschwindigkeit zu verbessern.
• Sie destillieren ein größeres Modell in ein kleineres, günstigeres für Edge- oder On-Premise-Deployment.

LoRA und QLoRA: Fine-Tuning ohne Rechenzentrum-Budget

Vollständiges Fine-Tuning aktualisiert jedes Gewicht im Modell, was für Modelle mit Dutzenden von Milliarden Parametern prohibitiv teuer ist. Low-Rank Adaptation (LoRA) umgeht das, indem kleine trainierbare Matrizen in die Attention-Schichten injiziert werden, während die ursprünglichen Gewichte eingefroren bleiben. Die Anzahl der trainierbaren Parameter sinkt um einen Faktor von 100 oder mehr, doch das resultierende Modell entspricht bei den meisten Aufgaben vollständigem Fine-Tuning oder übertrifft es. QLoRA fügt Quantisierung hinzu - das eingefrorene Basismodell wird in 4-Bit-Präzision geladen, was den GPU-Speicherbedarf so dramatisch senkt, dass ein 70-Milliarden-Parameter-Modell auf einem einzelnen A100 fein-abgestimmt werden kann.

Mit QLoRA kann ein Team, das einen A100 besitzt, ein modernes offenes Modell in einem Nachmittag fein-abstimmen - kein Cloud-Konto, keine Daten, die das Gebäude verlassen.

Datenvorbereitung: der entscheidende Schritt

Modellqualität ist durch Datenqualität begrenzt. Vor jedem Trainingslauf arbeitet Privonis mit Kunden zusammen, um einen überwachten Datensatz von Eingabe-Ausgabe-Paaren zu kuratieren, der das genaue gewünschte Verhalten darstellt. Typische Quellen sind: überprüfte Kundeninteraktionen, korrigierte Modellausgaben, von Experten annotierte Dokumente und synthetische Daten, die von einem stärkeren Lehrermodell generiert und dann gefiltert wurden. Volumen ist weniger wichtig als Vielfalt und Korrektheit - tausend sorgfältig geprüfte Beispiele übertreffen oft zehntausend verrauschte. Datenbereinigungspipelines behandeln Deduplizierung, Längenanpassung und Formalnormalisierung vor dem Training.

Evaluierung: zu wissen, wann man fertig ist

Fine-Tuning ohne rigorose Evaluierung ist Optimierung im Dunkeln. Ein zurückgehaltener Evaluierungssatz - der während des Trainings nie gesehen wurde - misst, ob das Modell generalisiert hat oder nur auswendig gelernt hat. Metriken hängen von der Aufgabe ab: Exact Match und F1 für Extraktionsaufgaben, ROUGE für Zusammenfassung, menschliche Präferenzwertungen für offene Generierung. Privonis führt automatisierte Evaluierungen nach jedem Checkpoint durch und markiert katastrophales Vergessen - Fälle, in denen das Modell Domänenfähigkeiten gewinnt, aber allgemeines Denkvermögen verliert - indem eine Standard-Benchmark-Probe in jede Evaluierungssuite aufgenommen wird.

Die Gewichte gehören Ihnen

Das ist der Punkt, der in Diskussionen über cloud-gehostete Fine-Tuning-APIs oft verloren geht: Wenn Sie über einen Drittanbieterdienst fein-abstimmen, können die resultierenden Gewichte an diesen Anbieter gebunden sein. Mit Privonis ist das Basismodell Open-Weight, der Trainingslauf findet auf Hardware statt, die Sie kontrollieren, und der LoRA-Adapter oder das zusammengeführte Checkpoint gehört Ihnen - zum Behalten, Versionieren und Deployen wo immer Sie möchten. Das bedeutet kein Vendor-Lock-in, keine Tokengebühr auf ein Modell, das Sie bezahlt haben zu trainieren, und kein Risiko, dass der Anbieter Ihre Daten für erneutes Training verwendet. Für europäische Unternehmen, die sensible Informationen verarbeiten, ist das Behalten der Gewichte kein Nice-to-have - es ist eine Governance-Anforderung.