RAG-Ticket-Triage in der Medtech-Branche: 8-Wochen-Pilot mit pgvector

Warum Ticket-Triage in der Medtech-Branche fehleranfällig ist

Medtech-Firmen mit 51-200 Mitarbeitern in der Schweiz kämpfen mit einem spezifischen Problem: Die Back-Office-Prozesse für Ticket-Handling sind manuell, fehleranfällig und skalieren nicht. Ein Support-Mitarbeiter klassifiziert 500 Tickets/Monat, 15-20 % landen in der falschen Abteilung, die Durchlaufzeit beträgt 24 Stunden statt der Zielmarke von 4 Stunden. Die Folge: Verzögerte Lieferungen, unzufriedene Kunden, steigende Kosten. Ein RAG-basierter Assistent, der Tickets automatisch klassifiziert und routet, reduziert die Fehlerquote auf < 5 % und die Durchlaufzeit auf < 4 Stunden. Die Herausforderung: Die Implementierung muss in 8 Wochen abgeschlossen sein, die Daten dürfen die Schweiz nicht verlassen, und das System muss in die bestehende Ticket-Infrastruktur integrieren, ohne diese zu ersetzen.

Voraussetzungen für den 8-Wochen-Pilot

Bevor du mit der Implementierung beginnst, brauchst du folgende Voraussetzungen: Ein bestehendes Ticket-System mit REST-API (z. B. Zendesk, Freshdesk oder ein internes System), auf das du programmatisch zugreifen kannst. Eine Datenbank mit pgvector-Erweiterung (PostgreSQL 15+), die auf eigener Hardware oder in einer Schweizer Cloud-Instanz läuft. Ein klar definierter Scope: Welche Ticket-Kategorien werden klassifiziert? Welche Routing-Regeln gelten? Wer ist der Human-in-the-Loop-Approver? Eine Datenbasis: Mindestens 500 historische Tickets mit Labels, um die Retrieval-Qualität zu testen. Ein Projektplan mit 8 Wochen Laufzeit und wöchentlichen Meilensteinen. Ohne diese Voraussetzungen verzögert sich der Pilot um 2-4 Wochen.

Die 7 Schritte zur Implementierung

1. Prozessaudit durchführen (Woche 1): Analysiere 500 historische Tickets aus den letzten 3 Monaten. Dokumentiere die aktuellen Routing-Regeln, die häufigsten Fehlklassifizierungen und die Durchlaufzeiten pro Kategorie. Erstelle eine Excel-Tabelle mit Spalten: Ticket-ID, Kategorie, Routing-Ziel, Durchlaufzeit, Fehler-Flag. Diese Tabelle wird deine Basis für die Erfolgsmessung. 2. Datenbasis vorbereiten (Woche 2): Extrahiere die Ticket-Texte und Labels aus dem Ticket-System über die REST-API. Bereinige die Daten: Entferne Duplikate, standardisiere die Kategorielabels. Speichere die bereinigten Daten in einer CSV-Datei. Diese Datei wird später für die Embeddings-Generierung verwendet. 3. pgvector-Setup (Woche 3): Installiere PostgreSQL 15+ mit der pgvector-Erweiterung. Erstelle eine Tabelle tickets mit Spalten: id, text, category, routing_target, embedding vector(1536). Generiere die Embeddings für die 500 historischen Tickets mit einem Open-Weight-Modell (z. B. Llama 3) auf eigener Hardware. Speichere die Embeddings in der pgvector-Spalte. 4. Retrieval-Pipeline bauen (Woche 4): Implementiere eine Python-Skript, das ein neues Ticket empfängt, das Embedding generiert und die 5 ähnlichsten historischen Tickets aus pgvector abruft. Verwende den Cosine-Score als Ähnlichkeitsmaß. Teste die Pipeline mit 50 neuen Tickets und vergleiche die Retrieval-Ergebnisse mit den manuellen Klassifizierungen. Ziel: > 80 % Übereinstimmung. 5. Human-in-the-Loop-Workflow einrichten (Woche 5): Integriere den RAG-Assistenten in das Ticket-System über Webhooks. Wenn ein neues Ticket eingeht, ruft das Webhook den RAG-Assistenten auf. Der Assistent klassifiziert das Ticket und schlägt ein Routing-Ziel vor. Ein Approver (Support-Lead) prüft den Vorschlag in einem einfachen Web-Interface und bestätigt oder korrigiert die Entscheidung. Nur nach Bestätigung wird das Ticket geroutet. 6. Pilotbetrieb starten (Woche 6-7): Aktiviere den RAG-Assistenten für 10 % der eingehenden Tickets. Die restlichen 90 % werden weiterhin manuell bearbeitet. Erhebe täglich die Metriken: Durchlaufzeit, Fehlklassifizierungsrate, manuelle Nachbearbeitungsquote. Dokumentiere jede Abweichung von den Zielwerten. 7. Auswertung und Übergabe (Woche 8): Vergleiche die Pilot-Metriken mit den Basiswerten aus Woche 1. Erstelle einen Bericht mit den Ergebnissen, den Lessons Learned und einem Rollout-Plan für die restlichen 90 % der Tickets. Übergabe an das Operations-Team: Dokumentation, Code, Betriebsanleitung.

