🌨️ 🎌 💪🏾 كما فعلنا المصمم التالي لروبوتات الدردشة. الجزء الأول 🐎 📮 👂🏼

مرحبا هابرومير! في العام الماضي ، قضيت أنا وفريقنا في إنشاء شركة Botlify Chatbot Constructor للأعمال التجارية ، وأود أن نشارك مع الجمهور تاريخًا قصيرًا للمشروع والقرارات الفنية المتخذة. في هذا المنشور ، سأحاول التركيز قدر الإمكان على التفاصيل التقنية والتعمق في المنتج والأعمال بشكل أقل ، على الرغم من حقيقة أن دوري في هذا المشروع أقل ارتباطًا بالتنمية والتكنولوجيا. تستند هذه المواد إلى تجربتي الشخصية ، فأنا لست مدربًا مبتدئًا ولا أتظاهر بأنني مبرمج جيد أو مدير أو مهندس معماري أو رجل أعمال. نحن شركة ناشئة صغيرة نسبيًا مع عدد قليل من المستخدمين ، لذلك لن يكون هناك شيء حول أعباء العمل ومشكلات المشاريع الكبيرة. تحت هذا التخفيض ، سأخبرك كيف بدأ مشروعي ، ونوع من أشعل النار التطوير الذي خطونا عليه والاستنتاجات التي توصلنا إليها.

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

الأهداف

قبل أن أبدأ قصة المشروع ، أود أن أتحدث عن الأهداف التي سعينا منذ البداية ، بدء هذه المغامرة. في الواقع ، بدأ مصممنا كمشروع للحيوانات الأليفة لتعلم أساسيات إدارة المنتجات ، وتطوير العملاء ، واكتساب مهارات إدارية جديدة وخبرة في الشركات الناشئة. لقد سمعت وحاولت عدة مرات لتطبيق نهج LEAN Startup وفي كل مرة اتضح أنها مختلفة تمامًا. بالطبع ، حلمنا ببناء عمل تجاري على هذا وكسب المال الجيد ، لكننا لم نفهم أنفسنا بالأوهام بأن هذه كانت طريقة بسيطة وقصيرة. والأكثر من ذلك ، أننا لم نحاول صنع نوع من WOW! - الابتكار. كان لدي وشريكي المؤسس عمل دائم بدوام كامل وأدركنا أننا لن نتمكن من تكريس الكثير من الوقت.كان الدافع الرئيسي هو على وجه التحديد الفرصة لإتقان مجالات جديدة تمامًا في صناعة تكنولوجيا المعلومات وتطبيق معرفة جديدة في الممارسة ، وفي نفس الوقت كسب المال.

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

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

وهنا صادفت المشكلة الأولى: كيف أصف الحوار مع البوت بطريقة توضح ما ولماذا يستجيب البوت وفي نفس الوقت يكون أمامه تسلسل كامل من الإجراءات أمامه؟في البداية ، حاولت استخدام xmind وأدوات أخرى لإنشاء خريطة ذهنية. اتضح شيء من هذا القبيل.

مثال على الخريطة الآلية

في وقت لاحق أصبح من الواضح أن روبوتات الدردشة ككل مناسبة تمامًا بشكل جيد في مفهوم وصف الحالات والتحولات بينها ، وتبين أنها ملائمة تمامًا للتنقل في فروع المحادثة حتى عندما يكون هناك الكثير منها.

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

الروبوتات موضوع معقد وكبير نوعًا ما ، ومواردنا محدودة جدًا. لذلك ، كان من الضروري بالنسبة لنا تبسيط قرارنا قدر الإمكان حتى يتمكن من رؤية السوق. " كلما كان ذلك أفضل " - لن أتعب من تكرار هذا الشعار في سياق الشركات الناشئة.

AI & ML

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

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

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

دردشة بوت مقابل رجل

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

معالجة

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

في بداية العمل على أي مشروع ، أرى أنه من المهم جدًا محاولة إضفاء الطابع الرسمي على أفكاري قدر الإمكان. في حين أن الفكرة لم تجد شكلها على الورق ، في شكل نص وملاحظات ورسومات ، لا توجد فكرة على الإطلاق. في الوقت نفسه ، يجب أن تكون جميع العمليات داخل الفريق بسيطة وطبيعية وسريعة قدر الإمكان ، وفعالة في التواصل. يجب ألا تستخدم أدوات كبيرة وثقيلة لإدارة فريقك ، مثل Jira أو Redmine ، إذا كان فريقك بأكمله هو أنت وصديقك. ولكن أيضًا عدم استخدام أي شيء أيضًا ، وإلا فإن كل شيء سيخرج بسرعة عن نطاق السيطرة وستنشأ الفوضى ، مما يحد من صعوبة أكثر بكثير من مجرد عدم السماح به. حتى في رأس شخص واحد يمكن أن تتشكل مثل هذه الفوضى وفقًا للمشروع ، ليس لي أن أخبرك بما أقول عن الفريق ، حتى لو كان من 2-3 أشخاص فقط.

استخدمنا ، مثل الشركات الناشئة الحقيقية ، Trello لتنظيم المهام وتخزين الروابط المهمة للمشروع ، كما تم طرح الأفكار هناك. بالنسبة لوثائق الأعمال ، فإن مستندات Google ، على الرغم من كونها تقنية ، تم إنشاؤها بشكل جيد تمامًا في تخفيض السعر ووضعها في المستودع المقابل. التواصل على مدار اليوم - Telegram ، وللوقوف اليومي على Google Hangouts . تعد المواقف اليومية أحد أحجار الزاوية لوجود فرق بعيدة . إذا لم يكن هذا موجودًا ، فلا يوجد فريق ، يبدأ شخص ما بالضرورة في الشعور بالوحدة والتعب وسوء الفهم والاستياء يتراكم ، ليس فقط السيطرة على الموقف ولكن أيضًا فقدان العلاقات في الفريق.

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

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

عندما رأينا اهتمام زوار الهبوط والتحويلات الإضافية الناتجة عن العرض التوضيحي ، قررنا أن نذهب إلى أبعد من ذلك. أتذكر أن الإصدار الأول من المنشئ كان نموذج تسجيل مع نموذج تسجيل دخول ، وبعد ذلك تم نقل المستخدم إلى صفحة تحتوي على اعتذار ووعد بالإبلاغ عندما يعمل شيء آخر. لقد قمت بتسجيل الدخول واستمارات التسجيل لمئات المرات في حياتي ولم أستطع حتى التفكير هنا أننا سنجد على الفور الكثير من المشاكل.لم يتمكن حوالي 60٪ من المستخدمين الأوائل من إكمال عملية التسجيل . لمن لا يعمل الزر ، لمن لا يأتي البريد الإلكتروني ، لمن هو شيء آخر. في البداية ، أدركت فكرة الإفراج عن شكلين فقط متشككين تمامًا ، ولكن نظرة أولية على Yandex ، أوضحت مترريكا أنها كانت القرار الصحيح. كان لإدراك أن المستخدمين يتصرفون بشكل مختلف عما تريد ، وأحيانًا بالطريقة التي اعتقدت حتى أنك لا تستطيعها ، كان لها تأثير كبير على كل ما فعلناه بعد ذلك. كهواية ، قضيت عدة مرات أسبوعيًا في بضع ساعات في متصفح ويب فقط أشاهد كيف يستخدم المستخدمون حرفتنا.

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

نتيجة

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

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

قبل الشروع في الجزء الأكثر تقنية من التأليف ، ربما يجدر إخباره لفترة وجيزة عما يسمح لك المنتج القيام به.

إدارة برامج الدردشة الآلية في حسابك
محرر chatbot مرئي
التحكم في الوصول إلى روبوت الدردشة (تحرير الوصول ، الوصول العام)
القدرة على نشر روبوتات الدردشة على الويب (القطعة ، المضمنة ، ملء الشاشة)
إعدادات Chatbot (التصميم والأسماء والمقاييس وموضع الأداة ، وما إلى ذلك)
دعم دمج برامج الدردشة الآلية مع الخدمات الخارجية من خلال طلبات GET و POST
تحليل مربعات حوار البوت
ادارة الحساب
نموذج الاشتراك ، إدارة الاشتراك

هندسة معمارية

الآن ، بمعرفة الخلفية والأهداف والفكرة والمبادئ التي أرشدتنا في التطوير ، يمكنني البدء في تقديم وصف عام لكيفية عمل كل هذا. نظرًا لأن خيارنا الأولي كان إنشاء روبوتات دردشة للمواقع وروبوتات دردشة ملء الشاشة ، مثل app.botlify.io/bot/5de53dbf9b9bae002b319600 ، كان من الواضح أن معظم العمل سيكون في الواجهة الأمامية. ونتيجة لذلك ، تم تشكيل واجهة العمل على العميل في قائمة مهام وقائمة أمنيات ذات معنى:

إنشاء / العثور على مكتبة عميل ، وهو نوع من "المحركات" لبرامج الروبوت للدردشة في متصفح يفهم تعليمات json المستلمة ويحافظ على الحوار مع المستخدم.
قم بإنشاء تطبيق لتحرير عُقد الروبوتات ، والذي سيحفظ قائمة بالعُقد والروابط بينها في كائن json-object (تقوم مكتبة العميل على أساسه بإجراء حوارات).
, , , - . , , , . , , , ..

, , . id , :

<script defer src="https://app.botlify.io/botlify.min.js"
    onload="Botlify({ bot: '5de53dbf9b9bae002b319600', type: 'widget'})"
</script>

, , ( )

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

نهاية المقدمة

بالنسبة للجبهة ، نستخدم Reactjs . نحن نحزم كل شيء في Docker (نقوم ببنائه ودفعه في حاوية nginx) ، الرمز على Github في المستودعات الخاصة ، بالنسبة لـ CI نستخدم إجراءات Github . أطلقنا حاويات على خوادم VPS العادية مع نصوص bash بسيطة. لتبسيط تطوير واجهة المستخدم استغرق مخطط .

Web — javascript , - . json -, . -(, , , , , .).
Web — javascript . id , , Web- .
— , . json, -. , «» , — -.
حساب المستخدم - تطبيق ويب لإدارة حسابك واشتراكك وبرامج الروبوت.
اللوحة الإدارية هي تطبيق ويب للمسؤولين. إدارة المستخدمين ، وبرامج التتبُّع ، والاشتراكات ، ولوحات المعلومات مع التحليلات.

يوضح الرسم البياني أدناه مكونات الواجهة الأمامية وكيف تتفاعل مع بعضها البعض. يتم استخدام Webclient ومحرر bot فقط في سياق التطبيقات الأخرى ، بينما إذا تم استخدام المحرر فقط في تطبيقاتنا ، فيمكن أيضًا استخدام عميل الويب من قبل عملائنا كوحدة ويب. عند إنشاء المشروع ، تتم إضافة الحزم مع Webclient و Editor إلى تطبيقات لوحة المعلومات والمشرف. بالإضافة إلى ذلك ، تم تصميم وحدة الويب باستخدام webpack للتسليم للمستخدمين.

MVP 1. عميل ويب

بصفتنا شركة ناشئة ، نسعى دائمًا لتحقيق أقصى النتائج باستخدام الحد الأدنى من الموارد. يبدو لي أن الخطوة المنطقية إلى حد ما لأول MVP كانت إنشاء عميل ويب من وجهة نظر أنه يمثل "وجه المنتج" ، وأظهر نتيجة عمل المصمم ، وليس عملية إنشاء الروبوت - فنجان قهوة ، وليس آلة قهوة. من أجل تقليل وقت تطوير الحل ، قررنا البحث عن مكتبات مناسبة لطلباتنا ، وفجأة ، تم العثور عليها! lucasbassetti.com.br/react-simple-chatbot هو مكون رد فعل يغطي جميع احتياجاتنا تقريبًا!

اقترح هذا المكون وصف منطق chatbot في شكل مصفوفة من الخطوات ، وقراءة القيم التي أدخلها المستخدمون ، وتخصيص المظهر ، والتحقق من صحة البيانات ، وبدا مرنًا بما يكفي للبدء. يبدو أبسط وصف للخطوات كالتالي:

<ChatBot
      steps={[
        {
          id: '1',
          message: 'What is your name?',
          trigger: '2',
        },
        {
          id: '2',
          user: true,
          trigger: '3',
        },
        {
          id: '3',
          message: 'Hi {previousValue}, nice to meet you!',
          end: true,
        },
      ]}
    />

