Similaridade entre back tests e operações em tempo real Por Hindemburg Melão Jr.

Transcrição

1 Similaridade entre back tests e operações em tempo real Por Hindemburg Melão Jr. Logo que comecei a desenvolver sistemas automáticos, em outubro de 2006, percebi a necessidade de se usar bases de dados tick-by-tick para que se pudesse realizar testes cujos resultados fossem válidos. Publiquei um artigo discutindo esse fato e analisando os problemas decorrentes de se usar bases de dados minuto a minuto ou com outra granulosidade que não fosse tick-by-tick. Alguns anos depois de meu artigo, praticamente todas as fontes internacionais de informação confiável também passaram a enfatizar a importância do uso de bases de dados tick-by-tick. Contudo, há alguns problemas no uso das bases tick-bytick, um dos quais é que estas bases são geralmente muito mais curtas, cobrindo períodos nos quais ocorre menor variedade de cenários mercadológicos. Outro problema é que a execução de back tests e otimizações nestas bases é muito mais lenta. E outro problema é que estas bases são muito maiores, frequentemente excedendo o limite de 2 Gb, que é o limite do Metatrader. Em muitas fontes diferentes, pode-se encontrar dados históricos GBPUSD desde 1971, mas são dados diários OHLC (OHLC = Open, High, Low, Close). Isto é, só se tem registrada a informação sobre 4 cotações de cada dia: a abertura, o fechamento, o máximo e o mínimo de cada dia. Porém ocorrem mais de ticks por dia, então mais de 99,996% das informações diárias sobre cotação não estão presentes nestas bases de dados, e só tem disponíveis 0,004% para se tentar modelar o Mercado. Não há como fazer modelagens adequadas a partir de uma base de dados tão incompleta. Por um lado, é bom utilizar uma base de dados que cobre um período de 43 anos. Por outro lado, é ruim que estas bases incluam apenas 0,004% do total de informações sobre as cotações a cada dia. Em outras fontes, pode-se encontrar bases de dados OHLC de 1 minuto desde Estas bases são cerca de 1400 vezes mais completas que as bases OHLC diárias, mas ainda são muito menos completas do que seria necessário para uma modelagem de alta qualidade. Numa base de dados de 1 minuto OHLC perde-se entre 90% e 95% das informações diárias, e tenta-se modelar o Mercado com 5% a 10% dos dados. Quando não se dispõe de bases de dados tick-by-tick, estas bases de 1 minuto acabam sendo uma alternativa sofrível e podem fornecer resultados com alguma utilidade, desde que sejam seguidos certos protocolos metodológicos para interpretar os resultados e selecionar os melhores genótipos. Embora estas bases cubram um período de 15 anos, que é 3 vezes menor do que as bases OHLC diárias, elas contém cerca de 6% da informação total de cada dia, portanto são 1400 vezes mais completas do que as bases OHLC diárias. E há uma fonte que fornece bases de dados tick-by-tick de boa qualidade desde Estas bases reúnem quase 100% de todas as cotações, perdendo uma parte ínfima, menor que 0,1% dos dados. Os resultados obtidos com back tests executados nestas bases são virtualmente idênticos aos que seriam obtidos em situação real operando no mesmo broker do qual estes dados foram extraídos. Há outras fontes com dados tick-by-tick desde 1998 (DiskTrading), desde 2000 (Gain Capital) e desde 2005 (Oanda), mas estas frequentemente apresentam erros que os invalidam. A fonte mais segura é a Dukascopy, mas as séries históricas da Dukascopy são relativamente curtas, iniciando em abril de Uma série iniciada em 2007 só contém uma crise relevante, que foi a de Seria desejável ter uma variedade maior de cenários, que incluísse as grandes crises de 1999, 1987, 1973 etc. Embora estas bases da Dukascopy tenham apenas 7 anos, portanto metade do tempo das bases de 1 minuto, elas contém quase 100% da informação diária sobre cotações, portanto 20 vezes mais do que as bases de 1 minuto. Então fica-se num dilema: usar bases de dados de boa qualidade, praticamente idênticos aos dados da situação real, mas que cobrem um período curto, de apenas 7 anos, ou usar bases de dados mais longas, que cobrem várias décadas, porém com qualidade inferior?

