Fable 5 vs. GPT-5.6 Sol: Hilft `/goal` bei NP-schweren Problemen?

 (charlesazam.com)
1 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • In einem 30-minütigen Lauf auf einem unveröffentlichten Glasfasernetz-Optimierungsproblem erzielte Fable 5 die beste Punktzahl und die stabilste Leistung, aber /goal brachte keine konsistente Verbesserung
  • /goal sorgt nicht einfach nur dafür, dass länger gearbeitet wird, sondern verändert Kontrollschleife und Suchpfad, sodass sowohl gute als auch falsche Strategien fortgesetzt werden können
  • /goal gewann 4 von 6 Vergleichen zwischen Fable 5 und GPT-5.6 Sol, doch seltene starke Leistungseinbrüche verschlechterten die Durchschnittswerte um jeweils 759 Punkte bzw. 868 Punkte
  • Der normale Modus von Fable 5 war mit durchschnittlich 32.386 Punkten und einer Spannweite von 319 Punkten am stabilsten, während der /goal-Modus mit 31.934 Punkten den Bestwert insgesamt erreichte
  • Bei schwieriger Optimierung ist nicht wichtiger, ob iteriert wird, sondern wie gut die iterierte Strategie ist; individuelle Gewinnraten und Durchschnittsleistung können zu gegensätzlichen Schlüssen führen

KIRO-Optimierungsproblem für Glasfasernetze

  • KIRO ist ein Operations-Research-Problem, das 2018 bei einem Hackathon für Ingenieurstudierende eingereicht wurde; mithilfe gerichteter Distanzmatrizen für Grenoble, Nizza und Paris soll die Gesamtkabellänge minimiert werden
  • Das Netzwerk besteht aus redundanten Schleifen, die an Verteilungshubs beginnen, sowie kurzen Abzweigungen, die von Türmen auf diesen Schleifen ausgehen
    • Jeder Turm darf genau einmal vorkommen
    • Mehrere strukturelle Nebenbedingungen müssen erfüllt werden
    • Die Kosten eines Kabelsegments können sich ändern, wenn die Richtung umgekehrt wird
    • Ein niedrigerer Score ist besser
  • Die menschliche Baseline war ein C++-Solver, der in der Vergangenheit über eine Woche hinweg für dieses Problem geschrieben wurde

  • Größe des Suchraums

    • Wegen unterschiedlicher Anzahlen und Größen von Schleifen sowie unterschiedlicher Bezugspunkte und Reihenfolgen der Abzweigungen lässt sich der gesamte Suchraum schwer mit einer einzigen geschlossenen Formel berechnen
    • Selbst wenn man nur den Fall betrachtet, in dem 532 Terminals in Paris ohne Reihenfolge und ohne Abzweigungen auf 11 Verteilungshubs zugewiesen werden, gibt es 11^532 Möglichkeiten
    • Selbst wenn man nur eingeschränkte gültige Lösungen mit 19 Schleifen zu je 28 Terminals und ohne Abzweigungen zählt, erreicht der Suchraum ungefähr 10^1223
    • 19 × 28 = 532, also sind alle Terminals enthalten
    • Keine Schleife überschreitet das Limit von 30 Terminals
    • Die Formel lautet (532! / 19!) × 11^19 ≈ 10^1223

Modelle und Ausführungsbedingungen

  • Verglichen wurden die Claude-Modelle Fable 5·Opus 4.8·Sonnet 5 und die GPT-Modelle GPT-5.6 Sol·Terra·Luna
  • Jedes Modell lief im normalen Modus und im nativen /goal-Modus
    • Optimierungszeit: 30 Minuten
    • Zeitlimit des externen Agenten: 1.900 Sekunden
    • Reasoning-Einstellung: jeweils der höchste verfügbare Wert pro Modell
    • Laufumgebung: Harbor 0.1.43, Docker und Subscription-Authentifizierung
  • Zunächst wurde für alle Modelle je ein 30-minütiger Lauf im normalen Modus und mit /goal ohne Hinweise ausgeführt
  • Für die Kernkandidaten Fable 5 und GPT-5.6 Sol wurde wiederholt, bis jeweils 3 gepaarte Läufe vorlagen
  • Vollständiger Code, Prompts, Ergebnistabellen, Ausschlusskriterien und Ausführungsspuren finden sich in CLIArena; das Experiment ist eine Fortsetzung des früheren Benchmark-Artikels

Ergebnisse von Fable 5 und GPT-5.6 Sol

  • Wenn der Wert „/goal-Score minus normaler Score“ negativ ist, ist /goal besser
  • Die drei Läufe von Fable 5 ergaben:
    • Lauf 1: normal 32.197 Punkte, /goal 31.934 Punkte, also 263 Punkte besser
    • Lauf 2: normal 32.516 Punkte, /goal 32.324 Punkte, also 192 Punkte besser
    • Lauf 3: normal 32.446 Punkte, /goal 35.178 Punkte, also 2.732 Punkte schlechter
  • Die drei Läufe von GPT-5.6 Sol ergaben:
    • Lauf 1: normal 33.581 Punkte, /goal 39.371 Punkte, also 5.790 Punkte schlechter
    • Lauf 2: normal 35.539 Punkte, /goal 32.703 Punkte, also 2.836 Punkte besser
    • Lauf 3: normal 33.663 Punkte, /goal 33.313 Punkte, also 350 Punkte besser

  • Warum Gewinnrate und Durchschnitt auseinanderliefen

    • /goal gewann zwar 4 von 6 Läufen, aber beide Modelle erzielten häufig kleine Verbesserungen und erlitten dafür selten große Leistungseinbrüche
    • Fable 5 lag im normalen Modus im Mittel bei 32.386 Punkten, mit /goal bei 33.145 Punkten, also 759 Punkte schlechter
    • Beim Median ergab sich eine Verbesserung um 192 Punkte
    • GPT-5.6 Sol lag im normalen Modus im Mittel bei 34.261 Punkten, mit /goal bei 35.129 Punkten, also 868 Punkte schlechter
    • Beim Median ergab sich eine Verbesserung um 350 Punkte
    • Der Durchschnitt im normalen Modus von Fable 5 war um 1.875 Punkte besser als bei Sol, der /goal-Durchschnitt lag um 1.984 Punkte vorn
    • Auch bei der Stabilität zeigte sich ein Unterschied
      • Die drei Ergebnisse von Fable 5 im normalen Modus lagen innerhalb einer Spannweite von 319 Punkten
      • Der normale Modus von Sol spannte 1.958 Punkte auf
    • Fable 5 mit /goal erreichte mit 31.934 Punkten den Bestwert insgesamt
    • Die sicherste Konfiguration war Fable 5 im normalen Modus

Gleiches /goal, unterschiedliche Implementierungen

  • Separates Bewertungsmodell in Claude Code

    • /goal in Claude Code funktioniert als sitzungsweiter Stop-Hook
    • Immer wenn das Hauptmodell einen Zug beendet, liest das Bewertungsmodell Haiku in der Standardeinstellung die Zielbedingung und die Unterhaltung und gibt mit Begründung yes oder no zurück
    • Bei no beginnt ein neuer Zug, bei yes wird das Ziel aufgehoben
    • Das Bewertungsmodell kann keine Tools verwenden oder Dateien prüfen und entscheidet nur anhand der Belege im Gesprächsverlauf
    • Es kann erkennen, wenn Arbeit zu früh beendet wird, aber nicht, ob es sich lohnt, den Solver weitere 10 Millionen Male laufen zu lassen
    • Da Claude Code nicht Open Source ist, stützen sich die Implementierungsdetails auf die goal-Dokumentation von Anthropic

  • Persistenter Zustand und Lifecycle-Tools in Codex

    • Das im Benchmark verwendete Codex CLI 0.144.4 behandelt Ziele als persistenten Zustand, der an einen Thread gebunden ist
    • Das TUI speichert das Ziel des aktiven Threads, und SQLite protokolliert Zustand und Budgetnutzung
    • Das Arbeitsmodell erhält die Tools create_goal, get_goal, update_goal
    • Wenn ein Thread mit aktivem Ziel in den Leerlauf geht, wird ein Folgeturn injiziert, einschließlich des Ziels und einer Abschlussprüfung
    • Claude überlässt die Entscheidung über den Abschluss einem unabhängigen Bewertungsmodell, das jedoch nur den Gesprächsverlauf sehen kann
    • In Codex kann das Arbeitsmodell Dateien und Tools verwenden, selbst den Abschluss erklären und die Arbeit fortsetzen, solange das persistente Ziel aktiv bleibt

