[FEATURE] Add train-type parameter to otx train

[sovrasov]

Currently, to enable SSL training we have to execute oxt build at the first step.
At the same time, otx train allows passing --unlabeled-data-roots, which causes a failure if otx build hasn't been executed before.
Therefore, CLI of otx train is contradictive and incomplete. This PR brings back missing ability to launch different training types right from otx train CLI.

This contradiction is caused by mixing two paradigms for launching a training: pre-configuration of a workspace and passing all the required arguments via CLI. The possible solutions are:

• restricting of otx train CLI.
• maintaining otx train CLI as a standalone and self-containing tool for configuring and launching trainings.

This PR follows the second option, but the first one deserves discussion as well.

[codecov-commenter]

Codecov Report

Patch coverage: 69.44% and no project coverage change.

Comparison is base (0e4a8b7) 80.54% compared to head (4b2ec68) 80.55%.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #1874   +/-   ##
========================================
  Coverage    80.54%   80.55%           
========================================
  Files          484      483    -1     
  Lines        33005    32968   -37     
========================================
- Hits         26585    26557   -28     
+ Misses        6420     6411    -9     

Impacted Files	Coverage Δ
...hms/classification/adapters/mmcls/data/datasets.py	76.86% <ø> (ø)
...odels/heads/custom_hierarchical_linear_cls_head.py	82.10% <ø> (ø)
...s/heads/custom_hierarchical_non_linear_cls_head.py	83.65% <ø> (ø)
otx/algorithms/common/tasks/training_base.py	53.27% <16.66%> (+0.03%)	⬆️
...dapters/openvino/model_wrappers/openvino_models.py	74.57% <50.00%> (ø)
otx/algorithms/detection/tasks/train.py	82.11% <50.00%> (ø)
otx/algorithms/detection/tasks/inference.py	73.56% <66.66%> (+0.13%)	⬆️
otx/algorithms/segmentation/tasks/inference.py	89.04% <66.66%> (+1.22%)	⬆️
otx/algorithms/classification/tasks/inference.py	86.84% <80.00%> (+0.61%)	⬆️
otx/algorithms/classification/utils/cls_utils.py	100.00% <100.00%> (ø)
... and 6 more

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[goodsong81]

LGTM. @harimkang Could you have a look?

[sungmanc]

I'm not sure why we should use otx build for SSL training. Users could use otx cli if they give train_params.
We currently use params --algo_backend.train_type to enable the different train types.

Example for SemiSL:

training_extensions/tests/e2e/cli/classification/test_classification.py

Line 291 in 0e4a8b7

class TestToolsMultiClassSemiSLClassification:

Example for SelfSL:

training_extensions/tests/e2e/cli/classification/test_classification.py

Line 715 in 0e4a8b7

args_selfsl = {

[harimkang]

I'm not sure why we should use otx build for SSL training. Users could use otx cli if they give train_params.

We currently use params --algo_backend.train_type to enable the different train types.

Example for SemiSL:

training_extensions/tests/e2e/cli/classification/test_classification.py

Line 291 in 0e4a8b7

class TestToolsMultiClassSemiSLClassification:

Example for SelfSL:

training_extensions/tests/e2e/cli/classification/test_classification.py

Line 715 in 0e4a8b7

args_selfsl = {

I agree to some extent, but vlad seems to want to improve the inconvenience. However, there can be conflicts between the two methods(use train_type / use params), and it seems that this could cause problems somewhere. (maybe not..?)

[sovrasov]

if self.mode in ("build", "train") and self.ar

_get_train_type method has a clear logic to extract training type from template & parameters: according to the code --train_type (when it's specified) will be used if params --algo_backend.train_type is not specified, so I don't expect any unpredictable behavior here.

[sovrasov]

I'm not sure why we should use otx build for SSL training. Users could use otx cli if they give train_params. We currently use params --algo_backend.train_type to enable the different train types.

Example for SemiSL:

training_extensions/tests/e2e/cli/classification/test_classification.py

Line 291 in 0e4a8b7

class TestToolsMultiClassSemiSLClassification:

Example for SelfSL:

training_extensions/tests/e2e/cli/classification/test_classification.py

Line 715 in 0e4a8b7

args_selfsl = {

params --... is also a correct way, but it's not documented and hard to discover (since otx train --help doesn't reveal that's hidden under the params section).

[sungmanc]

After this PR is merged, we need to consider eliminating params --algo_backend.train_type from the configuration.