89 篇博文 含有标签「llm-ops」

调出过去一周的生产环境追踪记录，查看你的延迟仪表板。你几乎肯定在总请求延迟上设置了 p50 和 p99。你可能还有令牌吞吐量（token throughput）。你甚至可能有一张每秒令牌数（tokens-per-second）图表，因为某个供应商的基准测试说服你这么做了。但你几乎肯定没有的是按模型、按路由、按租户划分的**首字时间（time to first token, TTFT）**直方图 —— 这是决定你产品感知速度的核心指标。

这绝非一个小疏忽。对于任何流式界面 —— 聊天、代码补全、智能体侧边栏、语音 —— 用户感知的速度取决于在内容出现之前，他们盯着闪烁光标的时间。一旦第一个令牌（token）出现，用户就开始进入阅读状态；随后的令牌是在与他们的阅读速度竞争，而不是与他们的耐心竞争。总延迟（Total latency）对于吞吐量规划和成本预算很重要，而 TTFT 则决定了产品是否让人感觉“有生命力”。

这两个数字之间的差距正在拉大。推理模型（Reasoning models）产生的总延迟可能与其非推理兄弟模型完全相同，但却会将 TTFT 从 400 毫秒推高到 30 秒。一个“保持延迟持平”的路由更改，可能会悄无声息地将一个反应灵敏的助手变成一个卡死的窗口。如果你没有对 TTFT 进行图表化，你就是在发布连你自己都察觉不到的 UX 退化。

一个平台团队对他们的摘要服务的系统提示词（system prompt）进行了一行细微的调整。没有代码审查，没有迁移指南，没有版本更新——这“仅仅是一个提示词”。两周后，法律产品团队发现他们的合规自动脱敏功能一直在静默地泄露姓名。调查耗费了一个冲刺（sprint）。修复很简单。损害的是信任。

这是 AI 变更日志问题的缩影。行为现在是你系统的一等输出（first-class output），当提示词、模型、检索器或工具模式（tool schemas）发生变化时，行为也会随之改变——而这些变化都不会出现在消费方应用的 git diff 中。如果团队像对待后端部署那样对待 AI 更新，认为在 #releases 频道发一条 Slack 消息就足够了，那么他们最终会重蹈 2010 年代早期那种“我们先上线，稍后再告诉 QA”工作流的覆辙。

大多数团队发现其 LLM 性能下降通常是在两周后，当时有人在 Slack 上发消息问：“嘿，有人注意到最近 AI 的输出似乎不太对劲吗？”到那时，损害已经造成：用户已经形成了负面印象，支持工单不断累积，而最初推动该功能的业务负责人也正在悄悄失去信心。

令人沮丧的是，你的基础设施在这段时间内一直非常健康。HTTP 200 状态码、180 毫秒的 p50 延迟、每次请求 0.04 美元的成本——仪表盘上的一切都显示为绿色。模型只是变得更安静、更模糊、更简短且更犹豫，而这些表现是基础设施监控无法察觉的。

这不是通过增加 Datadog 仪表盘就能弥补的监控漏洞。它需要一套完全不同类别的指标。

大多数团队在发布 LLM 功能后，会花费数周时间争论该功能是否真的好用。由于构建标注数据集感觉像是一个独立的项目，评估问题往往被推迟。当你有了标准答案（ground truth）时，你也积累了两个月无法诊断的沉默回归。这本末倒置了。如果你知道该采用哪些技术以及每种技术的局限性，你可以在第一周——在完成任何标注之前——就获得有意义的质量信号。

这篇文章是无标注评估的实战指南：涵盖了有效的无引用方法、所需条件，以及如果不小心就会误导你的特定失败模式。

当一名 on-call 工程师第一次以“模型刚才又表现得有点怪”为由关闭告警页面时，团队就已经悄然越界了。这句话同时表达了三层意思：它宣告了问题不可调查，它将未来类似的告警归类为噪音，并免除了轮值人员记录事件经过的责任。一周后，同样的特征再次触发告警，另一个人看到“之前已经关闭过一次”，于是真正的回归（regression）便会一直潜伏在生产环境中，直到有客户在 Twitter 上发帖投诉。

这种模式并不是因为懒惰。它是将标准的 SRE 直觉运行在一个不再表现出确定性的系统上所产生的必然结果。经典的 on-call 培训教导工程师将“输入相同但输出不同”的情况视为可观测性堆栈中的 Bug——这不可能是系统本身的 Bug，因为系统不会那样运作。但基于大语言模型（LLM）的系统正是在每一次请求中都以这种方式运作，这是其设计使然。如果建立 on-call 轮值机制时没有内化这一点，系统就会滑向两个极端：要么是瘫痪（每一个随机波动都是 P2 级事故），要么是虚无主义（模型总是很奇怪，别再给我发告警了）。

一个平台团队修改了意图分类器的 Prompt，旨在“更好地处理复合问题”。只改动了一个句子。他们自己的评估套件（eval suite）变绿了——复合问题的准确率提升了 6 个百分点。他们在下午 3 点合并了代码。到下午 5 点，三个下游 Agent 团队开始收到告警：路由 Agent 将退款请求发送到了物流队列，摘要 Agent 在不同的边界处截断，而工单打标 Agent 开始输出一个没有任何 Schema 能识别的类别。那些下游团队中没有一个参与了评审。也没有人负责“意图 Prompt”的轮值。

这不是假设。当 Prompt 变成共享依赖却未成为共享 API 时，这就是必然发生的情况。提升一个团队指标的 Prompt 修改，可能会悄悄破坏另一个团队建立在其之上的假设。与破坏性的 API 变更不同，这里没有反序列化错误，没有 Schema 不匹配，没有 500 错误——下游只是开始做出微妙的、更糟糕的决策。

