MUYI · 后端工程师的生产级知识体系

Appearance

向量检索选型：pgvector / Redis 8 / Milvus / Qdrant ​

向量检索是 RAG 的召回地基，选型错一次，全量重导+重建索引的迁移成本指数级上涨。一句话定位：在规模、过滤、运维三条轴上为你的数据挑一个 ANNS 引擎。

2026 年生产格局已收敛：pgvector=留在 PostgreSQL 内的最简运维。Milvus=超大规模分布式。Qdrant=Rust 高性能+强元数据过滤。Pinecone=托管领导者。Redis 8 的 Vector Sets 把向量下沉为缓存层原生能力。

面试里它是 RAG 题的工程分水岭：答得出"各方案边界+决策轴"，比背八个引擎的参数值钱得多。RAG 全局架构见 RAG体系与项目定位。

1 为什么选型难：规模、过滤、运维三条轴 ​

  • 规模轴：10 万条与 10 亿条是两个世界——前者任何引擎单机内存索引随便放，后者必须分布式+磁盘索引。问题从"召回率"变成"分片、副本、一致性"。
  • 过滤轴：生产检索几乎从不是裸 ANN，而是"向量相似 + 元数据条件"。例如部门=某部门 且 时间>某日期 且 状态=发布。条件能不能下推进索引、下推后召回率掉多少，各家差异巨大。
  • 运维轴：最容易被低估——多引一个专用组件就多一套要养的系统。反过来"复用已有 PG/Redis"的方案，运维增量接近零。

三条轴互相牵制：规模逼你上分布式，分布式抬高运维；过滤简单 SQL 就够，过滤复杂要专业引擎。选型本质是在三条轴的交点上找最便宜方案，而不是找"最强引擎"。

2 四层方案逐个拆 ​

1）pgvector：留在 PG 内，运维零增量 ​

PostgreSQL 扩展，提供 vector 列类型与距离算子（<=> 余弦、<-> L2、<#> 内积），两类 ANN 索引：

  • HNSW：图索引，建得慢、内存占用高，但查询快、召回稳；建索引定 m 与 ef_construction，查询期调 ef_search 权衡召回与延迟；
  • IVFFlat：倒排聚类，建得快、更省内存；质心靠数据采样，所以要先灌数据再建索引，查询期调 probes；
  • 建索引时绑定算子族（如 vector_cosine_ops），与查询算子必须匹配。
sql
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id        bigserial PRIMARY KEY,
  doc_id    bigint NOT NULL,
  content   text,
  embedding vector(1024)                 -- 维度建表即固定
);

CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);  -- 匹配 <=> 算子

SELECT id, content
FROM   chunks
WHERE  doc_status = 'published'          -- 元数据过滤 = 普通 WHERE，可与业务表 JOIN
ORDER  BY embedding <=> :query_vec       -- 余弦距离排序
LIMIT  50;

真正的卖点不在性能而在"零增量"：备份、主从、权限、监控、SQL 生态全部复用。向量与业务表同库 JOIN，元数据过滤就是 WHERE 子句，事务一致性白送。边界也明确：以单机纵向扩展为主，索引构建的内存与时间随规模陡增。千万级以内是舒适区，再往上要对照召回/延迟目标仔细压测。顺带一提：PostgreSQL 18（2025-09-25 GA）引入异步 I/O 子系统，读性能最高提升 3 倍——利好一切 PG 负载，但向量检索能力本身仍由 pgvector 提供，不因 PG 升级而改变。

2）Redis 8 Vector Sets：向量进缓存层 ​

Redis 8 起 Vector Sets 成为内置原生数据类型。VADD 写入向量（可附带属性），VSIM 做相似查询，底层自带 HNSW 索引——不是模块、不是插件，是数据结构级支持。官方基准称吞吐约高 27%，注意这是厂商自测口径，选型时当参考值而非结论。

定位是缓存层向量：

  • 内存级延迟（毫秒乃至亚毫秒），适合会话记忆、热点文档、实时个性化；
  • 内存即容量：float32 下千万条就是 GB 级起步，成本模型与磁盘型引擎完全不同；
  • 更常见的是"全量在专用向量库、热点子集在 Redis"的两层结构，而不是唯一真相源。
