Embedding 与语义搜索（直觉版）

一句话理解：Embedding 把一段文字变成“语义空间里的一个坐标”，意思相近的文字坐标也相近；语义搜索就是找离问题坐标最近的那些片段。

用户问“下单以后多久能开发票”，知识库里写的是“发票开具时限：订单完成确认后 7 个工作日内”。两句话几乎没有相同的词：下单 vs 订单完成确认，开发票 vs 发票开具，多久 vs 时限。传统的关键词搜索很可能找不到，但语义搜索能找到。

这就是 Embedding 带来的能力，也是 RAG 能够成立的基础。这一课不涉及数学，只建立足以做产品判断的直觉：它为什么有效、在哪里会失灵、选型时要注意什么。

直觉：给每段文字一个坐标

想象一张巨大的地图。每一段文字都被放到地图上的某个位置，规则是：意思越接近，放得越近。

真实的 Embedding 不是二维，而是几百到几千维，每一维也不对应人能读懂的含义。但直觉是一样的：

• Embedding 模型 负责把文字转换成坐标（一串数字，称为向量）。
• 向量索引（常说的向量数据库）负责存储这些坐标，并能快速找出“离某个点最近的若干个点”。
• 相似度 通常用余弦相似度衡量，可以理解为“两个坐标方向有多一致”，越接近 1 越相似。

语义搜索的全过程就是：把知识片段提前转成坐标存好 → 用户提问时把问题也转成坐标 → 找出最近的 K 个片段。

把这个过程画出来：

擅长与失灵

它擅长什么

能力	例子
同义词与近义表达	“开发票”能找到“发票开具”
口语与书面语	“东西坏了能不能换”能找到“商品损坏换货标准”
换一种问法	“为什么钱没退回来”能找到“退款失败常见原因”
跨语言（取决于模型）	英文问题可以找到中文文档
概念层面的相关	“客户不满意”能找到“投诉处理流程”

这些正是关键词搜索的弱项。用户不会按照文档的写法提问，这是语义搜索最大的价值。

它在哪里失灵

语义相近不等于“对这个问题有用”。以下几类情况，产品经理在设计时一定要心里有数：

失灵场景	例子	原因
精确字符串	订单号 ORD-1024、错误码 E-4031、SKU 编码	这些字符串没有“语义”，相近的编号坐标也可能相近，容易张冠李戴
否定与条件	“不 适用于企业版的规定” vs “适用于企业版的规定”	两句话大部分词相同，坐标非常接近
数字与范围	“金额 500 元以上” vs “金额 500 元以下”	数字差异对坐标影响很小
企业内部黑话	“A 类单”“二次退款”“挂起”	通用模型没见过这些词在你们公司的含义
版本与时间	v2 政策与 v3 政策	内容高度相似，坐标几乎重叠，无法分辨哪个生效
问题太短或太泛	“退款”	坐标附近什么都有

这张表几乎直接决定了后续的设计：

• 精确字符串 → 需要关键词检索补位（混合检索与重排序）。
• 版本与时间 → 需要元数据过滤（切块与元数据）。
• 否定、数字、条件 → 需要重排序和生成阶段的仔细核对。
• 内部黑话 → 需要术语表、查询改写，或选择更适合领域的模型。

把失灵场景和补救手段对应起来：

还有一点常被忽视：“相似”是相对的。 语义搜索总会返回最近的 K 个结果，哪怕知识库里根本没有答案。它不会说“没找到”，只会给你一些“最不远”的片段。所以必须设置相关度门槛，或在生成阶段要求“片段中没有依据就说不知道”。

问题和文档不是一回事

用户的问题通常很短，是疑问句；知识片段通常较长，是陈述句。两者在语义空间里天然有距离。常见的应对：

• 区分查询与文档的编码方式。 一些 Embedding 服务支持指定输入是“查询”还是“文档”。例如 Claude 文档中介绍的 Voyage AI 模型，就建议在检索场景下明确设置输入类型，服务会为两者加上不同的前置提示。
• 查询改写。 在检索前让模型把“多久能开票”改写成更接近文档写法的查询，或者生成几个不同表述分别检索。
• 为片段生成“可能被问到的问题”。 索引时为 FAQ 或条款生成几个假设问题，一并建立索引。

选型与工程上需要知道的事

不需要掌握底层原理，但以下几点会直接影响产品决策：

1. Embedding 模型和生成模型是两回事。 例如 Anthropic 官方文档明确说明它不提供自己的 Embedding 模型，并以 Voyage AI 作为示例提供方。选型时两者可以独立决定。

2. 更换 Embedding 模型需要重建整个索引。 不同模型的坐标系不通用，旧向量和新向量不能混用。知识库越大，这个成本越高，选型要慎重，并预留重建方案。

3. 领域适配很重要。 通用模型对金融、法律、医疗等领域的术语理解可能不够。一些提供方有面向代码、金融、法律的专门模型。无论选哪个，都要 用自己的真实问题做评测，公开排行榜只能作参考。

4. 向量检索是“近似”的。 为了速度，向量索引通常使用近似最近邻算法，极少数情况下会漏掉真正最近的结果。这在大多数场景下可以接受，但意味着“检索不到”不一定等于“库里没有”。

5. 维度与成本。 维度越高，通常表达能力越强，但存储和计算成本也越高。部分模型支持输出较低维度的向量，或压缩向量精度来节省存储。知识库规模大时，值得和工程师讨论这个取舍。

常见误区

• “向量检索找到的就是相关的。” 它只保证“最近”，不保证“有用”。没有答案时它照样返回结果。
• “语义搜索可以替代关键词搜索。” 订单号、错误码、条款编号这类精确查找，关键词搜索更可靠。生产系统通常两者结合。
• “选排行榜第一的 Embedding 模型就行。” 排行榜的数据集不是你的业务。用你自己的 30 到 50 个真实问题测一遍再决定。

产品经理检查清单

• 用户的问题中，有多少包含订单号、错误码、编号这类精确字符串？
• 知识库里有哪些内部术语、缩写？是否有术语表可以用于查询改写？
• 是否存在大量内容相似的文档（多个版本、多个区域）？如何区分？
• 检索结果是否设置了相关度门槛？没有依据时 Agent 怎么回复？
• 选择 Embedding 模型时，是否用真实问题做过对比评测？
• 如果将来要更换模型，重建索引需要多长时间、谁来负责？

练习

不写代码也能完成的直觉练习：

1. 写 10 对句子，分成三组：意思相同但用词不同（如“开发票”与“发票开具”）、用词相同但意思相反（如“适用”与“不适用”）、只有编号不同（如 ORD-1024 与 ORD-1042）。
2. 预测每一对在语义搜索中是“很近”还是“很远”。
3. 如果你会一点代码，调用任意一个 Embedding API 计算每对句子的余弦相似度，对照你的预测；如果不会，找工程师帮你跑一下。
4. 写两三句话总结：你的业务里哪类问题最不适合只用语义搜索。

延伸阅读

• Claude 文档：Embeddings

下一步

Embedding 的效果很大程度上取决于“被转成坐标的那段文字”本身是否合适。下一课「切块与元数据」讲如何切分文档，以及如何用元数据弥补语义搜索的盲区。