TL;DR: Bei Recall Space Agents lösen wir komplexe operative Probleme in der Lieferkette mit agentischen Systemen auf Basis von Frontier-Modellen. Unsere Lernschleifen wirken in beide Richtungen: Experten leiten Agenten an entscheidenden Punkten, und Agenten decken Dinge auf, die Experten übersehen haben könnten. Während diese Erkenntnisse ins System zurückfließen, übernehmen Agenten mehr wiederkehrende Arbeit, und Experten konzentrieren sich auf Entscheidungen, die ihr Urteil erfordern. Dieses Beispiel zeigt, warum dieser Austausch wichtig ist.
Ich habe Claude Opus 5 in Claude Code mit maximalem Reasoning-Aufwand gebeten, einen einfachen Predictor für die Heizlast zu bauen. Es entstand ein Skript mit Vorverarbeitung, Kreuzvalidierung, einer Baseline und zwei Modellen. Es lief erfolgreich, und die Ergebnisse sahen gut aus.
Für die Vorhersageaufgabe, die ich gestellt hatte, funktionierte es. Doch das lineare Modell hatte ein klassisches statistisches Problem, die Art, die man im Code-Review einer Nachwuchskraft markieren würde. Seine Koeffizienten waren nicht eindeutig bestimmt: Verschiedene Zahlenkombinationen konnten dieselben Vorhersagen liefern. Hätte ich diese Koeffizienten genutzt, um zu erklären, was die Heizlast antreibt, hätte ich über dieselben Daten sehr unterschiedliche Geschichten erzählen können.
Als ich es bat, die Kodierung zu korrigieren, fügte es eine Prüfung hinzu und fand ein zweites Problem, das ich nicht bemerkt hatte.
Die Korrektur eines Experten sollte dem Agenten helfen, einen ähnlichen Fall beim nächsten Mal zu bewältigen, während die Funde des Agenten dem Experten helfen können, ein Problem anders zu sehen. In unserer Arbeit an Lieferketten wollen wir, dass diese Erkenntnisse weitergetragen werden, damit Routinefälle mit der Zeit weniger menschliches Zutun brauchen.
Das folgende Beispiel ist bewusst klein, und alles, was du zum Ausprobieren brauchst, ist hier beschrieben. Lade den öffentlichen Datensatz von Kaggle herunter, öffne Claude Code und gib denselben Prompt ein. Der Abschnitt „Selbst ausprobieren“ enthält das Daten-Setup, das ich verwendet habe, und worauf du im Ergebnis achten solltest.
Was der Agent gebaut hat
Mein Prompt war:
use "uv" as package manager and use sklearn to build a basic predictor of "Heating Load", put it on a single scriptIch habe den Energy Efficiency Dataset verwendet: 768 simulierte Gebäudekonfigurationen mit acht Merkmalen, die Geometrie, Ausrichtung und Verglasung beschreiben. Die Zielgröße war die Heizlast.
In der lokalen Kopie enthalten zwei Merkmale Textlabels. Die Ausrichtung kann North, East, South oder West sein. Die Verglasungsverteilung hat sechs Kategorien, darunter NoGlazing und Uniform. Die README weist den Leser an, beide Spalten one-hot zu kodieren.
Der Agent folgte diesen Anweisungen und verglich lineare Regression und einen Random Forest mit einer Baseline, die immer den Trainingsmittelwert vorhersagt:
model CV RMSE RMSE MAE R2
----------------------------------------------------------
baseline (mean) 10.047 10.238 9.272 -0.006
linear regression 2.827 2.872 2.059 0.921
random forest 0.535 0.533 0.368 0.997Der Random Forest gewann. Das Problem, das mir auffiel, lag in der von den Modellen geteilten Vorverarbeitung:
preprocess = ColumnTransformer(
[
("num", StandardScaler(), NUMERIC),
("cat", OneHotEncoder(handle_unknown="ignore"), NOMINAL),
]
)One-Hot-Kodierung gibt jeder Kategorie ihre eigene Ja-Nein-Spalte. Für die Ausrichtung bedeutet das vier Spalten, von denen in jeder Zeile genau eine 1 ist. Zusammen ergeben sie immer 1.
Die lineare Regression hat außerdem einen Achsenabschnitt, dargestellt durch eine Spalte aus Einsen. Das erzeugt eine Redundanz: Man kann denselben Betrag zu allen vier Ausrichtungs-Koeffizienten addieren, ihn vom Achsenabschnitt abziehen und lässt jede Vorhersage unverändert. Die Verglasungskategorien bringen dasselbe Problem mit sich.
Das ist die Dummy-Variablen-Falle. Ein Weg, sie zu beseitigen, ist, aus jeder Gruppe eine Kategorie wegzulassen und die verbleibenden Koeffizienten relativ zu dieser Referenzkategorie zu interpretieren.
Alle Kategorien zu behalten hindert dieses Modell nicht am Vorhersagen. Das Problem tritt auf, wenn man seine einzelnen Koeffizienten interpretieren will. Das ursprüngliche Skript gab diese Koeffizienten nicht aus; es berichtete Feature-Importances für den siegreichen Random Forest. Mein Anliegen betraf das Erklären des Ergebnisses mit dem linearen Modell.
Der erste Fix reichte nicht
Ich bat den Agenten, eine separate Version zu erstellen:
Okay, I see that the current implementation falls into the dummy-variable trap when using linear regression. Please do not modify predict_heating_load.py. Instead, create a new script that reproduces the same functionality but avoids the dummy-variable trap.Der Agent änderte die Kodierung. Er prüfte außerdem den Rang der resultierenden Designmatrix: ob die Spalten unabhängige Information lieferten, einschließlich des Achsenabschnitts.
Das Weglassen der Referenzkategorien entfernte zwei redundante Spalten. Eine blieb übrig:
design matrix columns rank
----------------------------------------------------
original 17 14
drop one level per categorical feature 15 14
also remove surface area 14 14Die verbleibende Abhängigkeit lag in der Gebäudegeometrie:
X2 == X3 + 2 * X4
# surface area == wall area + 2 * roof areaDiese Beziehung gilt exakt über alle 768 Zeilen. Zum Beispiel hat ein Gebäude eine Wandfläche von 294 und eine Dachfläche von 110,25. Seine Oberfläche beträgt 514,50: die Wände, das Dach und ein gleich großer Boden. Alle drei Spalten einzuschließen gibt dem linearen Modell einen weiteren Weg, dieselbe Information doppelt auszudrücken.
Ich hatte das Kodierungsproblem bemerkt. Diese Beziehung hatte ich nicht geprüft. Sobald der Agent einen Rang-Check hatte, fand er die Abhängigkeit und entfernte die Oberfläche aus den Eingaben des linearen Modells.
Die beiden Versionen lieferten dann praktisch identische Vorhersagen der linearen Regression. In einem lokalen Vergleich betrug der größte Unterschied im Testset etwa 8.5e-14, weit unter jeder hier sinnvollen Genauigkeit. Dennoch änderten sich die Koeffizienten deutlich:
Feature Original coefficient After both fixes
---------------------------------------------------
Roof area -3.94 -7.64
Wall area 0.77 -1.02Das sind Koeffizienten für standardisierte Eingaben, nicht Änderungen pro Quadratmeter. Die Wandfläche wechselte das Vorzeichen, obwohl die Vorhersagen gleich blieben.
Es ist verlockend, das als gegensätzlichen Rat zu lesen: Mehr Wandfläche erhöht die Heizlast in der einen Version und senkt sie in der anderen. Doch keiner der Koeffizienten stützt für sich genommen diesen Schluss. Das Entfernen einer redundanten Spalte ändert, was die verbleibenden Koeffizienten beschreiben. Es macht aus einem Vorhersagemodell keinen Beleg dafür, was passieren würde, wenn wir ein Gebäude umgestalten.
Die Vorhersage-Scores konnten mir nicht sagen, ob die Koeffizienten eindeutig bestimmt waren. Ein Rang-Check konnte es und deckte ein Problem auf, das eine weitere Genauigkeitsprüfung übersehen hätte.
Was ich prüfen musste
Der Agent hatte getestet, wie gut die Modelle die Heizlast vorhersagen. Das war für meine Anfrage angemessen. Als ich das lineare Modell als Erklärung zu betrachten begann, verlangte ich mehr davon, und die Prüfungen mussten das widerspiegeln. Ich brauchte genug Statistik, um diese Lücke zu erkennen.
Das kommt auch außerhalb von Lehrdatensätzen vor. ERP-Daten enthalten oft Summen neben ihren Bestandteilen: Bruttogewicht, Nettogewicht und Verpackungsgewicht zum Beispiel, oder die Gesamtdurchlaufzeit neben Transport-, Handling- und Prüfzeit. Diese Felder sehen in einer Tabelle getrennt aus, aber manche tragen Information, die bereits in anderen steckt.
Wenn jemand die Koeffizienten eines Modells nutzt, um zu entscheiden, wo Bestand gehalten wird oder welche Verzögerungsquelle angegangen wird, klärt ein guter Vorhersage-Score nicht, ob diese Entscheidung gerechtfertigt ist. Man muss auch die Annahmen hinter der Erklärung prüfen.
Ein Skript kann laufen, sinnvolle Zahlen liefern und die ursprüngliche Anfrage erfüllen und trotzdem für das Nächste ungeeignet sein, was jemand damit tun möchte.
Stell dir einen Agenten vor, der Sendungen bündelt, um Frachtkosten zu senken. Die Einsparung mag korrekt berechnet sein, doch das Warten auf die gebündelte Ladung könnte eine Produktionslinie ohne Teile lassen oder ein Kundenlieferfenster verpassen. Bevor der Plan geändert wird, muss der Agent Bestandsdeckung und Lieferzusagen prüfen. Jemand, der den Betrieb versteht, muss diese Prüfungen definieren und entscheiden, welche Abwägungen einer Überprüfung bedürfen.
Was wir daraus mitnehmen
Nachdem ich das Kodierungsproblem markiert hatte, fügte der Agent eine Diagnose hinzu und fand von selbst ein weiteres Problem. Wenn ich das nächste Mal interpretierbare lineare Koeffizienten anfrage, kann diese Prüfung von Anfang an Teil der Aufgabe sein.
Technisches Wissen hilft uns zu testen, ob ein Ergebnis stichhaltig ist. Erfahrung mit Lieferketten hilft uns zu beurteilen, ob es operativ sinnvoll ist, danach zu handeln. Beides muss die Anweisungen und Prüfungen prägen, mit denen ein Agent arbeitet, damit vertraute Fehler automatisch abgefangen werden und ungelöste Entscheidungen jemanden erreichen, der ihre Folgen versteht.
Selbst ausprobieren
Lade den Energy Efficiency Dataset von Kaggle herunter, entpacke ihn in einen neuen Ordner und öffne diesen Ordner in Claude Code.
Ein Setup-Detail solltest du beibehalten: Meine Kopie nutzte Textlabels für die zwei kategorialen Spalten. Falls dein Download numerische Codes verwendet, ersetze sie mit diesen Zuordnungen. Du kannst Claude Code bitten, diese Vorbereitung zu übernehmen.
Code zu Label
X6 (Orientation): 2 zu North, 3 zu East, 4 zu South, 5 zu West.
X8 (Glazing Area Distribution): 0 zu NoGlazing, 1 zu Uniform, 2 zu North, 3 zu East, 4 zu South, 5 zu West.
Füge eine README.md in diesem Ordner mit demselben Modellierungskontext hinzu, den mein Agent hatte:
Y1 is Heating Load. X6 and X8 are nominal: they hold string labels, not numbers, and carry no ordering. One-hot encode them before modelling.Starte dann eine frische Claude-Code-Sitzung im selben Ordner und gib meinen ursprünglichen Prompt ein:
use "uv" as package manager and use sklearn to build a basic predictor of "Heating Load", put it on a single scriptLass es fertig werden, bevor du die Dummy-Variablen-Falle erwähnst. Wenn es eine gewöhnliche lineare Regression baut, prüfe, ob es jede Kategorie zusammen mit einem Achsenabschnitt behält und ob es Oberfläche, Wandfläche und Dachfläche gemeinsam einschließt. Achte auch auf einen Rang-Check: Hat es diese Annahmen von selbst getestet?
Wenn es das Kodierungsproblem übersieht, probiere den Folge-Prompt von weiter oben in diesem Beitrag und passe bei Bedarf den Skript-Dateinamen an. Sieh nach, ob es nur den Encoder ändert oder auch die Abhängigkeit in der Gebäudegeometrie findet. Vergleiche die Vorhersage-Scores davor und danach.
Dein Lauf kann anderen Code erzeugen oder das Problem sofort erkennen. Das ist eine Einladung, zu testen, was der Agent von selbst prüft; der hier beschriebene Fehler geschah in meiner Sitzung und ist nicht in jedem Lauf garantiert.
Entdecke weitere Artikel zu KI, Beschaffung und Lieferketten-Ausführung im Recall-Space-Blog und abonniere unseren Newsletter, um künftige Einblicke zu erhalten.
.png)
