Fila de revisão humana: escolher quais respostas do agente merecem auditoria

A confusão que produz filas inúteis é tratar como um só problema o que são dois. Estimar a taxa de erro do sistema exige amostra aleatória, sem viés, porque qualquer seleção enviesada destrói a capacidade de generalizar o número para o todo. Encontrar e corrigir erros exige exatamente o contrário: concentrar a atenção onde a probabilidade de erro é maior. As duas coisas são necessárias, e a solução é dividir explicitamente o orçamento entre elas em vez de escolher uma e fingir que ela serve para as duas.

orcamento diario de revisao: 60 respostas

[ 12 ] amostra aleatoria pura ....... estimar a taxa de erro real
[ 30 ] risco alto por sinal ......... encontrar defeito onde ele mora
[ 12 ] fronteira de decisao ......... calibrar limiar de escalonamento
[  6 ] casos novos ou fora do padrao . descobrir o que ainda nao existe

a fatia aleatoria e a unica que produz numero generalizavel
as outras tres produzem correcao, nao estatistica

A divisão acima não é arbitrária e cada fatia responde a uma pergunta distinta. A fatia aleatória é a única que permite dizer "a qualidade é de noventa e quatro por cento" com honestidade, e ela precisa ser pequena mas nunca zero, porque sem ela você perde a régua e passa a medir apenas o que já suspeitava. A fatia de risco alto é onde a correção acontece. A fatia de fronteira serve para calibrar limiares, que é uma tarefa recorrente e que ninguém faz sem dados. E a fatia de novidade é o seguro contra o ponto cego: ela existe para pegar o tipo de caso que ainda não tem sinal associado porque nunca apareceu antes.

Vale ser explícito sobre a consequência estatística de misturar: se você revisar só o que o sistema marcou como arriscado e reportar a taxa de erro dessa fila como taxa de erro do produto, o número vai ser terrível e não vai significar nada. O contrário também acontece: times que revisam só amostra aleatória concluem que a qualidade está ótima enquanto uma falha concentrada num tipo raro de pedido queima clientes silenciosamente todo mês.

Escolher o que revisar é um problema de ordenação, e ordenar exige sinal. O erro comum é usar um único indicador, quase sempre a confiança auto declarada do modelo, que é o pior deles isoladamente: modelos são confiantes quando erram e a correlação entre confiança expressa e correção é fraca o suficiente para não sustentar uma fila. O que funciona é combinar sinais baratos de origens diferentes, porque eles falham de formas diferentes e a combinação cobre mais que a soma das partes.

Repare que três desses sinais são gratuitos, porque já existem nos dados que o sistema produz: transbordo, reformulação e chamada de ferramenta. Começar por eles é a decisão certa quando não há orçamento para instrumentar nada novo, e eles sozinhos já rendem uma fila muito melhor que aleatória. A divergência entre gerações é o sinal mais forte da lista e o único que custa dinheiro, então ele entra depois, aplicado apenas ao subconjunto que já passou pelos outros filtros.

// Pontuacao de prioridade da fila. Sinais somados com peso, todos
// normalizados entre zero e um, para que o peso signifique alguma coisa.

const PESOS = {
  recuperacaoFraca: 0.25,
  transbordo: 0.30,
  reformulacao: 0.15,
  ferramentaComEfeito: 0.20,
  tamanhoAnomalo: 0.10,
};

// Valor de negocio multiplica em vez de somar: um erro numa conversa de
// ticket alto importa mais que o mesmo erro numa consulta trivial.
const fatorValor = (valorConversa, valorMediano) =>
  Math.min(3, Math.max(0.5, valorConversa / Math.max(1, valorMediano)));

export const pontuarParaRevisao = (resposta, contexto) => {
  const sinais = {
    // Escore de recuperacao vira risco invertido: quanto pior o contexto
    // recuperado, maior a chance de a resposta ter sido inventada.
    recuperacaoFraca: resposta.usouRag
      ? Math.max(0, 1 - resposta.escoreRecuperacaoTopo)
      : 0,
    transbordo: resposta.houveTransbordo ? 1 : 0,
    reformulacao: resposta.clienteReformulouEmSeguida ? 1 : 0,
    ferramentaComEfeito: resposta.ferramentasChamadas.some((f) => f.temEfeitoColateral) ? 1 : 0,
    tamanhoAnomalo: contexto.desvioDeTamanho(resposta) > 2 ? 1 : 0,
  };

  const base = Object.entries(PESOS).reduce(
    (soma, [chave, peso]) => soma + peso * sinais[chave],
    0,
  );

  return {
    prioridade: base * fatorValor(resposta.valorConversa, contexto.valorMediano),
    // Guardar os sinais junto da pontuacao e o que permite ao revisor
    // saber por que aquele item chegou na fila dele.
    sinais,
  };
};

