QML-PipeGuard: Drift-Aware Behavioral Fingerprinting for Quantum Machine Learning Pipeline Integrity

QML-PipeGuard ist ein vertragsbasiertes Framework, das die Integrität eingesetzter Quanten-Machine-Learning-Pipelines sicherstellt, indem es durch Verhaltensfingerprinting gleichzeitig zwischen harmloser Hardware-Drift und böswilligem Kanal-Substitution unterscheidet, und zwar mittels eines mathematisch rigorosen, informationell vollständigen beobachtbaren Vertrags.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen Meisterkoch engagiert, der für eine hochriskante Dinnerparty ein sehr spezifisches, komplexes Gericht zubereiten soll. Sie geben dem Koch ein detailliertes Rezept (den „deklarierten Kanal") und erwarten einen bestimmten Geschmack.

QML-PipeGuard ist wie ein intelligenter, unsichtbarer Kritiker, der nicht nur den fertigen Teller probiert, um zu sehen, ob er gut schmeckt. Stattdessen überprüft dieser Kritiker den molekularen Fingerabdruck der Zutaten, während sie gekocht werden, um sicherzustellen, dass der Koch tatsächlich die exakt versprochenen Zutaten und Methoden verwendet und sie nicht gegen etwas Günstigeres oder Leicht Abweichendes austauscht.

Hier ist, wie das Papier dies in einfachen Worten aufschlüsselt:

Die zwei Probleme, die es löst

Das Papier identifiziert zwei Möglichkeiten, wie bei „Quantum Machine Learning" (dem Einsatz von Quantencomputern zum Lernen und Treffen von Entscheidungen) etwas schiefgehen kann:

1. Der „wackelige Tisch" (Kalibrierungsdrift): Quantencomputer sind wie empfindliche Instrumente. Im Laufe der Zeit geraten sie ein wenig „aus der Stimmung". Ein Gate, das perfekt sein sollte, könnte zu 99 % perfekt werden, oder eine Messung könnte leicht verrauschen. Dies ist nicht böswillig; es ist einfach das Alter der Maschine oder die Notwendigkeit einer Wartung.

   • Die Analogie: Es ist wie ein Klavier, das über einige Tage hinweg langsam leicht aus der Stimmung gerät. Die Musik klingt immer noch größtenteils richtig, aber die Noten sind nicht exakt dort, wo sie sein sollten.

2. Der „schleichende Ersatz" (Adversarial Substitution): Dies ist der beängstigende Teil. Stellen Sie sich einen unehrlichen Koch (oder einen Cloud-Anbieter, der Geld sparen möchte) vor, der Ihre teuren, hochwertigen Zutaten gegen billige austauscht. Sie sorgen dafür, dass das Gericht für einen gelegentlichen Probierer genauso aussieht und schmeckt (besteht einen Basistest), aber die innere Struktur ist anders. Vielleicht haben sie eine andere Gewürzmischung verwendet, die eine Verzerrung verbirgt, oder eine billigere Methode, die Geld spart, aber die Qualität für den Einsatz in der realen Welt verschlechtert.

   • Die Analogie: Es ist wie der „Dieselgate"-Skandal, bei dem Autos im Labor Emissionstests bestanden haben, aber auf der Autobahn die Luft verschmutzt haben. Der Test wurde bestanden, aber die Realität war eine andere.

Die Lösung: Der „Verhaltens-Fingerabdruck"

Bestehende Sicherheitstools prüfen, ob das Klavier die richtige Marke ist (Device Fingerprinting) oder ob die Noten im Großen und Ganzen in Stimmung sind (Input Drift). Aber sie prüfen nicht, ob der tatsächliche Kochprozess mit dem Rezept übereinstimmt.

QML-PipeGuard führt eine neue Art der Prüfung ein: Behavioral Fingerprinting (Verhaltens-Fingerabdruck).

Anstatt nur zu fragen: „Ist die endgültige Antwort korrekt?", fragt es: „Entspricht das Verhalten des Quantencomputers exakt der mathematischen Signatur des versprochenen Rezepts?"

• Der Fingerabdruck: Das System misst einen bestimmten Satz von „beobachtbaren Werten" (wie das Überprüfen von Temperatur, Textur und Farbe des Essens zu bestimmten Zeitpunkten).
• Der Vertrag: Das System legt ein „Toleranzniveau" fest.
  • Wenn der Fingerabdruck leicht abweicht (innerhalb der Toleranz), sagt das System: „Ah, die Maschine ist heute nur ein wenig aus der Stimmung. Das ist eine normale Drift. Wir protokollieren es und fahren fort."
  • Wenn der Fingerabdruck wild abweicht (außerhalb der Toleranz), sagt das System: „Stopp! Das ist nicht das Rezept, das wir bestellt haben. Jemand hat die Zutaten ausgetauscht!"

Wie es funktioniert (Der Zaubertrick)

Das Papier verwendet einen cleveren Trick mit Pauli-Observablen. Stellen Sie sich diese vor wie das Überprüfen des Essens aus sechs verschiedenen Winkeln (Oben, Unten, Links, Rechts, Vorne, Hinten).

• Der schwache Check: Ein unehrlicher Koch könnte wissen, dass Sie nur den „Oben"-Winkel prüfen. Er kann die Zutaten so austauschen, dass es von „Oben" perfekt aussieht, aber von „Links" völlig anders ist.
• Der starke Check: QML-PipeGuard prüft alle sechs Winkel (und mehr, je nach Komplexität). Das Papier beweist mathematisch, dass wenn jemand versucht, die Zutaten auszutauschen, um den „Oben"-Check zu bestehen, er den Unterschied nicht verbergen kann, wenn Sie alle sechs Winkel gleichzeitig prüfen. Der „Fingerabdruck" wird den Austausch aufdecken.

Das „Shot"-Budget (Effizienz)

Quantencomputer sind langsam und teuer im Betrieb; Sie müssen denselben Test viele Male („Shots") ausführen, um eine klare Antwort zu erhalten.

• Das Papier zeigt, dass ihre Methode unglaublich effizient ist. Durch die Verwendung einer engeren mathematischen Formel reduzierten sie die Anzahl der erforderlichen Testläufe um etwa das 100-fache im Vergleich zu älteren, losen Methoden.
• Das Ergebnis: Sie testeten dies an einem echten IBM-Quantencomputer. Sie fingen erfolgreich einen „schleichenden" Austausch ab, den ein schwacher Check übersehen hätte, und ignorierten gleichzeitig die normale „wackelige Tisch"-Drift, die natürlich auftritt.

Erwähnte reale Szenarien

Das Papier schlägt drei Bereiche vor, in denen dies jetzt benötigt wird:

1. Finanzen & Gesundheitswesen: Ein Unternehmen könnte eine Compliance-Prüfung mit einem „guten" Modell bestehen, aber heimlich ein verzerrtes Modell im Einsatz verwenden. Dieses Tool würde den Wechsel aufdecken.
2. Cloud-Dienste: Ein Cloud-Anbieter könnte für einen Kunden einen billigeren, minderwertigen Quantencomputer verwenden, um Geld zu sparen, die grundlegenden Tests des Kunden bestehen, aber die Leistung verschlechtern. Dieses Tool würde den Ersatz aufdecken.
3. Akademie: Ein Forscher könnte Ergebnisse mit einem perfekten Modell melden, aber tatsächlich ein anderes ausführen, um das Peer-Review zu bestehen. Dieses Tool würde sicherstellen, dass das gemeldete Experiment das tatsächlich ausgeführte ist.

Zusammenfassung

QML-PipeGuard ist ein Laufzeit-Sicherheitswächter für Quantum Machine Learning. Es prüft nicht nur, ob die Antwort richtig ist; es prüft, ob der Prozess ehrlich ist. Es unterscheidet zwischen einer Maschine, die nur „aus der Stimmung" ist (Drift), und einer Maschine, die „gehackt" oder „ausgetauscht" wurde (adversarial substitution), und das alles mit sehr wenigen Ressourcen. Es ist das erste Tool, das dies für die gesamte Quanten-Pipeline tut, nicht nur für isolierte Teile.

Technische Zusammenfassung

Technische Zusammenfassung: QML-PipeGuard

Problemstellung

Da Quantum Machine Learning (QML) vom Forschungsprototyp zum eingesetzten Cloud-Service auf Hardware von IBM, IonQ und Quantinuum übergeht, hat die Sicherstellung der Integrität der Quantenausführungsphase eine kritische operative Herausforderung dargestellt. Bestehende Verifikationsmethoden adressieren spezifische, isolierte Probleme wie Rauschkompensation auf Pulsebene, Drift der Eingangsverteilung, Robustheit gegenüber Eingangsstörungen oder Authentifizierung der Geräteidentität. Sie versagen jedoch bei der Beantwortung einer einheitlichen Integritätsfrage auf Kanalebene: Ist der deklarierte Quantenkanal tatsächlich derjenige, der ausgeführt wird?

Die Arbeit identifiziert zwei unterschiedliche, aber strukturell ähnliche Bedrohungen für die Integrität der Pipeline:

1. Harmlose Kalibrierungsdrift: Rauschbehaftete Intermediate-Scale-Quanten-Hardware (NISQ) erfährt zwischen Neukalibrierungen natürliche Kalibrierungsänderungen (Verschiebungen der Gate-Genauigkeit, Schwankungen der Kohärenzzeit, Auslesefehler). Eine Pipeline kann sich trotz Verwendung derselben Schaltungsspezifikation im Laufe der Zeit unterschiedlich verhalten.
2. Adversarischer Kanalersatz: Eine Einheit, die die Ausführungsumgebung kontrolliert (z. B. ein Cloud-Anbieter, ein interner Betreiber oder ein externer Angreifer), kann den deklarierten Quantenkanal $E_A$ durch einen Ersatzkanal $E_B$ ersetzen. Dieser „schleichende" Kanal ist so konzipiert, dass er Standardverifikationstests besteht (z. B. durch Übereinstimmung der Klassifizierungsentscheidungen auf einem Testdatensatz oder Einigung auf schwache Observable-Teilmenge wie $\{Z\}$-nur-Messungen), während er sich mathematisch in seiner Verschränkungsstruktur oder Vertrauensverteilung bei Produktionsinputs unterscheidet.

Aktuelle Methoden, die auf schwachen Observable-Teilmenge beruhen, verpassen diese Substitutionen, da der Angreifer die klassischen Randverteilungen konstruktiv erhalten kann. Es gibt kein bestehendes Framework, das sowohl harmlose Drift als auch adversarischen Ersatz unter einem einzigen, zur Laufzeit verifizierbaren Vertrag abdeckt.

Methodik: QML-PipeGuard

Die Autoren stellen QML-PipeGuard vor, ein vertragsbasiertes Framework, das eine QML-Pipeline zur Laufzeit über ihren Verhaltensfingerabdruck charakterisiert.

Kernkonzepte

• Verhaltensfingerabdruck: Definiert als der Vektor der Erwartungswerte von Observablen unter einer tomografisch strukturierten Messfamilie $\mathcal{O}_A$ für einen Referenz-Zustand $\rho$.
• Observable-Vertrag: Eine Spezifikation $\sigma_A = (H_{spec}, \mathcal{O}_A, \varepsilon_A, \tau_A)$, wobei ein Kandidatenkanal $E_B$ den Vertrag erfüllt, wenn seine Erwartungswerte der Observablen mit dem deklarierten Kanal $E_A$ innerhalb einer kalibrierten Toleranz $\varepsilon_A$ übereinstimmen:
  $$|\text{Tr}(O E_B(\rho)) - \text{Tr}(O E_A(\rho))| \leq \varepsilon_A \quad \forall O \in \mathcal{O}_A$$
• Dual-Modus-Betrieb: Das Framework arbeitet mit einer einzigen mathematischen Maschinerie in zwei Modi:
  1. Driftbewusstes Monitoring: Nimmt Abweichungen innerhalb von $\varepsilon_A$ als harmlose Kalibrierungsereignisse auf, protokolliert sie, ohne die Ausführung zu unterbrechen.
  2. Adversarische Erkennung: Markiert Abweichungen außerhalb von $\varepsilon_A$ bei einer informationsvollständigen Observable-Familie als Integritätsverletzungen und stoppt die Pipeline.

Theoretisches Framework

Die Arbeit entwickelt drei QML-spezifische Schichten über einem Fundament des Verhaltens-Subtypings für Quantensoftware:

1. Pipeline-Komposition: Spezialisiert die Abstraktion „Kanal als Objekt" auf die Encoder–Ansatz–Messung-Struktur von QML-Modellen (VQCs, QSVMs, QNNs). Sie führt ein Bedrohungsmodell ein, bei dem „schleichende" Substitutionen die Klassifizierungsübereinstimmung und die Übereinstimmung schwacher Observabler erfüllen, aber den vollständigen Vertrag verletzen.
2. Endliche-Shot-Probenkomplexität: Leitet eine Schranke für den Messbudget (Satz 4) ab, die den Vertrag in eine operationell ausführbare Prüfung unter Shot-Rauschen umwandelt. Dies umfasst eine enge Rahmenkonstante $C = \sqrt{3}$ für die Ein-Qubit-Pauli-Familie, die über die Cauchy-Schwarz-Ungleichung auf der Bloch-Zerlegung hergeleitet wurde und frühere Schranken schärft.
3. Toleranz-Zerlegung: Führt eine Zerlegung $\varepsilon_A = \varepsilon_{adv} + \varepsilon_{drift}$ ein, um adversarische und natürliche Drift-Beiträge zu trennen und die Dual-Modus-Sichtweise zu ermöglichen.

Hauptbeiträge

1. Einheitliches vertragsbasiertes Framework: Das erste Framework, das sowohl harmlose Kalibrierungsdrift als auch adversarischen Kanalersatz unter einem einzigen zur Laufzeit verifizierbaren Vertrag für End-to-End-QML-Pipelines adressiert.
2. Erkennungssatz (Satz 1): Beweist, dass jede „schleichende" Substitution mit einer nicht-trivialen Diamant-Norm-Trennung $\delta$ den Vertrag bei einer informationsvollständigen Observable-Familie verletzt. Der Beweis liefert eine enge Rahmenkonstante $C = \sqrt{3}$ für Ein-Qubit-Pauli-Familien und verbessert concurrente Arbeiten um einen Faktor von $\sqrt{2/3}$.
3. Schranke für Probenkomplexität (Satz 4): Legt das erforderliche Shot-Budget für „informatives Erkennen" (Unterscheidung echter Kanalabweichung von Shot-Rauschen) fest. Die Schranke skaliert als $O(k \log k / \gamma^2)$, wobei $\gamma$ die Erkennungsmarge ist. Die Autoren zeigen, dass ihre engeren Konstanten und die Verfeinerung durch vorkalkulierte Referenzen das erforderliche Shot-Budget im Vergleich zu loseren Schranken in concurrenten Arbeiten um etwa das 100-Fache reduzieren.
4. Drift-Korollar (Korollar 2): Formalisiert die Bedingung, unter der Kalibrierungsdrift absorbiert wird versus wann sie einen Integritätsstopp auslöst, und liefert eine quantitative Schranke für akzeptable Hardware-Variabilität.
5. Hardware-Validierung: Eine End-to-End-Validierung auf dem IBM Heron r2-Prozessor (ibm fez) unter Verwendung einer Zwei-Qubit-Quantum-Support-Vector-Machine (QSVM)-Pipeline.

Experimentelle Ergebnisse

Das Framework wurde an einer Zwei-Qubit-QSVM-Pipeline mit drei Experimenten validiert:

1. Erkennung schleichender Substitution: Ein „schleichender" Kanal (identisch zum ehrlichen Kanal, jedoch mit einem vor der Messung eingefügten $S$-Gate) wurde getestet.
   • Schwacher Vertrag ($\{Z_1Z_2\}$): Der schleichende Kanal bestand mit einer Abweichung von 0,001 (innerhalb der Rauschuntergrenze).
   • Vollständiger Vertrag (Lokale Pauli-Familie): Der schleichende Kanal wurde mit einer maximalen Abweichung von 0,489 bei der Observablen $X_2$ erkannt, was etwa dem 3,3-fachen der Toleranz ($\varepsilon_A = 0,15$) entspricht. Die Erkennung erfolgte mit einem breiten Sicherheitsabstand zum Shot-Rauschen.
2. Validierung der Probenkomplexität: Unter Verwendung eines verrauschten Simulators verifizierten die Autoren, dass das konservative Shot-Budget ($N \approx 13.680$), abgeleitet aus Korollar 1, eine True-Positive-Rate (TPR) von 1,00 und eine False-Positive-Rate (FPR) von 0,00 erreicht. Eine Reduzierung des Budgets um den Faktor 10 ließ die FPR auf 0,15 ansteigen, was zeigt, dass das vorgeschriebene Budget die Schwelle für informatives Erkennen und nicht nur für nominale Markierung darstellt.
3. Drift-Beobachtung: Natürliche Hardware-Drift, beobachtet über drei Zeitpunkte in einem einzigen gebündelten Auftrag, ergab eine typische Drift-Magnitude $d_{typ}^{drift} = 0,067$. Dies lag gut innerhalb des kalibrierten Toleranzintervalls $[0,067, 0,289]$, was bestätigt, dass das Framework natürliche Drift absorbieren kann, während die Erkennungsfähigkeit erhalten bleibt.

Bedeutung und Behauptungen

Die Arbeit positioniert QML-PipeGuard als einen grundlegenden Schritt hin zur operativen Reife von QML, analog zur Formalisierung des Verhaltens-Subtypings in der klassischen objektorientierten Programmierung.

• Operative Machbarkeit: Die Autoren behaupten, dies sei die erste Hardware-Validierung eines Dual-Modus-Kanal-Integritätsvertrags an einer End-to-End-QML-Pipeline (einschließlich Encoder, Ansatz, Messung, Mehr-Qubit-Feature-Map und endlicher Shot-Probenahme) und nicht an isolierten Kanälen.
• Komplementarität: Das Framework ersetzt keine bestehenden Tools (z. B. Kalibrierung auf Pulsebene, Monitoring von Eingangsdrift oder Geräte-Fingerprinting), sondern füllt die Lücke „Integrität der Kanalausführung" im QML-Vertrauensstack. Es liefert die zur Laufzeit gültige Vertragsschicht, die in der aktuellen Praxis fehlt.
• Skalierbarkeit: Das Framework ist so konzipiert, dass es verfügbar ist, wenn QML in die Produktion skaliert, und adressiert Bedrohungen, die heute vorhanden sind (regulierte Branchen, Cloud-Dienste, Reproduzierbarkeitsbedenken), anstatt rein spekulativen zukünftigen Angriffen.
• Einschränkungen: Die Autoren weisen ausdrücklich darauf hin, dass der aktuelle Erkennungsumfang auf lokalen Pauli-Familien beruht, die für lokale-unitäre Substitutionen informationsvollständig sind, aber Verschränkungs-Gate-Substitutionen oder korreliertes Rauschen verpassen können, ohne die Observable-Familie zu erweitern (was die Shot-Budget-Kosten erhöht). Sie weisen zudem auf die Annahme eines vertrauenswürdigen Verifizierers mit unabhängigem Messzugang hin.

Die Arbeit schließt damit, dass das Framework zwar ein „erster Schritt" ist, aber erfolgreich demonstriert, dass die Integrität auf Kanalebene in realen Hardware-Umgebungen mit formaler Korrektheit und praktischer Probenkomplexität verifiziert werden kann.