720 篇博文 含有标签「llm」

2024年1月4日，OpenAI 下线了 /fine-tunes 接口。每一个基于 Ada、Babbage、Curie 和 Davinci 微调的模型都停止了响应。那些花费数月在这些模型上构建生产系统的团队——精心设计的提示、标注的数据集、标签流水线——一觉醒来发现收到的是 HTTP 404。微调模型没有迁移，学到的行为没有迁移，领域专业知识就此消失。

这不是小概率事件。2024年8月，Google 彻底关闭了 PaLM API，没有任何向后兼容的宽限期。与 OpenAI 至少允许现有 GPT-3.5 微调模型继续运行（只是禁止新的训练任务）不同，Google 的关闭意味着生产推理在同一天停止。如果你的微调 PaLM 模型处于关键路径上，你就遭遇了服务中断。

自 2024 年 10 月起，Google 已对所有 Gemini 用户的输出进行水印处理 —— 覆盖 2000 万用户，无可感知的质量损失，且可通过算法检测。OpenAI 已有可工作的原型，仅需数百个 token 即可产生可靠的信号。Anthropic 表示已列入路线图。欧盟《AI 法案》第 50 条要求涵盖范围内的提供商以机器可读格式标记 AI 生成的内容。然而：一种每百万 token 成本仅 0.88 美元的攻击，能同时对七种最新水印方案实现约 100% 的规避成功率。

这就是 LLM 文本水印的真实现状。已部署的方案、论文的声明与攻击者的实际能力之间的差距，远比大多数团队意识到的要大 —— 而你对水印的工程决策，很大程度上取决于你站在这个差距的哪一边。

你的 AI 功能在信心满满中上线了。A/B 测试显示用户参与度有了 12% 的统计学显著提升。置信区间没有重叠。样本量大小合适。p 值远低于 0.05。六周后，指标回落到了基准线。三个月后，它实际上已经低于基准线。实验告诉你该功能有效，但实验撒了谎。

这并不是你统计工具的 bug。这是标准 A/B 测试所测量的指标，与人类随着时间的推移与概率性 AI 系统互动之间存在的根本性错配。三种特定的偏差——新奇效应膨胀、锚定偏差和结转偏差——共同导致了每个 AI 功能实验的虚高，而增加留置组（holdout group）的常规补救措施并不能解决其中的任何一个问题。

2026 年初，Atlassian 报告了一件公司历史上从未发生过的事情：企业席位数量下降。对于一家增长模式完全依赖于扩张收入（随着客户组织增长而销售更多席位）的公司来说，这是一个结构性警报，而非偶然波动。直接原因并非客户流失或产品失败。而是 Atlassian 自身的 AI 功能大幅提高了团队效率，以至于完成同样的工作量所需的席位更少了。

这就是 AI 效率悖论：构建一个真正为用户节省时间的功能，你可能正在训练他们减少对你产品的使用。你的 AI 越有用，你的定价模型崩溃得就越快。

在每一家拥有成熟敏捷实践并决定增加 LLM 功能的公司，都悄然发生着这样一种失败模式：团队用故事点评估工作，将其分配到为期两周的冲刺（sprint）中，然后连续三个冲刺都报告“完成了 70%”，而工程经理则盯着那张拒绝下降的燃尽图发愁。没人撒谎。功能确实很难完成 —— 因为让故事点成为有用规划工具的条件，在 AI 功能中并不存在，而大家直到投入其中才察觉到这一点。

问题不在于工程师不擅长估算。问题在于故事点编码了关于软件工作本质的假设 —— 而 LLM 功能在结构上（而非偶然地）违反了这些假设。

你的 embedding 模型在周二下午 3 点宕机了。不到 30 秒，你的支持聊天机器人停止回答问题，个性化推荐引擎开始返回空结果，文档搜索一无所获，入职助手也停止工作了。你的值班工程师打开事件频道，看到来自 15 个彼此看不出联系的功能同时发出的告警。没有堆栈跟踪指向根本原因。这看起来像是分布式系统故障 —— 但其实不是。这是一个单一的共享依赖项失效了，而你之前并不知道有 15 个功能共享它。

这就是 AI 功能依赖问题：你的产品功能底层的基础设施层是深度互连的，但你的架构图却将每个功能显示为孤立的方框。当耦合是不可见的，故障传播也是不可见的 —— 直到问题爆发。

