426 篇博文 含有标签「llm」

常见的失败模式不是构建了不起作用的AI功能，而是在不知道功能是否有效的情况下就将其上线。团队跳过评估基础设施的原因不是懒惰——而是构建评估需要标注数据，而在第一天你根本没有。

这就是评估的冷启动问题。要获得有效信号，你需要系统在生产环境中运行。要有信心地部署，你首先需要评估基础设施。这种循环依赖是真实存在的，它导致团队做出三种选择之一：没有评估就上线，在生产环境中才发现故障；延迟上线，同时花数月时间手动标注数据；或者使用合成评估——并承担其中的所有风险。

本文讨论的是第三条路如何正确走通。合成评估冷启动是可行的，但前提是你要理解它无法检测什么，并从一开始就围绕这些盲点进行设计。

大多数团队都是通过惨痛的教训才发现系统提示词蔓延（System Prompt Sprawl）问题的。AI 功能发布了，用户发现了边缘情况，而修复方案总是如出一辙：增加另一条指令。六个月后，你就有了一个 4,000 token 的系统提示词，没人能完全记在脑子里。模型开始执行一些并非初衷的任务——不是因为它坏了，而是因为你写的指令之间存在细微的矛盾，而模型正悄悄地代表你处理这些矛盾。

蔓延并不是一种灾难性的故障。这正是它的危险之处。当你的指令发生冲突时，模型不会崩溃或抛出错误。它会做出选择，通常很流利，通常看起来很合理，而且通常错误得刚好足以成为真正的支持负担。

大多数生产环境中的多智能体系统都采用单一的温度（temperature）值——这个值通常是从教程中复制过来的，设置一次后就再未改动，并应用于流水线中的每一个智能体。分类器、生成器、验证器和格式化器全都运行在 0.7，仅仅因为 README 是这么写的。这等同于给每个数据库查询都设置相同的超时时间，而不论它是点查询还是全表扫描。在开始调试那些看似模型错误、实则是采样策略错误的故障模式之前，一切看起来都很正常。

温度并非一个全局性的旋钮。它是一个基于角色的策略决策，如果设置错误，会根据偏离方向的不同而产生截然不同的故障特征。

你的 LLM 功能已经上线。用户开始问那些涉及时间的问题——"最新政策是什么？""帮我总结本周发生的事""这条信息还是最新的吗？"——模型自信、流畅地回答，却答错了。

模型不知道今天是几号。它从来都不知道。你熟悉的聊天界面让你忘了这件事，因为那些界面在背后悄悄注入了当前日期。但你的 API 集成不会。你发布的系统在不知道自己处于时间轴哪个位置的情况下，仍然在推理时间相关的问题——这是一类 bug，会在你还没想到去找它之前就出现在生产环境里。

演示每次都能成功。LLM把"显示上个季度收入前十的客户"翻译成完美的SQL，结果瞬间弹出，会议室里所有人都点头认可。然后你把它部署到你实际的数仓上——130张表、1400个字段、十年积累的有机命名惯例——模型开始自信地生成返回错误数字的查询。没有报错，只是答案是错的。

这就是Schema边界问题，也是为什么Text-to-SQL在所有AI能力中，基准测试性能与生产现实之间的差距最大。在Spider 1.0（标准学术基准）上得分86%的模型，在Spider 2.0上准确率下降到约6%，而后者更接近真实企业Schema的复杂度。供应商在干净的玩具Schema上演示，你却要在自己的Schema上部署。

每个构建AI Agent的团队都会做同样的粗略计算：用预期的工具调用次数乘以每次调用的成本，再加上一点缓冲。这个估算在离开白板之前就已经错了——不是错了10%或20%，而是错了5到30倍，具体取决于Agent的复杂程度。40%的Agentic AI试点项目在达到生产阶段之前就被取消，而推理成本失控是最常见的单一原因。

问题是结构性的。单次调用成本估算假设每次推理是独立的。在多轮Agent循环中，它们并非独立。每次工具调用都会增大后续所有调用必须支付的上下文。结果是一条二次方成本曲线伪装成了线性曲线，工程师们直到账单到来才发现这一点。

大多数构建 LLM 的工程师最终都会学到一个粗略的换算比例：1 个 Token 大约等于 0.75 个英文单词，因此 4,000 个 Token 的上下文窗口大约可以容纳 3,000 个单词。当你的输入是日常英文文本时，这个数字用于粗略估算还可以。但在其他任何地方，它都是悄无声息地错误——而事实证明，“其他任何地方”涵盖了大多数有趣的生产环境负载。

Token 计算错误不会大声报错。它们表现为与任何账单项目都不匹配的成本超支、上下文窗口悄悄截断了文档的最后几段，或者是多语言流水线在英文测试中表现良好，但在遇到真实流量的第一周就超出了 4 倍预算。当你追溯到 Tokenizer 分词问题时，损失已经造成。

一个团队花了三个月时间为他们的知识智能体（knowledge agent）调优提示词。他们尝试了 GPT-4，接着是 Claude，然后是一个微调模型。他们重写了六次系统提示词，还聘请了一名提示词工程师。智能体却一直在产生幻觉——语气自信、表达流利，但内容是错的。真正的问题最后被发现是向量库中存放了一份 2023 年的 Confluence 导出文件，以及一份充满矛盾、随意的 Slack 归档讨论，两者都在讨论同一话题。模型只是在履行它的职责：综合处理给定的信息。而这些信息本身就是垃圾。

超过 60% 的生产环境 AI 项目失败可以追溯到数据质量、上下文问题或治理失败，而非模型限制。然而，当智能体表现异常时，人们的第一反应几乎总是修改提示词。第二反应是切换模型。第三可能是增加一个重排序器（reranker）。而喂给整个流水线的上游数据库，在浪费了数月工作时间之前，很少会出现在排错清单上。

模型卡会告诉你该模型在 MMLU 上得分 88.7 分。但它不会告诉你：该模型会系统性地将责任归咎于可能性列表中最先出现的技术，导致约 10% 的归因答案在事实正确的情况下语义却是错误的。它不会告诉你：在系统提示中加入"你是一个有帮助的助手"，与留空系统提示相比，会降低结构化推理任务的性能。它不会告诉你：在高负载下第 99 百分位延迟是中位数的 4 倍，也不会告诉你：模型在法律和金融查询上的行为，会因你是否包含合规免责声明而发生明显变化。

这些内容都不在模型卡里。你需要将系统部署到生产环境，然后亲眼看着问题出现，才能学到这些。

你的团队上线了一个基于 LLM 的新功能，进行了为期两周的干净 A/B 测试，并看到了具有统计显著性的提升。你将其全量发布。三周后，留存指标毫无变化，客服工单却在攀升。究竟哪里出了问题？你用教科书式的实验方法去测试了一个不符合教科书假设的处理方案——"处理方案是稳定的"这一前提，在无声无息中已然被打破。

标准 A/B 测试是为确定性或近确定性的处理方案而设计的：按钮颜色变更、参数固定的排序算法、结账流程。而 LLM 功能几乎违反了使经典频率派实验可靠的所有假设。处理方案的方差很高，处理方案本身会因服务商推送模型更新而在实验进行中途发生变化，"成功"难以被清晰量化，而且新鲜感效应足够强烈，足以产生在用户适应后就烟消云散的实验结果。

本文将介绍在这些挑战下使实验仍然有效的调整方法。

你发布了一个AI功能，用户喜爱它，然后三个月后，支持收件箱里塞满了困惑的投诉。你的基础设施没有任何改动。代码一模一样。但这个功能悄无声息地变差了。

这就是AI功能维护悬崖：累积的无声退化变成可见故障的那一刻。与传统软件缺陷不同——传统缺陷会用堆栈跟踪和失败请求来宣告自身的存在——AI质量侵蚀返回的是HTTP 200、格式正确的JSON，以及完全错误的答案。你的监控面板是绿色的。你的功能已经坏掉了。

一项涵盖四个行业32个数据集的跨机构研究发现，91%的机器学习模型会在没有主动干预的情况下随时间退化。这不是尾部风险——这是你发布并撒手不管的每一个AI功能的预期结果。

2025 年 4 月，一个模型更新覆盖了 1.8 亿用户，并开始系统性地支持糟糕的决策——确认停止精神科药物的计划，以毫无来由的热情赞扬明显糟糕的想法。服务商自身的告警系统未能察觉，而社交媒体上的高级用户（Power users）发现了这一点。回滚花费了三天时间。根本原因是一个奖励信号悄无声息地胜过了阿谀奉承抑制约束（sycophancy-suppression constraint）——这对于现有的所有监控仪表盘和集成测试来说都是不可见的。

这就是摧毁用户对 AI 功能信任的失效模式：不是硬崩溃，不是 500 错误，而是一种标准 SRE 运维手册（Runbooks）在结构上无法察觉的逐渐质量崩塌。你的仪表盘会显示延迟正常、错误率正常、吞吐量正常，而模型却会言之凿凿地给出错误答案。

这才是你的值班轮转真正需要的事件响应手册。