لا ترهن معماريتك بمزوّد نموذج واحد
الاعتماد على مزود واحد قلق تسمعه من الإدارة لا من المطورين. والأسئلة معروفة: ماذا لو تغير السعر؟ ماذا لو تغيرت الشروط؟ ماذا لو لزمت استضافة محلية لسبب تنظيمي؟
ما فعلته
شغلت معمارية الوكلاء نفسها على عائلة نماذج ثانية بجانب الأولى. الترقية لم تكن غايتي هنا، أردت أن أعرف كم يصمد التصميم نفسه عند الانتقال.
ماذا كشف الاختبار
تقسيم الوكلاء والحالة والطوابير وطبقة التحقق والبوابة البشرية عملت كلها من أول تشغيل، فهذه الأجزاء لا تعرف عن النموذج شيئا.
بقيت أجزاء احتاجت عملا. صيغة tool calling تختلف من عائلة إلى أخرى. وسلوك النموذج عند الغموض يختلف كذلك. حتى أطوال الـ context جاءت متفاوتة.
الدرس أن كل ما احتاج عملا وقع في طبقة واحدة رقيقة، وهذا تحديدا ما أردت إثباته.
القاعدة العملية
اعزل نداء النموذج خلف واجهة واحدة. لا تنثر استدعاءات المزود في كل ملف. عندما يجتمع النداء في موضع واحد يصبح تغيير المزود تعديلا في مكان واحد، أما التناثر فيحوله إلى بحث في الكود كله.
ما لا أدعيه
التبديل ليس مجانيا. سلوك النماذج يختلف، وهذا يعني إعادة ضبط المخرجات وإعادة تشغيل الاختبارات كاملة. يبقى مع ذلك فرق واسع بين أيام وبين إعادة بناء من الصفر، ومصدره أن التصميم بقي معزولا عن المزود.
لماذا يهم هذا تجاريا
اعرض نظامك على أي منشأة وسيسألك أحدهم: وماذا لو توقف المزود؟ إجابة «سنعيد البناء» تقفل الاجتماع مبكرا. أنا أستطيع القول إن التصميم مستقل وإنه اشتغل فعلا على عائلتين من النماذج، وخلف هذه الإجابة اختبار حقيقي جرى بالفعل.