具有时间序列数据的 k-Nearest Neighbors - 如何获得整个时间段估计量

数据挖掘 r 时间序列 k-nn
2021-10-09 22:00:40

我有一个大型数据集,用于显示工厂中多名员工在很长一段时间内(2017 年 1 月 1 日至今)进行的活动。在每个时间点记录不同员工执行的活动(因为他们与软件交互)。我将这些数据制成表格以记录每个操作员每天执行的活动数量。

我的桌子看起来像这样:

Date         Name    Activity  UnitsProcessed   Shift      Team
01/10/2017   MMouse  Soldering   1000           Shift A   Team A
01/10/2017   MMouse  Welding     3000           Shift A   Team A
01/10/2017   DDuck   Soldering   4000           Shift A   Team B
01/10/2017   DDuck   Welding     1000           Shift A   Team B
...
02/11/2017   MMouse  Soldering   1100           Shift A   Team A
02/11/2017   MMouse  Welding     2900           Shift A   Team A
02/11/2017   DDuck   Soldering   4010           Shift A   Team B
02/11/2017   DDuck   Welding     900            Shift A   Team B

每条线代表每个操作员每天工作时执行的活动,以及每个活动期间处理的单元数,以及操作员所属的班次和团队的分类器(为简单起见,假设这不会改变随着时间的推移)。

为简洁起见,我省略了 Shift B 中的值,但本质上,Shift B 的团队成员(通常)与 Shift A 的工作天数不同,但执行的任务比例通常与 Shift A 上的相应团队相似 - 团队A 队或 B 队。

我要解决的问题是:我为另一个运算符“GOofy”处理了日期、活动和单位 - 以及各种其他变量。但我不知道 GOofy 先生在哪个班次/团队工作。所以我正在使用 Mr. Mouse 和 Mr. Duck 的数据(显然,实际上是几十人),看看我是否可以尝试训练 kNN 正确猜测每个 Name 的 Shift 和 Team 模式,给定日期、活动, 和 Units Processed 字段等。

我的想法是:

a) 将 Team 和 Shift 分开并没有特别的价值,因此我应该创建一个将两者结合起来的连接列

B)如果我为“焊接”、“焊接”和其他活动创建单独的列,我可以按日期为每个活动每天处理的单位数。鉴于所执行的活动类型(我假设)是班次/团队组合的强预测因素,我应该能够根据该行的日期(可能转换为数字日期)训练以识别班次/团队以及每条焊锡、焊接等线路的相对值。

问题是,当扩展到测试集时,这只会给我每一天的预测值。但我怀疑工作天数也是一个重要的预测因素,所以我也想包括这一点。但我不确定如何解决这个问题。

我能想到的两种方法是:

选项 1:使用 kNN 为每个操作员/天组合生成班次/团队的估计量,x 变量是日期、每天焊接的单位和焊接的单位,然后为每个操作员计算“班次”的比例A, Team A”, “Shift A, Team B”等被分配给该操作员 - 所以如果 DDuck 被分配为“Shift A, Team A”,在 90% 的日子里,DDuck 似乎很可能确实是“Shift A,A队”。

选项 2:以某种方式创建一个变量来表示每个操作员的所有工作天数 - 尽管我不确定如何执行此操作 - 从而为每个操作员创建一个包含一行的集合。

这些方法中的任何一种都有效吗?是否有一种广泛使用的替代方法?

请注意,这不是与之前有关 kNN 和时间序列数据的问题的重复,因为这些问题与预测有关,而我正在尝试分析回顾性数据。

1个回答

你有更多的数字特征吗?KNN 处理需要数字数据的距离(欧几里得、L1 等)。它不包含分类数据。您的活动功能不适用于 KNN,甚至将日期转换为整数只会创建一个无法在 KNN 中表现良好的时间序列。我认为你正在接近这个错误。尝试逻辑回归。它将包含分类和数字特征。

将 Team 和 Shift 分开并没有特别的价值,因此我应该创建一个将两者结合起来的连接列。

我会为团队和班次建立两个独立的模型。您将获得更高的准确性,因为您使用数据来预测更少的类别并让模型专门处理每个任务。

总的来说,我会使用逻辑回归,而不是 KNN。它更适合您的问题。希望这可以帮助。