5.2 — Instrumentação de Telemetria: ROI e Consumo Granular por Fluxo, PR e Usuário

Objetivo da Aula

Desenhar um esquema de telemetria que captura custo de chamadas de LLM com granularidade suficiente para atribuição de negócio

Definir as dimensões mínimas de atribuição de custo: fluxo de negócio, Pull Request, usuário, sessão e modelo utilizado

Calcular ROI de um fluxo de IA combinando custo instrumentado com métricas de resultado entregue

Desenhar um pipeline de agregação com janelas de tempo e alertas de anomalia de custo

Distinguir telemetria de FinOps de IA (custo, token, valor) de observabilidade tradicional (latência, erro, disponibilidade)

Por que isso importa

O Capítulo 5.1 estabeleceu que custo de IA é uma propriedade arquitetural, não um efeito colateral de infraestrutura. Mas uma propriedade que não é medida não pode ser gerenciada. Sem telemetria granular, o arquiteto sabe apenas o número final da fatura do provedor de modelo no fim do mês — um agregado inútil para decisão, porque não diz o quê gastou, quem gastou, nem se valeu a pena.

A pergunta que todo time de engenharia de IA eventualmente recebe do financeiro é sempre alguma variação de: "por que a fatura de modelo dobrou este mês, e qual funcionalidade específica é responsável?" Sem instrumentação desenhada desde o início — não adicionada depois, às pressas — essa pergunta não tem resposta. E sem resposta, a reação política mais comum é cortar orçamento de IA de forma indiscriminada, penalizando os fluxos que geravam retorno junto com os que não geravam.

Impacto direto no seu trabalho: instrumentação de telemetria de custo é uma decisão de arquitetura que precisa ser tomada no desenho do harness, não anexada depois. As dimensões que você escolhe capturar hoje (fluxo, PR, usuário, sessão) determinam quais perguntas de negócio você conseguirá responder daqui a seis meses — e quais ficarão permanentemente sem resposta porque o dado nunca foi coletado.

Conceitos Fundamentais

O que uma telemetria de FinOps de IA precisa capturar

Observabilidade tradicional (latência, taxa de erro, disponibilidade) responde "o sistema está funcionando?". Telemetria de FinOps de IA responde uma pergunta diferente: "quanto custou, para quem, e valeu a pena?". Isso exige capturar, em cada chamada ao modelo, um evento estruturado com dimensões de negócio — não só dimensões técnicas.

{
  "evento": "llm_call",
  "timestamp": "2026-07-23T14:32:07Z",
  "trace_id": "a1b2c3d4",
  "fluxo_negocio": "triagem_ticket_suporte",
  "pull_request_id": null,
  "usuario_id": "user_48213",
  "sessao_id": "sess_9f21",
  "turno_numero": 4,
  "modelo": "tier2-intermediario",
  "tokens_entrada": 3120,
  "tokens_entrada_cache": 2400,
  "tokens_saida": 410,
  "custo_usd": 0.0187,
  "latencia_ms": 1840,
  "resultado": "sucesso",
  "motivo_escalonamento": null
}

Repare que o evento tem duas famílias de campos: campos técnicos (tokens, latência, modelo) que já existem em qualquer log de chamada de API, e campos de atribuição de negócio (fluxo_negocio, pull_request_id, usuario_id, sessao_id) que não vêm de graça — precisam ser propagados explicitamente pelo harness em cada chamada. É essa segunda família que transforma um log técnico em telemetria de FinOps.

Dimensões de atribuição: fluxo, PR e usuário

Três dimensões cobrem a maioria das perguntas que times de engenharia e financeiro fazem sobre custo de IA em produção:

Em harness de codificação autônoma — agentes que abrem, revisam ou geram Pull Requests — a dimensão pull_request_id merece atenção especial: ela permite responder "quanto custou, em tokens, revisar este PR de 40 arquivos versus aquele de 3 arquivos", uma pergunta que orienta decisões como limitar o escopo de revisão automática por tamanho de diff.

Exemplo de agregação por PR (consulta conceitual sobre os eventos):

SELECT pull_request_id,
       SUM(custo_usd) AS custo_total,
       SUM(tokens_entrada + tokens_saida) AS tokens_totais,
       COUNT(*) AS chamadas_realizadas
