سير العمل الحتمي مقابل سير العمل القائم على الوكيل: دروس من بناء مساعد تسوق

دروس في سير العمل الحتمي، والاستدلال الوكيلي، وإدارة الحالة

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

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

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

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

1. تحديد متى يتم استخدام سير العمل الحتمي مقابل الاستدلال الوكيلي.
2. تطوير إدارة الحالة من نموذج محادثة لمنتج واحد إلى تجربة تسوق متعددة المنتجات.

1. نظرة عامة على بنية النظام

تم بناء مساعد التسوق على أربع طبقات معمارية رئيسية مصممة لتحقيق التوازن بين الأداء والتكلفة والموثوقية.

أ. طبقة البيانات

يحافظ النظام على فصل صارم بين أنظمة التخزين المنظمة وغير المنظمة:

• كتالوج المنتجات: مخزن في PostgreSQL (Cloud SQL)، ويحتوي على بيانات تعريف المنتج، والتسعير، والمتغيرات، ومعلومات الفئة، وبيانات تعريف التنفيذ.
• المراجعات: يتم تخزين مراجعات العملاء في Qdrant. يتيح ذلك استرجاع محتوى المراجعة دلاليًا بدلاً من الاعتماد فقط على مطابقة الكلمات الرئيسية. عندما يطرح المستخدمون أسئلة دلالية مثل "ماذا يقول العملاء عن عمر البطارية؟"، يسترجع النظام المراجعات ذات الصلة ويولد ملخصًا قائمًا على الأدلة.

ب. خط أنابيب استيعاب البيانات

تصل بيانات الكتالوج والمراجعات باستمرار عبر Google Cloud Storage (GCS) وتتم معالجتها عبر مسارات Google Dataflow:

• مسار الكتالوج: GCS → Dataflow → Cloud SQL (تتم معالجته يوميًا).
• مسار المراجعات: GCS → Dataflow → توليد التضمين → Qdrant (تتم معالجته وفق جداول يومية وساعية للحصول على تعليقات العملاء الجديدة).

ج. طبقة النموذج

يتم توجيه جميع تفاعلات النموذج عبر TrueFoundry AI Gateway. يوفر هذا وصولاً مركزيًا للنموذج، وإمكانية المراقبة، والحوكمة، وتتبع التكلفة، وتحديد المعدل، وتجريد النموذج. يستخدم المساعد نماذج Gemini 2.5 Flash و Qwen لتحقيق التوازن بين زمن الاستجابة والجودة والتكلفة التشغيلية.

د. طبقة التنسيق

يتم تنسيق سير العمل الحواري باستخدام LangGraph، مما يتيح انتقالات الحالة الصريحة وإدارة سير العمل مع دعم كل من مسارات التنفيذ الحتمية والاستدلال القائم على الوكيل.

2. التحدي رقم 1: مسارات العمل الحتمية مقابل مسارات العمل القائمة على الوكيل

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

قمنا بتقسيم تفاعلات التسوق إلى نموذجين تنفيذيين متميزين بناءً على مقايضات واضحة في الأداء والقصد:

تحت الغطاء: آليات التنفيذ

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

[ReAct Loop]          
--> (1. Complex Tool-Selection Prompt) 
--> [Tool Call] 
--> (2. Synthesis Prompt) 
[Deterministic Flow]  
--> [Tool Call] 
--> (1. Light Formatting Prompt) 

دورة حياة وكيل ReAct (حلقة من 3 خطوات)

لسير العمل المعقد، يتولى وكيل ReAct مخصص التعامل مع التنفيذ ديناميكيًا من خلال دورة من ثلاث خطوات:

1. الخطوة 1: موجه التخطيط (استدعاء نموذج اللغة الكبير): يمرر النظام استعلام المستخدم جنبًا إلى جنب مع موجهات النظام التي تحتوي على تعريفات جميع الأدوات المتاحة. يجب على نموذج اللغة الكبير (LLM) أن يستدل على ما قاله المستخدم، ويحدد الأداة التي يجب استخدامها، ويستخرج المعلمات الدقيقة المطلوبة لتلك الأداة.
2. الخطوة 2: تنفيذ الأداة: ينفذ النظام الأداة الفعلية أو استدعاء واجهة برمجة التطبيقات باستخدام المعلمات المستخرجة.
3. الخطوة 3: موجه الملاحظة والتوليف (استدعاء نموذج اللغة الكبير): يتم إرجاع استجابة الأداة الخام إلى نموذج اللغة الكبير. يقوم النموذج بتقييم استجابة الأداة مقارنة بسؤال المستخدم الأصلي ويعدلها لتصبح استجابة نظيفة وذات سياق للمستخدم.

دورة الحياة الحتمية (اختصار من خطوتين)

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

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

عقوبة زمن الاستجابة وتعقيد الموجه

بالإضافة إلى عد عدد الاستدعاءات، الـ تعقيد الموجه يحدد بشكل كبير سرعات الاستجابة:

• عبء موجه ReAct: في الخطوة 1 من وكيل ReAct، يكون الموجه معقدًا للغاية. يجب على نموذج اللغة الكبير البحث عبر أدوات متعددة، وتقييم منطق التنفيذ، والحفاظ على السياق. يزيد هذا العبء المعرفي العالي من وقت معالجة الرموز وزمن استجابة التوليد.
• كفاءة الموجه الحتمي: في سير عمل حتمي، يكون الموجه النهائي مباشرًا: "هنا السؤال، وهنا استجابة الأداة الخام. أعطِ الإجابة." نظرًا لأن النموذج لا يحتاج إلى تقييم المسارات أو تتبع الأدوات، فإن توليد الرموز يكون سريعًا وخفيف الوزن.

الدرس الأساسي: فرض حلقة تفكير ReAct على استعلامات البيانات الأساسية يضيف زمن استجابة وتكلفة وتعقيدًا تشغيليًا غير ضروري دون تحسين جودة الإجابة. إذا كان بالإمكان التعامل مع تفاعل ما بشكل حتمي، فيجب أن يتم ذلك. يكون.

وضع ضوابط لعملاء ReAct

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

• مراحل وكيل المخزون: تحديد الموقع ← اختيار المتجر ← التحقق من المخزون ← شرح النتيجة.
• مراحل وكيل الشراء: التحقق من المنتج ← التحقق من المخزون ← اختيار طريقة التنفيذ ← عملية سلة التسوق ← التأكيد.

3. التحدي رقم 2: تطور إدارة الحالة

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

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

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

1. فصل نطاقات الحالة

يؤدي خلط بيانات المستخدم مع بيانات المنتج المؤقتة إلى إنشاء أنظمة هشة. لذلك، تمت إعادة هيكلة الحالة إلى حدود مميزة:

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

2. تتبع السياق الصريح (current_product_id)

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

3. ذاكرة المسار الخاصة بالوكيل

أدى الحفاظ على مصفوفة conversation_history = [] مسطحة ووحيدة إلى إحداث ضوضاء هائلة في الرموز وتدهور أداء النموذج. تتطلب محادثات البحث نوافذ سياق مختلفة تمامًا عن عمليات الدفع النهائية. تم تحديد نطاق الذاكرة مباشرة ضمن مسارات وكيل معزولة (Search, Inventory, Purchase, Product) لتقليل التلوث عبر السياقات.

4. حل مرجع المنتج

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

الخلاصة المعمارية الرئيسية: يجب أن تمثل الحالة سير العمل (البحث، المخزون، الشراء) بدلاً من مجالات البيانات (المراجعات، الكوبونات، المنتجات). إن تصميم الحالة بناءً على نية المستخدم وتقدم سير العمل يبسط التنسيق بشكل كبير ويقلل من تعقيد تتبع الوكلاء المتعددين.