嵌入模型选错的代价不会当场报错，而是在两周后表现为"检索就是不准"，然后有人开始怀疑分块、怀疑重排、怀疑向量库。真正该先回答的是三个问题：要几维、要不要稀疏输出、查询和文档是不是对称的。这篇按这三点把常见中文模型摆到同一张表上，再往下走查询改造与评测。

1. 选型先定四件事

先填这张表再谈模型名，顺序反了就会陷入"换模型 → 没用 → 再换"的循环。

2. 四条谱系的定位

三条经验：

1. BGE-M3 的价值在"一份权重出三种分数"，省掉单独维护 BM25 索引的对齐工作；代价是 dense 部分不一定比专用模型强。
2. M3E-base 的 768 维是显存档位优势，不是精度优势；在 GB 级索引上，768 与 1024 的存储差约 25%。
3. ERNIE-Embedding 类模型对实体名友好，但版本差异大，必须按具体版本核对维度与最大长度，别拿别人的表直接套。

3. 维度与存储账

docs = 5_000_000          # 条数
for dim in (768, 1024):
    for dtype, size in (("fp32", 4), ("fp16", 2), ("int8", 1)):
        gb = docs * dim * size / 2**30
        print(f"dim={dim:<5} {dtype:<5} {gb:7.1f} GiB")

上表只是向量本体，HNSW 图结构还要额外占（典型量级为向量的 1.2–1.5 倍，随 M 与 ef_construction 变）。所以"选个大维度更稳"这句话在小机器上往往直接触发磁盘水位告警。

3.1 维度不是越大越好，而是要和训练口径匹配

把 1024 维模型用 PCA 降到 256，检索质量通常只掉一点点；反过来，把 768 维模型"补零"到 1024，除了浪费显存没有任何收益。降维要配一次召回评测，别凭感觉。

4. 归一化与相似度口径

import numpy as np
def embed_norm(v):
    v = np.asarray(v, dtype=np.float32)
    n = np.linalg.norm(v, axis=-1, keepdims=True) + 1e-12
    return v / n

# 归一化之后，内积 == 余弦，可以直接用向量库的点积索引
sim = float(embed_norm(q) @ embed_norm(d).T)

最隐蔽的一种错配：入库时归一化、查询时忘了归一化。余弦相似度仍然算得出来，只是排序全乱，表现为"明明同义句却排不进前 10"。

5. 指令前缀与非对称检索

BGE 系列在中文检索上依赖查询前缀（如 为这个句子生成表示以用于检索相关文章：）。前缀不是玄学，它是训练时 query 侧与 passage 侧的分布差。

Q_PREFIX = "为这个句子生成表示以用于检索相关文章："

def encode_query(text, model):
    return model.encode(Q_PREFIX + text, normalize_embeddings=True)

def encode_passage(text, model):
    return model.encode(text, normalize_embeddings=True)   # 文档侧不加前缀

前缀用错的表现是"整体掉几个点到十几个点"，不会报错。验证方法很土但有效：取 20 条查询，分别带前缀和不带前缀各跑一遍，看 top-5 命中数。

6. Multi-Query 与 Self-Query：查询侧的两把改刀

Multi-Query 解决"用户措辞只覆盖了其中一种说法"，Self-Query 解决"语义之外还有结构化条件"。

# Multi-Query：让模型生成 N 个等价问法，分别检索后做 RRF 融合
def multi_query(q, llm, n=3):
    prompt = f"把下面的问题改写成 {n} 个语义等价、措辞不同的检索查询，每行一个：\n{q}"
    return [q] + [l.strip() for l in llm(prompt).splitlines() if l.strip()]

def rrf(rank_lists, k=60):
    score = {}
    for ranks in rank_lists:
        for i, doc_id in enumerate(ranks, start=1):
            score[doc_id] = score.get(doc_id, 0.0) + 1.0 / (k + i)
    return sorted(score.items(), key=lambda x: -x[1])

# Self-Query：先从自然语言里抽出过滤条件，再带过滤做向量检索
import json

def self_query(q, llm):
    raw = llm(f'抽取过滤条件，输出 JSON：{{"filter": {{}}, "query": ""}}\n问题：{q}')
    payload = json.loads(raw)
    return payload["query"], payload["filter"]      # 如 {"year": {"gte": 2024}}

Multi-Query 的 N 不是越大越好：N > 5 后新增改写大多是同义重复，融合后排序几乎不动，白付 token。

7. BM25Okapi 仍然要留一路

BM25Okapi 用的是词频饱和 + 文档长度归一，对编号、型号、人名、错误码这类字面强信号极其有效，而这恰好是 dense 检索的弱项。

from rank_bm25 import BM25Okapi
import jieba

corpus_tokens = [list(jieba.cut(d)) for d in docs]
bm25 = BM25Okapi(corpus_tokens, k1=1.5, b=0.75)
top = bm25.get_top_n(list(jieba.cut("ERR_4021 超时"), corpus_tokens, n=10)

分词器选错会静默毁掉这一路：用默认分词切"ERR_4021"，下划线会被切开，字面匹配能力直接消失。中文场景要么固定词典加自定义词，要么对编号类 token 做保留规则。

8. 召回评测的小闭环

评测集建设的顺序是：先 50 条真实查询 → 再扩到 200 条。50 条能发现方向性错误，200 条才能比较两个模型；少于这个量，跑出来的差异基本是噪声。

9. 排错：六种"检索不准"的真实原因

10. 边界：换模型解决不了的问题

11. 自测

1. 500 万条 1024 维 fp32 向量大约占多少存储？加上 HNSW 图结构后为什么不能只按向量本体算？
2. 入库归一化、查询忘了归一化，余弦相似度还能算出来吗？排序会怎样？
3. BGE 中文系列在对称任务上加查询前缀，会发生什么？
4. Multi-Query 的 N 从 3 加到 10，收益通常出现在哪里、什么时候饱和？
5. 为什么"ERR_4021"这类查询需要单独留一路 BM25Okapi？分词器在这条链路上起什么作用？
6. 评测集只有 30 条时，用它比较两个嵌入模型的结论可靠吗？为什么？