LLM Kehilangan Arah dalam Percakapan Multi-Turn

• Model bahasa besar (LLM) menunjukkan penurunan kinerja dan berkurangnya reliabilitas dalam percakapan multi-turn
• Dibandingkan single-turn, pada situasi multi-turn secara eksperimental terkonfirmasi terjadi penurunan kinerja rata-rata 39%
• Faktor utamanya adalah sedikit penurunan kapabilitas dan penurunan reliabilitas yang sangat besar, yaitu kurangnya konsistensi hasil
• LLM cenderung membuat asumsi yang salah di tahap awal, atau terlalu cepat mencoba jawaban akhir
• Akibatnya, jika LLM melakukan kesalahan di awal percakapan, ditemukan fenomena tidak bisa pulih dan kehilangan arah percakapan

---

ABSTRACT

• Model bahasa besar (LLM) sebagai antarmuka percakapan memiliki potensi untuk membantu mendefinisikan, menjelajahi, dan memperbaiki kebutuhan pengguna secara bertahap melalui percakapan multi-turn, bahkan ketika pengguna tidak dapat menyatakan kebutuhannya secara lengkap
• Namun, meskipun sebagian besar evaluasi LLM berfokus hanya pada lingkungan instruksi lengkap single-turn, analisis log percakapan nyata menunjukkan fenomena underspecification sering terjadi
• Dalam penelitian ini, performa LLM dibandingkan dalam skala besar melalui simulasi pada lingkungan single-turn dan multi-turn (underspecified)
• Hasilnya, pada 15 LLM utama semuanya ditemukan penurunan performa rata-rata 39% dalam percakapan multi-turn, yang dianalisis sebagai kombinasi sedikit penurunan kapabilitas dan penurunan reliabilitas yang tajam
• Teramati bahwa ketika LLM memilih jalur yang salah di awal percakapan, setelah itu ia tidak dapat pulih dan kehilangan arah sambil terus tersesat

Introduction

• LLM modern (misalnya ChatGPT, Gemini, Claude, dll.) adalah antarmuka yang mendukung percakapan multi-turn
• Walaupun pengguna tidak menjelaskan seluruh kebutuhannya dengan jelas sejak awal, kebutuhan dapat dipertegas secara bertahap lewat tanya jawab berulang (underspecified → refined)
• Di dunia nyata, banyak pengguna memberikan kebutuhan yang tidak jelas di awal percakapan, tetapi sebagian besar evaluasi masih dilakukan hanya dalam lingkungan single-turn dengan spesifikasi lengkap
• Beberapa penelitian sebelumnya mencoba evaluasi multi-turn, tetapi sering memperlakukan setiap turn percakapan sebagai episode terpisah, sehingga dampak ketidakjelasan yang umum dalam percakapan manusia nyata cenderung diremehkan
• Untuk menjembatani kesenjangan ini, penelitian ini mengusulkan lingkungan sharded simulation (informasi dipecah menjadi beberapa bagian dan hanya satu bagian diungkapkan pada tiap turn) untuk mensimulasikan secara presisi kondisi multi-turn dengan instruksi yang tidak lengkap

Ringkasan hasil utama penelitian

• Saat menerima seluruh instruksi sekaligus dalam single-turn, LLM menunjukkan kinerja 90%, tetapi pada instruksi multi-turn yang underspecified turun menjadi 65% (rata-rata turun 25 poin)
• Fenomena ini muncul hanya setelah dua turn percakapan, dan diamati secara konsisten pada semua LLM, baik model terbuka maupun tertutup, besar maupun kecil
• Analisis penyebab penurunan kinerja menunjukkan dua faktor: (1) penurunan kapabilitas (aptitude loss) dan (2) lonjakan ketidakreliabelan (unreliability)
  • Pada single-turn, model dengan kapabilitas tinggi juga cenderung memiliki reliabilitas tinggi, tetapi pada multi-turn reliabilitas rendah muncul terlepas dari kapabilitasnya
  • Artinya, jika LLM mulai masuk ke arah yang salah selama percakapan multi-turn, ia tidak dapat pulih — fenomena ini diberi nama “lost in conversation”
• Penyebab utama
  • Respons yang bertele-tele dan upaya terlalu cepat memberikan jawaban final
  • Asumsi yang salah terhadap informasi yang belum jelas
  • Ketergantungan berlebihan pada percobaan sebelumnya yang salah
