刚开始做 RAG 的人，十有八九会在同一个地方犯迷糊：文档说「把文本向量化」，代码里调的却是 embedding 接口，那这两个到底是不是一回事？概念一乱，后面选模型、定维度、建索引就容易跟着错。这篇不堆论文，先把边界划清楚，再给一套能照着走的流程：从想清楚要解决什么，到挑模型、定向量入库策略，最后用几条小测试确认结果能用。
刚开始做 RAG 的人，十有八九会在同一个地方犯迷糊：文档里写「把文本向量化」，代码里调的却是 embedding 接口，那这两个到底是不是一回事？概念一乱，后面选模型、定维度、建索引就容易跟着错。这篇不堆论文，先把边界划清楚，再给一套能照着走的流程：从想清楚要解决什么，到挑模型、定向量入库策略，最后用几条小测试确认结果能用。
先说结论：这两个词经常被当成同义词，其实一个是动作，一个是产物的性质。如果你只记住一点，就记这条：向量化是「把数据转成一串数」这件事本身，embedding 是「转出来的数带语义」的那一类。下面按概念、误区、选型入库、验证四块讲，每块都给能直接上手的动作。
先把两个词摆正：一个是手段，一个是结果
向量化描述的是过程：不管文本、图片还是音频，最后变成一串浮点数，这一步就算完成，跟这串数有没有语义没关系。embedding 强调的是产物的能力——语义相近的内容，算出来的距离也近，换个说法、换个语序，检索还能对上。把两个词画等号，等于把「有输出」当成「输出有用」。
| 方式 | 是否算向量化 | 是否懂语义 | 典型用途 |
|---|---|---|---|
| 哈希编码 | 是 | 否 | 去重、分桶、快速近似匹配 |
| One-Hot / TF-IDF | 是 | 基本不懂 | 传统关键词检索、文本分类基线 |
| embedding 模型 | 是 | 是 | 语义检索、RAG 召回、聚类 |
| 多模态 embedding | 是 | 是（跨模态） | 图文互搜、以图搜文 |
一句话记法：向量化回答「怎么变成数」，embedding 回答「变成的数带不带语义」。判断手上这步属于哪种，就问输出会不会拿去算相似度——会，就是 embedding 的活；只是把数据转成数值格式存起来，那只是普通向量化。
为什么这两个词老被混着用
- 云接口的函数名普遍叫 embeddings，返回的却是一个向量，动作和产物挤在一个名字里，看文档的人自然分不清
- 向量数据库的文档只讲「插入向量」，前面那一步在别处被叫「向量化」，容易让人以为跳过 embedding 也能建库
- 同一个厂商往往既有生成模型又有嵌入模型，接口参数名长得像，复制粘贴时接错是常事
- 中文语境里「向量化」被泛化成万能动词，连切块、清洗都有人这么叫，边界就更糊了
排查思路很简单：拿到一段代码或一段文档，先找那个把原始数据变成数组的调用，看它是不是模型推理。是模型推理、输出定长浮点数组，就是 embedding；是规则算法自己算出来的，就只是向量化。这一步分清楚，后面查问题时能省掉一半瞎猜。
选型和入库：按用途挑，别按榜单挑
选模型先问自己三件事：资料是什么语种、单块文本大概多长、检索延迟能忍到什么程度。榜单只能当参考，你的资料分布和榜单测试集往往不是一回事。各家模型的价格和上下文长度这类会变的数字，到 /embeddings 和 /price-watch 核对当时的数值，别拿记忆里的旧数做决策。
- 定语种和场景把资料抽样几十条出来，看中英混排比例。中英都有的，挑中英都稳的模型，只测英文样例会误判。
- 定切块和长度切块大小要迁就模型能吃多长，超长被截断会悄悄丢内容。切完抽查几条，确认语义没被切碎。
- 定部署形态走云端接口省运维，但要先量一次批量请求的延迟；本地部署可控，但要算显存和吞吐。哪种划算，到 /compute 看当时的数字再决定。
- 统一归一化入库前按模型说明做一次归一化，做不做、做哪种要统一，否则相似度排序会很怪，而且很难查。
- 小样本对比再定在 /embeddings 挑两三个候选，用自己真实资料跑几十条对照，别直接按排行榜定终身。
落地后怎么确认没搞砸
上线前准备一小批「问题—应命中文档」的对照，不用多，几十条覆盖典型问法就够。每次看正确片段是不是稳定排在前几位，排序错了先怀疑切块和清洗，再怀疑模型，最后才怀疑参数。这个对照集就是你的基线，换模型或改切块策略后必须重跑。
| 现象 | 先查什么 | 再查什么 |
|---|---|---|
| 正确文档完全不在结果里 | 切块是否丢内容、文本是否被截断 | 模型是否支持该语种 |
| 正确文档在但排很后 | 归一化是否统一、相似度算法是否选对 | |
| 相似问题结果忽好忽坏 | 索引里是否混了不同模型的向量 | 是否有人中途换了模型没重灌 |
| 响应很慢 | 批量大小与并发设置 | 云端接口延迟，到 /tools/speed-test 实测 |
什么时候可以不折腾：召回效果已经够用、资料更新也不频繁，就不必为了追新而换模型。反过来，如果业务对语义精度要求高、资料又在天天变，那就把对照集和重灌流程做成固定动作，别靠临时感觉判断。
下一步想比对候选模型的资料和当前价格，到 /embeddings 看模型库；想先摸清接口延迟和稳定性，到 /tools/speed-test 跑一轮实测，再决定用哪家。→常见问题
embedding 和向量化到底哪个是上层概念？
两个不在一个层级上。向量化是一类操作，凡是把数据转成数值向量的做法都算；embedding 是其中带语义的那一类，强调的是语义距离可比较。所以 embedding 可以看成向量化的一个子集，反过来把向量化都叫 embedding 就不对了。
不用 embedding，只做普通向量化能撑起 RAG 吗？
能跑但很勉强。关键词编码这类方式对措辞敏感，用户换个说法或同义词就召回不到，适合术语固定、查询方式单一的窄场景。资料表达多样、用户提问口语化的，还是得用带语义的嵌入模型。
换嵌入模型之后，原来的向量库还能直接用吗？
不能，必须整库重算。不同模型的向量空间不互通，混在一起算相似度结果没有意义。稳妥做法是建新索引、跑对照验证、确认效果不降再切流量，旧索引留一段时间方便回滚。
