پیش پردازش داده ها برای ML: گزینه ها و توصیه ها

این سند اولین مورد از یک سری دو قسمتی است که موضوع مهندسی داده و مهندسی ویژگی برای یادگیری ماشین (ML) را با تمرکز بر وظایف یادگیری نظارت شده بررسی می کند. این بخش اول بهترین روش‌ها برای پیش‌پردازش داده‌ها در خط لوله ML در Google Cloud را مورد بحث قرار می‌دهد. این سند بر استفاده از TensorFlow و کتابخانه منبع باز TensorFlow Transform ( tf.Transform ) برای تهیه داده ها، آموزش مدل و ارائه مدل برای پیش بینی تمرکز دارد. این سند چالش‌های پیش‌پردازش داده‌ها برای ML را برجسته می‌کند و گزینه‌ها و سناریوها را برای انجام تبدیل داده‌ها در Google Cloud به طور موثر توصیف می‌کند.

این سند فرض می‌کند که شما با BigQuery ، Dataflow ، Vertex AI و TensorFlow Keras API آشنا هستید.

سند دوم، پیش پردازش داده برای ML با Google Cloud ، یک آموزش گام به گام برای نحوه اجرای خط لوله tf.Transform ارائه می دهد.

مقدمه

ML به شما کمک می کند به طور خودکار الگوهای پیچیده و بالقوه مفید را در داده ها پیدا کنید. این الگوها در یک مدل ML فشرده می‌شوند که سپس می‌تواند در نقاط داده جدید استفاده شود - فرآیندی به نام پیش‌بینی یا انجام استنتاج .

ساخت یک مدل ML یک فرآیند چند مرحله ای است. هر مرحله چالش های فنی و مفهومی خود را ارائه می دهد. این مجموعه دو قسمتی بر روی وظایف یادگیری نظارت شده و فرآیند انتخاب، تبدیل، و تقویت داده های منبع برای ایجاد سیگنال های پیش بینی قدرتمند برای متغیر هدف تمرکز دارد. این عملیات دانش حوزه را با تکنیک های علم داده ترکیب می کند. عملیات جوهره مهندسی ویژگی هستند.

اندازه مجموعه داده های آموزشی برای مدل های واقعی ML می تواند به راحتی برابر یا بیشتر از یک ترابایت (TB) باشد. بنابراین، شما به چارچوب‌های پردازش داده در مقیاس بزرگ نیاز دارید تا این مجموعه داده‌ها را به طور کارآمد و توزیع‌شده پردازش کنید. هنگامی که از یک مدل ML برای پیش‌بینی استفاده می‌کنید، باید همان تبدیل‌هایی را که برای داده‌های آموزشی استفاده کردید، در نقاط داده جدید اعمال کنید. با اعمال همان تبدیل ها، مجموعه داده زنده را به روشی که مدل انتظار دارد به مدل ML ارائه می دهید.

این سند این چالش‌ها را برای سطوح مختلف دانه‌بندی عملیات مهندسی ویژگی مورد بحث قرار می‌دهد: تجمع‌های سطح نمونه، تمام گذر، و پنجره زمانی. این سند همچنین گزینه ها و سناریوهای انجام تبدیل داده برای ML در Google Cloud را توضیح می دهد.

این سند همچنین یک نمای کلی از TensorFlow Transform ( tf.Transform ) ارائه می‌کند، کتابخانه‌ای برای TensorFlow که به شما امکان می‌دهد از طریق خطوط لوله پیش‌پردازش داده، تبدیل داده در سطح نمونه و گذر کامل را تعریف کنید. این خطوط لوله با پرتو آپاچی اجرا می‌شوند و مصنوعاتی را ایجاد می‌کنند که به شما امکان می‌دهند همان تغییر شکل‌ها را در هنگام پیش‌بینی اعمال کنید.

پیش پردازش داده ها برای ML

این بخش به معرفی عملیات پیش پردازش داده ها و مراحل آمادگی داده می پردازد. همچنین انواع عملیات پیش پردازش و دانه بندی آنها را مورد بحث قرار می دهد.

مهندسی داده در مقایسه با مهندسی ویژگی

پیش پردازش داده ها برای ML هم شامل مهندسی داده و هم مهندسی ویژگی است. مهندسی داده فرآیند تبدیل داده های خام به داده های آماده است. سپس مهندسی ویژگی، داده های آماده شده را تنظیم می کند تا ویژگی های مورد انتظار مدل ML را ایجاد کند. این اصطلاحات معانی زیر را دارند:

داده های خام (یا فقط داده ها )

داده ها به شکل منبع خود، بدون هیچ گونه آمادگی قبلی برای ML. در این زمینه، داده ها ممکن است به صورت خام (در یک دریاچه داده) یا به شکل تبدیل شده (در یک انبار داده) باشند. داده‌های تبدیل‌شده در انبار داده‌ها ممکن است از شکل خام اصلی خود تبدیل شده باشند تا برای تجزیه و تحلیل استفاده شوند. با این حال، در این زمینه، داده های خام به این معنی است که داده ها به طور خاص برای وظیفه ML شما آماده نشده اند. اگر داده‌ها از سیستم‌های جریانی ارسال شوند که در نهایت مدل‌های ML را برای پیش‌بینی فراخوانی می‌کنند، داده‌های خام نیز در نظر گرفته می‌شوند.

داده های آماده شده

مجموعه داده در فرم آماده برای کار ML شما: منابع داده تجزیه شده، به هم پیوسته و در یک فرم جدولی قرار داده شده است. داده‌های آماده‌شده جمع‌آوری و با جزئیات درست خلاصه می‌شوند - برای مثال، هر ردیف در مجموعه داده نشان‌دهنده یک مشتری منحصر به فرد است، و هر ستون اطلاعات خلاصه‌ای را برای مشتری نشان می‌دهد، مانند کل هزینه شده در شش هفته گذشته. در جدول داده های آماده شده، ستون های نامربوط حذف شده اند و رکوردهای نامعتبر فیلتر شده اند. برای وظایف یادگیری تحت نظارت، ویژگی هدف وجود دارد.

ویژگی های مهندسی شده

مجموعه داده با ویژگی‌های تنظیم‌شده‌ای که توسط مدل مورد انتظار است - یعنی ویژگی‌هایی که با انجام برخی عملیات خاص ML بر روی ستون‌های مجموعه داده آماده‌شده ایجاد می‌شوند، و ایجاد ویژگی‌های جدید برای مدل شما در طول آموزش و پیش‌بینی، همانطور که بعدا توضیح داده شد. در عملیات پیش پردازش نمونه هایی از این عملیات عبارتند از مقیاس بندی ستون های عددی به مقداری بین 0 و 1، مقادیر برش، و ویژگی های طبقه بندی یک کدگذاری داغ .

نمودار زیر، شکل 1، مراحلی را نشان می دهد که در تهیه داده های از پیش پردازش شده درگیر است:

در عمل، داده های یک منبع اغلب در مراحل مختلف آمادگی هستند. به عنوان مثال، یک فیلد از یک جدول در انبار داده شما ممکن است مستقیماً به عنوان یک ویژگی مهندسی شده استفاده شود. در همان زمان، فیلد دیگری در همان جدول ممکن است قبل از تبدیل شدن به یک ویژگی مهندسی شده، نیاز به تغییرات داشته باشد. به طور مشابه، مهندسی داده و عملیات مهندسی ویژگی ممکن است در یک مرحله پیش پردازش داده ترکیب شوند.

عملیات پیش پردازش

پیش پردازش داده شامل چندین عملیات است. هر عملیات برای کمک به ML در ساخت مدل های پیش بینی بهتر طراحی شده است. جزئیات این عملیات پیش پردازش خارج از محدوده این سند است، اما برخی از عملیات به طور خلاصه در این بخش توضیح داده شده است.

برای داده های ساخت یافته، عملیات پیش پردازش داده ها شامل موارد زیر است:

