Wawancara Data Engineering: Bagaimana Cara Merancang Pipeline Fitur ML Tanpa Training-Serving Skew?

Pertanyaan dan Kapan Ini Berlaku

Rancang pipeline fitur ML untuk fraud scoring real-time. Set pelatihan mencakup 12 bulan sebelumnya, dan sistem online menangani sekitar 5.000 prediksi per detik. Setiap prediksi membutuhkan sekitar 50 fitur, dengan batas latensi 5 ms p99 untuk pengambilan fitur. Angka-angka ini adalah asumsi kapasitas untuk mendiskusikan trade-off, bukan standar industri bawaan.

Fitur-fitur tersebut mencakup agregat jumlah transaksi satu jam dari aliran event dan usia akun yang diperbarui setiap hari. Beberapa event datang terlambat, data historis mungkin di-backfill, dan pembaruan model dapat mengubah definisi fitur. Jelaskan cara membangun data pelatihan yang benar secara point-in-time, menyajikan nilai online dengan latensi rendah, menangani data yang hilang dan basi, meluncurkan versi baru, serta membuktikan bahwa semantik offline dan online cocok.

Pertanyaan ini berlaku untuk wawancara data engineering, machine learning engineering, dan platform ML. Tujuannya bukan untuk sekadar menghafal "tambahkan feature store". Tujuannya adalah menghubungkan definisi, komputasi, penyimpanan, serving, dan verifikasi suatu fitur ke dalam satu jalur yang dapat dilacak.

Apa yang Sedang Dievaluasi oleh Pewawancara

Pertama, dapatkah kandidat mendefinisikan semantik fitur sebelum menggambar arsitektur penyimpanan? Jawaban yang kuat memasukkan entity key, tipe data, sumber, versi transformasi, waktu event, waktu ketersediaan, jendela agregasi, persyaratan kesegaran (freshness), kebijakan default, dan pemilik ke dalam kontrak fitur. Sistem offline dan online sama-sama mengimplementasikan kontrak tersebut alih-alih menebak artinya dari sebuah nama.

Kedua, dapatkah kandidat menalar tentang waktu dengan benar? event_at menunjukkan kapan suatu event terjadi dalam domain bisnis; available_at menunjukkan kapan sistem benar-benar mengetahuinya. Suatu event mungkin terjadi sebelum prediksi tetapi baru tiba setelahnya, sehingga layanan tidak mungkin menggunakannya. Join pelatihan yang hanya memeriksa event_at <= prediction_at masih dapat menarik informasi yang terlambat atau di-backfill ke masa lalu.

Ketiga, dapatkah kandidat memilih komputasi dan penyimpanan untuk pola akses yang berbeda? Pelatihan offline membutuhkan riwayat waktu dan join point-in-time, sedangkan serving online biasanya membutuhkan nilai terbaru untuk suatu entitas. Agregat jendela adalah kandidat yang baik untuk pra-komputasi dan materialisasi. Fitur-fitur ringan yang hanya bergantung pada permintaan saat ini dapat dihitung sesuai permintaan (on demand). Mesin eksekusi offline dan online mungkin berbeda, tetapi semantiknya harus cocok dan kesetaraannya harus dibuktikan dengan data.

Keempat, dapatkah kandidat merancang peluncuran versi yang aman dan perilaku saat terjadi kegagalan? Sebuah model harus mengunci (pin) versi set fitur yang dikonsumsinya, dan versi lama serta baru harus hidup berdampingan selama jendela canary dan rollback. Hilang (missing) tidak berarti nol. Data basi, pemadaman penyimpanan, dan versi yang tidak kompatibel masing-masing membutuhkan kebijakan yang eksplisit.

Terakhir, pewawancara menginginkan verifikasi yang dapat dieksekusi: pemeriksaan kontrak, golden record, pengujian point-in-time historis, sampel vektor fitur online, pemutaran ulang (replay) offline, injeksi event yang terlambat dan tidak berurutan, latihan backfill dan rollback, ditambah metrik latensi, kesegaran, ketiadaan data, dan paritas.

Pertanyaan yang Perlu Diklarifikasi Terlebih Dahulu

