Elasticsearch Suggesters и автодополнение в 2026 году: Completion, search-as-you-type, Context

Автодополнение — один из тех элементов интерфейса, который пользователь замечает только тогда, когда он работает плохо. Медленные подсказки, нерелевантные результаты или полное их отсутствие после опечатки мгновенно ухудшают опыт взаимодействия. В этой статье мы разберём все инструменты, которые Elasticsearch предоставляет для построения быстрого, точного и масштабируемого автодополнения — от теоретических основ до продакшн-готовой архитектуры в 2026 году.

1. Автодополнение в контексте поиска: зачем это важно

Автодополнение выполняет сразу несколько задач: сокращает время ввода запроса, направляет пользователя к существующим сущностям в базе и снижает количество «нулевых» результатов. По данным индустриальных исследований, интерфейсы с качественным автодополнением показывают конверсию на 20–30% выше, чем без него.

С технической точки зрения автодополнение — это поиск в реальном времени: запрос отправляется после каждого нажатия клавиши, ответ должен приходить менее чем за 50–100 мс, а результаты должны быть релевантны даже при неполном или ошибочном вводе. Именно эти требования определяют выбор инструментов внутри Elasticsearch.

2. Обзор типов Suggesters в Elasticsearch

Elasticsearch предлагает четыре типа Suggesters, каждый из которых решает свою задачу:

Term Suggester — предлагает исправления на уровне отдельных слов на основе расстояния Левенштейна. Используется для «Вы имели в виду?».
Phrase Suggester — работает с целыми фразами, учитывает частоту совместного появления слов. Подходит для коррекции запросов после отправки.
Completion Suggester — специализированная структура данных (FST — Finite State Transducer) в памяти для мгновенных подсказок по префиксу. Основной инструмент для автодополнения.
Context Suggester — расширение Completion Suggester с фильтрацией по категории или геопозиции.

Тип поля search_as_you_type — это отдельная концепция, реализованная через специальный маппинг поля, а не через API Suggest. Мы рассмотрим оба подхода и объясним, когда использовать каждый из них.

3. Completion Suggester: маппинг, индексирование, запрос

Маппинг поля типа completion

Для использования Completion Suggester необходимо объявить поле с типом completion в маппинге индекса:

PUT /products
{
  "mappings": {
    "properties": {
      "name": {
        "type": "text"
      },
      "suggest": {
        "type": "completion",
        "analyzer": "simple",
        "preserve_separators": true,
        "preserve_position_increments": true,
        "max_input_length": 50
      }
    }
  }
}

Параметр analyzer: "simple" разбивает ввод по пробелам и приводит к нижнему регистру — стандартный выбор для латиницы и кириллицы без морфологии. max_input_length ограничивает длину хранимых вариантов для экономии памяти.

Индексирование документов с подсказками

Поле suggest поддерживает как строку, так и объект с весами и несколькими входными вариантами:

POST /products/_doc/1
{
  "name": "Apple MacBook Pro 16",
  "suggest": {
    "input": ["Apple MacBook Pro", "MacBook Pro 16", "ноутбук Apple"],
    "weight": 100
  }
}

POST /products/_doc/2
{
  "name": "Apple MacBook Air M3",
  "suggest": {
    "input": ["Apple MacBook Air", "MacBook Air M3", "ноутбук MacBook Air"],
    "weight": 85
  }
}

Поле weight управляет порядком подсказок: документы с большим весом появляются выше. Это полезно для продвижения популярных или акционных товаров.

Выполнение запроса автодополнения

POST /products/_search
{
  "suggest": {
    "product_suggest": {
      "prefix": "macbook",
      "completion": {
        "field": "suggest",
        "size": 5,
        "skip_duplicates": true
      }
    }
  }
}

Ответ содержит массив options с полями text, _score и исходным документом. Параметр skip_duplicates: true исключает повторяющиеся подсказки из разных документов — критически важная опция для продакшена.

4. Search-as-you-type: когда использовать вместо Completion Suggester

Тип поля search_as_you_type, введённый в Elasticsearch 7.2, создаёт автоматически несколько субполей с edge n-gram и shingle-анализаторами. Это позволяет искать не только по префиксу, но и по вхождению в середину строки.

PUT /articles
{
  "mappings": {
    "properties": {
      "title": {
        "type": "search_as_you_type"
      }
    }
  }
}

При таком маппинге Elasticsearch автоматически создаёт субполя: title, title._2gram, title._3gram и title._index_prefix. Запрос выглядит следующим образом:

GET /articles/_search
{
  "query": {
    "multi_match": {
      "query": "elasticsearch auto",
      "type": "bool_prefix",
      "fields": [
        "title",
        "title._2gram",
        "title._3gram"
      ]
    }
  }
}

Ключевое отличие: Completion Suggester работает только по префиксу и хранит FST в памяти (heap), что даёт задержку в 1–5 мс. search_as_you_type работает через обычный инвертированный индекс, поддерживает поиск по середине строки и полноценный скоринг, но медленнее (10–30 мс). Выбирайте Completion Suggester для строгого автодополнения, search_as_you_type — для полнотекстового поиска в реальном времени.

5. Context Suggester: фильтрация по категории и геолокации

Context Suggester позволяет сужать пространство подсказок по произвольным категориям или координатам. Это незаменимо, когда один индекс обслуживает несколько тенантов или когда подсказки должны зависеть от раздела сайта.

Маппинг с контекстом категории

PUT /marketplace
{
  "mappings": {
    "properties": {
      "suggest": {
        "type": "completion",
        "contexts": [
          {
            "name": "category",
            "type": "category"
          }
        ]
      }
    }
  }
}

Индексирование с контекстом

POST /marketplace/_doc/1
{
  "suggest": {
    "input": "iPhone 16 Pro",
    "weight": 90,
    "contexts": {
      "category": ["electronics", "smartphones"]
    }
  }
}

Запрос с фильтрацией по контексту

POST /marketplace/_search
{
  "suggest": {
    "product_suggest": {
      "prefix": "iphone",
      "completion": {
        "field": "suggest",
        "size": 5,
        "contexts": {
          "category": [
            { "context": "electronics", "boost": 2 },
            { "context": "smartphones", "boost": 3 }
          ]
        }
      }
    }
  }
}

Параметр boost внутри контекста позволяет не просто фильтровать, но и поднимать релевантные категории в выдаче. Для геолокационных подсказок используется тип geo с параметрами precision и радиусом поиска.

6. Fuzzy-подсказки: устойчивость к опечаткам

Completion Suggester поддерживает нечёткий поиск через параметр fuzzy. Это спасает ситуацию, когда пользователь пишет «макбук» или «iPhon» с опечаткой:

POST /products/_search
{
  "suggest": {
    "product_suggest": {
      "prefix": "macbok",
      "completion": {
        "field": "suggest",
        "fuzzy": {
          "fuzziness": "AUTO",
          "min_length": 3,
          "prefix_length": 1,
          "unicode_aware": true
        }
      }
    }
  }
}

Настройки fuzzy:

fuzziness: "AUTO" — автоматически выбирает допустимое расстояние в зависимости от длины слова.
min_length: 3 — fuzzy активируется только для строк длиннее 3 символов.
prefix_length: 1 — первый символ должен совпадать точно (повышает производительность).
unicode_aware: true — корректная работа с кириллицей и другими Unicode-символами.

Важно: fuzzy в Completion Suggester значительно медленнее точного поиска. В высоконагруженных системах рекомендуется использовать его только при отсутствии точных совпадений — то есть делать два запроса: сначала точный, затем нечёткий как fallback.

7. Оптимизация производительности

Размер индекса и FST в памяти

FST для Completion Suggester хранится в heap JVM. Размер зависит от числа уникальных входных строк и их длины. Для индексов с миллионами подсказок FST может занимать несколько гигабайт. Контролируйте это через параметр max_input_length и ограничивайте число вариантов input на документ (оптимально 3–5).

Шардирование

Completion Suggester выполняет запрос на каждом шарде и объединяет результаты на координирующей ноде. Для индексов подсказок оптимально использовать 1–2 primary shard — это минимизирует оверхед на merge и сериализацию. Не создавайте индекс подсказок с теми же настройками шардирования, что и основной поисковый индекс.

Отдельный индекс для подсказок

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

Кэширование на уровне Elasticsearch

Completion Suggester не использует request cache Elasticsearch. Однако при стабильном наборе данных запросы к одному префиксу будут попадать в page cache операционной системы. Убедитесь, что у нод достаточно свободной памяти за пределами heap для эффективного OS-кэша.

8. Архитектурная интеграция: фронтенд, debounce и Redis

Debounce на стороне клиента

Отправлять запрос на каждый keystroke без задержки — ошибка. Стандартная практика — debounce 150–200 мс. Это сокращает нагрузку на backend в 3–5 раз при типичной скорости печати.

