Feature Store: a divergência entre treino e serviço

Um atributo é calculado duas vezes na vida de um modelo: uma no treinamento, sobre dado histórico e em lote; outra na previsão, sobre dado atual e em tempo real. Se os dois cálculos divergem — e eles divergem, porque em geral são códigos diferentes escritos por pessoas diferentes — o modelo recebe em produção um valor que nunca viu no treino.

O nome disso é divergência entre treino e serviço, e é a causa mais comum de um modelo que passou em todas as avaliações e mesmo assim entrega mal. O sintoma engana: as métricas de treino continuam boas, o endpoint responde sem erro, e a qualidade da previsão simplesmente é pior do que deveria, sem nada apontando para o culpado.

• Uma definição, dois armazenamentos. O atributo é definido em um lugar; o serviço mantém um armazenamento offline para treinar e um online para consultar na previsão.
• O armazenamento offline guarda o histórico completo, com carimbo de tempo, e é o que se usa para montar conjunto de treino.
• O armazenamento online guarda o valor mais recente por chave e responde em baixa latência, que é o que o endpoint consulta.
• A viagem no tempo é o recurso que fecha o laço: montar o conjunto de treino com o valor que o atributo tinha NAQUELE instante, não o valor de hoje.

from sagemaker.feature_store.feature_group import FeatureGroup

fg = FeatureGroup(name="perfil-cliente", sagemaker_session=sess)
fg.load_feature_definitions(data_frame=df)          # infere tipos do DataFrame

fg.create(
    s3_uri="s3://lago/feature-store/",
    record_identifier_name="cliente_id",
    # `event_time` é o que torna a viagem no tempo possível. Sem ele, o
    # armazenamento offline vira uma tabela qualquer e o vazamento temporal volta.
    event_time_feature_name="registrado_em",
    role_arn=ROLE,
    enable_online_store=True,                       # os DOIS armazenamentos
)

fg.ingest(data_frame=df, max_workers=4, wait=True)

# Serviço: valor mais recente, em baixa latência.
atual = featurestore_runtime.get_record(
    FeatureGroupName="perfil-cliente", RecordIdentifierValueAsString="c-4471"
)

# Treino: o valor que o atributo tinha NAQUELE instante — não o de hoje.
consulta = fg.athena_query()
consulta.run(query_string=f'''
    SELECT * FROM "{consulta.table_name}"
    WHERE registrado_em <= \'2026-03-01T00:00:00Z\'
''', output_location="s3://lago/consultas/")

O serviço adiciona uma dependência, um custo e um conceito novo para o time. Ele não se paga quando:

• Há um modelo só, com atributos calculados no mesmo código que serve a previsão — não existem duas implementações para divergir.
• A inferência é em lote e usa exatamente o mesmo trabalho que gerou o treino. Aqui o problema não existe, por construção.
• Os atributos são derivados diretamente da carga da requisição, sem histórico nem agregação. Não há o que armazenar.

O ganho aparece quando há mais de um modelo consumindo o mesmo atributo, ou quando treino e serviço rodam em caminhos de código diferentes. Fora disso, é infraestrutura à espera de um problema.

Com atributo consistente entre treino e serviço, resta a pergunta sobre o próprio dado: ele representa quem o modelo vai atender? É o assunto de viés e desbalanceamento, e é onde o domínio 1 encontra o domínio 4.