AI-асистент для сайту: як працює RAG і з чого почати

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

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

Як працює RAG простими словами

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

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

З яких даних почати

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

• Публічні правила: можуть використовуватися у відповідях усім відвідувачам.

• Інформація клієнта: доступна лише після перевірки його особи та права на конкретний запис.

• Внутрішні матеріали: не повинні випадково потрапляти у відкритий чат.

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

У кейсі Service in UA показано підбір ремонту від пристрою до моделі та послуги. Така структурована предметна область добре пояснює, чому асистенту потрібні точні зв’язки даних. Це приклад організації сервісної інформації, а не повідомлення про наявність AI у цьому проєкті.

Пошук потрібного фрагмента важливіший за красиву відповідь

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

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

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

Де провести межу повноважень

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

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

Не варто давати асистенту універсальний доступ до CRM. Краще передбачити вузькі операції: отримати статус дозволеного замовлення, сформувати звернення, запропонувати доступний час. Сервер перевіряє користувача й дозволені параметри щоразу. Текст «це моє замовлення» не є доказом права доступу.

Як перевірити пілот до запуску

1. Зібрати репрезентативні запитання підтримки, прибравши приватні дані.

2. Записати очікувані факти, джерела й випадки, коли потрібен менеджер.

3. Перевірити пошук документів, правильність відповіді та відповідність цитат окремо.

4. Додати провокаційні запити, відсутні дані, іншу мову та суперечливі документи.

5. Порівняти результат із простим пошуком або звичайною формою допомоги.

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

Що входить у вартість експлуатації

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

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

Як сформулювати задачу для команди

Замість «додайте нам AI» корисно описати проблему: менеджери повторюють певні пояснення, відвідувачі губляться у довіднику, партнери довго шукають потрібний документ. Додайте приклади запитів, список джерел і межі відповідальності. На цій основі можна порівняти чат, поліпшення навігації та автоматизовану форму.

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

Поширені запитання

Чи гарантує RAG відсутність вигаданих відповідей?

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

Чи потрібно одразу навчати власну модель?

Не обов’язково. Спочатку варто перевірити доступ до знань і якість базового сценарію. Навчання моделі та підключення актуальних документів вирішують різні завдання.

Коли чат може бути зайвим?

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