我们如何处理对话代理中的‘灰色地带’逻辑

Source: Dev.to

原始输入的问题

标准的聊天机器人构建教程通常是这样的：

1. 获取用户的输入。
2. 将其追加到提示词中。
3. 发送给强大的模型（如 GPT‑4）。
4. 将答案流式返回。

在企业环境中，这令人恐惧。

当我们为 TON 生态系统设计架构时，面对的是高风险交互。加密、金融和去中心化企业解决方案没有容错空间，**“幻觉”**是绝对不允许的。如果一个机器人因为想要帮忙而自信地给出错误的钱包交易建议，这不是 bug，而是法律责任。

核心问题在于，强大的大语言模型（LLM）被设计成迎合用户。它们想要完成给定的模式。如果你提出一个问题，它们会觉得必须回答，即使答案是 “我可以帮助你绕过那个安全协议”。
为了解决这个问题，我们不再把 LLM 看作单一的大脑，而是把它视为由多个独立认知阶段组成的系统。最关键的阶段？门口的保镖。

“分类器优先”架构

我们对逻辑流程进行的最大升级是一条现在看起来显而易见的规则：

停止将原始用户输入直接发送给你的主 LLM。

在用户的消息到达生成答案的逻辑核心之前，它会先经过一个轻量级、高速的意图分类器。对于这个角色，像 Gemini 1.5 Flash 这样的模型非常出色——它们速度快、成本低，而且足够智能，能够对文本进行分类，而不会在创意细节中迷失。

Source:

对混乱进行分桶

我们让这个轻量模型只做一件事：分流。它不直接回答用户，而是给查询打标签。每个输入都会被归入以下类别之一：

• 安全 / 可操作的： 关于文档或功能的标准问题。
• 恶意 / 对抗性的： 提示注入尝试、辱骂性语言或试图欺骗机器人的行为。
• 模糊的： “它不起作用”或“帮帮我”。
• 超出范围的： 关于竞争对手、政治或任何机器人不应涉及的话题。

处理逻辑

• 如果归类为 “恶意”，系统会立即终止对话并返回预设的拒绝信息。昂贵的“推理”大脑永远不会被激活。
• 如果归类为 “模糊”，系统会触发澄清流程。
• 只有当归类为 “安全” 时，我们才会分配计算资源来生成细致的回复。

这形成了一道防御性防线：在查询到达推理引擎之前，我们已经剥离了大约 90 % 的风险。

背景改变一切

Classification isn’t static. This is where the “gray area” gets tricky—a phrase that is dangerous in the first message might be perfectly valid in the fifth message.

Consider the phrase: “I want to transfer my funds.”

• Message #1: 用户未经过身份验证，且我们不知道目的地。这是一个灰色地带的请求；直接回答可能会产生责任。
• Message #5: 在用户完成身份验证并选择钱包后，同样的短语就成为有效的操作指令。

使用 Firestore 的有状态感知

为了解决这个问题，我们依赖 stateful context awareness（有状态上下文感知）。仅凭 LLM 的上下文窗口无法可靠地跟踪业务逻辑的“状态”。虽然 LLM 在对话方面表现出色，但在记住刚才所在的严格工作流阶段时会出现困难。

我们使用 Firestore 之类的数据库来维护对话的外部 state object（状态对象）。这不仅仅是对已说内容的日志，而是跟踪交互的 阶段。

当意图分类器处理消息时，它首先从 Firestore 中获取当前状态。相同的用户查询会根据用户是处于 Stage 2 还是 Stage 0 而被不同地解释。

这种方法让机器人能够动态调整其防护措施：在对话开始时加强安全性，随着用户提供更多已验证的信息，逐步放宽操作能力。实际上，它把“灰色地带”转变为明确的黑白逻辑门。

审计反馈循环

即使使用了分类器和状态管理，机器人有时仍会选择保持沉默。它们会拒绝回答。在实际运行中，我们意识到 沉默是我们拥有的最丰富的数据信号，但大多数团队却忽视了它。

当机器人拒绝回答时，通常意味着以下两种情况之一：

• 良性沉默（合规）：用户试图欺骗机器人，而机器人正确地将其关闭。
• 不良沉默（知识缺口）：用户提出了合法的问题（例如，“这个特定 API 是如何 … 的？”）。

捕获、审查并对这两类沉默采取行动，对于系统的持续改进至关重要。

错误工作？

机器人将该查询分类为 “超出范围” 或 “未知”，因为它缺乏必要的数据。

Analyzing the “Why” with BigQuery ML

您如果把所有沉默都视为相同，就无法改进机器人。为了解决这个问题，我们使用 BigQuery ML 实现了审计循环。

1. 记录每一次交互，包括机器人拒绝回答或将查询标记为 “灰色区域” 的情况。
2. 对这些日志进行批处理，分析 意图 与 结果 的关系。

通过对这些沉默交互进行聚类，我们可以发现模式。如果我们注意到在某个特定主题上——例如 TON 生态系统中的新功能发布——出现 “不良沉默” 的激增，就说明我们存在知识盲区。机器人并未出错，只是还没有被教会该新主题现在是 “安全” 的。

此反馈循环将生产故障转化为训练数据，使我们能够区分机器人是“在安全地工作”还是“在毫无用处”。

为什么这对行业重要

企业中**“通用聊天机器人”的时代即将结束。与机器聊天的新奇感已消退；用户现在期待准确性、安全性和问题解决**。

行业正转向专用的、具代理性的架构。我们不再仅仅对模型进行提示；我们正在构建系统，在这些系统中，大语言模型是组件，而不是整台机器。

对开发者和产品负责人 的影响

• 竞争优势不再仅仅是“使用最好的模型”。
• 每个人都可以使用 Gemini、GPT‑4、Claude 等。
• 真正的优势在于编排层——围绕模型的分类器、状态管理和审计循环。

结论

构建高效的对话代理更多的是关于流量控制，而不是创意写作。人类语言杂乱、常常具有欺骗性，并充满歧义。

• Classifier‑First 方法 → 节省成本并提升安全性。
• Stateful context（例如 Firestore）→ 确保机器人理解时间和进度，而不仅仅是文本。
• 使用 BigQuery 等工具进行审计沉默 → 确保防护措施不会扼杀合法用户。

在企业技术及 TON 或其他 Web3 平台等复杂生态系统中，目标并不是构建一个无所不知的机器人，而是构建一个清楚知道自己不该做什么的机器人——并且能够精准地判断何时走出灰色地带，走向光明。