1. 为什么知识获取管道是 AI Agent 落地的第一道坎做 AI Agent 开发的人绕不开一个尴尬的现实模型本身很聪明但它不知道你公司内部的业务规则、不知道你上周刚更新的产品文档、不知道你那个跑了八年的 ERP 系统里藏着什么字段。你问它一个非常具体的业务问题它要么一本正经地胡说八道要么给你一段放之四海而皆准的废话。这不是模型不行是它压根没拿到该拿的信息。知识获取管道要解决的就是这件事。它的核心任务只有一句话在 Agent 需要做决策或回答问题的那个瞬间把正确、最新、结构化的知识送到模型面前。听起来简单做起来全是坑。我见过太多团队兴冲冲搭了个 Agent Demo演示的时候效果惊艳一上真实业务就崩十有八九问题出在知识管道上——要么检索回来的东西驴唇不对马嘴要么知识库半年没更新要么文档切分得稀碎导致上下文断裂。RAG也就是检索增强生成是目前解决这个问题最主流的技术路线。它的基本逻辑不复杂把知识存进一个可检索的仓库用户提问时先去仓库里找相关内容再把找到的内容和问题一起塞给大模型让模型基于这些材料来回答。但“基本逻辑不复杂”和“工程上能跑通”之间隔着一条巨大的鸿沟。稠密嵌入和稀疏嵌入怎么选、文档怎么切、检索命中率怎么提、多路召回怎么融合每一个环节都有讲究。这篇文章适合正在搭建 AI Agent 知识管道的工程师、正在选型 RAG 方案的技术负责人以及想搞清楚 RAG 到底怎么回事的产品同学。我会从整体设计思路讲到具体实操细节把我在实际项目中踩过的坑和验证过的方案都摊开来说。不堆术语不绕弯子尽量让刚接触 RAG 的人也能看懂让已经做过 RAG 的人也能找到几个能直接抄的优化点。2. RAG 知识管道的整体设计与核心思路拆解2.1 从“检索生成”到“知识获取管道”的认知升级很多人对 RAG 的理解停留在“向量数据库大模型”这个层面觉得把文档往向量库里一扔检索出来塞给模型就完事了。这种理解在 Demo 阶段够用但在真实业务里会死得很惨。原因很简单真实业务的知识不是一堆静态文档它散落在数据库、API、文件系统、甚至某个同事的聊天记录里真实业务的提问也不是标准问答它带着上下文、带着隐含意图、带着行业黑话。所以我更愿意把 RAG 叫做“知识获取管道”而不是“检索增强生成”。管道这个词强调的是流动性和工程化——知识从源头到模型中间要经过采集、清洗、切分、嵌入、索引、检索、重排、组装这一整套流程任何一个环节出问题最终效果都会打折扣。你得把它当成一个数据工程问题来对待而不是一个模型调用问题。从架构上看一条完整的知识获取管道通常包含三个大阶段。第一阶段是离线索引负责把各种来源的知识处理成可检索的格式包括文档解析、文本切分、嵌入计算、索引构建。第二阶段是在线检索负责在用户提问时快速找到最相关的知识片段包括查询理解、多路召回、结果重排。第三阶段是上下文组装负责把检索结果和用户问题整合成模型能理解的提示词包括去重、排序、截断、格式编排。这三个阶段环环相扣离线索引的质量决定了在线检索的上限在线检索的策略决定了最终回答的质量。2.2 稠密嵌入与稀疏嵌入两条腿走路才稳说到检索就绕不开嵌入模型的选择。这里有两个核心概念稠密嵌入和稀疏嵌入。我用一个生活化的类比来解释。假设你有一个巨大的图书馆稠密嵌入就像是给每本书打了一个“语义指纹”这个指纹是一个几百维的向量能捕捉书的主题、情感、风格等深层特征。你拿另一本书的指纹去比对就能找到语义上最相似的书哪怕它们用的词完全不一样。稀疏嵌入则像是给每本书建了一个“关键词倒排索引”记录每个词在书里出现了多少次、有多重要。你搜“RAG 检索优化”它就把包含这些词的书找出来词匹配得越准排名越高。稠密嵌入的优势在于语义理解能力强。用户问“怎么让 Agent 记住公司内部规定”它能检索到标题是“企业知识库构建指南”的文档哪怕文档里根本没出现“记住”这个词。但稠密嵌入也有短板它对精确匹配不敏感。用户搜一个具体的产品型号“XK-2024B”稠密嵌入可能给你返回一堆“2024年产品规划”之类的文档因为语义上它们都跟产品相关但精确的型号匹配反而丢了。稀疏嵌入正好相反。它对关键词匹配极其敏感BM25 这类经典算法在精确检索场景下依然能打。但它理解不了同义词和语义关联用户问“如何提升检索准确率”它可能找不到标题是“RAG 命中率优化实践”的文档因为字面上没有重叠。所以我的建议很明确不要二选一要做混合检索。稠密嵌入负责语义召回稀疏嵌入负责精确召回两路结果融合后再重排。这个思路在业界已经比较成熟了LangChain、LlamaIndex 这些框架都支持自己实现也不复杂。混合检索的命中率通常比单路检索高出 15 到 30 个百分点这个提升在真实业务里是质变。2.3 文档切分策略切得好比嵌得好更重要我见过很多团队在嵌入模型上反复对比、精挑细选却对文档切分极其随意直接按固定字数一刀切。这是典型的抓小放大。文档切分是知识管道的“第一道加工工序”切得不好后面嵌入再强、检索再准也救不回来。固定长度切分的问题在于它会切断语义单元。比如一份产品说明书某个功能的使用步骤跨了三个段落你从中间切开前半段在块 A后半段在块 B。用户问这个功能怎么用检索到块 A模型只看到一半步骤回答自然不完整。更糟糕的是如果切分点正好落在一个关键参数说明的中间那这个参数就彻底废了。我的实践经验是采用“递归切分重叠窗口”的策略。先按文档的自然结构切比如 Markdown 按标题层级切、PDF 按段落切、代码按函数切。如果某个段落还是太长再按句子边界切。每个块之间保留 10% 到 20% 的重叠内容确保跨块的语义连续性。块的大小控制在 256 到 512 个 token 之间比较合适太小了信息不完整太大了检索精度下降且浪费上下文窗口。还有一个容易被忽略的点元数据。每个知识块除了文本内容还应该带上来源、标题、时间、章节路径等元信息。这些元数据在检索时可以用于过滤和加权比如优先返回最近三个月更新的文档或者只检索某个产品线的知识。没有元数据的知识库就像没有目录的字典查起来全靠运气。3. 核心细节解析与实操要点3.1 嵌入模型选型别只看排行榜选嵌入模型的时候很多人直接去看 MTEB 排行榜挑排名最高的那个。这个做法不能说错但不够全面。排行榜上的分数是在通用基准上测出来的你的业务场景可能跟基准差很远。一个在通用问答上得分很高的模型在你的垂直领域可能表现平平。我的选型框架是这样的先看语言支持中文业务必须选中文能力强的模型很多英文模型在中文上的表现断崖式下跌。再看维度维度越高表达能力越强但存储和计算成本也越高。768 维和 1024 维在实际效果上差距不大但存储成本差 30% 以上。然后看最大输入长度如果你的文档块比较大模型支持的长度必须覆盖。最后也是最重要的在自己的业务数据上做小规模评测。拿 50 到 100 个真实问题人工标注正确答案然后测不同模型的召回率。这个评测花不了多少时间但能避免选型失误带来的返工。目前中文场景下BGE 系列、M3E 系列、GTE 系列都是比较成熟的选择。如果预算充足且对效果要求极高可以考虑调用商业嵌入 API但要注意数据隐私和调用成本。本地部署的话BGE-large-zh 是个稳妥的起点效果和资源消耗比较平衡。3.2 向量索引构建HNSW 不是唯一解向量索引决定了检索的速度和精度。常见的索引类型有 Flat、IVF、HNSW 等。Flat 是暴力检索精度最高但速度最慢只适合小规模数据。IVF 是倒排文件索引通过聚类减少检索范围速度快但精度有损失。HNSW 是分层可导航小世界图在速度和精度之间取得了很好的平衡是目前最主流的选择。但 HNSW 不是没有代价的。它构建索引慢内存占用高参数调不好还会导致检索质量下降。HNSW 有两个关键参数M 和 efConstruction。M 控制每个节点的连接数越大精度越高但内存占用越大通常设在 16 到 64 之间。efConstruction 控制构建时的搜索范围越大索引质量越好但构建越慢通常设在 100 到 500 之间。检索时还有一个 efSearch 参数控制检索时的搜索范围越大精度越高但速度越慢。我的经验是数据量在百万级别以下HNSW 用默认参数就能跑得不错。数据量再大就需要根据实际负载调参了。如果对延迟极其敏感可以考虑 IVF 加量化用少量精度换大幅速度提升。如果数据量很小几万条以内直接用 Flat 反而省心没必要上复杂索引。3.3 查询理解与改写让检索更懂用户用户提问往往很随意带着口语、省略、指代。直接拿原始问题去检索效果通常不好。查询理解这一步就是要把用户的问题“翻译”成更适合检索的形式。常见的操作包括查询改写把口语化的问题改写成更正式的检索语句查询扩展补充同义词和相关术语查询分解把复杂问题拆成多个子问题分别检索。比如用户问“那个新功能怎么配”查询理解模块需要结合对话历史判断“那个新功能”指的是什么然后改写成“XX功能配置步骤”再去检索。这一步可以用小模型来做也可以用规则加词典。如果业务领域的术语比较固定维护一个同义词词典加规则模板就能覆盖大部分场景成本低且可控。如果问题类型多样可以考虑用大模型做查询改写但要注意延迟和成本。3.4 重排检索结果的最后一道质检混合检索会返回多路结果这些结果的排序往往不能直接使用。重排模型的作用就是对候选结果进行精细化排序把最相关的排到最前面。重排模型通常比嵌入模型更重因为它要对“查询-文档”对进行交叉编码计算量更大但精度也更高。常见的重排方案有基于交叉编码器的重排和基于大模型的重排。交叉编码器把查询和文档拼在一起输入模型输出相关性分数效果比双塔嵌入好很多。大模型重排则是让模型直接判断每个文档跟查询的相关性效果更好但成本更高、延迟更大。我的建议是如果对延迟敏感用交叉编码器重排取 Top 20 候选重排后返回 Top 5。如果对效果要求极高且能接受额外延迟可以用大模型重排但要做好缓存和降级策略。重排这一步的投入产出比很高通常能把最终回答的准确率提升 10 到 20 个百分点。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先说一下我常用的技术栈。向量数据库我用 Milvus 或 Qdrant两者都支持混合检索和元数据过滤社区活跃文档齐全。嵌入模型用 BGE 系列通过 FlagEmbedding 库加载。重排模型用 BGE-reranker。框架层面LangChain 和 LlamaIndex 都可以我偏向 LlamaIndex因为它的索引抽象更清晰自定义起来更方便。安装依赖的命令如下pip install llama-index llama-index-vector-stores-milvus llama-index-embeddings-huggingface llama-index-postprocessor-flag-embedding-reranker FlagEmbedding pymilvus如果要用 Qdrant把 milvus 相关的包换成 qdrant 的即可。嵌入和重排模型首次运行会自动下载建议提前下载好放到本地缓存目录避免每次启动都重新下载。4.2 文档加载与切分实操假设我们有一批 Markdown 格式的产品文档放在./docs目录下。加载和切分的代码如下from llama_index.core import SimpleDirectoryReader from llama_index.core.node_parser import MarkdownNodeParser, SentenceSplitter # 加载文档 documents SimpleDirectoryReader(./docs).load_data() # 先按 Markdown 结构切分 md_parser MarkdownNodeParser() nodes md_parser.get_nodes_from_documents(documents) # 对过长的节点再做句子级切分保留重叠 splitter SentenceSplitter(chunk_size512, chunk_overlap64) nodes splitter.get_nodes_from_documents(nodes)这里的关键点是两级切分。第一级按 Markdown 标题切保证每个块有清晰的章节归属。第二级按句子切保证块大小均匀且不切断句子。chunk_overlap64意味着相邻块之间有 64 个 token 的重叠这个重叠量大约占块大小的 12%是我实测下来比较合适的值。重叠太少起不到衔接作用太多则冗余严重。切分完成后建议给每个节点补充元数据for node in nodes: node.metadata[source] node.metadata.get(file_name, unknown) node.metadata[chapter] node.metadata.get(header_path, )这些元数据在后续检索时可以用来过滤和加权。4.3 嵌入计算与索引构建嵌入和索引构建的代码如下from llama_index.embeddings.huggingface import HuggingFaceEmbedding from llama_index.vector_stores.milvus import MilvusVectorStore from llama_index.core import VectorStoreIndex, StorageContext # 加载嵌入模型 embed_model HuggingFaceEmbedding( model_nameBAAI/bge-large-zh-v1.5, max_length512, normalizeTrue ) # 配置 Milvus 向量库 vector_store MilvusVectorStore( urihttp://localhost:19530, collection_nameknowledge_base, dim1024, overwriteTrue ) # 构建索引 storage_context StorageContext.from_defaults(vector_storevector_store) index VectorStoreIndex( nodes, storage_contextstorage_context, embed_modelembed_model, show_progressTrue )normalizeTrue很重要它把嵌入向量归一化到单位长度这样内积就等于余弦相似度检索时计算更高效。dim1024对应 bge-large-zh 的输出维度如果换模型要相应调整。索引构建的时间取决于数据量和硬件。一万个节点在普通 CPU 上大概需要十几分钟GPU 上会快很多。构建过程中建议加进度条方便观察进度。4.4 混合检索与重排的完整实现混合检索需要同时走稠密和稀疏两路。LlamaIndex 原生支持通过 QueryFusionRetriever 做混合检索但稀疏检索部分需要自己配置。一个更可控的方式是分别构建稠密检索器和稀疏检索器然后手动融合。from llama_index.core.retrievers import VectorIndexRetriever from llama_index.retrievers.bm25 import BM25Retriever from llama_index.core.retrievers import QueryFusionRetriever from llama_index.postprocessor.flag_embedding_reranker import FlagEmbeddingReranker # 稠密检索器 dense_retriever VectorIndexRetriever( indexindex, similarity_top_k20 ) # 稀疏检索器 sparse_retriever BM25Retriever.from_defaults( nodesnodes, similarity_top_k20 ) # 融合检索 fusion_retriever QueryFusionRetriever( [dense_retriever, sparse_retriever], similarity_top_k20, num_queries1, modereciprocal_rerank ) # 重排 reranker FlagEmbeddingReranker( model_nameBAAI/bge-reranker-large, top_n5 )modereciprocal_rerank用的是倒数排名融合算法它不依赖两路检索的分数可比性只利用排名信息鲁棒性很好。两路各取 20 个候选融合后还是 20 个再经过重排取 Top 5 送给模型。这个流程在我多个项目里验证过效果稳定。4.5 上下文组装与提示词编排检索到 Top 5 知识块后需要把它们组装成模型能理解的提示词。这里有几个细节要注意。第一给每个知识块标上来源编号方便模型引用也方便后续溯源。第二控制总长度不要超过模型的上下文窗口通常留出 20% 给模型输出。第三如果知识块之间有冲突要在提示词里说明让模型自己判断或标注冲突。一个典型的提示词模板如下你是一个基于知识库回答问题的助手。请根据以下参考资料回答用户问题。 如果参考资料中没有相关信息请明确说明“根据现有资料无法回答”不要编造。 参考资料 [1] {chunk_1} [2] {chunk_2} ... 用户问题{query} 请给出准确、简洁的回答并标注引用的资料编号。这个模板看起来简单但“不要编造”和“标注引用”这两句能显著降低幻觉率。我在实际项目里对比过加上这两句之后编造回答的比例从 15% 降到了 5% 以下。5. 常见问题与排查技巧实录5.1 检索命中率低的排查思路检索命中率低是最常见的问题。排查的时候按这个顺序来先看切分把检索到的块和预期应该检索到的块都打印出来对比一下是不是切分把关键信息切散了。再看嵌入拿几个典型问题手动计算问题和候选块的相似度看看排序是否符合直觉。然后看查询理解用户原始问题和改写后的查询分别检索对比效果差异。最后看重排把重排前后的排序都打出来看看重排是不是把相关结果排到了后面。我遇到过一个典型案例用户问“如何配置数据同步”检索总是返回“数据同步概述”而不是“数据同步配置步骤”。排查发现是切分的时候“配置步骤”部分被切成了多个小块每个块的信息都不完整导致相似度分数偏低。后来调整了切分策略把配置步骤合并成一个块问题就解决了。5.2 常见问题速查表问题现象可能原因排查方法解决方案检索结果不相关嵌入模型不适合领域人工评估 Top 10 结果换领域适配的嵌入模型或做微调精确匹配失效只用稠密检索测试含专有名词的查询加入稀疏检索做混合回答不完整切分过碎检查检索块的完整性调整切分策略增大块或加重叠回答过时知识库未更新检查文档更新时间建立增量索引更新机制延迟过高重排模型太重分段计时换轻量重排或加缓存重复内容多切分重叠过大统计重复率降低重叠比例或去重专有名词检索不到分词问题检查分词结果自定义词典或换分词器多轮对话效果差查询未结合历史对比单轮和多轮加入对话历史做查询改写5.3 几个容易踩的坑第一个坑是忽略元数据过滤。很多团队把所有知识混在一个索引里检索时不做任何过滤。结果用户问 A 产品的问题检索出来 B 产品的文档因为语义相似。解决办法是在检索时加上产品线过滤条件这需要在切分时就打好元数据标签。第二个坑是嵌入模型和重排模型不匹配。嵌入模型用了一个重排模型用了另一个两者的相似度标准不一致导致重排效果不稳定。建议嵌入和重排用同一系列的模型比如都用 BGE 系列。第三个坑是不做增量更新。知识库建好之后就不管了新文档不进去旧文档不删除。时间一长知识库就跟实际业务脱节了。建议建立定时任务定期扫描文档目录自动更新索引。Milvus 和 Qdrant 都支持按 ID 删除和插入增量更新不难实现。第四个坑是忽视查询缓存。很多用户会问相似的问题每次都走完整检索流程很浪费。可以在检索前加一层语义缓存把相似查询的结果直接返回。缓存命中率在真实业务里通常能到 30% 以上对降低延迟和成本很有帮助。5.4 效果评估与持续优化知识管道建好之后需要持续评估和优化。我常用的评估指标有三个召回率即正确答案是否在检索结果中准确率即检索结果中相关内容的占比回答质量即最终回答是否准确完整。前两个指标可以自动化评估准备一批标注好的问答对定期跑评测。第三个指标需要人工评估建议每周抽一批真实用户问题做人工打分。优化是一个迭代过程。先保证召回率再优化准确率最后打磨回答质量。召回率不够就调整切分和检索策略准确率不够就加重排回答质量不够就优化提示词和上下文组装。每次只改一个变量观察指标变化避免同时改多个地方导致无法归因。6. 从基础 RAG 到 Agentic RAG 的演进方向基础 RAG 跑通之后下一步可以考虑往 Agentic RAG 方向演进。基础 RAG 的流程是固定的检索、重排、生成一条路走到黑。Agentic RAG 则把检索能力交给 Agent 自主决策Agent 可以根据问题类型选择不同的检索策略可以多轮检索逐步逼近答案可以在检索不到时主动追问用户。举个例子用户问“我们产品的定价策略跟竞品比有什么优势”。基础 RAG 会直接检索“定价策略”和“竞品”相关的文档然后生成回答。Agentic RAG 则会先检索自家产品的定价文档再检索竞品的公开信息然后对比分析如果发现竞品信息不足还会主动搜索更多来源。这种自主决策的能力让 Agentic RAG 在处理复杂问题时优势明显。实现 Agentic RAG 的关键是把检索工具化。把稠密检索、稀疏检索、数据库查询、API 调用都封装成 Agent 可以调用的工具然后给 Agent 一个规划器让它自己决定什么时候调用什么工具。LangChain 的 Agent 框架和 LlamaIndex 的 Agent 模块都支持这种模式。不过要注意Agentic RAG 的延迟和成本都比基础 RAG 高适合对效果要求高且能接受额外开销的场景。还有一个值得关注的方向是 GraphRAG。它把知识组织成图结构实体是节点关系是边。检索的时候不仅找相关文本块还能沿着图遍历找到关联实体适合处理需要多跳推理的问题。比如“A 产品的负责人是谁他之前负责过什么项目”这种问题需要先找到 A 产品的负责人再找这个人的历史项目图结构天然适合这种查询。GraphRAG 的构建成本比普通 RAG 高不少需要做实体抽取和关系抽取但如果业务场景涉及大量关联查询这个投入是值得的。我在实际项目里的体会是不要一上来就追求最复杂的方案。先把基础 RAG 跑通把切分、嵌入、检索、重排这几个环节调到位把评估体系建起来。基础打牢之后再根据业务需求逐步引入混合检索、重排、Agentic 决策、图结构这些进阶能力。每一步都要有数据支撑不要凭感觉加功能。知识获取管道是一个需要持续打磨的系统没有一劳永逸的方案只有不断迭代的过程。
