Sampler ilkeli — Ölçümlü devrelerden bit dizisi dağılımı

Sampler ilkeli, ölçüm içeren kuantum devrelerini yürütüp bit dizisi istatistiklerini (sayım veya dağılım biçiminde) üretmek için tasarlanmış soyut bir arayüzdür. Bu sayfa çıktı şekli, yerel referans yürütücü ve Runtime bağlamını işler; gözlemlenebilir beklenen değerler Estimator ilkeli dosyasında kalır. Shot kavramının devre modeli tarafı shot mantığı sayfasında özetlenir.

Sampler düşüncesinin merkezinde ölçüm sonrası klasik sonuç uzayı vardır: hangi klasik kayıtların ne sıklıkla görüldüğü (veya beklenen dağılımla nasıl uyduğu) raporlanır. Bu, devrenin kuantum evrimi ile aynı şey değildir; transpilasyon, gürültü, kalibrasyon ve okuma hataları histogramı gerçek donanımda kaydırırken, ilkel arayüz yine de aynı soyut sözleşmeyi sunar: girdi olarak yürütülebilir bir ölçüm şeması, çıktı olarak ölçüme bağlı istatistik.

Sayfa sınırı bilinçli olarak çizilir: transpilasyon kuralları, donanım kısıtları veya belirli bir hizmetin REST uç noktası burada sabitlenmez; amaç, Sampler’ı diğer Runtime parçalarından ayırt etmek ve okuyucuyu doğru kaynaklara yönlendirmektir. Böylece metin, Estimator veya toplu yürütüm sayfalarıyla tekrar etmek yerine birbirini tamamlar.

İş 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.

Sampler tipik olarak “bir veya birkaç devreyi çalıştır, dağılımı getir” döngüsünün içindedir. Klasik optimizasyon veya veri işleme adımları bu ilkelin dışında kalır; ancak hibrit iş akışları içinde Sampler çıktısı bir sonraki klasik kararın girdisi olabilir (örneğin eşik altındaki bit kalıplarını süzme, istatistiksel test, görselleştirme). Bu sayfa o hibrit desenin tam kodunu vermez, yalnızca ilkelin sorumluluk alanını netleştirir.

Ne vaat edilmez

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

Sürüm notları ve paket adları (örneğin istemci kütüphaneleri) sık güncellenir; bu yüzden tek bir “doğru import satırı” kilidi yerine, kavramsal sözleşme anlatılır. Donanım özelinde hata azaltma veya dinamik devre seçenekleri hata azaltma ve Runtime rehberleriyle birlikte okunmalıdır; Sampler yalnızca dağılım üretiminin omurgasıdır.

Estimator, Pauli (veya daha genel gözlemlenebilir) beklenen değerlerini tahmin etmek içindir; Sampler ise ölçüm sonucu uzayında örnekleme dağılımı üretir. İkisi aynı devreyi paylaşsa bile raporlanan nesne türü farklıdır; varyasyonel maliyet fonksiyonlarında genellikle Estimator öne çıkar, doğruluk veya örnekleme histogramında Sampler.

Bu ayrım, “aynı yürütme”yi iki farklı bilimsel soruya cevap olarak okumaktır. Estimator sorusu: verilen gözlemlenebilir için beklenen değer nedir? Sampler sorusu: bu ölçüm düzenine göre klasik bit dizileri hangi sıklıklarla (veya hangi olasılık yasasıyla) görülür? İkinci sorunun cevabı, okuma ve örnekleme bütçesi olmadan tam anlamıyla “tek sayı”ya indirgenemez; bu yüzden Sampler çıktısı doğası gereği daha zengin bir nesnedir ve çoğu zaman sayım veya dağılım temelli analizlere girer.

Uygulama seçimi pratikte şöyle eğilir: gradyan tabanlı optimizasyon, enerji yüzeyi veya maliyetin Pauli açılımı üzerinden yazıldığı yerlerde Estimator doğrudan hedefe bağlanır. Tomografi benzeri kalibrasyon, okuma doğrulaması, rastgele ölçüm şemaları veya “hangi bit dizisi ne kadar sık” sorusu açıkça isteniyorsa Sampler daha doğal bir ilk seçimdir. Bazı iş akışlarında her iki ilkel de aynı pipeline içinde, farklı adımlarda bir arada kullanılır.

