Cara Cek Model AI Asli di Penyedia API Pihak Ketiga: Metode Uji Statistik

Saat membeli akses model AI dari penyedia pihak ketiga, misalnya reseller API, API aggregator, atau produk AI wrapper, kamu bergantung sepenuhnya pada klaim mereka soal model yang dipakai. Bayangkan kamu membayar tarif Gemini Flash 3.5, tetapi permintaanmu sebenarnya diteruskan ke Gemini 3.0 yang lebih murah. Dari sisi pengguna, perbedaan ini hampir tidak terlihat.

Cara cek model AI asli di penyedia API pihak ketiga bukan dengan membaca satu atau dua jawaban, melainkan dengan membandingkan ratusan respons terhadap penyedia resmi secara statistik. Jika produkmu dibangun di atas model tertentu, selisih kualitas yang tidak terlihat ini bisa menurunkan akurasi produkmu tanpa kamu sadari.

Artikel ini adalah prosedur uji yang kami susun dan rekomendasikan, bukan laporan hasil uji terhadap penyedia tertentu: semua angka di bawah adalah contoh ilustratif untuk menjelaskan cara kerjanya.

Apa itu substitusi model?

Substitusi model (model substitution) adalah praktik penyedia yang melayani model berbeda, biasanya lebih murah, dari model yang diklaim dan ditagihkan. Bentuknya beragam:

• Versi lama — model diganti ke generasi sebelumnya yang tarifnya lebih rendah.
• Versi terkuantisasi — model yang sama dibuat lebih ringan (quantized), dengan kualitas sedikit menurun.
• Pengalihan sebagian — hanya sebagian permintaan yang diteruskan ke model murah, sehingga rata-rata kualitas hanya turun sedikit.

Istilah yang dipakai di sepanjang artikel ini:

Istilah	Arti
Penyedia resmi (first-party provider)	Perusahaan pembuat model yang menjual API-nya langsung, misalnya DeepSeek, Anthropic, atau Google.
Penyedia pihak ketiga (third-party provider)	Reseller, aggregator, atau wrapper yang menjual akses ke model milik pihak lain.
Kondisi uji (test condition)	Satu sumber respons dalam eksperimen, misalnya penyedia resmi atau penyedia yang diuji.
Skor kemiripan (similarity score)	Angka 0–100 yang menyatakan seberapa mirip dua respons.
Variabilitas antar-run (run-to-run variability)	Perbedaan alami respons model yang sama untuk prompt yang sama.
Kontrol negatif (negative control)	Model yang sengaja berbeda, dipakai untuk membuktikan bahwa tes mampu mendeteksi perbedaan.
Uji kesetaraan (equivalence test)	Uji statistik untuk membuktikan dua hal setara dalam batas toleransi yang ditentukan di awal.

Mengapa substitusi model sulit dibuktikan?

Karena LLM bersifat probabilistik: prompt yang sama, ke model dan penyedia yang sama, bisa menghasilkan respons berbeda di setiap permintaan. Satu respons yang "terasa berbeda" karena itu tidak bisa dijadikan bukti.

Bahkan dengan temperature 0, keluaran tidak dijamin identik (nondeterminism). Penyebabnya antara lain:

• Batching permintaan di server penyedia.
• Urutan operasi floating point di GPU.
• Pembaruan kecil pada model atau infrastruktur di sisi penyedia.

Jadi pertanyaan yang tepat bukan "apakah responsnya sama persis?", melainkan: "apakah perbedaan respons penyedia pihak ketiga lebih besar daripada variabilitas antar-run model itu sendiri?"

Bagaimana cara cek model AI asli di penyedia API pihak ketiga?

Ukur dulu seberapa mirip penyedia resmi dengan dirinya sendiri, lalu buktikan bahwa penyedia pihak ketiga sama miripnya. Penyedia resmi dijadikan referensi, dan untuk setiap prompt kita mengukur dua skor kemiripan:

1. Kemiripan referensi dengan dirinya sendiri (self-consistency): respons penyedia resmi dibandingkan dengan respons penyedia resmi dari permintaan terpisah. Skor ini menjadi baseline, yaitu batas atas kemiripan yang wajar untuk model tersebut.
2. Kemiripan referensi dengan penyedia yang diuji: respons penyedia resmi dibandingkan dengan respons penyedia pihak ketiga.

Jika penyedia pihak ketiga benar-benar memakai model yang sama, skor kedua seharusnya setara secara statistik dengan skor pertama. Jika skor kedua jelas lebih rendah, ada indikasi model yang berbeda. Satu komponen yang sering terlewat: kita juga perlu bukti bahwa tes ini mampu mendeteksi model yang berbeda, dan itulah fungsi kontrol negatif.

