AutoIndex：把文档索引做成可执行代码，BM25召回率提升30.5%

AutoIndex: Learning Representation Programs for Retrieval

论文原文 ↗ 论文发布 解读发布 解读：AI前沿分享

AutoIndex：把文档索引做成可执行代码，BM25召回率提升30.5% 论文图示

在检索增强生成（RAG）和现代搜索系统的工程实践中，存在一个长期被忽视的盲区：文档表示（Document Representation）。绝大多数优化工作都集中在链路的后半段，团队会花费大量精力微调稠密向量模型（Dense Retriever）、训练交叉编码重排器（Cross-Encoder Reranker）、或者设计复杂的提示词工程；而在链路的最前端，如何把一篇原始长文档切片、打平、挂载元数据并送入索引引擎，往往只是粗暴地依赖一套固定规则——比如固定 512 词的滑动窗口、50 词重叠率，或者简单的 Markdown 标题保留。

ArXiv URL：https://arxiv.org/abs/2607.18603v1

来自 Databricks 与马萨诸塞大学阿默斯特分校（UMass Amherst）的研究团队在最新论文中提出了一个截然不同的视角：文档在进入检索系统前的表示形式，不应该是一成不变的预处理超参数，而应当被视作可优化的代码程序。

基于这一理念，他们推出了名为 AutoIndex 的框架。AutoIndex 完全不修改底层的检索模型（实验中全程使用最传统的 BM25 检索器），也不做任何参数微调，而是让大语言模型（LLM）智能体去迭代搜索并生成 Python 数据转换代码，自动执行切块、降噪、重组与字段重加权。在极具挑战性的复杂检索基准 CRUMB 上，AutoIndex 生成的代码程序让固定的 BM25 在全部 8 个异构任务上均取得了显著提升，Recall@100 平均提升 8.4%，最高提升 30.5%，nDCG@10 最高提升达 43.6%。最关键的是，这种优化完全发生在离线建库阶段，搜索阶段不需要调用任何 LLM，没有任何推理延迟和 API 成本增加。

被固化的文档表示与检索瓶颈

回顾当前的信息检索与 RAG 落地架构，文档预处理环节始终处于一种尴尬的折中状态。

学术界与工业界的主流优化策略大致可以分为两类：一类是匹配函数层面的优化，从稀疏匹配升级到稠密检索、混合检索以及以 ColBERT 为代表的 Late-Interaction 架构；另一类则是管线级调优（Pipeline Optimization），例如通过自动化搜索框架在多种 Retriever、Reranker 和提示词模板之间寻找最优组合。然而，这些方案默认底层的索引单元（Indexable Units）是静态给定的。

当开发者意识到切分方式对效果影响巨大时，传统的做法通常是做网格搜索（Grid Search），去测试 256、512 还是 1024 的分块长度，或者设计定制化的元数据拼接模板。这种启发式规则不仅探索空间极其狭窄，而且无法适应复杂文档的异构结构。例如，在包含大量行内公式的技术文档中，未经处理的 LaTeX 源码会迅速稀释关键词词频；在法律案卷中，分散在章节末尾的判决引用需要向上挂载到案件概述才能产生匹配；在医疗临床试验数据中，表格与正文的混合排版会让通用的滑窗分块彻底粉碎原本的实体关联。

此前也有一些试图动态重写文档的工作。例如 Doc2Query 通过模型预测可能的问题并拼接到文档后，但极易引入模型幻觉导致索引污染；另一些方案则尝试在索引时调用 LLM 为每一篇文档生成摘要或结构化抽取，这种做法在百万级文档的实际企业知识库面前，会带来难以承受的建库成本。

AutoIndex 的切入点正在于此：它不针对单篇文档调用大模型重写，也不去调整检索器参数，而是直接在“文档转换程序”这一代码空间中进行搜索。它寻找的是一段通用的、确定性的可执行 Python 代码，这段代码负责将原始文档集合映射为最优的索引单元。

AutoIndex 核心架构：双智能体的验证导向程序搜索

AutoIndex 将文档索引过程形式化为一个黑盒代码合成问题。设输入文档为 $d$，待优化的 Python 代码程序为 $\theta$，由该代码实现的文档到索引单元的映射函数为 $f_\theta$。运行代码后，原始文档被转化为一系列可索引文本单元：

\[f_{\theta}(d)=\{c_{1},\ldots,c_{k}\}\]