• Terdapat kesenjangan besar antara penggunaan LLM di lapangan dan cara evaluasi model dilakukan
  • Semakin pemula penggunanya, semakin sering mereka memberi instruksi yang tidak lengkap di awal, sehingga fenomena ini menjadi salah satu penyebab utama sulitnya penerapan di dunia nyata
• Struktur makalah diperkenalkan sebagai berikut: ringkasan penelitian terdahulu, penjelasan lingkungan simulasi, 6 tugas generatif dan metrik evaluasi, eksperimen skala besar pada 15 LLM beserta hasilnya, serta implikasi praktis dan rekomendasi konkret untuk penerapan produk dan operasional

Background and Related Work

• Model bahasa generasi sebelumnya (misalnya BART, GPT-2, T5) memang tidak dapat menangani percakapan multi-turn dengan baik, sehingga dievaluasi terutama dalam format single-turn
• Setelah kemunculan ChatGPT, minat terhadap evaluasi multi-turn meningkat, dan dilakukan evaluasi crowdsourcing seperti MT-bench
• Namun, sebagian besar kerangka evaluasi masih berhenti pada percakapan episodik (setiap turn dievaluasi terpisah), sehingga kesinambungan percakapan tidak jelas yang terjadi di dunia nyata belum dipertimbangkan
• Di dunia nyata, sesuai “prinsip upaya minimum”, manusia sering memberi instruksi yang ambigu (a.k.a. underspecification), dan LLM juga mengalami penurunan performa karena menarik kesimpulan terlalu dini saat informasi kurang dan kurang mampu beradaptasi
• Penelitian ini dirancang untuk menargetkan evaluasi yang lebih dekat dengan lingkungan nyata, di mana ketidakjelasan menjadi faktor inti

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

• Instruksi dengan spesifikasi lengkap yang asli dipecah menjadi beberapa shard (potongan informasi)
  • Contoh: alih-alih memuat semua syarat dalam satu kalimat, pada tiap turn hanya satu informasi (pengaturan situasi, angka, kondisi, dll.) yang diungkapkan
• Shard pertama selalu menjelaskan tujuan tingkat atas dari instruksi, lalu shard berikutnya secara bertahap memberikan informasi tambahan (konteks, kondisi, dll.) di setiap turn
• Proses sharding ini membangun kumpulan data instruksi multi-turn berkualitas tinggi melalui usulan+verifikasi LLM (GPT-4o) dan penyempurnaan manual
• Untuk tiap tugas dibuat 90–120 instruksi yang di-shard (dengan beberapa jam pemeriksaan manual)

3.2 Simulating Sharded Conversations

• Simulasi percakapan terdiri dari 3 peran: LLM yang dievaluasi (assistant), user simulator yang mengetahui seluruh shard, serta sistem klasifikasi dan penilaian respons
• Turn pertama: user simulator hanya menyampaikan shard pertama ke assistant → assistant merespons → strateginya diklasifikasikan (klarifikasi, bertanya, mencoba menjawab, dll.) dan jawaban diekstrak → jawaban dinilai
• Turn berikutnya: hanya satu shard tambahan dari shard yang tersisa diungkapkan lalu diulang / pada setiap turn assistant bebas merespons
• Akhir percakapan: (1) evaluator memutuskan jawaban sudah benar, atau (2) tidak ada shard lagi yang bisa diberikan
• User simulator diimplementasikan dengan LLM (GPT-4o-mini), sehingga mampu memberikan shard secara natural dan melakukan rephrase otomatis
• Dalam seluruh eksperimen, salah klasifikasi dan kesalahan ekstraksi oleh LLM pendukung kurang dari 5%, dan kasus yang merugikan assistant kurang dari 2%
• Assistant dievaluasi dalam keadaan default tanpa informasi khusus tentang lingkungan ini (mirip praktik nyata, di mana informasi skenario tidak diberikan secara terpisah)

3.3 Simulation Types

