778 篇博文 含有标签「llm」

你的 RAG 评估仪表盘显示为绿色。忠实度（Faithfulness）为 0.91，回答相关度（Answer Relevance）为 0.88，你花了两个迭代周期构建的 LLM-as-judge 评估框架显示系统运行良好。与此同时，一位用户刚刚问了一个问题，而答案就在你的检索器（retriever）从未提取出的文档中，你的模型写下了一个自信、结构清晰但完全没用的回答，内容与问题相关但风马牛不相及。评判员给了它高分。它读起来很顺畅。它基于模型 确实 获取到的片段。它只是用与用户需求无关的内容回答了一个错误的问题。

这是大多数团队评估检索增强生成（RAG）时存在的隐性结构缺陷：他们给文章打分，却从未检查学生是否拿到了正确的书。RAG 系统是两个连接在一起的机器——一个是决定 模型能看到什么 的检索器，另一个是决定 如何处理这些内容 的生成器。几乎生产环境中的每一个评估框架都只衡量第二个机器。第一个机器，也就是真正决定答案质量上限的那个，却在未经监控的情况下运行。

你的基础设施账单上的每一项其他支出都经过了审核。有人为数据库集群提交了采购订单。有人在购买可观测性 SaaS 之前清点了席位。有人在团队将 Kubernetes 占用空间翻倍之前进行了容量审查。然后，模型 API 出现了，而这一切都没有发生。

一名工程师将他们的 API 密钥添加到了配置文件中。他们写了一个 create() 调用，看起来与代码库中的其他函数调用完全一样。它上线了。而财务部门第一次得知这个功能作为一个成本中心存在，是在月度发票上的一个差异项——一个没人预测过、没人批准过、也没人能立即解释的数字。

这就是 AI 的 FinOps 鸿沟，它不是一个监控问题。它是一个披着监控外衣的治理问题。即使你拥有完美的仪表板，依然会感到惊讶，因为早在支出出现在图表上之前，它对你的审批流程就是不可见的。

一位队友提交了一个拉取请求（PR）。Diff 只有三个单词。一行变红了 —— Do not add information not present in the source.（不要添加原文中不存在的信息）—— 另一行变绿了 —— Make your best guess if the source is incomplete.（如果原文不完整，请做出最佳猜测）。改动很小，意图也合理，代码审查只用了 11 秒。你批准了它。一周后，你的客服机器人开始自信地编造根本不存在的退款政策，而你正在翻阅日志，试图查出幻觉率是从什么时候开始翻倍的。

Git Diff 完美地完成了它的工作。它准确地向你展示了哪些字符发生了变化。但它无法展示唯一重要的事情：这些字符背后的行为已经从“不确定时拒绝”变成了“不确定时编造”。对于代码，文本差异是行为差异的忠实代理 —— 将 < 改为 <=，审查者可以推断出后果。而对于提示词（Prompts），文本差异和行为差异几乎没有任何关系。

Demo 成功了。Beta 测试也通过了。接着，正式发布带来的流量是平时的十倍，直接撞上了你从未进行过压测的每分钟 Token 配额，而在产品最受瞩目的时刻，所有超出上限的用户都收到了 429 错误。

这是无人排练过的故障模式。团队会偏执地对自己的服务器进行压测——副本、连接池、数据库索引——然后将每个请求都路由到一个存在于别人账户中的供应商配额，而那个上限他们从未真正触及过。限流不是一个在 try 块中捕获的错误。它是一个硬性的产品约束，如果你没有围绕它进行规划，那么产品发布之时，就是你第一次发现坑在哪里的时刻。

没人会刻意决定给智能体 (agent) 配备 40 个工具。这就像车库堆满杂物一样自然而然地发生了。你接入一个搜索工具，然后是一个数据库读取器，接着团队里有人发布了 Slack 集成，然后又安装了 ticketing MCP 服务器，因为这只需要一行配置。每次添加在当时看来都是合理的。没人会移除任何东西，因为移除工具感觉就像是在剥夺能力，而剥夺能力感觉就像是一种倒退。

