Проєктування архітектури RAG-пайплайна

Чому RAG-пайплайн відповідає неточно на складні запитання

Асистент відповідає впевнено й гладко — але жодного факту з вашого документа у відповіді немає.

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

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

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

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

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

Асистент транслює скасоване правило з такою ж упевненістю, як і чинне, — і розходження виявляє вже людина, яка читає першоджерело.

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

Що дає керована архітектура пошуку й генерації

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

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

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

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

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

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

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

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

Порівняння варіантів: векторний, гібридний і графовий пошук

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

Що змінюється на етапі видачі

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

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

Етапи роботи: від аудиту даних до передачі в підтримку

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

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

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

Технічна документація, схеми та регламенти оновлення

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

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

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

Кейс: як прибрали відповіді без опори на джерела

Асистент із внутрішньої бази знань відповідав упевнено, але в третині випадків посилання на документ у відповіді не було: модель добудовувала формулювання з пам’яті.

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

Що змінили

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

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

Метрики до та після

Частка відповідей без опори на джерело — 34% → 4%, середній час відповіді — 9 → 2,5 секунди, звернення в живу підтримку з типових питань — мінус 41%.

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

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

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

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

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

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

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

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

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

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

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

Питання, які ставлять інженери замовника

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

Як ділите документи на частини, щоб відповіді не втрачали сенс?

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

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

Як переконатися, що система не вигадує відповіді?

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

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

Документи змінюються щодня — як оновлюється база знань?

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

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

Де розміщується контур і як розмежовуються права?

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

Обговорення задачі: які вхідні дані пришвидшать оцінку

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

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

• Корпус знань: які документи відповідають на запитання (регламенти, інструкції, база звернень), у яких вони форматах, як часто оновлюються та хто відповідає за актуальність.
• Реальні запити: 20–30 формулювань від співробітників або клієнтів, включно з неточними та багатотемними, — на них ми перевіримо якість пошуку.
• Джерела й доступи: де лежать дані, чи є вивантаження або тестовий контур, які обмеження на зберігання та обробку діють.
• Вимоги до відповіді: чи обов’язкове посилання на джерело, що вважається неприпустимою помилкою, яка відповідь краща — «не знаю» чи приблизна.
• Критерії готовності: за якими питаннями і з якою часткою правильних відповідей рішення вважається прийнятим і хто з боку замовника це підтверджує.
• Інфраструктура: де працюватиме сервіс, чи допустимі зовнішні сервіси, чи потрібна робота в закритому контурі.
• Сценарій використання: хто ставить запитання, через який інтерфейс і скільки запитів на день очікується.

Такий набір закриває основні розвилки архітектури одразу — і ми пропонуємо план поетапної перевірки якості, а не загальні строки «на розробку».