LLM Wiki / RAG
Embedding 模型评估：不要只看排行榜
从领域语言、检索指标、延迟成本、多语言、维度和迁移风险评估 Embedding 模型，避免盲目替换导致 RAG 退化。
Embedding 模型决定了向量召回的语义空间。换模型看起来只是替换一个 API，实际上会改变所有向量、距离分布、阈值、召回结果和成本结构。
核心判断
Embedding 模型不能只看通用 benchmark。真正要看的是你的文档、你的查询、你的语言、你的权限过滤和你的延迟预算。
评估维度
| 维度 | 问题 |
|---|---|
| 领域匹配 | 业务术语、缩写、代码、表格字段是否能对齐。 |
| 多语言 | 中文、英文、中英混问、专有名词是否稳定。 |
| 长文本 | chunk 较长时语义是否稀释。 |
| 维度 | 向量维度影响存储、内存和检索速度。 |
| 成本 | embedding 单价、批量吞吐、重建索引成本。 |
| 稳定性 | 模型版本是否可固定，输出是否可复现。 |
离线评测
最小评测集应该包含 query 和 expected evidence。
{
"query": "远程员工 PTO 政策怎么计算？",
"expected_chunks": ["hr_policy_remote_pto_2026"],
"language": "zh-CN",
"category": "policy"
}用同一套 chunk，对不同 embedding 模型生成索引，然后比较 Recall@K、MRR、NDCG 和 P95。
迁移风险
Embedding 迁移通常需要双索引。
不要在旧索引里混入新模型向量。不同模型的向量空间不可直接比较。
结论
Embedding 评估不是“哪个模型更强”，而是“哪个模型在你的数据和预算里让正确证据更稳定地进上下文”。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。