现在说RAG烂大街我猜没人反对。随便一个懂点大模型的朋友都能用LangChain、LlamaIndex或者Dify在半小时内搭出一条RAG流水线加载文档、切成chunk、灌进向量库、接上LLM跑起来就能对着PDF问答。问题在于这套demo级的流水线放到真实业务里往往被吊打。我见过太多团队抱怨“RAG效果不行”但聊下来发现他们用的就是那条公开模板流水线缺的不是模型能力而是后面六个环节的精细度。换句话说从“能跑”到“能用”真正的分水岭根本不在框架选型而在六个容易被忽略的细节环节上。这篇文章挨个拆开讲每个环节都会说清楚原理、实操要点和踩坑经验希望能帮你少走几个月的弯路。1. 文档解析与清洗被严重低估的第一道分水岭很多人以为RAG第一步就是“导入文档”直接把PDF、Word往框架里一丢Embedding模型一跑就完事。这是最大的错觉。真实业务里的文档千奇百怪解析质量直接决定了后续切分和召回的上限。解析这一步做得烂后面所有环节都白搭。1.1 文本型PDF和扫描件是两个世界先把PDF分成两类文本型PDF和扫描型PDF。文本型PDF里每个字符是真实可选的文本对象用PyPDF2、pdfplumber这类工具可以直接提取扫描件本质上是一张张图片必须走OCR才能拿到文字。如果项目里混入了扫描件却没用OCR那结果是提取出来一堆空字符串召回率直接归零。我建议项目启动第一天就把文档来源摸清楚按类型建个清单哪些是导出型PDF哪些是扫描件哪些是Word/Excel导出的哪些是网页转存的。扫描件用量小就手工跑一遍OCR量大就做一个自动判定的预处理管道。判断“是否扫描件”有个很实用的笨办法统计提取出的有效字符数如果某页文本长度低于阈值大概率是图片页。OCR选型上中文场景我先后试过Tesseract和PaddleOCR实测PaddleOCR的中文识别率明显更高尤其是带表格的扫描件。注意OCR完成之后还要做一遍字符清洗常见的OCR错字比如“0”和“O”不分、“1”和“l”混淆如果后续要按编号检索这类错误会直接破坏召回。清洗规则不必很复杂一个定时扫描的监督脚本就能处理大部分问题。1.2 表格、多栏版式最常见的翻车点第二个高频翻车点是版面分析。很多金融、法律领域的PDF是双栏排版如果直接按文本流提取左右两栏的内容会被交错拼接形成完全不可读的乱序文本。一个常见现象是用户问“第三条的内容是什么”回答却把第二条和第四条的内容搅在一起。这就是版面分析没做的后果。我的做法是文本型PDF先走layoutparser或PyMuPDF自带的版面检测识别出标题栏、正文栏、表格区域再按阅读顺序重排。表格不能跟普通段落一样切割我试过用OpenCV画框和深度学习表格结构识别工具两种方案后者对复杂表头处理更稳。识别完表格之后建议把它转换为“表格名 表头行 行记录”这种带上下文的描述文本而不是保留Markdown表格格式。因为向量检索是按语义找答案Markdown的竖线符号对Embedding模型来说是噪音反而干扰相似度计算。提示解析清洗之后务必做一轮抽样人工验收。我每次都会随机抽10页查看提取结果确认没有错乱、乱码、缺漏再进入下一步。这一步多花一小时后面能省一整天。2. 切分策略隐藏的胜负手文档解析出来是完整的长文本直接全部塞给Embedding模型既不现实检索效果也差。这一步要把长文本切成有意义的片段也就是chunk。很多人按固定字数一刀切结果把完整的段落、句子甚至表格从中间劈开导致检索到的片段上下文不完整回答自然就歪了。切分策略直接决定了能召回什么粒度的信息是整个RAG管线里用户感知最明显的一个环节。2.1 固定窗口切分 vs 语义切分固定窗口切分是最简单的方案按token数每200或者400切一段再设置几十token的重叠。它的优点是实现简单、对任何文本都通用缺点是会切断句子和段落尤其不适合中文。中文不像英文以词为单位固定窗口很容易把一个完整语义的复句拦腰截断模型拿到的片段往往“读了后面忘了前面”。语义切分是按文档结构来切比如按标题、章节、段落边界作为切分点。效果比固定窗口好得多因为它保留了完整的语义单元。实际操作时可以用LangChain的MarkdownHeaderTextSplitter、RecursiveCharacterTextSplitter这类工具把标题层级作为天然的切分边界。还有一种更进阶的做法是根据embedding之间的余弦相似度做动态切分计算相邻句子的相似度当相似度低于阈值时认为话题切换在这里断开。这种方式对杂志、论文这种结构散乱的文档比较有效但计算量稍大我一般只在文档结构不明显的场景才用。2.2 父子chunk与滑动窗口的实战取舍在真实项目里经常遇到这样的矛盾检索阶段希望chunk小一点命中更精准比如只切到表格行或段落级搜索“合同编号”能精确命中但生成阶段交给大模型的上下文不能太碎只有表格一行信息是无法推理出完整条款的。这个时候就要用父子chunk结构小段负责检索大段负责生成。具体实现是将原文先切成大块父每块再细分成小块子。检索时通过子chunk的向量找到内容命中后用映射关系找到所属的父chunk把它作为上下文交给LLM。我在LangChain里踩过这个坑它默认的返回值是命中的那个小chunk本身如果不做父子映射模型拿到的是残缺信息。正确做法是在元数据里存父chunk的id命中子chunk后根据id回溯父chunk再拼接上下文。滑动窗口则是另一种思路它按固定步长滑动切割每个chunk之间保留部分重叠上下文相当于让模型能看到“上一段尾巴”适合纯文本流文档但与语义切分相比粒度更粗不太适合结构型文档。2.3 chunk size选型的经验值关于chunk size我直接给一组经验参考普通问答场景中文文本推荐200到300个token英文可以放到300到400个token如果文档是小说明、规章制度那样以短句为主的内容建议100到200个token如果文档是长篇幅逻辑推理内容可以放宽到500甚至800个token但检索精度会有所下降。为什么不直接给一个固定值因为不同文档的“语义密度”不一样。同样500个字一个场景是产品说明书每50个字就包含一个操作命令另一个场景是学术论文引言500字可能只讲了一个大背景。所以适合的chunk size必须通过小批量测试确定方法是在一套有标注的评测集上跑不同size对比命中率和回答质量。我见过大部分团队把chunk size当成固定参数一劳永逸不改这是明显的盲区。建议至少拿20条代表性query做AB对比再定初始值后续每遇到一类新文档要重新验证。3. 召回环节向量之外还差一个重排流水线做得再漂亮如果召回的文档压根不相关生成端再聪明也答不对。所以说召回是RAG的命门丝毫不过分。很多入门项目只做一个步骤把用户query转成向量去向量库做余弦相似度topN。感受过真实数据之后你会发现这条路单独走不稳向量检索擅长找语义相近的内容却不擅长处理专有名词、编号和低频词比如用户问“TPM2.0协议”纯向量可能召回一堆关于“安全芯片”的泛泛文档却没有精确命中那篇标题只有“TPM2.0”的规范。3.1 为什么纯向量检索容易“漏人”先说清楚原理。主流Embedding模型本质上是把文本映射到语义空间中的向量它捕捉的是整体语义倾向很难区分细粒度的实体。比如“合同编号A-20240001”和“合同编号B-20240001”语义空间里两者的向量距离非常接近检索排序时难以区分细微差异模型分不清谁是谁。再比如专业术语“胶质母细胞瘤”和它的英文缩写“GBM”如果文档中只出现英文缩写模型的词表里可能没有完整映射关系用户用中文问就召回不到。所以纯向量检索适合“找同义、找相关”不适合“精确匹配、找编号、找名称”。这也是为什么生产级的RAG系统里混合检索是标配而不是可选项。3.2 混合检索 Rerank是标配混合检索的做法很直白同时跑两路召回。一路是向量召回利用语义相似性另一路是BM25这种关键词召回用词频和逆文档频率的统计方法找到字面匹配的文档。两路结果合并去重之后再做一次重排。重排的必要性在于向量和BM25各自给出的排序分数不在同一个量级没办法直接比较。如果把两路结果按原分数混在一起取topN很可能是向量的一堆弱相关再加上关键词的一堆强相关没有一个出头的。Rerank模型会统一接收query和候选文档输出一个更精准的相关性分数然后再排序。我用下来bge-reranker这类开源模型在中文场景的表现能和商用付费服务打个平手部署成本却能省不少。代价是重排是额外计算量建议召回100条、重排取top5到10条性价比最高。重排这一步是很多项目“效果突然变好”的关键原因我测试过同样的管道加了Rerank之后答案命中率能提高十几个百分点。3.3 查询改写与HyDE值不值得上召回烂有时候不怪检索怪query本身太烂。用户真实输入往往很短、口语化、有歧义比如“它怎么开启”——如果不做上下文补全机器根本不知道“它”指代什么。查询改写就是让LLM先把用户问题改写成更适合检索的形式比如“TPM如何开启”改写成“TPM 2.0 安全模块的开启方法步骤”。这个操作对对话型RAG尤其重要因为多轮对话里大量指代词会随着对话轮次增长。另一种思路是HyDEHypothetical Document Embeddings让LLM先根据问题生成一个“假设答案”再拿这个假设答案的向量去检索。它的理论依据是假设答案可能比原问题更接近目标文档的语义空间检索效果通常更好。但它有两个明显副作用一是生成假设答案有额外延迟二是一旦模型凭空想象错了方向检索结果会被带偏。我的判断是只有在你已经确认检索结果普遍跑偏且query本身又特别简短模糊时才值得上HyDE。正常情况下查询改写加上混合检索和Rerank已经能把召回质量拉到够用线。4. 结构与知识图谱RAG知识库和结构知识库不是一回事最近知识图谱类RAG的讨论多了起来GraphRAG和Ontology RAG开始频繁出现在技术文章里。但我发现一个普遍误区很多人以为只要在流水线里加一个图数据库就能解决所有RAG问题。实际上RAG知识库和结构知识库在底层逻辑上就完全不同适用的场景更是天差地别。4.1 rag知识库和结构知识库的本质区别RAG知识库的核心载体是文本用向量表示文本语义检索方式是相似度匹配。它的优势是构建成本低任何文档都能直接导入使用不需要人工建模适合“找到原文中的答案”这类场景。它的劣势是它并不理解文本背后的实体关系只懂得“这段话和那段话在语义空间里离得近”而已。结构知识库的核心载体是实体和关系典型形式就是知识图谱。它是把文档里的信息抽取加工成“节点-边-节点”的三元组例如“张三—任职于—某科技公司”。这种结构天然支持关系推理比如“张三认识李四李四在A公司问张三有没有在A公司工作的朋友”这类多跳问题用向量检索很难答好用图谱却可以沿着关系路径直接推出来。本体Ontology就是给这类图谱事先定义好一套概念和关系标准比如“公司”是一个概念“任职于”是一类关系避免不同来源的实体名称发生冲突。4.2 什么场景必须上图谱、什么场景别硬上我不建议一上来就上知识图谱因为它构建和维护成本都不低需要做实体抽取、关系识别、实体对齐、关系消歧每一步都可能引入错误。有一个经验判断标准可供参考如果业务问题绝大多数是“某概念是什么”“某文档里怎么规定的”用RAG知识库就够了如果问题需要“跨多个文档找关系链条”比如“找出所有与A公司有股权关系的公司”那纯文本RAG很难做好因为答案分散在不同文档里向量检索顶多召回零散的片段无法完成关系推导。实际操作中我的建议是“文本先行、图谱补充”。先用RAG知识库覆盖80%的问答需求把高频卡点问题找出来再看这些问题是否集中在关系推理上。如果确实是再针对那部分数据构建图谱而不是一开始就把整批业务文档全部灌进图数据库。GraphRAG之类方法虽然自动抽谱可以降低人工建模成本但抽出来的图谱质量仍需人工校验我见过抽取错误率高达20%以上的项目这样的图谱喂给检索器等于在源头埋雷。4.3 Ontology与GraphRAG的实践观察Ontology的意义在于给异质数据定标准。一个企业里不同部门对“客户”的定义可能不一样销售部的“客户”是联系人财务部的“客户”是账期主体。如果没有统一本体图谱里会出现大量同名不同义的节点检索时很容易把两个概念混为一谈。所以本体建设其实是一个数据治理问题而不是纯粹的技术问题。GraphRAG类方案目前还处在“工程化初期”它们擅长构图但回答生成时如何把图路径和文本片段有机结合还没有一个完美的统一范式。我的实践经验是把图谱检索结果当作“结构化证据链”把向量检索的文本当作“内容来源”两者一起塞进Prompt让模型结合回答效果比二选一要好得多。这套混合的思路比盲目迷信单一架构要可靠得多。5. 生成端幻觉、引用与兜底设计RAG的意义本来就是给大模型“划范围”让它的回答有据可依。但很多人忽视了检索到了正确内容不代表模型会老实使用这些内容。大模型在生成时依然倾向于把训练记忆里的内容填进来尤其当检索内容不完整或格式复杂时。这一节讲的是如何从Prompt和输出设计上把幻觉压下去让回答稳定、可溯源、更可信。5.1 Prompt里必须体现的引用约束我搭RAG的Prompt从来只做三件事告诉模型角色和任务、限定信息来源、明确输出格式。最重要的限定信息来源部分要写清楚“只能基于下面的参考片段回答不要使用外部知识”还要加上“如果参考片段中没有答案直接回答‘知识库中暂无相关信息’”。为什么这么强调因为模型在自由发挥时会非常自信地编造条款尤其是那些训练数据里反复出现的常见条款但凡沾点边它就能给你生成一大段看似合理的假规则。还有一个容易忽略的点输出格式要明确要求模型在回答末尾自行附上引用来源引用粒度建议到chunkId如果支持还能细化到原文页码。我用过一个很简单的约束方法要求模型以“[1][2]”这种角标形式标注引用编号编号对应Prompt里给出的参考片段顺序。这样做有两个好处一是用户能看到依据在哪提升可信度二是工程上方便做日志复盘知道这次回答到底用了哪些文档。5.2 “知识不足”场景的兜底设计检索结果不一定总是有货尤其冷门问题或者长尾query可能召回结果为空也可能召回了一堆完全不相关的片段。许多系统的糟糕体验在于明明没有相关资料模型还在硬答。为了避免幻觉必须在Prompt里给出明确的“承认不知道”指令但承认本身不够还要在系统流程上做兜底。我的方案是实现三级兜底第一级检索结果为空时直接返回“知识库中暂无相关内容建议补充文档或联系管理员”第二级检索结果相关性不足时可以二次触发检索把query改写后再查一遍第三级二次检索仍不理想就如实告知用户“现有资料中未找到精确答案”并附上最接近的几条参考文档标题让用户自行判断。这三级兜底看起来很简单但对于客户的耐心度和系统的可信度影响非常大比生硬地给一个“也许你可以试试XXX”的假答案好得多。5.3 多路知识的融合产出生产级RAG常常不是单一路知识来源而是同时包含向量库、知识图谱、API接口等各自不同的信息通道。比如用户问“某设备当前运行状态和最近一次故障记录”向量库能给出设备手册相关段落API接口能查到实时状态图谱可能存着设备与维修记录的关联关系。如果只让模型看一路结果回答一定不完整。多路融合的关键是组织好Prompt结构同一答案可能需要同时引用“解释性文本”和“结构化状态”。实际工程中我会先把各路的检索结果按“来源名 内容 置信度”结构化拼装再统一交给模型。注意来源名最好是模型能理解的描述语言不要直接给一堆JSON字段名否则模型会照着JSON格式回答案看着生硬。这个细节我调试了很久才意识到模型对不同来源的响应方式受Prompt描述影响很大描述越贴近自然语言输出越稳定。6. 没有评测体系的RAG等于盲调很多团队跑通RAG之后的第一件事是继续调优但你问他“怎么知道这次调优有效果”他只能回答“感觉好了一些”。这本质上是在盲调。RAG系统链路长、环节多任何一个环节的改变都可能产生蝴蝶效应没有一套可靠的评测机制你就永远无法定位问题到底出在解析、切分、检索、重排还是生成。评测体系是第六道也可能最重要的分水岭。6.1 RAGAS等指标的适用与局限业界比较流行的是RAGAS这套评测框架它的核心指标包括忠实度答案是否忠于检索上下文、答案相关性答案是否切题和上下文相关性检索到的资料是否与问题高度相关。它通常需要拿一组query逐条调用LLM裁判打分而不是人工一件件看效率很高。但对LLM裁判打分这件事我的态度是可以作为“每天快速跑一遍回归”的廉颇但不能作为唯一质量基准。因为裁判LLM本身也有偏好和盲区比如对长答案更宽容、对某些术语理解错位导致分数和实际情况偏差。我踩过的情况是某次RAGAS忠实度得分很高可人工抽样却发现答非所问原因是裁判模型被回答的流畅度误导了。所以我会把RAGAS当成“早期报警器”分数波动就去做人工核查不把它的绝对分值当成业务真相。6.2 业务数据集才是金标准要真正评价RAG好不好最靠谱的是建立一个业务级评测集从真实用户query里挑出有代表性的问题每条配上标准答案或至少配上关键词和预期引用的文档。数量不需要很多50到100条质量高的就够用了关键是覆盖面要广要包含两类样本一类是高频常问的“普通题”另一类是高难度的“边界题”比如多跳推理、专有名词、空结果、近似误导题等。有了这个评测集每次改动后方可批量跑一遍对比回答质量的正确率、引用命中率、空答率。我把这个评测集当成RAG项目的“红绿灯”。没有这个红灯任何优化都只是自我感觉良好。建立方法我建议从日志里找真实query入手选择搜索日志里出现频率靠前的query作为骨干再让业务同事补充一些实际工作中遇到但日志里没有的疑难问题两者结合就是一套接地气的评测集。6.3 线上监控与回流闭环线下评测集解决的是“改版发布前”的问题线上运行一段时间之后问题又会冒出来用户问法变了、新增了文档类型、某类query持续答空。这时候需要线上日志的分析。我建议每条RAG日志至少要记录四个字段原始query、最终召回的相关片段列表、模型生成的回答、用户是否给出反馈比如点赞点踩。然后定期统计两个指标空答率模型回答“不知道”的比例和低满意度率点踩或未点踩的比例。如果某类query的空答率偏高就要检查是不是文档覆盖不足或检索配置太严如果召回相关但用户不满意重点检查重排和生成Prompt。把这些badcase抽出来人工分析之后再沉淀回线下评测集形成一个持续迭代的闭环。这个闭环跑三个月之后项目的RAG质量会稳定上一个台阶这也是为什么那些做得好的团队感觉“越调越好用”。我个人在实际操作中的体会是RAG的进阶之路从来不是换一个更贵的模型或者更炫的框架而是把这六个环节一个一个抠细。解析多花三小时切分测试跑两天重排模型部署多花一天评测集手工标注几个晚上这些都不起眼但拼在一起就是普通流水线和生产级系统的距离。如果你的项目正卡在“demo能用但上线就崩”的状态我建议先别急着改架构回头把这六处过一遍先补上评测数据集再动手调你会发现方向一下子清晰很多。最后再分享一个小技巧把最近三个月真实用户的高频query去重后拿出来当成一把评测集直接用效果比任何公开benchmark都说明问题。很多团队抱怨没有评测集其实评测数据早就躺在日志里了只差一个提炼的动作。 
长河君 · 2026/10/27 16:55:14 · 阅读 1.2k RAG从能跑到能用：决定生产级效果的六个关键环节
现在说RAG烂大街我猜没人反对。随便一个懂点大模型的朋友都能用LangChain、LlamaIndex或者Dify在半小时内搭出一条RAG流水线加载文档、切成chunk、灌进向量库、接上LLM跑起来就能对着PDF问答。问题在于这套demo级的流水线放到真实业务里往往被吊打。我见过太多团队抱怨“RAG效果不行”但聊下来发现他们用的就是那条公开模板流水线缺的不是模型能力而是后面六个环节的精细度。换句话说从“能跑”到“能用”真正的分水岭根本不在框架选型而在六个容易被忽略的细节环节上。这篇文章挨个拆开讲每个环节都会说清楚原理、实操要点和踩坑经验希望能帮你少走几个月的弯路。1. 文档解析与清洗被严重低估的第一道分水岭很多人以为RAG第一步就是“导入文档”直接把PDF、Word往框架里一丢Embedding模型一跑就完事。这是最大的错觉。真实业务里的文档千奇百怪解析质量直接决定了后续切分和召回的上限。解析这一步做得烂后面所有环节都白搭。1.1 文本型PDF和扫描件是两个世界先把PDF分成两类文本型PDF和扫描型PDF。文本型PDF里每个字符是真实可选的文本对象用PyPDF2、pdfplumber这类工具可以直接提取扫描件本质上是一张张图片必须走OCR才能拿到文字。如果项目里混入了扫描件却没用OCR那结果是提取出来一堆空字符串召回率直接归零。我建议项目启动第一天就把文档来源摸清楚按类型建个清单哪些是导出型PDF哪些是扫描件哪些是Word/Excel导出的哪些是网页转存的。扫描件用量小就手工跑一遍OCR量大就做一个自动判定的预处理管道。判断“是否扫描件”有个很实用的笨办法统计提取出的有效字符数如果某页文本长度低于阈值大概率是图片页。OCR选型上中文场景我先后试过Tesseract和PaddleOCR实测PaddleOCR的中文识别率明显更高尤其是带表格的扫描件。注意OCR完成之后还要做一遍字符清洗常见的OCR错字比如“0”和“O”不分、“1”和“l”混淆如果后续要按编号检索这类错误会直接破坏召回。清洗规则不必很复杂一个定时扫描的监督脚本就能处理大部分问题。1.2 表格、多栏版式最常见的翻车点第二个高频翻车点是版面分析。很多金融、法律领域的PDF是双栏排版如果直接按文本流提取左右两栏的内容会被交错拼接形成完全不可读的乱序文本。一个常见现象是用户问“第三条的内容是什么”回答却把第二条和第四条的内容搅在一起。这就是版面分析没做的后果。我的做法是文本型PDF先走layoutparser或PyMuPDF自带的版面检测识别出标题栏、正文栏、表格区域再按阅读顺序重排。表格不能跟普通段落一样切割我试过用OpenCV画框和深度学习表格结构识别工具两种方案后者对复杂表头处理更稳。识别完表格之后建议把它转换为“表格名 表头行 行记录”这种带上下文的描述文本而不是保留Markdown表格格式。因为向量检索是按语义找答案Markdown的竖线符号对Embedding模型来说是噪音反而干扰相似度计算。提示解析清洗之后务必做一轮抽样人工验收。我每次都会随机抽10页查看提取结果确认没有错乱、乱码、缺漏再进入下一步。这一步多花一小时后面能省一整天。2. 切分策略隐藏的胜负手文档解析出来是完整的长文本直接全部塞给Embedding模型既不现实检索效果也差。这一步要把长文本切成有意义的片段也就是chunk。很多人按固定字数一刀切结果把完整的段落、句子甚至表格从中间劈开导致检索到的片段上下文不完整回答自然就歪了。切分策略直接决定了能召回什么粒度的信息是整个RAG管线里用户感知最明显的一个环节。2.1 固定窗口切分 vs 语义切分固定窗口切分是最简单的方案按token数每200或者400切一段再设置几十token的重叠。它的优点是实现简单、对任何文本都通用缺点是会切断句子和段落尤其不适合中文。中文不像英文以词为单位固定窗口很容易把一个完整语义的复句拦腰截断模型拿到的片段往往“读了后面忘了前面”。语义切分是按文档结构来切比如按标题、章节、段落边界作为切分点。效果比固定窗口好得多因为它保留了完整的语义单元。实际操作时可以用LangChain的MarkdownHeaderTextSplitter、RecursiveCharacterTextSplitter这类工具把标题层级作为天然的切分边界。还有一种更进阶的做法是根据embedding之间的余弦相似度做动态切分计算相邻句子的相似度当相似度低于阈值时认为话题切换在这里断开。这种方式对杂志、论文这种结构散乱的文档比较有效但计算量稍大我一般只在文档结构不明显的场景才用。2.2 父子chunk与滑动窗口的实战取舍在真实项目里经常遇到这样的矛盾检索阶段希望chunk小一点命中更精准比如只切到表格行或段落级搜索“合同编号”能精确命中但生成阶段交给大模型的上下文不能太碎只有表格一行信息是无法推理出完整条款的。这个时候就要用父子chunk结构小段负责检索大段负责生成。具体实现是将原文先切成大块父每块再细分成小块子。检索时通过子chunk的向量找到内容命中后用映射关系找到所属的父chunk把它作为上下文交给LLM。我在LangChain里踩过这个坑它默认的返回值是命中的那个小chunk本身如果不做父子映射模型拿到的是残缺信息。正确做法是在元数据里存父chunk的id命中子chunk后根据id回溯父chunk再拼接上下文。滑动窗口则是另一种思路它按固定步长滑动切割每个chunk之间保留部分重叠上下文相当于让模型能看到“上一段尾巴”适合纯文本流文档但与语义切分相比粒度更粗不太适合结构型文档。2.3 chunk size选型的经验值关于chunk size我直接给一组经验参考普通问答场景中文文本推荐200到300个token英文可以放到300到400个token如果文档是小说明、规章制度那样以短句为主的内容建议100到200个token如果文档是长篇幅逻辑推理内容可以放宽到500甚至800个token但检索精度会有所下降。为什么不直接给一个固定值因为不同文档的“语义密度”不一样。同样500个字一个场景是产品说明书每50个字就包含一个操作命令另一个场景是学术论文引言500字可能只讲了一个大背景。所以适合的chunk size必须通过小批量测试确定方法是在一套有标注的评测集上跑不同size对比命中率和回答质量。我见过大部分团队把chunk size当成固定参数一劳永逸不改这是明显的盲区。建议至少拿20条代表性query做AB对比再定初始值后续每遇到一类新文档要重新验证。3. 召回环节向量之外还差一个重排流水线做得再漂亮如果召回的文档压根不相关生成端再聪明也答不对。所以说召回是RAG的命门丝毫不过分。很多入门项目只做一个步骤把用户query转成向量去向量库做余弦相似度topN。感受过真实数据之后你会发现这条路单独走不稳向量检索擅长找语义相近的内容却不擅长处理专有名词、编号和低频词比如用户问“TPM2.0协议”纯向量可能召回一堆关于“安全芯片”的泛泛文档却没有精确命中那篇标题只有“TPM2.0”的规范。3.1 为什么纯向量检索容易“漏人”先说清楚原理。主流Embedding模型本质上是把文本映射到语义空间中的向量它捕捉的是整体语义倾向很难区分细粒度的实体。比如“合同编号A-20240001”和“合同编号B-20240001”语义空间里两者的向量距离非常接近检索排序时难以区分细微差异模型分不清谁是谁。再比如专业术语“胶质母细胞瘤”和它的英文缩写“GBM”如果文档中只出现英文缩写模型的词表里可能没有完整映射关系用户用中文问就召回不到。所以纯向量检索适合“找同义、找相关”不适合“精确匹配、找编号、找名称”。这也是为什么生产级的RAG系统里混合检索是标配而不是可选项。3.2 混合检索 Rerank是标配混合检索的做法很直白同时跑两路召回。一路是向量召回利用语义相似性另一路是BM25这种关键词召回用词频和逆文档频率的统计方法找到字面匹配的文档。两路结果合并去重之后再做一次重排。重排的必要性在于向量和BM25各自给出的排序分数不在同一个量级没办法直接比较。如果把两路结果按原分数混在一起取topN很可能是向量的一堆弱相关再加上关键词的一堆强相关没有一个出头的。Rerank模型会统一接收query和候选文档输出一个更精准的相关性分数然后再排序。我用下来bge-reranker这类开源模型在中文场景的表现能和商用付费服务打个平手部署成本却能省不少。代价是重排是额外计算量建议召回100条、重排取top5到10条性价比最高。重排这一步是很多项目“效果突然变好”的关键原因我测试过同样的管道加了Rerank之后答案命中率能提高十几个百分点。3.3 查询改写与HyDE值不值得上召回烂有时候不怪检索怪query本身太烂。用户真实输入往往很短、口语化、有歧义比如“它怎么开启”——如果不做上下文补全机器根本不知道“它”指代什么。查询改写就是让LLM先把用户问题改写成更适合检索的形式比如“TPM如何开启”改写成“TPM 2.0 安全模块的开启方法步骤”。这个操作对对话型RAG尤其重要因为多轮对话里大量指代词会随着对话轮次增长。另一种思路是HyDEHypothetical Document Embeddings让LLM先根据问题生成一个“假设答案”再拿这个假设答案的向量去检索。它的理论依据是假设答案可能比原问题更接近目标文档的语义空间检索效果通常更好。但它有两个明显副作用一是生成假设答案有额外延迟二是一旦模型凭空想象错了方向检索结果会被带偏。我的判断是只有在你已经确认检索结果普遍跑偏且query本身又特别简短模糊时才值得上HyDE。正常情况下查询改写加上混合检索和Rerank已经能把召回质量拉到够用线。4. 结构与知识图谱RAG知识库和结构知识库不是一回事最近知识图谱类RAG的讨论多了起来GraphRAG和Ontology RAG开始频繁出现在技术文章里。但我发现一个普遍误区很多人以为只要在流水线里加一个图数据库就能解决所有RAG问题。实际上RAG知识库和结构知识库在底层逻辑上就完全不同适用的场景更是天差地别。4.1 rag知识库和结构知识库的本质区别RAG知识库的核心载体是文本用向量表示文本语义检索方式是相似度匹配。它的优势是构建成本低任何文档都能直接导入使用不需要人工建模适合“找到原文中的答案”这类场景。它的劣势是它并不理解文本背后的实体关系只懂得“这段话和那段话在语义空间里离得近”而已。结构知识库的核心载体是实体和关系典型形式就是知识图谱。它是把文档里的信息抽取加工成“节点-边-节点”的三元组例如“张三—任职于—某科技公司”。这种结构天然支持关系推理比如“张三认识李四李四在A公司问张三有没有在A公司工作的朋友”这类多跳问题用向量检索很难答好用图谱却可以沿着关系路径直接推出来。本体Ontology就是给这类图谱事先定义好一套概念和关系标准比如“公司”是一个概念“任职于”是一类关系避免不同来源的实体名称发生冲突。4.2 什么场景必须上图谱、什么场景别硬上我不建议一上来就上知识图谱因为它构建和维护成本都不低需要做实体抽取、关系识别、实体对齐、关系消歧每一步都可能引入错误。有一个经验判断标准可供参考如果业务问题绝大多数是“某概念是什么”“某文档里怎么规定的”用RAG知识库就够了如果问题需要“跨多个文档找关系链条”比如“找出所有与A公司有股权关系的公司”那纯文本RAG很难做好因为答案分散在不同文档里向量检索顶多召回零散的片段无法完成关系推导。实际操作中我的建议是“文本先行、图谱补充”。先用RAG知识库覆盖80%的问答需求把高频卡点问题找出来再看这些问题是否集中在关系推理上。如果确实是再针对那部分数据构建图谱而不是一开始就把整批业务文档全部灌进图数据库。GraphRAG之类方法虽然自动抽谱可以降低人工建模成本但抽出来的图谱质量仍需人工校验我见过抽取错误率高达20%以上的项目这样的图谱喂给检索器等于在源头埋雷。4.3 Ontology与GraphRAG的实践观察Ontology的意义在于给异质数据定标准。一个企业里不同部门对“客户”的定义可能不一样销售部的“客户”是联系人财务部的“客户”是账期主体。如果没有统一本体图谱里会出现大量同名不同义的节点检索时很容易把两个概念混为一谈。所以本体建设其实是一个数据治理问题而不是纯粹的技术问题。GraphRAG类方案目前还处在“工程化初期”它们擅长构图但回答生成时如何把图路径和文本片段有机结合还没有一个完美的统一范式。我的实践经验是把图谱检索结果当作“结构化证据链”把向量检索的文本当作“内容来源”两者一起塞进Prompt让模型结合回答效果比二选一要好得多。这套混合的思路比盲目迷信单一架构要可靠得多。5. 生成端幻觉、引用与兜底设计RAG的意义本来就是给大模型“划范围”让它的回答有据可依。但很多人忽视了检索到了正确内容不代表模型会老实使用这些内容。大模型在生成时依然倾向于把训练记忆里的内容填进来尤其当检索内容不完整或格式复杂时。这一节讲的是如何从Prompt和输出设计上把幻觉压下去让回答稳定、可溯源、更可信。5.1 Prompt里必须体现的引用约束我搭RAG的Prompt从来只做三件事告诉模型角色和任务、限定信息来源、明确输出格式。最重要的限定信息来源部分要写清楚“只能基于下面的参考片段回答不要使用外部知识”还要加上“如果参考片段中没有答案直接回答‘知识库中暂无相关信息’”。为什么这么强调因为模型在自由发挥时会非常自信地编造条款尤其是那些训练数据里反复出现的常见条款但凡沾点边它就能给你生成一大段看似合理的假规则。还有一个容易忽略的点输出格式要明确要求模型在回答末尾自行附上引用来源引用粒度建议到chunkId如果支持还能细化到原文页码。我用过一个很简单的约束方法要求模型以“[1][2]”这种角标形式标注引用编号编号对应Prompt里给出的参考片段顺序。这样做有两个好处一是用户能看到依据在哪提升可信度二是工程上方便做日志复盘知道这次回答到底用了哪些文档。5.2 “知识不足”场景的兜底设计检索结果不一定总是有货尤其冷门问题或者长尾query可能召回结果为空也可能召回了一堆完全不相关的片段。许多系统的糟糕体验在于明明没有相关资料模型还在硬答。为了避免幻觉必须在Prompt里给出明确的“承认不知道”指令但承认本身不够还要在系统流程上做兜底。我的方案是实现三级兜底第一级检索结果为空时直接返回“知识库中暂无相关内容建议补充文档或联系管理员”第二级检索结果相关性不足时可以二次触发检索把query改写后再查一遍第三级二次检索仍不理想就如实告知用户“现有资料中未找到精确答案”并附上最接近的几条参考文档标题让用户自行判断。这三级兜底看起来很简单但对于客户的耐心度和系统的可信度影响非常大比生硬地给一个“也许你可以试试XXX”的假答案好得多。5.3 多路知识的融合产出生产级RAG常常不是单一路知识来源而是同时包含向量库、知识图谱、API接口等各自不同的信息通道。比如用户问“某设备当前运行状态和最近一次故障记录”向量库能给出设备手册相关段落API接口能查到实时状态图谱可能存着设备与维修记录的关联关系。如果只让模型看一路结果回答一定不完整。多路融合的关键是组织好Prompt结构同一答案可能需要同时引用“解释性文本”和“结构化状态”。实际工程中我会先把各路的检索结果按“来源名 内容 置信度”结构化拼装再统一交给模型。注意来源名最好是模型能理解的描述语言不要直接给一堆JSON字段名否则模型会照着JSON格式回答案看着生硬。这个细节我调试了很久才意识到模型对不同来源的响应方式受Prompt描述影响很大描述越贴近自然语言输出越稳定。6. 没有评测体系的RAG等于盲调很多团队跑通RAG之后的第一件事是继续调优但你问他“怎么知道这次调优有效果”他只能回答“感觉好了一些”。这本质上是在盲调。RAG系统链路长、环节多任何一个环节的改变都可能产生蝴蝶效应没有一套可靠的评测机制你就永远无法定位问题到底出在解析、切分、检索、重排还是生成。评测体系是第六道也可能最重要的分水岭。6.1 RAGAS等指标的适用与局限业界比较流行的是RAGAS这套评测框架它的核心指标包括忠实度答案是否忠于检索上下文、答案相关性答案是否切题和上下文相关性检索到的资料是否与问题高度相关。它通常需要拿一组query逐条调用LLM裁判打分而不是人工一件件看效率很高。但对LLM裁判打分这件事我的态度是可以作为“每天快速跑一遍回归”的廉颇但不能作为唯一质量基准。因为裁判LLM本身也有偏好和盲区比如对长答案更宽容、对某些术语理解错位导致分数和实际情况偏差。我踩过的情况是某次RAGAS忠实度得分很高可人工抽样却发现答非所问原因是裁判模型被回答的流畅度误导了。所以我会把RAGAS当成“早期报警器”分数波动就去做人工核查不把它的绝对分值当成业务真相。6.2 业务数据集才是金标准要真正评价RAG好不好最靠谱的是建立一个业务级评测集从真实用户query里挑出有代表性的问题每条配上标准答案或至少配上关键词和预期引用的文档。数量不需要很多50到100条质量高的就够用了关键是覆盖面要广要包含两类样本一类是高频常问的“普通题”另一类是高难度的“边界题”比如多跳推理、专有名词、空结果、近似误导题等。有了这个评测集每次改动后方可批量跑一遍对比回答质量的正确率、引用命中率、空答率。我把这个评测集当成RAG项目的“红绿灯”。没有这个红灯任何优化都只是自我感觉良好。建立方法我建议从日志里找真实query入手选择搜索日志里出现频率靠前的query作为骨干再让业务同事补充一些实际工作中遇到但日志里没有的疑难问题两者结合就是一套接地气的评测集。6.3 线上监控与回流闭环线下评测集解决的是“改版发布前”的问题线上运行一段时间之后问题又会冒出来用户问法变了、新增了文档类型、某类query持续答空。这时候需要线上日志的分析。我建议每条RAG日志至少要记录四个字段原始query、最终召回的相关片段列表、模型生成的回答、用户是否给出反馈比如点赞点踩。然后定期统计两个指标空答率模型回答“不知道”的比例和低满意度率点踩或未点踩的比例。如果某类query的空答率偏高就要检查是不是文档覆盖不足或检索配置太严如果召回相关但用户不满意重点检查重排和生成Prompt。把这些badcase抽出来人工分析之后再沉淀回线下评测集形成一个持续迭代的闭环。这个闭环跑三个月之后项目的RAG质量会稳定上一个台阶这也是为什么那些做得好的团队感觉“越调越好用”。我个人在实际操作中的体会是RAG的进阶之路从来不是换一个更贵的模型或者更炫的框架而是把这六个环节一个一个抠细。解析多花三小时切分测试跑两天重排模型部署多花一天评测集手工标注几个晚上这些都不起眼但拼在一起就是普通流水线和生产级系统的距离。如果你的项目正卡在“demo能用但上线就崩”的状态我建议先别急着改架构回头把这六处过一遍先补上评测数据集再动手调你会发现方向一下子清晰很多。最后再分享一个小技巧把最近三个月真实用户的高频query去重后拿出来当成一把评测集直接用效果比任何公开benchmark都说明问题。很多团队抱怨没有评测集其实评测数据早就躺在日志里了只差一个提炼的动作。