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 इस बात की जांच करता है कि कॉलम नाम में "id" है या मान N% अद्वितीय हैं। हम पूर्व को फ़िल्टर करना चाहते हैं या उन्हें अलग तरह से प्रस्तुत करना चाहते हैं, इसलिए ग्रैन्युलैरिटी का यह स्तर उपयोगी हो सकता है, या तो अधिक दानेदार एनम के माध्यम से या ऊपर वर्णित विवरण संरचना के समान कुछ में।

बस @dsherry @freddyaboulton के साथ चर्चा की: मैंने चेतावनियों और त्रुटियों की सूची के बजाय एक शब्दकोश वापस करने के लिए हमारे डेटा चेक एपीआई को अपडेट करने के लिए https://github.com/alteryx/evalml/pull/1444 लगाया था। इस मुद्दे को ध्यान में रखते हुए, मैं अपने पीआर को DataCheckResults वापस करने के लिए अपडेट करूंगा जहां errors और warnings विशेषताएँ हैं, साथ ही साथ to_json विधि भी जोड़ें उस वर्ग के लिए जो JSON स्वरूपित संदेशों को @BoopBoopBeepBoop ने यहाँ सुझाया है, न्यूनतम जानकारी के साथ - अभी के लिए, केवल संदेश और स्तर।

JSON आउटपुट में और फ़ील्ड जोड़ने (जैसे "कोड") को ट्रैक करने के लिए यह समस्या खुली रहेगी।

धन्यवाद @ एंजेला97लिन !

तो यहाँ नवीनतम प्रस्ताव है:

• DataCheck.validate और DataChecks.validate को अपडेट करें ताकि दोनों निम्न प्रारूप लौटा सकें:

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

जहां उपरोक्त में प्रत्येक प्रविष्टि प्रारूप की है

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

• उपरोक्त code फ़ील्ड को पॉप्युलेट करने के लिए DataCheckMessageCode एनम को परिभाषित करें।
• DataCheckMessage , DataCheckError और DataCheckWarning कक्षाओं को उपरोक्त तानाशाही प्रारूप के पक्ष में हटा दें

इसे बनाने से पहले कोई आपत्ति/टिप्पणी? @tyler3991 @Cmancuso @BoopBoopBeepBoop @angela97lin @freddyaboulton

( @angela97lin @freddyaboulton मैंने इस प्रस्ताव के एक संस्करण को DataCheckResults वर्ग के साथ टाइप करना शुरू किया, और फिर फैसला किया कि हमें किसी अन्य वर्ग को परिभाषित करने के बजाय ऊपर से JSON-ified dict वापस करना चाहिए। कार्यात्मक रूप से समकक्ष, लेकिन नहीं कक्षा का उपयोग करना सरल है। सभी परिणाम वर्ग जो कर रहा होगा, वही जानकारी रख रहा है, इसमें अन्य कार्यक्षमता नहीं जोड़ रहा है। एलएमके अगर आपको लगता है कि यह एक बुरा विचार है।)

इस RE PR #1444 के बारे में @angela97lin से बात की। उपरोक्त योजना अपरिवर्तित है, सिवाय इसके कि वह सुविधा के लिए DataCheckMessage कक्षाओं को आंतरिक रूप से रखने का विकल्प चुन सकती है / लोगों के लिए अमान्य संदेश प्रविष्टियों को परिभाषित करना कठिन बना सकती है। लेकिन validate जैसा कि ऊपर परिभाषित किया गया है, एक JSON- सक्षम तानाशाही लौटाएगा।

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

जहां "विवरण" कुंजी कोई भी जानकारी रख सकती है जिसे डेटा चेक वापस करना चाहता है। और अगर इसमें शामिल करने के लिए कुछ भी नहीं है तो इसे छोड़ दिया जाएगा।

हमें निम्नलिखित डेटा जाँचों को अद्यतन करने की आवश्यकता है ताकि उन स्तंभों को शामिल किया जा सके जो जाँच में विफल रहे: अत्यधिक अशक्त, आईडी और लक्ष्य रिसाव। बोनस अगर हम अन्य डेटा चेक भी अपडेट करते हैं :)

यह मूल रूप से @BoopBoopBeepBoop ने प्रस्तावित किया है! ✨ @Cmancuso FYI करें