Definition in einem Satz
Diseño que reserva a una persona una revisión, decisión o autorización dentro de un proceso automatizado.
Definition: menschliches Eingreifen an einem festgelegten Punkt
Human-in-the-Loop, kurz HITL, ist ein Designmuster, bei dem eine Person an einer festgelegten Phase im Ablauf eines automatisierten Systems beteiligt ist. Sie kann Informationen prüfen, einen Fall einordnen, eine Ausgabe korrigieren, eine Handlung genehmigen oder Feedback geben. Der Begriff beschreibt die Beteiligung eines Menschen am Prozess, legt aber nicht von selbst fest, welche Aufgabe diese Person übernimmt oder wie viel Entscheidungsbefugnis sie behält.
Wenn ein System als HITL bezeichnet wird, heißt das deshalb nicht unbedingt, dass eine Person jede Eingabe und jedes Ergebnis überprüft. Der Eingriff kann auf Zweifelsfälle beschränkt sein, vor einer bestimmten Handlung stattfinden oder Informationen für eine spätere Phase liefern. Um das Design zu verstehen, muss man den Eingriffspunkt, die verfügbaren Handlungsmöglichkeiten und den Umgang mit der menschlichen Entscheidung konkret benennen.
Einführende Definitionen beschreiben HITL als menschliche Beteiligung am Lebenszyklus des maschinellen Lernens oder am Betrieb, an der Überwachung und an der Entscheidungsfindung eines Prozesses. Das sind allgemeine Beschreibungen, keine einheitliche technische Spezifikation und keine Garantie für die Qualität des Systems.
An welchen Stellen eine Person eingreifen kann
Der Eingriff kann in unterschiedlichen Phasen stattfinden. Bei der Prüfung von Eingaben kontrolliert oder ergänzt die Person Daten, bevor das System sie verarbeitet. Bei der Prüfung von Ausgaben bewertet sie eine Empfehlung oder Klassifizierung, bevor diese verwendet wird. Bei einer vorherigen Genehmigung entscheidet sie, ob eine Handlung ausgeführt wird. Während des Betriebs kann sie den Prozess beobachten und bei Ausnahmen eingreifen. Im Nachhinein kann ihr Feedback dazu dienen, Regeln zu überprüfen oder spätere Verbesserungen vorzubereiten.
Diese Funktionen sind nicht austauschbar. Eine Antwort zu prüfen bedeutet nicht automatisch, sie blockieren zu können. Eine Zahlung zu genehmigen ist nicht dasselbe, wie die Extraktion ihrer Daten zu überprüfen. Und eine Benachrichtigung zu erhalten heißt nicht, dass genügend Zeit und Handlungsspielraum für einen Eingriff vorhanden sind. Ein klares Design trennt die Aufgaben der Person von den automatisierten Aufgaben und legt fest, welches Ergebnis jeweils daraus folgt.
Auch der Umgang mit dem Fall, dass die Person nicht verfügbar ist, nicht antwortet oder der Einschätzung des Systems widerspricht, muss festgelegt werden. Läuft der Vorgang nach einer bestimmten Frist automatisch weiter, gehört diese Regel zum Design. Wird er angehalten, muss klar sein, wer die Blockade auflöst. Ohne solche Festlegungen bleibt eine wichtige praktische Frage des HITL-Ansatzes unbeantwortet.
Mögliche Entscheidungspunkte im Überblick
| Eingriffspunkt | Mögliche Aufgabe der Person | Was festgelegt werden sollte |
|---|---|---|
| Vor der Verarbeitung | Eine Eingabe prüfen oder ergänzen | Welche Daten sichtbar sind und welche Änderungen gespeichert werden können |
| Vor der Verwendung einer Ausgabe | Eine Empfehlung korrigieren, annehmen oder ablehnen | Ob das System auf die Entscheidung wartet oder den Vorgang fortsetzt |
| Vor der Ausführung einer Handlung | Genehmigen, ablehnen oder eine zusätzliche Prüfung anfordern | Welche Befugnisse bestehen und wie die Entscheidung dokumentiert wird |
| Bei einer Ausnahme während des Betriebs | Einen Fall untersuchen, anhalten oder eskalieren | Welche Signale den Eingriff auslösen und wer reagiert |
| Nach dem Ergebnis | Feedback zum Fall geben | Ob das Feedback eine Regel, einen Prozess oder ein Modell verändert |
Wie der Eingriff abläuft
Ein HITL-Ablauf sollte sich vom Anfang bis zum Ende beschreiben lassen. Zunächst erkennt das System den Fall, der menschliche Beteiligung erfordert – oder es legt, falls dies die gewählte Vorgehensweise ist, alle Fälle vor. Danach stellt es der Person die Informationen zur Verfügung, die sie für die Beurteilung benötigt. Die Person erhält eine oder mehrere konkrete Handlungsmöglichkeiten. Schließlich setzt das System die Entscheidung gemäß zuvor festgelegten Regeln um, dokumentiert sie oder leitet sie weiter.
Die Benutzeroberfläche und der Kontext sind ebenso wichtig wie die Tatsache, dass es überhaupt einen Prüfschritt gibt. Wird nur ein Wert angezeigt, ohne seine Grenzen offenzulegen, fehlen relevante Daten oder bleibt unklar, ob es sich um eine Empfehlung oder um eine bereits getroffene Entscheidung handelt, kann die Person den Fall möglicherweise nicht angemessen beurteilen. Das Design sollte verständlich machen, was vorgeschlagen wird, was noch offen ist und welche Folgen eine Annahme oder Ablehnung hat.
Eine technische Implementierung kann einen Ablauf anhalten, bis eine menschliche Entscheidung eingeht. Die Dokumentation von LangChain beschreibt zum Beispiel einen Mechanismus, der Werkzeugaufrufe unterbrechen und auf eine Entscheidung durch einen Menschen warten kann. Das veranschaulicht eine konkrete Möglichkeit, eine Pause einzubauen. Es begründet weder eine allgemeingültige Definition von HITL noch belegt es, dass eine solche Prüfung für jeden Prozess angemessen ist.
Zu dokumentierender Ablauf
- 01Festlegen, welches Ereignis den Eingriff auslöst: jeder Fall, eine Ausnahme oder ein bestimmter Schwellenwert.
- 02Angeben, welche Informationen die Person erhält und welche davon fehlen oder unsicher sein können.
- 03Die zulässigen Handlungen aufführen: annehmen, korrigieren, ablehnen, eskalieren, anhalten oder rückgängig machen.
- 04Erklären, was das System nach jeder Handlung tut und was geschieht, wenn keine Antwort eingeht.
- 05Dokumentieren, wer die Entscheidung wann getroffen hat und welche Informationen dabei verfügbar waren.
Drei Anwendungsbeispiele
Die folgenden Szenarien sind Beispiele für mögliche Designs und keine Aussagen darüber, wie ein bestimmter Dienst funktioniert. In jedem Beispiel werden die automatisierte Aufgabe und die Entscheidung, die bei einer Person verbleibt, getrennt beschrieben. So lässt sich beurteilen, ob der Eingriff tatsächlich wirksam ist oder ob lediglich die formale Möglichkeit besteht, einen Fall zu eskalieren.
Ein Beispiel macht den HITL-Ansatz nicht automatisch sicher oder geeignet. Entscheidend sind unter anderem die verfügbaren Informationen, der tatsächliche Entscheidungsspielraum und die Frage, was passiert, wenn ein Fall nicht rechtzeitig bearbeitet wird.
Verwandte Konzepte, die auseinanderzuhalten sind
HITL wird als weit gefasster Begriff für die menschliche Beteiligung an einem Prozess verwendet. Der Begriff sollte nicht automatisch mit menschlicher Aufsicht im regulatorischen Sinn gleichgesetzt werden. Je nach Kontext und anwendbarem Regelwerk kann Aufsicht bestimmten Anforderungen unterliegen. Die hier berücksichtigten Quellen reichen nicht aus, um konkrete rechtliche Pflichten zu beschreiben. Dieser Artikel erläutert daher ein Designmuster und trifft keine Aussage über die Einhaltung von Vorschriften.
Auch die Begriffe *human-on-the-loop* und *human-out-of-the-loop* kommen vor. *Human-on-the-loop* beschreibt eine Person, die den Betrieb beobachtet und eingreifen kann. *Human-out-of-the-loop* bezeichnet einen Prozess, der in der betreffenden Phase ohne individuellen menschlichen Eingriff abläuft. Als grobe Gegenüberstellung sind diese Begriffe hilfreich, ihre Verwendung ist jedoch nicht einheitlich. In einer konkreten Implementierung ist es genauer, Handlungen, Befugnisse und Zeitpunkt des Eingriffs zu beschreiben, statt sich allein auf die Bezeichnung des Musters zu verlassen.
Ein Eingriff im laufenden Betrieb ist vom Feedback zu unterscheiden, das zur Entwicklung oder Anpassung eines Modells verwendet wird. Bei RLHF – bestärkendem Lernen aus menschlichem Feedback – wird menschliche Beteiligung in einem Trainings- oder Anpassungsprozess genutzt. Dass Personen in dieser Phase Feedback gegeben haben, bedeutet nicht, dass während des Betriebs jede Entscheidung des Systems von einem Menschen überprüft wird. Umgekehrt kann eine Person im Betrieb eingreifen, ohne dass ihre Entscheidung zum Training eines Modells verwendet wird.
Auch aktives Lernen ist ein anderes Konzept: Allgemein bezeichnet es eine Strategie, Beispiele auszuwählen, bei denen eine Kennzeichnung oder Prüfung besonders hilfreich sein könnte. An dieser Auswahl können Menschen beteiligt sein; daraus folgt jedoch nicht, dass sie befugt sind, eine operative Handlung des Systems zu genehmigen. Die für diesen Artikel geprüften Quellen enthalten keinen ausführlichen technischen Vergleich von aktivem Lernen und RLHF. Die folgenden Abgrenzungen sind daher als konzeptionelle Orientierung und nicht als vollständige Taxonomie zu verstehen.
Menschliche Beteiligung ist nicht gleich menschliche Funktion
| Konzept | Welche Frage beantwortet es? | Was sich daraus allein nicht schließen lässt |
|---|---|---|
| HITL | An welchem Punkt wirkt eine Person mit? | Dass sie jeden Fall prüft oder über ausreichende Befugnisse verfügt |
| Menschliche Aufsicht | Wie und unter welchen Bedingungen wird ein System beaufsichtigt? | Dass in allen Kontexten dasselbe Modell gilt |
| RLHF | Wird menschliches Feedback in einer Trainings- oder Anpassungsphase verwendet? | Dass jede Ausgabe im laufenden Betrieb menschlich geprüft wird |
| Aktives Lernen | Welche Beispiele werden zur Prüfung oder Kennzeichnung ausgewählt? | Dass die Person Handlungen des Systems genehmigt |
Grenzen und häufige Fehler
Ein menschlicher Prüfschritt garantiert für sich genommen weder Sicherheit, Genauigkeit, Wirksamkeit noch die Einhaltung einer Vorschrift. Um ein Problem zu erkennen, benötigt eine Person relevante Informationen, ausreichend Zeit, passende Kenntnisse und die Befugnis, zu handeln. Fehlt eines dieser Elemente, kann der Eingriff zwar im Prozessdiagramm vorkommen, aber als wirksame Kontrolle versagen.
Ein mögliches Designrisiko besteht in der Annahme, die Person werde jeden Fehler erkennen, nur weil sie eine Empfehlung prüfen kann. Ihr kann der Kontext fehlen, sie kann zu viele Fälle gleichzeitig bearbeiten oder keine eindeutige Möglichkeit haben, die Empfehlung abzulehnen. Ebenso kann Druck bestehen, die automatisierte Ausgabe zu übernehmen, oder ein Eskalationsweg kann ins Leere führen. Das sind mögliche Grenzen, die für den jeweiligen Einsatzbereich geprüft werden müssen. Die herangezogenen Quellen messen weder, wie häufig sie auftreten, noch, wie stark sie sich auswirken.
Ein weiterer Fehler ist, „menschliche Prüfung“ als pauschales Etikett zu verwenden, ohne ihren Umfang anzugeben. „Eine Person ist in den Kreislauf eingebunden“ lässt offen, ob alle Fälle, nur Ausnahmen oder lediglich eine Stichprobe geprüft werden; ob die Prüfung vor oder nach der Handlung stattfindet; und wer für die Entscheidung verantwortlich ist. Ebenso bleibt unklar, wie eine fehlerhafte Ausgabe korrigiert werden kann und ob sich eine Handlung rückgängig machen lässt.
Schließlich sollte Aufsicht nicht mit Genehmigung verwechselt werden. Eine Person, die einen Bildschirm beobachten, eine Handlung aber nicht anhalten kann, hat eine andere Funktion als jemand, dessen Genehmigung erforderlich ist. Und eine Person, die für eine Eskalation erreichbar sein könnte, ist nicht dasselbe wie eine zugewiesene, informierte und entscheidungsbefugte Person, die den Fall tatsächlich lösen kann.
Praktische Kriterien zur Beschreibung eines HITL-Designs
Beschreiben Sie bei der Bewertung oder Dokumentation eines Systems genau, an welcher Stelle eine Person eingreift und welches Ereignis den Eingriff auslöst. Geben Sie an, ob die Beteiligung verpflichtend, auf bestimmte Fälle beschränkt oder erst nach einer Handlung vorgesehen ist. Werden nur Ausnahmen geprüft, erklären Sie, wie diese erkannt werden und welche Fälle möglicherweise nicht in die Prüfung gelangen.
Legen Sie dar, welche Informationen die Person sieht, welche Handlungen sie ausführen kann und welche Befugnisse dahinterstehen. Für eine Empfehlung, die angenommen, korrigiert oder abgelehnt werden kann, sind andere Kontrollen erforderlich als für eine Meldung, die lediglich bestätigt werden kann. Nennen Sie außerdem, wer den Prozess anhalten, eine zweite Prüfung anfordern oder eine Handlung rückgängig machen darf.
Beschreiben Sie, was geschieht, wenn die Person nicht antwortet, nicht verfügbar ist oder dem System widerspricht. Legen Sie Antwortzeiten fest, die zum jeweiligen Prozess passen, statt anzunehmen, eine einzige Frist sei für alle Kontexte geeignet. Dokumentieren Sie Entscheidungen und Änderungen so, dass der Ablauf nachvollzogen werden kann: Wer hat eingegriffen, auf Grundlage welcher Informationen und mit welchem Ergebnis?
Eine brauchbare Beschreibung beantwortet damit sechs Fragen: Wo greift die Person ein? Was sieht sie? Was entscheidet sie? Was darf sie ändern? Was geschieht bei einer Ausnahme oder ausbleibenden Antwort? Und wie wird geprüft, ob der Mechanismus wie beabsichtigt funktioniert? Diese Fragen machen Verantwortlichkeiten sichtbar, die das Etikett allein offenlässt.
Kurze Prüfliste
- 01Eingriffspunkt: In welcher Phase des Prozesses findet die Beteiligung statt?
- 02Kontext: Welche Informationen und Einschränkungen werden der prüfenden Person angezeigt?
- 03Befugnisse: Kann sie korrigieren, ablehnen, genehmigen, anhalten oder rückgängig machen?
- 04Ausnahmen: Was passiert bei einer Abweichung oder wenn keine Antwort eingeht?
- 05Nachvollziehbarkeit: Werden die Entscheidung und ihr Ergebnis festgehalten?
- 06Bewertung: Welche Belege würden zeigen, ob die Prüfung ihren Zweck erfüllt?
Umfang der Quellen
Die für diesen Artikel geprüften Quellen umfassen allgemeine Erläuterungen zu HITL, eine institutionelle Veröffentlichung über Eingriffsmechanismen und die technische Dokumentation eines konkreten Mechanismus, der Werkzeugaufrufe unterbricht, bis eine menschliche Entscheidung vorliegt. Die Quellen haben unterschiedliche Reichweiten: Eine einführende Definition ist keine Rechtsvorschrift, und die Dokumentation eines Produkts legt nicht fest, wie alle Systeme gestaltet werden sollten.
Es wurden keine regulatorischen Quellen vorgelegt, die eine Zusammenfassung konkreter rechtlicher Pflichten ermöglichen würden. Ebenso liegt keine Evidenz vor, mit der sich die Wirksamkeit der hypothetischen Beispiele oder die Häufigkeit der beschriebenen Risiken messen ließe. Der Artikel behauptet daher weder, dass ein HITL-Design regulatorische Anforderungen erfüllt, noch, dass menschliche Beteiligung allein bessere Ergebnisse hervorbringt. Die Kategorien und Beispiele sollen helfen, Designfragen zu formulieren, die anhand geeigneter Evidenz für den jeweiligen Kontext beantwortet werden müssen.
