Braucht Unternehmens-KI wirklich Fine-Tuning?

💡 Kurzfassung: Die wichtigsten Punkte

• Legen Sie veränderliche Fakten nicht in Modellgewichte. Nutzen Sie direkten Kontext für wenige Dokumente, RAG für eine große und wechselnde Quellsammlung und API oder Datenbank für aktuelle Datensätze.
• Halten Sie explizite Geschäftsregeln in Software. Ein Modell darauf zu trainieren, eine Rückgabefrist oder Berechtigungsgrenze nachzubilden, macht eine prüfbare Regel unnötig unsicher.
• Fine-Tuning ist sinnvoll, wenn ein Modell aus Beispielen ein dauerhaftes Muster lernen muss. Zeigen Sie zunächst, dass einfachere Methoden nicht ausreichen, testen Sie dann das angepasste Modell mit zurückgehaltenen Daten und messen Sie das gesamte Geschäftsergebnis.

Ein Kunde fragt, ob ein von Ihnen verkauftes Gerät bei minus 10 Grad funktioniert. Die Antwort steht eindeutig auf dem einseitigen technischen Datenblatt.

Würden Sie ein Modell feinabstimmen, um diese Frage zu beantworten?

Das sollten Sie nicht. Geben Sie dem Modell das relevante Datenblatt oder die entsprechende Passage zusammen mit der Frage. Bei zwei oder drei Quelldokumenten passen diese in denselben Kontext.

Die Situation ändert sich, wenn die Dokumentenmenge in die Tausende geht, Inhalte häufig wechseln oder jeder Nutzer andere Zugriffsrechte hat. Das System muss dann die richtige Quelle finden, bevor es dem Modell die relevante Passage gibt. Für diese Such- und Abrufaufgabe ist RAG – Retrieval-Augmented Generation – da.

Weder direkter Kontext noch RAG verändern das Training des Modells. Das Modell nutzt beim Antworten eine aktuelle Quelle. Ändert sich das Datenblatt, aktualisieren Sie das Dokument, statt das Modell neu zu trainieren.

Wann ist Fine-Tuning also sinnvoll?

Die Antwort hängt davon ab, was dem System fehlt: Informationen, eine explizite Regel oder ein Muster, das aus Beispielen gelernt werden muss.

Trainieren Sie ein Modell nicht auf Informationen, die bereits in einem Dokument stehen

Viele KI-Systeme in Unternehmen brauchen Zugriff auf Informationen. Das Modell muss vielleicht Produktspezifikationen, einen aktuellen Preis, eine Rückgaberichtlinie oder den Status der Bestellung eines Kunden kennen.

Liegen diese Informationen in einer oder wenigen kurzen Quellen, können sie direkt bereitgestellt werden. Mit wachsender Zahl von Quellen und Nutzern können RAG, Enterprise Search, eine Datenbankabfrage oder eine API die bessere Wahl sein. Was passt, hängt davon ab, wo die Information liegt, wie oft sie sich ändert und wer sie sehen darf.

Fine-Tuning ist hier meist ein unnötiger Umweg. Informationen, die ein Modell im Training gesehen hat, sind weder garantiert aktuell noch in jeder Antwort garantiert korrekt verwendet. Die Quelle zum Zeitpunkt der Anfrage bereitzustellen, macht außerdem leichter nachvollziehbar, worauf die Antwort beruht.

Dasselbe gilt für Unternehmensregeln. „Rückgaben werden innerhalb von 30 Tagen akzeptiert“ kann Information sein. „Ist die Frist abgelaufen, leite die Anfrage an einen Mitarbeiter weiter“ ist eine explizite Geschäftsregel. Es kann zuverlässiger und besser prüfbar sein, diese Regel in Software zu definieren, statt sie einem Modell anhand von Beispielen beizubringen.

Manchmal steht die Antwort in keinem Dokument

Stellen Sie sich einen Händler vor, der die Nachfrage des nächsten Monats prognostizieren möchte. Er verfügt möglicherweise über historische Verkäufe, Aktionen, Saisonalität, Feiertage und Lagerbestände. Doch kein Dokument enthält die Verkaufszahl des nächsten Monats.

Das System muss Zusammenhänge in vergangenen Beispielen lernen und eine Prognose für einen neuen Zeitraum erzeugen. Training eines Modells ist hier sinnvoll. Dieses Modell kann ein Zeitreihenmodell, eine klassische Methode des maschinellen Lernens oder ein anderes speziell entwickeltes Prognosesystem sein. Es muss kein feinabgestimmtes Large Language Model sein.

Dieser Unterschied ist wichtig. „Ein Modell trainieren“ und „ein LLM feinabstimmen“ sind nicht dieselbe Entscheidung. Das Erste umfasst jedes Modell, das ein Muster aus historischen Daten lernt. Das Zweite passt ein vortrainiertes Modell mit konkreten Beispielen an eine engere Aufgabe an.

Fine-Tuning ist erwägenswert, wenn ein Modell die richtigen Informationen und klare Anweisungen hat, aber immer wieder denselben Verhaltensfehler macht. Es kann eingehende Texte wiederholt falsch klassifizieren, erforderliche Felder uneinheitlich extrahieren oder die gewünschte Ausgabestruktur verletzen. Repräsentative Ein- und Ausgabebeispiele können die Leistung für eine solche eng umrissene Aufgabe verbessern.

Beginnen Sie selbst dann mit dem richtigen Modell, klaren Anweisungen, dem notwendigen Kontext und einigen guten Beispielen. Reicht das nicht für die erforderliche Qualität, nutzen Sie zunächst einen Testsatz, der zeigen kann, ob der Fehler tatsächlich im Modellverhalten liegt, bevor Sie Fine-Tuning bewerten.

