Berapa Kali Query Harus Diulang agar Hasil AI Search Layak Dibandingkan

Satu query. Satu screenshot. Satu kesimpulan.

Itu masih sering terjadi dalam audit AI visibility.

“Brand kita muncul di ChatGPT.”

“Kompetitor tidak disebut Gemini.”

“Website kita sudah dikutip.”

Semua pernyataan itu mungkin benar untuk satu output yang dilihat saat itu. Tetapi satu output belum cukup untuk menggambarkan stabilitas.

Generative system tidak bekerja seperti tabel database yang selalu mengembalikan baris identik. Jawaban bisa berubah karena sampling, retrieval, freshness, model update, product configuration, conversation context, dan faktor lain.

Pertanyaan yang lebih penting bukan “apakah brand pernah muncul?”, tetapi “seberapa konsisten brand muncul pada kondisi pengujian yang sama?”

Lalu muncul pertanyaan praktis: berapa kali satu query harus diulang?

Jawaban yang kredibel bukan angka ajaib.

Tiga kali, lima kali, sepuluh kali, atau tiga puluh kali bisa masuk akal tergantung tujuan measurement, biaya, volatility, dan seberapa besar keputusan yang akan dibuat dari data itu.

Mulai dari Tujuan Pengujian

Kalau tujuan hanya exploratory audit, kita tidak perlu memperlakukan setiap query seperti clinical trial.

Misalnya tim ingin menemukan pola awal dari 200 query. Dua atau tiga run per query mungkin sudah membantu melihat area yang menarik untuk diinvestigasi lebih jauh.

Tetapi kalau hasil akan digunakan untuk membandingkan dua periode, menilai efek perubahan besar, atau masuk ke board report, tiga run mungkin terlalu rapuh untuk query yang volatile.

Kalau keputusan bernilai besar bergantung pada hasil, sample harus lebih kuat.

Jadi jangan bertanya “berapa kali harus repeat?” tanpa bertanya “untuk keputusan apa?”

Exploration, monitoring, benchmarking, dan causal experiment membutuhkan tingkat rigor berbeda.

Kenapa Satu Run Lemah

Bayangkan query:

“Agency apa yang bagus untuk membantu brand Indonesia muncul di AI search?”

Run pertama menyebut Brand A, B, C.

Run kedua menyebut A, D, E.

Run ketiga menyebut B, C, F.

Run keempat menyebut A, C, E.

Kalau kita hanya mengambil run kedua, Brand C terlihat tidak visible.

Kalau kita hanya mengambil run ketiga, Brand A terlihat tidak visible.

Padahal dari empat run, A dan C sama-sama punya presence berulang.

Satu run sangat sensitif terhadap output individual.

Ini bukan berarti output pertama “salah”. Ia valid sebagai snapshot. Hanya saja snapshot tidak cukup untuk mengukur probability atau consistency.

Repeat testing mengubah pertanyaan dari “apa yang keluar sekarang?” menjadi “pola apa yang muncul jika kondisi diuji berulang?”

Tiga Run sebagai Screening, Bukan Hukum

Dalam praktik, tiga run sering menjadi minimum yang masuk akal untuk screening karena lebih baik daripada satu dan masih affordable untuk query set besar.

Dengan tiga run kita mulai bisa melihat:

Muncul 0/3.
Muncul 1/3.
Muncul 2/3.
Muncul 3/3.

Itu sudah memberi sinyal kasar.

Brand yang muncul 3/3 berbeda dari brand yang hanya muncul 1/3.

Tetapi resolution-nya masih rendah.

1/3 berarti sekitar 33 persen observed rate pada sample kecil. Satu perubahan output saja bisa mengubahnya menjadi 0 atau 67 persen.

Jadi tiga run bagus untuk triage, bukan selalu untuk klaim kuat.

Lima Run Memberi Gambaran Lebih Praktis

Untuk recurring audit, lima run per query sering menjadi kompromi yang cukup workable.

Kita mendapatkan interval sederhana:

0, 20, 40, 60, 80, atau 100 persen observed presence.

Masih kasar, tetapi lebih informatif.

Kalau sebuah brand muncul 5/5, kita bisa mengatakan visibility terlihat stabil pada test tersebut.

Kalau 2/5, visibility lebih intermittent.

Kalau 0/5, brand tidak terobservasi pada batch itu, tetapi tetap jangan menulis “AI tidak mengenal brand”.

Penting: observed absence bukan proof of universal absence.

