استخدام الأدوات الوكيلية: بناء سير عمل ذكاء اصطناعي متعدد الخطوات باستخدام واجهات برمجة التطبيقات الخارجية و RAG

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

التطور من روبوتات الدردشة إلى الوكلاء

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

يعتمد هذا الهيكل المعماري على ثلاثة مكونات أساسية:

• التخطيط: تقسيم طلبات المستخدمين المعقدة إلى خطوات قابلة للإدارة.
• استخدام الأدوات: تعريفات الواجهات (المخططات) التي تتيح للنموذج استدعاء الدوال.
• حلقات التغذية الراجعة: استخدام مخرجات أداة واحدة لإعلام الخطوة التالية في السلسلة.

دمج RAG للاستدلال المدعوم بالبيانات

يصبح استخدام الأدوات أكثر قوة بشكل كبير عند دمجه مع التوليد المعزز بالاسترجاع (RAG). بينما يسترجع RAG التقليدي نصوصاً ثابتة من قاعدة بيانات متجهة، يمكن لـ RAG الوكيل استرجاع نقاط بيانات محددة ثم استخدامها للاستعلام عن واجهات برمجة التطبيقات الديناميكية. على سبيل المثال، قد يقوم وكيل الدعم باسترجاع سجل تذاكر العميل (RAG) ثم يستخدم أداة تحديث التذكرة لتغيير الحالة بناءً على السياق المسترجع.

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

تنفيذ تعريفات الأدوات في الكود

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

def get_weather(location: str, unit: str = "fahrenheit") -> dict:
    """
    Fetch current weather for a given location.
    
    Args:
        location (str): The city and state, e.g., 'San Francisco, CA'
        unit (str): The temperature unit, either 'fahrenheit' or 'celsius'
    
    Returns:
        dict: A dictionary containing temperature and conditions
    """
    # Simulated API call
    return {
        "location": location,
        "temperature": 72,
        "unit": unit,
        "description": "Sunny"
    }

# Define the tool structure for the LLM
tool_definition = {
    "name": "get_weather",
    "description": "Get the current weather in a location",
    "parameters": {
        "type": "object",
        "properties": {
            "location": {
                "type": "string",
                "description": "The city and state, e.g. San Francisco, CA"
            },
            "unit": {
                "type": "string",
                "enum": ["celsius", "fahrenheit"],
                "description": "The temperature unit"
            }
        },
        "required": ["location"]
    }
}

إدارة السلاسل متعددة الخطوات

تظهر القوة الحقيقية لسير العمل الوكيلية في السلاسل متعددة الخطوات. فكر في وكيل مساعد للسفر. يسأل المستخدم: "احجز لي رحلة إلى لندن وخصّص ملخصاً للطقس المحلي هناك." يجب على الوكيل أولاً استدعاء واجهة برمجة تطبيقات حجز الرحلات، ثم تحليل تفاصيل التأكيد، وأخيراً استدعاء واجهة برمجة تطبيقات الطقس الخاصة بلندن. ثم يدمج المخرجات كليهما في استجابة متماسكة.

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

الخاتمة

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