تعرف على كيفية إنشاء ونشر وكلاء LLM باستخدام الأدوات باستخدام نماذج AWS SageMaker JumpStart Foundation

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

في هذا المنشور، نقدم وكلاء LLM ونوضح كيفية إنشاء ونشر وكيل LLM للتجارة الإلكترونية باستخدام Amazon SageMaker JumpStart وAWS Lambda. سيستخدم الوكيل أدوات لتوفير إمكانات جديدة، مثل الإجابة على الأسئلة المتعلقة بالمرتجعات ("هل عودتي؟ rtn001 تمت معالجتها؟") وتقديم تحديثات حول الطلبات ("هل يمكن أن تخبرني إذا كان الطلب 123456 شحنت؟"). تتطلب هذه القدرات الجديدة من LLMs جلب البيانات من مصادر بيانات متعددة (طلبات, عائدات) وتنفيذ عملية الاسترجاع المعززة (RAG).

لتشغيل وكيل LLM، نستخدم فلان-UL2 نموذج تم نشره كنقطة نهاية SageMaker واستخدام أدوات استرجاع البيانات المصممة باستخدام AWS Lambda. يمكن بعد ذلك دمج الوكيل مع Amazon Lex واستخدامه كروبوت محادثة داخل مواقع الويب أو AWS Connect. نختتم المنشور بالعناصر التي يجب مراعاتها قبل نشر وكلاء LLM في الإنتاج. للحصول على تجربة مُدارة بالكامل لبناء وكلاء LLM، توفر AWS أيضًا الوكلاء لميزة Amazon Bedrock (في المعاينة).

لمحة موجزة عن بنيات وكيل LLM

وكلاء LLM عبارة عن برامج تستخدم LLMs لتحديد متى وكيفية استخدام الأدوات اللازمة لإكمال المهام المعقدة. باستخدام الأدوات وقدرات تخطيط المهام، يمكن لوكلاء LLM التفاعل مع الأنظمة الخارجية والتغلب على القيود التقليدية لـ LLM، مثل انقطاع المعرفة، والهلوسة، والحسابات غير الدقيقة. يمكن أن تتخذ الأدوات مجموعة متنوعة من النماذج، مثل استدعاءات واجهة برمجة التطبيقات (API)، أو وظائف Python، أو المكونات الإضافية المستندة إلى خطاف الويب. على سبيل المثال، يمكن لـ LLM استخدام "مكون إضافي للاسترجاع" لجلب السياق ذي الصلة وتنفيذ RAG.

إذن ماذا يعني أن يختار LLM الأدوات ويخطط للمهام؟ هناك العديد من الأساليب (مثل تتفاعل, مركل, صانع الأدوات, عناقGPT، و وكيل المحولاتق) لاستخدام LLMs مع الأدوات، والتقدم يحدث بسرعة. ولكن إحدى الطرق البسيطة هي مطالبة ماجستير إدارة الأعمال بقائمة من الأدوات ومطالبته بتحديد 1) ما إذا كانت هناك حاجة إلى أداة لتلبية استعلام المستخدم، وإذا كان الأمر كذلك، 2) حدد الأداة المناسبة. تشبه هذه المطالبة عادةً المثال التالي وقد تتضمن أمثلة قليلة لتحسين موثوقية LLM في اختيار الأداة المناسبة.

''' مهمتك هي تحديد أداة للإجابة على سؤال المستخدم. لديك حق الوصول إلى الأدوات التالية. البحث: ابحث عن إجابة في الأسئلة الشائعة الترتيب: ترتيب العناصر noop: ليست هناك حاجة إلى أداة {بعض الأمثلة على اللقطات} السؤال: {input} الأداة: '''

