Forge - alat yang mendorong model 8B dari 53% ke 99% dalam tugas agen dengan guardrail

• Forge adalah lapisan keandalan untuk pemanggilan alat pada LLM self-hosted, dengan fokus meningkatkan stabilitas model lokal kecil dalam alur kerja agen multi-langkah
• Fitur intinya terdiri dari rescue parsing untuk memulihkan pemanggilan alat yang salah, mendorong percobaan ulang, memaksa langkah wajib, anggaran token yang sadar VRAM, dan kompresi konteks bertingkat
• Saat ini, konfigurasi self-hosted terbaik Ministral-3 8B Instruct Q8 di atas llama-server mencatat 86,5% pada 26 skenario evaluasi, dan 76% pada tier tersulit
• Ada tiga cara penggunaan: menyerahkan seluruh loop agen ke WorkflowRunner, memasukkan Guardrails middleware ke loop orkestrasi yang sudah ada, atau menerapkannya secara transparan lewat server proxy yang kompatibel dengan OpenAI
• WorkflowRunner mengelola prompt sistem, eksekusi alat, kompresi konteks, dan guardrail, sementara SlotWorker menambahkan antrean prioritas dan fitur preemption otomatis ke slot inferensi GPU bersama
• Server proxy dijalankan dengan python -m forge.proxy, dan berada di antara klien kompatibel OpenAI seperti opencode, Continue, dan aider dengan server model lokal untuk menerapkan guardrail
• Proxy secara otomatis menyuntikkan alat sintetis respond ke permintaan yang memiliki alat, sehingga model memanggil respond(message="...") alih-alih mengeluarkan teks biasa; pada respons, ini dihapus sehingga bagi klien tetap terlihat seperti respons teks normal
• Backend yang didukung adalah Ollama, llama-server (llama.cpp), Llamafile, dan Anthropic; llama-server menawarkan performa dan kontrol terbaik, Ollama memudahkan pengaturan, Llamafile memungkinkan eksekusi biner tunggal, dan Anthropic berperan sebagai baseline frontier serta alur kerja hibrida
• Instalasi dapat dilakukan dengan pip install forge-guardrails, dan klien Anthropic dapat ditambahkan dengan pip install "forge-guardrails[anthropic]"; persyaratannya adalah Python 3.12+ dan backend LLM yang sedang berjalan
• Harness evaluasi mengukur keandalan pemanggilan alat multi-langkah pada kombinasi model dan backend lewat 26 skenario, yang dibagi menjadi tier berbasis OG-18 dan 8 tier advanced_reasoning
• Konfigurasi pengujian mencakup 865 unit test deterministik yang tidak memerlukan backend LLM dan harness evaluasi terhadap backend nyata
• Kerangka guardrail Forge dan studi ablation telah dipublikasikan sebagai Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling, dengan lisensi MIT

[GN⁺]

Komentar Hacker News

• Saya suka pekerjaan di bidang ini dan merasa terbantu, tetapi saya menghindari LLM berbasis cloud dan terutama memakai model lokal 4B~30A3B parameter
  Jadi meskipun saya kurang punya intuisi soal performa atau akurasi LLM terbaru, saya rasa saya cukup paham level yang bisa diharapkan dan bottleneck pada model lokal
  Saya hanya membaca sekilas tulisan ini dan membaca abstraknya, tetapi meskipun ada pernyataan bahwa penyesuaian sederhana bisa membuatnya 10 kali lebih cepat atau lambat, metrik dan datanya tampak hampir sepenuhnya berfokus pada akurasi. Kecepatan juga perlu dibahas
  Terutama pada workflow bergaya agen dan model lokal, akurasi pemanggilan fungsi/alat secara pribadi bukan lagi masalah besar bagi saya sejak sekitar masa QwenCoder3 dalam 6~12 bulan terakhir; yang utama adalah pengelolaan konteks dan dampak terhadap waktu. Jika agen sering mengubah prompt, optimasi waktu seperti prompt caching jadi rusak
  Di sini tampaknya ditambahkan lapisan dan wrapper seperti guardrail dan retry, dan khususnya pada model lokal untuk penggunaan agen, ini bisa menjadi terlalu lambat sampai tidak layak dipakai
  Maaf kalau ini sebenarnya sudah dibahas langsung, tetapi pembahasan soal dampak terhadap waktu terlalu sedikit sehingga terasa seperti menyembunyikan atau melebih-lebihkan besar peningkatan nyatanya. Saya ingin mendengar pengalaman soal kecepatannya. Sedikit mengkhawatirkan juga bahwa orang lain tidak mengangkat ini; saya jadi bertanya-tanya apakah saya yang salah melakukan sesuatu, atau memang kebanyakan orang sebenarnya tidak memakai model lokal

