很多人做 RAG 时把「embedding」和「向量化」当同义词用，结果选型、报错排查、效果验收全拧在一起：模型效果差却去查数据库，或者以为换个向量库就能提升召回。这篇只解决概念边界这一个问题——先分清两者是谁包含谁、各自管什么环节，再给出从准备到落地的动作清单，让你知道出问题时该查哪一段。
做 RAG 的人几乎都会在两个词上翻车：embedding 和向量化。口头混着说没什么，一落到选型和排错就出问题——有人模型效果差却跑去换向量库，有人以为换个库召回就能上来，还有人把「换个更强的模型」当成万能药。这篇只解决一件事：把两者的边界和包含关系理清，再给出从准备到验收的动作顺序，让你出问题时知道该查哪一段。
先把结论摆出来：embedding 是向量化的一种实现方式，方向别搞反。剩下的内容都是围绕这句话展开的工程动作，每一步都写清「查什么、怎么验证、什么情况下不成立」。
先把两个词的关系摆正：谁包含谁
embedding 指的是「用模型把一段内容映射成稠密向量」这个动作和它的产物，强调的是模型参与计算这一层。向量化是更宽的说法，凡把文本、图片、数值转成向量表示的过程都算，embedding 是其中最常见的一条路径。所以「embedding 是向量化的一种实现方式」这个方向是对的，反过来把向量化说成 embedding 的子集，写进文档里迟早带偏排查方向。
- embedding
- 调用模型把内容算成稠密向量，语义好坏由模型决定
- 向量化
- 更宽的过程统称，包含模型路径和传统特征路径
- 向量库
- 负责存向量和算距离，不负责理解语义
落到 RAG 链路上：每一步该查哪个词
把词放回链路上，分工就清楚了。入库阶段，切片后调模型接口拿向量，再写进向量库，这是典型的 embedding 动作。查询阶段，把用户问题用同一个模型转成向量再去库里找最近邻，这一整段常被笼统叫「向量检索」，来源还是 embedding。两边用不同模型，是新手最容易踩的坑，而且报错往往很安静，只表现为召回莫名其妙地差。
建议动手前先写一张对照表，出问题时按表定位，而不是凭感觉换组件。下面这张可以直接抄成团队文档里的排查入口。
| 环节 | 用到的是哪类 | 出问题先查什么 |
|---|---|---|
| 文档切片入库 | embedding（模型算向量） | 切分粒度、截断长度、批量和并发 |
| 问题转向量 | embedding，且必须与入库同一模型 | 模型是否一致、维度是否对得上 |
| 相似度检索 | 向量库的距离计算与索引 | 距离度量设置、索引构建、入库是否完整 |
| 回答生成 | 与向量无关的生成侧 | 提示词、上下文拼装、片段条数 |
向量库之间的差异集中在索引和距离计算，跟模型好坏是两回事。要挑库，到 /stacks/vector-dbs 看向量数据库目录，按你的数据量和查询形态筛，别把选库当成提升语义理解的手段。
动手前的准备清单
- 定语言和语种：中文资料别直接用只擅长英文的模型，混语料要先小样本测召回再决定
- 定维度和截断长度：维度影响存储和计算开销，截断长度决定长文会不会被切掉尾巴，这两项在接入前写死
- 定批量和并发：先用小批量跑通再放大，避免一上来就被限流打回
- 定评估集：准备一组固定问句加人工标注的正确片段，后面换任何组件都跑同一组
模型清单不要凭记忆，到 /embeddings 核对当时的候选和规格，数字以页面实时展示为准。另外别忽略 token 计费方式对预处理策略的影响，长文切法不同，最终成本差别可能不小，具体到 /price-watch 看当时的数字。
- 小样本跑通挑几十条代表性文档，跑通切片、调模型、入库、查询全链路，确认维度对得上、能召回
- 固定评估集把上一步的问句和正确片段存成文件，之后每次换模型或换切法都跑同一份，只看正确片段能不能排进前几名
- 放大批量跑通后再提并发，盯住接口的错误率和响应时间，出现限流就先降批量而不是换模型
落地验收：怎么判断差别不是错觉
验收的核心是「同一份题，换组件重跑」。换模型、换切法、换向量库，都跑同一组固定问句加人工标注的正确片段，看正确片段能不能排进前几名。没有这份基准，任何「感觉好多了」都站不住。评测口径不熟的话，可参考 /benchmarks 的说明，先把比较方法对齐再比数值。
排查要分段。召回不准，先怀疑 embedding 模型和切分；召回准但回答差，问题在生成侧，继续折腾向量是白费功夫。这个顺序能省掉大量无效试错。
- 上线后留一条监控：同一问题的检索结果前后变化，能提前发现模型替换或数据漂移
- 换模型时保持切分和入库流程不变，一次只动一个变量，否则说不清是谁的功劳
- 基础质量校验可以到 /tools/quality-check 走一遍，先排除明显的数据和格式问题
三个常见误解，先拆掉
这三个误解在团队里流传很广，几乎每个新人都要撞一遍，提前拆掉比事后解释省事。
| 误解 | 实际情况 | 怎么纠正 |
|---|---|---|
| 向量库能提升语义理解 | 它只负责存和算距离 | 选库前先问：我要解决的是检索速度还是语义质量 |
| 换更强的模型一定涨召回 | 切分太碎或太粗时，收益会被切分问题吃掉 | 先调切分再换模型，一次只动一个变量 |
| 两个词可以随便互换描述 | 混用会把排查方向带偏 | 写文档和评审时统一口径，embedding 指模型那一步 |
尤其第三条，看着像文字工作，实际影响很大。技术评审里写「向量化效果不好」，对面可能去查库配置；写「embedding 召回不准」，大家就直奔模型和切分去了。
分清 embedding 是模型那一步、向量化是整个过程，排错时就不会在错误的组件上浪费时间。下一步把候选模型的规格、计费方式和中转站可用性对照着看一遍，再决定用哪个，比凭感觉换模型靠谱得多。→
常见问题
embedding 和向量化是不是一回事？
不完全是。向量化是统称，指把内容转成向量；embedding 是其中靠模型学出来的一种具体做法。日常口语混用没大问题，但排查效果问题时必须分开说，否则会去错地方找原因。
只用向量化不做 embedding 能做 RAG 吗？
能，但效果通常有限。传统词频类向量在关键词精确匹配上还行，遇到同义换述就吃力。资料里有大量口语化表达时，还是建议上 embedding 模型；如果只是内部短文档精确查，简单方案也够用。
换 embedding 模型后旧库要重做吗？
基本要重做。不同模型的向量空间不通用，用新模型查旧库会把错的东西排前面。稳妥做法是双写一段时间，用同一组问句对比召回，确认后再切流量、清旧数据。
