聊天机器人如何运作：规则、检索、大语言模型、工具与人工接管

聊天机器人的对话可能感觉轻松愉快，直到它失败的那一刻。你询问包裹在哪里。机器人重复了一条通用的配送政策。你提供了订单号。它再次要求提供订单号。三次循环后，那小小的聊天气泡, , 曾承诺便利, , 变成了你与答案之间的一扇锁门。

相反的体验几乎是看不见的。聊天机器人能够识别你想要跟踪订单，捕捉正确的号码，检查当前记录，用一句话解释结果，并在情况特殊时提供人工服务。区别不仅仅在于一个机器人拥有更多的人工智能，而在于一个对话系统拥有更清晰的任务、更好的状态、可靠的工具、更安全的界限，以及一个计划好的恢复方法。

本指南带你深入聊天气泡背后。它解释了主要类型的聊天机器人，跟踪一条消息在真实架构中的流程，并展示了流利的语言只是可靠对话的一部分。

什么是聊天机器人？

聊天机器人是一种通过文本、语音或其他对话渠道与人交换信息的软件。它会解析输入，决定接下来应发生什么，并返回响应或执行操作。这个广义的定义包括支持工具中的固定菜单、收集账户号码的语音流程、搜索文档的知识助手，以及可以起草开放式回复的语言模型系统。

对话是界面，而不是底层技术。两个聊天机器人可能看起来完全相同，但工作方式却完全不同。一个遵循决策树，另一个匹配意图并调用网络钩子，第三个检索文档并请大型语言模型撰写答案。最有用的系统通常结合几种方法。

来自ELIZA六十年的教训

1966年，约瑟夫·韦岑鲍姆出版了 ELIZA，自然语言对话程序。它著名的DOCTOR脚本使用模式和转换将用户语句的部分内容转换为回应。例如，一句“我不高兴”可以被匹配、重排并反映为一个问题。尽管该程序对个人生活几乎没有信息，也没有现代语言模型，这种交流仍可能让人感到被关注。

ELIZA 之所以仍然具有相关性，是因为人们会在社会交往中对语言作出反应。一个及时的问题、一句同情的话语，或一个自信的回答，都可能创造出超出其背后机制的理解印象。现代模型能力更强，但界面仍然容易引发同样的错误：通过其听起来自然的程度来判断系统的知识水平。

因此，一个专业的聊天机器人应该通过正确完成任务、显示其限制以及可恢复的错误来赢得信任。个性可以改善互动，但无法替代获取正确信息或安全流程的能力。

三种主要的聊天机器人架构

当我们将三种架构类型分开时，聊天机器人更容易理解。这些并不是严格的代际划分，每一代都让前一代过时。它们是拥有不同优势的工具。

1. 规则和对话流程

基于规则的聊天机器人遵循预先设计的路径。它可能显示按钮、匹配关键词、填写表单，或者在条件满足时在状态之间移动。逻辑可以是明确的：如果用户想要更改送货日期，收集订单编号，检查包裹是否符合条件，显示可用日期，并请求确认。

当流程狭窄且可接受的操作已知时，规则非常有价值。它们使合规步骤和破坏性操作更容易控制。当人们以意想不到的方式提出请求或偏离设计路径时，其弱点就会显现。一个良好的规则系统需要回退方案、纠正机制和逃生路线，而不仅仅是一个完美的理想路径。

2. 意图匹配和检索

基于意图的系统会估计用户试图做什么，然后提取称为实体或参数的有用细节。“跟踪订单4821”可能映射到追踪订单意图和订单编号参数。谷歌云的 Dialogflow意图文档 将这种模式描述为将输入与训练短语进行比较以找到匹配项。

检索增加了搜索层。系统不仅仅从固定响应中回答，还会查找相关段落、政策条目、帮助文章或记录。检索型聊天机器人可以直接引用已知答案，或者将所选材料传递给生成器。其质量取决于索引内容、查询形成方式、来源是否最新以及系统是否找到了正确的段落。

3. 语言模型、工具和混合系统

大型语言模型可以理解不同的表述方式，并在更广泛的输入范围内生成自然的响应。它可以进行总结、解释、翻译、提出澄清问题，或将结构化工具输出转换为可读语言。有关标记生成和模型限制的更深入解释，请参见 究竟什么是人工智能？。

该模型在实时事实和动作方面仍需要帮助。除非应用程序通过上下文、检索或工具提供相关信息，否则它无法知道订单4821的当前所在位置。它不能仅仅因为可以写出“您的退款已完成”这句话就安全地处理退款。应用程序必须将模型连接到授权服务并验证结果。

这就是为什么许多现代聊天机器人是混合型的原因。规则保护关键的过渡环节。检索提供当前知识。语言模型处理灵活的语言。工具读取或更改外部状态。常规代码验证权限和输出。需要判断或权力的情况由人类处理。

