Monitoramento em produção vs avaliação em dev-time

Onde a rendfly se encaixa ao lado de Braintrust, Helicone, Sentry e Datadog.

Existem dois eixos nas ferramentas de IA: quando elas rodam (dev-time vs produção) e o que elas observam (infraestrutura vs qualidade da conversa). A rendfly fica no quadrante produção + conversa — o que roda 24/7 em tráfego real de usuários e lê o conteúdo das respostas, não apenas se a requisição terminou.

O gráfico de dois eixos

Mapeando o cenário por esses dois eixos:

                   dev-time          produção
              ┌────────────────┬────────────────────┐
 qualidade    │ Braintrust     │ rendfly            │
 da conversa  │ Promptfoo      │                    │
              │ LangSmith      │                    │
              ├────────────────┼────────────────────┤
 infra /      │ testes unit.   │ Sentry / Datadog   │
 requests     │ checks de CI   │ Helicone / Langfuse │
              └────────────────┴────────────────────┘

Helicone e Langfuse ficam no canto inferior direito porque observam tráfego de produção — mas no nível da requisição (tokens, latência, custo), não no nível do conteúdo.

vs frameworks de eval em dev-time

Braintrust, Promptfoo e LangSmith foram desenhados para o ciclo de regressão pré-deploy. Você monta um dataset de conversas de exemplo, escreve ou gera critérios de avaliação e roda a suíte no CI antes de publicar uma mudança de prompt. Se a nova versão pontua pior que a baseline no seu conjunto de ouro, o pipeline falha e você corrige antes que usuários vejam qualquer coisa.

Esse é o lugar certo para esse tipo de checagem. O problema é que ela só cobre os cenários que você pensou em colocar no dataset. Tráfego de produção tem propriedades estatísticas diferentes do seu conjunto de eval. Um usuário real pergunta ao bot de WhatsApp sobre uma categoria de produto que você nunca testou. Uma formulação inesperada escapa da regra de recusa. Um pico sazonal traz uma nova classe de perguntas. Nada disso aparece no seu eval de CI.

Evals em dev-time também não veem mudanças do provider. Quando OpenAI ou Anthropic publica uma nova versão de modelo sem anúncio, seu prompt pode se comportar de forma sutilmente diferente em produção, mesmo que o conjunto de eval continue passando.

vs observabilidade de infraestrutura

Sentry, Datadog e OpenTelemetry dizem se requisições terminaram, quanto demoraram e se exceções foram lançadas. Para uma chamada de API de LLM, isso significa: a chamada HTTP para o provider retornou 200? Deu timeout? Houve exceção no código da aplicação?

O que elas não dizem: o que o modelo realmente respondeu. Uma requisição bem-sucedida que retorna uma resposta alucinada parece idêntica a uma requisição bem-sucedida que retorna uma resposta correta. Do ponto de vista de infraestrutura, não há nada para alertar. A latência está boa, o status code está bom, o throughput está bom. O conteúdo está errado.

Essas ferramentas são essenciais, e a rendfly não as substitui. Você ainda quer o Sentry capturando erros de aplicação e o Datadog observando sua infraestrutura. A rendfly cobre a camada conversacional que essas ferramentas não conseguem ver.

vs observabilidade específica de LLM

Helicone e Langfuse ficam mais perto da camada de LLM. Elas fazem proxy ou instrumentam suas chamadas de LLM e registram metadados da requisição: qual modelo foi chamado, quantos tokens foram usados, qual foi a latência, qual usuário ou sessão fez a chamada. Algumas oferecem rastreamento de custo e tagging básico de requests.

Isso é genuinamente útil para visibilidade operacional — depurar por que uma sessão específica foi lenta, rastrear custo por cliente, ver quais versões de modelo estão sendo chamadas. Mas a pergunta central que elas respondem é “o que aconteceu no nível da chamada de API”, não “essa conversa estava correta”.

Nem Helicone nem Langfuse rodam um veredito contra as regras da sua system message. Elas não sinalizam quando o agente quebra uma restrição de recusa ou sai do tom. Elas registram que a chamada aconteceu; não julgam se a resposta estava certa.

Quando você precisa das duas camadas

Times maduros geralmente acabam querendo as duas camadas. Evals em dev-time dão uma trava de regressão antes de você publicar uma nova system message ou versão de modelo. A rendfly dá cobertura 24/7 da cauda viva depois do deploy — capturando regressões que só surgem de comportamento real de usuários, mudanças de provider e conhecimento desatualizado.

A configuração é aditiva: rode Braintrust ou Promptfoo no CI, conecte a rendfly à produção e você cobre tanto o pré-deploy quanto o pós-deploy. Nenhuma ferramenta observa a mesma superfície que a outra.

Relacionado

• O que é a rendfly — a visão geral do que a rendfly faz e para quem ela serve