567 篇博文 含有标签「llm」

你AI系统健康仪表盘上最危险的指标，是99.9%正常运行时间旁边那盏绿灯。如果你第一次得知模型出问题是通过一张支持工单，那你拥有的不是可观测性——而只是感觉。

传统APM工具构建于一个二元故障的世界：请求要么成功，要么失败。对于LLM驱动的功能，这个模型彻底失效。一个请求可以在300毫秒内完成，返回HTTP 200，消耗token，给出一个自信却完全错误、毫无帮助、或比六周前悄然退化的答案。这些故障状态没有一个会触发你现有的告警。

研究持续表明，延迟和错误率加在一起，覆盖的LLM功能故障空间还不到20%。另外80%隐藏在五种故障模式中，大多数团队只有在用户已经注意到之后才会发现。

AI 工程中最昂贵的架构错误不是选错了模型，而是选错了交互范式。本该构建 Agent 的团队花了六个月打磨一个聊天机器人，然后困惑地发现用户什么事也办不成。本该构建 Copilot 的团队接入了完全自主的 Agent，结果用整个季度来扑灭未授权操作和失控成本引发的各种火。

这套分类学在你写下第一行代码之前就至关重要，因为聊天机器人、Copilot 和 Agent 有着根本不同的信任模型、上下文窗口策略和错误恢复需求。选错了不只是产品变差——而是产品无法通过调提示词或换模型来修复。

一家加拿大航空公司的支持聊天机器人凭空捏造了一项根本不存在的丧亲票价政策。该机器人表现得非常自信、格式规范且彬彬有礼。乘客们相信了它。法院随后判定航空公司应对这一虚假政策负责。与此同时，该聊天机器人的满意度评分可能还相当不错。

这就是隐式反馈陷阱。大多数团队用来衡量 AI 质量的信号——点赞评级、点击率、满意度评分——不仅充满噪点。它们还在衡量错误目标方面存在系统性偏见。而针对这些信号进行优化，只会让你的 AI 变得更糟。

大多数构建 LLM 应用的团队在第三周左右都会发现同样的问题：每次有人运行测试套件时，它都会发起实时 API 调用，消耗真金白银，耗时 30 多秒，且每次运行返回的结果都不尽相同。在原型阶段感觉良好的“直接调用 API”方法，现在变成了迭代速度的沉重负担——而且是账单上的一项重要支出。一个工程团队审计了他们每月的 API 支出，发现 2,847 美元中有 1,240 美元（43%）是由于开发和测试流量不必要地访问实时端点而产生的纯粹浪费。

解决方案不是停止测试，而是从一开始就构建正确的开发循环——让快速路径既便宜又具有确定性，而将慢速路径（真实的 API 调用）留给真正需要的时刻。

大多数构建 LLM 流水线的团队几乎立刻就会选择链式架构。复杂任务被拆分为多个步骤——提取、分类、摘要、格式化——每个步骤都有自己的提示词。这感觉很自然：更小的提示词更容易编写、调试和迭代。但很少有人会问：链式调用真的比在一次调用中完成所有工作更准确吗？在我见过的大多数代码库中，没有人测量过。

单体 vs. 链式的权衡是 AI 工程中最关键的架构决策之一，但几乎总是凭直觉做出的。本文将梳理实证依据，说明分解何时真正有帮助、何时会悄然使事情变得更糟，以及在生产环境中需要关注哪些信号。

当 Anthropic 去年废弃一个 Claude 模型时，一家公司察觉到了——但这仅仅是因为下游解析器在生产环境中开始报错。罪魁祸首？新模型偶尔会将其 JSON 响应包裹在 Markdown 代码块中。旧模型从不这样做。没人记录过这一假设，也没人对此进行过测试。修复只花了一个下午；诊断却花了三天。

这种模式——无声的行为依赖在生产环境中“震耳欲聋”地崩盘——是模型迁移中典型的失败模式。你更新了模型 ID，跑了一个简单的冒烟测试（sanity check），然后发布。六周后，一些细微的问题出现了。你的 JSON 解析失败率提高了 0.6%。边缘情况下的拒绝率翻了一番。你的结构化提取漏掉了一个以前能可靠填充的字段。差异不在代码中——而在模型的行为中，而你从未为此编写过契约（contract）。

随着主要供应商现在的废弃周期缩短至 60–180 天，且模型发布的速度在加快，这已不再是一个理论上的担忧。这是一个周期性的运营挑战。以下是如何提前应对的方法。

