Observabilidade para sistemas de IA: não dá para depurar o que não se vê

A falha que nunca dispara alarme

O monitoramento clássico de software se apoia numa premissa tranquilizadora: quando algo quebra, quebra fazendo barulho. Uma exceção é lançada, o status code pula para 500, a curva de latência dispara, um painel fica vermelho. Todo o ferramental dos últimos vinte anos — taxa de erro, latência p99, traces atravessando microsserviços — foi construído sobre a ideia de que falhas têm um sintoma visível. Basta medir o sintoma certo e apitar no limite certo.

Sistemas de IA rompem com essa premissa. A falha característica deles não é o crash, é a resposta errada-mas-plausível — o resumo que omite um ponto crucial, a classificação confiante e equivocada, o número extraído com uma ordem de grandeza a mais. E essa resposta não lança exceção nenhuma. Ela tem status code 200. Chega com latência normal. Nos logs, é indistinguível de uma resposta perfeita. O modelo não sinalizou que estava inseguro. Ele entregou, seguro de si como sempre, só que errado.

É exatamente aqui que a observabilidade clássica falha. Ela foi feita para vigiar sistemas que ou funcionam ou caem. Sistemas de IA têm um terceiro estado para o qual todo o instrumental é cego: eles funcionam, mas pior. E como esse estado não dispara alarme, quem costuma notá-lo primeiro é o cliente.

Por que sistemas de IA são unicamente opacos

Para entender por que a IA precisa de uma disciplina de observabilidade própria, é preciso levar a sério quatro propriedades que o software determinístico simplesmente não tem.

Não determinismo. Mande a mesma entrada duas vezes e você recebe duas respostas diferentes. Isso não é um bug, é o caráter embutido dos modelos probabilísticos. E te custa a técnica de depuração mais confiável da história do software: a reprodução determinística. Você não consegue mais capturar um defeito disparando-o de novo — na segunda tentativa o sistema pode se comportar impecavelmente. Se você não registrou exatamente o que aconteceu da primeira vez, o defeito se perdeu para sempre.

Regressão silenciosa de qualidade. Código determinístico que funcionava ontem funciona hoje, a menos que alguém o tenha mudado. Com sistemas de IA essa garantia some. A qualidade da resposta pode derivar sem que uma única linha de código seja tocada: porque o modelo por trás mudou, porque a distribuição das perguntas dos usuários se deslocou, porque um passo de retrieval anterior piorou. A regressão é real, mas não há commit para apontar o dedo.

Deriva de prompt e de versão. Uma funcionalidade de IA raramente é só "o modelo". É um template de prompt, um corpo de contexto, um conjunto de definições de ferramentas, uma versão de modelo e uma dúzia de parâmetros. Cada uma dessas peças pode mudar de forma independente — alguém ajusta o prompt de sistema, um índice de retrieval é reconstruído, o provedor libera uma atualização. Cada uma dessas mudanças pode deslocar o comportamento, e nenhuma delas se parece com um deploy clássico.

Nenhum stack trace para "resposta ruim". Quando o código determinístico cai, você recebe um número de linha e um caminho pela pilha de chamadas. Quando um modelo dá uma resposta ruim, não há stack trace. Não há uma linha onde "o defeito aconteceu". A resposta emergiu de bilhões de pesos e de todo o contexto que você forneceu. Depurar aqui não é "seguir o defeito até a origem", é "reconstruir as condições exatas sob as quais essa resposta foi produzida" — e isso só é possível se você tiver capturado essas condições de antemão.

O que você realmente precisa capturar

Se a falha não deixa stack trace, a observabilidade tem que fornecer o contexto que o stack trace daria. Isso significa capturar bem mais do que no software clássico — e fazê-lo de forma deliberada. O que um sistema de IA instrumentado deveria registrar por requisição:

