1. 为什么 AI Agent 绕不开一条知识获取管道1.1 大模型的天然短板决定了 RAG 不是可选项而是必选项在动手搭建 AI Agent 的过程中很多人会遇到一个非常尴尬的场景Agent 的规划能力、工具调用能力都调试好了模型却在一个常识性问题上给出了离谱的回答。尤其是当你让它处理企业内部的产品手册、规章制度、历史项目文档时它要么一本正经地编造出根本不存在的条款要么支支吾吾地说这个问题我无法回答。本质原因很简单大模型的参数知识是静态的有训练截止日期也不包含你私域数据里的任何内容。模型不知道你公司的产品叫什么名字不知道某个功能是在哪个版本上线的不知道某条流程是哪个部门定的。这时候AI Agent 必须有一条外部知识获取通道否则它的大脑再强也是无源之水。这里要引出 RAG 的定位。RAG 全称 Retrieval-Augmented Generation翻译过来是检索增强生成。它不是某个具体的软件而是一套知识获取管道的设计范式先从外部知识源中检索出与当前问题最相关的片段再把检索结果注入到 Prompt 中让大模型基于这些片段生成答案。放在 AI Agent 的架构里看RAG 就是 Agent 面向私域知识的那根吸管。没有它Agent 只能凭借模型记忆回答问题有了它Agent 才能把知识库当成自己的外接记忆体。1.2 知识割裂才是真正要解决的问题我见过很多团队把 RAG 单纯地理解为给大模型接了个数据库然后越做越不对劲。其实 RAG 要解决的核心问题是知识割裂。一个组织的知识可能散落在数据库里、PDF 文档里、内网 Wiki 里、工单系统里、甚至资深员工的聊天记录里大模型不可能把这些异构数据作为训练语料自然也就无法直接利用。Agent 如果要真正帮人干活就得把这些割裂的知识统一变成可检索的上下文。从知识获取管道这个视角去理解 RAG会比从技术组件视角理解顺手得多。管道意味着有入口、有处理流程、有出口入口负责接入各类文档和数据库处理流程负责清洗、拆解、向量化出口负责接收查询请求并返回最相关的片段。你在规划 AI Agent 时应该先想清楚知识从哪来、怎么进去、查询时怎么出来而不是上来就讨论该用哪个向量数据库。这个视角的差别决定了后续系统是长成能用的 Demo还是可维护的基础设施。2. RAG 管道的四个环节索引、检索、增强、生成2.1 索引环节分块策略和向量化是最容易偷走效果的暗坑RAG 管道第一步是把原始文档变成可检索的索引。索引环节的输入是各种格式的文件输出是向量库里的一组组向量及对应的原始文本。这一步看似只是跑一个脚本实际上直接决定了检索效果的 80%。先看文本拆分。文档不是整本塞进向量库的而是需要拆分成一个个语义完整的片段chunk。拆分策略有多层固定长度拆分不考虑语义边界暴力按 500 个字符切一刀容易把一句话从中间截断递归字符拆分如 LangChain 的 RecursiveCharacterTextSplitter会优先按段落、句子、标点逐层切割效果就好很多语义拆分则依赖 embedding 模型的相似度来判断边界计算成本高但效果最好。实践中对于中文技术文档我常用的是按块大小 500 字符左右、重叠 50 字符的递归拆分这样既能保留上下文连贯性又不会让单条向量承载过多噪音。一个需要注意的点是Chunk 过大检索精度会下降因为向量会包含大量无关信息Chunk 过小上下文可能缺失生成的答案容易断章取义。这个规律和搜索引擎里页面摘要的取舍逻辑很像。再看向量化。这里要区分向量模型和向量数据库两个概念。向量模型负责把文本变成数字向量向量数据库负责存放和检索这些向量。Embedding 模型的选择需要根据语言场景来做中文场景下实测 BGE 系列和 text-embedding-3 都不错英文场景可以选择 OpenAI 的 text-embedding-3-large 或者开源模型。很多人忽略了 embedding 模型和生成模型之间的协同性——如果 embedding 模型效果差即便生成模型再强检索返回的也是不相关的内容生成阶段只能是垃圾进、垃圾出。我通常会做一个简单的相似句召回测试来快速验证 embedding 模型的适配度拿 20 组查询词去召回已知的正确答案片段命中率不达标就换个模型。2.2 检索环节向量相似度 vs 关键词召回混合检索才是王道索引建好之后接下来是检索。检索的本质是把用户输入的问题转换成向量在向量库里找出最接近的 Top-K 个片段。这里面有两个容易被忽视的细节。第一相似度阈值和 Top-K 的联动。仅设定 Top-K 会导致一个问题如果用户问的内容和知识库完全无关系统依然会硬凑出 K 个片段然后让大模型基于这些无关片段编造答案。所以实践中要给相似度设一个阈值低于阈值的片段一律丢弃。没有阈值约束的 RAG 和没有刹车的车一样危险。阈值需要根据向量模型的分布来调整常见做法是把召回的相似度分数打出来看分布取明显拐点作为阈值。第二向量检索和关键词检索各有致命缺陷。向量检索擅长语义匹配蓝牙连不上怎么办 和 配对失败如何解决 这种说法不同但意思相近的查询它能有效命中。但向量检索也有天然盲区对于精确的数字、编号、型号比如型号 ABC-123 的最大功率向量经常分不清混淆相似的字符串需要用关键词检索BM25来兜底。所以在真实的 RAG 系统里我见过的主流做法是混合检索向量召回和关键词召回各做一遍然后用 RRFReciprocal Rank Fusion倒数排名融合把两个结果合并排序再进入重排序Rerank模型进行精排。混合检索不是花活而是同时保证找得对和找得全的折中方案。2.3 增强与生成Prompt 注入和上下文裁剪的细节检索出来的片段如何进到生成环节这里也有不少讲究。增强阶段的核心是构建含上下文的 Prompt简单说就是把用户问题、检索片段、历史对话、系统指令拼接到一起形成模型输入。但拼接不是把几十个片段一股脑塞进去那样会把模型淹没在一堆弱相关文本中反而降低回答质量。这里要讨论上下文裁剪策略。比如检索返回 10 个片段总长度 5000 字模型最大上下文 8000 字还要留出历史对话空间。这时候就得有个砍的规则优先保留高相似度片段尽量保证每个被留下的片段缓存有完整的开头和结尾也可以按窗口切分每个片段保留前后一小段原始段落确保语义孤岛问题不会出现。我习惯在 Prompt 里加一个明确的指令仅基于提供的资料片段回答如果资料中没有答案请直接说明知识库中未找到相关内容不要自行编造。 这个边界约束能明显减少幻觉。生成环节还有两个细节温度参数和引用溯源。知识获取类场景下temperature 一般调到 0 到 0.3 之间温度太高会导致回答跑偏或者表达摇摆不定引用溯源则要求模型在回答时标注来源比如 [1][2]同时对检索结果附上原始文档路径和页码。这既是产品需求也是排查答错问题到底错在检索还是生成的关键手段——如果答案引用的片段本身就不相关问题出在检索如果引用片段相关但答案写错了问题出在生成。3. 从零搭起一套 RAG工具选型与第一个 Demo3.1 技术选型为什么先用 LangChain Chroma 而不是一上来就上重方案说到工具选型不少人第一步就去想哪个向量数据库生产级最强哪个 RAG 框架功能最多结果被配置项淹没。如果你也是第一次上手我建议先走一条最简单的路Python LangChain Chroma 一个 OpenAI 兼容的 Embedding 接口。原因有三一是语言生态。Python 天然是 AI 生态的中心LangChain 社区对 RAG 的封装足够成熟各种文档加载器、文本拆分器、向量库接口都能直接调用不用自己从零实现。二是数据量问题。个人项目和早期的内部工具数据量在几万条文本片段以下时Chroma 这种嵌入式向量库完全够用没必要一开始就上 Milvus、Elasticsearch 这种分布式重武器毕竟运维成本完全不在一个量级。三是为了快速验证。先用最简方案把管道跑通看清每一步的数据流再去替换生产级组件时认知已经建立起来了不至于被容量规划和性能调优的内容干扰。如果你在 Java 技术栈里LangChain4j 或者 Spring AI 也提供了类似 RAG 的组件原理完全一致。我见过很多 Java 团队不想引入 Python 服务直接用 Java 生态搭了一套效果也很好关键还是把四个环节的职责搞清楚。任何框架都只是管道的外壳真正的灵魂在于数据质量、分块策略和检索融合。3.2 一个最小可运行的 RAG 管道实现这里给你一个我从空目录到跑通整个链路的最小例子。假设知识源是一个 Markdown 文件内容是某产品操作手册我们要让 Agent 能回答手册里提到的问题。# 安装依赖 # pip install langchain langchain-community langchain-openai chromadb from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_chroma import Chroma from langchain.chains import create_retrieval_chain from langchain.chains.combine_documents import create_stuff_documents_chain from langchain_core.prompts import ChatPromptTemplate # 1. 加载文档 loader TextLoader(product_manual.md, encodingutf-8) documents loader.load() # 2. 切分文档 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , ., !, ?, ,, , ], ) chunks splitter.split_documents(documents) # 3. 向量化并入库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) # 4. 构建检索器 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 5. 构建生成链路 llm ChatOpenAI(modelgpt-4o-mini, temperature0.1) prompt ChatPromptTemplate.from_messages([ (system, 你是一个知识库问答助手请仅基于以下资料片段回答问题。 如果资料中没有明确答案请直接说明知识库中无相关内容。\n\n{context}), (human, {input}), ]) document_chain create_stuff_documents_chain(llm, prompt) rag_chain create_retrieval_chain(retriever, document_chain) # 6. 提问 resp rag_chain.invoke({input: 如何开启设备的省电模式}) print(resp[answer])这一段代码走完你就已经有了一套完整的 RAG 管道。有人会问这和 AI Agent 有什么关系其实rag_chain本身就可以作为 Agent 的一个工具注册进去。当 Agent 遇到一个需要查文档的问题时它会在规划中决定调用这个工具并传入用户的原始问题工具返回答案后Agent 再把答案整合进自己的最终回复。这就是 Agent 调用知识管道的雏形。3.3 踩过的三个坑重复文档污染、检索噪音、中文分词第一个坑是重复文档污染向量库。开发过程中我经常修改手写稿然后重新跑一遍脚本Chroma 会在同一个目录里追加向量而不是覆盖导致同一个内容以多个向量形式存在于库里。后果是检索结果出现大量雷同片段且占用 JSON 存储空间和拖慢检索速度。解决方式很简单每次跑之前直接清掉./chroma_db目录或者加载数据前先对文档内容做 hash 去重保证每段文本只进一次库。第二个坑是检索噪音导致答案质量劣化。我曾经在梳理一个产品 FAQ 时发现问价格是多少会返回一堆讲发货时间的片段因为它们的向量距离比较接近。单纯调低 Top-K 也不管用正确答案被夹在中间。后来加了两层兜底一层是对检索结果做相似度阈值过滤另一层是在文档加载阶段给每个文本片段附加元数据如category: 价格或category: 物流检索时利用元数据过滤掉和当前问题类别不匹配的片段。这比单纯调阈值有效得多。第三个坑是中文文本的语义边界切割。RecursiveCharacterTextSplitter 如果分隔符数组里不包含中文标点就会出现从句子中间切断的尴尬场景。比如一段话在但字后面被硬生生截成两段前一段说这个功能很好但下一段说在某些场景下不稳定检索时模型只拿到前半截就会产生误导性的结论。后来我在分隔符参数里显式加上了。、、这类中文句末标点并把 chunk_overlap 加大到 50 以上问题才明显缓解。4. RAG 效果评估用 hit rate 说话拒绝拍脑袋4.1 hit rate 和 MRR 到底在衡量什么RAG 系统最容易出现的判断误区是找一个自己最熟悉的问题问一下答案对了就觉得系统没问题。这种拍脑袋式的验收方式在单个问题上有效但无法回答这套系统在不同用户、不同问题形态下是否依然可用。业界常用的两项基础评估指标是 hit rate 和 MRR。hit rate命中率衡量的是对于一组测试问题系统检索出的 Top-K 片段中是否包含了人工标注的正确答案片段。用公式表达命中数 / 总问题数。举个例子你准备了 50 个问题系统在检索阶段对其中 40 个问题都成功召回了正确片段那 hit rate 就是 0.8。这个指标只关心找没找到不关心排第几是评估检索环节的底线指标。MRRMean Reciprocal Rank平均倒数排名则进一步关心正确答案排在第几。如果正确答案在第一个位置贡献 1 分在第二个位置贡献 0.5在第三个位置贡献 0.33。所有问题的得分取平均就是 MRR。MRR 高意味着不仅找得到而且排在很靠前的位置生成阶段拿到正确上下文的风险就更低。刚才那个例子中即便 hit rate 是 0.8如果大量的正确答案排在第 3、第 4 位MRR 可能只有 0.6 左右这说明检索排序需要优化比如引入重排序模型。4.2 一份可复现的评估数据集怎么设计构建评估数据集是整个评估流程里最费工夫但也是最有价值的一步。我建议按下面这个思路来做数量上先做 30 到 50 条不用贪多。每条数据至少包含三列问题、预期答案片段直接从文档中复制的那段原话、答案所在文档路径。覆盖类型上刻意混合直接命中型和间接推理型问题。直接命中型对应文档中明确写出来的事实比如产品支持的最大扭矩是多少间接推理型则需要跨多个片段后综合比如该设备在高海拔地区使用时要注意什么这可能在操作条件、安全提示两个章节都有涉及。收集方式上可以把线上日志里的真实用户问题拿过来改写这类问题通常口语化严重、表述模糊正好用于测试系统的鲁棒性。有了这批数据你可以写一个评估脚本遍历每条测试问题调用检索器拿到 Top-5 结果然后判断预期答案片段的文本是否出现在这 5 个结果里。如果出现计数为命中如果没出现记录它排在 Top-10 的哪个位置方便定位是完全没召回还是召回但排序靠后。这一步在 LangChain 里写起来很简单只要微调一下 3.2 节的代码把rag_chain.invoke换成retriever.get_relevant_documents即可。4.3 从评估结果反推优化方向拿到 hit rate 和 MRR 之后优化方向就清晰了不用瞎猜hit rate 低说明索引环节出了问题优先检查文档加载是否有遗漏分块是否把关键信息切断了embedding 模型是否适配当前语言的文体。这里第一个要怀疑的往往是分块切断了语义尤其是中文长段落会出现问题句子在上一块、答案动词在下一块的情况。hit rate 高但 MRR 低说明检索排序不够准优先尝试混合检索叠加 BM25并引入重排序接口比如 Cohere Rerank 或 BGE Reranker。实测中单独依赖向量相似度的排序结果经常把正确答案排在 2、3 位重排序之后很多场景能稳定提到第 1 位。MRR 和 hit rate 都正常但生成答案仍然错误问题在增强与生成环节建议去检查 Prompt 构造、上下文裁剪规则以及模型是否遵循仅基于资料回答的指令。这个分环节归因的思路是 RAG 调优时最实用的心智模型。每次指标异常先把问题定位到具体环节避免在错误层面上做无用功。5. 从基础 RAG 到 Agentic RAG知识管道的下一步5.1 Agent 和 RAG 的关系工具调用中的知识获取很多人会把 RAG 和 AI Agent 放在对立面上讨论其实它们在架构上是互补的。在我自己的实践里Agent 负责做什么RAG 负责查什么两者通过工具调用协议连接。基础 RAG 是用户提问一次系统检索一次生成一次的三段式结构查询词不经过改写对用户问法高度敏感。而 Agent 化的知识获取开始具备更复杂的决策能力Agent 收到昨天那个功能上线出了什么问题这类模糊问题时会决定先查操作日志再根据日志内容去知识库检索对应功能的使用说明这是一个多步、迭代、带反馈的知识获取过程。让 Agent 来编排知识管道的直接好处是查询词可以被改写和扩展。用户说支付流程有问题Agent 可以基于历史对话推断出是在说对公打款然后把对公打款失败原因作为检索词去知识库查找效果通常好于直接用原始用户问题去检索。这就是 Agentic RAG 的第一层含义知识检索不再是单一的被动查询而是由 Agent 根据上下文规划出的主动行为。5.2 GraphRAG、Ontology RAG 和 Agentic RAG不是替代而是叠加顺着热词往下走GraphRAG、Ontology RAG、Agentic RAG 这几个概念容易被混为一谈。我的理解是它们解决的是不同层面的问题可以叠加使用而不是互相取代。RAG 基础版最适合局部事实型问题比如某某接口的入参是什么它能快速定位到具体段落。但当你问我们产品线里涉及支付能力的模块有哪些这类需要全局关联的问题时基础 RAG 的向量检索基本无能为力——因为答案分散在大量文档里没有任何一个片段能单独回答。这时候 GraphRAG 的价值就凸显了它先利用大模型从文档中抽取实体比如模块名、接口名、业务概念和关系比如依赖属于调用构建成知识图谱检索时用户问题先匹配图谱中的实体和关系路径再结合相关文档段落做生成。GraphRAG 适合回答关系性、全局性问题。Ontology RAG 则更偏领域建模。它是先把某个行业或企业的知识结构抽象成本体Ontology明确概念、属性和约束。比如产品 售后工单 客户 这些概念以及它们之间的关系然后在检索时利用本体约束来过滤和引导减少无意义的候选片段。优点是可解释性强、可控性高适合强领域知识壁垒的场景缺点是本体构建成本较高需要领域专家深度参与。你可以把本体理解为知识库的路标先把路标设计好检索车就能顺着路标走不走冤枉路。Agentic RAG 更像是一个编排层它决定的是用哪种方式去调用这些知识源。同一个 Agent 里可以同时挂基础向量检索工具、GraphRAG 查询工具、甚至外部数据库查询工具Agent 根据问题形态动态选择调用哪个、先后调用顺序、以及是否需要二次复盘。四者的关系可以概括为基础 RAG 提供底层检索能力GraphRAG / Ontology RAG 提供不同结构的知识组织方式Agent 负责在它们之上做决策编排。5.3 演化路线先把基础管道做扎实再加编排层结合这些年的项目经验我在知识获取管道上的演化路线是这样的先做单一知识源的向量检索 RAG把分块、embedding、检索、评估四个环节跑顺再扩展到多知识源的统一索引为每个源建立元数据标签实现按源过滤然后引入混合检索和重排序解决排序精度问题最后叠加 Agent 决策层。值得强调的是不要在第一个版本里就试图引入 Agentic RAG 和 GraphRAG。这些高阶方案在带来灵活性和全局关联能力的同时也带来了调试复杂度的大幅上升。如果你连基础 RAG 的 hit rate 都还没稳定在 0.7 以上GraphRAG 只会让你更难定位问题是出在图谱构建还是检索环节。相反当基础管道的数据质量、检索精度、评估闭环都建立起来后Agentic RAG 的编排层会变成一个薄薄的锦上添花层不会让系统失控。最后再分享一个我觉得很实用的经验每次微调 RAG 配置时把变更前后 hit rate 和 MRR 的变化记录在一个 MRD指标变更记录里。这看起来是个笨办法但久了你会发现很多玄学问题其实都对应着某个不起眼的参数改动比如 chunk_overlap 从 50 调到 80 后 hit rate 提升了 0.05。把这些经验沉淀下来等到做企业级知识平台的时候就是比任何框架选型都更值钱的资产。
1. 为什么 AI Agent 绕不开一条知识获取管道1.1 大模型的天然短板决定了 RAG 不是可选项而是必选项在动手搭建 AI Agent 的过程中很多人会遇到一个非常尴尬的场景Agent 的规划能力、工具调用能力都调试好了模型却在一个常识性问题上给出了离谱的回答。尤其是当你让它处理企业内部的产品手册、规章制度、历史项目文档时它要么一本正经地编造出根本不存在的条款要么支支吾吾地说这个问题我无法回答。本质原因很简单大模型的参数知识是静态的有训练截止日期也不包含你私域数据里的任何内容。模型不知道你公司的产品叫什么名字不知道某个功能是在哪个版本上线的不知道某条流程是哪个部门定的。这时候AI Agent 必须有一条外部知识获取通道否则它的大脑再强也是无源之水。这里要引出 RAG 的定位。RAG 全称 Retrieval-Augmented Generation翻译过来是检索增强生成。它不是某个具体的软件而是一套知识获取管道的设计范式先从外部知识源中检索出与当前问题最相关的片段再把检索结果注入到 Prompt 中让大模型基于这些片段生成答案。放在 AI Agent 的架构里看RAG 就是 Agent 面向私域知识的那根吸管。没有它Agent 只能凭借模型记忆回答问题有了它Agent 才能把知识库当成自己的外接记忆体。1.2 知识割裂才是真正要解决的问题我见过很多团队把 RAG 单纯地理解为给大模型接了个数据库然后越做越不对劲。其实 RAG 要解决的核心问题是知识割裂。一个组织的知识可能散落在数据库里、PDF 文档里、内网 Wiki 里、工单系统里、甚至资深员工的聊天记录里大模型不可能把这些异构数据作为训练语料自然也就无法直接利用。Agent 如果要真正帮人干活就得把这些割裂的知识统一变成可检索的上下文。从知识获取管道这个视角去理解 RAG会比从技术组件视角理解顺手得多。管道意味着有入口、有处理流程、有出口入口负责接入各类文档和数据库处理流程负责清洗、拆解、向量化出口负责接收查询请求并返回最相关的片段。你在规划 AI Agent 时应该先想清楚知识从哪来、怎么进去、查询时怎么出来而不是上来就讨论该用哪个向量数据库。这个视角的差别决定了后续系统是长成能用的 Demo还是可维护的基础设施。2. RAG 管道的四个环节索引、检索、增强、生成2.1 索引环节分块策略和向量化是最容易偷走效果的暗坑RAG 管道第一步是把原始文档变成可检索的索引。索引环节的输入是各种格式的文件输出是向量库里的一组组向量及对应的原始文本。这一步看似只是跑一个脚本实际上直接决定了检索效果的 80%。先看文本拆分。文档不是整本塞进向量库的而是需要拆分成一个个语义完整的片段chunk。拆分策略有多层固定长度拆分不考虑语义边界暴力按 500 个字符切一刀容易把一句话从中间截断递归字符拆分如 LangChain 的 RecursiveCharacterTextSplitter会优先按段落、句子、标点逐层切割效果就好很多语义拆分则依赖 embedding 模型的相似度来判断边界计算成本高但效果最好。实践中对于中文技术文档我常用的是按块大小 500 字符左右、重叠 50 字符的递归拆分这样既能保留上下文连贯性又不会让单条向量承载过多噪音。一个需要注意的点是Chunk 过大检索精度会下降因为向量会包含大量无关信息Chunk 过小上下文可能缺失生成的答案容易断章取义。这个规律和搜索引擎里页面摘要的取舍逻辑很像。再看向量化。这里要区分向量模型和向量数据库两个概念。向量模型负责把文本变成数字向量向量数据库负责存放和检索这些向量。Embedding 模型的选择需要根据语言场景来做中文场景下实测 BGE 系列和 text-embedding-3 都不错英文场景可以选择 OpenAI 的 text-embedding-3-large 或者开源模型。很多人忽略了 embedding 模型和生成模型之间的协同性——如果 embedding 模型效果差即便生成模型再强检索返回的也是不相关的内容生成阶段只能是垃圾进、垃圾出。我通常会做一个简单的相似句召回测试来快速验证 embedding 模型的适配度拿 20 组查询词去召回已知的正确答案片段命中率不达标就换个模型。2.2 检索环节向量相似度 vs 关键词召回混合检索才是王道索引建好之后接下来是检索。检索的本质是把用户输入的问题转换成向量在向量库里找出最接近的 Top-K 个片段。这里面有两个容易被忽视的细节。第一相似度阈值和 Top-K 的联动。仅设定 Top-K 会导致一个问题如果用户问的内容和知识库完全无关系统依然会硬凑出 K 个片段然后让大模型基于这些无关片段编造答案。所以实践中要给相似度设一个阈值低于阈值的片段一律丢弃。没有阈值约束的 RAG 和没有刹车的车一样危险。阈值需要根据向量模型的分布来调整常见做法是把召回的相似度分数打出来看分布取明显拐点作为阈值。第二向量检索和关键词检索各有致命缺陷。向量检索擅长语义匹配蓝牙连不上怎么办 和 配对失败如何解决 这种说法不同但意思相近的查询它能有效命中。但向量检索也有天然盲区对于精确的数字、编号、型号比如型号 ABC-123 的最大功率向量经常分不清混淆相似的字符串需要用关键词检索BM25来兜底。所以在真实的 RAG 系统里我见过的主流做法是混合检索向量召回和关键词召回各做一遍然后用 RRFReciprocal Rank Fusion倒数排名融合把两个结果合并排序再进入重排序Rerank模型进行精排。混合检索不是花活而是同时保证找得对和找得全的折中方案。2.3 增强与生成Prompt 注入和上下文裁剪的细节检索出来的片段如何进到生成环节这里也有不少讲究。增强阶段的核心是构建含上下文的 Prompt简单说就是把用户问题、检索片段、历史对话、系统指令拼接到一起形成模型输入。但拼接不是把几十个片段一股脑塞进去那样会把模型淹没在一堆弱相关文本中反而降低回答质量。这里要讨论上下文裁剪策略。比如检索返回 10 个片段总长度 5000 字模型最大上下文 8000 字还要留出历史对话空间。这时候就得有个砍的规则优先保留高相似度片段尽量保证每个被留下的片段缓存有完整的开头和结尾也可以按窗口切分每个片段保留前后一小段原始段落确保语义孤岛问题不会出现。我习惯在 Prompt 里加一个明确的指令仅基于提供的资料片段回答如果资料中没有答案请直接说明知识库中未找到相关内容不要自行编造。 这个边界约束能明显减少幻觉。生成环节还有两个细节温度参数和引用溯源。知识获取类场景下temperature 一般调到 0 到 0.3 之间温度太高会导致回答跑偏或者表达摇摆不定引用溯源则要求模型在回答时标注来源比如 [1][2]同时对检索结果附上原始文档路径和页码。这既是产品需求也是排查答错问题到底错在检索还是生成的关键手段——如果答案引用的片段本身就不相关问题出在检索如果引用片段相关但答案写错了问题出在生成。3. 从零搭起一套 RAG工具选型与第一个 Demo3.1 技术选型为什么先用 LangChain Chroma 而不是一上来就上重方案说到工具选型不少人第一步就去想哪个向量数据库生产级最强哪个 RAG 框架功能最多结果被配置项淹没。如果你也是第一次上手我建议先走一条最简单的路Python LangChain Chroma 一个 OpenAI 兼容的 Embedding 接口。原因有三一是语言生态。Python 天然是 AI 生态的中心LangChain 社区对 RAG 的封装足够成熟各种文档加载器、文本拆分器、向量库接口都能直接调用不用自己从零实现。二是数据量问题。个人项目和早期的内部工具数据量在几万条文本片段以下时Chroma 这种嵌入式向量库完全够用没必要一开始就上 Milvus、Elasticsearch 这种分布式重武器毕竟运维成本完全不在一个量级。三是为了快速验证。先用最简方案把管道跑通看清每一步的数据流再去替换生产级组件时认知已经建立起来了不至于被容量规划和性能调优的内容干扰。如果你在 Java 技术栈里LangChain4j 或者 Spring AI 也提供了类似 RAG 的组件原理完全一致。我见过很多 Java 团队不想引入 Python 服务直接用 Java 生态搭了一套效果也很好关键还是把四个环节的职责搞清楚。任何框架都只是管道的外壳真正的灵魂在于数据质量、分块策略和检索融合。3.2 一个最小可运行的 RAG 管道实现这里给你一个我从空目录到跑通整个链路的最小例子。假设知识源是一个 Markdown 文件内容是某产品操作手册我们要让 Agent 能回答手册里提到的问题。# 安装依赖 # pip install langchain langchain-community langchain-openai chromadb from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_chroma import Chroma from langchain.chains import create_retrieval_chain from langchain.chains.combine_documents import create_stuff_documents_chain from langchain_core.prompts import ChatPromptTemplate # 1. 加载文档 loader TextLoader(product_manual.md, encodingutf-8) documents loader.load() # 2. 切分文档 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , ., !, ?, ,, , ], ) chunks splitter.split_documents(documents) # 3. 向量化并入库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) # 4. 构建检索器 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 5. 构建生成链路 llm ChatOpenAI(modelgpt-4o-mini, temperature0.1) prompt ChatPromptTemplate.from_messages([ (system, 你是一个知识库问答助手请仅基于以下资料片段回答问题。 如果资料中没有明确答案请直接说明知识库中无相关内容。\n\n{context}), (human, {input}), ]) document_chain create_stuff_documents_chain(llm, prompt) rag_chain create_retrieval_chain(retriever, document_chain) # 6. 提问 resp rag_chain.invoke({input: 如何开启设备的省电模式}) print(resp[answer])这一段代码走完你就已经有了一套完整的 RAG 管道。有人会问这和 AI Agent 有什么关系其实rag_chain本身就可以作为 Agent 的一个工具注册进去。当 Agent 遇到一个需要查文档的问题时它会在规划中决定调用这个工具并传入用户的原始问题工具返回答案后Agent 再把答案整合进自己的最终回复。这就是 Agent 调用知识管道的雏形。3.3 踩过的三个坑重复文档污染、检索噪音、中文分词第一个坑是重复文档污染向量库。开发过程中我经常修改手写稿然后重新跑一遍脚本Chroma 会在同一个目录里追加向量而不是覆盖导致同一个内容以多个向量形式存在于库里。后果是检索结果出现大量雷同片段且占用 JSON 存储空间和拖慢检索速度。解决方式很简单每次跑之前直接清掉./chroma_db目录或者加载数据前先对文档内容做 hash 去重保证每段文本只进一次库。第二个坑是检索噪音导致答案质量劣化。我曾经在梳理一个产品 FAQ 时发现问价格是多少会返回一堆讲发货时间的片段因为它们的向量距离比较接近。单纯调低 Top-K 也不管用正确答案被夹在中间。后来加了两层兜底一层是对检索结果做相似度阈值过滤另一层是在文档加载阶段给每个文本片段附加元数据如category: 价格或category: 物流检索时利用元数据过滤掉和当前问题类别不匹配的片段。这比单纯调阈值有效得多。第三个坑是中文文本的语义边界切割。RecursiveCharacterTextSplitter 如果分隔符数组里不包含中文标点就会出现从句子中间切断的尴尬场景。比如一段话在但字后面被硬生生截成两段前一段说这个功能很好但下一段说在某些场景下不稳定检索时模型只拿到前半截就会产生误导性的结论。后来我在分隔符参数里显式加上了。、、这类中文句末标点并把 chunk_overlap 加大到 50 以上问题才明显缓解。4. RAG 效果评估用 hit rate 说话拒绝拍脑袋4.1 hit rate 和 MRR 到底在衡量什么RAG 系统最容易出现的判断误区是找一个自己最熟悉的问题问一下答案对了就觉得系统没问题。这种拍脑袋式的验收方式在单个问题上有效但无法回答这套系统在不同用户、不同问题形态下是否依然可用。业界常用的两项基础评估指标是 hit rate 和 MRR。hit rate命中率衡量的是对于一组测试问题系统检索出的 Top-K 片段中是否包含了人工标注的正确答案片段。用公式表达命中数 / 总问题数。举个例子你准备了 50 个问题系统在检索阶段对其中 40 个问题都成功召回了正确片段那 hit rate 就是 0.8。这个指标只关心找没找到不关心排第几是评估检索环节的底线指标。MRRMean Reciprocal Rank平均倒数排名则进一步关心正确答案排在第几。如果正确答案在第一个位置贡献 1 分在第二个位置贡献 0.5在第三个位置贡献 0.33。所有问题的得分取平均就是 MRR。MRR 高意味着不仅找得到而且排在很靠前的位置生成阶段拿到正确上下文的风险就更低。刚才那个例子中即便 hit rate 是 0.8如果大量的正确答案排在第 3、第 4 位MRR 可能只有 0.6 左右这说明检索排序需要优化比如引入重排序模型。4.2 一份可复现的评估数据集怎么设计构建评估数据集是整个评估流程里最费工夫但也是最有价值的一步。我建议按下面这个思路来做数量上先做 30 到 50 条不用贪多。每条数据至少包含三列问题、预期答案片段直接从文档中复制的那段原话、答案所在文档路径。覆盖类型上刻意混合直接命中型和间接推理型问题。直接命中型对应文档中明确写出来的事实比如产品支持的最大扭矩是多少间接推理型则需要跨多个片段后综合比如该设备在高海拔地区使用时要注意什么这可能在操作条件、安全提示两个章节都有涉及。收集方式上可以把线上日志里的真实用户问题拿过来改写这类问题通常口语化严重、表述模糊正好用于测试系统的鲁棒性。有了这批数据你可以写一个评估脚本遍历每条测试问题调用检索器拿到 Top-5 结果然后判断预期答案片段的文本是否出现在这 5 个结果里。如果出现计数为命中如果没出现记录它排在 Top-10 的哪个位置方便定位是完全没召回还是召回但排序靠后。这一步在 LangChain 里写起来很简单只要微调一下 3.2 节的代码把rag_chain.invoke换成retriever.get_relevant_documents即可。4.3 从评估结果反推优化方向拿到 hit rate 和 MRR 之后优化方向就清晰了不用瞎猜hit rate 低说明索引环节出了问题优先检查文档加载是否有遗漏分块是否把关键信息切断了embedding 模型是否适配当前语言的文体。这里第一个要怀疑的往往是分块切断了语义尤其是中文长段落会出现问题句子在上一块、答案动词在下一块的情况。hit rate 高但 MRR 低说明检索排序不够准优先尝试混合检索叠加 BM25并引入重排序接口比如 Cohere Rerank 或 BGE Reranker。实测中单独依赖向量相似度的排序结果经常把正确答案排在 2、3 位重排序之后很多场景能稳定提到第 1 位。MRR 和 hit rate 都正常但生成答案仍然错误问题在增强与生成环节建议去检查 Prompt 构造、上下文裁剪规则以及模型是否遵循仅基于资料回答的指令。这个分环节归因的思路是 RAG 调优时最实用的心智模型。每次指标异常先把问题定位到具体环节避免在错误层面上做无用功。5. 从基础 RAG 到 Agentic RAG知识管道的下一步5.1 Agent 和 RAG 的关系工具调用中的知识获取很多人会把 RAG 和 AI Agent 放在对立面上讨论其实它们在架构上是互补的。在我自己的实践里Agent 负责做什么RAG 负责查什么两者通过工具调用协议连接。基础 RAG 是用户提问一次系统检索一次生成一次的三段式结构查询词不经过改写对用户问法高度敏感。而 Agent 化的知识获取开始具备更复杂的决策能力Agent 收到昨天那个功能上线出了什么问题这类模糊问题时会决定先查操作日志再根据日志内容去知识库检索对应功能的使用说明这是一个多步、迭代、带反馈的知识获取过程。让 Agent 来编排知识管道的直接好处是查询词可以被改写和扩展。用户说支付流程有问题Agent 可以基于历史对话推断出是在说对公打款然后把对公打款失败原因作为检索词去知识库查找效果通常好于直接用原始用户问题去检索。这就是 Agentic RAG 的第一层含义知识检索不再是单一的被动查询而是由 Agent 根据上下文规划出的主动行为。5.2 GraphRAG、Ontology RAG 和 Agentic RAG不是替代而是叠加顺着热词往下走GraphRAG、Ontology RAG、Agentic RAG 这几个概念容易被混为一谈。我的理解是它们解决的是不同层面的问题可以叠加使用而不是互相取代。RAG 基础版最适合局部事实型问题比如某某接口的入参是什么它能快速定位到具体段落。但当你问我们产品线里涉及支付能力的模块有哪些这类需要全局关联的问题时基础 RAG 的向量检索基本无能为力——因为答案分散在大量文档里没有任何一个片段能单独回答。这时候 GraphRAG 的价值就凸显了它先利用大模型从文档中抽取实体比如模块名、接口名、业务概念和关系比如依赖属于调用构建成知识图谱检索时用户问题先匹配图谱中的实体和关系路径再结合相关文档段落做生成。GraphRAG 适合回答关系性、全局性问题。Ontology RAG 则更偏领域建模。它是先把某个行业或企业的知识结构抽象成本体Ontology明确概念、属性和约束。比如产品 售后工单 客户 这些概念以及它们之间的关系然后在检索时利用本体约束来过滤和引导减少无意义的候选片段。优点是可解释性强、可控性高适合强领域知识壁垒的场景缺点是本体构建成本较高需要领域专家深度参与。你可以把本体理解为知识库的路标先把路标设计好检索车就能顺着路标走不走冤枉路。Agentic RAG 更像是一个编排层它决定的是用哪种方式去调用这些知识源。同一个 Agent 里可以同时挂基础向量检索工具、GraphRAG 查询工具、甚至外部数据库查询工具Agent 根据问题形态动态选择调用哪个、先后调用顺序、以及是否需要二次复盘。四者的关系可以概括为基础 RAG 提供底层检索能力GraphRAG / Ontology RAG 提供不同结构的知识组织方式Agent 负责在它们之上做决策编排。5.3 演化路线先把基础管道做扎实再加编排层结合这些年的项目经验我在知识获取管道上的演化路线是这样的先做单一知识源的向量检索 RAG把分块、embedding、检索、评估四个环节跑顺再扩展到多知识源的统一索引为每个源建立元数据标签实现按源过滤然后引入混合检索和重排序解决排序精度问题最后叠加 Agent 决策层。值得强调的是不要在第一个版本里就试图引入 Agentic RAG 和 GraphRAG。这些高阶方案在带来灵活性和全局关联能力的同时也带来了调试复杂度的大幅上升。如果你连基础 RAG 的 hit rate 都还没稳定在 0.7 以上GraphRAG 只会让你更难定位问题是出在图谱构建还是检索环节。相反当基础管道的数据质量、检索精度、评估闭环都建立起来后Agentic RAG 的编排层会变成一个薄薄的锦上添花层不会让系统失控。最后再分享一个我觉得很实用的经验每次微调 RAG 配置时把变更前后 hit rate 和 MRR 的变化记录在一个 MRD指标变更记录里。这看起来是个笨办法但久了你会发现很多玄学问题其实都对应着某个不起眼的参数改动比如 chunk_overlap 从 50 调到 80 后 hit rate 提升了 0.05。把这些经验沉淀下来等到做企业级知识平台的时候就是比任何框架选型都更值钱的资产。
