ShreyasPasumarthi/pipeline-incidents-bench

# pipeline-incidents-bench **你的 AI agent 真的能修复破损的数据 pipeline 吗？证明它。** 提供可复现的破损数据 pipeline 场景，并包含*可执行的*标准答案，用于 评估 AI 事件响应 agent。每个场景都是一个小巧、真实的 分析代码仓库（包含 dbt + DuckDB 和 git 历史），并注入了一个故障。 agent 将获得与人类待命工程师相同的证据——失败的运行日志、 dbt artifacts、git log、源数据样本——并且必须诊断出根本原因， 并**编辑代码仓库以修复它**。 核心特性：**修复结果由执行结果评判，而非主观意见。** 在 agent 进行编辑后，测试框架会重新运行 pipeline。它会变绿并通过 隐藏的数据断言，否则就不会。没有 LLM 裁判来决定诊断是否“听起来合理”。 ## 为什么需要它 数据 pipeline 事件代价高昂且频繁发生：上游 schema 漂移， 供应商悄悄更改导出格式，看似无害的重构悄悄 丢失数据行。现有的可观测性工具可以检测到这些。目前悬而未决的问题是 agent 能否*修复*它们——而且目前 没有客观的方法来衡量这一点。这个 benchmark 就是那个测量标尺。 由此产生的设计选择： - **根本原因归因会被评分，包括空情况。** 有一个场景 根本没有代码原因——那些反射性地将责任归咎于最新 commit 的 agent 会扣分。真实的事件往往是数据问题，而不是代码问题。 - **到处都是诱饵 commit。** 无辜的 commit 修改了失败的模型； 有故障的 commit 带着无害的信息（“perf: simplify joins”）。 - **受保护的路径。** agent 不能通过编辑其不拥有的上游 数据或删除失败的测试来“修复” pipeline。警报并不等于火灾。 - **零基础设施。** 场景运行在 dbt + DuckDB 上：只需 `pip install`，无需 Docker，几秒钟内从红灯转为绿灯。更重级别的场景（Airflow, Postgres, Spark） 已在路线图上，但采用阻力比 真实感得分更重要。 ## 快速开始 ``` python3 -m venv .venv && .venv/bin/pip install -e . # 仅限 Python 3.14：pip install -U mashumaro (dbt-core 锁定版本滞后于 3.14 支持) .venv/bin/pib list # show scenarios .venv/bin/pib validate # every scenario: reproduces red + solvable .venv/bin/pib run --agent null # do-nothing baseline (~5%) .venv/bin/pib run --agent oracle # hidden solutions applied (100%) .venv/bin/pib run --agent "python3 agents/example/agent.py" # your agent here ``` ### 上下文来源 默认情况下，测试框架会自行组装事件包（`--context-source curated`）。如果要让其由 [Pipemend](../pipemend) 收集器从原始工作区状态构建——就像在生产环境中的方式一样——请传入 `--context-source collector`： ``` .venv/bin/pib run --agent "" --context-source collector ``` 收集器仅接收破损的代码仓库和运行命令，绝不接收 场景的标准答案。它必须能够通过作为同级目录的 `pipemend` 仓库（具有已构建的 `.venv`）、在 `PATH` 中，或通过 `PIPEMEND_CMD` 环境变量被发现。请参阅 [RESULTS.md](RESULTS.md) 查看 curated 与 collector 的比较。 ## Agent 协议 任何可执行的程序都可以。测试框架会调用： ``` --workspace --context --output ``` - `workspace` —— 破损的 pipeline 代码仓库。读取任何内容，编辑任何内容 （你的编辑就是修复方案）。你可以随意重新运行 `bash run_pipeline.sh`。 - `context` —— 事件包：失败的运行 stdout/stderr、解析后的 dbt `run_results`、最近 commit 的 `git log -p`、文件树，以及 每个数据文件（包括不在 git 中的落地文件）的头部样本。其确切 结构取决于 `--context-source`（curated 包还是 Pipemend collector 包）；agent 应将其视为不透明的事件证据。 - `report.json` —— 你的诊断： ``` { "root_cause_category": "schema_change | source_data_change | logic_bug | dependency_failure | infra_failure | other", "root_cause": "free-text diagnosis", "culprit_commit": ", or null if no code change caused this", "evidence": ["paths or short descriptions"], "fix_description": "what you changed and why" } ``` 请参阅 `agents/example/agent.py` 获取最简 I/O 框架。 ## 评分 | 检查项 | 权重 | 评分方式 | |---|---|---| | `fix_verified` | 50% | Pipeline 重新运行变绿 + 隐藏的 SQL 断言通过 + 未触及受保护的文件 | | `root_cause` | 20% | 诊断包含关键概念（关键词组，OR 的 AND） | | `category` | 15% | 与可接受的类别匹配（复合事件接受多个类别） | | `culprit_commit` | 15% | 正确的 sha —— 或正确地报告*没有*罪魁祸首 | 隐藏断言会阻止退化的“修复”：删除行、硬编码值， 或削弱测试都不会产生正确的行数和总数。 ## 场景剖析 ``` scenarios/001-upstream-column-rename/ scenario.yaml # commits to replay, ground truth, hidden assertions base/ # working pipeline repo (initial commit) commits/ # overlays replayed as git history; one may be the fault landing/ # files dropped outside git (vendor exports), if any solution/ # hidden reference fix — proves the scenario is solvable ``` 每个场景都必须通过 `pib validate`：故障必须能重现红灯，并且 参考解决方案得分刚好 100%。无法解决或无法 重现的场景不会被发布。 ### 当前场景 | id | 故障 | 原因在 git 中？ | |---|---|---| | `001-upstream-column-rename` | 上游导出重命名 `user_id` → `customer_id`；staging 视图损坏 | 是，伪装成 chore | | `002-vendor-export-format-change` | 供应商将 `amount` 切换为 `amount_minor`（美分）；not_null 测试失败 | **否** —— 仅限数据 | | `003-bad-join-refactor` | “perf” commit 将 left join 变成了 inner join；访客订单被悄悄丢弃 | 是，伪装成 perf | | `004-broken-import-refactor` | 摄取重构发布了破损的 import；pipeline 在 dbt 之前死亡 | 是 | | `005-duplicate-vendor-rows` | 供应商重新交付了重叠的行；unique 测试失败 | **否** —— 仅限数据 | 困难级别 —— 这些场景会惩罚浅尝辄止的“打补丁直到变绿”策略： | id | 故障 | 困难之处 | |---|---|---| | `006-incremental-backfill` | 美分 bug 损坏了*增量*模型 | 仅修复代码是不够的——过期行依然存在；必须进行回填（full-refresh） | | `007-compound-incident` | 供应商格式更改**和** join 回归同时发生 | 仅修复一个故障仍会使 pipeline 处于红灯状态；归因必须理清两个原因 | | `008-fanout-join` | 地址扩充 join 未过滤类型；订单出现发散 | 错误是发生在原因下游两个模型处的粒度违规 | | `009-poisoned-numeric-format` | 供应商添加了千位分隔符（`"1,234.56"`）；类型转换崩溃 | 故障表面出现在 mart 中，原因却在 landing 文件中；没有 git 原因 | | `010-warehouse-path-drift` | “标准化仓库位置”chore 将 dbt 指向了一个空数据库 | *诱人*的修复（将摄取与新路径对齐）会变绿，但违反了代码仓库文档约定的规范——隐藏断言会捕捉到它 | ## 相关工作与定位 “用于事件响应的 AI agent”领域非常活跃，但它根据*层* 以及工具实际拥有的*循环中的哪一部分*进行了清晰的划分： - **通用软件/基础设施可观测性** —— 例如 [Superlog](https://superlog.sh/) （开源 agentic 遥测：摄取 OpenTelemetry traces/logs/metrics， 将嘈杂的信号分组为事件）。这些工具在运行中的服务遥测上运行，在*检测和分类*方面表现最强；自主*修复*仍处于早期阶段（开放的默认 agent 仅记录事件摘要）。 - **数据可观测性** —— Monte Carlo, Anomalo, Metaplane：检测数据仓库中的数据质量 和新颖度异常。在报警方面很强；补救措施 则留给了人类。 这个 benchmark 刻意与两者正交。它不检测事件 ——它假设已经发生了一个事件——并且它衡量了其他人都避而不谈的步骤：**agent 真的能修复它，并通过执行验证吗？** 其范围是 *数据层*（dbt/warehouse/git），评分是可复现的 标准答案，而不是 LLM 裁判或人类的意见。据我们所知，没有公开的 benchmark 衡量过数据 pipeline 事件的已验证补救措施；这个差距就是 它存在的原因。 ## 路线图 - 30–50 个场景，涵盖 schema drift、数据异常、逻辑 bug、依赖 和基础设施故障 - 困难级别：dockerized Airflow + Postgres + Spark 场景 - LLM-agent 基准（Claude, GPT）及已发布的记分卡 - 用于根本原因自由文本的 LLM 裁判（关键词组为 v0） - 嘈杂的多信号事件：在这种场景中，失败的运行只是许多相关 警报中的一个，旨在测试分类/分组，而不仅仅是单故障修复 ## License MIT 由 **Pipemend** 构建和维护 —— 针对 数据 pipeline 的 AI 事件响应。

标签：AI智能体, dbt, DuckDB, 数据可观测性, 数据管道, 网络安全研究, 软件工程, 逆向工具