RAG知识库搭建全解析：从原理到优化的完整流程

RAG到底解决什么问题

RAG的全称是Retrieval-Augmented Generation，即检索增强生成。它的核心作用，是为大模型补充其自身缺乏的外部知识。大模型本身的参数里并不包含企业内部数据，而RAG通过引入外部知识库，让模型在回答问题或生成内容时能够参考这些数据，从而提升准确度、降低幻觉的发生概率。

用更直白的话说，RAG就是给大模型"外挂"一个知识库。这些外部数据既可以是结构化的（如关系型数据库中的记录），也可以是非结构化的（如PDF、Word文档、文本）。RAG的价值在知识密集型任务中尤为突出——当用户提出的问题依赖大量专业或私有信息时，仅靠模型本身的记忆往往难以给出可靠回答。

值得强调的是，向量数据库支持多模态存储。图片同样可以转化成向量存入其中，只不过图片需要使用专门处理图像的embedding模型，并且图片向量与文本向量应存放在不同的collection（集合）中，以便后续检索。

向量数据库是RAG系统的存储核心，其工作原理与传统关系型数据库有本质区别。传统数据库按字段精确匹配查询，而向量数据库存储的是高维浮点数向量——每段文本经过embedding模型编码后，会变成一个几百到几千维的数值数组，语义相近的内容在这个高维空间中距离较近。查询时，用户的问题同样被转成向量，数据库通过ANN（近似最近邻）算法快速找出与之最相似的向量，返回对应的原始文本片段。这种"语义检索"而非"关键词匹配"的能力，正是RAG能够理解自然语言问题并返回相关知识的技术基础。Milvus、Chroma、Weaviate、Pinecone等都属于向量数据库，各自在性能、部署方式和生态上有所差异。

RAG的基本流程

一个最基础的RAG系统，可以拆解为两个大阶段：构建知识库与检索生成。

构建阶段的起点是数据采集。数据可能来自本地文件，也可能来自企业内部的关系型数据库。拿到数据后，如果是文本，就需要进行切片，把长文本切成一个个chunk；如果是图片，则整张图片直接转化为向量。切片或转换后，通过embedding模型将其转成向量，最终存入向量数据库。

检索阶段则从用户提问开始：系统根据用户的问题，去向量数据库中做检索（也可以叫搜索），拿到相关结果后进行必要的处理，再把处理后的内容传给大模型，由大模型生成最终答案。

流程听起来简单，但真正落地时细节繁多。原作者特别提醒，做惯了传统CRUD（增删改查）项目的开发者容易低估RAG——传统项目只要功能完成、测试无bug基本就能交付，而AI项目还必须考虑输出结果的准确率和召回率能否达到企业要求，达不到就要持续优化。

RAG优化的关键环节

所有RAG的原理都相通，真正拉开差距的是"优化"。所谓优化RAG，就是通过对各个环节提供更合适的解决方案，把大模型输出幻觉的概率尽可能压低。原作者梳理了几个核心优化点：

向量数据库选型

不同的数据规模适合不同的向量数据库。数据量少和数据量大的场景，选择往往不同。作者在项目中选用了Milvus，理由是据其在AI岗位的同行反馈，大型项目中Milvus的使用相当普遍。当然向量数据库并非只有这一种，Milvus只是较为主流的代表。

数据加载与切片

本地文件类型多样——PDF、Word、Markdown、TXT，各自的加载方式不同。切片则是最见功力的环节之一。一些工具（如Dify）默认按定长切割，比如设定chunk为200字，就每200字切一刀。但定长切割并不总是最优：还可以按标点符号切、按语义切、按段落切，PDF可以按页切，Markdown可以按标题切。

切片做不好会带来直接后果：一句完整的话若被拦腰切断，其语义特征就被破坏，进而增加大模型生成结果出现幻觉的风险。

Embedding模型选择

词嵌入可以选用商业模型（如OpenAI、智谱、通义千问等），也可以选用HuggingFace上的开源模型。需要区分的是，处理文本的embedding与处理图片的embedding是不同的模型，二者用途不可混用。

