Lewati ke konten

AI & Data

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 kapan sebuah tim mulai membutuhkannya.

Diskusikan kebutuhan AndaCara kerja penambahan kapasitas tim

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.

Menilai kebutuhan

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.

Disiplinnya

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.

Konteks

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

Working model

Bagaimana peran ini bekerja dengan tim Anda

Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.

Tetap milik Anda

  • Produk
  • Prioritas bisnis
  • Roadmap
  • Arsitektur
  • Prioritas sprint
  • Standar engineering
  • Kolaborasi teknis sehari-hari

Ditangani Talent.ID

  • Hubungan kerja
  • Payroll
  • Benefit karyawan
  • Administrasi talenta
  • Hubungan karyawan berkelanjutan

Bagaimana kerja sama berjalan, langkah demi langkah

Contoh penerapan

Seperti apa ini dalam praktik

Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.

Tantangan
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.
Pendekatan
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.
Yang ditambahkan ke tim
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.

Disiplin terkait

Pertanyaan umum

Pertanyaan yang sering diajukan

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.

Ceritakan kebutuhan tim Anda

Jelaskan kekurangannya — pekerjaannya, stack-nya, cara tim Anda berjalan — dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.

Build your teamContact us