Apakah RAG Menjadi Ketinggalan Zaman Karena Agen yang Sudah Lama Beroperasi Seperti Claude Cowork Bermunculan?

Claude Cowork adalah fitur agen baru di aplikasi Claude Desktop. Dari sudut pandang pengembang, pada dasarnya fitur ini adalah sebuah task runner otomatis yang dibungkus dengan model: fitur ini dapat membaca, memodifikasi, dan menghasilkan file lokal, dan dapat merencanakan tugas multi-langkah tanpa Anda harus meminta secara manual untuk setiap langkah. Anggap saja ini sebagai perulangan yang sama di belakang Claude Code, tetapi diekspos ke desktop, bukan terminal.

Kemampuan utama Cowork adalah kemampuannya untuk berjalan dalam waktu yang lama tanpa kehilangan status. Ia tidak terkena batas waktu percakapan yang biasa atau pengaturan ulang konteks. Aplikasi ini dapat terus bekerja, melacak hasil antara, dan menggunakan kembali informasi sebelumnya di seluruh sesi. Hal ini memberikan kesan "memori jangka panjang", meskipun mekanisme yang mendasarinya lebih seperti status tugas yang persisten + pengalihan kontekstual. Bagaimanapun, pengalamannya berbeda dengan model obrolan tradisional, di mana semuanya diatur ulang kecuali Anda membangun lapisan memori Anda sendiri.

Hal ini memunculkan dua pertanyaan praktis bagi para pengembang:

1. Jika model ini sudah dapat mengingat informasi masa lalu, di mana RAG atau agentic RAG masih bisa digunakan? Apakah RAG akan diganti?

2. Jika kita menginginkan agen lokal bergaya Cowork, bagaimana cara kita mengimplementasikan memori jangka panjang sendiri?

Sisa artikel ini membahas pertanyaan-pertanyaan ini secara mendetail dan menjelaskan bagaimana database vektor cocok dengan lanskap "model memori" yang baru ini.

Claude Cowork vs RAG: Apa Bedanya?

Seperti yang saya sebutkan sebelumnya, Claude Cowork adalah mode agen di dalam Claude Desktop yang dapat membaca dan menulis file lokal, memecah tugas menjadi beberapa langkah yang lebih kecil, dan terus bekerja tanpa kehilangan status. Mode ini mempertahankan konteks kerjanya sendiri, sehingga tugas berjam-jam tidak diatur ulang seperti sesi obrolan biasa.

RAG (Retrieval-Augmented Generation) memecahkan masalah yang berbeda: memberikan model akses ke pengetahuan eksternal. Anda mengindeks data Anda ke dalam basis data vektor, mengambil bagian yang relevan untuk setiap kueri, dan memasukkannya ke dalam model. Sistem ini banyak digunakan karena menyediakan aplikasi LLM dengan bentuk "memori jangka panjang" untuk dokumen, log, data produk, dan banyak lagi.

Jika kedua sistem ini membantu model untuk "mengingat", apa perbedaan sebenarnya?

Bagaimana Cowork Menangani Memori

Memori Cowork bersifat baca-tulis. Agen memutuskan informasi mana dari tugas atau percakapan saat ini yang relevan, menyimpannya sebagai entri memori, dan mengambilnya nanti saat tugas berlangsung. Hal ini memungkinkan Cowork untuk menjaga kesinambungan di seluruh alur kerja yang sudah berjalan lama - terutama alur kerja yang menghasilkan status peralihan baru seiring berjalannya waktu.

Bagaimana RAG dan Agentic RAG Menangani Memori

RAG standar adalah pengambilan berbasis kueri: pengguna menanyakan sesuatu, sistem mengambil dokumen yang relevan, dan model menggunakannya untuk menjawab. Korpus pengambilan tetap stabil dan berversi, dan pengembang mengontrol dengan tepat apa yang masuk ke dalamnya.

RAG agen modern memperluas pola ini. Model dapat memutuskan kapan harus mengambil informasi, apa yang harus diambil, dan bagaimana menggunakannya selama perencanaan atau pelaksanaan alur kerja. Sistem ini dapat menjalankan tugas-tugas yang panjang dan memanggil alat, mirip dengan Cowork. Tetapi bahkan dengan RAG agen, lapisan pengambilan tetap berorientasi pada pengetahuan daripada berorientasi pada keadaan. Agen mengambil fakta-fakta otoritatif; agen tidak menulis status tugas yang berkembang kembali ke dalam korpus.

Cara lain untuk melihatnya:

• Memori rekan kerja digerakkan oleh tugas: agen menulis dan membaca statusnya sendiri yang berkembang.

• RAG digerakkan oleh pengetahuan: sistem mengambil informasi yang sudah ada yang harus diandalkan oleh model.

Rekayasa Balik Claude Cowork: Bagaimana Ia Membangun Memori Agen Jangka Panjang

Cowork mendapat banyak sorotan karena menangani tugas-tugas multi-langkah tanpa terus-menerus melupakan apa yang sedang dilakukannya. Dari sudut pandang pengembang, saya bertanya-tanya bagaimana ia bisa mempertahankan status di sesi yang begitu lama? Anthropic belum mempublikasikan bagian dalamnya, tetapi berdasarkan eksperimen pengembang sebelumnya dengan modul memori Claude, kami dapat menyusun model mental yang layak.

Claude tampaknya mengandalkan pengaturan hibrida: lapisan memori jangka panjang yang persisten ditambah alat pengambilan sesuai permintaan. Alih-alih memasukkan seluruh percakapan ke dalam setiap permintaan, Claude secara selektif menarik konteks masa lalu hanya jika dianggap relevan. Hal ini memungkinkan model menjaga akurasi tetap tinggi tanpa meniup token setiap saat.

Jika Anda memecah struktur permintaan, secara kasar akan terlihat seperti ini:

[0] Static system instructions
[1] User memory (long-term)
[2] Retrieved / pruned conversation history
[3] Current user message

Perilaku yang menarik bukanlah struktur itu sendiri - tetapi bagaimana model memutuskan apa yang harus diperbarui dan kapan harus menjalankan pengambilan.

Memori Pengguna: Lapisan Persisten

Claude menyimpan memori jangka panjang yang diperbarui dari waktu ke waktu. Dan tidak seperti sistem memori ChatGPT yang lebih mudah diprediksi, Claude terasa lebih "hidup". Ia menyimpan memori dalam blok-blok XML dan memperbaruinya dengan dua cara:

• Pembaruan implisit: Kadang-kadang model hanya memutuskan sesuatu sebagai preferensi atau fakta yang stabil dan secara diam-diam menuliskannya ke memori. Pembaruan ini tidak seketika; pembaruan ini muncul setelah beberapa kali, dan memori yang lebih lama dapat memudar jika percakapan terkait menghilang.

• Pembaruan eksplisit: Pengguna dapat secara langsung memodifikasi memori dengan alat memory_user_edits ("ingat X," "lupakan Y"). Penulisan ini bersifat langsung dan berperilaku seperti operasi CRUD.

Claude menjalankan heuristik latar belakang untuk memutuskan apa yang perlu dipertahankan, dan tidak menunggu instruksi eksplisit.

Pengambilan Percakapan: Bagian Sesuai Permintaan

Claude tidak menyimpan ringkasan bergulir seperti kebanyakan sistem LLM. Sebaliknya, ia memiliki sebuah kotak peralatan fungsi pengambilan yang dapat dipanggil kapan pun ia merasa kehilangan konteks. Panggilan pengambilan ini tidak terjadi setiap saat - model ini memicunya berdasarkan penilaian internalnya sendiri.

Yang paling menonjol adalah conversation_search. Ketika pengguna mengatakan sesuatu yang tidak jelas seperti "proyek itu dari bulan lalu," Claude sering kali menjalankan alat ini untuk menggali giliran yang relevan. Yang perlu dicatat adalah bahwa alat ini masih berfungsi ketika frasa tersebut ambigu atau dalam bahasa yang berbeda. Hal itu cukup jelas menyiratkan:

• Semacam pencocokan semantik (penyematan)

• Mungkin dikombinasikan dengan normalisasi atau terjemahan ringan

• Pencarian kata kunci yang berlapis-lapis untuk ketepatan

Pada dasarnya, ini sangat mirip dengan sistem RAG mini yang dibundel di dalam perangkat model.

Bagaimana Perilaku Pengambilan Claude Berbeda Dari Buffer Riwayat Dasar

Dari pengujian dan log, ada beberapa pola yang menonjol:

• Pengambilan tidak dilakukan secara otomatis. Model memilih kapan harus memanggilnya. Jika ia merasa sudah memiliki konteks yang cukup, ia tidak akan repot-repot memanggilnya.

• Potongan yangdiambil mencakup pesan pengguna dan asisten. Ini berguna - ini menyimpan lebih banyak nuansa daripada ringkasan khusus pengguna.

• Penggunaan token tetap waras. Karena riwayat tidak disuntikkan setiap saat, sesi yang panjang tidak membengkak secara tak terduga.

Secara keseluruhan, ini terasa seperti LLM yang ditambah dengan pengambilan, kecuali pengambilan terjadi sebagai bagian dari loop penalaran model itu sendiri.

Arsitektur ini pintar, tetapi tidak gratis:

• Retrieval menambahkan latensi dan lebih banyak "bagian yang bergerak" (pengindeksan, pemeringkatan, pemeringkatan ulang).

• Model terkadang salah menilai apakah ia membutuhkan konteks, yang berarti Anda melihat "kelupaan LLM" yang klasik meskipun datanya tersedia.

• Debugging menjadi lebih sulit karena perilaku model bergantung pada pemicu alat yang tidak terlihat, bukan hanya input yang diminta.

Claude Cowork vs Claude Codex dalam menangani memori jangka panjang

Berbeda dengan pengaturan Claude yang berat pada pengambilan, ChatGPT menangani memori dengan cara yang jauh lebih terstruktur dan dapat diprediksi. Alih-alih melakukan pencarian semantik atau memperlakukan percakapan lama seperti penyimpanan vektor mini, ChatGPT menyuntikkan memori secara langsung ke dalam setiap sesi melalui komponen berlapis berikut ini:

• Memori pengguna

• Metadata sesi

• Pesan sesi saat ini

Memori Pengguna

Memori Pengguna adalah lapisan penyimpanan jangka panjang utama - bagian yang bertahan di seluruh sesi dan dapat diedit oleh pengguna. Memori ini menyimpan hal-hal yang cukup standar: nama, latar belakang, proyek yang sedang berlangsung, preferensi pembelajaran, hal-hal semacam itu. Setiap percakapan baru akan disuntikkan blok ini di awal, sehingga model selalu dimulai dengan tampilan yang konsisten dari pengguna.

ChatGPT memperbarui lapisan ini dengan dua cara:

• Pembaruan eksplisit: Pengguna dapat memberi tahu model untuk "ingat ini" atau "lupakan itu", dan memori akan segera berubah. Ini pada dasarnya adalah API CRUD yang diekspos oleh model melalui bahasa alami.

• Pembaruan implisit: Jika model menemukan informasi yang sesuai dengan aturan OpenAI untuk memori jangka panjang-seperti jabatan atau preferensi-dan pengguna belum menonaktifkan memori, model akan menambahkannya sendiri secara diam-diam.

Dari sudut pandang pengembang, lapisan ini sederhana, deterministik, dan mudah dipahami. Tidak ada pencarian penyematan, tidak ada heuristik tentang apa yang harus diambil.

