RAG-System mit pgvector für Lieferstatus-Updates im Fintech

Das Problem: Routineanfragen binden Senior-Staff

Ihr Unternehmen mit über 2000 Mitarbeitern im Fintech-Bereich in der Schweiz verarbeitet täglich Tausende von Kundenanfragen zu Sendungsstatus. Diese Anfragen binden Senior-Mitarbeiter, die eigentlich für strategische Aufgaben vorgesehen sind. Sie haben noch kein KI-System in Produktion, wollen aber ohne neue Einstellungen Ihre Operations skalieren. Die Herausforderung: Sie müssen ein System bauen, das auf Ihre eigenen Daten (ERP, Helpdesk) zugreift, die EU AI Act-Anforderungen erfüllt und in 2 Wochen einen messbaren Piloten liefert. Der Use Case ist klar definiert: Kundenanfragen zu Order- und Shipment-Status-Updates automatisieren, damit Ihre Senior-Staff sich auf komplexe Fälle konzentrieren kann.

Voraussetzungen: Was Sie vor dem Piloten brauchen

Bevor Sie mit dem Piloten starten, müssen folgende Voraussetzungen erfüllt sein:

• Datenzugriff: Sie haben API-Zugriff auf Ihr ERP-System (z. B. SAP, Oracle) und Ihr Helpdesk-System (z. B. Zendesk, Freshdesk). Die APIs müssen Webhooks oder REST-Endpunkte für Sendungsstatus-Änderungen unterstützen.
• Datenqualität: Sie haben eine Stichprobe von mindestens 500 historischen Anfragen mit den zugehörigen Sendungsnummern und Status-Antworten. Diese Daten dienen als Testset für den Piloten.
• Infrastruktur: Sie haben ein PostgreSQL-Cluster (Version 15 oder höher) mit dem pgvector-Modul installiert. Alternativ können Sie eine Managed-Postgres-Instanz (z. B. AWS RDS, Azure Database for PostgreSQL) mit pgvector-Erweiterung nutzen.
• Compliance-Review: Ihre Rechtsabteilung hat bestätigt, dass die Verarbeitung von Sendungsdaten (Kundenname, Adresse, Sendungsnummer) unter das revDSG fällt und keine sensiblen Daten (z. B. Gesundheitsdaten) enthalten sind.
• Team: Sie haben einen technischen Lead (Backend-Entwickler mit PostgreSQL-Erfahrung) und einen Produktmanager, der den Piloten-Scope definiert.

Schritte: Vom Audit zum produktiven Piloten

1. Prozess-Audit durchführen: Dokumentieren Sie den aktuellen Workflow für Status-Anfragen. Messen Sie: Wie viele Anfragen pro Tag? Wie lange dauert die Bearbeitung? Wie viele Fehler (falscher Status, falsche Sendung) treten auf? Diese Baseline ist der Maßstab für den Piloten-Erfolg.

2. pgvector-Infrastruktur aufsetzen: Installieren Sie pgvector auf Ihrem PostgreSQL-Cluster. Erstellen Sie eine Tabelle shipments mit den Feldern: id, tracking_number, status, last_updated, embedding (Vektor, Dimension 1024). Laden Sie die historischen Sendungsdaten in diese Tabelle.

3. Embeddings generieren: Verwenden Sie ein Open-Weight-Modell (z. B. BGE-M3 oder Llama-3-8B-Instruct) auf Ihrer eigenen Hardware, um Text-Embeddings für die Sendungsbeschreibungen zu erzeugen. Speichern Sie die Embeddings in der embedding-Spalte. Dies garantiert, dass keine Daten das Gebäude verlassen.

4. RAG-Pipeline entwickeln: Bauen Sie eine Python- oder Node.js-Anwendung, die: a) die Kundenanfrage empfängt, b) ein Embedding der Anfrage erzeugt, c) eine Vektorsuche in pgvector durchführt (SELECT * FROM shipments WHERE embedding <-> $1 ORDER BY embedding <-> $1 LIMIT 5), d) die Top-5-Ergebnisse an ein LLM (z. B. OpenAI GPT-4 oder Anthropic Claude) übergibt, um eine Antwort zu formulieren.