FROM eventos_llm_call
WHERE fluxo_negocio = 'revisao_pr'
  AND timestamp >= '2026-07-01'
GROUP BY pull_request_id
ORDER BY custo_total DESC
LIMIT 10

Resultado hipotético:
  PR #4821 (refactor de 62 arquivos): US$ 4,32 — 9 chamadas
  PR #4790 (fix de 1 linha):          US$ 0,08 — 2 chamadas
  PR #4756 (novo módulo, 15 arquivos): US$ 1,91 — 5 chamadas

Esse tipo de agregação, impossível sem a dimensão pull_request_id capturada no momento da chamada, é o que permite ao arquiteto propor políticas como "acima de 30 arquivos modificados, o agente resume o diff em vez de enviar o conteúdo completo" — uma decisão de payload (Capítulo 5.4) fundamentada em dado real de custo, não em intuição.

Pipeline de agregação e janelas de tempo

Eventos brutos por chamada são granulares demais para dashboards executivos, mas indispensáveis para depuração de anomalia. A prática padrão é manter os dois níveis: eventos brutos com retenção curta (auditoria e depuração) e agregados por janela de tempo com retenção longa (tendência e relatório).

Pipeline de agregação: llm_call (evento bruto) → Job de agregação (a cada hora) → Tabela agregada, com os campos fluxo_negocio, hora, custo_total, tokens_totais, chamadas, custo_medio_por_chamada e taxa_escalonamento_tier.

Calculando ROI de um fluxo de IA

Custo instrumentado, sozinho, não diz se o sistema vale a pena. ROI exige combinar custo com uma métrica de resultado — e a métrica de resultado quase nunca vem do mesmo sistema de telemetria de LLM; normalmente vem de um sistema de negócio adjacente (ticket resolvido, PR aprovado sem retrabalho, relatório aceito sem correção).

ROI do fluxo = (Valor gerado - Custo do fluxo) / Custo do fluxo

Exemplo: fluxo de triagem automática de tickets, 1 mês
  Custo instrumentado (soma de llm_call): US$ 4.200
  Tickets triados corretamente (sem correção humana): 10.800
  Tickets que precisaram de correção humana: 1.200
  Custo evitado (tempo humano que seria gasto triando manualmente,
    a US$ 2,10/ticket, só nos 10.800 triados corretamente): US$ 22.680

  Valor líquido gerado = 22.680 - 4.200 = US$ 18.480
  ROI = 18.480 / 4.200 = 4,4  (ou 440%)

  Mas: os 1.200 tickets com correção humana também custaram tokens
  (triagem errada + retrabalho) — esse custo deve entrar no
  denominador, não ser ignorado.

O erro mais comum ao calcular ROI de IA é contar apenas o custo de token no denominador e ignorar o custo de retrabalho quando o resultado do modelo está errado. Um fluxo com custo de token baixo mas taxa de erro alta pode ter ROI pior do que um fluxo mais caro por chamada, mas com taxa de acerto muito maior — é o mesmo argumento levantado no Capítulo 5.1 sobre custo por unidade de valor, agora com o cálculo completo.

Aprofundamento Técnico

Amostragem vs. captura completa

Capturar telemetria em 100% das chamadas parece a escolha óbvia, mas tem custo próprio: overhead de I/O, volume de armazenamento e, em sistemas de altíssimo volume, latência adicional na chamada crítica. A alternativa é amostragem — capturar uma fração das chamadas em detalhe completo, e agregados leves (só contador e soma de custo, sem payload) em 100%.

Estratégia de captura em camadas:

Camada 1 — sempre, 100% das chamadas:
  contador de chamadas, soma de tokens, soma de custo
  (agregação leve, sem payload de prompt/resposta)

Camada 2 — amostragem (ex: 5% das chamadas, ou 100% das que erram):
  evento completo com prompt/resposta truncados, latência detalhada,
  metadados de raciocínio do agente

Regra prática: amostragem NUNCA se aplica a chamadas com
resultado = "erro" ou "escalonamento" — essas são sempre
capturadas 100%, porque são exatamente as que o arquiteto
mais precisa investigar.

