Capcane tutorial IBM Quantum pentru dezvoltatori

Începând cu IBM Quantum poate părea copleșitor, deoarece limitările hardware-ului și particularitățile software-ului provoacă adesea eșecuri neașteptate ale experimentelor.

Răspunsul direct este să urmezi un flux de lucru disciplinat: verifică starea backend-ului, asigură că adâncimea circuitului corespunde timpilor de coerență și aplică mitigarea erorilor înainte de a trimite job-urile.

Cum să verifici starea backend-ului IBM Quantum înainte de a rula

De ce contează calibrarea în timp real

Dispozitivele cuantice suferă variații pe măsură ce trec minutele, iar timpii de coerență, erorile de gate și fidelitățile de citire pot diferi semnificativ între ciclurile de calibrare. Dacă rulezi un circuit pe un backend al cărui T1 și T2 s-au deteriorat, rata de erori va crește și vei pierde tirajele alocate. Consultând cea mai recentă instantanee de calibrare poți decide dacă un circuit se potrivește ferestrei hardware curente sau dacă ar trebui să amâni jobul.

De exemplu, proiectul QuBIOS a măsurat o fidelitate logică Bell‑pair de 97,7 % pe dispozitivele IBM Heron r2 doar după ce a selectat rulări efectuate în timpul unei ferestre de calibrare în care ratele de eroare pentru gate cu două qubiți erau sub 0,5 %. Același hardware, când a fost interogat mai târziu, a arătat erori de gate în jur de 1 % și fidelitatea a scăzut sub limita fizică. Acest lucru ilustrează că, fără a verifica starea backend-ului, chiar și un experiment bine proiectat poate performa sub așteptări.

Accesarea tabloului de bord IBM Quantum

Accesează tabloul de bord public IBM Quantum la https://quantum-computing.ibm.com/dashboard. Tab-ul „Backends” listează toate dispozitivele disponibile; făcând clic pe un backend se deschide un panou cu cea mai recentă tabelă de calibrare. Rândurile cheie includ:

• Qubit T1 / T2 – timpi de relaxare și de dephasing în microsecunde.
• Eroare gate unic qubit – eroare medie per X, H, S, etc.
• Eroare gate cu două qubiți – eroare pentru gate CX sau CZ.
• Eroare citire – probabilitatea de a citi greșit starea |0⟩ sau |1⟩.

Aceste valori se actualizează după fiecare ciclu de calibrare, de obicei la fiecare câteva ore. Observă data și ora de la capătul panoului; dacă este mai veche de câteva ore, ia în considerare așteptarea următorului update.

Verificare programatică cu Qiskit

Într-un script Python, folosește furnizorul IBMQ pentru a extrage aceleași date:

Apelul properties() returnează un obiect BackendProperties care conține exact numerele afișate pe tabloul de bord. Poți scrie un script de verificare a pragului, de exemplu abandonând dacă orice eroare de gate cu două qubiți depășește 0,006 (0,6 %).

Integrarea verificărilor de stare într-un flux de lucru

Înainte de a trimite un job, urmează acești pași:

1. Deschide tabloul de bord IBM Quantum și notează ultima dată de calibrare pentru backend-ul țintă.
2. Rulează un fragment scurt de Qiskit (așa cum am arătat mai sus) pentru a prelua BackendProperties curente.
3. Compară T1/T2 și erorile de gate cu toleranța experimentului tău (de exemplu, solicită T1 > 120 µs și eroare CX < 0,005).
4. Dacă metricile îndeplinesc criteriile, continuă cu trimiterea jobului; altfel, selectează un backend diferit sau așteaptă următorul ciclu de calibrare.

Acest control disciplinat reduce probabilitatea de a arunca rezultate din cauza degradării hardware neașteptate, un capcană pe care mulți dezvoltatori o întâlnesc când presupun că performanța dispozitivului este statică.

Pentru o privire mai detaliată asupra modului în care metricile backend-ului au fost folosite în practică, vezi documentația proiectului QuBIOS.

Potrivirea adâncimii circuitului cu timpii de coerență ai qubit-urilor

Estimarea ferestrei de coerență

