完整题目
请描述常用的文本嵌入（Embedding）模型架构，如BERT、Sentence-BERT等，并解释不同输出向量维度对下游任务的影响。
本文目录
答案要点
- 区分BERT骨干、Cross-Encoder配对打分与SBERT独立句向量训练；“双塔”描述编码方式，不必是两套独立权重
- 解释CLS token与Mean Pooling的优劣
- 说明向量维度的影响（表达能力vs计算效率、存储成本）
- 提及实际选型考量（MTEB榜单、领域适配）
主流Embedding架构对比
| 模型 | 核心架构 | 关键改进 |
|---|---|---|
| BERT | Transformer Encoder | 预训练MLM+NSP，输出token级表示 |
| Sentence-BERT | 共享骨干的Siamese/Triplet编码方式 | 通过句对分类、回归或triplet等目标学习可比较的句向量，具体损失依训练方案 |
BERT为何不适合直接做语义检索
- BERT的[CLS]向量未经显式句子相似度训练，语义区分度弱
- BERT也能独立编码并pool成向量，但未针对句向量训练的质量未必好。Cross-Encoder才需逐(query,doc)配对前向；一条query对N文档为N次配对，N句全两两比较才是约O(N²)对。SBERT可预计算文档表示，但ANN检索成本另计。
Sentence-BERT的双塔设计
Tower A (Query) ──→ 固定编码器 ──→ 向量v₁ ──┐
├──→ 余弦相似度计算
Tower B (Doc) ──→ 共享权重编码器 ──→ 向量v₂ ──┘- 离线编码文档：文档向量预计算存入向量库
- 在线编码查询：仅编码query，实时检索Top-K
向量维度的影响
| 维度 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 高维（1024+） | 语义表达丰富，区分度高 | 存储大、检索慢、内存压力大 | 高精度要求、数据量可控 |
| 低维（256-384） | 检索快、省存储、易部署 | 信息压缩可能损失细粒度语义 | 海量数据、实时性要求高 |
工程权衡：相同dtype的裸向量768→384存储减半，但质量变化没有通用<2%保证；普通截断、PCA/学习投影、蒸馏与经过训练的Matryoshka前缀截断应分开评测。PQ压缩编码存储，不等于降维。
实际选型建议
- 看榜单：MTEB Leaderboard选Top3开源模型（如BGE、E5、GTE系列）
- 看领域：通用场景用E5，中文用BGE，代码用CodeBERT
- 看规模：亿级文档优先考虑384维+量化（FP16/INT8）
参考资料
换一种问法，检查是否真正理解
场景切入
假设你要给电商平台做商品检索，用户搜‘红色连衣裙’，你打算怎么把商品描述和用户查询变成向量来算相似度？你用的是单塔模型还是双塔？
层层追问
文本嵌入模型你平时怎么选的？……BERT 直接拿 [CLS] 向量做检索效果好吗？……那 Sentence-BERT 有什么改进？……向量维度比如 768 和 384，实际部署时你怎么权衡？
直球架构
对比一下 BERT 和 Sentence-BERT 的架构差异，重点说输出向量维度对检索精度、存储和速度的影响，以及你实际选型时会参考哪些指标？
练习口述回答 · 约4分钟
- 这道题本质在问怎么选架构和维度
- 区分BERT骨干、Cross-Encoder配对打分与SBERT独立句向量
- 输出维度是精度和效率的权衡
- 落地要结合场景和榜单，注意维度降维的坑
- 可延伸点：追问维度压缩方法
好，这道题我觉得核心不是在背BERT和Sentence-BERT的架构差异，而是问你在实际做文本[[嵌入]]的时候，怎么根据业务场景选模型和输出维度。说白了，就是怎么在表达能力和工程效率之间做取舍。
先说架构。BERT是预训练Transformer骨干，可输出token表示；直接使用CLS或pooling句向量的质量取决于训练与任务，不能把未经句向量训练的结果当检索质量保证。更关键的是，要区分用法：BERT可独立编码并pool成向量，但未经句向量训练时相似度质量可能较弱；Cross-Encoder配对打分才需逐对前向。单query对N文档是N次配对，N句全两两比较才约N平方对，不能说BERT骨干本身无法离线建索引。
Sentence-BERT是独立句向量检索的一类常见方案。它用两个共享权重的编码器分别编码query和doc，训练目标可采用句对分类、回归、triplet或后续对比学习方案，不能把全部SBERT训练等同一种Contrastive Loss。这样doc可以提前离线编码存到[[Vector Database]]里，线上只编码query，然后做[[ANN]]检索。文档编码可以预计算复用，查询只需独立编码再搜索；具体ANN搜索、向量维度与候选交互成本还需单独分析。
输出向量维度这块，我一般会先看业务对精度的要求。高维比如768或1024，语义表达更丰富，区分度更高，但存储和检索开销也大。低维比如256或384，检索快、省内存，但可能会损失一些细粒度语义。实际落地中，我通常会优先考虑384维，同dtype下裸向量存储可减半，但质量和速度变化要在具体模型、降维方法、题集与索引上测，不能套用统一MTEB<2%结论。
举个例子，假设我们要做电商客服的退款政策检索。文档量大概几百万篇，线上要求毫秒级响应。如果直接用768维，向量库可能要几十GB，检索延迟也高。我会先用384维的E5模型，可比较FP16/INT8的每坐标存储从4字节到2/1字节，或PQ子向量编码；这不是每个完整向量只有1–2字节。总索引、码本与运行时缓冲另计，延迟是否满足需要实测。当然，前提是业务对精度没那么敏感，召回率差一两个点能接受。如果场景是金融风控合同比对，一点语义差别都不能丢，那我会保留高维，配合[[HNSW]]索引和GPU加速来扛性能。
这里有个坑：很多人觉得维度越低越好，直接降到128甚至64，结果召回崩了。所以我会先拿一小批业务数据做A/B测试，对比不同维度下的Recall@K和延迟，找到那个拐点。另外，普通模型不能预设随意截断有效；可比较学习投影、PCA或蒸馏。经Matryoshka训练的模型专门支持不同前缀维度，也要按对应模型说明与目标题集验证。
说到降维，其实除了直接选低维模型，还可以用蒸馏降低输出维度，或用Product Quantization压缩编码存储，两者不能混称降维，但不同压缩方式对精度和速度的影响不太一样。
所以整体上，我会把文本嵌入看成一块拼图：架构选双塔，维度根据精度和效率的trade-off来定，再配合索引和量化，才能做出一个真正可用的检索系统。