RAG 的存储分工

我们打开主流开源或商业级 RAG 系统的底层架构与 docker-compose.yml，可以看到几乎完全统一的存储分工：

1. Dify（全球标星最高的一体化 LLM / RAG 应用平台）

Dify 的底层存储设计是这一分工的代表：

• 源文件（PDF、Docx、Markdown 等）：默认驱动即为 S3 协议兼容的对象存储（本地部署标配 MinIO，云端部署使用 AWS S3 / 阿里云 OSS / Cloudflare R2）。上传的原文档直接进 Bucket，前端查看或下载均走预签名 URL（Presigned URL）。
• 元数据、权限与会话：存储在 PostgreSQL，记录文件解析状态、知识库归属、Tenant 关系等。
• 向量数据与索引：默认配置直接使用 PostgreSQL + pgvector，在超大规模或特定集群下可无缝平替为 Milvus / Qdrant / Weaviate。

---

2. RAGFlow（主打复杂深度文档理解与精准解析的顶级开源 RAG）

RAGFlow 对各种排版复杂的 PDF、表格、扫描件做多模态解析（DeepDoc 引擎），对存储的依赖更清晰：

• 源文件及中间解析图片：由 MinIO (对象存储) 统一托管。文档切出的图表截图、OCR 原始图片、PDF 原件全在 MinIO。
• 分块文本与混合召回：使用 Elasticsearch (或 Infinity)。ES 同时负责存放分词后的 Chunks 文本、BM25 倒排索引以及密集向量索引，实现高精度的混合多路召回。
• 系统元数据与事务：早期采用 MySQL，后续逐步推荐支持 PostgreSQL，专门管理任务队列、知识库配置和用户信息。

---

3. FastGPT（国内高并发企业知识库与工作流引擎）

FastGPT 的设计方案：

• 源文件：同样采用 MinIO（早期版本也曾利用 MongoDB GridFS 作为文件系统存储二进制，新版均全面拥抱 MinIO/S3 体系）。
• Chunks 与向量数据：使用 PostgreSQL + pgvector。PG 中建有明确的外键或字段 file_id 指向对象存储中的文件，同时用 pgvector 跑向量相似度匹配。
• 业务状态数据：搭配 MongoDB 维护灵活无固定 Schema 的应用编排与工作流状态。

---

4. 商业云端产品（如 AWS Bedrock Knowledge Bases、Azure AI Search）

如果考察公有云原生的 RAG 方案：

• AWS Bedrock 知识库：官方强制绑定 AWS S3 作为数据源输入（用户将文档扔进 S3 Bucket），向量层推荐绑定 OpenSearch Serverless (向量引擎) 或 Amazon RDS for PostgreSQL (pgvector)。
• Azure AI Search：通常将文档保存在 Azure Blob Storage（微软的对象存储），配置 Indexer 定时增量同步文件、解析切片，再写入 Azure AI Search 内部的混合向量索引。

---

总结：

1. 职责分离：几十 MB 到数 GB 的原始 PDF/扫描件只发生全量读写，不参与查询计算，对象存储每 GB 成本仅为数据库云硬盘的几分之一到十分之一。
2. 计算下推：解析服务（如基于 Python/MinerU/PaddleOCR 的 Worker）从对象存储并发拉取文档，切片、Embedding 后直接流式写入向量库，数据库永远无需承受大文件 I/O 带来的内存颠簸与备份瓶颈。