Внутрішні знання розпорошені між Drive, Notion, SharePoint, Slack, PDF-файлами, нотатками в CRM і досвідом працівників. Агент бази знань дає команді єдине місце, де можна поставити запитання й отримати відповідь із посиланням на джерело. У цьому посібнику розглянемо чотири ключові рішення, від яких залежить, чи довірятиме команда агенту й користуватиметься ним надалі. Ухваліть їх послідовно до початку розробки.
Крок 1 — Визначте аудиторію
Почніть з однієї команди. Команди підтримки, продажів, операцій, HR і фінансів ставлять принципово різні запитання, тому база знань для всіх одразу не відповідатиме потребам жодної з них. Не намагайтеся відразу створити універсальний «мозок компанії».
Перевірка готовності: ви можете назвати п'ять запитань, які ця команда ставить щотижня. Якщо замість конкретних запитань виходять лише загальні категорії, обсяг робіт ще не визначено.
Типова помилка: почати з найширшої аудиторії, бо це здається амбітнішим. Надто широкий обсяг робіт призводить до нечітких відповідей і не дає об'єктивно оцінити користь агента.
Аудиторію визначено правильно, коли: агент призначений для однієї команди, а ви можете передбачити більшість її запитань уже на старті.
Крок 2 — Оберіть затверджені джерела
Перелічіть затверджені джерела, на які агент може спиратися у відповідях:
- Політики та регламенти
- Стандартні операційні процедури (SOP)
- Продуктова документація
- Записи в CRM або ERP
- Сторінки внутрішньої вікі
- Затверджені таблиці
Додаючи джерело, ви дозволяєте агенту спиратися на нього у відповідях. Якщо інформація в документі помилкова, агент лише поширюватиме її швидше й частіше. Перевірте кожне джерело перед індексацією: чи актуальне воно, хто відповідає за його оновлення та чи не суперечить воно іншим документам зі списку.
Типова помилка: проіндексувати два документи, що по-різному описують той самий процес. Відповідь агента залежатиме від того, який документ він знайде. Посилання на джерело не розв'яже проблему — воно лише вкаже на одну із суперечливих версій.
Джерела підготовлено правильно, коли: за актуальність кожного з них відповідає конкретна людина, а документи не суперечать одне одному щодо того самого факту.
Крок 3 — Визначте вимоги до відповідей
Корисний агент бази знань має:
- Посилатися на джерела — кожна відповідь містить посилання на документ, щоб її можна було швидко перевірити
- Визнавати, коли відповіді немає — «У мене немає затвердженого джерела щодо цього» краще за впевнений здогад
- Дотримуватися прав доступу — якщо користувач не має доступу до документа, агент не повинен використовувати його у відповіді для цього користувача
- Передавати складні запитання фахівцеві — спрямовувати справді неясні або ризиковані запитання відповідальній людині
- Не використовувати незатверджені джерела — відповідати лише на основі погодженого списку або прямо повідомляти, що підтвердженої відповіді немає
Мета — довіра, а не показна впевненість. Одна впевнена, але хибна відповідь про повернення коштів чи регуляторну вимогу може підірвати довіру всієї команди. Агент, якому ніхто не довіряє, — лише дорога інфраструктура.
Відповіді налаштовано правильно, коли: агент дещо частіше, ніж вам хотілося б, визнає, що не знає відповіді. На початку роботи це безпечне налаштування.
Крок 4 — Почніть з обмеженого запуску
Почніть з невеликої групи в межах однієї обраної команди. Протягом перших тижнів щотижня переглядайте журнали роботи й відстежуйте три типи сигналів:
- Запитання, на які агент не відповів → яких документів бракує
- Непевні або неповні відповіді → які джерела потрібно уточнити
- Неочікувані запитання → яким є реальний обсяг потреб команди
Кожне запитання без відповіді точно показує, що потрібно додати або виправити далі.
Типова помилка: одразу відкривати доступ широкій аудиторії, щоб «зібрати більше даних». Масштабний запуск ускладнює аналіз, а обмежений допомагає швидше побачити кожну прогалину.
Обмежений запуск успішний, коли: команда звертається до агента замість того, щоб щоразу писати колегам, а щотижневий список прогалин скорочується.