1. 为什么知识获取管道是 AI Agent 落地的第一道坎做 AI Agent 的人迟早会撞上同一堵墙模型本身很聪明但你问它公司上个月的报销政策、某个客户的合同条款、你们内部那套跑了八年的 ERP 字段含义它要么一本正经地胡说要么干脆告诉你我没有这方面的信息。这不是模型不行而是它的知识边界停在了训练数据截止的那一天。知识获取管道要解决的就是把这个边界往后推、往深挖让 Agent 在推理时能拿到外部真实、最新、私有的知识。在整条 Agent 链路里知识获取管道的位置非常靠前。你可以把 Agent 想象成一个刚入职的高材生脑子好使但对你公司的业务一无所知。RAGRetrieval-Augmented Generation检索增强生成就是给他配的那套资料室 检索员系统——他不需要把所有资料背进脑子只需要在回答问题时能快速从资料室里翻出最相关的几页然后基于这几页组织答案。这个类比里资料室是知识库检索员是检索器翻出最相关的几页就是稠密嵌入和稀疏嵌入在背后干的活。我见过太多团队在 Agent 项目上翻车不是因为模型选错了而是因为知识管道没搭好。检索召回率上不去后面接再强的模型也是垃圾进垃圾出。所以这一篇我不打算讲虚的直接把 RAG 基础里最核心的几个环节拆开文档怎么切、向量怎么算、稠密和稀疏怎么配合、检索结果怎么重排、以及那些文档里不会写但实际会踩的坑。适合正在从 0 到 1 搭建 AI Agent 的开发者也适合已经用了 RAG 但效果不理想的同学对照排查。2. RAG 基础架构的整体设计与选型思路2.1 一条完整的知识获取管道长什么样很多人对 RAG 的理解停留在把文档塞进向量库然后相似度检索这一步。这只是管道的一小段。一条能上生产的知识获取管道至少包含五个环节文档解析与清洗、分块Chunking、嵌入Embedding、索引与存储、检索与重排。每个环节都会影响最终的召回质量而且它们之间是乘法关系——任何一环拉胯整体效果都会断崖式下跌。我习惯把这五个环节画成一条流水线来理解。原始文档进来先做解析把 PDF、Word、HTML、数据库记录统一成纯文本然后按语义或固定长度切块每块单独算向量向量连同原文、元数据一起写进向量库用户提问时问题也走一遍嵌入去库里做相似度匹配召回 Top-K 候选最后用重排模型对候选精排把最相关的几块喂给大模型生成答案。这条链路里分块策略和检索策略是两个最容易被低估、也最影响效果的环节。为什么强调管道这个词因为它意味着数据是流动的、可迭代的。你今天切的分块策略明天发现召回不行得能快速重切、重建索引而不是推倒重来。所以架构设计之初就要考虑分块参数是否可配置、嵌入模型是否可替换、索引是否支持增量更新。这些决定了你后续调优的成本。2.2 稠密嵌入与稀疏嵌入为什么两个都要这是 RAG 基础里最值得讲清楚的一对概念。稠密嵌入Dense Embedding把一段文本映射成一个几百到几千维的稠密向量每一维都是浮点数语义相近的文本在向量空间里距离近。它的强项是语义匹配——你问怎么报销差旅费它能召回写着出差费用申请流程的文档哪怕字面一个词都不重合。稀疏嵌入Sparse Embedding则是高维稀疏向量绝大多数维度是零只有出现过的词对应的维度有值典型代表就是 BM25 这类基于词频的算法。它的强项是精确匹配——你搜一个产品型号XR-2000A它能精准命中而稠密嵌入很可能把这个型号和XR-2000B混为一谈。只用一个行不行实测下来单用稠密嵌入遇到专有名词、型号、代码、人名这类需要精确匹配的场景召回经常掉链子单用稀疏嵌入遇到同义改写、口语化提问又完全抓瞎。所以现在主流的做法是混合检索Hybrid Retrieval两路并行召回再用融合算法比如 RRFReciprocal Rank Fusion把结果合并。RRF 的逻辑很简单不看绝对分数只看排名把两路结果里排名靠前的文档加权求和避免了两路分数尺度不一致的问题。提示混合检索不是银弹。如果你的知识库全是自然语言叙述类文档稠密嵌入单独用可能就够了如果全是结构化字段、型号、编号稀疏嵌入的权重应该调高。别盲目上混合先搞清楚你的数据长什么样。2.3 分块策略切得好比嵌入模型选得好更重要我个人的经验是分块策略对召回效果的影响往往比换一个更贵的嵌入模型还大。原因很简单嵌入模型再强它也只能对你给它的那块文本负责。如果一块文本里混了三个不相关的主题算出来的向量就是个四不像检索时哪个主题都匹配不准。常见的分块方式有三种。固定长度分块最简单按字符数或 token 数切比如每 512 个 token 一块块之间留 50 token 重叠。优点是实现快、块大小均匀缺点是经常在句子中间切断语义不完整。语义分块按段落、标题、句子边界切尽量保证每块是一个完整语义单元。递归分块是前两者的折中先按大分隔符段落切太大再按小分隔符句子切直到满足大小限制。LangChain 的RecursiveCharacterTextSplitter就是典型实现。块大小怎么定没有万能值但有个经验区间中文场景 300 到 800 字英文场景 256 到 1024 token。块太小上下文不足模型拿到碎片拼不出完整答案块太大噪声多检索精度下降。重叠部分建议是块大小的 10% 到 20%防止关键信息正好卡在切割边界上被劈成两半。3. 核心环节的实操要点与参数细节3.1 文档解析脏数据是召回率的第一杀手真实项目里文档解析花的时间经常比调模型还多。PDF 里的表格、扫描件里的文字、Word 里的批注、HTML 里的导航栏全是噪声。我踩过最深的坑是一个客户的知识库PDF 用双栏排版解析出来文字顺序全乱两栏内容交错在一起检索出来的东西驴唇不对马嘴。处理原则是能拿到结构化源就别用解析。如果知识来自数据库直接查字段如果来自 Confluence、Notion 这类有 API 的平台走 API 拿干净的 Markdown只有实在没有源文件时才上 PDF 解析。PDF 解析工具里PyMuPDF对文本型 PDF 效果好扫描件得先走 OCR。表格建议单独抽出来转成 Markdown 或 JSON别混在正文里。清洗环节要做的事包括去掉页眉页脚、合并被硬换行拆断的句子、统一全半角、去掉多余空白。这些看着琐碎但每一条都直接影响后续分块和嵌入的质量。我一般会写一个清洗函数把常见噪声用正则批量处理处理完抽样人工看几十条确认没有明显问题再往下走。3.2 嵌入模型选型别只看排行榜嵌入模型的选择要看三个维度语言支持、维度、以及是否支持本地部署。中文场景优先选对中文优化过的模型很多英文榜单第一的模型在中文上表现平平。维度方面768 维和 1024 维是常见选择维度越高表达能力越强但存储和计算成本也越高。一个百万级文档的知识库1024 维向量用 float32 存储光向量就占 4GB 左右这个账要提前算。本地部署还是调 API涉及私有数据、合规要求高的场景本地部署是刚需。开源嵌入模型里BGE 系列、M3E 系列在中文检索任务上表现稳定社区验证充分。调 API 的好处是省事、模型更新快但数据要出域成本和延迟也要考虑。我的建议是先用 API 快速验证流程跑通效果达标后再评估是否迁移到本地别一上来就纠结部署方式把流程跑通才是第一优先级。注意嵌入模型一旦选定整个知识库的向量都得用它来算。中途换模型意味着全量重建索引。所以选型时多花点时间做对比测试用你自己的真实数据测召回别信通用榜单。3.3 向量库与索引HNSW 参数怎么调向量库选型上小规模十万级以下用 FAISS 或 Chroma 就够部署简单中大规模百万级以上考虑 Milvus、Qdrant、Weaviate 这类专业向量库支持分布式和更丰富的索引类型。选型的核心考量是数据规模、是否需要增量更新、是否需要元数据过滤、运维成本。索引类型里**HNSWHierarchical Navigable Small World**是目前最常用的近似最近邻索引。它有两个关键参数M和efConstruction。M是每个节点的连接数越大图越密召回越高但内存占用越大常用值 16 到 64efConstruction是建索引时的搜索宽度越大索引质量越高但建得越慢常用值 100 到 200。查询时还有个efSearch参数越大召回越高但查询越慢需要在召回和延迟之间权衡。我一般这样调先用默认值M16efConstruction200建索引测召回率和延迟如果召回不够先加efSearch因为它只影响查询不影响索引还不够再考虑重建索引调大M。这个顺序能让你用最小成本找到合适的参数组合。4. 完整实操流程从零搭一条可用的 RAG 管道4.1 环境准备与依赖安装先把基础环境搭起来。Python 3.10 以上核心依赖包括文档解析、分块、嵌入、向量库四类。下面是一套我常用的组合你可以按需替换。pip install pymupdf langchain langchain-community pip install sentence-transformers faiss-cpu pip install rank-bm25 jiebasentence-transformers用来加载本地嵌入模型faiss-cpu是向量库rank-bm25加jieba用来做中文稀疏检索。如果你的数据量大或者要上生产把faiss-cpu换成faiss-gpu或者专业向量库的客户端。4.2 文档解析与分块实现假设我们有一批 PDF 文档先解析再分块。这里用递归分块中文按标点和段落切。import fitz from langchain.text_splitter import RecursiveCharacterTextSplitter def parse_pdf(path): doc fitz.open(path) text for page in doc: text page.get_text() return text def clean_text(text): import re text re.sub(r\n{3,}, \n\n, text) text re.sub(r[ \t]{2,}, , text) return text.strip() splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , , , ] ) raw parse_pdf(handbook.pdf) cleaned clean_text(raw) chunks splitter.split_text(cleaned) print(f共切出 {len(chunks)} 块)chunk_size500是字符数中文场景这个值比较稳。chunk_overlap80是 16% 的重叠防止边界信息丢失。separators列表的顺序很重要它会优先按段落切段落太大再按句子切最后才按字符切这样能最大程度保证语义完整。4.3 稠密与稀疏双路索引构建接下来算嵌入、建索引。稠密用本地模型稀疏用 BM25。from sentence_transformers import SentenceTransformer import faiss import numpy as np from rank_bm25 import BM25Okapi import jieba model SentenceTransformer(BAAI/bge-base-zh-v1.5) # 稠密索引 embeddings model.encode(chunks, normalize_embeddingsTrue) dim embeddings.shape[1] index faiss.IndexFlatIP(dim) index.add(np.array(embeddings).astype(float32)) # 稀疏索引 tokenized [list(jieba.cut(c)) for c in chunks] bm25 BM25Okapi(tokenized)这里用IndexFlatIP做精确内积检索数据量小的时候够用。normalize_embeddingsTrue把向量归一化后内积等价于余弦相似度这是标准做法。BM25 那边用 jieba 分词中文必须分词否则按字切效果很差。4.4 混合检索与重排检索时两路并行用 RRF 融合。def hybrid_search(query, top_k5, k60): # 稠密召回 q_emb model.encode([query], normalize_embeddingsTrue) _, dense_ids index.search(np.array(q_emb).astype(float32), top_k * 2) dense_ids dense_ids[0].tolist() # 稀疏召回 q_tokens list(jieba.cut(query)) scores bm25.get_scores(q_tokens) sparse_ids np.argsort(scores)[::-1][:top_k * 2].tolist() # RRF 融合 rrf {} for rank, doc_id in enumerate(dense_ids): rrf[doc_id] rrf.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(sparse_ids): rrf[doc_id] rrf.get(doc_id, 0) 1 / (k rank 1) ranked sorted(rrf.items(), keylambda x: x[1], reverseTrue) return [chunks[i] for i, _ in ranked[:top_k]]k60是 RRF 的标准平滑参数来自原论文一般不用改。两路各召回top_k * 2个候选融合后取前top_k给重排留了余量。如果对精度要求高可以在融合后再接一个交叉编码器重排模型比如 BGE 的 reranker把候选和 query 拼一起过一遍模型打分精度能再提一截代价是延迟增加。4.5 接入大模型生成答案最后把召回的内容拼进 prompt交给大模型。def build_prompt(query, contexts): ctx \n\n---\n\n.join(contexts) return f基于以下资料回答问题资料中没有的信息不要编造。 资料 {ctx} 问题{query} 回答这个 prompt 里最关键的一句是资料中没有的信息不要编造。RAG 最常见的失败模式就是模型在召回内容不足时开始自由发挥加这句能显著降低幻觉率。更严格的做法是要求模型在答案里标注引用来源方便溯源。5. 常见问题与排查技巧实录5.1 召回不准的排查顺序召回不准是最常见的问题排查要有顺序别乱试。我一般按这个顺序走先看分块再看嵌入再看检索策略最后看 query 本身。分块问题表现为召回的内容总是缺头少尾或者一块里混了多个主题。解决办法是调整chunk_size和separators或者改用语义分块。嵌入问题表现为语义相近的内容召不回换个说法就找不到。这时候要检查嵌入模型是否适合你的语言和领域必要时换模型或做微调。检索策略问题表现为精确匹配的词召不回或者召回一堆不相关的。这时候调混合检索的权重或者加元数据过滤。query 问题最容易被忽略用户提问太短、太口语、有错别字都会影响召回。可以考虑加一层 query 改写把用户问题扩写成更适合检索的形式。5.2 常见问题速查表现象可能原因排查方向召回内容与问题无关分块过大噪声多减小 chunk_size优化分隔符专有名词召不回稠密嵌入对精确匹配弱提高稀疏检索权重加关键词过滤同义改写召不回稀疏检索对语义弱提高稠密检索权重换嵌入模型答案编造不存在的信息召回不足模型自由发挥加 prompt 约束提高召回数量检索延迟高索引参数过大或候选过多调小 efSearch减少 top_k增量更新后检索异常索引未同步更新检查增量写入逻辑重建索引5.3 几个文档里不会写的避坑经验第一个坑别用同一套参数处理所有类型的文档。产品手册、合同、FAQ、代码文档它们的理想分块大小和检索策略都不一样。我现在的做法是按文档类型分组每组一套分块参数检索时按类型路由。这样虽然麻烦但效果比一刀切好太多。第二个坑元数据过滤能救命。给每块加上来源、时间、部门、文档类型这些元数据检索时先按元数据过滤再算相似度能大幅减少不相关召回。比如用户问今年的政策你直接按时间过滤掉去年的文档召回质量立刻上一个台阶。第三个坑定期评估别凭感觉。RAG 效果会随着知识库增长而漂移。我建议建一个几十到上百条的评测集每条包含问题和标准答案每次改动后跑一遍看召回率和答案准确率的变化。没有评测集你根本不知道改动是变好还是变坏。提示评测集不用一开始就很大20 条真实问题就能发现大部分明显问题。关键是持续维护把线上发现的 bad case 补进去让它越来越贴近真实使用场景。6. 从基础 RAG 到 Agentic RAG 的演进方向基础 RAG 跑通之后你会发现它有几个天花板只能单轮检索、不会判断该不该检索、不会多步推理。这就是Agentic RAG要解决的问题——让 Agent 自己决定什么时候检索、检索什么、检索几轮、结果够不够。比如用户问一个需要跨多个文档综合的问题基础 RAG 一次召回可能只拿到部分信息而 Agentic RAG 可以先检索、评估结果、发现不足再补检索直到信息足够才生成答案。再往深走还有GraphRAG和Ontology RAG这类把知识图谱和 RAG 结合的方向。它们解决的是知识割裂问题基础 RAG 把文档切成独立的块块与块之间的关系丢了而图谱能把实体和关系显式建模出来让检索能沿着关系走。这些方向门槛更高但对付复杂领域知识效果更好。我的建议是先把基础 RAG 的每个环节调扎实再考虑上 Agentic 或 Graph。基础没打好就上高级架构只会把问题藏得更深。知识获取管道这条链路每一环都值得你花时间打磨因为它决定了你的 Agent 到底是在基于事实回答还是在一本正经地猜。
1. 为什么知识获取管道是 AI Agent 落地的第一道坎做 AI Agent 的人迟早会撞上同一堵墙模型本身很聪明但你问它公司上个月的报销政策、某个客户的合同条款、你们内部那套跑了八年的 ERP 字段含义它要么一本正经地胡说要么干脆告诉你我没有这方面的信息。这不是模型不行而是它的知识边界停在了训练数据截止的那一天。知识获取管道要解决的就是把这个边界往后推、往深挖让 Agent 在推理时能拿到外部真实、最新、私有的知识。在整条 Agent 链路里知识获取管道的位置非常靠前。你可以把 Agent 想象成一个刚入职的高材生脑子好使但对你公司的业务一无所知。RAGRetrieval-Augmented Generation检索增强生成就是给他配的那套资料室 检索员系统——他不需要把所有资料背进脑子只需要在回答问题时能快速从资料室里翻出最相关的几页然后基于这几页组织答案。这个类比里资料室是知识库检索员是检索器翻出最相关的几页就是稠密嵌入和稀疏嵌入在背后干的活。我见过太多团队在 Agent 项目上翻车不是因为模型选错了而是因为知识管道没搭好。检索召回率上不去后面接再强的模型也是垃圾进垃圾出。所以这一篇我不打算讲虚的直接把 RAG 基础里最核心的几个环节拆开文档怎么切、向量怎么算、稠密和稀疏怎么配合、检索结果怎么重排、以及那些文档里不会写但实际会踩的坑。适合正在从 0 到 1 搭建 AI Agent 的开发者也适合已经用了 RAG 但效果不理想的同学对照排查。2. RAG 基础架构的整体设计与选型思路2.1 一条完整的知识获取管道长什么样很多人对 RAG 的理解停留在把文档塞进向量库然后相似度检索这一步。这只是管道的一小段。一条能上生产的知识获取管道至少包含五个环节文档解析与清洗、分块Chunking、嵌入Embedding、索引与存储、检索与重排。每个环节都会影响最终的召回质量而且它们之间是乘法关系——任何一环拉胯整体效果都会断崖式下跌。我习惯把这五个环节画成一条流水线来理解。原始文档进来先做解析把 PDF、Word、HTML、数据库记录统一成纯文本然后按语义或固定长度切块每块单独算向量向量连同原文、元数据一起写进向量库用户提问时问题也走一遍嵌入去库里做相似度匹配召回 Top-K 候选最后用重排模型对候选精排把最相关的几块喂给大模型生成答案。这条链路里分块策略和检索策略是两个最容易被低估、也最影响效果的环节。为什么强调管道这个词因为它意味着数据是流动的、可迭代的。你今天切的分块策略明天发现召回不行得能快速重切、重建索引而不是推倒重来。所以架构设计之初就要考虑分块参数是否可配置、嵌入模型是否可替换、索引是否支持增量更新。这些决定了你后续调优的成本。2.2 稠密嵌入与稀疏嵌入为什么两个都要这是 RAG 基础里最值得讲清楚的一对概念。稠密嵌入Dense Embedding把一段文本映射成一个几百到几千维的稠密向量每一维都是浮点数语义相近的文本在向量空间里距离近。它的强项是语义匹配——你问怎么报销差旅费它能召回写着出差费用申请流程的文档哪怕字面一个词都不重合。稀疏嵌入Sparse Embedding则是高维稀疏向量绝大多数维度是零只有出现过的词对应的维度有值典型代表就是 BM25 这类基于词频的算法。它的强项是精确匹配——你搜一个产品型号XR-2000A它能精准命中而稠密嵌入很可能把这个型号和XR-2000B混为一谈。只用一个行不行实测下来单用稠密嵌入遇到专有名词、型号、代码、人名这类需要精确匹配的场景召回经常掉链子单用稀疏嵌入遇到同义改写、口语化提问又完全抓瞎。所以现在主流的做法是混合检索Hybrid Retrieval两路并行召回再用融合算法比如 RRFReciprocal Rank Fusion把结果合并。RRF 的逻辑很简单不看绝对分数只看排名把两路结果里排名靠前的文档加权求和避免了两路分数尺度不一致的问题。提示混合检索不是银弹。如果你的知识库全是自然语言叙述类文档稠密嵌入单独用可能就够了如果全是结构化字段、型号、编号稀疏嵌入的权重应该调高。别盲目上混合先搞清楚你的数据长什么样。2.3 分块策略切得好比嵌入模型选得好更重要我个人的经验是分块策略对召回效果的影响往往比换一个更贵的嵌入模型还大。原因很简单嵌入模型再强它也只能对你给它的那块文本负责。如果一块文本里混了三个不相关的主题算出来的向量就是个四不像检索时哪个主题都匹配不准。常见的分块方式有三种。固定长度分块最简单按字符数或 token 数切比如每 512 个 token 一块块之间留 50 token 重叠。优点是实现快、块大小均匀缺点是经常在句子中间切断语义不完整。语义分块按段落、标题、句子边界切尽量保证每块是一个完整语义单元。递归分块是前两者的折中先按大分隔符段落切太大再按小分隔符句子切直到满足大小限制。LangChain 的RecursiveCharacterTextSplitter就是典型实现。块大小怎么定没有万能值但有个经验区间中文场景 300 到 800 字英文场景 256 到 1024 token。块太小上下文不足模型拿到碎片拼不出完整答案块太大噪声多检索精度下降。重叠部分建议是块大小的 10% 到 20%防止关键信息正好卡在切割边界上被劈成两半。3. 核心环节的实操要点与参数细节3.1 文档解析脏数据是召回率的第一杀手真实项目里文档解析花的时间经常比调模型还多。PDF 里的表格、扫描件里的文字、Word 里的批注、HTML 里的导航栏全是噪声。我踩过最深的坑是一个客户的知识库PDF 用双栏排版解析出来文字顺序全乱两栏内容交错在一起检索出来的东西驴唇不对马嘴。处理原则是能拿到结构化源就别用解析。如果知识来自数据库直接查字段如果来自 Confluence、Notion 这类有 API 的平台走 API 拿干净的 Markdown只有实在没有源文件时才上 PDF 解析。PDF 解析工具里PyMuPDF对文本型 PDF 效果好扫描件得先走 OCR。表格建议单独抽出来转成 Markdown 或 JSON别混在正文里。清洗环节要做的事包括去掉页眉页脚、合并被硬换行拆断的句子、统一全半角、去掉多余空白。这些看着琐碎但每一条都直接影响后续分块和嵌入的质量。我一般会写一个清洗函数把常见噪声用正则批量处理处理完抽样人工看几十条确认没有明显问题再往下走。3.2 嵌入模型选型别只看排行榜嵌入模型的选择要看三个维度语言支持、维度、以及是否支持本地部署。中文场景优先选对中文优化过的模型很多英文榜单第一的模型在中文上表现平平。维度方面768 维和 1024 维是常见选择维度越高表达能力越强但存储和计算成本也越高。一个百万级文档的知识库1024 维向量用 float32 存储光向量就占 4GB 左右这个账要提前算。本地部署还是调 API涉及私有数据、合规要求高的场景本地部署是刚需。开源嵌入模型里BGE 系列、M3E 系列在中文检索任务上表现稳定社区验证充分。调 API 的好处是省事、模型更新快但数据要出域成本和延迟也要考虑。我的建议是先用 API 快速验证流程跑通效果达标后再评估是否迁移到本地别一上来就纠结部署方式把流程跑通才是第一优先级。注意嵌入模型一旦选定整个知识库的向量都得用它来算。中途换模型意味着全量重建索引。所以选型时多花点时间做对比测试用你自己的真实数据测召回别信通用榜单。3.3 向量库与索引HNSW 参数怎么调向量库选型上小规模十万级以下用 FAISS 或 Chroma 就够部署简单中大规模百万级以上考虑 Milvus、Qdrant、Weaviate 这类专业向量库支持分布式和更丰富的索引类型。选型的核心考量是数据规模、是否需要增量更新、是否需要元数据过滤、运维成本。索引类型里**HNSWHierarchical Navigable Small World**是目前最常用的近似最近邻索引。它有两个关键参数M和efConstruction。M是每个节点的连接数越大图越密召回越高但内存占用越大常用值 16 到 64efConstruction是建索引时的搜索宽度越大索引质量越高但建得越慢常用值 100 到 200。查询时还有个efSearch参数越大召回越高但查询越慢需要在召回和延迟之间权衡。我一般这样调先用默认值M16efConstruction200建索引测召回率和延迟如果召回不够先加efSearch因为它只影响查询不影响索引还不够再考虑重建索引调大M。这个顺序能让你用最小成本找到合适的参数组合。4. 完整实操流程从零搭一条可用的 RAG 管道4.1 环境准备与依赖安装先把基础环境搭起来。Python 3.10 以上核心依赖包括文档解析、分块、嵌入、向量库四类。下面是一套我常用的组合你可以按需替换。pip install pymupdf langchain langchain-community pip install sentence-transformers faiss-cpu pip install rank-bm25 jiebasentence-transformers用来加载本地嵌入模型faiss-cpu是向量库rank-bm25加jieba用来做中文稀疏检索。如果你的数据量大或者要上生产把faiss-cpu换成faiss-gpu或者专业向量库的客户端。4.2 文档解析与分块实现假设我们有一批 PDF 文档先解析再分块。这里用递归分块中文按标点和段落切。import fitz from langchain.text_splitter import RecursiveCharacterTextSplitter def parse_pdf(path): doc fitz.open(path) text for page in doc: text page.get_text() return text def clean_text(text): import re text re.sub(r\n{3,}, \n\n, text) text re.sub(r[ \t]{2,}, , text) return text.strip() splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , , , ] ) raw parse_pdf(handbook.pdf) cleaned clean_text(raw) chunks splitter.split_text(cleaned) print(f共切出 {len(chunks)} 块)chunk_size500是字符数中文场景这个值比较稳。chunk_overlap80是 16% 的重叠防止边界信息丢失。separators列表的顺序很重要它会优先按段落切段落太大再按句子切最后才按字符切这样能最大程度保证语义完整。4.3 稠密与稀疏双路索引构建接下来算嵌入、建索引。稠密用本地模型稀疏用 BM25。from sentence_transformers import SentenceTransformer import faiss import numpy as np from rank_bm25 import BM25Okapi import jieba model SentenceTransformer(BAAI/bge-base-zh-v1.5) # 稠密索引 embeddings model.encode(chunks, normalize_embeddingsTrue) dim embeddings.shape[1] index faiss.IndexFlatIP(dim) index.add(np.array(embeddings).astype(float32)) # 稀疏索引 tokenized [list(jieba.cut(c)) for c in chunks] bm25 BM25Okapi(tokenized)这里用IndexFlatIP做精确内积检索数据量小的时候够用。normalize_embeddingsTrue把向量归一化后内积等价于余弦相似度这是标准做法。BM25 那边用 jieba 分词中文必须分词否则按字切效果很差。4.4 混合检索与重排检索时两路并行用 RRF 融合。def hybrid_search(query, top_k5, k60): # 稠密召回 q_emb model.encode([query], normalize_embeddingsTrue) _, dense_ids index.search(np.array(q_emb).astype(float32), top_k * 2) dense_ids dense_ids[0].tolist() # 稀疏召回 q_tokens list(jieba.cut(query)) scores bm25.get_scores(q_tokens) sparse_ids np.argsort(scores)[::-1][:top_k * 2].tolist() # RRF 融合 rrf {} for rank, doc_id in enumerate(dense_ids): rrf[doc_id] rrf.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(sparse_ids): rrf[doc_id] rrf.get(doc_id, 0) 1 / (k rank 1) ranked sorted(rrf.items(), keylambda x: x[1], reverseTrue) return [chunks[i] for i, _ in ranked[:top_k]]k60是 RRF 的标准平滑参数来自原论文一般不用改。两路各召回top_k * 2个候选融合后取前top_k给重排留了余量。如果对精度要求高可以在融合后再接一个交叉编码器重排模型比如 BGE 的 reranker把候选和 query 拼一起过一遍模型打分精度能再提一截代价是延迟增加。4.5 接入大模型生成答案最后把召回的内容拼进 prompt交给大模型。def build_prompt(query, contexts): ctx \n\n---\n\n.join(contexts) return f基于以下资料回答问题资料中没有的信息不要编造。 资料 {ctx} 问题{query} 回答这个 prompt 里最关键的一句是资料中没有的信息不要编造。RAG 最常见的失败模式就是模型在召回内容不足时开始自由发挥加这句能显著降低幻觉率。更严格的做法是要求模型在答案里标注引用来源方便溯源。5. 常见问题与排查技巧实录5.1 召回不准的排查顺序召回不准是最常见的问题排查要有顺序别乱试。我一般按这个顺序走先看分块再看嵌入再看检索策略最后看 query 本身。分块问题表现为召回的内容总是缺头少尾或者一块里混了多个主题。解决办法是调整chunk_size和separators或者改用语义分块。嵌入问题表现为语义相近的内容召不回换个说法就找不到。这时候要检查嵌入模型是否适合你的语言和领域必要时换模型或做微调。检索策略问题表现为精确匹配的词召不回或者召回一堆不相关的。这时候调混合检索的权重或者加元数据过滤。query 问题最容易被忽略用户提问太短、太口语、有错别字都会影响召回。可以考虑加一层 query 改写把用户问题扩写成更适合检索的形式。5.2 常见问题速查表现象可能原因排查方向召回内容与问题无关分块过大噪声多减小 chunk_size优化分隔符专有名词召不回稠密嵌入对精确匹配弱提高稀疏检索权重加关键词过滤同义改写召不回稀疏检索对语义弱提高稠密检索权重换嵌入模型答案编造不存在的信息召回不足模型自由发挥加 prompt 约束提高召回数量检索延迟高索引参数过大或候选过多调小 efSearch减少 top_k增量更新后检索异常索引未同步更新检查增量写入逻辑重建索引5.3 几个文档里不会写的避坑经验第一个坑别用同一套参数处理所有类型的文档。产品手册、合同、FAQ、代码文档它们的理想分块大小和检索策略都不一样。我现在的做法是按文档类型分组每组一套分块参数检索时按类型路由。这样虽然麻烦但效果比一刀切好太多。第二个坑元数据过滤能救命。给每块加上来源、时间、部门、文档类型这些元数据检索时先按元数据过滤再算相似度能大幅减少不相关召回。比如用户问今年的政策你直接按时间过滤掉去年的文档召回质量立刻上一个台阶。第三个坑定期评估别凭感觉。RAG 效果会随着知识库增长而漂移。我建议建一个几十到上百条的评测集每条包含问题和标准答案每次改动后跑一遍看召回率和答案准确率的变化。没有评测集你根本不知道改动是变好还是变坏。提示评测集不用一开始就很大20 条真实问题就能发现大部分明显问题。关键是持续维护把线上发现的 bad case 补进去让它越来越贴近真实使用场景。6. 从基础 RAG 到 Agentic RAG 的演进方向基础 RAG 跑通之后你会发现它有几个天花板只能单轮检索、不会判断该不该检索、不会多步推理。这就是Agentic RAG要解决的问题——让 Agent 自己决定什么时候检索、检索什么、检索几轮、结果够不够。比如用户问一个需要跨多个文档综合的问题基础 RAG 一次召回可能只拿到部分信息而 Agentic RAG 可以先检索、评估结果、发现不足再补检索直到信息足够才生成答案。再往深走还有GraphRAG和Ontology RAG这类把知识图谱和 RAG 结合的方向。它们解决的是知识割裂问题基础 RAG 把文档切成独立的块块与块之间的关系丢了而图谱能把实体和关系显式建模出来让检索能沿着关系走。这些方向门槛更高但对付复杂领域知识效果更好。我的建议是先把基础 RAG 的每个环节调扎实再考虑上 Agentic 或 Graph。基础没打好就上高级架构只会把问题藏得更深。知识获取管道这条链路每一环都值得你花时间打磨因为它决定了你的 Agent 到底是在基于事实回答还是在一本正经地猜。
