Обновление базы знаний из закрытых обращений
Сценарий ищет пробелы между реальными обращениями и действующими статьями. Он не публикует переписку клиента и не считает ответ одного оператора официальным правилом: сначала собирается обезличенный кандидат с доказательством повторяемости.
Цель и граница автоматизации
Что меняем
Сценарий ищет пробелы между реальными обращениями и действующими статьями. Он не публикует переписку клиента и не считает ответ одного оператора официальным правилом: сначала собирается обезличенный кандидат с доказательством повторяемости. Практическая цель этой схемы - получить очередь новых и устаревших статей с примерами запросов в форме, которую ответственный может проверить по исходным данным. Скорость полезна только вместе с понятной границей ответственности и журналом изменений.
Где останавливается ИИ
Источником правила остается утвержденный процесс организации. Закрытое обращение показывает потребность, но не заменяет согласование содержания. ИИ завершает работу на стадии подготовки и разметки. Любое действие, которое меняет учетные данные, публикует текст, связывается с человеком или создает обязательство, выполняется только после явного подтверждения владельца процесса.
Страница построена вокруг контракта данных. Вход и результат описываются как отдельные наборы полей, между которыми можно провести проверку. Такой формат особенно полезен для документов, таблиц и каталога: свободный красивый текст не скрывает отсутствие обязательного значения.
Для каждого важного поля определите источник, допустимый формат, реакцию на пустое значение и человека, который подтверждает исправление. Если значение нельзя проследить до исходника, оно не должно автоматически попадать в рабочую систему.
Владелец, журнал и критерий готовности
До технической настройки назначьте одного владельца сценария «Обновление базы знаний из закрытых обращений». Он утверждает справочники, определяет допустимые исключения и решает, когда результат «Очередь новых и устаревших статей с примерами запросов» можно использовать дальше. Администратор конструктора отвечает за доставку и права, а владелец процесса - за смысл полей и решение человека. Эти роли могут выполнять разные сотрудники.
В журнале храните идентификатор входа, время каждого шага, версию промпта, использованную модель, статус проверки и причину остановки. Не записывайте полный чувствительный текст только ради отладки. Готовность пилота подтверждается не одним удачным примером, а серией обычных, пограничных и ошибочных случаев, для которых известен ожидаемый маршрут и возможен безопасный повтор. Отдельно зафиксируйте, кто получает уведомление, если проверка не завершена в установленный срок или очередь исключений растет.
Какие входные данные подготовить
Выбрать решенные обращения
Выгрузка исключает открытые, тестовые и чувствительные диалоги и сохраняет только нужный текст без контактов клиента. Для входа 1 сохраняйте источник, время получения и технический идентификатор. Пустое или противоречивое значение должно остановить обычную ветку, а не заменяться догадкой.
Найти существующую статью
Поиск определяет, был ли ответ в базе знаний и какую версию инструкции видел оператор. Для входа 2 сохраняйте источник, время получения и технический идентификатор. Пустое или противоречивое значение должно остановить обычную ветку, а не заменяться догадкой.
Собрать кандидатов
ИИ группирует независимые формулировки вопроса, отмечает пробел, противоречие или устаревший раздел и сохраняет примеры. Для входа 3 сохраняйте источник, время получения и технический идентификатор. Пустое или противоречивое значение должно остановить обычную ветку, а не заменяться догадкой.
Подготовить редакционный бриф
Кандидат содержит аудиторию, факты для подтверждения, запрещенные обещания, владельца и дату следующего пересмотра. Для входа 4 сохраняйте источник, время получения и технический идентификатор. Пустое или противоречивое значение должно остановить обычную ветку, а не заменяться догадкой.
Что должно появиться на выходе
Поле 1: Выбраны только решенные обращения
Результат должен позволять проверить условие «выбраны только решенные обращения» без повторного чтения всего массива. Рядом храните основание, статус ручной проверки и дату последнего изменения.
Поле 2: Персональные данные удалены
Результат должен позволять проверить условие «персональные данные удалены» без повторного чтения всего массива. Рядом храните основание, статус ручной проверки и дату последнего изменения.
Поле 3: Версия базы зафиксирована
Результат должен позволять проверить условие «версия базы зафиксирована» без повторного чтения всего массива. Рядом храните основание, статус ручной проверки и дату последнего изменения.
Поле 4: Есть несколько независимых примеров
Результат должен позволять проверить условие «есть несколько независимых примеров» без повторного чтения всего массива. Рядом храните основание, статус ручной проверки и дату последнего изменения.
Повторяющиеся вопросы после изменения восстановления доступа
После обновления интерфейса пользователи спрашивают, где найти резервный код. Операторы отвечают похожим способом, но действующая статья показывает старую кнопку. Один сотрудник предлагает обходной путь, допустимый только администраторам. Нельзя просто скопировать самый полный ответ в публичную базу.
Сценарий находит повторяемую тему, связывает ее со старой статьей и создает бриф на обновление. В примерах остаются обезличенные формулировки вопросов. Владелец процесса подтверждает новый путь для обычной роли, редактор обновляет снимки и дату пересмотра, а административное исключение не публикуется.
Если обращения показывают противоречивые решения разных команд, статья не создается до согласования правила. Очередь получает статус конфликта и владельцев. Модель не выбирает удобный ответ большинством голосов и не превращает временное обходное действие в официальную инструкцию.
Контрольные примеры для пилота
Запустить минимально заполненный пример для сценария «Обновление базы знаний из закрытых обращений» и убедиться, что недостающие поля отмечены явно.
Повторить один вход дважды и проверить, что автоматизация не создает вторую запись и не стирает ручные исправления.
Передать противоречивые данные, связанные с риском «Оператор мог решить случай исключением, которое нельзя превращать в общее правило.», и проверить переход к ручному разбору.
Искусственно отключить одно действие связки «Helpdesk + действующая база знаний + ИИ + редакционная очередь» и проверить уведомление, журнал ошибки и безопасный повтор.
Правила решений и остановки
- Остановить обычный маршрут, если возникает риск: Оператор мог решить случай исключением, которое нельзя превращать в общее правило.
- Передать ответственному случай, в котором возможно следующее: Старая статья может быть найдена как действующая без проверки версии.
- Не публиковать и не записывать итог автоматически, пока не исключен риск: Пример обращения способен содержать персональные или договорные сведения.
- При повторном запуске использовать устойчивый идентификатор и сохранять ранее подтвержденную версию результата «Очередь новых и устаревших статей с примерами запросов».
Что передать модели
Промпт задает формат черновика, но не заменяет проверки входных данных и ограничений платформы. Скопируйте его как основу и подставьте собственный справочник полей.
Сравни обезличенные решенные обращения с переданными статьями базы знаний. Верни recurring_question, existing_article, gap_type, evidence_examples, facts_to_confirm и proposed_outline. Не создавай официальное правило из ответа одного оператора и не копируй персональные данные.
Как работает сценарий
Выбрать решенные обращения
Выгрузка исключает открытые, тестовые и чувствительные диалоги и сохраняет только нужный текст без контактов клиента.
Найти существующую статью
Поиск определяет, был ли ответ в базе знаний и какую версию инструкции видел оператор.
Собрать кандидатов
ИИ группирует независимые формулировки вопроса, отмечает пробел, противоречие или устаревший раздел и сохраняет примеры.
Подготовить редакционный бриф
Кандидат содержит аудиторию, факты для подтверждения, запрещенные обещания, владельца и дату следующего пересмотра.
Утвердить публикацию
Владелец процесса проверяет правило, редактор пишет статью, а после публикации обновляется ссылка и версия в рабочей базе.
Проверочный список
Основные риски
Оператор мог решить случай исключением, которое нельзя превращать в общее правило.
Старая статья может быть найдена как действующая без проверки версии.
Пример обращения способен содержать персональные или договорные сведения.
Какие показатели отслеживать
Измеряйте путь до подтвержденного результата «Очередь новых и устаревших статей с примерами запросов», а не только скорость ответа модели.
Считайте изменения фактов, категорий и решений отдельно от стилистических правок. Так видно, где схема действительно ошибается.
Ошибки доставки, дубли и остановленные входы относятся к надежности автоматизации и не должны смешиваться с качеством текста.
Что уточнить перед внедрением
С чего начать безопасный пилот?
Возьмите небольшой исторический набор без лишних персональных данных, оставьте все действия в режиме черновика и сравнивайте результат с решением владельца процесса. Для связки «Helpdesk + действующая база знаний + ИИ + редакционная очередь» заранее проверьте права доступа и журнал ошибок.
Когда можно уменьшить ручной контроль?
Только после того, как накоплена выборка по типовым и сложным случаям, отдельно посчитаны смысловые исправления и подтвержден безопасный откат. Даже тогда исключения из раздела рисков остаются у человека.