567 篇博文 含有标签「llm」

当某家供应商宣布停用一个广泛使用的模型版本时，工程论坛上涌现出了告别帖子、请愿书和由用户撰写的迁移指南——这些用户的日常工作流都围绕着某个特定模型的行为指纹而构建。这不是软件弃用通常的走向。当你从 UI 中删除一个按钮时，用户会感到恼火。当你删除一个他们已经依赖的 AI 功能时，他们会感到失落。

这种不对称揭示了一个重要事实：弃用一个 AI 驱动的功能，从根本上比弃用传统功能更难。LLM 的行为包络——其语气、延迟特征、格式化倾向、响应长度——与功能的实际输出同样关键。用户不仅依赖 AI 做什么，更依赖它如何做。如果你的下架计划把 AI 退役当成 API 端点退役来处理，你将为这种错配付出流失代价。

大多数需要结构化LLM输出的团队都遵循同一套方案：写一个提示词说"只返回有效的JSON"，解析响应，运行Pydantic验证，失败则附上错误信息重试。这种方式在大多数情况下能用，但在生产环境中恰恰会在最糟糕的时刻失效——高负载、边缘用例输入，以及指令遵循不如GPT-4可靠的低成本模型。

语法约束生成是一种根本不同的方法。它不是礼貌地请求模型然后事后检查，而是从数学上让结构无效的输出成为不可能。模型无法输出缺失的括号、不存在的枚举值或遗漏的必填字段——因为这些token在采样前就被过滤掉了。不是不太可能，而是不可能。

大多数团队跳过了这个方法，但不应该。

大多数招聘 LLM 岗位的工程团队进行的面试大同小异：两轮 LeetCode，一个系统设计问题，可能还有一个关于 Transformer 内部机制的小测验。他们考核的重点不对 —— 而且他们自己也知道。那些在这些筛选中表现优异的候选人往往难以交付实际可用的 AI 功能，而那些在二叉搜索上栽跟头的候选人却能从零开始构建一个评估套件，并在一个下午内调试好一个产生幻觉的流水线。

能预示在 LLM 工程领域取得成功的技能，与传统机器学习或软件面试所测试的内容几乎没有交集。尚未更新招聘流程的招聘经理正在产生大量的漏选（false negatives）—— 拒绝了本可以成功的工程师 —— 而误选者（false positives）则带着扎实的 LeetCode 分数步入公司，却对模型何时在自信地胡说八道毫无直觉。

你发布的每一个 AI 功能，在成为产品决策之前，都首先是一个架构选择：这个模型调用是发生在用户的请求链路中，还是在用户无需等待的地方运行？这个选择通常由编写第一个原型的人做出，之后便不再被审视，并默默地决定了该功能在余下生命周期中的 p99 延迟。当事后分析（Post-mortem）询问为什么生产环境仪表盘在每周一上午 10 点变得无法使用时，答案几乎总是：某些本应属于冷路径（Cold-path）的东西被焊死在了热路径（Hot-path）中——而在 p50 时表现良好的模型，在流量扇出（Fan out）时，其 p99 的表现会变得极具灾难性。

热路径与冷路径的区别比 LLM 还要早。CQRS、流式架构、Lambda 架构——它们都在“必须立即响应”和“可以最终送达”之间划定了相同的界限。AI 工作负载的不同之处在于，走错方向的代价比以前高出了一个数量级。一个耗时 50 ms 的同步数据库查询变成 200 ms 是一次回归（Regression）。而一个在 p50 时耗时 1.2 秒的同步 LLM 调用在 p99 时变成 11 秒，则是你无意中做出的一项商业决策。

你的 LLM 供应商 SLA 涵盖了 HTTP 正常运行时间和首个 Token 到达时间。但它对于模型下个月是否仍会遵从你的格式化指令、是否会拒绝上周还能接受的请求、或者在你未测试的边缘条件下能否返回有效 JSON，只字未提。大多数工程团队是通过生产环境事故才发现这一点的——而非通过更新日志。

这就是隐性 API 契约问题。传统 API 承诺稳定、有据可查的行为；LLM 供应商只承诺一条连接。从请求发出到应用处理响应之间发生的一切，都由你自己负责。

当你给 Agent 一份 50 个工具的列表，让 LLM 自行决定调用哪个时，准确率大约在 94% 左右。还算合理，可以上线。但当这份列表增长到 200 个工具——这比任何人预期的都要快——准确率就会跌至 64%。到 417 个工具时，命中率只剩 20%。到 741 个工具时，更是跌落至 13.6%，与随机猜测在统计上没有区别。

解决方案是一种大多数团队跳过的模式：在工具分发之前运行意图分类层。不是取代 LLM，而是在它之前。分类器缩小工具命名空间，让 LLM 只看到与用户实际意图相关的工具。LLM 的推理能力保持完整，只是在一个经过筛选的相关子集上工作，而不是在一个不断膨胀的大海捞针中。

本文解释为什么团队会跳过这一步、跳过后代价几何，以及如何正确构建这个层——包括让其随时间持续优化的反馈循环。

