-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Research log #38
Comments
Sprint 15 (s. 20/10)Objetivos
Resultados
ObservaçõesPode 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)Apenas registrada. Será iniciada após outros experimentos serem realizados. Finalizada parcialmente. Falta sintetizar as anotações.
#43 (Matheus)
Sprint 21 (s. 01/12)Explorar separação das features dos pares positivos e negativos com t-SNE. Similar à #27 e #29. |
Na verdade há um engano aqui. No paper, temos
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 ( |
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
Dia 02
Dia 05
Dia 07
Sprint 22 (08/12 - 14/12)Dia 09
Dia 10
Dia 12
Dia 13
|
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). |
Nos últimos dias (13-23), atuei somente na #49. |
Ainda estudando #50. |
#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?). |
Criei #53 para ir mais a fundo na mecânica da perda, dado que os últimos SOTAs usam. |
Iniciei #53. |
Interessante, mas inacessível: Face recognition challenges due to aging: a review |
Comentando progresso incremental via leituras incrementais -- apenas li abstract, figures, tables, e conclusion até o momento. |
Creio que a #52 está finalizada porque consegui reproduzir o código, embora os resultados aparentem ser diferentes -- tanto localmente quanto na RIG2. |
Importante entender MixFair e a justificativa do debias term. Também investigar sobre mutual information. Ver #38 (comment). Também, considerando substituto da camada debias. |
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 #67 (comment). 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
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. |
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. |
Na última reunião (22/03/2024), apresentei os avanços recentes
O planejamento atual é continuar experimentando. Abaixo as linhas de possibilidades.
Penso que a mais interessante é a 2a, mas preciso avaliar como implementar. Em detalhes, além das issues anteriores, relembro aqui outras possibilidades
|
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
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. |
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.
|
Novos baselines considerando o código atual
Comparando ao baseline com código anterior
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.
|
A diferença em Não ajuda muito. Talvez um plot assim para cada tipo de parentesco seja melhor? |
Isso aqui é importante porque indica que o dataset é utilizado ineficazmente. |
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. |
É importante notar que multi-task learning possui várias estratégias de implementação. |
Experimentos recentesFaCoRNet + KinRace
KFC Full (multi-task + adversarial)
FaCoRNet + KFCAttentionV2
FaCoRNet + ajustes na perda contrastiva
|
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
Não lembro a intuição de chegar em co-atenção, mas estava lendo algo sobre gated fusion, se não me engano.
|
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
Adicionalmente, estudar os diferentes mecanismos de atenção é também importante, todavia no experimento #74 (reply in thread) não há diferença aparente com ou sem atenção... |
Adicionei mais detalhes #74 (reply in thread) 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
|
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... |
Resumo do meu resumo das duas últimas semanas com ChatGPT 2 de Maio de 2024
4 de Maio de 2024
6 de Maio de 2024
9 de Maio de 2024
10 de Maio de 2024
12 e 13 de Maio de 2024
|
Resumo dos meus registros do último mês com ChatGPT Categorias:
Estudo e Preparação de ApresentaçãoSemana 21 (20-26 Maio)
Semana 23 (03-09 Junho)
Semana 24 (10-16 Junho)
Implementação e ExperimentaçãoSemana 21 (20-26 Maio)
Semana 22 (27 Maio - 02 Junho)
Semana 23 (03-09 Junho)
Revisão SistemáticaSemana 24 (10-16 Junho)
Projeto de Pesquisa (PPGI058)Semana 23 (03-09 Junho)
|
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. |
Realizei #81 e documentei em #74 (comment). 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
|
Não reproduzi #80, mas tratei de iniciar experimentos associados. Documentei em #74 (comment).
Deu ruim. Ver experimentos 8 e 9.
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. |
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. |
Últimos experimentos
Esses dois últimos tiveram resultados insatisfatórios, especialmente o referente à #82. Avaliar-os-ei assim que oportuno. Próximos experimentos imediatos
Próximos estudos/experimentos posteriores
Adjust the temperature parameter Incorporate a mechanism to adjust the temperature 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)
Por exemplo, ajustar a temperatura a depender a dificuldade do par (baseando-se nesses dados demográficos). |
Não há filtragem das amostras positivas. As positivas vem de
Não há
|
Não funcionou. Posso ter errado a implementação, mas não focarei nisso agora. |
Houve resultados interessantes, mas nada grandioso -- um pouco acima do baseline.
Houve um resultado muito bom em termos de acurácia (~82%). Também abriu espaço uma discussão sobre transferência de métodos e técnicas usadas no contexto de self-supervision para supervision. Atualmente experimentando com perda CL tradicional (sem ser Hard) + FT (positivas). |
|
Estado da Arte em Verificação de ParentescoOntem reproduzi o melhor modelo até agora (f05ce2f3) nos conjuntos de validação e teste. Abaixo os resultados de treino (val. para seleção de modelo), validação (para seleção de limiar) e teste. Esses conjuntos de dados foram os mesmos da FaCoRNet.
Abaixo agregação dos últimos trabalhos de verificação de parentesco. Minha proposta atual está em segundo lugar em termos de acurácia média. Todavia, é importante lembrar que FaCoRNet é mais complexo (Contrastive + FaCoR + Rel-Guide) do que o meu (Sampler + HCLoss + Positive Feature Transformation). Além disso, computo o resultado em TODOS tipos de parentesco, o que acredito ser uma tarefa mais difícil.
Retirei as entradas dos trabalhos abaixo
Depois organizo melhor, referenciando cada um e os anos que foram publicados (#79). Por fim, ainda há experimentos a realizar sobre o método
|
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
The text was updated successfully, but these errors were encountered: