7 penggunaan Jev yang mengurangi pekerjaan nyata dalam perangkat lunak

Seseorang bertanya kepada situs web kami berapa banyak integrasi yang kami miliki. Situs itu menjawab dengan saran tentang berapa banyak kolom yang sebaiknya ada di formulir pendaftaran.

Jawabannya datang dengan cepat. Tetapi tidak berguna.

Kedua pertanyaan memuat kata “berapa banyak”. Kode pencarian kami memberikan skor minimum 0,86 pada kecocokan FAQ yang diterima, sehingga kecocokan yang lemah tampak meyakinkan. Kecepatan menutupi keputusan yang salah.

Kegagalan seperti itulah yang layak dipikirkan saat Anda melihat Ship with Jev. Pada 26 September 2026, direktori itu mencantumkan 551 karya komunitas. Gim berdampingan dengan komponen pencarian, agen peramban, alat riset, dan eksperimen perutean. Direktori menyebut angka kinerja sebagai klaim para pembuatnya; ini alat penemuan, bukan tolok ukur independen.

Pertanyaan yang menarik adalah pola mana di antaranya yang benar-benar mengurangi pekerjaan dalam produk nyata.

Bagi tim yang membangun integrasi dan perangkat lunak bisnis, inilah tujuh penggunaan yang akan saya evaluasi lebih dahulu. Urutannya adalah penilaian editorial tentang kegunaan dan kemudahan pengujian. Contoh alur kerja di bawah adalah rancangan usulan, kecuali jika disebutkan implementasi bertautan.

Apa yang ditambahkan Jev ke dalam aplikasi

TypeSafe menggambarkan Jev sebagai model untuk penilaian dengan tipe keluaran yang ditentukan. Anda memberinya keadaan yang relevan dan sebuah pertanyaan; Anda menerima pilihan, probabilitas, atau skor yang dapat dipakai kode. Peta kasus penggunaannya mencakup perutean, pengambilan, verifikasi, dan ekstraksi.

Pembedaan itu punya pendahulu yang berguna dalam materi YouTube yang kami impor. Dalam ceramah Diogo Almeida di AI Engineer, salah satu pendiri TypeSafe memperjuangkan perangkat lunak yang komponen dasarnya dapat mengungkapkan lebih banyak kecerdasan. Ia mempertentangkan ambisi itu dengan sekadar menempelkan asisten pada perangkat lunak yang sudah ada. Ini argumennya tentang arah AI, bukan pengukuran kinerja Jev saat ini.

Bayangkan sebuah persimpangan rel kereta. Keluaran yang berguna adalah jalur mana di antara yang tersedia yang harus diambil kereta. Satu paragraf yang menjelaskan jalur-jalur itu tidak menambah apa pun pada wesel.

Keberatannya masuk akal: “LLM biasa pun sudah bisa mengembalikan JSON.” Benar. Alasan untuk memakai komponen yang berbeda bertumpu pada kualitas, biaya, dan latensi yang terukur untuk keputusan itu. Respons bertipe saja tidak membuktikan satu pun dari ketiganya.

Tantangan dari CLM perlu dibahas lebih dahulu

Pada 23 September, Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré, dan Azalia Mirhoseini menerbitkan Contrastive Language Models. Karya mereka menantang anggapan bahwa Jev adalah satu-satunya jalur praktis menuju keputusan semantik yang cepat.

Para penulis melaporkan hasil zero-shot yang sebanding dengan Jev pada tugas penggunaan komputer, gim, dan pemanggilan alat, dengan latensi hingga 9× lebih rendah. Secara terpisah, mereka melaporkan 81,6% pada 38 tugas DeepSWE yang disisihkan untuk pengujian dan 87,6% pada 30 tugas Terminal-Bench 2.1. Hasil pemrograman tersebut memakai verifikator CLM yang disetel halus untuk memilih di antara solusi yang dihasilkan model lain. Mereka juga melaporkan hasil Jev di bawah acuan pemilihan acak pada pengaturan verifikator itu. Latensi diukur pada H100. Ini temuan para penulis, yang belum kami reproduksi secara independen. Evaluasi asli dan metodologinya.

