Custom AI: Mehr als nur ein Traum

Stell dir vor, du hast einen AI-Assistenten, der dein Produkt in- und auswendig kennt, in deiner Unternehmenssprache spricht und die Feinheiten deiner Branche besser versteht als jedes通用modell. Genau das verspricht domänenspezifisches Fine-tuning – und das Beste: Es wird immer zugänglicher, sogar für Entwickler ohne Rechencluster im Keller.

Ich habe vor Kurzem mit Continued Pretraining (CPT) experimentiert. Dabei trainierst du ein bestehendes Modell einfach auf spezialisierten Daten weiter. Die Ergebnisse waren überraschend, und ich habe eine Menge gelernt – vor allem darüber, was beim Aufbau von Trainingsdaten wirklich funktioniert.

Warum LoRA die Spielregeln ändert

Das Problem bei klassischem Fine-tuning: Du brauchst VRAM ohne Ende. Selbst ein 7-Milliarden-Parameter-Modell verschlingt schon ordentlich Speicher, bevor überhaupt das Training losgeht.

LoRA löst das elegant. Anstatt alle Gewichte zu aktualisieren, friert LoRA das Originalmodell ein und hängt kleine, trainierbare Adapter an bestimmte Schichten. Nur diese Adapter werden aktualisiert – ein winziger Bruchteil der Gesamtzahl.

Als Kontext: Bei Qwen 3 4B (4 Milliarden Parameter) hat meine LoRA-Konfiguration gerade mal 66 Millionen Parameter angesprochen – etwa 1,6 Prozent. Das machte Training auf normaler Hardware möglich, die sonst komplett überfordert wäre.

Ein Trainingsdatensatz, der zum Denken anregt

Mein Testfeld war ein Reiseberater für eine fiktive Stadt namens „Awesomeville" mit eigenem U-Bahn-System und historischen Sehenswürdigkeiten. Mein Ziel war nicht Auswendiglernen – ich wollte, dass das Modell tatsächlich über Routen, Umstiege und Verbindungen nachdenkt.

Stolperfallen, die ich durchlaufen habe

Qualität vor Quantität ist kein Klischee. Mein erster Versuch war... ehrgeizig. Am Ende hatte ich einen aufgeblasenen Datensatz mit 10.000 Einträgen, voll mit konkreten Routenbeispielen. Das Ergebnis? Ein Modell, das Routen auswendig gelernt hatte, anstatt zu navigieren. Bei unbekannten Szenarien brach es komplett zusammen.

Agents sind großartig, um synthetische Daten schnell zu generieren, aber sie bringen eigene Probleme mit:

• Template-Sprache: Agents nutzen oft repetitive Formulierungen, was es dem Modell erschwert, feine Unterschiede zwischen Beispielen zu erkennen
• Menge ohne Validierung: Agents generieren so effizient, dass man schnell tausende zweifelhafte Beispiele akkumuliert, bevor man die Qualitätsprobleme bemerkt

Der inkrementelle Ansatz, der funktioniert hat

Ich habe den ursprünglichen Datensatz verworfen und von Null neu aufgebaut – mit einem gestaffelten Ansatz:

1. EinLinien-Reisen – Einfach starten mit Routen auf einer U-Bahn-Linie
2. EinLinien-Umstiege – Basis-Umstiege an Umsteigebahnhöfen einführen
3. MehrLinien-Umstiege – Komplexe Routen über mehrere Linien aufbauen
4. Kontext-Bindung – Stationen mit nahegelegenen historischen Stätten verbinden

Die Kernerkenntnis: Inkrementell aufbauen, ständig testen und der Versuchung widerstehen, mehr Daten auf Probleme zu werfen, die besseres Design lösen könnte.

Parallel zum Training testen

Eine wichtige Lektion: Du musst nicht nach jeder Iteration komplett neu trainieren. Teile dein Training in Phasen auf – starte mit dem vollen Datensatz, dann gezieltes Nachtraining auf einem kleineren, fokussierten Set. Das sparte erheblich Zeit und ermöglichte trotzdem, die Reasoning-Fähigkeiten des Modells zu verfeinern.

Parallel zu den Trainingsdaten solltest du eine umfassende Testsuite aufbauen. Miss den Fortschritt anhand von Beispielen, die nicht im Training vorkamen – nicht nur an den Mustern, die du trainiert hast.

Das Fazit

Domänenspezialisierung durch Continued Pretraining ist längst nicht mehr nur etwas für Forschungslabore. Mit Tools wie Unsloth und Techniken wie LoRA können Entwickler spezialisierte Modelle erstellen, die ihren Anwendungsfall wirklich verstehen – ob Reiseberater, Rechtsassistent oder Dokumentationsbot.

Die eigentliche Herausforderung liegt nicht in der technischen Umsetzung. Sie liegt in der durchdachten Datenauswahl. Dein Trainingskorpus muss zum Reasoning anregen, nicht nur Muster abbilden. Bau inkrementell auf, validiere ständig und denk daran: Manchmal kommt das beste Modell durch klügere Daten zustande, nicht durch mehr Daten.

Wenn du eine domänenspezifische Anwendung baust, überleg dir, was ein custom fine-tuned Modell bieten könnte, das allgemeine APIs nicht liefern können. Die Einstiegshürde war noch nie so niedrig.