Das Quality Gate: kein schlechter Snapshot geht live
Zweistufige Prüfung vor jeder Promotion — billiger Sanity-Check, dann Eval-Set gegen den aktiven Snapshot. Aktivierung nur bei mindestens gleicher Qualität.
Immutable Versionen und Snapshots sorgen dafür, dass ein neuer Stand erst durch aktive Promotion live geht. Die Frage ist: Wer drückt den Knopf — und woher weiß er, dass der neue Stand nicht schlechter ist? Das ist die Aufgabe des Quality Gates im Knowledge Service. Es läuft vor jeder Aktivierung, zweistufig.
Stufe 1 — Sanity-Check
Billig und schnell, fängt grobe Unfälle ab. Das klassische Symptom: ein PDF liefert plötzlich 8 Chunks statt vorher 500 — fast immer kaputtes Layout-Parsing. Solche Ausreißer gegenüber der Vorgängerversion blocken die Promotion automatisch.
| Signal | Schwelle (Beispiel) | Aktion |
|---|---|---|
chunk_count ggü. Vorversion | Abweichung > ±50 % | blockieren |
| leere / triviale Chunks | > 20 % | blockieren |
| Parse-Warnings | harte Parse-Fehler | blockieren |
Der Ingest selbst meldet nur die Zahlen — die Bewertung passiert hier.
Stufe 2 — Eval-Set
Aussagekräftig, aber teurer. Pro Collection gibt es ein kleines, festes Set aus Frage → erwartete Quelle:
// eval-set/lughaty.json
[
{
"question": "Wie bildet man den Dual im Arabischen?",
"expectedSource": "arabische-grammatik.pdf",
"expectedOrdinalRange": [140, 150]
},
{
"question": "Was ist die Mondsonne (الشمسية والقمرية)?",
"expectedSource": "ausspracheregeln.pdf"
}
]
Der Kandidaten-Snapshot wird gegen dieses Set getestet:
| Metrik | Bedeutung |
|---|---|
| Retrieval-Hit-Rate | Anteil der Fragen, bei denen die erwartete Quelle in Top-k liegt |
| LLM-as-Judge (optional) | Claude bewertet, ob die Antwort die Frage geerdet beantwortet |
| Vergleich | Kandidat muss ≥ Score des aktuell aktiven Snapshots erreichen |
Der letzte Punkt ist der entscheidende: Es reicht nicht, „gut genug" zu sein — ein neuer Snapshot muss mindestens so gut wie der aktive sein, um ihn abzulösen. Damit kann eine Promotion den Stand nie verschlechtern.
Das Gate in der Antwort
Eine erfolgreiche Promotion liefert das Gate-Resultat transparent zurück:
{
"snapshotId": "s5a4b3c2-...",
"status": "active",
"qualityGate": {
"sanityCheck": "pass",
"evalHitRate": 0.91,
"previousHitRate": 0.88,
"verdict": "promoted"
}
}
Blockiert das Gate, bleibt der Snapshot draft und die API antwortet mit
422 QUALITY_GATE_FAILED samt Grund:
{
"code": "QUALITY_GATE_FAILED",
"reason": "chunk_count dropped from 500 to 8 (sanity-check)",
"snapshotId": "s5a4b3c2-...",
"status": "draft"
}
Warum das die Architektur vereinfacht
Ein schlechter Ingest wird gar nicht erst aktiv.
Das Gate ist der Grund, warum Rollback im Alltag selten gebraucht wird. Statt nach einem Vorfall zu reagieren, verhindert Dokki den Vorfall: Die Verschlechterung wird vor der Aktivierung erkannt, der alte Stand bleibt live. Rollback ist nur noch für den Restfall da, dass eine Schwäche erst im echten Betrieb sichtbar wird.