企业官网建设流程全解析

1. 事件背景：wikiHow 起诉 OpenAI，AI 训练数据版权问题再次被推到台前

2025 年初，知名在线教程网站 wikiHow 正式对 OpenAI 提起诉讼，核心指控是 OpenAI 未经授权抓取其平台上的大量文章，用于训练 GPT 系列模型。wikiHow 在诉讼中主张，OpenAI 在模型训练阶段使用了数量庞大的 wikiHow 内容，却没有获得许可、没有付费、也没有给予合理的署名，已经构成大规模版权侵权。

这一事件并不是孤例。最近几年，OpenAI 和其他大模型公司被内容方起诉的案例已经不少，比如新闻媒体、图片社区、作家协会、代码托管平台都陆续发起过类似诉讼。但这次的不同之处在于，wikiHow 是一个以“步骤式教程”为核心的内容平台，内容量极大，且大量文章属于“说明性文本”。这类文本在训练语料中往往被视为有价值的高质量“程序性知识”，因此对于训练模型理解人类操作流程、指令遵循、任务拆解有较为直接的作用。

从开发者的视角来看，这件事真正值得关心的不是单纯的新闻热度，而是它背后牵扯出的几个核心问题：

• 大模型公司训练数据到底从哪来？
• 爬取公开网页内容用于训练，是否属于“合理使用”？
• 模型学会了某个平台的内容，最终生成结果和原文高度相似时，责任怎么算？
• 普通开发者在构建数据管道、微调模型、发布开源数据集时，应该如何规避版权风险？

本文不站队，也不做法律判断，而是围绕这一事件，从训练数据技术构成、版权争议的主要矛盾、开发者数据合规实践等角度做一次系统梳理。

2. 为什么 wikiHow 类内容对大模型训练很有价值

2.1 大模型训练语料的基本构成

先回顾一下 GPT 这类大模型是怎么炼成的。以目前主流的大语言模型训练流程为例，大致分为三个阶段：

• 预训练：在海量互联网文本上学习语言规律和世界知识。
• 监督微调：用人工标注的指令-回答对，让模型学会服从指令。
• 对齐与偏好学习：通过人类反馈强化学习等方式，让模型输出更符合人类偏好。

其中预训练阶段对数据量的需求最为夸张，动辄需要数万亿 token。这些 token 不可能全部靠人工编写，绝大多数来自公开互联网语料的爬取与清洗。常见的数据来源包括：

• Common Crawl：非营利组织维护的网页抓取数据库，包含数十亿网页。
• WebText / OpenWebText：基于 Reddit 外链质量筛选的网页集合。
• Books3 / 电子书合集：用于提升模型长文本能力。
• 中文语料如 WuDaoCorpora、CLUECorpus 等。

wikiHow 的内容就是典型的网页语料来源之一。它的文章结构稳定、标题明确、段落清晰、步骤编号统一，还带有大量图片说明。从数据清洗角度看，这类页面 HTML 结构规整，正文抽取难度低，噪声少。从训练效果角度看，这类内容帮助模型学习“如何把一件事拆成多步操作”，对指令理解有正向作用。

2.2 wikiHow 内容的特点

wikiHow 目前收录了数万篇教程文章，覆盖生活、技术、教育、健康、娱乐等多个领域。每一篇文章基本都是这个结构：

• 一句话摘要。
• 背景介绍。
• 分步骤操作说明，通常带有编号标题。
• 小贴士和注意事项。

这种格式非常接近“指令-操作-要点”的三段式结构，正好是语言模型学习任务拆解的好素材。当模型在预训练阶段读了很多类似内容后，它生成“如何做某事”类回答时，会自动模仿这种分段、分步骤的语气和结构。这也是为什么很多用户会发现，ChatGPT 在回答“如何系领带”“如何安装软件”这类问题时，输出风格和 wikiHow 有点相似。

这个现象本身不算问题，但如果模型输出的内容在表述、结构、细节上和原文高度重合，就可能触及版权争议的边界。wikiHow 方面的主张正是如此：OpenAI 不仅使用了它的文章训练模型，而且在某些场景下模型生成的回答可以追溯到 wikiHow 原文的表达方式。

2.3 训练数据中的“高质量文本”筛选逻辑

大模型公司在构建预训练数据集时，通常会对爬取到的网页做质量打分。打分规则一般包括：