Dispozitivele IBM Quantum publică valorile T1 și T2 pentru fiecare qubit în pagina de stare a backend-ului. Pentru un dispozitiv tipic cu 27 de qubit-uri, T2 variază între 80 µs și 150 µs. O regulă de bază sigură este să păstrați timpul total de execuție al unui circuit sub 30 % din cel mai scurt T2 dintre qubit-urile pe care le utilizați. Acest lucru lasă o marjă pentru citire și întârzieri transitorii.

Pentru a traduce bugetul de timp într-un număr de porți, consultați tabelul gate_time al dispozitivului. De exemplu, o porțiune CX pe IBM Heron r2 are în medie 200 ns, în timp ce o rotație cu un singur qubit durează aproximativ 40 ns. Dacă cel mai scurt T2 este 90 µs, adâncimea maximă tolerabilă este aproximativ (0,3 × 90 µs) ÷ 200 ns ≈ 135 de straturi CX, presupunând că utilizați doar CX ca operație dominantă în termeni de timp.

Reglarea adâncimii circuitului

Când un circuit depășește adâncimea estimată, luați în considerare următoarele reducții:

• Îmbinați rotațiile consecutive cu un singur qubit într-o singură unitate unită folosind transpile cu optimization_level=3.
• Înlocuiți porțiile cu mai mulți controlori cu decompuneri bazate pe ancilla care folosesc mai puține operații CX.
• Exploatați seturile native de porți; pe dispozitivele unde porțiunea cu două qubit-uri nativă este iSWAP, rescrieți secvențele CX în consecință.

După fiecare pas de optimizare, rulați din nou transpile și verificați atributul depth. Dacă adâncimea rămâne mare, tăiați qubit-urile cu cea mai scăzută coerență sau redeschideți algoritmul pentru a folosi mai puține straturi de entanglement.

Ilustrarea impactului adâncimii cu rezultatele QuBIOS

Proiectul QuBIOS (/projects/QuBIOS) a rulat un experiment de pereche Bell logică [[4,2,2]] cu detectare de erori pe trei dispozitive IBM (ibm_fez, ibm_marrakesh, ibm_kingston). Circuitul logic a necesitat aproximativ 120 de straturi CX, ceea ce a corespuns ferestrelor de coerență ale dispozitivelor (≈ 140 µs execuție totală). Fidelitatea obținută de 97,7 % a depășit cea a celei mai bune perechi Bell fizice (89,7 % fidelitate în aceeași fereastră de 10 µs), demonstrând că rămânerea în bugetul de coerență permite protocoalelor cu detectare de erori să depășească hardware-ul brut.

În contrast, un test de cod de repetiție cu 9 qubit-uri care a depășit limita de coerență a arătat o scădere rapidă a fidelității, confirmând relația directă dintre adâncime și decoerență. Aceste descoperiri întăresc practica de a estima limitele de coerență înainte de finalizarea unui circuit.

Sfat: După transpiling, folosiți backend.properties() pentru a obține timpii exacti ai porților pentru backend-ul selectat, apoi calculați timpul de execuție așteptat cu circuit.duration(). Ajustați circuitul până când timpul de execuție rămâne sub 30 % din cea mai mică valoare T2.

Erori comune de codare în Qiskit care aruncă shot‑uri inutile

Omisiunea pasului de transpilație

Mulți dezvoltatori presupun că un circuit poate fi trimis direct la backend. În realitate, circuitul trebuie transpiled pentru a se potrivi setului de porți native al dispozitivului și hărții de acopere. Fără acest pas, compilatorul introduce SWAP‑uri suplimentare și conversii de porți de bază, ceea ce crește adâncimea totală și reduce probabilitatea de succes pentru fiecare shot.

# Incorect: trimiterea circuitului brut
job = backend.run(circuit, shots=8192)

# Corect: transpilați înainte de execuție
from qiskit import transpile
optimized = transpile(circuit, backend=backend, optimization_level=2)
job = backend.run(optimized, shots=8192)

Registre de măsurare nealiniate

