567 篇博文 含有标签「llm」

演示非常精彩。模型流利地回答了每一个问题，总结文档时没有出现幻觉，并处理了你提出的每一个边缘情况。利益相关者印象深刻。上线日期也就此定下。

发布三周后，准确率徘徊在 60% 左右。用户感到困惑。工单堆积如山。在演示中表现出色的模型，在处理生产环境流量时却步履维艰。

这不是一个关于模型好坏的故事，而是一个几乎每个构建 LLM 功能的团队都会遇到的错配故事：你测试的输入并不是用户发送的输入。

在峰值流量期间，部分 LLM 提供商的失败率超过 20%。当系统撞上这堵墙，并通过加倍等待时间和重试来应对时，你解决的是一个错误的问题。指数退避处理的是单次调用的韧性，对整个系统毫无作用——无法减少浪费的 token，无法解决连接池耗尽，也无法照顾到排在刚收到 429 响应那个请求后面的 50 个请求。

冲击 LLM API 的流量模式也发生了根本性变化。2023 年到 2025 年间，100 token 以下的简单查询从占流量的 80% 骤降至约 20%，而超过 500 token 的请求则成为持续的多数。Agentic 工作流在短时间内串联 10-20 个顺序调用，产生的流量模式在传统的每分钟请求数（RPM）限速下，与 DDoS 攻击别无二致。为负载可预测的 REST API 构建的基础设施，并不是 LLM 流水线所需要的基础设施。

大多数在 QA 阶段夭折的 AI 项目，死因并非模型不好，而是没有人在构建之前就"好"的定义达成共识。工单里的验收标准往往写着"摘要功能应生成准确、相关的摘要"——当工程师问"准确"是什么意思时，得到的答案是"看到就知道"。这不是行为需求，这是一种期许。

问题在于团队把原本用于确定性软件的需求流程照搬到了本质上具有随机性的系统上。当你为数据库查询写 assertTrue(output.equals("Paris")) 时，测试的通过与否是完全确定的。但把同样形式的断言用在 LLM 上，得到的是一个对所有有效的同义表达都失败、对所有自信的幻觉都通过的测试。单元测试在骗你，而它所依据的规格从来就不是为"生成输出分布而非单一值"的系统设计的。

一家金融科技团队基于 GPT-4o 构建了他们的 AI 聊天机器人。第一个月：1.5 万美元。第二个月：3.5 万美元。第三个月：6 万美元。预计年支出将达到 70 万美元，他们慌了，并决定转向自托管。六个月后，在耗尽了一名工程师的精力后，他们每月在基础设施、一名兼职 DevOps 工程师以及三次导致生产环境宕机的 CUDA 事故上花费 8.5 万美元。他们最终将开支降到了每月 8000 美元 —— 但并不是通过全盘自托管实现的，而是通过智能路由。

这两个决定都是错误的。真正的失败在于他们从未进行过实际的成本核算。

你的 AI 产品三个月前上线了。你有显示延迟、错误率和 token 成本的仪表盘。你已经看到用户与系统交互了数千次。然而你的模型和上线那天相比，好的地方一样好，差的地方一样差。

这不是数据问题。你拥有的数据已经多得不知该拿来做什么。这是架构问题。那些告诉你模型哪里失败的信号，就躺在应用日志、用户会话和下游结果数据里。它们与任何能改变模型行为的东西断开了连接。

大多数团队把 LLM 当作静态制品，然后在外围包裹监控和评估。最优秀的团队则把生产环境视为一条永不停歇的训练流水线。

一家金融科技初创公司在他们的系统提示词中添加了一个逗号。第二天，他们的发票生成机器人开始输出乱码，在有人追踪到原因之前，他们已经损失了 8,500 美元。没有抛出任何错误。没有触发任何报警。应用程序继续运行，虽然错了但很自信。

这就是在生产环境中调试 LLM 的真实样子。没有指向行号的堆栈追踪。没有你可以检查的核心转储（core dump）。系统不会崩溃——它在继续运行的同时，悄无声息地产生降级的输出。传统的调试直觉不再适用。大多数工程师的反应是随机调整提示词，直到看起来好一点，然后基于三个示例进行部署，并称其已修复。结果两周后，问题又以另一种形式浮出水面。

有一种更好的方法。LLM 的故障遵循系统性的模式，而这些模式对结构化的调查有反应。这就是这套方法论。

大多数关于 RAG 安全的讨论都集中在生成层 —— 越狱、系统提示词泄露、输出过滤。从业者花费数周时间在模型端调整护栏，却忽视了为其提供数据的摄入管道。一个令人不安的现实是：你的管道摄入的每一份文档都是一个潜在的指令面。一个 PDF 文件就能覆盖你的系统提示词、窃取用户数据，或在你的日志基础设施没有发现任何异常的情况下操纵决策。

