المعالجة المسبقة للبيانات لتعلم الآلة: الخيارات والتوصيات

هذه الوثيقة هي الأولى في سلسلة مكونة من جزأين تستكشف موضوع هندسة البيانات وهندسة الميزات للتعلم الآلي (ML)، مع التركيز على مهام التعلم الخاضعة للإشراف. يناقش هذا الجزء الأول أفضل الممارسات لمعالجة البيانات مسبقًا في مسار تعلم الآلة على Google Cloud. تركز الوثيقة على استخدام TensorFlow ومكتبة TensorFlow Transform ( tf.Transform ) مفتوحة المصدر لإعداد البيانات وتدريب النموذج وخدمة النموذج للتنبؤ. يسلط هذا المستند الضوء على تحديات المعالجة المسبقة للبيانات لتعلم الآلة، ويصف الخيارات والسيناريوهات اللازمة لإجراء تحويل البيانات على Google Cloud بشكل فعال.

يفترض هذا المستند أنك على دراية بـ BigQuery و Dataflow و Vertex AI و TensorFlow Keras API.

يقدم المستند الثاني، المعالجة المسبقة للبيانات لتعلم الآلة باستخدام Google Cloud ، برنامجًا تعليميًا خطوة بخطوة حول كيفية تنفيذ مسار tf.Transform .

مقدمة

يساعدك ML في العثور تلقائيًا على الأنماط المعقدة والمفيدة في البيانات. يتم تكثيف هذه الأنماط في نموذج تعلم الآلة الذي يمكن استخدامه بعد ذلك في نقاط بيانات جديدة - وهي عملية تسمى عمل التنبؤات أو إجراء الاستدلال .

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

يمكن أن يكون حجم مجموعات البيانات التدريبية لنماذج تعلم الآلة في العالم الحقيقي مساويًا أو أكبر من تيرابايت واحد (TB) بسهولة. لذلك، تحتاج إلى أطر معالجة بيانات واسعة النطاق من أجل معالجة مجموعات البيانات هذه بكفاءة وتوزيعها. عند استخدام نموذج تعلم الآلة لعمل تنبؤات، يتعين عليك تطبيق نفس التحويلات التي استخدمتها لبيانات التدريب على نقاط البيانات الجديدة. من خلال تطبيق نفس التحويلات، فإنك تقدم مجموعة البيانات المباشرة إلى نموذج تعلم الآلة بالطريقة التي يتوقعها النموذج.

يناقش هذا المستند هذه التحديات لمستويات مختلفة من التفاصيل للعمليات الهندسية للميزات: مستوى المثيل، والتمرير الكامل، وتجميعات النافذة الزمنية. يصف هذا المستند أيضًا الخيارات والسيناريوهات اللازمة لتنفيذ تحويل البيانات لتعلم الآلة على Google Cloud.

يوفر هذا المستند أيضًا نظرة عامة على TensorFlow Transform ( tf.Transform )، وهي مكتبة لـ TensorFlow تتيح لك تحديد تحويل البيانات على مستوى المثيل والتمرير الكامل من خلال خطوط أنابيب المعالجة المسبقة للبيانات. يتم تنفيذ خطوط الأنابيب هذه باستخدام Apache Beam ، وتقوم بإنشاء عناصر تتيح لك تطبيق نفس التحويلات أثناء التنبؤ كما هو الحال عند تقديم النموذج.

المعالجة المسبقة للبيانات لـ ML

يقدم هذا القسم عمليات المعالجة المسبقة للبيانات ومراحل جاهزية البيانات. ويناقش أيضًا أنواع عمليات المعالجة المسبقة وتفاصيلها.

هندسة البيانات مقارنة بهندسة الميزات

تتضمن المعالجة المسبقة للبيانات لتعلم الآلة كلاً من هندسة البيانات وهندسة الميزات. هندسة البيانات هي عملية تحويل البيانات الأولية إلى بيانات معدة . تقوم هندسة الميزات بعد ذلك بضبط البيانات المعدة لإنشاء الميزات التي يتوقعها نموذج ML. هذه المصطلحات لها المعاني التالية:

البيانات الأولية (أو البيانات فقط)

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

البيانات المعدة

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

الميزات الهندسية

مجموعة البيانات مع الميزات المضبوطة التي يتوقعها النموذج - أي الميزات التي يتم إنشاؤها عن طريق تنفيذ عمليات معينة خاصة بتعلم الآلة على الأعمدة في مجموعة البيانات المعدة، وإنشاء ميزات جديدة لنموذجك أثناء التدريب والتنبؤ، كما هو موضح لاحقًا في عمليات المعالجة المسبقة . تتضمن أمثلة هذه العمليات تغيير حجم الأعمدة الرقمية إلى قيمة تتراوح بين 0 و1، وقيم القطع، والميزات الفئوية ذات الترميز السريع .

ويوضح الرسم البياني التالي، الشكل 1، الخطوات المتضمنة في إعداد البيانات المعالجة مسبقًا:

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

عمليات المعالجة المسبقة

تتضمن المعالجة المسبقة للبيانات عدة عمليات. تم تصميم كل عملية لمساعدة ML في بناء نماذج تنبؤية أفضل. تفاصيل عمليات المعالجة المسبقة هذه تقع خارج نطاق هذا المستند، ولكن بعض العمليات موضحة بإيجاز في هذا القسم.

بالنسبة للبيانات المنظمة، تتضمن عمليات المعالجة المسبقة للبيانات ما يلي:

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

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

• بالنسبة للمستندات النصية: الاشتقاق والتجسيد ، وحساب TF-IDF ، واستخراج n-gram ، وتضمين البحث.
• بالنسبة للصور: القطع، وتغيير الحجم، والاقتصاص، والتمويه الضبابي، والمرشحات الكناري.
• بالنسبة لجميع أنواع البيانات (بما في ذلك النصوص والصور): نقل التعلم ، الذي يتعامل مع جميع الطبقات باستثناء الأخيرة من النموذج المدرب بالكامل كخطوة هندسية مميزة.

دقة المعالجة المسبقة

يناقش هذا القسم دقة أنواع تحويلات البيانات. ويوضح سبب أهمية هذا المنظور عند إعداد نقاط بيانات جديدة للتنبؤات باستخدام التحويلات التي يتم تطبيقها على بيانات التدريب.

يمكن تصنيف عمليات المعالجة المسبقة والتحويل على النحو التالي، بناءً على تفاصيل العملية:

