Analysen · Know-how

Woher die Fehler wirklich kommen.

Ein Prototyp-Score sagt nicht, was zu korrigieren ist. Nützlich ist, die Fehlschläge einzeln durchzugehen und für jeden zu entscheiden, ob er vom System stammt oder von dem, was man ihm zum Anwenden gegeben hat. In einem realen Fall hat die Antwort den Auftrag neu ausgerichtet.

Eine Kennzahl sagt nicht, was zu korrigieren ist

Ein Dokumentenprototyp liefert am Ende immer einen Prozentsatz. Das System bearbeitet einen gewissen Anteil der Fälle richtig, und sofort diskutiert das Team über das Modell: ein grösseres nehmen, die Anweisungen nachjustieren, die Suche anreichern.

Diese Diskussion kommt zu früh, denn die Kennzahl sagt nichts darüber, wo der Mangel sitzt. Ein System kann scheitern, weil es die Anfrage falsch verstanden hat, weil es das falsche Dokument geholt hat, oder weil die erwartete Antwort im anvertrauten Regelwerk nirgends steht. Diese drei Fehlschläge sehen sich in einer Ergebnistabelle ähnlich und verlangen völlig unterschiedliche Arbeit.

Der einzige Schritt, der sie trennt, ist mühsam und lässt sich nicht automatisieren: die Fehlschläge einzeln durchgehen und für jeden entscheiden, wo die Ursache liegt.

Jeden Fehlschlag einzeln zuordnen

In einem kürzlichen Prototyp haben wir sämtliche gescheiterten Fälle durchgesehen und jeden einer einzigen Ursache zugewiesen. Das Ergebnis hat den Auftrag neu ausgerichtet.

Mehr als die Hälfte der Fehlschläge kam nicht vom System. Sie kam daher, dass man von ihm verlangte, eine Regel anzuwenden, die nirgends geschrieben stand. Keine Einstellung, kein leistungsfähigeres Modell, keine bessere Suche ändert daran etwas: Die richtige Antwort existiert im Korpus nicht.

Was die Obergrenze an einem Projekt ändert

Einem Kunden diese Obergrenze mitzuteilen ist unangenehm, und es ist das nützlichste Gespräch des Auftrags. Es verschiebt das Projekt von einer technischen Baustelle zu einer Baustelle der Doktrin: Zu produzieren ist nicht eine bessere künstliche Intelligenz, sondern die fehlenden Regeln, geschrieben, validiert, verbindlich.

Es hat auch eine praktische Folge. Jede fehlende Regel wird zu einer benannten Zeile, mit der Zahl der Fälle, die sie freigeben würde. Die Liste der Lücken ordnet sich damit nach Volumen, und der Entscheid, eine bestimmte Regel zu schreiben oder nicht, stützt sich auf eine Zahl statt auf einen Eindruck.

Eine Prüfung sei hinzugefügt, die ihr Gewicht hat: Im Lauf des Auftrags erhielten wir eine erweiterte Fassung des Regelwerks, und wir haben sie über dieselbe Stichprobe laufen lassen, statt ihr aufs Wort zu glauben. Sie schloss keine der festgestellten Lücken, und ihre gemessene Wirkung liess sich an einer Handvoll Fälle abzählen. Eine Erweiterung, die beim Lesen substanziell wirkt, kann dort, wo es zählt, nichts ändern.

Zuerst die deterministischen Regeln, das Modell zum Auffangen

Der Reflex besteht darin, alle Fälle vom Modell bearbeiten zu lassen. Das ist am schnellsten gebaut und hinterher am schwersten zu vertreten.

Wir gehen umgekehrt vor. Ein Satz deterministischer Regeln, im Code geschrieben, bearbeitet zuerst das, was ohne Auslegung entscheidbar ist. Bei diesem Prototyp haben diese Regeln mehr als die Hälfte des Volumens ohne einen einzigen Modellaufruf aufgenommen, bei gleicher Trefferquote. Das Modell greift nur auffangend ein, bei dem, was die Regeln nicht entscheiden konnten.

Drei Vorteile, in dieser Reihenfolge der Bedeutung. Der deterministische Teil ist testbar: Er lässt sich mit Unit-Tests abdecken, und eine Regression wird sichtbar. Er ist einem Prüfer erklärbar, was keine Modellausgabe wirklich ist. Und er verbraucht nichts, womit die Kostenfrage aus der Debatte fällt.

Die Folgerung ist es wert, ausgesprochen zu werden: Der Anteil der ohne Modell bearbeiteten Fälle ist ein Reifegrad des Regelwerks. Je genauer es ist, desto grösser wird der deterministische Anteil. Ein unscharfer Korpus schiebt alles in die Auslegung.

Über die Kennung aufrufen, nie über Ähnlichkeit

