DBRAG用表索引加相关行重排，在Spider上把多表检索Recall@5提到95.8并改善多表问答
核心概要
DBRAG把多表问答拆成两阶段：先用离线表索引粗排候选表，再用查询相关行替换摘要中的随机行并由LLM重排，随后由程序辅助的思维链推理器选表并在完整表上执行操作；在Spider、GeoQuery、ATIS上，该框架在表检索与多表问答指标上均优于所比较的基线。
Figure 1: The DBRAG execution workflow. The Table Index retrieves top- K K candidates; the Row Index supplies query-relevant context rows. An LLM reranks the candidates to select top- M M tables. These tables are then passed to a program-aided reasoner, which uses a multi-table CoT prompt to generate the final answer.
arXiv深度剖析
DBRAG将多表问答显式分解为多表检索与多表推理两个子任务，检索端采用表索引粗排加LLM细排的两阶段策略，推理端采用多表感知的思维链提示配合程序化执行工具。 既有工作多针对单表场景，或假定相关表已由外部提供；DBRAG面向需要从整个数据库语料中自行找出相关表的开放域设定。 论文给出问题形式化定义、两项需求（R1检索多样性、R2推理器上下文规模）以及各组件与提示模板的完整描述，方法可复现。
在Spider检索评测中，使用相关行上下文的DBRAG取得最高平均Recall@5（95.8），高于JAR（Coarse-rank）的93.0、Coarse-rank的89.5、DTR的83.0与Contriever的80.6。 消融显示去掉行信息（仅表名与模式，83.7）或改用随机行（94.9）都会下降，说明查询相关行而非任意行是提升来源。 Spider测试集985条样本，按1至4表查询分组报告；4表组仅6条查询，作者已注明该组样本量小。
重排所用LLM会影响检索表现：GPT-3.5（Turbo-0125）平均95.8，Llama 3.3（70B-Instruct）92.5，Qwen2.5（32B-Instruct）90.8，差距在需要更多表的复杂查询上更明显。 该对比在固定检索设置下进行，说明细粒度重排对模型推理能力有依赖，而非仅由索引结构决定。 同一Spider数据集、同一默认参数下的三模型对比，按查询所需表数分层报告。
端到端多表推理中，DBRAG在Spider、GeoQ、ATIS多数指标上优于MTQA与ReadTable，尤其在Spider上ReadTable因表超出上下文长度而大量失败。 DBRAG用紧凑摘要指导选表与操作构造，执行工具仍访问完整检索表，因此上下文行选择不限制答案计算范围。 评测采用Table EM、Row EM、Column EM、Cell EM，并对后三者使用宏平均以降低大表查询的偏置；消融显示去掉选表步骤或替换相关行都会降低答案准确率。
启示与展望
该框架面向需要从整个数据库语料中检索相关表的多表问答场景，适用于答案可由SQL式操作获得的问题；作者指出未来工作将扩展到半结构化数据与知识图谱等异构数据集成。对使用方而言，DBRAG的价值在于把上下文预算集中在紧凑摘要上，同时让执行工具访问完整表内容，从而在表数量多、单表行数大的数据库中控制提示规模。
行索引的构建与维护在数十亿记录规模下的计算开销仍是开放问题，作者将其与动态模式更新、生产部署一并留待未来工作。评测问题虽涉及多表，但答案均可由SQL执行得到，开放式探索或趋势解释类查询尚未评估；含噪声、不一致或缺失信息的真实数据库也未纳入评测。此外，对比基线集合有限，未包含更高级的求解器。检索评测中4表查询仅6条，该分组结果需谨慎看待。