780 篇博文 含有标签「ai-engineering」

某家产品公司的团队为市场部门构建了一款头脑风暴助手。他们在文档语料库——营销简报、品牌指南、竞品分析——上添加了 RAG，认为更丰富的上下文会产出更好的创意。三周后，使用率下降了。定性反馈如下：输出"太安全"、"太可预测"、"感觉只是在重混我们现有的东西"。他们从头脑风暴功能中移除了检索。创意改善了，参与度也恢复了。

这种模式在实践中出现的频率远比人们承认的要高。检索增强生成已成为将 LLM 输出锚定到事实的默认架构，对于事实性任务，它当之无愧。但对于生成类任务——创意构思、创意写作、新颖方案生成——添加检索层可能会悄然压低模型产出的上限。这不是因为检索坏了，而恰恰是因为它按照设计在正常运转。

构建 RAG 系统的团队几乎普遍都会遇到同样的瓶颈：他们花一周时间调整 HNSW 索引参数，添加乘积量化（product quantization），将 recall@100 从 0.81 提高到 0.87 —— 然后发现 LLM 的输出质量几乎没有任何改观。投入数月努力所基于的假设是：更好的索引等于更好的回答。事实并非如此。瓶颈从来不在索引上。

真正的卡点在于候选集与上下文窗口（context window）之间的重排序（ranking）步骤。你喂给 LLM 的内容决定了它的输出，而重排序的工作就是确保那些真正相关的文档，而不仅仅是语义上最相似的文档，能够进入上下文。这种区别比你调整的任何 HNSW 配置都更重要。

大多数团队对待系统提示词的方式，就像早期 Web 开发者对待 CSS：粘贴一段能跑的代码，小心翼翼地修改以免破坏什么，提交到配置文件，然后祈祷没人动它。接着某位新成员"顺手整理"了一下，模型升级后行为悄然改变，三周后用户提了一个 bug，而没人能复现——因为没人知道上周二那个提示词究竟写的是什么。

这不是工作流问题，而是概念分类的错误。系统提示词不是配置，而是软件接口。只要工程团队还没有如此对待它们，他们构建的 LLM 功能就将持续脆弱、难以调试、无从扩展。

令人惊讶的是，许多 AI 团队一旦获得 o3 级别或 Claude 扩展思考模型的访问权限，就会默认对所有查询启用扩展思考。这背后的逻辑看似显而易见：更智能的推理等于更好的输出，何不始终开启？问题在于，这种逻辑没有考虑到测试时计算扩展在实践中如何运作的基本事实。扩展思考能显著提升特定类型任务的性能，在另一些任务上则会降低质量，并可能将全局推理成本推高 5-30 倍。那些从这些模型中获取最大价值的团队，将推理预算作为一个明确的决策来对待——其重要性不亚于模型选择或提示词工程。

本文阐述了任务分类体系、成本结构，以及将战略性使用思考预算的团队与仅仅为质量幻觉溢价买单的团队区分开来的路由决策框架。

一个团队发布了一款面向用户的 AI 助手。他们将其定价为每席位每月 49 美元，根据一份假设“每次查询平均 500 个 token”的电子表格，目标毛利率为 70%。三个月后，财务部门指出，他们的重度用户在每个会话中消耗了 15,000 个 token。定价模型之所以崩溃，并不是因为功能失败，而是因为产品团队为他们尚不了解的东西定了价。

这并非预测失败。这是一个结构性问题：大模型驱动产品的成本基准与传统 SaaS 定价所设计的处理方式根本不同。每一次 API 调用都有不可预测且实质性的 token 成本。输入因用户、任务和时间段而异。输出以各种方式复合增长，而这些影响直到几周后才会出现在你的云账单上。一旦你引入了智能体模式 (Agentic patterns) —— 工具调用、多轮推理、子智能体编排 —— 单次用户交互的成本可能是 0.02 美元，也可能是 20 美元，这完全取决于模型的决定。

大多数团队在设计 LLM 智能体时，会花大量精力在工具选择和系统提示措辞上。而几乎没有人认真思考工具返回什么内容。这是一个后果不断叠加的错误——因为工具响应的结构决定了智能体能否有效推理、消耗多少上下文窗口，以及产生幻觉解读的频率。

