(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)

Einführung: Der Paradigmenwechsel in der Qualitätssicherung für LLM-basierte Systeme 

Das Testen eines LLM-Chatbots innerhalb eines MCP-basierten Systems unterscheidet sich grundlegend vom Testen klassischer Software. Traditionelle Systeme sind deterministisch: Derselbe Input führt stets zum selben Output. Bei einer typischen REST-API liefert eine Anfrage entweder die erwartete JSON-Payload oder eben nicht. Die Assertions sind dabei klar und eindeutig.

Ein Chatbot, der auf einem großen Sprachmodell basiert, verhält sich anders. Das Testen von Outputs eines Large Language Models (LLM) erfordert einen fundamentalen Paradigmenwechsel. Die Annahmen, die Softwaretests seit Jahrzehnten geprägt haben — Determinismus, exakte Reproduzierbarkeit und binäre Zustandsvalidierung — brechen im Kontext generativer KI zusammen.

Um die Komplexität des Testens solcher Anwendungen zu verstehen, müssen wir zunächst die zugrunde liegende Architektur betrachten, erklären, warum klassische Assertions versagen, und die einzigartigen, kontextabhängigen Fallstricke und Besonderheiten analysieren.

Überblick über die Systemarchitektur

Ein moderner LLM-basierter Chatbot ist im Kern ein komplexes, mehrschichtiges verteiltes System, in dem jede Komponente neue Variablen in die Testgleichung einbringt.

Wenn ein Benutzer einen Prompt absendet, durchläuft dieser mehrere kritische serverseitige Komponenten, bevor eine Antwort erzeugt wird. Zunächst wird die Eingabe häufig von einem Orchestrator oder Reasoning-Engine verarbeitet. In Enterprise-Umgebungen wie unserer kommt hier typischerweise das Model Context Protocol (MCP) zum Einsatz. MCP ermöglicht es dem LLM, sicher mit externen Datenquellen und internen Tools zu interagieren, ohne Integrationen fest zu verdrahten.

Parallel dazu nutzt das System ein Retrieval-Augmented-Generation-Muster. Bevor das LLM eine Antwort generiert, wird die Benutzeranfrage eingebettet und an eine Vektordatenbank gesendet, um semantisch relevante Kontexte abzurufen. Dieser abgerufene Kontext wird zusammen mit Systemanweisungen und dem Chatverlauf dynamisch in einen versteckten Meta-Prompt eingefügt. Erst dann wird die Nutzlast an die Inference-Engine (die Model-Serving-Schicht) gesendet. Schließlich generiert das LLM Token sequenziell, die über eine persistente Verbindung, etwa WebSockets mittels SignalR, an den Client gestreamt werden.

Herausforderung

Diese architektonischen Entscheidungen wirken sich direkt auf die Testbarkeit aus. Wenn man den „Chatbot“ testet, testet man gleichzeitig die Retrieval-Mechanismen, die Orchestrierungsschicht und das generative Modell selbst. Deshalb haben Fehler in einer solchen Umgebung selten nur eine einzige Ursache.

Wenn der Chatbot eine falsche Antwort liefert, kann die Ursache unter anderem sein:

• die Retrieval-Komponente hat irrelevante Dokumente zurückgegeben
• der Prompt ist für die jeweiligen Use Cases nicht optimal optimiert
• das richtige Dokument wurde zwar gefunden, aber vom Modell ignoriert
• das Modell hat Informationen erfunden, die nicht im Kontext vorhanden waren
• der Chatbot hat kein Tool aufgerufen, um eine bestimmte Aktion auszuführen oder die benötigten Daten abzurufen
• das Tool hat einen Fehler zurückgegeben, der nicht an das Modell weitergegeben wurde
• das Kontextfenster hat relevante Informationen abgeschnitten

Der Chatbot arbeitet zudem innerhalb einer Konversation. Eine Antwort kann von vorherigen Gesprächsverläufen, abgerufenen Dokumenten, System-Prompts und Tool-Ausgaben abhängen. Das Testen eines einzelnen Prompts in Isolation reproduziert daher nicht immer das Verhalten, das in realen Gesprächen auftritt.

Der geschäftliche Kontext erhöht den Druck zusätzlich. In diesem System erscheint der Chatbot auf der Website eines Unternehmens und beantwortet Fragen potenzieller Kunden zur Erfahrung und zu Projekten des Unternehmens. Wenn der Bot Projekte erfindet oder eine Anfrage falsch versteht, geht der Schaden über bloß falsche Informationen hinaus. Er kann aktiv eine erfolgreiche Lead-Bearbeitung simulieren, indem er bestätigt, dass eine Kontaktanfrage oder ein Formular an das Vertriebsteam gesendet wurde, obwohl tatsächlich kein nachgelagerter Prozess ausgelöst wurde. Das Ergebnis ist ein unterbrochener Conversion-Flow: Der Nutzer glaubt, dass eine Übergabe an einen menschlichen Agenten stattgefunden hat, während kein Lead erfasst wird, keine Benachrichtigung ausgelöst wird und kein Follow-up jemals erfolgt!

Aus diesem Grund erforderte das Testing eine Kombination aus klassischen QA-Techniken und Bewertungsmethoden, die speziell für LLM-Systeme entwickelt wurden.

Grundlegende Unterschiede beim Testen von LLM-Output vs. deterministischen Systemen

CKlassisches Softwaretesten basiert auf Determinismus: Gegeben Zustand A und Input B erwartet man, dass das System Output C zurückliefert. Wenn stattdessen D zurückkommt, wird ein Bug gemeldet.

LLMs sind inhärent probabilistisch. Sie berechnen eine Wahrscheinlichkeitsverteilung über die nächsten möglichen Tokens in einer Sequenz. Dadurch können identische Eingaben unterschiedliche Ausgaben erzeugen. Diese Nicht-Deterministik zerstört klassische Regression-Testing-Workflows. Wenn man eine exakte Gleichheitsprüfung schreibt, die erwartet, dass der Bot sagt: „Die Anwendung ist eine webbasierte SaaS-Plattform“, und der Bot antwortet stattdessen: „Die Software ist eine online bereitgestellte Plattform im SaaS-Modell“, der deterministische Test schlägt fehl. 

Hier entsteht das Problem der semantischen Korrektheit. Die Ausgabe eines LLM kann grammatikalisch anders sein, andere Begriffe verwenden und völlig unterschiedlich strukturiert sein, und dennoch zu 100 % faktisch korrekt und gültig bleiben.

Aus diesem Grund brechen traditionelle Bug-Klassifikation und Reproduzierbarkeits-Workflows zusammen. Ein QA Engineer kann schwer ein „Steps to reproduce“-Ticket für eine LLM-Halluzination erstellen, da dieselben Schritte fünf Minuten später bereits eine perfekte Antwort liefern können.

Konfigurationsabhängige Natur des Systemoutputs

Selbst wenn man fortgeschrittene semantische Tests einsetzt, müssen QA-Teams ein Minenfeld konfigurationsabhängiger Variablen navigieren, das Test-Suites besonders fragil macht.

Zunächst ist die Testgültigkeit eng an spezifische Modellversionen gekoppelt. Unterschiedliche Modelle haben jeweils ihre eigenen Besonderheiten. Eine Test-Suite wird dadurch zu einer Momentaufnahme des erwarteten Verhaltens für ein bestimmtes Modell zu einem bestimmten Zeitpunkt.

Zweitens wirken Inferenz-Parameter wie Temperature (die die Zufälligkeit steuert) und Top-P (die die Vielfalt des Vokabulars kontrolliert) als versteckte Testvariablen. Eine Suite, die bei Temperature 0.2 noch relativ stabil ist, kann bei Temperature 0.7 deutlich weniger deterministisch werden.

Darüber hinaus sind diese Tests extrem empfindlich gegenüber Systemkonfigurationen. Kleine Anpassungen am System-Prompt – selbst scheinbar harmlose Formulierungsänderungen – können die nachgelagerten Outputs drastisch verändern.

Dies führt zu einer dauerhaften Herausforderung: der Unterscheidung zwischen Systemregressionen und erwarteter Varianz. Wenn ein Test fehlschlägt, muss das Team klären, ob das System tatsächlich kaputt ist (z. B. die RAG-Datenbank ist ausgefallen) oder ob das Modell lediglich eine statistisch unwahrscheinliche, aber dennoch akzeptable Antwortvariation erzeugt hat, die der semantische Evaluator nicht korrekt abgedeckt hat.

Schließlich führen Multi-Turn-Konversationen zu einer starken Zustandsverschmutzung. Da das Modell auf dem Gesprächsverlauf basiert, kann eine ungenaue Antwort in Turn eins den Kontext des LLM für Turn drei verfälschen. Das Testen von Multi-Turn-Flows erfordert daher das Isolieren des Zustands, das sorgfältige Management des Konversationskontexts und eine kontinuierliche Re-Validierung der gesamten Suite, während sich das System weiterentwickelt.

Damit erfasst ein Test nur ein eingeschränktes Beobachtungsfenster: eine einzelne Verhaltensschnittebene, erzeugt durch eine bestimmte Modellversion, Decoding-Konfiguration, System-Prompt, Eingabeprompt sowie Retrieval- und Konversationszustand. Sie stellt eine einzelne Trajektorie durch einen wesentlich größeren probabilistischen Raum möglicher Ausgaben dar.

Funktionales Testing

Zunächst wurde eine Liste von Use Cases erstellt. Das funktionale Testing begann mit den wichtigsten Benutzerszenarien, die auf der Website erwartet werden.

