本文深入解析RAG系统中的存储层设计，强调存储架构分层的重要性，详细阐述了向量数据、原始文本、结构化元数据、文档级管理信息四类数据的存储需求与访问模式差异。文章提出了典型的三层存储架构（向量检索层、内容存储层、管理与元数据层），并分析了不同数据规模下的架构演进策略。此外，还探讨了多级索引的存储实现、索引更新机制以及多租户权限隔离方案，为读者提供了从入门到进阶的RAG存储层设计全面指南。
1、题目分析
RAG 系统里最容易被低估的就是存储层。很多人把 RAG 理解成"文档切片→扔进向量库→检索→喂给 LLM"的线性流水线，存储仿佛只是中间一个"放东西的地方"。但真正做过生产级 RAG 的人都知道，存储架构的设计深度远超一个向量数据库的选型——你需要想清楚：哪些数据存哪里、不同存储组件之间怎么协作、怎么兼顾检索性能和数据管理、怎么支撑业务不断增长的知识规模。这些问题的回答方式，直接暴露你是"调了个 Demo"还是"真正设计过一套系统"。
面试官听这道题的时候，脑子里有一张架构图——他期待你也能画出一张。不是 RAG 原理图，是你项目里存储层的组件拓扑：有几类存储、各自承担什么职责、数据怎么流转、为什么这么分。
1.1 一种存储搞不定所有需求
要理解 RAG 存储架构为什么要分层，得先看清楚 RAG 系统里到底有哪些类型的数据需要存储，以及它们各自的访问模式有多不同。
最显而易见的是向量数据——每个文档 chunk 经过 Embedding 模型编码后生成的高维向量，用于语义相似度检索。向量数据的访问模式非常独特：写入是批量的（一次性灌入大量文档），读取是近似最近邻搜索（ANN），要求毫秒级延迟返回 Top-K 结果。这种访问模式需要专门的索引结构（HNSW、IVF 等）来支撑，传统的 B-Tree 或哈希索引在这个场景下完全无用。
但只有向量远远不够。每个 chunk 还有对应的原始文本——这是最终要塞进 LLM Prompt 的内容。向量库检索返回的是"最相似的 chunk ID"，你还得拿着这个 ID 去取回原文。有些向量数据库（如 Milvus、Qdrant）支持在向量旁边附带存储 payload/原文，但当 chunk 文本很长或者需要存储多种格式（Markdown 原文、清洗后纯文本、HTML 渲染版本）时，把所有内容都塞进向量库不是好主意——会严重影响向量索引的内存效率和构建速度。
还有结构化元数据——文档来源、作者、创建时间、所属部门、知识类目、版本号、权限标签等。这些元数据的访问模式是精确查询和范围过滤（“只看法务部门的文档”、“只看2024年之后的”），这恰恰是关系数据库的强项，向量库在这方面先天不足。
最后是文档级的管理信息——原始文件的存储路径、文档和 chunk 之间的父子关系、chunk 之间的前后顺序关系、文档的解析状态和版本记录。这些信息和检索无关，但对知识库的日常运维（增删改查文档、追溯 chunk 来源、支撑增量更新）至关重要。
这四类数据的访问模式、性能要求、存储特性完全不同。试图用单一存储组件搞定所有需求，结果一定是哪个需求都满足得不好。这就是 RAG 存储架构必须分层的根本原因。
1.2 典型的三层存储架构
理解了为什么要分层，就可以来看实际项目中最常见的存储架构了。大多数生产级 RAG 系统的存储层都可以归结为三层结构：向量检索层、内容存储层、管理与元数据层。三层各司其职，通过 chunk_id 和 document_id 这两个核心标识串联在一起。
向量检索层是整个架构中对性能要求最高的部分，它只负责一件事：根据查询向量快速找到最相似的 chunk_id。这一层的核心是向量数据库和它的索引结构。具体选型上，专用向量库（Milvus、Qdrant、Weaviate）在大数据量下的性能和稳定性最好，Milvus 支持分布式部署、数据分片和多种索引策略（HNSW 适合高召回场景，IVF_PQ 适合内存受限场景），是千万级以上向量规模的首选。如果规模在百万以下且团队已有 PostgreSQL 基础设施，pgvector 插件是性价比极高的方案——一个数据库同时承担向量检索和结构化存储的角色，少一个运维组件就少一份心智负担。Weaviate 的特色在于原生支持混合检索（向量 + BM25），适合对关键词精确匹配有强需求的场景。
内容存储层负责存放 chunk 的原始文本和解析后的结构化内容。最常见的做法是直接用关系数据库（PostgreSQL/MySQL）的一张 chunk 表来存：chunk_id 主键、chunk_text 存原文、document_id 外键关联到文档表。也有团队把原文存在向量库的 payload 字段里，省去一次跨库查询——但这会增加向量库的存储压力，而且当你需要对原文做全文搜索、正则匹配这类操作时，向量库的 payload 查询能力就捉襟见肘了。另一种常见方案是用 Elasticsearch 同时承担原文存储和 BM25 关键词检索的角色，一石二鸟。
管理与元数据层用关系数据库来实现是最自然的选择。这一层通常包含几张核心表：文档表（document_id、文件名、来源、上传时间、解析状态、版本号）、chunk 元数据表（chunk_id、document_id、在文档中的位置序号、chunk 类型标记、标题层级路径、业务标签）、以及document-chunk 映射表（维护父子关系，支撑多级索引和增量更新时的批量删除）。这些表看起来普通，但对知识库的长期运维极其重要——当你需要"删除某份过期文档的所有 chunk"或者"查看某个回答引用了哪篇文档的第几个段落"时，没有这层管理信息就寸步难行。
三层之间的数据流是这样的：文档入库时，原始文件经解析分块后，chunk 文本写入内容存储层，对应的向量写入检索层，元数据和文档信息写入管理层，三处共用同一个 chunk_id。检索时方向反过来——查询向量在检索层做 ANN 搜索拿到 chunk_id 列表，再分别去内容层取原文、去管理层取元数据用于后续过滤和溯源。
1.3 不同规模下的架构演进
存储架构不是一步到位的，它应该随着数据规模和业务复杂度的增长而演进。一上来就搞一套"大而全"的分布式架构，既浪费资源也增加了维护成本。反过来，只用一个 SQLite 或 ChromaDB 撑着也走不远。理解架构在不同阶段该长什么样，是面试中非常有区分度的一个点。
早期/原型阶段（< 10 万 chunks）：这个阶段的核心诉求是快速验证效果。用 pgvector 把向量、原文、元数据全塞在一个 PostgreSQL 里是最务实的选择——一个chunks表搞定所有事情，字段包括 chunk_id、document_id、chunk_text、embedding（vector 类型）、metadata（JSONB 类型）。检索就是一条 SQL：先 WHERE 过滤元数据，再 ORDER BY embedding 的余弦距离。一个库、一张表、一条查询，运维为零。ChromaDB 或 FAISS 也行，但它们对元数据过滤的支持弱，稍微有点业务逻辑的过滤需求就得在应用层自己写。
成长阶段（10 万 ~ 500 万 chunks）：pgvector 在这个量级开始出现性能瓶颈——ANN 查询延迟显著上升，尤其是在高并发场景下。这时候应该把向量检索拆出来交给专用向量库（Milvus Lite 或 Qdrant），原文和元数据继续留在 PostgreSQL。拆分的好处不只是性能：向量库可以独立扩缩容、独立调参、独立升级，不影响业务数据库的稳定性。如果业务上有 BM25 关键词检索的需求（大概率有），这时候引入 Elasticsearch 做内容存储兼关键词搜索层也是合理的。
规模化阶段（> 500 万 chunks）：存储架构要认真考虑分布式和高可用了。Milvus 支持分片（Sharding）和多副本，可以水平扩展到亿级向量。数据需要按业务维度做分区（按租户、按知识库、按时间），避免全量扫描。元数据层也要考虑读写分离和索引优化，避免复杂的元数据过滤查询成为性能瓶颈。
1.4 多级索引在存储层的落地
存储架构设计中有一个精巧的机制值得单独拎出来说——多级索引的存储实现。这个机制直接影响检索质量，但它的落地本质上是个存储设计问题。
核心思想是：检索时用细粒度的小 chunk 做匹配（精准），生成时用粗粒度的大 chunk 提供上下文（完整）。要实现这一点，存储层需要同时维护两级 chunk，并且建立它们之间的映射关系。
具体的存储设计是这样的：chunk 表中每条记录增加两个字段——parent_chunk_id（指向父级 chunk）和chunk_level（标记是 child 还是 parent）。Child chunk（比如 256 token）和 Parent chunk（比如 1024 token）各自独立存储，child 的parent_chunk_id指向它所属的 parent。向量检索层只索引 child chunk 的向量，parent chunk 不做向量索引。检索时在 child 级别做 ANN 搜索，命中后通过parent_chunk_id回溯到 parent，取 parent 的原文送给 LLM。
这个设计还可以进一步扩展到三级：在 parent 之上再加一层document summary（文档摘要）。对每篇文档生成一段摘要并存储在 chunk 表中（chunk_level = ‘summary’），也做向量索引。检索时先在 summary 层做一次粗筛确定相关文档，再到这些文档的 child chunk 中做细粒度搜索。这种"先粗后细"的路由可以在知识库特别大时（比如覆盖几百份文档）显著减少无关文档的干扰。
1.5 索引更新
存储架构设计中还有一个绕不开的话题——知识库更新。文档会新增、修改、删除，存储层必须有机制来应对这些变化，否则用户检索到的就是过时甚至错误的知识。
增量更新的核心难点在于分块边界的不稳定性。一篇文档修改了中间一段话后重新分块，新旧 chunk 的切分位置很可能完全对不上——不是简单地"某个 chunk 内容变了"，而是整篇文档的 chunk 列表都变了。所以增量更新不能做 chunk 级别的 diff，只能做文档级别的替换：先通过 document_id 删除该文档的所有旧 chunk（从向量层、内容层、管理层三处都要删），再把重新分块后的新 chunk 全量写入。
这个操作对存储层的要求是：三层存储的删除和写入必须保持一致性。如果向量层删了但管理层没删，就会出现"幽灵元数据"；如果内容层写了但向量层没写成功，就会出现"搜不到但实际存在"的 chunk。生产环境中通常的做法是将三层的写入操作封装在一个事务或者补偿机制中——如果全在 PostgreSQL 里（pgvector 方案），天然有事务保障；如果是多库架构，就需要先写管理层记录更新任务的状态，再异步执行向量层和内容层的更新，通过状态机保证最终一致性。
另外，文档管理表中的版本号和更新时间戳在检索侧也有用。当同一个话题在不同版本的文档中有冲突描述时，检索策略可以基于这些元数据做时间衰减加权——越新的 chunk 排序越靠前。
1.6 权限隔离
如果你的 RAG 系统面向多个用户或多个业务线（这在企业级应用中几乎是必然的），存储架构还需要考虑数据隔离和权限控制。
最直接的隔离方式是按租户做物理隔离——每个租户一个独立的向量库 Collection（Milvus 的术语）或 Namespace（Pinecone 的术语），甚至独立的数据库实例。这种方式隔离性最好、没有数据泄露风险，但运维成本高，资源利用率也低。
更常见的做法是逻辑隔离——所有租户的数据混在一个向量库中，但每个 chunk 的元数据里带上tenant_id，检索时强制加上tenant_id的过滤条件。这种方式资源效率高，但要求向量库支持高效的元数据过滤，而且应用层必须保证不会漏掉tenant_id的过滤——一旦漏掉，就是数据越权访问的安全事故。
Milvus 的 Partition Key 机制为逻辑隔离提供了很好的底层支持：把tenant_id设为 Partition Key 后，同一个租户的数据会被自动路由到同一个 Partition 中，检索时只在对应 Partition 内搜索，既有物理隔离的性能优势，又不需要为每个租户手动创建 Collection。
2、参考回答
我们项目中 RAG 的存储架构是一个三层的分层设计。最上层是向量检索层，用的 Milvus，只存 chunk 的向量和 chunk_id，专门做 ANN 搜索。中间是内容存储层，chunk 原文存在 PostgreSQL 里，同时部署了 Elasticsearch 做 BM25 关键词检索，向量和关键词两路结果用 RRF 融合。底层是管理与元数据层，也在 PostgreSQL，主要是文档表和 chunk 元数据表，记录来源、版本号、时间戳、业务标签，支撑元数据前置过滤和知识库日常运维。三层通过 chunk_id 和 document_id 贯穿。
在 chunk 组织上用了多级索引——256 token 的 child chunk 建向量索引用于检索，1024 token 的 parent chunk 只存原文不建索引，命中 child 后通过 parent_chunk_id 回溯取完整上下文送给 LLM。索引更新是文档级替换，因为重新分块后切分位置会变，没法做 chunk 级增量，检测到文档变更就通过 document_id 把三层里的旧数据全删再写入新的，多库之间通过状态机保证最终一致性。多租户隔离用了 Milvus 的 Partition Key，按 tenant_id 自动分区，兼顾了隔离性和资源效率。这套架构也不是一步到位的，早期用 pgvector 单库搞定所有事，数据量上来之后才拆分成现在的多组件架构。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
为什么要学习大模型？
我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。
大模型入门到实战全套学习大礼包
1、大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
2、大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
3、AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
4、大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
5、大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
适用人群
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
