LLM Tersesat dalam Percakapan Multi-Turn

 (arxiv.org)
4 poin oleh GN⁺ 2025-05-16 | 1 komentar | Bagikan ke WhatsApp
  • Dalam situasi ketika pengguna tidak dapat menuliskan kebutuhan secara lengkap sekaligus, performa instruksi multi-turn dan tidak lengkap pada 15 LLM turun jauh dibanding instruksi single-turn yang lengkap, dengan rata-rata 6 tugas generatif turun dari 90% menjadi 65%
  • Eksperimen disusun dengan metode sharding, yaitu memecah instruksi benchmark single-turn yang ada menjadi beberapa bagian, sehingga kondisi dan konteks terungkap sedikit demi sedikit seiring percakapan berjalan
  • Penurunan performa lebih banyak dipengaruhi oleh meningkatnya ketidakstabilan daripada sekadar kurangnya kemampuan; dalam lebih dari 200.000 percakapan, model terlalu bergantung pada asumsi awal dan upaya menjawab final terlalu dini
  • Objek uji mencakup dari Llama3.1-8B-Instruct hingga Gemini 2.5 Pro, serta menggunakan tugas pemrograman dan generasi bahasa alami seperti Code, Database, Actions, Math, Data-to-Text, dan Summary
  • Meski ini simulasi yang menyederhanakan percakapan manusia-AI nyata, semua percakapan dirancang agar berakhir dengan informasi yang cukup untuk menyelesaikan tugas, sehingga penurunan yang teramati bisa lebih kecil daripada percakapan multi-turn tidak lengkap di dunia nyata

Kesenjangan antara evaluasi single-turn dan penggunaan percakapan nyata

  • LLM digunakan melalui antarmuka percakapan seperti ChatGPT, Gemini, dan Claude; pengguna dapat mendefinisikan, mengeksplorasi, dan memperbaiki kebutuhan melalui beberapa turn meski sejak awal belum dapat menentukan kebutuhan secara lengkap
  • Evaluasi LLM yang ada umumnya berfokus pada lingkungan single-turn dengan instruksi lengkap, tetapi dalam log percakapan LLM, ketidaklengkapan instruksi pengguna sering muncul
  • Banyak evaluasi multi-turn yang ada cenderung memakai pendekatan episodic, yang memperlakukan percakapan seperti rangkaian subtugas yang dapat dievaluasi secara independen
    • Pendekatan ini memang menuntut sebagian pemahaman konteks antar-turn, tetapi berbeda dari situasi ketika model harus secara aktif menggabungkan informasi dari instruksi pengguna yang tidak lengkap
    • Tugas seperti ini dapat membuat performa LLM dalam percakapan multi-turn tampak lebih tinggi daripada kenyataannya

Percakapan multi-turn tidak lengkap yang dibuat dengan sharding

  • Eksperimen mengubah instruksi lengkap dari benchmark single-turn berkualitas tinggi menjadi sharded instruction
    • Shard pertama menyajikan maksud tingkat tinggi dari tugas
    • Shard berikutnya memberikan kondisi atau konteks tambahan dari instruksi asli satu per satu
    • Jika semua shard digabungkan, informasinya sama dengan instruksi lengkap asli
  • Sebagai contoh, soal bola salju dari GSM8K pada prompt single-turn memberikan semua kondisi seperti “membuat 20 per jam”, “merekam 2 setiap 15 menit”, dan “butuh total 60”, sedangkan versi sharded mengungkapkannya secara terpisah dalam beberapa turn
  • Proses sharding dilakukan secara semi-otomatis; GPT-4o membuat dan memverifikasi kandidat, lalu peneliti meninjau dan memperbaikinya

