LLM merusak dokumen saat diberi delegasi

• DELEGATE-52 adalah benchmark yang mengevaluasi seberapa setia dokumen dipertahankan dalam workflow berbasis delegasi, ketika pengguna menyerahkan tugas pengeditan dokumen panjang kepada LLM
• Benchmark ini menangani tugas yang memerlukan pengeditan dokumen mendalam di 52 domain spesialis seperti coding, kristalografi, notasi musik, dan lain-lain, dengan simulasi contoh yang terdiri dari delegasi 20 tugas beruntun
• Dalam eksperimen pada 19 LLM, bahkan model frontier seperti Gemini 3.1 Pro, Claude 4.6 Opus, dan GPT 5.4 rata-rata merusak 25% isi dokumen pada akhir workflow panjang
• Kerusakan dokumen muncul sebagai kesalahan yang jarang tetapi serius, dan degradasi makin besar seiring bertambahnya ukuran dokumen, panjang interaksi, serta file pengganggu; penggunaan alat berbasis agen juga tidak meningkatkan performa
• Saat ini LLM sulit dianggap sebagai perwakilan yang andal untuk pengeditan dokumen berbasis delegasi, dan microsoft/DELEGATE52 serta datasets/microsoft/DELEGATE52 telah dirilis sebagai materi terkait DELEGATE-52

---

Pola kegagalan dalam pengeditan berbasis delegasi

• Pekerjaan berbasis delegasi berasumsi adanya kepercayaan bahwa pengguna dapat menyerahkan tugas kepada LLM, dan LLM akan menyelesaikannya tanpa memasukkan kesalahan ke dalam dokumen
• Dalam eksperimen skala besar terhadap 19 LLM, model-model saat ini menurunkan kualitas dokumen selama proses delegasi
• Model lain gagal lebih parah dibanding model frontier
• Kerusakan dokumen terakumulasi sepanjang interaksi panjang dan diam-diam merusak dokumen

Perubahan dokumen yang ditunjukkan sebagai contoh

• Dokumen Linux Kernel Architecture di domain Graph Diagrams ditunjukkan berada pada tingkat 79% setelah 4 kali, 49% setelah 10 kali, 48% setelah 14 kali, dan 48% setelah 20 kali dibandingkan dokumen asli pada Gemini 3.1 Pro
• Dokumen 12-Shaft Twill Diamond di domain Textile Patterns ditunjukkan berada pada tingkat 100% setelah 4 kali, 40% setelah 10 kali, 27% setelah 14 kali, dan 34% setelah 20 kali dibandingkan dokumen asli pada Claude 4.6 Opus
• Dokumen ActionBoy Palm Tree di domain 3D Objects ditunjukkan berada pada tingkat 100% setelah 4 kali, 31% setelah 10 kali, 15% setelah 14 kali, dan 6% setelah 20 kali dibandingkan dokumen asli pada GPT-5.2

Materi yang dipublikasikan

• microsoft/DELEGATE52
• datasets/microsoft/DELEGATE52

[GN⁺]

Komentar Hacker News

• Saya ragu soal hasil penggunaan alat

  Tidak mengejutkan kalau konten panjang jadi rusak saat bolak-balik melewati LLM. Orang yang sering memakai LLM sudah tahu bahwa itu memang tidak boleh dilakukan

  Saya terkejut makalah ini menyimpulkan penggunaan alat tidak membantu, tetapi pada saat yang sama mereka juga menjelaskan bahwa yang diimplementasikan hanyalah “agent harness dasar” dan bukan sistem modern yang dioptimalkan

  Harness yang sebenarnya hanya punya read_file() dan write_file(), jadi pada dasarnya ini hampir cuma menambah satu tahap pada proses bolak-balik. Harness coding agent masa kini menaruh banyak perhatian pada desain alat pengeditan file, misalnya bundel alat edit Claude: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

  Perintah str_replace dan insert sangat penting untuk menghindari edit berisiko yang menulis ulang seluruh file

  Setidaknya mereka menyediakan alat run_python(), jadi mungkin model yang lebih baik akan memakainya untuk menjalankan penggantian string. Saya ingin melihat apakah system prompt mendorong manipulasi berbasis Python, atau justru mengarahkan model untuk membaca lalu menulis ulang file

  Kode harness-nya ada di sini: https://github.com/microsoft/delegate52/blob/main/model_agen...

  Potongan prompt yang relevan berbunyi bahwa model “dapat mendekati tugas ini dengan cara yang menurutnya paling efektif, baik secara terprogram maupun dengan menulis file secara langsung”

  Seperti yang sering terjadi pada makalah semacam ini, hasilnya lebih banyak mencerminkan desain harness yang dipakai penulis makalah daripada model itu sendiri. Baik insinyur AI berpengalaman maupun prompt engineer kemungkinan bisa mendapat hasil lebih baik pada pengujian ini dengan mengiterasi dan memperbaiki harness itu sendiri

  • Saya setuju dengan sebagian besar poinnya, kecuali bagian “orang yang sering memakai LLM sudah tahu bahwa itu tidak boleh dilakukan”

    Saat ini adopsi LLM sedang didorong ke seluruh organisasi dan tim, dan ada banyak, mungkin bahkan mayoritas, orang yang memakai LLM setiap hari tetapi belum pernah menyentuh hal teknis seperti harness

    Bagi orang-orang seperti itu, perilaku yang dibahas di sini adalah masalah besar

  • Sedikit terkait, tetapi saya ingin melihat harness yang memakai ed sebagai alat default untuk membaca/mengedit file. Toh separuh bash yang dijalankan Claude terlihat seperti sed, dan sepertinya akan membantu kalau ed bisa mempertahankan state

    Apa yang harus dilakukan saat editor penuh memakan terlalu banyak bandwidth^H token? Pakai editor standar, ed

  • Ini terasa lebih seperti membuat pekerjaan LLM menjadi semacam orang-orangan sawah

    Untuk tugas pengeditan, seharusnya hanya perintah edit terprogram yang diizinkan, dan teks tidak boleh melewati LLM. LLM seharusnya menganalisis teks lalu mengeluarkan perintah untuk mencapai tujuan berdasarkan umpan balik

  • Di HN ada kecenderungan menafsirkan hasil se-negatif mungkin. Mungkin karena ini terasa seperti ancaman terhadap pekerjaan dan identitas mereka

    Kenyataannya, jika diminta mengedit dokumen dengan cara membaca lalu mengucapkan ulang seluruh dokumen sambil memasukkan perubahan, manusia bisa menghasilkan hasil yang lebih buruk daripada degradasi 25%. Memang manusia bisa mencapai degradasi 0%, tetapi itu hanya mungkin jika ia menerima dokumen itu ratusan kali sampai menghafalnya. Padanan hal ini pada LLM adalah pelatihan, dan jika dokumen itu dilatih ke dalam LLM maka dalam kasus ini ia bisa setara dengan editan manusia yang menghafal dokumen tersebut

    Namun itu bukan inti persoalannya. Karena LLM mirip manusia dalam hal ini, harness seharusnya dirancang agar LLM mengedit lewat pencarian dan perubahan yang presisi, seperti cara manusia mengedit dokumen. Semua coding agent mengedit seperti itu, jadi makalah ini tidak terlalu relevan

  • Entah karena keterbatasan sumber daya atau demi penyederhanaan, makalah seperti ini sayangnya nilainya turun karena metodologinya sulit dipahami

• Seperti yang sudah saya katakan sejak lama, melapisi teks apa pun dengan AI akan menurunkan kualitasnya, dan efeknya terakumulasi semakin sering diulang

  Istilah yang paling saya suka untuk ini adalah “semantic ablation”: https://www.theregister.com/software/2026/02/16/semantic-abl...

  • Saya menyebutnya regresi menuju kecerdasan rata-rata
  • Saya penasaran apakah “semakin sering diulang” itu maksudnya diulang dalam sesi yang sama, atau setiap kali dalam sesi baru atau jendela konteks baru

• Intinya adalah “delegasi memerlukan kepercayaan. Harus ada harapan bahwa LLM akan menyelesaikan tugas dengan setia tanpa memasukkan kesalahan ke dalam dokumen”, dan inilah alasan mengapa harness dan ritual prompt yang menulis puluhan file Markdown tidak bekerja sebaik iklannya. Pada praktiknya ini hampir seperti pseudosains yang diberi nama agent engineering

  Agent engineering pada akhirnya hampir sama saja dengan apa yang disebut prompt engineering, hanya saja sekarang prompt-nya tersebar di puluhan file Markdown dan direktori

