أدى ظهور النماذج اللغوية الكبيرة إلى موجة من الإثارة حول وكلاء الذكاء الاصطناعي العموميين - وهي روبوتات يمكنها التعامل مع أي شيء بدءاً من كتابة التعليمات البرمجية إلى إدارة التقويمات. ولكن في بيئات المؤسسات الحقيقية، غالبًا ما يصطدم هؤلاء الوكلاء بحائط.
إنها مواد تجريبية رائعة ولكنها ليست جاهزة للإنتاج.
ما تحتاجه الشركات هو وكلاء الذكاء الاصطناعي المصممة خصيصًا لهذا الغرض - روبوتات الدردشة للأعمال التي تتكامل بعمق مع أنظمتها ومصممة لحل مشاكل أعمال محددة. وهنا يأتي دور وكلاء الذكاء الاصطناعي العموديين الذين يتفوقون على الروبوتات المساعدة العامة في تدفقات العمل الحرجة.
فما هي عوامل الذكاء الاصطناعي الرأسية بالضبط، ولماذا هي الأنسب للمؤسسات؟ دعونا نحاول الإحاطة بها.
ما هي عوامل الذكاء الاصطناعي الرأسية؟
وكلاء الذكاء الاصطناعي العمودي هي أنظمة خاصة بمجال محدد مصممة لأداء مهام محددة بوضوح ضمن وظيفة عمل معينة. وعلى عكس الوكلاء العموميين الذين يهدفون إلى القيام بكل شيء بنموذج واحد، فإن الوكلاء العموديين يتعمقون في العمق وليس على نطاق واسع - فهم مصممون للعمل ضمن سياق معروف، مع إمكانية الوصول إلى البيانات والقواعد والأنظمة المنظمة التي تهم المهمة.
من الناحية العملية، لا يكتفي هؤلاء الوكلاء بـ "التحدث" بشكل جيد - بل يتصرفون بشكل هادف. قد يقوم الوكيل الرأسي في مجال الخدمات اللوجستية بتحسين طرق التسليم بناءً على توافر الأسطول وحركة المرور في الوقت الفعلي. أما في مجال الرعاية الصحية، فقد يتحقق من التأمين، ويحدد مواعيد المتابعة، ويتعامل مع الاستقبال - وكل ذلك يستند إلى منطق صارم.
تشهد الفرق التي تستخدم الوكلاء الرأسيين اعتماداً أسرع، ومعدلات نجاح أفضل للمهام، وأخطاء أقل. ما السر؟ لا يعتمد هؤلاء الوكلاء على مطالبات عامة. فهي ترتكز على واجهات برمجة التطبيقات، والقواعد، والبيانات المهيكلة، وهي مصممة للقيام بمهمة واحدة بشكل جيد.
كيفية عمل وكلاء الذكاء الاصطناعي الرأسي
يتم تدريب وكلاء الذكاء الاصطناعي العموميين على مجموعات بيانات عامة ضخمة، مما يجعلهم رائعين في توليد النصوص - ولكن لا يمكن الاعتماد عليهم في بيئات العمل المنظمة. فهم يهلوسون ويكافحون مع مكالمات واجهة برمجة التطبيقات، ولا يمكنهم اتباع تدفقات العمل الصارمة. تم تصميم الوكلاء العموديين لحل هذه القيود من خلال الهيكل والمنطق والتكامل.
فيما يلي كيفية هندسة الوكلاء الرأسيين عملياً - وكيف تحل كل طبقة قيداً أساسياً من القيود الأساسية في LLMs ذات الأغراض العامة:
الوصول المباشر إلى واجهة برمجة التطبيقات (API)
لا يمكن للنماذج العامة التفاعل مع الأنظمة الداخلية ما لم يتم تغليفها بأدوات معقدة. يتصل الوكلاء العموديون مباشرةً بأنظمة إدارة علاقات العملاء أو تخطيط موارد المؤسسات أو منصات الجدولة، مما يسمح لهم بجلب البيانات في الوقت الفعلي وإنشاء السجلات وتشغيل تدفقات العمل بشكل موثوق.
منطق العمل المدمج
وبدلاً من الاعتماد على الحيل السريعة، يعمل الوكلاء الرأسيون ضمن قواعد وتدفقات محددة جيداً. فهم يعرفون ما هو صالح، والخطوات التي يجب اتباعها، وكيفية التصرف بما يتماشى مع سياسة الشركة - تمامًا مثل أي نظام خلفي آخر.
معالجة البيانات المهيكلة
لا تعمل LLMs العموديون المدربون على اللغة الطبيعية بشكل جيد مع JSON أو SQL أو المخططات الجامدة. تعمل الوكلاء العموديون على سد هذه الفجوة من خلال الترجمة بين مدخلات المستخدم الحرة والتنسيقات الخلفية المهيكلة، مما يضمن عمل المخرجات.
تضييق السياق إلى ما يهم
لا يعرف النموذج العامي سياسة الاسترداد الخاصة بك أكثر أهمية من Wikipedia. يرتكز الوكلاء العموديون على المعرفة الخاصة بالمجال مثل إجراءات التشغيل الموحدة أو مستندات السياسة أو قواعد المعرفة - لذا فهم يعملون فقط ضمن ما هو وثيق الصلة.
LLM هو مكون واحد فقط
في الوكيل العمودي، يلعب العامل LLM دورًا مساندًا - يُستخدم للتلخيص أو التفسير أو الاستجابة بشكل طبيعي. لكنها مغلفة داخل نظام يحكمه المنطق والذاكرة والتحكم في الوصول، مما يجعلها آمنة للإنتاج.
تمنح هذه الطبقات معًا الوكلاء الرأسيين الهيكلية التي تفتقر إليها النماذج العامة. فهم لا يعتمدون على الحث الذكي أو الأمل - فهم يعملون مع إمكانية الوصول والمساءلة والمواءمة مع احتياجات العمل الحقيقية.
لماذا يُعد وكلاء الذكاء الاصطناعي الرأسي أفضل لسير العمل التجاري
معظم عمليات سير العمل في المؤسسة ليست مفتوحة - فهي تتبع قواعد، وتتطلب عمليات تحقق من الصحة، وتعتمد على بيانات في الوقت الفعلي من الأنظمة الداخلية. يعاني الوكلاء العامون هنا. إنهم يولدون الإجابات، لكنهم لا يستطيعون اتباع عملية موثوقة أو احترام القيود دون تخصيص كبير.
يتم بناء وكلاء الذكاء الاصطناعي العمودي بهيكلية منذ البداية. فهي محددة النطاق لحالة استخدام واحدة، ومتكاملة مع الأنظمة التي تشغلها، ومدركة للمنطق الذي يحكمها. وهذا يجعلها أسرع في النشر، وأسهل في الاختبار، وأكثر موثوقية في الإنتاج.
كما أنها تخلق فوضى أقل. فبدلاً من الإفراط في طرح نموذج عام على أمل أن يفهم السياق، فإن الوكلاء الرأسيين يستندون إلى واجهات برمجة التطبيقات وقواعد العمل والتدفقات المحددة مسبقًا. وهذا يجعل من السهل الوثوق بها وتوسيع نطاقها وصيانتها.
أهم حالات استخدام وكلاء الذكاء الاصطناعي الرأسي
بدأ الوكلاء الرأسيون يظهرون بالفعل في الإنتاج - ليس كمساعدين مستقبليين، ولكن كأنظمة مركزة تحل مشاكل تشغيلية حقيقية. هذه ليست "مساعدين مساعدين للذكاء الاصطناعي" يحاولون القيام بكل شيء. إنهم وكلاء خاصون بمجال محدد يقومون بعمل واحد بشكل جيد.
دعنا نلقي نظرة على بعض حالات الاستخدام التي يمكن اعتمادها على الفور.
الوكلاء الذين يتعاملون مع العملاء مع ملكية سير العمل
أحد أكبر المفاهيم الخاطئة في تصميم chatbot لية هو الاعتقاد بأن المحادثة تساوي القيمة. فمعظم التدفقات التي تواجه العميل - الإعداد والحجز والتطبيقات - ليست "محادثات". إنها مهام منظمة ذات منطق وتحقق وتبعيات خلفية.
ومع ذلك، غالباً ما تقوم الشركات بنشر روبوتات الدردشة الآلية العامة هنا وتأمل في الأفضل. والنتيجة؟ مستخدمون مرتبكون، وتدفقات معطلة، وعملاء محتملون فاشلون.
من ناحية أخرى، صُمم الوكلاء الرأسيون المصممون خصيصاً لخدمة العملاء، لإكمال الرحلة الكاملة. فهم يعرفون الخطوات، ويتبعون القواعد، ويتكاملون مباشرةً مع الأنظمة الداخلية. تبدو التجربة أكثر سلاسة ليس لأن الوكيل "أكثر ذكاءً" ولكن لأنه مصمم لهذه المهمة.
وكلاء العمليات الداخلية لأتمتة المهام
هناك قدر كبير من العمل الداخلي القابل للتكرار ولكنه لا يزال مؤلماً: تحديث السجلات، وتعيين التذاكر، ومزامنة البيانات بين الأدوات. يمكنك أتمتة ذلك باستخدام الأتمتة الآلية، ولكن غالباً ما تتعطل الأتمتة الآلية في اللحظة التي يتغير فيها شيء ما.
يملأ الوكلاء العموديون هذه الفجوة بشكل جميل بفضل براعتهم كطبقة منطقية في أتمتة سير العمل وفهم الفروق الدقيقة. فهي ذكية بما فيه الكفاية للتعامل مع المدخلات الديناميكية ولكنها منظمة بما يكفي للبقاء ضمن حدود الحماية. والأهم من ذلك أنها متصلة بواجهات برمجة التطبيقات والمنطق الذي يحدد سير عملك الداخلي.
وكلاء المبيعات ووكلاء إدارة علاقات العملاء المتكاملين
المبيعات سريعة الحركة وحساسة للتفاصيل. قد يستجيب وكيل GPT العام بأدب، لكنه لن يعرف معايير التأهيل الخاصة بك، أو أي مندوب يمتلك أي منطقة، أو ما إذا كان العميل المحتمل موجود بالفعل في CRM.
مع وجود منصات مثل HubSpot التي توفر لوكيلك كل هذه المعلومات القيمة، فأنت بحاجة إلى وكيل يحقق أقصى استفادة منها.
تختلف روبوتات الدردشة الآلية للمبيعات المصممة بشكل عمودي صحيح. فهي تعيش داخل منطق خط أنابيبك. ويمكنها تأهيل العملاء المحتملين في الوقت الفعلي، وتسجيل الملاحظات، وتحفيز عمليات المتابعة، وحتى جدولة عمليات التسليم - دون أن يقوم شخص ما بدفعهم يدوياً.
عوامل التنسيق عبر الأنظمة
بعض المهام لا يمكن القيام بها في نظام واحد. فكّر في إنشاء تقرير ربع سنوي، أو إرسال حملة متابعة، أو تسوية المخزون عبر المواقع. هذه ليست مهام "محادثة" - إنها مهام سير عمل صغيرة تمتد عبر الأنظمة والمنطق.
محاولة الحصول على وكيل عام للقيام بذلك مع المطالبات هو كابوس. فالنموذج ينسى السياق، وتفشل مكالمات واجهة برمجة التطبيقات، وينهار المنطق.
يزدهر الوكلاء العموديون في هذا المجال. فهم ينظمون الأدوات، ويحترمون منطق العمليات، ويكملون المهمة من البداية إلى النهاية - دون الحاجة إلى مجالسة بشرية. توقف عن التفكير في الأمر على أنه ذكاء اصطناعي، وابدأ في التفكير فيه على أنه بنية تحتية.
هذه ليست سيناريوهات افتراضية. فالفرق تعمل بالفعل على نشر الوكلاء العموديين في الإنتاج - حيث تستبدل بهدوء الأتمتة الهشة والطيارين المساعدين المبالغ فيها بأنظمة تنجز العمل بالفعل. لا يكمن المفتاح في الذكاء فقط، بل في الهيكلية والتركيز والتكامل.
إذاً كيف يمكنك الانتقال من المفهوم إلى وكيل عمودي عامل؟ دعنا نحلل الأمر.
كيفية بناء أول وكيل ذكاء اصطناعي عمودي
هناك الكثير من الطرق لبناء وكيل ذكاء اصطناعي اليوم - مكدسات مفتوحة المصدر، وأطر عمل للتنسيق، ومنصات ذات كود كامل، ومنصات بناء بدون كود. يتيح لك بعضها تجميع عدة وكلاء معًا. والبعض الآخر يتيح لك ضبط السلوك من الصفر.
.webp)
في هذا المثال، سنبقي الأمر في هذا المثال عمليًا وعمليًا. سنستخدم Botpress كطبقة تنسيق، وسنربطه بنموذج لغوي أولي مثل GPT أو Claude أو Gemini - ثم سنعرض كيفية تحويل هذا LLM اللغوي العام إلى وكيل عمودي محدد النطاق ومتكامل وجاهز للمهام الحقيقية.
إذا كنت قد تعاملت بالفعل مع أدوات مثل CrewAI أو LangGraph أو AutoGen، فسيبدو النهج مألوفًا - ولكن هنا ينصب التركيز على الانتقال من نظام LLM فارغ إلى نظام جاهز للعمل.
1. ابدأ بإعداد الوكيل
اختر مهمة محددة وقابلة للتكرار ومحددة بوضوح. أشياء مثل حجز المواعيد، أو تدفقات الاستقبال، أو تأهيل العملاء المحتملين هي نقاط انطلاق مثالية.
.webp)
توجه إلى لوحة تحكم Botpress وأنشئ روبوتًا جديدًا، وحدد الغرض منه على الفور. أعطه وصفاً مختصراً مثل "وكيل حجز متعدد المواقع" أو "مساعد تأهيل العملاء المحتملين". في قسم "دور الوكيل"، اكتب سطرًا واحدًا حول ما يفترض أن يقوم به هذا الوكيل - ولا شيء أكثر من ذلك. هذا النطاق مهم.
2. إضافة المعرفة التي تؤسس للوكيل
تُعدّ LLMs المعارف قوية، ولكن بدون سياق العمل، فهي تخمين. انتقل إلى علامة التبويب "قاعدة المعرفة " وحمّل كل ما يحتاج الوكيل إلى معرفته - ملفات PDF، ومستندات المساعدة، وصفحات التسعير، والأسئلة الشائعة الداخلية، وحتى الصور ولقطات الشاشة إذا كان ذلك جزءًا من عملياتك.
.webp)
إذا كنت تقوم ببناء مساعد CRM (على سبيل المثال، لـ HubSpot)، قم بتحميل مستندات التأهيل ومعلومات المنتج وسياسات الخدمة. ضع علامة واضحة على كل إدخال بوضوح، وأنشئ مجموعات معرفية منفصلة إذا كنت تخطط لإنشاء المزيد من الوكلاء لاحقًا.
تأكد من تضمين KB فقط ما يتعلق بمجال الوكيل. هكذا تتجنب انجراف النطاق والهلوسة.
3. قم بتخطيط منطق العمل في محرر التدفق
هذا هو المكان الذي تنتقل فيه من مرحلة المحادثة إلى مرحلة التنفيذ.
توجه إلى محرر التدفق، وابدأ في بناء الهيكل: ما المعلومات التي يحتاج الوكيل إلى جمعها؟ ما هي الشروط التي يجب أن يتحقق منها قبل المتابعة؟ متى يصعد أو يتوقف؟
.webp)
على سبيل المثال، إذا كنت تقوم بإنشاء روبوت للحجز:
- اجمع الوقت والموقع والخدمة المفضلة لدى المستخدم
- التحقق من التوافر باستخدام مكالمة واجهة برمجة التطبيقات (سنصل إلى ذلك)
- تأكيد الفتحة، أو تقديم بدائل
يمكنك استخدام عقد الشرط، والتعبيرات، والمتغيرات - والتي يمكن تشغيلها جميعًا بمنطق LLM لتشغيلها والعمل دون الحاجة إلى أسلاك صلبة - لجعل المنطق يبدو ديناميكيًا ولكن بنطاق محدد دائمًا.
4. إضافة وصول إلى واجهة برمجة التطبيقات
انتقل إلى لوحة التكاملات وقم بإعداد مكالمات واجهة برمجة التطبيقات التي سيحتاجها وكيلك. يمكن أن يكون هذا نظام حجز (مثل Calendly أو واجهة برمجة تطبيقات الجدولة الداخلية الخاصة بك)، أو نقطة نهاية CRM، أو حتى نظام تذاكر الدعم.
- عنوان URL الأساسي ورؤوس المصادقة
- المعلمات (ديناميكية أو ثابتة)
- مكان تخزين الاستجابة (على سبيل المثال: slotOptions.workflow.slotOptions)
- كيفية استخدام تلك الاستجابة في التدفق (مثل عرض الأوقات المتاحة أو إرسال نموذج)
بمجرد أن يعمل، قم بتوصيل المستخدمين بسير عملك. يتوقف وكيلك الآن عن كونه "ذكيًا" ويبدأ في أن يكون مفيدًا.
5. التحقق من صحة سلوك الوكيل
استخدم محاكي الروبوت لتشغيل محادثات كاملة وتصحيح الأخطاء في الوقت الفعلي. كسر الأشياء عن قصد: أخطاء إملائية في الإدخالات، وتخطي الخطوات، وإعطاء مدخلات غريبة. شاهد كيف يتعافى الوكيل.
ثم، أضف الاحتياطيات. أضف عمليات التحقق من الصحة. استخدم العقد الشرطية لالتقاط حالات الحافة. إذا تخطى المستخدم حقلًا مطلوبًا، أعد التكرار مع توضيح ودّي لا يكسر تدفق المحادثة. إذا فشلت مكالمة واجهة برمجة التطبيقات، قم بتأكيد حالات الفشل وأبلغ المستخدم بالخطوات التالية بالضبط.
بمجرد الانتهاء من الاختبارات، توجه إلى الصفحة الرئيسية للوحة تحكم الوكيل، واختر القناة التي تريد نشر الوكيل عليها.
بمجرد إنشاء عامل رأسي واحد، يصبح النمط قابلاً للتكرار. تبدأ باكتشاف المزيد من تدفقات العمل التي يمكن أتمتتها وتحديد نطاقها وتحويلها إلى أنظمة - وليس مجرد محادثات. هذه هي القوة الحقيقية هنا: ليس فقط بناء الروبوتات ولكن إنشاء بنية تحتية تدفع العمل إلى الأمام.
هل تريد أن تبني بنفسك؟ يأتي Botpress مليئًا بالميزات التي تدعم تفاعلات LLM مع العديد من واجهات برمجة التطبيقات والمنصات والخدمات. إنها طريقة رائعة لتجربة تحويل LLMs إلى وكلاء يتم شحنها.
ابدأ البناء اليوم - إنه مجاني.
جدول المحتويات
شارك هذا على:
.svg)
