ML için veri ön işleme: seçenekler ve öneriler

Bu belge, denetimli öğrenme görevlerine odaklanarak makine öğrenimi (ML) için veri mühendisliği ve özellik mühendisliği konusunu inceleyen iki bölümlü bir serinin ilkidir. Bu ilk bölümde, Google Cloud'daki makine öğrenimi ardışık düzeninde verilerin ön işlenmesine yönelik en iyi uygulamalar anlatılmaktadır. Belge, verileri hazırlamak, modeli eğitmek ve modele tahmin amaçlı hizmet vermek için TensorFlow ve açık kaynaklı TensorFlow Transform ( tf.Transform ) kitaplığını kullanmaya odaklanıyor. Bu belge, makine öğrenimi için verileri ön işlemenin zorluklarını vurguluyor ve Google Cloud'da veri dönüşümünü etkili bir şekilde gerçekleştirmeye yönelik seçenekler ve senaryoları açıklıyor.

Bu belgede BigQuery , Dataflow , Vertex AI ve TensorFlow Keras API'sine aşina olduğunuz varsayılmaktadır.

İkinci belge olan Google Cloud ile ML için Veri ön işleme , tf.Transform ardışık düzeninin nasıl uygulanacağına ilişkin adım adım bir eğitim sağlar.

giriiş

ML, verilerdeki karmaşık ve potansiyel olarak yararlı kalıpları otomatik olarak bulmanıza yardımcı olur. Bu modeller, daha sonra yeni veri noktalarında kullanılabilen bir makine öğrenimi modelinde yoğunlaştırılır; bu sürece tahmin yapma veya çıkarım yapma adı verilir.

ML modeli oluşturmak çok adımlı bir süreçtir. Her adım kendi teknik ve kavramsal zorluklarını sunar. Bu iki bölümlü seri, denetimli öğrenme görevlerine ve hedef değişkene yönelik güçlü tahmin sinyalleri oluşturmak için kaynak verileri seçme, dönüştürme ve artırma sürecine odaklanır. Bu işlemler, alan bilgisini veri bilimi teknikleriyle birleştirir. Operasyonlar özellik mühendisliğinin özüdür.

Gerçek dünyadaki ML modelleri için eğitim veri kümelerinin boyutu kolaylıkla bir terabayta (TB) eşit veya daha büyük olabilir. Dolayısıyla bu veri kümelerini verimli ve dağıtık bir şekilde işleyebilmek için büyük ölçekli veri işleme çerçevelerine ihtiyacınız var. Tahminlerde bulunmak için bir ML modeli kullandığınızda, eğitim verileri için kullandığınız dönüşümlerin aynısını yeni veri noktalarına da uygulamanız gerekir. Aynı dönüşümleri uygulayarak canlı veri kümesini ML modeline modelin beklediği şekilde sunarsınız.

Bu belgede, özellik mühendisliği işlemlerinin farklı ayrıntı düzeylerine yönelik bu zorluklar ele alınmaktadır: örnek düzeyinde, tam geçişli ve zaman aralığı toplamaları. Bu belgede ayrıca Google Cloud'da makine öğrenimi için veri dönüşümü gerçekleştirme seçenekleri ve senaryoları da açıklanmaktadır.

Bu belge ayrıca, veri ön işleme hatları aracılığıyla hem örnek düzeyinde hem de tam geçişli veri dönüşümünü tanımlamanıza olanak tanıyan bir TensorFlow kitaplığı olan TensorFlow Transform'a ( tf.Transform ) genel bir bakış sağlar. Bu işlem hatları Apache Beam ile yürütülür ve model sunulurken olduğu gibi tahmin sırasında da aynı dönüşümleri uygulamanıza olanak tanıyan yapılar oluştururlar.

Makine öğrenimi için veriler ön işleme

Bu bölümde veri ön işleme işlemleri ve veri hazırlığının aşamaları tanıtılmaktadır. Ayrıca ön işleme operasyonlarının türleri ve bunların ayrıntı düzeyi de tartışılmaktadır.

Özellik mühendisliğiyle karşılaştırıldığında veri mühendisliği

Verilerin makine öğrenimi için ön işlenmesi, hem veri mühendisliğini hem de özellik mühendisliğini içerir. Veri mühendisliği ham verileri hazırlanmış verilere dönüştürme işlemidir. Özellik mühendisliği daha sonra, ML modelinin beklediği özellikleri oluşturmak için hazırlanan verileri ayarlar. Bu terimler aşağıdaki anlamlara sahiptir:

Ham veriler (veya yalnızca veriler )

Veriler, makine öğrenimi için önceden herhangi bir hazırlık yapılmaksızın, kaynak formundadır. Bu bağlamda veri ham haliyle (veri gölünde) veya dönüştürülmüş biçimde (veri ambarında) olabilir. Veri ambarındaki dönüştürülmüş veriler, analiz için kullanılmak üzere orijinal ham formundan dönüştürülmüş olabilir. Ancak bu bağlamda ham veriler , verilerin makine öğrenimi göreviniz için özel olarak hazırlanmadığı anlamına gelir. Veriler ayrıca tahminler için makine öğrenimi modellerini çağıran akış sistemlerinden gönderilirse ham veri olarak kabul edilir.

Hazırlanan veriler

Formdaki veri kümesi makine öğrenimi göreviniz için hazır: veri kaynakları ayrıştırıldı, birleştirildi ve tablo biçiminde bir forma yerleştirildi. Hazırlanan veriler toplanır ve doğru ayrıntı düzeyine göre özetlenir; örneğin, veri kümesindeki her satır benzersiz bir müşteriyi temsil eder ve her sütun, son altı haftadaki toplam harcama gibi müşteriye ilişkin özet bilgileri temsil eder. Hazırlanan bir veri tablosunda ilgisiz sütunlar çıkarılmış ve geçersiz kayıtlar filtrelenmiştir. Denetimli öğrenme görevleri için hedef özelliği mevcuttur.

Mühendislik özellikleri

