1 poin oleh GN⁺ 2023-09-04 | 1 komentar | Bagikan ke WhatsApp
  • Chatbot percakapan jangka panjang sulit secara stabil mencerminkan inti interaksi masa lalu dalam respons, meskipun memiliki jendela konteks panjang; studi ini membahas cara mengurangi masalah konsistensi dengan memori ringkasan rekursif
  • Prosedur intinya adalah membuat memori awal dari percakapan singkat, lalu setiap kali sesi ditambahkan, memori sebelumnya dan percakapan baru diringkas bersama untuk memperbaruinya menjadi memori terbaru
  • Pendekatan berbasis pencarian bergantung pada retriever untuk menemukan ujaran masa lalu yang diperlukan secara akurat, sementara pendekatan berbasis memori yang ada dapat terganggu kualitas responsnya oleh informasi usang yang belum diperbarui
  • Dalam eksperimen LLM publik dan tertutup seperti Llama, ChatGLM, dan OpenAI GPT-3.5-Turbo, baik evaluasi otomatis maupun evaluasi manusia menunjukkan konsistensi percakapan jangka panjang yang lebih tinggi dibanding pendekatan sebelumnya
  • Metode ini juga dapat digunakan bersama jendela konteks panjang atau LLM dengan retrieval augmentation, sehingga dapat menjadi pilihan praktis untuk menangani konteks percakapan yang sangat panjang tanpa sekadar memperpanjang seluruh riwayat percakapan

Konteks panjang saja tidak cukup untuk memori percakapan jangka panjang

  • LLM seperti GPT-4 dan ChatGPT dapat melakukan percakapan yang dinamis dan sesuai konteks di berbagai topik, tetapi dalam percakapan jangka panjang mereka bisa melewatkan informasi masa lalu dan menghasilkan respons yang tidak konsisten
  • Meski jendela konteks panjang memungkinkan seluruh riwayat percakapan diproses sebagai input, kemampuan untuk memahami interaksi masa lalu dan mengintegrasikan informasi inti ke dalam respons masih terbatas
  • Contoh umum yang memerlukan memori percakapan masa lalu adalah pendamping AI pribadi dan layanan bantuan kesehatan
    • Pendamping AI pribadi perlu mengingat percakapan sebelumnya untuk membangun hubungan
    • Layanan bantuan kesehatan harus mempertimbangkan seluruh riwayat pertanyaan pasien untuk memberikan hasil diagnosis
  • Dalam contoh Multi-Session Chat Dataset, ketika pengguna kembali menyebut topik “menggubah musik” sekitar 20 giliran kemudian, ChatGPT versi gpt-turbo-3.5-0301 menjawab bahwa dirinya adalah “model bahasa AI tanpa pekerjaan dalam arti tradisional”, sehingga menghasilkan respons yang tidak selaras dengan persona sebelumnya

Keterbatasan pendekatan berbasis pencarian dan berbasis memori

  • Pendekatan utama untuk memperkuat kemampuan percakapan jangka panjang terbagi menjadi pendekatan berbasis pencarian dan pendekatan berbasis memori
  • Pendekatan berbasis pencarian menyimpan ujaran masa lalu di repositori, lalu menggunakan retriever untuk menemukan riwayat yang paling relevan dengan percakapan saat ini dan memakainya dalam pembuatan respons
    • Keterbatasannya adalah sulit memperoleh retriever ideal yang dapat menangkap secara lengkap makna yang dibutuhkan oleh percakapan saat ini
  • Pendekatan berbasis memori merangkum percakapan masa lalu dengan model pembelajaran terpisah atau LLM yang kuat untuk menyimpan informasi inti
    • Jika mekanisme pembaruan berulang kurang memadai, informasi usang yang tersimpan dapat langsung merusak kualitas respons
  • MemoChat merekonstruksi riwayat percakapan masa lalu berdasarkan topik tiap pembicara, lalu mem-prompt LLM agar saat generasi melakukan pencarian dari memori terstruktur
  • MemoryBank mengusulkan mekanisme memori yang terlebih dahulu membuat ringkasan untuk setiap sesi percakapan, lalu mengompresnya menjadi ringkasan global
    • Jika memori yang tersimpan benar-benar tetap, sulit menjamin konsistensi dengan percakapan yang sedang berlangsung