VADD docs 1024 FLOAT32 <bytes> ITEM item-42 ATTR dept=health   # 形态示意：写入+属性
VSIM docs 1024 FLOAT32 <query-bytes> COUNT 10 WITHSCORES FILTER dept=="health"

机制细节与 Valkey 生态分叉见 A 轨 版本演进-Redis8新特性与Valkey分叉。

3）Milvus：十亿级分布式 ​

超大规模的正解：云原生分布式架构、存算分离，组件一整套。组件包括多类协调节点与 data/query/index 节点，外加 etcd、消息队列、对象存储这类依赖。十亿级向量、多副本、多租户是它的主场。索引族最全（HNSW、IVF 系、DiskANN 乃至 GPU 索引），标量字段过滤内建。代价同样清晰：组件多等于运维重——没有平台团队别轻易自建。要么用托管版，要么先确认真的到了那个量级。

4）Qdrant：Rust 与 payload 过滤 ​

Rust 实现的性能取向引擎：单二进制起服务，单机体验极好，亦有分布式模式。杀手锏是 payload 过滤：可过滤字段建 payload 索引后，"向量相似 + 复杂条件"在索引层面联合执行（filtered search）。高选择性过滤下召回与延迟都稳——这正是第 1 节"过滤轴"上的最强答卷。另有稀疏向量内建（BM25 可直接在引擎内算），原生支撑混合检索；标量/二值/乘积量化选项压内存。

一句带过 MySQL：9.0 起也有了原生 VECTOR 类型，能存能算距离。但 ANN 索引与周边生态还不在一个量级，生产向量检索主力仍是上述几家。Pinecone 则是托管领导者：免运维、按量计费，代价是数据出域与合规要过审。

3 决策树：数据量、过滤复杂度、已有基础设施 ​

已有 PostgreSQL，且数据量千万级以内、过滤即 SQL 条件？
├─ 是 → pgvector（运维零增量，JOIN 与事务白送）
└─ 否
    │
    需要内存级延迟（会话/热点/实时），内存预算充足？
    ├─ 是 → Redis 8 Vector Sets（做热点层，全量另放）
    └─ 否
        │
        十亿级 / 多租户 / 多副本超大规模检索？
        ├─ 是 → Milvus（接受养一套分布式，或直接托管）
        └─ 否
            │
            过滤条件复杂、追求单机/小集群高性能？
            ├─ 是 → Qdrant（payload 过滤 + 量化）
            └─ 否 → Pinecone（托管免运维，合规先行）

两条使用原则。一是先问已有基础设施再问引擎排名——团队已经在养 PG/Redis，"零新增组件"的权重远高于 benchmark 名次。二是从约束最强的一条轴入手倒推：规模不够就不该上分布式，过滤不复杂就不必为过滤付溢价。

三轴速查：

方案规模轴过滤轴运维轴一句话定位
pgvector千万级内舒适区SQL WHERE，表达力最强档零增量（复用 PG）已有 PG 的默认答案
Redis 8 Vector Sets受内存预算约束属性过滤，偏简单条件复用 Redis 体系热点/会话层
Milvus十亿级主场标量字段过滤内建最重（分布式全家桶）有平台团队再上
Qdrant单机到集群payload 过滤最强档轻（单二进制起步）复杂过滤首选
Pinecone大托管能力范围内零（全托管）买服务免运维

4 与 RAG 的配合：混合检索与重排 ​

RAG 2.0 的召回链路不再是单路向量，而是"混合检索 + 重排"：

查询 → 向量化 ──→ ANN 召回 top-k（元数据过滤下推）──┐
      └───────→ BM25 关键词召回 top-k ──────────────┤→ 融合（RRF/加权）
                                                      ↓
                                  重排（cross-encoder 逐对打分）→ top-n 进上下文

