Routine-Anfragen in DE / FR / IT / EN mit RAG über die Support-Wissensbasis beantworten — und klar eskalieren, sobald es nicht-Routine wird.
Kurz gesagt: Routine-Support in DE / FR / IT / EN mit RAG über die Support-Wissensbasis; eskaliert eindeutig und in der erkannten Sprache. Stack: Claude für Mehrsprachigkeit (idiomatisch in allen drei CH-Landessprachen plus EN), Azure OpenAI Switzerland wenn CH-Datenresidenz vertraglich gefordert ist, RAG-Index mit Eval-Set pro Sprache. Anti-Hype: Mehrsprachiger Support lohnt sich, wenn das Anfragevolumen pro Sprache substanziell ist (Richtwert: über 20 Anfragen pro Tag in der seltensten Sprache). Bei kleinerem Volumen oder hoher Spezialisierung pro Sprache bleibt ein gut eingespieltes mehrsprachiges Team oft das bessere Modell.
Schweizer KMU mit Endkundschaft über mehrere Sprachregionen — Tourismus, Versicherung, Versandhandel, öffentliche Dienste — stehen vor einem strukturellen Kostenproblem im Support. Ein grosser Teil des Volumens ist Standard: „Wo ist meine Bestellung?", „Wie ändere ich meine Buchungsdaten?", „Wann öffnet die Bergstation?", „Welche Unterlagen brauche ich für die Anmeldung?". Diese Anfragen sind individuell für den Kunden, aber kollektiv für den Anbieter wiederkehrend — und müssen trotzdem in der Sprache der Kundschaft beantwortet werden, höflich und korrekt.
Eine saisonale Touristik-Firma mit DE / FR / IT / EN-Kundschaft hat in der Praxis zwei Optionen: ein vollständig vier-sprachiges Team aufbauen (teuer, schwer zu rekrutieren, in der Nebensaison überdimensioniert), oder den Support auf ein bis zwei Sprachen reduzieren und die übrige Kundschaft auf Englisch oder via Übersetzungs-Workarounds bedienen (Kundschaft frustriert, Conversion sinkt). KI-gestützter Support ist nicht für alle Anfragen geeignet — aber für die Standard-60-70 % schon, und der Rest landet beim Menschen in der richtigen Sprache. Genau diese Kombination — autonom für Routine, sauber eskaliert für den Rest — ist der Hebel.
Die Pipeline ist klar geschnitten. Eingehende Nachricht (Mail, Web-Formular, Chat) → Sprach-Erkennung über das Modell selbst (Claude erkennt DE / FR / IT / EN zuverlässig, inklusive Schweizer Höflichkeitsformen und regionalem Wortschatz) → Topic-Klassifikation gegen einen kundenspezifischen Katalog (Bestellstatus, Buchungsänderung, Öffnungszeiten, Reklamation, sensible Anliegen, …). Bei klar Routine-klassifizierten Anfragen läuft RAG über die Support-Wissensbasis: der Index enthält FAQs, AGB, Produkt-Datenblätter und interne Antwort-Templates — pro Sprache versioniert, weil Inhalte regional variieren (Öffnungszeiten je Standort, AGB je Sprachversion).
Vor jeder ausgehenden Antwort steht das Confidence-Gate. Über dem Schwellwert geht die Antwort autonom raus, in der erkannten Sprache, mit Quellenverweis auf den Wissensbasis-Eintrag. Unter dem Schwellwert eskaliert der Agent an einen Menschen — und zwar an einen Menschen, der die Sprache spricht. Die Sprach-Erkennung ist robust genug, dass selbst bei eskalierten Fällen das Routing in die richtige Queue funktioniert. Topic-Gates oberhalb der Confidence-Logik: Reklamationen, Beschwerden, sicherheits- oder gesundheitsrelevante Anliegen werden immer eskaliert, unabhängig davon, wie hoch der RAG-Score liegt. Modellseitig: Claude (Anthropic direkt) für Default-Setup; Azure OpenAI Switzerland, wenn CH-Datenresidenz Vertragsbedingung ist.
Wichtig: Das System antwortet nicht nur — es weiss auch, wann es nicht antworten soll. Die Topic-Gates sind die ethische Linie. Wer Reklamationen oder Sicherheitsfragen einem Confidence-Score überlässt, riskiert Schäden, die kein Eval-Set je wieder einholt. Eskalation in solchen Fällen ist nicht „der Agent hat versagt", sondern „der Agent hat richtig erkannt, dass hier ein Mensch hin muss".
Ein Schweizer Reise-Anbieter — Komposit, kein realer Klient — mit Kundschaft über alle vier Sprachen und rund 80 Support-Anfragen pro Tag. Mischung aus klar-Routine (FAQ-Match: Buchungsänderung, Öffnungszeiten der Bergstation, AGB-Klärung, Stornobedingungen) und nicht-Routine (Reklamationen nach abgesagter Tour, individuelle Wünsche für Gruppen-Buchungen, mehrsprachige Komplexfälle, in denen eine italienischsprachige Kundin auf einen deutschsprachigen Reservationsvorgang reagiert). Vor dem Agent bediente ein dreiköpfiges Support-Team primär DE und FR; IT-Anfragen wurden auf Englisch beantwortet oder mit Verzögerung an eine externe Übersetzungs-Hilfe weitergegeben. Nach dem Rollout läuft der Agent in allen vier Sprachen: Routine-Anfragen erhalten Antworten in unter zwei Minuten, mit korrekter Tonalität und Quellenverweis. Reklamationen und Komplexfälle landen direkt beim Menschen in der richtigen Sprache, mit der ursprünglichen Anfrage und einem strukturierten Briefing aus der Agent-Vorarbeit (Sprache erkannt, Topic, vorhandene Kontext-Informationen).
Typisches Muster: 60-70 % der Anfragen werden vollautomatisch in der richtigen Sprache beantwortet; das Support-Team bearbeitet nur noch das tatsächlich Interessante — Reklamationen, Sonderwünsche, mehrdeutige Fälle — und zwar in der Sprache der Kundschaft. Wichtig: Die 60-70 % sind directional, nicht garantiert. Das tatsächliche Verhältnis hängt von der Qualität und Pflege der Wissensbasis ab — eine schlecht gepflegte FAQ-Sammlung führt zu schlechter RAG-Performance, unabhängig vom Modell. Der zweite Effekt: First-Response-Zeit fällt für die Routine-Schicht von Stunden auf Minuten, und sprachfremde Kundschaft (z.B. italienischsprachig in einem primär DE/FR-getriebenen Setup) bekommt erstmals konsistenten Native-Sprach-Support. Aufwand wird nicht eliminiert, sondern verlagert: weg von repetitiver Erst-Antwort, hin zu Wissensbasis-Pflege und zur Bearbeitung der eskalierten Fälle.
Claude und GPT-4 sind beide stark in DE / FR / IT — alle drei Sprachen mit guter idiomatischer Ausprägung und brauchbarem Gespür für Schweizer Höflichkeitsformen (höflichere Ansprache, weniger direkte Aufforderungen als in anderen DACH-Varianten). In unserer Erfahrung ist Italienisch der häufigste Schwachpunkt bei kleineren Modellen: Open-Source-Modelle wie Llama-3 oder Mistral haben mit IT erfahrungsgemäss mehr Mühe als mit DE oder FR, und sehr selten mit Schweizer Eigenheiten — Dialekt-Touches, regionale Begriffe, höflichkeitskonventionsbedingte Umschreibungen. Empfehlung für CH-Multi-Sprachigkeit: Claude oder GPT-4 als Default; wenn aus Compliance- oder Lizenz-Gründen ein Open-Source-Modell gefordert ist, ein intensives Eval-Setup pro Sprache vor Produktivgang einplanen. Romanisch wird von gängigen LLMs aktuell nicht produktionsreif unterstützt (Stand Mai 2026) — für das relevante Volumen in Graubünden bleibt menschliche Bearbeitung der professionellere Weg.
Drei Schwellen, die unabhängig voneinander greifen. (a) Topic-Klassifikation: Reklamationen, Beschwerden, sicherheits- oder gesundheitsrelevante Anliegen werden direkt eskaliert, unabhängig davon, wie hoch die Confidence wäre — diese Themen sollen einen Menschen sehen. (b) Confidence-Schwelle: wenn der RAG-Score unter einem konfigurierten Schwellwert liegt (z.B. unter 0.7 in einer Standard-Konfiguration), eskaliert der Agent — die Wissensbasis hat zur Frage keine ausreichend belastbare Antwort. (c) Längen- und Komplexitäts-Schwelle: wenn eine Anfrage Multi-Issues enthält (eine Mail mit drei verschiedenen Fragen) oder über eine bestimmte Token-Länge geht, splittet der Agent die Anfrage oder eskaliert direkt. Wichtig: Eskalierte Anfragen landen beim Menschen in der richtigen Sprache. Der Agent erkennt die Sprache zuverlässig, auch wenn er die inhaltliche Antwort nicht selbst gibt — die Sprach-Routing-Komponente ist unabhängig von der inhaltlichen Confidence.
Eval-Set pro Sprache, typischerweise 50 bis 100 Fragen mit definierten Antwort-Erwartungen. On top läuft ein Cross-Language-Eval: dieselbe Frage wird in allen vier Sprachen gestellt, und die Antworten sollen inhaltlich konsistent sein (auch wenn sprachlich angepasst). Bei jedem Modell-Wechsel oder RAG-Index-Update läuft der Eval-Set-Lauf vor dem Deployment — wenn eine Sprache plötzlich abfällt (typisches Muster: IT verliert gegenüber DE und FR), ist das ein Pre-Production-Blocker und nicht „nice to have". Zusätzlich empfehlen wir einen quartalsweisen Stichproben-Review durch Native Speaker, gerade für FR und IT, um Drift in Tonalität und Genauigkeit über Zeit zu erkennen. Wissensbasis-Updates sollten ebenfalls einen kleinen Eval-Lauf triggern, weil ein einzelner geänderter FAQ-Eintrag pro Sprache anders wirken kann.
Dieser Use Case sitzt in der Praktik KI-Engineering und greift in benachbarte Customer-Operations- und Wissens-Use-Cases.
Praktik: LLM-Anwendungen in Produktion — Mehrsprachigkeit, RAG, Evaluation, Guardrails, Plattformwahl mit CH-Datenresidenz.
RAG-Pipeline über firmen-eigene Inhalte — Indexierung, Retrieval, Antwort-Generierung mit Quellenverweis und Eval-Set.
Inbound klassifizieren, Antwort-Drafts, CRM-Routing mit Approval-Queue — das Schwester-Pattern für gemischte Sales/Support-Inboxen.
Mehrsprachiger Support lohnt sich, wenn das Anfragevolumen pro Sprache substanziell ist (Richtwert: über 20 Anfragen pro Tag in der seltensten Sprache) und ein 4-sprachiges Team unwirtschaftlich ist. Für ein 1-2-Sprachen-Setup mit hoher Spezialisierung bleibt das eingespielte Team-Modell oft besser — und das sagen wir Ihnen ehrlich, bevor wir Zeit Ihrerseits binden. In einem unverbindlichen 30-Minuten-Discovery-Call schauen wir Ihre Sprach-Verteilung und Wissensbasis an.
Discovery-Call anfragen