评测 on DataAgentX

改一条费率，先找准哪些交易会受影响

Thu, 22 Oct 2026 00:00:00 +0000

把一条支付费率从万分之 14 降到万分之 1，商户一个月能省多少钱？

这个问题看起来是一道乘法题，实际难点在乘法之前：哪些交易会受影响。这次用 DABstep 的两道 hard 题做复算，重点放在范围确定和独立核验。

数据与题目

DABstep 由 Adyen 与 Hugging Face 构建，考查跨表、跨文档的多步分析。这次用到 2023 年的 138,236 笔合成支付交易、1,000 条费率规则，以及商户资料、行业编码字典和业务手册。

第一题：一笔 10 欧元交易，按适用费率规则计算的平均手续费是多少？条件是账户类型 H、餐饮行业、GlobalCard。

第二题：针对指定商户 2023 年 1 月，把规则 384 的 rate 从 14 改为 1，其他条件保持不变，费用变化多少？

两题都要求先读手册，确认单位和规则含义，再做筛选与计算。

第一题：先映射条件，再逐条计算

条件里有“餐饮行业”，但数据里用的是 MCC 编码。第一步是把行业描述映射为 MCC 5812，再据此筛出适用规则。

筛出 46 条适用规则后，按每条规则分别计算：

手续费 = 固定费用 + rate × 交易金额 ÷ 10,000

对 46 个结果取算术平均，得到 0.123217 欧元。

这里必须说明一个口径问题：平均的是 46 条规则各自算出的手续费，没有按实际交易分布加权。因此它不能当成商户实际每笔平均支付的手续费，只能理解为“在该条件下，规则集合的平均费率水平”。

另外要注意单位：rate=14 表示万分之 14，即 0.14%，不是 14%。误读为 14% 会把按交易金额计算的费率部分放大 100 倍，即两个数量级；包含固定费用的总手续费不一定按同一倍数变化。

酒店数据实战：品牌榜为什么会变

Tue, 20 Oct 2026 00:00:00 +0000

酒店品牌榜上，平均 5 星的品牌为什么不一定第一？

这次用公开评测原题走一遍完整链路：数据 → 问题 → 解法 → 验收。重点不在算出答案，而在看清资格门槛和分母选择如何改变结论。

数据与题目

数据集是 InfiAgent-DABench，评测从 CSV、自然语言问题和约束出发，检验能否真正执行分析并给出结果。本次固定题单有 257 题、引用 52 份 CSV；这里只取其中的 hotel_data.csv，1,057 行、9 列，覆盖 7 个城市和 103 个非空品牌，每行是一条酒店记录。

选择的是 510、513 两道 medium 题。

510：评价数至少 100 的酒店中，哪个品牌平均星级最高？还要求品牌、星级非空，品牌在全表至少 10 家，按算术平均计算，出现并列时再看全表规模。

513：评价数与 bubble_score 的相关，在不同星级组里分别是多少？注意 bubble_score 和酒店星级不是一个字段。

两道题都设置了约束，这使它们比“算个平均值”更接近真实工作：约束决定谁有资格参与，也决定分母是什么。

解法：把 510 拆成两路

第一路在全表计算品牌规模，确定参评资格；第二路筛出有效酒店，计算星级总和与均值。最后在品牌粒度汇合。

筛选路径：

步骤	行数	说明
全表	1,057	所有酒店记录
品牌规模 ≥10 家	—	确定参评品牌
星级、品牌非空	332	具备评分所需字段
评价数 ≥100 且星级、品牌非空	296	符合酒店级条件
应用品牌规模门槛后最终参与排名	125 家 / 6 个品牌	同时满足品牌与酒店两级条件

第一名 Preferred Hotels & Resorts 在全表有 21 家，参与评分的有 19 家，星级总和 83.5，均值 83.5 ÷ 19 = 4.3947。

Data Agent 怎么做：把 23 篇内容收成一张工作地图

Sun, 04 Oct 2026 00:00:00 +0000

看过很多 Data Agent 产品，真正开始建设时，团队仍会回到几个朴素的问题：它到底替谁完成什么工作，应该使用哪些数据，怎样安全执行，如何证明结果可靠，失败后谁负责。

