💻 computer science

Auditing Empirical Comparisons in Quantum Software

यह शोध पत्र CLAIMSTAB-QC को प्रस्तुत करता है, जो परिणाम गणना से पहले अध्ययन डिजाइनों को लॉक करके क्वांटम सॉफ्टवेयर में अनुभवजन्य तुलनाओं के ऑडिटिंग के लिए एक ढांचा है, जो एक महत्वपूर्ण भौतिकीकरण अंतराल (materialization gap) को प्रकट करता है जहाँ अधिकांश रिपोर्ट किए गए दावे प्रत्यक्ष सत्यापन के लिए पर्याप्त साक्ष्य की कमी रखते हैं और सख्त जांच के तहत अक्सर अनसुलझे या उलटे परिणाम देते हैं।

मूल लेखक: Boshuai Ye, Peng Liang, Maryam Tavassoli Sabzevari, Arif Ali Khan

प्रकाशित 2026-07-02

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Boshuai Ye, Peng Liang, Maryam Tavassoli Sabzevari, Arif Ali Khan

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आप एक फूड रिव्यू पढ़ रहे हैं जिसमें लिखा है, "शेफ A का बर्गर शेफ B के बर्गर से अधिक स्वादिष्ट है।" आमतौर पर, हम इसे बर्गर के बारे में एक सार्वभौमिक सत्य मान लेते हैं। लेकिन क्या होगा यदि शेफ A ने एक गुप्त मसाला मिश्रण, एक विशिष्ट प्रकार के बन (bun) और एक सटीक तापमान पर सेट किए गए ग्रिल का उपयोग किया हो, जबकि शेफ B ने एक अलग बन और चारकोल ग्रिल का उपयोग किया हो? यदि आप अपने स्वयं के किचन टूल्स का उपयोग करके खुद उन्हें टेस्ट करने की कोशिश करते हैं, तो आपको लग सकता है कि शेफ B का बर्गर वास्तव में जीत गया।

यह वही समस्या है जिसे शोध पत्र "Auditing Empirical Comparisons in Quantum Software" हल करता है, लेकिन यहाँ बर्गर के बजाय, यह क्वांटम कंप्यूटरों और उन्हें चलाने वाले सॉफ्टवेयर के बारे में है।

यहाँ लेखकों द्वारा किए गए कार्यों का रोजमर्रा के उदाहरणों का उपयोग करके एक सरल विवरण दिया गया है।

1. समस्या: "सेब बनाम संतरे" वाला जाल (Apples vs. Oranges Trap)

क्वांटम सॉफ्टवेयर की दुनिया में, शोधकर्ता अक्सर शोध पत्र प्रकाशित करते हैं जिनमें दावा किया जाता है, "हमारा टूल (टूल A) उस टूल (टूल B) से तेज़/बेहतर है।"

हालाँकि, क्वांटम सॉफ्टवेयर एक विशाल, बहु-स्तरीय सैंडविच की तरह है। सैंडविच बनाने के लिए, आपको ब्रेड, फिलिंग, सॉस और उसे काटने के एक विशिष्ट तरीके की आवश्यकता होती है। क्वांटम सॉफ्टवेयर में, ये परतें हैं:

कोड (ब्रेड)।
कंपाइलर (स्लाइसर/काटने वाला)।
सिम्युलेटर या हार्डवेयर (प्लेट)।
शोर और त्रुटियाँ (ब्रेड के टुकड़े/crumbs)।

लेखक तर्क देते हैं कि यह कहना कि "टूल A बेहतर है" अक्सर भ्रामक होता है क्योंकि परिणाम पूरी तरह से इस बात पर निर्भर करता है कि सैंडविच कैसे बनाया गया था। यदि आप ब्रेड (सर्किट) या स्लाइसर (कंपाइलर सेटिंग्स) को बदलते हैं, तो टूल A अचानक टूल B से बदतर दिख सकता है।

2. समाधान: "कठोर निरीक्षक" (The Strict Inspector - CLAIMSTAB-QC)

लेखकों ने CLAIMSTAB-QC नामक एक नया फ्रेमवर्क बनाया है। इसे एक कठोर खाद्य निरीक्षक (food inspector) के रूप में सोचें जो केवल भोजन का स्वाद ही नहीं चखता; बल्कि वह पहले रेसिपी कार्ड की भी जाँच करता है।

यहाँ उनकी "निरीक्षण" प्रक्रिया कैसे काम करती है:

