Dados da Kalshi: construa um conjunto histórico honesto

Defina a pergunta de investigação antes de descarregar

Suponha que um analista quer estudar se uma previsão publicada antes do anúncio de um indicador melhorou decisões em mercados relacionados. Essa pergunta exige a previsão disponível na altura, a definição relevante do contrato, uma cotação executável contemporânea e um rótulo final determinado segundo as regras do contrato. Um conjunto de preços de fecho e valores finais do indicador não basta.

Escreva a decisão pretendida numa frase: num momento de observação definido, compare o custo de aquisição de um contrato elegível com uma estimativa datada e registe depois se uma posição proposta satisfaria uma regra declarada. Esta descrição esclarece que campos são essenciais e quais são apenas convenientes. Também torna visíveis provas em falta antes de o projeto produzir gráficos de desempenho atrativos.

Especifique previamente a população de investigação. A população pode incluir todos os contratos de eventos recorrentes selecionados durante um período fixo, incluindo contratos sem negócios, com dados em falta ou com regras excluídas. Conservar estes casos sustenta um denominador de cobertura significativo. Um conjunto de dados que contenha apenas os mercados em que uma estratégia imaginada negociou não pode revelar com que frequência a estratégia não tinha informação utilizável.

O guia anterior de análise de mercados de previsão separa interpretação de contratos, previsão e execução. Use essa separação no arquivo. Cada pergunta de investigação deve identificar que camada avalia; caso contrário, uma melhoria na classificação dos resultados finais pode ser apresentada erradamente como prova de desempenho de negociação executável.

A cobertura histórica dos dados da Kalshi precisa de um limite explícito

A documentação da Kalshi sobre dados históricos descreve níveis separados de dados atuais e históricos, com limites que dependem do tipo de registo. Um processo completo de recolha deve inspecionar os limites relevantes e consultar as fontes adequadas. Não encontrar um registo antigo num endpoint de dados atuais não prova que o mercado nunca existiu ou não teve atividade.

Guarde o momento da recolha, os parâmetros de consulta, o progresso da paginação e o contexto observado do limite. Estes pormenores explicam por que um arquivo contém determinados registos. Se o limite avançar durante uma recolha longa, pedidos sobrepostos e eliminação de duplicados por identidade podem ajudar a estabelecer cobertura sem dupla contagem. A implementação exata deve seguir os endpoints atualmente documentados e o comportamento de consulta que suportam.

Considere um projeto fictício que pede 100 eventos diários. O coletor obtém registos completos para 92, parciais para cinco e nenhuns para três. Comunique esses grupos separadamente. Chamar ao conjunto de dados um teste retrospetivo de 100 eventos esconde o facto de algumas observações não poderem sustentar a decisão planeada. Chamar-lhe um estudo de 92 eventos sem conservar as exclusões dificulta inspecionar o processo de seleção.

A cobertura é multidimensional. Um evento pode ter um resultado final, mas não profundidade contemporânea. Outro pode ter cotações, mas não uma versão guardada das regras. Um terceiro pode ter um histórico público completo sem um histórico de execuções da conta. Acompanhe que afirmações de investigação cada evento pode sustentar, em vez de atribuir um único indicador indiferenciado de completo a todo o registo.

Preserve vários momentos sem inventar precisão

Uma observação histórica pode ter uma hora do evento, uma hora de publicação da fonte, uma hora de receção pelo coletor e uma hora de processamento. Um valor económico pode descrever atividade de agosto, ser publicado em setembro e ser corrigido depois. O período de referência de agosto não é o momento em que um negociador de setembro podia ter conhecido o valor. Usá-lo como momento de disponibilidade introduz imediatamente informação futura.

Numa sequência fictícia, uma previsão é publicada às 08:29:50, recebida às 08:29:52 e incorporada numa decisão às 08:29:54. O anúncio oficial segue-se às 08:30:00. Essa previsão pode plausivelmente informar a decisão das 08:29:54. Uma correção recebida às 08:31:10 não pode, mesmo que tenha a mesma data de previsão ou se refira ao mesmo período do indicador subjacente.

Escolha uma regra de disponibilidade que corresponda ao sistema pretendido. Se a investigação avaliar o fluxo de trabalho efetivo do coletor, a hora de receção pode ser o limite adequado. Se estudar a disponibilidade pública teórica, a hora da fonte pode ser relevante, mas exige provas sobre a publicação. As duas perguntas são legítimas e diferentes; nenhuma deve aproveitar o momento favorável da outra sem o divulgar.

Evite falsa precisão. Uma data de fonte sem hora não estabelece disponibilidade à meia-noite. Um carimbo temporal arredondado ao minuto não prova que um registo precedeu outra observação dentro desse minuto. Preserve a resolução conhecida e aplique uma regra conservadora de elegibilidade quando a ambiguidade puder alterar a decisão.

