Avaliação de Apps com LLM

O que “Avaliação de Aplicativos com LLM” Significa (e Por Que É Diferente da Avaliação de Modelos)

Avaliar um modelo de linguagem (por exemplo, acurácia em um benchmark) não é o mesmo que avaliar uma aplicação de LLM. Um aplicativo de LLM é um sistema: prompts, recuperação, ferramentas, políticas, pós-processamento, restrições de UI, orçamentos de latência/custo e expectativas humanas interagem entre si.

Por exemplo, em um aplicativo de geração aumentada por recuperação (RAG, retrieval-augmented generation), o modelo pode ser capaz de responder corretamente, mas ainda assim falhar porque:

  • o recuperador não buscou o trecho certo,
  • o trecho foi buscado, mas não foi usado,
  • o modelo alucinou além das fontes,
  • o aplicativo respondeu corretamente, mas com tom, latência inaceitáveis ou sem citações.

Este artigo foca em estratégias de avaliação e métricas para aplicativos de LLM — especialmente RAG — centradas em fundamentação, fidelidade e qualidade ponta a ponta. Ele complementa tópicos mais amplos de avaliação como Avaliação Offline, Avaliação Humana e LLM-como-Juiz.

Anatomia de um Aplicativo de LLM (O Que Você Está De Fato Avaliando)

A maioria dos aplicativos de LLM pode ser decomposta em etapas:

  1. Interpretação da entrada
    • Engenharia de prompts (prompting), instruções do sistema, contexto do usuário, histórico da conversa
  2. Recuperação (opcional, RAG)
    • Reescrita de consulta, busca vetorial, reordenamento (reranking), segmentação em trechos (chunking)
  3. Raciocínio e geração
    • O modelo produz uma resposta; pode incluir cadeia de pensamento (chain-of-thought) internamente (geralmente não exposta)
  4. Uso de ferramentas (opcional)
    • Chamadas de APIs, execução de código, consultas a banco de dados, agentes
  5. Pós-processamento
    • Formatação, citações, filtros de segurança, redação (redaction), saídas estruturadas (JSON)
  6. Restrições de serviço
    • Latência, custo, limites de taxa, cache, modelos de fallback

Um bom plano de avaliação mede:

  • Qualidade do componente (por exemplo, recall de recuperação),
  • Qualidade da resposta (por exemplo, correção, fundamentação),
  • Qualidade do sistema (por exemplo, sucesso da tarefa, satisfação do usuário, custo/latência).

Conceitos-Chave: Correção, Fundamentação e Fidelidade

Esses termos frequentemente são usados de forma vaga, então ajuda ser explícito.

Correção (Acurácia da Tarefa)

Correção pergunta: A resposta está certa para a pergunta do usuário?
Isso pode exigir uma resposta de referência, um rótulo ouro (gold label) ou um juiz humano.

Correção é essencial, mas em RAG não é suficiente — uma resposta pode estar correta pelos motivos errados (por exemplo, chute com sorte ou memorização).

Fundamentação (Apoiada por Fontes Fornecidas)

Fundamentação pergunta: A resposta é sustentada pelo contexto recuperado (e/ou por fontes citadas)?

Em RAG, fundamentação é a promessa central: o sistema deve fundamentar as respostas em documentos recuperados, em vez de fatos alucinados.

Operacionalmente, fundamentação costuma ser medida como:

  • a fração de afirmações que são implicadas (entailed) pelos trechos recuperados,
  • se a resposta inclui citações que realmente sustentam as afirmaativas.

Fidelidade (Sem Afirmações Não Sustentadas ou Contraditórias)

Fidelidade pergunta: A resposta evita introduzir informação que não está presente no contexto e evita contradizer o contexto?

Em muitas configurações de avaliação de RAG:

  • Fundamentação enfatiza “sustentada por fontes” (evidência positiva),
  • Fidelidade enfatiza “sem alucinações / sem contradições” (evidência negativa).

