题记

世界上本没有RAG，走的人多了就有了RAG…

现在搞2B的AI应用，没人能回避RAG。RAG确实是物美价廉的大模型应用方案，而且QuickWin效率极高，所以感觉似乎一下子人人都在讲RAG，但我觉得这里的道道还没讲透，why RAG？ 所以我冒失的开个探讨贴，希望分享下我的理解，也期待能吸引到更多的深刻思考。

PS：先吹个水，我们去年3月份学着NewBing的样子搞AI大模型问答的时候，方案跟RAG大致类似，这一年时间，也没少围着这个话题搞实践。其实当时的初衷和动机是非常朴素的，并没有太高深的突破创新，我也不建议大家一下子就钻到高深技术里去看待RAG、认为用了RAG就怎样，且开源社区里方案演进也很快，这就是个IT解决方案，而且不咋标准，优先基于业务场景解决实际问题。

目录

1. RAG本质是啥

1.1 为啥要用RAG？

ChatGPT是世界上最好的AI大模型应用，如果像OpenAI一样，训练一个特别好的模型（如GPT3.5、GPT4），特别懂行、特别能聊，满足业务需求，其实是不需要RAG的。所以走RAG的都是训不出来这个模型，本身就是个workaround，是取舍（别管为啥了）。

那么，为啥这么多人被OpenAI的路子“卡住”，然后都选择RAG，本质上是AI大模型应用有三个困难（这些我们都遇到了）：

1. LLM预训练太贵、时间太长 --> 用了RAG，又快又省又准确
   既然不能“生”一个足够好的垂域大模型，又想要让大模型活儿好，能帮你做事，最快、最省事的方式是用In-Context Learning（ICL）：在提示词里把信息放进去，也就是我们之前提到的“开卷问答”。
2. LLM上下文的长度限制，也就是context length --> 用了RAG，抓最有用的信息当“小抄”
   既然要“开卷问答”，最好的办法是带书上考场，啥都有齐了。
   但是天不遂人愿，又有个新困难，大模型的上下文窗口长度是受限的，这也就是说，老师让带小抄，但是只能用一张纸写。于是乎，做搜索引擎的同学就站出来了，说可以先把问题拿去搜一下，考啥就搜啥，最好直接把参考题答案给搜出来（mark，这里有大坑），这样就很好的解决了上下文长度问题。按需拿知识做ICL，用最有用的信息来支撑垂域作答，就是RAG的另一个好处。
   当然，现在OpenAI的GPT4-turbo可以做到128K的上下文长度，能放好几百页纸，是不是就完美了？其实这里还有个暂时无解的事儿，就是输出的耗时也与输入Token的长度成正比（准确来讲，是O(N^2D)，其中N是序列长度，D是维度）。
   所以，除非模型发展到输出效率极高，短时间内context length。都是绕不过去的话题
3. LLM直接回答问题的时候，“幻觉”很严重 --> 在上下文输入更多信息，那不就是RAG嘛
   用过LLM都懂，除非日常问法，直接上下文不给足够的信息，让大模型作答，那简直是难为人家。Zero-shot的质量大幅低于Few-shot，甚至One-shot。
   用了RAG以后，通过在提示词中加入足够的上下文信息，得益于ICL中信息的有效性高于大模型参数中的预训练信息，使得“幻觉”问题得到大幅缓解，也算是另一个收益了。

1.2 RAG到底是个啥？

如果要在自己的项目中采用RAG，首先还是先理解RAG本质是啥。先放一个微软的参考架构图：

图里我圈了三个点，是RAG的核心能力组成，分别是 **知识预处理、知识检索、知识问答 **，逻辑上非常简单。

首先，还是要深刻理解RAG的本质：

1. RAG本质上是一种工程化的解决方案，且没有标准解
   别听他们说，谁家的RAG最领先，我当然也客观承认有技术的优劣之分，但核心能解决业务问题的，还是要靠定制化的方案。比如说，RAG中的知识切片和召回，怎么切、怎么召回，都是有业务特色在
2. RAG的核心其实并不是大模型，而是搜索
   我前阵子听大家聊，现在AI应用做得好的，都有搜索技术基因。确实，这里的关键技术点和工程改进点大部分跟搜索类似，所以做搜索引擎的同学做RAG非常顺手（估计也有一些路径依赖的成分，我们团队应该就是后者，歪打正着，但确实非常朴素）
3. RAG和搜索的最大区别是，RAG还要解决信息压缩的问题
   但是RAG和搜索又不是完全一样，我认为这里最大的区别，是搜索之后的结果不需要信息压缩，我只要解决搜准的问题就行，而RAG搜出来的内容是要消费的，而且消费的时候还得压缩（就是前面说的context length的问题）