O histórico de revisões dos dados da Kalshi deve ser aditivo

Guarde uma nova versão quando uma observação muda. Registe o que mudou, quando a substituição ficou disponível e que registo anterior substitui. Isto preserva um relato fiel das decisões anteriores, permitindo que análises posteriores usem informação corrigida nas perguntas que a exigem. Sobrescrever o valor antigo destrói a distinção.

Imagine um indicador hipotético inicialmente comunicado como 51,8 e depois revisto para 52,2. Um contrato resolvido pela divulgação inicial pode ter um resultado diferente de outro resolvido pela revisão posterior. Mesmo quando só o primeiro contrato está em estudo, um modelo de previsão pode incorporar informação futura se os seus dados históricos usarem silenciosamente 52,2 numa decisão tomada antes da revisão.

Existem, portanto, dois problemas de revisão: que versão determina o pagamento do contrato e que versão o investigador podia observar ao prever. Resolva-os separadamente. Um rótulo final de liquidação pode usar corretamente a primeira divulgação enquanto outra variável de entrada ainda contém conhecimento posterior. Rótulos corretos não tornam automaticamente todas as variáveis explicativas historicamente válidas.

Mantenha legível a linhagem de versões. Um revisor deve conseguir obter o registo disponível no momento da decisão e o registo final corrigido sem adivinhar que ficheiro foi renomeado. O guia relacionado de ferramentas de negociação da Polymarket é útil ao avaliar software que importa provas externas: uma interface aperfeiçoada não deve esconder se preserva esta distinção histórica.

Construa uma junção segundo o que era conhecido

Uma junção segundo o que era conhecido escolhe apenas registos disponíveis até ao limite temporal da decisão. Também faz corresponder o contrato, o evento e a definição da fonte corretos. Uma junção pelo momento mais próximo pode estar errada se selecionar uma observação posterior por esta estar mais perto. A condição temporal deve ser explícita antes de se aplicar qualquer regra de correspondência baseada em distância.

Suponha que uma decisão ocorre às 08:29:55. Uma cotação recebida às 08:29:54 é elegível segundo uma política de hora de receção; outra recebida às 08:29:56 não é. Se a cotação anterior for demasiado antiga segundo a política de investigação, o resultado certo pode ser não haver cotação utilizável. Usar a observação posterior completa uma linha à custa de um pressuposto histórico impossível.

Use o mesmo princípio para metadados. A descrição atual do contrato pode incluir um esclarecimento ausente no momento da decisão. Preserve a versão anterior para reconstruir o que o analista compreendia e conserve o esclarecimento para a interpretação final. Um relatório de investigação deve reconhecer quando condições posteriores explicam uma discrepância, em vez de fingir que essas condições estiveram sempre presentes.

O artigo anterior de negociação algorítmica em mercados de previsão desenvolve a reprodutibilidade como disciplina de operação. Uma junção segundo o que era conhecido é uma aplicação concreta: o conjunto de entradas de uma decisão histórica deve poder ser recuperado a partir de uma regra datada, não dos registos que estejam atuais quando o teste retrospetivo for repetido.

Separe rótulos de resultado de variáveis de entrada

A informação final de liquidação pertence à camada de avaliação. Não deve entrar nos dados de decisão do modelo apenas porque é conveniente conservar todos os campos do evento num só registo. Campos como estado final, hora de liquidação ou resumo posterior ao evento podem revelar a resposta direta ou indiretamente. Mesmo um filtro que selecione apenas mercados liquidados rapidamente pode criar uma população histórica enviesada.

Defina o rótulo em termos do pagamento efetivo do contrato, incluindo o tratamento excecional documentado. Uma pergunta com aparência binária não deve ser forçada a um rótulo de um ou zero se as suas condições sustentarem outro resultado. O arquivo deve preservar a determinação formal e o montante correspondente, em vez de inferir ambos de um título noticioso.

Mantenha os rótulos indisponíveis para a reprodução da decisão até esta gerar a sua previsão e ação proposta. Esta separação facilita detetar a entrada acidental de informação futura. Um revisor pode inspecionar o registo de entradas congelado e perguntar se algum campo depende de informação ocorrida depois do limite temporal da decisão.

Um teste negativo útil acrescenta deliberadamente um campo apenas futuro a uma cópia de desenvolvimento e verifica se o fluxo o rejeita ou expõe o seu momento de disponibilidade proibido. O objetivo não é provar que um modelo consegue prever com a resposta fornecida. É verificar que o processo de investigação consegue reconhecer e bloquear essa experiência inválida.