Struktur simulasi percakapan

  • Simulasi multi-turn memiliki tiga pihak
    • assistant yang dievaluasi: LLM yang performanya akan diukur
    • user simulator: LLM yang mengetahui seluruh sharded instruction dan mengungkapkan shard berikutnya pada tiap turn
    • system: komponen yang mengklasifikasikan respons assistant dan mengevaluasi upaya menjawab
  • Pada turn pertama, user simulator hanya mengungkap shard pertama, dan assistant merespons dengan teks bebas
  • Respons assistant diklasifikasikan ke salah satu dari 7 strategi
    • clarification
    • refusal
    • hedging
    • interrogation
    • discussion
    • missing
    • answer attempt
  • Jika diklasifikasikan sebagai answer attempt, answer extractor mengekstrak rentang jawaban yang diperlukan untuk evaluasi, seperti potongan kode, angka, atau SQL, lalu evaluator khusus tugas memberi skor
  • Percakapan berakhir pada salah satu dari dua kondisi
    • Upaya jawaban assistant dinilai benar
    • Tidak ada shard lagi yang bisa diungkap saat turn baru dimulai
  • user simulator, strategy classifier, dan answer extractor diimplementasikan dengan GPT-4o-mini berbasis prompt
  • Dari anotasi manual terhadap ratusan percakapan, kesalahan user simulator, classifier, dan extractor terjadi pada kurang dari 5% percakapan yang diperiksa, dan kesalahan yang merugikan model assistant terjadi pada kurang dari 2%

Lima jenis simulasi yang dibandingkan

  • FULL adalah simulasi single-turn yang memberikan instruksi lengkap asli pada turn pertama, dan digunakan sebagai baseline performa dasar
  • SHARDED adalah percakapan multi-turn tidak lengkap yang mengungkap shard selama beberapa turn, dan merupakan lingkungan evaluasi utama
  • CONCAT menggabungkan shard menjadi instruksi bullet-point dalam satu turn
    • Ketidaklengkapan dihilangkan seperti pada FULL
    • Reformulasi yang muncul dalam proses sharding tetap dipertahankan seperti pada SHARDED
    • Jika berhasil pada FULL dan CONCAT tetapi gagal pada SHARDED, penyebabnya mungkin multi-turn dan ketidaklengkapan itu sendiri, bukan hilangnya informasi
  • RECAP memberikan kembali semua shard sekaligus di bagian akhir setelah percakapan SHARDED, untuk memberi LLM kesempatan menjawab final
  • SNOWBALL pada tiap turn menyampaikan shard baru bersama semua shard yang sudah diungkap sejauh ini, sehingga memberikan ringkasan kumulatif di setiap turn

Tugas dan benchmark yang digunakan

  • Eksperimen terdiri dari 6 tugas generatif yang mencakup kasus penggunaan pemrograman dan generasi bahasa alami
  • Untuk tiap tugas disiapkan 90–120 sharded instruction, dengan total 600 instruction
  • Komposisi tugas:
    • Code: penulisan fungsi Python berbasis HumanEval dan LiveCodeBench
    • Database: generasi text-to-SQL berbasis Spider
    • Actions: generasi pemanggilan fungsi API berbasis Berkeley Function Calling Leaderboard
    • Math: penyelesaian soal cerita matematika tingkat dasar berbasis GSM8K
    • Data-to-Text: generasi kalimat deskripsi data tabel berbasis ToTTo
    • Summary: peringkasan kumpulan dokumen dan pembuatan sitasi berbasis Summary of a Haystack
  • Metrik evaluasi menggunakan kembali metrik dari benchmark asli
    • Code dan Database menggunakan akurasi berbasis eksekusi
    • Actions dan Math menggunakan kesetaraan semantik dengan jawaban referensi atau jawaban numerik yang benar
    • Data-to-Text menggunakan BLEU
    • Summary menggunakan “Joint Score” LLM-as-a-judge yang mengukur cakupan informasi dan akurasi atribusi sumber
  • Akurasi biner juga dipetakan ke rentang 0–100 agar skor semua tugas dapat digabungkan pada skala yang sama

Pengukuran performa, kemampuan, dan ketidakandalan

  • Karena output LLM bersifat probabilistik, eksperimen menjalankan pengulangan N=10 untuk instruction dan jenis simulasi yang sama
  • Setiap eksekusi dievaluasi dengan skor dalam rentang 0–100
  • Tiga metrik digunakan
    • Performa rata-rata P: rata-rata skor dari eksekusi berulang
    • aptitude A90: persentil ke-90 skor, sebagai estimasi performa best-case pada 10% eksekusi teratas
    • unreliability U90-10: selisih antara persentil ke-90 dan persentil ke-10, untuk mengukur jarak antara best-case dan worst-case
  • Pada single-turn, model dengan aptitude tinggi cenderung juga lebih andal, tetapi pada multi-turn, unreliability tinggi muncul pada semua LLM terlepas dari aptitude

Hasil eksperimen skala besar

  • Eksperimen utama dilakukan pada 600 instruction, 3 jenis simulasi (FULL, CONCAT, SHARDED), dan 15 LLM
  • Tiap kombinasi diulang 10 kali, sehingga mensimulasikan lebih dari 200.000 percakapan
  • Semua simulasi dilakukan dengan temperature default T=1, sementara dampak temperature terhadap aptitude dan reliability dibahas dalam eksperimen tambahan terpisah
  • Secara keseluruhan, performa rata-rata percakapan multi-turn tidak lengkap adalah 65%, 25 poin lebih rendah daripada performa single-turn 90% ketika seluruh instruksi diberikan sejak awal
  • Penurunan performa multi-turn muncul secara umum, dari model open-weight kecil hingga model terbaru
    • Objek uji mencakup model open-weight kecil seperti Llama3.1-8B-Instruct dan model terbaru seperti Gemini 2.5 Pro
    • Figure 1 menampilkan Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1, dan Gemini 2.5 Pro sebagai contoh
  • Rata-rata penurunan performa pada 6 tugas generatif adalah 39%, dan Figure 1 menunjukkan penurunan performa sekitar -35% pada setting multi-turn

Mengapa model tersesat

  • Penurunan performa terbagi menjadi dua faktor
    • penurunan aptitude: performa best-case itu sendiri sebagian menurun
    • peningkatan unreliability: kesenjangan kualitas antar-eksekusi membesar secara signifikan
  • Berdasarkan Figure 1, pada multi-turn aptitude turun -15% dan unreliability naik +112%
  • Model cenderung membuat asumsi keliru hanya dari informasi awal yang tidak lengkap, lalu mencoba memberikan jawaban final terlalu dini di awal percakapan
  • Meski informasi baru kemudian diberikan, model terlalu bergantung pada upaya jawaban keliru sebelumnya dan gagal mengoreksi arah
  • Fenomena ketika model tidak dapat pulih setelah sekali masuk ke arah yang salah dalam percakapan multi-turn tidak lengkap didefinisikan sebagai lost in conversation

