Як ми побудували власну RAG-систему: від проблеми до оптимального рішення

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт! Я Нікіта Бронніков — Android Lead у Liven, одному з бізнесів венчур-білдера SKELAR. Крім мобільної розробки, я займаюся ініціативами з впровадження AI у робочі процеси. І в цій статті пропоную розглянути наш шлях від хаосу в корпоративних знаннях до побудови власної RAG-системи.

Уявіть, що ви — новий розробник у команді й вам потрібно розібратися з архітектурою проєкту. Ви відкриваєте Notion і... губитеся в сотнях сторінок документації. Знайомо? А тепер уявіть, що у вас є персональний асистент, який миттєво знаходить потрібну інформацію з усіх корпоративних джерел і дає контекстуальні відповіді з посиланнями на джерела.

Саме таку систему ми побудували в Liven і далі я поділюся, чому готові рішення не спрацювали, як ми тестували різні підходи та які результати отримали. Стаття буде корисна тим, хто планує впроваджувати AI у роботу з документацією або хоче зрозуміти практичні аспекти побудови RAG-систем.

Що важливо визначити зі старту: RAG-система — не просто інструмент для пошуку інформації. Це core для AI-mind компанії, фундамент для майбутньої агентної системи, яка матиме доступ до всіх корпоративних знань і зможе проактивно допомагати в роботі.

Але починалася наша розробка з простої проблеми — хаосу в документації. Коли компанія зростає, то знання в ній розширюються дуже стрімко. У Liven ми зіштовхнулися з тим, що наш простір у Notion перетворився на справжній лабіринт інформації. Як влучно зауважив один із колег: «У Notion я заходжу як в окремий інтернет». Сотні сторінок документації, десятки баз даних, вкладені сторінки на п’ять рівнів вглиб — навігація в цих документах стала схожою на археологічні розкопки.

Найбільший блокер — неможливість тримати в голові всі контексти одночасно:

• Технічний контекст: API-документація, архітектурні рішення, стандарти коду, інструкції з деплою, конфігурації серверів. Кожна команда мала свій простір, свої конвенції найменування, свою структуру документів.
• Продуктовий контекст: user stories, продуктові гіпотези, результати досліджень, A/B-тести, роадмапи. Інформація оновлювалася нерівномірно — щось залишалося актуальним доволі довго, щось було застарілим уже за тиждень.
• Маркетинговий контекст: tone of voice, воронки, контент-плани, аналітика кампаній.

Але Notion — це лише верхівка айсберга. Реальна складність полягала в тому, що критично важлива інформація була розкидана в різних системах. YouTrack вміщувала тисячі задач з детальними описами: технічні специфікації, які не переносили в Notion, обговорення в коментарях, де ухвалювали важливі архітектурні рішення, історичний контекст — чому ми вирішили робити саме так, а не інакше.

Онбординг нових співробітників перетворився на справжній виклик через складні бізнес-контексти. Онбординг-документи не закривали всю проблематику, оскільки інформація накопичувалася швидше, ніж ми встигали їх оновлювати.

Хоча RAG-пошук існував у Notion, він не покривав усі описані проблеми. Головні обмеження:

• Notion AI працював виключно в межах Notion.
• Неможливість інтегрувати YouTrack або інші бази знань із Notion AI.
• Відсутність контролю над моделлю та її параметрами.

Стало очевидно: нам потрібен був не просто кращий пошук, а принципово новий підхід до роботи з корпоративними знаннями.

Пошук швидкого рішення: спроба з N8N

Розуміючи масштаб проблеми, ми не хотіли робити PoC з нуля. Тому перша ідея була — знайти готове рішення та адаптувати під наші потреби. Ми керувалися простою логікою: не винаходити велосипед, а взяти готове рішення та адаптувати під наші потреби. N8N з його візуальним підходом до автоматизації здавався ідеальним варіантом для швидкого прототипу.

N8N пропонував все, що нам було потрібно на старті: готові інтеграції з Notion API, вбудовані ноди для роботи з векторними базами даних, підтримка OpenAI для embedding та генерації відповідей, візуальний інтерфейс — і для цього не потрібно писати код із нуля. Ми знайшли готовий шаблон для роботи з великими документами. План був простий: встановити, налаштувати, запустити.

