Evalml: 数据检查:JSON 友好的消息 fmt,包括类型枚举和受影响的列名

创建于 2020-11-12  ·  9评论  ·  资料来源: alteryx/evalml

这将使以编程方式识别哪个或哪些功能具有特定错误或警告变得容易。

enhancement

最有用的评论

@angela97lin调整这个。 最新的:

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

其中“详细信息”键可以保存数据检查想要返回的任何信息。 如果没有要包含的内容,它将被省略。

我们需要更新以下数据检查以包含检查失败的列:高度为空、ID 和目标泄漏。 如果我们还更新其他数据检查,则奖励:)

这基本上就是@BoopBoopBeepBoop提出的! ✨ @Cmancuso仅供参考

所有9条评论

轻微扩展:为了启用其他编程格式和国际化,如果 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提到的细节,了解抛出哪种类型的错误可能会有所帮助。 例如,在 ID 列检查中,EvalML 会检查列名中是否包含“id”或值是否为 N% 唯一。 我们可能希望过滤掉前者或以不同的方式表示它们,因此这种粒度级别可能很有用,无论是通过更粒度的枚举还是类似于上述详细结构的东西。

刚刚与@dsherry @freddyaboulton讨论过:我已经提供了https://github.com/alteryx/evalml/pull/1444来更新我们的数据检查 API 以返回字典而不是警告和错误列表。 考虑到这个问题,我将更新我的 PR 以返回DataCheckResults其中errorswarnings是属性,并添加一个to_json方法对于将返回 JSON 格式的消息的类,正如@BoopBoopBeepBoop在这里建议的那样,信息最少——现在,只有消息和级别。

此问题将保持开放以跟踪向 JSON 输出添加更多字段(例如“代码”)。

谢谢@angela97lin

所以这是最新的提议:

  • 更新DataCheck.validateDataChecks.validate以返回以下格式:
{'errors': [...], 'warnings': [...]}

上面的每个条目的格式都是

{
  "message": "Warning: too many null values present in column 'foobar'",
  "code": "TOO_MANY_NULLS",
  "level": "warning",
  "columns": ["foobar"]
}
  • 定义一个DataCheckMessageCode枚举来填充上面的code字段。
  • 删除DataCheckMessageDataCheckErrorDataCheckWarning类以支持上面的 dict 格式

在我们构建这个之前有任何反对意见/评论吗? @tyler3991 @Cmancuso @BoopBoopBeepBoop @angela97lin @freddyaboulton

@angela97lin @freddyaboulton我开始用DataCheckResults类输入这个提案的一个版本,然后决定我们应该简单地从上面返回 JSON 化的 dict,而不是定义另一个类。功能等效,但不是使用该类更简单。所有结果类都会保存相同的信息,而不是向其添加其他功能。LMK,如果您认为这是一个坏主意。)

@angela97lin讨论了这个 RE PR #1444。 上面的计划没有变化,除了她可能会选择在内部保留DataCheckMessage类以方便/使人们更难定义无效的消息条目。 但是validate将返回上面定义的 JSON-able dicts。

@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"]
  }
}

其中“详细信息”键可以保存数据检查想要返回的任何信息。 如果没有要包含的内容,它将被省略。

我们需要更新以下数据检查以包含检查失败的列:高度为空、ID 和目标泄漏。 如果我们还更新其他数据检查,则奖励:)

这基本上就是@BoopBoopBeepBoop提出的! ✨ @Cmancuso仅供参考

此页面是否有帮助?
0 / 5 - 0 等级