Backend seçimi — algoritmayı doğru cihazla eşleştiren karar süreci

Önümüzde tek bir devre, karşımızda ise farklı kabiliyetlere, farklı topolojilere, farklı yoğunluk ve uygunluk durumuna sahip birden çok cihaz vardır. Backend seçimi bu çokluğu, devreye uygun bir aday listesine indirgeyen ve listeyi en olası başarıya göre sıralayan bir karar problemidir. "En iyi cihaz" diye soyut bir sayı yoktur; ancak "bu algoritma + bu zaman + bu bütçe için en iyi aday" vardır.

Üç dünyanın kesişimi

Karar üç dünyanın kesişiminde verilir: algoritmanın gereksinimi (qubit, kapı, etkileşim grafı, hata bütçesi), cihazın sözleşmesi (target — qubit sayısı, native kapı seti, coupling map), ve sistemin anlık durumu (kuyruk, uygunluk, son kalibrasyon). Bu üç ekseni aynı tabloya koymadan verilen kararlar genellikle "cihazın daha büyüğünü seçme" tuzağına düşer.

Karar problemi olarak çerçeveleme

Seçimi bir karar problemi olarak yazınca üç temel öğe çıkar: aday kümesi (hangi cihazlar bakılır?), kabul edilebilirlik koşulu (sert filtreler) ve tercih sıralaması (yumuşak skor). Bu çerçeve, kararı belgeleyebilmenin ve sonra gözden geçirebilmenin de zeminidir.

