DeepSeek在保险问答场景里如何秒杀一众AI的真实记录

本文使用真实大型企业 AI项目中的一个小小复杂场景PK DeepSeek和其它7个最著名的大模型的全过程记录，从此记录可以看到我们的DeepSeek有多强。

TGITCIC

1095人浏览 · 2025-03-19 19:32:11

TGITCIC · 2025-03-19 19:32:11 发布

背景

DeepSeek可真不是吹出来的，而是真的有实力。

我们用一个正在实施中的大型保险公司（1,000万条语料），272个上百页书、条款的Word, Pdf灌入我们的Rag库里进行问答，并对其使用不同的LLM进行SOTA类测试，下面的结果相当惊人。先说结果：

我们还没用满血版DeepSeek，只是Ollama上布署的DeepSeek 14b，结果秒杀了几乎一切其它满血版或者是一些视频号喜欢吹的大模型。

下面就带大家来看过程。

真实保险案例场景

语料/自有知识库

领域：保险领域
近1,000万条数据（chunk）；
272个每一个上百页的PDF;

RAG库架构

ES、Mongo、mySQL、Oracle混合召回；
LLM改写
折分时使用了：固定size+段落判断+语义折分+语义再组合以扩充和贯连上下文折；
重排序
最终送给LLM；

LLM改写猫娘核心部分

- 当前客户的提问为：$<prompt>。历史提问为$<historyPromptList>
- 关聊用户的历史提问上下文以及当前提问，判断客户的提问是否存在：过于宽范，过于简单，打招呼闲聊等问题导致搜索结果不准。
- 你首先把客户的提问中相关的敬语，打招呼等词汇去除掉。
- 如果用户在提问中使用的问法词法或者提问有逻辑不对的地方请你帮用户纠正一下。
- 在折分用户词语时要同时使用同义词、近义词、语义相近的词去扩充用户的提问。
# 打标签折关键字特别要求
- 请你以公司相关规章、制度、条款、操作手册、保险相关条条款的解读的专业背景知识想一下作为这样一个专业领域的在线客服在线搜索引擎会用到哪些关键字以便于用户在提出相应的诉求后快速可以检索到相关的知识库内的答案？请你把这些标签折成搜索引擎可以适合的关键字每个关键字。
- 按照一个搜索引擎可以搜索出的最大有效关键词重新折解客户的提问为带有英文数字逗号的关键词排列，关键字颗粒越细越好就和搜索引擎的分词那种效果一样。
- 折解时注意要把越能命中搜索结果的关键词越往前排，把称谓，动词放到整句提问的最后（即句子末尾）。
- 关键字折得越多越好，关键字一定是要可以覆盖用户的提问、包括用户提问中各个词语的同义词、近义词、不同叫法以及语义相近的词都需要列出。同时请记得把你自己如何回答这个问题的答案也折成关键字加入到改写的query里。

此处，我们要求LLM在改写时不能仅仅针对用户当前的提问，而要联系上下文。

联系上下文改写的重要性

比如说，当前提问为：

请问我在吃牛排，有什么好的红酒可以配？

于是AI哗哗哗输出了一堆内容

接着正常的人是怎么问的呢？

问法1：

还有没有更多？

问法2：

继续

此时如果换成是一个“肉人”，那么她/他会很好的连贯上下文知道：

哦。。。客户刚才问吃牛排要配什么红酒，我回答了几种。
那几种客户应该觉得还不满意或者想再看看有没有更多红酒推荐？
所以让我继续推荐更多红酒可以用来配吃牛排场景用的。

所以评价一个好的AI的一个核心指标是：它可以连贯上下文，这就是推理能力。好的AI的COT如果输出其实就是上面“肉人”的思考方式，这就是思维链。

比如说GPT O1、O3都具备这个能力。

如果不能贯联上下文会导致整个RAG系统的回答不准

一个优秀的AI系统应该是AI原生的，而不是作为工具嵌入到企业系统中去，因此整个系统的任何一个部件包括规则引擎等都是AI构成的。

但是LLM在实际生产环境时会有一个特性即：逃逸。

所谓LLM的逃逸

一个固定的问答，每次答会和上一次有不一样的地方，这是多样性，这倒也没什么，但是这个逃逸最讨厌的地方在于：一些AI函数的回调会发生这样的情况。

第一次输出：

{"result": "关键字1,关键字2,关键字3"}

第二次输出：

{"result": ["关键字1,关键字2,关键字3"]}

过了几轮又输出

{"result": [{"关键字1},[{"关键字2"},{"关键字3"}]

这时如果在AI原生应用里一旦失去“兜底”机制就会引起“级联雪崩”，这个雪崩不是微服务的雪崩而是一路影响到下游调用链中的结果。

所以一个优秀的LLM的逃逸应该是可控的。

这就是今天我们要PK的点。

在我们的系统内我们可以设置多路、1主1备、或者是集群AI线路。

因此我们的系统内可以动态配置任何LLM调用。不过如果只是格式问题的逃逸还好处理，但是实际在生产环境中我们碰到的推理上产生了语义的逃逸，此时这个偏之一毫差之万里的现象就很明显了。

因此我们拿这个LLM改写的真实场景来告诉大家各LLM在同等条件下PK到底表现如何。

PK用真实生产场景

先来看系统中存在的语料

语料解释

这个是语料，是一个PDF，我们不可能去改动PDF原文。

此处讲的是一个“员工忠诚险”。

而保险标的不是指：买这个保险要多少钱而是指“这个保险保的是什么东西以及发生了如何赔”。

所以在一般情况下，我们的用户不可能像这份文档里问问题时会把话术讲得这么文皱皱和官方话，最多这样问（雇员AI要理解成员工、标的要理解成保得什么？）：

员工忠诚险，投保额是怎么样的？

此时如果AI回答后一般人会接着这样再问一句：

它的免赔额度在多少？

所以AI在第二次用户问到：它的免赔额度在多少？时，重写用户的提示词因该是写成：

员工忠诚险,免赔额度,多少,投保额,保障范围,保险条款,忠诚险保费

此时针对用户的第二轮回答在搜出相应的语料以及回答时才会更精准。

因此我们开始使用以下AI对这个场景进行测试然后来看结果。