[RFC] Engine Refactor Proposal | Alternative 2

[ashwinvaidya17]

Motivation

Refer to #3752 for the motivation

This PR proposes an alternative design. It also includes one solution to register heterogeneous models to the CLI (there might be better approaches).

def test_engine_anomaly():
    model = Padim()
    engine = Engine(model)
    datamodule = MVTec(root="./datasets/MVTec")
    engine.train(datamodule)
    assert isinstance(engine, AnomalyEngine)


def test_engine_classification():
    datamodule = OTXDataModule(
        task=OTXTaskType.MULTI_CLASS_CLS,
        ...
    )
    model = MobileNetV3ForMulticlassCls(
        label_info=datamodule.label_info,
    )
    engine = Engine(model)
    engine.train(datamodule, max_epochs=1, deterministic=False, val_check_interval=0.5)
    assert isinstance(engine, LightningEngine)


def test_engine_ultralytics():
    model = YOLO("yolov8n.pt")
    engine = Engine(model)
    dataset = ClassificationDataset(root="./datasets/hazelnut_toy", args=DEFAULT_CFG)
    dataloader = DataLoader(dataset, batch_size=32, shuffle=True)
    engine.train(datamodule=dataloader)
    assert isinstance(engine, UltralyticsEngine)

[harimkang]

Currently, the role of auto-configuration is to check for task, data, and model inputs, regardless of the engine, and provide default settings for anything the user hasn't entered. Is there any reason to configure the engine internally? If it's just for the backend, it would be nice to have a different way to configure the default for each backend rather than configuring the engine directly. What do you think?

[harimkang]

Engine -> AutoConfigurator -> Engine : I think their relationship with each other is strange.

[harimkang]

As we talked about, the arguments in BaseEngine will be the same as those in the current otx Engine, only the Type will be made more general as needed, right?

[harimkang]

There's still a model here, which I think might be confusing for people looking at this PR.