Leitfaden / Industrielle KI
Small Language Models: Wann ein kleines Sprachmodell für die Industrie reicht
Eine Anwendung soll aus einer Wartungsmeldung Anlage, Fehlerbild und fehlende Angaben herausarbeiten. Sie muss keine beliebige Wissensfrage beantworten. Für eine solche begrenzte Aufgabe lohnt es sich, ein kleines Sprachmodell gegen größere Modelle und einfache Regeln zu testen.
Small Language Models, kurz SLMs, sind vergleichsweise kompakte Sprachmodelle. Eine einheitliche Größenobergrenze ist für die Auswahl wenig hilfreich. Entscheidend sind die Qualität Ihrer Aufgabe, die benötigten Ressourcen und die Fähigkeit, das Modell zuverlässig zu betreiben.
Klein bedeutet außerdem nicht automatisch spezialisiert. Ein kompaktes allgemeines Modell kann an Fachbegriffen scheitern. Ein größeres Modell kann durch geeignete Daten und Anpassung spezialisiert werden. Betrachten Sie Größe und Fachkompetenz als getrennte Eigenschaften.
Für welche industriellen Aufgaben lohnt sich der Vergleich?
Gute Kandidaten haben klar definierte Eingaben, begrenzte Ausgaben und überprüfbare Ergebnisse. Dazu gehören die Zuordnung von Servicemeldungen, das Extrahieren bestimmter Dokumentfelder oder das Vorbereiten strukturierter Rückfragen. Offene technische Problemlösung unter wechselnden Bedingungen ist anspruchsvoller.
| Aufgabe | Was ein kleineres Modell leisten könnte | Was zusätzlich geprüft werden muss |
|---|---|---|
| Wartungsmeldung strukturieren | Anlage, Symptom und fehlende Felder erkennen | Unbekannte Kennungen nicht erfinden |
| Dokumente zuordnen | Bekannte Dokumenttypen unterscheiden | Neue Typen als unbekannt behandeln |
| Rückfrage vorbereiten | Fehlende Angaben verständlich anfordern | Keine technische Diagnose behaupten |
| Quelle zusammenfassen | Relevante Passage knapp wiedergeben | Negationen, Werte und Einheiten erhalten |
Der Phi-3 Technical Report von Microsoft Research ist ein Forschungsbeispiel für leistungsfähige kompakte Modelle. Seine Benchmark-Ergebnisse sind kein Nachweis für Ihre technischen Dokumente und keine aktuelle Produktempfehlung. Die Modellwahl braucht einen eigenen Vergleich mit realistischen Aufgaben.
Wie arbeitet ein kleines Sprachmodell?
Ein autoregressives Sprachmodell verarbeitet Text als Tokens und erzeugt die Ausgabe schrittweise. Seine Parameter bilden gelernte Zusammenhänge ab. Weniger Parameter können den Speicherbedarf der Gewichte reduzieren; sie sagen für sich genommen wenig über die Qualität einer konkreten Fachaufgabe aus. Das Modell ist auch keine Datenbank mit garantiert richtigen Anlageninformationen.
Bei einer Wartungsanwendung könnte das Modell eine freie Meldung in festgelegte Felder umwandeln. Eine nachgelagerte Prüfung vergleicht die Anlagenkennung mit dem Stammdatensystem und weist unbekannte Kennungen zurück. Erst ein berechtigter Workflow darf daraus einen Auftrag vorbereiten. So bleibt die sprachliche Verarbeitung von der Befugnis zum Handeln getrennt.
Auch als Bestandteil eines KI-Agenten erhält das Modell nur die benötigten Werkzeuge und Zugriffe. Ein zurückgegebenes Feld ist zunächst ein Vorschlag. Für schreibende Aktionen gelten die festgelegten Freigabegrenzen, unabhängig von der Modellgröße.
RAG, Fine-Tuning oder ein besserer Prompt?
Beginnen Sie mit einer klaren Aufgabenbeschreibung und einem festen Ausgabeformat. Wenn das Problem auf diese Weise lösbar ist, spart das eine zusätzliche Trainingspipeline. Regeln zur Prüfung von Kennungen oder Einheiten sollten außerhalb des Sprachmodells bleiben, wo sie zuverlässig ausführbar sind.
RAG stellt zur Anfrage passende Quellen bereit. Es kann geeignet sein, wenn Informationen häufig wechseln oder eine Antwort auf eine konkrete Quelle verweisen soll. Das Modell braucht trotzdem Zugriffsgrenzen und die Fähigkeit, bei unzureichenden Quellen keine Antwort zu erfinden. Der RAG-Leitfaden für Industrieunternehmen behandelt diese Architektur.
Fine-Tuning verändert das Verhalten des Modells anhand von Trainingsbeispielen. Es kann für wiederkehrende Ausgabeformen oder Fachaufgaben infrage kommen. Aktuelle Wartungsstände oder wechselnde Freigaben gehören deshalb nicht automatisch in die Modellgewichte. Pflegeaufwand und neue Fehler müssen gegen den Nutzen getestet werden.
Ein Testsatz aus der tatsächlichen Arbeit
Sammeln Sie unterschiedliche, fachlich geprüfte Beispiele: vollständige und unvollständige Meldungen, Tippfehler, Abkürzungen, ähnliche Anlagenkennungen und mehrsprachige Eingaben. Halten Sie einen unabhängigen Teil für die endgültige Bewertung zurück. Beispiele aus derselben Vorlage oder demselben Vorgang sollten nicht unbemerkt über beide Gruppen verteilt sein.
Eine Ausgabe kann sprachlich überzeugend und fachlich falsch sein. Bewerten Sie Felder und Fehlerarten getrennt: falsche Zuordnung, erfundener Wert, fehlende Rückfrage oder unzulässige Aktion. Für kritische Angaben kann eine bewusste Nichtantwort besser sein als eine plausible Ergänzung.
Vergleichen Sie das kleine Modell mit mindestens einer fachlich sinnvollen Alternative. Das kann ein größeres Modell sein, aber auch eine Kombination aus Formular, Regeln und Suche. Die Welf-Anleitung zur Modellevaluation hilft, die Entscheidung nachvollziehbar aufzubauen.
Kosten pro brauchbarem Ergebnis rechnen
Die Größe der Modellgewichte erklärt nur einen Teil des Ressourcenbedarfs. Laufzeit, Kontextlänge, gleichzeitige Anfragen und zusätzliche Verarbeitung beeinflussen den Betrieb. Testen Sie mit dem vorgesehenen Server und einer realistischen Last, nicht nur mit einer einzelnen kurzen Anfrage.
Rechnen Sie auch menschliche Korrekturen ein. Ein rein hypothetisches Beispiel: Bei 1.000 Vorgängen führen zehn zusätzliche Prozentpunkte Nachprüfung zu 100 weiteren Prüfungen. Braucht jede davon zwei Minuten, entstehen 200 Minuten Zusatzarbeit. Eine niedrigere Inferenzrechnung kann dadurch bedeutungslos werden. Das Beispiel beschreibt keine gemessenen Welf-Ergebnisse.
Messen Sie Antwortzeit und Erfolgsquote gemeinsam. Ein Modell, das kurze Testtexte gut verarbeitet, kann an langen Stücklisten oder Dokumenten mit widersprüchlichen Angaben scheitern. Solche Eingaben gehören in den Vergleich, wenn sie im Betrieb vorkommen.
Lokal betreiben heißt Verantwortung übernehmen
Ein kleines Modell kann lokale Ausführung erleichtern. Prüfen Sie dennoch, ob ausreichender Speicher, Überwachung und Zuständigkeiten für Updates vorhanden sind. Daten können auch über Protokolle, angebundene Dienste oder Diagnosefunktionen abfließen. Ein lokaler Modellprozess allein macht die gesamte Anwendung nicht privat.
Zur Auswahl gehören Lizenzbedingungen, verfügbare Modellartefakte, reproduzierbare Konfiguration und ein getesteter Wechselweg. Halten Sie fachliche Regeln und Dokumentzugriffe möglichst unabhängig vom jeweiligen Modell. Das erleichtert den Vergleich einer neuen Version.
Für verteilte Anwendungen erläutert der Edge-AI-Leitfaden die Anforderungen an Rollout und Rückfallbetrieb. Wenn nur wenige Anfragen anfallen, kann eine zentral betriebene Anwendung einfacher sein als viele lokale Instanzen.
Wann sollten Sie beim größeren Modell bleiben?
Wenn das kleinere Modell wesentliche Qualitätsgrenzen verfehlt, sind zusätzliche Anpassungen nicht automatisch wirtschaftlich. Besonders breite Aufgaben, seltene Sonderfälle oder wechselnde Sprachen können den Vorteil aufzehren. Halten Sie die Entscheidung offen, statt eine gewünschte Modellgröße nachträglich zu rechtfertigen.
Welf entwickelt spezialisierte KI-Anwendungen und prüft Modelle anhand der vorgesehenen Aufgabe. Bringen Sie für den Einstieg typische Eingaben, problematische Grenzfälle und die gewünschte Ausgabe mit. Daraus lässt sich ein überprüfbarer Vergleich aufbauen. Modellauswahl besprechen.