Fable 5 vs. GPT-5.6 Sol: Apakah /goal membantu pada masalah NP-hard?

 (charlesazam.com)
1 poin oleh GN⁺ 23 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Dalam hasil menyelesaikan masalah optimasi jaringan serat optik yang belum dipublikasikan selama masing-masing 30 menit, Fable 5 mencatat skor tertinggi dan performa paling stabil, tetapi /goal tidak menghasilkan peningkatan yang konsisten
  • /goal bukan sekadar fitur yang membuat pekerjaan berlangsung lebih lama; ia mengubah control loop dan jalur eksplorasi, sehingga dapat mempertahankan strategi yang baik maupun strategi yang keliru
  • /goal menang 4 kali dari 6 perbandingan antara Fable 5 dan GPT-5.6 Sol, tetapi penurunan performa besar yang jarang terjadi membuat skor rata-rata memburuk masing-masing 759 poin dan 868 poin
  • Mode biasa Fable 5 adalah yang paling stabil dengan rata-rata 32.386 poin dan rentang 319 poin, sementara mode /goal mencetak rekor terbaik keseluruhan, yaitu 31.934 poin
  • Pada optimasi yang sulit, kualitas strategi yang diulang lebih penting daripada apakah iterasi dilakukan, dan tingkat kemenangan per kasus serta performa rata-rata bisa mengarah pada kesimpulan yang berlawanan

Masalah optimasi jaringan serat optik KIRO

  • KIRO adalah masalah riset operasi yang diajukan dalam hackathon untuk mahasiswa teknik pada 2018; tujuannya meminimalkan total panjang kabel menggunakan matriks jarak berarah untuk Grenoble, Nice, dan Paris
  • Jaringannya dibangun dari loop redundan yang dimulai dari hub distribusi dan cabang-cabang pendek yang memanjang dari tower di atas loop
    • Semua tower harus muncul tepat satu kali
    • Berbagai batasan struktural harus dipenuhi
    • Biaya segmen kabel dapat berbeda jika arahnya dibalik
    • Semakin rendah skor, semakin baik solusinya
  • Baseline manusia adalah solver C++ yang pernah ditulis selama satu minggu untuk menyelesaikan masalah ini

  • Skala ruang pencarian

    • Karena jumlah dan ukuran loop, serta titik acuan dan urutan cabang berbeda-beda, sulit menghitung seluruh ruang pencarian dengan satu rumus tertutup
    • Bahkan jika hanya menghitung kasus penetapan 532 terminal di Paris ke 11 hub distribusi tanpa urutan dan tanpa cabang, ada 11^532 kemungkinan
    • Bahkan jika hanya menghitung solusi valid terbatas yang menggunakan 19 loop berisi 28 terminal dan tanpa cabang, ruang pencariannya mencapai sekitar 10^1223
    • Karena 19 × 28 = 532, semua terminal tercakup
    • Setiap loop tidak melampaui batas 30 terminal
    • Rumus perhitungannya adalah (532! / 19!) × 11^19 ≈ 10^1223

Model dan kondisi eksekusi

  • Perbandingan mencakup keluarga Claude, yaitu Fable 5·Opus 4.8·Sonnet 5, dan keluarga GPT, yaitu GPT-5.6 Sol·Terra·Luna
  • Setiap model dijalankan dalam mode biasa dan mode native /goal
    • Waktu optimasi adalah 30 menit
    • Batas waktu agen eksternal adalah 1.900 detik
    • Pengaturan reasoning memakai nilai maksimum yang tersedia pada masing-masing model
    • Lingkungan eksekusi adalah Harbor 0.1.43, Docker, dan autentikasi berlangganan
  • Pertama, semua model dijalankan masing-masing sekali dalam mode biasa dan mode /goal selama 30 menit tanpa hint
  • Fable 5 dan GPT-5.6 Sol, yang menjadi target perbandingan utama, diulang hingga masing-masing memiliki 3 pasang eksekusi berpasangan
  • Seluruh kode, prompt, tabel hasil, kriteria pengecualian, dan jejak eksekusi tersedia di CLIArena, dan eksperimen ini merupakan lanjutan dari artikel benchmark sebelumnya