• Kapan waktu prediksi dan jendela labelnya? Asumsikan penilaian terjadi saat transaksi tiba dan label chargeback matang selama 30 hari ke depan. Informasi label tidak boleh mengalir kembali ke dalam fitur.
• Apa saja yang termasuk dalam anggaran latensi online? Apakah 5 ms p99 hanya mencakup pengambilan fitur, atau juga jaringan, serialisasi, dan inferensi? Jawaban ini memperlakukannya sebagai anggaran pengambilan fitur.
• Seberapa segar setiap fitur harus disediakan? Total transaksi satu jam mungkin memerlukan kesegaran tingkat menit, sedangkan usia akun dapat mentolerir pembaruan harian. Satu TTL tidak boleh diterapkan ke setiap fitur.
• Seberapa terlambat, terduplikasi, atau tidak berurutankah event yang mungkin terjadi? Ini menentukan watermark, deduplikasi, komputasi ulang, dan aturan penimpaan (overwrite) online.
• Apakah backfill historis harus mereproduksi "apa yang diketahui saat itu" atau "kebenaran terkoreksi terbaru"? Mereproduksi serving masa lalu membutuhkan yang pertama; analisis post-hoc mungkin membutuhkan yang kedua. Keduanya tidak dapat dicampur dalam satu dataset.
• Bagaimana bisnis harus menoleransi penurunan performa (degrade) pada data online yang hilang atau basi? Sistem fraud dapat menggunakan model dasar (baseline), tinjauan manual, atau keputusan konservatif alih-alih mengubah setiap nilai yang hilang menjadi nol.
• Bagaimana model dan fitur di-deploy secara independen? Kita perlu tahu apakah beberapa versi dapat dimaterialisasi secara paralel, berapa lama versi lama dipertahankan, dan apa target rollback-nya.
• Infrastruktur apa yang sudah ada? Untuk satu model batch-only bervolume rendah, transformasi berversi yang digunakan bersama dan snapshot yang tidak dapat diubah (immutable) mungkin sudah cukup. Platform fitur lengkap tidak boleh dijadikan asumsi awal.

Kerangka Jawaban 30 Detik

"Pertama, saya akan membuat kontrak fitur yang berisi entity key, dua clock, jendela waktu, versi, dan persyaratan kesegaran. Event mentah tetap tidak dapat diubah (immutable), dan definisi yang sama menghasilkan riwayat offline serta nilai online terbaru. Contoh pelatihan menggunakan join point-in-time pada prediction_at, yang dibatasi oleh event_at dan available_at, sehingga data yang datang terlambat tidak dapat berpindah ke masa lalu. Model mengunci feature_set_version; versi lama dan baru dimaterialisasi secara paralel dan dibandingkan secara bayangan (shadow-compared) sebelum traffic dialihkan. Saya mengambil sampel vektor fitur online yang sebenarnya, memutar ulang secara offline dari event mentah dengan definisi yang sama, membandingkan nilai, ketiadaan data, dan kesegaran fitur demi fitur, serta menginjeksikan event yang terlambat, backfill, kegagalan penyimpanan, dan rollback."

Pembahasan Mendalam Langkah-demi-Langkah

Langkah 1: Ubah setiap definisi fitur menjadi kontrak yang dapat dieksekusi.

Daftarkan setidaknya field-field berikut untuk setiap fitur:

Setelah nama fitur dirilis, definisinya tidak boleh diubah secara diam-diam. Jika txn_amount_sum_1h berubah dari "transaksi yang diotorisasi" menjadi "semua transaksi yang dicoba", publikasikan versi atau nama fitur baru. Model lama tidak boleh mengonsumsi makna baru tersebut tanpa disadari.

Langkah 2: Buat jalur offline dan online dimulai dari fakta yang sama.

Transaksi, perubahan akun, dan event sumber lainnya pertama-tama masuk ke log yang immutable atau lapisan riwayat yang dapat diputar ulang. Pemrosesan streaming menghitung fitur jendela dengan kesegaran tinggi; pemrosesan batch menghitung dimensi yang berubah lambat (slowly changing dimensions) dan backfill historis. Kedua jalur menulis riwayat waktu lengkap ke offline store dan mematerialisasikan nilai valid terbaru per entitas ke dalam online store.

"Definisi yang sama" tidak mengharuskan pekerjaan batch dan stream menggunakan bahasa pemrograman yang sama. Utamakan transformasi deklaratif bersama atau kode bersama. Jika dua implementasi memang diperlukan, golden record dan paritas pemutaran ulang menjadi gerbang rilis (release gates). Feature store mengatur batasan-batasan ini; ia tidak secara otomatis menghilangkan perbedaan antara dua implementasi.