Але реальність виявилася жорстокою.

Результат «із коробки» виявився жахливим. У відповідь на запити підтягувалися не ті статті з Notion, які мали б бути релевантними. Як наслідок — AI видавав некоректні відповіді та багато чого вигадував від себе.

Наприклад:

• На запит про «деплой на продакшн» ми отримували статті про маркетингові кампанії.
• Відповіддю на запитання про API-автентифікацію були фрагменти з HR-документації.
• А на технічні запити українською взагалі зʼявлявся випадковий набір документів.

Чому не обрали готові рішення (CrewAI, AutoGen)

На етапі вибору технологій ми розглядали популярні фреймворки для побудови AI-агентів — CrewAI та AutoGen. Вони пропонують готові абстракції для роботи з агентами та оркестрації LLM-викликів. Однак ми вирішили поки що не використовувати їх через кілька причин:

• Надмірна складність для MVP — ці фреймворки створені для складних мультиагентних систем, а нам потрібна була проста RAG-система.
• Втрата контролю — готові абстракції приховують критичні деталі пайплайну, які ми хотіли налаштовувати.
• Overhead — додатковий шар абстракції збільшує затримку та ускладнює дебагінг.

Тому ми вирішили розпочати з базових компонентів (LangChain + OpenAI), щоб повністю зрозуміти кожен етап обробки. У майбутньому, коли система еволюціонує в мультиагентну платформу, ми плануємо переглянути це рішення.

Після детального аналізу ми зʼясували системні проблеми шаблонного підходу:

Окрім технічних проблем, ми знайшли ще один критичний недолік. Шаблон N8N був заточений виключно під роботу з базами даних Notion, повністю ігноруючи звичайні сторінки. А в нас саме зі звичайних сторінок складається значна частина бази знань.

Шаблон не давав можливості:

• Парсити звичайні сторінки Notion поза базами даних.
• Рекурсивно переглядати вкладені сторінки.
• Зберігати ієрархічну структуру документів.

Після тижня експериментів стало очевидно: готові шаблони N8N підходять для простих юзкейсів, але не для продакшну RAG-системи. Занадто багато критичних параметрів жорстко зашиті, занадто мало контролю над процесом.

Потрібно було починати з чистого аркуша та будувати систему, де кожен компонент буде під нашим контролем.

Побудова власної RAG-системи

Невдача з готовими рішеннями стала для нас цінним уроком. Тому ми вирішили будувати з нуля, використовуючи перевірені технології. Почали з дослідження для кожного етапу RAG-pipeline.

Перед початком розробки ми чітко визначили вимоги: інтеграція з множинними джерелами (Notion та YouTrack як стартові платформи), підтримка української та англійської мов, контроль над кожним етапом — від чанкінгу до генерації відповідей, масштабованість та гнучкість налаштувань.

Вибір технологій

Векторна база даних: PostgreSQL з pgvector extension. Це було прагматичне рішення для MVP — команда вже мала досвід роботи з PostgreSQL і ми не хотіли ускладнювати інфраструктуру додатковою базою даних. Pgvector дозволив нам зберігати вектори просто поруч із метаданими документів.

LangChain: фундамент нашого рішення. Цей фреймворк створений спеціально для розробки LLM-застосунків і надав нам готові компоненти для кожного етапу обробки документів. Для чанкінгу ми використовуємо MarkdownTextSplitter — спеціалізований splitter, який розуміє структуру Markdown-документів і розбиває текст за заголовками, зберігаючи логічну цілісність.

OpenAI: для створення векторних представлень використовуємо text-embedding-3-large (вектори розміром 3072), для генерації відповідей — GPT-5. Ці моделі показали хороші результати з українською та англійською мовами.

Backend-архітектура: NestJS + PostgreSQL + LangChain.

Реалізація системи

Процес починається з інгестингу даних. Система підключається до Notion API та рекурсивно проходить усіма сторінками Notion Workspace (як базою даних, так і звичайними сторінками). Для оптимізації процесу система перевіряє дату останнього оновлення кожної сторінки — якщо документ не змінювали з моменту останньої синхронізації, вона його пропускає. Кожен новий або оновлений документ проходить через етап очищення — видаляються зайві HTML-теги та форматування, залишається чистий Markdown.

