Tair (Redis® OSS-Compatible):Tair untuk memori jangka pendek Agen AI

Skenario yang berlaku

Pola desain dalam artikel ini berlaku untuk skenario Agen AI berikut:

• Agen percakapan yang perlu mempertahankan konteks dalam percakapan multi-putaran, seperti bot layanan pelanggan, asisten belanja, dan asisten pribadi.

• Skema interaktif real-time yang sensitif terhadap latensi end-to-end dan memerlukan operasi baca/tulis memori dalam milidetik.

• Skema pemanggilan multi-tool dengan risiko penulisan konkuren, seperti Agen AI yang memanggil beberapa tool secara bersamaan.

• Layanan online dengan trafik fluktuatif yang memerlukan skalabilitas elastis.

Mengapa sistem memori membutuhkan Tair

Sistem memori Agen AI sangat sensitif terhadap latensi. Menurut Hukum Little (Konkurensi ≈ QPS × Latensi), jika latensi akses memori meningkat dari 5 ms menjadi 50 ms, jumlah permintaan yang sedang diproses akan meningkat sepuluh kali lipat. Hal ini dapat dengan cepat menghabiskan sumber daya seperti koneksi, thread, dan antrian. Karena setiap giliran percakapan melibatkan banyak operasi baca/tulis memori, latensi akan bertambah, berpotensi menyebabkan antrian, timeout, bahkan kegagalan berantai.

Perbedaan antara 5 ms dan 50 ms bukan hanya optimisasi pengalaman pengguna; ini adalah batas pemisah antara sistem yang dapat diskalakan secara stabil dan sistem yang tidak bisa. Inilah alasan utama Agen AI Taobao Flash Sale memilih Tair untuk lapisan memorinya. Dengan kernel multi-threaded eksklusifnya, Tair menyediakan latensi rendah yang stabil. Ini menjaga akses memori tetap dalam ambang batas aman, mencegah siklus degradasi kinerja di bawah beban konkurensi tinggi.

Memori model — List

Memori model menyimpan riwayat percakapan untuk diproses oleh model bahasa besar (LLM). Di setiap giliran, agen mencatat input pengguna dan tanggapannya sendiri, lalu meneruskannya sebagai konteks ke model pada putaran inferensi berikutnya.

Riwayat ini disimpan dalam Tair List, dengan satu kunci per sesi:

Key:  memory:model:{sessionId}
Type: List

Contoh data:
[
  {"role": "user",      "content": "Saya ingin memesan milk tea."},
  {"role": "assistant", "content": "Saya menemukan 3 toko milk tea di dekat Anda...", "cards": [...]},
  {"role": "user",      "content": "Yang ini, sedikit gula dan tanpa es."},
  {"role": "assistant", "content": "Dipilih: Baiya Juexian, sedikit gula, tanpa es, ukuran besar..."}
]

Operasi inti:

# Setelah setiap giliran percakapan, tambahkan catatan dialog baru
RPUSH memory:model:{sessionId} "{Catatan Percakapan JSON}"

# Sebelum inferensi model, baca N giliran terakhir sebagai konteks
LRANGE memory:model:{sessionId} -{N} -1

# Tetapkan waktu kedaluwarsa sesi (misalnya, 30 menit)
EXPIRE memory:model:{sessionId} 1800

Memori konteks bisnis — Hash

Memori konteks bisnis menyimpan informasi status terstruktur dari proses bisnis. Lapisan tool dan pemroses maksud agen melakukan kueri dan memperbarui informasi ini saat mengeksekusi logika bisnis.

Memori ini dibagi menjadi enam submodul berdasarkan domain bisnis dan disimpan dalam Tair Hash:

Key:  memory:context:{sessionId}
Type: Hash

Struktur field:
{
  "session":      "{Metadata sesi: ID pengguna, channel, tahap sesi, dll.}",
  "search":       "{Status pencarian: kueri saat ini, hasil pencarian, daftar produk yang direkomendasikan, dll.}",
  "order":        "{Status pesanan: isi keranjang belanja, SKU yang dipilih, jumlah item, dll.}",
  "conversation": "{Status percakapan: maksud saat ini, maksud sebelumnya, flag pergantian maksud, dll.}",
  "coupon":       "{Informasi kupon: kupon tersedia, kupon yang dipilih, dll.}",
  "bizState":     "{Status bisnis: alamat pengiriman, metode pengiriman, status pembayaran, dll.}"
}

Operasi inti:

# Perbarui satu submodul (misalnya, saat pengguna mengonfirmasi alamat pengiriman)
HSET memory:context:{sessionId} bizState "{Status Bisnis Terbaru JSON}"

# Baca submodul tertentu
HGET memory:context:{sessionId} order

# Baca semua konteks sekaligus (untuk skenario yang memerlukan informasi global, seperti pengenalan maksud)
HGETALL memory:context:{sessionId}

# Tetapkan waktu kedaluwarsa
EXPIRE memory:context:{sessionId} 1800

Perbandingan struktur data

Kinerja kernel Tair

Tair menggunakan model multi-threaded, memberikan kinerja baca/tulis hingga tiga kali lipat dibandingkan instans Redis open-source dengan spesifikasi yang sama. Artinya, untuk ukuran instans yang sama, Tair dapat menangani throughput operasional tiga kali lebih besar daripada Redis open-source.

Keunggulan kinerja ini sangat krusial dalam skenario Agen AI. Satu percakapan pengguna dapat memicu puluhan operasi Tair, seperti membaca riwayat percakapan, memperbarui konteks bisnis, serta mendapatkan atau melepaskan kunci terdistribusi. Dengan model single-threaded Redis open-source, database dapat dengan mudah menjadi bottleneck di bawah beban konkurensi tinggi. Kernel multi-threaded Tair memungkinkan satu node memanfaatkan penuh sumber daya CPU multi-core, sehingga mampu menangani konkurensi lebih tinggi tanpa perlu menambah node.

Skalabilitas elastis dan tanpa hambatan

Dalam alur percakapan agen, data memori menunjukkan pola khas read-heavy: agen harus membaca seluruh riwayat percakapan dan konteks bisnis sebelum setiap putaran inferensi (operasi baca), sedangkan operasi tulis hanya terjadi untuk menambahkan catatan baru di akhir setiap giliran. Rasio baca terhadap tulis biasanya berkisar antara 5:1 hingga 10:1.

Tair mendukung arsitektur kluster dengan pemisahan baca/tulis. Tair kemudian secara otomatis mendistribusikan permintaan baca ke replika baca saja, sementara permintaan tulis diarahkan ke node primary. Jumlah replika baca saja dapat disesuaikan secara fleksibel dari 1 hingga 9, dan kluster dapat diskalakan horizontal dari 2 hingga 256 shard. Anda dapat meningkatkan throughput secara linear dengan menambah replika baca saja atau shard sebelum lonjakan trafik, lalu menurunkannya kembali setelahnya untuk mengurangi biaya.

Contoh

Trafik normal: Kluster 8-shard dengan 1 replika baca saja per shard memenuhi kebutuhan bisnis harian.

Acara Imlek (trafik puncak 5x–10x):

• Opsi 1: Skalakan menjadi 5 replika baca saja per shard untuk peningkatan throughput baca secara linear.

• Opsi 2: Skalakan menjadi kluster 16-shard dengan 3 replika baca saja per shard untuk menggandakan kapasitas baca dan tulis.

Operasi penskalaan ini sepenuhnya transparan bagi layanan Anda. Kluster Redis tradisional dapat menghasilkan error seperti -ASK dan -TRYAGAIN selama migrasi slot. Untuk skenario percakapan berbasis agen, kegagalan permintaan apa pun dapat menyebabkan gangguan percakapan atau kehilangan memori. Edisi cloud-native Tair mencapai skalabilitas tanpa hambatan melalui optimisasi tingkat kernel—data dimigrasikan secara atomik sebagai satu slot utuh (bukan per kunci), sehingga mencegah pemisahan slot. Pada saat yang sama, komponen kontrol terpusat mengoordinasikan perilaku kluster, menghasilkan efisiensi migrasi yang lebih tinggi dan pengambilan keputusan yang lebih tepat.

Skalabilitas bandwidth elastis

Selain tekanan QPS, acara tersebut juga menimbulkan tantangan bandwidth yang signifikan. Setiap pembacaan memori oleh Agen AI melibatkan transfer riwayat percakapan dan konteks bisnis, menghasilkan muatan data per permintaan yang jauh lebih besar dibandingkan pembacaan key-value sederhana dalam skenario caching tradisional. Selama jam sibuk, bandwidth dapat menjadi bottleneck sebelum CPU atau memori.

Arsitektur Tair menyediakan dua lapis elastisitas:

• Skalabilitas horizontal untuk bandwidth kluster: Dalam arsitektur kluster, Anda dapat meningkatkan total bandwidth instans dengan menambahkan lebih banyak load balancer (LB). Satu LB memiliki batas bandwidth 20 Gbps. Ketika jumlah shard melebihi delapan, Anda dapat menambahkan LB sesuai kebutuhan tanpa memutus koneksi yang ada.

• Bandwidth burstable: Saat trafik instan melebihi bandwidth tetap, sistem secara otomatis meningkatkan bandwidth dalam hitungan detik (hingga maksimum 288 MB/s per node). Sistem secara otomatis melepaskan bandwidth ketika trafik mereda dan hanya menagih Anda berdasarkan jumlah burst yang digunakan. Bandwidth burstable beroperasi secara independen untuk setiap shard. Jika sebuah shard mengalami bottleneck bandwidth akibat hot key, hanya bandwidth shard tersebut yang diperluas secara otomatis, sementara shard lain tidak terpengaruh.

  Catatan

  Bandwidth burstable sangat cocok untuk lonjakan trafik tak terduga yang umum dalam skenario Agen AI. Dibandingkan dengan pembelian paket bandwidth tetap berkapasitas tinggi di awal, bursting on-demand lebih hemat biaya.

Pembersihan TTL otomatis

Dengan menetapkan TTL yang wajar (misalnya, 30 menit) pada semua kunci sesi, penggunaan memori secara otomatis berkurang setelah puncak trafik tanpa intervensi manual. Dikombinasikan dengan skalabilitas elastis Tair, hal ini memungkinkan manajemen sumber daya sepenuhnya otomatis: penskalaan naik saat puncak, penskalaan turun saat lesu, dan pembersihan data kedaluwarsa secara otomatis.

Akibatnya, seluruh layanan memori tetap stabil selama lonjakan trafik Imlek, dengan latensi P99 konsisten terkendali pada tingkat milidetik.