Gözlemlenebilir cebir

Pauli tabanı sezgisi Pauli sayfasında; Estimator tarafındaki ayrıntılar gözlemlenebilir değerlendirme ile sınırlandırılır.

Sampler tarafında gözlemlenebilir “liste olarak” verilmez; dağılım, devre içinde tanımlı ölçümlerin ürettiği klasik register’lar üzerinden okunur. Dolayısıyla Pauli ağırlıkları dolaylı olarak devreye girebilir (örneğü ölçüm tabanı dönüşümü veya ek yardımcı kübitler ile), fakat Sampler’ın birinci sınıf girdisi ölçüm şemasıdır. Bu ayrım, Estimator ile karşılaştırıldığında kafa karışıklığını azaltır.

Ölçüm yerleşimi

Ölçüm bloklarının devrede nereye konduğu çıktı uzayını belirler; ölçüm mantığı ile uyumlu düşünülmelidir.

Ortak ölçüm, ara ölçüm veya çoklu klasik register kullanımı, sonuç nesnesinde hangi alanın hangi bit dizilerine karşılık geldiğini belirler. Sampler ile çalışırken “hangi measure bloğunun hangi isimle raporlandığı”nı erken netleştirmek, sonradan veri çerçevesi birleştirmesini kolaylaştırır. Bu sayfa belirli bir ölçüm desenini dayatmaz; yalnızca çıktının ölçüm topolojisine bağlı olduğunu vurgular.

Çağrı tarafında yaygın desen, her bir yürütme birimi için devre + (isteğe bağlı) klasik bağlayıcılar ve shot sayısı gibi seçenekleri içeren bir PUB (Primitive Unified Buffer düşüncesi) vermektir. Parametreli devrelerde önce assign_parameters ile somut açı değerleri üretilir, sonra ilkel çalıştırılır.

PUB soyutlaması, “tek devre–tek iş” yerine yayımlanabilir birim düşüncesini getirir: aynı çağrı içinde birden çok bağımsız veya parametrelenmiş yürütme paketlenebilir. Yerel örneklerde bu genellikle bir demet listesi olarak görülür; Runtime tarafında ise ağ taşıması, serileştirme ve sunucu tarafı doğrulama ile birleşir. Önemli olan, çağrı sınırında her birimin hangi devre örneğine karşılık geldiğinin izlenebilir olmasıdır.

Parametre yönetimi iki yaygın yoldan birine gider: ya devre üzerinde assign_parameters ile tamamen bağlanmış bir kopya üretilir, ya da ilkelin desteklediği biçimde parametre değerleri ayrı taşınır. Bu sayfadaki laboratuvar ilki seçer; okuyucu kendi sürümünde ikinci yolu kullanıyorsa, sonuç indeksleme ve şekil aynı sezgisel çerçevede kalmalıdır.

Çoklu PUB

Tek bir run çağrısına birden çok PUB vermek, toplu iş yürütümü ile ölçeklenir; ayrıntılar toplu yürütüm sayfasında derinleşir.

Çoklu PUB, aynı deneyi tekrarlamak yerine koşullu veya karşılaştırmalı deneyleri tek seferde gruplamak için kullanışlıdır: farklı hazırlıklar, farklı açı parametreleri veya farklı okuma derinlikleri. Dönüşte her PUB için ayrı bir sonuç yuvası beklenir; indeks ile eşleme, klasik veri işlem kodunda hata yapılmasını engeller.

Seçenekler

Shot sayısı ve rastgele tohum gibi seçenekler yürütücüye göre değişir; burada yalnızca bütçe ve tekrarlanabilirlik sezgisi sabittir.

Shot arttıkça histogramın varyansı azalır; fakat maliyet ve süre genelde doğrusal ölçekte büyür. Tohum sabitleme, aynı devre ve seçeneklerle tekrarlanabilir sayımlar üretmek için kullanılır; ideal StatevectorSampler yolunda dağılım beklenen olasılıklara oturduğundan fark küçük görülebilir, fakat sayım nesnesinin biçimi yine de shot ile tutarlıdır. Donanımda ise tohum ve kalibrasyon birlikte “tekrarlanabilirlik”i tanımlar.

