做到 75%，客户期望 90% 以上：一个保险大模型问答项目的复盘

差的是一件事。整个项目周期里，我们和客户之间始终没有一个写在纸上的效果指标。

项目是什么

某头部寿险公司的大模型应用项目，核心是一套问答系统，覆盖 38 款保险产品，使用者是一线代理人和客服坐席。

团队九个人。技术总监是中科院博士，两个后端，一个前端，三个 AI 训练师，一个 AI 工程师，加我，负责项目管理和产品。老板全程跟着，我们的问题分析会和方案讨论会他参加过很多次。

功能全部落地之后，项目进入效果调优阶段。这个阶段我们跑的是一个固定循环。

先跑批问答数据，把 badcase 捞出来归类，逐类定位原因。我把问题现象和我们自己的归因整理成材料，约技术总监一起过。他听完回去出技术方案，再回来给我们逐条讲每个设计点解决的是哪一类问题。方案在内部推敲确认后，先跟客户对一遍，客户认可再排优先级、分工落地。落地完回到同一套问题集上重新验证，看这一轮提了多少。

然后进入下一轮。这个循环我们跑了几十遍。

第一版：FAQ 为主，60% 到 70%

第一阶段选的是 FAQ 为主的架构。

原因很实际。保险的回答不能自由发挥，费率、责任、免责、投保规则，每一句都可能被客户拿去当承诺，答错了是合规事故。FAQ 模式下答案是业务确认过的固定文本，可控性最高。我当时判断这是最适合保险公司的形态，现在也还这么看。

上线跑出来 60% 以上。

这个模式想往上提准确率，本质就是堆 FAQ 覆盖面。路走得通，代价也很清楚：需要大量 AI 训练师去写、去改，还要拉业务方逐条确认。我们在这个模式上磨了两轮，做到 70% 以上。

客户对这个模式不满意。不是不满意准确率，是不满意方式，他们认为靠人工堆 FAQ 不叫大模型项目。

方案被否决。客户坚持要以大模型自主回答为主，FAQ 只做辅助。

第二版：换成大模型为主，掉到 50% 以下

方案一切换，准确率立刻掉到 50% 以下。

这个跌幅当时看着挺刺眼，但现在想是必然的。FAQ 模式下的"答对"，是把预置答案取出来；大模型自主回答模式下的"答对"，要求理解问题、找对知识、组织答案，整条链路每一步都不出错。前者的准确率来自人工兜底，后者来自系统能力。这是两个不同的东西，数字掉下来不是退步，是终于开始度量真实水平了。

接下来一个多月，团队把整套问答流程重新规划了一遍。

最关键的一件事是重做知识切片。这是地基，前面所有的检索质量都压在它上面。

一万多条 FAQ 和产品条款不能整份丢给模型，得先切成块存起来，用户提问的时候检索出相关的几块，让模型基于它们组织答案。切片粒度直接决定检索质量：切得太大，一次检索出来的内容里有用的只占一小部分，模型要在噪音里找答案；切得太小，一个完整的责任条款被拆成两半，语义断了，检索到的那半句话本身就是错的。

第一版切法的问题在于我们是按文档结构切的，段落、条目、页码，这是文档的逻辑，不是用户提问的逻辑。用户问"这个病赔不赔"，涉及的是保险责任加免责条款两处内容，按文档结构切完它们隔得很远，检索时经常只命中一处。

最后我们改成按业务语义切：产品责任、免责条款、投保规则、费率各自成块，并且规定了哪些字段必须冗余保留——比如每个块都要带上产品全称和适用条件，因为这些信息在检索之后是模型判断"这段内容是不是我要的"的唯一依据。这份切片标准后来固化成了一份文档，成了团队的统一规范。

产品名标准化，单独带来 5 个点左右的提升。

一款产品叫「XX 尊享福终身寿险（分红型）」，代理人嘴里说的是"尊享福"，客户说"那个分红的"，还有人打字打成"尊享富"。名字对不上，检索什么都查不到。我做了一套改写模板，把全称、俗称、错别字都映射到同一个最短别名，用方括号强化权重。这是所有单项改造里收益最直接的一个。

