AI-Agenten sollten Modelle aufrufen

Das MLAT-Paper beschreibt einen Produktionspiloten, in dem ein Agent ein XGBoost-Preismodell als Tool aufruft, auf zurückgehaltenen Daten R^2 = 0.807 erreicht, einen mittleren absoluten Fehler von 3688 USD ausweist und die Angebotserstellung von mehreren Stunden auf unter 10 Minuten verkürzt.¹

Der nützliche Gedanke ist nicht das konkrete Preismodell. Entscheidend ist die Grenze: Wenn eine Aufgabe einen Score, eine Prognose, einen Preis, eine Risikoeinschätzung, ein Ranking, einen Klassifikator oder einen Detektor braucht, sollte der Agent das Modell aufrufen, das für genau diese Aufgabe trainiert wurde. Er sollte keine statistische Antwort in flüssiger Prosa improvisieren.

Ein trainiertes Modell gehört in das Tool-Register des Agenten. Das LLM kann entscheiden, wann es aufgerufen wird, das Ergebnis erklären, fehlende Eingaben anfordern und Ausnahmen weiterleiten. Das angepasste Modell sollte die numerische Schätzung, das Vertrauenssignal, die versionierte Ausgabe und die nachvollziehbare Belegspur erzeugen.

Kurzfassung

LLM-Agenten eignen sich gut für Orchestrierung. Statistische Modelle und Machine-Learning-Modelle sind bei klar begrenzten Vorhersagen oft besser. Das Muster Machine Learning as a Tool behandelt ein angepasstes ML-Modell als aufrufbares Tool innerhalb eines Agentenarbeitsablaufs, neben Suche, Datenbanken, APIs und anderen Tools.¹

Daraus ergibt sich für Teams eine klare Betriebsregel: Der Agent koordiniert die Arbeit, spezialisierte Modelle übernehmen spezialisierte Inferenz. Das Ergebnis sollte Modellversion, Eingabeschema, Ausgabeschema, Kalibrierungshinweise und einen nachvollziehbaren Aufrufdatensatz enthalten. Ohne diese Grenze kann das LLM sicher klingen und dabei stillschweigend ein Modell durch eine Schätzung ersetzen.

Zentrale Punkte

• Für Agentenentwickler: Stellen Sie trainierte Modelle als typisierte Tools mit Schemas, Versionen und Fehlermodi bereit.
• Für ML-Teams: Behandeln Sie den Agenten als Aufrufer, nicht als Ersatz für Modellevaluierung, Persistenz oder Registerdisziplin.
• Für Produktteams: Zeigen Sie, ob eine Zahl aus einem Modellaufruf, einer Regel, einer Datenbank oder einer LLM-Erklärung stammt.
• Für Sicherheitsteams: Wenden Sie dieselbe Logik begrenzter Befugnisse aus Agentenschlüssel brauchen Risikobudgets auf Modell-Tools an.
• Für Reviewer: Verlangen Sie Modellaufruf, Modellversion, Eingaben, Ausgabe und Vertrauensgrenzen, bevor Sie der Antwort vertrauen.

Warum sollten Agenten Modelle aufrufen, statt sie nachzuahmen?

Ein LLM kann über einen Preis sprechen. Ein Preismodell kann ihn aus den Merkmalen schätzen, die es gelernt hat. Ein LLM kann Risiko zusammenfassen. Ein Risikomodell kann Risiko anhand eines getesteten Merkmalsatzes bewerten. Ein LLM kann Abwanderung beschreiben. Ein Churn-Modell kann eine Wahrscheinlichkeit zurückgeben, die an einen Trainingsprozess gebunden ist.

Das sind unterschiedliche Aufgaben.

Agenten-Tools machen diese Trennung bereits möglich. OpenAIs Agents SDK dokumentiert Function Tools mit JSON Schema-Parametern, Handlern für Tool-Aufrufe und strukturierter Tool-Ausgabe.² Die Tool-Use-Dokumentation von Anthropic beschreibt, wie Claude clientseitige Tools und externe Funktionen mit durch JSON Schema definierten Eingaben aufruft.³ Der Agent kann eine Modellvorhersage über dasselbe Tool-Muster anfordern, das er für Suche, Kalenderaktualisierungen, Shell-Befehle oder Datenbankabfragen nutzt.

Der zentrale Fehlermodus entsteht, wenn Teams diese Trennung überspringen. Sie fragen das LLM nach einer Schätzung, weil das LLM eine liefern kann. Die Antwort kommt schnell. Die Prosa wirkt plausibel. Die Oberfläche zeigt nicht erkennbar, dass die Zahl aus Mustervervollständigung stammt und nicht aus einem angepassten Schätzer.

Das ist ein schwacher Vertrag. Der Benutzer weiß nicht, wodurch das Ergebnis entstanden ist. Der Reviewer kann weder Modellversion noch Eingabemerkmale prüfen. Der Betreiber kann den Aufruf nicht erneut abspielen. Das Produkt kann nicht erklären, warum sich die Antwort geändert hat.

