Зауважимо: коли RAG-пайплайн видає нерелевантні результати, проблема найчастіше в архітектурі retrieval'у. Базовий RAG «працює» за день, але production-ready RAG система з надійним retrieval, моніторингом і керованою вартістю потребує ретельного проєктування. При проектуванні архітектури RAG ключовим є вибір компонентів. Ми спроєктували та впровадили понад 30 RAG-систем для різних індустрій — від юридичних документів до техпідтримки. Наш досвід каже: 70% успіху — в архітектурі pipeline'у. Наприклад, один клієнт з FinTech використовував dense-only пошук і отримував recall 0.65. Після впровадження гібридного пошуку з reranker'ом recall виріс до 0.92 — це в 1.4 рази краще, а latency p99 залишився під 200 мс — це суттєво скоротило витрати на перезапити до LLM. Техніка retrieval augmented generation (RAG) активно використовується в індустрії. Retrieval-Augmented Generation — це не просто модний термін, а зріла техніка, яка потребує грамотної інженерної реалізації. Ми маємо 5 років досвіду в NLP та 30+ виконаних проєктів.
Компоненти сучасного RAG-пайплайну
┌─────────────────────────────────────────────────────┐ │ INGESTION PIPELINE │ │ Sources → Loaders → Parsers → Chunkers → Embedder │ │ → Metadata Extractor → Vector Store │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ RETRIEVAL PIPELINE │ │ Query → Query Transformer → Multi-Index Search │ │ → Reranker → Context Assembler │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ GENERATION PIPELINE │ │ Context + Query → Prompt Builder → LLM │ │ → Response Validator → User │ └─────────────────────────────────────────────────────┘ Як обрати стратегію чанкінгу?
Чанкінг визначає якість retrieval. Фіксований розмір 256-512 токенів простий, але втрачає контекст. Структурний чанкінг за заголовками розділів дає кращі результати для документів з чіткою ієрархією. Вибір векторної бази даних (Qdrant, Weaviate, ChromaDB) залежить від навантаження. Порівняння:
| Стратегія | Коли використовувати | Recall@10 | Latency |
|---|---|---|---|
| Фіксований 256 токенів | Short texts, FAQ | 0.78 | 2 ms |
| Рекурсивний з overlap 15% | General documents | 0.85 | 5 ms |
| Семантичний чанкінг | Довгі наративи | 0.88 | 12 ms |
| Структурний (за заголовками) | Юридичні, технічні | 0.92 | 8 ms |
Ми використовуємо семантичний чанкінг на основі меж речень з перекриттям 10%. Це дає баланс якості та швидкості. Для кожного документа потрібні метадані (джерело, дата, тип).
Чому гібридний пошук (sparse + dense) необхідний?
Dense embedding чудово знаходить семантичні дублі, але погано справляється з рідкісними термінами або абревіатурами. Sparse (BM25) — навпаки. Згідно з документацією Qdrant, гібридний пошук з Reciprocal Rank Fusion (RRF) підвищує метрики релевантності на 20-30%. Гібридний пошук комбінує обидва підходи. У порівнянні з dense-only, гібридний пошук в 1.3 рази кращий за Recall@10.
from qdrant_client import QdrantClient from qdrant_client.models import SparseVector def hybrid_search(query, top_k=10): dense_vector = embedder.embed_query(query) sparse_vector = sparse_encoder.encode(query) results = client.query_points( collection_name="docs", prefetch=[ {"query": dense_vector, "using": "dense", "limit": 30}, {"query": SparseVector(indices=sparse_vector.indices, values=sparse_vector.values), "using": "sparse", "limit": 30}, ], query=rrf_fusion, # Reciprocal Rank Fusion limit=top_k, ) return results У наших проєктах гібридний пошук підвищує Recall@10 на 25-30% — в 1.25-1.3 раза. Додатково використовуємо reranker на базі cross-encoder (наприклад, ms-marco-MiniLM-L-12-v2), який перевпорядковує top-30 результатів до top-5. Це покращує точність в 1.5-2 рази. Така комбінація знижує витрати на LLM-інференс на 30-50%, що при обсязі 1M запитів на місяць дає економію $1500-3000. За нашими оцінками, для середнього проєкту з 500k запитів на місяць економія складає $2,000.
Оцінка якості retrieval
Для production потрібно закладати evaluation framework з набором метрик: Recall@k, MRR, NDCG. Ми використовуємо кастомний датасет з 500+ запитів з розміткою релевантності. Навантажувальне тестування перевіряє latency p99 — зазвичай target < 500 мс. Моніторинг у проді фіксує дрифт даних та деградацію метрик.
Порівняння embedding-моделей
| Модель | Розмірність | Recall@10 (ours) | Застосування |
|---|---|---|---|
text-embedding-ada-002 (OpenAI) |
1536 | 0.85 | Хмарне, простота |
embed-english-v3.0 (Cohere) |
1024 | 0.87 | Багатомовність |
intfloat/e5-large-v2 (open-source) |
1024 | 0.84 | Self-hosting, економія |
Для production ми рекомендуємо open-source embedding-моделі (E5, BGE) з self-hosting — це знижує операційні витрати в кілька разів при порівнянній якості.
Типові помилки при проектуванні RAG
- Недостатня кількість чанків: якщо чанк занадто довгий (>1024 токенів), LLM втрачає контекст.
- Відсутність гібридного пошуку: dense-only пропускає терміни з низькою частотою.
- Невиконання оцінки (evaluation): без валідації на репрезентативному датасеті ви не знаєте реальну якість.
- Ігнорування латентності: pipeline має вкладатися в SLA (зазвичай p99 < 1 с).
Процес роботи
- Аналітика — вивчення джерел, типів запитів, очікуваного навантаження (RPS).
- Проєктування — вибір стеку (векторна БД, embedding-модель, чанкінг).
- Реалізація — побудова ingestion pipeline, retrieval pipeline, integration з LLM.
- Тестування — evaluation на кастомному датасеті, A/B-тестування різних конфігурацій.
- Деплой та моніторинг — розгортання за допомогою Docker/Kubernetes, налаштування оповіщень по latency та recall.
Що входить у роботу
- Документація архітектури (діаграми, специфікація компонентів)
- Вибір стеку та обґрунтування (векторна БД, embedding, LLM)
- Прототип пайплайну з гібридним пошуком та reranker'ом
- Evaluation framework з набором метрик
- Інтеграція з існуючою інфраструктурою
- Навчання команди замовника та код-рев'ю
- Підтримка на етапі впровадження (до 1 місяця)
Терміни орієнтовно
- Проєктування: 1 тиждень
- Ingestion pipeline: 1–2 тижні
- Retrieval pipeline з reranker'ом: 2–3 тижні
- Evaluation та оптимізація: 1–2 тижні
- Production hardening: 1–2 тижні
- Разом: 6–10 тижнів залежно від складності
Вартість робіт — від $8,000 залежно від складності. Зв'яжіться з нами, отримайте консультацію з архітектури RAG для вашого проєкту. Гарантуємо, що результат відповідатиме best practices MLOps та вашим SLA. Гібридний пошук знижує витрати на LLM-інференс на 30-50%, що особливо помітно при високих навантаженнях. Замовте проєктування RAG-пайплайну та отримайте working prototype вже через 3 тижні.