Duas escolhas desse código são deliberadas. A primeira é o valor da conversa entrar como multiplicador e não como mais uma parcela: um erro numa negociação de ticket alto merece atenção desproporcional, e somar mais um peso não produz esse comportamento. A segunda é devolver os sinais junto com a pontuação. Um item que chega na fila sem explicação faz o revisor gastar dois minutos entendendo por que está olhando aquilo, e dois minutos vezes trezentos itens é o turno inteiro de uma pessoa.

Aqui está o erro operacional que mata mais iniciativas de revisão do que qualquer problema técnico: a fila é dimensionada pela quantidade de itens suspeitos, e não pela capacidade humana disponível. Numa segunda-feira com incidente, o sistema marca oito mil respostas como arriscadas, a fila estoura, o revisor abre, vê o tamanho e fecha. A partir daí a fila está morta, e a próxima conversa sobre revisão humana vai começar do zero em seis meses.

A fila precisa ser um orçamento, não um filtro. Se a capacidade é de sessenta itens por dia, a fila do dia tem exatamente sessenta itens, escolhidos como os melhores sessenta segundo a pontuação e as cotas de cada fatia. O que não entrou não fica pendente: ele é descartado da fila e continua existindo nos dados agregados, onde é contado sem ser lido individualmente. Essa distinção entre "revisado" e "contabilizado" é o que impede a fila de virar dívida.

1. Meça o tempo real de revisão por item, cronometrado e não estimado, incluindo o tempo de ler o contexto da conversa e não só a resposta final.
2. Defina a capacidade diária como número de itens, derivada desse tempo e das horas que o time realmente tem, com folga para os itens difíceis que levam o triplo.
3. Monte a fila do dia por cota: cada fatia recebe um número fixo de vagas e disputa internamente por pontuação, para que a fatia de risco alto nunca engula a de amostra aleatória.
4. Descarte o excedente explicitamente em vez de acumular, e registre quantos itens ficaram de fora para que o dado de cobertura seja honesto.
5. Reserve uma faixa da capacidade para itens vindos de incidente aberto, porque durante incidente a prioridade muda e a fila normal fica irrelevante.

// Montagem da fila diaria por cota. A capacidade e o limite superior,
// e o excedente e descartado de proposito para a fila nunca virar deposito.

const COTAS = {
  aleatoria: 0.2,
  riscoAlto: 0.5,
  fronteira: 0.2,
  novidade: 0.1,
};

const pegarMelhores = (itens, n) =>
  [...itens].sort((a, b) => b.prioridade - a.prioridade).slice(0, n);

export const montarFilaDoDia = (candidatos, capacidade, aleatorioSeguro) => {
  const vagas = Object.fromEntries(
    Object.entries(COTAS).map(([fatia, fracao]) => [fatia, Math.floor(capacidade * fracao)]),
  );

  const porFatia = {
    // Amostra aleatoria de verdade: sem ordenacao por pontuacao, ou o
    // numero que ela produz deixa de ser generalizavel.
    aleatoria: aleatorioSeguro(candidatos, vagas.aleatoria),
    riscoAlto: pegarMelhores(
      candidatos.filter((c) => c.prioridade >= 0.6),
      vagas.riscoAlto,
    ),
    // Fronteira: itens perto do limiar de escalonamento, onde a decisao
    // de automatizar ou transbordar e mais dificil e mais calibravel.
    fronteira: pegarMelhores(
      candidatos.filter((c) => Math.abs(c.prioridade - 0.5) < 0.08),
      vagas.fronteira,
    ),
    novidade: pegarMelhores(
      candidatos.filter((c) => c.intencaoRara || c.semCoberturaNoEval),
      vagas.novidade,
    ),
  };

  const vistos = new Set();
  const fila = [];
  for (const [fatia, itens] of Object.entries(porFatia)) {
    for (const item of itens) {
      if (vistos.has(item.id)) continue; // um item pertence a uma fatia so
      vistos.add(item.id);
      fila.push({ ...item, fatia });
    }
  }

  return {
    fila,
    // Descartados nao viram pendencia: entram na metrica de cobertura
    // e desaparecem da fila, que precisa caber no turno de hoje.
    descartados: candidatos.length - fila.length,
    cobertura: candidatos.length === 0 ? 1 : fila.length / candidatos.length,
  };
};

O detalhe do conjunto de itens já vistos importa mais do que parece. Sem ele, um item de risco alto que também é raro aparece duas vezes na fila, o revisor lê o mesmo caso duas vezes e conclui, com razão, que a ferramenta é descuidada. Uma fila de revisão perde a confiança do time por esse tipo de detalhe muito antes de perder por má escolha de sinal.