تتضمن الأساليب الأكثر تعقيدًا استخدام LLM متخصصًا يمكنه فك تشفير "استدعاءات واجهة برمجة التطبيقات" (API) أو "استخدام الأدوات" بشكل مباشر، مثل غوريلا LLM. يتم تدريب مثل هذه LLMs المضبوطة على مجموعات بيانات مواصفات واجهة برمجة التطبيقات (API) للتعرف على مكالمات واجهة برمجة التطبيقات (API) والتنبؤ بها بناءً على التعليمات. في كثير من الأحيان، تتطلب شهادات LLM هذه بعض البيانات الوصفية حول الأدوات المتاحة (الأوصاف أو yaml أو مخطط JSON لمعلمات الإدخال الخاصة بها) من أجل إخراج استدعاءات الأداة. يتم اتباع هذا النهج من قبل وكلاء Amazon Bedrock و استدعاءات دالة OpenAI. لاحظ أن LLMs بشكل عام تحتاج إلى أن تكون كبيرة ومعقدة بدرجة كافية لإظهار القدرة على اختيار الأداة.

بافتراض أنه تم اختيار آليات تخطيط المهام واختيار الأدوات، يعمل برنامج وكيل LLM النموذجي بالتسلسل التالي:

1. طلب المستخدم - يأخذ البرنامج مدخلات المستخدم مثل "أين طلبي". 123456؟" من بعض تطبيقات العميل
2. خطط للإجراء (الإجراءات) التالية وحدد الأداة (الأدوات) التي تريد استخدامها – بعد ذلك، يستخدم البرنامج مطالبة لجعل LLM يقوم بإنشاء الإجراء التالي، على سبيل المثال، “ابحث عن جدول الطلبات باستخدام OrdersAPI". يُطلب من LLM اقتراح اسم أداة مثل OrdersAPI من قائمة محددة مسبقًا من الأدوات المتاحة وأوصافها. وبدلاً من ذلك، يمكن توجيه LLM لإنشاء استدعاء API مباشرةً باستخدام معلمات الإدخال مثل واجهة برمجة التطبيقات (12345).
   1. لاحظ أن الإجراء التالي قد يتضمن أو لا يتضمن استخدام أداة أو واجهة برمجة التطبيقات. إذا لم يكن الأمر كذلك، فسوف تستجيب LLM لإدخال المستخدم دون دمج سياق إضافي من الأدوات أو ببساطة إرجاع استجابة جاهزة مثل، "لا أستطيع الإجابة على هذا السؤال".
3. طلب أداة التحليل – بعد ذلك، نحتاج إلى تحليل والتحقق من صحة التنبؤ بالأداة/الإجراء الذي اقترحته LLM. يعد التحقق من الصحة ضروريًا للتأكد من أن أسماء الأدوات وواجهات برمجة التطبيقات ومعلمات الطلب ليست مهلوسة وأن الأدوات يتم استدعاؤها بشكل صحيح وفقًا للمواصفات. قد يتطلب هذا التحليل استدعاء LLM منفصلاً.
4. أداة الاستدعاء - بمجرد التأكد من صحة اسم (أسماء) الأداة والمعلمة (المعلمات)، نقوم باستدعاء الأداة. يمكن أن يكون هذا طلب HTTP أو استدعاء دالة وما إلى ذلك.
5. تحليل الإخراج - قد تحتاج الاستجابة من الأداة إلى معالجة إضافية. على سبيل المثال، قد يؤدي استدعاء واجهة برمجة التطبيقات (API) إلى استجابة JSON طويلة، حيث تكون مجموعة فرعية فقط من الحقول ذات أهمية لـ LLM. إن استخراج المعلومات بتنسيق نظيف وموحد يمكن أن يساعد LLM في تفسير النتيجة بشكل أكثر موثوقية.
6. تفسير الإخراج - بالنظر إلى مخرجات الأداة، تتم مطالبة LLM مرة أخرى بفهمها وتحديد ما إذا كان بإمكانها إنشاء الإجابة النهائية للمستخدم أو ما إذا كانت هناك حاجة إلى إجراءات إضافية.
7. قم بإنهاء أو المتابعة إلى الخطوة 2 – إما إرجاع إجابة نهائية أو إجابة افتراضية في حالة وجود أخطاء أو انتهاء المهلة.

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

