1. 为什么单层向量库开始不够用了做过 RAG 的人大概都有过这种体验demo 阶段效果惊艳一上真实业务就露馅。用户问“A 产品和 B 产品在保修政策上有什么区别”单层向量库检索回来的全是分别讲 A 和 B 的独立切片模型拿到一堆碎片要么答非所问要么把两边的政策张冠李戴。问题不在于 embedding 模型不够强而在于检索的粒度和知识的组织方式从一开始就没设计对。我最早做知识库问答的时候也是清一色的“文档切块 → 向量化 → 存库 → 相似度召回”这套标准流程。切片大小试过 256、512、1024重叠窗口调了又调embedding 模型从早期的通用模型一路换到后来的榜单前排选手效果确实有提升但始终卡在一个天花板上。后来复盘才发现向量检索擅长的是“语义相似”而不是“逻辑精确”。它能找到“意思相近”的文本但很难保证找到的是“回答问题所必需的那一条完整知识”。举个具体的例子。假设知识库里有一条结构化信息“退款到账时间审核通过后 3-7 个工作日”。如果这条信息被切成了“审核通过后 3-7 个”和“工作日到账”两个切片用户问“退款多久到账”向量检索可能只召回其中一个模型就得靠猜。更麻烦的是当知识库里有几十条类似的时效类信息时向量检索很容易把“发货时效”“退款时效”“换货时效”混在一起召回因为它们语义上高度相似。双层 RAG 的思路就是在这个背景下冒出来的。它的核心主张很朴素让结构化的归结构化让非结构化的归非结构化。具体来说就是把知识库拆成两层——上层是人工或半自动抽取的“结构化知识条目”下层是原始的文档切片。检索的时候两层同时发力结构化条目负责“精确命中”原始切片负责“补充上下文”。这套组合拳打下来实测在时效类、政策类、参数类问题上准确率比单层向量库高出一大截。这篇文章我会把双层 RAG 的完整设计思路、落地步骤、参数选择、踩坑经验全部摊开讲。不管你是刚接触 RAG 的新手还是已经被单层向量库折磨过的老手都能从中找到可以直接抄作业的东西。核心关键词我会在行文中自然带出双层 RAG、结构化知识条目、原始切片、向量库、Embedding以及最近大家讨论比较多的 embedding 模型排行和 embedding 模型选型问题。2. 双层 RAG 的整体架构与设计逻辑2.1 两层结构各自负责什么双层 RAG 的第一层叫结构化知识条目层。这一层存的不是原始文本而是从文档中抽取出来的、经过归一化处理的“知识原子”。每条知识条目通常包含几个固定字段主体比如产品名、政策名、属性比如时效、价格、条件、值比如 3-7 个工作日、来源指向原始文档的哪一段。这些条目可以存在关系型数据库里也可以存在支持结构化过滤的向量库里甚至用 JSON 文件管理都行关键是字段清晰、可精确匹配。第二层叫原始切片层也就是我们熟悉的向量库。文档按一定策略切块、embedding、入库负责语义召回。这一层保留的是原文的完整表达包括上下文、限定条件、例外说明等。它的优势是覆盖面广、语义泛化能力强劣势是精确性不足。两层的关系不是主从而是互补。结构化层解决“找得准”的问题原始切片层解决“找得全”的问题。用户提问后系统先尝试从结构化层精确命中命中后再去原始切片层拉取相关上下文如果结构化层没命中就退化为纯向量检索保证兜底能力。2.2 为什么不是“结构化 向量”简单拼接有人可能会说那我直接在向量库里加 metadata 过滤不就行了比如给每个切片打上“产品名”“文档类型”的标签检索时先过滤再相似度排序。这个方案在小规模场景下确实能用但它有两个硬伤。第一metadata 过滤是“硬过滤”。一旦过滤条件设错比如用户问的是“A 产品的退款政策”但 metadata 里标的是“售后政策”过滤就把正确结果排除了。而结构化条目层做的是“软匹配”它允许属性字段有一定的模糊性比如“退款时效”和“退款到账时间”可以映射到同一个属性上。第二metadata 过滤解决不了“值”的精确匹配。用户问“哪些产品支持 7 天无理由退货”metadata 只能告诉你哪些切片属于“退货政策”类但没法直接告诉你“7 天”这个值。结构化条目层可以把“7 天”作为独立字段存下来支持范围查询、精确查询、排序等操作。这是向量库做不到的。所以双层 RAG 不是简单的“结构化 向量”而是两套检索逻辑的协同。结构化层负责“点”原始切片层负责“面”点面结合才能既准又全。2.3 适用场景与不适用场景双层 RAG 最适合的场景有几个特征知识库里有大量时效、价格、参数、条件、政策类的信息用户提问经常涉及精确数值或明确条件业务对回答的准确性要求高于流畅性。典型的比如电商客服、金融产品咨询、企业内部制度问答、医疗指南查询等。反过来如果知识库主要是散文、故事、观点类内容用户提问也偏开放式的“聊聊 XX”“介绍一下 XX”那双层 RAG 的收益就不明显单层向量库加一个好的 embedding 模型可能就够了。因为这类场景本来就不追求精确匹配语义相似度才是核心指标。还有一个不适用的情况是知识库规模极小比如只有几十个切片。这种情况下人工维护结构化条目的成本可能比收益还高不如直接上单层方案把精力花在 prompt 优化上。3. 结构化知识条目的抽取与建模3.1 从文档到条目的抽取流程结构化条目的来源有两种一种是人工标注适合知识库规模不大、准确性要求极高的场景另一种是模型抽取适合大规模知识库但需要人工抽检和修正。我实际项目中用的是混合方案先用模型批量抽取再人工审核关键字段。模型抽取的 prompt 设计很关键。我的做法是给模型一个固定的 schema让它按字段填充。比如{ 主体: 产品名或政策名, 属性: 时效/价格/条件/范围, 值: 具体数值或描述, 单位: 天/元/次, 限定条件: 适用前提, 来源切片ID: 对应原始切片的唯一标识 }模型抽取完后我会做一轮归一化处理。比如“3-7 个工作日”“三到七个工作日”“3~7 工作日”统一成“3-7 工作日”“免费”“不收费”“0 元”统一成“0 元”。归一化做得好不好直接决定后续精确匹配的召回率。3.2 属性字段的设计原则属性字段是结构化条目的核心。设计得好检索效率翻倍设计得差还不如不做。我的经验是遵循三个原则。第一属性要“正交”。也就是说不同属性之间尽量不要有重叠含义。比如“退款时效”和“到账时间”如果都存检索时就得处理同义问题。更好的做法是合并成一个属性“退款到账时效”在值里区分“审核后”和“到账后”。第二属性要“可枚举”。理想情况下一个知识库里的属性字段应该收敛到一个可控的集合比如 20-50 个。这样检索时可以用分类模型先把用户问题映射到属性上再去匹配值。如果属性字段无限膨胀结构化层的优势就没了。第三属性要“带单位”。时效类带“天/小时”价格类带“元/美元”数量类带“个/次”。单位单独存一个字段方便做单位换算和范围查询。3.3 条目与原始切片的关联方式每条结构化条目都必须能追溯到原始切片。我的做法是在条目里存一个source_chunk_id指向向量库里对应的切片。这样当结构化层命中一条条目后系统可以顺着 ID 去向量库拉取完整上下文交给模型生成回答。这个关联关系是双向的。原始切片入库时也会在 metadata 里记录它被哪些结构化条目引用。这样当切片更新时可以反向找到受影响的条目触发重新抽取。没有这层双向关联知识库一更新就容易出现“条目和切片对不上”的问题。4. 原始切片层的切分与向量化策略4.1 切片大小的选择逻辑切片大小没有万能答案但有一个判断标准切片要能独立表达一个完整意思。如果切完之后的片段需要依赖前后文才能理解那这个切片就是失败的。我的实测经验是中文技术文档和政策文档512 字符左右是一个比较稳的起点。太短了语义不完整太长了向量会稀释关键信息。但这不是绝对的具体要看文档类型。比如 FAQ 类文档一问一答天然就是一个切片不用强行切而长篇制度文档可能需要按章节切再在章节内按段落切。重叠窗口我一般设10%-20%也就是 512 的切片配 50-100 字符的重叠。重叠的目的是防止关键信息正好落在切分点上被切断。但重叠也不能太大否则向量库里会有大量重复内容检索时召回一堆相似切片反而干扰排序。4.2 Embedding 模型的选择与排行参考Embedding 模型的选择直接决定向量检索的上限。最近 embedding 模型排行变化挺快但选型不能只看榜单得结合自己的业务场景。我的选型逻辑是这样的先看语言支持中文场景必须选中文语料训练充分的模型再看维度维度太高存储和检索成本大太低表达能力不足768 或 1024 维是比较常见的平衡点最后看榜单表现但榜单只能作为参考最终一定要在自己的业务数据上做 A/B 测试。我试过的一个实用方法是从知识库里抽 100 条真实用户问题人工标注正确答案对应的切片然后用不同 embedding 模型跑召回率。哪个模型在这 100 条上召回率高就用哪个。这比看任何榜单都靠谱。还有一个容易被忽略的点是embedding 模型的一致性。入库时用的模型和检索时用的模型必须是同一个否则向量空间不对齐检索结果会完全乱掉。如果中途要换模型必须全量重新 embedding不能只换检索端。4.3 向量库的选型与索引配置向量库的选择主要看三个维度规模、延迟、过滤能力。小规模百万级以下用 FAISS 或 Chroma 就够了部署简单中大规模千万级以上考虑 Milvus、Qdrant 这类专业向量库如果已经有 Elasticsearch 集群用它的向量检索功能也能凑合但性能和专业库有差距。索引配置上HNSW 是目前比较主流的选择召回率和速度平衡得比较好。关键参数是M和efConstruction。M控制每个节点的连接数越大召回率越高但内存占用越大一般设 16-64efConstruction控制建索引时的搜索深度越大索引质量越高但建索引越慢一般设 100-500。检索时的efSearch参数可以动态调要求高召回就调大要求低延迟就调小。5. 双层检索的协同与融合策略5.1 查询路由先走哪一层用户提问进来后第一步是查询路由。我的做法是用一个轻量分类模型或规则引擎判断这个问题是“结构化可回答”还是“需要语义检索”。判断依据主要是问题里有没有明确的实体和属性。比如“A 产品退款要几天”里有实体“A 产品”和属性“退款时效”这就是典型的结构化可回答问题。而“你们家的售后服务怎么样”没有明确属性更适合走语义检索。路由不是二选一而是优先级。结构化层先查命中且置信度高就直接用命中但置信度低就把结构化结果作为过滤条件再去向量库做语义检索完全没命中就纯向量检索兜底。5.2 结果融合与重排序两层都返回结果后需要做融合排序。我的做法是给每个结果算一个综合分结构化条目的精确匹配给高分向量检索的相似度分做归一化后加权。权重怎么定看业务。如果业务对准确性要求极高结构化权重调高如果对覆盖面要求高向量权重调高。重排序还有一个实用技巧用交叉编码器做精排。把用户问题和候选切片一起输入交叉编码器输出相关性分数。这一步比向量相似度准得多但计算量大只适合对 top-20 左右的结果做精排不适合全量。5.3 上下文组装与 prompt 设计检索到的内容最终要组装成 prompt 交给生成模型。我的组装顺序是结构化条目在前原始切片在后。结构化条目用表格或列表形式呈现清晰列出主体、属性、值原始切片按相关度排序附上来源信息。Prompt 里我会明确告诉模型“优先使用结构化条目中的精确信息回答原始切片仅作为补充上下文。如果结构化条目和切片内容冲突以结构化条目为准。”这句话很关键能有效防止模型被切片里的模糊表述带偏。6. 实操落地从零搭建一个双层 RAG6.1 环境准备与依赖安装先列一下我用的技术栈都是比较成熟的开源方案文档解析unstructured或pypdf看文档格式切片自己写规则或用langchain的 splitterEmbedding选一个中文表现好的模型本地部署或调 API向量库小规模用chromadb中大规模用qdrant结构化存储sqlite或postgresql生成模型任意一个指令跟随能力强的模型安装依赖pip install unstructured pypdf langchain chromadb qdrant-client sentence-transformers如果要用本地 embedding 模型sentence-transformers是标配。模型文件提前下载好避免运行时卡在下载上。6.2 文档解析与切片实操文档解析这一步坑最多。PDF 里的表格、页眉页脚、多栏排版解析出来经常是乱的。我的经验是能拿到原始格式就别用 PDF。如果是 Word 或 Markdown直接读如果是 PDF优先用带版面分析的解析器实在不行就人工清洗一遍。切片代码示例from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap80, separators[\n\n, \n, 。, , , ] ) chunks splitter.split_text(document_text)separators的顺序很重要优先按段落切再按句子切最后才按字符切。这样能最大程度保证切片语义完整。6.3 结构化条目抽取的 prompt 模板抽取 prompt 我打磨了好几版下面这版是实测比较稳的你是一个知识抽取助手。请从以下文本中抽取结构化知识条目。 文本 {chunk_text} 请按以下 JSON 格式输出每个条目包含 - 主体产品名、政策名或服务名 - 属性时效、价格、条件、范围等 - 值具体数值或描述 - 单位天、元、次等没有则填 null - 限定条件适用前提没有则填 null 如果文本中没有可抽取的结构化信息返回空数组 []。 只输出 JSON不要输出其他内容。抽取完后一定要做人工抽检。我一般抽 10% 的条目检查重点看属性字段有没有归错、值有没有抽错。抽检发现的问题要反哺到 prompt 里迭代几轮后准确率会明显提升。6.4 向量入库与索引构建入库时除了向量本身metadata 要存全切片 ID、来源文档、章节、页码、关联的结构化条目 ID。这些 metadata 在后续过滤和追溯时都会用到。Qdrant 建集合的示例from qdrant_client import QdrantClient from qdrant_client.models import VectorParams, Distance client QdrantClient(path./qdrant_data) client.recreate_collection( collection_nameknowledge_base, vectors_configVectorParams(size768, distanceDistance.COSINE) )size要和 embedding 模型输出维度一致distance中文场景一般用余弦相似度。6.5 检索接口的完整实现检索接口的核心逻辑def hybrid_retrieve(query, top_k10): # 第一步结构化层精确匹配 structured_results match_structured(query) # 第二步向量层语义检索 query_vector embed(query) vector_results vector_search(query_vector, top_ktop_k*2) # 第三步融合排序 merged merge_and_rerank(structured_results, vector_results) # 第四步拉取关联上下文 final_context fetch_context(merged[:top_k]) return final_contexttop_k*2是为了给重排序留余量先多召回再精排比直接取 top_k 效果好。7. 常见问题与排查技巧实录7.1 结构化条目命中率低怎么办最常见的原因是属性字段没对齐。用户问“退款多久到账”但条目里存的属性是“退款时效”字面不匹配就命不中。解决办法是建一个同义词映射表把“到账时间”“退款周期”“退款时长”都映射到“退款时效”上。这个表可以人工维护也可以用模型自动扩展。另一个原因是值格式不统一。条目里存的是“3-7 工作日”用户问的是“三天到七天”直接匹配就失败。所以归一化一定要做而且要在入库和查询两端都做。7.2 向量检索召回不相关切片先检查 embedding 模型是不是适合中文。有些榜单上排名很高的模型其实是英文优先的中文表现一般。换一个中文语料训练充分的模型试试。如果模型没问题那就是切片策略的问题。切片太大向量会稀释关键信息切片太小语义不完整。试着调整切片大小和重叠窗口观察召回质量变化。还有一个可能是查询本身太短。用户就问“退款”两个字向量检索很难区分“退款政策”“退款流程”“退款时效”。这种情况下可以在查询端做查询扩展用模型把短查询扩写成完整问题再检索。7.3 两层结果冲突怎么处理结构化条目说“3-7 工作日”原始切片里写的是“一般 3 天左右最长不超过 7 天”。这种冲突很常见因为切片是原文条目是抽取后的归一化结果。我的处理原则是以结构化条目为准但把切片作为补充说明一起给模型。Prompt 里明确指示优先级让模型自己判断。实测下来模型在明确指令下能很好地处理这种冲突不会胡乱编造。7.4 知识库更新后的同步问题文档更新了切片重新生成了但结构化条目还是旧的这就出问题了。解决办法是建立更新触发机制文档变更时先重新切片再根据切片 ID 找到关联的结构化条目标记为“待更新”然后重新抽取。没有这层机制知识库越更新越乱。下面这张表是我整理的高频问题速查问题现象可能原因排查方向解决手段结构化命中率低属性未对齐检查同义词映射补充映射表向量召回不准模型不适配换中文模型测试业务数据 A/B两层结果冲突归一化不一致检查抽取规则统一归一化标准更新后答案过时同步机制缺失检查关联关系建立触发更新检索延迟高索引参数不当调 efSearch平衡召回与速度8. 几个我踩过的坑和实测心得第一个坑是过度依赖模型抽取。我一开始图省事全量用模型抽结构化条目结果属性字段五花八门同一个意思有七八种写法检索时根本对不上。后来改成模型抽取加人工归一化工作量上去了但效果稳定多了。结构化条目的质量七分靠设计三分靠抽取。第二个坑是切片重叠设太大。我试过 50% 重叠结果向量库里大量重复内容检索时 top-10 里有 6 条是同一个段落的变体真正有用的信息反而被挤掉了。后来降到 15% 左右召回多样性明显改善。第三个坑是忽略 embedding 模型的一致性。有次我换了检索端的模型但忘了重新 embedding 入库检索结果完全乱套排查了半天才发现是模型不匹配。这个坑很隐蔽因为系统不报错只是结果莫名其妙。所以换模型一定要全量重跑别偷懒。第四个心得是结构化条目不要贪多。不是所有知识都值得结构化。我一开始想把所有信息都抽成条目结果维护成本爆炸。后来只抽高频查询涉及的字段比如时效、价格、条件其他一律交给向量层。二八原则在这里同样适用20% 的结构化条目覆盖了 80% 的精确查询需求。最后一个心得是关于评估。双层 RAG 的效果评估不能只看最终回答要分层看结构化层看命中率和准确率向量层看召回率和相关性融合层看最终答案的正确率。分层评估才能定位问题出在哪一层不然只知道“效果不好”不知道怎么改。这套方案我在两个实际项目里跑过一个是电商客服知识库一个是企业内部制度问答。电商场景下时效类问题的回答准确率从单层的 60% 左右提升到 85% 以上制度问答场景下政策条款的引用准确率提升更明显因为制度文档里全是条件、范围、例外结构化条目的优势发挥得很充分。当然这套方案不是银弹它增加了维护成本需要持续投入人力做条目审核和归一化。但如果你的业务对准确性有硬要求这个投入是值得的。