778 篇博文 含有标签「llm」

每个人都在担心模型崩溃，将其视为一个互联网规模的问题：AI 废话充斥网络，下一代基础模型基于这些数据进行训练，导致质量在一个缓慢的文明反馈循环中衰退。这种表述让人感到宽慰，因为它把崩溃变成了别人的问题——这是发生在 OpenAI 和 Anthropic 身上、以年为单位的事情，并且由成群的数据清洗博士负责缓解。

这里有一个令人不安的版本：同样的反馈循环已经在你公司内部运行，而且它的收敛速度比互联网规模的循环快得多。每一个被标记为“黄金示例”的日志补全、每一个进入 RAG 语料库的模型编写文档、每一个通过 LLM 生成答案并由 LLM 评判的评估——每一项都是在利用你自己的“数据废气”进行训练的微小行为。你不需要九代的递归预训练就能感受到它。在一个从自身日志中挖掘少样本示例和微调数据的生产系统中，第二代产品下个季度就会发布。

询问大型语言模型现在几点，你得到的回答虽然语气自信，但几乎肯定是不准确的。这并非因为模型坏了，而是因为它的内部没有时钟。Transformer 是一种无状态的文本补全引擎：它将 token 映射到 token。在整个流水线中，没有任何地方会接收到“现在是 14:32 UTC”这样的信号。模型感知不到当前时刻 —— 这是你必须在每一轮对话中主动提供给它的东西，否则它就会从陈旧的训练数据中臆造一个时间。

这种无声的失败往往在最糟糕的时刻浮出面。你的智能体认为现在是星期一，因为会话是在星期一开启的，于是它在星期二、星期三依然坚信这一点，直到它为一个已经过去的日子设定了“明天早上”的提醒。它利用数小时前就已冻结的 now 来分析“过去 24 小时”的日志。它在转换跨时区的会议时间时，因为误判了夏令时的边界而导致一小时的偏差。这些在传统意义上都不像是“幻觉”。其输出流畅、合理且逻辑自洽，只是它锚定在了一个不再存在的时刻。

模型给了客户一个错误的、代价高昂的回答。你打开复盘报告（post-mortem），将完全相同的提示词（prompt）粘贴回完全相同的端点，并将 temperature=0，结果你得到了一个不同的答案。不是更坏，也不是更好——只是不同。你本该找出根本原因（root-cause）的 bug 无法按需复现，而那个每个人都告诉你保证能复现的开关刚才却当面撒了谎。

就在这一刻，大多数团队发现“将 temperature 设置为 0”只是民间传说，而非工程控制手段。零 temperature 改变了模型的“采样”（sampling）方式——它强制进行贪婪解码（greedy decoding），始终选择概率最高的 token。它并不能保证两次计算得出的概率本身是完全一致的。而在生产环境的服务栈中，它们通常并不一致。

有一种特定的遗憾，只发生在 AI 团队中。你花了一个季度的时间构建了一个复杂的变通方案——多步提示词链、自定义重排序器（reranker）、手动调优的工具路由层——然后上线。它起作用了。但六周后，一个新模型发布，一次调用就能原生完成所有这些工作，你一个季度的工作现在变成了必须清除的累赘。功能没有失败。底座（Floor）移动了。

这是 2026 年规划 AI 功能的结构性问题：你构建其上的底座改进速度快于你的发布周期。从 2023 年到 2025 年中期，前沿实验室大约每六个月发布一次。到 2026 年第一季度，这一周期缩短至大约每四周发布一次重大版本，甚至出现过五个实验室在 13 天内密集发布的情况。在你规划和发布之间，你脚下的根基正在发生变动。

询问任何工程主管，他们是否被模型供应商锁定了，他们都会指向抽象层。“我们通过网关路由所有内容。更换供应商只是配置更改。”端点只有一行代码。Base URL 是一个环境变量。在纸面上，迁移只需要一个周二下午。

然后他们尝试了。他们将配置切换到不同的模型系列，集成测试依然通过，但生产环境却悄然崩溃。原本总能解析的 JSON 现在被包裹在 Markdown 代码块中。准确率曾达 94% 的分类器降到了 80% 出头。一个稳定运行了一年的提示词开始因为无人能复现的原因，在每 20 个请求中拒绝 1 个。端点在几秒钟内完成了切换，但行为并没有随之迁移。

这就是没人预料到的锁定。它不在你的合同或 SDK 中，而是在你的提示词（prompts）中——你的团队为了适应单一模型系列的特性，一次又一次地做出的数千个细微调整。你选的不是模型，而是与之“联姻”，而“婚前协议”就是你发布过的每一个提示词。

一份客户支持记录离开位于法兰克福的服务器，被拼接成一段提示词 (prompt)，然后跨越大西洋传输到位于弗吉尼亚州的 GPU。模型思考了 800 毫秒。响应返回。从用户的角度来看，什么都没发生 —— 聊天正常进行。从你的监管机构的角度来看，你将个人数据转移到了第三国，而你可能无法说明其法律依据。

这是 LLM 落地过程中演示版本会隐藏的部分。原型调用 api.openai.com 然后上线。接着，来自德国银行、法国医院或你公司法务团队的采购问卷会提出一个原型从未需要回答的问题：推理在哪里发生，谁可以强制访问这些数据？ “供应商符合 SOC 2 标准”是下意识的回答，但这是错误的 —— 它回答的是关于供应商内部控制的问题，而不是关于哪个司法管辖区的法院可以触及你的提示词。