每个单元 $c_i$ 均保留其所属源文档的标识。在整个语料库 $D$ 上运行后，系统构建起索引库 $C_{\theta}=\bigcup_{d\in D}f_{\theta}(d)$。检索器 $R$ 在测试阶段根据查询词 $q$ 对单元进行打分，并通过 MaxP 规则聚合为源文档的分数：

\[S_{\theta}(q,d)=\max_{c\in f_{\theta}(d)}R(q,c)\]

由于检索器 $R$（如 BM25）、评分聚合规则和索引后端在整个实验中完全冻结，检索性能的任何波动，都可以严格归因于代码程序 $\theta$ 的优劣。

AutoIndex 整体优化闭环

为了在庞大的代码空间中高效找到能提升检索质量的程序，AutoIndex 设计了一个闭环优化迭代循环，核心由两个分工明确的 LLM 智能体协作驱动：

生成的代码随后在隔离沙箱中执行，对验证集文档进行切分并重建索引，评估验证集上的指标变化 $\Delta J$（主要优化目标为 Recall@100）。AutoIndex 采用了审慎的选择策略：只有指标提升超过设定阈值 $\tau$ 的代码才会被保留。如果单轮迭代中有多个候选程序均带来正向收益，系统不会盲目随机挑选，而是提示 LLM 尝试将多个有效变换逻辑融合进一个综合程序中；只有当融合版程序的性能超过所有单一候选时才采纳，否则回退保留表现最好的单个候选程序。整个迭代通常仅需 5 轮即可收敛。

冻结 BM25 下的实验：全任务超越通用分块

为了验证表示程序自适应优化的威力，研究团队在复杂检索统一多任务基准 CRUMB 上进行了严格评测。CRUMB 包含 8 个跨越不同领域的复杂检索任务，包括临床试验（ClinicalTrial）、代码检索（CodeRetrieval）、法律问答（LegalQA）、论文检索（PaperRetrieval）、实体集合操作（SetOpEntity）、技术社区问答（StackExchange）、定理证明检索（TheoremRetrieval）以及根据线索寻物的隐式检索（TipOfTongue）。这些任务对长文档理解、多跳证据搜集以及结构化要素极其敏感。

实验中，检索器完全固定为 Lucene 实现的 BM25，代码生成骨干模型对比了 Claude Sonnet 4.6 与开源的 qwen3-coder。

在与传统 BM25 全文基准的对比中，经过 AutoIndex 优化的表示程序在 8 个任务上实现了全线正增长。在使用 qwen3-coder 的设定下，8 个数据集的 Recall@100 平均取得了 +8.4% 的相对提升。增幅最显著的三个任务是 TheoremRetrieval（+30.5%）、SetOpEntity（+19.2%）和 LegalQA（+10.4%）。在这些专业领域任务中，原始文档的词汇与用户提问存在严重的词汇不匹配（Vocabulary Mismatch），全文字符串使得关键信息的词频被长尾内容稀释，而经过程序重构后，BM25 展现出了远超预期的检索潜力。

更值得关注的是未被直接优化的排序指标。尽管 AutoIndex 在验证集上唯一的筛选依据是 Recall@100，但测试集上的排序质量指标 nDCG@10 同样迎来了爆发式同步增长，全任务平均提升达 +8.3%。其中，LegalQA 的 nDCG@10 暴增 +43.6%，CodeRetrieval 提升 +42.5%，TheoremRetrieval 提升 +27.3%。这有力地证明了 AutoIndex 并未通过盲目扩充索引体积、增加假阳性匹配来“刷高”召回率，而是真正重构出了信息密度更高、更能与查询意图对齐的有效文本单元。

与此同时，研究团队将 AutoIndex 与业界最常用的基准方案——固定 512 词元并保留标题的通用滑动分块（Passage-corpus）进行了对比。结果显示，固定大小的均一分块在面对异构任务时表现极不稳定，甚至在多个任务上由于切碎了上下文，表现大幅落后于整篇文档直接索引。而 AutoIndex 相对通用切块方案的优势极为夸张：在 SetOpEntity 上 Recall@100 相对高出 +152.8%，在 TipOfTongue 上高出 +361.4%，nDCG@10 的最高领先幅度甚至突破了 400%。这一断层差距直接击碎了“分块大小选 512 就能应对大部分场景”的经验主义神话。

