totalEstimatedMatches поведение с Microsoft (Bing) API когнитивного поиска (v5)

Question

Недавно преобразованный код Bing Search API v2 в v5, и он работает, но мне любопытно поведение «totalEstimatedMatches». Вот пример, чтобы проиллюстрировать мой вопрос:

Пользователь на нашем сайте ищет конкретное слово. Запрос API возвращает 10 результатов (наша настройка размера страницы) и totalEstimatedMatches, установленных на 21. Поэтому мы указываем 3 страницы результатов и пропускаем пользовательскую страницу.

Когда они добираются до страницы 3, totalEstimatedMatches возвращает 22, а не 21. Кажется странным, что с таким небольшим результирующим набором он еще не должен знать, что это 22, но в порядке я могу жить с этим. Все результаты отображаются правильно.

Теперь, если страницы пользователя возвращаются со страницы 3 на страницу 2, значение totalEstimatedMatches равно 21. Это меня удивляет, потому что, как только набор результатов был выгружен, API, вероятно, должен знать, что есть 22, а не 21 результат.

Я был профессиональным разработчиком программного обеспечения с 80-х годов, поэтому я понял, что это одна из тех чертей, которая связана с дизайном API. По-видимому, это не кеширование точного числа результатов или что-то еще. Я просто не помню такого поведения в API поиска V2 (который я понимаю, это сторонний код). Это было довольно достоверно по количеству результатов.

Неужели это ударит кого-нибудь, кроме меня, как-то неожиданно?

Answer 1

Оказывается, это является причиной, почему ответ JSON поле totalEstimatedMatches включает слово ...Estimated... и не просто называется totalMatches:

»... индексный поиск двигатель не поддерживает точную оценку общего матча «.

Взято из: News Search API V5 paging results with offset and count

Как и следовало ожидать, тем меньше результатов вы получите обратно, тем больше ошибка% вы, вероятно, увидеть в значении totalEstimatedMatches. Аналогичным образом, чем сложнее ваш запрос (например, выполняется сложный запрос, такой как ../search?q=(foo OR bar OR foobar)&..., который на самом деле является 3 поисковыми запросами, упакованными в 1), тем больше вероятность появления этого значения.

При этом мне удалось (по крайней мере предварительно) компенсировать это, установив offset == totalEstimatedMatches и создав простую функцию проверки эквивалентности.

Вот тривиальный пример в питоне:

while True: 
    if original_totalEstimatedMatches < new_totalEstimatedMatches: 
     original_totalEstimatedMatches = new_totalEstimatedMatches.copy() 

     #set_new_offset_and_call_api() is a func that does what it says. 
     new_totalEstimatedMatches = set_new_offset_and_call_api() 
    else: 
     break