Memindahkan Model ke Pengeluaran Tanpa Memecahkannya

Notebook mendapat skor 0.91 AUC pada laptop anda. Model kini dalam talian, mengembalikan nilai minus infiniti untuk 3% permintaan, jurutera on-call dipanggil pada pukul 2 pagi, dan anda tidak dapat menghasilkan semula larian latihan asal kerana anda tidak pernah menetapkan seed rawak. Selamat datang ke jurang antara "model berfungsi" dan "model dihantar."

Saya telah melihat adegan ini berulang di enam syarikat, dengan lima tindanan ML yang berbeza, dan coraknya tidak berubah. Kerugian bukan secara algoritma. Ia operasi. Ketakselarasan latihan dan penyajian secara diam-diam menurunkan AUC pengeluaran sebanyak 4-7 mata. Saluran ciri yang berfungsi semalam mengeluarkan NaN hari ini kerana seseorang mengubah skema hulu dan tidak memberitahu anda. Kejuruteraan melayan model anda sebagai kotak hitam kerana anda melayan perkhidmatan mereka seperti itu.

Ini ialah Playbook yang saya harap seseorang berikan kepada saya sebelum insiden pengeluaran pertama saya. Ia merangkumi tujuh perkara yang menentukan sama ada model anda menjadi baris hasil yang senyap atau topik kaji semula selepas insiden yang berulang.

Mengapa perkara ini penting sekarang

Kebanyakan pasukan sains data kehilangan 30-50% nilai model antara AUC luar talian dan kesan perniagaan dalam talian. Itu bukan metrik yang saya reka. Jalankan angka pada tiga model terakhir yang anda hantar: peningkatan luar talian, peningkatan dalam talian, masa dari "digabungkan" hingga "dilancarkan sepenuhnya." Jurang hampir selalu berbentuk staffing, bukan berbentuk algoritma.

DS yang memiliki disiplin pengembalian semula, pemantauan, dan antara muka kejuruteraan menghantar 5x lebih banyak nilai daripada DS dengan seni bina model yang sedikit lebih baik. Kesediaan pengeluaran adalah disiplin, bukan pilihan alat. Anda boleh melakukannya pada AWS Batch dan jadual Postgres. Anda juga boleh gagal dengan hebat menggunakan stor ciri paling mahal di pasaran.

Saluran ciri: Feast vs Tecton vs DIY

Setiap kegagalan ML pengeluaran yang pernah saya sebabkan secara peribadi boleh dikaitkan kepada ciri-ciri. Khususnya: ciri-ciri yang dilatih oleh model bukan ciri-ciri yang dilihat oleh model semasa masa pemarkahan. Kami menyebutnya ketakselarasan latihan dan penyajian, dan ia adalah pembunuh senyap.

Tiga pilihan:

DIY (jadual Postgres atau paparan gudang data). Baik apabila anda mempunyai satu model, pemarkahan kelompok, dan SQL yang sama menghasilkan data latihan dan data penyajian. Kebanyakan syarikat harus bermula di sini dan kekal lebih lama daripada yang mereka fikir. Perangkapnya: apabila anda mula menambah ciri masa nyata, SQL yang anda tulis untuk latihan (jumlah bergulir 7 hari dari gudang data) bukan SQL yang dijalankan oleh perkhidmatan penyajian (agregat penstriman dari Redis). Ia melayang. Secara senyap.

Feast (sumber terbuka). Percuma, anda hoskannya. Membuktikan nilainya apabila anda mempunyai 3+ model yang berkongsi ciri, mahu definisi yang sama digunakan dalam latihan dan penyajian dalam talian, dan bersedia mengoperasikan Redis/DynamoDB dan saluran Spark atau Flink. Cukai jujur: anda akan menghabiskan suku tahun untuk proses onboarding sebelum ciri-ciri mula mengalir. Berbaloi jika anda sudah lepas fasa satu model.

Tecton (terurus). Beli apabila kejuruteraan ciri merupakan kesesakan nyata, anda mempunyai bajet untuk $80-200K/tahun, dan anda lebih suka tidak menjalankan infrastruktur penstriman. Tecton menyelesaikan ketakselarasan latihan dan penyajian dengan membuat satu definisi menghasilkan kedua-dua pengisian semula dan nilai dalam talian. Penjejakan keturunan mereka menangkap "ciri ini berubah Selasa lepas" sebelum anda melakukannya.

