切片存储为适配 LLM 输入长度切割生成的文件文本片段向量存储切片经 Embedding 模型转化而成的高维向量用于相似度检索单看数据关联逻四层数据的绑定关系是通过全局唯一 ID 实现的原始文件的 ID 会作为外键关联到元数据记录切片记录会同时携带原始文件 ID 和自身切片 ID向量记录则以切片 ID 作为唯一主键由此形成完整的、可双向回溯的链路。从技术选型上RAG 应用全阶段的存储方案分云存储与私有化存储两条路线。云存储的核心优势是弹性扩容、低运维成本和全球分发能力私有化存储则以数据安全、合规与可控性见长。就技术栈演进来看两条路线方案分化不大主流存储产品大多同时支持云和私有化部署部分还可实现两类环境间的无缝迁移。本篇我们将基于数据存储的技术特性差异将上述四个阶段划归为三层存储架构这也是当前工业界生产级 RAG 系统的主流设计方案各层的核心存储对象与技术定位如下表所示存储层级核心存储对象技术定位内容存储层原始文件、切片数据存储非结构化内容的原始形态或处理后的中间形态保障数据的可溯源、可重处理管理与元数据层文件元数据提供结构化的数据关联能力与检索过滤依据向量检索层向量数据支撑高效的语义相似度检索是 RAG 区别于传统关键词检索的核心原始文件存储技术选型原始文件是RAG系统的数据源起点其完整性、读取性能和持久化能力是后续切片、向量化、检索等所有环节的前提。一旦原始文件丢失或损坏整个数据管道将失去可信基础。该阶段的存储需求明确一是高持久性确保数据不丢失二是支持高并发读取以应对数据更新和重处理如重新切片时的频繁访问三是兼容多格式存储覆盖PDF、Word、Excel、PPT、Markdown、HTML等常见非结构化文档。需要强调的是原始文件的存储性能对RAG上层检索并无直接影响正常检索流程不直接读取原始文件。存储层对原始文件的支持本质上是对数据管道容错机制的保障一旦切片或向量数据因误删或业务逻辑变更如调整切片token大小而失效系统可基于原始文件快速重处理恢复检索数据。这个阶段要解决的是海量非结构化数据的落地问题。过去很多企业喜欢用HDFS存大数据但技术趋势已经变了。现在云原生、Kubernetes和微服务这么火计算和存储分离已是行业共识。HDFS把计算和数据强行绑在一起处理海量小文件时效率极低扩展起来也极其痛苦。现在大家都在转向对象存储和新型分布式文件系统。对象存储的好处是把数据打包成一个个带唯一标识符的对象在扁平命名空间里管理。这种设计让它具备了极其恐怖的横向扩展能力。轻量级云原生对象存储MinIOGithub: https://github.com/minio/minio开发文档https://docs.min.io/aistor/reference/cli/#quickstart官网https://min.io/docs/如果要在公司内部自建对象存储工程师脑子里蹦出的第一个词多半是MinIO。MinIO 是用 Go 语言写的高性能、分布式、云原生对象存储系统。优点完全兼容 AWS S3 API迁移无痛采用极简的去中心化设计无需专门的元数据服务器数据高可用全靠纠删码技术相比传统三副本方案硬盘利用率高高性能吞吐量狂暴。八核NVMe环境下能跑出读取2.8 GB/s、写入2.1 GB/s的狂暴吞吐量缺点硬件排布要求苛刻部署标准 MinIO 存储池通常要4到16块硬盘节点之间硬件规格尽量保持一致对服务器资源胃口不小方建议每个节点至少4个以上CPU核心、4到32GB内存。大而全的统一存储平台Ceph (RGW)Github: https://github.com/ceph/ceph官网https://ceph.io/如果说MinIO是轻骑兵那Ceph绝对是存储界的航空母舰。运维一套Ceph集群简直就是新手的噩梦如果没有专门的资深存储工程师团队千万别碰它。Ceph是开源的软件定义存储平台野心非常大想在一个集群里同时搞定对象存储、块存储和文件系统。优点统一存储平台对象、块、文件一把梭极度灵活的数据分布控制通过Crush Map算法可以精细控制每份数据到底存在哪个机房、哪个机架、甚至哪块特定磁盘上支持异地多活和冷热数据分层缺点架构复杂运维门槛极高上面组件密密麻麻管理磁盘的OSD守护进程、维护集群状态的Monitor节点、监控指标的Manager进程极度吃内存资源开销大一个OSD进程通常要吃掉8到16GB内存小文件处理延迟偏高大概在6.3毫秒左右海量小文件的救星SeaweedFSGithub: https://github.com/seaweedfs/seaweedfs官网https://seaweedfs.com/SeaweedFS 专为海量小文件而生适合几百万、上千万个几十KB的文本或图片。它的设计灵感来自 Facebook 的 Haystack 论文 「 https://research.facebook.com/publications/finding-a-needle-in-haystack-facebooks-photo-storage/ 」。核心思想把元数据和数据存储彻底分开。主节点只管理卷的映射关系不关心具体文件。真正的文件和元数据都紧凑地塞在卷服务器里。优点海量小文件下读写快、延迟低元数据压力小主节点不存文件信息内存占用低适合大并发场景支持冷数据自动推到云端 S3集成了 Iceberg REST Catalog能直接对接数据湖分析引擎缺点大文件几百MB以上性能不如 Ceph 或 MinIO社区和生态不如 Ceph 成熟企业级工具少单卷有大小上限默认 30GB需提前规划部署和运维比 MinIO 复杂废旧硬件与边缘计算的黑马GarageGithub: https://github.com/deuxfleurs-org/garage开发文档https://garagehq.deuxfleurs.fr/documentation/quick-start/官网https://garagehq.deuxfleurs.fr/Garage 适合预算很低的团队。不需要买昂贵的企业级 NVMe 服务器用配置参差不齐的旧机器或便宜的 VPS 也能跑。它用 Rust 语言编写主打轻量、安全、容错强。设计思路来自亚马逊 Dynamo「 https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf 」论文和 CRDT 研究。不做复杂的纠删码而是简单做 3 副本复制配合一致性哈希来分布数据。优点运维门槛极低硬件要求低旧机器、VPS 都能用内存占用小单节点只要 1 到 2 GB 内存适合资源紧张的环境容错能力强能承受高延迟和跨机房部署部署简单支持 K8s 一键安装缺点3 副本方式浪费存储空间不如纠删码省容量性能一般不如 Ceph 或 SeaweedFS生态和社区较小企业级功能少暂不支持全托管的 S3 兼容界面需自行对接AI计算的高性能缓存网关JuiceFSGithub: https://github.com/juicedata/juicefs开发文档https://juicefs.com/docs/zh/csi/introduction/官网https://juicefs.com/JuiceFS 让算法工程师不用改代码就能把对象存储当成本地硬盘来用。它提供标准的 POSIX 接口数据存在便宜的 S3 等对象存储里目录树等元数据存在 Redis 或 TiKV 这类高性能 KV 数据库里。它在 AI 圈很火。数据和元数据分离既有对象存储的低成本、无限容量又通过本地多级缓存实现了接近本地 SSD 的读写速度。很适合跑模型训练或 RAG 数据清洗能让 GPU 充分利用起来不用等数据加载。优点像本地硬盘一样用代码无需改造数据放对象存储成本低、容量几乎无限多级缓存加速读性能接近本地 SSD元数据单独存 KV 数据库操作快缺点依赖外部 KV 存储如 Redis、TiKV多一个组件要维护首次读冷数据时延迟比纯本地盘高写小文件频繁时元数据压力较大多机同时写同一文件时一致性开销偏大原始文件存储方案架构流派与核心设计最适用的业务场景硬件资源占用与运维门槛AWSS3 / 阿里云****OSS公有云全托管对象存储资金充足、不愿碰底层运维的通用业务资源零占用运维门槛极低MinIO去中心化对象存储严格纠删码追求极致吞吐量服务器规格统一的私有云中高内存占用扩缩容略显死板中等门槛Ceph (RGW)统一存储平台组件繁杂极度灵活超大型数据中心需要精细化控制数据分布极度吃内存需要资深专家门槛极高SeaweedFS主从解耦O(1)寻址集成数据湖应对海量小文件极低延迟要求冷热分层轻量内存部署简便门槛较低GarageRust编写3副本一致性哈希抗高延迟边缘节点二手废旧服务器利旧预算极低极微小内存占用跨机房部署极易门槛极低JuiceFSPOSIX兼容元数据与数据物理分离AI模型训练需要将对象存储挂载为本地目录依赖外部Redis/TiKV架构稍显冗余门槛中等元数据Metadata存储技术选型文件元数据是描述原始文件属性的结构化数据是连接原始文件、切片数据与向量数据的核心枢纽。它与原始文件为「一对一」关系与切片及向量数据为「一对多」关系通过文件ID或切片ID实现绑定。在检索中元数据是重要的过滤与溯源依据用户可通过精准的元数据过滤先排除不符合业务属性的文档再进入向量相似度检索从而大幅提升检索性能和结果精准度。RAG场景下的元数据主要分三类基础属性原始文件名、文件大小、格式、存储唯一标识如对象存储URI、生成/修改时间、上传人、部门、业务标签等处理属性解析状态、最终切片大小、切片版本、向量化进度、关联切片ID、关联向量索引ID等权限属性可访问用户组、用户ID集合、部门权限集合以及检索时需应用的权限控制规则该阶段的存储需求与原始文件层有本质差异支持高并发下的快速查询与精准更新因元数据检索是RAG检索的前置过滤器具备强一致性事务能力确保增删改时元数据与原始文件、切片、向量数据的关联关系不出现异常支持随数据量增长的水平扩展能力兼容企业现有生态的标准查询接口如SQL及必要的检索索引如倒排索引、组合索引具备完善的备份恢复与数据安全加密能力关系型老大哥PostgreSQL如果公司知识库的元数据结构很固定比如只有 ID、标题、创建时间、作者、密级这几个字段用 PostgreSQL 就足够了。它成熟、稳定、事务强一致。PostgreSQL 15版本对 JSON 支持也很好偶尔存点非结构化数据也没问题。而且如果后面要用 pgvector 做向量检索把元数据和向量放在同一个库用一条 SQL 就能查对开发者非常方便。灵活的文档型数据库MongoDB官网 https://www.mongodb.com/博客https://www.puppygraph.com/blog/mongodb-vs-neo4j真实业务经常变化。今天加「点赞数」明天加「数据留存周期」。关系型数据库频繁改表结构很麻烦。这时MongoDB 这种文档型数据库更合适。MongoDB 用 BSON 格式存数据类似 JSON。不管多深的嵌套、多复杂的结构都不用提前定义 Schema。在 RAG 应用里适合存长文档切分后的上下文信息。它的聚合框架和索引机制很强大按元数据查文档也很快。复杂推理的利器图数据库 Neo4j官网https://neo4j.com/上面两种数据库在处理单一属性查询没啥问题但查询里包含多层关系比如「既给现代汽车供货、又在2025年报过供应链违约风险的欧洲企业相关应急预案有哪些」这种问题有三四层关联传统数据库用 JOIN 会卡死。Neo4j 可以很好地解决上述问题。它天生为处理关系而生采用免索引邻接架构节点在物理层面上直接相连。遍历关系的速度只取决于局部子图的大小和总数据量无关。在 Graph RAG 中可以把文档切片挂在公司、城市、高管等实体节点下。系统把用户问题翻译成 Cypher 查询按公司、国家、情感等条件沿图路径遍历让 RAG 的逻辑推理能力大大提升。如果不想把数据搬到 Neo4j也可以用 PuppyGraph。它在 MongoDB 上直接跑图查询不用 ETL避免数据搬家。极速的内存缓存Redis官网https://redis.io/博客https://redis.io/blog/hybrid-search-benefits-rag-systems/高并发的 RAG 系统里不能每次检索都查磁盘数据库。Redis 是内存数据库的王者常用来存用户会话、高频元数据和做全局限流。它的读写速度在亚毫秒级。Redis Stack 还支持混合检索在轻量级、对延迟要求极高的场景下地位不可替代。切片Chunk存储技术选型切片数据是原始文件经解析、切分后得到的文本片段是连接原始文件与向量数据的核心枢纽也是RAG检索中命中的最小单元。其存在的核心逻辑是适配LLM输入上下文窗口的token长度限制以text-embedding-v4模型为例单次输入上限为2048 token超长文档直接向量化会被截断破坏语义完整性切分成小片段后每个片段token长度控制在模型上限内从而保障向量检索精度。切片数据存储的内容并非单纯文本而是一个三元组切片唯一ID、切片文本内容、对应部分元数据如原始文档来源、页码、章节信息等。该阶段存储技术选型与原始文件层高度类似但有两处细节差异切片数据的读取频率远高于原始文件向量检索命中后需立即读取对应切片文本作为注入LLM的上下文部分RAG场景需支持基于切片元数据的过滤如仅检索某书特定章节或某产品特定版本文档。混合检索的无冕之王Elasticsearch / OpenSearchGithub1: GitHub - elastic/elasticsearch: Free and Open Source, Distributed, RESTful Search Engine · GitHub官网1https://www.elastic.co/elasticsearchGithub2: GitHub - opensearch-project/OpenSearch: Open source distributed and RESTful search engine. · GitHub官网2Getting started - OpenSearch Documentation纯向量检索能理解语义但像近视眼。搜具体报错代码或偏门人名时容易失败因为它重整体含义、轻字面匹配。所以现在RAG领域都使用混合检索Hybrid Search。混合检索就是让两套引擎同时干活。一边用向量引擎去找意思相近的另一边用传统的BM25算法去找包含特定关键词的。最后用一种叫RRF倒数排名融合Reciprocal Rank Fusion的算法把两边的排名结果综合一下这种做法能大幅度兜底大模型的检索质量。向量Vector存储技术选型向量数据是切片数据经Embedding模型转化后的高维数组是RAG架构中最特殊的一层存储无法被人类直接理解也无法用传统关系型数据库进行精准匹配或范围扫描。支撑其高效近似近邻检索能力是RAG系统性能优化的核心技术点。RAG的实际检索流程分三步联合完成元数据过滤基于用户过滤条件如某部门文档从元数据层筛选出符合条件的文档集合向量检索将用户检索词通过同一Embedding模型转化为向量在过滤后的集合内进行相似度计算找出最接近的向量结果溯源根据命中向量关联的切片ID读取切片原文及原始文件URI作为上下文注入LLM生成答案该阶段存储技术需求最为专业是四层数据中技术门槛最高的一层必须支持高并发、低延迟的近似最近邻检索千万级以上向量规模下响应时间需控制在毫秒级支持高维向量的高效存储与索引维度通常在数百至数千维具备与元数据层、切片层的高关联查询能力需先元数据过滤再向量相似度比对集群架构支持水平扩展应对数据量与并发增长最好具备混合检索能力同时支持向量相似度检索与传统关键词检索可通过加权或RRF算法进行结果融合8 向量Vector存储技术选型.png现在的向量数据库市场竞争激烈按架构流派可以分为几类。零运维的云原生 SaaSPinecone 与 Turbopuffer如果团队有预算但缺专业运维就别自建了直接上云托管。Pinecone最知名的闭源商业向量数据库。采用存算分离架构不用自己调 HNSW 参数、操心内存或扩容。适合平时没流量、偶尔爆发的业务表现很稳定。缺点是贵高并发场景一个月几千美金是常事。标准版只能建 20 个索引虽然支持 10 万个命名空间但灵活性还是有限。Turbopuffer后起之秀很特别。它完全架在 S3 这种廉价对象存储上是 Serverless 的。最适合有成千上万小租户的 SaaS 产品因为不限制命名空间数量且隔离性好。最低每月 64 美金就能处理海量读写请求。公有云基础设施AWS S3 Vectors 与 Cloudflare Vectorize很多人不想为了 RAG 单独买一个数据库。云大厂直接在现有基础设施里加入向量能力。AWS S3 Vectors亚马逊的新产品。既然原始文件就在 S3为何不直接在 S3 里做向量检索它提供专门的向量桶用简单 API 把向量传进去底层扩容全由 AWS 负责。跟 Bedrock、SageMaker 打通。按次计费、零服务器管理、亚秒级检索成本优势很大。Cloudflare Vectorize适合边缘 AI 计算尤其是跑在 Cloudflare Workers 上。它支持 5 万个索引配合 D1 和 R2 使用能在离用户最近的边缘节点返回 RAG 结果。缺点是不支持混合检索单索引最多 500 万向量。十亿级海量数据的开源霸主Milvus / Zilliz当向量数据突破一亿甚至到十亿、百亿级别轻量级数据库会崩溃。这时是 Milvus 的主场。开源版 Milvus专为超大云原生环境设计。架构极度解耦能无限扩展还支持 GPU 加速。但自己搭非常折磨人内部依赖一堆中间件分布式组件一挂就很难排查运维成本极高。Github: https://milvus.io/官网 GitHub - milvus-io/milvus: Milvus is a high-performance, cloud-native vector database built for scalable vector ANN search · GitHub托管版 Zilliz Cloud想用 Milvus 又不想脱发就花钱买托管版。内置专有的 Cardinal 引擎检索速度比开源版快 10 倍。预算友好与混合检索先锋Qdrant 与 Weaviate如果数据量在 5000 万以内又坚持开源这两个用 Rust 和 Go 写的明星项目值得关注。Qdrant预算有限的团队最爱。天生支持混合检索向量 BM25 元数据。Qdrant Cloud 提供 1GB 永久免费额度。在 5000 万数据量、99% 召回率下QPS 能到 41非常稳健。Weaviate把混合检索做到极致。自带图属性对细粒度的元数据过滤有原生支持适合需要复杂条件筛选的 RAG 系统。Vespa雅虎开源功能大而全适合复杂实时计算和机器学习重排序。FAISSMeta 开源极致批处理索引速度性能天花板适合纯极客玩家。传统数据库的最强外挂pgvector 与 pgvectorscale在 2026 年务实潮流是不建新数据库。如果你们已经把 PostgreSQL 玩得出神入化何必再引入不熟悉的专用向量库pgvectorC 语言写的 PG 向量扩展。数据量小于几千万时用起来很顺手可以用一条 SQL 在同一事务里查出业务数据和向量。但超过 5000 万后延迟和吞吐量会急剧恶化。pgvectorscaleTimescale 开源的神器用 Rust 和 pgrx 框架写的。采用受微软 DiskANN 启发的索引结构。在 5000 万向量、99% 召回率下它跑出 471 QPS比 Qdrant 快 11.4 倍。配合 pgai 库可以用外挂的 vectorizer worker 异步处理大模型嵌入不会拖垮数据库主进程。这套组合拳几乎成了中型 RAG 项目的终极首选。Github: GitHub - timescale/pgvectorscale: Postgres extension for vector search (DiskANN), complements pgvector for performance and scale. Postgres OSS licensed. · GitHub原型开发与边缘独立的轻量级利器ChromaDB 与 TursoChromaDB适合快速做 MVP。就是个 Python 或 JS 包像 NumPy 一样好用完全嵌在代码里不用起服务端。2025 年用 Rust 重写后快 4 倍但官方承认不适合大规模生产环境。LanceDB基于列式存储的嵌入式向量库支持零拷贝访问。很适合本地环境或数据科学家的 Jupyter Notebook。Turso(sqlite-vec)如果不想用 Pinecone 的命名空间隔离Turso 提供了一个思路给每个租户建一个完全物理隔离的 SQLite 节点放在边缘网络上。一租户一库彻底杜绝数据泄露风险。不能做全局搜索但在合规场景下是降维打击。向量存储技术底层架构与语言性能与规模上限核心优势适用场景Pinecone专有闭源托管亿级以上彻底免运维自动扩缩容计费灵活资金充裕、无运维团队的企业流量波动的SaaSAWSS3 Vectors依托对象存储无缝无限扩展极低成本零服务器配置原生打通Bedrock已经重度绑定AWS生态的Serverless RAG应用Milvus / Zilliz云原生分布式组件十亿、百亿级极限并发吞吐量天花板支持GPU解耦极其彻底海量数据场景拥有资深基础设施运维团队pgvectorscalePostgreSQL Rust扩展5000万~1亿级DiskANN索引性能逆天同事务混查关系数据熟练使用PG的团队力求系统架构精简降本QdrantRust专用开源5000万以内较优原生混合检索能力强Cloud版免费层极其慷慨预算有限但需要强悍混合检索的初创中型团队WeaviateGo专用开源亿级左右原生融合BM25与元数据深度过滤图属性加持高度依赖元数据复杂条件过滤的精准RAGChromaDB嵌入式内存/磁盘1000万以内零环境配置开发者API极度友好极速上手前期概念验证PoC、本地MVP产品原型开发云端与本地公有云与私有化部署的综合碰撞
)
