Fault-Class-Matched Test Oracles for Output-Invisible Quantum Transpiler Regressions
تقدم هذه الورقة عائلة من نماذج الاختبار المطابقة لفئة الخطأ التي تكتشف التراجعات غير المرئية في المخرجات في المترجمات الكمومية (quantum transpilers) — وتحديداً تلك التي تؤثر على البيانات الوصفية للتخطيط، والطور العالمي، وقابلية التكرار — وذلك من خلال التحقق من العقود الداخلية والعلاقات التحولية بدلاً من الاعتماد فقط على تكافؤ المخرجات، مما يحقق حساسية وخصوصية مثالية في أخطاء Qiskit وpytket الواقعية مع تقليل التكاليف الحسابية بشكل كبير.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل آلة تأخذ مجموعة معقدة من التعليمات الموجهة لحاسوب كمي، وتعيد كتابتها لتعمل على جهاز حقيقي ومحدد. هذه الآلة، التي تُسمى "المترجم البرمجي" (transpiler)، هي الجسر بين فكرة العالم المجردة والواقع المادي للمعالج الكمي. مهمتها هي تقرير أي الأجزاء المادية للآلة ستحمل المعلومات، وكيفية نقل هذه المعلومات إذا لم تكن الأجزاء متصلة مباشرة، وكيفية ترتيب الخطوات لجعل العملية أكثر كفاءة. لسنوات، كانت الطريقة القياسية للتحقق مما إذا كان هذا المترجم يعمل بشكل صحيح هي النظر إلى النتيجة النهائية. إذا أنتجت الآلة نفس المخرج الذي تنتجه مرجعية مثالية، يفترض المهندسون أن المهمة قد أُنجزت. إنه فحص منطقي بسيط: إذا كانت الإجابة صحيحة، فلا بد أن العمل صحيح.
ومع ذلك، فإن هذا الفحص البسيط ينطوي على خلل خفي. يمكن للآلة أن تنتج الإجابة النهائية الصحيحة بينما ترتكب أخطاءً سرية في ملاحظاتها الداخلية. فقد تبدل الأجزاء المادية الخاطئة، أو تفقد تتبع إزاحة طفيفة في التوقيت، أو تنتج ترتيباً داخلياً مختلفاً في كل مرة تعمل فيها، حتى لو ظل الرقم النهائي الذي تخرجه هو نفسه. هذه الأخطاء غير مرئية للفحص القياسي لأن الفحص ينظر فقط إلى الرقم النهائي، وليس إلى الملاحظات التي سجلتها الآلة أثناء القيام بالعمل. إذا مرت هذه الأخطاء الداخلية دون ملاحظة، فقد تتسبب في فشل الآلة لاحقاً عندما تُستخدم التعليمات بطريقة أكثر تعقيداً، أو قد تجعل النتائج غير موثوقة عندما يتم تشغيل الآلة عدة مرات.
لقد وضع فريق من الباحثين هدفاً لإيجاد طريقة لرؤية هذه الأخطاء غير المرئية. ركزوا على ثلاثة أنواع محددة من الأخطاء التي يغفل عنها الفحص القياسي. النوع الأول يتعلق بالخريطة التي ترسمها الآلة لتقرر أين تضع المعلومات؛ والثاني يتعلق بإزاحة ضئيلة وغير مرئية في توقيت العملية بأكملها؛ والثالث يتعلق بقيام الآلة بتقديم ترتيب داخلي مختلف في كل مرة تعمل فيها، حتى عندما تكون الإعدادات متطابقة تماماً. بنى الباحثون مجموعة جديدة من الأدوات المصممة خصيصاً لرصد هذه الأنواع الثلاثة من الأخطاء. وبدلاً من مجرد النظر إلى الإجابة النهائية، تقوم هذه الأدوات بقراءة الملاحظات الداخلية للآلة، وتتبع إزاحات التوقيت، والتحقق مما إذا كانت الآلة تنتج نفس الملاحظات في كل مرة.
اختبر الباحثون هذه الأدوات الجديدة على تسعة أخطاء واقعية تم إصلاحها بالفعل في نظام برمجيات كمية شهير. وفي كل حالة، فشلت الطريقة القديمة في فحص الإجابة النهائية في رؤية المشكلة. كانت الآلة قد أنتجت الرقم النهائي الصحيح، لذا قال الفحص القديم إن كل شيء على ما يرام. لكن الأدوات الجديدة، التي نظرت إلى الملاحظات الداخلية والتوقيت، رصدت الخطأ على الفور. لقد وجدت أن الآلة قد ارتكبت بالفعل خطأ في خريطتها، أو توقيتها، أو اتساقها، رغم أن النتيجة النهائية بدت مثالية. وهذا أثبت أن الطريقة القياسية في الفحص عمياء عن جزء كبير من الأخطاء التي يمكن أن تحدث.
وللتأكد من موثوقية أدواتهم وأنها ليست مجرد ضربة حظ، أنشأ الباحثون مئات الأخطاء الوهمية لمعرفة ما إذا كان بإمكان الأدوات رصدها. صنعوا أخطاءً أفسدت الخريطة الداخلية، وأخطاءً أزاحت التوقيت، وأخطاءً غيرت الترتيب الداخلي. رصدت الأدوات الجديدة كل واحد من هذه الأخطاء الوهمية. وفي الوقت نفسه، لم تطلق إنذارات كاذبة عندما كانت الآلة تعمل بشكل صحيح. كما اختُبرت الأدوات لمعرفة الوقت الذي تستغرقه في التشغيل؛ حيث تبين أن الأداة التي تفحص الخريطة الداخلية سريعة للغاية، إذ لا تستغرق سوى جزء ضئيل من الوقت المطلوب لفحص الإجابة النهائية. وكانت الأداة التي تفحص التوقيت سريعة أيضاً للمشكلات الصغيرة، وإن كانت تستغرق وقتاً أطول في المشكلات الكبيرة جداً. أما الأداة الثالثة، التي تفحص الاتساق، فقد وُجد أنها مفيدة للاختبارات المحددة والمستهدفة بدلاً من فحص كل عملية تشغيل.
أراد الباحثون أيضاً معرفة ما إذا كان نهجهم يعمل فقط على نظام برمجيات معين أم يمكنه العمل على أنظمة أخرى. لقد أعادوا بناء الأداة التي تفحص التوقيت من الصفر لتعمل على نظام برمجيات كمية مختلف تماماً. وعندما اختبروها، عملت بنفس كفاءة عملها في النظام الأول، حيث رصدت أخطاء التوقيت بدقة تامة. أظهر هذا أن المشكلة ليست فريدة من نوعها في حزمة برمجيات واحدة، بل هي مشكلة عامة في كيفية عمل هذه الآلات، وأن الحل يمكن تطبيقه على نطاق واسه.
تخلص الدراسة إلى أن الاعتماد فقط على الإجابة النهائية ليس كافياً لضمان عمل المترجم البرمجي الكمي بشكل صحيح. فما يقرب من ثمانية وعشرين بالمائة من الإصلاحات التي أُجريت على هذه المترجمات في الماضي كانت لأخطاء لم يستطع الفحص القياسي رؤيتها. ومن خلال إضافة هذه الفحوصات الجديدة والمستهدفة التي تنظر إلى الملاحظات الداخلية، والتوقيت، والاتساق، يمكن للمهندسين الآن رصد هذه المشكلات الخفية. إن الأدوات الجديدة سريعة، ودقيقة، وتعمل عبر أنظمة مختلفة، مما يوفر طريقة لبناء برمجيات كمية أكثر موثوقية دون إبطاء عملية التطوير. إن هذا العمل لا يحل محل الطريقة القديمة في الفحص، بل يسد الثغرات حيث تفشل الطريقة القديمة، مما يضمن أن الآلة لا تعطي الإجابة الصحيحة فحسب، بل تؤدي العمل بشكل صحيح أيضاً.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.