Typische Fragen waren unter anderem:

• Erfahrung in bestimmten Branchen
• verwendete Technologien für Backend– oder Frontend-Entwicklung
• Beispiele früherer Projekte
• grobe Projektschätzungen
• Kontaktaufnahme mit dem Vertriebsteam

Besucher fragen in der Regel nach der Erfahrung des Unternehmens, den Technologien und bisherigen Projekten. Einige Gespräche führen auch zu Kontaktanfragen.

Später wurde diese Liste zu Testfällen erweitert. Jeder Testfall ist strukturell wie ein klassischer Test aufgebaut, enthält jedoch spezifische Elemente, die für KI-basierte Systeme charakteristisch sind. Es gibt Abschnitte, die beschreiben, was zwingend enthalten sein muss, was in der Antwort angemessen ist und was unter keinen Umständen enthalten sein darf.

Eine Nutzerfrage wie „Haben Sie bereits Healthcare-Plattformen entwickelt?“ sollte eine Antwort liefern, die auf Portfolio-Daten aus der Wissensdatenbank basiert. Die Antwort sollte dabei reale Projekte erwähnen, falls solche existieren, und das Erfinden von Kunden vermeiden.

Hier folgt die Geschichte, wie wir ein maßgeschneidertes, durchgängiges Python-basiertes Test-Harness entwickelt haben, das für die End-to-End-Validierung von Streaming-Chatbot-Antworten konzipiert ist.

Die Herausforderung: WebSockets und nicht-deterministische Ausgaben

Der Chatbot streamt Tokens sequenziell über SignalR via WebSockets. Wir konnten nicht einfach einen HTTP-POST ausführen und eine JSON-Antwort auslesen. Daher haben wir ein modulares Python-Framework entwickelt, das in einen SignalR-Client, eine Evaluierungs-Engine und einen schlanken Test-Runner aufgeteilt ist.

Es wurde unter Berücksichtigung des „Separation of Concerns“-Prinzips entworfen: Testdaten (JSON-basierte Testfälle und Validierungsregeln) sind von der Transportschicht (SignalR/WebSockets), der Interpretationslogik (NLP-Analyse) und dem Ausführungs-Runner entkoppelt.

Erstellung des SignalR-Clients 

Der erste Schritt bestand darin, die Kommunikation herzustellen. Da unser Chatbot über SignalR arbeitet, haben wir uns für die leichtgewichtige Python-Bibliothek websocket-client entschieden, anstatt schwere Browser-Automation-Tools wie Playwright oder Selenium einzubinden, da unser Ziel war, die API-/Backend-Logik direkt zu testen (Integration/E2E-Ebene ohne UI-Overhead).

SignalR hat dabei seine eigenen Besonderheiten. Es erfordert einen spezifischen JSON-Handshake ({“protocol”: “json”, “version”: 1}) und hängt am Ende jeder Payload ein sehr spezifisches Terminierungszeichen (\x1e) an.

Unser Client-Skript stellt die WebSocket-Verbindung her, verwaltet den Handshake und geht anschließend in eine while True-Listening-Loop. Da das LLM seine Antwort in kleinen Daten-Chunks streamt, parst der Client eingehende ReceiveMessage-Events, konkateniert die Text-Chunks und wartet, bis er vom Server ein isComplete: True-Flag erhält. An diesem Punkt schließt er den Socket sauber und übergibt den vollständigen String an unseren Evaluator.

Drei-Schichten-Validierungsstrategie

Nachdem wir den vollständigen Textstring vom Chatbot erhalten hatten, mussten wir entscheiden, ob er „korrekt“ ist. Wir haben ein dreistufiges Quality-Gate implementiert:

Entkopplung von Logik und Daten: Die JSON-Testfallstruktur 

Eine der wichtigsten architektonischen Entscheidungen, die wir früh getroffen haben, war die strikte Trennung der Testausführungslogik von den Testdaten und Validierungsregeln. Anstatt Test-Szenarien direkt in Python-Skripte zu hardcoden, haben wir alles in eine strukturierte JSON-Datei ausgelagert.

Dadurch entstand eine saubere Separation of Concerns: Der Python-Runner übernimmt das Wie (Transport und Interpretation), während die JSON-Datei das Was definiert (die Eingaben und die Quality Gates).

Jeder Testfall ist ein in sich geschlossenes JSON-Objekt, das als umfassender Vertrag für eine spezifische Chat-Interaktion dient.

Vorteile und Skalierbarkeit dieses Ansatzes:

• Zero-Code-Onboarding: Der wichtigste Vorteil ist die Zugänglichkeit. Business-Analysten, Product Manager oder Junior-QA-Engineers können Testfälle schreiben, ändern und prüfen, ohne WebSockets, Python oder Sentence Transformers verstehen zu müssen. Sie passen einfach die JSON-Datei an.
• Horizontale Skalierbarkeit ohne Grenzen: Da der Runner über ein standardisiertes JSON-Array iteriert, erfordert das Skalieren der Test-Suite von 10 auf 10.000 Testfälle keinerlei architektonische Änderungen am zugrunde liegenden Python-Code.
• Versionskontrolle-freundlich: JSON-Dateien lassen sich in Git sehr gut diffen. Wir können exakt nachverfolgen, wann ein Synonym hinzugefügt wurde oder wann ein expected_answer aktualisiert wurde, um ein neues Produktfeature abzubilden.

Test-Runner und Reporting 

Wir haben einen eigenen CLI-Runner entwickelt, der die test_cases.json-Datei parst und die Test-Suite ausführt.

Zur Unterstützung beim Debugging haben wir colorama sowie reguläre Ausdrücke verwendet, um HTML-Tags zu entfernen und erkannte Keywords sowie Synonyme direkt in der Terminal-Ausgabe dynamisch in hellgrün hervorzuheben. Dadurch können QA-Engineers auf einen Blick visuell nachvollziehen, warum ein Test bestanden oder fehlgeschlagen ist.

Abschließend werden Ausführungsmetriken (Test-ID, Pass/Fail-Status und Antwortdauer in Sekunden) kontinuierlich in eine Ergebnis-Logdatei geschrieben, wodurch wir Latenzzeiten und Regressionsmetriken über die Zeit hinweg nachverfolgen können.

Ergebnisse

Das Testen KI-gestützter Systeme erfordert ein Denken jenseits traditioneller binärer Assertions.

Der Einsatz dieses maßgeschneiderten Frameworks hat die Art und Weise, wie unser Team an AI-Qualitätssicherung herangeht, grundlegend verändert. Wir haben uns von der aufwendigen manuellen Testarbeit entfernt, die viele frühe KI-Projekte belastet, und sie durch eine stärker deterministische, datengetriebene Pipeline ersetzt.

Durch die Kombination aus strenger Keyword-Validierung und semantischer Bewertung haben wir ein Sicherheitsnetz geschaffen, das sowohl flexibel als auch rigoros ist. Dies bildet die Grundlage für die Erhebung harter Metriken wie Latenz, Similarity-Scores und Halluzinations-Erkennungsraten.

Was kommt als Nächstes?

Während die aktuelle Architektur Single-Turn-Anfragen sehr gut verarbeitet, liegt die nächste Herausforderung in zustandsbehafteten Multi-Turn-Konversationen. Wir können das Framework so weiterentwickeln, dass es mit langen kontextuellen Zuständen arbeitet und bewertet, wie gut sich der Bot an Fakten erinnert, die drei oder vier Nachrichten zuvor etabliert wurden. Darüber hinaus prüfen wir die Integration von dynamischen „LLM-as-a-Judge“-Mechanismen, bei denen ein zweites Modell als finaler Schiedsrichter für Chatbot-Antworten fungiert.

Das System kann außerdem um Load- und Concurrency-Testing erweitert werden. Durch das Parallelisieren der Test-Suite über mehrere unabhängige Chat-Sessions hinweg können wir reale Nutzungsmuster simulieren und das Systemverhalten unter gleichzeitigen Anfragen evaluieren. Dadurch lassen sich Performance-Charakteristika wie Antwortlatenz, Durchsatz und Stabilität messen.

Das Testen von KI erfordert es, die Komfortzone absoluter Deterministik zu verlassen. Indem man Frameworks baut, die ebenso intelligent und anpassungsfähig sind wie die Systeme, die sie evaluieren, kann QA aufhören, hinterherzulaufen, und beginnt, die Entwicklung zuverlässiger KI-Produkte aktiv mitzugestalten.

Verwendete Technologien: Python, WebSockets, SignalR, PyTorch, Sentence Transformers (NLP), Scikit-learn, JSON, Regex.

Benötigen Sie Unterstützung beim KI-Testing?

Das Testen von LLM-basierten Systemen erfordert mehr als klassische QA-Ansätze. Eine strukturierte Validierungsstrategie hilft dabei, Halluzinationen zu erkennen und die Zuverlässigkeit von Antworten in produktiven KI-Anwendungen zu verbessern.

Siarhei Nestsiarenka, Chief QA

Project besprechen

(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)

In heutigen mehrsprachigen Arbeitsumgebungen ist eine schnelle und zuverlässige Lokalisierung essenziell. Bei SaM Solutions haben wir uns kürzlich der Herausforderung gestellt, eine große Menge interner Inhalte ins Englische zu übersetzen, indem wir eine KI-gestützte Lösung implementiert haben. Diese Fallstudie beschreibt, wie unser Team ein lokal gehostetes Large Language Model (LLM) nutzte, um die Übersetzung direkt in unserem Content-Management-System (CMS) zu automatisieren und dabei Effizienz, Kosteneinsparungen und vollständige Datenkontrolle zu erreichen.

