[111] Perceiver IO: A General Architecture for Structured Inputs & Outputs

paper

TL;DR

• I read this because.. : CS330 강의에서 언급됨. #118 에서도 Perceiver 사용했다고 해서 IO 붙은건 뭐가 다르지 하고 봄
• task : image classification, language modeling, optical flow, StarCraft II, …
• problem : 각각의 도메인 / 태스크에 대한 모델들이 각각 있음. 하나의 NN으로 처리하면 인생이 편할텐데
• idea : transformer encoder-decoder 구조인데 Perceiver구조(CA로 input modality가 들어가는 형태) + output query를 사용하자
• input : (encoder) N x D차원의 latent array (decoder) positional embedding or task embedding
• output : (encoder) context vector (decoder) class(for image classification), token id(for MLM), …
• architecture : 근데 encoder가 Perceiver 형태(텍스트, 이미지, 비디오등이 CA로 들어가는) / decoder는 encoder context vector랑 output query간의 CA만 있는
• objective : 각 태스크에 맞는 목표 함수
• baseline : GLUE(BERT), Image Classification(ViT-B), Optical Flow(PWCNet, RAFT), StarCraft(Transformer), AudioSet Classification(Perceiver IO)
• data : English Wikipedia + C4, ImageNet, JFT….
• result : GLUE에서 BERT랑 동일 FLOPS 대비 더 나은 성능. Optical flowㅂ도 베이스라인 대비 몇개 Metric 대비 좋은 성능. 나머지는 성능이 그럭저럭이지 best는 아님.
• contribution : 상당히 많은 modality에 대해 test. decoder에 task embedding / PE embedding을 넣는 방식이 contribution point가 아닌가?! 나머지는 막 새로운 느낌은 아닌듯
• etc. :

Details

Architecture

Output Queries

• 이미지 분류 같은 classification은 그냥 task embedding
• multi task인 경우 task embedding 들 여러개
• MLM의 경우 2048개의 Positional Embedding

아키텍쳐 세부

Result

• task들

• GLUE

introduction에서도 그렇고 UTF-8 byte로 한 걸 강조하는데 이것자체는 contribution인진 모르겠고(BBPE 같은 선행연구가 있으니?) 얘 때문에 max_len이 길어지는데 $$O(n**2)$$이 안되고 구조상 linear하게 복잡도가 늘어나는게 contribution인듯! 이 표에서도 그렇고 BERT보다 파라미터는 훨 큰데 FLOPS가 더 낮음. 파라미터는 hidden dim을 줄이고 Depth를 엄청 늘렸넹 이건 왜지 BERT랑 비교했을 때 max_len을 512 -> 2048로 늘렸고 vocab size는 256로 줄였다고 함.

• image classification

ViT-B/16와 비교했을 때 딱히 좋아보이진 않는뎅.. 일단 ViT보단 안좋은듯 성능 JFT pretraining 한게 86.4점인데 ViT-H/14의 88.6점이랑 차이가 좀 있어보인당(파라미터 수는 1/3이긴 함) 결국 최종적인 best 성능은 Conv 붙인 것도 좀 그럼 그 외 일단 전작 Perceiver보다 좋아졌다 정도 볼 수 있는듯?

• AudioSet Classification

• StarCraft II