Wissenskandidaten, Textbausteine und Suche

Tickessa trennt fachliche Fakten, Formulierungshilfen und technische Suchableitungen. Dadurch kann ein neuer KI-Anbieter oder ein neues Suchmodell verwendet werden, ohne dass geprüfte Originalinhalte verloren gehen.

Wissenskandidaten aus Antworten

Ein Wissenskandidat ist ein unveröffentlichter Vorschlag, der aus einer bereits geprüften KI-Antwort entstehen kann.

1. Erstelle im Ticket einen KI-Antwortentwurf.
2. Prüfe den Entwurf und übernimm oder bearbeite ihn.
3. Wähle am geprüften Vorschlag Als Wissen übernehmen.
4. Tickessa entfernt erkennbare E-Mail-Adressen und fallspezifische Angaben.
5. Der Kandidat erscheint unter Wissen & Bausteine → Wissenskandidaten.

Die Aktion versendet keine E-Mail und veröffentlicht keinen Artikel. Kann Tickessa die Anonymisierung nicht sicher bestätigen, wird kein Kandidat gespeichert.

Kandidat prüfen

Kontrolliere insbesondere:

• Ist die Aussage allgemein und nicht nur in diesem Einzelfall richtig?
• Sind Namen, E-Mail-Adressen, Ticketnummern und andere personenbezogene Details entfernt?
• Passt der Inhalt zum ausgewiesenen Projekt und zur Produktversion?
• Fehlen Voraussetzungen, Grenzen oder sichere Rückfragen?

Mit Als Entwurf anlegen wird ein interner Wissenseintrag mit offener fachlicher Prüfung erstellt. Mit Verwerfen wird der Kandidat nachvollziehbar abgelehnt. Auch nach der Umwandlung ist ein weiterer Freigabe- und Veröffentlichungsprozess erforderlich.

KI-Wissensentwurf aus mehreren gelösten Vorgängen

Im Bereich KI-Wissensentwurf aus gelösten Vorgängen kannst du eine wiederkehrende Lösung bewusst aus mehreren Fällen ableiten lassen. Das Lösen eines Tickets startet diese Funktion nicht automatisch.

1. Wähle das Projekt.
2. Markiere einen bis acht gelöste oder geschlossene Vorgänge. Es werden nur Fälle angeboten, die eine eingegangene Nachricht und eine als gesendet protokollierte Lösung enthalten.
3. Entscheide, ob ein neuer Wissensartikel oder eine Aktualisierung einer bereits veröffentlichten Fassung vorgeschlagen werden soll.
4. Lege die beabsichtigte spätere Zielgruppe fest. Öffentlich ist dabei nur ein Prüfhinweis und keine Veröffentlichung.
5. Wähle Entwurf … vorschlagen und bestätige den Hinweis zum Provideraufruf.

Tickessa entfernt vor dem KI-Aufruf bekannte Kontaktdaten, E-Mail-Adressen, Ticketnummern, URLs und Telefonnummern. Typische Anreden, Signaturvarianten und angehängte zitierte Mailverläufe werden aus Problem und Antwort abgeschnitten. Die KI erhält nur die so minimierten Problem-/Lösungspaare sowie bei einer Aktualisierung die freigegebene Zielfassung.

Die bereinigten Ticketauszüge bleiben technisch als unvertrauenswürdige Kundendaten gekennzeichnet und werden auf Manipulationsversuche geprüft. Nur die schon freigegebene Zielfassung eines vorhandenen Artikels gilt als geprüfte Referenz. So kann Text in einem Ticket weder die Sicherheitsregeln noch Freigabe oder Veröffentlichung verändern.

Wann wird kein KI-Aufruf durchgeführt?

Die lokale Vorprüfung stoppt bei ungeeigneten Grundlagen, zum Beispiel:

• ausgewählte Tickets gehören zu verschiedenen Projekten,
• Kategorie oder Produktversion widersprechen sich,
• eine belegte Problem- oder Lösungsseite fehlt,
• Lösungsaussagen stehen erkennbar im Widerspruch,
• der Zielartikel besitzt keine geeignete freigegebene Version.

Soweit die Auswahl noch sicher gespeichert werden kann, erscheint ein Prüfproblem mit den konkreten offenen Punkten. Es ist nicht als Wissensentwurf übernehmbar. Der Zähler der Provideraufrufe bleibt null. Wähle passende Quellen neu aus oder verwerfe den Warnkandidaten.

Einen erzeugten Kandidaten prüfen

Jeder KI-Kandidat zeigt:

• Projekt und sämtliche internen Quelltickets,
• neuen Artikel oder Aktualisierung,
• spätere Zielgruppe,
• offene Unsicherheiten,
• tatsächlich zitierte und nicht zitierte Quellen,
• Provider, Modell, KI-Lauf, Prompt- und Kontextversion,
• Ergebnis der Anonymisierungsprüfung.