当公司谈论 AI 风险时，对话通常集中在那些显而易见的失败上：幻觉事实、偏见输出、以及生成内容带来的法律责任。而较少受到关注的是一个更隐蔽的结构性问题：你已经在其输出本质上是概率性的系统之上，做出了商业承诺——定价层级、SLA（服务等级协议）、面向客户的准确性声明。每次模型生成响应时，它都是在从分布中采样。而合同中从未提及“分布”。

这是一个大多数团队发现较晚的业务风险，通常是在客户抱怨同一个文档审查工作流在周一和周五给出了完全不同的结果时，或者当监管机构要求提供系统在架构上无法提供的可复现性保证时。

你的团队发布了一项 AI 功能。你为本地化工作感到欢欣鼓舞：每个按钮标签、工具提示和错误消息都被翻译成了 12 种语言。产品经理签了字。该功能在全球上线。

然而，六周后，一位德国用户发布了一张截图。AI 的回答用词正确但语域（Register）不对 —— 在非正式的客服场景中显得过于生硬。一位日本用户反映，结构化输出中的日期格式为 MM/DD/YYYY，这导致他们的下游工具出现故障。一位巴西的支持工程师注意到，AI 在对复杂查询进行推理时，偶尔会在句子中途滑入英语。这些并不是基础设施故障。你的仪表盘显示一切正常。但对于非英语用户来说，产品正在悄无声息地变得更糟。

根本原因几乎总是一样的：团队翻译了 UI 字符串，但却让系统提示词保留为英文。这看起来像是本地化，但事实并非如此。

大多数团队在开发初期选择一次上下文格式后，就再也不会重新审视它。一位开发者选择 JSON 是因为它看起来结构化且机器可读。另一位开发者则选择 Markdown，因为他们在 README 文件中一直使用它。当似乎没有其他必要时，普通文本（Plain text）就成了默认选择。这些并不是工程决策——它们只是习惯。并且它们在无形中塑造了你的模型如何进行推理。

你传递给 LLM 的格式并非死板的包装。它本身就是一条指令。结构化的 JSON 上下文会引导模型进入遵循模式（schema-following）的行为。Markdown 鼓励层次化的综合。普通文本则开启了更灵活的推理。即使只是选错了一个格式类别，也可能导致准确率下降 40% 或更多——而且你无法在日志中查看到这种错误。

2025 年，全球新合并的代码中约有 41% 是 AI 生成的。这些代码绝大多数流入了公开索引、被爬取、并最终反哺到下一轮 AI 编程工具训练数据中的生产代码库。其中的含义直截了当，但后果仍在持续显现：AI 模型正日益在前代 AI 模型的输出上进行训练，而没有任何结构化的记录来追踪哪些代码来自何处。

这就是上下文污染问题。它并非假设。反馈循环已在大规模运行，质量影响可以量化，而其失效模式足够特殊——在短期内可能看起来像是进步，而底层分布却在悄然退化。

同一家公司的两位分析师都问了你的 AI 助手同一个问题："我们 Q3 的客户流失率是多少？"一个人得到的是 4.2%，另一个人得到的是 4.8%。两个答案都没有错——他们只是在不同的时间、不同的会话上下文中进行了查询，检索索引对略有不同的数据块进行了排名。AI 自信地回答了两个问题，没有任何保留，没有标记任何差异。两位分析师带着不同的数字走进了同一个会议，而你的工具刚刚变成了一个负担。

这就是跨用户一致性问题，也是企业 AI 部署悄然失去信任最常见的原因之一。这种失败并非经典意义上的幻觉——没有编造任何事实。失败在于：你的系统在规模上是非确定性的，而这种非确定性在两个用户互相对比结果之前是不可见的。

一个概念验证（PoC）花费了你 200 美元的 API token。你获得了上线的许可。六周后，账单变成了 18,000 美元。这并非定价变动或计费错误——而是成本建模的失败，也是 AI 工程中最可预见的意外。

AI 功能在预发布（staging）环境和生产环境之间的成本差距并非偶然。它遵循一个一致的模式：预发布环境在结构设计上（通常是无意的）隐藏了生产环境中每一个关键的成本驱动因素。理解这些驱动因素是避免首份账单演变成危机的关键。