“ 在RAG系统中，业务比技术更重要；好的业务和设计能大大减少你的工作量，并提升召回率。”
在刚开始做RAG的时候，认为RAG很简单；虽然说文档处理是一个难点，但那也是没办法的事，毕竟这玩意在业界就是一个难点；但随着这段时间做RAG的数据处理和优化才发现事情远远没有自己想的那么简单。
虽然说复杂文档处理是一个难点，但那并不是你做不好RAG的理由；原因就在于你根本没有弄明白，怎么才能做好一个RAG系统；你所认为的RAG就是简单的把文档处理拆分一下，然后向量化入库就算完成了一个RAG系统。
但RAG真的有那么简单吗？
怎么做好一个RAG系统？
再次强调一句话——做RAG需要弄明白两件事，一是RAG到底是什么，二怎么才能做好一个RAG系统？
先问自己一个问题，你真的了解RAG吗？
只要在网上看过几篇关于RAG的文章，很多人对RAG都会有一个基本的认识；但是，你真的让他做一个RAG系统出来，你会发现到处都是问题，表面上看着系统是做出来了，但是召回率一塌糊涂，做是做出来了，但是不能用。
原因就在于你没有真正理解什么是RAG，以及应该怎么做一个可以用的RAG系统。
首先，理解RAG有两个层面，一个是技术面，一个是业务面；网上关于RAG技术的介绍已经有很多了，这里就不再详细赘述，总之就是RAG的核心就在于文档处理和数据召回两个方面，以及最后丢给大模型的文档质量。
下面我们从两个角度深入讨论一下，怎么做好一个RAG系统；可能很多人都会认为，RAG的核心在于技术，事实上RAG的核心不在技术面，而在业务面，因为业务决定了你RAG的应用场景，而技术只是具体实现的一种方式。
为什么说RAG的核心在于业务？
因为不同的业务系统对RAG的要求是不一样的，这里的不一样包括很多方法；比如说文档的类型，格式，处理规范会不一样；其次，宽泛的文章写作和严格的医疗，法律对RAG的要求也不一样。
以作者现在做的日常咨询类场景为例，我们对RAG的召回率要求在百分之90以上；文档的主要形式是word，pdf，excel和数据库数据。
由于系统要求的是以自然语言对话的方式，来提升部门的办事效率；因此，对所有文档都需要进行向量化处理，这样才能更好的进行自然语言对话，毕竟对用户来说，他们并不是专业人员，很多术语和名词，他们也不知道是啥意思；所以，基于自然语言对话，让大模型去理解用户的意图，然后用相似度匹配的方式召回相关内容是一个很好的选择。
所以，面对这样的业务场景和多种不同的文档格式，我们需要一个统一的载体对文档进行处理；毕竟，word和excel是完全不同的两种数据格式；而我们表格和图片类数据又不多。
因此，我们选择的是markdown格式作为我们的主要载体，原因就在于word，excel，包括数据库数据都可以处理成markdown格式；而且markdown和xml，html这种结构化的数据格式相对比较干净和简单；完全非结构化的数据格式，如txt由于没有标题，段落等，不利于理解和处理。
而且，其也不像json等支持的数据有限，如图片在json中表示只能使用图片地址或base64，但这对模型来说根本没有任何意义。当然，如果说你的文档充满大量复杂布局的内容，如图片位置，多栏布局等，那么markdown就不是一个好的选择了。
总之，之所以选择markdown的原因就在于其对人类比较友好，对模型也比较友好；最重要的是其适合我们的业务场景。
其次，从技术层面来说，把不同格式的数据转换成markdown形式，也比较好处理；word，pdf等可以直接转换成markdown格式；而excel，也可以通过解析的方式拼接成markdown。
再有，对文档数据的处理，很多人在做RAG时，文档处理就是把文档一股脑的丢到向量库中；但事实上，很多文档充斥着大量的噪音和无用数据，这些数据完全可以给删掉，而不会对我们的业务产生任何影响，或者说唯一的影响就是好的影响。
在文档处理中，我们首先要删除掉噪音数据，其次还要对完整的数据做出选择；比如说，某些场景下时间是很重要的数据，但某些场景下时间是无用数据；总之，在不同的业务和场景中，选择合适的数据，比你累死累活的优化文档处理流程更重要；毕竟如果从源头上就错了，那么后续做的再多再好又有什么用。
再有，之所以选择markdown做载体，原因就是因为其简单的结构化格式；不同的数据和场景要求，使用不同的结构化形式，能够大大提升召回率，；比如说使用标签对数据进行分级等，而不是你累死累活的想办法去优化召回策略。
总之，想做好一个RAG系统你技术是一方面，更重要的是你的业务和要求；千万不要搞反了。