某中型 SaaS 公司的团队六个月前部署了一套模型路由器，目标明确：不再为 70% 的简单查询和格式转换任务支付前沿模型的高昂费用。他们运行了三个月，直到有人做了一道算术题。总推理成本上涨了 12%。

路由器本身并不贵——一个轻量级分类器，每个请求增加约 2ms 的开销。但分类器的决策边界校准有误：它将 60% 的查询升级到了昂贵模型，而非预期的 30%。那 40% 在本地处理的请求质量较差，导致用户重试率上升，进而拉高了总请求量。路由器的遥测数据显示"路由运行正常"，因为它确实在路由——只是路由得不好。

这种失败模式远比成功案例更为普遍。以下是如何构建真正能省钱的路由系统。

大多数团队选择 LLM 的方式，和十年前选数据库一样：看一张对比表，挑出最关心那一列得分最高的，然后开始构建。六个月后，他们要么在迁移，要么疑惑为什么评估结果和用户实际体验截然不同。基准没有错——只是模型选错了。

错误不在于选了错误的模型，而在于还没搞清楚自己的生产任务分布就急着选模型。基准测试的是别人认为重要的东西；你的生产系统有完全不同的分布。这两件事根本不是一回事。

大多数尝试使用 RLHF 微调语言模型的团队在开始之前就放弃了。典型案例是 OpenAI 的 InstructGPT：33,000 个偏好对、13,000 个有监督演示、一个专门的外包团队，以及一个需要数周时间才能稳定的强化学习流水线。如果这就是门槛，那么大多数产品团队根本玩不起这个游戏。

他们错了。现在的门槛已经没那么高了。2024–2025 年的研究共识已经悄然改变：数据质量胜过数据量，DPO 完全取代了 RL 基础设施，而最有价值的偏好信号其实已经流经你的产品，只是未被记录。看起来是研究团队的问题，实际上是埋点（instrumentation）问题。

一个银行助手正在处理一段客户支持对话。消息中嵌入了指令——由于是以零不透明度的白色文字渲染的，因此不可见——要求智能体绕过交易验证步骤。智能体照做了。当异常情况在日志中浮现时，已有 250,000 美元被转移到了客户从未接触过的账户中。

这并非凭空虚构的场景。它发生在 2025 年 6 月，精准地展示了为什么提示词注入（Prompt Injection）是生产级智能体 AI（Agentic AI）中悬而未决的最难问题。与仅生成文本的聊天机器人不同，智能体（Agent）会采取行动。它会调用工具、发送电子邮件、执行代码并发出 API 请求。当它的指令被劫持时，影响范围（blast radius）不再是一句糟糕的话，而是机器速度下的未经授权的操作。

根据 OWASP 2025 年 LLM 应用十大安全风险，提示词注入现在被列为排名第 1 的关键漏洞，出现在安全审计评估的 73% 以上的生产级 AI 部署中。每个构建智能体的团队都需要一个连贯的威胁模型和防御架构，且这种架构不能以安全之名让系统变得毫无用处。

问任何一个 AI 工程团队是否测试了他们的提示词，他们都会说"是的"。再问一句：一个有问题的提示词能否让 PR 失败并阻断合并？房间里会安静很多。对大多数团队而言，诚实的答案是否定的 —— 他们偶尔会跑一些评估笔记本，也许有一份记录已知提示词问题的共享 Notion 文档，以及一种模糊的感觉：事情比以前更糟了。那不是测试，那是在碰运气。

这个差距的存在，是因为提示词测试在感觉上与单元测试有本质区别。代码要么行为正确，要么不正确。提示词的输出处于一个连续谱上，输出是非确定性的，而且运行足够多的样本以建立信心会花费真金白银。这些都是真实的约束，但没有一个是无法克服的。那些建立了真正阻断合并的提示词 CI 的团队，并不是在每次构建上花费五十美元 —— 他们在三分钟以内、花费不到一美元的情况下完成运行，这得益于几个让这个问题变得可处理的设计决策。

大多数工程师将 LLM 质量回归视为提示词工程问题或模型能力问题。他们会重写系统提示词、尝试更新的模型，或添加少样本示例。他们很少检查每次 API 调用顶部静静躺着的三个数字：temperature、top-p 和 top-k。但这些默认值正在悄然改变模型产出的每一个响应，错误的调参会导致输出方差——团队往往数月内都把锅甩给模型，直到意识到罪魁祸首不过是一个从未动过的配置值。

这不是入门教程。如果你在生产环境中运行 LLM——用于信息抽取管道、代码生成、摘要，或任何输出流入真实系统的任务——以下是你在智能调参之前必须理解的机制与权衡。