4. RAG知识召回后，效果怎么用就全看大模型的阅读理解能力
   AI大模型的阅读理解能力，其实普遍来说还是不错的，或者说，传统的NLP模型其实已经不错了。当然，也会受限于垂域的一些黑话、背景知识，这些东西如果也靠ICL补充，也不是不行，关键是又会反向来占用context length，这玩意一个是长度受限，长度不受限效果也不好。
   所以这里就最好有一个公司级的L1模型，不需要特别牛逼，但是认知上要达标。一些common的垂域信息，大模型最好能够理解（比如说 ECS = 弹性云主机，安全云脑是我们的一个云服务等等），这些信息其实就是内部公开的一些产品文档、术语、叙词表等等

2. RAG的难点是啥

基于上面这些本质的问题，推导出来，从技术上有几个关键的技术难点：

2.1 知识预处理环节，最难的就是怎么切片

知识预处理环节其实有几个事儿是比较难的，一个是文档解析（这个事儿不是今天才有，一直都存在），比如说PPT怎么理解（我们的那些豆腐块、豆腐块和豆腐块之间的关系、动效、简短而精辟的PPT辞藻，都是PPT解析的难点）。

除了文档解析，还有一个是随着RAG而来的，就是文档切片。怎么切？这一刀切下去，长度合适、两端之间分割精准、信息完整，难度不亚于庖丁解牛。这里我看到有个提法特别好，分享在这里：

Levels Of Text Splitting

• Level 1: Character Splitting ：就是直接切分文档，前后增加一段OverLap来衔接语义
• Level 2: Recursive Character Text Splitting ：基于分隔符列表的递归分块，简单说就是按一些分隔符凑块块
• Level 3: Document Specific Splitting ：针对不同文档类型（PDF、Python、Markdown）的各种分块方法
• Level 4: Semantic Splitting ：顾名思义，用语义来动态调整块大小（我最看好的一个，为毛一定要固定每段大小）
• Level 5: Agentic Splitting ：用大模型来帮你拆分文本（无非就是花钱嘛。。。）
• Bonus Level: Alternative Representation Chunking + Indexing ：为啥一定要基于原文来切？可以摘要、假设、父子结构等等

因此，知识切片，有无限种处理方式。这就是我前面提到的，知识切片可以通用化，但效果不会好，一定是结合业务场景做出来才最好。

这里我们有一些探索，也看到JX社区里的一些实践，还是建议大家多参考Langchain和LLamaIndex社区的经验。

附上几个link，供参考：

• Langchain Text Spiltter
• LLamaIndex Node Parser
• 5_Levels_Of_Text_Splitting

2.2 知识检索环节，也是一套组合拳

知识检索，分为召回和精排，就是把东西搜出来，再排个序。

这个事儿从实现上，其实确实跟传统的搜索引擎没太多区别，如果说向量检索是一个的话，那之前其实也是这么玩儿的。我们当前的做法就是在ES上加向量化插件，这块能力在没有大模型的时候，就跟华为云的CSS服务兄弟们一起搞了，现在这个能力已经商用了。

这里其实核心还是到底我拿啥来做索引，我们大致有这么一个基础的认知：

• 在QA类的知识上，用Q来做索引效果好过用Q+A一起索引，因为A的内容容易发散，影响召回质量
• 在文档类的知识上，用title+content效果更佳（由于很多时候title要生成或组装，所以如何组装title需要对业务的理解）

精排方面，如何加权，也需要业务的介入，比如哪类文档权重更高、哪些人的作品质量更好等等。

总结来说，知识检索环节的核心，是在实施上需要对业务知识的理解，以及涉及到知识管理与治理的能力介入。

2.3 知识问答环节，更多就是靠提示词和模型

我们其实在早期有SFT微调了一个问答模型，专门做阅读理解，并且限定了模型不要自主发挥，就从我给的知识里摘取、组装。

但是做的业务场景越多，这个限定就越呆板。目前新的场景我一般都会优先用提示词工程来解决，尽可能不动模型。

当然，前面也提到了，模型至少要有个基本能力认知，这个我们也感同身受，早期盘古11B的版本升级到38B以后，性能直接提升20个点，关键就是训练了更多华为云的官网数据。

所以，这里我还没有完全确定是否ICL能解决一切问题，我们自己也微调了一些场景。但是我有个模糊的感觉，中长期来看，能不去自己搞模型，就不要搞，包括预训练和微调，这玩意搞上了以后，持有成本相当高。。。

3. RAG的未来在哪儿？（TBD）

我也没想好，个人内心是觉得RAG只有很短的生命周期，但是短到几个月还是几年？我不知道。。。未完待续