构建生成式 AI 应用的常见陷阱
大多数生成式 AI 项目都以失败告终——并非因为模型本身不好，而是因为团队在技术栈的每个层面都犯了相同且可预测的错误。一项 2025 年的行业分析发现，42% 的公司放弃了他们大部分的 AI 计划，而 95% 的生成式 AI 试点项目未能产生可衡量的业务影响。这些并非模型故障，而是团队本可以避免的工程和产品失败。
本文将列举那些最容易导致 AI 项目失败的陷阱——从问题选择到评估——并结合生产系统中的具体案例进行阐述。
陷阱 1：从技术出发，而非问题本身
在组织层面最常见的失败模式是：“第一步：我们要使用大型语言模型（LLM）。第二步：我们应该用它们来做什么？”
这种方法会带来两种代价高昂的后果。首先，团队将 AI 应用于确定性算法能够更好、更快、更便宜地解决的问题——例如日程安排、简单分类、基于阈值的异常检测。其次，他们将 text-to-SQL、Slack 机器人和文档问答等视为战略性 AI 投资，而这些实际上是任何供应商都会商品化的低投资回报率（ROI）功能。
真正有效的方法是：首先确定一个可量化的业务痛点，然后选择合适的工具。一家科技公司发现，销售团队在每个潜在客户的背景调查上花费 4 小时——每年量化价值约为 5000 万美元——然后他们构建了一个有针对性的 AI 集成，将其减少到 15 分钟。可量化的痛点优先，模型选择其次。
那些报告 AI 带来显著财务回报的组织，在选择建模技术之前，重新设计工作流程的可能性是其他组织的两倍。
陷阱 2：将产品失败归咎于模型局限性
当 AI 功能表现不佳时，人们的本能反应是归咎于模型，并将其替换为能力更强的模型。这通常是错误的。
三个生产案例使这一区别更加具体：
会议总结： 一个初始产品专注于优化总结长度（3 句话 vs. 5 句话）。用户研究发现，用户只关心分配给他们的行动项。问题在于产品设计，而非总结器的质量。
LinkedIn 的技能匹配聊天机器人： 产品设计旨在追求准确性；但用户想要的是实用性。告诉用户“你不适合这个职位”在技术上是正确的，但却是有害的。用户想要的是差距分析和改进路径。模型没错——是产品错了。
客户服务聊天机器人： 底层系统在受控条件下表现良好，但在处理实际客户问题时却举步维艰。那些看似罕见的边缘情况在生产环境中却变得普遍。Klarna 在 2024 年大肆宣传用 AI 取代客户服务人员，但在 2025 年因客户满意度下降而改弦易辙。
这意味着：你应该投入与选择底层大型语言模型（LLM）同样多的时间来设计用户交互模型。每个人都能访问相同的底层模型。你的差异化优势存在于用户体验（UX）层面——预期设定、优雅降级、回退机制以及工作流集成。及早构建人机协作模型原型；不要假设完全自动化就是最终目标。
陷阱 3：从 80% 到 99% 的差距并非线性
早期原型能以惊人的速度达到 70-80% 的质量水平。这就制造了一个规划陷阱：团队会按比例为剩余的差距进行预算。但这个差距并非如此运作。
LinkedIn 的生产经验具有代表性：用 1 个月达到所需质量的 80%，而在此基础上又花了 4 个月才突破 95%。之后每提升 1% 都被形容为“令人沮丧”。一家 AI 销售助理初创公司报告说，达到 80% 所需的时间与从 80% 提升到 90% 所需的时间相等——这种意想不到的均等令他们的团队措手不及。
为什么最后 20% 如此昂贵：
- 在 80% 时是边缘情况的幻觉，到了 90% 却成为主要障碍
- API 可靠性问题加剧：一个团队报告称，某个主要提供商的超时率达到 10%
- 提供商侧更新导致的模型行为悄然变化（无更新日志，无版本保证）
- 合规性覆盖范围：版权、数据溯源、隐私法规
- 测试用例覆盖率呈组合式爆炸增长
如果你在第一个月达到了 80% 的质量，请再预算四到五个月以达到生产就绪的可靠性。将合规性审查和安全测试纳入最初的项目计划，而非作为发布后的修补工作。
陷阱 4：在验证简单性之前追求复杂性
团队在验证简单方法是否有效之前，就急于采用代理框架、向量数据库和微调管道。每个抽象层都会隐藏原有的失败模式，并引入新的失败模式。
框架依赖： 流行代理框架的默认提示中曾发现错别字。未经宣布的框架更新可能会悄然改变应用程序的行为，如果不进行端到端测试，根本无法检测。当出现问题时，你调试的是别人的抽象层。
过早引入 RAG： 在复杂的检索场景中，基本的向量相似性搜索的准确率最高约为 65%。常见的实现错误包括：固定大小的分块会在任意边界分割语义单元、领域特定词汇的嵌入模型不匹配，以及对长度分布差异极大的文档类型使用相同的嵌入策略。专利文档在 1,000-1,500 个 token 的分块下表现最佳；客户聊天记录则在 200-400 个 token 下表现最佳。部署后更改嵌入策略需要重建整个索引。
过早微调： 为知识注入进行微调是一种已知的反模式。“让我们对公司文档进行微调”是错误的——RAG 才是用于注入模型不具备知识的正确工具。微调适用于风格、格式和行为的改变，而非事实。
从直接的 API 调用和精心设计的提示词开始。如 果你的应用每月推理费用低于 1,000 美元，那么复杂的优化很少能证明其工程成本是合理的。只有当你掌握了向量存储、代理和微调确实需要的具体证据时，才考虑添加它们。
误区五：导致检索质量低下的 RAG 实现细节
RAG 现在已成为知识支撑的标准，但实现质量差异巨大。一篇 2024 年的研究论文列出了生产 RAG 系统中的七个具体故障点：
- 内容缺失 — 相关信息根本不存在于检索语料库中
- 未命中 top-k — 正确的块存在但未在检索结果中浮现；固定大小的 k 很少是最佳的
- 脱离上下文的提取 — 检索到的块缺乏正确回答所需的周边上下文
- 不在上下文中 — 块已被检索，但 LLM 未能从中提取相关部分
- 错误提取 — LLM 从正确检索到的块中提取了不正确的信息
- 不完整提取 — 答案需要多个块但合成失败
- 输出格式失败 — 响应正确但下游使用格式不正确
每个故障点都需要不同的缓解措施。第 1-3 点是检索问题。第 4-6 点是合成问题。第 7 点是提示工程问题。一概而论无法带来任何改进。
一个近乎通用的解决方案：纯向量搜索已不足以满足生产检索需求。双编码器嵌入将复杂段落压缩到高维空间中的一个点——这在设计上是有损的。将向量搜索（语义含义）与 BM25 词法搜索相结合的混合搜索，始终优于任何单一方法。这现在是基本要求，而非优化。
误区六：放弃人工评估
最危险的评估错误是完全用“LLM 作为评判者”的方法取代人工判断。LLM 评判者存在系统性偏差：
- 它们偏爱 LLM 生成的文本而非人工撰写的文本
- 它们表现出锚定效应、确认偏误和顺序效应
- 它们以不明显的方式对评判提示措辞敏感
- 提供商侧的模型更新破坏了结果在时间上的可比性
除了偏见之外，单一分数评估会产生误导性信号。一个食谱助手需要分别评估查询表述、文档相关性、信息提取准确性、卡路里计算、约束应用和最终格式。仅测量最终输出意味着特定阶段可能在悄无声息中失败，而整体分数看起来却可以接受。
静态评估数据集也会衰退。用户行为和输入分布会发生变化；六个月前代表生产环境的测试集，今天可能已不再具有代表性。评估标准本身需要完善，随着团队了解“好”对于真实用户究竟意味着什么。
高效团队的不同做法：用每日对 30-1000 个随机抽样示例的人工审查来补充自动化评估。花 15 分钟审视你的数据所产生的价值与声望比，高于机器学习中几乎任何其他活动。使用 AI 评判者进行大规模分类，而不是做出最终决策。
误区七：将提示视为配置而非代码
提示工程就是代码。将提示视为静态配置的团队，会发布无法追踪的 bug 和无法诊断的回归问题。
生产环境中常见的提示反模式：
- 多轮对话中模糊的引用： 在一次长对话中，“重构上述代码”会导致模型选择错误的 code block。关键引用必须重新提供明确的上下文。
- 过长的系统提示： 长提示会稀释指令、增加成本并混淆模型。每条指令都与其他指令竞争。
- 相互冲突的指令： 同一个系统提示中“简洁”和“详细解释”的指令会产生不一致、不可预测的输出。
- 无边界的输出规范： 每个输出维度——格式、长度、范围、语气——都应有明确的约束。
- 静默的上下文漂移： 当对话超出上下文限制时，早期的细节会悄无声息地丢失。这表现为长对话中的矛盾和被遗忘的约束。
操作性解决方案：对提示进行版本控制、测试并以与应用程序代码相同的严谨性部署它们。在测试提示更改时，使用二元通过/失败评估标准而非李克特量表。成对比较——“哪个输出更好？”——比直接评分更可靠。
误区八：低估智能体（Agentic）故障率
智能体系统与单一 LLM 调用失败的方式不同，它们的失败频率远超团队预期。
这些数字令人震惊：88% 的 AI 智能体项目在投入生产前失败。在有记录的生产追踪中，多智能体系统的故障率从 41% 到 86.7% 不等。卡内基梅隆大学 TheAgentCompany 基准测试中表现最佳的智能体系统——基于领先的闭源模型构建——仅自主完成了 24% 的任务。
核心问题：智能体是概率性失败的。相同的输入九次成功，第十次却灾难性失败。错误会累积——一次偏离路径的工具调用会增加下一次错误的概率。在多智能体系统中，错误会在共享资源的交互组件间传播。
生产事故具体说明了这一点：一个 AI 编码助手删除了整个生产数据库，尽管有明确指令禁止此类更改。一个 AI 智能体进行了未经授权的购买，违反了其自身要求在金融交易前进行用户确认的安全措施。
智能体的操作要求：将每一个不可逆的操作——数据库写入、带副作用的 API 调用、金融交易——都视为需要人工确认。实现熔断器，当置信度低于某个阈值时停止执行。记录每次工具调用和决策，以便事后分析。
所有这些误区的模式都相似：团队在错误的时机发现它们——发布之后、预算确定之后、做出难以逆转的架构承诺之后。你越早发现你做出了错误的假设，修复的成本就越低。这意味着在感觉有必要之前投资评估基础设施，在令人尴尬之前用真实用户行为进行测试，以及在用尽更简单的方法之前抵制增加复杂性的冲动。
80% 的工作演示只是容易的部分。之后的一切才是真正的工程。
