Diferenças entre back tests, live tests demo e real

 

Um amigo e talvez futuro cotista enviou uma dúvida que pode interessar a muitos. Ele leu o artigo anterior, em que anunciamos os resultados recentes do Saturno V, e enviou a seguinte mensagem:

“Vi que você postou um novo texto e fiquei com uma dúvida. Tem várias versões rodando em contas reais e de teste, né? E qual é a correlação entre o desempenho das versões em backtests, contas de teste e contas reais?”

Por isso decidir dar à questão uma resposta detalhada e dar a ela a forma de artigo:

Não tem versões rodando em contas reais. Foram feitos apenas dois testes em contas reais, em 2008, com a versão 2.6, e ambos resultaram em lucro por mera sorte, porque os brokers (FXDD, HotSpot com MT da ATC nem qualquer outro) não atendem às condições para funcionamento ideal (spread de 1 pip), mas por insistência de duas entre as pessoas que estavam aguardando para fazer testes, e mediante a declaração de que estavam cientes do risco, os testes foram feitos. Apesar do lucro, ambos os testes apresentaram graves disparidades no resultado final, com ganhos muito menores do que o esperado e com quantidade de operações muitíssimo menor. O motivo é que o spread máximo necessário para uso da versão 2.6 e anteriores é 1 pip (spread + commission). Nos dois casos os valores ficavam acima de 1.8 pips. Verificamos diversas possibilidades relacionadas ao desenvolvimento de plataforma própria, para suprimir o Meta Trader do processo e poupar 0,2 pips em cada operação, e tentamos negociar com vários brokers a possibilidade de que a comissão fosse menor, de modo que ao somar tudo, ficasse abaixo de 1 pip. Chegamos a conseguir alguns avanços nas negociações, mas como o próprio spread real do mercado cria algumas dificuldades, oscilando entre 0,5 e 1 na maior parte do tempo em EURUSD e USDJPY, sendo que para usar o MT4 os brokers precisam pagar 0,2 pip à Metaquotes em cada operação realizada (0,1 na abertura da posição e 0,1 no fechamento), mesmo com comissão de 0,2 pips o valor total de spread + commissions ficaria entre 0,9 e 1,4, portanto extremamente difícil de atender ao critério para funcionamento. Soma-se a isso um atraso médio de 1 segundo por operação, que pode fazer muita diferença num sistema de scaping que faz operações muito curtas, como era o Saturno V 2.6. Esse tema já foi abordado em vários outros artigos, e as dificuldades para resolver a parte administrativa disso, que dependia de terceiros, me levaram a mudar a parte técnica, que dependeria quase exclusivamente de mim, portanto eu teria mais controle sobre a situação e sobre o nível de empenho para resolver o problema, ao contrário dos casos em que dependia da boa (ou má) vontade dos funcionários de corretoras, que algumas vezes davam informações incompletas, erradas, superficiais, não retornavam contatos etc. Na ATC ficamos quase uma semana trocando vários e-mails e mais de 5 horas ao telefone, com participação de 4 cotistas nas conversações, para conseguir a solução para algo tão básico como gerar uma senha de somente leitura, para que os interessados pudessem acompanhar as contas de teste, sendo a ATC uma das melhores corretoras. Essas dificuldades imensas para lidar com questões tão elementares me levaram a preferir tentar adaptar a parte técnica às condições tipicamente oferecidas pelas corretoras, em vez de tentar negociar com corretoras as condições necessárias para o sistema pronto nas condições de teste pudesse funcionar em situação real. Assim, quando retornei das reuniões em Porto Alegre e Canoas, tentei mesclar a versão 2.6 do Saturno com as últimas versões do Guinho_2008 e Melao_Tendencia, e assim nasceram as versões 3.0, 3.0b e 3.0c, entre as quais a mais promissora foi a 3.0 e sucessoras. Com a versão 3.0 em diante se pode operar com spreads de 2, 3, 4 pips ou até muito mais (Com USDTRY o spread médio é 18 pips e as operações realizadas até agora nesta divisa foram todas lucrativas nos testes em tempo real). Mesmo com spreads de 4 pips ou mais em EURUSD, os resultados permanecem praticamente iguais, porque as operações são mais longas e, o mais importante, as entradas são em movimentos mais longos (mesmo que as operações sejam curtas, se o movimento é longo, então o spread é quase irrelevante). Quando digo "praticamente iguais" quero dizer que os horários e as cotações em que são executadas as compras e vendas não diferem mais do que 1 segundo ou uma fração de pip em mais de 90% das vezes. A correlação de Pearson ou de Spearman ou tau de Kendall não fornecem uma informação útil para avaliar a similaridade, porque são muito acima de 0,999, pois em intervalos de centenas de pips em que as operações acontecem, o "erro" médio é menor que 1 pip (ou menor que 10 pipetes) entre back teste e tempo real, e presumivelmente menor ainda entre conta real e conta demonstrativa. Se fosse tomar como referência a correlação, a provável conclusão seria de que a similaridade é muito maior do que realmente é. Teria que desenvolver alguma ferramenta própria pra medir a similaridade com base em diferenças (talvez distâncias de Minkowski ou Mahalanobis), e principalmente o resultado global no balanço, no drawdown etc. E para desenvolver essa ferramenta precisaria coletar mais dados, já que a inclusão ou não de alguns parâmetros na ferramenta teriam que ser definidos empiricamente. Tenho feito também alguns "testes alternativos", como por exemplo executar operações com atrasos "forçados" e verificar em que medida isso afeta os resultados. Com atrasos de 12 segundos em todas as operações (sempre 12 segundos, fixos), as diferenças continuam absurdamente pequenas, com correlação de Pearson entre cotações acima de 0,999. E com atrasos de meia hora, em média (só executando operações na abertura do próximo candle de 1 hora, independente de quando for dado o sinal de entrada), a correlação ainda continua acima de 0,99. Uma informação mais útil do que a correlação é a seguinte: entre janeiro de 1999 e dezembro de 2008, o Saturno V 3.1415926c produz os seguintes resultados finais:

Sem atraso (operações hipotéticas ideais, porém impossíveis, portanto melhor que a situação real):
5758,51% e o número de operações muda para 124

Com atraso fixo de 12 segundos em cada operação (absurdamente alto, só ocorreria com graves problemas de conexão, portanto muito pior do que a situação real):
9437,72% e o número de operações muda para 126

Com atraso variável cuja média é de 30 minutos em cada operação:
1496,88% e o número de operações muda para 78


Nota-se que com atraso de 12 segundos a performance aumentou (por sorte) em relação a não ter atraso, a diferença poderia ter sido para menos, isso foi mera flutuação estatística, mas o fato importante é que a variação foi percentualmente muito pequena em todos os casos, e na essência não houve disparidade significativa em nenhum parâmetro relevante, exceto o número de operações realizadas, que cairia substancialmente se houvesse um atraso médio de 30 minutos em cada uma das operações. Obviamente isso é só um caso hipotético extremo, porque na pior das hipóteses poderia ocorrer um ou dois atrasos neste patamar se queimasse a(s) máquina(s) em que os sistemas ficam rodando, ou algo assim. A idéia de testar com atrasos é mostrar que o sistema não é sensível a uma grande variedade de mudanças no cenário, inclusive quedas de conexão. A versão 2.6 simplesmente poderia ser zerada se houvesse um atraso de 30 minutos. Mas a versão 3.0 praticamente não sofre nenhum efeito significativo com estes atrasos. Os testes com atraso mostram também que variações de dezenas de pips não chegam a afetar muito a performance. A queda de performance em cada operação com atraso de 30 minutos é, em média, 0,3, assim, se houver 1 atraso absurdo desses por ano (acho que devem ser mais raros ainda), a performance seria 0,97 da esperada com base nos testes sem atraso. Outra utilidade destes testes é que quando se opera com dinheiro real, cada operação interfere na cotação, sobretudo quando estivermos movimentando volumes grandes. E uma boa maneira de simular isso é com os atrasos, aliás, os atrasos produzem uma situação pior do que ocorreria com a mudança na cotação em função das operações, porque com os atrasos a cotação pode ir a favor ou contra, mas nas operações o preço sempre vai se mover a favor (se você compra, faz o preço subir e vice versa). Então com os atrasos se consegue, de certo modo, uma excelente simulação de uma situação muito ruim, bem pior do que a provável situação real. E se mesmo assim ele funciona, temos um forte indicativo de eficiência.