• FULLY-SPECIFIED (FULL): seluruh instruksi diberikan dalam single-turn, untuk mengevaluasi performa baseline
• SHARDED: hanya satu potongan informasi diungkapkan pada tiap turn, eksperimen inti penelitian ini untuk percakapan multi-turn yang underspecified
• CONCAT: seluruh sharded instruction diberikan sekaligus dalam bentuk bullet point, untuk mengukur hanya kehilangan informasi instruksi
• RECAP: setelah percakapan sharded, semua shard diringkas/diberikan lagi di akhir, sebagai salah satu bentuk intervensi sederhana ala agent
• SNOWBALL: pada tiap turn, shard baru ditambahkan sambil seluruh shard yang sebelumnya sudah diungkap diulang kembali, agar assistant tidak melewatkan informasi penting (eksperimen penguatan memori)

Task and Metric Selection

4.1 Task Selection

• Total 6 tugas: pemrograman (Code), basis data (pembuatan SQL), pemanggilan fungsi API (Actions), matematika (Math), tabel→teks (Data-to-Text), dan ringkasan berbentuk tanya jawab (Summary)
  • Contoh: menulis fungsi Python, mengubah bahasa natural menjadi kueri SQL, dll.
• Untuk tiap tugas, 90–120 instruksi dipilih dari benchmark berkualitas tinggi, lalu diverifikasi manual setelah proses sharding
• Keenam tugas tersebut merepresentasikan cakupan pemrograman maupun non-pemrograman, serta mencakup berbagai skenario seperti Summary yang membutuhkan long context

4.2 Metric Selection

• Metrik evaluasi
  • Kinerja rata-rata (P): skor rata-rata dari berbagai simulasi (0~100)
  • Kapabilitas (A90): nilai hasil 10% simulasi teratas (90th percentile, best-case)
  • Reliabilitas (U90_10): selisih skor antara 90% teratas dan 10% terbawah (mengukur konsistensi/variasi hasil)
• Contoh: pada box-plot, bagian paling atas adalah kapabilitas, sedangkan rentang atas-bawah menunjukkan reliabilitas
• Semua 6 tugas dikumpulkan skornya dengan metrik yang konsisten (benar/salah, kemiripan, BLEU, dll.)
• Metode rinci untuk seluruh parameter eksperimen, contoh, sampling, dan kode juga disertakan dalam appendix

Simulation Scale and Parameters

• Total 600 instruction dibangun untuk 6 tugas, lalu diuji dalam skenario FULL/CONCAT/SHARDED
• Untuk 15 LLM (GPT-4, Claude, Gemini, dll.), tiap kombinasi disimulasikan 10 kali, menghasilkan lebih dari 200 ribu data eksperimen
• Semua eksperimen dijalankan dengan temperature 1 (sampling), dan eksperimen tambahan (7.2) juga menganalisis efek temperature
• Dengan data simulasi berskala besar ini, dimungkinkan untuk mengidentifikasi penyebab utama dan pola perilaku serta penurunan performa LLM dalam percakapan multi-turn yang underspecified

Lost in Conversation Experiment

• Selanjutnya, isi utama makalah menjelaskan secara rinci pengaturan eksperimen, hasil per model, analisis penyebab penurunan performa, upaya perbaikan (RECAP/SNOWBALL), serta implikasi praktis dan rekomendasi konkret

[GN⁺]

Opini Hacker News

