MemGPT - LLM dengan memori yang dapat mengedit diri sendiri untuk konteks tak terbatas

• Letta adalah proyek untuk membangun AI berbasis memori tingkat lanjut yang dapat belajar seiring waktu dan meningkatkan dirinya sendiri
• Cara penggunaannya dibagi menjadi Letta Code, yang menjalankan agen di terminal lokal, dan Letta API, yang mengintegrasikan agen ke dalam aplikasi
• CLI memerlukan Node.js 18+, dipasang dengan npm install -g @letta-ai/letta-code, lalu jalankan letta untuk menjalankan agen bermemori di komputer lokal
• Agen Letta Code membantu pekerjaan coding dan tugas yang dapat dilakukan di komputer, mendukung skills dan subagents, serta dibundel dengan skills/subagents bawaan untuk memori tingkat lanjut dan pembelajaran berkelanjutan
• Letta bersifat model-agnostic, dan README merekomendasikan Opus 4.5 serta GPT-5.2 untuk performa terbaik, serta menautkan model leaderboard sebagai referensi peringkat
• Letta API digunakan untuk mengintegrasikan agen yang memiliki state ke dalam aplikasi, serta menyediakan agents API berfitur lengkap dan SDK Python maupun TypeScript
  • Paket TypeScript/Node.js: @letta-ai/letta-client
  • Paket Python: letta-client
  • Contohnya mengikuti alur membuat agen dan mengirim pesan dengan LETTA_API_KEY dan Letta API key
• Dengan menggunakan Letta dan layanan Letta terkait, pengguna dianggap menyetujui privacy policy dan terms of service

[GN⁺]

Komentar Hacker News

• Kami adalah penulis MemGPT. Jika ada pertanyaan terkait implementasi, kami akan menjawabnya
  Jika ingin mencobanya langsung, Anda bisa melihat penyuntingan memori bekerja di bot Discord pada server Discord MemGPT (https://discord.gg/9GEQrxmVyE). Saat berbicara dengan bot, Anda akan melihat proses MemGPT memodifikasi memori untuk memperbarui profil tentang pengguna dan dirinya sendiri
  Semuanya open source, jadi bisa juga dijalankan secara lokal dari kode di https://github.com/cpacker/MemGPT. Repositori itu juga memiliki contoh berpusat pada dokumen untuk bercakap-cakap dengan MemGPT tentang dokumentasi API LlamaIndex

• Saya penasaran mengapa semuanya ditangani dalam satu context window. Saat bereksperimen dengan hal serupa beberapa bulan lalu, saya memparalelkan dengan beberapa agen pada tahap prapemrosesan/pascapemrosesan
  Misalnya, context window utama tidak tahu bahwa memori dibuat atau diambil; post-processor secara otomatis membuat memori dari percakapan dan menyimpannya, sementara seluruh percakapan juga disimpan di database vektor. Pre-processor secara otomatis menyuntikkan memori dan konteks yang relevan sesuai percakapan, bahkan menulis ulang histori sehingga dari sudut pandang context window utama, memori itu tampak seperti sudah ada sejak awal
  Dengan cara ini, banyak ruang yang dipakai untuk system prompt yang tidak perlu di context window utama bisa dihemat

  • Poin-poin yang bagus. Dalam konteks chatbot, kepada siapa manajemen memori diserahkan adalah pilihan desain, dan menurut saya secara garis besar ada dua cara: manajemen memori implisit dan manajemen memori eksplisit
    Pada cara implisit, “LLM utama”, atau dalam chat “thread percakapan”, tidak mengetahui manajemen memori di latar belakang. Manajemen ini bisa ditangani oleh “LLM memori”, skrip berbasis aturan, neural network kecil, dan sebagainya
    Cara eksplisit adalah yang digunakan MemGPT, yaitu satu LLM menangani semuanya. Riset terdahulu terkait multi-sesi/chat jarak panjang biasanya memakai cara implisit dengan proses pembuatan memori terpisah, dan penyimpanan memori chatbot konsumen pun kemungkinan besar kebanyakan implisit
    Manajemen memori eksplisit membutuhkan kemampuan mengikuti instruksi yang kompleks, jadi menurut saya sulit dilakukan dengan sebagian besar LLM publik saat ini. Kami sedang meninjau cara mengatasinya, seperti fine-tuning model terbuka
    Trade-off-nya seperti yang Anda katakan. Cara implisit tidak perlu memasukkan semua instruksi manajemen memori ke pre-prompt LLM. Pesan sistem lengkap MemGPT sekitar 1.000 token. Sebaliknya, ketika LLM bekerja dengan benar, manajemen memori eksplisit membuat keseluruhan sistem jauh lebih sederhana, karena tidak ada overhead untuk mengelola beberapa model LLM di thread paralel
  • Pendekatan yang menarik. Saya sedang membuat sesuatu yang mirip, dengan cara memasukkan data transaksi ke context window sebagai bagian dari feedback loop untuk menulis ulang histori
    Saya melihat LLM dan pemrosesan bahasa alami dapat menjadi antarmuka yang lebih layak untuk data terstruktur. Ketika data dibuat dalam konteks bisnis tertentu, data diekstrak, embedding dibuat, dan database vektor dibangun
    Pada pascapemrosesan, setelah model utama merespons, post-processor secara otomatis membuat memori berdasarkan percakapan dan menyimpannya. Ini menyimpan konteks penting tanpa membebani model utama dengan tugas tersebut. Sebagai bagian dari permintaan, logika bisnis yang relevan juga dijalankan lalu diumpankan kembali ke sistem
    Pada prapemrosesan, sebelum mengirim input baru ke model utama, memori yang tersimpan diperiksa, konteks yang relevan disuntikkan, dan logika juga dijalankan. Dengan kata lain, pre-processor memberi model utama “ulasan” atas percakapan sebelumnya agar siap memberi respons yang lebih konsisten dan kaya informasi
  • Multi-agent punya potensi yang cukup besar. Menurut saya respons agen memiliki tingkat entropi tertentu, sehingga makin layak untuk dicoba

• Terkait hal yang ditulis di bagian keterbatasan, jika varian Llama 2 70B yang sudah di-fine-tune untuk function calling tetap membuat pemanggilan fungsi yang salah atau berhalusinasi fungsi di luar skema yang diberikan, Anda bisa memakai grammar-based sampling
  Setidaknya ini bisa menjamin pemanggilan fungsi valid secara sintaksis
  [0] https://github.com/ggerganov/llama.cpp/tree/master/grammars

  • Grammar-based sampling adalah ide bagus dan sangat cocok untuk hal seperti MemGPT. Saat bereksperimen dengan MemGPT menggunakan model non-gpt-4, masalah yang paling besar memengaruhi performa adalah penyalahgunaan argumen fungsi dan halusinasi fungsi
    Misalnya, model besar yang di-fine-tune dengan data function calling (https://huggingface.co/jondurbin/airoboros-l2-70b-2.1#agentf...) umumnya memang menghasilkan JSON yang bisa di-parse, tetapi argumen atau nama fungsinya salah
    Contohnya, saat hendak menulis data, alih-alih pemanggilan working_context.append yang benar seperti dinyatakan di pre-prompt, ia menghasilkan pemanggilan personal_diary.add yang sama sekali tidak ditentukan

• Dari judulnya saja saya mengira ini tentang memori neural network LLM, yaitu teknik penyuntingan memori yang mengubah memori tingkat bobot saat percakapan, bukan konteks, seperti pendekatan ROME [1]
  Saya lega mengetahui bahwa ini sebenarnya pekerjaan RAG yang keren, dan saya akan segera membuat versi MemEditGPT saya sendiri
  [1] https://arxiv.org/abs/2202.05262

  • Jika ingin berkontribusi, silakan buka issue atau PR di repositori. Semuanya open source dan berlisensi Apache 2.0, dan kami sedang aktif meninjau integrasi alur kerja umum ke CLI
    Seperti yang Anda pahami dengan benar, MemGPT tidak menyunting bobot LLM seperti ROME. “Memori” yang dimaksud MemGPT berada pada tingkat teks/token, bukan tingkat bobot
    Konsep intinya adalah memberi LLM kemampuan untuk menyunting scratchpad memori kerja yang dipertahankan di dalam konteks, serta membaca dan menulis konteks eksternal melalui fungsi. Detail pentingnya adalah, untuk menangani batas konteks yang terbatas, pembacaan selalu dilakukan per halaman, yaitu per chunk
    MemGPT dapat merangkai fungsi dalam satu input pengguna untuk membaca dan menulis berulang kali. Karena itu, seperti contoh dokumentasi API LlamaIndex di README, ia dapat mencari database dokumen besar, mengumpulkan informasi dari beberapa sumber, dan mengembalikan jawaban

• Untuk beberapa waktu saya curiga versi web ChatGPT (chat.openai.com, bukan API) bekerja seperti ini di dalam percakapan. Pada riwayat chat yang sangat panjang, rasanya kualitas menurun secara bertahap alih-alih tiba-tiba melupakan semuanya
  Tentu saja mungkin ada lebih banyak petunjuk di dalam konteks daripada yang saya kira
  Bagaimanapun, saya rasa ide seperti ini kemungkinan besar akan menjadi fitur dasar semua chatbot ke depannya

  • Ringkasan rekursif adalah cara sederhana dan populer untuk memberi ilusi konteks tanpa batas. Saat perlu mengosongkan ruang, cukup kompres N pesan tertua menjadi satu pesan ringkasan
    Ini bersifat lossy dan pada akhirnya akan kehilangan informasi penting, tetapi penurunan performanya bisa relatif landai. Di MemGPT, ringkasan rekursif implisit juga digunakan di atas semua manajemen memori eksplisit
  • Ada jauh lebih banyak petunjuk yang tersisa daripada yang dibayangkan. Selain itu, jendela konteks setara sekitar 12 halaman teks bahasa Inggris standar, dan ruang yang terbuang untuk system prompt juga tidak banyak
    Jika pernah melakukan tugas yang sedikit saja menarik, output akan sangat bias terhadap prompt. Karena hanya ada satu sampel berupa output/riwayat sebelumnya, sebagian informasi hilang alih-alih distribusi probabilitas yang mulus, dan beberapa input bisa dipetakan ke output yang sama sehingga sebagian informasi lain juga hilang
    Namun prompt di dunia nyata sering kali merupakan ungkapan paling mudah dan singkat yang terpikirkan untuk mendapatkan hasil yang diinginkan. Jadi jika LLM menebak prompt itu, interpretasinya terhadap konteks yang hilang kemungkinan cukup tepat. Dengan kata lain, banyak informasi yang tampak hilang tetap tersimpan di dalam output LLM, dan meskipun konteks lama terdorong keluar, jumlah informasi yang hilang sekaligus tidak terlalu besar
  • Alasan ChatGPT menunjukkan penurunan performa adalah karena ia tidak melakukan hal khusus untuk memperluas memori di luar panjang konteks
    Ada banyak teknik sepele untuk mengimplementasikan memori lossy. Misalnya, ada metode melakukan average pooling token seperti yang dipakai sentence transformers. Saya tidak begitu tahu mengapa cara ini jarang dipakai untuk mengompres banyak konteks ke dalam prompt. Pada dasarnya ini berperan sebagai memori jangka menengah
  • Tidak diketahui model tertutup sebenarnya melakukan apa, tetapi dari beberapa serangan prompt, tampaknya mereka memakai ringkasan rekursif selain hal-hal yang disebutkan di thread ini
  • Menurut saya, sepertinya mereka memotong token tertua dari percakapan hanya sebanyak minimum yang diperlukan agar tetap di bawah batas token. Percakapan tidak menurun seolah-olah memiliki memori jangka menengah

• Saya tidak ingat namanya, tetapi sudah ada bahasa pemrograman esoterik yang mengeksekusi perintah secara tidak stabil. Jika program dirancang dengan hati-hati, urutan perintah bisa dibuat berjalan dengan reliabilitas seperti 99%, 99,9%

  • Mungkin Java2000
    Dua puluh tahun kemudian, pendekatan yang sama menjadi populer tanpa ironi di bidang infrastruktur dengan nama “chaos engineering”
  • Agak mirip Malbolge, tetapi tampaknya tidak persis sama. https://en.m.wikipedia.org/wiki/Malbolge

• Pembaruan: Saya baru saja merilis chatbot Discord persisten yang diimplementasikan di atas MemGPT. Bisa dicoba di sini: https://discord.gg/9GEQrxmVyE
  Dengan kode GitHub, Anda juga bisa menjalankan demo chatbot secara lokal, serta demo bot tanya jawab dokumen yang memungkinkan Anda bertanya kepada MemGPT tentang dokumentasi API

• Menurut saya, batasan terbesar LLM adalah jendela konteks. Kemampuan penalaran yang hebat pun dalam kasus penggunaan nyata sering terbentur batas jendela konteks

  • Benar. Semoga teknik-teknik yang diperkenalkan di sini bisa membantu memikirkan arah untuk merancang chatbot persisten

• Saya setuju dengan penjelasan bahwa ringkasan rekursif adalah cara sederhana untuk menangani jendela konteks yang meluap, tetapi pada dasarnya bersifat lossy dan akhirnya membuat lubang besar di memori sistem
  Namun MemGPT juga melakukan hal yang sama dan memiliki masalah yang sama. Bedanya hanya sedikit: alih-alih meringkas semuanya secara rekursif, ia mencari riwayat secara selektif dan membuatnya untuk tiap permintaan. Idenya keren
  Tetapi saya skeptis. Pendekatan ini pada dasarnya bergantung pada asumsi bahwa konteks sebelumnya adalah konteks yang dapat diringkas dengan entropi rendah, dan bahwa kueri hanya bergantung pada sebagian riwayat
  Untuk kasus seperti chat atau “menjawab pertanyaan dari kumpulan dokumen raksasa”, mungkin benar. Tetapi untuk pembuatan kode, ketika konteks padat dengan informasi yang tidak bisa dibuang seperti definisi API tertentu, dan ketika diperlukan konteks yang luas seperti banyak definisi API, kedua asumsi itu salah
  Struktur dan implementasinya menarik dan demonya juga keren, tetapi sayang paper-paper terkait ringkasan tidak mengakui batasan mendasar dari pendekatan ini

  • Terima kasih sudah membaca papernya. Agar tidak ada salah paham, ringkasan rekursif hanyalah salah satu bagian dari manajemen memori MemGPT
    Seperti yang Anda katakan, antrean percakapan MemGPT dikelola dengan ringkasan rekursif seperti penelitian sebelumnya atau banyak implementasi chatbot. Namun ada juga memori LLM berupa area “tetap” yang bisa dibaca/ditulis dan tidak terkait ringkasan rekursif; di paper, ini disebut “konteks kerja”
    Jadi MemGPT dapat mengakses ringkasan rekursif yang dibuat otomatis sekaligus konteks kerja yang secara aktif dijaga tetap mutakhir oleh MemGPT
    Keduanya juga terpisah dari konteks eksternal MemGPT yang dibawa ke antrean percakapan melalui pemanggilan fungsi. Dalam semua contoh, pembacaan konteks eksternal tidak dikompresi dan dilakukan per halaman tanpa ringkasan
    Saat ringkasan antrean dipicu, MemGPT menerima notifikasi sistem, sehingga jika ada detail tertentu dari antrean percakapan yang perlu dipertahankan, ia bisa menuliskannya ke konteks kerja sebelum dihapus atau diringkas
    Dalam contoh agen percakapan, konteks kerja dipakai untuk menyimpan fakta-fakta utama tentang pengguna dan agen agar percakapan tetap konsisten. Konteks kerja selalu dilihat oleh LLM, jadi tidak perlu dicari secara terpisah
    Dalam tanya jawab dokumen, konteks kerja dapat dipakai untuk melacak tugas/pertanyaan saat ini dan progresnya. Pada kueri yang kompleks, ini membantu MemGPT mengikuti detail seperti pencarian sebelumnya dan permintaan halaman sebelumnya