跳转到主要内容

你的产品视图从未呈现的推理 Token

阅读需 1 分钟Tian PanTian Pan

一位客户给支持团队发了邮件。AI 助手告诉他们在错误的司法管辖区申报纳税,他们非常生气,想知道助手是如何得出那个答案的。你的支持人员打开问题队列,看到了最终回复:自信、听起来很有道理,但却是错误的。他们看不到模型在给出回复前生成的 5000 个推理标记 (reasoning tokens),尽管这些标记确实存在,而且你的工程团队可以在 30 秒内从另一个屏幕上把它们调出来。证据就在公司里,只是拿在错误的人手中。

这就是团队在生产环境的智能体上启用扩展思考 (extended thinking) 时产生的差距。推理成为了每一次调用的核心产物,而你的组织尚未决定谁在什么时候、以何种精度、以及在多长时间内可以看到它。默认决策是由负责各个界面的团队分别做出的,他们的默认设置各不相同,而这些缝隙恰恰是客户投诉产生的地方。

推理是一个界面,而非副作用

当你开启扩展思考时,模型会产生两个流:面向用户的回答和一段长得多的、用于解释该回答的推理轨迹 (reasoning trace)。模型提供商在单独的字段中返回推理内容,SDK 将其公开为结构化对象,应用程序存储它(因为存储完整响应是最省事的做法),而产品 UI 只显示最终答案,因为产品团队的职责范围仅限于“用户看到的内容”。

这些决策在局部看来都是正确的,但没有一个演变成深思熟虑的策略。结果是,推理轨迹存在于你的追踪存储中(通常是出于偶然),并被挡在你碰巧首先打开的那个团队的工具之后。

需要这些内容的群体各不相同:

  • 工程师需要完整的轨迹来调试回归问题:模型关注了哪些检索片段、考虑过拒绝哪些内容、逻辑链在何处偏离了方向。
  • 支持人员需要一份经过清洗的摘要,以便向客户转述:足以解释答案,但又不会暴露模型内部细节或其他用户的数据。
  • 产品经理 (PM) 和产品分析师需要聚合信号:推理何时不确定、何时陷入循环、何时在轨迹中途改变主意,以便在客户报告之前发现质量偏差。
  • 事故指挥员需要在复盘模版中嵌入固定格式的摘录,因为重建智能体的推理过程现在已成为基础的取证步骤。
  • 隐私合规人员需要知道哪些推理字段包含用户衍生的数据,因为这决定了数据的保留类别。

你无法用同一个原始数据块 (raw blob) 来满足所有这些群体的需求。但如果你在没有设计的情况下发布产品,你最终得到的就只是原始数据块,外加一个写着“咨询工程团队”的 Confluence 页面。

没人审查过的个人隐私信息 (PII) 问题

推理标记具有一种属性,使其在法律上与常规模型输出不同:它们由用户输入塑造,但从未被作为用户衍生数据进行审查。用户输入查询。查询中提到了姓名、诊断结果、薪资或地址。最终答案经过了清洗——也许你的防护层在显示前擦除了 PII——但位于上游一层的推理轨迹会原封不动地重述 PII,因为模型需要针对眼前的具体案例进行思考。

最近的研究对此直言不讳。思维链 (Chain-of-thought) 轨迹经常在推理过程中重述姓名、人口统计信息、医疗细节和其他隐私属性,即使模型已被指示不要在最终输出中这样做,而且较长的推理往往会增加而不是减少泄露。模型正在利用 PII 进行推理,而推理过程正在被存储。

你的隐私审查几乎肯定忽略了这一点。签署数据流合规的团队考虑的是请求体、响应体和日志。推理轨迹看起来像是模型遥测数据——内部的、面向工程的——因此它被划归到了与延迟指标相同的保留类别中。事实并非如此。它是具有与原始提示词相同敏感度的用户内容,有时还附带额外的推论。一条写着“用户提到他们是 HIV 阳性并询问加州的保险范围”的推理轨迹,现在就是存储在你的追踪表中的敏感医疗记录。

