💻 computer science

Learning Selective LLM Autonomy from Copilot Feedback in Enterprise Customer Support Workflows

Dieser Beitrag stellt ein eingesetztes System vor, das Copilot-Feedback und UI-Interaktionsspuren nutzt, um einen selektiven LLM-Agenten zur Automatisierung von Enterprise-Kundensupport-Workflows zu trainieren, der eine Automatisierungsrate von 45 % und eine Verkürzung der Bearbeitungszeit um 39 % bei gleichzeitiger Wahrung der Qualität durch einen auf Konfidenz basierenden Enthaltungsmechanismus erreicht.

Ursprüngliche Autoren: Nikita Borovkov, Elisei Rykov, Olga Tsymboi, Sergei Filimonov, Nikita Surnachev, Dmitry Bitman, Anatolii Potapov

Veröffentlicht 2026-04-28

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Nikita Borovkov, Elisei Rykov, Olga Tsymboi, Sergei Filimonov, Nikita Surnachev, Dmitry Bitman, Anatolii Potapov

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich ein belebtes Kundenbetreuungszentrum als einen riesigen, komplexen Kontrollraum vor. Darin jonglieren menschliche Bediener ständig mit Computern, klicken auf Tasten, füllen Formulare aus und tippen Nachrichten, um Kundenprobleme zu lösen. Es ist ein hochriskanter Job, bei dem ein falscher Klick für einen Kunden zu einem Kopfweh führen kann.

Dieser Artikel beschreibt ein neues System für einen „intelligenten Assistenten", das für diesen Kontrollraum entwickelt wurde. Anstatt die Menschen vollständig zu ersetzen, fungiert das System wie ein überaus aufmerksamer Co-Pilot, der lernt, das Auto zu fahren, aber nur dann das Steuer übernimmt, wenn es zu 100 % sicher ist, dass kein Unfall passiert.

So funktioniert es, aufgeschlüsselt in einfache Schritte:

1. Die „Schatten"-Phase (Lernen durch Beobachten)

Zunächst tut das System nichts. Es beobachtet nur. Es zeichnet jeden einzelnen Klick, jede Tastenanschlag und jede Bildschirmänderung auf, die die menschlichen Bediener beim Lösen Tausender Kundenfälle vornehmen. Denken Sie daran wie an einen neuen Fahrer, der auf dem Beifahrersitz sitzt und wochenlang einen Profi-Fahrer beobachtet, wie er durch eine Stadt navigiert, und jede Kurve und jedes Stoppschild auswendig lernt.

2. Die „Co-Pilot"-Phase (Vorschlagen, nicht Entscheiden)

Als Nächstes beginnt das System, Vorschläge zu machen. Es sagt: „Hey, basierend auf dem, was ich gesehen habe, sollten Sie wahrscheinlich als Nächstes auf diesen Knopf klicken."

Die Rolle des Menschen: Der Bediener kann entweder sagen: „Ja, gute Idee", und das System dies tun lassen, oder er kann sagen: „Nein, machen Sie es stattdessen so."
Das Lernen: Jedes Mal, wenn der Mensch das System korrigiert, lernt das System. Es ist wie ein Schüler, der eine Hausaufgabe mit einem roten Korrekturstift korrigiert bekommt. In nur zwei Wochen wird das System sehr gut darin, den richtigen nächsten Schritt zu erraten.

3. Die „Selektive Autopilot"-Phase (Das Steuer sicher übernehmen)

Dies ist der wichtigste Teil. Das System übernimmt nicht blindlings die Kontrolle. Es verfügt über einen integrierten „Sicherheits-Richter" (ein Critic).