Найважливіший етап — чанкінг. MarkdownTextSplitter аналізує структуру документа та розбиває його на логічні блоки. Заголовки служать природними межами для чанків. Це критично важливо — замість того, щоб механічно розбивати текст за кількістю символів, ми зберігаємо його семантичну цілісність. Кожен чанк перетворюється на вектор через OpenAI embeddings API. Спочатку ми використовували text-embedding-3-small, але швидко зрозуміли, що для української мови потрібна більша модель. Перехід на text-embedding-3-large (розмір 3072 замість 1536) значно покращив якість пошуку українською мовою — модель краще розуміє семантику та контекст українських текстів. Ці вектори разом з оригінальним текстом та метаданими (назва документа, URL, дата оновлення) зберігаються в PostgreSQL.

Коли користувач ставить запитання, система спочатку аналізує його складність. Прості запити покращуються та уточнюються через LLM, а складні розбиваються на кілька простіших підзапитів. Кожен оброблений запит перетворюється на вектор та виконується гібридний пошук (векторний + BM25) найбільш релевантних чанків.

Результати з різних підзапитів об’єднуються з дедуплікацією — документи, знайдені кількома підзапитами, отримують додаткові бали. Фінальний набір чанків формує контекст, який разом з оригінальним запитанням передається в GPT-5 для генерації відповіді з посиланнями на джерела.

Перехід на власну систему дав відчутні результати: якість відповідей покращилася надзвичайно, запити українською почали працювати коректно, з’явилася можливість точно налаштовувати кожен аспект роботи, система може розвиватися разом із нашими потребами.

Але це був лише початок. Маючи робочу базову версію, ми вирішили не зупинятися на досягнутому.

Тестування різних підходів

Пам’ятаєте проблему з N8N? Готові шаблони давали жахливі результати через жорстко зашиті параметри. Та отримавши робочий MVP, ми зрозуміли: це лише фундамент для експериментів. Світ RAG-систем пропонує безліч стратегій оптимізації, тож ми вирішили систематично протестувати найперспективніші з них. Мета — знайти оптимальний баланс між якістю відповідей, швидкістю обробки та вартістю для нашої корпоративної документації.

Важливо, що ми розглядали для себе базовий набір стратегій — це далеко не всі підходи, які існують у світі RAG-систем. Наш вибір базувався на практичності, доступності реалізації та потенційній ефективності для наших конкретних потреб.

Стратегії чанкінгу

1. Symbol-based chunking — найпростіший підхід, який ділить текст на фрагменти фіксованого розміру (наприклад, 1000 символів). Хоча він забезпечує передбачуваність розмірів чанків, часто розриває логічні зв’язки в тексті.
2. Markdown chunking — орієнтований на структуру підхід, який розбиває документи за заголовками та іншими Markdown-елементами. Це зберігає логічну структуру документів, особливо важливо для технічної документації з чіткою ієрархією.
3. Semantic chunking — аналіз семантичних меж через цілісність тексту. Працює за системою 2 етапів: спочатку використовує Markdown-заголовки як основні межі, потім виділяє зміни тем між параграфами через математичний аналіз схожості речень. Мінімальні API-виклики (тільки для виділення зміни теми), швидка обробка.
4. Agentic chunking — багатоетапний аналіз з LLM-агентом, який створює адаптивну стратегію для кожного документа:

• Етап 1. Аналіз структури документа та щільності інформації.
• Етап 2. Створення плану чанкінгу на основі аналізу.
• Етап 3. Виконання плану чанкінгу.
• Етап 4. Оптимізація меж чанків агентом.

Ця стратегія працює з інтенсивними API-викликами (аналіз + планування + оптимізація), має найвищу точність для складних документів. Розмір чанків: 200-1000 символів. У 5-6 разів дорожчий за semantic, але дає відмінну якість для нестандартних структур.

Стратегії пошуку

