Впровадження RAG: архітектура, поділ на фрагменти, векторні бази даних та оцінювання

Що таке впровадження RAG і як воно працює?

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

Продакшен-архітектура RAG має два конвеєри:

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

Більшість збоїв RAG виникає в першому конвеєрі, а не в моделі. Якщо таблицю розібрано як шум чи політику розрізано навпіл, жодна модель не відновить відповідь. Цей посібник проходить кожен етап так, як ми підходимо до нього в Lytvynov Production. Про те, як ми реалізуємо проєкти, читайте на сторінці розробки RAG.

Як завантажувати й розбирати документи?

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

Поширені джерела та що їм потрібно:

• PDF та офісні файли: розбір з урахуванням верстки, що зберігає заголовки, списки й таблиці; OCR для сканованих сторінок.
• Вікі та довідкові центри (Confluence, Notion, Zendesk, Intercom): API-конектори, що також підтягують права доступу й час оновлення.
• Тікети, чати й листи: відновлення гілок, видалення дублікатів цитованих відповідей і підписів.
• Бази даних і каталоги товарів: перетворювати записи на короткий читабельний текст або звертатися до них напряму через інструменти замість створення ембедингів.

Приведення багатьох неохайних форматів до однієї чистої таблиці часто найскладніша частина. У проєкті AI Grief Companion ми написали парсери для десяти форматів експорту чатів (WhatsApp, Messenger, Instagram, Discord, iMessage з резервної копії iPhone, SMS з Android та інших) і привели їх усі до однієї таблиці повідомлень ще до будь-якого кроку з ШІ. Той самий урок стосується бізнес-даних: спершу інвестуйте в єдину нормалізовану модель. Наша платформа календаря спортивних подій показує ту саму дисципліну поза ШІ: рушій розбору об'єднує дані із сотень зовнішніх календарів.

Яку стратегію поділу на фрагменти обрати?

Діліть спершу за структурою документа, а потім за розміром. Розбивайте за заголовками, розділами, пунктами списків чи гілками повідомлень, а потім обмежуйте фрагменти розміром, що вміщує одну завершену думку, зазвичай 200-800 токенів із невеликим перекриттям.

Додавайте контекст до кожного фрагмента: ставте на початок заголовок документа й шлях розділу ("Політика повернень > Клієнти з ЄС > Цифрові товари"), щоб фрагмент мав сенс сам по собі. Цей один крок часто покращує пошук більше, ніж зміна моделі ембедингів.

Як обрати модель ембедингів?

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

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

Яку векторну базу даних обрати для RAG?

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

Для SaaS-клієнтів на PostgreSQL ми за замовчуванням обираємо pgvector, бо права доступу й ідентифікатори клієнтів (tenant ID) лежать поруч із векторами, і стає на одну систему менше, яку треба захищати. На окремий рушій ми переходимо, коли це виправдовують масштаб чи потреби у фільтрації.

Навіщо гібридний пошук і переранжування?

Гібридний пошук поєднує пошук за ключовими словами (BM25) з векторним пошуком, бо кожен знаходить те, що пропускає інший. Векторний пошук розуміє перефразування; пошук за ключовими словами ловить точні коди товарів, повідомлення про помилки, імена та абревіатури. Потім переранжувальник (reranker) упорядковує об'єднаних кандидатів за справжньою релевантністю запитанню.

Типовий потік запиту: переписати запитання користувача на самодостатній пошуковий запит (розкрити "це" й "те" з контексту розмови), паралельно виконати пошук за ключовими словами й векторний пошук із фільтрами прав доступу, об'єднати результати (reciprocal rank fusion - простий метод), переранжувати 30-50 найкращих кандидатів за допомогою cross-encoder чи API переранжування й залишити 5-10 найкращих для промпту. Переранжування зазвичай дає один із найбільших приростів якості на годину інженерної роботи в RAG-проєкті.

Як скласти промпт і додати посилання на джерела?

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