• التحولات على مستوى المثيل أثناء التدريب والتنبؤ . هذه تحويلات مباشرة، حيث تكون هناك حاجة إلى قيم من نفس المثيل فقط لإجراء التحويل. على سبيل المثال، قد تتضمن التحويلات على مستوى المثيل قص قيمة ميزة ما إلى حد ما، أو توسيع ميزة أخرى متعدد الحدود، أو ضرب ميزتين، أو مقارنة ميزتين لإنشاء علامة منطقية.

  يجب تطبيق هذه التحويلات بشكل مماثل أثناء التدريب والتنبؤ، لأنه سيتم تدريب النموذج على الميزات المحولة، وليس على قيم المدخلات الأولية. إذا لم يتم تحويل البيانات بشكل مماثل، فإن النموذج يتصرف بشكل سيئ لأنه يتم تقديمه ببيانات ذات توزيع للقيم التي لم يتم تدريبه عليها. لمزيد من المعلومات، راجع مناقشة انحراف تقديم التدريب في قسم تحديات المعالجة المسبقة .

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

  على سبيل المثال، لتطبيع ميزة رقمية للتدريب، يمكنك حساب متوسطها (μ) وانحرافها المعياري (σ) عبر بيانات التدريب بأكملها. يُطلق على هذا الحساب اسم عملية التمرير الكامل (أو التحليل ). عند تقديم نموذج للتنبؤ، تتم تسوية قيمة نقطة البيانات الجديدة لتجنب انحراف خدمة التدريب. لذلك، يتم استخدام القيم μ وσ التي يتم حسابها أثناء التدريب لضبط قيمة الميزة، وهي العملية البسيطة التالية على مستوى المثيل :

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  تتضمن تحويلات التمرير الكامل ما يلي:

  • يقوم MinMax بتحجيم الميزات الرقمية باستخدام الحد الأدنى والحد الأقصى المحسوب من مجموعة بيانات التدريب.
  • الميزات الرقمية للتحجيم القياسي (تطبيع z-score) باستخدام μ وσ المحسوبة على مجموعة بيانات التدريب.
  • دلو الميزات العددية باستخدام الكميات.
  • احتساب القيم المفقودة باستخدام الوسيط (الميزات العددية) أو الوضع (الميزات الفئوية).
  • تحويل السلاسل (القيم الاسمية) إلى أعداد صحيحة (الفهارس) عن طريق استخراج جميع القيم المميزة (المفردات) لميزة فئوية الإدخال.
  • حساب حدوث مصطلح (قيمة الميزة) في جميع المستندات (المثيلات) لحساب TF-IDF.
  • حساب PCA لميزات الإدخال لعرض البيانات في مساحة ذات أبعاد أقل (مع ميزات تعتمد خطيًا).

  يجب عليك استخدام بيانات التدريب فقط لحساب الإحصائيات مثل μ و σ و min و max . إذا قمت بإضافة بيانات الاختبار والتقييم لهذه العمليات، فإنك تقوم بتسريب المعلومات من بيانات التقييم والاختبار لتدريب النموذج. ويؤثر القيام بذلك على موثوقية نتائج الاختبار والتقييم. للتأكد من تطبيق تحويل متسق على جميع مجموعات البيانات، يمكنك استخدام نفس الإحصائيات المحسوبة من بيانات التدريب لتحويل بيانات الاختبار والتقييم.

• التجمعات التاريخية أثناء التدريب والتنبؤ . يتضمن ذلك إنشاء مجموعات أعمال ومشتقات وعلامات كإشارات إدخال لمهمة التنبؤ - على سبيل المثال، إنشاء مقاييس الحداثة والتكرار والنقد (RFM) للعملاء لبناء نماذج الميل. يمكن حساب هذه الأنواع من الميزات مسبقًا وتخزينها في متجر الميزات لاستخدامها أثناء تدريب النموذج وتسجيل الدُفعات وخدمة التنبؤ عبر الإنترنت. يمكنك أيضًا إجراء هندسة ميزات إضافية (على سبيل المثال، التحويل والضبط) لهذه التجميعات قبل التدريب والتنبؤ.

• التجميعات التاريخية أثناء التدريب، ولكن التجميعات في الوقت الحقيقي أثناء التنبؤ . يتضمن هذا الأسلوب إنشاء ميزة من خلال تلخيص قيم الوقت الفعلي بمرور الوقت. في هذا النهج، يتم تحديد المثيلات التي سيتم تجميعها من خلال بنود النافذة الزمنية. على سبيل المثال، يمكنك استخدام هذا الأسلوب إذا كنت تريد تدريب نموذج يقدر وقت رحلة سيارة الأجرة استنادًا إلى مقاييس حركة المرور للمسار في آخر 5 دقائق، وفي آخر 10 دقائق، وفي آخر 30 دقيقة، وفي أوقات أخرى فترات. يمكنك أيضًا استخدام هذا الأسلوب للتنبؤ بفشل جزء من المحرك بناءً على المتوسط ​​المتحرك لدرجة الحرارة وقيم الاهتزاز المحسوبة خلال آخر 3 دقائق. على الرغم من أنه يمكن إعداد هذه التجميعات دون الاتصال بالإنترنت للتدريب، إلا أنه يتم حسابها في الوقت الفعلي من دفق البيانات أثناء التقديم.

  وبشكل أكثر دقة، عند إعداد بيانات التدريب، إذا لم تكن القيمة المجمعة موجودة في البيانات الأولية، فسيتم إنشاء القيمة أثناء مرحلة هندسة البيانات. عادةً ما يتم تخزين البيانات الأولية في قاعدة بيانات بتنسيق (entity, timestamp, value) . في الأمثلة السابقة، entity هو معرف مقطع المسار لمسارات سيارات الأجرة ومعرف جزء المحرك لعطل المحرك. يمكنك استخدام عمليات النوافذ لحساب (entity, time_index, aggregated_value_over_time_window) واستخدام ميزات التجميع كمدخل للتدريب على النموذج الخاص بك.

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

خط أنابيب ML على Google Cloud

يناقش هذا القسم المكونات الأساسية لخط أنابيب نموذجي شامل لتدريب وخدمة نماذج TensorFlow ML على Google Cloud باستخدام الخدمات المُدارة. ويناقش أيضًا أين يمكنك تنفيذ فئات مختلفة من عمليات المعالجة المسبقة للبيانات، والتحديات الشائعة التي قد تواجهها عند تنفيذ مثل هذه التحويلات. يوضح قسم كيفية عمل tf.Transform كيف تساعد مكتبة TensorFlow Transform في مواجهة هذه التحديات.

هندسة معمارية رفيعة المستوى

يوضح الرسم البياني التالي، الشكل 2، بنية عالية المستوى لخط أنابيب ML نموذجي للتدريب وخدمة نماذج TensorFlow. تشير التسميات A وB وC في الرسم التخطيطي إلى أماكن مختلفة في المسار حيث يمكن إجراء المعالجة المسبقة للبيانات. يتم توفير تفاصيل حول هذه الخطوات في القسم التالي.

يتكون خط الأنابيب من الخطوات التالية:

1. بعد استيراد البيانات الأولية، يتم تخزين البيانات الجدولية في BigQuery، ويتم تخزين البيانات الأخرى مثل الصور والصوت والفيديو في Cloud Storage. يستخدم الجزء الثاني من هذه السلسلة البيانات الجدولية المخزنة في BigQuery كمثال.
2. يتم تنفيذ هندسة البيانات (الإعداد) وهندسة الميزات على نطاق واسع باستخدام Dataflow. ينتج عن هذا التنفيذ مجموعات تدريب وتقييم واختبار جاهزة للتعلم الآلي يتم تخزينها في Cloud Storage. من الناحية المثالية، يتم تخزين مجموعات البيانات هذه كملفات TFRecord ، وهو التنسيق الأمثل لحسابات TensorFlow.
3. يتم إرسال حزمة تدريب نموذج TensorFlow إلى Vertex AI Training، الذي يستخدم البيانات المعالجة مسبقًا من الخطوات السابقة لتدريب النموذج. ناتج هذه الخطوة هو نموذج TensorFlow SavedModel المُدرب الذي يتم تصديره إلى Cloud Storage.
4. يتم نشر نموذج TensorFlow المدرب في Vertex AI Prediction كخدمة تحتوي على REST API بحيث يمكن استخدامه للتنبؤات عبر الإنترنت. يمكن أيضًا استخدام نفس النموذج لوظائف التنبؤ الدفعي.
5. بعد نشر النموذج كواجهة برمجة تطبيقات REST، يمكن لتطبيقات العميل والأنظمة الداخلية استدعاء واجهة برمجة التطبيقات عن طريق إرسال الطلبات مع بعض نقاط البيانات، وتلقي الاستجابات من النموذج مع التنبؤات.
6. لتنسيق مسار التدفق هذا وأتمتته، يمكنك استخدام Vertex AI Pipelines كمجدول لاستدعاء خطوات إعداد البيانات والتدريب النموذجي ونشر النموذج.