Die Belegschwelle gilt auch hier: Zuversicht ist kein Beleg. Ein Modellaufruf kann Belege erzeugen. Eine Prosaschätzung meist nicht.

Was ergänzt das MLAT-Muster?

MLAT steht für Machine Learning as a Tool. Das Paper beschreibt ein trainiertes ML-Modell als erstklassiges Tool, das ein LLM-Agent aufrufen kann, wenn die Unterhaltung eine quantitative Schätzung braucht.¹

Das Pilotsystem des Papers, PitchCraft, verwendet zwei Agenten. Ein Rechercheagent sammelt Interessentenkontext über parallele Tool-Aufrufe. Ein Entwurfsagent ruft ein XGBoost-Preismodell auf und schreibt anschließend über strukturierte Ausgaben ein Angebot.¹ Das ML-Modell übernimmt die Preisfindung. Das LLM übernimmt Kontext, Zusammenstellung und Erklärung.

Diese Trennung ist wichtig, weil sie zwei schlechte Designs vermeidet:

Der Agent bleibt wichtig. Er kann erkennen, wann Preiseingaben unvollständig sind. Er kann einen Benutzer nach fehlenden Feldern fragen. Er kann vor dem Modellaufruf Suche oder CRM-Tools nutzen. Er kann erklären, dass die Schätzung von einem Modell stammt und nicht aus seiner eigenen Autorität.

Das ist die richtige Arbeitsteilung: Das LLM orchestriert; das angepasste Modell sagt vorher.

Was sollte ein Modell-Tool zurückgeben?

Ein Modell-Tool sollte keine nackte Zahl zurückgeben. Ein seriöses Modell-Tool sollte ein Belegobjekt zurückgeben.

Diese Ausgabeform macht Modell-Tools kompatibel mit Agenten-Ausführungsspuren sind der Laufzeitvertrag. Wenn ein Agent ein Preismodell aufruft, sollte die Spur den Modellaufruf zeigen. Wenn ein Agent das Modell überspringt und trotzdem eine Zahl schreibt, sollte die Spur diese Lücke sichtbar machen.

Dieselbe Logik stützt Review-Pakete sind die neue finale Antwort. Eine finale Antwort mit einem Preis ist schwach. Eine finale Antwort mit Modellaufrufdatensatz, Modellversion, Merkmalsmomentaufnahme und Vertrauenshinweis gibt dem Reviewer etwas Prüfbares.

Wo passen Modellregister hinein?

Tool-Wrapping ersetzt MLOps nicht. Es macht MLOps für die Agentenausführungsumgebung sichtbar.

Die Dokumentation zum Modellregister von MLflow beschreibt Herkunft, Versionierung, Aliasse, Metadaten-Tags und Lebenszyklusinformationen für Modelle.⁴ Diese Registerebene ist wichtig, weil ein Agentenarbeitsablauf eine Modellversion nur zitieren kann, wenn die Plattform Versionen überhaupt nachverfolgt.

Die Dokumentation von scikit-learn zur Modellpersistenz macht von der Bereitstellungsseite her einen verwandten Punkt: Persistenzentscheidungen bringen Sicherheits- und Portabilitätskompromisse mit sich, und ONNX kann Modelle ohne Python-Umgebung bereitstellen, während pickle-basierte Wege Vertrauen in die Quelle voraussetzen.⁵ Ein Modell-Tool sollte kein unsicheres Modellartefakt in einen Agenten schmuggeln, nur weil der Agent eine Vorhersage angefordert hat.

Der minimale Betriebsstapel sieht so aus:

Teams legen diese Ebenen oft in einem einzigen Endpunkt namens predict zusammen. Für Demos reicht diese Abkürzung. Sie scheitert, sobald der Agent Vorhersagen in Kunden-E-Mails, Verkaufsangebote, Underwriting-Notizen, Infrastrukturpläne oder Entwürfe für medizinische Triage verkettet.

Das Produkt braucht einen Modellvertrag, keinen magischen Endpunkt.

Wie sollten Produkte Modellausgaben anzeigen?

Die UI sollte dem Benutzer zeigen, wenn eine Antwort von einem Modell-Tool stammt.

Schlechte Oberflächentexte verschleiern die Herkunft:

Bessere Texte benennen den Produktionspfad:

Diese Unterscheidung schützt die Würde des Benutzers. Benutzer sollten nicht raten müssen, ob eine Zahl aus einem getesteten Modell, einer Model Card, einer Geschäftsregel oder einer Sprachmodellvervollständigung stammt. Agentisches Design ist Gestaltung von Kontrollflächen argumentiert, dass Agentenprodukte Oberflächen für Aufsicht und Steuerung brauchen. Modellherkunft ist eine dieser Oberflächen.

