YoursSarcastically/eval-design

Was macht eval-design?

Du entwirfst die Messung, nicht das Produkt. Die Ausgabe dieses Skills ist eine Entscheidung, die jemand in einem Raum verteidigen kann, keine Zahl.

Meistens lautet die Entscheidung was als Nächstes repariert werden soll. Eine Evaluierung, die nur Systeme rankt, ist ein Report; eine Evaluierung, die die beiden Dinge benennt, die am meisten kosten, und beweist, dass die Reparatur funktioniert hat, wenn du sie erneut ausführst, ist eine Entwicklungsschleife. Baue für die zweite – die Fehlertaxonomie und die Aufschlüsselung nach Kriterien sind wichtiger als die Gesamtpunktzahl, denn das sind die Teile, an denen jemand handeln kann.

Die Position

Vier Regeln. Es sind Meinungen, und sie sind der Kern dieses Skills.

1. Kein Bauchgefühl. „Es fühlt sich besser an“ ist kein Ergebnis. Wenn eine Änderung nicht als Bewegung auf einem definierten Kriterium, gemessen an einem festen Satz, ausgedrückt werden kann, wurde sie nicht evaluiert. Verschiebe sie, wenn du magst – behaupte nur nicht, dass sie getestet wurde.

2. Jedes Kriterium muss widersprechbar sein. Ein Kriterium, bei dem zwei sorgfältige Prüfer nicht auf gegensätzlichen Seiten landen könnten, misst nichts. „Ist die Ausgabe hilfreich?“ ist kein Kriterium. „Gibt die Antwort das Rückgabefenster in Tagen an?“ ist eines. Jedes Kriterium in einer Rubrik trägt die spezifische Meinungsverschiedenheit in sich, die es beilegen soll – siehe references/rubric-design.md.

3. Kein LLM-als-Richter standardmäßig. Ein Richter ist ein System mit eigener Fehlerrate, und ein nicht validierter Richter wäscht diesen Fehler in deine Gesamtzahl ein. Menschen labeln zuerst, der Richter wird anhand dieser Labels kalibriert, und die Übereinstimmung wird neben jedem Ergebnis veröffentlicht, das der Richter produziert hat. Siehe references/judges.md.

4. Berichte die Baseline, sonst ist die Evaluierung Marketing. Regex, eine Schlüsselwortregel, das aktuelle Produktionssystem, nichts tun. Ungefähr ein Drittel der ausgelieferten KI-Funktionen verliert gegen etwas, das in mindestens einem Kriterium nichts kostet, und das willst du herausfinden, bevor ein Personalchef oder ein VP es tut.

Zwei strukturelle Regeln folgen daraus:

• Gates sind Böden, keine Gewichte. Ein Sicherheits-, Rechts- oder Vertrauenskriterium wird nicht gegen die Durchschnittsleistung getauscht. Ein System unterhalb des Bodens ist kein Kandidat zu irgendeinem Preis. Gewichtete Durchschnitte verbergen genau das.
• Konfidenzintervalle oder kein Ranking. Bei n=150 ist ein 3-Punkte-Unterschied Rauschen. Systeme innerhalb des Rauschens zu ranken, ist der häufigste Weg, wie Evaluierungsarbeit den Leser in die Irre führt.

Arbeitsablauf

Arbeite in dieser Reihenfolge. Überspringe nicht die Bewertung – jeder Fehler einer Evaluierung führt auf etwas zurück, das darüber übersprungen wurde.

1. Finde die Entscheidung. Was ändert sich aufgrund des Ergebnisses? „Welches Modell liefern wir aus“, „Kann das unbeaufsichtigt laufen“, „Hat die Prompt-Änderung zu einer Regression geführt“. Wenn sich nichts ändert, höre auf und sage das – dies ist der wertvollste Moment im gesamten Prozess, und die ehrliche Antwort ist manchmal „du brauchst keine Evaluierung“.
2. Schreibe zuerst die Fehlertaxonomie. Vor den Kriterien. Sammle 30–50 reale Ausgaben, lies jede einzelne und clustere, was schiefgelaufen ist. Kriterien, die aus beobachteten Fehlern abgeleitet wurden, schlagen Kriterien, die aus der Fantasie abgeleitet wurden, jedes Mal. → references/failure-taxonomy.md
3. Wandle die Taxonomie in Kriterien um. Jedes erhält ein Gewicht, eine Widersprechbarkeit und optional ein Gate. → references/rubric-design.md
4. Baue den goldenen Satz. Geschichtet, adversariell, versioniert und klein genug, dass ein Mensch ihn tatsächlich labelt. → references/golden-sets.md
5. Label mit Menschen, miss die Übereinstimmung. Wenn zwei Labeler nicht übereinstimmen können, ist die Rubrik kaputt, nicht die Labeler. Repariere die Rubrik und label neu. → references/statistics.md
6. Erst jetzt erwäge einen Richter, und nur kalibriert. → references/judges.md
7. Führe jedes System inklusive einer Nicht-KI-Baseline aus, schreibe results.json und rendere. → references/scorecard-spec.md
8. Schreibe das Urteil selbst. Die Bewertungstafel zeigt Zahlen; ein Mensch formuliert den getätigten Handel und was die Entscheidung umkehren würde.

Rendern

python3 skills/eval-design/scripts/render_scorecard.py results.json --md

Schreibt eine eigenständige scorecard.html (keine externen Anfragen, hell und dunkel) und eine SUMMARY.md zum Lesen im Repo. Schema: references/scorecard-spec.md.

python3 skills/eval-design/scripts/validate_rubric.py results.json

Schlägt bei den Fehlern fehl, die eine Bewertungstafel unehrlich machen: Gewichte, die sich nicht zu 1 addieren, Kriterien ohne angegebene Widersprechbarkeit, Gates ohne Begründung, fehlende Baseline oder ein behauptetes Ranking innerhalb des Konfidenzintervalls.

Wann dieser Skill nicht verwendet werden sollte

• Eine einmalige Prompt-Anpassung ohne zugehörige Entscheidung. Sieh dir einfach die Ausgabe an.
• Du hast keine Nutzer und keine Beispiele. Besorge zuerst 30 reale Eingaben. Eine auf vorgestellten Eingaben aufgebaute Evaluierung misst deine Vorstellungskraft.
• Die Aufgabe hat eine korrekte Antwort, die ein Programm überprüfen kann – Arithmetik, gültiges JSON, ein kompilierender Build. Schreibe den Check, keine Rubrik.
• Jemand will eine Zahl, um eine bereits getroffene Entscheidung zu rechtfertigen. Sage das laut, anstatt die Evaluierung zu bauen.

Referenzdateien

Lade bei Bedarf; lies sie nicht alle auf einmal.

Datei	Lesen, wenn
references/rubric-design.md	Kriterien schreiben oder reparieren
references/failure-taxonomy.md	Mit realen Ausgaben beginnen
references/golden-sets.md	Fälle auswählen und schichten
references/judges.md	Jemand schlägt LLM-als-Richter vor
references/statistics.md	Stichprobengröße, KIs, Übereinstimmung, Drift
references/scorecard-spec.md	results.json schreiben
references/antipatterns.md	Die Evaluierung eines anderen überprüfen