RAG Schema设计实战：三层模型与五大避坑指南

做RAG落地，最容易被忽视、却又最能决定系统上限的，往往是那张不起眼的Schema设计。我见过太多团队把精力砸在Embedding模型选型和向量库调参上，结果数据一多、权限一复杂，系统直接变成一锅粥。这锅粥的根源，十有八九不是算法不行，而是从文档到向量之间缺了一层严谨的结构设计。这篇就专门聊聊RAG里的Schema到底怎么规划，从分层模型到字段设计，再到我踩过的那些反模式坑，一次讲透。

1. Schema在RAG管线里的真实角色：不只是“建表”

很多朋友一听到Schema，第一反应是“这不是数据库DBA该操心的事吗”。在传统业务系统里这么想勉强可以，但放在RAG场景里，这种想法会害死人。RAG的完整链路涉及文档解析、切分、向量化、索引写入、查询召回、重排生成，每个环节对数据结构的要求都不一样。Schema在这个链条里扮演的角色，远不止是定义几个字段那么简单，它实际上是整个RAG系统的数据结构契约。

1.1 解析层、索引层、查询层的三重身份

先说解析层。一份PDF或者Word文档进来，经过解析器抽出来的往往是半结构化的内容：有章节标题、有段落、有表格、有图片说明。如果在这个阶段不定义统一的Schema，后面做切分时就只能靠经验“盲切”，切出来的块可能带着乱七八糟的噪声信息，也可能丢失关键的层级上下文。

再看索引层。向量数据库或者搜索引擎里存的每条记录，不能只有“文本+向量”两个字段。至少得有文档ID、分块序号、来源路径、入库时间、权限标签这些基础字段。不然等你要做时间范围过滤、按来源去重、或者给不同部门隔离数据的时候，你会发现底层根本没有可用的结构化字段，只能重新灌库。

最后是查询层。用户提问进来，除了向量相似度计算，经常会带一些隐性的过滤条件，比如“只看最近一个月发布的文档”“只要技术方案类的资料”。这些条件如果没在Schema里提前设计成可过滤字段，那所有请求都只能靠向量硬扛，召回精度和响应速度都会非常难看。所以Schema在RAG里不是一个静态的表结构，而是贯穿了解析、索引、查询三个阶段的数据契约。

1.2 为什么向量化越强，Schema越重要

有个反直觉的现象：Embedding模型的能力越强，对Schema的依赖反而越重。原因是，强模型能捕捉到更细腻的语义，但如果底层数据组织混乱，再强的语义匹配也会被无关信息的噪声干扰。打个比方，一个图书馆如果只是把书全部堆在地上，管理员记忆再好，你要借一本《Python网络爬虫》，他也得翻半天。但如果书架按分类、作者、出版年份排好，他扫一眼就能锁定位置。Schema就是这个排架规则，向量化负责的是“你心里想要什么”，Schema负责的是“东西在哪儿、长什么样、能不能快速拿出来”。

在真实项目里，我见过一个检索效果迟迟不达标的案例。团队的Embedding模型已经是当时的第一梯队，向量相似度算得也没问题，但查出来的结果总是张冠李戴。后来排查半天，发现原因是所有文档都塞在同一个Collection里，没有领域字段、没有时间字段、没有文档类型字段。用户问“上季度的市场分析”，系统只能召回语义上沾边但实际是两年前的旧报告。加了三个过滤字段之后，同样的模型、同样的向量， precision直接翻了一倍。这件事给我的触动很大：很多时候RAG系统的瓶颈根本不在模型侧，而在结构侧。

2. 一套可落地的三层Schema模型：文档层、分块层、索引层

分清阶段之后，下一步是定义字段。我习惯把RAG的Schema拆成三层来设计：文档层负责描述“一份文件是什么”，分块层负责描述“一个切片从哪里来、处于什么上下文”，索引层负责描述“这个块在检索系统里如何被组织和召回”。三层各管各的事，互不越界。

2.1 文档层：给每一份资料办“身份证”

文档层的核心目标是唯一标识和来源追溯。我一般会至少定义这些字段：

这里面最容易漏的是acl_tags。很多RAG系统上线时是内部工具，大家默认没有权限问题，但一旦要跨部门共享或者面向外部客户开放，权限过滤就是刚需。等用户提需求再补字段不是不行，但存量数据要全量回填，麻烦得很。我在项目里习惯一出文档就顺手把权限标签打上，哪怕现在用不上，也留着空数组占位。