Lima run juga memungkinkan melihat citation variation.

Misalnya brand disebut 5/5 tetapi owned domain hanya dikutip 1/5.

Itu insight yang tidak terlihat dari mention saja.

Sepuluh Run untuk Query Prioritas Tinggi

Tidak semua query harus mendapatkan jumlah repeat yang sama.

Satu pendekatan efisien adalah hierarchical testing.

Semua query mendapat tiga run awal.

Query yang strategis atau volatile mendapat tambahan hingga lima.

Query dengan dampak bisnis tinggi atau hasil ambigu mendapat tambahan hingga sepuluh.

Dengan begitu budget tidak habis untuk mengulang ratusan query yang hasilnya sudah sangat konsisten.

Misalnya 150 query audit.

Run 1–3 untuk semuanya: 450 observations.

Dari situ, 40 query dianggap high-value atau unstable.

Tambah dua run: 80 observations.

Kemudian 10 query paling penting diuji hingga sepuluh total: tambahan 50 observations.

Total 580, bukan 1.500.

Kualitas data meningkat tanpa biaya meledak.

Volatility Harus Menentukan Repeat Count

Query yang stabil tidak perlu diperlakukan sama dengan query yang chaotic.

Misalnya query A selama lima run selalu menghasilkan tiga brand yang hampir sama.

Query B berubah total setiap run.

Untuk query A, repeat tambahan mungkin punya diminishing return.

Untuk query B, kita perlu lebih banyak observasi atau setidaknya memberi label “high volatility”.

Ini lebih informatif daripada memaksakan satu angka universal.

Repeat count bisa adaptive.

Semakin tinggi disagreement antar-run, semakin besar kebutuhan sample.

Jangan Ulang dengan Cara yang Diam-Diam Berubah

Repeat testing hanya berguna kalau kondisi cukup konsisten.

Jika run pertama dilakukan logged out, run kedua logged in, run ketiga memakai conversation yang sudah panjang, hasilnya tidak benar-benar comparable.

Catat setidaknya:

Tanggal dan waktu.

Product atau model surface.

Status login bila relevan.

Lokasi atau market context.

Language.

Fresh chat atau existing conversation.

Web search/retrieval condition bila ada pilihan.

Query persis.

Parameter lain yang memang bisa dikontrol.

Kalau kondisi berubah, label sebagai test berbeda.

Jangan menyebutnya repeat dari eksperimen yang sama.

Fresh Chat vs Conversation Context

Ini detail yang sering diremehkan.

Dalam conversational AI, pertanyaan yang sama bisa menghasilkan jawaban berbeda ketika punya context sebelumnya.

Kalau tujuan kita mengukur standalone discoverability, gunakan fresh conversation untuk setiap repeat.

Kalau tujuan kita mengukur journey, justru context harus dirancang.

Misalnya:

Prompt 1: “Saya sedang mencari software payroll untuk 300 karyawan.”

Prompt 2: “Yang punya support Indonesia dan integrasi API?”

Prompt 3: “Bandingkan tiga yang paling cocok.”

Itu valid sebagai conversational journey test.

Tetapi jangan mencampurnya dengan standalone query result.

Keduanya mengukur hal berbeda.

Randomisasi Urutan Testing

Kalau kita menguji beberapa brand atau query cluster, urutan juga bisa menimbulkan operational bias.

Misalnya seluruh query Brand A diuji pagi hari dan Brand B malam hari pada hari model update.

Atau seluruh query komersial diuji sebelum perubahan platform, sedangkan query informational setelahnya.

Untuk project besar, randomisasi urutan atau distribusikan testing di window waktu yang sama.

Tujuannya bukan membuat eksperimen sempurna, tetapi mengurangi risiko bahwa perbedaan timing disalahartikan sebagai perbedaan brand.

Bandingkan Distribution, Bukan Cuma Average

Misalnya bulan Juli recommendation rate 40 persen.

Agustus juga 40 persen.

Kelihatannya tidak berubah.

Tetapi distribusinya bisa berbeda.

Juli:
Banyak query berada di 2/5 dan 3/5.

Agustus:
Sebagian query menjadi 5/5, sebagian jatuh ke 0/5.

Average sama, volatility meningkat.

Itu penting.

Bisnis mungkin lebih memilih visibility yang moderate tetapi stabil daripada sangat kuat di sebagian query dan hilang total di lainnya.

Karena itu simpan data per query, bukan hanya aggregate.

Confidence Bukan Hanya Persentase

