كثير من عروض وكلاء الذكاء الاصطناعي تفشل لا بسبب النموذج نفسه، بل عند نقطة تلاقي مخرجاته النصية ببرنامجك. هذه المخرجات النصية الحرة تعمل كواجهة برمجة تطبيقات (API) غير موثقة، مما يؤدي إلى سلوك غير متوقع وأخطاء.
هل تعلم أن المخرجات النصية لوكيل الذكاء الاصطناعي الخاص بك تعمل كواجهة برمجة تطبيقات (API) لم تصممها قط؟ هذا يعني أنك قد تواجه أخطاءً غريبة وغير متوقعة في برامجك، وربما دون أن تعرف السبب الحقيقي.
يكشف تقرير جديد أن معظم مشاريع وكلاء الذكاء الاصطناعي تفشل في نقطة حرجة واحدة: وهي عندما تترك مخرجات النموذج النصية البرنامج وتدخل برنامجك الخاص. حتى تلك اللحظة، يكون النص مجرد سلسلة حروف (string)، وسلاسل الحروف هذه لا تحتوي على مخطط (schema) محدد. تخيل أنك تكتب كوداً يعتمد على تحليل النص الحر للذكاء الاصطناعي لاتخاذ قرار، مثل: 'إذا تضمن الرد كلمة «موافقة»، فقم بدمج التغييرات'. هذا يبدو بسيطاً، لكن ماذا لو كتب النموذج: 'لا أوافق على هذا بعد'؟ حينها، قد يطابق برنامجك كلمة «موافقة» ويقوم بدمج تغييرات كان يجب رفضها. هذه مشكلة حقيقية!
في كل مرة تقوم فيها بتحليل معنى من نص يولده الذكاء الاصطناعي، فإنك بذلك تُعلن ضمنياً عن واجهة برمجة تطبيقات (API) دون أن تكتبها فعلياً. ولهذه الواجهة خصائص غير مقصودة تماماً: فهي غير مُحدّثة (غير مرتبطة بإصدار معين)، لذا فإن تغيير بسيط في أمر الإدخال (prompt) يمكن أن يغير الاتفاق بشكل صامت. كما أنها غير مُتحقّق منها (غير validated)، فلا يوجد خطأ واضح عندما يكون الشكل خاطئاً، بل مجرد مسار خاطئ في برنامجك. والأهم من ذلك، لا يمكن تسجيل القرارات بشكل واضح؛ يمكنك تسجيل فقرة كاملة، لكن لا يمكنك تسجيل أن 'النموذج اختار X من مجموعة من الخيارات'.
الحل هنا ليس في تحسين أوامر الإدخال (prompt engineering) وحدها، فهذا يقلل من معدل الفشل ولكنه لا يزيل الحاجة إلى التحليل. بدلاً من ذلك، تحتاج خطوة وكيل الذكاء الاصطناعي عادةً إلى مخرجين مختلفين: وصف للبشر يوضح ما لاحظه النموذج وما شكك فيه، وقرار للبرنامج يكون ذا قيمة يمكن للمضيف التحقق منها والتفرع بناءً عليها. يجب أن يأتي هذا القرار من مجموعة مغلقة من الخيارات التي يفهمها الكود الخاص بك بالفعل.
على سبيل المثال، يمكن أن يكون قرار المراجعة على شكل كائن (object) محدد مثل: { الحالة: 'مقبول' | 'مراجعة' | 'مرفوض'؛ الثقة: 'منخفضة' | 'متوسطة' | 'عالية'؛ النتائج: [مصفوفة من النصوص] }. بهذا الشكل، تصبح حالات الفشل واضحة: إذا عادت 'الحالة' كـ 'ربما جيد'، فهذا انتهاك للعقد (contract violation) ويجب رفضه. إذا كانت 'الحالة' صحيحة ولكن القرار خاطئ، فهذه مشكلة في حكم النموذج. وإذا كانت 'الحالة' صحيحة ولكن البرنامج اتخذ المسار الخاطئ، فهذا خطأ في تنفيذ كودك الخاص. بدون هذا الحدود المكتوبة والمحددة، ستبدو جميع هذه المشاكل وكأن 'الذكاء الاصطناعي فعل شيئاً غريباً'، ولن يكون لديك طريقة لتحديد السبب بدقة.
يكشف تقرير جديد أن معظم مشاريع وكلاء الذكاء الاصطناعي تفشل في نقطة حرجة واحدة: وهي عندما تترك مخرجات النموذج النصية البرنامج وتدخل برنامجك الخاص. حتى تلك اللحظة، يكون النص مجرد سلسلة حروف (string)، وسلاسل الحروف هذه لا تحتوي على مخطط (schema) محدد. تخيل أنك تكتب كوداً يعتمد على تحليل النص الحر للذكاء الاصطناعي لاتخاذ قرار، مثل: 'إذا تضمن الرد كلمة «موافقة»، فقم بدمج التغييرات'. هذا يبدو بسيطاً، لكن ماذا لو كتب النموذج: 'لا أوافق على هذا بعد'؟ حينها، قد يطابق برنامجك كلمة «موافقة» ويقوم بدمج تغييرات كان يجب رفضها. هذه مشكلة حقيقية!
في كل مرة تقوم فيها بتحليل معنى من نص يولده الذكاء الاصطناعي، فإنك بذلك تُعلن ضمنياً عن واجهة برمجة تطبيقات (API) دون أن تكتبها فعلياً. ولهذه الواجهة خصائص غير مقصودة تماماً: فهي غير مُحدّثة (غير مرتبطة بإصدار معين)، لذا فإن تغيير بسيط في أمر الإدخال (prompt) يمكن أن يغير الاتفاق بشكل صامت. كما أنها غير مُتحقّق منها (غير validated)، فلا يوجد خطأ واضح عندما يكون الشكل خاطئاً، بل مجرد مسار خاطئ في برنامجك. والأهم من ذلك، لا يمكن تسجيل القرارات بشكل واضح؛ يمكنك تسجيل فقرة كاملة، لكن لا يمكنك تسجيل أن 'النموذج اختار X من مجموعة من الخيارات'.
الحل هنا ليس في تحسين أوامر الإدخال (prompt engineering) وحدها، فهذا يقلل من معدل الفشل ولكنه لا يزيل الحاجة إلى التحليل. بدلاً من ذلك، تحتاج خطوة وكيل الذكاء الاصطناعي عادةً إلى مخرجين مختلفين: وصف للبشر يوضح ما لاحظه النموذج وما شكك فيه، وقرار للبرنامج يكون ذا قيمة يمكن للمضيف التحقق منها والتفرع بناءً عليها. يجب أن يأتي هذا القرار من مجموعة مغلقة من الخيارات التي يفهمها الكود الخاص بك بالفعل.
على سبيل المثال، يمكن أن يكون قرار المراجعة على شكل كائن (object) محدد مثل: { الحالة: 'مقبول' | 'مراجعة' | 'مرفوض'؛ الثقة: 'منخفضة' | 'متوسطة' | 'عالية'؛ النتائج: [مصفوفة من النصوص] }. بهذا الشكل، تصبح حالات الفشل واضحة: إذا عادت 'الحالة' كـ 'ربما جيد'، فهذا انتهاك للعقد (contract violation) ويجب رفضه. إذا كانت 'الحالة' صحيحة ولكن القرار خاطئ، فهذه مشكلة في حكم النموذج. وإذا كانت 'الحالة' صحيحة ولكن البرنامج اتخذ المسار الخاطئ، فهذا خطأ في تنفيذ كودك الخاص. بدون هذا الحدود المكتوبة والمحددة، ستبدو جميع هذه المشاكل وكأن 'الذكاء الاصطناعي فعل شيئاً غريباً'، ولن يكون لديك طريقة لتحديد السبب بدقة.
