Поиск пробелов в базе знаний

AI-агент регулярно сканирует поток клиентских обращений в helpdesk и сопоставляет их с текущим содержимым базы знаний. Результат — список тем, по которым клиенты задают вопросы, но документации нет или она устарела. Команда поддержки получает приоритизированный бэклог статей и готовые черновики вместо абстрактного ощущения «нам нужно обновить KB».

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

Ключевое отличие от ручного аудита — регулярность. Команда не ищет пробелы раз в квартал, когда кто-то вспомнил про KB. AI-агент работает постоянно и поднимает флаг, как только новая тема набирает критический объём обращений. Это убирает дрейф между реальностью клиентов и содержимым документации.

Что делает автоматизация по шагам

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

Чего автоматизация не делает

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

Автоматизация построена как custom-code с использованием LLM и интеграцией в helpdesk и CMS базы знаний. Запускается по расписанию — раз в сутки или неделю в зависимости от объёма тикетов. Архитектура разбита на три слоя: сбор данных, анализ и генерация артефактов.

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

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

Реализация по шагам

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

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

Для первой версии достаточно минимального стека: scheduler, скрипт сбора тикетов, LLM-вызов для кластеризации и оценки, простой дашборд или email-рассылка черновиков. Сложные оптимизации — feedback loop от редактора, continuous learning на принятых черновиках — добавляются после пилота.

Качество результата зависит от того, насколько чисто размечены категории тикетов в helpdesk. Если категоризация хаотичная, первый шаг — договориться о таксономии с командой поддержки до запуска пилота.

Для запуска автоматизации команде нужны доступы к системам и минимальная готовность базы знаний.

Данные и доступы

• API-доступ к helpdesk с правом чтения тикетов за последние 3-6 месяцев.
• API-доступ или экспорт базы знаний из CMS: заголовки, контент, теги, даты обновления.
• Сервисный аккаунт с правом создания черновиков в CMS или заведения задач в тикет-трекере.
• Место для развёртывания worker'а: облако или внутренняя инфраструктура.
• Ключи LLM-провайдера.

Готовность команды

• Назначенный knowledge-менеджер или редактор, который принимает черновики и ведёт их до публикации.
• Согласованная таксономия категорий обращений в helpdesk — без чистой структуры тегов результат будет шумным.
• Правило ревью: кто и в какой срок проверяет сгенерированный черновик перед публикацией.
• Продуктовая экспертиза доступна для уточнения технических деталей в статьях.

Сроки

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