• 文本长度足够，太短的内容会剔除。
• 语法正确度较高，机器翻译痕迹明显的内容降权。
• 信息密度大，比如操作类、教程类、百科类文本得分较高。
• 平台权威度，例如百科、政府网站、教育机构网站会有更高的保留概率。

wikiHow 这类站点在这些维度上都容易拿到高分，所以被保留进最终训练语料的概率很高。也就是说，即便 OpenAI 没有专门针对 wikiHow 做定向抓取，只要其通用爬虫抓过这个域名，并且语料筛选逻辑给它打了高分，它的文章就已经可能进入训练集。

3. 版权争议的核心：爬取、训练与生成三个环节的边界

3.1 三个环节需要分开看

要理解这场诉讼，不能把“爬取网页”和“训练模型”混为一谈。整体上可以分为三个环节：

wikiHow 起诉 OpenAI 时，重点指控的是前面两个环节，尤其是“未经许可的复制与使用”。在版权法框架下，训练模型时把整篇受版权保护的文章复制下来，并且用于建设一个商业模型，这是原告方最核心的不满。

3.2 “合理使用”是一个关键争论点

在美国版权法律体系中，合理使用是一个重要的抗辩理由，用来平衡版权人利益和公共创作自由。法院在判断是否构成合理使用时，一般会看四个因素：

• 使用的目的和性质，例如是商业使用还是非营利教学。
• 被使用作品的性质，例如是事实性作品还是创造性作品。
• 使用部分占原作品的比例。
• 使用行为对原作品潜在市场的影响。

OpenAI 类的公司通常会主张：大模型训练属于“转换性使用”，模型并没有直接复制文章发布，而是从海量语料中学习模式和知识，这更像人类阅读后写新文章，因此应当被认定为合理使用。

而 wikiHow 这类内容方则认为：抓取全文复制后用于商业训练，既不是用户个人阅读，也不是新闻评论式的引用；更重要的是，如果模型可以直接回答“如何做某事”，用户可能不再需要访问 wikiHow，这对原网站流量和广告收入构成直接替代。因此不应被认定为合理使用。

这两套说法的核心矛盾，本质上是对“模型训练是否属于转换性使用”这一问题的不同解释。目前各国法院尚未形成统一判例，这起诉讼可能会为后续同类案件提供重要参考。

3.3 “输入侵权”还是“输出侵权”

版权诉讼中，原告通常需要证明被告存在侵权行为。对于 AI 训练而言，存在两种可能的侵权路径：

• 输入侧侵权：复制原文进入训练数据集，本身构成未经授权的复制。
• 输出侧侵权：模型生成的结果与原文构成实质性相似，甚至照搬原文段落。

从举证难度来看，输入侧侵权更好证明，因为只要数据集中存在受版权保护的原文片段，复制行为就很容易成立。输出侧侵权则比较难证明，因为模型参数中并不直接存储原文，生成结果与原文相似到什么程度才算侵权，需要逐案分析。

wikiHow 在其诉讼材料中，比较聪明地把两条路径都提了：既指控 OpenAI 未经许可复制文章进入训练集，也举了模型输出内容与 wikiHow 原文相似的例子。这样一来，无论法院在“合理使用”问题上怎么判断，原告都有机会继续主张权益。

4. 从开发者视角看：AI 训练数据合规是一个绕不开的工程问题

4.1 不只是法律问题，也是工程问题

很多开发者觉得版权诉讼是法务关心的事情，和写代码没有关系。但实际上，数据合规问题已经越来越深入地影响机器学习工程的方方面面：

• 如果你用 Hugging Face 下载数据集，数据集的 License 决定了你能不能在商用项目里使用它。
• 如果你自己写爬虫收集训练数据，爬虫协议、robots.txt、网站服务条款都是需要考虑的约束。
• 如果你把模型部署成商业 API，一旦训练数据和生成效果和某个版权方的内容高度重合，被诉风险会显著增加。
• 如果你在公司内部做模型微调，训练数据可能涉及客户隐私或供应商合同限制。

因此，数据合规不应该到最后被起诉时才想起来，而是应该贯穿数据集构建、数据清洗、模型训练、模型上线全流程。

4.2 常见的数据来源与风险等级

为了方便理解，我整理了一个常见数据来源的风险参考表。请注意，这只是一个工程经验层面的梳理，不构成正式法律建议：

开发者在选择数据来源时，不应该只看数据的数量和质量，还要重点确认三件事：