Qiskit 2.x çizgisinde sonuç genellikle PrimitiveResult kapsayıcısıdır; her yayından (pub sonucu) ölçüm verisi bir DataBin içinde taşınır. Klasik sayımlar BitArray üzerinden get_counts() ile okunabilir; ideal yürütücülerde bu dağılım deterministik beklenenle örtüşür.

PrimitiveResult koleksiyon gibi düşünülebilir: her öğe, sırayla gönderilen bir PUB’a karşılık gelir. İçerideki data alanı, ölçüm register adlarına göre ayrışır; çoklu ölçüm kullanıldığında hangi alanın hangi klasik bitlere denk geldiğini isimden takip etmek gerekir. get_counts() çağrısı, ham bit dizilerini sözlük biçiminde özetler ve çoğu analiz için yeterli bir ilk duraktır.

Sonuç nesnesini okurken iki yaygın tuzak vardır: birincisi, PUB sırası ile sonuç sırasının karıştırılması; ikincisi, ölçüm adının varsayılan meas gibi bir etiketle geldiğinin unutulması. Laboratuvar kodları bilinçli olarak aynı deseni izler; kendi devrelerinizde measure_all yerine özel klasik register kullanıyorsanız, veri alan adlarını çıktıda doğrulamak gerekir.

Kuasi dağılım perspektifi

Bazı yollar kuasi-olasılık vektörü sunar; bu sayfa yürütücüye göre değişen yüzeyi sabitlemez, yalnızca Sampler çıktısının ölçüm tabanlı doğasını vurgular.

Donanım veya belirli emülasyon yollarında, raporlanan dağılım ham Born olasılıklarından sistematik olarak sapabilir; okuma hatası ve geç kapı hataları histogramı genişletir veya asimetrik kılar. Bu durumda Sampler çıktısı “kuantum durumunun tam özeti” değil, o yürütme yolunun ürettiği ölçüm istatistiğidir. Ayrımı korumak, sonuçları yanlış yorumlamayı önler.

Doğrulama

Küçük devrelerde el ile hesaplanan olasılıklarla kıyaslama, entegrasyon hatasını erken yakalar; sadakat ölçütleri yardımcı olabilir.

İdeal yürütücü ile başlayıp sonra gürültü modeline geçmek, hata ayıklamayı katmanlı yapar: önce devre ve ölçüm şeması doğrulanır, ardından kanal parametreleri titretilir. Sampler bu süreçte “beklenen dağılımı üret” işini üstlenir; kanal tanımı ve hata azaltma seçenekleri başka katmanlarda kalır.

Öğretim ve test için StatevectorSampler gürültüsüz ideal yürütmeden örnek üretir; üretim öncesi donanım emülasyonu için Aer tabanlı yürütücüler düşünülür. Bu sayfa belirli bir Aer sınıfının adını sabitlemez — kurulumunuza göre değişir.

StatevectorSampler, durum vektörü üzerinden ölçüm dağılımını türetir; yani önce kuantum durumu hesaplanır, ardından ölçüm projeksiyonu ile klasik sonuçların olasılığı çıkarılır. Bu, donanımın “shot atıp frekans toplama” gerçeğinin yerine geçen matematiksel referans yoludur: hızlı iterasyon, birim test ve ders notları için uygundur. Donanım davranışını taklit etmek farklı bir hedeftir ve genelde gürültü modeli içeren bir simülatör hattı gerektirir.

Yerel referans yürütücü seçimi, soruya bağlıdır: “Bu devrenin ölçüm dağılımı idealde ne olmalı?” sorusuna cevap arıyorsanız statevector tabanlı Sampler uygun olur. “Bu devre, verilen gürültü ve okuma modeliyle hangi histogramı üretir?” sorusu Aer veya donanım örneklemi ister. İkisini karıştırmamak, özellikle hata azaltma veya kalibrasyon tartışmalarında kritiktir.

Simülatör hattı

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

