CN101536084A

CN101536084A - 对话分析

Info

Publication number: CN101536084A
Application number: CNA200680024305XA
Authority: CN
Inventors: S·F·波特
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-06-30
Filing date: 2006-06-07
Publication date: 2009-09-16
Also published as: EP1894188A2; US7853453B2; JP2009500721A; KR101279738B1; WO2007005184A3; KR20080032052A; US20070005369A1; WO2007005184A2

Abstract

分析过程被应用于日志数据上，并使用诸如对话回合(用户－系统交换)信息等对话移动信息来揭示和/或诊断应用程序中最有可能的问题(图10)。

Description

对话分析

背景

以下讨论仅是为了概括的背景信息而提供的，并不旨在用于协助确定所要求保护的主题的范围。

人们在日常活动中越来越频繁地使用诸如个人数字助理(PDA)、设备和便携式电话等小型计算设备。随着现在微处理器可用于运行这些设备的处理能力的提高，这些设备的功能也在增加，并且在某些情况下合并。例如，现在许多便携式电话可用于访问和浏览因特网，以及可用于存储诸如地址、电话号码等个人信息。

由于这些计算设备被越来越频繁地使用，因此需要为用户提供用于将信息输入到计算设备中的简便的接口。不幸的是，由于期望将这些设备保持尽可能小以便于携带它们，将字母表的所有字母作为独立按键的常规键盘一般是不可能的，这是因计算设备外壳上可用的有限表面区域而引起的。即使不说小型计算设备的示例，对于为所有类型的计算设备提供更为便利的接口也存在着兴趣。

为了解决这个问题，对于使用话音或语音以便无论是在本地计算设备上还是通过诸如因特网等局域网访问信息越来越感兴趣并且得到越来越多的采用。使用语音识别，对话交互通常在用户和计算设备之间进行。用户一般可听地和/或可视地接收信息，同时可听地响应于提示或发出命令。然而，通常期望在应用程序开发期间或在部署应用程序之后查明其性能。具体地，期望从记入日志的数据中查明用户对应用程序的使用和/或成功率。有了这样的信息，开发者能够对应用程序进行“调整”(即作出调节)以便于更好地满足应用程序的用户的需求。例如，标识出应用程序和用户的对话中最可能遇到问题的部分会是有用的。这样，对话的这些部分可以被调节以减少混乱。

然而，从所部署的应用程序(例如语音或DTMF)的日志数据来确定对话问题是困难的。对话问题本质上是对于交互的流程的用户体验问题。它们通常会导致用户受挫，之后是挂机或者请求操作员协助。此外，就用户敌意以及支持开销而言，对于部署应用程序的实体，对话问题是代价昂贵的。

虽然对话问题的症状相当清晰(较低的任务完成率以及挂机或其他取消的增加)，但是这种问题的原因可能是非常难以发现的。典型的对话问题往往是系统和用户对手边的任务的理解之间的失配的结果。它们通常源于较低级别的应用程序问题，诸如混乱的提示，或错误地采用的路径(由于系统出错或用户误解)。

通常需要大量的会话数据来进行诊断，然而大量的会话数据意味着手动分析这种数据是冗长而单调的过程。例如，一般需要对话的冗长加长以使对混乱的完整描述能够浮现，这必须跨各个用户来概括。此外，查明问题的源位置(混乱开始的对话状态)是困难的；对于任何给定的挂机或其他用户取消，因为问题的源可能是取消之前的若干回合。此外，语音应用程序往往在其用户交互模式中有如此大的不同，使得自动化分析的实现一般是特定于应用程序的，并且其扩展性受到限制。最后，对于语音识别应用程序，语音识别器的不完美性意味着对用户行为的真实分析一般必须在用户输入的手动转录上找到—这是次要且通常代价昂贵的过程。

概述

提供本概述以便以简化的形式引入将在以下详细描述中进一步描述的一些概念。本概述并非旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于协助确定所要求保护的主题的范围。

对诸如但不限于语音、DTMF(双音调频)等用户/系统交互的对话分析提供了一种标识对各种各样应用程序通用的可能的对话问题的自动化技术，并且可以消除对响应/话语的转录的需求。堆堆日志数据应用分析过程，并使用诸如对话回合(用户—系统交换)信息等对话移动信息来揭示和/或诊断应用程序中最有可能的问题，对话回合信息诸如但不限于，回合类型(要求新的信息、要求值的确认、给出提供信息的陈述等)和提示类型(提问、给出陈述、提供帮助、重复提供信息的内容、响应‘不识别’事件、响应无声等)。

例如，假设每周接收几千个呼叫的电话系统(带有语音识别或DTMF输入)，可以对一周呼叫的日志执行数据分析，并且将突出应用程序的所有用户遇到的可能的问题区域。数据分析也可以提供对问题类型的指示，诸如但不限于“正在执行的”对话(任务)，即显示低水平的可用性，而不管其成功/失败率以及其原因；其中提示对用户而言是混乱的对话状态；其中开始对最大量的用户浮现问题的对话状态。

作为该数据分析的结果，调整该应用程序的开发者现在能够快速地执行分析以证实这些问题和/或在必要时修补任务和状态，而无需分析更多的数据或呼叫。这表示大量地节省应用程序维护和调整的时间和成本。

附图简述

图1是计算设备操作环境的第一实施例的平面图。

图2是图1的计算设备的框图。

图3是通用计算机的框图。

图4是客户机/服务器系统的体系结构的框图。

图5是示出用于在客户机侧标记中提供识别和可听提示的方法的框图。

图6是示出伴随控件的框图。

图7是用于创建启用语音的应用程序的方法的流程图。

图8是执行启用语音的应用程序的方法的流程图。

图9是对话分析模块的框图。

图10是用于执行有关较差性能的对话分析的方法的流程图。

图11是用于执行有关混乱提示的对话分析的方法的流程图。

图12是用于执行有关标识对话问题的源的对话分析的流程图。

详细描述

在具体描述对话分析(但不限于语音应用程序和DTMF)之前，概括地描述可在语音应用程序中使用的计算设备会是有用的。现在参考图1，在30处示出了一种示例性形式的数据管理设备(PIM、PDA等)。然而，可以构想本文中所描述的概念也可以使用以下讨论的其他计算设备，尤其是那些具有用于输入按钮等的有限表面区域的计算设备来实施。例如，电话和/或数据管理设备也可以得益于本文中所描述的概念。与现有的便携式个人信息管理设备和其他便携式电子设备相比，这种设备具有增强的用途，且这种设备的功能和紧凑尺寸更有可能促进用户一直携带该设备。因此，并不旨在使此处所描述的本申请的范围受限于此处所示的示例性数据管理或PIM设备、电话或计算机的公开。

一种示例性形式的数据管理移动设备30在图1中示出。移动设备30包括外壳32并具有包括显示器34的用户接口，它使用触敏显示屏幕结合指示笔33。指示笔33用于在指定的坐标处按下或接触显示器34以选择一域，以便选择性地移动光标的开始位置，或者以其它方式，诸如通过姿势或手写来提供命令信息。作为替代，或者除此之外，一个或多个按钮35可以被包括在设备30上以供导航。此外，也可以提供诸如可转动轮、滚轴等其他输入机制。然而，应该注意，本发明并不旨在受限于这些形式的输入机制。例如，另一种形式的输入可以包括诸如通过计算机视觉的可视输入。

现在参考图2，一框图示出了构成移动设备30的功能组件。中央处理单元(CPU)50实现软件控制功能。CPU 50耦合到显示器34，使得依照出现在显示器34上的控制软件来生成文本和图形图标。扬声器43可以耦合到CPU 50，该扬声器通常带有数模转换器59以提供音频输出。下载或由用户输入到移动设备30中的数据被存储在双向耦合到CPU 50上的非易失性读/写随机存取存储器存储54中。随机存储存储器(RAM)54提供对由CPU 50执行的指令的易失性存储，以及对诸如寄存器值等临时数据的存储。配置选项和其他变量的默认值被存储在只读存储器(ROM)58中。ROM 58也可用于存储设备的操作系统软件，这些软件控制移动设备30的基本功能以及其他操作系统内核功能(例如，将软件组件载入到RAM54中)。

RAM 54也以类似于PC上用于存储应用程序的硬盘驱动器的功能的方式用作代码的存储。应该注意，虽然使用了非易失性存储器来存储代码，但是可选地，代码也可以被存储在不用于代码执行的易失性存储器中。

