• 現有 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??