Experimentos

[vitalwarley]

A partir do baseline exposto em #38 (comment), comecei a realizar experimentos simples.

i. Adição de warmup e decaimento de LR multistep.
ii. Modificação nas taxas de aprendizado inicial, base e final
iii. Uso do AdamW

Descobertas notáveis

• (i) (amarelo) não promoveu melhor AUC ou acurácia geral, mas trouxe maior estabilizada na acurácia para cada tipo de parentesco; em alguns casos, até maior acurácia, como podemos ver abaixo -- baseline em verde. Todos os demais experimentos foram feito com (i).

Houve também um atraso na queda da perda, como esperado

• AdamW com a mesma LR iria divergir mais rápido, logo cancelei (azul claro). Com menor LR, não trouxe ganhos em AUC ou acurácia geral, mas manteve a estabilidade citada anteriormente (laranja). Usar uma LR base menor ainda (1e-6) manteve a estabilidade, mas piorou os valores (preto).

• O primeiro experimento foi refeito com diferentes taxas de aprendizado inicial e final para o warmup e cooldown: rosa e cinza. Mesmos resultados. Os experimentos em roxo e em azul possuem a mesma diferença, logo resultados equivalentes. Diferença notável está na perda de validação, mas, considerando a tendência da acurácia e AUC, penso que não vale explorar.

[vitalwarley]

A diferença entre os experimentos preto e laranja foram

-model.init_args.lr: 1.0e-05
+model.init_args.lr: 1.0e-06 # preto

Os hparams de ambos experimentos (exceto por lr, que mudou)

flags:
  ckpt_path: null
  data.class_path: datasets.facornet.FaCoRNetDataModule
  data.init_args.batch_size: 20
  data.init_args.root_dir: data/facornet
  model.class_path: models.facornet.FaCoRNetLightning
  model.init_args.adamw_beta1: 0.9
  model.init_args.adamw_beta2: 0.999
  model.init_args.cooldown: 400
  model.init_args.end_lr: 1.0e-11
  model.init_args.lr: 1.0e-06
  model.init_args.lr_factor: 0.75
  model.init_args.lr_steps: 8 14 25 35 40 50 60
  model.init_args.model.class_path: models.facornet.FaCoR
  model.init_args.momentum: 0.9
  model.init_args.optimizer: AdamW
  model.init_args.scheduler: multistep
  model.init_args.start_lr: 1.0e-11
  model.init_args.threshold: null
  model.init_args.warmup: 200
  model.init_args.weight_decay: 0.0005
  seed_everything: 100
  trainer.accelerator: gpu
  trainer.callbacks: "'class_path: lightning.pytorch.callbacks.ModelCheckpoint\ninit_args:\n  auto_insert_metric_name:\
  \ false\n  dirpath: exp/checkpoints/\n  filename: '\"'\"'{epoch}-{loss/val:.3f}-{loss/train:.3f}-{auc:.6f}'\"\
  '\"'\n  mode: max\n  monitor: auc\n  save_last: true\n  save_top_k: 1\n  save_weights_only:\
  \ false\n  verbose: false' 'class_path: lightning.pytorch.callbacks.EarlyStopping\n\
  init_args:\n  mode: max\n  monitor: auc\n  patience: 10\n  verbose: false'"
  trainer.default_root_dir: exp/
  trainer.deterministic: yes
  trainer.fast_dev_run: no
  trainer.limit_train_batches: 50
  trainer.log_every_n_steps: 10
  trainer.max_epochs: 107
  trainer.num_sanity_val_steps: 1

[vitalwarley]

Em vermelho, um novo experimento com acumulação de gradientes. Tamanho efetivo do batch foi 50.

Melhorias

• Melhor modelo em acurácia e AUC, mesmo que pouco
• Menor erro de validação

[vitalwarley]

Tentei um experimento com classificação de família, apenas. Está abaixo em vermelho

• accuracy ainda remete à verificação de parentesco.
• loss/train, por outro lado, representa a entropia cruzada.

Em roxo, o experimento anterior com acumulo de gradientes. Em verde, temos baseline++ (o (i) amarelo aqui).

Tal esquema usa das features do backbone da AdaFace. Como podemos ver, a acurácia de classificação (accuracy/classification/family) tende a subir, embora as demais de parentesco, não muito.

[vitalwarley]

Avaliei esse modelo nos conjuntos de validação e teste do FaCoRNet. Consegui os seguintes resultados

╚═╡(research) [9:30] λ guild compare -Fl 'family clf' -cc 'run,.started,.label,.status,accuracy,auc,loss/val as loss,loss/test as loss,loss/train as loss,precision,recall,threshold' --table
run       started              label                                     status     accuracy  auc       loss       precision  recall    threshold
8e8f6db4  2024-05-04 09:23:34  family clf - FaCoRNet/FIW test            completed  0.749565  0.826672  11.220501  0.758466   0.733031  0.045308
c7f23b93  2024-05-04 09:13:07  family clf - FaCoRNet/FIW val thresh sel  completed  0.740151  0.814772  10.543639  0.753245   0.714299  0.045308
e4acb3be  2024-04-09 11:27:25  family clf - FaCoRNet/FIW train           completed  0.745999  0.811999  4.269999   0.776000   0.690999  0.051899

Mais que o #18, todavia ele parece ter usado o conjunto de validação, além de ter feito um alinhamento de face diferente do FaCoRNet. As métricas de treino foram em um conjunto de validação de seleção de modelo -- contém cerca de 4k pares, enquanto validação para seleção de limiar contém 100k pares e o conjunto de teste cerca de 40k.

[vitalwarley]

Continuei com experimentos de classificação de família em um esquema de multi-task, e até tentei outras perdas, como ArcFace e AdaFace (essa talvez estivesse mal implementada). Ambas sem sucesso. Sinto que não vale a pena continuar essa investigação.

Também tentei ajustes na lr via scheduler OneCycle, mas sem sucesso. Creio que ajustes na lr mudam apenas a demora em estabilizar o modelo. Também não continuarei esses experimentos.

Vou dar continuidade às estratégias citadas aqui.

[vitalwarley]

FaCoRNet + KinRace

O dataset KinRace tem apenas os 4 tipos principais: fd, fs, md, ms. Podemos ver que a acurácia e AUC é maior que os treinamentos no FIW tradicional, todavia isso é enviesado, dado as diferenças no conjunto de validação. Abaixo segue os resultados nos conjuntos de validação para seleção de limiar e de teste, ambos do FIW tradicional.

run       label                                   auc       accuracy  accuracy/bb  accuracy/ss  accuracy/sibs  accuracy/fd  accuracy/md  accuracy/fs  accuracy/ms  accuracy/gfgs  accuracy/gmgs  accuracy/gfgd  accuracy/gmgd
df026327  eval FaCoRNet on FIW test set           0.863032  0.778778  0.761355     0.791543     0.747510       0.756975     0.795373     0.820457     0.767288     0.685714       0.541899       0.778781       0.732342
bb62552b  eval FaCoRNet on FIW threshold val set  0.841344  0.765277  0.842565     0.806252     0.792515       0.746798     0.774944     0.781466     0.757552     0.557451       0.542796       0.551181       0.546918
a340ff12  baseline +(kinrace)                     0.883000  0.814999                                           0.800419     0.832769     0.828706     0.795880

Comparando com o meu baseline da FaCoRNet, temos

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.

...

Abaixo os resultados reportados pelos autores [da FaCoRNet] 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

Originally posted by @vitalwarley in #38 (comment)

O único report dos autores do KFC no FIW é esse abaixo

O treinamento que fiz não foi no esquema de multi-task para raça. Dessa forma, o comentário que fiz

... 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.

Originally posted by @vitalwarley in #38 (comment)

pode não ser a verdade, vide o experimento acima -- a maior quantidade de dados não tornou o modelo melhor no FIW.

[vitalwarley]

Como argumentei na reunião de ontem, apesar da maior quantidade de amostras de treino, o KinRace aparenta ser insuficiente no que tange a complexidade-variabilidade-diversidade das características de parentesco.

