Arbiter: Detecting Interference in LLM Agent System Prompts

Dit paper introduceert Arbiter, een framework dat formele regels en multi-model LLM-scouring combineert om interferentiepatronen in systeemprompts van coderingsagenten te detecteren, waarbij het verschillende kwetsbaarheden blootlegt die vaak worden gemist door traditionele methoden.

Tony Mason

Gepubliceerd Wed, 11 Ma
📖 5 min leestijd🧠 Diepgaand

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

Stel je voor dat je een zeer slimme, maar soms wat verwarde assistent hebt die voor je werkt. Deze assistent (een AI-agent) kan code schrijven, bestanden beheren en taken uitvoeren. Maar er is een probleem: de instructies die deze assistent krijgt, zijn geschreven op een manier die vol zit met tegenstrijdigheden, en niemand heeft ze ooit goed gecontroleerd.

Dit artikel introduceert Arbiter, een slimme manier om deze instructies te testen. Hier is de uitleg in simpele taal, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Grondwet" zonder Controle

De instructies die een AI-agent krijgt, noemen de auteurs een systeemprompt. Denk hierbij aan de grondwet van een land of de bedrijfsregels van een fabriek.

  • Het probleem: In normale software (zoals een app op je telefoon) hebben we tools die fouten opsporen voordat het programma start. Maar bij deze AI-instructies is dat er niet.
  • De chaos: Stel, in de ene paragraaf staat: "Gebruik altijd de 'Todo'-lijst!" en in een andere paragraaf staat: "Gebruik nooit de 'Todo'-lijst!"
  • De reactie van de AI: De AI wordt niet boos, geeft geen foutmelding en logt geen waarschuwing. In plaats daarvan "gokt" hij even welke regel hij moet volgen. Soms doet hij het goed, soms maakt hij een rare fout. Omdat de AI zelf de fout moet oplossen, ziet hij de tegenstrijdigheid vaak niet eens.

2. De Oplossing: Arbiter (De Onafhankelijke Inspecteur)

De auteurs hebben Arbiter bedacht. Dit is een systeem dat de instructies controleert voordat de AI ze gebruikt. Arbiter werkt in twee fasen, die we kunnen vergelijken met twee verschillende soorten detectives:

Fase 1: De "Regel-Check" (Gerichte Analyse)

Stel je voor dat je een bouwkundige inspecteur bent die een huis controleert op specifieke regels: "Is er een trap? Ja. Is er een branddeur? Ja."

  • Arbiter kijkt naar de instructies en zoekt naar bekende fouten, zoals twee regels die elkaar direct tegenspreken.
  • Dit werkt goed voor duidelijke fouten, maar het mist dingen die niet op de "checklist" staan.

Fase 2: De "Verkenning" (Ondirigeerde Scouring)

Dit is de echte kracht van Arbiter. Stel je voor dat je tien verschillende detectives (verschillende AI-modellen) naar hetzelfde huis stuurt.

  • Je geeft ze geen specifieke regels om te zoeken. Je zegt alleen: "Kijk goed om je heen en vertel me wat je raar, interessant of verdacht vindt."
  • Omdat elke detective een andere achtergrond heeft (ze zijn getraind op verschillende data), zien ze verschillende dingen.
    • Detective A ziet een leegte in de muur (een veiligheidslek).
    • Detective B ziet dat de elektriciteitsrekening te hoog is (kostenprobleem).
    • Detective C merkt op dat de sleutel niet past in het slot (structuurprobleem).
  • Als drie detectives achter elkaar zeggen: "Ik zie niets meer nieuws," dan stoppen ze. Zo vinden ze fouten die de eerste inspecteur nooit had gevonden.

3. Wat Vonden Ze? (De Drie Bouwstijlen)

De auteurs keken naar drie grote AI-assistenten (van Anthropic, OpenAI en Google) en ontdekten dat de vorm van de instructies bepaalt welk type fout er optreedt:

  1. De "Monoliet" (Een groot, dik boek):

    • Vergelijking: Een enorme baksteen van instructies.
    • Fout: Omdat alles door verschillende teams is geschreven zonder coördinatie, botsen de regels elkaar. Bijvoorbeeld: "Gebruik altijd Todo" vs. "Gebruik nooit Todo".
    • Oplossing: Het moet netjeser worden opgedeeld, zoals het herschrijven van een rommelig manuscript.
  2. De "Vlakke" (Een simpel lijstje):

    • Vergelijking: Een korte, simpele handleiding.
    • Fout: Omdat het zo simpel is, zijn er weinig tegenstrijdigheden. Maar de assistent kan ook minder complexe dingen doen. Het is veilig, maar beperkt.
  3. De "Modulaire" (Blokken die je kunt schuiven):

    • Vergelijking: Een lego-constructie. Elke blok werkt prima op zich, maar als je ze aan elkaar klikt, passen ze niet goed.
    • Fout: Er is een gat tussen de blokken. Een heel grappig voorbeeld uit het artikel: De AI kan herinneringen opslaan (zoals "ik hou van blauw"), maar als het geheugen vol raakt en wordt gecomprimeerd, verdwijnt die herinnering omdat de "opslagdoos" geen plek heeft voor die specifieke info. De AI vergeet dus wat je net zei, puur door een ontwerpfout.

4. Het Verbazingwekkende Resultaat: Kosten

Het meest opvallende is hoeveel dit kostte.

  • Om deze drie grote AI-systemen volledig te analyseren, betaalden de auteurs $0,27 (27 cent).
  • Dat is minder dan de prijs van een stukje kauwgom.
  • Het betekent dat elke ontwikkelaar met een internetverbinding deze diepgaande controle kan uitvoeren. Het is niet nodig om een duur beveiligingsteam in te huren.

Conclusie

De boodschap van dit artikel is simpel: AI-instructies zijn software, en ze moeten worden getest zoals software.
Op dit moment laten we AI-agenten werken met instructies die vol zitten met fouten, omdat niemand ze heeft gecontroleerd. Met een slimme combinatie van regels en verschillende AI-detectives (Arbiter) kunnen we deze fouten vinden voor ze problemen veroorzaken, en dat kost bijna niets.

Het is alsof we eindelijk beginnen met het bouwen van een veiligheidscontrole voor de "grondwetten" van onze digitale werelden.