OceanBase DataPilot 获 Hugging Face DABstep 最高分！

编者按

OceanBase DataPilot 在被誉为“数据智能时代新基准”的 HuggingFace DABstep 基准测试 Hard 级别中获得全球最高分，并已连续 1 个月大幅领先第二名，位居全球第一。该⼯具旨在评估最先进的语⾔模型和 AI 代理在多步骤推理中的能⼒，特别是在数据分析领域的表现。

引言：当“更聪明的 Prompt”不再奏效

当今世界数据无处不在，而数据科学一直被视为人类智能的重要体现。在大型语言模型（LLM）的应用探索中，数据分析一直被视为重要方向。

然而，当开发者试图将 Text-to-SQL 或简单的 Python Agent 投入真实的金融、风控或运维场景时，往往会撞上一堵无形的墙：模型似乎“听懂”了，但分析出来的数据总是不对；脚本在测试集跑通了，上线面对脏数据却频繁崩溃；复杂的业务口径在不同轮次的对话中发生漂移。

所以，一家来自荷兰的支付解决方案提供商 Adyen 与全球著名 AI 社区 Hugging Face 才会一起联手，想搞清楚 AI 到底能不能胜任这份工作。

2025年2月，他们联合发布了一个 DABstep（Data Agent Benchmark for Multi-step Reasoning）基准测试，将这一矛盾摆在了台面上，即便是 o3-mini、DeepSeek-R1 这样的顶尖推理模型，在 Hard 模式下的准确率也仅在 13%-16% 徘徊。

它的难主要体现在三个极度真实的方面：

首先，DABstep 的问题是高度真实的。在测试里包含了 450+ 真实业务任务，全部来自于 Adyen 内部真实的金融业务场景。比如欺诈风险分析，支付费率计算。这些都不是研究人员凭空想象出来的简单问题，而是反映了分析师每天面临的挑战；

第二是数据环境的真实性。DABstep 包含结构化和非结构化数据，分别用于衡量领域知识和技术技能。其中，结构化数据包括 CSV 和 JSON 文件，代表真实世界的数据，如交易记录和业务元数据；非结构化数据包括文档、手册和详细指南等。这些任务需要高级数据分析技能，以处理结构化数据和理解多个数据集及文档中的非结构化数据。

最后是解决路径的真实性。DABstep 的问题无法通过单一代码片段解决，而是需要多步骤的迭代推理。AI 必须像一个真正的人类分析师一样，先做探索性分析，然后分步骤迭代的去解决问题。例如，代理至少需要知道数据集中有哪些列才能回答问题。

DABstep 基准测试分为 2 个难度级别：

⭐简单级别：作为热身任务，帮助验证设置、集成和研究⽅向。通常只需要⼀个结构化数据集和少量背景知识。⼈类在经过 3 小时以上的工作后平均能达到 62% 的基线准确率，⽽ Llama 70B 零样本提示可以超过 90% 的准确率。

⭐困难级别：需要更复杂的方法，涉及多个结构化数据集和领域特定知识。这些问题通常无法通过单⼀代码生成解决，而是需要多步骤推理。

DataPilot 是 OceanBase 推出的智能问数与洞察平台：支持快速搭建分析域、自动化语义层配置与指标管理；提供自然语言驱动的问答式分析，输出可解释的 SQL/推理过程与统计结论；内置细粒度数据权限与审计能力，确保数据安全合规。近期，DataPilot 在 DABstep Hard 级别的全球基准测试中获得最高分，并已连续 1 个月大幅领先第二名，位居全球第一。

DABstep 全球实时榜单：https://huggingface.co/spaces/adyen/DABstep

我们可以看到，DABstep 榜单上有很多参与者，为什么 OceanBase DataPilot 能拿到最高分？答案不在于 OceanBase 用了更强的模型，而在于建立了一套能够持续积累和复用的知识体系。

OceanBase DataPilot 的做法是：通过测试集和专业数据分析师构建的 success story 样本，以及必要的人工纠偏和引导，在这套框架下沉淀了能够比较稳定解答问题的数据理解、必要业务规则、公式指标、代码规范。基于这些构建的上下文，智能体能够在测试集上稳定回答推理问题，并且充分发挥 LLM 的能力，触类旁通解决相似问题，实现一定的外推泛化性能。

