Estimator ilkeli — Gözlemlenebilir için beklenen değer

Estimator ilkeli, hazırlanmış bir kuantum devresi ve seçilen gözlemlenebilirler için beklenen değerleri ⟨O⟩ tahmin etmek üzere tasarlanmış soyut bir arayüzdür. Gözlemlenebilirin Pauli açılımı, ölçüm dönüşümleri ve cebirsel incelikler gözlemlenebilir değerlendirme dosyasında kalır; bu sayfa çağrı yüzeyi, skaler sonuç okuması ve yerel referans yürütücüyü işler. Ölçüm histogramı ve bit dizisi dağılımı Sampler ilkeli konusudur.

Estimator düşüncesinin merkezinde Hermit operatör bekleneni vardır: durum ρ üzerinde verilen O için Tr(ρ O) sayısına yaklaşan bir tahmin üretilir. Bu, aynı devreyi Sampler ile çalıştırdığınızda elde edeceğiniz frekans tablosunun yerine geçmez; iki çıktı türü birbirini tamamlar. Varyasyonel eğitim, spektral boşluk tahmini veya maliyet fonksiyonu gibi akışlarda Estimator doğrudan gradyan veya enerji sorusuna bağlanır.

Sayfa sınırı şu şekilde çizilir: gözlemlenebilir cebirinin tam türetimi, transpilasyon ayrıntıları veya belirli bir bulut uç noktası burada sabitlenmez; amaç, Estimator’ı Sampler’dan ve gözlemlenebilir teorisinden ayırmaktır. Böylece metin, ilkel iş akışları ve toplu yürütüm sayfalarıyla gereksiz tekrar etmez.

İş akışı bağlamı

Ardışık çağrıların düzenlenmesi ilkel iş akışları ve oturum başlıklarında; kuyruk ve kimlik Runtime işleri ile ilişkilidir.

Estimator tipik olarak “aynı veya benzer devre ailesi için bir dizi ⟨Oᵢ⟩ iste” döngüsünün içindedir. Klasik optimizasyon adımı ilkelin dışında kalır; fakat hibrit iş akışları içinde Estimator çıktısı doğrudan kayıp fonksiyonuna beslenir. Bu sayfa o optimizasyonun matematiğini vermez, yalnızca ilkelin sorumluluk alanını netleştirir.

Ne vaat edilmez

Burada üretim anahtarı yönetimi, fiyatlandırma veya bölgesel uç nokta sabitlenmez; IBM Quantum Platform belgeleri kaynak kabul edilir.

Sürüm notları ve paket adları sık güncellenir; tek bir “doğru import” kilidi yerine kavramsal sözleşme anlatılır. Donanımda hata azaltma veya dinamik devre seçenekleri hata azaltma ile birlikte okunmalıdır; Estimator yalnızca beklenen değer tahmininin omurgasıdır.

Sampler ölçüm sonucu uzayında örnekleme dağılımı üretir; Estimator ise verilen Hermit gözlemlenebilirler için beklenen değeri raporlar. İkisi aynı devreyi paylaşsa bile dönüş nesnesi farklıdır; bu sayfa Estimator tarafını merkeze alır ve Sampler ile karşılaştırmayı Sampler ilkeli dosyasına havale ederek tekrarı keser.

Pratik seçim şöyle özetlenebilir: maliyet fonksiyonu Pauli (veya lineer kombinasyon) cümleleriyle yazılmışsa ve gradyan / enerji yüzeyi sorusu doğrudan ⟨O⟩ biçimindeyse Estimator doğal adaydır. “Hangi bit dizisi ne kadar sık” veya tam dağılım tabanlı bir doğrulama gerekiyorsa Sampler öne çıkar. İki ilkel aynı hibrit döngüde farklı adımlarda bulunabilir; önemli olan çıktı türünü karıştırmamaktır.

