Refleksi tentang ChatGPT dan Sistem Memori Claude: Apa yang Dibutuhkan untuk Mengaktifkan Pengambilan Percakapan Sesuai Permintaan

Pada sistem agen AI berkualitas tinggi, desain memori jauh lebih kompleks daripada yang terlihat pada awalnya. Pada intinya, sistem ini harus menjawab tiga pertanyaan mendasar: Bagaimana seharusnya riwayat percakapan disimpan? Kapan konteks masa lalu harus diambil? Dan apa, tepatnya, yang harus diambil?

Pilihan-pilihan ini secara langsung membentuk latensi respons agen, penggunaan sumber daya, dan-pada akhirnya-batas kemampuannya.

Model seperti ChatGPT dan Claude terasa semakin "sadar memori" semakin sering kita menggunakannya. Mereka mengingat preferensi, beradaptasi dengan tujuan jangka panjang, dan menjaga kontinuitas di seluruh sesi. Dalam hal ini, mereka sudah berfungsi sebagai agen AI mini. Namun di bawah permukaan, sistem memori mereka dibangun di atas asumsi arsitektur yang sangat berbeda.

Analisis rekayasa balik terbaru dari mekanisme memori ChatGPTdan Claude menunjukkan perbedaan yang jelas. ChatGPT bergantung pada injeksi konteks yang telah dihitung sebelumnya dan cache berlapis untuk memberikan kontinuitas yang ringan dan dapat diprediksi. Claude, sebaliknya, mengadopsi gaya RAG, pengambilan sesuai permintaan dengan pembaruan memori dinamis untuk menyeimbangkan kedalaman dan efisiensi memori.

Kedua pendekatan ini bukan hanya preferensi desain - keduanya dibentuk oleh kemampuan infrastruktur. Milvus 2.6 memperkenalkan kombinasi pengambilan hibrida padat-jarang, pemfilteran skalar yang efisien, dan penyimpanan berjenjang yang dibutuhkan oleh memori percakapan sesuai permintaan, sehingga pengambilan selektif menjadi cepat dan cukup ekonomis untuk digunakan dalam sistem dunia nyata.

Dalam tulisan ini, kita akan membahas bagaimana sistem memori ChatGPT dan Claude bekerja, mengapa mereka berbeda secara arsitektur, dan bagaimana kemajuan terbaru dalam sistem seperti Milvus membuat pengambilan percakapan sesuai permintaan menjadi praktis dalam skala besar.

Sistem Memori ChatGPT

Alih-alih meminta basis data vektor atau secara dinamis mengambil percakapan masa lalu pada waktu inferensi, ChatGPT membangun "memori" dengan merakit serangkaian komponen konteks yang tetap dan menyuntikkannya secara langsung ke dalam setiap prompt. Setiap komponen dipersiapkan sebelumnya dan menempati posisi yang diketahui dalam prompt.

Desain ini menjaga personalisasi dan kontinuitas percakapan tetap utuh sambil membuat latensi, penggunaan token, dan perilaku sistem lebih dapat diprediksi. Dengan kata lain, memori bukanlah sesuatu yang dicari oleh model dengan cepat - ini adalah sesuatu yang dikemas oleh sistem dan diberikan kepada model setiap kali model menghasilkan respons.

Pada tingkat tinggi, prompt ChatGPT yang lengkap terdiri dari lapisan-lapisan berikut ini, diurutkan dari yang paling global ke yang paling cepat:

[0] Petunjuk Sistem

[1] Petunjuk Pengembang

[2] Metadata Sesi (bersifat sementara)

[3] Memori Pengguna (fakta jangka panjang)

[4] Ringkasan Percakapan Terkini (obrolan sebelumnya, judul + cuplikan)

[5] Pesan Sesi Saat Ini (obrolan ini)

[6] Pesan terbaru Anda

Di antaranya, komponen [2] hingga [5] membentuk memori efektif sistem, masing-masing memiliki peran yang berbeda.

Metadata Sesi

