11.5 运行效果验证（AI 数据质检工作流）

叶彦辛《扣子编程从一句话到产品上线：零门槛AI心流开发》全书案例分享~_扣子编程从一句话到产品上线:零门槛ai心流开发-优快云博客

11.5.1  测试输入设计

为了验证工作流的端到端能力，笔者构造了一组涵盖 5 家虚构上市公司、4 个数据源的测试 CSV。5 家公司分别属于银行金融、白酒消费、半导体、医药生物、地产建筑五个行业，覆盖了 A 股主要的板块大类。4 个数据源分别命名为 source_wind.csv、source_eastmoney.csv、source_company_filing.csv、source_news.csv，分别模拟 Wind、东方财富、公司公告、财经新闻四个真实数据源的特征。

测试数据精心设计了真实场景中常见的多种脏数据模式： ①单位错误，财经新闻源把招商银行（600036）的营业收入误用百万元单位（32 914），与其他源（3 291.4 亿元）形成 10 倍差异；②前导零丢失，五粮液（000858）的股票代码因 CSV 默认数字解析而出现 858 vs 000858 的写出问题（用于压力测试工作流的 stock_code 字符串保持能力）；③负号丢失，部分源对周期股的归母净利润正负号录入错误；④小数点错位，员工数被错位放大 10 倍；⑤公司名格式不一致，部分源使用简称如“招商银行”与全称“招商银行股份有限公司”；⑥行业分类口径差异，不同源使用“银行”与“金融-银行”等不同口径；⑦字段缺失，部分源对市值、PE 等字段没有数据；⑧口径差异，员工数是否包含临时工。

source_metadata 设计为：公司公告可信度 1.00、Wind 可信度 0.80、东方财富可信度 0.70、财经新闻可信度 0.50。这一可信度分布反映了实际投研机构的源选择偏好——公司公告最权威但更新滞后，Wind 综合最稳定，东方财富覆盖广但偶有偏差，财经新闻前瞻但波动大。试运行入口的 source_metadata 输入示例如下：

[

  {"name": "source_company_filing", "trust": 1.0},

  {"name": "source_wind",           "trust": 0.8},

  {"name": "source_eastmoney",      "trust": 0.7},

  {"name": "source_news",           "trust": 0.5}

]

arbitration_strategy 字段保留默认值 hybrid，即按“majority_vote → authoritative_source → latest_filing → weighted_median → manual_review”五条规则按优先级降级仲裁。该字段同时支持 majority_only 与 authoritative_only 两种简化策略，用户可按业务偏好切换。

11.5.2  工作流执行流程展示

如图11-5所示，上传4个CSV文件。

图 11-5  试运行页面

点击“试运行”按钮后，工作流依次执行 8 个工作节点。在本章的初始页面展示中，整条流水线从开始节点出发到结束节点结束，是一条无分支的线性 DAG。各节点的执行耗时分布如表 11-4 所示。

表 11-4  各节点试运行耗时统计

节点名	能力类型	本次耗时	节点类型
数据加载	代码工具	710 毫秒	tool
主键对齐	代码工具 + LLM	3.0 秒	agent
字段级冲突检测	代码工具	6 毫秒	tool
异常值检测	大语言模型	6.8 秒	agent
仲裁规则应用	代码工具 + LLM	7.4 秒	agent
数值勾稽校验	代码工具	4 毫秒	tool
审计报告生成	大语言模型	1.4 分钟（约 84 秒）	agent
输出打包	对象存储	1.9 秒	tool
合计	—	约 103.8 秒（约 1.7 分钟）	—

从耗时分布可以看出本章工作流的几个特点。第一，工作流采用纯线性串行执行，前一节点输出是后一节点输入，节点间无并行分支——这种设计让数据流向清晰、调试边界明确，也让审计追溯路径唯一。第二，代码节点的耗时极低——数据加载（710 ms）、字段级冲突检测（6 ms）、数值勾稽校验（4 ms）三个纯代码节点合计仅约 720 ms，占总时长不到 1%。这印证了第 10 章的判断——廉价确定性逻辑应当使用代码工具实现。第三，大模型节点的耗时占据绝对主导——审计报告生成（约 84 s）、仲裁规则应用（7.4 s）、异常值检测（6.8 s）、主键对齐（3.0 s）合计约 101 s，占总时长约 97%。其中审计报告生成单节点就占了 80% 以上，是后续性能优化最值得关注的目标。