Business-Need

Da SaM Solutions international weiter wächst, ist der Bedarf an mehrsprachiger Kommunikation zwischen den Abteilungen immer dringlicher geworden. Unser internes Portal, das auf dem Umbraco CMS basiert, dient als zentrale Plattform für Nachrichten, Artikel und Unternehmensupdates. Mit über tausend Seiten Inhalt in verschiedenen Sprachen (Englisch, Deutsch, Polnisch, Litauisch usw.) standen wir vor der operativen Herausforderung sicherzustellen, dass dieses Material für alle Mitarbeiter zugänglich ist – unabhängig von der Ausgangs- oder Zielsprache. Dafür war eine skalierbare Lösung für die Übersetzung zwischen allen Unternehmenssprachen erforderlich.

Eine manuelle Übersetzung wurde geprüft, jedoch aufgrund des Umfangs des Materials und der Zeitbeschränkungen schnell verworfen. Wir benötigten eine automatisierte Lösung, die direkt in unser Unternehmensportal integriert werden kann, den Datenschutz wahrt und qualitativ hochwertige Ergebnisse mit minimalem manuellen Aufwand liefert.

Warum wir uns für ein lokal bereitgestelltes LLM entschieden haben

Cloudbasierte Übersetzungsdienste wurden aufgrund von Bedenken hinsichtlich der Datenvertraulichkeit und laufender Abonnementkosten nicht in Betracht gezogen. Stattdessen entschieden wir uns für die Bereitstellung eines selbst gehosteten LLM. Hier sind einige der wichtigsten Vorteile dieses Ansatzes.

Datensicherheit

Die gesamte Verarbeitung erfolgt auf interner Infrastruktur ohne Einbindung von Drittanbietern, wodurch das Risiko eines Abflusses sensibler Daten verhindert wird.

Geringere langfristige Kosten

Nach der anfänglichen On-Premises-Einrichtung fallen keine wiederkehrenden Lizenzgebühren oder API-Abonnementkosten an. Das Modell kann nach einer einmaligen Bereitstellung langfristig genutzt werden.

Flexible Konfiguration

Jeder Aspekt des Systems kann an spezifische Anforderungen angepasst werden. Es unterstützt sowohl lokal bereitgestellte KI-Modelle als auch Integrationen mit externen Anbietern wie OpenAI, sodass Modelle je nach Aufgabe und Infrastruktur ausgewählt, kombiniert oder gewechselt werden können.

Intranetbasierte Lösung

Das Modell läuft vollständig innerhalb des Unternehmens-Intranets und ermöglicht internen Teams schnellen und zuverlässigen Zugriff, ohne eine Internetverbindung zu benötigen. Dieses Setup entspricht strengen Netzwerkrichtlinien und unterstützt einen sicheren, unterbrechungsfreien Betrieb innerhalb interner Systeme.

Vollständige Integration

Ein lokal bereitgestelltes KI-Modell kann durch die Entwicklung von Model Context Protocols (MCP) direkt mit den internen Anwendungen des Unternehmens verbunden werden und so die Integration verschiedener Workflows sicherstellen.

Individuelle Anpassung

Das System ist vollständig konfigurierbar, um sich an sich verändernde Inhalts- und Sprachanforderungen anzupassen.

Fine-Tuning

Durch die lokale Bereitstellung erhalten wir die volle Kontrolle über den Trainingsprozess und können das Sprachmodell gezielt mit unseren domänenspezifischen Daten feinabstimmen. Dadurch versteht die KI interne Terminologie, Schreibstil und kontextspezifische Formulierungen besser.

Technische Umsetzung

Architektur

Wir entwickelten eine modulare und robuste Architektur, um KI-gestützte Übersetzungen nahtlos in unsere bestehende CMS-Infrastruktur zu integrieren. Das System identifiziert nicht übersetzte Dokumente, indem es die Umbraco-Metadaten nach Content-Typen wie News und Articles durchsucht. Jedem geeigneten Dokument wird ein eigener Übersetzungsjob zugewiesen, wodurch Nachverfolgbarkeit und eine isolierte Verarbeitung gewährleistet werden.

KI & Machine Learning

KI und Computer Vision: Die Zukunft der visuellen Intelligenz

Real-Life-Projekte, KI & Machine Learning

Entwicklung eines KI-Assistenten-Prototyps zur automatisierten Lead-Identifikation und -Qualifizierung

KI & Machine Learning, Digitale Transformation

KI-Entwicklungszyklus – Ein umfassender Leitfaden

Es wurde ein bedingter Veröffentlichungsablauf eingerichtet:

• News-Beiträge (sofern sie in der Originalsprache veröffentlicht sind) werden nach erfolgreicher Übersetzung automatisch veröffentlicht.
• Artikel bleiben zunächst unveröffentlicht und werden zur manuellen Prüfung an zuständige Redakteure weitergeleitet. Der Grund dafür ist, dass Artikel in der Regel länger sind und häufig spezielle Terminologie enthalten (branchenspezifisch oder unternehmensspezifisch), wodurch eine höhere Übersetzungsgenauigkeit erforderlich ist. Dies ist besonders wichtig für Unternehmensrichtlinien, ISO-Dokumentation und andere sensible Materialien.

Dieser Ansatz schafft ein Gleichgewicht zwischen Automatisierung und Qualitätssicherung und ermöglicht eine schnelle Bereitstellung von Inhalten, während dort, wo es erforderlich ist, eine redaktionelle Kontrolle erhalten bleibt.

Key Tools

Wir entschieden uns für Hangfire, eine robuste Job-Scheduling-Bibliothek für .NET, um Übersetzungs-Workflows zu verwalten. Hangfire bietet:

• Zuverlässige Ausführung von Hintergrundjobs,
• Wiederholungslogik für fehlgeschlagene Aufgaben,
• Ein integriertes UI-Dashboard zur Überwachung und Verwaltung des Jobstatus.

Um einen sicheren und komfortablen Zugriff zu gewährleisten, haben wir das Hangfire-Dashboard direkt in die Umbraco-CMS-Oberfläche eingebettet und mit internen Authentifizierungskontrollen konfiguriert.

Um Hangfire an unsere spezifischen Anforderungen anzupassen, führten wir mehrere wichtige Erweiterungen ein:

• Erweiterte Logging-Funktionen:
  Wir integrierten eine Logging-Bibliothek eines Drittanbieters in Hangfire, um eine detaillierte Überwachung und ein einfacheres Debugging von Hintergrundaufgaben zu ermöglichen.
• Erweiterung des Task-Managements:
  Wir entwickelten zusätzliche Funktionen, die es ermöglichen, bestimmte Aufgaben (z. B. Übersetzungsjobs) direkt in Hangfire manuell hinzuzufügen oder neu zu starten. Diese Steuerungen wurden nahtlos in das Hangfire-Dashboard integriert und geben uns mehr Kontrolle und Transparenz über unsere Job-Queue.

Übersetzungsjobs können so geplant werden, dass sie außerhalb der Hauptlastzeiten ausgeführt werden, um Ressourcenkonflikte zu minimieren und Störungen anderer interner Prozesse zu vermeiden. Dadurch können wir die Systemleistung aufrechterhalten und gleichzeitig große Inhaltsmengen effizient verarbeiten.

Überwindung von Herausforderungen

Während der Entwicklung und Testphase traten mehrere praktische Herausforderungen auf, die wir durch gezielte technische Entscheidungen angegangen sind.

Umgang mit langen Dokumenten

Lange Texte überschritten gelegentlich die optimale Eingabelänge des Modells. Um die Stabilität zu gewährleisten, implementierten wir einen Segmentierungsmechanismus, der Inhalte in Abschnitte unterteilt, die das ausgewählte Modell-Kontextfenster nicht überschreiten.

Umgang mit komplexem Format

Artikel mit aufwendigem Markup oder eingebetteten HTML-Tags führten manchmal zu fehlerhaften oder „halluzinierten“ Ausgaben. Obwohl solche Fälle selten waren, implementierten wir einen Post-Translation-Validierungsschritt, der die Formatintegrität überprüft und Konsistenz sicherstellt. Bei einem Validierungsfehler erstellt das System automatisch einen Log-Eintrag und markiert den Inhalt zur manuellen Prüfung.

Erkennung von Abkürzungen

Bestimmte Inhalte bestanden aus kurzen Zeichenketten, wie Akronymen oder Produktcodes, die nicht übersetzt werden müssen. Ein Pre-Processing-Filter wurde hinzugefügt, um diese Fälle zu umgehen.

Prompt-Tuning

Da die Qualität des Prompts entscheidend für die Übersetzungsgenauigkeit ist, stellten wir fest, dass selbst gut optimierte Prompts unvorhersehbare Ergebnisse liefern können. Wir verfeinern die Prompts kontinuierlich anhand beobachteter Sonderfälle.

Retry-Logik

Wenn ein Übersetzungsversuch fehlschlägt oder unvollständigen Inhalt liefert, wird der Job automatisch bis zu dreimal wiederholt. Fehler werden für Diagnosezwecke protokolliert.

Post-Processing-Checks

Abgeschlossene Übersetzungen werden auf Fehlerindikatoren wie gemischte Sprachen oder nicht übersetzte Abschnitte geprüft. Diese werden zur manuellen Kontrolle markiert, um die Qualitätssicherung sicherzustellen.

Ausblick

Um die Content-Lokalisierung weiter zu optimieren, planen wir die Entwicklung eines dedizierten Plugins für das Umbraco CMS. Dieses Plugin wird einen „Mit KI übersetzen“-Button direkt in der Redaktionsoberfläche einführen, sodass Benutzer Übersetzungsaufgaben mit einem Klick starten können.

Die Lösung wird sowohl lokal gehostete als auch externe LLMs unterstützen und den Redakteuren die Flexibilität geben, die jeweils am besten geeignete Engine auszuwählen. Nach Fertigstellung planen wir, das Plugin über den offiziellen Umbraco-Marktplatz der breiteren Community zur Verfügung zu stellen.

Fazit

Dieses Projekt zeigt, wie KI verantwortungsvoll und effektiv eingesetzt werden kann, um praktische geschäftliche Herausforderungen zu lösen. Durch die Kombination sorgfältiger Modellauswahl, robuster Systemarchitektur und durchdachter Integration in bestehende Workflows haben wir eine sichere und skalierbare Lösung geschaffen, die unsere internen Abläufe verbessert und uns auf zukünftige Anforderungen der Lokalisierung vorbereitet.

Herausforderung bei Content-Lokalisierung?

Lokal gehostete KI-Modelle bieten die perfekte Lösung: schnell, sicher und vollständig unter Ihrer Kontrolle – für nahtlose Unternehmensübersetzungen.

Andrey Kopanev, Senior .NET Developer, AI-Enthusiast

Starten Sie Ihr Projekt jetzt.

(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)

Risiken über mehrere internationale Standorte hinweg zu steuern und gleichzeitig interne Sicherheitsrichtlinien einzuhalten, ist alles andere als einfach. Genau vor dieser Herausforderung stand unser Kunde – ein global tätiges Unternehmen mit Niederlassungen auf mehreren Kontinenten. Gesucht wurde ein zentrales Risikomanagementsystem, das Sicherheitsvorgaben, Zugriffsregeln und Workflow-Automatisierung unternehmensweit miteinander verbindet.

Das Entwicklungsteam von SaM Solutions konzipierte und implementierte ein maßgeschneidertes Enterprise-Risk-Management-(ERM)-Modul auf Basis von .NET, das in eine bestehende Systemlandschaft integriert wurde. Ziel war es, Transparenz, Kontrolle und Effizienz im Umgang mit Risiken deutlich zu erhöhen.

Lesen Sie weiter und erfahren Sie Schritt für Schritt, wie wir dieses Projekt umgesetzt haben. Und wenn Sie vor einer ähnlichen Aufgabe stehen, sprechen Sie uns gerne an.

Businessanforderungen

Unser Kunde ist ein weltweit führendes Technologieunternehmen in den Bereichen Elektrifizierung und Automatisierung. Mit Aktivitäten in über 140 Ländern und rund 160.000 Mitarbeitenden benötigte das Unternehmen leistungsfähige Werkzeuge, um die wachsende Komplexität – insbesondere im Risikomanagement und in internen Prozessen – besser zu steuern.

Eine zentrale Herausforderung war die bestehende Systemlandschaft: Viele Abläufe basierten noch auf Lotus-Notes-Formularen, die veraltet und schwer wartbar waren. Der Kunde wollte diese Situation nicht nur für eine Migration nutzen, sondern seinen gesamten Ansatz modernisieren und zukunftssicher neu aufstellen.

Ganz oben auf der Prioritätenliste stand die Entwicklung eines zentralen Risikomanagement-Moduls. Die Lösung sollte weltweit in allen Niederlassungen einsetzbar sein und eng mit Sicherheitsmechanismen, Rollen- und Berechtigungskonzepten sowie Genehmigungs-Workflows integriert werden. Gleichzeitig musste das System Risiken übersichtlich visualisieren und strukturiert darstellen, damit Teams fundierte Entscheidungen treffen können.

Darüber hinaus umfasste unser Auftrag weitere zentrale Aufgaben:

• Entwicklung einer maßgeschneiderten IT-Lösung für das unternehmensweite F&E-Zentrum, abgestimmt auf interne Prozesse und globale Zusammenarbeit.
• Aufbau eines separaten Moduls für Reporting, Personalbudgetierung, Cross-Budgeting sowie mehrstufige Genehmigungsprozesse, um Finanzplanung und Transparenz über Abteilungsgrenzen hinweg zu unterstützen.

Die Ausgangssituation des Kunden

Zu Beginn der Zusammenarbeit wurde schnell deutlich: Gesucht war nicht einfach ein neues System, sondern eine nachhaltige Lösung, um zentrale Prozesse wieder beherrschbar zu machen, die mit dem internationalen Wachstum zunehmend komplex geworden waren.

„Es ging nicht nur darum, ein Altsystem zu ersetzen. Ziel war es, das Risiko- und Prozessmanagement über die gesamte globale Organisation hinweg neu zu denken.“

Wie viele große Unternehmen stand auch dieser Kunde vor mehreren typischen Herausforderungen.

• Fragmentierte Datenstruktur: Dutzende unstrukturierte Lotus-Notes-Formulare waren über Abteilungen und Länder verteilt, jeweils mit eigener Logik und eigenem Zweck. Eine zentrale, verlässliche Quelle zur Steuerung von Risiken fehlte.
• Zugriffsprobleme: Benutzerberechtigungen waren uneinheitlich geregelt. Einige Mitarbeitende hatten zu weitreichenden Zugriff, andere hingegen zu eingeschränkten – was sowohl Sicherheitsrisiken als auch operative Engpässe verursachte.
• Probleme mit der Datenintegrität: Ohne ein einheitliches System war es schwierig, Daten korrekt, aktuell und standortübergreifend synchron zu halten. Dadurch stieg das Risiko von Fehlern und Compliance-Verstößen.
• Begrenzte Transparenz: Eine visuelle Darstellung und Priorisierung von Risiken war nicht möglich. Führungskräfte konnten nur schwer erkennen, wo Probleme auftraten, wie sie bearbeitet wurden oder wie die aktuelle Risikolage insgesamt aussah.
• Manuelle und uneinheitliche Genehmigungen: Besonders im F&E-Bereich waren Genehmigungsprozesse komplex und wurden manuell abgewickelt. Das verlangsamte Projekte und führte zu unnötigen Reibungsverlusten.
• Keine einheitliche Risikomanagement-Strategie: Jede Niederlassung bewertete und behandelte Risiken auf eigene Weise. Dadurch entstanden Inkonsistenzen bei der weltweiten Umsetzung von Sicherheits- und Compliance-Standards.

All diese Faktoren bremsten das Unternehmen aus – sie verlangsamten Abläufe und erhöhten sowohl operative als auch regulatorische Risiken. Benötigt wurde ein zentrales, flexibles System, das alle Prozesse zusammenführt, international einsetzbar ist und gleichzeitig so benutzerfreundlich bleibt, dass sowohl technische als auch nicht-technische Mitarbeitende effizient damit arbeiten können.

Mögliche Lösungsansätze

Zu Beginn des Projekts prüften wir verschiedene technologische Optionen. Ein komplexes, unternehmensweites und sicherheitskritisches System dieser Art ließe sich grundsätzlich mit Java-Frameworks, Python-basierten Backends, PHP-Lösungen oder auch Low-Code-Enterprise-Plattformen umsetzen. Jede dieser Varianten hatte ihre Vorteile.

Warum .NET die beste Wahl für dieses Projekt war

Am Ende setzte sich .NET klar durch – und das nicht nur, weil die Plattform große Datenmengen auf Enterprise-Niveau effizient verarbeiten kann und integrierte Authentifizierungs- sowie rollenbasierte Zugriffskontrollen bietet.

Der Kunde verfügte bereits über mehrere interne Systeme auf .NET-Basis und über eine gut etablierte IT-Abteilung mit entsprechender Expertise. Zudem kamen unternehmensweit Microsoft-Technologien zum Einsatz, was Integration und laufenden Support deutlich vereinfachte. Durch die Wahl von .NET konnten wir auf dem bestehenden Ökosystem aufbauen, dank des langfristigen Supports durch Microsoft eine hohe Wartbarkeit sicherstellen und die Entwicklung durch enge Zusammenarbeit mit dem internen Team effizient gestalten. Für dieses Projekt war es daher sinnvoll, die Reihe .NET-basierter Lösungen fortzuführen.

Unser Vorgehen im Projekt

Nachdem Technologie-Stack und Ziele abgestimmt waren, arbeiteten wir nach einem agilen Entwicklungsansatz. In Sprints und mit enger Abstimmung mit den Stakeholdern des Kunden blieben wir flexibel, lieferten früh Mehrwert und entwickelten das System kontinuierlich auf Basis realer Rückmeldungen weiter.

Um ein System dieser Größenordnung und Komplexität umzusetzen, stellten wir ein funktionsübergreifendes Team zusammen, bestehend aus:

• 2 Solution Architects (seitens des Kunden) – verantwortlich für das Gesamtdesign des Systems und die Integrationsstrategie.
• 2 .NET-Entwicklern – zuständig für Backend-Entwicklung und Business-Logik.
• 3 Full-Stack-Entwicklern – verantwortlich für UI-Komponenten und Datenvisualisierungen.
• 1 QA Engineer – zuständig für Testautomatisierung und manuelle Tests in verschiedenen Umgebungen.