Hybrid search — комбінує 2 типи пошуку: векторний (розуміє сенс запиту) та повнотекстовий BM25 (шукає точні слова). Наприклад, запит «як налаштувати деплой» знайде документи і про deployment configuration, і про налаштування розгортання. Результати об’єднуються через RRF (Reciprocal Rank Fusion) — простий алгоритм, який бере топрезультати з обох пошуків і змішує їх, даючи вищі позиції документам, які знайшли обидва методи.

Enhanced hybrid search — «розумна» версія гібридного пошуку. Перед пошуком LLM аналізує запит користувача та покращує його. Наприклад, запит «Чому не працює платіжка?» перетворюється на «проблеми з API-платежів, помилки обробки платежів, налагодження платіжного модуля». Складні запити розбиваються на кілька простіших і запит «Як налаштувати проєкт і підключити базу даних?» стає двома окремими пошуками. А результати об’єднуються з видаленням дублікатів.

Стратегії аугментації

Аугментація в RAG — це техніки покращення якості пошуку через додаткову обробку запитів або результатів. Простіше кажучи, це способи зробити систему розумнішою.

1. Context distillation — «розумне стиснення» знайденої інформації. Система збирає всі знайдені документи, видаляє повтори, залишає тільки найважливіше та зберігає посилання на джерела. Це як мати помічника, який прочитав 20 документів і зробив короткий конспект найголовнішого.
2. Self-reflective RAG — «система-перфекціоніст». Спочатку генерує відповідь, потім сама себе перевіряє, чи все правильно, чи нічого не пропустила, чи немає помилок. Якщо знаходить проблеми — переписує відповідь. Найякісніший підхід, але повільний та дорогий.
3. Structured prompting — «шаблонізація» відповідей. Система завжди відповідає в одному форматі: спочатку короткий висновок, потім деталі, потім посилання.

Варіанти тестування

Комбінуючи різні стратегії, ми визначили 8 конфігурацій для тестування — від найпростішої (symbol chunking) до найскладнішої (agentic chunking із дистиляцією). Кожна комбінація мала свою мету:

Після того як ми визначили ці конфігурації, потрібно було об’єктивно виміряти, яка з них найкраще розвʼязує нашу початкову проблему — швидко знаходити релевантну інформацію серед усієї корпоративної документації.

Тестування системи

Для об’єктивної оцінки ефективності нашої RAG-системи ми створили спеціальний тестовий проєкт, побудований на тій самій технологічній основі, що й ключова система: NestJS з тими самими модулями та сервісами, PostgreSQL з pgvector extension, OpenAI API з тими самими моделями, LangChain з ідентичними налаштуваннями.

Це дозволило нам ізольовано тестувати кожну конфігурацію, порівнювати результати в контрольованому середовищі, швидко переключатися між стратегіями та збирати метрики продуктивності.

Тестові датасети

Для комплексного тестування ми підготували 2 різні датасети, кожен із яких перевіряв систему в різних умовах.

Датасет 1: Wikipedia (базовий). Це датасет на основі статей з Вікіпедії в Markdown-форматі. Вибір такого формату був принциповим рішенням — він повністю відповідає форматам наших основних джерел інформації (Notion та YouTrack). Вікіпедія забезпечила різноманітність тем від технічних статей до гуманітарних дисциплін та чітку ієрархію заголовків і розділів. Цей датасет дозволив нам протестувати базову функціональність системи в контрольованих умовах.

Датасет 2: Notion (800 корпоративних статей). Другий, більш важливий датасет створено з реальних статей нашого корпоративного Notion — 800 документів, які для цього ніяк спеціально не готували. Це справжні робочі файли: технічна документація, продуктові специфікації, результати досліджень, нотатки зустрічей, архітектурні рішення — все те, з чим система працюватиме в продакшні.

Ключова особливість цього датасету — запитання та контрольні відповіді, згенеровані синтетично за допомогою LLM. Ми проаналізували кожен документ і створили релевантні запити різної складності.

Такий підхід дав нам можливість протестувати систему на реальних корпоративних даних з їх хаотичною структурою, неоднорідним форматуванням та змішаним контентом. Тобто на тому, з чим система буде зіштовхуватися щодня.

