大模型微调数据选择策略及FunnelRAG渐进式检索实现

今天是2024年10月16日，星期三，北京，天气阴。

先说两个有意思的工作，都和当前大模型的热门方向相关。

第一个是关于大模型数据工程的，研究的是在大规模数据集上做监督微调（SFT）时，数据到底该怎么选。结果发现了一个相当反直觉的结论：随机选择，几乎总能打赢那些精心设计的数据选择技术。

第二个关乎RAG的最新进展，FunnelRAG，一种从粗糙到精细的渐进式检索范式，里面有些设计挺巧妙，但也有些坑需要注意。

供大家参考和思考。

一、大规模数据下监督微调（SFT）中的数据选择问题

最近这篇叫《Rethinking Data Selection at Scale: Random Selection is Almost All You Need》的工作（arXiv:2410.09335，代码也开源了）挺有意思。它专门研究在SFT场景下，海量数据里挑数据这回事到底有没有用。

核心结论非常直接：当你手头数据量很大的时候，大多数现有的数据选择方法，效果都很难显著超过最朴素的方法——随机选。文章还特别强调了一个观点：在SFT中，数据的多样性的优先级，可能比单纯追求高质量更高。另外，一个非常简单的技巧——按token长度过滤数据，反而是一种稳定又靠谱的方法，尤其是对那些能力不太强的基准模型来说。

有几个关键点值得拆开看看。

1、已有的数据选择方法

目前业界主流的自我评分方法，大致可以分为两大类：一类看数据质量，一类看数据多样性。

1）基于数据质量的方法

包括LESS、IFD、SelectIT和交叉熵这些。它们的基本思路是通过评估数据点的复杂性、完整性、评分或者影响力度来筛选数据。

比如LESS，它用低秩梯度相似性搜索来找“有影响力”的数据点。但问题是，影响力评分要依赖目标任务的目标集设计，这在现实场景里太难实现了——你很难为所有可能遇到的任务都准备齐全的目标数据。

IFD引入了一个“指令遵循难度”评分。麻烦在于，这个评分依赖response的困惑度（ppl），而ppl值又很受数据长度影响，结果筛出来的指令数据普遍都很短，平均才42个token，这显然不理想。

SelectIT靠模型的内在不确定性来挑数据点，但需要在多个LLM上跑评分，数据量一大，计算成本就指数级增长，大规模用不现实。

交叉熵方法相对直接，通过计算每个数据点的交叉熵来评估，熵值越高通常认为质量越好。

2）基于数据多样性的方法

包括DiverseEvol和ZIP这些。它们强调训练数据集的多样性。

DiverseEvol通过迭代采样训练子集，每次选和现有数据点距离最远的新数据点。想法不错，但时间消耗大到离谱——每次迭代要1到2天，整个选择过程下来要5到7天，实际生产环境根本扛不住。

ZIP则另辟蹊径，通过计算样本的压缩比率来选，比率越低越优先。它不费GPU资源，但选择过程是贪婪的，得一个一个往训练子集里加。在大规模数据集上效果并不好，比如在OpenHermes上，表现甚至还不如随机选。

2、关于多样性

从实验结果来看，基于多样性的策略整体上优于基于质量的策略。而且，如果给基于质量的方法加上K-means聚类，效果会明显提升。

举个例子，在Llama3和Qwen2模型上，结合K-means聚类的交叉熵方法，比单纯用交叉熵，平均得分分别提高了5%和3%。

不过话说回来，这个工作也有自身的局限。比如研究中使用的两个大规模数据集（Openhermes2.5和WildChat-1M），虽然已经不小了，但依然可能无法覆盖所有真实应用场景。而且很多现有数据选择方法本来就是为小规模数据集设计的，拿到大规模场景下自然水土不服，说明这些方法确实有改进空间。

另外，基于token长度的数据过滤方法虽然在部分场景有效，但不一定适用于所有模型，尤其是那些对长文本训练不敏感的。

二、从粗糙到精细的检索粒度的渐进式检索FunnelRAG

现有的RAG检索范式有两个核心痛点：一是平铺式的检索对单个检索器负担极大；二是恒定不变的检索粒度限制了性能上限。

有意思的是下面这张图很好地展示了这个问题：

《FunnelRAG: A Coarse-to-Fine Progressive Retrieval Paradigm for RAG》（arXiv:2410.10293）提出了一种新思路：从粗糙到精细的渐进式检索。具体来说，它采用了一个协作流程——先粗粒度，再细粒度；先大量候选，再少量精选；先用低容量检索器，再用高容量。简单说就是先做聚类，召回最近的类，从类里拿文档做排序，排序完再排段落。三个阶段：文档聚类簇 → 文档 → 段落。

听起来很美好对吧？但问题也跟着来了——这种粗到细的串行流程，容易造成召回偏置。

具体来看几个关键设计点：

1、FUNNELRAG框架中的渐进式检索流程

渐进式检索的核心理念是：通过逐步缩小候选规模、逐步提高检索器容量，来平衡检索效果和效率。

具体分三个阶段：

1）粗检索阶段：用BM25这样的稀疏检索器，从大规模文档集（比如21M篇文档）里，先筛出约4000篇粗粒度文档。

2）预排序阶段：用交叉编码器对这些文档做预排序，进一步缩小范围。这一阶段会把粗粒度文档切分成大约1000个文档级单元来排序。

3）后排序阶段：用更精细的列表级模型对段落级单元（大约100个）再做一次排序，最终拿到高质量结果。这个阶段会把文档级单元进一步切成段落级单元，分别交给低容量、中容量和高容量的检索器处理。

2、粗到细粒度分割的实现与影响

粗粒度分割阶段，用的聚类算法类似single-pass：

这种分割方式对检索性能的影响很显著：细粒度检索能更准确定位含答案的文档，提升召回率；粗粒度检索减少了初始候选规模，降低了计算量；通过逐步细分，还能将复杂任务分配给不同容量的检索器，实现负载均衡。

3、一个具体的例子

下面这张图给出了一个更直观的示例：

但也得承认，这个方法有不足之处。为了实现有效的检索，需要手工调整不少超参数，比如最大聚类大小、每个阶段的候选数量，这增加了系统复杂度，也需要一定专业知识。另外，尽管候选少了，但排名位置较低时计算成本依然不低。论文假设通过局部到全局的蒸馏方法能有效传递检索信号，但这个假设还没有被充分验证。而且模型越复杂，即使候选规模有限，计算开销也可能成为瓶颈——尤其是后排序阶段要处理大量段落级单元。

总结

这篇文章主要聊了两个工作。

第一个关于大模型数据工程，发现在大规模SFT场景下，随机选数据往往比那些复杂的挑选方法更靠谱。多样性比质量重要，而token长度过滤是个简单却有效的技巧。

第二个关于RAG新范式FunnelRAG。从粗到细的渐进式检索想法有亮点，但存在偏置问题。如果涉及动态更新，聚类数量、性能这些都会带来额外影响。而且为了实现有效检索，不少超参数需要手工调优，这既增加了复杂度，也考验经验。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：大模型微调数据选择策略及FunnelRAG渐进式检索实现要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题