Resumo Técnico: Compressão de Prompt Consciente de Cache (CAPC)

Declaração do Problema

As implementações modernas de Large Language Models (LLMs) dependem cada vez mais de dois primitivos distintos de redução de custo: cache de prompt (armazenamento dos estados KV de um prefixo para cobrar taxas descontadas em leituras subsequentes) e compressão de prompt (redução da contagem de tokens da entrada). Historicamente, essas técnicas foram tratadas como otimizações separadas. No entanto, a literatura dominante sobre compressão de prompt baseia-se em métodos conscientes da consulta (query-aware), que geram um prefixo comprimido único para cada consulta específica.

Essa escolha de design cria um conflito fundamental com mecanismos de cache estritos por prefixo (ex: cache_control da Anthropic). Como o prefixo comprimido muda a cada consulta, a chave do cache é invalidada a cada chamada. Consequentemente, o sistema paga a taxa total de entrada não descontada para cada requisição, efetivamente apagando a economia tanto da compressão quanto do cache. Embora a literatura existente frequentemente assuma uma taxa de acerto de cache ideal ($\rho = 1.0$), essa suposição falha em considerar a realidade econômica dos APIs do mundo real, onde o comportamento do cache é não trivial e a compressão consciente da consulta pode resultar em um retorno sobre investimento (ROI) líquido negativo.

Metodologia e Caracterização Empírica

Os autores abordam essa lacuna através de uma combinação de medição empírica, modelagem de custo e design algorítmico.

1. Caracterização Empírica do Anthropic Sonnet 4.6

O artigo primeiro caracteriza o comportamento de cache da API Anthropic Sonnet 4.6 através de experimentos controlados ($n=3$ tentativas, custo total de $1,91). As principais descobertas incluem:

• Arquitetura de Dois Níveis: O cache não é uniforme. Ele exibe um limiar nítido próximo a 3.500 tokens.
  • Nível Quente (Hot Tier) (< 3,5k tokens): A taxa de acerto ($\rho$) estabiliza em aproximadamente 0,83 (especificamente 0,833 para 2k tokens) mesmo após 30 chamadas. Não é 1.0.
  • Nível Persistente (Persistent Tier) (> 3,5k tokens): A taxa de acerto é efetivamente 1,0 a partir da segunda chamada em diante.
• Invalidação Estrita por Token: A invalidação do cache é estrita à sequência de tokens. Mesmo mutações menores (ex: uma única mudança de caractere) resultam em um erro de cache (cache miss), embora o espaçamento de início/fim seja normalizado pelo tokenizador.
• Estrutura de Preços: A API cobra um prêmio para escritas de cache ($c_w$) comparado a entradas não cacheadas ($p_{in}$), e um desconto significativo para leituras de cache ($c_r$). No Sonnet 4.6, $c_w \approx 1,25 \times p_{in}$ e $c_r \approx 0,10 \times p_{in}$.

2. Modelagem de Custo e Análise de Crossover

Os autores derivam um modelo de custo por chamada para quatro estratégias:

• A (Vanilla): Sem cache, sem compressão.
• B (Apenas Cache): Prefixo completo em cache, sem compressão.
• C (Compressão Consciente da Consulta): Comprimido por consulta, sem cache (erro de cache em todas as vezes).
• D (CAPC): Compressão agnóstica à consulta + cache.

O modelo define um limiar de crossover ($\rho_{cross}$) onde o custo de cache (Estratégia B) iguala o custo da compressão consciente da consulta (Estratégia C):
$$\rho_{cross}(r) = \frac{c_w - p_{in}/r}{c_w - c_r}$$
A análise revela que para altas taxas de compressão ($r \ge 6$), a taxa de acerto necessária para que o cache supere a compressão consciente da consulta exceda o platô empírico do nível quente do Sonnet 4.6 ($\rho \approx 0,89$). Assim, sob condições realistas, a compressão consciente da consulta é frequentemente mais barata que o cache ingênuo, contradizendo o senso comum.

3. O Algoritmo CAPC

A solução proposta, Compressão de Prompt Consciente de Cache (CAPC), combina três componentes:

1. Compressão Agnóstica à Consulta: Um documento estático é comprimido uma única vez (ex: via seleção de sentenças) em um prefixo fixo $D'$, garantindo que a chave do cache permaneça constante entre as consultas.
2. Limite de Razão de Preservação de Nível: Para evitar que a compressão excessiva empurre o prefixo para o "nível quente" (onde $\rho < 1$), a razão de compressão $r$ é limitada por $r_{max} = \lfloor |D| / 3500 \rfloor$. Isso garante que o prefixo comprimido permaneça no nível persistente ($\rho \approx 1,0$).
3. AdaptiveCacheBoundary: Para documentos em evolução, uma sub-rotina classifica posições de sentenças como STATIC (estática), QUASI (quase estática) ou DYNAMIC (dinâmica) com base nas taxas de mutação entre versões, cacheando apenas o prefixo estável.