• پاکسازی داده ها: حذف یا تصحیح سوابقی که دارای مقادیر خراب یا نامعتبر از داده های خام هستند، و حذف رکوردهایی که تعداد زیادی ستون را از دست داده اند.
• انتخاب و پارتیشن بندی نمونه ها: انتخاب نقاط داده از مجموعه داده ورودی برای ایجاد آموزش، ارزیابی (اعتبارسنجی) و مجموعه های آزمایشی . این فرآیند شامل تکنیک‌هایی برای نمونه‌گیری تصادفی تکرارپذیر، نمونه‌برداری بیش از حد کلاس‌های اقلیت و تقسیم‌بندی طبقه‌ای است.
• تنظیم ویژگی: بهبود کیفیت یک ویژگی برای ML، که شامل مقیاس بندی و عادی سازی مقادیر عددی، نسبت دادن مقادیر از دست رفته، برش نقاط پرت و تنظیم مقادیری است که دارای توزیع های منحرف هستند.
• تبدیل ویژگی: تبدیل یک ویژگی عددی به یک ویژگی طبقه‌بندی (از طریق سطل‌سازی )، و تبدیل ویژگی‌های دسته‌بندی به یک نمایش عددی (از طریق رمزگذاری یک‌بار، یادگیری با شمارش ، تعبیه‌های پراکنده ویژگی و غیره). برخی از مدل ها فقط با ویژگی های عددی یا دسته بندی کار می کنند، در حالی که برخی دیگر می توانند ویژگی های نوع ترکیبی را مدیریت کنند. حتی زمانی که مدل‌ها هر دو نوع را مدیریت می‌کنند، می‌توانند از نمایش‌های متفاوت (عددی و دسته‌بندی) یک ویژگی بهره ببرند.
• استخراج ویژگی: کاهش تعداد ویژگی‌ها با ایجاد نمایش داده‌های با ابعاد پایین‌تر و قدرتمندتر با استفاده از تکنیک‌هایی مانند PCA ، تعبیه استخراج و هش کردن .
• انتخاب ویژگی: انتخاب زیرمجموعه‌ای از ویژگی‌های ورودی برای آموزش مدل، و نادیده گرفتن موارد نامربوط یا اضافی، با استفاده از روش‌های فیلتر یا پوشش . در صورتی که ویژگی‌ها تعداد زیادی از مقادیر را از دست داده باشند، انتخاب ویژگی می‌تواند به سادگی شامل حذف ویژگی‌ها باشد.
• ساخت ویژگی: ایجاد ویژگی‌های جدید با استفاده از تکنیک‌های معمولی، مانند بسط چند جمله‌ای (با استفاده از توابع ریاضی تک متغیره) یا تلاقی ویژگی (برای ثبت تعاملات ویژگی). ویژگی‌ها را نیز می‌توان با استفاده از منطق تجاری از دامنه مورد استفاده ML ساخت.

وقتی با داده‌های بدون ساختار (مثلاً تصاویر، صدا یا اسناد متنی) کار می‌کنید، یادگیری عمیق با تا کردن آن در معماری مدل، جایگزین مهندسی ویژگی‌های مبتنی بر دانش می‌شود. لایه کانولوشن یک پیش پردازنده ویژگی خودکار است. ساختن معماری مدل مناسب نیاز به دانش تجربی از داده ها دارد. علاوه بر این، مقداری پیش پردازش مورد نیاز است، مانند موارد زیر:

• برای اسناد متنی: ریشه‌بندی و واژه‌سازی ، محاسبه TF-IDF ، و استخراج n گرم ، جستجوی جاسازی.
• برای تصاویر: برش، تغییر اندازه، برش، تاری گاوسی و فیلترهای قناری.
• برای همه انواع داده ها (از جمله متن و تصویر): آموزش انتقال ، که لایه های آخر مدل کاملاً آموزش دیده را به عنوان یک مرحله مهندسی ویژگی در نظر می گیرد.

دانه بندی پیش پردازش

این بخش در مورد جزئیات انواع تبدیل داده ها بحث می کند. این نشان می‌دهد که چرا این دیدگاه هنگام تهیه نقاط داده جدید برای پیش‌بینی‌ها با استفاده از تبدیل‌هایی که بر روی داده‌های آموزشی اعمال می‌شوند، حیاتی است.

عملیات پیش پردازش و تبدیل را می توان بر اساس دانه بندی عملیات به صورت زیر دسته بندی کرد:

• تحولات سطح نمونه در طول آموزش و پیش بینی . اینها تبدیلات مستقیمی هستند، که در آن فقط مقادیری از همان نمونه برای تبدیل مورد نیاز است. برای مثال، تبدیل‌های سطح نمونه ممکن است شامل بریدن مقدار یک ویژگی به مقداری آستانه، گسترش چند جمله‌ای ویژگی دیگر، ضرب دو ویژگی، یا مقایسه دو ویژگی برای ایجاد یک پرچم بولی باشد.

  این تبدیل ها باید در طول آموزش و پیش بینی به طور یکسان اعمال شوند، زیرا مدل بر روی ویژگی های تبدیل شده آموزش داده می شود، نه بر روی مقادیر ورودی خام. اگر داده ها به طور یکسان تبدیل نشده باشند، آنگاه مدل بد رفتار می کند زیرا با داده هایی ارائه می شود که دارای توزیع مقادیری است که با آن آموزش ندیده است. برای اطلاعات بیشتر، به بحث چولگی در خدمت آموزش در بخش چالش های پیش پردازش مراجعه کنید.

• تبدیل‌های پاس کامل در طول تمرین، اما تبدیل‌های سطح نمونه در طول پیش‌بینی . در این سناریو، تبدیل ها حالتی هستند، زیرا از برخی آمارهای از پیش محاسبه شده برای انجام تبدیل استفاده می کنند. در طول آموزش، کل داده های آموزشی را برای محاسبه مقادیری مانند حداقل، حداکثر، میانگین و واریانس برای تبدیل داده های آموزشی، داده های ارزیابی و داده های جدید در زمان پیش بینی تجزیه و تحلیل می کنید.

  به عنوان مثال، برای عادی سازی یک ویژگی عددی برای آموزش، میانگین آن (μ) و انحراف استاندارد آن (σ) را در کل داده های آموزشی محاسبه می کنید. این محاسبات عملیات تمام گذر (یا تجزیه و تحلیل ) نامیده می شود. هنگامی که مدل را برای پیش‌بینی ارائه می‌کنید، مقدار یک نقطه داده جدید عادی می‌شود تا از انحراف در ارائه آموزش جلوگیری شود. بنابراین، مقادیر μ و σ که در طول آموزش محاسبه می‌شوند برای تنظیم مقدار ویژگی استفاده می‌شوند، که عملیات سطح نمونه ساده زیر است:

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

  تبدیل های تمام گذر شامل موارد زیر است:

  • مقیاس‌بندی MinMax ویژگی‌های عددی با استفاده از min و max محاسبه‌شده از مجموعه داده آموزشی.
  • مقیاس بندی استاندارد (نرمال سازی امتیاز z) ویژگی های عددی با استفاده از μ و σ محاسبه شده بر روی مجموعه داده آموزشی.
  • سطل سازی ویژگی های عددی با استفاده از چندک.
  • وارد کردن مقادیر گمشده با استفاده از میانه (ویژگی های عددی) یا حالت (ویژگی های طبقه بندی).
  • تبدیل رشته ها (مقادیر اسمی) به اعداد صحیح (شاخص ها) با استخراج تمام مقادیر متمایز (واژگان) یک ویژگی طبقه بندی ورودی.
  • شمارش وقوع یک اصطلاح (مقدار ویژگی) در تمام اسناد (نمونه‌ها) برای محاسبه 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 با استفاده از خدمات مدیریت شده مورد بحث قرار می دهد. همچنین در مورد جایی که می‌توانید دسته‌های مختلف عملیات پیش‌پردازش داده‌ها را پیاده‌سازی کنید و چالش‌های رایجی که ممکن است هنگام اجرای چنین تبدیل‌هایی با آن‌ها مواجه شوید، بحث می‌کند. بخش How tf.Transform Works نشان می دهد که چگونه کتابخانه TensorFlow Transform به رفع این چالش ها کمک می کند.

معماری سطح بالا

نمودار زیر، شکل 2، یک معماری سطح بالا از یک خط لوله معمولی ML را برای آموزش و ارائه مدل های TensorFlow نشان می دهد. برچسب‌های A، B و C در نمودار به مکان‌های مختلف خط لوله اشاره می‌کنند که پیش‌پردازش داده‌ها می‌تواند انجام شود. جزئیات مربوط به این مراحل در بخش زیر ارائه شده است.

خط لوله شامل مراحل زیر است:

