Deskhero
Українська
Спробувати безкоштовно

← Back to articles

Як підтримувати базу знань чатбота: практичний посібник

Як підтримувати базу знань чатбота: практичний посібник

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

Ось короткий контрольний список, який потрібен вашій команді насамперед:

  • Гігієна джерел: Видаляйте застарілі, дубльовані або суперечливі документи, перш ніж вони потраплять до індексу.
  • Сегментація та індексація: Почніть із фрагментів завдовжки від 500 до 1 000 символів, а потім коригуйте розмір на основі тестів пошуку.
  • Налаштування пошукового механізму: Щоквартально тестуйте й коригуйте пороги схожості, щоб підтримувати високу точність у міру зростання бази знань.
  • Процес затвердження: Кожна нова або відредагована стаття має бути затверджена до того, як стане доступною в чат-боті.
  • Показники моніторингу: Регулярно відстежуйте якість відповідей, невирішені запитання та передачі звернень операторам.
  • Відкат і версійність: Ведіть журнал змін, щоб будь-яке невдале оновлення можна було скасувати протягом кількох хвилин.

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

Основні висновки

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

Пункт Деталі
Використовуйте цикл від аудиту до вилучення Виконуйте цикл аудит → оновлення → перевірка → публікація → вилучення щотижня, щомісяця або щокварталу, щоб запобігати деградації бази знань.
Тестуйте розмір фрагментів Почніть із фрагментів для пошуку завдовжки від 500 до 1 000 символів і коригуйте їх на основі результатів тестування.
Відстежуйте корисні сигнали якості Моніторте точність відповідей, невирішені запитання, передачі звернень операторам і підтверджені неправильні відповіді, а потім визначте пороги, що відповідають вашому сервісу.
Призначте куратора бази знань Покладіть на одну особу чітку відповідальність за редакційний календар, чергу перевірки та графік обслуговування.
Deskhero забезпечує відповіді на основі схвалених знань Чат-бот Deskhero відповідає лише на основі схваленого загальнодоступного вмісту FAQ і пропонує кандидатів для FAQ із вирішених тикетів та просканованих сторінок вебсайту.

Зміст

Що таке база знань чат-бота і як вона забезпечує відповіді?

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

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

Основні компоненти якісно побудованого конвеєра бази знань:

  • Вихідні документи: статті бази знань, вирішені тикети, PDF-файли, сторінки вебсайту, документи з політиками.
  • Метадані: теги для теми, напрямку продукту, аудиторії, дати останнього оновлення та автора.
  • Ембеддинги: щільні векторні представлення кожного фрагмента, створені моделлю ембеддингів.
  • Векторна база даних: зберігає та індексує ембеддинги для швидкого семантичного пошуку (Pinecone, Weaviate, pgvector та подібні інструменти).
  • Пошуковий механізм: надсилає запит до векторної БД і повертає N найбільш релевантних фрагментів.
  • LLM і системні підказки: об’єднують знайдені фрагменти у відповідь природною мовою відповідно до ваших інструкцій.
  • Рівень цитування: додає до кожної відповіді посилання на джерела, щоб Users і клієнти могли її перевірити.

Порада від професіонала: Зосереджуйте кожну статтю на одній чіткій темі. Розділяйте документи, які відповідають на кілька не пов’язаних між собою запитань. Розмір фрагмента також важливий: почніть із 500–1 000 символів і коригуйте його на основі результатів тестів. Надто малі фрагменти можуть втрачати контекст, а надто великі — приховувати релевантне речення.

Чому безперервне обслуговування важливе для точності чат-бота

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

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

Ризики нехтування не менш очевидні:

  • Застарілі відповіді: Чат-бот, який посилається на знятий із виробництва продукт або стару політику повернення, одразу втрачає довіру.
  • Суперечливий контент: Дві статті з різними відповідями на те саме запитання заплутують пошуковий механізм і призводять до непослідовних відповідей.
  • Ризик галюцинацій: Якщо пошуковий механізм не знаходить нічого релевантного, неправильно налаштована система вигадує відповідь. Добре підтримувана база знань зменшує цю прогалину.
  • Ризики невідповідності вимогам: У регульованих галузях застаріла відповідь щодо політики може спричинити серйозні проблеми під час перевірки та відповідності вимогам.
  • Втрата довіри: Клієнти, які двічі отримали неправильну відповідь, рідко дають боту третій шанс.

