告别向量检索不准：Embedding选型、索引构建与查询优化的配置实践
上个月给客户的知识库做语义搜索，上线后用户反馈"搜不准"：搜"怎么退款"，排第一的是"商品介绍"；搜"发票"，排第一的是"配送说明"。排查发现是 Embedding 模型没选对、索引没建好、查询参数没调优。花了一周把这三块调通，搜索 Top1 准确率从 45% 提到 82%。这篇把配置过程记录下来。
一、先诊断：向量检索不准的三个根因
语义搜索 = Embedding 向量化 + 向量索引 + 相似度查询。任何一环出问题都会导致搜不准：
| 问题 | 表现 | 根因 |
|---|---|---|
| Embedding 不匹配 | 同义句向量相似度低 | 模型没在对应领域微调 |
| 索引构建不当 | 查询慢或召回不全 | HNSW 参数没调，或用了暴力搜索 |
| 查询参数不对 | Top-K 里混了不相关结果 | 相似度阈值没设，过滤条件没加 |
先做这三点：选对 Embedding 模型、调优 HNSW 索引、加查询过滤。
二、Embedding 选型：通用模型 vs 领域微调
Embedding 模型决定了"语义相似度"的计算质量。通用模型（如 text-embedding-ada-002）对通用文本效果好，但对专业领域（如电商售后、医疗问答）效果差。
模型选型对比：
| 模型 | 维度 | 通用场景 | 领域场景 | 速度 |
|---|---|---|---|---|
| text-embedding-3-small | 1536 | 好 | 一般 | 快 |
| bge-large-zh | 1024 | 好 | 较好 | 中 |
| bge-large-zh-v1.5 | 1024 | 好 | 好 | 中 |
| 领域微调bge | 1024 | 一般 | 很好 | 中 |
选型建议：
- 先用通用模型跑基线：bge-large-zh-v1.5 对中文效果好，开箱即用
- 准备领域评测集：100-200 条 (query, 相关文档) 对，算 Top1/Top3 准确率
- 通用模型不达标再微调：用领域数据对 bge 做 fine-tuning，通常能提升 15-25%
- 维度不是越高越好：1536 维和 1024 维效果差异不大，但存储和计算差 50%
微调数据准备：
1. 收集领域内的 (query, 正例文档, 负例文档) 三元组
2. 正例：与 query 相关的文档（人工标注或点击数据）
3. 负例：与 query 不相关但容易混淆的文档（难负例）
4. 训练集 5000+ 条，验证集 500 条
5. 用 contrastive loss 训练，batch_size 32，epoch 3-5
踩坑提醒：不要用随机负例训练，模型学不到区分能力。必须用"难负例"（和正例语义相近但实际不相关的文档），微调效果才明显。
三、索引构建：HNSW 参数调优
向量索引决定了查询速度和召回率。HNSW（分层导航小世界图）是目前最常用的近似最近邻索引，两个关键参数：
HNSW 参数：
- M（图的度数）：每个节点的连接数，默认 16
- M 越大 → 召回率越高，内存占用越大，构建越慢
- M 越小 → 查询越快，召回率可能下降
- 推荐：M=16~32，1亿以内向量用16，1亿以上用32
- ef_construction（构建时搜索宽度）：构建时每层搜索的候选数，默认 200
- 越大 → 索引质量越高，构建越慢
- 推荐：ef_construction=200~400，对召回率要求高用400
查询参数：
- ef_search（查询时搜索宽度）：查询时搜索的候选数，默认 10
- 越大 → 召回率越高，查询越慢
- 推荐：ef_search=50~200，在线服务用100，离线批量用200
索引构建流程：
1. 向量归一化：所有向量做 L2 归一化，余弦相似度 = 内积
2. 选择距离度量：归一化后用内积（IP），比余弦相似度计算快
3. 设置 M=16, ef_construction=200
4. 批量插入：每次插入 1000 条，比单条插入快 5 倍
5. 构建完成后持久化，避免重启重建
实测效果：M=16, ef_construction=200, ef_search=100 时，100万向量查询延迟 5ms，召回率 98%。如果用暴力搜索，延迟 200ms，差了 40 倍。
四、查询优化：阈值过滤 + 重排序
向量检索返回 Top-K 后，不能直接把全部结果给用户，需要做过滤和重排：
查询优化三步：
1. 相似度阈值过滤：余弦相似度 < 0.5 的结果直接丢弃
- 阈值设太低 → 不相关结果混进来
- 阈值设太高 → 相关结果被误删
- 推荐：0.5~0.7，根据评测集调整
2. 元数据过滤：按文档类型、时间、分类等字段过滤
- 例如：只搜"售后政策"类文档，排除"商品介绍"
- 用标量过滤 + 向量检索的混合查询
3. 交叉编码器重排：对 Top-20 结果用 Cross-Encoder 重新打分
- 向量检索召回 Top-20
- Cross-Encoder 对 (query, doc) 对打分，取 Top-5
- 重排后准确率比纯向量检索高 20%+
混合查询示例：
query = "退款邮费谁出"
过滤条件：category = "售后政策" AND update_time > "2025-01-01"
向量检索：Top-20（带过滤）
重排序：Cross-Encoder 打分 → Top-5
阈值：最终分数 < 0.3 的丢弃
踩坑提醒：不要在向量检索后才做过滤（先召回再过滤），这样会浪费计算且可能召回不足。应该用支持标量过滤的向量数据库（如 Milvus、Qdrant），在检索时同时过滤。
五、踩坑清单（这 5 个坑都踩过）
- 用通用 Embedding 模型处理专业领域文本，同义句相似度只有 0.6，微调后提到 0.85
- HNSW 的 ef_search 用默认值 10，召回率只有 80%，调到 100 后召回率 98%，延迟只增加 2ms
- 向量没做归一化就用余弦相似度，计算慢且结果不稳定，归一化后用内积又快又稳
- 没加相似度阈值，Top-K 里混了很多 0.3 以下的不相关结果，用户以为搜不准
- 微调时用了随机负例，模型效果没提升，换成难负例后 Top1 准确率涨了 20%
这次知识库语义搜索是搭在乔拓云的企业官网产品上的，文档内容从官网帮助中心导入，我主要负责 Embedding 选型、HNSW 索引构建和查询优化这三块，调通后搜索 Top1 准确率从 45% 提到 82%，用户搜索满意度明显提升。
复盘要点
- Embedding 先通用后微调，用难负例训练，领域场景提升明显
- HNSW 索引 M=16/ef_construction=200/ef_search=100 是甜点配置
- 查询加阈值过滤 + 元数据过滤 + 交叉重排，准确率比纯检索高 20%+
以上是个人实践记录，各平台具体功能以官方实时信息为准。
开放问题：你们做语义搜索时，Embedding 模型和向量数据库是怎么选的？有什么调优经验？