1. پس از وارد کردن داده‌های خام، داده‌های جدولی در BigQuery و سایر داده‌ها مانند تصاویر، صدا و ویدیو در فضای ذخیره‌سازی ابری ذخیره می‌شوند. قسمت دوم این سری از داده های جدولی ذخیره شده در BigQuery به عنوان مثال استفاده می کند.
2. مهندسی داده (آماده سازی) و مهندسی ویژگی در مقیاس با استفاده از Dataflow اجرا می شوند. این اجرا مجموعه‌های آموزش، ارزیابی و تست آماده ML را تولید می‌کند که در فضای ذخیره‌سازی ابری ذخیره می‌شوند. در حالت ایده آل، این مجموعه داده ها به عنوان فایل های TFRecord ذخیره می شوند که فرمت بهینه شده برای محاسبات TensorFlow است.
3. بسته آموزشی مدل TensorFlow به Vertex AI Training ارسال می‌شود که از داده‌های از پیش پردازش شده مراحل قبلی برای آموزش مدل استفاده می‌کند. خروجی این مرحله یک TensorFlow SavedModel آموزش دیده است که به Cloud Storage صادر می شود.
4. مدل آموزش‌دیده TensorFlow در Vertex AI Prediction به‌عنوان سرویسی که دارای API REST است، به کار گرفته شده است تا بتوان از آن برای پیش‌بینی‌های آنلاین استفاده کرد. از همین مدل می توان برای کارهای پیش بینی دسته ای نیز استفاده کرد.
5. پس از استقرار مدل به‌عنوان REST API، برنامه‌های مشتری و سیستم‌های داخلی می‌توانند با ارسال درخواست‌هایی با برخی نقاط داده و دریافت پاسخ‌هایی از مدل با پیش‌بینی، API را فراخوانی کنند.
6. برای هماهنگی و خودکارسازی این خط لوله، می‌توانید از Vertex AI Pipelines به عنوان زمان‌بندی برای فراخوانی مراحل آماده‌سازی داده، آموزش مدل و استقرار مدل استفاده کنید.

همچنین می‌توانید از Vertex AI Feature Store برای ذخیره ویژگی‌های ورودی برای پیش‌بینی استفاده کنید. به عنوان مثال، می‌توانید به صورت دوره‌ای ویژگی‌های مهندسی شده را از آخرین داده‌های خام ایجاد کرده و آنها را در فروشگاه ویژگی‌های Vertex AI ذخیره کنید. برنامه های سرویس گیرنده ویژگی های ورودی مورد نیاز را از Vertex AI Feature Store واکشی می کنند و برای دریافت پیش بینی ها به مدل ارسال می کنند.

پیش پردازش را کجا انجام دهیم

در شکل 2، برچسب های A، B و C نشان می دهند که عملیات پیش پردازش داده ها می تواند در BigQuery، Dataflow یا TensorFlow انجام شود. بخش های زیر نحوه عملکرد هر یک از این گزینه ها را شرح می دهد.

گزینه A: BigQuery

به طور معمول، منطق در BigQuery برای عملیات زیر پیاده سازی می شود:

• نمونه گیری: انتخاب تصادفی زیر مجموعه ای از داده ها.
• فیلتر کردن: حذف نمونه های نامربوط یا نامعتبر.
• پارتیشن بندی: تقسیم داده ها برای تولید آموزش، ارزیابی و مجموعه های تست.

اسکریپت‌های BigQuery SQL را می‌توان به‌عنوان پرس‌وجو منبع برای خط لوله پیش‌پردازش Dataflow، که مرحله پردازش داده در شکل 2 است، استفاده کرد. برای مثال، اگر سیستمی در کانادا استفاده می‌شود و انبار داده دارای تراکنش‌هایی از سراسر جهان است، فیلتر کردن به دریافت داده های آموزشی فقط در کانادا به بهترین وجه در BigQuery انجام می شود. مهندسی ویژگی در BigQuery ساده و مقیاس‌پذیر است و از پیاده‌سازی تغییرات ویژگی‌ها در سطح نمونه و تجمیع‌های تاریخی پشتیبانی می‌کند.

با این حال، توصیه می‌کنیم که از BigQuery برای مهندسی ویژگی‌ها فقط در صورتی استفاده کنید که از مدل خود برای پیش‌بینی دسته‌ای (امتیاز) استفاده می‌کنید، یا اگر ویژگی‌ها از قبل در BigQuery محاسبه شده‌اند، اما در Vertex AI Feature Store ذخیره شده‌اند تا در حین پیش‌بینی آنلاین استفاده شوند. اگر قصد دارید مدل را برای پیش‌بینی‌های آنلاین مستقر کنید، و اگر ویژگی مهندسی شده را در فروشگاه ویژگی‌های آنلاین ندارید، باید عملیات پیش‌پردازش SQL را برای تبدیل نقاط داده خام که سایر سیستم‌ها تولید می‌کنند، تکرار کنید. به عبارت دیگر، شما باید منطق را دو بار پیاده سازی کنید: یک بار در SQL برای پیش پردازش داده های آموزشی در BigQuery، و بار دوم در منطق برنامه ای که مدل را برای پیش پردازش نقاط داده آنلاین برای پیش بینی مصرف می کند.

به عنوان مثال، اگر برنامه مشتری شما به زبان جاوا نوشته شده است، باید منطق را در جاوا دوباره پیاده سازی کنید. این می‌تواند خطاهایی را به‌دلیل ناهماهنگی‌های پیاده‌سازی ایجاد کند، همانطور که در بخش چوله‌ای در خدمت آموزش چالش‌های پیش‌پردازش بعداً در این سند توضیح داده شد. همچنین برای حفظ دو پیاده سازی متفاوت هزینه اضافی است. هر زمان که منطق SQL را برای پیش پردازش داده های آموزشی تغییر می دهید، باید پیاده سازی جاوا را بر این اساس به داده های پیش پردازش در زمان ارائه تغییر دهید.

اگر از مدل خود فقط برای پیش‌بینی دسته‌ای استفاده می‌کنید (به عنوان مثال، با استفاده از پیش‌بینی دسته‌ای Vertex AI)، و اگر داده‌های امتیازدهی شما از BigQuery گرفته شده است، می‌توانید این عملیات پیش‌پردازش را به عنوان بخشی از اسکریپت BigQuery SQL پیاده‌سازی کنید. در آن صورت، می‌توانید از همان اسکریپت SQL پیش‌پردازش برای آماده‌سازی داده‌های آموزشی و امتیازدهی استفاده کنید.

تبدیل های حالتی کامل برای پیاده سازی در BigQuery مناسب نیستند. اگر از BigQuery برای تبدیل‌های تمام گذر استفاده می‌کنید، به جداول کمکی برای ذخیره مقادیر مورد نیاز تبدیل‌های حالتی، مانند میانگین‌ها و واریانس‌ها برای مقیاس‌بندی ویژگی‌های عددی، نیاز دارید. علاوه بر این، پیاده سازی تبدیل های تمام گذر با استفاده از SQL در BigQuery پیچیدگی بیشتری در اسکریپت های SQL ایجاد می کند و وابستگی پیچیده ای بین آموزش و اسکریپت های SQL امتیازدهی ایجاد می کند.

گزینه B: Dataflow

همانطور که در شکل 2 نشان داده شده است، می توانید عملیات پیش پردازش محاسباتی گران قیمت را در Apache Beam پیاده سازی کنید و آنها را در مقیاس با استفاده از Dataflow اجرا کنید. Dataflow یک سرویس مقیاس خودکار کاملاً مدیریت شده برای پردازش دسته ای و جریانی داده است. هنگامی که از Dataflow استفاده می کنید، برخلاف BigQuery می توانید از کتابخانه های تخصصی خارجی نیز برای پردازش داده ها استفاده کنید.

جریان داده می‌تواند تبدیل‌های سطح نمونه، و تبدیل ویژگی‌های تجمع تاریخی و بلادرنگ را انجام دهد. به ویژه، اگر مدل‌های ML شما انتظار یک ویژگی ورودی مانند total_number_of_clicks_last_90sec را دارند، توابع پنجره‌سازی پرتو Apache می‌توانند این ویژگی‌ها را بر اساس جمع‌آوری مقادیر پنجره‌های زمانی داده‌های رویدادهای بلادرنگ (جریان‌سازی) محاسبه کنند (به عنوان مثال، رویدادهای کلیک). در بحث قبلی در مورد دانه بندی تبدیل ها ، این به عنوان "تجمیع های تاریخی در طول آموزش، اما تجمعات بلادرنگ در طول پیش بینی" نامیده می شد.

نمودار زیر، شکل 3، نقش Dataflow را در پردازش داده های جریان برای پیش بینی های زمان واقعی نشان می دهد.