Häufige Stolperfallen und wie du sie erkennst

• Embeddings-Qualität zu niedrig: Wenn die Retrieval-Ergebnisse < 80 % Übereinstimmung mit den manuellen Klassifizierungen zeigen, ist das Embedding-Modell nicht geeignet. Lösung: Teste ein anderes Modell (z. B. Mistral statt Llama 3) oder erweitere die Datenbasis auf 1 000+ Tickets. – API-Latenz zu hoch: Wenn die REST-API des Ticket-Systems > 500 ms Antwortzeit benötigt, verzögert sich der gesamte Workflow. Lösung: Cache die Ticket-Daten lokal oder optimiere die API-Abfragen. – Human-in-the-Loop-Approver überlastet: Wenn der Approver > 20 Vorschläge/Tag prüfen muss, steigt die Fehlerquote. Lösung: Erhöhe den Schwellenwert für die automatische Routing-Entscheidung oder verteile die Approvals auf mehrere Personen. – Datenlecks über Webhooks: Wenn die Webhook-Endpunkte nicht authentifiziert sind, können unbefugte Parteien Tickets manipulieren. Lösung: Verwende API-Keys mit Scope-Beschränkung und HTTPS-Verschlüsselung. – Scope-Creep: Wenn während des Piloten neue Anforderungen auftauchen (z. B. “Könntet ihr auch die E-Mail-Antworten generieren?”), verzögert sich der Zeitplan. Lösung: Halte dich strikt an den definierten Scope. Neue Anforderungen gehen in einen separaten Backlog für Phase 2.

Nächste Schritte nach dem Pilot

Der 8-Wochen-Pilot ist abgeschlossen. Die nächsten logischen Schritte: 1. Rollout auf 100 % der Tickets: Erhöhe den Anteil der automatisch gerouteten Tickets von 10 % auf 100 %. Beobachte die Metriken für 2 Wochen. Wenn die Fehlklassifizierungsrate < 5 % bleibt, ist der Rollout erfolgreich. 2. Erweiterung auf weitere Abteilungen: Wenn der Pilot in der Supply-Chain-Abteilung funktioniert, übertrage das Modell auf die Customer-Support-Abteilung. Die Architektur bleibt gleich, nur die Datenbasis und die Routing-Regeln ändern sich. 3. Integration in weitere Systeme: Verbinde den RAG-Assistenten mit dem ERP-System, um Lieferstatus automatisch abzufragen. Verwende dieselbe pgvector-Infrastruktur, erweitere nur die Datenquellen. 4. Kontinuierliche Verbesserung: Führe monatlich eine Evaluation der Retrieval-Qualität durch. Aktualisiere die Embeddings, wenn neue Ticket-Kategorien hinzukommen. Dokumentiere jede Änderung in einem Changelog. Der Pilot ist der Anfang, nicht das Ende. Die eigentliche Wertschöpfung entsteht, wenn das System in den Regelbetrieb übergeht und kontinuierlich optimiert wird.