一个安全模型在公开基准测试集上取得了 85.3% 的准确率。当研究人员用并非来自公开数据集的新型对抗性提示进行测试时，这个数字跌至 33.8%。该模型并未真正学会如何推理安全性，而是学会了识别评估数据分布。

这就是合成评估数据核心问题所在：当同一个模型家族既生成训练数据又生成测试用例时，通过评估意味着符合某个共同的统计先验，而非真正展示能力。这是一个看起来像质量保证的反馈循环，直到生产流量到来，数字对不上号才会暴露问题。

这种失败是结构性的，而非偶然的。修复它需要的不仅仅是增加更多合成样本。

Most RAG 的实现都以同样的方式失败：向量搜索检索到了看起来合理但并非用户真正需要的内容，LLM 用自信的辞令对其进行包装，最终用户得到一个大体正确但细节错误的答案。令人沮丧的是，这种失败模式是隐形的 —— 余弦相似度分数看起来很正常，检索到的片段也提到了正确的主题，但答案仍然是错的，因为问题需要跨关系进行推理，而不仅仅是语义上的接近。

向量嵌入 (Vector embeddings) 擅长一件事：找到听起来 像 你查询内容的文本。这是一种强大的能力，涵盖了极广的生产用例。但当问题取决于实体之间如何 连接（而非它们的描述有多匹配）时，这种方式就会出现可预见的失效。对于这类查询，知识图谱 —— 一种你可以通过 Cypher 或 SPARQL 遍历的属性图 —— 不仅仅是一种优化。它是一种从根本上不同的检索方式，解决的是另一类问题。

你的模型说“我非常有信心”，但 40% 的时间都是错的。这不叫幻觉——这是校准失败，而且在生产环境中，这是一个更难检测、衡量和修复的问题。

幻觉占据了所有媒体头条。但过度自信的错误答案往往更危险：模型以极高的表达置信度生成一个看似合理、流利的回答，而下游消费者完全收不到任何异常信号。幻觉检测器、RAG 依据性检查和事实核查流水线都有助于处理凭空捏造的内容。但对于模型知道事实却对其确定性存在系统性错误校准的情况，这些手段几乎无能为力。

大多数发布基于 LLM 功能的团队都将置信度视为事后才考虑的事情。这篇文章将探讨为什么校准会失败、如何衡量它，以及在生产环境中真正能改善这一指标的设计模式。

一家医疗初创公司从某个主流前沿模型迁移到了同一供应商提供的新版本。结果是：为了恢复功能对等（feature parity），耗费了 400+ 个工程小时。新模型每次响应生成的 token 数量是原来的五倍，抵消了预期的成本节省。它开始提供未经请求的诊断建议——这带来了合规性风险。而且它破坏了下游的所有 JSON 解析器，因为它把响应包裹在了 Markdown 代码块语法中。同一供应商，不同的模型，却是推倒重来。

这就是供应商抽象税（provider abstraction tax）：它不是切换供应商的成本，而是不为此做规划所产生的累积成本。它不是一次性的迁移事件，而是一个持续的消耗——你在升级三周后发现的行为退化、无法跨模型迁移的提示词工程工作，以及因为某个供应商分别计算输入和输出 token 的速率限制而导致静默失败的重试逻辑。直接在单一供应商之上构建系统的团队会无形中积累这种债务，直到收到弃用通知或价格变动通知时，账单才会一次性结清。

我尊重的一位资深分析师这样描述她的团队在使用大语言模型 (LLM) 驱动的分拣代理的前六个月：“它让简单的告警消失了，却让复杂的告警变得更难信任。”这句话一直让我记忆犹新，因为它捕捉到了这项权衡的本质。安全运营中心 (SOC) 中的 AI 并不是一个关于效率提升的故事。它是一个关于信心校准的故事，而大多数团队都在朝着同一个错误的方向进行校准。

诱人的版本是：在告警队列前放置一个模型，让它聚类重复项、总结原始事件并自动关闭明显的噪音。MTTR（平均响应时间）图表下降了。寻呼机安静了。一级告警积压蒸发了。而真正导致你被入侵的版本是：模型自信地将一次真实的入侵误判为无害的备份作业，而一名疲惫的分析师——被告知“AI 已经分拣过了，没问题”——甚至从未打开过这个案例。第一个版本是真实的，第二个版本也是。它们是同一个系统在不同信心水平下的表现。

检查你代码库中每一次 LLM 调用里的 max_tokens 参数。如果你和大多数团队一样，这个参数要么没设置，要么设成了模型的最大值，或者是半年前随便选的一个像 4096 这样的整数，之后就再也没动过。它是 API 请求中一个显眼的预算旋钮，却在默默地为你从未使用过的冗余买单。

在中等商业模型上，输出 token 的成本大约是输入 token 的四倍，而在昂贵模型上甚至高达八倍。生成步骤的经济效益完全是失衡的：你在 max_tokens 中留下的每一分未使用的余量，都是你可能需要支付的成本；而且由于解码是顺序进行的，你生成的每一个 token 都会线性地增加你的 P50 延迟。然而，大多数生产系统都将此参数视为安全阀——设置得高高的，然后忘掉它，继续开发。