Кожен другий українській AI-стартап у 2026 році будує RAG-систему. Це не перебільшення — у моєму моніторингу 40 з 80 стартапів, що отримали хоча б один транш венчурного фінансування за останні 18 місяців, мають RAG як центральний компонент продукту. Документації по темі багато. Реальних кейсів — мало. Я опитала шість команд і отримала чотири однакові відповіді на питання «що пішло не так».
Що таке RAG (коротко, для тих хто пропустив)
Retrieval-Augmented Generation — це коли ваш LLM не просто відповідає з пам’яті моделі, а перед відповіддю шукає релевантні документи у вашій базі і використовує їх як контекст. Базова архітектура: embedding-модель перетворює документи на вектори, векторна база зберігає їх, при запиті — пошук схожих векторів, передача їх LLM як контекст. Звучить просто. Не дуже просто на практиці.
Три помилки, які повторюються
1. Чанкінг по 1000 токенів
Найбільш стандартний підхід — розрізати документи на чанки по 1000 токенів. На практиці це дає погані результати на 80% реальних кейсів. Чанк часто розрізає речення посередині, втрачає контекст. Краще робити чанкінг по семантичних межах (параграфи, секції) і використовувати overlap 100-200 токенів. Команди, що перейшли на semantic chunking, повідомляють про покращення точності на 15-30%.
2. Vector DB без BM25
Векторний пошук вважається кращим за класичний keyword search. Це правда — для відкритих питань. Для специфічних термінів (назви компаній, номери продуктів, рідкісні слова) BM25 виграє у векторного пошуку. Гібридний підхід — векторний + BM25 з reranking-моделлю — дає кращі результати в 90%+ випадків. Pinecone, Weaviate, Qdrant — усі підтримують hybrid search з 2024 року.
3. Один embedding-модель на все
OpenAI ada-002 або text-embedding-3-small — це базова порада. На практиці кращі результати дають специфічні моделі для домену. Українська команда у legal-tech перейшла з ada-002 на bge-m3 (open-source, мультимовна) і отримала покращення точності пошуку на 22% при значно нижчій вартості.
Шість архітектур
Без назв компаній (анонімне опитування). Спільне у п’яти з шести: вибір Postgres + pgvector замість виділеної vector DB. Це проти консенсус-думки, але причина практична — українські команди не хочуть платити $200-500/міс за Pinecone, коли pgvector у власному Postgres коштує $0 додатково. Продуктивність на 1-5M документів — порівнянна.
Шоста команда — на 100M+ документах — використовує Qdrant у production. Поріг переходу: ~10M документів, де pgvector починає відчутно гальмувати без серйозного тюнінгу.
LLM-вибір: Claude Sonnet 4.5 — 4 з 6, GPT-4.1 — 1, fine-tuned Llama 3.3 — 1. Claude виграє через довший контекст і кращу якість на українській мові (за словами команд).
Що з цим робити
Якщо ви починаєте RAG-проект у 2026: pgvector у вашому Postgres, semantic chunking з overlap, гібридний пошук з BM25 + reranking (Cohere Rerank-3 або open-source bge-reranker), embedding-модель спеціально для вашого домену, Claude Sonnet 4.5 на топ. Це покриває 80% потреб української команди.
Найголовніше — не починайте з оптимізації. Перші 3-4 тижні — будуйте найпростішу версію (one chunk size, ada-002, basic top-k retrieval), вимірюйте якість на 100 реальних запитах, потім дослідно поліпшуйте. Це типова економіка AI-стартапу — складна інженерія приносить нуль доходу, поки немає базової версії продукту.
