Kalibrasyon verileri — donanımı yazılımdan okuyan sayılar katmanı

Donanım laboratuvarında fiziksel kalibrasyon Rabi salınımları, Ramsey deneyleri, randomized benchmarking gibi protokollerle yapılır. Bu sayfanın konusu o protokoller değildir; kalibrasyonun çıktısı, yani donanımı temsil eden sayılar dizisinin yazılım kenarındaki hâlidir. Qiskit, bu hâli ya doğrudan BackendV2.target nesnesi üzerinden ya da qubit başına özetler aracılığıyla sunar. Yani, bizim için kalibrasyon verisi = "donanımın şu andaki sayısal kimliği, API'den okunabilir biçimi".

"Yazılım kontrolü" perspektifi

Bu veri katmanı olmadan, transpiler bir devreyi donanıma uydururken "hangi qubit'i seçeyim, hangi kapıyı önceleyeyim?" sorularına ancak ezbere cevap verirdi. Kalibrasyon verisi, soyut planı somut donanıma bağlayan tablo'dur: devreyi yazarken yapılan tercihler, bu tablo üzerinden donanıma "anlamlı" hâle gelir.

Bu sayfanın sınırı

Burada kalibrasyonun nasıl ölçüldüğünü ya da hangi donanımın ne kadar iyi kalibre edildiğini tartışmayız; üretilen veriyi tüketim tarafında — okuma, saklama, karşılaştırma, karar — kavramsal olarak inceleriz.

Qiskit kalibrasyon verisini ikili bir yapı hâlinde sunar. Bir tarafta qubit başına alanlar vardır: QubitProperties içinde t1, t2, frequency ve (ayrı bir yoldan) okuma hatası ile okuma süresi. Diğer tarafta kapı + qargs başına alanlar vardır: InstructionProperties içinde duration (saniye), error (ortalama hata) ve isteğe bağlı puls düzeyi tarifi (calibration). Yani veri iki anahtarla indekslenir: "hangi qubit?" ve "hangi kapı, hangi qargs?".

Birimler ve "yok" değeri

Süre alanları SI saniyesindedir (örneğin 35 ns yerine 3.5e-8). Hata alanları ortalama hata oranıdır (0–1 aralığında). Bazı alanların değeri olmayabilir (cihaz raporu eksik olabilir); bu durumda alan None döner. Kalibrasyonun "tam" değil "bilinen kısım" olduğunu, eksikliği yok sayma yerine yazılı tutmak yazılımcı disiplinindendir.

İki anahtar, tek hikâye

"Bu qubit'i kullanırsam ne olur?" sorusu yalnızca qubit alanlarıyla cevaplanmaz; kullanılacak kapıların qargs üzerindeki süresi ve hatası da gerekir. Aynı qubit farklı kapı çiftlerinde farklı davranır; verinin iki anahtarlı yapısı bu gerçeği koruyarak modeller.

Kalibrasyon verisi statik dosya değildir; donanım servisleri belli aralıklarla ölçümleri yeniler ve sonuçları API üzerinden açar. Yazılım tarafında "backend'i çağırdığımda hangi veri geliyor?" sorusunun cevabı, sağlayıcının raporlama politikasına bağlıdır: bir backend nesnesi oluşturulduğunda alınan değer, ileride aynı nesne kullanılsa bile genellikle oluşturma anının kalibrasyonunu taşır. Daha yeni veri için backend nesnesinin tekrar alınması ya da sağlayıcının yenileme yöntemine başvurulması gerekir.

Süreç tarafı: snapshot mantığı

Yaşam döngüsü pratiğinin sağlam bir yolu, her iş başlatımı sırasında bir anlık görüntü almak ve onu deney kayıtlarıyla birlikte saklamaktır. Böylece "15 Mayıs 02:18 itibarıyla şu cihazın şu kalibrasyonu" diyebilir, saatler sonra okunan farklı sayıların algoritmanın değil "kalibrasyonun değişmiş olmasının" sonucu olduğunu somut belgeyle gösterebilirsiniz.

