Generative AI for Quantum Circuits and Quantum Code: A Technical Review and Taxonomy

Dit artikel presenteert een technische review en taxonomie van dertien generatieve systemen en vijf datasets voor het genereren van quantumcircuits en -code, waarbij wordt geconcludeerd dat hoewel syntaxis en semantiek vaak worden aangepakt, er een aanzienlijke kloof bestaat tussen gegenereerde circuits en praktische implementatie op quantumhardware vanwege het ontbreken van eind-tot-eind evaluatie.

De kern

Stel je voor dat je een bouwmeester bent die gebouwen ontwerpt voor een heel speciale, nieuwe stad: de Quantum-stad. Deze stad werkt volgens regels die heel anders zijn dan die van onze gewone wereld (zoals zwaartekracht of tijd). Om hier gebouwen te maken, heb je een AI-assistent nodig die de blauwdrukken (de circuits) voor je tekent.

Dit wetenschappelijke artikel is een grote inspectie van dertien van deze AI-assistenten. De auteur, Juhani Merilehto, heeft gekeken hoe goed ze zijn en wat ze precies doen. Hier is wat hij ontdekt, vertaald naar begrijpelijke taal:

1. De Drie Soorten Blauwdrukken

De AI's maken drie soorten "tekeningen" voor de Quantum-stad:

• De Python-lijst (Qiskit): Een lijst met instructies in een programmeertaal die mensen lezen.
• De Ruwe Code (OpenQASM): Een strakke, technische code die de computer direct begrijpt (vergelijkbaar met de taal van de bouwvakkers zelf).
• Het Schetsmodel (Grafieken): Een visueel plaatje van hoe de deuren en ramen (de quantum-gates) met elkaar verbonden zijn.

2. De Drie Testen (De "Keuringsdienst")

De auteur zegt dat we een AI niet alleen mogen beoordelen op of de tekst er mooi uitziet. We moeten drie lagen testen:

• Laag 1: Grammatica (De Taaltest)
  • Vraag: Is de zin grammaticaal correct?
  • Voorbeeld: Als je zegt "Ik eet een appel", is dat correct. Als je zegt "Ik eet een", dan is het fout. Alle AI's in dit onderzoek kunnen min of meer correcte zinnen maken.
• Laag 2: Betekenis (De Logica-test)
  • Vraag: Doet het gebouw wat het moet doen?
  • Voorbeeld: Als je vraagt om een huis met een dak, bouwt de AI dan echt een huis met een dak, of bouwt hij een schuur? Sommige AI's doen dit goed, maar het is lastig te controleren omdat quantum-wiskunde heel ingewikkeld is.
• Laag 3: Bouwbaarheid (De Werkelijkheidstest)
  • Vraag: Kan dit gebouw daadwerkelijk worden gebouwd in de echte Quantum-stad?
  • Het Grote Probleem: De echte Quantum-stad heeft beperkingen. Er zijn maar weinig grondstoffen, de wegen zijn krap (verbindingen tussen qubits), en het materiaal is fragiel (ruis).
  • De Schokkende bevinding: Geen enkele AI in dit onderzoek heeft ooit getoond dat ze hun ontwerp daadwerkelijk op een echte quantumcomputer heeft laten bouwen en laten werken. Ze stoppen allemaal bij de theorie. Het is alsof ze prachtige huizen tekenen, maar nooit controleren of de fundering het in de modder houdt.

3. De Verschillende AI-Methodes

De auteur heeft de AI's ingedeeld in verschillende "stijlen":

• De Vertalers: Ze leren uit enorme boeken met bestaande code en proberen nieuwe zinnen na te bootsen.
• De Experimenteerders: Ze gebruiken een soort "probeer-en-fout" methode (versterkt leren). Ze bouwen iets, kijken of het werkt in een simulator, en verbeteren het.
• De Kunstenaars: Ze gebruiken een techniek die lijkt op het verwijderen van ruis uit een foto. Ze beginnen met een wazig beeld en maken het steeds scherper tot het een goed quantumcircuit is.

4. Het Grootste Gat: De "Translatie"