Aer veya benzeri motorlarda, Sampler çağrısı altında yürütülen devre aynı kalır; değişen, arkadaki yürütme motorunun ürettiği örnek mekanizmasıdır. Bu modülerlik, aynı üst seviye kodun önce ideal referansla, sonra gürültülü emülasyonla doğrulanmasına izin verir.

Performans

Küçük devrelerde yerel sampler hızlıdır; büyük shot veya derin devrelerde bellek ve süre sınırları devreye girer.

Statevector yöntemi bellek kullanımını üstel ölçekte büyütebilir; kübit sayısı arttıkça alternatif örnekleme yolları cazip hale gelir. Shot sayısı arttıkça ise histogram toplama maliyeti büyür. Bu yüzden prototipte küçük devre ve makul shot ile başlamak, sonra toplu yürütüm veya Runtime ile ölçeklemek tipik bir eğridir.

IBM Qiskit Runtime üzerinde Sampler, 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 (qiskit-ibm-runtime vb.) ve sürüm notları sık değiştiği için burada API imzası sabitlenmez.

Bulutta Sampler çağrısı yalnızca “hesap makinesi gibi” bir fonksiyon değildir; kimlik doğrulama, kuyruk, kaynak seçimi ve sonuç geri taşıma gibi operasyonel katmanlar vardır. Oturum kullanımı, ardışık çağrılarda başlatma maliyetini azaltmayı hedefleyebilir; fakat iş mantığı açısından hâlâ aynı soyut sözleşme geçerlidir: PUB listesi girer, toplu sonuç çıkar. Bu sayfa operasyonel ayrıntıları oturum ve Runtime işleri dosyalarına bırakır.

Sürüm yüzeyi uyarısı özellikle şu noktada önemlidir: ilkel nesnelerinin yapılandırma anahtarları, hata sınıfları ve dönüş tipleri zaman içinde evrilir. Üretim kodunda sabitlenmiş sürüm ve kilitlenmiş bağımlılık aralığı kullanmak, beklenmedik kırılmaları azaltır. Kavramsal anlatım ise daha uzun ömürlüdür; bu yüzden burada “ne sabitlenir / ne sabitlenmez” açıkça yazılmıştır.

Mod ve seçenek uyumu

Hata azaltma veya dinamik devre seçenekleri donanım ve sürüme bağlıdır; bu sayfa yalnızca uyumluluk riskini işaret eder.

Örneğin okuma hatası azaltımı veya belirli bir transpilasyon seviyesi, Sampler’ın döndürdüğü ham sayımları değiştirir; fakat çağrının “dağılım isteme” sözleşmesi değişmez. Seçenekleri açarken, önce seçeneksiz bir taban çizgisi üretip sonra iyileştirmeleri tek tek eklemek, regresyonları izlemeyi kolaylaştırır.

Hibrit akışlar

Klasik–kuantum birleşik desenler hibrit kuantum iş akışı başlığında kalır.

Sampler çıktısı klasik tarafa “ham veri” olarak döndüğünde, bir sonraki adım sıkça istatistiksel bir işlemdir: güven aralığı, eşik testi veya veri çerçevesi birleştirme. Bu sayfa o istatistiksel işlemleri vermez; yalnızca ilkelin ürettiği nesnenin histogram okumasına uygun olduğunu ve Estimator’ın skaler çıktısının yerine geçmediğini hatırlatır.

Birinci kutu Bell benzeri devrede StatevectorSampler; ikinci kutu parametre bağlama; üçüncü kutu iki PUB ile toplu çağrı iskeleti.

Aşağıdaki kutular bilinçli olarak kısa tutulur; amaç, bu sayfanın metin bölümlerinde anlatılan soyut sözleşmeyi çalışır halde göstermektir. Çalıştırmadan önce ortamınızda Qiskit 2.x çizgisinin kurulu olduğundan emin olun; sürüm farkında data alanı adları veya yardımcı metot isimleri değişebilir, fakat run → result → get_counts() akışı aynı kalır.

Bell ve ideal dağılım

İlk örnek, iki kübitlik bir hazırlık ve tam ölçüm ile yaklaşık eşit 00 ve 11 sayımları üretmelidir; küçük sapmalar yalnızca örnekleme istatistiğinden kaynaklanır. Bu, devrenin doğru bağlandığını ve sonuç nesnesinin beklenen yoldan okunduğunu doğrular.

