Hauptgedanke

JSON in CSV umwandeln, einen Index neu nummerieren, ein Frontmatter abschreiben, eine Liste sortieren: Diese Vorgänge haben ein eindeutiges Ergebnis, das sich aus ihren Eingaben ableiten lässt. Überlässt man sie dem Modell, laufen sie über den teuersten Kanal — die Generierung — und bringen obendrein eine Schwankung mit, die niemand brauchte. Überlässt man sie einem Skript, kosten sie null Tokens und laufen in Millisekunden.

Bei competitor_analyze haben zwei nach Python verlagerte Schritte — das Schreiben der Frontmatter-Blöcke und die Berechnung des Index-Deltas — 111 000 Einheiten aus dem Verbrauch entfernt, ohne an den erzeugten Ergebnissen etwas zu ändern.

Das Kriterium für die Aufteilung ist nicht die Schwierigkeit der Aufgabe, sondern ob ein Urteil gefragt ist: Wenn sich das Ergebnis aus den Eingaben ableiten lässt, gibt es nichts zu entscheiden.

Warum das wichtig ist

Das ergibt eine Schnittregel für den Entwurf eines Skills: Jeder Schritt fragt sich, was er vom Modell erwartet, und ein Schritt, der keine Abwägung erwartet, hat beim Modell nichts zu suchen.

Der Gewinn ist übrigens nicht nur wirtschaftlich: Was ein Skript erzeugt, ist reproduzierbar, was ein Modell erzeugt, nur ungefähr.

Nuancen und Grenzen

Das Skript zu schreiben und zu pflegen kostet ebenfalls, und das taucht in keinem Token-Bericht auf. Für eine einmalige Transformation, die nie wieder ausgeführt wird, bleibt der Weg über das Modell billiger als der über die Entwicklung.

Und manche Transformationen wirken deterministisch bis zum ersten fehlerhaft formatierten Datensatz — das Modell fängt die Unregelmäßigkeit ab, wo das Skript abbricht.

Offene Fragen

• Wer bemerkt, dass sich in einen als mechanisch eingestuften Schritt ein Urteil eingeschlichen hat, wenn sein Ergebnis doch dieselbe Form behält?