解决方法不是“在存储前清洗推理内容”。清洗是有损的,工程人员确实需要未经清洗的版本来进行调试。解决方法是认识到推理内容应该针对不同受众制定保留和脱敏策略,并在数据落地到任何地方之前进行明确的设计。

存储成本变成了你从未写过的采样策略

存储推理标记的成本并不低。典型的扩展思考响应产生的标记数量是非推理调用的 3 到 10 倍,而且追踪记录必须保留其周围的结构化外壳——调用 ID、工具调用、中间状态——这增加了追踪存储中每一行的成本。乘以请求量后,推理轨迹的存储账单会让答案本身的存储账单显得微不足道。

因此,团队在发布时会带上采样规则。通常这是隐式的:可观测性供应商 SDK 中的默认设置,保留 10% 调用的完整轨迹,其余仅保留元数据。有时它是显式但粗糙的:保留错误的完整推理,丢弃成功的。无论哪种方式,采样规则都在对哪些轨迹重要进行一场无声的赌博。

当你需要它的那一天,这场赌博几乎总是输的。客户投诉很少来自于报错的调用——那些调用通常被重试并恢复了。投诉来自于那些以自信姿态给出错误答案的成功调用,而“自信的错误”恰恰是你的“仅保留错误”规则所丢弃的轨迹类别。当三天后客户投诉到来,而轨迹已被采样过滤掉时,你将一无所有。

有一些模式比一刀切的采样效果更好:

  • 基于智能体质量信号的尾部采样 (Tail-based sampling):当用户给出差评、请求被下游检查标记、答案与工具结果相矛盾、或者调用消耗的推理标记超过该工作负载的中位数时,保留完整推理。负面信号案例正是复盘开始的地方。
  • 针对特定客户的保留覆盖:对审计需求严格的企业客户,其租户下的调用进行全量保留。默认租户进行采样。成本由支撑该需求的合同承担。
  • 分级精度,而非非黑即白:为每次调用始终保留推理的结构化摘要(长度、决策点、考虑过的工具)。仅对有必要的部分子集保留原始标记。摘要成本低廉,且保留时间可以远超原始数据。
会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 9 分钟

你从未构建过的智能体反馈闭环

每一个点踩、每一次无声的放弃、每一次重新表述的问题,都是一个免费的带标签失败案例 —— 而大多数团队却将其丢弃。本文介绍如何构建从用户信号到分诊失败再到永久评估案例的流水线。

insider
ai-engineering
阅读需 12 分钟

智能体动作空间的可达性分析:为你从未测试过的分支提供评测覆盖

你的工具目录加上规划器构成了一个可达的执行计划图,而你的评测(Evals)可能从未覆盖过这些路径。借鉴编译器的可达性分析方法,找出那些可能最先由事故频道(Incident Channel)发现的隐藏分支。

insider
ai-engineering
阅读需 11 分钟

代理墙钟预算:一场与工具超时机制的赛跑

在代理技术栈内部,代理的时钟与工具的时钟几乎从未共享同一个零时刻 (t-zero)。当它们的预算发生偏差时,一个耗时 8 秒的工具调用可能会撞上 7.9 秒的截止期限,导致框架针对一个它从未见过的“成功”结果进行重新规划。

insider
agents
阅读需 11 分钟

供应商将你的模型标识符重定向到特定租户的微调模型,而其他人使用的却是基础模型

如果将 LLM 模型标识符视为权重的名称而非路由决策的标签,那么供应商可能会在评估套件仍保持“绿色”通过状态时,静默地将你的租户从微调模型切换回基础模型,导致客户最先察觉到问题。

insider
llm
阅读需 10 分钟

被反向代理剥离的 SSE Keep-Alive,以及你支付了两次费用的 Prompt

LLM 流式响应看起来像是从模型到用户的通畅管道 —— 直到一次 35 秒的工具调用导致反向代理断开连接,你的客户端针对无状态 API 重试整个 Prompt,最终用户的账单为同一个响应支付了两次费用。

insider
ai-engineering