حل نظرة عامة

بالنسبة لمنشور المدونة هذا، قمنا بتنفيذ وكيل LLM لدعم التجارة الإلكترونية الذي يوفر وظيفتين مدعومتين بالأدوات:

• أداة استرجاع حالة الإرجاع – الإجابة على الأسئلة المتعلقة بحالة الإرجاع مثل “ماذا يحدث لعودتي؟ rtn001؟"
• أداة استرجاع حالة الطلب - تتبع حالة الطلبات مثل "ما حالة طلبي؟" 123456؟"

يستخدم الوكيل LLM بشكل فعال كموجه استعلام. عند تقديم استفسار ("ما هي حالة الطلب 123456؟")، حدد أداة الاسترداد المناسبة للاستعلام عبر مصادر بيانات متعددة (أي المرتجعات والأوامر). نحن ننجز توجيه الاستعلام من خلال اختيار LLM من بين أدوات الاسترجاع المتعددة، المسؤولة عن التفاعل مع مصدر البيانات وجلب السياق. يؤدي هذا إلى توسيع نمط RAG البسيط، الذي يفترض وجود مصدر بيانات واحد.

كلتا أداتي الاسترجاع عبارة عن وظائف Lambda التي تأخذ معرفًا (رقم التعريف الخاص بالطلب أو معرف الإرجاع) كمدخل، ويجلب كائن JSON من مصدر البيانات، ويحول JSON إلى سلسلة تمثيل سهلة الاستخدام مناسبة للاستخدام بواسطة LLM. يمكن أن يكون مصدر البيانات في سيناريو العالم الحقيقي عبارة عن قاعدة بيانات NoSQL قابلة للتطوير بشكل كبير مثل DynamoDB، ولكن هذا الحل يستخدم لغة Python البسيطة قاموس مع بيانات العينة لأغراض العرض التوضيحي.

يمكن إضافة وظائف إضافية إلى الوكيل عن طريق إضافة أدوات الاسترداد وتعديل المطالبات وفقًا لذلك. يمكن اختبار هذا الوكيل كخدمة مستقلة تتكامل مع أي واجهة مستخدم عبر HTTP، وهو ما يمكن إجراؤه بسهولة باستخدام Amazon Lex.

فيما يلي بعض التفاصيل الإضافية حول المكونات الرئيسية:

1. نقطة النهاية لاستدلال LLM – جوهر برنامج الوكيل هو LLM. سوف نستخدم مركز النموذج الأساسي SageMaker JumpStart لنشر فلان-UL2 نموذج. يسهّل SageMaker JumpStart نشر نقاط نهاية استدلال LLM على مثيلات SageMaker المخصصة.
2. منسق الوكيل – يقوم منسق الوكيل بتنسيق التفاعلات بين LLM والأدوات وتطبيق العميل. بالنسبة للحل الذي نقدمه، نستخدم وظيفة AWS Lambda لتوجيه هذا التدفق واستخدام ما يلي كوظائف مساعدة.
   • مخطط المهام (الأداة) – يستخدم مخطط المهام LLM لاقتراح واحد من 1) الاستعلام عن المرتجعات، 2) الاستعلام عن الطلب، أو 3) عدم وجود أداة. نحن نستخدم الهندسة السريعة فقط و فلان-UL2 النموذج كما هو بدون تعديل.
   • محلل الأدوات – يضمن محلل الأداة أن اقتراح الأداة من مخطط المهام صالح. والجدير بالذكر أننا نضمن أن يكون واحدًا رقم التعريف الخاص بالطلب أو معرف الإرجاع يمكن تحليلها. وإلا فإننا نرد برسالة افتراضية.
   • مرسل الأدوات – يقوم مرسل الأدوات باستدعاء الأدوات (وظائف Lambda) باستخدام المعلمات الصالحة.
   • محلل الإخراج – يقوم محلل الإخراج بتنظيف واستخراج العناصر ذات الصلة من JSON إلى سلسلة يمكن قراءتها بواسطة الإنسان. يتم تنفيذ هذه المهمة بواسطة كل أداة استرجاع وكذلك داخل المنسق.
   • مترجم الإخراج – تتمثل مسؤولية مترجم المخرجات في 1) تفسير المخرجات من استدعاء الأداة و2) تحديد ما إذا كان من الممكن تلبية طلب المستخدم أو ما إذا كانت هناك حاجة إلى خطوات إضافية. إذا كان الأخير، يتم إنشاء الاستجابة النهائية بشكل منفصل وإعادتها إلى المستخدم.

