Warum eine KI-Vorführung mit echten Datenmengen etwas anderes zeigt

Eine KI-Vorführung mit drei hübsch aufbereiteten Beispieldokumenten überzeugt fast immer. Genau das macht sie als Beweis wertlos. Sie zeigt nur, dass ein Sprachmodell mit exakt diesen drei Dokumenten umgehen kann — nicht, ob es sich in einem gewachsenen Unternehmen genauso verhält.

Wer eine KI-gestützte Suche oder ein Chat-System kaufen will, sitzt aber meistens genau vor so einer Vorführung: aufgeräumt, mit wenigen ausgewählten Beispieldaten, jede Antwort ein Treffer. Das sieht überzeugend aus und sagt trotzdem wenig darüber aus, was nach der Einführung im eigenen Betrieb passiert.

Was eine Vorführung mit drei Beispieldaten beweist — und was nicht

Die Frage, die bei einer Vorführung eigentlich zählt, wird selten gestellt: Verhält sich das System noch genauso, wenn nicht mehr drei Dokumente dahinterstehen, sondern ein ganzer Kundenstamm, mehrere Jahre Mail-Verlauf und ein voller Beleg-Bestand aus Rechnungen, Angeboten und Aufträgen?

Bei einer Handvoll Beispieldaten lässt sich diese Frage gar nicht beantworten. Eine Suche über zehn Dokumente ist immer treffsicher — sie hat schlicht wenig zur Auswahl. Ob dieselbe Suche noch trägt, wenn Zehntausende ähnliche Datensätze dazwischenliegen, zeigt sich erst bei entsprechendem Umfang. Genau das ist der Unterschied zwischen einer Demo, die gefällt, und einer Demo, die etwas beweist.

Deshalb baue ich für Vorführungen inzwischen keine aufgeräumten Beispielprojekte mehr, sondern einen Datenbestand, der sich wie ein echter Mittelständler anfühlt: eine erfundene Firma mit eigener Historie, einem Kundenstamm im vierstelligen Bereich, mehreren Jahren Geschäftsverlauf und Belegen aus verschiedenen Systemen. Der Umfang geht in die Millionen einzelner Einträge, weil ein Unternehmen nach ein paar Jahren Betrieb genau dort landet — nicht, weil eine große Zahl an sich beeindrucken soll.

Warum Menge allein trotzdem nicht reicht

Ein Datenbestand, der nur groß ist, beweist ebenfalls wenig. Millionen zufällig aneinandergereihter Datensätze zeigen zwar, dass eine Suche nicht zusammenbricht — sie zeigen aber nicht, ob ein Ergebnis inhaltlich stimmt und ob mehrere Quellen sinnvoll zusammenfinden. Eine Anfrage im echten Betrieb berührt selten nur eine Tabelle. Sie zieht ein Angebot, den dazugehörigen Mail-Verlauf, eine Rechnung und vielleicht einen Termin zusammen — und genau dieses Zusammenspiel muss in der Vorführung sichtbar werden.

Deshalb hat der Bestand zwei sehr unterschiedliche Ebenen. Ein kleiner, wirklich durchdachter Kern aus miteinander verzahnten Fällen — ich nenne sie „Golden Paths” — bildet vollständige, in sich schlüssige Vorgänge ab: eine Anfrage, die über Mail, Angebot, Auftrag und Rechnung nachvollziehbar verläuft, mit echten inhaltlichen Bezügen zwischen den Stationen. An diesen Fällen zeige ich, wie eine Anfrage über mehrere Quellen hinweg richtig beantwortet wird.

Der weitaus größere Teil des Bestands entsteht dagegen nicht von Hand, sondern nach festen Mustern: Belegketten, Mail-Verläufe, Termine und Dateien, die sich aus Vorlagen und Zufallsdaten in großer Zahl erzeugen lassen, ohne dass jede einzelne Zeile inhaltlich durchdacht sein muss. Diese Masse liefert genau das, worauf es bei Menge ankommt — sie zwingt Suche und Auswertung dazu, unter realistischer Last noch treffsicher und schnell zu bleiben, statt nur in einer aufgeräumten Testumgebung zu glänzen.

Der Unterschied lässt sich an einer einfachen Beobachtung festmachen. Eine Suche über zehn Dokumente liefert praktisch immer ein brauchbares Ergebnis, weil es kaum etwas gibt, womit sie sich vertun könnte. Legt man denselben Suchbegriff über einen Bestand mit Hunderttausenden ähnlichen Einträgen, entscheidet sich erst dort, ob das dahinterliegende System wirklich einordnen kann, was gemeint ist — oder ob es nur noch die neueste oder die am häufigsten vorkommende Fundstelle nach oben spült. Genau diesen Unterschied kann eine Vorführung mit wenigen Beispieldaten gar nicht zeigen, weil die Situation, in der er entsteht, dort nie auftritt.