क्लेम कार्ड (Claim Card): जब कोई पेपर कहता है "A, B को हरा देता है," तो निरीक्षक ठीक से लिख लेता है कि क्या दावा किया गया था: विशिष्ट सामग्री, विशिष्ट उपकरण और उपयोग किए गए विशिष्ट नियम।
लॉक (The Lock): निरीक्षक द्वारा कुछ भी चखने से पहले, वे रेसिपी को लॉक कर देते हैं। उन्हें सामग्री या उपकरणों को बदलने की अनुमति नहीं है। उन्हें बिल्ly वही उपयोग करना होगा जैसा मूल पेपर में बताया गया है।
साक्ष्य की जाँच (The Evidence Check): निरीक्षक पेपर की "रसीद" (डेटा और कोड) को देखता है।
- परिदृश्य A: यदि पेपर ने सटीक रसीद प्रदान की है। निरीक्षक बर्गर का स्वाद ठीक उसी तरह ले सकता है जैसा वर्णित है।
- परिदृश्य B: यदि पेपर ने कहा "A बेहतर है" लेकिन उसने सामग्री या तापमान की सूची नहीं दी। निरीक्षक इसे चख नहीं सकता। उसे रुकना होगा और कहना होगा, "हम इस दावे को सत्यापित नहीं कर सकते क्योंकि साक्ष्य गायब हैं।"

3. बड़ी खोज: "गायब रसीद" का अंतर (The Missing Receipt Gap)

लेखकों ने इस फ्रेमवर्क का परीक्षण 119 विभिन्न शोध पत्रों से 455 दावों पर किया। परिणाम आश्चर्यजनक थे:

175 दावे एक स्पष्ट रेसिपी के रूप में लिखे जा सकते थे (Claim Cards)।
79 दावे ऐसे थे जो टेस्ट किए जाने योग्य लग रहे थे।
53 दावों में टेस्ट सेटअप करने के लिए पर्याप्त डेटा था।
लेकिन... केवल 8 दावों के पास वह पूर्ण "रसीद" थी जिसकी आवश्यकता बिना किसी अनुमान या गायब डेटा को बनाए बिना दावे का परीक्षण करने के लिए थी।

उपमा (Analogy): कल्पना कीजिए कि एक रेस्टोरेंट चेन दावा करती है कि उनके बर्गर शहर में सबसे अच्छे हैं। वे आपको 100 स्थानों की सूची देते हैं। आप जाँच करने के लिए उनमें से 53 स्थानों पर जाते हैं। लेकिन जब आप बर्गर चखने की कोशिश करते हैं, तो आपको एहसास होता है कि 45 स्थानों ने आपको यह नहीं बताया कि उन्होंने किन सामग्रियों का उपयोग किया था। आप वास्तव में केवल 8 स्थानों पर बर्गर को चख और सत्यापित कर सकते हैं।

इसे "मटेरियलाइजेशन गैप" (Materialization Gap) कहा जाता है। शोधकर्ता अक्सर परिणाम (विजेता) तो बताते हैं, लेकिन उस प्रमाण (सटीक सेटिंग्स) को नहीं देते जिसकी आवश्यकता दावे को सिद्ध करने के लिए होती है।

4. परिणाम: वास्तव में कौन जीता?

उन 8 दावों के लिए जिनके पास पूर्ण साक्ष्य थे, लेखकों ने "कठोर ऑडिट" चलाया:

2 दावे: मूल विजेता की पुष्टि हुई (Sustained verdict)।
4 दावे: यह बताना असंभव था कि कौन जीता क्योंकि डेटा बहुत मिश्रित था या परिणाम बहुत करीब थे (Unresolved verdict)।
2 दावे: सख्त परीक्षण के दौरान मूल विजेता वास्तव में हार गया (Reversed verdict)।

"रिवर्स" (Reversed) का उदाहरण: एक पेपर ने दावा किया कि टूल A ने टूल B की तुलना में कम त्रुटियाँ उत्पन्न कीं। जब लेखकों ने सेटिंग्स को लॉक किया और वर्णित तरीके से बिल्कुल फिर से टेस्ट चलाया, तो उन्होंने पाया कि टूल A ने वास्तव में अधिक त्रुटियाँ उत्पन्न कीं। मूल दावा केवल एक विशिष्ट, अनरिपोर्टेड सेटिंग के कारण सही था जिसे लेखकों ने लॉक नहीं किया था।

5. सबक: "अपना काम दिखाएँ" (Show Your Work)

पेपर निष्कर्ष निकालता है कि क्वांटम सॉफ्टवेयर की तुलना करने का वर्तमान तरीका टूटा हुआ है। यह एक गणित शिक्षक की तरह है जो कहता है, "उत्तर 5 है," लेकिन चरण (steps) नहीं दिखाता।

