关于结合 AIGC / LLM 技术开展智能化开源社区治理与运营工作的探索

[will-ww]

大概在 2022 年的时候，X-lab 整体关注的还是如下图所示的情景：

今天，离 ChatGPT 发布已经过去一年多的时间，AIGC / LLM 技术已经得到了极大的关注，无数基于该技术的研究如火如荼。这让我们又重新想到了上面这幅图的左半部分。Hypertrons（自动化协作机器人）在大模型技术的加持下，势必获得全新的审视。因此开辟此帖，探索大模型技术对开源社区生产、治理与运营的新方向。

当下的人工智能模型，我们大致可以分为两个类别：

• 决策式 AI：擅长对新的场景进行分析、判断和预测，例如人脸识别、推荐系统、风控系统、精准营销等
• 生成式 AI：擅长自动生成全新的内容，例如文本、图片、音视频等

AIGC 时代 （ChatGPT --> API 系统 --> 插件系统 --> Sora）已经开启，LLM 技术（Transformer --> GPT --> CLIP）飞速发展。在这样一个背景下，同样也给开源领域的学术研究、项目开发、服务运营、商业变现等事务，带来了巨大的机会，面向开源领域提供一个集“咨询、研发、运营”于一体的垂直大模型基础设施，具有相当的吸引力。我们在教育领域也做过类似的初步探索。

部署开源领域垂直大模型，可以做非常多的赋能与创新任务：

• 咨询
  • 开源组件选型
  • 开源趋势情报
  • 开源供应链风险评测
  • 基于开源组件的产品研发规划
  • 开源研究课题挖掘与方案设计
• 研发
  • DevOps 全流程 AI 赋能
  • Issue 标签自动化
  • 代码理解与 PR Review
  • 协作自动化与 RPA
  • 研发效能提升
• 运营
  • 开源社区问答助手
  • 内容运营文案生成
  • 开发者关系运营
  • 个性化激励机制
  • 个性化推荐系统

上述这些任务，都能够通过大模型技术在不同层面增强甚至取得突破性进展，还能落地回 Hypertrons 和 HyperCRX 这样的产品中，也为后续企业研发数字化的通用需求，做好技术积累与场景验证。

这是个充满希望的时代，这也是个令人绝望的时代。

[PureNatural]

部署开源领域垂直大模型，可以做非常多的赋能与创新任务：

最近读了一篇达摩院NLP团队去年8月份发布的《指令微调的电商领域大模型》，受益匪浅。

在下次轮到我做学术分享时，我会对该论文讲解

该论文将整个电商领域的数据集划分为100多个任务数据集，主要任务划分情况如下：

然后使用指令微调的方式，让模型逐一去学习这些任务，最后实验取得不错的效果

指令微调数据需要包含任务描述、任务指令、输入句子、候选标签（可选）、输出限制（可选）、输出结果

数据集有一部分来自于公开成熟的数据集，因为电商领域本身研究者参与的也很多，故产生了很多标准数据集
还有一部分没有标签的数据通过ChatGPT和人工标注的方式产生

那么放到开源领域我认为我们一下提出100多个任务数据集显然是很难的，可以把现有已经形成的数据集作为训练的一部分，这与我之前一直想制作的问答任务数据集也是相关联的。

同时数据集的制作又于OpenPerf有着关联性，OpenPerf中我们提出的9个任务，也可以选择合适的一部分作为指令微调数据集中的一个任务。如何构建开源领域的垂直大模型也会是我后面主要工作的一个方向。

[will-ww]

本次分享的视频：https://www.bilibili.com/video/BV1HF4m1V7sU/

同时，网上还有几个相关的资源：

• EcomGPT：指令微调的电商领域大模型
• 电商领域指令微调大模型（B 站视频）

领域指令数据集是提高通用大模型在领域任务上的泛化能力的关键，方法就是在通用大模型上进行指令微调，而微调后的大模型就可以称作领域大模型了，需要经过如下步骤：

• 识别并定义出领域任务：例如电商场景（领域）任务（如品牌识别，评价解析，广告文案生成等）
• 构造领域指令数据集：
  • 结构：指令（任务描述、任务指令、输入句子）+ 训练任务/数据集（held-in） + 评估任务/数据集（held-out）
  • 方法：公开的领域任务数据集 + 基于公开任务数据构造的原子任务数据集
  • 原子任务数据集是在对领域数据类型（如产品信息、用户对话、用户评论和搜索查询等）考察和抽象的基础上，将它们作为一种基础数据，进而构造出一批原子任务（如实体片段识别，实体分类等）
  • 原子任务涵盖了各种基本的语义理解能力，这些原子任务可以看做任务链任务（Chain of tasks）
  • 需要区分：领域任务、原子任务、任务链任务

这样围绕“任务”这个关键概念，可以从不同的视角出发开展工作：

• 从应用场景出发：领域任务
• 从数据类型出发：原子任务
• 从操作粒度出发：任务链任务

当上面的部分说法，会让人有一定的误解，咱们可以重新构建一套框架体系和命名规范，把这件事情说清楚。

[will-ww]

联系到咱们去年做的 OpenPerf，感觉还有有不少相似的地方：