بدأنا بالمحاولة بهذه الطريقة لتأليف برنامج دردشة يقدم مشروعنا ، الذي كانت خريطته الذهنية على الشاشة في بداية المقالة. بالطبع ، تبين أن وصف هذا json يدويًا غير مريح إلى حد ما ، وكان عليّ كتابة الكثير من الوظائف المخصصة ، ولكن بشكل عام أعطت هذه العملية فهمًا لكيفية عمل المكون ، وكيفية تحقيق النتيجة المرجوة به.

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

MVP 2. مُنشئ

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

ابدأ - وحدة فنية تبدأ جلسة جديدة
نهاية - كتلة إنهاء الجلسة
رسالة - عند الوصول إلى الكتلة ، يرسل البوت الرسالة المحددة في نص الكتلة
— . ,

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

بعد فحص قصير للحلول المتاحة ، استقرنا على Rete.js (https://rete.js.org). تعرفت على الوثائق والأمثلة ووجدت فيها كل ما نحتاجه للبدء. حتى أنه كان لديهم مثال فقط مع روبوت دردشة ، والذي كان المشغل الأخير

Rete . . , — , JSON

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

تم تصميم Rete.js بطريقة يتم من خلالها توسيع وظائفه من خلال إنشاء عُقد وعناصر تحكم ومكونات مخصصة ، مما سمح لنا بالحصول بسرعة على الصورة التي أردنا رؤيتها تمامًا ، والتي أشكر منشئو Rete ! بالطبع ، من أهمها محرر جاهز!

كما هو مكتوبالتوثيق :

المحرر عبارة عن منطقة بها عُقد ووصلات بين مآخذ التوصيل. الخيارات التالية متاحة:

التفاعل مع مساحة العمل (نقل ، تحجيم) وإدارة العقدة (نقل ، إضافة ، حذف)
عرض الاتصالات والعقد ومدخلاتها / مخرجاتها وضوابطها
التعامل مع أحداث المحرر
مخطط الاستيراد / التصدير بتنسيق JSON
توسيع الوظائف مع الإضافات
تخصيص مساحة العمل والعقد والوصلات

بعد استحضار القليل مع Rete ودراسة أمثلة أكثر تفصيلاً ، تمكنا من إنشاء شيء سمح لنا بإنشاء وحذف الكتل "start" و "end" و "message" و "إدخال لوحة المفاتيح". في الإخراج ، تلقينا json مع وصف العقد والمقابس والخطوط التي تربطها.

أحد الإصدارات الأولى للمحرر

بالفعل شيء ما ، ولكن هذا لا يكفي ، لأن عميل الويب لدينا لا يفهم هذا json. إنه يحتاج إلى نوع خاص به ، مع وصف الخطوات. تقرر تضمين محول من تنسيق json إلى آخر في العميل.

محول Json

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

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

قم بتغيير المحرر ، أضف نوع العقدة المطلوب
نحن نعلم محول json لتحويل عقدة جديدة إلى خطوة جديدة
نعلم العميل للعمل بخطوة جديدة

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

حساب المستخدم

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

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

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

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

بعد إنشاء الخزانة ، أمضينا بعض الوقت في كتل جديدة في المحرر ومعالجتها من قبل العميل:

— . ( ),
— -
Email — email

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

النتائج؟

تمكنا من بناء النماذج الأولية والصفحات المقصودة بسرعة كبيرة. نعم ، لم يكن على الإطلاق ما يتخيله الكثيرون تحت ستار MVP. ولكن بعد أمسيتين فقط بعد ظهور الفكرة ، يمكننا البدء في عرضها على الناس واختبارها. الصفحات المقصودة والإعلانات والنصوص المختلفة في البوت - يمكننا اختبارها والبحث عنها. أوصي بشدة أن يفكر أي شخص يشارك في تطوير الشركات الناشئة في كيفية إنجاز الأمور في أسرع وقت ممكن. لقد صنعنا أول منتج لاستخراج القيمة في حوالي ثلاثة أشهر ، ثم بدأت عملية تدريجية للتحسين المنتظم. بالطبع ، لدينا الآن المزيد من الكتل داخل المنشئ ، أضفنا التحقق ، وأنواع البيانات ، وطلبات GET و POST ، والكثير من أي إعدادات تصميم وعرض ، ولكن يمكنك البدء بدون كل هذا ، وهو ما فعلناه.

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

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

كما فعلنا المصمم التالي لروبوتات الدردشة. الجزء الأول