让RAG告别断章取义，HiChunk做到了~

• 现有 RAG 评测只关心“检索-生成”两端，对中间的文档怎么切分几乎不测，导致“证据稀疏”场景下好坏难分。
• 腾讯优图提出HiCBench——第一份专门评测“切分质量”的基准，包含人工标注的多级切分点+证据稠密 QA。

• 同时给出HiChunk框架：用微调 LLM 把文档先建成多级语义树，再配一个Auto-Merge 检索算法，动态决定召回哪一层节点。

RAG 的中间层“无人区”

图1：同一段落用不同切分方法可能得到完全一样的 top-chunk，但证据其实被拦腰截断，现有稀疏证据 QA 无法发现。

表1：主流 RAG 基准的证据极度稀疏，导致“切得好/切得差”在端到端指标上几乎无差别。

HiCBench：第一份“切分专用”评测

图2：HiCBench 构建流程——先人工标多级结构→再生成证据稠密 QA→保留证据占比≥10% 且 Fact-Cov≥80% 的样本。

三种任务类型

关键数字

• 130 篇长文（平均 8.5 k 词）
• 1 200 人工标注多级切分点
• (659 T1 + 541 T2)  QA 对，平均证据句 20+

HiChunk：把文档建成“可伸缩”的树

两级子任务

1. 切分点检测：在哪句断开？
2. 层级分配：这段属于 L1/L2/…/Lk？

用指令微调的 4 B 小模型（Qwen3-4B）直接生成“<sent_i> 是 L2 标题”式文本，统一解决。

超长文档怎么办？

图2(a) 迭代推理：每次只看 8 k token，滑动窗口产生局部切分点，再 Merge 到全局树，解决“层次漂移”。

Auto-Merge：检索时自动“拼积木”

图2(b) Auto-Merge：按 token 预算 T 动态决定“子节点→父节点”是否上卷，保证语义完整又不爆长度。

合并条件（同时满足）：

1. 已召回兄弟节点 ≥2
2. 兄弟累计长度 ≥ θ*（随已用 token 自适应增长）
3. 剩余预算足够装入父节点

怎么从这棵树里召回最合适的一段

实验结果

切分准确率

• 表3：HiChunk 在域内/域外均显著优于语义相似度或 LLM 单级切分。*

端到端 RAG（Qwen3-32B）

表4：证据越稠密，HC200+AM 优势越大；在稀疏数据集（GutenQA、OHRBench）上与基线持平，证明“不伤害”原有能力。

token 预算影响

图3：2 k→4 k token 预算下，HC200+AM 的 Rouge、Fact-Cov 全程高于其他切分策略。

最大层级消融

图4：只保留 L1 时证据召回掉 8%+；L3 后收益饱和，建议默认 3 级。

耗时

表5：HC 在保证最高质量的同时，速度是 LC 的 2×+ 快，可在线部署。

https://arxiv.org/pdf/2509.11552
HiChunk: Evaluating and Enhancing Retrieval-Augmented Generation with Hierarchical Chunking
Code: https://github.com/TencentCloudADP/HiChunk.git
Data: https://huggingface.co/datasets/Youtu-RAG/HiCBench

本文转载自​​PaperAgent​​