2 Desde 2006, a principal solução adotada tem sido usar as bases de ticks, sendo que na época ainda não existiam as bases da Dukascopy, mas era possível combinar bases de dados de ticks de diferentes fontes e assim conseguir identificar e eliminar a maioria dos erros, bem como melhorar a qualidade em todos os trechos da base. A partir de 2009, com a colaboração do amigo Marcelo, começamos a implementar algumas ideias para preenchimento de candles e geração de ticks artificiais, por meio dos quais se tornava possível usar séries históricas de 1 minuto com qualidade comparável às séries tick-by-tick. Rapidamente conseguimos gerar ticks artificiais com qualidade praticamente igual à dos ticks reais, porém com um aspecto negativo: as bases de dados ficavam grandes demais, o que tornava as otimizações lentas e também excedia o limite de 2 Gb que o Meta Trader consegue operar. Então passamos a trabalhar no desenvolvimento de métodos que mantivessem a alta similaridade entre os ticks artificiais e os reais, e ao mesmo tempo deixassem as bases tão pequenas quanto possível. Em 2010 e 2011 conseguimos os primeiros sucessos expressivos neste aspecto, obtendo resultados praticamente idênticos aos dados reais em intervalos de poucos meses. O gráfico a seguir mostra os resultados de back tests (linha vermelha) em comparação aos resultados reais (linha azul) no mesmo período, em teste feito ao longo de 2 meses no final de 2010: A similaridade é notável e os resultados reais se mostraram até um pouco melhores do que os resultados em back tests. Isso ocorreu, em parte, porque usamos spreads um pouco maiores que os reais nos back tests, confirmando que os back tests realizados nestas bases de dados são preditores de performance extremamente eficientes e acurados, capazes de prognosticar os resultados a serem alcançados em situação real com uma diferença muito pequena em comparação aos resultados esperados. Estes resultados foram comemorados com entusiasmo, mas nos anos que se seguiram, verificamos que, apesar da altíssima similaridade em períodos de poucos meses, eventualmente ocorriam operações na situação real que não eram executadas no back test no instante correspondente, ou o contrário (ocorrer operações no back test sem que ocorram na situação real no instante correspondente), provocando uma diferença bastante sensível. Foi constatado que são 4 os principais fatores responsáveis por tais diferenças: 1) Atrasos nas execuções, que não existe nos back tests, mas ocorre na situação real. 2) Penetração no livro de ofertas, que faz com que os preços pagos nos back tests sejam iguais aos das cotações exibidas, mas nas operações reais podem mudar levemente, conforme o volume negociado. 3) Se os dados históricos tick-by-tick usados no back test não forem os mesmos dados usados no broker, isto é, se as séries históricas para o back test forem provenientes de um broker diferente daquele no qual o sistema é usado em situação real, podem ocorrer pequenas diferenças nas cotações, e ainda que estas diferenças ocorram na quarta ou na quinta decimal, isso já pode ser suficiente para que algumas operações não sejam executadas no back test, mas podem ser executadas na situação real, ou o contrário. 4) Alguns brokers abrem 30 ou 60 minutos depois que o Forex já está em atividade no Domingo, e fecham 30 ou 60 minutos antes de o Forex interromper as atividades na Sexta-feira. Se a fonte de dados históricos não tiver o mesmo padrão que o broker sobre horário de início e término das atividades semanais, isso pode gerar diferenças relevantes também.