无线信号可以由移动设备通过耦合到CPU 50的无线收发机52来发送/接收。如有所需，也可以提供可任选的通信接口60以便直接从计算机(例如台式计算机)或从有线网络下载数据。因此，接口60可以包括各种形式的通信设备，例如红外线链路、调制解调器、网卡等。

移动设备30包括话筒29以及模数(A/D)转换器37，以及存储在存储54中的可任选识别程序(语音、DTMF、手写、姿势或计算机视觉)。作为示例，响应于来自设备30的用户的可听信息、指令或命令，话筒29提供语音信号，该信号由A/D转换器37数字化。语音识别程序可以对数字化的语音信号执行归一化和/或特征提取功能，以获得中间语音识别结果。使用无线收发机52或通信接口60，语音数据可被发送到以下讨论并在图4的体系结构中示出的远程识别服务器204。接着可以将识别结果返回给移动设备30以供在其上呈现(例如可视和/或可听地)，并最后传送给web服务器202(图4)，其中web服务器202和移动设备30以客户机/服务器的关系操作。类似的处理可用于其他形式的输入。例如，手写输入可以在有或没有预处理的情况下在设备上数字化。如同语音数据一样，这种形式的输入可以被发送给识别服务器204以供识别，其中识别结果接着被返回给设备30和/或web服务器202中的至少一个。同样地，DTMP数据、姿势数据和视觉数据可以作类似的处理。取决于输入的形式，设备30(以及以下讨论的其他形式的客户机)可包括诸如摄像机等必要的硬件用于视觉输入。

除了上述的便携式或移动计算设备之外，还应该理解，本文中所描述的概念可以用于诸如通用台式计算机等许多其他机算设备。例如，具有有限身体能力的用户可以在诸如全字母数字键盘等其它常规输入设备难以操作时将文本输入或键入到计算机或其他计算设备。

本发明也可用许多其他通用或专用计算系统、环境或配置来操作。适用于本发明的公知的计算设备、环境和/或配置的示例包括，但不限于，无线或蜂窝电话、常规电话(没有任何屏幕)、个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子设备、网络PC、小型机、大型计算机、包括任何上述系统或设备的分布式计算环境等。

以下是对图3所示的通用计算机120的简要描述。然而，计算机120也仅是合适的计算环境的一个示例，并不旨在对本发明的使用范围和功能提出任何限制。计算机120也不应被解释为对以下所示组件的任何一个或组合具有任何依赖或要求。

以下描述可以在诸如程序模块等由计算机执行的计算机可执行指令的一般上下文中提供。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。本文中所描述的示例性实施例可以在分布式计算环境中实现，其中由通过通信网络链接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以同时位于包括存储器存储设备的本地和远程计算机存储介质中。借助附图，以下描述了程序和模块执行的任务。本领域的技术人员可以将该描述和附图实现为可被写入任何形式的计算机可读介质的处理器可执行指令。

参照图3，计算机120的组件可包括，但不限于，处理单元140、系统存储器150以及将包括系统存储器在内的各种系统组件耦合到处理单元140的系统总线141。系统总线141可以是若干总线结构类型中的任何一种，包括存储器总线或存储器控制器、外围总线、以及使用各种总线体系结构中的任一种的局部总线。作为示例，而非限制，这些体系结构包括工业标准体系结构(ISA)总线、通用串行总线(USB)、微通道体系结构(MCA)总线、增强型ISA(EISA)总线、视频电子技术标准协会(VESA)局部总线和外围部件互连(PCI)总线(也称为背板(Mezzanine)总线)。计算机120通常包括各种计算机可读介质。计算机可读介质可以是能被计算机120访问的任何可用介质，并包括易失性和非易失性介质、可移动和不可移动介质。作为示例，而非限制，计算机可读介质可包括计算机存储介质和通信介质。计算机存储介质包括以任何方法或技术实现的、用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的易失性和非易失性介质、可移动和不可移动介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁性存储设备、或任何其它可用于存储所需信息并可由计算机120访问的介质。

通信介质通常在诸如载波或其它传输机制等已调制数据信号中具体化计算机可读指令、数据结构、程序模块、或其它数据，且包括任何信息传送介质。术语“已调制数据信号”意指以在信号中编码信息的方式设置或改变其一个或多个特征的信号。作为示例，而非限制，通信介质包括诸如有线网络或直线连接等有线介质，和诸如声学、射频(RF)、红外线和其它无线介质等无线介质。以上任何介质的组合也应包括在计算机可读介质的范围中。

系统存储器150包括诸如只读存储器(ROM)151和随机存取存储器(RAM)152等易失性和/或非易失性存储器形式的计算机存储介质。包含有助于如在起动时在计算机120内元件间传送信息的基本例程的基本输入/输出系统(BIOS)153通常存储在ROM 151中。RAM 152通常包含可被处理单元140立即访问和/或当时正被操作的数据和/或程序模块。作为示例，而非限制，图3示出了操作系统154、应用程序155、其它程序模块156、和程序数据157。

计算机120还可包括其它可移动/不可移动、易失性/非易失性计算机存储介质。仅作为示例，图3示出了读取和写入不可移动、非易失性磁介质的硬盘驱动器161，读取和写入可移动、非易失性磁盘172的磁盘驱动器171，以及读取和写入可移动、非易失性光盘176，诸如CD-ROM或其它光学介质的光盘驱动器175。可在示例性操作环境中使用的其它可移动/不可移动、易失性/非易失性计算机存储介质包括，但不限于，磁带盒、闪存卡、数字多功能盘、数字录像带、固态RAM、固态ROM等等。硬盘驱动器161通常通过诸如接口160等不可移动存储器接口与系统总线141连接，而磁盘驱动器171和光盘驱动器175通常通过诸如接口170等可移动存储器接口与系统总线141连接。

如上所述并如图3所示的驱动器及其相关联的计算机存储介质为计算机120提供计算机可读指令、数据结构、程序模块和其它数据的存储。在图3中，例如，硬盘驱动器161被示为存储操作系统164、应用程序165、其它程序模块166和程序数据167。注意，这些组件可以与操作系统154、应用程序155、其它程序模块156和程序数据157相同或不同。在此给予操作系统164、应用程序165、其它程序模块166和程序数据167的不同编号以至少说明它们是不同的副本。

用户可通过诸如键盘182、话筒183、以及诸如鼠标、跟踪球或触摸板等的定位设备181的输入设备向计算机120输入命令和信息。其它输入设备(未示出)可包括操纵杆、游戏垫、圆盘式卫星天线、扫描仪等等。这些和其它输入设备常常通过与系统总线耦合的用户输入接口180与处理单元140相连，但也可通过诸如并行端口、游戏端口或通用串行总线(USB)等其它接口和总线结构连接。监视器184或其它类型的显示设备也可通过诸如视频接口185等接口与系统总线141相连。除监视器以外，计算机还可包括诸如话筒187和打印机186等其它外围输出设备，它们可通过输出外围接口188相连。

计算机120可以使用与一台或多台远程计算机，诸如远程计算机194的逻辑连接在网络化环境中操作。远程计算机194可以是个人计算机、手持式设备、服务器、路由器、网络PC、对等设备或其它常见的网络节点，并且通常包括以上关于个人计算机120所描述的许多或全部元件。图3中所描绘的逻辑连接包括局域网(LAN)191和广域网(WAN)193，但也可包括其它网络。这样的网络化环境在办公室、企业范围计算机网络、内联网和因特网上是常见的。

当用于LAN网络化环境中时，计算机120通过网络接口或适配器190与LAN191连接。当用于WAN网络化环境中时，计算机110通常包括调制解调器192或其它用于通过诸如因特网等广域网193建立通信的装置。可以是内置式或外置式的调制解调器192通过用户输入接口180或其它适当机制与系统总线141连接。在网络化环境中，关于计算机120所描述的程序模块或其一部分可被存储在远程存储器存储设备中。作为示例，而非限制，图3示出了远程应用程序195驻留在远程计算机194上。应当理解，所示的网络连接是示例性的，且也可以使用其它用于在计算机间建立通信链路的手段。

示例性实施例