这并非理论推测。在过去的两年里，Microsoft 365 Copilot、Slack AI 和商业 HR 筛选工具都曾通过这种向量被攻击。同样的攻击模式也出现在 arXiv 上的 18 篇学术论文中，研究人员通过嵌入隐藏提示词，使 AI 同行评审系统做出有利于他们的偏向性评价。

用LLM智能体替换所有Zapier流程和RPA脚本的团队，往往在六个月后发现了同一件事：他们用"脆弱但可审计"换来了"灵活但难以维护"。Zapier流程以可预测的方式崩溃——第14步因API变更而失败。LLM工作流则悄无声息地出错——模型悄悄地将支持工单路由到错误的队列，直到客户升级投诉才被发现。审计日志只记录着"AI决策"，这用律师的话来说就是"没人知道发生了什么"。

答案不是回避在自动化中使用LLM，而是要有意识地判断哪些任务交给哪个系统，并架构好两者之间的接缝，使故障不会相互传染。

典型的 AI 叙事往往是这样的：你构建一个产品，添加一个 AI 功能，用户就能获得更智能的输出。这种框架虽然正确，但并不完整。更持久的优势根本不在产品层，而是在其底层运行的数据流水线中。

越来越多的工程团队悄然将 ETL 流水线中的正则规则、自定义分类器和手写解析器替换为 LLM 调用。结果是：流水线可以处理非结构化输入，适应模式偏移（schema drift），并对数千个类别的记录进行分类——而无需为每一个新的边缘情况重新训练模型。大规模运行这种模式的团队正在构建具有复利效应的数据资产。而那些仍将 LLM 纯粹视为产品功能的团队则不然。

你发布了一个新的平台级防护栏 (guardrail) —— 一条防止 AI 讨论竞争对手价格的规则。它在周一早上上线。到了周三，你最大的企业客户提交了一个支持工单：他们的销售助手 (他们曾精心调整该助手，以便为采购团队比较供应商选项) 停止工作了。他们没有更改任何东西。你更改了一些东西，而其影响范围 (blast radius) 在无形中波及了他们。

这就是多租户提示词问题 (multi-tenant prompt problem)。允许客户定制的 B2B AI 产品实际上是在运行一个分层指令系统，但大多数团队并没有将其视为一个系统。他们将其视为字符串拼接：获取平台提示词，附加客户的指令，也许再附加用户偏好，然后调用 LLM。模型会处理剩下的事情。

模型并不能处理好。它会默默地挑选一个赢家，而你直到有人投诉才会发现是哪一个。

模型卡会告诉你模型是否经过了针对CBRN误用的红队测试，以及它对哪些人群服务不足。但它不会告诉你：在10,000个并发请求下的p95 TTFT、性能在上下文窗口80%处出现的断崖、复杂JSON模式的格式错误率，或者自模型卡发布以来模型行为漂移了多少。

这种差距是结构性的，而非偶然。模型卡设计于2019年，用于公平性和安全性文档，目标受众是公民社会组织和监管机构。构建生产系统的工程团队并不是其使用场景。七年的推广之后，这一框架依然未变——而将模型卡视为部署规范的代价从未如此高昂。

2025年基础模型透明度指数（斯坦福CRFM + 伯克利）证实了这一遗漏的范围：OpenAI在100项透明度指标中得24/100，Anthropic得32/100，Google得27/100。平均分从58分降至40分，这意味着随着模型能力增强，AI透明度不升反降。四大主要实验室均不披露训练数据构成、能源使用情况或与部署相关的性能特征。

每个严肃的工程团队在合并代码前都会运行一次 Lint 检查。ESLint 捕获未定义的变量，Prettier 强制格式规范，Semgrep 标记安全反模式。没有人会在不先运行至少一次静态检查的情况下将 JavaScript 发布到生产环境。

现在想想你的团队在发布一次提示词变更之前会做什么。如果你的团队和大多数团队一样，答案是：在 PR 里审阅一下，用肉眼扫描，也许手动测试几个输入用例，然后合并。你生产 AI 功能的系统提示词——控制模型如何为每一位用户表现的指令集——所受到的预部署审查比一次 CSS 改动还要少。

这个差距不是一个微小的流程疏漏。一项分析了 2,000 多个开发者提示词的研究发现，超过 10% 的提示词存在提示词注入攻击的漏洞，约 4% 存在可衡量的偏见问题——而这一切都在没有人察觉的情况下部署到了生产环境。自动捕获这些问题的工具已经存在，只是大多数团队还没有把它接入流水线。