Cara Mencatat Hallucination agar Bisa Dibandingkan dari Waktu ke Waktu

Satu screenshot bisa bikin grup WhatsApp kantor ramai.

“ChatGPT bilang kantor kita di Surabaya.”

“Padahal nggak pernah.”

“Coba Gemini.”

“Di sini benar.”

“Perplexity beda lagi.”

Sepuluh menit kemudian sudah ada empat screenshot, tiga prompt yang tidak sama, dua orang memakai akun berbeda, dan satu kesimpulan besar:

“AI belum bisa dipercaya.”

Masalahnya bukan kekhawatiran itu tidak valid.

Masalahnya data yang dikumpulkan tidak cukup rapi untuk dibandingkan.

Kalau sebuah brand serius ingin memonitor hallucination, evidence harus lebih kuat daripada album screenshot.

OpenAI mendefinisikan hallucination sebagai pernyataan yang tampak masuk akal tetapi salah. NIST dalam Generative AI Profile memasukkan confabulation sebagai risiko yang perlu diidentifikasi dan dikelola. Untuk organisasi, implikasinya jelas: error perlu didokumentasikan dengan cara yang dapat diaudit.

Bukan untuk membuat dashboard keren.

Supaya kita bisa menjawab pertanyaan dasar:

Apakah error membaik?
Memburuk?
Berpindah?
Hanya terjadi di satu surface?
Muncul setelah perubahan data?
Terjadi pada claim yang sama?
Atau sebenarnya kita sedang membandingkan kondisi tes yang berbeda?

Mulai dari unit terkecil: claim

Jangan mencatat “jawaban AI salah” sebagai satu baris.

Satu answer bisa punya lima claim.

Contoh:

“PT Arunika Digital berkantor di Bandung, didirikan pada 2018, memiliki tiga cabang, menawarkan layanan A, dan CEO-nya Budi.”

Mungkin:

Bandung salah.
2018 benar.
Tiga cabang salah.
Layanan A benar.
CEO Budi sudah tidak menjabat.

Kalau seluruh answer diberi label “hallucination”, kita kehilangan resolution.

Lebih berguna membuat setiap claim sebagai unit evaluasi.

Claim ID: BR-LOCATION-HQ-001.
Claim text observed: “Berkantor pusat di Bandung.”
Ground truth: “Jakarta.”
Status: false.
Error type: entity/location.
Severity: medium.
Evidence source: official contact page.
Effective date: current as of test date.

Dengan format claim-level, kita bisa melihat pola.

Mungkin lokasi sering salah.
Mungkin leadership selalu benar.
Mungkin harga paling volatile.

Itu baru berguna untuk governance.

Pisahkan observed answer dan ground truth

Jangan mengedit screenshot lalu menulis versi “yang kita maksud”.

Simpan output apa adanya.

Observed answer adalah evidence tentang sistem.

Ground truth adalah evidence tentang dunia yang ingin diverifikasi.

Dua hal itu harus terpisah.

Untuk ground truth, catat sumber.

Official website?
Regulator?
Product database?
Contract?
Public filing?
Owner internal?
Merchant feed?
Business profile?

Tidak semua ground truth punya bobot yang sama.

Untuk klaim legal, dokumen legal lebih kuat daripada blog.

Untuk harga real-time, commerce database lebih berguna daripada press release.

Untuk alamat aktif, official location page dan business profile current lebih relevan daripada berita pembukaan cabang tiga tahun lalu.

Hallucination log yang tidak punya ground truth hanya menjadi daftar ketidaksukaan.

Kita perlu bisa menunjukkan kenapa claim dinilai salah.

Timestamp bukan detail administratif

Tanggal dan waktu wajib.

Model berubah.
Search index berubah.
Source berubah.
Website berubah.
Prompt context berubah.
Product settings berubah.

Jawaban 1 Juli dan 1 Agustus tidak bisa diperlakukan seolah terjadi pada environment identik.

Minimal catat:

tanggal,
waktu,
timezone,
platform,
model atau surface jika ditampilkan,
account state bila relevan,
locale,
language,
web/search mode bila terlihat,
device tidak selalu penting tetapi bisa dicatat jika surface berbeda.

Untuk Indonesia, timezone WIB/WITA/WIT perlu jelas jika monitoring lintas tim.

Jangan hanya menulis “Agustus”.