from qiskit import QuantumCircuit
from qiskit.primitives import StatevectorSampler

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

result = StatevectorSampler().run([(qc,)]).result()
counts = result[0].data.meas.get_counts()
print(counts)

Parametre atama ve tek PUB

İkinci kutu, dönüşümlü parametreli bir kapı ile tek kübit ölçümünü gösterir. assign_parameters çağrısı, sembolik devreyi somut bir açıyla “donmuş” bir kopyaya çevirir; böylece Sampler tarafı tamamen bağlanmış bir devre görür. Bu desen, optimizasyon döngüsünde farklı açıları denemek için de aynı şekilde genelleştirilebilir.

from qiskit import QuantumCircuit
from qiskit.circuit import Parameter
from qiskit.primitives import StatevectorSampler

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

assigned = qc.assign_parameters({theta: 0.4})
result = StatevectorSampler().run([(assigned,)]).result()
print(result[0].data.meas.get_counts())

İki PUB ve sonuç indeksi

Üçüncü kutu, tek run içinde iki farklı hazırlığı yan yana çalıştırır. Döngüdeki i değeri, gönderilen PUB sırasıyla aynı kalmalıdır; aksi halde yanlış devreye ait histogram birleştirilebilir. Bell ve ayrıştırılabilir hazırlığın sayımları birbirinden belirgin olmalıdır; bu fark, çoklu PUB mantığının doğru kurulduğuna dair hızlı bir görsel kontrol sağlar.

from qiskit import QuantumCircuit
from qiskit.primitives import StatevectorSampler

def bell():
    qc = QuantumCircuit(2)
    qc.h(0)
    qc.cx(0, 1)
    qc.measure_all()
    return qc

def separable():
    qc = QuantumCircuit(2)
    qc.h(0)
    qc.h(1)
    qc.measure_all()
    return qc

result = StatevectorSampler().run([(bell(),), (separable(),)]).result()
for i, pub_result in enumerate(result):
    print(i, pub_result.data.meas.get_counts())

Bu üçlü, yerelde doğrulanmış bir Sampler çağrısını Runtime’a taşırken de aynı kalır: PUB listesi ve sonuç indeksleme disiplini değişmez; değişen yalnızca yürütmenin arkasındaki motor ve ağ sarmalayıcıdır. Bulut örneği eklemek için oturum ve IBM Quantum belgelerindeki Sampler örneklerine geçmek doğal sonraki adımdır.

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

Bu sayfada öğrenilen çerçeve, “dağılım isteme” kararını diğer tüm Runtime başlıklarından ayırır: iş kuyruğu ve oturum yönetimi ayrı, örnekleme bütçesi ve shot dili ayrı, sonuç nesnesinin okunması ayrı bir beceridir. Aşağıdaki bağlantılar bu parçaları derinleştirir; okuma sırası serbest olsa da, çoğu kullanıcı için önce yerel referans, sonra toplu çağrı, en son bulut oturumu doğal bir yoldur.

Resmi IBM Quantum belgeleri, ilkel API yüzeyinin güncel halini taşır; Qubyt metinleri ise kavramları Türkçe ve sayfa zinciri içinde konumlandırır. İkisi birlikte kullanıldığında, hem “neden böyle” sezgisi hem de “şu an hangi imza” pratiği dengelenir.

• Estimator ilkeli — Pauli veya daha genel gözlemlenebilirler için beklenen değer; maliyet fonksiyonu ve gradyan yolları.
• İlkel iş akışları — ardışık çağrı düzeni, veri akışı ve Sampler–Estimator birlikte düşünüldüğünde ortaya çıkan desenler.
• Shot mantığı — örnekleme bütçesi, varyans ve tekrarlanabilirlik; Sampler çıktısının istatistiksel yorumu.
• Gözlemlenebilir değerlendirme — Estimator tarafındaki cebir ve ölçüm tasarımı; Sampler ile karıştırılmaması gereken kavramlar.
• IBM Quantum: Primitives — güncel Runtime ilkel rehberi ve örnekler.