Warum Wiederholbarkeit mehr zählt als Demos

Ein Demo beweist, dass etwas einmal unter günstigen Bedingungen funktioniert. Wiederholbarkeit beweist, dass ein Team es erneut schafft, wenn Inputs,...

Warum Wiederholbarkeit mehr zählt als Demos

Der zweite Durchlauf ist die Wahrheit

Beim ersten Durchlauf gab es Applaus. Das Modell fand die Klausel, das Dashboard leuchtete auf, die Antwort zitierte das richtige Dokument, und der Raum entspannte sich auf genau die Art, wie sich Räume entspannen, wenn eine Budgetzeile gerade leichter zu verteidigen geworden ist. Das Team hatte sorgfältig geprobt. Die Daten waren sauber genug, die Fragen waren sinnvoll, das Netzwerk verhielt sich, der Laptop des Anbieters hatte nicht beschlossen, eine kleine Heizung zu werden, und niemand fragte nach dem einen Randfall, der höflich in eine spätere Phase verschoben worden war. Es war eine gute Demo. Gute Demos sind nützlich. Sie zeigen Möglichkeiten. Sie geben den Menschen ein gemeinsames Objekt zum Diskutieren. Sie machen eine abstrakte Fähigkeit sichtbar.

Dann kam der zweite Durchlauf. Gleicher Anwendungsfall, aber jetzt mit den Daten der letzten Woche, einer anderen Bedienperson, einem Quelldokument mit einer seltsamen Tabelle, einer Richtlinienaktualisierung, die den Prompt nicht erreicht hatte, und einer Führungskraft, die zusah, weil das Ergebnis eine echte Entscheidung prägen würde. Die Antwort war immer noch flüssig. Das war nicht das Problem. Das Problem war, dass niemand sagen konnte, ob es dieselbe Antwort aus denselben Gründen war oder eine andere Antwort mit demselben Ton. Die Demo hatte bewiesen, dass das System funktionieren konnte. Sie hatte nicht bewiesen, dass die Organisation die Leistung wiederholen konnte.

Hier verändert ernsthafte KI-Arbeit ihren Charakter. Eine Demo fragt: Können wir es einmal zum Laufen bringen. Der Betrieb fragt: Können wir es wieder zum Laufen bringen, erklären, warum es funktioniert hat, wissen, wann es das nicht tat, und die Belege aufbewahren, wenn sechs Monate später jemand fragt. Wiederholbarkeit ist nicht das Gegenteil von Innovation. Sie ist der Teil der Innovation, der den Kontakt mit Gehaltsabrechnung, Recht, Sicherheit, Kunden, Bürgern, Prüfern, müden Mitarbeitern und der stillen Feindseligkeit echter Daten überlebt.

Die meisten Fehlschläge im KI-Betrieb kommen nicht als filmischer Zusammenbruch. Sie kommen als kleine Unterschiede, die niemand reproduzieren kann. Ein Abrufergebnis ändert sich. Eine Prompt-Aktualisierung behebt einen Fall und schwächt einen anderen. Ein Modell-Upgrade verschiebt die Entscheidungsgrenze. Ein Quellfeed lässt ein Feld weg. Eine manuelle Korrektur wird in einem System erfasst, aber nicht in einem anderen. Die Organisation hat immer noch ein funktionierendes System im theatralischen Sinne. Sie hat kein System mehr, das dieselbe Geschichte zweimal erzählen kann.

Eine Demo ist ein Foto. Wiederholbarkeit ist das Negativ, die Kamera, die Lichtnotizen und die Fähigkeit, das Bild erneut aufzunehmen, wenn der Kunde den Raum verändert.

Eine Demo verbirgt den langweiligen Vertrag

Eine Demo darf selektiv sein. Sie hat eine Geschichte, einen Anfang, einen befriedigenden Klick und meistens einen Beispieldatensatz, der gekämmt wurde wie ein Kind vor den Schulfotos. Das ist kein Betrug. Es ist Kommunikation. Die Probleme beginnen, wenn die Organisation Kommunikation mit einem Betriebsvertrag verwechselt. Die Demo definiert nicht die Aktualität der Quellen, Versionsgrenzen, Fallback-Pfade, Rechte der menschlichen Prüfung, Fehlersprache, Aufbewahrung oder die genaue Bedingung, unter der das System die Antwort verweigern muss. Diese Details liegen oft direkt außerhalb des Bildschirms, sehen unmodisch aus und warten darauf, später allen eine Rechnung zu stellen.

