Benchmark · KI-Tooling · Werkstattbericht

DRACO mit pi und pi-fusion: was unser Lauf wirklich zeigt

Tom Jansen · 22.06.2026 · 14 Min. Lesezeit

Wir wollten wissen, ob sich DRACO lokal mit pi und pi-fusion sinnvoll gegen starke öffentliche Referenzwerte stellen lässt. Die kurze Antwort: ja, als Mess- und Debug-Harness; nein, noch nicht als sauberer Leaderboard-Vergleich.

Drei Dinge kann ich sauber belegen: einen direkten GPT-5.5-xhigh-Lauf, bewertet mit GPT-4.1 mini; dieselben Antworten erneut bewertet mit GPT-5.5 xhigh als strengem Criterion-Judge; und einen DS4/Gemma/Qwen-Fusion-Lauf, aus dem nur die gültigen DS4-Panelantworten separat bewertet wurden.

61,77 %GPT-5.5 direkt, GPT-4.1 mini als Judge.

49,37 %GPT-5.5 direkt, GPT-5.5 xhigh strict als Judge.

48,21 %DS4-Salvage auf 52 gültigen DS4-Antworten.

25,07 %DS4-Salvage, wenn 48 Fehler als null zählen.

DRACO-Score · % der maximalen Rubrikpunkte

OpenRouter (veröffentlichte Referenz)

Fusion Fable 5 + GPT-5.5 → Opus 4.869,0 %

Budget-Fusion (Gemini 3 Flash · Kimi · DS4 Pro)64,7 %

Solo GPT-5.560,0 %

Unser lokaler Lauf (pi / pi-fusion)

GPT-5.5 · Judge GPT-4.1 mini61,8 %

GPT-5.5 · Judge GPT-5.5 xhigh strict49,4 %

DS4-Salvage (52 gültige Antworten)48,2 %

DS4 hart gerechnet (48 Fehler = 0)25,1 %

0255075100

OpenRouter-Referenz unser Lauf

Die Grafik zeigt Referenzwerte und lokale Ergebnisse. Sie ist kein Leaderboard: Tooling, Judge, Modelle und Fehlerbehandlung unterscheiden sich.

Warum DRACO?

DRACO steht für Deep Research Accuracy, Completeness, and Objectivity. Perplexity veröffentlichte den Benchmark Anfang 2026 als offenen Test für Deep-Research-Agenten. Der Testdatensatz enthält 100 Aufgaben aus zehn Domänen. Jede Aufgabe hat eine eigene Rubrik mit vielen gewichteten Kriterien. Positive Kriterien bringen Punkte, negative Kriterien ziehen Punkte ab, wenn die Antwort den beschriebenen Fehler tatsächlich begeht.

Das ist für Agenten relevanter als kurze Frage-Antwort-Benchmarks. DRACO prüft Recherche, Quellenarbeit, Vollständigkeit, Faktentreue und Darstellung. Genau dort soll pi-fusion helfen: mehrere unabhängige Antworten erzeugen, prüfen und zu einer besseren Endantwort verdichten.

Externer Vergleich

OpenRouter veröffentlichte am 12. Juni 2026 den Artikel Surpassing Frontier Performance with Fusion. Dort erreichte das beste berichtete Setup, Fable 5 plus GPT-5.5 mit Opus 4.8 als Synthesizer, 69,0 %. Ein Budget-Panel aus Gemini 3 Flash, Kimi K2.6 und DeepSeek V4 Pro mit Opus 4.8 als Synthesizer erreichte 64,7 %. Solo GPT-5.5 lag bei 60,0 %.

OpenRouter nutzte für Fusion- und Solo-Läufe serverseitig dieselben drei Tools: openrouter:web_search, openrouter:web_fetch und openrouter:bash. Benchmark-Leakage-Quellen wurden per Exclude- oder Blocked-Domains ausgeschlossen. Bewertet wurde mit Gemini 3.1 Pro Preview. Unser Lauf nutzte andere Tools, andere Modelle, andere Fehlerregeln und andere Judges. Deshalb ist nur die Größenordnung vergleichbar, nicht die Rangliste.

Was wir ausgeführt haben