Pembuatan memori yang diperbarui secara rekursif

  • Metode yang diusulkan adalah pendekatan plug-in sederhana yang membuat LLM itu sendiri menghasilkan ringkasan serta terus memperbarui dan meninjau konteks masa lalu agar menyimpan informasi real-time pembicara
  • Prosedurnya terdiri dari tiga tahap
    • LLM generatif menerima konteks percakapan singkat sebagai input dan menghasilkan ringkasan awal
    • Setelah itu, memori sebelumnya dan percakapan lanjutan digabungkan untuk terus memperbarui ringkasan atau memori baru
    • Chatbot menggunakan memori terbaru sebagai referensi utama untuk merespons percakapan saat ini
  • Karena ringkasan yang dihasilkan jauh lebih pendek daripada seluruh percakapan, konteks yang sangat panjang di berbagai sesi dapat ditangani tanpa memperbesar panjang input maksimum secara mahal
  • Percakapan jangka panjang didefinisikan sebagai Multi-Session Dialogue yang terdiri dari beberapa sesi
    • Menggunakan himpunan sesi masa lalu S = {S1, S2, ..., SN}, konteks percakapan sesi saat ini Ct, dan respons jawaban benar rt
    • Tujuannya adalah menghasilkan respons yang relevan dan sangat konsisten berdasarkan sesi masa lalu dan konteks saat ini
  • Memori Mi adalah memori yang tersedia saat sesi ke-i berakhir, dan keseluruhan proses didefinisikan sebagai proses sekuensial di mana setiap memori hanya bergantung pada sesi saat ini dan memori sebelumnya

Iterasi memori dan pembuatan respons

  • Metode yang diusulkan menugaskan dua pekerjaan kepada LLM apa pun
    • Iterasi memori: merangkum informasi inti secara rekursif mengikuti alur percakapan jangka panjang
    • Pembuatan respons berbasis memori: menggabungkan memori terbaru dan percakapan saat ini untuk menghasilkan respons yang tepat dan konsisten
  • Iterasi memori adalah proses memperoleh ringkasan yang konsisten dan mutakhir untuk digunakan chatbot
  • Sebagian studi sebelumnya memperbarui memori dengan menerapkan “operasi keras” seperti replace, append, dan delete pada ringkasan
    • Cara ini bergantung pada percakapan berkualitas tinggi yang diberi label operasi, mengganggu konsistensi semantik ringkasan, dan juga tidak cocok untuk pengelolaan jangka panjang
  • Metode yang diusulkan memasukkan konteks percakapan dan memori sebelumnya bersama-sama agar LLM menghasilkan memori atau ringkasan secara rekursif
    • Dengan memanfaatkan ringkasan sebelumnya, model dapat lebih baik mencerna konteks percakapan saat ini dan membuat memori berkualitas tinggi
  • Dalam contoh, setelah sesi pertama dibuat memori awal, dan setelah sesi kedua, informasi persona baru bahwa “bot baru-baru ini bergabung dengan gym baru yang beroperasi 24 jam” diintegrasikan ke dalam memori sebelumnya

Hasil eksperimen dan kemungkinan penerapan

  • Eksperimen diimplementasikan dengan LLM publik dan tertutup terbaru seperti Llama, ChatGLM, dan OpenAI GPT-3.5-Turbo
  • Performa percakapan jangka panjang terbukti lebih tinggi daripada pendekatan populer yang ada, baik dalam evaluasi otomatis maupun evaluasi manusia
  • Studi ini memverifikasi efektivitas penggunaan memori eksplisit dalam percakapan jangka panjang, serta bahwa memori yang dibuat dengan metode yang diusulkan lebih mudah dicerna oleh LLM
  • Jika dikombinasikan dengan in-context learning (ICL), kualitas respons dapat ditingkatkan lebih lanjut
    • Beberapa sampel dalam format (percakapan, memori, respons jawaban benar) ditunjukkan kepada LLM
    • Ini memungkinkan LLM memanfaatkan memori yang dihasilkan dengan lebih fleksibel
  • Pada text-davinci-003, skor BLEU meningkat sekitar +3%
  • Metode yang diusulkan melengkapi LLM berjendela konteks panjang seperti GPT-3.5-Turbo-16k dan LongLoRA-8k, serta LLM dengan retrieval augmentation seperti LLM-BM25 dan LLM-DPR
  • Kode publik tersedia di qingyue2014/Rsum