这一耗时分布反映了“AI 数据治理”相对于“传统 ETL”的代价——更智能的处理需要更多的 LLM 调用时间。但相对于人工对账 6 ~ 8 小时的传统方式，1.7 分钟的端到端耗时仍是数量级压缩，对绝大多数批处理类数据治理任务而言已完全可接受。

11.5.3  三类核心输出剖析

图 11-6  试运行输出页面

试运行完成后，输出打包节点返回了一个 zip 包，包含三个文件。下面按文件顺序逐一剖析。

（1）cleaned.csv（可信值表）。该 CSV 共 5 行（5 家公司）、13 列（与输入 schema 一致）。绝大多数字段都被成功仲裁出唯一可信值。表 11-5 给出了节选展示（仅展示典型字段）。

表 11-5  cleaned.csv 节选展示

stock_code	company_name	revenue_2024_yi	roe_2024_pct	employees
600036	招商银行股份有限公司	3291.4	14.86	116532
000858	五粮液股份有限公司	832.7	24.32	28614
688256	寒武纪科技股份有限公司	11.7	-12.55	1086
600196	复星医药股份有限公司	408.8	6.85	32475
601668	中国建筑股份有限公司	21871.3	12.18	<待复核>

从可信值表可以观察到几个关键事实。第一，招商银行的营业收入最终被正确仲裁为 3 291.4 亿元，避免了财经新闻源单位错误（32 914百万元）带来的污染。第二，五粮液的股票代码完整保留了前导零（000858 而非 858），印证了数据加载节点 dtype 参数的关键作用——这是扣子编程在测试中专门定位并修复的一个工程细节。第三，中国建筑的员工数因为公司公告口径（含临时工）与其他源（不含临时工）口径差异显著，CV 超过 10%，被升级为待人工复核。第四，所有公司名都被归一化为全称形式，保留了数据的完整性。

（2）conflicts.csv（冲突明细表）。该 CSV 共 20 余行，每一行对应一个被识别为冲突的 (主键, 字段) 组合。展示其中几条代表性记录：

stock_code,field_name,source_name,source_value,

              dispersion_value,rule_applied,trusted_value,reason

600036,revenue_2024_yi,source_news,32914,

               unit_error,llm_assisted+authoritative_source,3291.4,

              "财经新闻检测到单位错误(万元当亿元),

               排除后剩余3源一致,采纳公司公告权威值"

600036,revenue_2024_yi,source_wind,3291.4,

               (normal),majority_vote,3291.4,

              "3/3源一致(排除疑似单位错误后)"

600036,revenue_2024_yi,source_company_filing,3291.4,

               (normal),authoritative_source,3291.4,

              "权威源(公告)优先字段"

000858,stock_code,source_eastmoney,858,

               leading_zero_loss,majority_vote,000858,

              "其他3源完整保留前导零,采纳000858"

601668,employees,source_company_filing,1145200,

               caliber_diff,manual_review,<待复核>,

              "CV=12.3%>10%阈值,口径差异(含临时工),升级人工复核"

从冲突明细可以观察到工作流的“留痕”能力——每一处冲突都被记录，每一次决策都附带规则名与自然语言解释。下游消费者完全可以通过 conflicts.csv 重现整个仲裁过程，这是合规审计的核心需求。特别注意到仲裁日志中出现了“llm_assisted+authoritative_source” 这种组合标签，表示该字段的仲裁经过了“LLM 辅助判断+权威源优先”两条规则的协同处理，体现了代码规则引擎与大语言模型的有机结合。

（3）audit_report.md（可解释审计报告）。该 Markdown 报告约 1 200 字，包含本次治理概况、典型冲突案例、源可信度评估、推荐人工复核项四个章节。报告节选如下：

