Hallo zusammen, hier ist Alex von agntai.net. Wir sind Ende März 2026, und ich habe mit einem speziellen Problem zu kämpfen, das ich denke, dass viele von euch, die mit KI-Agenten arbeiten, wahrscheinlich ebenfalls haben oder sehr bald haben werden: Wie kann man verhindern, dass eure autonomen Agenten völlig aus dem Ruder laufen, wenn sie auf eine wirklich unerwartete Eingabe stoßen? Es geht nicht um kleinere Abweichungen; ich rede von der Art von Eingabe, bei der ein Mensch sich am Kopf kratzen würde und sagen würde: „Moment mal, was?“
Ich nenne das das Problem der „Reality Check Architektur“. Es geht darum, Agenten zu bauen, die genügend Intelligenz besitzen, um zu wissen, wann sie etwas nicht wissen, und noch wichtiger, genügend Intelligenz, um Hilfe zu bitten oder ihre Herangehensweise grundlegend neu zu bewerten, anstatt einfach sicher zu halluzinieren oder einen unsinnigen Plan auszuführen. Wir haben alle die lustigen (und manchmal beängstigenden) Beispiele gesehen, wie generative KI verrückt wird. Wenn dies einen Agenten antreibt, der Entscheidungen in der realen Welt trifft, hört der Spaß ziemlich schnell auf.
Das Problem: Agenten im Wilden Westen der Daten
Meine letzten Kopfschmerzen stammen von einem Projekt, bei dem wir Agenten einsetzen, um bei einer etwas chaotischen Echtzeitanalyse von Daten zu helfen. Denkt an einen Agenten, der einen Datenstrom von Sensoren beobachtet, versucht, Anomalien zu identifizieren und dann Maßnahmen zu empfehlen. Das Problem tritt nicht auf, wenn die Daten sauber oder sogar moderat verrauscht sind. Das Problem tritt auf, wenn ein Sensor komplett ausfällt und einen Strom von `NaN`s sendet, oder wenn ein Datenstrom aus einer neuen unerwarteten Quelle plötzlich mit einem völlig anderen Muster erscheint. Oder, mein persönlicher Favorit, wenn ein menschlicher Operator manuell um ein System herum arbeitet und etwas so Merkwürdiges eingibt, dass keine Trainingsdaten den Agenten darauf vorbereiten konnten.
Die meisten unserer Agenten sind mit einer ziemlich standardmäßigen Schleife aufgebaut: wahrnehmen, argumentieren, handeln. Die Wahrnehmungsschicht kann einige ML-Modelle für die Klassifizierung oder Merkmalsextraktion verwenden. Die Argumentationsschicht beinhaltet oft eine Form der Planung oder Entscheidungsfindung, manchmal unterstützt durch ein anderes LLM. Die Handlungsschicht führt Befehle aus. Das funktioniert sehr gut für 90 % der Fälle. Aber diese 10 %… da wird es interessant.
Ich erinnere mich an einen spezifischen Vorfall letzten Monat. Wir hatten einen Agenten, der ein Netzwerk auf der Suche nach ungewöhnlichen Verkehrsmustern überwachte. Ein neues experimentelles Diagnosetool wurde von der IT-Abteilung bereitgestellt – vollständig angekündigt an die Entwickler unseres Agenten (klassisch, oder?). Dieses Tool begann, einen Strom von sehr spezifischen und nicht standardmäßigen UDP-Paketen zu generieren. Unser Agent, der auf „normalen“ und „schädlichen“ Mustern trainiert wurde, konnte diesen neuen Verkehr nicht klassifizieren. Anstatt ihn als „nicht klassifiziert“ oder „unbekannt“ zu melden, begann er, ihn mit Überzeugung als eine geringfügige „Ping Flood“-Attacke zu klassifizieren und empfahl geringfügige Anpassungen der Firewall-Regeln. Es war nicht gefährlich, aber absolut falsch, und es mobilisierte Ressourcen, um etwas zu untersuchen, das kein Problem war. Mein sofortiger Gedanke war: „Wie integriere ich einen Mechanismus, der es dem Agenten ermöglicht zu sagen: ‚Moment mal, das passt in keine bekannte Kategorie. Ich brauche diesbezüglich menschliches Eingreifen?‘“
Über Vertrauen-Scores hinaus: Ein „Huh ?“-Modul bauen
Mein erster Gedanke war: „Nutzt einfach die Vertrauen-Scores der ML-Modelle!“ Und ja, das ist ein guter erster Schritt. Wenn euer Klassifizierungsmodell für die Sensordaten nur 30 % zuversichtlich in Bezug auf einen bestimmten Wert ist, ist das ein Alarmzeichen. Aber die Vertrauen-Scores erzählen nicht immer die ganze Geschichte. Ein Modell kann sehr zuversichtlich bezüglich einer falschen Klassifizierung sein, wenn die Eingabe hoch genug außerhalb der Verteilung liegt. Es ist wie zu fragen, ob jemand ein Schnabeltier identifizieren kann, wenn er nur Säugetiere und Vögel gesehen hat; er könnte mit Überzeugung „seltsamer Vogel“ oder „haariger Fisch“ sagen, weil das das Nächste ist, was er kennt, obwohl es grundsätzlich falsch ist.
Was wir brauchen, ist ein Modul für „Reality Check“ oder „Anomaliedetektion für den Agentenzustand“. Es geht nicht nur darum, Anomalien in den Eingabedaten zu erkennen, sondern auch Anomalien im *Verständnis* oder den *geplanten Aktionen* des Agenten im Hinblick auf den aktuellen Kontext.
Drei Säulen der Reality Check Architektur
Ich experimentiere mit einer Architektur, die drei Hauptkomponenten umfasst, um dies anzugehen:
- Validierung von Eingaben & Erkennung neuer Anomalien: Dies geschieht auf der allerersten Wahrnehmungsebene.
- Überprüfung der Kontextkonsistenz: Dies bewertet den internen Zustand des Agenten und die geplanten Maßnahmen im Vergleich zum bekannten Kontext.
- Human in the Loop (HITL): Ein solider Mechanismus für den Moment, in dem der Agent wirklich feststeckt.
Säule 1: Validierung von Eingaben & Erkennung neuer Anomalien
Hier fangen wir die wirklich merkwürdigen Eingaben ein. Bevor komplexe Verarbeitung erfolgt, durchlaufen die Rohdaten einen Konsistenzcheck. Es geht nicht nur um Datentypen; es geht darum, ob die Daten *scheinbar* etwas entsprechen, das der Agent bereits zuvor gesehen hat oder für das er entworfen wurde.
Praktisches Beispiel: Semantische Filterung von Eingaben
Nehmen wir an, euer Agent erwartet strukturierte JSON-Daten, die die Zustände von Geräten darstellen. Wenn er plötzlich einen Blob unstrukturierter Texte erhält, sollte er dies sofort melden. Über die strikte Schema-Validierung hinaus können wir einfache statistische Methoden oder sogar leichte Autoencoder zur Neuheitserkennung verwenden.
import pandas as pd
from sklearn.ensemble import IsolationForest
import numpy as np
class NoveltyDetector:
def __init__(self, data_sample, contamination=0.01):
# Trainiere ein Isolation Forest auf 'normalen' Daten
self.model = IsolationForest(contamination=contamination, random_state=42)
self.model.fit(data_sample)
def detect(self, new_data_point):
# Vorhersage: -1 für Anomalien, 1 für Inlier
prediction = self.model.predict(new_data_point.reshape(1, -1))
return prediction[0] == -1 # Wahr, wenn neu/anomal
# Beispielverwendung:
# Nehmen wir an, 'normal_sensor_readings' ist ein DataFrame typischer Sensordaten (z.B. Temperatur, Druck, Luftfeuchtigkeit)
# Zur Vereinfachung erstellen wir fiktive Normaldaten
normal_data = pd.DataFrame(np.random.rand(100, 3) * 100, columns=['temp', 'pressure', 'humidity'])
detector = NoveltyDetector(normal_data)
# Testen mit einem normalen Datenpunkt
normal_point = np.array([50, 50, 50])
print(f"Ist der Punkt {normal_point} neu? {detector.detect(normal_point)}") # Erwartet: Falsch
# Testen mit einem anormalen Datenpunkt (z.B. sehr hohe Temperatur)
anomalous_point = np.array([1000, 50, 50]) # Temperatur weit außerhalb des Rahmens
print(f"Ist der Punkt {anomalous_point} neu? {detector.detect(anomalous_point)}") # Erwartet: Wahr
# Testen mit einer völlig anderen Datenstruktur (das würde fehlschlagen, wenn nicht vorverarbeitet)
# Für einen echten Agenten wollt ihr die Schemaunverträglichkeiten *vor* dem.
# Aber wenn es numerisch ist, kann IsolationForest es immer noch melden.
weird_point = np.array([-1000, -2000, -3000])
print(f"Ist der Punkt {weird_point} neu? {detector.detect(weird_point)}") # Erwartet: Wahr
Dieses Snippet zeigt ein einfaches Isolation Forest für numerische Daten. Für komplexere und multimodale Eingaben könntet ihr Techniken wie One-Class SVMs oder sogar vortrainierte Repräsentationsmodelle (wie einen kleinen Autoencoder) verwenden, um Eingaben zu erkennen, die außerhalb des gelernten Manifolds der „normalen“ Daten liegen.
Säule 2: Überprüfung der Kontextkonsistenz
Hier glänzt das „Huh ?“-Modul wirklich. Nachdem ein Agent die Eingabe verarbeitet und einen Plan formuliert hat, müssen wir fragen: „Macht das im Gesamtzusammenhang Sinn?“ Das ist schwieriger, als nur die Eingabedaten zu überprüfen. Es beinhaltet die Bewertung des internen Zustands des Agenten, seiner vorgeschlagenen Aktion und wie dies mit seinen Zielen und der bekannten Umgebung übereinstimmt.
Beispiel: Erkennung von Inkonsistenzen Zustand-Aktionen-Ziel
Betrachten wir einen Agenten, dessen Ziel es ist, die CPU-Nutzung eines Servers unter 70 % zu halten. Wenn der Agent die CPU bei 65 % wahrnimmt und seine vorgeschlagene Aktion darin besteht, kritische Dienste abzuschalten, ist das ein massives Alarmzeichen. Die Aktion ist inkonsistent mit dem Ziel und dem aktuellen Zustand.
Dies kann mit einem Satz von vordefinierten Regeln oder, für komplexere Szenarien, einem anderen kleinen spezialisierten ML-Modell (ein „Kritiker“- oder „Überprüfer“-Modell) umgesetzt werden, das speziell auf Beispiele von konsistenten vs. inkonsistenten Zustand-Aktion-Paaren trainiert ist. Sie lehren im Grunde, was im operativen Bereich des Agents „Sinn macht“.
# Vereinfachte Regelbasierte Kontextuelle Überprüfung
class ContextualVerifier:
def __init__(self, operational_rules):
self.rules = operational_rules # Liste von (condition_func, consequence_func, error_message)
def verify_action(self, current_state, proposed_action):
for condition, consequence, error_msg in self.rules:
if condition(current_state, proposed_action):
# Wenn die Bedingung (z.B. "hohe CPU") erfüllt ist,
# überprüfen, ob die Konsequenz (z.B. "die Aktion sollte die Erhöhung sein") ebenfalls erfüllt ist.
if not consequence(current_state, proposed_action):
return False, error_msg
return True, "Die Aktion scheint konsistent zu sein."
# Einige Regeln für einen Server-Management-Agenten definieren
def rule_cpu_low_but_scaling_down_condition(state, action):
return state['cpu_util'] < 0.30 # Wenn die CPU niedrig ist
def rule_cpu_low_but_scaling_down_consequence(state, action):
return action['type'] != 'scale_down_services' # Sollte die Dienste nicht reduzieren
def rule_cpu_high_no_scaling_up_condition(state, action):
return state['cpu_util'] > 0.85 # Wenn die CPU hoch ist
def rule_cpu_high_no_scaling_up_consequence(state, action):
return action['type'] == 'scale_up_services' or action['type'] == 'optimize_processes' # Sollte erhöhen oder optimieren
operational_rules = [
(rule_cpu_low_but_scaling_down_condition, rule_cpu_low_but_scaling_down_consequence, "Fehler: Niedrige CPU, aber der Agent schlägt vor, die Dienste zu reduzieren!"),
(rule_cpu_high_no_scaling_up_condition, rule_cpu_high_no_scaling_up_consequence, "Fehler: Hohe CPU, aber der Agent schlägt keine Erhöhung oder Optimierung vor!")
]
verifier = ContextualVerifier(operational_rules)
# Testfälle
state1 = {'cpu_util': 0.25, 'mem_util': 0.4}
action1 = {'type': 'scale_down_services', 'target': 'web_app'}
is_consistent, msg = verifier.verify_action(state1, action1)
print(f"Test 1 : {msg} Konsistent : {is_consistent}") # Erwartet: Fehler, Konsistent : False
state2 = {'cpu_util': 0.90, 'mem_util': 0.7}
action2 = {'type': 'monitor_logs', 'severity': 'info'}
is_consistent, msg = verifier.verify_action(state2, action2)
print(f"Test 2 : {msg} Konsistent : {is_consistent}") # Erwartet: Fehler, Konsistent : False
state3 = {'cpu_util': 0.50, 'mem_util': 0.6}
action3 = {'type': 'log_event', 'message': 'Alles ist nominal'}
is_consistent, msg = verifier.verify_action(state3, action3)
print(f"Test 3 : {msg} Konsistent : {is_consistent}") # Erwartet: Die Aktion scheint konsistent zu sein. Konsistent : True
Dieser regelbasierte Ansatz ist einfach, aber effektiv für kritische Überprüfungen. Für differenziertere Konsistenz könnte ein kleines spezialisiertes LLM angeregt werden, eine vorgeschlagene Aktion gemäß dem vollständigen Zustand und den Zielen zu „kritisieren“, indem es fragt: „Folgt diese Aktion logisch aus dem aktuellen Zustand und den erklärten Zielen?“
Säule 3: Eskalation mit dem Menschen in der Schleife (HITL)
Wenn der Eingangnovitätsdetektor und der kontextuelle Konsistenzprüfer ein Problem melden, sollte der Agent nicht eigenständig fortfahren. Dies ist der Moment für HITL. Das Ziel hier ist nicht, den Agenten zu ersetzen, sondern ihm ein Sicherheitsnetz und einen Mechanismus zu bieten, um aus wirklich neuen Situationen zu lernen.
Meine Erfahrung hat gezeigt, dass ein gut gestaltetes HITL-System nicht einfach ein „Notfallknopf“ ist. Es sollte Folgendes bieten:
- Klarer Kontext: Der Agent sollte *warum* er eskaliert, welche Daten er sieht und was seine vorgeschlagene (aber blockierte) Aktion war, präsentieren.
- Nutzenbare Optionen: Anstatt einfach zu sagen „Ich weiß nicht“, sollte der Agent idealerweise einige Interpretationen oder potenzielle Aktionen präsentieren, auch wenn er sich nicht sicher ist, sodass der Mensch auswählen oder korrigieren kann.
- Feedbackprozess: Entscheidend ist, dass die Entscheidung oder Eingabe des Menschen *zurück* in den Lernprozess des Agenten eingespeist werden *muss*, entweder direkt (Anpassung eines kleinen Modells) oder indirekt (Hinzufügen zu einer Wissensdatenbank / Regelset).
Hier lernt der Agent, zwischen „Ich bin mir nicht sicher, bitte bestätigen“ und „Das übersteigt mein Verständnis vollkommen, ich brauche Hilfe“ zu unterscheiden.
Mein Feedback und was ich als Nächstes tun werde
Den Aufbau wirklich solider Agenten erfordert, über die Leistungsoptimierung für Durchschnittsfälle hinauszugehen. Wir müssen explizit für Randfälle, Unbekannte und „Was wäre, wenn“-Szenarien entwerfen. Mein Weg mit der Reality Verification Architecture hat es mir ermöglicht, einige wichtige Lektionen zu ziehen:
- Vertraue nicht, überprüfe: Jeder kritische Schritt in der Schleife des Agenten sollte einen Überprüfungsmechanismus haben, auch wenn er einfach ist.
- Überlappe deine Abwehrmechanismen: Ein einzelner Vertrauensscore ist nicht ausreichend. Kombiniere die Eingangsnovitätserkennung mit kontextuellen Konsistenzprüfungen.
- Akzeptiere die Unsicherheit: Entwerfe Agenten, die explizit erkennen, wenn sie außerhalb ihrer Komfortzone operieren. Das ist kein Scheitern; das ist eine Funktion.
- Nutze HITL als Lernchance: Jede menschliche Intervention ist eine Gelegenheit, deinen Agenten klüger und widerstandsfähiger zu machen. Stelle sicher, dass es einen klaren Feedbackprozess gibt.
- Beginne einfach: Du benötigst nicht für jede Überprüfung komplexe Deep-Learning-Modelle. Einfache Regeln und statistische Methoden können viele gängige Probleme lösen. Erhöhe die Komplexität nur dort, wo es notwendig ist.
Für die Zukunft konzentriere ich mich darauf, diese „Reality Verification“-Module tiefer in unsere Agentenrahmen zu integrieren. Wir experimentieren mit kleinen domänenspezifischen LLMs, um Erklärungen bei HITL-Eskalationen zu generieren und alternative Interpretationen vorzuschlagen, wenn die Hauptmodelle versagen. Das Ziel ist, Agenten zu bauen, die nicht nur intelligent, sondern auch sinnvoll und sicher sind, insbesondere wenn sie mit der chaotischen und unvorhersehbaren Realität der wirklichen Welt konfrontiert werden.
Was sind deine Erfahrungen mit Agenten, die unberechenbar handeln? Wie integrierst du Konsistenzprüfungen? Lass es mich in den Kommentaren unten wissen! Und wenn du interessante Beispiele von „Hä?“ Modulen in Aktion hast, würde ich gerne davon hören.
🕒 Published: