AutoIndex: 学习检索的表征程序

TL;DR AutoIndex 将文档前处理抽象为可执行程序的搜索问题，通过 agent 自动合成切片、丰富、重加权等转换，在固定 BM25 下显著提升检索质量：平均 Recall@100 提高 8.4%，最大提升 30.5%。

问题

问题背景

信息检索系统通常将原始文档转化为索引表示，以便快速匹配查询。当前优化焦点多集中在检索模型、重排序模型或 embedding 质量上，而文档表示(document representation)的设计——如何分块、加权、重组或清洗——往往被视为固定的预处理步骤，缺乏系统化的优化。

现有方法局限

多数检索流水线依赖人工设计的文档预处理规则，例如：

• 固定长度分块：按固定 token 数切割，忽略文档内部结构与语义边界，可能切断关键上下文或引入冗余。
• 启发式片段选择：基于标题、首段等简单规则提取部分内容，无法适应异构检索任务（如代码、问答、事实核查）的多样需求。
• 单一增强策略：手动添加元数据或摘要，覆盖范围有限，且无法针对查询失败模式动态调整。

这些方法将文档表示视为一次性工程决策，而非持续可优化的目标，导致索引信息密度不足或噪声过大，直接限制了 BM25 等稀疏检索器的召回上限。已有工作如自适应分块和索引丰富化仅解决局部问题，缺乏统一的程序合成框架来搜索最优的文档变换组合。

为什么这个问题难且重要

文档表示程序的空间巨大，可选的变换操作（切片、加权、正则化、重组等）与组合方式呈指数增长，人工穷举试错不可行。同时，检索质量对下游任务（如 RAG、问答）有级联影响，一个糟糕的索引可能让后续所有组件失效。技术上，挑战在于如何利用有限的验证查询自动搜索出能泛化的表示程序，并在迭代中诊断失败原因并修复。随着大型语言模型被广泛用于检索增强生成，减少对昂贵 API 重排序的依赖、直接提升第一阶段检索效果变得尤为关键。AutoIndex 将表示程序学习视为一个生成式搜索问题，为文档预处理引入自动化优化范式，使非专家也能获得适配其数据的定制索引。

行业类比

如同 AutoML 将模型结构搜索自动化，AutoIndex 让索引结构的程序化优化成为可能，在 RAG 或企业搜索场景中，无需手动调参即可显著提升检索质量，降低工程维护成本。

核心洞察

• 文档表示本身应作为与检索模型解耦的显式优化目标，而非一次性预处理。AutoIndex 将原始文档变换为可执行的表示程序，通过切片、富化、归一化、重加权等方式自动搜索最优表示，这与传统固定分块或静态元数据增强有本质区别——后者调整空间极小且需大量人工干预，而 AutoIndex 将表示空间拓展至图灵完备的程序变换，使 BM25 等简单检索器也能适配异构任务。
• 采用验证引导的智能体程序搜索，将分析 agent 的诊断与代码 agent 的修改闭环耦合。分析 agent 定位当前表示程序的失败模式，代码 agent 生成候选修正程序，仅当验证指标提升时才保留更新。这种迭代式、面向失败驱动的程序优化范式，有别于现有的一次性提示工程或超参数调优，能在少量迭代中自动发现任务特异性的表示策略，实现平均 +8.4% Recall@100 的稳定增益，极端任务提升超 30%。

方法

AutoIndex 将文档表示建模为可执行的表示程序（representation program），以原始文档为输入，通过程序转换输出用于检索的索引表示。其核心流程遵循“输入 → 迭代搜索 → 输出优化程序”的闭环。

输入与设定

• 原始文档集与训练/验证查询（固定 BM25 为检索器，不调参）
• 初始表示程序：通常为简单的全文索引（full-document indexing）

关键模块：验证引导的程序搜索

每轮迭代执行以下步骤：

1. 分析代理（Analysis Agent）
   基于当前程序构建索引并检索，针对验证查询的失败案例（如相关文档未召回）进行诊断。它输出自然语言描述的问题定位，例如“文档中的关键信息分散在多个段落，单段切片丢失上下文”。

2. 代码代理（Code Agent）
   接收分析报告，生成改进的表示程序代码。代码可执行多种转换：

   • 切片：将文档按语义边界切分成多个块（chunks），并可选地合并相邻块提供上下文
   • 富化：提取并附加元数据（如标题、作者、实体）
   • 规范化：处理大小写、缩写、日期格式
   • 重加权：对特定字段（如标题）赋予更高 BM25 权重
   • 重组：改变文档或字段的索引顺序 代码代理输出完整的 Python 程序，定义 represent(doc) -> List[Field] 接口。

3. 程序选择（Program Selection）
   执行候选程序并重建索引，在验证集上计算检索指标（如 nDCG@10）。仅保留指标提升的更新，并作为下一轮的基线。迭代持续到收敛或预算耗尽。

输出

最终学习到的表示程序，可直接应用于新文档的预处理，无需人工干预。它本质上是一个符号化、可解释的转换管道。

