跳到正文

RAG 知识库怎么存?

向量数据库选型、元数据管理及索引结构设计要点

原题：在检索增强生成（RAG）系统中，知识库通常以何种形式进行存储？请说明向量数据库的选择、元数据管理以及索引结构的设计考虑。

向量检索 · 安克科技真题

30 秒回答

  1. 向量数据库选型需考虑规模、延迟、成本三要素
  2. 元数据设计要支持过滤和排序
  3. 索引结构需权衡召回率与速度
  4. 实际落地常用混合检索（向量+关键词）

回答与解析

答案要点

  • 向量数据库选型需考虑规模、延迟、成本三要素
  • 元数据设计要支持过滤和排序
  • 索引结构需权衡召回率与速度
  • 实际落地常用混合检索（向量+关键词）
  • 需考虑数据更新和版本管理

知识库存储形式

RAG知识库采用双轨存储：向量存储（语义检索）+ 文档存储（原文召回），二者通过doc_id关联。

向量数据库选择

场景 推荐方案 理由
百万级/快速验证 FAISS、Milvus Lite 轻量、易部署
千万级/生产环境 Milvus、Pinecone、Weaviate 分布式、高可用
十亿级/超大规模 自研或云厂商方案（阿里云OpenSearch、AWS OpenSearch） 成本可控、深度定制

核心考量：延迟（<100ms）、召回率（Top5>90%）、成本（向量存储比原文大5-10倍）。

元数据管理

# 典型元数据结构
{
    "doc_id": "uuid",
    "source": "api_doc_v2.3",      # 来源追溯
    "category": "payment",          # 业务分类
    "chunk_index": 3,               # 分块序号
    "timestamp": 1699123456,        # 版本控制
    "access_level": "internal",     # 权限标记
    "title": "退款流程"             # 用于重排序
}

设计要点：

  • 支持预过滤（如where category='payment'），减少向量搜索空间
  • 保留原文存储位置，避免向量库膨胀

索引结构设计

  1. 向量索引：HNSW（平衡速度与召回）或 IVF（内存受限时）
  2. 倒排索引：BM25/关键词索引，用于混合检索
  3. 分层索引：热点数据内存HNSW + 冷数据磁盘索引

生产实践：90%场景用向量+关键词混合检索（RRF融合），纯向量检索在专有名词、ID查询上效果差。

口语版讲法(约4分钟)

  • 本质是存储与检索的权衡
  • 向量库选型分场景
  • 元数据是过滤利器
  • 索引结构要混搭
  • 风险与取舍

这道题其实在问，RAG系统的知识库存储，本质上是怎么在语义理解效率和工程成本之间做权衡。说白了，知识库不是简单存一堆文本，而是要同时支持两种检索：一种是向量检索，靠语义相似度找内容；另一种是关键词检索，靠精确匹配。真正落地的系统，通常两条腿走路，通过doc id把向量库和文档库关联起来。

先说向量数据库的选型。很多人一上来就问哪个库最好，其实得看场景。如果你只是百万级数据量做快速验证，FAISS或者Milvus Lite就够了，轻量好部署，成本也低。但如果是千万级的生产环境，比如电商客服系统，每天几百万次查询，那就要上Milvus、Pinecone或者Weaviate这种分布式方案，保证高可用和低延迟。要是到了十亿级，比如超大规模的文档库，我倾向于用云厂商的托管服务，像阿里云OpenSearch，或者自己定制，因为这时候成本是主要矛盾，向量存储比原文大5到10倍，得精打细算。核心指标就三个：延迟要低于100毫秒，召回率Top5要超过90%，成本要可控。

再一个关键是元数据管理。很多人只关注向量本身，忽略了元数据，其实元数据是提升检索效率的利器。举个例子，在客服退款场景里，知识库里既有支付相关的文档，也有物流相关的，如果不加过滤，用户问退款时可能会把物流文档也召回来。所以我会在每条向量旁边挂元数据，比如业务分类、时间戳、权限等级。查询时先根据元数据做预过滤，比如只查category等于payment的，这样向量搜索空间能缩小一半以上，召回质量也更高。另外元数据还能做版本控制，比如文档更新了，通过时间戳就能只查最新版本。

索引结构上，我倾向混合方案。向量索引用HNSW，它在速度和召回率之间平衡得最好，如果内存受限可以用IVF。但纯向量检索有硬伤，比如用户查订单号‘ORD123456’，向量检索几乎找不到，因为语义上它和任何文本都不像。这时候就得配合倒排索引，用BM25做关键词匹配。生产实践中，90%的场景我都会用向量加关键词的混合检索，用RRF算法融合两个结果集。这样既保语义又保精确。另外还可以做分层，热点数据放内存HNSW，冷数据放磁盘索引，提升整体吞吐。

这里有个坑：索引设计不能光看检索速度，还得考虑数据更新。如果知识库频繁改动，比如每天新增几万条文档，那索引重建就是个大问题。常见失败场景是，为了追求实时性直接增量插入，结果图索引的局部性被破坏，召回率慢慢下降。我上线时会特别关注这个问题，通常用双缓冲策略，一个主索引服务查询，一个影子索引后台重建，重建完原子切换。前提是业务能接受分钟级的更新延迟。

另外还有一点，元数据的过滤顺序也很讲究。是先过滤再向量搜索，还是先向量搜索再过滤？这直接影响延迟，不同数据库的实现不一样，像Pinecone是先过滤再搜索，而Milvus可以配置。我通常会根据过滤条件的筛选率来选，如果过滤能把候选集压到10%以下，那就先过滤，否则先搜索再过滤更高效。

所以整体来看，我更倾向把知识库存储看作一个系统工程，不是选个向量库就完事了。元数据的设计、索引的混合策略、更新的容错机制，每块都得根据业务场景做取舍。

关键一句:元数据过滤顺序影响延迟，需根据筛选率决定先过滤还是先搜索

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你在做一个电商客服的RAG系统，用户问“退款到哪了”，系统得先去知识库里找退款流程。那这个知识库里的文档，你具体是怎么存的？是只存向量，还是也要存原文？

  2. 问法 2 · 层层追问

    RAG系统里知识库的数据一般怎么存？……那向量数据库你怎么选？……除了向量，元数据怎么管理？比如我要按产品类别过滤搜索结果，你会在索引里怎么设计？

  3. 问法 3 · 直球架构

    直接说下RAG知识库的存储架构：向量数据库选型、元数据设计、索引结构，这三块你分别怎么考虑？比如千万级数据，延迟要求100ms以内，你会怎么搭？

同模块相关题目