BEAVER：不用训练也能把12万token压到3000，还比LLMLingua快26倍？

论文标题：BEAVER: A Training-Free Hierarchical Prompt Compression Method via Structure-Aware Page Selection

作者：Zhengpei Hu, Kai Li, Dapeng Fu, Chang Zeng, Yue Li, Yuanhao Tang, Jianqiang Huang

论文链接：https://arxiv.org/abs/2603.19635

代码链接：https://cslikai.cn/BEAVER/

🎯 核心摘要

大模型处理长文档有两个老大难问题：慢——自注意力 \(O(L^2)\) 复杂度导致128k token的预填充延迟高得离谱；笨——塞太多上下文进去反而"迷路"（Lost in the Middle效应），关键信息被淹没。现有的提示压缩方法要么靠困惑度逐token砍（砍完语法碎片化，上下文断裂），要么靠训练专用编码器（换个模型就得重训）。

BEAVER 换了个思路：不在token级别动刀，而是把长文档切成"页"，用双路池化把每页压成一个向量，再用语义+词法混合打分选出最重要的页面。整个过程零训练、零额外参数，128k上下文压缩延迟仅1.2秒——比 LongLLMLingua 快 26.4倍。在 RULER 多针检索任务上，BEAVER 拿到 83.7 分，几乎是 LLMLingua-2（47.9）的两倍。

定位上看，这不是什么"颠覆性突破"，而是一个工程设计精巧的免训练方案，核心贡献在于把"逐token筛选"升级为"结构化页面选择"，用张量操作替代串行计算，在速度和检索准确率上取得了不错的平衡。

📖 问题出在哪：现有压缩方法的三种病

假设你是一个律师，手上有一份300页的合同文档，客户问你："第127条里关于iPhone 17 Pro的促销价是多少？" 你不可能逐字读完300页再回答——你得先快速定位到相关段落，然后仔细阅读。

大模型面临同样的问题。把12万token的文档全塞给GPT，不仅贵、慢，效果可能还不如只喂相关段落。于是就有了"提示压缩"这个方向。但现有方案各有各的毛病：

图1：三种压缩范式的对比——无监督统计方法（A）压缩后语法碎片化、上下文丢失；有监督方法（B）保留了关键词但丢失了逻辑连接；BEAVER（C）通过结构感知的页面级选择保持了语法完整性和逻辑连贯性

图1：三种压缩范式的效果对比。注意看(A)中LongLLMLingua把"20%"压缩成了"a2%"——语法被破坏后模型直接答错了；(B)中LLMLingua-2保留了关键词但丢失了"普通客户需加价20%"的逻辑链；而(C)中BEAVER保持了完整句子结构，模型正确算出了$899 + 20% = $1,078.80

三种范式的核心区别：

范式 代表方法 原理 核心问题
无监督统计 Selective-Context, LongLLMLingua 用困惑度/自信息量给每个token打分，砍掉低分token 逐token删除破坏语法结构，压缩后文本碎片化
有监督学习 LLMLingua, LLMLingua-2 训练专用编码器做token级分类（留/删） 需要训练数据，换模型/领域迁移性差
免训练结构化 BEAVER 页面级选择 + 句子边界平滑 粒度较粗，可能保留少量冗余

🏗️ 方法详解：BEAVER 的三板斧

BEAVER 的名字来自"河狸"——一种擅长用树枝搭建精密水坝的动物。类比过来，BEAVER 把长文档当作一条河流，不是逐滴过滤（token级），而是用结构化的"坝体"（页面）来拦截和选择关键水段。

整体架构由三个模块组成：Segmenter（分段器）→ PageEncoder（页面编码器）→ QueryPlanner（查询规划器）。

图2：BEAVER整体流程。原始文本先被Segmenter切分成2D页面矩阵，PageEncoder用双路池化（Mean Pooling + Max Pooling）将每页编码为稠密向量，QueryPlanner通过语义+词法混合匹配选出高相关页面，最后Sentence Smoother将选中区域扩展到句子边界

图2：BEAVER 完整流程。上半部分是编码过程（Segmenter + PageEncoder），下半部分是选择过程（QueryPlanner + Sentence Smoother）。注意颜色编码：黄色=Anchor页（开头元数据）、红色=Flow页（查询前的连续窗口）、橙色=Flash页（远距离高分页面）

第一板斧：Segmenter——把token序列变成二维"书页"