区别于传统调参式优化（如调整 chunk size、检索超参），AutoIndex 将表示空间本身作为搜索对象，通过 LLM 代理自动发现组合式文档转换策略，突破固定预处理流程的限制。

实验

实验设计

AutoIndex 在 CRUMB 基准上评估，该基准包含 8 个异构检索任务。所有实验均固定使用 BM25 检索器，不进行任何微调。每轮迭代中，Analysis Agent 诊断当前文档表示程序的失败案例，Code Agent 生成候选更新，仅保留在验证集上提升检索质量的程序。比较对象包括静态全文档索引基线、均匀分块基线及初步的稠密检索实验。

关键发现

所学得的表示程序在所有 8 个任务上均优于全文档 BM25 基线，平均 Recall@100 提升 8.4%，nDCG@10 提升 8.3%，个别任务上 Recall@100 提升高达 30.5%，nDCG@10 提升达 43.6%。迭代搜索过程比单轮生成有效，分析反馈对程序改进至关重要。表示程序通过切片、富化、重加权等操作自适应地重构文档，验证了“文档表示应作为优化目标”这一核心论点。

与基线对比解读

相较于调整检索器或重排序模型，AutoIndex 在不改动 BM25 的条件下仅通过优化表示即可取得显著增益，表明数据预处理与表示策略本身具有巨大的提升空间。与均匀分块基线对比，自适应程序能根据查询类型动态调整粒度，更灵活地平衡召回与精度。该工作将程序合成引入检索流程，为工程实践提供了新视角：索引前的文档转换可被形式化为可搜索的程序空间，随业务需求演变而持续优化。

行业影响

落地场景

AutoIndex 为依赖检索管线的 AI 产品提供了一种自动优化文档表示的手段，适用于 RAG（检索增强生成）、企业搜索、电商搜索、代码库检索、法律/医疗文档检索等场景。其核心价值在于，当业务数据异构或预定义的分块/预处理规则失效时，框架能通过程序合成发现比人工设计更优的文档切分与增强策略，从而提升下游任务质量。

商业价值

• 降本：消除对专家手工调优检索预处理流水线的强依赖，减少 A/B 测试与启发式规则维护的人力投入。
• 增效与体验提升：在保持 BM25 这类低成本检索器不变的情况下，仅优化表示即可获得平均 +8.4% Recall@100，直接提升搜索/问答系统的准确率与用户满意度。对于长尾查询、跨领域数据等难以统一处理的场景，自适应的表示学习能显著降低检索失败率，进而改善转化率与留存。

与现有产品/工作流的接口

AutoIndex 可作为索引前置的可编程预处理模块集成进现有检索栈，无需更换检索引擎或重训模型：

1. 索引阶段：在文档写入 Elasticsearch、Vespa 或 OpenSearch 之前，通过 AutoIndex 生成的程序对原始文档进行变换（切片、字段合并、元数据注入、去噪等），产出自定义的 analyzer 或 ingest pipeline 配置。
2. 查询阶段：可保持原有查询处理不变，仅修改索引端表示。降低接入风险，且与现有精排/重排模块兼容。

具体落地用例

• 电商搜索：商品描述多为富文本，包含规格、文案、评论摘要等。AutoIndex 可自动发现“提取规格表 + 拼接前三条评论”的表示程序，使 BM25 在用户搜索“轻量 4K 笔记本”时能更精准命中，即使关键词稀疏分散在不同字段中。
• 企业知识库 RAG：技术文档、政策手册、代码文档等跨域知识库常需定制分块与元数据提取规则。AutoIndex 可对每种文档类型学习专用的表示程序，动态生成对齐查询意图的块表示，减少人工梳理文档模板的成本，同时提升 RAG 生成的回答可信度。

局限

• **检索器依赖性**：AutoIndex 目前仅与 BM25 检索器绑定优化，虽然固定检索器可以凸显表示程序的效果，但程序搜索的目标直接取决于 BM25 的评分机制（例如词频、IDF）。这意味着学习到的表示程序可能无法泛化到其他检索模型（如稠密检索、学习型稀疏检索），在更现代的检索架构中可能收益有限。论文虽提供了初步稠密检索实验，但未系统探索跨检索器的可迁移性，这限制了其作为通用表示学习框架的说服力。
• **计算与迭代成本**：每轮迭代都需要分析代理诊断失败案例、代码代理生成候选程序，并重建索引进行验证，LLM 调用和索引构建开销显著。虽然**分析代理与代码代理分离**的设计提高了程序成功率，但随着搜索空间扩大或查询数量增加，实际应用中的计算预算可能难以承受。此外，论文使用**策划好的候选查询**进行验证，这可能减少搜索难度，但在真实动态查询流下的表现仍有待验证。
• **可解释性与工程健壮性**：生成的表示程序本质上是 LLM 合成的 Python 代码，尽管它们切片、丰富、归一化文档，但程序逻辑往往难以人工理解与调试，可能引入不希望的副作用（例如错误删除关键信息或过度加权噪声）。AutoIndex 也未考虑跨文档关系（如主题聚类、链接分析），将文档表示孤立地处理，与一些联合优化文档编码和检索器的端到端方法相比，表示能力存在天然上限。