最近我在规划《RAG进阶实战》这个系列专栏起因其实很朴素团队过去半年里陆续上线了好几个RAG项目从设备日志问答到企业内部文档助手再到客服知识库都碰过一轮。Demo阶段人人都觉得“这不就是向量库加一个大模型嘛”可真到生产环境里检索召回率上不去、长文档上下文塞爆、改了个分块参数也不知道效果是变好还是变坏这些问题一个接一个冒出来。网上教程大多停在“怎么跑通一个最简单的RAG”很少讲清楚“为什么这样设计、遇到瓶颈怎么排查”。所以我想把这些经验整理成一个进阶性质的实战专栏这篇博客先聊聊策划案本身专栏怎么划分、每期讲什么、这样排背后的逻辑是什么。这个专栏不是给完全没接触过RAG的新手看的而是给那些已经跑通过简易RAG、却在实际落地时卡住的工程师和技术负责人。你可以把它理解成一份从“能用”走向“可控”的路线图先解决检索质量再处理上下文与生成然后是知识库形态的选择最后落到评估体系和智能体。每期除了概念讲解都会带一套可复跑的代码、一组参数基线以及效果对比方便你直接对着调整自己的项目。1. 做这个专栏的出发点RAG为什么值得追一个进阶系列1.1 看起来简单做起来难RAG的三座大山先坦白一个事实RAG入门真的不难。装个Chroma找一个开源向量模型写十几行代码把文档切块、向量化、入库然后接上大模型API提问一个最小可用的知识库问答系统就出来了。我见过很多团队在一天之内就能跑通这样的Demo但接下来就撞上三座大山。第一座是召回质量。你明明知道答案就在某份文档的第17页可检索系统就是把它排到了第30名以外。查询里带专业术语、产品编号、年份数字的时候纯向量检索经常翻车因为这些内容的语义相似度没有被很好地建模。第二座是上下文管理。把召回的Top 5文档一股脑塞给大模型问题是这五段里只有一段是有用的其余全是噪音模型被无关信息带偏给出的答案自然不靠谱。而且上下文窗口始终有限chunk太大太小都难受。第三座是评估。这是最容易被忽略的你换了一个Embedding模型、调了分块参数、加了重排序环节效果到底是变好了还是变坏了如果没有量化的评估集你只能靠肉眼抽样看几个问题然后陷入“感觉好像变好了”的幻觉里。这三座大山环环相扣任何一个环节出了问题最终答案都会跑偏。最坑的地方在于RAG链路是前后耦合的——检索问题会在生成阶段被放大生成问题又常常被误判为检索问题。这也是为什么我一直不建议用“单点优化”的思路去做RAG而是把它当系统工程来看待。1.2 给谁看、看完能带走什么策划这个专栏的时候我脑子里始终悬着一个问题什么样的内容对正在做RAG的人真正有用最终我把目标人群锁定在三类。第一类是已经跑通过简易RAG、想提升线上效果的开发者。他们不缺“怎么用LangChain搭一个Demo”的知识缺的是分块策略怎么选、混合检索怎么落地、Rerank怎么接这类具体方法。第二类是需要把企业知识库真正落地的工程师或技术负责人。他们的文档格式五花八门有PDF、有表格、有扫描件甚至还有图片需要考虑知识库形态怎么设计怎么跟现有系统集成。第三类是做Agent或复杂工作流的人他们需要理解RAG的检索能力边界知道什么时候单纯的知识问答不够、要升级成智能体。专栏的每个主题我都会给出三个层面的交付物可复跑的代码、一组参数基线、一份效果对比。所谓参数基线是指“我在这组配置下测出来的结果”比如分块大小512、重叠80、Top K取5、Rerank阈值设置多少你会有一个可以参照的起点而不是凭感觉瞎试。此外每一期都会有一段“避坑实录”把我实际踩过的坑直接写在里面。2. 专栏整体设计从热搜问题反推学习路径2.1 高频痛点与专栏期数的映射在做策划案之前我花了不少时间翻大家在各个社区提的高频问题。你会发现用户的真实痛点特别集中RAG知识库能不能存图片、RAG的瓶颈在哪、Ontology RAG和知识图谱怎么用、RAG和Wiki有什么区别、怎么在Mac上搭本地RAG、有没有本地的文本拆解工具。这些根本不是孤立的疑问它们其实指向了RAG知识体系的不同模块。我索性把这些高频问题直接映射成栏目让整个专栏像是从用户问题里“反推”出来的高频问题/关键词对应专栏内容为什么放在这个位置rag教程、rag实战第1期RAG链路全景与框架选型先摸清链路再谈优化本地文本拆解工具第2期分块策略与文本解析检索质量的基础rag瓶颈、rag评估第5期评估体系与调优方法有量化指标才能定位瓶颈rag知识库能存储图片嘛第4期多模态知识库知识形态决定检索策略ontology rag、kg知识库区分第4期知识图谱与RAG融合适合与向量库做对比理解langchain4j easy rag第1期框架选型不同技术栈的接入方案ollama 本地rag知识库第7期轻量本地化部署学完优化再学部署更容易理解取舍wiki和rag区分第4期知识形态澄清概念混淆的源头按照这个映射我最终排出了一个八期的专栏大纲RAG链路全景与框架选型LangChain、LlamaIndex、langchain4j easy rag等检索质量分块、Embedding与混合检索上下文工程窗口策略、压缩与Prompt设计知识库形态多模态、知识图谱与Wiki式内容组织评估体系指标设计、评估集构建与回归测试RAG智能体多跳检索、工具调用与迭代完善轻量本地化Mac/Ollama/离线部署方案生产落地监控、知识更新与运维这个顺序不是随意排的。我的基本思路是先解决“能不能找到”再解决“找到之后怎么用”然后是“用什么形态组织知识”接着是“怎么量化效果”最后才是“要不要升级成智能体”。每期内容都有依赖关系比如你连检索都做不好就急着上RAG智能体只会让错误的传播路径更长。2.2 框架与知识形态的统一理解专栏第一期会专门聊框架选型这里先给一个核心判断框架不是关键链路理解才是关键。Python生态里LangChain和LlamaIndex都用得比较多前者组件全但抽象层有点厚后者在文档解析和索引构建上更专注。如果你的团队以Java后端为主可以考虑langchain4j它有一个easy rag模式能把向量化、入库、检索这些东西封装成减少集成成本的组件。我自己在不同项目里都试过最大的感受是框架只是工具你要始终清楚自己处于RAG链路的哪一环数据在这个环节的输入输出是什么。知识形态的问题也会在第一期先埋个伏笔后面第四期单独展开。很多人把Wiki和RAG混为一谈实际上这俩根本不是同一层面的东西。Wiki是一种内容组织和写作方式讲究结构化的词条、链接和分类体系RAG是一种检索增强生成的架构模式解决的是“模型不知道最新/私有信息”的问题。一个Wiki站完全可以作为RAG的高质量语料来源但你不能说“用Wiki替代RAG”或者“RAG就是Wiki”。类似的还有知识图谱KG和向量库的区分向量库擅长语义相似检索知识图谱擅长实体关系推理它们不是替代关系而是互补关系。3. 单期内容怎么落地以“检索质量与分块策略”为例3.1 分块参数背后的逻辑以及为什么不能拍脑袋所有做RAG的人都会面临第一个决策文档怎么切别看这个问题听起来基础我见过太多项目因为分块策略没想清楚后面整个检索质量都不对劲。分块的核心矛盾在于块太小语义被切碎一个完整的知识点被拆到好几个chunk里块太大单个chunk里混入太多无关信息而且向量化的语义会变得模糊检索时还会消耗大量上下文窗口。我在专栏里会给一套比较实用的基准参数chunk_size在256到1024 token之间常用的是512chunk_overlap一般取10%到20%也就是80到100个token。这里说的token不是字符数中文场景下一个汉字可能对应一到两个token所以别拿字符数当标准。为什么要有overlap因为文本的语义边界往往不会恰好落在分块边界上重叠区域相当于给信息边界打了一层“缓冲垫”减少关键内容被拦腰切断的概率。用代码实现一个基础分块器很简单from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap80, separators[\n\n, \n, 。, , ], ) docs text_splitter.split_text(document_text) print(f切分得到 {len(docs)} 个文本块)注意separators的顺序这是有讲究的。它会优先按段落切段落太长再按句子切实在不行按标点硬切。这样做的好处是尽量保留语义完整的自然单位而不是机械地按固定长度截断。如果你的文档是Markdown或者HTML还可以先用结构解析按标题拆出章节再对过长的章节做二次分块这种“结构感知分块”比直接一刀切效果稳定得多。还有一个进阶方案值得在专栏中重点演示父子分块。具体做法是同时存两种粒度的chunk——小chunk用于检索大chunk用于生成。查询先匹配到精准的小块然后把包含这个小块的大块上下文喂给模型。这相当于兼顾了“检索精准”和“语义完整”两个目标代价是存储量和实现复杂度会上升。3.2 混合检索与重排序一次真实调优的参考实现纯向量检索的问题我在前面提了一句这里展开说说。向量Embedding擅长捕捉语义相似但面对精确匹配的场景反而容易翻车产品型号“A12-B34”和“A12-B35”在语义上几乎没有差别但你要找的是精确的那个人名、编号、年份、专业缩写这些“精确信号”恰恰是向量模型不敏感的。所以进阶RAG项目里混合检索几乎是标配。最朴素的混合检索就是BM25传统关键词检索与向量检索的分数融合。关键点有两个一是要先把两路分数归一化到同一量纲再做加权不然BM25的分数范围可能完全碾压向量距离二是权重需要根据数据特点调整代码库类文档可以适当提高关键词权重泛文档类则向量权重更高。from rank_bm25 import BM25Okapi import numpy as np # 假设 docs 是已经预处理的分块文本query_tokens 是查询的分词结果 bm25 BM25Okapi([doc.split() for doc in docs]) bm25_scores bm25.get_scores(query_tokens) # vector_scores 来自向量库检索比如余弦相似度需要先归一化 def normalize(scores): scores np.array(scores, dtypefloat) return (scores - scores.min()) / (scores.max() - scores.min() 1e-9) final_scores 0.6 * normalize(vector_scores) 0.4 * normalize(bm25_scores) top_indices np.argsort(final_scores)[::-1][:10]融合之后通常还会接一个重排序Rerank环节。做法是先扩大召回范围比如取Top 50然后用一个专门的Rerank模型对这50条重新打分再取前5到10条给大模型。Rerank模型跟Embedding模型的训练目标不同它更擅长判断“这段文本是否真正回答了问题”所以能显著改善排序质量。本地可跑的我推荐BGE系列的Rerank模型云端服务则可以用Cohere Rerank效果都挺稳。为了让大家有一个直观感受我把自己在内部文档集上的一组对比测试结果放进专栏方案答案命中率人工标注50题纯向量Top 566%BM25 向量融合Top 574%混合召回Top 50 Rerank取Top 584%这组数据只代表我的测试集情况但趋势很稳定混合检索带来的提升通常有10个百分点左右Rerank还能再往上加一截。这也是为什么我坚持把“检索质量优化”作为专栏的核心章节而不是简单讲完分块就带过。3.3 本地文本拆解工具怎么选热搜里有一条是“有没有本地的RAG文本拆解工具”这个需求非常实际。很多团队做知识库时文档都是保密的不可能传到云端服务去解析所以本地工具是刚需。我常用的方案有三个各自适用场景不一样。第一个是刚才代码里用到的langchain-text-splitters它轻量、无重依赖适合处理纯文本和结构比较简单的Markdown。第二个是LlamaIndex里的NodeParser它跟文档解析管线集成得更深能识别标题层级、段落关系适合有点结构的长文档。第三个是unstructured它对PDF、DOCX、表格的处理更暴力也更全面但安装时依赖比较多在Mac或Linux上偶尔会有系统库问题。特别提醒一下表格和PDF这两个坑。PDF转文本最怕的是文字流顺序错乱尤其是多栏排版和表格混合的文档按行提取出来的文本根本没法读。我的建议是表格优先转成Markdown格式或JSON结构再入库别直接塞原始PDF文本扫描件和手写批注不要指望普通分块器能解决先过OCR再说。注意不要迷信“按字数一刀切”这种省事做法。文本拆解的核心原则是先看文档结构再决定分块粒度结构清晰的文档优先按标题、段落、列表项切分只有在结构信息不可用时才退回到纯长度切分。4. 多模态、知识图谱和Mac本地化三块必须单独讲的内容4.1 RAG知识库能不能存图片多模态入库的三种做法“RAG知识库能存储图片吗”这个问题被问得特别多答案是可以但关键是怎么存、怎么让图片内容参与检索和生成。如果直接把图片文件丢进去指望模型读懂图片信息这条路目前并不通用大多数RAG系统处理的仍是文本。所以实践上要根据你的场景选策略我整理成一张对比表方案核心做法适合场景代价与注意点OCR提取文字用PaddleOCR或Tesseract把图片里的文字提取出来按文本块入库截图、扫描件、带文字的图表对纯图形语义无能为力表格结构会丢失多模态Embedding用CLIP、Chinese-CLIP或SigLIP把图片整体向量化支持图文互相检索以图搜图、产品图匹配、视觉相似查询对“图里的文字”不敏感结果可解释性一般生成图文描述用VLM比如Qwen-VL为图片生成详细描述文本再入库图片内容问答、需要让LLM“理解”图片描述质量直接决定召回质量耗时和成本偏高实操中我最常用的是“混合方案”先OCR把文字转成文本入库同时对图片本身做一次视觉向量化入库到一个单独的集合。查询时先判断用户意图是想找文字信息还是视觉相似再走对应的检索入口。这种方式兼顾了准确率和灵活性。还有个细节经常被忽略如果知识库里有大量表格截图最好的处理路径不是OCR识别成纯文本而是先用解析器把表格结构还原成Markdown或JSON再入库。OCR会把行列关系打平导致原始表格的对照关系全部丢失生成阶段自然答不对“第三列和第五列是什么关系”这类问题。4.2 知识图谱、Wiki与RAG从概念区分到Ontology RAG第四期内容里“知识形态”是主线我重点讲清楚三组概念向量库RAG、结构化知识图谱KG、Ontology RAG。先把向量RAG和KG做一个对照维度向量库 RAG知识图谱KG组织方式非结构化文本的向量表示实体、关系、属性的结构化图擅长查询语义相似、模糊搜索多跳关系推理、精确属性过滤维护成本增量入库较简单实体抽取、关系建模成本高典型短板缺乏逻辑推理难以回答关系类问题泛化能力弱无法覆盖非结构化语料你可以理解为向量库像一个“看过所有文档、但只是凭印象找内容”的助手知识图谱像一个“整理过每个人和事的关系网、能按关系推理”的数据库。真实业务里两者常常并存比如先用向量检索召回候选文档再从候选文档中抽取实体信息去图谱里查询关系最后把图谱结果和文档片段一起交给生成模型。Ontology RAG是这段时间比较受关注的方向。所谓本体Ontology就是提前定义好某一领域的概念、关系、约束规则。比如在法律场景里你可以定义合同、条款、当事人、签署日期这些概念以及它们之间的关系。检索时不直接在整个向量库里做语义相似搜索而是先通过本体限定“只能从合同条款类型的节点里找”再用图谱关系做路径过滤。这种约束能显著减少无关召回也降低生成时的幻觉概率。专栏里会给出一个三层结构示例实体链接层负责抽取问题中的关键实体图谱查询层根据本体做关系检索生成层最终把检索结果组织成答案。这不是要替代向量RAG而是给RAG加上“结构化约束”这个选项。4.3 在Mac上从零搭建本地RAG知识库“怎么在Mac上搭建RAG知识库”是热搜里的高频词也确实是个很有价值的实操主题尤其适合数据敏感、需要在离线环境验证方案的场景。我在专栏里安排了一期专门讲轻量本地化这里提前把主干步骤梳理出来。我推荐的组合是Ollama跑本地大模型Chroma做向量库Embedding用本地的BGE小模型或Ollama自带的nomic-embed-text。整个链路在Apple Silicon芯片的Mac上跑得很流畅M系列芯片可以直接走Metal加速。第一步是装Ollama并拉取模型brew install ollama ollama pull qwen2.5:7b # 或者 llama3.1:8b ollama pull nomic-embed-text # 本地embedding模型第二步建一个干净的Python虚拟环境装上必要的依赖python3 -m venv .venv source .venv/bin/activate pip install chromadb langchain langchain-text-splitters第三步就是前面讲过的文档分块和入库。入库时记得把文档来源、章节信息写进metadata后续过滤会非常有用from chromadb import PersistentClient client PersistentClient(path./chroma_data) collection client.get_or_create_collection( enterprise_docs, metadata{hnsw:space: cosine} ) collection.add( ids[chunk-001, chunk-002], embeddings[[...], [...]], # 来自本地embedding模型 documents[分块文本1, 分块文本2], metadatas[{source: product_manual.md, page: 3}, ...] )检索时先从Chroma拿候选再用Ollama的API组织提示词请求本地模型生成答案。整个过程不经过任何外部服务数据全程留在本机。关于Mac本地部署有三点要提醒第一内存是关键瓶颈7B模型配上8B参数在16GB内存的机器上勉强能跑但建议用Q4量化版本速度会快很多第二本地模型能力上限比云端大模型弱指望它处理复杂推理不现实更适合知识库问答这类“依据检索内容作答”的场景第三Embedding模型一定要本地化中文场景建议优先测试bge-small-zh-v1.5这类中文优化模型通用英文模型的中文检索效果会差一截。5. 避坑实录从高频故障到RAG瓶颈的排查思路5.1 高频问题速查表专栏第五期之前我会先放一张高频问题速查表把团队在多个项目里遇到过的典型故障整理出来。这里先剧透一部分现象可能根因排查方向与解法明明有答案却检索不到分块切碎了语义向量模型与查询语言不匹配调大chunk/overlap换中文Embedding加BM25关键词通道答案与检索内容无关提示词没有约束模型必须依据上下文在系统提示词中明确“仅依据给定材料作答禁止自行发挥”召唤到的内容里噪音太多Top K过大、Rerank阈值过低先扩大召回再压缩TopK引入父块或上下文压缩生成的答案出现幻觉检索结果缺失或覆盖不全加入“不知道就说不知道”指令用评估集测覆盖率响应太慢Embedding模型太大、向量库参数不当、模型未量化换小模型/量化检查HNSW的M与ef_search参数考虑缓存不同版本效果时好时坏没有固定评估集和基线建50条问题的评估集每次改动跑一遍做对比这张表在专栏里会配上完整的排查步骤和修复前后的对比数据。5.2 RAG的三大瓶颈怎么破热搜词里直接出现了“rag瓶颈”说明这是所有实践者都会遇到的共性问题。我把RAG的瓶颈归纳为三个层次并给出应对策略。第一是召回瓶颈。多数RAG项目的效果问题九成出在召回阶段而不是生成阶段。检索系统根本没把正确答案排上来后面所有优化都是白费。应对思路是混合检索加Rerank同时善用元数据过滤把“从所有文档里找”变成“从这个类别的文档里找”。第二是上下文瓶颈。就算召回了相关内容怎么把这些内容组织成上下文也是门学问。一股脑塞Top 5经常让模型“眼花缭乱”正确做法是先Rerank裁剪出最相关的片段然后按相关性排序组织上下文必要时对过长段落做摘要压缩。上下文窗口不是越大越好越相关的信息应该放在越靠前的位置。第三是评估瓶颈。没有量化评估就没有迭代基础。这个问题的解法我放在第七章详细讲核心思路是建一个覆盖正常问题、边界问题、反例问题的评估集每次改动跑同样的题看分数变化。有了这套机制你才敢大胆做实验而不是靠感觉调参。5.3 两个很容易被忽略的细节元数据与更新策略最后分享两个容易被忽略的细节都是实际项目中踩过坑才悟出来的。第一个是元数据过滤。很多人的知识库就是把所有文档切成块然后平铺入库检索时在全库范围找相似。但如果你的知识库里有多个来源、多类文档比如既有操作手册又有销售话术检索时就非常容易把不相关的文档类型捞上来。解决办法是入库时给每个chunk打上source、doc_type、date、author这类标签查询时先按条件过滤再检索。比如用户问“这台设备的故障代码怎么处理”你可以在检索前就限定doc_type operation_manual效果立竿见影。第二个是知识更新策略。很多团队一开始做知识库更新就是“全删全建”把所有文档重新切分、重新向量化、重新入库。这个做法在小规模场景下可以文档一多就非常浪费而且会让已积累的用户反馈和评估数据失效。更好的做法是增量式更新按文档粒度维护版本状态新增文档增量入库修改文档时只更新对应的chunk删除文档时同步清理它的向量和metadata。过期内容还要有定期清理机制避免知识库里堆满失效信息把检索结果带偏。6. 评估与智能体把RAG推到能上线、能自治的状态6.1 用评估集代替“我肉眼感觉变好了”前面反复提到评估这里必须把它具体化。RAG评估要分成两个层面检索层面和生成层面。检索层面常用的指标有RecallK、MRR、NDCG衡量的是正确答案有没有进入候选列表、排位靠不靠前。生成层面则更关注Faithfulness答案是否严格基于检索到的上下文和Answer Relevance答案是否对应用户的问题。前者防幻觉后者防答非所问。评估集的建设不需要一开始就搞得很庞大。我的经验是先挑50到100条问题覆盖三类正常问题答案就在文档里清晰明确、边界问题需要多段信息组合或涉及模糊表达、反例问题知识库里根本没有答案模型应该回答“不知道”。有了这个测试集每次改动后跑一遍把分数记录下来就能清楚地看到分块参数、检索策略或提示词的改动到底带来了什么影响。评估打分可以人工标注也可以用LLM-as-judge的方式让一个独立模型按评分标准给答案打分。注意评委模型的提示词要先定义清楚评分维度比如“答案是否忠于参考材料”“是否包含额外臆测”“是否直接回应了问题”。实测经验是评委模型对边界情况的判断不够稳定所以它只能帮你筛出高分和低分中间地带的样本还是要人工看。6.2 从单轮问答走向RAG智能体专栏的第六、第八期会聊RAG智能体这是许多团队在基础RAG稳定后自然想走的方向。所谓RAG智能体就是不再满足于“一次检索、一次生成”的单轮模式而是把RAG嵌入到一个可迭代、可决策的Agent流程里。典型能力包括问题拆解把复杂问题拆成子问题、多路检索同时查不同的索引或数据源、工具调用检索之外还能查数据库、调API、自省重试对生成结果不满意时重新检索补充信息。实现上可以用LangGraph、ReAct框架或Function Calling。但我在策划案里特别强调一个原则先把单轮RAG调稳定再升级成智能体。原因很简单Agent引入了额外的不确定性——模型自行决定下一步动作、自行判断是否重试这些行为如果缺乏约束线上效果会比单轮RAG更难控。所以进阶实践至少要设计三样护栏最da循环次数写死、系统提示词明确边界什么情况下可以调用工具、什么情况下必须终止、完整记录每次检索和决策的日志方便复盘。从我自己的项目经验看单轮RAG做到检索命中率85%以上、生成忠实度稳定的情况下再上Agent后续的收益会非常明显。反过来基础检索一塌糊涂就急着上Agent只会让错误被放大排查起来还特别痛苦。6.3 最后一点个人体会策划这个《RAG进阶实战》专栏的过程其实也是我把自己过去踩过的坑重新梳理了一遍。最大的体会是不要把RAG当成一个单纯的模型问题它是一个系统工程问题。从文档解析、分块策略、向量化、混合检索、上下文组织到评估迭代每一环都可能成为瓶颈而大多数“效果不行”的项目问题根本不在最后生成答案的那个大模型上。如果让我给正在做RAG的同学一句建议那就是先把评估集建起来再谈架构升级。哪怕只准备了30条有代表性的问题也能帮你在后续每次改动时有一个客观的“仪表盘”。查得到、找得准、答得稳这三个阶段挨个做到了你的知识库项目自然就从“能用”走向了“可控”。后续我也会按照这个框架把每一期的具体内容逐渐补齐分块调优的完整实验记录、混合检索的工程模板、多模态知识库的实现细节、Mac本地部署的分步脚本以及评估集的构建方法论。这些内容展开来都足够单独成篇到时候再逐期分享给大家。