Autocomplete: подсказки ввода в поиске

Прямой ответ

Подсказки ввода возвращаются на каждый нажатый символ, поэтому требование к задержке жёстче, чем к обычному поиску: ответ нужен за десятки миллисекунд, иначе подсказки отстают от ввода.

Два подхода дают разную задержку и качество.

Префиксный поиск по проиндексированному полю. Реализуется в любой системе с инвертированным индексом либо в базе данных через LIKE 'префикс%' с b-tree индексом.

Completion suggester в Elasticsearch использует отдельную структуру — конечный преобразователь (FST), оптимизированный под перечисление вариантов по префиксу.

{
  "mappings": {
    "properties": {
      "suggest": {
        "type": "completion",
        "analyzer": "standard"
      }
    }
  }
}

{
  "suggest": {
    "query-suggest": {
      "prefix": "ноут",
      "completion": {
        "field": "suggest",
        "size": 10,
        "skip_duplicates": true
      }
    }
  }
}

Вариант без отдельного движка — PostgreSQL с b-tree индексом:

CREATE INDEX idx_query_prefix ON search_queries (query text_pattern_ops);

SELECT query, cnt
FROM search_queries
WHERE query LIKE 'ноут%'
ORDER BY cnt DESC
LIMIT 10;

Индекс с классом операторов text_pattern_ops поддерживает префиксное сопоставление, тогда как обычный индекс для LIKE не используется.

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

Ранжирование подсказок и ограничение их числа

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

Частота запроса. Вариант, который ищут чаще, показывается выше. Частота накапливается из журнала поиска и периодически пересчитывается.

Вес варианта. Явно заданный вес позволяет поднять важные значения каталога независимо от частоты.

Длина совпадения. Подсказка, совпадающая с введённым префиксом полностью, полезнее длинного варианта, где префикс составляет малую часть.

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

Отдельная задача — дедупликация. Один вариант встречается в разных регистрах и формах, поэтому перед выдачей выполняется приведение и объединение дублей.

Практическое ограничение: подсказки обновляются на каждый символ, поэтому при вводе слова из восьми символов выполняется восемь запросов. Без ограничения частоты нагрузка на поисковый сервис многократно превышает нагрузку обычного поиска; об ограничении запросов — в статье про rate limiting API.

Распространённые приёмы снижения нагрузки:

1. Отправка запроса с задержкой после последнего нажатия, а не на каждый символ.
2. Отмена предыдущего запроса при вводе следующего символа.
3. Кэширование подсказок для коротких префиксов, которые повторяются у разных пользователей.
4. Минимальная длина префикса — два либо три символа, до которой подсказки не запрашиваются.

О кэшировании частых запросов — в статье про релевантность и ранжирование.

Практика: реализация подсказок ввода

1. Начинайте с истории поисковых запросов. Журнал поиска с частотой даёт подсказки, соответствующие реальным запросам, без ручной настройки.

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

3. Ограничивайте число возвращаемых вариантов. Возврат сотни вариантов при отображении десяти увеличивает трафик без пользы.

4. Проверяйте наличие результатов. Вариант без документов в выдаче исключается из подсказок.

5. Приводите варианты к единой форме. Регистр и лишние пробелы создают дубли в списке подсказок.

6. Ограничивайте частоту запросов от клиента. Отправка на каждый символ многократно увеличивает нагрузку на поисковый сервис.

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

8. Обновляйте частоты периодически. Пересчёт частот в реальном времени дорог, поэтому используется периодическое обновление.

Рекомендации:

1. Измеряйте задержку отдельно от обычного поиска. Подсказки выполняются чаще и требуют меньшей задержки, поэтому метрики собираются раздельно.
2. Не подсказывайте по одному символу. Односимвольный префикс даёт слишком общий список вариантов, а нагрузка на сервис максимальна.
3. Учитывайте опечатки в подсказках. Пользователь вводит префикс с ошибкой, и подсказки без допуска опечаток не помогают; о нечётком поиске — в статье про полнотекстовый поиск.
4. Разделяйте подсказки по контексту. Подсказки в каталоге и в разделе помощи строятся на разных наборах вариантов.
5. Фиксируйте минимальную длину префикса в конфигурации. Значение влияет на нагрузку и качество, поэтому подбирается по статистике запросов.

Практический сценарий: подсказки отстают от ввода

Контекст: список подсказок отображал устаревшие варианты, не соответствующие текущему вводу.

1. Диагностика. Клиент отправлял запрос на каждый символ, а ответы приходили в произвольном порядке. Ответ на префикс «ноу» отображался после ответа на «ноут», поэтому список не соответствовал вводу.
2. Причина. Отсутствовала отмена предыдущих запросов, а порядок ответов не гарантировался. Более ранний запрос с коротким префиксом выполнялся дольше и приходил последним.
3. Действия. (а) Добавили задержку перед отправкой, чтобы запрос выполнялся после паузы в вводе; (б) реализовали отмену предыдущего запроса при вводе следующего символа; (в) добавили проверку порядкового номера запроса на клиенте: ответ с устаревшим номером отбрасывается; (г) установили минимальную длину префикса два символа; (д) добавили кэширование подсказок для коротких префиксов с коротким временем жизни.
4. Результат. Список подсказок соответствует текущему вводу, а число запросов к поисковому сервису снизилось в несколько раз.

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

FAQ

Можно ли реализовать подсказки без поискового движка? Да, префиксный поиск по индексу базы данных покрывает задачу при умеренном объёме вариантов и наличии частот запросов.

Как часто обновлять частоты запросов? Периодически, в зависимости от скорости изменения статистики. Обновление в реальном времени дорого и редко требуется.

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

Почему подсказки требуют отдельного индекса? Требования к задержке и структуре отличаются от основного поиска, поэтому отдельный индекс настраивается под перечисление вариантов по префиксу.

Источники: Elasticsearch search suggesters, PostgreSQL text search controls, Apache Lucene documentation — ссылки в шапке.