数据分析的“真实之痛”

数据分析从来不是简单的“写代码”或“画图表”。在 DABstep 揭示的真实场景中，分析师通常面临着三重典型问题：

第一重约束是口径歧义。

文档可能会说“国内交易费率更低”，但数据表里有 issuer_country
（发卡国）、acquirer_country
（收单国）、ip_country
（IP归属地）等多个字段。到底哪两个字段匹配才算“国内”？模型往往靠直觉“猜”，导致在部分样本上正确，部分样本上谬误。这种歧义在真实业务中比比皆是，而模型缺乏明确的业务规则，只能在黑暗中摸索。

第二重约束是数据脏乱。

真实数据中，空值可能是 null
、None
，也可能是空数组 []
。普通的 Python 脚本在面对这些“非标”数据时，往往不是算错，而是直接抛出异常崩溃。

第三重约束是性能与资源受限。

即使逻辑正确，一个 O(R * T)
（R=规则数量，T=交易数量）的双重循环在面对百万级交易流水时也可能直接超时。在 DABstep 或真实业务中，“跑得太慢”等同于“不可用”。

OceanBase 是如何设计 Data Agent 的？

核心理念：从“临时对话”到“版本化资产”

想象一下，你在和 AI 聊天时，它每次都要重新理解“国内交易是什么意思”“空值该怎么处理”。这就像每天上班都要重新培训新员工，效率极低。普通的 RAG（检索增强生成）系统往往将上下文视为临时的、用完即弃的对话内容。OceanBase DataPilot 的思路是把知识变成可以长期保存、反复使用的“资产”。

具体来说，系统做了三件事。

第一，把上下文当成资产而不是临时对话内容，将 AI 需要的知识拆成三层，分别管理、分别迭代；

第二，把每次做题变成一次小型训练，用“样例题解过程 + 标准答案”做自动回归，持续修正并沉淀经验；

第三，把稳定交付当成产品目标，不仅要算对，还要能跑完、跑得快、不会因为脏数据频繁崩溃。

这张架构图把 DataPilot 的“资产化闭环”落到可执行模块上：上层 ReACT Agent 作为构建态与运行态的统一入口，用工具与沙箱执行驱动数据洞察，必要时调用子智能体生成多版本假设实现。

中层 Workflow 把对话结论、口径、工具与 SOP 结构化生成资源，并统一打上 Subject Tree Hypothesis Tag Resource Version。下层 seekdb 负责混合检索与版本化管理，既能按标签精确召回，也能按语义 query 组合上下文。Benchmark 则把不同 Hypothesis Tag 当作可对照实验分组：同一任务流程下仅切换检索标签，批量评测并输出分支分数，从而选择最优分支上下文沉淀为主干默认版本。

整套系统分为两部分。资产平面存放可检索、可版本化的知识与能力，相当于长期记忆；运行平面把这些资产组装成一次可执行的分析作业，负责当次执行。打个比方，资产平面就像一个知识库和工具箱，里面装着各种标准操作手册、代码模板、历史经验；运行平面就像一个装配车间，根据当前任务从工具箱里挑选合适的工具组装起来干活。

在资产平面“知识”又被分成三层。

把“知识”分层的原因很简单：不同类型的知识，生命周期、复用方式、验证方式完全不同。混在一起会很难维护。

第一层是数据事实层（Data Surface），回答最基础的问题：数据到底长什么样？字段是什么类型？有多少空值？可能的取值范围是什么？这一层的产物是字段字典、数据画像（缺失率、值域）、易错点提醒。

比如，明确告诉 Agent：“这个叫 Country 的字段，虽然名字像国家，但实际存的全是 IP 地址。”这样的信息看似简单，但对避免误判至关重要。

第二层是语义口径层（Semantic Lens），回答业务定义问题：业务到底怎么算？什么叫“月交易量”？是按金额还是笔数？是自然月还是滚动窗口？“欺诈率”怎么算？按金额还是按笔数？边界值如何判定？输出需要保留几位小数？空列表用什么语义表达？这一层的产物是术语卡、指标卡、粒度约束。比如，固化一条规则：“国内交易 = 发卡国和收单国相同，不看 IP 国家。”这样的规则一旦确定，就不再允许歧义和漂移。

