Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Praktik terbaik
Memilih data yang dapat di-cache
Caching semantik sangat cocok untuk pertanyaan berulang yang tanggapannya relatif stabil, sedangkan respons real-time atau sangat dinamis seringkali merupakan kandidat yang buruk untuk caching.
Gunakan filter tag dan numerik yang berasal dari konteks aplikasi yang ada (seperti ID produk, kategori, wilayah, atau segmen pengguna) untuk memutuskan kueri dan tanggapan mana yang memenuhi syarat untuk caching dan untuk meningkatkan relevansi klik cache.
Penyetelan ambang kesamaan
Ambang kesamaan mengontrol trade-off antara hit rate cache dan kualitas jawaban. Pilih ambang batas yang menyeimbangkan penghematan biaya dengan akurat untuk kasus penggunaan Anda:
| Ambang batas | Tingkat hit | Risiko kualitas | Terbaik untuk |
|---|---|---|---|
| 0,95 (ketat) | Rendah (~ 25%) | Sangat rendah | Aplikasi medis, hukum, keuangan |
| 0,90 (sedang) | Sedang (~ 55%) | Rendah | Chatbots umum |
| 0,80 (seimbang) | Tinggi (~ 75%) | Rendah—Sedang | FAQ bot, dukungan TI |
| 0,75 (santai) | Sangat tinggi (~ 90%) | Sedang | High-volume pertanyaan berulang |
penting
Mulailah dengan ambang batas yang lebih tinggi (0,90—0,95) dan turunkan secara bertahap sambil memantau akurasi. Gunakan A/B pengujian untuk menemukan keseimbangan optimal untuk beban kerja Anda.
Kueri mandiri versus percakapan
Untuk kueri mandiri — Terapkan caching semantik langsung pada teks kueri pengguna.
Untuk percakapan multi-putaran — Pertama gunakan memori percakapan Anda untuk mengambil fakta kunci dan pesan terbaru yang diperlukan untuk menjawab giliran saat ini. Kemudian terapkan caching semantik ke kombinasi pesan pengguna saat ini dan konteks yang diambil, alih-alih menyematkan seluruh dialog mentah.
Mengatur periode pembatalan cache
Gunakan TTL untuk mengontrol berapa lama respons cache disajikan sebelum dibuat ulang pada cache yang hilang.
| Jenis data | TTL yang direkomendasikan | Dasar Pemikiran |
|---|---|---|
| Fakta statis (dokumentasi, kebijakan) | 24 jam | Fakta jarang berubah |
| Informasi Produk | 12—24 jam | Diperbarui setiap hari di sebagian besar katalog |
| Tanggapan asisten umum | 1—4 jam | Seimbangkan kesegaran dengan hit rate |
| Real-time data (harga, persediaan) | 5—15 menit | Data sering berubah |
| Konteks percakapan | 30 menit | Session-scoped, berumur pendek |
# Set TTL with random jitter to spread out cache invalidations import random base_ttl = 82800 # ~23 hours jitter = random.randint(0, 3600) # Up to 1 hour of jitter valkey_client.expire(cache_key, base_ttl + jitter)
Tip
Setel TTL yang sesuai dengan kasus penggunaan aplikasi Anda dan seberapa sering data atau output model Anda berubah. TTL yang lebih lama meningkatkan tingkat hit cache tetapi meningkatkan risiko jawaban yang sudah ketinggalan zaman. TTL yang lebih pendek membuat respons lebih segar tetapi tingkat hit cache lebih rendah dan membutuhkan lebih banyak inferensi LLM.
Pemantauan dan pelacakan biaya
Lacak metrik kinerja cache untuk mengoptimalkan cache semantik Anda dari waktu ke waktu:
def record_cache_event(valkey_client, event_type: str): """Track cache hits and misses using atomic counters.""" valkey_client.incr(f"cache:metrics:{event_type}") # Also track hourly for time-series analysis from datetime import datetime hour_key = datetime.now().strftime("%Y%m%d%H") counter_key = f"cache:metrics:{event_type}:{hour_key}" valkey_client.incr(counter_key) valkey_client.expire(counter_key, 86400 * 7) # Keep 7 days def get_cache_stats(valkey_client) -> dict: """Get current cache performance metrics.""" hits = int(valkey_client.get("cache:metrics:hit") or 0) misses = int(valkey_client.get("cache:metrics:miss") or 0) total = hits + misses hit_rate = hits / total if total > 0 else 0 avg_cost_per_call = 0.015 # Example: ~$0.015 per LLM call savings = hits * avg_cost_per_call return { "total_requests": total, "hits": hits, "misses": misses, "hit_rate": round(hit_rate, 3), "estimated_savings_usd": round(savings, 2), }
Manajemen memori
Setel kebijakan maxmemory — Konfigurasikan
maxmemory-policy allkeys-lrupada ElastiCache klaster Anda untuk secara otomatis mengusir entri cache yang paling jarang digunakan saat klaster mencapai batas memorinya.Rencanakan kapasitas - Setiap entri cache biasanya membutuhkan sekitar 4—6 KB (dimensi penyematan × 4 byte+teks kueri+teks respons). ElastiCache Instans 1 GB dapat menyimpan sekitar 170.000 entri yang di-cache.
Gunakan pembatalan cache untuk data basi — Saat data yang mendasarinya berubah, gunakan pencarian teks untuk menemukan dan membatalkan entri cache terkait:
def invalidate_by_topic(valkey_client, topic_keyword: str): """Remove cached entries matching a topic after a data update.""" results = valkey_client.execute_command( "FT.SEARCH", "semantic_cache", f"@query:{topic_keyword}", "NOCONTENT", # Only return keys, not fields ) if results[0] > 0: keys = results[1:] for key in keys: valkey_client.delete(key) print(f"Invalidated {len(keys)} cached entries for '{topic_keyword}'")