Методологія оцінки: тулкіт RAGAS

Для об’єктивної оцінки якості та комплексного тестування RAG-системи ми використовували спеціальний інструмент RAGAS. Він оцінює не тільки фінальну відповідь, а й кожен етап RAG-pipeline окремо.

Ми обрали ключові метрики RAGAS:

• Answer Correctness — наскільки точно відповідь відображає фактичну інформацію з джерел. Метрика перевіряє фактологічну правильність та відсутність галюцинацій.
• Answer Relevancy — чи відповідає згенерована відповідь на поставлене запитання. Високий показник означає, що система розуміє суть запиту та не відхиляється від теми.
• Context Precision — якість відібраних документів для контексту. Метрика показує, наскільки релевантні фрагменти потрапили в топ результатів пошуку.
• Context Recall — повнота контексту. Перевіряє, чи всі необхідні для відповіді фрагменти були знайдені системою пошуку.
• Faithfulness — вірність джерелам. Оцінює, наскільки відповідь базується на наданому контексті без додавання інформації «від себе».

Додатково ми відстежували вартість операцій — важливий практичний показник для продакшну використання.

Так сформували все для об’єктивного тестування: 8 конфігурацій, 2 датасети (ідеальний Wikipedia та хаотичний Notion) і набір метрик RAGAS. А тепер про те, як ми дізналися, який підхід найкраще справляється з нашою проблемою.

Результати експериментів

Головним висновком поділюся одразу: найпростіший підхід (Markdown chunking + Hybrid search) переміг складні стратегії на обох датасетах. Але дияволи ховаються в деталях — розберімося, чому так і що це означає для продакшна системи.

Ми протестували 8 конфігурацій на обох датасетах, систематично комбінуючи різні стратегії чанкінгу, пошуку та аугментації. Це дозволило нам побачити, як різні підходи працюють і на ідеальних структурованих даних (Wikipedia), і на реальних корпоративних документах (Notion).

Загальні результати та порівняння датасетів

Датасет 1. Wikipedia (структуровані дані)

Датасет 2. Notion (реальні корпоративні дані):

Переможці за категоріями:

Порівняльний аналіз результатів

Symbol vs Markdown chunking: вплив структурованості даних

На Wikipedia (структуровані дані): Symbol chunking (0.7256) та Markdown chunking (0.7559) показали схожі результати через чітку структуру статей із заголовками. Різниця між механічним розбиттям за символами та структурним розбиттям за Markdown-елементами мінімальна.

На Notion (неструктуровані дані): Різниця виявилася кардинальною! Symbol chunking (0.5532) значно програв Markdown chunking (0.6013) — відмінність 8.7%. Хаотична структура корпоративних документів зробила структурне розбиття критично важливим.

Реальні відмінності на неструктурованих документах підтвердилися:

• Транскрипти розмов — symbol chunking розривав діалоги посередині реплік.
• Технічні нотатки без заголовків — markdown chunking знаходив логічні межі за форматуванням.
• Змішані формати (код + текст + таблиці) — структурний підхід зберіг цілісність блоків.

Enhanced Search: кардинально різна ефективність

На Wikipedia (прості запити): Enhanced search показав гірші результати (0.7424 vs 0.7559) через профіль тестових запитів — прості та конкретні (наприклад, «Що таке фотосинтез?»).

На Notion (складні запити): Enhanced search також програв (0.5738 vs 0.6013), але різниця менша (4.6% vs 1.8% на Wikipedia). Складні корпоративні запити частково компенсували недоліки трансформації запиту.

Несподіваний результат: навіть на складних корпоративних запитах Enhanced search не показав переваг. Причина — синтетично згенеровані запити виявилися недостатньо складними для розкриття потенціалу Enhanced search. В реальних корпоративних запитах, як правило, використовуються більш складні запити, що може вплинути на результати Enhanced search.

Context Distillation: різний вплив на різні типи контенту

Context distillation показав змішані результати — покращив точність, але знизив коректність та релевантність. Це очікуваний результат, оскільки дистиляція — це інструмент оптимізації витрат, а не покращення якості.

Коли Context Distillation необхідний:

• Великі документи (>10,000 токенів) в контексті.
• Обмежений бюджет на API-виклики.
• Необхідність зменшити затримку генерації відповідей.

Механізм роботи:

1. Система знаходить 15-20 релевантних фрагментів.
2. LLM аналізує та видаляє дублікати, периферійну інформацію.
3. Залишається 50-70% оригінального контексту з найважливішою інформацією.

Результат: менша вартість та швидша генерація і водночас потенційна втрата деталей. Для нашого тесту з короткими фрагментами з Вікіпедії дистиляція була надлишковою, але в продакшні з великими корпоративними документами вона критично важлива.

Semantic та Agentic chunking: потужні інструменти для правильних задач

Semantic chunking (0.7229) та Agentic chunking (0.699-0.7137) показали результати нижче базових підходів. Це не означає, що вони гірші — просто наш датасет не розкрив їхній потенціал.

Semantic chunking ефективний для:

• Багатотемних документів — довгих статей із кількома розділами про різні аспекти.
• Слабоструктурованого контенту — текстів без чітких заголовків.
• Змішаних форматів — документів із переплетеними темами.

Agentic chunking незамінний для:

• Хаотичних корпусів — транскриптів зустрічей, неформальних нотаток.
• Складних технічних документів — файлів, у яких контекст важливіший за структуру.
• Динамічного контенту — документів з непередбачуваною структурою.

Чому вони не спрацювали в нашому тесті: статті з Вікіпедії вже мають відмінну структуру з чіткими заголовками. Markdown chunking ефективно розбивав їх по логічних межах, тому додаткова семантична або агентна обробка не давала переваг, лише збільшувала вартість.

Проміжний висновок: для нашої корпоративної документації (яка хоч і хаотична, але має базову Markdown структуру) складні підходи не виправдали себе. Простота перемогла складність.

Детальний аналіз за метриками

Answer Correctness:

• Wikipedia: Markdown + hybrid search (0.7559) переміг завдяки простоті підходу.
• Notion: Markdown + hybrid search (0.6013) також лідирує, але з нижчими показниками через складність корпоративних даних.
• Висновок: прості підходи стабільно працюють краще на обох типах даних.

Answer Correctness — Датасет 1. Wikipedia (структуровані дані):

Answer Correctness — Датасет 2. Notion (корпоративні дані):

Answer Relevancy:

• Wikipedia: Hybrid search (0.8506) завдяки точному BM25 пошуку за ключовими словами.
• Notion: Hybrid search (0.6079) також переміг, але зі значно нижчими показниками через хаотичну структуру.
• Різниця: 28% падіння релевантності на реальних корпоративних даних.

Answer Relevancy — Датасет 1. Wikipedia (структуровані дані):

Answer Relevancy — Датасет 2. Notion (корпоративні дані):

Context Precision:

• Wikipedia: Symbol chunking + hybrid (0.9083) через дрібні, точні фрагменти.
• Notion: Markdown chunking + hybrid (0.8030) — структуроване розбиття критично важливе для хаотичних документів.
• Зміна лідера: на неструктурованих даних переміг механічний структурований підхід.

Context Precision — Датасет 1. Wikipedia (структуровані дані):

Context Precision — Датасет 2. Notion (корпоративні дані):

Context Recall:

• Wikipedia: Markdown + hybrid (0.7475) точно витягує потрібні абзаци.
• Notion: Markdown + hybrid (0.7810) навіть краще працює на корпоративних даних.
• Несподіванка: Recall на Notion виявився вищим за Вікіпедію.

Context Recall — Датасет 1. Wikipedia (структуровані дані):

Context Recall — Датасет 2. Notion (корпоративні дані):

Faithfulness:

• Wikipedia: Markdown + hybrid (0.7067) мінімізує галюцинації.
• Notion: Semantic chunking + enhanced search + distillation (0.6711) несподівано переміг.
• Зміна лідера: на складних даних більш складні підходи показали кращу вірність джерелам.

Faithfulness — Датасет 1. Wikipedia (структуровані дані):

Faithfulness — Датасет 2. Notion (корпоративні дані):

Аналіз вартості операцій

