لماذا تغيّر شركات البرمجة نماذج الذكاء الاصطناعي التي تعتمد عليها؟

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

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

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

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

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

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

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

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

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

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

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

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

وتكشف قضية الاختبارات المعيارية عن تحد إضافي، ففي مقال نشرته أوبن إيه آي في فبراير/شباط الماضي، أوضحت الشركة أسباب توقفها عن الاعتماد على اختبار إس دبليو إي بنش فيريفيد (SWE-bench Verified) لقياس قدرات النماذج المتقدمة في هندسة البرمجيات، مشيرة إلى عيوب في بعض حالات الاختبار واحتمال تلوث النتائج بسبب اطلاع النماذج على مسائل الاختبار وحلولها أثناء التدريب.

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

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

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

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

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

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

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