Розробка RAG-системи (Retrieval-Augmented Generation)

Розробка RAG-системи: де ламається пошук відповідей

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

Тому розробка RAG-системи починається з діагностики корпусу та стратегії вилучення, а не з вибору моделі.

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

• Розрізнений корпус. Регламенти лежать у wiki, договори — у файловому сховищі, листування — у пошті. Поки немає єдиної схеми метаданих і власника в кожного набору, пошук по базі знань не може відфільтрувати потрібний розділ і повертає суміш із різних галузей.
• Пошук за точними словами. Лексичний збіг на кшталт BM25 в Elasticsearch не бачить синонімів і перефразувань: «відпустка» та «щорічний оплачуваний відпочинок» для нього різні слова, і половина релевантних документів залишається за бортом.
• Відповіді без джерела. Якщо відповіді з посиланням на джерело не вбудовані у видачу за замовчуванням, перевірити твердження неможливо. Співробітник або йде читати документ сам, або перестає користуватися асистентом.
• Застарілі копії. Кілька редакцій одного документа в індексі дають суперечливі відповіді, а правка в джерелі не доїжджає до пошуку: асистент цитує скасовану версію.

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

Що змінюється після запуску: швидкість і клас відмов

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

Після запуску відповідь збирається з проіндексованих документів за секунди — і надходить разом із посиланням на конкретний розділ джерела.

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

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

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

Окремо закривається клас відмов через застарілі дані — при оновленні документа попередня редакція витісняється з індексу, і стара інструкція перестає потрапляти у відповіді.

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

До і після запуску ми знімаємо один і той самий набір: час до відповіді, частку відповідей із посиланням, частку відмов «не знайдено» і кількість ескалацій на другу лінію — розбіжність за цими числами і є виміряний результат запуску.

Варіанти архітектури: порівняння підходів до пошуку

Архітектура RAG тримається не на моделі генерації, а на тому, як улаштований пошук по корпусу.

Векторний пошук ловить смислові збіги, але втрачає артикули, абревіатури й заперечення; лексичний — навпаки, точний у рідкісних термінах, але безпорадний перед переказом думки своїми словами. Режим обирають під характер запитів і ціну помилки у відповіді, а не «за замовчуванням».

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

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

Етапи впровадження: від аудиту корпусу до передачі

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

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

1. Аудит корпусу документів. Дивимося формати, дублі, редакції, строк придатності та права доступу. На виході — карта корпусу з часткою придатних до індексації матеріалів і списком того, що доведеться чистити або дописувати.
2. Схема контурів. Розділяємо пошук і генерацію: що віддаємо в індекс, що йде в модель, де стоїть фільтр за правами користувача. Так відповідь не збереться з документів, недоступних конкретному співробітнику.
3. Підготовка даних і складання пошукового індексу. Нарізка на фрагменти за смисловими межами, векторні представлення, гібридний пошук із переранжуванням. Дрібні фрагменти дають точність, великі — контекст; баланс підбираємо за вимірами.
4. Налаштування відповідей. Системна інструкція, правила цитування, поведінка за відсутності даних: система каже «у базі немає», а не добудовує факти. Окремо описуємо, як обробляються суперечності між редакціями.
5. Тестування відповідей на реальних питаннях. Набір еталонних питань від ваших співробітників, включно з каверзними та пограничними. Рахуємо частку коректних відповідей із посиланням, частку чесних відмов і розбираємо кожну помилку до причини.
6. Передача. Конфігурації, регламент оновлення корпусу, скрипти переіндексації, метрики та інструкції для підтримки. Після передачі команда замовника може додавати документи, не ламаючи якість відповідей.

Що передаємо на руки: індекс, схеми, регламенти

Передача рішення — не архів із вихідними кодами, а комплект, за яким ваша команда зможе сама експлуатувати та розвивати систему. Що фізично опиниться у вас на руках:

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

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

Кейс: відповіді за регламентами замість ручного пошуку

Внутрішня база знань виробничого холдингу «Северный контур» — близько 4 000 документів: регламенти, накази, інструкції з охорони праці, шаблони договорів.

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

Що змінили

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

Індекс побудували за смисловими блоками, а не за файлами цілком, — питання про відпустку знаходить конкретний пункт, а не шістдесятисторінковий документ.

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

Що стало

Частка питань, закритих без ескалації, зросла з 38% до 79%, медіана часу до відповіді — з 20 хвилин до 40 секунд. Точність влучання в потрібний пункт на контрольній вибірці — 9 із 10 звернень.

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

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

Чим відрізняється RAG-пошук від дообучення моделі?

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

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

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

Перевірюваність у RAG вбудована: кожна відповідь розкладається на фрагменти-джерела, і видно, звідки взялося формулювання.

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

Обсяг даних теж розводить підходи. Дообучення вимагає тисяч узгоджених пар «питання — еталонна відповідь» і розмітки, інакше якість на домені падає. RAG запускається на кількох сотнях документів і працює з ними як є — включно з таблицями та сканами після розпізнавання.

Є і зворотний бік: дообучення краще задає стиль, формат і термінологію — модель починає писати так, як прийнято у вас. Тому вибір іде не «або-або»: спочатку RAG закриває роботу зі знанням, а дообучення додають точково, якщо потрібен свій голос. Далі розбираємо, як це виглядає в реалізації.

Технічні сумніви: якість, оновлення, доступи

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

У співробітників різні права доступу — система це врахує?

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

Чи можна не випускати дані за периметр?

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

Як зрозуміти, що якість відповідей не впала?

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

Чи доведеться перебудовувати поточні системи?

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

Обговоримо задачу і повернемося з планом та оцінкою

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

• Які документи та бази потрапляють у пошук: формати, приблизний обсяг, хто відповідає за їхню актуальність.
• 10–20 реальних питань користувачів і еталонні відповіді на них — за ними налаштовується якість.
• Де система працюватиме: ваш контур або зовнішня інфраструктура, вимоги до доступів і аудиту звернень.
• Сценарії використання: хто запитує, як часто, що вважаємо правильною відповіддю, а що — коректною відмовою.
• Які системи потрібно зв’язати: портал, CRM, месенджери, внутрішні сервіси, довідники.
• Хто з боку замовника приймає результат і за якими критеріями.

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

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

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