Kalau terjadi incident, hari dan jam bisa penting.

Prompt harus disimpan exact

Ini salah satu sumber noise terbesar.

Tester A bertanya:

“Berapa harga produk X?”

Tester B:

“Berapa harga terbaru produk X di Jakarta?”

Tester C:

“Berdasarkan website resmi, berapa harga produk X per Agustus 2026?”

Mereka bukan query yang sama.

Jawaban berbeda tidak otomatis berarti model unstable.

Intent dan constraints berbeda.

Karena itu log harus menyimpan exact prompt.

Jika ingin mengukur perubahan dari waktu ke waktu, gunakan frozen query set.

Contoh:

Q01: “Apa alamat kantor pusat Brand X?”
Q02: “Apa layanan utama Brand X?”
Q03: “Berapa harga Paket Y saat ini?”
Q04: “Siapa yang mengoperasikan Produk Z?”

Jangan mengubah wording setiap minggu tanpa memberi version.

Kalau query berubah, version-kan.

Q03-v1.
Q03-v2.

Seperti eksperimen normal.

Source capture harus lebih dari citation count

Jika answer menampilkan source, simpan:

URL,
title,
domain,
tanggal source bila tersedia,
posisi atau konteks citation,
apakah source official,
apakah source benar,
apakah source stale,
apakah source sebenarnya mendukung claim.

Citation bukan sinonim correctness.

AI bisa mengutip sumber kredibel tetapi mengambil konteks yang tidak tepat.

Atau source benar untuk 2024 tetapi tidak untuk 2026.

Atau source tidak pernah mengatakan claim yang dibuat.

Jadi field “cited: yes” terlalu dangkal.

Tambahkan source support status:

supports,
partially supports,
contradicts,
stale,
unclear,
not accessible.

Ini membuat analisis jauh lebih tajam.

Buat taxonomy error yang stabil

Tidak perlu 50 kategori pada hari pertama.

Mulai dengan yang berguna.

Entity confusion:
mencampur dua organisasi/orang/produk.

Stale fact:
fakta lama disajikan sebagai current.

Unsupported fabrication:
claim tidak ditemukan support yang masuk akal.

Incorrect synthesis:
source benar tetapi digabung menjadi kesimpulan salah.

Numeric error:
harga, jumlah, persentase, tanggal, ukuran.

Location error:
alamat, cabang, area operasi.

Capability error:
fitur atau layanan yang salah.

Attribution error:
mengaitkan quote, tindakan, produk, atau kebijakan ke entity yang salah.

Temporal error:
urutan waktu atau status sekarang keliru.

Policy error:
syarat, refund, eligibility, legal policy salah.

Taxonomy ini adalah internal tool, bukan standar universal.

Yang penting konsisten.

Kalau definisi kategori berubah tiap minggu, trend tidak bisa dibaca.

Severity juga harus konsisten

Frequency tanpa severity bisa menipu.

Bayangkan dua bulan:

Bulan A: 20 error typo lokasi minor.
Bulan B: 3 error, tetapi satu menyebut produk medis memiliki indikasi yang tidak benar.

Secara jumlah, B “lebih baik”.

Secara risiko, belum tentu.

Gunakan severity matrix.

Pertimbangkan:

potential harm,
buyer impact,
legal/regulatory impact,
financial impact,
reputational impact,
reversibility,
likelihood user acts on answer.

Low, medium, high, critical cukup untuk awal.

Dokumentasikan definisinya.

Jangan ubah rating karena manajemen ingin grafik hijau.

Tambahkan reproducibility

Satu error yang muncul sekali berbeda dari error yang muncul 8 dari 10 kali.

Lakukan repeated tests dengan batas wajar.

Catat:

attempt count,
error count,
correct count,
unknown/abstain,
variation.

Contoh:

Q02, 10 runs.
Correct: 6.
Incorrect: 3.
Abstain/uncertain: 1.

Sekarang kita punya hallucination frequency untuk query itu, pada environment dan periode tersebut.

Jangan menyebut angka ini sebagai “hallucination rate model global”.

Itu hanya rate pada test set Anda.

Scope matters.

Baseline sebelum correction

Kalau ingin tahu apakah perbaikan sumber membantu, jangan memperbaiki dulu baru mulai mengukur.

Ambil baseline.

Misalnya:

1–7 Agustus:
error alamat muncul 7/10.

8 Agustus:
website diperbarui,
directory dikoreksi,
schema disinkronkan,
old page diberi redirect.

15–21 Agustus:
error muncul 2/10.

Apakah correction menyebabkan improvement?

Mungkin.

Belum tentu.

Model atau index bisa berubah pada periode yang sama.

Source selection bisa berubah.

Jadi tulis sebagai observed association, bukan causal proof.

Kalau mau stronger evidence, desain test lebih ketat.

Tetapi bahkan observational log sederhana sudah jauh lebih baik daripada memory manusia.

Correction log harus terhubung

Hallucination log menjawab:

apa yang salah.

Correction log menjawab:

apa yang kita ubah.

Hubungkan dengan ID.

Incident H-2026-0812-004.
Correction C-2026-0813-002.

Action:
update official page,
add effective date,
deprecate old PDF,
request directory correction.

Owner:
Corporate Communications.

Completed:
13 Agustus.

Retest:
20 Agustus.

Result:
error frequency turun pada query set.

Sekarang organisasi punya learning loop.

Bukan sekadar panik.

Dashboard yang berguna tidak perlu ramai

Metrik yang bisa dipakai:

total tested claims,
incorrect claim count,
high-severity error count,
repeatable error count,
stale-source error count,
entity-confusion count,
correction backlog,
median correction age,
error persistence after correction.

Untuk multi-platform:

platform distribution,
source overlap,
claim agreement,
citation support rate.

Tetapi hati-hati membuat satu “AI Trust Score” lalu menganggapnya objective truth.

Bobotnya akan tergantung definisi internal.

Lebih baik tunjukkan komponen.

Transparency lebih penting daripada angka cantik.

Simpan evidence, tetapi jaga privasi

Monitoring bisa menyentuh data sensitif.

Jangan memasukkan prompt yang mengandung data pelanggan, health record, credential, kontrak rahasia, atau informasi internal hanya demi test.

Gunakan public claims atau synthetic test data jika cukup.

Kalau testing memang membutuhkan data terbatas, governance akses dan retention harus jelas.

Evidence system yang buruk bisa menciptakan risiko baru.

Retest bukan berarti spam

Tidak perlu mengirim query yang sama ratusan kali setiap jam.

Sampling harus proportional terhadap risk dan volatility.

Harga dinamis mungkin perlu lebih sering.

Nama legal jarang berubah.

Informasi emergency atau regulated bisa mendapat monitoring lebih ketat.

Satu cadence untuk semua claim justru tidak efisien.

Pikirkan risk-adjusted monitoring.

Kapan log mulai bernilai?

Bukan setelah punya ribuan baris.

Nilai pertama muncul ketika tim bisa mengatakan:

“Ini bukan feeling.”

“Error alamat meningkat sejak perubahan cabang.”

“Dua platform masih mengambil source lama.”

“Service hallucination tidak reproducible.”

“Price error hanya muncul pada prompt tanpa kata ‘terbaru’.”

“Koreksi source A diikuti penurunan error, tetapi kita belum menganggapnya causal.”

Itu percakapan yang jauh lebih dewasa.

NIST mendorong organisasi mengidentifikasi, mengukur, dan mengelola risiko GenAI. Hallucination log sederhana adalah salah satu implementasi praktis yang bisa membantu, selama kita tidak mengklaim format internal sebagai standar resmi.

Satu screenshot tetap berguna.

Ia adalah evidence satu kejadian.

Yang tidak boleh adalah memperlakukannya sebagai seluruh realitas.

Kalau kita ingin membandingkan hallucination dari waktu ke waktu, disiplin pengukuran harus lebih kuat daripada rasa kaget.

Simpan claim.
Simpan prompt.
Simpan waktu.
Simpan source.
Simpan ground truth.
Simpan severity.
Simpan correction.
Retest dengan metode yang sama.

Setelah beberapa minggu, pola mulai terlihat.

Dan ketika pola terlihat, tim tidak lagi bertanya hanya, “Kenapa AI salah?”

Pertanyaannya naik kelas:

“Error apa yang paling persisten, source mana yang ikut berperan, correction mana yang tampaknya efektif, dan risiko apa yang masih belum kita kendalikan?”

Itulah fungsi sebuah hallucination log yang benar-benar berguna.