Log Probability Tracking of LLM APIs

Diese Arbeit stellt eine kosteneffiziente Methode zur kontinuierlichen Überwachung von LLM-APIs vor, die durch die statistische Analyse von Log-Wahrscheinlichkeiten selbst kleinste Modelländerungen erkennt und dabei 1.000-mal günstiger ist als bestehende Ansätze.

Das Wesentliche

Das große Problem: Der unsichtbare Tausch

Stell dir vor, du bestellst jeden Morgen denselben Kaffee in deinem Lieblingscafé. Du vertraust darauf, dass er genau so schmeckt wie gestern. Aber was, wenn der Barista heimlich das Rezept ändert, einen anderen Kaffee verwendet oder sogar die Maschine austauscht, ohne es dir zu sagen?

Genau das passiert mit KI-Modellen (LLMs), die über das Internet angeboten werden. Entwickler, Forscher und Firmen nutzen diese KI-Dienste, weil sie erwarten, dass das „Gehirn" der KI immer gleich bleibt. Doch die Anbieter (wie OpenAI, Mistral oder andere) ändern im Hintergrund ständig die Software, die Hardware oder sogar das Modell selbst – manchmal, um schneller zu sein, manchmal, um Kosten zu sparen, und manchmal sogar, weil sie versehentlich Fehler machen oder böswillige Änderungen vornehmen.

Das Problem: Bisher gab es keinen einfachen Weg, das zu überprüfen. Um zu testen, ob sich die KI geändert hat, mussten Forscher Tausende von Fragen stellen und lange Antworten vergleichen. Das war wie ein riesiger, teurer Geschmackscheck für jeden einzelnen Kaffee – viel zu aufwendig, um es täglich zu tun.

Die Lösung: Der „Log-Prob"-Fingerabdruck

Die Autoren dieses Papiers haben eine clevere, fast magische Methode entwickelt, die sie „Log-Prob Tracking" (LT) nennen.

