تقديم فهرس ميلفوس نغرام: مطابقة أسرع للكلمات المفتاحية واستعلامات مشابهة لأحمال عمل الوكلاء

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

تعكس أعباء العمل الحقيقية هذه الحاجة باستمرار:

• يجب على مساعدي دعم العملاء العثور على محادثات تشير إلى منتج أو مكون معين.

• يبحث مساعدو البرمجة عن مقتطفات تحتوي على اسم دالة أو استدعاء واجهة برمجة التطبيقات أو سلسلة أخطاء.

• كما يقوم الوكلاء القانونيون والطبيون والأكاديميون بتصفية المستندات بحثاً عن البنود أو الاقتباسات التي يجب أن تظهر حرفياً.

تقليديًا، تعاملت الأنظمة مع هذا الأمر باستخدام مشغل SQL LIKE. يعتبر الاستعلام مثل name LIKE '%rod%' بسيطًا ومدعومًا على نطاق واسع، ولكن في ظل التزامن العالي وأحجام البيانات الكبيرة، فإن هذه البساطة تحمل تكاليف أداء كبيرة.

• فبدون فهرس، يقوم استعلام LIKE بمسح مخزن السياق بأكمله وتطبيق مطابقة النمط صفًا بصف. عند وجود ملايين السجلات، يمكن أن يستغرق حتى استعلام واحد ثوانٍ - وهو بطيء جدًا بالنسبة لتفاعلات الوكيل في الوقت الفعلي.

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

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

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

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

ما هو فهرس نغرام؟

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

يمكن تجميع تعبيرات LIKE بشكل عام في أربعة أنواع أنماط شائعة، اعتمادًا على كيفية استخدام أحرف البدل:

• مطابقة إنفكس (name LIKE '%rod%'): يطابق السجلات التي يظهر فيها قضيب السلسلة الفرعية في أي مكان في النص.

• مطابقة البادئة (name LIKE 'rod%'): يطابق السجلات التي يبدأ نصها ب "قضيب".

• مطابقة لاحقة (name LIKE '%rod'): يطابق السجلات التي ينتهي نصها ب قضيب.

• مطابقة أحرف البدل (name LIKE '%rod%aab%bc_de'): يجمع بين شروط السلاسل الفرعية المتعددة (%) مع أحرف البدل ذات الحرف الواحد (_) في نمط واحد.

على الرغم من اختلاف هذه الأنماط في المظهر والتعبير، إلا أن فهرس نغرام في ميلفوس يسرّعها جميعًا باستخدام نفس النهج الأساسي.

قبل بناء الفهرس، يقسّم ميلفوس كل قيمة نصية إلى سلاسل فرعية قصيرة ومتداخلة ذات أطوال ثابتة، تُعرف باسم n-grams. على سبيل المثال، عندما تكون n = 3، تتحلل كلمة "Milvus" إلى 3 جرامات التالية: "Mil"، و "ilv"، و "lvu"، و "vus". ثم يتم تخزين كل n-gram في فهرس مقلوب يعيّن السلسلة الفرعية إلى مجموعة معرّفات المستندات التي تظهر فيها. في وقت الاستعلام، تُترجم شروط LIKE إلى مجموعات من عمليات البحث عن n-gram، مما يسمح لـ Milvus بتصفية معظم السجلات غير المطابقة بسرعة وتقييم النمط مقابل مجموعة مرشحة أصغر بكثير. وهذا ما يحول عمليات مسح السلاسل المكلفة إلى استعلامات فعالة قائمة على الفهرس.

تتحكم معلمتان في كيفية إنشاء فهرس Ngram: min_gram و max_gram. ويحددان معًا نطاق أطوال السلاسل الفرعية التي يقوم ميلفوس بتوليدها وفهرستها.

• min_gram: أقصر طول سلسلة فرعية للفهرسة. في الممارسة العملية، يحدد هذا أيضًا الحد الأدنى لطول السلسلة الفرعية للاستعلام التي يمكن أن تستفيد من فهرس Ngram