يمكنك أيضًا استخدام Vertex AI Features Store لتخزين ميزات الإدخال لإجراء التنبؤات. على سبيل المثال، يمكنك إنشاء ميزات هندسية بشكل دوري من أحدث البيانات الأولية وتخزينها في Vertex AI Features Store. تقوم تطبيقات العميل بجلب ميزات الإدخال المطلوبة من Vertex AI Features Store وإرسالها إلى النموذج لتلقي التنبؤات.

أين تتم المعالجة المسبقة

في الشكل 2، توضح التسميات A وB وC أن عمليات المعالجة المسبقة للبيانات يمكن أن تتم في BigQuery أو Dataflow أو TensorFlow. تصف الأقسام التالية كيفية عمل كل خيار من هذه الخيارات.

الخيار أ: BigQuery

عادةً، يتم تنفيذ المنطق في BigQuery للعمليات التالية:

• أخذ العينات: اختيار مجموعة فرعية من البيانات بشكل عشوائي.
• التصفية: إزالة الحالات غير ذات الصلة أو غير الصالحة.
• التقسيم: تقسيم البيانات لإنتاج مجموعات التدريب والتقييم والاختبار.

يمكن استخدام البرامج النصية لـ BigQuery SQL كاستعلام مصدر لمسار المعالجة المسبقة لـ Dataflow، وهي خطوة معالجة البيانات في الشكل 2. على سبيل المثال، إذا تم استخدام نظام في كندا، وكان مستودع البيانات يحتوي على معاملات من جميع أنحاء العالم، فستتم التصفية إلى من الأفضل الحصول على بيانات التدريب في كندا فقط من خلال BigQuery. تعتبر هندسة الميزات في BigQuery بسيطة وقابلة للتطوير، وتدعم تنفيذ تحويلات ميزات التجميعات التاريخية على مستوى المثيل.

ومع ذلك، نوصي باستخدام BigQuery لهندسة الميزات فقط إذا كنت تستخدم النموذج الخاص بك للتنبؤ الدفعي (تسجيل النقاط)، أو إذا كانت الميزات محسوبة مسبقًا في BigQuery، ولكنها مخزنة في Vertex AI Features Store لاستخدامها أثناء التنبؤ عبر الإنترنت. إذا كنت تخطط لنشر النموذج للتنبؤات عبر الإنترنت، وإذا لم تكن لديك الميزة الهندسية في مخزن الميزات عبر الإنترنت، فيجب عليك نسخ عمليات المعالجة المسبقة لـ SQL لتحويل نقاط البيانات الأولية التي تنشئها الأنظمة الأخرى. بمعنى آخر، تحتاج إلى تنفيذ المنطق مرتين: مرة واحدة في SQL لمعالجة بيانات التدريب مسبقًا في BigQuery، ومرة ​​ثانية في منطق التطبيق الذي يستهلك النموذج لمعالجة نقاط البيانات عبر الإنترنت مسبقًا للتنبؤ.

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

إذا كنت تستخدم النموذج الخاص بك فقط للتنبؤ بالدُفعات (على سبيل المثال، استخدام Vertex AI للتنبؤ بالدُفعات )، وإذا تم الحصول على بيانات تسجيل النقاط الخاصة بك من BigQuery، فيمكنك تنفيذ عمليات المعالجة المسبقة هذه كجزء من البرنامج النصي BigQuery SQL. في هذه الحالة، يمكنك استخدام نفس البرنامج النصي SQL للمعالجة المسبقة لإعداد بيانات التدريب والتسجيل.

التحويلات ذات الحالة ذات التمرير الكامل ليست مناسبة للتنفيذ في BigQuery. إذا كنت تستخدم BigQuery لتحويلات التمرير الكامل، فستحتاج إلى جداول مساعدة لتخزين الكميات التي تحتاجها التحويلات ذات الحالة، مثل الوسائل والتباينات لقياس الميزات الرقمية. علاوة على ذلك، يؤدي تنفيذ تحويلات التمرير الكامل باستخدام SQL على BigQuery إلى زيادة التعقيد في نصوص SQL النصية، ويخلق تبعية معقدة بين التدريب ونصوص SQL النصية للتسجيل.

الخيار ب: تدفق البيانات

كما هو موضح في الشكل 2، يمكنك تنفيذ عمليات المعالجة المسبقة المكلفة حسابيًا في Apache Beam، وتشغيلها على نطاق واسع باستخدام Dataflow. Dataflow عبارة عن خدمة ضبط تلقائي مُدارة بالكامل لمعالجة البيانات المجمعة والدفقية. عند استخدام Dataflow، يمكنك أيضًا استخدام مكتبات خارجية متخصصة لمعالجة البيانات، على عكس BigQuery.

يمكن لتدفق البيانات إجراء تحويلات على مستوى المثيل، وتحويلات ميزات التجميع التاريخية وفي الوقت الفعلي. على وجه الخصوص، إذا كانت نماذج ML الخاصة بك تتوقع ميزة إدخال مثل total_number_of_clicks_last_90sec ، فيمكن لوظائف نافذة Apache Beam حساب هذه الميزات بناءً على تجميع قيم النوافذ الزمنية لبيانات الأحداث (الدفق) في الوقت الفعلي (على سبيل المثال، أحداث النقر). في المناقشة السابقة حول تفاصيل التحولات ، تمت الإشارة إلى ذلك باسم "التجميعات التاريخية أثناء التدريب، ولكن التجميعات في الوقت الفعلي أثناء التنبؤ".

يوضح الرسم البياني التالي، الشكل 3، دور Dataflow في معالجة بيانات الدفق للتنبؤات في الوقت الفعلي تقريبًا.

كما هو موضح في الشكل 3، أثناء المعالجة، يتم استيعاب الأحداث التي تسمى نقاط البيانات في Pub/Sub . يستهلك Dataflow نقاط البيانات هذه، ويحسب الميزات بناءً على التجميعات بمرور الوقت، ثم يستدعي واجهة برمجة تطبيقات نموذج ML المنشورة للتنبؤات. يتم بعد ذلك إرسال التنبؤات إلى قائمة انتظار Pub/Sub الصادرة. من Pub/Sub، يمكن استهلاك التنبؤات بواسطة الأنظمة النهائية مثل المراقبة أو التحكم، أو يمكن إعادتها مرة أخرى (على سبيل المثال، كإشعارات) إلى العميل الطالب الأصلي. يمكن أيضًا تخزين التنبؤات في مخزن بيانات منخفض زمن الوصول مثل Cloud Bigtable للجلب في الوقت الفعلي. يمكن أيضًا استخدام Cloud Bigtable لتجميع هذه التجمعات في الوقت الفعلي وتخزينها حتى يمكن البحث عنها عند الحاجة للتنبؤ.

يمكن استخدام نفس تطبيق Apache Beam لمعالجة بيانات التدريب المجمعة التي تأتي من مخزن بيانات غير متصل بالإنترنت مثل BigQuery ومعالجة البيانات في الوقت الفعلي لخدمة التنبؤات عبر الإنترنت.

في البنيات النموذجية الأخرى، مثل البنية الموضحة في الشكل 2، يستدعي تطبيق العميل مباشرة واجهة برمجة التطبيقات النموذجية المنشورة للتنبؤات عبر الإنترنت. في هذه الحالة، إذا تم تنفيذ عمليات المعالجة المسبقة في Dataflow لإعداد بيانات التدريب، فلن يتم تطبيق العمليات على بيانات التنبؤ التي تنتقل مباشرة إلى النموذج. لذلك، يجب دمج مثل هذه التحويلات في النموذج أثناء تقديم التنبؤات عبر الإنترنت.

