أسئلة مقابلة الذكاء الاصطناعي 2: كيفية ضمان موثوقية استدعاء الأدوات بواسطة نموذج اللغة الكبير (LLM)

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

على سبيل المثال، في حالة الاستعلام عن الطقس، هناك ثلاثة أنواع شائعة من "الاختلاق" في استدعاء الأدوات:
1. عدم استدعاء الأداة، واختلاق الإجابة مباشرة.
2. تمرير معاملات بتنسيق خاطئ عند استدعاء الأداة (مثل تمرير date="بعد غد" بينما الأداة لا تدعم ذلك).
3. تحويل تنسيق المعاملات بشكل غير مصرح به (مثل تحويل "بعد غد" إلى تاريخ محدد)، حتى لو لم تطلب الأداة ذلك.

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

لحل هذه المشكلة، هناك حاجة إلى حل هندسي متعدد المستويات:

1. المستوى الأول: تحسين المطالبات (قيود ناعمة)

   • يعتبر نقطة بداية لإطار القيود، ولكنه ليس النهاية بأي حال.
   • يجب التعامل مع المطالبات على أنها "عقد تشغيل"، توضح بوضوح الغرض من الأداة، ونوع كل معامل، وحدوده، مع أمثلة على القيم غير الصالحة.
   • يجب تضمين أمثلة قليلة (Few-shot)، من خلال عرض أمثلة "إدخال صحيح → استدعاء صحيح"، لتثبيت نمط سلوك النموذج باستخدام التعلم السياقي.

2. المستوى الثاني: إدخال JSON Schema (قيود صلبة)

   • هذه هي الخطوة الحاسمة من "الإقناع" إلى "وضع الحواجز".
   • استبدال وصف المعاملات باللغة الطبيعية بتعريف هيكلي قابل للقراءة آليًا والتحقق منه (JSON Schema). يمكن تعريف نوع الحقل بدقة، وما إذا كان إلزاميًا، ونطاق القيم المحددة، ويمكن منع النموذج من إخراج أي حقول غير معرفة عن طريق تعيين additionalProperties: false.
   • تدعم منصات API الرئيسية فرض هذه القيود الهيكلية على المخرجات أثناء مرحلة فك التشفير، مما يمنع انتهاكات التنسيق من المصدر.

3. المستوى الثالث: إنشاء حلقة تحقق-إصلاح-إعادة محاولة (تنفيذ احتياطي)

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

4. على المستوى المعماري: فصل المسؤوليات

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

قيود الحل الحالي: يمكنه التعامل بشكل جيد مع مشكلة تنسيق المعاملات، لكنه لا يزال غير كافٍ في تغطية التحقق من دلالات المعاملات (مثل تكافؤ "شنغهاي" و"هو"). سيكون هذا تحديًا هندسيًا يجب مواجهته في المستقبل.

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