Periksa semuanya dengan murah, teliti sedikit kasus yang memerlukannya

Bayangkan kumpulan ilustratif berisi 10.000 pembaruan kontak. Setiap catatan bisa dikirim ke model untuk menilai kembali bidang-bidangnya. Itu mengubah satu keputusan pemetaan menjadi 10.000 keputusan berulang.

Mulailah dari pertanyaan yang lebih murah: apakah catatan ini memenuhi kondisi yang sudah diketahui dari pemetaan yang disetujui? Periksa keberadaan bidang, tipe data, versi skema, dan syarat persetujuan yang eksplisit dengan kode. Teruskan catatan yang gagal atau tetap ambigu ke tinjauan yang lebih khusus.

Ini rancangan ilustratif, bukan tolok ukur Tajo. Angka penting bukan berapa banyak catatan yang lolos pemeriksaan awal, melainkan berapa banyak kesalahan penting yang keliru diloloskan.

Alur kerja khusus yang dibahas dalam sumber ini dimulai dengan klasifikasi luas antara normal dan tidak normal, lalu menganalisis lebih lanjut kasus yang ditandai. Ranahnya mempunyai risiko dan bukti yang berbeda dari data pemasaran. Sumber itu menunjukkan keputusan bertahap, bukan biaya atau sifat deterministik algoritme pertamanya. Dalam integrasi, pemeriksaan deterministik yang murah dapat mencakup kondisi yang diketahui sebelum kasus tak pasti ditinjau lebih teliti.

Pemeriksaan awal harus menyelesaikan kasus rutin

Pemeriksaan awal yang baik mengajukan pertanyaan yang dapat dijawab kode dari bukti yang tersedia. “Apakah bidang sumber ada?” adalah satu contoh. “Apakah nilai ini sesuai dengan tipe yang dinyatakan sistem tujuan?” adalah contoh lain. “Apakah versi skema ini sama dengan versi saat pemetaan disetujui?” adalah contoh ketiga.

Aturan dapat dijalankan pada setiap baris tanpa menciptakan tafsir baru untuk tiap baris. Aturan juga dapat menjelaskan jawabannya. Baris yang ditolak bisa menyatakan bahwa bidang birthday di sistem tujuan memerlukan tanggal, tetapi sumber mengirim teks bebas. Itu lebih berguna daripada “keyakinan AI rendah”.

Panduan konektor Brevo dari Tajo menjelaskan mengapa definisi atribut di sistem tujuan penting. Konektor dapat berhasil mengirim permintaan HTTP, sementara sistem penerima mengabaikan atribut yang belum dideklarasikan. Pemeriksaan awal atas bidang yang terdaftar menangkap satu jenis kesalahan sebelum penulisan. Pembacaan ulang kemudian dapat menangkap jenis lain. Keduanya berbeda dari pendapat model bahwa suatu kontak “tampak baik”.

Tujuannya bukan menghilangkan penilaian, melainkan menyimpannya untuk pertanyaan yang memang membutuhkan penilaian.

1. Kumpulan sinkronisasi baru

2. PERTAMA

   Periksa aturan yang diketahui

   • Identitas, tipe bidang, dan cakupan akun
3. LALU

   Putuskan kasus yang jelas

   • Loloskan catatan rutin; tahan kegagalan yang dikenal
4. JIKA DIPERLUKAN

   Tinjau kasus yang belum tuntas

   • Periksa bukti yang belum dapat diputuskan aturan

5. Hasil terverifikasi atau penahanan eksplisit

Pemeriksaan mahal harus menerima kasus yang tepat

Misalkan 9.800 dari 10.000 catatan ilustratif lolos pemeriksaan awal. Dua ratus sisanya diperiksa lebih dekat. Itu terdengar efisien. Belum ada kesimpulan tentang ketepatan sampai seseorang memeriksa sampel dari 9.800 itu dan hasil dari 200 sisanya.

Pemeriksaan awal mempunyai dua jenis kesalahan. Ia bisa menandai kasus rutin sehingga waktu tinjauan terbuang. Lebih serius, ia bisa meloloskan kasus yang seharusnya dihentikan. Kesalahan mana yang lebih mahal bergantung pada alurnya. Label opsional yang hilang dan izin mengirim email pemasaran yang tidak ada tidak boleh memakai batas yang sama.

Keberatan yang wajar adalah: “Jika model memahami tiap catatan, mengapa mempercayai aturan yang rapuh?” Catatan rutin yang berulang tidak menjadi lebih benar hanya karena model ditanya sekali lagi. Kelemahan aturan terlihat jelas: ketika kontrak sumber atau tujuan berubah, asumsinya dapat kedaluwarsa. Karena itu pantau kontrak dan ambil sampel kasus yang diterima, bukan mengganti semua pemeriksaan stabil dengan penilaian tanpa batas.

Kasus yang diteruskan juga tidak selalu perlu tinjauan manusia penuh. Kesalahan penyedia yang dikenal mungkin hanya membutuhkan perbaikan terdokumentasi. Arti bidang yang benar-benar baru mungkin memerlukan agen untuk mengusulkan pemetaan. Ambiguitas persetujuan mungkin perlu penanggung jawabnya. Pemeriksaan awal harus mengarahkan tiap kasus ke otoritas terkecil yang mampu menyelesaikannya.

Panduan mengintegrasikan beberapa alat bisnis menguraikan pemilihan sumber kebenaran dan pemicu sebelum memilih alat. Keputusan itu menentukan pengecualian yang layak ditangani. Perbedaan pada bidang yang tidak dipakai proses berikutnya mungkin dapat menunggu. Perbedaan pada bidang yang memilih audiens kampanye tidak dapat menunggu.

Ukur kesalahan yang lolos, bukan hanya penghematan

Sistem bertahap dapat menghasilkan grafik menarik: banyak kasus diproses murah, sedikit yang diteruskan. Grafik itu belum lengkap. Tambahkan ukuran kedua: di antara kasus yang diloloskan pemeriksaan awal, berapa yang gagal dalam pemeriksaan tujuan berikutnya atau dalam peninjauan sampel independen?

Ukuran harus terkait dengan pekerjaan nyata. Jika tugasnya menjaga keselarasan kontak, periksa keadaan kontak di sistem tujuan. Jika tugasnya memelihara audiens, periksa siapa yang masuk dan dikecualikan. Jumlah kesalahan tanpa penyebut dan akibat lanjutannya mudah dirayakan, tetapi sulit dipercaya.

Percobaan praktis dapat dimulai kecil. Simpan kumpulan catatan rutin dan pengecualian yang telah ditinjau. Jalankan aturan murah pada kumpulan itu. Periksa setiap pengecualian yang terlewat. Lalu jalankan aturan sebagai pengamat atas lalu lintas nyata tanpa membolehkannya menyetujui perilaku baru. Hanya setelah kasus yang terlewat dipahami, aturan itu boleh menentukan kasus mana yang tidak memerlukan tinjauan mendalam.

Panduan reverse ETL membahas pemindahan data berulang di balik pekerjaan ini. Pertanyaan triase berada di samping pipeline tersebut: pengamatan apa yang menunjukkan bahwa aturan stabil kini tidak lagi stabil?

Gunakan tinjauan cermat di tempat pemeriksaan luas tidak mungkin mengetahui jawabannya.