Wir machen große Fortschritte im Quantencomputing. Dabei ist es wichtig, das Ziel nicht aus den Augen zu verlieren: unsere theoretische Forschung in praxisnahe Lösungen für geschäftliche Anwendungen zu überführen. Als Problemlöser liegt genau darauf unser Fokus bei Insight Softmax: reale Geschäftsanforderungen adressieren, etwa eine effizientere Nutzung unseres Energienetzes, eine bessere Effizienz in Lieferketten oder, wie in diesem Fall, der Versuch, aussagekräftige Ergebnisse aus einer heutigen Quantenmaschine zu gewinnen.
Die Herausforderung
Quantencomputing ist rauschbehaftet und dadurch bekanntermaßen instabil. Störungen aus beliebigen externen Quellen, von WiFi-Signalen bis zu kosmischer Strahlung, können schon innerhalb einer Tausendstelsekunde einen schwerwiegenden Fehler verursachen. Und wenn die Störung aus dem Magnetfeld der Erde kommt, lässt sie sich nicht einfach für eine Minute abschalten.
Rauschen ist unvorhersehbar und kann sich im Zeitverlauf stark verändern. Das macht es zu einer großen Herausforderung. Wenn wir jedoch auf ein übergeordnetes Ziel hinarbeiten, also von der Idee zur Umsetzung kommen wollen, besteht der erste Schritt darin, dieses Rauschen vorhersagen und kontrollieren zu können.
In einer idealen Welt hätten wir direkt nach jeder Ausführung Diagnoseinformationen zur Hand, ein Modell zur Einordnung des Rauschens oder eine Schätzung, wann die Batches tatsächlich ausgeführt werden. Da uns diese Möglichkeiten nicht vollständig zur Verfügung stehen, brauchen wir einen Weg, mit dem Rauschen und der Variabilität umzugehen, denen wir begegnen.
Die Frage
Wie erreichen wir die bestmögliche Leistung, wenn wir ein System betreiben, das darauf ausgelegt ist, hochkomplexe Quantenschaltungen über noch komplexere Netzwerke zu simulieren? Die Antwort lautet Wissen: präzise, umfassend und breit angelegt.
Durch unsere Arbeit mit der IonQ-Maschine haben wir festgestellt, dass fehlende Kontrolle darüber, wann und wie unsere Schaltungen ausgeführt werden, es erschwert zu verstehen, was die Ergebnisse aussagen. Wenn wir beispielsweise eine große Anzahl von Schaltungen ausführen, also mehr als 40-50, werden sie auf unterschiedliche Batch-Läufe verteilt und im Verlauf des Tages ausgeführt. Derzeit haben wir keine Möglichkeit, die Reihenfolge dieses Ablaufs zu kennen oder zu beeinflussen.
Wären die Ergebnisse von Batch zu Batch relativ konsistent, wäre die Interpretation der Resultate weniger schwierig. Innerhalb eines einzelnen Batches waren unsere Ergebnisse zwar sinnvoll gruppiert, im Vergleich zwischen verschiedenen Batches jedoch inkonsistent.
Als nächsten Schritt entwickelten wir ein Experiment, das als „Litmustest“ dienen sollte, um die Konsistenz oder Inkonsistenz des Rauschens über einen Batch von Schaltungen hinweg zu bewerten. Bei erfolgreicher Anwendung könnte dieser Test uns helfen zu entscheiden, ob wir darauf vertrauen können, dass ein „Payload“-Batch von Schaltungen einem konsistenten Rauschprofil ausgesetzt ist.
Wenn sich das Rauschprofil über einen Batch hinweg als konsistent erweist, sollte uns der Litmustest zudem etwas über dieses Rauschen verraten, damit wir seinen Einfluss auf die Payload-Schaltungen berücksichtigen können.
Das Experiment
Wir entwarfen eine einfache Quantenschaltung mit zwei Qubits, um zu bestimmen, wie sich Rauschen durch diese Schaltung fortpflanzen würde, wenn das Rauschprofil konsistent wäre. Konkret wählten wir eine Quantenschaltung aus sechs CNOT-Gattern und zerlegten sie anschließend in 24 weitere Schaltungen. Wenn alle 24 Schaltungen denselben oder sehr ähnlichen Rauschprozessen ausgesetzt wären, sollten die durch die Ausführung eines solchen Batches gewonnenen Daten einem bestimmten Muster folgen. Wäre das Rauschprofil innerhalb des Batches nicht konsistent, könnten wir diese Inkonsistenz durch die Identifikation von Ausreißern in den Daten erkennen.
Ein CNOT-Gatter, kurz für „Controlled NOT“, verändert den Zustand eines Qubits, des „Targets“, basierend auf dem Zustand eines anderen Qubits, des „Controls“. Befindet sich das Control-Qubit im Zustand |1〉, sollte auf das Target-Qubit eine Bit-Flip- oder „NOT“-Operation angewendet werden. Befindet sich das Control-Qubit hingegen im Zustand |0〉, sollte mit dem Target-Qubit nichts geschehen. Die Litmus-Schaltung ist anschließend eine Folge von sechs CNOT-Gattern, bei der die Wahl von Control- und Target-Qubit abwechselt.
Gäbe es in der Litmus-Schaltung kein Rauschen, müssten die Eingabedaten exakt den Ausgabedaten entsprechen. Wichtig ist jedoch, dass dies bei weniger als sechs CNOT-Gattern nicht gilt. Selbst wenn eine bestimmte Eingabe, etwa 00, unverändert am Ausgang zurückgegeben werden sollte, was für 00 immer gilt, gibt es andere Eingaben, die nicht unverändert zurückgegeben würden. Deshalb haben wir unsere Litmus-Schaltung wie folgt in 24 weitere Schaltungen zerlegt: Für jede der vier möglichen Eingaben 00, 01, 10, 11 wird jede von sechs möglichen Teilschaltungen ausgeführt, also 1 CNOT, 2 CNOTs, 3 CNOTs, 4 CNOTs, 5 CNOTs, 6 CNOTs. Insgesamt ergibt das 6x4=24 Schaltungen. Diesen Batch möchten wir an den Quantencomputer übermitteln.
Nach Abschluss des Experiments verarbeiteten wir die Daten aus diesem Schaltungs-Batch, um zwei Punkte zu untersuchen. Erstens schätzten wir die durchschnittliche Fehlerwahrscheinlichkeit pro CNOT-Gatter, indem wir die durchschnittliche Fehlerwahrscheinlichkeit über alle 24 Schaltungen im Batch berechneten. Zweitens berechneten wir die Varianz der Fehler und prüften, ob sie einen Toleranzwert überschritt.
Wenn die Varianz die Toleranz überschreitet, können wir feststellen, dass das Rauschprofil nicht die für die Ausführung des Payload-Batches erforderliche Konsistenz zeigt. In diesem Fall können wir unseren Kunden Kosten sparen, indem wir die Ausführung auf dem Quantencomputer an dieser Stelle beenden.
Die Ergebnisse
Uns liegen nun Daten aus rund 500 Ausführungen derselben Schaltung vor, die alle zur selben Zeit eingeplant, aber im Laufe des Tages in nachfolgenden Batches ausgeführt wurden. Eine unvorhersehbare Anzahl von Schaltungen wird offenbar sequenziell ausgeführt. Wir nennen diese Phasen „execution windows“.
In der ersten Analyse stellten wir fest, dass sich das Rauschprofil von einem execution window zum nächsten stark verschieben kann und sich offenbar auch im Zeitverlauf verändert. Diese Drift scheint jedoch in einem Bereich zu liegen, mit dem wir umgehen können.
Wie geht es weiter?
Der nächste Schritt besteht darin zu verstehen, wie sich dieser Litmustest in die routinemäßige Ausführung von Quantenschaltungs-Batches integrieren lässt. Wenn die Batches beispielsweise einem konsistenten Rauschprofil ausgesetzt sind, könnten wir zufällige Schaltungen aus dem ursprünglichen Batch von 24 hinzufügen, um Vertrauen in die Konsistenz des Rauschprofils aufzubauen. Nach Abschluss könnten wir diese Litmustests nutzen, um alle Batches miteinander zu vergleichen und die Drift zwischen ihnen zu korrigieren.
Wir gehen davon aus, dass dieser Ansatz auch für andere nützlich sein könnte, die eine große Anzahl von Schaltungen auf IonQ-Hardware ausführen möchten. Diese Ergebnisse, die uns einen aussagekräftigeren Vergleich zwischen Batches ermöglicht haben, wurden von IonQ positiv aufgenommen. Wir danken IonQ für die Zeit und den fachlichen Austausch. Mit dem weiteren Fortschritt möchten wir diese Informationen nicht nur selbst nutzen, sondern auch mehr über unsere Erkenntnisse zur Hardware von IonQ teilen.
Weiteres Interesse könnte zu einem umfassenderen Protokoll führen, gemeinsam mit experimentellen Daten mehrerer Hardwareanbieter, die bereit sind, dedizierte execution windows zu ermöglichen.
Wenn Sie vor ähnlichen Herausforderungen stehen, schreiben Sie uns. Wir sprechen gern mit Ihnen und prüfen, ob wir zusammenarbeiten können.