Metadata sesi mewakili informasi yang berumur pendek dan tidak persisten yang disuntikkan sekali pada awal percakapan dan dibuang ketika sesi berakhir. Perannya adalah untuk membantu model beradaptasi dengan konteks penggunaan saat ini, bukan untuk mempersonalisasi perilaku dalam jangka panjang.

Lapisan ini menangkap sinyal tentang lingkungan sekitar pengguna dan pola penggunaan terkini. Sinyal-sinyal yang umum meliputi:

• Informasi perangkat - misalnya, apakah pengguna menggunakan perangkat seluler atau desktop

• Atribut akun - seperti tingkat langganan (misalnya, ChatGPT Go), usia akun, dan frekuensi penggunaan secara keseluruhan

• Metrik perilaku - termasuk hari aktif selama 1, 7, dan 30 hari terakhir, panjang percakapan rata-rata, dan distribusi penggunaan model (misalnya, 49% permintaan yang ditangani oleh GPT-5)

Memori Pengguna

Memori pengguna adalah lapisan memori yang persisten dan dapat diedit yang memungkinkan personalisasi di seluruh percakapan. Memori ini menyimpan informasi yang relatif stabil-seperti nama pengguna, peran atau tujuan karier, proyek yang sedang berjalan, hasil sebelumnya, dan preferensi pembelajaran-dan disuntikkan ke dalam setiap percakapan baru untuk menjaga kesinambungan dari waktu ke waktu.

Memori ini dapat diperbarui dengan dua cara:

• Pembaruan eksplisit terjadi ketika pengguna secara langsung mengelola memori dengan instruksi seperti "ingat ini" atau "hapus ini dari memori."

• Pembaruan implisit terjadi ketika sistem mengidentifikasi informasi yang memenuhi kriteria penyimpanan OpenAI-seperti nama atau jabatan yang telah dikonfirmasi-dan menyimpannya secara otomatis, sesuai dengan persetujuan default pengguna dan pengaturan memori.

Ringkasan Percakapan Terakhir

Ringkasan percakapan terbaru adalah lapisan konteks lintas sesi yang ringan yang menjaga kesinambungan tanpa memutar ulang atau mengambil riwayat obrolan lengkap. Alih-alih mengandalkan pengambilan dinamis, seperti pada pendekatan berbasis RAG tradisional, ringkasan ini dihitung sebelumnya dan disuntikkan langsung ke dalam setiap percakapan baru.

Lapisan ini hanya meringkas pesan pengguna, tidak termasuk balasan asisten. Ukurannya sengaja dibatasi-biasanya sekitar 15 entri-dan hanya menyimpan sinyal tingkat tinggi tentang minat terkini daripada konten yang mendetail. Karena tidak bergantung pada penyematan atau pencarian kemiripan, lapisan ini menjaga latensi dan konsumsi token tetap rendah.

Pesan Sesi Terkini

Pesan sesi saat ini berisi riwayat pesan lengkap dari percakapan yang sedang berlangsung dan memberikan konteks jangka pendek yang diperlukan untuk tanggapan yang koheren dan bergantian. Lapisan ini mencakup input pengguna dan balasan asisten, tetapi hanya selama sesi tetap aktif.

Karena model ini beroperasi dalam batas token yang tetap, riwayat ini tidak dapat bertambah tanpa batas. Ketika batas tersebut tercapai, sistem akan menghapus pesan-pesan yang paling awal untuk memberi ruang bagi pesan-pesan yang lebih baru. Pemotongan ini hanya mempengaruhi sesi saat ini: memori pengguna jangka panjang dan ringkasan percakapan terbaru tetap utuh.

Sistem Memori Claude

Claude mengambil pendekatan yang berbeda untuk manajemen memori. Daripada menyuntikkan kumpulan komponen memori yang besar dan tetap ke dalam setiap prompt - seperti yang dilakukan ChatGPT - Claude menggabungkan memori pengguna yang persisten dengan alat sesuai permintaan dan pengambilan selektif. Konteks historis diambil hanya ketika model menilainya relevan, sehingga memungkinkan sistem untuk menukar kedalaman kontekstual dengan biaya komputasi.

Konteks permintaan Claude terstruktur sebagai berikut:

[0] Perintah Sistem (instruksi statis)

[1] Kenangan Pengguna

[2] Riwayat Percakapan

[3] Pesan Saat Ini

Perbedaan utama antara Claude dan ChatGPT terletak pada bagaimana riwayat percakapan diambil dan bagaimana memori pengguna diperbarui dan dipelihara.

Memori Pengguna

Di Claude, memori pengguna membentuk lapisan konteks jangka panjang yang serupa dengan memori pengguna ChatGPT, tetapi dengan penekanan yang lebih kuat pada pembaruan otomatis yang digerakkan oleh latar belakang. Memori ini disimpan dalam format terstruktur (dibungkus dengan tag bergaya XML) dan dirancang untuk berkembang secara bertahap dari waktu ke waktu dengan campur tangan pengguna yang minimal.

Claude mendukung dua jalur pembaruan:

• Pembaruan implisit - Sistem secara berkala menganalisis konten percakapan dan memperbarui memori di latar belakang. Pembaruan ini tidak diterapkan dalam waktu nyata, dan memori yang terkait dengan percakapan yang dihapus secara bertahap dipangkas sebagai bagian dari pengoptimalan yang sedang berlangsung.

• Pembaruan eksplisit - Pengguna dapat secara langsung mengelola memori melalui perintah seperti "ingat ini" atau "hapus ini", yang dijalankan melalui alat memory_user_edits khusus.

Dibandingkan dengan ChatGPT, Claude menempatkan tanggung jawab yang lebih besar pada sistem itu sendiri untuk memperbaiki, memperbarui, dan memangkas memori jangka panjang. Hal ini mengurangi kebutuhan pengguna untuk secara aktif mengkurasi apa yang disimpan.

Riwayat Percakapan

Untuk riwayat percakapan, Claude tidak bergantung pada ringkasan tetap yang disuntikkan ke dalam setiap permintaan. Sebaliknya, Claude mengambil konteks masa lalu hanya ketika model memutuskan bahwa hal itu diperlukan, menggunakan tiga mekanisme yang berbeda. Hal ini untuk menghindari membawa riwayat yang tidak relevan ke depan dan menjaga penggunaan token tetap terkendali.

Komponen	Tujuan	Bagaimana Ini Digunakan
Jendela Bergulir (Percakapan Saat Ini)	Menyimpan riwayat pesan lengkap dari percakapan saat ini (bukan ringkasan), mirip dengan konteks sesi ChatGPT	Disuntikkan secara otomatis. Batas token adalah ~190K; pesan lama akan dihapus setelah batas tercapai
conversation_search alat	Mencari percakapan sebelumnya berdasarkan topik atau kata kunci, mengembalikan tautan percakapan, judul, dan kutipan pesan pengguna/asisten	Dipicu ketika model menentukan bahwa detail historis diperlukan. Parameter termasuk query (istilah pencarian) dan max_results (1-10)
recent_chats alat	Mengambil percakapan terbaru dalam rentang waktu tertentu (misalnya, "3 hari terakhir"), dengan hasil yang diformat sama seperti conversation_search	Dipicu ketika konteks terkini dalam cakupan waktu relevan. Parameter meliputi n (jumlah hasil), sort_order, dan rentang waktu

Di antara komponen-komponen ini, conversation_search sangat penting. Ini dapat menampilkan hasil yang relevan bahkan untuk kueri yang diucapkan secara longgar atau multibahasa, yang menunjukkan bahwa ini beroperasi pada tingkat semantik daripada mengandalkan pencocokan kata kunci yang sederhana. Hal ini kemungkinan melibatkan pengambilan berbasis penyematan, atau pendekatan hibrida yang pertama-tama menerjemahkan atau menormalkan kueri ke dalam bentuk kanonik dan kemudian menerapkan kata kunci atau pengambilan hibrida.

