embedding和向量化的区别，从准备到落地的做法

刚接触 RAG 的人常把「embedding」和「向量化」当同义词用，结果在选模型、切块、入库、检索对不上号时不知道该改哪一环。这篇先把两个词的边界摆清楚：一个是产出向量的模型能力，一个是把文本变成可比较数字串的工序，再顺着准备、实现、验证三段给出可执行清单，并说明什么情况下这套做法不适用。

刚接触 RAG 的人常把「embedding」和「向量化」当同义词换着用。真到选模型、切块、入库、检索对不上号的时候，问题就来了：不知道该改哪一环。这篇不讲大概念，先把两个词的边界摆清楚，再顺着准备、实现、验证三段给出可执行清单，最后说明什么情况下这套做法不适用。

一句话记住定位：一个说的是能力，一个说的是工序。分清之后，出错时你能快速判断是「模型选得不对」还是「流程哪一步没走完」，排查范围立刻小一半。

先把两个词分开：一个是能力，一个是工序

embedding 一般指向模型能力：把一段文本压成定长向量，语义相近的向量距离也近。向量化指的是把语料批量喂进这个模型、拿到向量并落库的整个过程。换种说法：embedding 回答「用什么把文本变成向量」，向量化回答「怎么把整份资料走完这条路」。两者不是并列概念，是工具与流程的关系。

容易混的还有「词向量」这类更早的做法，它只表示词级表示，和现在按段落的语义向量不是一回事。翻到旧资料时先看年代，别把词级表示的经验直接套到段落向量上。

动手前的准备清单

准备阶段的目标是把不确定项挪到前面，而不是急着写调模型的代码。下面四件事先定下来，后面实现和排查才有参照。

• 定切块策略：先按文档结构切，再设长度上限与重叠量；切块单位必须和检索时的使用单位一致，否则向量再准也凑不出完整上下文
• 定模型与维度：只看三件事——中文表现、支持的最大输入长度、维度与批量上限；具体哪家哪个版本别放死，到 /embeddings 看当时的可用清单
• 定存储：向量库负责近邻检索，原文和元数据可以放普通数据库，两边靠一个稳定的块 ID 关联，别只存向量不存原文
• 定批量与限速：按接口给的批量上限切批次，留出失败重试和断点续跑的余量，长文档一次跑完很容易中途断

落地三步：跑通、对上、量出来

实现阶段别一上来就全量跑。先用小样本把链路打通，再检查语义是否对得上，最后才用数据判断好坏。顺序反了，出了问题分不清是流程错还是模型差。

1. 跑通拿十几条已知相关的问答对做冒烟测试，确认向量能写入、能按 ID 取回、检索返回的是相关块而不是随机块
2. 对上抽查同义改写的两句话，看余弦相似度是否明显高于不相关句子；不达标先查切块，再查模型是否支持该语种，最后才怀疑维度设置
3. 量出来记录每次检索的召回情况与延迟基线，换模型或改切块后重跑同一批问题做对照，别凭感觉判断变好没有

查问题的顺序比结论更重要：检索不准时，先看切块是否把语义切断了，再看是否该用混合检索补关键词命中，最后才考虑换向量模型。把最后一步提前，等于每次都在推倒重来。具体到各家模型的可用状态和接口说明，到 /embeddings 核对；想先估一下不同方案的调用开销，去 /price-watch 看当时的数字，别拿旧印象拍板。

什么情况下这套做法不适用

先说清楚适用范围，比强推方案更有用。下面几种情况，纯靠 embedding 加向量化不一定合适，硬上往往维护成本比收益高。

• 资料以精确编号、代码符号、专有名词为主时，纯向量检索容易漏，应该配关键词检索做混合，别指望相似度解决字符串精确匹配
• 语料总量很小（几十条以内）时，直接把全文塞进上下文可能比建向量库更省事，建库反而多一层维护成本
• 需要频繁整体改写、且回答要严格按原文措辞时，检索增强未必是首选，要评估规则匹配或结构化查询是否更稳
• 多模态文档（扫描件、图表为主）先解决版面解析，向量化只是后半段，解析没做好时换模型收益很小

embedding 是你手里的工具，向量化是你要负责的整条流水线；工具能换，流水线得自己盯。