Evalml: Поддержка параметризации проверок данных; заставить InvalidTargetDataCheck проверить цель, используя problem_type

Созданный на 15 июл. 2020  ·  6Комментарии  ·  Источник: alteryx/evalml

Исправления #970 .

Согласно обсуждению с @freddyaboulton в #929, было бы неплохо, если бы мы могли передавать дополнительную информацию в DataChecks. Это потребует обновления API DataCheck и рассмотрения того, как он взаимодействует с AutoML, поскольку мы не создаем экземпляр DataChecks, а только передаем класс DataChecks в качестве параметра search() .

enhancement

Самый полезный комментарий

Знаете что, @angela97lin @freddyaboulton , давайте воспользуемся этой проблемой, чтобы отслеживать как а) обновление automl и API проверки данных для поддержки параметризации, так и б) обновление InvalidTargetDataCheck для проверки цели и создания интеллектуальных ошибок для всех целей типы, которые мы поддерживаем.

Упоминание, потому что я только что зарегистрировал ошибку № 970, и при ближайшем рассмотрении проблема будет исправлена ​​​​выше. Так что это закроет # 970.

Все 6 Комментарий

@ angela97lin angela97lin , не могли бы вы описать вариант использования этого?

@dsherry Конечно! В #929 @freddyboulton и я обсуждали, как было бы хорошо, если бы InvalidTargetDataCheck мог быть еще более полезным, если бы знал о типе проблемы, с которой он справляется. Например, если бы мы знали, что наша проблема связана с бинарной классификацией, но входные данные для проверки данных содержали более двух классов, мы могли бы выдать предупреждение/ошибку. Следовательно, было бы неплохо иметь возможность каким-то образом передавать параметры или просто дополнительную информацию для проверки данных. К сожалению, это не очень хорошо работает с нашим текущим дизайном, где мы передаем классы, а не экземпляры.

В качестве альтернативы мы могли бы создать классы проверки данных для каждого типа проблемы, такие как BinaryClassificationInvalidTargetDataCheck, но это также может стать довольно сложным при определении того, что должны включать DefaultDataChecks (или это тоже должно быть разбито на DefaultBinaryClassificationDataChecks?)

Только что обсуждалось с @angela97lin @freddyboulton

Нам нравится идея зеркально отразить шаблон, который мы используем для component_graph в конвейерах:

  • Список проверок данных может быть указан изначально для автоматического поиска как список подклассов DataCheck (или то же самое, но внутри DataChecks ), а не экземпляров
  • Как только automl search захочет запустить проверку данных, он может создать экземпляр класса DataChecks
  • В этот момент мы бы передали ему словарь data_check_parameters , аналогичный нашему конвейеру parameters , который содержит необязательную конфигурацию для одной или нескольких проверок данных.
  • Если пользователи хотят использовать DataChecks напрямую, они могут следовать аналогичному шаблону.
  • data_check_parameters по умолчанию должен быть равен None , поэтому людям не нужно создавать это, если это не требуется. Но если в проверке данных отсутствует обязательный аргумент (например, problem_type для некоторых), это должно привести к ошибке инициализации.

Вот набросок того, как это может выглядеть в автоматическом поиске:

# today this helper standardizes the input to a list of `DataCheck` instances, and wraps that in a `DataChecks` instance
# after this work, this would standardize the input to a `DataChecks` class.
# if `data_checks` was already a `DataChecks` class, do nothing. else if `data_checks` is a list of `DataCheck` classes, define a `AutoMLDataChecks` class to wrap and return that
data_checks_class = self._validate_data_checks(data_checks)
# next we create the `DataChecks` instance by passing in data checks parameters
data_check_parameters = {'Target Datatype Data Check': {'problem_type': self.problem_type}}
data_checks = data_checks_class(data_check_parameters)
data_check_results = data_checks.validate(X, y)

Прямое использование будет выглядеть аналогично.

Следующие шаги

  • @angela97lin @freddyaboulton другие просматривают приведенный выше скетч и проверяют его на вменяемость.
  • @angela97lin зарегистрирует проблему, чтобы отслеживать добавление проверки данных TargetDatatype (название подлежит уточнению), основываясь на нашем обсуждении #960 . Для этой проверки данных потребуется передать параметр problem_type в
  • Тот, кто поднимет эту проблему, должен одновременно поднять эту проблему на TargetDatatype и построить это! 🛠️ 😁

@dsherry План мне кажется хорошим! Единственное, что я хотел бы добавить, это то, что я предпочитаю расширять уже существующую InvalidTargetDataCheck , а не создавать новую проверку данных, но любой из этих подходов мне подойдет. Кто бы ни взял это, убедитесь, что цель имеет только два уникальных значения, когда problem_type является двоичным. Об этом упоминалось в обзоре №929.

if problem_type == "binary" and len(set(y)) != 2:
    # Warn that we do not have two unique values in y

Знаете что, @angela97lin @freddyaboulton , давайте воспользуемся этой проблемой, чтобы отслеживать как а) обновление automl и API проверки данных для поддержки параметризации, так и б) обновление InvalidTargetDataCheck для проверки цели и создания интеллектуальных ошибок для всех целей типы, которые мы поддерживаем.

Упоминание, потому что я только что зарегистрировал ошибку № 970, и при ближайшем рассмотрении проблема будет исправлена ​​​​выше. Так что это закроет # 970.

@dsherry Как своевременно! Это звучит хорошо для меня 😊

Была ли эта страница полезной?
0 / 5 - 0 рейтинги