1. RAG 知识库构建的整体设计思路1.1 为什么需要 RAG大模型的三道硬伤直接拿大模型当知识库用我踩过的坑可以列一长串。最典型的三类问题一是知识截止模型训练数据有明确的时间边界你问它上个月刚发布的内部规范它要么答不上来要么一本正经地编二是幻觉模型在不确定的时候倾向于“顺着你的话往下编”尤其在专业领域编出来的内容看起来还挺像那么回事三是私有数据盲区公司内部的制度文档、产品手册、客户案例这些数据从来没进过训练集模型不可能知道。RAGRetrieval-Augmented Generation检索增强生成就是冲着这三个问题来的。它的核心思路很朴素不去改模型而是在模型回答之前先把相关资料找出来塞进上下文。模型拿到资料后再组织语言相当于开卷考试。这样既绕开了重新训练的成本又能让回答有据可查。我个人的判断是只要你的知识是动态更新的、私有的、或者需要引用溯源的RAG 就是当前性价比最高的方案。微调适合改变模型的“说话风格”和“任务格式”但要让模型记住一堆随时会变的业务事实微调既贵又不好维护RAG 才是正解。1.2 全链路的五个核心环节一条完整的 RAG 链路我习惯拆成五段来看每一段都有独立的优化空间环节核心任务常见坑点文档解析把 PDF/Word/HTML 转成纯文本表格错乱、页眉页脚混入、扫描件无文字层切块把长文本切成合适粒度的片段切太碎丢上下文切太大检索不准向量化把文本转成语义向量模型选型不当、中英文混排效果差检索根据问题召回相关片段纯向量召回漏关键词、Top-K 设置拍脑袋生成把召回内容拼进 Prompt 让 LLM 回答上下文超长、指令冲突、引用丢失这五段里切块和检索是最容易被低估的两个环节。很多人把精力全花在选模型上结果切块策略一塌糊涂再好的向量模型也救不回来。我的经验是解析和切块决定了 RAG 效果的天花板检索和生成只是逼近这个天花板。1.3 方案选型的几个关键取舍搭建 RAG 之前先想清楚几个问题能省掉后面大量返工。第一自建还是用现成平台。Dify、FastGPT 这类平台开箱即用流水线可视化适合快速验证。但一旦你要做深度定制——比如自定义切块逻辑、混合检索权重、多路召回融合——平台就会变成束缚。我的建议是验证阶段用平台跑通闭环生产阶段核心链路自己写把平台当参考实现而不是最终方案。第二向量库选哪个。数据量在百万级以下Chroma、FAISS 这类轻量方案完全够用本地跑零成本。上了千万级、需要分布式和高可用再考虑 Milvus、Qdrant 这类专业向量数据库。别一上来就上重型武器运维成本会吃掉你所有精力。第三Embedding 模型怎么选。中文场景我实测下来BGE 系列如 bge-large-zh、bge-m3综合表现稳定bge-m3 还支持多语言和长文本。如果追求更强的语义理解可以上 SigLIP2 这类多模态向量模型处理图文混合内容。选型时一定要用你自己的业务数据做召回测试榜单排名和实际效果经常对不上。2. 文档解析与切块的核心细节2.1 文档解析脏数据是万恶之源解析这一步很多人觉得“不就是读个文件吗”实际上它是整条链路里最脏最累的活。我处理过的文档类型包括 PDF、Word、Markdown、HTML、Excel、扫描件每一种都有自己的脾气。PDF 是最麻烦的。文字层 PDF 和扫描件 PDF 要分开处理前者用 pdfplumber、PyMuPDF 直接抽文字后者必须先走 OCR。即便是文字层 PDF双栏排版、表格、公式也会让抽取结果错乱。我的做法是先用 PyMuPDF 抽取同时保留每个文本块的坐标信息后续切块时可以根据坐标判断阅读顺序避免双栏文档被横向串读。表格处理是另一个重灾区。直接把表格转成纯文本行列关系全丢。我一般用 Camelot 或 pdfplumber 的表格抽取功能把表格转成 Markdown 格式保留结构再单独作为一个 chunk 存入。这样检索到表格时LLM 还能看懂行列对应关系。实操心得解析完一定要做一次“肉眼抽检”。随机抽 20 个文档把解析结果和原文对照重点看表格、列表、页眉页脚有没有混入。这一步花 10 分钟能帮你省掉后面几小时的排查。页眉页脚、页码、水印这些噪声我一般用规则过滤统计每个文本块在文档中的出现位置如果某个短文本在超过 80% 的页面同一位置反复出现基本就是页眉页脚直接剔除。2.2 切块策略粒度决定检索质量切块是 RAG 里最需要“手感”的环节。切得太碎一个完整的意思被拆散检索到的片段缺头少尾切得太大一个 chunk 里混了好几个主题向量被平均掉检索精度下降。我常用的几种切块策略按场景选择固定长度切块是最简单的按 token 数切比如每 512 token 一块块间重叠 50 token。重叠是为了防止句子被硬切断导致语义丢失。这种方式实现简单适合结构松散的文本但缺点是经常在句子中间断开。递归字符切块是 LangChain 的默认策略按分隔符优先级递归切分先按段落切段落还太大就按句子切句子还大就按字符切。这种方式能尽量保持语义单元的完整是我用得最多的默认方案。语义切块更高级用 Embedding 计算相邻句子的相似度在相似度骤降的地方切一刀。效果确实好但计算成本高适合对精度要求极高的场景。按文档结构切块是我最推荐的方式前提是你的文档有清晰结构。Markdown 按标题层级切每个二级标题下的内容作为一个 chunk技术文档按章节切FAQ 按问答对切。这种方式切出来的 chunk 语义最完整检索效果最好。具体参数上我的经验值是这样的文档类型chunk 大小重叠说明技术文档500-800 token80保留完整代码块和说明制度规范300-500 token50条款粒度便于精确定位长篇文章800-1000 token100保留论述完整性FAQ按问答对0天然语义单元无需切注意chunk 大小不是越小越好。我见过有人切成 128 token结果检索出来的片段全是半句话LLM 根本没法用。判断标准很简单把 chunk 单独拿出来读如果意思完整、能独立理解这个粒度就对了。2.3 元数据被忽视的检索利器切块的时候一定要给每个 chunk 打上元数据。这些元数据在检索阶段能发挥巨大作用但很多人完全忽略。我一般会存这几类元数据来源信息文件名、路径、页码、结构信息所属章节、标题层级、时间信息创建时间、更新时间、类型信息正文、表格、代码、注释。有了这些检索时就能做过滤比如只搜某个目录下的文档或者只搜最近半年更新的内容。更进阶的用法是给 chunk 加上下文摘要。具体做法是让 LLM 为每个 chunk 生成一句话的上下文说明比如“本段出自《XX制度》第三章讲的是报销流程中的审批权限”把这句话拼在 chunk 前面一起向量化。这样检索时即使问题没提到“报销”只要语义相关也能召回。这个技巧我在多个项目里验证过召回率提升明显。3. 向量化与检索的实操要点3.1 向量化模型选型与批量处理向量化就是把文本转成高维向量让语义相近的文本在向量空间里距离也相近。这一步的核心是选对 Embedding 模型。中文场景下我实测过的模型里bge-large-zh-v1.5是稳妥的选择768 维语义区分度好。bge-m3支持 8192 长文本和多语言适合中英混排的文档。如果要做图文混合检索SigLIP2 这类多模态模型能把图片和文本映射到同一向量空间适合产品手册、说明书这类含大量图表的场景。选型时有个关键点查询和文档必须用同一个模型向量化。我见过有人文档用 A 模型、查询用 B 模型结果检索效果惨不忍睹。向量空间都不一致距离计算毫无意义。批量处理的性能优化也很重要。向量化是计算密集型任务我一般这样处理from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 批量编码batch_size 根据显存调整 # 显存 8G 时 batch_size 设 3216G 可设 64 embeddings model.encode( texts, batch_size32, normalize_embeddingsTrue, # 归一化后可用内积算余弦相似度 show_progress_barTrue )normalize_embeddingsTrue这个参数很关键。归一化之后向量内积就等于余弦相似度检索时计算更快。另外BGE 系列模型在检索时查询前面要加指令前缀为这个句子生成表示以用于检索相关文章文档则不加。这个细节很多人不知道加上之后召回效果有可感知的提升。3.2 检索策略纯向量不够混合才稳纯向量检索有个天然短板对精确关键词不敏感。比如你搜“错误码 E5021”向量检索可能召回一堆语义相关但没提到这个码的文档。这时候就需要混合检索向量检索负责语义召回BM25 负责关键词召回两路结果融合。融合算法我常用 RRFReciprocal Rank Fusion倒数排名融合。它的思路很简单不看绝对分数只看排名把两路结果的排名做倒数加权求和。这样能避免不同检索器的分数尺度不一致问题。def rrf_fusion(vector_results, bm25_results, k60): RRF 融合两路检索结果 scores {} for rank, doc_id in enumerate(vector_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(bm25_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) # 按融合分数排序 return sorted(scores.items(), keylambda x: x[1], reverseTrue)k60是 RRF 论文里的经验值实际用下来 60 左右都稳定。融合之后取 Top-K一般 K 设 5-10 比较合适。K 太小容易漏K 太大噪声多还会撑爆 LLM 的上下文。3.3 重排序用精度换召回混合检索解决了“召回全不全”的问题但召回的结果里难免有噪声。这时候加一个重排序Rerank环节用更精细的模型对 Top-K 结果重新打分排序。Rerank 模型和 Embedding 模型不一样Embedding 是双塔结构查询和文档分别编码速度快但精度有限Rerank 是交叉编码器把查询和文档拼在一起过模型精度高但速度慢。所以典型流程是先用向量检索快速召回 Top-50再用 Rerank 精排出 Top-5 给 LLM。我用得比较多的是 bge-reranker 系列中文效果稳定。加上 Rerank 之后检索精度通常能提升 10-20 个百分点代价是增加几十到几百毫秒延迟。如果对延迟不敏感、对精度要求高Rerank 几乎是必选项。3.4 多轮对话下的检索设计单轮问答的检索好做多轮对话就麻烦了。用户第二句问“那它的审批流程呢”这个“它”指代什么如果直接拿这句话去检索肯定召回一堆不相关的内容。我的处理方式是查询改写把当前问题和历史对话一起丢给 LLM让它改写成独立完整的查询。比如上面那句会被改写成“XX 事项的审批流程是什么”。改写后的查询再去检索召回质量立刻不一样。另一个技巧是指代消解 关键词提取。改写的同时让 LLM 提取核心关键词用关键词走 BM25 那一路语义查询走向量那一路两路并行。这样既保留了上下文理解又抓住了精确匹配。实操心得多轮对话的检索历史轮次不要全带上一般保留最近 3-5 轮就够了。带太多历史改写出来的查询会被无关信息污染反而降低检索质量。4. 生成环节与常见问题排查4.1 Prompt 组装把召回内容用对检索到相关片段后怎么拼进 Prompt 直接决定了最终回答质量。我常用的模板结构是这样的你是一个严谨的知识库助手。请仅根据下面提供的参考资料回答问题。 如果参考资料中没有相关信息请明确说明“资料中未找到相关内容”不要编造。 参考资料 [1] {chunk_1} [2] {chunk_2} [3] {chunk_3} 用户问题{question} 回答要求 1. 回答必须基于参考资料不要引入外部知识 2. 引用具体资料时标注编号如 [1] 3. 如果资料之间有冲突指出冲突并说明这个模板里有几个关键设计明确约束“仅根据资料回答”能大幅降低幻觉要求标注引用编号方便溯源要求处理冲突避免模型强行融合矛盾信息。上下文长度要控制好。召回 5 个 chunk每个 500 token加上模板和问题总共 3000 token 左右主流模型都能轻松处理。如果召回内容太多导致超长宁可减少 chunk 数量也不要截断单个 chunk——截断的 chunk 语义不完整反而误导模型。4.2 常见问题速查表RAG 上线后问题会以各种意想不到的方式冒出来。我把踩过的坑整理成一张速查表现象可能原因排查方向答非所问检索没召回相关内容检查切块粒度、Embedding 模型、查询改写回答笼统召回内容太泛提高检索精度加 Rerank缩小 chunk编造内容Prompt 约束不够强化“仅根据资料回答”指令降低 temperature关键词搜不到纯向量检索短板加 BM25 混合检索多轮对话跑偏查询指代未消解加查询改写环节表格内容答错表格解析丢失结构表格单独处理转 Markdown 保留结构响应太慢检索链路太长加缓存Rerank 只对 Top-K 做4.3 效果评估别靠感觉要量化RAG 效果好不好不能靠“感觉还行”。我一般建一个小规模的评估集准备 50-100 个真实问题每个问题标注好标准答案和应该召回的文档片段。然后跑两个指标召回率RecallK标准片段有没有出现在 Top-K 里。这个指标反映检索能力低于 80% 就要优化切块和检索策略。答案准确率LLM 生成的答案和标准答案的语义相似度可以用另一个 LLM 来打分。这个指标反映端到端效果。评估集不用很大但一定要覆盖真实场景。我见过团队用公开数据集评估效果很好一上真实业务就崩因为公开数据的语言风格和业务数据差太远。用自己的数据建评估集是 RAG 调优最值得投入的一件事。4.4 安全与成本的两个提醒最后说两个容易被忽略的点。安全方面知识库里如果有敏感信息检索环节要做权限过滤。不同用户能访问的文档范围不一样检索时必须带上用户权限做元数据过滤否则会出现越权访问。另外Prompt 里不要暴露系统内部信息比如文件路径、数据库结构这些防止被诱导泄露。成本方面向量化是一次性成本检索是持续成本。如果查询量大Embedding 和 Rerank 的调用费用会累积。我的做法是加一层查询缓存相同或相似的查询直接返回缓存结果命中率在 FAQ 类场景能到 30% 以上。另外Rerank 只对 Top-K 做不要对全量召回结果做能省不少算力。这套链路我在几个项目里跑下来从文档解析到最终回答端到端延迟控制在 2 秒以内答案准确率比纯 LLM 提升了 40% 以上。核心经验就一句话RAG 的效果是系统工程每个环节都及格整体才及格任何一个环节拉胯整体就崩。把精力花在解析、切块、检索这三个地基上比反复换模型有用得多。