// React-пример с debounce
import { useMemo } from 'react';
import debounce from 'lodash/debounce';

const fetchSuggestions = async (query) => {
  const res = await fetch(`/api/suggest?q=${encodeURIComponent(query)}`);
  return res.json();
};

const debouncedFetch = useMemo(
  () => debounce(fetchSuggestions, 180),
  []
);

Backend API-прокси

Фронтенд никогда не должен обращаться к Elasticsearch напрямую. Запросы проходят через backend API (Go, Node.js, Java), который:

Валидирует и санитизирует пользовательский ввод.
Применяет авторизацию и мультитенантность (например, добавляет контекст категории).
Кэширует результаты в Redis.

Кэширование подсказок в Redis

Подсказки для популярных префиксов можно кэшировать в Redis с TTL 60–300 секунд. Ключ кэша строится как suggest:{tenant}:{normalized_prefix}. Это особенно эффективно: по статистике, 80% запросов автодополнения приходится на 20% популярных префиксов.

# Псевдокод на Go
func GetSuggestions(ctx context.Context, tenant, prefix string) ([]string, error) {
    cacheKey := fmt.Sprintf("suggest:%s:%s", tenant, strings.ToLower(prefix))
    
    // Попытка получить из Redis
    cached, err := redisClient.Get(ctx, cacheKey).Result()
    if err == nil {
        var suggestions []string
        json.Unmarshal([]byte(cached), &suggestions)
        return suggestions, nil
    }
    
    // Запрос к Elasticsearch
    suggestions, err := esClient.Suggest(ctx, tenant, prefix)
    if err != nil {
        return nil, err
    }
    
    // Сохранение в Redis на 120 секунд
    data, _ := json.Marshal(suggestions)
    redisClient.Set(ctx, cacheKey, data, 120*time.Second)
    
    return suggestions, nil
}

Связка Elasticsearch + Redis даёт задержку менее 5 мс для закэшированных запросов против 20–50 мс для прямых запросов к Elasticsearch.

9. Аналитика подсказок: что выбирают пользователи

Отслеживание кликов по подсказкам — ценный источник данных для улучшения поиска. Рекомендуемый подход:

При показе подсказки присваивайте каждой уникальный suggestion_id (хеш от текста и позиции).
При клике отправляйте событие: { query, selected_suggestion, position, timestamp, session_id }.
Агрегируйте события в отдельном индексе Elasticsearch или в аналитической базе.
Используйте CTR (click-through rate) по позиции для оценки качества ранжирования подсказок.

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

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

10. Типичные ошибки при реализации автодополнения

Индексирование всего текста документа в поле completion. Поле completion предназначено для явно заданных вариантов, а не для полного текста. Индексируйте только те строки, которые вы хотите показывать как подсказки.
Один индекс для подсказок и основного поиска. Это смешивает требования к производительности и усложняет оптимизацию. Используйте отдельный индекс.
Отсутствие нормализации ввода. Пользователь может написать «MacBook» или «macbook» — нормализуйте к нижнему регистру до передачи в Elasticsearch и при индексировании.
Игнорирование кириллических символов. Анализатор standard плохо работает с кириллицей в completion. Используйте simple или настройте кастомный анализатор с lowercase токен-фильтром.
Без debounce на фронтенде. При скорости 200 мс/символ и задержке сети 50 мс каждый символ без debounce порождает параллельные запросы, которые могут прийти не в том порядке (race condition).
Слишком большой размер input массива. Добавление десятков вариантов на документ раздувает FST и увеличивает heap. Ограничьтесь 3–7 вариантами на документ.
Отсутствие мониторинга heap после добавления completion-индекса. Рост FST может привести к GC-паузам и деградации производительности всего кластера.

Заключение

Реализация качественного автодополнения с Elasticsearch — это не один инструмент, а целая архитектура: правильный выбор между Completion Suggester и search_as_you_type, грамотный маппинг, изоляция индекса подсказок, кэширование через Redis, debounce на фронтенде и петля обратной связи через аналитику кликов. В 2026 году эти практики стали стандартом для production-систем с требованиями к latency менее 100 мс.

Начните с простого Completion Suggester на отдельном индексе, добавьте Redis-кэш для топ-префиксов, настройте сбор аналитики кликов — и вы получите надёжную основу, которую можно расширять по мере роста требований.

Elasticsearch Suggesters и автодополнение в 2026 году: от completion до search-as-you-type в продакшене