ML vs. LLM: 5 Fehlerquellen für LLMs – und wie der Aufruf von ML-Tools Abhilfe schafft

TL;DR

• Ihr LLM kann jetzt Python ausführen und somit Berechnungen. Es kann jedoch noch kein lernen , den Zustand pro Datenstrom speichern oder einen Live-Feed bewerten. Die Berechnung selbst war nie das Schwierigste.
• ML-Modelle sind bei eng begrenzten numerischen Aufgaben präzise, ​​aber nutzlos, wenn es darum geht, zu entscheiden, was mit dem Ergebnis geschehen soll.
• Ein nützlicher KI-Agent benötigt beides. Unten: eine Entscheidungsmatrix und fünf Eingabeaufforderungen, die ein LLM zum Absturz bringen, jeweils mit dem ML-Tool-Aufruf zur Behebung des Problems.

Warum Teams immer wieder zum falschen Werkzeug greifen

Die Frage „ML vs. LLM“ taucht in der angewandten KI-Forschung häufiger auf als fast jede andere – und in neun von zehn Fällen liegt das Problem nicht an den Daten. Vielmehr hat ein Team ein LLM-System für eine Aufgabe implementiert, die eigentlich ML benötigt, oder ein reines ML- dashboard entwickelt, dessen Auswertung ein LLM-System erfordert.

Das ist eine Falle. LLM-Demos sind beeindruckend: Man beschreibt ein Problem in einfachen Worten und erhält sofort ein schlüssiges Ergebnis. Der nächste logische Schritt ist also, Sensordaten in dasselbe Modell einzuspeisen und es die morgige Last prognostizieren, die defekte Pumpe erkennen oder Maschinen nach Risiko einstufen zu lassen. In der Demo funktioniert das einwandfrei. Doch dann kommt der Produktivbetrieb mit Störungen, Lücken und Abweichungen, und die vermeintlich sicheren Ergebnisse erweisen sich still und leise als falsch.

Das gegenteilige Scheitern ist genauso häufig und weniger auffällig: präzise ML-Ergebnisse, die in einem dashboard angezeigt werden, das niemand nutzt. Die interessante Arbeit liegt an der Schnittstelle zwischen beiden – und genau dort setzt Widerstand ein:

Moment mal – können LLMs nicht jetzt einfach Python ausführen?

Eine berechtigte Frage. Vor zwei Jahren lautete die Antwort auf die Frage „Warum nicht einfach den LLM fragen?“: „Der kann das nicht.“ Diese Antwort ist inzwischen falsch – und würde dieser Artikel sich immer noch darauf stützen, würde ein kluger Ingenieur das Fenster schließen. Daher sollten wir genau festhalten, was sich geändert hat und was nicht.

In einem Chatfenster, ja. Sowohl ChatGPTs erweiterte Datenanalyse als auch Claudes Analysetool schreiben und führen Python in einer Sandbox aus. Diese Sandbox befindet sich jedoch im Produkt, das das Modell umschließt – nicht im Modell selbst.

