Bagaimana Menerapkan LLM Routing dan Guardrails? Contoh Kolaborasi Jev dengan LLM

Pengungkapan kepentingan dan bukti: PandaNpc sedang mengembangkan lapisan keputusan Agent yang menggunakan Jev. Berikut ini masing-masing mengutip dokumentasi resmi TypeSafe, cookbook resmi, serta pemanggilan Jev nyata dan kalibrasi skenario sintetis di repositori kami. Kalibrasi kami menggunakan providerM palsu berbasis skrip, sehingga tidak dapat mewakili traffic pengguna nyata atau performa jalur produksi lengkap.

LLM routing dapat dilakukan seperti ini: pertama, minta Jev menilai jenis permintaan dan seberapa tinggi risikonya, laluode memutuskan apakah akan meneruskannya ke fungsi biasa, LLM khusus, atau tinjauan manusia. Jev juga dapat ditempatkan di antara retrieval dan generation untuk menyaring bukti, atau setelah output LLM untuk memeriksa hasil. Yang dikembalikannya adalah opsi tertutup, skor, dan probabilitas; jawaban terbuka, pembuatan kode, dan penalaran panjang tetap dilakukan oleh LLM. Penjelasan TypeSafe tentang coding agents secara eksplisit menyatakan bahwa Jev tidak dapat langsung menggantikan model chat di balik Claude Code atau Codex.

Artikel ini menggunakan satu permintaan layanan pelanggan, satu pipeline tanya jawab RAG, dan catatan kalibrasi Agent kami sendiri untuk menjelaskan di mana kedua jenis model tersebut sebenarnya bertemu, dan mengapa hasil dengan confidence rendah harus memiliki tujuan yang jelas.

Apa yang Dapat Dinilai Jev, dan Apa yang Tetap Menjadi Tanggung Jawab LLM?

Hingga 23 September 2026, model stabil yang tercantum di Halaman model TypeSafe adalah jev-1.13.0. API menerima sebuah state dan kumpulan questions, lalu melalui POST /v1/systemone mengembalikan answers terstruktur yang sesuai. jev-latest pada hari itu menunjuk ke 1.13.0, tetapi alias dapat berubah seiring versi; sistem yang telah mengalibrasi ambang batas sebaiknya mematok versi dan mencatat ID model aktual dalam respons.

Noul tidak memiliki bidang confidence tersendiri; sebuah probabilitas Noul tidak dapat langsung ditulis sebagai “confidence model”. Score juga tidak boleh dipakai untuk menghitung jumlah uang yang tepat. Jumlah uang, perbandingan tanggal, kuota, dan pemeriksaan izin harus tetap berada dalam program deterministik; pihak resmi telah mencantumkan batasan-batasan Jev 1.13 ini.

Bentuk minimum satu panggilan

Bentuk permintaan di bawah ini sesuai dengan referensi API resmi; contoh pertanyaan adalah konfigurasi ilustratif yang dibuat untuk artikel ini, dan tidak diuji secara online untuk artikel ini:

JSON di bawah ini menggunakan pesan pelanggan dalam bahasa Inggris; dalam bahasa Indonesia, pelanggan akan mengatakan “Pesanan saya terpotong dua kali, mohon bantu proses pengembalian dananya.”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

Sistem aktual juga harus terlebih dahulu memeriksa dengan kode apakah catatan pemotongan termasuk pesanan yang sama dan apakah refund diizinkan. Contoh di atas hanya digunakan untuk menafsirkan maksud pengguna; pengguna meminta refund tidak berarti kelayakan refund telah terbukti, apalagi merupakan otorisasi untuk langsung mengeksekusi refund.

Menggunakan Jev untuk LLM Routing: Tiga Jalur Serah Terima

Contoh intent routing resmi TypeSafe pertama-tama menyerahkan permintaan layanan pelanggan ke Jev untuk menilai maksud dan kompleksitas, lalu kode melakukan percabangan: pengecekan status pesanan melalui fungsi database; pertanyaan produk dan retur/penukaran masing-masing melalui LLM khusus yang dimuat dengan materi berbeda; keluhan kompleks atau hasil confidence rendah masuk ke antrean manusia. Inilah kolaborasi Jev dan LLM yang paling mudah dipahami: yang pertama memberikan penilaian terstruktur, yang terakhir hanya muncul saat perlu menghasilkan penjelasan atau dialog.

