使用Tensorflow和公共数据集构建预测和应用问题标签的GitHub应用程序

预告片：构建一个标记问题并将其作为产品发布的模型！

在GitHub存储库上安装此应用程序。

https://mlbot.net/

动机：难以捉摸，完美的机器学习问题

作为数据科学家的朋友和同事会将理想的预测建模项目描述为以下情况：

• 有大量数据，已经标记或可以推断标签。
• 数据可用于解决实际问题。
• 问题涉及热衷的域名或想要解决的问题是自己的，可以成为第一个客户。
• 有一个平台，数据产品可以覆盖大量的受众，并提供收集反馈和改进的机制。
• 可以用最少的费用和时间来创建它，希望使用熟悉的语言和工具。
• 如果产品成功，有一种方法可以将产品货币化。

输入GH-Archive和GitHub应用程序：数据遇到机会的地方

提出了一个认为满足上述标准的数据集，平台和域名！

数据集：GH-Archive。

https://www.gharchive.org/

GH-Archive通过从GitHub REST API中摄取大部分这些事件，从GitHub记录大量数据。这些事件以GSON格式从GitHub发送到GH-Archive，称为有效负载。以下是编辑问题时收到的有效负载示例：

此示例的截取版本

鉴于GitHub上的事件类型和用户数量，有大量的有效负载。这些数据存储在BigQuery中，允许通过SQL接口快速检索！获取这些数据非常经济，因为当第一次注册帐户时，Google会为您提供300美元，如果已经拥有一个，则成本非常合理。

由于数据是JSON格式，取消嵌套此数据的语法可能有点不熟悉。使用JSON_EXTRACT函数来获取需要的数据。以下是如何从问题有效负载中提取数据的示例：

用于存储在BigQuery上的GH-Archive数据的示例查询语法

要注意不仅仅是问题数据 - 可以检索几乎任何发生的事情的数据在GitHub上！甚至可以从BigQuery中的公共存储库中检索大量代码。

https://github.com/hamelsmu/code_search/blob/master/notebooks/1%20-%20Preprocess%20Data.ipynb

平台：GitHub Apps和GitHub Marketplace

GitHub平台允许构建可执行许多操作的应用程序，例如与问题交互，创建存储库或修复拉取请求中的代码。由于应用程序所需的全部内容是从GitHub 接收有效负载并调用REST API，因此使用选择的任何语言编写应用程序，包括python。

GitHub市场提供了一种在可搜索平台上列出应用程序并向用户收取每月订阅费用的方法。这是将想法货币化的好方法。甚至可以托管未经验证的免费应用程序，以收集反馈和迭代。尽管有这些公共数据集，但使用机器学习的GitHub应用程序并不多！

端到端示例：使用机器学习自动标记GitHub问题

自动标记问题有助于组织和查找信息

为了展示如何创建应用程序，将引导完成创建可自动标记问题的GitHub应用程序的过程。此应用程序的所有代码（包括模型训练步骤）都位于GitHub存储库中。

https://github.com/hamelsmu/MLapp

第1步：注册应用程序并完成先决条件。

首先需要设置开发环境。完成本文的步骤1-4 。不需要阅读“Ruby编程语言”部分或步骤4之外的任何步骤。确保设置Webhook秘密，即使该部分是可选的。

请注意GitHub应用和Oauth应用之间存在差异。但是如果正在阅读文档，那么区分是很好的。

第2步：使用python轻松与GitHub API进行交互。

应用需要与GitHub API进行交互才能在GitHub上执行操作。在选择的编程语言中使用预构建的客户端非常有用。虽然GitHub上的官方文档展示了如何使用Ruby客户端，但还有许多其他语言的第三方客户端包括Python。本教程将使用Github3.py库。

作为应用程序与GitHub API连接的最令人困惑是身份验证。有关以下说明，请使用curl命令，而不是文档中的ruby示例。

首先必须通过签署JSON Web令牌（JWT）来作为应用程序进行身份验证。签署JWT后使用它作为应用程序安装进行身份验证。在作为应用程序安装进行身份验证后，将收到一个安装访问令牌，使用该令牌与REST API进行交互。

作为应用程序的身份验证是通过GET请求完成的，而作为应用程序安装进行身份验证是通过PUT请求完成的。尽管示例CURL命令中说明了这一点，但它是在开始时错过的一个细节。

即使将使用Github3.py库，了解上述身份验证步骤也很有用，因为可能希望使用请求库自己实现不支持的路由。因此最终在Github3.py库中编写了一个名为mlapp的瘦包装器，以帮助与问题进行交互，这里定义了问题。

以下是可用于创建问题，发表评论和应用标签的代码。代码也可在此笔记本中使用。

https://github.com/hamelsmu/MLapp/blob/master/notebooks/GitHub-api-example.ipynb

上面的代码在GitHub上创建了这个问题

可以在此处查看此代码创建的问题。

https://github.com/hamelsmu/simple_flask_app/issues/1

第3步：获取并准备数据。

如前所述使用BigQuery上托管的GH-Archive来检索问题示例。此外检索人们为每个问题手动申请的标签。以下是用于构建所有这些标签的Pareto图表的查询：

此查询生成的数据可在此电子表格中找到

来自公共数据集的热门问题标签。有一个非常长的尾巴（这里没有显示）。

