متابعة هذا الأمر في الوقت الحالي ، نظرًا لأن Woodwork تقوم بوضع اللمسات الأخيرة على خطط التحديثات الكبيرة. إذا أصبحت Woodwork امتدادًا للباندا ، فقد لا نرغب في القيام بذلك أو نحتاج إليه.

سجلت الوصول أنا و angela97lin @ وناقشنا بعض خيارات التنفيذ:

1. اجعل تقييم الرسم البياني للمكون يمرر الباندا إلى كل مكون. للإشارة إلى أنواع ww للمكونات ، قم إما بإضافة حقول جديدة إلى fit وما إلى ذلك ، أو التزم بنمط ميزة النص باستخدام معلمات init للإشارة إلى الأعمدة ذات الصلة. العيب: قبيح من منظور API ، وهذا هو سبب إنشاء الأعمال الخشبية في المقام الأول.
2. أثناء تقييم الرسم البياني للمكون ، قم بتمرير الأعمال الخشبية إلى كل مكون. اطلب من كل مكون إرجاع الباندا. العيب: يتمثل أحد القيود المحتملة في أن المكونات لا يمكنها تغيير نوع الأعمال الخشبية لميزات الإدخال أو الميزات التي تم إنشاؤها حديثًا ، إلا من خلال تغيير نوع pandas dtype. ومع ذلك ، ليس لدينا أي مكونات تعتمد على هذا.
3. أثناء تقييم الرسم البياني للمكون ، قم بتمرير الأعمال الخشبية إلى كل مكون. اطلب من كل مكون إعادة الأعمال الخشبية. التحدي: يجب أن تتحول معظم المكونات إلى حيوانات الباندا داخليًا لإجراء تحويلات مثل إضافة ميزات أو حذف الميزات أو تعديل الميزات. بعد هذه التحولات ، يتعين علينا التأكد من أن أنواع الأعمال الخشبية الأصلية تدخل في جدول بيانات الأعمال الخشبية الجديدة المرتجعة ، وإلا ستضيع الإعدادات التي تجاوزها المستخدم ، كما هي اليوم.

الحالة: @ angela97lin يتابع حاليًا الخيار 3 في # 1668

الخطة: سنستمر في هذه الإستراتيجية ، مع الحرص على تقليل وقت التشغيل بسبب العديد من عمليات إنشاء بيانات ww القابلة للتسجيل. وسننظر في ما إذا كانت هناك أي طلبات ميزات يجب أن نجعلها للأعمال الخشبية لتسهيل ذلك. سنراقب أيضًا أي خيارات مقنعة ربما فاتناها حتى الآن.

تضمين التغريدة

يبدو أن الخيار الثالث هو الخيار الأفضل والأنظف. نأمل ألا يتأثر الأداء ، ولكن يبدو من الناحية المفاهيمية سليمًا. شكرا لجذب انتباهي ... محاولة لف رأسي حول كل الأشياء.

القرصنة على هذا والتفكير أكثر:

الهدف النهائي هو أننا بحاجة إلى طريقة ما لتتبع الأنواع المنطقية الأصلية التي يريدها المستخدم. قد تكون هذه المعلومات التي يحتفظ بها الرسم البياني للمكون ، أو يتم تمريرها إلى كل مكون مسؤول عن إعادة هذه الأنواع مرة أخرى بعد تحويل بعض البيانات. تتبع حاليًا 3 ، وإضافة المعلومات إلى الرسم البياني للمكون نظرًا لأن هذا أسهل للاختبار (بدلاً من تحديث كل مكون) ... ولكن على مستوى المكون ، لن يكون ذلك منطقيًا.

لنفترض أن المستخدم يحدد Woodwork DataTable ويحول صراحةً عمودًا فئويًا إلى لغة طبيعية. يقوم المستخدم بتمرير ذلك إلى أحد المكونات. نحتاج إلى التحويل إلى الباندا لتمريرها إلى المكتبات الخارجية ، ونرغب في إرجاع كائن Woodwork. إذا استدعينا ببساطة مُنشئ Woodwork ، فسيأخذ فقط النوع المستنتج (قاطع) ، أيهما غريب؟ لذلك يجب علينا تتبع نوع اللغة الطبيعية المحدد الأصلي والتحويل قبل إعادته إلى المستخدم.

من المثير للاهتمام ملاحظة أداة القياس القياسية: يمكن أن تأخذ أعمدة Int وتحويلها إلى عوامات. إذا حاولنا بعد ذلك إعادة col إلى النوع الأصلي (int) ، فسنصرخ لمحاولة تحويل العوامات إلى int عندما لا يكون ذلك آمنًا. 😬

تحديث: أجريت مناقشة سريعة مع dsherry وchukarsten. أقوم حاليًا بتنفيذ # 3 ، ولكن لديّ مقبض الرسم البياني للمكون لتتبع أنواع المستخدمين الأصلية وتحديث تلك المعلومات عند تمريرها من مكون إلى آخر. يعمل هذا بشكل جيد ويوصلنا إلى مكان يعمل فيه AutoML / pipelines ، ولكن بعد دمج # 1668 ، يجب علينا معالجة هذا الأمر على مستوى المكون وإزالة هذا الرمز من الرسم البياني للمكون.

واجباتي التالية: إصلاح اختبارات الفهرس من تحديث الفرع من التعليقات الرئيسية والتنقية ومشكلات الملفات التي يمكن معالجتها غير المرتبطة بهذا العلاقات العامة (فقط رمز التنظيف العام). بمجرد أن تصبح الشفرة أكثر نظافة ، ابحث عن التكرار والملف الشخصي لمعرفة مصدر هذا الفارق الزمني الضخم / ما يمكننا فعله حيال ذلك.