Ähnliche Tickets, ohne die Antworten zu kennen

Eine naheliegende Funktion mit einem unbequemen Standardweg

Ähnlichkeitssuche über den eigenen Ticketbestand ist ein naheliegender Wunsch: Bevor jemand ein Problem zum dritten Mal von Grund auf neu untersucht, wäre es hilfreich zu wissen, dass ein sehr ähnlicher Fall vor drei Monaten bereits gelöst wurde. Technisch wird das meist über sogenannte Embeddings umgesetzt — mathematische Repräsentationen von Text, die es erlauben, „bedeutungsähnlich" statt nur „wortgleich" zu suchen.

Der übliche Weg dorthin führt über einen Cloud-Dienst: Der gesamte Ticketbestand wird in ein externes System hochgeladen, dort in Embeddings umgewandelt und in einer Vektordatenbank gespeichert, die ausserhalb der eigenen Kontrolle liegt. Für ein Werkzeug, dessen ganzer Zweck der kontrollierte Umgang mit personenbezogenen Daten ist, wäre das die Antithese zu allem, was JiCo sonst tut — ein zusätzlicher, dauerhafter Datenbestand an einem fremden Ort, gefüllt mit demselben Material, das die PII-Schleuse eigentlich vom Modell fernhalten soll.

Der Unterschied: eine lokale Kopie, die schon bereinigt ist

JiCos Ähnlichkeitssuche setzt deshalb an einer anderen Stelle an. Grundlage ist nicht der rohe Jira-Bestand, sondern die lokale Replika — jene Kopie, die JiCo für den eigenen Betrieb ohnehin schon anlegt, redigiert und verschlüsselt vorhält. Der Suchindex entsteht also nicht aus unbereinigten Rohdaten, sondern aus genau dem Material, das die PII-Schleuse bereits durchlaufen hat.

Die eigentliche Rechenarbeit — das Umwandeln von Text in Embeddings — läuft dabei ausschliesslich lokal, mit einem eigens dafür vorgesehenen, lokal betriebenen Modell (bge-m3). Es gibt keinen Moment, in dem Ticketinhalte für diese Funktion das eigene Gerät verlassen, weil weder die Berechnung noch der Index selbst je an einen externen Dienst gehen.

Wie sich das im Alltag anfühlt

Aus Sicht eines Sprachmodells oder des lokalen Chats zeigt sich das als ein einziges, unscheinbares Werkzeug: jira_aehnliche_suchen. Der Aufbau des Index geschieht dabei nicht automatisch im Hintergrund, sondern über einen bewusst angestossenen Lauf — entweder per Terminal-Befehl oder über das Panel unter Betrieb, dort inklusive einer Probesuche, mit der sich die Qualität vorab überprüfen lässt, und der Möglichkeit, den Index bei Bedarf vollständig zu leeren.

Ein Detail, das im Alltag überraschend oft wichtig wird: Jeder Treffer der Ähnlichkeitssuche zeigt nicht nur den Ticket-Stand, sondern auch, wie alt die lokale Kopie ist, auf der er beruht — „lokal gelesen vor n Minuten". Diese Angabe verhindert ein leises Missverständnis, das bei jeder Art von Suchindex entstehen kann: dass ein Treffer als aktueller Stand missverstanden wird, obwohl er auf einer möglicherweise schon etwas älteren lokalen Kopie beruht.

Ein Index, der mit der Replika mitwächst

Nach dem eigentlichen Aufbaulauf bleibt der Index nicht statisch stehen. Ein Hintergrundprozess trägt neu gelesene Tickets laufend nach — bis zu 32 je Durchlauf —, sodass frisch hinzugekommene oder erneut gelesene Inhalte mit der Zeit von selbst im Index landen, ohne dass jedes Mal ein vollständiger neuer Aufbaulauf nötig wäre. Weil der Index technisch aus der lokalen Replika abgeleitet ist, lässt er sich im Panel unter Betrieb › Datenpflege jederzeit vollständig leeren, ohne dass dabei etwas endgültig verloren ginge: Die zugrunde liegende Replika bleibt bestehen, und der Index selbst wird beim nächsten Abgleich aus ihr neu berechnet.

Was diese Funktion bewusst nicht tut

Eine Ähnlichkeitssuche über einen lokalen Index ist kein Ersatz für eine Live-Abfrage bei Jira, und sie wird auch nicht als solcher dargestellt. Sie beantwortet die Frage „was gab es hier schon einmal Ähnliches" — nicht die Frage „was ist der aktuelle Stand dieses konkreten Tickets jetzt gerade". Für Letzteres liest JiCo weiterhin direkt gegen Jira, mit der bekannten Stand-Prüfung vor jeder Ausführung.

Diese bewusste Trennung ist kein Zufall: Eine Ähnlichkeitssuche, die versuchen würde, gleichzeitig auch als aktueller Live-Zugriff zu funktionieren, würde entweder viel zu oft neu rechnen müssen, um aktuell zu bleiben, oder sich selbst die Möglichkeit zu falscher Sicherheit einhandeln. Klar getrennt zu bleiben ist hier die einfachere und ehrlichere Lösung.

Der eigentliche Gewinn liegt nicht in der Technik

Der eigentliche Unterschied zu einer gewöhnlichen Cloud-Ähnlichkeitssuche liegt nicht in der Qualität der gefundenen Treffer — das hängt vor allem vom verwendeten Modell ab, und lokale wie Cloud-Modelle entwickeln sich hier ständig weiter. Der Unterschied liegt darin, wo die Rechnung stattfindet und wo die Ergebnisse liegen bleiben: auf dem eigenen Gerät, aus bereits redigierten Daten, ohne einen neuen, dauerhaften Datenbestand an einem fremden Ort zu schaffen. Für ein Unternehmen, das genau das vermeiden will, ist das kein technisches Detail, sondern der eigentliche Grund, sich für diesen Weg zu entscheiden.