يمكن استخدام تدفق البيانات لإجراء تحويل كامل، عن طريق حساب الإحصائيات المطلوبة على نطاق واسع. ومع ذلك، يجب تخزين هذه الإحصائيات في مكان ما لاستخدامها أثناء التنبؤ لتحويل نقاط بيانات التنبؤ. باستخدام مكتبة TensorFlow Transform ( tf.Transform )، يمكنك تضمين هذه الإحصائيات مباشرة في النموذج بدلاً من تخزينها في مكان آخر. سيتم شرح هذا الأسلوب لاحقًا في كيفية عمل tf.Transform .

الخيار ج: TensorFlow

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

• تنفيذ كل منطق التحويل على مستوى المثيل في وظيفة input_fn وفي وظيفة serving_fn . تقوم الدالة input_fn بإعداد مجموعة بيانات باستخدام tf.data.Dataset API لتدريب النموذج. تقوم وظيفة serving_fn باستقبال البيانات وإعدادها للتنبؤات.
• وضع كود التحويل مباشرة في نموذج TensorFlow الخاص بك باستخدام طبقات المعالجة المسبقة لـ Keras أو إنشاء طبقات مخصصة .

يحدد رمز منطق التحويل في وظيفة serving_fn واجهة العرض الخاصة بـ SavedModel الخاص بك للتنبؤ عبر الإنترنت. إذا قمت بتنفيذ نفس التحويلات التي تم استخدامها لإعداد بيانات التدريب في كود منطق التحويل الخاص بوظيفة serving_fn ، فهذا يضمن تطبيق نفس التحويلات على نقاط بيانات التنبؤ الجديدة عند تقديمها.

ومع ذلك، نظرًا لأن نموذج TensorFlow يعالج كل نقطة بيانات بشكل مستقل أو في دفعة صغيرة، فلا يمكنك حساب التجميعات من جميع نقاط البيانات. ونتيجة لذلك، لا يمكن تنفيذ تحويلات التمرير الكامل في نموذج TensorFlow الخاص بك.

تحديات المعالجة المسبقة

فيما يلي التحديات الأساسية لتنفيذ المعالجة المسبقة للبيانات:

• انحراف خدمة التدريب . يشير انحراف خدمة التدريب إلى الفرق بين الفعالية (الأداء التنبؤي) أثناء التدريب وأثناء الخدمة. يمكن أن يحدث هذا الانحراف بسبب التناقض بين كيفية التعامل مع البيانات في التدريب ومسارات الخدمة. على سبيل المثال، إذا تم تدريب النموذج الخاص بك على ميزة تم تحويلها لوغاريتميًا، ولكن تم تقديمه مع الميزة الأولية أثناء العرض، فقد لا يكون مخرجات التنبؤ دقيقة.

  إذا أصبحت التحويلات جزءًا من النموذج نفسه، فقد يكون من السهل التعامل مع التحويلات على مستوى المثيل، كما هو موضح سابقًا في الخيار C: TensorFlow . في هذه الحالة، تتوقع واجهة تقديم النموذج (الدالة serving_fn ) بيانات أولية، بينما يقوم النموذج بتحويل هذه البيانات داخليًا قبل حساب المخرجات. التحويلات هي نفس تلك التي تم تطبيقها على نقاط بيانات التدريب والتنبؤ الأولية.

• تحويلات التمرير الكامل . لا يمكنك تنفيذ تحويلات كاملة التمرير مثل تحويلات القياس والتطبيع في نموذج TensorFlow الخاص بك. في تحويلات التمرير الكامل، يجب حساب بعض الإحصائيات (على سبيل المثال، القيم max min لقياس الميزات الرقمية) على بيانات التدريب مسبقًا، كما هو موضح في الخيار ب: تدفق البيانات . يجب بعد ذلك تخزين القيم في مكان ما لاستخدامها أثناء تقديم النموذج للتنبؤ لتحويل نقاط البيانات الأولية الجديدة كتحويلات على مستوى المثيل، مما يتجنب انحراف خدمة التدريب. يمكنك استخدام مكتبة TensorFlow Transform ( tf.Transform ) لتضمين الإحصائيات مباشرة في نموذج TensorFlow الخاص بك. سيتم شرح هذا الأسلوب لاحقًا في كيفية عمل tf.Transform .

• إعداد البيانات مقدمًا لتحسين كفاءة التدريب . قد يؤدي تنفيذ التحولات على مستوى المثيل كجزء من النموذج إلى تقليل كفاءة عملية التدريب. يحدث هذا التدهور بسبب تطبيق نفس التحويلات بشكل متكرر على نفس بيانات التدريب في كل فترة. تخيل أن لديك بيانات تدريب أولية تحتوي على 1000 ميزة، وأنك تطبق مزيجًا من التحويلات على مستوى المثيل لإنشاء 10000 ميزة. إذا قمت بتنفيذ هذه التحويلات كجزء من النموذج الخاص بك، وإذا قمت بعد ذلك بتغذية النموذج ببيانات التدريب الأولية، فسيتم تطبيق هذه العمليات الـ 10000 N مرات على كل مثيل، حيث N هو عدد العصور. بالإضافة إلى ذلك، إذا كنت تستخدم المسرعات (وحدات معالجة الرسومات أو وحدات TPU)، فإنها تظل في وضع الخمول بينما تقوم وحدة المعالجة المركزية بإجراء تلك التحويلات، وهو ما لا يعد استخدامًا فعالاً للمسرعات المكلفة.

  من الناحية المثالية، يتم تحويل بيانات التدريب قبل التدريب، باستخدام التقنية الموضحة ضمن الخيار ب: تدفق البيانات ، حيث يتم تطبيق عمليات التحويل البالغ عددها 10000 مرة واحدة فقط في كل مثيل تدريب. ثم يتم تقديم بيانات التدريب المحولة إلى النموذج. لم يتم تطبيق أي تحويلات أخرى، والمسرعات مشغولة طوال الوقت. بالإضافة إلى ذلك، يساعدك استخدام Dataflow على المعالجة المسبقة لكميات كبيرة من البيانات على نطاق واسع، باستخدام خدمة مُدارة بالكامل.

  يمكن أن يؤدي إعداد بيانات التدريب مقدمًا إلى تحسين كفاءة التدريب. ومع ذلك، فإن تنفيذ منطق التحويل خارج النموذج (الطرق الموضحة في الخيار أ: BigQuery أو الخيار ب: تدفق البيانات ) لا يحل مشكلة انحراف تقديم التدريب. ما لم تقم بتخزين الميزة الهندسية في مخزن الميزات لاستخدامها في كل من التدريب والتنبؤ، يجب تنفيذ منطق التحويل في مكان ما ليتم تطبيقه على نقاط البيانات الجديدة القادمة للتنبؤ، لأن واجهة النموذج تتوقع البيانات المحولة. يمكن أن تساعدك مكتبة TensorFlow Transform ( tf.Transform ) في معالجة هذه المشكلة، كما هو موضح في القسم التالي.

كيف يعمل tf.Transform

تعد مكتبة tf.Transform مفيدة للتحويلات التي تتطلب تمريرًا كاملاً. يتم تصدير مخرجات مكتبة tf.Transform كرسم بياني TensorFlow الذي يمثل منطق التحويل على مستوى المثيل والإحصائيات المحسوبة من تحويلات التمرير الكامل، لاستخدامها في التدريب والخدمة. إن استخدام نفس الرسم البياني لكل من التدريب والإرسال يمكن أن يمنع الانحراف، لأنه يتم تطبيق نفس التحولات في كلتا المرحلتين. بالإضافة إلى ذلك، يمكن تشغيل مكتبة tf.Transform على نطاق واسع في مسار معالجة الدفعات على Dataflow لإعداد بيانات التدريب مقدمًا وتحسين كفاءة التدريب.