Покроковий операційний план підтримки знань чат-бота

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

  1. Заплануйте аудит. Отримайте журнали розмов за попередній період. Позначте запити з низькими показниками впевненості, ескалаціями та резервними відповідями «Я не знаю». Це ваші прогалини найвищого пріоритету.

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

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

  4. Сегментуйте та створіть ембеддинги. Спочатку розбийте оновлені статті на фрагменти завдовжки від 500 до 1 000 символів. Додайте теги метаданих (тема, продукт, мова, аудиторія). Пропустіть фрагменти через модель ембеддингів і завантажте їх у векторну базу даних у тестове середовище, а не в продакшен.

  5. Запустіть поетапні перевірки. Використайте тестовий набір із 20–30 реальних запитів, отриманих із журналів. Перевірте, чи кожен запит знаходить правильний фрагмент і чи згенерована відповідь відповідає канонічній. Встановіть поріг проходження для точності пошуку перед перенесенням у продакшен.

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

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

  8. Вилучайте застарілий контент. Архівуйте його, а не видаляйте, щоб зберегти історію версій. Оновіть усі статті, у яких було посилання на вилучений контент.

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

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

Стандарти, шаблони та управління, що забезпечують надійність відповідей

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

Редакційні стандарти, яким має відповідати кожна стаття

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

Ролі в управлінні

  • Власник контенту: експерт у відповідній предметній галузі, який створює та оновлює статті у своїй сфері.
  • Куратор бази знань: забезпечує дотримання стандартів, проводить аудити, керує життєвим циклом статей і відповідає за редакційний календар.
  • Затверджувач: керівник команди або менеджер, який погоджує статтю до її публікації.
  • Відповідальний за ML: опрацьовує параметри сегментації, оновлення моделі ембеддингів, конфігурацію пошуку та обслуговування тестових наборів.
  • Рецензент із питань відповідності: обов’язкове погодження для статей, що стосуються регульованих тем (ціни, юридичні умови, конфіденційність даних).

Сигнали довіри, які варто впровадити зараз

  • Журнали аудиту, що фіксують кожну дію зі створення, редагування, затвердження та вилучення із зазначенням часу й ідентифікатора користувача.
  • Історія версій із переглядом відмінностей, щоб кожну зміну можна було перевірити.
  • Журнали змін, прикріплені до кожної статті, із зазначенням того, що і чому змінилося.
  • Позначки затвердження, видимі в адміністративній частині бази знань, щоб команда бачила, що дозволено, а що не дозволено використовувати в чат-боті.
  • Цитування джерел у кожній відповіді чат-бота.

Що вимірювати та як діяти на основі сигналів

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

Основні показники для відстеження:

  • Точність / правильність відповідей: відсоток відповідей чат-бота, які відповідають канонічній відповіді у вибірковому тестовому наборі.
  • Рівень обґрунтованості: відсоток відповідей із посиланням на конкретний вихідний фрагмент. Падіння цього показника свідчить про деградацію пошуку або відсутній контент.
  • Рівень самостійного вирішення: відсоток розмов, вирішених без участі User. Зростання ескалацій часто пов’язане з конкретною прогалиною в базі знань.
  • Рівень ескалацій: обернений показник до рівня самостійного вирішення; відстежуйте його за тематичними категоріями, щоб визначити, які області контенту потребують уваги.
  • Час до оновлення: скільки часу минає від виявлення прогалини до публікації перевірленого виправлення.
  • CSAT для бота: показник задоволеності клієнтів саме для розмов, опрацьованих чат-ботом.
  • Інциденти галюцинацій: кількість підтверджених випадків, коли бот надав фактично неправильну відповідь, не обґрунтовану жодним джерелом.

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

Підходи до інструментів і контрольний список інтеграції

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

  • Інкрементальна індексація: система може оновлювати окремі фрагменти без повторної індексації всієї бази знань. Це критично важливо для великих баз, де повна повторна індексація є повільною та дорогою.
  • Оновлення ембеддингів: можливість повторно генерувати ембеддинги для оновлених статей, не змінюючи незмінений контент.
  • Підтримка походження та цитування: кожен знайдений фрагмент містить посилання на джерело, яке відображається у відповіді.
  • Рольовий контроль доступу: власники контенту, затверджувачі та ML-інженери мають різні дозволи. Платформа повинна це забезпечувати.
  • Журнали аудиту: кожна подія індексації, зміна контенту та затвердження фіксуються із зазначенням часу й користувача.
  • Вебхуки для роботи з тикетами: коли тикет вирішено, вебхук може запустити перевірку бази знань або автоматично створити чернетку статті-кандидата. Це замикає цикл між операціями підтримки та обслуговуванням знань.
  • SSO: SSO Google і Microsoft зменшує труднощі для команд, які вже працюють у цих екосистемах.