2.2 分块层：让每个切片知道自己“站在哪里”

分块层是RAG特有的设计，也是和传统搜索系统差异最大的地方。每个切出来的块，除了文本内容本身，必须携带足够的上下文锚点：

• chunk_id：全库唯一，一般用doc_id + 序号的拼接方式生成。
• parent_doc_id：回溯到所属文档，用于聚合展示和上下文拼接。
• chunk_index：块在文档内的位置，方便按顺序拼接上下文。
• heading_path：从文档根到当前块的小标题路径，比如“第二章/2.3节/实现方案”。
• token_count：块的实际token数，后续做上下文裁剪和成本估算都靠它。
• content_type：是正文段落、表格、代码块还是图片说明，不同类型在召回后的呈现方式不一样。

heading_path这个字段是我强烈建议保留的。很多RAG系统只存了文本和向量，召回后给大模型喂的是一堆割裂的碎片，模型根本分不清这段内容是来自“问题描述”还是“解决方案”。有了章节路径之后，你可以在拼Prompt的时候把路径带上，比如[文档名 | 第三章 | 3.1节]，大模型对内容定位的准确度会明显提升，幻觉比例也会下降。

2.3 索引层：向量和标量如何协同工作

索引层是向量库里的物理映射，核心要回答两个问题：哪些字段参与向量召回，哪些字段参与结构化过滤。实际落地时，我会把字段分成三类：

• 向量字段：存Embedding数组，这是召回的主路径。一般一个Collection只放一个主向量字段，多向量方案在业务没跑稳之前慎用。
• 过滤字段：需要精确匹配的标量字段，比如doc_id、acl_tags、source_type、created_at。这些字段必须用合适的类型索引，保证过滤查询的延迟可控。
• 展示字段：召回后要返回给上层或者喂给大模型的字段，比如chunk_text、heading_path、page_number。这些字段不参与匹配，但是直接影响生成质量。

这套三层模型的好处是职责清晰，每一层的字段变更影响面可控。文档层调整不影响切分逻辑，分块层加字段不影响文档入库，索引层改映射也不需要重跑全量文档解析。后续系统迭代的时候，这种解耦能省下大量返工时间。

3. 字段设计避坑实录：我从低质召回项目里挖出的五个教训

前面讲了理想模型，这一节说点实在的。下面这五个坑，是我自己项目里真实踩过的，每一个都付出了不少调试时间。建议你在设计Schema之前，先对照着检查一遍。

3.1 坑一：doc_id生成规则不稳定，导致数据重复写入

最早的版本我直接用文件名作为doc_id。看起来没问题，但实际跑起来就出事了：同一份文档在不同目录下各传了一份，文件名一样但内容不同；或者文档更新后文件名带上了“V2”“最终版”之类的后缀，新ID直接生成，旧数据还躺在库里。结果检索的时候，重复内容被多次召回，用户反馈“为什么查到的全是同一个东西”。

正确的做法是，doc_id应该从文件内容或稳定属性中生成，而不是从路径或文件名生成。我在项目里最终采用了“文件原始URL或业务主键+内容哈希”的组合方式。内容变化时哈希变化，但原始定位不变，既保证唯一性，又能识别更新。另外，写库的时候要设置“按doc_id覆盖”的upsert策略，避免重复插入。

3.2 坑二：过滤条件全堆在向量库上，性能被打穿

一开始做权限过滤，我把所有过滤逻辑都塞给向量库：“向量相似度算完，再对结果集跑一遍权限过滤”。数据量小的时候确实能跑，但当Collection里存了几十万条记录、权限条件又复杂时，问题就来了。向量库的过滤能力在复杂表达式面前很脆弱，一个嵌套的should加must_not就能把查询延迟从几十毫秒拉到几百毫秒，而且有些向量库对这类查询的优化并不好，内存占用也飙升。

后来我梳理了一下，把可以前置的过滤尽量前置：在解析和写入阶段，就把文档的部门、域、类型等标签全部拍平成简单字段，避免查询时的复杂嵌套。对于确实需要跨条件的过滤，我把向量库和元数据过滤拆成两段：先按过滤条件圈定候选文档ID集合，再在候选集合内做向量检索。效果立竿见影，延迟稳定在原来的五分之一以下。

3.3 坑三：忽略了文本切分与Schema字段的联动