• OpenPerf 中的“通用任务类型”，比较像 EcomGPT 中的“原子任务”，是从数据类型和特征的视角出发的
• OpenPerf 中的具体任务，就是 EcomGPT 中的“领域任务”，是从领域场景的视角出发的

这样从构建开源领域大模型的视角看，对 OpenPerf 还是有很多启发的，这样 OpenPerf 存在的价值就有多个了：

• 原有价值点1：定义开源领域的数据科学任务，及其对应的基准体系（任务、数据、模型、评价）
• 原有价值点2：推动这些数据科学任务上面的算法和模型性能
• 新增价值点1：为构建开源数字生态领域大模型（GPT）提供了一套工程方法
• 新增价值点2：为构建原有 OpenPerf 提供了新的思路（例如任务增强和数据增强）

总之，基准测试体系的构建和领域大模型的构建，应该可以相互启发与促进，这也体现了大模型作为一种解决问题的范式，在推动科研与工程方面，所起到的积极效果。

基于上面的讨论，咱们就有了一个新目标了：OpenPerf 2.0 的构建与投稿。

[PureNatural]

补充：
EcomGPT仓库链接https://github.com/Alibaba-NLP/EcomGPT
EcomGPT模型下载地址https://www.modelscope.cn/models/iic/nlp_ecomgpt_multilingual-7B-ecom/summary

该论文目前只开源了12个测试数据集https://github.com/Alibaba-NLP/EcomGPT/tree/main/data/ecom_instruct_v1
可以参考

[PureNatural]

前期工作：
类比EcomGPT,我会搜索现在网络上关于开源数字生态领域已经公开的领域任务数据集，不定时更新该评论，暂时的想法是能形成10个左右领域任务数据集，构成20以上的原子任务数据集，随即展开实验。
分类任务：
https://github.com/nlbse2024/issue-report-classification
https://github.com/collab-uniba/Senti4SD
https://github.com/s2e-lab/BERT-Based-GitHub-Issue-Classification

[PureNatural]

类似机器人分类任务的数据集，根据毕博的工作，可能要考虑10多个特征才能提高预测准确率，输入的特征内容较多，在大语言模型中(不考虑多模态)，指令输入只能是一段文本，可以将该任务作为基础任务去尝试训练，将其转为问答任务：

例如。在微调阶段，直接输入某某账号是否为机器人账号，模型输出是或者否，也就是说让大模型直接去学习答案。 这样做的话，如果将机器人分类数据集分为训练集和测试集，那么大模型在测试集的表现会很差，因为它只学到了训练集的答案，没有学到测试集的。

那么，参考EcomGPT，将分类任务转为问答任务，如果提问的GitHub账号是模型学习过的，那么，模型可能就会回答正确答案，这样也可以说成是跨任务的泛化能力。

不过，其实我觉得构建问答数据集本身就很灵活，只要保证答案的准确性，多数任务都能转化为问答对的形式。
当然，这只是初步的想法， 后续还要看模型的具体效果。

[PureNatural]

分享一个关于大模型可实现NLP任务的博客
https://zhuanlan.zhihu.com/p/644170707

[PureNatural]

类比EcomGPT任务设计的内圈，其中包括dialogue、product infor、review、product title、search query、address等等业务场景。我发现这些场景都包含自己独有的自然语言，address就是比较特殊的文本，所以结合GitHub上的文本，我大致先按issue、readme、discusstion分了一下，主要情况如下：

• issue

  • 分类任务
    1. issue分类 https://github.com/nlbse2024/issue-report-classification
    2. issue comment 评论文本情感分类https://github.com/collab-uniba/Senti4SD
    3. issue title 文本情感分类
    4. issue comment 分类https://github.com/s2e-lab/BERT-Based-GitHub-Issue-Classification
    5. issue可回答性预测，确定一个问题是否可以根据给定的文本或知识库得到直接的答案
  • 提取任务
    1. issue回复答案匹配
    2. issue title 实体边界检测
    3. issue 回复外部链接提取
  • 生成任务
    1. issue title生成
    2. issue 回复生成
    3. issue 分类生成
    4. issue title 改写

• readme

  • 分类任务
    1. 实体类型分类
  • 提取任务
    1. readme文档纯文本内容提取
    2. readme 实体边界检测
  • 生成任务
    1. readme文档摘要内容生成
    2. 基于readme文档的问题生成
    3. 基于readme文档的答案生成
    4. 基于readme文档的issue title生成

• discusstion
  数据获取方式（https://github.com/orgs/community/discussions/23483）

  • 分类任务
    1. discusstion 问题类型
  • 提取任务
    1. 实体边界检测
    2. discusstion 回复答案匹配
    3. discusstion 回复外部链接提取
  • 生成任务
    1. discusstion title 生成
    2. discusstion 回复生成

todo...

头脑风暴先列一部分，不一定都会采用～

[PureNatural]

由于需要discusstion的数据作为一部分指令数据集，其实GitHub的较多仓库都没有使用该功能，我搜集了一些材料，以下是一些积极使用discussion的仓库，后续可能会针对以下仓库重点挖掘数据
https://github.blog/2022-01-13-how-five-open-source-communities-are-using-github-discussions/
https://docs.github.com/en/discussions#communities-on-githubcom-using-discussions-1
https://resources.github.com/devops/process/planning/discussions/