机器学习项目规划
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
规划机器学习项目与规划典型的软件工程项目不同。ML 项目具有非线性特征，并且不确定性程度各不相同。这需要采用迭代方法和实验性思维。
项目不确定性
早期规划可能很难，因为在开始项目时，最佳方法通常并不明显。这种固有的不确定性使得预估时间表变得困难。
最近的 Kaggle 竞赛就说明了机器学习项目的不确定性。在比赛的前几周，就有 350 支队伍参与其中。表现出色的团队将基准预测质量从 35% 提高到了 65%。在接下来的两周内，负责解决此问题的团队数量从 350 个增加到了 1, 400 个。不过，效果最好的模型预测质量仅为 68%。
图 3 展示了机器学习开发的不确定性，其中显示了工作量显著增加，但模型质量仅略有提升。
图 3. 在两周的时间里，负责解决此问题的团队数量增加了 4 倍，但模型的质量几乎保持不变，这凸显了估算机器学习解决方案的工作量之难。
换句话说，超过一千支团队（每支团队都尝试了各种数据转换、架构和超参数）仅能生产出预测质量为 68% 的模型。
下面的行业示例说明了 ML 项目的非线性特征，即输出与输入不成正比。两个团队花了几个月的时间才将模型的预测质量提升到了 90%。不过，多个团队花了超过 5 年的时间，才将该模型的预测质量提升到了 99.9%。
这些示例突出表明，可用于生产环境的机器学习是一项探索性过程，需要具备科学和工程思维。
实验方法
在大多数情况下，机器学习开发更像是进行实验，而不是实践传统软件工程。机器学习需要测试不同的特征、尝试多种架构，并恰当地调整超参数。从定义上讲，实验并不一定会成功。因此，最好使用实验框架进行规划。
我们来看看典型的软件工程计划，看看它与机器学习项目计划有何不同。
规划软件工程项目
在典型的软件工程计划中，您需要定义要求、概述组件、估算工作量并安排工作。明确定义了解决方案的路径。例如，工程师通常能够非常确定地知道自己需要完成哪些任务才能构建符合设计规范的应用。
在预测完成任务所需时间时，他们可以根据类似项目估算工作量。虽然总会遇到各种挑战（例如未知的依赖项或不断变化的要求），这有时会导致估算变得困难，但通常总有明确的解决方案。
相比之下，机器学习项目通常没有一条明确的成功之路。
规划机器学习项目
对于大多数机器学习项目，您需要通过试错过程尝试多种方法，才能找到最佳解决方案。在尝试解决问题之前，您通常不知道最佳解决方案。例如，最优解决方案的架构可能是简单的线性模型、神经网络，或者可能是决策树。只有尝试每种方法，才能找到最佳解决方案。
这种模糊性会导致规划难度加大。如前所述，预测机器学习项目所需的工作量很难。只有尝试解决问题，您才能更好地了解解决方案可能需要的时间和资源。
以下是规划机器学习工作时建议采用的策略：
为工作设置时间限制。设置明确的时间范围来完成任务或尝试特定解决方案。例如，您可以分配两周的时间来确定自己是否可以访问正确类型的数据。如果您能获得数据，那么您可以再指定两周时间，看看简单的模型是否表明机器学习解决方案可行。如果简单的模型失败，您可以再指定两周时间来尝试使用神经网络。在每个时间段结束时，您将获得更多信息，以便确定是否值得继续投入资源来解决此问题。
缩小项目要求的范围。如果某种机器学习解决方案看起来很有前景，但对您的产品或服务来说并不是一项关键功能，请缩小其要求的范围。例如，在规划下一季度的工作时，您可以计划尝试一个非常简单的解决方案。然后，在后续季度，您可以计划迭代改进解决方案。许多团队都是通过在较长的时间范围内逐步改进来实现机器学习解决方案，从而获得卓有成效的机器学习解决方案。
实习生或新员工项目。指引和指导实习生或新员工尝试使用机器学习解决方案，是开始探索未知结果的新领域的好方法。项目结束后，您将更好地了解实现 ML 解决方案所需的工作量，以及可能有前景的方法，或者是否应将资源用于其他方面。
对于任何策略，快速失败都是明智之举。先尝试成本最低但可能收益最高的方法。如果该方法有效，则说明您找到了合适的解决方案。如果没有，您也不会浪费大量时间和资源。
随着团队获得运行实验的经验，他们将能够更好地估算实验可能需要的工作量，从而提高规划的可预测性。不过，实验结果几乎总是未知的，因此无法事先估算找到最佳解决方案所需的实验次数。
采用实验性思维方式制定计划有助于您的团队取得成功。如果某种方法陷入了死胡同，团队成员不会因此而气馁，而是会理解这是寻找机器学习解决方案过程中的一部分。更重要的是，通过与利益相关方讨论机器学习开发中的固有不确定性，您可以设定更现实的预期。
检查您的理解情况
采用实验性思维规划机器学习开发有哪些好处？请选择所有适用的选项。
与利益相关方沟通机器学习开发过程中固有的不确定性。
确定最佳方法并优先解决。
您最初可能不知道哪种方法最适合。
注意事项
学习以概率方式规划多种机器学习方法需要时间和经验。您的项目计划可能需要经常更新。您可以将其视为一个动态文档，随着团队尝试多种方法而不断演变。通过重点关注以下关键要点，您可以提高成功几率：
- 估算每种方法的费用和成功几率。
- 尝试采用多种方法。
- 总结所收获的经验教训，并尝试一次改进一项系统。
- 针对故障进行规划。
有时，早期的方法会带来突破。有人可能会在数据生成流水线或训练-验证拆分中发现 bug。通过周密的规划和详尽的文档记录，您可以提高找到能够比预期更快解决业务问题的模型的可能性。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-27。
[null,null,["最后更新时间 (UTC)：2025-07-27。"],[[["\u003cp\u003eMachine learning (ML) projects are inherently uncertain, making it difficult to estimate timelines and predict effort due to their experimental and iterative nature.\u003c/p\u003e\n"],["\u003cp\u003eUnlike traditional software projects with clear paths, ML projects often require trying multiple approaches (data transformations, architectures, hyperparameters) to find the best solution.\u003c/p\u003e\n"],["\u003cp\u003eEffective ML project planning involves strategies like time-boxing tasks, scoping down requirements, and assigning projects to interns or new hires to explore feasibility and manage expectations.\u003c/p\u003e\n"],["\u003cp\u003eEmbracing an experimental mindset in ML development helps teams understand that failures and dead ends are part of the process, enabling better risk management and stakeholder communication.\u003c/p\u003e\n"],["\u003cp\u003eWhile experience improves effort estimation, the unpredictable nature of ML experiments necessitates dynamic project plans that evolve with learnings and breakthroughs.\u003c/p\u003e\n"]]],[],null,["# ML project planning\n\nPlanning ML projects is different than planning typical software engineering\nprojects. ML projects are characteristically non-linear and have varying degrees\nof uncertainty. They require an iterative approach and an experimental\nmindset.\n\nProject uncertainty\n-------------------\n\nEarly-stage planning can be difficult because the best approach typically isn't\napparent when beginning a project. This inherent uncertainty makes estimating\ntimelines hard.\n\nA recent [Kaggle](https://www.kaggle.com/) competition illustrates the\nuncertainty of ML projects. In the first few weeks of a competition, 350 teams\nparticipated. The top teams were able to increase the benchmark prediction\nquality from 35% to 65%. During the next two weeks, the number of teams working\non the problem increased from 350 to 1400. However, the best model only achieved\na prediction quality of 68%.\n\nFigure 3 illustrates the uncertainty in ML development by showing\nthe significant increase in effort but only minimal gains in model\nquality.\n\n**Figure 3**. Over a two week period, the number of teams working on the\nproblem increased by a factor of 4, but the model's quality stayed almost the\nsame, highlighting the difficulty in estimating effort of an ML solution.\n\nIn other words, over a thousand teams---each experimenting with a variety of\ndata transformations, architectures, and hyperparameters---only achieved\nproducing a model with 68% prediction quality.\n\nAn example from industry illustrates the non-linearity of ML projects,\nwhere the output isn't proportional to the inputs. Two teams\ntook several months to train a model to 90% prediction quality. However, it took\nseveral teams more than five years to get the model ready for production with\n99.9% prediction quality.\n\nThese examples highlight that production-ready ML is an exploratory process,\nrequiring both a scientific and engineering mindset.\n\nExperimental approach\n---------------------\n\nIn most cases, ML development is more like performing experiments than it is\npracticing traditional software engineering. ML requires testing different\nfeatures, trying multiple architectures, and tuning hyperparameters just right.\nBy definition, experiments aren't guaranteed to be successful. Because of this,\nit's best to plan using an experimental framework.\n\nLet's look at a typical software engineering plan to see how it's\ndifferent from an ML project plan.\n\n### Planning software engineering projects\n\nIn a typical software engineering plan, you define the requirements, outline the\ncomponents, estimate the effort, and schedule the work. There's a clearly\ndefined path to a solution. For example, engineers often know with a high degree\nof certainty the tasks they need to complete to build an application that meets\nthe\ndesign spec.\n\nWhen they predict the time it'll take to complete a task, they can estimate the\nwork based on similar projects. Although challenges invariably occur---like\nunknown dependencies or changing requirements---that can make estimating\nsometimes difficult, a clear path to the solution typically exists.\n\nIn contrast, ML projects don't normally have one clear path to success.\n\n### Planning ML projects\n\nFor most ML projects, you'll find the best solution by experimenting with\nmultiple approaches in a trial-and-error process. You won't typically know the\noptimal solution to your problem before attempting to solve it. For example, the\noptimal solution's architecture might be a simple linear model, or a neural net,\nor possibly a decision tree. Only by trying each approach can you discover the\nbest solution.\n\nThis ambiguity makes planning hard. As discussed previously, predicting the\neffort an ML project will require is difficult. Only by attempting to solve the\nproblem can you get a better sense for the amount of time and resources\na solution might require.\n\nThe following are recommended strategies for planning ML work:\n\n- **Time box the work**. Set clear timeframes to complete tasks or attempt a\n particular solution. For example, you might allocate two weeks to determine\n if you can get access to the right kind of data. If you can get the data,\n you then might designate two more weeks to see if a simple model indicates\n that an ML solution is feasible. If a simple model fails, you might\n designate two more weeks to try a neural net. At the end of each timeframe,\n you'll have more information to determine if\n continuing to apply resources to the problem is worthwhile.\n\n- **Scope down the project requirements**. If an ML solution appears promising\n but isn't a critical feature for your product or service, scope back its\n requirements. For example, when planning the next quarter's work, you might\n plan to try a very simple solution. Then in subsequent quarters, you\n might plan to iteratively improve the solution.\n Implementing an ML solution by making incremental improvements over a longer\n time horizon has been the way many teams have arrived at impactful ML\n solutions.\n\n- **Intern or new hire project**. Directing and guiding an intern or a\n new hire to attempt an ML solution can be a good way to begin exploring a\n new space with unknown outcomes. After the project is over,\n you'll have a better sense of the effort an ML solution will require and\n potentially promising approaches to pursue---or whether resources\n should be put somewhere else.\n\nWith any strategy, it's wise to fail fast. Attempt approaches with the lowest\ncosts, but potentially the highest payoff, first. If the approach works, you've\nfound a good solution. If it doesn't, you haven't wasted lots of time and\nresources.\n\nAs teams get experience and exposure to running experiments,\nthey'll be able to better estimate the effort an experiment might require,\nmaking planning more predictable.\nHowever, an experiment's outcome will almost always be unknown, so the number\nof experiments needed to find the best solution can't be estimated beforehand.\n\nPlanning approaches with an experimental mindset helps set your team up for\nsuccess. When an approach leads to a dead end, rather than being discouraged,\nteam members understand that's part of the process in finding an ML solution.\nMore importantly, by discussing the inherent uncertainty in ML development with\nstakeholders, you're able to set more realistic expectations.\n\n### Check Your Understanding\n\nWhat is a benefit of planning ML development using an experimental mindset? Select all that apply. \nTo identify and manage potential risks. \nTo decrease the time and resources spent on unsuccessful approaches. \nCommunicate with stakeholders the inherent uncertainty in ML development. \nTo identify the best approach and solve it first. \nYou won't initially know what approach will be the best one.\n\nKeep in mind\n------------\n\nLearning to plan multiple ML approaches probabilistically takes time and\nexperience. Your project plan might require frequent updates. Think of it as a\ndynamic document in constant evolution as your team experiments with multiple\napproaches. By focusing on the following key ideas, you'll increase your\nchances of success:\n\n- Estimate the cost and chance of success for each approach.\n- Attempt a portfolio of approaches.\n- Identify lessons learned and try to improve the system one thing at a time.\n- Plan for failures.\n\nOccasionally an early approach leads to a breakthrough. Someone might discover a\nbug in the data generation pipeline or training-validation split. With good\nplanning and thorough documentation, you increase the likelihood that you'll\nfind a model that solves your business problem sooner than expected."]]