Ortak sözleşme şudur: her ikisi de PUB benzeri birimlerle toplu çağrılabilir, sonuçlar PrimitiveResult ailesinde döner ve indeks sırası gönderim sırasına bağlıdır. Fakat Estimator sonucunda okunacak alanlar dağılım yerine beklenen değer ve ona eşlik eden belirsizlik özetleridir; bu okuma modeli bu sayfanın 4. bölümünde açılır.

Gözlemlenebilir cebir

Pauli tabanı ve sezgiler Pauli sayfasında; gözlemlenebilir oluşturma, ölçüm tabanı ve açılım ayrıntıları gözlemlenebilir değerlendirme ile sınırlıdır. Burada yalnızca Estimator çağrısında listenin nasıl paketlendiği ve skaler dizinin hangi sırayı izlediği vurgulanır.

Çok terimli bir Hamiltonyen tek bir SparsePauliOp olarak verilebileceği gibi, ayrı ayrı Pauli terimleri listesi olarak da verilebilir. Seçim, klasik tarafın türev veya katsayı güncellemesi nasıl yazıldığına bağlıdır; ilkel açısından ikisi de “birden çok beklenen değer” üretme isteğidir.

Shot ve varyans

Donanım veya örneklemeli yürütücülerde ⟨O⟩ tahmini shot sayısına bağlı bir belirsizlik taşır; ideal StatevectorEstimator yolunda ilgili standart sapma sıfıra yaklaşır. Shot dilinin sezgisi shot mantığı sayfasında kalır; burada yalnızca Estimator çıktısındaki stds alanının bu sezgiye paralel okunduğu belirtilir.

Aynı shot bütçesiyle Sampler histogramı ve Estimator ⟨O⟩ birlikte düşünüldüğünde, birinden diğerine türetim genel olarak otomatik değildir; özellikle çok ölçüm veya hata azaltma katmanları devredeyken eşleştirmeyi zorlamamak gerekir.

Estimator tarafında her bir yürütme birimi tipik olarak devre ve o devre üzerinde değerlendirilecek gözlemlenebilirlerin listesi ile paketlenir. Parametreli ailelerde önce assign_parameters ile somut açılar üretilir veya ilkelin desteklediği biçimde parametre değerleri ayrı taşınır; bu sayfadaki laboratuvar bağlanmış devre kullanır.

PUB düşüncesi yine “yayımlanabilir birim”dir: tek run çağrısında birden çok (devre, gözlemlenebilirler) çifti gönderilebilir. Dönüşte her birimin sonucu aynı sırayla gelir; klasik kodda indeks eşlemesi, Sampler ile aynı disiplini gerektirir. Fark, her yuvada histogram yerine beklenen değer vektörü ve eşlik eden belirsizlik alanlarının bulunmasıdır.

Gözlemlenebilir temsilinde SparsePauliOp yaygındır; terim sayısı arttıkça klasik tarafın ⟨Oᵢ⟩ dizisini nasıl ağırlıklandırdığınız (enerji, kısıt, düzenlileştirme) ayrı bir tasarım kararıdır. Estimator bu ağırlıkları bilmez; yalnızca istenen terimlerin beklenenlerini döndürür.

Çoklu PUB ve toplu iş

Birden çok PUB, farklı hazırlıklar veya aynı devrenin farklı parametrizasyonları için toplu değerlendirme sağlar; toplu yürütüm başlığı aynı desenin ölçeklenmesini işler.

Çoklu PUB kullanırken gözlemlenebilir listelerinin her PUB için uyumlu boyutta ve aynı semantik sırayla verildiğinden emin olunması gerekir. Aksi halde klasik taraf yanlış terimi yanlış katsayıyla eşleştirir; hata çoğu zaman sessizdir.

Seçenekler ve bütçe

Shot sayısı, rastgele tohum veya hata azaltma seçenekleri yürütücüye göre değişir; burada yalnızca “daha fazla shot → genelde daha düşük ⟨O⟩ varyansı” sezgisi sabittir. Bütçe planlaması shot mantığı ile birlikte düşünülmelidir.

