قام فريق من المطورين بدمج OpenSearch مع SQLite FTS5، مما أدى إلى خفض عمليات البحث عن الفيديو التي لا تسفر عن نتائج من 11.4% إلى 2.1%، مع الحفاظ على زمن استجابة أقل من 20 مللي ثانية. الآن، عندما يكتب المستخدمون "blackpink jenny solo stag"، تظهر لهم النتيجة الصحيحة "BLACKPINK Jennie SOLO stage" بدلاً من قائمة فارغة.

لماذا كانت الحاجة للتغيير قائمة

أظهرت سجلات البحث في إحدى منصات استضافة الفيديو مشكلة متكررة: خطأ مطبعي واحد في عنوان مكتوب بالخط اللاتيني قد يؤدي إلى محو جميع النتائج المطابقة. إن ملحق FTS5 الخاص بـ SQLite، والمتميز بقدرته على مطابقة السلاسل الفرعية في النصوص الصينية واليابانية والكورية (CJK)، لا يدعم المطابقة التقريبية (fuzzy matching). فوجود حرف واحد مكتوب بشكل خاطئ في اسم أو عنوان أغنية يؤدي إلى تعطل الاستعلام بالكامل.

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

كيف تمت إضافة OpenSearch

يعمل OpenSearch كخدمة بحث في الخطوط الأمامية، بينما يظل SQLite هو المصدر الموثوق للبيانات (source of truth). يعمل النظامان بالتوازي: يستقبل OpenSearch استعلام المستخدم أولاً، وإذا استجاب بسرعة كافية، يتم عرض نتائجه. أما إذا انتهى وقت استجابة OpenSearch أو حدث خطأ، فيتم الرجوع إلى فهرس SQLite FTS5. يضمن تصميم "الأمان ضد الفشل" (fail-safe) هذا عدم ترك شريط البحث فارغاً أبداً بسبب خلل بسيط في الشبكة.

تعيين الحقول المتعددة

يتم فهرسة كل عنوان فيديو بثلاث طرق في OpenSearch:

  • title.std – تتم معالجته بواسطة محلل قياسي (standard analyzer) مع عملية طي رموز ASCII (ASCII folding). يقوم هذا بتوحيد الحروف التي تحتوي على علامات تشكيل ويتعامل مع معظم الأخطاء المطبعية في النصوص اللاتينية.
  • title.cjk – تتم معالجته بواسطة محلل CJK يقوم بإنشاء ثنائيات (bigrams) (رموز مكونة من حرفين). يحافظ هذا على قوة مطابقة السلاسل الفرعية التي يوفرها FTS5 للنصوص الآسيوية.
  • title.keyword – يتم تخزينه دون تغيير لعمليات البحث عن المطابقة التامة والفرز.

تسمح الحقول المنفصلة بتطبيق التحليل المناسب لكل نص دون خلط استراتيجيات تقسيم الرموز (tokenisation).

مستويات التعزيز

بدلاً من استخدام استعلام واحد ضخم، بنى الفريق استعلاماً متعدد المستويات يقوم بترتيب النتائج تلقائياً:

  1. مطابقات العبارات التامة في title.keyword تحصل على أعلى تعزيز (boost)، مما يضمن تصدر المطابقات المثالية للقائمة.
  2. مطابقات ثنائيات CJK في title.cjk تحصل على تعزيز متوسط، مما يحافظ على جودة عمليات البحث باللغات الآسيوية.
  3. المطابقات اللاتينية التقريبية في title.std تحصل على تعزيز أقل، مما يسمح بظهور النتائج المتسامحة مع الأخطاء المطبعية دون أن تطغى على النتائج المطابقة تماماً.

يجعل هذا النهج المتدرج عملية الضبط مباشرة: فتعديل قيمة تعزيز واحدة يغير الأهمية النسبية لفئة كاملة من المطابقات.

التقريب الذكي

التقريب (Fuzziness) — الذي يسمح بعدد محدود من التعديلات على الحروف — ينطبق فقط على الحقل اللاتيني. قام الفريق بتعطيل التقريب لـ title.cjk لأن تغيير حرف واحد في لغات CJK غالباً ما يغير المعنى تماماً. بالنسبة للنصوص اللاتينية، يستخدم الاستعلام إعداد التقريب AUTO في OpenSearch، والذي يضبط مسافة التعديل المسموح بها بناءً على طول الكلمة، محققاً التوازن بين التسامح مع الأخطاء ودقة الصلة.

الأداء ومنطق التراجع

تغلف روتين البحث استدعاء OpenSearch داخل كتلة try-catch:

  • إذا أعاد OpenSearch نتيجة في غضون 400 مللي ثانية، يتم عرض نتائجه.
  • إذا أطلق الاستدعاء استثناءً (exception) أو تجاوز وقت المهلة، يقوم النظام فوراً بإعادة تشغيل الاستعلام مقابل SQLite FTS5.

يضمن ذلك عدم تدهور تجربة المستخدم بسبب زمن استجابة الشبكة أو انقطاع الخدمة. ظل زمن استجابة البحث أقل من 20 مللي ثانية.

الأثر القابل للقياس

  • انخفضت معدلات البحث التي لا تسفر عن نتائج للاستعلامات بالخط اللاتيني من 11.4% إلى 2.1%.
  • ظلت جودة البحث لاستعلامات CJK دون تغيير، مما يؤكد أن محلل CJK الجديد حافظ على نقاط القوة في فهرس FTS5 الأصلي.
  • ظل زمن الاستجابة من البداية إلى النهاية (end-to-end latency) أقل بكثير من الهدف المحدد بـ 20 مللي ثانية، مما يعني أن الطبقة المضافة لم تبطئ واجهة المستخدم.

الدروس والمقايضات

  • فصل عملية الطي (folding) والتقريب (fuzziness) – تعالج عملية الطي (توحيد الحروف) والتقريب (التعامل مع الأخطاء المطبعية) مشكلات مختلفة. ويؤدي إبقاؤهما في حقول منفصلة إلى تجنب التفاعلات غير المقصودة.
  • لا تعامل فهرس البحث كمصدر موثوق للبيانات – يظل SQLite هو المخزن الأساسي؛ بينما OpenSearch هو عرض مشتق وقابل للتحديث. يمنع هذا انحراف الفهرس (index drift) ويسهل عملية الاسترداد بعد الفشل.
  • مستويات التعزيز تبسط عملية الضبط – يؤدي تجميع المطابقات ذات الصلة تحت عامل تعزيز واحد إلى تقليل عدد المعلمات التي تحتاج إلى ضبط.

ما يجب مراقبته لاحقاً

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