RAG-Pilot für den Support: LangGraph mit Notion in 4 Wochen

Das Problem: Verstreutes Wissen im Support

Ein Logistikunternehmen mit 80 Mitarbeitern in Wien bearbeitet täglich 150 Support-Tickets. Davon sind 40 Prozent Routineanfragen: Sendungsverfolgung, Schadensmeldungen, Zollabfertigung. Die Support-Mitarbeiter verbringen 60 Prozent ihrer Zeit mit der Suche in Confluence und Notion, statt die Tickets zu lösen. Die Durchlaufzeit pro Ticket liegt bei 45 Minuten, die Fehlerquote bei 12 Prozent. Das Problem ist nicht mangelnde Kompetenz, sondern fehlende Kontextverfügbarkeit. Die relevanten Informationen sind in 3.200 Confluence-Seiten und 800 Notion-Dokumenten verstreut, ohne einheitliche Struktur. Ein RAG-System kann diese Lücke schließen, indem es die Wissensbasis in einen durchsuchbaren Vektorindex überführt und die Antwortgenerierung an die LLM-API delegiert. Der Pilot zielt darauf ab, die Durchlaufzeit auf 25 Minuten zu senken und die Fehlerquote auf unter 5 Prozent zu reduzieren.

Architektur: LangGraph mit Notion-Anbindung

Die Architektur besteht aus vier Komponenten: (1) einem Ingest-Pipeline, die über die Confluence und Notion REST-APIs Inhalte abruft, in Chunks von 512 Token aufteilt und mit dem Embedding-Modell text-embedding-3-small in Vektoren konvertiert; (2) einem Vektordatenbank-Backend (Qdrant oder Weaviate) mit HNSW-Indexierung für sub-100-ms-Suche; (3) einem LangGraph-Workflow, der die Anfrage klassifiziert, die Top-5-Ergebnisse abruft und ein Prompt mit Kontext an die LLM-API sendet; (4) einem Human-in-the-Loop-Interventionspunkt, bei dem der Support-Mitarbeiter den Vorschlag vor der Kundenantwort freigibt. Die API-Endpunkte sind über FastAPI exponiert, mit Rate-Limiting auf 10 Requests pro Minute pro Benutzer. Die Latenz liegt bei 1.200 ms für die Gesamtantwort, davon 800 ms für die LLM-Generierung.

Trade-offs: Chunking, Embeddings und Latenz

Die Chunk-Größe ist der kritischste Parameter. Zu kleine Chunks (unter 256 Token) verlieren Kontext, zu große (über 1.024 Token) reduzieren die Suchpräzision. Für Logistik-Dokumentation mit vielen Tabellen und Aufzählungen empfiehlt sich eine semantische Chunking-Strategie, die Absätze und Tabellen als eigene Einheiten behandelt. Die Embedding-Modell-Wahl ist ein Trade-off zwischen Kosten und Qualität: text-embedding-3-small kostet 0,02 USD pro 1.000 Token und reicht für die meisten Fälle. Wenn die Genauigkeit unter 80 Prozent liegt, lohnt sich der Wechsel zu text-embedding-3-large (0,13 USD pro 1.000 Token). Die Vektordatenbank-Wahl hängt von der Skalierbarkeit ab: Qdrant ist für unter 100.000 Vektoren ausreichend, Weaviate bietet bessere Filterung für strukturierte Metadaten.

Empfehlung: 4-Wochen-Plan für den Piloten

Für ein 51-200-Mitarbeiter-Unternehmen in der Logistik mit Confluence und Notion als Wissensbasis empfiehlt sich folgender 4-Wochen-Plan: Woche 1: Prozessanalyse und Auswahl der 20 häufigsten Ticket-Typen, Einrichtung des Vektordatenbank-Backends, Implementierung der Ingest-Pipeline. Woche 2: LangGraph-Workflow mit Human-in-the-Loop, Integration der LLM-API, Latenz-Optimierung. Woche 3: Pilotbetrieb mit 5 Support-Mitarbeitern, Messung der Antwortgenauigkeit und Latenz, Iteration an den Prompts. Woche 4: Auswertung der Metriken, Dokumentation, Übergabe an das Support-Team. Die wichtigsten Erfolgskriterien sind: Antwortgenauigkeit über 85 Prozent, P95-Latenz unter 2 Sekunden, Mitarbeiter-Zufriedenheit über 4/5. Wenn diese Kriterien nicht erfüllt sind, sollte der Pilot nicht in den Produktivbetrieb überführt werden.

Stolperfallen: Was den Piloten scheitern lässt

Die häufigsten Fehler bei RAG-Piloten in der Logistik sind: (1) unstrukturierte Quelldaten – Confluence-Seiten mit veralteten Informationen oder widersprüchlichen Anweisungen; (2) fehlende Metadaten – ohne Tags wie ‘Zoll’, ‘Schaden’, ‘Versicherung’ kann die Suche nicht filtern; (3) zu aggressive Automatisierung – wenn die KI ohne menschliche Freigabe antwortet, steigt das Risiko von Fehlinformationen; (4) mangelnde Messung – ohne Baseline vor dem Piloten kann man den Erfolg nicht belegen. Die Lösung ist eine strenge Scope-Definition: Nur die 20 häufigsten Ticket-Typen werden im Piloten abgedeckt, alle anderen gehen weiterhin manuell. Die menschliche Freigabe bleibt für alle Antworten, die Kunden betreffen.

Kommentare

Leave a Reply

Your email address will not be published. Required fields are marked *