लेखक सुझाव देते हैं कि भविष्य के शोध पत्रों को:

तुलना को स्पष्ट रूप से बताना चाहिए।
सटीक "रसीद" (विशिष्ट सेटिंग्स, सीड्स और डेटा) प्रदान करनी चाहिए जिससे टेस्ट को लॉक किया जा सके।
स्पष्ट रूप से स्वीकार करना चाहिए कि साक्ष्य कहाँ समाप्त होते हैं (जैसे, "हमने केवल छोटे सर्किट पर परीक्षण किया; हमें नहीं पता कि यह बड़े सर्किट पर काम करेगा या नहीं")।

सारांश

यह पेपर यह नहीं कह रहा है कि क्वांटम सॉफ्टवेयर बुरा है। यह कह रहा है कि किस सॉफ्टवेयर के "बेहतर" होने के दावे अक्सर अप्रमाणित होते हैं क्योंकि शोधकर्ता यह विवरण साझा नहीं करते कि उन्होंने परीक्षण कैसे चलाया।

उन्होंने एक टूल (CLAIMSTAB-QC) बनाया जो एक सख्त ऑडिटर के रूप में कार्य करता है। जब उन्होंने इसका उपयोग किया, तो उन्होंने पाया कि अधिकांश दावों का ऑडिट नहीं किया जा सका क्योंकि "रसीदें" गायब थीं। जिन दावों का ऑडिट किया जा सकता था, उनके परिणाम मिले-जुले थे: कभी-कभी मूल दावा कायम रहा, कभी-कभी नहीं, और अक्सर, यह बताना असंभव था।

मुख्य बात: यदि आप जानना चाहते हैं कि टूल A वास्तव में टूल B से बेहतर है या नहीं, तो आपको केवल अंतिम स्वाद नहीं, बल्कि पूरी रेसिपी देखने की आवश्यकता है।

तकनीकी सारांश: क्वांटम सॉफ्टवेयर में अनुभवजन्य तुलनाओं का ऑडिटिंग

समस्या विवरण
क्वांटम सॉफ्टवेयर इंजीनियरिंग (QSE) में अनुभवजन्य (empirical) शोध पत्र अक्सर तुलनात्मक दावे रिपोर्ट करते हैं (जैसे, "कंपाइलर A, कंपाइलर B की तुलना में छोटे सर्किट बनाता है")। हालाँकि, ये "A, B को हराता है" वाले निष्कर्ष केवल उपकरणों के अंतर्निहित गुण नहीं हैं; बल्कि ये सर्किट निर्माण, संकलन विकल्पों (compilation choices), सैंपलिंग रणनीतियों, बैकएंड शोर धारणाओं (noise assumptions), ऑप्टिमाइज़र स्टोकेस्टिसिटी (stochasticity), और संसाधन बजटों के एक जटिल स्टैक के परिणाम हैं। जबकि मौजूदा विधियाँ पुनरुत्पादकता (reproducibility - प्रयोगों को फिर से चलाना) और टूल टेस्टिंग को संबोधित करती हैं, वे सीधे तौर पर इस बात का ऑडिट नहीं करती हैं कि क्या रिपोर्ट किया गया तुलनात्मक संबंध स्रोत पेपर और आर्टिफैक्ट में प्रदर्शित विशिष्ट साक्ष्य द्वारा समर्थित है। फलस्वरूप, कई रिपोर्ट की गई तुलनाएँ उपलब्ध निष्पादन योग्य (executable) आर्टिफैक्ट के बावजूद ऑडिट करने योग्य नहीं रह जाती हैं।

मुख्य चुनौती सामग्री अंतराल (materialization gap) है: एक पेपर एक स्पष्ट क्रम रिपोर्ट कर सकता है, लेकिन स्रोत में अक्सर वह मेल खाने वाला साक्ष्य (paired baselines, समान सेटिंग्स, और लॉक किए गए परिणाम नियम) नहीं होता है जो प्रॉक्सी पुनर्निर्माण (proxy reconstruction) या असमर्थ धारणाओं को पेश किए बिना उस विशिष्ट संबंध का ऑडिट करने के लिए आवश्यक है। परिणामस्वरूप, कई रिपोर्ट की गई तुलनाएँ ऑडिट करने योग्य नहीं रहती हैं, भले ही उनके पास निष्पादन योग्य आर्टिफैक्ट उपलब्ध हों।

