Zwei Modelle, eine Grenze

Die Aufgabe war gewöhnlich: prüfen, ob Änderungen an einer Verarbeitungspipeline deren Ergebnis verbessern oder verschlechtern, gemessen an einer von Menschen erfassten Ground Truth. Die Daten waren es nicht: Datensätze mit personenbezogenen Angaben, die den Rechner, auf dem sie liegen, nicht verlassen dürfen. Ein Frontier-Modell in der Cloud war das richtige Werkzeug, um die Auswertung zu entwerfen, das Tooling dafür zu schreiben und die Ergebnisse zu lesen, und das falsche, um ihm die Daten zu geben. Ein lokales Modell auf demselben Rechner durfte alles anfassen, hatte aber wenig Kontext und war bei der Analyse langsam und unzuverlässig.

Die Arbeitsteilung, bei der wir gelandet sind, passt in einen Satz: Das Cloud-Modell liest nie einen Datensatz, das lokale Modell muss kaum nachdenken. Alles dazwischen ist Tooling, das dafür sorgt, dass beides stimmt. Fünf Lehren aus dem Aufbau.

1. Die gemeinsame Sprache sind Statistiken, nicht Werte

Über die Grenze geht ein kleines statistisches Vokabular, das ein Ergebnis beschreibt, ohne es zu zitieren. Pro Feld: die Exact-Match-Rate, die mittlere Accuracy (1 minus normalisierte Edit-Distanz), der Anteil der Werte, die noch ein Mensch ansehen müsste. Pro Datensatz: ein Score über seine Felder. Pro Feld und Datensatz: genau eine Fehlerklasse aus einem festen Katalog. Die Verteilung der Klassen zeigt, welche Art von Fehler überwiegt, und der Vergleich zweier Läufe wird zu einer Übergangsmatrix zwischen den Klassen. Wo Positionen zählen, zeigt eine Maske aus Punkten und Fragezeichen, an welchen Stellen sich die Werte unterscheiden, ohne ein einziges Zeichen von einer der beiden Seiten zu enthalten. Längendifferenzen, in Buckets gruppiert, verraten, ob ganze Zeilen fehlen oder nur einzelne Zeichen.

Das SQL dafür schrieb das Cloud-Modell an einer kleinen anonymisierten Stichprobe, die es sehen durfte. Das lokale Modell führte dasselbe SQL auf den echten Daten aus und gab die Tabellen zurück. Jede spätere Frage wurde zu einer weiteren Abfrage, die Quoten, Verteilungen oder eine Confusion Matrix lieferte: „Steht der erwartete Wert überhaupt in den Rohdaten?“, „Sind die kleinen Abweichungen nur Satzzeichen?“, „Wie oft läge eine Korrektur über die Prüfziffer richtig?“ Die Statistiken reichten aus, um über Mechanismen nachzudenken, statt nur Fehler zu zählen.

2. Das lokale Modell braucht ein Runbook, keine Aufgabe

Ein lokales Modell mit begrenztem Kontext plant schlecht und vergisst, was es getan hat. Funktioniert hat ein Runbook: nummerierte Schritte, je ein Befehl, die genauen Zeilen, die es zurückmelden soll, die erwartete Ausgabe und ein Satz zum Warum, damit es bei einer Überraschung nicht improvisiert. Nach solchen Runbooks erledigte es Seeding, Baseline-Läufe, Neuauswertungen und Abfragen und berichtete ehrlich, auch über das, was es nicht verstand.

Zwei Regeln fehlten im ersten Runbook und kosteten einen Tag: niemals das Datenbank-Volume löschen, weil dort die Baseline liegt; und jede Ausgabe in eine Datei umleiten und nur die Zeilen zurücklesen, die der Schritt nennt. Ohne die zweite Regel lud das Modell eine Liste mit Zehntausenden Zeilen in seinen Kontext, lief in eine Context-Compaction nach der anderen und hatte Mühe, seinen Bericht zusammenzusetzen.