图4示出了可以与本文所描述的概念一起使用的基于网络的识别(此处例示为广域网)的体系结构200。然而，应该理解，与远程组件的交互仅是一个实施例，这表现在包括识别器的语音应用程序可以在具有这里所提出的所有必须组件或模块的单个计算设备上操作。

一般地，存储在web服务器202上的信息可以通过移动设备30(在本文中也表示如基于输入形式所需地具有显示屏幕、话筒、摄像机、触敏面板等的其他形式的计算设备)或通过电话80来访问，在通过电话访问的情况中，响应于键被按下可听地或通过电话30生成的音调来请求信息，并且来自web服务器202的信息仅可听地提供回给用户。

在该示例性实施例中，体系结构200是统一的，这表现在无论信息是通过设备30还是使用语音识别的电话80获取的，单个识别服务器204都可以支持任一操作模式。此外，体系结构200使用公知的标记语言(例如HTML、XHTML、cHTML、XML、WML等)的扩展来操作。因此，存储在web服务器202上的信息也可以使用在这些标记语言中找到的公知GUI方法来访问。通过使用公知的标记语言的扩展，在web服务器202上的创作变得更简便，并且也可以容易地修改当前已有的传统应用程序以包括语音或其他形式的识别。

一般地，设备30执行由web服务器202提供的HTML+脚本等。当需要语音识别时，例如，可以是数字化的音频信号或者语音特征的语音数据(其中如上所述，音频信号由设备30作出了预处理)被提供给识别服务器204，并带有在语音识别期间使用的语法或语言模型的指示。识别服务器204的实现可以采取多种形式，示出了其中的一种，但一般地包括识别器211。识别的结果被提供回设备30以供在需要或适当时本地呈现。在通过识别和任何图形用户界面(如果使用)编译信息时，设备30将信息发送给web服务器202以供在需要时对其它HTML脚本的进一步处理和接收。

如图4所示，设备30、web服务器202和识别服务器204通常通过网络205，此处是诸如因特网等广域网来连接并且可单独寻址。因此，无需将这些设备中的任一个在物理上定位成彼此相邻。具体地，web服务器202不必包括识别服务器204。这样，web服务器202处的创作可以集中在它所想要的应用程序上，而作者无需知道识别服务器204的复杂性。相反，识别服务器204可以被独立地设计并连接到网络205，并由此无需web服务器202处所需的进一步改变来更新和改进。如下所述，web服务器202也可以包括可以动态地生成客户机侧标记和脚本的创作机制。在另一实施例中，web服务器202、识别服务器204和客户机30可以取决于实现机器的性能来组合。例如，如果客户机包括通用计算机，例如个人计算机，则客户机可以包括识别服务器204。同样，如有所需，web服务器202和识别服务器204可以被合并到单个机器中。

通过电话80访问web服务器202包括将电话80连接到有线或无线电话网络208，该电话网络又将电话80连接到第三方网关210。网关210将电话80连接到电话话音浏览器212。电话话音浏览器212包括提供电话接口和话音浏览器216的媒体服务器214。与设备30一样，电话话音浏览器212从web服务器202接收HTML脚本等。在一个实施例中，HTML脚本采用了与提供给设备30的HTML脚本类似的形式。这样，web服务器202无需单独支持设备30和电话80，或者甚至单独支持标准GUI客户端。相反，可以使用一通用标记语言。此外，与设备30一样，通过网络205或通过专用线路207例如使用TCP/IP从话音浏览器216向识别服务器204提供从由电话80发送的可听信号中作出的语音识别。web服务器202、识别服务器204和电话话音浏览器212可以被包含在任何适当的计算环境中，诸如图3所示的通用台式计算机。

然而，应该注意，如果采用DTMF识别，则这种识别的形式通常在媒体服务器214而非识别服务器204处执行。换言之，DTMF语法可由媒体服务器214使用。

再参考图4，web服务器202可以包括服务器侧插件创作工具或模块209(例如微软公司的ASP、ASP+、ASP.Net、JSP、Javabeans等)。服务器侧插件模块209可以动态地生成客户机侧标记，甚至是用于访问web服务器202的类型的客户机的特定形式的标记。可以在最初建立客户机/服务器关系时将客户机信息提供给web服务器202，或者web服务器202可以包括用于检测客户机设备的能力的模块或例程。这样，服务器侧插件模块208可以为每种话音识别情形(即，话音仅通过电话80，或对设备30为多模的)生成一客户机侧标记。通过使用一致的客户机侧模型，对许多不同客户机的应用程序创作将容易得多。

除了动态地生成客户机侧标记之外，下述的高级对话模块可以被实现为存储在存储211中的服务器侧控件，以供开发者用于应用程序创作。一般地，高级对话模块211可以基于开发者所指定的参数来动态地生成仅话音和多模情形中的客户机侧标记和脚本。高级对话模块211可以包括用于生成客户机侧标记以符合开发者的需求的参数。

客户机侧标记的生成

如上所述，当从客户机设备30作出请求时，服务器侧插件模块209输出客户机侧标记。简言之，服务器侧插件模块209允许定义或构造网站、由此允许定义或构造应用程序和由应用程序提供的服务。服务器侧插件模块209中的指令由编译代码组成。当web请求到达web服务器202时运该代码。服务器侧插件模块209接着输出要发送给客户机侧设备30的新的客户机侧标记页面。如所公知的，这个过程通常被称为呈现。服务器侧插件模块209对提取和封装标记语言及由此提取和封装客户机侧标记页面的代码的“控件”进行操作。这种提取和封装标记语言并在web服务器202上操作的控件包括或等价于“小服务程序(servlet)”或“服务器侧插件”等。

如所知的，现有技术的服务器侧插件模块可以生成客户机侧标记，用于可视地呈现并与客户机设备30交互。于2004年6月17日公布的题为“Web ServerControls for Web Enabled Recognition and/or Audible Prompting(用于启用web的识别和/或可听提示的web服务器控件)”的美国专利申请公开号US 2004/0113908和于2004年11月18日公布的题为“Application Controls for Speech EnabledRecognition(用于启用语音的识别的应用程序控件)”的美国专利申请公开号US2004/0230637A1都详细描述了用于将服务器侧插件模块209扩展成包括识别和可听提示扩展的三种不同的方法。虽然本发明的各方面可以与所有这些方法一起使用，但以下将出于解释一示例性实施例的目的而提供对一种方法的简要描述。

参考图5，识别/可听提示控件306与可视控件302分离，但是选择性地与之关联，如下所述。这样，控件306不会直接构建在可视控件302上，而是提供识别/可听提示启用，而无需重写可视控件302。如控件302等控件306使用了库300。在该实施例中，库300包括可视和识别/可听提示标记信息。

这种方法具有显著的优点。首先，无需改变可视控件302的内容。第二，控件306可以形成单个模块，该模块是一致的且无需依照启用语音的控件302的性质来改变。第三，语音启用过程，即明确地将控件306与可视控件302相关联，在设计时完全在开发者的控制之下，因为它是明确和选择性的过程。这也使得可视控件的标记语言可诸如通过控件306生成的标记语言所提供的识别或通过诸如键盘等常规输入设备从多个源接收输入值。简言之，控件306可以被添加到服务器侧插件模块209的可视创作页面的现有应用程序创作页面中。控件36为客户机设备30的用户提供了一种新形式的交互(即识别和/或可听提示)，而同时重复使用了可视控件的应用程序逻辑和可视输入/输出能力。考虑到控件306可以与对应用程序逻辑进行编码的可视控件306相关联，因此下文中可以将控件306称为“伴随控件(companion control)306”，而可以将可视控件302称为“主控件302”。应该注意这些称谓仅是出于区分控件302和306的目的而提供的，而非旨在限制。例如，伴随控件306可以用于开发或创作不包括可视呈现的网站，诸如仅话音的网站。在这种情况下，某些应用程序逻辑可以被包含在伴随控件逻辑中。

在图6中示出了一组示例性伴随控件400。在该实施例中，伴随控件400一般包括QA控件402、命令控件404、比较证实器控件406、自定义证实器控件408和语义映射图410。语义映射图410被示意性地示出，并包括可被认为是输入字段的语义项412，该语义项形成了可视域主控件402(例如HTML)和伴随控件400的非可视识别域之间的层。

