Бөлісу құралы:

Релевантность в поиске ключевое слово (оценка BM25)

  • Мақала

В этой статье объясняется алгоритм оценки релевантности BM25, используемый для вычисления показателей поиска для полнотекстового поиска. Релевантность BM25 является эксклюзивной для полнотекстового поиска. Фильтрация запросов, автозаполнение и предлагаемые запросы, дикие карта поисковые или нечеткие поисковые запросы не оцениваются или ранжируются по релевантности.

Алгоритмы оценки, используемые в полнотекстовом поиске

Поиск ИИ Azure предоставляет следующие алгоритмы оценки для полнотекстового поиска:

Алгоритм Использование Диапазон
BM25Similarity Исправлен алгоритм для всех служб поиска, созданных после июля 2020 года. Этот алгоритм можно настроить, но вы не можете переключиться на более старый (классический). Неограниченными.
ClassicSimilarity Присутствует в старых службах поиска. Вы можете принять участие в BM25 и выбрать алгоритм на основе индекса. 0 < 1.00

BM25 и Classic — это функции извлечения TF-IDF, которые используют частоту терминов (TF) и обратную частоту документа (IDF) в качестве переменных для вычисления показателей релевантности для каждой пары запросов к документу, которая затем используется для ранжирования результатов. Хотя концептуально похоже на классический, BM25 коренится в вероятностном получении информации, которая создает более интуитивно понятные совпадения, как измеряется исследованием пользователей.

BM25 предлагает расширенные параметры настройки, например разрешить пользователю решить, как масштабируются оценки релевантности с частотой соответствующих терминов. Дополнительные сведения см. в разделе "Настройка алгоритма оценки".

Примечание.

Если вы используете службу поиска, созданную до июля 2020 года, алгоритм оценки, скорее всего, является предыдущим значением по умолчанию, ClassicSimilarityкоторый можно обновить на основе индекса. Дополнительные сведения см. в разделе "Включение оценки BM25" в старых службах .

Следующий сегмент видео быстрое перемещение вперед объяснения общедоступных алгоритмов ранжирования, используемых в службе "Поиск ИИ Azure". Дополнительные сведения можно получить, просмотрев полное видео.

Как работает ранжирование BM25

Оценка релевантности относится к вычислению оценки поиска (@search.score), которая служит индикатором релевантности элемента в контексте текущего запроса. Диапазон не связан. Тем не менее, чем выше оценка, тем более релевантный элемент.

Оценка поиска вычисляется на основе статистических свойств строковых входных данных и самого запроса. Поиск ИИ Azure находит документы, соответствующие условиям поиска (некоторые или все в зависимости от searchMode), предпочитающие документы, содержащие множество экземпляров термина поиска. Оценка поиска возрастает, если условие поиска редко встречается в индексе данных, но часто — внутри документа. Основу для такого подхода к вычислению релевантности называют TF-IDF или частотой условия — инверсная частота в документе.

Оценки поиска могут повторяться в результирующем наборе. Если несколько попаданий имеют одну и ту же оценку поиска, порядок одного и того же оцененного элемента не определен и не является стабильным. Запустите запрос еще раз, и вы можете увидеть положение смены элементов, особенно если вы используете бесплатную службу или оплачиваемую службу с несколькими реплика. Учитывая два элемента с одинаковым показателем, нет никакой гарантии того, что он отображается в первую очередь.

Чтобы разорвать галстук среди повторяющихся показателей, можно добавить предложение $orderby в первый заказ по оценке, а затем упорядочить по другому сортируемому полю (например, $orderby=search.score() desc,Rating desc). Дополнительные сведения см. в статье Синтаксис $orderby OData в Когнитивном поиске Azure.

Для оценки используются только поля, помеченные как searchable индекс или searchFields в запросе. В результатах поиска возвращаются только поля, помеченные как retrievableполя, указанные в select запросе, вместе с оценкой поиска.

Примечание.

@search.score = 1 указывает на результирующий набор без оценивания или без ранжирования. Оценка одинакова для всех результатов. Результаты без оценки возникают, когда форма запроса является нечетким поиском, диким карта или регулярными запросами или пустым поиском (search=*иногда сопряжен с фильтрами, где фильтр является основным средством для возврата совпадения).

Оценки в текстовых результатах

Каждый раз, когда результаты ранжируются, свойство содержит значение, @search.score используемое для упорядочивания результатов.

В следующей таблице определяется свойство оценки, возвращаемое для каждого совпадения, алгоритма и диапазона.

Метод поиска Параметр Алгоритм оценки Диапазон
полнотекстовый поиск @search.score Алгоритм BM25 с использованием параметров, указанных в индексе. Неограниченными.

Вариант оценки

