Пояснення базового процесу RAG: від сирих документів до обґрунтованих відповідей.

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

Метод генерації з пошуком даних, який зазвичай скорочують до RAG, є стандартним рішенням. Система RAG дозволяє моделі звертатися до зовнішніх джерел інформації саме тоді, коли це необхідно. Не все мусить зберігатися в пам’яті моделі, адже система шукає у надійній базі знань, вибирає найбільш релевантні фрагменти та формулює відповідь, ґрунтуючись на них. Простіше кажучи, асистент із «закритою книгою» стає асистентом із «відкритою книгою».

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

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

У наступних розділах ця ідея розглядається з самого початку.

Що насправді робить RAG

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

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

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

Вибір джерела знань

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

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

Перш ніж індексувати щось, корисно поставити кілька практичних запитань:

• Чи є інформація точною та актуальною?
• Хто є власником цієї інформації?
• Чи мають усі користувачі дозвіл на її перегляд?
• Чи існують дублікати чи суперечливі версії?
• Чи потребують таблиці, зображення, примітки чи юридичні положення особливого оброблення?

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

Очищення та підготовка документів

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

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

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

Розділення документів на фрагменти

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

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

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

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

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

Створення ембеддингів

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

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

Саме така семантична відповідність пояснює, чому щільний пошук став важливим у відповідях на запитання з відкритої області. Дослідження Dense Passage Retrieval 2020 року показало, що навчені щільні представлення можуть перевершити потужний базовий алгоритм BM25 у кількох тестах щодо пошуку відповідей у відкритій області.

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

Зберігання ембеддингів у векторній базі даних

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

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

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

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

Отримання відповідних фрагментів

Процес надання відповідей починається, коли користувач ставить запит. Система вбудовує запит, шукає у векторному сховищі та повертає найбільш відповідні фрагменти. Фахівці називають це методом пошуку типу top-k, де k позначає кількість фрагментів, які повертаються; top-5 означає п’ять найбільш відповідних фрагментів.

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

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

Саме тому популярним є гібридний пошук. Він поєднує пошук за векторами з пошуком за ключовими словами у повному тексті та об’єднує отримані результати. Наприклад, Azure AI Search описує гібридний пошук як єдиний запит, який одночасно виконує обидва типи пошуку та об’єднує ранжовані результати за допомогою методу Reciprocal Rank Fusion. Простими словами, система має два шляхи до відповіді: через значення та через точну формулювання.

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

Складання запиту

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

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

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

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

Генерація відповіді

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

Гарний приклад: «Лептопи, що пройшли ремонт, мають бути повернуті протягом 14 днів після доставки. У правилах не зазначено жодних винятків щодо повернення протягом 20 днів, тому згідно з наданими правилами запит на повернення після 20 днів не буде прийнятий». Цей приклад ефективний, тому що він формулює правило, застосовує його до ситуації користувача та не вдає, ніби існує виняток, коли у джерелі його немає.

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

Оцінка процесу

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

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

Після цього перегляньте сформовану відповідь. Чи вона відповідає контексту? Чи містить вона твердження, які ніхто не підтримує? Чи вона стосується справжнього запитання та посилається на правильне джерело? Якщо документи виявилися недостатніми, чи визнається це?

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

Базовий цикл оцінки може відстежувати:

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

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

Де виникають проблеми у базових підходах

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

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

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

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

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

Проста архітектура

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

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

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

Для опанування цього не потрібна складна система. Для невеликого прототипу достатньо п’яти елементів: кількох документів у папці, моделі ембеддингу, місця для зберігання векторів, механізму пошуку та моделі чату. Важливо зрозуміти кожен крок та не сприймати весь процес як „чорну скриньку“.

Що робить пайплайн хорошим

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

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

Що робити далі

Як тільки проста система почне ефективно працювати, існує кілька можливостей для її покращення:

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

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

Переписуйте нечіткі запити на більш зрозумілі.

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

Створюйте панелі керування для моніторингу якості з часом.

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

Чому варто це вивчати

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

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