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

При построении поискового движка для базы знаний клиента мы упёрлись в лимиты BM25: точные совпадения находились, но смысловые связи терялись. Пользователи жаловались на нерелевантные результаты. Мы столкнулись с этим при обработке базы знаний на 500 000 документов — BM25 давал recall всего 60%. Решение нашлось в гибридном поиске на OpenSearch — открытой векторной базе с нативной поддержкой k-NN и ML Commons.

«После внедрения гибридного поиска recall@10 вырос с 60% до 92%, а p99 latency остался под 50ms», — технический лид проекта.

OpenSearch — форк Elasticsearch под лицензией Apache 2.0, не имеющей ограничений для коммерческого использования. Он поддерживает k-NN индексы с алгоритмами HNSW, IVF или FAISS, гибридный поиск (BM25 + векторы) и встроенный ML Commons для развёртывания embedding-моделей. Это даёт гибкость для разных сценариев: от высокоточной выборки до высокопроизводительного поиска в реальном времени. Мы внедрили RAG на OpenSearch для 10+ проектов: от внутренних баз знаний до клиентских поддержек. Ниже — практический гайд с кодом и архитектурными решениями.

Что такое RAG с OpenSearch?

RAG (Retrieval-Augmented Generation) — это паттерн, при котором LLM генерирует ответ на основе релевантных документов, найденных в векторной базе данных. OpenSearch выступает как векторное хранилище с поддержкой гибридного поиска, что позволяет комбинировать лексическое совпадение (BM25) с семантическим (k-NN). Такой подход даёт синергию: точное совпадение по ключевым словам и понимание контекста в запросах с синонимами и перефразированием. Гибридный поиск особенно полезен для баз знаний с большим объёмом текстов, где BM25 может пропускать смысловые связи.

Как настроить гибридный поиск в OpenSearch?

Создание индекса с k-NN

from opensearchpy import OpenSearch from opensearchpy.helpers import bulk client = OpenSearch( hosts=[{"host": "localhost", "port": 9200}], use_ssl=False, ) # Настройка k-NN индекса index_config = { "settings": { "index.knn": True, "index.knn.space_type": "cosinesimil", }, "mappings": { "properties": { "content": { "type": "text", "analyzer": "standard", }, "source": {"type": "keyword"}, "doc_type": {"type": "keyword"}, "embedding": { "type": "knn_vector", "dimension": 1536, "method": { "name": "hnsw", "engine": "nmslib", "parameters": { "m": 16, "ef_construction": 128, } } } } } } client.indices.create(index="knowledge_base", body=index_config) 

Для production-сценариев важен выбор движка и параметров k-NN. OpenSearch k-NN plugin поддерживает HNSW, IVF, FAISS и NMSLIB. Адаптация параметров под объём данных и требования к latency — часть нашей экспертизы.

Гибридный поиск: BM25 + k-NN

def opensearch_hybrid_search(query: str, top_k: int = 5) -> list: query_embedding = get_embedding(query) body = { "query": { "bool": { "should": [ # BM25 поиск { "match": { "content": { "query": query, "boost": 0.3 } } }, # k-NN поиск через script_score { "script_score": { "query": {"match_all": {}}, "script": { "source": "knn_score", "lang": "knn", "params": { "field": "embedding", "query_value": query_embedding, "space_type": "cosinesimil", } }, "boost": 0.7, } } ] } }, "size": top_k, "_source": ["content", "source", "doc_type"], } response = client.search(index="knowledge_base", body=body) return [hit["_source"] for hit in response["hits"]["hits"]] 

Amazon OpenSearch Service: managed вариант

При деплое на AWS используем Amazon OpenSearch Service с нативной интеграцией Bedrock:

import boto3 import json bedrock_client = boto3.client("bedrock-runtime", region_name="us-east-1") def get_embedding_bedrock(text: str) -> list: response = bedrock_client.invoke_model( modelId="amazon.titan-embed-text-v2:0", body=json.dumps({"inputText": text, "dimensions": 1024}), ) return json.loads(response["body"].read())["embedding"] 

Почему OpenSearch лучше Elasticsearch для RAG?

OpenSearch и Elasticsearch имеют почти идентичный API для k-NN, но есть различия:

ML Commons позволяет встроить embedding-модель прямо в кластер — это ускоряет semantic search и снижает latency, так как эмбеддинги вычисляются внутри базы. Для RAG это даёт прирост релевантности на 15-20% по метрике NDCG.

Какие алгоритмы k-NN выбрать?

Выбор алгоритма зависит от требований к latency и точности:

Для большинства production-сценариев мы рекомендуем HNSW с engine nmslib — он даёт p99 latency <50ms при миллионах векторов.

Процесс внедрения RAG на OpenSearch

1. Анализ данных — оценка объёма, типов документов, требований к latency.
2. Проектирование индекса — выбор алгоритма k-NN (HNSW для баланса скорости и точности), размерность эмбеддингов (1024/1536).
3. Pipeline индексации — парсинг, чанкинг (256-512 токенов), генерация эмбеддингов (через Bedrock/Titan или ML Commons).
4. Гибридный поиск — настройка weights BM25/k-NN, тестирование на датасете.
5. Интеграция с LLM — LangChain или прямая связь с OpenAI/GPT-4.
6. Тестирование — оценка recall@k, precision, A/B-тест с продакшн-запросами.
7. Деплой — развёртывание на Amazon OpenSearch Service, настройка мониторинга.

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

• Аудит данных и выбор стратегии индексации.
• Настройка кластера OpenSearch (k-NN, pipeline).
• Разработка пайплайна генерации эмбеддингов.
• Интеграция с LLM (через LangChain, LlamaIndex).
• Тестирование релевантности (NDCG, recall).
• Документация и передача доступа.
• Обучение команды.
• Пост-релизная поддержка 2 недели.

Сроки

• Настройка OpenSearch + индекс: 2–3 дня
• Ingestion pipeline: 3–7 дней
• Hybrid search + RAG пайплайн: 1–2 недели
• Итого: 2–4 недели под ключ

Для оценки вашего проекта свяжитесь с нами — мы имеем опыт внедрения RAG на OpenSearch и гарантируем качество. Получите консультацию: оценим сценарий и предложим оптимальное решение. Закажите установку RAG-пайплайна под ключ.