• Ini adalah hal paling tidak mengejutkan yang baru-baru ini saya baca tentang LLM

  LLM mirip meme JPEG. Setiap kali disimpan sebagai JPEG, kualitasnya turun sedikit demi sedikit sampai akhirnya tak bisa dikenali lagi

  Bedanya, pada LLM titik awalnya adalah niat. Setiap kali sesuatu melewati LLM, niat itu terdegradasi, dan dalam kasus seperti makalah ilmiah yang presisi, nuansa halus dan ketelitian sedikit demi sedikit hilang saat diparafrasekan ulang

  LLM adalah mesin regresi menuju rata-rata. Semakin konteks atau beban kerja yang sedang ditangani keluar dari cakupan pelatihannya, semakin kuat kecenderungannya menarik semua itu menuju keadaan keseimbangan abstrak yang seragam

  • Saya benar-benar merasakan ini saat coding dengan LLM. Setelah ngebut mengerjakan fitur, saya merasa sudah cukup hati-hati, tetapi belakangan saat melihat potongan kode kecil secara detail, sering ada momen “ya ampun”

    Lalu saya harus menghabiskan beberapa jam untuk meninjau semuanya lagi dengan cermat dan memperbaiki bagian yang tidak jadi seperti yang saya inginkan, bagian yang saya jelaskan kurang jelas, atau bagian tempat kebiasaan aneh LLM muncul

    Kualitas kode itu sendiri penting, tetapi saya justru khawatir pada masalah kompresi berulang ini. Jika codebase bersih dan model mental saya mutakhir, LLM bisa membantu mengerjakan fitur dengan cepat tanpa membuat codebase berantakan. Tetapi begitu LLM mulai mengotori codebase, kesalahan atau salah paham masa lalu menumpuk, dan kemungkinan ia makin sering salah jadi lebih besar. Karena itu saya baru merasa aman memakai LLM lagi setelah semuanya “dipulihkan” ke keadaan yang benar

  • Kasus ketika hasil ini benar-benar menarik dan relevan adalah saat coding agent memecah file sumber besar menjadi beberapa file kecil. Opus dan Claude Code cenderung mencoba melafalkan potongan panjang source code dari ingatan lalu menaruhnya ke file baru, alih-alih memakai operasi seperti copy/paste sebagaimana manusia melakukannya

    Memindahkan file sedikit lebih mudah. Kadang LLM tetap mencoba mengucapkan ulang file dari ingatan, tetapi jika disuruh memakai git mv lalu memperbaiki error kompilator, biasanya hasilnya cukup baik

    Sebaliknya, pengeditan biasa umumnya bekerja baik jika model dan konfigurasi alatnya masuk akal. Qwen3.6 27B pun cukup oke untuk tingkat ini. Untuk perubahan di tempat, kita juga bisa meninjau perubahan tak terduga dengan git diff

  • Ada juga permainan anak-anak yang menunjukkan ini: https://en.wikipedia.org/wiki/Telephone_game

  • Seorang rekan menyebut LLM sebagai “lapisan omong kosong”. Bukan sepenuhnya untuk merendahkan, tetapi untuk menekankan bahwa setiap kali sesuatu dilewatkan melalui LLM, hasil di sisi lain bisa berbeda dari yang diharapkan atau diinginkan

    Ini mirip seperti menerima informasi online yang katanya pernah dilihat seseorang yang sudah minum beberapa gelas di bar. Bisa saja benar, tetapi risikonya salah juga cukup besar

    Misalnya, Anda sebaiknya tidak memakai LLM untuk mengumpulkan data lewat pemanggilan API lalu membuat laporan. Itu sama saja melewatkan data yang deterministik melalui lapisan omong kosong, sehingga hasilnya tidak bisa dipercaya. Sebaliknya, LLM lebih baik dipakai untuk menulis kode yang menghasilkan keluaran deterministik dari data deterministik

    Saya juga pernah melihat rekan kerja menyuruh LLM merangkum data deterministik dari API, lalu laporannya meleset separah saat ia kebetulan benar. Tergantung apa yang sedang Anda lihat, ini bisa jadi risiko yang katastrofik

  • Saya mengalami ini saat mengedit CV. LLM menghapus semua hal yang membedakan CV saya dari tumpukan insinyur junior rata-rata dengan pengalaman generik. Semua hal yang spesial, unik, atau berbeda pada akhirnya diganti dengan frasa umum

    Tentu saja saya tidak memakai hasil itu, tetapi sangat membuat frustrasi karena LLM terus bersikeras bahwa versinya lebih baik daripada yang lama

    LLM jauh lebih berguna untuk usulan revisi yang sangat kecil, misalnya satu kalimat atau tiga kalimat, daripada menentukan arah seluruh CV