Metadata Sesi

Metadata Sesi berada di ujung spektrum yang berlawanan. Metadata ini berumur pendek, tidak persisten, dan hanya disuntikkan sekali pada awal sesi. Anggap saja sebagai variabel lingkungan untuk percakapan. Ini mencakup hal-hal seperti:

• perangkat apa yang Anda gunakan

• status akun/langganan

• pola penggunaan kasar (hari aktif, distribusi model, panjang percakapan rata-rata)

Metadata ini membantu model membentuk respons untuk lingkungan saat ini-misalnya, menulis jawaban yang lebih pendek di ponsel-tanpa mengotori memori jangka panjang.

Pesan Sesi Saat Ini

Ini adalah riwayat jendela geser standar: semua pesan dalam percakapan saat ini hingga batas token tercapai. Ketika jendela menjadi terlalu besar, giliran yang lebih lama akan hilang secara otomatis.

Yang paling penting, penggusuran ini tidak menyentuh Memori Pengguna atau ringkasan lintas sesi. Hanya riwayat percakapan lokal yang menyusut.

Perbedaan terbesar dari Claude tampak pada bagaimana ChatGPT menangani percakapan "baru-baru ini tetapi tidak sekarang". Claude akan memanggil alat pencarian untuk mengambil konteks masa lalu jika dianggap relevan. ChatGPT tidak melakukan itu.

Sebaliknya, ChatGPT menyimpan ringkasan lintas sesi yang sangat ringan yang disuntikkan ke dalam setiap percakapan. Beberapa detail penting tentang lapisan ini:

• Ini hanya meringkas pesan pengguna, bukan pesan asisten.

• Ia menyimpan sekumpulan item yang sangat kecil-kurang lebih 15 item-cukup untuk menangkap tema atau minat yang stabil.

• Lapisan ini tidak melakukan komputasi penyematan, tidak ada peringkat kemiripan, dan tidak ada pemanggilan pengambilan. Pada dasarnya ini adalah konteks yang sudah dikunyah sebelumnya, bukan pencarian dinamis.

Dari perspektif teknik, pendekatan ini menukar fleksibilitas dengan prediktabilitas. Tidak ada kemungkinan kegagalan pengambilan yang aneh, dan latensi inferensi tetap stabil karena tidak ada yang diambil dengan cepat. Kelemahannya adalah ChatGPT tidak akan menarik pesan acak dari enam bulan yang lalu kecuali jika pesan tersebut berhasil masuk ke dalam lapisan ringkasan.

Tantangan untuk Membuat Memori Agen Dapat Ditulis

Ketika sebuah agen berpindah dari memori hanya-baca (RAG) ke memori yangdapat ditulis - di manaia dapat mencatat tindakan, keputusan, dan preferensi pengguna - kerumitannya melonjak dengan cepat. Anda tidak lagi hanya mengambil dokumen; Anda mempertahankan keadaan yang terus berkembang yang menjadi dasar model.

Sistem memori yang dapat ditulis harus menyelesaikan tiga masalah nyata:

1. Apa yang harus diingat: Agen membutuhkan aturan untuk memutuskan peristiwa, preferensi, atau pengamatan mana yang layak disimpan. Tanpa ini, memori akan meledak dalam ukuran atau dipenuhi dengan noise.

2. Bagaimana menyimpan dan menyusun memori: Tidak semua memori sama. Item terbaru, fakta jangka panjang, dan catatan sesaat, semuanya membutuhkan lapisan penyimpanan, kebijakan penyimpanan, dan strategi pengindeksan yang berbeda.

3. Cara menulis cepat tanpa mengganggu pengambilan: Memori harus ditulis secara terus menerus, tetapi pembaruan yang sering dapat menurunkan kualitas indeks atau memperlambat kueri jika sistem tidak dirancang untuk sisipan dengan kecepatan tinggi.

Tantangan 1: Apa yang Perlu Diingat?