这五个问题比厂商名单更耐用，也把定义、架构、自治等级、评测和落地串在了一起。

下面这张图进一步把问题映射到一条端到端工作链：任务怎样进入系统，数据语义怎样约束规划与执行，证据、审批、回读和反馈又怎样闭环。

一、先决定它接手哪类工作

企业问数、端到端分析、自动化数据科学、多源研究和数据工程是不同路线。问数要求稳定语义和只读权限；开放分析要求多步证据链；数据工程还涉及变更、审批和回滚。

不要先决定“做一个万能 Agent”。选一个具体工作流，写清输入、交付物和失败影响。路线回答做什么，L0–L5 回答人和 Agent 怎样分工，两者不能混为一谈。

二、正确答案从找对数据开始

SQL 能运行，只证明程序没有报错。Data Agent 还要在当前身份范围内找到权威数据，确认 Schema 与数据水位，再绑定指标、实体、时间、粒度和 Join 规则。

数据目录回答“有什么”，语义层回答“代表什么、怎么算”。模型可以检索和整理这些知识，却不应自行决定收入、客户和退款口径。没有版本化语义，系统每次都在用自然语言临时猜企业规则。

三、七层架构服务于一个任务

一条完整链路可以概括为：

接入与路由找到相关、授权、足够的数据；
语义层绑定业务定义和关系；
规划与编排把目标变成可恢复状态机；
受控执行校验、授权并运行 SQL、代码和工具；
验证与评测检查来源、语义、程序、分析和交付；
治理与安全贯穿身份、策略、缓存、文件和动作；
交付与行动把声明、证据、制品、审批和反馈连接起来。

这些层不是采购七个系统，也不是强制微服务拆分。它们是一组责任边界：团队必须知道每项控制在哪里实施、失败回到哪里。

四、自治升级等于责任转移

L1 提供草稿，人执行；L2 能调用工具，人编排；Proto-L3 在限定目标内自主规划，人监督。越往后，Agent 获得越多发起、规划、执行和验证权，治理与恢复要求也越高。

同一产品可在不同工作流上处于不同等级。只读问数可能是 L2，生产变更仍保持 L1。等级应标注在“工作流 × 环境 × 权限”上，而不是品牌上。

五、公开榜单只能帮你找候选

Text-to-SQL、代码分析、异构数据和报告基准测量的是不同边界。看排名时记录数据版本、Oracle 输入、模型与工具、重试、评分器、成本和日期。

最终决策需要企业自己的任务集：正常任务之外，还要有歧义口径、迟到数据、同名测试表、越权、工具故障和无法回答的样本。比较任务成功、证据支持、人工修改、p95 延迟和总成本，并把越权与错误写入设为独立阻断项。

产品案例应该变成检查问题

不同厂商案例最有价值的部分，不是功能名单，而是设计线索：

内部 Data Agent 提醒我们，数据发现和组织上下文可能比 SQL 生成更难；
Skills 模式说明分析经验可以变成可复用、可评审的工作协议；
云平台产品展示了数据、语义、身份和运行时如何复用现有控制面；
只读设计说明查询与业务动作应拥有不同权限边界；
多 Agent 架构只有在职责、上下文或权限需要隔离时才有意义。

把每条线索变成自己的 POC 问题，而不是照抄厂商架构。

快手 Data Agent：1 万周活背后的规模化系统工程

Sun, 20 Sep 2026 00:00:00 +0000

一个 Data Agent 获得 1 万周活，意义不在于聊天框里多了多少提问，而在于它已经进入数据生产、经营诊断和日常交付。快手 2026 年 9 月 19 日技术分享中的阶段性数据，展示了一条从单场景 Workflow 到统一 Agent 入口的演进路径。

分享材料给出的快照包括：周活超过 1 万、核心数据分析与产运岗位渗透率超过 80%、Skill 数量超过 2,000，以及超过 60 万条评测记录。这些数字来自快手材料，未经过独立审计，也不应被理解为对其他组织的效果承诺。真正有参考价值的，是规模背后的系统关系。