Der direkte Lauf nutzte openai-codex/gpt-5.5:xhigh über pi. Konfiguriert waren web_search, fetch_content und get_search_content über pi-web-access. Der Lauf erzeugte 100 Antwortdateien. Die Generation-Summary meldet 98 returncode=0, 2 Timeouts und 34 Zeilen mit error_message. Alle 100 Antwortdateien wurden anschließend bewertet.

Für denselben direkten GPT-5.5-Lauf existieren zwei vollständige Score-Dateien:

scores.jsonl: OpenAI gpt-4.1-mini als Criterion-Judge, judge_runs=3.
scores.pi-gpt55-xhigh-strict-criterion-3.jsonl: pi openai-codex/gpt-5.5:xhigh als strenger Criterion-Judge, judge_runs=3.

Die vorhandene benchmark_summary.json im Direct-Run-Ordner gehört zur ersten Datei, also zum GPT-4.1-mini-Judge. Für den GPT-5.5-Judge gibt es ein Score-JSONL, aber keine separate benchmark_summary.*. Die Zahlen unten wurden deshalb direkt aus dem Score-JSONL aggregiert.

Maschine und Tooling

Der Lauf war ein lokaler Schreibtisch-Benchmark, kein Cloud-Run. Die Hardware- und Tooling-Daten stammen aus dem lokalen System- und Projektkontext während der Auswertung.

Komponente	Wert
Rechner	MacBook Pro `Mac17,6`, Apple M5 Max, 18 CPU-Kerne, 128 GB RAM
Betriebssystem	macOS 26.4, Darwin 25.4.0
pi	0.79.4
pi-fusion	0.1.0, lokaler Checkout `4741f0c`
Ollama	0.30.8
Node	v24.14.1
Python	3.13.12 im Benchmark-Projekt; gebündelte Codex-Runtime für PNG-Erzeugung
DS4	`ds4/deepseek-v4-flash` über pi; Modellinventar mit `ctx 100000`

Direkter GPT-5.5-Lauf	GPT-4.1 mini Judge	GPT-5.5 xhigh strict Judge
Scored Tasks	100	100
Score Mittelwert	61,77 %	49,37 %
Median	65,65 %	49,65 %
Min / Max	0,00 % / 100,00 %	0,00 % / 86,67 %
Judge-Kosten	12,07 $	200,37 $
Judge-Tokens	22,76M Input · 0,83M Output · 16,41M Cache-Read	20,43M Input · 3,23M Output · 2,64M Cache-Read
Judge-Laufzeit	20.748 s	17.315 s

Score je Domäne · gleiche Antworten, zwei Judges · Achse 30–90 %

Law84,4→66,1 −18,3

Medicine74,8→62,0 −12,9

Academic69,4→59,9 −9,5

UX Design68,3→51,5 −16,8

Technology61,9→49,9 −12,0

Finance61,5→51,3 −10,2

Shopping / Product54,8→38,5 −16,4

Needle in a Haystack53,7→46,9 −6,8

Personalized Assistant50,9→37,1 −13,8

General Knowledge46,7→37,8 −8,9

GPT-4.1 mini Judge GPT-5.5 xhigh strict Judge Spalte rechts: mini → strict · Differenz

Gleiche Antworten, anderer Judge. Der GPT-5.5-xhigh-Judge ist in allen Domänen strenger; die Differenz reicht von -6,8 bis -18,3 Prozentpunkten.

DS4/Gemma/Qwen über pi-fusion

Der Fusion-Lauf nutzte ein Panel aus ds4/deepseek-v4-flash:high, ollama/gemma4:latest und ollama/qwen3.6:latest:high. Judge und Synthesizer der Fusion-Stufe waren jeweils openai-codex/gpt-5.5:xhigh. Der Lauf war mit max_concurrency: 1 konfiguriert. Gemma und Qwen wurden vor und nach jedem Task per ollama stop entladen, um lokale Ressourcen freizugeben.

{
  "panel": [
    { "model": "ds4/deepseek-v4-flash", "thinking": "high" },
    { "model": "ollama/gemma4:latest", "thinking": "off" },
    { "model": "ollama/qwen3.6:latest", "thinking": "high" }
  ],
  "judge_model": { "model": "openai-codex/gpt-5.5", "thinking": "xhigh" },
  "synthesizer_model": { "model": "openai-codex/gpt-5.5", "thinking": "xhigh" },
  "max_concurrency": 1,
  "fusion_child_runner": "pi"
}

