Jebakan single run
Kesalahan paling umum dalam eksekusi eksperimen TI? Single run. Seorang peneliti menjalankan eksperimen sekali, mendapat angka, lalu melaporkannya sebagai "hasil penelitian."
Tapi satu run tidak cukup untuk membuat klaim ilmiah. Hasil dari satu run bisa dipengaruhi oleh:
- Variasi stokastik: random initialization, data shuffling, non-determinisme GPU
- Kondisi sesaat: beban CPU saat itu, caching OS yang bervariasi
- Kebetulan: split data yang kebetulan mudah
Eksperimen yang valid harus dijalankan multiple times untuk memastikan hasilnya stabil — bukan artefak dari satu kondisi lucky. Berapa kali? Cukup banyak untuk menghitung statistik deskriptif yang bermakna: rata-rata, standar deviasi, dan confidence interval.
Experiment Execution Pipeline
Alur dari desain ke dataset yang siap analisis:
Design → Execution Plan: desain eksperimen (skenario, variabel, metrik) diterjemahkan menjadi rencana eksekusi konkret: berapa skenario, berapa run per skenario, random seed apa, urutan eksekusi bagaimana.
Execution Plan → Controlled Execution: setiap skenario dijalankan sesuai rencana. "Controlled" berarti: satu variabel berubah per skenario, semua variabel kontrol dijaga, environment konsisten di setiap run.
Controlled Execution → Data Collection: output dari setiap run dikumpulkan: metrik yang diukur, prediksi per-sampel, waktu eksekusi, resource usage.
Data Collection → Data Logging: data mentah distrukturkan dengan metadata: run ID, timestamp, konfigurasi yang digunakan, environment info.
Data Logging → Dataset for Analysis: log divalidasi: apakah semua run tercatat? Apakah ada data yang hilang? Apakah format konsisten?
Prinsip pengumpulan data yang solid
Kelengkapan: semua skenario yang direncanakan harus dieksekusi dan dicatat. Skenario yang "hampir selesai tapi gagal di run terakhir" tidak boleh dimasukkan ke analisis seolah-olah selesai — kegagalan ini harus dilaporkan.
Konsistensi format: jika format log berubah di tengah eksperimen (misalnya script diperbarui), seluruh data sebelumnya perlu diverifikasi ulang.
Traceability: setiap data point harus bisa ditelusuri ke run spesifik dengan konfigurasi spesifik. Ini bukan formalitas — ini yang memungkinkan debugging ketika ada anomali.
Real-time logging: lebih baik log terlalu banyak daripada terlalu sedikit. Data yang tidak dilog tidak bisa direkonstruksi. Simpan parameter, environment state, dan timestamp untuk setiap run.
Menangani eksperimen yang gagal di tengah jalan
Eksperimen tidak selalu berjalan mulus. Hardware crash, timeout, atau error di run ke-7 dari 10 adalah situasi yang mungkin terjadi. Protocol yang baik:
- Dokumentasikan kegagalan secaraeksplisit — jangan sembunyikan atau abaikan
- Tentukan sebelumnya berapa minimum run yang cukup untuk analisis
- Jika perlu menjalankan ulang, pastikan kondisi environment identik dengan run sebelumnya
- Laporkan dalam metodologi berapa run yang berhasil dari berapa yang direncanakan
Transparansi tentang kegagalan parsial lebih dihargai reviewer daripada laporan yang terlihat mulus tapi menyembunyikan ketidaklengkapan.