Aynı toplam shot’ı Sampler ve Estimator arasında paylaştırmak mümkün olsa da anlamlı bir optimizasyon stratejisi gerektirir; bu sayfa o paylaştırımın formülünü vermez. Önce referans ⟨O⟩, sonra donanım ⟨O⟩ ile kıyaslama tipik bir doğrulama sırasıdır.

Qiskit 2.x çizgisinde Estimator sonucu da PrimitiveResult kapsayıcısıdır; her PUB için veri tipik olarak DataBin içinde taşınır. Beklenen değerler evs (expectation values), buna eşlik eden standart sapma özetleri stds alanında okunur; bu sayfa histogram veya get_counts() yolunu işlemez — o Sampler konusudur.

evs dizisinin uzunluğu, ilgili PUB’da istenen gözlemlenebilir sayısıyla eşleşmelidir. Sıra, gönderilen liste sırasına bağlıdır; klasik optimizasyon kodu bu sırayı sabitlemeden türev zinciri kuralı uygulayamaz. stds alanı örneklemeli yürütücülerde anlamlıdır; ideal statevector yolunda sıfıra yakın değerler görülmesi beklenir.

Sonuç okurken üç tuzak sık görülür: PUB sırası ile sonuç sırasının karışması; gözlemlenebilir sırasının katsayı sırasıyla uyumsuzluğu; ⟨O⟩’yi dağılımdan “elle türetilmiş” sanarak hata azaltma katmanlarını göz ardı etmek. İlk ikisi kod düzeniyle, üçüncüsü ise yorum disipliniyle giderilir.

Doğruluk ve referans

Küçük devrelerde StatevectorEstimator ile kapalı form veya bilinen spektral özelliklerle kıyaslama, entegrasyon hatasını erken yakalar. Sadakat veya durum tabanlı testler yardımcı olabilir; fakat ⟨O⟩ doğrudan “durum sadakati” ile aynı metrik değildir.

Donanıma geçerken ⟨O⟩ sapması hem gürültü hem de ölçüm/transpilasyon tasarımından kaynaklanır; bu ayrıştırma hata azaltma ve donanım belgeleriyle birlikte yürütülür. Estimator yalnızca tahmin arayüzüdür.

Metadaten ve teşhis

Yürütücüler ek meta alanları taşıyabilir; sürüme göre adlar değişebilir. Üretimde günlüklemeye ⟨O⟩, std ve iş kimliğini birlikte yazmak, regresyonları izlemeyi kolaylaştırır. Bu sayfa belirli bir meta şemasını sabitlemez.

Hibrit döngülerde kayıp fonksiyonu genelde ⟨O⟩’lerin lineer kombinasyonudur; katsayıları klasik taraf yönetir. Estimator tarafında yapılacak iş, doğru terimleri doğru sırada istemek ve dönen vektörü aynı sırayla işlemektir.

Öğretim ve test için StatevectorEstimator, durum vektörü üzerinden ⟨O⟩’yi gürültüsüz hesaplar; bu, donanımın örneklemeli gerçeğinin yerine geçen matematiksel referans yoludur. Gürültülü emülasyon veya donanım öncesi doğrulama için Aer tabanlı yürütücüler düşünülür; sınıf adları kurulumunuza göre değişebileceği için burada sabitlenmez.

Statevector yolu, kübit sayısı arttıkça bellek ve süre açısından üstel maliyet taşır; fakat küçük devrelerde hızlı iterasyon ve birim test için idealdir. Burada ⟨O⟩’nin “gerçek” referansı, verilen devre ve gözlemlenebilir tanımının matematiksel sonucudur; shot ile gelen belirsizlik bu yolda anlamsızdır ve stds sıfıra yakındır.

Yerel yürütücü seçimi soruya bağlıdır: “Bu ⟨O⟩ matematiksel olarak ne olmalı?” için statevector Estimator uygundur. “Bu ⟨O⟩ bu gürültü modeliyle ne dağılım gösterir?” sorusu farklı bir hat gerektirir. İkisini karıştırmamak, varyasyonel eğitim hatalarını azaltır.

