NL2SQL on DataAgentX

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

Agent 越强，为什么越需要语义层

Tue, 08 Sep 2026 00:00:00 +0000

把订单表、支付表和客户表的 Schema 交给模型，它很快就能写出一条可运行的 SQL。可当用户问“上个月收入是多少”，真正的问题才开始：收入是下单金额、实收、净收款还是财务确认收入？按下单时间还是确认时间？退款归属哪个月？

这些不是模型应该自由推断的常识，而是企业自己的业务合同。Agent 能力越强、执行链越长，一个错误定义被传播到报告和动作中的代价就越大。

Schema 描述数据的形状；语义层规定数据在什么条件下代表什么事实、允许怎样聚合。模型可以帮助发现冲突、起草定义，却不能替指标负责人决定口径。

语义层、本体和目录各管什么

资产目录回答“有什么、在哪里、谁负责”；语义层回答“怎么算、能按哪些维度分析”；业务本体回答客户、账户、订单等概念如何识别和关联。执行与治理系统则强制实施权限、预算和审计。

本体不一定要从复杂知识图谱起步。一个受治理的实体关系模型，能明确主键、基数、有效期和身份映射，就已经解决很多 Join 放大和概念混用问题。重要的是定义可引用、可版本化、可被查询编译或验证，而不是图画得多复杂。

六类语义资产缺一不可

资产	至少要明确	缺失后的典型错误
指标	公式、单位、时间口径、粒度、聚合、版本、负责人	把支付金额当确认收入；比率直接平均
实体	主键、唯一性、关系方向、基数、有效期	一对多 Join 放大金额；账户与客户混用
维度	层级、合法取值、适用指标、历史归属	用当前地区解释历史业绩
同义词	业务域、语言、候选概念与不可等同项	把营收、销售额和回款无条件合并
业务规则	状态过滤、币种、财务周期、用途、生效区间	测试订单进入正式报表
验证样例	问题、口径、查询、快照、预期结果、验证人	旧 SQL 被当成永久正确答案

这些资产可以分布在词汇表、指标服务、目录和样例库中，但必须通过稳定 ID 与版本关联。复制多份自然语言说明，通常只会制造新的漂移。

“收入”案例：先绑定定义，再写 SQL

假设团队同时维护交易总额、实收金额和财务确认收入。用户只说“收入”时，可靠流程是：

检查当前报表或会话是否已绑定某个指标；没有明确上下文就澄清。
将“上个月”转换为指定时区的具体区间，确定支付时间还是确认时间。
读取退款、税费、币种和内部账户排除规则。
先形成指标、维度、过滤与版本组成的语义计划，再编译查询。

一个最小指标契约可以长这样：

{
 "metric_id": "commerce.period_net_receipts",
 "version": "1.0",
 "definition": "期间成功收款减期间成功退款",
 "expression": "sum(receipt_cny) - sum(refund_cny)",
 "time_fields": {"receipts": "paid_at", "refunds": "refunded_at"},
 "timezone": "Asia/Shanghai",
 "grain": "calendar_day",
 "unit": "CNY",
 "allowed_dimensions": ["channel"],
 "missing_input_policy": "unknown_not_zero",
 "effective_from": "2026-08-01",
 "test_suite_ref": "tests/net-receipts-v1"
}

缺失输入记为未知，而不是零；退款与收款应先按兼容粒度聚合，再对齐计算，不能直接连接两张明细表造成乘积。最终答案还应带出采用的指标版本、时间字段、数据水位和限制。

语义如何进入运行链路

语义资产只有进入执行与验证，才不只是文档：

五条 Data Agent 技术路线：别用同一把尺子比较不同产品

Sat, 05 Sep 2026 00:00:00 +0000

同样叫 Data Agent，有的系统把一句业务问题翻译成 SQL，有的会连续运行查询和 Python、写出一份分析报告，还有的直接修改数据管道。这些产品共享了一个名字，却不应共享同一套验收标准。

判断路线时，我更愿意先看一个具体工作流，而不是厂商首页上的产品名称：它接收什么输入，替人完成哪段工作，最终交付什么，以及失败后会影响谁。按这四个问题，Data Agent 大致可以分为五条路线。

这张图有两个刻意的设计。第一，五条路线是并列的任务类型，不是从低到高的成熟度等级；第二，路线决定系统“做什么”，语义上下文、运行时、权限和评测共同决定它“能否可靠地做”。

一、企业问数与语义层：把业务语言变成可信查询

这条路线解决的是高频、相对标准化的业务问题，例如“华东区上周新增付费客户是多少”“下降主要来自哪个渠道”。Agent 需要把业务词汇映射到指标、维度、表和连接关系，再生成查询并解释结果。