Secara keseluruhan, pendekatan pencarian berdasarkan permintaan Claude memiliki beberapa kekuatan penting:

• Pengambilan tidak dilakukan secara otomatis: Pemanggilan alat dipicu oleh penilaian model itu sendiri. Misalnya, ketika pengguna merujuk ke "proyek yang kita bahas terakhir kali," Claude dapat memutuskan untuk memanggil conversation_search untuk mengambil konteks yang relevan.

• Konteks yang lebih kaya saat dibutuhkan: Hasil yang diperoleh dapat mencakup kutipan respons asisten, sedangkan ringkasan ChatGPT hanya menangkap pesan pengguna. Hal ini membuat Claude lebih cocok untuk kasus penggunaan yang membutuhkan konteks percakapan yang lebih dalam atau lebih tepat.

• Efisiensi yang lebih baik secara default: Karena konteks historis tidak disuntikkan kecuali jika diperlukan, sistem menghindari membawa sejumlah besar riwayat yang tidak relevan ke depan, mengurangi konsumsi token yang tidak perlu.

Imbalannya juga sama jelasnya. Memperkenalkan pengambilan sesuai permintaan meningkatkan kompleksitas sistem: indeks harus dibangun dan dipelihara, kueri dieksekusi, hasil diberi peringkat, dan terkadang diberi peringkat ulang. Latensi ujung ke ujung juga menjadi kurang dapat diprediksi dibandingkan dengan konteks yang telah dihitung sebelumnya dan selalu diinjeksikan. Selain itu, model harus belajar untuk memutuskan kapan pengambilan diperlukan. Jika keputusan tersebut gagal, konteks yang relevan mungkin tidak akan pernah diambil sama sekali.

Kendala di Balik Pengambilan Sesuai Permintaan Gaya Claude

Mengadopsi model pengambilan berdasarkan permintaan menjadikan basis data vektor sebagai bagian penting dari arsitektur. Pengambilan percakapan menempatkan tuntutan yang sangat tinggi pada penyimpanan dan eksekusi kueri, dan sistem harus memenuhi empat kendala pada saat yang bersamaan.

1. Toleransi Latensi Rendah

Dalam sistem percakapan, latensi P99 biasanya harus berada di bawah ~ 20 ms. Penundaan di luar itu akan segera terlihat oleh pengguna. Hal ini menyisakan sedikit ruang untuk ketidakefisienan: pencarian vektor, pemfilteran metadata, dan pemeringkatan hasil harus dioptimalkan dengan hati-hati. Kemacetan di titik mana pun dapat menurunkan seluruh pengalaman percakapan.

2. Kebutuhan Pencarian Hibrida

Permintaan pengguna sering kali menjangkau beberapa dimensi. Permintaan seperti "diskusi tentang RAG dari minggu lalu" menggabungkan relevansi semantik dengan pemfilteran berbasis waktu. Jika database hanya mendukung pencarian vektor, database dapat mengembalikan 1.000 hasil yang secara semantik mirip, hanya untuk pemfilteran lapisan aplikasi untuk menguranginya menjadi sedikit - membuang sebagian besar komputasi. Agar praktis, basis data harus mendukung kueri gabungan vektor dan skalar.

3. Pemisahan Penyimpanan-Komputasi

Riwayat percakapan menunjukkan pola akses panas-dingin yang jelas. Percakapan terbaru sering ditanyakan, sementara percakapan lama jarang disentuh. Jika semua vektor harus disimpan di memori, menyimpan puluhan juta percakapan akan menghabiskan ratusan gigabyte RAM - biaya yang tidak praktis dalam skala besar. Agar dapat digunakan, sistem harus mendukung pemisahan penyimpanan-komputasi, menyimpan data panas di memori dan data dingin di penyimpanan objek, dengan vektor yang dimuat sesuai permintaan.

4. Pola Kueri yang Beragam