Keputusan bukan "alat mana yang terbaik." Ia adalah: adakah saya mempunyai satu model atau ramai, kelompok atau masa nyata, dan adakah hanyutan ciri kini tidak kelihatan kepada saya? Jika ya-ya-ya, anda memerlukan stor. Jika tidak-tidak-tidak, paparan gudang data dan fail feature_definitions.py yang anda import dalam kedua-dua latihan dan penyajian sudah lebih dari mencukupi.

Kebolehulangan saluran latihan

Jika saya meminta anda menjalankan semula kerja latihan tepat yang menghasilkan model dalam pengeluaran sekarang, dari data mentah, dengan pembahagian yang sama dan metrik yang sama, bolehkah anda melakukannya dalam 30 minit?

Jika jawapannya tidak, anda tidak mempunyai saluran yang boleh diulang. Anda mempunyai cenderamata.

Apa yang kebolehulangan sebenarnya memerlukan:

Tetapkan setiap seed. Bukan sahaja random_state=42 pada pembahagian latihan dan ujian. Tetapkan seed numpy, seed PyTorch/TensorFlow, seed pensampelan anda, seed pengacak data anda, seed sebarang augmentasi. Saya pernah menyahpepijat model di mana dua jurutera mendapat AUC 0.86 dan 0.91 dari "notebook yang sama" kerana RNG CUDA torch tidak ditetapkan. Tiga hari hilang.
Hasi pembahagian anda. Jangan percaya train_test_split untuk menjadi deterministik merentasi versi pandas. Kira hasi yang stabil dari pengecam baris (user_id, transaction_id) modulo nisbah pembahagian. Baris yang sama, pembahagian yang sama, selama-lamanya. Bonus: apabila anda melatih semula pada data baharu, baris set ujian lama kekal dalam ujian.
Rekodkan SHA-256 dataset dalam artifak model. Kad model seharusnya merangkumi: SHA-256 dataset latihan (selepas kejuruteraan ciri), tetingkap latihan (2025-10-01 hingga 2026-03-31), versi skema ciri, commit kod, hasi fail kunci perpustakaan, metrik penilaian pada held-out, metrik penilaian pada set rujukan beku. Ini masuk ke dalam artifak Git LFS atau MLflow yang sama dengan berat model.
Kunci runtime. requirements.lock atau poetry.lock atau uv.lock yang dilakukan bersama model. Hanyutan versi perpustakaan memecahkan kebolehulangan secara senyap. scikit-learn 1.3 vs 1.4 sudah cukup untuk mengalihkan ramalan.

Ujian "jalankan semula latihan dari 6 minggu lalu" adalah tidak boleh dirunding. Jika anda tidak boleh lulus ujian itu, anda tidak dapat menyahpepijat regresi dengan penuh yakin. Anda hanya meneka.

Penyajian kelompok vs masa nyata: bila setiap satu

Kebanyakan model "masa nyata" seharusnya dikelompokkan. Saya akan mengatakannya dua kali kerana ia sentiasa diabaikan. Kebanyakan model "masa nyata" seharusnya dikelompokkan.

Pokok keputusan:

Bajet kependaman lebih daripada 1 jam, ramalan berubah perlahan: kelompok setiap malam. Markah semua orang pada pukul 2 pagi, tulis ke jadual, produk membaca dari jadual. Pemarkahan lead, risiko churn, cadangan kandungan untuk pengguna bukan permulaan sejuk. p99 kependaman: satu SELECT.
Bajet kependaman 5-60 minit, ramalan memerlukan kesegaran setiap jam: kelompok setiap jam. Bentuk yang sama, lebih kerap. Ramalan inventori, isyarat permintaan.
Bajet kependaman 30 saat hingga 5 minit, bergantung pada aktiviti sesi: kelompok mikro. Pengguna penstriman menanda dalam kelompok 100-1000 rekod setiap 30 saat. Isyarat penipuan, pengesanan anomali di mana tindakan boleh menunggu seminit.
Bajet kependaman kurang daripada 200ms, permintaan tidak dapat diramal: masa nyata. Kedudukan iklan, relevan carian, blok penipuan semasa pembayaran, pemperibadian masa nyata. Ini yang mahal. Bajet kependaman p99 seharusnya ditetapkan dalam kontrak antara muka sebelum anda melatih, bukan selepas anda menggunakan.