• 数据的 License 是什么？
• 允许的用途范围是什么？
• 是否包含个人信息或敏感内容？

4.3 爬虫技术本身没有问题，但边界要清晰

爬虫本身是一项中性技术，搜索引擎、数据分析、学术研究都需要爬虫。但这并不意味着可以随意抓取所有网页并自由使用。实际操作中，至少要注意这几个边界：

第一，robots.txt 是一个网站对爬虫的授权声明。虽然它在技术上不是强制约束，但在商业项目中，违反 robots.txt 抓取内容并用于训练，会增加法律风险。

第二，网站服务条款（Terms of Service）通常会写明是否允许抓取、是否允许将内容用于模型训练。即使页面内容是公开的，公开访问不代表可以自由复制和再加工。

第三，抓取频率过高可能构成对服务器资源的不当占用，这也是很多反爬虫诉讼的重要事实依据。

对于个人学习和小型实验，抓取少量页面做分析问题不大；但对于生产环境和商业产品，必须确保数据来源合法合规。

4.4 模型输出端的溯源与过滤

除了数据输入端，模型输出端同样需要建立合规意识。如果你基于一个版权敏感的数据集微调模型，那么模型生成的内容很有可能带有训练数据中的表述痕迹。这种情况下，可以考虑做以下几件事：

• 在推理层增加内容过滤规则，对与特定来源高度相似的输出做拦截。
• 对模型做去重后处理，降低连续多段原文输出的概率。
• 为生成内容增加提示，明确信息来源不是原始平台，避免“原创性”混淆。
• 进行定期抽样评估，检查模型是否出现大段复制某个受保护来源的情况。

从工程角度看，这相当于给输出加一道“安全阀”，虽然不能根治版权问题，但可以降低实际纠纷的风险。

5. 合规数据管道构建：一个最小可落地的实践方案

5.1 目标与场景

下面提供一个数据管道构建示例。它的目标不是教大家去爬取 wikiHow 之类的内容，而是展示一套“数据获取-记录-清洗-授权检查-版本控制”的合规流程。适用场景包括：

• 准备训练数据。
• 构建 RAG 检索知识库。
• 做开源数据集的整理发布。

示例环境以 Python 为主，依赖库包括 requests、pandas、datasets。核心思路是：所有数据来源必须可追溯，所有数据文件必须带 License 元信息，所有清洗操作必须可重复。

5.2 项目结构

data-pipeline/ ├── raw/ # 原始数据文件 ├── processed/ # 清洗后的数据文件 ├── metadata/ # 数据元信息与 License 记录 ├── scripts/ │ ├── fetch_source.py # 数据获取脚本 │ ├── clean_data.py # 数据清洗脚本 │ └── build_dataset.py # 构建训练数据集脚本 ├── data_manifest.json # 数据清单 └── README.md

5.3 记录数据来源与授权信息

很多开发者整理数据集时，只保留了数据内容，却没有记录这个数据的来源、抓取时间和授权情况。一旦后续需要商用或者应对版权质疑，就很难自证清白。比较好的做法是每一批数据都配一个数据清单。

示例 data_manifest.json：

{ "dataset_name": "example_tutorial_data", "version": "1.0.0", "created_at": "2025-02-10", "sources": [ { "name": "example-open-data", "url": "https://example.org/open-dataset", "license": "CC BY 4.0", "allowed_use": "commercial", "downloaded_at": "2025-02-08", "notes": "官方网站提供的开放下载链接" } ], "processing_steps": [ { "name": "remove_duplicates", "description": "去除重复文本", "script": "scripts/clean_data.py" } ] }

把这份清单放在项目根目录，和数据集本身一起纳入版本管理。后续无论是自己复盘，还是团队协作，甚至是面对授权查验，都能快速给出完整的数据来源链条。

5.4 数据获取脚本示例

以从开放 API 获取数据为例，下面这个脚本的思路是：先检查 API 服务条款，再记录抓取时间，最后保存原始响应。

# 文件路径：scripts/fetch_source.py import json import time import requests from datetime import datetime API_URL = "https://api.example.org/v1/items" HEADERS = { "User-Agent": "data-pipeline/1.0 (research purpose only)" } def fetch_items(limit=100): items = [] params = {"limit": limit} resp = requests.get(API_URL, headers=HEADERS, params=params, timeout=30) resp.raise_for_status() data = resp.json() items.extend(data.get("items", [])) return items def save_with_meta(items, source_name): timestamp = datetime.utcnow().isoformat() meta = { "source": source_name, "fetched_at": timestamp, "item_count": len(items), "license": "检查 API 服务条款后确认", "raw_file": f"raw/{source_name}_{int(time.time())}.json" } return meta if __name__ == "__main__": result = fetch_items(limit=50) meta = save_with_meta(result, "example_open_api") print(json.dumps(meta, ensure_ascii=False, indent=2))

