426 篇博文 含有标签「llm」

一个免费层级用户打开你的支持聊天窗口并询问：“你能为订单 #4821 退款吗？”你的智能体（agent）回答：“我无法办理退款 —— 这是管理员才能执行的操作。你可以通过控制面板进行升级，或者我可以为你转接。”拒绝是正确的。退款工具上的 ACL 是正确的。而你刚刚告诉了一个匿名用户：存在一个名为 issue_refund 的工具，它受名为 manager 的角色限制，并且你的平台接受格式为 #NNNN 的订单 ID。

你的规划器（planner）知道用户无法调用的工具。这种不对称性 —— 推理层可见完整目录，而动作层仅能执行部分目录 —— 正是大多数智能体权限控制（agent authorization）悄无声息出错的地方。工具边界处的 ABAC 能拦截未经授权的调用。但它无法拦截已经发生的“能力泄露”，这种泄露往往出现在前一个 token 中，比如规划、拒绝，或是关于变通方案的“热心”建议。

从任何成熟的 RAG 系统中提取一周的检索日志，并按分块（chunks）被返回的频率进行排序。其分布形态几乎总是相同的：一小部分分块出现在数千次查询中，而语料库中的绝大多数内容仅出现几次，甚至从未出现过。系统没有故障。它正在精准地执行索引构建时的预期功能 —— 而这恰恰是问题所在。

这就是向量检索中的流行度偏差（popularity bias），而且随着语料库的增长，这种情况会变得更加严重。少数分块变成了“引力井”，在互不相关的查询中频频胜出，而长尾内容则悄然消失在 top-k 截断值之下。你的 RAG 系统开始让人感觉“平庸” —— 用户提出具体问题，得到的回答听起来却像是为别人写的一样。等到产品部门开始投诉时，这种分布不均的情况往往已经持续数周了。

你刚接入的前沿模型对你的竞争对手早有定见。对于你产品旨在反驳的那些难题，它有一套默认答案。它对你所在的领域有一套“最佳实践”，而这些实践往往源于训练语料库中占据主导地位的内容；对于你在设计文档中反复纠结的每一个争议性决策，它都暗自偏向于传统做法。这些都不会出现在你的系统提示词（system prompt）中，也不是你写的。在涉及到你产品核心差异化的查询上，模型会先倾向于那些默认设定，而不是你告诉它的内容。

大多数团队在发布产品时，都把模型当成了一张可以任意配置的白纸。写好角色设定（persona），列出规则，粘贴品牌语气指南，运行几个能产生正确回答形式的 QA 提示词，然后就大功告成了。通过审核的提示词往往是处理简单查询的——在这些查询中，模型的先验认知（prior）恰好与你的预期相符。而那些真正有趣的查询，即如果产生通用回答就会让你的产品惨败的查询，几乎从未进入提示词迭代循环。在这些查询中，先验认知正在悄无声息地取胜。

向用户展示一个带有 AI 答案的界面，且每句话末尾都附有链接，还没等他们读完任何一个引用的段落，他们的信任度就已经飙升。这正是企业级 RAG 的全部营销卖点：“有据可查”、“有源可循”、“可验证”。这也是 AI 工程领域中交付最多、但测试最少的说法。最近的基准测试发现，50% 到 90% 的 LLM 回复并未得到其引用来源的完全支持，有时甚至与来源相矛盾。在对抗性评估集中，最先进模型生成的引用中有高达 57% 是不忠实的：模型根本没有真正使用它指向的文档。这些引用是事后补上去的，目的是为了让模型已经决定给出的答案显得合理。

这不是检索层面的 Bug。即便你拥有完美的检索系统，仍然会得到虚假的引用，因为这种失效是架构性的。生成器先写出文字，然后再缝补链接。这些链接看起来像证据，实则只是装饰。

强化思维在处理新颖的推理任务时表现出色。但在工具边界（即你的智能体必须选择调用哪个函数、何时调用以及传递哪些参数的时刻），同样的思维预算往往会适得其反。模型会权衡三个等效的工具，而快速模型原本只需要一个 token 就能消除歧义。它在原本不存在歧义的地方制造出听起来合理的歧义。它消耗了一千个推理 token 来反复质疑那个显而易见的 search 调用，结果最后还是调用了 search。你为一个不需要推理的决策支付了推理税。

