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

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

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 输入示例如下：

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 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 节选展示

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

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

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

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

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

11.5.4  与设计目标的逐项对照

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

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

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