RAG на Elasticsearch kNN: гибридный поиск BM25 и векторы

Разработка RAG с Elasticsearch kNN: гибридный поиск BM25 и векторы

Представьте: ваш Elasticsearch обрабатывает сотни тысяч документов, но пользователи жалуются, что поиск не находит релевантные ответы. BM25 отлично работает с точными совпадениями, но пасует перед синонимами, тавтологией и сложными запросами на русском языке. Результаты: клиенты уходят, операторы тратят время на поиск. Добавлять отдельную векторную базу? Это рост стоимости инфраструктуры, сетевые задержки и ещё одна система для поддержки. Оптимальное решение — использовать встроенный kNN в Elasticsearch 8.x, объединив полнотекстовый и векторный поиск в одном индексе. Мы помогли нескольким командам внедрить такой гибрид без смены инфраструктуры, и сейчас расскажем, как это сделать. Свяжитесь с нами для аудита вашего текущего поиска — мы предложим оптимальный маршрут.

Почему Elasticsearch kNN — оптимальное решение для гибридного поиска?

Типичные боли при внедрении RAG без перестройки: разрозненный поиск (BM25 пропускает семантику), инфраструктурный хаос (поднимать Pinecone или Weaviate параллельно с ES — увеличивать стоимость и сложность), латентность (внешние векторные БД добавляют сетевые задержки p99 до 50+ мс). Elasticsearch kNN решает все три: hybrid search (kNN + BM25) через RRF fusion в одном запросе, минимальный оверхед, не нужны новые серверы.

Elasticsearch — зрелая технология с 15+ лет на рынке, используется в тысячах продакшенов. Встроенная поддержка русского анализатора Snowball даёт качественный стемминг: запрос «договором» найдёт «договор», «договоры», «договорам». Это критично для BM25-части гибрида. Кроме того, ELK-стек (Logstash, Kibana) позволяет мониторить индексы и визуализировать метрики поиска без дополнительных инструментов.

Какие настройки HNSW дают наилучший баланс скорости и качества?

Для продакшена мы рекомендуем HNSW с параметрами m=16, ef_construction=100. Это оптимальный баланс между скоростью индексации и точностью поиска. Слишком маленькое num_candidates (менее 100) снижает recall, слишком большое — увеличивает latency. В наших проектах используем cosine similarity как метрику расстояния для эмбеддингов.

Как мы это делаем: стек, конфиги, кейс

Стек: Elasticsearch 8.11+, OpenAI text-embedding-3-small (1536-dim), Python 3.11, официальный клиент elasticsearch-py.

Кейс из нашей практики: миграция существующего Elasticsearch на RAG

Контекст: наш клиент — компания с 500K юридических документов в Elasticsearch 8.x. Задача: добавить RAG-поверхность без смены инфраструктуры.

Шаги:

1. Добавление поля embedding (dense_vector, dims=1536) к существующему маппингу.
2. Батчевая векторизация существующих документов (2 дня, 500K × $0.02/1M = $10).
3. Reindexing с новым полем (6 часов).
4. Добавление RRF fusion в поисковые запросы.
5. RAG-слой поверх ES retrieval.

Результаты (vs чистый BM25):

• NDCG@5: 0.64 → 0.81
• Recall@10: 0.71 → 0.88
• Latency P95: 85мс → 140мс (hybrid)
• Faithfulness (RAGAS): 0.76 → 0.91

Экономия на инфраструктуре: не нужно поднимать отдельный сервер за $200/мес. Переход от pure BM25 к hybrid kNN+BM25 дал +27% к NDCG без смены инфраструктуры. Клиент получил работающий RAG за 2 недели.

Создание индекса и индексация документов

Добавляем поле dense_vector в существующий индекс и выполняем батчевую векторизацию.

from elasticsearch import Elasticsearch es = Elasticsearch("http://localhost:9200") # Создание индекса с маппингом index_config = { "mappings": { "properties": { "content": { "type": "text", "analyzer": "russian", # Нативная поддержка русской морфологии }, "source": {"type": "keyword"}, "doc_type": {"type": "keyword"}, "page": {"type": "integer"}, "date": {"type": "date"}, "embedding": { "type": "dense_vector", "dims": 1536, "index": True, "similarity": "cosine", "index_options": { "type": "hnsw", "m": 16, "ef_construction": 100, } } } }, "settings": { "number_of_shards": 1, "number_of_replicas": 1, } } es.indices.create(index="knowledge_base", body=index_config) 

from openai import OpenAI from elasticsearch.helpers import bulk openai_client = OpenAI() def generate_actions(chunks: list): texts = [c["text"] for c in chunks] response = openai_client.embeddings.create( model="text-embedding-3-small", input=texts ) embeddings = [e.embedding for e in response.data] for chunk, embedding in zip(chunks, embeddings): yield { "_index": "knowledge_base", "_source": { "content": chunk["text"], "source": chunk["source"], "doc_type": chunk["doc_type"], "page": chunk.get("page", 0), "embedding": embedding, } } bulk(es, generate_actions(document_chunks)) 

Hybrid Search: BM25 + kNN на практике

Elasticsearch поддерживает гибридный поиск через knn + query в одном запросе с RRF fusion.

def hybrid_search_es( query: str, doc_type_filter: str = None, top_k: int = 5 ) -> list: query_embedding = openai_client.embeddings.create( model="text-embedding-3-small", input=query ).data[0].embedding filter_clause = [] if doc_type_filter: filter_clause.append({"term": {"doc_type": doc_type_filter}}) body = { "query": { "bool": { "must": { "match": { "content": { "query": query, "analyzer": "russian" } } }, "filter": filter_clause, } }, "knn": { "field": "embedding", "query_vector": query_embedding, "k": top_k * 3, "num_candidates": 100, "filter": filter_clause, }, "rank": { "rrf": { "window_size": 50, "rank_constant": 20, } }, "size": top_k, "_source": ["content", "source", "doc_type"], } response = es.search(index="knowledge_base", body=body) return [ { "text": hit["_source"]["content"], "source": hit["_source"]["source"], "score": hit["_score"], } for hit in response["hits"]["hits"] ] 

Преимущество русской морфологии из коробки

Elasticsearch с analyzer russian поддерживает стемминг русских слов через Snowball. Это критично для BM25 части гибридного поиска — запрос «договором» найдёт документы с «договор», «договоры», «договорам».

es.indices.analyze( index="knowledge_base", body={"analyzer": "russian", "text": "договором аренды"} ) # tokens: ["договор", "аренд"] — стеммированные формы 

Что входит в работу

• Аудит текущего индекса ES (маппинг, шарды, производительность)
• Проектирование схемы dense_vector и выбор embedding-модели
• Написание скриптов батчевой векторизации и реиндексации
• Реализация hybrid search с RRF fusion
• Интеграция RAG-пайплайна (с LangChain или прямыми вызовами OpenAI)
• Тестирование: NDCG, Recall, latency, faithfulness
• Документация и обучение команды (2 часа воркшопа)

Сроки ориентировочно

Сравнение Elasticsearch kNN с альтернативными векторными базами

Elasticsearch выигрывает по комплексной стоимости и простоте, если ES уже в продакшене. Для стартапов без легаси — Pinecone может быть быстрее в запуске.