• max_gram: أطول طول سلسلة فرعية للفهرسة. في وقت الاستعلام، يُحدّد بالإضافة إلى ذلك الحد الأقصى لحجم النافذة المستخدمة عند تقسيم سلاسل الاستعلام الأطول إلى ن-غرامات.

من خلال فهرسة جميع السلاسل الفرعية المتجاورة التي تقع أطوالها بين min_gram و max_gram ، يؤسس ميلفوس أساسًا متسقًا وفعالًا لتسريع جميع أنواع الأنماط المدعومة LIKE.

كيف يعمل فهرس نغرام؟

يقوم ميلفوس بتنفيذ فهرس نغرام في عملية من مرحلتين:

• بناء الفهرس: توليد أنماط نغرام لكل مستند وبناء فهرس مقلوب أثناء استيعاب البيانات.

• تسريع الاستعلامات: استخدام الفهرس لتضييق نطاق البحث إلى مجموعة مرشحة صغيرة، ثم التحقق من التطابقات الدقيقة LIKE على تلك الملفات المرشحة.

مثال ملموس يسهّل فهم هذه العملية.

المرحلة 1: بناء الفهرس

حلل النص إلى ن-غرامات:

افترض أننا نقوم بفهرسة النص "Apple" بالإعدادات التالية:

• min_gram = 2

• max_gram = 3

في ظل هذا الإعداد، يُنشئ ميلفوس جميع السلاسل الفرعية المتجاورة ذات الطول 2 و3:

• 2-غرامات Ap ، pp ، pl, le

• 3 - جرامات: App ، ppl, ple

إنشاء فهرس مقلوب:

ضع في اعتبارك الآن مجموعة بيانات صغيرة مكونة من خمسة سجلات:

• المستند 0: Apple

• المستند 1: Pineapple

• المستند 2: Maple

• المستند 3: Apply

• المستند 4: المستند 4: Snapple

أثناء الاستيعاب، يُنشئ ميلفوس n-غرامات لكل سجل ويدرجها في فهرس مقلوب. في هذا الفهرس:

• المفاتيح هي ن-غرامات (سلاسل فرعية)

• القيم هي قوائم بمعرّفات المستندات التي يظهر فيها ن-غرام

"Ap"  -> [0, 3]
"App" -> [0, 3]
"Ma"  -> [2]
"Map" -> [2]
"Pi"  -> [1]
"Pin" -> [1]
"Sn"  -> [4]
"Sna" -> [4]
"ap"  -> [1, 2, 4]
"apl" -> [2]
"app" -> [1, 4]
"ea"  -> [1]
"eap" -> [1]
"in"  -> [1]
"ine" -> [1]
"le"  -> [0, 1, 2, 4]
"ly"  -> [3]
"na"  -> [4]
"nap" -> [4]
"ne"  -> [1]
"nea" -> [1]
"pl"  -> [0, 1, 2, 3, 4]
"ple" -> [0, 1, 2, 4]
"ply" -> [3]
"pp"  -> [0, 1, 3, 4]
"ppl" -> [0, 1, 3, 4]

الآن تم بناء الفهرس بالكامل.

المرحلة 2: تسريع الاستعلامات

عندما يتم تنفيذ فلتر LIKE ، يستخدم ميلفوس فهرس نغرام لتسريع تقييم الاستعلام من خلال الخطوات التالية:

1. استخراج مصطلح الاستعلام: يتم استخراج السلاسل الفرعية المتجاورة بدون أحرف البدل من التعبير LIKE (على سبيل المثال، '%apple%' يصبح apple).

2. تحليل مصطلح الاستعلام: يتحلل مصطلح الاستعلام إلى n-غرامات بناءً على طوله (L) والمكون min_gram و max_gram.

3. البحث عن كل غرام وتقاطعه: يبحث Milvus عن ن-غرامات الاستعلام في الفهرس المقلوب ويتقاطع مع قوائم معرّفات المستندات الخاصة بها لإنتاج مجموعة صغيرة مرشحة.

4. التحقق من النتائج وإرجاعها: يتم تطبيق شرط LIKE الأصلي فقط على هذه المجموعة المرشحة لتحديد النتيجة النهائية.