先从能够验证结果的黄金任务开始

快手早期从单场景 Workflow 探索，逐步扩展到多场景、Agentic 能力和统一入口。规模化并不是先构建一个“万能 Agent”，而是不断找到高频、价值清楚、结果可核对的任务。

所谓黄金任务至少有三个条件：需求持续发生，节省时间对业务有价值，结果能够通过指标、查询或交付物验证。报告生成、异动归因、数据研发和实验分析都符合这一特征。

父 Agent 负责路由，专业 Agent 承担责任

统一入口接收用户目标，父 Agent 理解问题并选择主站、电商、商业化、安全或海外等专业 Agent。通用 Skill 则承担查数、归因和报告等可复用方法。

这种结构解决的是责任分配，而不只是多角色展示。父 Agent 要判断场景和权限，子 Agent 要在自己的数据域、规则和工具范围内完成任务。材料给出父子 Agent 路由准确率 95% 的阶段性口径；实际部署仍需要持续观察误路由如何被发现、纠正和回归。

Skill 把方法变成组织资产

指标查找、异常诊断、SQL 开发、报告和治理规则可以被封装成 Skill。Skill 市场让业务团队复用方法，也为评审和版本控制提供载体。

数量不是目标。一个有价值的 Skill 应明确输入、允许工具、异常处理、验证条件和交付物。若 2,000 个 Skill 缺少 Owner、版本和淘汰机制，路由成本与维护负担也会迅速上升。

知识飞轮解决模型之外的准确性

快手的架构把知识构建、分层存储、搜索或确定性路由、业务应用连成一条链。数据资产与历史任务被抽取为可服务知识，真实使用产生的纠正再回到知识和评测。

Data Agent 榜单怎么看：先读测量链，再看排名

Mon, 14 Sep 2026 00:00:00 +0000

看到某个 Data Agent 排名第一，不能直接推导出它最适合企业采购。榜单回答的是：在某套题、数据、工具、预算和评分规则下，哪些提交表现更好。企业真正要判断的是：它能否在自己的口径、权限、成本和故障条件下稳定交付。

读榜时，最有用的动作不是先看分数，而是沿测量链向前追溯。

1. 它到底测什么任务

Text-to-SQL、数据科学代码、跨源分析和完整报告不是同一种能力。先读输入、允许交互和最终交付物：提交的是一条 SQL、结果表、代码仓库，还是带证据的报告？是否允许多轮工具调用、人工提供表名或重试？

BIRD关注大规模数据库内容下的 Text-to-SQL；Spider 2.0包含企业数据库环境、多 SQL 方言与复杂工作流；Data Agent Benchmark覆盖多数据库系统、异构引用和非结构化信息；FDABench则包含结构化数据、文档、网页、图像、音视频和报告任务。四个榜单的分数没有直接换算关系。

2. 数据和上下文给了多少

核对数据库版本、Schema、文档、样例值、业务知识和真实数据内容。是否提供了 Oracle Tables 或正确表集合？是否允许检索外部知识？表名、注释与题目之间是否存在明显线索？

给出正确表名后测到的是查询推理；让系统自己找表，才包含资产发现。两种设置都有价值，但必须分开报告。动态网页或在线数据库还要记录评测日期，因为环境变化会让同一系统得到不同结果。

3. 运行协议是否可比

模型版本、提示预算、候选数量、重试次数、温度、工具、网络、超时和费用都会影响成绩。pass@k 与单次成功率不是一回事；生成 32 个候选再挑最好结果，也不能与一次运行直接比较。

排行榜有时会更新评分器或修复样本。引用数字时应同时记录基准版本、赛道、提交日期和设置，而不是只截一张榜单图片。

4. 评分器判断了什么

SQL exact match 要求字符串或结构接近参考答案，可能错判等价查询。Execution Accuracy 更接近结果，但仍可能在不完整数据、错误业务口径或偶然相同结果下给分。报告任务使用模型评分器或量表时，还要检查其校准、人工复核和偏差。

可靠基准通常组合执行结果、不变量、结构化断言和人工/模型量表。没有任何评分器可以自动证明企业语义、权限和业务价值。

