作者简介:顾海军(1970-),男,副教授,博士.研究方向:物联网,智能硬件云服务平台体系结构及关键技术.E-mail:ghyciom@163.com
提出了基于行为语言的智能交互代理,利用关键词匹配技术获取用户需求关键信息,触发cplus2asp系统根据行为语言描述的知识及规则进行推理得出调控策略,实现智能人机交互。该智能交互代理的实现方法解决了传统智能交互引擎交互接口不友好、交互过程复杂等问题的局限性。实验结果验证了该方法的有效性。
An intelligent interaction agent based on action language is proposed. The keyword matching technology is used to obtain the key information of the users' requirement, and the spus2asp system is triggered to drive the regulation strategy based on the knowledge and rules described in the action language to achieve intelligent human-computer interaction. After that, it uses its reasoning module to generate a sequence of actions for home services and convert them into equipment control instructions to eventually achieve intelligent management of the home environment.
智能家居系统的研究目标是为用户提供一个方便、快捷和舒适的家居环境, 但现阶段的智能家居系统在满足用户变化的个性化需求时明显力不从心, 人机交互过程实现方式单一, 只能通过固定的按键实现有限的功能, 用户体验差。所以解决人机交互过程中的不确定性成为近年来国内外研究的热点。随着人机交互技术的发展, 各大互联网公司相继推出具备自己特色的语音交互产品, 如国外的有三星公司的语音助手S-Voice、Google Now、亚马逊的Echo音箱以及微软的Cortana等, 国内的有科大讯飞的万能遥控器、微信语音、基于手势识别的人机交互技术[1]以及搜狗发布的语音交互引擎“ 知音” 等。Chen等[2]提出集成NLP和ASP的自动化代理, 应用在服务机器人人机交互过程中。Khandelwal等[3]提出构建BWIBots(Building-wide intelligence robots)平台, 旨在通过自然语言对话系统实现与人类的直接交互。使机器人可以有意识、有情感的和人类交互, 并在一段时间内收集环境信息, 学习人类居住环境的动态空间, 最终完成用户任务。
为解决来自人机交互的不确定性, 提升家居控制的智能性, 本文提出在智能家居系统中构建一个智能交互代理, 首先利用语音识别技术和关键词匹配技术获取用户需求的关键信息, 然后匹配成功的有效信息触发行为语言BC编写的推理规则求解出满足用户需求的设备调控策略, 实现家居设备的智能化管理。本文提出的智能交互代理除了可以融合环境上下文知识外, 还可融合多个用户的请求知识以及常识知识进行智能规划, 不再局限于为单个用户服务。在实际应用过程中, 只需通过一个智能交互代理即可享受居住环境中智能联网设备的自主化服务, 提升了用户体验。
本文提出的交互代理采取的措施为:
(1)首先, 要为人机交互Web平台提供合理的语音接口, 语音识别就是让机器通过识别和理解过程把语音信号转变为相应的文本或命令[4]。语音识别技术主要包括特征提取技术、模式匹配准则及模型训练技术3个方面。涉及的技术要独立开发比较困难, 所以这里通过Java调用第三方的语音云SDK。
(2)实现人机对话后, 将获取的用户信息与智能交互代理构建的知识库进行关键信息匹配, 当匹配成功后, 触发推理模块; 当匹配不成功时, 再次进行人机交互, 直至匹配成功为止[5]。
(3)进行规划推理, 本文使用BC语言来搭建推理框架。BC语言是面向任务规划的高级语言, 适用于规划推理, 通过调用cplus2asp系统进行求解[6]。匹配成功的用户信息触发cplus2asp系统调用BC语言编写的推理规则, 求解出的回答集即为需要执行的行为规划, 最后转换为控制命令对底层设备进行管理。
本文实现智能性的规划语言为行为语言BC, 行为语言BC是一种高级逻辑设计语言, 融合了行为语言B与行为语言BC的优秀性质[7, 8, 9], 具有较强的表达能力, 优势主要有:
(1)类似于自然语言, 程序编写没有固定顺序, 可以随意地增减语句而不会影响整体程序的执行, 具有很高的可扩展性。例如, 当用户关于温度控制的偏好发生变化时, 只需修改相关的问题描述, 而不必大篇幅的修改程序代码就能得到需要的结果。
(2)利用惯性律解决框架问题, 例如, 智能交互代理打开卧室内的空调, 但其他房间的空调并没有被执行开的动作。
(3)利用可废止推理和递归定义解决歧义问题。当一个病人与健康的人共处一室, 智能交互代理优先考虑适合病人的温度, 这间接地改变了那个健康人的优先权。
(4)可进行域分层的规划方法, 有效提高求解效率, 提升用户体验[8]。
BC语言语法表达形式如下:
A0 if A1, …, Am ifcons
ifcons为if consistent的缩写, 其中每个Ai均为原子。形如f=v的表达式被称为原子, f为变式逻辑符号, v为其值域中的元素, 由谓词符号后跟一串常量或变量的列表组成, 如equipment(aircondition, window)。不严格地说, 静态律表达的是对于每个状态S, 如果S满足A1, …, Am, 并且
a cause A0 if A1, …, Am ifcons Am+1, …, An (动态律)
其中, A0为包含一个普通变式常元的原子, A1, …, Am中的每个Ai均为原子或动作逻辑常量,
本文提出的智能交互代理以温控情景模式为背景进行举例说明, 在某个家庭的客厅内, 有空调和可调节的窗户两种改变室内温度的设备, 在用户不同的需求条件下, 可以选择开空调进行人工控温, 或者调控窗户进行自然控温。智能家居系统的智能性归根结底是家居设备的底层行动控制与顶层规划控制间的集成挑战, 尤其是来自人机交互的不确定性, 如图1所示。家居设备的底层行动控制包括设备的开、关、调高和调低等基本动作。顶层规划控制是从用户需求的初始状态出发, 求解出达到该目标条件的动作序列。
图1中的箭头表示智能家居系统温度控制中的数据流, 标识各模块之间的通信。各模块的功能如下。
(1)用户接口模块:主要用来输入用户需求信息和输出反馈信息。用户用自然语言的方式在GUI界面输入对环境调控的需求, 然后通过关键词索引技术与本文提出的知识框架进行关键信息匹配, 当匹配成功时调用推理模块求解出满足用户需求的调控策略, 通过文本或语音的形式反馈给用户; 当匹配不成功时, 通过交互代理的引导问询, 直到匹配成功为止[10, 11, 12]。
(2)环境监测模块:主要用来获取环境参数信息。环境中的无线传感设备实时监测环境信息, 因为环境参数信息是动态变化的, 所以传感设备需每隔几秒将监测到的数据经过信息处理转换为推理机可接受的BC语言表征的符号形式。
(3)任务规划模块:主要是基于知识进行推理。将智能家居系统背景知识和常识知识归纳在本文提出的知识框架下, 当用户需求知识作为查询文件触发推理引擎时, 调用求解系统cplus2asp根据常识知识编写的推理规则进行求解, 得出满足用户需求的可行的调控策略。
(4)设备调控模块:主要对设备进行智能化管理。将任务规划模块求得的调控策略转换为设备控制指令, 为用户提供舒适的家居环境。
无线传感模块和设备驱动模块利用现有的成熟技术提供一个技术支撑, 而用户接口模块和推理模块则是智能家居系统产业链的主要价值所在。本文将对用户接口模块和推理模块的技术实现进行描述。
智能交互代理采用行为语言进行设计, 行为语言BC是一种基于多值语义的高级逻辑设计语言, 表征方式简单易懂。用BC程序对智能家居系统的背景知识、常识知识和用户需求知识进行知识表征。智能交互代理中的推理模块提取设备的基本行为进行知识表征, 当用户用自然语言表达出自己的主观需求后, 将用户需求信息与智能交互代理的知识库进行关键信息匹配。当匹配成功时, 调用cplus2asp求解出调控策略; 当匹配不成功时, 再次进行问询, 直至成功获取结果为止。下面将以温控场景模式为例, 对BC语言编写的推理规则进行说明。BC程序的构成如图2表示。
用行为语言对智能家居系统下的背景知识和常识知识进行问题域描述时, 都可以归纳在知识框架(类, 对象, 动作, 状态流)下。
3.1.1 类和对象
类用来描述问题的分类, 而对象则指每一类中包含有不同对象, 本文提出的温控情景模式中的类和对象主要包括:
设备类d:用d声明智能家居环境中的设备, 在温度控制情景模式中用到的设备有窗户(w)、空调(a)。
温度类tem:用tem声明家居环境中的温度值, 如无线传感设备采集的室内外的温度值。
对象类os:在温控模式的规则编写过程中, 为了提高程序编写效率, 将涉及温度表征时的参数, 如室内in, 室外out, 目标tg以及中间过渡量inner都归纳在对象类os中。
状态类s:用s声明设备的状态, 如家居设备常见的开和关状态, 用s=0表征设备状态为关着的, 用s=1表征设备是开着的。
3.1.2 逻辑常量符号
在家居设备的调控过程中, 需要进行一些动作, 如打开设备或者关闭设备, 而设备开启动作的执行将导致设备从“ 关闭” 状态转移为“ 打开” 状态, BC语言用逻辑常量符号来表征动作的执行以及所引发的状态流的转移。温控模式中涉及到的逻辑常量符号如下。
o(d)/c(d):设备调控过程中, 最基本的设备打开动作用o(d)表征, 关闭设备动作用c(d)表征, 其中设备类d表征的对象有w(窗户), a(空调)等。
tem(os):用来表征某一对象的温度, 如tem(in)表征室内温度。
s(d):表征设备d的状态, 如s(d)=0表征设备是关闭的; s(d)=1表征设备是开着的。
mode:在家居设备的调控过程中, 有可能对家居环境中的多个设备进行管控, 为表征方便, 将mode取不同数值时对应不同设备的调控, 如mode=0表征对空调的管控; mode=1表征对窗户的管控。
在温控模式的规则编写过程中, 变化的量用变量来表征, 如变化的温度值用T、T1、T2来表征。
程序主体表征了行为的执行条件、执行效果和约束规则, 是实现问题域推理规则的核心内容。当用户需求发生改变时, 只需添加或删除用户需求相关的规则, 调用程序主体中的推理规则即可实现逻辑推理, 而无需修改程序主体中基本动作的规则表征。温控情景模式中涉及到的基本行为的规则表征如下:
nonexecutable o(w) if tem(tg)==tem(in).
% tem(tg)表示目标温度, tem(in)表示室内温度
nonexecutable o(w) if tem(in)==tem(out).
%tem(out)表示室外温度
nonexecutable o(w) if s(w)=1.
% s(w)=1表征窗户是开着的
nonexecutable o(w) if mode=0.
% mode=0表征开空调模式
o(w) if tem(out)< T1 & tem(in)> T1 & tem(tg)=T1 & mode=1.
% mode=1表征开窗模式
o(w) if tem(out)> T1 & tem(in)< T1 & tem(tg)=T1 & mode=1.
o(w) if tem(tg)< T1 & tem(in)> T1 & tem(out)=T1 & mode=1.
o(w) if tem(tg)> T1 & tem(in)< T1 & tem(out)=T1 & mode=1.
o(w) causes s(w)=1.
o(w) causes tem(in)=T1 if tem(inner)=T1.
tem(inner)=T1 if tem(in)< T1 & tem(out)> T1 & tem(tg)=T1 & mode=1.
tem(inner)=T1 if tem(in)> T1 & tem(out)< T1 & tem(tg)=T1 & mode=1.
tem(inner)=T2 if tem(in)< T1 & tem(out)< T1 & tem(tg)=T1 & tem(out)=T2 & mode=1.
tem(inner)=T2 if tem(in)> T1 & tem(out)> T1 & tem(tg)=T1 & tem(out)=T2 & mode=1.
c(w) if tem(in)==tem(inner) & s(w)=1 & mode=1.
c(w) causes s(w)=0.
% s(w)=0表征窗户是关着的
nonexecutable c(w) if s(w)=0.
nonexecutable c(w) & o(w).
o(a) if tem(in)==tem(inner) & s(w)=0 & mode=1.
o(a) if tem(in)=tem(tg) & mode=0.
o(a) causes tem(in)=T1 if tem(tg)=T1.
o(a) causes s(a)=1.
% s(a)=1表征空调是开着的
nonexecutable o(a) if tem(in)==tem(tg) & mode=0.
nonexecutable o(a) if s(a)=1.
nonexecutable o(a) if s(w)=1.
nonexecutable o(w) & o(a) & c(w).
开和关是家居设备的基本调控动作, 所以可以统一用o(d)表征设备的开启动作, 所以o(d)规则的表征对于具备“ 打开” 行为的设备来说是通用的, 这将大大提高程序的运行效率。而当设备具备除了基本行为之外的行为时, 只需编写相应的规则加入程序主体即可, 而不会影响原有程序的正确运行, 使推理规则具有了普适性。例如, 在温度调控中, 有的用户想节约用电, 在气温不是过高情况下, 会选择开窗进行室内温度调节, 在BC语言中用saving表征用户偏好的这种调控模式, 对应的推理规则表征为:
mode=1 if saving.
% 引入流符号saving表征用户的需求为节能
mode=0 if -saving.
在软件设计过程中, 将设备的基本调控行为的规则表征和用户需求相关的规则表征分别存储在不同的运行文件.cp中, 使设备的调控规则不受用户变化的需求规则的影响, 运行文件之间通过语句“ :-include 'xx.cp'” 实现互联。
当符号声明和程序主体表征完成后, 只需调用相应的查询语句即可触发推理规则进行问题求解。行为查询中主要定义了问题的初始条件和目标状态。其具体的表征形式如下:
:-query
label::< label> ;
maxstep::< maxstep> ;
< step> :< formula> ;
< step> :< formula> .
其中, query为查询的程序入口, 用< label> 对多个查询进行标识, 如query=< label> 来指定应该执行哪个查询; < maxstep> 用来表征用户指定的最大步, 比如温度控制中, 执行多次的设备调控行为, 将影响用户体验; < step> :< formula> 表明在此步的状态, 一般用来指定初始状态和目标状态。
在温控情景模式中, 推理模块的查询文件接收来自传感设备采集的室内外温度和用户输入的目标温度和偏好, 这时的行为查询语句表征为:
:- query
label :: 2;
maxstep :: 1..100;
0:tem(in)=10,
tem(out)=13,
tem(tg)=16,
saving;
maxstep:tem(in)=tem(tg),
s(w)=0.
经求解系统cplus2asp的推理结果如图3所示。
如图3所示, 在温控情景模式中, 当用户倾向于节约用电时, 推理引擎根据推理规则求解出满足用户需求的设备调控策略:先开窗, 进行换气, 然后关上窗户, 打开空调进行人工调控。
以上是温控模式中的一次编程实现, 在智能家居系统中, 只需用BC语言对家居设备的基本行为进行表征, 即可实现对家居设备的智能化管理。
本文提出基于行为语言的智能交互代理, 人机交互过程中, 当用户用自然语言表达出自己的主观需求后, 通过语音识别接口转换为文本, 进而与智能交互代理的知识库进行关键信息匹配, 当匹配成功时, 调用cplus2asp求解出调控策略; 当匹配不成功时, 再次进行问询, 直至成功获取结果为止。最后, 通过设备驱动模块实现家居设备的智能化管理。
本文提出的智能交互代理界面基于MVC(Model-view-controller)模式的动态Web应用进行开发, 调用第三方语音接口— — 科大讯飞语音识别接口实现语音交互, 在人机交互界面点击一个按钮, 弹出语音识别窗口, 当说完后会把自动识别的文字结果显示在下方的显示栏中。
当用户需求通过语音识别接口转换为文本信息后, 调用斯坦福大学研发的开源的语法解析器软件Stanford parser进行语法分析。在地址http://nlp.standford.edu/software/lex-parser.shtml#Download下载编译的jar包、源码、javadoc等, 进行解压缩后, 将2个jar包(Stanford-parser-xxx-models.jar和Stanford-parser.jar)加入到java build path中就可以对中文进行解析了。通过语音识别的文本信息调用Stanford parser进行解析, 例如, “ 屋里有点热” 的解析结果如图4所示。
图4中, NN表示“ 屋里” , 为常用名词; AD代表“ 有点” , 为形容词短语; VA代表“ 热” , 为形容词。根据标注的主谓宾的结果, 把上述句子转换为谓词形式, nsubj(热-3, 屋里-1), 即屋里(热)。
本文提出的智能交互代理利用关系数据库进行知识存储。用户话语信息的解析结果“ 屋里(热)” 和推理模块的已建知识库进行匹配, 根据匹配度分为广泛匹配、短语匹配、精确匹配3种匹配模式。
广泛匹配:指关键词的范围很广, 如关键词是“ 热” , 那么当用户说“ 今天好热啊” 、“ 今天屋里有点儿热” 等, 只要用户说的话语里有“ 热” 这个字, 推理机就根据“ 热” 这个关键字进行推理。
短语匹配:指所设置的关键词为一个整体, 不能被拆分。如设置“ 屋里(热)” 这个关键词为短语, 则只有当用户话语的解析结果为“ 屋里(热)” 时才可以进行推理, 而用户说“ 今天好热啊” 时, 语法解析结果为“ 热” , 则无法成功匹配。
精确匹配:就是用户说的内容必须完全等于设置的关键词:A=A 。如已设置的关键词是“ 屋里热” , 那么客户的输入必须是这几个字, 顺序不能错, 字也不能错, 就是完全匹配的精确模式。
当解析后的用户话语与推理模块的已建知识库成功匹配后, 调用求解系统cplus2asp, 并根据BC语言编写的推理规则进行求解规划。由用户话语与已建知识库的匹配度将顶层规划控制分为低级规划、中极规划和高级规划, 规划的分级表征了问题求解过程的复杂度。
在低级规划过程中, 用户需求信息和内建知识库实现精确匹配, 推理引擎可快速求解出结果; 在中级规划过程中, 用户需求信息和内建知识库实现短语匹配, 推理引擎有可能直接处理出结果, 有可能因为知识不完备, 需要通过与用户的问询, 完善实现推理所需的知识, 在中级规划中至多通过一次问询即可实现推理。在高级规划过程中, 用户需求信息和内建知识库实现广泛匹配, 用户需求信息不完备, 推理引擎无法进行推理, 需通过人机交互模块进行2、3次问询, 进而调用推理模块实现推理。
图5是以智能交互代理处理用户输入“ 屋里有点儿热” 过程为例说明智能交互代理的内部工作原理。图5展示了用户与智能交互代理之间的交互工作流, 虚线框显示了智能交互代理处理用户命令的过程。在例子中, 用户通过语音交互接口输入自然语言“ 屋里有点儿热” , 经过调用语法解析器解析为谓词形式屋里(热), 谓词形式的用户需求信息与推理模块的内建知识库进行关键信息匹配, 通过关键词匹配技术实现短语匹配, 继而触发推理模块的中级规划, 由于用户输入的需求信息知识不完备, 这时智能交互代理通过语音交互模块进行知识问询, 反馈给用户“ 请问目标温度是多少” 的指令, 然后用户通过再次输入信息完善用户需求知识, 直到推理引擎求解出满足用户需求的调控策略。
在温度控制的典型场景中, 用户用自然语言的方式表达出自己的主观需求, 通过智能交互代理推理出满足用户需求的设备调控策略。人机交互过程的信息反馈结果如图6所示。
图6展示了实验成功的人机对话交互过程, 第一组对话过程实现精确匹配, 通过低级规划快速推理出满足用户需求的调控策略。第二组过程实现短语匹配, 需经过一次问询才能进行推理进行中级规划。第三组过程实现广泛匹配匹配, 需经过2、3次问询才能进行推理进行高级规划。实验结果表明, 本文提出的智能交互代理是可行的。
为解决来自人机交互的不确定性, 给用户提供一个舒适、便捷的家居环境, 本文提出面向家居服务的智能交互代理。该代理采用行为语言BC语言进行设计, 行为语言BC是一种基于多值语义的高级逻辑设计语言。系统通过构建家居服务问题域知识库, 融合智能家居系统的背景知识、常识知识和用户需求知识进行自主决策。它通过基于Web的GUI界面接收用户的自然语言请求, 进而调用语音识别模块完成音频和文本之间的转换, 文本通过语法解析转换为谓词形式, 然后与已建知识库进行关键信息匹配。当匹配成功时, 即可调用cplus2asp求解出调控策略; 当匹配不成功时, 再次进行问询, 直至成功获取结果为止。最后通过设备驱动模块实现家居设备的智能化管理。在未来的研究工作中, 将继续致力于智能家居系统中的人机交互问题的研究, 不断对其进行优化与创新。
The authors have declared that no competing interests exist.
[1] |
|
[2] |
|
[3] |
|
[4] |
|
[5] |
|
[6] |
|
[7] |
|
[8] |
|
[9] |
|
[10] |
|
[11] |
|
[12] |
|