Blockiert wurden huggingface.co, hf.co, datasets-server.huggingface.co, openrouter.ai und cognition.ai. DS4 lief als ds4/deepseek-v4-flash über pi; das Modellinventar weist ctx 100000 aus.

Der Runner schloss 100/100 Tasks ab. Das bedeutet nicht, dass 100 vollständige Fusion-Läufe vorlagen: 49 Tasks hatten fusion_status=ok, 51 waren partial. Die Stage-Metriken zeigen: DS4 52 ok / 48 error, Gemma 99 ok / 1 error, Qwen 99 ok / 1 error, Fusion-Judge 97 ok / 3 error, Synthese 100 ok.

Für die posthoc-Auswertung wurden nur gültige DS4-Panelantworten extrahiert. Das Manifest enthält 100 Zeilen: 52 wurden eingeschlossen, 48 mit dem Grund panel status is error übersprungen. Von den 48 DS4-Fehlern waren 42 100k-Kontextüberschreitungen, 2 Provider finish_reason: error und 4 pi child produced no assistant output.

DS4/Fusion-Metrik	Wert	Einordnung
Runner-Tasks	100/100	alle Top-Level-Runs beendet, kein Timeout
Fusion-Status	49 ok · 51 partial	keine saubere Full-Fusion-Scorebasis
DS4-Panel	52 ok · 48 error	nur 52 DS4-Antworten wurden bewertet
DS4-Salvage Score	48,21 %	nur gültige DS4-Antworten
DS4 hart gerechnet	25,07 %	48 DS4-Fehler als null Punkte
DS4-Salvage Judge-Kosten	153,66 $	GPT-5.5 xhigh, Criterion-Modus, `judge_runs=3`

DS4-Salvage je Domäne · sortiert nach Coverage · Achse 0–100 %

Needle in a Haystackn = 1 / 6 bewertet82,7→13,8

Personalized Assistantn = 1 / 6 bewertet43,6→7,3

General Knowledgen = 4 / 9 bewertet51,2→22,7

Medicinen = 4 / 6 bewertet57,2→38,1

Lawn = 5 / 6 bewertet75,7→63,0

Financen = 6 / 20 bewertet40,0→12,0

UX Designn = 6 / 9 bewertet34,2→22,8

Technologyn = 7 / 10 bewertet40,2→28,1

Shopping / Productn = 8 / 16 bewertet30,9→15,5

Academicn = 10 / 12 bewertet59,5→49,6

Valid-only (nur gültige DS4-Antworten) All-tasks (DS4-Fehler = 0)

Der DS4-Salvage-Score ist ohne Coverage irreführend. Einige Domänen haben nur 1 bis 6 bewertete DS4-Fälle.

Kosten und Tokens

Der direkte GPT-5.5-Lauf kostete in der Generation 612,60 $. Die Generation nutzte 42,80M Input-Tokens, 1,76M Output-Tokens und 691,64M Cache-Read-Tokens. Der GPT-4.1-mini-Judge addierte 12,07 $; der GPT-5.5-xhigh-Judge addierte 200,37 $.

Der Fusion-Lauf kostete in der Generation 92,13 $. Diese Summe setzt sich aus 68,30 $ internem Fusion-Judge und 23,83 $ Synthese zusammen; DS4, Gemma und Qwen sind in den Stage-Metriken mit 0 $ erfasst. Token: 7,21M Input, 2,24M Output, 199,05M Cache-Read, 7,14M Cache-Write. Das posthoc DS4-Salvage-Judging addierte 153,66 $. Zusammen sind das 245,80 $.

Kosten in US-Dollar · Generierung + Judge · Achse 0–850 $

Direkt GPT-5.5 · Judge GPT-4.1 mini 624,67 $Gen 612,60 · Judge 12,07

Direkt GPT-5.5 · Judge GPT-5.5 xhigh 812,98 $Gen 612,60 · Judge 200,37

