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-lru` Ihren 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}'")
```