Revisão humana só se paga se o resultado alimentar alguma coisa. O padrão que não se paga é o revisor escrever um comentário livre num campo de texto e marcar o item como visto: isso produz conhecimento que mora na cabeça de quem revisou e num campo que ninguém consulta. O padrão que se paga transforma cada revisão em um registro estruturado que serve como caso de avaliação, evidência para ajuste de prompt ou entrada num relatório de qualidade.

• Veredito em categoria fechada, não em texto livre: correto, incorreto por informação errada, incorreto por informação faltando, correto mas em tom inadequado, recusa indevida, ação indevida por ferramenta.
• A resposta que deveria ter sido dada, escrita pelo revisor quando o veredito é negativo, porque é isso que transforma o caso em item de conjunto de avaliação sem trabalho adicional depois.
• A causa provável apontada entre opções conhecidas: contexto não recuperado, contexto recuperado mas ignorado, instrução ambígua no prompt, ferramenta devolveu dado errado, política mudou e o prompt não.
• Referência estável para a conversa e para a versão do prompt e do modelo vigentes naquele momento, sem a qual a análise agregada por versão é impossível.
• Tempo gasto na revisão, que é o dado que permite recalibrar a capacidade diária quando o perfil dos casos muda.

O segundo item é o de maior retorno e o mais negligenciado. Pedir ao revisor que escreva a resposta correta parece aumentar o custo da revisão, e aumenta mesmo, em talvez um minuto por caso negativo. Em troca, cada caso negativo revisado vira automaticamente um item de conjunto de avaliação com entrada e saída esperada, que é exatamente o insumo mais caro de produzir de qualquer outra forma. Sem isso, alguém vai precisar reconstruir esses casos depois, com menos contexto e mais esforço.

// Registro estruturado da revisao. O formato e o que permite reaproveitar
// o trabalho humano como caso de eval sem uma segunda passada.

export const registrarRevisao = async (repo, { item, revisor, veredito }) => {
  const registro = {
    conversaId: item.conversaId,
    respostaId: item.id,
    fatiaDaFila: item.fatia,
    sinais: item.sinais,
    // Versoes vigentes: sem elas nao da para dizer se a regressao veio
    // do prompt novo, do modelo novo ou da base de conhecimento nova.
    promptVersao: item.promptVersao,
    modelo: item.modelo,
    veredito: veredito.categoria,
    respostaEsperada: veredito.respostaEsperada ?? null,
    causaProvavel: veredito.causaProvavel ?? null,
    revisor,
    duracaoSegundos: veredito.duracaoSegundos,
  };

  await repo.salvarRevisao(registro);

  // Caso negativo com resposta esperada preenchida ja nasce como item
  // candidato do conjunto de avaliacao, marcado para curadoria.
  const negativo = veredito.categoria !== 'correto';
  if (negativo && veredito.respostaEsperada) {
    await repo.proporCasoDeEval({
      entrada: item.perguntaCliente,
      contexto: item.contextoRecuperado,
      saidaEsperada: veredito.respostaEsperada,
      origem: 'revisao-humana',
      revisaoId: registro.respostaId,
      // Nunca entra direto no eval: um caso mal escrito envenena a regua
      // por meses, entao passa por curadoria antes de valer nota.
      estado: 'aguardando-curadoria',
    });
  }

  return registro;
};

O estado de espera por curadoria não é burocracia. Um caso de avaliação escrito às pressas por um revisor cansado, com uma resposta esperada que reflete a opinião dele e não a política da empresa, vai valer nota por meses e empurrar o sistema na direção errada. A revisão humana propõe, a curadoria decide, e esse par de etapas custa pouco perto do estrago que um conjunto de avaliação contaminado provoca.

Uma fila de revisão pode consumir duas pessoas em tempo integral e não produzir nada, e o time só descobre isso quando alguém pergunta o que mudou por causa dela. As métricas de uma fila não são sobre quantidade revisada, que é apenas medida de esforço. Elas são sobre densidade de achado e sobre efeito, e as duas precisam aparecer no mesmo painel.

A elevação sobre a aleatória é a métrica que justifica toda a máquina, e ela merece cuidado na leitura. Se a fatia de risco alto tem densidade de erro de trinta por cento e a aleatória tem cinco, a elevação é seis: cada hora do revisor rende seis vezes mais achados do que renderia sem priorização. Se a elevação for próxima de um, toda a pontuação, os pesos e o código de fila estão sendo executados para produzir o mesmo resultado que um sorteio, e a resposta honesta é simplificar em vez de adicionar mais um sinal.

A concordância entre revisores é a métrica que quase ninguém coleta e que explica boa parte das discussões improdutivas sobre qualidade. Colocar dez itens por semana na fila de duas pessoas ao mesmo tempo custa dez itens de capacidade e revela se o critério é compartilhado. Quando a concordância é baixa, o problema não está no agente nem no revisor: está numa definição de "resposta correta" que ninguém escreveu, e nenhuma métrica de qualidade construída sobre esse chão significa coisa alguma.