Окрім якісних метрик, критично важливо розуміти економічні аспекти різних підходів. Ось детальний розбір вартості кожного етапу:

Вартість інгестінгу (обробка та індексація документів)

Аналіз різниці: датасет Notion коштує в 3.5-2.4 рази дорожче через більший обсяг та складність документів. Найбільша різниця у простих підходах (symbol/markdown), найменша — у складних (agentic).

Вартість виконання запитів

Драматичне зростання вартості: датасет Notion коштує в 5.7-6.2 рази дорожче для запитів через складність корпоративних документів та довші контексти.

Парадокс Context Distillation: Context distillation теоретично має зменшувати вартість через скорочення контексту для фінальної генерації. Однак у нашому експерименті він збільшив вартість у всіх конфігураціях.

Причини збільшення вартості:

1. Додатковий LLM-виклик: дистиляція потребує окремого API виклику для аналізу та стиснення контексту.
2. Короткі фрагменти Wikipedia: наші тестові чанки були відносно невеликими (200-800 токенів), тому економія на генерації мінімальна.
3. Overhead процесу: вартість аналізу контексту перевищила економію від скорочення.

Коли Context Distillation економічно виправданий:

• Великі корпоративні документи (>5,000 токенів на чанк).
• Складні запити з багатьма релевантними фрагментами.
• Висока частота запитів, де економія на генерації накопичується.

Чому в agentic-конфігурації дистиляція знизила вартість: Agentic chunking створює більші, менш структуровані фрагменти з багатьма дублікатами. Дистиляція ефективно очищає цей «шум» і економія від скорочення контексту перевищує вартість додаткового LLM-виклику.

Самарі

1. Обрана комбінація: Markdown chunking + Enhanced hybrid search
2. Хоча базовий Hybrid search показав найкращі результати в тестах, для продакшну ми обрали Enhanced hybrid search через кілька причин:
   
   • Реальні запити складніші за тестові — користувачі формулюють запитання менш чітко, ніж синтетично згенеровані запити.
   • Трансформація запиту критична для продакшну — покращення та розбиття запитів значно підвищує якість для неструктурованих запитань.
   • Прийнятна різниця у вартості — додаткові витрати на LLM-обробку запитів виправдані кращим UX.
3. Markdown chunking + Hybrid search — переможець тестів: показав найкращі результати на обох датасетах з синтетичними запитами, підтверджуючи ефективність простих підходів для структурованих запитань.
   
   • Структурованість даних критично впливає на результати:
     
     • На датасеті Wikipedia різниця між підходами мінімальна (1-2%).
     • На датасеті Notion різниця більша (до 8.7% між symbol та markdown chunking).
4. Enhanced search не виправдав очікувань: програв на обох датасетах, навіть на складних корпоративних запитах. Синтетично згенеровані запити виявилися недостатньо складними.
5. Context distillation показав змішані результати: покращив точність, але знизив коректність. На корпоративних даних ефект менш виражений.
6. Вартість зростає експоненційно: корпоративні дані коштують в 3.5-6.2 рази дорожче через складність та обсяг контексту.
7. Semantic та agentic chunking не показали переваг: навіть на хаотичних корпоративних документах прості підходи виявилися ефективнішими.

Наші кейси використання цієї системи

Після завершення розробки та тестування ми впровадили RAG-систему в щоденну роботу команди. За кілька місяців використання виділили 4 основні сценарії, де система показала найбільшу ефективність.

1. Онбординг нових співробітників

Найбільший ефект система показала у процесі онбордингу. Раніше новий розробник витрачав багато часу на вивчення розкиданої в Notion документації, намагаючись зрозуміти архітектурні рішення та бізнес-логіку. Система не просто знаходить відповідні документи, а надає контекстуальні відповіді з посиланнями на джерела. Новачок отримує не фрагменти документації, а цілісне розуміння рішень з історичним контекстом.

Тож менторам більше не потрібно повторювати одні й ті самі пояснення — система бере на себе роль «першої лінії підтримки» для базових запитань.

2. Пошук технічної документації для рефайментів