Qiskit cere ca fiecare qubit pe care doriți să-l citiți să fie măsurat într-un bit clasic. O greșeală comună este să creați un ClassicalRegister cu mai puține biți decât numărul de qubiți măsurați, sau să uitați să mapați explicit fiecare măsurare. Rezultatul este că unele rezultate ale qubitului sunt aruncate, irosind shot‑urile alocate.

# Incorect: lipsă de biți clasici pentru doi qubiți
qr = QuantumRegister(2)
cr = ClassicalRegister(1)   # doar un bit!
circuit = QuantumCircuit(qr, cr)
circuit.h(qr[0])
circuit.cx(qr[0], qr[1])
circuit.measure(qr, cr)     # generează eroare sau elimină datele

# Corect: registre corespunzătoare
cr = ClassicalRegister(2)
circuit = QuantumCircuit(qr, cr)
circuit.measure(qr, cr)

Neresetarea qubit-urilor între experimente

Când reutilizați un obiect de circuit pentru mai multe scanări de parametri, dezvoltatorii uită uneori să resetze qubit-urile la starea de bază. Excitațiile reziduale dintr-o rulare anterioară pot păstra statistici de măsurare distorsionate, ducând la rezultate înșelătoare și la necesitatea de a repeta experimentul cu mai multe shot‑uri.

# Incorect: reutilizarea circuitului fără reset
circuit = QuantumCircuit(1,1)
circuit.x(0)
circuit.measure(0,0)
job1 = backend.run(circuit, shots=4096)

# mai târziu, schimbați un parametru dar păstrați același circuit
circuit.rz(theta,0)   # X rezidual de la rularea anterioară rămâne
job2 = backend.run(circuit, shots=4096)

# Corect: începeți de la un circuit nou sau adăugați reset
circuit = QuantumCircuit(1,1)
circuit.reset(0)      # asigurați starea |0⟩
circuit.x(0)
circuit.measure(0,0)

Specificarea excesivă a shot‑urilor pentru backends zgomotoase

Dezvoltatorii solicită adesea numărul maxim permis de shot‑uri (de ex., 100 000) presupunând că conturile mai mari îmbunătățesc mereu acuratețea. Pe dispozitive zgomotoase, fiecare shot suplimentar implică timp de coadă suplimentar și poate fi executat după o derivație de calibrare a backend-ului, fără a oferi un beneficiu statistic. O abordare practică este să rulați un număr moderat de shot‑uri (2 000–5 000), să evaluați variația și să creșteți doar dacă intervalul de încredere rămâne prea larg.

Neglijarea activării mitigării erorilor de măsurare

Qiskit include o rutină simplă de mitigare a erorilor de măsurare care poate fi activată cu mitigate_measurement_errors=True în apelul execute. Omisirea acestui pas obligă la utilizarea numerelor brute zgomotoase, care de obicei dublează rata de eroare aparentă și forțează dezvoltatorii să compenseze cu mai multe shot‑uri.

from qiskit import execute
result = execute(optimized, backend, shots=4096,
                 mitigate_measurement_errors=True).result()

Abordarea acestor capcane de codare reduce shot‑urile pierdute și scurtează timpul total necesar pentru a obține rezultate cuantice fiabile. Pentru mai multă îndrumare privind selecția backend-ului, consultați pagina de stare IBM Quantum. Dacă aveți nevoie de un mediu sandbox pentru testarea scripturilor Qiskit, explorați simulările QuBIOS de la Qubitpage.

Flux de lucru pas cu pas pentru trimiterea unui job fiabil

1. Importă modulele necesare Qiskit și încarcă tokenul contului tău IBM Quantum folosind IBMQ.save_account și IBMQ.load_account. Aceasta înregistrează credențialele pentru sesiune.

2. Interoghează furnizorul pentru lista de backends disponibile cu IBMQ.get_provider().backends(). Filtrează lista după backend.status().operational și backend.configuration().n_qubits pentru a păstra doar dispozitivele funcționale care corespund numărului de qubiți dorit.

3. Selectează un backend care se potrivește adâncimii circuitului și bugetului de coerență, de exemplu backend = provider.get_backend('ibmq_montreal'). Verifică timpii medii T1/T2 cu backend.properties().t1 și backend.properties().t2 pentru a te asigura că dispozitivul poate susține timpul de execuție intenționat.