最近我交流的一个团队花了三个工程师周的时间，将平均 Prompt 从 4,000 Token 削减到了 2,600 Token。他们以此为荣 —— 纯 35% 的降幅，实打实的数据，幻灯片里漂亮的图表。然后有人反向算了一笔账：这笔节省每月大约为 1,800 美元。而他们投入的三个工程师周，折算成全额薪酬成本大约是 25,000 美元。按照这个月度消耗率，这笔优化大约需要 14 个月才能回本 —— 这还是假设 Prompt 永远不变、模型永远不降价，且那些工程师没有更有价值的东西可做的情况下。

然而，这些假设一个都没成立。下个季度 Prompt 改了两次。他们使用的模型本身就降价了 40%。而那些工程师那个月没能发布的特性，恰恰是最大客户一直询问的功能。

临床决策支持工具的任务只有一个：帮助医生使用他们在病历中使用的词汇来推理症状、药物和治疗方案。这意味着智能体必须能够直呼其名地讨论药物过量阈值、药物相互作用、禁忌症和剂量。这些都不是可选的。这就是产品本身。

因此，当模型在会诊中途打断，对面前就有患者的专业医生说，没有专业监督就无法提供医疗建议时，这是一种特殊的失败。医生没变，患者没变，提示词也没变。改变的是团队并不拥有的安全过滤器，它是针对团队并不属于的人群进行微调的，并按照团队无法控制的时间表进行更新。

这就是“供应商审核裂缝”（vendor moderation seam），它是应用 AI 领域讨论最少的边界之一。大多数团队将供应商的安全层视为模型的固定属性，就像上下文窗口一样。但事实并非如此。这是一种策略——一种动态的策略——无论你是否编写了它，现在它就是你产品的策略。

18 个月前，“我们构建了自己的检索流水线”在架构评审中还是一个非常合理的说法。你拥有分块策略、经过基准测试的嵌入模型、调优过的向量数据库、重排序器，以及一个由 3 名工程师耗时一个季度才搞定的上下文填充启发式算法。那一套技术栈曾是真正的差异化基础设施。而今天，同样的能力只需一次托管的工具调用：将文件上传到向量数据库，将其附加到请求中，供应商就会完成解析、分块、嵌入、存储、检索和重排序——所有这些都隐藏在一个 API 背后。曾经需要 3 名工程师开发一个季度的成果，现在只是一个配置对象。

这就是目前构建 AI 产品令人不安的模式。自建与外购之间的界限并非固定，它在移动，而且只向一个方向移动。每隔几个月，模型供应商就会发布一个原生功能（primitive），蚕食掉你曾经拥有的一个层级：记忆、检索、结构化输出、工具路由，甚至是多步编排。上个季度还让你引以为傲的基础设施，这个季度就成了竞争对手可以免费获得的东西，而且默认配置更好，延迟底线更低，因为它就运行在供应商自己的数据中心内部。

一种本能反应是将其视为需要防范的威胁。但这种思维框架是错误的。供应商吸收通用基础设施实际上是在帮你——它帮你删除了你本就不想要的维护工作。真正的问题在于，你选择构建的东西是位于不断上升的水位线之上还是之下。大多数团队从未明确做出这个决策。他们为了演示需求构建了一切，一年后才发现 70% 的代码库是在重新实现供应商现在提供的原生功能，而那 30% 真正具有防御性的部分反而因为缺乏关注而枯萎。

大多数财务团队都把第一张 LLM 账单放错了地方。它出现在实验阶段，当时只有少数工程师正在使用 API 密钥进行原型设计，它看起来确实就是当时的样子：研发支出 (R&D)。每月花费几千美元来弄清楚这项技术是否可行。因此，无论是在认知上还是在实际操作中，它都被归入了研发支出，没有人对此深究。

随后，功能上线，使用量攀升，第一季度还是可以忽略不计的误差项，到了第四季度就变成了云服务账单中增长最快的成本。问题从来不在于金额大小。问题在于成本已经悄然改变了类别——从对构建某项功能的固定投入，变成了服务每一位用户的变动成本——而思维模型却没有随之转变。

这种分类错误是目前 AI 产品中最昂贵的会计错误，而且它本质上甚至不是会计错误，而是预测错误。

一个 RAG 智能体用一段简洁的文字和一条引用回答了客户的监管问题。验证层获取了该 URL，看到返回码为 200 OK，勾选通过并发布。六个月后，合规性审计调取了对话记录，点击同一个链接，却发现页面现在的内容与智能体引用的完全相反。URL 没问题，对话记录中的引用也没问题，但两者不再匹配。客户的合规官询问智能体是否捏造了引用，而团队无法证明它没有捏造，因为证明该 URL 过去内容的唯一证据就是智能体自己声称它说过什么。

这不是通常意义上的幻觉。模型检索到了真实内容，忠实地提取了真实的句子，并给出了一个至今仍可解析的真实 URL。世界上任何链接检查工具都会认为这个引用是有效的。然而，审计依然失败了，因为验证层衡量的是错误的属性。可访问性（Reachability）并不等同于忠实度（Fidelity）。URL 只是指向受他人编辑控制的可变文档的指针，一旦文档发生变化，每一份引用它的对话记录都会变成一个随时可能爆发的“幻觉报告”。

用户提交了一个问题。你的模型生成了一个答案，这个答案以一种非常具体的方式“自信地出错”：格式完美，推理结构严密，并且出现了一个特定的限定词——这个限定词完全不适用于这个问题——它出现的位置，恰好是你系统提示词（system prompt）中示例三出现类似限定词的地方。这既不是幻觉，也不是提示词注入。模型只是精确地执行了示例教它的操作，尽管这些示例原本并非为了涵盖这个问题。

这就是 Few-Shot 提示主动诱发的故障模式，而大多数评估套件（eval suites）在结构上对此是视而不见的。你的示例并不是“优秀范式”的中立演示。它们是判例法（case law）。模型通过表面 token 选择最匹配的项，并将该先例——包括其限制条件——应用到眼前的任何案例中。