RAG für den Kundensupport: Weniger Tickets mit einer dokumentenbasierten Answer Engine
Jedes B2B-SaaS-Team, mit dem wir über KI-Features sprechen, beginnt mit derselben Anfrage: ein Assistent, der Kundenfragen aus der Produktdokumentation beantwortet, bevor jemand ein Ticket öffnet. Der Instinkt ist richtig. RAG für Kundensupport ist das dankbarste erste Retrieval-Projekt, das du wählen kannst. Das Quellmaterial existiert bereits, falsche Antworten fallen schnell auf, und der Business Case hat eine Zahl: Tickets, die nie eingereicht wurden. Dieser Beitrag beschreibt die Architektur, die wir für Kunden bauen, von der Ingestion-Pipeline über die Speicherung in pgvector und hybrides Retrieval bis zum Confidence-Schwellenwert, der entscheidet, wann die Engine schweigen und an einen Menschen übergeben sollte.
Was RAG für Kundensupport richtig machen muss
Eine Support-Answer-Engine hat einen Job. Zu einer Kundenfrage findet sie die Passagen in deiner Dokumentation und deinen gelösten Tickets, die sie beantworten, und generiert daraus eine Antwort, die in diesen Passagen verankert ist, mit Links zurück zu den Quellen. Die Verankerung ist der Punkt. Ein blankes LLM beantwortet bereitwillig Fragen zu Features, die du gar nicht hast, in einem selbstsicheren Ton, den deine Kunden glauben werden. Eine verankerte Engine kann nur sagen, was deine Dokumente sagen, und wenn die Dokumente nichts Brauchbares hergeben, sollte sie das zugeben und stattdessen ein Ticket anlegen.
Dieses zweite Verhalten trennt nützliche Deployments von peinlichen. Ein großer Teil echter Supportfragen ist kontospezifisch. "Warum wurde ich doppelt belastet" hat keine Antwort in deinen Docs, und kein Retrieval-Trick ändert das. Entwirf die Übergabe an einen menschlichen Agenten am ersten Tag, statt sie später anzuschrauben.
Die Ingestion-Pipeline
Alles Nachgelagerte hängt davon ab, was du hineingibst, und Support-Inhalte sind unordentlicher, als jede Demo suggeriert. In der Praxis ingestierst du aus drei Quellen: Markdown-Dokumentation in einem Repo, Wiki-Exporte aus einem Tool wie Notion und gelöste Konversationen aus einem Helpdesk wie Intercom.
Die Dokumentation ist der einfache Teil. Teile sie entlang der Überschriftsgrenzen, behalte den Überschriftenpfad (Billing, dann Invoices, dann Credit Notes) als Metadaten an jedem Chunk und speichere die Quell-URL, damit Antworten zurückverlinken können. Zur Größenwahl sind wir in unserem Beitrag über Chunking-Strategien in die Tiefe gegangen; die Kurzfassung: strukturbewusste Chunks von grob 200 bis 500 Tokens, mit dem Überschriftenpfad vor dem Embedding an den Text gehängt, schlagen bei Support-Inhalten Fenster fester Größe.
Helpdesk-Exporte brauchen echte Bereinigung. Eine gelöste Intercom-Konversation enthält Begrüßungen, Smalltalk, Screenshots, drei Runden "hat das bei dir funktioniert" und irgendwo in der Mitte die eigentliche Lösung. Indexierst du das rohe Transkript, indexierst du Rauschen. Was stattdessen funktioniert: Schicke jede gelöste Konversation zur Ingestion-Zeit einmal durch ein LLM, extrahiere ein sauberes Frage-Antwort-Paar und indexiere dieses Paar. Die Kosten liegen bei einem Bruchteil eines Cents pro Ticket, und der Gewinn ist groß, denn vergangene Tickets fangen die Formulierungen ein, die Kunden tatsächlich verwenden. Dokumentation tut das selten.
Hänge Metadaten an jeden Chunk: Quelltyp, Produktversion, Sprache und einen Zeitstempel der letzten Aktualisierung. Du wirst nach allen vieren filtern. Ein Kunde auf Version 2 deines Produkts sollte nie eine Antwort erhalten, die nur für Version 3 gilt, und ein deutschsprachiger Kunde sollte keine englischen Passagen in einer deutschen Antwort vorfinden.
Speicherung und Retrieval: pgvector plus BM25
Du brauchst dafür keine dedizierte Vektordatenbank. Ein Support-Korpus ist nach den Maßstäben der Vektorsuche klein, einige Zehntausend Chunks bei den meisten Produkten. Postgres mit pgvector bewältigt das bequem und hält die Vektoren in derselben Datenbank wie die Metadaten, sodass ein Versionsfilter eine WHERE-Klausel ist statt eines zweiten Systems, das betrieben werden will. Das vollständige Argument steht in unserem Blueprint für produktionsreifes RAG, und wenn dein Team genau bei so einer Tooling-Entscheidung feststeckt, sind unsere Engagements zur Tech-Stack-Strategie für diesen Fall gedacht.
Bei den Embeddings ist text-embedding-3-small von OpenAI die Standardwahl: günstig und gut genug für Support-Inhalte. Wenn deine Compliance-Anforderungen verlangen, dass Kundentext in deiner eigenen Infrastruktur bleibt, funktioniert auch ein selbst gehostetes mehrsprachiges Embedding-Modell. Die Architektur ändert sich dadurch nicht.
Vektorähnlichkeit allein wird dich allerdings enttäuschen. Support-Anfragen sind voll von exakten Bezeichnern wie Fehlercodes und API-Endpoint-Namen, und Embeddings sind schwach im exakten String-Matching, während die Volltextsuche von Postgres genau darin stark ist. Führe beides aus und verschmelze die Ergebnislisten per Reciprocal Rank Fusion. Das SQL für dieses hybride Setup haben wir in einem eigenen Beitrag beschrieben.
Die letzte Retrieval-Stufe ist das Reranking. Hol mit der hybriden Suche, die auf Recall getrimmt ist, 30 bis 50 Kandidaten, lass dann einen Cross-Encoder sie neu ordnen und behalte die besten fünf für den Prompt. Ein Cross-Encoder liest Frage und Passage zusammen und ist deshalb bei der Präzision deutlich besser als jede Retrieval-Methode für sich. Die zusätzliche Latenz liegt deutlich unter einer Sekunde, was sich ein Support-Widget leisten kann.
Der Confidence-Schwellenwert
Das ist die folgenreichste Designentscheidung im ganzen System, und die meisten Teams überspringen sie. Jedes Retrieval liefert Ähnlichkeits- und Reranker-Scores. Definiere einen Schwellenwert, unterhalb dessen die Engine gar nicht antwortet. Stattdessen sagt sie, dass sie nichts Verlässliches gefunden hat, öffnet ein Ticket und hängt die Frage plus die besten gefundenen Passagen an, damit der Agent mit Kontext startet statt mit einem leeren Bildschirm.
Kalibriere den Schwellenwert mit Daten, die du schon hast. Nimm ein paar hundert vergangene Kundenfragen, schick sie durch das Retrieval und lass jemanden beurteilen, ob die Top-Passagen sie wirklich beantworten. Trage die Scores beider Gruppen auf und wähle den Cutoff, der die Präzision hoch hält, und akzeptiere dabei, dass einige beantwortbare Fragen zu Menschen durchfallen. Dieser Tausch ist richtig. Eine selbstsichere falsche Antwort kostet Kundenvertrauen und produziert meist ein zweites, wütenderes Ticket. Eine Übergabe kostet dich nichts, denn dieses Ticket wäre ohnehin gekommen.
Die Symfony-Pipeline und das Next.js-Widget
Im Backend bauen wir die Ingestion-Seite als Symfony-Messenger-Pipeline. Ein Console-Command oder ein Webhook stellt eine Dokumentreferenz in die Queue, und Worker holen, bereinigen, chunken, embedden und upserten sie nach pgvector. Mach jeden Schritt idempotent, indem du auf einen Content-Hash keyst, damit ein erneuter Ingestion-Lauf nach einem Fehler oder einem Docs-Update sicher ist. Embedding-API-Aufrufe gehören in die Worker, hinter einen Rate Limiter, nie in einen Web-Request.
Der Query-Pfad ist bewusst dünn: ein Controller, der die Frage normalisiert, sie embeddet, die hybride Abfrage und den Reranker ausführt, den Schwellenwert anwendet und die generierte Antwort über Server-Sent Events streamt. Das Frontend ist ein kleines Next.js-Widget, das du ins Support-Portal einbettest. Es streamt die Antwort, während sie generiert wird, zeigt darunter die Quell-Links und bietet immer einen Ausweg an, der ein Ticket mit vorausgefüllter Frage anlegt. Sperr einen Kunden nie in eine Bot-Schleife.
Wenn du das in ein bestehendes Produkt einbaust, statt neu zu bauen, behandeln wir die Integrationsfragen in unserem Retrofit-Playbook.
Deflection ehrlich messen
"Beantwortete Fragen" ist eine Vanity-Metrik. Die Zahl, die zählt, ist die Deflection-Rate: der Anteil der Antwort-Sessions, in denen der Kunde eine verankerte Antwort gesehen und innerhalb eines Tages kein Ticket zum selben Thema eingereicht hat. Sie zu messen verlangt Disziplin, denn du musst Widget-Sessions mit Helpdesk-Daten verknüpfen, aber ohne sie kannst du nicht sagen, ob die Engine Agentenzeit spart oder Tickets nur verzögert.
Logge jede Session mit der Frage, den Retrieval-Scores, der Information, ob eine Antwort gezeigt wurde oder die Anfrage unter den Schwellenwert fiel, dem Daumen hoch oder runter des Kunden und jedem danach eingereichten Ticket. Zwei Nebenprodukte dieses Loggings verdienen ihren Platz. Die Fragen unterhalb des Schwellenwerts, wöchentlich geclustert, sind ein priorisiertes Backlog deiner Dokumentationslücken. Und die geloggten Retrieval-Ergebnisse werden zum Datensatz für einen richtigen Evaluation-Harness, den wir in unserem Beitrag über RAG-Evaluationsmetriken behandelt haben, damit du bei sinkender Antwortqualität erkennen kannst, ob das Retrieval oder die Generierung schuld ist.
Ticketvolumen ist eine Kostenzeile, und das ist eines der wenigen KI-Features, bei denen die Einsparung direkt messbar ist. Wenn du ein zweites Paar Augen auf deine Architektur willst, bevor du dich festlegst, oder ein Team, das die Engine Ende zu Ende gemeinsam mit deinem baut, liegt das mitten in unserer Arbeit im Bereich Custom Software Development. Schreib an hello@wolf-tech.io oder sieh dich auf wolf-tech.io um.