Як побудувати локального чат-бота в Kyivstar Cloud: інтерв’ю з Олександром Манчуком

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

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

Тобто RAG допомагає тримати відповіді в межах того, що нам реально потрібно. Проте навіть тут треба розуміти, що ідеальних моделей не буває, адже іноді вони все одно можуть «додумати» щось від себе.

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

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

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

Річ у тім, що дані у кожної компанії різні, і дуже часто вони непрості. Наприклад, стандартні інструменти для розпізнавання тексту добре працюють із простими Word-документами, але коли в документі є таблиці, починаються проблеми. Модель читає їх просто рядок за рядком і не розуміє, що це таблиця, де є зв’язки між стовпцями. А якщо документ — це взагалі скан чи фото, то більшість базових рішень просто «не бачать» потрібну інформацію.

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

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

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

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

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

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

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

Зберігати вектори можна або у спеціалізованих векторних базах (типу Faiss, Qdrant, Milvus), або навіть у звичайних базах даних, адже багато з них уже підтримують це «з коробки». Наприклад, PostgreSQL має розширення pgvector, яке додає можливість зберігати й шукати дані у векторному форматі. Тобто нічого радикально нового встановлювати не потрібно. Додається ще один модуль і можна працювати далі.

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

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

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

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

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

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

Тобто ми допомагаємо пройти головний етап, а далі компанія вже може розвивати це рішення під свої потреби.

Якщо говорити просто, то RAG складається з кількох основних частин, які повинні працювати разом.

По-перше, це мовна модель, яка вміє працювати з RAG-підходом. Тобто вона не просто генерує текст, а може звертатися до зовнішньої бази знань. Таких моделей зараз багато, наприклад, GPT-OSS, Mistral, Gemma та інші.

Друге — векторна база даних. Саме в ній зберігається уся інформація з ваших документів у спеціальному, числовому форматі. Найпопулярніші рішення — FAISS, Qdrant, Milvus або навіть PostgreSQL з розширенням pgvector.

Третій компонент — модель для перетворення тексту у вектори, або, як кажуть, embedding model. Вона «читає» документ і створює його числове представлення — вектор. Один із найвідоміших прикладів — all-MiniLM-L6-v2.

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

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

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

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

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

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

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

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

Якщо коротко, то вектори — це спосіб перетворити текст (або будь-які інші дані) у числа, щоб комп’ютер міг зрозуміти зміст і порівняти його з іншим змістом.

А тепер трішки детальніше. Наприклад, ми маємо текст — документ або сторінку. Щоб комп’ютер міг із ним працювати, його спочатку розбивають на невеликі шматочки по кілька сотень чи тисяч символів. Це потрібно, щоб не «губити» сенс між абзацами. Потім кожен шматочок додатково розбивається на ще менші елементи — токени.

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

Цю послідовність і називають вектором. Схожі за змістом речення мають схожі вектори. Саме тому модель може зрозуміти, що, «автомобіль»  і «машина» — це майже одне й те саме, навіть якщо слова різні.

Якщо спростити, то звичайний пошук шукає за словами (буквально), а векторний пошук — за змістом. Це називається семантичний пошук, коли система розуміє сенс вашого запиту, а не просто збіг символів.

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

Те саме працює не лише з текстом. Наприклад:

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

Тобто будь-що, що можна описати у вигляді даних, можна «перевести» у вектор.

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

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

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

Є також no-code/low-code платформи, де можна створити RAG-систему, з’єднуючи блоки графічно — це дуже зручно для користувачів без глибоких технічних знань. Утім, навіть у таких випадках базове розуміння програмування дуже допомагає, адже під капотом завжди є код.

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

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

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

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

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

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

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

Замовити консультацію можна на сайті Київстар.