在 AI 的语义检索场景里，给一段文字做向量化，先要把它交给嵌入模型，换回一串固定长度的数字——这串数字有多少位，就是嵌入维度。768、1024、1536、4096 都常见。进来的是一段文本，出去的是一个 1024 维的向量，中间发生的事是模型把语义压缩进这串数字，让意思相近的文本拿到位置相近的向量。维度数字本身没有好坏，关键看它装不装得下你要检索的那些语义差别。
维度里装的是什么
可以把一个维度想成一项打分指标：用身高和体重两项描述一个人很粗糙，用二十项就细得多。类比到此为止，回到机制上，嵌入的每一维并不是人类可读的指标——没有哪一维专门表示金额或日期，维度的含义是模型训练时自己长出来的，同一句话在不同模型里的向量完全不同。1024 维的意义在于提供 1024 个可自由取值的坐标，语义相近的文本在这些坐标上整体位置接近："退款"和"退货"挨得近，"退款"和"发货进度"离得远。
为什么常见的是 768、1024、1536
没有理论推导出某个维度最优，这些都是工程上试出来的经验值，通常取 2 的整数次幂或其倍数，因为内存对齐和矩阵运算对这类长度更友好。常见组合大致是：BERT 一代的编码模型多用 768，通用语义检索模型常用 1024，部分云端嵌入服务常见 1536 或 3072，一些多模态模型到 4096，具体以官方文档为准。维度翻倍，向量存储和相似度计算的成本大致跟着翻倍——百万级向量库里，这直接决定服务器开销和检索延迟。顺带一提，嵌入模型通常只有几亿参数，和动辄 7B、70B 的生成式大模型相比体量小得多，成本大头在向量数量，而非单条向量的长度。
维度高低各有一端的问题。太低，语义差异装不下，"退款"和"退货"可能被压成同一个点，检索时分不开；太高，表达够了，存储和计算成本上升，而且模型能力不足时，多出来的维度塞的是噪声。判断标准始终是嵌入模型的质量加数据切分方式，维度只是容器大小。选型还牵涉部署方式：选开源权重模型自己跑，数据不出本地；调云端服务则省运维，按数据敏感度定。
换模型为什么必须重建索引
这是实际工程里最容易踩的坑。向量数据库里存的向量，是用某个嵌入模型生成的；换一个嵌入模型，所有向量都要重新生成一遍。原因在于每个模型对"哪个维度代表什么"的定义完全不同，两套坐标系的刻度含义不一样，维度相同也不能直接比较。新旧向量混在一个库里，检索结果会完全乱掉——同样的查询词，一半结果来自旧坐标系，一半来自新坐标系，相似度分数没有可比性。所以嵌入模型要在建库前定下来，中途换模型的成本约等于整库重算一遍。
选型与排查对照
| 场景 | 做法 | 判断标准 |
|---|---|---|
| 新建检索库 | 先定嵌入模型再入库，用业务真实查询词做小样本测试，对比不同维度模型的召回表现 | 抽几十条真实查询看命中结果，人工判断可用的比例明显高才算过 |
| 存储成本吃紧 | 换质量达标的低维模型，或用支持降维的服务，再评估是否叠加模型量化降低开销 | 同一批测试问题的召回率下降在可接受范围，且单条向量占用明显变小 |
| 要换嵌入模型 | 全库向量重新生成并重建索引，新旧库并行跑一段时间再切换 | 新库检索结果抽检不差于旧库，新旧分数分开存放、永不混用 |
| 近义词检索分不开 | 先调数据切分粒度，再试更高维或更强的模型 | 切分调整后仍无改善，才考虑动模型 |
三个信号判断当前维度够不够用：一是细粒度查询分不开，检索"退货政策"总混进"退款政策"，说明维度或模型区分力不足；二是换更高维模型后命中率没有提升，说明瓶颈在数据切分，加大维度没用；三是向量文件大到拖慢检索，这时该降维或压缩，而不是继续加维度。
嵌入维度速查
- 维度是向量长度，常见 768、1024、1536、4096，多为 2 的幂
- 没有最优维度，够用就好，瓶颈通常在模型质量和切分方式
- 维度翻倍，存储和计算成本大致翻倍
- 不同模型的向量不可比较，换模型必须整库重建