Tidak semua yang dilakukan pengguna harus disimpan di memori jangka panjang. Jika seseorang membuat file sementara dan menghapusnya lima menit kemudian, merekamnya selamanya tidak akan membantu siapa pun. Ini adalah kesulitan utama: bagaimana sistem memutuskan apa yang sebenarnya penting?

(1) Cara umum untuk menilai kepentingan

Tim biasanya mengandalkan campuran heuristik:

• Berbasis waktu: tindakan terbaru lebih penting daripada tindakan lama

• Berbasis frekuensi: file atau tindakan yang diakses berulang kali lebih penting

• Berbasis jenis: beberapa objek secara inheren lebih penting (misalnya, file konfigurasi proyek vs. file cache)

(2) Ketika aturan bertentangan

Sinyal-sinyal ini sering kali bertentangan. Sebuah file yang dibuat minggu lalu namun diedit secara besar-besaran hari ini-haruskah usia atau aktivitas yang menang? Tidak ada jawaban yang "benar", itulah sebabnya mengapa penilaian tingkat kepentingan cenderung menjadi berantakan dengan cepat.

(3) Bagaimana database vektor membantu

Basis data vektor memberi Anda mekanisme untuk menegakkan aturan kepentingan tanpa pembersihan manual:

• TTL: Milvus dapat secara otomatis menghapus data setelah waktu yang ditentukan

• Peluruhan: vektor yang lebih tua dapat diturunkan bobotnya sehingga secara alami memudar dari pengambilan

Tantangan 2: Tingkatan Memori dalam Praktik

Ketika agen berjalan lebih lama, memori akan menumpuk. Menyimpan segala sesuatu dalam penyimpanan cepat tidak berkelanjutan, sehingga sistem membutuhkan cara untuk membagi memori menjadi tingkatan panas (sering diakses) dan dingin (jarang diakses).

(1) Memutuskan Kapan Memori Menjadi Dingin

Dalam model ini, memori panas mengacu pada data yang disimpan dalam RAM untuk akses latensi rendah, sedangkan memori dingin mengacu pada data yang dipindahkan ke disk atau penyimpanan objek untuk mengurangi biaya.

Memutuskan kapan memori menjadi dingin dapat ditangani dengan berbagai cara. Beberapa sistem menggunakan model yang ringan untuk memperkirakan kepentingan semantik dari sebuah tindakan atau file berdasarkan makna dan penggunaan terakhirnya. Sistem lainnya mengandalkan logika sederhana berbasis aturan, seperti memindahkan memori yang tidak diakses selama 30 hari atau tidak muncul dalam hasil pencarian selama seminggu. Pengguna juga dapat secara eksplisit menandai file atau tindakan tertentu sebagai hal yang penting, sehingga memastikan file atau tindakan tersebut selalu dalam keadaan panas.

(2) Tempat Penyimpanan Memori Panas dan Dingin

Setelah diklasifikasikan, memori panas dan dingin disimpan secara berbeda. Memori panas tetap berada di RAM dan digunakan untuk konten yang sering diakses, seperti konteks tugas aktif atau tindakan pengguna terkini. Memori dingin dipindahkan ke disk atau sistem penyimpanan objek seperti S3, di mana aksesnya lebih lambat tetapi biaya penyimpanannya jauh lebih rendah. Pertukaran ini bekerja dengan baik karena memori dingin jarang dibutuhkan dan biasanya diakses hanya untuk referensi jangka panjang.

(3) Bagaimana Basis Data Vektor Membantu

Milvus dan Zilliz Cloud mendukung pola ini dengan memungkinkan penyimpanan berjenjang panas-dingin sambil mempertahankan antarmuka kueri tunggal, sehingga vektor yang sering diakses tetap berada di memori dan data yang lebih lama berpindah ke penyimpanan yang lebih murah secara otomatis.

Tantangan 3: Seberapa Cepat Memori Harus Ditulis?

