15年软件架构师经验总结:在ML领域,初学者踩过的5个坑

简介: 15年软件架构师经验总结:在ML领域,初学者踩过的5个坑

如果你要构建你的第一个模型,请注意并避免这些问题。


数据科学和机器学习正变得越来越流行,这个领域的人数每天都在增长。这意味着有很多数据科学家在构建他们的第一个机器学习模型时没有丰富的经验,而这也是错误可能会发生的地方。

近日,软件架构师、数据科学家、Kaggle 大师 Agnis Liukis 撰写了一篇文章,他在文中谈了谈在机器学习中最常见的一些初学者错误的解决方案,以确保初学者了解并避免它们。


Agnis Liukis 拥有超过 15 年的软件架构和开发经验,他熟练掌握 Java、JavaScript、Spring Boot、React.JS 和 Python 等语言。此外,Liukis 还对数据科学和机器学习感兴趣,他多次参加 Kaggle 比赛并取得好成绩,已达到 Kaggle 比赛大师级别。

以下为文章内容:

在机器学习领域,这 5 个坑,你踩过吗?

1、在需要的地方没有使用数据归一化(data normalization)

对数据进行归一化操作,然后获取特征,并将其输入到模型中,让模型做出预测,这种方法是很容易的。但在某些情况下,这种简单方法的结果可能会让人失望,因为它缺少一个非常重要的部分。

一些类型的模型需要数据归一化,如线性回归、经典神经网络等。这类模型使用特征值去乘训练值的权重。在非归一化特征的情况下,一个特征值的可能范围可能不同于另一个特征值的可能范围。

假设一个特征的值在 [0,0.001] 范围内,另一个特征的值在 [100000,200000] 范围内。对于使两个特征同等重要的模型,第一个特征的权重将比第二个特征的权重大 1 亿倍。巨大的权重可能会给模型带来严重问题,比如存在一些异常值的时候。此外,估计各种特征的重要性变得困难,因为权重大可能意味着特征很重要,但也可能只是意味着其特征值很小。

归一化后,所有特征的值都在相同的范围内,通常为 [0,1] 或 [-1,1]。在这种情况下,权重将在相似的范围内,并与每个特征的实际重要性密切对应。

总的来说,在需要的地方使用数据归一化将产生更好、更准确的预测。

2、认为特征越多越好

有人可能会认为加入所有特征是一个好主意,认为模型会自动选择并使用最好的特征。实际上,这种想法很难成真。

模型的特征越多,过拟合的风险越大。即使在完全随机的数据中,模型也能够找到一些特征(信号),尽管有时较弱,有时较强。当然,随机噪声中没有真实信号。但如果我们有足够多的噪声列,则该模型有可能根据检测到的故障信号使用其中的一部分。当这种情况发生时,模型预测质量将会降低,因为它们一定程度上基于随机噪声。

现在有许多技术帮助我们进行特征选择。但你要记住,你需要解释你拥有的每一个特征,以及为什么这个特征会帮助你的模型。

3. 在需要外推的情况下,使用基于树的模型

基于树的模型易于使用,功能强大,这也是其受欢迎的原因。然而,在某些情况下,使用基于树的模型可能是错误的。

基于树的模型无法外推,这些模型的预测值永远不会大于训练数据中的最大值,而且在训练中也永远不会输出比最小值更小的预测值。

在某些任务中,外推能力可能非常重要。例如,如果该模型预测股票价格,那么未来股票价格可能会比以往任何时候都高。在这种情况下,基于树的模型将无法直接使用,因为它们的预测几乎会超过最高历史价格。

这个问题有多种解决方案,一种解决方案是预测变化或差异,而不是直接预测价值。另一种解决方案是为此类任务使用不同类型的模型。线性回归或神经网络就可以进行外推。

4、在不需要的地方使用数据归一化

之前文章谈到了数据归一化的必要性,但情况并非总是如此,基于树的模型不需要数据归一化。神经网络可能也不需要明确的归一化,因为有些网络内部已经包含归一化层,例如 Keras 库的 BatchNormalization 操作。

在某些情况下,即使是线性回归也可能不需要数据归一化,这是指所有特征都已处于类似的值范围,并且具有相同的含义。例如,如果模型适用于时间序列数据,并且所有特征都是同一参数的历史值。

5. 在训练集和验证集 / 测试集之间泄漏信息

造成数据泄漏比人们想象的要容易,考虑以下代码段:



image.png


数据泄漏的示例特性

实际上,这两种特征(sum_feature 和 diff_feature)都不正确。它们正在泄漏信息,因为在拆分到训练集 / 测试集后,具有训练数据的部分将包含来自测试的一些信息。这将导致更高的验证分数,但当应用于实际的数据模型时,性能会更差。

正确的方法是首先将训练集 / 测试集分开,然后才应用特征生成功能。通常,分别处理训练集和测试集是一种很好的特征工程模式。

在某些情况下,可能需要在两者之间传递一些信息 —— 例如,我们可能希望在测试集和训练集上使用相同的 StandardScaler。

总而言之,从错误中吸取教训是件好事,希望上述所提供的错误示例能帮助到你。

原文链接:https://towardsdatascience.com/5-typical-beginner-mistakes-in-machine-learning-3544bd4109b

相关文章
|
4月前
|
机器学习/深度学习 自然语言处理
彻底改变语言模型:全新架构TTT超越Transformer,ML模型代替RNN隐藏状态
【7月更文挑战第25天】近年来,NLP领域取得显著进展但也面临挑战,如长上下文建模与计算效率的平衡。为此,研究人员提出Test-Time Training (TTT) 模型架构。TTT由多机构合作开发,旨在解决长上下文建模难题及提高计算效率。通过将隐藏状态视为可学习更新的模型,TTT能随输入增长提升表示能力;采用自监督学习更新规则确保线性计算复杂度的同时保持高性能。实验显示TTT在多种NLP任务中表现优秀,尤其在长上下文处理方面超越Transformer。尽管如此,TTT仍面临训练资源需求高及自监督学习鲁棒性等挑战。[论文](https://arxiv.org/abs/2407.04620)
126 5
|
10天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
8天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
19天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
9天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
23 1
服务架构的演进:从单体到微服务的探索之旅
|
7天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
24 8
|
8天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
31 5
|
10天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
30 7
|
9天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
26 5
|
9天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
下一篇
无影云桌面