Embedding（词嵌入/向量化）模型的核心作用是将文本映射到语义空间，使得意思相近的句子对应的向量距离也更近。不同模型的向量维度、支持的最大输入长度（context length）以及对中文的处理能力差异显著。例如OpenAI的text-embedding-3-small输出1536维向量，而HuggingFace上的BGE系列模型对中文支持更友好，且可本地部署避免数据出境合规风险。选择embedding模型时需注意：构建知识库和检索时必须使用同一个模型，因为不同模型的向量空间不兼容，混用会导致检索完全失效。此外，embedding模型本身也有token限制，超长文本需要切片后再分别编码，这也是切片策略与embedding模型选择需要协同考量的原因。

检索器：多策略组合

最简单的RAG只用相似性检索，即按相似度排序返回结果。但成熟的检索方案远不止于此，还包括范围检索、分组检索、混合检索、全文检索等。实际项目中往往是多种检索器组合使用，以保证最终结果的准确性。

重排序（Re-rank）

检索出Top10或Top5结果后，这些结果虽然已按相似度排序，但相似度高不等于相关性强。因此需要引入额外的重排序模型，按相关性对检索结果重新排序，再放入提示词交给大模型。

重排序在流程中的位置很明确：检索 → 取Top结果 → 重排序 → 组装提示词 → 交给大模型。若跳过重排序，同样会影响最终答案的质量。

重排序模型（Reranker）与embedding模型的工作机制不同：embedding模型将查询和文档分别独立编码再比较距离，速度快但精度有限；而reranker模型通常采用交叉编码器（Cross-Encoder）架构，将查询和候选文档拼接后一起输入，直接输出相关性得分，精度更高但计算成本也更大。这就是为什么实际系统中往往采用"粗排+精排"两阶段策略：先用向量相似度从海量数据中快速召回Top100或Top50候选，再用reranker对这批候选做精细打分，取Top5或Top10交给大模型。常用的开源reranker包括BGE-Reranker、Cohere Rerank等，商业API也有对应服务。

结合Agent与工作流

更进阶的RAG还会结合Agent以及图工作流（graph workflow），让整个系统的处理逻辑更灵活可控。

Agent在RAG场景中承担的是"决策与调度"角色：它能根据用户问题的性质，动态判断是否需要检索、检索哪个知识库、是否需要调用外部工具（如搜索引擎、计算器、数据库查询），而不是简单地对每个问题都走固定的检索流程。图工作流（Graph Workflow）则允许将RAG中的各个步骤定义为节点，节点间的路由逻辑可以带有条件分支，例如"若向量检索结果置信度不足，则转入全文检索节点"。这种灵活性对于复杂业务场景尤为重要，比如用户问题涉及多个子问题时，Agent可以拆解问题并行检索再合并答案，而不是把整个复合问题直接扔给单次检索，后者往往导致召回质量下降。Dify、LangGraph、LlamaIndex Workflows等工具都提供了此类能力的实现框架。

为什么从向量数据库入手

作者强调，AI项目的"需求"通常极其简单——用户提问、系统回答，一句话就能说清。项目真正的核心不在需求，而在于如何用不同的解决方案把RAG流程打磨到位。

而在整条流程中，所有环节都围绕着一个中心：向量数据库。切片后的chunk要存进去，检索要从里面查，重排序也要基于检索结果。没有向量数据库，后续的切片、检索、重排序都无从谈起。因此教程从向量数据库（Milvus）开始，先解决存储这一根基问题，再逐步展开切片、embedding、检索、重排序等环节。

小结

RAG的原理不复杂，但从原理到生产级系统之间，隔着大量工程细节。向量数据库选型、数据切片策略、embedding模型选择、多检索器组合、重排序、Agent与工作流集成——每一个环节都存在优化空间，也都是决定最终幻觉率高低的关键。对于希望搭建私有知识库的开发者而言，理解这些环节各自的作用与相互关系，比死记流程更重要。