Sistem RAG tradisional biasanya menulis data secara berkelompok. Indeks dibangun ulang secara offline - sering kali dalam semalam - dan baru dapat dicari kemudian. Pendekatan ini bekerja untuk basis pengetahuan statis, tetapi tidak cocok untuk memori agen.

(1) Mengapa Memori Agen Membutuhkan Penulisan Waktu Nyata

Memori agen harus menangkap tindakan pengguna saat terjadi. Jika sebuah tindakan tidak segera dicatat, giliran percakapan berikutnya mungkin tidak memiliki konteks yang penting. Karena alasan ini, sistem memori yang dapat ditulis membutuhkan penulisan secara real-time daripada pembaruan offline yang tertunda.

(2) Ketegangan Antara Kecepatan Tulis dan Kualitas Pengambilan

Memori waktu nyata menuntut latensi penulisan yang sangat rendah. Pada saat yang sama, pengambilan berkualitas tinggi bergantung pada indeks yang dibangun dengan baik, dan konstruksi indeks membutuhkan waktu. Membangun ulang indeks untuk setiap penulisan terlalu mahal, tetapi menunda pengindeksan berarti data yang baru ditulis untuk sementara waktu tidak dapat diambil. Pengorbanan ini berada di pusat desain memori yang dapat ditulis.

(3) Bagaimana Basis Data Vektor Membantu

Basis data vektor mengatasi masalah ini dengan memisahkan penulisan dari pengindeksan. Solusi yang umum adalah melakukan penulisan secara streaming dan melakukan pembuatan indeks secara bertahap. Menggunakan Milvus sebagai contoh, data baru pertama kali ditulis ke buffer dalam memori, sehingga sistem dapat menangani penulisan dengan frekuensi tinggi secara efisien. Bahkan sebelum indeks penuh dibuat, data yang disangga dapat ditanyakan dalam hitungan detik melalui penggabungan dinamis atau pencarian perkiraan.

Ketika buffer mencapai ambang batas yang telah ditentukan, sistem akan membangun indeks secara bertahap dan mempertahankannya. Hal ini meningkatkan kinerja pengambilan jangka panjang tanpa memblokir penulisan waktu nyata. Dengan memisahkan konsumsi yang cepat dari konstruksi indeks yang lebih lambat, Milvus mencapai keseimbangan praktis antara kecepatan tulis dan kualitas pencarian yang bekerja dengan baik untuk memori agen.

Kesimpulan

Cowork memberi kita gambaran sekilas tentang kelas agen baru - gigih, penuh perhatian, dan mampu membawa konteks dalam jangka waktu yang panjang. Namun, hal ini juga memperjelas hal lain: memori jangka panjang hanyalah separuh dari gambarannya. Untuk membangun agen siap produksi yang otonom dan dapat diandalkan, kita masih membutuhkan pengambilan terstruktur dari basis pengetahuan yang besar dan terus berkembang.

RAG menangani fakta-fakta dunia; memori yang dapat ditulis menangani keadaan internal agen. Dan basis data vektor berada di persimpangan, menyediakan pengindeksan, pencarian hibrida, dan penyimpanan terukur yang memungkinkan kedua lapisan untuk bekerja sama.

Seiring dengan semakin matangnya agen yang sudah berjalan lama, arsitektur mereka kemungkinan besar akan menyatu dalam desain hibrida ini. Cowork adalah sinyal kuat ke mana arahnya - bukan menuju dunia tanpa RAG, tetapi menuju agen dengan tumpukan memori yang lebih kaya yang didukung oleh basis data vektor di bawahnya.

Jika Anda ingin menjelajahi ide-ide ini atau mendapatkan bantuan dengan pengaturan Anda sendiri, bergabunglah dengan Slack Channel kami untuk mengobrol dengan teknisi Milvus. Dan untuk panduan yang lebih praktis, Anda selalu dapat memesan sesi Jam Kerja Milvus.