من الناحية العملية، تعتمد الطريقة التي يتم بها تقسيم الاستعلام إلى ن-غرامات على شكل النمط نفسه. لنرى كيف يعمل هذا، سنركّز على حالتين شائعتين: مطابقات اللواحق ومطابقات أحرف البدل. تتصرف مطابقات البادئة واللاحقة بنفس الطريقة التي تتصرف بها مطابقات اللواحق، لذا لن نتناولها بشكل منفصل.

مطابقة اللواحق

بالنسبة لمطابقة اللواحق، يعتمد التنفيذ على طول السلسلة الفرعية الحرفية (L) بالنسبة إلى min_gram و max_gram.

1. min_gram ≤ L ≤ max_gram (على سبيل المثال، strField LIKE '%ppl%')

تقع السلسلة الفرعية الحرفية ppl بالكامل ضمن نطاق n-gram المكوّن. يبحث Milvus مباشرةً عن n-gram "ppl" في الفهرس المقلوب، مما ينتج عنه معرفات المستندات المرشحة [0, 1, 3, 4].

ولأن الحرف الحرفي نفسه هو عبارة عن n-غرام مفهرس، فإن جميع المرشحين يستوفون بالفعل شرط اللواحق. لا تستبعد خطوة التحقق النهائية أي سجلات، وتبقى النتيجة [0, 1, 3, 4].

2. L > max_gram (على سبيل المثال، strField LIKE '%pple%')

تكون السلسلة الفرعية الحرفية pple أطول من max_gram ، لذلك يتم تحليلها إلى ن-غرامات متداخلة باستخدام حجم نافذة max_gram. مع max_gram = 3 ، ينتج عن ذلك ن-غرامات "ppl" و "ple".

يبحث ميلفوس عن كل n-غرام في الفهرس المقلوب:

• "ppl" → [0, 1, 3, 4]

• "ple" → [0, 1, 2, 4]

ينتج عن تقاطع هذه القوائم المجموعة المرشحة [0, 1, 4]. ثم يتم تطبيق مرشح LIKE '%pple%' الأصلي على هؤلاء المرشحين. يستوفي الثلاثة جميعًا الشرط، وبالتالي تظل النتيجة النهائية [0, 1, 4].

3. L < min_gram (على سبيل المثال، strField LIKE '%pp%')

تكون السلسلة الفرعية الحرفية أقصر من min_gram وبالتالي لا يمكن تحليلها إلى نغرامات ن مفهرسة. في هذه الحالة، لا يمكن استخدام فهرس Ngram، ويعود Milvus إلى مسار التنفيذ الافتراضي، حيث يقوم بتقييم الشرط LIKE من خلال مسح كامل مع مطابقة النمط.

مطابقة أحرف البدل (على سبيل المثال، strField LIKE '%Ap%pple%')

يحتوي هذا النمط على عدة أحرف بدل، لذا يقوم ميلفوس أولاً بتقسيمه إلى حروف متجاورة: "Ap" و "pple".

ثم يقوم ميلفوس بمعالجة كل حرف بشكل مستقل:

• "Ap" طوله 2 ويقع ضمن نطاق n-غرام.

• "pple" أطول من max_gram ويتحلل إلى "ppl" و "ple".

وهذا يقلل الاستعلام إلى ن-غرامات التالية:

• "Ap" → [0, 3]

• "ppl" → [0, 1, 3, 4]

• "ple" → [0, 1, 2, 4]

ينتج عن تقاطع هذه القوائم مرشح واحد: [0].

أخيرًا، يتم تطبيق مرشح LIKE '%Ap%pple%' الأصلي على المستند 0 ("Apple"). نظرًا لأنه لا يفي بالنمط الكامل، تكون مجموعة النتائج النهائية فارغة.

القيود والمقايضات في فهرس نغرام

في حين أن فهرس Ngram يمكن أن يحسّن أداء الاستعلام LIKE بشكل كبير، إلا أنه يقدم مقايضات يجب أخذها بعين الاعتبار في عمليات النشر في العالم الحقيقي.

• زيادة حجم الفهرس

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

• غير فعّال لجميع أعباء العمل

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