يوضح الرسم البياني التالي، الشكل 4، كيف تقوم مكتبة tf.Transform بالمعالجة المسبقة وتحويل البيانات للتدريب والتنبؤ. يتم وصف العملية في الأقسام التالية.

تحويل بيانات التدريب والتقييم

يمكنك معالجة بيانات التدريب الأولية مسبقًا باستخدام التحويل المطبق في tf.Transform Apache Beam APIs، وتشغيلها على نطاق واسع على Dataflow. تتم المعالجة المسبقة في المراحل التالية:

• مرحلة التحليل: أثناء مرحلة التحليل، يتم حساب الإحصائيات المطلوبة (مثل الوسائل والتباينات والكميات) للتحويلات ذات الحالة على بيانات التدريب باستخدام عمليات التمرير الكامل. تنتج هذه المرحلة مجموعة من عناصر التحويل، بما في ذلك الرسم البياني transform_fn . الرسم البياني transform_fn هو رسم بياني TensorFlow يحتوي على منطق التحويل كعمليات على مستوى المثيل. ويتضمن الإحصائيات المحسوبة في مرحلة التحليل كثوابت.
• مرحلة التحويل: أثناء مرحلة التحويل، يتم تطبيق الرسم البياني transform_fn على بيانات التدريب الأولية، حيث يتم استخدام الإحصائيات المحسوبة لمعالجة سجلات البيانات (على سبيل المثال، لقياس الأعمدة الرقمية) بطريقة على مستوى المثيل.

يعالج نهج من مرحلتين مثل هذا تحدي المعالجة المسبقة المتمثل في إجراء تحويلات كاملة التمرير.

عندما تتم معالجة بيانات التقييم مسبقًا، يتم تطبيق العمليات على مستوى المثيل فقط، باستخدام المنطق الموجود في الرسم البياني transform_fn والإحصائيات المحسوبة من مرحلة التحليل في بيانات التدريب. بمعنى آخر، لا يمكنك تحليل بيانات التقييم بطريقة شاملة لحساب الإحصائيات الجديدة، مثل μ وσ، لتطبيع الميزات الرقمية في بيانات التقييم. بدلاً من ذلك، يمكنك استخدام الإحصائيات المحسوبة من بيانات التدريب لتحويل بيانات التقييم بطريقة على مستوى المثيل.

يتم إعداد بيانات التدريب والتقييم المحولة على نطاق واسع باستخدام Dataflow، قبل استخدامها لتدريب النموذج. تعالج عملية تقديم البيانات الدُفعات هذه التحدي المسبق للمعالجة المتمثلة في إعداد البيانات مقدما لتحسين كفاءة التدريب. كما هو مبين في الشكل 4 ، تتوقع الواجهة الداخلية النموذجية الميزات المحولة.

إرفاق التحولات بالنموذج المصدر

كما هو مذكور ، يتم تخزين الرسم البياني transform_fn الذي ينتجه خط أنابيب tf.Transform كرسوم بيانية مصدرة لـ TensorFlow. يتكون الرسم البياني المصدر من منطق التحول كعمليات على مستوى المثيل ، وجميع الإحصائيات المحسوبة في التحولات الكاملة تمريرات كثوابت الرسم البياني. عندما يتم تصدير النموذج المدرب للخدمة ، يتم إرفاق الرسم البياني transform_fn بـ sadeDModel كجزء من وظيفة serving_fn الخاصة به.

على الرغم من أنها تخدم النموذج للتنبؤ ، فإن واجهة خدمة النموذج تتوقع نقاط بيانات في التنسيق الخام (أي قبل أي تحولات). ومع ذلك ، تتوقع الواجهة الداخلية النموذجية البيانات في التنسيق المحول.

يطبق الرسم البياني transform_fn ، الذي أصبح الآن جزءًا من النموذج ، جميع منطق المعالجة المسبقة على نقطة البيانات الواردة. يستخدم الثوابت المخزنة (مثل μ و σ لتطبيع الميزات الرقمية) في التشغيل على مستوى المثيل أثناء التنبؤ. لذلك ، يحول الرسم البياني transform_fn نقطة بيانات RAW إلى التنسيق المحول. التنسيق المحول هو ما يتوقعه الواجهة الداخلية النموذجية من أجل إنتاج التنبؤ ، كما هو مبين في الشكل 4.

تحل هذه الآلية التحدي المسبق للمعالجة المتمثلة في انحراف خدمة التدريب ، لأن نفس المنطق (التنفيذ) الذي يتم استخدامه لتحويل بيانات التدريب والتقييم يتم تطبيقه لتحويل نقاط البيانات الجديدة أثناء خدمة التنبؤ.

ملخص خيارات المعالجة المسبقة

يلخص الجدول التالي خيارات المعالجة المسبقة للبيانات التي ناقشتها هذا المستند. في الجدول ، "N/A" يرمز إلى "غير قابل للتطبيق".

^* مع TensorFlow ، يجب إجراء التحولات مثل العبور والتضمين والترميز المتفرّب بشكل تعريفي كأعمدة feature_columns .

ما هو التالي

• لتنفيذ خط أنابيب tf.Transform وتشغيله باستخدام بيانات البيانات ، اقرأ الجزء الثاني من هذه السلسلة ، معالجة البيانات المسبقة لـ ML باستخدام TensorFlow Transform .
• خذ تخصص Coursera على ML مع TensorFlow على Google Cloud .
• تعرف على أفضل الممارسات للهندسة ML في قواعد ML .
• لمزيد من البنية المرجعية ، والرسوم البيانية ، وأفضل الممارسات ، استكشف حلول TFX Cloud .

هذا المستند هو الأول في سلسلة من جزأين تستكشف موضوع هندسة البيانات وهندسة الميزات للتعلم الآلي (ML) ، مع التركيز على مهام التعلم الخاضعة للإشراف. يناقش هذا الجزء الأول أفضل الممارسات للمعالجة المسبقة في خط أنابيب ML على Google Cloud. يركز المستند على استخدام TensorFlow ومكتبة TensorFlow Tensorflow مفتوحة المصدر ( tf.Transform ) لإعداد البيانات ، وتدريب النموذج ، وتقديم النموذج للتنبؤ. يسلط هذا المستند الضوء على تحديات بيانات المعالجة المسبقة لـ ML ، ويصف الخيارات والسيناريوهات لإجراء تحويل البيانات على Google Cloud بفعالية.

يفترض هذا المستند أنك على دراية بـ BigQuery و DataFlow و Vertex AI و TensorFlow Keras API.

يوفر المستند الثاني ، المعالجة المسبقة للبيانات لـ ML مع Google Cloud ، برنامجًا تعليميًا خطوة بخطوة لكيفية تنفيذ خط أنابيب tf.Transform .

مقدمة

يساعدك ML تلقائيًا في العثور على أنماط معقدة وربما مفيدة في البيانات. يتم تكثيف هذه الأنماط في نموذج ML الذي يمكن استخدامه بعد ذلك في نقاط بيانات جديدة - وهي عملية تسمى إجراء التنبؤات أو أداء الاستدلال .

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

