DOTLUX löst moin.ai durch Ragistry ab

Ausgangslage: ein technisch differenziertes Produktportfolio trifft auf einen Decision-Tree-Bot

DOTLUX ist ein klassischer Fall, in dem ein generischer Chatbot-Ansatz an der Realität des Produktportfolios scheitert. Das Unternehmen aus Weißenburg in Bayern, 2010 von Peter Berschneider und Thorsten Müller gegründet, fertigt LED-Leuchten im Premium-Segment — von Lightshower-Hallenstrahlern für Industrie- und Logistikhallen über PANELbig-ugr-LED-Panels mit COLORselect und 4-pin-Plug für Human Centric Lighting bis zu EXIT-Notleuchten, SOFTEDGE-Aufbauleuchten und DALI-2-gesteuerten Pendelleuchten wie der AURA-Serie. Mehrere hundert SKUs, viele davon mit konfigurierbarer Lichtfarbe (COLORselect) und Wattage (POWERselect).

Die Fragen, die im Chat ankommen, lauten typischerweise nicht „welche Leuchte für mein Wohnzimmer?", sondern: „Ich brauche eine Pendelleuchte für ein Großraumbüro, 4000 K, DALI-2-steuerbar, mindestens 1200 mm Länge.", „Welche Hallenstrahler eignen sich als Ersatz für eine bestehende HQL-Beleuchtung?" oder „Wie konfiguriere ich die DALI-Adresse beim PANELbig-ugr?". Der Online-Shop ist registrierten Wiederverkäufern vorbehalten — entsprechend technisch ist auch das Niveau der Anfragen.

Vor der Ragistry-Implementierung war moin.ai (knowhere GmbH, Hamburg) im Einsatz. Eine Wettbewerbsanalyse von Qualimero (April 2025) beschreibt die Architektur so: „In practice, Moin.ai works with generative AI but heavily relies on a stored knowledge base: answers are generated from prepared data, and unknown queries are forwarded to human agents." Genau dieser Charakter — eine vorbereitete Wissensbasis statt einer tiefen Anbindung an strukturierte Produktdaten — wurde für DOTLUX zum Problem. Der Aufwand, mehrere hundert technische Datenblätter manuell in eine KB-Struktur zu überführen und jede Spec-Variante als Intent zu pflegen, skaliert nicht.

Verstärkt wurde der Handlungsdruck durch die Servicezeiten: Telefonisch ist DOTLUX werktags 07:00–16:00 Uhr erreichbar. In den verbleibenden 15 Stunden werktags und am gesamten Wochenende ist der Chatbot die einzige First-Level-Anlaufstelle — ein Setup, das nur trägt, wenn die Antwortqualität stimmt.

Warum RAG statt Wissensbasis: die architektonische Entscheidung

Der Wechsel auf Ragistry war keine Vendor-Frage, sondern eine Architekturentscheidung. Klassische intent-basierte Chatbots brauchen für jede Frage einen vorab gepflegten Pfad. RAG (Retrieval-Augmented Generation) kehrt das Prinzip um: Die Antwort wird zur Laufzeit auf Basis der tatsächlichen Produktdaten generiert. Eine Analyse von Aubergine Solutions formuliert es so: „Unlike rigid decision trees or pattern-matching algorithms, RAG systems engage in genuine problem-solving conversations while maintaining accuracy and compliance standards."

Konkret läuft eine Anfrage bei DOTLUX wie folgt:

1. Die User-Query kommt über das Widget ins FastAPI-Backend.
2. Das Backend embedded die Query mit Jina Embeddings.
3. Über die pgvector-Extension läuft eine Cosine-Similarity-Search (Operator <=>), gewrappt in einer SQL-Funktion match_documents, die als RPC vom Backend aufgerufen wird.
4. Die Top-N relevanten Produkt-Chunks gehen als Kontext in den LLM-Prompt.
5. Bei spezifischen Filteranfragen (Wattage-Range, Lichtfarbe, IP-Klasse) ruft das LLM über MCP die Backend-Funktion filter_products(...) auf statt rein semantisch zu suchen.
6. Die Antwort wird Token-für-Token via SSE-Stream an das Widget zurückgegeben.

Ein 2026 erschienener Enterprise-RAG-Guide (ment.tech, April 2026) berichtet, dass RAG-basierte Chatbots in domänenspezifischen Szenarien 95–98 % Genauigkeit erreichen können — eine Größenordnung, die für technisch-präzise B2B-Beratung relevant ist, wo eine falsche IP-Klasse oder Kelvin-Angabe in der Beratung zu einer falschen Bestellung führt.

Der LLM-Stack: Claude Sonnet, Haiku und ein OpenAI-Fallback

Die LLM-Schicht ist mehrstufig aufgebaut:

• Claude Sonnet (Anthropic) als primäres Modell für Beratungsdialoge. Pricing laut Anthropic: 3 USD pro Million Input-Tokens, 15 USD pro Million Output-Tokens, mit Einsparpotenzialen von bis zu 90 % über Prompt-Caching und 50 % über Batch-Processing.
• Claude Haiku für Klassifikations- und Routing-Tasks. Typische Agent-Interaktionen mit Tool-Calls liegen bei 400–800 Tokens, also Bruchteilen eines Cent pro Klassifikation.
• OpenAI o3 als Fallback-Provider bei Anthropic-API-Ausfall.

