Direto ao ponto. Seis dias depois de o portfólio subir, a máquina de troca rodou pela primeira vez com dinheiro na linha. O monitor pegou um robô abrindo 10,9 vezes mais operações que o backtest, sem estar perdendo nada. A fila escolheu o substituto por regra e o agente executou a troca inteira sem passo manual meu. Aí veio a conta que ninguém tinha posto no papel: com o robô novo dentro, o pior caso do portfólio subiu de 692,24 para 708,60 dólares e cruzou por 8,60 a linha de 700 que eu declaro desde o capítulo quatro. Aceitei o número, e este capítulo é sobre o porquê.
Em 9 de julho de 2026, seis dias depois de os 61 robôs entrarem no ar, a rotina de reconciliação apontou um robô de tendência no USDCAD abrindo 1,50 operação por dia contra as 0,14 que ele abria no backtest. O lado das operações estava certo. A frequência estava 10,9 vezes acima. Ele não estava perdendo dinheiro, o rebaixamento dele era de 2,70 dólares contra um teto de 63,80, e mesmo assim ele saiu da carteira naquela tarde.
A troca correu sem um passo manual meu, a primeira vez fora de teste. O preço apareceu no fim, quando refiz a conta de risco do conjunto com a mesma régua do deploy: o pior caso do portfólio subiu 16,36 dólares, de 692,24 para 708,60. A minha linha declarada é 700. O número passou dela. Este capítulo é sobre a distância entre ter a fábrica de descartáveis escrita num documento e vê-la rodando, mais o custo que só aparece quando ela roda.
A doutrina estava escrita desde junho
O capítulo quatro fechou a direção do projeto numa frase: robô de setup decai, então eu paro de reotimizar e passo a trocar. Cada robô ganha um teto de rebaixamento tirado do Monte Carlo sobre o período de construção, in-sample, e quando ele fura esse teto sai da carteira e outro entra no lugar. Isso é a fábrica de descartáveis. Em junho ela era uma regra num documento e um resultado de backtest.
Entre a regra escrita e a regra rodando existe uma camada inteira que nenhum documento descreve: uma fila de reposição materializada em arquivo, com 143 robôs reservas separados em 13 células; identificadores estáveis por nome, porque antes o identificador saía da ordem da planilha e a mesma estratégia trocava de número entre gerações, quebrando o histórico dela; e um orquestrador que sugere o substituto, fecha a posição do robô morto, regenera as configurações do terminal e sobe o portfólio novo. Célula, aqui, é o cruzamento de comportamento com par e direção. O robô que saiu era tendência, USDCAD, comprado.
Por que um robô que não estava perdendo saiu da carteira
O disjuntor do capítulo quatro nem chegou perto de disparar nesse robô. Ele tinha queimado 2,70 dólares de um teto de 63,80, quatro por cento do que ele tem direito de perder antes de eu cortar. Quem disparou foi outro eixo, o mais novo dos três: a conferência de execução.
Ela compara o que o robô fez ao vivo com o que ele fez no backtest e olha duas coisas, frequência e lado. O lado estava certo. A frequência estava 10,9 vezes acima.
Um robô que abre onze vezes mais operações que o backtest deixou de ser o robô que a esteira aprovou. E isso importa mesmo sem prejuízo, porque a pergunta do simulado é uma só: o portfólio ao vivo se comporta como o portfólio que eu medi? Esse robô contamina a resposta. Ele paga spread numa cadência que a medição nunca viu, fica exposto em horários que o backtest não tinha e enche a amostra de operações que a régua não conhece.
Divergência grossa assim vem de parâmetro ou de símbolo errado. Mercado não faz isso. Por isso esse eixo corta na hora, sem janela de observação: o que está na frente é bug, e bug não melhora sozinho com mais uma semana de dados.
Os três gatilhos que tiram um robô, e o que ficou de fora de propósito
Todo gatilho de saída aqui faz a mesma pergunta: esse robô saiu do envelope com que ele foi aprovado? São três e eles não se sobrepõem. O primeiro é o rebaixamento acima do teto do Monte Carlo, o disjuntor do capítulo quatro. O segundo é estagnação, tempo demais sem fazer novo topo de capital, medido contra o envelope que o próprio Monte Carlo dá para essa espera. O terceiro é a divergência de execução que acabou de tirar esse robô da carteira.
O segundo eixo merece uma ressalva honesta. Para robô de tendência o envelope de espera é longo, entre 700 e 1.500 dias úteis, porque seca comprida faz parte da natureza de seguir tendência, e o gatilho precisa respeitar isso para não cortar robô são no meio de uma seca perfeitamente normal. Ele existe para o caso patológico, o robô que trava de vez. Como detector rápido serve pouco, e eu prefiro escrever isso a vender um gatilho que quase nunca vai disparar dentro do simulado.
O que ficou de fora foi o gatilho mais tentador de todos: cortar o robô que está ganhando menos que os outros. Por que envelope, e não desempenho recente? Porque desempenho recente já se provou ruído mais de uma vez aqui. No capítulo dois, escolher os melhores robôs pelo passado perdeu para a divisão igual de capital assim que a era virou, e no capítulo quatro o robô que ganhava numa alta de juros perdia na alta de juros seguinte. Um gatilho de desempenho só somaria corte falso a um sistema que já espera cerca de 1,7 corte a cada dois meses. E corte falso custa troca, que tem preço.
Como escolhi o substituto, e por que não escolhi o mais barato
O orquestrador propôs os candidatos da mesma célula do robô morto, tendência no USDCAD comprado, na ordem da fila. A ordem tem um critério só: quem foi cortado por último lá na esteira entra primeiro, porque aguentou mais rodadas de corte antes de cair. Entrou o primeiro apto da lista, com teto de rebaixamento de 147,60 dólares, contra os 63,80 do robô que saiu.
Descartei o lucro recente pelo motivo do bloco anterior. E deixei de lado o candidato de menor teto, que era a saída óbvia para o número caber embaixo dos 700. Por que a ordem da fila, e não o teto mais baixo? Porque escolher o robô pelo número que a régua vai medir é o mesmo mecanismo que infla backtest, descrito por Bailey, Borwein, López de Prado e Zhu (2014): você melhora a métrica sem melhorar o sistema. O portfólio caberia no papel, com o risco real intocado.
O bug que só apareceu no primeiro uso de verdade
Antes de aplicar a troca, o orquestrador roda uma precondição: o candidato tem material para subir, ou seja, o robô já está compilado no disco? A checagem procurava o arquivo pelo nome cru da estratégia. O deploy grava esse arquivo com um prefixo padronizado e com os pontos virando sublinhado. Os dois nomes nunca batiam.
O efeito é pior do que parece. A precondição responderia “sem robô compilado” até para robôs que já operavam ao vivo, e travaria toda troca dessa família. Ela passou por todos os testes que eu tinha escrito, porque nenhum deles chegou a pedir uma substituição de verdade. A função rodava em cenário de mentira. E em cenário de mentira ela acertava.
Consertei casando a convenção do deploy, com o nome cru como reserva. A lição é a mesma do capítulo um. Compilar e rodar não prova estar correto. A ferramenta de troca só mostrou o próprio defeito na primeira vez que a troca valeu dinheiro.
O custo honesto: 16 dólares que ninguém tinha posto no papel
A régua que decide o tamanho do portfólio é a do capítulo oito: o pior caso das posições em aberto, marcado dia a dia sobre o histórico dos robôs, com margem de segurança por cima. É esse número que eu comparo com a minha linha de 700 dólares, e foi ele que cortou o portfólio de 60 para 34 robôs lá atrás.
Refiz a medição com o robô novo dentro, sem tocar em nada na régua. Deu 708,60 dólares, contra 692,24 antes da troca. O substituto carrega mais rebaixamento em aberto do que o robô que ele substituiu, e a diferença de 16,36 empurrou o conjunto para o outro lado da linha.
Essa é a parte que a doutrina não contava. No papel, a fábrica troca uma peça e segue. Na prática cada troca re-sorteia o número de risco do conjunto inteiro, porque o risco do portfólio depende de como as posições abertas de todos os robôs se somam no mesmo instante, e nenhuma regra garante que o substituto some menos que o morto. A troca certa pode sair mais cara que a errada.
Aceitei o número, por três razões. A primeira é que 700 é um limite que eu declaro, e a parede de verdade é o capital que eu reservo para o caso extremo, da ordem de 1.200 dólares. A segunda é que o protocolo do simulado foi pré-registrado antes do deploy e já previa essa faixa: pior caso entre 700 e 900 conta como margem de erro, com acompanhamento de perto, sem corte. O corte fica para o portfólio que virou outro animal. A terceira razão é a que mais pesa. Mudar o critério de escolha depois de ver o número seria ajustar a régua ao resultado, o vício que esta série tenta evitar.
Registrei os 8,60 acima da linha no log de trocas em vez de arredondar para baixo. Escondido, esse número custaria mais caro que ele vale.
O que a doutrina escrita não me contou
Três coisas apareceram só quando a máquina rodou, e nenhuma delas estava no documento. A primeira é qual eixo abriu a temporada. Eu vinha construindo e testando o corte por rebaixamento havia meses, e imaginava que o primeiro robô sairia por ele. Saiu pela conferência de execução, o eixo que existe para pegar erro de configuração.
A segunda é o defeito da própria ferramenta, que nenhum teste tinha exposto. A terceira é o preço. Documento descreve a troca como evento neutro, uma peça sai e outra entra. A régua mostrou que a troca cobra.
Por isso doutrina escrita, por mais testada que esteja, continua sendo uma hipótese sobre o próprio sistema. Rodar com dinheiro na linha, ainda que simulado, é o que vira fato medido. Perold (1988) chamou de custo de implementação a diferença entre a carteira do papel e a carteira executada, e o que apareceu aqui é a versão operacional da mesma coisa.
O que eu ainda não sei
Se o número sobe a cada troca. Uma substituição não faz curva, e a hipótese que me preocupa é a de que ele só suba: se cada robô que entra empurrar o pior caso um pouco para cima, a linha de 700 vira teto móvel, e em algum momento a fábrica precisa devolver risco cortando robô em vez de repor. Vou medir a cada troca e publicar, subindo ou descendo.
Se o ritmo de cortes fica onde a esteira previu. Um corte em seis dias parece rápido contra os 1,7 esperados a cada dois meses, mas é um evento só. A conta que importa é a do fim do simulado.
E se o eixo de estagnação serve para alguma coisa nessa janela. Com envelope entre 700 e 1.500 dias úteis, a chance de disparar em dois meses é pequena.
O próximo capítulo
Poucos dias depois o portfólio teve uma semana ruim, e o check-up que eu fiz para saber se aquilo cabia no previsto terminou em outro lugar. A pergunta que apareceu foi se dez robôs meus segurando posição comprada no mesmo par ao mesmo tempo contam como diversificação. A régua que eu tinha dizia que sim. É o assunto do próximo capítulo.
Acompanhe a série para não perder. O próximo sai em poucos dias.
Perguntas frequentes
Por que trocar um robô que não estava perdendo dinheiro?
Porque o corte foi por fidelidade de execução. Ele abria 1,50 operação por dia contra as 0,14 do backtest, com o lado certo. O rebaixamento dele estava em 2,70 dólares de um teto de 63,80. Divergência desse tamanho vem de parâmetro ou símbolo errado, e um robô nesse ritmo contamina a medição do simulado inteiro.
O que decide qual robô entra no lugar?
A fila de reposição, montada antes do deploy, com 143 robôs reservas em 13 células de comportamento, par e direção. Entra o primeiro apto da mesma célula do robô que saiu, na ordem em que a esteira cortou cada um, porque quem caiu por último aguentou mais rodadas de corte. Lucro recente e teto baixo ficam fora do critério de propósito.
Trocar um robô muda o risco do portfólio?
Muda, e pode mudar para pior. Nesta primeira troca o pior caso das posições em aberto subiu de 692,24 para 708,60 dólares, porque o substituto carrega mais rebaixamento em aberto que o robô substituído. O risco do conjunto depende de como as posições abertas se somam no mesmo instante, então toda troca precisa ser re-medida com a régua do deploy.
Quantas trocas se espera num portfólio desses?
A esteira projetou cerca de 1,7 corte a cada dois meses para este portfólio. O primeiro veio em seis dias. Um evento isolado ainda não vira taxa, então o número que vale é a contagem no fim do simulado, comparada com a projeção feita antes de o portfólio subir.
Referências
- Perold, A. F. (1988). The Implementation Shortfall: Paper Versus Reality. Journal of Portfolio Management, 14(3), 4-9. A distância entre a carteira do papel e a carteira executada, medida como custo.
- Bailey, D. H.; Borwein, J. M.; López de Prado, M.; Zhu, Q. J. (2014). Pseudo-Mathematics and Financial Charlatanism. SSRN 2308659 / Notices of the AMS, 61(5), 458-471. Selecionar pela métrica que julga o sistema infla a métrica.
- López de Prado, M. (2018). Advances in Financial Machine Learning. Wiley. Sobre a lacuna entre backtest e produção.
Presente para Leitores: Robô de Gradiente Linear Gratuito
Estou liberando o acesso ao meu setup pessoal de Gradiente Linear sem custo nenhum. É só clicar e me pedir o arquivo.
Quem escreve: Flávio Araújo
Trader algorítmico há mais de 13 anos, MBA em Mercado de Capitais e Derivativos. Mantém um laboratório próprio que já rodou mais de 20 milhões de backtests e analisou mais de 20 mil estratégias, e opera um portfólio de robôs acompanhado publicamente no blog. LinkedIn · Instagram · YouTube
