嘿，@ericxsun,很好的建议！我认为Ludwig确实应该支持更复杂的训练过程，如GANs,只是在这些情况下正确的用户体验是什么问题。
如果我们单独考虑生成器和判别器，它们都可以作为不同的Ludwig模型定义来表示。然后复杂性在于训练过程本身。具体来说，我们需要支持以下内容：

• 每个配置多个模型
• 多个优化器(例如，一个Mapmodel_name: optimizer)
• 在不同模型之间切换的策略
• 判别器：使用生成器的输出来增强训练数据集(标签=假)
• 生成器：自定义损失函数，将判别器的输出纳入其中
• 生成器：能够在合成(随机噪声)数据上进行训练的能力
• 生成器：为图像、音频和其他我们希望生成的类型添加解码器

我认为这些都是提高Ludwig灵活性的好一般改进。如果你觉得我遗漏了什么，请告诉我。

另外值得一提的是，类似的事情今天应该可以通过train_online API用编程方式实现。例如：

generator = LudwigModel(generator_config)
discriminator = LudwigModel(discriminator_config)

real_samples = load_dataset()

for epoch in epochs:
    synthetic_dataset = generate_random_noise()
    generator.train_online(synthetic_dataset)

    generated_samples = generator.predict(generate_random_noise())
    combined_dataset = merge(generated_samples, real_samples)

    discriminator.train_online(combined_dataset)

采用这种方法，目前唯一缺失的部分是生成器(以及解码器，如果你使用的是图像或音频数据)的自定义损失函数，但这应该是可以解决的。

太好了，我来看看。非常感谢。

我同意@tgaddair的观点，但这里有一个警告，那就是目前在Ludwig中没有支持在两个LudwigModel示例之间流动的梯度。这意味着当你训练判别器时，生成器不会被更新。
我们需要考虑如何实现这一点，这可能会对内部产生影响。
我们还在考虑另一个替代方案，即允许更自定义Ludwig管道的实际模型部分。我们认为这个改变将使GAN类似的训练过程成为可能，尽管它不会比几个版本更早到来。