تحميل المعرفة ثم اقتراح حالات الاستخدام ثم الموافقة على SQL والنشر وسير العمل الكامل للدردشة
المسافة بين "يجب أن نضيف روبوت دردشة" و"روبوت الدردشة مباشر والتعامل مع المحادثات" عادة ما تُقاس بالأسابيع أو الأشهر. يتم كتابة وثائق المتطلبات. يتم تقييم البائعين. يتم جدولة اجتماعات التكامل. يتم اقتراح برامج الاختبار. بحلول الوقت الذي ينطلق فيه روبوت الدردشة فعلياً، غالباً ما تكون الاستعجالية الأصلية التي حفزت المشروع قد تلاشت إلى ضوضاء خلفية تنظيمية، استبدلت بأولويات أحدث امتصت الاهتمام والميزانية التي احتاجها مشروع الدردشة للانتهاء. الجدول الزمني للتنفيذ هو مقبرة حيث تذهب نوايا روبوت الدردشة الجيدة لتموت.
يضغط ChatBot API هذا الجدول الزمني من خلال هيكلة النشر كخط أنابيب خطي مع خطوات واضحة ومنفصلة. كل خطوة لها مدخل محدد ومخرج محدد وانتقال واضح إلى الخطوة التالية. لا توجد غموض حول ما يحتاج إلى الحدوث في كل مرحلة، لا توجد تبعيات دائرية تتطلب إعادة النظر في القرارات السابقة، ولا توجد خيارات معمارية تتطلب خبرة تقنية عميقة لاتخاذها. يتحرك خط الأنابيب في اتجاه واحد، من مستندات المعرفة الخام إلى روبوت دردشة مباشر، وكل خطوة تستغرق دقائق بدلاً من الأيام.
فهم هذا خط الأنابيب بالتفصيل له قيمة ليس فقط للتنفيذ بل لتحديد التوقعات الواقعية حول ما تساهم به كل خطوة في النتيجة النهائية. تعتمد جودة روبوت الدردشة على ما يحدث في كل مرحلة، والمعرفة بمكان الاستثمار في الاهتمام الإضافي مقابل حيث تكون الافتراضيات كافية ينتج عنها نتائج أفضل في وقت أقل من التعامل مع العملية بأكملها كصندوق أسود يعمل أم لا.
الخطوة الأولى وتحميل المعرفة التي تحدد ما يعرفه روبوت الدردشة
يبدأ خط الأنابيب بتحميل المعرفة. هذه هي الخطوة الأساسية لأن كل ما يتبعها يعتمد على جودة وكمال قاعدة المعرفة. تصبح المستندات المحملة في هذه المرحلة فهم روبوت الدردشة الكامل للعمل وعملياته وسياساته وإجراءاته. أي شيء غير ممثل في المستندات المحملة هو، من وجهة نظر روبوت الدردشة، أرض مجهولة التي ستتعامل معها إما بالاعتراف بالجهل أو بالعودة إلى معرفة عامة قد تكون أو قد لا تكون دقيقة للعمل المحدد.
تقبل عملية التحميل المستندات بصيغ قياسية وتعالجها من خلال خط أنابيب البلع الذي يؤدي عدة عمليات تلقائياً. يتم استخراج النص من صيغة المستند، مع الحفاظ على العناصر الهيكلية مثل العناوين والأقسام والقوائم مع تجاهل التنسيق الذي لا يحمل قيمة دلالية. ثم يتم تقطيع النص المستخرج إلى مقاطع صغيرة بما يكفي ليكون كل منها قابلاً للاسترجاع بشكل فردي لكن كبير بما يكفي للحفاظ على السياق في كل مقطع. يتم بعد ذلك تضمين هذه الأجزاء في فضاء متجه يمكّن البحث الدلالي، مما يعني أن روبوت الدردشة يمكنه العثور على معلومات ذات صلة بناءً على المعنى بدلاً من مطابقة الكلمات الرئيسية الدقيقة.
تحدث هذه المعالجة في الخلفية بعد التحميل وعادة ما تكتمل في غضون بضع دقائق لمجموعات المستندات بحجم معقول. أثناء المعالجة، يحلل النظام المحتوى لفهم بنيته الموضوعية، والتي تغذي الخطوة التالية من خط الأنابيب. لا يحتاج المستخدم إلى فهم التضمينات المتجهة أو البحث الدلالي للاستفادة منها. يحتاج إلى فهم أن المستندات التي يحملونها تصبح معرفة روبوت الدردشة، وأن المستندات الأكثر اكتمالاً والمكتوبة بوضوح أكثر ينتج عنها روبوت دردشة أكثر قدرة.
يعطي النهج العملي لتحميل المعرفة الأولوية للمستندات التي تعالج التفاعلات الأكثر شيوعاً التي سيتعامل معها روبوت الدردشة. إذا كان الغرض الأساسي هو دعم العملاء، فإن مستند FAQ والدليل استكشاف الأخطاء وإصلاحها والدليل المنتج هي أعلى ترتيب الأولويات. إذا كان الغرض الأساسي هو تأهيل المبيعات، فإن أدلة مقارنة المنتجات والوثائق الخاصة بالتسعير وأوصاف ملف العميل المثالي مهمة للغاية. يسمح البدء بالمستندات ذات التأثير الأعلى وإضافة المواد الثانوية لاحقاً لروبوت الدردشة بالتعامل مع السيناريوهات الأكثر شيوعاً على الفور بينما تستمر قاعدة المعرفة في التوسع.
الخطوة الثانية واقتراح حالات الاستخدام بناءً على المعرفة المرفوعة
بعد معالجة قاعدة المعرفة، يحلل النظام المحتوى لاقتراح حالات الاستخدام التي يمكن لروبوت الدردشة التعامل معها بشكل معقول بناءً على المعلومات المتاحة. خطوة الاقتراح هذه هي واحدة من أكثر الأجزاء قيمة في خط الأنابيب لأنها تجسر الفجوة بين "هنا وثائقنا" و"هنا ما يجب أن يفعله روبوت الدردشة"، وهي فجوة تكافح العديد من تطبيقات روبوت الدردشة للعبور بدون جلسات تخطيط واسعة.
يتم إنشاء الاقتراحات من خلال فحص التغطية الموضوعية للمستندات المحملة ورسم تلك التغطية على أنماط التفاعل الشائعة لروبوت الدردشة. إذا كانت قاعدة المعرفة تتضمن وثائق المنتج، يقترح النظام حالة استخدام معلومات المنتج. إذا كانت تتضمن أدلة استكشاف الأخطاء، فإنها تقترح حالة استخدام دعم تقني. إذا كانت تتضمن معلومات التسعير، فإنها تقترح حالة استخدام الاستعلام عن التسعير. يأتي كل اقتراح مع وصف للسيناريو الذي يغطيه والنوع من الأسئلة التي قد يطرحها المستخدمون والسلوك المتوقع لروبوت الدردشة عند التعامل مع هذا السيناريو.
هذه الاقتراحات نقاط بداية، وليست تكوينات نهائية. يراجع المستخدم كل اقتراح إما يقبله كما هو أو يعدله ليناسب احتياجاته المحددة بشكل أفضل أو يرفضه إذا لم يكن السيناريو ذا صلة. يمكن تعريف حالات استخدام إضافية يدويأً للسيناريوهات التي لم يحددها التحليل الآلي، مثل سير العمل المتخصصة أو الحالات الحدودية التي تهم العمل لكنها لا تمثل بشكل جيد في أنماط المستندات القياسية. ينتج عن الجمع بين الاقتراح الآلي والتحسين اليدوي مجموعة حالات استخدام شاملة وموجهة لاحتياجات العمل الفعلية.
الفائدة العملية للاقتراح الآلي لحالات الاستخدام هي أنها تلغي مشكلة الحد الفارغ التي تعرقل العديد من تطبيقات روبوت الدردشة. بدلاً من البدء بالسؤال "ماذا يجب أن يفعل روبوت الدردشة الخاص بنا؟" ومحاولة تعداد كل سيناريو ممكن من الصفر، يبدأ الفريق بقائمة منسقة من الاقتراحات المستندة إلى المحتوى الفعلي الذي قدموه. هذا نقطة بداية أساسية أسهل تسرع عملية صنع القرار وتقلل خطر تجاهل السيناريوهات المهمة التي تدعمها الوثائق بوضوح.
الخطوة الثالثة والموافقة على SQL وإنشاء سر المكون الإضافي
البنية التحتية التقنية التي تدعم تشغيل روبوت الدردشة تتطلب هياكل قاعدة بيانات لتخزين المحادثات وحالة الجلسة والتفاعلات الخاصة بالمستخدم وسجلات استرجاع المعرفة. ينتج خط الأنابيب مخطط SQL الضروري بناءً على حالات الاستخدام المعتمدة ويعرضه للمراجعة قبل التنفيذ. توجد خطوة الموافقة هذه لضمان الشفافية: يرى المستخدم بالضبط هياكل قاعدة البيانات التي سيتم إنشاؤها قبل إنشاؤها، مع الحفاظ على الرؤية الكاملة للبصمة التقنية لنشر روبوت الدردشة.
بالنسبة للمستخدمين الذين لديهم خلفية تقنية، توفر مراجعة SQL فرصة للتحقق من أن المخطط يتوافق مع معايير البنية التحتية الخاصة بهم واتفاقيات التسمية وسياسات حوكمة البيانات. بالنسبة للمستخدمين غير التقنيين، تخدم خطوة المراجعة بشكل أساسي كبوابة تأكيد تضمن أن خط الأنابيب لا يعدل هياكل قاعدة البيانات بدون موافقة صريحة. في كلا الحالتين، الموافقة هي إجراء واحد: راجع المخطط الذي تم إنشاؤه وأكد أنه مقبول وتقدم. يتم تصميم المخطط ليكون مستقلاً، وينشئ جداول جديدة وفهارس بدون تعديل أي هياكل قاعدة بيانات موجودة.
بعد الموافقة على SQL، ينشئ النظام سر مكون إضافي يخدم كبيانات اعتماد المصادقة لجميع تفاعلات API روبوت الدردشة. يستخدم هذا السر من خلال تكامل الواجهة الأمامية (سواء كان عنصر واجهة مستخدم على الويب أو مكون تطبيق جوال أو واجهة مخصصة) للمصادقة مع خلفية روبوت الدردشة وإنشاء جلسات محادثة مصرحة. إنشاء السر تلقائي ويتبع أفضل الممارسات الأمنية بما في ذلك الإنتروبيا الكافية والتخزين الآمن. ينسخ المستخدم السر ويخزنه في تكوين التطبيق الخاص به، مما يكمل إعداد المصادقة.
يمثل الجمع بين موافقة SQL وإنشاء السر الانتقال من التكوين إلى جاهزية النشر. قبل هذه الخطوات، يوجد روبوت الدردشة كتكوين: قاعدة معرفة وحالات استخدام وخيارات سلوكية. بعد هذه الخطوات، فهو يوجد كخدمة قابلة للنشر مع البنية التحتية لقاعدة البيانات للحفاظ على المحادثات وآلية المصادقة لتأمين الوصول. تحرك خط الأنابيب من التعريف المجرد إلى التنفيذ الملموس، والخطوة الأخيرة هي توصيل الواجهة الأمامية.
الخطوة الرابعة والنشر والمحادثات المباشرة الأولى
يربط النشر روبوت الدردشة بواجهته التي تواجه المستخدم. تعتمد آلية التكامل المحددة على مكان وجود روبوت الدردشة: عنصر واجهة مستخدم دردشة على الويب أو شاشة تطبيق جوال أو تكامل Slack أو لوحة معلومات مخصصة أو أي واجهة أخرى يمكنها إجراء طلبات HTTP إلى API. يوفر API روبوت الدردشة نقاط نهاية لبدء الجلسات وإرسال الرسائل وتلقي الردود واسترجاع سجل المحادثة. أي واجهة أمامية يمكنها استدعاء نقاط النهاية هذه يمكنها استضافة روبوت الدردشة.
لنشر الويب، النمط الأكثر شيوعاً هو عنصر واجهة مستخدم دردشة يظهر على صفحات محددة أو عبر الموقع بالكامل. يتعامل العنصر مع العرض البصري للمحادثة وحقل الإدخال لرسائل المستخدم وعرض ردود روبوت الدردشة. يتواصل مع API روبوت الدردشة باستخدام سر المكون الإضافي للمصادقة ومعرف الجلسة لاستمرارية المحادثة. يمكن بناء العنصر من الصفر باستخدام وثائق API أو يمكن تكييف قوالب عناصر واجهة مستخدم مبنية مسبقاً لمطابقة التصميم البصري للموقع.
المحادثات المباشرة الأولى هي في الوقت نفسه الجزء الأكثر إثارة والأكثر إفادة من العملية بأكملها. يسأل المستخدمون الحقيقيون أسئلة لم تتوقعها أي جلسة تخطيط. يصيغون الأشياء بطرق لم يتنبأ بها أي تعريف حالة استخدام. يتوقعون معلومات قاعدة المعرفة تقريباً لكن لا تحتويها تماماً. كل واحد من هذه التفاعلات هو فرصة للتعلم التي تغذي مرة أخرى في تحسينات قاعدة المعرفة وتعريفات حالات الاستخدام الموصوفة في خطوات خط الأنابيب السابقة. خط الأنابيب، بمعنى هذا، ليس خطياً بحتة. إنه خطي أثناء النشر الأولي ويصبح دوريأً أثناء التشغيل المستمر، مع بيانات المحادثة المباشرة التي تقود التحسين المستمر لقاعدة المعرفة وتعريفات حالات الاستخدام.
تعطي سجل المحادثة والتحليلات التي توفرها API صيانة روبوت الدردشة رؤية حول الأسئلة التي يتم طرحها بشكل متكرر والتي الاستجابات التي ترضي المستخدمين وحيث يسقط روبوت الدردشة. تحول هذه البيانات روبوت الدردشة من نشر ثابت إلى نظام ديناميكي يتحسن مع الاستخدام. الإعداد الأولي لمدة خمسة عشر دقيقة يجعل روبوت الدردشة مباشراً. التحسين المستمر، الموجه ببيانات المحادثة الحقيقية، يجعله قيمة تدريجياً أكثر على مدى الأسابيع والأشهر التالية.
خط الأنابيب الكامل في السياق
عند النظر إليها من النهاية إلى النهاية، يحول خط الأنابيب مستندات الشركة إلى دردشة محادثة ذكية مباشرة في أربع خطوات منفصلة: تحميل المعرفة وتعريف حالات الاستخدام والموافقة على البنية التحتية والنشر. كل خطوة لها مدخلات وإخراجات واضحة. كل خطوة تبني على السابقة. وكل خطوة يمكن إكمالها في دقائق بدلاً من الأيام، وهذا ما يجعل جدول النشر لمدة خمسة عشر دقيقة قابلاً للتحقيق للمنظمات التي تأتي إلى العملية مع وثائقها المعرفية منظمة بالفعل وأهدافها المحادثة مفهومة بالفعل.
المنظمات التي لا تملك وثائقها منظمة ستقضي المزيد من الوقت في التحضير مقابل خط الأنابيب نفسه، وهي نتيجة ذات قيمة فعلاً. تفرض عملية نشر روبوت الدردشة على المنظمة توحيد وهيكلة معرفتها المؤسسية، والتي توفر فوائد تتجاوز روبوت الدردشة نفسه. تخدم قاعدة المعرفة المنظمة نفسها التي تقوي روبوت الدردشة أيضاً كوثائق داخلية أفضل وعنصر تدريب أفضل للموظفين الجدد وأساس أفضل لأي مبادرة إدارة معرفة أخرى تقوم بها المنظمة.
يوضح خط الأنابيب أيضاً عملية نشر روبوت الدردشة بجعل كل خطوة مرئية ومفهومة. لا توجد صندوق أسود حيث تدخل المستندات وتخرج روبوت دردشة بدون رؤية في التحويل. كل خطوة قابلة للملاحظة، كل تكوين قابل للمراجعة، وكل مكون يمكن تعديله بشكل مستقل. تبني هذه الشفافية الثقة في النظام وتمكّن صيانة روبوت الدردشة لاتخاذ قرارات مستنيرة بشأن التحسينات والتوسعات بمرور الوقت.
أسئلة شائعة
هل يمكن إعادة تشغيل خط الأنابيب إذا تم ارتكاب أخطاء في خطوة سابقة
نعم. يمكن إعادة زيارة كل خطوة بشكل مستقل. يمكن إضافة مستندات المعرفة أو استبدالها في أي وقت. يمكن تعديل حالات الاستخدام أو إضافتها أو إزالتها بدون التأثير على قاعدة المعرفة. يمكن إعادة إنشاء مخطط SQL إذا كانت التغييرات الهيكلية مطلوبة. يتم تصميم خط الأنابيب للتحسين التكراري بدلاً من المطالبة بعبور نموذجي مثالي.
كم من الوقت تستغرق خطوة معالجة المعرفة
يعتمد وقت المعالجة على حجم المستندات المرفوعة. مجموعة نموذجية من خمسة إلى عشرة مستندات يبلغ مجموعها خمسين صفحة تعالج في أقل من خمس دقائق. تستغرق مجموعات المستندات الأكبر وقتاً أطول بشكل متناسب. تعمل المعالجة في الخلفية، ويتم إخطار المستخدم عند الانتهاء وأن قاعدة المعرفة جاهزة للاستخدام.
ماذا يحدث إذا لم تتطابق اقتراحات حالات الاستخدام مع الغرض المقصود من روبوت الدردشة
الاقتراحات هي نقاط بداية اختيارية. يمكن رفض جميع الاقتراحات واستبدالها بحالات استخدام محددة يدويأً تطابق الغرض المقصود بالضبط. يعمل نظام الاقتراح بشكل أفضل عندما تتعلق المستندات المرفوعة بوضوح بالدور المقصود لروبوت الدردشة، وبشكل أقل فعالية عندما تكون المستندات عرضية للحالة الأساسية المستخدمة.
هل مخطط SQL متوافق مع أي نظام قاعدة بيانات
يستهدف SQL الذي تم إنشاؤه نظام قاعدة البيانات المرتبط بتكوين حساب API. أنظمة قواعد البيانات العلائقية القياسية مدعومة، والمخطط يستخدم بناء جملة SQL متوافق على نطاق واسع لضمان المحمولية. يمكن للمستخدمين الذين لديهم متطلبات قاعدة بيانات محددة مراجعة المخطط الذي تم إنشاؤه وطلب التعديلات قبل الموافقة.
هل يمكن تدوير سر المكون الإضافي لأغراض أمنية
نعم. يمكن إعادة إنشاء أسرار المكونات الإضافية في أي وقت من خلال واجهة إدارة API. إعادة إنشاء سر على الفور يبطل السر السابق، مما يعني أنه يجب تحديث تكامل الواجهة الأمامية مع السر الجديد. تدعم هذه القدرة على التدوير أفضل الممارسات الأمنية بما في ذلك تغييرات بيانات الاعتماد الدورية والاستجابة الفورية لاشتباه في اختراق السر.
كم عدد المحادثات التي يمكن لروبوت الدردشة التعامل معها في نفس الوقت
تم تصميم API للتعامل مع المحادثات المتزامنة بدون تدهور. تعمل كل محادثة في سياق جلستها الخاص، والبنية التحتية الأساسية تتسع للتعامل مع طفرات حركة المرور. لا توجد حدود عملية على المحادثات المتزامنة لاستخدام API القياسي، على الرغم من أن الكميات العالية جداً قد تتطلب التنسيق مع الدعم لضمان مطابقة تخصيص البنية التحتية للطلب.