RAG 项目从 0-1 和 1-100+
从陆奇那篇刷屏的演讲《我的大模型世界观》算起，LLM带给人的震动已经超过一年了。去年4、5月间，不少企业一边焦虑一边摸索着入局。大致分三条路：第一类，数据资源雄厚的，自己下场做大模型，无论开源与否，现在多少都端出了一些LLM+的产品；第二类，选择在开源模型上做微调，尤其在化学、医疗这些垂直领域，已经有拿得出手的成绩；第三类，对大多数想快速落地的企业来说，走RAG路线似乎是性价比最高的选择。
今天要聊的是：如果一家企业决定用RAG来做智能应用，整个迭代路线大致长什么样？
就从这个图切入。
第一部分：Copilot——应用层
这个简单的对话页面，是多数LLM产品目前交付的模样。用户对着Copilot提问，Copilot给出回答，然后用户再追问——多轮对话就这么展开了。别看它简单，所有的大厦，都从这块砖开始。
第二部分：RAG模式
那Copilot是怎么做到自然回复的？回复的内容从哪来？这里就要拆开来看RAG的内部机制。
图里可以看出几个老朋友：【改写】、【检索】、【排序】、【生成】。具体每个模块怎么协作、怎么评估，之前的《RAG集合》系列已经讲了不少，这里不再展开。
值得注意的一个细节是：这张图里首次明确提出了RAG的两路检索——
向量检索
ES检索
ES检索
向量检索
两路检索各自生成一批结果，再按业务规则排序，只取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侧消费数据变化的影响而调整。但只要上下游协作关系相对稳定、产出数据量相对稳定，那就可以说——数据飞轮运转起来了。
感谢阅读。
