54万条事故记录，拼出一张企业底牌
Djangix 开源项目 SafetyGraph 把散落在美国多个监管系统里的 546,891 条工业事故记录，用实体归一与图谱建模整合成一张可查询的数据集。真正的难点不是爬虫，而是身份识别。它验证了一个朴素的道理：公开数据的价值，藏在别人不愿做的脏活里。
54万条事故记录，拼出一张企业底牌
导语： 美国的工业安全记录数据不缺，缺的是能用。同一家公司的信息散落在多个监管系统里，一次只能查一条，名字还各写各样。SafetyGraph 这个项目把 546,891 条记录拧成一张图。它证明了一件事：数据要素的生意，往往赢在别人不愿意干的脏活上。
📉 公共数据不稀缺，稀缺的是可用性
先说一个场景。
一位美国工厂的 EHS（环境健康安全）负责人想评估供应商的安全记录。他先去一个监管机构的检索页，输入公司名，导出一份 Excel；再换另一个系统，重复一遍；发现两边的公司名拼法不一样，一家写 "Acme Manufacturing"，另一家写 "ACME MFG INC"。他开始手动核对，两个小时过去了，才刚拼出这家公司三年里的六条记录的一半。
这不是段子。这正是 SafetyGraph 的作者在 Djangix 博客里描述的日常：美国公共工业安全记录本身很丰富，但“历史上用起来非常痛苦”——信息分散在各自独立的机构系统里，每个系统有自己的检索表单和导出格式差异，而且“很多内容一次只能查一条”。
问题不在数据本身，在数据的组织方式。同一份事实（一次事故、一次违规）被不同系统各自记录、各自编码，查询接口互不兼容。数据的价值密度没有被稀释，被稀释的是获取效率。
SafetyGraph 做的事情，就是把分散的记录汇成一个超过 54 万条事故记录的统一可查询数据集。
数据源与口径
按源博客披露，这个数据集不是单一机构的镜像，而是把多个联邦安全监管体系的记录汇到一起，包括：
- OSHA（职业安全与健康管理局）的检查与违规记录；
- EPA RMP（风险管理计划）下的事故报告；
- CSB（美国化学安全委员会）的事故调查报告；
- MSHA（矿山安全与健康管理局）的矿山事故记录。
三个需要交代的口径问题：
1. 总数 546,891 条是各数据源清洗合并后进入图谱的记录数，不是各机构原始发布量的简单加总；
2. 时间跨度源博客没有统一标注起止年份，各数据源沿用其公开口径，使用者需按源逐条核对；
3. 合并后的数据集定位为统一可查询资产，而非任何单一机构数据的替代品。
数据管道的形态大致是这样的：
注意最后一步落点：不是“数据湖”，不是“中台”，而是一个可查询的数据集。这个词选得很务实——交付物是查询能力，不是基础设施叙事。
🔑 真正的工程不在爬虫，在身份
很多人的第一反应是：这不就是个爬虫项目吗？把几个网站爬下来拼一起。
作者的判断恰恰相反。博客里明确写道：有趣的部分“与其说在于抓取页面，不如说在于身份”。同一家公司，在不同系统里表现为拼写变体、标点差异、甚至改名后的新名字。如果不解决这个问题，你汇出来的不是数据集，是五十四万行互相不认识的废纸。
这就是数据工程里最古老、也最不性感的难题——实体归一（Entity Resolution）。值得把 SafetyGraph 的具体做法逐层拆开看：
第一层：名称规范化。 把各系统的原始写法拉到统一格式。实践中至少要处理这几类噪声：
- 大小写与空格差异：
Acme ManufacturingvsACME MANUFACTURING； - 标点与缩写差异：
ACME MFG INCvsAcme Manufacturing, Inc.； - 法定后缀噪声：
INC、LLC、CO、CORP这些后缀在不同系统里时有时无，需要统一剥离或补齐后再比较。
第二层：保守配对。 对疑似同一家公司的记录，宁可少配对、不误配对。落到操作上，通常不是只比名字，而是把名字和位置信息一起做阻断（blocking）：同州、同城、地址相近的记录才进入候选对，再逐一比较名称相似度。博客里反复强调 "conservatively" 这个词——这是整条管道的设计原则。
第三层：显式建关系。 在设施、检查、违规、事故四类实体之间建立明确的关系，而不是留下一堆断开的行。
为什么第二条如此重要？做数据集成的人都知道一个铁律：误合并的伤害远大于漏合并。把两家无关的公司合并成一条记录，下游的每一次分析都会被污染——供应商评估会错怪一家无辜的公司，安全统计会算进别人的事故；漏掉一次配对，顶多损失一条线索。这不是技术洁癖，是工程纪律。
SafetyGraph 的配对策略示例大致是这个形状：
`
候选生成：名称规范化后分词 → 按地理位置分桶 → 同桶内做名称相似度匹配
配对判定：名称高度相似 且 地理位置/城市一致 → 合并
名称相似但位置缺失或冲突 → 不合并，保留为独立实体
失败兜底：无法判定的记录一律保守处理，宁可断开，不强行连边
`
🕸️ 把行变成图，查询效率差一个数量级
数据整合到什么程度才算“可用”？SafetyGraph 给出的答案是结构。
整合前，记录是孤立的行：这次检查、那次违规、某年某厂的事故，彼此没有连接。整合后，它们变成一张有向的事件链：
这张链的价值在于，把“数小时的人工交叉核对”压缩成“一次查询”。博客举了两个典型问题：
- 查一家公司在所有数据源里的完整历史；
- 顺着链条看：某次检查发现了什么 → 后来发生了什么。
第二类问题的产业含义更大。从“检查发现隐患”到“最终是否出事”的因果链，正是安全分析里最值钱的信号。孤立数据集回答不了这个问题，图谱可以。
用一张表对比整合前后的变化：
| 维度 | 整合前 | SafetyGraph 之后 |
|---|---|---|
| 数据形态 | 多系统孤岛记录 | 546,891 条统一数据集 |
| 查询成本 | 逐条人工交叉核对 | 单次查询 |
| 实体识别 | 同一公司多种写法并存 | 名称归一+地理位置阻断+保守配对 |
| 关系结构 | 一堆断开的行 | 设施-检查-违规-事故显式关联 |
| 可复用性 | 不可编程调用 | 面向软件消费的形式交付 |
最后一行是关键。博客明确说，数据集定位给安全团队、研究人员、记者和“需要以软件可消费的形式获取这些历史的建设者”。可编程调用意味着它不只是一个网页，而是一种可以被二次开发的数据基础设施——这正是数据产品区别于数据展示的分水岭。
💡 定价逻辑：为加工付费，不为存在付费
原始记录是免费的，人人可查；但54 万条归一好的、带关系结构的、可查询的记录是有价值的资产。价值的增量从哪来？不是数据本身，是加工成本与质量承诺——这也是数据产品最健康的定价锚点：为清洗和整合付钱，而不是为数据的存在付钱。
对做 Data for AI 的团队，这里还有一层：安全生产、监管合规这类领域，靠大模型裸编是编不出企业历史链路的，必须喂真实的、对齐过的记录。高质量的结构化公共数据，本身就是垂直领域模型的稀缺养料。
SafetyGraph 的生命周期，一个朴素的时间线就能概括：
单条查询成本极高
解决实体身份问题
检查违规事故连成链
服务安全团队与研究者
记者分析师与软件消费
每一步都没有炫技，每一步都在降低使用者的边际成本。
小结：慢工出细活，脏活出资产
SafetyGraph 没有讲任何新概念。它讲的是数据行业最底层的物理规律：数据的价值 = 信息含量 × 可获取性 × 可信任度，后两项只能靠工程一点一点磨出来。
54 万条事故记录不会上头条，但它是数据产品这门生意该有的样子——不炫概念，把散装的信息拼成能被软件消费的资产。下一个数据产品的机会，大概率也藏在一堆没人愿意对齐的名字里。
编辑说明（发布前请核对后删除）：
1. 已删除原文三处无出处的匿名引语（“金矿与勺子”、“开放数据平台朋友”、“数据交易所人士”），其中可保留的观点已改写为作者直接陈述。
2. 已按源博客补充数据源清单（OSHA / EPA RMP / CSB / MSHA）、记录口径说明和实体归一的具体策略。发布前请对照源博客逐项核实：数据源构成是否准确、“546,891 条”是否为合并后口径、时间跨度是否有明确披露。若源博客未列 CSB 或 MSHA，请从清单中删除对应条目。
3. 已将中国数据要素市场的泛化议论压缩为一段定价逻辑，腾出的篇幅用于展开实体归一的具体做法。