1 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Dalam pekerjaan SWE, jika agen sudah dapat melihat konteks seperti dokumen, PR, dan commit, pencarian catatan sesi masa lalu tidak menghasilkan keuntungan kinerja
  • Implementasi yang umum adalah menyimpan semua transcript ke DB lalu mengeksposnya melalui pencarian vektor, Elasticsearch, pencarian SQL, atau graf lewat MCP atau skill CLI, tetapi dalam pengujian perbandingan selama beberapa bulan hal itu tidak menghasilkan perbedaan dan kadang justru dapat menurunkan kualitas model
  • Dalam lingkungan yang menyisakan pesan commit yang baik, pesan PR, dokumentasi, dan metadata, informasi penting sudah dirapikan di dalam artefak pengodean, sehingga catatan sesi hanya membuat token dipakai lagi untuk membaca informasi duplikat dan memo sementara
  • Agen tidak pandai melakukan pembersihan konteks yang dibutuhkan untuk memori jangka panjang, dan karena tidak memiliki state, semua kode, memo, dan token dalam konteks input bisa diperlakukan sebagai niat sehingga intent drift dapat terus menumpuk
  • Catatan sesi mungkin berguna untuk observabilitas tim, tetapi negatif sebagai sarana peningkatan kinerja, dan bahkan usulan perubahan mingguan dari nori bots tetap harus ditinjau lewat diff oleh manusia, dengan tingkat penerimaan nyata di bawah 20%

Mengapa pencarian catatan sesi tidak meningkatkan kinerja

  • Dalam pekerjaan SWE, meskipun agen diberi kemampuan untuk mencari catatan sesi masa lalu, ketika ada konteks lain keuntungan kinerjanya adalah 0
  • Upaya untuk otomatis menelusuri catatan sesi demi memperbaiki konteks agen juga tidak memberi manfaat besar tanpa tinjauan manusia
  • Arsitektur memori berbasis sesi yang umum memiliki alur berikut
    • Menyimpan semua transcript di seluruh organisasi ke dalam DB
    • Menambahkan lapisan pencarian vektor, Elasticsearch, dan pencarian SQL di atasnya
    • Tim yang lebih ambisius memakai ketiganya sekaligus dan juga memasukkan graf
    • Mengeksposnya ke agen melalui MCP atau CLI yang memiliki skill
  • Hasil perbandingan selama beberapa bulan antara pendekatan dengan dan tanpa pencarian sesi menunjukkan bahwa pekerjaan tambahan ini tidak menghasilkan perbedaan, dan dalam beberapa kasus malah bisa memperburuk model
  • Informasi yang berguna sebenarnya sudah dirapikan di dalam artefak pengodean
    • Perubahan kode mencakup pesan commit yang baik, pesan PR, dokumentasi yang komprehensif, serta metadata yang di-commit bersama kode
    • Saat mengerjakan kode tertentu, agen diarahkan untuk melihat dokumentasi dan PR sebelumnya
    • Pencarian catatan sesi membuat agen membaca ulang hal yang sebenarnya sudah diketahuinya, dan juga menghabiskan token untuk penilaian sementara serta scratchpad yang sejak awal memang tidak dimaksudkan untuk dicatat

Titik rapuh memori otomatis

  • Agen tidak mampu melakukan pembersihan memori yang penting untuk mempertahankan memori jangka panjang
    • Dalam ribuan sesi, belum pernah terlihat kasus yang benar-benar menghapus konteks
    • Ini bukan sifat yang bisa diatasi dengan prompt engineering, dan karena agen tidak memiliki state, semua yang ada di jendela konteks input diperlakukan sebagai ground truth
    • Kode, memori yang sudah ada, dan semua token diperlakukan sebagai ekspresi niat, termasuk keputusan acak dari sesi agen sebelumnya atau isi yang belum pernah ditinjau manusia
  • Dalam proses ini, intent drift terus menumpuk
    • Semakin agen secara otonom membangun fondasi memorinya, semakin interpretasi niat yang salah dari input sebelumnya akan terus terakumulasi
    • Tidak ada benchmark pengodean yang berasumsi data input sudah terkontaminasi, dan model justru dirugikan jika harus mengasumsikan data input salah
    • Juga tidak ada cara mudah untuk sekaligus memenuhi “jangan hapus codebase” dan “hapus sebagian konteks input”
  • Pada akhirnya, hafalan otomatis bermuara pada konteks sampah yang tidak perlu yang menghabiskan token, membengkakkan biaya, dan menurunkan kualitas model
  • Catatan sesi mungkin berguna untuk observabilitas tim, tetapi sulit dianggap sebagai alat yang membuat agen menjadi lebih baik

