[📌 Часть 1/2] — 28 июля 2026 г. в 20:11:23.559
[📌 Часть 1/2] RAG в продакшене: гибридный поиск и реранкинг внутри бюджета p99 < 1с Чистый векторный поиск в RAG-системах часто ломается на точных совпадениях: IDs транзакций, артикулы товаров или специфические термины плохо работают через cosine similarity. Добавляем BM25 — получаем гибридный поиск, но теряем семантический контекст. Решение — реранкинг (Cross-Encoder), который оценивает релевантность пары «запрос-документ». Проблема в том, что Cross-Encoder тяжеловат: он проходит через каждый кандидат, и при k=50 это добавляет 200–400 мс к latency. В продакшене, где бюджет ответа часто ограничен второй, такая задержка убивает UX. Рассмотрим архитектуру, которая укладывает гибридный поиск + реранкинг в жесткие SLA без жертвования качеством. Ключевая идея — асинхронная фазовая сборка (parallel retrieval) и умная отсечка кандидатов перед дорогой моделью. Вместо последовательного вызова «Векторная БД → Поисковая система → Мerging», мы запускаем запросы в Qdrant (или Milvus/Pinecone) и Elasticsearch/Typesense параллельно через asyncio или concurrent.futures. Результаты объединяются алгоритмом Reciprocal Rank Fusion (RRF), который не требует весовых коэффициентов, а просто суммирует обратные ранги позиций документов из обоих источников. После RRF у нас есть отсортированный пул кандидатов. Критическая оптимизация — не пускать все 50–100 хитов в реранкер. Ставим «защелку» на семантическую дистанцию или уверенность векторной базы. Если топ-3 вектора уже имеют score > 0.85, реранкинг пропускаем (fast path). Это экономит ресурсы GPU/CPU на типовых запросах. Для сложных случаев (long-tail queries) запускаем BGE-Reranker или более легкую версию bge-reranker-base. Чтобы не гнаться за дорогой NVIDIA A100 только для реранкинга, кросс-энкодеры отлично живут на CPU с поддержкой AMX (Intel) или через ONNX Runtime с оптимизацией под AVX-512. Это снижает стоимость инфраструктуры в 5–10 раз по сравнению с GPU-only подходом для этого этапа.