861 篇博文 含有标签「insider」

你的聊天产品需要分支功能的最明显信号，往往也是最容易被忽略的：用户不断地将旧对话复制粘贴到新的会话中。他们不是在更换供应商，也不是因为无聊。他们是在尝试询问“如果我早点反驳那个假设会怎样？”，同时又不想丢失花费了 40 轮对话建立的上下文。线性线程只为他们提供了两个选项——要么覆盖下一条消息并丢失原始回复，要么开始新聊天并丢失前置内容。于是，他们利用剪贴板发明了第三种方案。

每当用户这样做时，你的产品就在通过这种变通方法泄露一个功能需求。这个变通方法很糟糕：它剥离了消息元数据，破坏了工具调用（tool-call）的联动，丢失了文件附件，并产生了不再映射到连贯任务的孤立线程。但它之所以存在，是因为另一种选择——放弃花费 30 分钟建立的上下文——更糟糕。对话在结构上是一棵树，而 UI 却坚持它是一个列表。用户只能手动填补这个鸿沟。

每个 AI 产品团队都会有一种特定的会议，通常发生在周四。有人共享屏幕，在 notebook 里输入一个 prompt，然后运行三四个例子。房间里的人反应热烈。大家惊叹“哇”。有人截图发到 Slack。决策就这样做出了——上线、更换模型、调整 temperature。没有人记录失败率，因为根本没人去衡量它。

这就是演示循环（demo loop），它带有一种几乎没有团队意识到的结构性偏见：它筛选的不是最佳输出，而是最“易读”的输出。几周或几个月下来，你的 prompt 不断演进，最终生成的是那些能“在会议中镇住场面”的答案——自信、流利、格式整齐、切中主题。至于它们是否正确，则是另一个变量，而你的流程并没有衡量这个变量。

其结果就是我所说的“有魅力的失败”（charismatic failure）：输出结果在某些方面是错误的，但由于选择压力，你的演示循环已经被训练得会自动忽略这些错误。

在某个预发布（staging）频道里，一位工程师写道：“将嵌入模型（embedder）升级到 v3，新模型在 MTEB 上的得分提高了 4 分，冒烟测试通过后合并。”两天后，客服工单开始陆陆续续出现，反馈搜索结果感觉“莫名其妙地不对劲”。一周后，检索精度下降了 14 个百分点，余弦相似度分数从 0.85 暴跌至 0.65 左右，而且没人能解释原因——因为这次部署看起来与过去五次模型升级完全一样。这根本不是一次普通的部署。而是一次披着部署外衣的数据库迁移。

嵌入模型轮转是 AI 基础设施中最容易被归类错误的变更类型。它通过与提示词（prompt）微调或生成模型版本更新相同的渠道进入你的系统——配置文件、PR、CI 检查——因此它遵循配置变更的治理流程。但从底层来看，新的嵌入模型并不会产生旧向量的更好版本。它产生的向量完全存在于不同的坐标系中，跨两个流形计算余弦相似度是一个范畴错误（category error）。正确的心理模型不是“升级依赖版本”，而是“在提供读取服务的同时，为一个拥有 5000 万行的表更换主键编码”。

你的评估套件通过了。质量仪表板显示为绿色。一周后，用户正在悄悄流失，没人能解释原因。评估集并没有通过犯错来撒谎——它的谎言在于它是一面镜子。你用来评分的标签，可以追溯到正是由你试图评估的那个模型家族生成或过滤的。通过这项评估并不是质量的证明。它证明了你的模型与其过去的输出是一致的。

这是成熟 LLM 流水线中一种隐蔽的失败模式：通过生产泄漏导致的评估集污染。这不同于著名的基准测试污染（即在 GSM8K 上训练的模型又在 GSM8K 上进行评分）——那个故事已经被讲烂了。更微妙的一种发生在下游。你的黄金标签来自用户反馈、来自先看到模型草稿的人类标注员、来自 RLHF 奖励追踪、来自 LLM-as-judge（模型即评委）的偏好数据。这些流水线中的每一个都将当前模型习语的指纹带回到了你的“基准真值”中。几个季度下来，测试集悄悄地记住了你模型的偏好，评估变成了一个自我表扬的循环。

每个在没有评估（evals）的情况下发布 AI 功能的团队都会对自己讲同样的故事：我们会以后再添加衡量标准，等到找到产品与市场契合点（PMF）之后，等到提示词（prompt）稳定之后，等到下一次发布之后。六个月后，提示词已经被四位工程师和两名产品经理修改过，其行为支撑着三个客户集成，团队发现“以后添加评估”意味着要从从未为此目的结构化过的生产日志中重建意图。本应开发新功能的季度变成了考古季度。

这不是规划错误。而是一个复利错误。为了更快发布而跳过评估的团队，正是那个将花费十二周时间从不完整的追踪（traces）中重建评估基础设施、为二月份所谓的“正确”含义争论不休、并悄悄移除没人能证明依然有效的功能的团队。追赶的成本超过了内置的成本——不是一点点，而是随着每一次未经回归检查就发布的提示词修改而倍增。

当你的第一个微调模型上线生产环境时，你的权重就成了一种你的隐私计划从未编目过的新型记录。进入训练组合的客户服务记录不再仅仅是数据库中你可以 DELETE 的一行 —— 它现在被冗余且不可提取地编码进了你的 API 所提供的参数中。原始记录可以从 S3 中擦除，从你的仓库中抹去，并从你的 RAG 索引中删除，而模型仍会继续使用该客户的姓名、账户 ID 或病史片段来完成提示词。你的销售团队签署的数据保护协议 (DPA) 承诺你会履行删除请求。但没有人问过 ML 团队这在技术上是否可行。

关于 PII 提取的研究表明，这并非假设。PII-Scope 基准报告显示，在现实的查询预算下，针对预训练模型的对抗性提取率最高可增加五倍；而使用自提示校准的成员推理攻击已将微调模型的 AUC 从 0.7 提升至 0.9。Llama 3.2 1B 是一个被广泛复制的小型基座模型，已被证明会记住其训练集中存在的敏感记录。对于任何在生产追踪数据上发布微调模型的人来说，结论是生硬的：你不能假设你的权重已经忘记了。

这一点很重要，因为大多数微调流水线是由 ML 工程师设计的，他们优化的是损失 (loss)，而不是由优化 GDPR 第 17 条款的数据主管设计的。结果产生了一个法律地位模糊、来源极少被记录、且不存在“删除用户 X”工作流的产物。

一位创业公司的 CTO 某天早晨检查 OpenAI 后台，发现了一张 67,000 美元的账单。他们往常的月账单是 400 美元。产品层面没有任何变化 —— 没有爆火的发布，没有新功能，也没有营销活动。变化的是，攻击者识别了他们的端点指纹，从构建产物中获取了泄露的密钥，并将推理服务以低于零售价 40-60% 的价格转卖给那些支付加密货币的买家。创业公司付了账单，而攻击者赚取了差价。

这不是 SaaS 创始人互相传颂的典型免费层滥用故事。典型故事是：少数重度用户滥用了慷慨的试用，流失率飙升，你收紧限制，单位经济效益在一个季度内恢复。这套剧本在 AI 产品上已经过时了。当你针对匿名请求的单位成本不再实际上为零，且你的慷慨一旦可以被变现，这种数学模型就崩塌了。

你的仪表盘显示 GPU 状态健康。利用率维持在 80% 左右，每秒生成的 token 吞吐量看起来很正常，冷启动很少见，而且模型也是你要求的那个。然而，你的报警器响了，因为 p99 延迟翻了三倍，少数用户遇到了超时，支持工单都在描述同一件事：“应用冻结了 20 秒，然后又恢复了。” 你调取了一个追踪（trace），发现一个毫不相关的客户发送的 28,000 个 token 的推理请求，正与每一个停滞的调用处在同一个批次（batch）中。某个租户的深度思考提示词刚刚抢走了其他所有人的机会。

这就是队头阻塞（head-of-line blocking），它是推理模型进入流量组合后，破坏共享 LLM 推理的典型故障模式。这种模式并不新鲜 —— 存储系统和网络栈已经与之斗争了几十年 —— 但由于连续批次（continuous batching）和 KV 缓存固定（KV-cache pinning）的工作方式，它在 GPU 上呈现出一种特定的形态。大多数团队针对平均负载进行设计，却太晚才发现，一旦请求大小不再相似，“共享推理更便宜”就不再成立了。