传统方法把长文档看成一维token流，逐个打分。BEAVER 的做法更接近人类阅读习惯——先翻书，按自然段落分页。

具体来说，Segmenter 以换行符为天然分隔符，用贪心策略将连续段落打包成固定容量 \(M\) 的"页面"。如果某个段落超过 \(M\) 个token，就拆分到多个页面。最终输出一个二维页面索引矩阵 \(\mathbf{P}\)，空位用 \(-1\) 填充。

这一步的关键参数是页面容量 \(M\)。消融实验显示 \(M=64\) 是最优值——太小（\(M=32\)）会切碎段落，太大（\(M=128\)）会把不相关内容混在同一页，分辨率下降。

第二板斧：PageEncoder——双路池化捕获全局语义和局部特征

每一页的token嵌入需要被压缩成单个页面向量。BEAVER 设计了双路池化策略，分别捕获两种不同类型的信息：

路径一：加权均值池化（捕获全局语义）

不是简单求平均，而是用 In-Context ITF（逆词频） 加权：

\[w^{itf}(t) = \text{Norm}\left(\log\left(1 + \frac{L_c + L_q}{1 + \text{tf}(t)}\right)\right)\]

直觉解释：在当前文档中出现频率越低的词，信息量越大，权重越高。这跟信息检索中的经典 TF-IDF 思想一脉相承，但区别在于它是上下文内统计（in-context），而非全局语料库统计。

\[\boldsymbol{\mu}_i = \frac{\sum_{j=1}^{M} \omega_{i,j} \mathbf{x}_{i,j}}{\sum_{j=1}^{M} \omega_{i,j} + \varepsilon}\]

路径二：最大池化（捕获局部显著特征）

\[\mathbf{m}_i = \max_{1 \le j \le M} (B_{i,j} \mathbf{x}_{i,j} + (1 - B_{i,j}) \cdot \beta)\]

其中 \(B_{i,j}\) 是有效位掩码，\(\beta\) 是一个很小的负数，防止padding位被选中。Max Pooling 的作用是捕获页面中最突出的局部特征——即使一页中只有一个关键实体名，它也能被保留下来。

最终用线性融合：\(\hat{\mathbf{p}}_i = \gamma \boldsymbol{\mu}_i + (1-\gamma) \mathbf{m}_i\)，其中 \(\gamma=0.7\)，即全局语义占主导。

为什么需要双路？想象一页合同中99%是格式化模板，只有一句"赔偿金额不超过500万"是关键信息。均值池化会被大量模板文本稀释，Max Pooling 则能抓住这个异常突出的特征。两者互补。

第三板斧：QueryPlanner——语义+词法+结构先验的三重选择

有了每页的向量表示，下一步是根据用户查询选出最相关的页面。QueryPlanner 设计了混合打分机制：

语义得分（向量空间匹配）：

\[s_{sem}(i) = \sum_{k=1}^{K} w_{q_k}^{itf} \frac{\hat{\mathbf{p}}_i \cdot \mathbf{q}_k}{\|\hat{\mathbf{p}}_i\|_2 \cdot \|\mathbf{q}_k\|_2}\]

词法得分（精确关键词匹配）：

\[s_{lex}(i) = \sum_{\ell \in \mathcal{P}_i} \mathbb{I}[C_\ell \in \mathcal{T}_\mathcal{Q}] \cdot w_{C_\ell}^{itf}\]

混合得分：\(s_{mix}(i) = \lambda \cdot s_{sem}(i) + (1-\lambda) \cdot s_{lex}(i)\)，其中 \(\lambda=0.7\)。

为什么要混合？消融实验给出了明确答案：纯语义匹配（Semantic Only）掉 6.0 分，纯词法匹配（Lexical Only）掉 3.1 分。语义匹配擅长捕捉"意思相近但用词不同"的段落，词法匹配则在精确实体检索（如具体人名、数字）上更靠谱。

除了按分数排名，BEAVER 还引入了三种结构先验（Structural Priors）来保证选择的鲁棒性：

策略 说明 消融掉的影响
Anchor 固定选取开头 \(k_{anc}=4\) 页 保留文档标题、元信息等全局上下文。去掉后暴跌 -21.7 分
Flow 查询前的连续 \(w_{flow}=4\) 页窗口 类似"工作记忆"，保留查询附近的上下文。去掉后跌 -8.1 分
Flash 按混合分数选Top-k远距离页面 捕获散落在文档各处的关键证据。去掉后跌 -2.7 分

