桥接UI设计与聊天机器人交互：将基于表单的原则应用于对话代理

Sanjay Krishna Anbalagan${}^1$, Xinrui Nei${}^2$, Umesh Mohan${}^3$, Vijay Kumar Kanamarlapudi${}^4$, Anughna Kommalapati${}^5$ 和 Xiaodan Zhao${}^6$
${}^{1345}$ Amazon Web Services, Dallas, USA
${}^{26}$ Amazon Web Services, Seattle, USA

摘要

特定领域聊天机器人应用通常涉及多步骤交互，例如优化搜索筛选条件、选择多个项目或执行比较操作。传统图形用户界面（GUI）通过提供明确的“提交”（提交数据）和“重置”（丢弃数据）操作来处理这些工作流程，使后端系统能够无歧义地跟踪用户的意图。相比之下，对话代理依赖于微妙的语言提示，这可能导致混淆和上下文管理不完整。本文提出将这些GUI启发的隐喻——确认（类似提交）和上下文切换（类似重置）建模为大型语言模型（LLM）提示中的显式任务。通过将用户的确认、重置动作和链式思维（CoT）推理作为结构化会话数据捕获，我们保持了清晰度，减少了用户困惑，并使特定领域聊天机器人的交互与后端逻辑对齐。我们在酒店预订和客户管理场景中展示了我们的方法，突出了在多轮任务连贯性、用户满意度和效率方面的改进。

关键词：GUI启发的CoT，提交|重置隐喻，特定领域聊天机器人

1 引言

Q1：为什么将图形用户界面（GUI）交互与聊天机器人进行比较？

A1：传统的GUI通常提供明确的提交（提交数据）和重置（丢弃数据）按钮。这些交互是明确的，允许后端清楚地跟踪用户的意图。相比之下，聊天机器人严重依赖自然语言提示，这些提示可能模糊或定义不足，导致对用户意图和上下文的混淆 [1]。

Q2：特定领域聊天机器人交互面临哪些挑战？

A2：特定领域的应用程序，如酒店预订系统、客户管理系统或库存系统，通常需要多步骤的用户交互。聊天机器人必须跟踪用户的选择（例如，搜索酒店、确认客户、优化筛选条件）。没有明确的“提交”或“重置”操作时，当用户的语言改变上下文时可能会产生混淆。例如，用户可能突然从讨论客户A切换到客户B，而没有明确的提示，使得系统不确定应该提交或丢弃哪些数据 [2]。

Q3：大型语言模型（LLMs）如何发挥作用？

A3：LLMs可以根据提示生成文本（包括结构化数据，如XML标签）。在传统的编程工作流程中，开发人员可以提示LLM生成特定变量或标签，解析这些输出，然后将其反馈到应用程序的逻辑中 [3]。这在自然语言的灵活性和显式UI操作的清晰度之间架起了一座桥梁。

Q4：本文提出了什么解决方案？

A4：我们建议将GUI启发的隐喻（如提交和重置）建模为LLM提示中的显式任务。通过将用户确认（类似提交）或上下文切换（类似重置）作为结构化会话数据捕获，系统可以清楚地知道用户是否希望继续使用相同的上下文或切换到新的上下文。我们还采用链式思维（CoT）推理（见Q6）用于多步骤任务，使LLM能够澄清用户输入中的模糊细节，并更透明地指导后端。

Q5：这种方法如何使多轮聊天机器人交互受益？

A5：通过使“确认”和“重置”步骤显式（并结合通过CoT的逐步推理），该方法：

• 在多轮交互中保持上下文的清晰。
• • 减少用户混淆和错误操作的可能性。
• • 使特定领域聊天机器人的交互与后端逻辑一致。
• • 提高在酒店预订或客户管理等任务中的连贯性、用户满意度和效率。

Q6：链式思维（CoT）是如何整合到您的提示中的？

A6：我们指示LLM生成结构化的中间步骤，有效地揭示其关于用户上下文变化或表单式操作（例如，“提交”与“重置”意图）的内部推理。这些步骤包含在LLM的输出中（可能是JSON/XML段或单独的解释性文本），但主要用于内部清晰和调试。通过解析此CoT输出，后端可以遵循一个透明的、逐步的推理过程：根据用户的陈述决定是否提交某些数据、重置字段或切换上下文。虽然CoT可以对最终用户隐藏，但它允许开发人员更好地理解LLM是如何得出某些操作的。

2 相关工作

对话接口已被广泛研究用于客户服务、信息检索和个人助理等任务 [1,2]。许多先前的工作集中在自然对话流或对话状态跟踪 [4] 上，旨在维持用户目标的信念状态。然而，这些方法通常不会显式处理提交（提交）或丢弃（重置）作为独立隐喻——许多方法依赖于通用的用户意图分类，这可能会错过部分上下文重置或确认的细微差别，而这些对于特定领域应用至关重要。
最近大型语言模型的进展使系统能够生成可在编程上下文中解析的结构化输出 [3]。将LLM-based文本生成与传统应用流程统一的努力经常强调提示设计 [5]，特别是如何设计指令，使LLM的输出既语义正确又具有程序用途。我们的工作建立在这条研究线的基础上，通过引入模仿GUI操作的任务型提示，增强链式思维推理，从而减少多轮对话中的歧义并保持清晰度。