5. Webhook-Integration einrichten: Verbinden Sie Ihr ERP-System mit dem RAG-System über Webhooks. Jede Status-Änderung im ERP löst einen Webhook aus, der die shipments-Tabelle in Echtzeit aktualisiert. Dies stellt sicher, dass das RAG-System immer aktuelle Daten hat.

6. Human-in-the-Loop-UI bauen: Entwickeln Sie ein einfaches Web-Formular, in dem ein Mitarbeiter den KI-Entwurf prüfen und freigeben kann. Das Formular zeigt: Kundenanfrage, KI-Entwurf, Top-3-Suchergebnisse aus pgvector. Der Mitarbeiter klickt auf „Freigeben“ oder „Ablehnen“.

7. Piloten testen und messen: Führen Sie den Piloten mit 100 realen Anfragen durch. Messen Sie: Trefferquote (richtige Sendung identifiziert), Antwortqualität (korrekter Status), Bearbeitungszeit (vorher/nachher), Fehlerquote. Diese Metriken sind die Grundlage für die Entscheidung über den Rollout.

Häufige Stolperfallen und wie Sie sie erkennen

• Veraltete Daten: Wenn das ERP-System Status-Änderungen mit mehr als 5 Minuten Verzögerung meldet, liefert das RAG-System veraltete Informationen. Erkennung: Vergleichen Sie die last_updated-Zeitstempel in der shipments-Tabelle mit den tatsächlichen Status-Änderungen im ERP. Wenn die Differenz regelmäßig über 5 Minuten liegt, müssen Sie die Webhook-Integration optimieren oder auf Polling mit 1-Minuten-Intervall umstellen.

• Falsche Embeddings: Wenn die Embeddings-Modell nicht gut für deutsche Logistik-Begriffe trainiert ist, liefert die Vektorsuche irrelevante Ergebnisse. Erkennung: Prüfen Sie manuell 20 Suchanfragen und vergleichen Sie die Top-5-Ergebnisse mit den erwarteten Sendungen. Wenn weniger als 80 % der Top-5-Ergebnisse die richtige Sendung enthalten, müssen Sie ein anderes Embeddings-Modell testen oder die Datenqualität verbessern.

• Halluzinationen des LLM: Das LLM kann Informationen erfinden, die nicht in den pgvector-Ergebnissen enthalten sind. Erkennung: Führen Sie 50 Testanfragen durch und prüfen Sie, ob die Antwort ausschließlich auf den Top-5-Suchergebnissen basiert. Wenn das LLM Informationen erfindet, müssen Sie den Prompt anpassen (z. B. „Beantworte ausschließlich auf Basis der folgenden Informationen“) oder ein anderes LLM-Modell verwenden.

• Performance-Probleme: Wenn die Vektorsuche in pgvector länger als 500 ms dauert, ist die Benutzererfahrung schlecht. Erkennung: Messen Sie die Antwortzeit der Vektorsuche mit EXPLAIN ANALYZE. Wenn die Zeit über 500 ms liegt, müssen Sie einen Index auf der embedding-Spalte erstellen (z. B. CREATE INDEX ON shipments USING ivfflat (embedding) WITH (lists = 100)).

Fazit: Der nächste Schritt nach dem Piloten

Der 2-Wochen-Pilot ist abgeschlossen, wenn Sie die Baseline-Metriken (Bearbeitungszeit, Fehlerquote) gemessen haben und die Trefferquote über 90 % liegt. Der nächste Schritt ist die Entscheidung über den Rollout: Wenn der Pilot erfolgreich war, planen Sie die Erweiterung auf weitere Use Cases (z. B. Reklamationen, Zahlungsstatus). Wenn der Pilot nicht erfolgreich war, analysieren Sie die Ursachen (Datenqualität, Embeddings-Modell, LLM-Prompt) und wiederholen Sie den Piloten mit den Anpassungen. Wichtig: Der Pilot ist ein Fixed-Scope-Projekt. Jede Erweiterung (z. B. zusätzliche Sprachen, zusätzliche Datenquellen) ist ein neues Projekt mit neuem Scope und neuem Zeitplan. Planen Sie den Rollout als separates Projekt mit einem eigenen Budget und einem eigenen Team.