Expertise liegt oft im Unwahrscheinlichen

Generative KI ist besonders wertvoll, wenn sie das Wahrscheinliche schnell verfügbar macht. Sie findet bekannte Muster, verdichtet häufige Vorgehensweisen, formuliert brauchbare Standardentwürfe und erzeugt in Sekunden Varianten, für die Menschen früher wesentlich länger recherchiert oder geschrieben hätten. Das ist keine Schwäche. Im Gegenteil: Ein großer Teil professioneller Arbeit besteht genau darin, bewährte Muster zuverlässig zu erkennen und anzuwenden.

Problematisch wird es erst, wenn wahrscheinlich, plausibel und passend miteinander verwechselt werden. Eine Lösung kann sprachlich überzeugend, technisch üblich und statistisch naheliegend sein – und trotzdem an genau jener Randbedingung scheitern, die im konkreten Projekt entscheidend ist. Ein ungewöhnlicher Kundenprozess, eine seltene Datenkonstellation, eine lokale Ausnahme, eine untypische technische Abhängigkeit oder ein Widerspruch zwischen zwei Anforderungen kann aus einer guten Standardantwort eine falsche Entscheidung machen.

Hier beginnt ein Teil dessen, was wir Expertise nennen. Expertise bedeutet nicht, grundsätzlich gegen Standards zu arbeiten. Sie bedeutet zu wissen, wann ein Standard trägt, unter welchen Bedingungen er gilt und an welcher kleinen Abweichung er seine Gültigkeit verliert.

Die entscheidende Fähigkeit im Umgang mit KI besteht deshalb nicht darin, immer ungewöhnlichere Antworten zu provozieren. Sie besteht darin, den Bereich außerhalb des Normalfalls systematisch sichtbar zu machen und ihn nur dort zu betreten, wo Evidenz, Risiko oder Kontext es rechtfertigen.

Wahrscheinlichkeit ist kein Qualitätsurteil

Ein Sprachmodell erzeugt Antworten aus gelernten Wahrscheinlichkeitsstrukturen. Vereinfacht gesagt verarbeitet es Kontext und berechnet fortlaufend, welche sprachlichen Fortsetzungen unter diesen Bedingungen plausibel sind. Moderne Systeme können dabei planen, Werkzeuge verwenden, recherchieren und komplexe Schlussketten erzeugen. Das Grundproblem verschwindet dadurch jedoch nicht: Plausibilität ist kein Wahrheits- oder Qualitätsflag.

In vielen Situationen ist das völlig ausreichend. Wenn ein Projektteam eine typische Meeting-Struktur, eine erste Liste denkbarer Risiken oder mehrere Formulierungsvarianten benötigt, ist die Nähe zu häufigen Mustern sogar erwünscht. Man möchte nicht jedes Mal das Projektmanagement neu erfinden.

Anders sieht es aus, wenn die Entscheidung an einer Ausnahme hängt. Ein System kann dann sehr überzeugend das Muster reproduzieren, das in ähnlichen Fällen meistens funktioniert. Genau das kann gefährlich werden, wenn der aktuelle Fall nicht in dieses Muster gehört.

Der Unterschied ist fundamental. Das Modell kann die Verteilung möglicher Antworten sehr effizient durchsuchen. Das Projekt braucht jedoch eine Entscheidung unter realen Konsequenzen.

Der Long Tail gehört zur Realität

Viele reale Verteilungen besitzen einen langen Randbereich: wenige Fälle kommen sehr häufig vor, sehr viele andere nur selten. In diesem „Long Tail" liegen ungewöhnliche Begriffe, seltene Ereignisse, wenig dokumentierte Sonderfälle, lokale Praktiken und Kombinationen, die in Trainingsdaten nur schwach vertreten sein können.

Gerade in Projekten sind solche Fälle nicht automatisch unwichtig. Ein Fehler, der nur bei einem Prozent der Transaktionen auftritt, kann bedeutungslos sein – oder genau die zahlungsrelevante Ausnahme betreffen. Eine seltene Nutzergruppe kann nebensächlich sein – oder regulatorisch, strategisch oder wirtschaftlich besonders wichtig. Ein technischer Edge Case kann kaum auftreten – aber im Fehlerfall das gesamte System stoppen.