• O trace completo: prompt, contexto, resposta. Não só a entrada do usuário, mas o prompt inteiro montado — prompt de sistema, contexto injetado, resultados de retrieval, exemplos few-shot — mais a resposta bruta do modelo. Essa é a única coisa que você não consegue reconstruir se não anotou. Sem o prompt exato, você não tem a menor chance de entender uma resposta ruim de um sistema não determinístico.
• Consumo de tokens e custo por requisição. Tokens de entrada, tokens de saída, o preço resultante — no nível da requisição, não como um total mensal agregado. Tem uma seção sobre o porquê mais abaixo.
• A cadeia de tool calls. Em sistemas agênticos: quais ferramentas foram chamadas, em que ordem, com quais argumentos, e o que retornaram. Um agente que se perde quase sempre o faz por uma cadeia rastreável de decisões ruins de ferramenta — mas só se você gravou a cadeia.
• A decomposição da latência. Não "a requisição levou 4 segundos", mas onde os 4 segundos foram parar: retrieval, primeira chamada ao modelo, três tool calls, segunda chamada ao modelo. Em pipelines de IA de vários estágios a latência total é uma soma, e você precisa ver as parcelas uma a uma.
• Sinais de feedback do usuário. O joinha para cima/para baixo, o "gerar de novo", o abandono silencioso, o copiar do resultado. Esses são os únicos sinais de correção que chegam em tempo real, em produção. São grosseiros, mas viram ouro assim que você os prende ao trace que os produziu.
• Scores de eval ao longo do tempo. A ligação entre observabilidade e uma suíte de avaliação de verdade. A observabilidade te diz que o comportamento mudou; os evals te dizem se ele piorou. Se você ainda não tem uma cultura de eval, nosso texto "Evals em vez de achismo" é por onde começar — a observabilidade é a fiação que alimenta esses evals com dados de produção de forma contínua.

O ferramental para isso cresce rápido. Plataformas de tracing de LLM no estilo do LangSmith são especializadas em desenhar traces inteiros de prompt-contexto-resposta e execuções de agentes; em paralelo, as convenções de OpenTelemetry para LLMs formam um padrão aberto que encaixa os spans de IA no mesmo mundo de tracing em que o resto do seu sistema já vive. Qual ferramenta você escolhe é secundário. A decisão que importa é capturar o trace completo, ponto — antes de precisar dele.

A regressão silenciosa: três jeitos de piorar sem barulho

O caso mais perigoso é aquele em que nada no seu sistema muda e ele piora mesmo assim. Três padrões aparecem repetidamente.

Mesmo nome de modelo, comportamento diferente. Um provedor atualiza o modelo por trás de um nome estável. Você continua chamando o mesmo endpoint, o mesmo identificador, e de repente recebe respostas sutilmente diferentes — mais cautelosas, mais prolixas, formatadas de outro jeito, mais fortes num ponto e mais fracas em outro. Nenhum deploy do seu lado, nenhuma mudança de código, nenhum alarme. Só uma funcionalidade que passou a bater diferente depois do fim de semana. Sem um histórico de traces para comparar o antes e o depois, isso é simplesmente invisível — você descobre pelas reclamações.

O template de prompt muda. Alguém do time melhora o prompt de sistema para consertar um caso de borda. O conserto funciona localmente, mas desloca o comportamento em outra área não testada. Não é azar, é a natureza dos prompts: eles são acoplados globalmente, uma mudança num ponto se propaga por toda parte. Sem prompts versionados gravados em cada trace, ninguém consegue depois dizer qual formulação estava rodando no dia em que a qualidade virou.

A qualidade do retrieval degrada. Em sistemas RAG o modelo muitas vezes nem é o problema — o contexto é. O índice vetorial é reconstruído e uma versão de embedding muda, uma base de documentos cresce e dilui os acertos, um parâmetro de chunking se altera. O modelo recebe contexto pior e dá respostas correspondentemente piores — mas parece que o modelo é que piorou. Só quem instrumenta o passo de retrieval separadamente enxerga que a causa está uma camada antes.

Os três padrões têm uma coisa em comum: eles não deixam rastro nas métricas clássicas. Taxa de erro estável, latência estável, disponibilidade verde. O único jeito de pegá-los é observar a substância da qualidade ao longo do tempo — e isso pressupõe que você ainda tenha os traces e os scores de eval de ontem para comparar com os de hoje.

Custo como métrica de primeira classe

No software determinístico, o custo por requisição costuma ser uma casa decimal com que ninguém se importa. Em sistemas de IA ele é uma métrica operacional de primeira classe — às vezes a que pega fogo primeiro.

O motivo é que o custo de IA pode ser explosivo e silencioso ao mesmo tempo. Dois padrões se destacam.