همانطور که در شکل 3 نشان داده شده است، در طول پردازش، رویدادهایی به نام نقاط داده در Pub/Sub وارد می شوند. Dataflow این نقاط داده را مصرف می کند، ویژگی ها را بر اساس مجموعات در طول زمان محاسبه می کند و سپس API مدل ML مستقر شده را برای پیش بینی فراخوانی می کند. پیش‌بینی‌ها سپس به یک صف Pub/Sub خروجی ارسال می‌شوند. از Pub/Sub، پیش‌بینی‌ها را می‌توان توسط سیستم‌های پایین‌دستی مانند نظارت یا کنترل مصرف کرد، یا می‌توان آن‌ها را (مثلاً به‌عنوان اعلان) به مشتری اصلی درخواست‌کننده بازگرداند. پیش‌بینی‌ها همچنین می‌توانند در یک ذخیره‌گاه داده با تأخیر کم مانند Cloud Bigtable برای واکشی بلادرنگ ذخیره شوند. همچنین می‌توان از Cloud Bigtable برای جمع‌آوری و ذخیره‌سازی این مجموعه‌های بی‌درنگ استفاده کرد تا در صورت نیاز برای پیش‌بینی بتوان آن‌ها را جستجو کرد.

همان پیاده‌سازی Apache Beam را می‌توان برای پردازش دسته‌ای داده‌های آموزشی که از یک دیتا استور آفلاین مانند BigQuery می‌آیند و داده‌های بیدرنگ پردازش جریانی برای ارائه پیش‌بینی‌های آنلاین استفاده کرد.

در سایر معماری های معمولی، مانند معماری نشان داده شده در شکل 2، برنامه مشتری مستقیماً API مدل مستقر شده را برای پیش بینی های آنلاین فراخوانی می کند. در آن صورت، اگر عملیات پیش‌پردازش در Dataflow برای آماده‌سازی داده‌های آموزشی پیاده‌سازی شود، عملیات روی داده‌های پیش‌بینی که مستقیماً به مدل می‌رود اعمال نمی‌شوند. بنابراین، تغییراتی مانند اینها باید در طول ارائه برای پیش‌بینی‌های آنلاین در مدل ادغام شوند.

جریان داده را می توان با محاسبه آمارهای مورد نیاز در مقیاس برای انجام تبدیل تمام گذر استفاده کرد. با این حال، این آمار باید در جایی ذخیره شود تا در حین پیش بینی برای تبدیل نقاط داده پیش بینی استفاده شود. با استفاده از کتابخانه TensorFlow Transform ( tf.Transform )، می‌توانید این آمارها را به‌جای ذخیره در جای دیگر، مستقیماً در مدل جاسازی کنید. این رویکرد بعداً در نحوه کار tf.Transform توضیح داده شده است.

گزینه C: TensorFlow

همانطور که در شکل 2 نشان داده شده است، می توانید عملیات پیش پردازش و تبدیل داده ها را در خود مدل TensorFlow پیاده سازی کنید. همانطور که در شکل نشان داده شده است، پیش پردازشی که برای آموزش مدل TensorFlow پیاده سازی می کنید، زمانی که مدل صادر شده و برای پیش بینی ها به کار گرفته می شود، بخشی جدایی ناپذیر از مدل می شود. تبدیل در مدل TensorFlow را می توان به یکی از روش های زیر انجام داد:

• پیاده سازی تمام منطق تبدیل سطح نمونه در تابع input_fn و در تابع serving_fn . تابع input_fn یک مجموعه داده را با استفاده از tf.data.Dataset API برای آموزش یک مدل آماده می کند. تابع serving_fn داده ها را برای پیش بینی ها دریافت و آماده می کند.
• با استفاده از لایه های پیش پردازش Keras یا ایجاد لایه های سفارشی، کد تبدیل را مستقیماً در مدل TensorFlow خود قرار دهید.

کد منطقی تبدیل در تابع serving_fn رابط سرویس SavedModel شما را برای پیش‌بینی آنلاین تعریف می‌کند. اگر همان تبدیل‌هایی را که برای آماده‌سازی داده‌های آموزشی استفاده شده‌اند، در کد منطقی تبدیل تابع serving_fn پیاده‌سازی کنید، تضمین می‌کند که همان تبدیل‌ها به نقاط داده پیش‌بینی جدید هنگام ارائه آنها اعمال می‌شود.

با این حال، از آنجایی که مدل TensorFlow هر نقطه داده را به طور مستقل یا در یک دسته کوچک پردازش می‌کند، نمی‌توانید تجمیع‌ها را از همه نقاط داده محاسبه کنید. در نتیجه، تبدیل های تمام گذر نمی توانند در مدل TensorFlow شما پیاده سازی شوند.

چالش های پیش پردازش

چالش های اصلی پیاده سازی پیش پردازش داده ها به شرح زیر است:

• چوله آموزشی-سرویس . انحراف تمرین-سرویس به تفاوت بین اثربخشی (عملکرد پیش بینی کننده) در حین تمرین و در حین سرو اشاره دارد. این انحراف می تواند ناشی از عدم تطابق بین نحوه مدیریت داده ها در آموزش و خطوط لوله سرویس دهی باشد. به عنوان مثال، اگر مدل شما بر روی یک ویژگی تغییر لگاریتمی آموزش دیده باشد، اما در حین ارائه با ویژگی خام ارائه شود، ممکن است خروجی پیش‌بینی دقیق نباشد.

  اگر تبدیل‌ها به بخشی از خود مدل تبدیل شوند، می‌توان آن‌طور که قبلاً در گزینه C: TensorFlow توضیح داده شد، تبدیل‌های سطح نمونه را انجام داد. در آن صورت، رابط سرویس دهی مدل (تابع serving_fn ) انتظار داده های خام را دارد، در حالی که مدل به صورت داخلی این داده ها را قبل از محاسبه خروجی تبدیل می کند. تحولات همان تغییراتی است که در نقاط داده های آموزش خام و پیش بینی اعمال شد.

• تحولات پاس کامل شما نمی توانید تبدیل های تمام گذر مانند تغییر مقیاس و نرمال سازی را در مدل TensorFlow خود پیاده سازی کنید. در تبدیل‌های تمام گذر، برخی از آمارها (مثلاً مقادیر max و min برای مقیاس‌بندی ویژگی‌های عددی) باید از قبل روی داده‌های آموزشی محاسبه شوند، همانطور که در گزینه B توضیح داده شده است: جریان داده . سپس مقادیر باید در جایی ذخیره شوند تا در طول خدمت مدل برای پیش‌بینی برای تبدیل نقاط داده خام جدید به عنوان تبدیل‌های سطح نمونه استفاده شوند، که از انحراف در خدمت آموزشی جلوگیری می‌کند. می توانید از کتابخانه TensorFlow Transform ( tf.Transform ) برای جاسازی مستقیم آمار در مدل TensorFlow خود استفاده کنید. این رویکرد بعداً در نحوه کار tf.Transform توضیح داده شده است.

• آماده سازی داده ها از قبل برای کارایی آموزش بهتر . اجرای تحولات سطح نمونه به عنوان بخشی از مدل می تواند کارایی فرآیند آموزش را کاهش دهد. این تنزل به این دلیل اتفاق می‌افتد که همان دگرگونی‌ها به طور مکرر برای داده‌های آموزشی مشابه در هر دوره اعمال می‌شوند. تصور کنید که داده‌های آموزشی خام با 1000 ویژگی دارید و ترکیبی از تبدیل‌های سطح نمونه را برای ایجاد 10000 ویژگی اعمال می‌کنید. اگر این تبدیل‌ها را به عنوان بخشی از مدل خود پیاده‌سازی کنید، و سپس داده‌های آموزشی خام را به مدل بدهید، این 10000 عملیات N بار در هر نمونه اعمال می‌شوند، جایی که N تعداد دوره‌ها است. به‌علاوه، اگر از شتاب‌دهنده‌ها (GPU یا TPU) استفاده می‌کنید، در حالی که CPU این تغییرات را انجام می‌دهد، بیکار می‌نشینند، که استفاده کارآمدی از شتاب‌دهنده‌های پرهزینه شما نیست.

  در حالت ایده‌آل، داده‌های آموزشی قبل از آموزش با استفاده از تکنیک توضیح داده شده در گزینه B: جریان داده ، که در آن 10000 عملیات تبدیل تنها یک بار در هر نمونه آموزشی اعمال می‌شوند، تبدیل می‌شوند. سپس داده های آموزشی تبدیل شده به مدل ارائه می شود. هیچ تغییر دیگری اعمال نمی شود و شتاب دهنده ها همیشه مشغول هستند. علاوه بر این، استفاده از Dataflow به شما کمک می کند تا با استفاده از یک سرویس کاملاً مدیریت شده، مقادیر زیادی از داده ها را در مقیاس پیش پردازش کنید.

  آماده سازی داده های آموزشی از قبل می تواند کارایی تمرین را بهبود بخشد. با این حال، پیاده‌سازی منطق تبدیل خارج از مدل (رویکردهایی که در گزینه A: BigQuery یا گزینه B: Dataflow توضیح داده شده است) مشکل انحراف ارائه خدمات آموزشی را حل نمی‌کند. مگر اینکه ویژگی مهندسی شده را در فروشگاه ویژگی ذخیره کنید تا هم برای آموزش و هم برای پیش‌بینی استفاده شود، منطق تبدیل باید در جایی پیاده‌سازی شود تا روی نقاط داده جدیدی که برای پیش‌بینی می‌آیند اعمال شود، زیرا رابط مدل انتظار داده‌های تغییر یافته را دارد. کتابخانه 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 به عنوان بخشی از عملکرد serving_fn به SaveDmodel وصل می شود.