• Senang melihat makalah yang mengonfirmasi hal yang secara empiris sudah diketahui siapa pun yang benar-benar pernah memakai alat LLM. Konsep “percakapan” itu dibuat oleh antarmuka produk. Menjaga konteks tetap bersih itu penting. Jika konteks sudah terkontaminasi, itu tidak bisa dipulihkan, jadi harus mulai lagi dengan percakapan baru

  • Pengalaman saya mirip dengan pengamatan ini, meski ada beberapa perbedaan. Selama 2 minggu saya melakukan debug masalah IPSEC dengan Gemini. Awalnya saya menyerap dokumentasi IPSEC OPNsense dan pfSense lalu memberi konteks umum. Setelah itu saya membagikan info konfigurasi dan terus melakukan tanya jawab. Pada akhirnya LLM jadi lebih jarang terdistraksi, dan kadang saya memasukkan posting forum atau posting SO, tetapi LLM juga sempat mengatakan, “ini berbeda dari gejala yang sedang kita lihat.” Semua jalan buntu dieliminasi secara logis, dan LLM membantu refleksi tetapi keputusan tetap harus dibuat manusia. Pada akhirnya saya menemukan akar masalahnya, dan seperti yang dikatakan pengguna lain, LLM kuat dalam menyederhanakan informasi kompleks, tetapi lemah dalam mengembangkan konsep sederhana menjadi kompleks. Saya lebih puas ketika input lebih kompleks atau lebih panjang daripada output. Saya bisa saja melakukannya tanpa LLM, tetapi sangat berguna karena ia menyimpan hal-hal yang tidak saya ingat konteksnya atau tidak bisa saya reproduksi dengan cepat. Juga membantu menemukan pola waktu dalam log dalam jumlah besar. Saya juga memperbaiki beberapa konfigurasi. Bukan hanya menyelesaikan masalah, saya juga belajar banyak. Pemahamannya tentang status kadang salah, tetapi mudah saya luruskan sendiri. Jadi, kalau tahu tujuannya dan memakainya sebagai alat, ini berguna, tetapi kalau keputusan diserahkan padanya atau terbawa ke arah yang salah, hasilnya tidak efektif. Saya memakai 350 ribu token (sekitar 300 ribu kata). Ada posting blog terkait. Tidak perlu rekomendasi wireguard
  • Pengalaman saya benar-benar sama. Istilah “terkontaminasi” memang pas. Begitu ada sesuatu yang salah, semua jawaban setelahnya mulai memburuk. Karena itu saya tidak suka fitur memory di ChatGPT. Tidak ada masalah besar, tetapi saya cemas karena tidak sepenuhnya paham bagaimana kontaminasi konteks itu terjadi
  • Tip terbaik dari saya adalah memanfaatkan tombol “edit” yang sangat kecil dan tersembunyi di ChatGPT dan Claude secara agresif. Kalau keluar jawaban buruk, jangan dibiarkan begitu saja; berhenti, perbaiki, lalu dapatkan jawaban yang lebih baik. Kalau tidak, kekacauan itu akan terus beranak-pinak
  • Saya selalu ingin bisa mem-fork percakapan dan bereksperimen ke berbagai arah. Saya ingin mencegah alur yang menjanjikan terkena kontaminasi yang tidak bisa dibalikkan. Saya belum bisa memakai fitur ini di ChatGPT, jadi saya penasaran apakah ada layanan yang menyediakannya
  • Contoh menarik dari masalah ini adalah prompt awal. Itu pada dasarnya konteks tersembunyi yang permanen. Bot Grok di Twitter belakangan sering menyebut “White Genocide”, dan itu karena seseorang mengubah prompt-nya agar selaras dengan topik tersebut. Chatbot yang sempurna seharusnya tidak terpengaruh di topik lain, tetapi kenyataannya terpengaruh. Pada akhirnya konteksnya berubah, dan ia terus-terusan terobsesi pada topik itu
  • Karena itulah saya membuat FileKitty. Alat untuk cepat menggabungkan beberapa file source code ke dalam format Markdown. Saat meminta dukungan LLM untuk pengembangan software, kalau pencarian codebase diserahkan ke LLM, kemungkinan kesalahan jadi lebih besar. Karena ada kehilangan dalam kompresi konteks, hasilnya juga bisa jadi terdilusi. Hasil terbaik didapat ketika konteks tertentu dibuat jelas sejak awal dan diperbarui di tengah percakapan. Meski begitu, panjang percakapan tetap harus diperhatikan. Ada juga prompt untuk menangkap konteks dengan baik lalu meneruskannya ke sesi baru. Kadang saya memilih file yang harus disertakan lalu memasukkannya ke prompt baru. Diskusi terkait juga bisa dilihat di thread HN lain
  • Sekarang pola seperti ini sudah jadi bagian dari alur kerja saya sendiri. Kadang saya meminta ke LLM, “Progresnya bagus, saya ingin lanjut ke langkah berikutnya, tetapi apakah sebaiknya kita lanjut di percakapan ini atau mulai baru?” Kalau model bilang lebih baik mulai baru, ia menyiapkan prompt ringkasan yang bagus, dan kadang juga menjawab bahwa masih aman untuk lanjut. Saya juga membuat beberapa catatan berjudul "kumpulan nilai awal untuk eksplorasi berikutnya". Dalam proses post-training berbasis RL dan sejenisnya, chatbot memang cenderung terus melanjutkan percakapan. Dalam RL, post-training berbeda dari RL sebenarnya karena hanya memakai mekanisme berbasis preferensi sekali jalan. Preferensi jangka panjang atau percakapan belum banyak diteliti karena kompleksitas komputasinya meningkat secara eksponensial
  • Saya penasaran apakah sudah ada contoh antarmuka untuk “merapikan” riwayat percakapan. Fitur untuk membersihkan jalur buntu atau hal yang tidak relevan di dalam percakapan. Riwayat penuh tetap dipertahankan, tetapi bagian yang tidak perlu dipangkas/dirapikan sesuai jalur topik. Bukan ringkasan, melainkan penataan yang organik
  • Saya hanya memakai LLM untuk autocomplete, tetapi saya rasa masalah ini bisa diselesaikan kalau UI chat LLM menambahkan tombol atau opsi “hapus pesan”. Kalau pesan LLM terakhir dihapus, kita bisa mendapatkan jawaban baru. Ini sangat berguna terutama pada LLM dengan tingkat keacakan (temperature) tinggi. Jika pesan lain dihapus, konteks bisa diperbarui agar tercermin dalam jawaban berikutnya. Ini juga bisa membantu meluruskan kesalahpahaman pengguna yang mengira LLM itu cerdas. Saya tidak tahu apakah ini sudah jadi standar. Kalau belum, saya letakkan ide ini ke domain publik. Di sisi lain, punya “subcontext LLM” untuk mengelola konteks utama juga praktis. Artinya, jika respons terlalu panjang atau masif, LLM bawahan merangkum/merapikan agar konteks seluruh percakapan lebih tertata. Atau lebih sederhana lagi, cukup sediakan tombol “edit pesan” agar manusia bisa merapikannya sendiri
  • Jika konteks sudah terkontaminasi, pemulihannya sulit. Mungkin bisa membaik kalau LLM dapat mereset atau memurnikan bagian tertentu secara berkala. Namun tantangannya adalah bagian mana yang harus dibersihkan dan bagaimana agar informasi inti tidak hilang. Manajemen konteks yang lebih cerdas bisa membantu menjaga konsistensi dalam percakapan panjang, tetapi menyeimbangkannya sulit. Mungkin agen lain bisa mengotomatisasi ini
  • Di chatbot AI, prompt gaya chain-of-thought juga menunjukkan batasan karena alasan yang sama
  • Soal pendapat bahwa “percakapan” hanyalah hasil dari antarmuka produk. Alurnya sudah berubah karena pembelajaran pada dataset evaluasi multi-turn untuk RL. Jendela konteks memang selalu baru, tetapi kecenderungan untuk menafsirkan tiap prompt sebagai bagian dari percakapan yang lebih panjang semakin kuat. Secara publik, post-training multi-turn memang belum meluas, tetapi dalam jangka panjang tampaknya akan diadopsi untuk mencapai lebih banyak tujuan
  • Saat coding, saya juga sering memulai percakapan baru tanpa banyak dialog, lalu menjelaskan ulang dengan kode saat ini. Pendekatan ini sering memberi hasil lebih baik daripada terus memukul satu percakapan yang sama. Sepertinya masalah ini bisa diatasi jika ringkasan dan pelupaan dinyatakan secara eksplisit ke model lewat perintah manual. Ini juga agak selaras dengan mekanisme kerja manusia (working memory vs memori naratif/episodik)
  • Salah satu fitur ChatGPT yang paling menjengkelkan adalah “memory”. Kontaminasi percakapan bisa terbawa bahkan antarchat
  • “Terkontaminasi” memang istilah yang sangat tepat. Saya ingin ada “version control” di percakapan/API sehingga bisa rollback ke keadaan lama atau menyalin ke percakapan baru. Bahkan salah ketik atau edit pesan pun bisa memberi bias halus ke respons-respons berikutnya, jadi fitur seperti ini makin terasa perlu
  • Saya sangat suka UX chat di zed. Seluruh riwayat percakapan bisa diedit seperti file teks, jadi bagian yang tidak diinginkan bisa dirapikan, dihapus, atau diperbaiki sebelum melanjutkan percakapan dengan konteks yang jauh lebih bersih dan relevan. Karena itu saya memakai zed sebagai salah satu antarmuka utama LLM, bahkan untuk hal-hal di luar pemrograman
  • Kontaminasi juga bisa terjadi lewat pertanyaan atau jawaban yang melenceng, atau lewat “pengenceran” yang berulang. Saat membuat konten pun saya sering mengalami instruksi yang awalnya jelas lalu makin lama makin kabur
  • Saya selalu berusaha mengingat bahwa “percakapan hanyalah hasil dari antarmuka produk”, tetapi dalam praktiknya itu tidak mudah karena banyak petunjuk “gaya percakapan” yang bermunculan
  • Saya menyesal telah menyalakan memory. Percakapan jadi terkontaminasi oleh informasi yang tidak berguna
  • Yang mengejutkan adalah seberapa cepat model membuat asumsi yang salah di tahap awal lalu menguncinya
  • Kalau dipikir-pikir, manusia juga sering seperti itu
  • Sekarang karena ChatGPT bisa mengakses percakapan lama lewat “memory”, kontaminasi bisa menjadi permanen. Begitu ia menangkap satu ide yang salah, meskipun pengguna menegaskan berkali-kali agar itu jangan disebut lagi, ia tetap terus memasukkannya ke jawaban. Bahkan prompt internal (“pengguna sangat tidak puas, xyz harus dihilangkan”) bisa ikut tercetak karena keliru, lalu terciptalah situasi lucu di mana justru xyz terus disebut-sebut

