在企业开发中——RAG技术常见的问题以及解决方案

虽然说现在大模型的主流应用方向是智能体——Agent；但也不能否则RAG在其中扮演的重大作用，因此RAG也是企业应用场景中经常用到的技术。但RAG虽然看起来很简单，但事实上存在很多问题和坑；还是那句话想把RAG做出来很简单，但想把RAG做好就很难。

以作者自身遇到的问题为例，一起讨论一下RAG各个环节中存在的问题和优化方案。

从技术的角度来说，RAG主要存在三个阶段，文档处理，数据召回，增强生成；其中这三个阶段最后一个阶段最简单，就是把召回的内容丢给模型，让模型根据这些内容进行处理；所以，RAG的难点主要在前两步，文档处理和数据召回，数据召回的质量直接影响到生成质量。

文档处理

所谓的文档处理本质上就是把外部文档处理成向量格式然后通过相似度计算的方式进行语义召回。

当然，RAG并没有限制必须把文档处理成向量格式，也没限制必须要进行相似度召回；RAG的目的是快速准确的找到和问题相关的内容，因此使用任何召回方式都可以，包括传统的字符匹配和现在的语义查询。只不过对于非格式化数据，以及基于自然语言对话的展示场景，使用相似度语义检索更符合业务场景。

文档处理之所以是一个难点，就在于其复杂的文档格式；如txt，word，pdf，markdown，excel，csv等等很多种格式，并且这些格式的数据没有一个统一的规范，虽然excel和csv是格式化数据，但在不同的业务场景中可能需要不同的处理，比如有些场景中只需要按列处理即可，而有些场景中可能需要解析表结构，然后拼接成markdown或合并部分列数据。

因此，文档处理中文档的类型，复杂的内容格式，对格式化的不同要求，以及文档的管理都是难点；毕竟如果文档处理的不好，会直接影响到第二步数据的召回质量。

所以，文档处理的难点其中之一，就是怎么根据不同的业务场景去规范文档的处理流程及格式；其次，就是类似于word，pdf这种复杂的文档类型，由于其没有固定的格式，以及其同时支持多种不同模态的数据(文字，图片，表格，架构图等等)；导致其处理起来特别麻烦，很容易丢失内容原本的意义；如架构图和设计图等，很难在向量化之后还保持其原本的意义。

当然，虽然现在使用多模态模型能够从一定程度上解决这个问题，但从成本和复杂度来说，好像又不是很值得。但基于orc等技术处理的复杂文档会丢失大量的有用信息。

向量数据的保存

其次是向量化数据的保存，之前的数据大多使用关系型数据库进行保存，并且其表结构和数据可以随时调整和修改；但向量化数据库由于其特殊性，导致其并不能像传统数据库那样随便进行编辑和修改；因此，刚开始设计的向量数据库随着业务的发展很难适应新的业务变化，但其调整起来又特别复杂，特别是随着业务数据的增多，导致其维护其它特别麻烦。

数据召回

数据召回的目的是根据用户问题，从大量的知识库中找到与用户相似度最高的文档内容，然后交由模型进行增强生成；但是面对语义召回这种本身就不确定的召回方式会出现两种情况，一种是无法召回有效数据，另一种是召回大量不相关数据；而不论哪一种都会对下一步的增强检索造成严重的影响，毕竟模型无法判断你提供的文档质量。

因此，面对这种情况需要从多个维度来提升召回质量，一是在召回侧，通过完善用户问题，提出子问题，假设性文档召回(hyDE)，标量召回等。其次，就是在文档处理端，对文档进行提炼总结，增加多个维度的相似度计算。

增强生成

虽然说增强生成比较简单，但其实也挺重要的；在上一步的数据召回时，有时为了提高数据的召回质量会添加很多无关字段，因此在正式把召回数据提交给模型之前，我们需要对文档数据进行清洗和格式化处理；比如删除一些无关字段，把文档转换成模型更好处理的格式等等。而不是直接把召回内容一股脑的全部丢给模型。

当然，以上只是传统的RAG处理流程，目前随着智能体技术的发展，智能体技术也逐渐被应用到RAG中；原理就是借助智能体的强大的工具使用能力，以及自主决策能力，让RAG系统能够动态获取外部数据的能力，而不是只是人工处理好的死数据，比如说使用浏览器进行网络搜索。