• Saya sudah lama bilang bahwa dengan harness yang benar, model lokal kecil pun bisa bekerja sangat mengejutkan dengan baik
  Jika sistemnya bisa mencoba segala hal, selama Anda bisa mencegahnya mengeluarkan hasil yang salah di tengah jalan, pada akhirnya ia bisa menemukan jawaban yang benar

  • Masalahnya adalah kualitasnya jadi mirip seperti memberi seorang junior waktu tak terbatas lalu menyuruhnya terus mencoba berbagai cara sampai mencapai tujuan
    Jika tugasnya cukup rumit, model terbaru pun punya masalah ini, dan pada model kecil efeknya makin besar
  • Saya suka framing itu. Saat mengerjakan ini, model kecil terasa cukup mengesankan
    Penalarannya juga lumayan baik dan dalam banyak kasus sudah cukup. Kadang hanya perlu sedikit didorong kembali ke jalurnya, lalu mereka bisa menyelesaikannya sendiri
  • Kalau saya memahaminya dengan benar, alasan model bisa berhasil adalah karena ia tahu kapan dirinya salah

• Senang melihat seseorang membuat jauh lebih baik sesuatu yang ingin saya luangkan waktu untuk buat sendiri. Satu pertanyaan saya adalah apakah, misalnya, ada ruang untuk paralelisasi di dalam loop retry
  Model lokal umumnya bisa menangani sejumlah terbatas permintaan bersamaan, kira-kira dua digit, dengan cukup baik bahkan di perangkat keras kelas konsumen, dan ini bisa menaikkan token/detik efektif lebih dari 10 kali
  Saya sudah lama memikirkan workflow yang memanfaatkan hal seperti ini, dan “perbaiki error ini” kelihatannya bisa jadi tempat penerapannya meskipun tidak sempurna. Penasaran bagaimana pendapat Anda