Simülatör hattı

Gürültülü senaryolar gürültü simülasyonu ile modellenir; Estimator yalnızca tahmin arayüzüdür, kanal tanımı ayrı katmandadır.

Aer veya donanım yolunda aynı PUB listesi kullanılabilir; değişen, arkadaki yürütme motorunun ⟨O⟩ tahmininin belirsizliğidir. Önce referans ⟨O⟩, sonra gürültülü ⟨O⟩ ile kıyaslamak, regresyonları izlemeyi kolaylaştırır.

Performans

Gözlemlenebilir terim sayısı arttıkça tek çağrı maliyeti büyür; toplu PUB kullanımı ve toplu yürütüm stratejileri ölçek için devreye girer.

Pauli terimlerini gereksiz yere çoğaltmak yerine, cebirsel olarak birleştirilebilenleri birleştirmek hem klasik tarafı hem de kuantum çağrısını sadeleştirir. Bu cebir gözlemlenebilir değerlendirme konusunun parçasıdır.

IBM Qiskit Runtime üzerinde Estimator, oturum veya tek seferlik iş akışının parçası olarak sunulur; ağ gecikmesi ve kuyruk davranışı Runtime yürütme çerçevesinde düşünülür. Paket birleştirmeleri ve sürüm notları sık değiştiği için burada API imzası sabitlenmez.

Bulutta Estimator çağrısı ⟨O⟩ üreten ince bir fonksiyon gibi görünse de arka planda kimlik doğrulama, kuyruk, kaynak seçimi ve sonuç geri taşıma vardır. Oturum kullanımı ardışık enerji veya gradyan değerlendirmelerinde başlatma maliyetini azaltabilir; iş mantığı ise yine PUB listesi girer, beklenen değer vektörleri çıkar biçimindedir. Operasyonel ayrıntılar oturum ve Runtime işleri dosyalarında kalır.

Sürüm yüzeyi riski özellikle şu noktada büyür: dönüş alanlarının adları, hata sınıfları ve seçenek anahtarları evrilir. Üretimde kilitlenmiş bağımlılık aralığı ve sabit sürüm, beklenmedik kırılmaları azaltır. Kavramsal anlatım ise daha uzun ömürlüdür.

Mod ve seçenek uyumu

Hata azaltma, dinamik devre veya belirli transpilasyon seviyeleri ⟨O⟩ tahminini değiştirir; fakat çağrının “beklenen değer isteme” sözleşmesi değişmez. Seçenekleri tek tek açarak taban ⟨O⟩ çizgisi oluşturmak regresyonları izlemeyi kolaylaştırır.

Runtime seçenekleri donanım sürümüne bağlıdır; bu sayfa yalnızca uyumluluk riskini işaret eder. Ayrıntılı seçenek listesi IBM belgelerinde güncellenir.

Hibrit akışlar

Varyasyonel veya QML tarzı döngüler hibrit kuantum iş akışı başlığında kalır.

Estimator çıktısı klasik tarafa skaler vektör olarak döndüğünde bir sonraki adım genelde otomatik türev, ceza terimi veya doğrusal cebirsel çözümdür. Bu sayfa o klasik adımları vermez; yalnızca ilkelin ⟨O⟩ ürettiğini ve Sampler histogramının yerine geçmediğini hatırlatır.

Birinci kutu StatevectorEstimator ile Bell hazırlığında ZZ bekleneni; ikinci kutu parametre bağlama ve tek gözlemlenebilir; üçüncü kutu iki PUB ile aynı Z gözlemlenebilirinin farklı hazırlıklardaki ⟨Z⟩ değerleri.

Aşağıdaki kutular kısa tutulur; amaç run → result → data.evs / data.stds okumasını göstermektir. Ölçüm measure blokları bu yürütücüde zorunlu değildir; beklenen değer durum üzerinden hesaplanır. Ortam: Qiskit 2.x.

