1. 流水线烂大街到底烂在哪儿1.1 每个 Demo 都长一个样这两年如果你说自己做 RAG大概率听到的反应是“哦又是个 RAG”。我算了下光是我进过的大小群里至少有十个朋友发过“基于 LangChain 的客服知识库”Demo八个人用的是同一张架构图加载文档、切分、Embedding、写进向量库、查询时做相似度检索、拼到 Prompt 里让大模型回答。你说它错吗完全没错。但你说它能解决实际问题吗大多数情况不能。这话说出来大概率要得罪一批刚入门的朋友但数据摆在那里。很多人把 RAG 项目上线之后最大的反馈是“召回的东西不相关”“答案看着挺顺溜但细节全是编的”“换个问法就崩了”。这不是模型出了问题而是流水线本身只能保证“跑通”并不保证“跑对”。真正让一个 RAG 系统从玩具变成生产工具的从来不是那条谁都能搭的流水线而是藏在流水线背后的几个关键决策。1.2 框架让我变强也让我变懒我并不是反对框架我自己也在用 LangChain、Dify 这些东西它们确实把大量重复工作变成了配置项。但框架最大的副作用是让人误以为“配置完就是完成”。框架像是一套预制菜你按说明书加热三分钟端出来的确实是一盘能吃的菜但离“私房菜”还有很大距离。大多数 RAG 翻车案例翻的不是流水线本身而是流水线前面的知识体系设计、中间的检索策略、后面的评估闭环。我记得有个朋友用 Dify 拉了一条知识库流水线接了云端的 Embedding 模型测试时问“公司年假怎么休”答案基本能对上于是他就上线了。结果业务方问的是“去年十二月入职的员工今年二月离职年假怎么折算”——这种牵扯时间、人员状态、制度变更的组合问题直接把流水线给绕晕了。他后来跑来找我排查我才发现他对知识库里的文档连版本日期字段都没打季度更新后的制度老版本还在索引里检索结果新旧混杂模型完全是“看心情”回答。所以我想聊的真正主题是RAG 烂大街不假但烂大街的只是那条“读进来、切一切、存进去、搜出来、拼起来”的流水线。真正拉开差距的是六个分水岭知识表示、查询理解与路由、索引设计、检索与重排、评估闭环、生成与答案治理。下面我一个个拆开讲这些都是我在实际项目里踩坑踩出来的希望对正在搭 RAG 的同学有参考价值。2. 分水岭一知识表示文本切片和知识图谱是两个物种2.1 纯文本切片的边界大部分 RAG 教程的第一步是“把 PDF 切了”但很少有人问你你的知识到底是什么形态如果是一堆手册、公告、FAQ纯文本切片没问题。但你的知识一旦涉及实体之间的依赖关系比如产品参数与维修流程的关联、制度条款之间的引用纯文本的 embedding 就会变得非常勉强。我在做一个设备维修知识库时把 200 多页的手册切成 500 字的块Embedding 之后检索效果还行。但用户问“这台设备报警 E20需要什么工具和零件”系统召回的是“E20 报警描述”那一块却漏了“维修步骤详细清单”和“备件清单”。原因是这几个信息散落在不同章节向量上离得很远。文本切片本身没有错错误的是把文本切片当成了唯一的知识表示。你想想一篇手册里有几十个报警代码每个代码对应原因、工具、步骤、备件这些关系其实是一张网硬切成一段段文字后网就断了。2.2 何时上图谱、本体和结构化知识后来我们给这个维修库加了一层图谱把报警代码、故障原因、工具、备件、工序节点拆成实体和关系用轻量本体约束类型。比如“E20 使用部件为 S 型密封圈”“E20 对应维修工序 M3”“M3 需要扭矩扳手”这些三元组存进图数据库。查询时先用 LLM 把用户的自然语言解析成结构化路径再去图数据库里把路径取出来最后把取到的结构信息喂给生成模块。同样的查询召回质量直接上了一个台阶因为模型拿到的不再是几段可能相关的话而是一条完整的“报警 - 工序 - 备件”证据链。所以说知识表示是第一个分水岭。它要求你先判断领域里是“文”重要还是“关系”重要。比如法规制度类条款之间的“引用”“修订”“废止”关系比原文更重要电商客服类商品属性、库存状态、售后策略之间的联动关系比商品文案重要。这时候只靠向量库是不够的就应该考虑引入图数据库或者至少做一个知识图谱映射这也是 ontology RAG 的核心思路。关于 RAG 知识库和结构化知识库的区分我常用的判断标准很简单如果答案依赖多个分散文档的数据推理就得往结构化方向靠如果答案基本能在某一段原文里找到纯文本切片就够。2.3 关键实操混合知识表示怎么落地在真实项目里很少有人一上来就建全量图谱太重了。我更推荐的做法是两段式先用文本流水线保证覆盖度然后把高频查询里暴露出的“跨段落依赖”挑出来针对这些依赖建小图谱。这么做成本低很多见效也快。一个经验参考故障类、法律类、医疗类知识库图谱的投入回报率远高于纯文本优化常识型、资料型、百科型知识库做好切片和重排就行。这里能看出 RAG 和知识图谱不是对立关系而是互补。GraphRAG 或 Ontology RAG 本质都不是替代向量检索而是给生成模型提供更准确的“骨架”。我在工程上习惯把结果分为三类需要文本证据的走向量召回需要关系推理的走图查询两者都需要走混合——先图后文或者先文后图都可以具体取决于查询路由的判断这个在分水岭二展开聊。3. 分水岭二查询理解与路由别再“一段话打天下”3.1 简单查询 vs 复杂查询几乎所有流水线示例都是同一个动作拿到 query算出向量去向量库里做 topk。这种做法对付“年假有几天”没问题但对付“去年十二月入职、今年二月离职的员工年假怎么折算”就开始吃力了。问题不在检索而在查询本身需要拆分它包含实体员工、时间、制度、约束入职时间、离职时间还隐含一个计算规则。你直接拿整句话去向量化必然把语义摊平成一片模糊最后检索出来的全是“年假”“入职”“离职”这几个词分别出现的文章片段。所以第二个分水岭是你有没有认真对待“查询”这个环节。我的经验是把用户输入当作一等公民处理先判断是简单事实型、多跳推理型、计算型还是闲聊型再决定走哪条路。简单事实型可以直接向量检索多跳推理型要拆解成子查询计算型要到结构化表格里取数不能到文档里硬找闲聊型最好直接走模型对话别进知识库免得召回一堆无关片段把答案带偏。分类这件事不需要特别大的模型几个典型话术模板加一个小分类器就能跑起来。3.2 查询改写与路由策略具体做法也不复杂。可以用一个小模型做意图分类分到三五个固定路由也可以让主 LLM 先做一次查询结构化输出一个 JSON包含意图、实体、时间约束、需要的字段。比如前面那个年假问题结构化之后可能是查询年假折算规则、适用入职时间为去年十二月、离职时间为今年二月。基于这个结构化结果我们再决定是去原文搜索、去图数据库找规则还是去人资系统接口查数。这里有一个很容易踩的坑查询改写不是越复杂越好。我见过有人每次查询都让 LLM 扩写成五个查询再合并结果结果延迟从 1 秒涨到 6 秒召回反而因为噪音更多而变差。对于大部分场景一个精确的意图分类加一个必要时的子查询拆分足够了。路由的目的是“用最少步骤拿到最准的上下文”不是秀模型能力。做路由之后还有个附带好处你可以针对不同路由单独调优各自的检索策略和阈值而不必用一个万能参数死磕所有查询。3.3 实操一个多路召回的路由设计我举一个简化的路由设计这种结构我在几个项目里都验证过。用户输入先交给意图分类器得到路由标签再按标签进对应索引fact直接查向量库取 top5 文档块graph先解析实体关系图查询取结果再关联文本证据table查结构化数据库或表格取数值之后生成chat不进知识库直接走对话模型mixed先查意图涉及的多个索引再用重排环节统一排序。这个设计看起来简单但解决了一个大问题它让你不再用一个检索器去面对所有问法。多路召回之后哪怕每个单路的精度不高最终候选集里也大概率包含正确答案剩下的交给重排。路由本身可以是极小的模型跑在本地不影响主链路延迟。路由的准确率也不需要 100%关键是错误路由要能兜底——比如把 fact 误判成 graph顶多是多查一步把 graph 误判成 fact可能就查不到答案所以我会在 fact 路由里也带一个“是否需要额外图查询”的二次判断开关。4. 分水岭三索引设计决定检索天花板的细节4.1 块的大小、父子块、元数据说完查询再往底层走一步索引。很多人觉得索引就是“切块存向量”但切块是个很讲究的活。大小切多少没有标准答案但有几个规律。小 chunk比如 256 字召回粒度细但上下文缺失大 chunk比如 1000 字以上上下文全但噪声也大。我的习惯是FAQ 类小 chunk手册类中 chunk制度类“父子块”结合——父块存整章、子块存整段检索命中子块后把父块内容一起送进模型这样既保证命中精度又保证上下文完整。这个技巧在 LangChain 里叫 parent document retriever很多框架都有现成实现新手容易忽略。元数据是另一个被低估的东西。给每个 chunk 打上来源、章节、标题、日期、实体标签之后可以做过滤式检索。比如“只查去年的制度”这个需求如果没元数据纯靠语义检索经常搜出老版本加了日期元数据并按时间过滤之后召回质量稳定很多。真实场景里“版本”“状态”“适用范围”这几个字段比嵌入向量还重要。一旦知识库维护过三个月你就会明白版本混乱才是让 RAG 答案失真的大杀器。4.2 多路索引与时间维度有时候一份知识库里既有长期稳定的制度又有频繁变动的公告放在同一个向量空间里互相干扰。我的做法是分索引稳定区一个集合动态区一个集合查询的时候按路由决定查哪边或都查。多路索引的引入也给时间维度留了接口文档更新时间、生效时间都可以作为排序权重。这在法规库和排班类知识库里特别管用。多路索引另一个好处是方便做权限隔离。比如企业内部知识库有的部门文档只能被对应部门的人检索。如果你把所有内容塞进一个向量集合就无法在召回阶段做权限过滤。分索引之后按用户角色路由到对应索引权限天然隔离。这个点很多教程不讲但真实企业场景几乎是刚需。4.3 实操示例图书知识库索引举一个图书类知识库的例子。如果直接整本切切出来的块经常横跨两个主题搜索“主角的性格转变”会召回各种支离破碎的段落。我后来给小说库设计了三级结构章节为父块、场景为子块、每个场景带人名和关系标签再把全书的人物关系单独抽成一张小图谱。这样问“某角色在第几章第一次见到另一个角色”可以走图查询定位章节再去父块里取全文上下文。效果比纯文本切片好非常多原因只有一个索引的结构跟用户真正想问的问题对齐了。如果你用的是现成框架比如 Dify 或 FastGPT也一定要研究它们的索引配置而不只是默认切分。很多框架支持自定义元数据注入、父子块模式这些能力用起来之后知识库的检索上限会明显提高。索引这件事表面上是在处理文本实际上是在为你的知识体系建模。多花半小时设计索引结构可以省下后面几周调参的时间。5. 分水岭四检索与重排TopK 不等于质量5.1 为什么 top-k 会骗你向量检索的 TopK 有个很经典的毛病它善于找“像”不善于找“对”。用户问“设备停机怎么恢复”召回的可能是“停机的原因分类”“停机记录表填写说明”因为它们在语义空间里离得很近但真正有用的“恢复操作步骤”反而排在后面。如果你直接拿 top3 去生成答案大概率是正确但无用的废话。另一个常见坑是“局部相似”造成的重复。一个 chunk 里只有一句话相关其余全是背景描述但向量分很高。于是你取了 5 个 chunk真正有用的信息可能只有 5 句话。此时生成模型很容易被不相关的内容带偏甚至出现把 A 文档的信息安到 B 实体头上的幻觉。所以检索只是获得了“一组可疑的相关内容”真正的排序必须靠重排。5.2 混合检索与重排序器我的标准做法是混合检索BM25 负责精确词匹配向量检索负责语义召回两者各自取回一批候选再用交叉编码器做重排。BM25 抓得住“E20”这种编号和专有名词向量抓得住“报警之后机器不转了”这种说法合并之后候选集质量会提高很多。重排阶段现在常用的 bge-reranker 或者相关榜单上的 reranker 模型会把 query 和 chunk 拼接成一对去打分比向量相似度更接近“实质相关性”。加入重排之后一定要控制输入给 LLM 的 token 量。重排只负责排序不负责去重。如果两个 chunk 高度重叠重排器可能给出相近的高分最终上下文全是重复信息。我会在重排后加一次简单的去重和压缩把重复段落过滤掉必要时只保留每个高分 chunk 里最相关的那段。这一步做得好生成效果提升非常明显。5.3 实操示例BM25 向量 重排我用一个简化伪代码展示链路方便你一比一复现思路def search(query, top_k5): bm25_hits bm25.search(query, top_k10) vector_hits vector_store.search(embed(query), top_k10) candidates merge(bm25_hits, vector_hits, dedupTrue) pairs [[query, chunk] for chunk in candidates] scores reranker.compute_score(pairs) ranked sort(candidates, byscores, reverseTrue)[:top_k] context compress(ranked) # 去掉重复与无关片段 return context实测下来这套链路比单独用向量检索的召回命中率一般能提升两到三成。代价是会增加几百毫秒延迟。如果对速度敏感可以用一个轻量分类器先判断是否需要重排简单查询跳过重排复杂查询才走完整链路。这又是一个“按需付出成本”的工程取舍而不是一刀切地追求最高精度。6. 分水岭五评估闭环不能只靠“感觉”6.1 离线评估指标很多人做完 RAG 之后评价标准是“看起来还行”这就埋了大雷。用户问十句有一两句回答得不对他可能不会告诉你但下次就不用了。所以第五个分水岭是评估闭环——你有没有一套能持续告诉你“这版比上一版强”的机制。离线评估我会看三类指标。一是检索质量最常用的是命中率即正确答案是否出现在召回的 top5 里还有 MRR。二是生成质量主要看忠实性也就是答案内容是否都有证据支撑以及完整性该覆盖的点有没有覆盖。三是端到端可用率把答案交给模拟用户或人工打标按“完全正确、部分正确、错误”三等分。这几个指标互相补充单纯看一个会骗人。6.2 端到端评估与线上反馈离线评估的局限是数据太少覆盖不了真实用户千奇百怪的问法。所以线上反馈必须接进来。最简单的做法是在答案底部加一个“有用/没用”按钮或者记录用户是否继续追问。别小看这个粗糙的信号它能在两周内帮你发现检索器是不是对某些高频问题系统性地失效。项目上线后我一般会单独维护一个“坏案例库”凡是用户点没用的、答错的、怼回来的都结构化记下来然后定期用这些坏案例重跑评估集。线上反馈光记录还不够要形成迭代动作。我习惯每两周做一次复盘把坏案例库里的问题重新跑一遍当前系统统计有多少被修复、有多少还是坏的坏的集中在哪个环节。这样你就能很清楚地知道下一步是调整 embedding、重排逻辑还是清洗知识文档。RAG 的优化本质上就是一个持续反馈闭环谁先建立这个闭环谁就能更快地把系统修到可用状态。6.3 实操一套最小可用的评测集最小可用的评测集不用太多50 到 100 条就可以起步。每条包含四列标准问题、查询类型、期望证据位置、参考答案。我把模板放在下面的表格里你可以直接抄。问题路由类型期望召回内容参考答案要点去年12月入职、今年2月离职年假怎么算graph/table离职年假折算规则、入职时间字段按当年剩余日历天数折算E20 报警需要什么备件graph报警对应工序的备件清单需要 XX 型号滤芯及密封圈公司附近的餐饮优惠chat不召回直接对话无这个表看起来简单但价值极高。每次调完切块参数、换 embedding、改路由规则都跑一遍对比“这版对几个、错几个”。十次迭代下来你会有一种“捏着数据做优化”的安全感而不是靠玄学调参。评估集建好之后建议存成 JSON 或 CSV纳入版本管理每次改动系统都留一个评估记录方便回溯到底哪次改动提升了效果。7. 分水岭六生成与答案治理防止一本正经胡说八道7.1 Prompt 与上下文压缩最后一道分水岭在生成端。哪怕前面检索做得很好如果 Prompt 不会调答案照样翻车。首先上下文不是越多越好。我见过有人把 10 个 chunk 全塞进去结果模型在无关信息里挑挑拣拣挑出个片面的答案。正确思路是先压缩再生成只保留与 query 明显相关的句子去掉背景、重复、无关实体。你也可以在 Prompt 里明确告诉模型“输出只能依据以下材料如果材料不包含答案直接说无法回答”。Prompt 里放哪些内容也很关键。我的固定套路是先放任务定义再放检索到的证据每段证据标注来源章节最后放用户问题。顺序错了效果会差很多因为模型对靠后的指令更敏感把用户问题放最后更能聚焦答案方向。这里有个小技巧在证据段落前加上“以下是知识库检出的参考片段它们可能相关也可能无关请自行判断”这句话看起来多余但能给模型一个“批判性使用材料”的暗示减少机械照搬导致的错误。7.2 引用、校验与幻觉兜底答案治理还包括引用溯源。生产环境里我强烈建议答案里的每个关键结论带上来源编号。这样用户能看到“这条依据来自《设备手册》第三章第 2 节”一旦发现错误也方便排查是证据问题还是模型理解问题。引用不只是用户体验更是一条调试链路。还有一个容易被忽略的操作设置“拒答”路径。很多 RAG 系统幻觉高发是因为模型在自己都不知道的情况下生成了答案。给 Prompt 加一条“材料不足时请回答‘知识库中未找到相关信息’”并将召回分数低于阈值的情况单独拦截直接走兜底话术能显著降低一本正经胡说八道的概率。我把它称为答案治理的守门员。别看这个设定简单它能让错误从“编造”变成“坦白”用户体验完全不同。8. 避坑实录从 Mac 搭建到图片需求那些事8.1 Mac 本地搭建 RAG 的关键很多人问我怎么在 Mac 上搭 RAG 知识库特别是没有 GPU 的情况下。其实现在本地搭一套最小系统不难用 Ollama 跑 embedding 和 chat 模型用 Chroma 或 Qdrant 做向量库用 LangChain 或 Dify 串流程。M 系列 Mac 跑 7B、8B 参数量级的模型完全没问题速度虽然比云端慢但做实验足够。我踩过最大的坑是 embedding 模型和中文字符。早期用某些英文优化模型处理中文召回效果惨不忍睹。后来换成了对中文友好的 embedding 模型并统一在入库前做文本清洗和同义归一效果立竿见影。Mac 上另一个问题是内存占用量切块大的时候嵌入一批长文档很容易把内存吃满。我的习惯是先小批量入库观察内存水位再逐步放大 batch。如果内存实在吃紧可以把 embedding 模型换小一点或者用 API 方式做向量化本地只负责存储和检索。8.2 知识库能不能存图片我试过的结果最近总有人问 RAG 知识库能不能存储图片。我直接说结论传统 RAG 流水线不能直接把图片塞进文本向量库但可以通过两个方向实现图片能力。一是提取图片里的文字用 OCR 转成文本再进入知识库适合截图、扫描件、表格图片。二是为图片单独建立视觉向量检索图片本身而不是文本再配合多模态模型生成答案适合设计图、产品图这种“看图说话”的场景。所以答案是“能但不是把图片和文本混在一个 chunk 里而是分索引、分流处理”。我在一个售后知识库里处理过大量设备照片和解说截图做法是 OCR 文本进一个向量索引图片原图单独存对象存储并保留链接生成答案时带上“相关图片链接”字段。用户体验很好也避免了多模态模型对每张图都读一遍的高延迟。如果你要处理的是图文混排的 PDF建议先按页面把图文关系保留再决定哪些内容走 OCR 文本、哪些图片走视觉模型这个设计比“整页塞进模型”可控得多。8.3 常见问题速查表我把几个真实项目里反复被问到的问题整理一下给后面的人少踩几个坑。现象可能原因处理建议召回文件都对但答案不相关生成的上下文里混入了无关 chunk做重排上下文压缩减少喂给模型的噪声换一种问法就查不到依赖单一向量检索加入 BM25向量混合召回制度版本总是回答老版缺少时间元数据过滤给 chunk 打生效日期检索时按版本过滤答案给得很完整但全在编没有做引用与拒答约束加事实校验、来源标注与“无法回答”兜底本地 Mac 跑得慢模型大或 batch 太大换小参数模型或在入库时用分批并限制并发用户问“图片里写了什么”答不出没有 OCR 或视觉索引单独接 OCR 管道或按需调用多模态模型这张表不是万能药但它对应的每一个问题我都亲眼见过有人在生产环境里踩过。RAG 的水很深但只要你顺着“知识表示、查询理解、索引设计、检索重排、评估闭环、答案治理”这六个分水岭逐项检查就大概率能定位到问题出在哪个环节。我在做第一个 RAG 项目的时候也天真地以为“搭好流水线就算完事”后来被用户一连串“这还是不对”的反馈硬生生逼着把六个环节逐个啃了一遍。现在回头看那些能在生产环境里稳定输出的 RAG 系统没有一个是在流水线层面胜出的全部赢在流水线之外的各种脏活累活上。前面这套经验如果你能照着梳理一遍至少可以少走几个月弯路。最后再提醒一句无论用什么框架起步一定要把“好问题、好证据、好评估”这三件事想清楚流水线反而最不需要担心。 
长河君 · 2026/10/27 16:55:11 · 阅读 1.2k RAG系统真正拉开差距的六大分水岭
1. 流水线烂大街到底烂在哪儿1.1 每个 Demo 都长一个样这两年如果你说自己做 RAG大概率听到的反应是“哦又是个 RAG”。我算了下光是我进过的大小群里至少有十个朋友发过“基于 LangChain 的客服知识库”Demo八个人用的是同一张架构图加载文档、切分、Embedding、写进向量库、查询时做相似度检索、拼到 Prompt 里让大模型回答。你说它错吗完全没错。但你说它能解决实际问题吗大多数情况不能。这话说出来大概率要得罪一批刚入门的朋友但数据摆在那里。很多人把 RAG 项目上线之后最大的反馈是“召回的东西不相关”“答案看着挺顺溜但细节全是编的”“换个问法就崩了”。这不是模型出了问题而是流水线本身只能保证“跑通”并不保证“跑对”。真正让一个 RAG 系统从玩具变成生产工具的从来不是那条谁都能搭的流水线而是藏在流水线背后的几个关键决策。1.2 框架让我变强也让我变懒我并不是反对框架我自己也在用 LangChain、Dify 这些东西它们确实把大量重复工作变成了配置项。但框架最大的副作用是让人误以为“配置完就是完成”。框架像是一套预制菜你按说明书加热三分钟端出来的确实是一盘能吃的菜但离“私房菜”还有很大距离。大多数 RAG 翻车案例翻的不是流水线本身而是流水线前面的知识体系设计、中间的检索策略、后面的评估闭环。我记得有个朋友用 Dify 拉了一条知识库流水线接了云端的 Embedding 模型测试时问“公司年假怎么休”答案基本能对上于是他就上线了。结果业务方问的是“去年十二月入职的员工今年二月离职年假怎么折算”——这种牵扯时间、人员状态、制度变更的组合问题直接把流水线给绕晕了。他后来跑来找我排查我才发现他对知识库里的文档连版本日期字段都没打季度更新后的制度老版本还在索引里检索结果新旧混杂模型完全是“看心情”回答。所以我想聊的真正主题是RAG 烂大街不假但烂大街的只是那条“读进来、切一切、存进去、搜出来、拼起来”的流水线。真正拉开差距的是六个分水岭知识表示、查询理解与路由、索引设计、检索与重排、评估闭环、生成与答案治理。下面我一个个拆开讲这些都是我在实际项目里踩坑踩出来的希望对正在搭 RAG 的同学有参考价值。2. 分水岭一知识表示文本切片和知识图谱是两个物种2.1 纯文本切片的边界大部分 RAG 教程的第一步是“把 PDF 切了”但很少有人问你你的知识到底是什么形态如果是一堆手册、公告、FAQ纯文本切片没问题。但你的知识一旦涉及实体之间的依赖关系比如产品参数与维修流程的关联、制度条款之间的引用纯文本的 embedding 就会变得非常勉强。我在做一个设备维修知识库时把 200 多页的手册切成 500 字的块Embedding 之后检索效果还行。但用户问“这台设备报警 E20需要什么工具和零件”系统召回的是“E20 报警描述”那一块却漏了“维修步骤详细清单”和“备件清单”。原因是这几个信息散落在不同章节向量上离得很远。文本切片本身没有错错误的是把文本切片当成了唯一的知识表示。你想想一篇手册里有几十个报警代码每个代码对应原因、工具、步骤、备件这些关系其实是一张网硬切成一段段文字后网就断了。2.2 何时上图谱、本体和结构化知识后来我们给这个维修库加了一层图谱把报警代码、故障原因、工具、备件、工序节点拆成实体和关系用轻量本体约束类型。比如“E20 使用部件为 S 型密封圈”“E20 对应维修工序 M3”“M3 需要扭矩扳手”这些三元组存进图数据库。查询时先用 LLM 把用户的自然语言解析成结构化路径再去图数据库里把路径取出来最后把取到的结构信息喂给生成模块。同样的查询召回质量直接上了一个台阶因为模型拿到的不再是几段可能相关的话而是一条完整的“报警 - 工序 - 备件”证据链。所以说知识表示是第一个分水岭。它要求你先判断领域里是“文”重要还是“关系”重要。比如法规制度类条款之间的“引用”“修订”“废止”关系比原文更重要电商客服类商品属性、库存状态、售后策略之间的联动关系比商品文案重要。这时候只靠向量库是不够的就应该考虑引入图数据库或者至少做一个知识图谱映射这也是 ontology RAG 的核心思路。关于 RAG 知识库和结构化知识库的区分我常用的判断标准很简单如果答案依赖多个分散文档的数据推理就得往结构化方向靠如果答案基本能在某一段原文里找到纯文本切片就够。2.3 关键实操混合知识表示怎么落地在真实项目里很少有人一上来就建全量图谱太重了。我更推荐的做法是两段式先用文本流水线保证覆盖度然后把高频查询里暴露出的“跨段落依赖”挑出来针对这些依赖建小图谱。这么做成本低很多见效也快。一个经验参考故障类、法律类、医疗类知识库图谱的投入回报率远高于纯文本优化常识型、资料型、百科型知识库做好切片和重排就行。这里能看出 RAG 和知识图谱不是对立关系而是互补。GraphRAG 或 Ontology RAG 本质都不是替代向量检索而是给生成模型提供更准确的“骨架”。我在工程上习惯把结果分为三类需要文本证据的走向量召回需要关系推理的走图查询两者都需要走混合——先图后文或者先文后图都可以具体取决于查询路由的判断这个在分水岭二展开聊。3. 分水岭二查询理解与路由别再“一段话打天下”3.1 简单查询 vs 复杂查询几乎所有流水线示例都是同一个动作拿到 query算出向量去向量库里做 topk。这种做法对付“年假有几天”没问题但对付“去年十二月入职、今年二月离职的员工年假怎么折算”就开始吃力了。问题不在检索而在查询本身需要拆分它包含实体员工、时间、制度、约束入职时间、离职时间还隐含一个计算规则。你直接拿整句话去向量化必然把语义摊平成一片模糊最后检索出来的全是“年假”“入职”“离职”这几个词分别出现的文章片段。所以第二个分水岭是你有没有认真对待“查询”这个环节。我的经验是把用户输入当作一等公民处理先判断是简单事实型、多跳推理型、计算型还是闲聊型再决定走哪条路。简单事实型可以直接向量检索多跳推理型要拆解成子查询计算型要到结构化表格里取数不能到文档里硬找闲聊型最好直接走模型对话别进知识库免得召回一堆无关片段把答案带偏。分类这件事不需要特别大的模型几个典型话术模板加一个小分类器就能跑起来。3.2 查询改写与路由策略具体做法也不复杂。可以用一个小模型做意图分类分到三五个固定路由也可以让主 LLM 先做一次查询结构化输出一个 JSON包含意图、实体、时间约束、需要的字段。比如前面那个年假问题结构化之后可能是查询年假折算规则、适用入职时间为去年十二月、离职时间为今年二月。基于这个结构化结果我们再决定是去原文搜索、去图数据库找规则还是去人资系统接口查数。这里有一个很容易踩的坑查询改写不是越复杂越好。我见过有人每次查询都让 LLM 扩写成五个查询再合并结果结果延迟从 1 秒涨到 6 秒召回反而因为噪音更多而变差。对于大部分场景一个精确的意图分类加一个必要时的子查询拆分足够了。路由的目的是“用最少步骤拿到最准的上下文”不是秀模型能力。做路由之后还有个附带好处你可以针对不同路由单独调优各自的检索策略和阈值而不必用一个万能参数死磕所有查询。3.3 实操一个多路召回的路由设计我举一个简化的路由设计这种结构我在几个项目里都验证过。用户输入先交给意图分类器得到路由标签再按标签进对应索引fact直接查向量库取 top5 文档块graph先解析实体关系图查询取结果再关联文本证据table查结构化数据库或表格取数值之后生成chat不进知识库直接走对话模型mixed先查意图涉及的多个索引再用重排环节统一排序。这个设计看起来简单但解决了一个大问题它让你不再用一个检索器去面对所有问法。多路召回之后哪怕每个单路的精度不高最终候选集里也大概率包含正确答案剩下的交给重排。路由本身可以是极小的模型跑在本地不影响主链路延迟。路由的准确率也不需要 100%关键是错误路由要能兜底——比如把 fact 误判成 graph顶多是多查一步把 graph 误判成 fact可能就查不到答案所以我会在 fact 路由里也带一个“是否需要额外图查询”的二次判断开关。4. 分水岭三索引设计决定检索天花板的细节4.1 块的大小、父子块、元数据说完查询再往底层走一步索引。很多人觉得索引就是“切块存向量”但切块是个很讲究的活。大小切多少没有标准答案但有几个规律。小 chunk比如 256 字召回粒度细但上下文缺失大 chunk比如 1000 字以上上下文全但噪声也大。我的习惯是FAQ 类小 chunk手册类中 chunk制度类“父子块”结合——父块存整章、子块存整段检索命中子块后把父块内容一起送进模型这样既保证命中精度又保证上下文完整。这个技巧在 LangChain 里叫 parent document retriever很多框架都有现成实现新手容易忽略。元数据是另一个被低估的东西。给每个 chunk 打上来源、章节、标题、日期、实体标签之后可以做过滤式检索。比如“只查去年的制度”这个需求如果没元数据纯靠语义检索经常搜出老版本加了日期元数据并按时间过滤之后召回质量稳定很多。真实场景里“版本”“状态”“适用范围”这几个字段比嵌入向量还重要。一旦知识库维护过三个月你就会明白版本混乱才是让 RAG 答案失真的大杀器。4.2 多路索引与时间维度有时候一份知识库里既有长期稳定的制度又有频繁变动的公告放在同一个向量空间里互相干扰。我的做法是分索引稳定区一个集合动态区一个集合查询的时候按路由决定查哪边或都查。多路索引的引入也给时间维度留了接口文档更新时间、生效时间都可以作为排序权重。这在法规库和排班类知识库里特别管用。多路索引另一个好处是方便做权限隔离。比如企业内部知识库有的部门文档只能被对应部门的人检索。如果你把所有内容塞进一个向量集合就无法在召回阶段做权限过滤。分索引之后按用户角色路由到对应索引权限天然隔离。这个点很多教程不讲但真实企业场景几乎是刚需。4.3 实操示例图书知识库索引举一个图书类知识库的例子。如果直接整本切切出来的块经常横跨两个主题搜索“主角的性格转变”会召回各种支离破碎的段落。我后来给小说库设计了三级结构章节为父块、场景为子块、每个场景带人名和关系标签再把全书的人物关系单独抽成一张小图谱。这样问“某角色在第几章第一次见到另一个角色”可以走图查询定位章节再去父块里取全文上下文。效果比纯文本切片好非常多原因只有一个索引的结构跟用户真正想问的问题对齐了。如果你用的是现成框架比如 Dify 或 FastGPT也一定要研究它们的索引配置而不只是默认切分。很多框架支持自定义元数据注入、父子块模式这些能力用起来之后知识库的检索上限会明显提高。索引这件事表面上是在处理文本实际上是在为你的知识体系建模。多花半小时设计索引结构可以省下后面几周调参的时间。5. 分水岭四检索与重排TopK 不等于质量5.1 为什么 top-k 会骗你向量检索的 TopK 有个很经典的毛病它善于找“像”不善于找“对”。用户问“设备停机怎么恢复”召回的可能是“停机的原因分类”“停机记录表填写说明”因为它们在语义空间里离得很近但真正有用的“恢复操作步骤”反而排在后面。如果你直接拿 top3 去生成答案大概率是正确但无用的废话。另一个常见坑是“局部相似”造成的重复。一个 chunk 里只有一句话相关其余全是背景描述但向量分很高。于是你取了 5 个 chunk真正有用的信息可能只有 5 句话。此时生成模型很容易被不相关的内容带偏甚至出现把 A 文档的信息安到 B 实体头上的幻觉。所以检索只是获得了“一组可疑的相关内容”真正的排序必须靠重排。5.2 混合检索与重排序器我的标准做法是混合检索BM25 负责精确词匹配向量检索负责语义召回两者各自取回一批候选再用交叉编码器做重排。BM25 抓得住“E20”这种编号和专有名词向量抓得住“报警之后机器不转了”这种说法合并之后候选集质量会提高很多。重排阶段现在常用的 bge-reranker 或者相关榜单上的 reranker 模型会把 query 和 chunk 拼接成一对去打分比向量相似度更接近“实质相关性”。加入重排之后一定要控制输入给 LLM 的 token 量。重排只负责排序不负责去重。如果两个 chunk 高度重叠重排器可能给出相近的高分最终上下文全是重复信息。我会在重排后加一次简单的去重和压缩把重复段落过滤掉必要时只保留每个高分 chunk 里最相关的那段。这一步做得好生成效果提升非常明显。5.3 实操示例BM25 向量 重排我用一个简化伪代码展示链路方便你一比一复现思路def search(query, top_k5): bm25_hits bm25.search(query, top_k10) vector_hits vector_store.search(embed(query), top_k10) candidates merge(bm25_hits, vector_hits, dedupTrue) pairs [[query, chunk] for chunk in candidates] scores reranker.compute_score(pairs) ranked sort(candidates, byscores, reverseTrue)[:top_k] context compress(ranked) # 去掉重复与无关片段 return context实测下来这套链路比单独用向量检索的召回命中率一般能提升两到三成。代价是会增加几百毫秒延迟。如果对速度敏感可以用一个轻量分类器先判断是否需要重排简单查询跳过重排复杂查询才走完整链路。这又是一个“按需付出成本”的工程取舍而不是一刀切地追求最高精度。6. 分水岭五评估闭环不能只靠“感觉”6.1 离线评估指标很多人做完 RAG 之后评价标准是“看起来还行”这就埋了大雷。用户问十句有一两句回答得不对他可能不会告诉你但下次就不用了。所以第五个分水岭是评估闭环——你有没有一套能持续告诉你“这版比上一版强”的机制。离线评估我会看三类指标。一是检索质量最常用的是命中率即正确答案是否出现在召回的 top5 里还有 MRR。二是生成质量主要看忠实性也就是答案内容是否都有证据支撑以及完整性该覆盖的点有没有覆盖。三是端到端可用率把答案交给模拟用户或人工打标按“完全正确、部分正确、错误”三等分。这几个指标互相补充单纯看一个会骗人。6.2 端到端评估与线上反馈离线评估的局限是数据太少覆盖不了真实用户千奇百怪的问法。所以线上反馈必须接进来。最简单的做法是在答案底部加一个“有用/没用”按钮或者记录用户是否继续追问。别小看这个粗糙的信号它能在两周内帮你发现检索器是不是对某些高频问题系统性地失效。项目上线后我一般会单独维护一个“坏案例库”凡是用户点没用的、答错的、怼回来的都结构化记下来然后定期用这些坏案例重跑评估集。线上反馈光记录还不够要形成迭代动作。我习惯每两周做一次复盘把坏案例库里的问题重新跑一遍当前系统统计有多少被修复、有多少还是坏的坏的集中在哪个环节。这样你就能很清楚地知道下一步是调整 embedding、重排逻辑还是清洗知识文档。RAG 的优化本质上就是一个持续反馈闭环谁先建立这个闭环谁就能更快地把系统修到可用状态。6.3 实操一套最小可用的评测集最小可用的评测集不用太多50 到 100 条就可以起步。每条包含四列标准问题、查询类型、期望证据位置、参考答案。我把模板放在下面的表格里你可以直接抄。问题路由类型期望召回内容参考答案要点去年12月入职、今年2月离职年假怎么算graph/table离职年假折算规则、入职时间字段按当年剩余日历天数折算E20 报警需要什么备件graph报警对应工序的备件清单需要 XX 型号滤芯及密封圈公司附近的餐饮优惠chat不召回直接对话无这个表看起来简单但价值极高。每次调完切块参数、换 embedding、改路由规则都跑一遍对比“这版对几个、错几个”。十次迭代下来你会有一种“捏着数据做优化”的安全感而不是靠玄学调参。评估集建好之后建议存成 JSON 或 CSV纳入版本管理每次改动系统都留一个评估记录方便回溯到底哪次改动提升了效果。7. 分水岭六生成与答案治理防止一本正经胡说八道7.1 Prompt 与上下文压缩最后一道分水岭在生成端。哪怕前面检索做得很好如果 Prompt 不会调答案照样翻车。首先上下文不是越多越好。我见过有人把 10 个 chunk 全塞进去结果模型在无关信息里挑挑拣拣挑出个片面的答案。正确思路是先压缩再生成只保留与 query 明显相关的句子去掉背景、重复、无关实体。你也可以在 Prompt 里明确告诉模型“输出只能依据以下材料如果材料不包含答案直接说无法回答”。Prompt 里放哪些内容也很关键。我的固定套路是先放任务定义再放检索到的证据每段证据标注来源章节最后放用户问题。顺序错了效果会差很多因为模型对靠后的指令更敏感把用户问题放最后更能聚焦答案方向。这里有个小技巧在证据段落前加上“以下是知识库检出的参考片段它们可能相关也可能无关请自行判断”这句话看起来多余但能给模型一个“批判性使用材料”的暗示减少机械照搬导致的错误。7.2 引用、校验与幻觉兜底答案治理还包括引用溯源。生产环境里我强烈建议答案里的每个关键结论带上来源编号。这样用户能看到“这条依据来自《设备手册》第三章第 2 节”一旦发现错误也方便排查是证据问题还是模型理解问题。引用不只是用户体验更是一条调试链路。还有一个容易被忽略的操作设置“拒答”路径。很多 RAG 系统幻觉高发是因为模型在自己都不知道的情况下生成了答案。给 Prompt 加一条“材料不足时请回答‘知识库中未找到相关信息’”并将召回分数低于阈值的情况单独拦截直接走兜底话术能显著降低一本正经胡说八道的概率。我把它称为答案治理的守门员。别看这个设定简单它能让错误从“编造”变成“坦白”用户体验完全不同。8. 避坑实录从 Mac 搭建到图片需求那些事8.1 Mac 本地搭建 RAG 的关键很多人问我怎么在 Mac 上搭 RAG 知识库特别是没有 GPU 的情况下。其实现在本地搭一套最小系统不难用 Ollama 跑 embedding 和 chat 模型用 Chroma 或 Qdrant 做向量库用 LangChain 或 Dify 串流程。M 系列 Mac 跑 7B、8B 参数量级的模型完全没问题速度虽然比云端慢但做实验足够。我踩过最大的坑是 embedding 模型和中文字符。早期用某些英文优化模型处理中文召回效果惨不忍睹。后来换成了对中文友好的 embedding 模型并统一在入库前做文本清洗和同义归一效果立竿见影。Mac 上另一个问题是内存占用量切块大的时候嵌入一批长文档很容易把内存吃满。我的习惯是先小批量入库观察内存水位再逐步放大 batch。如果内存实在吃紧可以把 embedding 模型换小一点或者用 API 方式做向量化本地只负责存储和检索。8.2 知识库能不能存图片我试过的结果最近总有人问 RAG 知识库能不能存储图片。我直接说结论传统 RAG 流水线不能直接把图片塞进文本向量库但可以通过两个方向实现图片能力。一是提取图片里的文字用 OCR 转成文本再进入知识库适合截图、扫描件、表格图片。二是为图片单独建立视觉向量检索图片本身而不是文本再配合多模态模型生成答案适合设计图、产品图这种“看图说话”的场景。所以答案是“能但不是把图片和文本混在一个 chunk 里而是分索引、分流处理”。我在一个售后知识库里处理过大量设备照片和解说截图做法是 OCR 文本进一个向量索引图片原图单独存对象存储并保留链接生成答案时带上“相关图片链接”字段。用户体验很好也避免了多模态模型对每张图都读一遍的高延迟。如果你要处理的是图文混排的 PDF建议先按页面把图文关系保留再决定哪些内容走 OCR 文本、哪些图片走视觉模型这个设计比“整页塞进模型”可控得多。8.3 常见问题速查表我把几个真实项目里反复被问到的问题整理一下给后面的人少踩几个坑。现象可能原因处理建议召回文件都对但答案不相关生成的上下文里混入了无关 chunk做重排上下文压缩减少喂给模型的噪声换一种问法就查不到依赖单一向量检索加入 BM25向量混合召回制度版本总是回答老版缺少时间元数据过滤给 chunk 打生效日期检索时按版本过滤答案给得很完整但全在编没有做引用与拒答约束加事实校验、来源标注与“无法回答”兜底本地 Mac 跑得慢模型大或 batch 太大换小参数模型或在入库时用分批并限制并发用户问“图片里写了什么”答不出没有 OCR 或视觉索引单独接 OCR 管道或按需调用多模态模型这张表不是万能药但它对应的每一个问题我都亲眼见过有人在生产环境里踩过。RAG 的水很深但只要你顺着“知识表示、查询理解、索引设计、检索重排、评估闭环、答案治理”这六个分水岭逐项检查就大概率能定位到问题出在哪个环节。我在做第一个 RAG 项目的时候也天真地以为“搭好流水线就算完事”后来被用户一连串“这还是不对”的反馈硬生生逼着把六个环节逐个啃了一遍。现在回头看那些能在生产环境里稳定输出的 RAG 系统没有一个是在流水线层面胜出的全部赢在流水线之外的各种脏活累活上。前面这套经验如果你能照着梳理一遍至少可以少走几个月弯路。最后再提醒一句无论用什么框架起步一定要把“好问题、好证据、好评估”这三件事想清楚流水线反而最不需要担心。