Wie wir eine produktionsreife RAG-Engine für einen Website-KI-Chatbot entwickelt haben

Faktengeprüft

(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.