الآن، دعونا نتعمق قليلاً في المكونات الرئيسية: منسق الوكيل، ومخطط المهام، ومرسل الأدوات.

عامل منسق

يوجد أدناه نسخة مختصرة من حلقة الوكيل داخل وظيفة Lambda لمنسق الوكيل. تستخدم الحلقة وظائف مساعدة مثل Task_planner أو tool_parser، لتقسيم المهام. تم تصميم الحلقة هنا لتعمل مرتين على الأكثر لمنع LLM من التعلق في حلقة طويلة دون داع.

#.. imports ..
MAX_LOOP_COUNT = 2 # stop the agent loop after up to 2 iterations
# ... helper function definitions ...
def agent_handler(event):
    user_input = event["query"]
    print(f"user input: {user_input}") 
    
    final_generation = ""
    is_task_complete = False
    loop_count = 0 

    # start of agent loop
    while not is_task_complete and loop_count < MAX_LOOP_COUNT:
        tool_prediction = task_planner(user_input)
        print(f"tool_prediction: {tool_prediction}")  
        
        tool_name, tool_input, tool_output, error_msg = None, None, "", ""

        try:
            tool_name, tool_input = tool_parser(tool_prediction, user_input)
            print(f"tool name: {tool_name}") 
            print(f"tool input: {tool_input}") 
        except Exception as e:
            error_msg = str(e)
            print(f"tool parse error: {error_msg}")  
    
        if tool_name is not None: # if a valid tool is selected and parsed 
            raw_tool_output = tool_dispatch(tool_name, tool_input)
            tool_status, tool_output = output_parser(raw_tool_output)
            print(f"tool status: {tool_status}")  

            if tool_status == 200:
                is_task_complete, final_generation = output_interpreter(user_input, tool_output) 
            else:
                final_generation = tool_output
        else: # if no valid tool was selected and parsed, either return the default msg or error msg
            final_generation = DEFAULT_RESPONSES.NO_TOOL_FEEDBACK if error_msg == "" else error_msg
    
        loop_count += 1

    return {
        'statusCode': 200,
        'body': final_generation
    }

مخطط المهام (التنبؤ بالأداة)

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

tool_selection_prompt_template = """ مهمتك هي تحديد الأدوات المناسبة لتلبية مدخلات المستخدم. إذا لم تكن هناك حاجة إلى أداة، فاختر "no_tool" الأدوات المتاحة هي: return_inquiry: قاعدة بيانات معلومات حول حالة إرجاع معينة، سواء كانت معلقة أو تمت معالجتها أو إلخ. order_inquiry: معلومات حول حالة طلب معين، مثل حالة الشحن والمنتج والمبلغ وما إلى ذلك. no_tool: ليست هناك حاجة إلى أداة للرد على إدخال المستخدم. يمكنك اقتراح أدوات متعددة، مفصولة بفاصلة. أمثلة: المستخدم: " ما هي ساعات عملك؟" الأداة: no_tool المستخدم: "هل تم شحن الطلب 12345؟" الأداة: مستخدم order_inquiry: "هل تمت معالجة ret812 المرتجعة؟" الأداة: return_inquiry المستخدم: "كم عدد الأيام المتبقية لدي حتى إرجاع الطلبات؟" الأداة: return_inquiry user: "ما هو إجمالي الطلب للطلب 38745؟" الأداة: order_inquiry المستخدم: "هل يمكنني إرجاع طلبي 38756 بناءً على سياسة المتجر؟" الأداة: order_inquiry المستخدم: "مرحبًا" الأداة: no_tool المستخدم: "هل أنت AI ؟" الأداة: مستخدم no_tool: "كيف حال الطقس؟" الأداة: مستخدم no_tool: "ما هي حالة استرداد الطلب 12347؟" الأداة: مستخدم order_inquiry: "ما هي حالة استرداد الإرجاع ret172؟" الأداة: إدخال المستخدم return_inquiry : {} الأداة: """