Die Fallback-Logik war nicht trivial: Anthropic und OpenAI unterscheiden sich in Tool-Calling-Schemata und Antwort-Latenzen genug, dass ein einfaches Drop-in-Replacement nicht reichte. Das Backend hat dafür eine eigene Provider-Abstraktion bekommen, die Tool-Definitionen, Message-Formate und Streaming-Events vereinheitlicht.

Das Widget: Sliding-Sheet statt Modal

Das Widget ist als JavaScript-Snippet auf dotlux.de und dotlux.com eingebettet und folgt einer Reihe bewusster UX-Entscheidungen:

• Sliding-Sheet von rechts statt klassischem Modal — die Seite bleibt sichtbar, der Kontext bleibt erhalten.
• Trigger-Button unten rechts mit rotierenden Themen-Texten (Produkte, Kundenservice, Garantie, Bedienungsanleitungen, Technische Details) und dynamischer Breitenanpassung.
• Shimmer-Animation auf dem Text als Loading-State, kein Drei-Punkte-Indicator.
• Cookie-basierte Session-Persistenz über 30 Tage, dadurch bleibt die Conversation-History über Browser-Sessions hinweg erhalten.
• Feedback-Button pro Antwort für laufendes Quality-Monitoring.
• Helles und dunkles Theme über Konfigurationsparameter.

Das Token-Streaming via SSE ist hier nicht Selbstzweck: Bei längeren Produktantworten mit Tabellen und Spec-Listen sieht der Nutzer schon nach unter einer Sekunde erste Inhalte — ein UX-Unterschied gegenüber Bots, die erst die vollständige Antwort holen und sie dann als Typewriter-Effekt animieren.

Datenpipeline: das eigentliche Schwergewicht im Projekt

Der mit Abstand aufwendigste Teil war nicht das LLM, sondern die Datenaufbereitung. Produktdaten kommen aus dem internen DOTLUX-Produktkatalog plus PDF-Datenblättern — und genau dort lag das Problem. Datenblätter unterschiedlicher Produktgenerationen variieren in Layout und Qualität, teils sind sie gescannt, teils enthalten sie eingebettete Spec-Tabellen. Für die strukturierte PDF-Extraktion wurden Tools wie MinerU evaluiert.

Der initiale Embedding-Aufwand für mehrere hundert SKUs lag deutlich über der ursprünglichen Planung. Primär wegen der Heterogenität der Datenquellen — eine saubere Normalisierung in ein einheitliches Schema vor dem Embedding war die Voraussetzung dafür, dass die spätere Cosine-Similarity-Suche überhaupt sinnvolle Treffer liefert.

Reibungspunkte im Roll-out

Mehrere Punkte mussten unterwegs gelöst werden:

• Migration der Conversation-History von moin.ai wurde bewusst nicht durchgeführt. Statt fragiler Schema-Mappings gab es einen sauberen Cut-off mit Kommunikation an Endkunden — eine pragmatische Entscheidung, die Engineering-Risiko gegen einmaligen Kommunikationsaufwand tauschte.
• DSGVO-Bewertung beim geplanten Sendungsverfolgungs-Modul: Eine Sendungsnummer ist potenziell auf eine identifizierbare Person rückführbar. Daher wurde eine gesonderte Datenschutz-Bewertung, ein Einwilligungs-Flow im Chat und eine Anpassung des Auftragsverarbeitungs-Vertrags vorgesehen. Das erste Roll-out wurde ohne dieses Modul ausgeliefert.
• Reseller-Edge-Case: B2B-Reseller stellen anders gelagerte Fragen als Endkunden („liefert AURA 4000K auch in 600 mm?" statt „welche Leuchte für mein Wohnzimmer?"). Embedding-Repräsentation und Retrieval-Prompts mussten dafür nachjustiert werden.
• Widget-Caching auf Test-Pages: In frühen Iterationen wurden Widget-Updates auf eingebetteten Test-Domains nicht zuverlässig invalidiert. Gelöst über Cache-Busting per Build-Hash.

Roadmap: was nach dem Initial-Roll-out kommt

Drei Module sind in Planung, aber außerhalb des Initial-Scopes:

1. Sendungsverfolgungs-Modul: User gibt Sendungsnummer im Chat ein, das Backend resolved gegen das Versand-System und gibt den Status zurück — mit vorgeschaltetem DSGVO-Workflow.
2. Geo-basierte Außendienst-Zuweisung: User gibt Standort an, das System routet auf den geografisch nächsten der 24 Außendienstler inklusive Verfügbarkeits-Check.
3. Mehrsprachiger Live-Betrieb in Deutsch, Englisch und Französisch parallel zur dreisprachigen Website.

Was sich konkret verändert hat

Eine quantitative Vorher-Nachher-Messung der Antwortqualität liegt zum Stand dieser Case Study nicht öffentlich vor — das Roll-out ist jung. Was strukturell anders ist, lässt sich aber benennen: An die Stelle einer manuell gepflegten Wissensbasis mit Decision-Tree-Logik ist eine RAG-Pipeline getreten, die direkt auf den tatsächlichen Produkt- und Datenblatt-Daten arbeitet. An die Stelle vorbereiteter Antworttexte ist ein generatives LLM mit strukturiertem Tool-Calling über MCP getreten. Und an die Stelle eines reinen Text-Chats ist ein gestreamtes, persistentes Widget getreten, das auch außerhalb der Telefonzeiten 07:00–16:00 als ernsthafte First-Level-Instanz funktioniert.