Pengambilan percakapan tidak mengikuti pola akses tunggal. Beberapa kueri murni semantik (misalnya, "pengoptimalan kinerja yang kita diskusikan"), yang lain murni temporal ("semua percakapan dari minggu lalu"), dan banyak yang menggabungkan beberapa batasan ("diskusi terkait Python yang menyebutkan FastAPI dalam tiga bulan terakhir"). Perencana kueri basis data harus menyesuaikan strategi eksekusi dengan jenis kueri yang berbeda, daripada mengandalkan pencarian brute-force yang bersifat satu ukuran untuk semua.

Bersama-sama, keempat tantangan ini mendefinisikan kendala inti dari pencarian percakapan. Sistem apa pun yang ingin menerapkan pencarian berdasarkan permintaan gaya Claude harus mengatasi semuanya dengan cara yang terkoordinasi.

Mengapa Milvus 2.6 Bekerja dengan Baik untuk Pengambilan Percakapan

Pilihan desain di Milvus 2.6 selaras dengan persyaratan inti dari pengambilan percakapan sesuai permintaan. Di bawah ini adalah rincian dari kemampuan utama dan bagaimana kemampuan tersebut dipetakan ke dalam kebutuhan pencarian percakapan yang sebenarnya.

Pengambilan Hibrida dengan Vektor Padat dan Jarang

Milvus 2.6 secara native mendukung penyimpanan vektor padat dan vektor jarang dalam koleksi yang sama dan secara otomatis menggabungkan hasilnya pada waktu kueri. Vektor padat (misalnya, penyematan 768 dimensi yang dihasilkan oleh model seperti BGE-M3) menangkap kemiripan semantik, sementara vektor jarang (biasanya dihasilkan oleh BM25) mempertahankan sinyal kata kunci yang tepat.

Untuk kueri seperti "diskusi tentang RAG dari minggu lalu," Milvus mengeksekusi pengambilan semantik dan pengambilan kata kunci secara paralel, kemudian menggabungkan hasilnya melalui pemeringkatan ulang. Dibandingkan dengan menggunakan salah satu pendekatan saja, strategi hibrida ini memberikan daya ingat yang jauh lebih tinggi dalam skenario percakapan nyata.

Pemisahan Penyimpanan-Komputasi dan Pengoptimalan Kueri

Milvus 2.6 mendukung penyimpanan berjenjang dalam dua cara:

• Data panas dalam memori, data dingin dalam penyimpanan objek

• Indeks dalam memori, data vektor mentah dalam penyimpanan objek

Dengan desain ini, menyimpan satu juta entri percakapan dapat dicapai dengan sekitar 2 GB memori dan 8 GB penyimpanan objek. Dengan penyetelan yang tepat, latensi P99 dapat tetap berada di bawah 20 ms, bahkan dengan pemisahan penyimpanan-komputasi yang diaktifkan.

Penghancuran JSON dan Pemfilteran Skalar Cepat

Milvus 2.6 mengaktifkan JSON Shredding secara default, meratakan bidang JSON yang bersarang menjadi penyimpanan kolumnar. Hal ini meningkatkan kinerja penyaringan skalar sebesar 3-5× menurut tolok ukur resmi (keuntungan aktual bervariasi menurut pola kueri).

Pengambilan percakapan sering kali membutuhkan pemfilteran berdasarkan metadata seperti ID pengguna, ID sesi, atau rentang waktu. Dengan JSON Shredding, kueri seperti "semua percakapan dari pengguna A dalam seminggu terakhir" dapat dieksekusi secara langsung pada indeks kolom, tanpa mengurai gumpalan JSON secara berulang-ulang.

Kontrol Sumber Terbuka dan Fleksibilitas Operasional

Sebagai sistem sumber terbuka, Milvus menawarkan tingkat kontrol arsitektural dan operasional yang tidak dimiliki oleh solusi kotak hitam yang tertutup. Tim dapat mengatur parameter indeks, menerapkan strategi tiering data, dan menyesuaikan penerapan terdistribusi agar sesuai dengan beban kerja mereka.

Fleksibilitas ini menurunkan hambatan untuk masuk: tim kecil dan menengah dapat membangun sistem pengambilan percakapan berskala jutaan hingga puluhan juta tanpa bergantung pada anggaran infrastruktur yang besar.