第三层是可执行作业层（Procedure Pack），负责怎么稳定做出来。

这一层是最硬核的部分，包含能处理脏数据、能在资源限制下跑完、能一键回归的代码。这里不仅要算对，还要能处理脏数据（不崩溃）、能在资源限制下跑完（性能可控）、能一键回归（证明没有退化）。

产物包括可复用工具、端到端作业脚本、验证器/回归集、多个实现变体。比如，一个通用工具：“安全的成员判断函数 safe_in
，处理空值、空数组、None 等各种边界情况。”这是最硬核的资产，包含了处理脏数据和性能优化的代码结晶。

从工程实现角度看，分层让检索与装配更直接：资产可以用结构化元数据进行治理与过滤，用全文做关键词召回，用向量做语义召回；必要时再对候选做轻量重排。运行态通常可以先用硬条件缩小范围，再用混合召回拉出候选资产组合，最后按适用条件与成本画像完成选择与装配。

GRPO 理念的上下文构建：Train-Free 的资产迭代

OceanBase DataPilot 借鉴了 GRPO（Group Relative Policy Optimization）的思想，将其应用于“上下文资产”而非“模型参数”的优化。

这是一种 Train-Free 的迭代方式，每一轮同时产出多个候选改动，用回归分数做相对比较，再选择最优候选写回。

训练信号来自两个方向。Success Story（样例题解过程）给你“方向线索”，告诉你哪些字段关键、哪些边界会翻转答案、哪些解释方式可沉淀为口径条目。Golden Answer（标准答案）给你“裁判尺度”，衡量你的改动有没有让一批样本更对齐，并且这个对齐是可以被机器验证的。

迭代闭环可以概括为“分支生成—标签化对照评测—主干沉淀”。

在生成阶段，ReACT Agent 在推理或人机交互中识别歧义点/未知点，将其显式化为占位符分叉，并由 ReCodeReasoningAgent（或其他子智能体）产出多套候选实现与上下文变体；这些候选以 Subject Tree Hypothesis Tag Resource Version 的形式被结构化写入 seekdb，形成可检索、可组合的分支版本。

随后进入对照评测阶段，Benchmark 接收一组待检验的 Hypothesis Tag 列表，对每个标签执行完全一致的任务流程与回归样本，只在上下文召回时透传对应 Tag 做混合检索，从而得到“同题同流程、仅上下文假设不同”的可比实验结果，并为每个分支输出可解释的分数与证据报告。

最后进入沉淀阶段，系统依据评测成绩与多目标权衡（正确性/稳健性/成本）选取最优假设分支，将其对应的资源集合提升为默认主干，其余分支保留为可追溯但不生效的候选，以便后续复测与回滚。

三个典型进化闭环案例

整套方法可分为三个典型闭环，对应前面三重典型问题的解决，分别代表了口径歧义、脚本崩溃和性能瓶颈。

逻辑闭环：解决“口径歧义”—— 让 AI 知道“国内交易”到底怎么算

例如一个数据表里有三个“国家”字段：发卡国、收单国、IP 国家，AI 每次都在猜“国内”到底指哪两个字段匹配。解决过程是这样的：系统生成三个候选定义（H1/H2/H3），分别对应不同的字段组合，然后用标准答案批量测试，看哪个定义的准确率最高。把最优定义写入“语义口径层”作为强制规则，再把判定逻辑封装成工具函数，所有脚本必须调用。结果是以后遇到“国内交易”，AI 不再猜测，而是直接查询已确定的口径定义。这个案例的核心在于把歧义消除，将隐性的业务规则显性化、资产化。

健壮性闭环：解决“脚本崩溃”—— 让代码能处理各种脏数据

在真实业务的数据中，空值可能是 null、None、空数组 []，普通代码遇到就崩溃。

解决过程包括四个步骤：

收集所有崩溃日志并按错误类型分类，提取最小复现样本写成回归测试用例，开发通用的安全判断函数 safe_in统一处理各种空值情况，把这个函数写入工具库并强制所有脚本使用。以后写代码时，不用每次都想“空值怎么办”，直接调用标准工具即可。这个例子把健壮性经验沉淀为可复用的工具，避免同类错误反复出现。

效率闭环：解决“性能瓶颈”—— 让慢代码跑得快

