When Equivalent Quantum Circuits Lose Synthesis Choices
تُظهر هذه الورقة أن تحويل الدوائر الكمومية عبر تنسيقات وسيطة مثل OpenQASM غالباً ما يؤدي إلى تدمير المعلومات الهيكلية عالية المستوى، مما يمنع المترجمات من تطبيق طرق التخليق المثلى، وتقترح إطار عمل "مُتحقق منه" (Verified) لتسجيل وإعادة بناء هذه العمليات لاستعادة قدرات التخليق.
المؤلفون الأصليون:Boshuai Ye, Peng Liang, Arif Ali Khan
تعد الحواسيب الكمومية بحل مشكلات قد تستغرق أجهزتنا اليوم آلاف السنين لفك شفرتها، لكنها هشة للغاية. ولتشغيل برنامج ما، يجب على العلماء ترجمة أفكارهم المعقدة إلى تسلسل من التعليمات البسيطة التي يمكن للأجهزة تنفيذها فعليًا. تتم هذه الترجمة بواسطة "المترجم" (compiler)، وهو قطعة من البرمجيات تعمل كمعماري بارع. يأخذ المترجم المفاهيم عالية المستوى — مثل تحويل رياضي يُستخدم لإيجاد أنماط في البيانات — ويقرر بالضبط كيفية بنائها باستخدام الأدوات المحددة والمحدودة المتاحة على الشريحة الكمومية. ومن الأهمية بمكان أن هناك غالبًا أكثر من طريقة لبناء هذه الهياكل؛ فبعض التصاميم تستخدم موارد أقل وتكون أقل عرضة للفشل، بينما البعض الآخر أكثر متانة ولكن بتكلفة أعلى. ومهمة المترجم هي اختيار التصميم الأفضل بناءً على الظروف المحددة للآلة التي يعمل عليها.
ومع ذلك، تم اكتشاف مشكلة صامتة في الطريقة التي يتم بها مشاركة هذه البرامج ونقلها بين أدوات برمجية مختلفة. فعندما يُحفظ برنامج كمومي كنص ليقرأه نظام آخر، أو عندما يتم تحويله من تنسيق إلى آخر، يمكن للتعليمات التفصيلية حول كيفية بناء جزء معين من البرنامج أن تتلاشى. يظل البرنامج يعمل بشكل صحيح من الناحية الرياضية، لكن البرنامج المستقبِل يفقد القدرة على اختيار التصميم الأكثر كفاءة، مما يضطره لاستخدام طريقة بناء افتراضية، وغالبًا ما تكون أكثر ركاكة. يحدث هذا دون أي علامات تحذير؛ فلا تظهر البرمجيات أي أخطاء، وتبدو النتيجة النهائية كما هي، ومع ذلك تصبح الدارة الأساسية أكبر حجمًا وأكثر عرضة للفشل.
وقد سعى الباحثون بوشواي يي، وبينج ليانغ، وعارف علي خان إلى قياس مدى تكرار حدوث ذلك وما هي التكلفة المترتبة عليه. وركزوا على ثلاثة أطر عمل برمجية رئيسية يستخدمها العلماء اليوم: Qiskit وTKET وCirq. واختبروا ما يحدث عندما يتم إرسال دارة كمومية عبر "رحلة ذهاب وإياب"، حيث يتم تصديرها كنص ثم استيرادها فورًا مرة أخرى، أو عندما يتم تمريرها بين مترجمين مختلفين. وكشفت تجاربهم أنه في كثير من السيناريوهات الشائعة، يتم تجريد التعليمات عالية المستوى. فعلى سبيل المثال، عندما أُرسل نوع معين من البوابات (gates) عبر تبادل نصي مباشر، لم يعد بإمكان البرنامج الذي استقبلها تطبيق طرق البناء المتخصصة والفعالة الخاصة به. ظل البرنامج يعمل، ولكنه أُجبر على استخدام بناء عام وأقل كفاءة.
إن عواقب هذا الفقدان ليست نظرية فحسب، بل هي ملموسة وهامة. ففي اختبار تضمن دارة مصممة للبحث عن عناصر في قاعدة بيانات، تسبب فقدان القدرة على اختيار أفضل طريقة بناء في قفزة في عدد بوابات الكيوبت الثنائية (two-qubit gates) بنسبة 37.2 بالمائة. وفي الحوسبة الكمومية، تعد بوابات الكيوبت الثنائية العمليات الأكثر عرضة للخطأ، وإضافة المزيد منها يقلل بشكل كبير من فرص الحصول على إجابة صحيحة. وفي مجموعة أخرى من الاختبارات، وجد الباحثون أنه عندما يتم إرسال برنامج عبر تبادل نصي، زاد عدد هذه البوابات الحرجة بنسبة تصل إلى 164 بالمائة في بعض الحالات. وأشار الباحثون إلى أن فقدان الكفاءة هذا يحدث بصمت؛ فالبرنامج لا يتوقف عن العمل، والفحوصات القياسية التي تتحقق من منطق البرنامج لا تزال تنجح، لأن البرنامج لا يزال يحسب الإجابة الصحيحة، ولكن بطريقة أكثر تكلفة بكثير.
ولحل هذه المشكلة، طور الفريق أداة تسمى "Verified". وبدلاً من الاعتماد على البرنامج المستقبِل لتذكر التصميم الأصلي بشكل سحري، تحتفظ أداة "Verified" بسجل منفصل للعملية عالية المستوى قبل إرسالها بعيدًا. وعندما يعود البرنامج، تتحقق هذه الأداة مما إذا كانت الدارة التي استلمتها لا تزال تطابق السجل الأصلي. فإذا تغيرت الدارة بسبب عمليات أخرى بطريقة تجعل السجل قديمًا، ترفض الأداة إعادة بناء العملية عالية المستوى، مما يمنع حدوث الأخطاء. أما إذا كان السجل لا يزال صالحًا، فإنها تعيد بناء العملية عالية المستوى، مما يستعيد القدرة على اختيار التصميم الأكثر كفاءة. وفي اختباراتهم، نجحت هذه الطة في استعادة التصاميم الفعالة المطلوبة في كل حالة كان ذلك ممكنًا فيها، بينما رفضت بشكل صحيح السجلات التي أصبحت قديمة.
وخلصت الدراسة إلى أن الحفاظ على الحوسبة ليس كافيًا؛ بل يجب على الأدوات البرمجية المستخدمة لمشاركة وتجميع البرامج الكمومية أن تحافظ أيضًا على الخيارات المتاحة للمترجم. ووجد الباحثون أن مجرد حفظ برنامج كنص غالبًا ما يدمر هذه الخيارات. وهم يقترحون أن الأدوات المستقبلية يجب أن تبلغ صراحةً عند تجاهل طلب تصميم معين وفعال، كما يجب أن تتحقق من أي سجلات تُستخدم لإعادة بناء العمليات عالية المستوى قبل القيام بذلك. وبدون هذه الضمانات، يمكن أن تتقوض إمكانات الحواسيب الكمومية للتفوق على الآلات التقليدية بسبب عدم الكفاءة غير الضرورية التي تُدخل في عملية مشاركة وتجميع برامجها.
ملخص تقني: عندما تفقد الدوائر الكمومية المكافئة خيارات التصنيع
1. بيان المشكلة
تقوم المترجمات الكمومية (Quantum compilers) بترجمة العمليات عالية المستوى (مثل تحويل فورييه الكمومي QFT، وبوابات Multi-Controlled X) إلى دوائر على مستوى البوابات. غالبًا ما تمتلك هذه العمليات عالية المستوى طرق تصنيع (synthesis) متعددة تؤدي إلى أعداد بوابات وأعماق مختلفة اعتمادًا على قيود الأجهزة (مثل الاتصال، وتوفر البوابات المساعدة/ancilla). ومع ذلك، أثناء التطوير والترجمة، تخضع الدوائر بشكل متكرر لتغييرات في التمثيل: التسلسل (مثل QPY)، التبادل النصي (OpenQASM 2/3)، التحويل بين المترجمات (مثل من Qiskit إلى TKET)، أو التنزيل الصريح (explicit lowering) إلى بوابات أساسية.
بينما تحافظ هذه التغييرات على الحساب الوظيفي (التحويل الوحدوي/unitary transformation)، إلا أنها غالبًا ما تجرد البيانات الوصفية (metadata) للعملية عالية المستوى، مستبدلة إياها بتنفيذ ثابت على مستوى البوابات أو تعريف بوابة عام. نتيجة لذلك، يفقد المترجم المستلم توافر التصنيع (synthesis availability): أي القدرة على تطبيق طرق التصنيع على العملية عالية المستوى الأصلية. هذا الفقدان يتسم بالخفاء؛ حيث تنجح عملية الترجمة وتجتاز فحوصات التكافؤ الوظيفي، ومع ذلك قد تعاني الدائرة الناتجة من أعداد أعلى بكثير من بوابات الكيوبت الثنائية (two-qubit gates) ومعدلات خطأ متزايدة على الأجهزة ذات الضجيج. يحدد البحث فجوة حرجة: الأدوات الحالية لا تبلغ عن فشل تطبيق طريقة تصنيع مطلوبة نتيجة لتجاوز حدود التمثيل هذه.
2. المنهجية
أجرى المؤلفون دراسة تجريبية شاملة عبر ثلاثة أطر عمل رئيسية لمترجمات الكم: Qiskit و TKET و Cirq.
التصميم التجريبي
الموضوعات: تمت دراسة أربع عائلات من العمليات عالية المستوى: تحويل فورييه الكمومي (QFT)، وMulti-Controlled X (MCX)، وLinearFunction، وPauliEvolutionGate.
مسارات التمثيل: قيمت الدراسة أربعة أنواع من تغييرات التمثيل:
تسلسل الإطار البرمجي: QPY (في Qiskit)، وJSON (في TKET وCirq).
تبادل OpenQASM: رحلات ذهاب وإياب مباشرة عبر نصوص OpenQASM 2 وOpenQASM 3.
التحويل بين المترجمات: رحلات ذهاب وإياب بين Qiskit وTKET.
التنزيل الصريح (Explicit Lowering): التفكيك إلى بوابات أولية.
المقاييس: المقياس الأساسي هو وسيط عدد بوابات الكيوبت الثنائية عبر عشر بذور عشوائية للتوجيه (routing seeds). المقاييس الثانوية شملت عمق الدائرة ووقت التشغيل المتوقع في بيئة مقاومة للأخطاء (fault-tolerant runtime). تم التحقق من التكافؤ الوظيفي باستخدام فحص تكافؤ المؤثرات (المصفوفات الكثيفة) والمخططات الوصفية (decision diagrams).
مجموعات البيانات:
التجارب المنضبطة: 36 حالة مصممة للدراسة ومسح للموارد لـ 102 حالة.
تحليل المشروع: تدقيق لسجل نظام Qiskit البيئي (179 مدخلًا، 29 مستودعًا) لتحديد أنماط الاستخدام الواقعي، واختيارات التصنيع غير الافتراضية، ومواقع تغيير التمثيل.
الدوائر الملتقطة: 259 دائرة تم التقاطها من اختبارات المشاريع، بما في ذلك 216 دائرة MCX.
خط معالجة متكامل (End-to-End): خط معالجة MQT يعالج دوائر Grover.
آلية الاسترداد "المحققة" (Verified)
لمعالجة فقدان التصنيع، قدم المؤلفون أداة استرداد تسمى Verified. تعمل من خلال:
التسجيل: تخزين سجل العملية (النوع، المعلمات، ربط الكيوبت، وبصمة المنطقة) قبل تغيير التمثيل.
التحقق: بعد تغيير التمثيل، تحدد الأداة المنطقة المقابلة في الدائرة المستلمة وتتحقق مما إذا كان السجل لا يزال صالحًا (أي أن المنطقة لم تتغير بسبب التوجيه أو التحسين).
إعادة البناء: فقط إذا تطابق السجل مع الدائرة المستلمة، تقوم الأداة بإعادة بناء العملية عالية المستوى، مما يسمح للمترجم بإعادة تطبيق التصنيع.
3. النتائج الرئيسية
فقدان توافر التصنيع
مسارات OpenQASM: أدت رحلة ذهاب وإياب مباشرة عبر OpenQASM 3 إلى إزالة توافر التصنيع في جميع الحالات الـ 360 المسلمة (144 MCX، 36 QFT، 180 PauliEvolution). في كل حالة، استدعى المترجم طريقة التصنيع المطلوبة، ولكن نظرًا لأن المدخل كان بوابة عامة وليس العملية عالية المستوى المحددة، لم ترجع الطريقة أي دائرة. نجحت عملية الترجمة بصمت، ولكن ضاعت فرصة التحسين.
التسلسل (Serialization): حافظت رحلات QPY في Qiskit على توافر التصنيع لجميع الحالات. ومع ذلك، حافظت رحلات JSON في TKET وCirq على التوافر فقط للإنشاءات الأصلية (native constructions)، وفشلت في حالات التبادل النصي لـ OpenQASM.
التحويل بين المترجمات: حافظت رحلات Qiskit–TKET–Qiskit على التوافر فقط للعمليات المدعومة أصليًا في TKET (مثل MCX)، لكنها فشلت في عمليات أخرى (مثل QFT).
تأثير التكلفة
زيادات عدد البوابات: أدى فقدان توافر التصنيع إلى زيادات كبيرة في أعداد بوابات الكيوبت الثنائية حيث اختلف التصنيع المفقود عن التنفيذ الثابت.
في خط معالجة MQT، أدت رحلة ذهاب وإياب عبر OpenQASM 2 لدائرة Grover مكونة من ثمانية كيوبتات إلى زيادة عدد بوابات الكيوبت الثنائية بنسبة 37.2% وزيادة وقت التشغيل المتوقع في بيئة مقاومة للأخطاء بنسبة 68.0%.
في اختبارات المشاريع الملتقطة، شهدت 38 دائرة MCX (مع توفر بوابات مساعدة نظيفة) زيادات في عدد البوابات تتراوح بين 10–164% بعد تبادل OpenQASM.
شهدت خمس دوائر حسابية صغيرة (جمع/adders) زيادات بنسبة 25–57% حتى بدون بوابات مساعدة.
فرص التحسين: استخدم مرجع "أفضل تصنيع ملاحظ" (الذي يختبر جميع الطرق) وسيطًا أقل بنسبة 16.2% من بوابات الكيوبت الثنائية مقارنة بمرجع التصنيع المبكر. هذه الوفورات المحتملة فُقدت تكرارًا عند مرور الدوائر عبر مسارات OpenQASM.
أداء الاسترداد عبر Verified
الاستعادة: في 830 عملية استرداد منضبطة، نجحت أداة Verified في استعادة التصنيع المطلوب في جميع الحالات التي كان فيها السجل صالحًا.
السلامة: رفضت Verified جميع السجلات الـ 17 القديمة (السجلات التي تغيرت فيها الدائرة بسبب التوجيه أو التحسين) في مجموعة السجلات القديمة الموسعة. أدى إعادة بناء هذه السجلات القديمة دون تحقق إلى إنتاج دوائر غير مكافئة في كل حالة.
المقايضات: رفضت Verified بعض السجلات الصالحة (إيجابيات كاذبة) لأن فحوصاتها كانت أكثر صرامة من تسميات الصلاحية (مثل اشتراط بقاء اسم المنطقة).
العبء الإضافي: تراوحت أوقات التحقق الوسيطة بين 2.0 مللي ثانية (QFT) و 638 مللي ثانية (LinearFunction) لكل عائلة عمليات.
4. المساهمات
توصيف الفقدان: يميز البحث بين "توافر التصنيع" و"التكافؤ الوظيفي"، ويوضح أن تغييرات التمثيل (خاصة مسارات OpenQASM) يمكن أن تلغي خيارات التصنيع بصمت مع الحفاظ على الحساب.
الدليل التجريبي: من خلال التجارب المنضبطة، وتدقيق المستودعات، وتحليل خطوط المعالجة، يحدد المؤلفون عقوبات التكلفة (تصل إلى زيادة 37.2% في عدد البوابات) الناتجة عن هذا الفقدان عبر Qiskit وTKET وCirq.
أداة Verified: تقديم وتقييم Verified، وهي آلية تسجل العمليات عالية المستوى وتعيد بناءها فقط بعد التحقق من صلاحيتها مقابل الدائرة المسلمة، مما ينجح في استعادة توافر التصنيع دون المساس بالتكافؤ الوظيفي.
5. الأهمية والادعاءات
يزعم البحث أن الحفاظ على الحساب ليس كافيًا للترجمة الكمومية المثلى. إن فقدان توافر التصنيع هو مشكلة منتشرة في برمجيات الكم الحالية تؤدي إلى دوائر دون المستوى الأمثل وتقليل دقة التنفيذ على الأجهزة ذات الضجيج.
يؤكد المؤلفون على ما يلي:
الفشل الصامت: لا تنبه المترجمات الحالية المستخدمين عندما تفشل طريقة التصنيع المطلوبة في التطبيق بسبب تغييرات التمثيل.
ضرورة التحقق: إن إعادة بناء العمليات عالية المستوى من السجلات دون تحقق أمر غير آمن ويمكن أن ينتج دوائر غير مكافئة.
توصيات التصميم: يجب على مطوري المترجمات وأدوات التبادل:
الإبلاغ عما إذا كان طلب التصنيع قد تم تنفيذه بالفعل.
الحفاظ على العمليات عالية المستوى حيثما أمكن، أو الاحتفاظ بسجلات العمليات للاسترداد المتحقق منه.
الإبلاغ عن تمثيل الدائرة المورد للمترجم في التقييمات، حيث يمكن أن يكون للدوائر المتكافئة وظيفيًا تكاليف مختلفة تمامًا بناءً على توافر التصنيع.
تخلص الدراسة إلى أنه بينما يسهل إغفال فقدان توافر التصنيع، إلا أن له آثارًا سلبية ملموسة على تكلفة الدائرة ووقت التشغيل، وأن الاسترداد المتحقق منه يعد استراتيجية قابلة للتطبيق للتخفيف من هذه الخسائر.