Specification Portability Across LLM Development Agents: Cross-Agent Compatibility in Specification-Driven Software Migration
تُثبت هذه الورقة أن المواصفات التي يتم إنشاؤها بواسطة وكيل ذكاء اصطناعي واحد لعمليات الهجرة من Oracle إلى PostgreSQL غالبًا ما تفشل في الانتقال بفعالية إلى وكلاء آخرين، مما يكشف عن تدهور كبير يعتمد على الوكيل في جودة التنفيذ ويسلط الضوء على الحاجة إلى استراتيجيات صريحة مثل التلقيم المعزز بالاسترجاع لضمان التوافق عبر الوكلاء في سير عمل هندسة البرمجيات.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في عالم تطوير البرمجيات المعاصر، انضم نوع جديد من العمال إلى الفريق: النموذج اللغوي الكبير. هذه برامج حاسوبية قوية تدربت على كميات هائلة من النصوص والأكواد، وهي قادرة على قراءة وصف لمهمة ما وكتابة التعليمات التي يحتاجها الحاسوب لتنفيذها. ومع ازدياد شيوع هذه الأدوات، ينتقل المطورون من مجرد طلب كتابة الكود منها إلى تزويدها بمخططات تفصيلية تُعرف بـ "المواصفات". تعمل هذه المواصفات كأدلة تشغيلية، تخبر النموذج بدقة ما يجب بناؤه، وكيف ينبغي أن يتصرف، وما هي القواعد التي يجب أن يتبعها. هذا النهج، المسمى "التطوير القائم على المواصفات"، يعد بجعل إنشاء البرمجيات أكثر موثوقية وهيكلية. ومع ذلك، برز سؤال جوهري مع بدء الفرق في استخدام نماذج متعددة ومختلفة لبناء نظام واحد: إذا كتب أحد النماذج مخططاً مثالياً، فهل سيتمكن نموذج آخر من قراءته وبناء الشيء نفسه؟ كان الافتراض السائد هو أن الخطة الجيدة تظل خطة جيدة بغض النظر عمن يقرؤها، لكن واقع كيفية تفسير هذه الآلات للمعلومات أكثر تعقيداً بكثير.
وضع باحثون في شركة "إيبام سيستمز" (EPAM Systems) هدفاً لاختبار هذا الافتراض عبر معاملة هجرة البرمجيات كتجربة منضبطة. اختاروا مهمة محددة وصعبة: نقل كود قاعدة بيانات من نظام "أوراكل" (Oracle) إلى نظام "بوستجري إس كيو إل" (PostgreSQL). يتحدث هذان النظامان لغات متشابهة ولكن بلهجات مختلفة، مما يتطلب ترجمة دقيقة للمنطق، وأنواع البيانات، والوظائف. وضع الفريق أولاً خطاً مرجعياً من خلال جعل نموذج واحد يولد مواصفات ثم يستخدم نفس تلك المواصفات فوراً لكتابة الكود الجديد. وقد نجح هذا الأمر بشكل جيد معقول؛ فمن بين أكثر من ألف ملف مصدر، تمكن النظام من إعادة توليد أكثر من 600 ملف، وعملت ما يقرب من 400 من تلك النصوص البرمجية الجديدة بشكل صحيح في البيئة المستهدفة. أثبت هذا أن طريقة استخدام مواصفات كخطوة وسيطة هي طريقة قابلة للتطبيق. ولكن الاختبار الحقيقي جاء عندما أدخلوا نموذجاً ثانياً ومختلفاً في العملية.
أنشأ الباحثون سيناريو حيث يقوم نموذج واحد، مثل "أمازون كيرو" (Amazon Kiro)، بكتابة مواصفات، ثم يُسلم هذا المستند إلى نموذج مختلف تماماً، مثل "جوجل جيمناي" (Google Gemini) أو "جيتهاب كوبايلوت" (GitHub Copilot)، لتوليد الكود. أرادوا معرفة ما إذا كان بإمكان النموذج الثاني فهم خطة النموذج الأول دون فقدان الجودة. كانت النتائج مذهلة ومفاجئة. تبين أن حجم المواصفات لم يكن له أي تأثير على النتيجة؛ فقد أنتج أحد النماذج وثيقة ضخمة ومفصلة تحتوي على ما يقرب من 1600 سطر من النص، بينما أنتج نموذج آخر نسخة موجزة تضم حوالي 200 سطر فقط. ومع ذلك، لم يكن طول الوثيقة مؤشراً على مدى جودة عمل الكود. في الواقع، كان الاكتشاف الأهم هو أن أصل المواصفات كان أمراً بالغ الأهمية. فعندما أُعطي "جوجل جيمناي" مواصفات كتبها "أمازون كيرو"، انهارت جودة الكود الناتج. فشلت النصوص البرمجية الجديدة في العمل، واحتوت على أخطاء في بناء الجملة (syntax errors)، ولم تشبه الهدف المنشود بأي شكل من الأشكال. لم يكن هذا الفشل مجرد خلل عابر؛ فقد كرر الباحثون التجربة وشاهدوا نفس الهبوط الدراماتيكي في الأداء، مما أكد أن النموذجين ببساطة لا يستطيعان الاتفاق على كيفية تفسير مجموعة التعليمات ذاتها.
ومع ذلك، لم يكن عدم التوافق هذا عاماً، مما أضاف طبقة من الدقة إلى الاكتشاف. فبينما عانى "جيمناي" بشدة مع مواصفات "كيرو"، تعامل "جيتهاب كوبايلوت" مع نفس الوثائق الغريبة بشكل أفضل بكثير، بل وأدى أحياناً بنفس كفاءة أدائه مع وثائقه الخاصة. أشار هذا إلى أن المشكلة لم تكن في أن الخطط الخارجية سيئة بطبيعتها، بل في أن النماذج المختلفة لديها طرق مختلفة في قراءة وفهم النصوص. ولمعالجة ذلك، اختبر الفريق عدة طرق لمساعدة النماذج على جسر الفجوة. حاولوا إعادة كتابة المواصفات الخارجية في تنسيق جديد قد يفضله النموذج المستقبِل، وحاولوا ضغط النص لجعله أقصر. ساعدت إعادة الكتابة "جيمناي" بشكل كبير، مما أعاد أداءه إلى مستوى قابل للاستخدام، لكن ضغط النص لم يقدم أي فائدة حقيقية. أما الاستراتيجية الأكثر واعدة فكانت تتضمن تقنية تسمى "التوليد المعزز بالاسترجاع" (Retrieval-Augmented Generation). فبدلاً من تغذية النموذج بالمواصفات كاملة دفعة واحدة، منح الباحثون النموذج أداة للبحث داخل الوثيقة واستخراج الأجزاء المحددة التي يحتاجها للمهمة الحالية فقط. لم ينتصر هذا النهج في كل المقاييس، لكنه كان الطريقة الوحيدة التي قدمت توازناً قوياً ومتسقاً في الأداء لكل من النماذج المتعثرة والناجحة.
تخلص الدراسة إلى أنه في عالم تُبنى فيه البرمجيات بواسطة فريق من وكلاء الذكاء الاصطناعي المختلفين، لا يمكن التعامل مع المواصفات كوثيقة محايدة وعالمية. فالخطة التي يكتبها وكيل ما ليست بالضرورة مجموعة تعليمات صالحة لوكيل آخر. تعتمد فعالية الكود بشكل كبير على العلاقة المحددة بين النموذج الذي كتب الخطة والنموذل الذي يبني البرمجيات. وإذا قام فريق باستبدال وكيل بآخر، فلا يمكنهم ببساطة افتراض أن المخططات الموجودة ستعمل؛ بل قد يحتاجون إلى تكييف لغة الخطة أو تغيير كيفية وصول الوكيل الجديد إلى المعلومات. تشير الأبحاث إلى أن مستقبل هندسة البرمجيات متعددة الوكلاء سيتطلب تركيزاً جديداً على كيفية هيكلة وتقديم المواصفات، لضمان أن المعرفة الواردة في الخطة يمكن بالفعل فهمها من قبل الآلة المكلفة ببنائها.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.