مرسل الأدوات

تعمل آلية إرسال الأداة عبر إذا كان غير ذلك منطق لاستدعاء وظائف Lambda المناسبة اعتمادًا على اسم الأداة. ما يلي هو tool_dispatch تنفيذ الوظيفة المساعدة. يتم استخدامه داخل عامل Loop وإرجاع الاستجابة الأولية من وظيفة Lambda للأداة، والتي يتم تنظيفها بعد ذلك بواسطة input_parser وظيفة.

def tool_dispatch(tool_name, tool_input):
    #...
     
    tool_response = None 

    if tool_name == "returns_inquiry":
        tool_response = lambda_client.invoke(
            FunctionName=RETURNS_DB_TOOL_LAMBDA,
            InvocationType="RequestResponse",
            Payload=json.dumps({
              "returnId": tool_input  
            })
        )
    elif tool_name == "order_inquiry":
        tool_response = lambda_client.invoke(
            FunctionName=ORDERS_DB_TOOL_LAMBDA,
            InvocationType="RequestResponse",
            Payload=json.dumps({
                "orderId": tool_input
            })
        )
    else:
        raise ValueError("Invalid tool invocation")
        
    return tool_response

نشر الحل

شروط هامة – لبدء عملية النشر، يجب عليك استيفاء المتطلبات الأساسية التالية:

• الوصول إلى وحدة الإدارة في AWS عبر مستخدم يمكنه تشغيل مجموعات AWS CloudFormation
• الإلمام بالتنقل أوس لامدا و أمازون ليكس لوحات المفاتيح
• فلان-UL2 يتطلب واحدة ml.g5.12xlarge للنشر، الأمر الذي قد يتطلب زيادة حدود الموارد عبر تذكرة الدعم. في مثالنا نستخدم لنا-الشرق-1 حسب المنطقة، لذا يرجى التأكد من زيادة حصة الخدمة (إذا لزم الأمر) فيها لنا-الشرق-1.

النشر باستخدام CloudFormation – يمكنك نشر الحل ل لنا-الشرق-1 من خلال النقر على الزر أدناه:

سيستغرق نشر الحل حوالي 20 دقيقة وسيؤدي إلى إنشاء ملف LLMAgentStack كومة، والتي:

• ينشر نقطة نهاية SageMaker باستخدام فلان-UL2 نموذج من SageMaker JumpStart؛
• تنشر ثلاث وظائف Lambda: LLMAgentOrchestrator, LLMAgentReturnsTool, LLMAgentOrdersTool; و
• ينشر أوس ليكس الروبوت الذي يمكن استخدامه لاختبار الوكيل: Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot.

اختبر الحل

تنشر المكدس روبوت Amazon Lex بالاسم Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot. يمكن استخدام الروبوت لاختبار الوكيل من البداية إلى النهاية. فيما يلي دليل شامل إضافي لاختبار روبوتات AWS Amazon Lex مع تكامل Lambda وكيفية عمل التكامل على مستوى عالٍ. ولكن باختصار، يعد روبوت Amazon Lex موردًا يوفر واجهة مستخدم سريعة للدردشة مع وكيل LLM الذي يعمل داخل وظيفة Lambda التي أنشأناها (LLMAgentOrchestrator).

