在企业级RAG系统中需要关注和优化的点 原创

“ 想做一个RAG项目很容易，但要想做好一个RAG系统却很难。”

最近手上的一个RAG聊天类项目也算接近了尾声，虽然从功能上来说项目已经完成了；但从质量上来看，其实离真正的完成还差了老大一截，原因就是做出来了，但没做好。

因此，今天我们就来基于这个项目做一个基本的项目总结，看看在一个企业级RAG系统中，到底存在哪些问题，以及应该怎么做。

企业级RAG

还是那句话，RAG从技术的角度来看主要是三个部分：

1. 文档预处理

2. 文档召回

3. 生成增强

所以，我们就从这三个角度来看一下在真正的企业级项目中应该怎么做。

文档预处理

文档预处理一直都是RAG系统中的一个技术难点，原因就在于无格式的复杂文档处理；典型的就是word，pdf这种图文表混合的文档，目前为止还没有一个很好的解决方案。

但技术的发展是一个线性的过程，并不能因为存在问题就不管了；因此，面对这种问题我们需要在贴合业务场景的前提下，尽量的把这些存在问题的影响降到最低。

在这里我们需要强调，也是需要注意的一件事；文档预处理之前一定要搞明白你的业务场景，不同的业务场景对文档处理的要求也不尽相同；比如说你是业务咨询类场景，这时你可能主要需要的是一些文字描述类文档；而如果你是技术咨询类场景，可能还需要大量的架构图，方案设计等。

前者我们可能只需要使用ocr技术或者直接把文档中的图片给丢掉即可；而后者可能需要使用多模态技术，把文档中的图 文 表给抠出来，然后进行混合检索和回答。

再说文档格式的问题，在真实的业务场景中，文档的来源很复杂包括线下文档word，pdf，excel，txt等常见文档，以及线上文档数据库，API等；数据格式也多种多样，因此需要有一个统一的文档格式来承载这些不同的文档数据，只有这样才能方便我们统一进行管理和预处理。

毕竟对于检索召回端来说，文档预处理属于前置流程，其对检索召回是无感的；所以，在文档预处理时只需要按照要求的文档格式进行处理，那么就可以完全做到文档处理和召回的分离，减少系统的耦合性。

比如作者在项目中就是把所有格式的文档都处理成markdown格式，这样就可以进行统一的管理和向量化。

当然这里文档转换成markdown格式，并不是直接把原文档简单转换成markdown即可；而是需要对原文档进行清洗，梳理，删除一些无用和不规范的内容，尽量让markdown文档变得紧凑，舍弃部门全而不精的内容。

并且，可以对处理之后的markdown文档进行总结提炼——summary，以及提取标签；这样在检索端就可以使用标量召回和相似度召回，提升召回率。

文档召回

在第一步文档处理过程中，我们在尽可能保证文档质量的前提下，第二步要关注的就是文档召回的方式问题了。

在文档召回过程中，我们首先需要对用户的问题进行处理；这里的处理包括问题的完善和优化，提出相似子问题，以及最后的兜底问题等。

原因主要在于，用户在提出问题时除非特别专业或了解相关内容；否则很多情况下，用户自己可能都不知道到底应该怎么提问题，以及问题中会存在语义不通顺，错别字等情况。所以，对问题进行改写优化，并从多个维度提出几个相似性问题，有助于提高召回率。

其次，可以根据用户的问题提取标签，这样就可以根据这些标签进行标量检索，这样能够大大提升准确率以及查询效率；毕竟简单的字符匹配相对应向量计算要快得多。

之后，通过多种方式召回数据之后，最后需要对召回的数据进行去重，排序等操作；把相似度最高的数据丢给大模型，而不是把召回的所有数据都丢给大模型。

生成增强

在完成数据召回之后，并不是说这些数据就直接丢给大模型，我们还需要对这些数据进行处理；否则会存在很多问题。

比如说，你最终召回的数据是一个文档列表，我们是否能够先把这个文档列表转换成一段完整的文档；而不是一段一段好像无关的文档列表。

其次，由于模型上下文窗口有限，特别是在多轮对话中，我们可能还需要对召回的文档进行提炼总结之后再丢给模型；以及对历史记录进行压缩；一是为了防止上下文超长导致内容丢失，二是上下文过长会导致模型处理质量下降。

最后，在一些业务场景中，可能还需要给用户展示参考文档，以及源文档；这时我们还需要处理好文档的格式，否则给用户看到一堆没有格式的乱七八糟的内容，也会影响用户体验。

本文转载自​​​AI探索时代​​​ 作者：DFires