Quais dados são necessários para avaliar algoritmos de execução?

Algoritmos de execução são métodos de decisão e ordenação que controlam como os pedidos são criados e divididos em ações menores ao longo do tempo. Para avaliá-los, você precisa de dados que descrevam (1) a intenção e as regras do algoritmo, (2) os pedidos que ele envia e quando, e (3) os resultados observados após custos de transação realistas.

Use uma lista de verificação estruturada de entradas, procedência, atualidade e verificações de qualidade:

Especificações de entrada do algoritmo: o objetivo de execução (por exemplo, minimizar o impacto de mercado vs. cumprir uma meta de timing), regras do ciclo de vida do pedido (quando colocar, cancelar, substituir) e quaisquer restrições (limites de participação, tamanho máximo de pedido ou horários de negociação).
Dados de pedidos e execução: carimbos de data/hora, IDs de pedidos, lado (compra/venda), tipo de pedido, tamanho, lógica de preço usada, cancelamentos e preenchimentos parciais.
Dados de contexto de mercado (ou um substituto documentado): cotações de referência usadas pelo algoritmo, medidas de liquidez se disponíveis e qualquer mapeamento de dados de mercado para decisões.
Dados de custos: spreads/taxas/comissões e quaisquer custos adicionais que afetem a qualidade de execução “líquida”.
Procedência e atualidade: de onde veio cada conjunto de dados, como foi capturado, abordagem de sincronização de relógio e se os dados estão alinhados às mesmas janelas de tempo.
Verificações de qualidade: completude dos logs, consistência dos identificadores, taxas de dados ausentes e se os dados registrados correspondem à versão do algoritmo que os produziu.

Como os dados funcionam na prática?

A avaliação geralmente envolve comparar o que o algoritmo fez com o que seria viável sob as mesmas restrições. Isso exige separar a mecânica estável das condições variáveis.

Comece com a mecânica estável Colete as regras definidas do algoritmo: como ele divide os pedidos, como responde a preenchimentos e rejeições e quais gatilhos usa. Se houver valores de parâmetros (limiares, pesos ou limites), registre-os juntamente com a versão exata do algoritmo.
Adicione o rastro de pedidos executados Construa uma tabela de eventos em nível de pedido a partir dos logs de execução: horário de colocação, horários de cancelamento/substituição, relatórios de preenchimento (incluindo preenchimentos parciais) e as quantidades finais executadas. Sem esse rastro, você não pode avaliar a sensibilidade à latência ou o comportamento de cancelamento.
Anexe o contexto de mercado usado para as decisões Mesmo que você não use dados de mercado em tempo real em seu estudo, você precisa de uma descrição consistente do ambiente. Por exemplo, se o algoritmo usa cotações de referência ou últimos preços conhecidos, você precisa da mesma série de referência (ou uma proxy documentada) alinhada aos carimbos de data/hora das decisões.
Calcule a qualidade de execução líquida com premissas explícitas Qualquer cálculo deve declarar suas premissas: quais custos estão incluídos, como os spreads são representados (por exemplo, preço médio vs. bid/ask) e como você lida com carimbos de data/hora quando eventos e preços não se alinham exatamente. Relações observadas historicamente não garantem comportamento futuro, portanto, os cálculos devem ser tratados como evidência sobre aquele período.

Exemplo de estrutura de evidência: você agruparia as execuções por condições semelhantes (regime de liquidez ou proxy de volatilidade, se tiver), e então compararia os resultados líquidos e as contagens de falhas (por exemplo, cancelamentos excessivos, taxas de preenchimento ruins). Se você não tiver dados de contexto de mercado, ainda poderá avaliar a consistência interna e a robustez, mas deve evitar alegações que exijam comparabilidade externa.

Quais são as limitações e riscos relevantes?

Várias limitações afetam a confiança com que você pode interpretar os resultados:

Dependências ocultas: algoritmos podem depender de feeds externos, verificações de risco ou comportamentos de corretoras/plataformas não presentes em seu conjunto de dados. Premissas ausentes ou simplificadas podem invalidar a avaliação.
Erros de timing e sincronização: mesmo pequenos desalinhamentos de carimbos de data/hora entre eventos de pedidos e dados de referência de mercado podem distorcer os cálculos de custo e desempenho.
Modelagem de custos incompleta: a execução “bruta” parece melhor do que a execução “líquida” se taxas, comissões ou efeitos de spread forem omitidos. Se as entradas de custo mudarem, as comparações entre períodos se tornam enganosas.
Modos de falha difíceis de prever: algoritmos podem se comportar de forma diferente durante mudanças rápidas de mercado, quando a liquidez diminui, quando pedidos são rejeitados ou quando cancelamentos dominam. Você precisa procurar esses eventos explicitamente nos logs.
Não estacionariedade: relações históricas entre métricas de execução e condições de mercado podem não se manter posteriormente. Os resultados variam com as condições de mercado, custos, mecânica de execução e jurisdição.

Limitação material para planejar: se você não tiver (a) a série de contexto de decisão usada pelo algoritmo ou (b) logs de eventos completos, você não pode separar de forma confiável se resultados ruins vêm das regras do algoritmo ou de entradas ausentes/incorretas.