不仅如此，表示程序带来的结构性收益还展现出了跨检索模型的迁移能力。在针对 StackExchange 的补充迁移测试中，研究人员将 AutoIndex 针对 BM25 优化出的表示程序直接应用给稠密向量检索模型 Qwen3-Embedding-0.6B。在完全没有针对向量空间重新搜索代码的情况下，该测试集上的 Recall@100 直接从 0.7391 攀升至 0.8741，取得了 +18.3% 的相对增幅。这说明高质量的代码重组并非针对特定词频公式的投机取巧，而是发掘了文本本身的语义结构。

智能体到底写出了什么样的索引代码？

AutoIndex 生成的程序并不是简单的正则替换，而是针对语料库特征自适应演化出的领域特定数据管道。论文中的具体案例生动展示了代码智能体的优化逻辑。

AutoIndex 处理 StackExchange LaTeX 代码示例

在上图展示的 StackExchange 技术问答案例中，原始文章中夹杂着密集的行内 LaTeX 数学公式。基准 BM25 在检索时，Top-3 结果全被公式片段中高频出现的非相关数学概念占据，导致真正解答定价机制的目标段落被排挤出局。

在第一轮迭代中，分析智能体迅速定位了这一模式，并在诊断报告中明确指出：反复出现的行内 LaTeX 符号不仅膨胀了文档长度，还严重干扰了核心术语的逆文档频率（IDF）计算。随后，代码智能体生成了一段带有阈值门控的预处理逻辑（strip_latex），精准剔除了无助于关键词匹配的复杂排版源码。文档切块大小从 1,847 tokens 骤降至 1,102 tokens。这一纯代码层面的变换瞬间逆转了检索排序，使得与定价相关的专业解答直接跃升至第一位，一举修复了该查询下的召回与精排指标。

另一个极具启发性的案例来自隐式影视情节检索任务 TipOfTongue。该数据集的特点是用户常常给出一段具体的场景细节描述，期望检索出对应的维基百科条目。然而，维基条目的开篇通常是高度概括的抽象介绍，二者在词汇层面的重合度极低。AutoIndex 的代码智能体在多次迭代后，写出了一种差异化加权策略：它在解析文档时识别出“剧情梗概（Plot）”与“演员阵容（Cast）”章节，对这些叙事细节更丰富的区域进行局部词频重加权，同时在整体单元中保留全文全局上下文。这种方式既避免了单纯截断剧情造成的上下文丢失，又放大了关键叙事词汇的检索可见度，最终在不引入外部大模型幻觉的前提下大幅推高了召回上限。

机制消融：为什么单轮重写或无分析不行？

为了探究 AutoIndex 各模块的必要性，作者在消融实验中对比了以下几个变体：

消融结果清晰地表明：受控且有具体失败案例支撑的搜索，才是程序合成驱动检索优化的关键所在。

重新审视 RAG 与检索系统的数据基础设施

长期以来，AI 社区习惯于将工程复杂性转移给更大的模型——检索不准就换 70B 重排器，召回不够就搞多跳 Agent 规划。AutoIndex 提供了一种反潮流却极其务实的思路：把算力花在离线的“数据表示构建期”，用代码将低成本检索器的潜力榨取到极致。

这种方法在工程落地层面具备三个无可比拟的优势。其一是极致的推理效率与成本节约。AutoIndex 在搜索完成后，产出的本质上就是一段纯 Python 数据处理脚本，在生产环境上线时零推理开销，毫秒级响应的轻量 BM25 即可承载此前需要复杂管线才能完成的召回任务。其二是高可解释性与确定性。与黑盒模型生成的文档重写内容不同，Python 代码的每一行逻辑都是白盒可见、可审计且可回滚的，工程师能确切知道文档为什么被这样切分和组织。其三是算法正交性。优化文档表示与后续叠加更高级的 Dense Retriever 或 Reranker 完全不冲突，前期实验已证明，优秀的数据表示程序同样能使向量模型受益。

当然，该框架仍处于演进的早期阶段。当前研究主要将 BM25 的 Recall@100 作为唯一搜索反馈，未来如何在代码搜索目标中联合权衡索引体积（Index Footprint）、内存延迟、多路召回指标，以及如何实现跨数据集的“程序迁移（Program Transfer）”，依然是值得探索的方向。

但 AutoIndex 已经明确传达了一个信号：在盲目上马更重型的检索模型之前，先用智能体为你的语料库编写一套专属的文档表示程序，或许才是提升系统性能性价比最高的切入点。

上一篇 GMA：评测8大前沿模型，真实手机工作流成功率为何全线跌破20%？ 2026-09-17 下一篇 AutoDesign：不是微调模型而是迭代脚手架，得分超Claude Design 7.4分 2026-09-17