هندسة AI
الهندسة المقترنة بـ AI، الجزء الأول: آليّة العمل
افتتاح السلسلة. وين بساعد النموذج، وين بكذب، وكيف بنينا إيقاع يومي حول الاثنين.
جزء منai-pairedجاري تحميل المقال…
افتتاح السلسلة. وين بساعد النموذج، وين بكذب، وكيف بنينا إيقاع يومي حول الاثنين.
جزء منai-pairedجاري تحميل المقال…
سنة من البرمجة الزوجيّة مع نموذج لغوي في الإنتاج علّمتنا شيئاً لم تفعله العروض أبداً: النموذج ممتاز في جزء من العمل، متوسّط في آخر، وخطر في ثالث. الحيلة هي سير العمل الذي يضع كلّاً في موضعه الصحيح. هذا هو الجزء الأوّل من ثلاثة عن الهندسة المقترنة بالـ AI بعد انتهاء العرض.
تخلّص من التسويق. يوماً بيوم، النموذج يفعل ثلاثة أشياء على فريقنا:
سيّئ في ثلاثة أشياء:
استقررنا على نمط من أربع خطوات، بهذا الترتيب:
١. spec → ٢. تمريرة أولى → ٣. تحرير + اختبار → ٤. مراجعة
أنت النموذج أنت (في الغالب) النموذج
لاحظ الأطراف. دور النموذج في المنتصف. الإنسان يحدّد المشكلة ويتحقّق من النتيجة. أيّ شيء آخر وتدفع لإجابة خاطئة واثقة.
الـ spec وثيقة مهيكلة. نستخدم قالباً من أربعة أقسام:
## الهدف
جملة واحدة.
## المدخلات
أنواع، قيود، حالات حدّيّة تستحقّ التسمية.
## المخرجات
أنواع، ماذا يعني «النجاح»، ماذا يعيد «الفشل».
## أمثلة
ثلاثة: مسار سعيد، حالة حدّيّة، حالة فشل.هذا ليس اختياريّاً. الـ spec هو ما يصنع الفرق بين «النموذج أنتج شيئاً مفيداً» و «النموذج أنتج هراء يبدو معقولاً». معظم المهندسين الذين يقولون «النموذج لا يكتب كوداً جيّداً» تخطّوا الخطوة ١.
النموذج يأخذ الـ spec وينتج مسوّدة أولى. لا نحرّر في منتصف التيّار. لا نطرح أسئلة متابعة. ندعه ينهي، ثمّ نقرأه كاقتراح كامل.
القاعدة التي استقررنا عليها: إن كانت التمريرة الأولى أكثر من ٣٠٪ خاطئة، لا نُكرّر مع النموذج عليها. نُعيد كتابة الـ spec ليكون أحكم ونحاول مرّة أخرى. التكرار مع النموذج على تمريرة أولى سيّئة يميل لإنتاج ثلاث تمريرات سيّئة أخرى تبتعد تدريجيّاً عمّا نريد.
نحرّر التمريرة الأولى يدويّاً. نكتب الاختبارات يدويّاً. النموذج يساعد في أسماء الاختبارات لكن ليس في التأكيدات. السبب: اختبارات النموذج لها ميل لتأكيد ما يفعله الكود بدلاً من ما قاله الـ spec.
بعد الانتهاء، نُلصق الـ diff عائداً في النموذج بسياق جديد ونسأل «أيّ حالات حدّيّة فاتتنا؟». معدّل الإصابة هنا حوالي ١ من ٥: معظم ما يقترحه مغطّى أصلاً أو خارج النطاق، لكنّ الواحد الذي يصل أحياناً bug حقيقيّ.
ثلاثة أرقام، شهريّاً:
الرقم الأخير هو الذي علّمنا أكثر. النموذج لا يزيل الـ bugs من النظام. ينقلها صعوداً إلى الـ spec. هذا جيّد إن عاملت الـ spec كقطعة الأثر، لا الكود.
ثلاثة أنماط تخلّينا عنها:
ترك النموذج يكتب الكود، يشغّل الاختبارات، يصلح الإخفاقات، يشغّل الاختبارات مجدّداً، في حلقة بلا إشراف. هذا يعمل للحالات التافهة ويفشل بصمت على أيّ شيء مهمّ. وضع الفشل هو أنّ النموذج «يصلح» الاختبارات بإضعافها. لم نجد حاجزاً يلتقط هذا بشكل موثوق.
ذهاب وإياب طويل مع النموذج على نفس قطعة الكود، أكثر من ١٠ دورات. هذا ينتج كوداً غريباً بنيويّاً لأنّ النموذج يأخذ متوسّط اقتراحاته السابقة. أفضل: اكتب spec جديد، تمريرة أولى جديدة.
النموذج يجيب بنعم. هو متحدّث واثق. الأسوأ، أحياناً يهلوس مشاكل غير موجودة. استبدل السؤال المفتوح بسؤال مهيكل: «اسرد الحالات الحدّيّة في هذا الكود غير المغطّاة بالاختبارات أدناه». السؤال المهيكل يحصل على إخراج مفيد؛ المفتوح لا.
الجزء الثاني من هذه السلسلة عن التطوير المدفوع بالـ spec تحديداً: بنية spec يستطيع النموذج العمل عليها بدون إعادة عمل، أنماط مضادّة، و diff فعليّ من ميزة شحنّاها بهذه الطريقة.
صفحة السلسلة تتابع البقيّة.