O agente desgovernado. Um sistema agêntico cai num laço: chama uma ferramenta, não gosta do resultado, chama de novo de um jeito ligeiramente diferente, de novo e de novo. Cada rodada queima tokens. Funcionalmente muitas vezes nem parece um defeito — afinal, o agente "está trabalhando". Mas uma única requisição presa num laço pode custar cem vezes uma normal, e quando isso acontece sob carga, a fatura no fim do mês é um susto que ninguém viu chegar. Só uma cadeia de tool calls gravada com contagem de tokens por passo torna esse laço visível — no melhor caso em tempo real, com um limite rígido que o estrangula.

Inchaço de contexto. É tentador dar mais contexto ao modelo — mais resultados de retrieval, mais histórico, mais exemplos. Cada acréscimo talvez melhore a qualidade um pouco e aumenta o custo de cada requisição com certeza. Sem transparência de custo no nível da requisição, esse inchaço se infiltra, um campo aqui, um documento ali, até o custo por requisição ter dobrado e ninguém conseguir nomear o momento em que isso aconteceu.

Instrumentar o custo por requisição torna essa dinâmica visível enquanto ainda é barato consertar. Também permite fazer a pergunta que todo produto de IA sério cedo ou tarde tem que encarar: quanto essa funcionalidade nos custa por usuário, e ela se paga? Essa pergunta não tem como ser respondida retroativamente a partir de uma fatura de nuvem agregada. Ela exige o custo na requisição individual, capturado desde o começo.

O outro lado: não se afogar em telemetria

Até aqui você poderia tirar a lição: logue tudo, cada prompt, cada resposta, cada passo intermediário, para sempre. Isso seria um erro — e caro e arriscado.

Gravar cada prompt e cada resposta por inteiro tem três consequências incômodas. Privacidade e PII: as entradas dos usuários num sistema de IA muitas vezes contêm exatamente os dados sensíveis que você menos quer espelhados num repositório de logs — nomes, e-mails, dados de saúde ou financeiros. Um log completo de prompts é um segundo lago de dados, pior protegido, um problema de conformidade e um alvo de ataque. Custo: armazenamento de traces não é de graça; reter janelas de contexto inteiras — dezenas de milhares de tokens por requisição nos modelos modernos — indefinidamente pode virar uma linha de custo por si só. Ruído: um log que contém tudo é um log em que você não acha nada. Completude sem estrutura não é observabilidade, é um palheiro.

A resposta não é "logar menos", é logar com mais inteligência. Amostragem: nem toda requisição precisa do trace completo; uma fração representativa somada à captura integral de todo caso de falha e de todo sinal negativo do usuário entrega a maior parte do conhecimento por uma fração do volume. Redação (redaction): dá para remover ou mascarar PII dos prompts e respostas antes de persistir — você mantém a estrutura do trace sem acumular o conteúdo sensível. Instrumente para os casos que doem de verdade, não para todos por igual.

E o limite mais importante de todos: observabilidade não substitui evals. Ela te diz que algo mudou — o tom está diferente, a latência subiu, o custo dobrou. Ela não te diz se a resposta está correta. Um trace pode parecer impecável e ainda conter uma resposta errada; toda métrica está verde e a saída continua sendo absurda. Julgar a correção é tarefa dos evals — uma suíte que confere contra expectativas conhecidas. Observabilidade e evals são duas metades do mesmo sistema: uma detecta a mudança, a outra a julga. Construa só uma e você terá ou um sistema de alerta precoce sem juízo, ou um juízo sem alerta precoce.

Conclusão

A observabilidade clássica foi feita para software que ou roda ou cai. Sistemas de IA têm um terceiro estado — roda, mas pior — e é justamente para esse estado que o instrumental antigo é cego. Uma resposta errada-mas-plausível carrega status code 200, chega com latência normal e é indistinguível nos logs de uma correta. Meça só taxa de erro e latência e você não verá a degradação silenciosa chegar — o cliente a vê primeiro.

A disciplina que decorre disso é nova, mas dá para aprender: capture o trace completo antes de precisar dele; trate o custo por requisição como métrica de primeira classe; observe a substância da qualidade ao longo do tempo, e não só a infraestrutura; e equilibre tudo isso com amostragem, redação e uma suíte de eval de verdade, para não se afogar em telemetria nem confundir mudança com correção.

É exatamente assim que tratamos as funcionalidades de IA na NH Labs: nós as instrumentamos como sistemas de produção — traces completos, custo por requisição, tendências de eval ao longo do tempo — para que a degradação silenciosa apareça rápido, e não só quando as reclamações começam a se acumular. Não dá para depurar o que não se vê. Então garantimos que a gente veja.