در حالی که این مدل را برای پیش بینی ارائه می دهد ، رابط کاربری مدل انتظار می رود نقاط داده در قالب خام (یعنی قبل از هرگونه تحول). با این حال ، رابط داخلی مدل انتظار داده های موجود در قالب تبدیل شده را دارد.

نمودار transform_fn ، که اکنون بخشی از مدل است ، تمام منطق پیش پردازش را در نقطه داده های ورودی اعمال می کند. در عملکرد سطح نمونه در طول پیش بینی ، از ثابت های ذخیره شده (مانند μ و σ برای عادی سازی ویژگی های عددی) استفاده می کند. بنابراین ، نمودار transform_fn نقطه داده خام را به قالب تبدیل شده تبدیل می کند. قالب تبدیل شده همان چیزی است که توسط رابط داخلی مدل به منظور تولید پیش بینی انتظار می رود ، همانطور که در شکل 4 نشان داده شده است.

این مکانیسم چالش پیش پردازش را در زمینه آموزش و پرورش حل می کند ، زیرا همان منطق (اجرای) که برای تبدیل داده های آموزش و ارزیابی استفاده می شود ، برای تبدیل نقاط داده جدید در طول پیش بینی استفاده می شود.

خلاصه گزینه های پیش پردازش

در جدول زیر گزینه های پیش پردازش داده ها که این سند در مورد آن بحث کرده است خلاصه می شود. در جدول ، "N/A" مخفف "کاربردی نیست".

^* با TensorFlow ، تحولات مانند عبور ، تعبیه و رمزگذاری یک داغ باید به عنوان ستون های feature_columns Columns به صورت اعلامیه انجام شود.

بعدش چی

• برای اجرای یک خط لوله tf.Transform و اجرای آن با استفاده از DataFlow ، قسمت دوم این سری را بخوانید ، پیش پردازش داده برای ML با استفاده از TensorFlow Transform .
• تخصص Coursera را در ML با TensorFlow در Google Cloud انجام دهید.
• در مورد بهترین روشهای مهندسی ML در قوانین ML اطلاعات کسب کنید.
• برای معماری های مرجع بیشتر ، نمودارها و بهترین شیوه ها ، راه حل های ابری TFX را کشف کنید.

این سند برای اولین بار در یک سری دو قسمتی است که به بررسی موضوع مهندسی داده ها و مهندسی ویژگی برای یادگیری ماشین (ML) می پردازد ، با تمرکز بر کارهای یادگیری تحت نظارت. این بخش اول در مورد بهترین شیوه ها برای پردازش داده ها در یک خط لوله ML در Google Cloud بحث می کند. این سند بر استفاده از کتابخانه TensorFlow و منبع باز منبع باز TensorFlow ( tf.Transform ) برای تهیه داده ها ، آموزش مدل و ارائه مدل برای پیش بینی متمرکز شده است. این سند چالش های پیش پردازش داده ها را برای ML برجسته می کند ، و گزینه ها و سناریوهای انجام تبدیل داده ها در Google Cloud را بطور مؤثر توصیف می کند.

این سند فرض می کند که شما با BigQuery ، DataFlow ، Vertex AI و Tensorflow Keras API آشنا هستید.

سند دوم ، پیش پردازش داده برای ML با Google Cloud ، یک آموزش گام به گام برای نحوه اجرای یک خط لوله tf.Transform ارائه می دهد.

مقدمه

ML به شما کمک می کند تا به طور خودکار الگوهای پیچیده و بالقوه مفید را در داده ها پیدا کنید. این الگوهای در یک مدل ML متراکم می شوند که می توانند در نقاط داده جدید استفاده شوند - فرایندی به نام پیش بینی یا انجام استنتاج .

ساختن یک مدل ML یک فرآیند چند مرحله ای است. هر مرحله چالش های فنی و مفهومی خود را ارائه می دهد. این سری دو قسمتی بر کارهای یادگیری تحت نظارت و فرایند انتخاب ، تبدیل و تقویت داده های منبع برای ایجاد سیگنال های پیش بینی قدرتمند به متغیر هدف متمرکز شده است. این عملیات دانش دامنه را با تکنیک های علوم داده ترکیب می کند. این عملیات جوهر مهندسی ویژگی ها است.

اندازه مجموعه داده های آموزش برای مدل های ML در دنیای واقعی می تواند به راحتی برابر یا بیشتر از یک ترابایت (سل) باشد. بنابراین ، برای پردازش این مجموعه داده ها به صورت مؤثر و توزیع ، به چارچوب های پردازش داده در مقیاس بزرگ نیاز دارید. هنگامی که از یک مدل ML برای پیش بینی استفاده می کنید ، باید همان تحولات را که برای داده های آموزش در نقاط داده جدید استفاده کرده اید ، اعمال کنید. با استفاده از همان تحولات ، مجموعه داده های زنده را به مدل ML روشی که مدل انتظار دارد ارائه می دهید.

این سند در مورد این چالش ها برای سطوح مختلف گرانول بودن عملیات مهندسی ویژگی ها بحث می کند: تجمع سطح نمونه ، تمام گذر و پنجره. این سند همچنین گزینه ها و سناریوها را برای انجام تبدیل داده ها برای ML در Google Cloud شرح می دهد.

این سند همچنین مروری بر TensorFlow Transform ( tf.Transform ) ، کتابخانه ای برای Tensorflow که به شما امکان می دهد تغییر داده های سطح نمونه و کامل را از طریق خطوط لوله پیش پردازش داده ها تعریف کنید. این خطوط لوله با Apache Beam اجرا می شوند و مصنوعاتی را ایجاد می کنند که به شما امکان می دهد در طول پیش بینی مانند هنگام ارائه مدل ، همان تحولات را اعمال کنید.

داده های پیش پردازش برای ML

در این بخش عملیات پیش پردازش داده ها و مراحل آمادگی داده ها معرفی شده است. همچنین در مورد انواع عملیات پیش پردازش و دانه بندی آنها بحث می کند.

مهندسی داده در مقایسه با مهندسی ویژگی

پیش پردازش داده ها برای ML شامل مهندسی داده ها و مهندسی ویژگی ها است. مهندسی داده ها فرآیند تبدیل داده های خام به داده های آماده شده است. مهندسی ویژگی سپس داده های آماده شده را برای ایجاد ویژگی هایی که توسط مدل ML انتظار می رود تنظیم می کند. این اصطلاحات دارای معانی زیر است:

داده های خام (یا فقط داده ها )

داده های موجود در فرم منبع آن ، بدون هیچ گونه آماده سازی قبلی برای ML. در این زمینه ، داده ها ممکن است به شکل خام آن (در یک دریاچه داده) یا به صورت تبدیل شده (در یک انبار داده) باشد. داده های تبدیل شده که در یک انبار داده است ممکن است از فرم خام اصلی آن تبدیل شده باشد تا برای تجزیه و تحلیل استفاده شود. با این حال ، در این زمینه ، داده های خام بدان معنی است که داده ها به طور خاص برای کار ML شما تهیه نشده است. در صورت ارسال از سیستم های جریان که در نهایت مدل های ML را برای پیش بینی ها فراخوانی می کنند ، داده های خام نیز در نظر گرفته می شود.

