LLM الطريقة الأكثر استقرارًا لكتابة التعليمات البرمجية هي كتابة DSL أولاً

منذ فترة، رأيت نفس الموقف مرارًا وتكرارًا: إلقاء المتطلبات مباشرة على النموذج، وسرعة الإنشاء سريعة جدًا، وإعادة العمل سريعة أيضًا؛ قم أولاً بوضع المتطلبات في طبقة DSL، ثم دع النموذج يكتب التنفيذ حول هذه الطبقة من النموذج الدلالي، ومن الواضح أن الإخراج مستقر. التغيير مباشر جداً. المفتاح ليس ما إذا كان من الممكن كتابة النموذج، ولكن ما إذا كان قد تم إغلاق المساحة الاختيارية أولاً.

اللغة الطبيعية مناسبة لقول التوجيهات، ولكنها ليست مناسبة لاتخاذ الكثير من القرارات الضمنية. سيتم تقسيم المتطلبات التي تبدو بسيطة إلى العديد من الأحكام الصغيرة عند تنفيذها: كيفية تسمية الحالة، وما إذا كان الفشل يعتبر مكتملًا، وعدد مرات إعادة المحاولة، والمنطقة الزمنية التي تعتمد عليها النافذة الزمنية، والطبقة التي تم كتابة السجل عليها. وطالما أن هذه الأحكام لا تزال مخفية في عملية التوليد، فإن النموذج سوف يملأ التفاصيل ويغير الحدود في نفس الوقت. يمكن تشغيل الشيء المكتوب النهائي، ولكن من الصعب مراجعته.

اللغة الطبيعية لا تصلح إلا للحديث عن المشاكل

LLM جيد جدًا في تطوير الوصف الغامض إلى نص كامل، كما أنه جيد جدًا في إكمال النية في مسودة قابلة للقراءة. ما لا يجيده هو التسمية المستقرة طويلة المدى والقيود المفروضة على مجموعة من قواعد العمل. بمجرد أن تتضمن المتطلبات تدفق الحالة والفروع غير الطبيعية والحدود الزمنية وحدود الأذونات، تبدو هذه الكلمات واضحة في العقل، لكنها غالبًا لا يتم الانتهاء منها عندما يتم وضعها فعليًا في الكود. يواجه النموذج مجموعة كبيرة من المشاكل المفتوحة، وسوف يتقلب الناتج بشكل طبيعي وفقًا لذلك.

ولهذا السبب، غالبًا ما تصبح الكلمات السريعة الطويلة أكثر إرهاقًا كلما كتبتها أكثر. بعد أن تستمر الكلمة السريعة في الإطالة، يظل النموذج يحصل على جزء من النص الحر، ولكن النص الحر يكون أطول. يتذكر المزيد من السياق دون الحصول على المزيد من الحدود. إذا لم تكن الحدود مغلقة، فيمكن للنموذج الاستمرار في التخمين فقط.

يقوم DSL بتحويل الحكم الضمني إلى مدخلات صريحة

بعد تغيير الإدخال إلى DSL، يتغير الوضع. لم يعد النموذج يخمن الأعمال بناءً على جمل عارضة، بل يملأ الفراغات بناءً على نموذج دلالي واضح. بالنسبة لسيناريو الاختبار، وعملية الإصدار، والوصف الرسومي، يتم تعريف العقد والعلاقات أولاً بواسطة DSL، ثم يتم استكمال النص والتعليمات البرمجية والمخططات بواسطة النموذج. وستكون النتيجة أشبه بشيء نما من نفس النظام.

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

إن القيمة الكبرى لهذا النوع من التعريف ليست في أنه يبدو جيدًا عند كتابته، ولكن في إمكانية التحكم في إصداره وتغييره ومراجعته. يمكن أن ينمو إنشاء التعليمات البرمجية والتوثيق والاختبار والرسوم البيانية من نفس النموذج الدلالي. النموذج هنا يشبه المحرك أكثر من كونه مخترعًا. وهي مسؤولة عن تطبيق الحدود المقررة وليست مسؤولة عن إعادة كتابتها على الفور.