假设有一个“规则匹配交易”的任务，因为嵌套循环（规则数 × 交易数），在百万级数据上超时。解决方法是先识别热点，发现主要耗时在双重循环；然后生成优化方案，先把交易按特征聚合减少匹配次数；接着验证优化，用标准答案确认结果一致，用性能测试确认确实更快；最后把优化版本作为新变体保存，标注适用条件（大数据量时使用）。当以后遇到同类任务，系统会优先选择高性能版本，自动规避性能陷阱。该例子可以把性能优化也变成可复用的资产，而不是每次都重新优化。

以上三个案例揭示了 OceanBase 方案的本质：不是让 LLM 每次都从零开始推理，而是通过资产化的方式，把“数据长什么样”（Data Surface）、“业务怎么算”（Semantic Lens）、“代码怎么写”（Procedure Pack）这三层知识固化下来。当遇到新问题时，系统先从资产库中检索相关知识，然后基于这些知识构建上下文，让 LLM 在一个“有记忆”的环境中推理。

更重要的是，这套体系具备泛化能力。虽然初始的资产是通过测试集和 success story 构建的，但一旦建立起来，系统就能触类旁通。

比如，学会了处理“国内交易”的口径歧义后，遇到类似的“跨境交易”“本地货币”等概念时，系统能够复用同样的消歧方法。学会了 safe_in
函数后，遇到其他类型的边界情况（如除零、类型转换），也能用类似的思路去抽象和沉淀。学会了特征聚合优化后，遇到其他双重循环的性能瓶颈，也能快速识别并应用类似的优化策略。

这就是为什么 OceanBase DataPilot 能在 DABstep 上拿到最高分的原因。不是因为模型更聪明，而是因为建立了一套让模型“变聪明”的机制。

这套机制通过三层资产管理，将隐性的推理能力显性化；通过 success story 和 golden answer，将一次性的成功经验持久化；通过混合搜索和事务写回，将碎片化的知识系统化。最终，系统不再是“做对一次题”，而是“学会一类题”。

让“存 + 找 + 写回”构建顺滑的闭环

值得注意的是，这套方法论要成立，有一个常被低估的前提：“长期资产”必须既能被稳定治理，又能被高质量检索，还能被安全写回。

如果这些能力分散在多个组件里（例如元数据一套、文档一套、向量索引一套），系统很容易在工程上变得很脆。改动写回时可能出现“部分成功”的情况，比如索引更新了但内容没更新，或者内容更新了但索引没更新。检索装配需要在应用层拼接多路召回与重排，结果不可控也难以回归。证据链散落在日志和文件里，难以追溯、难以长期复用。

为了让上面的闭环在工程上足够顺滑，资产库需要把“治理、检索、写回”三类能力稳定地提供出来。这就引出了一个关键问题：DABstep 这样的负载，本质上在考验数据库的什么能力？

OceanBase 为什么天然适合 AI Agent 负载

多模一体

传统的数据架构往往是“拼接”的，用 MySQL 处理交易，用 ES 存文档，用 Milvus 存向量，中间再挂一个 Redis 做缓存。这种架构在 AI Agent 场景下存在致命问题。一方面是割裂的上下文，Agent 需要频繁查询事实（Schema）、查阅口径（文档）、检索历史代码（向量），跨系统的每一次跳转都意味着延迟、网络抖动和潜在的一致性错误。另一方面是难以回溯的状态，当 Agent 犯错时，你很难复现是因为向量库索引没更新，还是数据库里的元数据变了。

OceanBase 采用一体化架构（TP + AP + AI），在一个引擎内同时承载结构化元数据、全文文档、向量语义索引与 JSON 。这意味着“上下文构建”发生在一个统一的数据平面内，数据的一致性和交互的原子性得到了物理级别的保障。

混合搜索

在 OceanBase 的方案中，混合搜索不再是锦上添花的功能，而是 Agent 工程的基石。

DABstep 的任务往往隐含着复杂的查询需求，比如“在距离五百米以内（空间查询），人均消费 25 元以下（关系过滤），评价 4.5 分以上且‘不用排队’（向量语义）的咖啡厅”这样的组合条件。

对于 Agent 而言，构建一次精准的上下文就是一次混合搜索的过程。找事实时利用关系数据库能力，快速获取表结构、字段统计信息；找口径时利用全文检索关键字；找经验时利用向量检索，召回历史上处理过类似的代码片段。

