总结
2.1.1 Dialog Task agents
Two categories
of dialog agents
populate the task tree
: fundamental dialog agents and dialog agencies.
两种
对话agents
填充了任务树
:基础对话agents和对话agencies。
The fundamental dialog agents appear as leaf nodes
(i.e. Welcome
, AskRegistered
) and represent atomic dialog actions
.
基础对话代理以
叶节点
的形式出现(即Welcome
、AskRegistered
),并代表原子对话动作
。
RavenClaw uses four types
of fundamental agents:
Inform - sends an output
(e.g. Welcome
),
Request - requests information (e.g. AskRegistered
),
Expect - expects information, but without requesting it
(e.g. Projector
)
and
DomainOperation - performs other domain-related operations
(e.g. GetResults
).
RavenClaw使用
四种类型
的基础代理:
Inform - 发送输出
(例如Welcome
),
Request - 请求信息(例如AskRegistered
),
Expect - 期待信息,但不请求
(例如Projector
),
以及
DomainOperation - 执行其他与域相关的操作
(例如GetResults
)。
The non-terminal nodes in the tree are dialog agencies (e.g. Login
, GetQuery
); agencies
control the execution of their subsumed agents, capturing the higher level temporal and logical structure
of the dialog task
.
树中的
非终端节点
是对话机构(例如Login
、GetQuery
);agencies
控制其包含agents的执行,捕获对话任务
的更高层次的时间和逻辑结构
。
Each agent implements an Execute routine, and holds a set of preconditions and triggers, and a completion criterion
.
每个代理都实现了一个执行例程,并持有一组前提条件和触发器,以及
一个完成标准
。
The Execute routine is specific to the agent type
.
执行例程特定于
代理类型
。
For example,
Inform-type agents simply generate an output
when executed,
while Request-type agents also trigger an Input Phase
(see subsection 2.2.2) to collect the user’s response
.
例如,
Inform类型的代理在执行时简单地生成输出
,
而Request类型的代理还会触发输入阶段
(参见第2.2.2小节)以收集用户的响应
。
For agencies
, the Execute routine
is in charge of planning the order of the execution of the sub-agents.
对于
机构
,执行例程
负责规划子代理的执行顺序。
This sub-task planning problem
is currently resolved by combining a set of simple policies
(i.e. left-to-right traversal
), with the preconditions
that each agent holds.
这个子任务规划问题
目前通过结合一组简单策略
(即从左到右遍历
)和每个代理持有的前提条件
来解决。
The system is however open to more sophisticated policies
, and even learning at the dialog task level
(e.g. by casting
the sub-agent planning problem as a Markov Decision Process
[^4]).
然而,该系统对
更复杂的策略
开放,甚至可以在对话任务级别
进行学习(例如,通过将
子代理规划问题视为
马尔可夫决策过程[^4]
)。
[4]
Litman, D. J.,
Kearns, M. S.,
Singh, S.,
以及
Walker, M. A.,
“对话管理的自动优化”,
收录于COLING 2000会议论文集。
解释
关于Expect类型的对话代理,我们可以结合其定义和特性来举例说明。
Expect类型的对话代理示例
假设在一个会议室预订系统中,有一个Expect类型的对话代理被命名为Projector
。
这个代理的目的是期待用户可能提到的关于投影仪的需求,但不会在对话中显式询问用户是否需要投影仪。
场景描述
用户通过语音与系统进行交互,以预订一个会议室。
在对话过程中,用户可能会提到他们需要在会议中使用投影仪,但这并不是系统必须询问的信息,因为有些会议可能不需要投影仪。
然而,如果用户提到了投影仪
,系统应该能够识别并作出相应的处理。
Expect代理的作用
-
期待信息:当
Projector
代理处于激活状态时,它会期待从用户的输入中捕获到与投影仪相关的信息。这种期待是隐式的,即系统不会主动询问用户是否需要投影仪。 -
处理信息:如果用户在对话中提到了投影仪(例如,“我们还需要一个投影仪”),
Projector
代理将能够识别这一信息,并触发相应的处理机制。- 这可能包括记录用户的需求、调整会议室的配置(如果系统具有这样的能力)或向用户提供关于投影仪使用的进一步信息。
-
不干扰对话流程:由于
Projector
代理不会主动请求信息,因此它不会打断对话的自然流程。- 这允许对话更加流畅地进行,同时仍然能够捕获用户可能提到的与投影仪相关的需求。
与其他代理的对比
与Request类型的对话代理相比,Expect类型的代理(如Projector
)在对话中更加被动。
Request类型的代理会主动向用户请求信息(例如,“您需要投影仪吗?”),
而Expect类型的代理则只是静静地等待并准备处理可能出现的相关信息。
这种差异使得Expect类型的代理在某些情况下更加合适,因为它们允许对话在不受干扰的情况下自然发展,
同时仍然能够捕获和处理重要的信息。
然而,这也意味着Expect类型的代理可能不如Request类型的代理那样能够确保所有必要的信息都被明确获取。
因此,在实际应用中,开发人员需要根据对话的具体需求和上下文来选择合适的代理类型。