يمكن أن يكون حجم مجموعات بيانات التدريب لنماذج ML في العالم الحقيقي يساوي بسهولة أو أكبر من Terabyte (TB). لذلك ، تحتاج إلى أطر عمل على نطاق واسع من أجل معالجة مجموعات البيانات هذه بكفاءة وتوزيع. عند استخدام نموذج ML لعمل تنبؤات ، يجب عليك تطبيق نفس التحولات التي استخدمتها لبيانات التدريب على نقاط البيانات الجديدة. من خلال تطبيق التحولات نفسها ، يمكنك تقديم مجموعة البيانات المباشرة إلى نموذج ML بالطريقة التي يتوقعها النموذج.

يناقش هذه الوثيقة هذه التحديات لمستويات مختلفة من التفاصيل في عمليات هندسة الميزات: مجموعات على مستوى المثيل ، والتمرير الكامل ، وتجمعات الرياح الزمنية. يصف هذا المستند أيضًا الخيارات والسيناريوهات لإجراء تحويل البيانات لـ ML على Google Cloud.

يوفر هذا المستند أيضًا نظرة عامة على تحويل TensorFlow ( tf.Transform ) ، وهي مكتبة لـ TensorFlow التي تتيح لك تحديد كل من تحويل البيانات على مستوى المثيل والتمرير الكامل من خلال خطوط أنابيب البيانات المسبقة للبيانات. يتم تنفيذ خطوط الأنابيب هذه باستخدام Apache Beam ، ويقومون بإنشاء قطع أثرية تتيح لك تطبيق نفس التحولات أثناء التنبؤ كما هو الحال عند تقديم النموذج.

بيانات المعالجة المسبقة لـ ML

يقدم هذا القسم عمليات معالجة البيانات ومراحل استعداد البيانات. كما يناقش أنواع عمليات المعالجة المسبقة والتقلبات.

هندسة البيانات مقارنة بهندسة الميزات

تتضمن المعالجة المسبقة بيانات ML على حد سواء هندسة البيانات وهندسة الميزات. هندسة البيانات هي عملية تحويل البيانات الخام إلى بيانات معدّة . هندسة الميزات ثم تغلب البيانات المعدة لإنشاء الميزات التي يتوقعها نموذج ML. هذه المصطلحات لها المعاني التالية:

البيانات الأولية (أو بيانات فقط)

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

البيانات المعدة

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

ميزات هندسية

مجموعة البيانات مع الميزات المضبوطة التي يتوقعها النموذج-أي الميزات التي يتم إنشاؤها عن طريق تنفيذ بعض العمليات الخاصة بـ ML على الأعمدة في مجموعة البيانات المعدة ، وإنشاء ميزات جديدة لنموذجك أثناء التدريب والتنبؤ ، كما هو موضح لاحقًا في عمليات المعالجة المسبقة . تتضمن أمثلة هذه العمليات توسيع نطاق الأعمدة العددية إلى قيمة بين 0 و 1 ، وقيم القطع ، والميزات الفئوية ذات الحجم الواحد .

يوضح الرسم البياني التالي ، الشكل 1 ، الخطوات التي تشارك في إعداد البيانات المعالجة مسبقًا:

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

العمليات قبل المعالجة

تتضمن المعالجة المسبقة للبيانات عدة عمليات. تم تصميم كل عملية لمساعدة ML على بناء نماذج تنبؤية أفضل. تفاصيل عمليات المعالجة المسبقة هذه خارج نطاق هذا المستند ، ولكن يتم وصف بعض العمليات لفترة وجيزة في هذا القسم.

بالنسبة للبيانات المنظمة ، تتضمن عمليات المعالجة المسبقة للبيانات ما يلي:

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

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

• بالنسبة إلى المستندات النصية: التنقيب والتخليص ، وحساب TF-IDF ، واستخراج n-gram ، والتضمين.
• للصور: القطع ، تغيير حجم ، زراعة ، طمس غاوسي ، ومرشحات الكناري.
• بالنسبة لجميع أنواع البيانات (بما في ذلك النص والصور): نقل التعلم ، والذي يعامل الطبقات المتقدمة من النموذج المدرب بالكامل كخطوة هندسية للميزات.

الحبيبية قبل المعالجة

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

يمكن تصنيف عمليات المعالجة المسبقة والتحول على النحو التالي ، استنادًا إلى الحبيبات العملية:

• التحولات على مستوى الحالة أثناء التدريب والتنبؤ . هذه تحولات واضحة ، حيث هناك حاجة فقط للقيم من نفس المثال للتحول. على سبيل المثال ، قد تتضمن التحولات على مستوى المثيلات تقطيع قيمة ميزة ما إلى بعض العتبة ، مما يوسع تعليديًا ميزة أخرى ، أو مضاعفة ميزتين ، أو مقارنة ميزتين لإنشاء علامة منطقية.

  يجب تطبيق هذه التحولات بشكل متماثل أثناء التدريب والتنبؤ ، لأنه سيتم تدريب النموذج على الميزات المحولة ، وليس على قيم الإدخال الخام. إذا لم يتم تحويل البيانات بشكل متماثل ، فإن النموذج يتصرف بشكل سيء لأنه يتم تقديمه مع البيانات التي لديها توزيع للقيم التي لم يتم تدريبها. لمزيد من المعلومات ، راجع مناقشة انحراف خدمة التدريب في قسم تحديات المعالجة المسبقة .

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

  على سبيل المثال ، لتطبيع ميزة رقمية للتدريب ، يمكنك حساب متوسطها (μ) وانحرافها المعياري (σ) عبر بيانات التدريب بأكملها. يسمى هذا الحساب تشغيل تمرير كامل (أو تحليل ). عندما تخدم النموذج للتنبؤ ، يتم تطبيع قيمة نقطة البيانات الجديدة لتجنب انحراف خدمة التدريب. لذلك ، يتم استخدام القيم μ و σ التي يتم حسابها أثناء التدريب لضبط قيمة الميزة ، وهي العملية البسيطة على مستوى المثيل التالية:

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  تشمل التحولات الكاملة ما يلي:

  • Minmax تحجيم الميزات العددية باستخدام Min و Max محسوبة من مجموعة بيانات التدريب.
  • الميزات العددية القياسية (تطبيع الدرجة Z) باستخدام μ و σ محسوبة على مجموعة بيانات التدريب.
  • دلو الميزات العددية باستخدام الكميات.
  • تحفيز القيم المفقودة باستخدام الوسيط (الميزات العددية) أو الوضع (الميزات الفئوية).
  • تحويل السلاسل (القيم الاسمية) إلى الأعداد الصحيحة (الفهارس) عن طريق استخراج جميع القيم المتميزة (المفردات) لميزة فئران الإدخال.
  • حساب حدوث مصطلح (قيمة الميزة) في جميع المستندات (الحالات) لحساب TF-IDF.
  • حساب PCA لميزات الإدخال لتسريع البيانات في مساحة أبعاد أقل (مع ميزات تعتمد خطيا).

  يجب عليك استخدام بيانات التدريب فقط لحساب الإحصاءات مثل μ و σ و min و max . إذا قمت بإضافة بيانات الاختبار والتقييم لهذه العمليات ، فأنت تتسرب من المعلومات من بيانات التقييم والاختبار لتدريب النموذج. يؤثر القيام بذلك على موثوقية نتائج الاختبار والتقييم. للتأكد من تطبيق تحول ثابت على جميع مجموعات البيانات ، يمكنك استخدام نفس الإحصاءات المحسوبة من بيانات التدريب لتحويل بيانات الاختبار والتقييم.

