Log Probability Tracking of LLM APIs

Deze paper introduceert een kosteneffectieve methode voor continue monitoring van LLM-API's door log-probabiliteiten te analyseren, wat 1.000 keer goedkoper is dan bestaande methoden en zelfs minimale modelwijzigingen kan detecteren.

De kern

De "Logprobs" van de LLM's: Een Simpel Manier om te Checken of een AI nog hetzelfde is

Stel je voor dat je een zeer dure, slimme robot (een Large Language Model of LLM) huurt via een internetdienst. Je betaalt maandelijks en vertrouwt erop dat deze robot elke dag precies hetzelfde doet. Maar wat als de eigenaar van de robot stiekem zijn hersenen aanpast? Misschien maakt hij hem slimmer, misschien verandert hij zijn persoonlijkheid, of misschien voegt hij zelfs een geheime "achterdeur" toe voor hackers.

Helaas hebben gebruikers geen manier om dit te controleren. De bestaande methoden om te checken of de robot nog steeds dezelfde is, zijn als een dure, tijdrovende inspectie waarbij je de robot duizenden vragen moet stellen. Dat is te duur en te veel werk om elke dag te doen.

In dit paper (geschreven voor de conferentie ICLR 2026) presenteren de auteurs een slimme, goedkope oplossing: Logprob Tracking.

Hier is hoe het werkt, vertaald naar alledaagse taal:

1. Het Probleem: De "Gok" van de AI

Wanneer een AI een woord bedenkt, doet ze dat niet zomaar. Ze kijkt naar alle mogelijke woorden en geeft elk woord een kans (een waarschijnlijkheid).