Die Häufigkeit eines Falls und seine Bedeutung sind deshalb zwei verschiedene Achsen.

Diese Trennung ist für KI-Projekte besonders wichtig, weil Modelle auf durchschnittliche Leistungswerte optimiert und Benchmarks häufig über aggregierte Ergebnisse gelesen werden. Ein System kann im Mittel sehr stark sein und dennoch genau in jener Nische schwächeln, die für ein bestimmtes Unternehmen entscheidend ist.

Was die Forschung über seltene Fälle zeigt

Die These, dass seltene Fälle für Sprachmodelle schwieriger sein können, lässt sich inzwischen gut empirisch stützen. Kandpal und Kollegen untersuchten den Zusammenhang zwischen Wissen in Sprachmodellen und der Häufigkeit relevanter Informationen in Pretraining-Daten. Ihre Ergebnisse zeigen einen starken Zusammenhang zwischen der Zahl relevanter Dokumente und der Fähigkeit, entsprechende Faktenfragen korrekt zu beantworten. Größere Modelle verbessern die Situation, beseitigen den Long-Tail-Effekt aber nicht vollständig.^[1]

Godbole und Jia konstruierten Benchmarks, bei denen bewusst niedrigwahrscheinlichere Beispiele in die Testmenge verschoben wurden. Auf diesen sogenannten Likelihood Splits stiegen die relativen Fehlerraten deutlich gegenüber klassischen Zufallssplits. Das macht sichtbar, wie stark gewöhnliche Benchmarks Leistung in den dichten, wahrscheinlicheren Bereichen einer Verteilung überschätzen können.^[2]

Eine EMNLP-Arbeit von Li und Kollegen untersuchte Long-Tail-Inferenzwissen mit systematisch erzeugten, faktisch kontrollierten Aussagen. Auch dort zeigte sich bei modernen Modellen ein klarer Leistungsabfall gegenüber häufigeren Fällen.^[3] Der Befund ist nicht, dass Modelle „nichts Seltenes können". Der Befund ist präziser: Leistung im Durchschnitt garantiert keine gleichmäßige Robustheit im Randbereich.

Für die Praxis folgt daraus keine Aufforderung, jede Standardantwort zu misstrauen. Es folgt eine andere Regel: Je höher die Konsequenzen eines seltenen Fehlers, desto stärker muss ein Projekt den Randbereich aktiv prüfen.

Expertise ist vor allem Grenzwissen

Ein Anfänger erkennt oft eine Regel. Eine erfahrene Person erkennt zusätzlich ihre Gültigkeitsgrenze.

Das ist ein unterschätzter Unterschied. Fachwissen besteht nicht nur aus mehr Fakten oder mehr Methoden. Ein großer Teil von Expertise ist Wissen darüber, wann eine Methode nicht angewendet werden darf, welche Voraussetzungen stillschweigend erfüllt sein müssen und welche kleine Beobachtung eine scheinbar klare Diagnose verändert.

Ein erfahrener Ingenieur kennt nicht nur den Normalbetrieb, sondern typische Ausfallbilder. Eine erfahrene Juristin erkennt nicht nur die Standardklausel, sondern die Konstellation, in der eine Ausnahme entscheidend wird. Ein erfahrener Produktmanager sieht nicht nur eine plausible Feature-Idee, sondern die Nebenwirkung auf Support, Wartung oder Nutzerverhalten. Ein erfahrener Kreativer erkennt, wann ein bewährtes Muster nur noch austauschbar wirkt.

Diese Art von Wissen ist für Sprachmodelle schwierig, wenn sie wenig explizit dokumentiert ist. Organisationen speichern oft die erfolgreiche Standardlösung, aber nicht die zehn Situationen, in denen sie bewusst verworfen wurde. Gerade diese verworfenen Alternativen, Gegenbeispiele und Ausnahmebedingungen enthalten jedoch wertvolles Grenzwissen.