Wiederholbarkeit macht den Vertrag sichtbar. Sie fragt, welche Eingabe die Eingabe ist, nicht die nächstliegende Kopie. Sie fragt, welche Regelversion die Antwort eingeschränkt hat, nicht welche Richtlinienseite vertraut aussah. Sie fragt, ob die Reihenfolge des Abrufs stabil ist, ob Gleichstände deterministisch behandelt werden, ob Prompts versioniert sind, ob Modellparameter benannt werden können, ob Tool-Aufrufe erfasst werden, ob die Bedienperson einen Fall erneut abspielen kann und ob eine Übersteuerung den Arbeitsablauf ändert oder nur ein Protokoll verziert. Das sind keine philosophischen Fragen. Sie sind die Verkabelung hinter zuverlässiger Arbeit.

Das Schwierige daran ist, dass Wiederholbarkeit am Anfang langsamer wirkt. Ein Team, das eine Demo anstrebt, kann den schnellsten Weg durch den Garten nehmen. Ein Team, das Wiederholbarkeit aufbaut, muss Pflastersteine verlegen, die Tore beschriften und entscheiden, wer den Schlüssel zum Schuppen besitzt. Das kann bürokratisch wirken für Menschen, die nur die erste Woche sehen. Beim dritten Vorfall beginnt es, gnädig zu wirken.

KI-Systeme erhöhen den Bedarf an dieser Gnade, weil sie legitime Variabilität einführen. Sprachmodelle können abgetastet werden. Der Abruf kann nahe Kandidaten an die Oberfläche bringen. Menschliches Urteilsvermögen kann sich unterscheiden. Dokumente können mehrdeutig sein. Ein wiederholbares System tut nicht so, als wäre die Welt in jedem Detail deterministisch. Es unterscheidet zulässige Varianz von unkontrollierter Varianz. Es sagt, dieses Feld darf variieren, weil die Nutzerin oder der Nutzer in natürlicher Sprache fragt, aber diese Quellenmenge darf nicht variieren ohne eine dokumentierte Korpusänderung. Diese Zusammenfassungsformulierung darf sich unterscheiden, aber die Anspruchsgrundlage nicht. Dieser Wert kann sich nach einem Modell-Upgrade verschieben, aber das Upgrade muss nachvollziehbar sein.

Gleiche Eingabe ist kein einfacher Begriff

Menschen sagen gleiche Eingabe, als wäre der Begriff offensichtlich. In echten Systemen ist er das selten. Die sichtbare Nutzerfrage ist nur ein Teil. Die tatsächliche Eingabe kann abgerufene Dokumente, versteckte Anweisungen, System-Prompts, Tool-Schemas, Richtlinienregeln, Nutzerrolle, Zeit, Gebietsschema, Zugriffsrechte, zwischengespeicherte Datensätze, Feature-Flags, Modellversion, Einbettungsindex, Schwellenwerteinstellungen und die stille Annahme umfassen, dass die Aktualisierung des Datenlagers von gestern erfolgreich war. Gleiche Eingabe kann ein überraschend voller Raum werden.

Deshalb beginnt Wiederholbarkeit mit der Identität der Eingabe. Das System sollte wissen, welche Datensätze verfügbar waren, welche ausgewählt wurden, welche Version des Korpus durchsucht wurde, welche Prompt-Vorlage verwendet wurde, welcher Richtliniensatz angewendet wurde, welches Modell lief, welche Tools erlaubt waren und welche menschliche Rolle die Ausgabe akzeptiert hat. Wenn das nach viel klingt, dann weil der Entscheidungspfad bereits groß war. Die einzige Frage ist, ob die Organisation es zugibt.

Der Unterschied ist am wichtigsten, wenn Ergebnisse angefochten werden. Wenn eine Kundin fragt, warum ein Anspruch abgelehnt wurde, ein Krankenhaus fragt, warum ein Risikohinweis erschien, eine Bank fragt, warum ein Fall eskaliert wurde, oder eine öffentliche Behörde fragt, warum eine Bürgerin oder ein Bürger eine bestimmte Anweisung erhalten hat, kann die Organisation nicht allein mit der sichtbaren Frage antworten. Sie braucht den Betriebskontext. Ohne ihn wird die Vorfallprüfung zu einer höflichen Séance, bei der alle Protokolle, Erinnerungen und Screenshots heraufbeschwören und dabei so tun, als wäre das eine Methode.