Dieses Team arbeitete eng mit der internen IT-Abteilung des Kunden zusammen, die ebenfalls über .NET-Spezialisten verfügte. Diese wurden schrittweise eingebunden, um Support und zukünftige Weiterentwicklung sicherzustellen.

Implementierte Kernfunktionen

Das gesamte System basiert auf .NET Core, mit einem SQL Server-Backend und einem JavaScript-Frontend nach dem MVC-Pattern. CI/CD-Pipelines sorgen für reibungslose Deployments, und das System wird auf Azure gehostet, um globale Verfügbarkeit, Leistung und Sicherheit zu gewährleisten.

Herausforderungen während der Entwicklung

Wie jedes großangelegte Unternehmensprojekt brachte auch dieses seine eigenen technischen und organisatorischen Herausforderungen mit sich. So sind wir die wichtigsten Punkte angegangen.

Flexible Risikovisualisierung gestalten

Eine zentrale Anforderung war, den Nutzern ein visuelles Verständnis der Risiken im Unternehmen zu vermitteln. Bei so vielen Variablen – Regionen, Kategorien, Schweregrade, Zeitachsen – mussten wir eine Visualisierung entwickeln, die sowohl flexibel als auch benutzerfreundlich ist.

Unser Team entwarf eine modulare, interaktive Oberfläche, die Risiken in Echtzeit gruppieren, filtern und farblich darstellen kann. Das Ergebnis ermöglicht es den Nutzern, ihre Risikolage sofort zu erfassen, ohne von Daten überwältigt zu werden.

Zugriffsrechte gemeinsam mit dem Kunden abstimmen

Die Umsetzung der Zugriffsrechte bezog sich nicht nur auf Rollen, sondern musste die Organisationsstruktur, Betriebsmodelle und internen Richtlinien des Kunden widerspiegeln. Gemeinsam mit dem Kunden haben wir die reale Hierarchie in ein flexibles Berechtigungssystem übertragen, das regionale und abteilungsspezifische Zugriffe unterstützt.

Nach mehreren Iterationen entstand ein Modell, das die Sicherheitsanforderungen präzise abdeckt und zugleich für Administratoren einfach zu verwalten ist.

Daten aus Altsystemen migrieren

Der Kunde hatte jahrelange Risiko-Daten in verschiedenen Lotus-Notes-Formularen und Tabellen gespeichert. Diese in das neue System zu übertragen und dabei Genauigkeit sowie Beziehungen zwischen den Datensätzen zu erhalten, war eine große Aufgabe.

Wir entwickelten eine maßgeschneiderte Migrationspipeline, um die Daten zu bereinigen, zu transformieren und in die neue Struktur zu importieren, mit gründlichen Tests zur Sicherstellung der Datenintegrität. So konnten die Nutzer ohne Verlust historischer Kontexte im neuen System arbeiten.

Echtzeit-Updates ohne Mehraufwand ermöglichen

Im Risikomanagement zählt Timing – Risiken können täglich auftreten oder sich ändern. Das System musste häufige Updates unterstützen, ohne den Nutzern oder dem Support-Team zusätzlichen Aufwand zu bereiten.

Zur Lösung setzten wir auf smarte Voreinstellungen, Inline-Bearbeitung und Änderungsverfolgung. Außerdem wurde das System so entwickelt, dass es erwartete Leistungskennzahlen erfüllt, inklusive eines Notfallplans zur Wiederherstellung.

Stehen Sie vor ähnlichen Herausforderungen?

Wenn Ihr Unternehmen vor Fragen des Risikomanagements, der Prozessautomatisierung oder der Modernisierung von Systemen steht, ist unser Team für Sie da. Bei SaM Solutions verbinden wir tiefgehende technische Expertise mit einem praxisnahen, geschäftsorientierten Ansatz, um maßgeschneiderte Lösungen zu entwickeln, die skalierbar und zukunftssicher sind.

Dzmitry Verasau, Chief .NET Technologist

Projekt besprechen

(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)

Das Fachmedium Ecommerce Germany schreibt, dass die DACH-Region „goes into 2026 as a very online, very picky, and very price-aware group of shoppers“.

Fast alle Menschen im Alter von 16 bis 74 Jahren nutzen das Internet, laut European E-commerce Report 2025. Und die Formulierung „fast alle“ ist wörtlich zu verstehen: In der Schweiz hat dieser Wert 100 % erreicht, in Österreich und Deutschland etwas weniger — 95 % bzw. 94 %. Rund 78 % kaufen mindestens einmal pro Jahr online ein. Es ist daher nicht überraschend, dass inzwischen jeder zweite Einkauf über digitale Zahlverfahren erfolgt.

Die Chancen und Herausforderungen für E-Commerce-Unternehmen wachsen, und in der aktuellen Situation können sie sich veraltete Architekturen schlicht nicht leisten.

Warum gewachsene E-Commerce-Architekturen an ihre Grenzen stoßen

Viele deutsche Händler sind technologisch organisch gewachsen: erst der Shop, dann ERP-, PIM- und WMS-Anbindungen, später Marktplatz-Connectoren, Marketing-Tools und Analytics. Über die Jahre entsteht ein funktionierender, aber hochgekoppelter Systemverbund.

Unter weiterem Wachstum werden jedoch typische Systemgrenzen sichtbar: 

• steigende Release-Risiken, 
• fragile Integrationen, 
• Daten-Inkonsistenzen,
• schwer kalkulierbare Betriebs- sowie Change-Kosten. 

Diese Dynamik ist grundsätzlich branchenweit zu beobachten, wird im deutschen Markt jedoch häufig durch starke ERP-Prägung, regulatorische Anforderungen und komplexe Organisationsstrukturen verstärkt.

Typische Wachstumstreiber im E-Commerce

Im deutschen E-Commerce wächst die Systemkomplexität vor allem entlang von drei Achsen: Last, Funktionsumfang und Kanalvielfalt.

In Summe entsteht kein linearer, sondern ein überproportionaler Komplexitätsanstieg, der gewachsene Architekturen besonders stark unter Druck setzt.

Wo Legacy-Systeme zum Risiko werden

Monolithische oder suite-zentrierte Kerne entwickeln sich zu Change-Bottlenecks: Releases werden langsamer, Testaufwände steigen und Upgrades geraten zu Großprojekten.

Gleichzeitig verschiebt sich der Fokus vieler Teams von Feature-Delivery hin zur Beherrschung von Integration Debt. Mit jedem zusätzlichen Partner, Payment-Provider oder Marktplatz wächst die operative Komplexität nichtlinear. Häufig verstärken Daten-Silos und konkurrierende Sources of Truth das Problem.

Unter Last zeigen sich die Folgen besonders deutlich: Skalierung wird teuer, Verfügbarkeit leidet bei starker Kopplung, und Performance-Regressionen schlagen direkt auf Conversion und Umsatz durch. Parallel erhöhen Cloud-Abhängigkeiten und neue regulatorische Pflichten das strategische Risiko. Legacy ist damit nicht nur ein technisches, sondern ein betriebswirtschaftliches Problem.

Woran Unternehmen kritische Engpässe erkennen

Modernisierungen scheitern selten am Ziel — meist daran, dass Teams den Engpass zu spät sehen. Die cleveren Organisationen kombinieren klassische Systemmetriken (Golden Signals: Latenz, Traffic, Errors, Saturation) mit E-Commerce-Kennzahlen wie Add-to-Cart-Rate oder Payment-Success, um Probleme früh als Umsatzrisiko zu erkennen. Lasttests simulieren echte User-Journeys inklusive Peak-Spikes und Payment-Mix, Postmortems und Observability liefern direktes Feedback für Architekturentscheidungen. Wer Verantwortung übernimmt („you build it, you run it“), erkennt Engpässe rechtzeitig und kann gezielt gegensteuern.

Wie echte Unternehmen ihre E-Commerce-Architektur fit für Wachstum machen

SaM Solutions hat die Herausforderungen von drei E‑Commerce-Unternehmen genau unter die Lupe genommen.

Wenn Auftrags- und Bestandsprozesse zum Skalierungsproblem werden

Fluent Commerce ist ein international tätiger Anbieter einer Order-Management-Plattform, die Einzelhändlern hilft, Bestände und Aufträge kanalübergreifend in Echtzeit zu steuern. Mit der Expansion in neue Märkte stiegen die Anforderungen an Skalierbarkeit, Performance und Transparenz deutlich. Ohne moderne Architektur kam es zu Verzögerungen bei Bestandsaktualisierungen, eingeschränkter Echtzeit-Übersicht und steigenden operativen Risiken.

SaM Solutions implementierte eine optimierte OMS-Lösung: Echtzeit-Bestandsmanagement, Multi-Paket-Processing, verbesserte Systemüberwachung, nahtlose Payment-Integration und optimierte Benutzeroberflächen. Dadurch konnte Fluent Commerce die Performance steigern, die Order- und Bestandsprozesse stabilisieren und die Grundlage für weiteres Wachstum und innovative Services schaffen.

Wenn die Shop-Plattform an ihre Grenzen stößt

Brooklyn Soap Company ist eine Grooming-Marke für Männer, die hochwertige, natürliche Pflegeprodukte anbietet und in mehrere europäische Märkte expandierte. Ihr Shop lief auf Magento 2, was zunehmend die Skalierbarkeit und Entwicklung verlangsamte: Datenformate waren inkompatibel, zentrale Funktionen mussten neu gedacht werden, und Marketing-Teams hatten nur begrenzte Flexibilität bei der Shop‑Administration.

