高频面试题

Embedding

Embedding 是前端转 AI 应用开发最值得掌握的 LLM 基础之一，因为知识库问答、语义搜索、相似问、反馈聚类和 RAG 召回都离不开它。

适合阶段：AI 应用开发 / RAG 项目面核心能力：Semantic Search · Recall@K · Hybrid Search · Rerank

面试官角度分析，想考什么

• Embedding 是什么？和 Chat 模型有什么区别？
  考你能否把它说成语义表示模型，而不是把 Embedding 和 Chat 生成混在一起。

• RAG 为什么需要 Embedding，它怎么完成语义召回？
  考机制链路：文档切分、向量化、入库、query 向量化、TopK 召回、rerank 和生成。

• Embedding 检索失败时怎么排查和优化？
  考工程边界：相似度不等于业务相关，召回问题要从 chunk、query、模型、索引、过滤、混合检索和评估指标定位。

可直接抄走的 30 秒参考答案

Embedding 是把文本变成向量，语义相近的文本在向量空间里距离更近。它和 Chat 模型不同：Embedding 负责表示和召回，Chat 模型负责生成和解释。RAG 里通常先把文档 chunk 向量化入库，再把用户 query 向量化，按相似度召回候选，必要时再做 BM25 混合检索和 rerank。生产中不能只看 topK 分数，要用 Recall@K、MRR、引用忠实性和业务 badcase 评估整个检索链路。

面试回答详解，知其所以然

这道题的核心不是“向量相似度怎么算”，而是理解 Embedding 在 AI 应用里负责召回证据。它不生成答案，但它决定生成模型能不能看到对的资料。

1. Embedding 是语义表示，不是文本生成

文本 -> embedding 模型 -> 向量 -> 向量库 -> 相似度检索

• Embedding 模型：输出向量，适合检索、聚类、去重、分类特征。
• Chat 模型：输出文本，适合回答、解释、生成、推理。

Embedding 把“语义接近”变成可以计算的距离。比如“怎么重置密码”和“忘记密码怎么办”字面不同，但向量可能接近；而“订单号 AB123”这种精确编号，向量不一定比关键词搜索可靠。

2. RAG 里的 Embedding 是召回链路的一环

典型链路是：

文档解析 -> chunking -> embedding -> 向量库
用户问题 -> query embedding -> TopK 召回 -> rerank -> 拼入 prompt -> Chat 模型回答

Embedding 主要影响召回：正确资料能不能进入候选集。后面的 rerank、prompt 和生成模型再决定排序、引用和回答质量。

余弦相似度衡量向量方向接近程度，但它不一定等于业务相关。

• 用户 query 太短，语义信息不足。
• chunk 缺少标题和上下文。
• 专有名词、编号、代码 API 更适合 BM25。
• 复杂问题可能需要多跳检索。
• 权限、时间、状态这类结构化条件不能只靠向量相似度。

所以生产 RAG 常用混合检索和 reranker，而不是只靠向量 topK。向量召回解决“语义相似”，BM25 解决“字面匹配”，元数据过滤解决“范围和权限”，rerank 解决“候选排序”。

3. 检索失败要按链路排查，而不是只换模型

Embedding 检索答错，可能不是模型本身差。排查顺序可以是：

• 数据解析：PDF、表格、代码块、标题层级是否丢失。
• chunking：chunk 是否太碎、太长、缺标题、跨段断裂。
• query 处理：用户问题是否太短、是否需要 query rewrite 或扩展。
• embedding 模型：是否适合中文、多语言、代码、领域术语。
• 索引和过滤：向量库参数、元数据过滤、权限过滤是否误杀。
• 召回和排序：是否需要 BM25、hybrid search、reranker 或多路召回。
• 评估指标：用 Recall@K、MRR、NDCG 和 badcase 标注定位问题。

模型选型也要看这些指标：目标语言、文档类型、向量维度、存储成本、查询延迟、吞吐、是否支持私有化部署，以及在业务评估集上的召回表现。

前端相关场景里，Embedding 常出现在语义联想、文档问答、相似问题推荐、用户反馈聚类、历史对话检索和上传文档后的索引状态展示。前端不用实现向量算法，但要理解“索引中、召回失败、无相关资料、引用不足”这些状态怎么表达给用户。

面试官追问3个问题

追问一：Embedding 模型能替代数据库搜索吗？

• 考察点：语义检索边界。
• 回答方向：不能完全替代。Embedding 适合语义召回，但精确过滤、权限、租户、时间范围、状态字段、排序规则仍要靠结构化数据库或搜索引擎。生产系统经常是向量检索、关键词检索和结构化过滤一起用。

追问二：为什么要混合检索？

• 考察点：生产经验。
• 回答方向：向量擅长语义相似，BM25 擅长关键词、编号、专有名词和代码符号。混合检索可以减少单一路径漏召回，再用 reranker 统一排序。特别是企业知识库里，产品名、接口名、合同编号和缩写很多，只靠向量容易不稳。

追问三：Embedding 模型换了要重建索引吗？

• 考察点：工程成本。
• 回答方向：通常要。不同 embedding 模型的向量空间、维度和距离分布不兼容，新模型生成的 query 向量不应该直接查旧模型建的索引。切换前要离线评估，规划重嵌入、双写索引、灰度查询和回滚方案。

扩展知识

常见指标

Recall@K：正确资料是否出现在前 K 个结果里
MRR：正确结果越靠前分越高
NDCG：考虑多个相关结果的排序质量

相关章节和资料

更完整的 RAG 链路可以看本站 RAG 章节；模型选型可接 嵌入模型选型。外部资料里，OpenAI Embeddings 适合了解通用 embedding API，Sentence Transformers Retrieve & Re-Rank 对两阶段召回和重排序解释得很清楚。