一个多月后，以大模型为主的架构做回了 75%。首批在一家分公司试运行，覆盖了一百多个一线人员。

团队当时是振奋的。从 50% 以下重建到 75%，而且这次的 75% 和 FAQ 模式的 70% 不是一个含金量。我们准备了完整的结果数据去汇报。

汇报会上，标准变成了 90% 到 95%

会上我们把数据摊开给客户审阅。

客户领导当场提出，准确率至少要到 90% 到 95%。

在这之前，客户对效果的期望一直没有一个明确说法，这次会议上第一次落成了具体数字。同时对"什么算答对"的判定也在收紧。

我不觉得客户是在故意刁难。主导项目的是 IT 对接人，他们自己也在承压，这是公司的重点项目，总公司领导在积极关注。他们是业务出身，很难向高层解释清楚为什么开放域问答做不到 95%，压力最终只能向下传导，变成一句"你们想办法"。

我为什么判断做不到

我的第一反应就是做不到，原因不在技术，在这类问题本身。

保险问答不是封闭题库。用户会问"我买的这个和竞品比哪个好"，会问"我去年体检有个结节还能买吗"，会问"明年不交了能退多少"。第一类要跨产品对比，第二类是核保的个案判断，第三类取决于具体保单状态。这些答案不在知识库里，因为它们本来就不该在知识库里，需要人来判断。

还有一类更麻烦，问题本身就没有标准答案。"这个产品好不好"，你没办法定义什么叫答对。

而这些题，在测试的时候都在。这就意味着分母里有一部分题，无论架构怎么改都拿不到分。当剩下能拿的分已经拿了大部分，往上的空间就不在工程范围内了。

这个判断我跟技术总监交叉验证过，他给的结论一致：这就是当前架构的能力上限。

我向老板汇报的时候是这么说的：效果不是不能再提升，是不可能达到客户期望的那个高度。这两句话意思完全不同，前一句是工程判断，后一句是项目判断。

最后一次汇报老板亲自到了现场。会后他还想再努力一把，我和技术总监一起把他劝住了。

客户当然不满意。方案两次变更本身就拖了进度，结果又没到他们的预期，后来一直在追着商务吐槽。这我能理解。

复盘：问题出在哪

如果只说一条，就是项目前期没有和客户约定预期效果指标。

这一条缺失，后面所有问题都是它的衍生。它不会因为你做得好而自动出现，只会在过程中被反复重新讨论。

第二条，方案选型的决策权和结果责任分开了。

客户否掉 FAQ 方案的时候，我们已经做到 70%。换成大模型为主是客户的选择，但准确率跌到 50% 以下、重建一个多月的代价，以及最终没达标的责任，是我们承担的。我当时没有把这笔交换算清楚讲明白。换方案意味着放弃已经拿到的 70%，而新架构的上限我们那时候并不知道。这句话应该在切换之前就摆在桌面上，而不是等到项目收尾才被理解。

指标这件事，本来应该在立项阶段就定下来。当时没有人提，我也没有提。95% 这个数字第一次说出口的时候我心里已经知道做不到，可那个时间点再去谈可达性，听起来更像是在找退路，而不是需求澄清。

如果重来，开工前我会做四件事

这是我从这个项目里真正带走的东西，后面也确实用上了。

后来

这套问答流程和方法论，我们带到了下一个项目。

那个项目是一点点积累起来的，从一开始就在做指标和范围的对齐。同样的架构，同样的切片标准，同样的 badcase 闭环，现在还在正常运行。

所以我不认为这是一次失败的技术尝试。技术方案本身是成立的，它只是在一个没有锚点的项目里，被一个不断上移的目标拖住了。

写这篇之前我犹豫了一阵。行业里晒成绩的文章很多，讲没做成的很少。但对我来说，这七个月最有价值的部分不在那 15 个百分点里，而在于我现在会在开工之前，先把指标这件事问清楚。