Principais Resultados

1. Benchmarks Sintéticos LongBench-v2

Em 16 configurações (4 tamanhos de documento $\times$ 4 razões), o CAPC foi a estratégia mais barata em 16/16 casos.

• Economia: Economia média de 49% sobre o cache-apenas, 64% sobre a compressão consciente da consulta e 90% sobre o vanilla.
• Qualidade: O CAPC manteve a qualidade dentro de 0,05 da linha de base não comprimida nas razões de preservação de nível.
• Validação de Crossover: Em $r=6$, a compressão consciente da consulta foi mais barata que o cache-apenas em todas as 4/4 configurações, validando a previsão do modelo de crossover.

2. Validação em Produção: Assistente de Uso de Ferramentas Empresarial

Validado em um prefixo estático de 94k tokens (prompt de sistema + 287 definições de ferramentas MCP).

• Redução de Custo: O CAPC em $r=3$ alcançou uma redução de custo de 51,7% sobre o vanilla.
• Qualidade: A qualidade de seleção de ferramentas igualou o cache-apenas (0,700 vs 0,703).
• Insight: A compressão consciente da consulta em $r=3$ na verdade teve um desempenho pior na seleção de ferramentas (0,603) porque descartou definições de ferramentas relevantes para a consulta. A abordagem agnóstica à consulta do CAPC preservou o catálogo completo, provando ser superior para agentes aumentados por ferramentas.
• Cache Implícito: O estudo revelou que a Anthropic faz o cache implícito de arrays tools= grandes mesmo sem marcadores explícitos, reduzindo o benefício marginal do cache explícito para estratégias vanilla, mas não anulando os ganhos de compressão do CAPC.

3. RAG de Grafo de Conhecimento (Graphify)

Integrado com graphify para indexação de código-fonte (repositórios FastAPI e httpx).

• Arquitetura: A Camada 1 (cacheada, agnóstica à consulta) contém metadados do grafo; a Camada 2 (por consulta) busca o código-fonte.
• Desempenho: O CAPC entregou uma redução de custo de 9,3x no FastAPI e 2,4x no httpx em comparação ao "cache-all" (esqueleto completo do grafo), mantendo taxas de acerto de cache estáveis de mais de 85%.
• Qualidade: O CAPC superou as consultas nativas do graphify e as linhas de base de RAG de embedding, particularmente em bases de código onde o modelo tinha conhecimento prévio mais fraco (httpx), entregando um aumento de qualidade de 142% sobre o vanilla.

4. Benchmark Público: $\tau$-Bench Retail

Avaliado em 50 tarefas determinísticas com recompensas de estado de banco de dados (sem juiz LLM).

• Resultado: O CAPC foi a estratégia mais barata, economizando 7,9% sobre o vanilla enquanto alcançou exatamente a mesma taxa de conclusão de tarefa (36/50) que o vanilla ($z=0,00, p=1,00$).
• ROI Negativo de Query-Aware: A compressão consciente da consulta foi 40,1% mais cara que o vanilla, fornecendo a primeira confirmação de produção de que métodos conscientes da consulta podem ter ROI negativo em benchmarks públicos.

Significância e Alegações

O artigo afirma fornecer a primeira caracterização sistemática da economia de cache de prompt, indo além da suposição idealizada de $\rho=1,0$. Suas principais contribuições são:

1. Realidade Empírica: Demonstrar que os caches de LLM possuem uma arquitetura de dois níveis com um platô de taxa de acerto não trivial abaixo de um limiar específico de tokens.
2. Inversão Teórica: Provar que, para altas taxas de compressão, a compressão consciente da consulta é frequentemente mais barata que o cache ingênuo, invertendo a hierarquia de design convencional.
3. Algoritmo Prático: Introduzir o CAPC, que unifica a compressão agnóstica à consulta com o cache explícito e uma restrição de preservação de nível.
4. Validação de Produção: Validar essas descobertas através de benchmarks sintéticos, agentes de uso de ferramentas empresariais, pipelines de RAG de grafo de conhecimento e benchmarks públicos determinísticos.

Os autores enfatizam que o CAPC não é um substituto para indexadores (como o graphify), mas uma camada complementar de "entrega de última milha" que otimiza o custo econômico de entregar o contexto derivado do índice a um LLM. O custo total de todo o trabalho empírico no artigo foi de $98,96, demonstrando que essas descobertas são reproduzíveis com recursos modestos.