Apa yang perlu disiapkan sebelum menguji?

Tiga hal: API key penyedia resmi, kumpulan prompt uji yang menantang, dan kondisi uji yang dikunci sehingga satu-satunya perbedaan adalah penyedia.

1. API key dari penyedia resmi. Contohnya DeepSeek, Anthropic, atau Google Gemini. Respons dari sini menjadi referensi.
2. Kumpulan prompt uji. Idealnya ratusan hingga ribuan, misalnya 1.000. Dengan anggaran terbatas, 200–300 prompt sudah dapat memberi sinyal awal karena desainnya berpasangan (lihat bagian analisis statistik). Sertakan prompt yang menuntut kemampuan tinggi: penalaran, matematika, pemrograman, dan instruksi bertingkat. Pada prompt sederhana, model lama dan baru cenderung menjawab mirip sehingga substitusi sulit terdeteksi.
3. Kondisi uji yang setara. Satu-satunya variabel yang berbeda adalah penyedia (base URL). Semua parameter lain dikunci:
   • Nama dan versi model yang sama persis; gunakan versi yang di-pin jika tersedia.
   • System prompt, temperature, top_p, max_tokens, dan stop sequence yang sama.
   • Mode penalaran (reasoning/thinking mode) yang sama, aktif atau nonaktif di semua kondisi.
   • Tanpa web search, tool use, atau function calling.
   • Seluruh pengujian dijalankan dalam jendela waktu yang sama, agar pembaruan model di penyedia resmi tidak memengaruhi hasil.

Bagaimana desain eksperimen yang benar?

Kirim setiap prompt ke empat kondisi uji: referensi, baseline, penyedia yang diuji, dan kontrol negatif. Contoh ini memakai DeepSeek V4 sebagai model yang diverifikasi. Notasi S(A,B) berarti skor kemiripan antara respons kondisi A dan kondisi B.

Kondisi uji	Sumber	Model	Fungsi
A. Referensi	Penyedia resmi	DeepSeek V4	Respons acuan
B. Kontrol konsistensi (baseline)	Penyedia resmi, permintaan terpisah	DeepSeek V4	Mengukur variabilitas antar-run: S(A,B)
C. Penyedia yang diuji	Penyedia pihak ketiga	DeepSeek V4 (sesuai klaim)	Objek verifikasi: S(A,C)
D. Kontrol negatif	Penyedia resmi	Model yang lebih murah atau lebih lama	Membuktikan tes mampu mendeteksi model berbeda: S(A,D)

Kondisi D adalah komponen terpenting yang sering dilewatkan. Pilih model yang paling mungkin dijadikan pengganti, misalnya Gemini 3.0 saat memverifikasi penyedia Gemini Flash 3.5, atau versi DeepSeek sebelumnya.

Saat menyusun prosedur ini, kondisi D adalah langkah yang paling menggoda untuk dilewati: ia menambah biaya API, dan hasilnya tidak menjawab pertanyaan "apakah penyedia ini jujur?" secara langsung. Tetapi tanpa kondisi D, hasil "lolos" tidak bisa dibedakan dari tes yang memang tidak mampu melihat perbedaan. Karena itu prosedur ini menghitung S(A,D) lebih dulu, sebelum melihat S(A,C). Jika jaraknya ke S(A,B) kecil, ganti prompt atau metrik dulu, bukan menyimpulkan apa pun tentang penyedia.

Opsional, tetapi sangat membantu: ambil 3–5 sampel untuk kondisi B pada setiap prompt. Dengan begitu, sebaran variabilitas antar-run per prompt dapat diestimasi, bukan hanya satu titik data.

Metrik apa yang dipakai untuk mengukur kemiripan respons?

Gunakan LLM sebagai penilai sebagai metrik utama, dilengkapi embedding similarity, akurasi pada soal terverifikasi, dan sinyal metadata. Tiap metrik menangkap jenis perbedaan yang berbeda.

LLM sebagai penilai (LLM-as-a-judge)

Sebuah LLM diminta menilai kemiripan dua respons pada skala 0–100. Agar penilaiannya objektif:

• Gunakan model penilai dari keluarga berbeda dengan model yang diuji, untuk menghindari bias terhadap gaya respons sendiri.
• Berikan rubrik penilaian yang eksplisit: kesesuaian isi dan fakta, struktur, gaya bahasa, dan panjang.
• Terapkan penilaian buta (blind evaluation): sembunyikan label kondisi uji dan acak urutan pasangan respons.
• Jalankan penilai dengan temperature 0 dan ukur konsistensinya dengan menilai ulang sebagian pasangan.