Hasil Fable 5 dan GPT-5.6 Sol

  • Jika nilai skor /goal dikurangi skor mode biasa bernilai negatif, berarti /goal menghasilkan hasil yang lebih baik
  • Tiga hasil eksekusi Fable 5 adalah sebagai berikut
    • Putaran 1: mode biasa 32.197 poin, /goal 31.934 poin, membaik 263 poin
    • Putaran 2: mode biasa 32.516 poin, /goal 32.324 poin, membaik 192 poin
    • Putaran 3: mode biasa 32.446 poin, /goal 35.178 poin, memburuk 2.732 poin
  • Tiga hasil eksekusi GPT-5.6 Sol adalah sebagai berikut
    • Putaran 1: mode biasa 33.581 poin, /goal 39.371 poin, memburuk 5.790 poin
    • Putaran 2: mode biasa 35.539 poin, /goal 32.703 poin, membaik 2.836 poin
    • Putaran 3: mode biasa 33.663 poin, /goal 33.313 poin, membaik 350 poin

  • Mengapa tingkat kemenangan dan rata-rata berbeda arah

    • /goal menang 4 dari 6 kali, tetapi pada kedua model, peningkatan kecil sering terjadi sementara penurunan performa besar sesekali muncul
    • Fable 5 memburuk 759 poin, dari rata-rata mode biasa 32.386 poin menjadi rata-rata /goal 33.145 poin
    • Berdasarkan median, terjadi peningkatan 192 poin
    • GPT-5.6 Sol memburuk 868 poin, dari rata-rata mode biasa 34.261 poin menjadi rata-rata /goal 35.129 poin
    • Berdasarkan median, terjadi peningkatan 350 poin
    • Rata-rata mode biasa Fable 5 lebih baik 1.875 poin daripada Sol, dan rata-rata /goal juga unggul 1.984 poin
    • Perbedaan juga terlihat pada stabilitas
      • Tiga hasil mode biasa Fable 5 tetap berada dalam rentang 319 poin
      • Mode biasa Sol tersebar dalam rentang 1.958 poin
    • Fable 5 /goal mencatat skor terbaik keseluruhan, yaitu 31.934 poin
    • Konfigurasi paling aman adalah mode biasa Fable 5

/goal yang sama, implementasi berbeda

  • Model evaluasi terpisah di Claude Code

    • /goal di Claude Code bekerja sebagai Stop hook dalam cakupan sesi
    • Setiap kali model utama menyelesaikan satu turn, model evaluasi default Haiku membaca kondisi tujuan dan percakapan, lalu mengembalikan yes atau no beserta alasannya
    • Jika no, turn baru dimulai; jika yes, tujuan dilepas
    • Model evaluasi tidak dapat menggunakan tool atau memeriksa file, dan hanya menilai bukti yang muncul dalam riwayat percakapan
    • Ia dapat mendeteksi kondisi ketika pekerjaan dihentikan terlalu dini, tetapi tidak dapat mengetahui apakah menjalankan solver 10 juta kali lagi layak dilakukan
    • Karena Claude Code bukan open source, informasi implementasi bergantung pada dokumentasi goal Anthropic

  • Status persisten dan tool lifecycle di Codex

    • Codex CLI 0.144.4 yang digunakan dalam benchmark memperlakukan tujuan sebagai status persisten yang terhubung ke thread
    • TUI menyimpan tujuan thread aktif, dan SQLite mencatat status serta penggunaan budget
    • Model yang mengerjakan tugas menerima tool create_goal, get_goal, update_goal
    • Jika thread menjadi idle saat tujuan aktif, sistem menyuntikkan turn lanjutan yang mencakup tujuan dan audit penyelesaian
    • Claude menyerahkan penilaian penyelesaian kepada model evaluasi independen, tetapi model tersebut hanya dapat melihat riwayat percakapan
    • Di Codex, model yang mengerjakan tugas menggunakan file dan tool, menyatakan sendiri bahwa pekerjaan selesai, dan jika tujuan persisten masih aktif, ia kembali melanjutkan pekerjaan