Karar tarafında ilk adım, algoritmanın sayısallaştırılabilir gereksinimini çıkarmaktır. Asgari liste şudur: ihtiyaç duyulan mantıksal qubit sayısı, kullanılan kapı kümesi (özellikle iki-qubit kapısı tercihleri), etkileşim grafı (hangi mantıksal qubit'ler arasında iki-qubit kapısı var?), beklenen iki-qubit kapı sayısı ve buna bağlı derinlik tahmini, hedeflenen hata bütçesi (ne ile yetinilir?) ve klasik bağlam (örneğin dinamik devre kullanılacak mı?).

Mantıksal vs fiziksel

Gereksinim mantıksal sayılarla yazılır; karar ise fiziksel donanım sayılarına dönüşür. Mantıksal etkileşim grafı, fiziksel coupling map'e gömüldüğünde "kaç SWAP eklenir?" ve "hangi qubit yolunu işgal eder?" soruları somutlaşır. Bu dönüşüm coupling map sayfasındaki layout + routing fikrinin doğrudan tüketimidir.

Bütçe tanımı

"Hata bütçesi" soyut bir niyet değildir; iki sayıdan oluşur: kabul edilen ortalama iki-qubit hata oranı ve kullanılacak iki-qubit kapı sayısının üst sınırı. İkisinin çarpımı, genel hata yığını için kaba bir tahmin verir; bu tahmin, "bu algoritma bu cihazda anlamlı bir cevap üretebilir mi?" sorusunun kapısıdır.

Sert filtreler, "bu cihaz aday bile olamaz" diyen evet/hayır kararlarıdır. Tipik filtreler: num_qubits ≥ gerekli mantıksal qubit, basis_gates ⊇ kullanılan kapılar, operasyonel uygunluk (çalışıyor mu? kullanıma açık mı?), dinamik devre gereksiniminin desteklenmesi, kullanım türünün izin verdiği "simülatör" vs "donanım" ayrımı.

Filtre vs skor

Sert filtre ile yumuşak skor karıştırılmamalıdır. "Hata oranı yüksek" tek başına bir cihazı dışlamak için yetersiz bir gerekçedir (yumuşaktır); "qubit sayısı yetmiyor" ise dışlamak için yeterli ve nettir (serttir). Sert filtre listesi kısa ve "tartışmasız" olmalıdır; gri alana giren her şey skora bırakılır.

Şüpheli operasyonel durum

Operasyonel durum, sıkça atlanan bir filtredir. "Aday gözüküyor ama bakımda" durumu, tüm hesabı yere düşürür. Karar sürecine "operasyonel = doğru" ön kontrolünü eklemek, hem süre kaybını hem hatalı yorumu önler.

Sert filtrelerden geçen cihazlar arasında bir tercih sıralaması yapmak için yumuşak skor kullanılır. Yaygın bileşenler: iki-qubit hata profili (kullanılacak yol üzerindeki ortalama cx hatasının düşük olması), kuyruk yoğunluğu (sıra ne kadar uzun?), topoloji uyumu (algoritma grafı ile coupling map ne kadar örtüşür → SWAP yükü ne kadar düşük?), okuma hatası, coherence ve görece daha ayrıntılı: kalibrasyon yaşı (bayat veri risk).

Tek metrik tuzağı

"En iyiyi" tek bir sayıya indirgemek karar süreçlerinin en yaygın hatasıdır. Tek metrik (örneğin sadece "cx hatası") gerçek hayatın çok eksenli yapısını yansıtmaz. En sade ama sağlam yaklaşım, normalize edilmiş birkaç eksenden ağırlıklı toplam üretmektir.

Pareto cephesi sezgisi

Bazı durumlarda iki cihaz arasında "hata daha iyi, kuyruk daha kötü" ya da tersi olur; bu çift, Pareto cephesi üzerindedir, ikisi de "ezilemez". Karar ağırlıkları, hangi yöne yatkın olunduğunu belirler: deneyin aciliyet'i mi, doğruluğu mu önde?

Farklı eksenlerden ortak bir skor üretmek için iki adım gerekir: normalizasyon (örneğin "0 = en iyi, 1 = en kötü" gibi tek aralığa indirgemek) ve ağırlıklandırma (eksenlerin hangi oranda toplanacağı). Normalizasyon olmadan hata oranı (10⁻³) ile kuyruk uzunluğu (50 iş) birbirini ezecek; ağırlık olmadan eşit hak verilecektir.

Ağırlıkları açıkça yazmak

Karar süreçlerinde ağırlıklar genellikle "aklımdaydı" mertebesinde kalır. Bunu raporlanabilir kılmak için tek bir sözlük yeterlidir: w = {"err": 0.5, "queue": 0.3, "swap": 0.2}. Sözlüğün kendisini deneye yapıştırınca, "seçimi ne ile yaptın?" sorusu bir saniyede cevaplanır.

Mutlak değer değil sıralama

Çıkan toplam skorun mutlak değeri değil, cihazlar arasındaki sıralaması önemlidir. Bu nedenle ağırlıkları "ince ayar" yapmak yerine, "aday değişiyor mu?" sorusu üzerinden kalibre etmek pratik bir yöntemdir.

Karar tek bir cihazla bitmez; pratik akış aday listesi + fallback biçimindedir. İlk aday operasyonel değilse, kuyruğu beklenmedik biçimde uzunsa, session açılamıyorsa ya da iş hatayla geri dönerse, ikinci aday devreye girer. Bu zincirin önceden tasarlanması, üretim akışını çökmekten kurtarır.

Zincirin nezaketi

Fallback yalnızca "sırada kim var?" değil, "ikinci aday için karar yeniden mi alınmalı?" sorusunu da içerir. İkinci adayın hata profili çok farklıysa, transpile, parametre seçimi ve hatta shots sayısı yeniden değerlendirilmeli olabilir.

Sınır koyma

Zincir sonsuz olmamalıdır; iki ya da üç adımdan sonra "bugün uygun değil" cümlesi geçerli bir cevaptır. Otomatik bir akışın "denemeye devam et" davranışı, karar disiplinini değil ısrarcılığı temsil eder.

Seçim, bir kerelik karar değildir; belirli koşullarda yeniden gözden geçirilir. Tipik tetikleyiciler: cihazın kalibrasyonu yenilendi (snapshot eskidi), kuyruk beklenmedik biçimde uzadı, iş FAILED ile döndü, algoritmanın gereksinimleri değişti (örneğin yeni bir versiyon daha az iki-qubit kapısı kullanıyor). Bu olaylar karar sürecini yeniden başlatma sinyalidir.

Süre tabanlı yenileme

"Snapshot şu kadar saatten eski ise karar yeniden alınır" cümlesi, ardışık işlerde kalibrasyon sürüklenmesinin sessiz etkilerini kapatır. Süre eşiği, deneyin doğruluk duyarlılığına göre belirlenir: hassas işlerde dakikalar, prototip işlerde saatler uygun olabilir.

Olay tabanlı yenileme

FAILED bir iş, yalnızca yeniden gönderim değil, yeniden seçim için de iyi bir tetikleyicidir. Aynı cihaza körü körüne yeniden göndermek yerine, kararı sıfırlayıp aday listesinden geçmek daha sağlamdır.

Backend seçimi, seçim sonucundan ibaret değildir; seçimin gerekçesi de raporun parçasıdır. Karar günlüğü, "aday listesi, sert filtreler, skor tablosu, ağırlıklar, kazanan ve fallback" alanlarını tutar. Bu kayıt, aynı günlerce sonra başka bir okuyucunun seçimi anlamasını sağlar; aynı zamanda "aynı koşulda farklı kişi farklı seçer mi?" sorusunun gerçek cevabıdır.

Asgari günlük şeması

En sade biçimde günlük: zaman damgası, algoritma kimliği, gereksinim sözlüğü, adayların metrik tablosu, ağırlık sözlüğü, sıralı sonuç, kazanan, kazananın snapshot referansı. Bu liste yine "üç ay sonra okunur" kuralıyla seçilir.

Karar şeffaflığı

Karar şeffaflığı, seçimin sezgiyle değil bağlamla yapıldığını gösterir. Aynı zamanda başkalarının kararı sorgulamasına ve ek metrik önerilerine yer bırakır. Bu, kuantum bilgisayar mimarisini yazılım üzerinden kontrol etmenin bilimsel etiğidir.

Üç blok da yereldir. İlk blok algoritmanın gereksinim sözlüğünü yazıp birkaç FakeBackend üzerinde sert filtreyi geçirir. İkinci blok geçen adayları yumuşak skorla sıralar (hata + kuyruk vekili + topoloji uyumu için basit metrikler). Üçüncü blok aynı seçimi küçük bir fallback zinciri ile sarar: ilk aday "uygun değil" olursa otomatik olarak ikinciye düşer.

# from qiskit_ibm_runtime import QiskitRuntimeService
# service = QiskitRuntimeService()
# adaylar = [b for b in service.backends() if b.num_qubits >= 5 and b.operational]
# secilen = service.least_busy(min_num_qubits=5, simulator=False)
# print(secilen.name)

from qiskit_ibm_runtime.fake_provider import FakeManilaV2, FakeBelemV2

requirement = {
    "num_qubits":   3,
    "uses_gates":   {"sx", "rz", "x", "cx"},
    "needs_dynamic": False,
}

candidates = [FakeManilaV2(), FakeBelemV2()]

def passes_capability(backend, req):
    if backend.num_qubits < req["num_qubits"]:
        return False
    native = set(backend.target.operation_names)
    if not req["uses_gates"].issubset(native):
        return False
    return True

for b in candidates:
    ok = passes_capability(b, requirement)
    print(f"{b.name:>14}  uygun={ok}")

from qiskit_ibm_runtime.fake_provider import FakeManilaV2, FakeBelemV2

# Sentetik (yerel öğretim için) yoğunluk verisi: kuyruk uzunluğu
fake_queue = {"fake_manila": 12, "fake_belem": 4}

def avg_cx_error(backend):
    rows = backend.target.get("cx", {}) or {}
    errs = [p.error for p in rows.values() if p and p.error is not None]
    return sum(errs) / len(errs) if errs else 1.0

def graph_overlap(backend, interaction):
    edges = {frozenset(e) for e in backend.coupling_map.get_edges()}
    needed = {frozenset(e) for e in interaction}
    return len(edges & needed) / max(1, len(needed))

def score(backend, interaction, weights):
    err   = avg_cx_error(backend)
    queue = fake_queue.get(backend.name, 50) / 50.0
    swap  = 1.0 - graph_overlap(backend, interaction)
    return weights["err"] * err + weights["queue"] * queue + weights["swap"] * swap

interaction = [(0, 1), (1, 2)]              # mantıksal etkileşim grafı
weights     = {"err": 0.5, "queue": 0.3, "swap": 0.2}

ranked = sorted([FakeManilaV2(), FakeBelemV2()],
                key=lambda b: score(b, interaction, weights))
for b in ranked:
    s = score(b, interaction, weights)
    print(f"{b.name:>14}  skor={s:.4f}  (düşük = daha iyi)")

from qiskit_ibm_runtime.fake_provider import FakeManilaV2, FakeBelemV2

# Sentetik operasyonel durum (yerel öğretim için)
operational = {"fake_manila": False, "fake_belem": True}

def passes_capability(backend, req):
    if backend.num_qubits < req["num_qubits"]: return False
    if not req["gates"].issubset(set(backend.target.operation_names)): return False
    return True

def is_operational(backend):
    return operational.get(backend.name, True)

req = {"num_qubits": 3, "gates": {"sx", "rz", "x", "cx"}}
priority_chain = [FakeManilaV2(), FakeBelemV2()]    # önce manila, sonra belem

chosen = None
log    = []
for b in priority_chain:
    cap = passes_capability(b, req)
    op  = is_operational(b)
    log.append((b.name, cap, op))
    if cap and op:
        chosen = b
        break

print("karar günlüğü:")
for name, cap, op in log:
    print(f"  {name:>14}  capability={cap}  operational={op}")
print("\nseçilen:", chosen.name if chosen else "uygun aday yok")

Backend seçimi, devre + an + bütçe üçlüsünü cihaz adayına çeviren karar problemidir. Sert filtreler "aday olmaz" diyenleri eler; yumuşak skor "aday olanları sırala" der. Ağırlıklar açık, fonksiyon saf, sonuç loglanırsa süreç bilimsel kalır. Çoklu aday + fallback zinciri akışın çökmesini önler; yeniden seçim tetikleyicileri (snapshot eskimesi, FAILED iş, kuyruğun şişmesi) süreci canlı tutar.

• Backend özellikleri — kararın girdi tablosu.
• Kalibrasyon verileri — skora beslenen "kullandığım yol" hatası.
• Coupling map — topoloji uyumu metriği.
• Queue mantığı — kuyruk vekili nasıl yorumlanır?
• Job sistemi — FAILED durum ile yeniden seçim birleşimi.
• Fake backend kullanımı — yerel karar simülasyonu.