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-by-
tick, 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 100.000 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 1999. 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 2007. 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 2007. Uma série iniciada em 2007 só
contém uma crise relevante, que foi a de 2008. 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?
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.
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
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.
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):
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 72.4 73.3
Lucro anual médio 103.52% 102.18%
Proporção de Lucro 108.85 104.21
Fator de Lucro 2.35 2.13
Trades 478 484
Máximo drawdown -19.30% -37.80%
Porcentagem lucrativas 60.88% 40.50%
Semestres negativos 0 2
Semestres abaixo 5% 2 2
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 86.4 86.2
Lucro anual médio 59.23% 63.74%
Proporção de Lucro 21.55 25.91
Fator de Lucro 2.03 2.25
Trades 570 569
Máximo drawdown -10.01% -9.78%
Porcentagem lucrativas 63.51% 63.09%
Semestres negativos 0 0
Semestres abaixo 5% 1 0
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 191.5 185.6
Lucro anual médio 129.60% 162.37%
Proporção de Lucro 241.20 581.88
Fator de Lucro 1.56 1.65
Trades 1264 1225
Máximo drawdown -24.32% -30.06%
Porcentagem lucrativas 59.73% 60.57%
Semestres negativos 0 0
Semestres abaixo 5% 1 1