先对齐任务：相似≠相关
Embedding 把文本映射到向量空间，「距离近」只表示语义相似的一种近似。检索与推荐要的是相关，而不是「像」。同一词在不同业务里含义不同：「苹果」在水果店与手机店语境完全不同。你必须用业务语料定义什么叫相似。
数据清洗：比换模型更常见的问题
重复文档、噪声 HTML、OCR 错误、以及过短的片段，都会污染检索。上线前先做：去重、长度过滤、分块策略统一、以及元数据补全。很多「embedding 不行」其实是数据不行。
评测集：要包含负样本与难例
只用正例集容易高估效果。建议构造：
- 难负例：看起来相关但实际不相关。
- 边界例：需要额外过滤条件才能判断。
- 跨语言/跨领域例（若你确实需要）。
指标上除了召回率，还可以看 MRR、nDCG 等排序指标，取决于业务。
阈值与重排：向量只是第一跳
即使 embedding 很好，你也需要决定阈值与重排策略。阈值太低会引入噪声；太高会漏召回。重排模型（交叉编码器）常常能弥补 embedding 的粗糙性，但会增加延迟。
线上监控：漂移与内容更新
内容库更新后，索引与向量分布会变化。建议监控：零结果率、点击率、人工反馈、以及检索结果的重复度。对高频查询建立回归集，定期对比新旧版本。
失败案例怎么用起来
很多团队会积累“检索错了”的截图，但没有把它们转成评测资产。更有效的方法是：把每个失败案例转成标准样本，记录查询、期望结果、错误类型、修复方案。然后每次升级 embedding 模型、重排模型或分块策略时自动回归。这样你能很快看出“新版本是否真的变好”，而不是只凭主观印象判断。
评测与产品协同
Embedding 质量评估不应只由算法同学负责。产品侧要给出真实任务路径，运营侧要补充用户反馈标签，工程侧要提供日志与埋点。三方协同后，评测指标才有业务意义。否则即便离线指标很漂亮，线上用户仍可能频繁搜不到想要的信息。
小结
Embedding 是工程系统的一部分，不是魔法向量。把任务定义、数据清洗、评测集与线上监控补齐，比盲目换大模型更有效。