如何通过ChatGPT的帮助预测玩家流失

使用低代码ML平台进行数据科学 | Actable AI

使用低代码平台分析数据和训练模型以预测玩家流失

介绍

在游戏世界中，公司不仅要吸引玩家，还要尽可能长时间地保留他们，尤其是在依赖于游戏内微交易的免费游戏中。这些微交易通常涉及购买游戏内货币，使玩家可以获取升级或自定义物品，并为游戏的开发提供资金。监控流失率（表示停止玩游戏的玩家数量）至关重要。这是因为高流失率意味着显著的收入损失，从而导致开发人员和经理的压力增加。

本文探讨了使用基于移动应用程序获取的数据的真实数据集，特别关注用户玩的关卡。利用机器学习，这已成为技术领域的重要组成部分，并构成了人工智能（AI）的基础，企业可以从其数据中提取有价值的见解。

然而，构建机器学习模型通常需要编码和数据科学专业知识，这使得许多个人和缺乏雇用数据科学家或处理复杂算法的强大硬件资源的较小公司无法接触它。

为了解决这些挑战，低代码和无代码机器学习平台应运而生，旨在简化机器学习和数据科学过程，从而减少对广泛编码知识的需求。此类平台的示例包括Einblick、KNIME、Dataiku、Alteryx和Akkio。

本文使用一个低代码机器学习平台来训练一个能够预测玩家是否会停止游戏的模型。此外，还深入探讨了结果解释和可用于提高模型性能的技术。

本文的其余部分如下：

1. 平台
2. 数据集
3. 探索性数据分析
4. 训练分类模型
5. 改善模型性能
6. 创建新功能
7. 训练新的（希望改进的）分类模型
8. 模型在生产中部署
9. 结论

平台

充分披露-我是Actable AI的数据科学家，在撰写本文的时候使用该平台。我还参与实现ML库中的新功能并维护它们，因此我很好奇该平台在实际问题上的表现如何。

该平台提供了一个Web应用程序，其中包含许多传统应用程序的受欢迎的机器学习方法，例如分类，回归和分割。还提供了一些不太常见的工具，例如时间序列预测，情感分析和因果推断。可以补全缺失数据，可以计算数据集的统计数据（例如功能之间的相关性，方差分析等），同时可以使用诸如条形图，直方图和词云等工具可视化数据。

还提供了Google Sheets的插件，使分析和模型训练可以直接在电子表格中完成。但是，请注意，此插件可能没有最新功能。

核心库是开源的，可在GitHub上获得，并由几个众所周知和可信的框架组成，例如AutoGluon和scikit-learn，这些框架也是开源和免费的。这与其他相关平台并无不同，它们也利用现有的开源解决方案。

但是，这引出了一个问题：如果大多数工具已经可用且免费使用，为什么要使用这些平台呢？

主要原因是这些工具需要掌握编程语言，例如Python，因此那些不熟悉编程的人可能会发现使用这些工具很困难甚至不可能使用。因此，这些平台旨在以图形用户界面（GUI）的形式提供所有功能，而不是一组编程命令。

更有经验的专业人士也可以通过易于使用的图形界面节省时间，并且这些平台还可以提供有关可用工具和技术的信息性描述。一些平台还可以展示您可能不熟悉的工具，或在处理数据时提供有用的警告（例如数据泄漏，即模型可以访问在未见过数据生产环境中不可用的特征），使您更好地处理数据。

使用这些平台的另一个原因是它们提供了用于运行模型的硬件。因此，您无需购买和维护自己的计算机和图形处理单元（GPU）等组件。

数据集

这个数据集是由一家使用该平台的游戏公司提供的，可以在此处查看，与之相关的是CC BY-SA-4许可证，只要提供适当的信用，就允许共享和适应。它共有789,879行（样本），相当可观，可以帮助减少过度拟合等效应。

数据集包含有关每个人在移动应用中玩的每个级别的信息。例如，有有关游戏时间的信息，玩家是否赢得或输掉了级别，级别号等等。

用户ID也已包括在内，但已被匿名化，以不泄露原始玩家的身份。某些字段也已被删除。但是，它应该为尝试预测玩家是否流失提供一个坚实的基础，看看本文中考虑的ML平台提供的工具是否有用。

每个特征的含义如下：