Saat implementasi, Anda dapat merancangnya dengan urutan berikut, alih-alih membiarkan model bebas menentukan semua tindakan:

1. Definisikan jalur terlebih dahulu: daftarkan dengan jelas permintaan yang dapat ditangani fungsi biasa, masing-masing LLM khusus, dan tinjauan manusia, serta sediakan other atau opsi fallback sejenis untuk Choice.
2. Masukkan fakta ke dalam state: ucapan asli pengguna, status akun, dan catatan pesanan menjadi bidang terpisah; jangan jadikan teks web dari sumber tak jelas sebagai instruksi sistem.
3. Ajukan pertanyaan sempit satu per satu: gunakan Choice untuk maksud, Score untuk risiko atau tingkat urgensi, dan Noul untuk satu fakta tunggal yang perlu dikonfirmasi.ihak resmi menyarankan beberapa pertanyaan independen state yang sama dapat dievaluasi secara paralel dalam satuintaan.
4. Biarkan kode melakukan routing akhir: periksa izin dan aturan keras terlebih dahulu, lalu lihat probabilit Jev dan ambang batas yang telah dikalibrasi untuk bisnis ini; permintaan dengan confidence rendah atau kurang bukt dialihkan ke manusia atau pertanyaan lanjutan5. Catat hasil dan tinjau ulang: simpan versi model, versi pertanyaan, probabilitas, tujuan akhir, dan hasil koreksi manusia, agar dapat menilai apakah ambang batas sudah tepat.

Sumber gambar: TypeSafe AI《Introducing System One Models & Jev》, 2026-09-15. Empat workflow dibuat sendiri oleh TypeSafe, metrik diagregasi dengan bobot sama per workflow; metode evaluasi lihat TypeSafe workflow evals.

Gambar resmi ini dapat membantu memahami mengapa ia menekankan “memasukkan banyak penilaian sempit ke dalam workflow program”. Sumbu vertikal pada gambar memakai penamaan “accuracy” dari vendor, tetapi jawaban referensinya berasal dari konsensus probabilitas prediksi dua model besar, bukan jawaban benar tunggal yang telah diverifikasi manusia; biaya dan metrik juga bergantung pada empat workflow ini dan metode evaluasi vendor, dan tidak dapat dikonversi menjadi “berapa banyak yang bisa dihemat dalam skenario apa pun”.

Retrieval-Augmented Generation: Jev Menyaring Bukti Sebelum LLM Menjawab

Cookbook RAG passage TypeSafe memberikan contoh multi-model yang lebih konkret: embedding OpenAI terlebih dahulu mengambil paragraf, Jev mengajukan empat Noul untuk setiap “pertanyaan + paragraf”—apakah relevan, apakah berisi bukti yang dapat digunakan untuk menjawab, apakah membantah premis dalam pertanyaan, apakah mencoba memberi instruksi kepada model penjawab. Kode memproses empat probabilitas tersebut secara berurutan, memutuskan untuk menempatkan paragraf itu ke area bukti, area bukti konflik, atau membuangnya; terakhir Claude Sonnet 5 menulis jawaban.

Langkah ini menyelesaikan masalah umum: paragraf dengan kemiripan vektor tinggi belum tentu dapat digunakan. Ia mungkin hanya memakai kata yang mirip, atau berupa postingan forum yang menyelipkan prompt injection “abaikan teks sebelumnya”. Contoh cookbook menempatkan pemeriksaan injeksi di urutan paling depan aturan routing, sekaligus mengingatkan bahwa ambang batas tersebut adalah titik awal yang dipilih untuk korpus itu, bukan nilai default untuk semua aplikasi RAG. Angka demonstranya berasal dari jev-1.12 tanggal 2026-08-27, dan tidak dapat dianggap sebagai hasil evaluasi baru untuk jev-1.13.0 ini.

Setelah generasi, masih dapat dilakukan satu lapisan pemeriksaan. Cookbook pemeriksaan kutipan TypeSafe pertama-tama memakai program untuk menemukan teks asli kutipan, lalu memakai Jev untuk menilai apakah paragraf tersebut mendukung, membantah, atau tidak menyebut klaim yang dihasilkan. Ia dapat memilih kutipan yang layak ditinjau ulang; penilaian model itu sendiri masih bisa salah, jadi “lolos pemeriksaan” tidak boleh ditulis sebagai jaminan fakta.