Die Eingabeidentität schützt Teams auch vor unberechtigter Schuldzuweisung. Wenn sich ein Ergebnis geändert hat, weil sich ein Quelldokument geändert hat, ist das ein Inhaltsproblem. Wenn es sich geändert hat, weil ein Index mit anderen Parametern neu aufgebaut wurde, ist das ein Abrufproblem. Wenn es sich geändert hat, weil ein Modell aktualisiert wurde, ist das ein Bereitstellungsproblem. Wenn es sich geändert hat, weil eine Bedienperson einen anderen Arbeitsablauf verwendet hat, ist das ein Prozessproblem. All das als Modellverhalten zu bezeichnen, ist bequem und falsch, eine starke Kombination in Organisationen mit vollen Kalendern.

Wiederholbarkeit bedeutet nicht, alles einzufrieren

Es gibt einen bequemen Einwand, dass Wiederholbarkeit die Anpassungsfähigkeit abtötet. Das tut sie nicht. Sie beseitigt Rätselraten. Ein wiederholbarer Betrieb kann weiterhin Modelle verbessern, Prompts ändern, Regeln aktualisieren, Daten bereinigen, Quellen hinzufügen, Schwellenwerte justieren und Arbeitsabläufe neu gestalten. Der Unterschied besteht darin, dass Änderungen zu benannten Ereignissen werden und nicht zu Wetterlagen. Wenn sich das Ergebnis bewegt, kann das Team fragen, welche kontrollierte Änderung es bewegt hat. So wird Verbesserung zu Lernen statt zu Aberglaube mit einem Versionshinweis.

Die besten Betriebsteams behandeln Änderungen als Experimente mit Grenzen. Sie behalten Basisfälle bei. Sie führen Schattenbewertungen durch. Sie vergleichen alte und neue Abrufergebnisse. Sie prüfen Beispiele mit hoher Wirkung vor der Übernahme. Sie dokumentieren, wer die Änderung genehmigt hat und warum. Sie legen Rollback-Bedingungen fest, bevor der Startanruf erfolgt, nicht während der Supportkanal glüht. Das ist keine theatralische Vorsicht. So kommen Teams schneller voran, sobald das erste System zählt.

Es gibt auch eine moralische Dimension, auch wenn sie besser klar ausgesprochen wird. Wenn ein System Geld, Arbeit, Fürsorge, Priorität, Durchsetzung oder Zugang beeinflusst, verdienen die betroffenen Menschen mehr als eine Vorführung. Sie verdienen einen Prozess, der sich selbst erklären kann. Wiederholbarkeit schafft die Voraussetzung für diese Erklärung. Man kann keinen Verschwindetrick prüfen. Man kann nur klatschen oder sich beschweren.

Gute Wiederholbarkeit trennt daher das Stabile vom Flexiblen. Stabil sind die Aufzeichnungen darüber, was passiert ist, die Versionskennungen, der Bewertungssatz, die Quellenherkunft, die Regelverantwortung, der Genehmigungspfad und die Ablehnungsbedingungen. Flexibel sind die Techniken, die zur Verbesserung innerhalb dieser Grenzen eingesetzt werden. Die Kunst besteht darin, zu wissen, was was ist. Viele Organisationen machen es umgekehrt. Sie frieren den Prozess ein, weil niemand dem System vertraut, und erlauben dann versteckte technische Änderungen, weil niemand sie sehen kann. Das ist Governance mit einem Jalousievorhang.

Der Stack existiert nicht, um Verbesserungen zu verlangsamen. Er existiert, damit Verbesserungen einen Boden haben und Vorfälle einen sinnvollen Ort zum Landen finden.

Der Bewertungssatz ist ein Arbeitsgedächtnis

Jede ausgereifte Organisation braucht eine kleine Sammlung von Fällen, die sie nicht vergisst. Kein synthetischer Benchmark, der gewählt wurde, weil er in einem Bericht beeindruckend aussieht, sondern ein lebendiges Evaluierungsset aus den schwierigen Fällen, die dem Team etwas beigebracht haben. Das Dokument mit widersprüchlichen Daten. Die Kundenanfrage, die zwei Richtlinien vermischt. Die Rechnung, bei der die Tabellenextraktion fast funktioniert. Die medizinische Notiz mit mehrdeutiger Abkürzung. Der Beschaffungsfall, bei dem die Rechtsgrundlage wichtiger ist als die offensichtliche Antwort. Diese Fälle werden zum institutionellen Gedächtnis.

