Evaluierung einer typed-decision-Konfiguration
Das Evaluierungsset ist das Produkt. Die Genauigkeit eines System-One-Modells wird dominiert davon, wie die Frage formuliert wurde, und die Fehlerart ist still – es liefert eine selbstbewusste, typgerechte, falsche Antwort. Ohne Beschriftungen kannst du nicht unterscheiden, ob eine schlechte Frage oder ein schlechtes Modell das Problem ist.
Gemessen: Die Umformulierung der Kriterien verbesserte ein Open-Source-Modell von 4/15 auf 14/15 bei 15 Datensätzen. Keine Modelländerung. Dann ergab der gleiche Vergleich bei 150 Datensätzen 61% insgesamt gegenüber Jevs 97% – die 15-Datensatz-Messung war ein Artefakt eines kleinen, leichten Sets. Beide Fakten zeigen: Formulierungen beeinflussen Ergebnisse, und kleine Sets lügen über die Richtung.
Ausführen
python ~/.claude/skills/jev-eval/scripts/sweep.py labelled.json configs.json \
--backend jev|von --question <name>
labelled.json ist [{"id","state","truth"}]. configs.json ordnet einem Konfigurationsnamen {"instructions", "criteria"} zu – ein Diktat von Optionen macht es zu einer Choice, eine Liste von Stufen macht es zu einem Score, das Weglassen macht es zu einem Noul. Das Skript liest den Jev-Schlüssel aus dem Keychain (typesafe-api-key), gibt die Genauigkeit pro Konfiguration aus, kennzeichnet die Streuung als ROBUST oder FRAGIL, durchläuft Schwellenwerte für Nouls und bewertet die Confidence-Gate-Funktion.
Reales Ergebnis, 50 Datensätze zu Agent-Shell-Befehlsrisiko, nur das Backend geändert:
config Genauigkeit ms/rec
A Kurze Einzeiler 45/50 410 <- Jev
B Ausführliche Kriterien 49/50 415
C Ausführlich + Ausnahmen 46/50 418
D Absichtlich faul 44/50 411
Streuung: 44/50 bis 49/50 (ROBUST - Formulierung ist nicht lasttragend)
A Kurze Einzeiler 9/50 66 <- Von, gleiche Konfigurationen
B Ausführliche Kriterien 23/50 121
C Ausführlich + Ausnahmen 15/50 129
D Absichtlich faul 22/50 53
Streuung: 9/50 bis 23/50 (FRAGIL - und die Obergrenze ist immer noch nicht nutzbar)
Lies zuerst die Obergrenze, dann die Streuung. Ein FRAGILES Modell, dessen beste Konfiguration 23/50 erreicht, ist kein Formulierungsproblem, das du durch besseres Schreiben lösen kannst – es ist das falsche Modell für diese Frage.
1. Erstelle das Set
Mindestens 50 Datensätze, 200+ vor der Auslieferung. Ziehe aus dem echten Datenstrom, nicht aus synthetischen Daten.
- Füge die langweilige Mitte ein, nicht nur saubere Beispiele und dramatische Randfälle
- Füge Datensätze mit fehlenden/kaputten Metadaten ein – dort scheitern Klassifikatoren
- Beschrifte durch Lesen des Datensatzes, bevor ein Modell läuft. Beschrifte nie aus Modellausgaben
- Speichere als JSON mit dem rohen Datensatz plus einem
truth-Feld
[{"id":"D-1994","state":"...vollständiger Datensatztext...","truth":"inbound_prospect"}]
Wenn du selbst einen Datensatz nicht sicher beschriften kannst, kann das Modell das auch nicht – entweder verwerfen oder die Frage so anpassen, dass die Antwort eindeutig ist.
2. Durchlaufe Formulierungen, nicht nur Modelle
Der Kernschritt. Schreibe 3–4 wirklich unterschiedliche Kriterienkonfigurationen und führe alle aus:
- A – ein kurzer Einzeiler pro Option (was jeder zuerst schreibt)
- B – 3–4 Sätze pro Option mit konkreten Beispielen
- C – B plus eine explizite Voreinstellung und explizite Ausnahmen ("NUR wenn…")
- D – absichtlich faul, vier oder fünf Wörter, als Bodentest
Berichte die Genauigkeit pro Konfiguration pro Modell:
config JEV VON LAYA (Führung-Triage, n=50)
A Kurze Einzeiler 47/50 34/50 21/50
B Ausführliche Kriterien 49/50 28/50 15/50
C Ausführlich + Ausnahmen 48/50 24/50 19/50
D Absichtlich faul 48/50 22/50 24/50
Lies zuerst den Boden, dann die Streuung. Der Boden ist "Kann dieses Modell die Aufgabe überhaupt erfüllen, wenn ich es schlecht formuliere?"; die Streuung ist "Wie viel Wartungsaufwand wird es mich kosten?". Gemessen an der Befehlsaufgabe erreicht jedes gehostete Modell einen Boden von 82-92% (Haiku 46-48, GPT-4.1-mini 45-50, Jev 44-49, GPT-5-mini 41-49), während Von einen Boden von 9/50 und Laya 18/50 hat. Beachte, dass Jev nicht formulierungsstabiler ist als ein kleines LLM – es schwankt um dieselben zehn Punkte. Was du kaufst, ist der Boden, nicht die Immunität.
Beachte, was die Führungsspalte NICHT zeigt: einen klaren Trend "mehr Details = besser". Vons beste Konfiguration ist hier die kurze. Was auch immer die Zahlen eines Open-Source-Modells bewegt, ist Empfindlichkeit gegenüber der Oberflächenform, nicht Verständnis – also gehe nicht davon aus, dass deine nächste Kriterienüberarbeitung es verbessert – führe das Set erneut aus.
3. Durchlaufe Schwellenwerte für jeden Noul
Versende niemals 0,5. Durchlaufe und lies die Kurve:
for t in [0.5,0.6,0.7,0.75,0.8,0.85,0.9,0.95]:
tp = sum(p>=t and y for p,y in z); fp = sum(p>=t and not y for p,y in z)
fn = sum(p< t and y for p,y in z); tn = sum(p< t and not y for p,y in z)
print(f"{t} P={tp/max(tp+fp,1):.2f} R={tp/max(tp+fn,1):.2f} acc={(tp+tn)/len(z):.2f}")
Verschiedene Modelle haben unterschiedliche Böden. Jevs Noul lag bei 0,2–0,5 für Datensätze, die offensichtlich sauber waren, während Claude auf 0,0 ging – also war sein effektiver Grenzwert bei ~0,85. Ein auf einem Modell optimierter Schwellenwert überträgt sich nicht auf ein anderes. Wiederhole den Durchlauf, wenn du das Modell wechselst.
4. Bewerte das Confidence-Gate ehrlich
Zwei Zahlen, immer zusammen:
errs = [r for r in rows if r.pred != r.truth]
rights = [r for r in rows if r.pred == r.truth]
for g in [0.5,0.7,0.9]:
caught = sum(r.conf < g for r in errs) # Fehler, die das Gate eskaliert
escalated = sum(r.conf < g for r in rows) # Gesamtvolumen eskaliert
print(f"Gate {g}: fängt {caught}/{len(errs)} Fehler, eskaliert {escalated/len(rows):.0%} des Volumens")
Ein Gate, das 10/11 Fehler fängt, aber 93% des Volumens eskaliert, ist kein funktionierendes Gate – es ist ein langsamer Pfad mit Extra-Schritten. Gute Kalibrierung ohne gute Genauigkeit bringt nichts.
5. Bericht
- Genauigkeit pro Konfiguration pro Modell, mit hervorgehobener Streuung
- Gewählter Schwellenwert pro Noul, mit dem Durchlauf, der ihn rechtfertigt
- Gate: gefangene Fehler und eskaliertes Volumen
- Prognostizierte Latenz und Kosten pro 1k bei Produktionsvolumen
- Explizite Angabe der Evaluierungsset-Größe und was sie nicht abdeckt
Kleine Sets lügen. 15 Datensätze, bei denen zwei Modelle beide 100% erreichen, unterscheiden nichts – sag das so, anstatt zu implizieren, dass die Gleichheit bedeutungsvoll ist.
Verwandt
jev-integrate ist der Verkabelungs-Workflow, den dieses hier speist. jev-audit findet Kandidaten, die eine Evaluierung wert sind.