3 提出的方法

3.1 将UI操作转化为提示任务

关键见解：在典型的GUI中，提交提交用户输入的数据，而重置则丢弃它，返回到默认或初始状态。我们在聊天机器人环境中复制这一想法，通过设计专门的提示来显式标记用户意图。例如，当用户似乎确认特定客户时，我们将此视为类似提交的操作。相反，当用户想要放弃当前客户或切换到新客户时，我们将其视为类似重置的操作。

3.2 用于LLMs的任务型提示（带CoT）

LLMs可以通过提示生成结构化数据（例如，XML或JSON）表示这些操作。我们的提示工程还结合了链式思维指令，允许LLM阐明中间推理步骤（主要用于内部使用）。通过解析模型的输出，我们将结果值（例如，isCustomerConfirmed）和CoT文本段落馈送到后端。这确保了系统能够可靠地提交或重置用户上下文，并完全透明地了解LLM的推理过程。

核心优势

1. 明确的上下文管理：每个提示都明确请求一个动作标签（例如，确认客户上下文的是或否），并包含解决歧义的中间推理步骤。
2. 2. 无缝集成：开发人员可以解析LLM的输出标签和链式思维文本段落（例如，使用简单的XML解析器或正则表达式），并将它们集成到现有的应用逻辑中。
3. 3. 交互一致性：可以引入多个任务（例如，IsHotelSelectionConfirmed, IsBookingReset），每个任务控制对话状态的一部分，由CoT指导以澄清每个决策是如何达成的。

4 实现

4.1 示例：客户确认任务

以下是一个说明性的TypeScript代码片段，展示我们如何构建客户确认提示。目标是检测用户是否想继续使用当前客户或切换到新客户。我们还提供“链式思维”指令，以便LLM的输出包含其推理的痕迹：

人类：你是一个客户搜索机器人，你的任务是根据和确定用户查询是指搜索客户还是有关当前客户的详细信息。请遵循以下指南：

1. 如果出现以下情况，请用$<$ isCustomerConfirmed $>$ no $</$ isCustomerConfirmed $>$响应：

• 用户查询提及或暗示不同客户的名称。
• • 用户查询涉及澄清或纠正当前客户。
• • 用户查询涉及地理或行业特定优化而未作解释。
• • 用户查询使用诸如“那个”、“我的意思是”或“我正在寻找”之类的短语，表明上下文切换。

2. 如果出现以下情况，请用$<$ isCustomerConfirmed $>$ yes $</$ isCustomerConfirmed $>$响应：

• 用户查询询问当前客户的详细信息（服务消耗、定价等）。
• • 用户查询不涉及澄清或纠正当前客户名称。
• • 用户查询涉及比较当前客户与其他客户之间的详细信息，但保留当前客户上下文。

3. 在…标签中简要解释你的推理。
4. $<$ examples $>$
5. $<$ example $>$
6. query: “the one in china”
7. current customer name: $ABC$ Company
8. user query history list: [“Is ABCCompany a customer”]
9. $<$ isCustomerConfirmed $>$ no $</$ isCustomerConfirmed $>$
   10.User mentions ‘the one in China’, so likely switching context.
   $</$ example $>$
   $<$ example $>$
   query: “recent news”
   current customer name: $ABC$ Company
   user query history list: [“Is ABCCompany a customer”]
   $<$ isCustomerConfirmed $>$ yes $</$ isCustomerConfirmed $>$
   User is asking for details on ABCCompany with no mention of a new entity.
   $</$ example $>$
   $</$ examples $>$
   以下是用户查询：${userQuestion}
   以下是当前客户名称：${customerName}
   以下是用户查询历史：
   
   ${JSON.stringify(userQueryHistoryList)}
   $</$ userQueryHistory $>$

它是如何工作的：

1. 用户查询：用户的最新输入。
2. 2. 当前客户名称：聊天机器人当前使用的上下文。
3. 3. 用户查询历史：帮助LLM跟踪上下文的先前查询列表。
4. 4. 响应：LLM返回yes或no以及总结推理的…块。虽然后端可以解析链式思维用于日志记录或调试，但最终用户通常只看到总结的结果。
5. 
   图1. 交互流程图。
   主要收获：LLM的显式yes/no标签被解释得类似于用户在图形UI中点击提交或重置。内容提供了每个决策的透明、逐步推理。

5 示例场景

5.1 示例对话

场景：用户正在搜索特定客户

1. 用户：“ABCCompany是客户吗？”

LLM输出：