Ein wiederholbares System führt diese Fälle aus, wenn sich etwas ändert. Das Ziel ist nicht, alte Ausgaben zu verehren. Manchmal war die alte Ausgabe falsch. Das Ziel ist, Bewegung zu verstehen. Hat die neue Version den Fall aus dem richtigen Grund verbessert. Hat sie ein fragiles, aber wichtiges Verhalten gebrochen. Ist sie selbstbewusster geworden, während sie Beweise verloren hat. Hat sie eine andere Quelle gewählt. Hat sie dieselbe Schlussfolgerung mit einem schwächeren Weg erzeugt. Bei ernsthafter Arbeit zählt der Weg, denn dieselbe Antwort aus dem falschen Grund ist nicht dieselbe Antwort.

Hier verlieren viele demo-getriebene Programme die Kontrolle. Sie messen Nutzerzufriedenheit, Latenz und allgemeine Genauigkeit, aber sie halten die schmerzhaften Fälle nicht in der Nähe. Das Ergebnis ist ein System, das insgesamt besser aussehen kann, während es an den Rändern schlechter wird, die zählen. Durchschnittswerte sind nützlich. An den Rändern kommt die Beschwerde mit Anhängen an.

Das Evaluierungsset sollte auch Ablehnungsfälle enthalten. Ein System, das immer antwortet, ist nicht hilfreich. Es ist bedürftig. Wiederholbarkeit erfordert, dass das System konsequent ablehnt, wenn Quellen fehlen, Autorität abwesend ist, das Vertrauen zu schwach ist, ein Nutzer außerhalb seiner Rolle fragt oder die Aufgabe eine menschliche Entscheidung erfordert. Ablehnungsverhalten ist Teil der Qualität. Ein klares Nein ist oft wertvoller als ein charmantes Vielleicht, das als Gewissheit verkleidet ist.

Menschliches Urteilsvermögen muss ebenfalls wiederholbar sein

Wiederholbarkeit ist nicht nur eine Eigenschaft von Maschinen. Auch menschliche Schritte brauchen Wiederholbarkeit. Wenn ein Prüfer die Modellausgabe als Entwurf behandelt, ein anderer als Entscheidung und ein dritter als nervigen Kollegen, wird der Arbeitsablauf abweichen, egal wie stabil das Modell ist. Die Organisation muss definieren, was Prüfung bedeutet. Verifiziert der Mensch Quellen, prüft er Richtlinien, stichprobt er Beweise, gibt er frei, bearbeitet er Sprache oder verantwortet er die Schlussfolgerung. Jedes Verb schafft eine andere Pflicht.

Operatoren brauchen Schnittstellen, die diese Pflichten unterstützen. Wenn sie Quellen verifizieren müssen, müssen die Quellen sichtbar sein. Wenn sie Richtlinien prüfen müssen, muss die Regelbasis in der Nähe der Ausgabe sein. Wenn sie überschreiben müssen, muss der Überschreibungsweg normal sein, nicht hinter einem Button versteckt, der sich wie ein Geständnis von Verrat anfühlt. Wenn sie eine Entscheidung später erklären müssen, muss das System bewahren, was sie zu diesem Zeitpunkt gesehen haben. Sonst wird menschliche Aufsicht zu einer dekorativen Phrase mit einer Mitarbeiter-ID.

Schulung ist ebenfalls wichtig, aber nicht die Art, die Menschen lehrt, das System zu bewundern. Nützliche Schulung zeigt die Grenzen. Sie gibt Prüfern Beispiele für starke Ausgaben, schwache Ausgaben, fehlende Beweise, veraltete Quellen, Prompt-Injection, Richtlinienkonflikte und Fälle, in denen das Modell mit ruhigem Herzen ignoriert werden sollte. Sie sagt den Menschen, welche Meinungsverschiedenheiten erwartet werden. Sie sagt ihnen, dass gute Überschreibungen Teil des Kontrollsystems sind. Wenn jede Überschreibung als Einführungsfehler behandelt wird, lernen die Menschen, nicht mehr hinzusehen. Menschen sind anpassungsfähig, manchmal unbequem.

Es ist ein trostloser Trost, das Verfahren aufzuschreiben. Nicht weil Dokumente magisch sind. Das sind sie nicht, wie jeder weiß, der ein gemeinsames Laufwerk kennengelernt hat. Der Trost kommt davon, die Organisation zu zwingen, sich zu entscheiden. Ein wiederholbarer menschlicher Schritt sagt, diese Rolle muss diese Prüfung mit diesen Beweisen unter dieser Frist durchführen, und das passiert, wenn die Prüfung fehlschlägt. Plötzlich hat die Aufsicht ein Gerüst.

