As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Práticas recomendadas
Escolhendo dados que podem ser armazenados em cache
O cache semântico é adequado para consultas repetidas cujas respostas são relativamente estáveis, enquanto respostas em tempo real ou altamente dinâmicas geralmente são candidatas ruins para armazenamento em cache.
Use filtros numéricos e de tags derivados do contexto existente do aplicativo (como ID do produto, categoria, região ou segmento de usuário) para decidir quais consultas e respostas são elegíveis para armazenamento em cache e para melhorar a relevância dos acessos ao cache.
Ajuste do limite de similaridade
O limite de similaridade controla a compensação entre a taxa de acerto do cache e a qualidade da resposta. Escolha um limite que equilibre a economia de custos com precisão para seu caso de uso:
| Limite | Taxa de acerto | Risco de qualidade | Melhor para |
|---|---|---|---|
| 0,95 (estrito) | Baixo (~ 25%) | Muito baixo | Aplicações médicas, legais e financeiras |
| 0,90 (moderado) | Médio (~ 55%) | Baixo | Chatbots em geral |
| 0,80 (balanceado) | Alto (~ 75%) | Baixo — Médio | Perguntas frequentes, bots, suporte de TI |
| 0,75 (relaxado) | Muito alto (~ 90%) | Médio | High-volume consultas repetitivas |
Importante
Comece com um limite mais alto (0,90—0,95) e diminua-o gradualmente enquanto monitora a precisão. Use A/B testes para encontrar o equilíbrio ideal para sua carga de trabalho.
Consultas autônomas versus conversas
Para consultas autônomas — aplique o cache semântico diretamente no texto da consulta do usuário.
Para conversas em vários turnos — primeiro use sua memória de conversação para recuperar os principais fatos e as mensagens recentes necessárias para responder ao turno atual. Em seguida, aplique o cache semântico à combinação da mensagem atual do usuário e do contexto recuperado, em vez de incorporar todo o diálogo bruto.
Definindo períodos de invalidação do cache
Use o TTL para controlar por quanto tempo as respostas em cache são servidas antes de serem regeneradas em caso de falha de cache.
| Tipo de dados | TTL recomendado | Lógica |
|---|---|---|
| Fatos estáticos (documentação, políticas) | 24 horas | Os fatos mudam com pouca frequência |
| Informações do produto | 12—24 horas | Atualizado diariamente na maioria dos catálogos |
| Respostas gerais do assistente | 1—4 horas | Equilibre o frescor com a taxa de acerto |
| Real-time dados (preços, inventário) | 5 a 15 minutos | Os dados são alterados com frequência |
| Contexto da conversa | 30 minutos | Session-scoped, de curta duração |
# 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)
dica
Defina TTLs que correspondam ao caso de uso do seu aplicativo e à frequência com que suas saídas de dados ou modelo mudam. TTLs mais longos aumentam as taxas de acerto do cache, mas aumentam o risco de respostas desatualizadas. TTLs mais curtos mantêm as respostas mais atualizadas, mas reduzem as taxas de acerto do cache e exigem mais inferência de LLM.
Monitoramento e controle de custos
Acompanhe as métricas de desempenho do cache para otimizar seu cache semântico ao longo do tempo:
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), }
Gerenciamento de memória
Defina a política de memória máxima — configure
maxmemory-policy allkeys-lruem seu ElastiCache cluster para remover automaticamente as entradas de cache menos usadas recentemente quando o cluster atingir seu limite de memória.Planeje a capacidade — cada entrada de cache normalmente requer aproximadamente 4 a 6 KB (dimensões de incorporação × 4 bytes + texto de consulta + texto de resposta). Uma ElastiCache instância de 1 GB pode armazenar aproximadamente 170.000 entradas em cache.
Use a invalidação de cache para dados obsoletos — Quando os dados subjacentes mudarem, use a pesquisa de texto para encontrar e invalidar entradas de cache relacionadas:
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}'")