Perbandingan itu mengubah apa yang harus kami uji. Memilih antrean dukungan, memilih bagian pencarian, dan menilai lintasan pemrograman yang panjang adalah tugas yang berbeda. Hasil yang baik pada satu tugas tidak menyelesaikan yang lain.

CLM mengodekan keadaan dan kandidat tindakan secara terpisah, sehingga embedding tindakan yang dapat digunakan kembali bisa disimpan dalam cache. Repositorinya mendokumentasikan antarmuka yang kompatibel dengan TypeSafe dan batas keadaan bawaan sebesar 2.048 token. Keadaan yang lebih panjang dipotong kecuali dikonfigurasi lain. Kompatibilitas pada batas API tidak membuktikan kesetaraan keputusan.

Kartu model yang dirilis menyebut embedding Qwen3-8B dan memperingatkan bahwa hasil verifikator yang kuat memerlukan head yang disetel halus. Kartu itu juga menegaskan bahwa CLM menilai kandidat yang diberikan dan tidak menghasilkan solusi. Bobot terbuka memberi pilihan untuk evaluasi; perangkat keras, penyajian, dan pemeliharaan tetap berbiaya.

Bagi Tajo, pelajarannya konkret: bandingkan model keputusan pada kasus yang sama, catat latensi dingin dan hangat secara terpisah, dan uji kandidat salah yang masuk akal. Kunci versi model serta encoder atau head proyeksi apa pun. Tolak konfigurasi penyedia yang tidak didukung alih-alih diam-diam memilih penyedia lain. Periksa ulang kalibrasi saat model atau himpunan kandidat berubah.

Tujuh alur kerja di bawah tetap menjadi kandidat yang berguna untuk dievaluasi. Nilainya tidak bergantung pada Jev memenangi setiap perbandingan.

1. Pencarian yang memeriksa apakah hasil menjawab pertanyaan

Ini pilihan pertama saya karena kegagalannya terlihat dan hasilnya mudah diberi label. Apakah bagian yang dikembalikan menjawab apa yang ditanyakan pengunjung?

Ambil sekumpulan kecil kandidat dengan pencarian kata kunci, embedding, atau keduanya. Lalu tanyakan kepada Jev apakah setiap bagian memuat fakta yang diminta. Cookbook pemeringkatan ulang dari TypeSafe memperagakan struktur dua tahap ini. Cookbook itu juga memperlihatkan batasnya: pemeringkat ulang tidak bisa memilih dokumen yang terlewat oleh tahap pengambilan.

1. Pengambilan

   kata kunci, embedding

   Kumpulan kandidat kecil

   Tak bisa menambah yang terlewat
2. Jev

   penilaian bertipe

   Apakah bagian ini

   memuat faktanya?
3. Jawaban

   atau tanpa jawaban

   Benar atau tak terjawab

   Total latensi diukur

Untuk contoh jumlah integrasi kami, jalur terpendeknya bahkan lebih sederhana. Hitung entri dalam katalog otoritatif. Jelaskan apa arti jumlah itu. Konektor yang terdokumentasi dan koneksi yang dikonfigurasi pelanggan adalah dua hal yang berbeda.

Simpan penilaian semantik untuk pertanyaan yang maknanya perlu ditafsirkan, seperti “Bisakah ini memindahkan hanya pelanggan yang berubah sejak kemarin?” Ambil dokumentasi sinkronisasi yang relevan, lalu periksa bahwa dokumen itu membahas pembaruan inkremental.

Implementasi jevsearch oleh Kyle McLaren membuat urutan ini nyata: hasil kata kunci datang lebih dulu, disusul peringkat Jev. Tolok ukur yang diterbitkannya memakai korpus dokumentasinya sendiri dan kueri berlabel. Itu bukti yang berguna tentang pengujian tersebut, bukan janji untuk situs web atau bahasa lain.

Ukur jawaban yang benar, jawaban tanpa dukungan, pertanyaan yang tak terjawab, dan total latensi. Sertakan salah ketik dan kueri terjemahan. Hasil tak relevan yang lebih cepat tetap tak relevan.

2. Meneruskan permintaan ke halaman, antrean, atau agen yang tepat

Seorang pengguna menulis: “Kontak berhenti masuk setelah saya mengganti akun.” Aplikasi Anda perlu membedakan pemecahan masalah koneksi dari penagihan, pemetaan kolom, dan permintaan membuat sinkronisasi baru.

Berikan layar saat ini, percakapan terbaru, dan tujuan yang tersedia bagi pengguna itu. Minta tujuan terbaik, dengan opsi eksplisit “tidak ada yang cocok”. Biarkan pengenal tujuan tetap di bawah kendali aplikasi.

Beberapa penilaian bisa berguna bersamaan: maksud, tujuan, urgensi, dan apakah pesan memuat permintaan yang dapat ditindaklanjuti. Pola fan-out dari TypeSafe memungkinkan pertanyaan yang independen berbagi satu permintaan. Setelah itu kode memakai jawaban yang relevan.

Saran navigasi yang tidak berbahaya dan izin untuk menjalankan pekerjaan adalah dua keputusan terpisah. Menemukan halaman penagihan yang tepat tidak memberi wewenang untuk pengembalian dana. Menemukan agen yang tepat tidak memberi agen itu kredensial.

Manfaat praktisnya adalah lebih sedikit pelimpahan dan lebih sedikit putaran klarifikasi. Ukur seberapa sering pengguna mencapai tujuan yang benar pada percobaan pertama. Simpan kumpulan pemutaran ulang yang berisi tindak lanjut seperti “ya”, “tugas baru”, dan “apakah yang tadi sudah selesai?” Kalimat-kalimat itu hanya masuk akal dengan konteks.

3. Memetakan data yang berantakan menjadi integrasi yang andal

Berikut alur kerja integrasi yang diusulkan. Ekspor sumber memuat customer_email, billing_email, dan account_owner_email. Tujuan mengharapkan alamat email kontak.

Kemiripan string menyisakan ambiguitas yang nyata. Deskripsi kolom, contoh nilai, dan tujuan bisnis membantu menyelesaikannya. Jev dapat memilih di antara kolom sumber yang sebenarnya, sementara kode memeriksa tipe, nilai wajib, dan batasan tujuan.

Cookbook ekstraksi pra-urai yang terkait memakai rancangan yang sangat berguna: kode menemukan nilai kandidat, model memilih satu kandidat, dan kode menyalin nilai aslinya. Dengan begitu tidak ada alamat atau jumlah pengganti yang dikarang.

1. Kode

   temukan kandidat

   customer_email

   billing_email

   account_owner_email
2. Jev

   pilih satu

   Deskripsi kolom

   Contoh nilai, tujuan
3. Kode

   salin nilai asli

   Tipe, nilai wajib

   Batasan tujuan

Untuk integrasi CRM dan email, simpan kolom sumber dan keputusan pemetaan bersama-sama. Tampilkan pratinjau rekaman yang terdampak. Biarkan pemetaan yang tidak pasti tetap belum diputuskan sampai ditinjau.

Ada keuntungan ekonomis di sini: pemetaan skema yang sudah disetujui dapat dipakai ulang. Anda tidak perlu memanggil model untuk setiap baris selama arti kolomnya tidak berubah.

Ukur rekaman yang ditolak dan pemetaan yang salah terhadap sampel yang sudah ditinjau. Permintaan API yang berhasil membuktikan bahwa muatan diterima; itu tidak membuktikan bahwa email yang benar sampai ke kontak yang benar.

4. Memilih model terkecil yang menyelesaikan tugas

Perutean model menarik ketika aplikasi mengirim semuanya ke model termahalnya. Pergantian label, penilaian pencarian, dan penyelidikan arsitektur yang sulit memiliki kebutuhan yang berbeda.

Pertama, tentukan model yang sudah dikonfigurasi dan diizinkan menerima data tugas. Catat alat yang didukung dan kinerja yang teramati. Setelah itu penilaian yang sempit dapat merekomendasikan opsi yang sesuai dari himpunan itu. TypeSafe memasukkan pola ini dalam contoh perutean modelnya.

Jev Router dari OpenRouter menyajikan pola ini sebagai ID model typesafe/jev-router lewat API obrolannya. Daftarnya menjelaskan pemilihan model sekaligus upaya penalaran seiring percakapan berubah. Evaluasi model hilir yang diizinkan, biaya sebenarnya, penanganan data, dan perilaku selama pemanggilan alat sebelum mengadopsinya. Kami memverifikasi daftar itu; kami belum menguji tolok ukur router ini.

Kebijakan yang kami sarankan dimulai dengan kode biasa untuk aturan dan fakta yang pasti. Pakai model keputusan untuk pertanyaan semantik yang terbatas, model generatif yang sesuai untuk menulis atau implementasi, dan eskalasi ketika bukti menuntutnya.

Apa yang dibutuhkan tugas ini?

1. Aturan dan fakta yang pasti

   Kode biasa

2. Pertanyaan semantik terbatas

   Model keputusan

3. Menulis atau implementasi

   Model generatif yang sesuai

4. Bukti menuntut lebih

   Eskalasi

Router itu sendiri memakan waktu dan uang. Untuk tugas berulang yang jelas, aturan tetap bisa lebih baik. Untuk tugas yang ambigu, bandingkan perutean dengan acuan model tetap pada pekerjaan yang sudah selesai.

Lacak biaya per hasil yang diterima, percobaan ulang, tingkat eskalasi, dan kegagalan yang ditemukan kemudian. Panggilan pertama yang lebih murah dapat menjadi alur kerja yang mahal jika seseorang harus memperbaiki keluarannya.

5. Memeriksa klaim sebelum menjadi jawaban untuk pelanggan

Sebuah kutipan bisa ada dan tetap tidak mendukung kalimat di sebelahnya. Sebuah sumber mungkin menjelaskan fitur yang direncanakan, sementara jawaban menyebutnya tersedia hari ini.

Cookbook pemeriksaan kutipan dari TypeSafe memisahkan dua pemeriksaan. Pencocokan string biasa mendeteksi kutipan yang hilang. Penilaian semantik mengevaluasi apakah sumber di sekitarnya mendukung klaim.

Terapkan rancangan yang sama pada balasan dukungan, panduan integrasi yang dihasilkan, atau laporan penyelesaian yang diusulkan agen. Simpan klaim, bagian sumber, dan putusannya agar tersedia untuk ditinjau.

Penyelesaian tetap memerlukan bukti langsung. Pengujian membuktikan perilaku yang diuji. Catatan deployment membuktikan adanya deployment. Penilaian semantik dapat menandai ketidakcocokan antara laporan dan buktinya; ia tidak dapat menciptakan bukti yang hilang.

Kasus penggunaan ini menarik karena dapat ditempatkan sebelum langkah penerbitan yang sudah ada. Ukur klaim tanpa dukungan yang lolos, klaim yang didukung tetapi diblokir tanpa perlu, dan beban kerja peninjauan yang timbul. Mulailah dari kesalahan eksplisit yang sudah Anda ketahui dibuat oleh sistem Anda.

6. Mengubah transkrip dan masukan pelanggan menjadi daftar pilihan yang berguna

Arsip transkrip menjadi berguna ketika seseorang dapat menemukan bagian yang penting. “Mengandung kata integrasi” adalah filter yang lemah untuk “menjelaskan mengapa pelanggan meninggalkan proses penyiapan”.

Satu pendekatan adalah mengambil bagian yang mungkin relevan, lalu menilai beberapa sifat tertentu: apakah bagian ini menggambarkan hambatan penyiapan, memuat contoh konkret, atau dapat berdiri sendiri tanpa konteks yang hilang?

Pertahankan URL sumber dan penanda waktu pada setiap bagian terpilih. Penanda waktu berasal dari transkrip. Model menilai relevansi.

Bagi editor video, sinyal itu dapat menghasilkan daftar pilihan klip untuk ditinjau. Bagi tim produk, sinyal itu dapat mengelompokkan keberatan yang berulang. Bagi pemasar, sinyal itu dapat memisahkan bukti dari pelanggan dari klaim kampanye yang tidak berdasar.

Pola skor komposit dari TypeSafe menjaga dimensi tetap terpisah sehingga kode dapat mengubah bobotnya. Klip yang cocok untuk tutorial mungkin berbeda dari klip yang cocok untuk demo produk singkat. Pakai ulang penilaian selama bukti dasar dan kriterianya tidak berubah.

JevQL menawarkan implementasi komunitas yang terkait: predikat semantik atas baris PostgreSQL, yang dievaluasi di luar basis data. Dokumentasinya membuat filter biasa relevan bagi tagihan. Kurangi baris yang memenuhi syarat sebelum meminta penilaian semantik.

Ukur penerimaan peninjau dan waktu yang dihemat dalam menemukan bahan yang dapat dipakai. Skor kekuatan pembuka bukan ramalan jumlah tayangan.

7. Antarmuka yang memilih tindakan berguna berikutnya

Layar pengaturan mungkin menerima perintah “Hentikan sinkronisasi ini sampai besok.” Agen peramban mungkin harus memilih di antara kontrol yang terlihat pada halaman saat ini.

Dalam rancangan antarmuka yang kami usulkan, aplikasi memberikan tindakan yang diizinkan dan keadaan saat ini. Jev memilih di antaranya. Antarmuka menampilkan kontrol yang relevan atau usulan yang dapat ditinjau.

Ship with Jev mencakup demo pencarian penerbangan melalui peramban oleh Gregor Zunic. Waktu eksekusi dan biaya yang dilaporkan berlaku untuk demonstrasi tersebut. Ide yang dapat diterapkan di tempat lain adalah memilih dari tindakan yang tersedia pada setiap langkah; alur peramban lain memerlukan verifikasinya sendiri.

Keadaan harus tetap mutakhir. Jika akun atau halaman yang dipilih berubah saat penilaian berlangsung, buang hasil yang sudah tidak sesuai. Kaitkan tindakan dengan akun dan keadaan yang telah ditinjau.

Ini juga dapat membuat katalog antarmuka dengan tipe data yang ditentukan menjadi berguna. Model memilih tampilan yang dikenal beserta data terbatasnya; kode perenderan biasa menghasilkan antarmuka. Ukur keberhasilan penyelesaian tugas dan tindakan yang salah, dengan perhatian khusus pada apakah kontrolnya tetap mudah dipahami.

Dari mana saya akan memulai

Pilih keputusan berulang yang sudah menimbulkan pemborosan nyata. Gunakan kegagalan sebenarnya untuk menyusun kumpulan evaluasi.

Masalah yang ada	Eksperimen pertama	Bukti yang layak dikumpulkan
Pencarian menjawab pertanyaan yang salah	Nilai daftar pendek hasil pengambilan	Jawaban benar, keputusan tidak menjawab, latensi
Permintaan berpindah-pindah antartim	Pilih dari antrean yang diizinkan	Akurasi perutean pertama, pelimpahan
Impor membutuhkan pemetaan manual	Pilih kolom sumber yang benar-benar ada	Kesalahan pemetaan, waktu peninjauan
Setiap tugas memakai model terbesar	Rutekan tugas yang memenuhi syarat	Biaya per hasil yang diterima
Jawaban yang dihasilkan membuat klaim berlebihan	Periksa klaim terhadap sumber	Klaim tanpa dukungan yang lolos
Tidak ada yang memakai arsip transkrip	Kembalikan kutipan dengan penanda waktu	Penerimaan peninjau, waktu menemukan bukti
Pengguna tidak dapat menemukan kontrol	Sarankan tindakan yang tersedia	Tingkat penyelesaian, pilihan yang salah

Jangan menyalin ambang keyakinan dari sebuah demo. Dokumentasi keyakinan TypeSafe menjelaskan bahwa tingkat keyakinan Choice dan Score merangkum suatu distribusi. Itu bukan bukti bahwa masukannya lengkap atau bahwa tindakan terpilih telah diotorisasi.

Sertakan kasus ketika tidak ada kandidat yang cocok. Sertakan layanan yang tidak tersedia. Sertakan setiap bahasa yang akan Anda dukung. Simpan revisi model dan definisi pertanyaan bersama hasilnya agar perubahan berikutnya dapat dibandingkan secara adil.

Untuk produk integrasi, saya akan memulai dengan relevansi pencarian dan pemetaan kolom. Keduanya memperpendek jalur menuju sinkronisasi yang berjalan. Keduanya memungkinkan Anda memeriksa kesalahan sebelum berkembang menjadi masalah pelanggan.

Pilih satu jawaban salah yang diberikan perangkat lunak Anda hari ini. Buat perangkat lunak itu mengambil langkah berikutnya yang benar secara andal.