639 篇博文 含有标签「llm」

团队第一次构建带有结构化输出的流式 AI 功能时，遇到的 bug 总是如出一辙。模型生成正常，数据块（chunks）接收正常。但在第 47 个 token 左右，解析器挂掉了，UI 冻结了，或者更糟——一个半成型的枚举（enum）值被路由到了下游工具，导致其悄无声息地执行了错误操作。团队在 JSON.parse 周围加了一个 try/catch，觉得自己搞定了，然后发布。两周后，兄弟团队抱怨响应变长后流式 UI 感觉很卡。一个季度后，事故审查询问为什么在一个模型仍在描述为 "DeleteIfEmpty" 的记录上触发了 "Delete" 工具调用。

Bug 不在任何单个 token 中。Bug 在于 token 流式传输和结构化输出在架构上是冲突的，而大多数框架只是用“祈祷”来掩盖这种冲突。Schema 说“这是一个完整的对象”。Token 流说“这是一次一个字节的数据”。从定义上讲，这两个端点之间的每一个中间状态对于 Schema 来说都是无效的。团队的工作是决定在这些中间状态期间该做什么——而大多数团队并没有明确做出这个决定。

一个长时间运行的 Agent 每 12 轮就会达到其压缩阈值。每一次压缩的成本都相当于一次规模等同于当前运行窗口的 LLM 调用——首先是 8K tokens，然后是 14K，接着是 22K——因为被总结的内容跨度随着每次触发而增长。到了第 60 轮，用户在观察 Agent 自我总结上花费的 token，已经超过了在实际推理上花费的 token。成本仪表盘将“用户推理成本”显示为一个单一数字，完全没有意识到其中一半是为用户永远不会再看的上下文压缩而付费的。

这就是“总结税”：一类随着对话长度增加而增长的开销，在用户回合之间悄然触发，并作为一个单一项目出现，将用户付费的工作与系统为自我管理而进行的内务处理混为一谈。这是现代 Agent 架构中最接近“垃圾回收停顿时间（garbage-collection pause time）”的东西——而大多数团队在生产环境中运行时都关闭了 -verbose:gc。

五份精心设计的文档。260 万条记录的语料库。操纵特定 AI 响应的成功率高达 97%。这是来自 PoisonedRAG 的基准测试结果，该研究发表于 USENIX Security 2025 —— 而且这种攻击不需要模型访问权限，不需要在推理阶段进行提示词注入，甚至不需要与系统进行任何直接交互。攻击者只需向知识库贡献内容即可。

如果你的 RAG 系统允许用户添加内容 —— 服务台工单、Wiki 编辑、客户反馈、共享笔记 —— 那么你已经发布了攻击载体。问题在于你是否也同步发布了防御机制。

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% 或更多——而且你无法在日志中查看到这种错误。