---
marp: true
paginate: true
class: bagian-iii
header: 'RTI — Riset Teknologi Informasi | Universitas Putra Bangsa Kebumen'
footer: 'Helmi Bahar Alim, S.Kom., M.Kom. | 2026'
---
# Bab 11 — Data Validation & Integrity
## Memastikan Data yang Dikumpulkan Dapat Dipercaya
*Pertemuan 11 (M11) | Sub-CPMK 3.3 | CPMK03 | CPL06*
Fase: **Executing** (M9–M11) · Bagian III: Execution
**Universitas Putra Bangsa** | Fak. Sains & Teknologi · Prodi Teknik Informatika
---
## Agenda Pertemuan 11
1. Mengapa validasi data itu urusan peneliti, bukan pre-processing
2. Data Trust Model — pipeline dari Raw ke Analysis Ready
3. Empat Pilar Kualitas Data
4. Proses validasi step-by-step
5. Anomaly detection — outlier, missing values, inkonsistensi
6. Alignment data–eksperimen
7. Cognitive Traps & Studi Kasus
8. Output Praktis: Dataset Tervalidasi + Catatan Anomali
---
## Capaian Pembelajaran
Setelah pertemuan ini, mahasiswa mampu:
- Menjelaskan perbedaan **validasi data** dan **preprocessing data**
- Menerapkan **4 pilar kualitas data** sebagai kriteria penerimaan dataset
- Melaksanakan proses validasi (format → range → consistency → logic)
- Mendokumentasikan **anomali** yang ditemukan dan keputusan yang diambil
- Memeriksa **alignment** antara data yang dikumpulkan dan desain eksperimen
> Sub-CPMK 3.3 → Memvalidasi integritas data eksperimen (CPL06)
---
## Data Trust Model
*Setiap langkah harus meningkatkan kepercayaan terhadap data*
**Raw Data** (dari eksperimen) ↓ Data Cleaning (format, struktur) ↓ Consistency Check (antar-run, antar-skenario) ↓ Validation (range, logic, alignment) ↓ Trusted Data (dengan dokumentasi anomali) ↓ **Analysis Ready** (siap Bab 13)
> Validasi ≠ Preprocessing. Validasi memastikan data **benar**. Preprocessing mempersiapkan data untuk **analisis**. Urutannya tidak bisa dibalik.
---
## Empat Pilar Kualitas Data
*Standar yang harus dipenuhi oleh setiap dataset penelitian*
| Pilar | Definisi | Pertanyaan Kunci | Contoh Pelanggaran |
|-------|---------|-----------------|-------------------|
| **Accuracy** (Akurasi) | Data mencerminkan fenomena yang diukur | Apakah nilai ini masuk akal? | F1=1.02 (mustahil) |
| **Consistency** (Konsistensi) | Tidak ada kontradiksi dalam dataset | Apakah run yang sama menghasilkan format yang sama? | Skenario A: nilai 0–1, Skenario B: nilai 0–100 |
| **Completeness** (Kelengkapan) | Semua yang seharusnya ada, ada | Adakah run yang hilang? | 10 run direncanakan, 8 di CSV |
| **Validity** (Validitas) | Data sesuai dengan definisi variabel dalam desain | Apakah yang diukur sesuai dengan RQ? | Mengukur accuracy padahal RQ butuh recall |
---
## Proses Validasi Data — 4 Tahap
### Tahap 1 — Format Validation
```python
# Cek struktur CSV
import pandas as pd
df = pd.read_csv('exp03_summary.csv')
print(df.dtypes) # Apakah kolom numerik dibaca sebagai float?
print(df.shape) # Apakah jumlah baris sesuai rencana?
print(df.isnull().sum()) # Apakah ada missing values?
```
### Tahap 2 — Range Validation
```python
# Validasi range metrik
assert (df['f1_micro'] >= 0).all() and (df['f1_micro'] <= 1).all(), "F1 out of range!"
assert (df['precision'] >= 0).all() and (df['precision'] <= 1).all(), "Precision out of range!"
assert (df['time_sec'] > 0).all(), "Training time harus positif!"
```
---
## Proses Validasi Data — Lanjutan
### Tahap 3 — Consistency Check
```python
# Cek jumlah run per skenario (harus 10 per skenario)
run_counts = df.groupby('scenario')['run_id'].count()
print(run_counts)
# Output yang diharapkan:
# scenario
# attention 10
# baseline 10
# no-attention 10
```
### Tahap 4 — Logic Validation (Alignment dengan Desain)
```
□ Semua skenario yang direncanakan ada di dataset?
□ Semua random seed yang dijadwalkan tereksekusi?
□ Metrik yang ada di dataset ← sesuai dengan RQ dan hipotesis?
□ Satuan metrik konsisten? (0–1 atau 0–100%?)
```
---
## Anomaly Detection
*Tiga jenis anomali yang paling sering ditemukan:*
### 1. Outlier Statistik
```python
from scipy import stats
z_scores = stats.zscore(df['f1_micro'])
outliers = df[abs(z_scores) > 3]
print("Outliers:", outliers)
```
Jika ditemukan outlier → **jangan langsung dibuang**. Investigasi dulu:
- Apakah log menunjukkan sesuatu yang aneh pada run tersebut?
- Apakah hardware state berbeda?
- Dokumentasikan alasan, baru putuskan: retain atau exclude with justification.
### 2. Missing Values
Cek cross-referensi dengan execution log. Run hilang = re-run jika memungkinkan.
### 3. Inkonsistensi Format
Contoh: kolom `time_sec` yang seharusnya float, tertuliskan "N/A" di beberapa baris.
---
# Cognitive Traps
## Bab 11 — Data Validation
---
## Cognitive Traps — Bab 11
**"Data dari eksperimen saya sendiri pasti sudah benar"**
Eksperimen yang dirancang baik pun bisa menghasilkan data yang cacat karena bug kecil, kondisi hardware, atau kesalahan konfigurasi. Validasi bukan soal ketidakpercayaan — tapi standar ilmiah.
**"Outlier dibuang karena pasti error"**
Outlier bisa menjadi temuan paling menarik dalam penelitian. Membuang outlier tanpa investigasi = kehilangan insight + manipulasi data. Selalu dokumentasikan outlier dan alasan keputusan.
**"Validasi data itu sama dengan preprocessing"**
Validasi = memastikan data benar (integritas). Preprocessing = mempersiapkan data untuk analisis (transformasi). Urutan wajib: validasi dulu, baru preprocessing. Tidak bisa dibalik.
**"Kalau run-nya banyak, satu yang error tidak apa-apa"**
Setiap run yang cacat mempengaruhi mean dan std. Dalam 10 run, 1 run error = 10% data rusak = seluruh analisis terdampak.
---
## Studi Kasus 1 — Data Inconsistency (Basic)
**Konteks:** Mahasiswa membandingkan Model A vs Model B, 10 run masing-masing.
**Masalah yang ditemukan saat validasi:**
- Model A: F1-score dalam skala 0–1 (0.872, 0.865, dst)
- Model B: F1-score dalam skala 0–100 (87.5, 86.2, dst)
- Keduanya berasal dari library yang berbeda (sklearn vs torchmetrics)
**Dampak jika tidak divalidasi:**
- Model A mean = 0.869
- Model B mean = 86.8 → tampak 100x lebih buruk
- Analisis komparatif menjadi tidak valid
**Solusi:** Normalisasi ke skala yang sama **setelah validasi mengidentifikasi ini**, dan dokumentasikan dalam catatan preprocessing.
---
## Studi Kasus 2 — Missing Runs + Outlier (Advanced)
**Konteks:** 10 run direncanakan per skenario. Dataset hanya berisi 9 run. Run ke-7 juga tampak anomali (F1 = 0.342, jauh di bawah mean 0.87).
**Investigasi:**
1. **Missing run:** Cross-cek dengan execution log → run ke-6 gagal karena `CUDA OOM` dan tidak di-log dengan benar
2. **Outlier run-7:** Log menunjukkan GPU temperature spike 85°C selama run → thermal throttling aktif
**Keputusan yang didokumentasikan:**
```
Anomali 1 — Run ke-6: Eksekusi gagal (CUDA OOM).
Keputusan: Re-run dengan batch_size=16 (bukan 32).
Anomali 2 — Run ke-7: Thermal throttling aktif (85°C).
Keputusan: Exclude dari analisis. Alasan: kondisi hardware tidak normal.
Pengganti: Re-run dengan server di ruangan ber-AC.
```
---
## Dokumentasi Catatan Validasi
*Setiap keputusan tentang data harus terdokumentasi*
```
DATA VALIDATION REPORT — Eksperimen 3
Tanggal validasi: 2026-05-02
Peneliti: [Nama]
HASIL VALIDASI FORMAT : PASS — semua kolom sesuai tipe yang diharapkan
HASIL VALIDASI RANGE : PASS — semua nilai F1 dalam [0,1]
HASIL VALIDASI KONSISTENSI: FAIL → lihat anomali 1
HASIL VALIDASI ALIGNMENT : PASS — semua metrik sesuai RQ
ANOMALI YANG DITEMUKAN:
[ANO-01] Run exp03_s1_r6: Missing. Penyebab: CUDA OOM.
Keputusan: Re-run. Status: Selesai (exp03_s1_r6b).
[ANO-02] Run exp03_s1_r7: Outlier (F1=0.342). Penyebab: Thermal throttling.
Keputusan: Exclude + re-run (exp03_s1_r7b).
STATUS AKHIR: Dataset valid. Siap untuk preprocessing.
```
---
## Research vs Ad-Hoc — Data Handling
| Aspek | Ad-Hoc | Research |
|-------|--------|---------|
| Validasi data | Langsung analisis | Validasi dulu sebelum apapun |
| Outlier | Dibuang atau diabaikan | Investigasi + dokumentasi keputusan |
| Missing data | Di-impute langsung | Cari tahu penyebab, pertimbangkan re-run |
| Format inconsistency | "Nanti saja saat analisis" | Temukan saat validasi, perbaiki dengan dokumentasi |
| Laporan | Hanya hasil | Hasil + catatan anomali + audit trail |
---
## Ringkasan Pertemuan 11
| Konsep | Inti |
|--------|------|
| Data Trust Model | Raw → Cleaning → Consistency → Validation → Trusted → Analysis Ready |
| 4 Pilar | Accuracy, Consistency, Completeness, Validity |
| Proses Validasi | Format → Range → Consistency → Logic (4 tahap) |
| Anomaly Handling | Investigasi dulu → keputusan berbasis bukti → dokumentasi |
| Output Wajib | Dataset tervalidasi + Catatan anomali + Validation report |
---
## Final Statement & Output Praktis
"Data yang divalidasi dengan buruk adalah fondasi yang retak — bangunan analisis di atasnya, sebagus apapun, tidak akan dapat dipercaya."
### Output Praktis M11
Kumpulkan dan lampirkan:
1. **Dataset tervalidasi** (`exp_summary_validated.csv`)
2. **Validation report** (format bebas, isi sesuai template catatan validasi)
3. **Catatan anomali** — setiap anomali yang ditemukan dan keputusan yang diambil
*Dataset ini menjadi input untuk Preprocessing (Bab 13) dan Presentasi Hasil (Bab 12).*
---
## Referensi Utama — Bab 11
- Pipino, L. L., Lee, Y. W., & Wang, R. Y. (2002). Data quality assessment. *Communications of the ACM, 45*(4), 211–218.
- Strong, D. M., Lee, Y. W., & Wang, R. Y. (1997). Data quality in context. *Communications of the ACM, 40*(5), 103–110.
- Rahm, E., & Do, H. H. (2000). Data cleaning: Problems and current approaches. *IEEE Data Engineering Bulletin, 23*(4), 3–13.
- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in software engineering*. Springer.