Підходи до інтеграції, які працюють у продакшені

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

Поетапна індексація в ізольованому середовищі: новий або оновлений контент спочатку індексується в тестовому середовищі. Тестовий набір запускається в тестовому середовищі до того, як будь-яка зміна потрапить у продакшен. Це еквівалент конвеєра CI для контенту бази знань.

Конвеєри перевірки на кшталт CI: ставтеся до змін бази знань як до змін коду. Оновлення контенту запускає автоматичний тестовий прогін на наборі з 20–30 запитів. Помилки блокують публікацію. Успішні результати передаються затверджувачу для фінального погодження.

Ключові компроміси, які потрібно розуміти

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

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

Як Deskhero відповідає цьому плану обслуговування

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

Ось як конкретні етапи плану пов’язані з функціями Deskhero:

  • Відповіді лише на основі схвалених знань: чат-бот зі ШІ Deskhero відповідає на основі схваленого загальнодоступного вмісту FAQ. Інші знання робочого простору не використовуються у відповідях чат-бота для клієнтів. Для ввімкнення чат-бота потрібно щонайменше 100 схвалених загальнодоступних елементів FAQ.
  • Пропозиції FAQ із вирішених тикетів: вирішені тикети та проскановані сторінки вебсайту можна перетворити на кандидатів для FAQ. User перевіряє та схвалює запис, перш ніж він стане доступним чат-боту.
  • Окремі області знань: внутрішня база знань може використовуватися для формування пропозицій відповідей зі ШІ для Users. У відповідях чат-бота для клієнтів використовується лише схвалений загальнодоступний FAQ.
  • Двостороння синхронізація електронної пошти: запитання клієнтів надходять електронною поштою, через форму або чат-бота й стають тикетами у спільній скриньці. Відповіді можна надсилати з підключеної адреси компанії.
  • Позначені автоматичні дії: автоматичні дії позначаються та реєструються, а повністю автоматичне надсилання вмикається за бажанням.
  • REST API: Deskhero надає REST API для роботи з тикетами та робочим простором. Вихідні вебхуки не підтримуються.
  • Багатомовний інтерфейс: інтерфейс Deskhero доступний 14 підтримуваними мовами, а пошук чат-бота може зіставляти загальнодоступний контент FAQ різними мовами.

Deskhero підключає поштові скриньки Gmail, Google Workspace або Microsoft 365 до спільної служби підтримки, даючи команді змогу зберегти наявні адреси електронної пошти. ШІ для клієнтів відповідає на основі схваленого загальнодоступного контенту FAQ і передає невирішені запитання людині. Пропозиції FAQ можна створювати на основі вирішених тикетів і просканованих сторінок вебсайту, але User має перевірити їх перед схваленням. Автоматичні дії позначаються та реєструються. Платформа також містить внутрішню базу знань, аналітику тикетів, 14 мов інтерфейсу, інтеграцію із Shopify, SSO Google і Microsoft та REST API. Вона починається з 30-денної безкоштовної пробної версії, для якої не потрібна кредитна картка.

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

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

Графік обслуговування, персонал і міркування щодо вартості

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

Рекомендовані періоди:

  • Щотижня: переглядайте журнали розмов, формуйте список із 20 найчастіших запитань без відповіді, позначайте термінові прогалини в контенті та проводьте пріоритетні виправлення через етап затвердження.
  • Щомісяця: запускайте повний цикл оновлення контенту. Створюйте нові статті, оновлюйте змінені політики або продукти, вилучайте застарілий контент і запускайте повний тестовий набір.
  • Щокварталу: проводьте перевірку змін у політиках і продуктах, налаштування пошуку, оцінювання моделі ембеддингів і аудит управління (чи всі статті належно схвалені та мають версії?).

Мінімальна модель персоналу для невеликих команд:

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