Показатели поиска дают общее представление о релевантности, отражающее качество совпадений относительно других документов в том же результирующем наборе. Но оценки не всегда согласованы с одним запросом к следующему, поэтому при работе с запросами можно заметить небольшие несоответствия в том, как упорядочены документы поиска. Существует несколько объяснений, почему это может произойти.

Причина Description
Идентичные результаты Если несколько документов имеют одинаковый рейтинг, то один из них может появиться первым.
Изменчивость данных Содержимое индекса меняется по мере того, как вы добавляете, изменяете или удаляете документы. Частота терминов изменяется при обработке обновлений индекса с течением времени, что влияет на показатели поиска соответствующих документов.
Несколько реплик Для служб, использующих несколько реплик, запросы к каждой реплике выдаются параллельно. Статистика индекса, используемая для вычисления оценки показателей поиска, вычисляется отдельно для каждой реплики, а результаты объединяются и упорядочиваются в ответе на запрос. Реплики в основном являются зеркальным отражением друг друга, но статистика может отличаться из-за наличия небольших различий. Например, одна реплика могла удалить документы, участвующие в статистике, которые были объединены из других реплик. Как правило, различия в статистике на каждую реплику более заметны в небольших индексах. В следующем разделе приведены дополнительные сведения об этом условии.

Влияние сегментирования на результаты запроса

Сегмент — это блок индекса. Поиск ИИ Azure подразделяет индекс на сегменты , чтобы ускорить процесс добавления секций (путем перемещения сегментов в новые единицы поиска). В службе поиска управление сегментами — это сведения о реализации и неконфигурируемые, но зная, что индекс сегментирован, помогает понять случайные аномалии в поведении ранжирования и автозаполнения:

  • Аномалии с ранжированием: рейтинг поиска сначала рассчитывается на уровне сегментов, а затем объединяется в результирующий набор. В зависимости от особенностей содержимого сегментов совпадения из одного сегмента могут ранжироваться выше, чем из другого. Если вы заметите счетчик интуитивно понятных ранжирований в результатах поиска, скорее всего, это связано с эффектами сегментирования, особенно если индексы малы. Чтобы избежать подобных аномалий, перейдите на глобальный расчет рейтингов по всему индексу, но это приведет к снижению производительности.

  • Аномалии с автозаполнением: запросы автозаполнения, где совпадения подбираются по первым нескольким символам частично введенного ключевого слова, принимают параметр нечеткого соответствия, который допускает небольшие отклонения в написании. Для автозаполнения нечеткие совпадения возможны только по терминам в пределах текущего сегмента. Например, если сегмент содержит "Майкрософт" и частичный термин "micro", поисковая система будет соответствовать в этом сегменте, но не в других сегментах, которые содержат оставшиеся части индекса.

На схеме ниже показана связь между репликами, секциями, сегментами и единицами поиска. В этом примере один индекс состоит из четырех единиц поиска с двумя репликами и двумя секциями в службе. В каждой из четырех единиц поиска хранится только половина сегментов индекса. В единицах поиска в левом столбце хранится первая половина сегментов, составляющая первую секцию, в то время как в правом столбце отражена вторая половина сегментов, т. е. вторая секция. Поскольку реплики две, у каждого сегмента индекса по две копии. В единицах поиска в верхней строке хранится одна копия, составляющая первую реплику, а в нижней строке — вторая копия, представляющая вторую реплику.

Индексы поиска распределены по сегментам между секциями.

На схеме выше показан лишь один пример конфигурации. Поддерживаются различные сочетания секций и реплик — всего до 36 единиц поиска.

Примечание.

Количество реплик и секций должно быть делителем 12 (а именно 1, 2, 3, 4, 6, 12). Поиск по искусственному интеллекту Azure предварительно делит каждый индекс на 12 сегментов, чтобы его можно было распределять по равным частям по всем секциям. Например, если в вашей службе есть три секции и вы создаете индекс, то каждая секция будет содержать по четыре сегмента индекса. Как поиск azure AI сегментирует индекс является подробным описанием реализации, при условии изменения в будущих выпусках. Несмотря на то, что сегодня это число 12, вам не следует полагаться на то, что в будущем оно не изменится.

Статистика оценки и прикрепленные сеансы

Для масштабируемости поиск ИИ Azure распределяет каждый индекс по горизонтали через процесс сегментирования, что означает, что части индекса физически отделены.

По умолчанию оценка документа вычисляется на основе статистических свойств данных в сегменте. Этот подход, как правило, не является проблемой для большого объема данных. Он обеспечивает лучшую производительность, чем вычисление оценки на основе информации по всем сегментам. Тем не менее, использование этой оптимизации производительности может привести к тому, что два очень похожих (или даже идентичных) документа будут иметь разные оценки релевантности, если они окажутся в разных сегментах.

