Resumo Técnico: Quando as Políticas Alteram as Probabilidades

Declaração do Problema

Sistemas de revisão de código baseados em Grandes Modelos de Linguagem (LLMs) dependem cada vez mais de modelos para estimar o risco de um patch (probabilidade de falha) e tomar decisões de aprovação dentro de um único prompt. Este design assume que uma probabilidade relatada descreve o patch e suas evidências, independentemente da política de decisão a jusante (ex: o custo de uma falsa aceitação versus uma falsa rejeição).

O artigo investiga uma questão crítica de sistemas: Quando o patch e as evidências estão fixos, uma política de decisão a jusante pode alterar a própria probabilidade numérica de falha? Se um bloco de política (que define custos e limiares) altera a probabilidade relatada, o escore torna-se "dependente da política", tornando-o instável para reutilização, calibração ou comparação entre diferentes custos de erro organizacionais.

Metodologia

Configuração Experimental

O estudo avalia quatro interfaces de revisor implantadas (DeepSeek-V4-Pro, Grok-4.3, Mistral-medium-3.5 e GPT-5.5/Codex) usando 15.792 respostas sobre 720 candidatos a patches.

• Fonte de Dados: 360 problemas de repositório do SWE-rebench. Para cada problema, o conjunto de dados inclui exatamente um patch que passou e um que falhou em um harness de teste executável arquivado, criando uma taxa de falha de candidatos equilibrada de 50%.
• Monitor: Um modelo separado (Gemini 3.5 Flash) fornece um escore de falha contínuo e independente para cada patch.

Designs de Sistema Avaliados

1. Revisor de Prompt Único (Conjunto): O LLM recebe o patch, o contexto do código, o escore do monitor e um bloco de política (definindo custos e limiares) em um único prompt, gerando tanto uma probabilidade quanto uma ação.
2. Pipeline Modular (Separado):
   • Apenas Risco: O revisor relata uma probabilidade de falha sem qualquer informação de política (custos, limiares ou priors).
   • Monitor: Um modelo independente fornece um esscore de falha.
   • Controlador: O código combina os escores do revisor e do monitor e aplica a regra de decisão (limiarização) com base na política de custo específica.

Condições de Prompt

O estudo utiliza pares correspondentes de chamadas onde o patch, o contexto e as evidências do monitor são idênticos, mas o bloco de política varia:

• Custo Igual (Condição A): Custo de falsa aceitação = 1, Limiar = 0,5.
• Custo-10 (Condição C): Custo de falsa aceitação = 10, Limiar ≈ 0,091.
• Prior Baixo (Condição B): Assume que a taxa de falha mudou para 0,10 (usado como um controle positivo para verificar a sensibilidade aos priors de evidência).
• Custo-20 (Condição D): Custo de falsa aceitação = 20.

Métricas

• Brier Score: Erro quadrático médio das previsões de probabilidade (quanto menor, melhor).
• Perda de Decisão (Decision Loss): Calculada usando os custos impressos no prompt. Aceitar um patch que falha custa $C_{FA}$; rejeitar um patch que passa custa $C_{FR}=1$.
• Dependência de Política: Medida pela mudança na probabilidade relatada quando apenas o bloco de política muda, comparada à variação de repetição no mesmo prompt.

Principais Resultados

1. Prompts de Política Alteram o Risco Relatado

Substituir um bloco de política de custo igual por um bloco de alto custo (10:1) alterou significativamente as probabilidades de falha relatadas, embora o patch e as evidências tenham permanecido fixos.

• Magnitude: A mudança média na probabilidade relatada foi de 13,6 a 16,9 pontos percentuais entre os quatro sistemas.
• Estabilidade: Para três dos quatro sistemas (Grok, Mistral, GPT/Codex), esse movimento induzido pela política excedeu a variação observada em chamadas repetidas do mesmo prompt.
• Direção: A mudança não foi uniforme; alguns modelos baixaram suas estimativas de risco, enquanto outros (Grok) aumentaram ligeiramente, indicando mudanças comportamentais heterogêneas em vez de um único viés conservador.
• Precisão: O prompt de custo-10 piorou o Brier score médio em 0,0323 em comparação com o prompt de custo igual.

2. Impacto na Decisão e Perda Excessiva

• Ações do Modelo: Para cada revisor, as ações retornadas diretamente pelo prompt de alto custo (Custo-10) resultaram em maior perda de decisão do que simplesmente rejeitar todos os patches.
• Fonte da Perda: Quando a mesma regra de alto custo foi aplicada via código às probabilidades elicitadas sob custos iguais, a perda de decisão diminuiu para todos os quatro sistemas. Isso demonstra que o ato de elicitar a probabilidade sob um prompt de alto custo contribui para a perda excessiva, independentemente da capacidade do modelo de aplicar o limiar.
• Aderência ao Limiar: Embora o Grok, Mistral e GPT/Codex tenham seguido amplamente a limiarização determinística de suas próprias probabilidades relatadas (88–98% de concordância), as probabilidades em si foram degradadas pelo contexto da política.

3. Desempenho do Pipeline Modular

• Custos Iguais: O pipeline modular (Revisor de Apenas Risco + Monitor + Controlador de Código) melhorou a precisão da probabilidade média e reduziu a perda de decisão média em 0,073 por problema em comparação com escores de revisor calibrados, aceitando 58–68% dos patches.
• Altos Custos (10:1): Em uma penalidade de falsa aceitação de 10:1, o pipeline modular aceitou 0% dos patches, igualando-se à linha de base de "rejeitar tudo". Isso indica que, embora o design modular evite a distorção de probabilidade induzida pela política, os escores disponíveis (mesmo combinados) não são precisos o suficiente para suportar aprovações não triviais sob restrições de custo extremas.
• Papel do Monitor: O monitor substituiu em grande parte os revisores mais fracos (DeepSeek, Grok, Mistral), mas proporcionou apenas um ganho marginal e incerto para o revisor mais forte (GPT/Codex).

Significância e Alegações

O artigo argumenta que a estimativa de risco e a tomada de decisão devem ser avaliadas separadamente. A principal contribuição é a demonstração de que "a política a jusante pode mudar a probabilidade que ela deveria usar".

• Interface vs. Capacidade: O estudo distingue entre um problema de interface (probabilidades dependentes de política que mudam quando os custos mudam) e um limite de capacidade (escores que não são precisos o suficiente para suportar aprovações sob altos custos). O design modular resolve o problema da interface, mas expõe o limite de capacidade.
• Protocolo de Avaliação: Os autores propõem uma avaliação de três partes para sistemas de revisão:
  1. Manter o caso e a evidência fixos, variar a política a jusante e comparar o movimento da probabilidade contra chamadas repetidas.
  2. Relatar o erro para revisor-apenas, monitor-apenas e escores combinados usando representações de evidência correspondentes.
  3. Aplicar regras de decisão fora do modelo e relatar a perda em todo o intervalo de custo relevante.
• Implicações de Design: Um escore dependente de política é difícil de usar como uma interface de software porque não pode ser confiável para cache, recalibração ou consumo por equipes com diferentes estruturas de custo. Separar as etapas (elicitação de risco, combinação de evidências e aplicação de custo) cria um registro mais claro de onde as mudanças se originam.

Os autores declaram explicitamente que estas descobertas dizem respeito a quatro interfaces de revisor fixas e um resultado de harness arquivado; eles não implicam comportamento universal em todos os modelos ou que chamadas separadas sejam o único design viável, mas sim que qualquer design deve passar no teste de independência de política para ser robusto.