QA控件402包括Prompt(提示)属性，该属性引用Prompt对象以执行输出控件的功能，即为人类对话提供“提示”客户机侧标记，这通常涉及播放预先录制的音频文件、或用于文本—语音转换的文本、直接包括在标记中或经由URL引用的数据。同样地，输入控件被具体化为QA控件402和命令控件404，并且也跟随人类对话且包括Prompt属性(引用Prompt对象)和Answer(回答)属性(引用至少一个Answer对象)。QA控件402和命令控件404两者都将语法与来自客户机设备30的用户的期望或可能的输入相关联。

此时，提供对每个控件的简短描述会是有帮助的。

QA控件

一般地，QA控件402通过所示的属性可以执行以下功能中的一个或多个：提供输出可听提示、收集输入数据、执行输入结果的置信度证实、允许确认输入数据以及协助控制网站处的对话流等。换言之，QA控件402包含用作对特定话题的控制的属性。

与其他控件一样，QA控件402在web服务器202上执行，这意味着它是使用服务器侧标记形式(ASP、JSP等)在web服务器上所保持的应用程序开发网页上定义的，但是作为一不同形式的标记输出到客户机设备30。虽然在图6中示出，其中QA控件看似是由所有属性Prompt、Reco(记录)、Answer、ExtraAnswer(额外回答)和Confirm(确认)组成的，但应该理解这些仅仅是选项，QA控件可以包括其中的一个或几个。

此时，按照应用情形来解释QA控件的使用会是有帮助的。参考图6，在仅话音应用中，QA控件402可以用作对话中的问题和答案。问题可以由Prompt对象提供，而通过Grammar对象来定义语法，用于识别输入数据和对该输入的相关处理。Answer属性使用Answer对象将识别出的结果与语义映射图410中的语义项412相关联，它包含关于如何处理识别结果的信息。线414表示将QA控件402与语义映射图410及其中的语义项412相关联。许多语义项412个别地与可视或主控件302相关联，如线418所示，虽然一个或多个语义项412可以不与可视控件相关联并且仅内部使用。在多模情形中，其中客户机设备30的用户可例如以“轻叩事件(TapEvent)”触摸可视文本框，则可听提示不是必须的。例如，对于包含具有形成关于客户机设备的用户应该将什么输入到对应的域中的指示的视频文本的文本框的主控件，相应的QA控件402可以有或没有诸如音频回放或文本—语音转换等相应提示，但会具有对应于供识别的期望值的语法，以及处理输入或处理诸如没有检测到语音、未识别语音等其他识别器事件或在超时的时候激发的事件的事件处理程序。

在另一实施例中，识别结果包括指示所识别出的结果是正确的置信度水平的置信度水平度量。也可以在Answer对象中指定确认阈值，例如置信度水平阈值等于0.7。如果置信度水平高于相关联的阈值，就认为该结果被确认。

也应该注意，除此之外或者作为替代，为了指定用于语音识别的语法，QA控件和/或命令控件可以响应于提示或问题来指定Dtmf(双音调频)语法以识别电话键的激活。

此时，应该注意当填充语义映射图410的语义项412时，通过例如语音或Dtmf的识别，可采取几种动作。首先，可以发出或激发指示值已被“改变”的事件。取决于是否满足置信度水平，可以发出或激发的另一事件包括指示对应的语义项已被确认的“确认”事件。这些事件用于控制对话。

Confirm属性也可以包括具有类似于以上关于Answer属性描述的结构的Answer对象，该类似性表现在它与语义项412相关联，并可在需要时包括一置信度阈值。Confirm属性本身并不旨在获取识别结果，而是确认已经获取的结果并从用户处查明所获取的结果是否正确。Confirm属性是用于断言先前获取的结果的值是否正确的Answer对象的集合。所包含的QA的Prompt对象会查询这些项，并从相关联的语义项412处获取识别结果，并在诸如“您说了西雅图吗？”等问题中形成该结果。如果用户使用诸如“是”等确定来响应，则激发已确认事件。如果用户使用诸如“不是”等否定来响应，则清除相关联的语义项412。

Confirm属性也可以在向用户提供了确认提示后接受改正。例如，响应于确认提示“您说了西雅图吗？”，用户可以用“旧金山”或“不是，旧金山”来响应，在任一情况下，QA控件接收到改正。有了关于通过Answer对象正在确认哪个语义项的信息，就可以将该语义项中的值替用经改正的值来替换。还应该注意，如有所需，确认也可以被包括在对信息的进一步提示中，诸如“您希望何时去西雅图？”，其中系统的提示包括对“西雅图”的确认以及对出发日的进一步提示。提供对目的地地点的改正的用户响应会激活Confirm属性来改正相关联的语义项，而仅有触发日的响应将提供对目的地的隐含确认。

ExtraAnswer属性允许应用程序作者指定除了已经作出的提示或查询之外用户可提供的Answer对象。例如，如果面向旅行的系统就目的地城市提示用户，但是用户通过指示“西雅图明天”来响应，则将重现最初提示用户的Answer属性，并由此将目的地城市“西雅图”与一适当的语义项绑定，而ExtraAnswer属性可以将“明天”作为接下去的一天(假设系统知道当天)来处理，并且由此将这个结果与语义映射图中适当的语义项绑定。ExtraAnswer属性包括为用户也可能声明的可能的额外信息定义的一个或多个Answer对象。在以上提供的示例中，在也已经检索到了关于出发日的信息之后，假设置信度水平超过相应的置信度阈值，系统于是无需再就这个信息来重新提示用户。如果置信度水平没有超过相应的阈值，则激活适当的Confirm属性。

命令控件

命令控件404是在仅话音对话中常见的用户说话，它通常在所提的问题方面具有极小的语义重要性，而是寻求协助或实现导航，例如帮助、取消、重复等。命令控件404可包括用于指定Prompt对象的Prompt属性。此外，命令控件404不仅可用于指定语法(通过Grammar属性)和对识别的相关联的处理(有点类似于没有将结果绑定到语义项的Answer对象)，而且还可用于指定上下文的‘范围’和类型。这允许对客户机侧标记上全局和上下文敏感行为的创作。命令控件404允许诸如“帮助”命令等其他类型的输入，或者允许客户机设备的用户导航到网站的其他选定区域的命令。

比较证实器控件

比较证实器控件根据一运算符来比较两个值，并采取适当的动作。要比较的值可以是任何形式的，诸如整数、文本串等。比较证实器控件包括指示要证实的语义项的属性SematicItemtoValidate(要证实的语义项)。可将要证实的语义项与一常数或另一语义项进行比较，其中该常数或其他语义项分别由属性ValuetoCompare(要比较的值)和SematicItemtoValidate提供。与比较证实器相关联的其他参数或属性包括用于定义要进行的比较的Operator(运算符)，和定义值的类型(例如整数或语义项串)的Type(类型)。

如果与比较证实器控件相关联的证实失败，则Prompt属性可以指定一可被播放的Prompt对象，从而指示用户，所获取的结果是不正确的。如果在比较时证实失败，则由要证实的语义项定义的相关联的语义项被指示为空，以使系统将就正确的值重新提示用户。然而，在不正确的值会被用于重复该不正确值的对用户的提示中的情况下，不清除语义映射图中的相关联语义项的不正确值会是有用的。取决于应用程序程序作者的期望，可以在相关联的语义项的值改变值时，或者在值已被确认时触发比较证实器控件。

自定义证实器控件

自定义证实器控件类似于比较证实器控件。属性SematicItemtoValidate指示要证实的语义项，而属性ClientValidationFunction(客户机证实函数)通过一相关联的函数或脚本指定了自定义证实例程。该函数可提供一关于证实是否失败的布尔值“是”或“否”，或者其等价物。Prompt属性可以指定一Prompt对象以提供对证实的出错或失败的指示。取决于应用程序作者的期望，可以在相关联的语义项的值改变值时，或者在值已被确定时触发自定义证实器控件。

控件执行算法

客户机侧脚本或模块(本文中称为“RunSpeech”(运行语音))被提供给客户机设备用于图6的控件。该脚本的目的是经由一逻辑来执行对话流，该逻辑当在客户机设备30上执行脚本时，即当由于脚本中包含的值而激活了涉及该控件的标记以便在客户机上执行时，在脚本中指定。脚本允许页面请求之间的多个对话回合，由此对于诸如通过电话浏览器216的仅话音对话的控制特别有用。客户机侧脚本RunSpeech以循环的方式在客户机设备30上执行，直至提交了完整的表单，或者是从客户机设备30请求了新的页面。

一般地，在一个实施例中，该算法通过输出语音和识别用户输入来生成对话回合。该算法的总体逻辑如下地用于仅话音环境(关于以上未讨论的属性或参数，参考2004年6月17日公布的题为“Web Server Controls for Web Enabled Recognitionand/or Audible Prompting”的美国专利申请公开号US2004/0113908)：

1.以语音索引顺序找出第一个活动的(如下所定义的)QA、比较证实器或自定义证实器控件。

2.如果没有活动的控件，则提交页面。

3.否则，运行该控件。

QA在且仅在以下情况下被认为是活动的：

1.QA的ClientActivationFunction(客户机激活函数)或者不存在，或者返回真，并且

2.如果Answer属性集合为非空，则Answer集合所指向的所有语义项的状态为空，或者

3.如果Answer属性集合为空，则Confirm数组中的至少一个语义项的状态为NeedsConfirmaiton(需要确认)。

然而，如果QA使得PlayOnce(播放一次)为真，且其提示被成功运行(到达OnComplete(在完成时))，则QA不会成为激活的候选项。

QA如下运行：

1.如果这是与先前的活动控件不同的控件，则重置提示计数值。

2.递增提示计数值。

3.如果指定了PromptSelectFunction(提示选择函数)，则调用该函数并将Prompt的inlinePrompt(内嵌提示)设置成返回的串。

4.如果Reco对象存在，则启动它。该Reco应该已包括任何活动的命令语法。

证实器(比较证实器或自定义验证器)在以下情况下是活动的：

1.SemanticItemToValidate还没有被该证实器验证，且其值已被改变。

比较证实器如下运行：

1.依照证实器的Operator，比较SemanticItemToCompare(要比较的语义项)或ValueToCompare(要比较的值)和SemanticItemToValidate的值。

2.如果测试返回假，则将SemanticItemToValidate的文本域置空，并播放提示。

3.如果测试返回真，则将SemanticItemToValidate标记为经该证实器证实。

自定义证实器如下运行：

1.使用SemanticItemToValidate的值来调用ClientValidationFunction(客户机证实函数)。

2.如果该函数返回假，则清除语义项并播放提示，否则如由该证实器所证实的。

命令在且仅在以下情况下被认为是活动的：

1.它在范围内，并且

2.在范围树的较低处没有相同类型的另一个命令。

在多模情况下，该逻辑被简化为以下算法：

1.等待触发事件—即用户轻叩控件；

2.收集预期回答；

3.监听输入；

4.将结果绑定到语义项，或者如果没有结果，则抛出事件；

5.返回到1。

在多模环境中，应该注意如果用户改正了文本框或者与结果的可视表示相关联的其它输入域，则系统可以更新相关联的语义项以指示值已被确认。

在图6中所示的另一实施例中，提供使得应用程序作者能够创建处理电话事务的语音应用程序的呼叫控件407以及应用程序控件430，后者提供了在一种控件中装入各常见语音情形的手段。呼叫控件407和应用程序控件430对于实施本发明而言不是必须的，但仅是为了完整性起见而提及的。对这两个控件的进一步讨论在2004年6月17日公布的题为“Web Server Controls for Web Enabled Recognitionand/or Audible Prompting”的美国专利申请公开号US 2004/0113908和于2004年11月18日公布的题为“Application Controls for Speech Enabled Recognition”的美国专利申请公开号US 2004/0230637A1中提供。

记录用户交互数据

作为示例使用上述结构，应用程序开发者能够开发启用语音的应用程序。然而，本文中所描述的各方面允许开发者记录用户交互数据或将其记入日志。

然而，应该理解，本文中所描述的概念不限于上述用于提供对话，模型的对话创作结构，而是可以被应用于生成对话模型的任何创作工具，诸如但不限于被实现为中间件、API(应用程序接口)等，并且被配置成记录部分或全部以下描述的信息的那些工具。此外，诸如电话应用程序等启用语音应用程序的功能性质及其话音用户接口的细节可以在域和应用程序类型之间有较大的不同，由此任何启用的自动化日志记录一般仅是启试探性的，而非确定性的。因此，对此的一个实现可能是将自动化日志记录事件属性实现为可覆盖的默认值，而非不可改变的属性。然而，对丰富信息的日志记录的简化和促进相对于依赖于手动和程序性创作的系统仍然是很大的进步。

再参考图4，当为任何类型的用户执行应用程序(诸如但不限于经由移动设备30或经由电话80访问)时，依照对话控件211执行启用语音的应用程序的web服务器202将用户交互日志数据记录在存储217中。

如所需地，应用程序通常，而不是专门地被定义或编写为一组分层控件，此处通常例示为结合命令控件404的QA控件402、应用程序控件430、呼叫控件407和证实器406和408。该分层结构定义了要完成的总体任务，以及完成该总体任务的其子任务。该分层结构中的层数取决于应用程序的复杂程度。例如，应用程序可以总体地针对作出机票预定(即，最高层任务)，而两个主要的子任务针对获取出发信息和到达信息。同样，可以为获取出发信息和获取到达信息的主要子任务中的每一个定义进一步的子任务，具体地，为获取出发/到达机场信息、出发/到达时间等。这些子任务可能在包含它们的任务中以一序列出现。

一般地，记录两种类型的数据，任务/对话数据和回合数据。从任务/对话数据开始，如在日志中表示的该数据应该按照任务和子任务来捕捉应用程序的分层或顺序结构。图7示出了用于创建应用程序的方法500。在502处，对话创作工具允许按照嵌套或顺序的任务单元来创作或定义对话，使得当开发者编写启用语音的应用程序时，作者一般会以模块化的方式来编写。即，会鼓励作者将各个回合组合成一完成特定任务的集合，并且将各个任务组合成完整更高层任务的集合。由于在设计时任务结构和进出各个任务的流是已知的，因此在步骤504处，启用对进出任务(例如通过任务开始和任务完成事件)以及从用户处获取的用于由应用程序使用的输入域的回合数据和值(在本文中被例示为“语义项”)的日志记录，以提供对任务结构的序列和/或分层结构的自动化日志记录。这意味着对话流、获取的值和任务结构可以从事件日志中明确地恢复和构建。应该注意，仅出于解释的目的单独示出了步骤502和504，这些步骤的部分或全部特征可以用不同的顺序或并发地执行。

该数据还量化了完成任何给定任务或子任务的成功、失败或其他(例如，未知)状态。此外，任务/对话数据包括任务不成功或失败的原因，或者其完成状态未知的原因，或者如果适用，在可能有多个继续进行的原因的情况下的继续进行的原因。其他数据可以包括指示用户是否没有提供响应或者语音识别器不能识别出话语的进展数据。还可以记录输入域值的列表，或应用程序对基于提示或用户响应或其状态或与其相关联的值所使用的存储位置。

图8示出了用于执行启用语音的应用程序的方法520。方法520包括在步骤522处执行按照具有一个或多个回合的任务来定义的启用语音的应用程序。步骤524包括记录与任务、回合和语义项相关的信息。应该注意，仅出于解释的目的单独示出了步骤522和524，这些步骤的部分和全部特征可以用不同的顺序或并发地执行。

在一个实施例中，任务/对话数据包括部分或全部以下的信息：

任务/对话数据

名称：作者定义的用于任务/对话的串标识符，例如“getCreditCardInfo(获取信用卡信息)”、“ConfirmTravel(确认旅行)”等。如果作者在设计时没有提供名称，则给出默认名称，例如Dialog1(对话1)、Dialog2(对话2)、DialogN(对话N)......

父：包含该任务/对话的对话的名称(为了从日志重构对话分层结构)

任务开始：首次进入任务/对话的时间戳

任务完成：退出任务/对话的时间戳。对于任何打开的对话，在使用默认值关闭应用程序时总是应该从下到上激发该事件(即，在日志中不会有“在结束时仍打开”对话)。

状态：任务/对话的完成状态，可由作者设置、基于对话的执行自动推断、或者基于作者定义的条件半自动地设置。在一个实施例中，默认值状态可以是“UNSET(未设置)”，其中后续值可以是以下之一：

SUCCESS(成功)

FAILURE(失败)

UNKNOWN(未知)

自动任务完成状态