• Ini adalah gejala yang berakar pada kecenderungan overconfidence LLM yang sudah dikenal, ketiadaan refleksi diri, dan ketidakmampuan menyadari kapan perlu meminta lebih banyak informasi. Kalau melihat hasil model penalaran, saat bingung LLM tidak meminta penjelasan tambahan, melainkan terus menebak apa yang dimaksud pengguna. Ini menunjukkan batas realistis dari gagasan menggantikan programmer manusia. Bagian yang benar-benar sulit justru adalah “interaksi dengan stakeholder” untuk mengubah kebutuhan yang ambigu menjadi jelas

  • Soal ketidakmampuan refleksi diri, sebenarnya tidak ada agen nyata di dalam LLM, dan pengguna terjebak dalam semacam “cerita pemelihara keyakinan”. Jika Anda meninggalkan input teks sebagai peran pengguna dalam naskah film, LLM hanya meng-autocomplete alur yang tidak lengkap dalam peran chatbot. Misalnya, wawancara dengan draculabot hanya meniru refleksi diri secara dangkal seperti “mendambakan darah” atau “menjadi awan kelelawar”
  • Saya juga sama kecewanya dengan ketidakmampuan LLM untuk secara tegas meminta klarifikasi tambahan pada situasi masalah terbuka dengan informasi ambigu (terutama paradoks). Saya mengujinya di DeepSeek-R1 dan Claude-3.7-Sonnet, dan ada juga blog eksperimen terkait
  • Gemini 2.5 Pro dan ChatGPT-o3 kadang memang meminta informasi tambahan sebelum menjalankan tugas. Gemini juga kadang menawarkan beberapa opsi sambil meminta input dari saya
  • Programmer sungguhan sebenarnya menghabiskan sebagian besar waktunya untuk memahami kebutuhan dengan jelas. LLM masih memperlakukan menebak itu sendiri sebagai semacam fitur
  • Ironisnya, ini juga mirip saat bekerja dengan developer junior. Anda memberi tugas, lalu mereka hanya maju lurus, membuat asumsi tanpa bertanya apa-apa, dan akhirnya sering tersesat begitu dalam di hutan sampai perlu tim penyelamat untuk mengevakuasi
  • Saya rasa ini cukup mudah diubah. Seperti prompt chain of thought yang mengganti token terakhir menjadi “hmm”, kalau LLM hendak berkata “mungkin ini ~”, token itu cukup diganti menjadi “saya akan meminta penjelasan tambahan terlebih dahulu”
  • Meminta informasi tambahan atau refleksi diri juga sebenarnya bisa dilakukan dengan cukup baik kalau memang diminta

