Mehrsprachige Support-Tickets automatisch übersetzen, klassifizieren und priorisieren — mit Talend und einem lokalen LLM

Wie ich eine Pipeline gebaut habe, die Support-Tickets in beliebigen Sprachen übersetzt, klassifiziert und priorisiert — mit Ollama, Talend und Qlik Sense

Das Problem, über das niemand spricht

Support-Teams bearbeiten täglich Tickets in mehreren Sprachen. Der interne Workflow läuft auf Deutsch, aber die Tickets kommen auf Englisch, Französisch, Spanisch — und manchmal in Sprachen, mit denen man gar nicht gerechnet hat.

Die klassische Lösung: Ein Mensch liest das Ticket, erkennt die Sprache und leitet es manuell weiter. Das funktioniert. Es kostet aber auch täglich Zeit — still und unbemerkt.

Ich wollte das vollständig automatisieren. Nicht mit einem spezialisierten NLP-Microservice, nicht mit einem eigens trainierten Modell — sondern mit einem gut strukturierten Prompt und einem lokalen LLM, direkt eingebettet in einen Talend-Job.

Die Architektur im Überblick

Der Job besteht aus drei Teilen: einem Prejob, einem Hauptflow (aufgeteilt in zwei Subjobs) und einem Postjob.

Der Job läuft mehrmals täglich — damit die Qlik Sense App kontinuierlich aktuell bleibt

Subjob 1: Tickets an das lokale LLM schicken

Der erste Subjob nimmt jeden Ticket-Datensatz und schickt ihn an Ollama — als lokale REST-API, vollständig getrennt vom Talend Remote Engine. Diese Entkopplung macht es einfach, Modelle zu tauschen, unabhängig zu skalieren oder das LLM zu aktualisieren, ohne die Pipeline anzufassen.

Der Prompt

Kein Fine-Tuning. Kein Modelltraining. Nur ein strukturierter Prompt mit einer strikten JSON-Ausgabevorgabe:

Klassifiziere und übersetze diesen Artikel, antworte NUR mit JSON ohne Markdown.
Format:
{
  "ticket_id": "...",
  "Kategorie": "...",
  "beschreibung_auf_Deutsch": "..."
}
Verarbeite nur diesen Text: <ticket_text>

Wichtige Designentscheidungen:

• „NUR mit JSON ohne Markdown” — Keine Backticks, keine Prosa, keine Erklärungen. Das ist nicht verhandelbar, wenn man die Antwort zuverlässig parsen will.
• Festes Schema — Das LLM gibt immer dieselben Felder zurück: Ticket-ID, Kategorie, deutsche Beschreibung, Subkategorie, Priorität. tExtractJSONFields erledigt den Rest zuverlässig.
• Few-Shot-Beispiele im System-Prompt — Ein paar Beispiele pro Aufgabe reichen, damit das Modell von Anfang an sauber klassifiziert — ohne Training.

Das Modell übernimmt:

• Spracherkennung — egal was reinkommt
• Übersetzung ins Deutsche — als Zielsprache für alle nachgelagerten Prozesse
• Klassifizierung — Hardware / Software / Netzwerk
• Subklassifizierung und Priorisierung

Jede Sprache funktioniert. Ob ein Ticket auf Japanisch oder Arabisch ankommt — es wird genauso übersetzt und klassifiziert wie eines auf Englisch oder Französisch.

Die Antwort parsen

Nachdem tOllamaClient die Antwort zurückgibt, übernimmt ein tJavaRow eventuelle Bereinigungen oder Sonderfälle. Danach mappt tExtractJSONFields die JSON-Felder direkt in den Datenfluss. Das Ergebnis wird per tFileOutputJSON als JSON-Datei abgelegt.

Subjob 2: Anreicherung und QVD-Ausgabe

Der zweite Subjob setzt dort an, wo der erste aufgehört hat. Er liest die Ticket-Daten, führt einen Lookup-Join gegen die übersetzten Ticket-Datensätze durch und schreibt den angereicherten Datensatz mit tQVDOutput als QVD-Datei raus.