# 多源财务数据质检审计报告

 

## 一、本次治理概况

 

本次治理共接入 4 个数据源(公司公告、Wind、东方财富、财经新闻),

覆盖 5 家上市公司、13 个字段。检测到字段级冲突 21 条,其中

18 条通过自动仲裁产出可信值,3 条升级人工复核。本次未发现勾稽

关系失败的可信值。

 

## 二、典型冲突案例

 

【案例 1】招商银行(600036)营业收入

- 公司公告: 3,291.4 亿; Wind: 3,291.4 亿;

  东方财富: 3,291.4 亿; 财经新闻: 32,914

- 异常识别: 财经新闻的 32,914 与其他源的 10 倍关系明显,

  且字段单位为亿元,判定为"单位错误(万元当亿元)"

- 仲裁: 排除财经新闻后,公告/Wind/东方财富三源一致,

  命中 majority_vote 规则,并参考权威源(公告)再次确认,

  可信值 3,291.4 亿

- 决策理由: 公告作为权威源,Wind 与东方财富一致;

  财经新闻的单位录入错误已被识别并排除。

 

【案例 2】五粮液(000858)股票代码

- 公司公告: 000858; Wind: 000858;

  东方财富: 858(整型); 财经新闻: 000858

- 异常识别: 东方财富的 858 与其他源的 000858 实际指代

  同一只股票,差异源于 CSV 读入时整型转换丢失前导零

- 仲裁: 命中 majority_vote 规则,可信值 000858

 

## 三、源可信度评估

基于本次治理结果,事后估算各源可信度:

- 公司公告: 1.00 (与其他源高度一致,唯一差异为口径)

- Wind: 0.95 (无明显错误,数值精度最高)

- 东方财富: 0.85 (1 处前导零丢失为序列化技术问题,非数据错误)

- 财经新闻: 0.60 (检测到 1 处单位错误,

  建议下游加强录入校验)

 

## 四、推荐人工复核项

1. 中国建筑 员工数: 口径差异(含临时工 vs 不含),

   请确认采用哪一口径

2. ...(其他略)

这份审计报告完整地把“为什么这样仲裁”用自然语言交代清楚，让合规审计员可以一眼看懂、签字放行。这种“机器决策＋人类可读”的能力，是 AI 时代数据治理工作流相对于传统 ETL 的核心进步。

11.5.4  与设计目标的逐项对照

将 11.3 节中提示词所声明的工作流目标与本节实际运行结果进行对照，如表 11-6 所示。

表 11-6  设计目标与实际运行效果对照

设计目标	实际交付	验证结果
多源 CSV 数据加载	4 个源 CSV 全部成功加载，stock_code 前导零保留	达成
以主键对齐多源记录	5 家公司全部成功对齐，公司名归一化	达成
字段级冲突识别	约 20 处字段冲突被准确识别	达成
脏数据模式识别	单位错误／前导零丢失／口径差异等全部识别	达成
五条规则按优先级降级仲裁	18 处自动仲裁＋3 处升级人工复核	达成
可信值通过数值勾稽校验	所有可信值勾稽关系通过	达成
可解释审计报告	约 1 200 字自然语言报告，含四个章节	达成
三产物 zip 打包返回	cleaned.csv＋conflicts.csv ＋audit_report.md	达成

八项设计目标全部实现闭环，验证了本章提出的多源数据质检工作流设计方法与九要素提示词模型的有效性。需要补充说明的是，扣子编程在本项目的搭建过程中主动暴露并修复了一个真实的工程 bug——CSV 读写过程中股票代码 000858 的前导零被 pandas 隐式吞掉、变成整型 858。这一 bug 被定位的过程（先在 cleaned.csv 中看到 858 → 追溯到 data_load_node 与 output_package_node 的 dtype 配置 → 显式声明 dtype={"stock_code": str} 并在 to_csv 阶段保持字符串格式）本身就是一个生动的 AI 协同调试案例，提示读者：AI 生成的工作流并非“开箱即生产”，仍需配合具体业务数据进行回归验证。