3. Das Tooling muss das Modell vor seinem eigenen Output schützen

An dieser Liste war das lokale Modell nicht schuld. Das Vergleichstool stellte eine Stichprobe einem vollständigen Lauf gegenüber und wertete jeden Datensatz, der auf einer Seite fehlte, als Fehler. Die Kennzahlen waren dadurch absurd negativ, und das Urteil kippte zwischen ähnlichen Läufen hin und her. Das lokale Modell erkannte das Artefakt richtig. Das hätte es gar nicht erst tun müssen.

Der Fix gehörte ins Tool: nur Datensätze vergleichen, die in beiden Läufen vorkommen, und die einseitigen nur zählen; jede Liste begrenzen und die vollständige Fassung in eine Datei schreiben; die teuren Kennzahlen einmal pro Lauf vorberechnen, damit ein Vergleich Sekunden dauert. Danach passte ein ganzer Durchlauf in ein Kontextfenster.

4. Befunde des lokalen Modells sind Behauptungen, geprüft wird im Code

Das lokale Modell verfolgt Code gut und merkt nicht, wann es falschliegt. Es meldete, ein Normalisierungsschritt existiere in der Produktion, aber nicht in unserem lokalen Pfad. Das hätte eine ganze Klasse von Vergleichen zu unseren Ungunsten verzerrt. Die Behauptung kam mit Dateinamen und Zeilennummern und war trotzdem falsch: Dieselbe Tabelle gibt es ein zweites Mal unter anderem Namen, in einem Schritt, den unsere Konfiguration sehr wohl ausführt. Eine Abfrage auf den echten Daten bestätigte das mit einer glatten Null.

Das Cloud-Modell konnte das prüfen, weil der Code nicht sensibel ist, nur die Daten. Jeder Befund durchlief denselben Loop: Das lokale Modell misst, das Cloud-Modell liest den betreffenden Code und bestätigt entweder den Mechanismus oder schickt eine genauere Abfrage zurück. Einige Befunde wurden auf diesem Weg umgestoßen, bevor jemand danach handelte.

5. Befunde als Messungen festhalten, nicht als Meinungen

Das Ergebnis war keine Zusammenfassung, sondern ein Ticket. Es nennt die Datengrundlage, belegt jeden Befund mit Datum, Lauf und Statistik, verknüpft jede Verbesserungsidee mit der Kennzahl, die sie bestätigen oder widerlegen würde. Den Entwurf schrieb das Cloud-Modell aus den Statistiken. Angelegt wurde das Ticket erst, nachdem ein Mensch mit Zugriff auf die Daten es geprüft hatte.

Was diese Disziplin wert ist, zeigte sich an den Prüfziffern. Das Produktivsystem markiert Werte, bei denen es unsicher ist, und gibt sie an einen Menschen weiter. Dem Cloud-Modell fiel auf, dass die Prüfziffern eines Feldes ein einzelnes unbekanntes Zeichen eindeutig bestimmen, und es fragte nach der Korrekturquote. Das lokale Modell hat sie gemessen: Die meisten Felder mit genau einer unsicheren Stelle lassen sich so auflösen, die Korrektur trifft fast immer die Ground Truth, und die Fehlerquote liegt dort, wo die Arithmetik sie erwarten lässt. Dieselbe Abfrage fand außerdem nicht markierte Werte, deren eigene Prüfziffer nicht aufgeht.

Was der Aufbau kostet

Zwei Modelle, ein Runbook pro Phase, ein Wrapper-Skript und ein Schema aus Views, die Werte in Quoten, Verteilungen und Klassen übersetzen. Die meisten der ersten Tage flossen in dieses Tooling. Dafür bekamen wir einen Loop, in der die sensible Seite ein deterministischer Executor mit kleinem Kontext ist und die denkende Seite nie einen Grund hat, nach den Daten zu fragen. Wenn Ihre Daten den Rechner nicht verlassen dürfen und Ihr bestes Modell nicht darauf läuft, ist genau dieser Trade-off die Methode.