Die KI-Ergebnisbewertung beantwortet auf Anfrage die Frage „Ist dieses konkrete Ergebnis gut?“. Sie beantwortet nicht „Ist unser Modell seit letztem Monat stillschweigend schlechter geworden?“, denn niemand wird sich daran erinnern, diese Frage für jede in Produktion laufende Pipeline zum richtigen Zeitpunkt zu stellen. Kontinuierliches Monitoring ist dieselbe Bewertung, nur geplant statt angefordert — die Sache, die Qualitätsregressionen tatsächlich abfängt, bevor ein Kunde es tut.
Das ist ein kleines Detail mit überproportional viel Engineering dahinter: Nichts auf der Crowdee-Plattform lief zuvor je nach einem wiederkehrenden Zeitplan. Jeder bestehende Job — Verifikationsläufe, Crowd-Aufgaben, Enrichment — wird einmal ausgelöst und ist dann fertig. Monitoring zu bauen bedeutete, erstmals wiederkehrende Zeitplanung einzuführen: Pro Monitoring-Zeitplan wird ein Cron-Musterdurchlauf registriert (stündlich, täglich oder wöchentlich) und sauber wieder abgebaut, wenn ein Zeitplan pausiert oder gelöscht wird. Es ist eine kleine Oberfläche, aber neue Infrastruktur, keine Variation von etwas, das wir schon hatten.
Der Durchlauf eines Zeitplans betrachtet abgeschlossene Läufe im Geltungsbereich — organisations- oder projektweit, passend zum Quelltyp des Zeitplans — aus dem vorherigen Zeitraum, die er noch nicht ausgewertet hat, wobei er mit seiner eigenen Historie abgleicht, sodass derselbe Lauf vom selben Zeitplan nie zweimal bewertet wird. Findet sich nichts, wird ein leerer Zeitraum erfasst, und es geht weiter — ein leerer Zeitraum ist kein Fehlschlag, nur Stille. Findet sich etwas, wird ein normaler KI-Ergebnisbewertungs-Batch für den zuletzt geeigneten Lauf verteilt, auf genau demselben Weg, den auch eine manuelle Bewertungsanfrage nutzen würde. Sobald das Crowd-Panel das Quorum erreicht, wird der Gesamttransparenzwert in den Monitoring-Lauf zurückgeschrieben.
Wir haben bewusst keinen festen Qualitätsschwellenwert ausgeliefert, den man einmal konfiguriert und dann vergisst. Eine Regel „Wert unter 70 ist schlecht“ verallgemeinert nicht — eine Pipeline, die normalerweise um 60 liegt, driftet nicht bei 58, und eine, die normalerweise 95 erreicht, driftet ganz sicher bei 80. Stattdessen wird jeder bewertete Lauf mit dem eigenen gleitenden Durchschnitt vorheriger abgeschlossener Läufe genau dieses Zeitplans verglichen und markiert, sobald er spürbar von seiner eigenen Historie abweicht. Der allererste von einem Zeitplan ausgewertete Lauf hat keine Vergleichsbasis, wird also nie markiert — Drift ist naturgemäß ein Signal ab dem zweiten Lauf, und das ist in Ordnung, denn eine Veränderung lässt sich ohnehin nicht aus einem einzigen Datenpunkt erkennen.
Hier ist der Teil, den wir nicht schöngeredet haben: Aktuell wählt jeder Durchlauf genau einen Lauf als Stichprobe aus, obwohl die Zeitplan-Konfiguration bereits eine Stichprobenstrategie (alle, ein zufälliger Prozentsatz oder eine feste Anzahl pro Zeitraum) und eine Stichprobenanzahl akzeptiert. Diese Felder werden gespeichert und validiert, aber pro Durchlauf wird immer nur der eine zuletzt geeignete Lauf gezogen. Wir haben uns entschieden, die Planungs- und Drift-Erkennungsinfrastruktur korrekt auszuliefern, statt sie zu verzögern, bis die Mehrfach-Stichproben-Unterstützung fertig ist — und wir sagen das lieber offen in der Dokumentation, als Sie es selbst entdecken zu lassen, wenn Ihre Stichprobenzahlen nicht mit dem übereinstimmen, was Sie konfiguriert haben. Wenn Sie heute engmaschigere Abdeckung benötigen, ist eine kürzere Taktung — stündlich statt täglich — der Behelf, bis die Mehrfach-Stichprobe kommt.
Ein leerer Durchlauf ist kostenlos. Ein Durchlauf, der eine Bewertung verteilt, kostet so viel wie eine manuelle KI-Ergebnisbewertung — standardmäßig 45 Credits —, da es sich um genau denselben zugrunde liegenden Vorgang handelt, nur durch einen Timer statt durch eine Anfrage ausgelöst. Zeitplan-Felder und die vollständige Drift-Erkennungsformel finden Sie in der Dokumentation zum Kontinuierlichen Monitoring.
Artikel teilen:
