Untrusted Authors, Trusted Answers: A Calculus of Fidelity-Graded Translations
تقدم هذه الورقة حساباً مُحققاً بـ Lean 4 ونظاماً ثنائي المستويات يُسمى "hurdy-gurdy" يُمكّن النماذج اللغوية الكبيرة غير الموثوقة من توليد إجابات ذاتية التصديق وذات درجة دقة لأسئلة البرمجة، وذلك عبر تركيب مسارات ترجمة موثوقة ضمن رسم بياني متنامٍ من اللغات التي تم التحقق منها بشرياً.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
معضلة المحقق: عندما لا يمكنك الوثوق بالمرسل
تخيل أنك تحاول حل لغز، مثل معرفة ما إذا كان تفاعل كيميائي معين سينفجر أو ما إذا كان برنامج كمبيوتر سيتعطل. في عالم علوم الكمبيوتر، يسمى هذا "التحقق" (verification). عادةً، لحل هذه الألغاز، يتعين عليك ترجمة المشكلة الأصلية المعقدة والفوضوية إلى لغة أبسط يمكن لمحلل كمبيوتر فائق الذكاء فهمها. فكر في الأمر كترجمة رواية مكتوبة بلغة ميتة إلى اللغة الإنجليزية لكي يتمكن محقق حديث من قراءتها.
المشكلة هي أنه في كل مرة تترجم فيها شيئًا، فإنك تخاطر بارتكاب خطأ. ربما أغفل المترجم كلمة، أو ربما أساء فهم جملة. في الماضي، كانت الطريقة الوحيدة للتأكد من أن الترجمة مثالية هي إثبات، باستخدام رياضيات ثقيلة، أن المترجم صحيح بنسبة 100%. لكن إثبات أن المترجم مثالي أمر صعب للغاية، مثل محاولة إثبات أن الإنسان لن يرتكب خطأً مطبعيًا طوال حياته. إذا كان المترجم مخطئًا، فقد يحل المحقق الخاص بك لغزًا خاطئًا، ولن تعرف ذلك أبدًا. تسأل هذه الورقة سؤالًا جريئًا: ماذا لو توقفنا عن محاولة العثور على مترجم مثالي، وبدلاً من ذلك بنينا نظامًا يمكننا فيه الوثوق بـ الإجابة حتى لو كان المترجمون معيبين؟
آلة "هيردي-جيردي" (Hurdy-Gurdy): الثقة في الإجابة، لا في المؤلف
تقدم هذه الورقة طريقة جديدة للتفكير في ترجمات الكمبيوتر، تسمى hurdy-gurdy. بدلاً من الاعتماد على مترجم واحد مثالي، بنى المؤلفون نظامًا يعامل الترجمات كشبكة من المسارات المختلفة. تخيل أنك بحاجة للوصول من منزلك (البرنامج الأصلي) إلى وجهة تُعرف فيها الإجابة (المحلل). بدلاً من اتخاذ طريق واحد، تبني hurdy-gurdy خريطة بها مسارات عديدة. بعض المسارات بناها بشر، وبعضها ذكاء اصطناعي، وبعضها فرق عمل مختلفة. والأهم من ذلك، أن النظام لا يفترض أن أيًا من هذه المسارات مثالي. بدلاً من ذلك، يستخدم مجموعة ذكية من القواعد للتحقق مما إذا كانت المسارات تتفق مع بعضها البعض.
الفكرة الجوهرية هي "المربع التبادلي" (commuting square). تخيل أن لديك برنامجًا في اللغة (أ). يمكنك ترجمته إلى اللغة (ب) وتشغيله هناك. أو يمكنك ترجمته إلى اللغة (ج) وتشغيله هناك. إذا كانت كلتا الترجمتين صادقتين، فيجب أن يرويا لك نفس القصة حول ما يفعله البرنامج. يقوم النظام بتشغيل كلا المسارين ويقارن النتائج. إذا تطابقت، فهذه علامة قوية على أن الإجابة صحيحة. وإذا اختلفتا، فإن النظام لا يكتفي بالقول "خطأ" فحسب؛ بل يعمل كالمحقق، حيث يغوص خطوة بخطوة للعثور على المترجم الذي ارتكب الخطأ بالضبط، وأي جزء محدد من البرنامج تسبب في الخلل. وهذا يسمح للنظام بالإمساك بالأخطاء حتى لو كان المترجمون غير موثوقين أو تم كتابتهم بواسطة وكلاء ذكاء اصطناعي قد يهلوسون.
مستويان: "الاستخدام" و"النمو"
يعمل النظام على مستويين متميزين، أو طبقتين، يعملان معًا ولكن لا يختلط عملهما أبدًا.
مستوى الاستخدام (اللاعب): هذا هو المكان الذي تُجاب فيه الأسئلة. تخيل مراهقًا فضوليًا (أو ذكاءً اصطناعيًا) يسأل: "هل سيتعطل هذا البرنامج؟" ينظر النظام إلى خريطة المسارات الخاصة به. قد يرسل البرنامج عبر مسارين مختلفين: أحدهما مبني من وصف يدوي لشريحة كمبيوتر، والآخر مبني من نموذج رياضي رسمي لنفس الشريحة. إذا قال كلا المسارين "نعم، سيتعطل"، واتفقا على كيفية تعطل البرنامج، فإن النظام يكون واثقًا جدًا. إذا كانت الإجابة هي "نعم، سيتعطل"، يمكن للنظام حتى أخذ البرهان ("الشاهد") وتشغيله بشكل عكسي، خطوة بخطوة، في اللغة الأصلية ليظهر لك بالضبط ما كان يفعله البرنامج عند التعطل. هذا يشبه المحقق الذي لا يكتفي بالقول "الخادم هو الفاعل"، بل يعيد عرض مسرح الجريمة في الوقت الفعلي لإثبات وقوعها.
مستوى التطور (الباني): هنا تصبح الخريطة أكبر. إذا واجه النظام سؤالًا لا يستطيع الإجابة عليه (ربما لأنه لا يملك مسارًا لنوع معين من المنطق)، فإنه لا يستسلم. بل يكتب السؤال كـ "طلب". ثم يطلب من وكيل ذكاء اصطناعي بناء مترجم جديد لسد تلك الفجوة. وبمجرد بناء المترجم الجديد، يتم اختباره مقابل المسارات الموجودة. إذا اجتاز الاختبارات، يتم إضافته إلى الخريطة. وإذا فشل، يتم إصلاحه أو رفضه. القاعدة الرئيسية هنا هي أن النظام لا يسمح أبدًا لمترجم جديد بتغيير الإجابات على الأسئلة القديمة؛ بل يضيف فقط احتمالات جديدة. يسمى هذا "الترس" (ratchet)؛ فهو يتحرك للأمام فقط، ولا يعود أبدًا للخلف.
الاكتشاف الكبير: الثقة أحادية الاتجاه
الاكتشاف الأكثر إثارة للاهتمام في الورقة هو الفرق الجوهدي بين نوعين من الإجابات: الوجودية (إيجاد شيء يحدث بالفعل) والكلية (إثبات أن شيئًا ما لا يحدث أبدًا).
- الإجابات الوجودية (حالة "نعم"): إذا وجد النظام طريقة لتعطل البرنامج، فيمكنه إثبات ذلك بنسبة 100% عن طريق إعادة تشغيل التعطل في اللغة الأصلية. حتى لو كان كل مترجم وكل محلل في المنتصف يكذب، فإن إعادة التشغيل تثبت وقوع التعطل. الثقة هنا مجانية تقريبًا لأن الدليل يحمل نفسه.
- الإجابات الكلية (حالة "لا"): إذا قال النظام إن البرنامج لا يتعطل أبدًا، فمن الصعب جدًا إثبات ذلك. لا يمكنك إعادة تشغيل حدث "لم يحدث شيء فيه". هنا، يجب على النظام الاعتماد على قوة الشبكة بأكملها: اتفاق المسارات المستقلة المتعددة، ودرجات المترجمين، والشهادات الرياضية. هذا هو المكان الذي ينفق فيه النظام "ميزانية الثقة" الخاصة به. إنه يشبه هيئة المحلفين: إذا قال شاهد واحد "لم يفعل ذلك"، فأنت بحاجة إلى فريق كامل من الشهود المستقلين لتكون متأكدًا.
ما الذي فعله النظام في الواقع
لم يكتب المؤلفون نظرية فحسب؛ بل بنوا نموذجًا أوليًا يعمل واختبروه. أنشأوا سجلًا يحتوي على 13 لغة برمجة مختلفة (مثل C وPython وتعليمات شرائح الكمبيوتر) و 15 زوجًا مختلفًا من الترجمة تربط بينها. حتى أنهم جعلوا النظام يبني بعض هذه المترجمات باستخدام وكلاء ذكاء اصطناعي لم يتلقوا أي إشراف بشري، باستثناء قواعد النظام نفسه.
كانت النتائج مبهرة. عندما طلبوا من النظام حل 78 سؤالًا مختلفًا حول برامج الكمبيوتر (بناءً على معايير اختبار واقعية)، أجاب النظام على 100% منها بشكل صحيح. فعل ذلك عن طريق تشغيل الأسئلة عبر مسارين مختلفين (واحد من وصف يدوي، وآخر من نموذج رسمي) والتحقق من توافقهما. وفي الحالات التي وجد فيها النظام تعطلاً، نجح في إعادة تشغيل التعطل في الكود الأصلي لإثباته. وفي الحالات التي قال فيها "لا يوجد تعطل"، استخدم طريقة "معتمدة" تتضمن مُدققًا تم التحقق منه رسميًا (قطعة صغيرة ومثالية من الكود) للتدقيق في الرياضيات، مما ضمن أن الإجابة كانت صلبة.
كما اكتشف النظام أخطاءه الخاصة. في إحدى الحالات، ارتكب المترجمون الذين بناهم الذكاء الاصطناعي خطأً محددًا تسبب في اتفاقهم على إجابة خاطئة (فشل مشترك النمط). استطاعت بنية النظام، التي تتضمن فحص "التنوع"، اكتشاف ذلك في النهاية من خلال مقارنة النتائج مع محاكي خارجي مستقل. أثبت هذا أن النظام يمكنه العثور على الأخطاء حتى في بناة الذكاء الاصطناعي الخاصين به.
لماذا يهم هذا
تشير هذه الورقة إلى طريقة جديدة للتعامل مع مستقبل البرمجيات، حيث قد يكتب الذكاء الاصطناعي الكثير من الكود. بدلاً من الأمل في أن يكون كُتّاب الذكاء الاصطناعي مثاليين، يمكننا بناء أنظمة تتحقق من الإجابات من خلال فحص المسارات المتعددة والمستقلة. لا يحتاج النظام للوثوق بالمؤلف؛ بل يثق في البنية التحتية. إنه يثبت أنه حتى مع مؤلفين غير موثوقين، يمكننا الحصول على إجابات موثوقة، بشرما توفرت الأدوات الصحيحة للتحقق من العمل. النظام ليس مثاليًا بعد — فهو لا يغطي كل البرامج الممكنة، ويعتمد على بعض الافتراضات بشأن المفسرات الأساسية — ولكنه يثبت أن نهج "الثقة من خلال البنية" هذا يعمل ويمكن أن ينمو بمرور الوقت، ويصبح أفضل وأكثر موثوقية مع كل سؤال جديد يجيب عليه.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.