В Части 1 этой серии мы исследовали персонажей, которые анализируют виртуальных помощников, и некоторые существующие инструменты, которые им помогают. В этом посте мы рассмотрим основные компоненты построения вашего собственного конвейера анализа. Построение собственного анализа позволяет полностью настроить анализ как для ваших конкретных персонажей, так и для вашего конкретного виртуального помощника.
При разработке анализа журнала Watson Assistant можно выделить четыре основных этапа:
· Соберите бревна
· Извлеките интересующие поля
· Определите аналитическую цель
· Фильтровать данные для аналитических целей
В оставшейся части этого сообщения в блоге мы подробно рассмотрим эти шаги. В третьей части этой серии будут продемонстрированы рецепты общих аналитических целей.
Соберите журналы
Первый шаг - определить, где находятся ваши данные журнала. В зависимости от архитектуры вашего приложения вы можете хранить полные или частичные данные журнала локально или в собственном облачном хранилище данных. Watson Assistant также хранит журналы с политикой хранения, которая зависит от вашего тарифного плана.
Watson Assistant предоставляет API для получения журналов. В API журналов каждый журнал представляет собой пару запрос-ответ, и позже мы рассмотрим, как соотнести эти журналы с разговорами. API журнала требует параметров запроса (таких как диапазон дат) и возвращает результаты с разбивкой на страницы. Если вы анализируете большие наборы данных, вам может понадобиться создать оболочку для обработки разбивки на страницы и ограничения скорости, применяемых API. Пользователи Python могут ссылаться на скрипт getAllLogs из WA-Testing-Tool.
API журнала имеет богатый синтаксис запросов, позволяющий точно указать, какие журналы вас интересуют. Чаще всего я использую фильтр с использованием диапазона response_timestamp (response_timestamp ›= 2017–07–01, response_timestamp‹ 2017-08– 01), чтобы получить все события за заданный период времени.
Я рекомендую загружать и хранить полные «сырые» (JSON) события журнала, пока вы не наберетесь достаточного опыта в аналитике, чтобы понять, какие поля вам нужны. Намного проще получить больше полей, чем вам нужно, и отфильтровать их позже, чем получить меньше полей, чем вам нужно! В следующем разделе я перечислю наиболее часто используемые поля журнала.
Извлеките интересующие вас области
API журналов документирует каждое из полей в объекте Журнал, включая дочерние объекты MessageRequest и MessageResponse, а также их дочерние объекты. Доступно множество полей, но я опишу здесь наиболее полезные поля для анализа и почему вы должны их использовать. Поля, начинающиеся с запрос. исходят от пользователя и тех, у кого есть ответ. происходят из Watson Assistant. Ограничение анализируемых полей значительно сокращает объем данных, хранящихся в памяти при выполнении анализа.
· request.context.conversation_id: вам нужен уникальный идентификатор, чтобы сопоставлять события журнала с беседой для выполнения аналитики на уровне беседы. Разговор_id уникален для пользовательского сеанса с одним навыком диалога. Если ваш помощник использует несколько навыков диалога для обслуживания одного разговора, вы должны использовать другое поле в качестве коррелятора разговора. (В большинстве помощников с несколькими диалогами уровень оркестрации предоставляет этот идентификатор корреляции и сохраняет его в объекте request.context).
· request_timestamp и response_timestamp: эти поля позволяют сортировать и фильтровать события по времени. В помощниках с несколькими навыками это лучшие поля сортировки в разговоре.
· response.context.system.dialog_turn_counter: для помощников с индивидуальным навыком это удобный ключ для ссылки на n -й поворот разговора. Код, на который ссылается эта серия блогов, обновляет dialog_turn_counter для использования также в помощниках с несколькими навыками.
· request.input.text: то, что пользователь на самом деле набрал (или сказал) помощнику. Это используется в большинстве пошаговых аналитик, включая сбор высказываний пользователей для создания новых слепых наборов и достоверных данных.
· response.output.text: чем система ответила пользователю. Хотя это не совсем полезно для аналитики, оно помогает аналитикам следить за ходом разговора. Самый простой ручной анализ диалога - это распечатать все пары request.input.text и response.output.text, отсортированные по request_timestamp.
· response.intents [0] .intent и response.intents [0] .confidence: представляют собой наивысшее намерение, выбранное классификатором, и связанный с ним показатель достоверности. Хотя навык диалога может не использовать намерения в каждом узле диалога, эти поля имеют решающее значение для аналитика намерений и полезны для других аналитических персонажей. Эти поля могут быть использованы для создания новой базовой истины.
· response.entities: сущности часто используются для увеличения намерений при достижении цели пользователя. Анализ сущностей помогает аналитику намерений уточнить разговорные ветвления, а также предоставить понимание бизнес-аналитикам.
· response.output.nodes_visited: в этом поле перечислены все диалоговые узлы, выполняемые Watson Assistant при доставке ответа пользователю. Каждый раз, когда навык диалога использует «Перейти к узлу», «Пропустить и оценить дочерние узлы» и «ответы с несколькими условиями», он будет иметь несколько записей в nodes_visited. Аналитик намерений может использовать это поле, чтобы определить, как пользователь реагирует (input.text) после посещения заданного узла диалога. Код, упомянутый в этой серии блогов, также создает поле «prev_nodes_visited», которое выравнивает node_visited после предыдущего сообщения в той же строке, что и текущее сообщение.
· workspace_id: это поле особенно полезно для помощников, владеющих несколькими навыками. В нем указывается, какой навык получил запрос пользователя.
· Переменные контекста для конкретного приложения: вы можете хранить произвольные данные в объекте контекста Watson Assistant. Эти данные будут храниться в request.context на уровне оркестрации или в response.context, если они сгенерированы Watson Assistant. Эти поля будут полезны бизнес-аналитику.
· request.context.vgwSessionID (для пользователей голосового шлюза): в речевых приложениях идентификатор сеанса голосового шлюза является лучшим идентификатором корреляции для разговоров, поскольку он уникален для каждого разговора, и его также можно использовать при оценке голоса Журналы шлюза.
· Уверенность речи (для пользователей «Преобразование речи в текст»): в речевых приложениях достоверность преобразования речи в текст полезна для оценки ответов Watson Assistant. Я рекомендую, чтобы ваш уровень оркестрации сохранял значение «results [0] .alternatives [0] .confidence» из речи в текст в поле «request.context.STT_CONFIDENCE» в Watson Assistant. Это очень важно для речевого аналитика.
Извлечение этих полей из события журнала JSON - относительно простое упражнение по синтаксическому анализу. Пользователи Python могут ссылаться на сценарий extractConversations из WA-Testing-Tool, который анализирует данные журнала JSON и создает как фрейм данных Pandas, так и файл CSV, содержащий только интересующие поля.
Определите аналитическую цель
Как уже говорилось в Части 1, у каждого персонажа разные области внимания. Аналитик намерений хочет найти ответы пользователя на вопросы открытого диалога. Аналитик намерений хочет видеть, какие узлы генерируют самые неожиданные ответы. Бизнес-аналитик хочет увидеть, сколько звонков увеличилось.
Поля интересов в предыдущем разделе могут быть объединены в рецепты, поддерживающие каждую из этих целей и многое другое. Анализ работает лучше всего, когда вы знаете, какова ваша цель анализа, однако ниже я расскажу о некоторых общих шаблонах, чтобы вы начали.
Фильтрация данных для аналитической цели
В зависимости от аналитической цели вам может потребоваться применить фильтр «с учетом разговора» к событиям журнала, чтобы систематизировать их по разговору, или вы можете оставаться независимым от разговора.
Например, «получить все ответы на узел диалога X» не зависит от диалога, в то время как «получить все первые ответы на узел диалога X» зависит от диалога (пользователь может посещать один и тот же узел диалога несколько раз в разговоре). Многие «подсчетные» аналитики могут быть выполнены любым способом: «сколько эскалаций произошло» можно ответить независимо от диалога, подсчитав количество событий с помощью узла эскалации в списке nodes_visited, но фильтр с поддержкой диалога также может сказать вам что произошло до или после эскалации. По возможности начните с аналитики, не зависящей от беседы, поскольку ее немного проще реализовать.
В следующем посте я продемонстрирую рецепты, обслуживающие общие аналитические паттерны.
Выражаю благодарность следующим рецензентам этого поста: Эрику Уэйну, Айшварии Харихаран, Одри Холломан, Мохаммаду Горджи-Сефидмазги и Даниэлю Зиска.
За дополнительной помощью в анализе и улучшении Watson Assistant обращайтесь в IBM Data and AI Expert Labs and Learning.
