Os editores do portal QuantStart escreveram
material sobre o que você deveria saber quando começar a desenvolver seu próprio sistema para testar estratégias de negociação. Examinamos algumas das questões levantadas no artigo anterior no blog e, desta vez, preparamos uma recontagem adaptada de teses sobre quais problemas os desenvolvedores estão enfrentando, qual é a diferença entre os backtests de diferentes tipos e quais são seus prós e contras.
O que é Backtester
Backtest é a aplicação das regras de uma estratégia de negociação a um conjunto de dados históricos sobre os preços dos instrumentos financeiros. A essência da abordagem é que, se desenvolvermos um mecanismo para determinar o momento de entrada e saída de uma posição (compra / venda), por exemplo, ações de um determinado portfólio e aplicar as regras resultantes a dados históricos, isso dará uma idéia da produtividade da estratégia de negociação “no passado "
Alguém disse uma vez que "todos os modelos estão errados, mas alguns são úteis". Essa frase é ótima para backtesting. Os sistemas de teste histórico de estratégias financeiras ajudam a determinar se vale a pena aplicar o conjunto de regras existente à negociação real. Se soubermos como uma estratégia poderia se comportar no passado, ela ajudará a filtrar estratégias ruins sem a necessidade de perdas financeiras reais.
O problema é que o resultado do backtesting não tem nada a ver com os resultados das negociações reais na bolsa. Este é apenas um modelo de realidade. Um modelo que geralmente contém muitas suposições.
Existem dois tipos principais de backtesters - para loop e orientado a eventos.
Ao desenvolver esses sistemas, sempre há a necessidade de um compromisso entre precisão e complexidade da implementação. Esses dois tipos de backtesters representam toda a gama de opções para esse compromisso.
Desafios de backtesting
Testar dados históricos traz muitas dificuldades. Todos eles estão conectados ao fato de que todo o processo é apenas uma simulação da realidade. Aqui estão apenas alguns deles:
- Teste em amostra - surge um problema ao usar os mesmos dados para o treinamento de modelos de negociação e para os testes posteriores. Nesse caso, a produtividade mostrada é significativamente depreciada - porque o resultado é alcançado em um sistema de dados conhecido anteriormente. Na realidade, os dados geralmente diferem significativamente do treinamento. De fato, esta é uma forma de reciclagem.
- Erro do sobrevivente - os índices de ações (por exemplo, S & P500) são caracterizados por um processo de listagem e fechamento de capital quando determinadas ações e instrumentos financeiros aparecem ou são excluídos deles. Se essas alterações não forem levadas em consideração durante o backtesting, uma estratégia que não leve em consideração as ações de empresas que foram excluídas do índice devido à baixa capitalização pode ser considerada bem-sucedida. Para evitar esses problemas, ao executar backtests por longos períodos, é necessário usar dados que não estejam sujeitos ao erro do sobrevivente.
- Erros de previsão (viés de previsão) - dados do futuro também podem afetar o resultado do backtest. Por exemplo, considere o caso em que um índice de regressão linear é calculado em um determinado intervalo de tempo. Se esse indicador for usado na mesma amostra, os dados do futuro entraram nele, o que significa que a produtividade resultante da estratégia é significativamente depreciada. Backtesters orientados a eventos ajudam a resolver esse problema.
- Mudança nas condições de mercado - os parâmetros do mercado financeiro não são estacionários. Isso significa que os processos que resultam em movimentos do preço das ações não dependem de parâmetros constantes ao longo do tempo. Esse fato complica a generalização de modelos parametrizados (muitas estratégias de negociação são casos especiais de tais estratégias), o que leva ao fato de que a eficácia da estratégia em dados históricos é muito melhor do que na negociação real.
- Custos de transação - muitos backtesters cíclicos não levam em conta nem as informações mais básicas sobre custos de transação, como várias taxas e encargos. Freqüentemente, autores de artigos científicos pecam e preferem não se curvar a essas insignificâncias. Encontrar uma estratégia que seja muito lucrativa sob condições ideais e sem custo é muito fácil. O problema é que, ao negociar em condições reais, essas estratégias podem ser profundamente inúteis. É extremamente importante levar em consideração o spread, a situação do mercado, várias taxas, derrapagem (em transações com ativos altamente voláteis, o preço real da transação pode diferir levemente do esperado para a aplicação - tanto na direção favorável quanto na negativa).
Há também outros assuntos que não são discutidos com frequência, mas, no entanto, são extremamente importantes para criar um backtester de qualidade. Entre eles estão:
- Os dados da OHLC são informações sobre o preço de abertura, o preço mais alto de um instrumento financeiro durante o pregão, seu valor mais baixo e o preço de fechamento do período de negociação (gráfico aberto-alto-baixo-fim, OHLC). Geralmente é importado de fontes como o Yahoo Finance. Nesse caso, pode ser uma combinação de diferentes feeds de dados. Isso significa que será difícil obter valores extremos (incluindo preços altos e baixos) para um sistema de negociação em tempo real. Isso também precisa ser levado em consideração no modelo de negociação.
- Limitações capacitivas - O backtesting é tentador para usar uma oferta infinita de dinheiro. Na realidade, a quantidade de fundos disponíveis para negociação é sempre limitada (assim como a quantidade possível de fundos emprestados para negociação de margem). Também é importante não esquecer o limite médio do volume diário negociado (volume médio diário, ADV), especialmente para ações com pouco líquido, quando o risco é alto de que o sistema de negociação leve a uma mudança real no preço. Este efeito de mercado também deve ser considerado.
- Seleção de benchmark - é necessário responder à pergunta se o benchmark está selecionado corretamente com o qual a estratégia testada será comparada. Por exemplo, se você negocia futuros de commodities que são neutros ao índice S & P500, vale a pena usar esse índice como referência? É provável que uma cesta de outros fundos de commodities seja uma escolha mais apropriada.
- Robustez - se você alterar o horário de início da estratégia durante o backtest, quanto isso afeta o resultado? Para estratégias de longo prazo, o horário de início do trabalho não deve afetar seriamente a produtividade - não importa se o backtest foi iniciado na segunda ou quinta-feira. Se for sensível demais às condições iniciais, isso significa que não há como prever sua possível produtividade no início da negociação real.
- Reciclagem e variação - já abordamos os problemas de reciclagem acima, mas esse é um problema mais amplo, inerente a todos os métodos supervisionados de aprendizado de máquina. Esse problema pode ser resolvido apenas com o uso cuidadoso de técnicas de validação cruzada. E mesmo neste caso, deve-se ter muito cuidado ao adaptar estratégias ao ruído nos conjuntos de dados de teste.
- Tolerância psicológica - a psicologia é frequentemente ignorada ao criar sistemas de negociação automatizados, porque sua influência deve ser minimizada por algoritmos. No entanto, as pessoas permanecem humanas, mesmo quando negociam não com as mãos, mas com a ajuda de robôs. Como resultado, isso pode afetar os resultados. Por exemplo, se durante um backtest um levantamento de um depósito de 50% pode parecer um risco aceitável, na realidade a perda de metade do valor dos ativos acaba sendo uma experiência muito mais traumática. Não é fácil resistir a ações não planejadas em tal situação.
Isso é tudo com os problemas dos testes na história, agora passamos à descrição dos próprios sistemas para esses testes.
Dois tipos de testadores traseiros
Primeiro, considere os sistemas cíclicos. Esse é o tipo mais simples de backtester descrito com mais frequência em várias postagens de blog de finanças.
Backtest de loop
Eles funcionam assim - o sistema simplesmente repete cada dia de negociação (ou barra OHLC), faz cálculos relacionados ao preço do ativo desejado (por exemplo, calcula os preços médios de fechamento) e depois executa a operação correspondente (entrando em uma posição longa ou curta). Outras iterações continuam. No processo, as informações sobre o desempenho são armazenadas para criar um gráfico (curva de patrimônio) como resultado.
É assim que o pseudocódigo de um algoritmo é semelhante:
for each trading bar: do_something_with_prices(); buy_sell_or_hold_something(); next_bar();PythonCopy
Como você pode ver, o sistema é extremamente simples, o que torna esses testadores traseiros uma excelente opção para obter as primeiras estimativas sobre as perspectivas do sistema de negociação.
Prós
O backtester cíclico é muito simples de implementar, usando quase qualquer linguagem de programação, e é rápido. Isso é útil quando você deseja testar o efeito de muitos parâmetros diferentes.
Contras
A principal desvantagem são os resultados irreais. Freqüentemente, em backtesters cíclicos, não existe nem uma funcionalidade básica para contabilizar os custos de transação; ela deve ser implementada separadamente. Também comumente usados são apenas pedidos de MERCADO.
Além disso, a possibilidade de reutilizar o código para um sistema produtivo e de teste é mínima, portanto você deve escrevê-lo novamente. Isso aumenta a probabilidade de erros de software.
Os testadores de loopback são propensos a erros de previsão. Eles devem ser usados exclusivamente como uma ferramenta de filtragem para rejeitar estratégias obviamente malsucedidas. Ao mesmo tempo, é importante permanecer extremamente cético em relação às estratégias que mostraram bons resultados. É importante lembrar que, na vida real, as estratégias raramente têm um desempenho melhor do que durante um backtest.
Sistemas Orientados a Eventos
Sistemas desse tipo estão no lado oposto do espectro. Eles estão muito mais próximos da realidade. Geralmente eles trabalham em grandes intervalos, durante os quais os "eventos" são constantemente pesquisados em uma "fila de eventos" especial, incluindo:
- ticks - o surgimento de novos dados de mercado;
- eventos de sinalização - o aparecimento de sinais de negociação;
- evento de pedido - um pedido para concluir uma transação está pronto para ser enviado ao sistema do broker;
- evento de transação - recebimento do intermediário de informações sobre a execução do aplicativo.
Quando um determinado evento é reconhecido, ele é transmitido para o módulo correspondente na infraestrutura do sistema de negociação para processamento adicional e potencialmente gera novos eventos que caem novamente na fila.
O pseudocódigo desse backtester é o seguinte:
while event_queue_isnt_empty(): event = get_latest_event_from_queue(); if event.type == "tick": strategy.calculate_trading_signals(event); else if event.type == "signal": portfolio.handle_signal(event); else if event.type == "order": portfolio.handle_order(event); else if event.type == "fill": portfolio.handle_fill(event) sleep(600);
Como você pode ver, o sistema é extremamente dependente do módulo de processamento de portfólio - este é o verdadeiro coração dos sistemas orientados a eventos.
Prós
Backtesters desse tipo têm muitas vantagens:
- Reduzindo a probabilidade de erros de previsão - devido à estrutura, que assume uma transmissão em fases de mensagens, é menos provável que ocorram erros de previsão em sistemas orientados a eventos, pelo menos no nível de negociação. No entanto, a probabilidade de ocorrência ainda é preservada, pois erros podem estar contidos no próprio modelo.
- Capacidade de reutilizar o código - para usar a estratégia em negociações reais, você só precisa substituir o módulo de processamento de dados e o mecanismo de execução de pedidos. A descrição da estratégia, o módulo de gerenciamento de riscos e gerenciamento de posições, um código para avaliar a produtividade do sistema - tudo isso pode ser usado sem alterações. Isso reduz a probabilidade de novos erros.
- Nível do portfólio - Estratégias orientadas a eventos facilitam a reflexão no nível do portfólio. Por fim, isso torna mais fácil fazer alterações na estratégia e desenvolver métodos de hedge.
- Gerenciamento de riscos “correto” - nesses sistemas, é mais fácil “modular” o gerenciamento de riscos. Um profissional pode usar facilmente técnicas como o critério Kelly e também incluir vários alertas, definir limites (por exemplo, na volatilidade).
- Implantação e monitoramento remotos - o princípio modular de escrever código simplifica sua implantação na nuvem ou de acordo com o esquema de colocação de trocas.
Contras
As vantagens dos sistemas orientados a eventos são compreensíveis, mas existem certas desvantagens. Entre eles estão:
- Código complexo - o desenvolvimento de um sistema totalmente coberto por testes levará semanas e meses de trabalho no modo de tempo integral.
- Orientação a objetos - o design modular do sistema requer uma abordagem orientada a objetos para a programação. Então, precisamos de uma linguagem que apóie esses princípios. O teste de unidade não será mais fácil.
- Limite alto de entrada - um iniciante na programação não poderá criar esse sistema. Será necessária experiência significativa em engenharia, o que tornará possível lidar com a escrita de código, a implementação de logs, a realização de testes de unidade, a implementação de controle de versão e práticas de integração contínua.
- Baixa velocidade - uma abordagem na qual as mensagens no sistema são transmitidas seqüencialmente em seus diferentes níveis, diminui a velocidade de execução dos aplicativos em comparação com a abordagem cíclica vetorizada. Computar várias combinações de parâmetros pode consumir tempo.
Outros materiais relacionados ao mercado financeiro e de ações da ITI Capital :