这是 2026 年智能体系统中隐形的成本中心：问题不在于推理模型本身（其擅长领域的定价是合理的），而在于在错误的环节部署了推理模型。这种反模式（anti-pattern）就潜伏在显而易见的地方，因为顶层任务看起来很难（如“回答用户的问题”），所以团队将整个循环都包裹在深思熟虑的模式中，却从未意识到 80% 的思维预算都花在了对工具选择的微观决策上，而这些决策模型凭第一直觉就已经选对了。

打开一个智能体在长程规划任务中的追踪记录（trace），数一数模型写了多少次“让我重新考虑一下”、“经反思”或“更好的方法是”。现在，将它最终确定的计划与最初起草的计划进行对比。在我审计过的大多数追踪记录中，第二个计划其实就是换汤不换药的第一个计划 —— 同样的分解方式、同样的工具调用、同样的操作顺序，只是重命名了一些步骤标签并重新组织了理由的措辞。反思确实运行了。模型输出了看起来像是在重新考虑的 token。但计划本身纹丝不动。

这很重要，因为“带有反思”已悄然成为一种质量等级。团队在发布规划器时会加入一轮、两轮或三轮反思，并为此支付额外的成本。推理开支是真实且可衡量的。但计划层面是否真的发生了改变，几乎没有人去进行检测，而答案往往是：没有。

一个用户询问你的助手，“我该如何杀死一个挂起的 Python 进程？”结果收到了一个关于暴力的礼貌拒绝。另一个用户问，“谁获得了 2003 年诺贝尔物理学奖？”结果得到了一个自信编造的名字。这两个回答都来自同一个模型，都通过了你的安全审核，并且到周一都会出现在你的支持收件箱里。令人沮丧的是，这并不是两个独立的故障，也不是两个独立的修复方案。它们是同一个失败：你的模型被训练成识别拒绝模板，而不是识别它实际上不应该回答的内容。

整个行业花了三年时间让模型拒绝违反政策的请求。但几乎没有花时间教它们拒绝那些无法可靠回答的问题。结果是拒绝能力的方向出现了偏差：在表面模式（如 “kill”、“exploit”、“bypass”）上得到了大量强化，但在认知状态（如 “我不知道那是谁”）上几乎没有训练。当你只优化一个方向时，你得到的模型会对错误的问题说“不”，同时对错误的问题说“是”，而且通常发生在同一次对话中。

200K token 的上下文窗口并不是真正的 200K token 窗口。将其填满，你刚刚付费使用的模型就会悄然变成一个更糟糕的版本——这种退化并非发生在“迷失在中间（lost in the middle）”所预言的中间位置，而是在右侧边缘，也就是近因偏差（recency bias）本应拯救你的地方。包装盒上的标签卖给你的是余量；而硅片卖给你的却是悬崖。

这是一种大多数团队尚未内化的不同失效模式。“迷失在中间”训练了一代提示词工程师（prompt engineers），让他们习惯于将关键指令放在开头，将关键问题放在结尾，坚信首因效应（primacy）和近因效应（recency）能确保信号得以传递。然而，当利用率接近宣称的窗口极限时，这种启发式方法会悄然失效。这种下降并非逐渐的、线性的，也与模型在半满状态下的表现不对称。一旦超过某个随模型而异的利用率阈值，你就进入了一个不同的运行机制，在 30K 时有效的提示词结构在 180K 时会彻底失败。

经济上的诱惑让情况变得更糟。如果你刚刚为百万 token 的窗口付费，那么使用它的压力是巨大的——你会倾倒整个代码库，喂入每一张支持工单，交给它季度财报，并让它找出重点。结果就是，你会得到一个看似推导严密、实则自信错误的答案，而在审计时它会瞬间瓦解。

你团队每个周一盯着看的调试语料库并不是生产环境的代表性样本。它具有明显的偏差，而且偏差的方向完全错误。1% 的头部采样在保留一个罕见的灾难性轨迹之前，会先保留一百次中位数请求——大多数团队只有在某种静默循环了数月的失败模式最终导致退款或停机，并试图在追踪存储（trace store）中寻找示例却一无所获时，才会发现这一点。