Penulisan online harus bersifat idempoten. Event membawa ID yang stabil sehingga duplikat tidak meningkatkan nilai agregat dua kali. Saat menulis nilai terbaru, bandingkan timestamp fitur dan versinya sehingga hasil lama yang terlambat tidak dapat menimpa nilai yang lebih baru. Fitur berjendela juga memerlukan interval keterlambatan yang diizinkan (allowed-lateness interval), watermark, dan aturan koreksi yang eksplisit.

Langkah 3: Bangun data pelatihan yang benar-benar tepat secara point-in-time.

Setiap contoh pelatihan memiliki prediction_at. Untuk entitas yang sama, join as-of dasar memilih versi fitur terbaru dengan event_at <= prediction_at. Ketika event dapat datang terlambat atau di-backfill, join tersebut juga harus memenuhi available_at <= prediction_at:

eligible_feature = same_entity
  AND event_at <= prediction_at
  AND available_at <= prediction_at

selected_feature = latest eligible_feature by event_at, then available_at

Kondisi kedua sangat penting. Misalkan sebuah transaksi terjadi pada hari Senin, tiba pada hari Rabu, dan prediksi historis terjadi pada hari Selasa. Transaksi tersebut berada di masa lalu menurut waktu bisnis tetapi masih di masa depan menurut pengetahuan sistem. Jika platform data tidak dapat mempertahankan available_at, gunakan snapshot immutable atau log fitur online dari waktu tersebut. Jangan menyajikan tabel terkoreksi hari ini sebagai status yang sebenarnya dilihat oleh serving historis.

"Sesuai yang diketahui saat itu" (as known then) dan "terkoreksi terbaru" (latest corrected) harus menjadi mode dataset yang eksplisit. Yang pertama mereproduksi apa yang dapat dilihat oleh model pada momen historis; yang kedua mendukung rekonsiliasi atau analisis post-hoc. Label ditangani secara terpisah: hanya contoh dengan jendela observasi yang matang yang masuk ke pelatihan, dan data pembuatan label tidak pernah berpartisipasi dalam join fitur.

Langkah 4: Pilih antara materialisasi dan komputasi saat baca (compute-on-read).

Agregat jendela seperti jumlah transaksi satu jam atau jumlah perangkat tujuh hari membutuhkan komputasi intensif dan sensitif terhadap kesegaran, jadi hitung secara inkremental dan materialisasikan dari aliran data. Fitur berfrekuensi rendah seperti usia akun dapat diperbarui secara batch. Fitur ringan yang hanya bergantung pada permintaan saat ini dan tidak memerlukan riwayat pelatihan dapat dihitung sesuai permintaan, mengurangi beban penyimpanan dan area sinkronisasi.

Online store mengambil nilai terbaru berdasarkan entity key dan feature_set_version alih-alih memindai riwayat pada saat permintaan. Offline store mempertahankan time series untuk pelatihan, backfill, dan audit. Bersamaan dengan nilai, API pengambilan harus mengembalikan atau mencatat timestamp fitur, versi komputasi, dan status ketiadaan data sehingga serving dapat mendeteksi keusangan dan ketidakcocokan.

Langkah 5: Tentukan perilaku saat data hilang, basi, dan terjadi pemadaman.

Setiap fitur atau grup fitur memiliki batas toleransi kesegarannya sendiri. Pada saat membaca, hitung prediction_at - feature_timestamp dan tandai nilai sebagai basi jika melebihi batas tersebut. Hilang, basi, dan nilai numerik nol yang sah adalah tiga status yang berbeda. Data pelatihan harus merepresentasikan ketiadaan data dengan cara yang sama persis seperti serving.

Tingkat risiko menentukan mekanisme penurunan performa (degradasi). Fitur yang tidak kritis dapat menggunakan nilai default yang disertakan dalam pelatihan model. Fitur yang diizinkan untuk basi sementara dapat menggunakan nilai sebelumnya. Jika fitur fraud yang kritis tidak tersedia, alihkan ke model yang tidak bergantung padanya, kirim kasus tersebut ke peninjauan manual, atau buat keputusan yang lebih konservatif. Catat setiap alasan degradasi agar sistem tidak secara diam-diam terus menggunakan nilai default untuk jangka waktu yang lama.

