Zwei Ansätze für RAG-basierte Ticket-Triage im Schweizer E-Commerce
Der Vergleich betrifft zwei Ansätze zur Implementierung eines Retrieval-Augmented Generation (RAG)-Assistenten für Ticket-Triage und -Routing in einem Schweizer E-Commerce-Unternehmen mit 11-50 Mitarbeitern. Option A nutzt Open-Weight-Modelle (z. B. Llama 3 70B oder Mistral 8x7B) auf eigener Hardware oder in einem Schweizer Rechenzentrum. Option B nutzt kommerzielle Cloud-APIs (OpenAI GPT-4o, Anthropic Claude 3.5 Sonnet) mit Datenverarbeitung in der EU. Beide Ansätze nutzen LangChain und LangGraph als Orchestrierungsframework und integrieren sich in Slack oder Microsoft Teams. Der Unterschied liegt in der Datenverarbeitung, den Kosten und der Compliance-Struktur. Für Unternehmen, die monatliche Berichte automatisieren und Ticket-Triage skalieren wollen, ohne neue Mitarbeiter einzustellen, ist die Wahl der Modell-Infrastruktur entscheidend für den ROI und die DSGVO-Konformität.
Kriterien für die Bewertung der Modell-Infrastruktur
Die Bewertung erfolgt anhand von sechs Kriterien, die für die operative Umsetzung in der Schweiz relevant sind:
- Latenz: Reaktionszeit des Modells bei der Ticket-Klassifikation (Ziel: < 2 Sekunden).
- Kostenstruktur: Fixkosten (Hardware, Lizenzen) vs. variable Kosten (API-Aufrufe).
- DSGVO-Konformität: Datenabfluss, Auftragsverarbeitungsverträge (AVV), Speicherort.
- Vendor-Lock-in: Abhängigkeit von einem bestimmten Anbieter oder Framework.
- Skalierbarkeit: Verhalten bei steigendem Ticketvolumen (z. B. +50 % in der Hochsaison).
- Integrationstiefe: Aufwand für die Anbindung an bestehende CRM-, ERP- und Messaging-Systeme.
Diese Kriterien sind gewichtet: Für Unternehmen mit 11-50 Mitarbeitern haben Compliance und Kostenstruktur höhere Priorität als maximale Latenz, da die Ticketvolumen moderat sind und die manuelle Nachbearbeitung den Engpass bildet.
Vergleichstabelle: Open-Weight vs. Cloud-APIs
| Kriterium | Option A: Open-Weight auf eigener Hardware | Option B: Cloud-APIs (EU-Hosted) |
|---|---|---|
| Latenz | 150-400 ms (je nach GPU, z. B. A100) | 300-800 ms (inkl. Netzwerk-Roundtrip) |
| Kosten (monatlich, 10k Tickets) | 2 500-4 000 CHF (Strom, Wartung, Amortisation) | 1 200-2 500 CHF (API-Gebühren, z. B. GPT-4o) |
| DSGVO | Daten bleiben im Gebäude, kein AVV nötig | AVV mit Cloud-Anbieter, Daten in EU-Rechenzentrum |
| Vendor-Lock-in | Gering (Open-Source, austauschbar) | Mittel (API-Schnittstellen, aber austauschbar) |
| Skalierbarkeit | Begrenzt durch Hardware, Skalierung erfordert neue GPUs | Unbegrenzt, Skalierung durch API-Limits |
| Integration | Höherer initialer Aufwand (GPU-Setup, Modell-Deployment) | Geringer initialer Aufwand (API-Key, Webhook) |
Die Zahlen basieren auf typischen Preisen im Schweizer Markt (2024). Option A hat höhere Fixkosten, aber niedrigere variable Kosten bei hohem Volumen. Option B hat niedrigere Fixkosten, aber variable Kosten steigen linear mit dem Ticketvolumen.
Szenario-spezifische Bewertung
Szenario 1: Hohe Datenhoheit, moderates Volumen. Ein Schweizer E-Commerce-Unternehmen mit 20 Mitarbeitern verarbeitet 5 000 Tickets/Monat. Die Tickets enthalten personenbezogene Daten und Bestellhistorie. Hier gewinnt Option A, weil die Daten nicht das Gebäude verlassen dürfen. Die Latenz von 200 ms ist für die Triage ausreichend, da die menschliche Freigabe den Engpass bildet. Die Kosten von 3 000 CHF/Monat sind akzeptabel, da die manuelle Bearbeitungszeit um 40 % sinkt.
Szenario 2: Schnelle Umsetzung, geringes Volumen. Ein Startup mit 12 Mitarbeitern verarbeitet 1 500 Tickets/Monat und braucht in 4 Wochen einen funktionierenden Pilot. Hier gewinnt Option B, weil der Setup-Aufwand geringer ist. Die API-Kosten von 800 CHF/Monat sind niedrig, und die DSGVO-Konformität ist durch den EU-Hosted-Service gewährleistet. Die Latenz von 500 ms ist für die Triage irrelevant, da die menschliche Freigabe den Prozess dominiert.
Szenario 3: Skalierung ohne neue Hires. Ein Unternehmen mit 30 Mitarbeitern will das Ticketvolumen von 8 000 auf 15 000/Monat skalieren, ohne Personal zu erhöhen. Hier gewinnt Option B, weil die Skalierung durch API-Limits begrenzt ist und die Kosten linear steigen. Option A würde neue GPUs erfordern, was den 4-Wochen-Timeline sprengt. Die Cloud-Option erlaubt es, die Kapazität in Tagen zu erweitern, nicht in Wochen.
Empfehlung für die operative Umsetzung
Für die meisten Schweizer E-Commerce-Unternehmen mit 11-50 Mitarbeitern ist Option B (Cloud-APIs, EU-Hosted) die empfohlene Wahl für den 4-Wochen-Pilot. Die Gründe: 1. Geringerer initialer Aufwand, der den Timeline-Ziel von 4 Wochen einhält. 2. Niedrigere Fixkosten, die für kleine Teams akzeptabler sind. 3. DSGVO-Konformität durch EU-Hosted-Service und AVV. 4. Skalierbarkeit ohne Hardware-Investition. Option A ist nur zu empfehlen, wenn die Datenhoheit eine harte Anforderung ist (z. B. Gesundheitsdaten, Finanzdaten) oder das Ticketvolumen über 20 000/Monat liegt, wo die variablen Kosten der Cloud-APIs die Fixkosten der eigenen Hardware übersteigen. In beiden Fällen sollte die Architektur mit LangGraph model-agnostic bleiben, um später zwischen den Optionen wechseln zu können, ohne den Code zu ändern.
Leave a Reply