UltraBERT 将 32K Token 塞进单个向量，分块可以安息了？
内容提要
UltraBERT-Embed-150M支持32K token输入，可将整篇文档压缩为单个768维向量。在LongEmbed和MLDR测试中，整文档向量在Passkey任务上召回率达99%，但在细节检索任务上普遍不如512 token分块，长文档细节易丢失。分块向量经1-bit TurboQuant压缩后体积缩小30倍，20万篇文章约140MB，保留约95%质量，重打分后达98%。结论：分块尚未过时，细节检索仍建议以512 token分块为起点。
延伸解读
整文档向量的优势与局限
UltraBERT-Embed-150M 能将 32K token 的整篇文档压缩为单个 768 维向量，在 Passkey 任务上召回率达 99%，说明它确实能读取长上下文。但在细节检索任务（如 2WikiMultihopQA、QMSum、MLDR）上，整文档向量普遍不如 512 token 分块。例如 Needle 任务中，文档长度 32K 时整文档向量召回率仅 30%，而分块为 56%。这表明单个向量难以保留长文档中的所有细节，整文档向量更适合主题级匹配，而非精确细节查找。
分块向量压缩后成本大幅降低
分块方案的主要缺点是向量数量多、存储成本高。MLDR 的 20 万篇文章平均分成 7 块，共 143 万个向量，float32 下约 4 GB。但使用 1-bit TurboQuant 压缩后，每个向量从 3072 字节降至 104 字节，总体积约 140 MB，缩小 30 倍。压缩后保留约 95% 的检索质量，重打分后可达 98%。这意味着分块方案在存储和内存上的负担已显著减轻，使其在大规模场景下更具可行性。
混合检索并非总是更优
文章尝试将整文档向量与分块向量结合进行混合检索，在 Qdrant 中同时搜索并融合结果。在 SummScreenFD 和 Needle 任务上，混合检索比单独使用分块略有提升（最高 0.02 和 0.03），但在 2WikiMultihopQA、QMSum 和 MLDR 上反而比单独分块更差，MLDR 上差距最大。因此，简单叠加两种表示并不保证效果提升，实际应用中需根据任务类型谨慎选择，或进一步调优融合权重。
实践建议：分块仍是细节检索的起点
基于测试结果，文章建议细节检索仍以 512 token 分块作为起点，对于单一事实可尝试 256 token。整文档向量嵌入耗时约为分块的 3 倍（在 NVIDIA L4 上），且压缩后质量损失更大（1-bit 下仅保留 89%），建议至少使用 2-bit 或保留重打分。压缩虽降低了存储成本，但重打分会引入额外延迟（冷缓存时超过 100 ms），需在自身查询上测试权衡。分块并未过时，但 32K 窗口为检索设计提供了更多探索空间。
Q&A
UltraBERT-Embed-150M 模型支持多长的输入？输出向量维度是多少？
UltraBERT-Embed-150M 支持最长 32K token 的输入，可将整篇文档压缩为单个 768 维向量。
在长文档检索中，整文档向量和 512 token 分块哪个效果更好？
整文档向量在 Passkey 任务上召回率达 99%，但在多数细节检索任务（如 2WikiMultihopQA、QMSum、MLDR）上不如 512 token 分块。分块在细节查找上更优。
为什么长文档用单个向量会丢失细节？
单个向量难以容纳长文档的所有细节。例如在 Needle 任务中，256 token 时整文档向量召回率为 84%，32K token 时降至 30%，而 512 token 分块在相同长度下召回率为 56%。
1-bit TurboQuant 压缩对分块向量有什么效果？
1-bit TurboQuant 将每个分块向量从 3072 字节压缩到 104 字节，体积缩小 30 倍。20 万篇文章的分块向量总大小约 140MB，保留约 95% 的检索质量，重打分后可达 98%。
整文档向量和分块向量结合使用效果如何？
在 Qdrant 中同时使用整文档向量和分块向量进行混合查询，仅在 SummScreenFD 和 Needle 任务上有小幅提升（最高 0.02 和 0.03），在 2WikiMultihopQA、QMSum 和 MLDR 上反而比单独使用分块差。
对于细节检索，文章建议的起始配置是什么？
文章建议细节检索仍以 512 token 分块为起点，对于单个事实可以测试 256 token。压缩使额外向量更可负担，但质量和重打分延迟需在自己的查询上测试。
