RAG-архітектура для enterprise
90% enterprise AI-проєктів — це RAG (Retrieval-Augmented Generation). Без розуміння цієї архітектури неможливо ані специфікувати проєкт, ані оцінити його вартість, ані правильно safeguard'ити. Цей модуль розкриває 4-компонентну RAG-архітектуру + метрики якості + типові помилки.
Що ви опануєте
- 4 компоненти RAG: indexer, retriever, generator, evaluator
- Чому RAG, а не fine-tuning, у 90% випадків
- Vector databases + embedding models — як обрати
- Метрики якості RAG (precision, recall, faithfulness)
- Access control у RAG (часто пропускається)
Концепція 1: RAG-патерн — крок за кроком
RAG = пошук + генерація. Спрощена послідовність:
- Документ → split на chunks → embeddings → store у vector DB.
- Користувацький запит → embedding → знайти top-k similar chunks.
- Chunks + question → передати у LLM → згенерувати обґрунтовану відповідь з citations.
Чому це краще за просто prompt:
- Модель бачить ваші дані, не лише її training set.
- Дані можна оновлювати без re-training.
- Citations дають transparency — користувач бачить, звідки взялась відповідь.
Концепція 2: Чому RAG > Fine-tuning
| Критерій | Fine-tuning | RAG |
|---|---|---|
| Оновлення даних | Re-train model (тижні, $$$) | Update vector store (хвилини) |
| Citations | Складно | Природно вбудовано |
| Cost | $10K-100K на cycle | $1-5K на setup, copies cheap |
| **Контроль | Низький (дані запечатані у ваги) | Високий (повний RAG audit trail) |
| Latency | Низька | Помірна (retrieval + generation) |
Висновок: для dynamic data (документи, що змінюються) RAG майже завжди переможе. Fine-tuning кращий для style/format трансформацій.
Концепція 3: Vector Databases
Vector database — спеціалізована БД для embeddings (n-dimensional vectors). Embedded text shares similar meaning = similar vectors.
Топ-вибори для enterprise:
| База | Тип | Коли вибирати |
|---|---|---|
| Pinecone | Managed cloud | Швидкий старт, не хочете ops |
| Weaviate | Self-hosted або cloud | Контроль + flexibility |
| pgvector | PostgreSQL extension | Уже маєте PG, не хочете нову систему |
| Qdrant | Self-hosted (Rust) | Performance + open source |
| Azure AI Search | Managed (Azure) | M365 / Azure ecosystem |
Що питати vendor:
- Підтримка hybrid search (vector + keyword)?
- Filtering під час search (для access control)?
- Update vs insert (як часто можна оновлювати)?
Концепція 4: Embedding Models
Embedding model перетворює text у vectors. Якість embeddings = якість retrieval.
Закриті моделі:
- OpenAI text-embedding-3-large — найкраща quality, $0.13/1M tokens.
- Cohere embed-v3 — multi-language strong support.
- Voyage embeddings — best-in-class для коду.
Open-source:
- all-MiniLM — найшвидший, прийнятна quality, безкоштовно.
- BGE — баланс quality/speed.
- Stella — top-tier open-source.
Для української: перевірте multi-language support. Не всі моделі однаково добре працюють з кирилицею.
Концепція 5: Chunking Strategy
Як ви ріжете документи на chunks = 50% RAG-якості. Дрібні chunks — втрачають контекст. Великі — додають шум.
Базові стратегії:
| Стратегія | Опис | Коли |
|---|---|---|
| Fixed-size | 500 токенів кожен | Швидкий старт, baseline |
| Sentence-aware | Не ріжемо посеред речення | Кращий за fixed |
| Semantic | Ріжемо за зміною topic'у | Найкраща quality, найдорожча |
| Hierarchical | Multiple sizes одночасно | Складні документи |
Практичне правило: почніть з fixed-size 512 токенів з 50-токенним overlap'ом. Це baseline, що працює у 80% випадків.
Концепція 6: Метрики якості RAG
Hallucination у RAG досі трапляється. Вимірюйте — інакше не знаєте.
Базові метрики:
| Метрика | Що вимірює |
|---|---|
| Precision@k | Скільки з top-k retrieved документів реально relevant |
| Recall | Скільки relevant документів ми reach'нули |
| MRR (Mean Reciprocal Rank) | Як близько до top'у relevant документ |
| Faithfulness | Чи answer базується на retrieved chunks (vs hallucinated) |
| Answer relevance | Чи answer стосується question |
Стандартний tool: RAGAS — open-source framework для оцінки RAG. Безкоштовний.
Запустити RAG у production без метрик. Потім дивуватись, що користувачі скаржаться на wrong answers. Метрики — це not optional.
Концепція 7: Access Control у RAG (критично)
Retrieved документи МУСЯТЬ поважати дозволи користувача. Інакше RAG стає каналом витоку даних з SharePoint, Confluence, Drive.
Поганий патерн:
- Усі документи в одному vector store.
- Retrieve без access check.
- Junior employee може через RAG питання витягти CEO compensation details.
Zero Trust патерн:
- Метадані доступу зберігаються разом з embeddings.
- Retrieval фільтрує по permissions користувача до ranking.
- Audit logs показують, який документ був retrieved для кого.
Це найчастіший shame moment у early-stage RAG-deployments. Не falle у цю пастку.
Чекліст: запуск RAG-додатку
- Класифікувати documents за access tier перед індексацією
- Обрати vector DB + embedding model з multi-language support (якщо UA)
- Налаштувати chunking strategy (start з fixed-size 512)
- Імплементувати access-control filtering у retrieval
- Налаштувати RAGAS для evaluation з baseline metrics
- Audit logging для compliance evidence
- Human evaluation на тестовому наборі 50+ queries
Глибше у джерелах
Підсумок
RAG — це не магія. Це класична інформаційна архітектура з LLM-обгорткою. Уся складність — у якості retrieval та оцінці faithfulness. 4 компоненти + метрики + access control — це формула, що відрізняє enterprise RAG від demo-якості.
Наступний модуль: Agentic AI та MCP — наступний фронтир і новий рівень governance-викликів.