RAG у бізнесі: як створити AI-пошук по документах компанії без витоку даних

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

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

Разом із Марком Мотлюком, AI Tech Lead у Genesis, HBJ розбирається, як працює RAG, з яких компонентів складається така система, яких помилок варто уникати під час її впровадження та як захистити корпоративні дані.

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

Retrieval-augmented generation (RAG) — це підхід, за якого мовна модель формує відповіді не лише на основі знань, отриманих під час навчання, а й із урахуванням актуальної інформації із зовнішньої бази знань. Для цього система спочатку знаходить релевантні фрагменти документів, додає їх як контекст, а вже потім модель генерує відповідь.

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

Наприклад, менеджер запитує: «Коли варто надіслати повідомлення про розірвання договору з підрядником?». Система знаходить відповідний пункт у договорі, передає його моделі й генерує відповідь із посиланням на джерело.

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

Які бізнес-задачі вирішує AI-пошук по документах

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

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

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

З яких компонентів складається RAG-система

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

Далі система витягує текст із документів різних форматів (PDF, DOCX, таблиць або HTML) і ділить його на логічні фрагменти (chunks), щоби знаходити не весь документ, а лише релевантні частини.

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

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

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

Як підготувати документи для корпоративного AI-пошуку

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

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

У команді Марка Мотлюка, AI Tech Lead у Genesis дотримуються підходу, який складається з набору незалежних етапів: отримання документа, перетворення в єдиний формат, очищення, збагачення метаданими, поділ на фрагменти та індексація. Такий підхід спрощує розвиток системи й допомагає підтримувати RAG-базу знань в актуальному стані.

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

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

Як захистити корпоративні дані від витоку

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

За словами Марка Мотлюка безпеку потрібно закладати в архітектуру системи ще на етапі проєктування.

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

Інфраструктуру RAG слід захищати так само, як будь-яку іншу внутрішню систему: обмежувати службові доступи тільки всередині мережі компанії й регулярно проводити пентести. Для роботи з моделями важлива прозора політика обробки даних LLM-провайдерів. Компанії потрібна не лише гарантія, що дані не використовуються для навчання нових моделей, а повний zero data retention».

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

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

Як перевіряти якість відповідей RAG

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

«Ми починаємо створення будь-якої AI-системи з побудови датасету для end-to-end оцінювання, або Eval. Для кожного тестового запитання є перелік фактів чи тез, які повинна містити правильна відповідь. Далі результат автоматично оцінює окрема LLM — це підхід LLM-as-a-Judge, — розповідає фахівець. — Ми перевіряємо не лише загальну правильність відповіді, а й її повноту, опору на знайдені джерела, коректність цитувань і відсутність вигаданих тверджень.

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

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

Типові помилки під час впровадження RAG

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

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

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

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

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

«По-перше, ще до початку роботи варто врахувати total cost of ownership і переконатися, що для конкретного сценарію справді потрібна RAG-система. У деяких випадках достатньо MCP-серверів або skills, які напряму працюють із корпоративними системами та отримують актуальні структуровані дані.

По-друге, паралельно з MVP потрібно створювати Eval. Тобто end-to-end набір тестів із реальними запитаннями користувачів і переліком того, що має містити якісна відповідь. Без цього системно покращувати систему практично неможливо.

І нарешті, не обов'язково будувати всю інфраструктуру з нуля. Уже існує багато open-source конекторів, інструментів для обробки документів і компонентів observability, які допомагають значно швидше запустити RAG».

FAQ

Чим RAG відрізняється від навчання власної AI-моделі?

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

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

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

Яка база даних потрібна для RAG?

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

Як зрозуміти, що RAG відповідає правильно?

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