Розробка RAG: точні відповіді ШІ на основі знань вашої компанії

Що таке розробка RAG і коли вона потрібна вашій компанії?

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

Типові впровадження RAG, про які нас питають:

• Внутрішній асистент, що відповідає на запитання працівників на основі політик, регламентів і вікі.
• Асистент підтримки клієнтів, що спирається на статті довідкового центру й вирішені тікети (див. розробка чат-ботів на ШІ).
• Пошук і відповіді на запитання за договорами, специфікаціями чи технічною документацією.
• Шар "пам'яті" для ШІ-продукту, щоб асистент пам'ятав факти про конкретного користувача чи акаунт.

Як працює RAG-конвеєр у продакшені?

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

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

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

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

Які ембединги й векторну базу даних використовувати?

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

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

Як виміряти точність RAG?

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

Ми відстежуємо чотири показники:

1. Влучність пошуку: чи з'явився правильний фрагмент серед найкращих результатів?
2. Достовірність: чи стверджує відповідь лише те, що є в знайдених фрагментах?
3. Правильність відповіді: чи збігається відповідь з очікуваною за оцінкою рецензента або LLM-оцінювача, звіреного з прикладами від людей?
4. Якість відмов: коли відповіді немає в базі знань, чи каже про це система, замість вигадувати?

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

А як щодо приватності даних, прав доступу й вибору моделі?

RAG-система ніколи не має показувати користувачеві фрагмент, який він не зміг би відкрити в оригінальному джерелі. Ми зберігаємо правила доступу як метадані фрагментів і фільтруємо під час пошуку, тож права застосовуються ще до того, як модель щось побачить. Чутливі дані можна шифрувати під час приймання: у нашому проєкті AI Grief Companion кожне повідомлення шифрується окремим ключем AES-256-GCM у KMS-конверті, а користувач може видалити все одним кліком.

Для етапу генерації ми працюємо з API OpenAI та Anthropic Claude, а також з відкритими моделями, що працюють на вашій власній інфраструктурі (той самий проєкт запускає адаптери Qwen2.5-7B через vLLM). Вибір залежить від правил роботи з даними, мов, затримки й вартості відповіді. Промпти зберігаються в базі даних з історією версій там, де це корисно, тож тон та інструкції можна налаштовувати без релізу коду.

Скільки коштує розробка RAG?

Вартість розробки RAG залежить переважно від того, скільки джерел ви підключаєте, наскільки вони хаотичні й наскільки суворі вимоги до точності та прав доступу. Proof of concept на одному джерелі з тестовим набором зазвичай займає 3-6 тижнів; асистент для продакшену з кількома джерелами, правами доступу й інтерфейсом займає 2-4 місяці; RAG на рівні платформи для кількох продуктів із власними моделями потребує більше часу.

Витрати на роботу рахуються окремо: токени моделі на кожну відповідь, вартість ембедингів при кожному переіндексуванні й хостинг векторної бази даних. Під час proof of concept ми рахуємо вартість 1 000 запитань, щоб не було несподіванок, і після короткої розмови для оцінки обсягу даємо фіксовану ціну на погоджені етапи. У нас RAG-асистент за вашими знаннями коштує від 5 000 USD; наш посібник про вартість розробки чат-бота на ШІ розбирає більші обсяги.

Де ми будували RAG і LLM-системи?

Наша найповніша робота з пошуком - AI Grief Companion для американського стартапу: шлюз приймання даних на Python розбирає десять форматів експорту чатів в одну нормалізовану таблицю повідомлень, а ML-конвеєр будує профіль особистості, граф фактів у Neo4j, пам'ять на RAG і адаптери LoRA. Чат завжди використовує той етап, який уже готовий, тож користувачі можуть спілкуватися із системою ще до завершення навчання.

З продуктового боку AI Resume Master, наш власний конструктор резюме, використовує LLM, щоб генерувати, переписувати й покращувати резюме та супровідні листи, і досяг 50 000 активних користувачів на місяць. Ширшу картину додавання функцій на LLM у наявний продукт дивіться на сторінці інтеграція ШІ і в нашому посібнику з впровадження RAG.

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

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

Якщо у вас є база знань, про яку люди постійно ставлять ті самі запитання, запишіться на консультацію і принесіть п'ять прикладів запитань. Ми чесно скажемо, чи RAG тут правильний інструмент.