1. 为什么知识获取管道是 AI Agent 的分水岭做 AI Agent 开发的人绕不开一个尴尬的现实模型本身很聪明但它对你私有的业务知识一无所知。你问它公司内部的报销流程它只能给你编一段听起来很像那么回事的废话。这不是模型不行而是它的知识边界停在了训练数据截止的那一天而且从来没读过你电脑里的那些文档。知识获取管道要解决的就是这个问题。它的核心任务只有一句话在 Agent 需要知识的时候把正确的那一小块知识准确地送到模型面前。听起来简单做起来全是坑。我见过太多项目模型选的是顶配Prompt 写得也漂亮结果卡在知识检索这一步答非所问、张冠李戴最后整个 Agent 沦为演示玩具。RAGRetrieval-Augmented Generation检索增强生成就是目前最主流的知识获取管道实现方案。它的思路非常朴素先把知识切块存起来用户提问时去库里捞最相关的几块连同问题一起塞给大模型让模型基于这些参考资料来回答。这个思路从 2020 年提出到现在已经演化出了稠密嵌入、稀疏嵌入、混合检索、重排序、Agentic RAG 等一大堆变体但底层逻辑没变。这篇文章适合谁看如果你正在从零搭建 AI Agent或者已经搭了一个但发现它不够懂业务那知识获取管道就是你下一个必须啃下来的硬骨头。我会从整体设计思路讲到具体实操把稠密嵌入和稀疏嵌入的区别、向量库怎么选、切块策略怎么定、检索效果怎么调全部拆开揉碎讲清楚。不堆概念只讲能落地的东西。2. 知识获取管道的整体设计与方案选型2.1 一条完整的知识管道长什么样很多人对 RAG 的理解停留在向量数据库 大模型这个层面实际上一条能用的知识获取管道至少包含五个环节每个环节都会影响最终效果。第一个环节是文档加载与解析。你的知识可能散落在 PDF、Word、Markdown、网页、数据库里格式五花八门。解析质量直接决定了后面所有环节的上限——如果 PDF 里的表格被解析成一堆乱码后面检索再精准也是白搭。第二个环节是切块Chunking。大模型有上下文长度限制你不可能把整本手册塞进去所以要把长文档切成小块。切块策略是 RAG 里最容易被低估的环节切得太碎会丢失上下文切得太大会引入噪声。第三个环节是嵌入Embedding。把每个文本块转换成一串数字向量让语义相近的文本在向量空间里距离更近。这里就涉及到稠密嵌入和稀疏嵌入两条技术路线后面会详细展开。第四个环节是存储与索引。向量存到哪里用专门的向量数据库还是传统数据库加扩展索引怎么建才能保证检索速度第五个环节是检索与重排。用户提问时把问题也转成向量去库里找最相似的块。但单纯的向量相似度往往不够准需要配合关键词检索、重排序模型等手段来提升精度。这五个环节串起来才是一条完整的知识获取管道。任何一环掉链子整个 Agent 的问答质量都会崩。2.2 稠密嵌入与稀疏嵌入两条路线的取舍这是 RAG 里最核心的技术选型问题值得单独拎出来讲。稠密嵌入Dense Embedding是把文本映射成一个固定长度的稠密向量比如 768 维或 1024 维每一维都是浮点数。它的优势是能捕捉语义相似性——如何申请年假和休假流程是什么这两句话字面完全不同但稠密嵌入能把它们映射到相近的位置。代表模型有 BGE、M3E、text-embedding-3 系列等。稀疏嵌入Sparse Embedding则是高维稀疏向量绝大多数维度是零只有少数维度有值。最典型的就是 BM25 这类基于词频的算法它本质上是在做关键词匹配。它的优势是精确——用户搜RTX 4090 显卡它就能精准命中包含这几个词的文档不会因为语义相近就召回一堆无关内容。两条路线各有软肋。稠密嵌入对专有名词、型号、代码标识符这类精确匹配场景表现很差你搜ERR_5021它可能给你返回一堆讲错误处理的通用文档。稀疏嵌入则完全不懂语义用户换个说法它就抓瞎。所以现在主流的做法是混合检索Hybrid Search同时跑稠密和稀疏两路召回然后用 RRFReciprocal Rank Fusion之类的算法把两路结果融合排序。实测下来混合检索在大多数场景下比单用一路的召回率高 15% 到 30%。这个提升幅度值得你多花那点计算资源。2.3 为什么我不建议一上来就上 GraphRAG最近GraphRAG、Ontology RAG这些概念很火很多人在搭第一个 RAG 项目时就想着上知识图谱。我的建议是先别。GraphRAG 的核心思路是把知识抽成实体和关系构建图谱检索时沿着图谱游走。它在处理跨文档的多跳推理这类问题上确实有优势比如张三负责的项目里哪些用到了李四团队开发的组件这种需要串联多个实体的问题。但它的代价也很明显。构建图谱需要额外的实体抽取和关系抽取步骤这一步要么烧钱调大模型要么本地跑一个抽取模型成本高、耗时长。而且抽取质量不稳定实体识别错了整个图谱就歪了。对于绝大多数文档问答场景一套调好的混合检索 RAG 已经够用上 GraphRAG 属于杀鸡用牛刀。我的经验是先用基础 RAG 跑通把检索命中率RAG hit rate调到 80% 以上再考虑要不要上图谱。如果基础 RAG 都调不好图谱只会让问题更复杂。3. 核心细节解析与实操要点3.1 切块策略决定检索质量的第一道关切块这件事看起来就是把长文本切成小段但里面的门道很多。最粗暴的做法是固定长度切块比如每 500 个字符切一刀。这种做法的问题是经常把一句话、一个段落从中间切断导致语义不完整。你检索到的块可能前半句在讲 A后半句在讲 B模型看了也懵。稍微好一点的是按语义边界切块优先在段落、句子、标题这些自然边界处切分。这样每个块内部语义相对完整。实现上可以按换行符、句号、分号这些标点做递归切分LangChain 的 RecursiveCharacterTextSplitter 就是这个思路。再进阶一点是带重叠的切块Overlapping Chunking。相邻两个块之间保留一定比例的重叠内容比如 10% 到 20%。这样做的好处是即使一个关键信息正好落在切分点上它也会同时出现在前后两个块里不至于丢失。代价是存储和检索的计算量会增加。关于块大小没有一个放之四海皆准的数字但有一些经验值可以参考场景类型建议块大小重叠比例理由技术文档、API 手册300-500 字符15%内容密度高小块更精准长篇文章、报告500-800 字符10%需要保留段落完整性对话记录、FAQ200-400 字符20%一问一答本身就很短法律、合同文本800-1200 字符10%条款之间关联性强注意块大小不是越小越好。块太小会导致单个块信息量不足模型拿到手也不知道在说什么块太大则会引入无关噪声稀释关键信息。我一般会先用 500 字符起步然后根据实际检索效果微调。还有一个容易被忽略的点给每个块加上下文元数据。比如这个块来自哪个文档、哪一章、哪一节。检索时可以把这个元数据一起返回让模型知道这段内容的出处。更高级的做法是给每个块生成一个简短的摘要检索时用摘要匹配返回时用原文这样能兼顾检索精度和上下文完整性。3.2 嵌入模型选型别只看排行榜嵌入模型的选择直接决定了稠密检索的效果。市面上的模型很多选型时不能只看 MTEB 排行榜还要考虑实际约束。中文场景下BGE 系列如 bge-large-zh-v1.5是目前比较稳妥的选择在中文语义相似度任务上表现稳定社区支持也好。M3E 系列也是常见选项体积相对小一些适合资源受限的场景。如果追求更好的效果且不介意调用外部服务一些商业嵌入 API 的表现确实更强但要注意数据隐私和调用成本。多语言场景下需要选支持多语言的模型比如 BGE-M3它同时支持稠密、稀疏和多向量检索一个模型搞定多种需求省去了维护多套模型的麻烦。选型时要重点看几个指标。向量维度影响存储和检索速度768 维和 1024 维在效果上可能只差几个百分点但存储成本差不少。最大输入长度决定了单个块能有多长大部分模型支持 512 个 token超过就会被截断所以块大小要配合模型的最大长度来定。推理速度在批量处理大量文档时很关键本地部署的话要考虑 GPU 显存够不够。实操心得嵌入模型和检索时的查询向量必须用同一个模型生成。我见过有人建库时用模型 A查询时用模型 B结果检索效果惨不忍睹。这个坑一定要避开。3.3 向量数据库从轻量到企业级的选型向量存哪里取决于你的数据规模和部署环境。小规模场景几万条以内用 FAISS 就够了。它是 Facebook 开源的向量检索库纯内存运行速度快部署简单一个 Python 包搞定。缺点是数据存在内存里重启就没了需要自己做持久化。中等规模场景几十万到几百万条可以考虑 Chroma、Qdrant、Milvus 这些专门的向量数据库。Chroma 上手最简单适合快速原型Qdrant 性能好支持过滤和混合检索Milvus 功能最全但部署和维护成本也最高。企业级场景如果团队已经在用 PostgreSQL可以直接上 pgvector 扩展省去维护独立向量库的麻烦。如果用的是 Java 技术栈Spring AI已经提供了对多种向量库的统一抽象切换底层实现时改动很小。选型时除了看规模还要考虑是否支持元数据过滤。比如你只想在2024 年之后的文档里检索向量库得支持按元数据筛选后再做向量搜索。这个功能在实际项目里非常常用选型时一定要确认。4. 实操过程与核心环节实现4.1 从零搭建一条最小可用的知识管道下面我用 Python 走一遍完整流程把一条最小可用的 RAG 管道搭起来。这套代码可以直接抄作业改改路径就能跑。第一步加载和切块。假设你的知识是一堆 Markdown 文件from langchain_community.document_loaders import DirectoryLoader from langchain_text_splitters import RecursiveCharacterTextSplitter # 加载目录下所有 markdown 文件 loader DirectoryLoader(./knowledge, glob**/*.md) docs loader.load() # 递归切块优先在段落、句子边界切分 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap75, # 15% 重叠 separators[\n\n, \n, 。, , , , , , ] ) chunks splitter.split_documents(docs) print(f共切出 {len(chunks)} 个块)这里 separators 的顺序很重要它会按顺序尝试用这些分隔符切分优先用靠前的。把段落分隔符放在最前面能最大程度保证语义完整。第二步生成嵌入并存入向量库。这里用 Chroma 做演示from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import Chroma # 加载中文嵌入模型 embedding HuggingFaceBgeEmbeddings( model_nameBAAI/bge-large-zh-v1.5, model_kwargs{device: cuda}, encode_kwargs{normalize_embeddings: True} ) # 建库并持久化 vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db )normalize_embeddingsTrue这个参数别漏了它把向量归一化到单位长度这样计算余弦相似度时可以直接用点积速度快很多效果也稳定。第三步检索。基础检索就是拿问题去向量库里找最相似的几个块query 报销流程需要哪些材料 results vectorstore.similarity_search_with_score(query, k5) for doc, score in results: print(f相似度: {score:.4f}) print(doc.page_content[:200]) print(---)k5表示返回最相似的 5 个块。这个数字也不是随便定的太小可能漏掉关键信息太大则会引入噪声。一般 3 到 8 之间比较合适具体看你的块大小和文档密度。4.2 混合检索的实现稠密加稀疏单走向量检索在遇到精确匹配需求时会翻车所以要把 BM25 加进来。LangChain 提供了 EnsembleRetriever 来做这件事from langchain_community.retrievers import BM25Retriever from langchain.retrievers import EnsembleRetriever # 稀疏检索BM25 bm25_retriever BM25Retriever.from_documents(chunks) bm25_retriever.k 5 # 稠密检索向量库 dense_retriever vectorstore.as_retriever(search_kwargs{k: 5}) # 融合两路结果权重各占一半 ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, dense_retriever], weights[0.5, 0.5] ) results ensemble_retriever.invoke(ERR_5021 错误怎么处理)权重怎么定如果业务里精确匹配需求多比如查型号、查错误码可以把 BM25 权重调高到 0.6 甚至 0.7如果更多是自然语言问答向量检索权重可以高一些。这个需要根据实际数据调没有标准答案。4.3 重排序把最相关的顶上来混合检索解决了召回问题但召回的块排序未必最优。这时候可以加一个**重排序Rerank**环节用一个专门的交叉编码器模型对召回的块重新打分排序。交叉编码器和嵌入模型的区别在于嵌入模型是分别把问题和文档转成向量再算相似度速度快但精度有限交叉编码器是把问题和文档拼在一起送进模型直接输出相关性分数精度高但速度慢。所以典型做法是先用向量检索快速召回一批候选比如 20 个再用重排序模型精排取前 5 个送给大模型。from langchain.retrievers import ContextualCompressionRetriever from langchain_community.document_compressors import CrossEncoderReranker from langchain_community.cross_encoders import HuggingFaceCrossEncoder # 加载重排序模型 cross_encoder HuggingFaceCrossEncoder(model_nameBAAI/bge-reranker-large) reranker CrossEncoderReranker(modelcross_encoder, top_n5) # 在混合检索基础上加重排序 compression_retriever ContextualCompressionRetriever( base_compressorreranker, base_retrieverensemble_retriever ) final_results compression_retriever.invoke(报销流程需要哪些材料)加了重排序之后检索精度通常能再提升 10% 到 20%。代价是每次查询多了一次模型推理延迟会增加几百毫秒。如果对响应速度要求极高可以权衡是否加这一层。4.4 把检索结果喂给大模型最后一步是把检索到的块和用户问题拼成 Prompt送给大模型生成回答def build_prompt(query, contexts): context_text \n\n.join([c.page_content for c in contexts]) return f基于以下参考资料回答问题。如果资料中没有相关信息请明确说明资料中未提及不要编造。 参考资料 {context_text} 问题{query} 回答这个 Prompt 模板有两个关键点。一是明确要求基于参考资料回答防止模型自由发挥二是要求没有就说没有这是抑制幻觉最有效的手段之一。我试过很多种 Prompt 写法这两句话是性价比最高的。5. 常见问题与排查技巧实录5.1 检索命中率低的排查思路RAG hit rate是衡量知识管道质量的核心指标指的是应该被检索到的块实际被检索到的比例。如果命中率低按下面的顺序排查。先看切块是否合理。把检索失败的案例拿出来看看正确答案所在的块长什么样。如果块被切得支离破碎语义不完整那问题出在切块环节调整 chunk_size 和 separators。再看嵌入模型是否匹配。中文文档用了英文模型或者专业领域用了通用模型都会导致语义捕捉不准。可以拿几个典型问题手动算一下和正确答案块的相似度如果相似度普遍偏低考虑换模型。然后看检索方式是否单一。纯向量检索在精确匹配场景下天然弱势加上 BM25 做混合检索往往能立竿见影。最后看是否需要重排序。如果召回的块里其实有正确答案只是排在了后面没被取到那加重排序就能解决。5.2 常见问题速查表问题现象可能原因排查方向解决手段答非所问检索到的块不相关检查切块和嵌入模型调整块大小换嵌入模型精确查询失败纯向量检索不擅长精确匹配确认是否用了混合检索加入 BM25调高稀疏权重答案不完整召回块数量不足检查 top_k 设置增大 k 值加重排序模型编造答案Prompt 未约束或检索为空检查检索结果是否为空优化 Prompt加无则说明约束响应太慢重排序或嵌入模型太大分析各环节耗时换小模型或异步处理新文档检索不到索引未更新检查文档是否入库建立增量更新机制5.3 几个踩过的坑坑一块重叠设置过大导致重复召回。有一次我把重叠设成了 50%结果检索出来的 5 个块里有 3 个内容高度重复浪费了上下文窗口。重叠比例控制在 10% 到 20% 就够了别贪多。坑二忽略元数据过滤导致跨领域污染。一个项目里同时有产品和财务两类文档用户问产品问题却召回了财务文档。后来给每个块打上 category 标签检索时先按标签过滤问题就解决了。坑三嵌入模型没归一化导致相似度计算错误。这个坑很隐蔽因为不归一化也能算出结果只是排序会乱。用余弦相似度时一定要确认向量是否归一化或者直接用支持余弦距离的向量库。坑四文档更新后忘记重建索引。知识库是活的文档会增删改。如果没有增量更新机制Agent 就会一直用旧知识回答。建议把索引更新做成定时任务或者文档变更时触发重建。独家技巧建库时给每个块生成一个假设性问题。具体做法是让大模型针对每个块生成 2 到 3 个它可能回答的问题把这些问题和块一起存进向量库。检索时用户的问题更容易匹配到这些假设性问题命中率能提升不少。这个技巧来自一些前沿的 RAG 实践实测有效。6. 知识管道的进阶方向基础 RAG 跑通之后如果还想继续提升有几个方向可以探索。Agentic RAG是最近比较热的方向。传统 RAG 是一次检索一次生成Agentic RAG 则让 Agent 自己决定要不要检索、检索几次、用什么查询词检索。比如用户问一个复杂问题Agent 可以先拆解成几个子问题分别检索再综合回答。这种模式对复杂查询的处理能力明显更强但实现复杂度也更高需要 Agent 框架的支持。多路查询改写是另一个性价比很高的优化。用户的问题往往表述不理想可以先用大模型把问题改写成几个不同角度的查询分别检索后合并结果。比如怎么报销可以改写成报销流程、报销所需材料、报销审批步骤等覆盖面更广。知识图谱融合适合有大量实体关系的场景。把 RAG 和轻量级的知识图谱结合用图谱来处理实体间的关联查询用向量检索来处理语义查询两者互补。不过还是那句话别一上来就追求最复杂的方案。把基础管道的每个环节调扎实命中率做到 85% 以上比堆一堆花哨的技术但每个都半吊子要强得多。我在实际项目里的体会是RAG 的效果提升80% 来自切块策略和检索方式的优化剩下 20% 才来自那些高级技巧。先把地基打牢再考虑盖楼。