Различия в задержке поиска между семантическим поиском на базе ИИ и поиском по ключевым словам

Есть ли какие-либо данные о задержке для семантического поиска и семантически связанных тем по сравнению с поиском по ключевым словам и предложенными темами?

Заранее спасибо.

Не могли бы вы уточнить, что вы имеете в виду под задержкой?

Что касается связанных тем, то поскольку все эмбеддинги предварительно рассчитаны, дополнительных затрат времени выполнения нет. Напротив, SQL-запрос для поиска связанных тем выполняется быстрее, чем наш старый запрос на предложение тем, а мы также кэшируем связанные темы для ещё более высокой производительности.

Что касается поиска на основе ИИ, то наш текущий подход HyDE[1] к нему влечёт за собой серьёзные задержки, поэтому он выполняется асинхронно: пользователю сначала показывается стандартный поиск, а затем предлагается дополнить его результатами ИИ, когда они будут готовы. Здесь, в Meta, результаты поиска с использованием ИИ готовы в среднем через 4 секунды после появления обычных результатов поиска.


  1. GPT-4: HyDE означает Hypothetical Document Embeddings (эмбеддинги гипотетических документов) — техника, используемая в семантическом поиске для нахождения документов на основе сходства их содержания. Этот подход позволяет получать более точные и контекстно релевантные результаты поиска, оценивая концептуальное сходство между документами, а не полагаясь исключительно на совпадение ключевых слов. Это техника обучения без учителя, которая сочетает возможности GPT-3 по пониманию языка с контрастными текстовыми энкодерами, улучшая способность ИИ понимать и обрабатывать естественный язык более тонко и эффективно. ↩︎

3 лайка

Вот именно то, что я искал. Спасибо, Фалько.

Проводилось ли какое-либо исследование по способам снижения этой задержки для семантического поиска?

Первая версия AI Search имела значительно меньшую задержку, но и гораздо худшие результаты.

Что касается следующей версии, у нас есть несколько планов по снижению задержки:

  • Использование эмбеддингов на уровне постов вместо эмбеддингов на уровне тем

  • Применение модели повторного ранжирования для сортировки результатов поиска

  • Сделание HyDE опциональным

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

2 лайка

Круто. Спасибо за разъяснения, Фалько.

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

  1. Похоже, что при переключении тумблера для отображения результатов семантического поиска пользователю показывается смесь результатов из API семантического поиска и API поиска по ключевым словам. Верно ли это? Если да, то как ранжируются эти два набора результатов относительно друг друга?
  2. Касательно этого, можете ли вы прокомментировать, как работает сортировка по: словам с результатами семантического поиска. Я заметил, например, что статья, у которой есть иконка звезды в одном варианте сортировки, её нет в другом.



1 лайк

Да, именно так.

Используя технику, называемую «реципрокное слияние рангов» (reciprocal rank fusion). В будущем мы можем перейти к использованию переупорядочивающей модели (re-ranker).

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

1 лайк

Круто, спасибо, Фалько. Судя по тому, что мы видим, API семантического поиска возвращает результаты семантического поиска только клиенту. Следовательно, рекуррентное слияние рангов (Reciprocal Rank Fusion) выполняется на стороне клиента. Так ли это? Также есть ли у нас возможность самостоятельно заменить этот алгоритм переупорядочивания, если мы захотим поэкспериментировать с другими вариантами?

1 лайк

Да, именно так,

Технически, поскольку всё работает на стороне клиента, вы можете переопределить это.

Тем не менее, в долгосрочной перспективе я вижу, что мы будем всё больше полагаться на модели повторного ранжирования, которые по очевидным причинам будут работать на стороне сервера.

Понял. Спасибо!

1 лайк