AI 项目的失败案例复盘——我亲历的 3 个失败，原因和教训
AI 项目的失败案例复盘——我亲历的 3 个失败，原因和教训
适读人群：正在做或准备做 AI 项目的工程师
阅读时长：约 20 分钟
文章价值：真实失败案例 + 深层原因分析 + 可避免的工程教训
为什么要写失败
这篇文章写起来比较难，不是因为技术上难，是因为写失败要honest。
网上关于 AI 项目的分享，大部分是成功案例：「我们把某某公司的效率提升了 60%」「RAG 系统准确率达到 92%」。很少有人写失败，写了也是轻描淡写带过，没有细节，没有真正的反思。
我理解为什么——写失败需要勇气，会显得不专业，可能让客户或者潜在客户对你失去信心。
但我觉得失败案例的价值比成功案例大。成功案例告诉你「做对了什么」，失败案例告诉你「做错了什么」，而后者更容易直接应用。
以下是我亲历的三个失败，每一个都有具体的技术原因和业务原因，我会尽量说清楚「为什么会这样」，不只是「发生了什么」。
失败一：过度工程化的 Agent，实际上简单 RAG 就够了
事情经过
大概是一年半前，一家制造业客户找我做「设备维修知识库」。需求描述是：维修工人在现场，拍一张设备照片或者描述一个故障症状，AI 给出维修步骤和注意事项。
这个需求听起来不复杂。但我当时处于一个「迷上 Agent」的阶段，刚研究完 ReAct、Tool Use、Memory 那套东西，觉得这是大展身手的机会。
我设计了一个「维修专家 Agent」：
- 多工具调用：查设备手册、查维修记录、查配件库存、查天气（用于判断是否适合户外设备维修）
- 多轮对话记忆：记录每台设备的历史维修情况
- 自主规划：AI 自己决定先查什么信息，再做什么推断
- 多模态：图片识别故障部位
我花了六周开发，又花了两周调试，系统跑起来了。演示给客户看，他们觉得「很酷」。
然后开始小范围测试，找了 10 个维修工人试用。
一个星期后，反馈回来了。
「这玩意太慢了，我在现场等不了那么久。」
「有时候查一个问题，转了好几圈才给答案，我不如直接翻纸质手册。」
「它问我'天气情况如何'，我在室内修设备，跟天气有什么关系？」
我做了分析：维修工人在现场，最核心的需求是「快速」。他们要的不是 AI 帮他们「思考」，是 AI 帮他们「查找」。一个能快速检索设备手册、给出相关维修步骤的系统，就完全满足需求了。
Agent 的复杂性带来的延迟（每次要 8-15 秒）、不确定性（不知道 AI 接下来会做什么）、冗余查询（查天气的操作毫无意义），全都是负价值。
深层原因
技术原因：我把「技术上可以做」和「这个场景需要」混为一谈。Agent 是一个很好的技术范式，但它适合的是需要多步骤推理、需要自主规划的复杂任务，不适合「快速检索 + 结果呈现」这种简单需求。
业务原因：我没有认真做用户研究。维修工人的使用场景是：现场，手脏，可能嘈杂，需要快速，不能等待。我想象中的用户是坐在电脑前有充裕时间思考的工程师，完全不是实际用户。
结果
我推倒重来，用了两周做了一个简单的 RAG 系统：用户描述故障症状或上传设备型号，系统检索设备手册里的相关章节，直接返回。平均响应 2 秒以内。
用这个版本重新测试，满意度从一版的 3.2 分（满分 5 分）提升到了 4.6 分。
两周的工作，做出了六周都做不好的结果。
教训
在开始设计之前，先定义「用户最关键的一个需求是什么」。 在这个场景里，最关键的需求是「快」，不是「智能」。如果我一开始就把这个问题问清楚，就不会走弯路。
技术选型的原则是「最简单能解决问题的方案」，不是「最先进的方案」。 这句话很多工程师都知道，但在面对新技术的诱惑时，很容易忘掉。
失败二：没有做用户验收，上线后发现和预期偏差很大
事情经过
第二个失败是一个客服 AI 项目，给一家电商公司做智能客服。
这个项目技术上做得相当好，从各种指标看都不错：
- 在测试集上准确率 88%
- 平均响应时间 1.8 秒
- 在我们自己设计的 100 个测试问题上，通过率 91%
我们做了大量内部测试，也做了单元测试、集成测试，感觉准备很充分，就上线了。
上线第三天，客服团队的负责人来找我，语气很不好：「你们的 AI 让客户投诉了，你知道吗？」
我一脸懵：「准确率 88%，这很正常吧？」
他说：「用户问'我的包裹为什么还没到'，你们的 AI 回答了各种关于快递的知识，但就是没有告诉他怎么查自己的包裹在哪里，也没有给客服联系方式。客户以为 AI 在敷衍他，直接在差评里写'机器人废话连篇'。」
我拿出测试集一看，我们的测试问题是：「快递延误的常见原因有哪些？」「物流公司有哪些服务保障？」……这些都是知识性问题，AI 答得很好。
但真实用户问的是：「我的包裹 3 天没动静了，你帮我联系一下快递公司可以吗？」「我订的东西说今天到，为什么还没来？」——这些是需要操作的问题，需要查单号、需要联系快递、需要有明确的后续步骤，不是知识问答。
我的测试集和真实用户的问题完全不在一个维度上。
深层原因
技术原因：测试集的设计有根本性缺陷。我设计测试集的时候，是从「AI 能答什么」出发，而不是从「用户真正会问什么」出发。这两者之间的偏差，就是系统上线后表现和预期的偏差。
业务原因：没有做用户验收测试（UAT）。正常的软件项目，上线前业务方会做验收测试，确认系统满足他们的实际需求。但 AI 项目在当时还是新鲜事物，客户方也不知道怎么验收，默认就是「工程师说好了就上吧」。我没有主动推动这一步，是我的失误。
结果
紧急修复花了两周，主要工作是：
- 从已上线的真实对话日志里，提取真实用户问题，重建测试集
- 补充了「操作引导型」的回答模式：问题涉及具体订单操作时，不给知识，给步骤和联系方式
- 补充了「人工转接」的触发逻辑：当 AI 判断自己无法有效解决问题时，主动提供转人工选项
修复后，投诉率下降了 70%，客户满意度回升。
教训
测试集要从真实用户问题里来，不能自己想象。 如果没有上线前的真实问题，可以让客服团队提供最近一个月的真实咨询记录，从里面抽取典型问题。
AI 项目必须做用户验收测试，而且要让实际使用者参与，不是技术人员。 技术人员知道系统的能力边界，会绕开系统不擅长的问题；实际用户不会，他们怎么想就怎么问。
一定要设计「兜底」机制。 AI 不能解决的问题，要有明确的出口（转人工、提供联系方式），不能让用户在 AI 那里转圈转到放弃。
失败三：数据质量问题被忽视导致 RAG 效果差
事情经过
第三个失败是最近的，发生在一个法律行业的 RAG 系统项目。
需求是：律师助手，能快速检索公司内部的案件文档、法律意见书、合同模板，提高律师的工作效率。
技术方案挺扎实：Milvus 向量数据库，Qwen 系列嵌入模型，GPT-4o 做问答生成，文档分块策略也经过仔细设计。从架构角度，这是一个规范的 RAG 系统。
上线后两个月，使用率一直起不来。跟律师们聊，得到的反馈出奇地一致：「查不到想要的东西。」
我一开始以为是检索算法问题，调整了相似度阈值、增加了混合检索……没用。
后来我做了一个操作：随机抽了 30 份文档，逐一查看原始内容。
然后我理解了问题所在。
这批法律文档的来源极其混乱：
- 有直接从 Word 导出的 PDF，格式完整
- 有扫描件 OCR 后的文档，有大量识别错误（「第二十三条」被识别成「第二十三冬」，「合同」被识别成「合詞」）
- 有直接把邮件线程另存为 PDF 的，包含大量无关的邮件头、签名档
- 有手写注释被 OCR 进来的，完全无意义的字符串
- 有多个版本的同一份文件，标题完全一样但内容有差异（哪个是最新版完全看不出来）
更严重的是：这些文档里有些包含敏感的客户信息，在知识库构建的时候，没有人做脱敏处理。理论上，如果 AI 检索到了这些内容，可能会把一个客户的案件信息透露给另一个客户（在某些巧妙的提问下）。
我之前以为数据质量问题就是「有些文档格式不对」，没想到是这个程度。
深层原因
技术原因：数据质量的验证缺失。我在系统开发阶段，用的是一小批样本文档，这批文档是人工精选的，质量很好。真正入库的时候，是客户方直接把文件夹压缩包给了我，我直接跑了向量化脚本。没有做数据质量评估，没有做清洗，没有做内容验证。
业务原因：客户方没有数据治理意识。他们以为「把文件给你，你做就好了」。公司十年积累的法律文档，没有统一的命名规范，没有版本管理，没有分类整理，是一堆历史遗留的文件堆。这不是他们的错，这是大多数中小型公司的现实。我有责任在项目启动时把这个问题说清楚，结果我没有。
结果
这个问题的修复成本非常高。因为核心问题是数据，所以要重新处理数据：
- 建立数据质量评分机制：OCR 置信度、内容完整性、重复文件检测，每个文档打分
- 低分文档：人工审核确认后再入库，不自动入库
- 脱敏处理：识别并脱敏客户姓名、案件编号、联系方式
- 版本管理：引入文档版本标注，同一文件的多个版本只保留最新有效版
这些工作花了将近一个月，而且需要律师事务所自己的人参与（他们要认定哪些文件是有效的、哪个是最新版）。
修复完成后，检索准确率从主观评价的「查不到」提升到了 80%+ 的「查得到」。
教训
数据质量评估要在项目立项阶段就做，不是上线前。 如果数据质量差，这是项目风险，需要明确的时间和成本来解决。不把这个风险暴露出来，到时候是项目延期或者系统质量差，后果更严重。
客户交付的数据，不能默认是「可用的」。 要做数据勘探：随机抽样 50-100 份文档，人工查看，评估数据质量，估算清洗工作量。
数据安全在知识库构建前必须处理。 法律、医疗、金融这些涉及客户隐私的行业，脱敏是前提，不是可选项。
三个失败的共同模式
回头看这三个失败，有一个共同点：都是在「开始做之前」就埋下了的问题，不是做到中途出现的问题。
失败一，技术选型过度，是立项时的决策问题。 失败二，测试集偏差，是项目启动时的方法论问题。 失败三，数据质量被忽视，是立项时的尽调不足问题。
这三个问题，如果我在项目开始前各花一到两天时间认真回答几个问题，都可以提前发现：
用户最关键的一个需求是什么？现有技术方案是否与这个需求匹配？（解决失败一）
我的测试集是从哪里来的？它代表的是技术能力还是用户实际需求？上线前谁来验收，怎么验收？（解决失败二）
数据从哪里来，质量如何？有没有安全风险？我看了多少真实文档？（解决失败三）
三个简单的问题。每个问题如果认真回答，可以省去几周甚至几个月的返工。
「失败」值多少钱
写这篇文章的时候，我算了一下这三个失败的成本：
失败一：六周开发白做，加两周重做，损失约 8 周工时，项目延期交付。 失败二：紧急修复两周，加上客户关系损害，差点丢了后续合同。 失败三：一个月数据修复，使用率低迷了两个月，客户续费谈判受阻。
如果把这些成本换算成「每个失败能买几次问题前置检查」，是完全不成比例的。
但这种算法有个问题：在项目开始的时候，花时间做这些检查，感觉像是「浪费时间」，因为那时候还没有失败，不知道失败的代价。只有失败之后，才会觉得「当初多花一天时间就好了」。
这是一种认知偏差，解决方法只有一个：把这些检查动作变成习惯，不管每次是否感觉有必要，都做。
结语：失败没有那么可怕，但要用足代价
这三个项目，两个最终成功交付（修复之后），一个合同续签了但关系受损。从商业结果上，没有造成特别惨烈的结局。
但我学到的东西，是几年顺风顺水都学不到的。
我现在遇到新项目，固定会做几件事：
- 找 5 个真实用户，看他们最核心的一个需求是什么，不是我想象的需求
- 在设计技术方案之前，先问「最简单能解决问题的方案是什么」
- 在接触数据之前，先随机抽样 50 份，亲自看
- 在上线之前，让实际使用者做一轮验收，不是技术团队
这四件事加在一起不超过一周，但能避免 80% 的方向性失误。
失败没有那么可怕。可怕的是失败了，花的代价没有买到足够的教训。