Відділ обслуговування клієнтів у компанії, що розробляє програмне забезпечення, щодня витрачає кілька годин на відповіді на одні й ті самі запитання: як скинути пароль, які умови договору, коли виставляється рахунок. Знання є, документи є, але кожен консультант шукає відповіді окремо — у Confluence, Notion, старих електронних листах. Це не проблема відсутності знань. Це проблема доступу до знань у потрібний момент. Корпоративний AI-асистент на базі документів вирішує саме це.
Чим відрізняється корпоративний GPT від звичайного чат-бота
#«Чат-бот» і «RAG-асистент» — це дві різні архітектури, які варто розрізняти перед вибором технології:
| Ознака | Звичайний чат-бот / fine-tuning | RAG-асистент на базі знань |
|---|---|---|
| Джерело відповідей | Знання, закодовані у вагах моделі | Ваші документи, індексовані в реальному часі |
| Актуальність | Вимагає повторного навчання після змін | Достатньо повторної індексації бази |
| Ризик галюцинацій | Високий (модель інтерполює те, чого не знає) | Низький при правильній конфігурації guardrails |
| Цитування джерел | Відсутнє | Фрагмент документа + посилання / номер сторінки |
| Вартість оновлення знань | Висока (fine-tuning після кожної зміни) | Низька (реіндексація нових файлів) |
| Контроль рамок | Ускладнений | Вбудований за конструкцією |
Практичне правило: якщо ваші знання змінюються частіше, ніж раз на квартал (а в більшості компаній — щотижня), RAG — це правильна архітектура. Fine-tuning залиште для моделей, що спеціалізуються на стилі та форматі, а не на актуальних фактах.
Як працює RAG крок за кроком
#Щоб правильно спроектувати систему, варто розуміти кожен етап у конвеєрі обробки:
Індексація (разово, потім інкрементально): Кожен документ ділиться на фрагменти (чанки). Кожен фрагмент проходить через модель ембедінгів — у нас BGE-M3, що працює локально — і перетворюється на числовий вектор. Вектори потрапляють до векторної бази. Жоден текст не залишає вашої інфраструктури на цьому етапі.
Запит (у реальному часі): Користувач пише запитання. Запитання векторизується тією ж моделлю. Семантичний пошук витягує 3–8 фрагментів документів з найбільшою схожістю до запитання. Опціонально застосовуємо reranking, який повторно сортує фрагменти за релевантністю перед передачею їх моделі.
Генерація відповіді: Мовна модель (через router LLM) отримує запитання та витягнуті фрагменти в контексті. Відповідь формулюється виключно на їх основі. Якщо фрагменти не містять відповіді, модель прямо каже: «у базі немає цієї інформації» та пропонує звернутися до людини.
Останній пункт — це різниця між асистентом, якому можна довіряти, і таким, що ввічливо вигадує. Guardrails змушують визнавати відсутність знань замість інтерполяції відповідей.
Які знання можна індексувати
Майже будь-який структурований формат працює добре. Ось що ми підтримуємо у типових впровадженнях:
- Документи Word / PDF — процедури, регламенти, специфікації продуктів, комерційні пропозиції
- FAQ та help center — контент, експортований з Zendesk, Intercom, Notion, Confluence
- База даних продуктів — опис, параметри, діапазони цін, умови постачання (JSON / CSV)
- Електронні листи та треди — історія обслуговування клієнтів як база кейсів (з анонімізацією PII)
- Транскрипції розмов — особливо цінні при післяпродажному обслуговуванні
Чого уникаємо на старті: документів з великою кількістю таблиць у вигляді зображень (скановані PDF без текстового шару), баз зі суперечливими версіями однієї й тієї ж інформації без позначки «чинне від / скасовано», та репозиторіїв повністю — індексуємо документацію, а не код.
Хороше правило: перш ніж індексувати тисячу файлів, індексуйте сто найважливіших і виміряйте точність відповідей. Якість бази знань визначає верхню межу якості асистента, а не навпаки.
Шар безпеки: це не опція
Корпоративний асистент працює з даними, які мають цінність і витік яких коштує дорого. Тому безпеку проектуємо з першого рядка, а не додаємо постфактум.
PII маскується перед хмарою. Якщо документи містять персональні дані, ми маскуємо їх перед відправкою до моделі в хмарі. Альтернативно — весь стек (embedding + модель) працює локально на вашій інфраструктурі (self-hosting).
Guardrails контролюють рамки. Система відповідає лише на запитання, які мають покриття в базі. Запитання на теми поза рамками (наприклад, прохання написати код або політична думка) відхиляються з повідомленням та опцією переключення на людину.
Injection та prompt attack. Guardrails фільтрують вхід користувача перед передачею до моделі — блокують спроби витягнути секрети з контексту, ін'єкції інструкцій та атак на prompt.
Human-handoff для питань поза компетенцією. Асистент, який не знає, не вгадує — передає розмову людині з повним контекстом треду. Без цього кожна помилка моделі стає проблемою клієнта. Детальніше про цей патерн у статті про безпеку агентів AI.
Логи та підзвітність. Кожне запитання та кожна відповідь логуються без PII — не для стеження за користувачами, а для аудиту, вимірювання якості та відповідності RODO. Цей слід — вимога AI Act, а не опція.
Де корпоративний асистент дає найбільший ефект
Три типи впроваджень, які ми зустрічаємо найчастіше і які найшвидше окупаються:
Обслуговування клієнтів та helpdesk. Асистент обробляє 40–70% повторюваних запитань без участі людини. Консультант бачить переадресовані розмови з повним контекстом — не починає з «про що йдеться?». Вимірюваний результат: час до першої відповіді, відсоток звернень, закритих без ескалації.
Внутрішня база знань для співробітників. Онбординг нового співробітника скорочується на кілька–десятки годин, оскільки запитання до досвідчених колег замінює асистент на основі документів відділу. Вимірюваний результат: кількість запитів до внутрішньої команди, час онбордингу.
Продажний асистент перед пропозицією. Менеджер або клієнт на сайті може запитати про наявність, параметри та умови без очікування на відповідь електронною поштою. Вимірюваний результат: час від запиту до пропозиції, коефіцієнт конверсії.
У кожному з цих випадків стартова точка однакова: вузька, добре описана предметна область, виміряний бейзлайн (скільки часу це займає сьогодні?), пілот на реальному трафіку. Перевірте оцінку готовності вашої компанії перед плануванням обсягу.
Час та вартість: чого очікувати
Корпоративний асистент — це інженерний проект, а не одноразова конфігурація платформи. Чесна картина впровадження:
Пілот (одна предметна область): зазвичай кілька тижнів від підготовки документів до працюючої системи з виміряними результатами. Конкретні терміни залежать від обсягу — розрахуйте це у калькуляторі ROI.
Що займає час? Не модель, не інфраструктура. Підготовка та впорядкування бази знань (суперечливі версії, дублікати, відсутні метадані) — це зазвичай 30–50% загальних зусиль пілоту. Тому починаємо з аудиту документів, а не з налаштування моделі.
Вартість підтримки. Індексація нових документів — низьковитратна операція. Змінна вартість — кількість запитів до моделі в хмарі, яку можна попередньо оцінити у калькуляторі inference. При великому трафіку або чутливих даних часто оптимальнішим є локальна модель.
Де НЕ обіцяємо: не наводимо фіксованих цін або термінів до аудиту обсягу. Масштаб впровадження (одна область vs. все підприємство) змінює цифри на порядок. Точка входу — завжди пілот з фіксованою вартістю — напишіть нам з описом процесу.
Спробуйте наживо
Опишіть вашу базу знань та основний сценарій використання, і модель покаже, як спроектувати конвеєр індексації та обсяг guardrails — як відправну точку, а не готовий проект (playground: PII маскується, нульове збереження):
FAQ
#Чим відрізняється корпоративний GPT від ChatGPT?
#ChatGPT відповідає з загальних знань, закодованих у моделі — він нічого не знає про ваші документи чи процедури. Корпоративний RAG-асистент відповідає виключно з вашої бази знань: кожна відповідь має джерело у конкретному фрагменті документа. Поза межами бази прямо каже «у мене немає цієї інформації», а не інтерполює.
Чи потрапляють наші дані до хмари?
Залежить від обраної архітектури. При локальній моделі (self-hosting) весь стек працює на вашій інфраструктурі, і жоден текст не залишає корпоративної мережі. При моделі в хмарі ми маскуємо PII перед відправкою запиту. Вибір залежить від чутливості даних та вимог RODO — обговорюємо це на етапі пілоту.
Наскільки великою має бути база знань?
Мінімального порогу немає. Пілоти починаємо з кількох десятків добре підготовлених документів. Важливіша за кількість — якість та узгодженість: одна добре описана предметна область без суперечливих версій дає кращі результати, ніж тисяча невпорядкованих файлів. Якість бази визначає верхню межу якості асистента.
Чи може асистент помилятися?
Так. Кожна RAG-система має похибку, особливо на граничних запитаннях та документах з неоднозначним змістом. Тому guardrails змушують відповідати «не знаю» замість вгадування, логуємо кожну відповідь для аудиту якості, а впровадження на критичних шляхах завжди включає human-handoff. Асистент має розвантажувати людину, а не замінювати її там, де помилка коштує дорого.
Скільки часу займає впровадження?
Пілот однієї предметної області — зазвичай кілька тижнів від надання документів до працюючої системи з першими вимірами. Найбільша змінна — підготовка бази знань з вашого боку. Повний масштаб та графік вимагають аудиту обсягу — зв'яжіться з нами, щоб почати з конкретної цифри.