AI-агенту підтримки не потрібна найбільша можлива база знань. Йому потрібна надійна: правильні теми, одна авторитетна відповідь на кожну політику, достатній контекст для її коректного застосування й спосіб помітити зміну контенту. Завантаження всіх документів компанії дає більше тексту для пошуку, але також створює суперечності, застарілі інструкції та приватну інформацію, якої ніколи не мало бути у відповіді клієнтові.
Нанесіть попит на карту й оберіть одне авторитетне джерело
Почніть із попиту. Вивантажте недавні розмови підтримки, згрупуйте їх за наміром клієнта й ранжуйте групи за частотою, наслідком помилки та наявністю стабільної відповіді. Першу карту покриття будуйте з масових низькоризикових запитань, як-от кроки налаштування та можливості тарифу. Питання, що потребують винятку, розслідування акаунту, юридичного судження або інформації без затвердженого джерела, мають залишатися явною територією передачі людині.
Створіть інвентар джерел до переписування. Для кожної статті запишіть призначення, аудиторію, мову, частину продукту, власника, дату останньої перевірки та звʼязок заміни зі старішими документами. Позначте дублікати й розбіжності. Якщо дві сторінки по-різному описують правило повернення коштів, AI не знає, яка внутрішня історія зробила одну правильною; людський власник має обрати авторитетну й архівувати іншу.
Будуйте одну статтю навколо одного завдання чи рішення клієнта. Дайте пряму відповідь першою, далі — умови, нумеровані кроки, приклади, винятки та наступну дію. Використовуйте ті самі терміни, що й інтерфейс продукту, а абревіатури пояснюйте при першій появі. Описовий заголовок «Змінити billing email робочого простору» легше знайти, ніж «Налаштування акаунту», бо він містить намір, який імовірно висловить клієнт.
Пишіть уривки, зрозумілі навіть після окремого пошуку
Зробіть кожен розділ зрозумілим, коли його дістають окремо. AI-пошук часто працює з уривками, а не передає моделі весь посібник, тому заголовок «Ліміти» поза початковою сторінкою втрачає зміст. Краще «Ліміти завантаження файлів у тарифі Growth», повторюйте критичний контекст там, де неоднозначність небезпечна, і тримайте таблиці достатньо простими, щоб рядок мав сенс разом зі своїми заголовками.
Додайте клієнтську лексику без набору ключових слів. Включіть поширені альтернативні терміни, старі назви функцій, скорочення та природні запитання, але фактичну відповідь тримайте в одному місці. Ставте посилання на суміжні завдання замість копіювання абзаців між статтями. Дубльований текст із часом розходиться, а AI може знайти застарілу копію лише тому, що її формулювання ближче до запитання.
Застосовуйте метадані, контроль доступу й мінімізацію даних як межі
Використовуйте метадані для реальних меж. Мова, регіон, тариф, версія продукту, аудиторія, дата початку дії та статус контенту можуть не дати релевантному уривку потрапити не до того клієнта. Метадані мають відбивати відмінності, які бізнес справді підтримує; десятки невикористаних тегів роблять фільтрацію складною на вигляд, поки автори забувають заповнювати важливі поля.
Не допускайте персональні й секретні дані до набору джерел. Приберіть експорти клієнтів, приватні внутрішні нотатки, облікові дані, непублічні деталі безпеки та документи, додані лише тому, що лежали поруч. Дайте системі пошуку доступ лише до затверджених колекцій і перевірте, хто може додавати чи публікувати контент. База знань сама по собі не є межею безпеки, а retrieval не усуває ризики prompt injection чи розкриття інформації.
Тестуйте реальними запитаннями й зробіть відповідальність постійною
Тестуйте запитаннями, а не превʼю сторінок. Побудуйте регресійний набір із реальних формулювань, помилок у написанні, уточнень, неоднозначних запитів, непідтримуваних тем, хибних передумов і ворожих інструкцій. Для кожного визначте очікуване джерело, відповідь або передачу. Запускайте набір після зміни контенту так само, як після зміни моделі чи пошуку, бо невинна стаття може змінити уривок-переможець для багатьох наявних запитань.
Нарешті, призначте кожній опорній статті власника й тригер перегляду. Перевіряйте часто використовуваний контент за графіком, але також запускайте перегляд після зміни цін, політик, інтерфейсу чи повторного збою підтримки. Повертайте запитання без відповіді й відредаговані чернетки AI до відсутнього або слабкого джерела. База знань, готова до AI, — не одноразовий видавничий проєкт, а операційна система, що стає надійнішою щоразу, коли черга показує прогалину.
Побудуйте першу колекцію з 20 найчастіших намірів
Візьміть 20 найчастіших намірів підтримки за минулий квартал. Для кожного визначте одну затверджену відповідь, одного власника контенту, аудиторію й тариф, дату останньої перевірки та випадки обовʼязкової передачі людині. Не підключайте намір, доки суперечності й відсутні умови не виправлені.
Створіть пʼять-десять тестових запитань на кожен намір із реальних формулювань клієнтів, включно з уточненням і хибною передумовою. Запишіть очікувану статтю та мінімальні факти правильної відповіді. Додайте явні випадки без відповіді, щоб систему оцінювали за безпечною відмовою так само, як за успішним пошуком.
Запустіть колекцію в режимі помічника й аналізуйте редагування за джерелом. Якщо оператори постійно змінюють відповіді з однієї статті, виправте її та повторно запустіть усі повʼязані запитання. Розширюйтеся за межі перших 20 намірів лише коли відповідальність, тестування й цикл оновлення надійно працюють на першому наборі.
Поширене запитання
Що робить базу знань готовою до AI?
База знань, готова до AI, має свідомі межі, одне актуальне авторитетне джерело для кожної відповіді, самодостатні розділи, корисні метадані аудиторії й версії, не містить зайвих персональних або секретних даних і має названих власників. До неї додається регресійний набір для перевірки пошуку, безпечної відмови та передачі людині, коли джерела відсутні, суперечать одне одному або виходять за дозволені межі.