[vitalwarley]

KFC Full (multi-task + adversarial)

Resultados com código original abaixo. Há diferenças nos resultados que indicam potenciais diferenças no meu código.

Multi-task RACE (+ADV)

...

Originally posted by @vitalwarley in #52 (comment)

[vitalwarley]

guild compare ...

╚═╡(research) [9:53] λ guild compare 1:3 -cc '.label,auc,accuracy,accuracy/fd,accuracy/md,accuracy/fs,accuracy/ms,accuracy/val/race/mean as accuracy/race/mean,accuracy/val/race/std as accuracy/race/std,accuracy/test/race/mean as accuracy/race/mean,accuracy/test/race/std as accuracy/race/std,precision,recall,threshold' --table 

run       label              auc       accuracy  accuracy/fd  accuracy/md  accuracy/fs  accuracy/ms  accuracy/race/mean  accuracy/race/std  precision  recall    threshold
40a69816  eval KFC test set  0.906356  0.843989  0.825083     0.860181     0.867338     0.816649     0.621036            0.080411           0.815508   0.889010  0.076431
b479cb2b  eval KFC val set   0.903855  0.840909  0.831197     0.850757     0.848539     0.832503     0.585206            0.067311           0.812468   0.882939  0.076431
8d79fd1e  kfc full           0.860000  0.811999  0.811157     0.817685     0.831553     0.783306     0.699091            0.112297           0.760999   0.902000  0.041499

Consisderando os resultados acima e os que obtive com código original abaixo

*************
epoch 100
total_loss:1.681790
kinship_loss:0.057413
race_loss:1.624377
race margin:  [tensor(0.0765, grad_fn=<DivBackward0>), tensor(0.1486, grad_fn=<DivBackward0>), tensor(0.0209, grad_fn=<DivBackward0>), tensor(-0.1239, grad_fn=<DivBackward0>)]
auc is 0.866994
std is 0.033332
auc did not improve from 0.903749

➜  KFC git:(main) ✗ cat log_files/log_find.txt
auc :  0.8809779349594808
threshold : 0.08373381197452545

➜  KFC git:(main) ✗ cat log_files/log_test.txt
number of false negative pairs:  8055
false negative rate:  0.08803855990556758
number of false positive pairs:  10478
false positive rate:  0.11452117078715544
fd : 0.7729957088838849
md : 0.8245710256209355
fs : 0.8146399557653864
ms : 0.7698731501057082
avg : 0.797440269307277

Originally posted by @vitalwarley in #52 (comment)

eu creio que a diferença na acurácia por raça, bem como a média e o desvio padrão, são problemas menores, isso é, bugs na computação dessas métricas.

Segue a curva ROC referente ao treinamento exposto no comentário anterior com meu código

Não vejo como uma falha em reproduzir os resultados nos daria isso. O interessante desse gráfico é a cauda longa -- easy positives e hard negatives.

[vitalwarley]

Resultados do KFC no FIW

Abaixo os resultados do KFC (multi-task + adversarial) treinado no KinRace e avaliado dataset FIW (menores do que os resultados reportados pelos autores), bem como da estratégia FaCoRNet treinada no KinRace e também testada no FIW (postei acima).

run       label                                   auc       accuracy  accuracy/fd  accuracy/md  accuracy/fs  accuracy/ms  precision  recall    threshold
e112c645  eval KFC on FIW test set                0.855462  0.774878  0.740795     0.779682     0.808244     0.727600     0.772715   0.779436  0.139290
af0315bb  eval KFC on FIW threshold val set       0.839169  0.759072  0.742046     0.748319     0.765985     0.740611     0.754811   0.767434  0.139290
df026327  eval FaCoRNet on FIW test set           0.863032  0.778778  0.756975     0.795373     0.820457     0.767288     0.756589   0.822624  0.155246
bb62552b  eval FaCoRNet on FIW threshold val set  0.841344  0.765277  0.746798     0.774944     0.781466     0.757552     0.769625   0.757213  0.155246

[vitalwarley]

Não vejo como uma falha em reproduzir os resultados nos daria isso

De fato, avaliando as curvas do meu treinamento, consegui praticamente o mesmo AUC: 0.9014 na época 18 vs 0.903749 do código original -- incerto da época, mas olhando os gráficos do primeiro comentário aqui, parece ter sido bem no começo (e.g. 3a época) -- o que faz sentido quando notamos que originalmente os autores do KFC usaram 600 passos por época, pois 6 * 3 = 18.

Como o modelo salvo durante o treinamento é o melhor encontrado, as métricas de validação e teste estão corretas. Apenas as métricas de treino são enviesadas. Talvez seja útil inserir uma validação posterior ao treino do conjunto de validação de seleção do modelo, pois as métricas de treino apresentadas são sempre aquelas do último passo realizado.

[vitalwarley]

AUC e histograma de similaridades relativos à época 20, pouco depois da obtenção do melhor resultado

[vitalwarley]

FaCoRNet + KFCAttentionV2

Sobre KFCAttention

For our attention module in Figure 3, we refer to [31] and modify their structure to reach better accuracy. We first use average pooling to obtain channel features (s1, s2) from feature map (m1, m2) and then use 1x1 convolution layer to get feature vectors (s′1, s′2) to create attention map rather than only using one 1x1 convolution layer. This modification can not only improve the computational efficiency for downstream tasks but also allow for the interaction of different channels within a layer. Secondly, we make use of the effective attention impact of CBAM[40]. In the original method[31], they use two layers of 1x1 convolution to obtain feature vectors (c1, c2), however, we use CBAM[40] that contains channel and spatial attention, which focuses on the most relevant features of an input and generates more sophisticated features.

research/ours/models/attention.py

Lines 278 to 295 in 9f162c6

	class KFCAttentionV2(KFCAttention):
	def __init__(self):
	super().__init__()
	self.conv_concat = nn.Sequential(
	nn.Conv2d(in_channels=512 * 2, out_channels=512, kernel_size=1, stride=1, padding=0),
	nn.ReLU(),
	)
	def forward(self, embedding1, compact_feature1, embedding2, compact_feature2):
	concat_feature1, concat_feature2, x1, x2 = super().forward(
	embedding1, compact_feature1, embedding2, compact_feature2
	)
	# (B, 25600) -> (B, 2 * 512, 50)
	concat_feature = torch.cat([concat_feature1, concat_feature2], dim=1).view(-1, 2 * 512, 1, 1)
	# (B, 512, 50)
	concat_feature = self.conv_concat(concat_feature)
	return x1, x2, concat_feature.view(-1, 512, 50)

Denominei V2 porque modifiquei a implementação original. Isso é, para que fosse possível usar tal mecanismo na FaCoRNet, eu ajustei arbritariamente sua saída ao combinar f1 e f2 (concat_feature) com uma camada convolucional. Pretendo realizar outros testes.

Aproveitei para registrar o $\psi = \textbf{M}(\beta)/s$, onde $\beta$ é o mapa de atenção e $s$ um parâmetro de escala, definido na FaCoRNet como uma temperatura adaptável

• c83e426a, em azul claro, é o baseline. Note que a temperatura de facto começa em 0.08, mas vai caindo ao longo das épocas. Lembremo-nos que 0.08 foi almejado com base em Supervised Contrastive Learning #54; os autores da FaCoRNet definiram empiricamente s = 500 para que esse valor da temperatura fosse possível.
• 70597d24 e f9e959bb são experimentos com KFCAttention cujo $s$ é 250 e 125, respectivamente.

auc	accuracy	threshold

Não houve melhorias nas métricas.

[vitalwarley]

Tentei agora retornar o mapa de correlação (attention map na imagem do comentário acima), mas o valor da temperatura explode (com $s = 500$, temos $t > 500$).

research/ours/models/attention.py

Line 310 in 25c7343

correlation_map = self.compute_correlation_map(F1, F2)

E se usarmos um $\textbf{M}$ diferente da operação global sum pooling? Tanto M quanto s foram escolhidos meio que arbitrariamente... parecem mais "atrapalhar" a melhoria da arquitetura em si do que ajudar. Bom, food for thought.

[vitalwarley]

Note que a temperatura de facto começa em 0.08, mas vai caindo ao longo das épocas.

Algo que resolva isso? Ao passo que a temperatura cai, o modelo começa a estabilizar. Quem causa o que?

[vitalwarley]

FaCoRNet + ajustes na perda contrastiva

Na linha de buscar uma nova forma de computar a temperatura baseando-se no mapa de atenção, tentei um esquema sugerido pelo ChatGPT no contexto de entropia (que tenho ressalvas e confesso ter pouco entendido)

research/ours/losses.py

Lines 61 to 65 in a8dd2af

	class FaCoRContrastiveLossV2(FaCoRContrastiveLoss):
	def m(self, beta, epsilon=1e-6):
	beta = -(beta * (beta + epsilon).log()).sum(dim=[1, 2])
	return beta

O $\psi$, no entanto, não entra no intervalo desejado (0.08-1)

[vitalwarley]

onde o experimento amarelo é o novo, que usa um outro mapa de atenção

research/ours/models/attention.py

Line 177 in 08d7471

f1_2, f2_2, att_map0 = self.spatial_ca(x1_feat, x2_feat)

e o experimento azul é o meu baseline original (sem mods).

Interessante a perda de validação. Talvez pelo fato do $\psi$ ter sido constante? Usei a perda original da FaCoRNet

research/ours/losses.py

Lines 37 to 58 in 08d7471

	class FaCoRContrastiveLoss(torch.nn.Module):
	def __init__(self, s=500):
	super().__init__()
	self.s = s
	def m(self, beta):
	return (beta**2).sum([1, 2]) / self.s
	def forward(self, x1, x2, beta):
	m = 0.0
	x1x2 = torch.cat([x1, x2], dim=0)
	x2x1 = torch.cat([x2, x1], dim=0)
	beta = self.m(beta)
	beta = torch.cat([beta, beta]).reshape(-1)
	cosine_mat = torch.cosine_similarity(torch.unsqueeze(x1x2, dim=1), torch.unsqueeze(x1x2, dim=0), dim=2) / (
	beta + m
	)
	mask = 1.0 - torch.eye(2 * x1.size(0)).to(x1.device)
	numerators = torch.exp(torch.cosine_similarity(x1x2, x2x1, dim=1) / (beta + m))
	denominators = torch.sum(torch.exp(cosine_mat) * mask, dim=1)
	return -torch.mean(torch.log(numerators / denominators), dim=0)

todavia ajuste s para 12.5 em vez de 500.

Tal experimento também permitiu mais estabilidade nos demais tipos de parentesco

mesmo sem warmup na LR, algo que consegui aqui.

[vitalwarley]

O problema é que tal atenção tem um erro

research/ours/models/attention.py

Lines 99 to 100 in 08d7471

	# This is wrong: it inverts the attention
	energy_new = torch.max(energy, -1, keepdim=True)[0].expand_as(energy) - energy

Vou experimentar sem e avaliar.

[vitalwarley]

Corrigindo o erro e executando amarelo novamente, nada muda. Nem o baseline com a correção. O que muda é a estabilidade do treino, mas olhando aqui, isso pode ter sido causado pelo total de batches por época -- atualmente 100, na época 50.

[vitalwarley]

A diferença nos experimentos com mapa de atenção provindo do CA é apenas na perda

Abaixo do experimento azul (CA corrigido), há um cinza, que é o amarelo acima. Ou seja, o gradiente muda, logo a perda. Isso fica mais claro ao observarmos o $\psi$ ao longo do treinamento

[vitalwarley]

Tentei combinar os dois maps de atenção (canal e espacial)

research/ours/losses.py

Lines 111 to 119 in 56c444d

	class FaCoRContrastiveLossV7(FaCoRContrastiveLoss):
	def m(self, betas):
	beta_0, beta_1 = betas
	beta_0 = (beta_0**2).sum([1, 2]) / self.s
	beta_1 = (beta_1**2).sum([1, 2]) / self.s
	beta = beta_0 + beta_1 # / 2
	return beta

[vitalwarley]

Comparativo entre os módulos de atenção: FaCoR vs KFC

run       started              time     label                                                                                                       status      model                    attention                        accuracy  auc       loss/train  loss/val  precision  recall    threshold
8f964af2  2024-04-24 12:04:58  0:18:54  baseline - FaCoRNetKFCV2, FaCoRV4, FaCoRAttention, ContrastiveLossV2 -- backbone embeddings for similarity  completed   models.facornet.FaCoRV4  models.attention.FaCoRAttention  0.788999  0.861999  0.848999    3.930000  0.768000   0.828999  0.059200
28925bde  2024-04-23 12:39:09  0:29:01  baseline - FaCoRNetKFCV2, KFCV4, KFCAttention, ContrastiveLossV2 -- backbone embeddings for similarity      completed   models.kfc.KFCV4         models.attention.KFCAttention    0.744000  0.814999  0.043600    4.059999  0.759999   0.712999  0.042599
585613fe  2024-04-22 14:27:31  0:25:41  baseline - FaCoR, FaCoRAttention, ContrastiveLossV2                                                         completed   models.facornet.FaCoR    models.attention.FaCoRAttention  0.791000  0.862999  0.848999    3.930000  0.772000   0.824999  0.080700
131268af  2024-04-22 12:04:27  0:16:13  baseline - KFCV2, KFCAttention, ContrastiveLossV2                                                           completed   models.kfc.KFCV2         models.attention.KFCAttention    0.662000  0.717000  0.103000    4.0       0.671999   0.634999  -2.059999
68644994  2024-04-04 16:37:58  0:34:51  baseline @ arch-rog-strix                                                                                   completed   models.facornet.FaCoR                                     0.795000  0.865999  0.828999    5.320000  0.794000   0.796000  0.090199

• Consegui treinar KFC no FIW tanto com código original quanto com meu código (28925bde).
  • Resultados originais ~ 80% AUC. Todavia, após seu máximo na 3a época, foi decaindo e na época 44 obtive 66% de AUC. Treinamento foi interrompido.
  • Meus resultados foram ~ 82% AUC. Não houve instabilidade. Treinamento acabou naturalmente na época 20 com EarlyStopping(10) -- logo máximo alcançado foi na época 10.
    • Um experimento anterior e similar a este (131268af) teve o pior resultado com AUC ~ 77% na 3a época, mas que decaiu ao longo das épocas até 72% na 13a. Tal experimento continha um erro: métricas foram computadas usando as features de atenção, mas no KFC original foi usado as features do backbone. As features de atenção foram usadas apenas na perda contrastiva.
• Ao que tudo indica, o mecanismo de atenção da FaCoR é melhor (585613fe) do que o mecanismo de atenção do KFC (28925bde).
• Realizei também um experimento com FaCoR onde pudesse usar as embeddings do backbone para computar as métricas, tal como originalmente no KFC, mas nada mudou (8f964af2, o novo, vs 585613fe) significativamente.
• 131268af já é um experimento do KFC similar ao desse último do FaCoR (585613fe), no sentido de usa as features de atenção para as métricas.
  • Aparentemente as features de atenção não servem para computar as métricas no KFC.
• Todos perdem para o baseline (68644994), que contém o mecanismo Rel-Guide.

[vitalwarley]

Mecanismo de atenção é inútil para verificação de parentesco (task 1)?

Adicionei f357ed93 (amarelo), que não usa o mecanismo de atenção. Apenas a perda contrastiva, como #26, onde aqui a diferença é no backbone (AdaFace vs ArcFace). Não há diferença significativa aparente relativo ao 585613fe (azul), que contém o mecanismo de atenção.

De fato, a ablação feita pelos autores mostra uma melhoria bem sutil na tarefa 1: 1% de acurácia com uso do FaCoR e 0.3% de acurácia com a adição do Rel-Guide.

