Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Best Practices
Daten auswählen, die zwischengespeichert werden können
Semantisches Caching eignet sich gut für wiederholte Abfragen, deren Antworten relativ stabil sind, wohingegen Echtzeitantworten oder hochdynamische Antworten oft schlechte Kandidaten für das Caching sind.
Verwenden Sie Tag- und numerische Filter, die aus dem vorhandenen Anwendungskontext abgeleitet werden (z. B. Produkt-ID, Kategorie, Region oder Benutzersegment), um zu entscheiden, welche Abfragen und Antworten für das Zwischenspeichern in Frage kommen, und um die Relevanz von Cache-Treffern zu verbessern.
Optimierung des Schwellenwerts für Ähnlichkeit
Der Ähnlichkeitsschwellenwert steuert den Kompromiss zwischen der Cache-Trefferquote und der Antwortqualität. Wählen Sie einen Schwellenwert, der Kosteneinsparungen und Genauigkeit für Ihren Anwendungsfall in Einklang bringt:
| Threshold | Trefferquote | Qualitätsrisiko | Am besten geeignet für |
|---|---|---|---|
| 0,95 (streng) | Niedrig (~ 25%) | Sehr niedrig | Medizinische, rechtliche und finanzielle Anwendungen |
| 0,90 (mäßig) | Mittel (~ 55%) | Niedrig | Allgemeine Chatbots |
| 0,80 (ausgewogen) | Hoch (~ 75%) | Niedrig — Mittel | Häufig gestellte Fragen, Bots, IT-Support |
| 0,75 (entspannt) | Sehr hoch (~ 90%) | Mittel | High-volume sich wiederholende Abfragen |
Wichtig
Beginnen Sie mit einem höheren Schwellenwert (0,90—0,95) und senken Sie ihn schrittweise, während Sie gleichzeitig die Genauigkeit überwachen. Verwenden Sie A/B Tests, um das optimale Gleichgewicht für Ihre Arbeitslast zu finden.
Eigenständige Abfragen versus Konversationen
Für eigenständige Abfragen — Wenden Sie semantisches Caching direkt auf den Text der Benutzerabfrage an.
Für Konversationen mit mehreren Runden — Verwenden Sie zunächst Ihren Konversationsspeicher, um die wichtigsten Fakten und aktuellen Nachrichten abzurufen, die für die Beantwortung der aktuellen Runde erforderlich sind. Wenden Sie dann semantisches Caching auf die Kombination aus der aktuellen Benutzernachricht und dem abgerufenen Kontext an, anstatt den gesamten Rohdialog einzubetten.
Zeiträume für die Invalidierung des Caches festlegen
Verwenden Sie TTL, um zu steuern, wie lange zwischengespeicherte Antworten bereitgestellt werden, bevor sie bei einem Cache-Fehler neu generiert werden.
| Datentyp | TTL wird empfohlen | Begründung |
|---|---|---|
| Statische Fakten (Dokumentation, Richtlinien) | 24 Stunden | Fakten ändern sich selten |
| Informationen zum Produkt | 12—24 Stunden | In den meisten Katalogen täglich aktualisiert |
| Allgemeine Antworten des Assistenten | 1—4 Stunden | Bringen Sie Frische und Trefferquote in Einklang |
| Real-time Daten (Preise, Inventar) | 5—15 Minuten | Daten ändern sich häufig |
| Kontext der Konversation | 30 Minuten | Session-scoped, kurzlebig |
# 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)
Tipp
Legen Sie TTLs fest, die Ihrem Anwendungsfall entsprechen und festlegen, wie oft sich Ihre Daten- oder Modellausgaben ändern. Längere TTLs erhöhen die Cache-Trefferraten, erhöhen aber auch das Risiko veralteter Antworten. Kürzere TTLs sorgen dafür, dass die Antworten aktueller sind, senken aber die Cache-Trefferquoten und erfordern mehr LLM-Inferenz.
Überwachung und Kostenverfolgung
Verfolgen Sie die Cache-Leistungskennzahlen, um Ihren semantischen Cache im Laufe der Zeit zu optimieren:
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), }
Speicherverwaltung
Maxmemory-Richtlinie festlegen — Konfigurieren Sie
maxmemory-policy allkeys-lruIhren ElastiCache Cluster so, dass die zuletzt verwendeten Cache-Einträge automatisch gelöscht werden, wenn der Cluster sein Speicherlimit erreicht.Kapazitätsplan — Jeder Cache-Eintrag benötigt in der Regel etwa 4—6 KB (Einbettungsmaße × 4 Byte + Abfragetext + Antworttext). Eine ElastiCache 1-GB-Instance kann ungefähr 170.000 zwischengespeicherte Einträge speichern.
Cache-Invalidierung für veraltete Daten verwenden — Wenn sich die zugrunde liegenden Daten ändern, verwenden Sie die Textsuche, um zugehörige Cache-Einträge zu finden und für ungültig zu erklären:
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}'")
