让RAG告别断章取义_HiChunk做到了
- 现有 RAG 评测只关心"检索—生成"两端，对中间的文档怎么切分几乎不测，导致"证据稀疏"场景下好坏难分。
- 腾讯优图提出 HiCBench——第一份专门评测"切分质量"的基准，包含人工标注的多级切分点 + 证据稠密 QA。
- 同时给出 HiChunk 框架：用微调 LLM 把文档先建成多级语义树，再配一个 Auto-Merge 检索算法，动态决定召回哪一层节点。
图 1：HiChunk 论文标题页（Tencent Youtu Lab，arXiv:2509.11552）
一、RAG 的中间层"无人区"
图 2（论文 Figure 1）：同一段落用不同切分方法可能得到完全一样的 top-chunk，但证据其实被拦腰截断，现有稀疏证据 QA 无法发现
表 1（论文 Table 1）：主流 RAG 基准（Qasper / OHRBench / GutenQA）的证据极度稀疏——OHRBench 与 GutenQA 的平均证据句仅 1.7 句，导致"切得好/切得差"在端到端指标上几乎无差别
二、HiCBench：第一份"切分专用"评测
HiCBench 的构建流程：先由人工标注文档的多级切分结构，再基于标注生成证据稠密的 QA 对，并保留证据占比 ≥10% 且 Fact-Cov ≥80% 的样本。
1. 三种任务类型
| 类型 | 证据分布 | 用途 |
|---|---|---|
| T0 证据稀疏 | 1–2 句 | 模拟传统场景 |
| T1 单块证据稠密 | 同一语义块 512–4096 词 | 考核"块内完整" |
| T2 多块证据稠密 | 跨 2+ 语义块，256–2048 词/块 | 考核"跨块召回" |
2. 关键数字
- 130 篇长文（平均 8.5K 词）
- 1200 个人工标注多级切分点
- 1200 个 QA 对（659 个 T1 + 541 个 T2），平均证据句 20+
三、HiChunk：把文档建成"可伸缩"的树
图 3（论文 Figure 2）：HiChunk 框架总览——(a) 长文档迭代推理，(b) Auto-Merge 检索算法
1. 两级子任务
- 切分点检测：在哪句断开？
- 层级分配：这段属于 L1/L2/…/Lk？
用指令微调的 4B 小模型（Qwen3-4B）直接生成"<sent_i> 是 L2 标题"式文本，统一解决。
2. 超长文档怎么办？
Algorithm 1（对应图 3(a)）：迭代推理伪代码——每次只看 8K token，滑动窗口产生局部切分点，再 Merge 到全局树，解决"层次漂移"
四、Auto-Merge：检索时自动"拼积木"
Algorithm 2（对应图 3(b)）：Auto-Merge 检索伪代码——按 token 预算 T 动态决定"子节点→父节点"是否上卷，保证语义完整又不爆长度
合并条件（同时满足）：
- 已召回兄弟节点 ≥ 2
- 兄弟累计长度 ≥ θ*（随已用 token 自适应增长）
- 剩余预算足够装入父节点
五、实验结果
1. 切分准确率
表 3（论文 Table 3）：HiChunk 在域内/域外均显著优于语义相似度（SC）或 LLM 单级切分（LC）
2. 端到端 RAG（Qwen3-32B）
表 4（论文 Table 4）：证据越稠密，HC200+AM 优势越大；在稀疏数据集（GutenQA、OHRBench）上与基线持平，证明"不伤害"原能力
3. token 预算影响
图 4（论文 Figure 3）：2k→4k token 预算下，HC200+AM 的 ROUGE、Fact-Cov 全程高于其他切分策略
4. 最大层级消融
图 5（论文 Figure 4）：只保留 L1 时证据召回掉 8%+；L3 后收益饱和，建议默认 3 级
5. 耗时
表 5（论文 Table 5）：HC 在保证最高质量的同时，速度是 LC 的 2 倍以上，可在线部署