跳到正文

向量数据库 vs 传统数据库怎么选？

RAG 系统中结构化与非结构化数据混合存储与检索方案

原题：在RAG系统中，知识库数据通常以何种方式存储？请比较向量数据库与传统数据库的优劣，并说明如何结合结构化与非结构化数据进行高效存储与检索。

重排与优化 · 安克科技真题

30 秒回答

  1. 向量数据库的核心原理（embedding+相似度检索）与传统数据库的差异
  2. 向量库与关系型数据库各自的优劣场景
  3. 混合检索架构设计（多路召回、重排序）
  4. 结构化与非结构化数据的融合策略

回答与解析

答案要点

  • 向量数据库的核心原理（embedding+相似度检索）与传统数据库的差异
  • 向量库与关系型数据库各自的优劣场景
  • 混合检索架构设计（多路召回、重排序）
  • 结构化与非结构化数据的融合策略

知识库存储方式

RAG知识库的核心存储形态：

  • 向量数据库：文本/图像等embedding存储，支持语义相似度检索
  • 传统数据库：结构化元数据（来源、时间、权限等）+ 原始内容
  • 对象存储：原始文档、图片、音视频等大文件

向量库 vs 传统数据库

维度 向量数据库 传统数据库
核心能力 语义相似度（ANN） 精确匹配、范围查询、聚合计算
适用场景 "找相似内容" "找ID=123且价格>100"
索引结构 HNSW、IVF、PQ等近似索引 B+树、哈希、倒排
精度/召回 近似结果，存在漏召 精确结果
扩展性 高维向量检索优化 事务一致性保障

关键洞察：两者不是替代关系，是互补关系。

混合存储架构实践

分层设计：

检索层：向量库（Milvus/Pinecone/Elasticsearch）→ 语义召回Top-K
过滤层：关系型数据库（MySQL/PostgreSQL）→ 元数据精确过滤
重排层：Cross-encoder/BGE-reranker → 精排
生成层：LLM → 最终答案

结构化+非结构化融合策略：

  1. 多路召回（Multi-way Retrieval）

    • 向量检索：用户问题embedding → 语义相关文档
    • 关键词检索：BM25/倒排索引 → 精确匹配实体
    • 结构化查询：SQL过滤时间、品类、权限等

  2. 元数据增强向量检索

    • 向量存储时携带结构化标签（{"doc_id": "xxx", "category": "售后", "valid_until": "2024-12"}）
    • 检索后先用结构化条件过滤，再送入LLM

  3. 统一查询接口

    • 用户问题先过NL2SQL/意图识别，拆分为"语义检索条件" + "结构化过滤条件"
    • 示例："去年手机类的退货政策" → 向量检索"退货政策" + SQL过滤category='手机' AND year=2023

选型建议：中小规模用PostgreSQL+pgvector一体化；大规模分离，向量库专注ANN，关系库负责事务和复杂查询。

口语版讲法(约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，中间用消息队列异步同步。前提是团队有能力维护两套系统，否则运维成本会失控。

还有一个延伸点，就是当知识库频繁更新时，向量库的增量索引怎么保持实时性和质量，比如软删除和异步重建的策略，这其实挺考验工程细节的。

所以整体上，我会把 RAG 的存储看成 语义通道加精确通道的组合，核心是理解不同检索方式的适用边界，然后在业务场景里做取舍，而不是迷信某个技术。

关键一句:知识库频繁更新时，向量库的增量索引如何平衡实时性和检索质量，比如软删除和异步重建策略。

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你们要给电商客服做一个知识库，里面有商品描述、售后政策这些文本，也有价格、库存这种结构化数据。用户问‘去年买的红色手机怎么退货’，你打算怎么存这些数据，让检索又快又准？

  2. 问法 2 · 层层追问

    RAG系统里知识库一般怎么存？……那语义检索和精确查询怎么平衡？……如果既有非结构化文本又有结构化字段，比如时间、类别，你怎么设计存储和检索？

  3. 问法 3 · 直球架构

    设计一个RAG知识库的存储架构，支持向量检索和结构化元数据过滤。你会选什么数据库？怎么组织数据？多路召回和重排怎么落地？

同模块相关题目