Mensch im Loop
Warum dieser Schritt
Warum ein Mensch in der Schleife
Der Antwortentwurf steht als Text in der Datenbank. Bevor er rausgeht, kommt der menschliche Blick.
Bis hierher hat die Pipeline alles automatisch erledigt: Email empfangen, geparst, klassifiziert, Entitäten und Beziehungen erkannt, in Datenbanken gespeichert, einen Antwortentwurf geschrieben. Was sie noch nicht getan hat: die Antwort wirklich verschickt. Genau hier wartet das System auf eine menschliche Entscheidung. Vier Aspekte zeigen, warum dieser Wartepunkt absichtlich eingebaut ist.
Was automatisch kann und was nicht
Ein Sprachmodell schreibt einen Antwortentwurf, der in den meisten Fällen brauchbar aussieht. Das heißt aber nicht, dass er auch immer die richtige Antwort ist. Manche Mails verlangen eine Entscheidung, die das Modell allein nicht treffen kann: einen Preis nennen, einen Termin zusagen, ein Angebot rauslassen, einen Kunden ablehnen.
Solche Entscheidungen brauchen menschliche Verantwortung. Das System kann den Entwurf vorbereiten und so weit wie möglich personalisieren, aber den letzten Schritt zum tatsächlichen Versenden überlässt es einem Bearbeiter. Diese bewusste Trennung zwischen "Vorbereitung" und "Verantwortung" ist der Sinn des Mensch-im-Loop-Schritts.
Status wartet auf Prüfung als Wartepunkt
Nach dem Entwurfs-Schritt hat die Email den Status awaiting_review. Dieser Status sagt der Bedien-Oberfläche: hier liegt eine Email mit einem fertigen Antwortentwurf, jemand schaue bitte drauf. Solange niemand reagiert, bleibt die Email in diesem Zustand. Der automatische Pipeline-Lauf ist hier zu Ende, ohne menschliche Aktion geht nichts weiter.
Das ist eine wichtige Eigenschaft: das System wartet aktiv. Es schickt nichts versehentlich raus, es vergisst nichts, es verwirft nichts. Eine Email mit einem Entwurf bleibt im Bedien-Bildschirm sichtbar, bis ein Bearbeiter sie bearbeitet hat. Damit ist sichergestellt, dass jeder Entwurf einmal von menschlichen Augen gesehen wird.
Drei mögliche Entscheidungen
Ein Bearbeiter, der einen Entwurf sieht, hat im aktuellen System drei Hauptaktionen: annehmen (der Entwurf wird ohne Änderung zur Versand-Warteschlange geschickt), ablehnen (der Entwurf wird verworfen, optional mit einer Begründung) oder neu erzeugen (das Sprachmodell wird gebeten, einen neuen Entwurf zu schreiben, eventuell mit anderen Eingaben).
Plus zwei seltener verwendete Aktionen: neu klassifizieren (das Sprachmodell wird gebeten, die Kategorie noch einmal zu bestimmen, falls die erste Einordnung falsch wirkt) und eskalieren (die Email wird an einen anderen Zuständigen weitergeleitet). Diese fünf Aktionen bilden zusammen die Mensch-im-Loop-Schnittstelle.
Was im aktuellen Code passiert ist und was noch nicht
An dieser Stelle endet der automatische Teil des email2rag-Systems. Das System bietet die Aktionen über ein Command-Pattern an: jede Aktion ist ein Handler-Klasse mit einer einzigen handle()-Methode, die den Status der Email und des Entwurfs ändert und einen Audit-Log-Eintrag schreibt.
Was noch nicht implementiert ist: eine automatische Eskalation bei zu lange unbearbeiteten Mails, eine Erinnerungs-Funktion für vergessene Entwürfe, eine Statistik darüber, wie viele Entwürfe pro Bearbeiter und Zeitraum durchgewunken oder abgelehnt werden. Solche Erweiterungen wären möglich, sind aber Ausbaustufen, nicht Grundlagen.
Im nächsten Unterkapitel geht es um die konkrete Anzeige in der Bedien-Oberfläche: was sieht ein Bearbeiter, wenn eine Email mit einem Entwurf vor ihm liegt.