Charles AZAM testete zwei KI-Modelle mit einem kniffligen Optimierungsproblem. Die Frage: Hilft der native /goal-Befehl, bessere Lösungen zu finden, oder ist er hinderlich? Die Ergebnisse zeigen, wann der Befehl nützt und wann er schadet.
Das Problem: Ein Netzwerk aus Glasfaser
Das Problem heißt KIRO, ein NP-schweres Optimierungsproblem aus der Netzwerkplanung. Es geht darum, in Grenoble, Nizza und Paris Verteilerpunkte und Endgeräte über Glasfaserkabel zu verbinden. Die Lösung muss aus redundanten Schleifen bestehen, die an Verteilerknoten hängen, mit kurzen Abzweigen von Masten. Jeder Mast darf nur einmal vorkommen, die Richtung der Kabel beeinflusst die Kosten. Ziel ist es, die gesamte Kabellänge zu minimieren.
Zur Einordnung: Der Suchraum ist astronomisch groß. Selbst wenn man nur die 532 Endgeräte in Paris auf 11 Verteilerknoten verteilt, gibt es 11^532 mögliche Zuordnungen. Eine konservative Abschätzung ergibt etwa 10^1223 Möglichkeiten. Die Anzahl der Atome im Universum wird auf 10^80 geschätzt.
Der Test: Sechs Modelle, zwei Modi, dreißig Minuten
AZAM ließ jedes Modell 30 Minuten rechnen, einmal im normalen Modus (Plain) und einmal mit aktiviertem /goal-Befehl. Der Befehl signalisiert: „Hier ist dein Ziel: Finde die kürzeste Gesamtkabellänge. Arbeite so lange, bis du es erreicht hast oder die Zeit abläuft.“ Gemessen wurde die Länge der gefundenen Lösung – niedrigere Werte sind besser. Als Benchmark diente AZAMs eigene, in C++ geschriebene Lösung.
Getestet wurden Claude Fable 5, Opus 4.8, Sonnet 5, Terra, Luna und GPT-5.6 Sol. Die Hauptvergleiche konzentrierten sich auf Fable und Sol, von denen jeweils drei vollständige Durchläufe pro Modus vorliegen. Alle Läufe liefen in einer Docker-Umgebung unter Harbor 0.1.43, mit maximaler Reasoning-Stufe und einem Timeout von 1900 Sekunden.
Die Ergebnisse: Fable dominiert, /goal ist ein zweischneidiges Schwert
Die Ergebnisse sind eindeutig: Claude Fable 5 ist GPT auf diesem Problem überlegen. Im Plain-Modus erreichte Fable durchschnittlich 32.386 Meter Gesamtkabellänge, Sol 34.261 Meter – ein Unterschied von fast 1.900 Metern. Fables Ergebnisse schwankten nur um 319 Meter, Sols um fast 2.000 Meter. Fable lieferte nicht nur durchschnittlich bessere, sondern auch verlässlichere Lösungen.
Beim /goal-Vergleich führte der Befehl in vier von sechs Durchläufen zu einer Verbesserung. Doch der Durchschnitt zeigt: Bei Fable stieg die Länge mit Goal um 759 Meter, bei Sol um 868 Meter. In den verbleibenden zwei Läufen gab es massive Verschlechterungen. Bei Fable sprang der Wert in einem Lauf von 32.446 auf 35.178 Meter (plus 2.732 Meter), bei Sol von 33.581 auf 39.371 Meter (plus 5.790 Meter). Der Median bewegte sich leicht in die richtige Richtung. /goal hilft häufig ein bisschen, schadet aber gelegentlich massiv. Die Gewinne sind klein, die Verluste können groß sein.
Warum ist das so? Ein Blick unter die Haube
AZAM untersuchte die Implementierung der /goal-Funktion in Claude Code und Codex. Obwohl der Befehl gleich heißt, steckt unterschiedliche Architektur dahinter. Bei Claude Code wird /goal als separater Evaluator realisiert. Nach jeder Antwort des Hauptmodells prüft ein kleineres Modell (Claude Haiku) anhand des Transkripts, ob das Ziel erreicht ist. Es kann keine Werkzeuge nutzen oder Dateien inspizieren – es sieht nur den Dialog. Bei Codex wird der Zielzustand persistiert und das Modell erhält spezielle Werkzeuge (create_goal, get_goal, update_goal). Das Modell entscheidet selbst, wann das Ziel erreicht ist, und bekommt bei Leerlauf eine Fortsetzungsaufforderung. Diese Architektur ist anfälliger für Fehleinschätzungen und kann dazu führen, dass das Modell zu früh aufgibt oder sich in eine falsche Richtung verbeißt.
Bei Optimierungsproblemen mit riesigen Suchräumen ist es nicht trivial zu erkennen, ob ein weiterer Schritt das Ergebnis verbessert oder verschlechtert. Ein Befehl, der einfach „mach weiter“ sagt, kann einen guten Algorithmus verstärken, aber auch einen schlechten weiter in die Irre führen. Die Qualität der Suchstrategie ist wichtiger als die Anzahl der Wiederholungen.
Was bedeutet das für die Praxis?
Blindes Vertrauen in einen /goal-Befehl ist nicht angebracht. Wenn du eine KI mit einer schwierigen Optimierungsaufgabe betraust, solltest du verstehen, wie der Goal-Mechanismus in deinem System funktioniert. Ein externer Evaluator, der nur den Dialog sieht, kann Fehlentscheidungen des Hauptmodells möglicherweise nicht korrigieren. Ein selbstbewertendes System kann sich in eine Sackgasse manövrieren und Ressourcen unnötig verbrauchen.
Der Benchmark zeigt auch, dass die Modellwahl entscheidend ist. Claude Fable 5 erwies sich auf diesem NP-schweren Problem als robuster und leistungsfähiger als GPT-5.6 Sol – unabhängig vom Goal-Modus. Die Kombination aus einem starken Modell und einer durchdachten Steuerung (ohne künstliche Goal-Vorgabe) führte zu den besten und verlässlichsten Ergebnissen.
KI ist kein Allheilmittel. Selbst fortschrittliche Modelle stoßen bei kombinatorischen Optimierungsproblemen an ihre Grenzen. Der /goal-Befehl ist kein Turbo-Knopf, sondern ein Werkzeug, das je nach Problem und Implementierung sowohl nützen als auch schaden kann. Teste verschiedene Konfigurationen, vertraue auf Konsistenz und sei skeptisch gegenüber Features, die auf den ersten Blick wie ein einfacher Verstärker wirken. Die wahren Helden sind durchdachte Algorithmen und clevere Problemzerlegung – die KI hilft, sie schneller auszuführen, ersetzt aber nicht das Verständnis des Problems.
Quelle: charlesazam.com
