你的 LLM 抄不准的那个账号

一个客服智能体读完工单、拉出账户、总结了最近的活动、发起了退款。退款落到了错误的账户上。不是被凭空捏造出来的账户——是一个真实存在的、只差一位数的账户。模型写下了 acct_7H9j2，可这位客户的真实记录是 acct_7H9j3。trace 干净得无可指摘：搜索调用拿到了正确的记录，总结调用产出了正确的摘要，退款调用毫无报错地完成。每一步都成功了。钱落进了错的人手里。

这并不是事故复盘里通常说的那种"幻觉"。模型没有凭空发明一个客户。它把一个真实存在的客户的两个字符换错了位置——这是另一类失败，一类你的评测集大概率从没抓到过的失败，因为你测试样本里的合成标识符在构造上本就是唯一的。两个账号同时出现在上下文里、前三个字符相同，而语言模型——一个从未被训练成"忠实复制随机字符串"的 token 预测器——挑错了那个。

教训是结构性的，不是行为性的。模型没有任何专门为标识符设计的注意力机制。在模型眼里，acct_7H9j2 只是一串子词 token，它们的延续概率会随窗口中其他每一个 token 漂移。一旦上下文里出现了一个"近亲"标识符，模型就只差一次坏采样，就会做出一次悄无声息的替换——而 harness 会毫不犹豫地把它执行下去。

为什么"抄标识符"是模型最不擅长的字符串复制

语言模型的训练目标是从一个已学到的分布中预测下一个 token。UUID、ARN、账号、交易号、哈希摘要、签名 URL——这些都是高熵字符串，它们的价值恰恰在于"不可预测"。对一个全部能力都建立在"对已见模式做插值"上的系统来说，它们是最差的输入。

BPE 分词器会把这些字符串切成大量短的子词 token。一项公开基准测得：一个 UUID 平均消耗 24 个 token，而英文单词大约只占 1.25 个。模型被要求逐字复现一个 24-token 的序列，而这串 token 在经过注意力层之前往往已经被几十个其他 token 隔开，并且没有任何语义锚点可供校验。当上下文里同时存在两个相似标识符时，每一个"模糊位置"上的正确续写概率会向五五开崩塌。

同一份基准还跑了一个 200 条数据、引用 100 个不同标识符的聚合任务。用原始 UUID 时，模型每轮大约出 48 次错；把 UUID 重映射成小整数别名后，错误数降到了大约 6。这暴露出的架构事实非常清晰：标识符保真度是输入格式的属性，而不是模型的属性。你完全可以不换模型，只换格式，就把失败率压低一个数量级。

这种失败还有一种被团队低估的不对称性。模型并不会对标识符的每一位"平等地出错"。它最容易搞错的是局部熵最高的位置——那段看上去最像噪声的中段，因为模型在那里的先验最弱。所以被改坏的标识符往往仍然能被解析、仍然能通过正则、仍然指向一条真实存在的记录、仍然能完成一次成功的工具调用。你不会得到一个响亮的 not found。你得到的是一次安静的"打错人"。

你在生产环境真正遇到的失败形态

被换错客户的故事是这类问题最响的版本。安静的那些长这样。

智能体被要求比较两个订单的大小。它没有去比字段，而是去比 ID 本身。用户问哪个订单更大，模型从两个 ID 的前缀模式自信地给出了答案——把字符串当成了有信息量的 token，而不是不透明的键。答案错了。trace 里能看到两次 get_order 调用都返回了正确的数据；只是模型在推理时选择不去用。

智能体根据文件名去总结一份文档。检索工具返回了一组 Document 记录，每条都有 id、title、body 三个字段。模型的摘要里，一半文档用的是 title，另一半用的是 id——因为 prompt 没有显式告诉它"哪个字段才是给人读的内容"，它就只能不一致地猜。

智能体根据 URL 字符串去回答一张图片相关的问题。工具返回了一个签名后的 S3 链接。模型从未真正调用后续的 describe_image 工具，因为 schema 里没有任何东西告诉它：这个 URL 是一个引用，而不是一个值。它从路径片段和 bucket 名里凑出了一个听起来合理的答案。

智能体对一笔已不存在的交易号发起了退款。一次检索调用在同一个 response 里返回了 5 个交易号。模型选中了一个，但在把它带过工具调用边界时，掉了中间两位字符。新拼出的 ID 恰好属于同账户下的另一笔交易，工具就开开心心地把它退掉了。

每一例里，trace 看上去都是健康的：工具调用成功、返回结构良好、智能体的推理也说得头头是道。真正的伤害来自一个架构从未把它当作一个步骤来命名的"字符串复制"步骤。

别再让模型去抄 ID 了

修复办法是把"标识符保真"从模型的工作描述里直接删掉。模型永远不应该把一个原始标识符敲进一次工具调用。harness 应该从一张稳定的、带类型的引用表里解析标识符，模型通过符号句柄寻址这张表。

加载中…