Anchor 的影响最大——这说明长文档的开头往往包含了理解全文所必需的元信息（目录、摘要、背景说明等），直接砍掉开头是灾难性的。

句子级平滑：压缩后的"缝合"

页面选中后，BEAVER 还做了一步关键操作：将选中区域向外扩展到最近的句子边界。

图3：句子级平滑的示意图。初始检索到的span（橙色实线框）被向外扩展到最近的句子边界（虚线框），确保语法完整性

图3：句子级平滑。被选中的页面区域（橙色框）自动扩展到完整句子，避免出现"I never said"这样的断头句

这个操作看起来简单，但消融结果显示它贡献了 1.6 分的提升——因为它保证了压缩后的文本在语法上是完整的，LLM 不用对着碎片化的文本做"脑补"。

🧪 实验结果：四个基准的全面评测

实验设置

  • 后端LLM：gpt-3.5-turbo-instruct
  • 嵌入模型：Qwen3-8B embeddings
  • 压缩预算：2,000 / 3,000 token
  • 四大基准：LongBench（4,750样本）、ZeroSCROLLS（4,378样本）、RULER（13任务，4k-128k合成上下文）、L-Eval（2,197样本）

主实验：LongBench + ZeroSCROLLS

方法 类型 SingleDoc MultiDoc Summ. FewShot Synth. Code AVG 延迟(s) 加速比
Selective-Context 无监督 16.2 34.8 24.4 15.7 8.4 49.2 24.8 47.1 0.3×
LongLLMLingua 无监督 39.0 42.2 27.4 69.3 53.8 56.6 48.0 6.1 2.6×
LLMLingua 有监督 22.4 32.1 24.5 61.2 10.4 56.8 34.6 5.9 2.6×
LLMLingua-2 有监督 29.8 33.1 25.3 66.4 21.3 58.9 39.1 3.7 4.2×
BEAVER 免训练 40.7 37.6 22.1 57.4 38.2 57.1 42.2 3.0 5.2×
原始Prompt（无压缩） - 39.7 38.7 26.5 67.0 37.8 54.2 44.0 15.6 -

几个值得关注的点：

  1. SingleDoc QA 是 BEAVER 的强项：40.7 分甚至超过了无压缩的原始 Prompt（39.7），说明压缩掉噪音信息反而有利于模型聚焦关键内容
  2. FewShot 是短板：57.4 vs LongLLMLingua 的 69.3，掉了12分。页面级压缩在需要保留完整 few-shot 示例时粒度太粗
  3. Summarization 也偏弱：22.1 分，因为摘要任务需要全局信息覆盖，而 BEAVER 的选择策略天然倾向于局部高相关段落

RULER：多针检索的碾压性优势

方法 S-1 S-2 S-3 Key-1 Key-2 Key-3 Val Qry VT FWE QA-1 QA-2 AVG
LLMLingua 100.0 5.0 4.0 7.0 6.0 12.0 6.0 4.8 59.4 90.7 15.0 37.0 28.9
LongLLMLingua 100.0 6.0 4.0 9.0 2.0 3.0 7.8 7.3 60.4 91.3 19.0 36.0 28.8
LLMLingua-2 27.0 86.0 27.0 72.0 11.0 2.0 80.3 82.3 3.4 95.3 45.0 43.0 47.9
BEAVER 100.0 100.0 100.0 99.0 88.0 41.0 99.8 99.8 78.2 93.7 50.0 55.0 83.7

RULER 是合成的"大海捞针"任务，BEAVER 在这里的表现堪称碾压：

  • 单针检索（S-1/S-2/S-3）全部满分或接近满分
  • 多键检索（Key-1/Key-2）从 LLMLingua-2 的 72.0/11.0 飙到 99.0/88.0
  • 整体平均 83.7 vs 次优 47.9，领先近 36 分

这个结果合理吗？RULER 是合成数据，"针"的位置和内容都是精心设计的。页面级选择对这类"特定信息精准检索"天然友好——目标信息集中在少数页面，选对页面就等于全选对。但在真实场景中，信息分布往往更分散，优势不会这么极端。

L-Eval：跨域泛化

