剖析RAG之父所说的：数据处理才是RAG系统的护城河！

掘金前端

作者华洛

2025年5月19日 07:56

RAG之父Douwe Kiela在一场演讲中，提到了这样的论点：内部知识是我们的竞争壁垒，数据处理是我们的护城河。

"大规模处理企业数据的能力才是护城河，重点要放在让AI有效处理大规模、多元和含噪数据上，而非过度清洗数据。" Kiela格外强调了这句话。

这一点与我这几年的实战经验非常契合。

这是很多AI产品失败的原因之一：数据准备过度理想化。

很多产研团队觉得他们在测试阶段测试数据的准确率等于生产环境的准确率！

这是一个很荒谬的误区，我们的测试数据通常都是标准的理想化的数据占比更多，杂乱的、喊噪音的数据占比更少，但是生成环境其实正相反：杂乱的、喊噪音的数据占比更多，反而标准的数据占比更少

就行Kiela在演讲中的案例：某银行的AI诈骗检测系统在试点阶段准确率达95%，但部署到生产环境后跌至62%。

真实世界数据总是混乱的，能处理不完美数据的系统才是王道。构建处理真实世界数据的能力，比幻想完美数据集更实际。

RAG工程解决方案

下面给大家看一下我们是如何增强我们RAG系统的数据处理能力来解决的一些标准RAG无法解决的问题：

只能进行文本回复，无法提供相关的图片、视频等能力。

RAG系统想要加入图片、视频等能力，有两种方案可以解决：元数据和描述。

第一种方案：元数据是应用在结构化数据中，在结构化数据中添加有meta字段，meta字段代表着与我们的这条数据有关的其他数据。

当用户的query在知识库检索时检索到了我们这条数据，我们就可以根据meta字段进行相应的图片\视频等内容的输出。

例如，在售前场景中。我们有一批专利图片，我们要利用元数据的方案就要在我们的excel中加入图片地址信息：

当用户询问专利相关问题时，我们的程序会获取到meta字段，还记得方才我们说的那个知识库响应内容content字段么？

meta字段就在里面，我们的程序拿到后就可以进行处理，返回给前端显示对应的专利图片。

第二种方案：描述是应用在非结构化的数据中，通过自然语言对图片\视频进行描述，然后把描述文案向量化之后添加到向量数据库中。

这样当用户的query和我们向量数据库中的内容进行匹配时，就可以匹配到一个图片信息，然后我们的大模型可以根据描述介绍图片，我们的程序可以根据信息返回图片。

还是刚才那个例子我们有一批专利图片，如果是使用描述的方案：

我们可以进行专利的描述，然后把描述文案加入到向量数据库中：

企业申请的XXX专利。
企业获取的XXX授权。
企业的国际PCT专利。

当用户询问专利相关问题时，知识库就会检索到相关的内容，我们就可以进行图片化的回复了。

如果用户query不标准，问题不全，我们的知识库可能匹配不到内容。

这个问题的出现是因为：RAG系统本身是不支持上下文的：

例如，我们先问：你们企业有哪些授权？ AI回复之后，我们又问：专利呢？

这时需要进入RAG系统参与匹配的应该是你们企业有哪些专业？而不是专利呢？

所以这时候就需要上下文分析的能力来分析上下文得到用户的真实问题你们企业有哪些专业？

我们的解决方案是使用提示词来进行上下文分析 + query改写。

上下文分析提示词如下：

## 业务知识

【这里根据自己的业务场景，添加必须让大模型知道的业务知识，例如对某些名词的解释】

## 要求

- 根据user的上下文对话，分析出user本次对话的真实意图。
- 必要的知识放在【业务知识】中，查询业务知识的信息与user对齐概念。
- 把user最终的真实意图转化成与上下文文风一致的问题后直接输出，不要输出分析过程
- 输出格式为{user:真实意图}

## 上下文

question：【上一次分析的结果query】
answer：【回复内容】
question:【用户本次query】

## 输出

上下文分析 提示词用在解决使用RAG系统时，问题需要有上下文关联性的场景，可以帮助我们获得完整的用户意图。

query改写提示词如下：

## 业务知识

【这里根据自己的业务场景，添加必须让大模型知道的业务知识，例如对某些名词的解释】

## 要求

- 对问题进行一次改写，改写为一条新的问题。
- 需要保持语义一致性，核心意图不变，允许根据上下文扩展关联信息。
- 如果只有一个名词，用户的默认意图是需要解释。
- 用词保持简单，保证新问题是一句话，没有过多的冗余内容。
- 改写标准为主语 + 谓语 + 宾语的标准语法，不要使用倒装句等其他语法。
- 输出格式为{user:新问题}