• De oude manier: Je vraagt de AI een zin te maken en kijkt naar het antwoord. Als het antwoord "Hallo" is, is het antwoord "Hallo". Maar als de AI morgen "Hoi" zegt, weet je niet of dat komt omdat ze veranderd is, of gewoon omdat ze een beetje wispelturig is (AI's zijn namelijk niet altijd 100% voorspelbaar).
• De nieuwe manier (Logprobs): De auteurs kijken niet naar het woord zelf, maar naar de kans die de AI gaf aan dat woord. Het is alsof je niet kijkt naar wat de robot zegt, maar naar het zweet op zijn voorhoofd terwijl hij het woord kiest.

2. De Analogie: De dobbelsteen en de trilling

Stel je een dobbelsteen voor die je elke dag gooit.

• De oude methode: Je kijkt alleen naar het getal dat boven komt (bijv. een 6). Als de dobbelsteen morgen een 5 is, denk je: "Hij is veranderd!" Maar misschien was het gewoon toeval. Om zeker te weten, moet je duizenden keren gooien. Dat kost veel tijd en geld.
• De nieuwe methode (Logprob Tracking): De AI is als een dobbelsteen die op een trillende tafel ligt. De auteurs kijken niet naar het getal, maar naar de trilling van de tafel terwijl de dobbelsteen rolt. Zelfs als de dobbelsteen soms een 6 en soms een 5 gooit, verandert de trilling van de tafel direct als je de tafel zelf een beetje verandert (bijvoorbeeld door een nieuwe schroef erin te draaien).

Ze hoeven maar één keer te "gooien" (één woord laten genereren) om te zien of de trilling anders is dan gisteren.

3. Waarom is dit zo krachtig?

• Extreem goedkoop: De oude methoden kostten duizenden dollars per jaar om een AI te controleren. Deze nieuwe methode kost ongeveer $0,14 per jaar. Dat is 1000 keer goedkoper!
• Super gevoelig: Ze kunnen veranderingen detecteren die zo klein zijn dat ze bijna onzichtbaar zijn. Denk aan het toevoegen van slechts één stap aan het trainingsproces van de AI. De oude methoden zagen dit niet, maar deze nieuwe methode wel.
• Snel: Je hoeft maar één letter (bijvoorbeeld "x") in te typen en te kijken naar de kans die de AI gaf aan het eerste antwoord.

4. Wat hebben ze ontdekt?

De auteurs hebben dit systeem gebruikt om meer dan 100 verschillende AI-diensten (zoals die van OpenAI, Microsoft, en andere) gedurende maanden in de gaten te houden.

• Ze ontdekten 37 keer dat er iets veranderde.
• Vaak gebeurde dit zonder dat de gebruikers er iets van merkten.
• Zelfs bij "open" modellen (waar de code openbaar is), bleek dat de dienst die je gebruikt stiekem verandert. Het is alsof een restaurant zegt: "We gebruiken hetzelfde recept," maar de kok verandert stiekem de hoeveelheid zout, en niemand proeft het verschil tot het te laat is.

5. De "TinyChange" Benchmark

Om te bewijzen dat hun methode werkt, hebben ze een nieuwe test gemaakt genaamd TinyChange.
Stel je voor dat je een foto van een kat maakt. Dan maak je 58 versies van die foto, waarbij je bij elke versie heel weinig pixels verandert (soms maar één pixel).

• De oude methoden zagen pas verandering als je de hele kat in een hond veranderde.
• De nieuwe methode zag al verandering als je maar één pixel op het oor van de kat verplaatste.

Conclusie: Waarom is dit belangrijk?

Voor ontwikkelaars, onderzoekers en toezichthouders is het cruciaal dat AI's betrouwbaar zijn. Als een AI plotseling anders reageert, kunnen auto's crashen, medicijnen verkeerd worden voorgeschreven of onderzoeken onbetrouwbaar worden.

Deze paper biedt een goedkope, continue alarmbel. Het is als een rookmelder die niet alleen brand detecteert, maar ook al detecteert als er een klein vonkje is, voordat er een vuur ontstaat. Het zorgt ervoor dat we weten of de AI die we gebruiken, nog steeds dezelfde AI is als gisteren.

Kort samengevat: In plaats van de hele AI te testen (wat duur is), kijken we naar de "trillingen" in haar keuzes. Dat is goedkoper, sneller en ziet veranderingen die niemand anders ziet.

Technische samenvatting

Probleemstelling

Gebruikers van Large Language Model (LLM) API's vertrouwen erop dat het onderliggende model consistent blijft over tijd. Deze consistentie is cruciaal voor de betrouwbaarheid van downstream-toepassingen en de reproduceerbaarheid van onderzoek. Echter, API-aanbieders kunnen modelupdates, hardware-wijzigingen, quantisatie of zelfs kwaadaardige backdoors implementeren zonder dit expliciet te melden.

Bestaande methoden voor het auditen van deze veranderingen zijn te duur om regelmatig toe te passen op het brede scala aan beschikbare API's. Deze methoden vereisen vaak uitgebreide benchmarks met duizenden queries (bijv. MMLU of specifieke datasets) om statistisch significante conclusies te trekken. Hierdoor blijven LLM API's in de praktijk grotendeels onbewaakt, wat risico's met zich meebrengt voor ontwikkelaars, onderzoekers en regelgevers.

Methodologie: Log Probability Tracking (LT)

De auteurs introduceren Log Probability Tracking (LT), een methode die gebruikmaakt van de log-probabiliteiten (logprobs) van de gegenereerde tokens in plaats van de tokens zelf.

1. Het Kader:

   • In plaats van de output-tokens te analyseren, vraagt de methode de API om de log-probabiliteiten van de top-$k$ tokens voor een enkel output-token.
   • Hoewel logprobs in de praktijk niet deterministisch zijn (door temperatuur-sampling, batch-variaties en hardware-onderlinge invloeden), bevatten ze veel meer informatie dan het geselecteerde token alleen.

2. Statistische Test:

   • De methode gebruikt een permutatietest (een vorm van hypothesetoetsing) om te bepalen of de verdeling van logprobs van twee API's (of dezelfde API op verschillende tijdstippen) identiek is.
   • Procedure:
     • Stuur een korte prompt (zelfs één token, zoals "x") naar de API.
     • Vraag om de logprobs van het eerste output-token.
     • Herhaal dit $N$ keer om een steekproef te verzamelen.
     • Bereken het gemiddelde van de logprobs voor elk token in de vocabulaire.
     • Bereken de teststatistiek $S$: het gemiddelde absolute verschil tussen de gemiddelde logprobs van de twee verdelingen.
     • Voer een permutatietest uit om een $p$-waarde te bepalen. Als $p < \alpha$, wordt de nulhypothese (dat de modellen gelijk zijn) verworpen.

3. Omgaan met Non-Determinisme:

   • Omdat logprobs fluctueren, behandelt de methode elke logprob als een steekproef uit een kansverdeling. Door te kijken naar de gemiddelde waarden over veel steekproeven, kan de methode systematische veranderingen onderscheiden van willekeurige ruis.

Belangrijkste Bijdragen

1. Logprob Tracking (LT) Methode:

   • Bewijst dat een prompt van slechts één token en de logprobs van één output-token voldoende zijn om veranderingen te detecteren die door andere methoden worden gemist.
   • De methode is extreem kostenefficiënt (tot 1.000x goedkoper dan bestaande methoden) omdat deze geen lange conversaties of complexe benchmarks vereist.

2. TinyChange Benchmark:

   • De auteurs introduceren een nieuwe benchmark genaamd TinyChange om de gevoeligheid van audit-methoden te meten bij kleine, realistische modelveranderingen.
   • Deze benchmark genereert 58 varianten van modellen met variërende intensiteit van wijzigingen:
     • Fine-tuning (van 1 tot 512 stappen).
     • LoRA fine-tuning.
     • Ongestructureerde gewichts-pruning (random en op magnitude).
     • Ruis toevoegen aan parameters (Gaussische ruis).
   • De benchmark is toegepast op 5 open-weight modellen (Qwen, Gemma, Phi-3, Llama, OLMo).

3. Uitgebreide Evaluatie:

   • Vergelijking van LT met twee state-of-the-art baselines: MET (Model Equality Testing met MMD) en MMLU-ALG (gebaseerd op het abstract algebra-deel van de MMLU benchmark).

Resultaten

• Gevoeligheid: LT is aanzienlijk gevoeliger dan bestaande methoden. Het kan veranderingen detecteren die zo klein zijn als één stap van fine-tuning.
  • Bij gewichts-pruning kan LT veranderingen detecteren tot een factor van $2^{-10}$ (of lager) van de gewichten, terwijl MET en MMLU-ALG pas reageren bij veel grotere veranderingen ($2^{-1}$ en $2^{-4}$ respectievelijk).
  • Dit betekent dat LT 2 tot 3 ordes van grootte gevoeliger is dan MET.
• Kostenefficiëntie:
  • LT vereist slechts ongeveer 28 input-tokens en 20 output-tokens per test.
  • De geschatte jaarlijkse kosten voor continu monitoren (per uur) bedragen slechts $0,14 voor LT, vergeleken met $146 voor MET en $332 voor MMLU-ALG (gebaseerd op GPT-4.1-prijzen).
• Prompt Lengte: De lengte van de prompt heeft een verwaarloosbaar effect op de prestaties. Een prompt van één token ("x") werkt bijna even goed als langere prompts (33 tokens), wat de kosten verder minimaliseert.
• Real-world Monitoring:
  • De auteurs hebben LT gedurende 4 maanden toegepast op 189 API-endpoints van 10 providers.
  • Er werden 37 mogelijke veranderingen gedetecteerd bij 29 endpoints.
  • Opvallend: Bijna alle gedetecteerde veranderingen betroffen "open-weight" modellen, wat suggereert dat zelfs bij open modellen de implementatie ondoorzichtig is en ongemelde wijzigingen vaak voorkomen.

Betekenis en Impact

• Transparantie en Betrouwbaarheid: LT biedt een praktische, goedkope manier voor derden om de integriteit van LLM-API's te bewaken. Dit is essentieel voor reproduceerbaarheid in onderzoek en stabiliteit in productie-applicaties.
• Sensitiviteit: De methologie toont aan dat zelfs subtiele wijzigingen (zoals een enkele fine-tuning stap) detecteerbaar zijn via logprobs, wat een nieuwe standaard stelt voor wat er mogelijk is in black-box auditing.
• Beperkingen en Toekomst:
  • De methode vereist dat de API logprobs ondersteunt (ongeveer 23% van de endpoints op OpenRouter doet dit).
  • Providers zouden kunnen proberen de methode te omzeilen door monitoring-queries te herkennen en specifieke antwoorden te geven, maar dit zou andere inconsistenties creëren.
  • De methode onderscheidt niet tussen model- en infrastructuurveranderingen, maar dat is minder belangrijk voor het doel van reproduceerbaarheid: elke systematische verandering moet gedetecteerd worden.

Conclusie:
Het paper introduceert een doorbraak in het monitoren van LLM-API's. Door in plaats van de output-tokens, de onderliggende log-probabiliteiten te analyseren met een eenvoudige statistische test, kunnen veranderingen worden opgespoord die tot 1.000 keer goedkoper en 2-3 ordes van grootte gevoeliger zijn dan bestaande technieken. Dit maakt continue, real-time auditing van LLM-diensten voor het eerst haalbaar en noodzakelijk voor een transparante AI-ecosysteem.