639 篇博文 含有标签「llm」

大多数构建 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 何时能让这笔账划算，以及一个基于真实生产数据在微调和提示词工程之间进行选择的决策框架。

你的向量搜索在基准测试中表现出色，但用户依然感到沮丧。

失败模式非常微妙：用户询问“我们的哪些供应商卷入了影响与 Martinez 账户所在地区相同客户的事件？”你的嵌入模型检索到了事故记录。它们检索到了供应商合同。它们检索到了客户账户。但它们是以相互孤立的文档形式检索出来的，LLM 必须在上下文中理清这些关系——而这些关系横跨了实体图（entity graph）中的三个跳数（hops）。当每个查询涉及五个或更多实体时，如果没有关系结构，准确性会降至接近零。而有了关系结构，性能则保持稳定。

这正是知识图谱增强检索——GraphRAG——旨在解决的瓶颈。它不是向量搜索的直接替代品。它是一个具有不同成本结构、不同失败模式、以及在特定类别查询中具有压倒性优势的不同系统。

大多数采用知识蒸馏的团队，都在错误的理由和错误的时机下做出了这个决定。他们看到一个70B模型吞噬了推理预算，读到蒸馏可以产出一个"同样出色"的7B学生模型，便立即开干。六周后，他们得到了一个在验证集上表现良好的蒸馏模型，上线后却开始大规模输出自信满满的废话。验证集来自与教师模型合成训练数据相同的分布，而真实流量并非如此。

蒸馏是一种优化工具，而非能力升级手段。只有在特定条件下，经济账才算得过来——而且失败模式足够隐蔽，团队往往要等到用户先发现问题。

一个团队在周二下午将 GPT-4o 换成了一个更新的模型。到周四，支持工单增加了 30%，但没人能说清原因 —— 新模型的回答稍短，拒绝了一些旧模型能处理的边缘情况请求，并且日期格式化的方式不同，导致下游解析器崩溃。团队选择了回滚。两个迭代周期的工作付诸东流。

这种故事不断上演。问题不在于新模型更差 —— 它在大多数方面可能表现得更好。问题在于团队发布的流程与发布 bug 修复程序完全相同：合并、部署、观察。这对代码有效，但对 LLM 则行不通。