• التجميعات التاريخية أثناء التدريب والتنبؤ . يتضمن ذلك إنشاء تجميعات الأعمال والاشتقاقات والأعلام كإشارات إدخال لمهمة التنبؤ - على سبيل المثال ، إنشاء مقاييس الحداثة والتردد والنقدية (RFM) للعملاء لبناء نماذج النزعة. يمكن حساب هذه الأنواع من الميزات وتخزينها في متجر للميزات لاستخدامها أثناء التدريب على النماذج ، وتسجيل الدفعة ، وتقديم التنبؤ عبر الإنترنت. يمكنك أيضًا إجراء هندسة إضافية للميزات (على سبيل المثال ، التحول والضبط) لهذه المجموعات قبل التدريب والتنبؤ.

• التجميعات التاريخية أثناء التدريب ، ولكن التجمعات في الوقت الفعلي أثناء التنبؤ . يتضمن هذا النهج إنشاء ميزة من خلال تلخيص القيم في الوقت الفعلي مع مرور الوقت. في هذا النهج ، يتم تعريف الحالات المراد تجميعها من خلال بنود النوافذ الزمنية. على سبيل المثال ، يمكنك استخدام هذا النهج إذا كنت ترغب في تدريب نموذج يقدر وقت رحلة التاكسي بناءً على مقاييس حركة المرور للمسار في الدقائق الخمس الماضية ، في آخر 10 دقائق ، في آخر 30 دقيقة ، وفي آخر ، وفي آخر. فترات. يمكنك أيضًا استخدام هذا النهج للتنبؤ بفشل جزء المحرك استنادًا إلى المتوسط ​​المتحرك لقيم درجة الحرارة والاهتزاز المحسوبة على مدار الدقائق الثلاث الماضية. على الرغم من أنه يمكن إعداد هذه المجموعات دون اتصال بالإنترنت للتدريب ، إلا أنها يتم حسابها في الوقت الفعلي من دفق البيانات أثناء التقديم.

  بتعبير أدق ، عند إعداد بيانات التدريب ، إذا لم تكن القيمة المجمعة في البيانات الأولية ، يتم إنشاء القيمة أثناء مرحلة هندسة البيانات. عادة ما يتم تخزين البيانات الأولية في قاعدة بيانات مع تنسيق (entity, timestamp, value) . في الأمثلة السابقة ، entity هو معرف قطاع الطريق لطرق سيارات الأجرة ومعرف جزء المحرك لفشل المحرك. يمكنك استخدام عمليات Windowing لحساب (entity, time_index, aggregated_value_over_time_window) واستخدام ميزات التجميع كمدخل لتدريب النموذج الخاص بك.

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

خط أنابيب ML على Google Cloud

يناقش هذا القسم المكونات الأساسية لخط أنابيب من طرف إلى طرف نموذجي لتدريب وخدمة نماذج TensorFlow ML على Google Cloud باستخدام الخدمات المدارة. يناقش أيضًا المكان الذي يمكنك فيه تنفيذ فئات مختلفة من عمليات معالجة البيانات المسبقة ، والتحديات الشائعة التي قد تواجهها عند تنفيذ مثل هذه التحولات. يوضح قسم كيفية عمل TF.Transform كيف تساعد مكتبة TensorFlow Transform في مواجهة هذه التحديات.

الهندسة المعمارية عالية المستوى

يوضح الرسم البياني التالي ، الشكل 2 ، بنية عالية المستوى لخط أنابيب ML نموذجي للتدريب وخدمة نماذج TensorFlow. تشير الملصقات A و B و C في الرسم البياني إلى الأماكن المختلفة في خط الأنابيب حيث يمكن أن تحدث معالجة البيانات المسبقة. يتم توفير تفاصيل حول هذه الخطوات في القسم التالي.

يتكون خط الأنابيب من الخطوات التالية:

1. بعد استيراد البيانات الخام ، يتم تخزين البيانات الجدولية في BigQuery ، ويتم تخزين بيانات أخرى مثل الصور والصوت والفيديو ، في التخزين السحابي. يستخدم الجزء الثاني من هذه السلسلة بيانات جدولة مخزنة في BigQuery كمثال.
2. يتم تنفيذ هندسة البيانات (التحضير) وهندسة الميزات على نطاق واسع باستخدام DataFlow. ينتج هذا التنفيذ مجموعات التدريب والتقييم والاختبار جاهزة ML التي يتم تخزينها في التخزين السحابي. من الناحية المثالية ، يتم تخزين مجموعات البيانات هذه كملفات tfrecord ، وهو التنسيق الأمثل لحساب TensorFlow.
3. يتم تقديم حزمة مدرب طراز TensorFlow إلى تدريب Vertex AI ، والذي يستخدم البيانات المعالجة مسبقًا من الخطوات السابقة لتدريب النموذج. إن إخراج هذه الخطوة عبارة عن موسر متكررة مدربة يتم تصديرها إلى التخزين السحابي.
4. يتم نشر نموذج TensorFlow المدربين للتنبؤ AISX AI كخدمة تحتوي على واجهة برمجة تطبيقات REST بحيث يمكن استخدامها للتنبؤات عبر الإنترنت. يمكن أيضًا استخدام نفس النموذج لوظائف التنبؤ بالدفعة.
5. بعد أن يتم نشر النموذج كأو قبل واجهة برمجة تطبيقات REST ، يمكن لتطبيقات العميل والأنظمة الداخلية استدعاء واجهة برمجة التطبيقات عن طريق إرسال الطلبات مع بعض نقاط البيانات ، وتلقي الاستجابات من النموذج مع التنبؤات.
6. لتنسيق خط الأنابيب وأتمتة هذا ، يمكنك استخدام خطوط أنابيب Vertex AI كمجدول لاستدعاء إعدادات البيانات ، والتدريب النموذجي ، وخطوات نشر النموذج.

يمكنك أيضًا استخدام متجر ميزات Vertex AI لتخزين ميزات الإدخال لجعل التنبؤات. على سبيل المثال ، يمكنك إنشاء ميزات هندسية بشكل دوري من أحدث البيانات الخام وتخزينها في متجر ميزة Vertex AI. تجلب تطبيقات العميل ميزات الإدخال المطلوبة من متجر ميزات Vertex AI وإرسالها إلى النموذج لتلقي التنبؤات.

أين تفعل المعالجة المسبقة

في الشكل 2 ، تُظهر الملصقات A و B و C أن عمليات المعالجة المسبقة للبيانات يمكن أن تحدث في BigQuery أو Dataflow أو TensorFlow. تصف الأقسام التالية كيفية عمل كل من هذه الخيارات.

الخيار أ: BigQuery

عادة ، يتم تنفيذ المنطق في BigQuery للعمليات التالية:

• أخذ العينات: اختيار مجموعة فرعية بشكل عشوائي من البيانات.
• التصفية: إزالة حالات غير ذات صلة أو غير صالحة.
• التقسيم: تقسيم البيانات لإنتاج مجموعات التدريب والتقييم والاختبار.

يمكن استخدام البرامج النصية SQL BigQuery كاستعلام مصدر لخط أنابيب معالجة البيانات المسبقة ، وهو خطوة معالجة البيانات في الشكل 2. على سبيل المثال ، إذا تم استخدام نظام في كندا ، والمستودع البيانات لديه معاملات من جميع أنحاء العالم ، والتصفية إلى الحصول على بيانات التدريب في كندا فقط يتم القيام به في BigQuery. تعتبر هندسة الميزات في BigQuery بسيطة وقابلة للتطوير ، وتدعم تنفيذ عمليات التجميع على مستوى المثيل وتاريخ التحولات.

