从陆奇那篇广为流传的演讲《我的大模型世界观》算起，大型语言模型（LLM）带来的技术冲击已超过一年。去年4、5月间，许多企业一边焦虑一边摸索着入局，大致分三条路径：第一类，数据资源雄厚的企业自行研发大模型，无论开源与否，现在都已推出了一些LLM+产品；第二类，选择在开源模型上做微调，尤其在化学、医疗等垂直领域，已取得可验证的成果；第三类，对多数希望快速落地的企业而言，采用RAG（检索增强生成）路线似乎是性价比最高的选择。

本文要探讨的是：如果一家企业决定基于RAG构建智能应用，整个迭代路线大致是什么样的？

就从这张图切入。

第一部分：Copilot——应用层

这个简洁的对话界面，是目前大多数LLM产品呈现的形态。用户向Copilot提问，Copilot给出回答，随后用户继续追问——多轮对话就这样展开了。别看它简单，所有的大厦都从这块基石开始。

第二部分：RAG模式

那么Copilot是如何做到自然回复的？回复内容从何而来？这里就需要拆解RAG的内部机制。

图中可以看出几个核心环节：【改写】、【检索】、【排序】、【生成】。关于每个模块如何协作、如何评估，之前的《RAG集合》系列已有详细阐述，此处不再展开。

值得关注的一个细节是：这张图首次明确提出了RAG的双路检索——向量检索与ES检索。

ES检索：基于关键词和结构化数据的检索，类似于我们日常使用的应用筛选逻辑。

向量检索：需要将Query转化为向量，与知识库中预先处理好的文档向量进行匹配，找出相似度最高的若干结果。向量检索内部又可细分为稠密向量与稀疏向量，实际业务中常组合使用。

双路检索各自生成一批结果，然后按照业务规则进行排序，只取排名靠前的（topN）高质量结果用于生成回复。

回复生成后，推送到Copilot前端呈现给用户。

上面描述的是单轮对话的RAG。若要实现多轮对话，或利用已有用户信息提升生成精度，可进行如下优化：让历史对话记录和用户画像参与【改写】与【生成】两个环节，这样最终的回复会更贴合用户需求。

第三部分：知识库

在整个RAG流程中，知识库是目前最不透明的黑盒。尽管这张图已尽量简化，但实际构建过程中遇到的问题，才是整个项目中最消耗人力的部分。

我们可以借助传统数据仓库的ETL逻辑来理解：

E——Extract（提取）

数据源：不同项目需从不同数据源中抓取与项目目标相关的文档，而且随着项目推进，还需不断扩充数据源，以适应模型调整。目标文档：第一遍粗筛，从五花八门的文档中挑出真正相关的内容，存下来作为处理起点。

T——Transform（转换）

文档格式五花八门，一般建议统一转为txt格式再处理（如果本身就是结构化数据，此步可省略）。文档分片：长文本需要切分，不合理的分片会直接影响召回效果，这一点在前面的《11个RAG里要踩的坑》中已提醒过。

内容画像：文档不仅需要切片，还需为每份文档建立“画像”——即文档的特征标签，检索时通过画像的关键信息定位到一批相关文档。

用户画像与历史对话：若涉及多轮对话，最好建立用户画像（或利用已有数据仓库中的画像），历史对话信息也要做好存储、提取和清洗。

L——Load（加载）

向量数据库：文本分片结果和内容画像的向量化结果会存入其中，服务于RAG的向量检索路径。ES数据库：内容画像中的结构化信息存入其中，服务于ES检索路径。

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

如果框架已经搭建完成，那恭喜你，已经走完了从0到1的阶段。接下来进入的是从1到100+的阶段——核心就是模型替换与数据飞轮。

如图所示，LLM在整个RAG流程中几乎每个节点都有参与，作用深远。项目初期为验证可行性，通常会先用GPT系列跑通流程。验证可行后，就开始进行成本估算和风险处理，逐步替换模型：例如将embedding环节换成百度的，或自行训练一个文本分片模型。最终，框架中的LLM会变成多个微调开源模型与多个闭源模型的集成。

开源模型的微调需要更多数据集，项目要继续优化，生成内容需无限逼近用户真实需求，这就要求知识库更大、更好。因此，数据飞轮必须建立起来。

数据飞轮这个词听起来新鲜，本质并不复杂。它要求整个知识库的建设过程都有相对标准、可依据的规则。例如：什么才是优质的画像结果？专家介入后的标注规则是什么？一旦这些规则稳定下来，所有参与人员就能有据可依，数据产出也趋于稳定，对Copilot侧提供的增量数据就能实现稳定、可预期的输出。

当然，数据飞轮并非建好就一劳永逸。它仍会受到整体项目目标和Copilot侧消费数据变化的影响而调整。但只要上下游协作关系相对稳定、产出数据量相对稳定，那就可以说——数据飞轮已开始运转。

感谢阅读。