Model tarafından beklenen ayarlanmış özelliklere sahip veri kümesi (yani, daha sonra açıklanacağı gibi, hazırlanan veri kümesindeki sütunlarda ML'ye özgü belirli işlemlerin gerçekleştirilmesi ve eğitim ve tahmin sırasında modeliniz için yeni özellikler oluşturulmasıyla oluşturulan özellikler). Ön işleme işlemlerinde . Bu işlemlere örnek olarak sayısal sütunların 0 ile 1 arasında bir değere ölçeklendirilmesi, değerlerin kırpılması ve tek-sıcak kodlama kategorik özellikleri verilebilir.

Aşağıdaki diyagram, şekil 1, önceden işlenmiş verilerin hazırlanmasında yer alan adımları göstermektedir:

Uygulamada, aynı kaynaktan gelen veriler genellikle farklı hazırlık aşamalarındadır. Örneğin, veri ambarınızdaki bir tablodaki bir alan, doğrudan tasarlanmış bir özellik olarak kullanılabilir. Aynı zamanda, aynı tablodaki başka bir alanın mühendislik özelliğine dönüşmeden önce dönüşümlerden geçmesi gerekebilir. Benzer şekilde, veri mühendisliği ve özellik mühendisliği işlemleri aynı veri ön işleme adımında birleştirilebilir.

Ön işleme işlemleri

Veri ön işleme birkaç işlemi içerir. Her işlem, ML'nin daha iyi tahmin modelleri oluşturmasına yardımcı olmak için tasarlanmıştır. Bu ön işleme işlemlerinin ayrıntıları bu belgenin kapsamı dışındadır ancak bazı işlemler bu bölümde kısaca açıklanmaktadır.

Yapılandırılmış veriler için veri ön işleme işlemleri aşağıdakileri içerir:

• Veri temizleme: Ham verilerden bozuk veya geçersiz değerlere sahip kayıtların kaldırılması veya düzeltilmesi ve çok sayıda sütunu eksik olan kayıtların kaldırılması.
• Örnek seçimi ve bölümleme: eğitim, değerlendirme (doğrulama) ve test kümeleri oluşturmak için giriş veri kümesinden veri noktalarının seçilmesi. Bu süreç, tekrarlanabilir rastgele örnekleme, azınlık sınıfları aşırı örnekleme ve katmanlı bölümleme tekniklerini içerir.
• Özellik ayarlama: sayısal değerlerin ölçeklendirilmesi ve normalleştirilmesi, eksik değerlerin atanması, aykırı değerlerin kırpılması ve çarpık dağılımlara sahip değerlerin ayarlanması dahil olmak üzere makine öğrenimi için bir özelliğin kalitesinin iyileştirilmesi.
• Özellik dönüşümü: sayısal bir özelliğin kategorik bir özelliğe dönüştürülmesi ( gruplandırma yoluyla) ve kategorik özelliklerin sayısal bir temsile dönüştürülmesi (tek sıcak kodlama, sayımlarla öğrenme , seyrek özellik yerleştirmeler vb. yoluyla). Bazı modeller yalnızca sayısal veya kategorik özelliklerle çalışırken diğerleri karışık türdeki özellikleri işleyebilir. Modeller her iki türü de ele aldığında bile aynı özelliğin farklı temsillerinden (sayısal ve kategorik) yararlanabilirler.
• Özellik çıkarma: PCA , yerleştirme çıkarma ve karma oluşturma gibi teknikleri kullanarak daha düşük boyutlu, daha güçlü veri temsilleri oluşturarak özelliklerin sayısını azaltır.
• Özellik seçimi: modeli eğitmek için giriş özelliklerinin bir alt kümesinin seçilmesi ve filtre veya sarma yöntemleri kullanılarak ilgisiz veya gereksiz olanların göz ardı edilmesi. Özellik seçimi, eğer özelliklerde çok sayıda değer eksikse, basitçe özelliklerin bırakılmasını da içerebilir.
• Özellik oluşturma: polinom genişletme (tek değişkenli matematiksel fonksiyonlar kullanarak) veya özellik geçişi (özellik etkileşimlerini yakalamak için) gibi tipik teknikleri kullanarak yeni özellikler oluşturma. Özellikler ayrıca ML kullanım senaryosunun etki alanından iş mantığı kullanılarak da oluşturulabilir.

Yapılandırılmamış verilerle (örneğin görüntüler, ses veya metin belgeleri) çalışırken, derin öğrenme, onu model mimarisine katlayarak etki alanı bilgisine dayalı özellik mühendisliğinin yerini alır. Evrişimli katman, otomatik bir özellik ön işlemcisidir. Doğru model mimarisini oluşturmak, verilere ilişkin bazı deneysel bilgileri gerektirir. Ek olarak, aşağıdakiler gibi bir miktar ön işleme de ihtiyaç vardır:

• Metin belgeleri için: kök çıkarma ve lemmatizasyon , TF-IDF hesaplaması ve n-gram çıkarma, yerleştirme araması.
• Görüntüler için: kırpma, yeniden boyutlandırma, kırpma, Gauss bulanıklığı ve kanarya filtreleri.
• Tüm veri türleri için (metin ve resimler dahil): tam olarak eğitilmiş modelin son hariç tüm katmanlarını bir özellik mühendisliği adımı olarak ele alan transfer öğrenimi .

Ön işleme ayrıntı düzeyi

Bu bölümde veri dönüştürme türlerinin ayrıntı düzeyi ele alınmaktadır. Eğitim verilerine uygulanan dönüşümleri kullanarak tahminler için yeni veri noktaları hazırlarken bu perspektifin neden kritik olduğunu gösterir.

Ön işleme ve dönüştürme işlemleri, işlem ayrıntı düzeyine göre aşağıdaki şekilde kategorize edilebilir:

• Eğitim ve tahmin sırasında örnek düzeyinde dönüşümler . Bunlar, dönüşüm için yalnızca aynı örnekteki değerlerin gerekli olduğu basit dönüşümlerdir. Örneğin, örnek düzeyindeki dönüşümler, bir özelliğin değerinin belirli bir eşiğe kırpılmasını, başka bir özelliğin polinom olarak genişletilmesini, iki özelliğin çarpılmasını veya bir Boole bayrağı oluşturmak için iki özelliğin karşılaştırılmasını içerebilir.

  Bu dönüşümler, eğitim ve tahmin sırasında aynı şekilde uygulanmalıdır çünkü model, ham girdi değerlerine göre değil, dönüştürülen özelliklere göre eğitilecektir. Veriler aynı şekilde dönüştürülmezse model, eğitilmediği bir değer dağılımına sahip verilerle sunulduğu için kötü davranır. Daha fazla bilgi için Ön İşleme zorlukları bölümündeki eğitim-sunum çarpıklığı tartışmasına bakın.

• Eğitim sırasında tam geçişli dönüşümler, ancak tahmin sırasında örnek düzeyinde dönüşümler . Bu senaryoda dönüşümler durum bilgilidir çünkü dönüşümü gerçekleştirmek için önceden hesaplanmış bazı istatistikler kullanırlar. Eğitim sırasında, eğitim verilerini, değerlendirme verilerini ve tahmin zamanında yeni verileri dönüştürmek için minimum, maksimum, ortalama ve varyans gibi miktarları hesaplamak üzere eğitim verilerinin tamamını analiz edersiniz.

  Örneğin, eğitim için sayısal bir özelliği normalleştirmek için, tüm eğitim verileri genelinde bunun ortalamasını (μ) ve standart sapmasını (σ) hesaplarsınız. Bu hesaplamaya tam geçiş (veya analiz ) işlemi denir. Modeli tahmin için sunduğunuzda, eğitim sunumunda çarpıklığı önlemek için yeni bir veri noktasının değeri normalleştirilir. Bu nedenle, eğitim sırasında hesaplanan μ ve σ değerleri, aşağıdaki basit örnek düzeyinde işlem olan özellik değerini ayarlamak için kullanılır:

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

  Tam geçişli dönüşümler aşağıdakileri içerir:

  • MinMax, eğitim veri kümesinden hesaplanan minimum ve maksimum değerleri kullanarak sayısal özellikleri ölçeklendirir.
  • Eğitim veri kümesinde hesaplanan μ ve σ kullanılarak standart ölçeklendirme (z-puanı normalleştirme) sayısal özellikleri.
  • Nicelikler kullanılarak sayısal özelliklerin gruplandırılması.
  • Ortancayı (sayısal özellikler) veya modu (kategorik özellikler) kullanarak eksik değerleri atama.
  • Bir girdi kategorik özelliğinin tüm farklı değerlerini (sözcük dağarcığı) çıkararak dizeleri (nominal değerler) tam sayılara (indeksler) dönüştürme.
  • TF-IDF için hesaplamak üzere tüm belgelerde (örneklerde) bir terimin (özellik değeri) oluşumunun sayılması.
  • Verileri daha düşük boyutlu bir alana (doğrusal olarak bağımlı özelliklerle) yansıtmak için giriş özelliklerinin PCA'sını hesaplamak.

  μ, σ, min ve max gibi istatistikleri hesaplamak için yalnızca eğitim verilerini kullanmalısınız. Bu işlemler için test ve değerlendirme verilerini eklerseniz modeli eğitmek için değerlendirme ve test verilerinden bilgi sızdırmış olursunuz. Bunu yapmak test ve değerlendirme sonuçlarının güvenilirliğini etkiler. Tüm veri kümelerine tutarlı bir dönüşüm uyguladığınızdan emin olmak amacıyla, test ve değerlendirme verilerini dönüştürmek için eğitim verilerinden hesaplanan istatistiklerin aynısını kullanırsınız.

• Eğitim ve tahmin sırasındaki tarihsel toplamalar . Bu, tahmin görevine girdi sinyalleri olarak iş toplamaları, türetmeler ve işaretler oluşturmayı içerir; örneğin, müşterilerin eğilim modelleri oluşturması için güncellik, sıklık ve parasal (RFM) ölçümler oluşturma. Bu tür özellikler önceden hesaplanabilir ve model eğitimi, toplu puanlama ve çevrimiçi tahmin sunumu sırasında kullanılmak üzere bir özellik deposunda saklanabilir. Ayrıca eğitim ve tahminden önce bu toplamalara ek özellik mühendisliği (örneğin, dönüştürme ve ayarlama) gerçekleştirebilirsiniz.

• Eğitim sırasındaki tarihsel toplamalar, ancak tahmin sırasındaki gerçek zamanlı toplamalar . Bu yaklaşım, zaman içindeki gerçek zamanlı değerleri özetleyerek bir özellik oluşturmayı içerir. Bu yaklaşımda toplanacak örnekler zamansal pencere cümlecikleri aracılığıyla tanımlanır. Örneğin, rotanın son 5 dakika, son 10 dakika, son 30 dakika ve diğer dakikalardaki trafik ölçümlerine dayalı olarak taksi yolculuğu süresini tahmin eden bir model eğitmek istiyorsanız bu yaklaşımı kullanabilirsiniz. aralıklar. Bu yaklaşımı, son 3 dakika içinde hesaplanan sıcaklık ve titreşim değerlerinin hareketli ortalamasına dayanarak bir motor parçasının arızasını tahmin etmek için de kullanabilirsiniz. Bu toplamalar eğitim için çevrimdışı olarak hazırlanabilse de, sunum sırasında bir veri akışından gerçek zamanlı olarak hesaplanır.

  Daha doğrusu, eğitim verilerini hazırlarken, eğer toplu değer ham verilerde yoksa değer, veri mühendisliği aşamasında yaratılır. Ham veriler genellikle (entity, timestamp, value) biçiminde bir veritabanında depolanır. Önceki örneklerde entity , taksi rotaları için rota segmenti tanımlayıcısı ve motor arızası için motor parçası tanımlayıcısıdır. Hesaplama için pencereleme işlemlerini (entity, time_index, aggregated_value_over_time_window) kullanabilir ve toplama özelliklerini model eğitiminiz için bir girdi olarak kullanabilirsiniz.

  Gerçek zamanlı (çevrimiçi) tahmine yönelik model sunulduğunda, model, girdi olarak birleştirilmiş değerlerden türetilen özellikleri bekler. Bu nedenle, sisteminize aktarılan gerçek zamanlı veri noktalarından toplamaları hesaplamak için Apache Beam gibi bir akış işleme teknolojisini kullanabilirsiniz. Akış işleme teknolojisi, yeni veri noktaları geldikçe zaman pencerelerine dayalı olarak gerçek zamanlı verileri toplar. Ayrıca eğitim ve tahminden önce bu toplamalara ek özellik mühendisliği (örneğin, dönüştürme ve ayarlama) gerçekleştirebilirsiniz.

Google Cloud'da ML ardışık düzeni

Bu bölümde, yönetilen hizmetleri kullanarak TensorFlow ML modellerini Google Cloud'da eğitmek ve sunmak için kullanılan tipik bir uçtan uca ardışık düzenin temel bileşenleri açıklanmaktadır. Ayrıca veri ön işleme operasyonlarının farklı kategorilerini nerede uygulayabileceğinizi ve bu tür dönüşümleri uygularken karşılaşabileceğiniz ortak zorlukları da tartışır. Tf.Transform nasıl çalışır bölümü, TensorFlow Transform kütüphanesinin bu zorlukların üstesinden gelmeye nasıl yardımcı olduğunu gösterir.

Üst düzey mimari

Aşağıdaki diyagram (şekil 2), TensorFlow modellerinin eğitimi ve sunumu için tipik bir ML işlem hattının yüksek düzey mimarisini göstermektedir. Diyagramdaki A, B ve C etiketleri, veri ön işlemesinin gerçekleşebileceği ardışık düzendeki farklı yerleri ifade eder. Bu adımlara ilişkin ayrıntılar aşağıdaki bölümde verilmektedir.

Boru hattı aşağıdaki adımlardan oluşur:

1. Ham veriler içe aktarıldıktan sonra tablo verileri BigQuery'de, görüntüler, ses ve video gibi diğer veriler ise Cloud Storage'da depolanır. Bu serinin ikinci bölümünde örnek olarak BigQuery'de depolanan tablo verileri kullanılıyor.
2. Veri mühendisliği (hazırlık) ve özellik mühendisliği, Dataflow kullanılarak uygun ölçekte yürütülür. Bu yürütme, Cloud Storage'da depolanan ML'ye hazır eğitim, değerlendirme ve test kümeleri üretir. İdeal olarak bu veri kümeleri, TensorFlow hesaplamaları için optimize edilmiş format olan TFRecord dosyaları olarak saklanır.
3. Modeli eğitmek için önceki adımlarda önceden işlenmiş verileri kullanan bir TensorFlow model eğitim paketi Vertex AI Training'e gönderilir. Bu adımın çıktısı, Cloud Storage'a aktarılan eğitimli bir TensorFlow SavedModel'dir .
4. Eğitilen TensorFlow modeli, çevrimiçi tahminler için kullanılabilmesi amacıyla REST API'ye sahip bir hizmet olarak Vertex AI Prediction'a dağıtılır. Aynı model toplu tahmin işleri için de kullanılabilir.
5. Model bir REST API olarak dağıtıldıktan sonra istemci uygulamaları ve dahili sistemler, bazı veri noktalarıyla istekler göndererek ve tahminlerle birlikte modelden yanıtlar alarak API'yi çağırabilir.
6. Bu işlem hattını düzenlemek ve otomatikleştirmek için Vertex AI Pipelines'ı veri hazırlama, model eğitimi ve model dağıtım adımlarını başlatmak üzere bir planlayıcı olarak kullanabilirsiniz.

Tahminlerde bulunmak amacıyla giriş özelliklerini depolamak için Vertex AI Özellik Mağazasını da kullanabilirsiniz. Örneğin, en son ham verilerden periyodik olarak mühendislik özellikleri oluşturabilir ve bunları Vertex AI Özellik Mağazasında saklayabilirsiniz. İstemci uygulamaları, Vertex AI Özellik Mağazasından gerekli giriş özelliklerini alır ve tahminleri almak üzere bunları modele gönderir.

Ön işleme nerede yapılır?

Şekil 2'de A, B ve C etiketleri veri ön işleme işlemlerinin BigQuery, Dataflow veya TensorFlow'da gerçekleştirilebileceğini göstermektedir. Aşağıdaki bölümlerde bu seçeneklerin her birinin nasıl çalıştığı açıklanmaktadır.

Seçenek A: BigQuery

BigQuery'de genellikle aşağıdaki işlemler için mantık uygulanır:

• Örnekleme: Verilerden rastgele bir alt kümenin seçilmesi.
• Filtreleme: alakasız veya geçersiz örneklerin kaldırılması.
• Bölümleme: Verileri eğitim, değerlendirme ve test setleri oluşturmak için bölmek.

BigQuery SQL komut dosyaları, şekil 2'deki veri işleme adımı olan Dataflow ön işleme hattı için kaynak sorgusu olarak kullanılabilir. Örneğin, Kanada'da bir sistem kullanılıyorsa ve veri ambarında dünyanın her yerinden işlemler varsa, filtreleme Yalnızca Kanada'ya özel eğitim verileri almanın en iyi yolu BigQuery'de yapılır. BigQuery'deki özellik mühendisliği basit ve ölçeklenebilirdir ve örnek düzeyinde ve geçmiş toplama özelliği dönüşümlerinin uygulanmasını destekler.

Ancak BigQuery'yi özellik mühendisliği için yalnızca modelinizi toplu tahmin (puanlama) için kullanıyorsanız veya özellikler BigQuery'de önceden hesaplanmış ancak çevrimiçi tahmin sırasında kullanılmak üzere Vertex AI Özellik Mağazası'nda depolanmışsa kullanmanızı öneririz. Modeli çevrimiçi tahminler için dağıtmayı planlıyorsanız ve çevrimiçi özellik deposunda tasarlanmış özelliğe sahip değilseniz, diğer sistemlerin oluşturduğu ham veri noktalarını dönüştürmek için SQL ön işleme işlemlerini çoğaltmanız gerekir. Başka bir deyişle, mantığı iki kez uygulamanız gerekir: İlk kez BigQuery'de eğitim verilerini ön işlemek için SQL'de ve ikinci kez tahmin amacıyla çevrimiçi veri noktalarını ön işlemek için modeli tüketen uygulamanın mantığında.

Örneğin, istemci uygulamanız Java'da yazılmışsa mantığı Java'da yeniden uygulamanız gerekir. Bu, bu belgenin ilerleyen kısımlarındaki Ön İşleme zorluklarının eğitim-hizmet çarpıklığı bölümünde açıklandığı gibi, uygulama tutarsızlıklarından kaynaklanan hatalara neden olabilir. Ayrıca iki farklı uygulamayı sürdürmek ekstra masraf gerektirir. Eğitim verilerini ön işlemek için SQL'deki mantığı değiştirdiğinizde, Java uygulamasını, sunum sırasında verileri ön işlemeye uygun şekilde değiştirmeniz gerekir.

Modelinizi yalnızca toplu tahmin için kullanıyorsanız (örneğin, Vertex AI toplu tahmini kullanarak) ve puanlama verileriniz BigQuery'den geliyorsa bu ön işleme işlemlerini BigQuery SQL komut dosyasının parçası olarak uygulayabilirsiniz. Bu durumda, hem eğitim hem de puanlama verilerini hazırlamak için aynı ön işleme SQL komut dosyasını kullanabilirsiniz.

Tam geçişli durum bilgisi olan dönüşümler BigQuery'de uygulamaya uygun değildir. Tam geçişli dönüşümler için BigQuery'yi kullanıyorsanız sayısal özellikleri ölçeklendirmek için ortalamalar ve varyanslar gibi durum bilgisi olan dönüşümlerin ihtiyaç duyduğu miktarları depolamak için yardımcı tablolara ihtiyacınız vardır. Ayrıca BigQuery'de SQL kullanarak tam geçişli dönüşümlerin uygulanması, SQL komut dosyalarında daha fazla karmaşıklık yaratır ve eğitim ile puanlama SQL komut dosyaları arasında karmaşık bir bağımlılık oluşturur.

Seçenek B: Veri Akışı

Şekil 2'de gösterildiği gibi, Apache Beam'de hesaplama açısından pahalı ön işleme işlemlerini uygulayabilir ve bunları Dataflow'u kullanarak uygun ölçekte çalıştırabilirsiniz. Dataflow, toplu ve akış veri işlemeye yönelik tam olarak yönetilen bir otomatik ölçeklendirme hizmetidir. Dataflow'u kullandığınızda, BigQuery'den farklı olarak veri işleme için özel harici kitaplıkları da kullanabilirsiniz.

Dataflow, örnek düzeyinde dönüşümlerin yanı sıra tarihsel ve gerçek zamanlı toplama özelliği dönüşümlerini gerçekleştirebilir. Özellikle, ML modelleriniz total_number_of_clicks_last_90sec gibi bir giriş özelliği bekliyorsa Apache Beam pencereleme işlevleri , bu özellikleri, gerçek zamanlı (akış) olay verilerinin (örneğin, tıklama olayları) zaman pencerelerinin değerlerini toplamaya dayalı olarak hesaplayabilir. Dönüşümlerin ayrıntı düzeyiyle ilgili daha önceki tartışmada buna "Eğitim sırasındaki geçmiş toplamalar, ancak tahmin sırasındaki gerçek zamanlı toplamalar" deniyordu.

Aşağıdaki diyagram (Şekil 3), neredeyse gerçek zamanlı tahminler için akış verilerinin işlenmesinde Dataflow'un rolünü göstermektedir.

Şekil 3'te gösterildiği gibi, işleme sırasında veri noktaları adı verilen olaylar Pub/Sub'a alınır. Dataflow bu veri noktalarını kullanır, zaman içindeki toplamlara göre özellikleri hesaplar ve ardından tahminler için dağıtılan ML modeli API'sini çağırır. Tahminler daha sonra giden Pub/Sub kuyruğuna gönderilir. Tahminler, Pub/Sub'dan izleme veya kontrol gibi alt sistemler tarafından tüketilebilir veya istekte bulunan orijinal istemciye geri gönderilebilir (örneğin, bildirim olarak). Tahminler, gerçek zamanlı alım için Cloud Bigtable gibi düşük gecikmeli bir veri deposunda da saklanabilir. Cloud Bigtable, bu gerçek zamanlı toplamaları biriktirmek ve depolamak için de kullanılabilir; böylece tahmin için gerektiğinde bunlara bakılabilir.

Aynı Apache Beam uygulaması, BigQuery gibi çevrimdışı bir veri deposundan gelen eğitim verilerini toplu olarak işlemek ve çevrimiçi tahminler sunmak için gerçek zamanlı verileri akış halinde işlemek için kullanılabilir.

Şekil 2'de gösterilen mimari gibi diğer tipik mimarilerde, istemci uygulaması çevrimiçi tahminler için doğrudan dağıtılan model API'sini çağırır. Bu durumda, eğitim verilerini hazırlamak için Dataflow'da ön işleme işlemleri uygulanırsa işlemler doğrudan modele giden tahmin verilerine uygulanmaz. Bu nedenle çevrimiçi tahminlerin sunulması sırasında bu gibi dönüşümlerin modele entegre edilmesi gerekir.

Veri akışı, gerekli istatistikleri uygun ölçekte hesaplayarak tam geçişli dönüşümü gerçekleştirmek için kullanılabilir. Ancak bu istatistiklerin, tahmin veri noktalarını dönüştürmek için tahmin sırasında kullanılmak üzere bir yerde saklanması gerekir. TensorFlow Transform ( tf.Transform ) kütüphanesini kullanarak, bu istatistikleri başka bir yerde saklamak yerine doğrudan modele gömebilirsiniz. Bu yaklaşım daha sonra tf.Transform nasıl çalışır bölümünde açıklanacaktır.

Seçenek C: TensorFlow

Şekil 2'de gösterildiği gibi, veri ön işleme ve dönüştürme işlemlerini TensorFlow modelinin kendisinde uygulayabilirsiniz. Şekilde gösterildiği gibi, TensorFlow modelini eğitmek için uyguladığınız ön işleme, model dışa aktarıldığında ve tahminler için dağıtıldığında modelin ayrılmaz bir parçası haline gelir. TensorFlow modelindeki dönüşümler aşağıdaki yollardan biriyle gerçekleştirilebilir:

• Tüm örnek düzeyindeki dönüşüm mantığının input_fn işlevinde ve serving_fn işlevinde uygulanması. input_fn işlevi, bir modeli eğitmek için tf.data.Dataset API'sini kullanarak bir veri kümesi hazırlar. serving_fn işlevi, verileri tahminler için alır ve hazırlar.
• Keras ön işleme katmanlarını kullanarak veya özel katmanlar oluşturarak dönüşüm kodunu doğrudan TensorFlow modelinize yerleştirme.

serving_fn işlevindeki dönüşüm mantığı kodu, çevrimiçi tahmin için SavedModel'inizin sunum arayüzünü tanımlar. Eğitim verilerini hazırlamak için kullanılan dönüşümlerin aynılarını, serving_fn işlevinin dönüştürme mantığı kodunda uygularsanız, aynı dönüşümlerin, sunulduğunda yeni tahmin veri noktalarına da uygulanmasını sağlar.

Ancak TensorFlow modeli her veri noktasını bağımsız olarak veya küçük bir toplu iş halinde işlediğinden, tüm veri noktalarından toplamaları hesaplayamazsınız. Sonuç olarak TensorFlow modelinizde tam geçişli dönüşümler uygulanamaz.

Ön işleme zorlukları

Veri ön işlemeyi uygulamanın başlıca zorlukları şunlardır:

• Eğitim-hizmet çarpıklığı . Eğitim-servis çarpıklığı, antrenman ve servis sırasındaki etkinlik (tahmin performansı) arasındaki farkı ifade eder. Bu çarpıklığa, eğitimdeki verileri işleme şekliniz ile sunum ardışık düzenleri arasındaki tutarsızlık neden olabilir. Örneğin, modeliniz logaritmik olarak dönüştürülmüş bir özellik üzerinde eğitildiyse ancak sunum sırasında ham özellik ile sunulduysa tahmin çıktısı doğru olmayabilir.

  Dönüşümler modelin kendisinin bir parçası haline gelirse, daha önce Seçenek C: TensorFlow'da açıklandığı gibi örnek düzeyindeki dönüşümleri yönetmek kolay olabilir. Bu durumda, model hizmet arayüzü ( serving_fn işlevi) ham verileri beklerken model, çıktıyı hesaplamadan önce bu verileri dahili olarak dönüştürür. Dönüşümler, ham eğitim ve tahmin veri noktalarına uygulananlarla aynıdır.

• Tam geçişli dönüşümler . TensorFlow modelinizde ölçeklendirme ve normalizasyon dönüşümleri gibi tam geçişli dönüşümleri uygulayamazsınız. Tam geçişli dönüşümlerde, Seçenek B: Veri Akışı bölümünde açıklandığı gibi bazı istatistiklerin (örneğin, sayısal özellikleri ölçeklendirmek için max ve min değerler) eğitim verileri üzerinde önceden hesaplanması gerekir. Daha sonra değerlerin, yeni ham veri noktalarını örnek düzeyinde dönüşümler olarak dönüştürmek için tahmin amacıyla model hizmeti sırasında kullanılmak üzere bir yerde saklanması gerekir; bu, eğitim hizmeti çarpıklığını önler. İstatistikleri doğrudan TensorFlow modelinize eklemek için TensorFlow Transform ( tf.Transform ) kitaplığını kullanabilirsiniz. Bu yaklaşım daha sonra tf.Transform nasıl çalışır bölümünde açıklanacaktır.

• Daha iyi eğitim verimliliği için verileri önceden hazırlamak . Örnek düzeyinde dönüşümlerin modelin bir parçası olarak uygulanması, eğitim sürecinin verimliliğini düşürebilir. Bu bozulma, aynı dönüşümlerin her çağda aynı eğitim verilerine tekrar tekrar uygulanması nedeniyle oluşur. 1.000 özelliğe sahip ham eğitim verileriniz olduğunu ve 10.000 özellik oluşturmak için örnek düzeyinde dönüşümlerin bir karışımını uyguladığınızı hayal edin. Bu dönüşümleri modelinizin bir parçası olarak uygularsanız ve daha sonra modeli ham eğitim verilerini beslerseniz, bu 10.000 işlem her örnekte N kez uygulanır; burada N , dönem sayısıdır. Ayrıca, hızlandırıcılar (GPU'lar veya TPU'lar) kullanıyorsanız, CPU bu dönüşümleri gerçekleştirirken bunlar boşta kalır ve bu, maliyetli hızlandırıcılarınızın verimli bir şekilde kullanılması anlamına gelmez.

  İdeal olarak, eğitim verileri , Seçenek B: Veri Akışı altında açıklanan teknik kullanılarak eğitimden önce dönüştürülür; burada 10.000 dönüştürme işlemi, her eğitim örneğinde yalnızca bir kez uygulanır. Dönüştürülen eğitim verileri daha sonra modele sunulur. Daha fazla dönüşüm uygulanmaz ve hızlandırıcılar her zaman meşguldür. Ayrıca Dataflow'u kullanmak, tam olarak yönetilen bir hizmet kullanarak büyük miktarda veriyi uygun ölçekte önceden işlemenize yardımcı olur.

  Eğitim verilerinin önceden hazırlanması, eğitim verimliliğini artırabilir. Ancak dönüşüm mantığını modelin dışında uygulamak ( Seçenek A: BigQuery veya Seçenek B: Veri Akışı'nda açıklanan yaklaşımlar), eğitim sunumunda çarpıklık sorununu çözmez. Tasarlanan özelliği hem eğitim hem de tahmin için kullanılacak özellik deposunda saklamadığınız sürece, model arayüzü dönüştürülmüş verileri beklediğinden, dönüşüm mantığının tahmin için gelen yeni veri noktalarına uygulanacak bir yere uygulanması gerekir. TensorFlow Transform ( tf.Transform ) kitaplığı, aşağıdaki bölümde açıklandığı gibi bu sorunu çözmenize yardımcı olabilir.

tf.Transform nasıl çalışır?

tf.Transform kütüphanesi, tam geçiş gerektiren dönüşümler için kullanışlıdır. tf.Transform kütüphanesinin çıktısı, eğitim ve hizmet için kullanılmak üzere örnek düzeyindeki dönüşüm mantığını ve tam geçişli dönüşümlerden hesaplanan istatistikleri temsil eden bir TensorFlow grafiği olarak dışa aktarılır. Hem eğitim hem de servis için aynı grafiği kullanmak çarpıklığı önleyebilir çünkü her iki aşamada da aynı dönüşümler uygulanır. Ayrıca tf.Transform kitaplığı, eğitim verilerini önceden hazırlamak ve eğitim verimliliğini artırmak için Dataflow üzerinde toplu işleme hattında uygun ölçekte çalışabilir.

Aşağıdaki diyagram (şekil 4), tf.Transform kitaplığının eğitim ve tahmin için verileri nasıl ön işlediğini ve dönüştürdüğünü gösterir. Süreç aşağıdaki bölümlerde anlatılmaktadır.

Eğitim ve değerlendirme verilerini dönüştürün

tf.Transform Apache Beam API'lerinde uygulanan dönüşümü kullanarak ham eğitim verilerini önceden işler ve bunu Dataflow'da uygun ölçekte çalıştırırsınız. Ön işleme aşağıdaki aşamalarda gerçekleşir:

• Analiz aşaması: Analiz aşamasında, durum bilgisi olan dönüşümler için gerekli istatistikler (ortalamalar, varyanslar ve nicelikler gibi), tam geçişli işlemlerle eğitim verileri üzerinde hesaplanır. Bu aşama, transform_fn grafiği de dahil olmak üzere bir dizi dönüşüm eseri üretir. transform_fn grafiği, örnek düzeyinde işlemler olarak dönüştürme mantığına sahip bir TensorFlow grafiğidir. Analiz aşamasında hesaplanan istatistikleri sabit olarak içerir.
• Dönüştürme aşaması: Dönüştürme aşaması sırasında, transform_fn grafiği ham eğitim verilerine uygulanır; burada hesaplanan istatistikler, veri kayıtlarını örnek düzeyinde işlemek için (örneğin sayısal sütunları ölçeklendirmek için) kullanılır.

Bunun gibi iki aşamalı bir yaklaşım, tam geçişli dönüşümleri gerçekleştirmenin ön işleme zorluğunu giderir.

Değerlendirme verileri ön işleme tabi tutulduğunda, transform_fn grafiğindeki mantık ve eğitim verilerindeki analiz aşamasından hesaplanan istatistikler kullanılarak yalnızca örnek düzeyinde işlemler uygulanır. Başka bir deyişle, değerlendirme verilerindeki sayısal özellikleri normalleştirmek amacıyla μ ve σ gibi yeni istatistikleri hesaplamak için değerlendirme verilerini tam geçişli bir şekilde analiz etmezsiniz. Bunun yerine, değerlendirme verilerini örnek düzeyinde dönüştürmek için eğitim verilerinden hesaplanan istatistikleri kullanırsınız.

Dönüştürülen eğitim ve değerlendirme verileri, modeli eğitmek için kullanılmadan önce Dataflow kullanılarak uygun ölçekte hazırlanır. Bu parti veri hazırlama işlemi, eğitim verimliliğini artırmak için verilerin hazırlanmasının ön işleme zorluğunu ele almaktadır. Şekil 4'te gösterildiği gibi, model dahili arayüzü dönüştürülmüş özellikler beklemektedir.

Dönüşümleri dışa aktarılan modele ekleyin

Belirtildiği gibi, tf.Transform boru hattı tarafından üretilen transform_fn grafiği, dışa aktarılan bir tensorflow grafiği olarak saklanır. Dışa aktarılan grafik, örnek düzeyindeki işlemler olarak dönüşüm mantığından ve tam geçiş dönüşümlerinde grafik sabitleri olarak hesaplanan tüm istatistiklerden oluşur. Eğitimli model servis için dışa aktarıldığında, transform_fn grafiği serving_fn işlevinin bir parçası olarak SavedModel'e eklenir.

Tahmin modeli sunarken, model servis arayüzü ham formatta (yani herhangi bir dönüşümden önce) veri noktaları bekler. Ancak, model dahili arayüzü verileri dönüştürülmüş formatta bekler.

Şu anda modelin bir parçası olan transform_fn grafiği, gelen veri noktasındaki tüm ön işlem mantığını uygular. Tahmin sırasında örnek düzeyinde işlemde saklanan sabitleri (μ ve σ gibi) kullanır. Bu nedenle, transform_fn grafiği ham veri noktasını dönüştürülmüş biçime dönüştürür. Dönüştürülmüş format, Şekil 4'te gösterildiği gibi tahmin üretmek için model dahili arayüz tarafından beklenen şeydir.

Bu mekanizma, eğitim ve değerlendirme verilerini dönüştürmek için kullanılan aynı mantık (uygulama), tahmin porsiyonu sırasında yeni veri noktalarını dönüştürmek için uygulandığından, eğitime hizmet etme eğrisinin ön işleme zorluğunu çözmektedir.

Ön İşleme Seçenekleri Özeti

Aşağıdaki tabloda, bu belgenin tartıştığı veri ön işleme seçeneklerini özetlemektedir. Tabloda, "Yok" anlamına gelir "uygulanamaz."

^* Tensorflow ile, geçiş, gömme ve tek sıcak kodlama gibi dönüşümler bildirici olarak feature_columns sütunları olarak gerçekleştirilmelidir.

Sırada ne var

• Bir tf.Transform Boru Hattı uygulamak ve DataFlow kullanarak çalıştırmak için, bu serinin ikinci bölümünü okuyun, ML için Veri Ön İşleme Tensorflow dönüşümü kullanarak .
• Google Cloud'da TensorFlow ile ML'de Coursera Uzmanlığı'nı ele alalım.
• ML Kurallarında ML Mühendisliği için En İyi Uygulamalar hakkında bilgi edinin.
• Daha fazla referans mimarisi, diyagram ve en iyi uygulamalar için TFX bulut çözümlerini keşfedin.

Bu belge, denetimli öğrenme görevlerine odaklanarak, veri mühendisliği ve makine öğrenimi (ML) için özellik mühendisliği konusunu araştıran iki bölümlük bir dizide ilk belgedir. Bu ilk bölüm, Google Cloud'daki bir ML boru hattında ön işleme için en iyi uygulamaları tartışmaktadır. Belge, verileri hazırlamak, modeli eğitmek ve tahmin için modeli sunmak için TensorFlow ve Açık Kaynak Tensorflow Dönüşümü ( tf.Transform ) kitaplığı kullanmaya odaklanmaktadır. Bu belge, ML için verilerin ön işlemenin zorluklarını vurgular ve Google Cloud'da veri dönüşümünü etkin bir şekilde gerçekleştirme seçeneklerini ve senaryolarını açıklar.

Bu belge, BigQuery , DataFlow , Vertex AI ve Tensorflow Keras API'sına aşina olduğunuzu varsayar.

İkinci belge, Google Cloud ile ML için veri ön işlemesi , bir tf.Transform boru hattının nasıl uygulanacağı için adım adım bir eğitim sunar.

giriiş

ML, verilerde otomatik olarak karmaşık ve potansiyel olarak kullanışlı kalıplar bulmanıza yardımcı olur. Bu kalıplar, daha sonra yeni veri noktalarında kullanılabilen bir ML modelinde yoğunlaşır - tahminler yapma veya çıkarma işlemi adı verilen bir süreç.

ML modeli oluşturmak çok aşamalı bir işlemdir. Her adım kendi teknik ve kavramsal zorluklarını sunar. Bu iki bölümlük seri, denetimli öğrenme görevlerine ve hedef değişkene güçlü öngörücü sinyaller oluşturmak için kaynak verilerin seçilmesi, dönüştürülmesi ve artırılması sürecine odaklanmaktadır. Bu işlemler alan bilgisini veri bilimi teknikleriyle birleştirir. Operasyonlar özellik mühendisliğinin özüdür.

Gerçek dünya ML modelleri için eğitim veri kümelerinin boyutu, bir terabayte (TB) kolay veya daha büyük olabilir. Bu nedenle, bu veri kümelerini verimli ve dağınık olarak işlemek için büyük ölçekli veri işleme çerçevelerine ihtiyacınız vardır. Tahmin yapmak için bir ML modeli kullandığınızda, yeni veri noktalarındaki eğitim verileri için kullandığınız dönüşümleri uygulamanız gerekir. Aynı dönüşümleri uygulayarak, canlı veri kümesini ML modeline modelin beklediği şekilde sunarsınız.

Bu belge, özellik mühendisliği operasyonlarının farklı ayrıntılı seviyeleri için bu zorlukları tartışmaktadır: örnek düzeyinde, tam geçiş ve zaman penceresi toplantıları. Bu belgede ayrıca Google Cloud'da ML için veri dönüşümü gerçekleştirme seçenekleri ve senaryoları da açıklanmaktadır.

Bu belge ayrıca, veri ön işlem boru hatları aracılığıyla hem örnek düzeyinde hem de tam geçiş veri dönüşümünü tanımlamanızı sağlayan TensorFlow için bir kütüphane olan TensorFlow Dönüşümü'ne ( tf.Transform ) genel bir bakış sağlar. Bu boru hatları Apache Beam ile yürütülür ve modelin sunulduğu zamanla aynı dönüşümleri uygulamanıza izin veren eserler oluştururlar.

ML için önişleme verileri

Bu bölüm, veri ön işleme işlemlerini ve veri hazırlığının aşamalarını tanıtmaktadır. Ayrıca ön işleme operasyonlarının türlerini ve bunların ayrıntı düzeyini de tartışır.

Özellik mühendisliğine kıyasla veri mühendisliği

ML verilerinin ön işlenmesi hem veri mühendisliği hem de özellik mühendisliğini içerir. Veri mühendisliği , ham verileri hazırlanan verilere dönüştürme işlemidir. Özellik mühendisliği daha sonra ML modelinin beklenen özelliklerini oluşturmak için hazırlanan verileri ayarlar. Bu terimlerin aşağıdaki anlamları vardır:

Ham veriler (veya sadece veriler )

ML'ye önceden hazırlık yapmadan kaynak formundaki veriler. Bu bağlamda, veriler ham formunda (bir veri gölünde) veya dönüştürülmüş bir biçimde (bir veri ambarı) olabilir. Bir veri ambarıdaki dönüştürülmüş veriler, analitik için kullanılacak orijinal ham formundan dönüştürülmüş olabilir. Bununla birlikte, bu bağlamda, ham veriler verilerin özellikle ML göreviniz için hazırlanmadığı anlamına gelir. Veriler, sonunda tahminler için ML modellerini çağıran akış sistemlerinden gönderilirse ham veriler olarak da kabul edilir.

Hazırlanan Veriler

ML görevinize hazır formdaki veri kümesi: Veri kaynakları ayrıştırılmış, birleştirilmiş ve tablo bir forma konulmuştur. Hazırlanan veriler toplanır ve doğru tanrısallığa özetlenir - örneğin, veri kümesindeki her satır benzersiz bir müşteriyi temsil eder ve her sütun, son altı haftada harcanan toplam gibi müşteri için özet bilgileri temsil eder. Hazırlanan bir veri tablosunda alakasız sütunlar düşürüldü ve geçersiz kayıtlar filtrelendi. Denetimli öğrenme görevleri için hedef özellik mevcuttur.

Tasarlanmış özellikler

Model tarafından beklenen ayarlanmış özelliklere sahip veri kümesi-yani, hazırlanan veri kümesindeki sütunlarda belirli ML'ye özgü işlemleri gerçekleştirerek ve daha sonra açıklandığı gibi, eğitim ve tahmin sırasında modeliniz için yeni özellikler oluşturarak oluşturulan özellikler Ön işleme işlemlerinde . Bu işlemlerin örnekleri arasında sayısal sütunları 0 ila 1 arasındaki bir değere, kırpma değerlerine ve tek-hızlı kodlayan kategorik özelliklere ölçeklendirme sayılabilir.

Aşağıdaki diyagram, Şekil 1, önceden işlenmiş verilerin hazırlanmasında yer alan adımları göstermektedir:

Uygulamada, aynı kaynaktan veriler genellikle farklı hazırlık aşamalarındadır. Örneğin, veri ambarınızdaki bir tablodan bir alan doğrudan tasarlanmış bir özellik olarak kullanılabilir. Aynı zamanda, aynı tablodaki başka bir alanın, tasarlanmış bir özellik haline gelmeden önce dönüşümlerden geçmesi gerekebilir. Benzer şekilde, veri mühendisliği ve özellik mühendisliği işlemleri aynı veri ön işleme adımında birleştirilebilir.

Önişleme işlemleri

Veri ön işlemesi çeşitli işlemler içerir. Her işlem ML'nin daha iyi öngörücü modeller oluşturmasına yardımcı olmak için tasarlanmıştır. Bu önişleme işlemlerinin ayrıntıları bu belgenin kapsamı dışındadır, ancak bazı işlemler bu bölümde kısaca açıklanmaktadır.

Yapılandırılmış veriler için, veri ön işleme işlemleri aşağıdakileri içerir:

• Veri Temizleme: Ham verilerden bozuk veya geçersiz değerleri bozan veya geçersiz değerlerin kaldırılması veya düzeltilmesi ve çok sayıda sütun eksik olan kayıtların kaldırılması.
• Örnek seçimi ve bölümleme: Eğitim, değerlendirme (doğrulama) ve test kümeleri oluşturmak için giriş veri kümesinden veri noktaları seçme. Bu işlem, tekrarlanabilir rastgele örnekleme, azınlık sınıfları aşırı örnekleme ve tabakalı bölümleme için teknikleri içerir.
• Özellik Ayarı: Sayısal değerleri ölçeklendirme ve normalleştirmeyi, eksik değerleri engelleme, kesme aykırı değerleri ve dağınık dağılımları ayarlamayı içeren ML için bir özelliğin kalitesinin iyileştirilmesi.
• Özellik Dönüşümü: Sayısal bir özelliği kategorik bir özelliğe dönüştürmek ( kova ile) ve kategorik özellikleri sayısal bir gösterime dönüştürmek (tek sıcak kodlama, sayımlarla öğrenme , seyrek özellik gömeçleri vb.). Bazı modeller sadece sayısal veya kategorik özelliklerle çalışırken, diğerleri karışık tip özellikleri işleyebilir. Modeller her iki türü de ele aldığında bile, aynı özelliğin farklı gösterimlerinden (sayısal ve kategorik) yararlanabilirler.
• Özellik çıkarma: PCA , gömme ekstraksiyonu ve karma gibi teknikleri kullanarak daha düşük boy, daha güçlü veri gösterimleri oluşturarak özellik sayısını azaltmak.
• Özellik seçimi: Modeli eğitmek için giriş özelliklerinin bir alt kümesini seçmek ve filtre veya sargı yöntemlerini kullanarak alakasız veya gereksiz olanları yok saymak. Özellik seçimi, özelliklerin çok sayıda değer eksikse, özellikleri düşürmeyi de içerebilir.
• Özellik yapımı: Polinom genişlemesi (tek değişkenli matematiksel işlevler kullanarak) veya özellik geçişi (özellik etkileşimlerini yakalamak için) gibi tipik teknikler kullanarak yeni özellikler oluşturmak. Özellikler, ML kullanım durumunun alanından iş mantığı kullanılarak da oluşturulabilir.

Yapılandırılmamış verilerle (örneğin, görüntüler, ses veya metin belgeleri) çalıştığınızda, Deep Learning, alan-bilgi tabanlı özellik mühendisliğinin model mimarisine katlanarak yerini alır. Evrişimsel bir katman otomatik bir özellik önişlemcisidir. Doğru model mimarisinin oluşturulması, veriler hakkında bazı ampirik bilgi gerektirir. Buna ek olarak, aşağıdakiler gibi bir miktar ön işlem gereklidir:

• Metin belgeleri için: sapma ve lemmatizasyon , TF-IDF hesaplaması ve N-gram ekstraksiyonu, gömme arama.
• Görüntüler için: Kırpma, yeniden boyutlandırma, kırpma, Gauss bulanıklığı ve kanarya filtreleri.
• Her türlü veri için (metin ve görüntüler dahil): Tamamen eğitimli modelin tüm ama hassas katmanlarını özellik mühendisliği adımı olarak ele alan aktarma öğrenimi .

Ön işleme ayrıntı

Bu bölüm, veri dönüşüm türlerinin ayrıntı düzeyini tartışmaktadır. Eğitim verilerine uygulanan dönüşümleri kullanarak tahminler için yeni veri noktaları hazırlarken bu perspektifin neden kritik olduğunu gösterir.

Ön işlem ve dönüşüm işlemleri, çalışma tanecikliğine dayanarak aşağıdaki gibi kategorize edilebilir:

• Eğitim ve tahmin sırasında örnek düzeyinde dönüşümler . Bunlar, dönüşüm için yalnızca aynı örnekten değerlerin gerekli olduğu basit dönüşümlerdir. Örneğin, örnek düzeyindeki dönüşümler, bir özelliğin değerini bir eşik değerine kırpmayı, polinom olarak başka bir özelliği genişletmeyi, iki özelliği çarpmayı veya bir boole bayrağı oluşturmak için iki özelliği karşılaştırmayı içerebilir.

  Bu dönüşümler eğitim ve tahmin sırasında aynı şekilde uygulanmalıdır, çünkü model ham giriş değerleri üzerinde değil, dönüştürülmüş özellikler üzerinde eğitilecektir. Veriler aynı şekilde dönüştürülmezse, model kötü davranır, çünkü eğitilmediği değerlerin dağılımına sahip verilerle sunulur. Daha fazla bilgi için, önişleme zorlukları bölümünde eğitim-hizmet eğimi tartışmasına bakın.

• Eğitim sırasında tam geçiş dönüşümleri, ancak tahmin sırasında örnek düzeyinde dönüşümler . Bu senaryoda dönüşümler durumdur, çünkü dönüşümü gerçekleştirmek için önceden hesaplanmış bazı istatistikler kullanırlar. Eğitim sırasında, eğitim verilerini, değerlendirme verilerini ve yeni verileri tahmin zamanında dönüştürmek için minimum, maksimum, ortalama ve varyans gibi miktarları hesaplamak için eğitim verilerinin tamamını analiz edersiniz.

  Örneğin, eğitim için sayısal bir özelliği normalleştirmek için, eğitim verilerinin tamamı boyunca ortalamasını (μ) ve standart sapmasını (σ) hesaplarsınız. Bu hesaplamaya tam geçiş (veya analiz ) işlemi denir. Tahmin için modele hizmet ettiğinizde, eğitim-hizmet etme eğrisini önlemek için yeni bir veri noktasının değeri normalleştirilir. Bu nedenle, eğitim sırasında hesaplanan μ ve σ değerleri, aşağıdaki basit örnek düzeyinde işlem olan özellik değerini ayarlamak için kullanılır:

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

  Tam geçiş dönüşümleri aşağıdakileri içerir:

  • Minmax ölçeklendirme Min ve maks kullanan sayısal özellikler, eğitim veri kümesinden hesaplanır.
  • Eğitim veri kümesinde hesaplanan μ ve σ kullanan standart ölçeklendirme (z-skor normalizasyonu) sayısal özellikleri.
  • Kantilleri kullanarak sayısal özellikleri kovalamak.
  • Ortanca (sayısal özellikler) veya modu (kategorik özellikler) kullanarak eksik değerlerin uygulanması.
  • Bir giriş kategorik özelliğinin tüm farklı değerlerini (kelime) çıkararak dizelerin (nominal değerler) tamsayılara (dizinler) dönüştürülmesi.
  • TF-IDF için hesaplanacak tüm belgelerde (örnekler) bir terimin (özellik değeri) oluşumunu saymak.
  • Verileri daha düşük boyutlu bir alana (doğrusal bağımlı özelliklerle) yansıtmak için giriş özelliklerinin PCA'sının hesaplanması.

  Μ, σ, min ve maks gibi istatistikleri hesaplamak için yalnızca eğitim verilerini kullanmalısınız. Bu işlemler için test ve değerlendirme verilerini eklerseniz, modeli eğitmek için değerlendirme ve test verilerinden bilgi sızdırıyorsunuz . Bunu yapmak test ve değerlendirme sonuçlarının güvenilirliğini etkiler. Tüm veri kümelerine tutarlı bir dönüşüm uyguladığınızdan emin olmak için, test ve değerlendirme verilerini dönüştürmek için eğitim verilerinden hesaplanan aynı istatistikleri kullanırsınız.

• Eğitim ve Tahmin Sırasında Tarihsel Toplamlar . Bu, tahmin görevine girdi sinyalleri olarak iş toplama, türevler ve bayraklar oluşturmayı içerir - örneğin, müşterilerin eğilim modelleri oluşturması için yenilik, frekans ve parasal (RFM) metrikleri yaratır. Bu tür özellikler, model eğitimi, toplu puanlama ve çevrimiçi tahmin porsiyonu sırasında kullanılacak bir özellik deposunda önceden hesaplanabilir ve saklanabilir. Ayrıca, eğitim ve tahminten önce bu agregasyonlara ek özellik mühendisliği (örneğin, dönüşüm ve ayar) gerçekleştirebilirsiniz.

• Eğitim sırasında tarihsel toplama, ancak tahmin sırasında gerçek zamanlı toplama . Bu yaklaşım, zaman içinde gerçek zamanlı değerleri özetleyerek bir özellik oluşturmayı içerir. Bu yaklaşımda, toplanacak örnekler zamansal pencere hükümleri ile tanımlanır. Örneğin, son 5 dakikada, son 10 dakikada, son 30 dakikada ve diğerinde rota için trafik metriklerine dayanan taksi yolculuğu süresini tahmin eden bir model eğitmek istiyorsanız bu yaklaşımı kullanabilirsiniz. aralıklar. Bu yaklaşımı, son 3 dakikada hesaplanan sıcaklık ve titreşim değerlerinin hareketli ortalamasına dayanarak bir motor kısmının arızasını tahmin etmek için de kullanabilirsiniz. Bu agregasyonlar eğitim için çevrimdışı hazırlanabilse de, porsiyon sırasında bir veri akışından gerçek zamanlı olarak hesaplanır.

  Daha kesin olarak, eğitim verileri hazırladığınızda, toplu değer ham verilerde değilse, değer veri mühendisliği aşamasında oluşturulur. Ham veriler genellikle (entity, timestamp, value) biçimine sahip bir veritabanında saklanır. Önceki örneklerde entity , taksi yolları için rota segmenti tanımlayıcısı ve motor arızası için motor kısım tanımlayıcısıdır. Pencere işlemlerini hesaplamak için (entity, time_index, aggregated_value_over_time_window) kullanabilir ve toplama özelliklerini model eğitiminiz için bir giriş olarak kullanabilirsiniz.

  Gerçek zamanlı (çevrimiçi) tahmin için model sunulduğunda, model bir giriş olarak toplanan değerlerden türetilen özellikleri bekler. Bu nedenle, sisteminize akan gerçek zamanlı veri noktalarından gelen toplamaları hesaplamak için Apache Beam gibi bir akış işleme teknolojisi kullanabilirsiniz. Akış işleme teknolojisi, yeni veri noktaları geldikçe zaman pencerelerine göre gerçek zamanlı verileri birleştirir. Ayrıca, eğitim ve tahminten önce bu agregasyonlara ek özellik mühendisliği (örneğin, dönüşüm ve ayar) gerçekleştirebilirsiniz.

Google Cloud'da ML Boru Hattı

Bu bölümde, yönetilen hizmetleri kullanarak Google Cloud'da Tensorflow ML modellerini eğitmek ve sunmak için tipik bir uçtan uca boru hattının temel bileşenlerini tartışmaktadır. Ayrıca, veri ön işleme işlemlerinin farklı kategorilerini ve bu dönüşümleri uyguladığınızda karşılaşabileceğiniz ortak zorlukları nerede uygulayabileceğinizi de tartışır. TF.Transform Works bölümünün nasıl TensorFlow dönüşüm kütüphanesinin bu zorlukları ele almaya nasıl yardımcı olduğunu göstermektedir.

Üst düzey mimarlık

Aşağıdaki diyagram, Şekil 2, tensorflow modellerini eğitmek ve servis etmek için tipik bir ML boru hattının üst düzey bir mimarisini göstermektedir. Diyagramdaki A, B ve C etiketleri, boru hattındaki veri ön işlemenin gerçekleşebileceği farklı yerleri ifade eder. Bu adımlarla ilgili ayrıntılar aşağıdaki bölümde verilmiştir.

Boru hattı aşağıdaki adımlardan oluşur:

1. Ham veriler içe aktarıldıktan sonra, tablo verileri BigQuery'de saklanır ve görüntüler, ses ve video gibi diğer veriler bulut depolamasında saklanır. Bu serinin ikinci kısmı örnek olarak BigQuery'de depolanan tablo verilerini kullanır.
2. Veri mühendisliği (hazırlık) ve özellik mühendisliği, DataFlow kullanılarak ölçekte yürütülür. Bu yürütme, bulut depolamasında depolanan ML'ye hazır eğitim, değerlendirme ve test setleri üretir. İdeal olarak, bu veri kümeleri tensorflow hesaplamaları için optimize edilmiş format olan TFRecord dosyaları olarak saklanır.
3. Modeli eğitmek için önceki adımlardan önceden işlenmiş verileri kullanan Vertex AI eğitimine bir tensorflow model eğitmeni paketi gönderilir. Bu adımın çıktısı, bulut depolamasına aktarılan eğitimli bir tensorflow tasarrufu .
4. Eğitimli tensorflow modeli, çevrimiçi tahminler için kullanılabilmesi için REST API'si olan bir hizmet olarak Vertex AI Tahminine dağıtılır. Aynı model de toplu tahmin işleri için de kullanılabilir.
5. Model REST API'sı olarak dağıtıldıktan sonra, istemci uygulamaları ve dahili sistemler, bazı veri noktaları ile istek göndererek ve modelden tahminlerle yanıt alarak API'yı çağırabilir.
6. Bu boru hattını düzenlemek ve otomatikleştirmek için, veri hazırlama, model eğitim ve model dağıtım adımlarını çağırmak için bir zamanlayıcı olarak Vertex AI boru hatlarını kullanabilirsiniz.

Tahmin yapmak için giriş özelliklerini depolamak için Vertex AI özellik mağazasını da kullanabilirsiniz. Örneğin, en son ham verilerden periyodik olarak tasarlanmış özellikler oluşturabilir ve Vertex AI özellik mağazasında saklayabilirsiniz. İstemci Uygulamaları Vertex AI özellik mağazasından gerekli giriş özelliklerini getirir ve tahminleri almak için bunları modele gönderir.

Önişleme nerede yapılır

Şekil 2'de, A, B ve C etiketleri, veri ön işleme işlemlerinin BigQuery, DataFlow veya TensorFlow'da gerçekleşebileceğini göstermektedir. Aşağıdaki bölümlerde bu seçeneklerin her birinin nasıl çalıştığı açıklanmaktadır.

Seçenek A: Bigquery

Tipik olarak, mantık aşağıdaki işlemler için BigQuery'de uygulanır:

• Örnekleme: Verilerden rastgele bir alt kümeyi seçme.
• Filtreleme: alakasız veya geçersiz örneklerin çıkarılması.
• Bölümleme: Verilerin eğitim, değerlendirme ve test setleri üretmek için bölünmesi.

BigQuery SQL komut dosyaları, Şekil 2'deki veri işleme aşaması olan veri akışı ön işleme boru hattı için bir kaynak sorgu olarak kullanılabilir. Örneğin, Kanada'da bir sistem kullanılıyorsa ve veri deposunun dünyanın dört bir yanından işlemleri varsa, filtreleme Kanada'nın yalnızca eğitim verilerini en iyi şekilde BigQuery'de yapılır. BigQuery'deki özellik mühendisliği basit ve ölçeklenebilirdir ve örnek düzeyinde ve tarihi toplama özellik dönüşümlerini uygulamayı destekler.

Bununla birlikte, sadece toplu tahmini (puanlama) için modelinizi kullanıyorsanız veya özellikler Bigquery'de önceden hesaplanmışsa, ancak çevrimiçi tahmin sırasında kullanılacak olan Vertex AI özellik mağazasında depolanmışsa, özellik mühendisliği için BigQuery kullanmanızı öneririz. Modeli çevrimiçi tahminler için dağıtmayı planlıyorsanız ve bir çevrimiçi özellik mağazasında tasarlanmış özelliğiniz yoksa, diğer sistemlerin ürettiği ham veri noktalarını dönüştürmek için SQL ön işleme işlemlerini çoğaltmanız gerekir. Başka bir deyişle, mantığı iki kez uygulamanız gerekir: SQL'de bir kez BigQuery'de eğitim verilerini ön planda ve uygulama mantığında ikinci kez tahmin için çevrimiçi veri noktalarını önceden işlemek için modeli tüketen.

Örneğin, müşteri uygulamanız Java'da yazılmışsa, Java'daki mantığı yeniden yerleştirmeniz gerekir. Bu, bu belgede daha sonraki zorlukların ön işleme zorluklarının eğitime hizmet eden çarpıklık bölümünde açıklandığı gibi, uygulama tutarsızlıkları nedeniyle hatalar getirebilir. Ayrıca iki farklı uygulamayı sürdürmek için ekstra ek yük. Eğitim verilerini önceden işlemek için SQL'deki mantığı ne zaman değiştirdiğinizde, Java uygulamasını servis zamanında ön işlem verilerine göre değiştirmeniz gerekir.

Modelinizi yalnızca toplu tahmini için kullanıyorsanız (örneğin, Vertex AI toplu tahmini kullanarak) ve puanlama için verileriniz BigQuery'den kaynaklanıyorsa, bu ön işlem işlemlerini BigQuery SQL komut dosyasının bir parçası olarak uygulayabilirsiniz. Bu durumda, hem eğitim hem de puanlama verilerini hazırlamak için aynı ön işlem SQL komut dosyasını kullanabilirsiniz.

Tam geçişli durumlu dönüşümler BigQuery'de uygulama için uygun değildir. Tam geçiş dönüşümleri için BigQuery kullanıyorsanız, sayısal özellikleri ölçeklendirmek için araçlar ve varyanslar gibi durumlu dönüşümlerin ihtiyaç duyduğu miktarları depolamak için yardımcı tablolara ihtiyacınız vardır. Ayrıca, BigQuery'de SQL kullanılarak tam geçiş dönüşümlerinin uygulanması, SQL komut dosyalarında artan karmaşıklık yaratır ve eğitim ve puanlama SQL komut dosyaları arasında karmaşık bağımlılık yaratır.

Seçenek B: Veri Akışı

Şekil 2'de gösterildiği gibi, Apache Beam'de hesaplama açısından pahalı ön işleme işlemlerini uygulayabilir ve veri akışını kullanarak ölçekte çalıştırabilirsiniz. DataFlow, parti ve akış veri işleme için tam olarak yönetilen bir otomatiklik hizmetidir. DataFlow'u kullandığınızda, BigQuery'nin aksine, veri işleme için harici özel kütüphaneleri de kullanabilirsiniz.

DataFlow, örnek düzeyinde dönüşümler ve geçmiş ve gerçek zamanlı toplama özellik dönüşümleri gerçekleştirebilir. Özellikle, ML modelleriniz total_number_of_clicks_last_90sec gibi bir giriş özelliği bekliyorsa, apache ışını pencereleme işlevleri bu özellikleri gerçek zamanlı (akış) olay verilerinin zaman pencerelerinin değerlerini toplamaya göre hesaplayabilir (örneğin, olaylar tıklayın). Dönüşümlerin ayrıntı düzeyinde daha önceki tartışmada, buna "eğitim sırasında tarihsel toplanmalar, ancak tahmin sırasında gerçek zamanlı kümeler" olarak adlandırıldı.

Aşağıdaki diyagram, Şekil 3, yakın gerçek zamanlı tahminler için akış verilerinin işlenmesinde veri akışının rolünü göstermektedir.

Şekil 3'te gösterildiği gibi, işleme sırasında, veri noktaları olarak adlandırılan olaylar Pub/Sub'a alınır. DataFlow bu veri noktalarını tüketir, zaman içinde agregalara dayalı özellikleri hesaplar ve daha sonra tahminler için dağıtılan ML Model API'sını çağırır. Tahminler daha sonra giden bir pub/alt kuyruğa gönderilir. Pub/Sub'dan, tahminler izleme veya kontrol gibi aşağı akış sistemleri tarafından tüketilebilir veya bunlar (örneğin bildirimler olarak) orijinal isteyen istemciye geri itilebilir. Tahminler, gerçek zamanlı getirme için Cloud BigTable gibi düşük gecikmeli bir veri deposunda da saklanabilir. Cloud Bigtable, bu gerçek zamanlı toplama biriktirmek ve saklamak için de kullanılabilir, böylece tahmin için gerektiğinde aranabilirler.

Aynı Apache Beam uygulaması, çevrimiçi tahminler sunmak için BigQuery ve Stream Pro-Process gerçek zamanlı veriler gibi çevrimdışı bir veri deposundan gelen eğitim verilerini toplu işleme için kullanılabilir.

Şekil 2'de gösterilen mimari gibi diğer tipik mimarilerde, istemci uygulaması doğrudan çevrimiçi tahminler için Dağıtım Model API'sını arar. Bu durumda, eğitim verilerini hazırlamak için veri akışında ön işleme işlemleri uygulanırsa, işlemler doğrudan modele giden tahmin verilerine uygulanmaz. Bu nedenle, bunlar gibi dönüşümler çevrimiçi tahminler için hizmet sırasında modele entegre edilmelidir.

DataFlow, gerekli istatistikleri ölçekte hesaplayarak tam geçiş dönüşümü gerçekleştirmek için kullanılabilir. Ancak, bu istatistiklerin tahmin sırasında tahmin veri noktalarını dönüştürmek için kullanılacak bir yerde saklanması gerekmektedir. Tensorflow dönüşümü ( tf.Transform ) kütüphanesini kullanarak, bu istatistikleri başka bir yerde saklamak yerine doğrudan modele yerleştirebilirsiniz. Bu yaklaşım daha sonra TF.Transform'un nasıl çalıştığı konusunda açıklanmaktadır.

Seçenek C: Tensorflow

Şekil 2'de gösterildiği gibi, tensorflow modelinin kendisinde veri ön işlem ve dönüşüm işlemlerini uygulayabilirsiniz. Şekilde gösterildiği gibi, tensorflow modelini eğitmek için uyguladığınız ön işleme, model tahminler için ihraç edildiğinde ve dağıtıldığında modelin ayrılmaz bir parçası haline gelir. Tensorflow modelindeki dönüşümler aşağıdaki yollardan biriyle gerçekleştirilebilir:

• input_fn işlevinde ve serving_fn işlevinde tüm örnek düzeyinde dönüşüm mantığının uygulanması. input_fn işlevi, bir model eğitmek için tf.data.Dataset API'sini kullanarak bir veri kümesi hazırlar. serving_fn işlevi, verileri tahminler için alır ve hazırlar.
• Keras ön işlem katmanlarını kullanarak veya özel katmanlar oluşturarak dönüşüm kodunu doğrudan tensorflow modelinize koymak.

serving_fn işlevindeki Dönüşüm Mantık Kodu, Çevrimiçi Tahmin için SavedModelinizin Servis Arabirimini tanımlar. serving_fn işlevinin Dönüşüm Mantık Kodunda eğitim verilerini hazırlamak için kullanılan aynı dönüşümleri uygularsanız, aynı dönüşümlerin sunulduğunda yeni tahmin veri noktalarına uygulanmasını sağlar.

Bununla birlikte, tensorflow modeli her veri noktasını bağımsız olarak veya küçük bir partide işlediğinden, tüm veri noktalarından toplama hesaplayamazsınız. Sonuç olarak, tensorflow modelinizde tam geçiş dönüşümleri uygulanamaz.

Önişleme zorlukları

Veri ön işlemlerinin uygulanmasının temel zorlukları aşağıdadır:

• Eğitim-hizmet eğrimi . Eğitim hizmeti eğrisi, eğitim sırasında ve servis sırasında etkinlik (öngörücü performans) arasındaki farkı ifade eder. Bu çarpıklık, eğitimdeki verileri nasıl ele aldığınız ile servis boru hatları arasında bir tutarsızlıktan kaynaklanabilir. Örneğin, modeliniz logaritmik olarak dönüştürülmüş bir özellik üzerinde eğitilmişse, ancak servis sırasında ham özellik sunulursa, tahmin çıkışı doğru olmayabilir.

  Dönüşümler modelin kendisinin bir parçası haline gelirse, Seçenek C: TensorFlow'da daha önce açıklandığı gibi, örnek düzeyinde dönüşümleri işlemek kolay olabilir. Bu durumda, model servis arayüzü ( serving_fn işlevi) ham veriler beklerken, model çıkışı hesaplamadan önce bu verileri dahili olarak dönüştürür. Dönüşümler, ham eğitim ve tahmin veri noktalarına uygulananlarla aynıdır.

• Tam geçiş dönüşümleri . 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.

Sırada ne var

• 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.

giriiş

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 intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

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

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

ML pipeline on Google Cloud

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

High-level architecture

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

The pipeline consists of the following steps:

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

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

Where to do preprocessing

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

Option A: BigQuery

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

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

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

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

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

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

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

Option B: Dataflow

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

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

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

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

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

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

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

Option C: TensorFlow

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

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

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

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

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

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

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

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

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

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

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

How tf.Transform works

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

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

Transform training and evaluation data

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

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

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

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

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

Attach transformations to the exported model

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

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

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

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

Preprocessing options summary

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

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

Sırada ne var

• 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 .