Resumo Técnico: Litmus – Especificação de Métricas Baseada em Código e Zero-Label

Declaração do Problema

À medida que os sistemas de Grandes Modelos de Linguagem (LLMs) transitam de protótipos para pipelines de produção agentes complexos (envolvendo recuperação, uso de ferramentas, roteamento e fallbacks), a avaliação tornou-se cada vez mais difícil. As práticas atuais sofrem de dois problemas primários:

1. Objetivos de Avaliação Implícitos: Os objetivos de avaliação são frequentemente deixados sem declaração, levando a uma abordagem de "salada mista" onde métricas são selecionadas sem um racional claro.
2. Desalinhamento com Necessidades de Produção: Métricas automáticas são frequentemente projetadas para comparação de saída final em ambientes de pesquisa, falhando em suportar a depuração, monitoramento, auditabilidade e gestão de risco exigidas em produção. Falhas em sistemas agentes frequentemente derivam de componentes intermediários (ex: erros de recuperação, regras puladas, confiança mal calibrada) em vez de apenas o escore da saída final.

Sistemas de métricas automáticas existentes (ex: AutoMetrics, DynamicRubric) assumem que o alvo de avaliação já é conhecido e focam em ajustar um juiz às saídas finais, muitas vezes exigindo rótulos ou gerando rubricas sem interrogar o design real do sistema.

Metodologia: O Sistema Litmus

O Litmus é um sistema zero-label que projeta a avaliação e as métricas de monitoramento diretamente a partir do código-fonte. Ele reformula o design de métricas como um problema de elicitação de objetivos resolvido através de interrogação. O sistema opera em cinco estágios (Figura 2):

1. Reconstrução de Arquitetura:

   • Um scanner determinístico analisa o codebase para construir grafos de importação e de símbolos/chamadas.
   • Um LLM sintetiza um grafo de componentes de 8 a 20 nós descrevendo módulos, papéis, capacidades de IA e superfícies de risco.
   • Um crítico adversário valida este grafo contra evidências de código, podando componentes "fantasmagóricos" e sinalizando componentes perdidos para garantir que a arquitetura esteja fundamentada em código resolvível.

2. Classificação de Padrões:

   • Os componentes são mapeados para uma taxonomia de padrões de avaliação (ex: aquisição de dados, núcleo de IA, garantia) e estratégias transversais (ex: RAG, orquestração de agentes).
   • Este passo estreita o espaço de design ao identificar famílias plausíveis de métricas (ex: cobertura para recuperação, latência para núcleos de IA) sem resolver as suposições subjacentes.

3. Interrogação (Geração de Restrições):

   • O Litmus converte ambiguidades em restrições explícitas via dois canais:
     • Perguntas de Clarificação: Direcionadas a profissionais para resolver decisões subespecificadas (ex: "Os caminhos de fallback devem disparar com frequência?").
     • Perguntas de Validade Adversária: Verificações internas por um crítico de LLM em quatro eixos: ajuste de pipeline, condições de validade, suposições de dados e direção de qualidade.
   • As respostas a estas perguntas tornam-se fatos confirmados (restrições rígidas) que admitem, rejeitam ou reescalonam métricas candidatas.

4. Design de Métricas:

   • Condicionado pela arquitetura reconstruída e pelos fatos confirmados, o sistema emite um portfólio de métricas de alto sinal por componente.
   • O portfólio inclui:
     • Verificações determinísticas: Para comportamentos mensuráveis (ex: taxas de erro, latência).
     • Métricas LLM-as-Judge: Pontuadas em uma rubrica de 5 pontos com raciocínio de Cadeia de Pensamento (CoT) para qualidade semântica.
     • Métricas compostas: Sub-métricas ponderadas que medem uma única dimensão de qualidade a partir de múltiplos ângulos.
   • Uma "regra de cinco métricas" limita a redundância, e uma "regra de não-guarda-chuva" garante que as métricas visem níveis específicos em vez de saídas vagas de nível de módulo.

