%%{init: {'theme': 'neutral', 'themeVariables': { 'edgeLabelBackground': '#ffffff' }}}%%
graph LR
A[Distribusi Fitur Latih Baseline] -->|Evaluasi Komparatif KS-Test| B{Drift Terdeteksi?}
C[Distribusi Fitur Produksi Baru] --> B
B -->|Ya: Kirim Alert & Pemicu Latih Ulang| D[Sistem retraining]
B -->|Tidak| E[Sistem Aman]
17 Sintesis: Merancang Pipeline & Prinsip yang Bertahan Lama
17.1 Kerangka Perancangan: Dari Tujuan Prediksi ke Pipeline Final
Rekayasa fitur tidak berdiri sendiri sebagai langkah terisolasi. Transformasi data yang rumit akan menjadi sia-sia jika tidak selaras dengan tujuan awal pemodelan. Kita memerlukan kerangka perancangan terstruktur untuk memastikan setiap keputusan memiliki pijakan konseptual yang kokoh. Kerangka ini memastikan pipeline dapat dieksekusi secara konsisten pada saat inference.
Tahap pertama yang menentukan adalah membangun tulang punggung masalah. Pada fase ini, kita belum menulis kode transformasi sama sekali. Kita berfokus merumuskan empat definisi dasar. Kesalahan pada tahap awal dapat memicu data leakage dan merusak seluruh validitas rekayasa fitur. Keempat definisi tersebut meliputi:
- Tujuan prediksi: Sasaran akhir yang ingin diselesaikan oleh model saat diterapkan di lingkungan produksi.
- Unit observasi: Representasi spesifik dari satu baris di dalam data pelatihan. Unit ini dapat berupa satu pelanggan, satu transaksi tunggal, atau pengukuran sensor per menit.
- Target: Label yang diprediksi beserta batas horizon waktunya.
- Strategi split: Cara pemisahan data untuk menyimulasikan kondisi inference seobjektif mungkin.
Setelah fondasi ditetapkan, perancangan bergerak ke tahap pengolahan data. Alur kerja ini mencakup langkah operasional yang dieksekusi secara berurutan:
- Pengumpulan sumber data: Menarik data historis yang tersedia secara sah sebelum titik prediksi.
- Transformasi: Mengubah data mentah menjadi representasi yang siap diproses oleh model.
- Seleksi: Membuang atribut yang redundan atau tidak relevan demi menjaga dimensi data tetap terkendali.
- Pembuatan baseline: Mengembangkan model sederhana sebagai pembanding utama sebelum menguji fitur-fitur yang lebih kompleks.
- Evaluasi: Menguji fitur baru terhadap baseline untuk mengukur peningkatan performa prediksi sekaligus memonitor stabilitasnya.
Satu elemen utama dalam perancangan ini adalah memastikan fitur yang dihasilkan stabil saat menghadapi data baru. Saat mengevaluasi fitur pada tahap baseline atau memantau data drift di lingkungan produksi, kita mengukur pergeseran distribusi antara data pelatihan dan data inference. Pengukuran stabilitas ini lazim menggunakan Population Stability Index (PSI). Secara matematis, metrik ini dihitung melalui persamaan berikut:
\[ PSI = \sum_{i=1}^{k} \left( P_{aktual, i} - P_{ekspektasi, i} \right) \times \ln \left( \frac{P_{aktual, i}}{P_{ekspektasi, i}} \right) \]
Di mana: * \(k\) mewakili jumlah kelompok (atau bin) dari variabel yang dievaluasi. * \(P_{aktual, i}\) menunjukkan proporsi sampel pada bin ke-\(i\) di dalam data aktual (inference). * \(P_{ekspektasi, i}\) menunjukkan proporsi sampel pada bin ke-\(i\) di dalam data yang diharapkan (pelatihan).
Sebagai contoh penerapan kerangka ini, mari kita tinjau sistem persetujuan kredit. Tujuannya adalah memprediksi risiko gagal bayar. Unit observasinya berupa aplikasi pinjaman individu, dan targetnya adalah kegagalan bayar dalam horizon dua belas bulan ke depan. Untuk menjaga praktik pipeline yang benar, strategi split yang paling valid adalah pemisahan temporal berdasarkan tanggal pengajuan aplikasi. Ketika struktur awal ini sudah solid, barulah fitur turunan direkayasa dari riwayat transaksi dan diuji terhadap baseline regresi logistik. Jika tahap desain awal keliru, tingkat PSI akan bergeser drastis saat produksi, dan rekayasa fitur sekompleks apa pun tidak akan mampu menyelamatkan performa model.
17.2 Konsistensi Pelatihan dan Inference: Mencegah Skew di Produksi
Sebuah pipeline machine learning pada dasarnya adalah kontrak komputasional. Kontrak ini menjamin bahwa distribusi dan logika kalkulasi fitur yang dilihat oleh model saat pelatihan (training) harus identik secara struktural dengan fitur yang masuk saat inference. Apabila kontrak ini tercederai, sistem akan menderita training-serving skew, yaitu degradasi performa model di lingkungan produksi akibat ketidakselarasan transformasi data.
Training-serving skew merupakan ancaman paling mematikan karena ia bersifat silent failure (gagal tanpa suara). Kode tidak akan meledak atau mengeluarkan pesan error, namun kualitas akurasi probabilitas merosot drastis. Fenomena ini sering dipicu oleh hal-hal operasional: * Insinyur perangkat lunak menulis ulang kueri Python eksperimen ke dalam bahasa Java/Go di backend dengan pembulatan yang berbeda. * Pelanggaran status fit/transform. (Sistem produksi menghitung rata-rata bergerak dari aliran data real-time alih-alih menggunakan konstanta pelatih historis yang dibekukan).
Pada praktik industri lampau, solusi standar untuk mencegah skew adalah membungkus seluruh tahap transformasi ke dalam satu objek (pipeline serialization) seperti modul pickle. Namun, pendekatan ini gagal menangani ekosistem skala raksasa yang mewajibkan komputasi silang-platform. Solusi definitif untuk tantangan ini terwujud dalam arsitektur Feature Store (seperti pustaka open-source Feast).
Berdasarkan hierarki kebutuhan yang dirumuskan oleh praktisi industri (Eugene Yan, 2021), sistem Feature Store menyediakan tingkat “Integritas” dengan memusatkan definisi fitur ke dalam satu basis kode dan membelah penyimpanan menjadi dua mesin sinkron: 1. Offline Store: Basis data pergudangan (seperti BigQuery atau Snowflake) yang dirancang secara optimal untuk ekstraksi batch besar data historis guna pelatihan model. 2. Online Store: Basis data kunci-nilai berlatensi sangat rendah (seperti Redis atau DynamoDB) yang menyajikan nilai fitur terbaru secara real-time kepada layanan inference.
%%{init: {'theme': 'neutral', 'themeVariables': { 'edgeLabelBackground': '#ffffff' }}}%%
graph TD
subgraph Ingesti ["Ingesti Log & Event"]
A[Sistem Database]
end
subgraph Feature_Store ["Sistem Feast"]
A -->|Batch ETL| Offline[Offline Store: Parquet/BigQuery]
A -->|Stream / Streaming| Online[Online Store: Redis]
end
subgraph ML_Services ["Konsumen Model"]
Offline -->|Train Silsilah Fitur Bebas Leakage| Train[Melatih Model ML]
Online -->|Latensi Rendah Real-time Retrieve| Serving[Aplikasi Inference]
end
Fungsi penting dari Feature Store adalah jaminan Point-in-Time Correctness (Time Travel). Ketika analis menarik miliaran baris data latih historis, sistem secara otomatis memastikan bahwa nilai fitur yang digabungkan (join) ke sebuah observasi adalah nilai yang eksis secara kronologis sesaat sebelum waktu kejadian. Hal ini melindungi pipeline dari kebocoran waktu (temporal leakage). Pada tahap inferensi, aplikasi backend cukup memanggil antarmuka seragam get_online_features() dengan menyetor ID Entitas (seperti ID Pelanggan), dan sistem akan merespons dengan vektor utuh tanpa memaksa tim backend mengulangi logika kalkulasi rekayasa. Pendekatan terpusat ini merupakan benteng terkuat komunitas machine learning untuk menghapus ilusi antara kehebatan laboratorium dengan ketangguhan dunia nyata.
17.3 Validasi Skema, Versioning Transformasi, dan Fenomena Drift
Stabilitas fitur di lingkungan produksi membutuhkan pengamanan teknis berlapis di luar kerangka arsitektur pipeline itu sendiri. Distribusi data riil bergerak dinamis seiring bergantinya waktu. Desain sistem analitik mutlak memfasilitasi tiga lapisan perlindungan operasional yang umumnya didukung oleh perkakas spesialis pihak ketiga: validasi skema, manajemen versi, dan pemantauan pergeseran.
Validasi Skema Berbasis Runtime Validasi skema memverifikasi keutuhan data mentah sebelum membiarkannya masuk ke mesin instruksi transformasi. Industri modern umumnya mengandalkan pustaka khusus seperti Pandera untuk menegakkan validasi statistik berlapis: * Tipe Data dan Kelengkapan: Sistem otomatis memblokir injeksi matriks jika mendeteksi anomali struktural akibat sistem hulu, seperti bergesernya struktur kolom numerik menjadi format teks (string). * Rentang Batas Wajar: Mesin mengetes nilai observasi terhadap limit batas ekspektasi, serta memvalidasi keselarasan entitas kategorikal terhadap kamus referensi guna menangkal intrusi dari label asing yang tak dikenal model.
Jika tumpukan data harian melanggar batasan validasi ini, proses akan ditolak (rejected) dan peringatan diaktifkan. Tanpa palang pintu ini, nilai pengamatan cacat akan meracuni pipeline dan memaksa model menghasilkan prediksi manipulatif.
Manajemen Versi (Data Version Control) Siklus komputasi rekayasa fitur secara rutin dimodifikasi seiring eksperimentasi. Seluruh berkas transformasi memerlukan kontrol manajemen versi (Data Version Control / DVC) yang mengikat jejak skrip rekayasa fitur dengan checkpoint modelnya. Fiksasi historis ini merupakan kunci untuk operasi pemulihan (rollback). Apabila probabilitas prediksi mendadak menyimpang di produksi, teknisi dapat langsung merestorasi status pipeline ke versi kode ekstraksi yang stabil.
Pemantauan Data Drift Data drift mendeskripsikan bergesernya sebaran distribusi atribut masukan produksi menjauhi distribusi sampel pelatihan aslinya. Pergeseran diam-diam ini mereduksi akurasi tanpa memicu peringatan error sama sekali. Simpangan ini dikalkulasi menggunakan ukuran geometri probabilitas matematis, di mana Population Stability Index (PSI) dan jarak Wasserstein menjadi standar pengukuran yang paling lazim digunakan. Secara formal, perhitungan PSI diformulasikan sebagai: \[ \text{PSI} = \sum_{i=1}^{B} \left( P_{\text{actual}, i} - P_{\text{expected}, i} \right) \times \ln \left( \frac{P_{\text{actual}, i}}{P_{\text{expected}, i}} \right) \] Di mana sebaran nilai numerik dibagi ke dalam \(B\) buah bin interval, \(P_{\text{actual}, i}\) melambangkan proporsi populasi data produksi pada interval ke-\(i\), dan \(P_{\text{expected}, i}\) mewakili persentase populasi dari distribusi data latih referensi pada interval yang identik. Ambang batas umum menetapkan bahwa jika PSI \(> 0.2\), maka drift yang terjadi bersifat masif dan wajib ditangani.
%%{init: {'theme': 'neutral', 'themeVariables': { 'edgeLabelBackground': '#ffffff' }}}%%
graph TD
A[Data Masuk] --> B(Batch: Diolah Berkala Tiap Malam - Latensi Tinggi)
A --> C(Streaming: Diolah Seketika via Kafka/Flink - Latensi Rendah)
Dalam memitigasi anomali ini, ekosistem pemantauan telah beralih pada pemanfaatan alat spesialis: * Evidently AI: Bekerja dominan pada deteksi pergeseran univariate (variabel tunggal), yang memberikan panel kontrol visual mengenai fitur apa yang nilai rata-rata populasinya paling parah terdistorsi. * NannyML: Menutup kelemahan utama dari pemantauan konvensional, yakni ketiadaan label ground truth di lingkungan produksi real-time. NannyML memelopori algoritma seperti Confidence-Based Performance Estimation (CBPE) dan Direct Loss Estimation (DLE). Algoritma tersebut secara matematis mengestimasi seberapa besar drift fitur saat ini telah menggerus performa prediksi riil model (seperti kejatuhan skor AUC), murni bermodalkan pergerakan fitur fitur input tanpa menunggu kedatangan label hasil observasi aslinya.
Saat degradasi terdeteksi, rantai mitigasi standar tidak menyarankan model langsung dimatikan. Praktisi harus memverifikasi apakah ini isu integritas mekanis (seperti disfungsi pemancar sensor) atau transformasi populasi organik. Bila terbukti pergeseran populasi riil, dan ambang degradasi (berdasarkan parameter NannyML) melewati toleransi komersial, pipeline kemudian dijadwalkan ulang untuk proses retraining parsial menggunakan irisan data termutakhir.
17.4 Kerangka Keputusan Lintas Tipe Data
Setiap tipe data menuntut perlakuan yang spesifik. Pemilihan teknik rekayasa fitur sangat bergantung pada modalitas data, batasan latensi saat inference, serta tingkat interpretasi yang disyaratkan oleh proyek. Kerangka keputusan lintas tipe data bertindak sebagai alat navigasi utama bagi perancang sebelum menyusun satu baris kode pun. Peta utuh dari panduan ini dapat ditelusuri pada Lampiran A.
Cabang pertama dalam pohon keputusan berawal dari kendala produksi. Merujuk pada pedoman pembingkaian masalah machine learning, perancang harus menetapkan target latensi prediksi sejak awal:
- Pemrosesan batch: Pendekatan untuk inferensi periodik dengan volume data masif dan toleransi waktu komputasi yang longgar.
- Pemrosesan streaming: Pendekatan untuk merespons permintaan secara seketika berdasarkan arus data waktu nyata.
Batasan arsitektur ini mendikte jenis fitur yang bisa diimplementasikan. Fitur agregasi kompleks yang mencakup riwayat transaksi sebulan penuh mungkin valid beroperasi pada sistem batch, tetapi memakan durasi komputasi yang terlalu lambat untuk melayani kebutuhan sistem streaming.
%%{init: {'theme': 'neutral', 'themeVariables': { 'edgeLabelBackground': '#ffffff' }}}%%
graph TD
subgraph Training_Time ["Waktu Pelatihan"]
A1[Data Historis Lengkap] --> B1[Fitur Agregat Mewah]
end
subgraph Serving_Time ["Waktu Produksi"]
A2[Inference Real-time] -->|Atribut Transaksi Baru Belum Tercatat di DB| B2[Fitur Kosong / Missing - Kegagalan Model]
end
Gambar 17.3 mengilustrasikan perbedaan jalur ekstraksi fitur dalam arsitektur sistem untuk memenuhi batasan waktu respons inference.
Setelah arsitektur dasar ditetapkan, kerangka keputusan membagi perlakuan fitur berdasarkan modalitas input:
- Data Tabular (Representasi yang Dirancang Manusia): Pemrosesan bertumpu pada manipulasi skala, reduksi kardinalitas, dan injeksi atribut interaksi antar kolom. Pendekatan ini membangun representasi eksplisit yang sangat transparan bagi keperluan audit bisnis. Transparansi ini sangat membantu saat sistem perlu melacak data drift. Evaluasi pergeseran distribusi populasi pada fitur tabular umumnya diukur melalui perhitungan Population Stability Index (PSI):
\[ PSI = \sum_{i=1}^{k} (A_i - E_i) \times \ln\left(\frac{A_i}{E_i}\right) \]
Di mana \(A_i\) mewakili proporsi sampel aktual pada bin ke-\(i\) saat inference, \(E_i\) mewakili proporsi ekspektasi dari kumpulan data latih, dan \(k\) adalah jumlah total bin. Atribut eksplisit rancangan manusia memungkinkan kalibrasi yang terarah ketika nilai PSI melewati batas aman.
Deret Waktu dan Spasial (Struktur dan Konteks): Kehadiran dimensi temporal atau koordinat lokasi mewajibkan perancang untuk berfokus pada isolasi konteks. Implementasi teknis membutuhkan aturan windowing ketat guna merekam riwayat historis tanpa terekspos kejadian masa depan. Pada area ini, penerapan praktik pipeline yang benar menjadi penangkal utama terhadap kebocoran data spesifik modalitas.
Teks, Citra, dan Audio (Representasi yang Dipelajari Mesin): Modalitas tidak terstruktur memaksa perancang untuk memotong jalur rekayasa manual. Sistem langsung mengandalkan vektor embedding berdensitas tinggi dari pretrained model. Beban kerja beralih dari merancang fitur individual menjadi menyusun arsitektur integrasi, memastikan gabungan representasi dari mesin saling melengkapi struktur prediksi akhir.
Kerangka keputusan ini memastikan sinkronisasi antara teknik komputasi dan aturan operasional di lapangan. Regulasi industri finansial yang menuntut rekam jejak audit penuh akan menolak embedding kotak hitam dan mengunci pilihan pada representasi rancangan manusia, meskipun pretrained model terbaru tersedia. Pemetaan arsitektur di awal mencegah perancang membangun sistem teknis yang pada akhirnya ditolak oleh lingkungan produksi.
17.5 Prinsip Dasar: Masalah, Ketersediaan, dan Aturan Split
Rekayasa fitur berawal dari pemahaman atas masalah operasional, bukan sekadar eksperimen algoritmik. Praktisi kerap menghabiskan waktu mencoba berbagai transformasi rumit pada data historis, padahal fitur yang kuat justru lahir dari pemahaman mendalam tentang mekanisme domain. Pendekatan berbasis masalah (problem-driven) memastikan setiap operasi komputasi terarah pada sinyal yang relevan dengan tujuan sistem.
Berikut adalah prinsip-prinsip yang harus dipenuhi saat merancang fitur untuk produksi:
17.5.1 Ketersediaan Data Saat Inference
Syarat teknis paling kaku dalam produksi adalah ketersediaan data pada saat prediksi berjalan (inference). Fitur wajib tersedia secara komputasional dan faktual pada detik model dipanggil. Metrik evaluasi yang tinggi di fase eksperimen tidak ada artinya jika bahan baku fitur tersebut mengalami hambatan latensi di produksi.
- Kasus Sinkronisasi Data: Model prediksi churn sering menggunakan fitur waktu interaksi terakhir (last login date). Jika saluran data menyinkronkan log interaksi setiap 24 jam sekali pada tengah malam, fitur tersebut akan usang saat model mengeksekusi prediksi di siang hari.
- Risiko Training-Serving Skew: Perbedaan jalur ketersediaan data antara lingkungan eksperimen (tersedia semua) dan produksi (tersedia sebagian atau tertunda) menyebabkan model menerima distribusi data yang berbeda saat bekerja di lapangan.
%%{init: {'theme': 'neutral', 'themeVariables': { 'edgeLabelBackground': '#ffffff' }}}%%
graph LR
Img[Foto Produk] -->|ResNet Extractor| Embedding[Vektor Laten Visual]
Tab[Teks Metadata] -->|One-Hot Scaler| Tabular[Fitur Tabular]
Embedding --> Cat[Concatenate Layer]
Tabular --> Cat
Cat --> MLP[Model Klasifikasi Cacat Produk]
Untuk mendeteksi seberapa jauh pergeseran distribusi yang terjadi akibat perbedaan fase ini, kita dapat mengukur Population Stability Index (PSI):
\[ PSI = \sum_{i=1}^{k} \left( P_{inference,i} - P_{train,i} \right) \ln \left( \frac{P_{inference,i}}{P_{train,i}} \right) \]
Di mana: * \(k\) adalah jumlah partisi (bin) dari suatu fitur. * \(P_{inference,i}\) adalah proporsi sampel pada bin ke-\(i\) di lingkungan produksi. * \(P_{train,i}\) adalah proporsi sampel pada bin ke-\(i\) di set pelatihan.
Nilai PSI di atas 0,2 menandakan pergeseran populasi atau skew yang besar. Jika ini terjadi, desain ketersediaan fitur tersebut perlu dievaluasi ulang.
17.5.2 Transformasi Selalu Mengikuti Split
Validitas evaluasi menuntut agar semua transformasi data dilakukan setelah penerapan strategi pemisahan (split). Praktik pipeline yang benar mengatur urutan operasi sebagai berikut:
- Estimasi Parameter pada Data Latih: Operasi penyusunan fitur (seperti perhitungan rata-rata untuk imputasi, penyesuaian skala, atau target encoding) harus dihitung murni menggunakan observasi dari set pelatihan.
- Pembekuan Transformer: Parameter transformasi yang telah diperoleh kemudian dibekukan dan dipakai apa adanya untuk mentransformasi set pengujian.
- Pencegahan Data Leakage: Jika kalkulasi beroperasi pada keseluruhan dataset sebelum pemisahan, distribusi set pengujian akan ikut terhitung ke dalam parameter transformasi. Kebocoran ini menghasilkan akurasi palsu yang terlihat tinggi saat eksperimen namun anjlok saat produksi.
17.5.3 Keamanan Operasional dan Fitur Proxy
Melanjutkan prinsip privasi dari Bab 9, fakta bahwa sebuah atribut menaikkan akurasi prediksi tidak otomatis membuatnya boleh dipakai. Sistem harus dibangun dengan batas keamanan operasional agar tidak mengeksploitasi atribut yang dilindungi.
- Penghapusan Atribut Sensitif: Variabel demografi atau data pribadi yang dilindungi wajib dibuang dari pipeline pemodelan.
- Bahaya Fitur Proxy: Model amat rentan menyerap fitur proxy, yaitu atribut yang terkesan netral namun berkorelasi kuat dengan variabel sensitif. Misalnya, atribut “kode pos domisili” atau “rute pengiriman harian” sering kali menyimpan profil status sosial-ekonomi secara terselubung.
- Mengunci Bias Historis: Membiarkan sistem mengakses variabel proxy sama dengan menginstruksikan model untuk mempelajari dan mereplikasi bias historis yang sudah berurat akar pada data mentah.
17.6 Prinsip Dasar Bagian II: Validasi, Sinergi Representasi, dan Arah ke Depan
Menambahkan ratusan atribut baru ke dalam dataset sering dianggap sebagai metode cepat untuk meningkatkan akurasi. Namun, penambahan variabel tanpa dasar keilmuan justru memperbesar risiko overfitting, di mana model menghafal noise dari data pelatihan. Sistem prediksi yang andal selalu dibangun dari stabilitas fitur yang teruji melalui skema validasi silang yang ketat, bukan sekadar dari lonjakan dimensi matriks.
Buku ini telah mengeksplorasi spektrum pemrosesan data yang membentang luas, dari representasi yang dirancang manusia di satu sisi, hingga representasi yang dipelajari mesin di sisi lain. Kedua pendekatan tersebut tidak dirancang untuk saling berkompetisi. Sinergi keduanya justru bekerja maksimal saat diimplementasikan pada sistem prediksi berarsitektur hibrida. Algoritma deep learning menangani beban ekstraksi pola rumit dari data tidak terstruktur, sementara tenaga ahli mengamankan pemahaman konteks logis melalui variabel tabular konvensional.
Integrasi kedua spektrum tersebut diformulasikan secara matematis melalui teknik penggabungan matriks representasi:
\[ \mathbf{x}_{final} = \big[ \phi_{learned}(\mathbf{x}_{unstructured}) \parallel \phi_{designed}(\mathbf{x}_{tabular}) \big] \]
Di mana: * \(\mathbf{x}_{final}\) adalah vektor fitur gabungan yang diteruskan ke layer model prediktif akhir. * \(\phi_{learned}\) adalah fungsi ekstraksi otomatis (misalnya pretrained model jaringan saraf) yang memproses input non-tabular \(\mathbf{x}_{unstructured}\) (contoh: matriks piksel citra sinar-X). * \(\phi_{designed}\) adalah fungsi transformasi manual berbasis keilmuan yang memproses atribut terstruktur \(\mathbf{x}_{tabular}\) (contoh: rentang kategori usia atau riwayat penyakit). * \(\parallel\) menandakan operator konkatenasi untuk menyatukan kedua bentuk vektor.
%%{init: {'theme': 'neutral', 'themeVariables': { 'edgeLabelBackground': '#ffffff' }}}%%
graph TD
subgraph Ritel_System ["Sistem Peramalan Ritel Temporal"]
A1[Data Penjualan] --> B1[Feature Lag & Rolling Window]
B1 --> C1[Model XGBoost Forecasting]
end
subgraph Medis_System ["Sistem Multimodal Medis"]
A2[Rekam Medis Tabular] --> D2[Concatenate Layer]
B2[Citra Rontgen Paru] -->|CNN Extractor| D2
D2 --> E2[Model Jaringan Neural Prediksi Patologi]
end
Validasi simultan terhadap \(\mathbf{x}_{final}\) menjamin model belajar membedakan pola general yang sesungguhnya. Model tercegah dari sekadar menghafal temuan individu karena dikunci oleh batasan fisik yang diatur oleh logika representasi desain manusia.
Masa depan rekayasa fitur bertumpu penuh pada kolaborasi antara komputasi mesin dan evaluasi rasional manusia. Walaupun perangkat otomasi AutoFE sanggup memproduksi usulan transformasi dalam hitungan detik, ekuilibrium operasional tetap mengandalkan pembagian tugas yang definitif:
- Tugas Mesin: Menemukan pola laten berskala besar, memproses input data dimensi tinggi, serta membuat kombinasi iterasi turunan atribut secara komprehensif tanpa henti.
- Tugas Manusia: Memverifikasi kewajaran logis dari penambahan atribut, mendeteksi jalur jebakan data leakage di level operasional, dan menakar beban latensi komputasi terhadap efisiensi infrastruktur.
Mesin berekspansi sebagai fasilitator hipotesis representasi, sedangkan kepakaran manusia bertindak sebagai pengawas gerbang validasi akhir.
17.7 Studi Kasus: Merancang Pipeline dari Nol untuk Berbagai Skenario
Kita akan merancang dua pipeline dari nol untuk mendemonstrasikan bagaimana jenis data dan rumusan masalah memandu penentuan unit observasi hingga pemilihan representasi.
17.7.1 Skenario Pertama: Peramalan Permintaan Ritel
Sebuah jaringan swalayan memprediksi volume penjualan untuk mengatur stok barang. Desain pipeline untuk masalah ini dibangun dengan spesifikasi berikut:
- Unit observasi dan target: Kombinasi spesifik antara toko, produk, dan minggu. Target prediksinya adalah volume penjualan pada minggu \(T+1\).
- Strategi pembagian data (split): Prediksi bergantungan pada waktu, sehingga pembagian data menaati kronologi secara ketat. Pemisahan temporal menyisihkan blok minggu terakhir khusus untuk pengujian guna menyimulasikan kondisi di lingkungan produksi.
- Ekstraksi fitur: Data tabular membutuhkan jendela waktu (windowing) terstruktur. Contoh representasinya adalah nilai rata-rata historis (rolling average) dari minggu \(T-1\) hingga \(T-4\).
- Pencegahan leakage: Perhitungan fitur tidak boleh menyertakan informasi dari target di minggu \(T+1\). Praktik pipeline yang benar wajib diterapkan sejak awal pembentukan sampel pembelajaran demi menghindari look-ahead leakage.
Setelah pipeline fitur ritel beroperasi di produksi, stabilitas datanya perlu dipantau. Metrik yang lazim dipakai untuk mendeteksi data drift adalah Population Stability Index (PSI):
\[ \text{PSI} = \sum_{i=1}^{k} (A_i - E_i) \times \ln\left(\frac{A_i}{E_i}\right) \]
Di mana: * \(k\) adalah jumlah kategori atau bin pembagian fitur numerik. * \(A_i\) adalah proporsi observasi pada bin \(i\) saat data masuk fase produksi (inference). * \(E_i\) adalah proporsi observasi pada bin \(i\) saat data berada di fase pelatihan (training).
Pergeseran skor PSI yang tinggi menandakan bahwa distribusi fitur telah berubah dan siklus pelatihan ulang kemungkinan diperlukan.
17.7.2 Skenario Kedua: Diagnosis Medis Multimodal
Skenario kedua melibatkan klasifikasi tingkat keparahan penyakit paru-paru berdasarkan data rumah sakit. Karakteristik perancangan arsitektur multimodal ini meliputi:
- Unit observasi: Satu sesi pemeriksaan pasien individual tanpa horizon waktu prediktif ke depan.
- Strategi split: Pemisahan data diacak, namun seluruh rekam medis dari satu pasien harus selalu masuk ke blok split yang sama. Ini membatasi model agar tidak sekadar menghafal karakteristik individu pasien.
- Pemrosesan citra: Citra sinar-X melewati augmentasi dan masuk ke pretrained model jaringan konvolusional (CNN). Model ini sengaja dibekukan untuk mengabdi sebagai ekstraktor fitur yang memproduksi vektor embedding. Bagian ini memakai representasi yang dipelajari mesin.
- Pemrosesan tabular: Hasil tes darah dan sensor numerik diproses terpisah. Fitur-fitur tersebut diimputasi lalu diseragamkan dengan metode robust scaling.
- Penggabungan (fusion): Aliran embedding citra dan aliran fitur tabular digabungkan secara internal sebelum masuk lapisan klasifikasi akhir.
[GAMBAR 17.6: Skema - Arsitektur dua sistem prediktif berdampingan: pipeline forecasting ritel temporal di sisi kiri dan arsitektur hybrid multimodal medis di sisi kanan]
Implementasi kode transformasi merupakan tahapan teknis penutup. Ketepatan dalam merumuskan unit observasi, mengatur logika split pengujian, serta menyatukan ragam bentuk representasi adalah pondasi sejati dari pembangunan sistem prediktif yang berhasil.
import numpy as np
import pandas as pd
from sklearn.base import BaseEstimator, TransformerMixin
from sklearn.pipeline import Pipeline, FeatureUnion
from sklearn.preprocessing import RobustScaler
from sklearn.impute import SimpleImputer
from sklearn.decomposition import PCA
from sklearn.ensemble import RandomForestClassifier
# 1. Transformer kustom untuk melakukan pemilihan (seleksi) kolom spesifik
class ColumnSelector(BaseEstimator, TransformerMixin):
def __init__(self, columns):
self.columns = columns
def fit(self, X, y=None):
return self
def transform(self, X):
return pd.DataFrame(X)[self.columns].values
# 2. Simulasi Dataset Medis: Gabungan data tabular & embedding citra rontgen
np.random.seed(42)
df_medis = pd.DataFrame({
'tensi_darah': np.random.normal(120.0, 15.0, 100),
'kadar_hemoglobin': np.random.normal(14.0, 2.0, 100),
'img_feat_1': np.random.normal(0.0, 1.0, 100),
'img_feat_2': np.random.normal(0.0, 1.0, 100)
})
df_medis.iloc[10:20, 0] = np.nan # Sisipkan nilai kosong
y_diagnosis = np.random.randint(0, 2, size=100)
# 3. Aliran pemrosesan fitur tabular numerik
tabular_flow = Pipeline([
('select_tab', ColumnSelector(columns=['tensi_darah', 'kadar_hemoglobin'])),
('impute', SimpleImputer(strategy='median')),
('scale', RobustScaler())
])
# 4. Aliran pemrosesan fitur embedding citra (pre-extracted CNN)
image_flow = Pipeline([
('select_img', ColumnSelector(columns=['img_feat_1', 'img_feat_2'])),
('pca', PCA(n_components=1, random_state=42))
])
# 5. Peleburan (fusion) fitur secara paralel menggunakan FeatureUnion
fusion_layer = FeatureUnion([
('tab_pipeline', tabular_flow),
('img_pipeline', image_flow)
])
# 6. Merangkai pipeline utama tingkat tinggi secara menyeluruh
main_pipeline = Pipeline([
('union', fusion_layer),
('classifier', RandomForestClassifier(random_state=42))
])
# 7. Menjalankan proses fitting terintegrasi
main_pipeline.fit(df_medis, y_diagnosis)
# Verifikasi dimensi output hasil gabungan
features_transformed = fusion_layer.fit_transform(df_medis)
print(f"Dimensi data masukan awal : {df_medis.shape}")
print(f"Dimensi fitur gabungan akhir: {features_transformed.shape}")
print("Status: Arsitektur Pipeline FeatureUnion berhasil dieksekusi.")