حالات اختبار العينة التي يجب مراعاتها هي كما يلي:

• الاستعلام عن أمر صالح (على سبيل المثال، "ما هو العنصر الذي تم طلبه؟" 123456؟")
  • الطلب "123456" هو طلب صالح، لذا يجب أن نتوقع إجابة معقولة (على سبيل المثال، "صابون الأيدي العشبي")
• استعلام إرجاع صالح للعودة (على سبيل المثال، "متى عودتي rtn003 تمت معالجتها؟")
  • يجب أن نتوقع إجابة معقولة حول حالة الإرجاع.
• لا علاقة لها بكل من المرتجعات أو الطلبات (على سبيل المثال، "كيف هو الطقس في اسكتلندا الآن؟")
  • سؤال لا علاقة له بالمرتجعات أو الطلبات، وبالتالي يجب إرجاع الإجابة الافتراضية ("عذرًا، لا أستطيع الإجابة على هذا السؤال.")
• الاستعلام عن أمر غير صالح (على سبيل المثال، "ما هو العنصر الذي تم طلبه؟" 383833؟")
  • المعرف 383832 غير موجود في مجموعة بيانات الطلبات وبالتالي يجب أن نفشل بأمان (على سبيل المثال، "لم يتم العثور على الطلب. يرجى التحقق من معرف الطلب الخاص بك.")
• استعلام إرجاع غير صالح (على سبيل المثال، "متى عودتي؟ rtn123 تمت معالجتها؟")
  • وبالمثل، معرف rtn123 غير موجود في مجموعة بيانات المرتجعات، وبالتالي يجب أن يفشل بأمان.
• استفسار عن الإرجاع غير ذي صلة (على سبيل المثال، "ما هو تأثير العودة rtn001 على السلام العالمي؟")
  • هذا السؤال، رغم أنه يبدو متعلقًا بأمر صحيح، إلا أنه غير ذي صلة. يتم استخدام LLM لتصفية الأسئلة ذات السياق غير ذي الصلة.

لإجراء هذه الاختبارات بنفسك، إليك التعليمات.

1. على وحدة تحكم Amazon Lex (وحدة تحكم AWS > أمازون ليكس)، انتقل إلى الروبوت بعنوان Sagemaker-Jumpstart-Flan-LLM-Agent-Fallback-Bot. لقد تم بالفعل تكوين هذا الروبوت للاتصال بـ LLMAgentOrchestrator وظيفة لامدا كلما FallbackIntent يتم تشغيل.
2. في جزء التنقل، اختر النوايا.
   
3. يختار يبني في الزاوية اليمنى العليا
   
4. 4. انتظر حتى تكتمل عملية الإنشاء. عند الانتهاء، تحصل على رسالة النجاح، كما هو موضح في لقطة الشاشة التالية.
   
5. اختبر البوت عن طريق إدخال حالات الاختبار.
   

تنظيف

لتجنب الرسوم الإضافية، احذف الموارد التي أنشأها الحل الخاص بنا باتباع الخطوات التالية:

• على ال AWS كلاودفورميشن وحدة التحكم، حدد المكدس المسمى LLMAgentStack (أو الاسم المخصص الذي اخترته).
• يختار يمسح
• تأكد من حذف المكدس من وحدة تحكم CloudFormation.

مهم: تحقق جيدًا من حذف المكدس بنجاح من خلال التأكد من أن ملف فلان-UL2 تتم إزالة نقطة نهاية الاستدلال.

• للتحقق، انتقل إلى وحدة تحكم AWS > Sagemaker > نقاط النهاية > الاستدلال صفحة.
• يجب أن تسرد الصفحة جميع نقاط النهاية النشطة.
• تأكد sm-jumpstart-flan-bot-endpoint غير موجود مثل لقطة الشاشة أدناه.

اعتبارات الإنتاج

يتطلب نشر وكلاء LLM في الإنتاج اتخاذ خطوات إضافية لضمان الموثوقية والأداء وقابلية الصيانة. فيما يلي بعض الاعتبارات قبل نشر الوكلاء في الإنتاج:

• تحديد نموذج LLM لتشغيل حلقة الوكيل: للحل الذي تمت مناقشته في هذا المنشور، استخدمنا فلان-UL2 نموذج بدون ضبط دقيق لتنفيذ تخطيط المهام أو اختيار الأداة. من الناحية العملية، يمكن أن يؤدي استخدام LLM الذي تم ضبطه بشكل دقيق لأداة الإخراج أو طلبات واجهة برمجة التطبيقات (API) مباشرة إلى زيادة الموثوقية والأداء، بالإضافة إلى تبسيط عملية التطوير. يمكننا ضبط LLM في مهام اختيار الأداة أو استخدام نموذج يقوم مباشرة بفك تشفير الرموز المميزة للأداة مثل Toolformer.
  • يمكن أن يؤدي استخدام النماذج المحسّنة أيضًا إلى تبسيط إضافة الأدوات وإزالتها وتحديثها المتاحة للوكيل. باستخدام الأساليب المستندة إلى الموجهات فقط، يتطلب تحديث الأدوات تعديل كل مطالبة داخل منسق الوكيل، مثل تلك الخاصة بتخطيط المهام، وتحليل الأدوات، وإرسال الأداة. يمكن أن يكون هذا مرهقًا، وقد يتدهور الأداء إذا تم توفير عدد كبير جدًا من الأدوات في سياق LLM.
• الموثوقية والأداء: يمكن أن يكون وكلاء LLM غير موثوقين، خاصة بالنسبة للمهام المعقدة التي لا يمكن إكمالها خلال بضع حلقات. إن إضافة عمليات التحقق من صحة المخرجات، وإعادة المحاولة، وتنظيم المخرجات من LLMs إلى JSON أو yaml، وفرض المهلات لتوفير فتحات هروب لـ LLMs العالقة في الحلقات يمكن أن يؤدي إلى تعزيز الموثوقية.

خاتمة

في هذا المنشور، اكتشفنا كيفية إنشاء وكيل LLM يمكنه استخدام أدوات متعددة من الألف إلى الياء، باستخدام الهندسة السريعة ذات المستوى المنخفض، ووظائف AWS Lambda، وSageMaker JumpStart كعناصر أساسية. ناقشنا بنية وكلاء LLM وحلقة الوكيل بالتفصيل. قد تكون المفاهيم وبنية الحلول المقدمة في منشور المدونة هذا مناسبة للوكلاء الذين يستخدمون عددًا صغيرًا من مجموعة الأدوات المحددة مسبقًا. ناقشنا أيضًا العديد من الاستراتيجيات لاستخدام الوكلاء في الإنتاج. يوفر Agents for Bedrock، الذي هو قيد المعاينة، أيضًا تجربة مُدارة لبناء الوكلاء مع دعم أصلي لاستدعاءات الأدوات الوكيلة.

عن المؤلف

جون هوانج هو مهندس الذكاء الاصطناعي التوليدي في AWS مع التركيز بشكل خاص على تطبيقات نماذج اللغة الكبيرة (LLM)، وقواعد بيانات المتجهات، واستراتيجية منتجات الذكاء الاصطناعي التوليدية. إنه متحمس لمساعدة الشركات في تطوير منتجات AI/ML ومستقبل وكلاء LLM والطيارين المساعدين. قبل انضمامه إلى AWS، كان يشغل منصب مدير المنتج في Alexa، حيث ساعد في جلب الذكاء الاصطناعي للمحادثة إلى الأجهزة المحمولة، بالإضافة إلى تاجر مشتقات في Morgan Stanley. وهو حاصل على درجة البكالوريوس في علوم الكمبيوتر من جامعة ستانفورد.