• Saya sering memakai teknik meminta LLM merangkum diskusi sejauh ini dalam format prompt yang ringkas, lalu saya koreksi/edit sendiri dan memulai percakapan baru. Metode ini cukup efektif, dan saya rasa sebentar lagi akan diotomatisasi

  • Cursor sempat mencoba ini secara otomatis, tetapi (kecuali memakai model konteks besar) hasil ringkasannya melewatkan terlalu banyak detail sehingga kurang berguna di praktik nyata
  • Claude Code punya perintah /compact yang merangkum percakapan untuk mengurangi penggunaan token

• Saya merancang sendiri TSCE (Two-Step Contextual Enrichment). Saat dipakai pada 300 tugas di GPT-35-turbo, performanya naik +30pp. Framework-nya terbuka dan bebas dipakai. Saya juga melakukan 300 eksperimen tambahan dengan gpt-4.1. Baseline gagal menghapus em-dash sebanyak 149/300 kali, sedangkan TSCE hanya gagal 18/300 kali. Seluruh data dan skripnya juga saya buka

  • Kilowatt-jam terbuang untuk tugas find and replace sederhana. Sudah coba text.replace("—", "-")?
  • Dengan sedikit mengubah prompt baseline, saya mendapat tingkat keberhasilan 100% di GPT-4.1. Bisa tanpa panggilan tambahan, tanpa pemborosan token, dan tanpa teknik rumit

