• 간단히 말해, Perceiver IO는 다양한 데이터 유형과 문제에 적용할 수 있는 유연하고 강력한 기계 학습 모델로, 기존 모델들의 한계를 극복하고자 하는 새로운 시도

abstract

• 위의 글은 기계 학습 분야의 한 연구에 대한 설명입니다. 이 연구의 핵심은 'Perceiver IO'라는 새로운 아키텍처를 개발한 것입니다. 이해를 돕기 위해 여기서 몇 가지 핵심 요소를 쉽게 설명해드리겠습니다.

1. 기계 학습의 목표:

• 기계 학습의 주요 목표 중 하나: 다양한 데이터 유형과 문제에 적용할 수 있는 범용적인 시스템을 만드는 것
• 이는 기계 학습 모델이 여러 상황에서 유용하게 활용될 수 있도록 하는 것을 의미

2. 기존 아키텍처의 한계:

• 현재의 기계 학습 모델들은 특정 도메인(예: 언어, 이미지 등)이나 특정 작업에 최적화되어 있어, 다른 종류의 데이터나 문제에는 잘 맞지 않는 경우가 많음
• 또한, 매우 큰 데이터셋을 처리하는 데에도 한계

3. Perceiver IO의 개발:

• 연구팀은 'Perceiver IO'라는 새로운 모델을 개발했습니다. 이 모델은 입력과 출력의 크기에 따라 확장 가능하며, 다양한 크기와 형태의 데이터를 처리할 수 있습니다. 이는 모델이 다양한 유형의 문제를 해결할 수 있게 해줍니다.

4. 유연한 질의 메커니즘:

• Perceiver IO는 유연한 '질의 메커니즘'을 도입했습니다.
• 이는 모델이 다양한 종류의 출력을 생성할 수 있게 해주며, 특정 작업에 대한 모델을 별도로 설계할 필요가 없게 만듭니다.

5. 다양한 작업에서의 성능:

• 이 아키텍처는 자연어 처리, 시각적 이해, 다중 작업 및 다중 모달 추론 등 다양한 영역에서 좋은 성능을 보여줍니다.
• 예를 들어, 'StarCraft II' 같은 복잡한 게임에서도 효과적으로 작동합니다.

6. 성능 평가:

• Perceiver IO는 입력을 토큰화하지 않음에도 불구하고, GLUE 언어 벤치마크에서는 BERT 같은 기존 Transformer 기반 모델보다 더 좋은 성능을 보였고, Sintel 광학 플로우 추정에서도 최고 수준의 성능을 달성했습니다.
• 이는 모델이 다양한 크기와 종류의 데이터를 효과적으로 처리할 수 있음을 의미합니다.
  ———-

Introduction

• 간단히 말해서, Perceiver IO는 기존의 제한적인 기계 학습 모델과 달리 다양한 유형의 데이터와 작업을 하나의 모델로 처리할 수 있는 강력하고 범용적인 아키텍처

1. 기계 학습의 현재 상황:

• 현재 많은 기계 학습 모델들은 특정한 작업에만 적합하고, 한 가지 유형의 데이터(예: 이미지, 언어)만 잘 처리할 수 있습니다.
• 이러한 모델들은 각각 다른 형태의 데이터를 처리하기 위해 서로 다른 방식을 사용하고, 이를 통합하기 위해 추가적인 네트워크를 필요로 합니다.

2. Perceiver IO의 목표:

• Perceiver IO는 이러한 문제를 해결하기 위해 만들어졌습니다.
• 목표는 하나의 아키텍처로 다양한 유형의 데이터와 다양한 종류의 작업을 처리할 수 있는 모델을 만드는 것입니다.

3. Perceiver의 기본 아이디어:

• Perceiver 아키텍처는 입력 데이터를 고정 크기의 '잠재 공간'으로 변환하는 데에 초점을 맞춥니다.
• 이 과정은 '어텐션'이라는 메커니즘을 사용합니다. 이 잠재 공간은 다양한 유형의 데이터를 동일하게 처리할 수 있게 해줍니다.

4. Perceiver IO의 발전:

• 원래 Perceiver는 간단한 출력(예: 분류)만 처리할 수 있었습니다. 그러나 Perceiver IO는 더 복잡한 출력도 처리할 수 있습니다.
• 예를 들어, 특정한 '쿼리'를 사용하여 다양한 크기와 형태의 출력을 생성할 수 있습니다. 이를 통해 모델은 다양한 작업을 수행할 수 있게 됩니다.

5. Perceiver IO의 장점:

• 이 아키텍처는 입력과 출력의 크기가 다양해도 잘 작동합니다.
• 또한, 특정한 유형의 데이터나 작업에만 제한되지 않고, 다양한 문제에 적용
• 이로 인해 모델의 범용성과 유연성이 크게 향상됩니다.

6. 성능: Perceiver IO는 다양한 벤치마크에서 우수한 성능을 보여주었습니다. 예를 들어, 언어 처리, 이미지 분류, 광학 플로우 추정 등 다양한 영역에서 좋은 결과를 얻었습니다. 또한, 다중 모달 데이터(예: 비디오와 오디오)를 함께 처리하는 데에도 효과적입니다.
   ————-

어떻게 navigation에 적용해볼까?

기존 SARL에서, 적용한 방식 회고

목표

• transformer은 sequence length(N, num_modality or unroll) 에 따라,
  • GPU 사용량이 증가하고,
  • GPU 메모리 사용량이 증가하고,
  • 계산시간도 증가(softmax 때문에)
• N을 줄일 수 있다면, 더 많은 sequence length를 (input 사용량 증가, unroll 증가)
  • GPU 사용량이 일정하고,
  • GPU 메모리 사용량이 일정하고,
  • 계산시간도 일정해짐.
• 학습시 기대 효과
  • (input 사용량 증가, unroll 증가)하더라도
    • GPU 사용량, GPU 메모리 사용량, 학습하는데 걸리는 시간 등을 유지가능
• inference 시 기대 효과
  • input 사용량 증가 하더라도,
    • GPU 사용량, GPU 메모리 사용량, inference time을 줄일 수 있음.

로직

• 원래는 query, key, value 모두 (b, u , num_modal, token_dim)으로 두고, attention 진행하는데,
• perceiver I/O 개념을 적용해서, query는 학습 가능한 parameter인 (b, u, num_latents, token_dim)으로 바꿔서 학습합니다.

---

어떻게 MARL에 적용해볼까?

• 기대 효과를 생각했을 때, 실험 시도가 큰 매력이 없어보임.

modality num을 증가시켰을 때, perceiver I/O를 쓴 경우와 안 쓴 경우의 경향성을 비교해보기

• 다른 input 넣어볼 종류가 있을까?
  • grid map?
  • 애초에, relative positions를 추가되므로, input이 많아짐.

perceiver I/O 안 쓴 경우

• modality number이 증가할수록, 성능이 증가하길 기대함.

agents_number을 증가시켜 보고, perceiver I/O를 쓴 경우와 안 쓴 경우의 경향성을 비교해보기