Kalibrasi Agent Kami: Di Mana Eskalasi Confidence Rendah Akan Tersendat?

Di repositori PandaNpc, klien Jev, bank pertanyaan, dan orkestrator menggunakan Jev untuk pengenalan maksud Agent, penilaian kandidat modifikasi, pemeriksaan kondisi penyelesaian, dan keputusan pengiriman. Klien juga melakukan retry terbatas untuk timeout, 429, dan 5xx, serta membatasi anggaran permintaan dan hasil kedaluwarsa; izin eksekusi dipegang oleh orkestrator dan lapisan alat terkendali, bukan diberikan langsung oleh satu penilaian Jev.

Pada 202-09-22, kami menggunakan jev-1.13.0 untuk menjalankan satu kali shadow dan satu kali enforce pada masing-masing 19 turn sintetis, total 38 kali eksekusi, dan mencatat 165 keputusan Jev yang nyata. Laporan kalibrasi internal ini serta respons mesin nyata yang disimpan menggunakan provider LLM palsu berbasis skrip, sehingga data ini hanya menjelaskan performa keputusan dalam skenario terkendali. Data tersebut tidak dapat membuktikan tingkat keberhasilan keseluruhan, persentase penghematan, atau latensi end-to-end pada permintaan pengguna nyata.

Temuan yang paling berharga bukanlah kecepatan rata-rata, melainkan ambang batas yang “terlihat aman” justru menyebabkan kemacetan: dari 19 turn dalam mode enforce, 13 turn di Q2 “apakah informasi cukup untuk mulai memodifikasi” naik eskalasi karena probabilitas Noul jatuh ke rentang tidak pasti 0.15–0.85 yang telah ditetapkan; LLM Worker tidak mendapat kesempatan menjalankan langkah selanjutnya. Catatan kalibrasi menunjukkan bahwa dari 34 keputusan Q2 yang dilabeli informasi cukup, banyak probabilitasnya berada di rentang tengah. Laporan menyarankan agar Q2 yang kompleks dipecah menjadi penilaian yang lebih atomik, atau aturan eskalasi disesuaikan; ini adalah saran, bukan ambang batas yang sudah diterapkan.

Bank pertanyaan kami menilai pintu masuk sebagai answer_only, inspect, modify, atau out_of_scope; pada jalur penulisan, kandidat modifikasi yang diajukan Worker terlebih dahulu diurutkan oleh Score, lalu konten akhir dan ringkasan perubahan melewati penerimaan dan keputusan pengiriman. Ini hanyalah titik keputusan: apakah objek benar-benar dapat dibaca dan ditulis tetap ditentukan oleh eksekutor terkendali yang memberikan izin berdasarkan tahap. Jev tidak berwenang melonggarkan whitelist alat sendiri, dan tidak dapat melewati pemeriksaan konsistensi sebelum pengiriman.

Data kalibrasi mengungkap trade-off lain. Dalam mode shadow, Jev memberikan jawaban dan distribusi lengkap, tetapi tidak mengubah jalur eksekusi asli Worker; dalam mode enforce, jawaban memengaruhi apakah akan melanjutkan, naik eskalasi, atau membuang. Menganggap akurasi shadow langsung sebagai tingkat penyelesaian enforce akan salah membaca sistem: eskalasi Q2 akan menghentikan tugas lebih awal, sehingga penilaian kandidat, penerimaan, dan pertanyaan pengiriman berikutnya sama sekali tidak mendapat kesempatan muncul. Karena itu laporan ini membaca distribusi tiap pertanyaan, arah eskalasi, dan status akhir secara terpisah.

Ada perbandingan konkret dalam modifikasi kandidat: pada turn yang sama, kandidat yang memodifikasi target secara presisi mendapat skor 2.94, sedangkan kandidat yang menimpa seluruh file mendapat 0.38; kandidat dengan skor tinggi dipilih. Contoh ini hanya menunjukkan bahwa dalam situasi sintetis tersebut, pertanyaan skor membedakan dua opsi. Sebaliknya, kandidat dengan bukti terpotong mendapat 2.27; nilai yang terlihat “lumayan” tidak boleh membuat kita mengabaikan confidence rendah dan tanda pemotongannya. Kode kami menandai bukti yang tidak lengkap secara terpisah, agar model tidak membuat penilaian penulisan yang deterministik hanya berdasarkan prefiks yang dipertahankan.

