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

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

项目是什么

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

团队不到十人，前后端、AI 训练师、AI 工程师都有，技术负责人是算法背景，我负责项目管理和产品。老板全程跟着，问题分析会和方案讨论会他参加过很多次。

功能落地后，项目进入效果调优阶段，跑的是一个固定循环：

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

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

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

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

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

上线跑出来 60% 以上。

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

客户对这个模式不满意，不是不满意准确率，是不满意方式。他们认为靠人工堆 FAQ 不叫大模型项目，坚持要以大模型自主回答为主，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 个百分点里。现在每接一个项目，我都会在开工之前先把指标问清楚。