4. Transpilează circuitul pentru backendul ales folosind transpile(circuit, backend=backend, optimization_level=2). Transpilerul va mapa qubiții logici pe qubiții fizici și va respecta harta de corelare a dispozitivului, reducând operațiile SWAP inutile.

5. Trimite jobul cu backend.run(transpiled_circuit, shots=8192). Stochează obiectul Job returnat pentru a putea monitoriza progresul și a recupera rezultatele mai târziu.

6. Verifică statusul jobului cu job.status() până când ajunge la JobStatus.DONE. Dacă jobul eșuează, inspectează job.error_message() și ia în considerare ajustarea adâncimii circuitului sau creșterea numărului de shots.

7. Când jobul se finalizează, extrage contorii brut cu result = job.result() și counts = result.get_counts(). Aplică o etapă simplă de mitigare a erorilor de citire, cum ar fi matricea de calibrare a măsurării furnizată de CompleteMeasFitter, pentru a îmbunătăți fidelitatea.

8. Validează rezultatul comparând distribuția mitigată cu probabilitățile teoretice așteptate. Trasează rezultatele cu plot_histogram și, dacă este necesar, repetă experimentul cu un alt backend pentru a confirma consistența.

Sfat: Rulează întotdeauna un circuit „test” scurt (de exemplu, un gate X pe un singur qubit) pe backendul selectat înainte de a lansa jobul complet; acest lucru confirmă rapid că dispozitivul este accesibil și că tokenul de autentificare este încă valid.

Pentru informații mai detaliate despre comportamentul hardware-ului cuantic, vezi pagina de cercetare QuBIOS unde perechile Bell logice detectate erorile și codurile de repetiție sunt analizate pe dispozitivele IBM. Dacă ai nevoie de asistență cu configurarea contului sau depanarea joburilor, contactează-ne prin pagina de suport.

Tehnici de mitigare a erorilor pe care ar trebui să le activezi

Mitigare a erorilor de citire

Dispozitivele IBM Quantum raportează rezultate de măsurare care sunt părtinitoare din cauza imperfecțiunilor detectorului. Abordarea standard este construirea unei matrice de calibrare prin pregătirea fiecărui stadiu de bază computațional pe qubitii țintă și măsurarea distribuției rezultate. Inversa acestei matrice este apoi aplicată la numărătorii brute, corectând efectiv inversările sistematice de citire. În practică, rulezi o rutină qiskit.ignis.mitigation.readout_meas_mitigation.CalibrationFitter înainte de experimentul principal, salvezi matricea de calibrare și folosești apply pe obiectul rezultat. Această etapă adaugă doar câteva secunde suplimentare de execuție, dar poate crește fidelitatea cu 5–10 % pe dispozitivele cu rate tipice de eroare de citire de 2–4 %.

Extrapolație zero‑zgomot (ZNE)

ZNE funcționează prin întinderea artificială a adâncimii circuitului, de obicei prin inserarea perechilor de identitate sau a repetițiilor de gate, și apoi potrivirea valorilor observabile la un limită de zgomot zero. În Qiskit poți folosi qiskit.utils.ZNE cu un model de extrapolație liniară sau exponențială. Cheia este să păstrezi circuitul întins suficient de scurt încât dispozitivul să nu depășească fereastra de coerență; altfel extrapolația devine nefiabilă. Într-un cod de repetiție cu 9 qubi, aplicarea ZNE a redus rata de eroare logică de la aproximativ 3 % la circa 1,8 % când factorul de întindere a fost limitat la 1,5×, demonstrând că extrapolația modestă deja oferă câștiguri măsurabile.

Calibrare a erorilor de măsurare pentru execuții codificate

Când rulezi coduri de corecție a erorilor, cum ar fi codul de repetiție cu 9 qubi raportat în proiectul QuBIOS, măsurătorile brute de sinod își moștenesc atât părtinirea de citire, cât și erorile induce de gate. O rutină de calibrare combinată efectuează mai întâi matricea de citire pentru qubitii fizici, apoi rulează circuitul codificat cu un stadiu logic cunoscut (de ex., toate-zero) pentru a captura modul în care codul mapează erorile la sinodii măsurate. Prin aplicarea inversei matricei de citire urmată de un tabel de corecție specific decoderului, qubitul logic poate fi menținut coerent pentru ~150 µs, o îmbunătățire dramatică față de viața de 41–75 µs a unui qubit necodificat.