3 Quando se compara operações durante apenas 2 ou 3 meses, pode ser que nenhuma operação seja realizada justamente nos 30 minutos finais da sexta-feira, e nenhum dos outros 3 itens citados acima cause qualquer problema que possa provocar diferença relevante entre os resultados em back test em comparação aos resultados em situação real. Mas quando se compara operações durante vários meses ou anos, quase inevitavelmente ocorrem algumas situações que se enquadram num destes 4 casos acima, e estas situações acabam produzindo diferenças substanciais, porque embora sejam raras (cerca de 4,3 por ano), os efeitos são bastante marcantes, pois pode acontecer de uma operação que seria positiva no back test acabe sendo negativa na situação real, devido a uma diferença na cotação de um centésimo de milésimo de dólar, mas isso basta para que uma operação seja fechada com lucro no back test, enquanto a mesma operação continue à deriva até ser fechada pelo stop loss na situação real, com prejuízo. Assim, 4,3 operações com esse tipo de diferença já afetam muito os resultados. Por isso, embora as performances sejam mais de 99% semelhantes em mais de 99% do tempo, nos raros casos em que algo sai diferente no back test em relação à situação real, dependendo de qual seja esta diferença, pode afetar bastante o resultado final. Por isso, esta altíssima similaridade observada em curtos períodos de 2 ou 3 meses não se mantinha em períodos mais longos. Esse fato já havia sido observado há mais de 2 anos, mas havia poucos dados para confirmar esta hipótese na época. Para lidar com este problema, além do trabalho constante no aprimoramento do método para geração dos ticks artificiais, também foram feitas melhorias no processo de otimização para agilizar cada etapa e tornar o processo de validação o mais confiável possível. Também foram feitos estudos sobre a similaridade entre os resultados em diferentes brokers, ou num mesmo broker em diferentes contas, usando a mesma versão do Saturno V, mesma configuração em todas as contas e em todos os brokers. E o que pudemos observar foi surpreendente: várias contas num mesmo broker, todas as contas usando mesma versão e mesma configuração do Saturno V, que deveriam produzir resultados quase idênticos, podem se manter similares por alguns meses, mas depois de certo ponto começam a acumular diferenças substanciais. Isso mostra que não se trata de uma limitação nos back tests, mas sim de uma característica inerente à Geometria Fractal das cotações, pois a diferença não se deve ao fato de ser back test ou situação real. A diferença se manifesta em nível similar quando se usa duas ou mais contas reais, num mesmo broker e com exatamente mesmas condições em ambas, ainda assim as performances acabam sendo sensivelmente diferentes. Entre março de 2013 e fevereiro de 2014, duas contas no broker Spedia, ambas usando a mesma versão e mesma configuração do Saturno V, uma das contas acumulou 36% de lucro enquanto a outra acumulou 4,8% de lucro. O broker usou as mesmas cotações, mesmo spread, mesma comissão, mesma swap e todos os demais parâmetros iguais nas duas contas, então seria esperado que os resultados fossem quase idênticos, com pequenas oscilações causadas por atrasos nas execuções ou motivos de liquidez. No entanto, as diferenças foram bastante grandes. Em testes realizados em 2012, comparando 4 brokers: Alpari, FXPro, Spedia e Oanda, em 8 meses as contas na Spedia e Oanda se mostraram quase iguais, com 126% e 121% de lucro, enquanto na Alpari foi 74% e FXPro 83%. Naquela época, essa diferença foi atribuída principalmente aos atrasos na execução da Alpari e ao maior spread da Alpari e FXPro. Porém quando os testes foram realizados dentro de uma mesma corretora, eliminando diferenças de spread e uniformizando a latência nas execuções, os resultados se mantiveram num patamar semelhante de disparidade. Embora estas diferenças sejam casos extremos, e na maioria das vezes as diferenças são bem menores, estes casos exemplificam como variáveis inerentes ao Mercado e aos brokers podem provocar diferenças globais nos resultados tão grandes ou maiores do que quando se compara back tests com situação real. Aliás, as diferenças entre duas contas no mesmo broker em situação real são maiores do que as diferenças entre dois back tests rodados em séries históricas de fontes diferentes, ou as diferenças entre back tests com ticks