方法 Coursera QA QuALITY SFictionQA TPO LongFQA Legal AVG
LLMLingua 58.9 50.0 60.9 65.1 34.3 21.9 — 48.5
LongLLMLingua 62.2 51.0 65.6 71.0 37.7 21.3 — 51.5
LLMLingua-2 64.4 55.0 66.4 73.2 45.0 23.7 — 54.6
BEAVER 64.4 56.9 76.6 74.0 44.7 28.8 — 57.6

在 L-Eval 上领先 LLMLingua-2 约 3 分。特别是在 SFictionQA（科幻小说问答）上 76.6 vs 66.4，领先 10 分——长篇小说的章节结构与 BEAVER 的页面划分天然契合。

效率对比：线性增长 vs 超线性膨胀

图4：不同压缩方法在16k-128k上下文下的推理延迟对比。BEAVER（绿色）延迟随上下文长度线性增长，在128k时仅1.2秒；LongLLMLingua（红色）延迟爆炸式增长到31.7秒

图4：延迟对比。横轴是上下文长度（16k到128k），纵轴是压缩延迟（毫秒）。BEAVER 在128k时延迟仅约1200ms，而 LongLLMLingua 需要约31700ms——差距达26.4倍

BEAVER 的延迟优势来源于操作全是张量化的：嵌入提取、池化、余弦相似度计算都可以高效并行。而 LongLLMLingua 需要逐token计算困惑度，这是串行的自回归过程，上下文越长越慢。

🔬 消融实验：每个组件都在干什么

配置 S-Doc M-Doc Avg. Δ
BEAVER（完整） 40.7 37.6 39.2 —
页面大小 M=32 38.5 36.3 37.4 -1.8
页面大小 M=128 37.5 36.1 36.8 -2.4
去掉 Max Pooling 39.2 33.7 36.5 -2.7
去掉 Mean Pooling 39.2 34.0 36.6 -2.6
去掉多token查询 38.3 34.3 36.3 -2.9
换用 LLaMA3 嵌入 39.4 38.2 38.8 -0.3
去掉 ITF 加权 35.7 37.3 36.5 -2.7
仅语义匹配 36.5 29.9 33.2 -6.0
仅词法匹配 38.8 33.4 36.1 -3.1
去掉句子平滑 40.4 34.7 37.6 -1.6
仅 Flow 策略 33.3 28.8 31.1 -8.1
仅 Anchor 策略 15.0 20.0 17.5 -21.7
仅 Flash 策略 39.7 33.2 36.4 -2.7

几个关键发现：

  • 换嵌入模型影响极小（LLaMA3 只掉 0.3 分），说明 BEAVER 对嵌入模型不敏感，跨模型迁移能力强
  • 仅 Anchor 策略暴跌 21.7 分——光保留开头而不根据查询选择内容，等于瞎压
  • 仅语义掉 6 分 是所有 QueryPlanner 消融中最严重的，说明词法精确匹配是不可或缺的补充
  • 双路池化缺一不可，各掉 2.6-2.7 分，验证了 Mean+Max 互补的设计直觉

跨模型可扩展性

图5：在不同规模Qwen3模型上的性能保持率。BEAVER（蓝色）在0.6B到32B模型上保持84%-98%的Dense性能，而其他方法仅28%-48%

图5：RULER 上的性能保持率（相对于不压缩的Dense上界）。BEAVER 在 Qwen3-0.6B 上竟然保持了 98% 的性能——小模型受压缩影响反而最小，这有点反直觉

0.6B 模型保持率最高（98%），可能的解释是：小模型本身处理长上下文能力弱，Dense 性能就不高，压缩后反而通过去除噪音提升了信噪比。

🤔 批判性分析：BEAVER 的边界在哪

优势确实明显

  1. 零训练成本：不需要准备训练数据、不需要微调，拿来就用。这在实际工程部署中价值很大
  2. 速度碾压：128k 上下文 26.4 倍加速，且延迟线性增长
  3. 检索能力突出：在需要"大海捞针"的场景下效果极好

但也有几个需要冷静看待的问题

问题一：RULER 的高分有多少含金量？

RULER 是合成基准，"针"的分布相对规律。83.7 的高分在一定程度上是因为页面级选择与"信息集中在少数页面"的合成场景高度匹配。在真实文档中——信息散落在大量段落的各个角落、需要多跳推理来关联——页面级粒度可能不够精细。论文自己也承认了这个局限："retrieval mechanism struggles with deep multi-hop reasoning...where supporting evidence shares little direct overlap"。