Langkah 6: Luncurkan versi baru sambil mempertahankan kemampuan rollback.

Artefak model mengunci feature_set_version yang berisi nama fitur, skema, dan versi transformasi. Untuk merilis v2, materialisasikan v1 dan v2 secara paralel. Lakukan pembacaan bayangan (shadow-read) pada entitas yang sama dan putar ulang kasus-kasus historis. Setelah cakupan, kesegaran, distribusi nilai, dan perbedaan per fitur memenuhi ambang batasnya, deploy model yang mengonsumsi v2. Pertahankan v1 hingga jendela rollback berakhir.

Aturan kompatibilitas skema juga harus eksplisit. Menambahkan fitur opsional mungkin bersifat backward compatible; menghapus fitur, mengubah tipenya, atau mengubah semantiknya biasanya memerlukan versi baru. Sebelum deployment model, verifikasi bahwa online store telah memiliki versi dan cakupan yang diperlukan. Jangan men-deploy model terlebih dahulu dan membiarkan backfill fitur menyusul kemudian.

Langkah 7: Verifikasi paritas menggunakan fakta dari serving online.

Ambil sampel permintaan online dan catat entitas, prediction_at, feature_set_version, setiap nilai fitur, timestamp fitur, status hilang/basi, dan versi model akhir. Hanya mencatat skor model akan membuat kita mustahil mengetahui apakah ketidakcocokan berasal dari nilai, batas waktu, atau versi.

Pemverifikasi memulai dari event sumber yang immutable, menggunakan versi definisi yang sama, merekonstruksi vektor offline pada waktu prediksi yang sama, dan membandingkan fitur demi fitur:

• nilai cocok, dengan toleransi yang dideklarasikan untuk fitur floating-point;
• status hilang, default, dan basi cocok;
• batas jendela event dan zona waktu cocok;
• versi fitur online cocok dengan deklarasi model;
• event yang terlambat, duplikat, tidak berurutan, dan di-backfill terputar ulang secara deterministik.

Sebelum rilis, injeksikan skenario online store tidak tersedia, kunci yang hilang sebagian, timeout data, dan rollback dari v2 ke v1. Saat runtime, pantau latensi pengambilan p50/p95/p99, lag materialisasi, tingkat data hilang, tingkat default, tingkat data basi, tingkat ketidakcocokan versi, dan tingkat ketidakcocokan replay. Pemantauan kinerja model dapat mengungkap konsekuensinya, tetapi tidak dapat menggantikan bukti di tingkat fitur ini.

Contoh Jawaban yang Kuat

"Saya akan mendefinisikan kontrak fitur sebelum memilih database. Untuk setiap fitur, saya mendaftarkan entity key, tipe, sumber, versi transformasi, waktu event, waktu ketersediaan sistem, jendela waktu, batas kesegaran, dan aturan degradasi. Event mentah masuk ke lapisan riwayat yang immutable. Pemrosesan streaming menangani agregat dengan kesegaran tinggi seperti jumlah transaksi satu jam; pemrosesan batch menangani dimensi akun dan backfill. Keduanya menulis riwayat waktu secara offline dan mematerialisasikan nilai valid terbaru per entitas secara online.

Contoh pelatihan menggunakan prediction_at sebagai jangkar untuk join point-in-time. Suatu fitur harus memenuhi event_at <= prediction_at dan available_at <= prediction_at. Hal itu mengecualikan rekaman yang terjadi lebih awal tetapi belum tiba. Untuk mereproduksi serving historis, saya menggunakan dataset as-known; data yang dikoreksi disimpan terpisah untuk analisis post-hoc. Label chargeback hanya masuk setelah jendela 30 harinya matang, dan sumber label tidak pernah masuk ke pipeline fitur.

Serving online mengambil sekitar 50 nilai berdasarkan entitas dan feature_set_version, bersama dengan timestamp dan statusnya. Agregat jendela dihitung sebelumnya; fitur murah khusus permintaan dihitung sesuai permintaan. ID event yang stabil mencegah pembaruan ganda, dan versi lama yang terlambat tidak dapat menimpa nilai online yang lebih baru. Setiap fitur memiliki batas kesegarannya sendiri. Status hilang, basi, dan nol tetap dibedakan. Jika fitur fraud yang kritis tidak tersedia, serving menggunakan model dasar yang tervalidasi atau peninjauan manual alih-alih mengisi nol secara diam-diam.

