1. 为什么知识获取管道是 AI Agent 的分水岭做 AI Agent 开发的人绕不开一个尴尬的现实模型本身很聪明但它不知道你公司上个月刚改的产品报价不知道你本地文档里那份接口规范更不知道你私有的那套业务术语。你问它它要么一本正经地胡说要么礼貌地告诉你“我无法访问实时信息”。这不是模型不行而是它的知识边界被训练数据锁死了。知识获取管道要解决的就是这件事。它的核心任务只有一句话在 Agent 需要知识的那一刻把正确、最新、可溯源的知识喂到它嘴边。而RAGRetrieval-Augmented Generation检索增强生成就是目前工程上最成熟、落地最广的一条实现路径。你可以把它理解成给大模型配了一个“随身图书馆管理员”——模型负责推理和表达管理员负责在书架里精准找到那几页资料递过去。这一篇是“走进 AI Agent”系列的第四篇前面聊了 Agent 的骨架、工具调用和记忆机制这一篇专门啃知识获取管道。适合谁看如果你正在做AI Agent 开发、准备搭rag 知识库、或者被“rag 是什么”这个问题卡在门口这篇就是给你写的。我会从整体设计思路讲到稠密嵌入、稀疏嵌入的取舍再到一套能跑起来的rag 实战流程最后把踩过的坑摊开讲。不堆概念只讲能抄作业的东西。先说清楚一个定位问题。RAG 不是万能的它和微调Fine-tuning、长上下文Long Context是三条不同的路。微调是把知识“腌”进模型权重里成本高、更新慢适合固化风格和领域语感长上下文是把资料一股脑塞进 prompt简单粗暴但贵且容易“中间迷失”RAG 则是外挂式检索知识更新只改数据库、不动模型成本可控、可溯源。绝大多数企业级场景RAG 是性价比最高的起点。这也是为什么agentic rag、rag as service这类词最近这么热——大家都在把 RAG 从“一个功能”升级成“一套服务”。2. 知识获取管道的整体设计与方案选型2.1 一条完整的 RAG 管道长什么样很多人以为 RAG 就是“向量数据库 大模型”这个理解太粗了。一条能上生产的管道至少包含五个环节每个环节都能单独把你坑到怀疑人生。第一个环节是文档加载与解析。你的知识可能躺在 PDF、Word、Markdown、网页、数据库甚至 ERP 系统里。PDF 里的表格、扫描件里的文字、双栏排版的阅读顺序都是解析阶段的硬骨头。解析质量直接决定后面所有环节的天花板——垃圾进垃圾出这句话在 RAG 里是铁律。第二个环节是切分Chunking。把长文档切成适合检索和喂给模型的小块。切太大检索精度下降、噪声变多切太小语义被割裂、上下文丢失。这是最考验经验的一步后面会专门展开。第三个环节是嵌入Embedding。把每个文本块转成一个高维向量让“语义相似”变成“向量距离近”。这里就分出了稠密嵌入和稀疏嵌入两条技术路线也是本篇的重点之一。第四个环节是存储与索引。向量存进向量数据库同时往往还要保留原始文本、元数据来源、时间、权限方便过滤和溯源。第五个环节是检索与重排Retrieval Rerank。用户提问先转成向量去库里召回一批候选再用重排模型精挑细选最后把最相关的几块拼进 prompt 交给大模型生成答案。这五步串起来才叫一条知识获取管道。任何一步偷懒最终答案的质量都会打折。2.2 为什么是 RAG而不是别的方案选型这件事我一般看三个维度知识更新频率、数据私密性、成本预算。如果知识每天都在变比如客服话术、库存信息微调基本出局因为每次更新都要重新训练周期和成本都扛不住。RAG 只需要更新数据库里的文档几分钟就能生效。如果数据涉及企业内部资料不能外传那本地 rag、net rag 本地知识库这类私有化部署就是刚需向量库和模型都跑在内网。如果预算有限又想快速验证RAG 的起步成本远低于微调——你甚至可以用开源嵌入模型加一个本地向量库零 API 成本跑通全流程。还有一个常被忽略的点可溯源。RAG 能把答案对应的原文片段一起返回用户能点开看“这话是从哪份文档来的”。在法务、医疗、金融这类场景可溯源不是加分项是准入项。微调做不到这一点模型说完你根本不知道依据在哪。2.3 稠密嵌入与稀疏嵌入两条腿走路才稳这是本篇最核心的技术选型值得掰开讲。稀疏嵌入是传统信息检索的老将。它把文本表示成一个超高维、绝大多数维度为 0 的向量每个维度对应词表里的一个词。最典型的就是 BM25 这类基于词频的算法。它的强项是关键词精确匹配用户搜“X200 型号电池”文档里只要有这几个字就能精准命中。缺点是它不懂同义词——“手机”和“移动电话”在它眼里是两个完全不同的词语义鸿沟跨不过去。稠密嵌入是深度学习带来的新武器。它把文本压成一个几百到几千维的稠密向量每个维度都有值代表某种抽象语义特征。它的强项是语义理解用户问“怎么给设备充电”文档里写的是“为终端补充电量”稠密嵌入能把它们拉到很近的距离。缺点是对专有名词、型号、编号这类精确 token 不敏感容易把“A100”和“A101”当成差不多的东西。看到这里你应该明白了两者不是替代关系是互补关系。生产环境里我强烈建议混合检索Hybrid Retrieval——稀疏负责精确命中稠密负责语义召回两路结果融合后再重排。这就是很多rag 实战项目里效果提升最明显的一招。至于ontology rag、graphrag这类进阶玩法本质是在稠密和稀疏之外再引入知识图谱的结构化关系适合实体关系复杂的场景但工程复杂度也上了一个台阶建议先把基础混合检索跑顺再考虑。3. 核心细节解析与实操要点3.1 文档切分决定成败的隐形环节切分策略没有银弹但有清晰的取舍逻辑。固定长度切分最简单按字符数或 token 数硬切比如每 500 token 一块块间留 50 token 重叠。优点是实现快、块大小均匀缺点是经常把一句话、一个表格从中间劈开语义断裂。我一般只在快速验证阶段用它。递归切分是更实用的默认选择。它按优先级依次尝试分隔符先按段落分段落还太大就按句子分句子还大就按字符分。这样能尽量保持语义单元的完整。LangChain 的RecursiveCharacterTextSplitter就是这个思路中文场景记得把分隔符换成中文标点。。语义切分最讲究用嵌入模型计算相邻句子的语义相似度在语义“断层”处切分。效果好但计算成本高适合对精度要求极高的场景。实操中我的经验参数是这样的块大小控制在 300 到 800 token 之间重叠 10% 到 15%。为什么是这个范围因为太小比如 100 token会导致单块信息不足检索出来答非所问太大比如 2000 token会稀释语义一块里混了好几个主题向量表示变得模糊。重叠是为了防止关键信息正好落在切分边界上被割裂。注意表格和代码块要特殊处理。表格建议整块保留或转成 Markdown 后单独成块代码块按函数或类切分千万别按字符硬切否则检索出来的代码片段根本没法用。3.2 嵌入模型怎么选嵌入模型是管道的“翻译官”它把文本翻译成向量。选错了后面再优化也白搭。选型看四个指标语义质量检索准确率、维度影响存储和速度、语言支持中文必须专门验证、部署方式API 还是本地。中文场景下我一般优先考虑在中文语料上训练过的模型因为很多英文模型对中文的语义区分度明显偏弱。维度方面768 维和 1024 维是常见选择维度越高表达能力越强但存储和计算成本也越高。如果你的知识库规模在百万级以下1024 维完全扛得住上千万级就要认真算存储账了。本地部署还是调 API涉及私密数据、要求本地 rag的场景本地部署是唯一选择。开源嵌入模型配合 GPU 或甚至 CPU 都能跑只是吞吐量差别大。API 方案省心但有数据外传风险和调用成本适合非敏感场景快速起步。实操心得嵌入模型一旦选定整个知识库的向量必须用同一个模型生成。中途换模型意味着所有历史向量全部作废、必须重建。这个坑我见过太多人踩上线前一定要把模型版本锁死并记录在案。3.3 向量数据库的取舍向量数据库这块选型逻辑其实很清晰。小规模、单机、快速验证用 FAISS 或 Chroma 就够了轻量、零运维、几行代码跑起来。中等规模、需要持久化和并发Milvus、Qdrant、Weaviate 这类专业向量库更合适支持分布式、过滤、多租户。如果你已经在用 PostgreSQLpgvector 扩展是个被低估的选择——不用引入新组件直接用现有数据库运维成本最低。选型时重点看三个能力元数据过滤能不能按来源、时间、权限筛、混合检索支持原生支持稀疏稠密最好、水平扩展数据涨了能不能加节点。很多rag 项目后期卡壳就是因为早期选了个不支持元数据过滤的库等要做权限隔离时发现推倒重来。3.4 检索与重排把好最后一道关检索阶段混合检索的融合策略有两种主流做法。一种是加权求和给稠密和稀疏的分数各配一个权重比如 0.7 和 0.3相加另一种是倒数排名融合RRF不看绝对分数只看排名把两路结果的排名倒数相加。RRF 的好处是不用调权重、对分数尺度不敏感我一般先用 RRF 打底再根据效果微调。召回数量上我通常先召回 20 到 50 个候选再交给重排模型。重排模型Reranker是专门做精排的交叉编码器它把 query 和每个候选块拼在一起算相关性精度远高于向量相似度但速度慢所以只用在候选集上。这一步是效果提升的“性价比之王”——加一个重排模型往往比换更贵的嵌入模型提升还明显。最后进 prompt 的块数一般控制在 3 到 5 块。太少信息不足太多会引入噪声还可能超出上下文窗口。这里有个细节给每块标注来源编号让模型在回答时引用既方便溯源也能抑制幻觉。4. 实操过程与核心环节实现4.1 环境与依赖准备下面这套流程是我常用的最小可跑通方案用 Python 生态本地部署嵌入模型向量库用 Chroma轻量、零运维适合快速验证和rag 个人免费版需求。pip install langchain langchain-community chromadb sentence-transformers rank-bm25 jieba pypdf这里解释下每个依赖的作用langchain提供管道编排和切分工具chromadb是向量库sentence-transformers用来加载本地嵌入模型rank-bm25实现稀疏检索jieba做中文分词BM25 需要pypdf解析 PDF。全部本地运行不依赖任何外部 API。4.2 文档加载与切分实现from langchain_community.document_loaders import PyPDFLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载文档实际项目里可以遍历目录批量加载 loader PyPDFLoader(knowledge.pdf) docs loader.load() # 中文场景的递归切分分隔符按优先级排列 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap75, separators[\n\n, \n, 。, , , , , , ] ) chunks splitter.split_documents(docs) print(f切分出 {len(chunks)} 个文本块)chunk_size500配合chunk_overlap75正好是 15% 的重叠比例。分隔符列表里中文标点排在英文空格前面保证中文句子优先在句末切分。这一步跑完建议随机抽几个块打印出来肉眼检查看看有没有被切得莫名其妙的片段。4.3 稠密嵌入与向量入库from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 本地嵌入模型中文场景选中文优化过的模型 embedding HuggingFaceEmbeddings( model_nameBAAI/bge-base-zh-v1.5, model_kwargs{device: cpu}, encode_kwargs{normalize_embeddings: True} ) # 构建向量库并持久化 vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db )normalize_embeddingsTrue是个关键细节把向量归一化到单位长度后余弦相似度计算会更快更稳定。persist_directory让向量落盘下次直接加载不用重新嵌入。模型选的是中文优化的 bge 系列768 维CPU 也能跑适合本地验证。4.4 稀疏检索与混合融合from rank_bm25 import BM25Okapi import jieba # 构建 BM25 索引中文需要先分词 tokenized [list(jieba.cut(c.page_content)) for c in chunks] bm25 BM25Okapi(tokenized) def sparse_search(query, top_k20): tokens list(jieba.cut(query)) scores bm25.get_scores(tokens) ranked sorted(range(len(scores)), keylambda i: scores[i], reverseTrue) return [(chunks[i], scores[i]) for i in ranked[:top_k]] def dense_search(query, top_k20): return vectorstore.similarity_search_with_score(query, ktop_k) def rrf_fusion(dense_results, sparse_results, k60): 倒数排名融合k 是平滑常数常用 60 scores {} for rank, (doc, _) in enumerate(dense_results): key doc.page_content scores[key] scores.get(key, 0) 1 / (k rank 1) for rank, (doc, _) in enumerate(sparse_results): key doc.page_content scores[key] scores.get(key, 0) 1 / (k rank 1) ranked sorted(scores.items(), keylambda x: x[1], reverseTrue) return ranked[:5]RRF 的公式是1/(krank)k 取 60 是论文里的经验值作用是削弱排名靠前项的绝对优势让两路结果更均衡地融合。这段代码把稠密和稀疏两路召回合并输出最终 top 5。实测下来混合检索相比单用稠密在包含型号、编号的查询上召回率提升非常明显。4.5 拼装 Prompt 与生成def build_prompt(query, contexts): context_text \n\n.join( f[{i1}] {c} for i, c in enumerate(contexts) ) return f基于以下资料回答问题并在答案中标注引用的资料编号。 如果资料中没有相关信息请明确说明资料中未提及不要编造。 资料 {context_text} 问题{query} 答案 # 完整调用链 query X200 型号的电池续航是多少 dense dense_search(query) sparse sparse_search(query) top_chunks [c for c, _ in rrf_fusion(dense, sparse)] prompt build_prompt(query, top_chunks) # 把 prompt 交给你的大模型生成即可Prompt 里那句“标注引用的资料编号”和“不要编造”是抑制幻觉的关键。让模型引用编号用户能顺着编号回查原文可信度立刻不一样。这套流程跑通你就有了一个最小可用的rag 知识库。5. 常见问题与排查技巧实录5.1 检索不准的排查顺序检索不准是最常见的问题但很多人一上来就换模型方向错了。正确的排查顺序是从数据往模型倒着查。先看切分把召回的块打印出来如果块本身语义就不完整那问题在切分换再好的模型也没用。再看嵌入拿一个已知答案的问题手动算 query 向量和正确块的相似度如果相似度很低说明嵌入模型不适合你的领域。最后看检索策略如果稠密召回不到但稀疏能召回说明需要混合检索如果两路都召回不到可能是知识库里压根没有这个知识。下面这张表是我整理的常见症状和对应处理可以直接对照排查。症状可能原因处理方向答案答非所问切分过大块内主题混杂减小 chunk_size启用语义切分专有名词检索不到稠密嵌入对 token 不敏感加入稀疏检索做混合同义问法召回失败稀疏为主语义鸿沟提高稠密检索权重答案包含过时信息知识库未更新建立文档更新与重建索引流程引用来源对不上元数据丢失入库时保留 source 字段响应特别慢候选集过大或重排过重控制召回数量重排只跑 top 205.2 几个我踩过的坑坑一中文分词影响 BM25 效果。早期我直接用空格分词处理中文结果 BM25 几乎失效因为中文句子没有空格。换成 jieba 分词后稀疏检索才正常工作。如果你的领域有大量专业术语记得给 jieba 加自定义词典否则术语会被切碎。坑二嵌入模型和查询用了不同的预处理。有些嵌入模型要求查询加特定前缀比如“为这个句子生成表示以用于检索”文档块则不加。如果查询和文档的预处理不一致相似度会系统性偏移。用之前一定翻一遍模型的说明文档。坑三忽略元数据过滤导致权限泄露。多部门共用知识库时如果不做权限过滤A 部门的人可能检索到 B 部门的机密文档。正确做法是在入库时给每块打上权限标签检索时按用户权限过滤。这个必须在架构设计阶段就考虑后期补代价极大。坑四盲目追求大 chunk_size。有人觉得块大信息全结果检索精度暴跌。记住检索是“先找对块再读内容”块太大反而找不准。宁可块小一点、多召回几块也不要块大到语义模糊。5.3 效果评估怎么做没有评估的优化都是瞎猜。我一般准备一个几十到几百条的测试集每条包含问题、标准答案、对应的正确文档块。然后看两个指标召回率正确块有没有被检索到和答案准确率最终生成的答案对不对。召回率和答案准确率要分开看。如果召回率高但答案准确率低问题在生成环节prompt 或模型如果召回率本身就低那优化重点在检索环节。分开定位才能对症下药。这套评估集建议在项目一开始就建边开发边跑别等到上线前才想起来。6. 从基础 RAG 到 Agentic RAG 的演进思路基础 RAG 是“一问一检索一生成”的直线流程但真实场景里用户的问题往往需要多步推理、多轮检索。比如“对比 A 产品和 B 产品的续航并结合最新报价给出推荐”这一句话里藏着好几个子任务查 A 参数、查 B 参数、查报价、做对比。直线 RAG 一次检索搞不定。Agentic RAG的思路是把检索变成 Agent 的一个工具让 Agent 自己决定“要不要检索、检索什么、检索几次”。Agent 可以先拆解问题对每个子问题分别检索发现信息不足时再发起新一轮检索最后综合生成。这就把 RAG 从“管道”升级成了“能力”。实现上你可以把前面的检索函数包装成一个工具注册给 Agent。Agent 的规划能力负责决定调用时机和参数。这里的关键是给检索工具设计好的描述让 Agent 清楚它什么时候该用、能查什么。描述写得好Agent 的调用决策就准。再往上一层是rag as service把整套知识获取能力做成独立服务多个 Agent、多个应用共享同一个知识底座。这时候要考虑的是服务化、多租户、版本管理、灰度更新这些工程问题。agentscope 2.0这类框架提到的 rag as service本质就是这个方向。对大多数团队来说先把基础 RAG 跑稳、评估体系建好再往 Agentic 演进节奏会更舒服。我个人在实际操作中的体会是RAG 这个领域最容易被低估的是“数据工程”部分——解析、切分、清洗、元数据这些脏活累活占了整个项目七成以上的工作量却往往被当成“调个库就行”。真正拉开效果差距的从来不是用了多新的模型而是这些基础环节做得够不够扎实。把切分做细、把混合检索跑通、把评估集建起来这三件事做到位你的知识获取管道就已经超过市面上大部分 demo 了。