## 上下文

question：【上一次分析的结果query】
answer：【回复内容】

## 问题

【用户本次query】

## 输出

query改写 提示词用在我们为了提高准确性，会通过改写query，对RAG系统进行多次匹配的场景。可以帮助我们把用户的非标准问题改写成更容易匹配我们的知识库的问题。

比如这个提示词，我们的知识库中全都是主谓宾组成的标准语法，那么我们就更希望把用户的问题也全部改成主谓宾的标准语法。

知识库中的内容仍然存在匹配错误的情况。例如：用户问A产品的价钱，我们知识库筛选出了B产品的价钱，然后回复给了用户。

这个问题的出现是因为：RAG系统是根据语义进行匹配的，虽然现在大家都是用混合检索了，但是在匹配的过程中还是会出现匹配错误的情况

我们当然是不允许把错误的信息返回给用户的。

所以在匹配到答案之后，需要再验证一次这个答案是否解决了用户的问题。

例如：用户问A会议的开始时间，我们拿到了B会议的信息，其中也有开始时间。如果不做相关性验证，就对用户造成了误导。

提示词如下：

## 业务知识
【这里根据自己的业务场景，添加必须让大模型知道的业务知识，例如对某些名词的解释】

## 资料
【知识库匹配出来的答案】

## 问题
【用户的query】

## 要求

- 必要的知识放在【业务知识】中，查询业务知识的信息与user对齐概念。
- 判断资料是否能够有效的回复user的问题。
- 如果资料是有效的，返回'''Y'''，否则返回'''N'''，不要输出任何其他内容。

## 输出

当相关性验证没有通过时，我们还可以调用query改写，再进行重试。或者把知识库匹配到的问题直接以相似问的形式返会给用户。

query改写的逻辑是把query的语法、用词等修改成和我们的知识库中存的数据相似性高一些的新query，以此来增加匹配度。
相似问的逻辑是我们把问题抛回给用户，让用户自己进行选择他想问的问题或者重新提问。

经典的中文二义性问题。用户的问题可以用A来回答，也可以用B来回答，怎么办？

中文是具有的二义性问题的:

能吃多少吃多少？，是多吃点还是少吃点？
咬死了猎人的狗。，是要死了猎人的狗，还是猎人的狗被咬死了？

这些二义性问题还可以根据上下文来大概进行判断，但是还有一些二义性问题，就无法利用上下文了，例如：

Q1：清华大学怎么样？ Q2：计算机专业怎么样？

用户是问计算机专业怎么样？还是清华大学的计算机专业怎么样？，这种问题结合上下文和不结合上下文是完全两个问题。

对于这种场景的问题，给大家分享一个我的解决方案，两个问题答案我们都回复给用户，利用结构化的表达方式，无论用户的真实意图是哪一个，都可以感受到被回答了。

回复示例：

【内容一：计算机专业介绍，回复计算机专业怎么样】
上下文衔接内容
【内容二：计算机专业的前景、发展等内容】
上下文衔接内容
【内容三：清华大学的计算机专业优势、介绍。】

既然回答哪个都有可能是错的，那么我们就全都要，全部回复即可。

结语

传统的RAG目前比较主流存在的问题有以下几个：

知识库内容缺失：现有的文档其实回答不了用户的问题，系统有时被误导，给出的回应其实是“胡说八道”，理想情况系统应该回应类似“抱歉，我不知道”。
TopK截断有用文档：和用户查询相关的文档因为相似度不足被TopK截断，本质上是相似度不能精确度量文档相关性。
上下文整合丢失：从数据库中检索到包含答案的文档，因为重排序/过滤规则等策略，导致有用的文档没有被整合到上下文中。
有用信息未识别：受到LLM能力限制，有价值的文档内容没有被正确识别，这通常发生在上下文中存在过多的噪音或矛盾信息时。
提示词格式问题：提示词给定的指令格式出现问题，导致大模型/微调模型不能识别用户的真正意图。
准确性不足：LLM没能充分利用或者过度利用了上下文的信息，比如给学生找老师首要考虑的是教育资源的信息，而不是具体确定是哪个老师。另外，当用户的提问过于笼统时，也会出现准确性不足的问题。
答案不完整：仅基于上下文提供的内容生成答案，会导致回答的内容不够完整。比如问“文档 A、B和C的主流观点是什么？”，更好的方法是分别提问并总结。

总的来看：