1. 项目概述一次对机器学习供应链的深度“体检”如果你和我一样经常在Hugging Face上寻找合适的预训练模型或数据集然后基于它们进行微调、集成最终构建自己的应用那么你很可能已经身处一个庞大而复杂的“供应链”网络之中。这个网络我们称之为机器学习供应链它远比传统软件依赖库的“pip install”要复杂得多。它不仅仅是代码的依赖更包含了数据集的来源、基础模型的架构、训练过程的参数以及最容易被忽视却又至关重要的——许可证条款。最近我和团队一起对Hugging Face这个全球最大的模型与数据集枢纽进行了一次大规模的实证分析。我们爬取了超过76万个模型和17.5万个数据集的公开信息试图回答几个核心问题这个生态系统的“说明书”写得怎么样模型与模型、模型与数据之间到底是如何“血脉相连”的当我们在复用这些组件时头顶上悬着的“许可证之剑”究竟有多锋利结果既在预料之中又令人深思。我们发现文档的缺失和模糊是常态供应链的图谱错综复杂得像一团乱麻而许可证的声明混乱与潜在冲突更是为未来的合规使用埋下了不小的隐患。这篇文章我就想和你聊聊我们看到的这些真实情况以及作为一名从业者在实际项目中该如何应对这些挑战。2. 研究设计与数据爬取如何为76万个模型“建档立卡”要理解一个生态系统首先得看清它的全貌。我们的目标是为Hugging Face上的ML供应链画一张尽可能精确的“地图”。这听起来简单做起来却是一系列精细且充满陷阱的操作。2.1 数据收集策略与工具选型我们的数据源很明确Hugging Face Hub的公开API。这是最官方、最稳定的接口。我们从获取完整的模型和数据集列表开始。这里第一个坑就出现了API返回的列表有时并不完整或者存在分页限制。我们的策略是分批次、多时间点抓取。例如我们在2024年7月9日先抓取了50万个模型的列表作为样本两天后7月11日再执行一次全量抓取最终得到了760,460个模型的元数据。数据集列表则是在7月9日一次性获取的。对于每个模型和数据集我们需要获取其“模型卡”Model Card或“数据卡”Dataset Card中的结构化信息特别是CardData属性和标签Tags。CardData通常包含模型描述、用途、训练数据、基础模型等字段而标签则包含了许可证、任务类型、库依赖等信息。我们优先使用Hugging Face官方Python库huggingface_hub进行批量请求因为它内置了速率限制处理和错误重试机制比手动构造HTTP请求稳定得多。注意直接使用requests库进行大规模爬取极易触发反爬机制导致IP被临时封禁。huggingface_hub库在后台维护了健康的请求间隔是进行此类研究的首选工具。然而API不是万能的。大约有0.5%的模型页面其关键信息如基础模型引用在API返回的元数据中缺失或不完整但在网页版的模型卡中却有描述。对于这部分“顽固分子”我们不得不动用备选方案网页爬虫。我们使用requests获取HTML页面再用BeautifulSoup进行解析专门提取那些API遗漏的文本字段。这个过程非常耗时且解析规则需要针对不同页面结构进行微调因此我们只将其作为API数据的补充而非主要手段。2.2 数据清洗与标准化从混乱到有序的攻坚战原始数据到手才是真正麻烦的开始。如果你认为“基础模型”字段里填写的都会是标准的org/model_name格式那就太天真了。我们遇到了五花八门的表述清理它们是一项艰巨的工程。1. 名称解析与规范化这是最大的挑战。用户填写基础模型或数据集时极其随意。例如一个模型可能将基础模型写为bert-base-uncased短名称https://huggingface.co/google-bert/bert-base-uncased完整URLBased on the awesome BERT model from Google描述性文本bert模糊指代同上或Same as parent中文或非标准引用我们的处理流程是短名称解析首先尝试利用Hugging Face自身的重定向机制。例如访问huggingface.co/bert-base-uncased会被自动重定向到huggingface.co/google-bert/bert-base-uncased。我们通过模拟请求捕获最终的重定向URL来解析短名称。URL提取使用正则表达式从文本中提取可能的Hugging Face资源链接。模糊匹配对于描述性文本我们构建了一个已知模型名称的索引尝试进行关键词匹配如“BERT”、“RoBERTa”、“GPT-2”但这类匹配的准确率有限我们将其标记为“低置信度”关联在后续分析中会区别对待。无效引用处理对于“同上”、“N/A”、“-”等无法解析的引用我们将其记录为“未声明或无法识别”。2. 字段值标准化许可证信息的记录方式也千奇百怪。在原始数据中表示“无许可证”的方式有空列表[]、空字符串“”、字符串“none”、null值以及Python的None。我们将所有这些统一映射为空的Python列表[]。对于多许可证声明我们确保其存储为有序列表以便后续进行兼容性比对。3. 唯一标识符映射为了在构建图谱时高效处理我们为每个解析成功的模型和数据集创建了内部唯一ID映射其Hugging Face内部的唯一ID如621ffdc036468d709f174364并建立从各种名称变体到该ID的映射表。这张映射表是我们整个数据工程的基石。这个过程让我深刻体会到在MLOps中元数据的管理和规范是基础设施中的基础设施。一个混乱的命名和引用习惯会给下游的所有分析和自动化工具带来巨大的成本。3. 现状剖析ML供应链文档的“七宗罪”基于清洗后的数据我们开始系统地审视文档质量。结果发现问题比我们预想的更加普遍和多样。这些文档缺陷不仅让研究者头疼更给想要合规复用模型的开发者挖了无数个坑。3.1 引用模糊与缺失供应链的“断头路”在试图构建“模型A基于模型B训练”这样的关系时高达38.7%的模型在其CardData的“基础模型”字段中要么留空要么填写了无法解析的内容。这直接导致我们无法为这些模型在供应链图谱中找到“上游”。更糟糕的是“模糊引用”。例如一个微调模型只写了“基于BERT”。Hugging Face上有成千上万个BERT变体具体是哪一个是bert-base-uncased还是bert-large-cased或者是某个特定社区发布的bert这种模糊性使得依赖追溯变得几乎不可能。实操心得如果你在发布一个微调模型请在“基础模型”字段中务必使用完整的、可点击的Hugging Face资源标识符格式为organization/model_name。例如写google-bert/bert-base-uncased而不是简单的bert。这是对下游使用者最基本的负责。3.2 许可证信息藏匿与矛盾许可证是合规的生命线但它的声明情况堪称混乱。我们的数据显示约有29.4%的模型在标签Tags和CardData中均未声明任何许可证。这意味着使用这些模型在法律上处于灰色地带。更有趣的是信息不一致。虽然绝大多数99.9%有许可证的模型在标签和CardData中都进行了声明但我们发现了134个案例存在差异。全部都是标签中声明的许可证比CardData中更多。例如CardData里写[“mit”]而标签里却是[“mit”, “apache-2.0”]。这通常是因为上传者后期通过UI添加了标签但未更新模型卡的文本内容。重要提示我们的手动核查发现对于在标签中未声明许可证的热门模型下载量前100仍有15%其实在其他地方如模型卡正文、关联的GitHub仓库README隐藏了许可证信息。其中9个甚至需要跳转到外部GitHub页面才能找到。自动化工具如果只解析标签会严重低估有许可证模型的比例并可能误导使用者。最佳实践是许可证信息应在模型卡正文的显著位置如开头明确写出并同步到许可证标签中。3.3 训练数据描述笼统数据集是模型的“食粮”其来源直接影响模型的偏见、性能和合规风险。然而超过40%的模型在文档中对其训练数据的描述极为笼统例如“使用公开数据集训练”、“来自网络文本”。仅有约22%的模型提供了具体的数据集名称或可追溯的链接。当训练数据是混合数据集时情况更糟几乎没有人能完整列出所有组成部分及其比例。带来的问题假设一个文本生成模型被用于商业产品后来被发现其训练数据中包含了大量未经许可使用的版权书籍。如果文档中只写了“来自网络”开发者根本无法在选用模型时进行有效的合规风险评估。这种信息不透明将风险完全转嫁给了下游使用者。3.4 模型卡模板的滥用与空白Hugging Face提供了优秀的模型卡模板包含“预期用途”、“局限性”、“偏见”、“训练数据”等章节。但很多用户只是机械地填充甚至直接留空。我们观察到大量模型卡仅在“描述”部分写了几句话其他所有结构化字段都是空的。更常见的是“滥用”在“偏见”章节里写“暂无”在“局限性”里写“参见描述”。这使得模板形同虚设失去了其引导提供全面信息的本意。给平台和开发者的建议平台可以考虑引入轻量级的“文档完整性”评分或徽章激励用户填写。对于开发者填写一个完整的模型卡不仅是贡献社区也是对自己工作的总结和风险披露能显著增加模型的可信度和采用率。4. 结构揭秘ML供应链图谱的复杂真相清理好数据修补了漏洞我们终于可以开始绘制供应链图谱了。我们将每个模型和数据集视为节点将“基于...训练”、“使用...数据集”视为有向边从而构建了一个庞大的有向图。对这个图的分析揭示出ML供应链一些反直觉的结构特性。4.1 深度与广度并非想象中那么深一个直观的猜想是随着模型不断被微调再微调供应链会变得非常“深”形成长长的链条。但数据告诉我们事实并非如此。供应链深度有限在我们的图谱中绝大多数依赖链的长度即从一个“叶子”模型回溯到其最原始基础模型的跳数都在3层以内。超过5层的依赖链非常罕见。这意味着常见的模式是一个大型基础模型如Llama-2-7b被直接微调成各种应用模型而这些应用模型较少被再次用作基础进行深度微调。为什么我们分析有以下几个原因技术层面多次微调可能导致灾难性遗忘或性能下降不如直接从更稳定、能力更强的基座模型开始。实用层面开发者倾向于基于最流行、性能最好的“明星”基座模型进行开发而不是一个已经经过他人修改的“二手”模型。文档与信任供应链越深溯源越困难模型行为的不可预测性可能增加降低了使用意愿。供应链的“枢纽”现象图谱呈现出明显的“无标度网络”特征。少数节点明星模型拥有极其庞大的出度被引用数。例如bert-base-uncased,roberta-base,gpt2以及后来的Llama-2-7b-hf它们作为基础模型被成千上万个下游模型引用。与此同时大部分模型节点只有零个或极少的“子节点”即基于它微调的模型。这个结构对开发者的启示当你选择一个模型作为基座时选择这些“枢纽”模型通常是更安全的。它们的社区支持更广遇到的问题更可能已有解决方案且由于其结构稳定微调技巧也更成熟。4.2 循环依赖与数据反馈环路在传统软件中循环依赖是糟糕的设计需要避免。但在ML供应链中我们发现了潜在的、更复杂的“循环”或“反馈环路”这主要是通过数据流实现的。一个典型的场景是模型生成数据 - 数据用于训练新模型。模型A如一个文本生成模型被用于大规模生成合成数据。这些合成数据被收集起来构成一个新的数据集B。数据集B又被用于训练或微调模型C。模型C可能和模型A属于同一家族甚至是模型A的改进版。这样数据在模型间流动形成了非线性的依赖关系。在我们的数据中要明确识别这种关系极其困难因为它很少在文档中明确写明“本数据集由X模型生成”。但这在AI生成内容AIGC爆发的当下正变得越来越普遍。这种环路带来了新的问题如果模型A的训练数据有版权问题那么其生成的合成数据以及用这些数据训练的模型C在法律上处于什么位置目前的许可证体系几乎无法回答这个问题。4.3 复合模型与架构依赖除了简单的“微调”关系现代模型架构引入了更复杂的依赖。例如MoE混合专家模型一个模型内部由多个“专家”子模型组成。在Hugging Face上这些子模型可能本身就是独立的、可下载的模型实体。那么MoE模型与其专家子模型之间是一种新型的“组成”依赖。集成模型将多个模型的预测结果进行组合。其文档中应列出所有组成模型但这在实践中很少被完整记录。模型融合/嫁接将不同模型的部分组件如编码器、解码器组合成一个新模型。这些关系在当前以“基础模型”字段为核心的文档规范下很难被准确表达。供应链图谱需要扩展新的边类型来描述这些更丰富的依赖关系。5. 许可迷局ML组件的合规“雷区”如果说文档是“地图”那么许可证就是“交通规则”。地图不清已经够麻烦规则再混乱或冲突那就寸步难行了。我们对76万个模型的许可证标签进行了统计分析并深入探查了上下游模型间的许可证兼容性问题。5.1 许可证生态分布百花齐放与未知迷雾我们首先将所有许可证归类。ML领域的许可证大致可分为三类传统开源软件许可证如MIT、Apache-2.0、GPL系列。它们设计时并未考虑模型权重、训练数据等ML特有元素。知识共享许可证如CC-BY-4.0、CC-BY-SA-4.0。常用于数据集但用于模型时其条款特别是关于“演绎作品”的定义的解释存在模糊性。ML专用许可证如OpenRAIL系列、Llama 2 Community License、BigScience OpenRAIL-M等。这些许可证通常包含针对AI的特定条款例如使用限制禁止用于非法、有害内容、商业限制用户规模上限、竞争限制禁止用输出训练竞争模型等。统计发现MIT许可证是绝对主流在声明了许可证的模型中MIT许可证占比超过35%。它极其宽松几乎允许任何用途是开发者的首选。Apache-2.0紧随其后占比约25%。它与MIT类似宽松但包含了明确的专利授权条款对大企业更友好。ML专用许可证迅速崛起以OpenRAIL为代表的一系列许可证在2022年之后发布的新模型中占比显著提升特别是在大语言模型领域。这反映了社区对AI伦理和滥用风险的关注。“未知”与“自定义”占相当比例约15%的声明许可证属于“其他”类别其中很多是自定义许可证Custom License。这些许可证文本往往很长且需要人工仔细阅读才能理解其限制自动化合规检查难度极大。多许可证声明增多约8%的模型声明了多个许可证如[“mit”, “apache-2.0”]。这通常意味着使用者可以任选其一遵守。这增加了灵活性但也要求使用者明确做出选择并记录。5.2 上下游许可证兼容性冲突这是最核心的合规风险点。当你微调一个模型时新生成的模型子模型的许可证必须与其基础模型父模型的许可证兼容。我们分析了所有能明确建立父子关系的模型对约12万对检查其许可证兼容性。我们采用了一个保守的规则如果子模型的许可证比父模型更严格限制更多则视为潜在冲突。例如父模型使用MIT极宽松子模型使用GPL-3.0强传染性。理论上子模型开发者有权在GPL下发布其“修改版本”。但关键在于子模型是否构成了GPL意义上的“衍生作品”这在法律上尚无定论但为安全起见许多企业法务会将其视为风险。父模型使用Apache-2.0子模型使用自定义许可证禁止商业使用。这明显增加了限制可能违反Apache-2.0关于“允许再许可”的精神尽管Apache-2.0允许添加附加限制但需明确说明。“许可证降级”父模型使用CC-BY-SA-4.0要求相同方式共享子模型使用MIT无此要求。这直接违反了CC-BY-SA的“相同方式共享”条款是明确的冲突。我们的发现令人担忧在具有明确父子关系和许可证声明的模型对中约有5.1%存在这种“许可证收紧”的潜在冲突。其中大部分是从宽松许可证MIT/Apache转向具有商业限制的ML专用许可证。给模型开发者的血泪教训在发布一个微调模型前请务必检查你所用基础模型的许可证。你的模型许可证不能强加比基础模型许可证更严格的限制。最安全的做法是继承父模型的许可证。如果你必须使用不同的许可证请确保它是与父许可证兼容的、且不会增加额外限制的。例如从MIT出发你可以安全地选择Apache-2.0因为Apache包含专利条款可视为一种“附加许可”而非限制但你不能选择GPL或禁止商业使用的许可证。5.3 命名要求与归属缺失一些许可证特别是Creative Commons系列和部分开源许可证明确要求在使用作品时保留原作者署名。例如CC-BY-4.0要求提供原作者姓名、许可证名称、指向原作品的链接并说明是否进行了修改。我们在手动审查热门模型时发现许多基于CC-BY数据集训练的模型在其模型卡中完全没有提及数据集的来源更不用说提供完整的署名信息了。这直接违反了许可证条款。同样一些基于GPL模型微调的模型也没有在其发布包中包含必要的GPL许可证文本。实操建议在你的模型卡中设立一个清晰的“致谢”或“归属”章节。列出所有使用到的基础模型、数据集、代码库并附上其原始链接和许可证。这不仅是为了合规也是一种学术和工程上的规范。6. 给从业者的行动指南与未来展望面对这样一个文档不全、结构复杂、许可混乱的ML供应链生态作为一名一线开发者或团队负责人我们该如何应对以下是我从这次大规模分析中提炼出的几点核心建议。6.1 模型选用者的尽职调查清单在你决定将一个Hugging Face模型引入你的项目前请务必完成以下检查溯源检查明确它的“基础模型”是什么点击链接确认该模型确实存在。如果基础模型不明确将其视为高风险项。你无法评估其继承的技术债务和合规风险。尝试追溯2-3层理解其“技术血脉”。许可证审查确认声明首先检查模型标签和模型卡顶部的许可证声明。如果缺失去关联的GitHub仓库、论文或作者主页寻找。理解条款不要只看许可证名称。对于MIT/Apache基本可放心使用。对于GPL评估其“传染性”对你的项目尤其是商业项目的影响。对于ML专用许可证如OpenRAIL务必仔细阅读全文重点关注使用限制Usage Restrictions禁止用于哪些领域如犯罪、歧视、军事商业限制Commercial Restrictions是否有用户数、营收规模的上限归属要求Attribution如何正确署名再分发要求Redistribution如果你分发你的微调版本需要遵守什么兼容性分析如果你要基于此模型进行微调或商用检查其许可证是否与你计划的用途及后续分发许可证兼容。文档与质量评估模型卡是否完整是否描述了局限性、偏见和预期用途训练数据是否有说明如果数据来源模糊需警惕偏见和版权风险。查看社区的讨论、Issues和Pull Requests了解模型的活跃度和已知问题。6.2 模型发布者的最佳实践如果你要向Hugging Face发布模型或数据集请做好社区的“好公民”提供完整的模型卡认真填写每一个字段尤其是“训练数据”、“局限性”和“偏见”。坦诚的说明比华丽的营销更能赢得长期信任。明确且规范的引用在“基础模型”字段使用完整的org/model_name格式。如果是基于论文实现引用论文。如果使用了多个组件一一列出。选择并明确声明合适的许可证如果希望被广泛使用选择MIT或Apache-2.0。如果涉及敏感技术或有伦理考量选择一个合适的OpenRAIL许可证。绝对不要使用比你所依赖组件更严格的许可证。将许可证全文或链接放在模型卡开头并在标签中正确添加。提供可复现性信息尽可能提供训练脚本、超参数配置和精确的环境依赖。这能极大提升模型的价值。6.3 对平台与工具构建者的呼吁当前的挑战单靠开发者自觉难以根本解决需要平台和工具的支持增强元数据规范与验证平台可以在模型上传时对“基础模型”字段进行有效性校验检查链接是否存在对许可证标签提供标准化下拉菜单选择并鼓励使用SPDX许可证标识符。构建供应链可视化与审计工具开发能自动绘制模型依赖图谱的浏览器插件或在线工具并高亮显示潜在的许可证冲。这能帮助开发者直观地理解依赖关系。推广SBOM软件物料清单概念至ML领域为ML模型生成标准的“物料清单”强制列出所有组件基础模型、数据集、库及其版本和许可证。这应是模型发布的一部分。开发许可证兼容性检查器类似于FOSSology或ScanCode for ML能够自动解析模型及其依赖的许可证并报告潜在的不兼容风险。ML供应链的复杂性是技术发展的必然结果。我们的分析揭示的种种问题并非为了指责某个平台或开发者而是为了清晰地描绘出我们当前所处的阶段。混乱往往伴随着巨大的机遇。那些能率先在团队内部建立ML组件治理规范、能熟练进行供应链风险排查、能清晰发布合规模型的组织和个人将在未来越来越注重安全、合规和可解释性的AI时代建立起显著的优势。这条路不容易但值得从现在就开始走。