RAG检索增强生成实战：向量数据库选型与混合检索优化

大模型幻觉问题和私有知识缺失问题，现在主要靠RAG检索增强生成来解决。企业做知识库问答、合同审查、文档分析、AI Agent工具调用，链路基本都建立在RAG之上：先把知识切片向量化存进检索库，用户提问时先召回相关片段，再交给大模型生成回答。本文按向量数据库选型、切片策略、混合检索、重排序、效果评估几个环节拆开讲，给出可以直接落地的配置和结论。

一、RAG工作流拆解与各环节职责

一条完整的RAG链路包含六个环节：文档解析、切片、向量化、检索、重排序、生成。前五个环节决定召回质量，最后一个环节决定回答质量。常见的翻车案例是只优化生成环节、忽视召回，结果检索回来的片段文不对题，模型再强也答不准。

文档 → 解析 → 切片 → Embedding → 向量库+倒排索引 → 混合检索 → Rerank → 拼装Prompt → 生成

每个环节都要有对应的评测指标，后面单独说评估方法。

二、向量数据库选型对比：Milvus、Qdrant、Elasticsearch、pgvector

选型看四个维度：数据规模、元数据过滤能力、运维成本、生态完整度。不同量级选型结论差别很大。

• pgvector：挂在PostgreSQL里，百万级以内、不想引入新组件时首选，事务和SQL能力直接复用。
• Elasticsearch 8.x：原生支持向量字段（dense_vector + HNSW），还能同时建BM25倒排索引，混合检索在同一套API里完成，运维体系现成。
• Qdrant：Rust实现，单机二进制部署，REST接口简单，千万级向量内存友好，适合中小团队自建。
• Milvus：分布式架构，亿级向量和复杂标量过滤是强项，但组件多（etcd、MinIO、Pulsar），部署和运维成本高。

选型原则：数据量在百万级以内，优先pgvector或ES；千万级以上且过滤条件复杂，再上Milvus。不要一开始就上重组件。

三、切片策略与Embedding模型选择

切片决定检索颗粒度。固定长度切（如512字符）加100到200字符的重叠，是通用做法；结构化文档按标题、段落语义切，效果更好。切片太小碎片多，检索到不完整上下文；切片太大噪音多，命中精度下降。

Embedding模型推荐中文本地化效果好的，如bge-large-zh-v1.5（1024维）或更新的Qwen3-Embedding系列。向量维度并非越大越好，1024维对多数业务场景足够，维度翻倍存储和检索耗时也翻倍。

四、混合检索与RRF融合：关键词召回补向量盲区

纯向量检索在专有名词、型号、人名、缩写上召回很差，因为这些词在语义空间里没有区分度。叠加BM25关键词检索，再用RRF（Reciprocal Rank Fusion）融合两路结果，是生产环境的标准做法。以下以Elasticsearch为例：

POST /kb_index/_search
{
  "size": 20,
  "query": {
    "bool": {
      "should": [
        {"match": {"content": {"query": "服务器RAID磁盘阵列", "boost": 1}}},
        {"knn": {"field": "content_vector",
                 "query_vector": [0.021, ...],
                 "k": 20, "num_candidates": 200}}
      ]
    }
  },
  "rank": {"rrf": {"window_size": 20, "rank_constant": 60}}
}

RRF把两路召回各自排名做倒数求和，参数rank_constant默认60，window_size控制融合窗口。融合后按新分数取topK，进重排环节。

五、重排序与上下文压缩

混合检索返回的片段按相关度排序不精确，重排序用交叉编码器模型（如bge-reranker-v2-m3）对查询和候选片段逐对打分，把top20压到top5，精度明显提升。生成环节再按窗口大小做上下文压缩，避免塞入太多不相关内容拉低回答质量。

六、RAG效果评估与常见坑

上线前先建评估集：至少200条业务真实问题，标注正确答案片段。指标看召回率（Recall@k）、命中率（Hit Rate）、忠实度（Faithfulness）。常见坑：文档解析丢表格内容、切片把同一语义拆散、没有做问题改写（用户口语提问和文档表述对不上）、增量更新没做导致答案陈旧。解决顺序建议：先补解析和切片，再调混合检索，最后上重排，不要一上来就换模型。