RAG 项目从 0-1 和 1-100+

如果从陆奇的演讲《我的大模型世界观》刷屏开始算的话，LLM 带给我们的震撼已经超过一周年了。从去年的 4、5 月开始，很多企业一边焦虑，一边探索。大致路线分为：

1.数据资源/资产雄厚的企业，自研大模型，无论研发的模型是否开源，截止到今都或多或少了的发布了一些 LLM+的服务产品。

2.其余参与的企业中，有的选择基于已经开源的模型做微调，也有很多在化学、医疗领域做出了不错的成绩的。

3.对于大多数想要入场的企业来说选择走 RAG 路线，似乎是性价比更高的选择。

今天，我们想聊一聊，如果一家企业要用 RAG 的方式做智能应用，大致的迭代路线是什么样的？

以下述这张图为切入点：

第一部分：Copilot-应用测

这是一个非常简略的对话页面，也是目前 LLM 交付出来的大部分产品形式，当用户面向 Copilot发起提问时，Copilot 会输出对用户问题的解答，用户可基于 Copilot 的回复持续进行多轮对话。

第二部分：RAG 模式

针对 Copilot 如何顺畅的回复用户的提问，Copilot 的回复内容从何而来，进行解密。

在这张图里面，我们可以看到 RAG 的几个老朋友：【改写】、【检索】、【排序】、【生成】。各个模块具体是如何协作、评估的，在我们的《 RAG 集合》系列内，此处不做过多赘述。

在这张图中，我们首次明确提到 RAG 的两路检索，分别是：向量的检索和 ES 的检索，

ES 检索：

这一路的检索主要是基于一些关键词，结构数据的检索，类似我们应用系统的筛选逻辑。

向量检索：

这一路检索需要对 Query 进行向量处理，和知识库中的 Doc 向量化的结果，进行两相匹配，找出与 Query相似度最高的 Doc 结果。向量检索其实还可以细分稠密向量和稀疏向量，依据实际的业务情况组合使用。

上述两路都会得到一批检索结果，对这批检索结果，我们依据一定的业务规则，可对结果进行排序，取出排序中 topN 的优质结果，参与后续的生成回复的任务。

回复生成后，就可以推送给Copilot的应用端，呈现给用户。

上述是一个单个轮次对话的 RAG，如果是多轮次，或者需要根据已有的用户信息，增加生成结果的精度，可优化如下：

历史对话和用户画像可参与【改写】和【生成】环节，使得最终的回复结果更贴近用户需求。

第三部分：知识库

在 RAG 整个流程中，知识库是目前最大黑盒，虽然我勉强用上述这张图做了简略的表达，但是实际在知识库的构建中，面临着诸多问题需要去解决，这块是整个项目占用人力资源最多的地方。

借助传统数据仓库过程 ETL 的逻辑进行理解：

E - Extract（提取）

数据源：依据不同的项目需要从多个数据源获取和项目目标相关的需求文档，且随着项目的进展，还需要不断的扩充数据源，满足模型调整的需求。

目标文档：数据源中获取的文档不管格式还是内容往往五花八门，存在脏乱差的数据，目标文档是基于文档维度第一遍初筛，选出和需求相关的目标文档后存储作为数据处理的起点。

T - Transform（转换）

文档转化：文档的格式有很多，一般建议都转化为 txt 格式后进行处理。当然，如果业务背景下，数据源获取的数据本来就是结构化数据，那么是没有必要做这一步的。

文档分片：一些长文本，需要进行文本分片，这块在《11 RAG 里要踩的坑》里面就提到，如果不合理的分片是会影响到最终的召回效果的。

内容画像：文档除了直接切片使用外，我们还要给各个文档建立内容画像，这个内容画像表示了这个文档的特征，我们的检索过程可以通过内容画像的关键信息定位到一批符合需求的文档。

用户画像/历史对话：在多轮次的对话需求里，如果我们希望做得更好的话，还需要针对用户建立用户画像，或者利用公司数据仓库内已经存在的用户画像。历史对话的信息也需要进行存储、取用、清洗的处理。

L - Load（加载）

向量数据库（分片向量+画像向量）：这部分是基于文本分片结果和内容画像的长文本，进行向量化后存储在向量数据库内，服务于我们 RAG 的向量检索路。

ES 数据库（关键词）：这部分是内容画像中的结构化数据，服务于 RAG 的 ES 检索路。

第四部分：模型替换和数据飞轮

如果项目进度已经把这个图整体的框架都搭建完成了，那么恭喜你，完成了 0-1，现在要进入的是 1-100+的过程了。

这个过程的主要内容就是：模型替换和数据飞轮。

如图所示，LLM 在整个 RAG 项目的各个节点都有参与，且作用深远。

一般来说，在项目初期为了验证可行性，一般 图示的LLM=GPT 系列进行流程的跑通。

如果在 GPT 的基础上验证整体的项目可行，那么就会进行成本估算和风险处理，做模型替换，比如在embedding 环节用百度的，比如训练一个自己的文本分片模型。

最后图示的 LLM内会包含多个微调开源模型+多个闭源模型的集成。

开源模型的微调需要更多的数据集，项目需要进一步优化，生成内容需要无限趋近于用户的真实需求，要求我们的知识库要更大更好，所以我们要建数据飞轮模式。

飞轮并不是一个新的东西，但是它要求整个知识库的建立过程都有相对标准可以依据的规则，比如什么是优质的画像结果，专家介入对画像结果标注规则是什么？

这些规则进入一个相对稳定的阶段，那么该知识库建立的所有参与人员都可以有依据的完成任务，数据的产出就相对稳定，对Copilot 侧提供的增量数据就进入稳定了有预期的产出。

当然数据飞轮并不是建立之后就一成不变的，还是会受到整体项目目标和 Copilot 侧消费数据的变化进行调整的，但是上下游的协作关系相对稳定，产出数据量相对稳定，那么就可以说数据飞轮运转起来了。

此致，感谢阅读。