Warum wir keine universellen Chatbots bauen (und was wir stattdessen bauen)
Die wichtigsten Erkenntnisse
- Ein universeller Chatbot erbt jeden Grenzfall Ihres Geschäfts, ohne die Leitplanken, die ein enges Feature haben kann.
- Enge, eingebettete KI-Funktionen lassen sich leichter evaluieren, günstiger betreiben und scheitern auf vorhersehbare Weise.
- Die richtige Frage ist nicht „sollen wir KI hinzufügen", sondern „welche konkrete Aufgabe in einem bestehenden Workflow lohnt sich zu automatisieren".
- Das ist keine grundsätzliche Anti-Chatbot-Haltung; es ist eine Scoping-Disziplin, die Chatbots meistens einfach ausschließt.
„Könnt ihr unserer Website einen KI-Chatbot hinzufügen" ist die mit Abstand häufigste KI-Anfrage, die wir bekommen, und diejenige, der wir am häufigsten widersprechen. Nicht weil Chatbots nicht funktionieren, sondern weil „universeller Chatbot für unser Geschäft" fast nie der richtige Umfang für das erste KI-Feature ist, das ein Unternehmen ausliefern sollte, und es trotzdem zu bauen erzeugt meist etwas, das in der Demo beeindruckend wirkt und im Produktivbetrieb Vertrauen untergräbt.
Das Kernproblem ist der Umfang. Ein universeller Chatbot erbt jede Frage, die ein Kunde stellen könnte, jeden Grenzfall Ihrer Richtlinien, jede Art, wie Ihr Produkt missverstanden werden kann, ohne die Leitplanken, die ein engeres Feature haben kann. Sie können kein sinnvolles Evaluationsset für „alles, was ein Nutzer fragen könnte" bauen, was bedeutet, dass Sie nicht sinnvoll wissen können, wie oft es falsch liegt, bevor Ihre Kunden es für Sie herausfinden.
„Identifiziere, welche drei Clips aus dieser Stunde Webinar-Material veröffentlichungswürdig sind" oder „markiere, welche Produktlistings basierend auf Umsatz- und Bestandsmustern Aufmerksamkeit brauchen" sind Aufgaben mit begrenzter Eingabe, überprüfbarer Ausgabe und einer klaren Definition, wann sie korrekt erledigt wurden. Ein enges Feature ist in jeder wichtigen Dimension das Gegenteil. Sie können ein echtes Evaluationsset, eine echte Genauigkeitszahl und eine echte Antwort auf „wie oft liegt das falsch und was passiert dann" aufbauen.
Kosten und Latenz sind ebenfalls vorhersehbarer. Ein universeller Chatbot muss für beliebig lange, beliebig komplexe Gespräche bereit sein, was bedeutet, für jeden Request auf den ungünstigsten Fall auszulegen. Ein enges Feature verarbeitet eine definierte Eingabe und erzeugt eine definierte Ausgabe, wodurch Token-Verbrauch, Latenz und damit Kosten etwas werden, das Sie tatsächlich vorhersagen und kontrollieren können, statt einer Zahl, die Sie am Monatsende überrascht.
Der eigentliche Unterschied liegt aber in den Fehlermodi. Wenn ein enges Feature etwas falsch macht, scheitert es auf eine Weise, die Sie vorhergesehen und für die Sie einen Fallback gebaut haben: Ein Clip wird zur menschlichen Prüfung markiert statt automatisch veröffentlicht, eine Produktempfehlung erhält eine Kennzeichnung als „geringe Konfidenz" statt als sicher angezeigt zu werden. Wenn ein universeller Chatbot etwas falsch macht, ist es meist eine mit völliger Selbstsicherheit formulierte falsche Antwort, in einem Gespräch, das Ihr Evaluationsset nie vorhergesehen hat, vor einem Kunden.
Das ist keine pauschale „Chatbots sind schlecht"-Haltung, und wir sagen das auch direkt, wenn ein Chatbot tatsächlich das richtige Werkzeug ist: ein gut abgegrenzter interner FAQ-Bot über eine feste, kuratierte Wissensbasis mit klarer Eskalation an einen Menschen ist ein legitimes enges Feature, kein universelles, auch wenn es von außen wie ein Chatbot aussieht. Der Unterschied, auf den es uns ankommt, ist Umfang und Evaluierbarkeit, nicht die Oberfläche.
Was wir stattdessen in der Praxis bauen: KI, die an einer bestimmten Stelle in einem bereits existierenden Workflow verdrahtet ist und eine klar definierte Aufgabe zuverlässig erledigt, während ein Mensch oder eine einfache Regel die Fälle übernimmt, bei denen sie sich nicht sicher ist. In unserer Webinar-Distributionspipeline ist das die Erkennung von Clips und Zitaten aus Rohmaterial. In der ERP-Arbeit ist das die Kennzeichnung, welche Listings und Bestandsstände in einem für die manuelle Durchsicht zu großen Katalog tatsächlich menschliche Aufmerksamkeit brauchen.
Die zugrunde liegende Disziplin ist jedes Mal dieselbe: die kleinste, konkreteste Aufgabe innerhalb eines Prozesses finden, den ein Team bereits ausführt, eine, für die Sie ein echtes Evaluationsset bauen können, und die zuerst automatisieren. Das ist ein weniger aufregendes Angebot als „wir fügen Ihrem ganzen Produkt KI hinzu", und es ist auch die Version, die tatsächlich etwas ausliefert, dem Ihr Team vertraut und das es sechs Monate später noch nutzt.
Weitere Beiträge aus dem Blog
Wie Sie Bestände über Amazon, Shopify und WooCommerce synchronisieren, ohne zu überverkaufen
Multichannel-Verkäufer überverkaufen aus einer Handvoll vorhersehbarer Gründe. Hier erfahren Sie, was das tatsächlich verursacht und welche Sync-Architektur das Problem dauerhaft löst.
Ein verteiltes Entwicklungsteam über die USA und Pakistan hinweg aufbauen: Wie Zeitzonen zum Vorteil werden
Die Zeitzonendifferenz wird meist als Einwand dargestellt. Bewusst gehandhabt, ist sie eher eine zweite Schicht als ein Kommunikationsproblem.
.NET 10 für Geschäftsanwendungen: Was ist neu, und sollten Sie upgraden?
.NET 10 kam als LTS-Release mit echten Performance- und Tooling-Verbesserungen. Hier ist, was für Geschäftsanwendungen wirklich zählt, und wie wir das Upgrade sequenzieren würden.
Bereit, über Ihr Projekt zu sprechen?
Erzählen Sie uns, woran Sie arbeiten. Wir antworten innerhalb eines Werktags mit den nächsten Schritten, ohne aufdringliche Verkaufsgespräche.