Після генерації перевіряйте посилання в коді: кожен вказаний ідентифікатор має бути серед знайдених, а відповіді з фактичними твердженнями без посилань можна позначати чи генерувати заново. Показуйте посилання в інтерфейсі як лінки на оригінальний документ і розділ. Користувачі довіряють відповідям, які можуть перевірити, а команди підтримки можуть виправити документ-джерело замість того, щоб сперечатися з ШІ. Ширшу картину інтеграції (стримінг, обмеження, витрати) дивіться в посібнику про інтеграцію ChatGPT або Claude у застосунок.

Як працювати з правами й контролем доступу в RAG?

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

Ніколи не покладайтеся на промпт, щоб приховати вміст ("не розкривай документи HR"), бо модель можна вмовити порушити інструкції. Швидко синхронізуйте зміни прав із систем-джерел і видаляйте фрагменти, коли видаляються документи. У мультитенантному SaaS фільтр за клієнтом у кожному запиті обов'язковий, і ми додаємо автоматичні тести, які намагаються дістати дані іншого клієнта. Чутливий вміст може також потребувати шифрування під час зберігання; платформа AI Grief Companion шифрує кожне повідомлення під час завантаження окремим ключем AES-256-GCM і підтримує видалення всього одним кліком.

Як оцінювати RAG-систему?

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

• Еталонний набір: 100-300 реальних запитань з еталонними відповідями й документами-джерелами, які мають бути знайдені. Додайте запитання, на які в корпусі немає відповіді.
• Метрики пошуку: recall at k (чи з'явився правильний фрагмент серед перших k?) та якість ранжування.
• Метрики генерації: вірність джерелам (чи кожне твердження підтверджене знайденими фрагментами?), релевантність відповіді, повнота й точність посилань. Друга модель може оцінювати це за рубрикою, а люди перевіряють вибірку.
• Сигнали з продакшену: оцінки "палець вниз", перефразування запитання, ескалації до людини та запитання без відповіді.

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

Як підтримувати RAG-індекс актуальним?

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

Вебхуки із систем-джерел дають оновлення майже в реальному часі; для повільнішого вмісту достатньо запланованих завдань (щогодини чи щоночі). Додайте в пошук метадані актуальності, щоб новіші версії політики ранжувалися вище за старіші, і архівуйте застарілі документи замість того, щоб дозволяти їм конкурувати. Моніторте завдання синхронізації, як будь-який інший продакшен-конвеєр, бо тихий збій синхронізації робить асистента впевнено хибним щодо змін минулого місяця.

Які найпоширеніші збої RAG?

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

RAG, fine-tuning чи довгий контекст: що обрати?

Обирайте RAG для знань, fine-tuning для поведінки, а довгий контекст для невеликого матеріалу, що змінюється з кожним запитом. Ці підходи доповнюють, а не конкурують один з одним, і багато продакшен-систем використовують два з них разом.

Платформа AI Grief Companion - реальний приклад поєднання підходів. Вона будує профіль особистості, граф фактів у Neo4j і підготовку до RAG з історії чатів користувача та навчає LoRA-адаптери (SFT і CPT на Qwen2.5-7B з 4-бітним QLoRA) під манеру однієї конкретної людини, а vLLM завантажує потрібний адаптер у момент запиту. Чат використовує той етап, який уже готовий, тож розмова можлива ще до завершення навчання. Fine-tuning відповідає за те, як людина пише; пошук - за те, що вона казала.

Як ми працюємо над RAG-проєктами

У Lytvynov Production ми починаємо RAG-проєкти з короткої розмови для оцінки обсягу: дивимося на вибірку ваших реальних документів і запитання, які ставлять користувачі, а потім даємо фіксовану ціну на розробку. На першому етапі ми створюємо еталонний набір і тестуємо на ньому розбір і пошук. Далі працюємо етапами й звітуємо про оцінки якості на кожному з них. Якщо ви плануєте асистента по базі знань чи чат-бота на ШІ на корпоративних даних, зв'яжіться з нами.