在某些情况下，如上所述，可以从任务退出的性质中以合理的确定性推断出任务的状态是否为成功、失败或未知中的一个。例如，由于出错或异常而结束的任务可以被自动地以完成状态Failure记入日志。同样地，取消的任务(例如其中对任务对象调用Cancel()方法)可以自动地以完成状态Failure记入日志。类似地，由于达到了某一“出局”(例如以下讨论的MaxSilence(最大无声)或MaxNoReco(最大无记录))计数而结束的任务会自动地以完成状态Failure记入日志。

相反地，以该任务中遇到，或者在设计时被指定为属于该任务的、具有基础(grounded)(用户输入或从中导出的)值的回合的所有语义项(即应用程序的输入域)自然结束(即没有被取消)的任务会被自动地以完成状态Success记入日志。

半自动任务完成

任务状态日志记录的部分自动化也是有用的。对于给定的任务，作者可以在步骤502处指定或定义针对任务成功或失败的一组条件，如果满足这些条件，则确定该任务在退出时的任一点上的状态。条件可以是程序性的(例如foo＝＝’bar’)，或者更有用地，可以简化条件，使得作者只需要为每个任务指定一个或多个语义项(例如为出发城市和到达城市提供的值)，且当那些语义项具有确认的值时系统会自动将Success记入日志，并且可任选地，当那些语义项不具有确认的值时将Faiulre记入日志。

这个方面是有用的省时机制，因为它意味着任务状态日志记录无需在任务的每个退出点上程序性地编码。相反，只要最终用户退出任务，就自动地评估条件，并且确定状态且将其记入日志而无需额外的开发者代码。

原因：对话完成的原因，可以由作者设置，例如

命令—用户说出的用于改变到对话的不同部分的命令以及命令的性质(即“取消”、“运算符”、“主菜单”等)；

用户挂断—用户挂断，或者用其他方式退出或放弃；

应用程序出错)—发生应用程序出错

最大无记录(maxNoReco)—达到未识别的话务的最大数

最大无声(maxSilence)—达到无声用户响应的最大数

语义更新：

项：任何其值/状态有改变的语义项的列表，包括新的值和对应的状态。一般地，该数据与以下所述的回合数据相关，这表现在对于每个对话回合(由应用程序/响应或用户没有响应来提示)，语义项值和/或状态中的一个或多个会改变。然而，在某些情况中，应用程序自身能够改变语义项。例如，如果应用程序不能证实诸如信用卡卡号等值，那么它自己可以清除该值，而无需基于对话回合来清除。然而，这一改变会被记录。

回合数据包括与应用程序的直接交互，并且基于由应用程序提供的提示(当未预期响应时)、或者与用户响应或没有响应相关的应用程序提示来组织，换言之，提示/响应交换或者用户提供的命令并非必须响应提示，或者至少是未预期是对提示的响应的响应。因此，可以记录的数据的三个区域包括与应用程序提供的提示相关的信息、用户提供的响应(可以是预期的或非预期的响应)以及系统确定的识别结果。在一个实施例中，回合数据包括以下信息的部分或全部：

回合数据

配置

名称：作者定义的串标识符。如果作者在设计时没有提供名称，则可给出默认名称；然而，需要清楚且一致地在同一对话/任务中的不同回合之间进行区分。一种可能的技术是基于提示的名称和类型。

类型：可以从与之相关联的语义项的性质推断出特定回合的目的的详细说明。在上述情况下，语义项通过回答、额外回答和确认的概念与回合相关联。

回合目的的示例包括：

要求新的确认(回合启用回答)

确认相关信息(接受/拒绝，回合启用确认)

给出信息声明(回合没有回答和确认)。

父：包含该配置的对话/任务的名称(为了从日志中重构对话分层结构)。

语言：所使用的语言。

语音语法：与所使用的语音识别语法相关的信息。

DMTF语法：与使用的DMTF识别语法相关的信息。

阈值：用于拒绝值和/或确认值的置信度阈值

超时：允许提示后初始无声和用于确定响应的结束的结束无声的时间段，以及认为声音模糊不清的时间段

提示

名称：可任选，由于可以使用回合数据名称，可以不是必需的。

类型：对话模型可以包括多个预定义的提示类型，其中任何一个可以由应用程序选择，对它的使用允许记录系统试图作什么来实现，即回合的目的。

提示类型的示例包括：

主提示(MainPrompt)—提出问题(或给出声明)

帮助提示(HelpPrompt)—提供帮助

重复提示(RepeatPrompt)—重复信息内容

无识别提示(NoRecognitionPrompt)—响应“无识别”

无声提示(SilencePrompt)—响应无声

升级的无识别提示(EscalatedNoRecognitionPrompt)—在多次尝试后响应“无识别”

升级的无声提示(EscalatedSilencePrompt)—在多次尝试后响应无声

由于这些类型是预定义的，且在任何时候可用于选择，因此它们可以按照类型自动地记入日志，这使用给定提示的目的的概念自动地丰富了日志数据以达到回合的目标。

因此，提示类型与回合类型相结合—在对话创作模型中它们都是编程原语，因此当应用程序遇到时被自动地记入日志—允许在日志中任一点处的系统目的的丰富视图。

语义项：进行相关提示的语义项(用于链接询问/确认循环等)。

对话模型使用语义项的概念，每个语义项含有值和状态，以便简化对话流创作。通过自动地将每个语义项的改变值和状态记入日志，并将其与任务和用户/系统移动信息组合，进一步丰富了日志。

回答/额外回答/确认模型将语义项链接到回合，因此链接到任务。因此，所知的是(且可以被自动地记入日志)，哪个语义项与哪个系统移动和哪个用户移动相关，以及哪个有助于哪个任务。

提示的文本内容：例如“欢迎”

插嘴(bargein)：开/关/中间提示时间

用户察觉的等待时间：用户响应和播放下一提示之间的时间段。当系统负荷较重时，该时间段可能较长，这会使得用户混淆，因为用户可能相信应用程序没有响应。

TTS：真/假—用于生成提示的文本—语音。

提示完成时间：完成/切断提示的时间。

提示波文件：提供的实际提示。

用户输入：

模式：用户是提供DTMF还是语音

类型：用户是否提供命令，如果是，是什么类型的(例如帮助/重复/等)，或者用户是否提供响应，如果是，是什么类型的(回答/确认/拒绝)

对话模型将应用程序的语法的功能分类到不同类型的用户响应，即回答、接受、拒绝等，这些用户响应指示用户提供响应的目的。这些类型可以直接被记入日志，作为系统相信用户正试图完成事件的指示符。不同响应类型的示例如下：

回答—用户向请求值的问题提供回答。

额外回答—用户提供问题焦点之外的回答。

接受—用户确认一条信息。

拒绝—用户拒绝一条信息。

帮助命令—用户要求帮助。

重复命令—用户请求信息的重复。

其他命令—用户发出某种其他形式的命令(没有明确地归类，但是知道它不是上述类型中的任一种)。

无声—用户没有说话(这有时被用作一种形式的‘隐式接受’)

由于这些类型与特定的语法相关联，因此只要用户说出任何与相应语法匹配的话，就可以自动地将它们记入日志。许多系统允许单个对话回合包括多种类型—例如在单个回合中接受一个以上项，或者回答一个项并接受另一个。

无声：如果检测到无声，相对于最大无声它是哪个数字或计数。

无记录(NoReco)：如果对该话语没有检测到识别，相对于最大无记录它是哪个数字或计数。

出错：如果发生出错，它是否会被应用程序或平台抛出。

结果：

识别结果：系统返回识别结果。通常，识别结果包括用于经解释的话语的语义标记语言(SML)标签。此外，在适当时可以提供N个最佳的备选解释和音频记录结果。

除了每个解释之外：

没有SML标签的话语文本(如果提供语音)或者按键(如果提供DTMF)。

置信度：解释的置信度水平。

语义映射：SML结果的各部分和语义项之间的链接。换言之，来自SML结果中的哪个值会被置于哪个语义项中。

语法规则匹配：语法中的哪条规则与用户输入匹配。

置信度：作为整体的话语。

插嘴：用户插嘴的定时，或为空(如果不存在插嘴)。

识别波文件：实际记录的用户输入和指向它的指针。

总之，记入日志的用户交互数据允许将对话看作在感兴趣的某些域(例如表单域或槽值)上操作的任务的分层或顺序结构，并且任务中的每个对话回合将有关表单域的系统目的(对话移动)(例如询问值、确认它、重复它等)以及语音识别器相信是用户目的的内容(例如提供值、拒绝它、寻求帮助等)记入日志。

使用该结构来实现实施优势。具体地，对系统性能的分析得到改进，因为任务完成的成功或失败一般是明确的，因此很大程度上简化了报告的事务成功率，并且能更好地理解完成任务所采取的对话步骤的性质(因为在创作时每个步骤背后的目的是已知的)。

由于其结合到对话创作工具中的方式，实现这种形式的数据日志记录是简便的。这种装备的高层性质对于各种各样的应用程序类型是通用的，并且日志记录的实际细节在创作时通过其在概念上以及对于日志记录原语集成到创作工具中而变得容易。由此，鼓励了应用程序作者使用任务/子任务模型来构造应用程序，并且指示从任务出发的哪些转换指示成功完成，且它们无需明确地装备系统/用户目的日志记录，因为那被构建到会话回合创作模型中。

对话分析

以下描述一般地参考任务层上的分析；然而，所有的原理都适用于任务和会话层两者上(即，将会话作为单个任务来分析，其中较低层的任务结构化是未知的或被忽略)。

参考图9，对话分析模块600接收诸如上述的输入的记入日志的应用程序数据，并对其执行分析。一般地，出于解释的目的，对话分析模块600可包括较差任务性能诊断模块602、混乱提示分析模块604以及用于标识对话问题的源的模块606。虽然可以将它们有利地结合使用，但每个过程或模块可以独立于其他来使用。以下可以提供指示各度量的报告或其他适当的输出。如果适用，可以在任务的基础上提供度量。

1.诊断较差任务性能

图10的较差任务诊断模块602及其相应的过程603揭示或标识应用程序中应该被分析或调整的较差执行的部分，和/或提出较差性能的原因。它在步骤605处从记入日志的数据分析每个会话或任务(任务是包含对话回合、子任务或两者的对话的结构化组件)，并且在步骤607处推断‘任务可用性’的度量。这一度量，尤其是以下描述的度量是基于用于完成任务的对话移动序列的模式(由例如回合类型或响应类型指示)的对用户体验的成功的指示符。

过程603可用于独立于或者结合任务成功/失败的显式指示符和记入日志的数据中存在的其他度量来使用。这些指示符是显式应用程序装备的结果，它确定当任务完成时应该如何将其状态记入日志(通常为值成功/失败/未知)以及如何使用这些状态来生成关于总体任务完成率的报告。其他显式指示符包括原始回合计数以及持续时间。单独使用时，显式指示符对任务的用户经验有极少的洞察；然而，此处所描述的分析提供了较深的洞察。这对于跨所有任务(从那些具有较低的完成率的任务到具有较高的完成率的任务)；来评估任务性能是有价值的，因为它提供了任务效率和可用性的度量。这些可用于预测总体任务性能的可能原因和/或用作提高性能和优化用户体验的度量。

以下度量中的一个、一些或所有可以跨用于分析的数据集从给定任务的所有实例中计算出。

确认评分

模块610在步骤611处获取涉及关于接收到的响应的确认的回合与有关要求接收到的响应的回合之比的指示。在示例性实施例中，模块610计算确认评分，它是指示“确认”回合与“请求”回合之比的值。例如，可以通过将“确认”回合数相加，并将其除以“请求”回合数来计算该比率。这样，确认比“1”指示在任务中请求和确认数相等。一般地，较低的比率(使用该示例)会指示更高效的对话交互(虽然某些应用程序会要求交易推断出每个请求的显式验证)。较高的确认水平的原因(即比期望的发生更多的“确认”)会可示较差的设计的对话流、次优的置信度阈值和/或语法问题。如本领域的技术人员所理解的，可以使用用于“确认”与“请求”作比较的不同度量。但是，一般底，归一化(例如使用用于确定评分的比率)会是有利的，因为它允许人们将一个任务相对于另一个任务作比较，而不考虑每个任务的提示和答案的数目会不同的这一事实。

语义项回合评分

模块612在步骤613处获取涉及关于请求接收到的响应的回合与其中对响应的请求跨数据出现的任务实例之比的指示。在所示实施例中，模块612计算语义项或响应回合评分，它是在每个语义项(SI)的基础上通过将该SI的请求回合数求和并将其除以其中对语义项的请求跨数据出现的任务实例数来计算的(如这里所使用的，语义项记录了由用户提供的响应)。通过在语义项的基础上计算该评分，给出了对获取特定语义项的值的困难的洞察—较高的比率指示作出了多次尝试来请求项；较低的值表示较少的尝试。

示例可以是该过程标识难以在不失败的情况下获取信用卡号，因为用户必须一次提供全部的多个数字。例如，取决于应用程序，这种提示可能在对话中的多个位置处出现；然而使用相同的语义项。如果是这种情况，则解决方案可以是向用户请求信用卡号的较小集合。

应该注意，如有所需，对于具有多个SI(来自用户的响应)的任务，可以计算单个有代表性的评分作为所有各个SI回合评分的平均数。

语义项有效性评分

模块614在步骤615处获取涉及关于确认接收到的响应的回合与基于接收到的响应分配的值之比的指示。在所示实施例中，模块614计算语义项或响应有效性评分，它可在每个响应或语义项(SI)的基础上通过将确认了SI的值的次数相加并将其除以将值分配给该SI的总次数来计算。该评分给出对用于获取语义项的任务的效率的洞察—这是否则可能由于较高的回合计数或确认评分而变得不明显的洞察。语义项有效性评分的较高值表示较高的接受率；而较低的值表示较高的拒绝率。应该注意，如有所需，对于具有多个SI(来自用户的响应)的任务，可以计算单个有代表性的评分作为所有各个SI有效性评分的平均数。

用户重复率

模块616在步骤617处获取涉及基于用户请求用户重复回合的指示。在所示实施例中，模块616计算用户重复评分，它是在每个回合的基础上通过将重复进入回合的次数相加(其中重新进入是由于用户请求而非无声或不识别而发生的)并将其除以该回合发生的总数来计算的。用户对重复的请求通常包括命令帮助、重复和返回，但也可以包括导致直接重新进入当前或前一状态的任何命令。较高的值指示较高的重新进入水平，这意味着从该状态开始的用户混乱，较低的值指示较低的重新进入水平。

2.混乱提示

模块604和相应的过程619(图11)被用于获取关于应用程序中哪些提示造成混乱的指示。在步骤621处，对给定回合的提示接收已记入日志的数据，而在步骤623处计算出‘混乱等级’，以确定是否应该为了清楚或简单而调整提示用语。在该示例中，该等级越高，就越有可能需要调整提示。

可以从以下发生的事件计算出示例性混乱等级：

(a)无声计数：在提示之后用户无声(没有输入)的次数；

(b)帮助计数：在提示之后用户请求协助的次数；

(c)重复计数：用户请求系统重复提示的次数；

(d)拒绝率：(对于类型为请求的回合)：拒绝或取消语义项值(即，对提示的识别出的响应)的次数。

这各个总数对数据中提示的实例数求和。应该注意，不同的加权因数可以应用于不同的组成部分(a)-(d)上。所得等级可单独使用，或者它可以结合从反应用户理解响应的时间的较低水平的识别器数据计算出的因数：

(e)响应等待时间：例如提示结束和用户响应开始之间的平均(或其他度量)等待时间。(这假设人们对混乱提示的响应比不混乱的提示的响应要慢)。应该注意，该评分本身可以提供关于提示的混乱等级的指示。

3.标识对话问题的源

模块606和相应的过程631(图12)用于找出可能是造成用户放弃任务的问题的源的状态。相对于识别类型来确定任务放弃。对于语音和DTMF，以下动作中的任一个可以被认为是放弃：

—用户挂机

—取消当前任务的用户命令(例如“取消”)

—请求转到代理人的用户命令(例如“操作员”)

—请求转到代理人的DTMF按键(例如0)

过程或方法631适用于其中已知用户至少一次试图与自动化系统交互(即在呼叫开始时，没有尝试放弃动作)的会话。该过程试图找出从中可找出问题状态的最近已知的正确状态。该过程如下：

