做检索增强生成RAG有一段时间的朋友应该都有类似体验文档一切、向量一存、召回一跑demo阶段效果惊艳一上真实业务就“翻车”。最典型的翻车是模型一本正经地引用了一段完全不相关的内容或者把两段来自不同章节的文字缝在一起生成一个看起来合理但事实完全不存在的答案。我之前在做一个企业内部知识库问答系统时就被这类问题折磨了很久。后来把架构从“单一向量库”改成“结构化知识条目原始切片”的双层RAG效果才算真正稳住。这篇文章就把这套方案的思路、落地细节和踩坑记录完整写出来给正在做RAG或者准备改造RAG架构的朋友一个参考。双层RAG这个方案的核心并不复杂第一层用结构化知识条目实体、属性、关系、限定条件锁定答案范围第二层在锁定范围内用原始切片提供证据和上下文。两层互补一层保证“对”一层保证“全”。它解决的也不是什么高深问题而是单一向量库最容易翻车的三个痛点事实漂移、粒度错配、不可解释。下面我分几个部分拆开讲包括为什么单一向量库会失效、双层RAG怎么设计、知识条目怎么建、检索流程怎么落、效果怎么测以及我自己踩过的坑。1. 单一向量库为什么会“失灵”三个真实翻车场景在讲双层RAG之前我先把单一向量库方案的失效场景说透。不是单一向量库完全不能用而是它在真实业务中有一批“结构性缺陷”这些缺陷不是调参能解决的需要从架构层面补。1.1 事实漂移语义相近但事实不同单一向量库最大的问题是它把文本里的“事实信息”和“语义信息”混在一起编码了。向量空间里距离近的文本不一定事实一致。举个我真实遇到的例子知识库里同时有“A型号设备的最大载荷是10吨”和“B型号设备的最大载荷是10吨”两句话的向量距离非常近。用户问“A型号最大载荷多少”向量召回可能把这两段都捞回来甚至因为B段文字更长、上下文更全B段排在前面。最终生成的答案就变成了“A型号的最大载荷是10吨来自B设备文档”——模型没有能力在生成时判断这段引用是否匹配A设备。这就是事实漂移。模型不是在编造它是被检索结果带偏了。根本原因是向量检索只保证“语义相似”不保证“实体一致”。而在知识问答场景里用户问的是具体实体必须保证答案来自该实体的资料。1.2 粒度错配一个问题对应多个切片切片之间没有主次文档切块chunk是单一向量库方案里最纠结的参数。切大了检索精度下降召回一个超长段落里面话题混杂模型抽取答案时容易抽到无关内容切小了上下文断裂一个完整事实被拆成两块检索只中了其中一块另一块丢失答案自然不完整。举个例子。一份产品FAQ里某个条目写着“产品X支持10种协议其中协议A用于工业场景协议B用于农业场景协议C为私有协议”。如果按固定512字切块这句话可能被切到两个块里。用户问“产品X支持哪些协议”向量召回往往只命中包含“协议A”的那个块模型回答时就只列协议A和协议B漏掉协议C。这就是粒度错配用户的问法对应的是“这个实体的问题描述全集”但文档被切成了“碎片”没有一个碎片能代表完整的答案。1.3 不可解释业务方追问“你凭什么这么答”时你没法回答单一向量库的检索结果是一堆“相似文本”相似不代表依据。业务方尤其是做审核、合规、医疗、法律这类领域的会追一个问题这个答案的依据是什么在哪个文档的哪一段单一向量库能返回原始切片但它返回的是“语义相似的片段”而不是“逻辑上支撑这个结论的知识单元”。比如问“A设备超过质保期维修收费吗”答案应该是“超出质保期维修收取人工费材料费具体参考合同条款2.3”这是一个知识单元条款而不是一段相似文本。单一向量库没有“条款”这个结构化概念它只有“文本块”。我后来的体会是如果只是做“文档内容问答”单一向量库够用但如果是做“知识问答”也就是答案是某个既定知识、规则、条款的查询单一向量库在架构上就有先天缺陷。这也是双层RAG能补上的地方。2. 双层RAG的设计思路用“骨架血肉”替代“一张大网”我落地的那套双层RAG思路其实是从一个生活场景里来的。你去图书馆借一本书不是直接跑到书架前去逐本翻而是先去查图书目录卡片确定这本书在哪个书架、属于哪个分类再根据书目信息找到具体位置翻开对应页码。这就是两层检索先定位再细读。2.1 第一层结构化知识条目负责“定位”第一层检索的对象不是文本切片而是知识条目——也就是把文档里的事实抽成结构化的“实体-属性-值”或“实体-关系-实体”三元组再配上一些关键限定条件。还是用设备维保的例子从文档里抽取出来的知识条目是这样的实体设备A型号属性最大载荷值10吨来源产品规格书-第3章版本V1.2生效时间2024-01-01用户问“A型号载荷是多少”系统先去匹配“实体设备A型号”和“属性最大载荷”直接锁定到这一条知识条目。这条条目本身就可以作为答案骨架值是10吨来源是规格书第3章。这一步不需要语义向量用结构化的精确匹配就能做到完全避免实体漂移。2.2 第二层原始切片负责“证据供给”第一层锁定了知识条目但知识条目本身是抽出来的上下文信息被压缩了。比如条目里“最大载荷10吨”背后还有测试条件、备注限制“测试条件下测得的极限值”这些上下文在结构化条目里会丢失。所以需要第二层以知识条目命中的实体/属性作为锚点回到原始文档切片里把包含该实体和该属性的那一段切出来作为证据上下文喂给大模型。这层要的是“原文证据”不是“相似文本”是严格围绕知识条目展开的“定向切片”。两层合起来的效果是第一层保证“答案指向正确”第二层保证“生成依据充分”。模型拿到的prompt是“知识条目原始切片用户问题”三件套它的任务是“基于知识条目的结论参考原始切片的内容生成自然语言回答”。2.3 为什么比单一向量库好用两类错误同时被压住单一向量库有“召回不准确”和“生成没依据”两类问题。双层RAG在架构上同步解决召回不准确由第一层结构化匹配兜底。实体、属性、限定条件这些用精确/规则/弱语义匹配方式处理不会出现“A设备的答案引用了B设备文档”的问题。生成没依据由第二层定向切片兜底。原始切片是“根据知识条目回查”得到的不是“根据问题语义相似度”得到的天然和答案结论对齐。说白了双层RAG的本质是把“一次模糊检索”拆成“一次精确消歧一次定向取证”。前者负责解决“用户到底在问哪个实体、哪个属性”后者负责解决“回答时应该看哪几段原文”。这一步拆解之后整个RAG的可靠性上限高了一个量级。3. 结构化知识条目的构建从非结构化文本到知识条目的落地细节双层RAG的基础是第一层的知识条目。条目抽不好后面全白搭。这一节我把构建流程、存储选型、校验手段完整讲一遍。3.1 抽取哪些内容实体、属性、关系、限定条件一个都不能少做RAG的人容易把“知识抽取”等同于“实体抽取”但实际只抽实体是不够的。我抽的字段分四类实体Entity用户问题里有明确指称的对象。设备型号、人名、产品名、部门名、合同编号、条款编号等。属性Attribute用户会查询的内容维度。载荷、质保期、价格、责任人、审批流程、处罚标准等。值Value属性对应的具体答案。10吨、3年、800元、张三、需经两级审批等。限定条件Condition和值绑定的一些约束。生效时间、适用地区、版本、规格、测试条件等。为什么限定条件必须抽因为在真实文档里知识几乎都是带条件的。同样一个设备载荷空载和满载测试条件下的数值不同同样一个质保条款在保内和保外的结论不同。不抽限定条件知识条目就变成了“断章取义”的源头。抽取方式我做过三种对比纯手工、纯LLM大模型、LLM规则校验。实测下来纯LLM速度快但会有幻觉纯手工精度高但维护成本不可承受最后用的方案是LLM在字段级做抽取输出JSON结构然后套两层规则校验第一层是JSONSchema校验第二层是关键字段完整性校验实体、属性、值必须非空。校验不通过的知识条目会进入人工复核队列不在线上生效。3.2 存储选型图数据库不是必须的别为了“高级”而高级不少文章一写知识条目就上图数据库。但我在实际项目里发现知识条目的查询模式并不多大部分场景是“实体属性限定条件”的精查少数场景是“实体关系”的图遍历。如果业务里没有“多跳关系查询”这样的需求上Neo4j/JanusGraph反而是负担——多一个组件多一份运维而且答案速度还被图查询拖慢。我的建议是分两级条目数量在十万级以下用关系型表存储就够了。一张表存条目id、实体、属性、值、限定条件JSON、来源文档id、版本、状态、时间戳。再加一张向量表专门存“实体属性”的组合语义向量用来处理用户问法和文档写法不一致的情况比如文档里写“承重能力”用户问“载重限额”。条目数量到百万级、且确实需要多跳关系推理时再上真正的图数据库。图数据库的“多跳路径”能力在风控、合规审查这类场景里才有价值。表结构设计时可以加一个“置信度”字段值在0到1之间表示抽取结果的可信程度。这个置信度后续在排序时有用两层检索结果融合时结构化条目的置信度越高整体排序权重越大。3.3 校验机制不靠谱的知识条目比没有知识条目更可怕知识条目是“答案骨架”骨架错了后面怎么补都歪。我在项目里前后被知识条目的三个问题坑过抽取幻觉LLM把原文里没有的信息提炼成了条目。这种最常见比如把文档里的“建议载荷不超过8吨”抽成“最大载荷8吨”。字段串位把属性值填错了。比如把质保期3年填到价格字段。上下文丢失不问条件抽出来的条目过于绝对。解决这些问题的核心是“抽取后校验”。校验分两层第一层原文回查校验。抽取出的知识条目必须能从某一段原始文本中定位到对应描述否则丢弃。这层用“文本蕴含”判断模型完成输入是“假设设备A最大载荷8吨前提原文第3章第2节‘A设备建议载荷不超过8吨极限测试可达10吨’”输出是“是否蕴含”。不蕴含的直接进人工队列。第二层冲突检测。同一实体同一属性如果存在多条内容冲突的条目一个说8吨一个说10吨说明文档本身或抽取过程有问题。这种冲突条目不会自动失效而是标记成“待确认”进人工仲裁。这个机制看起来简单但救了我好几次。3.4 知识条目的更新与版本管理规则类知识半年内就会过期知识库是活的东西。企业的知识条目平均每月有10%到15%会发生变化。我的做法是给每一条知识条目加三个时间字段生效时间、失效时间、版本号。当前查询只返回“生效时间 now 失效时间”的条目。老版本不会删除会保留历史版本用于审计和追踪。文档重新解析后新版本条目生效旧版本进入“历史”状态。这个设计在业务上极其重要。比如用户问“2023年与2024年的报销标准分别是什么”只有版本管理能做到“按时间维度查询”。单一向量库对这个场景基本无能为力——它在切完块之后完全没有“时间版本”的概念。4. 原始切片层的索引构建与双层检索流程实现知识条目建好之后第二层原始切片和整个检索流程的接续就得重点处理。这一节是工程实现的核心部分我把索引策略、检索步骤、融合排序三个方面完整拆开讲。4.1 原始切片策略固定切块不是不行但要为知识条目服务第二层切片的主体是原始文档但切片方式要考虑“能为第一层服务”。我试验过三种方案固定窗口滑切简单但容易切断句群使得第二层回查时找不到完整上下文。语义边界切分用段落、标题级别去切能保住句群完整性但对长文档没有统一粒度。句子级归属先把文档切成句子再把每个句子映射到它所属的章节、段落和文档。检索时不直接搜句子而是搜“以句子命中的段落块”。最终我采用的是“语义块为主句子级索引辅助”。具体做法先把文档按Markdown标题、段落边界切出“父块”平均约800字再把每个父块内部切成“子块”平均约200字。父块用来做第二层的上下文返回子块用来做检索定位。用户问题时先在子块上做向量检索找到命中子块后返回它所属的父块作为证据上下文。这样既保证了命中粒度又保证了上下文完整度。4.2 双层检索流程一个问题的完整旅程完整流程我拆成六个步骤这样便于调试也便于向业务方解释用户问题进行实体识别。这一步用轻量实体识别模型抽取出用户问句里的实体名和属性词。注意不是随便做NER而是只识别知识条目库里存在的实体和属性这一步是之后第一层匹配能精确的原因。第一层结构化匹配。用实体名查询索引表再结合属性词命中具体条目。如果用户问“A设备载荷”查询的就是实体“设备A型号”属性“最大载荷”直接精确匹配不涉及向量。如果第一层匹配失败进入降级方案用实体名属性词做向量召回找到知识条目索引上的候选。这里的向量召回是“实体与属性的组合”不是原文切片是处理用户问法和文档写法不一致的兜底。第一层命中后获取知识条目上的“来源文档id章节定位”然后进入第二层。这一步是把条目作为锚点去定位原始文档中的相关片段而不是用向量搜索全库。第二层定向检索。在锚点锁定的文档范围内用子块级向量检索找和“实体属性”语义最匹配的切片取回对应的父块作为证据上下文。这个检索范围已经从全库缩到“该知识条目来源的文档/章节”精度高很多。融合生成。把知识条目JSON、原始切片文本、用户问题拼成给大模型的Prompt让模型基于条目结论生成答案并用切片文本补充细节和背景。这个流程里最关键的是第4步“用条目定位文档”。这一步让检索范围从全库级别缩小到文档块级别检索精度和效率同时得到提升。4.3 融合排序两层结果不是各算各的而是要算总分有的双层RAG实现是“先看第一层结果再调第二层”但实践下来如果两层结果各自独立排序再简单拼在一起会出现一个问题第一层条目模糊命中第二层切片高相似整体回答被高相似的切片带偏。我的处理方法是设计一个综合排序分数把两层的匹配质量统一起来第一层得分结构化匹配得分实体精确命中的权重最高0.6属性语义匹配的权重中等0.3限定条件匹配的权重低0.1。实体一定要精确否则会重复出现“问A答B”的问题。第二层得分切片相关性得分调用的就是子块向量的余弦相似度但要在限定范围内计算。综合得分 第一层得分×0.7 第二层得分×0.3如果第一层命中。如果第一层未命中只走第二层的普通向量检索此时综合得分直接使用第二层得分但会乘以0.6的降权系数让系统更倾向使用结构化命中的结果。这组权重不是拍脑袋的我用小验证集做了几轮搜索调参最终固定成0.7/0.3。核心逻辑是第一层精确命中要覆盖第二层高相似噪声的影响宁愿第二层相似度略低也要保实体准确。4.4 触发器优化某些问题不需要走完整双层流程不是每个问题都要走完整流程。我在实际落地时加了几条触发规则来优化成本和延迟如果用户问题是“实体单个属性”的简单查询第一层已经能直接给出完整条目且置信度高于0.9可以直接跳过第二层只把条目里的来源信息作为引用来源。如果用户问题是“比较型”进入by对比词等不走条目方式走切片方式并拼上对照文档的相关片段。如果第一层回收实体为空整个结构化层直接跳过退化为纯向量检索。这样做的原因很简单结构化条目可能是“结论”但没有切片证据时回答的可用信息量是够的。而如果碰到复杂比较、综合归纳类问题结构化条目反而不够用切片是更合适的上游材料。触发器先判断问题类型再决定走哪条路线。5. 实操对比双层RAG和单一向量库的效果差多少架构讲完直接上效果对比。我自己做了一套小规模评测集专门用来观察两种方案的差异。5.1 评测集搭建三类问题混合着测评测集包含200条由业务人员清洗后的问题分为三类事实单查类120条此类问题对实体和属性有明确指向从文档里能找到精确答案。规则限定类50条此类问题存在限定条件答案需要结合版本、时间、规格等条件判断。综合归纳类30条此类问题需要从多个文档片段中梳理要点适合测上限。评测标准有三个维度事实准确率答案和知识库标准答案一致的比例、依据相关性生成的答案和给出的引用文档片段内容是否相关、完整度答案是否把关键限定条件都包含了。基于这套评测集我们用同样的文档库跑了两套管线。5.2 指标结果与归因分析三类问题的平均结果是这样的事实单查类单一向量库准确率约76%双层RAG约93%。18个百分点的差距基本来自实体混淆和切片粒度丢失。规则限定类单一向量库准确率约41%双层RAG约82%。差距最大条件是单一向量库最薄弱处。综合归纳类单一向量库约67%双层RAG约70%差异不大。这类问题对两套方案的挑战在本质上差不多。归因很清晰双层RAG提升最明显的场景是“问题精度高知识答案确定”的业务比如客服知识问答、政策条款问答、设备参数咨询。它比较不擅长的场景是开放式的“文档综述”类问题后者依旧需要检索策略上的调整。5.3 成本与延迟代价加一层值不值改造成双层RAG最直接的问题是成本多了知识抽取、结构化存储、两轮检索。我说一下实测数据知识构建成本离线抽取2000份文档条目抽取大概用8000次LLM调用也就是几千元左右之后增量更新每次约几百次调用。查询延迟单轮问答从1200ms增加到1700ms左右增加的部分主要在第一层实体识别和条目匹配这部分通常可以在1秒内查完。索引占用多了一张结构化索引表和一张实体-属性向量表整体占用比单一向量库增加15%到20%。取舍上我的经验是如果业务场景是“宁可慢一点不能答错”的加层非常值得但只要做的是档泛泛的段落问答成倍增加的成本并不划算。5.4 适用边界不是所有RAG场景都该上双层做技术选型最忌讳“拿着锤子找钉子”。根据我的实测双层RAG适合的场景至少满足以下三点之一问题类型高度集中大多数是“实体属性条件”的知识查询答案对事实性有硬要求错一处就可能引发业务风险知识库有大量实体同名、属性交叉的文档必须要能做实体消歧。反之如果知识库只是一些随笔、会议纪要、技术博客用户提问也开放多变那这种场景“单层向量检索微调Prompt”反而更能保召回率。6. 踩坑记录双层RAG落地过程中的几个高频问题理论设计和离线评测都过了上线之后才是真正磨人的阶段。这里把我在实时环境里碰到的高频问题列出来都是真实断断过的坑。6.1 第一层命中和第二层切片“打架”第一层锁定了一个版本的参数A第二层定向切片时切出来之后却混入了另一个文档别名下的参数B。原因大多出现在“同义词没对齐”。解决手段是给实体建立别名表把“A型号”“A设备”“产品A”在该入库时都归并到同一规范实体名上。规范在查询和检索时统一做归一化旧名直接替换成规范名。6.2 抽取的内容“对”但属于无效条目有些知识条目在结构上是完全正确的比如“售后服务热线400-xxx”,可是用户问“怎么联系售后”这类条目却可能没被召回因为用户问题里没有出现任何实体名。我们的应对是给部分条目加“高频问法关键词”字段从线上日志里提取用户的常见问法匹配到对应条目上。这种做法本质上是在结构层之外补了一层“口语化表达索引”。6.3 增量更新导致第一层有条目第二层切片还没覆盖新文档入库时知识条目已经生成但原始切片索引还在异步构建中用户会遇到“有答案却没引用”的情况。处理逻辑是第二层在指定范围内搜索不到切片时并不直接失败而是将知识条目本身作为依据返回并提示“依据知识库条目信息”。同时提醒后台切片索引进度同步完成后自动补正回复内容。6.4 时间条件没进筛选旧规则盖过新规则知识条目带了生效时间和失效时间但在某些用户的问句中时间条件跟得很自然比如“我们2022年的报销标准是”。一开始那版系统没做时间识别导致新条目盖住了旧条目。完善做法是唤醒时从用户问题里识别绝对年份识别完成后在结构化匹配时就先按这一年份过滤生效条目如果问句里没有明显的年份限定才用“当前有效”的默认条件。6.5 综合归纳类问题把双层走成“两截”双层流程天然更适合精确问答但综合类问题一多模型常常把“第一层的条目”和“第二层的切片”拼得上下文不连贯。我后来在Prompt模板里明确写了生成规则优先根据条目下结论再引用切片补充限定与说明不要直接把切片全文贴给用户。同时把切片里和主题无关的段落提前过滤只保留关联度高的句子。这样处理后综合问题的回答质量大幅上升。有一个值得提醒的细节知识库的知识更新不是一次性的而是持续的。在持续迭代流程里第一层结构化的最大价值会自动涌现当某一条规则被修正时你只需要修改那一个实体属性对应的条目并且重新定位相关文档切片而不是重新切全库、重算全库向量。这是单一向量库做不到的。无论做哪一层都要在架构设计上第一时间把“来源文档标识”带上它既是后续定位切片的前提也是追踪知识来源的依据。到目前为止我仍然在持续演进这版双层RAG主要思路集中在第三层“知识路径扩展”比如让多个知识条目之间自动生成关联路径从“单点查询”走向“链式推理”。但要提醒还在观望的朋友架构永远为业务服务。如果你的问题大多是开放文本摘要类单层的快和简单就是优势。可一旦你所在的业务对答案的“确定性”有硬性要求结构化知识条目原始切片的双层架构大概率是你绕不开的一条路。
