Das Problem

Warum jeder wachsende Online-Shop an dieselbe Grenze stosst

Vorverkaufs-Support ist der versteckte Engpass im Online-Handel. Kunden stellen immer wieder dieselben Fragen: Produktabmessungen, Stilkompatibilitat, Montageanleitungen, Preise fur individuelle Wandgroßen. Jede einzelne Antwort ist einfach. Das Volumen ist es nicht.

Mehr Support-Mitarbeiter einzustellen skaliert die Kosten linear mit dem Traffic. Ein generischer Chatbot gibt generische Antworten und verliert das Vertrauen, sobald er einen Preis falsch angibt. Die echte Losung benotigt etwas, das sowohl semantische Fragen ("etwas Ruhiges und Modernes fur ein Schlafzimmer") als auch harte Faktenabfragen ("Was ist der genaue Preis von SKU 000389 mit 10% Verschnittmarge") bewaltigen kann — ohne beides zu verwechseln.

Das ist das Problem, das Hybrid RAG lost. Und das ist die Architektur, die wir fur da-vinchi.pl gebaut haben.

Die zentrale Architekturentscheidung: zwei Wahrheitsschichten

Ein einfaches LLM uber Dokumenten halluziniert Preise. Ein reiner SQL-Bot verfehlt semantische Absichten. Hybrid RAG teilt Wissen in zwei Schichten: SQL fur harte Fakten (Preis, SKU, Lager), pgvector fur weiches Wissen (Stil, Raumguides, FAQ). Der Agent fragt beide ab — und erfindet nie eine Zahl, die er nicht aus der Datenbank abgerufen hat.

Was der Agent automatisch erledigt

Das gesamte Vorverkaufsgesprach — ohne Mitarbeiter

"Zeig mir Tapeten fur ein Kinderzimmer mit Blumen"
Semantische Suche uber 1.200 SKUs — sofortige Auswahl mit exakten Preisen, kein manuelles Filtern
"Preis fur SKU 000389, gibt es ein Set?"
Direkter Katalog-Lookup — prazise Spezifikationen aus SQL, kein Schatzen, keine Fehler
"Wie hange ich sie auf? Welchen Leim brauche ich?"
Wissensbasis-Antworten aus Firmenunterlagen — Montageanleitungen sofort bereitgestellt
"Meine Wand ist 3,2m x 2,6m, was kostet das?"
Preisberechnung mit Verschnittmarge — exakter Gesamtpreis, kein Hin-und-Her mit dem Support
Hybrid RAG Architektur

Wie das Zwei-Schichten-Wissenssystem funktioniert

Die grundlegende Architekturentscheidung ist, harte Fakten von weichem Wissen zu trennen und sie uber verschiedene Pfade abzurufen.

Nutzeranfrage: "Etwas Ruhiges fur ein Schlafzimmer, ca. 120 EUR"
  ↓
LangGraph ReAct Agent — entscheidet, welche Tools er aufruft
  ↓                                              ↓
pgvector (Supabase)                   PostgreSQL (Supabase)
semantisch: "ruhiger Schlafzimmerstil"    SQL: Preis BETWEEN 100 AND 140
→ Stilguides, Raumtreffer               → SKU, exakter Preis, Lagerbestand
  ↓                                              ↓
Agent fuhrt Ergebnisse zusammen — Produktauswahl mit echten Preisen → Antwort

SQL-Schicht (harte Fakten): SKU, Endpreis, Lagerbestand, Farben, Raumtags. Der Agent konstruiert keine URL oder keinen Preis aus dem Gedachtnis. Jede dem Kunden gezeigte Zahl stammt aus einer Live-Datenbankabfrage.

pgvector-Schicht (weiches Wissen): 142 semantische Chunks uber 5 Typen — FAQ, technische Spezifikationen, Stilguides, Raumempfehlungen, Verkaufsskripte. Anfragen wie "etwas fur ein skandinavisches Interieur" triggern Vektor-Ahnlichkeitssuche, liefern den richtigen Stilkontext und fuhren dann zu SQL-Filtern.

LangGraph Agent — 5 Tools

Was jedes Tool tut und warum es existiert