Stel je voor dat je een architect vraagt een huis te bouwen, maar hij tekent het in een land waar alle wegen breed zijn. De echte bouwvakkers werken echter in een land met smalle steegjes.
De AI's tekenen vaak circuits alsof alle qubits (de bouwstenen) direct met elkaar verbonden zijn. Maar in de echte hardware is dat niet zo. Je moet het ontwerp eerst "vertalen" (transpileren) naar de smalle steegjes.

• Het probleem: De AI's doen dit vertalen niet zelf. Ze laten het aan een andere machine over. Soms is dat vertalen zo zwaar dat het mooie huis dat de AI tekende, in de praktijk instort of te lang duurt om te bouwen.

5. Conclusie: Wat moeten we doen?

De auteur zegt: "We hebben geweldige tekenaars, maar we missen de bouwvakkers."

• We moeten stoppen met alleen kijken of de code klopt (grammatica).
• We moeten kijken of het ontwerp werkend is op echte machines.
• We moeten AI's leren die rekening houden met de beperkingen van de echte hardware (de smalle steegjes) terwijl ze tekenen, niet pas daarna.

Kortom: We hebben een heleboel slimme AI's die prachtige quantum-blauwdrukken kunnen tekenen, maar tot nu toe heeft niemand bewezen dat deze blauwdrukken ook daadwerkelijk een werkend quantumgebouw opleveren in de echte wereld. Dat is de volgende grote stap.

Technische samenvatting

1. Probleemstelling

Het veld van generatieve kunstmatige intelligentie (AI) voor quantumsoftware is gefragmenteerd en divers. Systemen genereren quantumartefacten op verschillende abstractieniveaus (Qiskit-code, OpenQASM-programma's, circuitgrafieken), maar er ontbreekt een gestructureerde taxonomie en een uniforme evaluatiestandaard.

De kernuitdaging ligt in het definiëren en afdwingen van semantische correctheid. In tegenstelling tot klassieke code, waar unit-tests vaak volstaan, is het verifiëren van quantumcirkels fundamenteel duurder:

• Statevector-simulatie vereist $O(2^n)$ geheugen voor $n$ qubits.
• Unitaire vergelijking kost $O(4^n)$.
• Er bestaat geen algemene polynoom-tijd equivalentiechecker voor willekeurige unitaire transformaties op grote schaal.

Daarnaast is hardware-uitvoerbaarheid een eerste-orde constraint (connectiviteit, native gate-set, ruis), wat geen klassiek equivalent heeft. De huidige literatuur mist een duidelijk beeld van hoe ver generatieve systemen komen in het daadwerkelijk uitvoeren van gegenereerde circuits op echte quantumhardware.

2. Methodologie

De auteur voerde een gestructureerde scoping review uit (volgend op PRISMA-ScR richtlijnen) tussen januari en februari 2026.

• Bronnen: Hugging Face (modelcards), arXiv (papers tot februari 2026), en proefvervolging via GitHub en citaties.
• Selectieproces: Uit een initiële pool van 228 kandidaten (35 modelcards + 193 papers) werden na screening 13 generatieve systemen en 5 ondersteunende datasets geselecteerd.
• Inclusiecriteria: Systemen moesten minimaal twee van de volgende drie publiceren: modelarchitectuur/parameteraantal, trainingsdata-bron/schaal, en minstens één kwantitatieve evaluatiemetric.
• Scope: De review focust op systemen die quantumartefacten genereren die bedoeld zijn voor compilatie of uitvoering (QASM, Qiskit). "Quantum-versterkte" generatieve modellen (waar quantumcircuits intern zijn maar de output niet) zijn uitgesloten.

3. Belangrijkste Bijdragen

A. Een Nieuwe Taxonomie

De paper introduceert een taxonomie die systemen classificeert op twee assen:

1. Type Artefact: Qiskit-code (Python), OpenQASM-programma's (2.0 vs 3.0), of Circuitgrafieken (DAG's).
2. Trainingsregime:
   • Supervised Fine-Tuning (SFT): Statische modellen.
   • Verifier-in-the-loop RL: Reinforcement Learning met simulatiebeloningen.
   • Diffusion/Graph Generation: Modellen die werken op discrete tokens of grafen.
   • Agentic Optimization: Multi-agent systemen met externe tools.

