完整题目
在RAG系统中，知识库数据通常以何种方式存储？请比较向量数据库与传统数据库的优劣，并说明如何结合结构化与非结构化数据进行高效存储与检索。
本文目录
答案要点
- 向量数据库的核心原理（embedding+相似度检索）与传统数据库的差异
- 向量库与关系型数据库各自的优劣场景
- 混合检索架构设计（多路召回、重排序）
- 结构化与非结构化数据的融合策略
知识库存储方式
RAG知识库的核心存储形态：
- 向量数据库：文本/图像等embedding存储，支持语义相似度检索
- 传统数据库：结构化元数据（来源、时间、权限等）+ 原始内容
- 对象存储：原始文档、图片、音视频等大文件
向量库 vs 传统数据库
| 维度 | 向量数据库 | 传统数据库 |
|---|---|---|
| 核心能力 | 语义相似度（ANN） | 精确匹配、范围查询、聚合计算 |
| 适用场景 | "找相似内容" | "找ID=123且价格>100" |
| 索引结构 | HNSW、IVF、PQ等近似索引 | B+树、哈希、倒排 |
| 精度/召回 | 近似结果，存在漏召 | 精确结果 |
| 扩展性 | 高维向量检索优化 | 事务一致性保障 |
关键洞察：两者不是替代关系，是互补关系。
混合存储架构实践
分层设计：
检索层：向量库（Milvus/Pinecone/Elasticsearch）→ 语义召回Top-K
过滤层：关系型数据库（MySQL/PostgreSQL）→ 元数据精确过滤
重排层：Cross-encoder/BGE-reranker → 精排
生成层：LLM → 最终答案结构化+非结构化融合策略：
-
多路召回（Multi-way Retrieval）
- 向量检索：用户问题embedding → 语义相关文档
- 关键词检索：BM25/倒排索引 → 精确匹配实体
- 结构化查询：SQL过滤时间、品类、权限等
-
元数据增强向量检索
- 向量存储时携带结构化标签（
{"doc_id": "xxx", "category": "售后", "valid_until": "2024-12"}） - 检索后先用结构化条件过滤，再送入LLM
- 向量存储时携带结构化标签（
-
统一查询接口
- 用户问题先过NL2SQL/意图识别，拆分为"语义检索条件" + "结构化过滤条件"
- 示例："去年手机类的退货政策" → 向量检索"退货政策" + SQL过滤
category='手机' AND year=2023
选型建议：中小规模用PostgreSQL+pgvector一体化；大规模分离，向量库专注ANN，关系库负责事务和复杂查询。
换一种问法，检查是否真正理解
场景切入
假设你们要给电商客服做一个知识库，里面有商品描述、售后政策这些文本，也有价格、库存这种结构化数据。用户问‘去年买的红色手机怎么退货’，你打算怎么存这些数据，让检索又快又准？
层层追问
RAG系统里知识库一般怎么存？……那语义检索和精确查询怎么平衡？……如果既有非结构化文本又有结构化字段，比如时间、类别，你怎么设计存储和检索？
直球架构
设计一个RAG知识库的存储架构，支持向量检索和结构化元数据过滤。你会选什么数据库？怎么组织数据？多路召回和重排怎么落地？
练习口述回答 · 约4分钟
- RAG存储的本质是语义相似度+元数据过滤
- 向量库和传统库是互补，不是替代
- 混合架构：多路召回+元数据过滤+重排
- 落地风险和选型建议
这道题其实问的是[[RAG]]系统里知识库怎么存，本质是 语义相似度检索 和 精确条件过滤 怎么配合的问题。不是单纯比较哪个数据库好，而是要看场景做组合。
先说[[向量数据库]]和传统数据库的定位。向量库的核心是存 [[Embedding]]，用 [[ANN]] 算法比如 [[HNSW]] 或者 [[IVF]] 做近似检索，擅长找相似内容，比如用户问“退货政策”，它能召回语义相近的文档。但它不擅长精确匹配，比如查“订单号123”或者“价格大于100”这种，它搞不定。反过来，传统数据库像 MySQL、PostgreSQL 擅长精确查询、范围过滤、聚合统计，但做不了语义相似度。所以两者是互补关系，不是替代。
具体到业务场景，举个例子，一个电商客服系统，知识库里既有退款政策这种非结构化文档，也有订单状态、商品类目这种结构化数据。用户问“去年手机类的退货政策”，这里面包含两部分：语义上要搜“退货政策”，结构上要过滤“类目=手机”和“时间=去年”。如果只用向量库，搜出来的结果可能混入其他类目；只用关系库，搜不到语义相关的政策内容。所以 真正落地一定是混合架构。
我一般会这样设计：检索层用向量库做语义召回，拿到 Top-K 后，再用关系库做元数据精确过滤，比如按时间、类目、权限筛一遍，最后用 [[重排]] 模型比如 [[Cross-Encoder]] 精排，再把结果喂给 LLM。这个流程里，向量库负责召回率，关系库保证精确率，重排提升排序质量。
这里有个坑，就是元数据怎么跟向量关联。常见做法是在向量入库时把结构化标签作为属性存进去，比如 {"doc_id": "xxx", "category": "售后", "valid_until": "2024-12"}。检索时先向量召回一批候选，再用这些标签做过滤。但要注意，如果过滤条件太严格，可能把相关文档全滤掉，导致召回为空。所以 过滤条件要保留一定的宽松度，或者做多路召回，向量搜一条线，[[BM25]] 关键词搜一条线，SQL 查结构化数据一条线，最后合并。
选型上，中小规模我倾向用 PostgreSQL 加 pgvector 插件，一体化部署简单，不用维护两套系统。但大规模并发或者向量维度很高时，还是得分开，向量库用专门的如 Milvus，关系库用 MySQL，中间用消息队列异步同步。前提是团队有能力维护两套系统，否则运维成本会失控。
还有一个延伸点，就是当知识库频繁更新时，向量库的增量索引怎么保持实时性和质量，比如软删除和异步重建的策略，这其实挺考验工程细节的。