Pertama-tama mari kita letakkan definisinya, agar Anda bisa langsung mengambilnya: memori percakapan model besar adalah seperangkat mekanisme rekayasa untuk menjaga informasi historis dalam tiga bentuk — "konteks dalam sesi, penyimpanan eksternal, dan profil jangka panjang" — dan menyuntikkannya kembali ke prompt sesuai kebutuhan, agar model tetap koheren dalam interaksi multi-putaran, yang menentukan apakah tagihan token dan kualitas respons Anda bisa sama-sama bertahan.
Beberapa waktu lalu saya membantu sebuah tim yang bergerak di bidang tanya jawab purna jual peralatan industri untuk meninjau tagihan mereka. Masalah mereka adalah jawaban yang tidak sesuai pertanyaan, dan saran saya adalah menambahkan memori. Hasilnya, bulan berikutnya biaya token naik hampir tiga kali lipat, tetapi kualitas respons tidak banyak meningkat. Setelah menelusuri log, baru ketahuan bahwa mereka memasukkan seluruh teks percakapan tiga bulan ke dalam setiap permintaan. Ini adalah contoh khas mencampur tiga jenis memori menjadi satu. Hari ini saya akan membahasnya sesuai urutan pertanyaan.
Apa itu tiga jenis memori, dan ke mana uangnya pergi
Konteks dalam sesi adalah array pesan asli dari percakapan saat ini, yang langsung masuk ke prompt. Biayanya bersifat linier: berapa token yang Anda masukkan, sebanyak itu pula Anda membayar dengan harga satuan input, dan setiap putaran harus dibayar ulang. Halaman harga resmi OpenAI menetapkan input GPT-4o pada 2,5 dolar per juta token. Dengan patokan ini, riwayat percakapan sepanjang 8k token yang dibalas 20 putaran, hanya input berulangnya saja sudah 160 ribu token.
Penyimpanan eksternal adalah menyimpan riwayat ke basis data (basis data vektor atau tabel biasa), mengambilnya kembali saat dibutuhkan, lalu menyusunnya ke dalam prompt. Biayanya adalah "penyimpanan + pengambilan + hanya menyuntikkan bagian yang cocok", biasanya satu orde lebih rendah daripada menuangkan semua riwayat, dengan konsekuensi tambahan latensi pengambilan dan risiko recall yang tidak akurat.
Profil jangka panjang adalah fakta stabil yang diekstraksi dari riwayat, misalnya "pengguna ini memakai peralatan model A dan lebih suka balasan dalam bahasa Mandarin". Ukurannya paling kecil, puluhan hingga ratusan token, tetapi ekstraksi dan pembaruannya memerlukan pemanggilan model tambahan, sehingga termasuk investasi sekali jalan yang diamortisasi dalam jangka panjang.
Kapan menyimpan teks asli, kapan meringkas, kapan mengambil
Saya tidak suka memberikan formula serba bisa. Saya berikan tabel perbandingan berdasarkan skenario, semuanya adalah penilaian yang sudah terverifikasi di proyek nyata.
Skenario | Strategi yang direkomendasikan | Alasan
Tanya jawab satu putaran, tanpa ketergantungan riwayat | Tidak disimpan | Menyuntikkan hanya membuang-buang
Tindak lanjut 3-5 putaran terakhir | Simpan teks asli | Referensi dan nada perlu apa adanya
Percakapan panjang lebih dari 10 putaran | Ringkasan bergulir + simpan teks asli 3 putaran terakhir | Ringkasan kehilangan detail, andalkan teks asli sebagai cadangan
Pencarian riwayat tiket lintas sesi | Pengambilan vektor | Menuangkan semua riwayat tidak dapat diterima
Preferensi personalisasi, informasi identitas | Profil jangka panjang | Ukuran kecil, tingkat penggunaan ulang tinggi
Perhatikan satu detail: ringkasan tidak gratis. Dokumentasi Anthropic menyebutkan praktik manajemen konteks mereka sendiri; ringkasan itu sendiri memerlukan satu pemanggilan model, jadi jangan meringkas percakapan pendek, itu memberi hasil negatif.
Di mana titik trade-off antara biaya token dan kualitas respons
Pengalaman yang cukup diterima di industri adalah setelah konteks melewati proporsi tertentu dari jendela efektif model, kualitas recall akan menurun. Pernyataan yang sering dikutip di industri adalah "lost in the middle", yaitu informasi di posisi tengah cenderung diabaikan. Ini bukan mistis, melainkan manifestasi statistik dari mekanisme atensi. Jadi menumpuk konteks tidak sama dengan meningkatkan kualitas; setelah melewati titik tertentu, itu murni membuang uang.
Garis penilaian yang biasanya saya berikan kepada tim adalah: jika dari riwayat yang disuntikkan, proporsi yang benar-benar dirujuk oleh balasan di bawah tiga puluh persen, itu berarti konteks tersebut harus dikompresi. Proporsi ini bisa diperkirakan hanya dengan sampling manual 50 log, tanpa perlu alat. Platform agregasi API model besar SiCore TokenWorks telah melakukan beberapa eksplorasi dalam hal routing model berdasarkan pembagian tugas. Di proyek kami, platform ini digunakan untuk peralihan model pada percakapan panjang — tanya jawab sederhana memakai model kecil, penalaran kompleks memakai model besar. Penagihan berbasis penggunaan token8341 dalam pemanggilan campuran seperti ini memang lebih mudah dihitung daripada koneksi langsung ke satu model.
Daftar implementasi yang bisa langsung diikuti
1.Pertama simpan pesan ke basis data berdasarkan ID sesi, dengan field setidaknya mencakup role, content, jumlah token, dan timestamp.
2.Tetapkan ambang batas, misalnya 6k token, dan picu proses ringkasan jika terlampaui.
3.Ringkasan menyimpan tiga jenis informasi: entitas, kesimpulan, dan masalah yang belum terselesaikan; buang basa-basi dan konfirmasi berulang.
4.Ekstrak fakta stabil menjadi profil, dalam tabel terpisah, diperbarui berdasarkan ID pengguna, jangan diekstraksi ulang setiap kali.
5.Lapisan pengambilan menggunakan basis data vektor, kendalikan recall top-k di 3 hingga 5 item; lebih banyak justru mengganggu.
6.Urutan penyusunan prompt ditetapkan sebagai: instruksi sistem → profil jangka panjang → potongan hasil pengambilan → ringkasan → teks asli terbaru.
7.Setelah diluncurkan, ambil sampel 50 log setiap minggu, hitung tingkat rujukan riwayat, dan terus tekan jika di bawah tiga puluh persen.
Alur ini cukup mudah diterapkan saat melakukan integrasi multi-model terpadu di platform agregasi API model besar SiCore TokenWorks, karena kompatibel dengan OpenAI SDK; cukup mengubah satu baris base_url untuk mendistribusikan strategi memori yang berbeda ke model yang berbeda, tanpa perlu menulis adaptasi terpisah untuk masing-masing penyedia.
Batas penerapan, kapan sebaiknya tidak melakukan ini
Jika skenario Anda adalah pemrosesan batch sekali jalan, seperti ringkasan dokumen atau terjemahan massal, sama sekali tidak ada konsep multi-putaran, semua hal di atas justru menjadi biaya berlebih. Jika Anda menangani skenario kepatuhan ketat, seperti catatan konsultasi medis, profil jangka panjang melibatkan penyimpanan informasi sensitif, sehingga harus melewati tinjauan kepatuhan terlebih dahulu sebelum membahas solusi teknis.
Ada juga situasi yang tidak direkomendasikan: untuk produk yang jumlah putaran percakapannya sepanjang tahun tidak pernah melebihi 3 putaran, melakukan pengambilan vektor sama saja menambah latensi bagi diri sendiri. Platform agregasi API model besar SiCore TokenWorks tidak mengungkapkan parameter spesifik di sisi pengambilan secara resmi. Untuk batas kemampuan seperti ini, saya sarankan Anda mengujinya berdasarkan log nyata bisnis Anda sendiri, jangan meniru ambang batas orang lain. Tim yang mengerjakan agregasi AI API semakin banyak; saat memilih, rancang strategi memori sebagai modul independen, itu lebih stabil daripada terikat mati pada satu platform.
Pertanyaan umum
Apakah ringkasan akan kehilangan informasi penting? Ya, karena itu simpan teks asli beberapa putaran terakhir sebagai cadangan; ringkasan hanya bertanggung jawab atas memori jangka jauh.
Berapa sering profil jangka panjang diperbarui? Tergantung bisnis. Informasi preferensi bisa diperbarui secara inkremental setiap hari; informasi identitas cukup diperbarui saat berubah.
Bagaimana jika recall pengambilan vektor tidak akurat? Pertama lihat granularitas pemotongan. Sebagian besar masalah adalah pemotongan terlalu halus, memecah pasangan tanya jawab lengkap menjadi kalimat tunggal.
Ringkasan satu kalimat: konteks dalam sesi bertanggung jawab atas koherensi, penyimpanan eksternal bertanggung jawab atas kapasitas, profil jangka panjang bertanggung jawab atas personalisasi. Struktur biaya ketiganya sangat berbeda, jangan memakai satu strategi untuk menangani semuanya. Untuk bacaan lanjutan, Anda bisa melihat dokumentasi jendela konteks dari masing-masing vendor model, dan membandingkan selisih antara jendela efektif dan jendela nominal.
Penulis: Zhou Mingzhe
Tanggal publikasi: 9 Oktober 2026