Boas práticas de backfill
Por diversos motivos, pode ser necessário fazer o backfill de dados, seja por erros nos dados, novas informações (como novos recursos) ou reconciliação de dados entre dois sistemas. Quando o backfill ocorrer, siga os princípios deste artigo para manter a qualidade dos dados e a performance do modelo.
Quando o backfill é necessário
Backfill é o processo de preencher retroativamente um conjunto de dados com dados históricos. Alguns cenários comuns:
| Cenário | Descrição | Exemplo |
|---|---|---|
| Novos recursos | Você identificou uma nova métrica importante para o seu modelo e tem os registros históricos brutos para calculá-la. | Você adiciona “taxa de cliques” como recurso e precisa de três meses de histórico para que o modelo tenha dados suficientes para aprender. |
| Recuperação de dados | Seu pipeline de dados falhou em dias específicos, criando lacunas nos dados entregues ao Decisioning Studio Pro. | Uma interrupção do pipeline na terça-feira deixou uma lacuna. Depois que a correção é implementada, você faz o backfill desses registros ausentes a partir do sistema de origem. |
| Mudanças de lógica | Você atualizou a fórmula de cálculo de um recurso ou alterou a definição de um evento. | Você redefiniu “usuário ativo” e precisa reexportar os dados históricos para que o modelo seja treinado com a definição atualizada. |
Requisitos
Para que o Decisioning Studio Pro funcione corretamente, todos os dados recebidos precisam permitir o preenchimento retroativo (backfill) de períodos históricos. A janela de retrospecção necessária (medida em meses) depende dos requisitos de treinamento do modelo de IA. Consulte sua equipe de AI Decisioning Services para confirmar o valor correto para o seu caso de uso.
Ao fazer um backfill histórico, os seguintes padrões são obrigatórios:
- Consistência do processo: Os snapshots históricos de recursos precisam ser gerados com um processo totalmente consistente com a criação dos snapshots em tempo real. Se o seu pipeline em tempo real aplica transformações, agregações ou filtros, essas mesmas etapas precisam ser aplicadas aos dados de backfill.
- Consistência do esquema: O esquema dos dados de backfill precisa corresponder exatamente ao pipeline diário normal, incluindo os mesmos campos, tipos de dados e convenções de nomenclatura de colunas.
Armadilhas comuns
Vazamento de dados (viés de antecipação)
O vazamento de dados é o erro mais crítico no preenchimento retroativo. Ele acontece quando o processo de preenchimento retroativo incorpora, sem querer, informações que não estariam disponíveis no momento em que o registro histórico foi gerado.
Por que isso importa
Se o modelo for treinado com dados que “conhecem o futuro”, ele vai parecer ter uma boa performance durante o treinamento, mas vai produzir resultados ruins em produção. Isso acontece porque as decisões em tempo real não têm acesso a dados futuros.
Por exemplo, imagine calcular um recurso histórico de “valor do tempo de vida” usando o gasto total de um cliente até agora (ou seja, até hoje) e depois usar esse valor para prever um comportamento que aconteceu meses atrás. No momento daquele evento histórico, o valor do tempo de vida completo ainda não era conhecido.
Para evitar isso, reconstrua cada recurso histórico a partir das informações disponíveis naquele registro de data e hora histórico.
Desvio de esquema e de lógica
As estruturas de dados e as definições de negócio mudam com o tempo. Inconsistências entre os dados históricos e os dados em tempo real podem degradar a qualidade do modelo de forma silenciosa.
- Desvio de esquema: Se um campo (por exemplo,
zip_code) foi adicionado ao seu banco de dados recentemente, os registros preenchidos retroativamente de antes dessa mudança vão conter valores nulos nesse campo. Garanta que o seu pipeline lide bem com campos ausentes e que o modelo não dependa demais de campos com pouca cobertura histórica. - Desvio de lógica: Se a definição de uma métrica mudou em um momento específico (por exemplo, “usuário ativo” foi redefinido em 2024), aplicar a nova definição de forma uniforme a dados mais antigos (por exemplo, registros de 2022) pode criar picos ou quedas artificiais que não aconteceram de verdade. Sempre que possível, aplique a definição que estava em vigor no momento de cada registro histórico ou documente claramente o ponto de ruptura para que o modelo possa levar isso em conta.
Registros duplicados de jobs de preenchimento retroativo com falha
Jobs de preenchimento retroativo que falham no meio da execução e são reiniciados podem gerar registros duplicados se o processo não tiver sido projetado para evitar isso. Registros duplicados inflam as métricas artificialmente e introduzem ruído no treinamento do modelo.
A solução: Projete todos os scripts de preenchimento retroativo para serem idempotentes, ou seja, executar o mesmo job duas vezes deve produzir o mesmo resultado que executá-lo uma vez. Use um dos seguintes padrões:
- Upsert (atualizar ou inserir): Usa como chave um ID de transação ou registro de data e hora único. Assim, inserir de novo um registro existente atualiza esse registro em vez de criar uma duplicata.
- Excluir e depois inserir: Exclua os registros existentes do intervalo de tempo de destino antes de inserir. Assim, o conjunto de dados é sempre substituído de forma limpa.