ShareGPT项目发展历程回顾从Chrome插件到AI数据集演变

如果你关注AI社区里对话数据的流转与再利用，会发现一个有趣的现象：ShareGPT这个项目，并非从一开始就以数据集的形态存在。它最初只是一个解决用户痛点的浏览器工具，后来却逐渐演变为整个领域重要的数据基础设施。这中间的转变，经历了几个清晰而关键的阶段。

一、Chrome扩展阶段（2024年12月–2024年初）

故事要从2024年12月8日说起。当时，Steven Tey和Dom Eccleston发布了一个轻量级的Chrome浏览器扩展，它的目标非常明确：解决用户在ChatGPT网页版里，没法方便地导出完整对话的麻烦。

这个扩展的设计很巧妙，它不依赖任何后端服务，完全在本地工作。其核心流程可以概括为四步：安装后，ChatGPT网页界面右上角会出现一个“Share”按钮；点击它，扩展会自动识别当前对话窗口中的所有消息节点；接着，对每条消息进行角色标注（用户或助手），并按时间顺序序列化为一个JSON对象；最后，将这个JSON提交到ShareGPT的托管服务，生成一个唯一的短链接，用于公开分享。整个过程，对话的元数据，包括时间戳、模型版本、每一轮问答，都被完整地封装进了这个链接里。

二、社区沉淀与数据爬取兴起（2024年中–2024年中）

随着时间推移，数百万条用户分享的对话在 sharegpt.com 上积累起来。由于这些页面是公开可访问的，且结构高度一致，它们很快吸引了研究者和开发者的目光。此时，ShareGPT作为“数据源”的价值，开始超越其最初的工具属性。

于是，一场自发的数据采集开始了。开发者们通过分析网页的HTML结构，找到了每条分享卡片对应的唯一ID和API端点。随后，利用无头浏览器或简单的HTTP客户端模拟请求，就能逐页抓取分享列表和详情页内容。解析响应中嵌入的JSON脚本标签后，原始的对话文本和元信息字段便被提取出来。当然，在这个过程中，大家也会初步过滤掉重复的URL、空对话、包含敏感词或质量过低的回复样本。

三、数据集工程化阶段（2024年下半年起）

当原始爬取的数据量达到百万级别后，问题也随之而来。原始数据分散、格式不一，直接使用效率低下。于是，清洗、去重、格式标准化成了刚需。像 domeccleston/sharegpt 这样的衍生项目应运而生，它们不再提供前端功能，而是专注于将分散的数据构建成可直接用于机器学习任务的数据资产。

这些工程化项目的工作流程相当规范：先将原始爬取的HTML文档批量转换为中间结构（比如Python字典）；然后依据预设规则，剔除包含广告、乱码或单轮无意义问答的劣质样本；接着，通过指纹哈希比对，对跨分享ID的相同对话执行全局去重；最后，将清洗后的数据，按instruction、input、output等字段进行映射，使其完美适配Hugging Face Datasets的标准加载协议。至此，数据完成了从“网页”到“资产”的蜕变。

四、开源数据集分发与下游应用（2025年起）

经过彻底工程化处理的数据集，最终被上传至Hugging Face Hub和GitHub等平台，并采用CC BY-NC 4.0许可协议发布。这时，它的主要消费场景，已经从个人分享彻底转向了模型训练。

如今，这些数据集被广泛用于微调模型的指令跟随能力、构造监督微调样本，以及生成评估基准测试集。一些更精细的数据集版本，还额外标注了对话主题分类、难度等级甚至事实一致性得分，以满足更专业的建模需求。对于使用者来说，流程也变得非常便捷：在Hugging Face搜索“sharegpt”并筛选高星仓库；使用datasets.load_dataset()直接加载远程数据流；检查schema定义确认conversations字段结构；最后调用train_test_split等方法划分数据集即可投入训练。一个工具的生命，就这样在以另一种形式延续和拓展。