你项目中 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、embeddingvector 类型、metadataJSONB 类型。检索就是一条 SQL先 WHERE 过滤元数据再 ORDER BY embedding 的余弦距离。一个库、一张表、一条查询运维为零。ChromaDB 或 FAISS 也行但它们对元数据过滤的支持弱稍微有点业务逻辑的过滤需求就得在应用层自己写。成长阶段10 万 ~ 500 万 chunkspgvector 在这个量级开始出现性能瓶颈——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 系统面向多个用户或多个业务线这在企业级应用中几乎是必然的存储架构还需要考虑数据隔离和权限控制。最直接的隔离方式是按租户做物理隔离——每个租户一个独立的向量库 CollectionMilvus 的术语或 NamespacePinecone 的术语甚至独立的数据库实例。这种方式隔离性最好、没有数据泄露风险但运维成本高资源利用率也低。更常见的做法是逻辑隔离——所有租户的数据混在一个向量库中但每个 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 单库搞定所有事数据量上来之后才拆分成现在的多组件架构。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。