Mit Anonymisierte Prüfgrundlage anzeigen kannst du außerdem genau die bereinigten Problem- und Lösungsauszüge lesen, die Tickessa fachlich für den Vorschlag verwendet hat. Das sind nicht die rohen Ticketdaten: bekannte Kontaktdaten, E-Mail-Adressen, Ticketnummern und Antwortsignaturen wurden vorher entfernt. Technische Prüfgründe wie eine fehlende Produktversion oder widersprüchliche Lösungen erscheinen dabei als verständliche Hinweise.

Bei einer Aktualisierung öffnet Änderung gegenüber … einen zeilenweisen Vergleich: − kennzeichnet Text der bisherigen freigegebenen Fassung, + den Vorschlag. Die freigegebene Fassung bleibt währenddessen unverändert.

Als Entwurf anlegen erzeugt bei einem neuen Artikel eine interne Version 1. Bei einer Aktualisierung entsteht am vorhandenen Artikel eine neue interne Fassung. Beide tragen weiterhin Prüfung offen. Erst danach kannst du über die normale Wissensbearbeitung korrigieren, fachlich freigeben und – falls wirklich gewollt – in einem getrennten Schritt veröffentlichen.

Keine automatische Veröffentlichung

KI-Erzeugung, Kandidatenprüfung und Umwandlung können keine Veröffentlichung auslösen. Auch ein als „später öffentlich“ gekennzeichneter Kandidat wird zunächst ausschließlich intern gespeichert.

Budget, Ausfall und Anbieterwechsel

Eine widerspruchsfreie Erzeugung benötigt einen budgetierten Lauf der administrativ konfigurierten Aufgabe Wissensentwurf. Nur ein zuvor ausdrücklich freigegebener Fallback kann bei einem zulässigen Fehler einen zweiten Lauf auslösen. Tages-/Monatsbudget, Not-Aus und Aufruflimit gelten auch hier. Ist die Aufgabe ausgeschaltet, das Budget erreicht oder der Anbieter nicht erreichbar, wird kein halbfertiger Kandidat angelegt. Du kannst weiterhin einen Wissenseintrag manuell anlegen.

Ein späterer Anbieterwechsel ändert nur, wer einen neuen Vorschlag erzeugt. Projektgrenze, interne Erstfassung, Fachprüfung und getrennte Veröffentlichung bleiben technisch gleich.

Textbausteine

Textbausteine sind wiederverwendbare Formulierungen für die Ticketbearbeitung. Sie können projektbezogen oder projektübergreifend sein und ein Kürzel besitzen.

Ein Textbaustein:

• ist keine automatisch versendete Antwort,
• ersetzt keine fachlich geprüfte Wissensquelle,
• darf keine fallbezogenen Kundendaten oder Geheimnisse enthalten,
• muss vor einer Kundenantwort immer im konkreten Zusammenhang geprüft werden.

In Tickessa 0.8.0 zeigt der Bereich die vorhandenen Textbausteine mit Titel, Vorschau, Projekt und Kürzel. Die weitergehende redaktionelle Verwaltung wird getrennt ausgebaut.

Lokale Suchableitung

Wissensartikel und Textbausteine bleiben als Originale in der eigenen MariaDB-Installation. Der Suchindex und spätere Embeddings sind ausschließlich neu erzeugbare Ableitungen.

Der Bereich Lokale Suchableitung zeigt:

• Status: ob ein verwendbarer Index vorliegt,
• Generation: wie oft die Ableitung kontrolliert neu aufgebaut wurde,
• Dokumente: wie viele freigegebene Quellen enthalten sind,
• Zuletzt aufgebaut: Zeitpunkt des letzten vollständigen Aufbaus,
• Index-/Embedding-Modell: Bezeichnung der verwendeten Suchmethode.

Administratoren können Kontrolliert neu aufbauen wählen. Dabei wird nur die alte Ableitung ersetzt. Originalartikel, Versionen, Quellen, Antwortprofile und Qualitätsfeedback bleiben erhalten.

Welche Quellen darf die KI verwenden?

Vor einem KI-Vorschlag filtert Tickessa die Wissensgrundlage serverseitig. Eine Quelle muss insbesondere:

• zum Projekt des Tickets gehören oder ausdrücklich projektübergreifend sein,
• fachlich freigegeben und veröffentlicht sein,
• für die aktuelle Zielgruppe zulässig sein,
• innerhalb ihres Gültigkeitszeitraums liegen,
• zur bekannten Produktversion passen,
• nicht wegen Wiedervorlage oder Widerspruch ungeprüft verwendet werden.

Die Oberfläche zeigt die tatsächlich angebotenen Quellen samt Version. Nennt ein Modell eine andere Quelle, wird der Vorschlag verworfen. Gibt es keine passende Wissensgrundlage, darf ein Antwortentwurf keine unbelegte Lösung behaupten; er kann nur Rückfragen vorschlagen und bleibt vollständig manuell zu prüfen.