向量检索怎么选方案
向量检索的选型基本由两件事决定：现有技术栈与数据规模。已有 Postgres 就用 pgvector 加一列向量，能复用事务、SQL 与现成的过滤条件；已有 Elasticsearch 则用 dense_vector 做向量与全文的混合检索；MongoDB 的向量能力主要随 Atlas 提供；数据规模与索引种类要求更高时，再考虑 Milvus 这类专用向量库，代价是多一套组件与同步链路。无论哪种，都要把过滤条件、召回率与运维成本放在一起权衡。
pgvector 示例
pgvector 示例
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE items (id bigserial PRIMARY KEY, name text, embedding vector(768)); -- 维度需与模型输出一致
-- HNSW 索引：适合在线查询，建索引比 ivfflat 慢但查询更稳
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops); -- 距离函数要与查询运算符匹配
-- 余弦距离近邻查询（<=> 为余弦距离运算符）
SELECT id, name FROM items
ORDER BY embedding <=> '[0.10, 0.22, 0.31]'
LIMIT 10;
-- 带结构化过滤：先按业务条件收窄，再走向量排序
SELECT id, name FROM items
WHERE category = 'guide'
ORDER BY embedding <=> '[0.10, 0.22, 0.31]' LIMIT 10;方案对照
| 方案 | 优势 | 注意点 |
|---|---|---|
| pgvector | 复用 Postgres 事务与 SQL，可与结构化条件组合 | 数据量大时要调 HNSW 参数与内存，注意索引构建耗时 |
| ES dense_vector | 向量与全文混合排序，过滤能力丰富 | 向量字段内存与堆开销高，维度与算子要先规划 |
| MongoDB Atlas Vector Search | 与文档数据同库，减少一条同步链路 | 自建部署需核对版本与组件支持范围 |
| 专用向量库（Milvus 等） | 面向大规模向量调优，索引类型多 | 多一套组件、监控与数据同步链路 |
典型使用场景
- RAG 检索：把文档切块后生成向量，按语义召回候选片段
- 以图搜图或商品相似推荐：相似度作为召回一环，再叠加业务排序
- 日志与工单聚类：向量召回加标签过滤，快速找相似历史问题
- 混合检索：关键词召回与向量召回合并后再重排，提升准确率
- 敏感内容匹配：向量近邻找出与样本高度相似的存量数据
基本信息
| 索引结构 | HNSW（在线查询常用）与 IVF 系列（构建快、需调聚类数） |
|---|---|
| 距离函数 | 余弦、欧氏、内积三种，必须与建索引时的算子类一致 |
| 过滤策略 | 前过滤（先筛再算）与后过滤（先算再筛），结果数量与延迟表现不同 |
| 维度约束 | 向量维度由嵌入模型决定，建表后通常无法直接改 |
| 评测指标 | recall@k 衡量召回质量，需用标注集评测而非凭感觉 |
向量只是召回的一环：RAG 类场景还要设计切块策略、权限与时间过滤、重排与召回率评测。先用小规模标注集验证效果，再扩容量与调索引参数。
距离函数必须与索引算子类一致：用余弦距离查询却按内积建索引，结果排序会完全不符合预期且不报错。
向量索引的内存占用随数据量线性增长：只在小表上测速度会严重低估容量需求，扩容前按全量数据与索引参数估算内存。