这个脚本的重点不是爬取技术，而是“记录”。每次抓取，都留下时间戳、来源、数量、授权状态，保证数据可追踪。

5.5 数据清洗与去重脚本

原始数据往往包含大量重复片段、广告文本和无关导航信息。清洗环节要把这些噪声去掉，同时保留与数据质量相关的统计信息。

# 文件路径：scripts/clean_data.py import re import hashlib import pandas as pd def normalize_text(text): # 去除多余空白 text = re.sub(r"\s+", " ", text) # 去除常见广告标记 text = re.sub(r"\[广告\]|Sponsored|Advertisement", "", text, flags=re.IGNORECASE) return text.strip() def deduplicate(df, text_column="text"): # 使用文本哈希进行快速去重 df["text_hash"] = df[text_column].apply( lambda x: hashlib.md5(x.encode("utf-8")).hexdigest() ) df_dedup = df.drop_duplicates(subset="text_hash", keep="first") return df_dedup.drop(columns=["text_hash"]) def main(): input_path = "raw/example_open_api_1700000000.json" output_path = "processed/example_open_api_cleaned.parquet" df = pd.read_json(input_path) df["text"] = df["text"].apply(normalize_text) df = deduplicate(df) df.to_parquet(output_path, index=False) print(f"清洗完成，保留 {len(df)} 条记录") if __name__ == "__main__": main()

清洗环节的目标是让数据达到可训练的基础质量。这里的 normalize_text 只是一个最小例子，实际数据管道中还可以加入语言检测、敏感信息检测、长度过滤等步骤。

5.6 构建可训练数据集

最后一步是把清洗后的数据转换成模型训练框架需要的格式。下面以 Hugging Face datasets 库为例：

# 文件路径：scripts/build_dataset.py from datasets import Dataset, DatasetDict def load_processed_data(path): import pandas as pd df = pd.read_parquet(path) return Dataset.from_pandas(df) if __name__ == "__main__": train_data = load_processed_data("processed/example_open_api_cleaned.parquet") # 切分训练集和验证集 split = train_data.train_test_split(test_size=0.1, seed=42) dataset = DatasetDict({ "train": split["train"], "validation": split["test"] }) dataset.save_to_disk("processed/example_dataset_hf") print(dataset)

到这一步，一个带来源记录、清洗流程、数据清单的数据管道就算完成了。值得注意的是，这个流程并没有加入任何“判断数据是否侵权的魔法逻辑”，它只是通过完整的记录和追踪机制，让数据的合法性更容易被审查。如果数据源本身就没有授权，记录再完整也无法改变侵权事实。因此，采集端的源头把握仍然是第一位的。

6. 常见问题与排查清单

6.1 常见问题表格

6.2 数据合规排查清单

如果你接手一个已有项目，不确定现有数据的版权状态，可以按下面这个清单快速排查：

• 数据集的下载页面是否有 License 说明？
• 如果是从网页抓取，是否记录了抓取时间和对应的 robots.txt？
• 数据是否包含用户生成内容？是否可能包含个人信息？
• 数据是否来自多个来源混合？每个来源的授权状态是否一致？
• 是否有任何一方明确声明禁止将内容用于模型训练？
• 数据清洗过程中是否保留了可追溯的版本记录？
• 模型上线后，是否对输出内容做过相似度抽检？

以上清单不能替代正式的法律审查，但它可以帮助你在日常开发中建立合规意识，避免到了项目后期才发现数据来源埋雷。

7. AI 版权争议对未来技术生态的长期影响

7.1 数据授权模式可能会走向规范化

wikiHow 起诉 OpenAI 这类案件，不管最终判决结果如何，都会推动 AI 行业建立更规范的数据授权机制。目前已经能看到一些趋势：

• 更多内容平台开始发布明确的 AI 训练数据授权条款。
• 出现新的数据授权交易平台，帮助内容方和模型公司达成许可协议。
• 开源社区对数据集的 License 标注越来越重视。
• 大模型公司开始提供训练数据来源说明，比如 OpenAI 曾公布过部分数据构成细节。

