Unsicherheit gestalten

Ein Widerspruch ist eine Information

Wenn eine KI-gestützte Oberfläche eine mögliche Zuordnung zwischen Dokument und Buchung findet, soll eine Person vielleicht handeln, obwohl nicht alle Felder übereinstimmen. Es liegt nahe, die Unsicherheit zu einem Badge wie „wahrscheinlich“, „geprüft“ oder einem Prozentwert zusammenzufassen. Trotzdem muss klar sein, was abweicht und welche Wirkung die Handlung hat.

Ein Widerspruch ist nicht nur ein Hindernis für das System. Er kann die wichtigste Information auf dem Bildschirm sein. Design sollte die Abweichung konkret prüfbar machen und zugleich erlauben, die Entscheidung aufzuschieben oder manuell weiterzugehen.

Zwei fiktive Quellen

Die Rechnung zeigt 84,90 Euro und den 4. Oktober. Die Buchung zeigt 89,40 Euro und den 5. Oktober. Das sind verfasste Werte, keine aus Kundendaten extrahierten Angaben. Kein Modell hat den Vergleich erzeugt und kein Finanzdienst ist verbunden. Das Konzept beginnt beim Widerspruch, statt eine Erklärung dafür zu erfinden.

Die Datumsabweichung könnte in bestimmten echten Kontexten unproblematisch sein, die Betragsabweichung eine eigene Prüfung erfordern. Diese Möglichkeit reicht nicht für eine Zuordnung. In einem echten Produkt würden fachliche Regeln und tatsächliche Belege den nächsten Schritt bestimmen.

Warum ein Konfidenz-Badge nicht reicht

Dieses Muster verlangt eine Entscheidung, ohne die nötigen Belege zu zeigen. „Wahrscheinlich“ sagt nicht, welches Feld unsicher ist. Ein Zahlenwert würde das ohne belegte Bedeutung und Kalibrierung nicht lösen. Selbst dann beantwortet er möglicherweise nicht die praktische Frage der Person.

Die Schaltfläche versteckt außerdem die Folge. Verknüpft Bestätigen ein Dokument, ändert es einen Datensatz oder genehmigt es eine Zahlung? Ein Bedienelement sollte die echte Handlung benennen. Dieses Konzept führt keine Zahlung aus und hält die Prüfung lokal. Ein Produktivsystem bräuchte eigene fachliche Anforderungen.

Belege neben das Feld stellen

Ein besserer Ausgangspunkt ist der Vergleich einzelner Felder. Quellen beschriften, Betrag und Datum aus beiden zeigen und die Abweichung mit Worten statt nur mit Farbe benennen. Originalinformationen bleiben vom bearbeiteten Wert getrennt.

So lässt sich jeweils eine Abweichung prüfen. Ist ein Quellenausschnitt in einem echten System verfügbar, sollte er ohne Verlust der Bearbeitung erreichbar sein. Fehlt er, sollte die Oberfläche diese Grenze benennen, statt eine erfundene Markierung auf ein fingiertes Dokument zu setzen.

Die Erklärung sollte die aktuelle Aufgabe unterstützen. „Betrag und Datum unterscheiden sich“ kann hilfreicher sein als eine lange Darstellung der Modellarchitektur. Genauere Herkunftsangaben bleiben dort wichtig, wo sie die Prüfung oder das Hinterfragen unterstützen.

Korrektur gehört zum Hauptablauf

Bearbeitung sollte keinen Abbruch der Aufgabe verlangen. Beschriftungen bleiben sichtbar, Eingaben nach Fehlern erhalten und Erklärungen stehen beim betroffenen Feld. Eine Zusammenfassung kann auf mehrere Fehler zeigen, ersetzt aber nicht die lokale Erklärung.

Einen geprüften Wert von einer automatisch geklärten Zuordnung unterscheiden. Eine Person kann nach Prüfung einen Wert festhalten und die Quellen trotzdem getrennt lassen. In diesem Prototyp meldet „Lokale Prüfung festhalten“ nur die eingegebenen Lehrwerte und löst keine externe Handlung aus.

Abbruch und manuelles Weitergehen ermöglichen

„Ich kann das nicht entscheiden“ hilft nur mit einem Weg weiter. Quellen getrennt halten, Prüfung ermöglichen und manuelle Eingabe anbieten. Bei der Rückkehr bleiben Kontext und Eingaben erhalten. Rückgängig machen oder Zurücksetzen muss benennen, was wiederhergestellt wird.

Ein System sollte nicht still aus einer Korrektur lernen, wenn dieses Verhalten nicht definiert und kommuniziert wurde. Ein Feld korrigieren, ein Modell trainieren und eine folgenreiche Handlung genehmigen sind getrennte Ereignisse. Ein gemeinsamer Klick nimmt informierte Kontrolle.

Den Weg nach dem Fehler prüfen

• Ist erkennbar, welche Felder widersprechen, und sind beide Quellen sichtbar?
• Sind vorgeschlagene Werte von Originalbelegen getrennt?
• Benannt die Handlung ihre Folge?
• Sind Bearbeitung, Aufschub und manuelle Arbeit ohne Kontextverlust möglich?
• Sind Fehler per Tastatur und Screenreader verständlich?

Eine realistische Evaluation umfasst fehlende Quellen, widersprüchliche Werte, erfolglose Änderungen und Entscheidungen, ein Ergebnis offen zu lassen. Eine Demonstration des Idealfalls belegt keine Zuverlässigkeit.

Quellen und Grenzen

Die Hinweise von Google PAIR zu Vertrauen und Fehlern sowie Microsoft HAX stützen den Fokus auf Belege, Korrektur und Weiterkommen. Die oben beschriebenen Entscheidungen sind meine redaktionelle Interpretation, kein validierter Finanzablauf. Es werden weder Extraktionsgenauigkeit, kalibrierte Konfidenz noch Studienergebnisse behauptet.