$<$ isCustomerConfirmed $>no</$ isCustomerConfirmed $>$
$<$ chainOfThought $>$ 用户命名$ABCCompany$，当前没有设置客户上下文，因此我们将其视为新搜索。$</$ chainOfThought $>$

操作：系统搜索“ABCCompany”
2. 用户：“他们的最近新闻是什么？”

LLM输出

$<$ isCustomerConfirmed $>$ yes $</$ isCustomerConfirmed $>$
用户询问“他们”的最近新闻，指的是ABCCompany。上下文仍然是ABCCompany。

操作：系统获取ABCCompany的新闻
3. 用户：“实际上显示XYZCompany的信息？”

LLM输出

$<$ isCustomerConfirmed $>no</$ isCustomerConfirmed $>$
$<$ chainOfThought $>$ 用户只想查看XYZCompany的信息，
丢弃ABCCompany的上下文。‘their’ recent news, referring to ABCCompany. Context remains ABCCompany. $<$ /chainOfThought $>$

操作：系统将上下文重置为XYZCompany

5.2 使用和不使用isCustomerConfirmed（SUBMIT | RESET）的示例对话

不使用标签：

用户：“Delta是客户吗？”
LLM：“Delta Airlines已经是客户两年了。”
用户：“Dental。”
LLM：“Delta Airlines为员工提供牙科计划……”
用户：“不，我的意思是Delta Dental。”
LLM：“……Delta Dental可能是一个独立实体；让我看看……”

推理（不使用）：

没有给出明确的“重置”提示。系统直到用户明确澄清“Delta Dental”为新客户之前，都将“Dental”归入Delta Airlines下。这导致了混淆和额外步骤。

使用标签：

用户：“Delta是客户吗？”
LLM：“是的，Delta Airlines已经是客户两年了。”
用户：“Dental。”
LLM：“您是指将Delta Dental作为新客户，还是指Delta Airlines的牙科计划？”
用户：“我特指Delta Dental。”
LLM：“明白了。让我们谈谈Delta Dental。”

推理（使用）：

因为在立即后续（“Dental”）评估为否，系统意识到用户可能从“Delta Airlines”切换到“Delta Dental”。它会在转换上下文之前提出一个澄清问题以确认意图。这确保了较少的误解和更顺畅的对话流程。

6 讨论与未来工作

6.1 增强多模态交互

尽管我们专注于文本聊天，但同样的方法可以扩展到语音界面或混合交互，其中用户在语音和最小GUI之间切换。每个“动作”仍然需要被识别、跟踪，并且如果开发者需要完全透明，则可以在链式思维中进行解释。

6.2 扩展到其他领域

该方法不仅适用于客户管理，还可推广到任何有多步骤工作流程的领域——旅行预订、预约安排、电子商务购物车。每当确认（提交）与重置（取消）相关，并且需要逐步CoT澄清时，此方法都可以减少歧义。

6.3 局限性和下一步

LLM可靠性：该方法严重依赖LLM持续输出正确的标签和连贯的链式思维。提示设计和测试至关重要。

边缘案例：用户可能使用模糊语言或讽刺，可能导致错误的CoT或误分类。微调和强大的提示工程可以缓解这个问题。

初步测试：在一个有100名用户的试点研究中，我们观察到与基线聊天机器人方法相比，对话错位（例如用户需要重复或纠正上下文）减少了约30%。未来的更大规模测试可以更严格地量化用户满意度和任务完成时间的改善。

7 结论

我们介绍了一种新颖的方法，在特定领域聊天机器人应用中建模确认和上下文切换，通过将GUI隐喻（提交/重置）重新用作LLM提示中的显式任务。通过将这些动作捕获为结构化会话数据——例如$<$ isCustomerConfirmed $>$ yes $</$ isCustomerConfirmed $>$——并结合链式思维推理（内部用于清晰），我们更有效地使对话流程与后端逻辑对齐。我们在客户管理和酒店预订场景中的示例展示了这种机制如何帮助减少用户困惑，保持连贯的上下文，并创建更高效、用户友好的交互范式。

参考文献

1. Radziwill, N., & Benton, M.: “Evaluating Quality of Chatbots and Intelligent Conversational Agents.” Journal of Quality Management, 25(2), 2017.
2. 2. Nuruzzaman, M., et al.: “A Survey on Chatbot Implementation in Customer Service Industry.” International Journal of Management and Applied Science, 2018
3. 3. Williams, J. D., & Zweig, G.: “End-to-End LSTM-Based Dialog Control Optimized with Supervised and Reinforcement Learning.” arXiv preprint, 2016
4. 4. Brown, T., et al.: “Language Models are Few-Shot Learners.” Advances in Neural Information Processing Systems, 2020.
5. 5. Reynolds, L., & McDonell, K.: “Prompt Programming for Large Language Models: Beyond the Few-Shot Paradigm.” arXiv preprint, 2021.
      参考论文：https://arxiv.org/pdf/2507.01862