Essa camada dupla resolve a tensão entre completude e custo de observabilidade: a Camada 1 garante que nenhum centavo de gasto fica invisível no agregado, enquanto a Camada 2 garante que há profundidade de depuração disponível quando algo sai do esperado, sem pagar o custo de armazenar payload completo de toda chamada bem-sucedida e rotineira.

Detecção de anomalia de custo

Telemetria só vira FinOps operacional quando gera alerta antes que a fatura do mês feche. A técnica mais simples e robusta o suficiente para a maioria dos casos é comparar o custo agregado da janela atual contra a média móvel e o desvio padrão das janelas anteriores.

z_score = (custo_janela_atual - media_movel_7_janelas) / desvio_padrao_7_janelas

Regra de alerta:
  z_score > 3  → anomalia forte (investigar imediatamente)
  z_score > 2  → anomalia moderada (revisar no próximo ciclo)

Exemplo: fluxo "revisao_pr", agregado por hora
  Média móvel das últimas 7 horas: US$ 12,40/hora, desvio: US$ 2,10
  Hora atual: US$ 41,80

  z_score = (41,80 - 12,40) / 2,10 ≈ 14,0
  → muito acima do limiar de 3: alerta forte, provável loop
    sem critério de parada (Capítulo 1.6) ou escalonamento
    indevido para tier caro (Capítulo 5.3)

Um z-score isoladamente alto não diz a causa — só diz que algo está fora do padrão. A causa raiz típica é uma de três: um loop de agente girando sem convergir, um roteador de modelo escalonando incorretamente para o tier mais caro (Capítulo 5.3), ou um pico legítimo de volume de negócio (nesse caso, não é anomalia — é sazonalidade, e o alerta deve alimentar o ajuste da própria média móvel, não disparar pânico).

Latência como métrica complementar ao custo

Telemetria de FinOps de IA que só observa custo perde metade do quadro. Latência e custo costumam se mover juntos — um turno que escalou para um tier mais caro (Capítulo 5.3) quase sempre também demorou mais — mas nem sempre na mesma proporção, e a divergência entre os dois é, ela mesma, um sinal de diagnóstico.

Registrar latencia_ms em todo evento, como no schema apresentado no início deste capítulo, custa quase nada e permite essa triagem de causa raiz sem precisar cruzar sistemas de observabilidade diferentes — desde que ambas as métricas (custo e latência) morem no mesmo evento estruturado, e não em ferramentas separadas com granularidade de tempo distinta.

Atribuição multi-tenant e chargeback interno

Em organizações com múltiplos times ou produtos compartilhando a mesma infraestrutura de harness, a telemetria granular habilita chargeback: atribuir o custo de IA de volta ao centro de custo que o gerou, em vez de tratá-lo como despesa geral de infraestrutura.

Sem a dimensão fluxo_negocio (e um mapeamento fluxo → centro de custo), esse relatório simplesmente não existe — o financeiro só vê "US$ 13.150 gastos em IA", sem saber onde investigar primeiro.

Chargeback não é só um exercício contábil — é o que dá a cada time incentivo real para otimizar o próprio fluxo (Capítulo 5.4), porque o custo deixa de ser um número abstrato de infraestrutura e passa a aparecer no orçamento do time responsável.

Armadilhas de telemetria mal desenhada

Duas armadilhas recorrentes destroem a utilidade de uma telemetria de FinOps de IA, mesmo quando tecnicamente ela está "funcionando":

Explosão de cardinalidade não controlada: usar trace_id ou sessao_id como dimensão de agrupamento em dashboards, em vez de reservá-los para drill-down pontual. Isso derruba performance de consulta e infla custo de armazenamento de índice sem gerar nenhum insight adicional — a granularidade certa para dashboard é fluxo/modelo/hora, não sessão individual.

Dado sensível no payload de log: capturar prompt e resposta completos em texto plano no evento de telemetria, sem mascaramento, expõe dado de usuário (PII) em um sistema de observabilidade que normalmente tem controle de acesso mais frouxo do que o sistema de negócio de origem. A prática correta é truncar ou mascarar o conteúdo do prompt/resposta no evento de telemetria — mantendo metadados (contagem de tokens, custo, latência, resultado) sempre, e conteúdo completo apenas em um sistema de auditoria separado, com controle de acesso equivalente ao do dado original.