riset-teknologi-informasi/slide/slide-10-experiment-execution.md

marp	paginate	class	header	footer
true	true	bagian-iii	RTI — Riset Teknologi Informasi | Universitas Putra Bangsa Kebumen	Helmi Bahar Alim, S.Kom., M.Kom. | 2026

Bab 10 — Experiment Execution & Data Collection

Dari Rencana ke Data yang Terpercaya

Pertemuan 10 (M10)  |  Sub-CPMK 3.2  |  CPMK03  |  CPL06

Fase: Executing (M9–M11)  ·  Bagian III: Execution

Universitas Putra Bangsa  |  Fak. Sains & Teknologi  ·  Prodi Teknik Informatika

---

Agenda Pertemuan 10

1. Execution plan: pentingnya perencanaan sebelum eksekusi
2. Experiment Execution Pipeline
3. Mengapa multiple run wajib
4. Struktur data logging yang benar
5. Konsistensi eksekusi — sama persis setiap kali
6. Data collection protokol
7. Cognitive Traps & Studi Kasus
8. Output Praktis: Log Eksperimen + Dataset Mentah

---

Capaian Pembelajaran

Setelah pertemuan ini, mahasiswa mampu:

• Menyusun execution plan yang detail sebelum menjalankan eksperimen
• Menerapkan multiple run dan menjelaskan alasan statistiknya
• Merancang struktur data logging yang komprehensif
• Memastikan konsistensi eksekusi di semua skenario dan run
• Menghasilkan dataset eksperimen mentah yang siap divalidasi

Sub-CPMK 3.2 → Melaksanakan eksperimen dan mengumpulkan data (CPL06)

---

Experiment Execution Pipeline

Dari desain ke dataset yang siap dianalisis

Design ↓ Execution Plan (sebelum eksperimen dimulai) ↓ Controlled Execution (skenario satu per satu) ↓ Data Collection (setiap metrik, setiap run) ↓ Data Logging (terstruktur, timestamped) ↓ Dataset for Analysis

Eksekusi tanpa execution plan = memasak tanpa resep. Mungkin jadi, tapi tidak terjamin konsistensinya.

---

Execution Plan — Apa yang Harus Ada

Sebelum menjalankan eksperimen pertama:

EXECUTION PLAN — Eksperimen [N]

Skenario yang akan dijalankan:
  Skenario 1: [kondisi A] — [parameter spesifik]
  Skenario 2: [kondisi B] — [parameter spesifik]
  Skenario 3: [baseline]  — [parameter spesifik]

Jumlah run per skenario: 10
Random seeds untuk tiap run: [42, 123, 456, 789, 1024, ...]

Urutan eksekusi:
  1. Skenario baseline → 10 runs
  2. Skenario 1 → 10 runs
  3. Skenario 2 → 10 runs

Estimasi waktu per run: 45 menit
Total waktu: ~22.5 jam

---

Mengapa Multiple Run Wajib?

Satu run tidak cukup karena:

1. Inisialisasi random (weight initialization, shuffle order) berbeda setiap run
2. Hardware variance (thermal throttling, background processes)
3. Satu run tidak bisa menghitung standard deviation → tidak bisa uji statistik

Runs	Yang Bisa Dihitung	Yang Tidak Bisa
1 run	Point estimate saja	± std, t-test, CI
3 run	Mean (terlalu kecil untuk distribusi)	Reliable CI
5 run	Mean ± std (minimum acceptable)	Large sample statistics
10+ run	Mean ± std + t-test + CI	—

Minimum dalam riset TI: 5 run. Disarankan 10 run untuk stabilitas statistik.

---

Struktur Data Logging

Setiap run harus menghasilkan log yang lengkap

log_entry = {
    "run_id": "exp03_run07",
    "timestamp": "2026-04-13T10:25:33",
    "experiment_id": "exp-03",
    "scenario": "attention-mechanism",
    "random_seed": 789,
    "config": {
        "model": "BiLSTM",
        "attention": True,
        "learning_rate": 1e-3,
        "batch_size": 32,
        "epochs": 50
    },
    "results": {
        "f1_micro": 0.872,
        "f1_macro": 0.815,
        "precision": 0.889,
        "recall": 0.856,
        "training_time_sec": 2723
    },
    "hardware": "RTX 3090, 24GB VRAM, CUDA 11.8"
}

---

Konsistensi Eksekusi — Checklist Setiap Run

Sebelum memulai setiap run, pastikan:

Item	Cek
Environment aktif (conda/venv)	conda activate rti-exp
Config file benar untuk skenario ini	cat configs/exp_03_s1.yaml
Random seed di-set	Set di numpy, torch, Python random
Dataset di lokasi yang benar + checksum OK	md5sum dataset.csv
GPU memory kosong	nvidia-smi
Log directory tersedia	mkdir -p logs/exp03/
Tidak ada proses berat yang berjalan	Tutup browser, aplikasi lain

Konsistensi eksekusi bukan paranoia — ini adalah standar ilmiah.

---

Cognitive Traps

Bab 10 — Experiment Execution

---

Cognitive Traps — Bab 10