5. 失败如何分类

总分相同的两个系统，生产表现可能完全不同。一个主要失败在复杂 SQL，另一个会选错表、泄露数据或高置信编造。至少区分：来源选择、语义绑定、程序执行、分析推断、拒答、安全、超时和成本。

还要看方差。同一题运行五次，有一次成功和每次都稳定接近正确，对真实用户不是同一体验。报告均值之外，应提供成功分布、置信区间或重复试验。

6. 成绩能否迁移到我的任务

建立一张 Benchmark Card：范围、数据、环境、评分、风险、维护状态和不覆盖项。然后选择与企业工作流最接近的子集，在内部任务上复跑。

公开基准适合定位候选与能力边界，企业黄金集负责最终决定。后者应包含真实身份、指标版本、数据快照、允许与禁止资产、期望产物、拒答条件和错误成本。

一份读榜检查表

检查项	必须记录
范围	用户、任务、模态、语言、行业和不覆盖内容
数据	数据集/快照版本、是否 Oracle Tables、污染风险
环境	模型、工具、网络、预算、超时、重试、随机性
评分	主指标、评分器版本、人工复核和等价规则
稳定性	运行次数、方差、失败类型和置信区间
成本	延迟、Token、扫描量、工具费用和人工时间
维护	负责人、最后更新、变更日志和淘汰条件

把榜单变成采购证据

先用两个互补公开基准筛出候选，例如一个企业 Text-to-SQL 基准加一个跨源分析基准。再选 50–100 个内部任务，以相同身份、快照、预算和停止规则运行。最后进入影子流量，观察人工修改、权限阻断、延迟、成本和故障恢复。

OpenAI Data Analytics Skills：把分析拆成可检查的工作协议

Sun, 13 Sep 2026 00:00:00 +0000

“最近转化率为什么下降？”一个演示型 Agent 很快就能找表、写 SQL、画折线并列出几个原因。真正交付时，问题才暴露出来：分母是什么，数据是否到齐，渠道结构是否变化，所谓“原因”是计算得到的贡献还是语言模型补出的故事？

Data Analytics Skills 最值得研究的地方，不是某句提示词，而是它把分析工作的责任、交接和完成标准写成了可复用协议。

本文基于公开整理仓库中 15 份 Skill 文档的 2026-10-04 版本进行设计解读。Skill 文本描述期望的工作方式，不等于完整运行架构、线上权限或效果实测。

15 个 Skills 形成五组责任

责任域	Skills	它们要解决的问题
路由与上下文	Index、Gather Business Context、Create Data Context	该不该分析；需要什么临时背景；哪些知识值得长期保存
度量与判断	Design KPIs、Metric Diagnostics、Product & Business Analysis、KPI Reporting、Market Sizing	衡量什么；变化如何构成；证据支持什么决定
可信度	Analyze Data Quality、Validate Data	输入是否适用；计算、方法和结论是否成立
计算与表达	Jupyter Notebooks、Visualize Data	计算是否可复算；图形是否诚实表达问题
交付	Build Dashboard、Build Report、Publish Artifact to Sites	成果如何服务监控、阅读和发布

这不是一条每次都跑完的十五步流水线，也不代表需要十五个独立 Agent。Index 应选择最小够用链，每个 Skill 只承担自己的完成责任。

路由先确定主任务，再决定交付形式

“为什么转化下降”是指标诊断；“把转化下降做成一页报告”仍要先完成诊断，再组织表达。用户提到报告，不会让原因调查自动完成。相反，查询一个定义清楚的指标，也不应自动扩张成全面业务分析。

SQL 跑通了，Data Agent 的答案就可信吗

Thu, 10 Sep 2026 00:00:00 +0000

查询成功、图表漂亮、报告完整，都不能单独证明答案可信。Agent 可能选错数据源、套错指标口径、执行了正确 SQL 却读到不完整数据，最后再把相关性写成因果解释。

一个总准确率会把这些错误压成同一个数字，也会掩盖高风险失败。更有效的做法是沿分析链逐层验证，并让失败回到真正需要修复的位置。

