اشترت الشركة في العامين الماضيين العديد من أدوات الذكاء الاصطناعي: مساعدو الدردشة، وإضافات الكتابة، وروبوتات خدمة العملاء، ونظام الأسئلة والأجوبة الداخلي. لكن القدرات الحقيقية التي ترسخت لا تزال قليلة. فكلمات التوجيه ما زالت محفوظة على الحواسيب الشخصية، وعمليات الأعمال مبعثرة في زوايا الوثائق، وبعد إطلاق النماذج الذكية يفتقر النظام إلى التغذية الراجعة والتعديلات، ولا تزال الكوادر الأساسية في العمل مشغولة بأوقات عملها بالاستفسارات ذاتها. وغالبًا ما لا تكمن المشكلة في أن النموذج ليس ذكيًا بما يكفي، بل فيلم يصمّم النظام «العمل» كقدرة وظيفية قابلة للإدارة。
أولاً، نوضح: لماذا لا يمكن استخدام نافذة الدردشة كمنصب وظيفي؟
يُنهي روبوت الدردشة المحادثة بمجرد الإجابة عن سؤال واحد. أما الوظائف فتحتاج إلى استمرار تولي المهام: جمع المعلومات، وتطبيق قواعد التقييم، واستدعاء الأنظمة، وتسجيل حالة الرد، وإعادة التصعيد عند مواجهة أي استثناءات. ويُعدّ تسديد نفقات السفر مثالاً نموذجياً؛ فقد يبدأ المستخدم بالقول: «ساعدني في تقديم طلب سداد نفقات السفر»، ثم يسأل في منتصف المحادثة: «كم تبقى من الحد المسموح به لهذا الشهر؟»، وبعد ذلك يضيف فاتورة إضافية. وإذا عامل النظام كل محادثة على أنها محادثة جديدة، فستتعطل العملية، وستُفقد السياق، ولن يكون بالإمكان لاحقاً مراجعة ما إذا كان الخطأ في القاعدة أم في الواجهة البرمجية.
في الصناعة، توجد بالفعل ممارسات تُعرِّف الذكاء الاصطناعي على أنه «موظف رقمي»: إذ يُزوَّد بمنصب ورقم موظف وحدود كفاءاته وسجل عمله، إلى جانب SOP قابلة للتعديل، وقاعدة معرفية، وأدوات، ومسار تنفيذي. وعلى صعيد المصادر المفتوحة، فإن منتج StaffDeck الذي أطلقته مؤسسات مثل OpenBMB يتعامل مع العامل الذكي باعتباره مجموعةً من الموارد القابلة للتشغيل، وليس مجرد نص إرشادي. وبالنسبة للشركات التي تطوّر حلولها الخاصة أو تُعدّها حسب الطلب، فإن ما يستحق الاستلهام ليس مصطلح المنتج بحدّ ذاته، بل هذا النموذج الكائني.
منطق الأعمال: يجب أن يحتوي النظام على سبعة أنواع على الأقل من الكائنات
عند إنشاء نظام الموظف الرقمي، ابدأ أولاً بتدوين كائنات الأعمال في المواصفات، ثم تابع بعد ذلك اختيار النموذج.
- ملف الوظيفة: الاسم أو اسم الشخصية، رقم الموظف، المسؤوليات، الحالة عبر الإنترنت، والجهة المستفيدة من الخدمة. بدون ملفات تعريفية، لا توجد جهة لربط الصلاحيات والتقييمات بها.
- حدود القدرة: أي الوثائق يمكن قراءتها، وأي الحقول يمكن كتابتها، وما لا يمكن التعهد به. يجب أن تكون الحدود قابلة للتعديل من قبل المشرف، وليس محددة بشكل ثابت في عبارات التحذير.
- SOP / المهارات القائمة على العمليات: قم بتفكيك العمليات المعقدة إلى عقد، مع دعم التفرعات الشرطية واستدعاء الأدوات والبحث عن المعرفة والتحويل إلى موظف بشري.
- أنطولوجيا المعرفة: يتم تخزين الموضوعات والقواعد والمصادر ودليل التشغيل بشكل منفصل، ويجب أن تكون الإجابات قادرة على الرجوع إلى المصدر، كما يجب أن يكون البحث قابلًا للضبط.
- الوصول إلى الأدوات: واجهة HTTP أو MCP، تُستخدم للاستعلام عن الحد الائتماني، وإنشاء المستندات، وتغيير الحالة، وليس فقط لإنشاء مقطع نصي.
- المهام المجدولة: لا يمكن انتظار المستخدمين حتى يبدؤوا بالحديث بشأن المهام الدورية مثل تجميع التقارير اليومية، والمتابعة المتأخرة، وفحص المخزون.
- التتبع والتعليقات: تسجيل المسار والخطوات والأدوات والمعرفة والردود؛ كما يتم إدخال الإعجابات والتعليقات السلبية والإحالات اليدوية إلى الجولة التالية من المراجعة.
غالبًا ما يتضمن الطلب الحقيقي عدة مهام. يجب أن يتمكن الموظف الرقمي أولاً من الدخول إلى SOP الخاص بتسديد المصاريف، وجمع جميع الحقول وإجراء التحقق من القواعد، ثم الانتقال إلى SOP الخاص باستعلام الحد الائتماني لاستدعاء الواجهة البرمجية. وإذا قام المستخدم بطرح سؤال حول السياسات أثناء العملية، فيجب حفظ الموقع الحالي، والعودة إلى المسار الأصلي بعد الإجابة. أما بالنسبة للأسئلة التي تتجاوز القواعد، فيُرجى تسليم السياق إلى المنشئ أو المسؤول المناوب، مع منع تقديم إجابات قاطعة دون أساس.
منطق التصميم: الأدوار، آلة الحالة، التدرج المعرفي
كيف يتم تغيير الدور؟
على الأقل يُقسَّم الناس إلى أربع فئات:المُنشئ(ترسيخ الخبرات لدى الموظفين)،المشرف(إدارة الأذونات، النشر، الحصص)،المستخدم(إسناد المهام إلى الموظف الرقمي)،الشخص المناوب(استمرار الاستثناء). لا ينبغي أن يمتلك المنشئ بشكل افتراضي صلاحية تعديل المخزون أو السعر؛ كما لا ينبغي للمستخدم رؤية النص الكامل للتعليمات والرمز السري. يجب أيضًا تقسيم الواجهات المفتوحة إلى مستويات: فالرمز السري على مستوى الحساب يتيح التحكم في موارد النظام، بينما يقتصر الرمز السري على مستوى الموظف على إنشاء الجلسات وقراءة سجلاته فقط.
يستخدم SOP آلة الحالة، ولا يعتمد فقط على ذاكرة المحادثة.
يمكن للغة الطبيعية إنشاء المسودة الأولى، ويتعين تنفيذ العملية عبر آلة الحالة: العقدة الحالية، والمقابس التي تم جمعها، والأدوات القابلة للاستدعاء، وإعادة المحاولة في حالة الفشل، وعقدة العمل اليدوي. وبعد انقطاع المهمة، يجب أن يكون بالإمكان تسلسل السياق والعودة إلى العقدة الأصلية لمتابعة التنفيذ. يُسمح بالتبديل بين عدة SOPs في الوقت الفعلي، لكن يجب الاحتفاظ بمعلومات «من أين جاءت وما هي المعلومات المؤكدة التي أحضرتها» عند التبديل، لتجنب إعادة ملء النماذج من قبل المستخدم. كما ينبغي أن تكون الإصدارات والفروع قابلة للرجوع، بحيث يمكن إطلاق التغييرات على الكلمات الدلالية في الموقع مباشرةً، مع استبعاد أي مساءلة لاحقة.
لا تجعل المعرفة عبارة عن بحث مختلط.
أنشئ فهرسًا قابلًا للتنقل وفقًا للمستندات والفصول والصفحات والملخصات؛ ابدأ بتحديد الفئة المحتملة للمعلومة، ثم حدد الموقع الأصلي في النص. تقسيم المعرفة إلى دلاء: افصل بين معايير الأنظمة، ووصف المنتجات، ونصائح خدمة ما بعد البيع، وحالات الاستثناء، بحيث يكون البحث الموجه أكثر استقرارًا من البحث باستخدام الكلمات الرئيسية الشاملة. ربط كل إجابة بالمصدر والقواعد والموضوع التجاري، ويجب أن يتيح بيئة الاختبار الاطلاع على «سبب صحة استهداف هذا الجزء». غالبًا ما يساعد تصحيح عملية البحث في حل المشكلات أكثر من اللجوء إلى نموذج أكبر.
التطوير والتنفيذ: الواجهات، العزل، المراقبة، والقبول
يوصى أثناء التشغيل بتوحيد نقطة الدخول لتجنب اتباع كل ميزة سلسلة إجراءات منفصلة، مما قد يؤدي إلى انحراف الحالة. يجب إنجاز اكتشاف القدرات، والتنفيذ المعزول، وسلامة المُنتجات، وحساب الحصص خلال وقت التشغيل، وليس بالاعتماد على الاتفاقيات فقط. وقبل نشر الميزات في السوق الداخلية، يتعين إجراء فحص للأذونات: يجب ألا تظهر رؤوس المصادقة، ومتغيرات البيئة، وبيانات الاعتماد الخاصة بالاتصال في واجهات القراءة العادية.
- قناة التنفيذ: يناسب التدفق المتزامن المحادثات؛ أما التشغيل غير المتزامن + تدفق الأحداث فيناسب استئناف النقل بعد الانقطاع وقوائم المهام، وهما يستخدمان نفس النواة.
- هوية القناة: يمكن استخدام واتساب، واتساب للأعمال، فاي شو، و DingTalk كمنافذ دخول، لكن يجب أن تكون هوية الموظفين، والمحادثات، وTrace موحدة، ويُمنع إنشاء مجموعة من السجلات في كل قناة.
- الأمن: يقتصر تكوين النموذج على الاستشهاد بأرقام التكوينات الموجودة، ولا يتم إرجاع مفتاح المورد؛ كما تُجرى عملية إخفاء الهوية عند إدخال نتائج الأدوات في نظام التتبع.
- الدعم اليدوي: في حالات المهلة الزمنية، وانخفاض مستوى الثقة، والتجاوز غير المصرح به، وتحويل المستخدم يدويًا إلى موظف بشري، يجب أن تُنقل السياق بالكامل في جميع الحالات الأربع.
لا يكفي أن تقتصر عملية القبول على اختبار «القدرة على الدردشة». قدم مجموعة من السكريبتات القابلة للتكرار: الإغلاق الطبيعي، والتدخل أثناء العملية، ونقص الرصيد، وتجاوز زمن الاستجابة للواجهة البرمجية، والكتابة بصلاحية غير مخوّلة، ورفض الإجابة لعدم وجود مصدر. وفي كل سكريبت، تحقق من: استعادة العقدة إلى حالته الطبيعية، وصواب كتابة المستند، واكتمال التتبع (Trace)، ووصول الاستثناء إلى الشخص المختص. إن نسبة نجاح العينات، ونسبة معالجة الأوقات الزائدة، وعدد الحالات التي تم الرد عليها دون أساس، تعد مؤشرات أكثر ملاءمة لتحديد شروط الدخول إلى النظام من نجمات الرضا.
ترتيب الإطلاق: أولاً، مهام متكررة لفترة قصيرة
لا تبدأ مباشرةً ببناء مساعد شامل. اختر جزءًا من مهام المتابعة اليومية في المبيعات، أو متابعة الموافقات، أو الأسئلة والأجوبة حول السياسات، أو التدقيق المسبق للنفقات، والذي يتكرر لأكثر من نصف ساعة يوميًا، وصِغَ الإدخال والإخراج والصلاحيات والاستثناءات في أربع جمل، ثم زوّده بإجراءات تشغيل معيارية (SOP) وواجهتين لقراءة البيانات فقط أو كتابتها بمحدودية. وعندما تكون البيانات الرئيسية غير نظيفة أو تكون عناصر الموافقة غير واضحة، قم أولًا بتصحيح الكيانات والحالات، ثم أضف التنفيذ الذكي — فبعد أن تُ automatize البيانات غير النظيفة، ستنتشر بسرعة أكبر في جميع أنحاء الشركة.
كيف نعرف أن التصميم صائب: لم تعد تلك المرحلة التي تعتمد على المتابعة الجماعية وتعبئة النماذج هي المسار الرئيسي؛ أصبح بالإمكان مراجعة المحاضر والمتابعات والتقارير المجمّعة مقابل المستندات بشكل عشوائي؛ وللحالات غير الواضحة يوجد جهة لرفع المستوى؛ كما تُخضع العمليات الحساسة للمراجعة، ويمكن استعراض السجلات. ولتقييم مدى مطابقة التطوير للمعايير، يُنظر إلىهل يمكن استئناف SOP نفسه بعد انقطاعه؟、الإجابة هل يمكن الإشارة إلى المصدر؟、هل يمكن إدراج حالة الحدود في الجولة التالية من المراجعة؟. إذا تم اجتياز هذه المهام الثلاث، فسيتم توسيع الوظائف لاحقًا، وهو أمر أكثر استقرارًا من إنشاء العديد من نقاط الدردشة أولًا.
تكمن الصعوبة التقنية لنظام الموظف الرقمي ليس في إنشاء المحادثات، بل في تحويل الوظائف والعمليات والمعرفة والأدوات والمسارات إلى كائنات برمجية قابلة للإصدار. يمكن تعديل عبارات التحذير عشر مرات في الأسبوع، ولكن إذا انفرط نموذج الكائن، فسيتعين كتابة مجموعة جديدة من المهارات لكل مرحلة لاحقة. يجب أولاً ضمان عمل هذه الفئات السبع من الكائنات وآلة الحالة بشكل سليم؛ إذ إن ترقية النموذج لا تكون ممكنة إلا بعد ذلك. وإلا فإن كل مرة يتم فيها تغيير النموذج ستصبح بمثابة مشروع جديد، وليس مجرد تغيير في الإعدادات.