4 artificiais em comparação a ticks reais. Isso se deve ao fato de que nos brokers há maior número de fatores propagadores de erros/anomalias, tais como atrasos nas execuções, variações nos spreads, variação na liquidez etc. Nos back tests não há atrasos nas execuções (é possível simular atrasos, caso seja necessário), nem variações nos spreads (pode-se também simular isso), e a liquidez é infinita. Também foi observado que a similaridade depende, em parte, da versão e da configuração do Saturno V. Para configurações que realizam operações mais longas, a similaridade é muito maior do que para versões que realizam operações mais curtas. Este fato já era conhecido e foi apenas corroborado mais uma vez. E mesmo que não fosse conhecido, isso é compreensível e até previsível, pois nas operações mais curtas, qualquer pequena diferença em atraso na execução, valor das cotações, atualização no posicionamento do trailing stop etc. geram disparidades muito mais sensíveis. A informação quantitativa sobre isso ajuda a ter uma ideia do tamanho deste efeito e da proporção que ele varia conforme as operações se tornam mais longas. De modo geral, estes experimentos nos proporcionam uma nova visão sobre o nível de similaridade que podemos almejar e efetivamente alcançar, bem como os procedimentos necessários para manter alta similaridade entre back tests e situação real. Em primeiro lugar, para assegurar maior similaridade, precisamos realizar operações mais longas. Isso pode implicar lucros menores, mas torna as performances mais previsíveis. Em segundo lugar, pudemos formular um novo método para geração de ticks que provavelmente será quase idêntico aos ticks reais, sem gerar bases de dados tão grandes. Em terceiro lugar, sabemos que a qualidade dos back tests já está no mesmo patamar da situação real desde 2007, e nossos resultados em back tests tick-by-tick são tão semelhantes aos resultados reais quanto se compararmos os resultados reais de dois brokers diferentes, ou até mesmo se comparar duas contas diferentes num mesmo broker. Isso porque há um limite de similaridade que pode ser alcançado e, por maiores que sejam os esforços, não se consegue similaridades melhores por esbarrar em limites impostos por propriedades inerentes às cotações. Além disso, conseguimos compreender melhor, inclusive quantitativamente, o motivo de nossas medidas iniciais de similaridade entre back test e situação real em 2010 serem muito maiores do que as medidas posteriores, mesmo os métodos mais recentes sendo cada vez mais eficientes e mais rigorosos. O fato é que em intervalos de poucos meses pode não ocorrer nenhum outlier que agrave a diferença entre back test e situação real, mas em 1 ano ou 2 anos, quase certamente ocorrerão alguns outliers e produzirão uma diferença bastante marcante nos resultados. Por fim, o mais importante é que em períodos suficientemente longos, como algumas décadas, os resultados se mostram estáveis tanto entre backtests de fontes diferentes quanto em back tests de mesma fonte em períodos diferentes, ou em back tests de fontes diferentes e períodos diferentes. Isso também é previsível, já que depois de certo ponto, as disparidades produzidas por outliers tendem a ocorrer simetricamente, de modo que umas acabam compensando as outras e não são cumulativas em períodos longos, embora possam eventualmente se acumular em períodos curtos, porque a quantidade de eventos em períodos curtos é muito pequena. Aqui se aplica novamente o exemplo da moeda: em 4 lançamentos, pode ser que ocorram 4 caras, mas em 100 lançamentos, é muitíssimo improvável que ocorram 100 caras. Isso nos leva à conclusão de que ao comparar resultados em poucos meses, encontra-se uma similaridade irreal, meramente local, que não se conserva em períodos mais longos. Quando a comparação se prolonga por alguns anos, ou mesmo por vários meses, a diferença aumenta substancialmente e atinge um patamar mais realista. Porém quando a comparação se prolonga por décadas (e provavelmente por séculos), a diferença não deve continuar a aumentar, pois a ocorrência de outliers, em vez de agravar a situação, tende a anular progressivamente este efeito, mantendo a diferença aproximadamente no mesmo patamar. Então mesmo que ocorram diferenças punctuais importantes, estas se anulam mutuamente por ocorrerem dos dois lados, e depois de intervalos muito longos as performances acabam se homogeneizando.