聊天机器人一次交互中会发生的事情

遵循一个简单的信息：“订单4821在哪里？”实际的实现可能会合并或重新命名步骤，但其基本职责仍然可以识别。

1. 接收并规范化输入。渠道可能提供已输入的文本、转录的语音、按钮选择、语言或会话元数据。
2. 确定目标。系统会判断请求是关于追踪、取消、付款、其他主题，还是不支持的事项。
3. 提取所需的详细信息。在此情况下，订单号是4821。如果缺失或不明确，机器人应询问而不是自行编造。
4. 检查会话状态。系统确定已知信息、允许保留的信息以及当前活跃的步骤。
5. 检索知识或调用工具。跟踪服务返回当前状态。聊天机器人不应根据语言模式创建该状态。
6. 撰写并验证响应。应用程序将结果转化为清晰的语言，检查必填字段，并避免暴露内部或个人数据。
7. 回复、恢复或转交。正常结果返回给用户。错误、不支持的情况或需要人工处理的请求则走不同的路径。

Google Cloud 使用“履行（fulfillment）”一词来指会话回合中返回静态响应、调用 Webhook 获取动态信息、设置参数或采取行动的部分。 Dialogflow 履行文档 作出了一个重要区分：理解请求和履行请求是不同的职责。

会话状态不是人类记忆

聊天机器人需要足够的状态信息，以避免每次交互都从头开始。会话状态可能会记录当前任务是包裹追踪，订单号是4821，并且用户已经确认了邮政编码。没有状态信息时，“第二个包裹怎么样？”就没有可用的参考。

该状态是生成的数据，而非人的记忆。一些系统仅保留当前会话。其他系统会存储对话历史、摘要、偏好或账户信息。由于上下文有有限的容量，或者应用程序故意限制发送的内容，模型也可能只接收到长对话的一部分。

用户不应假设聊天机器人在窗口关闭时会忘记，也不应因为它的表述方式而认为它会记住。保留、账户关联、训练使用和删除取决于具体服务。在共享敏感信息之前，请查看该服务的隐私说明，并仅使用完成任务所需的最少信息。

检索增强生成的工作原理

语言模型的参数不是存储经常变化的退货政策的好地方。检索增强生成（通常简称为RAG）通过搜索外部集合以获取相关材料，并在模型生成答案前将选定的段落放入模型的上下文中，从而解决了这个问题。

原始的 检索增强生成论文 将预训练生成器与从索引中检索的显式非参数记忆结合起来。如今，这种广泛的模式出现在许多知识助手中：先搜索，再生成。

一个有用的RAG流程至少有四个可能失败的环节。来源集合可能不完整。文档可能已经过时。检索可能选择到无关的段落。生成器可能误读或夸大收到的信息。引用只有在指向确切的支持来源并且用户可以检查它时才有帮助。

因此，RAG改善了访问当前可检查知识的能力，但不能保证其真实性。应进行端到端评估：正确的来源是否进入了索引，搜索是否找到它，答案是否在证据范围内，以及引用是否支持该主张？

答案和行动需要不同层次的控制

解释退款政策的聊天机器人与执行退款的聊天机器人不同。第二种系统可以改变外部状态。它可能会调用账户服务、日历、支付系统、消息工具或设备控制。这种能力有时被称为代理能力，但实际问题更简单：这个应用程序除了生成文本还能做什么？

安全的操作路径应将重要检查置于模型文本之外：

• 验证用户身份并确认账户或资源属于他们。
• 授权特定操作，而不是给予聊天机器人广泛访问权限。
• 使用常规代码验证工具参数、金额、目的地和允许范围。
• 在不可逆或代价高的操作前要求明确确认。
• 返回经过验证的工具结果，而不是假设操作已成功。
• 记录足够的信息以调查故障，同时不暴露不必要的敏感数据。

该插图展示的是目标架构，而不是对任何特定聊天机器人的承诺。语言模型可以建议调用哪种工具，但周围的应用程序应决定是否允许该调用。更多的自主性会增加权限边界、速率限制、确认、监控和人工审核的价值。

提示注入：当内容试图变成指令时

使用工具或检索的聊天机器人可能会读取用户、网站、电子邮件或文档提供的文本。其中一些文本可能包含针对模型的指令，例如告诉它忽略先前的规则、揭示隐藏信息或以意想不到的方式调用工具。这就是提示注入。

OWASP GenAI 安全项目 将提示注入列为语言模型应用的主要风险。核心问题在于模型通过相同的语言通道处理指令和普通内容。一个不可信的文档在语法上可能看起来与应用程序的指令相似。

没有任何提示可以取代系统级控制。应用程序应将检索到的内容和用户提供的内容视为不可信，限制可用工具，应用最小权限原则，验证工具调用，隔离敏感操作，并在后果重要时要求确认。模型不应仅因为界面是对话式就获得主密钥。

