702 篇博文 含有标签「llm」

大多数构建 RAG 系统的团队认为他们只有两种失败模式：检索未能找到相关文档，或者 LLM 在拥有文档的情况下产生了幻觉。第一种模式被强迫症般地衡量着 —— Recall@K、MRR、NDCG。第二种模式则被视为模型本身的问题。然而，这两种定义都不完整。

存在第三种介于两者之间的失败模式：检索成功（相关文档排在 Top-K 中），但检索到的上下文实际上并不包含足以正确回答问题的足够信息。模型变得非常自信，生成一个看似合理的答案，但结果却是错误的。对包括 GPT-4o、Gemini 1.5 Pro 和 Claude 3.5 在内的前沿模型的研究表明，这种情况在多步查询中的发生率超过 50% —— 而大多数生产系统都没有任何监测手段来检测它。

你的推理模型在 98% 的情况下能正确识别出数据是敏感的，但它在思维链（chain-of-thought）中泄露该数据的概率却高达 33%。这种差距——即知道某事是隐私与实际保持其私密性之间的脱节——是推理轨迹（reasoning trace）隐私问题的核心，而大多数生产团队尚未为此做好准备。

深度思考（Extended thinking）已成为对准确性要求极高的应用程序的标准工具：客户服务分流、医疗编码辅助、法律文件审查、财务分析。而这些领域恰恰是 Prompt 中数据最敏感的地方。在这些场景中部署推理模型，如果不了解轨迹如何处理这些数据，将面临巨大的暴露风险。

大多数基于推理模型进行构建的团队将隐私视为一个双面问题：清理输入的提示词，清理输出的回复。中间的推理链（reasoning trace）为了可观测性而被完整记录，被提供给下游系统进行调试，有时甚至会被传回给那些要求“查看思考过程”的用户。那一层中间层才是真正的风险所在——而大多数生产部署并未将其视为应有的隐患。

2026 年初的研究量化了从业者一直在口头观察到的现象：大型推理模型（LRM）在中间推理步骤中泄露个人身份信息（PII）的频率高于其最终答案。在一项针对五个开源模型在医疗和金融场景下的测试研究中，结论是明确的——中间推理可靠地浮现了最终回复成功隐瞒的 PII。最终答案被清理了，但推理链没有。

大多数构建 LLM 应用的团队都了解 Prompt caching —— 这是 API 提供商提供的一种前缀重用机制，旨在对重复的输入 Token 进行折扣。部署其上一层技术的团队则少之又少：语义缓存 (Semantic Caching)，它能彻底消除那些语义相同但表述不同的查询所产生的 LLM 调用。这种差距并非源于怠惰，而是源于对语义缓存供应商文档中 “95% 准确率” 含义的普遍误解。

那 95% 的数字指的是缓存命中时的匹配正确性，而不是缓存实际被命中的频率。实际生产环境中的命中率从开放式聊天的 10% 到结构化 FAQ 系统的 70% 不等 —— 在你编写任何缓存代码之前，你应该先计算出你处于该范围的哪一侧。

你的 LLM 管道在测试中达到了 97% 的成功率。但在它发布后，在实际使用的长尾场景中，JSON 解析失败会静默地损坏下游状态，缺失字段会在三步之后导致空指针异常，或者包裹在 Markdown 代码块（fences）中的响应会在凌晨 2 点破坏你的提取逻辑。结构化输出失败是生产级 AI 系统中鲜为人知的可靠性杀手——它们很少出现在基准测试中，但在多步管道中会无形地累积，而且只要你理解了问题的核心，它们是完全可以避免的。

令人不安的事实是：在生产环境中，简单的 JSON 提示词（prompting）失败率高达 15–20%。对于一个每天进行 1000 次 LLM 调用的管道来说，这意味着 150–200 次静默失败。由于这些错误通常不会立即显现——它们作为格式错误的数据而非异常向前传播——它们是检测和调试难度最高的一类 Bug。

GPT-4o 在 Spider 基准测试中获得了 86.6% 的分数。将其部署到你的实际数据仓库中，你可能只能得到 10%。这种差距不是舍入误差——它正是问题的核心。构成缺失的 76% 的查询在执行时没有错误，返回的行符合正确的架构（schema），但结果完全错误。

Text-to-SQL 不是语法问题。每一个严肃的生产环境部署都会发现同一个令人不安的真相：最棘手的失败是无声的。一个扫描 10TB Snowflake 表、由于重复连接（join）导致返回的营收数据偏高 30%、或者悄悄绕过行级安全设置的查询，从外部看与正确的查询完全一样。它运行结束，返回数据，没有人会标记它。

