LLM-Evals mit kleinem Referenzdatensatz: Was 12 Fälle leisten

Zwölf Fälle sind zu wenig, um die allgemeine Qualität eines LLMs zu beziffern. Sie können trotzdem eine produktionskritische Grenze zuverlässig schützen – wenn jeder Fall eine konkrete Fehlerklasse repräsentiert, die Auswertung mehr prüft als den Modelltext und mehrere Läufe gegen ein vorab definiertes Gate antreten.

Genau dafür nutzt Abundance einen kleinen, versionierten Datensatz zur Claim-Verifikation. Das akzeptierte Artefakt enthält drei Läufe: 11/12, 10/12 und 11/12 bestandene Fälle. Das sind zusammen 32 von 36 Ausführungen und eine mittlere Pass-Rate von 88,9 %. Diese Zahl ist kein universeller Qualitätswert. Sie gehört zu einem festgepinnten Modellprofil, Prompt-Version claim-verification-v3, Datensatzversion 2026-08-25.1 und einer eng definierten Komponente.

Der Schwesterartikel LangGraph Deep Research: Zitate verifizieren statt nur verlinken beschreibt die Laufzeitarchitektur. Hier geht es ausschließlich um das Eval-Design und seine Aussagekraft.

Was die zwölf Fälle tatsächlich prüfen

Der öffentliche Claim-Verifikationsdatensatz enthält zwölf Golden Cases aus zehn Kategorien. Darunter sind Public Policy, Public Health, Technologie, Safety, Quellenprovenienz, Ökonomie, Forschungsmethoden, Forecasting, Finance und Rechtspolitik.

Jeder Fall enthält:

• eine Forschungsfrage;
• genau einen strukturierten Claim;
• genau einen dazu zugelassenen Beleg;
• das erwartete Verdict;
• einen Textausschnitt, der im wörtlichen Zitat vorkommen muss;
• bei Bedarf Begriffe, die in den dokumentierten Limitationen auftauchen müssen.

Der Satz deckt alle vier möglichen Verdicts ab: supports, contradicts, insufficient und unverifiable. Die Fälle zielen bewusst auf Grenzentscheidungen statt auf zwölf Varianten derselben einfachen Unterstützung.

Die URLs in diesen Fixtures verwenden bewusst example-Domains. Es sind kontrollierte synthetische Komponentenfälle, keine Stichprobe echter Webrecherchen.

Ein Fall besteht nur, wenn alle Dimensionen stimmen

Eine bloße Übereinstimmung beim Verdict reicht nicht. Das öffentliche claim_verification_eval_harness.py bewertet für jeden Fall mehrere Grenzen:

1. richtige Claim-ID;
2. richtige Beleg-ID;
3. richtiges Verdict;
4. korrekter Claim-Fingerprint;
5. korrekter Beleg-Fingerprint;
6. wörtlich an den Beleg gebundenes Zitat;
7. erwartete Belegpassage im Zitat;
8. erwartete Einschränkungen, falls der Fall welche vorgibt.

Sobald eine Dimension fehlschlägt, besteht der gesamte Fall nicht. Das macht die Metrik streng, aber interpretierbar: Ein Modell kann semantisch richtig liegen und trotzdem durchfallen, wenn es das passende Zitat nicht liefert oder eine notwendige Aktualitätsgrenze verschweigt.

Die Prüfstruktur verhindert außerdem, dass ein scheinbar gutes Ergebnis durch erfundene IDs oder Quotes entsteht. Der Eval-Code verwendet dieselben deterministischen Hash- und Quote-Bindungen wie die Laufzeitanwendung.

Warum der alte Check 0 von 12 erreicht

Die öffentliche Legacy-Baseline bildet bewusst eine schwache Heuristik ab: Ist ein Zitatverweis vorhanden, gilt der Claim als unterstützt. Die Baseline vergibt deshalb für jedes Paar supports und liefert kein wörtliches Zitat.

Auf dem zusammengesetzten Gate besteht sie 0/12 Fälle. Das bedeutet nicht, dass die alte Lösung semantisch in allen zwölf Fällen falsch lag. Selbst die direkten Support-Fälle scheitern, weil das erwartete, gebundene Zitat fehlt. Bei Widerspruchs-, Insufficient- und Unverifiable-Fällen kommt zusätzlich das falsche Verdict hinzu.

Die korrekte Aussage lautet daher:

Die Legacy-Heuristik besteht keinen der zwölf vollständigen Vertragsfälle.

„0 % Claim-Verifikationsgenauigkeit“ wäre irreführend, weil das Gate Provenienz, Zitatbindung, Semantik und Limitationen gemeinsam bewertet.

Das Promotion-Gate vor dem Lauf festlegen

Der Kandidat wird nicht anhand seines besten Laufs freigegeben. Der Harness führt mehrere Trials aus und entscheidet nach vorher festgelegten Regeln:

python -m abundance_research.claim_verification_eval_harness \
  --model deepseek-v4-flash \
  --runs 3 \
  --max-concurrency 3 \
  --output evals/results/claim-verification-candidate.json

