O filtro que protege a produção é o mesmo que trava a fase de descoberta

Em projeto de IA há um consenso que parece impossível de contestar: mais rigor é sempre melhor. Testar bem, exigir evidência antes de avançar, não aprovar nada sem prova. Concordo com a parte que importa. Rigor é o que separa um sistema em produção de um acidente esperando para acontecer.

Só que o mesmo rigor que salva uma decisão de produção mata a fase de exploração quando chega cedo demais. Um time aplica a régua de "isso está pronto para rodar sozinho" a cada candidato que ainda está em protótipo. Passam meses. Nada nunca passa. E quase sempre a conversa dentro da sala vira falta de competência técnica, quando o que trava é outra coisa: o rigor certo, aplicado à pergunta errada.

Descoberta e implantação não fazem a mesma pergunta

Descoberta pergunta se algo é plausível o bastante para merecer mais investigação. A régua ali privilegia recall: deixar passar tudo que for razoavelmente promissor, mesmo ao custo de perseguir umas pistas que não vão dar em nada.

Implantação pergunta se algo é seguro o bastante para rodar sem supervisão. A régua inverte e privilegia precisão: rejeitar qualquer coisa não comprovada, mesmo ao custo de barrar candidatos que talvez funcionassem bem.

A confusão entre as duas quase sempre segue a mesma direção. O filtro de implantação, calibrado para tolerar pouquíssimo falso-positivo, é posto para responder a pergunta de descoberta. O resultado é previsível: ele rejeita quase tudo. Não porque as ideias sejam ruins, mas porque a régua foi calibrada para outro trabalho.

No meu próprio sistema, o filtro de produção virou o gargalo

O DT Dashboard é onde isso me custou mais caro. A descrição pública dele é curta: "Motor determinístico de day trading: detecção em camadas, paridade backtest↔produção e mineração estatística com controle de falsos positivos. A IA só tria conhecimento — nunca decide o trade." O que importa aqui é que o rigor estatístico está no centro do projeto por decisão minha.

O pipeline de mineração de padrões roda testes de permutação e correção de múltiplas comparações por BH-FDR. São critérios desenhados para uma pergunta específica: o que pode entrar em produção com capital real. Exigem 3.000 observações para validar um candidato, piso de 200 observações por coorte e piso de 30 por célula. Para aquela pergunta, os números estão certos.

Apliquei os mesmos critérios à geração de candidatos, que é fase exploratória. Passaram meses sem um único candidato novo sobreviver ao filtro. E o padrão não tem nada de específico do meu domínio. É o mesmo quando alguém testa variações de prompt, compara configurações de RAG ou avalia o comportamento de um agente: já na primeira triagem, cobra a prova que só faria sentido pedir na hora de liberar o sistema.

A régua da descoberta é outra porque o erro ali custa outra coisa

O diagnóstico não foi que o rigor estava errado. Foi que ele estava na pergunta errada.

Descoberta roda em ambiente controlado: sandbox, conta de teste, revisão humana antes de qualquer coisa seguir adiante. Um falso-positivo ali custa uma investigação extra e algumas horas perdidas, não um incidente. Usar a régua de produção nesse ponto é pagar o preço de um erro que o ambiente já impede.

A forma de testar também embute a régua. Testar uma hipótese escolhida de antemão, o caso confirmatório, paga de 10 a 100 vezes menos penalidade estatística de múltiplas comparações do que varrer uma árvore combinatória inteira à procura do que aparecer. É a mesma matemática respondendo a duas perguntas diferentes: quanto você precisa provar depende de quanto procurou antes de perguntar.

Inverter a régua na outra direção quebra a produção

A recomendação carrega um preço, e ele vai na mesma frase: usar a régua da descoberta numa decisão de produção ganha velocidade de exploração e custa exatamente a proteção que a fase de implantação existe para dar. Recall alto significa deixar passar o que ainda não foi comprovado. O que parecia promissor no teste exploratório entra em produção sem o segundo filtro e falha na primeira condição real que ninguém tinha testado.

Não existe uma régua universalmente mais rigorosa e melhor. Existem duas perguntas, cada uma com a sua, e o erro caro é tratar as duas como se fossem uma só.

Antes de aplicar um filtro, pergunte o que aquela decisão autoriza

O teste cabe em qualquer reunião: essa decisão autoriza algo a rodar sem supervisão, ou autoriza só mais uma rodada de investigação? Se a resposta muda o filtro que você ia usar, os dois já estavam invertidos.

Mudo de ideia se aparecer um time rodando descoberta e implantação com o mesmo filtro, sem travar na exploração e sem deixar passar risco não avaliado para produção. Até agora não vi nenhum.