Mengapa ChatGPT dan Claude Mengambil Jalur yang Berbeda

Pada tingkat tinggi, perbedaan antara sistem memori ChatGPT dan Claude terletak pada bagaimana masing-masing menangani lupa. ChatGPT mendukung pelupaan proaktif: setelah memori melebihi batas yang ditetapkan, konteks yang lebih lama akan dibuang. Ini menukar kelengkapan dengan kesederhanaan dan perilaku sistem yang dapat diprediksi. Claude lebih menyukai pelupaan yang tertunda. Secara teori, riwayat percakapan dapat tumbuh tanpa batas, dengan penarikan kembali yang didelegasikan ke sistem pengambilan sesuai permintaan.

Jadi mengapa kedua sistem tersebut memilih jalur yang berbeda? Dengan kendala teknis yang dijelaskan di atas, jawabannya menjadi jelas: setiap arsitektur hanya dapat berjalan jika infrastruktur yang mendasarinya dapat mendukungnya.

Jika pendekatan Claude dicoba pada tahun 2020, kemungkinan besar tidak praktis. Pada saat itu, basis data vektor sering kali mengalami latensi ratusan milidetik, kueri hibrida tidak didukung dengan baik, dan penggunaan sumber daya meningkat pesat seiring dengan bertambahnya data. Dalam kondisi seperti itu, pengambilan berdasarkan permintaan akan dianggap sebagai rekayasa yang berlebihan.

Pada tahun 2025, lanskap telah berubah. Kemajuan dalam infrastruktur - yang digerakkan oleh sistem seperti Milvus 2.6 - telahmembuat pemisahan penyimpanan-komputasi, pengoptimalan kueri, pengambilan hibrida padat-jarang, dan penghancuran JSON menjadi layak untuk diproduksi. Kemajuan ini mengurangi latensi, mengendalikan biaya, dan membuat pengambilan selektif menjadi praktis dalam skala besar. Hasilnya, alat sesuai permintaan dan memori berbasis pengambilan tidak hanya menjadi layak, tetapi juga semakin menarik, terutama sebagai fondasi untuk sistem gaya agen.

Pada akhirnya, pilihan arsitektur mengikuti apa yang dimungkinkan oleh infrastruktur.

Kesimpulan

Dalam sistem dunia nyata, desain memori bukanlah pilihan biner antara konteks yang telah dikomputasi sebelumnya dan pengambilan sesuai permintaan. Arsitektur yang paling efektif biasanya bersifat hibrida, yang menggabungkan kedua pendekatan tersebut.

Pola yang umum adalah menyuntikkan percakapan terbaru melalui jendela konteks geser, menyimpan preferensi pengguna yang stabil sebagai memori tetap, dan mengambil riwayat yang lebih lama sesuai permintaan melalui pencarian vektor. Seiring dengan semakin matangnya sebuah produk, keseimbangan ini dapat bergeser secara bertahap-dari konteks yang terutama dihitung sebelumnya menjadi semakin digerakkan oleh pencarian-tanpa memerlukan pengaturan ulang arsitektur yang mengganggu.

Bahkan ketika memulai dengan pendekatan prakomputasi, penting untuk mendesain dengan mempertimbangkan migrasi. Memori harus disimpan dengan pengenal yang jelas, stempel waktu, kategori, dan referensi sumber. Ketika pengambilan dapat dilakukan, penyematan dapat dibuat untuk memori yang ada dan ditambahkan ke basis data vektor bersama dengan metadata yang sama, sehingga logika pengambilan dapat diperkenalkan secara bertahap dan dengan gangguan yang minimal.

Ada pertanyaan atau ingin mendalami fitur-fitur Milvus terbaru? Bergabunglah dengan saluran Discord kami atau ajukan pertanyaan di GitHub. Anda juga dapat memesan sesi tatap muka selama 20 menit untuk mendapatkan wawasan, panduan, dan jawaban atas pertanyaan Anda melalui Milvus Office Hours.