Im Lauf des Auftrags wurde uns ein Einwand vorgetragen, und er war begründet. Die Anwendung zeigte eine Gegenüberstellung des bearbeiteten Falls mit vergleichbaren Fällen, was den Eindruck eines Zauberknopfs erweckte: Das System finde die Antwort, indem es nach Ähnlichem suche.

Die Antwort passt in einen Satz, und sie betrifft die Architektur. Die Antwort wird im Regelwerk über die Kennung geholt, deterministisch. Die Ähnlichkeit dient nur der Ergänzung der Anzeige, nie der Entscheidung. Der Test, der das beweist, ist einfach: Man kann die Ähnlichkeitsgegenüberstellung vollständig entfernen, ohne dass sich am erzeugten Dokument ein Komma ändert.

Nichts generieren, was verbindlich ist

Bei einem Dokument mit rechtlicher oder vertraglicher Wirkung gilt die Regel absolut: Das Modell formuliert nicht. Der Referenztext wird Wort für Wort aus dem validierten Korpus übernommen, und das Modell setzt nur zusammen und personalisiert, was zu personalisieren ist.

Diese Vorgabe ist leichter einzuhalten, als es scheint, denn sie entspricht dem, was eine Fachperson ohnehin tut: Sie erfindet keine Klausel neu, sie nimmt die freigegebene Vorlage und passt sie an. Ein System, das verbindlichen Inhalt generiert, macht es nicht besser als ein Mensch, es macht etwas, wozu niemand berechtigt ist.

Die Lücke sichtbar machen, nicht nur den Fehlschlag

Die Vorrichtung, die diese Zuordnung möglich gemacht hat, verdient eine Beschreibung, denn sie ist übertragbar. Wir haben einen zweiten Referenzkorpus aufgebaut, unabhängig von dem des Kunden, und er wird nur dann herangezogen, wenn das Hauptregelwerk zur Situation schweigt.

Diese bedingte Auslösung macht den ganzen Unterschied. Würden beide Korpora zusammen abgefragt, antwortete das System besser, und niemand sähe, dass das Regelwerk des Kunden unzureichend war: Die Lücke würde still geschlossen. Ruft man den zweiten nur beim Schweigen des ersten auf, wird jeder Rückgriff zu einem Signal, zählbar und am Bildschirm zuordenbar.

Das ist eine widersinnig erscheinende Wahl: Wir verschlechtern die scheinbare Leistung des Systems bewusst, um eine Information sichtbar zu machen. Diese Information ist mehr wert als die Punkte, die sie kostet.

Der Fehler, den kein besseres Modell verringern wird

Eine Kategorie von Fehlschlägen widersteht jeder Verbesserung, und an ihr arbeiten wir als Nächstes. Das System erkennt die Kategorie des Falls richtig, holt das für diese Kategorie vorgesehene Dokument, und dieses Dokument behandelt die besondere Lage des Dossiers dennoch nicht.

In der Kette ist nichts falsch. Die Einordnung stimmt, der Abruf stimmt, und das Ergebnis passt nicht. Kein leistungsfähigeres Modell korrigiert das, denn es gibt keinen Verständnisfehler zu korrigieren: Es fehlt eine Prüfung, die den Inhalt des gewählten Dokuments dem tatsächlichen Inhalt der Anfrage gegenüberstellt und lieber verweigert als ausliefert, wenn dieser Abgleich scheitert.

Diese Kategorie ist der Grund, weshalb wir Leistungstabellen pro Etappe misstrauen. Eine Kette, in der jedes Glied einen guten Wert ausweist, kann ein unbrauchbares Ergebnis liefern, und nur eine durchgehende Bewertung, auf während der Konstruktion ungesehenen Fällen, bringt das ans Licht.

Was sich übertragen lässt

Vier Handgriffe, anwendbar auf jedes System, das ein schriftliches Regelwerk auf Einzelfälle anwendet.

Auf während der Konstruktion ungesehenen Fällen bewerten, sonst misst die Kennzahl das Gedächtnis des Systems und nicht seine Fähigkeit. Jeden Fehlschlag einer einzigen Ursache zuordnen, was Stunden kostet und Wochen umlenkt. Die Obergrenze bei unverändertem Regelwerk berechnen, um zu wissen, wie viel des verbleibenden Abstands auf die Informatik entfällt und wie viel auf das Schreiben. Und das Schweigen des Regelwerks messbar machen, damit das Fehlende sichtbar wird, statt lautlos geschlossen zu werden.

Das Ergebnis dieses Vorgehens ist nicht nur ein System. Es ist eine Liste fehlender Regeln, geordnet nach der Zahl der Fälle, die sie freigeben würden, und der Kunde behält sie, auch wenn er den Anbieter wechselt.

Ein Problem schildern →