Ada godaan membuat label seperti “95% confidence” pada audit AI search.

Hati-hati.

Statistical confidence membutuhkan asumsi tentang sampling dan independence yang belum tentu terpenuhi dalam testing model.

Sepuluh output dari product yang sama dalam satu jam belum tentu setara dengan sepuluh sampel independen dari populasi pengguna.

Model bisa menggunakan retrieval infrastructure yang sama, version yang sama, atau cache-like behavior tertentu yang tidak kita lihat.

Lebih aman memakai istilah operational confidence.

Contoh:

High consistency: brand muncul 9–10 dari 10 run.

Medium consistency: 5–8 dari 10.

Low consistency: 1–4 dari 10.

Not observed: 0 dari 10.

Ini bukan confidence interval statistik formal. Ini classification rule internal yang transparan.

Kalau organisasi punya data scientist dan desain sampling yang lebih sophisticated, tentu bisa membangun analisis statistik lebih kuat. Tetapi jangan memberi aura scientific yang tidak didukung desain pengujian.

Repeat across Time Sama Pentingnya dengan Repeat dalam Satu Sesi

Sepuluh run hari ini memberi gambaran intraday stability.

Tetapi tidak menjawab stability minggu depan.

AI search berubah.

Fresh web information berubah.

Kompetitor menerbitkan konten baru.

Model dan retrieval system dapat diperbarui.

Karena itu recurring measurement perlu dua dimensi:

Within-period repeats.

Across-period repeats.

Misalnya lima run per query dalam monthly audit.

Lalu core query set diulang setiap bulan.

Dengan desain itu kita bisa melihat apakah visibility berubah karena random output atau benar-benar ada shift yang persisten.

Kalau satu bulan turun dari 5/5 menjadi 1/5 lalu bulan berikutnya kembali 5/5, kita mungkin melihat volatility.

Kalau turun konsisten selama tiga periode, sinyalnya lebih serius.

Jangan Memburu Repeat Sampai Angka yang Diinginkan Muncul

Ini bentuk p-hacking versi sederhana.

Tim menjalankan query berulang sampai brand akhirnya muncul, lalu screenshot yang bagus dipakai dalam report.

Atau sebaliknya, kompetitor diuji sampai tidak muncul.

Ini bukan measurement.

Repeat count harus ditentukan sebelum melihat hasil, atau memakai adaptive rule yang sudah ditulis sebelumnya.

Contoh:

Semua query tiga run.

Jika hasil 0/3 atau 3/3 dan query bukan priority, stop.

Jika 1/3 atau 2/3, tambah dua run.

Priority queries selalu sepuluh run.

Rule seperti ini menjaga testing tetap disiplin.

Berapa Angka Praktisnya?

Untuk banyak organisasi, framework berikut cukup rasional sebagai titik awal:

1 run: hanya snapshot atau troubleshooting.

3 run: exploratory screening.

5 run: baseline recurring measurement untuk query set utama.

10 run: query penting, volatile, atau untuk validation lebih kuat.

Lebih dari 10: gunakan bila ada alasan bisnis atau metodologis yang jelas, bukan karena “semakin banyak pasti semakin benar”.

Angka ini bukan standar universal dan bukan jaminan statistik. Ini operational framework.

Jika cost per test tinggi, kita bisa mengurangi repeat tetapi memperbesar coverage query.

Jika query set kecil dan board decision sangat penting, kita bisa memperbanyak repeat.

Measurement selalu trade-off antara breadth dan depth.

Satu Tes Tidak Pernah Cukup untuk Klaim Stabil

AI visibility bukan posisi ranking yang bisa dilihat sekali lalu dianggap permanen.

Yang kita ukur adalah pola output dalam sistem yang dinamis.

Karena itu hasil paling berguna bukan “brand muncul” atau “brand tidak muncul”.

Yang berguna adalah:

Brand muncul berapa kali dari berapa run.

Pada intent apa.

Dengan source apa.

Seberapa sering direkomendasikan.

Seberapa konsisten dari waktu ke waktu.

Dalam kondisi testing apa.

Kalau report menyimpan semua itu, lima run bisa lebih bernilai daripada lima puluh screenshot random.

Pertanyaannya bukan mencari angka repeat yang terdengar ilmiah.

Pertanyaannya adalah membangun protocol yang cukup kuat agar ketika bulan depan angka berubah, kita tahu perubahan itu layak diperhatikan atau cuma noise.

Itu standar yang jauh lebih berguna untuk AI search measurement.