5. Rastreabilidade e Exportação:

   • O sistema exporta definições de métricas executáveis com rastreabilidade total ao código-fonte e aos fatos confirmados que as justificam.
   • Ele mapeia métricas de avaliação offline para seus correspondentes de monitoramento de produção.

Contribuições Principais

1. Reformulação do Design de Métricas: O artigo propõe mudar de "qual métrica computar?" para "o que deve ser medido e por quê?" ao tratar o design de métricas como um problema de resolução de incerteza baseado em inquirição, conectando preocupações de validade à geração de perguntas de clarificação.
2. Sistema Litmus: Um sistema zero-label que deriva um portfólio de métricas justificado e por estágio a partir do código-fonte isoladamente, usando respostas de profissionais e verificações de validade interna como restrições de design explícitas.
3. Framework de Avaliação: Os autores introduzem eixos de nível de portfólio para caracterizar sistemas de design de métricas automáticas:
   • Cobertura: A fração das preocupações de falha de referência endereçadas.
   • Fundamentação (Grounding): O grau em que as métricas se referem a artefatos de implementação específicos (módulos, regras) em vez de linguagem genérica.
   • Redundância: A fração de pares de métricas que medem o mesmo comportamento.

Resultados Experimentais

O Litmus foi avaliado em três pipelines de IA reais e definidos por código: Agrupamento de Contas Financeiras, QA Científica (PaperQA2) e Avaliação de Risco Inerente. Foi comparado ao AutoMetrics e a três baselines de DynamicRubric (INST, DS, FT).

• Cobertura: O Litmus alcançou a cobertura mais ampla ou empatou na cobertura mais ampla em todos os pipelines, abrangendo mais estágios de pipeline do que as baselines que focavam em saídas finais.
• Redundância: O Litmus produziu um portfólio de quase zero redundância, superando significativamente o AutoMetrics.
• Fundamentação: O Litmus liderou em fundamentação para os pipelines financeiro e de risco, com apenas um leve atraso no QA Científico.
• Validade (Acordo de Rótulos): Apesar de usar zero rótulos durante o design, o Litmus alcançou a maior validade (Spearman $\rho$) contra rótulos de qualidade independentes por linha em todos os três pipelines.
  • QA Científica: O Litmus alcançou $\rho = 0,72$, superando decisivamente todas as baselines (todas $< 0,47$).
  • Financeiro & Risco: O Litmus classificou-se em primeiro lugar, com resultados caindo dentro de intervalos de confiança sobrepostos às baselines mais fortes em alguns componentes, mas mantendo um ranking favorável sob a restrição zero-label.
• Sensibilidade à Degradação: As métricas do Litmus foram entre as mais sensíveis a saídas sinteticamente degradadas, igualando ou excedendo as baselines na detecção de corrupção.

Significância e Alegações

O artigo alega que a especificação de métricas automática (definir o que e por que medir) é um pré-requisito para uma implementação de métricas automática eficaz. Ao interrogar o código-fonte e os profissionais, o Litmus produz um "portfólio justificado" onde cada métrica está ligada a evidências e à intenção de design.

Os autores posicionam o Litmus como uma mudança de tratar métricas como objetos genéricos selecionados post-hoc para tratá-las como compromissos de medição fundamentados no design do sistema. Os resultados sugerem que a elicitação de alvos de avaliação via interrogação produz maior cobertura, menor redundância e maior validade do que sistemas que assumem que o alvo de avaliação é conhecido ou que focam exclusivamente na pontuação da saída final. O artigo conclui que esta abordagem é particularmente vital para pipelines de IA de produção onde as falhas são distribuídas por componentes intermediários e requerem monitoramento rastreável e específico por estágio.

Limitações Reconhecidas:

• A avaliação dependeu de uma única família de modelos-juiz para pontuação, potencialmente introduzindo viés de alinhamento.
• Os sistemas comparados não são estritamente comensuráveis (Litmus é design zero-label; baselines são ajustadas por rótulos ou geradoras de rubricas).
• Métricas de cobertura são monótonas com o tamanho do portfólio, e as listas de preocupação de referência foram elaboradas pelos próprios autores.
• O benefício end-to-end das perguntas de clarificação do profissional requer estudos humanos adicionais.