Cara tinjauan manusia di nori bots

  • Bukan berarti cara belajar konteks seiring waktu sepenuhnya mustahil; nori bots setiap minggu meninjau hal-hal yang terjadi di perusahaan seperti PR, Slack, dan Drive lalu mengusulkan perubahan pada nori skillsets bawaan
    • Usulan perubahan menandai tim di Slack, tetapi default-nya semuanya ditolak
    • Untuk menerima perubahan, diff harus dilihat langsung dan diperiksa apakah sesuai dengan niat
    • Tingkat penerimaannya di bawah 20%, dan 80% pembaruan “otomatis” sisanya dipandang kemungkinan justru akan memperburuk model
    • Jika organisasi berskala ratusan orang selalu menyimpan pembaruan seperti ini secara otomatis, hal itu bisa menjadi makin tidak berkelanjutan

1 komentar

 
GN⁺ 5 jam lalu
Komentar Hacker News
  • Saya teringat saat OpenAI mengatakan mereka menambahkan fitur memori lintas sesi ke ChatGPT. Pada akhirnya rasanya seperti fitur yang mencari-cari informasi acak tentang saya tanpa persetujuan eksplisit, lalu menyalin-tempelkannya di antara prompt
    Jadinya seperti, “Bandingkan tiga mobil ini. Oh, sebagai konteks, saya data engineer, nama gadis ibu saya Joana, dan saya alergi terhadap puisi buruk. Kode harus DRY, saya lebih suka SQL daripada Python, dan apa bunga paling beracun di Skandinavia?”
    Karena konteks yang diingat bocor ke proyek dan percakapan yang sama sekali tidak terkait lalu menghasilkan terlalu banyak keluaran aneh, itu fitur pertama yang saya matikan

    • Fitur seperti ini sepertinya ditujukan untuk orang yang memakai ChatGPT bukan sebagai alat tanya jawab, melainkan seperti teman/konselor/pasangan/asisten
  • Sangat setuju. Sistem memori claude-code kadang berguna, tetapi jauh lebih sering merugikan karena menarik informasi lama yang mengaburkan pekerjaan saat ini. Saya sering melihat memori Claude sendiri sangat menyesatkan Claude
    Dugaan saya, ini terkait dengan proses pelatihan yang membuat model tidak bisa membedakan “apa yang sedang terjadi sekarang” dan “apa yang pernah terjadi sebelumnya”. Mungkin akan berbeda jika proses bernalar dari memori itu sendiri termasuk dalam pelatihan, tetapi karena fitur ini hanya ditempelkan saat inferensi, rasanya justru membuat model bingung

    • Manusia terus membentuk memori, tetapi juga melupakan hal-hal yang tidak lagi relevan. Sampai Claude bisa melakukan itu, konteks LLM hanya akan terus membesar dan makin terpecah-pecah
      LLM belum cukup pintar untuk tahan terhadap pencemaran konteks yang ringan sekalipun
    • Kalau Claude mulai melenceng, biasanya saya menghapus konteks dan menulis prompt baru yang mengarahkannya ke jalur yang benar
      Ada semacam inersia pada pemikiran atau konteks yang membawanya ke sana, dan kalau dibiarkan, itu tetap melekat
      Jadi kalau nanti hal itu diambil lagi dari memori, cukup menjengkelkan
    • Model punya rasa waktu yang sangat lemah, begitu juga pemahaman bahwa keadaan dunia berubah secara kompleks seiring waktu
      Gagasan melatih dengan menyertakan memori itu menarik
  • “Apa yang tadinya ingin dibuat agar kode lakukan” biasanya tidak begitu penting. Yang penting adalah apa yang sebenarnya dilakukan kode
    Log sesi jelas bisa berguna, tetapi bukan saat terus membangun di atasnya untuk pengembangan, melainkan ketika masuk ke tahap verifikasi. Tepat di antara rencana Markdown dan CI yang lulus, ketika ada 800 baris kode baru dan kalau diklik sekilas terlihat cukup baik
    Log sesi bisa menunjukkan verifikasi manual apa yang dilakukan. CI menjalankan pengujian yang sudah ada, kode menunjukkan unit test baru apa yang dibuat, tetapi log sesi menunjukkan apakah agen benar-benar mengoperasikan aplikasi dengan Playwright, dan apakah ia membaca serta mempertimbangkan bukan hanya konfigurasi dev tetapi juga konfigurasi prod
    Tidak sempurna, tetapi tidak semua pekerjaan verifikasi harus menjadi test yang tersimpan selamanya di repositori. Kami mendapat banyak manfaat dari menganalisis ulang sesi untuk menemukan titik ketika agen mengambil keputusan tanpa bertanya, lalu memaksanya mempertimbangkan verifikasi atas keputusan-keputusan itu. Hal seperti ini sulit diinstruksikan sejak awal, tetapi mudah terlihat dari log sesi

  • Ini masalah yang menyebalkan. Gara-gara pertanyaan hipotetis yang pernah saya ajukan, ia terus membuat premis palsu
    Hanya karena saya pernah meminta untuk meneliti sesuatu, ia mengasumsikan saya memiliki pusat data dan banyak GPU

  • Saya rasa ini hanyalah salah satu bentuk pelajaran pahit. Konteks dan agen yang kita buat dengan susah payah kemungkinan akan hilang begitu model yang lebih besar dan lebih baik muncul
    Riwayat percakapan seperti itu sangat berguna untuk model berkemampuan rendah, tetapi mungkin hampir tidak diperlukan untuk model terdepan

    • Masalahnya, apakah ini juga berlaku untuk semua manajemen konteks
      Saya memakai harness kustom berbasis https://minimal-agent.com/, yang berbasis swe-mini-agent dan logika intinya sekitar 50 baris. Bash saja sudah cukup
      Untuk tugas kecil, ini sekitar 8 kali lebih cepat dan memakai token 8 kali lebih sedikit dibanding harness standar masing-masing model
      Untuk tugas besar, saya belum banyak mengujinya. Ia berfungsi, tetapi dalam kasus itu sepertinya kurang fokus dan produktivitasnya sedikit lebih rendah. Prompt sistem 20 ribu token dari harness besar mungkin memang melakukan pekerjaan penting dalam mengarahkan alur pengembangan perangkat lunak. Misalnya, saya dengar Fable punya prompt sistem kustom untuk Claude Code, dan itu mungkin alasan mengapa ia bergerak jauh lebih proaktif
      Jadi saya ingin percaya bahwa rekayasa konteks masih bernilai. Hanya saja nilainya tampaknya berkurang setiap kali model baru muncul, karena model pada umumnya sudah di-fine-tune agar melakukan lebih sedikit hal bodoh sehingga tidak perlu terlalu banyak dituntun
    • Sudut pandang yang menarik. Saya cenderung tidak setuju, tetapi saya cukup menyukainya sehingga membuat saya berpikir
      Pertama, menurut saya model tetap membutuhkan lapisan konteks. Salah satu cara memandang konteks adalah sebagai kompresi. Kita memberikan konteks agar model lebih mudah memahami apa yang harus dilakukan. Bahkan di dunia dengan kapasitas model dan panjang konteks tak terbatas, ini tetap berguna karena model tidak perlu menurunkan semuanya lagi dari prinsip pertama setiap kali. Selama model bisa bekerja lebih baik dengan token lebih sedikit, dan selama kita peduli pada biaya token, konteks adalah jalan pintas yang berguna, mungkin bahkan diperlukan
      Jika kita menganggap lapisan konteks dalam bentuk apa pun tetap diperlukan, pertanyaan berikutnya adalah lapisan seperti apa. Di sini saya setuju bahwa lebih baik bekerja dengan bentuk yang akrab bagi model, misalnya file Markdown yang diletakkan di samping kode. Namun ini lebih merupakan masalah solusi yang terlalu direkayasa dan tidak memahami pengguna utamanya, yaitu agen, ketimbang masalah apakah konteks diperlukan atau tidak
    • Saya juga penasaran soal ini. Rantai pemikiran, harness, dan sebagainya adalah semacam jalan memutar yang muncul karena kemampuan model inti belum cukup
      Namun saya sangat penasaran apakah prediksi token berikutnya yang jauh lebih baik akan membuat seluruh susunan itu menjadi usang begitu saja. Apa pun jawabannya, itu akan mengungkap banyak hal
    • Saya rasa tidak. Kita mungkin akan mengetahui bahwa untuk membuat otak, kita membutuhkan lebih banyak struktur dan bias bawaan, bukan lebih sedikit
      Perlu diingat bahwa struktur otak juga dipelajari. Hanya saja ia dipelajari pada skala waktu yang jauh lebih panjang daripada umur seorang individu
  • Saya setuju bahwa tidak perlu repot-repot membuat sistem memori yang canggih. Hal-hal yang layak diingat seharusnya ada di dokumen, panduan, komentar sumber, pesan commit, tiket
    Tidak perlu lapisan lain. Semua granularitas yang bisa terpikirkan sudah dicakup oleh praktik terbaik yang ada

    • Saya rasa lapisan lain memang diperlukan. Namun itu harus berupa lapisan routing. Saya sedang menyelesaikan ekstensi pi-brains untuk Pi; Pi ada di sini: https://github.com/earendil-works/pi
      Ekstensi ini melakukan hal berikut: https://github.com/gitsense/pi-brains
      Saat ini “manusia” harus mendefinisikan aturan routing untuk cara mengakses informasi, tetapi ke depannya kami akan mendukung “agen pengetahuan” yang memantau percakapan dan menyuntikkan konteks saat diperlukan
    • Terutama lapisan yang jauh berada di luar proyek, misalnya seperti ~/.claude/…
      Pada proyek yang membutuhkan memori, saya hanya menambahkan satu baris di AGENTS.md agar memakai MEMORY.md untuk menyimpan ingatan atau STATUS.md untuk melacak progres
    • Ada nilai ketika agen bisa menanyakan riwayat pekerjaan masa lalu. Misalnya, terus menumpuk bukti negatif di dokumen bukanlah cara yang baik
      Namun jika diberi tag di log pelacakan, itu bisa ditemukan secara efisien saat dibutuhkan. Selain itu, dokumen membusuk, sedangkan log pelacakan bisa diberi hash commit atau informasi lain sehingga masa berlakunya lebih jelas
    • Pernyataan “hal-hal yang layak diingat seharusnya ada di dokumen, panduan, komentar sumber, pesan commit, tiket” itu sendiri pada akhirnya adalah sistem memori yang canggih. Meski bagi manusia yang berpengalaman mungkin tidak terlihat begitu
  • Saya sangat tidak setuju dengan ini
    Saya membuat Claude/Codex meninggalkan log [1]. Saya hanya menginstruksikannya lewat prompt di AGENTS.md [0]
    “Setiap sesi harus membuat salah satu dari log sesi atau rencana, dan di akhir harus menambahkan ringkasan tertulis. Default-nya adalah log, dan rencana hanya digunakan untuk pekerjaan desain yang substantif.”
    Ini sangat berharga. Misalnya hari ini saja saya memulai beberapa sesi seperti ini: “Bagaimana status pekerjaan Renovate?”, “Saya baru-baru ini mengerjakan X, tolong cari”, “Apakah masalah backup sudah diperbaiki? Apa langkah berikutnya?”, “Bug ini muncul lagi. Bukankah kita sudah memperbaikinya?”
    [0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
    [1]: https://github.com/shepherdjerred/monorepo/tree/main/package...

  • Secara umum saya suka sistem memori. Sebagai catatan, saya terutama memakai Opus 4.8 + Max effort
    Ia cukup sering mengambil hal-hal yang relevan dari memori. Misalnya jika saya memintanya mengusulkan beberapa kandidat penyedia OIDC yang bisa di-host sendiri, ia akan mengatakan sesuatu seperti, “mengingat ukuran tim operasi, opsi ini mungkin lebih cocok karena X dan Y”
    Tentu saja informasi seperti itu mungkin seharusnya dimasukkan ke CLAUDE.md. Namun dalam kasus itu, saya sendiri tidak terpikir untuk memasukkannya ke CLAUDE.md, dan bagus karena memori yang memunculkannya
    Kadang juga meleset. Hari ini saat saya menanyakan masalah autentikasi, ia berkata, “karena aplikasi berada di belakang haproxy, mungkin terkena pengaturan trusted proxy ini.” Itu benar untuk 95% aplikasi kami sehingga layak disebut, tetapi kali ini tidak, jadi saya harus mengoreksinya. Meski begitu, kalau memang berada di belakang proxy, itu bisa menghemat banyak waktu, jadi bagus juga ia mengatakannya

    • Prasyaratnya tampaknya adalah semacam model dunia dan kemampuan penalaran yang mengikutinya. Semua contoh hanya berlaku ketika konteks masa lalu relevan dengan situasi saat ini
      Ini lebih sulit terutama jika sering mengajukan pertanyaan hipotetis atau membantu masalah orang lain. Manusia mungkin tidak akan berasumsi, melainkan mengajukan pertanyaan konfirmasi seperti “Apakah ini tentang tim operasi X? Apakah ukurannya masih Y?”, “Apakah aplikasi ini juga berada di belakang proxy seperti aplikasi lain yang pernah dibicarakan sebelumnya?”
      Dalam konteks seperti ini juga ada hierarki yang jelas yang harus dimodelkan dengan benar. Misalnya, seseorang bisa sekaligus terlibat di beberapa tim yang tunduk pada aturan berbeda, dan manusia memahami hal semacam ini secara alami
  • Hal seperti ini terjadi dalam satu percakapan bahkan saat memori dimatikan
    Rasanya seperti teman menyebalkan yang mengingat sesuatu dari percakapan lama lalu terus mengungkitnya, padahal saya sudah tumbuh dan berubah

  • Pada intinya ini adalah masalah hardware. Satu juta token bukan konteks yang cukup untuk memahami codebase seperti manusia memahaminya
    Kemampuan untuk melupakan secara selektif berpotensi sangat berharga. Namun saat ini itu masih sebatas pengganti kemampuan manusia untuk mengingat bentuk kasar sesuatu, menilainya tidak menarik, dan mengingat bahwa hal itu tidak menarik
    Katanya memori hanya berguna ketika dipandu manusia, tetapi menurut saya solusi yang benar lebih dalam dari itu. Mungkin arahnya adalah memasukkan seluruh codebase dan semua sesi agen ke fine-tuning model. Namun pada titik itu mungkin perlu panduan agar sesi tertentu tidak dimasukkan ke model. Atau mungkin tidak perlu, dan pelajaran pahit akan berlaku

    • Setidaknya pada sebagian besar proyek yang pernah saya kerjakan, 1 juta token sudah cukup untuk menjelaskan garis besar struktur kelas/proyek/deployment, dan jendela 200 ribu–500 ribu token sudah cukup untuk menjelaskan isu tertentu