选型影响链路的三个点：

  • 过滤下推：元数据条件必须"先过滤后召回"在引擎内完成。"召回完再 WHERE"会在高选择性条件下掏空召回率。pgvector（SQL WHERE）与 Qdrant（filtered search）在这一点上表达力与性能最稳。
  • 混合检索的落点：pgvector 可与 tsvector 同库同 SQL 实现 BM25+向量与 RRF 融合。Qdrant 稀疏向量内建，Milvus 亦支持稀疏向量。Redis Vector Sets 通常只承担向量热点层，关键词侧交给别的组件。引擎选择直接决定混合链路是"一个系统"还是"两个系统加胶水"。
  • 重排掩盖差距：ANN 召回 50~200 条喂给 cross-encoder 重排是常见配置，重排才是延迟大头。向量库之间的亚毫秒差距常被重排吃掉，别为 0.5 ms 放弃运维便利。
  • 先建评估集再选型：recall@k / nDCG 的离线评估集（人工标注的 query-相关 chunk 对）是选型的裁判。厂商 benchmark 用的多是公开数据集，与你的数据分布、过滤形态差得很远。"自己数据上测出的召回曲线"才是唯一可信依据。

切分质量决定召回上限，检索选型决定下限——切分侧实战见 RAG切分策略实战。

5 成本与运维真实账本 ​

  • 内存账：float32、1024 维约 4 KB/条原始向量，100 万条约 4 GB。HNSW 图还要再叠一层邻居结构。上亿条不量化就得磁盘索引或分布式。
  • 人力账：pgvector 运维增量接近零（DBA 体系直接复用）。Redis 团队熟悉度高但内存单价贵。Milvus 一套分布式组件起步 3~5 个，没有平台团队就是负资产。Qdrant 单机门槛最低。Pinecone 免运维但账单随流量走。
  • 迁移账：向量库之间迁移=全量重导+重建索引+双写切换，是最贵的一笔。选型时给"长大了怎么办"留路径（pgvector 起步、量大迁 Qdrant/Milvus 是常见演进，反向很少）。
  • 隐性账：每引入一个专用引擎，就多一份监控、备份、安全补丁、值班认知负担。小团队的真实成本里人力永远贵过机器。

面试追问链 ​

  • 四层方案一句话定位？→ pgvector 留在 PG 最简运维；Redis 8 Vector Sets 缓存层向量；Milvus 超大规模分布式；Qdrant Rust 高性能+强过滤；Pinecone 托管领导者；
  • 选型看哪几条轴？→ 规模、过滤、运维三条轴互相牵制，在交点上找最便宜方案；
  • pgvector 两种索引怎么选？→ HNSW 建慢查快召回稳，IVFFlat 建快省内存但要先灌数据再建（采样质心）；查询期分别调 ef_search 与 probes；
  • 元数据过滤为什么关键？→ 生产是"向量+条件"；先过滤后召回（下推）与召回后过滤的召回率差距在高选择性条件下是灾难级的；
  • Redis 8 Vector Sets 是什么？→ 原生数据类型级支持，VADD/VSIM、内置 HNSW；官方基准吞吐约高 27%（厂商自测口径）；
  • MySQL 能做向量检索吗？→ 9.0 起有原生 VECTOR 类型，能存能算距离，ANN 索引与生态未到主力水位；
  • PostgreSQL 18 对向量检索的影响？→ 异步 I/O 子系统读性能最高 3 倍提升（2025-09-25 GA），向量检索本身仍靠 pgvector；
  • 什么时候必须上 Milvus？→ 十亿级/多租户/多副本，且养得起或直接买托管；
  • 混合检索链路怎么画？→ 向量+BM25 双路召回 → RRF/加权融合 → cross-encoder 重排 → top-n 进上下文；
  • 为什么说别为亚毫秒差距换引擎？→ 重排才是延迟大头，运维增量是长期成本。

面试官视角小结 ​

这道题的评分梯度：能背出四个名字是及格。能说出每家的"一句话定位"与索引类型（HNSW/IVFFlat、VADD/VSIM），说明做过功课。能主动把讨论拉到规模/过滤/运维三条轴，讲清"过滤下推 vs 召回后过滤"的召回率差异。这是有生产经验的信号。

最强的候选人不只选引擎，而是把选型放回 RAG 全链路。全链路包括混合检索落点、重排掩盖的延迟差距、迁移账与人力账。并能给出"pgvector 起步、量大再迁"这种有退出路径的演进策略。反过来，只报 benchmark 数字、不问已有基础设施与团队运维能力的答案，恰恰暴露了没真选过型。

2026-10 新增（2026 技术栈补全）。