对于每个用户会话，在步骤629处接收已记入日志的数据并使得任务结构平面化，即：将对话回合和/或任务进入和/或完成状态作为状态的一维列表来对待，该列表如步骤633处所示按时间排序；然后：

在步骤635处定位放弃的点；

在步骤637处从放弃动作通过对话回合的序列反向跟踪，直至遇到以下状态之一(注意可以改变以下顺序)：

(a)如果如步骤639所示遇到了带有状况“成功”的任务完成，则认为紧接着的回合状态是问题源

(b)如果如步骤641所示用户接受一值，或是遇到了期间语义项达到“确认”状态的任何回合，则认为紧接着的回合状态是问题的源

(c)如果如步骤643所示用户拒绝/改正一值，或是遇到了期间语义项导致“空”状态或改变其值的任何回合，那么认为其中所讨论的语义项为“请求”类型的回合的话题的最接近的前一回合状态是问题的源

(d)如果如步骤645所示遇到用户“返回”或在会话中实现追溯用户步骤的其他命令，则采用该返回命令(或者如果在序列中，则为多个返回命令)之后的回合的名称，并认为在初始的返回命令之前的回合的最接近实例是问题的源；

(e)如果如步骤647所示达到会话的开始处，则假设会话中的第一信息请求回合状态(即第一请求或命令启用)是问题的源；

(f)否则，对于所有其他的回合类型，保持反向跟踪(即返回步骤637)。

结果可跨会话整理并被表示为按照造成任务放弃的可能性排列的状态列表。例如，在发生了76次放弃的用户数据中，45次是在“回合A”状态、15次是在“回合B”状态、14次是在“回合C”状态而2次是在“回合D”状态。

虽然以上参考具体实施例描述了本发明，但是本领域的熟练技术人员应该认识到可以作出形式和细节上的改变而不背离本发明的精神和范围。

Claims

1.一种分析用户和具有对话回合的交互式应用程序之间的对话的计算机实现的方法(603)，其中回合包括来自系统的提示以及从所述用户接收的响应，所述方法包括：

接收指示应用程序中所述系统和至少一个用户之间的对话回合的信息(605)，所述回合与所述应用程序的一个或多个任务相关；以及

获取所述应用程序相对于所述一个或多个任务的性能的指示(607)。

2.如权利要求1所述的计算机实现的方法(603)，其特征在于，获取所述应用程序相对于所述一个或多个任务的性能的指示(607)包括获取涉及关于对接收到的响应的确认的回合与关于请求响应的回合之比的指示(611)。

3.如权利要求1所述的计算机实现的方法(603)，其特征在于，获取所述应用程序相对于所述一个或多个任务的性能的指示(607)包括获取涉及关于请求接收到的响应的回合与其中对响应的请求跨所述信息出现的任务实例之比的指示(613)。

4.如权利要求1所述的计算机实现的方法(603)，其特征在于，获取所述应用程序相对于所述一个或多个任务的性能的指示(607)包括获取涉及关于确认接收到的响应的回合与基于该接收到的响应而分配的值之比的指示(615)。

5.如权利要求1所述的计算机实现的方法(603)，其特征在于，获取所述应用程序相对于所述一个或多个任务的性能的指示(607)包括获取涉及基于用户请求的用户重复回合的指示(617)。

6.如权利要求1所述的计算机实现的方法(603)，其特征在于，获取所述应用程序相对于所述一个或多个任务的性能的指示(607)包括以下的两个或多个：

获取涉及关于对接收到的响应的的确认的回合与关于请求响应的回合之比的指示(611)；

获取涉及关于请求接收到的响应的回合与其中对该响应的请求跨所述信息出现的任务实例之比的指示(613)；

获取涉及关于确认接收到的响应的回合与基于接收到的响应而分配的值之比的指示(615)；

获取涉及基于用户请求的用户重复回合的指示(617)。

7.一种分析用户和具有对话回合的交互式应用程序之间的对话的计算机实现的方法(619)，其中回合包括来自系统的提示以及从所述用户接收的响应，所述方法包括：

接收指示启用语音的应用程序中所述系统和至少一个用户之间的对话回合的信息(621)，所述回合与所述应用程序的一个或多个任务有关；以及

获取所述应用程序中造成混乱的提示的指示(623)。

8.如权利要求7所述的计算机实现的方法(619)，其特征在于，获取所述应用程序中造成混乱的提示的指示(623)包括获取在所述提示之后用户无声的次数的指示。

9.如权利要求7所述的计算机实现的方法(619)，其特征在于，获取所述应用程序中造成混乱的提示的指示(623)包括获取在所述提示之后用户请求协助的次数的指示。

10.如权利要求7所述的计算机实现的方法(619)，其特征在于，获取所述应用程序中造成混乱的提示的指示(623)包括获取用户请求所述系统重复所述提示的次数的指示。

11.如权利要求7所述的计算机实现的方法(619)，其特征在于，获取所述应用程序中造成混乱的提示的指示(623)包括获取识别出的对所述提示的响应被取消的次数的指示。

12.如权利要求7所述的计算机实现的方法(619)，其特征在于，获取所述应用程序中造成混乱的提示的指示(623)包括获取响应等待时间的指示。

13.如权利要求7所述的计算机实现的方法(619)，其特征在于，获取所述应用程序中造成混乱的提示的指示(623)包括以下的两个或多个：

获取在所述提示之后用户无声的次数的指示；

获取在所述提示之后用户请求协助的次数的指示；

获取用户请求所述系统重复所述提示的次数的指示；

获取识别出的对所述提示的响应被取消的次数的指示；

获取响应等待时间的指示。

14.一种分析用户与具有对话回合的交互式应用程序之间的对话的计算机实现的方法(631)，其中回合包括来自系统的提示以及从所述用户接收的响应，所述方法包括：

接收指示启用语音的应用程序中所述系统和至少一个用户之间的对话回合的信息(629)，所述回合与所述应用程序的一个或多个任务有关；以及

获取所述对话中造成用户放弃任务的问题的源的指示(635-647)。

15.如权利要求14所述的计算机实现的方法(631)，其特征在于，获取所述对话中造成用户放弃任务的问题的源的指示包括定位指示对话回合和/或任务进入和/或任务完成的状态的顺序列表中的放弃点(635)。

16.如权利要求15所述的计算机实现的方法(631)，其特征在于，任务完成包括对应的成功指示，并且其中获取所述对话中造成用户放弃任务的问题的源的指示包括从所述放弃点开始通过所述顺序列表反向跟踪(637)，直至遇到带有成功指示的任务完成(639)，其中所述问题的源的指示包括紧接着的下一回合。

17.如权利要求15所述的计算机实现的方法(631)，其特征在于，识别出的响应与所述状态的顺序列表相关，并且其中获取所述对话中造成用户放弃任务的问题的源的指示包括从所述放弃点开始通过所述顺序列表反向跟踪，(637)直至用户接受识别出的响应，或期间识别出的响应获得确认状态的回合(641)，其中所述问题的源的指示包括紧接着的下一回合。

18.如权利要求15所述的计算机实现的方法(631)，其特征在于，识别出的响应被记录并且与所述状态的顺序列表相关，并且其中获取所述对话中造成用户放弃任务的问题的源的指示包括从所述放弃点开始通过所述顺序列表反向跟踪(637)，直至一回合拒绝或改正记录的识别响应，或期间对识别响应的定位导致“空”状态的回合，或其中已记录的识别响应改变其值的回合(643)，其中所述问题的源的指示包括其中响应于请求回合接收到相应的已记录的识别响应的最接近的前一回合。

19.如权利要求15所述的计算机实现的方法(631)，其特征在于，识别出的响应被记录并且与所述状态的顺序列表相关，并且其中获取所述对话中造成用户放弃任务的问题的源的指示包括从所述放弃点开始通过所述顺序列表反向跟踪(637)，直至所述用户提供追溯用户步骤的命令(645)，接着查明所述命令之后的回合的指示，其中所述问题的源的指示包括对应于所述回合的所述指示的、并且在追溯用户步骤的命令之前的回合，作为所述问题的源。

20.如权利要求15所述的计算机实现的方法(631)，其特征在于，获取所述对话中造成用户放弃任务的问题的源的指示包括从所述放弃点开始通过所述顺序列表反向跟踪(637)，直至达到所述会话的开始处(647)，其中认为第一信息请求回合是所述问题的源。