Apakah pemanggilan API pihak ketiga benar-benar menggunakan model yang Anda pilih? Anthropic FlashProve memverifikasi identitas hasil inferensi dengan bukti kriptografi berukuran 19MB

Catatan penulis: saat memanggil Model Bahasa Besar lewat API pihak ketiga, kualitas jawaban saja tidak cukup untuk memastikan model mana yang sebenarnya berjalan. Artikel ini membahas FlashProve, proyek open source dari Anthropic: bagaimana ia memakai zkSNARK untuk mengikat hasil inferensi ke bobot model tertentu, berapa biayanya, apa yang bisa dan tidak bisa dibuktikannya, dan seberapa jauh ia dari pemanggilan API sehari-hari.

Pada 2 November 2026, para peneliti dari Anthropic Frontier Red Team bersama EPFL, MIT, dan institusi lain merilis FlashProve: prototipe open source inferensi yang dapat dibuktikan (provable inference) untuk Model Bahasa Besar. Pada Llama 4 Maverick dengan 400B parameter, FlashProve membuat bukti hanya dengan satu GPU H100. Satu bukti berukuran sekitar 19 MB, dan CPU biasa bisa memverifikasinya dalam belasan detik.

Ini bukan sekadar demo konsep atau produk di atas slide. Anthropic merilis laporan teknis, dokumen spesifikasi protokol, sisi prover yang bisa dijalankan, dua implementasi sisi verifier, serta bukti formal dalam Lean, semuanya dengan lisensi Apache 2.0. Meski begitu, Anthropic menegaskan bahwa ini baru kemajuan riset tahap awal, dan masih banyak jalan menuju tujuan riset yang utuh.

Nilai utama: setelah membaca artikel ini, kamu akan paham mengapa “identitas model” sulit dipastikan pada pemanggilan API pihak ketiga, mekanisme apa yang dipakai FlashProve untuk menyelesaikannya, di mana batas dan biaya sebenarnya, serta apa yang bisa kamu lakukan sekarang sebagai pengguna API.

Mengapa Ada Masalah Kepercayaan terhadap Identitas Model pada Pemanggilan API Pihak Ketiga

Ketika Anda mengirim permintaan lewat API apa pun, yang kembali hanyalah sepotong teks dan satu kolom nama model. Anthropic menyatakan terang-terangan di blog risetnya bahwa pengguna saat ini tidak bisa memastikan jawaban yang diterima benar-benar berasal dari model yang diklaim pengembangnya. Bisa jadi layanan proksi API diam-diam menggantinya demi menekan biaya, atau penyerang mengutak-atik aliran token.

Yang lebih penting, kualitas output yang bagus tidak berarti identitas model itu asli. Model murah pun bisa menjawab sangat baik untuk pertanyaan tertentu, dan versi yang sudah diturunkan kualitasnya (downgrade) belum tentu bisa dikenali dengan mata telanjang. Bahkan jika seluruh riwayat obrolan dipublikasikan, secara teori riwayat itu tetap bisa dipalsukan dengan model yang lebih murah, sehingga bukti semacam ini tidak punya kekuatan pembuktian yang mutlak.

Verifikasi secara mendasar juga sulit dilakukan. Bobot model-model terdepan umumnya tidak dipublikasikan. Seandainya bobotnya pun didapat, daya komputasi yang dibutuhkan untuk menghitung ulang inferensinya jauh melampaui kemampuan pengguna biasa, bahkan lembaga evaluasi sekalipun. Anthropic merangkum beberapa skenario khas dari masalah kepercayaan ini:

• Layanan proksi API pihak ketiga: pelanggan ingin memastikan token yang diterima berasal dari model yang memang mereka pilih dan bayar.
• Evaluasi independen: lembaga evaluasi perlu memastikan model yang diuji sebelum dan sesudah rilis adalah model yang benar-benar melayani pengguna di lingkungan produksi.
• Deteksi manipulasi: setelah server inferensi dibobol, penyerang bisa menyisipkan jawaban berbahaya, bahkan mengirimkan malware ke komputer pengguna.
• Regulasi dan kepatuhan: regulator bisa saja mewajibkan hanya model yang lolos persetujuan keamanan yang boleh dijalankan, atau meminta bukti bahwa perangkat keras memang dipakai untuk inferensi, bukan diam-diam untuk pelatihan.

Tujuan dari inferensi yang dapat dibuktikan (Provable Inference) adalah memungkinkan pengguna yang daya komputasinya terbatas dan tidak mengetahui bobot model untuk memverifikasi bahwa suatu jawaban benar-benar berasal dari model yang diminta.

Ringkasan Inti FlashProve

Yang menarik, Anthropic menyebutkan bahwa sebagian besar pekerjaan optimisasi dalam sistem ini dikerjakan oleh Claude. Untuk mengantisipasi “keputusan yang sulit dievaluasi” yang bisa dibuat AI dalam sistem besar dan kompleks, tim menulis pernyataan keamanan tingkat atas yang dapat diaudit dalam Lean sebagai langkah lindung nilai.

Bagaimana FlashProve Membuktikan Inferensi Berasal dari Model yang Ditentukan

FlashProve hanya punya dua peran: penyedia model sebagai pembukti (Prover) dan pengguna sebagai pemverifikasi (Verifier). Prosesnya terbagi menjadi tahap offline dan tahap online, ditambah pemeriksaan di sisi verifikasi.

Mekanisme Tiga Langkah FlashProve

1. Komitmen model secara offline (Model Commitment): pembukti menerbitkan komitmen atas bobot model, yang bisa dibayangkan sebagai “sidik jari” yang sangat singkat. Komitmen ini mengunci satu set bobot yang pasti, sementara bobotnya sendiri tetap tersembunyi. Dalam pengujian, langkah ini cukup dilakukan sekali per model dan memakan waktu sekitar 39 menit. Komitmen yang dihasilkan bisa mendukung sekitar 16 juta permintaan sebelum perlu dibuat ulang.
2. Pembuatan bukti secara online: setelah menerima permintaan dari pemverifikasi (prompt beserta token keluarannya), pembukti membuat satu berkas bukti. Pernyataan yang dibuktikan adalah “model yang telah dikomitmenkan akan menghasilkan token keluaran ini saat dijalankan”.
3. Pemeriksaan di sisi verifikasi: siapa pun yang memegang komitmen, prompt, dan jawaban bisa memeriksa bukti tersebut. Tanpa bobot dan hanya dengan daya komputasi terbatas, pemeriksa bisa yakin bahwa bobot yang dikomitmenkan memang menghasilkan token-token ini untuk prompt tersebut.

Empat Sifat Keamanan FlashProve

Dua sifat pertama (kelengkapan dan kesahihan) sebenarnya bisa dicapai oleh pemverifikasi yang tahu bobot dan punya daya komputasi cukup dengan menghitung ulang sendiri. Dua sifat berikutnyalah yang membuat sistem ini benar-benar bermakna:

• Kelengkapan (Completeness): bukti yang dibuat pembukti yang jujur pasti diterima.
• Kesahihan (Soundness): memalsukan bukti valid untuk pernyataan yang salah sama sulitnya dengan menembus asumsi kriptografi yang sudah dipercaya luas, sehingga pemverifikasi tidak perlu memercayai pembukti.
• Pengetahuan nol (Zero Knowledge): pemverifikasi tidak bisa mengetahui bobot, nilai-nilai antara dalam komputasi, maupun pakar (expert) mana yang aktif di tiap lapisan. Namun, arsitektur modelnya sendiri tidak disembunyikan.
• Keringkasan (Succinctness): yang dibuktikan adalah satu kali eksekusi model terkuantisasi berukuran sekitar 232 GB, tetapi pemverifikasi hanya menerima berkas sekitar 19 MB yang bisa diperiksa dalam hitungan detik di CPU 24 inti.

Bagaimana Arsitektur MoE Menekan Biaya Pembuktian FlashProve

Percepatan FlashProve sebagian besar memanfaatkan struktur MoE (Mixture of Experts). Di Llama 4 Maverick, setiap token hanya memakai sekitar 17B dari 400B parameter. Beban kerja pembukti pun hanya sebanding dengan sekitar 17B itu, sementara bukti tetap menyembunyikan pakar mana saja yang dipilih.

Ada dua rancangan rekayasa lain yang sama pentingnya. Pertama, pembuktian massal setelah kejadian: pembukti membaca teks yang sudah selesai secara paralel sekaligus, seperti Prefill, sehingga komitmen bobot hanya dibuka sekali per batch. Kedua, kecocokan dengan satu GPU: bobot dipotong per lapisan dan dibuktikan bagian demi bagian, lalu dimuat bertahap (streaming) dari memori biasa. Dengan begitu, satu GPU 80 GB ditambah sekitar 290 GB memori host sudah cukup untuk menjalankannya.

Data Biaya Pembuktian FlashProve dari Hasil Pengujian

Biaya adalah indikator utama untuk menilai apakah inferensi yang dapat dibuktikan (provable inference) layak diterapkan. Lingkungan pengujian Anthropic seperti ini: sisi pembukti memakai satu GPU H100 plus 24 inti CPU, sisi verifikator hanya memakai CPU, dan setiap permintaan berupa satu jendela 1024 Token.

Pembanding yang dipakai adalah model yang sama versi FP8, dijalankan dengan vLLM di 8 GPU H100. Artinya, waktu GPU yang dibutuhkan untuk membuktikan satu batch permintaan kira-kira 70-95 kali lipat dibandingkan inferensi biasa untuk batch yang sama, alias overhead tambahan sekitar dua orde magnitudo.

110 tokens/s Bukan Berarti Jawaban Lengkap Dibuktikan Secara Real-Time

Bagian ini paling sering disalahpahami saat membaca FlashProve. Laporan teknisnya menyebutkan dengan jelas: setiap berkas bukti sebenarnya hanya memeriksa satu Token setelah Prompt. Angka 110 tokens/s adalah throughput sisi pembukti dalam memproses jendela permintaan, bukan kecepatan memverifikasi jawaban lengkap Token demi Token.

Jadi, klaim bahwa “FlashProve sudah bisa membuktikan jawaban lengkap secara real-time” kurang tepat. Rumusan yang lebih akurat: dalam kondisi batch, konteks pendek, dan pembuktian setelah kejadian (post-hoc), FlashProve menekan biaya inferensi yang dapat dibuktikan hingga level yang sebelumnya sulit dibayangkan.

FlashProve dan Perbandingannya dengan Solusi Penalaran Terbukti yang Sudah Ada

Penalaran terbukti (provable inference) di dunia akademik biasanya disebut zkML. Anthropic mengulas perkembangan bidang ini di blognya, dan perbandingan angkanya cukup gamblang.

Perbandingan dengan VerInf: VerInf adalah satu-satunya solusi yang sebelumnya diketahui pernah membuktikan model yang sama. Namun ukuran buktinya mencapai 93,6 GB dan verifikasinya memakan waktu hampir sehari, sehingga nyaris mustahil dipakai dalam praktik. Sebaliknya, FlashProve menekan ukuran bukti menjadi sekitar 19 MB dan memangkas waktu verifikasi menjadi belasan detik. Dengan begitu, audit oleh pihak ketiga di CPU biasa untuk pertama kalinya menjadi layak dilakukan.

Perbandingan dengan Attestable: Attestable meraih angka komersial yang mengesankan pada model dense, tetapi sampai blog ini ditulis, pustaka open source-nya belum dirilis. Keunggulan FlashProve ada pada keterbukaan penuh: kode, bukti Lean, dan dokumentasinya terbuka sehingga siapa pun bisa mereproduksi dan memperbaikinya. Harganya, saat ini FlashProve sangat bergantung pada arsitektur MoE.

Apa yang Bisa dan Tidak Bisa Dibuktikan FlashProve

Bagi pengguna API pihak ketiga, memahami batasan sama pentingnya dengan memahami kemampuan. Tabel berikut merangkum batasan utama dari blog riset dan laporan teknisnya:

Keterbatasan Deteksi pada Pembuktian Pasca-Kejadian FlashProve

FlashProve memakai pembuktian pasca-kejadian (Post-hoc Proving): pengguna menerima respons lebih dulu, lalu server pembukti independen menghitung ulang dan membuat bukti, dan terakhir bukti itu diperiksa oleh verifier. Cara ini membolehkan proses pembuktian berjalan lebih lambat, sehingga kita tidak perlu mengorbankan keamanan demi efisiensi atau sebaliknya. Konsekuensinya, perlindungan datang terlambat: kalau pembuktian gagal, hasilnya hanya mengungkap adanya masalah, dan pengguna tidak terlindungi sebelum menerima jawaban.

Laporan teknisnya juga mengingatkan bahwa kalau sistem log dikuasai penyerang, penyerang bisa mengirim konten yang sudah dimanipulasi kepada pengguna sambil membuat log hanya mencatat hasil yang benar. Karena itu, FlashProve harus dipakai bersama langkah keamanan lain seperti log tepercaya dan kontrol akses.

Bagian Verifikasi Formal FlashProve yang Belum Selesai

Kalimat “dibuktikan secara formal dengan Lean” mudah disalahartikan sebagai “seluruh sistem terbukti benar”, padahal kenyataannya tidak demikian. Batasan yang tercantum dalam laporan teknis meliputi:

• Pembuktian sifat zero-knowledge di Lean saat ini baru mencakup bukti untuk satu permintaan, belum mencakup bukti batch.
• Kode sisi pembukti di GPU dibuat oleh AI berdasarkan representasi Lean, dan kesetaraannya dengan representasi Lean belum dibuktikan.
• Verifier cepat berbasis C++ yang dipakai sehari-hari juga dibuat oleh AI dan tidak punya jaminan formal. Yang ada hanyalah hasil pengujian yang kesimpulannya selalu cocok dengan verifier Lean.
• Dokumen spesifikasi protokol yang panjang dibuat oleh AI dan tidak ditinjau secara rinci oleh penulisnya, jadi perlu dibedakan dari laporan teknis yang ditulis sendiri oleh penulis.

Keterbatasan ini tidak berarti risetnya tidak berguna. Artinya, verifikasi formal saat ini mengunci sifat matematis di level protokol, sementara kesenjangan antara kode yang dijalankan dan protokolnya masih harus dijembatani lewat audit manual atau audit oleh agen.

Analisis Dampak: Seberapa Jauh FlashProve dari Pemanggilan API Pihak Ketiga Sehari-hari

Dampak bagi Developer dan Pengguna API

• Dalam waktu dekat belum akan masuk ke alur pemanggilan sehari-hari: Biaya GPU yang membengkak sekitar dua orde magnitudo, ukuran berkas bukti sekitar 19 MB per permintaan, dan batas jendela konteks 1024 Token membuatnya sulit dipakai langsung untuk API percakapan yang frekuensinya tinggi.
• Cakupan penerapannya terbatas: Sistem ini mengasumsikan arsitektur MoE, model berbasis bilangan bulat (integer), dan decoding greedy. Sebagian besar pemanggilan di lingkungan produksi memakai sampling acak dan inferensi floating point, sehingga belum bisa langsung diterapkan.
• Nilai terbesarnya ada di tataran pemahaman: Untuk pertama kalinya, “memverifikasi identitas model” berubah dari hal yang mustahil menjadi persoalan rekayasa. Developer perlu sadar bahwa kolom nama model yang dikembalikan, ID model, atau log permintaan biasa tidak setara dengan bukti kriptografis.

💡 Saran memilih: Selama inferensi yang dapat dibuktikan (provable inference) belum matang, hal yang lebih layak diperhatikan saat memilih layanan pihak ketiga adalah transparansi penagihan, keterlacakan log pemanggilan, dan konsistensi hasil uji mandiri. Saat memanggil lewat platform agregator seperti APIYI (apiyi.com), Anda bisa meminta beberapa model sekaligus dan menyimpan catatan pemanggilan secara lengkap, sehingga mudah melakukan perbandingan silang dan audit sendiri.

Dampak bagi Industri dan Regulasi

• Perangkat evaluasi dan kepatuhan bertambah satu opsi: Regulator bisa meminta penyedia layanan melampirkan bukti untuk permintaan inferensi dalam suatu periode, guna memastikan perangkat keras memang menjalankan model yang dimaksud, tanpa perlu mengetahui bobot (weights) yang bersifat proprietari. Namun Anthropic juga mengakui bahwa ini tidak bisa membuktikan bahwa perangkat keras tidak dipakai untuk pelatihan secara diam-diam di jalur lain.
• Solusi perangkat lunak dan perangkat keras tepercaya saling melengkapi: Trusted execution environment bergantung pada perangkat keras antipalsu dari vendor, sedangkan zkSNARK bergantung pada sulitnya masalah komputasi tertentu, sehingga bukti tidak bisa dipalsukan meski perangkat keras dan sistem operasi berhasil dibobol. Keduanya akan berperan di skenario yang berbeda.
• Verifikasi produksi Anthropic menempuh jalur lain: Dalam pembaruan Frontier Safety Roadmap tanggal 19 Oktober 2026, Anthropic menyebutkan bahwa proyek verifikasi inferensinya sudah membangun prototipe pada lalu lintas inferensi produksi. Caranya dengan tanda tangan yang mencakup lalu lintas Token internal, lalu menghitung ulang inferensi di server tepercaya. Proyek ini juga pernah menangkap satu anomali integritas yang sangat langka dan tidak berniat jahat. Proyek tersebut kini bernama inference verification, dan merupakan proyek yang terkait tetapi terpisah dari FlashProve, jadi keduanya tidak boleh dicampuradukkan.

Apa yang Bisa Dilakukan Pengguna API Pihak Ketiga Saat Ini: Membuat Catatan Audit Pemanggilan Sendiri

Karena bukti kriptografis belum bisa dipakai dalam waktu dekat, yang bisa dilakukan developer sekarang adalah memastikan “keterlacakan” (traceability) sudah beres. Contoh di bawah ini mengatur temperature=0 saat pemanggilan, lalu menulis waktu permintaan, ID permintaan, kolom model yang dikembalikan, dan hash jawaban ke log lokal, sehingga memudahkan uji ulang konsistensi di kemudian hari. Perlu ditekankan, ini hanya catatan audit di level engineering, bukan bukti kriptografis atas identitas model.

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Antarmuka APIYI yang kompatibel dengan OpenAI
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "用一句话解释零知识证明"}],
    temperature=0
)
print(resp.model, resp.id)
print(resp.choices[0].message.content)

import hashlib
import json
import time
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Satu kunci untuk memanggil banyak model
)

def audited_call(prompt: str, model: str, log_path: str = "audit.jsonl") -> str:
    """Memanggil model dan mencatat informasi keterlacakan (bukan bukti kriptografis)"""
    start = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=0,
        max_tokens=512,
    )
    content = resp.choices[0].message.content or ""
    record = {
        "ts": int(start),
        "latency_s": round(time.time() - start, 3),
        "requested_model": model,
        "returned_model": resp.model,   # Hanya kolom klaim yang dikembalikan oleh server
        "request_id": resp.id,
        "prompt_sha256": hashlib.sha256(prompt.encode()).hexdigest(),
        "output_sha256": hashlib.sha256(content.encode()).hexdigest(),
        "usage": resp.usage.model_dump() if resp.usage else None,
    }
    with open(log_path, "a", encoding="utf-8") as f:
        f.write(json.dumps(record, ensure_ascii=False) + "\n")
    return content

# Tetapkan sekumpulan petunjuk probe, uji ulang secara berkala, lalu bandingkan hash output dan distribusi latensi
probes = ["计算 37*43 并只输出结果", "列出三种排序算法的时间复杂度"]
for p in probes:
    for m in ["gpt-4o-mini", "claude-sonnet-4-5"]:
        print(m, audited_call(p, m)[:60])

🚀 Mulai Cepat: Kamu bisa mendapatkan kuota uji coba gratis lewat APIYI (apiyi.com), lalu memakai skrip probe di atas untuk menguji ulang beberapa model secara berkala. Perlu dicatat, metode seperti ini hanya meningkatkan keterlacakan dan tidak bisa menggantikan bukti tingkat bobot (weight-level) seperti FlashProve.

Selain itu, ada beberapa praktik yang bisa dipadukan: pakai ID model yang tetap, bukan alias yang kabur; simpan sekumpulan petunjuk probe untuk memantau perubahan output dan latensi dalam jangka panjang; untuk kebutuhan bisnis yang kritis, kirim permintaan ke beberapa model sekaligus untuk validasi silang; serta pantau perkembangan apakah penyedia layanan membuka komitmen terhadap bobot atau mekanisme yang bisa diverifikasi.

Pertanyaan yang Sering Diajukan (FAQ)

Poin Utama FlashProve (Key Takeaways)

• Celah kepercayaan itu nyata: pada pemanggilan API pihak ketiga, jawaban berkualitas tinggi tidak membuktikan bahwa identitas model benar-benar asli.
• Mekanisme inti: komitmen bobot secara offline ditambah bukti zkSNARK secara online, sehingga pengguna cukup memakai CPU untuk memverifikasi.
• Biaya turun drastis: throughput satu jendela pada satu H100 sekitar 110 token/detik, ukuran bukti sekitar 19 MB, dan waktu verifikasi sekitar 17 detik.
• Bedakan cara pengukurannya: throughput pemeriksaan per token adalah 39,1 token/detik, sedangkan untuk satu permintaan tunggal hanya 17,6 token/detik.
• Batasannya jelas: hanya untuk MoE, dekode greedy berbasis bilangan bulat, konteks 1024 token, dan deteksi setelah kejadian (post-hoc).
• Cara memulai: untuk saat ini, Anda bisa memakai antarmuka terpadu multimodel dari APIYI (apiyi.com) untuk melakukan uji ulang dan audit sendiri.

Kesimpulan

Makna utama FlashProve bisa diringkas menjadi tiga hal:

1. Verifikasi identitas model menjadi masalah rekayasa: sebelumnya, membuktikan bahwa sebuah model adalah model yang sama membutuhkan belasan jam dan bukti hingga hampir 100 GB. Kini angkanya turun ke kisaran ratusan token/detik dalam pemrosesan batch, dengan bukti sebesar 19 MB.
2. Masih jauh dari siap produksi: biaya tambahan sekitar dua orde magnitudo, konteks yang pendek, batasan arsitektur dan metode dekode, serta cakupan verifikasi formal yang belum lengkap membuatnya masih sebatas prototipe riset.
3. Perlu dipadukan dengan mekanisme keamanan lain: bukti setelah kejadian hanya bisa mendeteksi, bukan mencegah, sehingga harus dikombinasikan dengan log tepercaya dan kontrol akses.

Bagi pengguna API pihak ketiga hari ini, sikap yang paling realistis adalah: jangan menjadikan kolom nama model sebagai bukti, tetapi juga tidak perlu terlalu cemas. Mulailah dengan membenahi catatan pemanggilan, uji ulang dengan probe, dan validasi silang antarmodel, sambil terus memantau perkembangan inferensi yang dapat dibuktikan (provable inference). Kami menyarankan memakai APIYI (apiyi.com) agar Anda bisa membandingkan beberapa model dengan satu kunci API, lalu membangun baseline kualitas yang dapat dilacak pada data bisnis Anda sendiri.

📚 Referensi

1. Blog Riset Anthropic – Progress on provable inference for large language models: Artikel rilis asli FlashProve
2. Tautan: anthropic.com/research/provable-inference

3. Keterangan: Berisi desain sistem, data hasil pengujian, perbandingan dengan solusi yang sudah ada, serta penjelasan keterbatasannya

4. Laporan Teknis FlashProve: Detail teknis lengkap yang dilampirkan pada blog riset

5. Tautan: anthropic.com/research/provable-inference (lihat tombol Read the technical report di dalam halaman)

6. Keterangan: Berisi batasan-batasan penting, seperti cara penghitungan throughput, keterbatasan pembuktian pasca-kejadian (post-hoc), dan batas verifikasi formal

7. Anthropic Frontier Safety Roadmap: Penjelasan perkembangan proyek verifikasi inferensi

8. Tautan: anthropic.com
9. Keterangan: Untuk memahami perbedaan antara inference verification dan FlashProve

Penulis: Tim Teknis APIYI
Diskusi teknis: Silakan hubungi kami lewat beranda resmi APIYI. Materi integrasi lainnya bisa diakses di pusat dokumentasi docs.apiyi.com

Artikel terkait

• Model yang “Menjadi Lebih Bodoh” Belum Tentu Diganti: 6 Jenis Penyebab Umum Hasil Tidak Normal saat Memanggil API dan Urutan Pemeriksaan dalam 3 Langkah: Anthropic merilis riset pembuktian inferensi FlashProve, tetapi meski identitas bobot telah dikonfirmasi, penurunan kemampuan masih bisa disebabkan oleh petunjuk sistem, pemotongan konteks, atau parameter decoding; artikel ini merangkum penyebab umum dan urutan pemeriksaannya.