تكوين تسجيل نقاط صلة BM25

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

ينطبق BM25 على:

  • الاستعلامات التي تستخدم المعلمة search للبحث عن النص الكامل، على الحقول النصية searchable التي لها إسناد.
  • يتم تحديد نطاق التسجيل إلى searchFields، أو إلى كافة searchable الحقول إذا كانت searchFields خالية.

يستخدم محرك البحث BM25 لحساب @searchScore لكل تطابق في استعلام معين. يتم ترتيب المستندات المطابقة حسب نقاط البحث الخاصة بها، مع إرجاع أفضل النتائج في استجابة الاستعلام. من الممكن الحصول على بعض تباين النقاط في النتائج، حتى من نفس الاستعلام الذي ينفذ على نفس فهرس البحث، ولكن عادة ما تكون هذه الاختلافات صغيرة ولا تغير الترتيب العام للنتائج.

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

خوارزمية تسجيل النقاط الافتراضية

اعتمادا على عمر خدمة البحث، يدعم Azure الذكاء الاصطناعي Search خوارزميتين لتسجيل النقاط لاستعلام بحث نصي كامل:

  • خوارزمية Okapi BM25 (بعد 15 يوليو 2020)
  • خوارزمية التشابه الكلاسيكية (قبل 15 يوليو 2020)

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

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

تعيين معلمات BM25

يوفر ترتيب BM25 معلمتين لضبط حساب نقاط الصلة.

  1. استخدم طلب إنشاء أو تحديث الفهرس لتعيين معلمات BM25:

    PUT [service-name].search.windows.net/indexes/[index-name]?api-version=2020-06-30&allowIndexDowntime=true
    {
        "similarity": {
            "@odata.type": "#Microsoft.Azure.Search.BM25Similarity",
            "b" : 0.75,
            "k1" : 1.2
        }
    }
    
  2. إذا كان الفهرس مباشرا، فلحق معلمة allowIndexDowntime=true URI بالطلب، الموضحة في المثال السابق.

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

  3. قم بتعيين "b" و "k1" إلى قيم مخصصة، ثم أرسل الطلب.

    الخاصية النوع ‏‏الوصف
    k1 رقم يتحكم في دالة التحجيم بين مصطلح تكرار كل مصطلحات مطابقة لدرجة الصلة النهائية لزوج استعلام المستند. عادة ما تكون القيم من 0.0 إلى 3.0، مع 1.2 كافتراضي.

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

    يعد استخدام قيمة k1 أكبر أمرا مهما في الحالات التي يتم فيها تضمين مصطلحات متعددة في استعلام بحث. في هذه الحالات، قد ترغب في تفضيل المستندات التي تطابق المزيد من مصطلحات الاستعلام، على المستندات التي تطابق مصطلحا واحدا فقط، عدة مرات. على سبيل المثال، عند الاستعلام عن مصطلح "Apollo Spaceflight"، قد تحتاج إلى خفض درجة مقالة حول الأساطير اليونانية التي تحتوي على مصطلح "أبولو" بضع عشرات المرات، دون ذكر "Spaceflight"، بالنسبة لمقالة أخرى تذكر صراحة كل من "أبولو" و"Spaceflight" عدد قليل من المرات فقط.
    ب رقم يتحكم في كيفية تأثير طول المستند على درجة الصلة. تتراوح القيم بين 0 و1، مع 0.75 كقيمة افتراضية.

    تعني القيمة 0.0 أن طول المستند لا يؤثر على النتيجة. تعني القيمة 1.0 أن تأثير تكرار المصطلح على درجة الصلة يتم تسويته حسب طول المستند.

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

تمكين تسجيل BM25 على الخدمات القديمة

إذا كنت تقوم بتشغيل خدمة بحث تم إنشاؤها من مارس 2014 إلى 15 يوليو 2020، يمكنك تمكين BM25 عن طريق تعيين خاصية "التشابه" على الفهارس الجديدة. يتم عرض الخاصية فقط على الفهارس الجديدة، لذلك إذا كنت تريد BM25 على فهرس موجود، يجب إسقاط وإعادة إنشاء الفهرس مع تعيين خاصية "التشابه" إلى Microsoft.Azure.Search.BM25Similarity.

بمجرد وجود فهرس بخاصية "التشابه"، يمكنك التبديل بين BM25Similarity أو ClassicSimilarity.

تصف الارتباطات التالية خاصية التشابه في Azure SDKs.

مكتبة العميل خاصية التشابه
.NET SearchIndex.Similarity
Java SearchIndex.setSimilarity
JavaScript SearchIndex.Similarity
Python خاصية التشابه على SearchIndex

مثال REST

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

PUT [service-name].search.windows.net/indexes/[index name]?api-version=2020-06-30
{
    "name": "indexName",
    "fields": [
        {
            "name": "id",
            "type": "Edm.String",
            "key": true
        },
        {
            "name": "name",
            "type": "Edm.String",
            "searchable": true,
            "analyzer": "en.lucene"
        },
        ...
    ],
    "similarity": {
        "@odata.type": "#Microsoft.Azure.Search.BM25Similarity"
    }
}

(راجع أيضًا )