Оценка релевантности в гибридном поиске с помощью RRF

Статья
10/01/2024

Взаимное ранжирование Fusion (RRF) — это алгоритм, который оценивает оценки поиска из нескольких, ранее ранжированных результатов для создания единого результирующего набора. В службе "Поиск ИИ Azure" RRF используется всякий раз, когда существует два или более запросов, которые выполняются параллельно. Каждый запрос создает ранжированный результирующий набор, а RRF используется для объединения и гомгенизации ранжирования в одном результирующем наборе, возвращаемом в ответе запроса. Примеры сценариев, в которых RRF всегда используется, включают гибридный поиск и несколько векторных запросов, выполняемых одновременно.

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

Примечание.

Новая версия в версии 2024-09-01-preview — это возможность деконструировать оценку поиска на основе RRF в ее подкормках компонентов. Это дает прозрачность в состав всех показателей. Дополнительные сведения см. в разделе "Оценки поиска распаковки" (предварительная версия) в этой статье.

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

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

Ниже приведено простое объяснение процесса RRF:

Получите ранжированные результаты поиска из нескольких запросов, выполняемых параллельно.
Назначьте обратные оценки ранжирования для результатов в каждом из ранжированных списков. RRF создает новое @search.score значение для каждого совпадения в каждом результирующем наборе. Для каждого документа в результатах поиска подсистема назначает обратную оценку ранжирования на основе его позиции в списке. Оценка вычисляется как 1/(rank + k), где rank находится позиция документа в списке и k является константой, которая была экспериментально наблюдаема, чтобы лучше всего выполнить, если оно имеет небольшое значение, например 60. Обратите внимание, что это k значение является константой в алгоритме RRF и полностью отделяется от k того, что управляет числом ближайших соседей.
Объединение показателей. Для каждого документа подсистема суммирует взаимные оценки ранжирования, полученные из каждой системы поиска, создавая объединенную оценку для каждого документа.
Модуль ранжирует документы на основе объединенных показателей и сортирует их. Результирующий список — это плавленный рейтинг.

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

Параллельное выполнение запросов

RRF используется в любое время, когда выполняется несколько запросов. В следующих примерах показаны шаблоны запросов, в которых выполняется параллельный запрос:

Полнотекстовый запрос, а также один векторный запрос (простой гибридный сценарий), равен двум выполнениям запросов.
Полнотекстовый запрос, а также один векторный запрос, предназначенный для двух полей вектора, равен трем выполнениям запросов.
Полнотекстовый запрос, а также два векторных запроса, предназначенных для пяти векторных полей, равно 11 выполнений запросов

Оценки в результатах гибридного поиска

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

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

Метод поиска	Параметр	Алгоритм оценки	Диапазон
полнотекстовый поиск	`@search.score`	Алгоритм BM25	Нет верхнего предела.
векторный поиск	`@search.score`	Алгоритм HNSW, используя метрику сходства, указанную в конфигурации HNSW.	0.333 – 1.00 (Cosine), от 0 до 1 для Euclidean и DotProduct.
гибридный поиск	`@search.score`	Алгоритм RRF	Верхний предел ограничивается числом сплетаемых запросов, причем каждый запрос способствует максимальному значению 1 к оценке RRF. Например, объединение трех запросов приведет к повышению показателей RRF, чем при слиянии только двух результатов поиска.
семантическое ранжирование	`@search.rerankerScore`	Семантическое ранжирование	0.00 - 4.00

Семантический ранжирование происходит после объединения результатов RRF. Его оценка (@search.rerankerScore) всегда сообщается отдельно в ответе запроса. Семантический рангировщик может повторно выполнять полнотекстовые и гибридные результаты поиска, предполагая, что эти результаты включают поля с семантически богатым содержимым. Он может повторно выполнять чистые векторные запросы, если в документах поиска содержатся текстовые поля, содержащие семантическое содержимое.

Распакуйте оценку поиска в подкормках (предварительная версия)

С помощью предварительной версии 2024-09-01-preview можно деконструировать оценку поиска для просмотра своих подкормок.

Для векторных запросов эти сведения помогут определить подходящее значение для векторного весового значения или установки минимальных пороговых значений.

Чтобы получить подкормки, выполните приведенные действия.

Используйте последний предварительный просмотр REST API документов поиска или бета-версию пакета Пакета SDK Azure, который предоставляет эту функцию.
Измените запрос, добавив в него новый debug параметр vector, semantic если используется семантический рангер или all.

Ниже приведен пример гибридного запроса, который возвращает дочерние ядра в режиме отладки:

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2024-09-01=preview

{
    "vectorQueries": [
        {
            "vector": [
                -0.009154141,
                0.018708462,
                . . . 
                -0.02178128,
                -0.00086512347
            ],
            "fields": "DescriptionVector",
            "kind": "vector",
            "exhaustive": true,
            "k": 10
        },
        {
            "vector": [
                -0.009154141,
                0.018708462,
                . . . 
                -0.02178128,
                -0.00086512347
            ],
            "fields": "DescriptionVector",
            "kind": "vector",
            "exhaustive": true,
            "k": 10
        }
    ],
    "search": "historic hotel walk to restaurants and shopping",
    "select": "HotelName, Description, Address/City",
    "debug": "vector",
    "top": 10
}

Весовые оценки

С помощью версий API 2024-07-01 и более поздних версий API можно весовых векторных запросов увеличить или уменьшить их важность в гибридном запросе.

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

Совпадение найдено	Позиция в результатах	@search.score	умножение веса	@search.score (взвешанный)
вектор результатов один	позиция 1	0.8383955	0,5	0.41919775
векторные результаты два	позиция 5	0.81514114	2.0	1.63028228
Результаты BM25	позиция 10	0.8577363	Неприменимо	0.8577363

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

При добавлении векторного весового значения начальные оценки подвергаются умножительу весового значения, который увеличивает или уменьшает оценку. Значение по умолчанию — 1.0, что означает отсутствие весовых показателей и начальная оценка используется как в оценке RRF. Однако при добавлении веса 0,5 оценка уменьшается, и этот результат становится менее важным в объединенном рейтинге. И наоборот, если добавить вес 2,0, оценка становится более крупным фактором в общей оценке RRF.

В этом примере @search.score значения (весовые) передаются в модель ранжирования RRF.

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

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

Часто поисковая система находит больше результатов, чем top и k. Чтобы вернуть дополнительные результаты, используйте параметры topразбиения по страницам и skipnext. Разбиение на страницы — это определение количества результатов на каждой логической странице и переход по полной полезных данных. Можно задать maxTextRecallSize для больших значений (значение по умолчанию — 1000), чтобы вернуть дополнительные результаты из текстовой стороны гибридного запроса.

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

Дополнительные сведения см. в статье "Работа с результатами поиска".

Схема рабочего процесса оценки поиска

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

Запрос, создающий предыдущий рабочий процесс, может выглядеть следующим образом:

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2024-07-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
   "queryType":"semantic",
   "search":"hello world",
   "searchFields":"field_a, field_b",
   "vectorQueries": [
       {
           "kind":"vector",
           "vector": [1.0, 2.0, 3.0],
           "fields": "field_c, field_d"
       },
       {
           "kind":"vector",
           "vector": [4.0, 5.0, 6.0],
           "fields": "field_d, field_e"
       }
   ],
   "scoringProfile":"my_scoring_profile"
}

Поделиться через