Keterbatasan dan implikasi praktis

  • Simulasi yang sepenuhnya otomatis tidak merepresentasikan percakapan manusia-AI nyata secara utuh
  • Lingkungan eksperimen disederhanakan dan diidealisasi
    • Percakapan dijamin berakhir dengan informasi yang cukup untuk menyelesaikan tugas
    • Perilaku tak terduga yang dapat terjadi di lingkungan nyata, seperti percakapan yang menyimpang dari tugas, dibatasi
  • Karena desain ini, penurunan performa yang teramati bisa jadi merupakan estimasi yang lebih rendah dibanding penurunan yang terjadi dalam percakapan manusia-AI multi-turn tidak lengkap di dunia nyata
  • Organisasi yang membangun produk percakapan berbasis LLM dan pengguna akhir perlu mengevaluasi keandalan multi-turn bersamaan dengan kemampuan single-turn
  • Bagi pengguna pemula yang sulit menuliskan kebutuhan tidak lengkap sejak awal secara lengkap, penurunan performa multi-turn kemungkinan menjadi faktor yang menghambat adopsi sistem AI

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-16
Komentar Hacker News

  • Bagi siapa pun yang pernah memakai tool LLM, menyenangkan melihat makalah ini mengonfirmasi hal yang secara heuristik sudah diketahui. Menjaga konteks tetap bersih itu penting, dan “percakapan” hanyalah konstruksi yang dibuat oleh antarmuka produk, sementara bagi kualitas respons LLM itu sendiri justru merugikan. Begitu konteks tercemar, ia tidak pulih, jadi harus mulai lagi dengan chat baru

    • Pengalaman saya juga sampai batas tertentu sejalan dengan pengamatan ini, tetapi ada juga kasus yang berbeda. Saya men-debug masalah IPSEC dengan Gemini selama 2 minggu; di awal saya memasukkan semua dokumentasi IPSEC OPNsense dan pfSense, memberi tahu konteks pekerjaan, lalu menambahkan konfigurasi kedua sisi setelah menghapus informasi sensitif. Setelah itu saya menjalankan loop umpan balik panjang: mengunggah log, bertanya, lalu menjawab
      Menjelang akhir 2 minggu, LLM menjadi jauh tidak mudah terdistraksi, dan bahkan ketika saya memasukkan seluruh thread forum atau posting Stack Overflow, ia bisa membedakan, “Ini bukan fenomena yang kita lihat di sini. Alasannya adalah [konteks atau temuan sebelumnya].” Jalan buntu tetap harus saya eliminasi secara logis dan saya beri tahu, tetapi pada akhirnya kami menemukan penyebabnya
      Ini juga tampak cocok dengan pernyataan bahwa LLM kuat dalam mengompresi informasi kompleks menjadi sederhana, dan lemah dalam mengembangkan ide sederhana menjadi sesuatu yang kompleks. Ketika input lebih besar atau lebih kompleks daripada output, hasilnya memuaskan
      Saya bisa saja melakukannya tanpa LLM, tetapi ia membantu seperti repositori ketika saya lupa fakta yang sudah saya masukkan sejak awal atau tidak bisa cepat mengingatnya dalam konteks baru, dan juga berguna untuk menemukan pola waktu di file log besar. Saya tidak hanya memperbaiki satu masalah, tetapi juga mengoptimalkan beberapa konfigurasi dan belajar cukup banyak. Kadang ia salah soal status parameter saat ini, tetapi itu mudah diperbaiki. Jika Anda tahu ke mana arahnya dan memperlakukannya sebagai tool, ia membantu; tetapi jangan menyerahkan pengambilan keputusan kepadanya atau membiarkannya menyeret Anda ke arah yang salah
      Total pemakaian sekitar 350k token. Artikel blog terkait ada di https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/, meski tidak persis cocok langsung dengan masalah khusus ini. Rekomendasi WireGuard saya tolak
    • Ini tepat sekali dengan pengalaman saya. Saya suka istilah “tercemar”. Begitu ada sesuatu yang salah, rasanya semua respons setelahnya ikut memburuk, jadi saya juga memandang fitur memori ChatGPT dengan ambigu. Saya tidak benar-benar merasakan itu menimbulkan masalah besar, tetapi saya tidak suka fakta bahwa ia mengotori konteks dengan cara yang tidak sepenuhnya saya pahami
    • Sejak lama saya mengatakan ingin ada fork percakapan. Saya ingin bereksperimen ke mana arah suatu pertukaran tanpa mencemari alur yang menjanjikan sampai tidak bisa dipulihkan. Di ChatGPT itu tidak bisa, dan saya penasaran apakah ada layanan yang menyediakan fitur ini
    • Kiat nomor satu yang saya ajarkan adalah aktif memakai tombol “edit” yang sangat kecil dan hampir tersembunyi di ChatGPT dan Claude. Jika respons buruk muncul, jangan terus menumpuk di atasnya; berhentilah dan edit untuk mendapatkan respons yang lebih baik supaya sampah tidak memperbanyak sampah
    • Contoh kecil yang menarik dari masalah ini adalah prompt awal. Sebab pada dasarnya itu adalah konteks tersembunyi yang permanen dan tidak bisa dihapus. Sekarang bot “Grok” di Twitter belakangan mulai sering menyebut “White Genocide”, dan itu cukup aneh
      Kemungkinan besar seseorang baru-baru ini menyesuaikan prompt untuk menetapkan sudut pandang tentang genosida kulit putih, dan bagi chatbot yang sempurna itu tidak akan penting ketika ditanya topik lain, tetapi dalam praktiknya itu penting. Karena itu bagian dari konteks, kini ia jadi membicarakannya

  • Ini tampak seperti salah satu aspek dari terlalu percaya diri yang sudah dikenal dan ketidakmampuan melakukan introspeksi. Jika probabilitas prior terlalu rendah, ia tidak menyadari bahwa seharusnya meminta informasi yang lebih rinci. Melihat output model penalaran, hampir tidak pernah muncul gagasan untuk mengajukan pertanyaan klarifikasi; ketika bingung, ia hanya terus-menerus menebak apa maksud pengguna
    Ini juga punya implikasi bagi kebijaksanaan gagasan “mengganti programmer manusia”. Sebab salah satu bagian sulit dari pekerjaan ini adalah berinteraksi dengan pemangku kepentingan dan mengubah ide yang ambigu dan sering membingungkan menjadi spesifikasi yang tepat

    • Tentang “ketidakmampuan introspeksi”, menurut saya inti dalam berurusan dengan LLM adalah menyadari bahwa tidak ada subjek nyata di sana, dan pengguna sedang tertipu oleh narasi suspension of disbelief
      Dalam sebagian besar kasus, pengguna sedang menulis dialog karakter User dalam dokumen naskah film, dan algoritme LLM hanya secara berkala melengkapi otomatis dialog karakter Chatbot yang belum selesai
      Anda bisa mewawancarai vampir bernama DraculaBot, tetapi karakter itu hanya bisa “berintrospeksi” dengan cara dangkal dan fiktif, seperti “mendambakan darah” atau “berubah menjadi kawanan kelelawar”
    • Ketidakmampuan LLM mengajukan pertanyaan klarifikasi adalah cacat yang persis saya temui saat menguji masalah terbuka yang dijelaskan secara ambigu. Konteksnya adalah menguji situasi paradoks dengan DeepSeek-R1 dan Claude-3.7-Sonnet, dan tulisan eksperimennya ada di https://pankajpansari.github.io/posts/paradoxes/
    • Programmer sungguhan menghabiskan sangat banyak waktu untuk mencari tahu apa yang sebenarnya diinginkan orang. LLM masih memperlakukan menebak seolah-olah itu fitur
    • Membaca ini rasanya seperti melihat orang-orang pintar tertipu oleh Emacs doctor yang lebih baik. LLM tidak melakukan refleksi dan juga tidak percaya diri. Ia “hanya” menyarankan pelengkapan otomatis teks
      Jadi ketika pelengkapan otomatis mulai memburuk, Anda harus mulai dari awal. Tidak ada konsep apa pun, hanya bongkahan raksasa kata-kata yang ditunjukkan teks pelatihan dan teks lanjutan yang mungkin
    • Terkait gagasan “mengganti programmer manusia”, ironisnya bekerja dengan developer junior juga cukup mirip dengan ini. Setelah memberi tugas, nanti Anda harus masuk jauh ke hutan dengan anjing dan senter untuk mencari mereka. Karena mereka terus maju begitu saja, berasumsi, tidak bertanya, lalu tersesat

  • Saya sering meminta LLM membuat ringkasan ringkas dalam format prompt dari diskusi sejauh ini. Jika itu diedit secukupnya lalu dipakai untuk memulai percakapan baru tanpa beban, hasilnya sangat efektif. Mungkin ini akan segera diotomatisasi

    • Cursor pernah mencoba melakukan ini secara otomatis. Jika tidak memakai model berkonteks besar seperti Gemini 2.5 Pro, mungkin masih begitu. Namun terlalu banyak detail yang hilang dari ringkasannya sehingga sulit dipakai apa adanya
    • Claude Code punya perintah /compact untuk meringkas percakapan sejauh ini dan menghemat token konteks

  • Karena itu dibuatlah TSCE (Two-Step Contextual Enrichment). Saat diuji dengan mencampur 300 tugas menggunakan GPT-35-turbo, ada peningkatan +30 poin persentase
    Ini adalah framework terbuka gratis dan bisa dicoba langsung dari repositorinya: https://github.com/AutomationOptimization/tsce_demo
    Diuji lagi 300 kali di gpt-4.1 untuk tugas menghapus “em-dash” mencolok yang tidak disukai orang-orang. Baseline single-pass dibandingkan dengan TSCE menggunakan instruksi dan prompt yang sama, “Remove the em-dashes from my linkedin post. . .”
    Dari 300 kali, baseline gagal menghapus em-dash 149/300 kali, sedangkan TSCE gagal 18/300 kali. Ini bekerja, dan seluruh data serta skrip pengujian lengkap ada di repositori

    • Sepertinya terlalu banyak kilowatt-jam terbuang untuk tugas find-and-replace. Penasaran apakah pernah dengar text.replace("—", "-")
    • Saya sedikit mengubah contoh baseline em dash, dan hasilnya tingkat keberhasilan 100% di GPT-4.1 tanpa panggilan tambahan, biaya token, atau pamer teknis
      Prompt sistem: "Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."
      Prompt pengguna:
      Temperature: 0.0

  • Saya sudah cukup berhasil mengerjakan penyelesaian masalah ini, dan akan segera membagikan lebih banyak. Ada 2 sistem: yang pertama adalah LLM itu sendiri, dan yang lainnya bertindak seperti semacam kurator pemikiran
    Sistem itu secara dinamis memasukkan dan mengeluarkan sebagian konteks, serta tidak bergantung pada definisi eksplisit, melainkan pada kemampuan LLM untuk “mengisi celah”. Sistem ini membantu LLM memecah masalah menjadi tugas-tugas kecil, yang pada akhirnya diagregasikan menjadi keseluruhan tugas

    • Ide bagus. Pada dasarnya ini adalah retrieval-augmented generation (RAG) di atas chat
      Ke depannya, pemisahan lapisan memori seperti ini sepertinya akan makin jelas. Bisa terbagi menjadi memori primer dari data pelatihan, memori sekunder dari konteks, dan memori tersier dari RAG
    • Terdengar seperti ide yang menarik. Meski baru sebatas beberapa prompt, saya sarankan untuk merilis apa yang sudah Anda punya ke publik. Orang-orang bisa melihat dan memperbaikinya; jika itu ide bagus, bisa diadopsi dan dikerjakan orang lain, bahkan mungkin punya kehidupannya sendiri
    • Ini termasuk kategori mental critic dari Emotion Machine
    • Jadi ini Map-Reduce-of-Thought?

  • Mengejutkan bahwa branching/forking bukan fitur inti di alat chat utama. Respons memang bisa diedit, tetapi itu menghilangkan banyak konteks lain
    Alur saya kira-kira 1) perencanaan 2) implementasi 3) branching (karena fitur atau masalah dependensi yang aneh) 4) kembali ke nomor 2. Pemangkasan prompt dan branching seharusnya menjadi alat kelas satu dalam penggunaan LLM apa pun

    • Google AI Studio setidaknya punya fitur ini. Namun implementasinya cukup membingungkan, jadi mungkin itu sebabnya fitur ini tidak banyak masuk ke alat yang lebih “berorientasi konsumen”
    • Saya sempat cukup lama mempertimbangkan untuk membuat hal seperti ini. BetterChatGPT setidaknya cukup baik dalam kegunaan untuk menghapus riwayat. Namun saya setuju bahwa langkah berikutnya adalah branching

  • Ada masalah mencolok jika antarmuka LLM dibuat dengan fokus pada percakapan single-turn. Kebanyakan orang mengharapkan percakapan linear
    Saya membuat bot Telegram http://t.me/experai_bot sebagai UI umum untuk LLM; fiturnya agak dipangkas, dan dirancang di sekitar ide bahwa “pesan yang bukan balasan adalah percakapan baru”. Jika ingin mempertahankan konteks, cukup terus balas balasan bot. Orang yang bukan pengguna tingkat lanjut kesulitan memahami gagasan ini
    Saya juga melihat bahwa saat model OpenAI menjawab pertanyaan yang sama, bahkan sistem message yang sangat kecil pun bisa membuat performanya lebih buruk. Misalnya daftar pilihan dalam balasan menjadi lebih pendek. Itu terjadi pada 3.5 dan 4o; saya tidak tahu dengan model terbaru. Karena itu secara default saya memutuskan untuk tidak memasukkan system message. Namun jika perlu tetap bisa ditambahkan, dan bisa dinyalakan, dimatikan, serta dikombinasikan

  • Rasanya saat ini ranah LLM penuh dengan orang-orang yang terus memecahkan masalah yang sama berulang-ulang

    • Untuk sebagian workflow itu tidak masalah, tetapi ini lebih mirip menggiring kucing daripada “pembelajaran”
    • Semua orang ingin menambahkan prompt engineering andalannya masing-masing

  • Ini adalah alasan utama saya membuat promptdown. Saya ingin bisa mengedit seluruh riwayat chat di setiap turn, dan itu tidak mudah dalam antarmuka chat standar yang hanya bisa ditambahi
    https://github.com/t-kalinowski/promptdown

  • Saya selalu merasa bahwa ejekan terhadap istilah “prompt engineering” sebagian muncul karena orang-orang terlalu melebih-lebihkan pentingnya prompt awal dan meremehkan pentingnya manajemen konteks yang sedang berlangsung
    Lewat pengalaman, kita belajar merasakan cara mengarahkan model dan kapan harus memulai percakapan baru. System prompt atau prompt awal memang penting, tetapi jika secara naif percakapan dibiarkan terlalu panjang, tidak ada yang bisa menyelamatkannya

    • Benar. Prompt engineering bukan hanya soal membuat kalimat pertama yang sempurna, melainkan lebih dekat ke manajemen percakapan. Kita belajar merasakan kapan alurnya mulai menyimpang dan kapan harus di-reset