• Saya pernah memecahkan masalah dengan dua sistem (LMM + curator otomatis). Satu adalah LLM itu sendiri, satu lagi ‘kurator pikiran’ yang secara dinamis mengganti dan mengelola bagian-bagian konteks. Dasarnya bukan aturan yang tegas, melainkan kemampuan LLM untuk mengisi celah. Ini membantu memecah masalah menjadi unit-unit kecil untuk diproses, lalu hasilnya digabung untuk mencapai tujuan akhir

  • Ide yang keren. Yang Anda lakukan saat ini tampak mirip dengan conversation RAG. Di masa depan, pemisahan lapisan memori (data training / konteks saat ini / RAG) kemungkinan akan makin jelas
  • Menurut saya ini ide yang menarik. Kalau dibagikan ke publik walau sederhana, banyak orang bisa ikut memperbaiki dan komunitas bisa mengembangkannya sendiri
  • Ini mirip dengan sistem kritik internal yang dibahas di Emotion Machine
  • Akan menarik jika bisa tahu lebih banyak tentang proyek yang sedang Anda buat. Kelihatannya menarik
  • Jadi pada akhirnya ini bisa disebut Map-Reduce-of-Thought

• Aneh rasanya fitur branching/forking belum jadi dasar di alat chat utama. Jawaban memang bisa diedit, tetapi dalam kasus seperti itu banyak konteks lain ikut hilang. Alur kerja saya adalah 1. rencanakan 2. bangun 3. branch 4. ulangi. Saya rasa pemangkasan/branching prompt seharusnya menjadi alat inti dalam pemanfaatan LLM

  • Google AI Studio setidaknya punya fitur ini. Namun implementasinya membingungkan, dan mungkin itu juga alasan mengapa fitur ini belum lebih luas dipakai
  • Sudah sejak lama saya ingin membuat hal seperti ini sendiri. BetterChatGPT setidaknya punya antarmuka penghapusan riwayat yang bagus, tetapi menurut saya branching adalah langkah berikutnya

• Masalah muncul ketika antarmuka LLM dirancang dengan fokus pada percakapan single-turn. Kebanyakan pengguna mengharapkan percakapan linear. Karena itu saya membuat bot Telegram experai_bot sebagai UI universal untuk LLM, dengan pendekatan “kalau bukan balasan, berarti percakapan baru”. Untuk menjaga konteks, percakapan memang harus diteruskan dalam struktur pohon balasan. Pengguna nonteknis kesulitan memahami cara ini. Selain itu, model OpenAI (berdasarkan 3.5 dan 4o) makin tidak akurat ketika pertanyaan yang sama diulang, karena spasi atau opsi makin dipersingkat. Hasil relatif lebih terjaga jika system message diminimalkan. Jika perlu, system message bisa ditambahkan sebagai opsi

• Alasan utama saya membuat promptdown adalah agar seluruh riwayat chat bisa diedit sepenuhnya pada setiap turn. Struktur append-only pada antarmuka standar membuat hal seperti ini sulit dilakukan

• Rasanya bidang LLM saat ini seperti semua orang terus memecahkan masalah yang sama berulang-ulang

  • Seperti LLM dalam percakapan multi-turn, semua orang sedang mengulangi masalah yang sama
  • Ini bukan “pembelajaran” melainkan “menggiring kucing”, tetapi untuk beberapa alur kerja memang cocok
  • Semua orang ingin memamerkan kemampuan prompt engineering versinya sendiri

• LLM benar-benar seperti jin dalam botol. Ia akan menjawab tiga pertanyaan, lalu setelah itu mulai bicara ngawur saja