本文涵盖了在生产环境中真正困扰团队的失效模式，以及防止这些模式的层级架构。

当最尖端的模型在 SWE-bench Verified 上获得 80% 的评分时，这听起来像是问题已经解决了。五分之四的真实 GitHub issue 都能被自动处理。直接交付给你的团队吧。但事实是：同一个模型在 SWE-bench Pro（一个专门设计用于防止数据污染、包含来自私有代码库的长程任务的基准测试）上的得分仅为 23%。此外，一项针对经验丰富开发者的严谨对照研究发现，使用 AI 编程工具反而让他们慢了 19%，而不是变快了。

这些数字并不矛盾。它们反映了基准测试衡量的内容与生产环境软件工程实际需求之间的差距。如果你正在构建或打算采用智能体编程（agentic coding）工具，那么这个差距就是最值得关注的事情。

你的代码通过一个流程发布：特性分支 (feature branch) → 合并请求 (pull request) → 自动化测试 → 预发布 (staging) → 生产环境 (production)。每一步都有门槛。如果没有通过你定义的检查，任何东西都无法到达用户手中。这种“枯燥”正是它最好的地方。

现在想象你需要更新一个系统提示词 (system prompt)。你在仪表盘中编辑字符串，点击保存，更改立即生效 —— 没有测试，没有预发布，版本控制中没有 diff，除了手动改回去之外没有回滚的方法。这就是大多数团队的运作方式，也是提示词更改成为 LLM 应用非预期生产事故主要原因的原因。

挑战不在于团队粗心大意。而在于持续交付 (continuous delivery) 的规范是为确定性系统构建的，而 LLM 并非确定性的。整个思维模型需要从头重建。

当 100 万 Token 的上下文窗口发布时，许多团队认为这相当于拿到了可以停止思考上下文设计的“许可”。逻辑很直观：如果模型能看到一切，那就把一切都给它。丢进整个文档。传递完整的对话历史。将每一个工具输出都转发给下一个 Agent 调用。让模型自己去处理。

这就是“上下文堆砌 (Context Stuffing)”反模式。它会产生一种典型的故障模式：系统在早期演示中运行良好，但在生产环境中会遇到可靠性瓶颈，无论如何调整提示词都无法修复。在原本应该很简单的问题上，准确率反而下降。回答变得模棱两可、含糊其辞。Agent 开始在互不相关的文档之间产生幻觉性的关联。模型“看到”了所有正确的信息 —— 它只是找不到。

大多数构建智能体（agent）的团队将数据库模式（schema）视为后端关注的问题。这种模式是由工程师为工程师设计的，遵循了数十年关系型数据库的最佳实践：积极规范化、避免冗余、拆分引用表、强制执行外键。这种方法对于联机事务处理（OLTP）系统是正确的，但对于 AI 智能体来说通常是错误的。

当智能体读取你的模式以确定如何回答问题时，它并不是在解析数据结构，而是在构建你业务的心智模型。如果你的模式是为已经理解该领域的应用程序代码构建的，那么智能体将根据为别人绘制的地图进行工作。结果就是幻觉式的联接、错误的聚合，以及原本只需两步却需要八步的工具调用链。

大多数团队通过惨痛的教训发现，发布一项新的 LLM 功能与发布一个新的 UI 按钮完全不同。一个在离线评估中表现出色的 Prompt 变更发布到生产环境后，可能会悄无声息地导致 30% 用户的体验质量下降——而你的仪表盘却全程显示 HTTP 200。等你察觉时，成千上万的用户已经遭遇了糟糕的体验，而你却没有快速恢复到正常状态的路径。

防止传统软件故障的渐进式发布工具包——特性标志（feature flags）、金丝雀发布（canary releases）、A/B 测试——同样适用于 LLM 驱动的功能。但其机制差异之大，以至于直接复制粘贴现有的部署手册会让你陷入麻烦。非确定性、语义质量指标以及 LLM 变更的多层性质（模型、Prompt、参数、检索策略）都制造了团队通常会低估的棘手问题。

大多数工程师都低估了微调成本，低估程度达三到五倍。训练运行只是账单中最小的一部分。数据整理、实验失败、部署基础设施以及持续的模型维护才是预算真正的去向。跳过这类计算的团队往往会在投入微调项目数月后才意识到，一个设计良好的 few-shot 示例提示词本可以在一周内解决问题。

本篇文章将深入探讨完整的经济账——微调在整个生命周期中的实际成本、LoRA 和 PEFT 何时能让这笔账划算，以及一个基于真实生产数据在微调和提示词工程之间进行选择的决策框架。