778 篇博文 含有标签「llm」

你的企业刚刚部署了一个 RAG 系统。你索引了每个 Confluence 页面、每份运行手册（runbook）、每篇架构文档。六个月后，一位高级工程师离职了——就是那个知道为什么支付服务会有那种不寻常的重试模式、为什么你们从不把缓存扩容超过 80%，以及周五绝对不要给哪家供应商打电话的人。这些知识从未被记录下来。你的 RAG 系统根本不知道它的存在。

这就是隐性知识（tacit knowledge）问题。这也是为什么大多数企业 AI 系统表现不佳的原因——不是因为检索质量或幻觉，而是因为它们所需的知识从一开始就没被捕获。60% 的员工表示，很难甚至几乎不可能从同事那里获取关键信息。90% 的组织表示，员工离职会导致严重的知识流失。你的 RAG 能索引的文档只是冰山一角。

每当一个新的 LLM 功能上线，总会有人问："我们该用多少 temperature？"答案几乎千篇一律："不知道，留着 0.7 吧。"然后对话结束，没有人再碰这个值。

这是一个用默认值做出的产品决策。Temperature 不只是控制模型听起来有多"随机"——它决定了用户是否信任输出、是否会重新运行查询、是否感到被帮助或被淹没。把它调好比大多数团队意识到的更重要；调错了也很难诊断，因为失败的表现看起来像是模型行为差，而不是配置差。

Text-to-SQL 演示看起来出奇地简单：把 schema 粘贴到提示词里，向 GPT-4 提个问题，拿到一条整洁的 SELECT 语句，然后 Slack 里就开始涌现"要不要把这个集成进数据平台？"的消息。等到你真正打算上线时，麻烦来了。基准测试显示 85% 的准确率，但内部数据团队反映大约一半的答案是错的，而安全团队则在追问：生成的查询在执行前有没有经过审查？没人能给出一个像样的答案。

这正是 text-to-SQL 作为研究问题与作为工程问题之间的鸿沟。研究问题关注的是让模型生成语法正确的 SQL；工程问题面对的是 schema 歧义、访问控制、查询验证，以及你的企业数据库根本不像 Spider 或 BIRD 数据集这一现实。

你的ASR系统返回了"the patient takes metaformin twice daily"。正确的词应该是metformin。转录看起来很干净——没有[INAUDIBLE]标记，没有错误标志。那个词的置信度是0.73。你的管道丢弃了这个数字，将干净的文本传给了LLM。LLM将其视为真实情况，围绕一种不存在的药物进行推理。

这就是转录层的谎言：一种隐性假设，认为中间文本表示——无论是由语音识别、OCR还是解析文档的视觉模型产生的——都足够可靠，可以不加保留地向下游传递。事实并非如此。但几乎每个生产管道都将其视为可信来源。

当确定性系统崩溃时，你会找到 bug。堆栈跟踪指向某一行代码。代码差异（diff）显示了更改。回顾起来，修复方案显而易见。但 AI 系统并非如此。

当一个由大语言模型（LLM）驱动的功能开始输出更差的结果时，你寻找的不是 bug。你面对的是一个发生偏移的概率分布，它存在于一系列组件构成的堆栈中，而每个组件都引入了各自的方差。是模型的问题吗？是供应商在某个周二进行的无声更新？是架构变更后未刷新的检索索引？是某人为了修复另一个问题而修改的系统提示词（system prompt）？还是三个冲刺（sprint）前就停止捕获回归的评估系统（eval）？

复盘会议变成了责任拍卖会。每个人都出价“模型变了”，因为这是一个无法证伪且无需成本的借口。

大多数后端工程师能够背诵 REST 契约：客户端发送请求，服务器处理请求，服务器返回状态码和响应体。200 表示成功，4xx 表示客户端出了问题，5xx 表示服务器出了故障。响应是确定性的，超时是可预测的，幂等键保证了安全重试。

而 LLM 后端违背了上述所有假设。一个返回 200 OK 的请求，可能意味着模型对整个响应产生了幻觉。一次成功的请求可能需要十二分钟，而不是十二毫秒。两次参数完全相同的请求会返回不同的结果。如果服务器在推理过程中超时，你根本不知道模型究竟是否已完成。

把 LLM 硬塞进传统 REST API 的团队，最终往往面对一堆补丁：超时杀死了正在运行的 Agent 任务，客户端把带幻觉的 200 当成成功，重试逻辑因为幂等键没有针对概率性操作设计而三次扣了用户的信用卡。本文将梳理这些不匹配最致命的地方，以及真正在生产环境中能站得住脚的接口模式。

凌晨两点，报警器响了。仪表盘显示没有 5xx 错误、没有超时激增、没有异常延迟。然而客服已经被淹没："AI 给出了奇怪的回答。"你打开运行手册——立刻意识到它是为完全不同的系统写的。

这是 2026 年 AI 故障响应的标志性失效模式。系统在技术上完全健康。Bug 是行为上的。传统运行手册假设存在离散的失败信号：堆栈跟踪、错误码、不响应的服务。基于 LLM 的系统彻底打破了这一假设。输出语法正确、延迟正常、内容却完全错误。没有任何告警能捕捉到它。唯一的信号是某些东西"感觉不对"。

这篇文章是我第一次不得不响应生产 AI 故障时希望就存在的手册。

你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 工程中最关键的架构决策之一，但几乎总是凭直觉做出的。本文将梳理实证依据，说明分解何时真正有帮助、何时会悄然使事情变得更糟，以及在生产环境中需要关注哪些信号。