搭 RAG 知识库的团队经常在选型时纠结向量数据库要不要选带对象存储的原文要不要塞进向量库这些纠结的背后其实是同一个问题没拆开——RAG 的数据有三种形态生命周期和访问模式各不相同放在同一层里管检索层会被无关的存储压力拖垮。把三种形态拆开各归各的层选型自然就清楚了。三种形态三种访问模式原始文档PDF、HTML、Office 文件体积最大写入后几乎不变访问模式是偶尔整读一份通常是解析管线和审计取证在读。切块产物解析后的分段文本和元数据是中间产物随解析管线批量重生成读它的只有入库程序。向量embedding 之后的数值数组体积小、要求毫秒级随机读被检索服务高频访问。三种访问模式对应三种存储需求整读、批量吞吐、低延迟随机读。前两种是对象存储的主场第三种是向量数据库的主场。给个体感数字一块 1024 维、float32 存储的向量是 4 KB一百万个切块的全部向量也就几个 GB向量库的本机盘放得下。真正占空间的是原文几 TB 的 PDF 和网页库在对象存储这边向量库只管索引和向量。两层各自的容量曲线一个按 TB 走、一个几乎不动监控上也不会互相干扰。原文和切块对象存储这一层原文进对象存储没什么争议值得说清的是放在 RustFS 这类 S3 存储上能白拿多少管理能力。版本化让解析管线的每次重跑可回溯新解析结果写成新版本解析出问题回滚版本即可。生命周期规则可以把 90 天未访问的中间切块产物自动降级省下的空间比想象的多切块产物通常是原文体积的两三倍。presigned URL 让检索结果引用原文时不用暴露存储凭据前端拿到的链接带过期时间权限控制在服务端。切块产物建议和原文分桶放。切块是要重生成的数据桶上配不同的生命周期原文桶上开版本化和对象锁切块桶不用。混在一个桶里这两套策略会互相打架。落下来就是三条命令的事mcaliassetrfs http://rustfs:9000$AK$SKmcmb rfs/raw-docs rfs/parsed-chunksmcversionenablerfs/raw-docs原文桶保版本切块桶不保前面说的策略就落在最后一行的差别上。presigned URL 的过期时间也顺手定个规矩给前端签 URL有效期按文档大小给几 MB 的文件五分钟足够别图省事签一天。链接有效期越长被转发出去造成越权读取的窗口就越大这个参数值得写进检索服务的统一配置而不是散在各处。对象锁跟 presigned 这条读链路不冲突对象锁拦的是删除和覆盖锁着的对象拿预签名链接照常能读别指望用锁去收紧读的口子读的边界靠桶策略加 presigned 的有效期来管锁只管写删那头。对象存储这一层不做检索。判断依据很朴素检索需要的是给一个语义毫秒级返回最近的 N 条对象接口给的是给一个 key返回整个对象。语义检索的活归向量库别让检索服务去扫对象存储。还有一条容易被忽略的边界生命周期规则把切块降级、甚至清掉之后检索结果里的 presigned URL 指向的是原文引用照样有效。切块的存亡不影响引用这正是原文放对象存储、向量放检索层带来的容错空间。但切块桶也不是切块的唯一副本向量库入库时通常把切块文本连着向量一起存了生命周期清掉桶里那份向量库里的还在两份中间产物从此不同步。哪天换切块策略重灌对账范围要把向量库里那份也算进去别只盯着切块桶的桶清单。向量检索层的事但持久层可以想清楚向量数据库负责 ANN 索引和毫秒级查询这一层没有替代品。要拆开看的是它的持久层索引文件和原始数据总要落在某块盘上。向量库自身管的是这些文件的编排底下的容量、备份、多副本对象存储接得住的部分就交给对象存储。分层边界在于检索延迟由向量库负责数据不丢由对象存储负责两个承诺别指望同一个组件给。不少向量库支持把段文件或快照直接落到 S3配一个 endpoint 就接上了。接上之后这层关系更干净向量库管索引和查询段文件的容量、备份、多副本由对象存储兜底向量库重装不丢数据。要分清的是落到 S3 的是持久层运行时的查询仍然是向量库把索引加载进本机内存和盘上跑的别把支持 S3理解成拿 S3 当在线查询存储检索延迟按本地盘的账规划S3 只负责数据不丢和可重建。embedding 模型换版本是 RAG 系统躲不掉的事。换模型意味着全量重算向量这时候原文在对象存储上的价值就显出来了切块和向量都可以删掉重生成原文是不动的底座。这也是原文桶开版本化、切块桶不开的另一个理由重生成型的数据不值得保版本。原文桶保版本同样有账要算覆盖和删除都会留旧版本容量只增不减官方文档把这条写在版本化页的运维注意事项里配套动作是给非当前版本配生命周期清理文档还提醒了顺序先定恢复期和保留期再配非当前版本的清理规则别让清理跑在恢复需求前面。按生命周期核对一遍分层放完用数据生命周期过一遍每层的能力是否对得上入库阶段解析管线读原文桶、写切块桶S3 接口批量吞吐multipart 上传用上。检索阶段向量库毫秒级响应命中后用 presigned URL 引用原文全程不碰存储凭据。重建阶段换模型或换切块策略删切块桶重灌原文桶不受影响。审计阶段谁在什么时候入库了哪份文档对象锁和版本化给取证留底。四条都对得上这套分层就站住了。任何一条对不上比如检索服务要扫对象存储找数据或者重建要动原文桶说明边界画错了位置。RustFS 在这套分层里的角色是下面两层原文和切块的承载者给的是 S3 接口加版本化、对象锁、生命周期、presigned 这组管理能力向量检索不是它的活也不该是。分层清晰之后每一层的选型都可以独立替换向量库换型不动原文解析管线重写不动检索这是拆层真正的回报。分层里点到的版本化、对象锁、presigned URL官方文档各有专页可查版本化、对象锁RustFS 1.0.0 在 2026 年 9 月 16 日发布源码在 GitHub 的 rustfs/rustfs 仓库。搭第一版环境时原文桶和切块桶的桶策略直接照文档样例抄比从零琢磨快。