Пошук прогалин у базі знань

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

Команда підтримки отримує пріоритизований беклог статей і готові чернетки замість абстрактного відчуття «нам потрібно оновити KB».

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

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

Що робить автоматизація покроково

1. Збирає тикети, чати та дзвінки зі служби підтримки за заданий період — день, тиждень або квартал.
2. Фільтрує службові звернення (білінг, доступ, баги), залишаючи теми, пов'язані з контентом, для аналізу.
3. Нормалізує дані: очищає персональні дані, приводить до єдиного формату.
4. Групує звернення за темами за допомогою кластеризації — схожі запитання потрапляють в одну групу.
5. Для кожної теми виділяє ключовий сенс: що саме клієнт хотів дізнатися або вирішити.
6. Шукає відповідну статтю в CMS бази знань за заголовком, змістом, тегами та метаданими.
7. Оцінює покриття теми: чи є стаття, чи достатньо вона повна, чи не застаріла.
8. Формує список прогалин, впорядкованих за частотою звернень і бізнес-пріоритетом.
9. Генерує чернетку статті на основі реальних діалогів із клієнтами та відповідей агентів підтримки.
10. Надсилає чернетку відповідальному редактору через менеджера бази знань або тикет на ревью.

Чого автоматизація не робить

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

Автоматизація побудована як custom-code з використанням LLM та інтеграцією у службу підтримки і CMS бази знань. Запускається за розкладом — раз на добу або тиждень залежно від обсягу тикетів. Архітектура розбита на три шари: збір даних, аналіз і генерація артефактів.

Технічний потік

1. Вилучення даних. Worker забирає закриті тикети зі служби підтримки через API за обраний період. Поля: тема, опис, переписка, категорія, CSAT, дата закриття.
2. Очищення та анонімізація. Скрипт видаляє PII (імена, адреси, номери), нормалізує текст, розбиває на чанки для обробки.
3. Кластеризація звернень. Ембеддинги через text-embedding модель, групування за косинусною близькістю. Підсумок — теми з кількістю звернень і середнім CSAT.
4. Пошук у базі знань. Для кожної теми запит до CMS через API або RAG поверх експорту статей. Повертає топ-3 кандидати за релевантністю.
5. Оцінка покриття. LLM аналізує тему і знайдені статті, видає рішення: покрито, покрито частково, прогалина, застаріло.
6. Пріоритизація. Ранжування за формулою: частота звернень × негативний CSAT × відсутність покриття.
7. Генерація чернеток. LLM створює структуру статті на основі реальних переписок і прикладів відповідей агентів.
8. Доставка. Чернетка потрапляє до CMS як чернетка або до тикет-трекера як завдання для менеджера бази знань.

Реалізація покроково

1. Розгортаємо воркер у хмарі (AWS Lambda, Cloud Run або власноруч розгорнутий контейнер).
2. Налаштовуємо API-доступ до служби підтримки і CMS, готуємо сервісного користувача з потрібними правами.
3. Збираємо історичну вибірку тикетів за 3-6 місяців для калібрування кластеризації.
4. Індексуємо поточну базу знань — експорт статей і побудова векторного індексу.
5. Налаштовуємо промпти для LLM: оцінка покриття, генерація чернеток, форматування.
6. Тестуємо на історичних даних, звіряємо результат із ручним аудитом команди.
7. Запускаємо пілот на одному продукті або категорії звернень.
8. Розширюємо на всю базу після валідації якості чернеток.

Компоненти рішення

Для першої версії достатньо мінімального стека: планувальник, скрипт збору тикетів, LLM-виклик для кластеризації та оцінки, простий дашборд або email-розсилка чернеток. Складні оптимізації — петля зворотного зв'язку від редактора, навчання на прийнятих чернетках — додаються після пілота.

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

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

Дані та доступи

• API-доступ до служби підтримки з правом читання тікетів за останні 3-6 місяців.
• API-доступ або експорт бази знань з CMS: заголовки, контент, теги, дати оновлення.
• Сервісний акаунт з правом створення чернеток у CMS або заведення задач у тікет-трекері.
• Місце для розгортання воркера: хмара або внутрішня інфраструктура.
• Ключі LLM-провайдера.

Готовність команди

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

Терміни

Пілот з одним продуктом або категорією — 2-4 тижні. Включає підключення API, індексацію бази знань, налаштування промптів і валідацію на історичних даних. Розширення на всю базу знань — додаткові 1-2 тижні після пілота. Терміни зростають, якщо категоризація тікетів у службі підтримки потребує попереднього очищення.