• Saya punya beberapa ide di area ini dan sedang memasukkannya ke harness saya. Harness saya cukup terspesialisasi jadi saya tidak yakin seberapa bisa digeneralisasi
  Saya memecah masalah menjadi eksekusi yang direncanakan, lalu memberi agen eksekusi rencana awal yang mencakup tujuan eksplisit seperti alat mana yang harus dipanggil dan kriteria keberhasilan untuk eksekusi tersebut. Harness kemudian mengeksekusi rencana itu secara berurutan
  Pada setiap langkah yang melibatkan pemanggilan alat, saya memecah pemanggilan alat itu menjadi bagian-bagian. Harness menanyakan ke agen nilai parameter yang valid untuk argumen alat saat ini, dan definisi alat memiliki validator untuk setiap argumen. Jika validasi gagal, harness memundurkan percakapan dan menyuntikkan alasan kegagalan ke percobaan berikutnya
  Jika ada respons yang valid untuk suatu argumen, ia lanjut ke argumen berikutnya, dan setelah semua argumen terisi, alat dipanggil. Lalu ekspektasi awal agen, nilai aktual, dan error yang muncul dikirimkan bersama, dan ditanyakan apakah agen puas dengan hasilnya
  Jika tidak puas, agen menjelaskan alasannya, lalu harness memundurkan percakapan, memasukkan alasan retry, dan memulai lagi proses pemanggilan alat dari awal
  Agen bisa meminta perencanaan ulang jika menemukan cacat pada rencana awal, dan harness juga akan mencoba perencanaan ulang jika kegagalan beruntun terlalu banyak
  Pendekatan ini cukup efektif untuk mengurangi kegagalan pemanggilan alat. Salah satu kelebihannya adalah subagen menerima riwayat percakapan yang sempurna tanpa kesalahan. Hanya saja saya belum membenchmark apakah tingkat penyelesaian tugas nyata benar-benar lebih baik

  • Saya bereksperimen dengan filosofi serupa pada harness coding bergaya agen berbasis model kecil, dan saya membangunnya di atas forge
    Terkait pemunduran percakapan, saya menerapkan pelipatan pemanggilan alat yang serupa pada agen utama, yaitu agen yang berbicara dengan pengguna. Setelah tugas selesai, riwayat pemanggilan alat dilipat agar konteks tetap bersih; ini lebih soal kebersihan daripada ukuran
    Bagian di mana harness menginterogasi model agak berbeda, dan saya belum mencoba pendekatan itu. Forge mengandalkan koreksi diri model agar terhindar dari mode error khusus, tetapi jika proses tanya jawab itu bisa diabstraksikan dan diotomatisasi berdasarkan hal seperti skema, rasanya itu memungkinkan
    Secara keseluruhan, aspek riwayat percakapan yang bersih itu bagus, tetapi pada alat dengan banyak argumen, tampaknya jumlah bolak-balik bisa jauh lebih banyak dibanding “biarkan gagal dulu lalu beri satu dorongan”. Meski begitu, ini ide yang menarik untuk skenario atau tugas yang lebih sulit
  • Saya memakai Strix Halo dan karena ia lambat pada konteks panjang, saya juga memikirkan pendekatan yang sama. Dengan cara ini, tampaknya konteks di bawah 10 ribu token bisa dipertahankan
    Jika model kecil bisa mencapai lebih dari 50k token/detik, itu akan cukup besar
    Hanya saja sekarang saya sedang sibuk dengan pekerjaan kantor dan proyek lain, jadi baru sempat menguji beberapa lusin prompt untuk melihat apakah ini memungkinkan
  • Karena penasaran saya sedang membangunnya sendiri dengan gemma4, dan saya terkejut karena hasilnya melaju lebih jauh dari dugaan

• Sangat bagus. Saat ini saya belum bisa memakai inferensi lokal karena biaya, tetapi saat memakai model kecil lewat OpenRouter saya memang khawatir soal pemanggilan alat
  Saya sedang membuat Dokimasia (do-kee-ma-see-ah), framework pengujian argumen yang berorientasi pytest, dan ingin mendengar pendapat: https://github.com/deevus/dokimasia
  Pengujian argumen mungkin bukan sesuatu yang dibutuhkan Forge, tetapi karena Anda sedang membangun alat AI secara mendalam, saya pikir Anda mungkin punya pemikiran soal ini

  • Ide yang menarik. Pada dasarnya ini tampak seperti memformalkan lapisan abstraksi untuk menguji berbagai jenis integrasi dalam ekosistem AI, misalnya MCP atau skills
    Ini tampaknya satu tingkat di atas Forge, dan lebih dekat ke pengujian workflow nyata serta titik integrasi yang muncul di dalamnya, misalnya alat mana yang menyediakan akses MCP
    Sepertinya tidak akan jadi masalah besar juga untuk menumpuk keduanya bersama
    Yang membuat saya penasaran adalah bagaimana Anda menangani nondeterminisme model-model ini. Kadang mereka melakukan pemanggilan alat dengan benar, kadang mengeluarkan JSON yang salah. Apakah test suite mencoba beberapa kali?