Ein konkreter Fall in der Vorführung

Wie sich das in der Praxis anfühlt, zeigt sich am besten an einem der durchdachten Fälle. Eine Anfrage geht per Mail ein, wird zu einem Angebot, das Angebot wird zum Auftrag, aus dem Auftrag entsteht eine Rechnung, und Wochen später ruft derselbe Kunde wegen einer Nachfrage noch einmal an. In einem gewöhnlichen System liegen diese fünf Stationen in vier unterschiedlichen Werkzeugen, und niemand sieht sie automatisch zusammen.

In der Vorführung stelle ich genau diese Frage: Was hat dieser Kunde zuletzt angefragt, und wie ist der Vorgang ausgegangen? Die Antwort zieht Mail, Angebot, Auftrag, Rechnung und den späteren Anruf zu einem zusammenhängenden Bild zusammen — nicht, weil dieser eine Fall besonders präpariert wäre, sondern weil er einer von mehreren Golden Paths ist, die genau für diesen Moment gebaut wurden. Der Rest des Bestands sorgt währenddessen dafür, dass die Suche sich durch Hunderttausende ähnlicher, aber nicht gemeinter Vorgänge hindurcharbeiten muss, um genau diesen einen zu finden.

Wie der Demo-Bestand entsteht

Die Firma hinter dem Demosystem heißt bewusst „Demodaten und Fake GmbH & Co. KG” — ein Name, der von der ersten Sekunde an klarmacht, dass hier niemandes echte Daten stecken. Rund 80 fiktive Mitarbeitende, ein Kundenstamm im vierstelligen Bereich, mehrere Jahre Geschäftsverlauf: ein generischer Handels- und Dienstleistungsbetrieb, wie es ihn in dieser Größenordnung mehrfach in jeder Branche gibt.

An diesem Bestand hängen dieselben Quellen, die auch bei einem echten Kunden zusammenkommen: das ERP-System mit Kunden, Angeboten, Aufträgen und Rechnungen, die Mail-Postfächer inklusive Kalender und Kontakten, ein Mail-Altarchiv als Volumen-Träger, Dateiablagen und die Auftragsabwicklung. Für die Vorführung zählt nicht, dass jede dieser Quellen einzeln funktioniert — das würde wieder nur die Drei-Dokumente-Demo wiederholen. Es zählt, dass sie gemeinsam denselben Datenbestand ergeben, durch den am Ende eine einzige Suche geht.

Ohne diesen Aufwand ließe sich das nicht zeigen. Bei einem echten Kunden lässt sich vor Vertragsabschluss weder der volle Datenbestand einsehen noch würde man ihn dafür anfassen wollen. Ein Demosystem, das sich in Umfang und Zusammenspiel wie ein echter Betrieb verhält, ist deshalb keine Spielerei, sondern die einzige ehrliche Art, vor der Entscheidung zu zeigen, was nach der Einführung tatsächlich passiert.

Was das für die Kaufentscheidung bedeutet

Für den Vertrieb — auf beiden Seiten des Tisches — folgt daraus eine einfache Prüffrage: Läuft eine Vorführung mit ein paar ausgewählten Beispielen, oder mit einem Bestand, der sich wie der eigene, gewachsene Betrieb anfühlt? Die erste Variante zeigt eine Möglichkeit. Die zweite zeigt ein Ergebnis.

Wer eine KI-gestützte Suche oder ein Chat-System für das eigene Unternehmen prüft, darf das ruhig genauso hart nachfragen: Wie viele zusammenhängende Datensätze stecken in dieser Vorführung wirklich dahinter? Wenn die Antwort „ein paar Beispieldateien” lautet, ist noch nichts bewiesen — nur gezeigt, dass ein Modell lesen kann. Erst wenn Menge, Vielfalt und das Zusammenspiel mehrerer Quellen stimmen, lässt sich beurteilen, ob ein System auch im eigenen Alltag hält, was die Vorführung verspricht.

Ein weiterer Punkt gehört zu einer ehrlichen Prüfung dazu: Wie reagiert das System, wenn eine Quelle einmal fehlt oder verspätet ankommt? In einem echten Betrieb ist nicht jede Anbindung zu jedem Zeitpunkt vollständig — ein Postfach hängt kurz, eine Belegkette ist noch nicht durchgelaufen. Ein Demosystem, das nur den Idealfall abbildet, verschweigt genau die Situation, die im Alltag am häufigsten vorkommt. Deshalb gehört zu einer aussagekräftigen Vorführung auch der unvollständige Fall — nicht als Vorführfehler, sondern als bewusst gezeigte Grenze.

Genau das ist der Anspruch, den ich an mein eigenes Demosystem stelle — nicht die schönste Oberfläche, sondern der ehrlichste Beweis dafür, was im Betrieb tatsächlich passiert.