Posts
Lessons Learned – von der Idee bis zum Go-Live unseres KI-Chatbots
Erfahrungen aus der Entwicklung bei Magenta Business
Die Entwicklung eines KI-Chatbots mit modernen Sprachmodellen (LLMs) war für unser Team nicht nur spannend, sondern auch lehrreich. Der Weg war gespickt mit Erfolgen, Rückschlägen und vielen Lessons Learned. Heute wird unser Chatbot aktiv von Kund:innen genutzt, aber der Weg dorthin war nicht geradlinig.
In diesem Beitrag teilen wir unsere Erkenntnisse – damit andere Teams schneller und mit weniger Stolpersteinen zum Ziel kommen.
KI in Java? Geht – und zwar ziemlich gut
Wer KI-Anwendungen entwickeln möchte, muss nicht zwingend in Python unterwegs sein. Für Java-Teams gibt es mittlerweile sehr gute Frameworks wie Spring AI und LangChain4J, die die Anbindung von Sprachmodellen wie GPT, Claude oder Mistral deutlich vereinfachen. Selbst das Integrieren von Backend-Funktionalität oder anderer Firmen-APIs per Tool in die KI ist mit diesen Frameworks einfach. So könnt Ihr relativ leicht einfache KI Agenten bauen.
Unser Tipp: Baut frühzeitig einen kleinen Prototypen – zum Beispiel eine REST-API, die ein paar typische Kundenfragen beantwortet. So schafft ihr Vertrauen im Team, gewinnt durch Demos Unterstützung aus der Fachseite und könnt Aufwände realistischer abschätzen.
MVP statt Feature-Wildwuchs
Ein häufiger Fehler bei neuen Technologien: Man will gleich alles auf einmal. Unser erster KI-Chatbot war technisch aufwendig und in seinem Kontext sehr mächtig – aber leider nicht relevant genug für unsere Kund:innen. Der Use Case war zu spitz, das Interesse zu gering. Die Folge: kaum Nutzung, viel Aufwand, wenig Impact.
Lektion gelernt: Startet mit einem MVP (Minimal Viable Product).
Ein schlanker Chatbot, der ein echtes Problem löst, bringt mehr als ein hochgerüsteter Alleskönner mit viel zu kleiner Zielgruppe. Im laufenden Betrieb lässt sich immer noch optimieren und ausbauen – basierend auf echten Nutzungsdaten.
Beim zweiten Anlauf waren wir strategischer: Zuerst haben wir analysiert, wie stark der klassische Hilfe-Chat überhaupt genutzt wird. Daraufhin platzierten wir den KI-Chatbot an einer prominenten, deutlich frequentierten Stelle im Portal – und wurden mit deutlich höherer Nutzung belohnt.
Trotzdem empfehlen wir, erste KI-Bots an weniger kritischen Stellen zu testen. Denn KI-Systeme sind nicht immer vorhersehbar – und Fehler können schnell teuer werden. Beispiele wie der versehentliche Verkauf von Neuwagen für 1 Dollar zeigen, wie wichtig kontrollierte Einführungen sind.
Wir empfehlen auch den Chatbot am Anfang nur in einem kleinen Kontext einzusetzen. Das bedeutet beispielsweise, dass ihr den Chatbot auf einer einzelnen Webseite einsetzt und ihn auch nur für den UseCase auf dieser Webseite trainiert. Per SystemPrompt erklärt ihr dem Chatbot, dass er Fragen außerhalb des kleinen Kontextes freundlich Ablehnen soll oder an andere Kanäle (z. B. Hotline oder Hilfe-Seiten) verweisen soll.
Klare Kennzeichnung: UX beginnt beim Icon
Ein weiteres Learning aus der Praxis: Nur weil ein neuer Chatbot live ist, heißt das noch lange nicht, dass er auch genutzt wird. Anfangs wurde unser KI-Chat von vielen Kund:innen schlicht übersehen – wir hatten nämlich dasselbe Icon wie beim klassischen Live-Chat verwendet.
Den 2. KI-Chatbot haben wir mit einem neuen Icon und Beschriftung "KI-Chat" direkt am Chat-Starten-Button versehen. Ob das direkt zur gestiegenen Nutzung geführt hat, lässt sich nicht sicher sagen – aber: Die Nutzung ist da, und der klarere Hinweis hat wahrscheinlich geholfen, den Chatbot besser einzuordnen.
Guter Chatbot ≠ komplexer Chatbot
Nicht jeder Bot muss agentisch sein und eine prall gefüllte Wissensdatenbank haben. In unserem Fall reichte für viele Anliegen ein einfacher FAQ-Chatbot. Zusammen mit dem Service-Team haben wir analysiert:
-
Welche Probleme melden Kund:innen am häufigsten?
-
Welche Antworten gibt der Service immer wieder?
Mit diesem Wissen haben wir einen Bot gebaut, der ohne aufwendige Logik zuverlässig funktioniert – ganz einfach mit einem LLM, einem SystemPrompt und einer gepflegten FAQ-Liste.
Ein zusätzlicher Pluspunkt: Die Zusammenarbeit mit der Fachseite lief auch ohne KI-Vorerfahrung reibungslos. Die Kolleg:innen mussten nur ihr Wissen in eine strukturierte Liste bringen – ein KI-Experte übernahm das Feintuning. Umgekehrt musste der KI-Experte das Fachthema gar nicht im Detail verstehen.
Sicherheit, Kostenkontrolle und Guardrails
Sobald ein Chatbot live geht, wird er getestet – auch von weniger wohlmeinenden Nutzer:innen. Die ersten Angriffe auf unseren Bot waren klassische Injection-Versuche über die REST-API zwischen Frontend und Backend. Gut, dass wir bereits auf bekannte Security-Mechanismen gesetzt hatten:
-
Validierung aller Eingabenparameter - also auch der Chatnachricht
-
Detailliertes Logging zur Analyse von Angriffen
Dazu kamen KI-spezifische Maßnahmen:
Weil LLM-Anfragen pro Call abgerechnet werden, haben wir Kostenlimits und DoS-Schutzmechanismen implementiert. Außerdem empfehlen wir, sogenannte Guardrails zu aktivieren – also Filter für sensible Inhalte (Hass, Gewalt, Sexualität, Jailbreak etc.), die vom Cloud-Provider zusammen mit dem LLM als Service angeboten werden.
Lernen durch echte Chats
Egal wie viel man testet – im Live-Betrieb zeigt sich die Realität. Und die sieht oft anders aus als gedacht. Kund:innen schreiben nicht immer vollständige Fragen, sondern oft nur Stichworte wie „Rechnung“, „Störung“ oder „EVN“ (Einzelverbindungsnachweis). Trotzdem erwarten sie eine sinnvolle Antwort.
Aktuelle Sprachmodelle kommen damit erstaunlich gut zurecht – aber sie brauchen Kontext. Deshalb analysieren wir regelmäßig die echten Chatverläufe, um fehlendes Wissen nachzupflegen und den SystemPrompt zu verbessern.
Ein Beispiel: LLMs kennen in der Regel nicht das aktuelle Datum. Wird nach „Rechnung im Mai 2025“ gefragt, kann das Modell falsche Schlüsse ziehen, weil seine Trainingsdaten aus 2024 sind. Wir lösen das inzwischen, indem wir das aktuelle Datum automatisch im SystemPrompt mitgeben.
Testing auf KI-Niveau
Klassische Tests wie Unit- oder Integrationstests reichen bei KI-Systemen nicht aus, da die Antworten nicht immer eindeutig oder fest definiert sind. Entscheidend ist vielmehr, ob die Antworten hilfreich, konsistent oder missverständlich sind.
Deshalb setzen wir zusätzlich ein zweites KI-Modell ein, das die Antworten unseres Chatbots bewertet. In folgendem Video führe ich das vor.
Vektor-Datenbanken: Einfach reicht oft
Für viele Anwendungen braucht es keine dedizierte Vektor-Datenbank wie Milvus oder chroma. Wir haben sehr gute Erfahrungen mit der Vektor-Erweiterung für MongoDB und PostgreSQL gemacht – ideal für einfache RAG-Szenarien. Der große Vorteil: keine zusätzliche Infrastruktur, falls ihr diese stark verbreiteten Datenbanken schon im Einsatz habt.
Fazit
KI-Entwicklung ist keine Raketenwissenschaft – besonders nicht in Java. Wer Webanwendungen bauen kann, bringt die besten Voraussetzungen mit, um auch KI-gestützte Chatbots schnell und effektiv umzusetzen. Moderne Frameworks wie Spring AI oder LangChain4J machen den Einstieg leicht – ganz ohne Python.
Der schnellste Weg zum Erfolg führt über erste Prototypen statt langer PowerPoint-Präsentationen. Schon ein einfacher Prototyp, der grundlegende Fragen beantwortet, überzeugt Kollegen und schafft interne Unterstützung. Ein aufwendiges Frontend ist dafür nicht nötig – der Nutzen steht im Vordergrund.
Am wichtigsten: Nutzt echte Kundendaten und lernt daraus. Kunden sind kreativer als jedes Testskript und zeigen durch ihre Fragen, wo die KI glänzt und wo noch nachgebessert werden muss. Die enge Zusammenarbeit mit dem Service-Team hilft, echte Probleme zu verstehen und den Chatbot gezielt zu verbessern.