"Satu run sudah cukup kalau hasilnya bagus" "Bagus" dalam satu run mungkin keberuntungan (lucky seed). Tanpa multiple run, tidak ada cara mengetahui apakah hasil tersebut stabil atau artifact dari kondisi spesifik satu eksekusi.

"Data logging berlebihan, cukup catat hasil akhir saja" Ketika ada anomali atau hasil yang tidak terduga, log yang lengkap adalah satu-satunya cara untuk menginvestigasi. Logging minimal = debugging impossible. Disk space murah, waktu investigasi mahal.

"Eksperimen bisa dijalankan sambil mengerjakan yang lain" Background processes mengkonsumsi CPU/GPU/RAM dan dapat mempengaruhi throughput dan latency measurement. Untuk eksperimen yang mengukur performa sistem, isolasi resource wajib.

---

Studi Kasus 1 — Single Run Disaster (Basic)

Konteks: Mahasiswa melaporkan F1=91.5%. Dosen meminta run ulang. Hasil: 84.2%.

Investigasi:

• Run pertama: lucky seed, distribusi batch training kebetulan balans
• Run ulang: seed berbeda, batch distribution berbeda
• Variance sangat tinggi: std = 3.7% → model tidak stabil

Tabel dari 5 run:

Run	Seed	F1-score
1	42	91.5% ← yang dilaporkan
2	123	84.2%
3	456	87.1%
4	789	85.8%
5	1024	86.3%
Mean ± Std		87.0 ± 2.6%

Pelajaran: F1 yang sebenarnya adalah 87.0 ± 2.6%, bukan 91.5%.

---

Studi Kasus 2 — Eksekusi Tidak Konsisten (Advanced)

Konteks: Researcher membandingkan dua model. Model A selalu dijalankan di pagi hari (server dingin), Model B di sore hari (server panas, thermal throttling aktif).

Hasil: Model A 15% lebih cepat dalam inference time.

Masalah: Perbedaan inference time bukan karena model — tapi karena kondisi hardware yang berbeda.

Protokol eksekusi yang benar:

1. Randomize urutan eksekusi per run (Model A/B dijalankan bergantian dalam satu sesi)
2. Jalankan warm-up run sebelum pengukuran (GPU dalam kondisi stabil)
3. Ukur hardware state sebelum setiap run (nvidia-smi, CPU temperature)
4. Catat semua di log

---

Format Dataset Mentah

Hasil semua run harus tersimpan dalam format yang terstruktur

results/
  exp03_summary.csv          ← semua run, semua skenario
  exp03_raw/
    run_01_seed42.json
    run_02_seed123.json
    ...
  exp03_config/
    scenario_1_attention.yaml
    scenario_2_baseline.yaml

Format exp03_summary.csv:

run_id,scenario,seed,f1_micro,f1_macro,precision,recall,time_sec
exp03_s1_r1,attention,42,0.872,0.815,0.889,0.856,2723
exp03_s1_r2,attention,123,0.865,0.810,0.882,0.849,2698
exp03_s2_r1,baseline,42,0.821,0.768,0.844,0.799,2511

---

Research vs Engineering — Execution

Aspek	Engineering	Research
Eksekusi	Run sekali, jika berhasil → selesai	Minimal 5 run per skenario
Kondisi eksekusi	Tidak disebutkan	Dikontrol dan didokumentasikan
Data yang disimpan	Hasil akhir saja	Semua run, semua metrik, semua log
Anomali	Dibuang / diabaikan	Dicatat dan diinvestigasi
Urutan eksekusi	Tidak penting	Randomized untuk menghindari order bias

---

Ringkasan Pertemuan 10

Konsep	Inti
Execution Pipeline	Design → Plan → Execution → Collection → Logging → Dataset
Multiple Run	Min. 5 runs → bisa hitung mean ± std → bisa uji statistik
Data Logging	Setiap run: ID, timestamp, config, result, hardware
Konsistensi	Checklist yang sama sebelum setiap run
Format Dataset	CSV summary + JSON detail per run + YAML config

---

Final Statement & Output Praktis

"Data yang baik bukan data yang banyak, tetapi data yang dikumpulkan dengan konsistensi metodologi yang ketat."

Output Praktis M10

Hasilkan dan kumpulkan:

1. Log eksperimen (minimal 5 run per skenario, format terstruktur)
2. Dataset mentah (results/exp_summary.csv + file per run)
3. Catatan anomali — apa yang terjadi di luar rencana selama eksekusi

Dokumen ini menjadi dasar untuk validasi data di Bab 11.

---

Referensi Utama — Bab 10

• Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). Experimentation in software engineering. Springer.

• Pineau, J., Vincent-Lamarre, P., Sinha, K., Larivière, V., Beygelzimer, A., d'Alché-Buc, F., Fox, E., & Larochelle, H. (2021). Improving reproducibility in machine learning research. Journal of Machine Learning Research, 22(1), 7459–7478.

• Hoefler, T., & Belli, R. (2015). Scientific benchmarking of parallel computing systems: Twelve ways to tell the masses when reporting performance results. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (pp. 1–12). ACM.