Elas se sobrepõem bastante, mas distingui-las é útil:

  • Uma resposta pode ser parcialmente fundamentada (algumas afirmações sustentadas), mas infiel (adiciona detalhes extras não sustentados).
  • Uma resposta pode ser fiel (apenas repete o contexto) e ainda assim não correta (o próprio contexto está errado ou é irrelevante para a pergunta).

Avaliação de RAG: O Que Medir

RAG introduz um modo de falha em duas etapas: a recuperação pode falhar, ou a geração pode falhar mesmo com boa recuperação. Uma avaliação forte de RAG separa essas coisas.

1) Qualidade da Recuperação (Buscamos a evidência certa?)

Métricas comuns de recuperação de informação (IR, information retrieval) se aplicam quando você tem documentos/trechos relevantes rotulados:

  • Recall@k: recuperamos pelo menos um item relevante no top k?
  • Precision@k: que fração dos itens recuperados é relevante?
  • MRR (Mean Reciprocal Rank): quão bem ranqueado está o primeiro resultado relevante?
  • nDCG@k: qualidade do ranqueamento quando a relevância é graduada (por exemplo, 0/1/2)

Nuance prática de RAG: “relevante” frequentemente é no nível do trecho, não no nível do documento. A estratégia de segmentação em trechos pode dominar as métricas de recuperação.

Exemplo: Recall@5

def recall_at_k(retrieved_ids, relevant_ids, k=5):
    topk = set(retrieved_ids[:k])
    return 1.0 if topk.intersection(relevant_ids) else 0.0

Quando você não tem trechos relevantes ouro, ainda é possível avaliar a recuperação via:

  • relevância de contexto julgada por LLM (“Este trecho é útil para responder à pergunta?”),
  • heurísticas como sobreposição com entidades da resposta de referência (ruidoso, mas às vezes útil).

2) Qualidade do Contexto (A evidência é utilizável?)

Mesmo se a recuperação acertar um documento relevante, o contexto retornado pode ser:

  • longo demais (partes importantes truncadas),
  • redundante demais,
  • sem linhas-chave por causa dos limites do trecho,
  • poluído com quase-duplicatas.

Medidas úteis no nível do contexto:

  • Relevância do contexto: quanto do texto recuperado é de fato relevante para a pergunta
  • Cobertura do contexto: se o texto recuperado contém os fatos específicos necessários
  • Redundância: trechos repetidos desperdiçam a janela de contexto

Muitas equipes calculam um score semelhante a “precisão de contexto” com um juiz LLM:

  • Pontuar cada trecho recuperado por relevância em uma escala 0–2 ou 0–1
  • Agregar ao longo do top-k

3) Qualidade da Resposta (O modelo respondeu bem?)

Qualidade da resposta inclui:

  • Correção
  • Fundamentação / fidelidade
  • Completude (cobre todas as subperguntas)
  • Clareza e formatação (concisa, estruturada, segue instruções)
  • Segurança e conformidade com políticas (específico por domínio; veja Avaliação de Segurança)

Em produção, avalie também:

  • Latência (p50/p95)
  • Custo (tokens, chamadas de ferramenta)
  • Estabilidade (variância entre execuções repetidas)
  • Resistência a regressões (desempenho após mudanças em prompt/recuperador)

Medindo Fundamentação e Fidelidade na Prática

Avaliação no Nível de Afirmações (Um Padrão Robusto)

Uma abordagem comum e eficaz é:

  1. Decompor a resposta em afirmações atômicas.
  2. Para cada afirmação, verificar se o contexto recuperado implica, contradiz ou não sustenta a afirmação.
  3. Agregar em scores de fundamentação/fidelidade.

Isso reduz ambiguidade em comparação a julgar a resposta inteira de uma só vez.

Exemplo de rubrica

  • Implicada: explicitamente sustentada pelo contexto
  • Contradita: o contexto diz o oposto
  • Não sustentada: nem implicada nem contradita (risco de alucinação)

Agregações

  • Fundamentação: entailed / total_claims
  • Taxa de infidelidade: (not_supported + contradicted) / total_claims
  • Taxa de contradição: contradicted / total_claims

Usando NLI vs Juízes LLM

Você pode implementar verificações de implicação com:

  • modelos de NLI (inferência de linguagem natural, natural language inference): rápidos, consistentes, mas podem ter desempenho inferior em texto específico de domínio
  • LLM-como-juiz: flexível e muitas vezes de maior qualidade, mas deve ser calibrado (viés, sensibilidade a prompt)

Veja LLM-como-Juiz para design de juiz, calibração e armadilhas.

Dica prática: ao usar um juiz LLM, obrigue-o a citar o(s) trecho(s) de suporte a partir do contexto. Isso incentiva pontuação baseada em evidências e facilita auditorias.

Acurácia de Citações (Quando Você Exige Citações)

Se seu aplicativo produz citações, avalie:

  • Cobertura de citações: afirmações importantes têm citações?
  • Correção de citações: o trecho citado realmente sustenta a afirmação?
  • Especificidade de citações: a citação é precisa (aponta para a passagem certa) vs “spam de citações”?

Um padrão simples: fazer o juiz verificar cada afirmação apenas contra o snippet citado (não o contexto inteiro). Isso captura “citações de passagem”.

Medidas de Qualidade Ponta a Ponta (O Que os Usuários Realmente Sentem)

Métricas de componentes (recall de recuperação, fundamentação) são diagnósticas, mas o resultado que importa é se os usuários têm sucesso.

Medidas ponta a ponta incluem:

Taxa de Sucesso da Tarefa

Defina sucesso em termos dos objetivos do usuário:

  • O usuário obteve a ação/resultado correto?
  • O fluxo de trabalho terminou sem handoff?
  • A resposta correspondeu ao formato exigido (por exemplo, esquema JSON)?

Para fluxos de trabalho com agentes, veja Avaliação de Agentes.

Preferência em Pares / Taxa de Vitória

Em vez de pontuação absoluta, compare sistema A vs sistema B:

  • Mostrar o mesmo prompt e contexto
  • Juízes escolhem a melhor resposta com base em uma rubrica
  • Reportar vitória/empate/derrota com intervalos de confiança

Avaliação em pares frequentemente é mais confiável do que notas 1–5, mas ainda exige desenho cuidadoso do protocolo (veja Avaliação Humana).

Métricas Centradas no Usuário (Online)

Em produção, você pode acompanhar:

  • avaliações de satisfação do usuário (ruidosas, mas úteis em escala),
  • taxa de re-pergunta (“usuário pergunta novamente imediatamente”),
  • taxa de escalonamento para suporte humano,
  • retenção e conclusão de tarefas.

Essas são indicadores defasados e podem ser confundidos por mudanças no produto, mas refletem a realidade melhor do que métricas offline.

Orçamentos de Custo/Latência como Restrições de Qualidade

Uma resposta “melhor” que custa 5× mais ou viola SLAs de latência pode ser pior no geral. Trate latência e custo como saídas de avaliação de primeira classe, não como algo secundário.

Construindo um Bom Conjunto de Avaliação de RAG

Um conjunto de avaliação forte é mais valioso do que qualquer métrica isolada. Princípios de Construção de Benchmarks se aplicam, mas RAG adiciona necessidades específicas.

O Que Incluir

Para cada caso de teste, idealmente armazene:

  • Consulta do usuário
  • Fontes de conhecimento permitidas (qual corpus/silo é permitido)
  • Resposta ouro (se viável)
  • Passagens de suporte ouro (IDs de documento ou IDs de trecho)
  • Casos extremos
    • consultas ambíguas
    • documentos conflitantes
    • perguntas “não está no corpus” (deve se abster ou dizer “não sei”)
    • perguntas restritas por política (deve recusar)

Evitando Contaminação e Vazamento

Se seu conjunto de avaliação é derivado de logs de produção ou documentação:

  • garanta que o modelo não foi ajustado finamente (fine-tuned) nele,
  • cuidado com vazamento de dados de treino em modelos fundacionais,
  • evite artefatos de “resposta no prompt” (por exemplo, incluir texto ouro no contexto recuperado sem querer).

Veja Contaminação do Conjunto de Teste.

Representatividade e Deriva

Aplicativos RAG frequentemente sofrem com deriva de domínio (novos documentos, novas versões de produto). Planeje:

  • atualização periódica dos conjuntos de avaliação,
  • corpora versionados e testes versionados,
  • recortes de “documentos recentes” para detectar regressões.

Um Fluxo de Trabalho Prático de Avaliação (Recomendado)

Um fluxo de trabalho comum para sistemas RAG:

Passo 1: Avaliação Somente de Recuperação

Execute o recuperador sem geração:

  • calcular recall@k e métricas de ranqueamento (se existirem rótulos),
  • executar julgamento de relevância de trechos,
  • inspecionar falhas e ajustar segmentação em trechos, filtros de metadados, reescrita de consulta, reordenamento.

Este estágio responde: Conseguimos buscar a evidência?

Passo 2: Geração Dado Contexto Fixo

Mantenha o contexto recuperado fixo (use passagens ouro ou a saída do recuperador) e avalie a geração:

  • correção,
  • fundamentação/fidelidade,
  • seguimento de instruções.

Este estágio responde: Dada a evidência, o modelo consegue usá-la?

Passo 3: Execuções Completas Ponta a Ponta

Execute o pipeline completo (recuperação + geração + pós-processamento) e avalie:

  • correção ponta a ponta,
  • acurácia de citações,
  • latência/custo,
  • comportamentos de segurança.

Passo 4: Teste de Regressão

Cada mudança (prompt, recuperador, reordenador, versão do modelo, segmentação em trechos) deve rodar uma suíte de regressão e produzir deltas com estimativas de significância. Veja Reprodutibilidade e Significância Estatística.

Exemplo: Avaliando um Bot RAG de Suporte ao Cliente

Imagine um bot respondendo perguntas sobre um manual interno do produto.

Exemplo de caso de teste

  • Consulta: “O plano Pro inclui SSO?”
  • Resposta ouro: “Sim, SSO está incluído no plano Pro.”
  • Evidência ouro: seção do manual “Plans & Authentication”, parágrafo 3

Modos de falha que você quer detectar

  • Erro de recuperação: os trechos top-k não mencionam SSO.
  • Sim não fundamentado: o modelo responde “Sim” corretamente, mas a evidência não sustenta.
  • Errado mas fundamentado: recuperou um documento desatualizado que diz “SSO é apenas Enterprise”; o modelo repete fielmente.
  • Erro de citação: o modelo cita uma página de preços que não menciona SSO.

Um padrão simples de prompt de juiz (conceitual)

  • Entrada: pergunta, resposta, contexto recuperado
  • Saída:
    • lista de afirmações atômicas
    • para cada afirmação: implicada / não sustentada / contradita + evidência citada
    • score geral de fundamentação

Isso gera tanto uma métrica numérica quanto uma trilha de auditoria.

Armadilhas Comuns (e Como Evitá-las)

Manipulação de Métricas e Lei de Goodhart

Se você otimiza um proxy de forma agressiva demais, pode degradar a qualidade real (por exemplo, maximizar contagem de citações gera citações sem sentido). Este é um caso concreto de Lei de Goodhart em Métricas.

Mitigação: Use um portfólio de métricas (correção + fundamentação + preferência do usuário + custo/latência) e atualize periodicamente os conjuntos de avaliação.

Dependência Excessiva de Scores de Número Único