它看起来像 NL2SQL，真正的难点却通常不在 SQL 语法，而在语义：什么算“新增”，退款是否回冲，订单按支付日还是发货日归属。没有指标定义、实体关系、权限和可复用的正确样例，模型越会写 SQL，越可能快速给出一个格式正确但口径错误的答案。

Snowflake Cortex Analyst要求通过语义模型描述业务概念，并继承 Snowflake 的访问控制；其 Verified Query Repository 用经过验证的问句—SQL 对提升稳定性。Microsoft Fabric Data Agent也把自然语言问题转成面向 Fabric 数据源的查询，并按调用者权限执行。它们说明了这条路线的核心：不是聊天界面，而是“语义约束下的只读数据访问”。

验收重点：业务口径命中率、查询执行正确率、权限不越界、无答案时能否拒答或澄清。仅用 SQL 字符串与标准答案逐字比较，往往会低估等价查询，也会漏掉“SQL 正确但业务答案错误”的情况。

二、端到端分析与报告：从一个问题走到可复核的判断

如果问题变成“为什么本月留存下降，应该先排查什么”，单次查询就不够了。Agent 要拆解假设、选择比较基线、运行多轮查询或代码、制作图表，并把证据与结论组织成报告。

这条路线的产品价值来自缩短分析闭环，但也最容易制造“看起来很专业”的错觉。一份排版完整的报告可能用了错误分母，忽略了样本结构变化，或者把相关性写成因果关系。因此系统应保存分析计划、查询与代码、关键中间结果、图表数据和引用，让读者能够沿证据链回查。

验收重点：问题拆解是否覆盖关键假设，结论能否由已执行的证据支持，统计方法是否适用，重跑是否得到一致结果。报告文笔只是最后一层，不是核心质量。

三、自动化数据科学：让实验可运行，也让失败可解释

数据科学 Agent 会参与探索性分析、特征处理、统计检验、模型训练与评估。它与报告型 Agent 的区别，是交付物不只有洞察，还包括可运行代码、数据切分、模型指标和实验记录。

Google Data Science Agent把自然语言目标转成 Colab Enterprise 笔记本中的分析计划、代码与结果。这类系统可以显著减少搭脚手架的时间，但仍无法替代对标签泄漏、时间穿越、抽样偏差和评估设计的专业判断。

验收重点：环境与依赖能否复现，训练/验证边界是否正确，指标是否匹配业务成本，异常和失败是否被暴露。一个能跑通的 notebook 只是起点，不是模型可上线的证明。

四、异构与多模态分析：在多种证据之间建立连接

真实调查常同时涉及数据库、Excel、PDF、网页、图片、日志甚至音视频。此时 Agent 的主要工作不再是生成某一种查询，而是检索、解析、实体对齐、跨源聚合，并说明每个判断来自哪里。

例如排查供应商履约问题，既要读仓库里的交付数据，也要从合同 PDF 提取时限条款，再从工单文本识别异常原因。任何一个实体匹配或时间对齐错误，都可能让最后的综合结论失真。

验收重点：解析覆盖率、实体链接准确率、来源定位、冲突证据处理与引用完整性。系统应把“没有找到”“无法确认”和“推断得到”分开，而不是用流畅文字抹平证据缺口。

五、数据治理与数据工程：从回答问题走向改变系统

这条路线面向元数据维护、质量规则、血缘与影响分析、数据模型开发、管道排错和运维。它的输出可能是一份变更建议，也可能是 Dataform、dbt 或编排系统中的代码和配置。

SQL 写对了，答案为什么还会错？

Fri, 04 Sep 2026 00:00:00 +0000

数据分析里最危险的结果，往往不是一条报错的 SQL，而是一条顺利运行、数字精确、图表漂亮，却回答了错误问题的 SQL。

假设运营问：“本月新增客户是多少？”系统找到 customer 表，按 created_at 统计去重 ID，返回 12,486。查询没有语法错误，结果也能复现。但销售团队口中的“新增客户”是首次付费客户，财务还要求排除退款和内部测试账户。12,486 只是“本月新建客户记录”，不是提问者准备据此做预算的指标。

SQL 没有错。错误发生在 SQL 之前。

正确性不是一个开关，而是一条链

一项数据结论至少要通过四层正确性：

语法正确：查询能被数据库解析和执行。
数据正确：表、Join、粒度、时间和质量状态符合任务要求。
口径正确：计算使用了组织认可、在当前时间有效的业务定义。
解释正确：结论没有超出证据，限制条件和不确定性被如实表达。

大多数 Text-to-SQL 指标首先测的是前两层的一部分。企业真正承担决策风险的，却是后两层。

五种常见的“正确地算错”

1. 同一个词，在不同团队代表不同事件

“客户”可能是注册用户、通过认证的企业、首次付费账户或签署合同的主体。“收入”可能是下单金额、支付金额、确认收入或扣除退款后的净收入。字段名相似，并不能证明业务含义相同。

