文本嵌入：分层表示与量化组合的实测取舍

一句话结论

这篇论文没有提出新的嵌入模型，而是把“分层可变长表示”和“量化”这两个正交压缩手段放进同一套 MTEB 评测里拆开，回答组合后是否仍划算：int8 可近似无损，二值量化不可取，降维要按任务类别和次数谨慎用。

方法要点

论文的核心是实证基准，不是新网络结构。作者用四类基于 Transformer 的嵌入模型，覆盖分层表示与 32 位、8 位、二值量化，在 MTEB 的 38 个任务上跑每任务 168 种配置，并分别报告“每向量理论存储”和“端到端评测时间”。统计上使用 Friedman 检验与 Nemenyi 事后分析，避免只看平均值。

关键设计有三点：

1. 分层表示负责可变长度：通过从中间层采样得到不同长度的表示，压缩的是维度与计算路径。
2. 量化负责数值精度：从 32 位降到 8 位，或进一步二值化，压缩的是每个维度的存储。
3. 两者分开计量：存储按理论每向量大小算，时间按端到端评测算，不把“存储变小”直接当成“推理变快”。

伪代码如下：

for model in four_embedding_models:
    for rep in ["分层可变长表示"]:
        for quant in ["float32", "int8", "二值量化"]:
            for task in MTEB_38:
                cfg = build_config(rep, quant, dimension_halving)
                score = evaluate(cfg, task)
                storage = per_vector_storage(cfg)
                latency = end_to_end_time(cfg)

# 论文给出的选择规则（伪代码）
if task_category == "检索":
    reject("二值量化")
if dimension >= m16:
    one_halving_may_pass()
two_successive_halvings = "预期可检测退化"

论文在 arXiv 摘要 中明确说，评测时间只测了一次，因此时间结论只作指示性参考；全文可从 ar5iv 查看。

关键数字

最重要的实用结论是：int8 是低风险默认项，二值量化不是。如果你只做配对分类或重排序，int8 与 float32 在统计上拉不开差距；但整体预算要按最多 1.5 个百分点损失来算。存储收益最直观：8 倍降维加 int8 可以把每向量存储压到 32 倍，同时保留 94.4% 的基线效果。

局限与前提

第一，时间结论弱。作者自己承认端到端评测时间只测了一次，只能当指示性结果；因此“量化不加速评测”应理解为在这套测量里没有证据，而不是严格延迟基准。相反，采样中间层缩短评测时间这一点更值得关注。

第二，结论必须按任务类别看。检索退化远快于其他类别，不能把整体平均当作检索场景的保证。做 RAG 或搜索召回时，二值量化应直接排除；int8 也要在目标数据上复测。

第三，维度减半不是无限可用。原文的边界是 m=16 以上，单次减半未达统计可检测；连续两次减半总能检测到退化。换句话说，降维一次可以谈，连续降维两次不要默认安全。

第四，论文是开放获取的作者版本，信息源没有给出代码仓库或权重下载链接。它能指导配置选择，但不是“拿来即跑”的工程包。

能不能用

能用，但要按任务挑配置。做配对分类、重排序，可把 int8 当作默认压缩；做检索，不要用二值量化，且优先保维度。需要极限存储时，8 倍降维加 int8 是论文给出的组合：32 倍每向量存储压缩，效果为基线的 94.4%。如果业务不能接受接近 6% 的效果损失，就不要直接上这套组合。

本地复现需要自备四类 Transformer 嵌入模型、MTEB 的 38 个任务评测流水线，并跑每任务 168 种配置；时间部分应多次重复，不能照搬单次测量。代码与权重：信息源未提供，论文本身为 CC BY 4.0 开放获取，适合按实验设计自行复现。

参考来源

1. arXiv 摘要页：Balancing hierarchical representation and quantization
2. ar5iv 全文
3. 期刊 DOI