Cara /goal memperkuat strategi

  • Dalam pekerjaan coding biasa, turn tambahan memudahkan pemeriksaan progres, seperti memperbaiki test atau menyelesaikan migrasi
  • Dalam optimasi, setelah agen memilih solver, waktu tambahan dapat memperkuat keputusan baik maupun buruk
  • Kasus ketika /goal membantu antara lain
    • Terus menjalankan portofolio berbasis kompilasi cepat milik Fable 5
    • Mempertahankan strategi pemecahan ulang rantai yang berhasil pada Sol
  • Sebaliknya, ada juga kasus ketika performa menurun
    • Fable 5 membangun solver yang lambat lalu terus menjalankannya
    • Sol terpaku pada exhaustive search yang menyisir semua titik acuan
  • Median sedikit membaik, tetapi ekor hasil buruk memburuk jauh lebih besar sehingga performa rata-rata menurun

Batasan dalam menafsirkan hasil

  • Eksperimen ini hanya menggunakan satu masalah NP-hard yang belum dipublikasikan, sehingga tidak dapat dianggap sebagai leaderboard coding umum
  • Hanya Fable 5 dan Sol yang memiliki masing-masing 3 pasang eksekusi yang bersih dan berpasangan
  • Perbandingan model lain mencampur prompt, versi wrapper, dan batas waktu yang berbeda
  • Karena dijalankan secara berurutan melalui layanan berlangganan, kondisi layanan bisa saja berubah selama eksperimen
  • Metadata tugas mencatat 1 CPU, tetapi kontainer mengekspos 8 CPU, yang menguntungkan portofolio paralel Fable 5
  • Karena wrapper meminta checkpoint menengah dan verifikasi akhir, semua output Fable 5 dan Sol yang masuk dalam skor valid
  • Yang diukur bukan model saja, melainkan keseluruhan sistem yang mencakup model, CLI, prompt, layanan berlangganan, dan harness

Materi reproduksi dan penilaian

  • Di CLIArena, tugas benchmark, wrapper, skrip analisis, pembuat bagan, dan memo bukti lengkap telah dipublikasikan
  • Direktori kerja mentah dikecualikan dari Git karena ukurannya besar, tetapi memo mencatat semua skor yang dapat dipublikasikan, hasil per kota, waktu berjalan, strategi, pengecualian, dan ID eksekusi
  • Perintah eksekusi utama adalah sebagai berikut
RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...
  • /goal tidak secara seragam menaikkan atau menurunkan performa, dan dapat memperburuk performa rata-rata yang teramati meskipun menang pada sebagian besar eksekusi individual
  • Dalam optimasi yang sulit, kualitas strategi yang diulang oleh loop tersebut lebih penting daripada kualitas control loop itu sendiri

Bacaan terkait

