Kosten in SWE-bench: Wie sich der Preis pro gelöstem Issue berechnen lässt, ohne Fehlschläge, Wiederholungen oder Evaluation zu verschleiern

Die irreführende Zahl: Der Preis pro gelöstem Issue erklärt sich nicht von selbst

Ein Agentenergebnis als „Kosten pro gelöstem Issue“ auszudrücken, scheint eine technische Evaluation in eine einfache wirtschaftliche Entscheidung zu verwandeln. Tatsächlich ist diese Zahl jedoch ein Verhältnis zwischen Variablen, die sehr unterschiedlich definiert sein können. Der Zähler kann nur die Tokens eines abschließenden Aufrufs enthalten oder sämtliche während einer Trajektorie begonnenen Aufrufe. Der Nenner kann die Zahl der Patches sein, die den Verifier bestehen, die Zahl der ursprünglich ausgewählten Issues oder ein unter mehreren Versuchen ausgewähltes Ergebnis. Ohne diese Definitionen beschreiben zwei identische Zahlen nicht zwangsläufig vergleichbare Betriebsabläufe.

Diese Unterscheidung ist besonders bei SWE-bench wichtig. Die Aufgabe geht von realen, Repositories zugeordneten Issues aus und verlangt eine Änderung, die in einer dafür vorbereiteten Umgebung verifiziert werden kann. Die beobachtbaren Kosten beschränken sich daher nicht auf das Verfassen eines Patches. Ein System kann Dateien untersuchen, zusätzlichen Kontext anfordern, Tools ausführen, seine Strategie neu starten oder ein Limit ausschöpfen, ohne eine gültige Lösung hervorzubringen. All diese Ereignisse können Ressourcen verbrauchen, auch wenn die Instanz nicht als gelöst zählt.

Die richtige wirtschaftliche Frage hängt von der Entscheidung ab. Für die Budgetierung eines vollständigen Laufs sind die durchschnittlichen Kosten pro versuchtes Issue relevant. Um die Leistung eines Workflows zu beurteilen, der nur verifizierte Änderungen ausliefert, können die Gesamtkosten geteilt durch die strikten Erfolge interessanter sein. Um zu entscheiden, ob sich eine teurere Konfiguration lohnt, ist meist der zusätzliche Aufwand pro zusätzlichem Erfolg gegenüber einer Basislinie entscheidend. Und wenn mehrere Trajektorien zugelassen und nur eine davon behalten wird, muss die gesamte Richtlinie gemessen werden, nicht bloß die ausgewählte Trajektorie.

Das bedeutet nicht, dass eine zusammenfassende Kennzahl nutzlos wäre. Es bedeutet, dass sie als Titelseite eines Kostendatenblatts gelesen werden sollte. Das Datenblatt muss die Version des Datensatzes, die tatsächlich ausgeführte Teilmenge, Ausschlüsse, die Zahl der Versuche, die Auswahlregel, das Abbruchprotokoll, die Verbrauchskategorien und den einbezogenen Anteil der Evaluierungsinfrastruktur nennen. Ohne diese Elemente kann die Zahl eine gültige interne Beobachtung sein, aber keine ausreichende Grundlage für Agentenvergleiche oder die Kalkulation einer Automatisierung.

Wofür während einer Ausführung bezahlt wird

Die erste Komponente ist die Inferenz. Bei einer API sollte das Verbrauchsprotokoll Eingabe- und Ausgabetokens getrennt ausweisen, wenn der Anbieter sie unterschiedlich abrechnet. Meldet die Plattform gecachte Eingaben oder abrechenbare Reasoning-Tokens, sollten auch diese Kategorien separat erscheinen. Die OpenAI-Dokumentation, die ausschließlich für Systeme gilt, welche diese API verwenden, unterscheidet diese Kategorien und weist darauf hin, dass mehrere angeforderte Completions zusätzliche Tokens verbrauchen. Diese Terminologie und Preisstruktur darf nicht automatisch auf andere Anbieter übertragen werden.

Die zweite Komponente sind Hilfsaufrufe und Tools. Ein Agent kann suchen, Dateien zusammenfassen, Tests erzeugen, Diffs prüfen oder nach der Ausführung von Befehlen neue Completions anfordern. Manche Tools haben keinen direkten API-Preis, vergrößern aber den Kontext späterer Aufrufe oder verbrauchen eigene Rechenleistung. Wird ein externes Tool pro Nutzung abgerechnet, sollte es als eigene Kostenposition erscheinen. Wird ihm kein Geldwert zugeordnet, sollten zumindest die Zahl seiner Aufrufe und die verbrauchten Ressourcen erfasst werden, damit eine andere Organisation sie mit ihren eigenen Tarifen bewerten kann.

Die dritte Komponente ist die Evaluation. Das SWE-bench-Harness bereitet Docker-Images vor, wendet Patches an und führt Tests mit Zeitlimits je Instanz aus. Seine Dokumentation behandelt außerdem Anforderungen an CPU, Speicher und Storage sowie Caching-Mechanismen. Images aufzubauen oder abzurufen, Container auszuführen und Artefakte aufzubewahren, kann insbesondere bei großen Kampagnen einen erheblichen Kostenanteil darstellen, auch wenn dies keine Inferenzkosten sind. Werden diese Kosten ohne Aufschlüsselung vermischt, lässt sich nicht erkennen, ob eine Verbesserung vom Agenten oder von der Infrastruktur stammt; werden sie in einer operativen Budgetplanung weggelassen, kann der reale Aufwand unterschätzt werden.

Sinnvoll ist außerdem die Trennung zwischen amortisierten und marginalen Kosten. Ein gemeinsames Image für viele Instanzen vorzubereiten kostet pro Lauf etwas anderes, als es jeweils von Grund auf neu zu bauen. Ebenso kann ein Ergebnis-Cache spätere Arbeit vermeiden. Solche Effizienzen sind legitim, sofern sie dokumentiert werden; sie dürfen aber nicht so dargestellt werden, als hätte jedes Issue denselben marginalen Aufwand verursacht. Ein belastbares Datenblatt bietet beide Perspektiven: die Kosten der beobachteten Kampagne und die Regeln zur Zuordnung geteilter Kosten.

Vier Nenner für vier unterschiedliche Fragen

Die erste Kennzahl sind die durchschnittlichen Kosten pro versuchtes Issue: die Gesamtkosten der Kampagne geteilt durch alle Issues, für die das Protokoll gestartet wurde. Sie eignet sich am besten, um die Kosten einer ähnlichen Arbeitswarteschlange zu schätzen, weil sie Erfolge, Fehlschläge, ungültige Trajektorien und durch Limits erschöpfte Fälle einbezieht. Es muss klar sein, ob ein Issue, das vor dem Start des Agenten ausgeschlossen wurde, Teil der Grundgesamtheit ist. Ein Ausschluss nach der Ausführung sollte seine Kosten nicht verschwinden lassen.

Die zweite Kennzahl sind die Kosten pro strengem Erfolg: die Gesamtkosten der in der Richtlinie enthaltenen Trajektorien geteilt durch die Zahl der Issues, deren Patch den definierten Verifikationsprozess besteht. Sie beschreibt, welcher durchschnittliche Aufwand erforderlich war, um unter diesem Protokoll ein validiertes Ergebnis zu erhalten. Sie kann steigen, selbst wenn die Kosten pro Versuch sinken, falls die Lösungsrate fällt; deshalb sollte sie nicht ohne beide Grundgrößen veröffentlicht werden.

Die dritte Kennzahl sind die inkrementellen Kosten einer höheren Lösungsrate. Löst Konfiguration B mehr Issues als Konfiguration A, wird sie als Differenz der Gesamtkosten von B und A geteilt durch die Differenz der Erfolge berechnet. Dieses Verhältnis beantwortet eine marginale Entscheidungsfrage: Was kostet jeder zusätzliche Erfolg mit einer ambitionierteren Konfiguration? Es ist nur interpretierbar, wenn beide Systeme auf derselben Menge, mit gleichwertigen Erfolgskriterien und vergleichbaren Evaluierungsressourcen laufen.

Die vierte Kennzahl betrifft Richtlinien mit mehreren Versuchen pro Issue. Wenn pass@k, Wiederholungen oder eine nachträgliche Auswahl zugelassen sind, müssen die Kosten alle für ein Issue generierten Trajektorien summieren, einschließlich der nicht ausgewählten. Die Kosten der besten gefundenen Trajektorie zu melden, bedeutet, ein bedingtes Ergebnis zu berichten, das den Aufwand zu ihrer Auffindung nicht reproduziert. Die Veröffentlichung muss klären, ob pro Instanz eine einzige Trajektorie, mehrere unabhängige Trajektorien oder ein adaptiver Entscheidungsbaum ausgeführt wurde.

Das Protokoll verändert Rechnung und Bedeutung des Ergebnisses

Ein Limit für Schritte, Zeit, Aufrufe oder Geldbudget ist Teil der evaluierten Intervention. Wird es erhöht, können einige schwierige Issues mehr Erkundung erhalten; zugleich kann sich ein großer Teil der Ausgaben auf einen langen Schwanz ungelöster Fälle konzentrieren. Deshalb sollten neben dem Mittelwert auch Median, Perzentile und die Verteilung pro Instanz veröffentlicht werden. Ein niedriger Mittelwert kann mit wenigen außergewöhnlich teuren Fällen einhergehen, die im Produktionseinsatz nicht akzeptabel wären.

Die Abbruchrichtlinie muss explizit sein. Eine Ausführung kann beim Erhalt eines Patches, beim Ausbleiben relevanter Dateien, bei Überschreitung eines Budgets, nach fehlgeschlagenen Tests oder beim Erreichen einer Iterationszahl beendet werden. Jede Option verändert sowohl Kosten als auch Erfolgswahrscheinlichkeit. Für Wiederholungen ist dieselbe Präzision nötig: Es muss angegeben werden, was sie auslöst, ob sie Kontext erben, ob sie Cache wiederverwenden und ob verworfene Versuche gezählt werden. Eine Folge interner Neustarts als „einen Versuch“ zu bezeichnen, kann einen wesentlichen Verbrauchsunterschied verschleiern.

Pass@1 und pass@k beantworten unterschiedliche Fragen. Pass@1 nähert die Leistung einer einzigen Gelegenheit unter einer festgelegten Konfiguration an. Pass@k beschreibt die Möglichkeit, dass mindestens eine von mehreren Gelegenheiten erfolgreich ist, entspricht aber nicht den Kosten einer einzelnen Gelegenheit. Bei nachträglicher Auswahl muss das verwendete Auswahlsignal dokumentiert werden, ebenso ob die Auswahl zusätzliches Modell- oder Rechenbudget verbrauchte und ob sie Zugriff auf Testergebnisse hatte. Eine vom Verifier informierte Auswahl kann für Forschung nützlich sein, darf aber nicht mit einer Richtlinie verwechselt werden, die vor der Verifikation verfügbar ist.

Der aussagekräftigste Vergleich setzt oft gemeinsame Einschränkungen fest: dieselbe Instanzmenge, dasselbe Harness, dieselben Evaluierungslimits und, wenn das wirtschaftliche Ziel im Vordergrund steht, ein vergleichbares maximales Budget pro Issue. Anschließend lassen sich Kosten-gegen-Lösungsraten-Kurven zeigen. Diese Darstellung offenbart, ob die höhere Lösungsrate zu schrittweise steigenden Kosten entsteht oder von einer Minderheit sehr teurer Trajektorien abhängt. Sie verhindert außerdem, dass eine Agentenqualität zugeschrieben wird, was schlicht darauf beruhen könnte, dass der Agent mehr ausgeben durfte.

Inferenz und Evaluation: Sie zu trennen heißt nicht, eine von beiden zu ignorieren

Die Trennung von Inferenz und Evaluation ermöglicht Antworten auf zwei Fragen, die eine einzige Zahl vermischt. Die erste lautet, wie viel es kostet, wenn der Agent eine Änderung vorschlägt. Die zweite lautet, wie viel es kostet, festzustellen, ob diese Änderung das Benchmark-Protokoll besteht. In SWE-bench erfordert die Evaluation, die Vorhersage anzuwenden und Tests in einer Repository-Umgebung auszuführen. Das Harness dokumentiert Image-Vorbereitung, Container-Ausführung, Zeitlimits und Cache-Optionen; die Verifikation als kostenfreie Operation zu behandeln, wäre daher methodisch unvollständig.

Die Trennung zwingt nicht zur Wahl einer einzigen Konvention. Für die Modellforschung kann es sinnvoll sein, zunächst die Inferenzkosten und daneben die Evaluierungskosten der Kampagne zu berichten. Für die Planung eines automatisierten Reparaturdienstes sind die Gesamtbetriebskosten relevanter: Inferenz, Orchestrierung, Tools, Testrechenleistung, Storage und menschliche Prüfung, sofern sie Teil des Workflows ist. Entscheidend ist, nicht für einen Agenten bestimmte Positionen zu addieren und sie für einen anderen wegzulassen.

Es gibt eine praktische Unsicherheit: Infrastrukturkosten hängen von Region, Anbieter, reservierter Kapazität, Parallelität und Aufbewahrungsrichtlinie ab. Die verfügbaren Quellen beschreiben Komponenten des Harnesses, legen jedoch keinen universellen Tarif für deren Betrieb fest. Eine sorgfältige Veröffentlichung sollte deshalb neben jeder lokalen monetären Umrechnung physische Einheiten wie Containerzeit und zugewiesene Ressourcen angeben. So kann eine andere Organisation den Betrag mit ihren eigenen Verträgen neu berechnen.

Experimentartefakte sind für diese Trennung entscheidend. Das SWE-bench-Experiment-Repository berücksichtigt Vorhersagen, Ausführungsprotokolle, Traces und Ergebnisse pro Instanz. Diese Artefakte in konsistenter Struktur zu teilen oder zusammenzufassen, erlaubt es zu prüfen, welche Patches evaluiert wurden, Instanzen ohne Ergebnis zu erkennen und Kostensummen mit Trajektorien abzugleichen. Auditierbarkeit verlangt nicht die Offenlegung von Zugangsdaten, vertraulichen Prompts oder geschützten Daten; sie verlangt jedoch, dass Ausschlüsse und Aggregationen die Prüfung der Buchführung nicht verhindern.

Das minimale Veröffentlichungsdatenblatt und die operative Entscheidung

Das Datenblatt sollte mit der Identität des Experiments beginnen: Variante und Revision des Datensatzes, Zahl der zulässigen, versuchten und ausgeschlossenen Instanzen sowie Gründe für die Ausschlüsse. Das ist relevant, weil SWE-bench mehrere Varianten bietet und die Projektdokumentation SWE-bench Verified als einen Datensatz mit 500 Instanzen ausweist. Nur „SWE-bench“ zu nennen, reicht nicht aus, um die evaluierte Population zu erkennen. Außerdem sollten die Kennung des Harnesses, die Images oder die einschlägige Konfiguration und die Verifikationsregeln erhalten bleiben.

Danach müssen Modell, Anbieter oder Endpoint, die Region, sofern sie den Preis beeinflusst, das Datum der Preisabfrage und die Währung folgen. Die Abrechnung sollte Eingabe-, Ausgabe-, Cache- und Reasoning-Tokens zeigen, soweit diese Kategorien beim verwendeten Anbieter existieren, ebenso wie Hilfsaufrufe. Sie muss das Limit pro Issue, die Abbruchrichtlinie, Wiederholungen und die Auswahlmethode enthalten. Mittelwerte sollten von einer Verteilung pro Instanz und von Zählungen fehlgeschlagener, erschöpfter, ungültiger oder nicht verifizierbarer Trajektorien begleitet werden.

Das Datenblatt endet mit zwei Summen: Inferenz und Evaluation. Für beide sollte angegeben werden, welche Positionen enthalten sind, was ausgeschlossen wird und wie geteilte Kosten zugeordnet werden. Wird eine Zahl pro Erfolg veröffentlicht, muss sich die Gesamtsumme des Zählers mit den vorherigen Positionen und der Nenner mit den beobachteten strikten Erfolgen abstimmen lassen. Bei mehreren Samples pro Instanz müssen die gemeldeten Kosten die Kosten für Erzeugung und Auswahl unter allen Samples sein, nicht jene des Gewinner-Samples.

Um Modelle in einer frühen Phase zu erkunden, sind die Kosten pro versuchtes Issue und eine Auflösungskurve unter festen Budgets meist die nützlichsten Kennzahlen. Für die Optimierung eines Agenten sollten die inkrementellen Kosten pro zusätzlichem Erfolg und die Verteilung teurer Fälle ergänzt werden. Für die Budgetierung einer Automatisierung sind die Gesamtbetriebskosten pro eingehendem Issue maßgeblich, einschließlich Verifikation und menschlicher Intervention, die der tatsächliche Prozess verlangt. Keine dieser Kennzahlen ersetzt die anderen: Jede beantwortet ein anderes Risiko.

Die vorsichtige Schlussfolgerung lautet, dass ein Agent die Kosten zur Lösung von Issues nicht zwangsläufig senkt, nur weil er eine höhere Lösungsrate erzielt oder einen niedrigen Betrag für seine Erfolge ausweist. Er kann Ausgaben in mehr Trajektorien, mehr Kontext, mehr Testrechenleistung oder eine nachträgliche Auswahl verlagern. Ein belastbarer Vergleich legt diese Verlagerung offen. Mit einem vollständigen Datenblatt kann ein Team entscheiden, ob es für mehr Erfolge zahlt, die Exposition gegenüber teuren Fällen begrenzt oder eine Konfiguration übernimmt, die eine besser vorhersehbare Wirtschaftlichkeit bietet.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.