QVD (QlikView Data) ist das native Binärformat von Qlik — optimiert für schnelles Laden in Qlik Sense. Direkt aus Talend in QVD zu schreiben bedeutet: keine Zwischenformate, keine zusätzlichen Konvertierungsschritte.

Prejob und Postjob: Sauber halten

Bevor der Hauptjob startet, prüft der Prejob, ob eine QVD-Ausgabedatei vom vorherigen Lauf noch existiert. Falls ja, löscht tFileDelete sie. Das verhindert, dass veraltete Daten sich ansammeln, und stellt sicher, dass jeder Lauf eine saubere, aktuelle Ausgabe produziert.

Nach Abschluss des Jobs löst der Postjob aus, das die frische QVD in die Qlik Sense Umgebung lädt — und die aktualisierten Daten sofort in der App verfügbar macht.

Warum Talend — und nicht Python oder n8n?

Eine berechtigte Frage. Beide sind leistungsfähige Werkzeuge. In einer Qlik-nativen Umgebung ist Talend aber aus mehreren Gründen die richtige Wahl.

Native Qlik-Integration. Talend unterstützt QVD-Ausgabe nativ über tQVDOutput. Mit Python oder n8n bräuchte man zusätzliche Werkzeuge, einen separaten Server oder eigene Konnektoren, um QVD-Dateien zu erzeugen und in die Qlik-Umgebung zu übertragen. In Talend ist das eine einzige Komponente – konfiguriert, nicht programmiert.

Enterprise-Architektur von Haus aus. Talend bringt eine produktionsreife Architektur mit, die man nicht selbst aufbauen muss. Der Remote Engine führt Jobs nah an den Datenquellen aus, entkoppelt von der Cloud-Orchestrierungsschicht. Die Talend Management Console (TMC) bietet zentrales Scheduling, Ausführungshistorie, Alerting und Monitoring für alle Jobs — ohne zusätzliche Infrastruktur aufzubauen. Mit Python-Skripten oder n8n bräuchte man einen eigenen Server, einen Prozessmanager, eine Logging-Lösung und eine Monitoring-Schicht — bevor man überhaupt mit der eigentlichen Logik anfängt.

Eine umfangreiche Komponentenbibliothek. Eine der unterschätzten Stärken von Talend ist, wie viel bereits fertig ist. Allein für diesen Job: tOllamaClient für den LLM-Aufruf, tExtractJSONFields zum Parsen der Antwort, tQVDOutput für die native Qlik-Ausgabe, tFileExist und tFileDelete für das Datei-Lifecycle-Management, tMap für Transformationen und tJavaRow für individuelle Logik. Jede dieser Komponenten ist konfiguriert – keine Bibliothek zum Installieren, kein Skript zum Schreiben und Warten. In einem Enterprise-Kontext zählt diese Konsistenz: Jede Komponente verhält sich vorhersehbar, loggt einheitlich und ist automatisch in das TMC-Monitoring integriert.

Operative Einfachheit. Der Job läuft mehrmals täglich. Mit Talend ist das Scheduling eine Konfiguration — kein Cron-Job auf einem Server, den irgendwann jemand vergisst.

Der größere Punkt

LLMs und Chatbots werden so oft in einem Atemzug genannt, dass man fast vergisst, was sonst noch möglich ist. In einer Datenpipeline ist ein Sprachmodell einfach eine weitere Verarbeitungskomponente — eine, die zufällig außergewöhnlich gut in Aufgaben ist, die sich mit Regeln kaum lösen lassen: Übersetzung, Klassifizierung, Priorisierung über beliebige Sprachen hinweg.

Die Intelligenz ist unsichtbar. Niemand, der die Qlik Sense App nutzt, weiß, dass ein LLM in der Pipeline steckt. Er sieht nur saubere, klassifizierte, deutschsprachige Ticket-Daten — mehrmals täglich aktualisiert, vollautomatisch.

Das ist der Use Case, über den es nachzudenken lohnt: nicht KI als Produkt, sondern KI als Infrastruktur.

Fragen zur Prompt-Struktur, zum Talend-Komponentenaufbau oder zur Ollama-Integration? Gerne in den Kommentaren.