Für IT-Leitungen, Digitalisierungsverantwortliche und Projektleitungen, die einen KI-Chatbot-Piloten erfolgreich abgeschlossen haben und nun vor der Skalierung stehen oder mittendrin stecken, lohnt ein Blick auf eine fast 400 Jahre alte Schiffskatastrophe.
Kennen Sie die Geschichte der Vasa? Gebaut im Auftrag von Gustav II. Adolf sollte das prunkvollste und kampfstärkste Kriegsschiff seiner Zeit Schwedens Macht zeigen. Doch am 10. August 1628 - direkt bei der Jungfernfahrt - sank es nach wenigen Minuten und rund 1 300 Metern Fahrt Stockholmer Hafen.Eine leichte Windböe genügte, denn der Schwerpunkt lag zu hoch. Der König hatte die Anforderungen mehrfach geändert und ein zweites Kanonendeck ohne Bauplan verlangt. Ein Stabilitätstest fiel schlecht aus, doch das Schiff lief trotzdem aus. Heute steht die Vasa nach Ihrer Bergung 1961 im Vasa Museum Stockholm.
KI-Projekte fühlen sich oft an wie die Vasa: Der Pilot gelang, nun soll alles groß und beeindruckend werden. Die Vasa lehrt, worauf es ankommt:
Schauen wir uns an, was diese Themen bei KI Chatbots bedeuten.
Klare Anforderungen definieren
Was soll Ihr KI-Chatbot eigentlich können?
Weil das Pilotprojekt vielversprechende Ergebnisse liefert und die KI bereits brauchbare Antworten gibt, wird häufig darauf verzichtet, konkrete Anforderungen zu definieren. Dabei bleibt offen, welche Fragen der Chatbot beantworten soll.
Denn das – so meint man – ergibt sich ja aus den Dokumenten! Die KI soll zudem in den Dokumenten beschriebenen Auskunft geben. Faktisch läuft das aber darauf hinaus, dass die KI zu allem Auskunft gibt, was sie in die Dokumente hineininterpretiert!
Um hier Probleme zu vermeiden werden in Projekten „Goldstandards“ (oder manchmal auch Competency questions genannt) definiert, also Beispielfragen und Antworten. Diese Fragen geben schonmal eine gute Grundlage, um den Agenten dann auch testen zu können.
Neben den korrekten Antworten ist auch zu klären, welche Qualität der Antworten erwartet wird. Sollen alle möglichen Antworten genannt werden, auch wenn mal eine falsche dabei ist (im technischen Bereich üblich und möglich), oder dürfen nur korrekte Antworten gegeben werden?
Ohne klare Requirements kann der Projekterfolg nicht abgeschätzt und nicht mal nachträglich beurteilt werden. Klare Requirements sind also unverzichtbar für den Projekterfolg!
Welche genauen Voraussetzungen für eine stabile Lage des Schiffs notwendig sind, das konnte zum damaligen Zeitpunkt niemand wirklich berechnen. Das ergab sich aus Erfahrungen, die nicht einfach skaliert werden konnten.
Ähnlich scheint es bei KI-Projekten zu sein. Man beschreibt allgemein die eingesetzte Technik. Man testet von „Eingabe der Frage“ bis zu „Erstellung der Antwort“. Und wenn das Ergebnis gut aussieht, ist man zufrieden. Was genau zwischen Frage und Antwort geschehen ist und wie reproduzierbar die Antwort zu anderen Umgebungsbedingungen sein könnte ist damit nicht klar, und die Verlässlichkeit und Skalierbarkeit auch nicht.
Dabei sollte Schritt für Schritt ein klares Konzept dafür bestehen, wie die KI ihre Antwort generiert:
Welche Aussagen fehlen eigentlich, weil sie als „Generelles Wissen“ vorausgesetzt werden, oder weil es im entsprechenden Kontext um von allen vorausgesetztes Wissen geht?
Und hier ist es wichtig zu verstehen, wie das genau funktioniert und welche Anforderungen die Antwort eigentlich stellt.
Ein Beispiel: Wenn die Frage eine Symptomatik beschreibt, wird eine reine Volltextsuche oder auch Vektorsuche nicht ausreichen, die passenden Textstellen von Lösungen zu finden.
Bestimmt erscheint es manchen Lesern eigentümlich, solche Fragestellungen für das eigene System beantworten zu müssen. Wer jedoch die Konstruktion seiner eigenen Pipeline aus dem Piloten nicht kennt, der weiß nicht wirklich, was das System macht und kann schon durch eine etwas andere Frage, einen etwas anderen Content an das Limit des nicht bestehenden Konzeptes gebracht werden, so dass die Antwort auf einmal unzutreffend ist.
Testen, Messen und Analysieren ist absolut hilfreich und zeigt auf, wie das System denn tatsächlich arbeitet. Und an welchen Stellen das Ganze „wackelig“ wird. Man nennt das dann auch „Observability“, Beobachtbarkeit. Die oben beschriebenen Schritte müssen nicht nur konzipierbar sein, sondern auch beobachtbar und messbar.
Die Kernvoraussetzung dazu ist, dass man die Erstellung einer Antwort des LLMs als Prozess interpretiert, dessen einzelne Schritte isoliert betrachtet werden können müssen. So kann man die Dokumentenqualität prüfen, jedenfalls dann, wenn man die Fragen kennt.
Man kann die Interpretation der Antwort beobachten und testen, man kann die Suche einzeln bewerten (das führt dann zum Begriff des Context Engineerings) und man kann das System auch dabei beobachten, wie es die Antwort generiert. Und idealerweise kann man für diese Schritte auch einzelne Qualitätsmerkmale festlegen, um wirklich die Skalierbarkeit des Chatbots steuern zu können.
Eigentlich ist es wie immer: Natürlich funktioniert ein Pilot ganz gut. Das heißt aber noch nicht, dass man ihn einfacher vergrößern kann. Nimmt man hingegen den Piloten, um die Technik und ihre Eigenheiten zu erlernen und konstruiert die „große Lösung“ dann mit diesem Wissen, dann wird die Skalierung vom „wir probieren’s mal aus“ zur Konstruktion und zum vorhersehbaren System. Damit das Schiff dann auch erfolgreich aus dem Hafen läuft und nicht unglücklich scheitert.
Prüfen Sie, wie gut Ihre Wissensbasis für den zuverlässigen KI-Einsatz aufgestellt ist. Inklusive individueller Expertenanalyse und konkreter Handlungsempfehlungen.
Nur begrenzte Expertenanalysen pro Monat verfügbar.