В роботі над технічними рефайментами критично важливо розуміти, чому система побудована саме так. Часто рішення, які здаються нелогічними, мають глибокі причини, закопані в старих обговореннях. Система дозволяє швидко знаходити не тільки технічні специфікації, але й контекст ухвалення рішень, що критично важливо для якісного рефайменту.

3. Аналіз транскрипцій зустрічей

Одна з найцікавіших можливостей системи — робота з транскрипціями зустрічей. У Notion ми зберігаємо записи всіх важливих зустрічей і система може знаходити в них специфічні обговорення. Вона аналізує не тільки формальні рішення, але й контекст обговорень — хто які аргументи наводив, які альтернативи розглядали, які ризики обговорювали.

4. Пошук бізнес-контексту

Розробникам часто потрібно розуміти не тільки «як» реалізувати фічу, але й «чому» вона потрібна. Система допомагає швидко знаходити продуктовий контекст технічних рішень.

Повна інтеграція з Notion дозволила системі працювати не тільки з базами даних, але й зі звичайними сторінками, де часто зберігається найцінніший контекст — неформальні нотатки, гіпотези, результати досліджень.

Висновки

Побудова власної RAG-системи стала одним із найцікавіших технічних викликів мого останнього року. Процес від ідеї до робочого MVP зайняв кілька місяців, але результат перевершив очікування. Які ключові уроки я виокремив із цього досвіду:

• LLM-технології кардинально змінюють підхід до роботи з інформацією. Правильно використовуючи їх, можна вирішити велику кількість бізнес-проблем, які раніше здавалися нерозв’язними. Головне — не намагатися застосувати AI всюди, а знайти справжні болі, де технологія дає максимальну віддачу.
• Тестування має передувати реалізації. Якби ми почали з систематичного тестування різних підходів, а не з побудови системи «на інтуїції», то заощадили б багато часу. Експерименти з чанкінгом, пошуком та аугментацією показали, що найпростіші рішення часто виявляються найефективнішими.
• Контроль над кожним компонентом критично важливий. Готові рішення типу N8N підходять для простих випадків, але для продакшну RAG-системи потрібна можливість налаштовувати кожен етап pipeline. Від якості чанкінгу до параметрів пошуку — все має значення.

Що ми зробили б по-іншому

Якби почали проєкт спочатку, то одразу б зосередилися на систематичному тестуванні різних підходів. Створили б тестовий датасет, налаштували метрики оцінки та протестували всі основні стратегії перед початком розробки основної системи.

Також раніше почали б експериментувати з векторними базами даних. PostgreSQL з pgvector виправдав себе для MVP, але міграція на спеціалізовані рішення типу Qdrant дасть кращу продуктивність та гнучкість.

Серед наших короткострокових цілей:

• Інтеграція з YouTrack — додати тисячі технічних задач з детальними обговореннями в коментарях.
• Підключення Slack — індексувати важливі обговорення з робочих каналів.
• Покращення пошуку — експериментувати з reranking-моделями та гібридними підходами.

Та RAG-система — це лише перший крок до глобальної мети. В довгостроковій візії ми бачимо її не тільки як інструмент запитань-відповідей для співробітників, але й як «пам’ять» для майбутньої агентної системи.

Уявіть AI-агентів, які мають доступ до всіх знань компанії та можуть:

• Проактивно допомагати в роботі — нагадувати про важливі деталі під час code review.
• Попереджати про потенційні проблеми — аналізувати нові рішення на основі минулого досвіду.
• Автоматизувати рутинні задачі — генерувати документацію, створювати онбординг-матеріали, аналізувати технічний борг.

Так корпоративні знання стануть не просто базою для пошуку, а активним учасником робочих процесів. RAG-система, яку ми побудували — це фундамент для такої системи. І побудова цього фундаменту показала, що сучасні LLM-технології вже готові для серйозного корпоративного використання. Головне — підходити до них не як до магічного розвʼязання всіх проблем, а як до потужного інструменту, який потребує обміркованого застосування.

Сподіваюся, наш досвід допоможе іншим командам уникнути типових помилок та швидше дійти до робочих рішень. Адже технології розвиваються швидко, але принципи залишаються ті самі: розуміти проблему, тестувати гіпотези та будувати системи поступово.