• Churn：如果玩家已经超过2周没有玩这个游戏，为‘1’，否则为‘0’
• ServerTime：玩级别时的服务器时间戳
• EndType：级别结束的原因（主要是‘Win’如果玩家赢得了游戏，‘Lose’如果玩家输掉了游戏）
• LevelType：级别类型
• Level：级别号
• SubLevel：子级别号
• Variant：级别变体
• Levelversion：级别版本
• NextCar：未使用（包括在内，以查看平台如何处理仅具有一个标签的特征，如后面所讨论的）
• AddMoves：可用的额外移动
• DoubleMana：未使用（包括在内，以查看平台如何处理仅具有一个标签的特征，如后面所讨论的）
• StartMoves：级别开始时可用的移动次数
• ExtraMoves：购买的额外移动
• UsedMoves：玩家使用的移动次数
• UsedChangeCar：未使用（包括在内，以查看平台如何处理仅具有一个标签的特征，如后面所讨论的）
• WatchedVideo：是否观看了视频，提供额外的移动
• BuyMoreMoves：玩家购买更多移动的次数
• PlayTime：玩这个级别所花费的时间
• Scores：玩家达到的分数
• UsedCoins：在这个级别中使用的总硬币数
• MaxLevel：玩家达到的最高级别
• Platform：设备类型
• UserID：玩家ID
• RollingLosses：玩家连续损失的次数

探索性数据分析

在训练之前的第一步是通过探索性数据分析（EDA）来了解数据。EDA是一种数据分析方法，涉及对数据集的主要特征进行总结，可视化和理解。目标是从数据中获得见解，并识别可能存在的任何模式，趋势，异常或问题（例如缺失值），这些可以帮助确定要使用的特征和模型。

首先，让我们来看看导致级别结束的主要原因：

如上图所示，级别结束的主要原因（由EndType表示）是玩家输掉游戏（63.6%）而不是赢得游戏（35.2%）。我们还可以看到UsedChangeCar列似乎是无用的，因为它对所有行包含相同的值。

一个非常重要的观察是，我们的目标值高度不平衡，前10,000行中只有63个样本（即数据的0.6%）具有流失值为1（即玩家已经流失）。这将需要记住，因为我们的模型很可能会非常容易地偏向于仅预测Churn的值为0。原因是该模型可以获得某些指标（例如准确性）的非常好的值；在这种情况下，如果一个虚拟模型只选择最流行的类别，那么它将99.4%的时间是正确的！我邀请您阅读Baptiste Rocca和Jason Brownlee的两篇优秀文章，了解更多信息。

不幸的是，Actable AI尚未提供处理不平衡数据的任何方法，例如通过合成少数类过采样技术（SMOTE），或使用类别权重或不同的采样策略。这意味着在选择优化指标时需要小心。如上所述，准确度不是最好的选择，因为即使一个类别的样本从未被正确标记，也可以实现高比率。

另一种有用的分析类型是特征之间的相关性，特别是预测特征与目标特征之间的相关性。这可以使用“相关性分析”工具来完成，其结果可以直接在Actable AI平台上查看：

在上图中，蓝色条表示特征与Churn的正相关性，当值等于1时，而橙色条则表示负特征相关性。应注意，相关性介于-1到1之间，其中正值表示两个特征倾向于以相同的方向变化（例如，两者都增加或两者都减少），而负相关性仅指当其中一个特征增加或减少时，另一个特征则相反。因此，相关性的大小（忽略负号）可能是最重要的注意事项。

有许多值得关注的地方，例如输掉一级的玩家更容易流失（最顶部的蓝条），反之，赢得一级的玩家更容易继续玩（第三个橙条）。但是，还应注意到这些值相当低，表明这些特征与目标之间的相关性相当弱。这意味着可能需要执行特征工程，利用现有特征创建新特征，以捕捉更重要的信息，从而使模型能够执行更准确的预测。稍后将更详细地讨论特征工程。

但是，在创建新特征之前，值得看看我们可以使用数据集中的原始特征实现什么样的性能。下一步可能更令人兴奋——训练模型以查看可以实现什么样的性能。

训练分类模型

由于我们希望预测用户是否会停止玩游戏，因此这是一个分类问题，需要选择多个标签中的一个。在我们的情况下，问题涉及将两个标签之一分配给一个（“1”对应于“Churn”，“0”对应于“No Churn”），这进一步使它成为二元分类问题。

这个过程主要是通过AutoGluon库完成的，它会自动训练若干模型，然后选择表现最佳的模型。这避免了手动训练单个模型并比较它们的性能。

在Actable AI平台中需要设置许多参数，下面是我的选择：

还可以选择用于优化模型的指标。我使用了接收器操作特征下面积（AUC ROC），因为它对之前讨论的类别不平衡问题不太敏感。值的范围从0到1（后者是完美得分）。

一段时间后，生成并显示结果，也可以在这里查看。计算了许多不同的指标，这不仅是良好的实践，而且几乎是必要的，如果我们真的想要了解我们的模型，因为每个指标都专注于模型性能的某些方面。

显示的第一个指标是优化指标，值为0.675：

这不是很好，但要记住，在我们的EDA期间，特征与目标之间的相关性相当弱，因此性能平庸并不令人意外。

这个结果也凸显了理解结果的重要性；通常我们会对精度为0.997（即99.7%）非常满意。但是，这主要是由于数据集的高度不平衡，正如之前讨论的那样，因此不应给予太多重要性。与此同时，像精确度和召回率这样的分数基于0.5的阈值，可能不是最适合我们应用的。

ROC和精确率-召回率曲线也显示出来，再次清楚地表明表现有些差：

这些曲线也有助于确定我们在最终应用中可以使用的阈值。例如，如果希望最小化假阳性的数量，那么我们可以选择一个阈值，在该阈值下，模型获得更高的精度，并检查相应的召回率。

还可以查看获得的最佳模型的每个特征的重要性，这也许是更有趣的结果之一。这是通过AutoGluon的置换重要性计算的。还显示了P值，以确定结果的可靠性：

也许并不奇怪的是，最重要的特征是EndType（显示导致级别结束的原因，例如胜利或失败），其次是MaxLevel（用户玩的最高级别，更高的数字表示玩家非常投入和活跃在游戏中）。

另一方面，UsedMoves（玩家执行的移动次数）几乎没有用，而StartMoves（玩家可用的移动次数）实际上可能会损害性能。这也是有道理的，因为玩家使用的移动次数和可用的移动次数本身并不是高度信息化的；它们之间的比较可能会更有用。

我们还可以查看每个类别（在本例中为1或0）的估计概率，这些概率用于推导出预测的类别（默认情况下，分配具有最高概率的类别作为预测类别）：

可解释的人工智能（Explainable AI）变得越来越重要，以理解模型行为，这就是为什么像Shapley值这样的工具日益流行的原因。这些值代表了特征对预测类别概率的贡献。例如，在第一行中，我们可以看到36的RollingLosses值降低了该玩家预测类别（类别0，即该玩家将继续玩游戏）的概率。

相反，这意味着另一个类别（类别1，即玩家流失）的概率增加了。这是有道理的，因为RollingLosses值更高表示玩家已经连续失去了许多关卡，并因此更有可能因失望而停止玩游戏。另一方面，RollingLosses值较低通常会提高负类别（即玩家不会停止玩）的概率。

如前所述，许多模型都经过训练和评估，然后选择最佳模型。有趣的是，在这种情况下，最佳模型是LightGBM，也是最快的之一：

提高模型性能

此时，我们可以尝试提高模型的性能。也许最简单的方法之一是选择“优化质量”选项，看看我们能走多远。此选项会配置一些已知能够提高性能的参数，但可能会导致训练时间较慢。以下是所得到的结果（您也可以在此查看）：

再次关注ROC AUC指标，性能从0.675提高到0.709。对于这样一个简单的改变来说，这是相当不错的增长，尽管仍然远离理想状态。我们还能做些什么来进一步提高性能吗？

创建新特征

如前所述，我们可以使用特征工程来做到这一点。这涉及从现有特征中创建新特征，这些特征能够捕捉到更强的模式，并与要预测的变量更高度相关。

在我们的情况下，数据集中的特征具有相当狭窄的范围，因为这些值仅涉及单个记录（即用户玩的一个级别的信息）。因此，通过总结一段时间内的记录，可能会更有用地获得更全面的视角。这样，模型将了解用户的历史趋势。

例如，我们可以确定玩家使用了多少额外的移动，从而提供体验难度的度量；如果需要的额外移动很少，那么级别可能太容易了；另一方面，高数量可能意味着级别太难了。

还可以通过检查最近几天玩游戏所花费的时间来检查用户是否沉浸在游戏中并感到愉快。如果玩家没有玩很多游戏，这可能意味着他们失去了兴趣，可能会很快停止玩。

有用的特征因不同领域而异，因此重要的是要尝试找到与任务有关的任何信息。例如，您可以查找和阅读研究论文、案例研究和文章，或者寻求已在该领域工作并具有经验和熟悉最常见特征、它们之间的关系、任何潜在陷阱以及最有可能有用的新特征的公司或专业人士的建议。这些方法有助于减少试错，并加快特征工程过程。

鉴于最近大型语言模型（LLM）的进展（例如，您可能听说过ChatGPT …），并且鉴于特征工程的过程可能对经验不足的用户有些困难，我很想看看LLM是否有用于提供创意以创建特征。我做到了这一点，以下是输出：

ChatGPT的回答实际上非常好，并且还指出了一些基于时间的特征，如上所述。当然，要记住，如果所需信息不可用，我们可能无法实现所有建议的特征。此外，众所周知，它容易出现幻觉，因此可能不提供完全准确的答案。

我们可以从ChatGPT获得更多相关响应，例如通过指定我们正在使用的特征或通过使用提示，但这超出了本文的范围，并留给读者作为练习。尽管如此，LLMs可以被视为启动工作的初始步骤，但仍强烈建议从论文，专业人士等寻求更可靠的信息。

在Actable AI平台上，可以使用相当著名的SQL编程语言创建新功能。对于不熟悉SQL的人，利用ChatGPT自动生成查询的方法可能会很有用。然而，在我的有限实验中，这种方法的可靠性可能会有所不同。

为确保计算所需输出的准确性，建议手动检查结果的子集，以验证正在正确计算所需的输出。这可以通过检查在SQL Lab中运行查询后显示的表格轻松完成，SQL Lab是Actable AI的界面，用于编写和运行SQL代码。

以下是我用于生成新列的SQL代码，如果您想创建其他功能，这应该有助于为您提供一个起点：

SELECT     *,    SUM("PlayTime") OVER UserLevelWindow AS "time_spent_on_level",    (a."Max_Level" - a."Min_Level") AS "levels_completed_in_last_7_days",    COALESCE(CAST("total_wins_in_last_14_days" AS DECIMAL)/NULLIF("total_losses_in_last_14_days", 0), 0.0) AS "win_to_lose_ratio_in_last_14_days",    COALESCE(SUM("UsedCoins") OVER User1DayWindow, 0) AS "UsedCoins_in_last_1_days",    COALESCE(SUM("UsedCoins") OVER User7DayWindow, 0) AS "UsedCoins_in_last_7_days",    COALESCE(SUM("UsedCoins") OVER User14DayWindow, 0) AS "UsedCoins_in_last_14_days",    COALESCE(SUM("ExtraMoves") OVER User1DayWindow, 0) AS "ExtraMoves_in_last_1_days",    COALESCE(SUM("ExtraMoves") OVER User7DayWindow, 0) AS "ExtraMoves_in_last_7_days",    COALESCE(SUM("ExtraMoves") OVER User14DayWindow, 0) AS "ExtraMoves_in_last_14_days",    AVG("RollingLosses") OVER User7DayWindow AS "RollingLosses_mean_last_7_days",    AVG("MaxLevel") OVER PastWindow AS "MaxLevel_mean"FROM (    SELECT        *,        MAX("Level") OVER User7DayWindow AS "Max_Level",        MIN("Level") OVER User7DayWindow AS "Min_Level",        SUM(CASE WHEN "EndType" = 'Lose' THEN 1 ELSE 0 END) OVER User14DayWindow AS "total_losses_in_last_14_days",        SUM(CASE WHEN "EndType" = 'Win' THEN 1 ELSE 0 END) OVER User14DayWindow AS "total_wins_in_last_14_days",        SUM("PlayTime") OVER User7DayWindow AS "PlayTime_cumul_7_days",        SUM("RollingLosses") OVER User7DayWindow AS "RollingLosses_cumul_7_days",        SUM("PlayTime") OVER UserPastWindow AS "PlayTime_cumul"    FROM "game_data_levels"    WINDOW        User7DayWindow AS (            PARTITION BY "UserID"            ORDER BY "ServerTime"            RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW        ),        User14DayWindow AS (            PARTITION BY "UserID"            ORDER BY "ServerTime"            RANGE BETWEEN INTERVAL '14' DAY PRECEDING AND CURRENT ROW        ),        UserPastWindow AS (        PARTITION BY "UserID"        ORDER BY "ServerTime"        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW        )) AS aWINDOW    UserLevelWindow AS (        PARTITION BY "UserID", "Level"        ORDER BY "ServerTime"        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW    ),    PastWindow AS (        ORDER BY "ServerTime"        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW    ),    User1DayWindow AS (        PARTITION BY "UserID"         ORDER BY "ServerTime"         RANGE BETWEEN INTERVAL '1' DAY PRECEDING AND CURRENT ROW    ),    User7DayWindow AS (        PARTITION BY "UserID"        ORDER BY "ServerTime"        RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW    ),    User14DayWindow AS (        PARTITION BY "UserID"        ORDER BY "ServerTime"        RANGE BETWEEN INTERVAL '14' DAY PRECEDING AND CURRENT ROW    )ORDER BY "ServerTime";

在这段代码中，‘windows’ 被创建用于定义考虑的时间范围，如最近一天、最近一周或最近两周。该范围内的记录将在特征计算过程中使用，这主要旨在提供关于玩家在游戏中的历史背景。完整的特征列表如下：

• time_spend_on_level：用户在玩关卡时所花费的时间。提供了关卡难度的指示。
• levels_completed_in_last_7_days：用户在过去7天（1周）内完成的关卡数量。提供了关卡难度、毅力和游戏沉浸度的指示。
• total_wins_in_last_14_days：用户在过去14天内赢得关卡的总次数。
• total_losses_in_last_14_days：用户在过去14天内输掉关卡的总次数。
• win_to_lose_ratio_in_last_14_days：赢得次数与输掉次数的比率（total_wins_in_last_14_days/total_losses_in_last_14_days）
• UsedCoins_in_last_1_days：前一天内使用的硬币数量。提供了关卡难度和玩家花费游戏货币的意愿的指示。
• UsedCoins_in_last_7_days：前7天（1周）内使用的硬币数量。
• UsedCoins_in_last_14_days：前14天（2周）内使用的硬币数量。
• ExtraMoves_in_last_1_days：前一天内用户使用的额外步数。提供了关卡难度的指示。
• ExtraMoves_in_last_7_days：前7天内用户使用的额外步数（1周）。
• ExtraMoves_in_last_14_days：前14天内用户使用的额外步数（2周）。
• RollingLosses_mean_last_7_days：用户在过去7天（1周）内的累积损失的平均值。提供了关卡难度的指示。
• MaxLevel_mean：所有用户达到的最高等级的平均值。
• Max_Level：玩家在过去7天（1周）内达到的最高等级。与 MaxLevel_mean 一起，它提供了关于玩家相对于其他玩家的进步的指示。
• Min_Level：用户在过去7天（1周）内玩的最低等级。
• PlayTime_cumul_7_days：用户在过去7天（1周）内玩的总时间。提供了玩家游戏沉浸度的指示。
• PlayTime_cumul：用户玩游戏的总时间（自第一个可用记录以来）。
• RollingLosses_cumul_7_days：过去7天（1周）内滚动损失的总数。提供了关卡难度的指示。

在计算特定行的新特征值时，只使用过去的记录是非常重要的。换句话说，在生产部署时，必须避免使用未来的观察结果，因为模型显然不会访问任何未来值。

一旦满意创建的特征，我们就可以将表保存为新数据集，并运行一个新模型，这样（希望）可以获得更好的性能。

训练新的（希望改进的）分类模型

现在是时候看看新列是否有用了。我们可以重复之前的步骤，唯一的区别是现在使用包含附加特征的新数据集。与原始模型进行公平比较所使用的相同设置，结果如下（也可以在此处查看）：

新模型的ROC AUC值为0.918，与原值0.675相比有很大改进。它甚至比针对质量进行优化的模型（0.709）更好！这证明了理解数据并创建能够提供更丰富信息的新特征的重要性。

现在有趣的是看看我们的哪些新特性实际上是最有用的；同样，我们可以检查特征重要性表：

看起来，最近两周的总损失次数非常重要，这是有道理的，因为玩家输掉游戏的次数越多，他们可能变得更容易失去兴趣并停止玩游戏。

所有用户中的平均最高等级也似乎很重要，这也是有道理的，因为它可用于确定玩家与其他玩家的大多数相差多少——高于平均水平表示玩家很好地融入了游戏，而比平均水平低得多的值可能表明玩家仍然没有受到很好的激励。

这些只是我们可以创建的一些简单特征。我们可以创建其他特征，从而进一步提高性能。我会将其留给读者作为练习，以查看可以创建哪些其他特征。

使用相同的时间限制训练针对质量进行优化的模型并没有改进性能。然而，这也许是可以理解的，因为使用了更多的特征，所以可能需要更多的时间进行优化。正如在这里所观察到的，将时间限制增加到6小时确实将性能提高到了0.923（以AUC为指标）：

还应该注意，某些指标，如精确度和召回率，仍然相当差。然而，这是因为假定分类阈值为0.5，这可能不是最佳的。确实，这也是我们关注AUC的原因，如果我们调整阈值，它可以给出更全面的性能图片。

在训练的模型中，以AUC为指标的性能可以总结如下：

┌─────────────────────────────────────────────────────────┬───────────┐│                         模型                          │ AUC (ROC) │├─────────────────────────────────────────────────────────┼───────────┤│ 原始特征                                                │     0.675 ││ 原始特征 + 针对质量进行优化                             │     0.709 ││ 工程特征                                                │     0.918 ││ 工程特征 + 针对质量进行优化 + 更长时间                  │     0.923 │└─────────────────────────────────────────────────────────┴───────────┘

在生产环境中部署模型

如果不能在新数据上实际使用好的模型，那么拥有好的模型就毫无用处。机器学习平台可能会提供此功能，即在给定训练模型的情况下，在未来的未见过的数据上生成预测。例如，Actable AI平台允许使用API，使模型可用于平台外的数据，就像导出模型或插入原始值以获得即时预测一样。

然而，定期在未来的数据上测试模型以确定其是否仍按预期运行非常重要。确实，可能需要使用新数据重新训练模型。这是因为特征分布等特征可能会随时间而变化，从而影响模型的准确性。

例如，公司可能会引入新政策，然后影响客户行为（无论是积极的还是消极的），但是如果模型没有访问任何反映新变化的特征，则可能无法考虑新政策。如果存在如此重大的变化，但没有可用于通知模型的特征，则值得考虑使用两个模型：一个在旧数据上进行训练和使用，另一个在新数据上进行训练和使用。这将确保模型专门用于处理具有不同特征的数据，这些特征可能很难通过单个模型捕获。

结论

本文使用了一个包含有关用户在移动应用中每个级别玩耍的信息的真实数据集来训练分类模型，可以预测玩家在两周内是否会停止玩游戏。

整个处理流程都被考虑在内，从EDA到模型训练再到特征工程。提供了对结果解释以及如何改进的讨论，从0.675的值提高到0.923的值（其中1.0是最大值）。

创建的新特征相对简单，当然还存在许多可以考虑的特征。此外，还可以考虑特征归一化和标准化等技术。一些有用的资源可以在这里和这里找到。

关于Actable AI平台，我可能有点偏见，但我认为它有助于简化数据科学家和机器学习专家需要完成的一些更繁琐的过程，具有以下可取之处：

• Core ML库是开源的，所以任何具有良好编程知识的人都可以验证其安全性。任何懂Python的人也都可以使用。
• 对于那些不懂Python或不熟悉编码的人，GUI提供了一种使用许多分析和可视化工具的简单方法。
• 开始使用该平台并不太困难（它不会用太多技术信息来压倒用户，这可能会使不太熟悉的人望而却步）。
• 免费版允许在公开数据集上运行分析。
• 除了本文考虑的分类之外，还有大量工具可用。

话虽如此，它也有一些缺点，同时还有一些方面需要改进，例如：

• 免费版不允许在私有数据上运行ML模型。
• 用户界面看起来有点过时。
• 有些可视化效果可能不够清晰，有时很难解释。
• 应用程序有时反应较慢。
• 在计算和显示主要结果时，不能使用0.5以外的阈值。
• 不支持不平衡数据。
• 仍需要一些数据科学和机器学习的知识才能从该平台中获得最大的收益（尽管这可能也适用于其他平台）。

在未来的其他文章中，我将考虑使用其他平台来确定它们的优点和缺点，以及哪些用例最适合每个平台。

在那之前，希望这篇文章能给您带来启发！请随时留下任何反馈或问题！

您对本文有什么想法吗？请随时发表评论或在领英上直接给我留言！

此外，请确保关注我，以确保在未来文章发表时得到通知。

作者在撰写本文时是Actable AI的数据科学家。