تقييم أداء فهرس Ngram على استعلامات LIKE

الهدف من هذا المعيار هو تقييم مدى فعالية فهرس Ngram في تسريع استعلامات LIKE عمليًا.

منهجية الاختبار

لوضع أدائه في سياقه، نقوم بمقارنته مع وضعين أساسيين للتنفيذ:

• الرئيسي: التنفيذ بالقوة الغاشمة دون أي فهرس.

• مقلوب رئيسي: التنفيذ باستخدام فهرس مقلوب تقليدي.

قمنا بتصميم سيناريوهين للاختبار لتغطية خصائص البيانات المختلفة:

• مجموعة بيانات Wiki النصية: 100,000 صف، مع اقتطاع كل حقل نصي إلى 1 كيلوبايت.

• مجموعة بيانات كلمة واحدة: 1,000,000 صف، حيث يحتوي كل صف على كلمة واحدة.

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

• تستخدم الاستعلامات نمط المطابقة اللواحق (%xxx%)

• يتم تكوين فهرس Ngram باستخدام min_gram = 2 و max_gram = 4

• لعزل تكلفة تنفيذ الاستعلام وتجنب النفقات الزائدة لتجسيد النتائج، تقوم جميع الاستعلامات بإرجاع count(*) بدلاً من مجموعات النتائج الكاملة.

النتائج

اختبار للويكي، كل سطر عبارة عن نص ويكي مع اقتطاع طول المحتوى بمقدار 1000، 100 ألف صف

	حرفي	الوقت (مللي ثانية)	السرعة	العد
ماجستير	الملعب	207.8		335
ملعب رئيسي مقلوب		2095		335
نغرام		1.09	190 / 1922	335
ماجستير	مدرسة ثانوية	204.8		340
ماجستير مقلوب		2000		340
نغرام		1.26	162.5 / 1587	340
ماستر	هي مدرسة ثانوية مختلطة ذات نظام تعليمي مختلط، مدرسة ثانوية راعية	223.9		1
ماستر مقلوب		2100		1
نغرام		1.69	132.5 / 1242.6	1

اختبار للكلمات المفردة، 1 مليون صف

	حرفي	الوقت (مللي ثانية)	تسريع	العد
الرئيسي	نا	128.6		40430
سيد مقلوب		66.5		40430
نغرام		1.38	93.2 / 48.2	40430
ماجستير	نات	122		5200
سيد مقلوب		65.1		5200
نغرام		1.27	96 / 51.3	5200
ماجستير	ناتي	118.8		1630
سيد مقلوب		66.9		1630
نغرام		1.21	98.2 / 55.3	1630
ماجستير	ناتو	118.4		1100
سيد مقلوب		65.1		1100
نغرام		1.33	89 / 48.9	1100
ماجستير	الأمة	118		1100
سيد مقلوب		63.3		1100
نغرام		1.4	84.3 / 45.2	1100

ملاحظة: تستند هذه النتائج إلى معايير أجريت في مايو/أيار. منذ ذلك الحين، خضع الفرع الرئيسي إلى تحسينات إضافية على الأداء، لذا من المتوقع أن تكون فجوة الأداء الملحوظة هنا أصغر في الإصدارات الحالية.

تُبرز النتائج المعيارية نمطًا واضحًا: يُسرّع فهرس Ngram استعلامات LIKE بشكل كبير في جميع الحالات، وتعتمد سرعة أداء الاستعلامات بشكل كبير على بنية وطول البيانات النصية الأساسية.

• بالنسبة للحقول النصية الطويلة، مثل المستندات على غرار ويكي التي تم اقتطاعها إلى 1,000 بايت، فإن مكاسب الأداء تكون واضحة بشكل خاص. فمقارنةً بالتنفيذ بالقوة الغاشمة مع عدم وجود فهرس، يحقق فهرس Ngram تسريعًا يتراوح بين 100-200 مرة تقريبًا. وعند مقارنته بالفهرس المقلوب التقليدي، يكون التحسن أكثر دراماتيكيةً، حيث يصل إلى 1,200-1,900×. ويرجع ذلك إلى أن الاستعلامات المماثلة على النصوص الطويلة مكلفة بشكل خاص بالنسبة لمقاربات الفهرسة التقليدية، في حين أن عمليات البحث عن نغرام يمكن أن تضيّق مساحة البحث بسرعة إلى مجموعة صغيرة جدًا من المرشحين.