Não transforme velas em execuções garantidas

Barras de preços agregadas resumem atividade durante um intervalo. Não preservam necessariamente a sequência, a quantidade ou o estado da fila necessários para reconstruir uma ordem específica. O preço mínimo de um intervalo pode ter ocorrido depois da hora de compra proposta ou para uma quantidade demasiado pequena para sustentar a posição pressuposta. Um teste retrospetivo não pode tratar toda a barra como simultaneamente disponível.

Por exemplo, um minuto fictício contém negócios a 0,42 $ e a 0,58 $. Um modelo avaliado no início desse minuto não pode simplesmente comprar a 0,42 $ porque esse valor se tornou depois o mínimo registado. Se a primeira oferta de venda disponível era de 0,55 $, o custo modelado deve refletir essa observação ou uma aproximação conservadora explicitamente indicada. O mínimo atrativo é conhecimento histórico posterior.

A simulação de ordens limitadas tem um problema relacionado. Um negócio ao preço da ordem não estabelece que a ordem simulada teria recebido prioridade. Indique o modelo de execução e teste a sensibilidade a execução atrasada, parcial ou ausente. Uma estratégia cuja vantagem aparente desaparece com execuções modestamente menos favoráveis exige uma conclusão diferente de outra que permanece robusta.

A discussão anterior de estratégias de negociação de contratos de eventos compara métodos com modos de falha diferentes. Os conjuntos de dados históricos devem preservar as provas relevantes para o método escolhido. Um estudo direcional de liquidação e uma estratégia de liquidez de curta duração não devem ser avaliados com pressupostos grosseiros de execução idênticos apenas porque partilham um rótulo de resultado.

Conserve exclusões e abstenções

Um processo de decisão pode recusar atuar porque uma cotação está desatualizada, uma regra é ambígua ou o modelo não tem provas suficientes. Guarde essa decisão e a sua razão. Estes registos ajudam a distinguir uma estratégia seletiva de um conjunto de dados que simplesmente perde casos inconvenientes. Também quantificam quanto trabalho operacional é necessário para obter uma oportunidade utilizável.

Suponha que 100 janelas fictícias de observação produzem 60 decisões elegíveis, 25 exclusões por dados desatualizados e 15 exclusões relacionadas com regras. Comunicar o desempenho apenas das 60 decisões é adequado se a regra de seleção tiver sido definida previamente, mas as outras 40 continuam a pertencer à contabilidade da cobertura do estudo. Afetam a viabilidade e podem revelar fraquezas sistemáticas em torno de anúncios importantes.

Avalie se as exclusões se concentram. Se faltarem dados sobretudo durante movimentos rápidos do mercado, o desempenho nos períodos calmos restantes pode não generalizar para o ambiente de negociação pretendido. A ausência de dados pode estar relacionada com o resultado ou com a dificuldade de execução. Uma simples declaração de que foram removidas linhas incompletas não resolve esse problema.

A abstenção deve continuar distinta de uma previsão negativa. Um modelo incapaz de interpretar um contrato não previu que Sim irá perder. Combinar essas categorias pode fazer a calibração parecer melhor ou pior por razões sem relação com a capacidade de previsão. Preserve a razão analítica do silêncio, em vez de codificar toda a ação ausente como zero.

O enviesamento por informação futura também entra na seleção dos dados da Kalshi

Escolher mercados bem-sucedidos depois de analisar os resultados é uma forma óbvia de fuga de informação, mas escolhas mais subtis podem ter o mesmo efeito. Selecionar um horizonte temporal, um pressuposto de comissões ou um limiar do modelo depois de examinar os resultados finais do teste transforma esses resultados em informação de desenvolvimento. O arquivo histórico não pode proteger um estudo de escolhas feitas fora do fluxo de dados.

Use um período de desenvolvimento para escolher o método e congele depois as decisões relevantes antes de avaliar um período posterior. Registe alterações seguintes como novas versões e avalie-as em provas efetivamente posteriores quando possível. Uma separação cronológica ajuda a alinhar a investigação com a tarefa real de atuar antes dos resultados futuros, embora não elimine todas as dependências entre eventos relacionados.

Mantenha juntos os contratos relacionados ao avaliar a incerteza. Vários limiares do mesmo anúncio partilham informação substancial e podem ser resolvidos a partir de um único número subjacente. Tratá-los como observações independentes pode exagerar a dimensão efetiva da amostra. Cem linhas de contratos derivadas de dez anúncios não fornecem necessariamente cem testes independentes de capacidade.

O artigo relacionado sobre algoritmos de negociação da Polymarket explora a comparação entre regras de decisão. A sua relevância aqui é metodológica: o arquivo deve apoiar comparações justas sob o mesmo histórico elegível, em vez de deixar cada candidato herdar um subconjunto favorável diferente de eventos ou um modelo de execução diferente informado pelo conhecimento posterior.

