Arbiter: Detecting Interference in LLM Agent System Prompts

Die Arbeit stellt Arbiter vor, ein Framework zur Erkennung von Interferenzmustern in Systemprompts von LLM-Coding-Agenten, das durch formale Regeln und Multi-Modell-Analysen bei drei großen Anbietern zahlreiche Schwachstellen aufdeckt und zeigt, dass die Prompt-Architektur die Fehlerklassen, nicht aber deren Schweregrad bestimmt.

Tony Mason

Veröffentlicht Wed, 11 Ma
📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

Each language version is independently generated for its own context, not a direct translation.

Stellen Sie sich vor, Sie stellen einen hochintelligenten, aber etwas verwirrten Assistenten ein, der für Sie programmieren soll. Damit dieser Assistent weiß, was er tun darf und was nicht, geben Sie ihm eine riesige Anleitung (einen sogenannten "System-Prompt"). Diese Anleitung ist wie eine Verfassung für den Roboter: Sie sagt ihm, wie er sich verhalten soll, welche Werkzeuge er benutzen darf und welche Regeln er einhalten muss.

Das Problem? Diese Anleitungen sind oft chaotisch, widersprüchlich und wurden von verschiedenen Teams geschrieben, ohne dass jemand sie auf logische Fehler geprüft hat. Es ist, als würde man einem Koch sagen: "Koche immer mit Salz!" und zwei Seiten später: "Verwende niemals Salz!", ohne dass der Koch merkt, dass er in eine Sackgasse läuft. Er entscheidet einfach intuitiv, was er gerade tut – und das kann schiefgehen.

Hier kommt Arbiter ins Spiel.

Was ist Arbiter?

Stellen Sie sich Arbiter wie einen super-scharfsinnigen Detektiv-Team vor, das keine eigene Meinung hat, sondern nur die Anleitung des Assistenten genau unter die Lupe nimmt. Das Team besteht aus zwei Arten von Ermittlern:

  1. Die "Archäologen" (Gezielte Suche):
    Diese gehen die Anleitung Zeile für Zeile durch und suchen nach bekannten Mustern von Fehlern. Sie fragen sich: "Hey, steht hier 'Tun' und dort 'Nicht tun'?" oder "Sind diese beiden Abschnitte doppelt gemoppelt?". Sie sind wie ein Lektor, der nach Rechtschreibfehlern sucht, aber für logische Widersprüche.

  2. Die "Entdecker" (Ungezielte Suche):
    Diese sind etwas verrückter. Sie bekommen den Auftrag: "Lies diese Anleitung einfach genau durch und sag mir, was dir komisch oder interessant vorkommt." Sie suchen nicht nach spezifischen Fehlern, sondern lassen sich von ihrer Intuition leiten. Das Besondere: Sie arbeiten mit verschiedenen KI-Modellen (wie Claude, Gemini, Codex). Ein Modell denkt vielleicht an Sicherheitslücken, ein anderes an Geldverschwendung, ein drittes an verwirrende Identitäten. So decken sie Dinge auf, die ein einzelner Prüfer nie gesehen hätte.

Was haben sie herausgefunden?

Die Forscher haben die Anleitungen von drei großen KI-Assistenten (von Anthropic, OpenAI und Google) untersucht und dabei drei verschiedene "Architektur-Typen" entdeckt, die jeweils zu unterschiedlichen Problemen führen:

  • Der "Monolith" (Ein riesiger Block):

    • Vergleich: Ein riesiges, altes Haus, in dem jeder Raum von einer anderen Familie renoviert wurde, ohne dass sie miteinander gesprochen haben.
    • Problem: Da alles in einem einzigen riesigen Dokument steht, entstehen Widersprüche an den Grenzen zwischen den Abteilungen. Zum Beispiel sagt eine Abteilung: "Benutze immer diese Aufgabe-Liste!" und eine andere: "Benutze diese Liste NIEMALS beim Speichern von Code."
    • Ergebnis: Viele kleine, aber kritische Widersprüche.
  • Der "Flache" (Einfach und kurz):

    • Vergleich: Eine einfache Checkliste auf einem Zettel.
    • Problem: Da die Anleitung so kurz ist, gibt es kaum Widersprüche. Aber dafür fehlt ihr auch die Tiefe. Sie ist konsistent, aber vielleicht zu simpel für komplexe Aufgaben.
  • Der "Modulare" (Aus Bausteinen zusammengesetzt):

    • Vergleich: Ein Lego-Haus, bei dem jedes Teil perfekt funktioniert, aber die Verbindungen zwischen den Teilen nicht richtig geplant sind.
    • Problem: Die einzelnen Teile (Module) sind gut, aber wenn sie zusammengefügt werden, fallen Dinge durch das Raster.
    • Ein echtes Beispiel: Google hatte eine Anleitung, die sagte: "Speichere wichtige Erinnerungen des Benutzers." Aber eine andere Regel sagte: "Wenn der Speicher voll wird, komprimiere die Geschichte und lösche alles, was nicht im XML-Format steht." Da die "Erinnerungen" nicht im XML-Format waren, wurden sie automatisch gelöscht, sobald der Speicher voll wurde. Ein riesiger Fehler, der in den Verbindungen zwischen den Modulen lauerte.

Warum ist das wichtig?

Bisher haben die Firmen diese Anleitungen wie magische Zaubersprüche behandelt, die man einfach hinschreibt. Sie haben keine Tests gemacht, keine Fehlerlisten geführt und keine "Sicherheitschecks" durchgeführt.

Arbiter zeigt:

  • Diese Anleitungen sind echte Software, die genauso viele Fehler haben kann wie ein normales Computerprogramm.
  • Man braucht verschiedene Perspektiven (verschiedene KIs), um alle Fehler zu finden. Ein KI-Modell allein ist blind für bestimmte Fehlerarten.
  • Es ist billig und einfach: Die gesamte Analyse aller drei großen Anbieter kostete insgesamt nur 27 Cent (weniger als drei Minuten Mindestlohn in den USA).

Das Fazit

Die Autoren sagen im Grunde: "Wir bauen hochkomplexe KI-Agenten, die Code schreiben und Dateien löschen, aber wir geben ihnen Anleitungen, die voller versteckter Fallen stecken, ohne sie jemals zu testen."

Arbiter ist der erste Schritt, um diese Anleitungen so professionell zu behandeln wie normale Software: mit Tests, mit Struktur und mit einem Team, das nach Fehlern sucht, bevor sie passieren. Es ist ein Aufruf, die "Verfassungen" unserer KI-Assistenten endlich ernst zu nehmen und zu prüfen.