• في مجموعات البيانات التي تتألف من إدخالات من كلمة واحدة، تكون المكاسب أقل لكنها تظل كبيرة. في هذا السيناريو، يعمل فهرس نغرام أسرع بحوالي 80-100 ضعف تقريب ًا من التنفيذ بالقوة الغاشمة وأسرع بـ45-55 ضعفًا من الفهرس المقلوب التقليدي. على الرغم من أن النص الأقصر أرخص بطبيعته في المسح الضوئي، إلا أن النهج القائم على n-gram لا يزال يتجنب المقارنات غير الضرورية ويقلل من تكلفة الاستعلام باستمرار.

الخلاصة

يعمل فهرس Ngram على تسريع الاستعلامات LIKE من خلال تقسيم النص إلى نغرامات ذات طول ثابت وفهرستها باستخدام بنية مقلوبة. يحول هذا التصميم مطابقة السلاسل الفرعية المكلفة إلى عمليات بحث فعالة عن نغرام متبوعة بالحد الأدنى من التحقق. ونتيجة لذلك، يتم تجنب عمليات مسح النص الكامل بينما يتم الحفاظ على الدلالات الدقيقة لـ LIKE.

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

في الوقت نفسه، يستفيد فهرس Ngram من التكوين الدقيق. اختيار القيم المناسبة min_gram و max_gram أمر بالغ الأهمية لتحقيق التوازن بين حجم الفهرس وأداء الاستعلام. عندما يتم ضبطه ليعكس أنماط الاستعلام الحقيقية، يوفر فهرس نغرام حلاً عملياً وقابلاً للتطوير للاستعلامات عالية الأداء LIKE في أنظمة الإنتاج.

لمزيد من المعلومات حول فهرس نغرام، راجع الوثائق أدناه:

• وثائق فهرس نغرام | وثائق ميلفوس

هل لديك أسئلة أو تريد التعمق في أي ميزة من أحدث إصدار من ميلفوس؟ انضم إلى قناة ديسكورد الخاصة بنا أو قم بتسجيل المشاكل على GitHub. يمكنك أيضًا حجز جلسة فردية مدتها 20 دقيقة للحصول على رؤى وإرشادات وإجابات لأسئلتك من خلال ساعات عمل ميلفوس المكتبية.

تعرف على المزيد حول ميزات Milvus 2.6

• تقديم ميلفوس 2.6: بحث متجه ميسور التكلفة على نطاق المليار

• تقديم وظيفة التضمين: كيف يعمل ملفوس 2.6 على تبسيط عملية البحث في المتجهات والبحث الدلالي

• تمزيق JSON في ميلفوس: تصفية JSON أسرع ب 88.9 مرة مع المرونة

• فتح الاسترجاع الحقيقي على مستوى الكيان: مصفوفة جديدة من الهياكل وقدرات MAX_SIM في ميلفوس

• الجمع بين التصفية الجغرافية المكانية والبحث في المتجهات مع الحقول الهندسية وRTREE في ملفوس 2.6

• تقديم AISAQ في Milvus: أصبح البحث عن المتجهات بمليارات النطاقات أرخص ب 3,200 مرة على الذاكرة

• تحسين NVIDIA CAGRA في Milvus: نهج هجين بين وحدة معالجة الرسومات ووحدة المعالجة المركزية للفهرسة الأسرع والاستعلامات الأرخص

• MinHash LSH في Milvus: السلاح السري لمكافحة التكرارات في بيانات تدريب LLM

• الارتقاء بضغط المتجهات إلى أقصى الحدود: كيف يخدم ميلفوس 3 أضعاف الاستعلامات باستخدام RaBitQ

• تكذب المعايير - قواعد بيانات المتجهات تستحق اختبارًا حقيقيًا

• استبدلنا كافكا/بولسار بنقار الخشب في ميلفوس