资料的含义 | ML#Day9

实务上,我们可能并没有自己想的那麽了解系统的真实面,这也造就一些起步上的困难,反思一下,这也关於问题的选定,与挑选参数的过程与方式,有些相关延伸思考的地方。

打个比方,原本以为我们以下单次数区分的3种客户:一般忠实的客户,以及只买1~2次的客户,和大量购买的大客户,可能呈现一种常态的分布,只买一两次的客户和大买的大客户占少量,一个月购买10~100次的忠实客户占最大的比例。

但仔细统计下来却不是的,以会员成分分析起来,只购买1~2次就没出现的客户占据了7成,中间值的客户占不到1成,剩下的又都是大客户包办,呈现一种M型的分布。

另外一件事,我们藉由系统改版的机会,保留新旧接口并存的方式,藉以得知哪些帐号是从旧接口进来下单,因为网页介面上已经无法透过旧接口下单,换而言之,这些帐号就是程序机器人,透过打API的方式跟我们下订单。结果统计下来,这种帐号数量占比不到1%,订单的金额总数也只有3%左右。

对於自家资料的了解程度,会影响实作上的结果深远,因为会遇到个很现实的问题,如果我们想要用数学分析一个模型出来,那必须有些假设,而这些假设必须是有机会贴近实情的,它必须是一种正确的资料。

性质不同的参数,不能被当作同一种参数使用,举例来说,如果想知道文化对於消费习惯的影响,那麽以这个命题,下面这些参数,你不能视为同一种参数:

台北、上海、蒙古、非洲、纽约、荷兰、鹿特丹、伦敦、义大利半岛、福冈、马尼拉、北海道........

当我们了解上面这些名词的含义之後,其实不难分出其中的差异,并且不觉得它们属於同样的层次,或者能够分在同一类。

这也是一种「资料清洗」的工作,问题是当遇到格式错误或缺失值以外的问题,麻烦的是你必须要知道这些资料内容对於命题的意义不同,如此以来才有可能知道怎麽做二次处理。

回到我们的题目很直观的可以知道,用程序的下单购买行为,一定跟真人在下单的行为有所不同,如果今天机器人下单的占比若有5成,那麽我们一定会将它们和一般的客户分开来统计和讨论,并不会视为同一类。

这就是现实面血淋淋的难题,资料是乾净的情况下,可以用一些检定或运算,检视是否对模型输出结果有所影响,但不乾净的情况下,真的很难办。

所以我们在挑选参数和假设参数有其重要性的时候,其实也在一边试图理解我们自己的系统资料,这种分析为的是可以预测未来(因为你想做出一个模型可以得知预期的output),也在了解过去,因为足够了解自己参数的意义,才能够正确地处理好参数,拿到乾净的资料。

如此一来,实务面的开发与网路上提供的练习资料,也能够理解其中的差异吧,因为人家拿出来的资料基本上是乾净处理过的,而我们自己的资料还是处理原生原始状态,很大程度还没变成所谓有「价值的资料」。


<<:  DAY5-PHP这是什麽老东西

>>:  [day2]开发规格书阅读-不简单的数位金流API

[Day 11] 多对多关联的变形:Parent-Child reference

之前我们看过了透过 DAO 方式,来处理资料之间呈现一对多关联,或者多对多关联的做法。 今天我们来看...

笔记 - 常见演算法时间复杂度

这是在找linked list资料看到harry xie大神文章提到的 里面是常见演算法的时间复杂度...

Day 07 生命周期(Lifetime)

前面说过自己建立的Service都必须在Startup.cs(Blazor Server)或Prog...

写给MLOps人才培育苦手 | MLOps落地指南 - 团队篇

当理解MLOps的定义、以及ML专案与软件专案的差别之後,接下来我想谈谈如何再把MLOps往下切分成...

[Day 1]从零开始学习 JS 的连续-30 Days---宣告变数

学习 JS Day 1 JavaScript 变数 变数就好比是资料容器,而资料又可以分为不同种类(...