这并不是什么罕见的边缘情况。这是所有专为无状态 Web 服务设计、随后又被用于长时程（long-horizon）Agent 的可观测性栈的默认行为。同样的采样算法在处理 HTTP 请求追踪时表现良好，但在处理 Agent 时却会系统性地抹除那些最重要的轨迹——因为在这里，每个“请求”都是一个包含三十个步骤的计划，可能会调用数十个工具，重新生成三个子计划，并在第 27 步发生细微错误之前消耗数万个 token。

解决方法不是“增加采样”。增加采样只会让账单爆炸，而不会改变偏差——你只会得到更多已经过剩的普通数据。解决方法是改变你采样的对象，以只有在轨迹结束后才能获知的预测结果为基准。这需要抛弃基于头部的默认设置，并围绕尾部信号、异常权重以及能在 Agent 执行的长尾效应中存续的有界蓄水池（bounded reservoirs）重新构建保留层。

语义缓存命中是唯一一种能在不到一毫秒的时间内，将错误答案发送给错误用户的 LLM 优化方式。SQL 缓存之所以会返回你或他人的数据行，是因为有人写错了 join —— 这种故障模式属于查询 bug。而语义缓存返回另一个租户的响应，是因为两个 embedding 在 0.03 的余弦距离内落到了一起，这正是系统完全按设计运行的结果。缓存完成了它的工作，问题在于这份工作本身。

大多数团队将语义缓存作为一种成本方案来推行 —— 每个 AI 工程 Slack 频道里都流传着一份“削减 70% 账单”的 PPT —— 并且像对待 Redis TTL 一样审查缓存键（cache key）：完全不审。这种审查通常交由性能团队负责。安全团队永远看不到设计文档，因为没有人会为“我们增加了一条更快的路径”提交安全审查。六个月后，某人的合规审计发现，“我无法登录我的账户，我的电子邮件是 [email protected]”和“我无法登录我的账户，我的电子邮件是 [email protected]”在向量化后都处于“我无法登录我的账户”的阈值内，于是缓存愉快地向 Bob 提供了原本为 Jane 生成的响应，其中包含了她账户请求的密码重置链接。

这篇文章将讨论为什么语义缓存值得拥有与 SQL 谓词相同的审查严谨性、如何通过缓存键设计从结构上防止跨用户泄露，以及你需要什么样的审计追踪来区分“缓存命中提供了正确答案”与“缓存命中在亚毫秒级延迟下提供了他人的答案”。

第一次验证器捕捉到糟糕的 LLM 输出时，感觉像是一场胜利。第二次，你会调整提示词以降低失败的可能性。到第二十次时，团队中没人能解释为什么提示词中存在那三个段落 —— 它们是早已被遗忘的事故留下的瘢痕组织，而模型在阅读警告上花费的 Token 比推理实际任务还要多。

这就是验证器陷阱。你添加的每一个事后防护（post-hoc guard）—— JSON 模式检查、正则表达式、内容分类器、第二个作为裁判的 LLM —— 都会对上游提示词施加反馈压力。提示词会增加防御性指令来安抚验证器，验证器反过来又会捕捉到一类新的失败，接着你又会添加更多指令。每一次迭代在局部看来都是合理且明智的。但总体而言，系统变得越来越慢、越来越贵，而且在原本设计的任务上的表现也明显变差了。

大多数工程师在构建第一个 LLM agent 时，都会遵循相同的流程：写一个系统提示词，添加一个调用模型的循环，撒上一些工具调用逻辑，然后看着它在简单的测试用例上运行。六周后，这个 agent 变成了一团难以理解的嵌套条件、粘贴在 f-string 里的 prompt 片段，以及散落在三个文件中的重试逻辑。添加一个功能需要通读整个代码。遇到生产 bug 就得盯着一个上千 token 的上下文窗口，试图重建模型当时在"想"什么。

这就是"意大利面式 agent"问题，在以 prompt 为起点而非设计为起点的团队中几乎普遍存在。解决方案不是更好的提示技巧，也不是换一个框架，而是一种纪律：在写第一个 prompt 之前，先设计好状态机。