Apenas com a arquitetura completa (68644994, rosa) temos um ganho notável, mas vale salientar que as curvas representam o treinamento, enquanto a tabela anterior provavelmente apresenta os resultados no conjunto de teste.

[vitalwarley]

[3:4ae2435d]  facornet:train [marked]  2024-04-18 16:55:56  completed  baseline
[5:ece11c16]  facornet:train [marked]  2024-04-05 16:41:00  completed  baseline +(warmup, multistep, wd)
[6:68644994]  facornet:train [marked]  2024-04-04 16:37:58  completed  baseline @ arch-rog-strix

A única diferença aqui é que no experimento ece11c16 (roxo) temos um warmup, multistep lr e weight decay. Treinamento similar ao meu baseline original 68644994 (rosa). O experimento 4ae2435d (cinza) deveria ser similar a ambos, mas tem um comportamento estranho, especialmente na perda de validação. Vou avaliar novos experimentos similares...

---

O baseline original (6) é claramente pior nos diversos tipos de parentesco. Quanto aos outros dois, não há diferença significativa...?

---

[1:f357ed93]  facornet:train [marked]  2024-04-25 17:53:19  completed  baseline - FaCoRNetBasic, FaCoRV5, FaCoRAttentionDummy, ContrastiveLossV2 --
[2:585613fe]  facornet:train [marked]  2024-04-22 14:27:31  completed  baseline - FaCoR, FaCoRAttention, ContrastiveLossV2 - no rel-guide
[3:4ae2435d]  facornet:train [marked]  2024-04-18 16:55:56  completed  baseline

Temos aqui a reprodução da ablação feita pelos autores do FaCoRNet, todavia notamos que para mim não houve diferença significativa, especialmente entre 4ae2435d (cinza) e 585613fe (azul claro). f357ed93 em verde.

[vitalwarley]

Não houve diferença significativa nos experimentos que realizei ontem. Todos os baselines são equivalentes entre si. Nem relativo aos experimentos sem Rel-Guide e FaCoR há ganhos suficientemente notáveis. 585613feem rosa é o experimento sem Rel-Guide. f357ed93 em verde é o experimento sem FaCoR -- consequentemente, sem Rel-Guide. Os demais são baseline -- 4ae2435d o que fiz dia 18 é o azul claro, enquanto os demais fiz ontem. Esses novos baseline usaram scheduler=multistep e diferentes trainer.limit_train_batches, mas não houve impacto relevante. Esses não reproduziram a queda na perda de validação como o anterior do dia 18.

[vitalwarley]

KFC Full com módulo de atenção original do FaCoR

Foi preciso realizar algumas modificações na arquitetura, pois o mecanismo de perda do FaCoR original retorna apenas um dos mapas -- usei um customizado que retorna ambos os mapas. As modificações no KFC foram: Debias com menos unidades e duas camadas de projeção (uma para cada mapa de atenção).

research/ours/models/kfc.py

Lines 109 to 140 in 432488e

	class KFCFullV2(KFC):
	"""
	KFC wit FaCoRAttentionV3.
	"""
	def __init__(self, attention: nn.Module):
	super().__init__(attention)
	self.debias_layer = Debias(512) # Redefine the debias layer for the new attention model
	self.proj_atten1 = nn.Sequential(
	nn.Linear(512 * 512, 512),
	nn.ReLU(),
	)
	self.proj_atten2 = nn.Sequential(
	nn.Linear(49 * 49, 512),
	nn.ReLU(),
	)
	def forward(self, imgs):
	img1, img2 = imgs
	idx = [2, 1, 0]
	e1, compact_feature1 = self.encoder(img1[:, idx]) # each featur 16, 512x7x7
	e2, compact_feature2 = self.encoder(img2[:, idx])
	x1, x2, (atten_em1, atten_em2) = self.attention(e1, compact_feature1, e2, compact_feature2)
	reverse_em1, reverse_em2 = grad_reverse(e1, 1.0), grad_reverse(e2, 1.0)
	r1, r2 = self.task_race(reverse_em1), self.task_race(reverse_em2)
	atten_em1 = atten_em1.view(atten_em1.size(0), -1)
	atten_em2 = atten_em2.view(atten_em2.size(0), -1)
	atten_em1 = self.proj_atten1(atten_em1) # (B, 512, 512) -> (B, 512)
	atten_em2 = self.proj_atten2(atten_em2) # (B, 49, 49) -> (B, 49)
	biasmap, bias_pair = self.debias_layer(atten_em1, atten_em2)
	return r1, r2, e1, e2, x1, x2, biasmap, bias_pair

• atten_em1 é o mapa referente à atenção de canais
• atten_em2 é o mapa referente à atenção espacial

Os resultados não foram melhores -- azul (novo) vs amarelo (meu baseline)

[vitalwarley]

Esse baseline foi registrado em #74 (reply in thread). Lá mostro que minha reprodução foi relativamente satisfatória.

[vitalwarley]

Diferentes backbones

Procurei avaliar se backbones menores poderiam mitigar o sobreajuste, mas isso não aconteceu. Em todos os casos, a perda de validação começa a subir em intervalos de treino similares. Todos os novos experimentos são treinados em batches aleatórios, isso é, cada passo retorna um batch não sequencial, como originalmente feito pelos SOTA2021 -- SOTA2023 não fez assim.

[vitalwarley]

Treinamentos mais longos

Procurei avaliar se algo mudava em treinamentos um pouco mais longos (aumentei a paciência de 10 para 50). Também ajustei o uso do viés na amostragem do treinamento cinza. Sem tem viés, não há embaralhamento (shuffle). O treinamento em cinza não tem isso. O treinamento em rosa tem, mas como faz tempo, pode ter algo que o faça ser mais ou menos ruidoso. O treinamento em azul claro também tem, mas como é recente, tenho certeza do seu funcionamento. Interessante a estabilidade.

O viés é uma forma de garantir que cada batch contenha apenas um par positivo.

[vitalwarley]

Adição da perda de entropia cruzada (sem uso na otimização)

A ideia era confirmar uma hipótese que formulei a partir de experimentos esporádicos no contexto de transformação de atributos. Como precisei alterar a perda contrastiva, notei que a implementação provinda de #26 (bem como #50 e #51) estava errada para amostras de validação. Especificamente, não respeitava a definição que dizia que no numerador deviam existir apenas amostras positivas e no denominador apenas negativas.

Em verde o modelo FaCoRNet (AdaFace) sem o módulo de atenção e perda guiada. Em outras palavras, um experimento SOTA2021-like (vide #26). Como a perda de entropia cruzada binária desce continuamente (não continuou pois o experimento parou por conta de EarlyStopping com paciência 5 sobre AUC), podemos dizer que loss/val está enviesada pelo erro que comentei acima. Na prática não há diferença, todavia é uma importante informação no sentido de não ficar "preocupado" na razão para que houvesse sobreajuste, que claramente não há. Ainda assim, há uma convergência muito rápida -- o modelo não vê mais que 20% das amostras. Isso pode ser o problema no sentido de que o aprendizado não tenha sido generalista o suficiente.

[vitalwarley]

Adição da perda de entropia cruzada (com uso na otimização)

Resumo dos meus registros de pesquisa do dia 09/06 com ChatGPT

Examinando a Configuração do Experimento

1. Funções de Perda e Otimização:
   • Os experimentos envolvem adicionar a perda de entropia cruzada (CE) à perda contrastiva existente.
   • Diferentes fatores de perda ((\alpha)) são testados para combinar as perdas: 0,25, 0,5 e 0,75.
   • Os experimentos também testam o uso de ambas as perdas diretamente sem ponderação proporcional.
   • Otimizadores usados: SGD e AdamW.

loss = (1 - self.hparams.loss_factor) * contrastive_loss + self.hparams.loss_factor * family_loss    

2. Métricas de Desempenho:
   • Acurácia
   • Área Sob a Curva (AUC)
   • Precisão
   • Recall
   • Perda (treino/validação, treino/bce, validação/bce)

Analisando Resultados das Imagens Fornecidas

1. Imagem 1:
   • Comparação de diferentes fatores de perda para adição de CE à perda existente.
   • Observações:
     • Fatores de perda mais altos resultam em convergência mais lenta.
     • Acurácia e AUC mostram melhorias iniciais, mas podem estabilizar ou degradar com o tempo.
     • Precisão e recall flutuam mais com fatores de perda mais altos.

2. Imagem 2:
   • Adicionando o otimizador AdamW à mistura.
   • Observações:
     • AdamW mostra convergência mais rápida em comparação com o SGD.
     • Tendências semelhantes nas métricas de desempenho, mas ligeiras melhorias na estabilidade e nos valores finais.

3. Imagem 3:
   • Comparação mais detalhada com configurações variadas.
   • Observações:
     • Tendências consistentes em acurácia e AUC em diferentes configurações.
     • Os valores de perda indicam que algumas configurações estabilizam melhor, especialmente com AdamW.

4. Imagem 4:
   • Experimentos sem ponderação proporcional das perdas.
   • Observações:
     • Diferentes dinâmicas de convergência, algumas configurações mostrando melhor desempenho inicial, mas possível overfitting depois.
     • Métricas de perda fornecem insights sobre quais combinações são mais eficazes.

        if self.hparams.loss_factor:
            loss = (1 - self.hparams.loss_factor) * contrastive_loss + self.hparams.loss_factor * family_loss
        else:
            loss = contrastive_loss + family_loss

5. Imagem 5:
   • Comparação específica para SOTA2021 com 12 classes.
   • Observações:
     • Compromisso entre acurácia e AUC, onde maior acurácia às vezes leva a menor AUC.
     • Indica possível overfitting ou descalibração na classificação de pares positivos.

6. Imagem 6:
   • Experimentos de subconjuntos de "Understanding the behaviour of contrastive loss (2021)".
   • Observações:
     • Ajuda a entender como diferentes configurações se comportam em conjuntos de dados variados (por exemplo, CIFAR10, SVHN).
     • Métricas de uniformidade e tolerância fornecem insights sobre a distribuição de embeddings e consistência.

Próximos Passos

Ajustando Pesos das Perdas

• Testando Combinações de Pesos:
  • Usar diferentes valores de (\alpha) e (\beta) para a perda combinada: (\alpha * \text{con_loss} + \beta * \text{bce_loss}).

Experimentos com Camada de Projeção

• Configuração:
  • Introduzir uma camada de projeção como feito no SOTA2021.
  • Validar usando embeddings da camada anterior.

Transformação de Atributos

• Transformações:
  • Aplicar transformações de atributos apenas para a perda de CE.
  • Experimentar com transformações antes de aplicar as perdas e extrapolação positiva.

Análise de Subgrupos

• Experimentos com Subconjuntos:
  • Conduzir experimentos em subconjuntos como CIFAR10, CIFAR100, SVHN, ImageNet100.
  • Analisar uniformidade e tolerância para entender a dinâmica dos embeddings.

[vitalwarley]

Closes #81

Experiments:

1. Run ID: 12130393 - Batch Size and Gradient Accumulation (1)

   • Started: 2024-06-18 11:33:18
   • Color: Gray
   • Details:
     • Batch Size (bs): 10
     • Gradient Accumulation (grad_acc): 2

2. Run ID: f18f8b14 - Batch Size and Gradient Accumulation (2)

   • Started: 2024-06-18 11:41:43
   • Color: Light Blue
   • Details:
     • Gradient Accumulation (grad_acc): 1

3. Run ID: 19b7cef3 - Kinship Type per Batch

   • Started: 2024-06-18 11:55:14
   • Color: Dark Blue
   • Details:
     • Strategy: Process one type of kinship per batch

4. Run ID: fd7cf2f8 - Batch Size Adjustment

   • Started: 2024-06-18 12:03:11
   • Color: Green
   • Details:
     • Batch Size (bs): 11

5. Run ID: 9c08db3d - Projection Head Addition

   • Started: 2024-06-18 12:12:10
   • Color: Orange
   • Details:
     • Projection Head Dimension: 128

6. Run ID: 441a41d3 - Fusion Scheme Change

   • Started: 2024-06-18 13:00:41
   • Color: Purple
   • Details:
     • Revert Projection Head Initialization
     • New Fusion Scheme: Multihead Attention

7. Run ID: 26d7abed - Attention Output Adjustment

   • Started: 2024-06-18 13:16:11
   • Color: Pink
   • Details:
     • Change: Remove squeeze(0) from attn_output

8. Run ID: 292b707c - Sequence Dimension Addition

   • Started: 2024-06-18 13:23:48
   • Color: Yellow
   • Details:
     • Sequence Dimension: 1 (necessary for attention mechanism)

9. Run ID: ef315a79 - Attention Mechanism Update

   • Started: 2024-06-18 13:33:58
   • Color: Black
   • Details:
     • Update attention with layer norm and fully connected (fc) layer

[vitalwarley]

Experimento 0 (Baseline)

• RUN ID: f357ed93 - Cor: Azul Claro
• Descrição: Baseline com AdaFace.
• Resultados: Referência para comparação com outros experimentos.

Experimento 1

• RUN ID: db71e217 - Cor: Laranja
• Descrição: MLP 512 -> 128 sem ativação.
• Resultados: Ruins.

Experimento 2

• RUN ID: a6c6cdc1 - Cor: Roxo
• Descrição: Duas MLPs: 512 -> 256, ReLU, 256 -> 128. Treino e validação usam as últimas embeddings (128), tanto na perda quanto nas métricas.
• Resultados: Melhor que Experimento 1, mas ainda insatisfatório.

Experimento 3

• RUN ID: 12ded432 - Cor: Vermelho
• Descrição: Ajustei a computação das métricas para usar as features do backbone; mantive a computação da perda para as features projetadas.
• Resultados: Resultados mistos. Melhor desempenho que Experimento 2, mas com limitações.

Experimento 4

• RUN ID: 4f09912a - Cor: Amarelo
• Descrição: Experimento 3 com ArcFace.
• Resultados: Pior que o baseline.

Experimento 5

• RUN ID: 3110bf25 - Cor: Rosa
• Descrição: Experimento 3 com ArcFace, alterando FaCoRV7 e removendo BGR para RGB.
• Resultados: Melhorou um pouco no início, mas depois deu no mesmo que o anterior.

Experimento 6

• RUN ID: 0a478305 - Cor: Cinza
• Descrição: Experimento 3 com normalização prévia à perda.
• Resultados: Não mudou nada. Experimento cancelado.

Experimento 7

• RUN ID: cf81b007 - Cor: Verde
• Descrição: Baseline com ArcFace, removendo camada de projeção.
• Resultados: Próximo, mas pior que o AdaFace (baseline).

Experimento 8

• RUN ID: e5efa067 - Cor: Preto
• Descrição: Baseline com ArcFace, removendo camada de projeção, sem normalização.
• Resultados: Não mudou nada.

[vitalwarley]

Nos experimentos realizados, o baseline (RUN ID: f357ed93, cor azul claro) utilizou AdaFace como referência inicial. No Experimento 1 (RUN ID: db71e217, cor laranja), uma MLP 512 -> 128 sem ativação teve resultados ruins. O Experimento 2 (RUN ID: a6c6cdc1, cor roxa) com duas MLPs (512 -> 256, ReLU, 256 -> 128) melhorou um pouco, mas ainda insatisfatório. O Experimento 3 (RUN ID: 12ded432, cor vermelha) ajustou a computação das métricas para usar as features do backbone, mostrando resultados mistos, mas com melhor desempenho que os anteriores. No Experimento 4 (RUN ID: 4f09912a, cor amarela), a inclusão do ArcFace piorou os resultados. No Experimento 5 (RUN ID: 3110bf25, cor rosa), com ArcFace e ajustes de FaCoRV7 e remoção de BGR para RGB, houve uma leve melhora inicial, mas depois estabilizou. No Experimento 6 (RUN ID: 0a478305, cor cinza), a normalização prévia à perda não trouxe mudanças, levando ao cancelamento do experimento. No Experimento 7 (RUN ID: cf81b007, cor verde) e Experimento 8 (RUN ID: e5efa067, cor preta), a remoção da camada de projeção no ArcFace, com e sem normalização, não alterou significativamente os resultados. Insight: As modificações experimentadas não superaram o desempenho do baseline com AdaFace. A projeção das features não proporcionou melhorias consistentes, sugerindo que o foco deve estar em aprimorar diretamente as embeddings do backbone ou explorar outras arquiteturas e métodos de normalização.

[vitalwarley]

Experimentos - Supervised Contrastive Learning and Feature Fusion for Improved Kinship Verification (#80)

Experimento 1 - f8235ddb - Light blue

• Mas a partir do estágio 2. Sem pré-treino inicial. Apenas fusão e classificação. Não uso os mesmos hparams também. Arbitrariamente definindo rede de classificação, pois os autores deram poucos detalhes.
  • Resultados insatisfatórios. Nenhuma métrica aumenta. Perda de treino desce vagarosamente. Perda de validação parece querer subir.

Experimento 2 - 516a10fb - Light gray

• A partir do estágio 1 usando os pesos da run baseline f357ed93 temos uma alta performance (acurácia e auc iniciam altas, ~.80 e ~.85), mas ainda equivalente/menor ao baseline. Além disso, as perdas são iguais àquelas a partir do estágio 2 (f8235ddb). Algo errado?

Experimento 3 - 94b84733 - Purple

• Com AdamW (lr=1e-4), as métricas iniciaram para 0.55 em vez de 0.86. Cancelei.

Experimento 4 - aa8b9945 - Green

• Ainda com AdamW. Diminui lr para 1e-5. Esse começou entre o baseline e o experimento 2 listado acima(516a10fb). Logo em seguida caiu 20% em acurácia e AUC.

Experimento 5 - e0419ae1 - Orange

• Voltei ao SGD. Adicionei multistep LR. Parece que vai ser igual ao 2. Cancelei.

Experimento 6 - 80665a16 - Yellow

• Combinei 4 e 5, mas com AdamW. Começou em 0.8625 de AUC, maior de todos até agora, exceto do baseline. Mas igual ao 4, caiu logo em seguida, embora menos, uns 3%.

Experimento 7 - 753d730a - Pink

• Mesmo que o 6, mas lr=1e-6. Permaneceu em cima, quase passando do baseline. Ambas perdas de treino e validação descem e sobem, respectiva e lentamente. Após 6a época, parece que vai caindo em AUC e Acurácia.

Experimento 8 - 5a10400b - Red

• Mudei FF para MHA. Começa como E7, mas logo vai decaindo gradativamente.

Experimento 9 - cb797f99 - Blue

• Mudei MHA para CrossAttention entre as features.
  • Vai seguir o mesmo caminho do experimento 8. Interessante, no entanto, o aumento do RECALL enquanto PRECISION cai.

Experimento 10 - 37bbc9eb - Brown

• Mudei as features para serem aquelas da fusão inicial.
  • Comportamento similar à e0419ae1 e 516a10fb. AUC subiu um pouco, mas não vai muito além de 0.8625. Próximo também ao baseline f357ed93; mais estável relativo ao 753d730a, que decai a partir da época 7.

Observações

• A MLP de classificação pode ser melhorada:

self.fc1 = nn.Linear(1024, 512)
self.relu = nn.ReLU()
self.fc2 = nn.Linear(512, 1)

• Tudo indica que a chave do método proposto é de fato o sampler.
• Todos os experimentos tiveram loss/val indicando sobreajuste. Bom lembrar que aqui é BCE, logo essa indicação é real. Na verdade, apenas o experimento cb797f99 que teve queda na perda de validação; todavia, AUC e acurácia caíram ao longo do treinamento.

Próximo Experimento

• Baseline f357ed93 + Sampler.

Insights Adicionais

Insights adicionais

1. Balanceamento de Dados e Amostragem:

   • A chave para melhorar o desempenho parece estar no uso de um sampler eficaz. Implementar um sampler que equilibre melhor as amostras positivas e negativas pode ajudar a evitar o sobreajuste e melhorar a generalização do modelo.

2. Aprimoramento do Modelo de Classificação:

   • Melhorar a MLP de classificação, como indicado, pode aumentar a capacidade do modelo de aprender representações discriminativas. Adicionar mais camadas ou unidades, dropout para regularização, e experimentar diferentes funções de ativação podem ser passos úteis.

3. Ajuste de Hiperparâmetros:

   • A escolha do otimizador e a taxa de aprendizado são cruciais. Enquanto AdamW mostrou algum potencial, os experimentos indicam que uma taxa de aprendizado bem ajustada é essencial. Um scheduler mais agressivo ou uma abordagem cíclica pode estabilizar o treinamento.

4. Regularização e Normalização:

   • Introduzir técnicas de regularização como dropout, batch normalization ou layer normalization pode ajudar a estabilizar o treinamento e melhorar a robustez do modelo.

5. Exploração de Estruturas de Atenção:

   • Continuar explorando diferentes mecanismos de atenção, como o cross-attention, pode revelar novas formas de capturar relações complexas entre as features, melhorando assim a performance geral do modelo.

6. Aumento de Dados:

   • Aumentar a diversidade dos dados através de técnicas de data augmentation pode ajudar o modelo a generalizar melhor. Isso pode incluir variações de rotação, escala, cor, etc.

7. Transfer Learning e Fine-Tuning:

   • Utilizar modelos pré-treinados em grandes datasets e ajustá-los cuidadosamente ao problema específico de reconhecimento de parentesco pode fornecer uma base sólida, que, combinada com técnicas de atenção e fusão de features, pode melhorar significativamente os resultados.

Ao implementar esses ajustes e continuar experimentando com diferentes configurações, você pode encontrar uma combinação que maximize a performance do seu modelo para o reconhecimento visual de parentesco.

[vitalwarley]

Experimentos - Estágio 1 - Adição Sampler e Camada de Projeção - #80

• 585613fe, em rosa, é o baseline FaCoRNet, que é o aprendizado contrastivo com backbone AdaFace.
• 9ae61bff, em branco, é o baseline com sampler. Temos um claro ganho de performance: AUC = 0.8708 vs 0.8671 e ACC = 0.8037 vs 0.7973 relativo ao baseline acima. Melhores resultados de cada em épocas diferentes.
• d23748dd, em azul, temos a camada de projeção, cujos resultados são inferiores; talvez haja espaço para melhorias? Os autores não revelam muito aqui

a) Architecture: We use ArcFace100 [18] as the encoder f , a 2-layer MLP projection head g that maps facial represen- tations into a 128-dimensional space, and a 2-layer MLP for the binary classifier with sigmoid activation in the last layer. Both the projection head and classifier use ReLU as activation function in the hidden layer.

        self.fc1 = nn.Linear(512, 256)
        self.relu = nn.ReLU()
        self.fc2 = nn.Linear(256, 128)

onde a perda contrastiva as embeddings de 128D, enquanto que as métricas são feitas nas embeddings provindas do backbone (512D).

A diferença entre o experimento com sampler (9ae61bff) e o baseline (f357ed93) é apenas que o baseline não tem sampler e é treinado em 100 passos por época (biased=True). Por causa do sampler, esse novo experimento é otimizado em vários batches antes da validação ser feita.

Sobre os hiperparâmetros, o autor revela que

Hyperparameters: In the first stage, the model is optimized using SGD with a learning rate of 5×10−5, a weight decay of 10−4, a momentum of 0.9 and a temperature of 0.07. In the second stage, the classifier is trained with cross-entropy loss, optimized using Adam with a learning rate of 10−4. In both stages, we use a batch size of 32 as this is the limit accommodated by our setup.

Eu não segui à risca tais hiper-parâmetros e acredito que isso não importa tanto. Abaixo os valores do hparams efetivamente usados no 9ae61bff:

flags:
  ckpt_path: null
  data.class_path: datasets.sclff.SCLFFDataModule
  data.init_args.batch_size: 20
  data.init_args.root_dir: data/facornet
  model.init_args.loss.class_path: losses.ContrastiveLoss
  model.init_args.loss.init_args.beta: 0.08
  model.init_args.lr: 0.0001
  model.init_args.model.init_args.model: adaface_ir_101
  model.init_args.optimizer: SGD
  seed_everything: 100

Experimentos - Estágio 2 - Classificação de Parentesco - #80

Nos experimentos do estágio 2 eu mudei o otimizador e avaliei diferentes valores para lr, mas nada mudou significativamente. Em todos eles as embeddings do backbone ficaram praticamente com a mesma distribuição (em 06c0f11a eu defini a similaridade como 2 * torch.sigmoid(logits) - 1, por isso ficou concentrada em 0.2)

Em todos os casos houve finetuning dos pesos. O que o autor revela é

To evaluate our approach, we tried both freezing and finetuning the pre-trained encoder. Without any fine-tuning and with only 1250 steps of training, our method achieved a near state-of-the-art average accuracy and almost beats the previous best accuracy. This highlights the effectiveness of our feature extraction method in capturing discriminative information. By finetuning the model, we achieved a new state-of-the-art result in the FIW benchmark, with an average accuracy of 81.1% while only training for 1500 steps Fig. 3

O paper não dá detalhes sobre o treinamento do estágio 1. Quantas épocas, por exemplo? Apenas é dito quantos passos foram usados no estágio 2. A partir dos passos, pressuponho que poucas épocas foram usadas.

São quase 5000 relacionamentos possíveis, considerando o train.csv. Algumas amostras existentes no diretório estão fora do train.csv. Seria bom dispensá-lo, mas é importante na definição dos pares. Noutro momento, se oportuno, avalio os arquivos originais do dataset com as relações entre os indivíduos da família.

Bom, usando um batch de 20, temos 238 passos por época. Meu melhor experimento (9ae61bff) levou 4 épocas, menos que o reportado pelo autor (1250/1500 passos de 32 para 4777 amostras dá cerca de 8/10 épocas).

Realizei os experimentos do estágio 2, agora de classificação, com os pesos de 9ae61bff e d23748dd, mas tudo ruim. É possível que em nenhum desses eu acertei o código? Sim, mas não vou me apegar nisso agora. Fico satisfeito que o sampler funcionou e que a camada de projeção é, aparentemente, inútil. Vou focar em um próximo experimento, que é adicionar aumento de base em cima do 9ae61bff.

Data augmentation: For data augmentation, we use strong color jitter, random grayscale, and random horizontal flipping. This will create more variance in the data and help the model avoid overfitting and generalize better. In contrast to [17], we don’t use random cropping, thereby preserving the integrity of the faces and the alignment applied to them.

Essa referência 17 é o SimCLR

Ting Chen, Simon Kornblith, Mohammad Norouzi, and Geoffrey E. Hinton. A simple framework for contrastive learning of visual rep- resentations. CoRR, 2020.

Até onde lembro, o único SOTA que usou aumento de base foi o SOTA2020 (#24).

[vitalwarley]

Aumento de base + Sampler - #80

     augmentation_params:
       color_jitter:
         brightness: 0.5
         contrast: 0.5
         saturation: 0.5
         hue: 0.1
       random_grayscale_prob: 0.2
       random_horizontal_flip_prob: 0.5

O autor não especificou, logo defini valores arbitrariamente.

Em preto temos o novo experimento, relativo ao experimento anterior (9ae61bff), em branco, com apenas o sampler.

Tipo de Parentesco	Acurácia	Insight
Geral	Menor	A acurácia geral foi inferior, indicando uma possível necessidade de melhorias no modelo ou na abordagem geral utilizada.
fd (Father-Daughter)	Quase equivalente	O desempenho do modelo neste tipo de parentesco se manteve quase equivalente, sugerindo consistência.
fs (Father-Son)	Quase equivalente	Similar ao fd, o modelo teve um desempenho estável.
md (Mother-Daughter)	Quase equivalente	Consistência observada também neste tipo de parentesco.
ms (Mother-Son)	Quase equivalente	O modelo se mostrou estável para este tipo de parentesco.
bb (Brother-Brother)	Quase equivalente, embora menor no final	Apesar de uma leve queda ao final, o desempenho foi consistente na maior parte do tempo.
sibs (Siblings)	Quase equivalente, embora menor no final	O desempenho foi estável, mas com uma pequena diminuição ao final, sugerindo uma área de possível melhoria.
ss (Sister-Sister)	Quase equivalente	Estabilidade no desempenho do modelo para este tipo de parentesco.
gfgd (Grandfather-Granddaughter)	Drasticamente maior (~7%)	Acurácia significativamente maior, indicando um ponto forte do modelo para este tipo de parentesco.
gfgs (Grandfather-Grandson)	Maior (~3%)	Acurácia aumentada, sugerindo bom desempenho.
gmgd (Grandmother-Granddaughter)	Menor (~3%)	Acurácia levemente menor, indicando necessidade de atenção e possíveis ajustes.
gmgs (Grandmother-Grandson)	Menor no começo (~6%), depois um pouco maior (~3%)	Inicialmente menor, mas houve melhora ao longo do tempo, sugerindo que ajustes no modelo beneficiaram esse tipo de parentesco.

Esses resultados indicam áreas específicas de força e fraqueza no modelo de reconhecimento de parentesco, oferecendo pontos claros para possíveis melhorias e ajustes.

[vitalwarley]

Aumento de base + Sampler + Hard Contrastive Loss

• Sampler vem de Supervised Contrastive Learning and Feature Fusion for Improved Kinship Verification #80 (ver experimentos)
• Hard Contrastive Loss foi proposto em Understanding the Behaviour of Contrastive Loss #53

Se houvesse F1 score, o experimento 279536af seria aquele com maior valor. Note o equilíbrio entre precisão e cobertura. Abaixo os valores computados pelo ChatGPT -- não avaliei corretude, mas acho que está OK.

         run  f1_score
0   279536af  0.809077
1   9b947034  0.804223
2   d9c19e3c  0.801396
3   bf97a381  0.790271
4   bc431860  0.795898
5   18bcf6dc  0.791677
6   f1ef45fb  0.795898
7   42f0d22b  0.791677
8   16792909  0.792429
9   1bcfb733  0.794444
10  0d13151c  0.794444
11  c9de9f47  0.787461
12  41b359fc  0.790446
13  94d60fab  0.790446
14  4f911a1f  0.786428
15  74de3009  0.794049

Abaixo a tabela de resultados

run       operation       started              label                 status     model.init_…  beta  accuracy  auc       loss      precision  recall    threshold
279536af  facornet:train  2024-06-30 19:48:56  baseline - SOTA2021…  completed  0.8           0.2   0.804000  0.875999  2.099999  0.791000   0.828000  0.061700
9b947034  facornet:train  2024-06-30 19:19:03  baseline - SOTA2021…  completed  0.8           0.1   0.797999  0.870000  2.259999  0.779999   0.829999  0.057199
d9c19e3c  facornet:train  2024-06-30 18:49:08  baseline - SOTA2021…  completed  0.8           0.08  0.796000  0.867999  2.369999  0.779999   0.824000  0.058200
bf97a381  facornet:train  2024-06-30 14:00:39  baseline - SOTA2021…  completed  0.2           0.05  0.796999  0.867999  2.990000  0.814999   0.767000  0.081600
bc431860  facornet:train  2024-06-30 17:13:48  baseline - SOTA2021…  completed  0.4           0.08  0.792999  0.866999  2.680000  0.787000   0.805000  0.075699
18bcf6dc  facornet:train  2024-06-30 16:51:55  baseline - SOTA2021…  completed  0.4           0.05  0.796000  0.866999  2.970000  0.808000   0.776000  0.076200
f1ef45fb  facornet:train  2024-06-30 15:44:16  baseline - SOTA2021…  completed  0.4           0.08  0.792999  0.866999  2.680000  0.787000   0.805000  0.075699
42f0d22b  facornet:train  2024-06-30 15:23:33  baseline - SOTA2021…  completed  0.4           0.05  0.796000  0.866999  2.970000  0.808000   0.776000  0.076200
16792909  facornet:train  2024-06-30 18:21:16  baseline - SOTA2021…  completed  0.8           0.05  0.790000  0.865999  2.799999  0.785000   0.800000  0.059900
1bcfb733  facornet:train  2024-06-30 17:36:06  baseline - SOTA2021…  completed  0.4           0.1   0.788999  0.865000  2.650000  0.773999   0.815999  0.073600
0d13151c  facornet:train  2024-06-30 16:05:23  baseline - SOTA2021…  completed  0.4           0.1   0.788999  0.865000  2.650000  0.773999   0.815999  0.073600
c9de9f47  facornet:train  2024-06-30 14:21:16  baseline - SOTA2021…  completed  0.2           0.08  0.788999  0.864000  2.740000  0.792999   0.782000  0.088500
41b359fc  facornet:train  2024-06-30 17:57:43  baseline - SOTA2021…  completed  0.4           0.2   0.788999  0.861999  2.730000  0.783999   0.796999  0.101999
94d60fab  facornet:train  2024-06-30 16:27:32  baseline - SOTA2021…  completed  0.4           0.2   0.788999  0.861999  2.730000  0.783999   0.796999  0.101999
4f911a1f  facornet:train  2024-06-30 14:42:06  baseline - SOTA2021…  completed  0.2           0.1   0.783999  0.861000  2.720000  0.778999   0.794000  0.089400
74de3009  facornet:train  2024-06-30 15:02:49  baseline - SOTA2021…  completed  0.2           0.2   0.774999  0.851999  2.849999  0.731000   0.869000  0.069300

O melhor experimento é 279536af. Tem 0.6% de acurácia e AUC relativo ao segundo. Interessante notar a temperatura beta é 0.2, valor muito maior do que aquele que geralmente uso (0.08) -- isso, no entanto, é explicado no paper:

the hard contrastive loss usually generate more uniform embedding distribution, and it is beneficial to choose relative large temperatures.

Mais uniformidade, menos tolerância.

alpha é o hiper-parâmetro da perda e define quais amostras serão usadas. Um alpha = 0.8 indica que as amostras usadas são aquelas acima do 80o quantil das similaridades -- são de fato as difíceis daquele batch.

Ablação

• 279536af, em azul claro, é o experimento com Hard CL

Hard CL

CL

Considerações

1. Minha implementação está de fato correta? Os resultados indicam que sim, mas não está.
   1.1 Eu filtrei as amostras positivas difíceis também, mas não devia.
   1.2 Eu usei um alpha global, mas deve ser um alpha por amostra $x_i$

$$\mathcal{L}_{\text{hard}} \left( x_i \right) = -\log \frac{\exp \left( s_{i, i} / \tau \right) }{\sum_{s_{i, k} \geqslant s_\alpha^{(i)}} \exp \left( s_{i, k} / \tau \right) +\exp \left( s_{i, i} / \tau \right) }$$

2. Devo realizar o mesmo procedimento para as amostras positivas? Isso é, definir um alpha_neg e filtrar as fáceis positivas do batch?
3. Como combinar as ideias de Improving Contrastive Learning by Visualizing Feature Transformation? Isso é, transformar as features em busca de mais difíceis positivas e negativas? Está mais fácil agora, dado que eu ajustei a perda contrastiva recentemente para considerar as labels.

[vitalwarley]

Filtrar os positivos não funciona, pelo menos não da forma que fiz

research/ours/losses/scl.py

Lines 229 to 247 in 2916894

	# Select easy positives based on the alpha_positive quantile
	threshold_i_pos = torch.quantile(pos_sim_ij, self.alpha_pos, dim=0, keepdim=True)
	threshold_j_pos = torch.quantile(pos_sim_ji, self.alpha_pos, dim=0, keepdim=True)
	hard_pos_sim_ij = pos_sim_ij[pos_sim_ij <= threshold_i_pos]
	hard_pos_sim_ji = pos_sim_ji[pos_sim_ji <= threshold_j_pos]
	# Compute loss
	contrastive_loss = 0
	# TODO: is it right?
	for pos_sim_ij, pos_sim_ji in zip(hard_pos_sim_ij, hard_pos_sim_ji):
	loss_ij = -torch.log(pos_sim_ij / (pos_sim_ij + sum_hard_neg_sims_i))
	loss_ji = -torch.log(pos_sim_ji / (pos_sim_ji + sum_hard_neg_sims_j))
	contrastive_loss += (loss_ij + loss_ji).sum()
	contrastive_loss /= 2 * num_pairs # Average the loss over both directions

Em azul claro temos o baseline, sem filtragem dos positivos.

[vitalwarley]

Temperatura ajustável ao longo das épocas

Em azul temos o baseline -- similar ao 279536af que registrei antes, mas aqui temos uma correção da perda de validação, tal que lá dispensemos a filtragem de amostras. Lembre que sua temperatura é 0.2. Todos experimentos tem alpha de 0.8.

Note o painel temperature. Melhor experimento é o amarelo, cuja temperatura cresce de 0.1 a 0.3 logaritmicamente -- o treinamento parou cedo por causa da ausência de melhorias na AUC ao longo de 5 épocas.

[vitalwarley]

Transformação de Atributos - Extrapolação de Positivos

Inspirando-se na transformação de atributos (FT) proposta em Improving Contrastive Learning by Visualizing Feature Transformation, obtive alguns resultados interessantes e até um novo SOTA interno (meu melhor resultado em termos de acurácia até agora)

O baseline é o amarelo (6bd93c32). É o azul claro no comentário anterior, acima. O melhor resultado é o roxo (843e338a). Eu realizei transformação de atributos positivos. Especificamente,

    lambda_ = torch.distributions.Beta(alpha, alpha).sample().item()
    for i, j in positive_pairs:
        new_embedding_i = lambda_ * embeddings[i] + (1 - lambda_) * embeddings[j]
        new_embedding_j = lambda_ * embeddings[j] + (1 - lambda_) * embeddings[i]

Diferentemente do paper que cito acima, eu esqueci de adicionar + 1 ao lambda_, tal que seu intervalo fosse (1, 2). Esse intervalo é importante para que a similaridade desse novo par fosse menor do que o original, algo justificadamente necessário para o aprendizado. Ainda assim, quando corrigi o lambda_, obtive resultados piores, como mostrado no experimento laranja (d950c7ad)

É importante notar que nosso contexto aqui difere daquele apresentado no paper sobre FT. Lá temos autosupervisão, enquanto aqui temos supervisão. Nosso pares positivos são usados para criar também nosso pares negativos. Minha teoria para esses resultados é que, de alguma forma, manter lambda_ em (0, 1) é melhor no nosso contexto justamente porque tem alguma influência benéfica também nos pares negativos.

[vitalwarley]

CFLTPos - Contrastive Loss with Positive Feature Transformation

Exceto experimentos cinza (843e338a) e roxo (6bd93c32), ambos referenciados nos comentários anteriores, os demais foram experimentos com a perda contrastiva tradicional e transformação de atributos positivos tal como apresentado por Zhu et al. (2021) -- com + 1.

Aqui eu removi a soma + 1 da definição do lambda. As curvas de treinamento mostram resultados estáveis.

---

Vou voltar para HCL e explorar diferentes gamma sem a soma + 1. Deixarei também por mais épocas.

[vitalwarley]

HCL + Transformação de Atributos - Extrapolação de Positivos - Parte 2

Vou voltar para HCL e explorar diferentes gamma sem a soma + 1. Deixarei também por mais épocas.

É a continuação dos experimentos aqui. Em verde temos f05ce2f3, o mesmo experimento que 843e338a, só que com mais épocas. Interessante notar as perdas de treino e validação, que ainda não estabilizaram, todavia as métricas parecem ter convergido. Seria bom treinar por mais épocas ainda.