牛了,UMG-RAG实现自适应检索粒度
今天分享普渡大学的 UMG-RAG 论文,它回答了一个每个做 RAG 的人都会遇到的问题:chunk size 到底该设多少?
答案是:别拍脑袋定一个固定值。不同查询需要不同粒度,而检索器自己的分数分布会告诉你——它对当前查询有多确定。
粒度权衡:粗了有噪声,细了会漏检
RAG 的检索粒度是一个根本性权衡:
粗粒度 chunk(如 32 句一段)保留了完整上下文,答案很可能就在里面。但同时也塞了大量无关内容,让 LLM 遭遇 lost-in-the-middle——答案确实在上下文里,但被噪声淹没,模型可能忽略它。
细粒度 chunk(如 2 句一段)更精确,噪声少。但短 chunk 可能缺乏语义线索、实体别名或桥接上下文,导致检索器根本找不到它。
更关键的是,不同查询需要不同粒度。一个简单事实查询可能 2 句就够;一个需要多跳推理的查询可能需要 16 句的上下文来桥接信息。固定粒度注定无法同时服务两类查询。
UMG-RAG 的思路是:与其人工选一个粒度,不如同时用多种粒度检索,然后根据检索器自己对每条查询的"确定程度"来决定信谁。
主方案UMG-RAG
UMG-RAG 是 training-free 的。它不训练新 retriever,不修改 generator,只在现有 dense 和 sparse retriever 之上加了一层自适应融合。
第一步:多粒度多通道检索
文档被切成 5 种粒度的重叠 chunk:2、4、8、16、32 句。对每种粒度,dense retriever(如 BGE-M3)和 sparse retriever(如 SPLADEv3)各自检索 top-M=100 个候选。
这样,每条查询产生 5 × 2 = 10 组候选列表,每组对应一个 expert-粒度对。
第二步:分数分布 → 证据分布 → 熵 → 置信度
核心机制从这里开始。
不同 expert、不同粒度的分数不可直接比较——dense 分数和 sparse 分数量级不同,粗粒度分数和细粒度分数分布也不同。所以 UMG-RAG 先把每组分数归一化,然后转化成证据分布:
p_{e,g}(u|q) = softmax(s̃_{e,g}(q,u))这个分布衡量的是:expert e 在粒度 g 下,把多少"证据质量"集中在候选 u 上。
然后计算归一化熵:
H_{e,g}(q) = -Σ p·log(p) / log(|C|)低熵 = 分布集中 = 检索器有明确偏好 = 可信****高熵 = 分布平坦 = 检索器犹豫不决 = 不可信
置信度就是:
c_{e,g}(q) = 1 - H_{e,g}(q)所有 10 组 expert-粒度对的置信度归一化后,作为融合权重w_{e,g}(q)。
第三步:置信度加权融合 + 长度惩罚排序
每个 chunk 的最终证据概率是所有 expert-粒度对的置信度加权混合:
P(u|q) = Σ w_{e,g}(q) · p_{e,g}(u|q)然后按 evidence utility 排序:
R(u|q) = P(u|q) / sqrt(ℓ(u))ℓ(u)是 chunk 的 token 长度。sqrt 惩罚温和地偏袒紧凑 chunk,但如果一个长 chunk 获得了很强的证据支持,它仍然可以排名靠前。
最终取 top-K=5 个 chunk 送入 generator。
这个设计的本质是:让检索结果自己告诉你它有多可靠。对于词汇匹配明确的查询,sparse retriever 在细粒度上的分数分布会很尖锐(低熵高置信),权重自然偏向它;对于需要语义理解的查询,dense retriever 在粗粒度上的分数分布可能更集中,权重就会偏向它。不需要训练,不需要人工调参。
UMGP-RAG:细粒度做定位器,粗粒度做上下文
UMG-RAG 还有一个扩展:UMGP-RAG(P = Parent Promotion)。
问题:细粒度 chunk 检索精准,但可能上下文不够;粗粒度 chunk 上下文完整,但噪声多。
UMGP-RAG 的解法:
- Parent promotion:g=2 或 g=4 的命中 chunk,提升到其 g=8 的 parent chunk。细粒度检索充当"定位器",告诉系统"答案大概在这里";返回给 generator 的是更宽的 parent,提供局部连贯性。
- Bounded evidence aggregation:多个细粒度 chunk 映射到同一个 parent 时,用
A(v) = 1 - Π(1-P(u))聚合证据。多个命中的 parent 会获得更高分数——直觉上,如果多个独立检索信号都指向同一个区域,那里更可能包含答案。 - Overlap-aware deduplication:如果两个 chunk 的句子重叠超过 75%(较短者为准),跳过后来的。这避免了返回几乎相同的上下文。
实验结果
论文在 Natural Questions(NQ)和 HotPotQA 上测试,使用 3 个 dense retriever(BERT / BGE-M3 / Qwen3-Embedding-4B)+ SPLADEv3 sparse retriever,2 个 generator(Qwen2.5-3B / Llama-3.2-3B)。
最关键的发现:检索召回最高 ≠ 生成最好
以 BGE-M3 + Qwen2.5-3B-Instruct 在 NQ 上为例:
| 方法 | AR@5(检索) | F1(生成) | AR(生成) |
|---|---|---|---|
| LongRAG | 0.9101 | 0.4598 | 0.4219 |
| Hybrid (RRF) | 0.8241 | 0.4927 | 0.4727 |
| UMG-RAG | 0.8023 | 0.4809 | 0.4593 |
| UMGP-RAG | 0.8759 | 0.5052 | 0.4794 |
LongRAG 的检索召回率最高(0.91),因为它的 chunk 很长,答案几乎一定在里面。但生成 F1 和 AR 却不如 UMGP-RAG——因为长 chunk 里太多噪声,答案可能出现在 LLM 不容易注意到的位置。
UMGP-RAG 的检索召回略低于 LongRAG,但生成质量最好。这验证了论文的核心主张:RAG 需要的不是最长的上下文,而是紧凑、连贯、与查询对齐的上下文。
Parent promotion 持续有效
在所有 retriever-generator 组合中,UMGP-RAG 都优于 UMG-RAG。这说明自适应融合最有效的方式是:用细粒度检索定位,用粗粒度 parent 返回上下文。
成本
多粒度检索确实增加了预处理开销:标准 RAG 0.15s/query,UMGP-RAG 5.36s/query。但生成阶段反而更快更省内存(0.33s vs 0.71s,6716 MiB vs 7558 MiB),因为送入 generator 的上下文更紧凑。
学AI大模型的正确顺序,千万不要搞错了
🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!
有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!
就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!
我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~