Deshalb sollte eine KI-Wissensbasis nicht nur aus „so machen wir es" bestehen. Sie sollte auch enthalten: „so machen wir es nicht, wenn …"

Gegenbeispiele sind produktiver als bloß mehr Varianten

Wenn eine KI eine überzeugende Lösung vorgeschlagen hat, ist die naheliegende Reaktion oft: „Gib mir fünf weitere Varianten." Das erhöht Vielfalt, prüft aber nicht zwingend die Grundannahme. Fünf Varianten können dieselbe falsche Prämisse in unterschiedlichen Formulierungen wiederholen.

Ein Gegenbeispiel arbeitet anders. Es fragt nach einer Situation, in der die vorgeschlagene Lösung nicht funktioniert. Dadurch wird nicht die Oberfläche variiert, sondern die Gültigkeitsgrenze getestet.

Statt „Welche anderen Projektpläne wären möglich?" ist häufig die stärkere Frage: „Unter welchen realistischen Bedingungen würde dieser Projektplan scheitern?" Statt „Gib mir weitere Zielgruppen" kann gefragt werden: „Welche relevante Nutzergruppe wird von unserem aktuellen Modell systematisch falsch verstanden?" Statt „Verbessere diese Architektur" kann gefragt werden: „Welche Annahme muss falsch sein, damit diese Architektur die falsche Wahl ist?"

Das verändert die Rolle der KI. Sie wird vom Antwortgenerator zum Falsifikationspartner.

Dabei ist wichtig, dass auch das Gegenbeispiel selbst nur ein Vorschlag ist. Es muss genauso geprüft werden wie die ursprüngliche Lösung. Die Methode erzeugt keine Wahrheit; sie erzeugt bessere Prüfoberflächen.

Selten ist nicht automatisch klug

Die Gegenbewegung zur Standardlösung kann genauso gefährlich werden wie blinde Standardisierung. Wer glaubt, das Unwahrscheinliche sei per Definition genialer, ersetzt einen Bias nur durch einen anderen.

Viele seltene Ideen sind selten, weil sie schlecht funktionieren. Viele ungewöhnliche Wege sind teuer, unnötig komplex oder bereits aus guten Gründen verworfen worden. Innovation ist nicht die Kunst, möglichst weit von der Norm abzuweichen. Sie ist die Fähigkeit, dort abzuweichen, wo die Normalannahme den konkreten Fall nicht erklärt.

Deshalb braucht „Tail Scouting" immer eine zweite Achse: Relevanz.

Die Tabelle zeigt, warum Seltenheit allein kein Priorisierungskriterium ist. Entscheidend ist die Kombination aus Wahrscheinlichkeit, Konsequenz, Erkennbarkeit und Reversibilität.

Den Tellerrand kann man systematisch suchen

„Über den Tellerrand denken" klingt oft nach spontaner Kreativität. Für professionelle KI-Arbeit ist eine systematischere Methode hilfreicher. Der Rand einer Lösung lässt sich über vier Fragen erschließen.

Zuerst werden die Annahmen sichtbar gemacht: Was muss wahr sein, damit die Standardlösung funktioniert? Danach werden die Grenzen untersucht: Ab welcher Änderung von Daten, Ressourcen, Zeit, Nutzerverhalten oder regulatorischem Rahmen kippt die Lösung? Anschließend werden Gegenbeispiele gesucht: Gibt es reale oder plausible Fälle, die trotz ähnlicher Oberfläche anders behandelt werden müssen? Erst danach lohnt sich die Suche nach alternativen Hypothesen oder ungewöhnlichen Lösungswegen.

Damit wird Kreativität nicht abgeschafft. Sie wird an ein Problem gebunden.

Ein ungewöhnlicher Vorschlag, der keine konkrete Schwäche der Standardlösung adressiert, ist nur eine Option. Ein ungewöhnlicher Vorschlag, der eine nachgewiesene Grenze besser behandelt, ist eine ernsthafte Alternative.

Zwei Suchmodi statt einer einzigen Antwortschleife