对于开发者来说，未来获取训练数据的门槛可能会提高，但合规路径会更加清晰。

7.2 小模型和微调场景的影响

一个容易被忽视的问题是：版权诉讼主要针对的是大公司的大模型，但对做微调和小模型开发的开发者同样有影响。如果你在某个垂直领域微调模型，使用的领域数据来自特定平台，那么这个平台完全可以主张对数据内容的控制权。

比如，一个医疗问答模型使用了某医学知识库的文章做微调，一个法律助手模型使用了某法律数据库的裁判文书。这些知识库的版权方完全可以质疑训练数据的来源合法性。模型大小不是避风港，数据来源才是重点。

7.3 开源模型并不等于数据完全自由

很多初学者有一个误区：开源模型权重就代表可以随意使用，甚至认为模型开源等于训练数据也合规。事实上，模型权重开源主要指的是推理和部署层面的开放性，训练数据是否合规是另一回事。

如果你用了一个开源模型，但用自己的私有数据做了微调，那么你仍然需要为微调数据负责。开源社区里也出现过由于训练数据 License 不一致，导致模型发布者被迫下架模型的案例。

7.4 技术手段不能替代合规流程

有人会想，能不能通过“换个说法”规避版权，比如把原文改写一遍再用。这种做法在法律上的有效性存疑，在工程上也不可持续。改写后的数据可能引入新的错误，还可能被判定为“基于原作品的衍生创作”，仍然受到版权约束。

真正稳妥的路径，还是回到数据源头：优先使用明确授权的数据，记录数据来源，控制数据使用范围。技术手段只能帮助你降低风险，不能替你解决授权问题。

8. 给开发者的几条实用建议

8.1 先做数据审计，再谈模型效果

如果你所在团队正在做一个 AI 产品，第一步不是急着调模型，而是先梳理清楚现有的数据资产：

• 数据从哪里来？
• 为什么可以被使用？
• 如果被质疑，能不能拿出完整的来源记录？

把数据审计当作和模型评估同等重要的工作，而不是可有可无的流程。

8.2 在项目初始化阶段就建立 License 管理

项目一开始就创建一个 LICENSE.md 或者 data_manifest.json，把每一批数据的授权信息写清楚。后续每加入新数据，同步更新。这个习惯在个人项目和公司项目中都适用。

8.3 输出侧加相似度检测

对于面向用户的 AI 应用，可以在生成链路中增加一个相似度检测模块。当模型输出与某个版权敏感来源的文本相似度过高时，自动降级或重写。下面是一个简单的思路示例：

# 输出侧相似度检测示例 from difflib import SequenceMatcher def check_similarity(generated_text, source_text): similarity = SequenceMatcher(None, generated_text, source_text).ratio() return similarity def safe_generate(generated_text, source_texts, threshold=0.7): for source_text in source_texts: score = check_similarity(generated_text, source_text) if score > threshold: return "生成内容与已有来源相似度过高，请修改后输出。" return generated_text

这个示例只是演示思路，实际项目中可以换成 embedding 向量相似度计算、n-gram 重叠检测等手段。

8.4 关注行业动态，不把确定性答案留给未来

AI 版权问题目前没有全球统一的答案。同一个行为在某国可能被判合理使用，在另一个国家可能构成侵权。开发者需要持续关注所在地区的最新案例和监管要求，不要轻易相信“AI 训练是绝对合法”或“AI 训练绝对侵权”的极端说法。

9. 总结与后续学习方向

从 wikiHow 起诉 OpenAI 这一事件出发，本文梳理了 AI 训练数据版权争议的来龙去脉，重点讲解了训练语料构成、合理使用争议、数据爬取边界、输出侧风险，以及开发者如何建立合规数据管道。

下一篇可以继续关注这几个方向：

• 如果判决结果出来，合理使用边界会怎么变化。
• 大模型公司在训练数据披露上是否会更加透明。
• 内容平台与 AI 公司之间是否会形成新的数据授权协议模式。
• 开源社区的数据集 License 治理工具如何演进。

对于正在学习大模型开发的读者，建议把“数据合规”当作和“模型架构”“训练技巧”同等重要的学习模块。模型效果好不好是一时的事，数据来源是否站得住脚，决定了这条路能不能长期走下去。

如果本文对你有帮助，可以收藏备用，后续有新的判例或行业动态，也可以回来对照这份整理继续深入理解。