面试题 · 检索
搜索「RAG架构」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在RAG系统中，知识库数据通常以何种方式存储？请比较向量数据库与传统数据库的优劣，并说明如何结合结构化与非结构化数据进行高效存储与检索。
RAG知识库的核心存储形态：
| 维度 | 向量数据库 |
|---|
学习内容与项目面试，在同一条路上。
| 传统数据库 |
|---|
| 核心能力 | 语义相似度（ANN） | 精确匹配、范围查询、聚合计算 |
| 适用场景 | "找相似内容" | "找ID=123且价格>100" |
| 索引结构 | HNSW、IVF、PQ等近似索引 | B+树、哈希、倒排 |
| 精度/召回 | 近似结果，存在漏召 | 精确结果 |
| 扩展性 | 高维向量检索优化 | 事务一致性保障 |
关键洞察：两者不是替代关系，是互补关系。
分层设计：
检索层：向量库（Milvus/Pinecone/Elasticsearch）→ 语义召回Top-K
过滤层：关系型数据库（MySQL/PostgreSQL）→ 元数据精确过滤
重排层：Cross-encoder/BGE-reranker → 精排
生成层：LLM → 最终答案结构化+非结构化融合策略：
多路召回（Multi-way Retrieval）
元数据增强向量检索
{"doc_id": "xxx", "category": "售后", "valid_until": "2024-12"}）统一查询接口
category='手机' AND year=2023选型建议：中小规模用PostgreSQL+pgvector一体化；大规模分离，向量库专注ANN，关系库负责事务和复杂查询。
场景切入
假设你们要给电商客服做一个知识库，里面有商品描述、售后政策这些文本，也有价格、库存这种结构化数据。用户问‘去年买的红色手机怎么退货’，你打算怎么存这些数据，让检索又快又准？
层层追问
RAG系统里知识库一般怎么存？……那语义检索和精确查询怎么平衡？……如果既有非结构化文本又有结构化字段，比如时间、类别，你怎么设计存储和检索？
直球架构
设计一个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，中间用消息队列异步同步。前提是团队有能力维护两套系统，否则运维成本会失控。
还有一个延伸点，就是当知识库频繁更新时，向量库的增量索引怎么保持实时性和质量，比如软删除和异步重建的策略，这其实挺考验工程细节的。
所以整体上，我会把 RAG 的存储看成 语义通道加精确通道的组合，核心是理解不同检索方式的适用边界，然后在业务场景里做取舍，而不是迷信某个技术。