Evalml: Проверки данных: JSON-дружественное сообщение fmt, включая перечисление типов и имена затронутых столбцов

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

{
  "message": "Warning: too many null values present in column 'foobar'",
  "check": "NullCheck",
  "code": "TOO_MANY_NULLS",
  "detail": {
    "level": "warning",
    "columns": ["foobar"]
  }
}

Это позволило бы выполнять форматирование результатов, не зависящее от языка, путем привязки code обратно к строкам интернационализации. А наличие метаданных, доступных в деталях, позволяет при желании отформатировать эту информацию обратно в сообщения, которые представлены в структурированном виде.

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

@BoopBoopBeepBoop спасибо. Мне нравится это предложение.

Вы ожидаете, что «код» будет перечислением или просто строкой, определенной где-то внутри проверки данных?

Я могу предложить одну настройку - сохранить структуру плоской:

{
  "message": "Warning: too many null values present in column 'foobar'",
  "code": "TOO_MANY_NULLS",
  "level": "warning",
  "columns": ["foobar"]
}

Здесь мы говорим в терминах JSON, но я считаю, что каждое из этих полей должно быть прикреплено к объекту DataCheckWarning / DataCheckError .

Это справедливо - я добавил туда эти элементы, поскольку в моей голове detail было "по сути картой". Однако это не лучшие примеры, потому что они, вероятно, присутствуют во всех проверках ...

Могут ли быть какие-либо ситуации, когда наши сообщения должны включать дополнительные метаданные, которые, по сути, присутствуют «для каждого сообщения»? Примеры, которые я видел раньше, - это вызов конкретных значений в качестве примеров, форматирование динамических нижних / верхних границ в сообщениях и т. Д. Обычно здесь вам выгодно иметь карту detail (или выбрать другое имя).

Вы ожидаете, что «код» будет перечислением или просто строкой, определенной где-то внутри проверки данных?

Я бы просто ожидал, что он будет стабильным - где он живет 🤷

Вы ожидаете, что «код» будет перечислением или просто строкой, определенной где-то внутри проверки данных?

Я бы просто ожидал, что он будет стабильным - где он живет 🤷

Если все равно, я бы предпочел перечисление. В настоящее время мы определяем наши собственные строки, чтобы определить, какие проверки запускать как часть задания, и было бы неплохо иметь перечисление, согласованное с EvalML, чтобы использовать его вместо создания наших собственных.

Наряду с этим и, возможно, в отношении того, что @BoopBoopBeepBoop упоминал с подробностями, может быть полезно узнать, какой тип ошибки был выдан. Например, при проверке столбца идентификатора EvalML проверяет, есть ли в имени столбца «идентификатор» или значения уникальны на N%. Мы можем захотеть отфильтровать первые или представить их по-другому, поэтому этот уровень детализации может быть полезен либо с помощью более детализированных перечислений, либо в чем-то похожем на детальную структуру, описанную выше.

Только что обсуждалось с @dsherry @freddyaboulton : я разместил https://github.com/alteryx/evalml/pull/1444, чтобы обновить наш API проверки данных, чтобы он возвращал словарь вместо списка предупреждений и ошибок. Имея в виду эту проблему, я обновлю свой PR, чтобы вернуть DataCheckResults где errors и warnings - атрибуты, а также добавлю метод to_json для класса, который будет возвращать сообщения в формате JSON, поскольку @BoopBoopBeepBoop предложил здесь с минимальной информацией - пока только сообщение и уровень.

Эта проблема останется открытой для отслеживания добавления дополнительных полей (таких как «код») к выходным данным JSON.

Спасибо @ angela97lin !

Итак, вот последнее предложение:

• Обновите DataCheck.validate и DataChecks.validate чтобы оба возвращали следующий формат:

{'errors': [...], 'warnings': [...]}

где каждая запись в приведенном выше формате имеет формат

{
  "message": "Warning: too many null values present in column 'foobar'",
  "code": "TOO_MANY_NULLS",
  "level": "warning",
  "columns": ["foobar"]
}

• Определите перечисление DataCheckMessageCode для заполнения поля code выше.
• Удалите классы DataCheckMessage , DataCheckError и DataCheckWarning в пользу формата dict выше.

Есть ли какие-либо возражения / комментарии, прежде чем мы построим это? @ tyler3991 @Cmancuso @BoopBoopBeepBoop @ angela97lin @freddyaboulton

( @ angela97lin @freddyaboulton Я начал печатать версию этого предложения с классом DataCheckResults , а затем решил, что мы должны просто вернуть JSON-ified сверху, а не определять другой класс. Функционально эквивалентен, но не использование класса проще. Все, что будет делать класс результатов, - это хранить ту же информацию, не добавляя к нему других функций. LMK, если вы считаете, что это плохая идея.)

Поговорил с DataCheckMessage внутри для удобства /, чтобы людям было труднее определять недопустимые записи сообщений. Но validate вернет JSON-совместимый dict dict, как определено выше.

( @ angela97lin, если это не соответствует тому, что мы только что обсуждали, поправьте меня!)

Настройте это с помощью @ angela97lin . Последний:

{
  "message": "Warning: too many null values present in column 'foobar'",
  "code": "TOO_MANY_NULLS",
  "data_check_name": "HighlyNullDataCheck",
  "level": "warning",
  "details": {
    "columns": ["foobar"]
  }
}

где клавиша «детали» может содержать любую информацию, которую требуется вернуть при проверке данных. И он будет пропущен, если нечего включать.

Нам необходимо обновить следующие проверки данных, чтобы включить столбцы, которые не прошли проверку: очень null, ID и целевая утечка. Бонус, если мы обновим и другие проверки данных :)

Это в основном то, что предлагал @BoopBoopBeepBoop ! ✨ @Cmancuso К вашему сведению