Machine learning engineer
Machine learning engineer memperlakukan sebuah model sebagai sistem yang berjalan, bukan sebagai hasil akhir: pipeline yang memproduksinya, feature yang memberinya masukan, service yang menjawab request, dan pemantauan yang menyadari bahwa dunia sudah bergeser sementara modelnya belum. Model yang skornya bagus di sebuah notebook barulah permulaan pekerjaannya. Panduan ini menjelaskan disiplin tersebut dan cara menilainya.
Apa yang dikerjakan seorang machine learning engineer?
Machine learning engineer membangun, melatih, men-deploy, dan memelihara model prediktif di production. Cakupannya meliputi menyiapkan dan merekayasa feature yang dikonsumsi model, menjalankan pipeline pelatihan yang bisa direproduksi, melacak dan membandingkan eksperimen, memberi versi dan mendaftarkan artefak model, men-deploy-nya di balik antarmuka serving yang memenuhi anggaran latensi, serta memantau pergeseran data dan perilaku yang menggerus akurasi seiring waktu. Bagian yang paling menentukan dari peran ini adalah segala hal yang terjadi setelah skor offline pertama yang bagus: pengemasan, kesetaraan perhitungan, biaya, observability, rollback, dan pelatihan ulang.
Bug production yang khas di bidang ini adalah ketidakcocokan antara cara sebuah nilai dihitung saat pelatihan dan cara ia dihitung ketika sebuah request datang. Feature yang diturunkan dari tabel historis lengkap di sebuah batch job, lalu dihitung ulang saat request dari data yang belum lengkap atau dengan definisi yang sedikit berbeda, menghasilkan model yang tervalidasi dengan indah namun berkinerja buruk di lapangan. Kode transformasi bersama dan feature store terutama ada untuk menutup jurang itu, dan engineer yang belum pernah tertimpa masalah ini cenderung meremehkannya.
Tuntutan reproduksibilitas di sini lebih berat daripada di perangkat lunak biasa, karena sebuah artefak model adalah fungsi dari kode, data pelatihan, hyperparameter, random seed, dan versi library sekaligus. Membangun ulang artefak tertentu yang sudah ter-deploy berbulan-bulan kemudian adalah tuntutan audit di sektor yang diatur regulasi dan tuntutan penanganan insiden di tempat lain, dan itu hanya mungkin bila datanya diberi versi berdampingan dengan kodenya, bukan sekadar diceritakan di pesan commit.
Model juga meluruh meski tidak ada yang berubah. Perangkat lunak yang dibiarkan akan berperilaku sama tahun depan; model yang dibiarkan justru terus memburuk, karena populasi yang ia nilai menjauh dari populasi yang ia pelajari, dan kadang karena hubungan yang ia rekam memang sudah tidak berlaku lagi. Memutuskan apa yang dipantau, ambang mana yang seharusnya memicu pembangunan ulang, dan apakah pembangunan ulang langsung dirilis atau menunggu persetujuan adalah tanggung jawab permanen, bukan sebuah fase proyek.
Kapan tim membutuhkan kapabilitas ini
Banyak sekali pekerjaan pemodelan mandek persis di titik ketika ia harus keluar dari laptop. Berikut tekanan yang biasanya membuat engineer khusus untuk lapisan ini layak dibiayai.
Model yang menjanjikan tidak punya jalan keluar
Ia berkinerja bagus di notebook dan tidak ada jalur menuju penyajian request. Pengemasan, penguncian dependency, anggaran latensi, kesetaraan feature, batching, autoscaling, dan skenario rollback semuanya belum ada, dan setiap satunya asing bagi orang yang membangun modelnya.
Prediksi diam-diam menjadi kurang akurat
Tidak ada yang mendapat peringatan, karena tidak ada yang gagal. Penurunannya muncul lewat metrik komersial yang bergerak atau tim operasi yang kehilangan kepercayaan, yang berarti hal itu sudah berlangsung cukup lama sebelum ada yang memeriksanya.
Pelatihan ulang menjadi ritual manual
Satu orang, serangkaian langkah yang tercatat di suatu tempat, dan satu minggu kerja yang lenyap. Rapuh, tidak terdokumentasi di tempat yang penting, dan berhenti total ketika orang tersebut berhalangan.
Eksperimen tidak bisa dibandingkan atau diulang
Hasil tersimpan sebagai tangkapan layar dan utas percakapan, beberapa varian memakai nama file yang sama, dan tak seorang pun bisa menyatakan dengan yakin dataset dan parameter mana yang menghasilkan artefak yang sedang melayani trafik.
Inference berubah menjadi kendala biaya atau latensi
Pengeluaran untuk akselerator mendominasi tagihan infrastruktur, atau anggaran waktu respons tak sanggup menampung modelnya. Semua langkah yang tersedia — batching, kuantisasi, distilasi, caching, arsitektur yang lebih kecil — menukar akurasi dengan ekonomi, dan menuntut orang yang bisa mengukur pertukaran itu.
Kewajiban audit atau regulasi mulai berlaku
Kini ada yang harus membuktikan data mana yang melatih model yang ter-deploy, siapa yang menyetujuinya, bagaimana kinerjanya pada kelompok yang terdampak, dan bagaimana satu keputusan bisa dijelaskan. Menyusun ulang semua itu belakangan jauh lebih berat daripada mencatatnya sambil berjalan.
Kapabilitas inti
Feature engineering dan kesetaraan perhitungan
Menyusun input yang dipelajari sebuah model, dan menjamin bahwa perhitungan yang persis sama berjalan ketika sebuah prediksi diminta. Kesetaraan itu diverifikasi sebagai bagian dari deployment, bukan diandaikan dari niat yang sama-sama dipahami.
Pipeline pelatihan yang bisa direproduksi
Berparameter, terjadwal, berversi dari ujung ke ujung, dengan data pelatihan yang dikunci sekuat kodenya. Menjalankan ulang konfigurasi kuartal lalu semestinya menghasilkan artefak kuartal lalu, bukan pendekatannya.
Pelacakan eksperimen
Mencatat konfigurasi, dataset, metrik, dan artefak agar varian bisa dibandingkan secara jujur dan sebuah hasil bisa dipertanggungjawabkan berminggu-minggu kemudian tanpa bergantung pada ingatan siapa pun.
Evaluasi dan pemilihan metrik
Memilih ukuran yang mencerminkan keputusan yang ditopang model tersebut, memahami kalibrasi sebagai hal yang berbeda dari kualitas pemeringkatan, menangani ketimpangan kelas, dan menetapkan ambang berdasarkan perbedaan ongkos tiap jenis kesalahan.
Registry model dan promosi
Artefak berversi dengan garis keturunan yang tersambung ke proses pelatihan yang persis menghasilkannya, jalur yang jelas dari kandidat menuju serving, dan kemampuan kembali ke artefak sebelumnya dengan cepat ketika sebuah rilis berjalan buruk.
Serving dan inference
Endpoint real-time, batch scoring, streaming scoring, batching request, utilisasi akselerator, dan keputusan arsitektur yang menjaga persentil sembilan puluh lima tetap di dalam anggarannya ketika banyak permintaan datang bersamaan.
Deteksi drift dan pelatihan ulang
Mengamati distribusi input di samping outputnya, memisahkan perubahan pada populasi dari perubahan pada hubungan yang mendasarinya, serta menetapkan apa yang memicu pembangunan ulang, apa yang menjadi gerbangnya, dan siapa yang menyetujuinya.
Pelatihan terdistribusi dan berakselerasi
Paralelisme data dan model, penganggaran memori, checkpoint yang selamat dari instance yang terputus, serta ekonomi praktis antara kapasitas yang dipesan dan kapasitas yang bisa dihentikan sewaktu-waktu.
Adaptasi model yang sudah ada
Menilai kapan transfer learning atau tuning hemat parameter atas model yang sudah dipublikasikan mengalahkan pelatihan dari nol, dan apa implikasi pilihan itu terhadap lisensi, reproduksibilitas, serta besarnya dataset yang benar-benar dibutuhkan.
Deployment yang bertanggung jawab
Mengukur kinerja pada tiap kelompok yang terdampak alih-alih hanya secara agregat, menyediakan penjelasan ketika sebuah keputusan menyangkut individu, menjalankan shadow deployment sebelum trafik sungguhan, dan menyediakan jalur tinjauan manusia ketika taruhannya menuntut demikian.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam machine learning engineering. Daftar ini menggambarkan lanskap disiplin tersebut sebagaimana dipraktikkan secara umum di industri, dan bukan klaim tentang perkakas engineer mana pun. Stack serving dan produk orkestrasi jauh lebih sering berganti dibanding praktik yang mendasarinya, sehingga kefasihan pada salah satunya jauh lebih lemah memprediksi dibanding pengalaman menjaga sebuah model tetap bekerja.
Bahasa
- Python
- SQL
- Scala
- C++
Framework pemodelan
- PyTorch
- TensorFlow
- JAX
- scikit-learn
- XGBoost
- LightGBM
Orkestrasi pelatihan dan workflow
- Kubeflow
- Metaflow
- Ray
- Apache Airflow
- Amazon SageMaker
- Google Vertex AI
Pelacakan dan registry
- MLflow
- Weights & Biases
- Neptune
- DVC
Pengelolaan feature
- Feast
- Tecton
- Delta Lake
- Apache Parquet
Serving dan inference
- NVIDIA Triton
- TorchServe
- BentoML
- KServe
- ONNX Runtime
- TensorRT
Pemantauan
- Evidently
- Arize
- WhyLabs
- Prometheus
- Grafana
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Talent.ID handles
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Apa yang perlu dinilai saat memilih kandidat
Kualitas model adalah topik paling mudah dibicarakan seorang kandidat sekaligus termasuk dasar paling tidak berguna untuk mengambil keputusan. Skor offline yang bagus itu syarat minimum; pekerjaan yang sebenarnya adalah engineering yang menjaga model tetap akurat, terjangkau, bisa direproduksi, dan bisa dibalikkan dua tahun kemudian. Gali bagian-bagian yang baru ada setelah sesuatu benar-benar melayani trafik.
Pengalaman dengan model di production
Tanyakan apa yang pernah mereka deploy dan benar-benar melayani request sungguhan, lalu apa yang pertama kali rusak. Kandidat yang pengalamannya berupa kompetisi dan tugas kuliah akan bercerita tentang optimisasi; kandidat yang pernah mengoperasikan model akan bercerita tentang sebuah insiden, sebuah rollback, dan celah pemantauan yang kemudian mereka tutup.
- Pernah membawa sebuah model melewati rilis sekaligus melewati pembatalan rilis itu
- Bisa menyebut hal pertama yang rusak dan mengapa itu tidak terantisipasi
- Berbicara tentang pihak yang mengonsumsi prediksinya, bukan hanya tentang skornya
- Pernah memensiunkan sebuah model, bukan hanya meluncurkannya
Kebiasaan menjaga reproduksibilitas
Pastikan apakah mereka sanggup membangun ulang sebuah artefak tertentu. Di sinilah praktik paling tajam menyimpang dari prinsip yang diucapkan, dan pertanyaan lanjutannya — apa persisnya yang diberi versi — lebih menyingkap daripada pertanyaan pertamanya.
- Memberi versi pada data pelatihan berdampingan dengan kode dan konfigurasinya
- Mencatat seed, versi library, dan perangkat keras di tempat hasilnya bergantung pada itu
- Menjaga garis keturunan dari artefak yang melayani kembali ke proses yang menghasilkannya
- Benar-benar pernah membangun ulang model lama, bukan sekadar merasa mampu melakukannya
Pertimbangan dalam memilih metrik
Tanyakan mengapa mereka memilih ukuran yang mereka optimalkan. Jawaban yang lemah menyebut metrik apa pun yang secara bawaan dilaporkan library. Jawaban yang kuat menghubungkan ukuran itu dengan keputusan yang ditopang prediksinya dan dengan ongkos yang ditanggung bisnis untuk tiap jenis kesalahan.
- Menolak akurasi mentah ketika kelasnya sangat timpang
- Memahami kalibrasi dan kapan estimasi probabilitas harus benar-benar bisa dipercaya
- Menetapkan ambang dari perbandingan ongkos false positive dan false negative
- Mengharapkan angka offline melebih-lebihkan kinerja sesungguhnya dan bisa menjelaskan mengapa
Konsistensi antara pelatihan dan serving
Kandidat yang pernah tersandung soal ini akan mengangkatnya tanpa diminta. Tanyakan bagaimana sebuah feature dihitung di masing-masing jalur dan dari mana mereka tahu keduanya cocok, lalu tanyakan apakah mereka pernah menemukan keduanya berbeda di production.
- Berbagi kode transformasi di kedua jalur alih-alih menulisnya dua kali
- Pernah mendiagnosis cacat skew dan bisa menceritakan bagaimana ia menampakkan diri
- Memvalidasi kesetaraan sebagai gerbang deployment, bukan sebagai tinjauan berkala
- Bisa menjelaskan apa yang diselesaikan sebuah feature store dan apa yang tidak
Pemeliharaan dan drift
Tanyakan apa yang mereka pantau dan apa yang mereka lakukan ketika angkanya bergerak. Jawaban yang paling menarik sering kali berupa kasus ketika mereka menyelidiki drift lalu menyimpulkan bahwa pelatihan ulang justru bukan responsnya, dan itu menuntut pemahaman atas penyebabnya alih-alih reaksi terhadap sebuah ambang.
- Memantau distribusi input di samping distribusi prediksinya
- Memisahkan populasi yang bergeser dari hubungan yang berubah
- Punya pemicu yang jelas untuk membangun ulang, bukan hanya penanggalan
- Pernah menolak melakukan pelatihan ulang dengan alasan yang bisa ia jelaskan
Ekonomi inference
Tanyakan berapa biaya seribu prediksi dan dari mana mereka tahu. Engineer yang pernah memikul tagihannya menjawab seketika dan bisa menyebut tuas-tuasnya; yang belum pernah menganggap serving sebagai detail yang sudah beres dan diurus orang lain.
- Tahu biaya per prediksi dari sesuatu yang pernah ia operasikan
- Pernah menerapkan batching, kuantisasi, atau distilasi dan mengukur pertukaran akurasinya
- Pernah benar-benar memeriksa utilisasi akselerator alih-alih mengandaikannya
- Bisa menceritakan kapan model yang lebih sederhana justru pilihan komersial yang lebih baik
Menahan diri soal pemodelan
Engineer yang paling berguna di bidang ini setidaknya sekali pernah mengganti sebuah model dengan aturan biasa. Tanyakan baseline apa yang mereka pakai sebagai pembanding, dan apakah pernah ada model yang gagal mengunggulinya cukup jauh untuk membenarkan ongkos pemeliharaannya.
- Menetapkan baseline sederhana sebelum mengusulkan sebuah arsitektur
- Menimbang ongkos pemeliharaan berkelanjutan terhadap perbaikan yang ditawarkan
- Menanyakan keputusan mana yang berubah sebagai akibat dari prediksi itu
- Pernah menyarankan untuk tidak memakai model yang diinginkan seseorang yang lebih senior
Pertanyaan wawancara yang layak diajukan
Semua ini milik proses seleksi Anda sendiri dan bukan milik siapa pun yang lain. Anda yang menjalankan penilaian dan menarik kesimpulannya; pertanyaan berikut sekadar yang biasanya memindahkan percakapan keluar dari notebook menuju sistem yang harus mengelilinginya.
Sebuah model yang sudah ter-deploy berkinerja lebih buruk dibanding saat evaluasi. Apa saja penjelasan yang mungkin, dan dalam urutan apa Anda akan memeriksanya?
What a strong answer shows
Struktur berpikir diagnostik. Harapkan pembahasan soal perhitungan feature yang berbeda antar jalur, kebocoran data yang menggelembungkan angka offline, populasi input yang bergeser, label yang datang terlalu lambat untuk dipercaya, dan pembagian data evaluasi yang mengabaikan urutan waktu.
Bagaimana Anda menangkap cacat kesetaraan feature sebelum ia sampai ke pelanggan?
What a strong answer shows
Apakah verifikasinya otomatis atau sekadar cita-cita. Jawaban yang kuat membandingkan nilai yang dihitung kedua jalur pada record yang sama sebagai gerbang rilis, lalu memasang alert atas penyimpangan sesudahnya.
Jelaskan strategi pelatihan ulang untuk sesuatu yang pernah Anda jalankan. Apa pemicunya dan siapa yang menyetujui hasilnya?
What a strong answer shows
Kematangan operasional. Cari pemicu yang berbasis pemantauan alih-alih jadwal tetap, gerbang evaluasi yang harus dilewati model kandidat, dan kejelasan soal apakah promosinya otomatis atau menuntut keputusan manusia.
Anda mewarisi sebuah model tanpa dokumentasi. Apa yang pertama Anda pastikan?
What a strong answer shows
Penentuan prioritas dalam ketidakpastian. Urutan yang berguna adalah: keputusan apa yang ia topang, apa yang saat ini ia capai terhadap baseline yang terukur, data mana yang melatihnya, dan apakah artefaknya masih bisa dibangun ulang sama sekali.
Ceritakan masalah kebocoran data yang pernah Anda temukan. Bagaimana ia terungkap?
What a strong answer shows
Pengalaman nyata dengan hasil yang terlalu bagus untuk jadi kenyataan. Dengarkan soal feature yang ternyata mengandung hasilnya, pembagian data yang mengabaikan urutan waktu, atau preprocessing yang di-fit ke seluruh dataset sebelum pembagian dilakukan.
Inference kini menjadi pos terbesar di tagihan infrastruktur. Apa saja pilihannya dan apa ongkos masing-masing bagi Anda?
What a strong answer shows
Kesediaan menukar akurasi dengan ekonomi secara sadar. Harapkan pembahasan batching, arsitektur yang lebih kecil, kuantisasi, distilasi, caching input yang berulang, serta pernyataan terukur tentang berapa ongkos kualitas dari tiap pilihan.
Kapan model yang lebih sederhana mengalahkan yang lebih canggih, dan bagaimana Anda memutuskannya?
What a strong answer shows
Pertimbangan engineering yang mengalahkan preferensi teknis. Jawaban terkuat menimbang keuntungan marginalnya terhadap pemeliharaan, latensi, keterjelasan, dan jumlah orang yang sanggup menopangnya.
Bagaimana Anda mengevaluasi perilaku sebuah model pada kelompok pengguna yang berbeda-beda?
What a strong answer shows
Apakah kinerja agregat dianggap sudah cukup. Cari pengukuran pada tingkat kelompok, kesadaran bahwa akurasi keseluruhan menyembunyikan perilaku yang tidak merata, serta sikap yang matang tentang apa yang harus dilakukan ketika muncul kesenjangan.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- Beberapa model sedang melayani trafik production, masing-masing dipelihara secara informal oleh siapa pun yang dulu membangunnya. Pelatihan ulang dilakukan manual, artefak di dalam registry tidak bisa ditelusuri kembali ke proses yang menghasilkannya, dan sebuah keluhan akurasi belakangan ini sulit ditelusuri sumbernya karena tidak ada satu pun catatan tentang distribusi inputnya.
- Approach
- Kapasitas engineering tambahan bekerja di dalam praktik yang sudah mapan di tim — repositori mereka, konvensi review mereka, proses deployment mereka, dan arah teknis yang sudah mereka tetapkan. Prioritas produk dan kewenangan arsitektural tetap pada tim internal; kapasitas tambahan mengerjakan tugas pipeline, registry, dan pemantauan berdampingan dengan mereka.
- What this adds to the team
- Tim menambah kapasitas kerja tanpa menyerahkan kepemilikan atas model maupun keputusan platformnya. Apa yang dibangun, dalam urutan apa, dan pada standar apa tetap berada pada orang-orang yang bertanggung jawab atas hasilnya.
Related disciplines
Frequently asked questions
- Apa beda machine learning engineer dan data scientist?
- Keluarannya berbeda. Data scientist menetapkan apa yang seharusnya diukur, merancang studinya, memastikan apakah efek yang teramati itu nyata, dan mengomunikasikannya kepada pihak yang harus bertindak atasnya. Machine learning engineer mengambil sebuah pendekatan pemodelan dan mengubahnya menjadi sesuatu yang bisa dilatih dengan andal, melayani request di dalam anggaran, dan tetap bekerja ketika keadaan berubah. Keahliannya beririsan di tengah, dan kedua peran ini gagal dengan cara berbeda: yang satu menghasilkan jawaban yang tak bisa ditindaklanjuti siapa pun, yang lain menghasilkan sistem yang tak seorang pun pernah memastikan layak dibangun.
- Apa bedanya peran ini dengan AI engineer?
- Machine learning engineer menghasilkan dan memelihara model. AI engineer membangun aplikasi di sekeliling foundation model yang dilatih pihak lain, dan menghabiskan waktunya pada retrieval, context, evaluation harness, dan guardrail alih-alih pada proses pelatihan dan pipeline feature. Keduanya bisa sama-sama mengatakan bahwa mereka bekerja dengan model, padahal keseharian keduanya nyaris sepenuhnya berbeda, sehingga ada baiknya menyatakan secara eksplisit dalam deskripsi pekerjaan yang mana yang sebenarnya dibutuhkan.
- Apakah machine learning engineer perlu latar belakang riset?
- Untuk sebagian besar pekerjaan komersial, tidak. Arsitektur baru dan riset yang dipublikasikan memang menuntutnya, tetapi mayoritas nilai di production justru datang dari kualitas data, feature yang masuk akal, evaluasi yang jujur, dan operasi yang andal — semuanya kekuatan engineering, bukan kekuatan riset. Gelar doktor bukan syarat sekaligus bukan penghalang, dan menjadikannya patokan secara default mempersempit pilihan secara signifikan tanpa memperbaiki hasilnya.
- Apakah MLOps merupakan peran tersendiri?
- Di bawah skala tertentu ia praktik, bukan jabatan: engineer yang sama yang melatih model juga memegang pipeline, registry, serving, dan pemantauannya. Begitu beberapa tim merilis model di atas infrastruktur bersama, biasanya muncul spesialisasi platform yang memisahkan diri, dan posisinya lebih dekat ke platform engineering daripada ke pemodelan. Menciptakan jabatan itu terlalu dini cenderung menghasilkan infrastruktur tanpa pengguna.
- Seberapa sering sebuah model perlu dilatih ulang?
- Jadwal tetap hanyalah pengganti bagi hal yang sebenarnya penting, yaitu apakah lingkungan model itu sudah cukup berubah sehingga merugikannya. Sebagian model tahan bertahun-tahun tanpa disentuh; sebagian lain memburuk dalam hitungan minggu setelah perubahan harga atau pergeseran musim. Pendekatan yang sehat adalah memantau input dan hasilnya, menetapkan pemicu, dan memperlakukan irama kalender sebagai jaring pengaman, bukan sebagai mekanismenya.
- Bisakah seorang data engineer berpindah ke peran ini?
- Ini jalur yang sudah sering ditempuh, karena sebagian besar pekerjaannya adalah pembangunan pipeline yang sudah dikuasai kandidatnya. Yang perlu ditambahkan adalah pertimbangan statistik: memilih ukuran evaluasi, mengenali kebocoran data, memahami mengapa skor offline melebih-lebihkan kinerja sesungguhnya, dan menafsirkan drift alih-alih sekadar mendeteksinya.
- Bagaimana machine learning engineer bekerja bersama tim engineering yang sudah ada?
- Dalam model penambahan kapasitas tim engineering, arah pekerjaan sehari-hari ada pada Anda. Standar Anda, arsitektur Anda, roadmap Anda, dan perencanaan sprint Anda yang menentukan apa yang terjadi, dan kolaborasi teknisnya berlangsung dengan engineer Anda. Talent.ID bertanggung jawab mempekerjakan mereka: hubungan kerja, payroll, benefit karyawan, administrasi talenta, dan hubungan yang berlanjut sepanjang masa kerja.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.