Listă de verificare practică

• Rulează o calibrare completă a citirii pe exact submulțimea de qubi pe care o vei folosi.
• Generează circuite întinse pentru ZNE cu un factor maxim de întindere de 1,5–2 pentru a rămâne în limitele T1/T2.
• Include o execuție de referință a circuitului codificat (de ex., |0⟩ logic) pentru a construi un tabel de corecție a erorilor de măsurare pentru cod.
• Aplică pașii de corecție în ordinea: matrice de citire → extrapolație ZNE → corecție a sinodului specific codului.

Prin integrarea acestor trei tehnici, dezvoltatorii pot obține în mod rutinișc rate de eroare logică care se apropie de pragul de 3 % raportat pentru codul de repetiție cu 9 qubi și, adesea, îl depășesc pe backend-urile noi. Pentru îndrumări suplimentare privind combinarea mitigării cu trimiterea de joburi, vezi secțiunea anterioară de flux de lucru sau contactează echipa Qubitpage prin /contact.

Compararea caracteristicilor backend-urilor IBM Quantum

Când alegi un dispozitiv IBM Quantum pentru un experiment nou, factorii cei mai decisivi sunt numărul de qubi fizici, timpii de coerență (T1 și T2) și adâncimea maximă a circuitului pe care sistemul o poate susține înainte ca decoerența să devină dominantă. Cele trei dispozitive utilizate cel mai des în cercetările recente – ibm_fez, ibm_marrakesh și ibm_kingston – diferă vizibil în aceste metrici, iar alegerea poate schimba rezultatul unui benchmark precum experimentul cu perechi Bell logic reported în proiectul QuBIOS.

Mai jos găsești o comparație concisă care evidențiază limitele practice pe care le vei întâlni când traduci un circuit Qiskit într-un job pentru fiecare backend. Valorile sunt medii preluate de pe pagina de stare a sistemului IBM din 7 nov. 2026, aceeași zi în care echipa QuBIOS a rulat aproximativ 40 de joburi pe cele trei mașini.

Toate cele trei sisteme expun aceeași topologie de 27 de qubi, dar variațiile ușoare în T1 și T2 se traduc în bugete de adâncime diferite. De exemplu, un circuit care ajunge la adâncimea 115 va rula confortabil pe ibm_fez dar va fi aproape de limită pe ibm_kingston. Când adâncimea depășește limita raportată, backend-ul trunchiază automat circuitul, ceea ce poate duce la pierderi neașteptate de fidelitate.

O altă considerație practică este ciclul de calibrare. Fiecare dispozitiv actualizează parametrii qubi-ului său aproximativ la fiecare 12 ore; trimiterea unui job imediat după o actualizare de calibrare adesea produce fidelitate mai mare deoarece valorile T1/T2 sunt la vârf. În schimb, joburile trimise spre finalul unui ciclu pot suferi de deriva, în special pe ibm_marrakesh, unde T2 medie prezintă o dispersie mai largă.

Pentru dezvoltatorii care au nevoie să ruleze rutine de mitigare a erorilor, plafonul de adâncime contează deoarece circuitelor suplimentare de corecție a erorilor de măsurare se adaugă adâncime. Pe ibm_fez poți adăuga de obicei un strat de mitigare de 20 de gate fără a depăși limita de 120 de gate, în timp ce pe ibm_kingston ar trebui să menții supraîncărcarea de mitigare sub 10 gate.

În final, alegerea backend-ului influențează timpii de coadă. Istoric, ibm_fez are o cerere ușor mai mare, rezultând timpi de așteptare medii de 30 de minute, în timp ce ibm_kingston curăță adesea în 10 minute. Echilibrul dintre capacitatea de adâncime și latența cozii este o parte cheie a fluxului de lucru descris în secțiunea 4 a acestei serii de tutoriale.

Întrebări frecvente

Care este cea mai bună modalitate de a monitoriza ratele de eroare ale qubit-urilor pe IBM Quantum?

