What Output-Equivalence Oracles Miss: An Empirical Study of Equivalence-Invisible Bug Fixes in Quantum Transpilers (Qiskit, tket, Cirq)
تُظهر هذه الدراسة التجريبية أن أوراكل (oracles) تكافؤ المخرجات القياسية المستخدمة للتحقق من صحة المترجمات الكمومية تفشل في اكتشاف جزء كبير (حوالي 28%) من إصلاحات الأخطاء في العالم الحقيقي في Qiskit وtket وCirq، وتحديداً تلك المتعلقة بالعيوب غير المرئية في تخطيط الدوائر، أو سجلات التبديل، أو الحتمية التي لا تغير الوحدة (unitary) المحسوبة.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تعد الحواسيب الكمومية بحل مشكلات قد تستغرق أجهزتنا اليوم آلاف السنين لحلها، لكن بناءها وبرمجتها أمران في غاية الصعوبة. ولجعلها مفيدة، يستخدم العلماء برمجيات خاصة تسمى "المترجمات التحويلية" (transpilers). فكر في المترجم التحويلي كأنه مترجم يأخذ تعليمات مجردة ومعقدة مكتوبة لجهاز كمومي نظري، ويعيد كتابتها في مجموعة محددة من الأوامر التي يمكن لجهاز مادي حقيقي تنفيذها بالفعل. تتضمن هذه العملية إعادة ترتيب ترتيب العمليات ومطابقتها مع الاتصالات المحدودة المتاحة على الرقاقة. ولكي يكون هذا الترجمة مفيدة، يجب أن تعطي النتيجة النهائية نفس الإجابة التي تعطيها التعليمات الأصلية؛ فإذا غيرت الترجمة الحسابات، يصبح الكمبيوتر عديم الفائدة.
لسنوات، كانت الطريقة القياسية للتحقق مما إذا كان المترجم التحويلي يعمل بشكل صحيح هي مقارنة الإجابة النهائية للتعليمات المترجمة بالإجابة الأصلية. فإذا تطابقت الإجابات، تُعتبر الترجمة ناجحة. هذه الطريقة، المعروفة باسم "فحص تكافؤ المخرجات"، فعالة وموثوقة في رصد الأخطاء الكبرى. ومع ذلك، فإن لديها نقطة عمياء؛ فهي تنظر فقط إلى النتيجة النهائية، وتتجاهل الرحلة التي سلكتها البيانات للوصول إليها. تماماً كما قد يصل المسافر إلى وجهته الصحيحة، لكنه قد يكون سلك طريقاً خاطئاً، أو فقد أمتعته، أو وصل في يوم غير مناسب، يمكن للدائرة الكمومية أن تنتج الإجابة الصحيحة بينما تحمل أخطاءً خفية في بنيتها الداخلية. وتتعلق هذه الأخطاء الخفية بأشياء مثل الترتيب المحدد للبيانات، أو توقيت العمليات، أو التتبع الدقيق لحالة البيانات. وإذا كانت الإجابة النهائية صحيحة، فغالباً ما تمر هذه العيوب الداخلية دون ملاحظة، مما قد يتسبب في فشل الكمبيوتر لاحقاً عند استخدام الدائرة في سياق أكثر تعقيداً.
وضع فريق من الباحثين هدفاً لقياس مدى تكرار حدوث ذلك في العالم الحقيقي. وقد ركزوا على البرمجيات التي تشغل بعض أكثر المنصات استخداماً في الحوسبة الكمومية. وبدلاً من إنشاء اختبارات جديدة أو محاكاة أخطاء افتراضية، ذهبوا مباشرة إلى المصدر: وهو التاريخ الفعلي للإصلاحات التي قام بها المهندسون الذين يبنون هذه الأدوات. فقاموا بفحص مجموعة مختارة بعناية من 68 إصلاحاً للثغرات (bugs) التي تم دمجها في الكود الرئيسي لحزمة برمجية كمومية كبرى. وبالنسبة لكل إصلاح، طرحوا سؤالاً بسيطاً: لو استخدم المهندسون اختبار "التحقق من الإجابة النهائية" القياسي فقط، هل كانوا سيلاحظون المشكلة التي كان من المفترض أن يعالجها هذا الإصلاح؟
كانت النتائج مذهلة. فقد وجد الباحثون أنه في حوالي 28 بالمائة من الحالات، كان الاختبار القياسي سيفشل تماماً في رصد الخلل. وفي هذه الحالات، كان البرنامج معطلاً بطريقة مؤثرة — ربما كان يسجل التنسيق الخاطئ للبيانات أو يتصرف بشكل غير متوقع عند تشغيله عدة مرات — ولكن الإجابة الرياضية النهائية ظلت صحيحة. ولأن الاختبار القياسي يهتم فقط بالإجابة، فقد كان سيعتبر هذه النسخ المعطلة مثالية. وقد أكد الفريق هذه النتيجة من خلال النظر في الإصلاحات في حزمتين برمجيتين كموميتين مستقلتين أخريين. وفي إحداهما، كان معدل هذه الأخطاء غير المرئية أعلى، حيث بلغ 33 بالمائة. وفي الثالثة، كانت العينة أصغر ولكنها أشارت إلى نفس الاتجاه. وهذا يشير إلى أن المشكلة ليست فريدة من نوعها في برنامج واحد، بل هي فجوة جوهرية في كيفية تحققنا حالياً من الحواسيب الكمومية.
كما بحث الباحثون فيما إذا كانت هذه الأخطاء غير المرئية أسهل في الرصد من غيرها. فرب-ما كانت أكبر، أو أكثر تعقيداً، أو تستغرق وقتاً أطول للإصلاح، مما يسمح للمهندسين بتمييزها دون الحاجة إلى نوع جديد من الاختبارات. وقاموا بمقارنة الإصلاحات غير المرئية مقابل المرئية باستخدام خمس إشارات سطحية مختلفة، مثل عدد أسطر الكود التي تم تغييرها أو الوقت الذي استغرقه دمج الإصلاح. ووجدوا أنه لا يوجد فرق؛ فالأخطاء غير المرئية بدت تماماً مثل الأخطاء العادية. وهذا يعني أن المهندسين لا يمكنهم الاعتماد ببساطة على نظرة سريعة إلى الكود أو حجم التغيير لرصد هذه الأخطاء؛ فالاختبارات القياسية عمياء عنها حقاً.
وعند التعمق في طبيعة هذه الأخطاء غير المرئية، اكتشف الفريق نمطاً محدداً. فقد وقعت العديد من الأخطاء عند الحدود حيث ينتقل البرنامج بين طرق تمثيل البيانات الداخلية المختلفة. على سبيل المثال، عندما ينقل البرنامج قطعة من المعلومات من تنسيق عام إلى تنسيق متخصص لخطوة عتادية معينة، تظل النتيجة الرياضية صحيحة، ولكن "البيانات الوصفية" (metadata) — أي السجل الذي يوضح مكان البيانات أو كيفية ترتيبها — تتعرض للتلف. هذا التلف غير مرئي لاختبار الإجابة النهائية، ولكنه قد يتسبب في فشل الكمبيوتر عندما يحاول استخدام تلك البيانات لاحقاً. وأشار الباحثون إلى أن هذا يحدث غالباً عندما يتم نقل البرنامج إلى لغة برمجة جديدة أو عند دمج أجزاء مختلفة من النظام.
لا تدعي الدراسة أن طرق الاختبار الحالية عديمة الفائدة؛ ففحص الإجابة النهائية لا يزال ضرورياً وفعالاً. ومع ذلك، تظهر النتائج أن الاعتماد عليها وحدها يترك فجوة كبيرة في السلامة. فما يقرب من حالة واحدة من كل ثلاث حالات إصلاح في عيّنتهم كانت تعالج مشكلة لم يستطع الفحص القياسي رؤيتها. ويجادل الباحثون بأنه لضمان موثوقية الحواسيب الكمومية حقاً، يجب أن يتوسع عملية الاختبار لتتجاوز مجرد الإجابة النهائية؛ إذ يجب أن تفحص أيضاً السجلات الداخلية، وترتيب البيانات، واتساق العملية نفسها. ومن خلال تحديد المكان الذي تختبئ فيه هذه الأخطاء غير المرئية بالضبط، توفر الدراسة هدفاً واضحاً للجيل القادم من أدوات الاختبار، مما يضمن أن الحواسيب الكمومية في المستقبل لن تكون صحيحة رياضياً فحسب، بل ستكون سليمة بنيوياً أيضاً.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.