工具输出 schema 设计是基础设施，而非管道细节。设计失误，你的智能体将以表面上像推理问题的方式失败，而根源其实是 schema 问题。

一家大型医疗保险公司部署了一套AI工具来评估病后护理索赔。该系统的错误率超过90%——也就是说，每十个经人工审核人员最终推翻的拒赔案例中，有九个是被错误拒绝的。然而这些拒赔并未被主动纠正。患者不得不逐一提出申诉。当诉讼来临时，公司的回应是将矛头指向AI。

AI什么都没有拒绝。是人类在他们自己设计的工作流程中大规模地批准了这些拒赔，在他们选择部署的系统里。但"AI决定了"这句话把责任引向了一个方向，恰好让组织、批准上线的高管以及在每个案例上签字的审核人员得以脱身。

这就是责任转移问题——它不是未来的风险，而是已经在生产AI系统中普遍存在的现实。

询问任何工程副总裁 AI 编码工具是否能提高生产力，他们都会给出肯定的回答。但如果你询问一名在一套拥有十年历史的代码库中工作的资深工程师（Staff Engineer），这套代码库里有六个没有文档记录的数据模型，部署流程全靠 Shell 脚本维系，你得到的答案将会截然不同。

AI 编码工具带来的生产力提升呈现出一种大多数组织尚未完全消化的分化态势。初级工程师在每周完成的任务量上看到了 27%–39% 的提升。而在一项针对真实世界问题的受控研究中，资深开发者在使用 AI 辅助时，完成任务所需的时间反而比不使用时增加了 19%。这两个结果都与这些工具的工作原理相一致 —— 并且它们正导向一个目前正在工程团队中悄然上演的管理陷阱。

当麦当劳在三年运营后关停其 AI 得来速系统时，失败的原因并不是模型识别订单能力不足。失败的根源在于架构：没有明确的升级路径交给人工收银员，没有触发重试的置信度阈值，也没有定义系统困惑时该如何处理。AI 只是不停地尝试。顾客不断地抓狂。顺利路径设计得很好，其他一切都没有。

几乎每一个失败的 AI 部署都重复着这个模式。模型在演示中运行良好，在生产中出现故障。而事后分析揭示了同样的根本原因：降级设计从来不是架构的一部分，而是某人打算"之后再加"的东西。

你的 AI 功能顺利发布了。文档看起来很棒：输入 schema、预期输出，以及一个经过验证的示例。三个月后，模型静默更新。输出发生了偏移。你的文档错了，但还没人发现——因为它们看起来仍然是“正确”的。

这是 AI 文档债（AI documentation debt）的核心，而且它比任何其他类型的技术债积累得都要快，因为在用户发现之前，这种失败是隐形的。

一位小团队工程师花了三个月将测试生成委托给 AI。代码覆盖率从 47% 跃升至 72%，再到 98%。每次 PR 都返回绿色。然后生产环境崩了。用户注册中的竞态条件因数据库复制延迟导致重复邮箱。优惠码接口在代码无效时返回 null 而非零，导致支付计算对 4700 名客户静默出错。最终损失：4.7 万美元退款和 66 小时工程时间。测试并没有遗漏几个边界情况——它们覆盖了所写的代码，而非所部署的系统。

这就是覆盖率幻觉。随着 AI 辅助开发成为默认选项，落入这个陷阱正变得越来越容易。

思维链提示（Chain-of-thought prompting）本是为了解决语言模型的黑箱问题。展示推理过程，验证每个步骤，理解模型如何得出结论。这个想法直觉上是对的——而这恰恰是问题所在。它感觉太显然正确了，以至于从业者将可见推理链部署到生产系统中，却没有追问一个更难的问题：如果展示推理过程反而让事情变得更糟，该怎么办？

2024年至2026年间的研究已开始系统性地记录这种"更糟"究竟是什么样子。可见推理链导致了两种截然不同的失败模式，在生产环境出现问题之前往往被忽视。第一种是用户侧问题：中间推理步骤会在用户看到最终答案之前，将其锚定于可能错误的结论。第二种是系统层问题：推理追踪制造了审计追踪的假象，而作为模型实际决策过程的解释，它从根本上是不可靠的。