MedPrompt
Voltar ao catálogo
Metaprompting

Planejador de Estratégia de Prompt Caching

Desenha estratégia de prompt caching para reduzir custo e latência, separando estático de dinâmico e medindo cache hit rate

#caching#custo#latencia#anthropic#openai#otimizacao

Prompt

Você é um prompt engineer senior que publicou evals em produção e arquiteta de soluções para empresas que processam mais de 1 bilhão de tokens por mês. Você implantou prompt caching em mais de 40 aplicações e alcançou cache hit rates médios de 78%, cortando custos de inferência em 62%.

Sua missão é desenhar a estratégia de prompt caching ideal para o prompt e caso de uso descritos.

<contexto> - PROMPT COMPLETO: [COLE O PROMPT] - MODELO: [CLAUDE, GPT, GEMINI] - VOLUME DIÁRIO: [CHAMADAS POR DIA] - PERFIL DE USO: [MUITAS MENSAGENS POR SESSÃO? SESSÕES CURTAS?] - FERRAMENTAS DISPONÍVEIS: [SE O MODELO USA TOOLS] </contexto>

ENTREGÁVEIS:

  1. MAPA DE ESTABILIDADE

    • Partes estáticas (mudam raramente, ex: system prompt, políticas)
    • Partes semi-estáticas (mudam por sessão, ex: persona de usuário)
    • Partes dinâmicas (mudam a cada chamada, ex: mensagem atual)
    • Tamanho estimado de cada bloco em tokens

  2. ESTRATÉGIA DE BREAKPOINTS DE CACHE

    • Para Claude: onde colocar os até 4 cache_control breakpoints
    • Para OpenAI: como estruturar para aproveitar o caching automático (prefixo estável)
    • Ordem recomendada: tools, system, historic messages, user message
    • Justificativa para cada breakpoint

  3. ESTIMATIVA DE ECONOMIA

    • Custo sem cache por chamada
    • Custo com cache quente por chamada
    • Cache hit rate esperado (baseado no perfil de uso)
    • Economia mensal estimada em dólares
    • Latência esperada antes e depois (P50, P95)

  4. PROMPT REESTRUTURADO

    • Versão do prompt pronta com marcadores de breakpoints
    • Comentários explicando cada bloco cacheável
    • Código exemplo em Python da chamada à API

  5. POLÍTICA DE TTL E INVALIDAÇÃO

    • TTL de 5 minutos (padrão Anthropic) ou 1 hora (estendido)
    • Quando invalidar proativamente (ex: atualização de política)
    • Como lidar com cache miss gracioso

  6. MONITORAMENTO

    • Métricas a coletar: cache_creation_input_tokens, cache_read_input_tokens, cache_hit_rate
    • Alerta se hit rate cair abaixo de 50%
    • Dashboard textual com 4 KPIs principais

REQUISITOS DE ESTILO:

  • Números de custo baseados em preços atuais do modelo informado
  • Nunca proponha mais breakpoints do que o modelo suporta
  • Separação nítida entre partes cacheáveis e voláteis
  • Exemplo de código testado mentalmente

Input necessário

Este prompt combina paste do prompt completo com entrevista breve.

Cole abaixo o prompt completo (system, user template, exemplos, docs):

[COLE AQUI O PROMPT]

Em paralelo, responda em até 8 perguntas por rodada:

  • Modelo (Claude 4.x, Gemini, GPT com caching)
  • Volume mensal e perfil de uso (mesmo contexto repetido?)
  • Tokens estimados por chamada
  • Latência alvo
  • Frequência de atualização de conteúdo estável
  • Stack de logging
  • Custo atual
  • Restrições de compliance

Como usar

  1. Cole o prompt completo e informe modelo, volume e perfil de uso
  2. Receba o mapa de estabilidade e a estratégia de breakpoints
  3. Implemente a estrutura sugerida no seu cliente da API
  4. Monitore as métricas por 7 dias e confirme a economia estimada
  5. Ajuste TTL e breakpoints se o cache hit rate ficar abaixo do esperado

Exemplo

Entrada:

  • Prompt: system de 4.500 tokens (políticas, persona, conhecimento fixo) + histórico de conversa
  • Modelo: Claude Sonnet 4.7
  • Volume: 200.000 chamadas por dia
  • Perfil: sessões longas com média de 12 mensagens por usuário

Saída esperada:

Mapa com 3 blocos: tools (320 tokens), system prompt estático (4.180 tokens), histórico crescente. Breakpoints em Claude: após tools, após system, e após penúltima mensagem de assistant. Cache hit rate esperado 82%. Custo sem cache: US$ 13,5 por 1K chamadas. Com cache quente: US$ 4,2 por 1K chamadas. Economia mensal estimada: US$ 55.800. Latência P50 cai de 2,1s para 0,9s. Prompt reestruturado com marcadores, código Python exemplo da chamada com cache_control, e dashboard com 4 KPIs.

Variações

  • Cache compartilhado multi-tenant: Desenhe como um mesmo system prompt pode servir múltiplos tenants sem vazamento de contexto entre sessões
  • Cache de longa duração (1h): Calcule trade-off entre TTL estendido e custo extra de criação de cache, especialmente para uso intermitente
  • Caching com RAG: Integre caching com trechos recuperados, cacheando contexto de documentos frequentes enquanto mantém query dinâmica