将 AutoML 用于大型数据集会带来与计算资源、数据预处理和模型可解释性相关的挑战。 AutoML 工具可以自动执行特征工程、模型选择和超参数调整等任务，但是扩展这些过程以处理海量数据集通常需要仔细的优化。 开发人员必须在自动化与硬件限制和处理时间等实际约束之间取得平衡，尤其是在处理超出可用内存或需要分布式计算的数据时。
一个主要的挑战是计算效率。 AutoML 系统通常会探索许多模型架构和超参数，这对于大型数据集而言，计算成本会变得非常高。 例如，训练一个具有数百万行数据的神经网络可能需要每次迭代花费数小时，而 AutoML 的试错方法可能会使此时间大大增加。 像 Google 的 Vertex AI 或 H2O.ai 这样的工具如果没有专门的基础设施（例如 GPU 或分布式集群），可能难以扩展。 即使是交叉验证之类的简单任务也可能会成为瓶颈 - 将 100GB 的数据集分成 5 个部分进行验证，需要重复处理 80GB 的块，这会给内存和存储带来压力。 开发人员可能需要手动优化管道（例如，使用稀疏数据格式或抽样）以减少开销，从而破坏了 AutoML 的“自动化”承诺。
另一个问题是数据质量和预处理。 AutoML 工具通常假定数据干净且结构良好，但是大型数据集更可能包含噪声、缺失值或冗余特征。 例如，一个包含 1000 万个客户记录的数据集可能包含数千个不相关的列，需要 AutoML 可能无法有效处理的特征选择。 像 Auto-sklearn 或 TPOT 这样的工具可以自动执行一些预处理，但是它们可能无法很好地扩展 - 将 one-hot 编码应用于 1TB 数据集中具有 10,000 个唯一值的分类列可能会使系统崩溃。 开发人员可能需要在应用 AutoML 之前手动预处理数据（例如，聚合类别或使用嵌入），这会增加复杂性并破坏端到端自动化的目标。
最后，使用大规模 AutoML，模型的可解释性和维护变得更加困难。 大型数据集通常会导致难以调试或解释的复杂模型（例如，深度学习集成）。 例如，AutoML 系统可能会选择具有 500 个估计器的梯度提升树集成，以最大程度地减少 terabyte 级数据集上的误差，但是向利益相关者解释特征重要性或预测变得不切实际。 此外，随着数据的发展，重新训练模型需要重新运行整个 AutoML 管道，这对于实时应用程序而言可能不可行。 开发人员可能需要实施自定义监视或退回到更简单的模型，从而降低自动化的好处。 在扩展 AutoML 时，在性能提升与透明性和可维护性之间取得平衡仍然是一个关键障碍。