ومع ذلك ، نوصيك باستخدام BigQuery لهندسة الميزات فقط إذا كنت تستخدم النموذج الخاص بك للتنبؤ بالدُفعات (التسجيل) ، أو إذا كانت الميزات محسوبة في BigQuery ، ولكن تم تخزينها في متجر ميزات Vertex AI لاستخدامها أثناء التنبؤ عبر الإنترنت. إذا كنت تخطط لنشر النموذج للتنبؤات عبر الإنترنت ، وإذا لم يكن لديك الميزة المهندسة في متجر للميزات عبر الإنترنت ، فيجب عليك تكرار عمليات المعالجة المسبقة SQL لتحويل نقاط البيانات الخام التي تنشئها الأنظمة الأخرى. بمعنى آخر ، تحتاج إلى تنفيذ المنطق مرتين: مرة واحدة في SQL لبيانات التدريب المسبق في BigQuery ، والمرة الثانية في منطق التطبيق الذي يستهلك النموذج للمعالجة المسبقة للبيانات عبر الإنترنت للتنبؤ.

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

إذا كنت تستخدم النموذج الخاص بك فقط للتنبؤ بالدُفعات (على سبيل المثال ، باستخدام تنبؤ بدفعات Vertex AI) ، وإذا تم الحصول على بياناتك للتسجيل من BigQuery ، فيمكنك تنفيذ عمليات المعالجة المسبقة هذه كجزء من البرنامج النصي BigQuery SQL. في هذه الحالة ، يمكنك استخدام نفس البرنامج النصي SQL Preprocessing لإعداد كل من بيانات التدريب والتسجيل.

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

الخيار ب: Dataflow

كما هو موضح في الشكل 2 ، يمكنك تنفيذ عمليات المعالجة المسبقة باهظة الثمن في حزمة Apache ، وتشغيلها على نطاق واسع باستخدام DataFlow. Dataflow هي خدمة تلقائية تتم إدارتها بالكامل لمعالجة البيانات الدفعة والبث. عند استخدام DataFlow ، يمكنك أيضًا استخدام مكتبات متخصصة خارجية لمعالجة البيانات ، على عكس BigQuery.

يمكن لـ Dataflow إجراء تحويلات على مستوى المثيل ، وتحولات ميزة التجميع التاريخية والوقت الحقيقي. على وجه الخصوص ، إذا كانت نماذج ML تتوقع ميزة إدخال مثل total_number_of_clicks_last_90sec ، فيمكن أن تحسب وظائف Apache Beam Windowing هذه الميزات بناءً على تجميع قيم Windows من بيانات الأحداث في الوقت الفعلي (على سبيل المثال ، على سبيل المثال ، انقر فوق الأحداث). في المناقشة السابقة حول تفاصيل التحولات ، تمت الإشارة إلى ذلك باسم "التجميعات التاريخية أثناء التدريب ، ولكن في الوقت الفعلي أثناء التنبؤ".

يوضح الرسم البياني التالي ، الشكل 3 ، دور تدفق البيانات في معالجة بيانات الدفق للتنبؤات في الوقت الفعلي القريب.

كما هو موضح في الشكل 3 ، أثناء المعالجة ، يتم تناول الأحداث التي تسمى نقاط البيانات في Pub/Sub . يستهلك Dataflow نقاط البيانات هذه ، ويحسب الميزات بناءً على المجاميع مع مرور الوقت ، ثم يستدعي واجهة برمجة تطبيقات ML المنتشرة للتنبؤات. ثم يتم إرسال التنبؤات إلى قائمة انتظار حانة/SUP خارجية. من Pub/Sub ، يمكن استهل يمكن أيضًا تخزين التنبؤات في متجر لبيانات منخفضة الكلية مثل Cloud Bigtable لجلب في الوقت الفعلي. يمكن أيضًا استخدام Cloud Bigtable لتراكم وتخزين هذه التجميعات في الوقت الفعلي حتى يمكن البحث عنها عند الحاجة للتنبؤ.

يمكن استخدام نفس تطبيق Apache Beam لبيانات التدريب على العمليات التي تأتي من مخزن بيانات دون اتصال بالإنترنت مثل بيانات BigQuery و Dream-Process في الوقت الفعلي لخدمة التنبؤات عبر الإنترنت.

في البنية النموذجية الأخرى ، مثل البنية الموضحة في الشكل 2 ، يقوم تطبيق العميل باستدعاء مباشرة واجهة برمجة تطبيقات النموذج المنشور للتنبؤات عبر الإنترنت. في هذه الحالة ، إذا تم تنفيذ عمليات المعالجة المسبقة في تدفق البيانات لإعداد بيانات التدريب ، لا يتم تطبيق العمليات على بيانات التنبؤ التي تنتقل مباشرة إلى النموذج. لذلك ، يجب دمج مثل هذه التحولات في النموذج أثناء التقديم للتنبؤات عبر الإنترنت.

يمكن استخدام Dataflow لأداء التحول الكامل ، عن طريق حساب الإحصاءات المطلوبة على نطاق واسع. ومع ذلك ، يجب تخزين هذه الإحصائيات في مكان ما لاستخدامه أثناء التنبؤ لتحويل نقاط بيانات التنبؤ. باستخدام مكتبة TensorFlow Transform ( tf.Transform ) ، يمكنك تضمين هذه الإحصائيات مباشرة في النموذج بدلاً من تخزينها في مكان آخر. يتم شرح هذا النهج لاحقًا في كيفية عمل TF.Transform .

الخيار C: TensorFlow

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

• تنفيذ جميع منطق التحويل على مستوى المثيل في وظيفة input_fn وفي وظيفة serving_fn . تقوم وظيفة input_fn بإعداد مجموعة بيانات باستخدام واجهة برمجة تطبيقات tf.data.Dataset لتدريب نموذج. تتلقى وظيفة serving_fn بيانات التنبؤات وتعدها.
• وضع رمز التحويل مباشرة في نموذج TensorFlow الخاص بك باستخدام طبقات المعالجة المسبقة Keras أو إنشاء طبقات مخصصة .

يحدد رمز منطق التحويل في وظيفة serving_fn واجهة التقديم الخاصة بـ SaveDmodel للتنبؤ عبر الإنترنت. إذا قمت بتنفيذ نفس التحولات التي تم استخدامها لإعداد بيانات التدريب في رمز منطق التحول لوظيفة serving_fn ، فإنه يضمن تطبيق التحولات نفسها على نقاط بيانات التنبؤ الجديدة عند تقديمها.

ومع ذلك ، نظرًا لأن نموذج TensorFlow يعالج كل نقطة بيانات بشكل مستقل أو في دفعة صغيرة ، لا يمكنك حساب التجميعات من جميع نقاط البيانات. نتيجة لذلك ، لا يمكن تنفيذ التحولات الكاملة في نموذج TensorFlow.

تحديات المعالجة المسبقة

فيما يلي التحديات الأساسية لتنفيذ المعالجة المسبقة للبيانات:

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

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

• التحولات كاملة التمرير . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

ما هو التالي

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

مقدمة

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data )

The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.

Prepared data

The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.

Engineered features

The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

• Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
• Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
• Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
• Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
• Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
• Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
• Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

• For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
• For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
• For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

• Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.

  These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.

• Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.

  For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Full-pass transformations include the following:

  • MinMax scaling numerical features using min and max computed from the training dataset.
  • Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
  • Bucketizing numerical features using quantiles.
  • Imputing missing values using the median (numerical features) or the mode (categorical features).
  • Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
  • Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
  • Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).

  You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.

• Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

• Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other فترات. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

  More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.

  When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

High-level architecture

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

The pipeline consists of the following steps:

1. After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
2. Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
3. A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
4. The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
5. After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
6. For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

• Sampling: randomly selecting a subset from the data.
• Filtering: removing irrelevant or invalid instances.
• Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

• Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
• Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

• Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.

  If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.

• Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

ما هو التالي

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .