Cinco falhas silenciosas em aplicações com LLM

O que são falhas silenciosas em apps com LLM

Uma falha silenciosa acontece quando a aplicação termina a execução sem lançar uma exceção, mas o resultado está errado, incompleto ou fora do contexto. Em um app com LLM, o servidor pode responder com HTTP 200 e a interface pode parecer normal, enquanto a informação entregue ao usuário não serve para a decisão que ele precisa tomar.

O tema ganhou força porque modelos de linguagem são usados em chatbots, classificação, extração de dados e automações que misturam código determinístico com texto probabilístico. Monitorar apenas disponibilidade e tempo de resposta deixa uma parte importante da qualidade sem cobertura.

Não existe uma biblioteca única ou um criador das falhas silenciosas. Elas surgem na combinação entre prompt, modelo, contexto, ferramentas externas, regras de negócio e código da aplicação. O objetivo deste guia é mostrar como observar essa cadeia sem depender de uma mensagem de erro.

Como funciona

Uma aplicação com LLM costuma receber uma entrada, montar um prompt, anexar contexto, chamar o modelo e transformar a saída em uma ação ou resposta. Cada etapa pode terminar tecnicamente bem e ainda alterar o sentido do resultado.

Imagine uma busca em uma base de documentos. A recuperação pode retornar trechos válidos, mas não os trechos mais relevantes. O modelo então escreve uma resposta coerente usando um contexto insuficiente. Nenhuma dessas etapas precisa quebrar a execução.

Por isso, a observabilidade precisa acompanhar mais do que logs de exceção. É útil registrar a versão do prompt, a origem do contexto, as ferramentas chamadas, o formato retornado e uma avaliação da qualidade, sempre removendo dados sensíveis antes de armazenar os eventos.

Principais recursos para encontrar os problemas

A investigação começa separando falhas de formato, falhas de conteúdo e falhas de fluxo. Essa separação ajuda a escolher a proteção certa para cada ponto da aplicação.

Os cinco grupos mais comuns são:

• Regressão de prompt: uma pequena mudança faz o modelo ignorar uma instrução importante.
• Contexto inadequado: a busca, o recorte ou a ordenação dos documentos não ajudam a pergunta atual.
• Formato instável: a resposta é texto válido, mas não respeita o contrato que o próximo passo espera.
• Ferramenta ou dado desatualizado: a chamada termina, porém usa uma fonte vazia, antiga ou incompleta.
• Avaliação cega: os testes verificam apenas status, latência ou presença de texto e não conferem o significado.

O diferencial de uma boa estratégia é comparar a saída com exemplos esperados e regras de negócio. Uma resposta bem escrita não deve ser aprovada automaticamente quando a tarefa exige precisão, rastreabilidade ou um formato específico.

Como começar: instalação e acesso passo a passo

Você pode começar sem trocar o provedor do modelo. Separe um pequeno conjunto de entradas reais, remova informações pessoais e guarde a resposta que a aplicação produz hoje. Esse conjunto será a primeira referência para detectar regressões.

Em um projeto Python, instale ferramentas simples para testar contratos e automatizar verificações. O modelo pode continuar sendo chamado pelo código que sua aplicação já usa.

Python -m venv .venv
source .venv/bin/activate
pip install pytest jsonschema

Depois, defina o que é uma resposta aceitável para cada caso. Inclua exemplos normais, entradas ambíguas, ausência de contexto e falhas de integração. Comece com poucos casos, mas revise-os quando uma falha real aparecer.

Exemplo prático

Considere um assistente que classifica chamados de suporte. A saída pode ter JSON válido e uma categoria permitida, mas ainda classificar um pedido de boleto como problema técnico. A validação estrutural aprova o documento, enquanto a avaliação semântica encontra o erro.

Uma proteção básica combina schema com um conjunto de respostas de referência. O primeiro teste verifica o contrato; o segundo compara a decisão com o gabarito mantido pela equipe.

from jsonschema import validate

SCHEMA = {
    'type': 'object',
    'required': ['categoria', 'resumo'],
    'properties': {
        'categoria': {'enum': ['financeiro', 'técnico', 'acesso']},
        'resumo': {'type': 'string', 'minLength': 1}
    },
    'additionalProperties': False
}

def validar_resposta(resposta):
    validate(instance=resposta, schema=SCHEMA)

def avaliar_categoria(resposta, categoria_esperada):
    validar_resposta(resposta)
    return resposta['categoria'] == categoria_esperada

saída = {'categoria': 'financeiro', 'resumo': 'Pedido sobre boleto'}
assert avaliar_categoria(saída, 'financeiro')

Esse exemplo não prova que toda resposta está correta, mas torna o critério explícito. Na prática, registre também a entrada, a versão do prompt e o motivo da avaliação para que uma mudança possa ser investigada depois.

Comparação com alternativas

Verificar o código HTTP é importante para saber se o serviço está disponível, mas isso não mede a qualidade da resposta. Um teste de unidade com uma saída fixa também ajuda, porém não cobre alterações de prompt, modelo ou contexto.

A validação de schema é excelente para detectar campos ausentes, tipos incorretos e propriedades extras. Ela não diz se uma justificativa está correta ou se a categoria escolhida faz sentido para a entrada.

As avaliações com exemplos reais cobrem o significado, enquanto a observabilidade mostra onde o resultado foi produzido. A melhor combinação usa saúde do serviço, testes determinísticos, contratos, avaliações semânticas e revisão humana nos casos de maior risco.

• Use logs e métricas para disponibilidade, erro e latência.
• Use schema para garantir o formato consumido pelo código.
• Use avaliações para conferir a qualidade da resposta.
• Use revisão humana quando uma saída errada puder causar prejuízo relevante.

Pontos positivos e limitações

O principal benefício dessa abordagem é transformar qualidade em algo verificável. Em vez de confiar na impressão de que o texto parece bom, a equipe cria critérios e acompanha mudanças com exemplos reproduzíveis.

Outro ganho é a investigação mais rápida. Quando uma avaliação falha, a equipe pode comparar o prompt, o contexto e a ferramenta usados naquele caso, em vez de procurar uma exceção genérica em todo o sistema.

A limitação é que nem toda resposta tem uma única formulação correta. Os casos de avaliação precisam ser revisados, o custo de chamadas pode crescer e dados sensíveis exigem cuidado especial. Além disso, uma métrica agregada pode esconder erros graves em um grupo pequeno de usuários.

Casos de uso reais

Em um time de atendimento, a avaliação pode conferir se a resposta usa a política correta e se encaminha exceções para uma pessoa. O status HTTP sozinho não detecta uma orientação desatualizada.

Em uma rotina de extração de notas fiscais ou contratos, o schema verifica o formato dos campos e uma amostra revisada verifica o conteúdo. Um valor ausente pode ser mais perigoso do que uma exceção visível.

Para uma equipe de desenvolvimento, avaliações podem comparar sugestões de código com testes, regras de segurança e requisitos do ticket. A resposta pode compilar e ainda introduzir uma decisão incorreta.

Em um produto de busca com documentos internos, a equipe pode medir se a resposta está apoiada no contexto recuperado. Isso ajuda a distinguir um problema de recuperação de um problema de instrução do modelo.

Dicas e boas práticas

A qualidade melhora quando a equipe trata o fluxo inteiro como um sistema observável. As práticas abaixo são simples de aplicar e ajudam a evitar que um resultado apenas plausível seja confundido com um resultado correto.

pytest -q

# Rode a avaliação sem incluir dados sensíveis no relatório
Python avaliar_respostas.py --dataset casos-seguros.json

Vale a pena?

Sim, vale a pena para qualquer aplicação em que uma resposta errada tenha impacto maior do que alguns milissegundos de latência. Chatbots internos, extração, classificação e assistentes de código se beneficiam de critérios que vão além do HTTP 200.

O investimento pode ser pequeno no começo: alguns casos reais, um schema e uma avaliação executada no CI já revelam problemas que os logs tradicionais não mostram. Depois, a equipe pode adicionar métricas, rastreamento de contexto e revisão por amostragem.

Se você está começando, escolha um fluxo importante e escreva o primeiro teste antes de ajustar o prompt novamente. O próximo passo é transformar uma falha silenciosa conhecida em um caso que falha de forma visível, explica o motivo e impede uma regressão.