Ein reales Beispiel, in das Fine-Tuning gehört

MEDIC, ein bei Amazon Pharmacy entwickeltes System zur Verringerung von Fehlern in Verordnungsanweisungen, markiert diese Grenze gut.

Von Ärztinnen und Ärzten formulierte Einnahmeanweisungen können dieselben Informationen auf sehr unterschiedliche Weise ausdrücken. Das System muss Teile wie Verwendungsverb, Dosis, Verabreichungsweg und Häufigkeit erkennen. Die Antwort wartet nicht in einem einzelnen technischen Dokument. Das System muss dieselben Felder in vielen Formen freien Textes erkennen.

Die Forschenden passten dafür ein kleines DistilBERT-Modell mit etwa tausend von Fachleuten gelabelten Beispielen an. Das Modell extrahiert die relevanten Teile einer Verordnung. Software prüft diese anschließend gegen Apothekenregeln und Arzneimitteldatenbanken. Fehlen Informationen oder widersprechen sie sich, stoppt das System, statt eine Empfehlung zu erzeugen. Technikerinnen, Techniker und Apotheker behalten die abschließende Prüfung.

Während der Einführung von MEDIC bei Amazon Pharmacy berichteten die Forschenden von einer Verringerung von Beinahefehlern bei Verordnungsanweisungen um 33 %: Fehler, die abgefangen wurden, bevor eine falsche Anweisung den Patienten erreichte. Das Ergebnis ist auf eine Organisation und eine Aufgabe begrenzt, macht aber einen wichtigen Punkt deutlich. Fine-Tuning ersetzte keine aktuelle Informationsquelle. Es verbesserte die Fähigkeit des Systems, aus Freitext konsistente Felder zu extrahieren.

Eine weitere Erkenntnis der Studie ist ebenso nützlich. Ein größeres T5-Modell, das mit 1,5 Millionen Beispielen feinabgestimmt wurde, erzeugte in schwierigen Fällen weiterhin selbstsicher Anweisungen, statt seine Grenzen zu erkennen. Das Ergebnis von MEDIC entstand nicht durch ein angepasstes Modell allein. Eine eng begrenzte Modellaufgabe, explizite Abbruchbedingungen, Prüfquellen und menschliche Kontrolle wirkten zusammen.

RAG und Fine-Tuning sind keine Konkurrenten

RAG bringt relevante Informationen zum Zeitpunkt der Antwort in das System. Fine-Tuning verändert, wie sich ein Modell bei einer bestimmten Art von Eingabe verhält. Ein System kann beides nutzen.

Es kann zum Beispiel mit RAG ein aktuelles Produktdokument abrufen und dem Modell die relevante Passage geben. Muss das Modell anschließend Felder in das Unternehmensschema extrahieren und tut es dies trotz gut gestalteter Anweisungen weiterhin uneinheitlich, kann Fine-Tuning für diese enge Aufgabe sinnvoll sein.

Ein Vergleich von Microsoft-Forschenden zu landwirtschaftlichen Fragen ergab ebenfalls, dass beide Ansätze Ergebnisse gemeinsam verbessern können. Die Studie ist auf einen Datensatz und bestimmte Modelle begrenzt. Ihre nützliche Schlussfolgerung lautet nicht, dass jedes System RAG und Fine-Tuning kombinieren sollte. Sie lautet, dass sich beide Ansätze ergänzen können, weil sie unterschiedliche Probleme lösen.

Beginnen Sie bei dem, was tatsächlich fehlt

Die Entscheidung fällt leichter, wenn sie bei der fehlenden Komponente statt bei einer Liste von Methodennamen beginnt.

Bevor Sie Fine-Tuning beginnen, sollten vier Antworten klar sein:

1. Bei welchen realen Eingaben wiederholt das Modell welchen Fehler?
2. Lösen die richtige Quelle, klarere Anweisungen oder einige Beispiele diesen Fehler?
3. Lässt sich die Verbesserung auf einem repräsentativen Testsatz messen, der nicht im Training verwendet wurde?
4. Rechtfertigt der Nutzen für Qualität oder Kosten die Arbeit für Datenaufbereitung, Nachverfolgung von Modellversionen und nötiges Nachtraining?

Ich habe zuvor erläutert, warum ein KI-Projekt nicht mit der Modellauswahl beginnen sollte: Beginnen Sie mit dem Geschäftsproblem, nicht mit dem KI-Modell. Für die Fine-Tuning-Entscheidung gilt dieselbe Reihenfolge. Bestimmen Sie zuerst, warum das System hinter dem Bedarf zurückbleibt. Entscheiden Sie dann, welche Komponente diese Lücke schließen kann.

Ein KI-System für Unternehmen zu bauen bedeutet nicht, alles, was das Unternehmen weiß, in ein Modell zu legen. Informationen lassen sich aus ihrer Quelle lesen. Regeln lassen sich in Software anwenden. Ein separates Modell kann Muster in historischen Daten lernen. Fine-Tuning wird erst nützlich, wenn das Problem tatsächlich wiederholtes Modellverhalten ist.

Die erste Frage sollte daher nicht „RAG oder Fine-Tuning?“ lauten. Fragen Sie stattdessen: Fehlen dem System Informationen, eine Regel oder ein Muster, das es lernen muss?

Als Nächstes betrachte ich die Grenze zwischen einem Arbeitsablauf, dessen Schritte Software festlegt, und einem KI-Agenten, der seinen nächsten Schritt auswählt.

Weitere Entscheidungen zu Modellen, Informationen, Befugnissen und Bewertung finden Sie im Leitfaden zur Gestaltung eines KI-Systems für Ihr Unternehmen.