ZZ ve Bell hazırlığı

Beklenen ⟨ZZ⟩ idealde 1 civarındadır; stds statevector yolunda sıfıra yakın olmalıdır. Bu, devre ve gözlemlenebilir eşlemesinin doğru kurulduğuna dair hızlı bir kontrol sağlar.

from qiskit import QuantumCircuit
from qiskit.quantum_info import SparsePauliOp
from qiskit.primitives import StatevectorEstimator

qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)

obs = SparsePauliOp("ZZ")
result = StatevectorEstimator().run([(qc, [obs])]).result()
print(result[0].data.evs, result[0].data.stds)

Parametre atama ve ⟨Z⟩

assign_parameters ile bağlanmış devre üzerinde tek gözlemlenebilir; varyasyonel döngüde aynı desen farklı açılar için tekrarlanır.

from qiskit import QuantumCircuit
from qiskit.circuit import Parameter
from qiskit.quantum_info import SparsePauliOp
from qiskit.primitives import StatevectorEstimator

theta = Parameter("t")
qc = QuantumCircuit(1)
qc.ry(theta, 0)

obs = SparsePauliOp("Z")
assigned = qc.assign_parameters({theta: 0.3})
result = StatevectorEstimator().run([(assigned, [obs])]).result()
print(result[0].data.evs, result[0].data.stds)

İki PUB, aynı gözlemlenebilir

Aynı Z terimi farklı hazırlıklarda ⟨Z⟩ = 0 ve ⟨Z⟩ = −1 civarı verir; indeks sırası gönderilen PUB sırasına uymalıdır.

from qiskit import QuantumCircuit
from qiskit.quantum_info import SparsePauliOp
from qiskit.primitives import StatevectorEstimator

def plus_state():
    qc = QuantumCircuit(1)
    qc.h(0)
    return qc

def one_state():
    qc = QuantumCircuit(1)
    qc.x(0)
    return qc

obs = [SparsePauliOp("Z")]
result = StatevectorEstimator().run([(plus_state(), obs), (one_state(), obs)]).result()
for i, pub_result in enumerate(result):
    print(i, pub_result.data.evs, pub_result.data.stds)

Bu üçlü, yerelde doğrulanmış Estimator çağrısını Runtime’a taşırken de aynı kalır: PUB listesi ve evs indeksleme disiplini değişmez. Bulut örneği için oturum ve IBM Quantum belgelerindeki Estimator örnekleri doğal sonraki adımdır.

Estimator; gözlemlenebilir beklenen değere odaklanır, Sampler ise ölçüm dağılımına; ikisi Runtime iş akışlarının tamamlayıcı parçalarıdır.

Bu sayfada öğrenilen çerçeve, “⟨O⟩ isteme” kararını diğer başlıklardan ayırır: gözlemlenebilir cebiri gözlemlenebilir değerlendirme dosyasında; shot ve belirsizlik dili shot mantığı ile; iş kuyruğu ve oturum Runtime işleri ve oturum ile ilişkilidir. Çoğu kullanıcı için önce StatevectorEstimator referansı, sonra toplu PUB, en son bulut oturumu doğal bir yoldur.

Resmi IBM Quantum belgeleri güncel API yüzeyini taşır; Qubyt metinleri kavramları Türkçe ve sayfa zinciri içinde konumlandırır.

• Sampler ilkeli — ölçüm histogramı ve get_counts() yolu; Estimator ile karıştırılmaması gereken çıktı.
• Gözlemlenebilir değerlendirme — Pauli açılımı, ölçüm tabanı ve SparsePauliOp tasarımı.
• İlkel iş akışları — ardışık çağrı düzeni ve hibrit döngüde Estimator’un yeri.
• Toplu yürütüm — çoklu PUB ile ölçekleme.
• Shot mantığı — ⟨O⟩ belirsizliği ile örnekleme bütçesi ilişkisi.
• IBM Quantum: Primitives — güncel rehber ve örnekler.