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 이 세부 사항과 함께 언급한 내용에 대해 어떤 유형의 오류가 발생했는지 아는 것이 도움이 될 수 있습니다. 예를 들어 ID 열 검사에서 EvalML은 열 이름에 "id"가 있는지 또는 값이 N% 고유한지 확인합니다. 전자를 걸러내거나 다르게 표현하기를 원할 수 있으므로 이 수준의 세분성은 더 세분화된 열거형을 통해 또는 위에서 설명한 세부 구조와 유사한 것을 통해 유용할 수 있습니다.

@dsherry @freddyaboulton 과 방금 논의했습니다: 경고 및 오류 목록 대신 사전을 반환하도록 데이터 검사 API를 업데이트하기 위해 https://github.com/alteryx/evalml/pull/1444 를 올렸습니다. 이 문제를 염두에 두고 errors 및 warnings 가 속성인 DataCheckResults 를 반환하도록 PR을 업데이트하고 to_json 메서드를 추가합니다. @BoopBoopBeepBoop 이 제안한 것처럼 JSON 형식의 메시지를 반환할 클래스에 대해 최소한의 정보로 지금은 메시지와 수준만 제공합니다.

이 문제는 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 필드를 채우기 위해 DataCheckMessageCode 열거형을 정의합니다.
• 위의 dict 형식을 위해 DataCheckMessage , DataCheckError 및 DataCheckWarning 클래스를 삭제합니다.

우리가 이것을 구축하기 전에 어떤 반대/의견이 있습니까? @tyler3991 @Cmancuso @BoopBoopBeepBoop @angela97lin @freddyaboulton

( @angela97lin @freddyaboulton DataCheckResults 클래스를 사용하여 이 제안의 버전을 입력하기 시작한 다음, 다른 클래스를 정의하는 대신 위에서 JSON-ified dict를 반환하기만 하면 됩니다. 기능적으로 동등하지만 그렇지 않습니다. 클래스를 사용하는 것이 더 간단합니다. 결과 클래스가 수행하는 모든 결과는 동일한 정보를 유지하고 다른 기능을 추가하지 않는 것입니다. 나쁜 생각이라고 생각하면 LMK입니다.)

이 RE PR #1444에 대해 @angela97lin과 대화했습니다 . 그녀가 내부적으로 DataCheckMessage 클래스를 유지하도록 선택할 수 있다는 점을 제외하고 위의 계획은 변경되지 않았습니다. 그러나 validate 는 위에 정의된 JSON 가능 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"]
  }
}

여기서 "details" 키는 데이터 검사에서 반환하려는 모든 정보를 보유할 수 있습니다. 그리고 포함할 내용이 없으면 생략합니다.

검사에 실패한 열을 포함하도록 다음 데이터 검사를 업데이트해야 합니다. 높은 null, ID 및 대상 누출. 다른 데이터 검사도 업데이트하면 보너스 :)

이것은 기본적으로 @BoopBoopBeepBoop이 제안한 것입니다! ✨ @Cmancuso