Artefak model mengunci versi set fiturnya. Untuk v2, saya mematerialisasikan v1 dan v2 secara paralel, melakukan shadow read dan perbandingan pemutaran ulang, memindahkan model hanya setelah cakupan lolos pengujian, dan mempertahankan v1 untuk rollback. Untuk membuktikan paritas, saya mengambil sampel vektor fitur online nyata beserta waktu dan versinya, membangun kembali vektor yang sama secara offline dari event immutable, dan membandingkan setiap nilai dan statusnya. Gerbang rilis juga mencakup event yang terlambat dan tidak berurutan, backfill, kegagalan penyimpanan, dan rollback versi. Metrik runtime mencakup p99 pengambilan, lag materialisasi, tingkat hilang/basi, ketidakcocokan versi, dan ketidakcocokan pemutaran ulang.

Jika hanya ada satu model batch bervolume rendah, saya akan mulai dengan satu transformasi berversi dan snapshot pelatihan immutable. Saya baru akan memperkenalkan platform fitur lengkap ketika beberapa model benar-benar berbagi fitur dan membutuhkan pengambilan data historis sekaligus serving berlatensi rendah."

Kesalahan Umum

• Memilih database online sebelum mendefinisikan semantik → penyimpanan berlatensi rendah tidak dapat mencegah fitur dengan nama yang sama memiliki arti yang berbeda → buat kontrak fitur yang dapat dieksekusi terlebih dahulu.
• Hanya menggunakan event_at dalam join historis → rekaman yang datang kemudian akan melompat ke masa lalu → batasi juga available_at atau reproduksi snapshot historis.
• Mengasumsikan feature store bersama menjamin paritas → jalur batch dan stream mungkin masih menggunakan jendela waktu, nilai default, atau zona waktu yang berbeda → buktikan kesetaraan dengan definisi bersama, golden record, dan pemutaran ulang.
• Membiarkan hasil yang terlambat menimpa nilai online → jendela yang lebih lama dapat memundurkan status entitas → bandingkan timestamp dan versi fitur, serta buat penulisan menjadi idempoten.
• Mengubah setiap nilai yang hilang menjadi nol → nol bisa jadi merupakan nilai yang valid, sementara pemadaman sistem dapat menjadi sinyal bagi model → bedakan antara hilang, default, basi, dan nol riil.
• Mengedit fitur yang sudah dirilis secara langsung di tempat (in place) → model lama mengonsumsi semantik baru tanpa perubahan versi → publikasikan versi baru dan kunci dependensi model.
• Men-deploy model sebelum backfill fitur selesai → traffic awal melihat versi yang hilang atau bercampur → materialisasikan terlebih dahulu, validasi cakupan, baru kemudian alihkan model.
• Hanya membandingkan distribusi offline dan online → distribusi yang serupa dapat menyembunyikan kesalahan join entitas atau batas jendela waktu → putar ulang dan bandingkan setiap fitur untuk permintaan yang sama persis.
• Hanya mencatat skor prediksi → kegagalan tidak dapat dilacak apakah berasal dari nilai, waktu, atau versi → ambil sampel vektor aktual beserta metadatanya.
• Membangun platform fitur lengkap untuk setiap kasus penggunaan → satu model batch dapat menyerap kompleksitas yang tidak perlu → perkenalkan kemampuan platform sesuai kebutuhan berbagi, riwayat, dan latensi yang nyata.

Pertanyaan Lanjutan

Lanjutan 1: Mengapa waktu event dan waktu ketersediaan tidak dapat digabungkan?

Waktu event menjawab "kapan ini terjadi dalam domain bisnis?" Waktu ketersediaan menjawab "kapan sistem mengetahuinya?" Event yang terlambat, koreksi manual, dan backfill membuat keduanya berbeda. Mereproduksi prediksi historis membutuhkan kedua batas waktu tersebut; jika tidak, model akan menggunakan informasi yang belum tersedia saat itu. Keduanya mungkin sama jika kedatangan sinkron adalah jaminan nyata yang dapat diaudit, tetapi asumsi itu tidak boleh dianggap sebagai fakta secara default.

Lanjutan 2: Haruskah pemrosesan batch dan stream menggunakan kode yang persis sama?