कार्यप्रणाली: CLAIMSTAB-QC फ्रेमवर्क
लेखक CLAIMSTAB-QC प्रस्तुत करते हैं, जो एक सोर्स-बाउंडेड फ्रेमवर्क है जिसे अनुभवजन्य तुलनाओं का ऑडिट करने के लिए डिज़ाइन किया गया है, जहाँ रिपोर्ट किए गए संबंध को ही ऑडिट यूनिट माना जाता है। यह फ्रेमवर्क निम्नलिखित चरणों के माध्यम से कार्य करता है:

क्लेम कार्ड प्रतिनिधित्व (Claim Card Representation): एक रिपोर्ट की गई तुलना को क्लेम कार्ड $C = \langle P, BA, BB, M, R \rangle$ के रूप में औपचारिक रूप दिया जाता है, जहाँ $P$ समस्या का संदर्भ है, $BA/BB $बेसलाइन हैं,$ M $मीट्रिक है, और$ R$ रिपोर्ट किया गया संबंध है। यह किसी भी परिणाम की गणना करने से पहले दायरे को निर्धारित करता है।
सामग्रीकरण और लॉकिंग (Materialization and Locking): फ्रेमवर्क स्रोत-समर्थित साक्ष्य की पहचान करके क्लेम को "मटेरियलाइज" करने का प्रयास करता है। यह एक ऑडिट स्पेस ( $S_{audit} = S_{scope} \times E_{env}$ $S_{a u d i t} = S_{sco p e} \times E_{e n v}$ ) को छह अक्ष समूहों (axis groups) के साथ परिभाषित करता है: स्कोप (समस्या का आकार, इंस्टेंस), L1 (निर्माण/संकलन), L2 (सैंपलिंग/अनुमान), L3 (बैकएंड/शोर), ALGO (ऑप्टिमाइज़र स्टोकेस्टिसिटी), और बजट (संसाधन सीमाएँ)।
- एक ड्राय-रन-फर्स्ट (Dry-Run-First) प्रक्रिया इन अक्षों का निरीक्षण करती है। केवल वे ही विविधताएँ सक्रिय की जाती हैं जो स्रोत-समर्थित, मीट्रिक-प्रभावित और संबंध-संरक्षण करने वाली हैं।
- डिज़ाइन परिणामों की गणना करने से पहले लॉक (locked) किया जाता है। यदि स्रोत में आवश्यक युग्मित डेटा (जैसे, समान सीड्स के तहत मेल खाते सर्किट) की कमी है, तो ऑडिट एक एविडेंस बाउंड्री (Evidence Boundary) पर रुक जाता है।
परिणाम गणना (Outcome Computation):
- स्केलर-डायरेक्शनल (Scalar-Directional) रिकॉर्ड्स (सख्त "बेहतर/बदतर" दावों) के लिए, फ्रेमवर्क प्रत्येक मेल खाने वाले सेल के लिए एक साइन्ड मार्जिन (signed margin) की गणना करता है।
- यह संबंध को Sustained (निचली सीमा $\ge \tau$ ), Reversed (ऊपरी सीमा $\le 1-\tau$ ), या Unresolved के रूप में वर्गीकृत करने के लिए विल्सन निर्णय नियम (Wilson decision rule) लागू करता है। सख्त दावों के लिए $\tau$ का मान 0.95 रखा गया है।
- गैर-स्केलर रिकॉर्ड (एग्रीगेट, क्रॉसओवर) उपयोग किए गए नियमों का उपयोग करते हैं यदि वे लॉक करने योग्य हैं; अन्यथा, उन्हें सीमाओं (boundaries) के रूप में चिह्नित किया जाता है।
रिपोर्टिंग: आउटपुट में स्कोप्ड वर्डिक्ट (S/U/R) या एक स्पष्ट एविडेंस बाउंड्री शामिल होती है जो यह बताती है कि तुलना को ऑडिट क्यों नहीं किया जा सका (जैसे, लापता टाइमिंग प्रोटोकॉल, अनमैच्ड सीड्स)।

प्रमुख योगदान

फ्रेमवर्क: एक नवीन QSE फ्रेमवर्क जो ऑडिट फोकस को "क्या हम परिणाम को पुनरुत्पादित कर सकते हैं?" से बदलकर "क्या स्रोत साक्ष्य रिपोर्ट किए गए संबंध का समर्थन करता है?" पर ले जाता है, जो सोर्स-बाउंडेड रिकॉर्ड और लॉक किए गए डिज़ाइनों का उपयोग करता है।
अनुभवजन्य अध्ययन: 119 क्वांटम-सॉफ्टवेयर पेपर्स (2020–2024) से 455 तुलनात्मक दावों पर इस फ्रेमवर्क का अनुप्रयोग।
पुन: प्रयोज्य आर्टिफैक्ट (Reusable Artifact): एक रिलीज़ किया गया पैकेज जिसमें क्लेम रिप्रजेंटेशन, ऑडिट रिकॉर्ड, लॉक किए गए ट्रेसेस और मिसिंग-एविडेंस एनोटेशन शामिल हैं ताकि अनुभवजन्य QSE तुलनाओं के निरीक्षण को सुगम बनाया जा सके।