Verifique a aritmética com um pequeno exemplo congelado

Antes de executar um grande estudo, crie um conjunto fictício de dez decisões que uma pessoa possa calcular independentemente. Suponha que cada decisão compra uma unidade padrão de Sim de um dólar a 0,55 $ e incorre em 0,02 $ de encargos totais modelados. O custo total é de 5,70 $. Se seis posições ganharem e quatro perderem, o pagamento total é de 6 $ e o resultado líquido de 0,30 $, segundo esses pressupostos declarados.

Esse resultado representa uma taxa de vitórias realizada de 60% e aproximadamente 5,26% sobre o desembolso de 5,70 $. Não é prova de um retorno estável de 5,26% em todos os períodos futuros. Se apenas cinco posições ganharem, o mesmo custo produz uma perda de 0,70 $. O exemplo verifica se o fluxo separa contagem de resultados, resultado em dinheiro e denominador percentual.

Altere agora um preço de aquisição para 0,65 $, mantendo tudo o resto fixo. O custo total aumenta 0,10 $, para 5,80 $, e o resultado com seis vitórias cai para 0,20 $. Um programa que deixe o lucro inalterado pode estar a usar a exatidão dos resultados como substituto da contabilidade de caixa. Um programa que altere a contagem de vitórias confundiu preço com resultado.

Estes pequenos testes são úteis porque todos os pressupostos são visíveis. Não validam desempenho real nem substituem uma revisão completa do conjunto de dados. Estabelecem que os mecanismos da investigação preservam o cálculo pretendido antes de um grande arquivo tornar o mesmo erro mais difícil de detetar.

Mantenha um registo de correções que altere as conclusões certas

Uma correção do conjunto de dados deve identificar que resultados dependem do registo alterado. Suponha que um negócio duplicado exagerou o volume numa janela de observação, mas não afetou a melhor oferta de venda guardada nem o pagamento final. A variável de volume e qualquer decisão de elegibilidade nela baseada precisam de revisão. Reescrever todos os resultados sem relação esconderia o âmbito da correção, em vez de melhorar a exatidão.

Registe o resultado original, o corrigido e a razão da diferença. Se a correção mudar que eventos se qualificam, repita os cálculos relevantes da população e do desempenho. Se mudar apenas um rótulo de apresentação, explique esse efeito mais restrito. Esta abordagem atenta às dependências ajuda um revisor a distinguir uma conclusão de investigação que sobreviveu à correção de outra que simplesmente ainda não foi recalculada.

Um registo de correções também desencoraja a manutenção seletiva. Erros que melhoram o desempenho aparente merecem a mesma atenção que erros que o reduzem. Preserve experiências falhadas e resultados corrigidos desfavoráveis juntamente com os bem-sucedidos. O arquivo documenta então o que o processo de investigação aprendeu, incluindo o custo dos seus próprios erros, em vez de se tornar um histórico selecionado em que todas as alterações parecem confirmar a tese original.

Disponibilize o conjunto de dados com as suas limitações

Uma publicação de investigação deve identificar o período coberto, a regra da população, as fontes de dados, as lacunas de recolha, a política de revisões, a convenção de preços, os pressupostos de execução e a definição dos rótulos. Deve também identificar que perguntas o arquivo não consegue responder. Um conjunto de dados com apenas cotações periódicas pode apoiar uma análise geral de previsões, mas não ter os pormenores necessários para afirmar resultados de execução sensíveis à fila.

Guarde um registo compacto de decisão juntamente com os resultados agregados. Para qualquer linha selecionada como amostra, um revisor deve poder reconstruir os dados disponíveis, a previsão, a decisão de elegibilidade, a quantidade proposta e o resultado posterior. A exatidão agregada ou o lucro são muito mais credíveis quando se podem seguir exemplos individuais sem reconstruir todo o projeto de memória.

O guia do terminal de negociação da Polymarket oferece uma ligação útil às operações diárias: a interface usada para tomar uma decisão deve deixar registos que a investigação histórica possa interpretar mais tarde. Uma melhor conceção do arquivo começa frequentemente antes do negócio, quando o sistema ainda pode preservar exatamente o que o operador viu e autorizou.

Os dados da Kalshi apoiam aprendizagem honesta quando a verdade final e o conhecimento histórico permanecem distinguíveis. Preserve ambos, documente as lacunas entre eles e faça cada decisão simulada respeitar o seu limite temporal de informação. Essa estrutura permite que um resultado dececionante ensine algo útil e impede que um resultado impressionante assente em provas que a estratégia nunca poderia ter possuído.