Menschliche Aufsicht ist nicht wiederholbar, weil Menschen sich in allem einig sind. Sie ist wiederholbar, wenn Uneinigkeit eine definierte Form und eine brauchbare Aufzeichnung hat.

Zufall braucht eine Adresse

Manche KI-Systeme enthalten Zufall mit Absicht. Sampling kann bessere Sprache erzeugen. Suche kann Alternativen erkunden. Agenten können verschiedene Werkzeugpfade ausprobieren. Menschliches Feedback kann das Verhalten im Laufe der Zeit verändern. Nichts davon ist grundsätzlich schlecht. Der operative Fehler besteht darin, Zufall überall und nirgends leben zu lassen. Wenn Variation nützlich ist, sage, wo sie erlaubt ist. Wenn sie riskant ist, begrenze sie. Wenn sie auftritt, zeichne genug auf, um sie zu verstehen. Zufall ohne Adresse führt dazu, dass Teams einen Nebelwerfer debuggen.

Es gibt praktische Techniken. Verwende deterministische Einstellungen, wenn die Ausgabe folgenreich und die Aufgabe begrenzt ist. Fixiere Versionen und Vorlagen. Behalte Korpus-Snapshots. Protokolliere Retrieval-Kandidaten. Trenne kreatives Schreiben von Entscheidungsunterstützung. Bei generativem Text, der variieren kann, bewerte Behauptungen und Quellen statt der Oberflächenformulierung. Für agentische Arbeitsabläufe erfasse Werkzeugpläne, Werkzeugergebnisse und Verweigerungspfade. Bei Modellaktualisierungen führe paarweise Vergleiche durch, bevor der Verkehr umgestellt wird. Nichts davon beseitigt Unsicherheit. Es gibt der Unsicherheit einen Platz am Tisch und verhindert, dass sie durch die Deckenplatten wandert.

Wiederholbarkeit verändert auch die Sprache bei Vorfällen. Statt zu sagen, die KI habe eine schlechte Antwort gegeben, kann das Team sagen, die Antwort habe Korpus-Snapshot 18, Richtlinienpaket 12, Modellversion 4, Prompt-Vorlage 31, abgerufene Dokumente A, C und F verwendet, Dokument B wegen des Zugriffsbereichs übersprungen, und sei von Rolle X ohne Eskalation akzeptiert worden. Dieser Satz ist weniger aufregend als „das System ist außer Kontrolle geraten“. Er ist auch nützlicher, was für dramatische Menschen eine wiederkehrende Enttäuschung ist.

Wenn das System diesen Satz nicht liefern kann, betreibt die Organisation keine KI. Sie betreut KI. Sie beobachtet, reagiert, tröstet und hofft, dass die nächste Schicht besser läuft. Das mag für einen Prototyp akzeptabel sein. Für Arbeit, auf die Menschen sich verlassen, ist es nicht akzeptabel.

Der Beschaffungsfehler

Wiederholbarkeit muss nicht nur aufgebaut, sondern auch gekauft werden. Viele Beschaffungsprozesse belohnen noch immer die beste Vorführung. Das System, das glatt wirkt, schnell antwortet und der Führung ein angenehmes Gefühl von Modernität vermittelt, bekommt Punkte. Das System, das Aufbewahrung von Belegen, Exportformat, Regressionstests, deterministisches Retrieval, Fixierung der Modellversion, rollenbasierte Prüfung und Rollback-Richtlinie erklärt, kann weniger aufregend klingen. So kaufen Organisationen zukünftige Besprechungen.

Bessere Kaufentscheidungen beginnen mit unbequemen Fragen. Können wir einen Fall erneut durchspielen. Können wir den Nachweispfad exportieren. Können wir jedes Modell und jeden Prompt, die eine Antwort beeinflussen, festhalten und benennen. Lässt sich die Abfrage nach einem Index-Neuaufbau reproduzieren. Können wir das aktuelle Verhalten mit einer Baseline vergleichen, die vor der Übernahme eines Updates festgelegt wurde. Können menschliche Korrekturen analysiert werden, ohne dass gutes Urteilsvermögen bestraft wird. Können wir mit unseren Aufzeichnungen gehen. Können wir einem Prüfer erklären, was passiert ist, ohne ein Support-Ticket zu eröffnen und eine Kerze anzuzünden.