Hohe Sicherheit: Wenn das System sehr sicher ist (z. B. „Klicken Sie auf die Schaltfläche 'Weiter'"), führt es dies automatisch im Hintergrund aus.
Geringe Sicherheit: Wenn das System unsicher ist (z. B. „Soll ich diese spezifische Nachricht an den Kunden senden?"), hält es an und bittet den Menschen um Hilfe.
Das Ergebnis: Der menschliche Bediener kann nun mehrere Gespräche gleichzeitig beobachten. Er muss nur dann eingreifen, wenn das System anhält und eine Frage stellt. Er tippt nicht mehr selbst; er ist lediglich das Sicherheitsnetz.

Wie es mit Fehlern umgeht

Der Artikel stellt fest, dass das System darauf ausgelegt ist, vorsichtig zu sein.

Das „Stopp"-Zeichen: Wenn sich der Computerbildschirm auf eine seltsame Weise verändert, die das System noch nie gesehen hat, oder wenn das System bei einer Entscheidung nervös wird, gibt es die Kontrolle sofort an den Menschen zurück.
Der „Reset"-Knopf: Wenn das System einen Fehler macht, gerät es nicht außer Kontrolle. Es hält an, lässt den Menschen den Bildschirm korrigieren und setzt dann genau dort fort, wo es aufgehört hat.

Die Ergebnisse aus der Praxis

Das Team testete dies in einer realen Geschäftsumgebung mit etwa 15.000 Kunden.

Geschwindigkeit: Das System bewältigte 45 % des gesamten Gesprächs von Anfang bis Ende ohne menschliche Hilfe.
Zeitersparnis: Die Zeit, die ein Bediener aktiv für die Bearbeitung eines einzelnen Kunden aufwenden musste, sank um 39 %.
Qualität: Die Qualität der Unterstützung ging nicht zurück. Die Kunden waren genauso zufrieden wie zuvor.

Die große Erkenntnis

Der Artikel argumentiert, dass man keinen Roboter braucht, der versucht, alles perfekt zu machen, um nützlich zu sein. Stattdessen braucht man einen Roboter, der selektiv mutig ist. Er erledigt automatisch die langweiligen, repetitiven, risikoarmen Aufgaben (wie das Klicken auf Tasten oder das Ausfüllen von Formularen), weiß aber genau, wann er sagen muss: „Ich bin mir nicht sicher, Sie übernehmen diesen Fall."

Dieser Ansatz ist schneller zu entwickeln als traditionelle Computerprogramme (bei denen Menschen starre Regeln für jedes mögliche Szenario schreiben müssen) und zuverlässiger als eine „wilde" KI, die versucht, alles allein zu erledigen. Er verwandelt den menschlichen Bediener von einem „Fahrer" in einen „Flottenleiter", der viele Gespräche gleichzeitig mit viel weniger Stress überwacht.

1. Problemstellung

Der Einsatz von Large-Language-Model-(LLM-)Agenten für die End-to-End-Automatisierung im unternehmensinternen Kundensupport stößt auf erhebliche Hindernisse:

Fehlerfortpflanzung: Kleine Fehler bei mehrstufigen UI-Interaktionen summieren sich über längere Zeiträume auf und führen zu Workflow-Fehlern.
Kosten und Komplexität: Traditionelle mehrstufige Regelkreise sind im großen Maßstab teuer, und häufige UI- oder Prozessänderungen machen spröde Robotic-Process-Automation (RPA) oder manuell skriptgesteuerte Abläufe schwer wartbar.
Sicherheit und Vertrauen: Vollautonome Agenten riskieren eine Verschlechterung der Supportqualität oder verursachen irreversible Fehler in sensiblen Geschäftsprozessen (z. B. Kontenänderungen).
Datenknappheit: Im Gegensatz zu Benchmarks für das Web-Browsing fehlen für Unternehmensworkflows große, öffentliche Datensätze zum Training, und die Domänenlogik ist hochspezialisiert.

Die Autoren schlagen ein System vor, das selektive Automatisierung erreicht: Es automatisiert Schritte mit hoher Konfidenz, während unsichere Entscheidungen an menschliche Bediener delegiert werden, wodurch Effizienz und Sicherheit in Einklang gebracht werden.

2. Methodik

Das System verwendet eine gestaffelte Bereitstellungs-Pipeline, die vom Imitationslernen (insbesondere DAgger) inspiriert ist und drei Phasen durchläuft, um eine Policy und einen Critic zu trainieren.

A. Datenrepräsentation und Serialisierung

Schema-gesteuerte Ansicht: Anstatt sich auf rohes DOM oder Screenshots zu verlassen (die anfällig für UI-Änderungen sind), extrahiert das System eine schema-gesteuerte JSON-Repräsentation der Business-Process-Management-(BPM-)Schnittstelle.
Zustand-Aktion-Spuren: Bediener-Sitzungen werden als Trajektorien $\{s_t, a_t\}$ protokolliert. Der Zustand $s_t$ umfasst Chatverlauf, UI-Kontext (Kundenprofil, aktives Szenario) und globale Ankündigungen. Aktionen $a_t$ werden in vier Kategorien eingeteilt: Nachrichtenerstellung, Navigation, Auswahl/Formularausfüllung und Sitzungsverwaltung.
Eingabeformat: UI-Snapshots und Aktionen werden zu einem chronologischen Dialog verschmolzen, der Kundenmitteilungen, Bedieneraktionen und aktualisierte UI-Zustände für die LLM-Eingabe abwechselnd darstellt.

B. Gestaffelte Bereitstellungs-Pipeline

Protokollierungsphase:
- Erfasst vollständige Interaktionsspuren von Bedienern.
- Trainiert ein initiales Policy-Modell ( $\pi_\theta$ ) durch Supervised Fine-Tuning (SFT) mittels Behavior Cloning (Vorhersage der nächsten Aktion basierend auf dem Zustand).
Copilot-Phase:
- Setzt die Policy ein, um Bedienern in Echtzeit Aktionen vorzuschlagen.
- Feedback-Schleife: Bediener akzeptieren den Vorschlag oder korrigieren ihn.
- Kritisch vs. Nicht-kritisch: Nicht-kritische Aktionen (z. B. UI-Navigation) können automatisch ausgeführt werden; kritische Aktionen (z. B. Senden von Nachrichten, Schließen von Chats) erfordern die menschliche Genehmigung.
- Diese Phase generiert gelabelte Daten (akzeptieren/ablehnen), speziell für kritische Schritte.
Phase der selektiven Automatisierung:
- Trainiert ein Critic-Modell ( $c_\phi$ ) mithilfe des Copilot-Feedbacks, um die Wahrscheinlichkeit abzuschätzen, dass ein vorgeschlagener kritischer Schritt korrekt ist.
- Gesteuerte Ausführung: Das System führt eine Aktion $\hat{a}$ nur aus, wenn die Critic-Bewertung $c_\phi(s, \hat{a}) \geq \tau$ ist (wobei $\tau$ ein kalibrierter Schwellenwert ist).
- Abstinenz: Liegt die Bewertung unter $\tau$ , wird die Kontrolle an den menschlichen Bediener übergeben, der vom aktualisierten UI-Zustand aus fortfährt.
- Kalibrierung: Der Schwellenwert $\tau$ wird so justiert, dass geschäftliche Präzisionsanforderungen erfüllt werden (z. B. Sicherstellen, dass 90 % der automatisierten Aktionen von Menschen akzeptiert würden).

C. Sicherheit und Anpassungsfähigkeit

Handling von Out-of-Distribution (OOD): Das System verwendet tägliche Validierungsregeln, um neue UI-Elemente zu erkennen. Wird eine Drift erkannt, wird die Automatisierung für den betroffenen Slice deaktiviert und es wird in den Copilot-Modus zurückgefallen, um neue Supervision zu sammeln.
Anonymisierung: Trainingsdaten unterliegen einer strengen Maskierung (Ersetzung von Entitäten, Unterscheidbarkeit auf Sitzungslevel), um personenbezogene Daten (PII) zu schützen.
Kontinuierliche Verbesserung: Modelle werden auf rollierenden Fenstern aktueller Daten neu trainiert, mit slice-spezifischen Policy-Critic-Paaren für verschiedene Problemcluster.

3. Hauptbeiträge

Produktionsskalierbare gestaffelte Bereitstellung: Eine neuartige Pipeline, die vom Protokollieren über Copilot zur selektiven Automatisierung übergeht und natürlich vorkommende Supervision (Akzeptieren/Ablehnen) nutzt, anstatt manuelle Regelverfassungen zu erfordern.
Schema-gesteuerte Zustands-Serialisierung: Der Wechsel von visuellen/screenshot-basierten Agenten zu einer strukturierten JSON-Repräsentation der BPM-Schnittstelle, was eine robuste Überwachung und zuverlässige Tool-Aufrufe ohne Bildverarbeitung ermöglicht.
Critic-gesteuerte Autonomie: Ein Mechanismus, der eine durch SFT trainierte Policy mit einem auf Trajektorien-Feedback trainierten Critic kombiniert, um den Trade-off zwischen Fehlerabdeckung und Sicherheit zu steuern und eine sichere Hintergrundausführung von Schritten mit hoher Konfidenz zu ermöglichen.
Engineering-Framework: Umfassende Dokumentation von Sicherheitsvorkehrungen (Abstinenz, Umgang mit Daten-Drift, Fallbacks) und einem Online-Evaluierungsprotokoll mit Ablationsstudien.

4. Experimentelle Ergebnisse

Das System wurde in einer Live-Produktionsumgebung mit jeweils etwa 15.000 Kunden pro A/B-Testgruppe evaluiert.

Offline-Ergebnisse

Notwendigkeit von SFT: Zero-Shot-Prompting (selbst mit großen Modellen wie GPT-5 oder Gemini 3) erreichte nur eine Tool-Genauigkeit von ca. 47 %. Domänenspezifisches SFT auf dem Qwen2.5-7B-Modell erreichte 79,15 % Tool-Genauigkeit, was beweist, dass spezialisiertes Fine-Tuning für Unternehmenslogik unerlässlich ist.
Datenmischung: Das Mischen historischer Protokolle mit Copilot-Ablehnungskorrekturen verbesserte die Generalisierung bei schwierigen Fällen.
Critic-Leistung: Ein durch SFT trainierter Critic übertraf eine auf Konfidenz basierende Baseline um +3,84 % Precision und +3,03 % F1, was bestätigt, dass das Lernen aus explizitem menschlichem Feedback der rohen Modellunsicherheit überlegen ist.

Online-Ergebnisse (A/B-Tests)

Effizienz: Im Vergleich zu einer rein menschlichen Baseline reduzierte das System der selektiven Automatisierung die durchschnittliche Agentenzeit (AAT) um 39 % (von 227 s auf 139 s).
Qualität: Die Werte für die Korrektheit der Problemlösung blieben im Vergleich zur Baseline statistisch unverändert, was bestätigt, dass keine Verschlechterung der Supportqualität eintrat.
Automatisierungsrate: Das System automatisierte 45 % der Sitzungen vollständig End-to-End ohne menschliches Eingreifen.
Vergleich mit klassischen Bots: Es übertraf eine regelbasierte Chatbot-Baseline durch eine Reduktion der AAT um 16 %.
Inkrementeller Gewinn: Der Wechsel von „obligatorischer Bestätigung" zu „automatisierungsfähiger Ausführung" reduzierte die AAT weiter um 25 %.

5. Bedeutung und Fazit

Dieses Papier zeigt einen praktischen, skalierbaren Weg zur Bereitstellung von LLM-Agenten in hochriskanten Unternehmensumgebungen auf.

Paradigmenwechsel: Es bewegt sich weg von „vollständiger Autonomie" (was riskant ist) und „statischer RPA" (was spröde ist) hin zu inkrementeller, selektiver Autonomie.
Mensch im Loop: Das System behandelt Bediener als „KI-Editoren", die mehrere gleichzeitige Sitzungen überwachen und nur dann eingreifen, wenn das System unsicher ist.
Generalisierbarkeit: Der Ansatz ist auf jeden strukturierte Schnittstellen-Workflow anwendbar, bei dem Interaktionsprotokolle verfügbar sind, und bietet einen Bauplan für sichere, effiziente Automatisierung in regulierten Branchen.

Die Arbeit unterstreicht, dass Sicherheit nicht durch Einschränkung der Modellfähigkeiten erreicht wird, sondern durch die Steuerung seiner Ausführung mittels eines gelernten Critics und eines gestaffelten Bereitstellungsprozesses, der sich kontinuierlich an sich ändernde Geschäftslogik anpasst.