很多团队把切分逻辑和Schema设计完全分开做，各管各的。切分参数调了半天，最后发现召回结果不好的原因，是切出来的块粒度跟Schema里的heading_path对不上。比如一个块跨越了两个章节，但Schema只给它打了某一个小节的标签，用户搜“服务器部署”时，本该召回跨章节的上下文，结果因为标签不匹配而漏掉。

这个问题的解法是，切分器在输出的每个块上，不仅要生成chunk_text，还要同步生成heading_path和chunk_index。也就是说，切分逻辑要跟Schema设计协同起来，切分规则本质上是在执行一种“预定义的分块Schema”。我后来在项目里直接要求：切分器的输出必须符合分块层的字段约束，如果有块在配置过程中无法填充某些必填字段，就说明切分规则本身有问题，得回去改。

3.4 坑四：权限字段设计成多值嵌套，查询写不出来

做权限设计时，我一开始想得很美：用acl_tags存一个数组，不同的角色存不同标签，查询时用“包含其中一个标签”的逻辑来匹配。听起来很合理，但真到查询的时候才发现，多值字段在过滤语义上很容易踩坑，尤其是“只要包含A标签或包含B标签”这种OR逻辑，和向量库的过滤语法结合之后，不少库对OR语义支持得很别扭。而且一旦标签数量增长，索引膨胀得厉害。

这类场景我的建议是提前把权限拍平成独立的布尔字段，或者用“一组标签对应一个权限组ID”的方式简化匹配。核心原则是：查询时能用等值匹配，就绝不用多值包含匹配；能用简单ID匹配，就不要让过滤条件有复杂的集合逻辑。

3.5 坑五：时间戳字段格式不统一，后续清洗到崩溃

文档来源五花八门，有的时间字段是2024-01-15 10:30:00，有的是时间戳毫秒值，还有的干脆只有年份。如果入库Schema没有强制统一格式，等要做“最近三个月内的资料”过滤时，你会发现排序结果乱七八糟。这个问题看似低级，实际在跨系统接入时非常普遍。

我在Schema设计规范里规定：所有时间字段统一存UTC时间的ISO 8601字符串，入库前在解析层完成转换。显示层要什么格式，上层再做格式化，底层不妥协。这个规矩立了之后，跨来源的时间过滤再也没出过幺蛾子。

4. Schema驱动下的检索质量优化：从“能搜到”到“搜得准”

Schema不是设计完就躺着的“死结构”，它的设计思路会直接影响检索策略的调优空间。同一个Embedding模型，搭配合理的Schema设计，检索质量可以肉眼可见地拉开差距。

4.1 元数据预过滤：让向量检索跑在“对的地盘”

最直接的优化是元数据预过滤。用户问“上季度的技术方案类文档”，在向量检索之前，先用source_type=技术方案和created_at>=季度开始时间把候选集缩到一个很小的范围内，然后在这个范围内做向量相似度计算。这样既省算力，又能排除大量语义沾边但实际不符的干扰项。

预过滤要生效，依赖的就是索引层Schema里的过滤字段设计得够不够好。如果当年设计的时候没有预留这些字段，现在只能一边吐槽一边补数据。

4.2 父子文档关联：避免“只见树木不见森林”

分块层设计里，parent_doc_id这个字段的价值，在召回策略里体现得最明显。单纯按向量相似度召回，经常出现一个文档的十来个分块全部挤进TopK，而其他相关文档一个都进不来的情况。有了parent_doc_id之后，召回阶段可以先按块检索出候选集合，再做一轮按父文档去重或聚合，保证同一个文档最多只占几个名额，给其他相关文档留出位置。

更进阶一点的玩法是父子文档的两阶段召回：先召回相关的chunk_id，再根据parent_doc_id把整个文档的上下文取出来，喂给大模型生成。这个策略在回答“某份文档整体是怎么设计的”这类问题时特别好用，因为它们需要的是全局视野，单块内容根本撑不起来。

4.3 重排阶段的Schema辅助：让分数和标签参与决策

重排（Rerank）阶段的输入，很多人只拿文本和向量相似度，但其实Schema里的结构化字段也能派上用场。比如content_type是“文档摘要”的块，在大文档检索时往往比正文内容更重要，可以在重排分数里给它一个加权偏置。另外token_count这个字段，在做生成上下文的裁剪时是硬参考，超了就得压缩或者截断，提前算好能省不少请求时间。

这些设计都不是什么高深算法，纯粹是让系统在关键决策点上多一个可利用的输入信号。而所有这些信号，前提都是建好了Schema字段。