聊天机器人为何会给出错误或令人沮丧的答案

它们误解了请求

语言是模糊的。“关闭我的账户”可能意味着注销、删除个人资料、取消订阅或关闭金融账户。一个可靠的聊天机器人会在猜测的代价高于提出一个澄清问题的代价时识别这一点。

他们缺乏所需的信息

一个模型可能知道一般的运输词汇，但缺少用户的订单记录。检索可能会错过相关政策。某个工具可能不可用。正确的回应是说明限制或使用备用方案，而不是用一个貌似合理的故事来填补空白。

他们生成自信的虚假信息

NIST将自信呈现的虚假或错误生成内容称为杜撰（confabulation）。 生成式人工智能概况 指出这种行为可能包括虚构的逻辑或引用。流畅性使这些错误更难被察觉，但并不意味着其影响不重要。

他们丢失状态或将错误的状态传递下去

一个会话可能会忘记某个细节、混淆两个订单、保留错误的假设，或者将一个任务的信息应用到另一个任务上。状态应该足够可见以便纠正，并且范围足够狭窄以避免意外混合。

它们没有优雅的退出机制

最痛苦的循环通常是设计失败。机器人已经达到了其能力的极限，但仍不断重述相同的答案。备选方案应该改变路径：询问一个缺失的细节，展示一个支持的选项，创建一个案例，或将对话转交出去。

人工交接是系统的一部分，而不是承认失败。

有些请求含糊不清、情绪化、特殊或具有重大影响。其他请求则需要聊天机器人不应具备的权限。人类专家可以解释上下文，协商例外，承担责任，或识别文档化过程不适用于该案例。

移交只有在上下文随之传递时才有效。接手的人应收到用户的目标、确认的细节、相关工具结果以及升级的原因。强迫用户重复整个对话，会把技术上成功的转接变成糟糕的体验。

Dialogflow的 实时客服移交文档 将移交视为明确的转接。这个设计原则超越了单一平台：升级应是一个有归属权且经过测试的流程，而不是机器人在遇到问题时即兴编造的一句话。

如何判断聊天机器人是否优秀

一个令人信服的演示很容易安排。可靠的聊天机器人必须能处理常见的变化并能应对明显的失败。评估应从用户来完成的任务开始。

• 任务完成情况：用户是否获得了答案或正确完成了操作？
• 基础性：事实性陈述是否遵循了提供的来源或经过验证的工具结果？
• 恢复能力：缺失信息、未匹配事件和工具故障是否引导出有用的下一步？
• 安全性：在面对对抗性输入时，授权、确认、数据处理和工具界限是否得以保持？
• 交接质量：对话是否到达了正确的人，并提供了足够的上下文？
• 语言与可访问性：在支持的语言、输入方式、语音条件、键盘导航和辅助技术中，流程是否顺畅？
• 用户努力：完成任务需要多少轮交互、重复操作和纠正？

测试对话应包含超过顺利路径的情况。使用缺失的订单号、一个消息中包含两个号码、拼写错误、不支持的请求、过期的文档、工具超时、请求更改主题、直接请求某人以及隐藏在检索内容中的恶意指令。Google Cloud 的 代理设计指南 同样推荐迭代设计和测试用例，而不是试图一次设计所有路径。

如何在不放弃判断的情况下使用聊天机器人

1. 说明目标和最小相关上下文。精确的请求可以减少不必要的交互回合。
2. 除非特定的可信服务明确要求并保护这些输入，否则不要粘贴密码、认证代码、支付凭证、私钥或敏感记录。
3. 区分解释和实时结果。询问答案是来自当前记录、引用来源还是一般模型知识。
4. 打开引用并验证重要的声明。来源链接可能无关、过时或与答案不一致。
5. 在确认每个操作之前都要审查。检查账户、金额、目的地、日期，以及该更改是否可以撤销。
6. 当机器人重复自己、缺乏权限、误解敏感问题或无法显示答案来源时，请寻求人帮助。

值得保留的思维模型

聊天机器人不是生活在泡泡里的个性。它是一个对话界面，连接到某种组合的流程、分类器、搜索、语言模型、记录、工具、策略、安全检查和人。你看到的回应是该大型系统的最后一步。

最好的问题不是“这个机器人听起来像人吗？”而是问它是否理解了任务、使用了正确的证据、遵守了权限、诚实地恢复了，并且让你保持控制。自然语言让系统更易接近。良好的工程设计让它值得使用。

主要技术参考文献

• Joseph Weizenbaum, ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
• Lewis 等, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
• NIST，人工智能风险管理框架：生成式人工智能概要，2024年。
• Google Cloud，Dialogflow CX 关于意图、实现、代理设计和人工交接的文档。
• OWASP GenAI 安全项目，LLM01:2025 提示注入。