下层错误会污染上层。来源不对时，评价报告文笔没有意义；发生越权时，再高的平均准确率也不能抵消安全问题。

五层验证，各自回答不同问题

层级	验证问题	失败后回到哪里
来源层	资产、版本、权限、数据水位和覆盖是否正确	接入与上下文路由
语义层	指标、实体、粒度、时间、Join 与过滤是否符合业务定义	语义计划或澄清
执行层	查询/代码能否安全运行，结果是否完整且符合契约	工具参数、代码或运行环境
分析层	比较基线、统计方法、推断和不确定性是否成立	分析计划或补充证据
交付层	结论是否有引用，图表是否误导，接收者是否有权使用	报告、制品或审批流程

每层都应产生结构化结果：pass、fail、unknown 或 needs_human，并附证据。未知不能自动当作通过；同一个模型对自己的答案说“看起来正确”，也不是独立验证。

一道题需要多种正确性

以“哪个渠道导致本月转化下降”为例：

任务正确性：是否回答了“贡献变化”，而不是只列出最低转化率渠道。
数据正确性：是否覆盖本月全部渠道，水位是否完整。
语义正确性：转化率分子分母和新客定义是否一致。
程序正确性：SQL 是否避免重复 Join，查询结果是否被截断。
分析正确性：渠道结构变化是否造成聚合偏差，是否误写因果。
交付正确性：结论、证据、限制和建议是否对应，接收人是否有权限。

只用 exact match 比较 SQL，会把等价查询判错，也会把能运行但业务错误的查询判对。评测应执行查询、检查语义绑定和结果性质，再由规则或人判断分析结论。

建立一套来自真实工作的任务集

通用基准能比较研究系统，但企业上线仍需要自己的任务集。样本应来自实际问法、历史工单、分析报告和失败日志，并按业务域、难度、风险和数据形态分层。

每题至少记录：用户身份、目标、允许资产、禁止资产、语义版本、数据快照、期望产物、可接受变体、必须拒绝的行为和评分规则。开放分析不必只有一个标准答案，但应有事实不变量、必须覆盖的假设和不可越过的推断边界。

困难样本不能只靠“更长问题”制造。真正有价值的是同名表、歧义指标、权限差异、数据延迟、空集与零、工具超时、冲突证据和无法回答的问题。

指标要与失败成本对应

一组更实用的指标包括：

资产选择与覆盖：Hit@K、Recall@K、跨源完整集合覆盖率。
语义绑定：正确指标/实体/版本比例，歧义时的澄清或拒答质量。
执行可靠性：可执行率、结果契约通过率、超时与资源超限、重复副作用。
答案支持率：关键事实声明中有可访问证据支持的比例。
校准：系统表达的置信度是否与真实正确率一致，未知时是否收敛。
安全阻断：未授权请求误放行率，必须独立报告并设为上线门禁。
成本与延迟：端到端 p50/p95、模型与工具调用、扫描量和人工复核时间。

不要把这些指标简单平均成一个“综合分”。越权、错误写入和没有证据的高置信结论，成本远高于格式不完美；权重应由场景风险决定。

离线评测、影子运行和线上监控各做什么

离线回归用于固定快照上比较模型、提示词、语义版本和工具变更。每次发布都跑核心集和近期故障集，保存执行轨迹与差异。

影子运行让 Agent 处理真实请求但不向用户或生产系统提交结果，用来发现目录、权限、成本和长尾问题。它比离线集更接近环境，同时保持较低风险。

线上监控关注任务完成、人工修改、拒答、升级、工具故障、权限阻断、延迟和成本。用户点赞不是正确性标签；人工修改也要区分文风调整、口径修正和事实错误。

线上确认的错误进入回归集，但要去除敏感数据、绑定版本并记录失效条件。评测集本身也会漂移，需要负责人和更新流程。

评判器也要被评测

LLM-as-a-judge 适合检查结构、覆盖和开放式表达，却可能偏爱更长、更自信或与自身风格相近的回答。使用前应让多名领域专家标注一组校准样本，测量一致性，并为高风险结论保留人工复核。