Agent 如果静默选择一个定义，会让偶然的猜测看起来像确定事实。更好的行为是检索权威定义；存在多个有效口径时，把候选项和数字影响展示给用户确认。

2. 时间窗口没有对齐

“本月”可能指自然月、最近 30 天、财务账期，也可能受用户时区影响。同比还隐含工作日、节假日和完整周期是否可比。SQL 中一个看似无害的 CURRENT_DATE - 30，就可能改变管理层对趋势的判断。

3. Join 改变了数据粒度

订单表是一行一单，商品明细是一行一个 SKU。两表直接 Join 后对订单金额求和，会把多商品订单重复计算。查询能运行，抽样看起来也合理，只有先声明目标粒度并检查 Join 前后的行数和唯一键，才容易发现问题。

4. 状态过滤散落在历史 SQL 里

是否排除取消单、退款单、测试账户和风控交易，经常没有写在字段说明里，而是藏在某张看板或某位分析师维护的查询中。只给 Agent schema，相当于只给它词典，没有给它组织的会计规则。

5. 定义已经改变，答案仍在引用旧版本

指标口径会随业务发展而调整。文档、看板、语义层和历史 SQL 如果不同步，同一问题在不同入口会出现多个“官方答案”。这类版本漂移必须通过负责人、生效时间和弃用状态处理，不能靠模型选择看起来最新的一段文字。

为什么把更多 schema 塞进上下文仍不够

Spider 2.0 把 Text-to-SQL 放进更接近企业的环境：632 个工作流问题，数据库经常包含上千列，任务还需要检索元数据、方言文档和项目代码。论文发布时的基线结果显示，经典基准上的高分并不会直接迁移到这种复杂环境。

什么是 Data Agent：判断它是不是智能体的四个标准

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

“为什么本周转化率下降了？”

一个 NL2SQL 工具可以把这句话翻译成查询。一个真正的 Data Agent 则要先问清楚：是哪条业务线、哪个转化漏斗、自然周还是滚动七天、当前用户有权查看哪些数据。随后，它还要找到可信的数据集，调用指标定义，拆解异常，运行查询，检查样本量和数据新鲜度，最后把结论连同证据交给使用者。

二者都可能有聊天框，也都可能生成 SQL。区别不在界面，而在于谁对完整任务闭环负责。

一个可以落地的定义

Data Agent 是运行在受治理数据环境中的自主或半自主软件系统。它接受自然语言或高层任务，在权限边界内完成上下文装配、规划、工具执行和结果验证，交付可追溯的数据答案、洞察或行动。

这里的每个限定词都有用：

数据环境意味着系统面对的是真实表、指标、文档、元数据和访问策略，而不是一组预设答案。
自主或半自主意味着它能维护任务状态，根据中间结果继续、修正或停止，而不是只完成一次生成。
受治理意味着模型不能绕开身份、权限和审批规则；高风险操作必须有边界。
可追溯意味着使用者能看到结论依据了什么数据、口径和执行过程，也能复核关键结果。

近年的 Data Agent 研究也反复指出：这个名称同时被用于查询助手和自主系统，术语混用会掩盖能力差异。《A Survey of Data Agents》因此提出了从 L0 到 L5 的分类；后续的《Data Agents: Levels, State of the Art, and Open Problems》则把数据管理、准备和分析都纳入同一个工具使用框架。定义的价值，不是再造一个新名词，而是让产品承诺可以被检验。

Data、Model 和 Harness 缺一不可

只看大模型，很容易把 Data Agent 理解成“更会推理的聊天机器人”。实际系统更接近三个部分的乘积。

Data：不只是数据库连接

数据侧至少包含三类上下文：

事实数据：仓库、湖仓、业务数据库、文件和 API。
业务语义：指标定义、维度层级、实体关系、同义词和计算规则。
治理上下文：身份、行列权限、数据分级、新鲜度、血缘和使用限制。

能连上 Snowflake 或 BigQuery，只解决了“数据在哪里”。如果不知道“有效订单”是否排除退款，也不知道财务口径何时生效，系统仍然会稳定地产生错误答案。

Model：提供推理，不拥有权限

模型擅长理解意图、提出假设、生成 SQL 或 Python，并把结果组织成人能读懂的说明。但模型参数不是企业事实库，也不应该成为权限系统。把业务定义塞进提示词，只能暂时改善某个问题，无法替代版本化的语义层和强制执行的访问策略。

Harness：把能力组织成可靠过程

Agent Harness 是最容易被低估的部分。它负责装配上下文、保存状态、安排步骤、选择工具、传递身份、限制执行、校验结果并记录轨迹。模型可以替换，工具可以增加；只要 Harness 的契约稳定，系统仍能按同一套治理规则工作。