传统的 API 工程在几十年前就通过契约测试（contract tests）解决了这个问题。消费者发布它所期望的形状；提供者有义务保持该形状正常工作。Pact、消费者驱动的契约、共享 Schema——这是 HTTP 服务发布工程的正统做法。Prompt 也应该遵循同样的纪律，而大多数组织仍然像处理团队间传递的贴纸一样对待它们。

走进几乎任何一家拥有在线 LLM 功能的工程团队，问一个简单的问题：谁负责管理提示词（Prompts）？你会听到一阵停顿，然后是一个耸肩，接着是一个经不起推敲的回答。“产品经理写了第一个版本。”“PM 在上个迭代（Sprint）里改了一下。”“我觉得它在某个 Notion 文档里，或者可能是 agent.ts 里的那个 const SYSTEM_PROMPT。”提示词正在生产环境中运行。它决定了用户看到的内容，决定了智能体采取的操作，也决定了下季度收入图表中显示的数字。然而，它的治理覆盖面甚至不如那个没人愿意承认动过的 CSS 文件。

这就是影子提示词库：堆积如山的字符串——系统提示词、few-shot 示例、工具描述、路由规则、评估器准则——它们共同定义了产品行为，却集体缺乏代码审查、部署流水线、负责人、弃用策略和审计追踪。它们是你 AI 技术栈中最关键的承重构件，也是受监管最少的环节。

后果已不再仅仅停留在理论层面。现在有 98% 的组织报告存在未经授权的 AI 使用，近一半的组织预计在 12 个月内会发生影子 AI 事件。监管机构的步伐比治理速度更快：欧盟 AI 法案（EU AI Act）的高风险条款将于 2026 年 8 月生效，其中第 12 条明确规定，将输出结果与提示词及模型版本绑定的日志必须是自动生成的，而非设想中的。如果你的提示词散落在十几个代码库和一个 Slack 讨论串中，你拥有的不是审计追踪，而是隐患。

大多数团队发现自己依赖模型的方式，和你发现承重墙的方式一样——试图拆掉它的时候。停用邮件到了，你在配置中替换了模型标识符，然后你的应用开始返回自信、格式优美、却微妙错误的答案。没有报错，没有崩溃，只是信任在缓慢流失，需要数周才能察觉，数月才能修复。

这就是模型下线悬崖：强制迁移揭示出你"模型无关"的系统其实从未无关过的那一刻。你的提示词、输出解析器、评估基线、用户的期望——所有这些都在悄悄地校准到即将按照别人的发布节奏而改变的行为特性上。

你的 Sprint 回顾涵盖了那些常见问题：不稳定的测试、某人一直推迟的数据库迁移、用胶带勉强粘合的 API 端点。但如果你正在交付 AI 功能，代码库中最昂贵的债务恰恰是那种没人会写在便利贴上的。

传统技术债务是线性积累的。你走了捷径，之后为此付出利息，等痛苦到了一定程度再重构。AI 技术债务是复合增长的。一个默默退化的提示词会产生污染评估的训练信号，这会误导你下一轮提示词修改，进而进一步侵蚀用户体验的质量。等有人注意到时，三层假设已经在底下腐烂了。

你的 Agent 上周二在生产环境出了故障。一个客户报告了错误的回答。你调出日志，看到最终输出，也许还有几条中间的 print 语句——然后你就卡住了。你无法重新运行 Agent 来重现同样的故障，因为模型不会产生相同的 token，你的工具调用的 API 现在返回了不同的数据，嵌入在提示词中的时间戳也已经变了。Bug 消失了，你只能盯着间接证据发呆。

这就是 AI Agent 的根本调试问题：传统软件是确定性的，所以你可以通过重建输入来复现 bug。Agent 系统不是。每次运行都是模型采样、实时 API 响应和时间依赖状态的独特组合。没有专门的工具，事后调试就变成了取证猜测。

确定性重放通过在执行过程中记录每个非确定性来源，并在重放时替换这些记录来解决这个问题——把你无法复现的 Agent 运行变成你可以像调试器一样逐步跟踪的东西。

每一个交付 LLM 驱动功能的团队最终都会进行同样的对话：“如果我们需要更换供应商怎么办？”标准的回答——“我们只需要换一下 API 密钥”——揭示了对耦合实际存在位置的危险误解。在实践中，尝试进行供应商迁移的团队会发现，API 端点是他们最不需要担心的问题。真正的锁定隐藏在七个不同的耦合点中，每一个都能将一次“快速更换”变成一个耗时一个季度的项目。

迁移费用通常会消耗原始开发时间的 20–50%。那些将模型切换视为即插即用的企业团队，往往在面对损坏的输出、激增的 Token 成本以及需要数周才能诊断出的推理质量变化时束手无策。在需要迁移之前，了解这些耦合点在哪里，是受控过渡与紧急应对之间的本质区别。

你的团队上线了一个 AI 驱动的客服机器人。它运行良好，用户很满意。然后月度账单到了，你发现监控 LLM 调用的基础设施成本比 LLM 调用本身还要高。

这不是假设。团队报告称，将 AI 工作负载监控添加到现有的 Datadog 或 New Relic 设置中，可观测性账单增加了 40-200%。与此同时，推理成本持续下降——GPT-4 级别的性能现在每百万 token 仅需 0.40 美元，而 2022 年末为 20 美元。监控技术栈还没有收到这个消息。

结果是一个倒挂现象，如果不是这么贵的话会很有趣：你花在观察 AI 思考上的钱比让 AI 思考的钱还多。