1. Применить для scoring example несколько AutoML фреймворков (файлы для скорингового примера лучше брать из ветки refactor-evo-strategy.
2. Попробовать вывести информацию о отобранных признаках, виде модели и её настройках, которые получаются в ходе оптимизации.
3. Сохранить полученную в ходе оптимизации модель для быстрого воспроизведения результата.

Нужно сгенерить несколько датасетов, на которых можно выявить,

1. не пытается ли модель обучаться на test и valid части
2. не переобучается ли она на любых доступных train-данных

В датасетах можно делать разные комбинации:

1. корректный train, случайный test
2. случайные train и test
3. случайный train, корректный test
   и аналогичный комбинации с valid-выборкой (как в скоринговом примере)

Скорее всего, сейчас эти тесты будут падать.

Код EPDE - в FEDOT.Algs

Это нужно для того, чтобы не менять число поколений и индивидов в скоринговом примере, а передавать просто число минут, после которого алгоритм вырубится по таймеру. Опцию передачу поколений и размера популяции можно сохранить, но сделать необязательно. Если время -1 - то время не учитывается.

• если получится, добавить прогрессбар, отображающий прогресс композирования и достигнутые результаты на тестовой и валидационной выборках.

Пример реализации можно посмотреть в tpot(код связанный с EpistasisLab/tpot#723)

Проверка корректности композирующих алгоритмов на задаче воспроизведения заранее известных цепочек

1. PrimaryNode и SecondaryNode вместо ModelNode и OperationNode.
2. Добавить класс Model. Изменить иерархию классов EvaluationStrategy.
3. Переделать evalutate под новый класс данных Data.
4. Добавить каркас для Chain и Composer.

На основе имеющегося алгоритма GP

• описание для документации

Воспроизводится на penn-ml

https://stackoverflow.com/questions/47312432/attributeerrorlinearsvc-object-has-no-attribute-predict-proba

Нужно реализовать mock для ModelTypesRepository в этом и остальных тестов в этом скрипте.

Сейчас у репозитория в конструкторе создается и инициализируется поле "дерево" - self._tree.
Для удобства в тесте нужно сделать mock на это поле, чтобы не было дублирования (как сейчас)

Можно ориентироваться на те, что упомянуты в
https://github.com/EpistasisLab/tpot/blob/master/tpot/config/regressor.py

Модели: только ML
Операции: только ансамблирование

• Взять улучшенную реализацию случайного композера из composer-experiments
• Сравнить функции генерации случайных деревьев из composer-experiments и chain-regularisation/master.
  (см #80 (comment))

https://github.com/J3FALL/THEODOR/blob/master/core/composer/gp_composer/gp_composer.py#L29 тут разве не

super(GPComposer, self).__init__()

?

В первую очередь интересна мутация, обеспечивающая удаление моделей.
Над подходящими кроссоверами надо подумать.

По результатам обсуждений
+Нарисовать диаграмму для документации.

Нужно реализовать запуск FEDOT для задач из penn-ml-benchmarks.
Примеры можно посмотреть в папках cases и tests.

Осталось только добавить XGBoost и KNN.
Яна уже реализовала KNN в ветке gp-composer - можно попробовать взять оттуда.

1. Реализовать генерацию случайных синтетических датасетов.
2. Обучить на них набор моделей.
3. Сформировать на их основе случайные цепочки произвольной структуры.
4. Ввести метрики качества для таких тестов (качество, робастность, сходимость etc)
5. Выполнить тесты по оценке эффективности для существующего ГП-композера (насколько "хорошо" восстановливается структра дерева).

Сейчас много дублирующихся методов для создания датасетов, цепочек, etc.

Чтобы дать возможность спрогнозировать время расчета цепочки

Взять несколько простых моделей (например, лин. регресссий), вручную создать цепочку нод и реализовать "раскручивание" моделей при вызове последней из них.

Т.е. математически что-то вроде этого должно получиться:

y = a1(a2(a3*x+b3)+b2)+b1

Расширенное описание:

Сейчас у нас есть модели в отдельных нодах и их можно выполнять (как это сделано, например, в тесте test_eval_strategy_logreg)

Но выполнение отдельных моделей не особо полезно.
Нужна ещё и функциональность выполнения цепочек моделей, когда следующая модель принимает на вход результат предыдущей.

Тогда при вывозе метода apply в последней в цепочке ноде должны выполняться все предшествующие её ноды , и только потом - вызванная.

Где a и b - коэфициенты линейных регрессионных моделей

Сами цепочки будет составлять композирующий алгоритм, но это отдельная таска - пока их можно собрать вручную из самый простых моделей (например, лин. регрессий).

Данные можно взять любые, не обязательно получившаяся модель должна быть эффективной - главное, чтобы при вывозе apply в ноде 4 выполнялся подсчет в node1, node2, node3, потом обучалась и выполнялась модель в node 4.

Ну и учитывать что уровней такой иерархии может быть больше двух.

Что нужно сделать:
0) Подготовать данные SSH, которые использовались в
https://niuitmo-my.sharepoint.com/:w:/g/personal/240590_niuitmo_ru/EdtbfZ7BHclCuzz1sg0yN2MBDN23F08KbVT3lAau6EgKGg?e=UgPVGo

1. Добавить твою реализацию LSTM в evaluation.py (и соответсвующие enum-ы - см. существующие модели). Инструкция есть тут:
   https://github.com/ITMO-NSS-team/FEDOT.Algs/wiki/How-to-embed-custom-model-into-the-Fedot-pipeline

2. Попробовать запустить прогнозирование по аналогии с ARIMA в metocean_forecasting_problem.py
   [тут нужно добавить регрессионные модели и оператор разности между рядами, сделаю сам]

3. Запустить итоговый модельный сетап.

Если LSTM обучается долго - возможно есть смысл сохранять обученную модель на диск.

Для начала можно сделать на примере TPOT и MLBOX, как наиболее легковесных.

Пример:

Можно по аналогии с тем, как это сделано в https://www.researchgate.net/publication/338883598_An_Adaptive_and_Near_Parameter-free_Evolutionary_Computation_Approach_Towards_True_Automation_in_AutoML
можно что-то более интересное придумать.

По аналогии с:

+Описать требования к формату (для документации).

Сейчас процент покрытия отображается некорректно (84% было месяца 3 назад, кажется).
Надо разобраться, почему coveralls не обновляет эти значения.
Это можно исправить уже после переноса репозитория в ITMO.NSS_Team ближе к публичному релизу.

Сейчас при наличии в датасете текстовых колонок обработка данных ломается. Нужно учесть такую возможность.

Описание предлагаемой реализации:

В FEDOT.Algs мы реализуем именно алгоритмы оптимизации деревьев (символьных, gp, ast - можем как угодно их называть. Соответственно, для удобства нужен интерфейс типа GPTree (в котором есть все нужные методы для работы с узлами).

В ядре остается композеры и его реализации, в частности, GPComposer. Их единственная ответственность - композировать цепочки(copose_chain).

Внутри GPComposer::compose_chain импортируется GPOptimizer. Для того, чтобы его использовать, мы сначала конвертируем Chain в GPTree, и оптимизируем его. Результат конвертируется обратно в Chain. В Jav-е есть идеально подходящая штука для таких вещей - анонимные классы. Т.е. мы могли бы объявить анонимный класс, в котором реализовать методы класса GPTree: add_node, root_node и т.д. (частично делегируя вызовы методов GPTree
методам Chain). В питоне, к сожалению, я знаю, как это сделать дешево и по аналогии.
Да, при таком подходе ядро явно завязывается на FEDOT.Algs, но, имхо, это нормально, т.к. алгоритмы сами по себе - вещь более абстрактная, чем сборка цепочек из моделей ML. Зато сами алгоритмы оптимизации цепочек теперь можно использовать, совершенно не привязываясь к композеру и т.д.

Сейчас в https://github.com/nccr-itmo/FEDOT/blob/master/core/composer/visualisation.py есть вариант с помощью networkx, но он:

1. требует громоздкой установки graphviz (https://itmo-nss-team.github.io/FEDOT.Docs/fedot/quick-start)
2. дает не слишком красивые и гибкие визуализации
3. недостаточно информативен (не выводятся гиперпараметры моделей).

Необходимо вместо него реализовать нативный вариантат отрисовки.

Вот тут есть оч. старая реализация кастомной отрисовки моделей, но это совсем примитивный вариант.
https://github.com/nccr-itmo/FEDOT/blob/custom_visualise/core/composer/tree_drawing.py

Сейчас при каждом составлении цепочки все ноды пересоздаются и поэтому обучаются заново (кэш теряется).

Из-за этого на композирование уходит много времени. Нужно реализовать preserving нод, которые не затронуты мутацией или кроссовером.

Доработки и рефакторинг после показа:

1. Отрицательные значения метрик (см. ROC AUC): добавить property для метрик, которые передаются алгоритму оптимизации.
2. Хранение reference_data в chain - тут нужно подумать.
3. Обработка Nan-ов в EvaluationStrategy.
4. Дублирование кода в models. Возможно, добавить прослойку для SKLearn/ML Model.
5. TBA

С помощью Readthedocs или чего-то аналогичного

Композитный классификатор на основе агрегированных данных кредитного скоринга

Сейчас композер выдаёт излишне сложные цепочки, если жестко не ограничить глубину дерева.

Это можно попробовать исправить вот так: в отличие от большинства задач ГП, у нас дорогой является лишь задача обучения модели. Сделать предсказание относительно дешево.

Поэтому, для каждого уже обученного дерева моделей мы можем бесплатно посчитать фитнес также для каждого из его поддеревьев (т.к. заново обучать их не требуется).
Т.е. можно в композер ввести оператор "регуляризации", который будет сводить дерево к простейшему поддереву (и или заменять оригинал, или вкидывать его в популяцию в одном или нескольких экземплярах).

• split_train_test
• data_from_file
• _to_numerical
• инициализация seed
• etc
• сделать рефакторинг файлов и папок в тестах

Потом будет выложено на гитхаб в качестве доп. документации

Проверки для chain на :

• отсутствие циклов
• отсутствие изолированных нод и подграфов
• отсутствие нескольких корневых нод
• отсутствие нод, ссылающихся сами на себя
• наличие primary-нод
• другие проверки, если таковые можно придумать

Можно вызывать такой метод каждый раз при добавлении ноды в chain.