Spesifikasi bersama yang dibekukan

Kebanyakan perbandingan sudah rusak sebelum baris pertamanya diisi. Satu proyek diwakili demo yang baru dirilis minggu ini, proyek lain diwakili dokumentasi yang terakhir disentuh setahun lalu. Dua bahan itu tidak pernah menjawab pertanyaan yang sama, sehingga tabel apa pun yang disusun di atasnya hanya mengulang perbedaan bahan.

Urutan kerjanya karena itu dibalik. Spesifikasi dibekukan lebih dulu, lalu kedua proyek dimasukkan ke dalamnya. Bentuk minimum yang perlu disepakati sebelum baris pertama diisi ada pada tabel berikut.

Unsur yang dibekukanIsi yang dicatatBila tidak bisa disamakan
Tanggal potong dan releaseVersi atau commit yang diuji pada kedua sisi, beserta tanggalnyaBaris ditandai tidak sebanding, bukan dinilai nol
Tugas dan inputPerintah, data masukan, dan kriteria berhasil yang identikTulis tugas pengganti dan sebutkan apa yang berubah
Chain dan izinJaringan, dompet uji, dan batas izin yang diberikanCatat selisih izin sebagai batas pengujian
Tingkat aksesApa yang boleh dilihat penguji: repo, trace, dashboard, atau hanya demoAkses yang ditolak dicatat apa adanya di ringkasan

Kolom paling kanan dipakai sesering dua kolom lainnya. Pembaca yang melihat satu sel kosong perlu tahu apakah kosong itu berarti gagal, atau berarti tidak pernah bisa diuji.

Ambang bukti yang sama di kedua sisi

Ambang yang dipakai ada empat: seberapa langsung bukti menyentuh klaim, apakah bukti terikat ke versi tertentu, apakah bisa direproduksi, dan siapa yang membuatnya. Keempatnya diterapkan ke kedua proyek dengan ketat yang sama, termasuk ke proyek yang lebih Anda sukai.

Dua jebakan muncul berulang:

  • repo open-source yang isinya tidak bisa dihubungkan ke deployment yang sedang berjalan dianggap otomatis mengalahkan demo tertutup yang punya trace lengkap, padahal yang satu terbuka tetapi tidak relevan dan yang lain tertutup tetapi relevan;
  • satu laporan dari tim proyek dihitung berkali-kali sebagai konfirmasi karena dikutip ulang di beberapa tempat.

Catatan arsip: untuk setiap bukti simpan jenis sumber, versi yang dirujuk, apakah reproduksi berhasil, batas yang diakui, dan statusnya sekarang.

Kasus normal, variasi, dan kegagalan yang disuntikkan

Otonomi tidak terbaca dari halaman pemasaran. Ia terbaca dari apa yang terjadi ketika alat yang dipanggil mati di tengah jalan. Jalankan kasus normal, satu variasi di luar skenario demo, dan satu kegagalan alat yang sengaja disuntikkan, persis dalam urutan yang sama untuk kedua proyek.

Satu hal mudah terbalik di tahap ini. Otonomi yang lebih tinggi bukan nilai lebih dengan sendirinya: untuk tindakan yang memindahkan dana, sistem yang berhenti lebih awal sering kali lebih tepat daripada sistem yang terus berjalan tanpa bertanya. Trace kedua proyek disimpan sejajar supaya klaim semacam itu bisa diperiksa ulang orang lain.

Yang dicatat selama pengujian berjalan:

  • siapa yang memilih alat berikutnya, sistem atau manusia;
  • apakah rencana diubah sendiri setelah hasil antara tidak sesuai harapan;
  • di titik mana sistem meminta klarifikasi, dan apakah permintaan itu masuk akal;
  • di titik mana sistem berhenti, dan apakah berhenti itu dirancang atau kebetulan;
  • berapa kali manusia harus masuk agar tugas selesai.

Izin dan kerugian maksimum sebagai ambang terpisah