Über die API, jedoch nur nach entsprechender Konfiguration. Die API bildet die Grundlage nahezu aller IoT Agenten und -Plattformen, und die Codeausführung ist dort optional. Der Code-Interpreter von OpenAI ist ein Tool, dem Sie ein Tools- Array übergeben und einen bereitgestellten Container zurückerhalten (ca.$0,03 Codeausführungstool in der Messages API befindet sich in der Beta-Phase und ist standardmäßig deaktiviert. Rufen Sie den einfachen Endpunkt mit einer Eingabeaufforderung auf, erhalten Sie Tokens, aber keine Codeausführung.

Innerhalb eines Produktionssystems ist es ohnehin ungeeignet. Selbst wenn es aktiviert ist, erhält man nur eine kurzlebige Sandbox: gestartet, Ergebnis wird geliefert, wieder abgebaut. Es ist ein Rechner, kein Ort, um ein Modell zu trainieren, eine Baseline pro Sensor zu erstellen oder einen Livestream zu beobachten. Und es läuft im Blindflug – der Code wird bei jedem Aufruf neu geschrieben, importiert, was gerade im Sandbox-Image vorhanden ist, und wird, sofern keine Infrastruktur zur Protokollierung eingerichtet ist, ohne nachvollziehbare und reproduzierbare Protokollierung ausgeführt. Für eine Zahl, die einen Techniker alarmiert oder einen Sicherheitsalarm auslöst, ist die Aussage „Das LLM hat etwas Python-Code geschrieben, den wir nie überprüft haben“ allein schon disqualifizierend.

Die korrekte Regel lautet also nicht „LLMs können nicht rechnen“. Sie lautet vielmehr: Die Codeausführung ermöglicht einem LLM zwar Berechnungen, aber sie erlaubt ihm nicht, ein generalisierbares Modell zu lernen, Zustände über Hunderte von Datenströmen hinweg zu speichern oder einen Datenstrom in Echtzeit zu bewerten. Das ist die Grenze – und genau diese Grenze überschreiten die fünf folgenden Eingabeaufforderungen.

Die eigentliche Trennlinie: Berechnen vs. Lernen

ML lernt ein generalisierbares Modell; das LLM interpretiert das Ergebnis in Sprache. Die Codeausführung ermöglicht dem LLM Berechnungen – sie lässt es nicht lernen.

Maschinelles Lernen (ML) für Schlussfolgerungen, logisches Lernen (LLM) für das Schlussfolgern.

ML ist das richtige Werkzeug, wenn die Frage lautet: „Wie hoch ist die Zahl?“ – eine Prognose, ein Anomaliewert, eine Schätzung der verbleibenden Nutzungsdauer, eine Klassenbezeichnung. LLM ist das richtige Werkzeug, wenn die Frage lautet: „Was sollen wir mit der Zahl anfangen?“ – sie erklären, priorisieren, die Nachricht formulieren, den nächsten Schritt festlegen, das passende Werkzeug einsetzen.

Drei kurze Plausibilitätsprüfungen:

• Kann ein LLM eine Zeitreihe prognostizieren? Manchmal – und zwar schlecht. Nicht für Produktionsumgebungen, wo Fehlprognosen Geld kosten.
• Kann ein ML-Modell ein Wartungsticket erstellen? Nein. Es gibt eine Zahl zurück. Was diese Zahl im Kontext bedeutet, ist ein sprachliches Problem.
• Benötige ich beides? Für jeden Arbeitsablauf, bei dem ein Mensch involviert ist, ja.

Die Entscheidungsmatrix

Dies ist die Tabelle zum Vergleich von maschinellem Lernen und Learning-Level-Management (ML vs LLM), die wir für IoT und Industrieprojekte immer wieder auf Whiteboards neu zeichnen – wann man traditionelles machine learning, wann ein LLM und wann beides einsetzt. Speichern Sie sie am besten gleich ab.

Wenn Ihre Aufgabe eine Zeile in der linken Spalte ist und Sie nach dem falschen Werkzeug in der mittleren Spalte greifen, ist dieser Artikel genau das Richtige für Sie.

Fünf Aufgaben, die LLMs zum Scheitern bringen

Jedes Beispiel folgt dem gleichen Aufbau: die Eingabeaufforderung, die zum Fehler führt – warum das Ausführen von Python das Problem nicht löst – die Aufgabe des maschinellen Lernens (mit einem Codebeispiel) – die Übergabe, die der Bediener tatsächlich sieht.

4.1 Anomalieerkennung – Vibrationen an einem Pumpenmotor (Fertigung)

Die Frage: Steht diese Pumpe kurz vor dem Ausfall?

Übergibt man die Rohdaten an ein Programm, das ein LLM ausführt, berechnet dieses Mittelwerte, Maxima und eine Standardabweichung. „Kurz vor dem Ausfall“ ist jedoch keine Berechnung, sondern eine Abweichung vom Normalzustand dieser Pumpe, die in einem gelernten Modell beschrieben wird. Das LLM hat diese Pumpe aber noch nie gesehen.

Aufgabe des maschinellen Lernens: Ein Machine-Learning-Modell – ein Isolation Forest – wird anhand von 90 Tagen „normaler“ Schwingungs-RMS-Werte und Lagertemperaturen trainiert. Neue Messwerte werden in Echtzeit ausgewertet.

from sklearn.ensemble import IsolationForest import numpy as np # X_normal: shape (n_samples, 2) — [vibration_rms, bearing_temp] clf = IsolationForest(contamination=0.01, random_state=42) clf.fit(X_normal) # Negative Werte = stärkere Anomalie. Ein Schwellenwert von -0,1 ist für die meisten industriellen Sensoren geeignet. scores = clf.score_samples(X_today) anomalies = X_today[scores < -0.1]

Das Modell liefert einen Wert pro Minute. Es gibt keine Empfehlung, was damit zu tun ist.

Die Aufgabe des LLM. Sobald ein Wert den Schwellenwert überschreitet, ruft der LLM die Arbeitsauftragshistorie für das betreffende Objekt ab, prüft das Datum der letzten Wartung, fragt den Teilebestand ab und verfasst eine Nachricht für den Instandhaltungsleiter.

Die Übergabe, die der Bediener sieht:

„Pumpe P-103 hat um 02:14 Uhr den Grenzwert für Anomalien überschritten. Die letzte Lagerwartung erfolgte vor 7 Monaten – gemäß dem 6-Monats-Wartungsplan überfällig. Es ist kein Ersatzlagersatz vor Ort verfügbar. Wir empfehlen, noch vor dem Morgenlauf einen Techniker in dieser Schicht zu entsenden.“

Das ML-Modell lieferte eine Zahl. Das LLM wandelte diese in eine Entscheidung um. Dieses Muster ist der Kern dessen, was in der intelligenten Fertigung in der Praxis so nützlich macht.

4.2 Prognose – Energiebedarf in einem Gebäude (Heizung, Lüftung, Klimaanlage / Gebäudetechnik)

Die Frage lautet: „Wie viel Energie wird dieses Gebäude morgen verbrauchen?“ Ein Code, der LLM (Late-Level Model) ausführt, führt eine schnelle Regression anhand der eingegebenen Daten durch und liefert einen zuverlässigen, spezifischen Wert zurück – ohne den bisherigen Verbrauch des Gebäudes zu berücksichtigen. Es erkennt das Verbrauchsverhalten anhand von Mustern ,anstatt es vorherzusagen. Dies ist keine Spekulation: Eine Studie von NeurIPS aus dem Jahr 2024 zeigte, dass das Entfernen des LLM aus gängigen LLM-basierten Prognosemethoden die Genauigkeit nicht beeinträchtigte, sondern oft sogar verbesserte.

Aufgabe des maschinellen Lernens. Lag-Features (Tageszeit, Wochentag, Verzögerung 1 Tag, Verzögerung 7 Tage, Temperaturvorhersage) in einen XGBoost-Regressor einbinden – oder in Prophet, falls ein Nicht-ML-Ingenieur die Wartung übernehmen muss.

import xgboost as xgb from sklearn.model_selection import train_test_split # features: hour, dow, lag_1d, lag_7d, temp_forecast X_train, X_test, y_train, y_test = train_test_split(features, target, test_size=0.2) model = xgb.XGBRegressor(n_estimators=200, learning_rate=0.05) model.fit(X_train, y_train) tomorrow_forecast = model.predict(tomorrow_features)

Die Übergabe. Das LLM wandelt die Zahl in eine Anweisung um: „Morgen liegen die Werte 14 % über einem typischen Mittwoch, wahrscheinlich aufgrund der vorhergesagten Hitzewelle. Kühlen Sie das Gebäude zwischen 3 und 5 Uhr morgens vor, um die Last in die Nebenzeiten zu verlagern und die Bedarfsspitzengebühr zu vermeiden.“

4.3 Vorausschauende Instandhaltung – verbleibende Nutzungsdauer (Logistik / Mobilität)

Die Frage lautet: „Bei welchen Lkw muss innerhalb der nächsten 30 Tage die Lichtmaschine ausgetauscht werden?“ Das ist ein Überlebensmodell, das auf historischen Ausfällen und aktuellen Verschleißsignalen – Spannungsdrift, Neustarthäufigkeit, Hitzebelastung – basiert und Anlagen einstuft, die es noch nie zuvor gesehen hat. Ein LLM kann das nicht extrapolieren.

from lifelines import CoxPHFitter import pandas as pd # df: eine Zeile pro Anlage, Spalten = Degradationssignale + 'Dauer' + 'Ereignis' (1 = fehlgeschlagen) cph = CoxPHFitter() cph.fit(df, duration_col='Dauer', event_col='Ereignis') risk_scores = cph.predict_partial_hazard(current_fleet_signals) ranked_fleet = current_fleet_signals.assign(risk=risk_scores).sort_values('risk', ascending=False)

Die Übergabe. Das LLM ordnet die Modellausgabe dem Geschäftskontext der Woche zu – geschäftskritische Routen, Lagerbestände der benötigten Teile, Schichtleiter – und erstellt die fünf wichtigsten Arbeitsaufträge. Das ist der Kern der IoT : Die Rangliste allein wird ignoriert; erst die Rangfolge in Kombination mit der Begründung führt zu den entsprechenden Maßnahmen.

4.4 Klassifizierung — Wasserqualitätsalarme (Versorgungsunternehmen / Umwelt)

Die Frage lautet: „Handelt es sich bei dieser pH-Wert-/Trübungs-/Leitfähigkeitskombination um einen echten Alarm oder um Sensorauschen?“ Die meisten Überwachungssysteme für Wasserinfrastrukturen verwenden immer noch feste Schwellenwerte, die drei- bis fünfmal zu hohe Werte liefern. Ein Klassifikator, der mit ca. 10.000 gekennzeichneten Messwerten trainiert wurde, halbiert die Anzahl der Fehlalarme um mehr als die Hälfte. Die manuelle Kennzeichnung aller 50.000 täglichen Messwerte durch ein LLM ist hingegen nicht konsistent und deutlich teurer als ein Batch-Verfahren, das in Millisekunden Ergebnisse liefert.

from xgboost import XGBClassifier # X: [pH, Trübung, Leitfähigkeit, Stunde des Tages, Sensoralter in Tagen] # y: 1 = echter Alarm, 0 = Rauschen clf = XGBClassifier(n_estimators=100, use_label_encoder=False, eval_metric='logloss') clf.fit(X_train, y_train) p_alarm = clf.predict_proba(X_today)[:, 1]

Die Übergabe. Wenn P(alarm) > 0,7, ruft das LLM vorgelagerte Kontextinformationen ab – aktuelle Niederschläge, Wartungsarbeiten in der Nähe, benachbarte Sensoren – und entscheidet: eine Feldprobe entsenden, ein Ticket öffnen oder es als Rauschen automatisch schließen.

4.5 Freitext → strukturiert — Schichtnotizen des Technikers (diejenige, bei der LLM eindeutig gewinnt)

Die Frage: Was genau steckt hinter Tausenden von unstrukturierten Technikernotizen, die über zwei Jahre hinweg entstanden sind?

Warum maschinelles Lernen hier scheitert: Man bräuchte einen annotierten Trainingsdatensatz, der nicht vorhanden ist, und die Kategorien ändern sich im Laufe der Zeit, da die Geräte altern und neue Fehlermodi auftreten. Ein vor sechs Monaten trainierter überwachter Klassifikator wird den neuen Fehlermodus, der im letzten Quartal erstmals aufgetreten ist, nicht erkennen.

Die Aufgabe des LLM. Null- oder Wenig-Shot-Klassifizierung in eine stabile Kategorienliste – „elektrischer Fehler“, „mechanischer Verschleiß“, „Kommunikationsausfall“, „Benutzerfehler“, „unklar“ – plus Extraktion der Anlagen-ID, des Schweregrades und aller erwähnten Teile.

import anthropic client = anthropic.Anthropic() def parse_note(note_text: str) -> dict: response = client.messages.create( model="claude-sonnet-4-6", max_tokens=256, messages=[{ "role": "user", "content": f"""Klassifiziert diese Technikernotiz. Nur JSON zurückgeben. Notiz: {note_text} Schema: {{ "category": "electrical_fault|mechanical_wear|comms_loss|user_error|unclear", "severity": "low|medium|high", "asset_id": "string or null", "parts_mentioned": ["Liste von Strings"] }}""" }] ) import json return json.loads(response.content[0].text)

Keine Trainingsdaten. Kein Labeling-Sprint. Diese Woche ausliefern.

Die Übergabe verläuft hier in umgekehrter Richtung. Das LLM erzeugt die strukturierten Felder → einfaches SQL (oder ein ML-Modell, falls genügend Zeilen vorhanden sind) aggregiert diese zu einem Pareto-Diagramm der Fehlerkategorien nach Standort, Anlagenklasse und Quartal.

Ehrlichkeitscheck: Wenn Sie bereits 100.000 beschriftete Notizen und eine stabile Kategorisierung haben, optimieren Sie ein kleines Modell – das ist schneller und pro Anruf günstiger. Falls nicht, ist das LLM eindeutig der richtige Ausgangspunkt.

Zwei weitere, die kaputtgehen – aus einem anderen Grund

„Welche meiner 400 Sensoren verhalten sich gerade abnormal?“ Das Problem liegt nicht in der Mathematik, sondern in der schieren 400 und aktuellen Zeitpunkt. Ein LLM bietet keine Möglichkeit, für jeden Sensor einzeln einen Live-Baseline-Wert für 400 Datenströme zu speichern und jeden neuen Messwert damit zu vergleichen. Das erfordert einen persistenten Zustand, und den bietet das LLM nicht.

„Benachrichtige mich sofort, wenn dieser Messwert vom Normalwert abweicht.“ Ein LLM (Local Level Manager) arbeitet nach dem Anfrage-Antwort-Prinzip. Er kann nicht permanent einen MQTT-Stream überwachen und jedes Paket in der Millisekunde auswerten, in der ein Schwellenwert überschritten wird. Das ist nicht nur eine Frage der Schwierigkeit, sondern architektonisch unmöglich – daran ändert auch noch umfangreiche Codeausführung nichts.

Das Architekturmuster

Wenn man alles zusammennimmt, ist das Diagramm unabhängig von der vertikalen Ausrichtung gleich:

Der LLM fungiert als Orchestrator. Die ML-Modelle sind Werkzeuge. Ebenso die Datenbank und Slack. Behandelt man sie alle gleich – als aufrufbare Werkzeuge, die der LLM nutzen kann – bleibt die Architektur übersichtlich, unabhängig von der Anzahl der hinzugefügten Modelle oder Datenquellen. Diese Architektur bildet das Herzstück moderner cloudbasierter SCADA und Industrie-4.0-Systeme . Der Unterschied besteht darin, dass die Verarbeitungsschicht nun ein LLM anstelle einer Regel-Engine ist.

Eines macht dieses Diagramm deutlich: Das LLM greift niemals auf Rohdaten zu. Es arbeitet mit Aggregaten, Scores und Zusammenfassungen, die von den ML- und Datenanalyse-Tools erzeugt werden. Das ist so beabsichtigt. Ein LLM, das eine Zusammenfassung mit 50 Zeilen verarbeitet, ist schnell, ressourcenschonend und zuverlässig. Ein LLM, das auf 50.000 Rohdatenzeilen zugreift – selbst wenn es mit eigenem Python-Skript arbeitet – ist langsam, aufwändig und zustandslos: Es berechnet bei jedem Aufruf von Grund auf neu, anstatt ein Modell abzufragen, das das Muster bereits gelernt hat.

Anti-Muster

1. Die Verwendung von SQL-Abfragen durch den LLM für große Tabellen ist problematisch. SQL-Abfragen kann der LLM problemlos ausführen. Schwierigkeiten bereitet die Ausführung komplexer Abfragen für 25.000 Zeilen und die anschließende Rückgabe aller Ergebnisse an das Kontextfenster – dies ist langsam, aufwändig und fehleranfällig. Daher empfiehlt es sich, die Daten zunächst mit einem Tool für vorbereitete Ansichten zu aggregieren, das die Rohdaten auf die 50 relevanten Zeilen reduziert. Anschließend kann der LLM die zusammengefassten Daten verarbeiten.

2. Geschäftsregeln in das ML-Modell integrieren. Wenn das Modell darauf trainiert ist, einen Messwert gemäß Ihren aktuellen SLA-Schwellenwerten als Alarm zu kennzeichnen , führt jede Schwellenwertänderung zu einem erneuten Training. Speichern Sie Geschäftsregeln in der LLM-Prompt-Ebene, wo die Bearbeitung eine einzelne Zeile Code erfordert und keinen erneuten Trainingszyklus auslöst.

3. Eine Demo als Machbarkeitsnachweis zu behandeln, ist problematisch. Die Demo lief mit 10 fehlerfreien Datenpunkten in einem Notebook. In der Produktionsumgebung gibt es 10.000 Datenpunkte, fehlende Zeitstempel, doppelte Messwerte und Sensoren, die drei Tage lang ausfallen und dann veraltete Werte liefern. Eine trainierte Pipeline kommt damit zurecht; eine Eingabeaufforderung – selbst mit einer Code-Sandbox – nicht, da sie nie gelernt hat, wie ein fehlerfreies Signal aussieht.

Häufig gestellte Fragen

Können LLMs nicht einfach Python ausführen – wozu brauche ich dann ML? Die Codeausführung behebt Berechnungen, nicht das Lernen. Und ML ist meist gar nicht im Einsatz: Über die API ist es ein optionales Tool, das die meisten Agentenplattformen nie integrieren. Selbst wenn es vorhanden ist, handelt es sich um eine temporäre Testumgebung – es kann kein generalisierendes Modell trainieren, den Zustand pro Datenstrom speichern oder in Echtzeit bewerten, und sein frischer, nicht festgelegter, nicht-deterministischer Code ist nicht so überprüfbar wie ein Produktionsmodell. Ein LLM kann Berechnungen mit den ihm übergebenen Daten durchführen; es kann aber nicht das Modell selbst sein

Wann sollte ein KI-Agent maschinelles Lernen (ML) anstelle eines logischen Lernmodells (LLM) verwenden?
Immer dann, wenn die Aufgabe darin besteht, eine Zahl zu erzeugen. Prognosen, Anomalieerkennung, Klassifizierung und die Schätzung der Restnutzungsdauer sind allesamt ML-Aufgaben. Ein LLM kann – selbst in einer Code-Sandbox – zwar einen einmaligen Wert berechnen, aber es kann nicht als Modell dienen: Es kann kein generalisierbares Muster lernen, keinen Zustand speichern oder in Echtzeit arbeiten.

Kann ein LLM Zeitreihenprognosen erstellen?
In begrenztem Umfang ja – für sehr kurze Zeithorizonte und einfache Muster kann ein LLM mit einem Aufruf eines statistischen Modells scheinbar Prognosen erstellen. Es erstellt die Prognosen aber nicht selbst, sondern ruft lediglich das Modell auf. Wenn man ein einfaches LLM bittet, eine Zahlenfolge aus dem Kontext zu extrapolieren, liefert es zwar überzeugend klingende, aber statistisch falsche Ergebnisse. Verwenden Sie dies nicht im Produktivbetrieb.

Kann ein LLM Anomalien erkennen?
Nicht zuverlässig. Anomalieerkennung erfordert ein gelerntes Modell des „normalen“ Verhaltens, das auf historischen Daten basiert – eine Verteilung, eine Basislinie, ein Schwellenwert, der auf Ihre spezifische Ausrüstung kalibriert ist. Ein LLM verfügt über kein solches Modell Ihrer spezifischen Ausrüstung. Es kann einen Anomaliewert erst dann interpretieren, wenn ein ML-Modell einen solchen berechnet hat.

Was ist der Unterschied zwischen einem KI-Agenten und einem machine learning Modell?
Ein ML-Modell ist eine Funktion: Es verarbeitet strukturierte Eingaben und gibt eine Zahl oder eine Kategorie zurück. Ein KI-Agent hingegen ist ein Orchestrator: Er nimmt ein Ziel entgegen, entscheidet, welche Tools (darunter ML-Modelle, Datenbanken, APIs und Messaging-Dienste) aufgerufen werden, interpretiert die Ergebnisse und leitet entsprechende Maßnahmen ein. Ein Agent ohne ML-Tools ist ein Chatbot. Ein ML-Modell ohne Agent ist ein dashboard , das niemand liest.

Muss ich mein ML-Modell neu trainieren, wenn sich Geschäftsregeln ändern?
Nein – und das ist einer der am meisten unterschätzten Vorteile der zweischichtigen Architektur. Geschäftsregeln (Schwellenwerte, SLAs, Eskalationslogik, kundenspezifische Richtlinien) gehören in die LLM-Prompt-Schicht. Sie liegen als Klartext vor und lassen sich in Sekundenschnelle ändern. Ein erneutes Training ist erst dann erforderlich, wenn sich die zugrunde liegende Signalverteilung ändert – beispielsweise bei neuer Ausrüstung, neuen Fehlermodi oder neuen Betriebsbedingungen.

Kann die Feinabstimmung eines LLM ein ML-Modell bei numerischen Aufgaben ersetzen?
Fast nie. Die Feinabstimmung lehrt das LLM, Text zu erzeugen, der dem korrekten numerischen Ergebnis ähnelt . Sie lehrt es jedoch nicht, Berechnungen durchzuführen. Für produktive Anwendungen, bei denen numerische Genauigkeit wichtig ist – wie Prognosen, Anomalieerkennung oder Klassifizierung –, ist ein gut abgestimmtes scikit-learn-Modell mit sauberen Merkmalen einem feinabgestimmten LLM überlegen, läuft schneller, ist kostengünstiger und einfacher zu überprüfen.

Noch etwas

Dieses Muster – KI im IoT richtig umgesetzt – findet sich immer wieder in unseren Ubidots. Unsere KI-Agenten bilden die LLM-Orchestrierungskomponente, und UbiFunctionermöglicht es Ihnen, Ihre eigenen Python-Anwendungen – scikit-learn, XGBoost, pvlib, Ihr eigenes trainiertes Modell – als aufrufbares Tool zu verwenden. Die Architektur entspricht der obigen Abbildung; wir stellen Ihnen lediglich die Laufzeitumgebung und die bereits integrierten Sensordaten zur Verfügung – eine dauerhafte, nachvollziehbare Umgebung, die eine kurzlebige LLM-Sandbox niemals bieten kann.