DS4-Fusion · DS4-Salvage-Judge 245,80 $Gen 92,13 · Judge 153,66

Generierung Judge Generierung der beiden Direct-Läufe ist identisch und wird geteilt

Die direkte GPT-5.5-Generation wurde für beide Judge-Auswertungen wiederverwendet. Die beiden Direct-Gesamtsummen dürfen deshalb nicht addiert werden.

Was die Scores bedeuten

Der GPT-4.1-mini-Judge reproduziert ungefähr den OpenRouter-Solo-GPT-5.5-Kontext: 61,77 % lokal gegen 60,0 % bei OpenRouter. Das ist plausibel, aber kein Beweis für Gleichstand, weil Tooling und Judge abweichen.

Der GPT-5.5-xhigh-Judge drückt dieselben Antworten auf 49,37 %. Das ist der methodisch stärkere interne Anspruch: strengere Criterion-Einzelbewertung, drei unabhängige Judge-Pässe pro DRACO-Kriterium, JSON-only Judge-Instruktion. Es ist aber nicht der DRACO- oder OpenRouter-Judge und deshalb kein offizieller Score.

Der DS4-Salvage-Wert von 48,21 % zeigt nur die Qualität der 52 erfolgreichen DS4-Panelantworten. Als Systemscore für den 100er-Lauf ist 25,07 % ehrlicher, weil 48 DS4-Fehler sonst unsichtbar würden.

Warum die OpenRouter-Lücke groß ist

Erstens: anderes Modell. OpenRouter berichtet unter anderem DeepSeek V4 Pro. Unser DS4-Panel nutzte ds4/deepseek-v4-flash:high. Das ist nicht dieselbe Modellklasse.

Zweitens: anderer Judge. OpenRouter nutzte Gemini 3.1 Pro Preview. Unsere beiden Direct-Scores zeigen, wie stark absolute Scores allein durch den Judge schwanken können: 12,41 Prozentpunkte Differenz auf denselben Antworten.

Drittens: anderes Tooling. OpenRouter hatte ein serverseitiges, einheitliches Toolset. Unser Setup kombinierte pi, pi-web-access, lokale Ollama-Modelle, DS4 und GPT-5.5. Die DS4-Fehler zeigen, dass Kontextmanagement vor Modellqualität kam.

Viertens: andere Fehlerbehandlung. OpenRouter veröffentlichte Scores für abgeschlossene Systeme. Unser Fusion-Lauf produzierte 51 partielle Läufe. Deshalb wurde kein finaler Fusion-Score behauptet.

Was ich vor dem nächsten Lauf ändern würde

Offizielle Judge-Konfiguration replizieren. Ein echter DRACO-Vergleich braucht denselben Judge oder mindestens eine klare Judge-Matrix.
Coverage immer neben Score berichten. Valid-only Score und All-tasks Score müssen zusammen stehen.
Kontextbudget vor jedem Modellaufruf erzwingen. 42 DS4-Kontextüberschreitungen sind ein Harness-Problem.
Finale Fusion-Antworten erst nach stabilen Panels judgen. Mit 51 partiellen Läufen wäre ein Fusion-Fullscore irreführend.
Artefakte standardisieren. Jede Judge-Variante braucht eigene Summary-Dateien, Kosten, Tokens, Modellversionen und Run-Manifeste.
Smoke-Sets vor Full-Runs nutzen. 100 DRACO-Tasks sind teuer genug, dass Blocklisten, Tooling und Judge erst auf 10 bis 15 Tasks stabil sein müssen.

Wie es weitergeht

Der nächste saubere Lauf sollte klein starten: 10 bis 15 DRACO-Tasks, identische Blocklisten, identische Tools, harte Kontextbudgets und automatische Retry-Regeln. Erst wenn kein Panelmitglied am Kontextlimit stirbt, lohnt sich ein neuer 100er-Lauf.

Danach sollten drei Scores getrennt berichtet werden: Solo-Modell, finaler Fusion-Output und Panel-Salvage. Für jeden Score gehören Judge-Modell, Judge-Modus, judge_runs, Coverage, Kosten, Tokens und Fehlerklassen in dieselbe Tabelle. Alles andere sieht präzise aus, ist aber nicht reproduzierbar.