داده های آماده شده

مجموعه داده های موجود در فرم آماده برای کار ML شما: منابع داده تجزیه شده ، به هم می پیوندند و به صورت جدولی قرار می گیرند. داده های آماده شده جمع می شوند و به دانه بندی مناسب خلاصه می شوند - برای مثال ، هر ردیف در مجموعه داده ها یک مشتری منحصر به فرد را نشان می دهد و هر ستون مانند کل هزینه شده در شش هفته گذشته ، اطلاعات خلاصه ای را برای مشتری نشان می دهد. در یک جدول داده های آماده ، ستون های بی ربط کاهش یافته و سوابق نامعتبر فیلتر شده اند. برای کارهای یادگیری تحت نظارت ، ویژگی هدف موجود است.

ویژگی های مهندسی شده

مجموعه داده با ویژگی های تنظیم شده که توسط مدل انتظار می رود-یعنی ویژگی هایی که با انجام برخی عملیات خاص ML بر روی ستون های موجود در مجموعه داده های آماده شده و ایجاد ویژگی های جدید برای مدل شما در طول آموزش و پیش بینی ، همانطور که بعداً توضیح داده شده است ، ایجاد می شود. در عملیات پیش پردازش . نمونه هایی از این عملیات شامل مقیاس بندی ستون های عددی به مقدار بین 0 تا 1 ، مقادیر قطع و ویژگی های طبقه بندی شده یک داغ است .

نمودار زیر ، شکل 1 ، مراحل مربوط به تهیه داده های از پیش پردازش شده را نشان می دهد:

در عمل ، داده های همان منبع اغلب در مراحل مختلف آمادگی قرار دارند. به عنوان مثال ، یک زمینه از یک جدول در انبار داده شما ممکن است مستقیماً به عنوان یک ویژگی مهندسی شده استفاده شود. در عین حال ، یک قسمت دیگر در همان جدول ممکن است قبل از اینکه به یک ویژگی مهندسی تبدیل شود ، نیاز به تحولات داشته باشد. به طور مشابه ، مهندسی داده ها و عملیات مهندسی ویژگی ممکن است در همان مرحله پیش پردازش داده ها ترکیب شوند.

عملیات پیش پردازش

پیش پردازش داده ها شامل چندین عملیات است. هر عملیاتی برای کمک به ML در ساخت مدل های پیش بینی بهتر طراحی شده است. جزئیات این عملیات پیش پردازش خارج از محدوده این سند است ، اما برخی از عملیات به طور خلاصه در این بخش شرح داده شده است.

برای داده های ساخت یافته ، عملیات پیش پردازش داده ها شامل موارد زیر است:

• پاکسازی داده ها: حذف یا تصحیح سوابق که مقادیر خراب یا نامعتبر را از داده های خام و حذف سوابق که تعداد زیادی ستون را از دست نمی دهند ، حذف می کنند.
• انتخاب و تقسیم بندی موارد: انتخاب نقاط داده از مجموعه داده ورودی برای ایجاد آموزش ، ارزیابی (اعتبار سنجی) و مجموعه های آزمون . این فرآیند شامل تکنیک هایی برای نمونه گیری تصادفی قابل تکرار ، نمونه برداری از کلاس های اقلیت و پارتیشن بندی طبقه بندی شده است.
• تنظیم ویژگی ها: بهبود کیفیت یک ویژگی برای ML ، که شامل مقیاس بندی و عادی سازی مقادیر عددی ، مقادیر از دست رفته ، قطع کردن دور و تنظیم مقادیر توزیع شده است.
• تحول ویژگی: تبدیل یک ویژگی عددی به یک ویژگی طبقه بندی (از طریق سطل سازی ) و تبدیل ویژگی های طبقه بندی شده به یک نمایش عددی (از طریق رمزگذاری یک داغ ، یادگیری با شمارش ، تعبیه ویژگی های پراکنده و غیره). برخی از مدل ها فقط با ویژگی های عددی یا طبقه ای کار می کنند ، در حالی که برخی دیگر می توانند ویژگی های نوع مختلط را کنترل کنند. حتی هنگامی که مدل ها هر دو نوع را اداره می کنند ، می توانند از بازنمودهای مختلف (عددی و طبقه بندی) از همان ویژگی بهره مند شوند.
• استخراج ویژگی ها: کاهش تعداد ویژگی ها با ایجاد ابعاد پایین تر ، نمایش داده های قدرتمندتر با استفاده از تکنیک هایی مانند PCA ، استخراج جاسازی و هشویی .
• انتخاب ویژگی: انتخاب زیر مجموعه ای از ویژگی های ورودی برای آموزش مدل و نادیده گرفتن موارد بی ربط یا اضافی ، با استفاده از روش های فیلتر یا بسته بندی . انتخاب ویژگی ها همچنین می تواند شامل رها کردن ویژگی ها باشد اگر ویژگی ها تعداد زیادی از مقادیر را از دست ندهند.
• ساخت ویژگی ها: ایجاد ویژگی های جدید با استفاده از تکنیک های معمولی ، مانند گسترش چند جمله ای (با استفاده از توابع ریاضی یک متغیره) یا عبور از ویژگی (برای ضبط تعامل ویژگی). همچنین می توان با استفاده از منطق کسب و کار از دامنه مورد استفاده ML ، ویژگی ها ساخته شد.

هنگامی که شما با داده های بدون ساختار (به عنوان مثال ، تصاویر ، صدا یا اسناد متنی) کار می کنید ، یادگیری عمیق جایگزین مهندسی ویژگی های مبتنی بر دامنه دانش با تاشو آن در معماری مدل می شود. یک لایه حلقوی یک پیش پردازنده ویژگی اتوماتیک است. ساخت معماری مدل مناسب به دانش تجربی از داده ها نیاز دارد. علاوه بر این ، مقداری از پیش پردازش لازم است ، مانند موارد زیر:

• برای اسناد متنی: STEMMING و LEMMATISTION ، محاسبه TF-IDF و استخراج N-GRAM ، تعبیه.
• برای تصاویر: بریده ، تغییر اندازه ، کشت ، تار گاوسی و فیلترهای قناری.
• برای همه نوع داده ها (از جمله متن و تصاویر): یادگیری انتقال ، که لایه های همه اما لاستیک مدل کاملاً آموزش دیده را به عنوان یک مرحله مهندسی ویژگی درمان می کند.

گرانوری پیش پردازش

در این بخش در مورد دانه بندی انواع تحولات داده ها بحث شده است. این نشان می دهد که چرا این دیدگاه هنگام تهیه نقاط داده جدید برای پیش بینی ها با استفاده از تحولاتی که بر روی داده های آموزش اعمال می شود ، بسیار مهم است.

عملیات پیش پردازش و تحول را می توان به شرح زیر طبقه بندی کرد ، بر اساس دانه بندی عملیاتی:

• تحولات سطح نمونه در طول آموزش و پیش بینی . اینها تحولات ساده هستند ، جایی که فقط مقادیر از همان نمونه برای تحول لازم است. به عنوان مثال ، تحولات سطح نمونه ممکن است شامل قطع مقدار یک ویژگی در آستانه ، گسترش چند جمله ای ویژگی دیگر ، ضرب دو ویژگی یا مقایسه دو ویژگی برای ایجاد یک پرچم بولی باشد.

  این تحولات باید در طول آموزش و پیش بینی به طور یکسان اعمال شود ، زیرا این مدل بر روی ویژگی های تبدیل شده آموزش داده می شود ، نه بر روی مقادیر ورودی خام. اگر داده ها به طور یکسان تبدیل نشوند ، مدل ضعیف رفتار می کند زیرا با داده هایی ارائه می شود که دارای توزیع مقادیری است که با آنها آموزش داده نشده است. برای اطلاعات بیشتر ، به بحث در مورد آموزش SKEW در بخش چالش های پیش پردازش مراجعه کنید.

