A equipa de agentes de IA e o pipeline de pesquisa

Agentes especializados da Stratmill fazem avançar cada estratégia por uma sequência fixa de etapas, com verificações entre elas.

A equipa de agentes

O Responsável de Investigação redige as hipóteses. O Programador de Estratégias converte-as em estratégias NautilusTrader. O Agente de QA revê a correção do código. O Analista de Estratégias interpreta os resultados dos backtests e das otimizações e decide o que fazer a seguir. O Responsável de Risco audita a segurança de uma estratégia antes da promoção. O Gestor de Carteira decide a promoção e a alocação em toda a carteira.

A dar-lhes apoio, o motor de backtesting executa todos os backtests e otimizações com comissões reais; o engenheiro de dados mantém completo o catálogo de dados de mercado; o Refinador da Biblioteca propõe melhorias fundamentadas em citações da Biblioteca de Conhecimento quando uma estratégia é iterada; e o exportador transfere estratégias para outras plataformas.

Fases por ordem

Uma execução passa pelas etapas de programação, verificação, backtesting, análise do backtest, otimização e análise. A partir da análise, pode voltar à programação para iterar, regressar ao Responsável de Investigação para rever a hipótese, ser abandonada ou avançar para a análise de risco, promoção e negociação simulada. As etapas mais avançadas são processadas primeiro, para que a verificação e o backtesting não fiquem sem recursos atrás de uma fila de código novo.

Camadas de verificação

O código é verificado antes de ser aplicado ao histórico completo. Uma nova submissão idêntica à iteração anterior falha de imediato. Uma verificação de consistência confirma que o código negoceia na plataforma e no instrumento declarados na hipótese. A análise estática verifica a estrutura e os métodos obrigatórios, e proíbe o acesso a ficheiros, à rede e ao sistema, bem como formas de consultar dados futuros.

Em seguida, os testes sintéticos executam a estratégia em mercados gerados (tendência ascendente, tendência descendente, lateralização, um pico de volatilidade, volume nulo e um intervalo de preços, além de dados complementares em falta, caso a estratégia os utilize) num ambiente de execução isolado. Um backtest curto em ambiente isolado, com barras reais recentes, tem de executar pelo menos uma transação. Por fim, o Agente de QA compara a lógica com a hipótese: antecipação de informação, direção do sinal, dimensionamento, regras da plataforma e calendários. O QA não avalia o desempenho.

Quando a verificação falha

Uma falha devolve a execução ao programador, com a indicação do problema. Após 3 tentativas falhadas, a execução é abandonada. Se uma regra nunca for acionada ou o programador não conseguir cumprir um requisito, a execução regressa ao Responsável de Investigação para rever a hipótese. As falhas causadas pela própria plataforma são novamente tentadas e nunca são contabilizadas contra a estratégia.

As duas decisões do analista

Após o primeiro backtest, o analista decide otimizar, iterar, rever a hipótese ou abandonar, para que as horas de otimização sejam dedicadas apenas a ideias com um sinal real. Um controlo de viabilidade verifica a decisão com base nos números: uma estratégia com operações suficientes e um retorno médio por operação acima do limite das comissões da plataforma não é abandonada por impulso, e uma estratégia abaixo desse limite não é enviada para otimização.

Após a otimização, o analista decide promover, iterar, rever ou abandonar, com os dados fora da amostra e do conjunto de validação final disponíveis. Todas as decisões são guardadas na página da estratégia, juntamente com a respetiva justificação.

Limites de comissões por plataforma

O analista verifica o limiar mínimo de custos Forex e as evidências de spread, comissão e financiamento registadas para a execução. Uma hipótese sem vantagem líquida suficiente é revista ou rejeitada. A falta de evidências de custos é um impedimento operacional e não pode ser substituída por custos zero.

Revisão do Responsável de Risco

Antes da promoção, o Responsável de Risco audita a segurança da estratégia e tem de a aprovar explicitamente. Aplicam-se também limites impostos pelo código: alavancagem dentro do limite máximo do seu perfil de risco, um controlo de risco definido (um stop que arrisque uma parte limitada do capital próprio por operação ou uma saída por sinal com dimensão de posição limitada), ausência de problemas críticos e uma pontuação de risco aceitável. O Responsável de Risco também pode rejeitar uma dispensa de um critério proposta pelo analista. Uma rejeição devolve a execução ao programador.

Gestor de Carteira e alocação

A fase de Gestão de Carteiras volta a verificar cada critério e limite de risco no código, impede a entrada de estratégias demasiado correlacionadas com as que já estão em execução e decide se a estratégia deve passar à negociação simulada. O capital é alocado por volatilidade inversa, com um limite por estratégia; as novas estratégias começam com pesos iguais e as estratégias em incubação recebem metade do peso. A passagem da negociação simulada para a negociação em tempo real nunca é automática.

Limites de iteração e abandono

Uma estratégia é abandonada quando o seu retorno médio por operação está abaixo dos custos de negociação, quando o seu desempenho fora da amostra falha, quando falha repetidamente a verificação, ou quando o analista não vê caminho para a viabilidade. O motivo é registado e é reencaminhado para o agente de investigação, para que o mesmo beco sem saída não se repita.

Execuções da plataforma e as suas execuções

A plataforma executa a sua própria investigação de forma contínua; o seu espaço de trabalho é executado em paralelo, com capacidade reservada e prioridade mais elevada, pelo que a sua ideia não fica em fila de espera atrás do trabalho da plataforma. Pode pausar, retomar ou parar as suas próprias execuções a qualquer momento a partir da página da estratégia.