Perbezaan kos adalah besar. Kerja kelompok setiap malam berjalan pada satu contoh besar selama sejam. Perkhidmatan masa nyata memerlukan auto-scaling, kolam hangat, pemantauan p99, dan SRE dalam pusingan. Pilih kelompok melainkan anda mempunyai sebab yang nyata.

Satu kisah perang: kami menghantar model cadangan "masa nyata" yang memanggil Postgres secara synchronous untuk tiga carian ciri setiap permintaan. p99 pergi ke 4 saat sebelum kami menangkapnya. Penyelesaiannya bukan Postgres yang lebih cepat. Ia adalah mengakui model tidak perlu masa nyata, memindahkannya ke kelompok, dan menyajikan dari jadual yang telah dikira terlebih dahulu. Kependaman turun ke 8ms. Pasukan produk tidak menyedari perubahan kerana cadangan sebenarnya tidak bergantung pada sesi.

Pemantauan model: hanyutan data, hanyutan konsep, metrik perniagaan

Empat perkara yang perlu dipantau. Tiga daripadanya adalah diagnostik. Hanya satu yang membayar bil.

Hanyutan input. Adakah ciri-ciri yang dilihat model hari ini diedarkan seperti ciri-ciri yang dilatihnya? Jejaki Population Stability Index (PSI) per ciri, setiap hari. PSI lebih 0.1: siasat. PSI lebih 0.25: taburan latihan dan taburan pengeluaran anda bukan lagi yang sama. Amaran. Untuk ciri berterusan, juga jalankan ujian Kolmogorov-Smirnov berbanding tetingkap rujukan. Murah, cepat, menangkap pecahan skema sebelum ramalan merosot.

Hanyutan ramalan. Adakah output model diedarkan seperti minggu lepas? Kadang-kadang hanyutan input tidak kelihatan (interaksi ciri bergerak) tetapi hanyutan ramalan adalah nyata. Jejak p10/p50/p90 output model setiap hari.

Hanyutan konsep (sedar kelewatan label). Adakah hubungan antara ciri-ciri dan label berubah? Anda hanya boleh menyemak ini apabila label tiba, yang untuk banyak model adalah hari atau minggu kemudian. Bina saluran penilaian tertunda: apabila label tiba, kira semula AUC/MAE pada baris tersebut dan carta dari masa ke masa. Perangkapnya ialah memberi amaran tentang AUC sehari selepas pelancaran apabila anda tidak mempunyai label lagi. Anda akan terpandang 0.

Metrik perniagaan. Hasil. Kadar penukaran. CAC. Nilai sepanjang hayat. Perkara yang wujud untuk digerakkan oleh model. Ini ialah satu-satunya metrik yang menentukan sama ada model kekal. Ambang amaran pada hanyutan input/ramalan adalah diagnostik. Ambang amaran pada metrik perniagaan adalah kewujudan.

Saya pernah melihat pasukan menghantar model dengan papan pemuka hanyutan yang dikalibrasi dengan cantik dan sifar keterlihatan sama ada hasil bergerak. Jangan jadi pasukan itu. Papan pemuka pertama ialah papan pemuka perniagaan. Papan pemuka hanyutan wujud untuk menerangkan mengapa metrik perniagaan bergerak, bukan untuk menggantikannya.

Pelancaran "mod bayang"

Skor-tetapi-tidak-bertindak. Selama satu hingga dua minggu. Pada trafik yang sama. Bandingkan ramalan model baharu dengan ramalan incumbent dan dengan hasil sebenar apabila label tiba.

Ini ialah amalan leverage tertinggi yang saya tahu dalam ML pengeluaran, dan kebanyakan pasukan melangkauinya.

Aliran pelancaran mod bayang:

Lancarkan model baharu bersama incumbent. Kedua-duanya menanda setiap permintaan. Hanya ramalan incumbent mempengaruhi tingkah laku produk.
Log kedua-dua ramalan ditambah semua ciri yang digunakan.
Selepas 7-14 hari, bandingkan:
- Pertindihan taburan: adakah kedua-dua model membuat ramalan yang serupa pada input yang sama? Jika 30% tidak bersetuju, cari tahu sebab sebelum beralih.
- Padankan berbanding jangkaan luar talian: adakah tingkah laku dalam talian model baharu sepadan dengan apa yang penilaian held-out anda ramalkan? Jika luar talian kata peningkatan +5% dan bayangan kata ia sama, data latihan anda bocor.
- Kependaman, kadar ralat, kes tepi (input NaN, ciri hilang): adakah model baharu mengendalikan ekor panjang?
Hanya beralih apabila data bayangan mengesahkan kisah luar talian.

Juara/pencabar adalah idea yang sama, diformalkan. Incumbent ialah juara. Model baharu ialah pencabar. Anda tidak menaikkan pangkat pencabar sehingga ia menang di bawah trafik sebenar, bukan hanya pada set ujian.

Pelancaran itu sendiri harus berperingkat: 1% hingga 5% hingga 25% hingga 50% hingga 100%, dengan sekurang-kurangnya 24-48 jam antara langkah dan metrik perniagaan dipantau pada setiap peringkat. Jika ada yang bergerak ke arah yang salah, berhenti. Jangan rasionalkan.

Corak perkongsian kejuruteraan: kontrak antara muka

Model "lempar fail pickle ke atas tembok" gagal setiap kali. Inilah yang berkesan sebaliknya.

Sebelum anda mula melatih, duduk bersama jurutera platform dan tulis kontrak antara muka satu halaman. Ia merangkumi:

Skema API. Medan input, jenis, null yang dibenarkan, peraturan pengesahan. Medan output, jenis, julat. Apakah rupa respons apabila model tidak dapat menanda (ciri hilang, pelayan model tidak berfungsi)?
SLO kependaman. p50, p95, p99 dalam milisaat. Ini menentukan sama ada anda boleh melakukan carian ciri masa nyata, seni bina model mana yang di luar jadual, sama ada inferens GPU diperlukan.
SLO throughput. Permintaan per saat pada puncak. Mendorong konfigurasi auto-scaling.
Bajet ralat. Berapa peratus permintaan yang boleh gagal oleh perkhidmatan? 0.1%? 1%? Ini menetapkan bar untuk keketatan pengesahan input.
Sempadan pemilikan. Siapa yang memberi amaran apabila model mengembalikan ramalan yang salah berbanding apabila perkhidmatan mengembalikan ralat 500? DS memiliki yang pertama. Kejuruteraan memiliki yang kedua. Kedua-dua memiliki yang ketiga (model berjalan tetapi ramalan buruk).
Kuasa pengembalian semula. Siapa yang boleh membalikkan suis pemati kecemasan tanpa eskalasi? Pada pukul 3 pagi, jawapannya seharusnya "jurutera on-call," bukan "halang Camellia."

Tuliskan ini. Tandatangani. Semat. Apabila insiden pengeluaran yang tidak dapat dielakkan berlaku, kontrak itu ialah yang memastikan perbualan tentang menyelesaikan isu, bukan berunding tanggungjawab.

DS yang hadir dalam mesyuarat itu dengan draf kontrak mendapat kepercayaan sejak mereka masuk. DS yang hadir dengan notebook dan bertanya "bagaimana kita lancarkan ini?" bermula dari sifar.

Disiplin pengembalian semula

Setiap pengerahan dihantar dengan laluan pengembalian semula yang telah diuji. Bukan laluan pengembalian semula yang didokumenkan. Yang telah diuji.

Tiga komponen:

Penandaan versi. Setiap model mendapat versi (pricing-model-v23). Setiap ramalan yang dilog merangkumi versi yang menilaikannya. Apabila anda menyiasat regresi, anda boleh menapis mengikut versi.
Suis pemati kecemasan. Bendera konfigurasi yang menukar trafik dari model baharu kembali ke model sebelumnya dalam masa bawah 60 saat. Bukan penggunaan semula. Balik bendera. Perkhidmatan penyajian membaca bendera pada masa permintaan.
Latihan pengembalian semula. Setiap suku tahun, lakukan pengembalian semula dalam pengeluaran selama 5 minit semasa tetingkap trafik rendah. Jika anda tidak menarik picu dalam 90 hari, pengembalian semula adalah teori, yang bermakna ia tidak berfungsi.

Kali pertama anda memerlukan pengembalian semula bukan masa untuk mendapati bahawa artifak model sebelumnya telah dipadamkan dari S3, saluran ciri telah direfaktor, atau suis pemati kecemasan tidak pernah berfungsi. Saya telah secara peribadi mengalami ketiga-tiganya.

Perangkap biasa

Melatih pada data yang tidak dapat dilihat model semasa masa penyajian. Kebocoran data. Bentuk paling biasa: ciri yang hanya boleh dikira selepas peristiwa yang anda ramalkan. Ciri "hari sejak log masuk terakhir" yang dikira dari gudang data akan merangkumi log masuk selepas cap masa ramalan melainkan anda memotongnya secara eksplisit.
Menetapkan random_state=42 tetapi tidak menetapkan seed pensampelan hulu. Pembahagian anda deterministik, latihan anda tidak.
Menggunakan tanpa juara/pencabar. Anda meneka sama ada model baharu lebih baik.
Memberi amaran tentang AUC bukannya hasil. AUC turun dari 0.84 ke 0.82, buruk? Anda tidak tahu. Mungkin hasil naik.
Tiada ujian pengembalian semula dalam 90 hari. Anda tidak mempunyai pengembalian semula. Anda mempunyai harapan.
Melayan kejuruteraan sebagai meja perkhidmatan dan bukannya rakan kongsi. Mereka akan melayan model anda dengan cara yang sama.

Templat dan alat

Empat dokumen yang setiap model yang dihantar seharusnya ada:

Kad model. SHA-256 dataset, tetingkap latihan, seed, versi skema ciri, metrik penilaian pada held-out dan rujukan beku, SLO penyajian, pemilik, tarikh penggunaan, prosedur pengembalian semula.
Senarai semak perbandingan mod bayang. Pertindihan taburan, padanan luar talian-dalam talian, kependaman, kadar ralat, pengendalian kes tepi, keperluan tandatangan mengikut pihak berkepentingan.
Buku larian pengembalian semula. Balik suis pemati kecemasan langkah demi langkah, cara mengesahkan model sebelumnya menyajikan trafik, siapa yang perlu diberitahu, templat kaji semula selepas insiden.
Kontrak antara muka kejuruteraan/DS. Satu halaman. Skema API, SLO, bajet ralat, sempadan pemilikan, kuasa pengembalian semula. Ditandatangani oleh DS, ketua kejuruteraan, dan pusingan on-call.

Mengukur kejayaan

Anda melakukan ini dengan betul apabila:

Anda boleh menjalankan semula larian latihan tepat mana-mana model pengeluaran dari data mentah dalam bawah 30 minit.
Setiap pengerahan mempunyai pengembalian semula yang telah diuji dan dilakukan dalam 90 hari yang lalu.
Pemantauan menangkap hanyutan sebelum metrik perniagaan bergerak, bukan selepas itu.
Jurutera platform anda berkata "bekerja dengan anda mudah" tanpa digesa.
Tiga pengerahan terakhir membosankan.

Pengerahan yang membosankan ialah matlamat. Drama adalah kegagalan. DS yang menghantar dengan membosankan ialah DS yang kerap menghantar, dan DS yang kerap menghantar menggabungkan nilai lebih cepat daripada sesiapa dengan seni bina model yang sedikit lebih baik.

Ketahui Lebih Lanjut

Sehari dalam Kehidupan Data Scientist
Reka Bentuk Eksperimen yang Tahan Ulasan Pihak Berkepentingan
Metrik DS: Model Dihantar, Kesan Perniagaan, Kemerosotan
Perangkap Biasa Data Scientist
Perihalan Kerja Data Scientist - JD pelengkap dengan jangkaan peranan yang panduan ini operasikan

Buku Panduan Data Scientist