search_knowledge
Semantischer Abruf aus pgvector — Stil-Mapping, Raumguides, FAQ, Montage. Bewaltigt die "weichen" Fragen, die keine einzelne korrekte SQL-Antwort haben.
search_catalog
Facettierte SQL-Suche mit progressiver Fallback-Logik: lockert Filter schrittweise, wenn die anfanglichen Ergebnisse zu eng sind. Verhindert "keine Ergebnisse"-Sackgassen.
get_product_details
Direkter Lookup nach SKU, Produkt-ID oder URL-Slug. Das primare Anti-Halluzinations-Tool — aufgerufen, wann immer der Agent einen Preis oder eine Spezifikation bestatigen muss, bevor er sie prasentiert.
compare_styles
Ruft zwei Produktstile ab und vergleicht sie fur den spezifischen Anwendungsfall eines Kunden nebeneinander. Bewaltigt "Was ist besser fur X?"-Fragen ohne generische Antworten.
calculate_wall_price
Berechnet Gesamtkosten nach Wandabmessungen einschließlich Standard-Verschnittmarge. Ersetzt das haufigste Hin-und-Her zwischen Kunden und Support-Mitarbeitern.
ETL-Pipelines

Wie die Wissensbasis aufgebaut wird

Zwei unabhangige Pipelines speisen das System:

Katalog-Import: CSV aus dem Shop-Backend → Deduplizierung → Out-of-Stock-Filterung → 355 aktive SKUs in PostgreSQL. Wiederholbar ohne Duplikate.

Wissensbasis-Aufbau: Strukturierte Markdown-Dokumente → 142 Chunks uber 5 semantische Typen. Die Chunking-Strategie variiert je nach Dokument: FAQ wird pro Frage aufgeteilt, Raumguides tragen strukturierte Metadaten, Stil-Mappings enthalten Farb- und Kategoriefelder.

Beide Pipelines laufen unabhangig und konnen erneut ausgefuhrt werden, wenn sich Produktkatalog oder Richtlinien andern.

Kennzahlen

Was ausgeliefert wurde

  • 355 aktive SKUs in strukturiertem SQL
  • 142 semantische Wissens-Chunks in pgvector
  • 5 Agent-Tools fur den gesamten Vorverkaufsfluss
  • Null halluzinierte Preise im Produktionstesting
  • Vollstandiges Web-Chat-Widget in den Shop eingebettet
  • LangSmith-Tracing fur jeden Agent-Lauf
  • pytest-Kaufer-Szenario-Integrationstests in CI
FAQ

Haufige Fragen zur KI-Kundenservice-Automatisierung

Wie verhindert ein Kundenservice KI Chatbot Preishalluzinationen?
Der Schlussel ist die Trennung in zwei Wissensschichten. Harte Fakten — SKU, exakter Preis, Lagerbestand — liegen in SQL und werden direkt abgefragt. Der Agent konstruiert keinen Preis aus dem Gedachtnis. Weiches Wissen — Stilguides, Raumempfehlungen — liegt im Vektorspeicher fur semantische Suche. Der Agent prasentiert nur Preise aus SQL, was Halluzinationen strukturell unmoglich macht.
Welche Anfragen kann ein KI-Verkaufsassistent ohne menschliche Eingriffe bearbeiten?
Ein gut aufgebauter RAG-Agent deckt das gesamte Vorverkaufsgesprach ab: semantische Produktsuche, exakte SKU-Abfragen mit Preis und Lager, Montage- und Anwendungsfragen, Ruckgabebedingungen und FAQ sowie Preisberechnungen nach Wandabmessungen. Nachkauf-Anfragen (Bestellstatus, Versand) benotigen weiterhin einen Menschen oder eine separate Integration.
Was ist Hybrid RAG und warum ist es fur E-Commerce besser?
Hybrid RAG kombiniert Vektor-Ahnlichkeitssuche (fur semantische Anfragen wie "etwas Minimalistisches fur ein Kinderzimmer") mit strukturiertem SQL-Abruf (fur harte Fakten wie Preis, SKU, Abmessungen). Reines Vector Search halluziniert Preise. Reines SQL verfehlt semantische Absichten. Der hybride Ansatz bewaltigt beides korrekt — und ist die richtige Architektur fur jeden Produktkatalog mit faktischen und beschreibenden Attributen.
Tech Stack

Eingesetzte Technologien

Python LangGraph FastAPI Supabase pgvector (HNSW) Google Gemini Sentence-Transformers LangSmith Docker Railway GitHub Actions pytest VS Code + Claude Code
Mochten Sie den Kundenservice fur Ihren Online-Shop automatisieren?

Ich entwickle RAG-basierte Kundenservice KI fur E-Commerce: Produktkatalog-Integration, semantische Suche, Preisberechnungen, FAQ-Handling. Funktioniert mit jedem Produktkatalog — Tapeten, Mobel, Elektronik, B2B-Zubehör. Standort Munchen, Kunden in ganz Europa.

← Zuruck zu den Artikeln