很多 RAG 项目介绍会说“把文档向量化后放进向量数据库”。这句话太容易让人误会，好像 embedding 只是一个按钮。实际检索质量从表示空间就开始决定：模型如何理解文本，问题和文档是否在同一个语义空间，领域词是否能被正确表示。
面试官如果追问 embedding，不一定期待你推导模型结构，但会看你是否知道向量检索为什么会召回错、为什么换模型会影响结果、为什么切分策略会改变相似度。
向量相似不是答案正确
向量检索找的是语义相近片段，不是直接找正确答案。用户问“退款多久到账”，系统可能召回“退款规则说明”，也可能召回“到账通知模板”。两者语义都接近，但只有前者真正可答。
因此 embedding 只是第一步。后面还需要关键词补充、重排、证据过滤和生成约束。把向量相似度当成答案可信度，是很多 RAG 项目早期的坑。
模型要适配领域语言
通用 embedding 模型在很多场景可用，但遇到专业缩写、公司内部名词、代码符号、金融产品、运维术语时，可能表现不稳定。比如同一个词在不同业务里含义不同，模型如果没有见过类似语料，就可能把不相关文档拉近。
解决方式不一定是立刻训练模型。可以先优化文档标题、补充同义词、做查询改写、混合关键词召回，再评估是否需要领域 embedding。面试里能把这些选择讲出来，比一句“换更好的模型”更靠谱。
切分会改变表示
一段文本被切成多大，会直接影响向量表达。切得太小，片段缺少上下文，模型不知道这个句子属于哪个主题；切得太大，片段里混入太多信息，相似度可能被无关内容稀释。
好的切分要尽量保持语义完整。技术文档可以按标题层级和段落切，FAQ 可以按问答对切，代码文档要保留函数名和上下文。切分不是预处理细节，而是检索质量的一部分。
评估要从问题集开始
判断 embedding 好不好，不能只看几个样例。要准备一批真实问题，标注应该召回哪些资料，观察正确资料是否进入候选、排在第几位、是否被重排保留。没有评估集，换模型、改切分、调 topK 都只能凭感觉。
一个成熟回答可以是：我会把 embedding 看作检索系统的一层，而不是独立组件。先用真实问题评估召回，再分析是模型表示、切分、领域词还是排序出了问题。这样 RAG 项目才有持续优化的方向。
还要注意 embedding 的更新成本。换一个 embedding 模型，不只是改一行配置，历史文档向量通常需要重建。重建期间新旧向量混用，检索结果可能不稳定。因此模型切换最好有版本字段、离线重建、灰度评估和回滚方案。
面试里提到版本，会显得更接近真实项目。向量数据库里存的不只是向量，还应该有文档版本、切分版本、embedding 模型版本和权限元数据。否则出了问题，很难知道是哪一次变更影响了召回。