此电子表格包含整个帕累托图表的数据。问题标签的长尾不是相互排斥的。增强功能和功能标签可以组合在一起。标签的质量和含义可能因项目而异。尽管存在这些障碍，还是决定简化问题并将尽可能多的标签分为三类：功能请求，错误和使用在手动查看前200个标签后构建的启发式问题。此外咨询了大型开源项目Kubeflow的维护人员，作为验证直觉的第一位客户。

尝试创建一个名为other的第四个类别，以便对前三个类别中的项目进行负面样本，但是发现信息很嘈杂，此“其他”类别中存在许多错误，功能请求和问题。因此有限的训练集来，可以归类为或者是问题的功能要求，错误或问题完全。

应该指出的是，训练数据的这种安排远非理想，希望训练数据尽可能地类似于真实问题的分布。然而目标是以最少的时间和费用构建一个最小的可行产品，并在以后进行迭代，因此采用这种方法向前推进。

最后特别注意去除重复问题。解决了以下类型的重复：

1. 同一个回购中同一标题的问题。
2. 无论标题如何，在其正文中具有相同内容的问题。通过仅考虑前75％的字符以及在问题正文中持续75％的字符来删除进一步的重复。

使用此链接查看用于对问题进行分类和重复数据删除问题的SQL查询。不必运行此查询，来自Kubeflow项目的朋友已运行此查询并将结果数据作为CSV文件托管在Google Cloud Bucket上，按照此笔记本中的代码进行检索。原始数据的探索以及数据集中所有字段的描述也位于笔记本中。

https://console.cloud.google.com/bigquery?sq=123474043329:01abf8866144486f932c756730ddaff1

https://github.com/hamelsmu/MLapp/blob/master/notebooks/Issue_Labeling_Model.ipynb

第4步：构建和训练模型。

现在有了数据，下一步是构建和训练模型。决定借用为类似问题构建的文本预处理管道并在此处应用它。此预处理管道清除原始文本，标记数据，构建词汇表，并将文本序列填充到相同长度。

模型有两个输入：问题标题和正文，并将每个问题分类为错误，功能请求或问题。下面是使用tensorflow.Keras定义的模型架构：

关于这个模型的一些注意事项：

• 不必使用深度学习来解决此问题。刚刚使用了为另一个密切相关的问题构建的现有管道，以便快速自我引导。
• 模型架构令人尴尬地简单。目标是让事情尽可能简单，以证明可以使用简单的方法构建真正的数据产品。没有花太多时间调整或试验不同的架构。
• 预计通过使用更先进的架构或改进数据集，这个模型有很大的改进空间。提供的一些提示下一步该博客文章的部分。

评估模型

下面是一个混淆矩阵，显示了模型在三个类别的测试集上的准确性。该模型确实难以对问题进行分类，但在区分错误和功能方面做得相当不错。

由于测试集不能代表所有问题（因为只将数据集过滤到了可以分类的那些），上面的准确度指标应该用一些salt。通过收集用户的明确反馈来缓解这个问题，这能够非常快速地重新训练模型和调试问题。将在后面的部分讨论显式反馈机制。

做出预测

以下是示例的模型预测。此笔记本中提供完整代码。

https://github.com/hamelsmu/MLapp/blob/master/notebooks/Issue_Labeling_Model.ipynb

希望选择合理的阈值，因此模型不会向人们发送过多错误预测的垃圾邮件（这意味着应用程序在某些情况下可能不会提供任何预测）。通过在几个回购测试系统并以可接受的误报率与几个维护者协商来选择阈值。

步骤5：使用Flask响应有效负载。

现在有了一个可以进行预测的模型，以及一种以编程方式为问题添加注释和标签的方法（步骤2），剩下的就是将各个部分粘合在一起。通过以下步骤完成此操作：

1. 启动一个侦听来自GitHub.com的有效负载的Web服务器（指定了GitHub将在步骤1中注册您的应用程序时将有效负载发送到的端点）。
2. 验证有效负载是否来自GitHub（由此脚本中的verify_webhook函数说明）。
3. 如果需要，可以使用GitHub API（在步骤2中学习）响应有效负载。
4. 将收到的适当数据和反馈记录到数据库中，以便进行模型再训练。

实现这一目标的一个好方法是使用像Flask这样的框架和像SQLAlchemy这样的数据库接口。如果已熟悉flask，则下面是代码的截断版本，当GitHub通知已打开问题时，该代码应用预测的问题标签：

如果不熟悉Flask或SQLAchemy，请不要担心。通过Flask，HTML，CSS和Javascript上的精彩MOOC了解有关此主题的所有信息。如果是数据科学家，本课程是一项非常好的时间投入，因为这将允许以轻量级方式为数据产品构建界面。学习了这门课程，并对此印象深刻。

将它作为练习让读者浏览GitHub存储库中的其余部分代码。

https://github.com/hamelsmu/MLapp

收集明确的用户反馈。

此截图来自此问题

如上所述，通过要求用户对prediction或react对预测作出反应来请求显式反馈。将这些反应存储在一个数据库中，这样就可以重新训练和调试模型。这可能是将数据产品作为GitHub应用程序启动的最激动人心和最重要的方面之一！

在应用主页上看到更多预测和用户反馈的示例。例如，这是kubeflow / kubeflow repo的页面：