A Building as a Repository: KIR, a Typed Intermediate Representation for Agent-Authored Building Information Models
تقدم هذه الورقة KIR، وهو تمثيل وسيط نمطي يعامل نماذج معلومات البناء كبرامج ذات إصدارات للكشف المنهجي عن سبعة أنماط فشل محددة وتمثيلها في عمليات الإنشاء التي يتم تأليفها بواسطة وكلاء مستقلين، مما يظهر تحسينات كبيرة في تشخيص الأخطاء واختصار الكود مقارنة بالتعامل المباشر مع واجهة برمجة تطبيقات المضيف.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل عالماً لا تكون فيه المخططات الهندسية لمدننا مجرد رسومات ثابتة، بل تعليمات حية تكتبها برمجيات ذكية. هذه البرمجيات مصممة لبناء نماذج رقمية للمباني، طبقة تلو الأخرى، وغرفة تلو أخرى، باستخدام برامج معقدة يعتمد عليها المعماريون والمهندسون كل يوم. التحدي يكمن في أن هذه البرامج صُممت للأيدي البشرية، وليس للآلات ذاتية التشغيل. فهي تتفاعل مع الأوامر بطرق غالباً ما تكون غير متوقعة: قد تفشل أداة ما بصمت، أو قد يتم اتخاذ قرار دون تسجيل السبب، أو قد تختفي معلومة بالغة الأهمية دون أثر. عندما يرتكب معماري بشري خطأً، يمكنه رؤية الخطأ، وفهم السياق، وإصلاحه. أما عندما يرتكب وكيل برمجِي (software agent) خطأً في هذه البيئة، فإنه غالباً لا يستطيع معرفة ما الذي حدث خطأً، أو ماذا كان يحاول أن يفعل، أو ما إذا كان المبنى الذي أنشأه يطابق بالفعل التصميم المعطى له. النتيجة هي نظام قد يدعي فيه الكمبيوتر أن المهمة قد أنجزت، حتى لو كان المبنى الذي أنتجه معيباً أو غير مكتمل.
هذه هي المشكلة التي سعى الباحث ديمتري كولكليف لحلها. لقد طرح سؤالاً بسيطاً ولكنه عميق: ماذا لو توقفنا عن مطالبة هؤلاء الوكلاء بكتابة الكود الخام الذي يتحدث مباشرة إلى برنامج البناء، وطلبنا منهم بدلاً من ذلك كتابة خطة واضحة ومعرفة النوع (typed plan) يمكن للمترجم (compiler) التحقق منها قبل بناء أي شيء؟ كانت النتيجة نظاماً جديداً يسمى KIR. هذا النظام يعامل المبنى ليس كمجموعة من الملفات، بل كبرنامج محمول في مستودع إصدارات (versioned repository)، تماماً مثل مكتبة من التعليمات التي يمكن قراءتها، وفحصها، ومراجعتها. الفكرة الجوهرية هي أنه قبل أن يحاول الوكيل بناء جدار أو وضع باب، يجب عليه أولاً أن يكتب بالضبط ما ينوي فعله، ويجب على نظام منفصل أن يتحقق من أن الخطة سليمة، وأن المراجع واضحة، وأن العواقب معروفة. إذا كانت الخطة غامضة، يرفض النظام المضي قدماً ويشرح بالضبط سبب الرفض، مقدماً قائمة بالتصحيحات الممكنة. هذا النهج ينقل العبء من التخمض والأمل إلى المعرفة والتحقق.
لقد بنى الباحثون هذا النظام للتعامل مع سبعة طرق محددة يمكن أن تسوء بها مشاريع البناء دون أن يلاحظ أحد ذلك. في الطريقة القديمة، قد يحاول وكيل تحديد مستوى طابق معين، ولكن إذا كان هناك مستويان بأسماء متشابهة، فقد يختار البرنامج أول واحد يجده ويمضي قدما، تاركاً الوكيل غير مدرك أنه اختار الخيار الخاطئ. في النظام الجديد، يتم رصد هذا الغموض فوراً. يتوقف النظام عن العملية ويقدم سجلاً بالرفض يدرج المشكلة بدقة والمرشحين المتاحين، مما يجبر الوكيل على اتخاذ قرار متعمد. وبالمثل، إذا ترك وكيل قيمة فارغة، متوقعاً أن يقوم البرنامج بتعبئتها بقيمة افتراضية، فإن النظام الجديد يسجل بالضبط مصدر هذه القيمة الافتراضية. إنه يحتفظ بسجل دائم لما إذا كانت القيمة قد كُتبت بواسطة الوكيل، أو حُسبت بواسطة ماكرو، أو زودها البرنامج نفسه. هذا يخلق مساراً للمصدر (provenance)، وتاريخاً لكل قرار تم اتخاذه في بناء النموذج.
لاختبار هذه الفكرة، أنشأ الباحثون بيئة محكومة حيث يمكنهم إجراء التجارب دون الحاجة إلى تشغيل برنامج البناء الفعلي. لقد بنوا مترجماً يأخذ خطة الوكيل المحددة النوع ويتحقق منها مقابل لقطة (snapshot) لنموذج مبنى. في إحدى التجارب، غدوا النظام بأربع وأربعين برنامجاً مختلفاً، بعضها يحتوي على أخطاء متعمدة صُممت لكسر النظام. رفض النظام بنجداً تسعة وعشرين من هذه البرامج المعيبة، موفراً رموز تشخيص مفصلة تشرح بالضبط ما هو الخطأ. والأهم من ذلك، أنه فعل ذلك دون الانهيار أو إلقاء خطأ غير معالج؛ بل توقف ببساطة وشرح المشكلة. بالنسبة للبرامج التي تم قبولها، أنتج النظام كمية هائلة من الكود لتشغيله في برنامج البناء الفعلي. تصميم مبنى واحد استغرق مائة سطر من التعليمات لوصفه في النظام الجديد، توسع إلى ما يقرب من أربعة ملايين حرف من الكود عند ترجمته لبرنامج المضيف. هذا الفرق الهائل يسلط الضوء على تعقيد البرمجيات الأساسية وقيمة وجود خطة مدمجة وقابلة للقراءة من قبل البشر تقع بين الوكيل والآلة.
كما قدم النظام طريقة جديدة للتفكير في حالة مشروع البناء. في الأنظمة التقليدية، تكون المعاملة (transaction) إما ناجحة أو فاشلة. في هذا النظام الجديد، هناك حالة ثالثة: "غير مؤكدة". إذا أرسل البرنامج أمراً لبناء جدار ولكن الاستجابة فُقدت أو كانت غير واضحة، فإن النظام لا يخمن ما إذا كان الأمر قد نجح أم لا، بل بدلاً من ذلك، يحدد الإجراء كـ "غير مؤكد" ويتطلب خطوة تحقق محددة قبل إمكانية إعادة المحاولة. هذا يمنع النظام من افتراض وجود عنصر بنائي بينما قد لا يكون موجوداً. كما بنى الباحثون "مساراً عكسياً"، وهو وسيلة لقراءة نموذج مبنى مكتمل وإعادته إلى لغة النظام. هذه العملية تتحقق من أن كل عنصر في النموذج يمكن تفسيره. إذا واجه النظام جزءاً من المبنى لا يستطيع فهمه أو التعبير عنه، فإنه لا يتجاهله بصمت، بل يسجله كـ "ذرة" (atom) مع سبب محدد للفشل، مما يضمن عدم ضياع أي جزء من المبنى أثناء الترجمة.
كان تقييم هذا النظام صارماً. اختبره الباحثون على برج محاكى مكون من ستين طابقاً، وهو هيكل معقد يحتوي على مئات الطوابق وآلاف الأعمدة. وجدوا أن النظام يمكنه إنشاء خطة المبنى بأكملها بتنسيق مدمج يزيد قليلاً عن أحد عشر ألف حرف، والتي توسعت بعد ذلك إلى الكود اللازم لبرنامج المضيف. كما اختبروا قدرة النظام على التعامل مع التعارضات عندما يحاول عدة وكلاء تعديل نفس المبنى. يستخدم النظام طريقة "المقارنة والتبديل" (compare-and-swap)، والتي تضمن أنه إذا حاول وكيلان تغيير نفس الجزء من المبنى في نفس الوقت، فإن النظام يكتشف التعارض ويرفض دمج التغييرات حتى يحل الوكلاء الخلاف. هذا يمنع نوع فساد البيانات الذي يحدث غالباً عندما يعمل عدة أشخاص على نفس الملف الرقمي.
ومع ذلك، يحرص الباحثون على توضيح ما لم يثبتوه بعد. فبينما يعمل النظام بشكل مثالي في اختباراتهم غير المتصلة بالإنترنت (offline tests) وينتج كوداً يتم ترجمته بنجاح، إلا أنهم لم يجروا بعد مقارنة منضبطة لمعرفة ما إذا كان الوكلاء الذين يستخدمون هذا النظام أفضل في بناء الأشياء من الوكلاء الذين يكتبون الكود مباشرة. هذه التجربة مخططة ولكنها لم تُنفذ بعد. تظهر النتائج الحالية أن النظام قوي، وأنه يكشف الأخطاء التي قد تمر دون ملاحظة، وأنه يوفر سجلاً واضحاً وقابلاً للفحص لكل قرار تم اتخاذه. إنه يفصل بين صحة الخطة ونجاح التنفيذ وصحة التصميم النهائي، ويعتبرها ثلاثة أشياء متميزة يجب التحقق منها بشكل منفصل.
تكمن أهمية هذا العمل في تحوله من نموذج التنفيذ الأعمى إلى نموذج البناء القائم على الأدلة. من خلال معاملة المبنى كبرنامج يمكن قراءته، وفحصه، ومراجعته، يمنح النظام الوكلاء المستقلين القدرة على التفكير في أفعالهم. إنه يوفر لغة للفشل، مما يسم يسمح للنظام بالقول "لا يمكنني فعل هذا بسبب X" بدلاً من مجرد الفشل بصمت. هذا النهج لا يجعل البرمجيات أكثر موثوقية فحسب، بل يجعل عملية البناء باستخدام الوكلاء شفافة وخاضعة للمساءلة. لقد أظهر الباحثون أنه من الممكن بناء نظام يعرف فيه الكمبيوتر ما يفعله، ولماذا يفعله، وما الذي حققه، مما يخلق أساساً لمستقبل يمكن فيه للوكلاء الأذكياء التعاون مع البشر لتصميم وبناء الهياكل المعقدة لعالمنا. يقف هذا العمل كدليل على أنه مع الأدوات الصحيحة، يمكن جسر الفجوة بين نية الوكيل والنتيجة النهائية بالوضوة والدقة.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.