Stell dir vor, wenn die KI ein Wort ausspricht (z. B. „Hallo"), ist das nicht nur ein Zufall. Hinter den Kulissen berechnet die KI für jedes mögliche Wort im Universum eine Wahrscheinlichkeit, wie gut es passt. Diese Zahlen nennt man Log-Probabilities (kurz: LogProbs).

• Die alte Methode: Man schaut nur auf das fertige Wort („Hallo"). Das ist wie zu schauen, ob das Glas voll ist.
• Die neue Methode (LT): Man schaut auf die unsichtbaren Wahrscheinlichkeitszahlen, die die KI berechnet hat, bevor sie das Wort gewählt hat. Das ist wie zu schauen, wie sehr der Barista eigentlich an den Kaffee geglaubt hat, bevor er ihn ausgeschenkt hat.

Diese Zahlen sind viel detaillierter als das Wort selbst. Selbst wenn die KI immer noch das Wort „Hallo" sagt, haben sich die inneren Zahlen vielleicht schon leicht verschoben, weil sich das Modell im Hintergrund geändert hat.

Der Trick: Ein einziger Buchstabe reicht

Das Geniale an dieser Methode ist die Effizienz. Früher musste man ganze Geschichten schreiben, um Änderungen zu merken. Mit dieser neuen Methode reicht ein einziger Buchstabe (z. B. nur das „x").

• Die Analogie: Stell dir vor, du willst prüfen, ob ein Musikinstrument gestimmt ist. Früher musste man ein ganzes Konzert spielen. Jetzt reicht es, auf eine einzige Saite zu klopfen und den Klang genau zu analysieren.
• Die Kosten: Weil man nur einen Buchstaben anfordert, kostet die Prüfung fast nichts. Die Forscher sagen, ihre Methode ist 1.000-mal billiger als die alten Methoden.

Der „TinyChange"-Test: Wie empfindlich ist die Waage?

Um zu beweisen, dass ihre Waage wirklich empfindlich ist, haben die Forscher einen neuen Test namens TinyChange erfunden.

Stell dir vor, du hast eine Waage.

• Die alten Waagen (andere Methoden) merken erst, wenn du einen ganzen Ziegelstein auf die Waage legst (eine große Änderung).
• Die neue Waage (LT) merkt schon, wenn du ein einziges Sandkorn darauf legst (eine winzige Änderung, wie ein einziger Schritt beim „Feintuning" des Modells).

Sie haben gezeigt, dass ihre Methode selbst winzige Änderungen erkennt, die andere Methoden völlig übersehen würden.

Was haben sie in der echten Welt gefunden?

Die Forscher haben diese Methode über 4 Monate lang auf 189 verschiedene KI-Angebote angewendet. Sie haben stündlich nur einen Buchstaben gesendet und die Reaktion gemessen.

Das Ergebnis war erschreckend, aber wichtig:
Sie haben 37 Fälle entdeckt, in denen sich die KI-Angebote verändert haben.

• Bei manchen Anbietern passierte das fast wöchentlich.
• Selbst bei Modellen, die als „offen" gelten (wo man denken würde, alles ist transparent), gab es heimliche Änderungen.
• Viele Anbieter haben auf die Nachfrage der Forscher nicht geantwortet oder sagten nur: „Wir ändern Dinge regelmäßig."

Warum ist das wichtig?

Diese Methode ist wie ein Rauchmelder für KI.
Sie sagt dir nicht genau, was geändert wurde (ob es die Hardware war oder ein neuer Algorithmus), aber sie warnt dich sofort: „Hey, hier stimmt etwas nicht mehr!"

Das ist entscheidend für:

1. Forscher: Damit ihre Experimente heute das gleiche Ergebnis liefern wie gestern.
2. Entwickler: Damit ihre Apps nicht plötzlich kaputtgehen, weil die KI sich verändert hat.
3. Sicherheit: Damit niemand heimlich eine „Hintertür" in die KI einbaut, die nur sie sehen können.

Fazit

Die Autoren haben gezeigt, dass man mit einem sehr einfachen, billigen Trick (einem Buchstaben und den unsichtbaren Wahrscheinlichkeiten dahinter) die Integrität von KI-Systemen überwachen kann. Es ist ein großer Schritt hin zu mehr Transparenz in einer Welt, in der KI-Modelle oft wie schwarze Kästen behandelt werden.

Kurz gesagt: Sie haben einen billigen, super-empfindlichen Schnüffler gebaut, der merkt, wenn die KI im Hintergrund ihren Charakter ändert – lange bevor es jemand merkt, der nur auf die Antworten schaut.

Technische Zusammenfassung

1. Problemstellung

Nutzer von Large Language Model (LLM) APIs erwarten, dass das bereitgestellte Modell über die Zeit konsistent bleibt. Diese Konsistenz ist entscheidend für die Zuverlässigkeit nachgelagerter Anwendungen, die Reproduzierbarkeit von Forschungsergebnissen und regulatorische Compliance.

• Das Problem: API-Anbieter ändern Modelle oft stillschweigend (z. B. durch Fine-Tuning, Quantisierung, Hardware-Updates oder sogar bösartige Backdoors). Bisherige Audit-Methoden zur Erkennung solcher Änderungen sind jedoch zu teuer, um sie in regelmäßigen Abständen auf die breite Palette verfügbarer APIs anzuwenden.
• Die Lücke: Es gibt keine praktikable, kostengünstige Methode, um kontinuierlich zu überwachen, ob ein API-Endpunkt das gleiche Modell bedient wie zuvor. Bestehende Ansätze erfordern oft umfangreiche Benchmarking-Sets und die Verarbeitung vieler Tokens, was hohe Kosten verursacht.

2. Methodik: Logprob Tracking (LT)

Die Autoren schlagen eine neue Methode namens Logprob Tracking (LT) vor, die Log-Wahrscheinlichkeiten (Logprobs) der zurückgegebenen Tokens nutzt, anstatt nur die Tokens selbst zu analysieren.

• Grundprinzip: Während der Inferenz wird jedes Token aus einem Vektor von Log-Wahrscheinlichkeiten über den gesamten Vokabularraum des Modells gesampelt. Viele APIs (z. B. über OpenRouter) erlauben die Rückgabe der Top-k Logprobs. Diese enthalten deutlich mehr Information als das generierte Token allein.
• Herausforderung: Logprobs sind in der Praxis nicht deterministisch. Sie schwanken aufgrund von Temperatur-Sampling (intentional) und Unstimmigkeiten in der Inferenz-Infrastruktur (Batch-Größen, GPU-Zuweisung, Hardware-Stack) (unintentional).
• Lösungsansatz (Statistischer Test):
  • Statt die Logprobs direkt zu vergleichen, wird ein zweistichprobenbasierter Permutationstest angewendet.
  • Prozedur: Ein sehr kurzer Prompt (im Idealfall nur 1 Token, z. B. „x") wird an zwei APIs (oder dieselbe API zu verschiedenen Zeitpunkten) gesendet. Es werden $N$ Stichproben genommen, wobei jeweils nur der erste Output-Token und dessen Logprobs angefordert werden.
  • Teststatistik: Für jeden beobachteten Token wird der durchschnittliche Logprob-Wert berechnet. Die Teststatistik $S$ ist der durchschnittliche absolute Abstand zwischen den Mittelwerten der Logprobs der beiden Verteilungen.
  • Entscheidung: Ein Permutationstest ermittelt einen p-Wert. Ist $p < \alpha$, wird die Nullhypothese (dass die Verteilungen identisch sind) verworfen, und eine Änderung wird detektiert.
  • Robustheit: Durch die Aggregation über viele Stichproben und den Vergleich der Mittelwerte wird die nicht-deterministische Schwankung der Logprobs statistisch kompensiert.

3. Wichtige Beiträge

1. Logprob Tracking (LT) Methode: Demonstration, dass ein Prompt von nur 1 Token und die Logprobs eines einzigen Output-Tokens ausreichen, um Änderungen mit höherer Sensitivität und zu einem Bruchteil der Kosten zu erkennen als bestehende Methoden.
2. TinyChange Benchmark: Einführung eines neuen Benchmarks zur Evaluierung der Sensitivität von Audit-Methoden bei kleinen, realistischen Modelländerungen.
   • Erzeugt 58 Varianten von 5 Open-Weight-Modellen (0,5B bis 8B Parameter).
   • Änderungen umfassen: Fine-Tuning (1 bis 512 Schritte), LoRA, unstrukturiertes Pruning (Gewichtsreduktion) und Rauschen (Gaußsches Rauschen auf Parametern).
   • Ziel: Messung der kleinsten detektierbaren Änderung (z. B. ein einziger Fine-Tuning-Schritt).
3. Umfassende Evaluation: Vergleich von LT mit zwei State-of-the-Art-Baselines (MET und MMLU-ALG) auf dem TinyChange-Benchmark und in realen API-Umgebungen.

4. Ergebnisse

• Sensitivität: LT ist signifikant empfindlicher als bestehende Methoden.
  • LT kann Änderungen erkennen, die so klein sind wie ein einziger Schritt des Fine-Tunings.
  • Im Vergleich zur Methode MET (Model Equality Testing) ist LT um den Faktor $2^9$ (512) und im Vergleich zu MMLU-ALG um den Faktor $2^6$ (64) empfindlicher.
  • LT erreicht eine ROC-AUC von ca. 0,915 über den gesamten Benchmark, während MET nur 0,670 erreicht.
• Kosten:
  • LT ist extrem kosteneffizient, da nur ein Token angefordert wird.
  • Die geschätzten jährlichen Kosten für eine stündliche Überwachung (bei GPT-4.1-Preisen) betragen für LT nur 0,14 $, im Vergleich zu 146 $ für MET und 332 $ für MMLU-ALG.
  • LT ist damit etwa 1.000-mal günstiger als die Alternativen.
• Prompt-Länge: Die Länge des Prompts hat nur einen minimalen Einfluss auf die Leistung. Ein Prompt von 1 Token ist fast genauso effektiv wie längere Prompts.
• Real-World-Deployment: Die Autoren überwachten über 4 Monate hinweg 189 API-Endpunkte von 10 Anbietern.
  • Es wurden 37 potenzielle Änderungen identifiziert.
  • Fast alle Änderungen betrafen Open-Weight-Modelle, was darauf hindeutet, dass undokumentierte Änderungen auch bei „offenen" Modellen weit verbreitet sind und die Transparenz untergraben.

5. Bedeutung und Fazit

• Transparenz und Sicherheit: LT bietet eine kostengünstige, hochsensitive erste Verteidigungslinie, um die Integrität und Reproduzierbarkeit von LLM-APIs zu sichern. Es deckt auf, dass Modelle oft stillschweigend verändert werden, was für Entwickler, Forscher und Regulatoren ein kritisches Risiko darstellt.
• Praktische Anwendbarkeit: Die Methode ist leicht in Audit-Pipelines integrierbar. Sie kann als Trigger für tiefgehende Untersuchungen dienen, sobald eine Abweichung erkannt wird.
• Einschränkungen: Die Methode setzt voraus, dass die API Logprobs zurückgibt (was bei ca. 23% der getesteten Endpunkte der Fall ist). Zudem kann sie nicht unterscheiden, ob die Änderung durch Software, Hardware oder das Modell selbst verursacht wurde.
• Zukunftsausblick: Die Autoren hoffen, dass die Ergebnisse den Druck auf Anbieter erhöhen, Logprob-Unterstützung standardmäßig anzubieten, und dass LT als Standardtool für kontinuierliches Monitoring etabliert wird.

Zusammenfassend beweist das Paper, dass durch die intelligente Nutzung von Log-Wahrscheinlichkeiten und einfacher Statistik eine bisher unerreichte Kombination aus hoher Sensitivität (Erkennung kleinster Änderungen) und extrem niedrigen Kosten für das Monitoring von LLM-APIs möglich ist.