KI Chatbot fur E-Commerce: Hybrid RAG System ohne Preishalluzinationen

Der Kunde — ein polnischer Online-Shop fur Tapeten und Dekor — hatte einen 57-MB-PDF-Katalog mit 1.200+ Produkten. Der erste Gedanke: alles vektorisieren, LLM Fragen beantworten lassen. Das ist der falsche Ansatz fur E-Commerce, und zwar aus folgendem Grund.

Wenn ein Kunde fragt "Was kostet Artikel SKU-4821?" muss die Antwort exakt sein. Eine semantische Vektorsuche liefert die ahnlichsten Chunks — aber Ahnlichkeit garantiert keine Genauigkeit. Preise konnen halluzinieren. Abmessungen werden zwischen Produkten verwechselt. Lagerbestande geraten bei Varianten durcheinander.

Der originale Katalog war zudem 57 MB rohes PDF — direkt an Gemini File Search hochgeladen, traf das den Hot-Cache-Preistier (~45 $/Monat) und verursachte uber 8 Sekunden Antwortlatenz. Fur ein Chat-Widget unbrauchbar.

Die Grundursache

E-Commerce-Daten haben zwei grundlegend verschiedene Informationstypen, die unterschiedliche Abrufstrategien erfordern:

• Harte Fakten — Preis, SKU, Lagerbestand, Abmessungen. Muss exakt sein. Halluzination hier = Geschaftsverlust.
• Weiches Wissen — Stilbeschreibungen, Anwendungsfalle, Empfehlungen, FAQ. Kann angenahert sein. Semantischer Abruf funktioniert gut.

Eine einzige Abrufstrategie kann nicht beides bedienen. Das ist die Kernerkenntnis hinter Hybrid RAG.

Die Losung teilt den Katalog in zwei Schichten auf, jede fur die Anfragen geeignet, fur die sie konzipiert ist:

Schicht 1 — SQL (Supabase PostgreSQL)

Alle deterministischen Fakten liegen in strukturierten Tabellen: Produkt-ID, Name, Preis, Lagerbestand, Abmessungen, Kategorie, Lieferant. Wenn der Agent einen Preis oder Verfugbarkeitsstatus benotigt, fuhrt er eine SQL-Abfrage uber das get_product_detail-Tool aus. Die Antwort ist immer exakt — kein Embedding-Abstand, keine Naherung.

Schicht 2 — pgvector (semantische Suche)

Produktbeschreibungen, Stilhinweise, Anwendungsfalltext und FAQ-Inhalte werden gechunkt, mit Sentence-Transformers eingebettet und in pgvector gespeichert. Wenn ein Nutzer fragt "Was eignet sich gut fur ein kleines Bad?" oder "Etwas Modernes fur ein Kinderzimmer?", fuhrt der Agent eine Ahnlichkeitssuche durch und ruft den relevantesten Stilkontext ab.

Die ETL-Pipeline

Bevor eine Anfrage korrekt beantwortet werden kann, mussen die Daten sauber sein. Ich habe eine ETL-Pipeline gebaut, die: strukturierte Felder aus dem rohen PDF extrahiert, Produktduplikate bereinigt, vor dem Massen-Embedding Contract Tests fur jede Kategorie durchfuhrt (Trockenlauf mit einem einzelnen Element zur Verifikation der Prompt-Genauigkeit) und in beide Supabase-Tabellen upserted. Das 57-MB-PDF wurde zu einer sauberen 5-MB-Wissensbasis.

Der Agent ist uber einen FastAPI /chat-Endpunkt zuganglich. Das Frontend ist ein leichtgewichtiges Web-Chat-Widget, das auf den Produktseiten des Shops eingebettet ist. Telegram wurde nur fur internes Debugging wahrend der Entwicklung genutzt — nicht in der produktiven, kundenseitigen Schnittstelle.

Deployment erfolgt auf Railway mit Docker — Zero-Config-Autoskalierung, kein Server-Management. Die Supabase-Instanz handhabt sowohl die PostgreSQL-Daten als auch die pgvector-Extension. Keine separate Vektordatenbank-Infrastruktur notwendig.

Observability von Anfang an

LangSmith ist vor der ersten Produktionsanfrage eingebunden. Jeder Agent-Lauf wird protokolliert: welche Tools wurden aufgerufen, in welcher Reihenfolge, wie viele Token wurden verbraucht, wo hat der Agent gezogert oder wiederholt. Das ist nicht optional — ohne Observability ist das Debuggen eines fehlverhaltenden Agents in der Produktion Raterei.

Qualitassicherung

Kaufer-Szenario-Integrationstests laufen gegen den Live-Agent: 20+ Testanfragen fur Preisfragen, Lagerpruungen, Stilempfehlungen und Randfalle (abgekundete Produkte, nicht vorratige Varianten). Diese Tests laufen in CI vor jedem Deployment. Der Agent kann mit einem fehlgeschlagenen Kaufer-Szenario nicht in die Produktion gehen.

Nach Datentyp aufteilen, nicht nach Abrufmethode

Der grosste Fehler bei RAG-Implementierungen ist, alles zu vektorisieren. Die richtige Frage lautet: "Benotigt dieses Datenelement exakten oder angenaherten Abruf?" Preise und SKUs brauchen Exaktheit. Beschreibungen und Empfehlungen brauchen Annaherung. Bauen Sie Ihre Abrufschicht entsprechend auf.

ETL-Qualitat bestimmt Agent-Qualitat

Garbage in, Garbage out ist das haufigste RAG-Versagen. Ich habe mehr Zeit in die ETL-Pipeline investiert — Deduplizierung, Feldnormalisierung, Contract Tests — als in den Agent selbst. Eine gut strukturierte Wissensbasis macht den Agent ohne Prompt-Engineering dramatisch genauer.

ReAct statt Chains fur mehrstufige Anfragen

Chains funktionieren fur einstufigen Abruf. Echte Nutzeranfragen sind mehrstufig. Ein ReAct Agent mit gut gestalteten Tools handhabt Gesprachskontext, Folgefragen und zusammengesetzte Anfragen, ohne jedes Szenario speziell zu codieren.

Observability ist in der Produktion nicht optional

LangSmith von Tag 1 — nicht nach dem ersten Produktionsvorfall nachgerustet. Sie mussen sehen, was der Agent tut, bevor Nutzer Ihnen sagen, dass etwas falsch lauft.

Diese Architektur eignet sich fur jeden E-Commerce- oder B2B-Betrieb in Deutschland, der hat:

• 100+ Produkte mit strukturierten Attributen (Preis, Kategorie, Spezifikationen)
• Kunden, die vor dem Kauf Fragen stellen — nicht nur browsen und klicken
• Einen Katalog, der sich regelmasig andert (saisonal, Lagerupdates)
• Ein Support-Team, das Zeit mit wiederkehrenden Produktfragen verbringt

Die Integration ist ein Chat-Widget auf der bestehenden Website — kein vollstandiger Neuaufbau notwendig. Der Agent verbindet sich mit Ihrer Produktdatenbank und bestehenden Infrastruktur. Entwicklungszeit fur einen Standard-E-Commerce-Aufbau: 3-6 Wochen.

Branchen, die in Deutschland gut funktionieren: Mobel- und Einrichtungshandler, Baustofflieferanten, B2B-Teile- und Komponentenhandler, Tapeten- und Bodenbelagspezialisten, Lebensmittel- und Getranke-Groshandel.