OceanBase 将这些能力融合在同一套 SQL 引擎中，用户（或 Agent）只需一条 SQL 即可完成“语义 + 关键词 + 标量”的混合筛选，无需在应用层进行复杂的归并排序。这种“Data In, Data Out”的能力，让 Agent 能够以毫秒级速度，在一次执行中同时完成“查数据 + 查语义 + 查能力 + 跑作业”，从而保证了系统“算对、跑完、跑稳”。

事务写回

在 Agent 的迭代过程中，每次“学到的经验”都需要写回到资产库。但这个写回过程涉及多个维度：更新注册表（标记哪些口径、工具被更新）、内容落库（新的口径定义、代码片段）、证据链记录（回归测试报告、性能基准）。如果这三个操作不在同一个事务里，就可能出现“部分成功”的脏状态，比如注册表说“口径已更新”，但实际内容还是老的。

OceanBase 事务能力确保了这一点，把涉及的“注册表更新 + 内容落库 + 证据链记录”作为一次原子操作提交。要么全部成功并可追溯，要么全部回滚不污染长期记忆。从工程角度看，这意味着写回时不会出现“索引更新了但内容没更新”的不一致状态，回滚时能完整恢复到上一个稳定版本，证据链（如回归测试结果）与资产内容强绑定，可追溯、可审计。这是保证资产质量的关键机制。

可嵌入也可服务

以 OceanBase seekdb 为例，可支持两种部署模式，满足不同阶段的需求。在构建态（训练/迭代阶段），OceanBase seekdb 可以作为轻量级嵌入式数据库直接在开发环境中运行，快速响应资产的增删改查，加速迭代周期。在运行态（生产环境），OceanBase seekdb 可以作为独立的数据服务部署，承载高并发的查询请求，支持多个 Agent 实例并发访问资产库。这种灵活性让团队可以在“快速迭代”和“稳定服务”之间自由切换，无需重新设计架构。

从“榜单”到可落地的“技术路径”

在 AI Agent 走向深水区的今天，Hugging Face 发布的 DABstep 榜单揭示了一个真实的现实：即便拥有最强推理能力的 LLM，在面对真实复杂的业务数据分析时，准确率也往往不尽如人意。

然而，OceanBase 凭借“数据底座 + Agent 工程化”的方法论成功登顶。OceanBase DataPilot 在 DABstep Hard 难度中拿到最高分，其意义远超一个榜单的排名。它证明了真正能支撑 AI 走向生产的，不是更聪明的提示词，而是通过数据底座的一体化能力解决上下文碎片化难题，将 Agent 的推理过程转化为可持久化、可回归、可迭代的资产体系。

该体系的关键在于三个技术决策。

第一，是用数据库而非文件系统管理资产，利用事务、索引、查询优化器等成熟能力，避免重复造轮子。

第二，是用回归测试而非人工评估驱动迭代，通过自动化的 pass/fail 判定和相对比较（A/B testing），减少主观性和人工成本。

第三是用混合搜索而非单一检索方式构建上下文，结合关系过滤（精确匹配）、全文召回（关键词）、向量召回（语义），在召回率和准确率之间找到工程平衡点。

在这个体系中，混合搜索所体现的价值远不止是加速检索，更是提升推理质量的基础设施。在数据分析场景中，Agent 需要从三个维度构建上下文：事实维度（schema、statistics、data profile）通过关系查询获取，口径维度（business rules、metric definitions）通过全文检索定位，经验维度（code snippets、procedures、best practices）通过向量检索召回。

这三类信息的粒度、分布、召回策略完全不同，通过混合搜索可以高效组装。更重要的是，混合搜索的结果是确定性的，给定相同的查询和资产版本，返回的上下文是可复现的，这是实现回归测试和版本控制的前提。

未来，OceanBase 会将文中所述的完整 Data Agent 能力集成进 DataPilot 新版本中，包括资产管理（Data Surface、Semantic Lens、Procedure Pack）、混合搜索引擎（关系 + 全文 + 向量）、自动化回归系统（regression runner + commit gate），实现更加坚实可靠的智能问数产品，敬请期待！

‍

想了解更多行业资讯

扫码关注👇