Kami juga memisahkan “kandidat mana yang dipilih” dan “mengizinkannya menulis” menjadi dua langkah berbeda. Setelah kandidat dinilai oleh Jev, eksekutor terkendali hanya membuka alat tulis pada tahap ACT/modify; tiket sekali pakai yang diterbitkan terikat pada ID pemanggilan alat, nomor revisi saat ini, hash objek target, dan ringkasan parameter. Teks kandidat meskipun memancing model untuk “mengabaikan batasan”, tetap tidak akan mendapatkan izin alat untuk melewati pemeriksaan ini. Ini pelajaran dari integrasi di tingkat kode kami: penilaian probabilitas menentukan jalur mana yang layak ditempuh, sedangkan izin efek samping ditentukan oleh kondisi program yang dapat ditinjau ulang.

Jalur kegagalan juga harus dirancang. Klien hanya melakukan retry terbatas pada timeout, error jaringan, 429, atau 5xx; jawaban yang dibatalkan atau melewati tenggat turn langsung dibuang. Jika Jev tidak tersedia dalam mode enforce, proses tidak boleh dilanjutkan tanpa otorisasi degradasi; jika diizinkan menjalankan llm_only, eksekutor mengunci ke mode hanya-baca. Jika cabang sudah termodifikasi baru kehilangan Jev, orkestrator menandai seluruh putaran sebagai gagal, bukan membiarkan LLM berikutnya menambal penulisan tanpa lapisan keputusan. Jalur-jalur ini memiliki biaya bagi pengalaman pengguna, tetapi membuat “model sementara tidak tersedia” tidak diam-diam berubah menjadi “izin tulis tetap sama”.

Laporan kalibrasi juga membedakan “eskalasi confidence rendah” dan “penolakan eksekusi”. Misalnya, sebuah discard yang benar tetapi confidence-nya tidak mencapai ambang seragam 0.85 akan dicatat sebagai memerlukan input pengguna; ini tidak sama dengan pelolosan yang salah. Berdasarkan hal itu, laporan menyarankan agar ambang pengiriman dan pembuangan dipisahkan, tetapi saat ini masih berupa saran. Saat menulis workflow, Anda harus membedakan tiga hasil—pelolosan yang salah, penolakan yang salah, dan menunggu tinjauan—jika tidak, kumpulan data yang sama akan menghasilkan kesimpulan ambang batas yang salah.

Kasus ini mengajarkan bahwa kerja sama Jev dan LLM tidak bisa hanya digambarkan sebagai “Jev menilai dulu, LLM baru bekerja”. Setiap penilaian harus ditanyakan: seberapa lebar rentang tidak pastinya? Apakah akan membuat pemroses berikutnya tidak pernah menerima tugas? Jika bukti masukan terpotong, dapatkah dilakukan eskalasi eksplisit alih-alih menebak? Dalam implementasi kami, pembangun state mencatat evidence_truncated, dan membuat pemanggil memperlakukan jalur yang kekurangan bukti sebagai tidak pasti; perhitungan deterministik seperti penghitungan dan pengurutan diselesaikan lebih dulu di kode, bukan diserahkan kepada Jev untuk menebak. Batasan yang diketahui dari Jev 1.13 resmi juga menyarankan agar penghitungan dan aritmetika tetap berada di kode.

Di Mana LLM Guardrails Harus Ditempatkan?

Cookbook LLM guardrails TypeSafe menempatkan Jev di kedua sisi input dan output LLM. Ia memakai sekumpulan Noul untuk mengidentifikasi berbagai risiko, memakai Score untuk mengukur tingkat keparahan, lalu kode memutuskan berdasarkan kebijakan apakah akan meloloskan, meninjau manusia, memblokir, atau mengalihkan ke dukungan. Output juga harus diperiksa, karena input biasa tetap dapat menghasilkan keluaran generasi yang tidak pantas.

Batas guardrails semacam ini juga jelas: Jev dapat memeriksa konten berdasarkan pertanyaan yang telah ditulis sebelumnya, tetapi bukan bukti keamanan yang serba bisa. Dokumentasi batasan resmi secara eksplisit menyebut bahwa konten berbahaya dapat memengaruhi penilaian, dan mengharuskan penulisan criteria yang jelas serta pengujian batas. Dalam sampel sintetis kami, pernah dilakukan 16 probe injeksi terhadap parameter kandidat, dan tercatat 0 pembalikan peringkat; sampelnya terlalu kecil, sehingga tidak dapat disimpulkan bahwa “ketahanan terhadap prompt injection sudah terpecahkan”. Yang benar-benar menentukan apa yang dapat dilakukan alat tetap daftar izin di kode, gerbang tahap, dan pemeriksaan sebelum pengiriman.

Kapan Cocok Digunakan, dan Kapan Jangan Digunakan?

Yang cocok untuk Jev adalah: himpunan kandidat diketahui, masalah dapat dipecah menjadi beberapa penilaian singkat, dan perangkat lunak membutuhkan probabilitas untuk memutuskan pemrosesan otomatis atau eskalasi ke manusia. Misalnya routing layanan pelanggan, penyaringan paragraf RAG, penilaian aksi kandidat Agent, dan pemeriksaan kutipan dalam hasil generasi. Jika tugas mengharuskan menulis balasan, mengubah sepotong kode, atau menjelaskan proses penalaran kompleks, LLM yang mengambil alih. Jika tugasnya menghitung uang secara tepat, membandingkan tanggal, atau memeriksa kontrol akses, program harus menghitungnya langsung. Halaman model juga menyatakan bahwa Jev hanya menerima teks, dan bahasa Inggris adalah bahasa pelatihan dengan performa terbaik saat ini; skenario bahasa Mandarin perlu dievaluasi dengan data sendiri, dan tidak boleh meniru ambang batas cookbook bahasa Inggris.

Jika ingin mengamati bagaimana Agent nyata menangani izin dan pemanggilan alat, lihat PandaNpc Agent; tentang batas dan skenario penggunaan coding Agent, Anda juga dapat merujuk ke Perbandingan Claude Code dan Codex.

Pembaca dapat memulai dengan set validasi yang sangat kecil: siapkan empat jenis sampel—“jelas dapat diproses otomatis”, “jelas harus ditolak”, “semantik ambigu”, dan “mengandung instruksi berbahaya”; tentukan anotasi manusia terlebih dahulu, lalu catat probabilitas setiap pertanyaan Jev dan hasil routing. Kriteria keberhasilan bukanlah setiap item lolos otomatis, melainkan tingkat kesalahan jalur pemrosesan otomatis dan jumlah eskalasi manusia berada dalam rentang yang dapat Anda terima. Jika banyak sampel ambigu tersendat pada pertanyaan yang sama, periksa dulu apakah pertanyaan itu mencampur beberapa penilaian, apakah state terlalu panjang, atau apakah ambang batas telah dikalibrasi dengan data lokal.

FAQ

Apakah Jev dapat menggantikan Claude Code, Codex, atau model chat? Tidak. TypeSafe memposisikannya sebagai model keputusan terstruktur di dalam perangkat lunak; chat, penulisan, dan pembuatan kode tetap membutuhkan LLM.

Jika tipe kembaliannya tetap, apakah pasti tidak akan membuat kesalahan? Tidak. Tipe tetap mengurangi masalah parsing dan output di luar batas, tetapi klasifikasi, penilaian, dan penilaian fakta tetap dapat salah. Jalur dengan confidence rendah dan risiko tinggi harus tetap memiliki tinjauan manusia.

Berapa banyak pertanyaan yang dapat diajukan dalam satu permintaan? Anda dapat menempatkan beberapa Choice, Score, dan Noul independen yang berbagi state yang sama dalam satu permintaan. Setiap pertanyaan dievaluasi sendiri-sendiri; penilaian kompleks tetap harus dipecah, lalu digabungkan oleh kode.

Apakah bahasa Mandarin dapat digunakan? Pihak resmi menyatakan dukungan untuk bahasa alami termasuk aksara Tionghoa, Jepang, dan Korea, tetapi akurasi bahasa Inggris saat ini paling baik. Beban kerja bahasa Mandarin perlu divalidasi dan dikalibrasi secara terpisah.