Dimensi izin tidak ikut dirata-ratakan bersama dimensi lain. Kerugian maksimum, susunan signer, limit belanja, kemampuan mencabut izin, dan ketahanan terhadap prompt injection berdiri sebagai ambang yang harus dilewati, bukan sebagai nilai yang bisa ditutup oleh dimensi lain.

Alasannya sederhana. Demo yang mengesankan tidak mengurangi kerugian ketika allowance tak terbatas disalahgunakan, dan tidak ada skor kemampuan yang membatalkan kunci treasury yang dipegang satu orang. Satu cacat izin kritis membatalkan baris itu, lalu ditulis apa adanya di ringkasan.

Bila satu proyek menolak memperlihatkan susunan izinnya, baris itu tetap unknown. Unknown bukan sinonim dari aman, juga bukan sinonim dari buruk; ia hanya berarti belum ada yang bisa diperiksa.

Biaya penuh dan pendapatan bersih pada satu periode

Angka ekonomi hanya sebanding bila penyebutnya sama. Pakai satu tugas yang benar-benar diterima sebagai satuan, dan periode kalender yang sama untuk kedua sisi. Model yang tarifnya murah bisa berakhir lebih mahal karena memerlukan banyak percobaan ulang, dan percobaan ulang itu tetap dibayar.

  1. Kumpulkan pemakaian nyata, kegagalan, dan jam manusia pada periode yang dipilih, lalu kalikan dengan tarif bertanggal.
  2. Keluarkan penjualan token, hibah, dan subsidi dari baris pendapatan produk; keduanya boleh ditampilkan, tetapi tidak pada baris yang sama.
  3. Data yang tidak tersedia ditulis sebagai rentang dengan asumsi terburuknya, bukan dibulatkan menjadi satu angka yang terlihat rapi.

Perbandingan ekonomi yang jujur sering berakhir dengan dua rentang yang bertumpang tindih. Itu hasil yang sah, dan lebih berguna daripada selisih persen yang dibangun dari asumsi terbaik di satu sisi dan asumsi terburuk di sisi lain.

Putusan per dimensi

Penutup berkas ini bukan satu peringkat. Untuk setiap dimensi, yaitu kemampuan, mutu bukti, ekonomi, keamanan, kebutuhan blockchain, dan kebutuhan token, ditulis proyek mana yang lebih kuat, pembaca seperti apa yang terpengaruh oleh perbedaan itu, dan apa yang masih belum diketahui.

Hasil yang terbelah justru yang paling sering benar. Satu proyek bisa lebih terbukti perilakunya tetapi tokennya sulit dibenarkan, proyek lain bisa jauh lebih rapi kontrol izinnya tetapi belum punya bukti pendapatan sama sekali. Memaksa dua kolom itu menjadi satu pemenang membuang justru informasi yang dicari pembaca.

Kondisi yang akan membalikkan putusan ikut dituliskan: release berikutnya, perubahan susunan signer, atau satu reproduksi independen yang gagal. Tanpa kondisi itu, perbandingan ini belum selesai ditulis.

Setelah riset selesai: jika langkah berikutnya hanya memastikan apakah token didukung Binance, baca cara mendaftar Binance setelah meneliti proyek AI, lalu periksa aset, jaringan, dan produk yang tersedia untuk lokasi Anda. Pemeriksaan listing tidak menggantikan penilaian keaslian produk di atas.

Yang dicatat sebelum, selama, dan sesudah

Bagian ini mengubah riset di atas menjadi catatan yang dapat diulang orang lain. Pemeriksaannya dikelompokkan menurut kapan ia dikerjakan: sebelum perbandingan dimulai, selama kedua sistem dijalankan, dan ketika hasilnya dirangkum. Tidak satu pun darinya menghasilkan rekomendasi.

Sebelum perbandingan dimulai

Yang dicari pada tahap ini cuma satu: materi yang berdiri di satu baris punya waktu dan kedekatan yang serupa. Cara mengujinya adalah menukar tanggal potong, release, atau input antara kedua sisi; keunggulan yang lenyap setelah ditukar berasal dari spesifikasi, bukan dari proyeknya. Tugas atau batas izin yang berbeda menciptakan keunggulan semu, dan baris semacam itu tidak menghasilkan pemenang — yang dilaporkan adalah spesifikasinya.

Selama kedua sistem dijalankan

Perilaku pada kasus yang sama harus bisa disejajarkan langkah demi langkah. Gagalkan alat dengan sengaja, lalu keluarkan permintaan dari skenario demo. Bila yang tersisa untuk dibandingkan ternyata hanya label otonomi dari materi pemasaran, pengujiannya belum benar-benar berjalan. Yang dicatat adalah titik pertama yang menuntut campur tangan manusia, bukan tingkat otonomi tertinggi yang pernah terlihat.

Pada rangkaian yang sama, jalankan juga jalur kerugian terburuk: allowance, penggantian signer, pencabutan izin, dan prompt injection. Cacat izin yang kritis harus muncul di ringkasan, bukan terkubur di catatan kaki, dan kontrol yang hanya tertulis di dokumen tanpa pernah dijalankan pada kondisi gagal tidak dihitung sebagai kontrol. Batas keamanan mengalahkan skor tertimbang: satu cacat kritis membatalkan baris itu.

Ketika hasilnya dirangkum

Artefak sejenis harus melewati ambang yang sama di kedua sisi. Periksa apakah bukti masih berdiri pada versi lain atau di tangan pihak ketiga, dan hitung berapa kali satu materi dari tim proyek dipakai ulang sebagai konfirmasi yang terlihat independen. Reproduksi yang gagal menurunkan keyakinan, tanpa ikut menurunkan penilaian kemampuan.

Unit economics diperlakukan dengan cara yang sama. Hitung ulang dari angka yang dipublikasikan, ulangi hitungan pada periode lain dan pada skenario dengan banyak percobaan ulang, lalu tolak campuran yang memakai kasus terbaik untuk biaya sekaligus kasus terbaik untuk pendapatan. Yang ditampilkan adalah rentang beserta asumsi terburuknya, bukan satu angka tunggal.

Terakhir, setiap perbedaan yang dilaporkan harus bisa ditarik kembali ke spesifikasi bersama. Baca ulang dimensinya dalam urutan berbeda, atau minta orang lain membacanya; begitu hasil multi-dimensi berubah menjadi peringkat investasi, berkas ini sudah keluar jalur. Tuliskan kondisi yang akan membalik putusan, karena tanpa itu putusannya belum selesai.

Pertanyaan umum

Dapatkah proyek beda chain dibandingkan?

Bisa jika tugas dan kriteria setara; gas, finality, dan model izin disesuaikan.

Apakah proyek paling transparan selalu lebih baik?

Transparansi menaikkan keyakinan, tetapi kemampuan dan keamanan tetap dinilai terpisah.

Haruskah ada pemenang?

Tidak. Trade-off per penggunaan biasanya lebih berguna daripada ranking tunggal.

Kapan tabelnya perlu diuji ulang?

Begitu ada release baru di salah satu sisi, baris yang tersentuh release itu dijalankan lagi, bukan seluruh tabel. Selama spesifikasi dan versi yang tercatat masih berlaku, baris lainnya tetap dipakai.

Bagaimana bila salah satu proyek menolak memberi akses?

Baris itu ditandai unknown dan tetap terlihat di ringkasan; akses yang ditolak tidak dihitung sebagai nilai nol, juga tidak dianggap lulus.

Sumber yang menopang berkas ini

  1. AI x Crypto: Exploring Use Cases and Possibilities — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  2. Building effective agents — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  3. Measuring AI agent autonomy in practice — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  4. OpenAI Evals — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  5. NIST AI 600-1: Generative AI Profile — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  6. OWASP Top 10 for Agentic Applications — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  7. Ethereum JSON-RPC API — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  8. AI agent with a spending limit for a treasury — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.