Sergey

> I am having the same problem on a jupyter-notebook on windows. using `multiprocessing.set_start_method('fork')` gives the following error: 'ValueError: cannot find context for 'fork'' Because there is the one [choice](https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods)...

Задача актуальна для целых ветвей графа. 

Еще в копилку того, что можно фиксить. 

> Тут нюанс ещё в том что у этих веток могут быть разные гиперпараметры. Думал про это. Была еще мысль, что можно оставлять две ветки, чтобы они могли мутировать параллельно....

Solved by https://github.com/aimclub/GOLEM/pull/182.

В https://github.com/aimclub/FEDOT/pull/1138 включена стратификация при разделении данных на выборки для задач классификации. Проблема должна быть исчерпана.

Текущий список моделей (неполный): Регрессия - XGBRegressor - AdaBoostRegressor - GradientBoostingRegressor - DecisionTreeRegressor - ExtraTreesRegressor - RandomForestRegressor - SklearnLinReg - SklearnRidgeReg - SklearnLassoReg - SklearnSVR - SklearnSGD - LGBMRegressor -...

Предлагаю уменьшить количество моделей для композиции. Основная мотивация - сократить пространство поиска оптимального пайплайна. Логика устранения: тяжелые или дублирующие друг друга модели. 1. Для регрессии: 1. `SklearnLinReg` - отлично заменяется...

> The best practices should be derived from state-of-the-art frameworks (TPOT, etc) to remove non-effective and add new models. Я глянул списки моделей в TPOT и AutoGluon. Там очень много...

Наиболее оптимальный вариант, кмк, создать укрупненные `operations`, отвечающие за классы моделей. Например, `operation`, отвечающие за леса, за градиентные бустинги, за линейные модели, и т.д.. На этапе композиции использовать эти `operations`,...