Model Cards helfen auf der Dokumentationsebene beim selben Problem. Das Model-Cards-Paper schlägt strukturierte Berichte zu Modelleigenschaften, beabsichtigter Nutzung, Metriken und Evaluierungskontext vor.⁶ Agentenoberflächen können diese Idee zur Laufzeit übernehmen: Jede Modellantwort sollte genug Kontext enthalten, damit ein Benutzer oder Reviewer versteht, welche Art von Aussage das Modell gemacht hat.

Was sollten Agenten verweigern?

Ein modellbewusster Agent sollte mehrere verlockende Abkürzungen verweigern.

Er sollte verweigern, eine Modellausgabe zu erfinden, wenn das Modell-Tool nicht verfügbar ist. Er kann sagen, dass das Preismodell fehlgeschlagen ist. Er kann fragen, ob der Benutzer eine grobe, menschlich gekennzeichnete Schätzung möchte. Er sollte das Modell nicht stillschweigend ersetzen.

Er sollte verweigern, den Gültigkeitsbereich des Modells ohne Belege auszuweiten. Ein Churn-Modell, das auf Mid-Market-SaaS-Daten trainiert wurde, wird nicht zum universellen Orakel für Unternehmensgesundheit, nur weil der Prompt freundlich darum bittet.

Er sollte verweigern, Unsicherheit zu verstecken. Wenn ein Modell ein Intervall zurückgibt, sollte die Antwort dieses nicht in eine einzelne selbstsichere Zahl zusammendrücken, sofern das Produkt dafür keine klare Darstellungsregel hat.

Er sollte verweigern, ein Modell-Tool mit fehlenden oder erfundenen Merkmalen aufzurufen. Der Agent kann Eingaben sammeln, Rückfragen stellen oder Felder als unbekannt markieren. Er sollte den Merkmalsvektor nicht mit bequemer Fiktion füllen.

Er sollte verweigern, Modellautorität als Handlungsautorität zu behandeln. Ein Modell kann Betrugsrisiko schätzen. Das heißt nicht, dass der Agent ein Konto sperren darf. Die Handlung braucht weiterhin die Disziplin begrenzter Schlüssel aus Agentenschlüssel brauchen Risikobudgets.

Die Entscheidungsregel

Nutzen Sie diese Regel beim Aufbau eines Agentenarbeitsablaufs:

Diese Regel gibt dem LLM eine wertvolle Aufgabe, ohne ihm zu erlauben, jedes andere System nachzuahmen. Es kann den Arbeitsablauf koordinieren, Ausgaben erklären, die Nachricht entwerfen und bessere Fragen stellen. Es kann nicht zum Preismodell, Risikomodell, Betrugsmodell, Ranking-Modell oder Policy Engine werden, nur weil es flüssig klingt.

Die besten Agentenprodukte werden nicht ein Modell bitten, so zu tun, als wäre es das ganze Unternehmen. Sie werden eine Tool-Oberfläche bauen, auf der jedes System die Aufgabe erledigt, die es belegen kann.

FAQ

Gilt das nur für klassische Machine-Learning-Modelle?

Nein. Dasselbe Muster gilt für jeden spezialisierten Schätzer oder Scorer: Gradient-Boosting-Modelle, Klassifikatoren, Ranking-Systeme, Prognosemodelle, Regel-Engines, Retrieval-Scorer und domänenspezifische Detektoren. Entscheidend ist nicht der Algorithmus. Entscheidend ist der Vertrag rund um die Ausgabe.

Warum das LLM nicht direkt schätzen lassen?

Manchmal reicht eine grobe qualitative Schätzung. Ein Produkt sollte das klar sagen. Wenn der Benutzer einen Preis, einen Risikoscore, eine Prognose oder eine Berechtigungsentscheidung braucht, sollte die Antwort aus einem getesteten Modell- oder Regelpfad mit nachvollziehbaren Eingaben und Grenzen stammen.

Macht ein Modell-Tool die Antwort automatisch korrekt?

Nein. Ein Modell-Tool kann trotzdem veraltet, verzerrt, falsch kalibriert, falsch verwendet oder außerhalb seines gültigen Bereichs sein. Das Modell-Tool verbessert die Prüfbarkeit. Es ersetzt nicht Evaluierung, Monitoring und menschlichen Review.

Was ist der minimal tragfähige Modell-Tool-Vertrag?

Beginnen Sie mit Eingabeschema, Ausgabeschema, Modellversion, Vorhersage, Vertrauenssignal oder Einschränkung, Fehlerform, Timeout und Spur-ID. Ergänzen Sie Merkmalsnamen, Registerlink, Model-Card-Verweis und Kalibrierungshinweise, wenn das Modell Geld, Zugang, Sicherheit oder kundenwirksame Entscheidungen betrifft.

Wie verändert das die Agenten-UX?

Die Oberfläche sollte die Quelle wichtiger Ausgaben kennzeichnen. Benutzer sollten sehen, ob eine Antwort aus einem Modellaufruf, einem abgerufenen Dokument, einer Geschäftsregel, einer menschlichen Freigabe oder LLM-Synthese stammt. Diese Herkunft verändert, wie viel Vertrauen die Antwort verdient.

Quellen