Für eine Freigabe fordert der Code:

• mindestens drei Läufe;
• mindestens 80 % Pass-Rate im Mittel;
• mindestens 70 % in jedem einzelnen Lauf;
• eine messbare Verbesserung gegenüber der Baseline;
• dieselbe Datensatzversion für Kandidat und Baseline.

Das Modellprofil ist über den Alias deepseek-v4-flash auf die Revision deepseek/deepseek-v4-flash-0731 festgelegt. Auch die Verifier-Version wird im Artefakt gespeichert. Damit ist nachvollziehbar, welche Kombination die Messung erzeugt hat; ein später geänderter Prompt oder Modellalias kann nicht still dieselbe Zahl beanspruchen.

Was in den drei Läufen schiefging

Das akzeptierte, im Repository versionierte v3-Baseline-Artefakt zeigt nicht nur den Mittelwert, sondern jeden Fehler:

Der Mittelwert beträgt 88,9 %, der schwächste Lauf 83,3 %. Beides liegt über dem Gate. Interessanter als die Freigabe sind die Fehlersignaturen: Das System schwankt nicht bei IDs oder erfundenen Quotes, sondern bei einigen semantischen Grenzziehungen und einmal bei einer fehlenden Einschränkung. Genau daraus lassen sich neue Regressionstests ableiten.

Was zwölf Fälle leisten können

Ein kleiner Datensatz ist nützlich, wenn die Aufgabe eng und die Fälle absichtlich gewählt sind. Hier kann er:

• eine bekannte schwache Heuristik zuverlässig zurückweisen;
• alle vier Output-Klassen mindestens einmal abdecken;
• sicherheitsrelevante Randfälle wie Prompt Injection, Kausalität und veraltete Quellen festhalten;
• Schema-, Provenienz- und Quote-Regressionsfehler sofort sichtbar machen;
• stochastische Schwankung durch wiederholte Trials zeigen;
• einen Pull Request oder Modellwechsel an einem stabilen Mindestvertrag messen.

Das ist näher an einem ausführbaren Komponentenvertrag als an einem Benchmark-Leaderboard. Zwölf sorgfältig ausgewählte Fälle können für so einen Vertrag wertvoller sein als Hunderte unkuratierte Beispiele, weil bei jedem Fehler klar ist, welche Grenze gebrochen wurde.

Was zwölf Fälle nicht leisten können

Aus dem Ergebnis folgen ausdrücklich nicht:

• „Das Modell verifiziert 89 % aller wissenschaftlichen Claims korrekt.“
• „Die Quote-Bindung beweist die Wahrheit eines Claims.“
• „Die Leistung ist auf andere Modelle, Prompts oder Sprachen übertragbar.“
• „Der Datensatz bildet die Verteilung realer Nutzerfragen ab.“
• „Drei Läufe liefern bereits ein enges statistisches Konfidenzintervall.“

Die zwölf Fixtures sind klein, synthetisch und absichtlich kuratiert. Sie messen eine Komponente mit jeweils einem Claim und einem Beleg. Reale Reports enthalten mehrere Claims, mehrere Belege, uneindeutige Exzerpte und Fehler aus vorgelagerten Recherchephasen.

Abundance hält deshalb mehrere Ebenen getrennt: Die zwölf Claim-Verifikationsfälle sind nicht zwölf Fälle aus dem größeren Berichtssatz. Daneben existieren zehn eigene Evidence-Assessment-Fixtures und ein separater Datensatz mit 30 Report-Referenzfällen. Jede Suite beantwortet eine andere Frage.

So würde ich den Datensatz weiterentwickeln

Der nächste sinnvolle Ausbau ist nicht einfach „mehr Fälle“, sondern mehr belegte Fehlerabdeckung:

1. Jeden echten Produktionsfehler als minimierten Regression Case sichern.
2. Mehrdeutige Multi-Beleg-Claims mit Support und Gegenbeleg ergänzen.
3. Deutsche und englische Paare separat messen.
4. Lange Exzerpte, Tabellen und numerische Einheiten aufnehmen.
5. Einen unveränderten Holdout-Satz von den Entwicklungsfällen trennen.
6. Zusätzlich eine kleine, manuell geprüfte Stichprobe echter Rechercheberichte auditieren.

Erst dieser letzte Punkt verbindet den Komponentenvertrag mit der realen Einsatzverteilung. Bis dahin bleibt die belastbare Aussage eng: Das festgepinnt konfigurierte System bestand in drei dokumentierten Läufen 11, 10 und 11 von zwölf versionierten Vertragsfällen.

Primärquellen und Versionsstand

Datensatz, Harness und Ergebnisartefakt stammen aus dem öffentlichen Abundance-Commit b4fc4c3. Der frühere Tag v1.0.0 enthält den produktionsreifen Kern, aber noch nicht dieses nachgelieferte Eval-Gate. Die verlinkte Academic-DeepSearch-Case-Study ordnet die Messung in das Gesamtprodukt ein.

Zur Case StudyAcademic DeepSearch→