• تحولات تمام عیار در طول آموزش ، اما تحولات سطح نمونه در طول پیش بینی . در این سناریو ، تحولات بسیار بیان شده است ، زیرا آنها از برخی از آمار پیش ساخته برای انجام تحول استفاده می کنند. در طول آموزش ، شما کل داده های آموزش را برای محاسبه مقادیر مانند حداقل ، حداکثر ، میانگین و واریانس برای تبدیل داده های آموزش ، داده های ارزیابی و داده های جدید در زمان پیش بینی ، تجزیه و تحلیل می کنید.

  به عنوان مثال ، برای عادی سازی یک ویژگی عددی برای آموزش ، شما میانگین آن (μ) و انحراف استاندارد آن (σ) را در کل داده های آموزش محاسبه می کنید. این محاسبه یک عمل کامل (یا تجزیه و تحلیل ) نامیده می شود. هنگامی که شما به مدل برای پیش بینی خدمت می کنید ، مقدار یک نقطه داده جدید برای جلوگیری از آموزش و پرورش ، عادی می شود. بنابراین ، مقادیر μ و σ که در طول آموزش محاسبه می شوند ، برای تنظیم مقدار ویژگی استفاده می شوند ، که عملکرد ساده در سطح نمونه زیر است:

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

  تحولات تمام گذر شامل موارد زیر است:

  • Minmax Scaling ویژگی های عددی با استفاده از Min و Max محاسبه شده از مجموعه داده های آموزش.
  • مقیاس بندی استاندارد (عادی سازی نمره Z) ویژگی های عددی با استفاده از μ و σ محاسبه شده در مجموعه داده های آموزش.
  • با استفاده از مقدار.
  • مقادیر گمشده با استفاده از مدیان (ویژگی های عددی) یا حالت (ویژگی های طبقه بندی).
  • تبدیل رشته ها (مقادیر اسمی) به اعداد صحیح (شاخص ها) با استخراج تمام مقادیر مجزا (واژگان) یک ویژگی طبقه ای ورودی.
  • شمارش وقوع یک اصطلاح (مقدار ویژگی) در کلیه اسناد (نمونه ها) برای محاسبه برای 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

در این بخش به بحث در مورد اجزای اصلی یک خط لوله انتهایی معمولی برای آموزش و خدمت به مدل های ML Tensorflow در Google Cloud با استفاده از خدمات مدیریت شده می پردازیم. همچنین بحث می کند که در کجا می توانید دسته های مختلفی از عملیات پیش پردازش داده ها و چالش های مشترکی را که ممکن است هنگام اجرای چنین تحولات با آن روبرو شوید ، پیاده سازی کنید. بخش How tf.Transform Works نشان می دهد که چگونه کتابخانه TensorFlow Transform به رسیدگی به این چالش ها کمک می کند.

معماری سطح بالا

نمودار زیر ، شکل 2 ، معماری سطح بالا از یک خط لوله معمولی ML را برای آموزش و ارائه مدل های Tensorflow نشان می دهد. برچسب های A ، B و C در نمودار به مکان های مختلف خط لوله که در آن پیش پردازش داده می تواند انجام شود ، اشاره دارد. جزئیات مربوط به این مراحل در بخش زیر ارائه شده است.

خط لوله شامل مراحل زیر است:

1. پس از وارد کردن داده های خام ، داده های جدولی در BigQuery ذخیره می شوند و داده های دیگری مانند تصاویر ، صوتی و فیلم در ذخیره سازی ابر ذخیره می شوند. بخش دوم این سری از داده های جدولی ذخیره شده در BigQuery به عنوان نمونه استفاده می کند.
2. مهندسی داده ها (آماده سازی) و مهندسی ویژگی در مقیاس با استفاده از DataFlow اجرا می شوند. این اعدام مجموعه های آموزش ، ارزیابی و آزمایشی آماده ML را که در ذخیره سازی ابری ذخیره می شوند ، تولید می کند. در حالت ایده آل ، این مجموعه داده ها به عنوان فایلهای Tfrecord ذخیره می شوند ، که فرمت بهینه شده برای محاسبات TensorFlow است.
3. یک بسته مربی مدل TensorFlow به آموزش Vertex AI ارسال می شود که از داده های از پیش پردازش شده از مراحل قبلی برای آموزش مدل استفاده می کند. خروجی این مرحله یک Tensorflow SaveDmodel آموزش دیده است که به ذخیره ابری صادر می شود.
4. مدل TensorFlow آموزش دیده به عنوان خدماتی که دارای API REST است ، برای پیش بینی AI Vertex مستقر شده است تا بتواند برای پیش بینی های آنلاین مورد استفاده قرار گیرد. از همین مدل نیز می توان برای مشاغل پیش بینی دسته ای استفاده کرد.
5. پس از استقرار مدل به عنوان API REST ، برنامه های مشتری و سیستم های داخلی می توانند با ارسال درخواست با برخی از نقاط داده و دریافت پاسخ از مدل با پیش بینی ، API را فراخوانی کنند.
6. برای ارکستر و خودکار کردن این خط لوله ، می توانید از خطوط لوله AI Vertex به عنوان یک برنامه ریز برای استناد به تهیه داده ها ، آموزش مدل و مراحل استقرار مدل استفاده کنید.

همچنین می توانید از فروشگاه ویژگی Vertex AI برای ذخیره ویژگی های ورودی برای پیش بینی استفاده کنید. به عنوان مثال ، شما می توانید به طور دوره ای از جدیدترین داده های خام ویژگی های مهندسی شده ایجاد کرده و آنها را در فروشگاه ویژگی Vertex AI ذخیره کنید. برنامه های مشتری ویژگی های ورودی مورد نیاز را از فروشگاه ویژگی Vertex AI واگذار کرده و آنها را برای دریافت پیش بینی به مدل ارسال می کنند.

پیش پردازش را از کجا انجام دهید

در شکل 2 ، برچسب های A ، B و C نشان می دهد که عملیات پیش پردازش داده می تواند در BigQuery ، DataFlow یا Tensorflow انجام شود. بخش های زیر نحوه عملکرد هر یک از این گزینه ها را شرح می دهد.

گزینه A: BigQuery

به طور معمول ، منطق در BigQuery برای عملیات زیر اجرا می شود:

• نمونه برداری: انتخاب تصادفی زیر مجموعه از داده ها.
• فیلتر: حذف نمونه های نامربوط یا نامعتبر.
• پارتیشن بندی: تقسیم داده ها برای تولید مجموعه های آموزش ، ارزیابی و آزمون.

اسکریپت های BigQuery SQL می توانند به عنوان یک پرس و جو منبع برای خط لوله پردازش DataFlow ، که مرحله پردازش داده ها در شکل 2 است استفاده شود. به عنوان مثال ، اگر یک سیستم در کانادا استفاده شود ، و انبار داده دارای معاملات از سراسر جهان است. دریافت داده های آموزش فقط کانادا به بهترین وجه در BigQuery انجام می شود. مهندسی ویژگی در BigQuery ساده و مقیاس پذیر است و از اجرای تجمع های سطح و تاریخی از ویژگی های تحول های خاص پشتیبانی می کند.

با این حال ، ما توصیه می کنیم فقط در صورت استفاده از مدل خود برای پیش بینی دسته ای (امتیاز دهی) از BigQuery برای مهندسی ویژگی استفاده کنید ، یا اگر این ویژگی ها در BigQuery قرار دارند ، اما در فروشگاه ویژگی Vertex AI ذخیره می شوند که در طی پیش بینی آنلاین استفاده می شود. اگر قصد دارید مدل را برای پیش بینی های آنلاین مستقر کنید ، و اگر ویژگی مهندسی شده را در یک فروشگاه ویژگی آنلاین ندارید ، باید عملیات پیش پردازش SQL را تکرار کنید تا نقاط داده خام را که سایر سیستم ها تولید می کنند ، تغییر دهید. به عبارت دیگر ، شما باید دو بار منطق را پیاده سازی کنید: یک بار در SQL برای پردازش داده های آموزش در BigQuery و بار دوم در منطق برنامه که مدل را برای پیش بینی نقاط داده آنلاین برای پیش بینی مصرف می کند.

به عنوان مثال ، اگر برنامه مشتری شما در جاوا نوشته شده است ، باید منطق را در جاوا دوباره تکرار کنید. این می تواند خطاهایی را به دلیل اختلافات اجرای ، به وجود آورد ، همانطور که در بخش آموزش و پرورش SKEW از چالش های پیش پردازش بعداً در این سند شرح داده شده است. همچنین برای حفظ دو پیاده سازی متفاوت ، سربار اضافی است. هر زمان که منطق را در SQL تغییر دهید تا داده های آموزشی را از قبل پردازش کنید ، باید اجرای جاوا را بر این اساس تغییر دهید تا داده های پیش پردازش را در زمان خدمت انجام دهید.