• Ambiguitas dalam pemanggilan alat juga saya alami pada model frontier berskala besar. Saya memakai Claude Code, Codex, dan Gemini CLI setiap hari secara paralel untuk development, dan mode kegagalan yang paling umum adalah saat grep/find berakhir dengan exit code 1, yaitu tidak ada kecocokan
  Model membacanya bukan sebagai “pencarian dijalankan dan tidak menemukan apa-apa”, melainkan sebagai “alat gagal”, lalu menyerah atau hanya mengubah sedikit sintaks dan mencoba lagi alih-alih memperluas cakupan pencarian
  Lapisan retry-dengan-nudge ini hampir 1:1 dengan hal yang saya lakukan manual berkali-kali dalam sejam. Semacam, “Bukan, alatnya tidak gagal, memang tidak ada pola itu di file tersebut. Coba X”
  Mengenkode hal seperti ini di level framework tampaknya arah yang tepat
  Saya penasaran apakah Anda juga melihat guardrail semacam ini memperkecil jarak dengan model frontier kecil pada tugas yang panjang. Intuisi saya mengatakan bahwa pada Sonnet, selisih 87→99 mungkin tidak akan bertahan jika melampaui kira-kira 50 langkah. Setelah itu, context drift akan lebih dominan daripada semantik retry

  • Setidaknya pada model frontier besar, memang jelas lebih unggul di titik itu. Hanya saja saya belum sempat memformalkan hasil tersebut karena keterbatasan waktu
    Sebagai petunjuk yang relevan, forge secara teknis lebih peduli pada eksekusi pemanggilan alat daripada kualitas model itu sendiri. Jawaban sebenarnya seperti ini
    Pada model kecil kelas 14B, faktor pembatasnya adalah perhatian efektif. Bahkan jika masih cukup muat dalam ukuran jendela konteks saat pelatihan, setelah titik tertentu mulai terlihat penurunan performa. Saya tidak punya angka pasti, tetapi model seperti Opus bisa bertahan jauh lebih lama di titik itu
    Saya juga sudah membuat fitur pelipatan riwayat pesan pemanggilan alat yang mungkin suatu hari akan saya pakai langsung di forge. Intinya, riwayat pesan dirapikan secara cerdas agar model tidak terlalu mudah kehilangan jejak
    Meski begitu, kumpulan evaluasi coding pada harness coding bergaya agen memang mencakup tugas refactoring dan penambahan fitur, semuanya dikerjakan di repository sandbox nyata. Model kecil pun bisa didorong sampai 50~60 kali pemanggilan alat dan tetap menyelesaikan tugas seperti itu. Hanya saja saya rasa saya tidak akan memberi mereka lebih dari satu tugas seperti itu dalam sesi yang sama

• Sedikit di luar topik, tetapi kalau Anda berada di Texas Instruments, saya penasaran apakah Anda bisa mencari tahu bagaimana status hak kekayaan intelektual untuk mesin Lisp TI Explorer
  Saya tahu siapa pemilik hak kekayaan intelektual Genera, tetapi saya tidak berhasil menemukan informasi untuk Lisp OS milik TI

  • Siapa yang memegang hak kekayaan intelektual Genera?

• Bagi orang-orang yang memikirkan stack “keamanan agen” secara lebih luas, arah ini terasa saling melengkapi dengan hal-hal seperti kontext-cli milik Kontext (github.com/kontext-dev/kontext-cli) atau OneCLI (github.com/onecli/onecli)

• Ada bagian yang mengatakan “bobot Mistral-Nemo 12B yang sama menghasilkan akurasi 7% pada native function calling di llama-server, dan 83% pada mode prompt Llamafile”
  Saya kira Llamafile itu cuma model dan llama.cpp yang dibundel menjadi satu biner, jadi apakah perbedaan ini berasal dari Llamafile yang menyuntikkan system prompt bawaan sementara endpoint llama-server mentah dipanggil tanpa harness?
  Ini tampak seperti membandingkan apel dan pai apel, dan bahan di tengahnya hilang

  • Saya juga terkejut. Tulisan itu memberi contoh yang ekstrem tetapi nyata. Dalam kasus ini, kemungkinan besar template native function calling yang tidak bekerja
    Namun itu tidak menjelaskan selisih sekitar +4 poin persentase antara prompt Lamaserver dan llamafile, atau selisih sekitar +30 poin persentase pada Ollama yang berada hampir di tengah antara native llamaserver dan llamafile
    Backend serving memengaruhi hampir semua keluarga model, dan bagian ini nyaris belum pernah saya lihat benar-benar dibahas

• Ini benar-benar arah yang sangat bagus. Bahkan pada model bonsai 1-bit hasilnya sangat tidak masuk akal bagus, dan juga cocok dengan lmstudio
  Sekarang jadi sepenuhnya realistis untuk memasang 7900XTX ke perangkat cadangan, menaruhnya di ruang bawah tanah, lalu memberinya tujuan yang konyol dan melupakannya