Sobre os testes em contas reais, temos uma fila aguardando para aplicar, algumas pessoas com 10k, algumas com 100k, algumas com mais de 1M. Nossa conta, na minha com o C., na do E. e outros, nós seremos as primeiras cobaias humanas. O teste já deu certo em ratos e macacos, inclusive gorilas e chimpanzés, além de ter apresentado quase nenhuma diferença entre os testes com ratos e com primatas superiores, e presumivelmente as diferenças devem ser ainda menores ao passar dos testes com gorilas para humanos. Nos casos de back tests em comparação aos testes em contas demo em tempo real, também suponho que a diferença ficará menor ainda entre contas demo e contas reais, ambas em tempo real, pelo menos com valores baixos, mas depois a liquidez infinita das contas demo deve fazer diferença cada vez maior (conforme o volume negociado aumentar) em comparação à liquidez finita do mercado real. Enfim, sempre teremos novos obstáculos, e nem todos os passos serão para a frente. Acho que o importante é que a maioria dos passos seja na direção certa, e que o caminho seja percorrido com dignidade. Cerca de metade dos cotistas se opuseram à publicação deste artigo, devido às possíveis conseqüências negativas que poderia ter. Ainda não foram apurados todos os votos, para decidir se será mantido ou não (na verdade, acho que eu poderia decidir sozinho, mas prefiro que todos opinem). Particularmente acho que precisa haver transparência, além disso, acho que quem leu e entendeu o artigo, percebeu que indica algo positivo sobre a versão atual. Talvez isso se torne mais nítido depois que eu publicar o artigo com os gráficos de todas as versões testadas, com gráficos e resumos de relatórios, mostrando que podem ficar alguns meses negativas, embora fiquem positivas a longo prazo. Além disso, nunca teremos uma versão definitiva, sempre teremos várias versões em teste. Um amigo comentou que isso pode causar a impressão de que ainda não temos uma versão definitiva. A verdade é que nunca teremos uma versão definitiva. Sempre testaremos novas possibilidades de aprimoramento, e as versões que se destacarem nos testes vão progressivamente sendo testadas em condições mais próximas da real, e se elas superarem a melhor versão anterior, podem ser colocadas para operar parte do capital, e com o passar do tempo, quando as versões muito antigas estiverem muito abaixo das mais recentes, aquelas podem ser aposentadas.

Há um provérbio que diz: “siga aquele que vive em busca da verdade, mas se afaste daquele que acredita tê-la encontrado”.

O desenvolvimento de sistemas automáticos deve ser uma busca constante pela melhor solução para modelar o mercado, sendo que sempre teremos algumas versões com melhores resultados do que outras, e é excelente que mais de uma sejam suficientemente boas para ficarem positivas a longo prazo. Um dos resultados mais importantes que obtivemos foi justamente nos testes com atrasos forçados, porque revelam que mesmo em situações extremamente desfavoráveis, muito piores do que a pior situação real, ainda assim o Saturno V 3.1415926c se manteria firme e com excelente desempenho. Mesmo com atrasos de 30 minutos(!) na execução das operações ou com várias dezenas de pips de spread, ele continuaria a funciona quase no mesmo nível. Nenhum outro sistema anterior a ele consegue algo que se aproxime disso. Este foi o separador de águas que nos serviu como sinal de partida para começar testes nas contas reais, com risco muito baixo. Não queremos submeter contas reais a "testes". Queremos usar as contas reais para confirmar a supremacia do Saturno que havia sido amplamente verificada nos back tests e nas contas demonstrativas, e para isso os testes com atraso foram decisivos, pois se ele funciona em 10 anos de simulação em situação pior do que o quadro mais negativo que podemos esperar na situação real, então temos um controle de risco suficientemente rigoroso para atender aos nossos padrões e podemos dar início à próxima etapa, que consistirá em operar contas reais num nível de confiabilidade e segurança que já não pode ser chamado meramente de "teste".