Нейросеть за 20–30 минут превращает пачку закрытых тикетов в черновик статьи базы знаний: находит повторяющуюся проблему, вытаскивает рабочее решение из переписки оператора с клиентом и оформляет это в короткую пошаговую инструкцию — специалист поддержки задаёт тикеты по одной теме, а модель собирает из них связный текст статьи.
Что делает модель
Черновик статьи базы знаний из десяти-пятнадцати похожих тикетов модель собирает за 20–30 минут вместо часа-полутора ручного анализа переписки, по нашему опыту внедрений: формулировка проблемы, шаги решения и типичные уточняющие вопросы клиента.
База знаний почти всегда отстаёт от практики — новая проблема возникает, специалисты решают её в переписке с клиентами, а отдельная статья под неё подолгу остаётся ненаписанной. Модель хорошо решает именно этот разрыв: она читает подборку похожих тикетов и вытаскивает из них общий сценарий решения, который дальше можно оформить в статью.
- Формулировка проблемы клиента человеческим языком вместо тикет-жаргона
- Пошаговое решение, вытащенное из переписки оператора с клиентом
- Типичные уточняющие вопросы, которые операторы задают клиенту
- Черновик заголовка и структуры будущей статьи базы знаний
Задача здесь — построить статью с нуля из сырых тикетов вместо ответа по уже готовой базе: как модель потом отвечает клиентам и операторам по собранной базе знаний, разобрано в статье про ИИ-помощника по базе знаний техподдержки.
Более широкую картину того, что именно ИИ отдаёт первой линии поддержки, а что остаётся оператору, разбирает статья про ИИ для поддержки клиентов. Здесь — узкая задача пополнения базы знаний из уже закрытых обращений.
Модель для базы
Модель для сборки статьи подбирается по объёму и однородности тикетов. GigaChat и YandexGPT быстро справляются с короткой перепиской по простому вопросу. ChatGPT и Claude точнее держат структуру статьи, когда тикеты длинные и решение состоит из нескольких вариантов в зависимости от ситуации клиента.
- GigaChat — быстрая статья по короткой типовой переписке
- YandexGPT — короткая статья без вариативных сценариев
- ChatGPT (GPT-5) — точнее держит структуру при нескольких вариантах решения
- Claude — лучше формулирует проблему человеческим языком без жаргона
- DeepSeek — дешёвый вариант для первого черновика статьи
Для тикетов с техническими деталями — версия приложения, код ошибки, модель устройства — полезно явно попросить модель сохранить эти детали дословно, а перефразировать только объяснение для клиента, иначе точная техническая формулировка размывается в общем пересказе.
Отраслевая специфика тоже играет роль — для финансового продукта важна точная формулировка условий, для технического сервиса — точные шаги настройки. Модель точнее собирает статью, если получает в промпте пример уже готовой статьи базы знаний в нужном формате.
Стоит также заранее решить, кто в команде отвечает за публикацию готовой статьи в общей базе, — модель отдаёт черновик, а формальное размещение и модерацию обычно берёт на себя один и тот же человек, чтобы структура базы знаний держалась в едином формате вместо расползания между разными стилями.
Ещё одна деталь — тикеты, где решение потребовало помощи разработчика или другого отдела. Такие случаи стоит помечать отдельно: типовая статья базы знаний рассчитана на самостоятельное решение оператором, а если типовой ответ на самом деле требует эскалации, это стоит указать прямо в тексте статьи, чтобы новый специалист сразу знал о необходимости эскалации вместо потери времени на попытку решить вопрос в одиночку.
Шаблон промпта
Хороший промпт для сборки статьи задаёт четыре параметра: сами тикеты по одной теме, желаемую структуру статьи, целевую аудиторию текста и уровень детализации технических параметров.
- Опишите роль: «Ты специалист поддержки, собираешь статью базы знаний из тикетов»
- Вставьте пять-десять похожих тикетов с полной перепиской
- Задайте структуру статьи — проблема, решение, частые уточнения
- Укажите, для кого статья — для клиента или для нового оператора
- Попросите отдельно вынести технические детали дословно
Сколько похожих тикетов закрывает ваша поддержка за месяц?
Формулировку проблемы стоит проверять на конкретность — «письмо подтверждения после оплаты картой пропадает» вместо общего «проблема с оплатой», иначе статья в базе знаний плохо находится поиском по нужному запросу клиента.
Отдельно полезно попросить модель предложить два-три альтернативных заголовка статьи под разные формулировки, которыми клиенты ищут эту же проблему в поиске по базе знаний — так статья находится по большему числу запросов.
Ещё полезно попросить модель отдельно указать, какому продукту или тарифу соответствует статья, если у компании их несколько, — иначе инструкция для одного тарифа рискует попасть в поиск по запросу пользователя другого тарифа с иным набором функций.
Что проверяет специалист
Модель хорошо вытаскивает сценарий решения из переписки, но точность технических деталей и актуальность самого решения на сегодняшний день — зона ответственности специалиста: решение из тикета трёхмесячной давности могло устареть после обновления продукта.
| Блок статьи | Что делает модель | Что проверяет специалист |
|---|---|---|
| Проблема | Формулирует человеческим языком по переписке | Точность формулировки под реальный запрос клиента |
| Решение | Собирает шаги из переписки оператора | Актуальность решения после последнего обновления продукта |
| Технические детали | Сохраняет коды ошибок и версии дословно | Точность деталей по актуальной документации |
Особенно внимательно стоит сверять решение, если тикеты собраны за длинный период, — за полгода продукт мог обновиться, и старое решение подходит лишь части похожих случаев сегодня.
Финальную статью полезно показать коллеге, который работал с похожими обращениями недавно, — он быстро заметит устаревшую деталь или шаг, который в текущей версии продукта работает иначе.
Ещё одна деталь — статьи, которые ссылаются на конкретный интерфейс или кнопку в продукте. После редизайна такие инструкции быстро теряют актуальность: скриншот и словесное описание шага перестают совпадать с текущим видом продукта, и это стоит проверять при каждом крупном обновлении интерфейса вместо ожидания жалоб клиентов на неработающую инструкцию.
Как внедрить
Первый шаг — выбрать тему, где за последний месяц набралось хотя бы десять закрытых тикетов с одинаковым решением: на таком объёме модель уверенно вытаскивает общий сценарий вместо единичного случая.
Соберите десять тикетов по одной повторяющейся проблеме, прогоните через модель и сравните черновик статьи с той, что специалист написал бы вручную с нуля.
Метрика для проверки результата простая — сколько повторных тикетов по той же проблеме закрывается ссылкой на новую статью вместо повторного объяснения с нуля в течение следующего месяца.
Стандартизация такого промпта на всю команду поддержки — тема отдельного обучения, формат разобран в статье про обучение сотрудников работе с ИИ.
Частая ошибка на старте — публиковать статью сразу после первого черновика без сверки с последней версией продукта: решение из тикетов месячной давности иногда устаревает быстрее, чем кажется.