Was aussah, als würde es funktionieren

Ein Ausfall ist ein gutes Ereignis. Etwas hört auf zu arbeiten, jemand merkt es, jemand repariert es. Der unangenehme Fall ist der andere: Etwas läuft weiter, liefert ein Ergebnis, sieht von aussen unverändert aus und tut dabei etwas anderes als das, was sein Name verspricht. Die vorige Fassung fand sechs solche Stellen, indem sie den Messort wechselte. Diese beiden Fassungen finden drei weitere, indem sie fragen: Was passiert eigentlich, wenn etwas schiefgeht?

Das Sicherheitsnetz war ein anderer Richter

Vier der zwölf Analysen hatten einen Rückfallweg. Konnte ihr Modell nicht geladen werden, übernahm eine Regelmechanik. Das klingt nach Vorsicht und war als Vorsicht gemeint. Nur urteilt diese Mechanik anders: auf echten deutschen Rückmeldungen beim Schweregrad in rund zwei von drei Fällen, beim Thema in knapp drei von vier, und die häufigste Themenklasse des Korpus kennt sie überhaupt nicht.

Seit dieser Fassung liefern alle sieben Modellanalysen im Fehlerfall ein ehrliches Nichts. Der Block bleibt stehen, sagt aber, dass er eingeschränkt ist, nennt den Grund maschinenlesbar und trägt die Sicherheit null. Und die Marke steht auch in der Datenbank, denn sie beantwortet als einzige die Frage, die hinterher zählt: Welche Auswertungen sind entstanden, während ein Modell weg war? Das ist dieselbe Linie wie in v2.5.7, wo fremdsprachige Texte als solche erkannt und sichtbar zurückgestellt werden, statt still falsch gelesen zu werden. Hier gilt sie für den Ausfall eines Modells.

Ein Modell wechselt, vierzehn Blöcke stehen still

Die zweite Fassung tauscht das Modell, das erkennt, worum es einem Absender geht. Ein Modelltausch ist die Änderung, bei der man zu Recht nervös wird: Er soll etwas bewegen, aber nur das Richtige. Deshalb ist nicht die Verbesserung die eigentliche Zusage, sondern die Gegenprobe.

Stimmung, Emotion, Ursache, Schweregrad, Risiko, Thema, Trend, Wettbewerb und Geo stehen über alle Rückmeldungen still. An denselben Texten gelesen ist das Ergebnis sieben besser, zweiundzwanzig gleich, eines schlechter. Drei von vier bekannten Fehlgriffen sind repariert, und der lehrreichste ist dieser: Eine Beitragserhöhung wurde als Reisefall gelesen, woraufhin die Antwort einen Schadensfall erfand, den es nie gegeben hatte. Sie fragt jetzt nach der Mitgliedsnummer.

Ein Risikowert, den jeder umsonst bekam

Der dritte Befund hat dieselbe Form wie die ersten beiden. Das Kündigungsrisiko aus der Kundenhistorie summiert sieben Faktoren. Einer davon war ein Sockel, den jeder Kunde bekam, weil seine Eingangsgrösse im ausgelieferten Stand nie gefüllt wurde und ein leerer Wert dort als schlechtes Zeichen galt.

Jeder Kunde stand damit grundlos eine Stufe höher. Der Sockel ist weg, die Formel selbst unverändert. Auch das ist wieder derselbe Fall: Der Wert wurde berechnet, war plausibel, hatte einen Namen und sagte nichts über den Kunden aus, für den er berechnet wurde.

Was Betreiber tun müssen

• Ein Upgrade braucht diesmal einen Datenbankschritt. Ohne ihn startet die Anwendung, aber eine neue Spalte fehlt, und mit ihr die Überwachung des siebten Modells. Es ist ausgerechnet das mit der schwächsten dokumentierten Kennzahl gewesen, das bis dahin nicht überwacht werden konnte.
• Die Vergleichswerte der Drift-Überwachung beschreiben nach dem Update ein Vorgängermodell und schlagen deshalb an. Sie gehören neu gesetzt, aber erst nach dem ersten Betriebszeitraum. Wer sie sofort setzt, schreibt den Messkorpus als Normalzustand fest.
• Wer eigene Auswertungen auf dem Absichtslabel fährt, bekommt auf rund einem Viertel der Fälle ein anderes. Das ist beabsichtigt und die ganze Änderung.

Der Nebensatz, der am meisten sagt

Mit dem Rückfallweg sind rund siebentausendsiebenhundert Zeilen Code verschwunden, ohne dass sich ein einziges Urteil bewegt hat. Weniger Code, dieselben Antworten, ein ehrlicherer Fehlerfall. Das ist die Art Zahl, die sich schlecht bewerben lässt und viel darüber sagt, was in einer Software eigentlich arbeitet und was nur danach aussieht.