你大概遇到过这种场景：想给一堆文档做个搜索，用关键词匹配老是搜不准，别人告诉你「上向量检索吧」，然后丢来一个叫 embedding 的词。这篇文章不推公式，先把它比喻成人话，再讲它在检索流程里扮演哪个角色、哪些环节最容易踩坑，以及什么时候你其实不需要它。
你大概遇到过这种场景：手上有一堆文档想做个搜索，用关键词匹配老搜不准，别人丢来一句「上向量检索吧」，顺带蹦出一个叫 embedding 的词。这篇文章不推公式，先把它比喻成人话，再讲它在检索流程里具体负责哪一段、哪些环节最容易翻车，以及什么情况下你其实压根不需要它。
先给一个整体位置感：embedding（向量嵌入）不是模型，也不是数据库，它只是把内容转成一串数字的一个动作。真正做事的是「算这串数字的模型」加「存这串数字的库」加「拿它比远近的检索逻辑」。搞清这个分工，后面选型时就不容易被各种名词绕进去。
一句话：它给每段内容发一个「坐标」
把 embedding 想成地图坐标就通了。地图用经纬度两个数定位一个点，embedding 用几百到几千个数定位一段内容。语义上越接近的内容，在这套坐标里挨得越近；意思差得远的，坐标就拉得开。所以判断两段话像不像，不用理解文字，比坐标远近就行。
- 输出的是一串固定长度的数字，长度由模型决定，这串数本身没有任何可读含义，只有相对位置有意义
- 它是有损的、为「比较」服务的，不保证能还原原文，这点和加密压缩完全不是一回事
- 同一段话每次算出来的向量应该稳定一致，如果同一个模型对同一输入结果老在变，先怀疑调用方式而不是模型
- 别把 embedding 和嵌入模型混为一谈：前者是结果，后者是生产这个结果的工具，概念边界可以去 /ai-dict/category/basics 对照条目
- 向量维度
- 这串数字的长度，由模型固定，换模型通常就变了
- 距离度量
- 比较两个坐标远近的算法，常见有余弦相似度和欧氏距离，用哪个要跟库的默认值对齐
- 归一化
- 把向量长度统一，某些度量下必须做，不做结果会偏
它凭什么知道「猫」和「喵」是一回事
核心机制说起来很朴素：训练时让经常一起出现的表达彼此靠拢，让明显不相关的表达被推开。至于用哪套训练目标、什么网络结构，那是模型作者的事，你用的时候不用关心。你要关心的是它因此擅长什么、不擅长什么。
它擅长的是「意思相近」，不擅长「字面一致」。订单号、错误码、人名、函数名、法条编号这类要求一字不差的串，关键词匹配反而更稳。这不是 embedding 的缺陷，是它的定位决定的——它本来就不是为精确匹配设计的。
- 换模型基本就要把所有内容重算一遍，同一个模型的不同版本产出的向量通常不能混着用，这是最常见的翻车点
- 模型选型别只看宣传语，拿你自己的几十条真实问题跑一遍召回，比任何榜单都实在
- 想横向看有哪些嵌入模型可选、各自定位，翻 /embeddings 的条目对着看
- 中文场景要确认模型对中文的实际表现，别默认英文强就等于中文强
| 你的需求 | 优先考虑 | 原因 |
|---|---|---|
| 问「有没有讲退款政策的段落」 | embedding 检索 | 语义匹配，措辞不同也能命中 |
| 查订单号 O12345 | 关键词精确匹配 | 字符级一致，向量反而容易召偏 |
| 既问语义又查编号 | 混合检索 | 两路各取所长，再合并排序 |
| 几十条固定问答 | 规则或关键词 | 量小、可控、省一层复杂度 |
放到检索里：它是「先找候选」那一步
在一条完整的问答链路里，embedding 只负责「召回」，也就是把可能相关的几段原文先捞出来，后面交给大模型组织答案。它不负责答案对不对。召回错了，后面提示词写得再花也救不回来——这是新手最容易忽略的因果顺序。
- 切块把长文档切成一段段小块，块太大信息杂，块太小语义断，从按段落切、带一点重叠开始
- 算向量并入库每块算一次 embedding 存进向量库，同时保留原文和出处，方便后面核对命中是否真的对
- 问题也算一次用户提问用同一个模型算向量，模型必须和入库时完全一致，否则比出来全是噪声
- 比距离取最近几块取最近的若干块作为候选，数量别设太大，否则噪声会淹没正确答案
这里有个反直觉的点：切块策略、是否保留标题、是否加一点上下文，对最终效果的影响常常比换一个更强的嵌入模型还大。很多人一上来就折腾模型，其实该先调的是切块。向量库怎么选可以看 /stacks/vector-dbs，检索这条链路的整体定位见 /guides/rag-one-sentence-guide。
什么情况下别急着上它
不是所有搜索都值得上向量。数据量很小、答案又固定的时候，关键词或规则匹配更快也更可控，硬加一层向量只会让你多维护一套东西，还多一个出错的环节。
- 数据量小、问题模式固定，比如几十条内部 FAQ，关键词配规则就够，别为了新概念增加复杂度
- 要求一字不差的场景，如订单号、代码符号、法条原文，必须保留关键词通道，做成混合检索而不是全换成向量
- 没有评估手段时不要盲调参数：先准备一小批「问题—正确出处」的对照样本，改一次测一次，否则全凭感觉
- 还要确认数据能不能出域、是否需要本地部署，这块判断口径参考 /safety 的说明
第一次动手，按这个顺序来
第一次上手，最怕的是一边换模型一边改切块一边调参数，最后不知道是哪一步起了作用。按下面这个顺序来，一次只动一个变量，出了问题也定位得到。
- 先定评估集准备二十条左右真实问题加各自期望命中的原文，这是你后面判断好坏的唯一尺子
- 再定切块策略从按段落切、给一点重叠开始，别一上来就上复杂分块逻辑
- 然后选模型与库先拿小样本跑通，重点确认维度、距离度量、要不要归一化这三项是否对齐
- 最后再谈优化加不加关键词混合、上不上重排，都放到基础链路跑通之后再考虑
跑通之后想横向比一比不同嵌入模型和向量库的实际表现，别只看宣传，拿你自己评估集的结果说话。价格和可用规格这类会变动的数字，记得去站内对应页面核对当时的数值，别照着过时的印象选型。
下一步先把嵌入模型和向量库的当前选项过一遍，再决定要不要动手。→常见问题
embedding 和向量数据库是一回事吗？
不是。embedding 是「把内容转成数字坐标」这个动作和它的产物，向量数据库是「存这些坐标并快速找出最近的几个」的工具。你可以只用 embedding 不做库（比如几百条数据直接在内存里算），也可以有库但用得很糟。
它和「向量模型」「嵌入模型」有什么区别？
日常说话基本同义，都指把内容转成向量的那类模型。硬要分，嵌入模型偏指模型本身，向量模型有时也用来指代整个向量检索方案。想理清这层关系，可以对照 embedding-vs-vector-model-basics 那篇。
中文内容用它效果会不会差？
多数主流模型对中文够用，真正的差距往往出现在专有名词、行业缩写和长文本上。判断方法很土但有效：拿你自己的 20 条真实问题跑一遍，看到第几名命中，别只看官方演示。
