Управление и контроль
Как изменения вводятся в работу
Путь, который проходит каждое изменение ваших ИИ-агентов от запроса до релиза, кто его утверждает, как сохраняется каждая версия и как можно отменить изменение, а также как обрабатываются срочные изменения.
На этой странице
Каждое изменение ваших ИИ-агентов проходит один и тот же задокументированный путь: его запрашивают, вносят в тестовой среде, тестируют, утверждают назначенные вами сотрудники, выпускают в работу и фиксируют. Так происходит независимо от того, исходит ли изменение от вашей команды, например новое правило эскалации, или от Telonic, например более новая языковая модель (компонент ИИ, который понимает диалог и составляет ответ). Каждое изменение фиксируется, и его можно отменить. Ваша организация всегда знает, что делают её агенты, почему и с какого момента.
Шесть шагов
| Шаг | Что происходит | Кто выполняет |
|---|---|---|
| 1. Запрос | Изменение предлагается с указанием причины | Ваша команда, в консоли (веб-приложении Telonic, которым пользуется ваша команда) или через ваше контактное лицо в Telonic; либо Telonic, если речь идёт об улучшении или изменении платформы |
| 2. Подготовка | Изменение вносится в тестовой среде и никогда не вносится напрямую в рабочую | Ваша команда, если речь о средствах контроля, которые остаются у неё; Telonic, если речь о работе по созданию |
| 3. Тестирование | Изменение проверяется на тестовом наборе вашей отрасли, наборе регрессионных тестов и, если это настроено, на смоделированных диалогах; ваша команда его опробует | Telonic и ваша команда |
| 4. Утверждение | Назначенные вами сотрудники изучают изменение и результаты тестов и утверждают его | Назначенные вами утверждающие |
| 5. Релиз | Изменение переносится в рабочую среду в согласованное время | Telonic или ваша команда, если речь о средствах контроля в консоли |
| 6. Фиксация | Новая версия фиксируется с указанием того, кто её запросил, кто утвердил и когда она была введена в работу | Фиксируется в консоли |
Кто может утвердить изменение
Сотрудников, которые утверждают изменения, вы назначаете по ролям во время внедрения. Для разных видов изменений могут требоваться разные утверждающие. Страховая компания может требовать, чтобы любое изменение охвата, ограничений или утверждённых ответов утверждала её служба комплаенса, а любую смену поставщика утверждала её служба информационной безопасности.
Прежде чем принять решение, утверждающие видят, что и почему меняется, а также результаты тестов. Изменение, которое не утверждено, не вводится в работу. Каждое утверждение фиксируется в журнале. См. раздел Средства контроля, которые остаются у вашей команды.
Каждое изменение фиксируется и может быть отменено
Для ваших агентов ведётся управление версиями (учитывается каждая версия конфигурации агента, поэтому любую более раннюю версию можно восстановить). Каждое изменение создаёт новую версию, а предыдущая сохраняется.
Если после ввода в работу изменение работает не так, как задумано, уполномоченный сотрудник может восстановить предыдущую версию. Восстановление версии само по себе является изменением: оно фиксируется с указанием того, кто и почему его выполнил. В истории изменений каждого агента видны все версии: что изменилось, кто запросил и утвердил изменение и когда оно было введено в работу. См. раздел Журнал аудита и записи о решениях.
Сравнение двух версий
A/B-тестирование позволяет параллельно запускать две версии агента, каждую на части диалогов, чтобы сравнить их результаты, прежде чем сделать одну из них стандартной. Оно полезно, когда действительно неясно, какой подход работает лучше, например при выборе между двумя способами объяснить план платежей или двумя вариантами порядка вопросов при первичном уведомлении о страховом случае.
Обе версии тестируются и утверждаются до начала сравнения. A/B-тестирование настраивается во время внедрения для тех рабочих процессов, где оно вам нужно.
Изменения, которые вносит Telonic
Telonic постоянно совершенствует платформу и отраслевые модели, и часть этих улучшений доходит до вашего развёртывания. Они проходят тот же путь: проверяются и тестируются перед релизом, в том числе на тестовом наборе вашей отрасли.
Любую смену модели или поставщика для вашего развёртывания ваша организация утверждает до релиза, а новая модель внедряется только в том случае, если на тестовом наборе вашей отрасли она работает как минимум так же хорошо. Вы получаете уведомление до любого существенного изменения в поведении ваших агентов или в платформе, на которой они работают. Срочные исправления безопасности применяются после их тестирования, и вам сообщают, что изменилось.
Срочные изменения
Когда что-то нужно изменить срочно, у вас есть два варианта, для которых релиз вообще не нужен. Вы можете перенаправить канал обратно на вашу команду, в вашей собственной телефонной системе или в консоли. Либо, если в исходном документе есть ошибка, вы можете исправить её в самом источнике, а знания агента обновляются вслед за вашими документами. См. раздел Контроль со стороны человека на практике.
Для изменения самого агента путь сокращается, но не отменяется. Изменение вносится в тестовой среде и проверяется теми тестами, которые к нему относятся. Его утверждает назначенный вами сотрудник, ответственный за экстренные утверждения, затем его выпускают в работу, а впоследствии разбирают вместе с вами. Оно фиксируется так же, как любое другое изменение.
Технические подробности
| Вопрос | Ответ |
|---|---|
| Что считается изменением? | Любое изменение конфигурации агента, его рабочих процессов, правил, ограничений, источников знаний, утверждённых ответов, тона, модели или поставщика |
| Где вносится изменение? | В тестовой среде. В рабочую среду оно переносится только после тестирования и утверждения |
| Как восстанавливается версия? | Уполномоченный сотрудник восстанавливает предыдущую версию, и это само по себе фиксируется как изменение |
| Считаются ли изменения ваших документов релизами? | Ваши документы обновляете вы сами. При изменении ваших документов знания агента переиндексируются (документы заново считываются и упорядочиваются для поиска), поэтому ответы агента опираются на последнюю утверждённую вами версию содержания |
| За какой срок уведомляют о существенных изменениях? | Как предусмотрено вашим договором |
На практике
Застройщик Sahel Crest Properties из Дубая использует агента на линии по передаче объектов.
- Руководитель службы клиентской поддержки замечает, что покупатели сообщают о сырости в квартирах. Она хочет, чтобы такие диалоги сразу передавались отделу передачи объектов и осмотр назначал сотрудник.
- Она предлагает изменение в консоли с указанием причины.
- Изменение вносится в тестовой среде. Оно успешно проходит тестовый набор для недвижимости, набор регрессионных тестов и проверку на наборе смоделированных покупателей, которые пишут на арабском и английском языках.
- Застройщик требует, чтобы изменения правил эскалации утверждала служба комплаенса. Менеджер по комплаенсу читает краткий отчёт о тестировании и утверждает изменение.
- Изменение выпускают в работу рано утром в воскресенье, до того как возрастёт нагрузка на линию по передаче объектов. Версия 23 вводится в работу, а версия 22 сохраняется.
- Через неделю команда анализирует передачи диалогов, вызванные новым правилом, и оставляет его в силе.
Что контролирует ваша команда
- Кто утверждает каждый вид изменений, включая срочные.
- Когда выполняются релизы.
- Восстанавливать ли предыдущую версию.
- В каких рабочих процессах используется A/B-тестирование.
См. также
- Тестирование перед каждым релизомУправление и контроль
- Средства контроля, которые остаются у вашей командыУправление и контроль
- Журнал аудита и записи о решенияхУправление и контроль
- Контроль со стороны человека на практикеУправление и контроль
- Безопасная разработка и тестированиеБезопасность и защита данных