团队向 AI 工作流添加人工审批的方式，与他们在代码库中添加 if (isDangerous) requireHumanApproval() 的方式如出一辙：将其视为一个二进制开关，在设计时检查一次，然后便将其遗忘。架构图上的指标是“人工监督”旁边的一个绿色对勾。而真正重要的指标——人工花费了多长时间、他们是否阅读了任何内容、在点击批准时该条目是否仍然相关——却很少有对应的仪表板。

将人工审批者视为二进制开关，你就等于在不知不觉中构建了一个队列。而队列具有动态特性：积压量的增长速度超过了你的员工配置速度、陈旧性使昨天的决定变得毫无意义、疲劳让审查变成了“走过场”（rubber-stamping），以及优先级倒置让真正重要的那一个决策被排在三百个无关紧要的决策之后。架构图中看不到这些，但它们都会出现在事故回顾（incident retro）中。

打开任何 2024 年时代的 AI 功能链路追踪 (trace)，模型调用就像是一头巨鲸。八百毫秒的生成时间，包裹在检索、鉴权和数据库查询组成的薄壳中，后者的时间几乎可以忽略不计。那一年的每一个架构决策——缓存、预取、流式 UX——都是为了隐藏那头“巨鲸”。

现在，查看运行在 2026 年推理栈上的相同功能的链路追踪。那头巨鲸已经变成了一只海豚。缓存后的预填充 (prefill) 在 180ms 内返回第一个 token。解码 (decode) 以每秒 120 个 token 的速度流式传输。模型不再是慢节点。你自己的基础设施才是，而且大部分基础设施还没有意识到这一点。

这种顺序重排是今年最重要的性能转变，也是各团队一直反应不足的一个。现在，AI 请求的 p99 底限是由特征存储 (feature store) 调用、鉴权中间件以及那些一直都很慢的 Postgres 查询决定的——在模型占据九成预算时，没人关心这些。

你的 LLM 调用耗时 2,340 毫秒。你的 APM Span 是这么记录的。这个数字是你可观测性堆栈中最昂贵的谎言，因为四种完全不同的故障模式都被渲染成了同一个不透明的紫色条块。长提示词下的 Prefill（预填充）浪涌。一个一小时没访问的租户导致的冷 KV 缓存。提供商连续批处理（continuous batching）中的“吵闹邻居”。一次无声的路由变更将你的流量导向了不同的区域。同样的 Span。同样的耗时。同样的 p99 告警。却是四个截然不同的复盘分析。

适用于微服务的分布式追踪准则 —— 每个网络跳数一个 Span、一个时长、几个标签 —— 在面对托管推理时失效了。LLM 调用并非单一实体。它是一个由多个阶段组成的流水线，每个阶段都有截然不同的扩展特性，运行在行为取决于队列中其他人的共享硬件上。将其视为一个单一且不透明的 Span，会导致你花费三天时间去调试“模型变慢了”，而实际上模型根本没变。

大多数团队在上线当天开启 JSON 模式，却从未衡量这背后的代价。这种假设合情合理：结构化输出能保证正确性，为什么不选它呢？答案是，严格的 JSON 模式约束解码通常会使数学、符号和多步分析任务的推理准确度降低 5–15%，而由于评估是在开启格式标志之前运行的，或者评估衡量的是可解析性而非质量，因此没人注意到这一点。

输出格式是一种解码时的约束，正如所有约束一样，它会扭曲模型的概率分布。当你查看日志时，这种扭曲是不可见的：JSON 有效，Schema 匹配，字段类型也对得上。你在日志中看不到的是模型本可以用散文形式产出的推理过程，但由于无法塞进你给定的语法中而消失了。“格式税”是真实存在的，在文献中已有详尽记录，但在生产环境中几乎普遍未被衡量。

这篇文章将探讨何时该支付这笔费用，如何在不必支付时及时止损，以及对于既想要结构化输出又想要准确性的工程师来说，格式选择的决策树究竟是什么样的。