Research log

[vitalwarley]

Enquanto não penso em outro meio mais apropriado para o relatório abaixo, tratarei de inserir o log de tudo que foi feito na pesquisa desde julho.

Sprint 1

24

Basicamente revisei o que tínhamos até então baseado nos progressos de 2022, quando tentei reproduzir SOTA 2020 no FIW para o TCC. Não consegui reproduzir alguns resultados, logo desisti.

Sprint 2

25

Fui em busca de potenciais novos SOTAs e encontrei alguns surveys e trabalhos interessantes. Especificamente, em um desses trabalhos, encontrei o novo SOTA no RFIW 2021. Encontrei também o trabalho do desafio em si.

Após criar a issue sobre a leitura e reprodução do novo SOTA, fui em busca de outros surveys e trabalhos interessantes. Até o momento eu só terminei a leitura de A survey on kinship verification (Wang et al, 2023), mas não "Facial Kinship Verification: A Comprehensive Review and Outlook" (ainda em curso, pois comecei recentemente; seção 3).

26

Tratei de clonar o repositório e tentar reproduzir o trabalho. Obtive resultados equivalentes.

Reunião semanal

Acredito que apresentei os slides, onde explorei perguntas de pesquisa relacionadas com alguns trabalhos prévios no contexto de reconhecimento facial e com o tema machine unlearning.

Pouco depois, criei outra apresentação sobre o SOTA de 2021, mas não cheguei a apresentá-lo. Apenas em setembro, dia 15, que o apresentei para o pessoal do ZOIOZ, todavia noutra versão.

Sprint 3

27

Basicamente busquei reproduzir a análise visual via t-SNE das features aprendidas com o método proposto na #26. O processo está em tsne.ipynb, enquanto que em tsne_pairs.ipynb fui um pouco além (#29).

Sprint 4

28

Continuei a reprodução da análise visual com t-SNE.

29

É o que o nome diz: tentei fundir as featuers dos pares para visualizá-los. Os resultados são interessantes e creio valer retomar a análise em busca de insights (e.g. por que a fusão leva pares negativos de diferentes parentescos ao "mesmo lugar"?).

Sprint 5

32

@matheuslevi11 avaliou com objetivo de familiarizar-se com reconhecimento facial e transformers, bem como por curiosidade nossa sobre o trabalho em questão.

31

Obtive um SOTA para estimação de idade e gênero e apliquei no dataset. Os resultados estão no notebook rfiw_age_gender_analysis.ipynb. Mais detalhes na própria issue, mas conseguimos ali evidências para discrepâncias significativas nas diferenças de idade entre os diferentes tipos de parentesco ao compararmos pares positivos e negativos.

Sprint 6

33

Comecei um experimento para identificação de parentesco usando o mesmo backbone de #26, mas com uma camada de classificação. Os resultados não foram bons e ainda não retomei a issue; possivelmente farei com alguns ideias que surgiram ao longo do caminho.

Sprint 8

34

Criei, mas ainda não li.

35

Em um dado momento, nós pretendíamos adicionar informações de idade/gênero diretamente na perda contrastiva. Concluímos que isso não era possível, dado que necessitava criar tipos de parentescos arbitrários.

36

@matheuslevi11 analisou a acurácia do modelo de estimação de idade e gênero da #31. A ideia era validar a análise de idade que fizemos. Fica a questão: os erros encontrados nessa #36 (e.g. 33% de erro no test set são decorrentes da idade ou gênero)?.

Sprint 9

37

@matheuslevi11 iniciou uma análise dos erros do #26. Mais uma vez queríamos validar a hipótese da #31.

---

TODO

• Relatórios das reuniões com prof. Tiago
• Relatórios das reuniões com pessoal do ZOIOZ

[vitalwarley]

Sprint 15 (s. 20/10)

39

Objetivos

1. Reproduzir estratégias do SOTA2020 com PyTorch
   • Baseline: modelo pré-treinado em reconhecimento facial no MS1MV3 (93k IDs, 5.2M images))
   • Classificação de famílias
   • Classificação de famílias com normalização das features
2. Reproduzir SOTA2021 com PyTorch (meu código)
   • ResNet101 sem pré-treino em reconhecimento facial, mas treinada diretamente em verificação de parentesco com perda contrastiva
3. Mesclar SOTA2020 e SOTA2021
   • Usar modelo resultante do treinamento de classificação de famílias em uma tarefa de verificação de parentesco

Resultados

• Objetivo 1.3 não foi alcançado. AUC desejada era >0.79, mas consegui apenas 0.78 -- com alguns valores diferentes para os hparams.
• Objetivo 2 não foi alcançado. Consegui apenas 0.6674 de AUC em vez de 0.864550.
• Objetivo 3 não foi alcançado. Nenhum experimento conseguiu alcançar o objetivo final de ter AUC > 0.864550 (valor que consegui com scripts originais na RIG1).

Observações

Pode haver, entre outras, diferenças na arquitetura do modelo do script original vs modelo que usei (insightface), apesar de ambos serem ResNet101.

Sprint 20 (s. 24/11)

40

Apenas registrada. Será iniciada após outros experimentos serem realizados.

41

Finalizada parcialmente. Falta sintetizar as anotações.

42

• Há outros viéses, como o racial, que atrapalham a verificação de parentesco?

43 (Matheus)

• Como reutilizar features faciais para diferentes problemas?
• Como transformers são e podem ser usados no contexto de reconhecimento facial?

Sprint 21 (s. 01/12)

44

Explorar separação das features dos pares positivos e negativos com t-SNE. Similar à #27 e #29.

[vitalwarley]

Sprint 15 (s. 20/10)

39

Objetivos

2. Reproduzir SOTA2021 com PyTorch (meu código)

   • ResNet101 sem pré-treino em reconhecimento facial, mas treinada diretamente em verificação de parentesco com perda contrastiva

Resultados

• Objetivo 2 não foi alcançado. Consegui apenas 0.6674 de AUC em vez de 0.864550.

Na verdade há um engano aqui. No paper, temos

We use ArcFace (pre-trained ResNet101) [3] as the feature extraction network, which was also used by Vuvko [18] and won the first place in task I of the RFIW 2020 Data Challenge.

o que implica que de fato pré-treinaram o modelo no mesmo dataset que o SOTA2021 (MS1MV3). Não consegui o mesmo resultado que o SOTA2021 (0.865), mas cheguei perto (0.852). Dessa forma, vou continuar o #46 nos meus scritps (hybrid) com as ideias da semana: adicionar entropia cruzada (já fiz alguns experimentos e relato lá na 46) e t-SNE durante o treinamento.

[vitalwarley]

A partir de hoje vou criar revisões / logs por dia em vez de por issue. Assim teremos mais coerência no andamento dos experimentos, coisa que por vezes acaba me atrapalhando. Em breve começo a criticar mais à fundo os resultados encontrados.

Sprint 21 (01/12 - 07/12)

Dia 01

• Avaliei a geometria das embeddings provindas do SOTA2021 para os pares positivos e negativos.

  • Isso foi feito ao longo da semana, como podemos ver na issue.

Dia 02

• Terminei estudos do A Multi-Task Comparator Framework for Kinship Verification

  • 41

• Resgatei o melhor modelo treinado no esquema do SOTA2020 (classificação de famílias) e o usei em alguns experimentos variando tamanho do batch e taxa de aprendizado.

  • Sem sucesso -- nenhum experimento ultrapassou AUC de 0.86.

Dia 05

• Adicionei a perda de entropia cruzada ao código do SOTA2021. Resultados até aqui -- não conseguimos novo SOTA (AUC > 0.86 aqui).

Dia 07

• Identifiquei um engano sobre alguns experimentos e resultados no contexto do SOTA2021. Isso me direcionou a usar meus scripts de treinamento (que possuem guildai para facilitar). Identifiquei também um "erro" no dataset, que me direcionou a realizar experimentos com batch menor. Implementei SCL no SOTA2021 (op train-kv) e realizei alguns experimentos.

Sprint 22 (08/12 - 14/12)

Dia 09

• Não houve sucesso nos experimentos com batch menor, todavia vi que usei valores exagerados para beta, então outros experimentos foram realizados -- ainda assim sem sucesso. Paralelamente, tentei realizar experimentos com atualizações na taxa de aprendizado como feito no SOTA2020, mas sem êxito.

• Agreguei minhas anotações do trabalho Supervised Contrastive Learning for Pre-trained Language Model Fine-tuning.

Dia 10

• Resolvi adicionar SCL à estratégia do SOTA2020, porque fazia mais sentido dado a proposta original em Supervised Contrastive Learning for Pre-trained Language Model Fine-tuning. Nenhum experimento conseguiu ultrapassar o SOTA2020.

  • Em breve adiciono todos os experimentos no contexto do SOTA2020 para vermos que nada que foi feito até agora deu melhores resultados que a melhor estratégia do autor.

• Comecei a estudar mais sobre aprendizado contrastivo.

Dia 12

• Houve revisão de alguns experimentos e reunião presencial de follow-up e feedback. Foi decidido, entre outras possibilidades, a tentativa de replicação de A Multi-Task Comparator Framework for Kinship Verification.

Dia 13

• Criei a issue para replicar o trabalho A Multi-Task Comparator Framework for Kinship Verification. Enquanto procurava códigos associados, achei outros trabalhos interessantes

  • KFC: Kinship Verification with Fair Contrastive Loss and Multi-Task Learning

  • Kinship Representation Learning with Face Componential Relation

• Houve uma reunião com Matheus Levi para priorizar o estudo do SwinFace: A Multi-task Transformer for Face Recognition, Expression Recognition, Age Estimation and Attribute Estimation, pois creio que pode ser útil como backbone para lidar com viéses presente na verificação de parentesco.

[vitalwarley]

Semana passada, dia 07, explorei uns artigos ao pesquisar "contrastive learning" no scholar

Debiased Contrastive Learning

The paper discusses a new approach to self-supervised representation learning called debiased contrastive learning. This method corrects for the bias in traditional contrastive learning, which samples negative data points uniformly from the training data, and instead samples from truly different labels. The proposed objective consistently outperforms the state-of-the-art for representation learning in vision, language, and reinforcement learning benchmarks, and the authors provide a theoretical analysis of the debiased contrastive representation with generalization guarantees for a resulting classifier. The paper includes experiments on CIFAR10, STL10, ImageNet-100, and sentence embeddings.

What Makes for Good Views for Contrastive Learning?

The paper discusses the importance of view selection in contrastive learning, which has achieved state-of-the-art performance in self-supervised representation learning. The paper argues that reducing the mutual information between views while keeping task-relevant information intact is key to effective sparring. The authors introduce a semi-supervised method to learn effective views for a given task and demonstrate optimal views for contrastive representation learning are task-dependent. They examine the relationship between mutual information and representation quality in various settings and find a U-shaped relationship between the two.

Contrastive Learning Inverts the Data Generating Process

The article discusses the success of contrastive learning in self-supervised learning and its connection to generative modeling and nonlinear independent component analysis. Despite certain statistical assumptions, the theory shows that the success of contrastive learning lies in its ability to invert the data generating process, leading to useful learned representations. The article presents experimental evidence and theoretical foundations for more effective contrastive losses. The work is the first to analyze the circumstances under which representation learning methods used in practice represent the data in terms of its underlying factors of variation.

---

Estavam na primeira página da pesquisa e minha intuição é de que valem a penar ler com calma futuramente, especialmente porque temos trabalhos usando aprendizado contrastivo para solucionar a tarefa de KV (#26 e #50). Entendi que o primeiro mostra como criar uma função de perda que remova um tipo viés dos atributos aprendidos; o segundo sugere um princípio de minimização de informação (no contexto de informação mutual) para aprender representações que descartem informações sobre variáveis "inconvenientes" tal que melhore a generalização do modelo; o terceiro, por fim, eu só li o abstract (acima é o resumo do GPT3.5).

[vitalwarley]

Nos últimos dias (13-23), atuei somente na #49.

[vitalwarley]

Semana passada fiz um relatório bem simples.

Hoje comecei #50. Ao longo da semana vou revisando as demais issues que estão abertas há um tempo.

[vitalwarley]

Semana passada fiz um relatório bem simples.

Hoje comecei #50. Ao longo da semana vou revisando as demais issues que estão abertas há um tempo.

Por diferentes razões, não consegui voltar ao ritmo de antes. Retomando hoje.

[vitalwarley]

Ainda estudando #50.

[vitalwarley]

50 finalizada. #52 iniciada.

[vitalwarley]

51 parece ser uma boa próxima leitura. Dentre outras coisas, é proposta uma modificação na perda contrastiva tradicional.

Além disso, há uma ablação para qualidade de imagem, algo que nunca vi nos poucos papers de KV que li. Isso me deixa curioso em saber como adaptar a proposta do trabalho Recognizability Embedding Enhancement for Very Low-Resolution Face Recognition and Quality Estimation para o contexto de verificação de parentesco, se é que é possível (qual seria o equivalente de UIs aqui?).

[vitalwarley]

Criei #53 para ir mais a fundo na mecânica da perda, dado que os últimos SOTAs usam.

[vitalwarley]

Criei #53 para ir mais a fundo na mecânica da perda, dado que os últimos SOTAs usam.

Adicione #54 com mesmo objetivo.

[vitalwarley]

Iniciei #53.

[vitalwarley]

Interessante, mas inacessível: Face recognition challenges due to aging: a review

[vitalwarley]

Pausei #53. Vou estudar #51 para apresentar ao grupo próxima semana.

Enquanto isso, neste momento estou colhendo os resultados de #52, que estão na RIG2.

[vitalwarley]

https://github.com/vitalwarley/research/issues/51#issuecomment-1946939366

Comentando progresso incremental via leituras incrementais -- apenas li abstract, figures, tables, e conclusion até o momento.

[vitalwarley]

Creio que a #52 está finalizada porque consegui reproduzir o código, embora os resultados aparentem ser diferentes -- tanto localmente quanto na RIG2.

[vitalwarley]

Importante entender MixFair e a justificativa do debias term. Também investigar sobre mutual information. Ver https://github.com/vitalwarley/research/issues/38#issuecomment-1856482051. Também, considerando substituto da camada debias.

[vitalwarley]

Resumo do mês de janeiro até agora

• Estudei, apresentei e reproduzi os resultados da #50 (ver #52)
• Planejei os estudos de da #53 e #54
• Iniciei os estudos de #53, mas pausei em favor da #51
• Criei outras issues para estudo futuro

  • 56

    • Vai ser útil na disciplina PPGI058 (IA Generativa)
    • Pode ser útil ao TCC do @matheuslevi11

  • 55

    • utsc-nelslip nas tabelas apresentadas em #25
  • Dois survey, que já estudei, mas que quero estudá-los novamente

    • 57

    • 58

No entanto, na reunião de ontem, ficou definido focar nos três itens abaixo

1. 63

2. 64

3. 65

[vitalwarley]

Enquanto atuava #65, lembrei do meu interesse na #51 e criei a #66.

[vitalwarley]

Dentre as tarefas que ficaram definidas no resumo anterior, eu realizei parcialmente a #65. As tarefas #63 e #64 não foram devidamente iniciadas.

Na última reunião de pesquisa (08/03/2024), eu tratei especialmente da minha análise do #51, em especial do método proposto vs. o que foi implementado, como podemos ver em https://github.com/vitalwarley/research/issues/67#issuecomment-1975381986. Nesse contexto, eu havia definido dois passos posteriores: 1) reorganizar o código para meu esquema próprio (fiz para outras tarefas, vide #49 e #46), pois facilita os experimentos e discussões; 2) reproduzir os resultados dos autores. Nenhum desses passos foi realizado ainda.

Essa reunião também trouxe novas atividades

• Buscar evidências de que o uso de informações prévias de gênero e idade melhoram a performance do modelo

  • 70

• Completar as bases de dados com MiVOLO (Lucas Massa)
• Avaliar duas novas estratégias
  • Feature disentanglement
  • Agregar informações de identidade e demográficas (e.g., gênero, idade, raça) no processo de aprendizado
  • Multi-level representations
  • ...

Pretendo explorar essa primeira estratégia usando o trabalho #50 como base, pois já possui anotações de raça e identidade. Pretendo também adicionar pseudo-labels de idade e gênero (e possivelmente outras provindas de #42). Como farei isso tudo ainda é uma questão em aberto.

[vitalwarley]

Outra ideia discutida na reunião foi multi-task learning. Penso que seja mais fácil explorá-la antes de algo na linha de feature disentanglement.

[vitalwarley]

Na última reunião (22/03/2024), apresentei os avanços recentes

• 71

  • Reorganizei o código para usá-lo com guildai.
  • Consegui reproduzir os resultados da FaCoRNet.
  • Tentei por um momento adaptar o código para PyTorch Lightning, mas travei na compatibilidade da CLI com guildai.
  • Adicionei uma camada HeadKin para classificação de parentesco, todavia não houve ganho em AUC ou acurácia de verificação -- o melhor resultado até agora foi a reprodução, com AUC = 0.8747. É o que devemos conseguir superar.
  • Observações
  • Há uma instabilidade na verificação de tipos de parentesco bb que talvez valha investigar.
  • Similarmente, há uma demora para alcançar a estabilidade e convergência nos tipos sibs e ss.
  • Os tipos grandparent-grandchild são pouco frequentes, logo a acurácia do modelo nessas amostras são drasticamente menores e instáveis.

• 72

  • Ainda em curso.
  • Pretendo refazer os experimentos listados a partir daqui.

O planejamento atual é continuar experimentando. Abaixo as linhas de possibilidades.

• Multi-task learning
• Feature disentanglement
• Multi-level representations

Penso que a mais interessante é a 2a, mas preciso avaliar como implementar.

Em detalhes, além das issues anteriores, relembro aqui outras possibilidades

• 63

• 64

• 65

• https://github.com/vitalwarley/research/issues/52#issuecomment-1997488997
  • Adicionar Rel-Guide Loss ao KFC ou Debias e Race Classifier à FaCoRNet
  • Avaliar diferentes mecanismos de interação de canais
  • Classificador de família no lugar do classificador de parentesco

[vitalwarley]

Essa semana decidi focar primeiro em experimentar com classificação de família junto à FaCoRNet a partir do que fiz na #71. Todavia, não resisti à vontade (e necessidade) de usar PyTorch Lightning. Já consegui realizar a implementação junto ao guildai, mas falta algo no módulo Lightning. Abaixo segue o treinamento com meu código original, onde incluí a perda de validação para comparar com meu código em PyTorch Lightnining. Ainda não entendi porque a perda de treino desce, mas a de validação não. Estranho também que a AUC difere em ambos os casos, mas não a acurácia. Na verdade, a acurácia é até maior no código com PyTorch Lightning (0.8738 vs 0.8061). Em todos os casos, computei as métricas apenas ao fim da época -- considerando todas as (bs * step_per_epoch) predições na época.

Accuracy

Em rosa, o código original. Acurácia de treinamento faz sentido ser 0, dado que no treinamento só há amostra positivas; possivelmente problema de arrendondamento.

AUC

Em rosa, o código original.

Loss

Original

PyTorch Lightning

[vitalwarley]

Tentei as seguintes mudanças

• Remover o viés do dataset (shuffle=True no train_dataloader e break quando se chegava em trainer.limit_train_batches).
• Otimização manual
• Remoção das métricas -- deixei apenas a perda de treino e validação

Nada mudou. A perda de treino continua caindo, enquanto a perda de validação continua subindo.

[vitalwarley]

Isolei o treinamento em um novo código e consegui reproduzir o mesmo problema (apenas a perda de validação manteve-se igual). A questão é: por quê? Caso não consiga responder amanhã, vou desistir do Lightning e voltar pro código raw.

import torch
from torch.utils.data import DataLoader
import matplotlib.pyplot as plt
from tqdm import tqdm
from models.facornet import FaCoRNetLightning
from datasets.facornet import FaCoRNetDataModule

from lightning import seed_everything

seed_everything(100)

num_epochs = 5
batch_size = 20
steps_per_epoch = 100

# Step 1: Initialization
model = FaCoRNetLightning()
model.cuda()

# Step 2: Data Preparation
data_module = FaCoRNetDataModule(batch_size=batch_size, root_dir="../datasets/facornet")
data_module.setup('fit')
train_loader = data_module.train_dataloader()
val_loader = data_module.val_dataloader()

# Step 3: Training Loop
optimizer = torch.optim.SGD(model.parameters(), lr=1e-4, momentum=0.9)
for epoch in range(num_epochs):
    model.train()
    epoch_train_loss = 0
    for idx, batch in enumerate(tqdm(train_loader, total=steps_per_epoch)):
        optimizer.zero_grad()
        loss = model.training_step(batch, idx)
        loss.backward()
        optimizer.step()
        # Log training loss
        epoch_train_loss += loss.item()
        if idx >= steps_per_epoch:
            break

    # Step 4: Validation Loop
    model.eval()
    with torch.no_grad():
        epoch_val_loss = 0
        for batch in tqdm(val_loader):
            val_loss = model.validation_step(batch, ...)
            # Log validation loss
            epoch_val_loss += val_loss.item()
        epoch_val_loss /= len(val_loader)

    epoch_train_loss /= len(train_loader)
    print(f"Epoch: {epoch} | Loss: {epoch_train_loss} | Val Loss: {epoch_val_loss}")

    use_sample = (epoch + 1) * batch_size * steps_per_epoch
    train_loader.dataset.set_bias(use_sample)

# ... training_step / validation_step in the FaCoRNetLightning

def forward(self, inputs):
    return self.model(inputs)

def _step(self, batch, stage="train"):
    img1, img2, labels = batch
    kin_relation, is_kin = labels
    # Move img1 and img2 to the same device as the model
    img1, img2 = img1.to(self.device), img2.to(self.device)
    f1, f2, att = self((img1, img2))
    loss = self.loss_fn(f1, f2, beta=att)
    sim = torch.cosine_similarity(f1, f2)

# datasets and dataloaders in the datamodule
  if stage == "fit" or stage is None:
      self.train_dataset = FIW(
          root_dir=self.root_dir,
          sample_path=Path(FIWFaCoRNet.TRAIN_PAIRS),
          batch_size=self.batch_size,
          biased=True,
          transform=self.transform,
      )
      self.val_dataset = FIW(
          root_dir=self.root_dir,
          sample_path=Path(FIWFaCoRNet.VAL_PAIRS_MODEL_SEL),
          batch_size=self.batch_size,
          transform=self.transform,
      )

def train_dataloader(self):
    return DataLoader(self.train_dataset, batch_size=self.batch_size, shuffle=False, num_workers=4, pin_memory=True)

def val_dataloader(self):
    return DataLoader(self.val_dataset, batch_size=self.batch_size, shuffle=False, num_workers=4, pin_memory=True)

🤔

[vitalwarley]

O problema era no código original. Esqueci a agregação das perdas de validação. Eu retornava apenas a perda do último batch. Segue abaixo as métricas do novo treinamento.

AUC e ACC são avaliadas no conjunto de validação e continuam subindo, mesmo com o notável sobreajuste.

[vitalwarley]

mas falta algo no módulo Lightning... Ainda não entendi porque a perda de treino desce, mas a de validação não. Estranho também que a AUC difere em ambos os casos, mas não a acurácia.

Bom, acredito que resolvi os problemas restantes relativo às métricas. Dropei as métricas de treino, dado que não há amostras negativas ali. Também preferi o uso das métricas funcionais, pois não preciso acumulá-las ao longo da validação -- tenho minha própria forma de fazê-lo para obtenção do melhor limiar.

Segue abaixo as métricas e afins. Aproveitei para adicionar precisão e cobertura. O modelo atinge um teto porque é incapaz de melhorar a discriminabilidade das amostras positivas. Isso é, a maior parte dos pares negativos são corretamente verificados, todavia grande parte dos pares positivos não -- note o limiar usado e a distribuição dos limiares positivos e negativos. Ainda assim, eu esperava uma menor cobertura, não? Há o que entender aqui. De qualquer forma, é um ótimo achado. Penso que essa seja a real contribuição da perda contrastiva, que foi tunada pelo mapa de atenção.

[vitalwarley]

Da última reunião até hoje, apenas tratei de atuar na #71. A ideia era deixar o Lightning de lado, mas ao tentar continuar as atividades no código raw (sem framework), percebi que seria desgastante e improdutivo. Portanto, decidi voltar. Abaixo os milestones.

1. Consegui usar guildai com Lightning
2. Descobri problemas nas métricas e nas perdas no Lightning relativo ao meu código raw
   • Perda de validação subindo no Lightning, mas descendo no código raw
   • Acurácia maior que AUC
3. Corrigi um problema no código raw: falha na agregação da perda de validação
   • Pensei que a perda de validação denotar sobreajuste a partir da ~5 época era problema no meu código Lightning, mas notei que era problema também no código original dos autores.
4. Corrigi um "problema" com limiar: valores retornados por torchmetrics.functional.roc representam probabilidades
   • Usar tal limiar como probabilidade para discriminar as predições (similaridades) na validação e teste resultava em baixa acurácia no geral (muitos Falsos Negativos)
   • Foi preciso, portanto, converter a probabilidade de volta para logit antes de logá-lo
   • Adicionei um plot representativo ao treinamento: ROC Curve e Histogram of Similarities (with similarity threshold)

[vitalwarley]

Novos baselines considerando o código atual

run       operation       auc       accuracy  precision  recall    threshold
9ae929af  facornet:test   0.896797  0.818005  0.813028   0.826395  0.101611
605fc9ef  facornet:val    0.875998  0.802175  0.804439   0.798456  0.101611
68644994  facornet:train  0.874000  0.802999  0.814999   0.828000  0.090199

• Métricas de treino (computadas no conjunto de validação para seleção do modelo) não são pareadas, isso é, ordenei pelo máximo de cada, mas não necessariamente foram computadas na mesma época.

Comparando ao baseline com código anterior

Aqui temos [as métricas de validação para seleção do modelo:] AUC = 0.8747 e ACC = 0.8029.

Quanto à validação para obtenção do limiar e teste posterior.

	AUC	acc	threshold	acc_md	acc_ms	acc_sibs	acc_ss	acc_bb	acc_fd	acc_fs	acc_gfgd	acc_gfgs	acc_gmgd	acc_gmgs
Val	0.8748	0.8013	0.5248	0.8172	0.7631	0.8587	0.9067	0.9295	0.7732	0.8087	0.3465	0.2412	0.3627	0.3495
Test	0.8953	0.8171	0.5248	0.7999	0.7519	0.8190	0.8471	0.8615	0.7489	0.8420	0.6694	0.4792	0.4225	0.2262

• Esse baseline foi na RIG2 com batch_size=50.
  • O tamanho do batch apenas define em que ponto do treinamento a validação ocorre, porque a forma que o treinamento vem sendo feito desde #26 é dar apenas um passe em todo dataset.
  • Logo, um batch maior significa usar um modelo mais maduro, digamos assim.
  • Na RIG, foram 50 (passos por época) * 50 (tamanho do batch) batches por época. Total 2500.
  • No meu experimento, foram 50 * 20 = 1000.
• O número de épocas não importa: há um sobreajuste logo após o começo do treinamento. A validação vai subir. As métricas ainda melhoram, mas estabilizam em seguida.
• O threshold em cada caso é uma probabilidade. Convertendo-os, temos: 0.0993.

Abaixo os resultados reportados pelos autores mais uma vez, bem como meus resultados por tipo de parentesco também. Podemos ver que meus resultados são equivalentes aqueles reportados pelos autores.

run       auc       accuracy  accuracy/bb  accuracy/ss  accuracy/sibs  accuracy/fd  accuracy/md  accuracy/fs  accuracy/ms  accuracy/gfgs  accuracy/gmgs  accuracy/gfgd  accuracy/gmgd
9ae929af  0.896797  0.818005  0.826169     0.838524     0.816051       0.793792     0.820931     0.840610     0.798957     0.702040       0.575419       0.787810       0.765799

[vitalwarley]

A diferença em accuracy/gmgs entre os experimentos é notável: 0.2262 ⇒ 0.5754. Por quê?

Não ajuda muito. Talvez um plot assim para cada tipo de parentesco seja melhor?

[vitalwarley]

• O tamanho do batch apenas define em que ponto do treinamento a validação ocorre, porque a forma que o treinamento vem sendo feito desde Reproduzir "Supervised Contrastive Learning for Facial Kinship Recognition"  #26 é dar apenas um passe em todo dataset.
• Logo, um batch maior significa usar um modelo mais maduro, digamos assim.
• Na RIG, foram 50 (passos por época) * 50 (tamanho do batch) batches por época. Total 2500.
• No meu experimento, foram 50 * 20 = 1000.
• O número de épocas não importa: há um sobreajuste logo após o começo do treinamento. A validação vai subir. As métricas ainda melhoram, mas estabilizam em seguida.

Isso aqui é importante porque indica que o dataset é utilizado ineficazmente.

[vitalwarley]

Discussão sobre os experimento sem https://github.com/vitalwarley/research/discussions/74 para que essa issue de log permaneça enxuta.

[vitalwarley]

Discussão sobre os experimento sem #74 para que essa issue de log permaneça enxuta.

De lá pra cá, realizei mais experimentos, e todos sem sucesso. Alguns aprendizados ficaram, no entanto. Ver discussão para mais detalhes. Penso que a estratégia de multi-task só funcionou no #50 por conta da tamanho do novo dataset (+44227 pares). Minha próxima tarefa é usá-lo, mas sem esquema de multi-task.

[vitalwarley]

É importante notar que multi-task learning possui várias estratégias de implementação.

[vitalwarley]

Experimentos recentes

FaCoRNet + KinRace

• Não há multi-tasking, mas apenas treinamento de verificação.
• Não houve melhoras nos conjuntos de validação e teste do FIW relativo ao treinamento do FaCoRNet no FIW.
• Minha hipótese de que mais dados de treino foram o suficiente para color KFC "na frente" no FIW foi parcialmente invalidada. Parcialmente apenas, pois não fui a fundo em confirmar que minha implementação tinha sido satisfatória. Eu creio que sim, no entanto.
  • O KinRace tem mais amostras, de fato, mas de apenas 4 tipos de parentesco. Os demais tipos de parentesco ainda são informativos e por isso seu tamanho pode não ter sido tão efetivo assim a ponto de equivaler aos resultados do FaCoRNet treinado apenas no FIW.

KFC Full (multi-task + adversarial)

• Consegui melhores resultados com meu código em Lightning do que com código original (e.g. 0.9036 vs 0.8801 na AUC de validação)
• Todavia, deve haver algum bug na computação das métricas sobre as raças, pois foram drasticamente menores.
• Resultados no FIW foram um tanto abaixo daqueles reportados pelo autor, o que é estranho, dado que em alguns casos obtive melhores resultados.
  • O interessante foi que a estratégia da seção anterior trouxe melhores resultados no FIW.

FaCoRNet + KFCAttentionV2

• TODO

FaCoRNet + ajustes na perda contrastiva

• TODO

[vitalwarley]

De sábado até ontem, foquei em Comparativo entre os módulos de atenção: FaCoR vs KFC. Dediquei mais tempo do que esperava, e acredito que por que não planejei adequadamente como realizar esse comparativo. De qualquer forma, podemos ver que, segundo meus experimentos, aparentemente o mecanismo de atenção proposto pelo #50 não é melhor do que o proposto em #51, mesmo que o do KFC seja uma suposta "melhoria".

Seguem algumas ideias

• Avaliar Co-attention no contexto trazido pela FaCoRNet

One core question for kinship recognition is: How to properly extract and compute the relation between face components in a face image pair?

Não lembro a intuição de chegar em co-atenção, mas estava lendo algo sobre gated fusion, se não me engano.

• Avaliar KFC (completo) com módulo de atenção original do FaCoR
  • O esperado é termos melhores resultados que aqueles que eu consegui.

[vitalwarley]

Ontem não houve reunião, mas apresentei os resultados atuais ao grupo soios. Dia 19/04 houve reunião, no entanto, e o que ficou definido foi

• 77

• Experimentar com remoção dos componentes de atenção da FaCoR
• [x] KFC no FIW diretamente (testar seu mecanismo de atenção)
  • Feito em https://github.com/vitalwarley/research/discussions/74#discussioncomment-9228520, todavia precisei adicionar componentes ao KFC para que pudesse adaptar os mapas de atenção do FaCoR para uso na camada de Debias.

• 76

  • Extender o trabalho do Lucas para reconhecimento facial de parentesco a partir da pseudo anotação do FIW com expressão, idade e gênero

Adicionalmente, estudar os diferentes mecanismos de atenção é também importante, todavia no experimento https://github.com/vitalwarley/research/discussions/74#discussioncomment-9229886 não há diferença aparente com ou sem atenção...

[vitalwarley]

Adicionei mais detalhes https://github.com/vitalwarley/research/discussions/74#discussioncomment-9247283 sobre o comparativo entre os módulos. Dado a dificuldade de discernir ganhos de performance na track 1 (kinship verification), comecei a implementar a validação para a track 3 (search and retrieval). Todavia, encontrei alguns obstáculos

• 51 não apresenta como fez para obter os resultados da track 3, nem provê implementação.

  • Estou avaliando como implementar.
• Tentei pegar as listas de #26, mas não há ground-truth. Na época, usaram o site da competição para obter os resultados, eu acredito.
  • Felizmente, á consegui as labels e em breve as usarei.

[vitalwarley]

Essa semana trabalhei na #75. Minha razão para isso foi de fato avaliar minha ablação dos componentes da FaCoRNet realmente atestam para ineficácia do módulo de atenção. A partir daí, um caminho seria um estudo aprofundado da perda contrastiva ou do mecanismo de atenção.

Em resumo, acredito que consegui reproduzir a Track 3 do SOTA2021 (#26) e atualmente estou tentando reproduzir os resultados #51 na mesma trilha. O problema é que está bem lento e, aparentemente, não há nada o que possa ser feito, exceto usar as features do backbone em vez daquelas do mecanismo de atenção...

[vitalwarley]

Resumo do meu resumo das duas últimas semanas com ChatGPT

2 de Maio de 2024

• Discussão sobre Implementações Anteriores:
  • Trabalho na Implementação da Track 3 no FaCoRNet: Para avaliar se o módulo de atenção realmente traz melhores resultados. Se isso fosse confirmado, aprofundaria o estudo dos mecanismos de atenção.
  • Reprodução dos Resultados do SOTA2021: Consegui reproduzir e até melhorar os resultados da Track do "Supervised Contrastive Learning for Facial Kinship Recognition – 2021". No entanto, o uso do mecanismo de atenção no meu código deixou o processo bastante lento (cerca de 12 horas). Os autores originais não divulgaram como otimizaram essa tarefa.
• Início de Novos Tópicos de Pesquisa:
  • Criação das Issues #76 e #77.

4 de Maio de 2024

• Avaliação de Modelo de Classificação de Família:
  • Treinamento de Modelo (April 9, 2024): Monitoramento de AUC com paciência de 10 dias. Planejo refazer o treinamento, desta vez monitorando especificamente a classificação de família.
  • Problemas Técnicos: O treinamento foi interrompido devido a um erro de CUDA: "RuntimeError: CUDA error: CUDA-capable device(s) is/are busy or unavailable".
  • Discussão Relevante: GitHub Discussion #74.

6 de Maio de 2024

• Coleta e Estudo de Literatura sobre Aprendizado Contrastivo:
  • Papers Coletados:
  • "Understand and Improve Contrastive Learning Methods for Visual Representation: A Review" (Seção 4.2 interessante).
  • "Contrastive Learning With Stronger Augmentations".
  • "Intriguing Properties of Contrastive Losses".
  • "Improving Contrastive Learning by Visualizing Feature Transformation".
  • Ideias e Reflexões: Consideração de várias ideias como aumento de base, ordenação dos lotes por dificuldade e banco de memória.
  • Experimentos com diferentes backbones: R18, R50, R101 @ WebFace4M.
  • Discussão Adicionada: GitHub Discussion #74.
• Estudo sobre Aprendizado por Currículo para Reconhecimento de Parentesco:
  • Curriculum Learning for Face Recognition
  • "Easy pair selection method for Kinship Verification using fixed age group images" (Chai et al., 2023).
  • "Recognizability Embedding Enhancement for Very Low-Resolution Face Recognition".
  • "Harnessing Unrecognizable Faces for Improving Face Recognition".
  • Ideias Adicionais: Fusões de features de indivíduos de um par e classificação de família, assumindo que as features dos indivíduos de uma família estarão próximas. Isso pode ser interessante para melhorar a precisão da classificação.

9 de Maio de 2024

• Leitura e Avaliação Inicial:
  • Paper: "Age-Invariant Adversarial Feature Learning for Kinship Verification".
  • Links para Discussões e Issues: GitHub Issue #34.
• Experimentos com Task 3 de KV: Usando features do backbone da FaCoRNet, os resultados foram ruins, sugerindo um possível bug no código.

10 de Maio de 2024

• Reunião de Equipe:
  • Definições de Tarefas e Estudos Futuros: Estudar "Improving Contrastive Learning by Visualizing Feature Transformation". Considerar a criação de bases reduzidas do FIW ou usar toy-datasets para testar ideias semelhantes às apresentadas no paper.

12 e 13 de Maio de 2024

• Experimentos com Diferentes Backbones e Treinamentos Prolongados:
  • Links para Discussões e Insights Adicionais: GitHub Discussion #74.
• Organização do Zotero: Adição de novos artigos providos pelo Prof. Tiago Vieira.
• Reflexões e Insights:
  • Paper: "Adversarial Similarity Metric Learning for Kinship Verification".
  • Insight: Reflexões sobre o que define parentesco e o impacto de manipulações de imagem na similaridade.
  • Discussões: Criação de toy-examples, como usar MNIST ou CIFAR-10 para classificação com redes siamesas.
  • Papers Adicionais:
  • "Kinship Verification Based on Cross-Generation Feature Interaction Learning".
  • "Reasoning Graph Networks for Kinship Verification: From Star-Shaped to Hierarchical".
  • "A Unified Approach to Kinship Verification".
  • Alternativas ao DisVAE: Consideração de outros métodos devido a problemas de adaptação de domínio, como feature augmentation.
• Continuação do Estudo sobre Aprendizado Contrastivo e Métodos Relacionados:
  • Novos Métodos e Abordagens:
  • "Max-Margin Contrastive Learning" (2022), inspirado em SVMs.
  • Survey: "A Survey on Self-supervised Learning: Algorithms, Applications, and Future Trends" aponta Masked Image Modeling-based methods como superiores aos métodos contrastivos.
  • Survey: "Contrastive self-supervised learning: review, progress, challenges and future research directions" discute "asymmetric scoring function" na Seção 6.5.
  • Necessidade de Tempo: Reconhecimento de que a área de aprendizado contrastivo é extensa e requer tempo para um entendimento profundo.
• Dúvidas
  • Se no processo de treinamento, cada par positivo fosse misturado entre si, como isso impactaria o treinamento? Misturado à lá MixUp.
  • A dúvida que me persegue: por que o modelo satura logo no início do treinamento (i.e., erro de treino estabiliza, enquanto erro de validação sobe; ao mesmo tempo, métricas de performance estabilizam também)? O que acontece com treinamento se eu remover EarlyStopping e treinar até o fim?
  • Esse experimento "sem" EarlyStopping já foi feito. Nada acontece, apenas a estabilização das métricas, inclusive do erro de validação e antes de ver o dataset inteiro.

[vitalwarley]

Resumo dos meus registros do último mês com ChatGPT

Categorias:

1. Estudo e Preparação de Apresentação
2. Implementação e Experimentação
3. Revisão Sistemática
4. Projeto de Pesquisa (PPGI058)

---

Estudo e Preparação de Apresentação

Semana 21 (20-26 Maio)

• May 20
  • Prioridade em estudar e preparar a apresentação sobre o artigo "Improving Contrastive Learning by Visualizing Feature Transformation" para a equipe do Zoioz.
• May 22
  • Continuar estudando o artigo, focando na seção "Proposed Feature Transformation Method".
  • Detalhes sobre métodos de transformação de atributos, como Positive Extrapolation e Negative Interpolation.
  • Discussões sobre técnicas de interpolação negativa e a importância de variância e diversidade nos conjuntos de dados.
  • Planos de entender melhor a "Uniformity-Tolerance Dilemma" e a "Gradient Reduction Problem".
• May 23
  • Foco em finalizar o artigo e preparar a apresentação.
  • Discussões sobre extensão de filas de memória versus transformação de atributos.
  • Reflexões sobre treinamento no FIW e a necessidade de experimentos de visualização para analisar parâmetros como temperatura e tamanho do batch.

Semana 23 (03-09 Junho)

• June 5
  • Documentação das atividades anteriores e preparação para apresentação.
  • Continuação da apresentação sobre "Improving Contrastive Learning by Visualizing Feature Transformation".
• June 6
  • Revisão de tarefas necessárias e preparação de template para qualificação.
  • Finalização da apresentação e revisão final.

Semana 24 (10-16 Junho)

• June 8
  • Discussão sobre possíveis priors para kinship e criação de dataset para avaliação.
  • Avaliação do Controllable Face Synthesis Module no contexto de DisVAE.

---

Implementação e Experimentação

Semana 21 (20-26 Maio)

• May 25
  • Implementação do método proposto no esquema atual com FaCoRNet.
  • Relatórios de experimentos com problemas e ajustes necessários, como interpolação negativa causando colapso.
  • Experimentações variando parâmetros e observações sobre resultados e ajustes necessários.

Semana 22 (27 Maio - 02 Junho)

• May 27
  • Experimentos contínuos com diferentes abordagens e ajustes, como normalização de features e variação de temperatura.
  • Discussão sobre a necessidade de melhorar o baseline SOTA2021-like.
• May 28
  • Revisão e análise dos últimos experimentos.
  • Reflexões sobre a transformação de atributos no contexto de aprendizado contrastivo supervisionado.
  • Experimentação com diferentes valores de temperatura e análise de resultados.
• May 29
  • Revisão de experimentos e avaliação de técnicas de perda contrastiva.
  • Exploração de métodos de visualização para reconhecimento de parentesco e análise de distribuições de similaridade.
• May 30
  • Tentativa de implementar uma versão da perda contrastiva que considere rótulos de família.
  • Ajustes e correções em experimentos para melhorar a estabilidade e performance.

Semana 23 (03-09 Junho)

• June 4
  • Treinamento do DisVAE e integração com código de kinship para gerar um dataset aumentado.
• June 5
  • Revisão de experimentos e reflexões sobre ajustes necessários.
• June 9
  • Revisão de experimentos e considerações sobre a adição de CE na otimização.
  • Experimentação com diferentes fatores de perda e ajustes no método de transformação de atributos.
  • Ainda não documentado.

---

Revisão Sistemática

Semana 24 (10-16 Junho)

• June 12
  • Planejamento da Revisão Sistemática (Research 69) utilizando ferramentas e geração de perguntas de pesquisa.
  • Coleta e filtro de artigos relevantes, resultando em 43 trabalhos finais.
• June 13
  • Continuação do planejamento da revisão sistemática.
  • Refinamento da pergunta de pesquisa e criação de uma busca abrangente de termos e fontes de dados.
• June 14
  • Finalização do artigo com resultados preliminares.
  • Revisão dos artigos coletados e preparação para a conclusão da revisão sistemática.

---

Projeto de Pesquisa (PPGI058)

Semana 23 (03-09 Junho)

• June 4
  • Treinamento do DisVAE e integração com código de kinship para gerar um dataset aumentado.
  • Treinamento concluído e planejamento de próximos passos.
• June 5
  • Documentação das atividades anteriores e preparação para apresentação de resultados.
  • Revisão e finalização dos experimentos no contexto de DisVAE.
• June 8
  • Discussão sobre possíveis priors para kinship e criação de dataset para avaliação.
  • Avaliação do Controllable Face Synthesis Module no contexto de DisVAE.

[vitalwarley]

Documentei meus experimentos do dia 09/06 aqui. Interessante que durante #69, eu encontrei o artigo Supervised Contrastive Learning and Feature Fusion for Improved Kinship Verification, cujo esquema é em dois estágios:

Os experimentos que documentei adicionam a perda entropia cruzada binária, mas em um estágio só e não em um esquema de classificação. Outra diferença é o uso de uma camada de projeção. Eu uso o backbone (encoder) sem projeção. Em outros casos eu já tinha usado a camada de projeção, mas não nos últimos experimentos.

[vitalwarley]

Realizei #81 e documentei em https://github.com/vitalwarley/research/discussions/74#discussioncomment-9809115. Sem sucesso. Difícil demais? O dataset de treino foi oriundo do train.csv, onde eu resgatei todas as amostras de cada tipo de parentesco e criei 10k combinações para serem usadas no treinamento -- par_i e par_j, onde cada par era do mesmo tipo de parentesco. Acontece que no treinamento em si mantive 100 passos por época, mas acho que não mudaria o resultado se isso fosse aumentado.

Próximos passos

• Reproduzir #80
  • Adicionar insight do mecanismo de atenção para fusão de atributos
• Experimentar SOTA2021-like com AdaFace usando camada de projeção no treinamento

[vitalwarley]

Próximos passos

• Reproduzir Supervised Contrastive Learning and Feature Fusion for Improved Kinship Verification #80

Não reproduzi #80, mas tratei de iniciar experimentos associados. Documentei em https://github.com/vitalwarley/research/discussions/74#discussioncomment-9817777.

• Adicionar insight do mecanismo de atenção para fusão de atributos

Deu ruim. Ver experimentos 8 e 9.

• Experimentar SOTA2021-like com AdaFace usando camada de projeção no treinamento

Ver esses experimentos. Em resumo, tal camada parece não dar bons resultados isolados, isso é, melhorar o baseline (o estágio 1 do #80), todavia, em conjunto estágio 2 de classificação, talvez haja uma sinergia.

[vitalwarley]

Novos experimentos relativo ao dia 20 e 25 registrados aqui. Em resumo, no Estágio 1 dos experimentos, a adição de um sampler ao baseline FaCoRNet com backbone AdaFace resultou em um claro ganho de performance (AUC = 0.8708 vs 0.8671 e ACC = 0.8037 vs 0.7973). No entanto, a inclusão de uma camada de projeção apresentou resultados inferiores. O autor de #80 revelou que a arquitetura utilizada inclui um encoder ArcFace100 e cabeçalhos de projeção e classificador MLP, com embeddings contrastivas de 128D e métricas nas embeddings de 512D do backbone. Como citei, usei AdaFace101 -- provindo do FaCoRNet. No Estágio 2, experimentos com classificação de parentesco não mostraram melhorias significativas, como reportado pelo autor. Possivelmente errei algo, mas não investigarei por agora. A adição de aumento de base será o foco dos próximos experimentos, utilizando técnicas como jitter de cor, escala de cinza aleatória e inversão horizontal para melhorar a generalização do modelo.

[vitalwarley]

Aumento de base + Sampler

[vitalwarley]

Últimos experimentos

• Domingo: Aumento de base + Sampler + Hard Contrastive Loss
• Ontem

  • 82

  • Adversarial Training

Esses dois últimos tiveram resultados insatisfatórios, especialmente o referente à #82. Avaliar-os-ei assim que oportuno.

Próximos experimentos imediatos

1. Corrigir HC Loss 1.1 Não filtrar amostras positivas 1.2 Usar alpha local
2. Remover aumento de base
3. Filtrar positivas (corretamente)
4. Experimentar com transformação de atributos (à lá Improving Contrastive Learning by Visualizing Feature Transformation)

Próximos estudos/experimentos posteriores

1. Estudar #82 e entender o raciocínio para mineração realizada 1.1 Eu implementei o paper, mas obtive resultados ruins. Pode ser que minha implementação esteja errada e/ou os hparams usados no paper não sejam adequadas ao backbone que usei.
2. Avaliar temperatura ajustável

Adjust the temperature parameter $\tau$ dynamically to balance between uniformity and tolerance, as highlighted in #53​. This helps in handling the uniformity-tolerance dilemma by controlling the strength of penalties on hard negative samples.

Incorporate a mechanism to adjust the temperature $\tau$ dynamically based on the training stage or batch difficulty.

def adjust_temperature(initial_tau, epoch, max_epoch, min_tau=0.07):
    return max(min_tau, initial_tau * (1 - epoch / max_epoch))

# Example usage
current_tau = adjust_temperature(initial_tau=0.5, epoch=10, max_epoch=100)

3. Incorporar informações de gênero, idade e raça 3.1 Obtive as duas primeiras via MiVOLO. A terceira tem o KinRace, mas o ideal seria usar todos os parentescos, e o KinRace tem apenas os quatro principais, se n me engano.

Por exemplo, ajustar a temperatura a depender a dificuldade do par (baseando-se nesses dados demográficos).

[vitalwarley]

Próximos experimentos imediatos

1. Corrigir HC Loss 1.1 Não filtrar amostras positivas

Não há filtragem das amostras positivas. As positivas vem de pos_sim_ij e pos_sim_ji. exp_cosine_sim_masked é usado apenas para obter as negativas; as positivas ali são definidas como zero, logo não contribuiriam mesmo assim.

1.2 Usar alpha local

Não há alpha local. Eu entendi errado. Todavia, posso experimentar isso em breve...

2. Remover aumento de base

Parece ter sido melhor em termos de acurácia e precisão.

[vitalwarley]

3. Filtrar positivas (corretamente)

Não funcionou. Posso ter errado a implementação, mas não focarei nisso agora.