بمجرد إنشاء هذه الحدود، فإن العديد من الأشياء التي كانت صاخبة لفترة طويلة سوف تصبح هادئة. ما الذي يجب أن يشمله الاختبار، وما إذا كان الفشل متوقعًا، ومن له الكلمة الأخيرة في شروط التراجع؟ لم يعد يتم شرحها على الفور بلغة طبيعية، ولكن مكتوبة في بنية قابلة للتنفيذ. ما ينظر إليه البشر هو الدلالات، وما تنفذه الآلات هو الدلالات، وما نعود إليه عند استكشاف الأخطاء وإصلاحها هو نفس الدلالات.

LLM مناسب للمشاركة في نمو DSL

لا يلزم تنفيذ LLM خارج DSL فقط. الاستخدام الأكثر ملاءمة هو السماح له بالمشاركة في نمو DSL أولاً. أضف بعض السيناريوهات الحقيقية إليه، ودعه يكمل الكلمات الحدودية، وقيم التعداد، والفروع غير الطبيعية، والأمثلة المضادة، ثم اسمح للأشخاص بإيقافه. عندما يتم الانتهاء من خط المشترك الرقمي (DSL)، فإن ما يتم تسليمه لاحقًا إلى النموذج لن يكون لغة طبيعية غير محدودة، بل مدخلات مقيدة.

في هذه المرحلة، يعد LLM مفيدًا جدًا. يمكن أن يساعد في محاذاة البيانات المتفرقة في مجموعة من المصطلحات، ويمكنه أيضًا تحديد المشكلات مثل عدم تناسق الأسماء، وفجوات الحالة، والمسارات غير الطبيعية المفقودة أثناء مرحلة المسودة. بعد استقرار النموذج الدلالي، سيقوم النموذج بإنشاء تطبيقات ورسوم بيانية تخطيطية وعينات اختبار. سيكون الإخراج أشبه بالجري على المسار ولن يتحول إلى أماكن أخرى في كل مرة.

أفضل أن أضع LLM خلف DSL. اجعل الحدود واضحة أولًا، ثم دعهم يساعدون في ملء الحدود لاحقًا، حتى لا يتم تشتيت انتباه النظام بسهولة عن طريق الارتجال مرارًا وتكرارًا.

ستصبح الطبقة الدلالية أيضًا غير عملية

المزيد من DSL ليس دائمًا أفضل. عندما يكون المجال لا يزال يتغير بشكل جذري، فإن التصلب المبكر سوف يؤدي إلى افتراضات خاطئة؛ إذا تم تصميم الطبقة الدلالية بشكل عالمي للغاية، فسوف تصبح إطارًا ثقيلًا آخر. عادة ما يكون السيناريو الفعال من حيث التكلفة هو حدوث نفس النوع من الإجراءات بشكل متكرر، وتكون تكاليف المراجعة مرتفعة، ويجب أن يكون السلوك قابلاً للتتبع. في هذه المرحلة، لم تعد خدمة DSL عبئًا إضافيًا، بل أصبحت عبارة عن مجموعة من الأحكام المتناثرة في مدخل مستقر.

ولذلك، فإن الحكم الأكثر عملية ليس هو “هل يمكن تجهيز LLM بخدمة DSL؟” ولكن “هل من الضروري إصلاح دلالات هذا الأمر أولا؟” بمجرد أن تكون الإجابة بنعم، لا ينبغي أن تتحمل الكلمة الإرشادية المسؤولية الكاملة. الموجه هو المسؤول عن شرح النية، DSL هو المسؤول عن تحمل القيود، والنموذج هو المسؤول عن تحويل القيود إلى نتائج قابلة للتنفيذ. ما هو مكتوب بهذه الطريقة هو أشبه بنظام هندسي وليس سلسلة من الارتجالات.