Wie /goal Strategien verstärkt

  • Bei normalen Coding-Aufgaben lässt sich Fortschritt durch zusätzliche Züge leicht prüfen, etwa durch das Reparieren von Tests oder das Abschließen einer Migration
  • Bei Optimierung kann zusätzliche Zeit, nachdem der Agent einen Solver gewählt hat, sowohl gute als auch schlechte Entscheidungen verstärken
  • Fälle, in denen /goal half:
    • Es ließ das schnelle kompilationsbasierte Portfolio von Fable 5 weiterlaufen
    • Es setzte die erfolgreiche Strategie von Sol zur erneuten Kettenaufteilung fort
  • Es gab aber auch Fälle, in denen die Leistung sank
    • Fable 5 baute einen langsamen Solver und ließ ihn dann weiterlaufen
    • Sol versteifte sich auf eine vollständige Suche über alle Bezugspunkte
  • Der Median verbesserte sich leicht, aber der schlechte Rand der Verteilung verschlechterte sich deutlich stärker, wodurch die Durchschnittsleistung sank

Einschränkungen bei der Interpretation der Ergebnisse

  • Untersucht wurde nur ein unveröffentlichtes NP-schweres Problem, daher ist das kein allgemeines Coding-Leaderboard
  • Nur für Fable 5 und Sol konnten jeweils 3 sauber gepaarte Läufe gesichert werden
  • In die Vergleiche anderer Modelle flossen unterschiedliche Prompts, Wrapper-Versionen und Zeitlimits ein
  • Da die Läufe nacheinander über Subscription-Dienste ausgeführt wurden, kann sich der Dienstzustand während des Experiments verändert haben
  • In den Job-Metadaten war 1 CPU verzeichnet, dem Container wurden jedoch 8 CPUs bereitgestellt, was dem parallelen Portfolio von Fable 5 zugutekam
  • Weil der Wrapper Zwischen-Checkpoints und eine finale Validierung verlangte, waren alle in die Wertung eingegangenen Ausgaben von Fable 5 und Sol gültig
  • Gemessen wurde nicht das Modell allein, sondern das Gesamtsystem aus Modell, CLI, Prompt, Subscription-Dienst und Harness

Reproduktionsmaterial und Einordnung

  • In CLIArena sind Benchmark-Aufgaben, Wrapper, Analyseskripte, Diagrammgenerator und vollständige Evidenznotizen veröffentlicht
  • Die rohen Arbeitsverzeichnisse sind wegen ihrer Größe nicht in Git enthalten, aber die Notizen dokumentieren alle veröffentlichbaren Scores, stadtbezogenen Ergebnisse, Laufzeiten, Strategien, Ausschlüsse und Run-IDs
  • Die wichtigsten Ausführungskommandos sind:
RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...
  • /goal erhöhte oder verringerte die Leistung nicht einheitlich; es konnte die meisten einzelnen Läufe gewinnen und zugleich die beobachtete Durchschnittsleistung verschlechtern
  • Bei schwieriger Optimierung ist die Qualität der Strategie, die eine Kontrollschleife wiederholt ausführt, wichtiger als die Qualität der Kontrollschleife selbst

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Hacker-News-Kommentare

  • Das obige Diagramm ist etwas verwirrend. Dort steht „je niedriger, desto besser“, aber die y-Achse ist umgekehrt, sodass visuell weiter oben besser wirkt, zahlenmäßig aber niedrigere Werte besser sind

    • Es sieht nicht so aus, als wäre die Achse umgekehrt. 32.000 ist unten, 40.000 oben, also wurde es vielleicht nach dem Kommentar korrigiert

  • Claude neigt dazu, bei langfristigen Aufgaben über Wochen hinweg Anweisungen zu vergessen, egal wie sehr man betont, dass sie wichtig sind. Ich habe /goal nicht verwendet, aber vermutlich sorgt es dafür, dass die Kernanweisung tatsächlich im Gedächtnis bleibt. Hier scheint es um kürzere Sitzungen zu gehen, in denen dieses Problem weniger stark auftritt

    • Ich habe in die Statusleiste von Claude Code die Kontextnutzung eingebaut, und ab etwa 50–60 % scheint es tatsächlich zu „ermüden“. Ich bat darum, die Testumgebung zu ändern und Tests hinzuzufügen, und es schob das mit Verweis auf „erhebliche Infrastrukturarbeit“ auf; nach /compact und einer erneuten Bitte erledigte es das aber ohne Klagen
      Allerdings ist /compact fehleranfällig, daher würde ich es während der Arbeit nicht empfehlen. Es ist verwandt, aber nützlich, wenn man zu einer neuen Aufgabe übergeht; für Korrekturen, die Kontext aus dem Generierungsprozess brauchen, etwa bei einer Blockade im gerade geschriebenen Code, ist es jedoch ungeeignet, weil es den Gedankengang verwirft
    • Das ist einer der Vorteile von pi. Dort wurde der Befehl /protect eingeführt, um Nachrichten von der Komprimierung auszunehmen, und Skills werden ebenfalls automatisch geschützt. Bei langfristigen Aufgaben nutze ich etwas wie /protect your goal is...
    • Nachdem ich Claude und GPT lange in mehreren Laufzeitumgebungen verwendet habe, stimme ich zu, dass die Ursache die Kontextkomprimierung ist. Die Komprimierung in Codex hält zusammenhängende Gespräche fast magisch natürlich aufrecht, während man bei Claude den Zeitpunkt der Komprimierung sorgfältig steuern musste
    • Die Qualität sinkt schon lange, bevor die Komprimierung erreicht wird. Die Komprimierungswarnung ist wie ein Schild „Nächste Tankstelle in 100 Meilen“, aber man befindet sich bereits mitten im Ödland
      Übermäßig komplexe Verfahren sind nicht nötig, aber die Reihenfolge Aufgaben zerlegen → in neuem Kontext planen → in neuem Kontext implementieren → in neuem Kontext /code-review → in neuem Kontext korrigieren ist gut. Bei Fable 5 fällt die Qualität stark ab, sobald der Kontext 50 % überschreitet, sodass im Codebestand dieselbe Implementierung viermal auftauchen kann. Die eigene Arbeit in derselben Sitzung prüfen zu lassen, ist ungefähr so, als würde man Schüler ihre eigene Prüfung benoten lassen
    • Bei etwa 700.000 Token Kontext ließ auch bei Fable das Urteilsvermögen deutlich nach. OpenAIs Entscheidung, den Codex-Kontext auf 400.000 zu begrenzen, könnte richtig sein; das scheint ein sinnvoller Punkt zu sein, an dem sich der meiste Kontext noch zuverlässig nutzen lässt

  • Wenn man Suchstrategien vergleicht, ist der Ultra-Modus wahrscheinlich überlegen, daher bin ich auf eine Folgeevaluation gespannt
    Ultra setzt Recherche-Agenten parallel ein, führt an festgelegten Prüfpunkten adversariale Reviews durch und nutzt verschiedene Techniken, um nicht in lokalen Optima stecken zu bleiben. /goal ist eher für Single-Path-Recherche oder kleinere verteilte Sammelaufgaben geeignet

    • Der Ultra-Modus braucht klarere Dokumentation oder Warnhinweise. Viele Entwickler, mich eingeschlossen, verstanden ihn als universelle Funktion, bei der das Modell einfach härter arbeitet und bessere Ergebnisse liefert; bei vielen Aufgaben kann die Leistung aber sogar schlechter sein, und die Kosten sind definitiv höher

  • Anthropic liegt im Coding-Bereich deutlich hinter OpenAI zurück. Bis vergangenen März habe ich mit Claude Code ein Repository mit insgesamt 400.000 Zeilen im Basistarif betreut, aber es war sehr langsam und konnte Probleme trotz Tests, Observability, Dokumentation und geschichteter Architektur nicht sauber beheben
    Wir sind ein Dreierteam, das an Kommunalverwaltungen liefert, und seit dem Wechsel zu Codex ist es deutlich angenehmer geworden, außerdem ist die Sorge um Nutzungslimits verschwunden. Jeder im Team verwaltet das Ganze mit zwei Codex-Plus-Konten. Anthropic sollte effizientere Modelle bauen, statt Angst zu schüren; nicht jeder braucht Fable

    • Für mich war Opus 4.8 hervorragend, und Codex war nur so lala. Hängt vermutlich vom Nutzer und der Aufgabe ab
    • Das variiert stark je nach Problemfeld und Sprache. GPT war ziemlich schlecht beim Schreiben von Elixir und bei offenen Aufgaben; aktuell ist Opus stärker bei Elixir, und Fable versteht das Problemfeld selbst deutlich besser als beide
      In den sechs Wochen nach dem Wechsel zu GPT gab es ständig selbstsicher vorgetragene Fehler, sodass ich es am Ende ganz eingestellt habe; die Arbeit in diesem Zeitraum war praktisch verschwendet. Jetzt nutze ich eine Mischung aus Opus/Fable und DeepSeek Pro. DeepSeek ist bei Kosteneffizienz und Geschwindigkeit überwältigend stark und reicht für 90 % der Implementierungsarbeit aus, bricht aber in Elixir zusammen, wenn es zur Compile-Zeit auf Runtime-Funktionen zugreifen will. Die anfänglichen Probleme hat Fable schnell bereinigt
      Jedes Modell hat eigene, schwer zu entdeckende Stärken, daher glaube ich nicht, dass ich in naher Zukunft nur eines verwenden werde. Wenn Qualität nötig ist, verzichte ich gern auf Effizienz

  • In meiner Arbeit hat /goal den Planungsmodus ersetzt, und ich nutze für 95 % der AI-Arbeit folgenden Ansatz:
    Zuerst lasse ich ein bestimmtes Feature lesen und prüfen, ob es vollständig verstanden wurde; wenn in der Zusammenfassung Details fehlen, wird wiederholt. Dann lasse ich nach der aktuellen Uhrzeit fragen und mit /goal für eine bestimmte Zeit ein technisch eindeutiges Designdokument schreiben, wobei carry_forward_requirements.md und testing_best_practices.md ausdrücklich berücksichtigt werden müssen. Es enthält konkrete Code- und Dokumentreferenzen sowie Änderungen, sodass auch ein Implementierer ohne Kontext es ausführen kann, und die gesamte Zeit wird für Überprüfung genutzt, ohne vorzeitig aufzuhören.
    Schon wenn man GPT nur 10 Minuten lang zwingt, ein Designdokument zu schreiben, kommt ein deutlich robusteres Ergebnis als im Planungsmodus heraus, was Zeit bei der Überarbeitung des Entwurfs spart.

    • Es wirkt, als würde man beim Beenden anhand von Zeit die Abbruchbedingung einer rekursiven Funktion nicht nach dem tatsächlichen Ergebnis, sondern nach der verstrichenen Zeit festlegen.
      Ich schreibe in /goal ein explizites Ziel, das der Agent erreichen soll. Man gibt Bedingungen vor, die Design und Architektur erfüllen müssen, vergleicht das Ergebnis fortlaufend damit und beendet erst, wenn alles erreicht ist. Ob 10 Minuten oder 10 Stunden: Der Kern von /goal ist, ein bestimmtes Ergebnis fertigzustellen.
    • Damit ein Agent sein Ziel zuverlässig erreicht, scheint die Phase der Hypothesengenerierung am wichtigsten zu sein. Von Anfang an im richtigen Suchraum zu starten, sagt den Erfolg am besten voraus, und selbst bei einem sehr starken Modell ist ein einziger riesiger Loop, der alle Hypothesen von Grund auf durchackert, bei praktischen Aufgaben wahrscheinlich eine Sackgasse.
      In komplexen Bereichen war es am besten, Deep Research an separate Tool-Aufrufe zu delegieren, um dem Agenten eine solide Grundlage zu geben. Wenn man die Recherche dem Haupt-Agenten-Loop überlässt, leidet die Qualität wegen RLHF und der Tendenz, Kontext zu bewahren und schnell zu antworten. Wenn es als Tool bereitsteht, kann es mehrfach recherchieren, ohne zu merken, dass dabei Milliarden Tokens verbraucht werden, und selbst wenn bei unabhängiger Hypothesengenerierung und Validierung viele Tokens verschwendet werden, kann man den Suchraum um das 10- bis 100-Fache erweitern, bevor die Umgebung verändert wird. In vielen Fällen ist die Priorität Genauigkeit > Zeit > Kosten sinnvoll.
    • Es wirkt seltsam, zu sagen, ein LLM habe etwas „vollständig verstanden“. Das erinnert an Prompt-Techniken wie „bis du zu 95 % sicher bist“, und ich frage mich, welche Auswirkungen das auf die reale Arbeit hat. Ebenso frage ich mich, was sich ändert, wenn man schreibt „bis du sicher verstehst“.

  • Ich frage mich, was /goal ist.

    • Sowohl Codex als auch Claude Code bieten es an, aber die Funktionsweise ist etwas unterschiedlich.
      Bei Claude Code liest Haiku den Gesprächsverlauf und beurteilt, ob das Ziel erreicht wurde; falls nicht, injiziert es die verbleibende Arbeit erneut in das Hauptmodell. Bei Codex wirken die vom Hauptmodell aufrufbaren Tools und die umgebende Laufzeitumgebung zusammen, und wenn keine Fertigmeldung vorliegt, wird erneut gepromptet.
      Es ist eine Funktion, die das Problem lösen soll, dass das Modell wegen Aufmerksamkeitsproblemen nur einen Teil der Aufgabe erledigt und dann stoppt. Statt dass der Nutzer immer wieder zum Weitermachen drängen muss, gibt es automatisch zusätzliche Anweisungen, um die Fertigstellung zu erreichen.
    • Wenn man in Claude von Anfang an /goal verwendet, stoppt es nicht, bis das Ziel erreicht ist oder die Möglichkeiten des Prompts erschöpft sind. Es fühlt sich an wie „Das ist die Mission, also führe sie aus“, und ich nutze es ein paarmal pro Woche.
    • Es ist eine Funktion, bei der ein LLM wiederholt ausgeführt wird, bis es die Zielbedingungen erfüllt.
    • Genauer gesagt wird wiederholt, bis es selbst urteilt, dass das Ziel abgeschlossen ist.
    • Der Agent selbst ist so aufgebaut, dass er das LLM wiederholt ausführt und dann entscheidet, ob gestoppt wird. /goal setzt darüber im Grunde noch einen Eltern-Agenten, der dem Kind-Agenten immer wieder sagt „noch nicht fertig, also mach weiter“, bis dieser entscheidet, dass er fertig ist.

  • Seit dem Release habe ich GPT 5.6 Sol Xhigh und Fable 5 viel verwendet. Die Intelligenz ist ähnlich wie bei 5.5, aber die Beharrlichkeit scheint extrem erhöht worden zu sein, was die Aufgabenabschlussrate und Wettbewerbsfähigkeit in Benchmarks verbessert hat. Andererseits steigt damit auch die Wahrscheinlichkeit, auf anomale oder riskante Methoden zurückzugreifen, sodass man es weiter überwachen muss.
    Kürzlich wollte es per CLI Betriebsumgebungsvariablen auslesen, die nichts mit der Aufgabe zu tun hatten, und als der Zugriff auf SSH-Keys scheiterte, bat es um Computer-Control-Berechtigungen. Nach dem Abbruch fragte ich nach dem Grund, und es antwortete, es habe direkt in 1Password nach den Keys suchen wollen; als ich weiter nachhakte, räumte es ein, dass die Betriebsumgebungsvariablen nicht nötig gewesen waren. Seitdem habe ich den Modus „approve for me“ deaktiviert und nutze es nur noch für einfache Änderungen und Bugfixes.
    Fable ist nicht nur intelligenter, sondern auch einsichtsvoller, versteht Absichten gut und agiert auf Basis von Wissen über die reale Welt wie ein domänenerfahrener Produktmanager. Es macht auch unerwartete Vorschläge, während man GPT 5.6 sehr viel wörtlicher instruieren muss.

    • Fable wirkt wie ein größeres Modell, daher sind die Ausführungskosten höher; im allgemeinen Software Engineering scheint es nicht überlegen, aber bei Aufgaben, die reine Intelligenz erfordern, kann die Größe ein Vorteil sein.
      Bei DeepSWE 1.1 liegt 5.6-Sol xhigh leicht vor Fable 5, braucht dabei aber nur halb so viele Tokens und kostet etwa ein Drittel. Im Artificial Analysis Intelligence Index liegt Fable 5 dagegen leicht vorn, kostet aber das Dreifache.
      Beim Coden schicke ich beiden Modellen dieselbe Aufgabe und bekomme mehrere Antworten, aber die Ergebnisse sind subjektiv, sodass schwer vorherzusagen ist, welches gewinnt. Die Aufgaben im Originaltext haben den Vorteil, dass sie quantifizierbar sind, aber viele Software-Aufgaben lassen sich nicht so leicht bewerten.

  • Da GPT kürzlich bei AtCoder-Heuristik-Wettbewerben die besten menschlichen Teilnehmer geschlagen hat, sollte es bei solchen Optimierungsproblemen stärker sein. Anthropic scheint sich auf diesen Typ relativ weniger zu konzentrieren.

  • Ich würde gern nicht nur die Endpunktzahl sehen, sondern auch die beste Punktzahl im Zeitverlauf. Das wäre nützlicher, um die Wirkung von /goal zu beurteilen.

  • Es gibt pro Modell nur eine Bewertung, und da der Problemraum breit ist und man für gute Lösungen mehrere Versuche braucht, wirkt der Großteil der Ergebnisse wie Rauschen.

    • In der Praxis habe ich tatsächlich mehr Läufe mit veränderten Prompts und Laufzeiten gemacht, aber der Einfluss von /goal war jedes Mal gering oder nicht signifikant.