Як впровадити 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 в одному запиті, мінімальний оверхед, не потрібні нові сервери. Ми гарантуємо сумісність з існуючою інфраструктурою та забезпечуємо підтримку сертифікованими фахівцями з 5+ років досвіду.

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/міс — у 3 рази дешевше, ніж рішення з Pinecone + окремий ES. Перехід від 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-моделі
• Написання скриптів батчевої векторизації та реіндексації
• Реалізація об'єднаного пошуку з RRF fusion
• Інтеграція RAG-пайплайну (з LangChain або прямими викликами OpenAI)
• Тестування: NDCG, Recall, latency, faithfulness
• Документація та навчання команди (2 години воркшопу)
• Ми маємо 5+ років досвіду в пошукових системах і реалізували понад 10 проектів RAG.

Терміни орієнтовно

Порівняння Elasticsearch kNN з альтернативними векторними базами

Elasticsearch виграє за комплексною вартістю та простотою, якщо ES вже в продакшені. Для стартапів без легасі — Pinecone може бути швидшим у запуску. Наш досвід показує: Elasticsearch kNN у 3 рази дешевший за інфраструктуру, ніж Pinecone + окремий ES.