Evaluasi Model AI Sebelum Beralih Penyedia API: Checklist Alur Kerja

Mengganti penyedia API AI bukanlah keputusan peringkat leaderboard model. Ini adalah perubahan produksi yang dapat mengubah kualitas output, validitas JSON, panggilan alat, latensi, perilaku rate limit, penanganan error, dan total biaya sekaligus.

Pendekatan paling aman adalah mengubah pergantian yang diusulkan menjadi uji penerimaan yang dapat diulang. Jalankan model yang saat ini dipakai dan kandidat pada kasus-kasus yang berbentuk produksi yang sama, beri skor pada hasil alur kerja lengkap, definisikan gate migrasi yang tegas sebelum melihat hasil, dan tampilkan kandidat secara bertahap di belakang rute yang siap rollback.

Panduan ini memberi Anda proses tersebut, termasuk scorecard, desain dataset, matriks kompatibilitas, metode pengujian berpasangan, rumus biaya, tahap rollout, dan memo keputusan.

Jawaban singkatnya: gunakan uji penerimaan pergantian penyedia

Sebelum memindahkan traffic produksi, minta rute kandidat lulus lima pemeriksaan berikut:

1. Kualitas alur kerja: Menyelesaikan tugas pengguna dengan tingkat keberhasilan yang dapat diterima pada input yang representatif.
2. Kompatibilitas kontrak: Output terstruktur, panggilan alat, streaming, error, dan status akhir berfungsi dengan aplikasi Anda.
3. Keandalan operasional: Latensi, timeout, rate limit, retry, dan konkurensi tetap berada dalam tujuan layanan Anda.
4. Nilai ekonomi: Biaya efektif per tugas yang diterima membaik atau tetap berada dalam tradeoff yang disetujui.
5. Peluncuran aman: Shadow traffic dan canary bertahap menunjukkan bahwa hasil offline bertahan dalam kondisi produksi.

Jangan menyetujui pergantian hanya karena kandidat menang pada benchmark publik, menghasilkan beberapa jawaban yang mengesankan, atau memiliki harga token yang diiklankan lebih rendah. Sinyal-sinyal itu dapat membantu membuat shortlist. Namun, itu tidak membuktikan bahwa penyedia dapat menjalankan alur kerja Anda.

Mulailah dengan keputusan migrasi, bukan daftar model

Tulis keputusan satu kalimat sebelum membangun evaluasi:

Ganti rute A dengan rute B untuk alur kerja X jika B tidak inferior dalam keberhasilan tugas, lolos setiap gate kontrak, memenuhi anggaran latensi dan keandalan produksi, serta menurunkan biaya efektif per tugas yang diterima sebesar jumlah yang disyaratkan.

Kalimat itu memaksa tim untuk mendefinisikan cakupan. Satu penyedia mungkin cocok untuk ekstraksi tetapi tidak untuk penggunaan alat secara agentik, atau untuk pengayaan batch tetapi tidak untuk asisten interaktif. Hindari kesimpulan universal "model terbaik" ketika keputusan sebenarnya menyangkut satu rute, satu beban kerja, dan satu batas operasi.

Catat input berikut dalam rencana evaluasi:

Jika perubahan integrasi itu sendiri masih belum pasti, tinjau checklist migrasi gateway API yang kompatibel dengan OpenAI sebelum menguji model. Antarmuka yang sama mengurangi perubahan kode, tetapi tidak membuat perilaku model identik.

Definisikan unit evaluasi sebagai trace lengkap

Unit evaluasi harus sesuai dengan hal yang dialami pelanggan Anda. Untuk classifier satu langkah, itu mungkin satu permintaan dan respons. Untuk agen, itu bisa berupa satu trace utuh yang berisi beberapa panggilan model, invokasi tool, percobaan ulang, dan jawaban akhir.

Rekaman trace yang berguna mencakup:

{
  "case_id": "support-refund-042",
  "segment": "refund-policy",
  "input": {},
  "expected_contract": {},
  "route": "candidate-b",
  "attempts": 1,
  "latency_ms": 1840,
  "input_tokens": 3120,
  "output_tokens": 486,
  "provider_cost_usd": 0.0124,
  "schema_valid": true,
  "tool_sequence_valid": true,
  "task_success": true,
  "failure_class": null
}

Ini mencegah kesalahan pengukuran yang umum: hanya memberi skor pada prosa akhir sambil mengabaikan argumen yang salah format, tool berulang, percobaan ulang tersembunyi, atau lonjakan latensi yang membuat alur kerja tidak dapat digunakan.

Bangun set pengujian yang menyerupai produksi

Set evaluasi harus merepresentasikan distribusi dan mode kegagalan dari rute yang ingin Anda migrasikan. Memilih secara acak tumpukan kecil prompt yang "umum" biasanya menyembunyikan kasus yang menyebabkan insiden.

Gunakan enam kelompok kasus:

1. Kasus sering: Input yang bertanggung jawab atas sebagian besar trafik normal.
2. Kasus bernilai tinggi: Tugas di mana jawaban yang salah menyebabkan koreksi manual yang mahal atau kehilangan konversi.
3. Kasus long-tail: Bahasa, format, domain, atau maksud pengguna yang jarang.
4. Kasus kontrak: Input yang menekan schema, enum, objek bertingkat, tool, dan perakitan streaming.
5. Kasus adversarial: Instruksi ambigu, bukti yang saling bertentangan, prompt injection, dan permintaan yang tidak didukung.
6. Kasus operasional: Konteks besar, output panjang, burst konkurensi, timeout, dan error di sisi penyedia.

Stratifikasi dataset sehingga setiap segmen penting memiliki cukup contoh untuk diperiksa secara terpisah. Sebuah kandidat bisa terlihat memadai secara agregat, tetapi gagal pada satu bahasa, satu alat, atau satu tier pelanggan.

Jaga tiga lapisan dataset:

• Development set: Kasus yang terlihat dan digunakan untuk menyempurnakan prompt dan validator.
• Decision set: Kasus yang disisihkan untuk menyetujui atau menolak migrasi.
• Production audit set: Kasus baru yang diambil setelah peluncuran untuk mendeteksi drift.

Jangan berulang kali menyesuaikan terhadap decision set. Begitu tim telah melihat kegagalannya dan mengubah sistem, kasus-kasus tersebut pada dasarnya telah menjadi data development.

Bekukan kondisi pengujian

Perbandingan berpasangan hanya berguna ketika incumbent dan kandidat menerima pekerjaan yang setara. Bekukan atau catat:

• Instruksi sistem dan developer.
• Input pengguna dan lampiran.
• Definisi tool dan JSON Schema.
• Temperature, output maksimum, seed jika didukung, dan pengaturan reasoning.
• Hasil retrieval dan urutan dokumen.
• Region, versi API, pengenal model, dan route provider.
• Kebijakan retry, timeout, dan concurrency.
• Waktu evaluasi dan sumber harga.

Jika satu route menggunakan prompt yang berbeda karena provider mensyaratkannya, versi-kan kedua prompt dan perlakukan perbedaan itu sebagai bagian dari paket migrasi. Keputusan bisnis berkaitan dengan sistem baru, bukan model abstrak yang terpisah dari integrasinya.

Jalankan setiap kasus melalui kedua route. Acak atau sembunyikan presentasi saat manusia memberi skor pada output subjektif, agar penilai tidak dipengaruhi oleh nama provider.

Tetapkan batas tegas sebelum skor berbobot

Skor berbobot berguna untuk trade-off, tetapi tidak boleh memungkinkan model murah mengompensasi kegagalan kontrak yang kritis.

Tentukan terlebih dahulu gate yang tidak dapat ditawar. Contoh gate bisa mencakup:

• Tidak ada eksekusi tool yang tidak sah.
• Tidak ada rahasia atau data terbatas dalam output.
• JSON yang diwajibkan berhasil di-parse dan divalidasi terhadap skema produksi.
• Bahasa yang diwajibkan tetap berada di atas ambang minimum keberhasilan tugas.
• Rate timeout dan server-error tetap berada dalam anggaran yang disetujui.
• Klien menangani penghentian streaming dan error provider dengan benar.
• Route rollback diuji sebelum paparan ke produksi.

Ambang batas harus berasal dari risiko produk Anda dan baseline saat ini. Angka di bawah ini adalah scorecard ilustratif, bukan rekomendasi universal:

Publikasikan bobot dan gerbang sebelum run final. Mengubahnya setelah hasil tiba mengubah evaluasi menjadi pembenaran.

Periksa objektif skor sebelum menggunakan penilai model

Gunakan validator deterministik sejauh mungkin:

• Parsing JSON dan validasi JSON Schema.
• Pencocokan field yang persis atau dinormalisasi.
• Pemeriksaan toleransi numerik.
• Validasi sitasi dan URL.
• Validasi alat yang diizinkan dan argumen.
• Pemeriksaan urutan alat dan langkah maksimum.
• Kompilasi kode, unit test, dan eksekusi dalam sandbox.
• Aturan kebijakan dan detektor konten terlarang.
• Cakupan bukti retrieval.

Gunakan tinjauan manusia atau penilai berbasis model untuk kriteria yang tidak dapat direduksi menjadi pemeriksaan deterministik, seperti kejelasan, nada, sintesis, atau apakah sebuah jawaban mengikuti instruksi bernuansa.

Saat menggunakan penilai model:

1. Berikan rubrik yang sempit dengan kondisi lulus yang dapat diamati.
2. Kalibrasikan terhadap sampel yang dinilai manusia.
3. Sembunyikan identitas penyedia jika memungkinkan.
4. Pertahankan prompt penilai, versi model, dan rasional mentah.
5. Kirim perbedaan pendapat dan kasus batas ke tinjauan manusia.

Pedoman evaluasi OpenAI merekomendasikan eval khusus tugas dan evaluasi berkelanjutan, sementara Anthropic juga merekomendasikan pendefinisian kriteria sukses yang dapat diamati dan membangun evaluasi di sekitarnya. Implikasi praktisnya sederhana: rubrik Anda harus mendeskripsikan hasil alur kerja yang Anda perlukan, bukan kecerdasan umum.

Bandingkan hasil berpasangan dan ketidakpastian

Skor rata-rata saja dapat menyembunyikan ketidakstabilan. Karena kedua rute memproses kasus yang sama, bandingkan keduanya kasus per kasus.

Untuk keberhasilan tugas biner, buat tabel berpasangan:

Dua kelompok ketidaksepakatan ini sangat berguna. Tinjau secara manual dan klasifikasikan akar penyebabnya sebelum menyetujui pergantian.

Untuk hasil yang layak dijadikan dasar keputusan, laporkan interval kepercayaan di sekitar perbedaan dalam keberhasilan tugas, biaya, dan latensi. Bootstrap berdasarkan case ID adalah metode yang praktis karena dapat mempertahankan struktur berpasangan tanpa mengasumsikan bahwa setiap metrik mengikuti distribusi normal.

Gunakan aturan non-inferiority ketika kandidat menawarkan manfaat yang jelas, seperti biaya lebih rendah atau ketersediaan regional yang lebih baik, dan produk dapat mentoleransi perbedaan kualitas kecil yang dibatasi. Tentukan margin yang diizinkan sebelum pengujian. Setujui hanya ketika interval kepercayaan tidak melintasi batas regresi yang tidak dapat diterima.

Selain itu, periksa hasil berdasarkan segmen. Hasil keseluruhan yang lulus tidak boleh menutupi kasus kontrak yang gagal, bahasa, alat, atau alur kerja bernilai tinggi.

Gunakan taksonomi kegagalan di level trace

Setiap kasus yang gagal harus menerima satu kelas kegagalan utama. Taksonomi yang konsisten mengubah evaluasi menjadi pekerjaan engineering, bukan perdebatan berdasarkan anekdot.

Lacak baik kegagalan pertama maupun hasil trace final. Retry yang memulihkan sebuah permintaan tetap menghabiskan waktu dan uang, dan pemulihan berulang dapat menjadi masalah kapasitas produksi. Panduan batas rate LLM menjelaskan cara memisahkan RPM, TPM, antrean, retry, dan perilaku fallback.

Uji kompatibilitas penyedia sebagai matriks

Endpoint yang kompatibel dengan OpenAI dapat mengurangi pekerjaan migrasi, tetapi kompatibilitas bukanlah sesuatu yang biner. Uji fitur-fitur tepat yang digunakan aplikasi Anda.

Dokumentasi output terstruktur Google, misalnya, mencatat bahwa dukungan skema didasarkan pada subset JSON Schema. Itulah mengapa Anda harus menguji skema aktual Anda, alih-alih mengasumsikan bahwa skema yang diterima oleh satu provider akan berperilaku identik di mana pun.

Hitung biaya efektif per tugas yang diterima

Harga token hanyalah satu komponen dari ekonomi migrasi. Ukur total biaya untuk mendapatkan hasil yang dapat digunakan:

biaya efektif per tugas yang diterima =
  (penggunaan model
   + retry
   + penggunaan fallback
   + biaya tool dan retrieval
   + panggilan evaluasi atau moderasi
   + biaya infrastruktur tambahan)
  / tugas yang diterima

Perkirakan juga biaya review manusia yang muncul akibat hasil dengan keyakinan rendah atau hasil yang salah format. Kandidat dengan token yang lebih murah bisa jadi lebih mahal jika meningkatkan retry, loop tool, antrean review, atau output yang ditolak.

Untuk harga rute saat ini, gunakan perbandingan harga API AI sebagai titik awal, lalu pastikan model dan harga yang tepat pada saat pengambilan keputusan. Simpan stempel waktu harga bersama hasil Anda karena harga dan ketersediaan model dapat berubah.

Laporkan biaya per segmen maupun keseluruhan. Kasus konteks panjang, tugas multibahasa, input gambar, dan trace agen dapat menghasilkan pemenang yang berbeda dari permintaan teks pendek.

Uji beban kandidat dengan kebijakan retry yang sebenarnya

Pengujian kualitas offline biasanya berjalan lambat dan berurutan. Produksi tidak.

Ulangi subset yang representatif pada concurrency yang diharapkan dan puncak. Ukur:

• Latensi trace end-to-end pada p50, p95, dan p99.
• Waktu ke token pertama dan waktu hingga selesai saat streaming penting.
• Waktu antre dibandingkan waktu provider.
• Respons rate-limit dan perilaku Retry-After.
• Timeout, kegagalan koneksi, dan error 5xx dari upstream.
• Jumlah retry dan tingkat pemulihan retry.
• Efek samping duplikat yang disebabkan oleh aksi tool yang di-retry.
• Frekuensi fallback dan rute akhir yang berhasil.

Gunakan perilaku retry terbatas yang sama seperti yang direncanakan untuk produksi. Retry tanpa batas dapat membuat tingkat keberhasilan terlihat bagus sambil melanggar batas latensi dan biaya. Jika kandidat memerlukan pengaturan retry atau antrean yang berbeda secara material, sertakan perubahan operasional itu dalam keputusan migrasi.

Jalankan shadow traffic sebelum canary

Shadow testing mengirim salinan input produksi yang memenuhi syarat ke kandidat sementara incumbent masih melayani pengguna. Ini mengungkap distribusi prompt yang realistis dan perilaku penyedia tanpa membiarkan output kandidat memengaruhi pelanggan.

Lindungi jalur shadow:

• Kecualikan traffic sensitif kecuali kontrol data kandidat telah disetujui.
• Nonaktifkan alat yang menimbulkan side effect atau arahkan ke mock.
• Redaksi atau tokenisasi field yang dibatasi jika diperlukan.
• Tetapkan batas volume dan biaya shadow.
• Jaga trace ID incumbent dan kandidat tetap terhubung untuk analisis berpasangan.
• Jangan biarkan retry shadow mengonsumsi anggaran kapasitas rute utama.

Hasil shadow harus dievaluasi dengan validator dan taksonomi kegagalan yang sama seperti set keputusan offline.

Lakukan canary pada perpindahan penyedia secara bertahap

Setelah gate offline dan shadow lolos, buka sebagian kecil traffic yang dapat diamati. Urutan praktis adalah:

1. Traffic internal dan sintetis.
2. Pengguna atau alur kerja berisiko rendah.
3. Persentase kecil dari traffic produksi yang memenuhi syarat.
4. Peningkatan bertahap dengan jendela observasi tetap pada setiap tahap.
5. Rollout penuh hanya setelah kandidat tetap berada di dalam setiap guardrail.

Tentukan pemicu rollback otomatis sebelum memulai. Contohnya termasuk regresi keberhasilan tugas, lonjakan kegagalan skema, pelanggaran latensi p95, peningkatan fallback rate, pembengkakan biaya, atau kegagalan kebijakan kritis.

Gunakan routing yang stabil sehingga percakapan, run agen, atau pelanggan yang sama tetap berada pada satu rute ketika perpindahan di tengah sesi akan merusak state. Jaga incumbent tetap hangat sampai jendela rollback ditutup.

Untuk pola keandalan multi-penyedia, lihat playbook routing fallback API LLM.

Pertahankan kebijakan routing setelah evaluasi

Hasilnya tidak harus "pindahkan semuanya." Banyak tim mendapatkan hasil yang lebih baik dengan melakukan routing secara sengaja:

• Rute yang berfokus pada kualitas untuk tugas kompleks atau bernilai tinggi.
• Rute berbiaya rendah untuk ekstraksi dan klasifikasi yang terbatas.
• Rute berlatensi rendah untuk saran interaktif.
• Rute regional untuk kebutuhan lokasi data atau ketersediaan.
• Rute fallback untuk rate limit dan gangguan.

Ini membuat evaluasi dapat digunakan kembali. Setiap rute memiliki kontrak, dataset, dan anggaran operasional. Kandidat baru bersaing untuk pekerjaan yang ditentukan alih-alih menjadi proyek migrasi tingkat platform lainnya.

Flatkey menyediakan satu lapisan akses yang kompatibel dengan OpenAI di berbagai penyedia model, yang dapat menyederhanakan pengujian berdampingan dan routing. Ini tidak menghilangkan kebutuhan evaluasi; ini mengurangi pekerjaan integrasi yang diperlukan untuk menjalankan evaluasi dan mempertahankan opsi rollback. Bandingkan rute saat ini di harga Flatkey.

Template memo keputusan perpindahan penyedia

Akiri evaluasi dengan catatan keputusan singkat yang ditandatangani:

Lampirkan hasil di tingkat kasus, versi runner, prompt, validator, respons mentah, dan cuplikan harga. Reviewer di masa depan harus dapat mereproduksi alasan mengapa perpindahan disetujui.

Checklist evaluasi model AI final

Sebelum beralih penyedia API AI, pastikan Anda telah:

• Menentukan alur kerja yang tepat dan rute kandidat.
• Mencatat baseline yang digunakan saat ini dan batas operasional.
• Membangun set pengembangan, keputusan yang ditahan, dan audit produksi.
• Memasukkan kasus umum, bernilai tinggi, long-tail, adversarial, kontrak, dan operasional.
• Mengunci prompt, alat, pengaturan, input retrieval, dan kebijakan retry.
• Menjalankan tes berpasangan antara incumbent dan kandidat.
• Menerapkan validator deterministik sebelum penilaian subjektif.
• Mengkalsibrasi penilai berbasis model apa pun terhadap manusia.
• Menentukan gerbang keras, bobot, dan margin non-inferiority sebelumnya.
• Melaporkan interval kepercayaan dan hasil di tingkat segmen.
• Mengklasifikasikan kegagalan trace secara konsisten.
• Menguji skema, alat, streaming, error, penggunaan, dan batas rate limit.
• Menghitung biaya efektif per tugas yang diterima.
• Melakukan load test pada concurrency yang diharapkan dan puncak.
• Menyelesaikan tinjauan privasi, retensi, regional, dan kontrol akses.
• Lolos pemeriksaan shadow traffic dan canary bertahap.
• Menguji rollback otomatis dan menjaga incumbent tetap tersedia.
• Menandatangani dan menyimpan memo keputusan pergantian penyedia.

Pertanyaan yang sering diajukan

Berapa banyak kasus uji yang cukup untuk evaluasi model AI?

Tidak ada jumlah universal. Gunakan kasus yang cukup untuk mencakup setiap segmen material dan mempersempit ketidakpastian di sekitar keputusan migrasi. Segmen berisiko tinggi atau berfrekuensi rendah mungkin memerlukan oversampling yang disengaja. Laporkan interval kepercayaan alih-alih memperlakukan ukuran sampel sebagai bukti itu sendiri.

Haruskah saya menggunakan benchmark publik untuk memilih penyedia API?

Gunakan benchmark untuk membuat daftar pendek atau memahami kapabilitas umum. Jangan gunakan benchmark sebagai gerbang migrasi. Prompt, alat, skema, anggaran latensi, kebijakan retry, kontrol data, dan campuran trafik Anda menentukan kecocokan produksi.

Apakah satu base URL yang kompatibel dengan OpenAI bisa membuat penyedia saling dapat dipertukarkan?

Ini dapat memusatkan autentikasi dan mengurangi perubahan pada klien. Namun, ini tidak dapat menjamin dukungan parameter yang identik, output terstruktur, perilaku tool, event streaming, batasan, atau kualitas model. Uji matriks kompatibilitas untuk setiap route yang Anda gunakan.

Apa metrik paling penting saat beralih penyedia?

Untuk sebagian besar sistem otomasi, mulailah dengan keberhasilan penyelesaian alur kerja end-to-end. Lalu jelaskan hasil itu باستخدام kualitas, validitas kontrak, latensi, keandalan, retry, fallback, dan biaya efektif.

Kapan evaluasi harus dijalankan ulang?

Jalankan ulang saat versi model, route penyedia, prompt, tools, sistem retrieval, harga, distribusi workload, kebijakan risiko, atau envelope traffic berubah secara material. Tetap jalankan audit kontinu yang lebih kecil setelah peluncuran agar regresi muncul sebelum migrasi terjadwal berikutnya.

Buat setiap perpindahan penyedia dapat direproduksi

Aset yang tahan lama bukanlah model yang menang. Melainkan sistem evaluasinya: kasus yang diberi versi, capture trace, validator, grader, scorecard, load test, kontrol rollout, dan catatan keputusan.

Dengan sistem tersebut, penyedia baru menjadi eksperimen yang terbatas, bukan penulisan ulang yang berisiko. Anda dapat mengukur kandidat terhadap kontrak produksi yang sama, mengeksposnya secara bertahap, dan membatalkan perubahan dengan cepat jika kenyataan tidak sesuai dengan laboratorium.

Sumber

• OpenAI: Praktik terbaik evaluasi
• OpenAI: Bekerja dengan evals
• Anthropic: Menentukan kriteria sukses dan membangun evaluasi
• Anthropic API: Batas rate
• Google Gemini API: Output terstruktur
• Google Gemini API: Pemanggilan fungsi