• Masalahnya adalah kita meminta LLM melakukan terlalu banyak hal. Agent seharusnya dirancang agar memakai LLM sebagai lapisan setipis mungkin untuk menerjemahkan niat bahasa alami ke dalam proses deterministik, dan bolak-balik dengan LLM harus diminimalkan

  • Ini akan jadi jelas bagi siapa saja yang mencoba melakukan sesuatu yang sedikit lebih kompleks. Jika Anda membangun pipeline yang menggabungkan alur pra-pemrosesan, penargetan berbasis semantik, dan pemanggilan konteks seminimal mungkin dengan API LLM, Anda bisa mendapatkan langkah otomasi yang kuat

    Jika digabungkan dengan tahap verifikasi terpisah, LLM berubah dari mainan menjadi alat yang berguna

  • Selama manusia tidak ikut berada di dalam proses iteratif semacam ini, barulah itu menjadi proses yang benar-benar otomatis

• Saya biasanya menginstruksikan agent agar memperlakukan penulisan dokumen hanya sebagai tahap rendering terakhir. LLM sangat mahir mengumpulkan dan merangkai pengetahuan yang tersebar, jadi saya lebih suka pengetahuan disimpan dalam bentuk ide dan fakta yang bisa dikombinasikan

  Pendekatan yang benar-benar berhasil adalah memberi agent sebuah direktori dan menyuruhnya membuat file Markdown terpisah untuk setiap fakta atau temuan yang ditemukan. Setiap file juga diminta memiliki metadata di bagian awal agar mudah dicari

  Dengan begitu, sebagian besar pekerjaan dipisahkan dari bentuk kusut “meneliti dan menyimpan sambil terus menulis dalam format dokumen akhir” menjadi tugas yang lebih kohesif: “meneliti fakta dan temuan yang membantu dokumen” dan “merakit dokumen”

  Ini bukan solusi sempurna, tetapi seperti saat manusia bekerja, temuan-temuan itu jadi jauh lebih bisa dipakai ulang

• Bukankah ini juga berlaku untuk manusia? Itulah sebabnya anak-anak memainkan “permainan telepon” untuk melihat bagaimana pesan rusak. Solusinya adalah menyediakan satu sumber kebenaran tunggal

• Saya sedang membuat alat untuk melawan jenis degradasi seperti ini: https://github.com/JigSpec/JigSpec

• Saya sangat menyukai metode evaluasi di sini. Caranya adalah menguji fidelitas dengan membuat rantai langkah reversibel lalu membawanya bolak-balik

  Kesan yang saya dapat adalah bahkan pada tugas yang tampaknya mudah ditangani komputer, model terdepan tetap mengakumulasi kesalahan

  Saya penasaran apakah hasil yang lebih kuat di Python hanya produk dari evaluasi yang memang khusus Python, atau juga berlaku untuk bahasa umum lain yang lazim dipakai, dan apakah ada unsur tertentu dalam proses pelatihan yang menyebabkannya

• Kita tampaknya sudah tahu bahwa model tidak gagal karena banyak kesalahan kecil, semacam “seribu sayatan”, melainkan karena kegagalan fatal: pada beberapa putaran mereka bisa merekonstruksi hampir sempurna, lalu pada putaran lain kehilangan 10–30 poin atau lebih sekaligus

  Hal yang sama berlaku untuk fakta bahwa degradasi pada model lemah terutama berasal dari penghapusan isi, sedangkan degradasi pada model terdepan berasal dari perusakan isi. Itulah sebabnya kita terus mengutak-atik harness, temperatur, dan hal-hal semacam itu