Servis vs cihaz

Servisin yenileme aralığı ile cihazın gerçekten tekrar kalibre edilme anı her zaman çakışmaz. Bu yüzden bir alanın "son güncelleme" zaman damgası, alanın o tarihten daha eski bir değerle gelmesini engellemez; servisin yayın tarihi başkadır, ölçüm tarihi başkadır.

Süperiletken qubit'lerin frekansı, T1/T2 süreleri, kapı hataları zamanla sürüklenir: ortam etkileri, soğutucu durumu, sinyal hatları, son kalibrasyondan bu yana geçen süre, hepsi birer faktördür. Yazılım kenarında "drift" bir hata değil, doğal bir veri özelliğidir. Bu yüzden okunan değerlerin yaşına dikkat etmek; üç saat önce alınmış bir snapshot ile şimdiki snapshot'ın aynı olduğunu varsaymamak gerekir.

Stale = bayat

Stale veri, eski veri demektir. Otomasyon pipeline'ında bayat veri sessiz hataya yol açar: transpiler dünkü hatalar üzerinden bugünün kararını verir. Çare; "her job için canlı veri çek, snapshot'a yaz, sonuca eşliğinde sakla" disiplinidir.

Drift'in kapsamı

Süre alanları (kapı süresi, okuma süresi) görece kararlıdır; hata alanları daha değişkendir. T1/T2 saatten saate ciddi değişebilir. Bu hiyerarşi, "hangi alana ne sıklıkta güveneceğim?" sorusunu da kuruyor: süreyi planlamak güvenli, hatayı "şu an" okumadan kullanmak risklidir.

Snapshot = bir andaki kalibrasyon değerlerinin tüm önemli alanlarıyla beraber serileştirilmiş hâli. Bir snapshot tipik olarak: cihaz adı, alındığı zaman damgası, qubit başına T1/T2/freq ve okuma hatası, (kapı, qargs) için duration ve error, kullanılan kapı seti ve coupling map'tir. Arşiv ise bu snapshot'ları bir dosyaya/günlüğe yazma, sonradan karşılaştırma ve rapora ekleme pratiğidir.

Diff'in değeri

İki snapshot arasındaki fark, "iki ay önce bu kenarın hatası 5e-3 idi, şimdi 8e-3" gibi gözleme imkân tanır. Bu fark, deneyin yeniden üretilme sürecinde "cihaz koşulları değişti" cümlesinin sayıyla ifade edilmiş hâlidir.

Format seçimi

Snapshot için en sade biçim JSON benzeri bir sözlüktür: insan okuyabilir, otomasyon kolayca tüketir. Süre değerlerini saniye, hata değerlerini 0–1, zaman damgasını ISO 8601 tutmak yıllar sonra okunabilirliği artırır.

Kalibrasyon verisini "okuyup geçmek" yerine, ondan karar üretmek mümkündür. Tipik bir karar: aynı topoloji altında bağlı 3 qubit'lik bir yol kullanacağız; en uygun yolu seçmek. Burada kriter cihazın "genel kalitesi" değil, "biz hangi kenarları gerçekten kullanacağız?" sorusudur. Bu kenarların hatalarının toplamını minimuma indirgemek, alacağımız sayıların bilimsel zeminini güçlendirir.

"Ortalama" tuzağına düşmemek

"Cihaz şu kadar hatalı" özet bir bilgidir; deneyiniz açısından kullandığınız yolun hatası kritiktir. Bir cihazın çok iyi qubit'leri ile çok kötü qubit'leri yan yana yaşayabilir; ortalama, kararı yanıltabilir.

Karar yardımı vs son söz

Hatadan yola çıkan seçim her zaman doğru olmayabilir; topoloji uyumu, ölçüm hatası, beklenen SWAP yükü ile birleştirilmelidir. Kalibrasyon verisi karar yardımıdır; son söz, algoritmanın gereksinimleriyle birlikte verilir.

İdeal simülatörlerin (örneğin AerSimulator'ün varsayılan modu) kalibrasyon verisi yoktur; çünkü hata modeli aktif değildir. FakeBackend nesneleri ise gerçek bir cihazın belirli bir andaki kalibrasyonunun donmuş kopyasını taşır; bu hem topoloji hem süre/hata alanlarını içerir. Yani: ideal sim → yok, FakeBackend → donmuş anlık, gerçek cihaz → canlı.

Eğitim ekseni

Yerel çalışmada okunabilen sayıların "bugün gerçek cihazı temsil ettiğini" varsaymamak gerekir. Ama "kalibrasyon API'sinin kendisini" anlamak ve karar mantığını alıştırmak için FakeBackend yeterli bir oyun alanıdır.

Modeli özelleştirmek

İleri düzey yerel deneyler için, sahte modeldeki sayıları elle değiştirip "daha kötü" ya da "daha iyi" cihaz hayal etmek de mümkündür. Bu, kalibrasyonun karar üzerindeki etkisini izole etmenin pratik bir yoludur.

Kalibrasyon verisinin raporda yer alması, deneyin tekrar üretilebilirlik zeminidir. Bir başkası ya da gelecekteki siz, aynı algoritmayı aynı snapshot üzerinde ardışık kararlarla yeniden inşa edebilir. Bu, "aynı sonuç" garantisi vermez — gerçek cihaz o gün başka olur — ama "aynı bağlam" garantisi verir.

Asgari rapor seti

Bir akademik veya iç raporun kalibrasyon kısmında olması beklenen alanlar: cihaz adı, snapshot zamanı, kullanılan qubit indeksleri, bu qubit'lerin T1/T2 ve okuma hataları, kullanılan iki-qubit çiftlerinin kapı süresi ve hataları, transpile seçenekleri ve seed. Bu liste "makale tarzı" değil, "üç ay sonra anlamı korunsun" kuralıyla seçilmiştir.

Veriden anlatıya

Snapshot'tan üretilen birkaç özet sayı (örneğin "seçilen yoldaki toplam cx hatası") raporun okurluğunu artırır. Sayılar baş düzeyde özetlenir, detay tabloya bırakılır.

Üç blok da yereldir. İlk blok kalibrasyon snapshot'ını ham hâliyle ekrana özetler: qubit başına T1/T2/freq ve okuma hatası + (cx, qargs) için duration/error. İkinci blok aynı snapshot'ı tekrarlanabilir bir sözlüğe sarar ve JSON metnine çevirir (dosya yazımı ekleyebilirsiniz). Üçüncü blok belirli uzunluktaki bağlı qubit yollarını arar ve iki-qubit hatasının toplamına göre sıralar; "en az toplam hatayla 3-qubit yolu hangisi?" sorusunun yerel cevabıdır.

# from qiskit_ibm_runtime import QiskitRuntimeService
# service = QiskitRuntimeService()
# backend = service.backend("ibm_brisbane")
# target  = backend.target
# qp      = backend.qubit_properties(0)
# print(qp.t1, qp.t2, qp.frequency)
# print(target["cx"][(0, 1)].duration, target["cx"][(0, 1)].error)

from qiskit_ibm_runtime.fake_provider import FakeManilaV2

backend = FakeManilaV2()
target  = backend.target

print(f"# cihaz: {backend.name} · qubit={backend.num_qubits}\n")
print("qubit  T1 (µs)   T2 (µs)   freq (GHz)")
for q in range(backend.num_qubits):
    qp = backend.qubit_properties(q)
    t1 = qp.t1 * 1e6     if qp.t1 is not None else float("nan")
    t2 = qp.t2 * 1e6     if qp.t2 is not None else float("nan")
    fr = qp.frequency * 1e-9 if qp.frequency is not None else float("nan")
    print(f"  {q:>2}   {t1:7.2f}   {t2:7.2f}   {fr:8.4f}")

print("\ncx qargs    duration (ns)   error")
cx_rows = target.get("cx", {}) or {}
for qargs, p in list(cx_rows.items())[:6]:
    dur = p.duration * 1e9 if p and p.duration is not None else float("nan")
    err = p.error           if p and p.error    is not None else float("nan")
    print(f"  {str(qargs):>8}  {dur:>12.1f}   {err:.2e}")

import json, time
from qiskit_ibm_runtime.fake_provider import FakeManilaV2

backend = FakeManilaV2()
target  = backend.target

def _none_or(v):     # None'ı JSON için temiz tutar
    return None if v is None else float(v)

snapshot = {
    "device":    backend.name,
    "captured":  time.strftime("%Y-%m-%dT%H:%M:%S"),
    "num_qubits": backend.num_qubits,
    "basis":     sorted(target.operation_names),
    "qubits": {
        q: {
            "t1":        _none_or(backend.qubit_properties(q).t1),
            "t2":        _none_or(backend.qubit_properties(q).t2),
            "frequency": _none_or(backend.qubit_properties(q).frequency),
        }
        for q in range(backend.num_qubits)
    },
    "gates": {
        name: {
            str(list(qargs)): {
                "duration": _none_or(p.duration if p else None),
                "error":    _none_or(p.error    if p else None),
            }
            for qargs, p in (target.get(name, {}) or {}).items()
        }
        for name in ("sx", "rz", "x", "cx") if name in target.operation_names
    },
}

print(json.dumps(snapshot, indent=2)[:800], "...")

from collections import defaultdict
from qiskit_ibm_runtime.fake_provider import FakeManilaV2

backend = FakeManilaV2()
target  = backend.target
edges   = list(backend.coupling_map.get_edges())

# Yön bağımsız ortalama cx hatası (her kenar için)
edge_err = {}
for (a, b) in edges:
    ps = []
    for q in ((a, b), (b, a)):
        p = target.get("cx", {}).get(q)
        if p and p.error is not None:
            ps.append(p.error)
    if ps:
        edge_err[frozenset((a, b))] = sum(ps) / len(ps)

# Komşu listesi
adj = defaultdict(set)
for a, b in edges:
    adj[a].add(b); adj[b].add(a)

# 3-qubit yol: a — b — c
paths = []
for b in adj:
    for a in adj[b]:
        for c in adj[b]:
            if a == c or a >= c:
                continue
            e1 = edge_err.get(frozenset((a, b)))
            e2 = edge_err.get(frozenset((b, c)))
            if e1 is None or e2 is None:
                continue
            paths.append(((a, b, c), e1 + e2))

paths.sort(key=lambda x: x[1])
print("en iyi 5 yol (toplam cx hatası):")
for path, total in paths[:5]:
    print(f"  {path}   toplam_err={total:.3e}")

Kalibrasyon verisi, donanımın yazılım tarafındaki sayısal kimliğidir. İki anahtarla (qubit ve (kapı, qargs)) indekslenir; süre saniyede, hata 0–1 aralığındadır. Sürüklenir, eski olur ("stale"), bu yüzden her iş başlatımıyla beraber bir snapshot alıp arşivlemek bilimsel disiplinin parçasıdır. Karar tarafında "ortalama" yerine "kullandığım yol" sorulur. Yerel FakeBackend üzerinde API yapısı ve karar mantığı hesap gerektirmeden öğrenilebilir.

• Backend özellikleri — aynı verinin alanlara ayrılmış genel tanıtımı.
• Backend mimarisi — Target nesnesi ve sözleşme.
• Coupling map — topolojinin karar tarafındaki yüzü.
• Backend seçimi — snapshot'tan kararlı seçim adımları.
• Soğutma ve kalibrasyon — fiziksel arka plan.
• Aer simülatörü ve Fake backend kullanımı — yerel oyun alanı.