SaM Solutions migrierte den gesamten Storefront zu Shopify, entwickelte ein vollständig individuelles Theme und baute zentrale Funktionen wie einen „Bundle Builder“ und Checkout‑Upsells neu. Dabei wurde eine maßgeschneiderte Datenkonvertierung implementiert, um Kunden, Bestellungen, Produkte und Konfigurationen fehlerfrei zu übertragen.

Das Ergebnis ist eine leistungsstarke, modulare E‑Commerce‑Plattform, die flexibel wächst, schneller in neue Märkte geht und die User Experience verbessert — inklusive höherer Skalierbarkeit, besserer Produkt‑ und Content‑Verwaltung sowie einzigartiger Checkout‑Funktionen, die den durchschnittlichen Bestellwert steigern.

Wenn das ERP-System die digitale Agilität begrenzt

DiscountFilterStore.com ist ein global tätiger Onlinehändler für Wasserfiltersysteme, der über eigenen Shop und große Marktplätze wie Amazon, eBay und Walmart verkauft. Um Kosten zu senken und mehr Flexibilität zu gewinnen, entschied sich das Unternehmen, seine Geschäftsprozesse von Oracle NetSuite auf Odoo zu migrieren — ohne Unterbrechung der laufenden Verkäufe oder Integrationen.

SaM Solutions entwarf eine kontrollierte ERP‑Migration inklusive eines speziell entwickelten Synchronisationstools, optimierter Marktplatz‑Integrationen und Workflow‑Anpassungen, die Odoo als zentrales System etablierten. Parallel wurden bestehende Marktplatzverknüpfungen und die WMS‑Integration angepasst und die Lösung in Odoo.sh bereitgestellt.

Die Migration führte zu deutlich reduzierten ERP‑Kosten (bis zu 10‑fach), verbesserter Stabilität aller Integrationen, höherer Daten‑Transparenz sowie einer skalierbareren, ressourcenschonenderen ERP‑Architektur — und das alles ohne Datenverlust oder Ausfallzeiten.

E-Commerce & Kundenerlebnis (CX)

Composable Commerce Migration: Ihre Schritt-für-Schritt-Strategie

Digitale Transformation, E-Commerce & Kundenerlebnis (CX)

Composable Commerce und Digitale Transformation

E-Commerce & Kundenerlebnis (CX)

Was ist Composable Commerce?

Strategische Erkenntnisse aus drei Modernisierungsprojekten

Architektur-Quick-Check für E-Commerce-Verantwortliche

Unternehmen, die ihre E-Commerce-Architektur modernisieren wollen, müssen typische Engpässe früh erkennen. Die folgenden Checkpoints zeigen Warnsignale und praxisnahe Maßnahmen, um Risiken bei Traffic, Daten, Integrationen und Compliance zu minimieren.

Fazit: Skalierbarkeit beginnt bei der Architektur

Nur wer modulare Systeme nutzt, klare Datenflüsse etabliert und flexible Integrationen implementiert, kann Traffic-Spitzen meistern, Multi-Channel-Expansion ermöglichen und schnelle Anpassungen im Wettbewerb umsetzen. Moderne Plattformen bilden die Basis für stabile Prozesse, bessere Customer Experience und nachhaltiges Wachstum im E‑Commerce.

(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)

Die Gewinnung potenzieller Kunden für Softwareentwicklungsdienstleistungen ist selten eine einfache Aufgabe. In der Praxis bedeutet sie häufig, Chats, Foren und soziale Netzwerke manuell zu beobachten, vielversprechende Gespräche zu identifizieren und potenzielle Kontakte anschließend einzeln mit ähnlichen Einleitungsnachrichten anzusprechen. Dieser Prozess ist zeitaufwendig, repetitiv und kaum skalierbar.

In diesem Artikel erläutere ich, wie ich einen funktionsfähigen Prototyp eines KI-gestützten Assistenten namens SaMio entwickelt habe, der die frühzeitige Lead-Identifikation und -Qualifizierung für Softwareentwicklungsanbieter automatisiert und dabei Gespräche natürlich, respektvoll und kontextsensitiv gestaltet.

Die Herausforderung: Manuelle Lead-Identifikation skaliert nicht

Der Ausgangspunkt war ein sehr typischer Workflow aus der Praxis.

Ein Mitarbeiter eines Unternehmens überwacht kontinuierlich Chats und soziale Plattformen, um Personen zu identifizieren, die möglicherweise an Softwareentwicklungsdienstleistungen interessiert sind. Wird eine solche Person gefunden, ähnelt der nächste Schritt klassischer Kaltakquise – nur über moderne Messenger statt per Telefon. Die Ansprache folgt dabei meist einem festen Muster: Begrüßung, einige qualifizierende Fragen und anschließend entweder ein konkretes Angebot oder ein höflicher Rückzug.

Die Probleme dieses Ansatzes lagen auf der Hand:

• Dieselben Einleitungsnachrichten mussten immer wieder manuell formuliert werden.
• Gespräche verliefen selten strikt linear entlang eines Skripts.
• Personen konnten jederzeit ablehnen, nicht reagieren oder das Thema wechseln.
• Es war schwierig, konsistent zu bewerten, ob eine Person tatsächlich dem Ideal Customer Profile (ICP) entsprach.

Ziel war es daher, diesen Prozess zu automatisieren, ohne daraus eine robotische Spam-Maschine zu machen und ohne Menschen zu verärgern.

Die Grundidee: Skriptbasierter Ablauf und Anpassungsfähigkeit von LLMs

Anstatt Gespräche vollständig frei zu improvisieren, habe ich mit einem strukturierten, skriptbasierten Ansatz begonnen.

Im Kern von SaMio steht eine definierte Gesprächslogik, die aus folgenden Elementen besteht:

• initialen Begrüßungsnachrichten,
• einer Abfolge qualifizierender Fragen,
• abschließenden Erfolgs- oder Abbruchnachrichten.

Jeder Frageschritt verfolgt ein konkretes Validierungsziel, zum Beispiel die Identifikation der Branche, der Unternehmensgröße oder der Rolle der Person im Unternehmen. Die Anzahl der Fragen ist flexibel und kann je nach geschäftlichen Anforderungen erweitert werden.

Ein statisches Skript allein würde jedoch niemals natürlich wirken. Reale Gespräche sind unordentlich: Menschen antworten indirekt, stellen themenfremde Fragen oder präzisieren frühere Aussagen. Genau hier wird KI unverzichtbar.

Das Gespräch menschlich wirken lassen

Um Dialoge natürlich wirken zu lassen, habe ich ein Large Language Model (LLM) angebunden, das sich an den Kommunikationsstil und den Kontext des Gegenübers anpasst.
SaMio versendet dabei nicht einfach vordefinierte Nachrichten, sondern:

• wählt passende Varianten aus dem Skript aus,
• interpretiert frei formulierte Antworten der Nutzer,
• extrahiert relevante Informationen aus diesen Antworten,
• passt Tonfall und Gesprächstempo an den Verlauf der Unterhaltung an.

Wenn jemand plötzlich über das Wetter spricht oder das Thema wechselt, kann der Assistent natürlich reagieren und das Gespräch bei passender Gelegenheit behutsam wieder zurückführen.

Gleichzeitig muss der Assistent klare Grenzen erkennen. Lehnt eine Person das Gespräch ab oder signalisiert deutliches Desinteresse, respektiert der Assistent diese Entscheidung und beendet den Dialog, ohne weiter nachzusetzen.

Dieses Gleichgewicht – anpassungsfähig zu sein, ohne aufdringlich zu wirken – war eines der wichtigsten Designziele.

Qualifizierungs- und Validierungslogik

Im Verlauf des Gesprächs sammelt SaMio die Antworten auf die qualifizierenden Fragen. Wichtig dabei:

• Die Antworten werden separat gespeichert und können später aktualisiert werden, falls der Nutzer zusätzliche Informationen liefert.
• Das System vermeidet es, dieselbe Frage mehrfach zu stellen.
• Jede Antwort fließt in eine Gesamtbewertung ein, wie gut die Person zum definierten Ziel-ICP passt.

Sobald alle relevanten Daten gesammelt sind oder das Gespräch auf natürliche Weise zu einem Ende kommt, bewertet der Assistent das Ergebnis.

Passt der potenzielle Kunde zum ICP, wählt der Assistent eine von mehreren Erfolgsmeldungen aus. Diese sind zurückhaltende, nicht aufdringliche Vorschläge, z. B. ein kurzes Demo-Angebot, das Teilen eines Leitfadens oder das Zeigen konkreter Beispiele.

Passt die Person nicht oder lehnt eine weitere Diskussion ab, wählt der Assistent eine höfliche, wertschätzende und respektvolle Absage aus.

Post-Conversation-Automatisierung

SaMio hört nach der Konversation nicht auf zu arbeiten. Nach dem Ende des Gesprächs:

• wird automatisch eine Zusammenfassungs-E-Mail mit den Ergebnissen des Dialogs versendet,
• wird der gesamte Gesprächsverlauf in der Datenbank für spätere Auswertungen gespeichert,
• werden relevante Daten mit Google Sheets synchronisiert, sodass die Lead-Verfolgung ohne manuelle Eingaben stets aktuell bleibt.

Dies gewährleistet Transparenz, Nachvollziehbarkeit und eine einfache Übergabe an Vertriebs- oder Marketingteams.

Beispiel einer Zusammenfassungstabelle

Technische Entscheidungen und Architektur