Folosește tabloul de bord de calibrare oferit în IBM Quantum Console, care afișează T1, T2, eroarea de citire și eroarea de gate cu două qubit-uri pentru fiecare qubit. Exportează fișierul JSON zilnic și compară valorile cu un script simplu care marchează orice metrică care se abat cu mai mult de 10 % față de săptămâna precedentă. Această abordare îți permite să identifici qubit-urile deteriorate înainte ca acestea să afecteze job-urile tale.

Cât de multe „shots” ar trebui să folosesc pentru un circuit mic pentru a obține statistici fiabile?

Pentru circuite cu mai puțin de zece rezultate de măsurare, începe cu 1 000 de shots și evaluează eroarea standard a estimărilor de probabilitate. Dacă eroarea depășește 1 % din probabilitatea observată, dublează numărul de shots până când marginile scad sub acel prag. În practică, 2 000–4 000 de shots echilibrează adesea timpul de execuție și încrederea statistică pentru benchmark-uri mici.

Pot rula același circuit pe mai multe backends simultan?

IBM Quantum nu oferă o funcție „broadcast” încorporată, dar poți scrie scripturi pentru trimiterea paralelă folosind clasa Qiskit IBMQJobManager. Creează o listă de backends țintă, trimite circuitul către fiecare și colectează obiectele JobResult odată ce toate job-urile au terminat. Această paralelizare manuală îți permite să compari performanța între dispozitive într-un singur experiment.

Ce include „datele de calibrare a backend-ului” și de ce contează?

Datele de calibrare cuprind timpii de relaxare ai qubit-urilor (T1), timpii de dephasing (T2), ratele de eroare ale gate-urilor simple și cu două qubit-uri și procentele de eroare la citire. Aceste numere definesc modelul de eroare pe care Qiskit îl folosește pentru simulări de zgomot și influențează selecția qubit-urilor pentru un circuit dat. Ignorarea calibrării recente poate duce la estimări de fidelitate prea optimiste, care nu se potrivesc cu rulările reale pe hardware.

Cum știu dacă circuitul meu este prea adânc pentru dispozitivul selectat?

Verifică timpii de coerență raportate de dispozitiv și compară-i cu durata totală a gate-urilor circuitului tău, pe care o poți obține din transpile(..., optimization_level=3) și atributul duration al QuantumCircuit-ului rezultat. Dacă durata circuitului depășește aproximativ 70 % din cel mai scurt T1 dintre qubit-urile alocate, probabilitatea de erori de decoerență crește brusc. Reducerea adâncimii prin combinarea gate-urilor sau utilizarea gate-urilor nativ cu două qubit-uri aduce adesea circuitul în limita sigură.

Încheierea ghidului despre capcanele IBM Quantum

Când începi un nou proiect IBM Quantum, verifică mai întâi datele de calibrare ale dispozitivului și selectează un backend al cărui nivel de eroare se potrivește toleranței algoritmului tău. Folosește dispozitivele ibm_fez sau ibm_marrakesh pentru circuite mici, dar treci la un QPU mai mare numai după ce confirmi că adâncimea poartelor rămâne bine sub timpii de coerență raportați.

Structurează codul cu QLang sau cu primitivele standard Qiskit și validează întotdeauna circuitul transpiled înainte de trimitere. Inserează resetări de măsurare explicite și evită presupunerile implicite despre ordinea qubit-urilor; o configurație incompatibilă poate crește erorile dramatic. După fiecare execuție, compară fidelitatea observată cu linia de bază a dispozitivului (de exemplu, rezultatul de 97,7 % pentru perechea Bell logică pe IBM Kingston) pentru a detecta regresiile devreme.

În final, păstrează un set de teste mici care rulează atât pe un simulator, cât și pe hardware real, alături; această obicei detectează diferențele cauzate de modelele de zgomot sau de actualizările backend-ului. Urmând acești pași reduci timpul pierdut în coadă și îmbunătățești fiabilitatea rezultatelor.

Ești gata să explorezi mai multe instrumente practice? Vizitează pagina cea mai relevantă de pe Qubitpage pentru ghidare suplimentară.