اگر فقط از مدل خود برای پیش بینی دسته ای استفاده می کنید (به عنوان مثال ، با استفاده از پیش بینی دسته ای Vertex AI) ، و اگر داده های شما برای امتیاز دهی از BigQuery تهیه شده است ، می توانید این عملیات پیش پردازش را به عنوان بخشی از اسکریپت BigQuery SQL پیاده سازی کنید. در این حالت ، شما می توانید از همان اسکریپت پیش پردازش SQL استفاده کنید تا هم آموزش و هم برای به ثمر رساندن داده ها را تهیه کنید.

تحولات مطلق کامل برای اجرای در BigQuery مناسب نیست. اگر از BigQuery برای تحولات تمام عیار استفاده می کنید ، به جداول کمکی برای ذخیره مقادیر مورد نیاز تحولات حالت ، مانند میانگین و واریانس برای مقیاس ویژگی های عددی نیاز دارید. علاوه بر این ، اجرای تحولات تمام عیار با استفاده از SQL در BigQuery باعث افزایش پیچیدگی در اسکریپت های SQL می شود و وابستگی پیچیده ای بین آموزش و به ثمر رساندن اسکریپت های SQL ایجاد می کند.

گزینه B: Dataflow

همانطور که در شکل 2 نشان داده شده است ، می توانید عملیات پیش پردازش محاسباتی گران قیمت را در Apache Beam پیاده سازی کرده و آنها را با استفاده از DataFlow در مقیاس اجرا کنید. DataFlow یک سرویس خودکار سازی کاملاً مدیریت شده برای پردازش داده های دسته ای و جریان است. هنگامی که از DataFlow استفاده می کنید ، می توانید برخلاف BigQuery ، از کتابخانه های تخصصی خارجی برای پردازش داده ها نیز استفاده کنید.

DataFlow می تواند تحولات سطح نمونه و تحولات ویژگی تجمیع تاریخی و در زمان واقعی را انجام دهد. به طور خاص ، اگر مدل های ML شما از ویژگی های ورودی مانند total_number_of_clicks_last_90sec انتظار داشته باشند ، توابع پنجره های پرتوی Apache می توانند این ویژگی ها را بر اساس جمع کردن مقادیر ویندوزهای زمان داده های زمان واقعی (جریان) داده ها محاسبه کنند (به عنوان مثال ، روی رویدادها کلیک کنید). در بحث قبلی در مورد دانه بندی تحولات ، این به "تجمع تاریخی در طول آموزش ، اما تجمع در زمان واقعی در طول پیش بینی" گفته شد.

نمودار زیر ، شکل 3 ، نقش جریان داده ها را در پردازش داده های جریان برای پیش بینی های نزدیک به زمان واقعی نشان می دهد.

همانطور که در شکل 3 نشان داده شده است ، در حین پردازش ، وقایع به نام نقاط داده به Pub/Sub منتقل می شوند. DataFlow این نقاط داده را مصرف می کند ، ویژگی های آن را بر اساس مصالح با گذشت زمان محاسبه می کند ، و سپس API مدل ML مستقر را برای پیش بینی می نامد. پیش بینی ها سپس به یک میخانه/زیر برون مرزی ارسال می شوند. از Pub/Sub ، پیش بینی ها می توانند توسط سیستم های پایین دست مانند نظارت یا کنترل مصرف شوند ، یا می توان آنها را به عقب (به عنوان مثال ، به عنوان اعلان ها) به مشتری درخواست کننده اصلی سوق داد. پیش بینی ها همچنین می توانند در یک فروشگاه داده با تأخیر کم مانند Cloud BigTable برای واکشی در زمان واقعی ذخیره شوند. Cloud Bigtable همچنین می تواند برای جمع آوری و ذخیره این تجمع های زمان واقعی استفاده شود تا در صورت نیاز برای پیش بینی ، آنها را جستجو کنید.

از همان اجرای پرتو Apache می توان برای داده های آموزشی پردازش دسته ای که از یک داده آفلاین مانند BigQuery و داده های زمان واقعی پردازش برای ارائه پیش بینی های آنلاین استفاده می شود ، استفاده کرد.

در سایر معماری های معمولی ، مانند معماری نشان داده شده در شکل 2 ، برنامه مشتری مستقیماً API مدل مستقر را برای پیش بینی های آنلاین فراخوانی می کند. در این حالت ، اگر عملیات پیش پردازش در DataFlow برای تهیه داده های آموزشی انجام شود ، عملیات برای داده های پیش بینی که مستقیماً به مدل می رود ، اعمال نمی شود. بنابراین ، تحولات مانند این باید در هنگام خدمت برای پیش بینی های آنلاین در مدل ادغام شوند.

با محاسبه آمار مورد نیاز در مقیاس می توان از DataFlow برای انجام تحول کامل عبور کرد. با این حال ، این آمار باید در جایی ذخیره شود تا در طول پیش بینی برای تبدیل نقاط داده پیش بینی استفاده شود. با استفاده از کتابخانه TensorFlow Transform ( tf.Transform ) ، می توانید به جای ذخیره آنها در جای دیگر ، مستقیماً این آمار را در مدل جاسازی کنید. این رویکرد بعداً در نحوه عملکرد tf.transform توضیح داده شده است.

گزینه C: Tensorflow

همانطور که در شکل 2 نشان داده شده است ، می توانید عملیات پیش پردازش و تحول داده ها را در خود مدل Tensorflow پیاده سازی کنید. همانطور که در شکل نشان داده شده است ، پیش پردازش که شما برای آموزش مدل Tensorflow پیاده سازی می کنید ، هنگامی که مدل صادر می شود و برای پیش بینی مستقر می شود ، به بخشی جدایی ناپذیر از مدل تبدیل می شود. تحولات در مدل TensorFlow می تواند به یکی از روشهای زیر انجام شود:

• اجرای تمام منطق تحول در سطح نمونه در عملکرد input_fn و در عملکرد serving_fn . عملکرد input_fn یک مجموعه داده را با استفاده از API tf.data.Dataset برای آموزش یک مدل آماده می کند. عملکرد serving_fn داده ها را برای پیش بینی ها دریافت و آماده می کند.
• قرار دادن کد تحول به طور مستقیم در مدل Tensorflow خود با استفاده از لایه های پیش پردازش KERA یا ایجاد لایه های سفارشی .

کد منطق تحول در تابع serving_fn رابط خدمت SaveDmodel شما را برای پیش بینی آنلاین تعریف می کند. اگر همان تحولات را که برای تهیه داده های آموزش در کد منطق تحول از تابع serving_fn استفاده شده است ، پیاده سازی می کنید ، تضمین می کند که همان تحولات در نقاط داده پیش بینی جدید هنگام ارائه آنها اعمال می شود.

با این حال ، از آنجا که مدل TensorFlow هر نقطه داده را به طور مستقل یا در یک دسته کوچک پردازش می کند ، شما نمی توانید تجمع را از تمام نقاط داده محاسبه کنید. در نتیجه ، تحولات تمام عیار در مدل Tensorflow شما قابل اجرا نیست.

چالش های پیش پردازش

موارد زیر چالش های اصلی اجرای پیش پردازش داده ها است:

• آموزش و پرورش . SKEW آموزش و پرورش به تفاوت بین اثربخشی (عملکرد پیش بینی) در طول آموزش و در حین خدمت اشاره دارد. این شکاف می تواند به دلیل اختلاف بین نحوه کنترل داده ها در آموزش و خطوط لوله سرویس ایجاد شود. به عنوان مثال ، اگر مدل شما بر روی یک ویژگی تبدیل شده لگاریتمی آموزش دیده باشد ، اما در هنگام خدمت با ویژگی خام ارائه شده است ، ممکن است خروجی پیش بینی دقیق نباشد.

  اگر تحولات به بخشی از خود مدل تبدیل شوند ، می توان تحولات سطح نمونه را انجام داد ، همانطور که در ابتدا در گزینه C توضیح داده شد: Tensorflow . در این حالت ، مدل رابط خدمتکار (عملکرد serving_fn ) انتظار داده های خام را دارد ، در حالی که مدل داخلی این داده ها را قبل از محاسبه خروجی تبدیل می کند. تحولات همان مواردی است که در نقاط داده های آموزش خام و پیش بینی داده شده است.

• تحولات تمام عیار . شما نمی توانید تحولات تمام عیار مانند مقیاس بندی و تحولات عادی سازی را در مدل Tensorflow خود اجرا کنید. 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.

معماری سطح بالا

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 .