ai newsSo., 25. Okt.

Claude Haiku vs. Opus im Bug-Test: fast gleich viele saubere Fixes bei 95 Prozent geringeren Kosten

Bei 25 echten Bugs lagen Claude Haiku 5.5 und Opus mit 52 zu 54 sauberen Fixes nahezu gleichauf. Nur bei einem schwierigen Parser-Edgecase zeigte Haiku Schwaechen, was bei deutlich geringeren Kosten ein starkes Ergebnis ist.

dev.toSonntag 02:21 · 25.10.DE2 Min. Lesezeit
Bild: dev.to

Letzte Woche habe ich gemessen, wo Claude Haiku 5.5 im Vergleich zu Opus schwächelt. Die Antwort war ein schwieriger Bug im Markdown-Parser, bei dem Sonnet und Opus einen Randfall erkannten, der im Bugreport nicht auftauchte, Haiku dies dagegen meist nicht schaffte. Ein einzelner Bug ist nur ein dünner Beweis, deshalb habe ich den drei Modellen diesmal 25 echte Bugs vorgelegt.

Kurzfassung: Haiku hat ebenso viele Bugs sauber behoben wie Opus (52 und 54 von 75 Durchläufen) und das zu etwa 95 Prozent geringeren Kosten. Opus lag bei den schwierigeren Bugs vorn, vor allem weil es seltener andere Tests beschädigte. Und wo ein Bugreport einen Fall ausließ, haben alle drei Modelle ihn auf dieselbe Weise übersehen.

Die Bugs kamen in zwei Runden. In der einfachen Runde (15 Bugs) lagen Ursache und Symptom nahe beieinander. In der schweren Runde (10 Bugs) handelte es sich um Bugs, bei denen der Report nur ein Symptom zeigt, das oft weit von der Ursache entfernt ist.

"Sauberer Fix" bedeutet, dass jeder Testfall der Maintainer für den Fix durchläuft und kein anderer Test bricht.

Bei 22 der 25 Bugs hatten Haiku und Opus exakt dieselbe Anzahl sauberer Fixes. Die drei, bei denen sie sich unterschieden:

Ein weiterer Bug verdient eine Erwähnung: ein zod-Bug, bei dem numerische Record-Keys an mehreren Stellen der JSON-Schema-Ausgabe korrekt behandelt werden mussten. Kein Durchlauf hat das vollständig gelöst, aber Opus bestand 14 der 24 Testfälle über seine drei Durchläufe, Haiku 9 und Sonnet 5.

Bei drei schweren Bugs haben alle Durchläufe aller Modelle das Beispiel im Report gelöst und denselben Fall übersehen, den der Report nicht erwähnte:

Beim letzten Mal waren Sonnet und Opus besser darin, einen solchen Fall zu finden. Über 25 Bugs hinweg hat sich das nicht bestätigt. Das Bezahlen eines größeren Modells brachte nicht den fehlenden Fall; die Tests der Maintainer zu lesen hätte es getan.

Wahrscheinlich bei dieser Stichprobengröße nicht nachweisbar, und ich möchte hier vorsichtig sein.

Um zu zeigen, dass zwei Modelle innerhalb von ±10 Punkten gleichwertig sind, wären mehrere hundert Durchläufe pro Modell mit unterschiedlichen Bugs nötig. Ich werde mit derselben Methode weitere Bugs hinzufügen.

Daten (225 Durchläufe: bestandene Fälle, gebrochene Tests, Zeit und Kosten pro Durchlauf; CSV und JSON, CC BY 4.0): https://tokensave.app/data/claude-haiku-vs-opus-real-bugs

DOI: 10.5281/zenodo.23619927 (auch auf Hugging Face, Kaggle und GitHub)

Offenlegung: Ich betreibe TokenSave, das diese Messungen veröffentlicht. Keine Unterstützung oder Credits von Anthropic.

Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.

Original (Englisch) anzeigen

Last week I measured where Claude Haiku 5.5 falls behind Opus. The answer was one hard bug in the marked parser, where Sonnet and Opus caught an edge case the bug report left out and Haiku mostly did not. One bug is thin evidence, so this time I gave the three models 25 real bugs.

Short version: Haiku fixed as many bugs cleanly as Opus (52 and 54 of 75 runs) at about 95% less cost. Opus was ahead on the harder bugs, mostly because it broke other tests less often. And where a bug report left a case out, all three models missed it the same way.

The bugs came in two rounds. The easy round (15 bugs) had cause and symptom close together. The hard round (10 bugs) used bugs where the report only shows a symptom, often far from the cause.

"Clean fix" means every maintainer test case for the fix passes and no other test breaks.

On 22 of the 25 bugs, Haiku and Opus had exactly the same number of clean fixes. The three where they differed:

One more bug is worth a mention: a zod bug that needed numeric record keys handled in several places of the JSON Schema output. No run fixed all of it, but Opus passed 14 of the 24 test cases over its three runs, Haiku 9 and Sonnet 5.

On three hard bugs, every run of every model fixed the example in the report and missed the same case the report did not mention:

Last time, Sonnet and Opus were better at finding a case like this. Across 25 bugs that did not hold. Paying for a bigger model did not buy the missing case; reading the maintainers' tests would have.

Probably not detectable at this size, and I want to be careful here.

To show that two models are equal within ±10 points would take several hundred runs per model, on different bugs. I will keep adding bugs with the same method.

Data (225 runs: cases passed, tests broken, time and cost per run; CSV and JSON, CC BY 4.0): https://tokensave.app/data/claude-haiku-vs-opus-real-bugs

DOI: 10.5281/zenodo.23619927 (also on Hugging Face, Kaggle and GitHub)

Disclosure: I run TokenSave, which publishes these measurements. No support or credits from Anthropic.

Originaltitel: Claude Haiku vs Opus on 25 real bugs: 52 vs 54 clean fixes, 95% cheaperQuelle: dev.to (dev.to). Original öffnen