Um único “score de RAG” esconde estrutura importante:

  • falhas de recuperação vs alucinações na geração exigem correções diferentes,
  • algumas consultas são inerentemente ambíguas,
  • algumas falhas são graves (violação de política), mesmo que raras.

Mitigação: Sempre recorte métricas por categoria (tópico, dificuldade, “precisa de recuperação”, “deve se abster”, atualização do documento).

Viés do Juiz e Não Determinismo

Juízes LLM podem ser viesados a verbosidade, certos tons, ou à família de modelo usada. Eles também introduzem variância.

Mitigação:

  • calibrar juízes em um subconjunto rotulado,
  • usar comparações em pares para diferenças sutis,
  • amostrar múltiplas execuções do juiz para confiança,
  • manter versão do modelo/prompt do juiz.

(Veja LLM-como-Juiz.)

Rótulos de Recuperação Que Não Correspondem à Realidade

“Passagens ouro” podem ser incompletas: pode haver múltiplas fontes válidas, ou a resposta ouro pode ser derivável de vários documentos.

Mitigação: Permitir múltiplas passagens relevantes; tratar a avaliação de recuperação como fracamente supervisionada a menos que você tenha curado evidências com cuidado.

Ignorar Robustez

Sistemas RAG frequentemente quebram sob:

  • erros de digitação, paráfrases, consultas multilíngues,
  • prompts adversariais (“ignore o contexto”),
  • históricos longos de conversa e correferência,
  • documentos conflitantes.

Mitigação: Adicionar testes de estresse e recortes adversariais. Veja Avaliação Robusta.

Padrões de Ferramentas (O Que as Equipes Costumam Implementar)

Mesmo sem um fornecedor específico, a maioria das equipes maduras constrói:

  • Um harness de avaliação que reexecuta prompts de teste e armazena:
    • trechos recuperados
    • saídas do modelo
    • chamadas de ferramenta
    • latência, tokens, custos
  • Um formato de anotação para:
    • respostas ouro (quando possível)
    • IDs de evidência ouro
    • tags categóricas
  • Um pipeline de juiz (frequentemente baseado em LLM) que produz:
    • julgamentos de fundamentação/fidelidade com trechos de evidência citados
    • julgamentos de correção ou preferência
  • Um dashboard para recortes e diffs de regressão

Ferramentas open-source e de plataformas comumente suportam esses fluxos; independentemente da ferramenta escolhida, o ponto-chave é versionamento (corpus, prompts, modelos, juízes e conjuntos de teste).

Checklist Prático

Ao avaliar um aplicativo de LLM (especialmente RAG), garanta que você consegue responder:

  • Recuperação
    • Qual é o recall@k em consultas rotuladas?
    • Os trechos recuperados são de fato relevantes (e não apenas topologicamente similares)?
  • Fundamentação e fidelidade
    • Que fração das afirmações da resposta é sustentada pelo contexto?
    • Existem contradições ou adições não sustentadas?
    • As citações são corretas e específicas?
  • Qualidade ponta a ponta
    • O sistema resolve a tarefa do usuário?
    • Como ele se comporta em consultas “não está no corpus” (comportamento de abstenção)?
    • Quais são as distribuições de latência e custo?
  • Confiabilidade
  • Segurança

Resumo

Avaliação de aplicativos com LLM é avaliação de sistemas. Para aplicações RAG, a lente mais útil é:

  • Qualidade da recuperação (você consegue buscar a evidência?),
  • Fundamentação e fidelidade (a resposta se mantém na evidência e evita alucinação?),
  • Qualidade ponta a ponta (o usuário tem sucesso sob restrições reais?).

A prática de maior alavancagem é construir um conjunto de avaliação representativo e versionado e separar diagnósticos da etapa de recuperação dos diagnósticos da etapa de resposta — e então usar uma combinação de métricas automatizadas, juízes calibrados e revisão humana seletiva para orientar melhorias iterativas.