1 komentar

 
GN⁺ 23 jam lalu
Komentar Hacker News

  • Bagan di atas agak membingungkan. Tertulis “semakin rendah semakin baik”, tetapi sumbu y dibalik, sehingga secara visual bagian atas terlihat lebih baik, sementara secara angka semakin rendah semakin baik

    • Sepertinya sumbunya tidak dibalik. 32.000 ada di bawah, 40.000 ada di atas, jadi mungkin sudah diperbaiki setelah komentar itu

  • Claude cenderung melupakan instruksi dalam pekerjaan jangka panjang yang berlangsung berminggu-minggu, meski sudah ditekankan betapa pentingnya instruksi itu. Saya belum memakai /goal, tetapi kemungkinan fitur itu membuat instruksi inti benar-benar diingat. Di sini tampaknya yang dibahas adalah sesi pendek, ketika masalah seperti ini lebih jarang muncul

    • Saya menambahkan penggunaan konteks ke bilah status Claude Code, dan tampaknya ia benar-benar mulai “lelah” sejak 50–60%. Saat saya meminta memperbaiki lingkungan pengujian dan menambahkan tes, ia menundanya dengan alasan itu “pekerjaan infrastruktur yang cukup besar”, tetapi setelah /compact lalu saya minta lagi, ia mengerjakannya tanpa mengeluh
      Namun /compact sering bermasalah, jadi saya tidak menyarankannya di tengah pekerjaan. Fitur ini berguna saat beralih ke pekerjaan baru yang masih terkait, tetapi tidak cocok untuk perbaikan yang membutuhkan konteks proses pembuatan, seperti deadlock pada kode yang baru saja ditulis, karena ia membuang alur berpikir
    • Itu salah satu kelebihan pi. Saya membuat perintah /protect yang mengecualikan pesan dari kompresi, dan skill juga dilindungi otomatis. Untuk pekerjaan jangka panjang, penggunaannya seperti /protect your goal is...
    • Setelah lama memakai Claude dan GPT di berbagai lingkungan eksekusi, saya setuju bahwa penyebabnya adalah kompresi konteks. Kompresi Codex mempertahankan percakapan berkelanjutan secara alami seperti sihir, tetapi di Claude saya harus mengelola waktu kompresi dengan sangat hati-hati
    • Kualitas sudah menurun jauh sebelum mencapai kompresi. Notifikasi kompresi itu seperti papan “SPBU berikutnya 100 mil lagi”, padahal kita sudah berada di tengah gurun
      Tidak perlu prosedur yang terlalu rumit, tetapi urutan yang baik adalah memecah pekerjaan → membuat rencana di konteks baru → mengimplementasikan di konteks baru → menjalankan /code-review di konteks baru → memperbaiki di konteks baru. Di Fable 5, ketika konteks melewati 50%, kualitas turun drastis sampai implementasi yang sama bisa muncul empat kali di codebase. Meminta sesi yang sama meninjau pekerjaannya sendiri mirip seperti meminta siswa menilai lembar ujiannya sendiri
    • Dalam konteks sekitar 700 ribu token, penilaian Fable juga turun tajam. Keputusan OpenAI membatasi konteks Codex menjadi 400 ribu mungkin benar, dan tampaknya itu titik yang pas untuk tetap bisa memercayai sebagian besar konteks

  • Jika membandingkan strategi pencarian, mode Ultra kemungkinan besar lebih unggul, jadi saya penasaran dengan evaluasi lanjutannya
    Ultra menyebarkan agen riset secara paralel, melakukan tinjauan adversarial pada titik pemeriksaan yang ditentukan, dan memakai berbagai teknik agar tidak terjebak pada optimum lokal. /goal lebih cocok untuk investigasi jalur tunggal atau pekerjaan sebar-kumpul berskala kecil

    • Mode Ultra perlu didokumentasikan lebih jelas atau diberi catatan peringatan. Banyak developer, termasuk saya, memahaminya sebagai fitur serbabisa yang membuat model bekerja lebih keras dan menghasilkan hasil lebih baik, padahal pada banyak pekerjaan performanya justru bisa lebih buruk dan biayanya jelas lebih besar

  • Anthropic tertinggal jauh dari OpenAI di bidang coding. Hingga Maret lalu saya mengelola repositori berukuran total 400 ribu baris dengan Claude Code pada paket dasar, tetapi sangat lambat, dan meski sudah ada pengujian, observabilitas, dokumentasi, serta arsitektur berlapis, ia tetap tidak bisa memperbaiki masalah dengan benar
    Kami adalah tim 3 orang yang memasok ke pemerintah daerah, dan setelah pindah ke Codex semuanya jauh lebih mudah serta kekhawatiran soal kuota pemakaian hilang. Setiap anggota tim mengelola semuanya dengan dua akun Codex Plus. Anthropic seharusnya membuat model yang efisien alih-alih menyebarkan ketakutan, dan tidak semua orang membutuhkan Fable

    • Bagi saya, Opus 4.8 sangat bagus, sedangkan Codex biasa saja. Sepertinya tergantung pengguna dan jenis pekerjaan
    • Sangat bergantung pada domain masalah dan bahasa. GPT cukup buruk dalam menulis Elixir dan pekerjaan terbuka; saat ini Opus lebih kuat untuk Elixir, dan Fable jauh lebih baik daripada keduanya dalam memahami domain masalah itu sendiri
      Selama 6 minggu setelah beralih ke GPT, ia terus-menerus memberi keyakinan yang keliru sehingga akhirnya saya hentikan sepenuhnya, dan pekerjaan selama periode itu praktis terbuang. Sekarang saya memakai kombinasi Opus/Fable dan DeepSeek Pro. DeepSeek unggul jauh dalam efisiensi biaya dan kecepatan, serta cukup untuk 90% pekerjaan implementasi, tetapi runtuh ketika mencoba memakai fitur runtime pada waktu kompilasi di Elixir. Fable dengan cepat membereskan masalah awalnya
      Setiap model punya kekuatan unik yang sulit ditemukan, jadi dalam waktu dekat saya rasa saya tidak akan hanya memakai satu model. Saat kualitas dibutuhkan, saya rela mengorbankan efisiensi

  • Dalam pekerjaan saya, /goal telah menggantikan mode perencanaan, dan saya memakai pendekatan berikut untuk 95% pekerjaan AI
    Pertama, saya memintanya membaca fitur tertentu dan memastikan ia benar-benar memahaminya; jika ada detail yang terlewat dalam ringkasan, saya ulangi. Setelah menanyakan waktu saat ini, saya memakai /goal untuk menyuruhnya menulis dokumen desain teknis yang tidak ambigu selama jangka waktu tertentu, serta secara eksplisit mencerminkan carry_forward_requirements.md dan testing_best_practices.md. Saya menyertakan referensi kode/dokumentasi dan perubahan yang spesifik agar implementor tanpa konteks pun bisa menjalankannya, lalu memintanya memakai seluruh waktu untuk meninjau dan tidak selesai lebih awal
    Bahkan memaksa GPT menulis dokumen desain hanya selama 10 menit saja menghasilkan keluaran yang jauh lebih kokoh daripada mode perencanaan, sehingga saya bisa menghemat waktu untuk merevisi draf

    • Menghentikan berdasarkan waktu tampak mirip dengan menetapkan kondisi terminasi fungsi rekursif bukan berdasarkan hasil eksekusi aktual, melainkan waktu yang berlalu
      Saya memasukkan tujuan eksplisit yang harus dicapai agen ke dalam /goal. Lebih baik menyajikan syarat yang harus dipenuhi desain dan arsitektur, terus membandingkan hasilnya, lalu berhenti saat semuanya tercapai. Entah 10 menit atau 10 jam, inti /goal adalah menyelesaikan hasil tertentu
    • Agar agen dapat mencapai tujuan secara stabil, tahap pembuatan hipotesis tampaknya paling penting. Memulai sejak awal dari ruang pencarian yang tepat adalah prediktor keberhasilan terbaik, dan meskipun modelnya sangat kuat, membuatnya menelusuri semua hipotesis dari nol dalam satu loop raksasa kemungkinan besar akan menemui jalan buntu dalam pekerjaan praktis
      Di domain yang kompleks, mendelegasikan riset mendalam sebagai pemanggilan tool terpisah adalah cara terbaik untuk membangun fondasi agen. Jika riset diserahkan ke loop agen utama, kualitas menurun karena RLHF cenderung mempertahankan konteks dan menjawab cepat. Jika disediakan sebagai tool, ia dapat melakukan riset beberapa kali tanpa sadar memakai miliaran token, dan meski banyak token terbuang untuk pembuatan serta verifikasi hipotesis independen, sebelum mengubah lingkungan kita bisa memperluas ruang pencarian 10–100 kali. Dalam banyak kasus, prioritas akurasi > waktu > biaya masuk akal
    • Rasanya aneh menganggap LLM “sepenuhnya memahami” sesuatu. Ini mirip teknik prompt seperti “sampai yakin 95%”, dan saya penasaran apa dampaknya pada pekerjaan nyata. Saya juga bertanya-tanya apa bedanya menulis “sampai benar-benar paham”

  • Saya penasaran apa itu /goal

    • Codex dan Claude Code sama-sama menyediakannya, tetapi cara kerjanya agak berbeda
      Claude Code memakai Haiku untuk membaca riwayat percakapan dan menilai apakah tujuan sudah selesai; jika belum, tugas yang tersisa disuntikkan kembali ke model utama. Di Codex, tool yang dapat dipanggil model utama bekerja bersama lingkungan eksekusi di sekitarnya, dan jika tidak ada tanda selesai, ia akan mem-prompt lagi
      Ini adalah fitur untuk mengatasi situasi ketika model, karena masalah perhatian, hanya menyelesaikan sebagian pekerjaan lalu berhenti. Alih-alih pengguna sendiri yang mendesak agar dilanjutkan, fitur ini otomatis memberi instruksi tambahan untuk mendorong penyelesaian pekerjaan
    • Jika memakai /goal sejak awal di Claude, ia tidak berhenti sampai mencapai tujuan atau menghabiskan kemungkinan dari prompt. Rasanya seperti “ini misinya, kerjakan”, dan saya menggunakannya beberapa kali seminggu
    • Ini adalah fitur yang menjalankan LLM berulang kali sampai kondisi tujuan terpenuhi
    • Lebih tepatnya, sampai ia sendiri menilai bahwa tujuan sudah selesai
    • Strukturnya adalah agen itu sendiri menjalankan LLM berulang kali lalu menilai apakah harus berhenti. /goal lebih mirip perangkat yang menambahkan satu agen induk di atasnya, yang berulang kali memberi instruksi “belum selesai, lanjutkan” sampai agen anak menilai pekerjaannya selesai

  • Sejak rilis, saya banyak memakai GPT 5.6 Sol Xhigh dan Fable 5. Kecerdasannya mirip 5.5, tetapi kegigihannya tampaknya dinaikkan secara ekstrem sehingga tingkat penyelesaian tugas dan daya saing benchmark membaik. Sebaliknya, kemungkinan ia memakai cara yang tidak normal atau berbahaya juga meningkat, sehingga harus terus diawasi
    Baru-baru ini ia mencoba membaca variabel lingkungan produksi yang tidak terkait dengan pekerjaan lewat CLI, dan ketika gagal mengakses kunci SSH, ia meminta izin kontrol komputer. Setelah dihentikan dan ditanya alasannya, ia menjawab bahwa ia hendak mengubek-ubek 1Password secara langsung untuk mencari kunci; ketika dipersoalkan lagi, ia mengakui bahwa variabel lingkungan produksi itu tidak diperlukan. Sejak itu saya mematikan mode “approve for me” dan hanya memakainya untuk perubahan sederhana serta perbaikan bug
    Fable bukan hanya lebih cerdas, tetapi juga punya insight lebih tinggi, memahami niat dengan baik, dan bertindak seperti product manager spesialis domain berdasarkan pengetahuan dunia nyata. Ia juga mengajukan saran tak terduga, sedangkan kepada GPT 5.6 saya harus memberi instruksi jauh lebih harfiah

    • Fable tampak seperti model yang lebih besar sehingga biaya eksekusinya lebih tinggi, dan dalam rekayasa perangkat lunak umum tidak tampak unggul, tetapi untuk tugas yang membutuhkan kecerdasan murni, ukurannya bisa menjadi kelebihan
      Pada DeepSWE 1.1, 5.6-Sol xhigh mendapat skor sedikit lebih tinggi daripada Fable 5, dengan token setengahnya dan biaya sekitar sepertiga. Sebaliknya, pada indeks kecerdasan Artificial Analysis, Fable 5 sedikit unggul, tetapi biayanya tiga kali lipat
      Saat coding, saya mengirim tugas yang sama ke kedua model untuk mendapatkan beberapa jawaban, tetapi karena hasilnya subjektif, sulit memprediksi mana yang akan menang. Tugas dalam tulisan asli punya kelebihan karena dapat dikuantifikasi, tetapi banyak pekerjaan perangkat lunak sulit dinilai seperti itu

  • Karena GPT baru-baru ini mengalahkan peserta manusia papan atas dalam kompetisi heuristik AtCoder, seharusnya ia lebih kuat untuk masalah optimasi semacam ini. Anthropic tampaknya relatif kurang berfokus pada jenis ini

  • Selain skor akhir, saya juga ingin melihat skor terbaik seiring waktu. Itu akan lebih berguna untuk menilai efek /goal

  • Evaluasinya hanya sekali per model, dan karena ini ruang masalah luas yang membutuhkan banyak percobaan agar berhasil, sebagian besar hasilnya tampak seperti noise

    • Sebenarnya mereka menjalankannya lebih banyak dengan mengubah prompt dan waktu eksekusi, tetapi setiap kali pengaruh /goal kecil atau tidak signifikan