Фактори витрат для оцінювання:

  • Витрати на зберігання у векторній базі даних і запити масштабуються відповідно до розміру бази знань та кількості запитів.
  • Частота оновлення ембеддингів впливає на обчислювальні витрати, тому за можливості інкрементальних оновлень оновлюйте лише змінений контент.
  • Час на перевірку людьми може становити значну частину витрат, особливо коли продукти або політики часто змінюються.
  • Вартість підписок на інструменти залежить від платформи. Платформи, які об’єднують керування базою знань, роботу з тикетами та чат-бота в одній підписці (замість окремих векторної БД, API LLM і інструментів служби підтримки), зменшують як витрати, так і складність інтеграції.

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

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

Оглядова схема графіка обслуговування, персоналу та міркувань щодо вартості

Як перевіряти нові джерела знань перед інтеграцією

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

Перед індексацією пропускайте кожне потенційне джерело через такі перевірки:

Перевірка точності: Чи відображає контент поточну поведінку продукту, політику або ціни? Зіставте його із системою обліку (вашою CRM, документацією продукту або схваленими юридичною командою документами політик). Якщо ви не можете перевірити твердження за первинним джерелом, не індексуйте його.

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

Перевірка дублювання: Чи значною мірою перетинається цей контент із наявною статтею бази знань? Дубльований контент створює неоднозначність під час пошуку. Перед індексацією об’єднайте або консолідуйте його.

Перевірка формату та структури: Чи структурований документ так, щоб сегментація створювала узгоджені, самодостатні уривки? Документ із великою кількістю перехресних посилань («див. розділ 4.2 для отримання деталей») погано сегментується, оскільки окремі фрагменти втрачають контекст. Перепишіть або реструктуруйте його перед індексацією.

Перевірка походження: Чи можете ви простежити контент до авторитетного внутрішнього або зовнішнього джерела? Для регульованих тем чітко вкажіть джерело в метаданих статті.

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

Як використовувати відгуки користувачів для вдосконалення знань чат-бота

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

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

Люди переглядають відгуки користувачів про чат-бота на планшеті

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

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

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

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

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

Що насправді дізнаються команди підтримки під час роботи в продакшені

Наведений вище план правильний у теорії. Ось що ламається на практиці та як це швидко виправити.

Починайте з малого й доведіть цінність до масштабування. Індексація всіх доступних документів одночасно може створити роздуту базу знань і ускладнити встановлення корисного базового рівня якості. Оберіть 20–30 категорій запитань із великим обсягом звернень, створіть для них якісні статті та запустіть чат-бота в цій вузькій області. Розширюйте охоплення після того, як тести покажуть, що відповіді точні та корисні.

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

Регулярно реєструйте та відстежуйте невідомі відповіді. Частий перегляд журналу «Я не знаю» допомагає командам виявляти повторювані прогалини до того, як вони накопичаться. Для визначення пріоритетів виправлень використовуйте кількість запитів і вплив на клієнтів.

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

Швидкі виправлення для команд, які лише починають:

  • Встановіть правило найменування статей у перший день (Область продукту: Тема: Аудиторія). Перейменовувати 200 статей постфактум болісно.
  • Створіть шаблон метаданих з обов’язковими полями та вставляйте його в кожну нову статтю до початку написання.
  • Створіть тестовий набір із 20–30 реальних запитів із перших журналів розмов і запускайте його перед кожним перенесенням у продакшен.

Deskhero робить план обслуговування операційним із першого дня

Виконання цього плану в розрізнених інструментах може створити додаткову координаційну роботу. Deskhero об’єднує процес перевірки загальнодоступного FAQ, пропозиції FAQ і розмови з клієнтами в одній службі підтримки.

Deskhero

Чат-бот відповідає лише на основі схваленого загальнодоступного контенту FAQ, тоді як пропозиції відповідей зі ШІ для Users можуть використовувати ширші знання робочого простору. Пропозиції FAQ із вирішених тикетів і просканованих сторінок вебсайту зменшують обсяг роботи зі створення контенту з нуля, але все одно потребують перевірки людиною. Двостороння інтеграція поштових скриньок зберігає зв’язок між тикетами, відповідями та наявною адресою команди.

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

Джерела

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

FAQ

Що таке база знань чат-бота?

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

Як підтримувати чат-бота в актуальному стані протягом тривалого часу?

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

Що ніколи не можна повідомляти чат-боту?

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

Скільки коштує підтримка чат-бота?

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