لقد كنت أبني سير عمل ذكاء اصطناعي في n8n للعمليات الداخلية، وآمل الحصول على ملاحظات من الأشخاص الذين تعاملوا مع مشاكل مشابهة.
يتعامل سير العمل مع طلبات مختلفة حسب السياق. يسحب البيانات، ويوجه المهام، ويحدّث الأنظمة، ويسلم العمل للعملية الصحيحة. كان يعمل بشكل جيد في البداية، لكن مع توسيع سير العمل، بدأ الوكيل يتخذ قرارات سيئة بشأن الأداة أو سير العمل الذي يجب استدعاؤه.
في بعض الأحيان يتخطى الاسترجاع عندما يجب أن يستعلم قاعدة المعرفة. وفي أحيان أخرى يستدعي الفرع الخاطئ أو يجيب من الذاكرة بدلاً من استخدام أحدث البيانات. نما الطلب بمرور الوقت، لذلك أتساءل عما إذا كان ذلك جزءاً من المشكلة أو إذا كانت المعمارية الشاملة بحاجة إلى التغيير.
حالياً نستخدم n8n مع OpenAI وقاعدة بيانات متجهة للاسترجاع وعدد قليل من واجهات برمجة التطبيقات الداخلية. كما كنا نختبر Workbeaver للمهام سطح المكتب التي لا تتعرض عبر واجهات برمجة التطبيقات، مع الحفاظ على n8n كطبقة التنسيق الرئيسية.
بالنسبة لمن يبنون وكلاء ذكاء اصطناعي أكبر في n8n:
هل تحتفظون بمنسق واحد، أم تقسمون المسؤوليات بين وكلاء أصغر؟
كيف تقللون من الهلوسة عند توفر أدوات متعددة؟
هل تعتمدون بشكل أساسي على هندسة الطلب، أم وجدتم أن التغييرات المعمارية أكثر فعالية؟
أي أفضل الممارسات للقرار بشأن متى يجب على الوكيل استرجاع البيانات مقابل الإجابة مباشرة؟
سأكون ممتناً حقاً لسماع ما نجح في مشاريعكم. شكراً مقدماً.
هذا يبدو أقل مشكلة في الـ prompt وأكثر أنك تجاوزت حدود المنسق الواحد. عندما يمتلك عامل واحد كل أداة فهو يختار من قائمة كبيرة في كل دورة، ووصفات الأدوات بالإضافة إلى الـ prompt المتضخم يتنافسان على نفس ميزانية الانتباه، لذا يصبح اختيار الأداة غير واضح تماماً كما تضيف فروعاً جديدة. هذا هو النمط الذي تصفه.
ما أصلحها بالنسبة لي هو تقسيمها. احتفظ بعامل موجّه نحيف وظيفته الوحيدة هي اختيار الممر، ثم قم بنقل المهمة إلى عملاء فرعيين صغار يمتلك كل منهم أداتين أو ثلاثة. مساحة قرار أصغر لكل عامل، prompt أقصر لكل واحد، اختيار أداة أكثر موثوقية بكثير. المنسق الواحد السمين يبدو أنيقاً لكنه يتدهور مع كل أداة تضيفها.
بخصوص تخطي الاسترجاع، توقف عن جعل الاسترجاع أداة يمكن للعامل اختيار تخطيها. على الفروع حيث يجب تأسيس الإجابة على الحقائق، قم بتشغيل الاسترجاع كخطوة ثابتة قبل أن يرى العامل الطلب حتى، بحيث يكون دائماً لديه سياق طازج ولا يستطيع الإجابة من الذاكرة. أبعد هذا القرار عن النموذج حيث تكون الدقة مهمة.
هندسة الـ prompt مقابل الهندسة المعمارية، وبعد حجم معين الهندسة المعمارية هي التي تفوز وليس قريباً. تعديلات الـ prompt لها سقف، التوجيه بالإضافة إلى العملاء الفرعيين ذوي النطاق هو ما يستمر عندما تستمر السطح في النمو.
لقد بنيت حفنة من إعدادات هذه الوكلاء المتعددين في الإنتاج، وأنا سعيد بالخوض بعمق أكثر في بنية التوجيه إذا كان ذلك يساعد.
لقد اصطدمت بالعائق الذي يواجهه تقريباً كل وكيل n8n متنام: منسق واحد مع prompt ضخم وحوالي اثنا عشر أداة. دقة اختيار الأداة في النموذج تنهار بشكل حاد مع زيادة عدد الأدوات وطول الـ prompt، لذا فإن الأعراض التي تراها (استرجاع مفقود، فرع خاطئ، الإجابة من الذاكرة) هي نمط الفشل المتوقع، وليست مشكلة ضبط يمكنك حلها بتحسين الـ prompt.
سأجيب على أسئلتك بالترتيب.
منسق واحد مقابل انقسام. انقسام. حول سير العمل الكبير الواحد أو الاثنين إلى أربعة أو خمسة أصغر، كل منها يتحمل مسؤولية واحدة، واجعل المنسق يستدعيها عبر webhook أو Execute Workflow. الوظيفة الوحيدة للمنسق تصبح التوجيه: صنف الطلب، سلمه إلى سير العمل الفرعي الصحيح، اجمع النتيجة. يجب ألا يسترجع أو يحدث أو يلمس APIs بنفسه. كل وكيل فرعي ثم يرى فقط 3 إلى 5 أدوات ذات صلة بوظيفته بدلاً من القائمة كاملة، والنموذج يختار بشكل صحيح بكثير أكثر عندما تكون القائمة قصيرة. كمكافأة إضافية يمكنك فعلاً تصحيح الأخطاء فيها، لأن الفشل الآن معزول في سير عمل صغير واحد بدلاً من أن يكون مدفوناً في نظام أحادي.
تقليل الهلوسات مع توفر أدوات متعددة. رافعتان. أولاً، قلل مجموعة الأدوات لكل وكيل، كما هو مذكور أعلاه. ثانياً، اسحب القرارات من النموذج أينما كان القرار فعلاً حتمياً. إذا كان يمكن اختيار فرع من حقل معروف باستخدام عقدة Switch، افعل ذلك ولا تجعل LLM يقرر. احتفظ بحكم الوكيل للحالات الغامضة فعلاً. معظم مشاكل “استدعى الفرع الخاطئ” هي فعلاً “طلبت من النموذج اتخاذ قرار كان يمكن لقاعدة أن تتخذه”.
هندسة الـ prompt مقابل العمارة. يحتوي ضبط الـ prompt على حد أقصى وويبدو أنك تواجهه. بعد حجم معين يصبح الـ prompt هو المشكلة وليس الحل، لأنك تدفع نافذة السياق بعيداً بحيث يفقد النموذج التعليمات السابقة. وكيل محكم بـ 3 أدوات مع prompt قصير يتفوق على وكيل بـ 15 أداة مع prompt ضخم في كل مرة. أصلح العمارة أولاً، ثم اضبط الـ prompts داخل القطع الأصغر.
قررت الاسترجاع مقابل الإجابة المباشرة. لا تترك هذا لتقدير النموذج، لأن “أجاب من الذاكرة بدلاً من البيانات الحديثة” يعني أنك أعطيته الخيار لتخطي الاسترجاع. في الفرع الذي يحتاج بيانات جديدة، اجعل الاسترجاع خطوة مطلوبة في التدفق، وليس أداة قد يستدعيها الوكيل أم لا. إذا كان يجب أن يمر عبر قاعدة البيانات المتجهة أو API للوصول إلى الإجابة، فلا يمكنه الاختصار إلى الذاكرة. افرض المسار بدلاً من الأمل في أن يقنعه الـ prompt.
شيء واحد أكثر يستحق الذكر لأنك تشغل هذا في الإنتاج: بمجرد الانقسام إلى أسير عمل فرعية مرتبطة بـ webhook، احذر من الأعطال الصامتة عبرها. يمكن لوكيل فرعي أن يعود أخضر بينما يسقط بهدوء العمل، والمنسق سيستمر بسعادة على بيانات قديمة أو فارغة. يستحق الانتباه لعدد العناصر في كل نقل يد.
أنا سعيد بالذهاب أعمق في نمط التوجيه إذا كان مفيداً.
@James198 نقطة إضافية واحدة لدعم الفصل، الآن يمكنك ضبط كل مهمة (سير عمل فرعي) وأدواتها للنموذج الذي يعمل بشكل أفضل لهذا الجزء من المهمة. Haiku سيء جداً في استدعاء الأدوات، وكذلك GPT 4 mini، بينما Sonnet و GPT 5 يعملان بشكل رائع معها. وفصل أجزاء سير العمل يسمح لك حقاً بضبط دقيق وتحسين مخرجاتك.
مشكلة الفرع الخاطئ مثيرة للاهتمام. عندما يختار الممر الخاطئ، هل عادة ما تكون نفس زوج الفروع الذي يحدث التباس فيه، أم أنه عشوائي تماماً؟ وعندما يجيب من الذاكرة بدلاً من الاستعلام عن مخزن المتجهات، هل هذا يحدث على نوع معين من الطلبات (مثل بحث الحالة مقابل بدء العمليات)؟
لقد كنت أبني طبقات تقييم لهذا النمط بالضبط وسأكون فضولياً بشأن معدل الفشل في يوم نموذجي. يساعد تقسيم الوكيل الفرعي الآخر المذكور، لكن عادة ما تكون هناك قرار تصنيف ثم توجيه لا يزال هشاً حتى بعد التقسيم.
{“output”:“جزء تخطي الاسترجاع / الفرع الخاطئ / الإجابة من الذاكرة هو الجزء المفيد. أأخذ سير عمل إنتاجي واحد لمدة خمسة أيام وأرسل خريطة محررة من فشلين أو ثلاثة فشل تم إعادة إنتاجهما، بالإضافة إلى التغيير الأول والتراجع. مكتوب فقط. أنت تكتب الخطأ وسير العمل، تدفع، وتسقط الآثار المحررة. بدون مكالمات، بدون إعادة كتابة. كم كلفك آخر خطأ؟”}