Welche Veränderung soll das Training bewirken?

Fine-Tuning passt ein bereits trainiertes Modell anhand zusätzlicher Beispiele an eine Aufgabe an. Ein sinnvoller Auftrag lautet etwa: Serviceberichte sollen wiederkehrenden Fehlerklassen zugeordnet und in einem festgelegten Schema ausgegeben werden. «Die KI soll unser Unternehmen verstehen» ist dafür zu unbestimmt. Das Projekt braucht beobachtbares Zielverhalten, einen Datenbestand und eine Möglichkeit, den Fortschritt unabhängig zu prüfen.

Nicht jede Anpassung verändert sämtliche Modellparameter. Die Hugging-Face-Dokumentation zu LoRA beschreibt ein Verfahren, bei dem die ursprünglichen Gewichte eingefroren bleiben und kleinere zusätzliche Matrizen trainiert werden. Solche Verfahren können den Trainingsaufwand reduzieren. Daraus folgt keine Garantie für bessere Ergebnisse in Ihrem Prozess.

Für Auftraggeber zählt deshalb zuerst der Unterschied zwischen dem heutigen Fehler und dem gewünschten Ergebnis. Muss das System gleichartige Fälle konsistenter einordnen? Soll es Fachsprache verwenden? Oder fehlt ihm schlicht die aktuelle Information? Diese Fragen führen zu unterschiedlichen Lösungen.

Wann zusätzliche Informationen mehr helfen

Ändern sich Preise, Zuständigkeiten oder technische Anleitungen laufend, sollten diese Inhalte in einer gepflegten Quelle bleiben. Ein Modelltraining ist kein Ersatz für deren Aktualisierung und Berechtigungen. Für solche Aufgaben beschreibt unser Leitfaden zu RAG mit eigenen Unternehmensdokumenten, wie eine Anwendung benötigte Informationen zur Anfrage hinzuholen kann.

Fine-Tuning und Wissenssuche können zusammenwirken. Die Suche liefert beispielsweise den gültigen Vertragstext, während ein angepasstes Modell daraus eine standardisierte Zusammenfassung erstellt. Der Auftrag muss beide Leistungen getrennt testen. Wenn das falsche Dokument gefunden wird, lässt sich dieses Problem nicht durch einen schöner formulierten Antworttext lösen.

Eine praktische Vorprüfung besteht aus drei Varianten: Basismodell mit einfachem Auftrag, Basismodell mit sorgfältigem Prompt und Beispielen sowie die geplante Anpassung. Erst wenn die zweite Variante zuverlässig an nachvollziehbare Grenzen stösst, ist der zusätzliche Trainingsaufwand begründet.

Das Arbeitsmittel: eine Karte pro Trainingsbeispiel

Erstellen Sie für jede Aufgabe eine kleine Beispielkarte. Sie enthält den tatsächlichen Eingang, die erwartete Ausgabe, den Grund für diese Ausgabe und die Freigabe durch eine fachkundige Person. Ergänzen Sie besondere Fälle: unvollständige Angaben, unbekannte Klassen, widersprüchliche Informationen und Aufgaben, die das Modell ausdrücklich zurückweisen soll.

Für einen fiktiven Wartungsbetrieb könnte eine Karte so aussehen:

• Eingang: «Anlage startet nach dem Filterwechsel nicht; Fehlermeldung fehlt.»

• Erwartete Klasse: «Weitere Diagnose erforderlich».

• Erwartete Ausgabe: Beschreibung des beobachteten Problems und zwei sachliche Rückfragen.

• Verbotene Ergänzung: Eine bestimmte defekte Komponente behaupten.

• Fachliche Begründung: Die vorliegenden Angaben reichen für eine Ursache nicht aus.

Gerade die letzte Zeile verhindert, dass gut klingende Vermutungen versehentlich als Trainingsziel dienen. Zwei Fachpersonen sollten eine Auswahl unabhängig beurteilen. Wenn sie unterschiedliche Zielantworten erwarten, braucht es zunächst eine fachliche Regel. Das Modell kann eine ungeklärte Entscheidung nicht zuverlässig vereinheitlichen.

Training und Abnahme auseinanderhalten

Reservieren Sie vor der Entwicklung einen unabhängigen Testsatz. Nahezu identische Vorgänge, Kopien und Varianten desselben Dokuments gehören nicht gleichzeitig in Training und Test. Sonst erscheint das Ergebnis besser, als es bei wirklich neuen Fällen sein dürfte. Halten Sie zusätzlich einige besonders schwierige, aber relevante Fälle für eine abschliessende Prüfung zurück.

Auch die Google-Dokumentation zum überwachten Fine-Tuning unterscheidet Trainings- und Validierungsdaten und beschreibt eine anschliessende Evaluation. Ob ein konkretes Modell, eine Region oder ein gewünschtes Datenformat unterstützt wird, muss der Umsetzungspartner zum Angebotszeitpunkt prüfen.

Fordern Sie einen Ergebnisvergleich, in dem dieselben Testfälle von der besten Variante ohne Training und der angepassten Variante bearbeitet werden. Bewertende Personen sollten möglichst nicht wissen, welcher Kandidat welche Antwort erzeugt hat. Prüfen Sie fachliche Richtigkeit, gültiges Ausgabeformat, korrekte Zurückweisung und benötigte Nacharbeit getrennt.

Kosten an der gesamten Aufgabe messen

Ein günstiger Modellaufruf kann teuer werden, wenn Mitarbeitende häufig nachbessern müssen. Erfassen Sie deshalb neben Rechen- und Betriebskosten auch die Vorbereitung der Beispiele, fachliche Prüfung, Fehlersuche und spätere Wiederholung des Trainings. Ein kleiner Datensatz verlangt nicht automatisch ein kleines Projekt.

Nutzen Sie als Abnahmeblatt fünf Felder: getestete Version, Ergebnis je Fehlerklasse, Bearbeitungszeit mit Nacharbeit, laufender Betriebsaufwand und offene Einschränkungen. Die Entscheidung kann auch lauten, beim Basismodell zu bleiben. Ein solcher Befund ist ein brauchbares Projektergebnis, wenn die Prüfung begrenzt und transparent durchgeführt wurde.

Klären Sie zudem, welche Rechte für Trainingsmaterial bestehen, wo es verarbeitet wird und welche Artefakte Sie erhalten. Dazu gehören die freigegebene Datenversion, Bewertungsregeln, Testergebnisse sowie die benötigte Konfiguration. Das erleichtert spätere Anbieter- oder Modellwechsel.

Einen begrenzten Auftrag formulieren

Beginnen Sie mit einer einzigen wiederkehrenden Aufgabe und einer ausdrücklich begrenzten Untersuchungsphase. Vereinbaren Sie, dass erst der Vergleich entscheidet, ob eine angepasste Modellversion in Betrieb geht. So kaufen Sie eine überprüfbare Verbesserung statt eines Trainingslaufs ohne fachliches Ziel.

Mit einclick als KI-Umsetzungspartner lässt sich aus Ihrem konkreten Fehlermuster ein solcher Prüfauftrag entwickeln: mit nachvollziehbaren Beispielen, einer Vergleichsvariante und klaren Anforderungen an die spätere Pflege.