5. 两种落地场景的Schema配置示例：全文索引型和关系模型型

最后看看实操层面。不同底层存储选型，Schema的具体写法差别不小。我列两种常见的场景，能直接抄作业。

5.1 全文索引Inverted Index加向量字段的配置

以某搜索服务为例，一个比较顺手的Schema配置大概长这样：

{ "mappings": { "properties": { "doc_id": { "type": "keyword", "doc_values": true }, "chunk_id": { "type": "keyword" }, "source_type": { "type": "keyword" }, "created_at": { "type": "date", "format": "strict_date_optional_time" }, "acl_tags": { "type": "keyword" }, "heading_path": { "type": "text", "analyzer": "standard" }, "chunk_text": { "type": "text", "analyzer": "ik_smart", "search_analyzer": "ik_max_word" } } } }

注意几个细节：doc_id和chunk_id一定要用keyword类型，别用text，否则分词之后ID就被拆得七零八落，等于没有。created_at要用date类型，方便范围查询。acl_tags如果是数组，尽量保持枚举值，不要掺入动态变化的文本标签。

等待文本进入索引后，向量字段一般单独加在mapping里，取决于后端向量插件或独立向量服务，配置时保持向量维度和Embedding模型输出一致就行。

5.2 关系型向量表的建表方案

如果是用关系型数据库加向量插件的方式，比如某关系库的向量类型，建表DDL可以参考下面这种结构：

create table document_chunks ( id bigserial primary key, doc_id varchar(128) not null, chunk_id varchar(128) not null, chunk_index int not null, heading_path text, token_count int default 0, source_type varchar(64), created_at timestamptz default now(), acl_tags varchar[] default '{}', chunk_text text, chunk_embedding vector(1536), unique(doc_id, chunk_index) ); create index on document_chunks using hnsw (chunk_embedding vector_cosine_ops); create index on document_chunks (source_type, created_at);

用关系型方案的好处是，RAG系统的元数据管理可以跟业务系统共用一套事务机制，比如统一在应用层更新文档版本时，同时维护document_meta表和document_chunks表的数据，一致性更容易保证。缺点是向量检索的规模上限和运维成本要结合自己的数据量评估，尤其在纯向量库和关系库之间做取舍时，不能只盯某一项指标，要一起压测。

5.3 Schema版本管理：别在线上直接改字段

最后提醒一个所有RAG项目都会面临的进化问题：Schema逃不过演进的宿命，上线之后必然要加字段、改类型。我的建议是，任何改动都走版本化流程：新建一个V2的Collection或索引，把数据迁移过去，验证没问题后再切流量。绝对不要在生产环境的Schema上直接加字段或者改类型，一旦和存量数据不兼容，回滚的成本会高得让你怀疑人生。这也是为什么我特别推荐在解析层加一个内部版本号，每次重新灌库时都带上Schema版本，排查问题的时候能少掉一半头发。

6. Schema设计要跟着检索场景走，而不是跟着“数据库规范”走

文章写到这里，核心的思路已经铺开了。最后聊一点我自己的体会：设计RAG的Schema，最重要的不是严格遵循某一套数据库范式，而是跟着检索场景走。

你在设计字段之初，先想清楚用户可能怎么查：他们会不会按时间过滤？会不会按文档类型筛选？需要不需要权限隔离？这些问题想得越早，字段就预留得越齐，后期也就越省力。因为RAG系统一旦进入生产环境，数据是会持续增长的，Schema改一次，全量重灌一次，成本非常现实。

我给团队定的规矩是：任何新的RAG项目，先写出一份“查询场景清单”，列出最多二三十个典型提问和对应的过滤条件，然后再对着清单去定义Schema字段。这样做出来的Schema，几乎不会出现“上线后发现没字段可用”的尴尬。反过来，如果你先按教科书式数据库规范把表建得漂漂亮亮，等真实检索需求砸过来时，大概率还得推倒重来一遍。

还有个实用的小技巧，值得分享一下：正式落库前，用一份覆盖各种类型字段的测试文档集跑一遍全流程，重点看两类问题——一是筛选条件在不同组合下的召回率差异，二是chunk_text的表现质量。很多字段当时觉得用不上，等数据量涨起来才发现，这恰恰是决定系统上限的“隐藏晴雨表”。所以别嫌前期定义Schema费时间，这一步省下的功夫，后面千倍百倍都会还回来。