Dit leidt tot zes specifieke families, waaronder Qiskit-code-assistenten, specialistische kleine taalmodellen, en agentic systemen.

B. Een Drie-Lagen Evaluatiekader

De auteur stelt een gestructureerd evaluatiekader voor om systemen te vergelijken:

• Laag 1: Syntactische Validiteit: Parseert/compileert de output volgens de target-grammatica?
• Laag 2: Semantische Correctheid: Implementeert het artefact de beoogde unitaire transformatie, algoritme of taakdoel? (Methoden variëren per familie: unit-tests, proces-fideliteit, verwachtingswaarde-alignment).
• Laag 3: Hardware-uitvoerbaarheid:
  • 3a (Compilabiliteit): Transpileert het circuit succesvol naar een specifieke hardware-native gate-set en connectiviteit?
  • 3b (Empirische Uitvoering): Wordt het circuit daadwerkelijk uitgevoerd op een echte Quantum Processing Unit (QPU) en vergeleken met ideale simulatie?

C. Positionering ten opzichte van Klassieke Code

De paper benadrukt dat quantumcode-generatie fundamenteel anders is dan klassieke code-generatie (zoals Codex of AlphaCode) vanwege de hoge kosten van semantische verificatie en de noodzaak om hardware-beperkingen als eerste-class constraint te behandelen.

4. Resultaten en Kernbevindingen

• De "Hardware Gap": De meest cruciale bevinding is dat geen enkel van de 13 onderzochte systemen end-to-end evaluatie op quantumhardware (Laag 3b) rapporteert als onderdeel van hun model-evaluatie.
  • Alle systemen adresseren Laag 1 (syntaxis).
  • De meeste adresseren Laag 2 (semantiek) tot op zekere hoogte.
  • Slechts één systeem (AltGraph) adresseert gedeeltelijk Laag 3a (post-transpilatie metrics), maar geen enkele sluit de lus naar Laag 3b (echte QPU-uitvoering).
• Verschil OpenQASM 2.0 vs 3.0: Systemen die OpenQASM 3.0 targeten (met klassieke controleflow) hebben te maken met een grotere grammatische ruimte en path-afhankelijk gedrag, wat semantische verificatie complexer maakt dan bij de lineaire OpenQASM 2.0.
• Evaluatie-fragmentatie: Er is geen enkele dataset of benchmark die alle drie de lagen dekt. Vergelijkingen tussen systemen zijn moeilijk omdat ze verschillende evaluatiemethoden gebruiken (bijv. unit-tests voor Qiskit vs. proces-fideliteit voor circuit-generatie).
• Schalingsprobleem: De "simulatie-muur" (statevector simulatie kost $O(2^n)$) beperkt verifier-in-the-loop training tot kleine qubit-aantallen (meestal < 30-50 qubits).

5. Betekenis en Toekomstperspectief

Deze review biedt een noodzakelijke structuur voor een snel evoluerend veld en identificeert kritieke lacunes:

1. Noodzaak voor Standaardisatie: Er is dringend behoefte aan gestandaardiseerde evaluatieprotocollen die syntaxis, semantiek en hardware-realisme scheiden.
2. Transpilatie-bewuste Generatie: Huidige modellen genereren vaak logisch correcte circuits die enorme transpilatie-overhead (veel SWAP-gates) vereisen. Toekomstige systemen moeten hardware-connectiviteit en native gate-sets tijdens de generatie meenemen.
3. Dataset Provenance: Er is een gebrek aan interoperabiliteit tussen datasets (bijv. OpenQASM 2.0 vs 3.0), wat hergebruik en cross-system benchmarking belemmert.
4. Hardware-Closed Loop: De grootste stap vooruit is het integreren van echte hardware-uitvoering (of zeer nauwkeurige hardware-simulatie met ruis) in de evaluatiecyclus van generatieve modellen.

Concluderend stelt de paper dat terwijl generatieve AI voor quantumsoftware veelbelovend is, er een significante kloof bestaat tussen gegenereerde circuits en praktische, hardware-uitvoerbare implementaties. De weg vooruit ligt in transpilatie-bewuste training, betere datasets en een verschuiving van pure simulatie-evaluatie naar hardware-gedreven validatie.