Если вы предпочитаете вычислить оценку на основе статистических свойств для всех сегментов, это можно сделать, добавив scoringStatistics=global в качестве параметра запроса (или добавьте "scoringStatistics": "global" в качестве основного параметра запроса).

POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2023-11-01
{
    "search": "<query string>",
    "scoringStatistics": "global"
}

Использование scoringStatistics гарантирует, что все сегменты в одном реплика предоставляют одинаковые результаты. Тем не более чем разные реплика могут немного отличаться друг от друга, так как они всегда обновляются с последними изменениями в индексе. В некоторых случаях вам может потребоваться, чтобы пользователи во время "сеанса запроса" получали более согласованные результаты. В таких случаях вы можете предоставить sessionId как часть запросов. sessionId является уникальной строкой, которую вы создаете для ссылки на уникальный сеанс пользователя.

POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2023-11-01
{
    "search": "<query string>",
    "sessionId": "<string>"
}

До тех пор, пока используется то же sessionId самое, рекомендуется предпринять попытку нацелиться на ту же реплика, что повышает согласованность результатов, которые будут видеть ваши пользователи.

Примечание.

Повторное использование одних и тех же значений sessionId может повлиять на балансировку нагрузки запросов по репликам, а также негативно повлиять на производительность службы поиска. Значение, используемое в качестве sessionId, не может начинаться с символа "_".

Настройка релевантности

В службе "Поиск ИИ Azure" можно настроить параметры алгоритма BM25 и настроить релевантность поиска и повысить оценку поиска с помощью следующих механизмов:

Подход Внедрение Description
Настройка алгоритма оценки Поиск индекса
Профили повышения Поиск индекса Укажите критерии повышения оценки поиска соответствия на основе характеристик контента. Например, может, вам нужно повысить приоритет совпадений на основе потенциального дохода, повысить уровень более новых элементов или, возможно, элементов, которые слишком долго находились на складе. Профиль повышения — часть определения индекса, состоящая из взвешенных полей, функций и параметров. Можно обновить существующий индекс с изменениями профиля оценки без перестроения индекса.
Семантическое ранжирование Запрос запроса Применяет понимание машинного чтения к результатам поиска, повышая семантику релевантные результаты в верхней части.
Параметр featuresMode Запрос запроса Этот параметр в основном используется для распаковки оценки, но его можно использовать в коде, который предоставляет пользовательское решение оценки.

Параметр featuresMode (предварительная версия)

Запросы документов поиска имеют новый параметр featuresMode , который может предоставить дополнительные сведения о релевантности на уровне поля. В то время как @searchScore вычисляется для всего документа (насколько этот документ является релевантным в контексте этого запроса), с помощью параметра featuresMode можно получать сведения об отдельных полях, как указано в структуре @search.features. В этой структуре содержатся все поля, используемые в запросе (определенные поля используются с помощью конструкции searchFields из запроса или все поля с атрибутом доступные для поиска в индексе). Для каждого поля можно получить следующие значения:

  • Число уникальных токенов, найденных в поле
  • Оценка подобия или мера того, насколько содержимое поля сходно с термином из запроса
  • Частота термина или количество раз, когда термин из запроса был найден в поле

Для запроса, предназначенного для полей "description" (описание) и "title" (заголовок), ответ, который содержит @search.features, может выглядеть следующим образом:

"value": [
 {
    "@search.score": 5.1958685,
    "@search.features": {
        "description": {
            "uniqueTokenMatches": 1.0,
            "similarityScore": 0.29541412,
            "termFrequency" : 2
        },
        "title": {
            "uniqueTokenMatches": 3.0,
            "similarityScore": 1.75451557,
            "termFrequency" : 6
        }
    }
 }
]

Вы можете использовать эти величины в пользовательских решениях оценки или применить эту информацию для отладки проблем, связанных с релевантностью поиска.

Число ранжированных результатов в ответе полнотекстового запроса

По умолчанию, если вы не используете разбиение на страницы, поисковая система возвращает 50 самых высоких совпадений для полнотекстового поиска. Параметр можно использовать top для возврата меньшего или большего числа элементов (до 1000 в одном ответе). Полнотекстовый поиск имеет максимальное ограничение в 1000 совпадений (см . ограничения ответа API). После того как найдены 1000 совпадений, поисковая система больше не ищет.

Чтобы вернуть больше или меньше результатов, используйте параметры topразбиения по страницам и skipnext. Разбиение на страницы — это определение количества результатов на каждой логической странице и переход по полной полезных данных. Дополнительные сведения см. в статье "Работа с результатами поиска".

См. также