Klassifizierung
Zero-Shot-Klassifikation — Werte syncen, beschreiben und Ausführung einstellen.
Klassifizierungsaufgaben
Ein Klassifizierungs-Agent lässt die Runtime ein Ticket-Attribut setzen — Queue, Priorität, Typ, Service oder ein Dropdown-DynamicField. Die KI arbeitet zero-shot: Sie wählen Zielwerte aus dem Ticketsystem, schreiben kurze Beschreibungen, und die lokale LLM wählt den passenden Wert.
Studio legt eine Agent-Art pro Ziel an (wie die Runtime). Bei nativen Zielen ist das Prediction-Target fest; nur die DynamicField-Klassifikation fragt nach dem Feldnamen.
Aufgabe anlegen
- Öffnen Sie Agents.
- Klicken Sie + New Agent / + Neuer Agent und wählen Sie eine der Arten:
- Queue classification / Warteschlangen-Klassifikation
- Priority classification / Prioritäts-Klassifikation
- Type classification / Typ-Klassifikation
- Service classification / Service-Klassifikation
- Dynamic field classification / DynamicField-Klassifikation
- oder Beispiel ausprobieren für eine Demo (Abteilung, Kommunen-Queues, Verwaltungspriorität oder Universitäts-Queues)
- Studio öffnet die Detailseite des neuen Agenten (zunächst Inactive).
Ziel und LLM
Rechts unter Einstellungen:
- Prediction target — fest bei Queue-, Priority-, Type- und Service-Agenten. Bei DynamicField-Klassifikation: DynamicField name (exakter Name im Ticketsystem).
- LLM size — Studio empfiehlt eine Größe; darunter steht der konkrete Modellname.
Werte synchronisieren und beschreiben
- Klicken Sie Sync values from ticket system. Studio übernimmt die exakten Namen aus dem Ticketsystem (Beschreibungen werden nicht überschrieben).
- Klicken Sie einen Wert und ergänzen Sie die AI description — kurz, in der Sprache Ihrer Tickets, wann dieser Wert zutrifft.
Ohne brauchbare Beschreibungen bleibt die Klassifikation schwach. Namen müssen zum Ticketsystem passen — keine frei getippten Schreibvarianten.
Ausführung
Unter Ausführung steuern Sie, wann die Runtime läuft und was bei unsicherer Vorhersage passiert. Speichern Sie mit Speichern.
| Einstellung | Bedeutung |
|---|---|
| Only when state is | Optional: nur Tickets in diesem Status (z. B. new) |
| Only when … is | Optional: nur wenn das Zielattribut einen bestimmten Wert hat |
| Also run when … is empty | Zusätzlich laufen, wenn das Attribut leer ist |
| Strenge | Mindest-Sicherheit der KI: Locker (60 %), Normal (80 %) oder Streng (90 %) |
| Fallback-Wert setzen? | Bei niedriger Sicherheit einen sicheren Ersatzwert statt der KI-Vorhersage schreiben |
| Fallback-Wert | Ersatzwert auswählen; erscheint nur, wenn ein Fallback gesetzt wird |
| Zur manuellen Prüfung markieren? | Unsichere Tickets für Agents über die HumanReviewNeeded-DynamicFields markieren |
Stellen Sie zuerst die Strenge ein. Legen Sie danach fest, was bei niedriger Sicherheit passiert. Ohne Fallback-Wert bleibt die manuelle Prüfung eingeschaltet, damit kein unsicheres Ticket ohne Aktion bleibt.
Kundenspezifischer Kontext gehört in Zusatzinformationen (Modell-Einstellungen),
nicht in einen separaten Basis-Prompt. Unter Advanced (optional):
Artikelnotiz schreiben mit Vorlagen-Platzhaltern ({result_value},
{confidence}, …).
Tickets, die für dieses Attribut bereits ein Konfidenz-DynamicField haben, werden nicht erneut klassifiziert.
Aktivieren
- Mindestens einen Eligibility-Filter setzen (State und/oder Attribut / „empty“).
- Keine blockierenden Werte: Predict darf nicht für Werte an sein, die im Ticketsystem fehlen — sonst blockiert Activate.
- Activate — die Runtime übernimmt die Aufgabe.
- Deactivate stoppt die Ausführung; die Konfiguration bleibt.
Archivieren entfernt die Aufgabe aus der Liste, löscht sie aber nicht.
Tipps
- Typischerweise ein aktiver Agent pro Attribut (z. B. ein Queue-Agent).
- Nach Queue-/Prioritätsänderungen im Ticketsystem erneut Sync.
- Wirkung und Fallbacks auf dem Dashboard prüfen.