问题二：FewShot 和 Summarization 的掉分不容忽视

LongBench 上 FewShot 掉了近 12 分（vs LongLLMLingua）、Summarization 掉了 5 分。这两类任务的共同特点是需要广覆盖——few-shot 需要完整保留示例，摘要需要全局信息。页面级选择天然倾向于"精准但局部"，在需要"全面但宽泛"的场景下会吃亏。

问题三：超参数敏感性

\(M=64\)、\(\gamma=0.7\)、\(\lambda=0.7\)、\(k_{anc}=4\)、\(w_{flow}=4\) ——这些超参数是在实验中调出来的，论文承认"requires manual adjustment across drastically different domains"。免训练不代表免调参。

问题四：对 LLMLingua 系列的比较是否充分？

LLMLingua-2 虽然需要训练，但训练一次后可以跨任务使用。而 BEAVER 的免训练优势在面对固定领域部署时可能并不突出——如果你就是做法律文档问答，花一次训练成本换更高的准确率可能更划算。

💡 工程启示

  1. "结构化"是长文档压缩的正确方向：比起逐token打分，利用文档的自然结构（段落、章节、页面）做选择，既能保持语义完整性，又能用张量操作加速

  2. 语义+词法混合检索的普适性：这个思路在 RAG 系统中同样适用。单纯的向量检索在精确实体匹配上容易翻车，加入 BM25 风格的词法匹配能显著提升鲁棒性

  3. Anchor + Flow + Flash 的选择策略可借鉴：保留文档头部元信息（Anchor）、查询附近上下文（Flow）、全局高分段落（Flash）——这种三路选择策略可以直接应用到 RAG 的 chunk 重排序中

  4. ITF 加权的轻量替代：相比传统的 TF-IDF 需要全局语料库统计，In-Context ITF 只需要当前文档的词频就能工作，在实时系统中更实用

📝 总结

BEAVER 把提示压缩从"逐token删删删"升级到了"结构化页面选择"，核心贡献是一套免训练、张量化、可并行的压缩框架。在检索类任务上效果拔群（RULER 83.7 分），速度快了一个数量级（26.4倍），跨模型泛化能力也不错。

但这不是万能药。在需要广覆盖的 few-shot 和摘要任务上有明显短板，多跳推理场景下的表现也有待验证。它更适合"长文档 + 精准检索" 这类场景——比如合同审查、技术文档问答、知识库搜索——而非通用的长上下文压缩方案。

从方法论层面看，BEAVER 验证了一个有价值的设计思想：在token和document之间存在一个更合适的压缩粒度——"页面"，它既保留了结构完整性，又具备足够的语义区分度。这个思路值得在更多场景中探索。

📊 附录：三个真实案例对比

以下是论文提供的三个详细案例，直观展示了不同压缩方法的差异。

案例1：QA任务——iPhone 15 Pro 定价查询

案例1：三种方法在QA任务上的对比。LongLLMLingua破坏了语法导致回答失败，LLMLingua-2保留了价格但丢失了加价逻辑导致幻觉，BEAVER保持了完整的逻辑链正确回答

案例1：查询"普通用户购买iPhone 15 Pro (256GB)的价格"。正确答案是\(1,078.80（\)899 + 20%加价）。只有BEAVER通过保留完整的加价规则和价格信息，让LLM得出了正确答案

案例2：摘要任务——政府报告总结

案例2：摘要任务对比。LongLLMLingua的压缩结果语法破碎到无法提取具体规则，LLMLingua-2保留了关键词但丢失了连接逻辑，BEAVER保持了完整的程序性逻辑链

案例2：总结众议院规则报告。BEAVER保持了"72小时可用性要求"、"豁免条件"和"两个立法日"等复杂程序性逻辑的完整性

案例3：Few-Shot 数学推理

案例3：Few-Shot任务对比。LongLLMLingua和LLMLingua-2都破坏了CoT推理链，LLM只能依赖零样本知识猜答案；BEAVER保留了完整的CoT示例，LLM成功利用示例进行推理

案例3：包含15个数学Word Problem的Few-Shot Prompt。BEAVER 保留了完整的 Chain-of-Thought 示例块（"Let's think step by step..."），LLM 通过真正的上下文学习（而非零样本猜测）得出正确答案

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注公众号：机器懂语言