5 Há muitas outras constatações interessantes que foram feitas ao investigar os resultados acumulados dos últimos anos. E foi grande o impacto destas constatações no aprimoramento da estratégia, nos métodos de otimização, nos critérios para seleção dos melhores genótipos e na ponderação da importância relativa de cada variável para o resultado dos back tests. No fim das contas, o teste conclusivo acaba sendo nas operações reais, mas este acaba tendo dois problemas principais: é muito lento e não pode ser retestado. Enquanto um back test pode ser executado em 2 minutos de 1986 a 2014, seria necessário 28 anos para fazer o mesmo teste em situação real. Uma diferença brutal. Então surge a questão: é melhor tomar como referência o resultado de apenas um teste durante 4 anos em situação real ou o resultado de milhões de testes num intervalo em 28 anos de back test? E a resposta é: ambos. O teste em situação real ajuda a detectar erros que possam ter sido cometidos nas otimizações, nas validações, na qualidade das bases de dados. Ao ser testado em situação real e ficar claro que os resultados são semelhantes aos dos back tests, então se pode interpretar os resultados nos back tests com praticamente mesma segurança que os resultados em situação real. Feito isso, ganha-se um histórico de referência muito mais longo, ganha-se liberdade de teste e reteste milhões de vezes, modificando os parâmetros várias vezes e verificando como estas alterações influem nos resultados, até encontrar os valores ótimos para cada parâmetro e maximizar a eficiência da estratégia. Nada disso pode ser feito por meio de testes em situação real, mas com back tests isso é feito trivialmente. Os back tests, por sua vez, proporcionam uma visão de longo prazo sobre a eficiência da estratégia, já que 4 anos em situação real não é muito e não proporciona uma visão abrangente sobre uma larga variedade de cenários. A título de curiosidade, seguem os resultados comparativos de back tests usando as 3 melhores configurações para o Saturno V 8.07h, no período de 1/4/2007 a 31/1/2014, usando cotações da Dukascopy com ticks reais e usando cotações da ForexTester com ticks artificiais pelo melhor método atual que podemos produzir (ainda não começarmos a usar o novo método para ticks artificiais citado neste artigo):

6 Dukascopy, Saturno V 8.07h, configuração 01, rodando entre 1/4/2007 e 31/1/2014: Forextester, Saturno V 8.07h, configuração 01, rodando entre 1/4/2007 e 31/1/2014: Podemos observar que em alguns trechos do histórico dos balanços (linha azul), os resultados são muito similares em ambas, mas de repente ocorre um ou mais ouliers que agravam a diferença. O mesmo efeito se pode observar nas outras configurações testadas, sendo maiores as diferenças nos casos das configurações que executam operações mais curtas. Nesta primeira configuração, apesar de os gráficos formarem curvas visivelmente bastante diferentes, as estatísticas de resultados se mostram muito semelhantes: Parâmetro de comparação Dukascopy ForexTexter Trades por ano Lucro anual médio % % Proporção de Lucro Fator de Lucro Trades Máximo drawdown % % Porcentagem lucrativas 60.88% 40.50% Semestres negativos 0 2 Semestres abaixo 5% 2 2

7 Dukascopy, Saturno V 8.07h, configuração 02, rodando entre 1/4/2007 e 31/1/2014: Forextester, Saturno V 8.07h, configuração 02, rodando entre 1/4/2007 e 31/1/2014: Parâmetro de comparação Dukascopy ForexTexter Trades por ano Lucro anual médio 59.23% 63.74% Proporção de Lucro Fator de Lucro Trades Máximo drawdown % -9.78% Porcentagem lucrativas 63.51% 63.09% Semestres negativos 0 0 Semestres abaixo 5% 1 0

8 Dukascopy, Saturno V 8.07h, configuração 03, rodando entre 1/4/2007 e 31/1/2014 Forextester, Saturno V 8.07h, configuração 03, rodando entre 1/4/2007 e 31/1/2014: Parâmetro de comparação Dukascopy ForexTexter Trades por ano Lucro anual médio % % Proporção de Lucro Fator de Lucro Trades Máximo drawdown % % Porcentagem lucrativas 59.73% 60.57% Semestres negativos 0 0 Semestres abaixo 5% 1 1