数据质量 on DataAgentX

数据质量与分析验证：两道门守住不同的风险

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

一张表没有空值、没有重复，分析就能放心发吗？

未必。数据全对，也可能算错；算得对，也可能比较错了，或者把相关性写成了因果。这三类失败发生在不同的环节，需要用不同的检查去拦。

Data Analytics Skills 把它们分成两个 Skill：Analyze Data Quality 检查数据，Validate Data 检查分析。两道门分别守住不同的风险，缺任何一道都会漏。

先问数据适不适合这次用途

Analyze Data Quality 的起点不是数据本身，而是用途和粒度：一行是用户、订单、订单明细，还是事件？

这个问题决定了后面所有检查是否有意义。订单号重复，不一定是脏数据，也可能是合法的明细行。如果粒度判断错了，去重反而会删掉有效记录，把一个正确的数据源变成错误的分析输入。

原文要求先确认：数据集代表什么、预期粒度、主键或候选键、重要日期列、时区假设、领域规则、允许取值和业务阈值。缺失的上下文应当谨慎推断并标注为假设，而不是默默补齐。

质量检查要按数据形态选

确认粒度之后，再选择高价值检查。原文给出的默认覆盖面是完整性、唯一性、有效性、一致性、完整性约束、时效性、体量与形态。

它也按数据形态给出不同的重点：

数据形态	典型检查
事件数据	重复事件 ID、未来时间戳、会话或用户覆盖缺口、发布后事件结构突变
维度表	非唯一业务键、孤儿代理键、状态变化缺少时间戳、参考值异常流失
事实表	混合粒度、不可能的量值（负收入）、Join 膨胀、迟到或部分加载的分区
特征与评分表	结果字段泄漏、特征稀疏度突增、模型变更后的分布漂移、标签漂移
实验数据	重复分流、分组不均衡、有曝光无分流、分流时间戳之前的事件

一条重要的方法论：比较比例，而不只是计数。1,000 条空值在一个亿级表里和在十万级表里，意义完全不同。同时按时间、来源、国家、平台、模型版本等维度分组，才能区分真实问题和预期波动。

质量报告要解释影响

“发现空值”只是检查结果，不是质量报告。

更有用的写法是：哪些日期、来源和人群受影响；会不会改变分母；会不会造成关联丢行；会不会让看板滞后。原文要求把每项发现与下游风险绑定：破坏可信分析、造成有偏决策、打断 Join、让看板过期、让实验失效、让模型特征不可靠，或者让细分结论失真。

每项发现应带证据、风险、严重度、置信度和最小修复建议，并保留 SQL 或 Notebook。原文对自动化的态度是克制的：稳定规则适合做成自动化测试，波动较大的指标不宜套死阈值。

一个容易被忽略的中间层

粒度之外，还有一类问题最容易被漏掉：时间维度上的完整性。

当用户说“从某天开始”“突然”“最近才出现”时，原文要求优先做时间诊断：首次出现日期、最后出现日期、每日或每周的空值率趋势、重复率趋势、行数趋势、类别份额变化、分布漂移，以及发布、迁移、事故、模型变更和回填前后的变化点。

这类检查之所以重要，是因为很多“业务变化”其实是采集或管道变化。把它们当成业务问题去解释，会浪费大量时间，还会得出错误结论。

再问分析能否支持决定

Validate Data 的对象是分析、图表、报告和建议——不是数据表。

它先提取关键主张：主要问题、受众、决定、头条数字、数据来源、时间窗口、人群、过滤、比较基线和已声明的限制。然后核对方法：人群、资格规则、排除项、抽样、指标定义、公式、单位、分母、时区、队列、比较期和基线，是否与这个决定匹配。

原文特别点出几类隐藏问题：隐藏的排除项、不一致的定义、部分周期比较，以及缺少实验或可靠因果证据的因果措辞。

独立复算，而不是再读一遍

Validate Data 要求独立重算影响最大的数字，检查粒度、小计、分母、非零分母、比率基数、环比基数、加权平均、单位、币种、时区处理，以及互斥类别是否加总到总数。

对 SQL，还要检查 Join 类型、Group By 粒度、过滤、去重计数，以及 Join 前后的行数变化。

教学示例：A 渠道 9 次转化、10 次访问，转化率 90%；B 渠道 50 次转化、100 次访问，转化率 50%。两组率直接平均是 70%，但整体应为 59 ÷ 110 ≈ 53.6%。记录没错，平均方式错了。

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

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 个工作流问题，数据库经常包含上千列，任务还需要检索元数据、方言文档和项目代码。论文发布时的基线结果显示，经典基准上的高分并不会直接迁移到这种复杂环境。