六个月后，你的智能体有了一个工具带，其中有三个它经常使用的工具，十几个偶尔使用的工具，以及二十多个在生产环境中技术上从未被选中的长尾工具。这种“长尾”并非免费，甚至代价高昂。目录中每一个未使用的工具都在主动降低智能体从那些重要工具中做出正确选择的能力。

有一种特定的争论，你只会和语言模型发生。你粘贴进代码。它把一个能运行的调用改写成了早在几个大版本前就不存在的形式。你纠正它。它道歉、表示同意，然后在下一轮对话中故技重施。你不是在对抗无知，而是在对抗一段对 不同 版本技术栈的、自信且经过充分排练的记忆——这段记忆被远超你纠正信息的训练样本所强化。

这就是我所认为的“与先验知识对抗”（fighting the prior）故障模式。模型的参数化知识——它在训练期间吸收的一切——包含了流行的、过时的，或者仅仅是与你实际使用的框架版本不同的内容。当你的上下文与它的先验知识发生冲突时，先验知识往往会胜出。与纯粹的幻觉不同，这种错误之所以危险，恰恰是因为它具有误导性的合理性：那个被弃用的 API 曾经是正确的，所以代码看起来没问题，能通过随意的阅读，甚至有时还能编译通过。

大多数团队在针对错误的层面进行威胁建模。他们加固了聊天框——速率限制、输入校验、监视用户输入内容的越狱分类器——却将模型读取的所有内容视为惰性的。Wiki 页面、支持工单、抓取的网页、日历邀请、某人上传的 PDF：在他们眼中这些只是数据，而不是指令。它们是供模型总结的背景材料，而不是让模型执行的命令。

这种假设本身就是漏洞。一旦你的 Agent 获取了内容并将其放入上下文窗口（Context Window），该内容的执行权限就与你的系统提示词（System Prompt）完全一致。在“这是你的指令”和“这是供参考的文档”之间没有权限边界。它们都只是 Token，而模型经过训练，会遵循出现在任何地方的指令。

演示在一周内惊艳了执行团队。十八个月后，它依然只是个演示。模型仍在沙盒中回答问题，幻灯片依然被循环用于新的路演，每个季度都有人问为什么还没上线。没有人能给出一个好的答案，因为真相往往令人不安：让所有人印象深刻的部分是廉价的部分，而没有人为昂贵的部分做过规划。

这就是“试点炼狱”（pilot purgatory），而它现在已成为默认的结局。MIT 的 NANDA 计划发现，大约 95% 的企业生成式 AI 试点项目未能对损益表产生可衡量的影响。IDC 和 Lenovo 统计了另一项指标——即那些字面上从未上线的 POC——将这一比例定为 88%：企业每启动 33 个概念验证，只有 4 个能进入生产阶段。放弃大部分 AI 计划的公司比例从 2024 年的 17% 飙升至 2025 年的 42%。这些故事的主角并非模型能力不足，而是没有人为其预留预算的“毕业差距”。

令人不安的事实是，一个可以运行的演示仅代表了在生产环境中运行该系统所需工作的 10%，但正是这 10% 看起来像完成了 100%。所有让 AI 系统能 安全运行 的要素——评估（evals）、护栏（guardrails）、可观测性、成本控制、安全审查、值班（on-call）以及拥有预算的负责人——在演示中是不可见的，但在生产环境中却是不可逾越的底线。

大多数团队购买推理资源的方式，就像他们的前辈在 2010 年购买 EC2 时一样：全部按需（on-demand），按 token 计费，且在两个维度上同时让人措手不及。账单是一个意外。速率限制（rate limit）是另一个——在发布的中途出现的 429 错误，就在你从未预留的按需资源池被其他同样选择支付零售价的人争抢时。然后有人打开定价页面，发现供应商一直都在悄悄销售预留容量：预置吞吐量（provisioned throughput）、承诺使用折扣（committed-use discounts）、按单位小时计费而不是按百万 token 计费。云计算行业花了十年时间才内化的预留实例决策，现在就摆在 token 面前，但几乎没有人移植这一套玩法。