Kode bersama mengurangi perbedaan dan patut diutamakan, tetapi itu bukan satu-satunya desain yang valid. Mesin eksekusi, manajemen status, atau persyaratan kinerja mungkin memerlukan dua implementasi berbeda. Dalam kasus tersebut, bagikan kontrak dan data pengujian, verifikasi kesetaraan dengan golden case, pengujian batas, dan pemutaran ulang event historis, serta jadikan pengujian perbedaan sebagai gerbang rilis.

Lanjutan 3: Bagaimana event yang terlambat mengoreksi fitur jendela online?

Pertama, tentukan keterlambatan yang diizinkan dan aturan penutupan jendela waktu. Event di dalam interval tersebut dapat dideduplikasi dan memperbarui jendela yang terpengaruh, sementara hanya versi fitur yang lebih baru yang boleh menimpa nilai online. Event di luar interval tersebut masuk ke proses koreksi atau backfill. Apakah data pelatihan masa lalu berubah bergantung pada mode dataset: as-known mereproduksi serving masa lalu, sementara corrected mencerminkan kebenaran terbaru. Simpan keduanya secara terpisah.

Lanjutan 4: Bagaimana Anda memutuskan apakah akan mematerialisasi atau menghitung fitur saat diminta (on demand)?

Bandingkan biaya komputasi, penggunaan ulang, kesegaran, latensi pengambilan, dan risiko paritas. Agregat jendela di banyak event historis yang sering digunakan kembali dan sensitif terhadap latensi adalah kandidat kuat untuk materialisasi. Fitur murah khusus permintaan tanpa kebutuhan pelatihan historis adalah kandidat yang baik untuk komputasi saat baca. Perhitungkan juga biaya backfill dan potensi titik kegagalan, alih-alih hanya melihat waktu CPU untuk satu permintaan.

Lanjutan 5: Bagaimana definisi fitur dapat berubah tanpa mengganggu serving?

Rilis versi set fitur baru dan materialisasikan versi lama serta baru secara paralel. Validasi skema dan cakupan, lakukan shadow-read pada entitas online, dan bandingkan dampak model sebelum mengalihkan sebagian kecil traffic ke model baru. Model lama tetap terkunci pada versi lama, dan data lama tetap disimpan selama jendela rollback. Jangan pernah mengganti semantik di tempat dengan nama yang sama.

Lanjutan 6: Bagaimana jika hasil floating-point offline dan online tidak identik?

Pisahkan kesalahan numerik yang dapat diterima dari perbedaan semantik. Deklarasikan toleransi absolut atau relatif per fitur dan gunakan aturan null, zona waktu, pembulatan, dan batas jendela yang sama. Perbedaan sistematis berdasarkan entitas atau batas harus diperlakukan sebagai kesalahan. Jangan menggunakan satu toleransi global yang longgar untuk menyembunyikan kesalahan join, pemotongan presisi, atau urutan agregasi yang berbeda.

Lanjutan 7: Haruskah serving gagal atau mengalami degradasi saat online feature store tidak tersedia?

Keputusan bergantung pada risiko dan kemampuan pemulihan (recoverability). Rekomendasi berisiko rendah dapat menggunakan cache atau peringkat baseline untuk sementara. Keputusan fraud berisiko tinggi dapat dialihkan ke peninjauan manual, menggunakan aturan konservatif, atau menolak permintaan yang tidak dapat dinilai dengan aman. Strategi ini harus diikutsertakan dalam pelatihan dan latihan simulasi, mencatat alasannya, serta memiliki batas durasi dan volume traffic agar mode kegagalan tidak menjadi operasi normal.

Lanjutan 8: Bagaimana Anda membuktikan bahwa pipeline baru berhasil mengurangi training-serving skew?

Pilih permintaan historis yang mencakup kasus normal, hilang, batas jendela, terlambat, dan di-backfill, lalu simpan vektor online aktual beserta versinya. Bangun kembali secara offline pada prediction_at yang sama dari event immutable, lalu bandingkan setiap nilai dan statusnya. Lanjutkan pengambilan sampel rekonsiliasi yang sama setelah peluncuran dan tetapkan syarat agar tingkat ketidakcocokan tetap berada di bawah batas yang telah ditentukan. Grafik distribusi dan metrik model melengkapi bukti ini; keduanya tidak dapat menggantikan pemutaran ulang pada permintaan yang sama.