ماذا لو كان بإمكانك دمج نماذج ترتيب التعلم الآلي المعقدة مباشرة في محرك البحث الخاص بك، متجاوزًا تمامًا خدمات الاستدلال الخارجية وزمن الاستجابة الشبكي المرتبط بها؟ هذا بالضبط ما حققه المطورون في Swiggy لاقتراحات الإكمال التلقائي الخاصة بهم، متجاوزين القواعد الثابتة لتقديم نتائج أكثر ملاءمة بشكل كبير بسرعات أقل من ميلي ثانية. لا يتعلق الأمر بمجرد إنشاء كود AI؛ بل يتعلق بإعادة التفكير جوهريًا في كيفية دمج أدوات AI في تجارب المنتجات الأساسية، مما يجعلها أسرع وأذكى.
لفترة طويلة، كان بناء نظام إكمال تلقائي ذكي حقًا يبدو بمثابة مقايضة لمطوري البرمجيات. يمكنك الحصول على استجابات سريعة جدًا بالاعتماد على المطابقة المعجمية الأساسية ومجموعة من القواعد الثابتة التي تم ضبطها بعناية. أو، يمكنك استهداف الملاءمة المعقدة باستخدام التعلم الآلي، ولكن هذا يعني عادةً تقديم خدمات إضافية، وقفزات شبكية، وزمن الاستجابة الذي لا مفر منه الذي يأتي مع محرك استدلال خارجي. زمن الاستجابة هذا مؤلم بشكل خاص للإكمال التلقائي، حيث يتطلب كل ضغطة مفتاح اقتراحًا فوريًا وملائمًا.
غالبًا ما أجبر هذا النهج التقليدي المطورين على تقديم تنازلات. قد يقضي فريق الهندسة أسابيع، بل أشهر، في تحسين القواعد التجريبية، وضبط الأوزان، وصيانة منطق معقد للتعامل مع الحالات الهامشية – وهي عملية هشة وتستغرق وقتًا طويلاً.
عندما تم تقديم نموذج ML، كان عادةً ما يعيش خارج محرك البحث الأساسي، ويتطلب خط أنابيب نشر خاص به، واعتبارات التوسع، ونقطة نهاية API. أضاف هذا تعقيدًا معماريًا كبيرًا، وغالبًا ما حول ما ينبغي أن يكون استعلام بحث بسيط إلى تحدي تنسيق متعدد الخدمات. كان التأثير على العمل اليومي لمطور البرمجيات واضحًا: المزيد من البنية التحتية للإدارة، والمزيد من نقاط الفشل المحتملة، ووقت أقل للتركيز على المشكلة الأساسية للملاءمة.
اكتشاف Swiggy يتجاوز هذه المعضلة تمامًا. من خلال دمج نموذج ترتيب متعلم مباشرة داخل OpenSearch، فقد قاموا بدمج العملية التقليدية المكونة من مرحلتين ‘استرداد ثم ترتيب’ في عملية محسّنة للغاية داخل المحرك. هذا يعني أن نفس النماذج القوية المستخدمة للترتيب المتقدم يمكنها الآن العمل جنبًا إلى جنب مع توليد المرشح الأولي داخل OpenSearch نفسه.
بالنسبة لمطور البرمجيات، يترجم هذا إلى بنية مبسطة، وتقليل كبير في زمن الاستجابة، والقدرة على تكرار ونشر نماذج التعلم الآلي بنفس المرونة التي قد يطبقونها على تكوينات فهرس البحث. إنه يمكّنهم من بناء تجارب بحث تكيفية وذكية حقًا دون عبء معماري نموذجي.
ضع في اعتبارك سير العمل النموذجي لمطور برمجيات مكلف بتحسين ملاءمة الإكمال التلقائي:
قبل دمج ML مباشرة في OpenSearch:
سيقوم المطور بتكوين OpenSearch للاسترداد المعجمي الأولي، مما يضمن توليد مرشح سريع. إذا أرادوا تطبيق التعلم الآلي، فإنهم سيبنون بعد ذلك خدمة منفصلة، ربما تطبيق Python يستضيف نموذج XGBoost. ستتلقى هذه الخدمة المرشحين الأوليين، وستستعلم من مخزن الميزات للإشارات في الوقت الفعلي، وستطبق نموذج ML، وستعيد ترتيب النتائج قبل إعادتها. هذه الرحلة ذهابًا وإيابًا، بما في ذلك زمن الاستجابة للشبكة ووقت الاستدلال، يمكن أن تضيف بسهولة 20-50 ميلي ثانية لكل ضغطة مفتاح – وهو ما يكفي للشعور بالبطء للمستخدم. الوقت المستغرق سيكون في إدارة نظامين منفصلين وعقدة الشبكة بينهما.
بعد دمج ML مباشرة في OpenSearch مع LTR:
لا يزال المطور يتعاون
موجز الذكاء الاصطناعي الأسبوعي لمهنتك
بريد واحد أسبوعيًا: تغييرات الذكاء الاصطناعي التي تمسّ مهنتك فعلًا — أدوات وعروض وما يجب فعله.
