向量与语义相似度 | 上下文与 RAG | 做产品

向量与语义相似度

整套知识库、语义搜索、推荐相关内容，底下都是同一个东西：**把文字变成坐标，然后比距离。**这一节讲清楚这个坐标是怎么回事。

你会遇到的现象

先看老办法的毛病。传统的关键词搜索是字面匹配：用户搜「退款」，系统去找含有「退款」两个字的文档。

问题是，同一个意思有太多说法。「退款」「退钱」「不想要了」「申请退回」——字面上毫无重合，意思却是一回事。关键词搜索对这些一律抓瞎。

向量解决的就是这件事。它不看字面，看意思。「我不想要了」和「怎么申请退款」在字面上没有一个字重合，但转成坐标之后，两个点靠得很近。

所以那张图右边的语义空间，可以理解成一张按意思排布的地图：讲退款的挤在一块，讲物流的挤在另一块，讲天气的在很远的地方。检索就是把用户的问题也放上这张图，然后看谁离它最近。

负责这件事的是一个专门的模型，叫向量模型（embedding model）。它和你熟悉的文本模型是两类不同的东西：文本模型文字进文字出，向量模型文字进、一串数字出。

这串数字通常有几百到几千个，也就是几百到几千维。图上画成两维只是为了看得见——但「距离近＝意思像」这个直觉是对的，几千维空间里也是同一回事。

这些坐标不是人定的，是模型从海量文本里训练出来的：经常出现在相似语境里的词句，坐标就被拉得近。所以它反映的是语料里的用法习惯，不是什么客观真理——这一点后面会成为一个坑。

算距离的方法通常叫余弦相似度，你不需要懂它的数学。只要知道：它输出一个 0 到 1 之间的数，越大越像。

好消息是这一层很便宜。向量模型是六类模型里最便宜的，通常比文本模型低一两个数量级。所以「把全部文档向量化」这件事，成本上几乎不是问题。

三件事值得知道。

**一、这是一次性的预处理。**你的文档要先切成小段、逐段算出向量、存进向量数据库。这是离线做的，用户提问时只需要给问题算一次向量，然后比距离——所以查询很快。

**二、文档更新要重新算。**改了一篇文档，对应的向量得重新生成。这件事很容易在项目里被忘掉，结果就是知识库答的还是三个月前的旧内容。更新机制必须在设计阶段就想好。

**三、换向量模型意味着全部重算。**不同向量模型产出的坐标系不通用，混着用等于在两张不同的地图上量距离，结果毫无意义。所以选型要慎重，换一次成本不小。

向量很好用，但它有几个内建的局限，提前知道能少踩不少坑。

**一、它算的是「像不像」，不是「对不对」。**这是最要紧的一条，下一节专门讲。一段和问题很像的文字，未必包含答案；一段能回答问题的文字，未必和问题字面相像。

二、它对否定不敏感。「支持退款」和「不支持退款」在向量空间里往往靠得很近——因为它们的用词几乎一样。这在合规、政策类的知识库里是个真风险。

**三、精确匹配反而是弱项。**订单号、产品型号、法条编号这类东西，向量检索经常不如老式的关键词搜索准。这也是实际系统要混合使用两种检索的原因。

**四、长文本会被稀释。**一段很长的文字压成一个坐标，等于把里面所有主题平均了一下，结果哪个主题都不突出。所以切分怎么做，直接决定检索准不准。

很好用，但有四个内建的局限，提前知道能少踩不少坑

① 算的是「像不像」，不是「对不对」一段和问题很像的文字，未必包含答案；一段能回答问题的文字，未必字面相像。这是整套 RAG 的效果天花板所在

② 对否定不敏感

支持退款 ≈

不支持退款用词几乎一样，坐标就靠得很近合规、政策类知识库里的真风险

③ 精确匹配反而是弱项订单号、产品型号、法条编号这类，向量经常不如老式关键词搜索准。所以实际系统要两种检索混着用

④ 长文本会被稀释一段长文压成一个坐标，等于把里面所有主题平均了一下，哪个都不突出。切分怎么做，直接决定检索准不准

还有两条工程上的硬约束：文档更新要重新算向量（最容易在项目里被忘掉，结果知识库答的还是三个月前的内容），以及换向量模型意味着全部重算——不同模型的坐标系不通用，混着用等于在两张地图上量距离。

相似不等于相关检索最大的误差来源，就藏在「像」和「有用」的差别里。

关键词、向量与混合检索向量不是万能的，实际系统几乎都是混着用。

RAG：知识库的三步检索出来之后，怎么接到模型的回答上。