Das Problem, das sie löst
Die Evaluierung von KI-Systemen – Coding-Agenten, analytische Ausgaben, Datenpipelines – im Datensatz-Maßstab trifft auf drei Randbedingungen zugleich. Korrektheit darf nicht davon abhängen, dass ein Modell ein anderes bewertet: Ein Judge, der nur die Prosa des Modells liest, lässt eine selbstsichere, falsche Antwort durch – und einer, der seine eigene Familie bewertet, schönt das Ergebnis. Ergebnisse müssen reproduzierbar sein, sonst lässt sich eine heute geschriebene Begründung morgen nicht mehr herleiten und verteidigen. Und Zehntausende Samples ohne Caching über eine Frontier-API zu bewerten ist schlicht teuer. Die Pipeline beantwortet alle drei zugleich: deterministische Ground Truth für Korrektheit, gepinnte und versionierte Konfiguration für Reproduzierbarkeit, aggressives Caching plus lokale Inferenz für die Kosten.
Drei Rollen, ein Verifikations-Layer, eine automatisierte Pipeline
Der Aufbau trennt drei Dinge, die üblicherweise vermischt werden – das Modell, das bewertet wird, das Modell, das bewertet, und die deterministische Schicht, die Fakten liefert – und ergänzt einen headless Track für Vergleiche in großer Menge über mehrere Formate. Nichts bewertet sich selbst, und kein semantisches Urteil ergeht, bevor der Code tatsächlich ausgeführt wurde.
Interaktives Rubric-Design
Rubric-Erstellung und Einzelfall-Spot-Checks in einem editor-integrierten lokalen Workflow (Continue + Ollama), plus eine native lokale Chat-App für Ad-hoc-Analysen. Schnelle Iteration, solange die Rubric instabil ist und Caching keine Rolle spielt.
Lokales Judging mit hohem Durchsatz
Ganze Datensätze auf einer einzelnen RTX 5090 (Blackwell) über vLLM mit nativen FP4-Gewichten, chunked prefill und Prefix-Caching der eingefrorenen Rubric. Continuous Batching hält die Karte ausgelastet.
Frontier-Arbiter für harte Fälle
Die härtesten semantischen, Sicherheits- und Ehrlichkeits-Urteile gehen an ein Frontier-Cloud-Modell über dessen Batch-API – mit der Rubric als gecachtem Prefix und den Sandbox-Fakten als Kontext.
Gehärtete Ausführungs-Sandbox
Nicht vertrauenswürdiger, modellgenerierter Code läuft nur in einem verwerfbaren, netzwerklosen, nicht-root, read-only Container – und liefert die deterministische Ground Truth (läuft er? bestehen die Tests?), die jedes Urteil verankert.
Multi-Format-A/B- & Vision-Evaluierung
Ein separater, vollautomatisierter Zweig auf Basis eines lokalen OpenAI-kompatiblen Inferenz-Servers und eines CLI-Eval-Harness. Er liest mehrere Eingabeformate – reinen Text, strukturierte Daten und gerenderte Bilder (u. a. Screenshots von Charts, Dashboards oder UI) – für paarweise A/B- und Vision-fähige Vergleiche und rendert die Ergebnisse in eine Review-Matrix. Keine interaktive UI im Loop: Ein Lauf ist ein einzelner reproduzierbarer Befehl, keine Sitzung.
Die Entscheidungen hinter den drei Ergebnissen
VRAM-Effizienz auf einer einzelnen 32-GB-Karte
Drei Einstellungen tragen den Großteil: flash attention an, ein q8_0-KV-Cache (der den Cache des 32B-Modells bei 16k-Kontext etwa von 4 GB auf 2 GB halbiert) und eine explizite Kontextlänge von 16384 Tokens. Letzteres wiegt schwerer, als es aussieht – ohne sie fällt die Laufzeit still auf einen Default von 4096 Tokens zurück, der Client schickt weiter 16k, während das Modell nur je 4k sieht, und Teile des zu bewertenden Codes fallen unbemerkt aus dem Fenster. Auf dem vLLM-Batch-Judge sind die Entsprechungen --kv-cache-dtype fp8, chunked prefill und --gpu-memory-utilization 0.90 – bewusst Rand gelassen, damit der KV-Cache wachsen kann, bevor er präemptiert.
Das Ergebnis: ein 32B-Judge und ein 7B-Autocomplete-Modell gemeinsam resident, mit Reserve – und die beiden Backends konkurrieren nie um denselben VRAM: Der lokale Judge gibt die Karte frei, bevor die Batch-Engine sie beansprucht.
Reduktion von Judge-Bias
Der Judge ist nie das getestete Modell; ein Modell, das seine eigene Familie bewertet, liest seine eigenen Gewohnheiten als Qualität. Deterministische Tool-Ausgaben – ruff, pyright und pytest, ausgeführt in der Sandbox – gehen als Fakten, vor dem semantischen Urteil ein, damit der Arbiter aus dem argumentiert, was der Code tatsächlich getan hat, statt an der Meinung eines Vormodells zu ankern. Confidence ist keine Single-Shot-Zahl: Sie entsteht aus Self-Consistency über mehrere Samples, mit dokumentierter Varianz statt versteckter.
Eine Präzisionsregel trägt das Ganze: Ein Modell, das selbst evaluiert wird, läuft mit vollen Gewichten – nur ein Judge oder eine Open-Weight-Baseline darf komprimiert (FP4) laufen. Bewertet man ein komprimiertes getestetes Modell, hat man das verkleinerte Abbild gemessen, nicht das Modell.
Senkung der Token-Kosten
Die Rubric steht am Anfang jeder Anfrage als identischer, ≥1024-Token gecachter Prefix. Ein Cache-Read kostet etwa ein Zehntel des Basis-Input-Preises; Batch-Verarbeitung nimmt weitere 50 % auf Input und Output und stapelt mit dem Cache – daher die ≈95 % Ersparnis auf dem wiederholten Teil. Weil ein 24-Stunden-Batch selbst die einstündige Cache-TTL überlebt, ist Within-Batch-Wiederverwendung nicht garantiert; deshalb wird der Lauf auf dem garantierten 50-%-Batch-Boden kalkuliert, mit einem Prime-Call plus gelegentlichem Heartbeat-Read warm gehalten, und Cache-Hits gelten als Upside, nicht als Annahme.
Bei anhaltender Masse übernimmt der lokale FP4-Judge zu praktisch Stromkosten, und der Cloud-Arbiter bleibt den strittigen und sicherheitskritischen Fällen vorbehalten – ein zweistufiges Routing, das den teuren Pfad schmal hält.
Modell-Code als nicht vertrauenswürdig behandeln
Weil ein Teil der Arbeit darin besteht, Systeme gezielt zum Scheitern zu bringen, gilt ihr Output standardmäßig als feindlich. Jede Ausführung ist verwerfbar (--rm), hat kein Netzwerk, ein read-only Dateisystem mit kleinem tmpfs-Kratzbereich, einen nicht-root-Nutzer, entzogene Linux-Capabilities bei intaktem seccomp-Standardprofil sowie harte CPU-, Speicher-, PID- und Laufzeit-Limits. Abhängigkeiten sind ins Image eingebacken, gerade damit der Lauf kein Netz braucht – ein Lauf mit Netzzugang ist kein sicherer Lauf.
Das Engineering oben ist nicht theoretisch. Das Panel unten zeigt gemessene Telemetrie aus einem einzelnen ~227-minütigen Produktionslauf – die Karte wird gleichzeitig an ihre Speicher-, Rechen- und Leistungsgrenze getrieben, bleibt dabei thermisch entspannt und kostet ungefähr den Strompreis im Betrieb.
Rubric-Lebenszyklus & Leitplanken
Eine Rubric verdient den Freeze erst, wenn sie vier Gates besteht. Sie muss diskriminieren – bestehen alle Samples oder scheitern alle, misst sie nichts, was für Capability-Elicitation fatal ist. Sie muss adversariales Härten gegen die Failure-Modes überstehen, die agentische Systeme wirklich zeigen: Reward-Hacking, fehlende Fehlerbehebung, halluzinierte Tool-Ergebnisse. Sie muss einen Kontaminations-Check bestehen – öffentliche Tasks werden als private neu gebaut. Und sie muss gepinnt sein: Semver plus Content-Hash, in die Eval-Metadaten geschrieben.
Nach dem Freeze ist eine einzige Zeichenänderung tabu – sie bricht den Cache und macht bereits bewertete Samples inkonsistent zum neuen Text. Die Begründung entsteht im selben Durchgang wie das Urteil, denn hier ist die Begründung der Deliverable: Sie lässt sich nicht von einem schwächeren Modell nachträglich erfinden, das die Argumentation nie geführt hat.
Tooling & Umgebung
In der Praxis: Regressionstest eines Coding-Modell-Upgrades im Datensatz-Maßstab
Ein Anbieter liefert eine neue Version des Coding-Modells hinter einem internen agentischen Tool. Die Leaderboard-Deltas sehen positiv aus, aber aggregierte Benchmarks verbergen, ob es bei den Failure-Modes regressiert ist, die das Team wirklich Geld kosten – stille Fehlerbehebungs-Ausfälle, fabrizierte bestehende Tests – und die proprietäre Codebase darf nicht an eine Cloud-API.
Ein reproduzierbares, verteidigbares Urteil über Tausende Samples liefern, verankert daran, ob Code tatsächlich läuft und besteht statt an der Prosa eines Modells – ohne eine Frontier-API-Rechnung, die linear mit der Sample-Zahl wächst.
Die Rubric einfrieren (Semver + Content-Hash); jedes Sample in der gehärteten Sandbox für deterministische Fakten ausführen (ruff, pyright, pytest); das Gros lokal auf dem FP4-32B-Judge bewerten; nur strittige und sicherheitskritische Fälle via Batch an den Cloud-Arbiter routen, mit der Rubric als gecachtem Prefix; Confidence aus Self-Consistency über Samples ziehen und die Varianz dokumentieren.
Ein Versionsvergleich auf identischen eingefrorenen Kriterien, der die stille Drift sichtbar macht, die aggregierte Scores verfehlen. Das Gros läuft zu praktisch Stromkosten, der Cloud-Pfad bleibt auf harte Fälle am garantierten 50-%-Batch-Boden beschränkt; und jedes Urteil ist Monate später reproduzierbar aus der gepinnten Rubric plus den dokumentierten Fakten – eine Audit-Eigenschaft, keine bloße Zahl. Das Upgrade geht live, oder nicht, auf Basis von Evidenz statt einer Leaderboard-Schlagzeile.
Wo sie sich auszahlt
- Einen Coding-Assistenten oder ein agentisches Tool prüfen, bevor es eine Codebasis berührt – die Ausgabe läuft in der gehärteten Sandbox, um zu messen, ob es sich wirklich von einem fehlschlagenden Test erholt oder klammheimlich einen bestehenden vortäuscht, statt seinem eigenen Bericht zu vertrauen.
- Dataset-QA und Präferenzdaten-Qualität für RLHF – das Trainingssignal selbst gegen eine feste, versionierte Rubric geprüft, sodass Konsistenz- und Abdeckungslücken an einer stabilen Referenz auffallen statt an schwankendem menschlichem Urteil.
- Regressionstest eines Modell-Upgrades – dieselbe eingefrorene Rubric über Versionen abgespielt, um den stillen Qualitätsdrift sichtbar zu machen, den aggregierte Benchmarks wegmitteln, wobei jede Differenz aus den gepinnten Kriterien reproduzierbar bleibt.
- Auswahl zwischen Kandidaten-Modellen für eine Aufgabe – nach deterministischer Korrektheit und kalibrierter, selbstkonsistenter Confidence; gelesen wird die Varianz über mehrere Samples, nicht ein einzelner glücklicher erster Eindruck.
- Modellgeschriebenen quantitativen Code ausführen – ein Backtest, ein Pricing-Skript, eine Datentransformation – in der gehärteten Sandbox, damit ein nur plausibel aussehendes Ergebnis deterministisch auffliegt, wenn die Tests scheitern, statt erst entdeckt zu werden, wenn die Position bereits im Buch steht.
- KI-geschriebene Recherche auf erfundene Zahlen prüfen – eine halluzinierte Zahl kostet weit mehr, wenn sie eine Kapitalallokation steuert, als wenn sie in einem Chatfenster steht; dieselbe Rubric, die Code bewertet, wird auf die Behauptung und ihre Quellen angewandt.
- Reproduzierbarkeit als Audit-Eigenschaft – datierte Modell-Pins, Temperatur null und eine content-gehashte Rubric bedeuten, dass ein Urteil Monate später herleitbar und verteidigbar bleibt – das macht aus einem Einzelurteil etwas, hinter das sich ein Risiko-Komitee tatsächlich stellen kann.
- Zweistufiges lokal/Cloud-Routing als Kostensteuerungs-Architektur – derselbe Kapitaleffizienz-Instinkt, angewandt auf Inferenz-Ausgaben: der Großteil bleibt beim lokalen Judge, und die Cloud wird nur dort bezahlt, wo ein Urteil wirklich davon abhängt.
Diese Pipeline ist der operative Kern hinter Code → Capital: Die Disziplin, die einen Coding-Agenten bewertet, ist dieselbe, die jedes KI-System bewertet, dessen Output Kapital berührt. In beiden ist der Fehler, der wehtut, die selbstsichere falsche Antwort – und die Abwehr ist dieselbe: den Code ausführen, das Urteil in Fakten verankern, die Referenz fest und versioniert halten und das Ganze günstig genug machen, um es oft laufen zu lassen.
Durchgängig gebaut und betrieben unter CTC AI Operations – von GPU-Konfiguration und Sandbox-Härtung über Rubric-Design bis zu Cloud-Batching und Kostenmodellierung.