परिणाम
अध्ययन एक महत्वपूर्ण मटेरियलाइजेशन फनल (materialization funnel) और अंतराल को प्रकट करता है:

प्रतिनिधित्व (Representation): 455 स्वीकृत दावों में से, 175 को क्लेम कार्ड के रूप में दर्शाया जा सकता था।
योजना (Planning): 79 को स्केलर-डायरेक्शनल प्लानिंग रिकॉर्ड के रूप में पहचाना गया।
लॉक करने की क्षमता (Lockability): 53 ने लॉक करने योग्य ऑडिट या डायग्नोस्टिक डिज़ाइन दिए।
प्रॉक्सी-मुक्त ऑडिटिंग (Proxy-Free Auditing): केवल 8 रिकॉर्ड्स ने मूल तुलना को ऑडिट करने के लिए पर्याप्त मेल खाने वाला साक्ष्य प्रदर्शित किया (Tier-1)।
- इन 8 में से, 2 Sustained थे, 4 Unresolved थे, और 2 Reversed थे।
- विशेष रूप से, दो "Reversed" मामलों (EX-C7 और EX-C8) ने दिखाया कि रिपोर्ट किया गया दिशा-निर्देश क्रमशः 0/80 और 0/80 लॉक किए गए सेल्स में विरोधाभासी था, जो कि केवल बराबरी के बजाय सख्त विरोधाभासों से प्रेरित था।
नियंत्रित डायग्नोस्टिक्स (Controlled Diagnostics): 24 बेंचमार्क-प्रासंगिक तुलनाओं पर प्रयोगों ने दिखाया कि सरल ऑडिट प्रोटोकॉल (एकल कॉन्फ़िगरेशन या एकल-अक्ष) अक्सर उन दिशाओं को बनाए रखते हैं जो पूर्ण लॉक किए गए अक्षों (L1–L3, ALGO, BUDGET) के निरीक्षण के दौरान कमजोर हो जाती हैं या Unresolved हो जाती हैं।
मजबूती (Robustness): जब साक्ष्य पर्याप्त था, तो वर्डिक्ट सांख्यिकीय विकल्पों (थ्रेशोल्ड, ग्रुपिंग) के प्रति मजबूत पाए गए, लेकिन टाई-हैंडलिंग और थ्रेशोल्ड के प्रति संवेदनशीलता को स्पष्ट रूप से एक बाउंड्री कंडीशन के रूप में रिपोर्ट किया गया था।

महत्व और दावे
पेपर तर्क देता है कि अनुभवजन्य QSE तुलनाएँ अक्सर उन आवश्यक साक्ष्यों के बिना रिपोर्ट की जाती हैं जो स्वयं तुलना का ऑडिट करने के लिए आवश्यक हैं। इस कार्य का प्राथमिक महत्व यह प्रदर्शन है कि प्रदर्शन क्रम (performance orderings) और उनके सहायक साक्ष्य अलग-तुल्य (separable) हैं।

लेखक निष्कर्ष निकालते हैं कि अनुभवजन्य QSE के आगे बढ़ने के लिए, स्रोतों को न केवल यह रिपोर्ट करना चाहिए कि कौन जीतता है, बल्कि वह मेल खाने वाला साक्ष्य (matched evidence) भी रिपोर्ट करना चाहिए जो उस क्रम के दायरे को लॉक करने के लिए आवश्यक है। फ्रेमवर्क एक तंत्र प्रदान करता है जो एक ऐसी तुलना के बीच अंतर करता है जिसे ऑडिट किया जा सकता है (Sustained/Reversed/Unresolved) और एक ऐसी तुलना के बीच जो साक्ष्य की कमी के कारण मौलिक रूप से ऑडिट करने योग्य नहीं है (Boundary)। यह भविष्य के QSE अध्ययनों के लिए रिपोर्टिंग लक्ष्य को बदल देता है: पेपर्स को स्पष्ट रूप से उन बेसलाइन्स, सेटिंग्स, इंस्टेंस, बजट और परिणाम नियमों को उजागर करना चाहिए जो उस क्रम को लॉक करने के लिए आवश्यक हैं, और स्पष्ट रूप से चिह्नित करना चाहिए कि कहाँ एविडेंस बाउंड्रीज़ आगे के ऑडिटिंग को रोकती हैं।