Kemiripan embedding (embedding similarity)

Cosine similarity antara vektor embedding dua respons. Murah dan deterministik, cocok sebagai pelengkap LLM penilai.

Akurasi pada soal terverifikasi

Untuk soal matematika atau pemrograman yang jawabannya bisa dicek otomatis, bandingkan akurasi tiap kondisi uji. Model versi lama atau terkuantisasi biasanya menunjukkan penurunan akurasi pada soal sulit, dan sinyal ini sering lebih tajam daripada skor kemiripan.

Sinyal metadata

Tidak cukup sebagai bukti tunggal, tetapi murah untuk dikumpulkan dan sering menjadi petunjuk awal:

• Jumlah token input — kirim prompt identik lalu bandingkan nilai usage.prompt_tokens. Model dengan tokenizer berbeda akan melaporkan angka berbeda. Catatan: model dalam satu keluarga sering memakai tokenizer yang sama, dan penyedia pihak ketiga dapat memanipulasi angka ini.
• Panjang dan pola gaya respons — distribusi panjang respons, penggunaan format markdown, dan frasa pembuka yang khas.
• Log probabilitas (logprobs) — jika tersedia di kedua sisi, distribusi probabilitas token merupakan sidik jari model yang sangat kuat.
• Uji kapabilitas (capability probe) — pertanyaan tentang batas pengetahuan (knowledge cutoff), panjang konteks maksimum, atau fitur yang hanya ada di versi terbaru.

Bagaimana membaca hasilnya secara statistik?

Hitung selisih berpasangan per prompt, buktikan kesetaraan dengan uji TOST, lalu periksa ekor distribusi. Pendekatan intuitifnya: jika rata-rata S(A,B) adalah 93 ± margin galat (margin of error), maka rata-rata S(A,C) juga harus berada di sekitar 93. Arahnya sudah tepat, tetapi ada tiga penyempurnaan penting.

1. Gunakan selisih berpasangan per prompt

Karena setiap prompt dijawab oleh semua kondisi uji, hitung selisih skor di tingkat prompt (paired difference), bukan membandingkan dua rata-rata secara terpisah. Prompt yang secara alami sulit menghasilkan respons mirip akan bernilai rendah di kedua kondisi, sehingga efeknya saling meniadakan. Hasilnya, margin galat jauh lebih kecil untuk jumlah prompt yang sama.

d_i = S(A_i, B_i) − S(A_i, C_i)

MoE_95% = 1,96 × s_d / √n

s_d adalah simpangan baku dari d_i dan n adalah jumlah prompt. Contoh dengan s_d = 10 poin:

Jumlah prompt (n)	Margin galat 95%
100	± 1,96 poin
300	± 1,13 poin
1.000	± 0,62 poin

Margin galat mengecil sebanding dengan akar kuadrat n: menggandakan presisi membutuhkan empat kali lipat jumlah prompt. Jika distribusi skor tidak simetris (umum pada skala 0–100), gunakan bootstrap confidence interval sebagai pengganti rumus di atas.

2. "Tidak berbeda signifikan" tidak sama dengan "setara"

Ini kesalahan interpretasi yang paling umum. Dengan sampel kecil, margin galat melebar dan hampir semua penyedia akan "lolos" karena uji tidak memiliki daya statistik (statistical power) yang cukup. Yang perlu dibuktikan adalah kesetaraan, bukan sekadar ketiadaan perbedaan signifikan. Gunakan uji kesetaraan dengan metode Two One-Sided Tests (TOST):

1. Tetapkan batas toleransi δ sebelum melihat data. Patokan praktis: setengah dari selisih antara S(A,B) dan S(A,D). Misalnya baseline 93 dan kontrol negatif 83, maka δ = 5 poin.
2. Hitung interval kepercayaan (confidence interval) 90% dari rata-rata d_i.
3. Penyedia dinyatakan setara jika seluruh interval berada di dalam [−δ, +δ].
4. Penyedia dinyatakan lebih rendah kualitasnya jika seluruh interval berada di atas +δ.
5. Di luar kedua kondisi tersebut, hasil belum dapat disimpulkan: tambah jumlah prompt.

3. Periksa distribusi, bukan hanya rata-rata

Penyedia dapat mengalihkan hanya sebagian permintaan (partial routing). Contoh: 20% permintaan dialihkan ke model dengan skor 15 poin lebih rendah. Rata-rata hanya turun 0,2 × 15 = 3 poin, sehingga mudah tersamar oleh variabilitas.

Cara mendeteksinya: hitung persentil ke-5 dari S(A,B), lalu hitung proporsi prompt pada kondisi C yang skornya di bawah nilai tersebut. Penyedia yang memakai model sesuai klaim seharusnya menghasilkan proporsi sekitar 5%. Jika proporsinya mencapai 20%, ekor distribusi (tail) menunjukkan anomali. Uji binomial atau uji Kolmogorov–Smirnov dapat dipakai untuk mengonfirmasi.

Kesalahan apa yang membuat hasil uji menyesatkan?

Kebanyakan hasil uji yang menyesatkan berasal dari prompt yang terlalu mudah, parameter yang diubah penyedia, atau respons dari cache.

• Cakupan prompt terlalu sempit atau terlalu mudah — membatasi prompt pada satu domain (misalnya fashion) memang menekan variasi, tetapi berisiko memilih domain di mana semua model menjawab mirip. Desain berpasangan sudah mengendalikan variasi antar-prompt, sehingga prompt yang beragam dan menantang lebih disarankan.
• Parameter diabaikan penyedia — sebagian penyedia pihak ketiga diam-diam mengubah temperature atau max_tokens. Periksa distribusi panjang respons dan nilai finish_reason.
• Respons dari cache — penyedia dapat mengembalikan respons yang tersimpan di cache. Pastikan setiap prompt unik, misalnya dengan menambahkan ID acak di awal prompt pada semua kondisi uji.
• Pembaruan model selama pengujian — penyedia resmi juga dapat memperbarui modelnya. Jalankan semua kondisi uji dalam jendela waktu yang sama dan catat tanggal pengujian.

Apa yang tidak bisa dibuktikan metode ini?

Metode ini memberi bukti statistik yang kuat, bukan kepastian 100%. Batasannya:

• Kuantisasi sulit dibedakan — versi terkuantisasi dari model yang sama dapat menghasilkan skor kemiripan sangat tinggi. Untuk kasus ini, akurasi pada soal sulit dan analisis logprobs jauh lebih efektif.
• Hanya berlaku untuk jendela waktu uji — penyedia bisa mengganti model setelah pengujian selesai, jadi hasilnya mewakili tanggal pengujian, bukan jaminan ke depan.
• Metadata bisa dimanipulasi — jumlah token dan nilai lain yang dilaporkan penyedia tidak cukup sebagai bukti tunggal.
• Bukan dasar tuduhan — gunakan hasilnya untuk meminta klarifikasi dari penyedia atau mengevaluasi ulang pilihan penyedia, bukan sebagai tuduhan tanpa data pendukung.

Checklist verifikasi model AI

• ☐ Siapkan API key penyedia resmi dan penyedia pihak ketiga yang akan diuji
• ☐ Susun 300–1.000 prompt yang beragam dan menantang, sebagian dengan jawaban yang dapat diverifikasi
• ☐ Kunci semua parameter; satu-satunya perbedaan adalah penyedia (base URL)
• ☐ Jalankan kondisi A, B, C, dan D (kontrol negatif) dalam jendela waktu yang sama
• ☐ Ukur skor kemiripan dengan LLM penilai secara buta, dilengkapi embedding similarity
• ☐ Pastikan S(A,D) jelas lebih rendah dari S(A,B); jika tidak, tes belum cukup sensitif
• ☐ Hitung selisih berpasangan, interval kepercayaan, dan uji kesetaraan dengan δ yang ditetapkan di awal
• ☐ Periksa ekor distribusi untuk mendeteksi pengalihan sebagian permintaan
• ☐ Bandingkan juga jumlah token, akurasi, dan panjang respons

Apakah harga API yang lebih murah berarti penyedianya curang?

Tidak selalu: sebagian penyedia memang efisien atau menerapkan skema harga berbasis volume. Namun jika produkmu dibangun di atas model tertentu, kamu berhak memastikan apa yang sebenarnya kamu bayar. Dengan baseline yang tepat, kontrol negatif, dan analisis statistik yang benar, kecurigaan dapat diubah menjadi data yang terukur.

Perlu disampaikan terus terang: Intura menjual model AI, jadi pertimbangkan saran berikut dengan itu. Untuk tugas yang spesifik, ada cara lain menghindari pertanyaan ini sama sekali: menjalankan model sendiri. Model kecil hasil fine-tuning dari Intura berjalan di CPU atau perangkat edge milikmu, sehingga kamu tahu persis model dan versi mana yang menjawab setiap permintaan.