Baseten joey-1 mempertanyakan apakah setiap keputusan AI membutuhkan model besar
Model keputusan 2B, API seharga $0,01 per juta token masukan, dan cara praktis mengalihkan pekerjaan yang tidak pasti ke model lebih besar atau manusia.
“Tim mana yang perlu menangani tiket ini?” jarang membutuhkan jawaban lima paragraf. Yang dibutuhkan adalah salah satu dari beberapa tujuan yang sah, keyakinan yang cukup untuk memilih secara bertanggung jawab, dan cara meminta bantuan ketika permintaan tidak sesuai.
Baseten memperkenalkan joey-1 pada 29 Oktober 2026 untuk pekerjaan semacam itu. Dibangun oleh kelompok riset Base Labs miliknya, model ini berada di ujung kecil keluarga model keputusan bersama elephant-1 dan mammoth-1. Daya tariknya adalah kontrak keluaran yang lebih terbatas: keputusan dan probabilitas, bukan penjelasan yang dihasilkan lalu harus ditafsirkan aplikasi. Pengumuman Baseten memaparkan peluncurannya.
Peluang praktisnya adalah pembagian kerja yang berbeda. Biarkan model kecil menangani keputusan berulang yang didefinisikan dengan baik; belanjakan lebih banyak untuk sisa yang tidak pasti. Panduan ini menjelaskan perhitungan harga, tiga contoh aplikasi, dan pemeriksaan yang membuat strategi perutean seperti itu berguna.
Banner kartu model joey-1 resmi Baseten. Gambar: Base Labs / Baseten, dari repositori modelnya yang menyatakan lisensi MIT; diubah ukurannya dengan tambahan margin. Sumber gambar · Lisensi dan catatan gambar.
Model keputusan dimulai dari pilihan yang dapat diterima aplikasi Anda
Model bahasa umum dapat mengklasifikasikan permintaan dengan menulis “penagihan”, mengembalikan JSON, atau menjelaskan mengapa pelanggan layak memperoleh pengembalian dana. Masing-masing antarmuka memiliki tempatnya. Model keputusan khusus berfokus pada pemilihan di antara jawaban yang disediakan dan pelaporan probabilitas dalam bentuk terstruktur.
Ini mengubah pekerjaan yang Anda lakukan sebelum inferensi. Anda membutuhkan pertanyaan yang tepat dan pilihan yang menjelaskan tindakan bermakna. “Apa yang perlu kita lakukan?” merupakan kontrak lemah. “Kasus ini perlu diterima bagian penagihan, dukungan teknis, atau penipuan?” lebih terbatas, meskipun tetap membutuhkan kebijakan untuk permintaan yang cocok dengan beberapa tim atau tidak satu pun.
Halaman pustaka model joey-1 Baseten, diperiksa pada 2 November, mendokumentasikan masukan teks dan gambar, pertanyaan pilihan, keputusan ya/tidak, dan penilaian berurutan melalui /v1/systemone. Hasilnya ditujukan untuk penggunaan secara programatis. Hasil tersebut bukan pengganti pembuat penjelasan atau tanggapan terpisah ketika pengguna membutuhkannya.
Bayangkan model kecil sebagai meja pemilahan. Nilainya berasal dari memindahkan pekerjaan biasa ke tempat yang tepat sambil mengirim kasus tidak biasa kepada pihak dengan kewenangan atau konteks lebih besar. Meja yang dengan percaya diri salah merutekan kasus sulit menciptakan pekerjaan tersembunyi di tahap berikutnya, meskipun setiap inferensi murah.
Karena itulah aplikasi perlu mempertahankan ketidakpastian. Sistem perutean dapat mencatat label sementara, mengajukan pertanyaan klarifikasi, atau menyerahkan item kepada manusia. Sistem tidak harus mengubah setiap distribusi probabilitas menjadi tindakan bisnis langsung.
Satu sen membeli token masukan, bukan jumlah keputusan yang tetap
Saat diperiksa pada 2 November 2026, entri harga resmi mencantumkan $0,01 per 1 juta token masukan, dengan masukan tembolok dan keluaran tercantum seharga $0,00. “Satu sen” merujuk pada satuan token tersebut. Permintaan yang memuat riwayat panjang membutuhkan pemrosesan masukan lebih banyak dibandingkan permintaan pendek dengan cakupan yang ditentukan secara cermat.
Berikut contoh perhitungan menggunakan tarif masukan yang diterbitkan tersebut, sebelum pajak, layanan lain, atau ketentuan komersial. Perhitungan mengasumsikan masukan tanpa tembolok dan harga stabil; ini contoh perencanaan, bukan estimasi tagihan.
| Contoh beban kerja | Total token masukan | Biaya masukan pada $0,01 per juta |
|---|---|---|
| 100.000 permintaan × 500 token | 50 juta | $0,50 |
| 1 juta permintaan × 500 token | 500 juta | $5,00 |
| 10 juta permintaan × 500 token | 5 miliar | $50,00 |
| 1 juta permintaan × 2.000 token | 2 miliar | $20,00 |
Rumusnya sederhana: total token masukan dibagi 1 juta, dikalikan $0,01. Perhitungan operasional lebih luas. Sertakan biaya eskalasi, persiapan data, percobaan ulang, pemantauan, dan koreksi manual jika ada.
Misalkan dua konfigurasi perutean memiliki selisih biaya penggunaan model beberapa dolar. Satu konfigurasi mengirim lebih sedikit kasus untuk ditinjau, tetapi sesekali mengarahkan permintaan mendesak ke antrean lambat. Konfigurasi kedua mengeskalasi lebih banyak permintaan dan menghindari kesalahan itu. Pilihan yang tepat bergantung pada biaya kesalahan dan kapasitas peninjau yang tersedia, bukan sekadar tagihan token termurah.
Argumen itu semakin kuat ketika inferensi semakin murah. Setelah penggunaan model menjadi bagian kecil dari biaya total alur kerja, sedikit peningkatan kalibrasi atau rancangan label dapat lebih berarti daripada pengurangan harga token lebih lanjut. Inferensi murah memperluas jenis otomatisasi yang layak; inferensi murah tidak menghapus kebutuhan untuk menilai hasil.
Diagram perutean orisinal, terinspirasi oleh pendekatan eskalasi dalam pengumuman Baseten pada 29 Oktober. Ambang batas menjadi tanggung jawab aplikasi yang menerapkannya.
Perutean tiket merupakan tugas awal yang baik ketika label memiliki penanggung jawab
Dalam contoh alur dukungan, joey-1 menugaskan pesan masuk ke bagian penagihan, dukungan teknis, atau keamanan akun. Pertanyaan ya/tidak terpisah memeriksa apakah pelanggan meminta pengembalian dana. Skor berurutan mengidentifikasi seberapa mendesak kasus membutuhkan perhatian.
Pertanyaan tersebut berkaitan, tetapi tidak perlu dilebur menjadi satu label. Permintaan penagihan juga dapat mendesak. Permintaan keamanan akun dapat memuat tuntutan pengembalian dana. Memisahkan keputusan memudahkan pendefinisian apa yang diterima setiap tim dan kombinasi mana yang membutuhkan penanganan khusus.
Mulailah dengan menulis label bersama orang yang bertanggung jawab atas antrean. Sertakan contoh kasus yang menimbulkan perbedaan pendapat di masa lalu. Putuskan cara menangani pesan yang menyebut kegagalan pembayaran akibat bug perangkat lunak. Model tidak dapat menyelesaikan ketidakjelasan organisasi yang dibiarkan tidak terdefinisi oleh organisasi itu sendiri.
Untuk peluncuran, bandingkan rekomendasi dengan keputusan yang sudah ada sebelum memindahkan pekerjaan secara otomatis. Tinjau perbedaan berdasarkan kategori: kebijakan ambigu, konteks kurang, kesalahan model yang jelas, atau label historis yang keliru. Satu persentase akurasi agregat menyembunyikan berbagai masalah tersebut.
Pengumuman Baseten pada 29 Oktober menempatkan joey-1 sebagai model lini pertama dengan model saudaranya yang lebih besar tersedia untuk ketidakpastian. Baseten melaporkan latensi menyeluruh P50 sebesar 20 milidetik untuk rata-rata permintaan 2.000 token dalam kondisi layanan produksinya. Ini merupakan pengukuran vendor untuk beban kerja layanan tertentu, bukan jaminan latensi bagi aplikasi atau perangkat keras Anda. Sumber: Baseten.
Perute dokumen perlu mengenali ketika tujuan yang sesuai tidak tersedia
Contoh penggunaan kedua adalah penerimaan dokumen. Aplikasi menerima berkas dan perlu memutuskan apakah berkas itu masuk alur faktur, peninjauan pengeluaran, atau antrean arsip umum. Masukan teks dan gambar opsional dapat membuat model relevan untuk materi dokumen campuran, asalkan representasi yang dikirim memuat informasi yang dibutuhkan tugas.
Definisikan keputusan sebenarnya secara terbatas. Memeriksa apakah suatu halaman tampak sebagai faktur berbeda dari memverifikasi bahwa faktur itu autentik, memadai secara hukum, atau dapat dibayar. Pengklasifikasi dapat membantu memilih alur kerja tanpa menerima izin menyetujui pembayaran.
Kasus uji paling berharga mungkin justru berada di luar taksonomi: struk yang dilampirkan pada kontrak, gambar terlalu buram untuk dibaca, atau bahasa yang tidak didukung. Jika aplikasi hanya menawarkan tiga tujuan yang sah, aplikasi membutuhkan mekanisme lain untuk bukti yang tidak lengkap dan konten yang belum dikenal. Jalur peninjauan eksplisit lebih mudah dioperasikan daripada tebakan yang dipaksakan.
Pantau pula perubahan populasi masukan. Model yang selama evaluasi sebagian besar melihat faktur domestik pendek mungkin kemudian menerima laporan beberapa halaman dan surat-menyurat hasil pindai. Memantau hanya label akhir yang dipilih dapat melewatkan perubahan tersebut. Catat panjang permintaan, jenis masukan, ketidakpastian, dan hasil peninjauan dengan tingkat perlindungan privasi yang sesuai.
Kartu model yang diterbitkan, diperiksa pada 2 November, menjelaskan joey-1 sebagai model 2B parameter yang dilatih lanjutan dari Qwen3.5-2B dan mencantumkan lisensi MIT. Fakta tersebut mendukung pilihan penerapan dengan bobot terbuka. Fakta itu tidak menetapkan kebutuhan memori universal, kinerja CPU, atau izin untuk menggunakan kembali setiap ilustrasi dari pengumuman.
Pemeriksaan gambar menjadi berguna ketika kondisinya dapat diamati
Untuk skenario ketiga, bayangkan pemeriksaan foto produk yang dikirim sebelum masuk peninjauan katalog manual. Pertanyaan berguna dapat menanyakan apakah label terlihat, apakah gambar memuat objek yang diminta, atau apakah foto terlalu terhalang untuk dinilai. Setiap pertanyaan perlu menyebut sesuatu yang dapat diamati dalam gambar yang diberikan.
Rubrik yang tidak membantu mencampurkan pengamatan dengan fakta tersembunyi. “Apakah ini penjual yang dapat dipercaya?” tidak dapat dijawab hanya dari foto produk. “Apakah area nomor seri yang diminta terlihat?” lebih terbatas dan memberi alur berikutnya alasan konkret untuk meminta gambar lain.
Penilaian berurutan dapat berguna ketika para peninjau sudah memiliki rubrik bersama, seperti tidak dapat digunakan, perlu ditinjau, dan dapat digunakan. Tulis kriteria dengan istilah yang dapat diterapkan peninjau secara konsisten. Jika dua tingkat bersebelahan tidak dapat dibedakan bahkan oleh manusia, distribusi probabilitas tidak akan memperbaiki taksonominya.
Gunakan model untuk memprioritaskan peninjauan sebelum mengizinkan penolakan otomatis. Kiriman yang ditolak dapat langsung memengaruhi pelanggan, dan biaya penolakan keliru dapat melampaui penghematan otomatisasi. Tahap peninjauan juga menyediakan contoh untuk menyempurnakan rubrik dan memeriksa apakah kinerja berbeda antar kondisi masukan.
Ini merupakan rancangan ilustratif, bukan penerapan joey-1 yang dilaporkan. Ciri bersamanya adalah pertanyaan terbatas yang diikuti langkah berikutnya yang dapat dibatalkan. Itu tempat yang masuk akal untuk mempelajari perilaku model pada data Anda.
Probabilitas membutuhkan kebijakan sebelum menjadi tindakan
Nilai keyakinan bukan penanda izin. Jika aplikasi memilih bertindak di atas 0,90, ambang itu merupakan pilihan rancangan yang konsekuensinya perlu diukur. Skor tinggi tetap bisa salah, terutama ketika permintaan berbeda dari data yang digunakan untuk menetapkan ambang.
Kesalahan berbeda layak mendapat kebijakan berbeda. Mengarahkan pertanyaan biasa ke tim dukungan yang salah menimbulkan ketidaknyamanan. Menganggap laporan pengambilalihan akun sebagai urusan rutin dapat jauh lebih merugikan. Ambang probabilitas yang sama tidak perlu otomatis mengatur kedua tugas.
Kerangka evaluasi orisinal. Cakupan, biaya tindakan keliru, dan kualitas eskalasi merupakan metrik aplikasi; diagram tidak melaporkan hasil joey-1 yang diukur.
Bangun kumpulan uji terpisah dengan kasus biasa yang representatif, kasus sulit, dan masukan di luar cakupan. Untuk setiap ambang usulan, periksa bagian yang ditangani otomatis dan kesalahan dalam bagian tersebut. Kemudian periksa apa yang terjadi pada sisanya: model yang menghindari kesalahan dengan mengeskalasi hampir semuanya dapat membuat alur kerja tetap tidak berubah.
Bandingkan seluruh rangkaian dengan model lebih besar yang digunakan sendiri. Rancangan yang mendahulukan model kecil menambahkan tahap perutean, yang memiliki mode kegagalan dan latensinya sendiri. Rancangan itu unggul ketika cukup banyak permintaan dapat ditangani secara tepat pada tahap pertama dan jalur eskalasi memperbaiki sisa yang sulit.
Mulai dengan API terkelola, atau anggarkan penyediaan sendiri secara eksplisit
Baseten menawarkan Model APIs terkelola, penerapan khusus, dan bobot yang dapat diunduh. Konteks serta kondisi penyajiannya perlu diperiksa secara terpisah. Artikel peluncuran menjelaskan konteks 16k untuk Model APIs dan pilihan penerapan khusus 262k, sementara kartu model menetapkan panjang urutan pelatihan 16.384 token dan menolak permintaan di luar batas pelatihannya. Tidak ada satu batas maksimum yang perlu disalin begitu saja ke semua jalur. Artikel peluncuran, kartu model.
- Pilih satu kontrak keputusan. Sebutkan pilihan yang sah, makna masing-masing, dan apa yang dilakukan aplikasi ketika bukti tidak mencukupi.
- Pilih jalur penerapan. Untuk proyek percontohan terkelola, buka entri API model dan buat kredensial dalam antarmuka akun penyedia. Untuk penyajian lokal, ikuti persyaratan lingkungan eksekusi dengan versi yang ditetapkan dalam kartu model.
- Kirim permintaan minimal. Contoh API resmi menggunakan
https://inference.baseten.co/v1/systemonedenganstate,questionsbertipe, dan pengenal modeldecision-models/baseten-joey-2b-latest. - Validasi tanggapan terstruktur. Tolak hasil yang tidak valid formatnya atau tidak tersedia, simpan probabilitas yang diperlukan untuk evaluasi, dan pertahankan kebijakan perutean dalam aplikasi Anda.
- Jalankan evaluasi bayangan. Bandingkan rekomendasi dengan hasil yang ditinjau sebelum mengaktifkan tindakan otomatis.
- Tambahkan dan ukur eskalasi. Arahkan kasus tidak pasti atau berkonsekuensi besar ke model lebih besar atau manusia, lalu periksa hasil seluruh jalurnya.
Kartu model mendokumentasikan penyiapan yang dihosting sendiri yang membutuhkan GPU CUDA dan lingkungan penyajian dengan versi yang ditetapkan. “2B” menjelaskan skala model; itu bukan janji bahwa sembarang laptop memiliki memori cukup. Sertakan beban tambahan lingkungan eksekusi, pemrosesan gambar, konkurensi, dan panjang konteks saat menentukan kapasitas penerapan.
Proyek percontohan API dapat menjawab pertanyaan kesesuaian produk sebelum Anda berinvestasi pada infrastruktur tersebut. Penyediaan sendiri menjadi keputusan terpisah tentang kendali, pemanfaatan, upaya operasional, dan biaya total. Bobot terbuka membuat pilihan itu tersedia; bobot terbuka tidak otomatis membuatnya ekonomis.
Kumpulan pemutaran ulang melindungi alur kerja ketika model atau perintah berubah
Simpan koleksi permintaan yang sudah ditinjau dengan versi yang tercatat setelah proyek percontohan pertama berfungsi. Sertakan kasus biasa, kesalahan mahal, dan contoh ketika jawaban yang benar adalah meminta bantuan. Simpan susunan pertanyaan dan deskripsi pilihan bersama hasil yang diharapkan, dengan menggunakan data yang Anda diizinkan untuk menyimpannya.
Ketika mengubah perintah, ambang, atau konfigurasi penyajian, jalankan ulang koleksi tersebut sebelum memperluas lalu lintas. Peningkatan dalam satu kategori dapat menyembunyikan regresi di kategori lain. Misalnya, perutean yang lebih tegas dapat mengurangi volume peninjauan sambil meningkatkan kesalahan pada pesan pendek yang ambigu. Rata-rata keseluruhan saja tidak dapat menjelaskan kompromi itu.
Catat pengenal model yang sebenarnya dan jalur penyajian yang digunakan untuk setiap evaluasi. Jika suatu penerapan mengikuti pengenal latest yang berubah, tetapkan cara mendeteksi perubahan perilaku dan meninjau kembali penerimaan. Skema aplikasi yang stabil tidak menjamin keputusan identik selamanya.
Latih pula kegagalan layanan. Batas waktu terlampaui, model tidak tersedia, atau tanggapan tidak valid perlu masuk jalur pemulihan yang ditentukan, bukan diam-diam memilih tim bawaan. Pilihan bawaan itu sendiri merupakan keputusan bisnis dan mungkin tidak sesuai untuk permintaan sensitif. Sistem model kecil yang andal menangani jawaban tidak tersedia dengan kesengajaan yang sama seperti jawaban berkeyakinan tinggi. Disiplin operasional itu penting meskipun biaya permintaan normal hanya sebagian kecil dari satu sen.
Model kecil membuat kualitas batas keputusan lebih terlihat
Menurut kami, joey-1 paling menarik ketika aplikasi sudah mendefinisikan pilihannya dengan jelas. Keputusan murah dan cepat dapat memindahkan pekerjaan dalam jumlah besar, tetapi taksonomi buruk hanya memindahkan kesalahan lebih cepat.
Pertanyaan bernilai adalah seberapa banyak pekerjaan yang dapat ditangani sistem dengan benar dalam cakupan yang diketahui, dan seberapa baik sistem menangani sisanya. Model kecil layak digunakan ketika jalur eskalasi menjadi bagian produk, bukan catatan kaki setelah harga.
Sumber
- Baseten: Keputusan seharga satu sen, memperkenalkan joey-1, 29 Oktober 2026.
- Pustaka model dan contoh API Baseten joey-1, diperiksa pada 2 November 2026.
- Kartu model Base Labs joey-1, diperiksa pada 2 November 2026. Entri tolok ukur dilaporkan penerbit; entri Artificial Analysis-nya diidentifikasi sebagai replika internal.
Hubungkan peninjauan Anda dengan sumbernya
Telli.sh adalah salah satu pilihan untuk menyimpan materi sumber yang diizinkan dan catatan di balik keputusan teknis. Buat ruang kerja catatan.