这种现象的原因并非无知。而是你为计算资源学习的预留实例数学模型无法直接迁移，而它失效的方式恰恰是在惩罚那种天真的承诺。预留一个 EC2 实例是在赌你一年后仍然需要那种实例类型。预留一块 token 吞吐量则是在赌你一年后仍然需要 那个模型——而模型的生命周期是以月计算的，而不是以十年计算。承诺的结构很熟悉，但你所承诺的对象却并非如此。

有一句特定的短语应该让每一位工程主管立刻叫停会议：“只要模型变强，这就没问题了。”说这句话的人通常信心满满，有时还会配上一张展示能力曲线向上弯曲的幻灯片，而这几乎总是标志着路线图悄然从一份计划变成了某种预测。

这种区别比听起来更重要。计划是你所控制的一系列事情：你将编写的代码、你将构建的集成、你将运行的测试。预测是对你无法控制的事情的押注 —— 在这种情况下，是一个尚不存在的模型，它由一个从未承诺过交付日期的供应商按其时间表发布。当你围绕 “上下文窗口将翻倍” 或 “到第三季度推理能力将足够好” 来规划功能时，你并没有消除问题中最难部分的风险。你只是把它转移到了别人的发布日程表上，并宣称已经完成了。

在安全评审中，有人问道：“如何防止用户通过越狱来泄露系统提示词（system prompt）？”于是你添加了一个输入分类器。接着又有人问：“如果模型生成了有害内容怎么办？”于是你又增加了一个输出分类器。然后法务部门要求对个人可识别信息（PII）进行脱敏，RAG 团队想要进行可靠性（groundedness）检查。现在，原本只需要一次模型调用的用户消息，变成了需要四次。你的 p95 延迟翻了一倍，推理费用上涨了 40%，而那个原本感觉是秒开的演示 Demo，现在在屏幕显示内容之前有了明显的停顿。

这就是“护栏税”（guardrail tax），而且几乎没有人为此做预算。出于本能去“添加护栏”感觉是免费的，因为每一个单独的检查都很便宜，而且显然是有益的。但护栏的组合并不是免费的——它们堆叠在关键路径（critical path）上，每一个都是增加延迟、消耗 Token 的串行环节，并且成为了一个新的依赖项，可能宕机、触发限流，或者干脆判错。

诚实的讨论应该从承认这一点开始：护栏不是一个功能开关（feature flag）。它是强行加在第一个推理系统之上的第二个推理系统，它有自己的失效模式和自己的账单。以下是如何思考护栏的实际成本，以及如何在不支付高昂代价的情况下获得保护的方法。

这次升级看起来就像是白捡的便宜。供应商发布了一个更新的模型，它在每一项公开基准测试中的得分都更高，每个 token 的成本更低，且生成 token 的速度更快。你在一个配置文件里修改了模型字符串，运行了评估套件，看着 340 个测试用例全部变绿，然后在周二下午发布上线。到了周四，客服工单不断增加，却没人能指出到底是哪一个测试失败了。

这是应用层 LLM 开发中最令人困惑的失效模式，因为它违反了其他所有软件与你达成的契约：如果测试通过，行为就保持一致。在这里，该契约失效了。模型升级不是对一个你可控接口的库进行版本更新。它是一次对概率函数的无声、大规模更替，而你的评估套件只检查了你想到要写下来的那一小部分行为。

真正带来伤害的退化往往存在于你从未编码定义过的行为中——语气、冗余度、格式习惯，以及模型如何处理请求中模糊的中间地带。这些恰恰是你的用户所依赖的东西，也恰恰是 pass/fail 断言无法察觉的东西。