Anfangs habe ich mit einem lokalen LLM (Gemma) experimentiert. Zwar erschien dieser Ansatz aus Kosten- und Datenschutzsicht attraktiv, zeigte aber schnell seine Grenzen.
Das Modell hatte Schwierigkeiten, mehrdeutige Antworten korrekt zu interpretieren. Reagierte ein Nutzer themenfremd, aber ohne das Gespräch abzulehnen, konnte das Modell häufig nicht sinnvoll adaptieren und weitermachen.

Daraufhin wechselte ich zu GPT-4o-mini, gehostet auf Azure. Dieses Modell bot deutlich bessere Stabilität in der Konversation und ein zuverlässigeres Kontextverständnis.

Eine weitere zentrale Herausforderung war die Kontrolle von Gesprächsabweichungen. Da cloudbasierte Modelle kostenpflichtige Tokens verbrauchen, war es nicht möglich, den Assistenten lange, irrelevante Gespräche führen zu lassen. Es galt, sorgfältig abzuwägen zwischen:

• Zulassen von natürlichem Small Talk,
• Sanftes Zurückführen des Gesprächs auf das Thema,
• Vermeidung unnötiger Token-Verbräuche,
• Vermeidung offensichtlichen „Bot-Verhaltens“.

Hier spielt Prompt-Engineering eine wichtige Rolle, um Grenzen zu definieren und gleichzeitig Flexibilität zu erhalten.

Technologie-Stack

Der Prototyp wurde aufgebaut mit:

• Azure,
• Docker,
• .NET,
• PostgreSQL

Das Ergebnis: Ein funktionsfähiger, produktionsreifer Prototyp

SaMio ist ein voll funktionsfähiger Prototyp, der:

• natürliche, adaptive Gespräche führt,
• Leads basierend auf echten Antworten qualifiziert,
• die Grenzen der Nutzer respektiert,
• Follow-ups und Berichte automatisiert,
• Daten zuverlässig speichert und synchronisiert.

Am wichtigsten ist: SaMio zeigt, wie LLM-basierte Assistenten über einfache Chatbots hinausgehen und zu praktischen Werkzeugen für echte Geschäftsprozesse werden können, wenn sie mit strukturierter Logik, Validierungsregeln und durchdachten Einschränkungen kombiniert werden.

Fazit

Dieses Projekt hat eindrücklich gezeigt, dass erfolgreiche KI-Systeme selten „reine KI“ sind. Der eigentliche Mehrwert entsteht an der Schnittstelle von strukturierten Geschäftsskripten, menschlichen Kommunikationsmustern und sorgfältig kontrollierten Sprachmodellen.

Für Softwareentwicklungsanbieter eröffnet dieser Ansatz neue Möglichkeiten für skalierbare, respektvolle Lead-Generierung, ohne Authentizität oder Vertrauen zu gefährden.

Wer ähnliche Automatisierungsherausforderungen untersucht, sollte sich eine einfache Erkenntnis zu Herzen nehmen: Beginnen Sie mit realen menschlichen Arbeitsabläufen und lassen Sie die KI diese verbessern – nicht blind ersetzen.

(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)

Moderne Websites leiden nicht an einem Mangel an Informationen – im Gegenteil: Sie leiden oft unter Informationsüberfluss. Blogs, News, Leistungsseiten, Eventankündigungen, Case Studies … alles ist relevant, alles wächst, und alles ist über Navigationspfade verteilt, die für Besucher wenig Sinn ergeben, wenn sie einfach nur eine konkrete Antwort suchen.

Genau deshalb haben wir ein internes RAG-Projekt (Retrieval-Augmented Generation) gestartet: um einen Website-Chatbot zu betreiben, der Fragen auf Basis unserer tatsächlichen Inhalte beantwortet. Verlässlich, datenschutzkonform und ohne so zu tun, als würde er Dinge „wissen“, die er nie gesehen hat.

Entdecken Sie die praktische Geschichte, wie wir das System aufgebaut haben, was zunächst nicht funktioniert hat und was die Antworten schließlich spürbar präziser gemacht hat.

Business-Anforderung des Kunden

Das Projekt begann mit der Anfrage eines Kunden, eine skalierbare KI-Plattform zu entwerfen und zu implementieren.

Unser übergeordnetes Ziel war es, ein System zu schaffen, das:

• die Registrierung und den Zugriff auf das System ermöglicht,
• mehrere unterschiedliche Modelle anbinden kann,
• einen KI-Pop-up-Chat auf jeder Website einbettet.

Im Rahmen des MCP-Umfangs benötigte der Chatbot einige klar definierte Funktionen:

• Beantwortung von Nutzerfragen mithilfe der Website-Inhalte (Blogs, Artikel, News, Event-Seiten).
• Versand von E-Mails direkt aus dem Chat-Flow heraus (damit Besucher Fragen stellen, fehlende Informationen bereitstellen und eine Kontaktaufnahme auslösen können, ohne ein klassisches Kontaktformular ausfüllen zu müssen).

Das eigentliche Problem verstehen

Ein Website-Chatbot wirkt auf den ersten Blick einfach. Das bleibt jedoch nur so lange so, bis man versucht, ihn wirklich präzise zu machen. Die zentrale Einschränkung war dabei klar:

• Ein allgemeines LLM kennt den aktuellen Stand unserer Website nicht automatisch.
• Große, cloudbasierte Sprachmodelle bringen zudem erhebliche Herausforderungen in Bezug auf Kosten, Datenschutz und die Abhängigkeit von externer Infrastruktur mit sich. Das gilt insbesondere dann, wenn sie nicht nur auf öffentliche Webinhalte, sondern auch auf interne oder sensible Informationen angewendet werden.
• Infolgedessen entscheiden sich viele Teams für kleinere, lokal betriebene Modelle. Dieser Wechsel legt jedoch einen neuen Engpass offen: begrenzte Kontextfenster. Wenn ganze Dokumente oder Seiten in einen einzigen Prompt geladen werden, skaliert dieser Ansatz nicht mehr – Eingaben werden abgeschnitten, und irrelevante Abschnitte verbrauchen wertvollen Kontext. Der Ansatz mit „einem riesigen Prompt“ wird damit fragil und ineffizient.

Anstatt dem Modell also alles auf einmal „beizubringen“, haben wir uns für den Ansatz entschieden, der sich in realen Produktionssystemen bewährt hat: Zuerst werden die passenden Inhaltsbausteine abgerufen, und erst danach wird auf deren Basis die Antwort generiert. Genau das ist RAG.

Lösungen entdecken

Wir haben verschiedene Ansätze untersucht, bevor wir uns festgelegt haben.

Option 1: Die Seite als Prompt verwenden

Warum es scheiterte:

• Webseiten enthalten LLM-irrelevantes Rauschen (z. B. Navigation, wiederholte Abschnitte, versteckte Elemente, Cookie-Hinweise), das nichts mit der eigentlichen Anfrage zu tun hat.
• Begrenzte Kontextfenster führen dazu, dass das Modell Inhalte sowieso verwirft.
• Die Antworten können je nach abgeschnittenen Inhalten stark variieren.

Option 2: Cloud-Ingestion + verwaltete Suche (z. B. Azure)

Warum wir uns in dieser Phase dagegen entschieden haben:

• Die Kosten steigen schnell, sobald Inhalte häufig indexiert und die Nutzung skaliert wird.
• Datenschutz und Kontrolle werden auf lange Sicht komplexer, insbesondere bei internen Erweiterungen.

Option 3: Fine-Tuning

Warum es nicht passt:

• Ständige Website-Updates würden ständiges Nachtrainieren oder Modell-Drift erfordern.
• Fine-Tuning beantwortet nicht automatisch die Frage: „Woher stammt diese Antwort?“
• Zudem ist es rechenintensiv und erfordert tiefgehendes ML-Fachwissen, um Modelle effektiv zu trainieren, zu warten und zu debuggen.

Option 4: RAG mit lokalen Komponenten

Warum wir uns dafür entschieden haben:

• Wir behalten die volle Kontrolle über Daten und Kosten.
• Wir können das Konzept zunächst mit öffentlichen Inhalten testen und später sicher auf internes Wissen ausweiten.
• Wir können die Wissensbasis kontinuierlich aktualisieren, indem Inhalte neu indexiert werden.

KI & Machine Learning

Was ist Retrieval Augmented Generation (RAG)?

KI & Machine Learning, Digitale Transformation

KI-Entwicklungszyklus – Ein umfassender Leitfaden

KI & Machine Learning, Softwareentwicklung

Was ist Agentic AI? Der Leitfaden zu agentenbasierter Künstlicher Intelligenz

So haben wir den Prozess umgesetzt

Um eine interne RAG-Engine bereitzustellen, die Ingestion, Retrieval, LLM-Orchestrierung und die Einbettung auf der Website abdeckt, haben wir ein funktionsübergreifendes Team zusammengestellt:

• Project Manager (PM) – koordinierte die Stakeholder, definierte Iterationen und Meilensteine und hielt den Umfang unter Kontrolle, während sich die Anforderungen weiterentwickelten.
• Architekt – verantwortete die Zielarchitektur, den Integrationsansatz und zentrale technische Entscheidungen wie Sicherheit, Skalierbarkeit und Datenfluss.
• .NET-Entwickler – implementierte die RAG-Services, die Retrieval-Pipeline, die Integration der Vektordatenbank und die MCP-Tools (Suche, Aktionen).
• Frontend-Entwickler – entwickelte die Chatbot-Benutzeroberfläche und die Nutzerflows, die notwendig sind, um den Chatbot auf der Website einzubetten und in realen Sessions nutzbar zu machen.
• 2 Java-Entwickler – unterstützten Java-basierte Backend-Services und Integrationen; entwickelten die MCP-Plattform sowohl in .NET als auch in Java mit einheitlicher Architektur, wobei die Java-Implementierung für die Produktion ausgewählt wurde; bauten und pflegten CI/CD, Kubernetes, GitOps und überwachten die Stabilität der Plattform.

Dieses Setup ermöglichte es uns, schnell zu iterieren und die endgültige Antwortqualität zu verbessern, während das formalisierten Kommunikationsprotokoll von MCP einem mehrsprachigen, heterogenen Team die Zusammenarbeit erlaubte, ohne von einer einzelnen Expertise abhängig zu sein.

Wir haben die Lösung in Iterationen entwickelt – die erste funktionierte „technisch“, aber noch nicht „produktseitig“.

Version 1: Ein schneller Python-Prototyp (funktionierte, aber war chaotisch)

Wir starteten mit einem Skript, das:

• Seiten crawlte,
• Inhalte extrahierte,
• JSON-Dateien mit den extrahierten Inhalten erzeugte, die anschließend von einem separaten Tool verarbeitet wurden, um Embeddings zu erstellen und sie in der Vektordatenbank zu speichern.

Was schiefging:

• Wir erstellten Embeddings für ganze Seiten inklusive HTML und Tags, was viel irrelevantes „semantisches Rauschen“ erzeugte.
• Zudem stießen wir auf praktische Probleme bei der stabilen Text-zu-Embedding-Konvertierung und der Konsistenz.

Ergebnis: Der Chatbot konnte antworten, aber die Antworten wirkten oft unscharf, zu allgemein oder auf dem falschen Textfragment basierend.

Version 2: Eine Microservice-basierte Pipeline (sauberer, skalierbar)

Sobald unser Microservices-Team eingebunden war, haben wir den Ingestion-Ansatz neu gestaltet: Statt sich durch Querverlinkungen zu „hangeln“, nutzte der Service – wo möglich – die Website-APIs. Der Microservice:

• rief Inhalte ab,
• bereinigte sie,
• teilte sie in Chunks auf,
• erstellte Embeddings für diese Chunks
• und übertrug sie in die Vektordatenbank.

Allein dadurch verbesserte sich die Relevanz deutlich, da das Modell aufhörte, Navigationsmenüs und wiederholte UI-Blöcke „mitzulernen“.

Entwurf der RAG-Strategie

Der Erfolg von RAG hängt von zwei Dingen ab:

• wie Inhalte in Chunks aufgeteilt werden,
• wie die abgerufenen Inhalte gerankt werden.

Getestete Chunking-Experimente

Wir haben mehrere Strategien untersucht, da manuelles, menschlich gesteuertes Aufteilen langsam ist, sich bei Updates nur schwer warten lässt und keinen skalierbaren Ansatz darstellt.

Unsere Untersuchungen umfassten unter anderem:

• Satzfenster-Chunking,
• Semantisches Chunking (Split/Merge auf Basis von Embedding-Ähnlichkeit),
• Hybride Ansätze, die feste Fenster mit semantischem Zusammenführen kombinierten.

Verwendete Bibliotheken und Komponenten:

• TextChunker (Microsoft.SemanticKernel.Text)
• drittich.SemanticSlicer
• SemanticChunker.NET

Eigene Strategien, z. B.:

• SemanticDoubleParseMergeStrategy
• WindowChunkStrategy

WindowChunkStrategy (Grundidee):

• Ein Fenster aus drei Sätzen bilden
• Um einen Satz verschieben → nächstes Fenster
• Embeddings benachbarter Fenster vergleichen
• Fenster zusammenführen, wenn sie semantisch nah beieinander liegen

So blieb der inhaltliche Zusammenhang erhalten, ohne riesige Textblöcke zu erzeugen. Am Ende haben wir uns für SemanticSlicer entschieden.

Finaler Retrieval-Flow (der Teil, der alles verändert hat)

Unsere erste Implementierung setzte auf eine einfache Vektorsuche. Sie funktionierte – aber nicht so gut, wie wir es brauchten. Deshalb haben wir zwei zentrale Schritte ergänzt: Query-Enrichment und Re-Ranking.

Vereinfachter Ablauf: Der Nutzer stellt eine Frage im Chat (Beispiel: „Welche Expertise hat Ihr Unternehmen?“)

An diesem Punkt verbesserten sich die Antworten spürbar: präzisere Aussagen, weniger irrelevante Zitate und eine bessere Ausrichtung daran, wie Menschen tatsächlich Fragen stellen.

Implementierte Funktionen

Die folgenden Funktionen bilden den Kern des Systems und ermöglichen zuverlässige Aktionen, präzises Retrieval und eine nachvollziehbare Wissensverankerung im realen Produktionseinsatz.

Überwindung von Herausforderungen

Content-Rauschen und „falsche Inhalte einbetten“

Früh führte das Einbetten von Rohseiteninhalten dazu, dass der Assistent falsche Signale „lernte“. Lösung: sauberere Extraktion + Chunking, fokussiert auf sinnvolle Textblöcke.

Namen und mehrsprachige Randfälle

Einige Nutzerfragen waren nicht auf Englisch (z. B. „Who is the named person?“). Embedding-Modelle, die in den Fremdsprachen nicht stark sind, können fehlerhafte Ergebnisse liefern. So kann das System beispielsweise eine andere Person mit demselben Namen abrufen, nur weil die Vektorähnlichkeit nicht genau genug ist. Untersuchte Lösungsansätze:

• Hybrides sparse + dense Retrieval,
• Zusätzliche Signale zur Erkennung von Personennamen.

Evaluation und Testing

Das RAG-Retrieval selbst ist deterministisch für dieselben Eingaben, seine Nicht-Determinismus-Quellen liegen jedoch in der Generierung der Query-Embeddings und darin, wie das LLM den abgerufenen Kontext verarbeitet und formuliert. Erkenntnis: Der stabilste Testansatz besteht darin, Folgendes zu prüfen:

• Retrieval-Korrektheit: Wurden die richtigen Chunks abgerufen?
• Antwort-Grundlage: Nutzt die Antwort tatsächlich den bereitgestellten Kontext?

Aktualität und Indexierungs-Latenz

Neue Inhalte werden nicht sofort durchsuchbar – die Ingestion benötigt Zeit. Wir mussten ein Gleichgewicht finden zwischen:

• Infrastruktur-Last,
• Nutzererwartung, dass „der Chatbot wissen sollte, was wir heute veröffentlicht haben“,
• Indexierungsfrequenz, die vollständig konfigurierbar war (bis zu alle 15 Minuten).

Ergebnisse und Geschäftlicher Nutzen

Selbst zu diesem Zeitpunkt ist der Nutzen bereits deutlich sichtbar.

Was sich für die Nutzer geändert hat:

• Besucher können Fragen in natürlicher Sprache stellen, statt sich durch Menüs zu kämpfen
• Der Chatbot ermöglicht schnellere Auffindbarkeit von Blogs, Artikeln und Updates
• Das E-Mail-Tool sorgt für einen reibungsloseren Lead-Flow: Frage stellen → fehlende Details ergänzen → Nachricht senden, ganz ohne das klassische Formular

Was sich für das Unternehmen geändert hat:

• Bessere Nutzung von Inhalten: Wertvolle Seiten werden nicht mehr „vergraben“
• Skalierbarer Ansatz: Dieselbe Architektur kann über öffentliche Seiten hinaus erweitert werden
• Kosten- und Datenschutzkontrolle: Das System ruft nur ab, was benötigt wird, anstatt alles in externe Prompts zu schicken

Nächste Schritte

Dieses Projekt befindet sich weiterhin in der Entwicklung. Die nächsten Schritte konzentrieren sich auf Zuverlässigkeit und Skalierbarkeit:

• Automatisierte Evaluierung von Retrieval und fundierten Antworten.
• Verbesserte Mehrsprachigkeit, insbesondere bei Namen und kurzen Anfragen.
• Stärkeres hybrides Retrieval (sparse + dense), um „falsche Treffer“ in den Vektoren zu reduzieren.
• Abschluss der Infrastrukturkomponenten (KI-Server und RAG-Collection-Setup).
• Überprüfung der Multi-Site-Abdeckung (die US-Website könnte einen eigenen MCP-Server betreiben)

Summary

Dieses Projekt zeigt, wie eine produktionsreife RAG-Architektur einen KI-Chatbot von einer oberflächlichen Schnittstelle zu einer verlässlichen Wissenszugriffsschicht für eine wachsende Website verwandeln kann. Durch die Kombination von strukturierter Inhaltserfassung, semantischer Aufteilung, hybridem Retrieval und kontrollierter LLM-Orchestrierung haben wir ein System geschaffen, das präzise, fundierte Antworten auf Basis realer Inhalte liefert – und nicht auf Annahmen oder Halluzinationen.

Die Lösung verbessert die Auffindbarkeit von Inhalten für Nutzer und legt eine Grundlage, die auf interne Wissensdatenbanken, mehrsprachige Umgebungen und weitere Datenquellen ausgeweitet werden kann. Am wichtigsten ist: Sie zeigt, dass hochwertige KI-Assistenten nicht allein durch Prompts entstehen, sondern durch gezielte architektonische Entscheidungen bei Daten, Retrieval und Infrastruktur.