有段时间没更新 Agent 系列了这篇是第四篇聊聊知识获取管道也就是现在被提到最多的 RAG。前面几篇我们解决了 Agent 的大脑和手脚问题但真正让 Agent 在具体业务里落地、能回答出靠谱内容的关键反而是这一层最朴素的能力检索增强生成RAG。Retrieval-Augmented Generation四个字母拆开检索、增强、生成。没有它Agent 再聪明也只会闭着眼睛背书有了它Agent 才算是真正读过书、查过资料。这篇内容我会把 RAG 的完整链路从索引到检索再到生成拆开讲透把底层原理讲清楚然后给出大量我在实际项目里验证过的推荐配置、避坑经验和选型方案最后再延伸到最近很火的 Agentic RAG。无论你是刚入门准备做本地知识库还是已经在企业里做 Java/Spring AI 或者 LangChain4j 的开发这篇都值得收藏着慢慢看。1. 为什么 Agent 必须有 RAG 这条知识管道1.1 大模型的边界参数容量与知识固化的死穴先从最底层说起。任何 LLM不管参数是 7B 还是 700B本质都是把训练语料里的统计规律压缩进权重里。训练结束的那一天它的知识就被固化了。如果你问它2025 年第三季度我们公司的销售额是多少它只能给你一本正经地胡说八道因为它根本没见过这些数据。这就叫知识截止更可怕的是模型为了自洽会编一个看起来完全合理的数字出来这就是幻觉。我最早在企业里做 Agent 落地时最深的体会就是用户评判一个 AI 靠不靠谱不是看它能不能写诗而是看它能不能准确说出咱们部门上个月的报销量是多少。这个问题如果纯靠大模型本身永远答不对。微调有没有用有用但微调是把你的一部分领域知识灌进模型权重里成本高、周期长、更新一次要重新训一次而且对于每天都在变的企业数据来说微调完全跟不上节奏。这就引出了 RAG 最核心的价值把知识从模型参数中解放出来放到外部知识库里需要的时候检索出来再交给模型回答。模型只需要做一个聪明的读者而知识库负责提供正确的资料。1.2 知识割裂企业私有数据与模型之间的断层企业内部常年积累的各种文档——合同、SOP、产品手册、工单记录、ERP 里的商品描述——这些数据散落在不同的系统里天然存在严重的知识割裂问题。当你把 Agent 接入这些系统时如果缺乏有效的知识获取管道Agent 面对这些信息是两眼一抹黑的。你看最近热词里高频出现的知识割裂 RAG、解决了知识割裂 RAG说的就是这个场景。我自己做过一个 ERP 商品检索的 Agent 项目当时最头疼的就是如何处理同一商品在不同业务系统里的属性差异采购系统里叫华为笔记本电脑 MateBook X Pro售后系统里叫MateBook X Pro 2024 款酷睿 Ultra7。传统的关键词搜索完全没法把这两条记录关联起来。RAG 配合向量语义检索就能干这活它会先把所有记录向量化然后在语义空间里找相似度最高的内容把分散的记录拼成一个完整的商品视图。这才是 RAG 在产品检索类场景里的真正价值而不是简单地问一个答一个。1.3 Agent 的感知-决策-行动闭环里RAG 是感知层的地基如果把 AI Agent 比作一个人那么大模型是大脑工具调用Function Calling / Tool Use是手脚而 RAG 就是眼睛和耳朵。Agent 要做决策先得有信息输入这一点在 Agentic 架构里体会更深——Agent 在规划任务时往往需要先去检索知识库才知道下一步具体该调用哪个工具、按什么顺序执行。举个实战中的例子我做一个售后客服 Agent 时用户的提问是我的笔记本连不上公司 WiFi怎么办。Agent 的第一步不是直接给答案而是先把这个问题的故障现象向量化去知识库检索到相关的排查文档拿到文档里写的几个排查步骤后再结合用户的具体设备信息调用工具生成一份个性化排查清单。如果没有 RAG模型只能套用通用知识永远给不出贴合你公司网络环境和 IT 政策的回答。RAG 之于 Agent是感知层的地基感知层做不好后面所有的决策和行动都是空中楼阁。2. RAG 完整工作链路拆解从文档入库到生成回答2.1 离线索引让文档变成向量空间里的坐标点RAG 的第一个大阶段叫索引构建也就是把原始文档处理成计算机能检索的结构化数据。这个过程可以拆成四个步骤文档加载与清洗把 PDF、Word、Markdown、HTML 等格式的文档解析成纯文本。这一步最容易踩坑PDF 里的表格解析出来可能是一片乱码扫描件需要 OCR网页里可能有大量导航和广告噪声。我的经验是图片型 PDF 直接扔给 OCR 服务表格类文档尽量转成 CSV 或结构化 Markdown 再入库否则就是给后面的检索环节埋雷。文本切分Chunking把长文档切成合适大小的片段。切分策略直接决定检索效果常见的方式有固定大小切分、递归字符切分、基于文档结构切分和语义切分。对中文文档我一般优先用递归字符切分把分隔符优先级设为\n\n、\n、。、、块大小设置在 500-800 个 token 左右。文本向量化Embedding用嵌入模型把每个文本片段转换成一个高维向量。这个向量要能表达文本的语义相似的文本在向量空间里距离更近。中文环境我推荐从 BGE、bge-m3 这类模型入手。向量入库与索引创建把向量和原文、元数据一起存入向量数据库并建立索引结构如 HNSW、IVF方便后续快速相似度检索。这里要注意同一个文档片段需要保留原文引用信息方便最后回答时标注来源。实际项目中我会把所有入库的片段都打上 metadata比如来源文档名、章节号、页码、上传时间等。这些元数据在做按条件过滤时非常关键——比如只搜索某一年份的合同或者只搜索某个产品线的资料可以先用元数据缩小检索范围再做向量检索效率和准确性都更高。2.2 在线检索与生成相似度计算、上下文组装与引用输出用户提问时RAG 系统的在线部分会发生这么几个步骤用户问题向量化得到 query embedding。在向量库中执行相似度检索用余弦相似度或内积计算返回 Top-K 个最相关的片段。可选地做重排序Rerank把 Top-K 片段用更精细的模型重新精排一遍。把问题和检索到的片段组装进 Prompt让大模型基于这些上下文生成回答。这个链路看起来不复杂但每个环节都有很大的优化空间。在公司内部搭建一个最小可用的 RAG 系统选好 Embedding 模型和向量库之后基本上一天时间就能串起来但真正要在生产环境里稳定运行、回答准准确率超过 90%需要把每个环节的细节都抠到位。关于 Prompt 组装一个好的 RAG Prompt 至少要包含三件事检索到的参考资料、用户的问题、输出约束。输出约束里必须强调当参考资料无法回答问题时直接说明不知道不要编造以及引用来源标注到具体文档。我在早期项目里吃过亏——模型从检索片段里找到了一句话但引用错了文档来源用户拿着来源去核对发现对不上信任感瞬间崩塌。所以引用必须精确到文档和段落这一点在业务场景里比回答内容本身还重要。2.3 类比理解图书馆、检索员与教授的协同工作把 RAG 讲给完全没有技术背景的朋友听时我最常用的类比是图书馆模型向量数据库就是图书馆里面存着成千上万本书的摘要卡片每张卡片都在一个精确的位置上向量坐标。Embedding 模型就是图书分类法它把语义相近的书放在相邻的书架上。检索环节就是检索员拿着读者写的需求描述在图书馆里找到最匹配的几本摘要卡。大模型就是一位学术水平很高但从不看书的教授他不可能记住图书馆里所有内容但你把相关资料抽出来摆在他面前他能快速读完并整理出一份条理清晰的答复。这个类比能解释 RAG 的很多特性为什么 RAG 可以解决幻觉因为教授模型阅读的是真实的资料而不是凭空回忆。为什么 RAG 可以及时更新因为图书馆可以随时上架新书更新知识库不需要重新培训教授。为什么 RAG 会答非所问因为检索员找错了书召回了无关片段或没找全召回不足。3. 关键技术选型Embedding、向量库与切分策略怎么选3.1 Embedding 模型选择中文场景避坑与实战推荐Embedding 模型的选择在 RAG 项目里属于一票否决级别的问题选错了后面怎么优化都白搭。你在热词里会看到 bge 系列这是目前中文场景最值得优先考虑的。我自己的选型原则是这样的场景推荐模型说明中文通用文档BAAI/bge-large-zh-v1.5中文效果稳定社区案例多中英混合/多语言BAAI/bge-m3支持 100 多种语言还支持稀疏向量做混合检索纯英文/代码场景text-embedding-3-large或BAAI/bge-large-en-v1.5OpenAI 的性能够强但需调 API本地离线优先BAAI/bge-small-zh-v1.5体积小、速度快适合资源受限的机器如果你用bge-m3我强烈建议你在入库时同时生成稠密向量和稀疏向量检索时做混合加权。实践证明稠密向量擅长抓语义近义改写比如怎么退换货和退货流程是什么稀疏向量擅长抓专有名词和精确术语比如SN 码、SKU。两者结合在中文业务场景里的效果提升非常明显尤其是那些包含大量产品型号、合同编号的场景。3.2 向量数据库选型从本地原型到企业级部署的完整阶梯向量数据库没法说哪家最好只能看哪家最合适你的场景。我把主流选项按从轻到重排了一个阶梯Chroma / FAISS适合本地学习、快速原型验证。Chroma 可以直接嵌在 Python 进程里用不需要额外部署服务但生产环境的性能和扩展性一般。pgvector如果你公司已经在用 PostgreSQL这是成本最低的升级路径。直接在 PostgreSQL 里启用vector扩展支持 SQL 语法做向量检索跟现有业务数据天然打通。中小项目强烈推荐少维护一个中间件。QdrantRust 写的性能好部署简单支持 payload 过滤很灵活适合中小型独立部署项目。Milvus专门为大规模向量检索设计功能全面支持分布式和多种索引类型适合企业级知识库和每天百万级检索请求的场景。我个人的倾向是项目初期先用 pgvector 或 Qdrant 快速跑通业务等检索规模和并发上来了再平滑迁移到 Milvus。不要一上来就上重型方案RAG 的核心难点往往不在存储而在检索质量上你要把精力优先放在切分和检索调优。3.3 Chunk 切分策略的核心参数与调优思路关于切分我尝试过各种花哨的做法最后发现切分策略要从文本结构出发而不是死磕一个固定的最佳块大小。下面这张表总结了我在实战中的参数参考切分策略适用场景常用参数固定窗口切分代码、日志、格式统一的文本chunk_size512 字符overlap64递归字符切分普通文档按换行符、句号分级切分chunk_size500-800overlap80-100Markdown 标题切分Markdown 文档按标题层级分块按 # ## ### 层级递归切割语义切分长文档按语义完整度切块依赖 Embedding成本较高关于overlap重叠参数我特别想强调一下一定不要省略。如果两个相邻 chunk 之间没有重叠那么原本横跨切片边界的那句话就会被拦腰切断上一块丢了后半句下一块又缺了前半句无论检索到哪块都得不到完整信息。overlap 一般设置为 chunk_size 的 10%-20%宁可让相邻两块多一点冗余也尽量不要漏信息。再说说父子分块这个进阶思路有些文档切得太碎会把上下文拆散切得太大又拖慢检索精度。一个折中的方案是小分块检索大分块生成。具体做法是把文档切成较小的块比如 300 token用于向量检索找到最相关的小块后根据元数据回溯到它所属的更大块比如整节 2000 token把大块作为上下文交给模型。这样既保证了检索命中率又保留了足够的上下文语义。4. 从传统 RAG 到 Agentic RAG知识管道的智能进化4.1 传统 RAG 的三大天花板传统 RAG 基本是检索一次、生成一次的流水线模式问题在于场景稍一复杂就破功查询意图理解弱用户问我最近报修过好几次设备想看看有没有共性规律传统 RAG 会把设备报修和共性规律都拿去向量检索但知识库里可能根本没有这类汇总统计型答案。依赖单次检索质量如果用户的问题需要多步推理比如先查产品序列号对应的保修期再查到期的服务条款一次检索根本覆盖不了两步的信息需求。知识碎片化当答案分散在多篇文档里比如某工单的处理依赖另一份制度文件的授权条款时单轮检索找不到完整上下文。这就是 Agentic RAG 出现的直接原因。热词里agentic rag自成一条说明这已经不是一个概念了而是一个具体的落地方向并且 LangChain、Spring AI、LangChain4j 都在往这个方向演进。4.2 Agent 驱动的 RAG规划、多跳检索与自我反思Agentic RAG 的本质是把 RAG 的调用封装成 Agent 的检索工具让大模型自己决定何时检索、检索几次、用什么关键词检索、是否要改写查询。从技术实现角度看核心是三个能力查询改写与意图消解。用户刚说出来的raw query往往不适合直接做向量检索。比较典型的是代词指代它跟华为那款有什么区别——Agent 需要先在对话历史里定位它指的是什么重写成完整的问题再去检索。还有一种情况是口语化表达需要转成知识库里的术语说法比如本子卡得不行要改写成笔记本电脑卡顿性能问题排查。多跳检索Multi-hop Retrieval。把一个大问题拆解成多个子问题逐步检索每步检索的结果作为下一步检索的上下文。我做一个企业制度问答 Agent 时用户会问在项目验收环节如果供应商延期交付按合同条款应该扣多少违约金这个问题要查至少两个知识源项目验收制度和某份具体合同的违约条款。Agent 会先检索制度文档确认验收流程再定位到对应供应商合同最后才组织回答。自我反思与结果验证。Agent 检索完信息后先自我判断一下这些上下文有足够信息回答问题吗上下文之间有没有冲突不满足就重新检索一遍满足才组装最终 Prompt。这就是 well-known 的 Self-RAG 和 Corrective RAG 等方案背后的基本思路。4.3 工程化落地LangChain4j、Spring AI 与 Agent 框架的融合这一节说点贴近开发者的内容。如果你在用 Java 技术栈做企业级 Agent 应用热词里的 LangChain4j 和 Spring AI 是绕不开的。Spring AI 从 1.0 开始内置了 RAG 相关的抽象比如VectorStore、DocumentReader、QueryTransformer等和 Spring Boot 的生态无缝集成。你可以在 Spring 配置里声明一个PgVectorStore的 Bean然后通过RetrievalAugmentationAdvisor给 ChatClient 加上检索能力就像这样Bean VectorStore vectorStore(EmbeddingModel embeddingModel) { return new PgVectorStore(embeddingModel, PgVectorStore.PgVectorIndexConfig.builder() .indexType(PgVectorStore.PgVectorIndexType.HNSW) .build()); } Bean RetrievalAugmentationAdvisor advisor(VectorStore vectorStore) { return RetrievalAugmentationAdvisor.builder() .queryTransformers(new RewriteQueryTransformer()) .retriever(QueryRetriever.builder() .vectorStore(vectorStore) .topK(5) .build()) .build(); }LangChain4j 则提供了更贴近 LangChain Python 的编程模型ContentRetriever接口可以做更细粒度的自定义控制也支持把 RAG 组件注册成 Agent 的工具。我在 Java 项目里更喜欢 LangChain4j 的一点是它的EmbeddingStoreIngestor做文档入库时可以指定分段器、增强器和元数据定制器把整条索引管道用几行代码串起来EmbeddingStoreIngestor ingestor EmbeddingStoreIngestor.builder() .documentSplitter(DocumentSplitters.recursive(600, 80)) .embeddingModel(embeddingModel) .embeddingStore(embeddingStore) .build();对于更复杂的 Agentic RAG我建议你参考热词里提到的 LangChainPython生态。它的create_agentRetrieverTool组合几乎是 Agentic RAG 的标准姿势把检索器包装成ToolAgent 在收到用户问题后自主判断是否调用检索工具、调用几次。Python 做原型可以写得非常快但生产环境稳定性、可观测性Java 系明显更有优势。我的建议是公司里如果已经有成熟的 Java 技术栈Agentic RAG 的生产落地优先考虑 Spring AI LangChain4j做研究和算法迭代用 Python 的 LangChain 或 LlamaIndex 更顺手。4.4 GraphRAG 与 Ontology RAG当知识需要关联而非相似当你处理的知识不只是文档碎片的堆叠而是一张张充满关系的图谱时向量相似度检索会显得力不从心。典型场景公司规章制度里有部门职责与审批权限两个章节它们的语义不相似但在实际业务里是强关联的。传统 RAG 查申请采购需要谁审批可能只检索到采购制度GraphRAG 会沿着知识图谱里的关联关系找到对应的审批权限章节还能可视化展示谁在什么条件下有权审批多少金额。热词里的 GraphRAG、Ontology RAG、LLM Wiki 都指向同一个趋势用图谱结构辅助 RAG 检索可以从全局理解文档间的关联关系而不仅限于片段里的词语匹配。微软开源的 GraphRAG 项目思路是先用 LLM 从文档里抽取出实体和关系图再基于图结构做社区检测式的问题回答Ontology RAG 则更进一步把领域知识建模成结构化本体比如设备-故障-维修方案三元组检索的关键词是按图找点而不是按词找片。如果你的业务有强关系型知识比如故障诊断、合规审查、家族关系图谱我建议你预留一条路在现有 RAG 之上给知识库加一层图谱索引。这不一定要一上来就全量上 GraphRAG可以从本体定义开始先给文档的实体打上标签再逐步建立实体间的关系索引。这样 Agent 在复杂推理场景下能获得传统 RAG 给不了的全局视野。5. RAG 实操经验与避坑实录5.1 检索质量差的真凶往往不在检索而在索引我修过大量检索效果不好的问题最终发现至少一半问题出在索引阶段文档格式解析不干净。扫描版 PDF 没有做 OCR直接入库后文本是乱码PPT 转出来的内容混入了大量文本框坐标信息网页转出来的文本夹杂一大堆导航菜单。这些问题不会在入库时报错却会在检索时给你致命的打击——检索到的片段看着像关键字匹配到了但上下文完全不可读。处理方式是在入库前做清洗层把无效信息剥掉必要时按干净文本给模型原始格式留备份的原则双轨存储。切分粒度不合理。这是另一个重灾区。切得太碎检索到的是孤零零的一句话模型没有上下文可参考切得太大一个 chunk 里混了多件事向量表示被稀释成平均语义检索精度反而下降。我建议拆成两级去调先定 chunk_size 候选集300、500、800用一个评估集跑一遍 Top-K 命中率选指标最好的那组再根据 bad case 手动调整 overlap。向量检索和关键词检索的关系没处理好。很多人以为向量检索万能但我实测发现包含大量精确编码、型号、编号的内容比如GB/T 19001-2016向量检索效果不如最简单的 BM25 关键词检索。你可以在系统里把两者结合成混合检索再做分数归一化融合。这也是为什么我在 3.1 提到 bge-m3 的稀疏向量能力值得重视的原因。5.2 检索参数的黄金规则Top-K、score 阈值与 Rerank关于检索参数我有一套自己验证过的黄金规则Top-K 不要死磕固定的 3 或 5。一般问答 5 够用但涉及多细节准确度的场景比如精确到金额、日期我建议检索 8-10 个候选然后交给一个重排序模型精排取前 3-4。检索多召回一点交给 Rerank 去精排召回率远高于只检索 Top-K 就跑生成。score 阈值必须设但不能设太高。很多向量库返回的相似度分数在语义空间里表现并不稳定同一个模型在不同语料上的分数分布差异很大。我的做法是基于验证集统计分数分布选取能保留绝大多数正样本的分数作为底线再结合 Top-K 做双重约束。宁可多给模型一些低分但不相关的片段也不要因为阈值太高把正确的片段过滤掉。Rerank 是质量提升的秘密武器。推荐用 cross-encoder 模型比如bge-reranker-base它会把 query 和每个候选文本拼接后整体编码比起双塔的向量相似度计算交互式建模的精度要高一个档次。代价是速度慢所以架构上先粗召回向量 Top-K 取 20-30再精排Rerank 取 5性能和效果能兼得。5.3 常见问题速查表从幻觉到引用错乱的排查清单现象根本原因处理建议回答明显编造检索片段不够、Prompt 未声明不知为不知增加 Top-K强化 Prompt 输出约束加无法回答请明确说明指令回答正确但引用来源混乱检索片段没绑定精确元数据生成时把多个片段混合引用入库时给每块打上 doc_id chunk_index生成时要求按来源编号标注相似问题反复答不准Embedding 模型没有针对业务术语优化考虑微调 Embedding 或在词表层面做同义词扩展检索结果与问题无关查询改写不足、切分粒度不匹配加 QueryTransformer 改写调整 chunk_size做混合检索系统响应太慢检索条数太多、Rerank 模型太重粗召回 Top-K 降到 20 以内Rerank 模型用轻量版或把 Rerank 做成异步知识库更新后效果没变化更新时未重建向量索引或缓存了旧片段入库时校验覆盖写入建缓存失效机制再分享一个排查技巧当问题“答不对”时先别急着调模型或 Prompt把检索返回的 Top-K 片段直接打印出来看一眼。如果片段里根本没有正确答案那是检索/索引的问题如果片段里有答案但模型还是答错了才是生成/Prompt 的问题。这一步能帮你节省至少一半的排查时间。5.4 评估你的 RAG不能只靠感觉差不多最后说评估。说实话RAG 的评估是项目中后期最容易敷衍、也是最容易翻车的地方。我见过太多团队上线前随便找几个问题人工测一测就说效果还行上线后被业务方用真实问题一轮就击穿了。评估至少要分两层离线评估用一组带标准答案的 QA 对计算两个核心指标。召回质量评估检索环节比如 RecallK看正确片段有没有进 Top-K回答质量评估端到端可以用 RAGAS 框架里面的忠实度Faithfulness和答案相关性Answer Relevance指标。忠实度回答的是模型说的话有没有依据检索片段相关性回答的是答案满不满足用户提问。我自己用 RAGAS 跑过几个项目它甚至不需要标注样本用 LLM 打分就行适合没有人工评估资源的团队。在线评估上线后用日志分析用户反馈、回答采纳率、人工抽检比例。有条件的话做 A/B对比不同切分参数或不同检索方案在同一批真实流量上的表现。热词里有一条rag实战、rag项目实战说明现在做 RAG 的人和项目都不少了但真正能写出严格评估报告的项目凤毛麟角。能给出量化指标的 RAG 项目在任何技术评审里都是加分项。6. 这个方向还能怎么继续深挖写到这RAG 的基础链路、选型和踩坑重点基本都覆盖了。如果你顺着这篇的思路往深了走我个人建议按这个顺序往下探索先从评估开始没评估体系就别谈优化再做混合检索与重排序的调优这套组合拳能把大多数项目的检索质量提升一大截接着深入Agentic RAG把查询改写、多跳检索、自我反思这些能力一步步加进去你会发现 Agent 的智能水平有明显变化最后再去看GraphRAG / Ontology RAG当你处理的业务场景有强关系和复杂逻辑时那会是一层全新的知识表达维度。我现在做一个新项目时第一步就是在纸上画出知识从哪里来、要经过哪些处理、最终服务什么问答/推理场景把这条知识获取管道想清楚了才开始写代码。这篇系列能够帮到你一点点就是我分享这些踩坑经验最大的意义。
RAG知识获取管道全解析：从原理到Agentic RAG实战
有段时间没更新 Agent 系列了这篇是第四篇聊聊知识获取管道也就是现在被提到最多的 RAG。前面几篇我们解决了 Agent 的大脑和手脚问题但真正让 Agent 在具体业务里落地、能回答出靠谱内容的关键反而是这一层最朴素的能力检索增强生成RAG。Retrieval-Augmented Generation四个字母拆开检索、增强、生成。没有它Agent 再聪明也只会闭着眼睛背书有了它Agent 才算是真正读过书、查过资料。这篇内容我会把 RAG 的完整链路从索引到检索再到生成拆开讲透把底层原理讲清楚然后给出大量我在实际项目里验证过的推荐配置、避坑经验和选型方案最后再延伸到最近很火的 Agentic RAG。无论你是刚入门准备做本地知识库还是已经在企业里做 Java/Spring AI 或者 LangChain4j 的开发这篇都值得收藏着慢慢看。1. 为什么 Agent 必须有 RAG 这条知识管道1.1 大模型的边界参数容量与知识固化的死穴先从最底层说起。任何 LLM不管参数是 7B 还是 700B本质都是把训练语料里的统计规律压缩进权重里。训练结束的那一天它的知识就被固化了。如果你问它2025 年第三季度我们公司的销售额是多少它只能给你一本正经地胡说八道因为它根本没见过这些数据。这就叫知识截止更可怕的是模型为了自洽会编一个看起来完全合理的数字出来这就是幻觉。我最早在企业里做 Agent 落地时最深的体会就是用户评判一个 AI 靠不靠谱不是看它能不能写诗而是看它能不能准确说出咱们部门上个月的报销量是多少。这个问题如果纯靠大模型本身永远答不对。微调有没有用有用但微调是把你的一部分领域知识灌进模型权重里成本高、周期长、更新一次要重新训一次而且对于每天都在变的企业数据来说微调完全跟不上节奏。这就引出了 RAG 最核心的价值把知识从模型参数中解放出来放到外部知识库里需要的时候检索出来再交给模型回答。模型只需要做一个聪明的读者而知识库负责提供正确的资料。1.2 知识割裂企业私有数据与模型之间的断层企业内部常年积累的各种文档——合同、SOP、产品手册、工单记录、ERP 里的商品描述——这些数据散落在不同的系统里天然存在严重的知识割裂问题。当你把 Agent 接入这些系统时如果缺乏有效的知识获取管道Agent 面对这些信息是两眼一抹黑的。你看最近热词里高频出现的知识割裂 RAG、解决了知识割裂 RAG说的就是这个场景。我自己做过一个 ERP 商品检索的 Agent 项目当时最头疼的就是如何处理同一商品在不同业务系统里的属性差异采购系统里叫华为笔记本电脑 MateBook X Pro售后系统里叫MateBook X Pro 2024 款酷睿 Ultra7。传统的关键词搜索完全没法把这两条记录关联起来。RAG 配合向量语义检索就能干这活它会先把所有记录向量化然后在语义空间里找相似度最高的内容把分散的记录拼成一个完整的商品视图。这才是 RAG 在产品检索类场景里的真正价值而不是简单地问一个答一个。1.3 Agent 的感知-决策-行动闭环里RAG 是感知层的地基如果把 AI Agent 比作一个人那么大模型是大脑工具调用Function Calling / Tool Use是手脚而 RAG 就是眼睛和耳朵。Agent 要做决策先得有信息输入这一点在 Agentic 架构里体会更深——Agent 在规划任务时往往需要先去检索知识库才知道下一步具体该调用哪个工具、按什么顺序执行。举个实战中的例子我做一个售后客服 Agent 时用户的提问是我的笔记本连不上公司 WiFi怎么办。Agent 的第一步不是直接给答案而是先把这个问题的故障现象向量化去知识库检索到相关的排查文档拿到文档里写的几个排查步骤后再结合用户的具体设备信息调用工具生成一份个性化排查清单。如果没有 RAG模型只能套用通用知识永远给不出贴合你公司网络环境和 IT 政策的回答。RAG 之于 Agent是感知层的地基感知层做不好后面所有的决策和行动都是空中楼阁。2. RAG 完整工作链路拆解从文档入库到生成回答2.1 离线索引让文档变成向量空间里的坐标点RAG 的第一个大阶段叫索引构建也就是把原始文档处理成计算机能检索的结构化数据。这个过程可以拆成四个步骤文档加载与清洗把 PDF、Word、Markdown、HTML 等格式的文档解析成纯文本。这一步最容易踩坑PDF 里的表格解析出来可能是一片乱码扫描件需要 OCR网页里可能有大量导航和广告噪声。我的经验是图片型 PDF 直接扔给 OCR 服务表格类文档尽量转成 CSV 或结构化 Markdown 再入库否则就是给后面的检索环节埋雷。文本切分Chunking把长文档切成合适大小的片段。切分策略直接决定检索效果常见的方式有固定大小切分、递归字符切分、基于文档结构切分和语义切分。对中文文档我一般优先用递归字符切分把分隔符优先级设为\n\n、\n、。、、块大小设置在 500-800 个 token 左右。文本向量化Embedding用嵌入模型把每个文本片段转换成一个高维向量。这个向量要能表达文本的语义相似的文本在向量空间里距离更近。中文环境我推荐从 BGE、bge-m3 这类模型入手。向量入库与索引创建把向量和原文、元数据一起存入向量数据库并建立索引结构如 HNSW、IVF方便后续快速相似度检索。这里要注意同一个文档片段需要保留原文引用信息方便最后回答时标注来源。实际项目中我会把所有入库的片段都打上 metadata比如来源文档名、章节号、页码、上传时间等。这些元数据在做按条件过滤时非常关键——比如只搜索某一年份的合同或者只搜索某个产品线的资料可以先用元数据缩小检索范围再做向量检索效率和准确性都更高。2.2 在线检索与生成相似度计算、上下文组装与引用输出用户提问时RAG 系统的在线部分会发生这么几个步骤用户问题向量化得到 query embedding。在向量库中执行相似度检索用余弦相似度或内积计算返回 Top-K 个最相关的片段。可选地做重排序Rerank把 Top-K 片段用更精细的模型重新精排一遍。把问题和检索到的片段组装进 Prompt让大模型基于这些上下文生成回答。这个链路看起来不复杂但每个环节都有很大的优化空间。在公司内部搭建一个最小可用的 RAG 系统选好 Embedding 模型和向量库之后基本上一天时间就能串起来但真正要在生产环境里稳定运行、回答准准确率超过 90%需要把每个环节的细节都抠到位。关于 Prompt 组装一个好的 RAG Prompt 至少要包含三件事检索到的参考资料、用户的问题、输出约束。输出约束里必须强调当参考资料无法回答问题时直接说明不知道不要编造以及引用来源标注到具体文档。我在早期项目里吃过亏——模型从检索片段里找到了一句话但引用错了文档来源用户拿着来源去核对发现对不上信任感瞬间崩塌。所以引用必须精确到文档和段落这一点在业务场景里比回答内容本身还重要。2.3 类比理解图书馆、检索员与教授的协同工作把 RAG 讲给完全没有技术背景的朋友听时我最常用的类比是图书馆模型向量数据库就是图书馆里面存着成千上万本书的摘要卡片每张卡片都在一个精确的位置上向量坐标。Embedding 模型就是图书分类法它把语义相近的书放在相邻的书架上。检索环节就是检索员拿着读者写的需求描述在图书馆里找到最匹配的几本摘要卡。大模型就是一位学术水平很高但从不看书的教授他不可能记住图书馆里所有内容但你把相关资料抽出来摆在他面前他能快速读完并整理出一份条理清晰的答复。这个类比能解释 RAG 的很多特性为什么 RAG 可以解决幻觉因为教授模型阅读的是真实的资料而不是凭空回忆。为什么 RAG 可以及时更新因为图书馆可以随时上架新书更新知识库不需要重新培训教授。为什么 RAG 会答非所问因为检索员找错了书召回了无关片段或没找全召回不足。3. 关键技术选型Embedding、向量库与切分策略怎么选3.1 Embedding 模型选择中文场景避坑与实战推荐Embedding 模型的选择在 RAG 项目里属于一票否决级别的问题选错了后面怎么优化都白搭。你在热词里会看到 bge 系列这是目前中文场景最值得优先考虑的。我自己的选型原则是这样的场景推荐模型说明中文通用文档BAAI/bge-large-zh-v1.5中文效果稳定社区案例多中英混合/多语言BAAI/bge-m3支持 100 多种语言还支持稀疏向量做混合检索纯英文/代码场景text-embedding-3-large或BAAI/bge-large-en-v1.5OpenAI 的性能够强但需调 API本地离线优先BAAI/bge-small-zh-v1.5体积小、速度快适合资源受限的机器如果你用bge-m3我强烈建议你在入库时同时生成稠密向量和稀疏向量检索时做混合加权。实践证明稠密向量擅长抓语义近义改写比如怎么退换货和退货流程是什么稀疏向量擅长抓专有名词和精确术语比如SN 码、SKU。两者结合在中文业务场景里的效果提升非常明显尤其是那些包含大量产品型号、合同编号的场景。3.2 向量数据库选型从本地原型到企业级部署的完整阶梯向量数据库没法说哪家最好只能看哪家最合适你的场景。我把主流选项按从轻到重排了一个阶梯Chroma / FAISS适合本地学习、快速原型验证。Chroma 可以直接嵌在 Python 进程里用不需要额外部署服务但生产环境的性能和扩展性一般。pgvector如果你公司已经在用 PostgreSQL这是成本最低的升级路径。直接在 PostgreSQL 里启用vector扩展支持 SQL 语法做向量检索跟现有业务数据天然打通。中小项目强烈推荐少维护一个中间件。QdrantRust 写的性能好部署简单支持 payload 过滤很灵活适合中小型独立部署项目。Milvus专门为大规模向量检索设计功能全面支持分布式和多种索引类型适合企业级知识库和每天百万级检索请求的场景。我个人的倾向是项目初期先用 pgvector 或 Qdrant 快速跑通业务等检索规模和并发上来了再平滑迁移到 Milvus。不要一上来就上重型方案RAG 的核心难点往往不在存储而在检索质量上你要把精力优先放在切分和检索调优。3.3 Chunk 切分策略的核心参数与调优思路关于切分我尝试过各种花哨的做法最后发现切分策略要从文本结构出发而不是死磕一个固定的最佳块大小。下面这张表总结了我在实战中的参数参考切分策略适用场景常用参数固定窗口切分代码、日志、格式统一的文本chunk_size512 字符overlap64递归字符切分普通文档按换行符、句号分级切分chunk_size500-800overlap80-100Markdown 标题切分Markdown 文档按标题层级分块按 # ## ### 层级递归切割语义切分长文档按语义完整度切块依赖 Embedding成本较高关于overlap重叠参数我特别想强调一下一定不要省略。如果两个相邻 chunk 之间没有重叠那么原本横跨切片边界的那句话就会被拦腰切断上一块丢了后半句下一块又缺了前半句无论检索到哪块都得不到完整信息。overlap 一般设置为 chunk_size 的 10%-20%宁可让相邻两块多一点冗余也尽量不要漏信息。再说说父子分块这个进阶思路有些文档切得太碎会把上下文拆散切得太大又拖慢检索精度。一个折中的方案是小分块检索大分块生成。具体做法是把文档切成较小的块比如 300 token用于向量检索找到最相关的小块后根据元数据回溯到它所属的更大块比如整节 2000 token把大块作为上下文交给模型。这样既保证了检索命中率又保留了足够的上下文语义。4. 从传统 RAG 到 Agentic RAG知识管道的智能进化4.1 传统 RAG 的三大天花板传统 RAG 基本是检索一次、生成一次的流水线模式问题在于场景稍一复杂就破功查询意图理解弱用户问我最近报修过好几次设备想看看有没有共性规律传统 RAG 会把设备报修和共性规律都拿去向量检索但知识库里可能根本没有这类汇总统计型答案。依赖单次检索质量如果用户的问题需要多步推理比如先查产品序列号对应的保修期再查到期的服务条款一次检索根本覆盖不了两步的信息需求。知识碎片化当答案分散在多篇文档里比如某工单的处理依赖另一份制度文件的授权条款时单轮检索找不到完整上下文。这就是 Agentic RAG 出现的直接原因。热词里agentic rag自成一条说明这已经不是一个概念了而是一个具体的落地方向并且 LangChain、Spring AI、LangChain4j 都在往这个方向演进。4.2 Agent 驱动的 RAG规划、多跳检索与自我反思Agentic RAG 的本质是把 RAG 的调用封装成 Agent 的检索工具让大模型自己决定何时检索、检索几次、用什么关键词检索、是否要改写查询。从技术实现角度看核心是三个能力查询改写与意图消解。用户刚说出来的raw query往往不适合直接做向量检索。比较典型的是代词指代它跟华为那款有什么区别——Agent 需要先在对话历史里定位它指的是什么重写成完整的问题再去检索。还有一种情况是口语化表达需要转成知识库里的术语说法比如本子卡得不行要改写成笔记本电脑卡顿性能问题排查。多跳检索Multi-hop Retrieval。把一个大问题拆解成多个子问题逐步检索每步检索的结果作为下一步检索的上下文。我做一个企业制度问答 Agent 时用户会问在项目验收环节如果供应商延期交付按合同条款应该扣多少违约金这个问题要查至少两个知识源项目验收制度和某份具体合同的违约条款。Agent 会先检索制度文档确认验收流程再定位到对应供应商合同最后才组织回答。自我反思与结果验证。Agent 检索完信息后先自我判断一下这些上下文有足够信息回答问题吗上下文之间有没有冲突不满足就重新检索一遍满足才组装最终 Prompt。这就是 well-known 的 Self-RAG 和 Corrective RAG 等方案背后的基本思路。4.3 工程化落地LangChain4j、Spring AI 与 Agent 框架的融合这一节说点贴近开发者的内容。如果你在用 Java 技术栈做企业级 Agent 应用热词里的 LangChain4j 和 Spring AI 是绕不开的。Spring AI 从 1.0 开始内置了 RAG 相关的抽象比如VectorStore、DocumentReader、QueryTransformer等和 Spring Boot 的生态无缝集成。你可以在 Spring 配置里声明一个PgVectorStore的 Bean然后通过RetrievalAugmentationAdvisor给 ChatClient 加上检索能力就像这样Bean VectorStore vectorStore(EmbeddingModel embeddingModel) { return new PgVectorStore(embeddingModel, PgVectorStore.PgVectorIndexConfig.builder() .indexType(PgVectorStore.PgVectorIndexType.HNSW) .build()); } Bean RetrievalAugmentationAdvisor advisor(VectorStore vectorStore) { return RetrievalAugmentationAdvisor.builder() .queryTransformers(new RewriteQueryTransformer()) .retriever(QueryRetriever.builder() .vectorStore(vectorStore) .topK(5) .build()) .build(); }LangChain4j 则提供了更贴近 LangChain Python 的编程模型ContentRetriever接口可以做更细粒度的自定义控制也支持把 RAG 组件注册成 Agent 的工具。我在 Java 项目里更喜欢 LangChain4j 的一点是它的EmbeddingStoreIngestor做文档入库时可以指定分段器、增强器和元数据定制器把整条索引管道用几行代码串起来EmbeddingStoreIngestor ingestor EmbeddingStoreIngestor.builder() .documentSplitter(DocumentSplitters.recursive(600, 80)) .embeddingModel(embeddingModel) .embeddingStore(embeddingStore) .build();对于更复杂的 Agentic RAG我建议你参考热词里提到的 LangChainPython生态。它的create_agentRetrieverTool组合几乎是 Agentic RAG 的标准姿势把检索器包装成ToolAgent 在收到用户问题后自主判断是否调用检索工具、调用几次。Python 做原型可以写得非常快但生产环境稳定性、可观测性Java 系明显更有优势。我的建议是公司里如果已经有成熟的 Java 技术栈Agentic RAG 的生产落地优先考虑 Spring AI LangChain4j做研究和算法迭代用 Python 的 LangChain 或 LlamaIndex 更顺手。4.4 GraphRAG 与 Ontology RAG当知识需要关联而非相似当你处理的知识不只是文档碎片的堆叠而是一张张充满关系的图谱时向量相似度检索会显得力不从心。典型场景公司规章制度里有部门职责与审批权限两个章节它们的语义不相似但在实际业务里是强关联的。传统 RAG 查申请采购需要谁审批可能只检索到采购制度GraphRAG 会沿着知识图谱里的关联关系找到对应的审批权限章节还能可视化展示谁在什么条件下有权审批多少金额。热词里的 GraphRAG、Ontology RAG、LLM Wiki 都指向同一个趋势用图谱结构辅助 RAG 检索可以从全局理解文档间的关联关系而不仅限于片段里的词语匹配。微软开源的 GraphRAG 项目思路是先用 LLM 从文档里抽取出实体和关系图再基于图结构做社区检测式的问题回答Ontology RAG 则更进一步把领域知识建模成结构化本体比如设备-故障-维修方案三元组检索的关键词是按图找点而不是按词找片。如果你的业务有强关系型知识比如故障诊断、合规审查、家族关系图谱我建议你预留一条路在现有 RAG 之上给知识库加一层图谱索引。这不一定要一上来就全量上 GraphRAG可以从本体定义开始先给文档的实体打上标签再逐步建立实体间的关系索引。这样 Agent 在复杂推理场景下能获得传统 RAG 给不了的全局视野。5. RAG 实操经验与避坑实录5.1 检索质量差的真凶往往不在检索而在索引我修过大量检索效果不好的问题最终发现至少一半问题出在索引阶段文档格式解析不干净。扫描版 PDF 没有做 OCR直接入库后文本是乱码PPT 转出来的内容混入了大量文本框坐标信息网页转出来的文本夹杂一大堆导航菜单。这些问题不会在入库时报错却会在检索时给你致命的打击——检索到的片段看着像关键字匹配到了但上下文完全不可读。处理方式是在入库前做清洗层把无效信息剥掉必要时按干净文本给模型原始格式留备份的原则双轨存储。切分粒度不合理。这是另一个重灾区。切得太碎检索到的是孤零零的一句话模型没有上下文可参考切得太大一个 chunk 里混了多件事向量表示被稀释成平均语义检索精度反而下降。我建议拆成两级去调先定 chunk_size 候选集300、500、800用一个评估集跑一遍 Top-K 命中率选指标最好的那组再根据 bad case 手动调整 overlap。向量检索和关键词检索的关系没处理好。很多人以为向量检索万能但我实测发现包含大量精确编码、型号、编号的内容比如GB/T 19001-2016向量检索效果不如最简单的 BM25 关键词检索。你可以在系统里把两者结合成混合检索再做分数归一化融合。这也是为什么我在 3.1 提到 bge-m3 的稀疏向量能力值得重视的原因。5.2 检索参数的黄金规则Top-K、score 阈值与 Rerank关于检索参数我有一套自己验证过的黄金规则Top-K 不要死磕固定的 3 或 5。一般问答 5 够用但涉及多细节准确度的场景比如精确到金额、日期我建议检索 8-10 个候选然后交给一个重排序模型精排取前 3-4。检索多召回一点交给 Rerank 去精排召回率远高于只检索 Top-K 就跑生成。score 阈值必须设但不能设太高。很多向量库返回的相似度分数在语义空间里表现并不稳定同一个模型在不同语料上的分数分布差异很大。我的做法是基于验证集统计分数分布选取能保留绝大多数正样本的分数作为底线再结合 Top-K 做双重约束。宁可多给模型一些低分但不相关的片段也不要因为阈值太高把正确的片段过滤掉。Rerank 是质量提升的秘密武器。推荐用 cross-encoder 模型比如bge-reranker-base它会把 query 和每个候选文本拼接后整体编码比起双塔的向量相似度计算交互式建模的精度要高一个档次。代价是速度慢所以架构上先粗召回向量 Top-K 取 20-30再精排Rerank 取 5性能和效果能兼得。5.3 常见问题速查表从幻觉到引用错乱的排查清单现象根本原因处理建议回答明显编造检索片段不够、Prompt 未声明不知为不知增加 Top-K强化 Prompt 输出约束加无法回答请明确说明指令回答正确但引用来源混乱检索片段没绑定精确元数据生成时把多个片段混合引用入库时给每块打上 doc_id chunk_index生成时要求按来源编号标注相似问题反复答不准Embedding 模型没有针对业务术语优化考虑微调 Embedding 或在词表层面做同义词扩展检索结果与问题无关查询改写不足、切分粒度不匹配加 QueryTransformer 改写调整 chunk_size做混合检索系统响应太慢检索条数太多、Rerank 模型太重粗召回 Top-K 降到 20 以内Rerank 模型用轻量版或把 Rerank 做成异步知识库更新后效果没变化更新时未重建向量索引或缓存了旧片段入库时校验覆盖写入建缓存失效机制再分享一个排查技巧当问题“答不对”时先别急着调模型或 Prompt把检索返回的 Top-K 片段直接打印出来看一眼。如果片段里根本没有正确答案那是检索/索引的问题如果片段里有答案但模型还是答错了才是生成/Prompt 的问题。这一步能帮你节省至少一半的排查时间。5.4 评估你的 RAG不能只靠感觉差不多最后说评估。说实话RAG 的评估是项目中后期最容易敷衍、也是最容易翻车的地方。我见过太多团队上线前随便找几个问题人工测一测就说效果还行上线后被业务方用真实问题一轮就击穿了。评估至少要分两层离线评估用一组带标准答案的 QA 对计算两个核心指标。召回质量评估检索环节比如 RecallK看正确片段有没有进 Top-K回答质量评估端到端可以用 RAGAS 框架里面的忠实度Faithfulness和答案相关性Answer Relevance指标。忠实度回答的是模型说的话有没有依据检索片段相关性回答的是答案满不满足用户提问。我自己用 RAGAS 跑过几个项目它甚至不需要标注样本用 LLM 打分就行适合没有人工评估资源的团队。在线评估上线后用日志分析用户反馈、回答采纳率、人工抽检比例。有条件的话做 A/B对比不同切分参数或不同检索方案在同一批真实流量上的表现。热词里有一条rag实战、rag项目实战说明现在做 RAG 的人和项目都不少了但真正能写出严格评估报告的项目凤毛麟角。能给出量化指标的 RAG 项目在任何技术评审里都是加分项。6. 这个方向还能怎么继续深挖写到这RAG 的基础链路、选型和踩坑重点基本都覆盖了。如果你顺着这篇的思路往深了走我个人建议按这个顺序往下探索先从评估开始没评估体系就别谈优化再做混合检索与重排序的调优这套组合拳能把大多数项目的检索质量提升一大截接着深入Agentic RAG把查询改写、多跳检索、自我反思这些能力一步步加进去你会发现 Agent 的智能水平有明显变化最后再去看GraphRAG / Ontology RAG当你处理的业务场景有强关系和复杂逻辑时那会是一层全新的知识表达维度。我现在做一个新项目时第一步就是在纸上画出知识从哪里来、要经过哪些处理、最终服务什么问答/推理场景把这条知识获取管道想清楚了才开始写代码。这篇系列能够帮到你一点点就是我分享这些踩坑经验最大的意义。