الانتقال من IPSoft Amelia إلى Amazon Lex V2: دليل ميداني

تتعثر معظم برامج الانتقال من Amelia إلى Lex للسبب نفسه: تبدأ الفرق بالروبوت الجديد بدل المنظومة القديمة. فالمساعد الافتراضي الذي عمل سنوات يراكم سلوكًا غير موثق — قواعد تصعيد تسكن في الإعدادات، ومنطق أعمال مخبأ في طبقات التكامل، ومسارات لم يملكها أحد منذ رحيل فريق المورّد الأول.

ابدأ بحصر سلوكي

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

صمّم على قياس Lex ولا تترجم حرفيًا

ليس Lex V2 هدفًا للنقل واحدًا بواحد. فحدود الروبوتات واللغات والقصود تكافئ التصميم المعياري: روبوتات بقصود مشتركة للمهام العامة (التحقق، الاستعلام عن الوثيقة) تُركَّب خلف طبقة تنسيق بـLambda، بدل روبوت ضخم لكل خط أعمال. وهنا أيضًا تصلح عشر سنوات من تضخم القصود — بدمج المتشابهات بينما تعمل حزمة اختبار الانحدار على السلوك القديم كمرجع.

انتقل على دفعات وتحقق بالتوازي

الإصدارات المرحلية مع التشغيل المتوازي — القديم وLex يخدمان الحركة جنبًا إلى جنب لكل مسار — تحوّل الانتقال المخيف إلى تقويم إصدارات اعتيادي. واختبارات الانحدار الحوارية (إعادة تشغيل مجموعات العبارات مع كل إصدار) تلتقط انحراف القصود قبل العملاء. الوضع المستقر الذي نستهدفه دورة إصدار كل أسبوعين: دفعات صغيرة ونشر بلا مفاجآت.

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