1 komentar

 
GN⁺ 2023-09-04
Komentar Hacker News
  • Semua pendekatan yang menumpuk memori di “ruang teks” terasa cukup hacky
    Untuk mempertahankan makna model secara utuh, menyimpannya di ruang embedding yang padat tampaknya lebih alami daripada prosedur tambalan yang terus-menerus membuat ulang ringkasan
    Selain itu, model harus dilatih untuk mengenali dan memanfaatkan memori, dan kalau bisa sebaiknya sejak awal dilatih dalam pengaturan seperti itu

    • Memang terlihat hacky, tetapi konsep LLM percakapan itu sendiri pada dasarnya juga bisa dianggap begitu
      Pada akhirnya, ia hanya diminta menambahkan satu kata berikutnya ke percakapan yang diberikan, lalu ketika pada suatu titik mengeluarkan token akhir, aplikasi mengembalikan kendali ke pengguna
      Menurut saya ruang laten dan ruang teks tidak sejauh yang dibayangkan. LLM cukup tumpul, tetapi sangat piawai berbicara; menulis kode juga mirip, ia pandai melakukannya, tetapi runtuh di ranah yang benar-benar membutuhkan pemikiran abstrak seperti matematika
      Peretasan ruang teks semacam ini memang cenderung berhasil, dan itulah sebabnya prompt seperti “berpikirlah langkah demi langkah” menjadi umum
      LoRA lebih dekat dengan arah yang disebutkan, dan sangat bagus untuk memadatkan banyak pemahaman ke dalam data yang sangat sedikit. Namun menyesuaikan bobot untuk satu percakapan masih belum realistis, jadi untuk penggunaan itu kita sedang mengeksplorasi ruang teks
    • Bayangkan saja memakai metode ini di kepala Anda. Jika Anda merangkum diskusi sejauh ini secara rekursif, ingatan bisa menjadi lebih baik
      Merangkum sesuatu di kepala mungkin terasa “hacky”, tetapi menurut saya sebagian besar cara kerja memori sebenarnya mirip dengan itu
    • Menariknya, cara terus-menerus membuat ulang ringkasan tidak jauh berbeda dari cara kerja otak manusia, setidaknya memori jangka panjang, yang diyakini bekerja
      https://news.northwestern.edu/stories/2012/09/your-memory-is...
    • Hampir semua komputasi yang kita gunakan hari ini juga pada dasarnya sering kali merupakan konstruksi hacky; hanya saja sudah cukup diabstraksikan dan diberi penanganan kesalahan sehingga tidak terlihat seperti hack
    • Saya penasaran mengapa ada intuisi bahwa ruang embedding yang padat bisa melakukan pelestarian makna secara sempurna
      Sejauh yang saya pahami, embedding pada dasarnya lebih dekat ke kompresi lossy. Kalau ringkasan teks, setidaknya agen bisa memverifikasi apakah ringkasan itu merepresentasikan informasi asli secara akurat
  • Di CodeRabbit, kami sudah memakai pendekatan seperti ini untuk review PR bertahap dan percakapan dalam konteks perubahan kode
    Ini membuat bot tampak memiliki konteks jauh lebih banyak daripada kenyataannya, dan merupakan salah satu trik yang kami gunakan untuk memperluas review kode AI hingga PR besar (lebih dari 100 file)
    Pada tiap commit, kami merangkum diff per file, lalu membuat ringkasan dari ringkasan-ringkasan itu, dan memperbaruinya secara bertahap setiap kali commit ditambahkan ke PR. Ringkasan dari ringkasan ini disimpan tersembunyi di dalam komentar PR, dan digunakan saat mereview tiap file atau menjawab pertanyaan pengguna
    Sebagian kodenya open source, dan prompt terkait yang digunakan untuk ringkasan rekursif ada di sini: https://github.com/coderabbitai/ai-pr-reviewer/blob/main/src...
    [0]: coderabbit.ai

    • Saya penasaran apakah ada masalah saat mem-parsing hasil prompt
      Jika ya, saya juga penasaran apakah pernah mencoba function calling alih-alih mem-parsing keluaran teks bebas
  • Kalau statusnya masih “kode dan skrip akan dirilis nanti”, sekarang sulit untuk mempercayai klaim apa pun
    Bisa saja benar, bisa juga omong kosong, tetapi kalau tidak ada cara mereproduksi eksperimen dengan biaya rendah, saya menganggap makalah seperti ini ditulis penulisnya untuk dimasukkan ke CV
    Di bidang LLM, saya sudah menunggu lebih dari 6 bulan untuk makalah-makalah yang mengatakan “kode akan dirilis nanti”, tetapi tidak ada tanda-tanda benar-benar dirilis. Bahkan beberapa makalah begitu tidak tahu malu sampai memasukkan tautan rusak yang mengarah ke domain parkir
    Sudah saatnya komunitas benar-benar menyadari praktik kode yang tidak dipublikasikan seperti ini

    • Benar. Ini ide yang sangat sederhana dan tidak membutuhkan banyak kode, jadi seharusnya tidak sulit untuk dirapikan lalu dipublikasikan
      Dulu saya pernah bereksperimen dengan ide serupa hanya dengan mengutak-atik prompt langsung di dashboard API; ada potensinya, tetapi rasanya tidak sepadan dengan biaya API. Kemungkinan besar pendekatan embedding vektor jauh lebih baik
  • Sebagai contoh pribadi, perusahaan kami memiliki ribuan “Briefings”, yaitu panel offline berdurasi satu jam, terkadang berlangsung sepanjang hari
    Kami berhasil merangkum tiap briefing, dan transkrip yang berantakan dirapikan dengan baik menjadi ringkasan lima paragraf
    Bagian yang lebih relevan adalah kami mengklasifikasikan tiap briefing ke dalam topik dan subtopik dengan relasi 1:N. Puluhan briefing dikelompokkan dalam satu topik, belasan briefing dalam satu subtopik, lalu kami menguji secara luas dengan merangkum kembali subset ringkasan yang relevan, dan hasilnya dengan LLM sangat bagus
    Awalnya saya skeptis apakah ini akan berhasil, tetapi ternyata bekerja dengan sangat baik. Kalau ada context window yang cukup besar, kami tidak akan melakukannya seperti ini, tetapi untungnya itu tidak menjadi masalah

    • Teknik ini tetap berguna meskipun context window besar
      Menurut saya memecah masalah seperti MapReduce jauh lebih baik daripada memasukkan semuanya ke context window raksasa 32k lalu memintanya diselesaikan sekaligus
  • Beberapa bulan lalu saya mencoba membuat memori ringkasan rekursif dengan model open source, tetapi jika diimplementasikan secara naif, sering kali ia terjebak selamanya pada topik tertentu
    Karena ada potongan-potongan tertentu yang bertahan di semua putaran peringkasan

    • Benar. Jika amplifikasi tidak bisa diredam secara signifikan, bahkan saat ukuran chunk disesuaikan secara manual untuk materi yang sudah diketahui, cara konteks tetap menggenggam “pikiran yang sedang sekarat” tampak sangat mirip dengan Alzheimer
    • Selain itu, pendekatan ini bisa dibuktikan tidak dapat diskalakan
      Mustahil mengecilkan blok teks apa pun menjadi blok teks yang lebih kecil tanpa kehilangan informasi sama sekali
      Jika itu mungkin, artinya kompresi tak terbatas juga mungkin, dan dataset apa pun seharusnya bisa diperkecil menjadi 1 bit lalu dipulihkan secara sempurna. Namun itu tidak bisa dilakukan
      Jika percakapan dikompresi menjadi ringkasan, sebagian informasi pasti hilang. Sebagus apa pun tuning, pelipatan, atau metode cerdas yang dipakai, secara fundamental kehilangan informasi tetap terjadi
      Terlebih lagi, proses ini bersifat rekursif, sehingga pada suatu titik sekumpulan ringkasan akan diringkas lagi, dan saat itu pun sejumlah informasi akan hilang
      Jadi mungkin berguna untuk kasus-kasus sepele, tetapi memasukkan ringkasan rekursif ke prompt terasa cukup bodoh, dan jika diminta melakukan sesuatu yang benar-benar berguna, hampir pasti tidak akan bekerja dengan baik. Saat ringkasan rekursif tidak banyak dipakai, informasi yang hilang sedikit sehingga terlihat seolah berfungsi; begitu benar-benar digunakan, kemungkinan besar batasannya cepat terlihat
    • Ini mengingatkan pada “pengalaman halusinasi buruk” atau pola kompulsif
      Jika memikirkan betapa mudahnya pikiran manusia keluar jalur hanya karena trauma atau proses perkembangan, gagasan tentang AI yang seperti manusia terasa sangat sarat harapan
    • Cukup instruksikan agar hal yang tampak tidak relevan dilupakan, yaitu dilewati dari ringkasan
  • Makalahnya agak mengecewakan. Detail tentang tekniknya nyaris tidak ada, hanya ada tabel yang menunjukkan bahwa metodologi yang mereka pakai menghasilkan hasil bagus
    Saya tahu ini hal umum dalam sains masa kini, tetapi dari sudut pandang developer yang menangani LLM, nilai makalahnya nyaris tidak ada. Tentu reputasi akademik para penulis mungkin sedikit naik, dan tampaknya besar kemungkinan memang itu tujuannya

    • Kalau melihat halaman paling akhir, ada prompt
    • Juga tertulis “kode dan skrip akan dirilis nanti”
      Jadi terpikir ingin menulis beberapa makalah seperti ini juga. Penasaran perlu menulis berapa makalah sampai bisa memasang jabatan “ML researcher” di bagian paling atas CV
    • Rasanya mereka memasukkan topik sederhana ke format makalah ilmiah dan membuatnya jauh lebih rumit
      Seharusnya jauh lebih banyak waktu dihabiskan untuk contoh dan prompt
  • Saya juga menulis hal serupa beberapa minggu lalu, tetapi orang-orang terlalu menyederhanakan bagian ringkasan: https://news.ycombinator.com/item?id=37117515
    Nilai memori jangka panjang berbeda secara halus tergantung use case
    Jika membuat asisten rumah, Anda perlu mengidentifikasi nama dengan NER, memahami gaya bicara seperti apa yang disukai orang itu saat mengirim pesan kepadanya, serta memahami tempat dan moda transportasi
    Jika membuat bot dukungan pelanggan, Anda perlu mengidentifikasi pertanyaan yang berlanjut menjadi percakapan panjang atau pertanyaan yang berujung pada pengabaian keranjang secara tiba-tiba
    Ringkasan pada level umum saja sudah cukup untuk demo yang keren, tetapi untuk membuat produk yang benar-benar berguna sekarang, perlu melangkah satu tingkat lebih jauh

  • Saya kurang paham apa yang baru di sini
    Peringkasan memori riwayat chat berbasis LLM sudah merupakan teknik yang dikenal luas dan sudah diimplementasikan di banyak framework LLM. Jika meringkas setiap pesan seperti di makalah, itu menjadi bottleneck performa besar dan menambahkan latensi signifikan ke loop chat
    Banyak implementasi memakai buffer berukuran tetap, lalu secara bertahap meringkas kumpulan memori lama yang terdorong keluar dari buffer. Idealnya pekerjaan ini juga diproses di luar loop chat
    Saya salah satu pembuat Zep, penyimpanan memori jangka panjang open source, dan kami mengimplementasikan ringkasan dengan cara seperti ini
    0: https://github.com/getzep/zep

  • Ini sedikit menyimpang dari artikel atau diskusi, tetapi memori pendek memang batasan nyata
    Namun menurut saya sebagian besar kritik terhadap kemampuan GPT-4 berlaku sama, atau bahkan lebih kuat, bagi manusia
    Dalam situasi tes Turing terbalik, saya tidak yakin ada orang hidup yang bisa meyakinkan saya bahwa dirinya adalah GPT-4. Jawaban GPT-4 yang cepat dan tertata saja sudah melampaui kemampuan manusia
    Bahkan jika tim manusia diberi 60 menit untuk menjawab tiap pertanyaan, mereka mungkin akan kesulitan menyamai respons GPT-4 terhadap pertanyaan yang menarik. Sepertinya akan jadi kompetisi yang menarik

  • Implementasi dalam makalah pada dasarnya menambahkan teks memori sebagai bagian dari prompt
    Saya penasaran mengapa tidak memakai sistem penyimpanan dan pencarian yang tidak menggunakan token jendela konteks. Misalnya saat menyimpan, yaitu ketika prompt pengguna masuk, data bisa diklasifikasikan otomatis dengan tag; saat mengambil kembali, LLM bisa menjalankan kueri yang difilter berdasarkan tag yang diperkirakannya sebelum memberi respons
    Secara intuitif, dengan beberapa aturan awal saja seperti nama atau gaya tag yang di-hardcode, hasilnya tampaknya sudah bisa cukup bagus