目录RAG 核心流程2.1 Ingest把数据导进来2.2 Chunk把长文档切成小块2.3 Embed把文字变成向量2.4 Index存进向量数据库2.5 Retrieve检索相关内容2.6 Answer大模型生成回答2.7 流程小结优缺点三、大模型五大致命局限性四、传统关键词检索的痛点五、RAG 核心概念六、RAG 六大核心流程分两大阶段离线准备阶段一次构建、增量更新在线运行阶段每次用户提问必走七、RAG 优缺点优点缺点八、RAG 四大经典落地场景九、Demo 到企业级 RAG 的核心难点RAG 核心流程RAG 全链路图ingest → chunk → embed → index → retrieve → answer。这六步分成两个阶段前四步是准备阶段离线做一次后两步是运行阶段每次用户提问都走一遍。下面一个个拆开讲。2.1 Ingest把数据导进来第一步很简单把你的数据源接入系统。数据可能是 PDF 产品手册、Word 内部文档、网页内容、数据库里的结构化数据格式五花八门。不同格式用不同的解析方式PDF 要提取文字Word 要读取内容网页要爬取并清洗。这步的目标就一个拿到干净的纯文本。2.2 Chunk把长文档切成小块文档一般都很长直接用有两个问题1.大模型的上下文窗口有限塞不下整篇文档2.检索时希望找到最相关的那一小段而不是整篇文章。所以要切块。比如一份 50 页的产品手册可以按章节切或者固定每 500 字切一块。切块有讲究太大检索不够精准还容易超出上下文限制太小语义不完整上下文丢失常见做法是 500-1000 字一块相邻块之间有一定重叠比如重叠 100 字防止重要信息正好被切断。2.3 Embed把文字变成向量这步是整个 RAG 的核心。前面说过传统关键词搜索不懂语义。怎么让机器理解这玩意儿怎么用和产品使用方法是一回事答案是把文字转成向量。向量就是一串数字比如[0.23, -0.45, 0.67, ...]可能有几百上千维。这串数字编码了这段文字的语义信息意思相近的文字向量在空间中的距离也近。打印机怎么用 → [0.23, -0.45, 0.67, ...] 产品使用方法 → [0.25, -0.42, 0.65, ...] ← 很接近 今天天气不错 → [-0.89, 0.12, 0.03, ...] ← 差很远这个转换由专门的 Embedding 模型完成比如 Qwen3 的 Qwen3-Embedding-8B或者开源的 bge、m3e。2.4 Index存进向量数据库向量算出来了得找个地方存起来。普通数据库存结构化数据做精确匹配。向量数据库专门存向量做相似度搜索——给一个向量找出距离最近的 N 个。常见的向量数据库有Milvus、Pinecone、Weaviate轻量级的有Faiss、Chroma。从我目前的调研来看Milvus 在向量数据库中更新迭代快、社区活跃度高同时也提供了较完善的可视化界面上手和管理都比较方便。因此后续课程我们将以 Milvus 作为示例工具进行讲解与演示。存的时候向量和原文要一起存。后面检索出来得把原文拿给大模型看。同时还要有元数据简单理解是个 JSON的概念方便检索时进行筛选精准数据。2.5 Retrieve检索相关内容用户提问了比如打印机墨盒怎么换。这时候做两件事1.把用户问题也转成向量2.拿这个向量去向量数据库搜找出最相似的几个文档块。因为语义相近的文字向量也相近所以用户说墨盒怎么换文档里写的是墨盒更换步骤照样能匹配上。这就是前面说的理解语义——不是比字面是比意思。2.6 Answer大模型生成回答最后一步把检索到的内容和用户问题打包发给大模型。你是一个产品客服请根据以下参考资料回答用户问题。 参考资料 【文档1】墨盒更换步骤1. 打开前盖... 【文档2】墨盒型号说明本产品适用 XX-100 墨盒... 用户问题打印机墨盒怎么换 请基于参考资料回答如果资料中没有相关内容请说明。大模型看到这些资料就能给出准确的回答而不是自己编。2.7 流程小结准备阶段跑一次就行有新文档时增量更新运行阶段每次用户提问都走一遍。阶段步骤做什么准备阶段离线Ingest导入原始文档Chunk切成小块Embed转成向量Index存进向量数据库运行阶段在线Retrieve检索相关文档Answer大模型生成回答上面六步先有个整体印象就行。实际落地的时候每一步都有不少讲究。比如文档怎么切块效果最好向量模型选哪个检索结果要不要做重排序这些选择没有标准答案得看你的数据特点和业务场景。后面的章节会把每个环节拆开聊聊常见的做法和踩坑点。优缺点先说好处RAG 能火起来不是没道理的。成本低上手快想让大模型懂你的业务知识有两条路一是拿你的数据去微调模型二是用 RAG 把知识喂给它。微调要准备训练数据、要算力、要时间搞一次少说几天。RAG 就简单多了把文档灌进向量库当天就能跑起来。想让大模型懂你的业务知识有两条路一是拿你的数据去微调模型相当于让模型“重新学习”一遍把知识记进模型参数里二是用 RAG 把知识喂给它。知识更新方便微调完的模型知识就固化了。要更新再微调一轮。RAG 不一样文档有变动重新处理一下就行甚至可以做到实时检索最新数据。对于知识频繁变化的场景这点很关键。答案可追溯大模型回答的时候你能看到它参考了哪些文档。用户觉得答案有问题可以去查原文验证。这在对准确性要求高的场景比如金融、医疗、法务很重要——出了问题能查到底。再说问题RAG 也不是万能的。效果看知识库质量垃圾进垃圾出。知识库里的文档质量差、组织乱检索出来的内容也不会好到哪去。RAG 系统的上限很大程度上取决于你喂给它的数据。系统复杂度上来了原本直接调大模型就完事现在多了文档处理、向量存储、检索排序这些环节链路变长了。任何一个环节出问题最终效果都会打折扣。调试起来也比单纯调模型麻烦。检索耗时不能忽视多了检索这一步响应时间必然变长。有研究说检索环节能占整个 RAG 流程耗时的 60% 以上。如果业务对延迟敏感这块得重点优化。总的来说RAG 适合知识密集、更新频繁、需要可追溯的场景。但它不是银弹效果好不好得看知识库建得怎么样、系统设计得合不合理。三、大模型五大致命局限性幻觉问题不懂事实逻辑容易一本正经编造虚假内容。知识时效性差知识库冻结无法知晓后续新政策、新产品、新动态。垂直专业深度不足通用知识丰富企业私有业务、小众专业领域知识缺失。无法访问私有数据拿不到公司制度、内部文档、客户数据、业务资料。回答不可追溯无法给出答案参考出处医疗 / 法律 / 金融等场景不适用。四、传统关键词检索的痛点仅匹配字面关键词无法理解语义同义表述用户口语化提问、委婉表述完全匹配不到解决不了自然语言问答需求。五、RAG 核心概念全称Retrieval-Augmented Generation 检索增强生成2020 年 Meta 提出。核心思想大模型开卷考试融合两大能力大模型语义理解 私有知识库语义检索。核心流程逻辑私有文档入库→用户提问→语义检索相关资料→把问题 资料喂给大模型→基于资料合规作答。六、RAG 六大核心流程分两大阶段离线准备阶段一次构建、增量更新Ingest 数据接入解析 PDF/Word/ 网页 / 数据库等清洗为纯文本。Chunk 文档切块长文档拆分小块兼顾上下文完整性与检索精度常规 500-1000 字相邻块做重叠防信息截断。Embed 向量化通过 Embedding 模型把文字转为多维数字向量语义相近则向量空间距离近解决语义匹配问题。Index 向量入库向量 原文 元数据存入向量数据库课程主推 Milvus。在线运行阶段每次用户提问必走Retrieve 语义检索用户问题向量化在向量库相似度匹配召回相关文档块。Answer 生成回答拼接用户问题 检索资料交给大模型限定依据资料作答杜绝编造。七、RAG 优缺点优点落地成本低、上手快相比微调无需算力和训练数据。知识更新灵活修改文档即可增量更新无需重新训练模型。答案可溯源能展示参考文档满足严谨行业合规要求。缺点垃圾进垃圾出效果上限完全依赖知识库文档质量。系统链路长、复杂度高任一环节出问题都会影响最终效果。额外增加检索环节响应延迟升高对高并发低延时业务需专项优化。八、RAG 四大经典落地场景企业内部知识库查制度 / 流程 / 技术文档对接 OA/HR/BI/ 订单系统升级为企业智能助手。智能客服依托产品手册、FAQ、历史工单替代传统关键词机器人覆盖非标提问。专业领域助手法律法条判例、金融研报财报、医疗文献用药兼顾准确 可溯源。开发技术助手接入代码仓库、API 文档、技术手册辅助开发答疑。九、Demo 到企业级 RAG 的核心难点数据层多格式文档解析、表格 / 扫描件处理、切块策略难统一。问答层问题重写口语转标准问、多轮上下文补全、多意图拆分。调度层意图识别区分闲聊 / 知识库检索 / 工具调用、多知识库路由、敏感问题拦截。检索层纯向量检索有局限需向量 关键词混合检索、结果重排序、权限过滤、精准编号匹配。会话层多轮对话记忆管理、历史摘要压缩、长期记忆持久化与更新。配套层问题引导澄清、请求风控、答案溯源、模型负载均衡、效果监控迭代。