Diese Fragen sind kein Zeichen von Misstrauen gegenüber Anbietern. Sie sind ein Zeichen von Professionalität. Ein guter Anbieter sollte sagen können, welche Teile wiederholbar sind, welche probabilistisch, welche Nachweise verfügbar sind, welche nicht, und was der Käufer selbst betreiben muss. Ein Käufer, der diese Fragen nicht stellt, wird die Antworten irgendwann im Produktivbetrieb finden, wo Antworten teurer sind und mit einem Headset geliefert werden.

Dieselbe Beschaffungslogik gilt intern. Plattformteams sollten keine Demo an den Betrieb verkaufen, ohne den Vertrag über Wiederholbarkeit. Datenteams sollten keine Quellen übergeben, ohne die Herkunft zu dokumentieren. Modellteams sollten keine Verbesserungen freigeben, ohne Baseline-Vergleiche. Governance-Teams sollten keine Grundsätze genehmigen, ohne die Aufzeichnungen zu prüfen. Alle wollen den Start. Wiederholbarkeit ist die Disziplin, sich um den Dienstag nach dem Start zu kümmern.

Der Kompromiss ist nicht Geschwindigkeit gegen Langsamkeit. Es geht um frühen Glanz gegen die Fähigkeit, weiterzumachen, wenn die echte Arbeit Widerstand leistet.

Wiederholbarkeit ist Freundlichkeit gegenüber künftigen Teams

Es gibt einen menschlichen Grund, sich um Wiederholbarkeit zu kümmern, der in Strategiepräsentationen selten auftaucht. Sie ist freundlicher. Freundlicher gegenüber den Betreibern, die nicht raten sollten, warum sich ein System geändert hat. Freundlicher gegenüber den Ingenieuren, die Vorfälle nicht aus Dashboard-Krümeln rekonstruieren sollten. Freundlicher gegenüber den Managern, die unter Beobachtung Entscheidungen treffen müssen. Freundlicher gegenüber Kunden, Bürgern, Patienten und Kollegen, die Antworten verdienen, die nicht im Nachhinein improvisiert sind. Ein wiederholbares System reduziert das Maß an institutionellem So-tun-als-ob, das nötig ist, um die Woche zu überstehen.

Wiederholbarkeit macht Ehrlichkeit auch leichter. Wenn Nachweise verfügbar sind, können Teams sagen: Hier hat das Modell versagt, dort waren die Daten veraltet, die Richtlinie war mehrdeutig, der Prüfer hatte zu wenig Kontext, oder die Quelle fehlte. Ohne Nachweise fühlt sich jedes Eingeständnis riskant an, weil niemand weiß, wo die Schuld landen wird. Also weichen Menschen ihre Sprache auf, verzögern Entscheidungen und erzeugen den dichten Nebel, der als Abstimmung bekannt ist. Nachweise machen Organisationen nicht mutig, aber sie senken die Kosten dafür, präzise zu sein.

Es wird weiterhin Überraschungen geben. Wiederholbarkeit ist kein Schutzschild gegen die Realität. Neue Fälle werden Annahmen widerlegen. Nutzer werden ungewöhnliche Fragen stellen. Dokumente werden mit Formatierungen eintreffen, die aussehen, als wären sie während eines Stromausfalls ausgehandelt worden. Modelle werden sich in die eine Richtung verbessern und in eine andere zurückfallen. Es geht nicht darum, Überraschungen zu beseitigen. Es geht darum, Überraschungen aufschlussreich statt ansteckend zu machen.

Deshalb ist Wiederholbarkeit wichtiger als Demonstrationen. Demonstrationen erzeugen den Glauben, dass eine Fähigkeit existiert. Wiederholbarkeit schafft die Möglichkeit, sich auf sie zu verlassen. Ersteres ist nützlich, um ein Gespräch zu beginnen. Zweiteres ist notwendig, um Arbeit zu erledigen. Wenn ein KI-System Teil einer Institution wird, geht es nicht mehr darum, ob es einen Raum beeindrucken kann. Die Frage wird, ob es seine Arbeit an einem gewöhnlichen Tag, unter gewöhnlichem Druck und mit gewöhnlichen Menschen beteiligt, erstellen, bewahren und erklären kann. An gewöhnlichen Tagen verdienen ernsthafte Systeme ihren Platz.