DevHwi

Elasticseach 주요 용어

• Document : Elasticsearch가 저장하고 색인을 생성하는 JSON 형태의 데이터를 의미한다. 굳이 DB와 비교하면 Table의 각 row 개념이다.
• Index : 비슷한 Document를 모아놓은 단위이다. DB에서 Table과 대응된다.
• Shard : Index는 그 안의 document를 여러 shard로 분산 저장하여 고가용성을 보장한다. 원본 document는 primary shard에, 복제본은 replication shard에 저장된다.
• _id : Index 내 document에 부여하는 고윳값이다. 사용자가 직접 정해줄 수 있고, 정하지 않으면 Elasticsearch에서 중복되지 않도록 알아서 생성한다. 굳이 DB와 비교하면 primary key 개념이다. 
• Node : Elasticsarch process의 실행을 Node라고 한다. (일반적으로 서버에 1개 Elasticsearch process를 띄우기 때문에 1개 서버로 봐도 된다.) Node는 안에 여러 개의 shard를 가진다. 고가용성 보장을 위해, 같은 Node 안에 동일 shard의 primary 버전과 replication 버전을 두지 않는다. (죽으면 같이 죽어서 가용성 보장이 안되기 때문에) 
• Cluster : Elasticsearch의 서비스를 제공하는 하나의 묶음이다. 일반적으로 여러개의 Node를 묶어 1개의 Cluster를 구성한다. Node는 Cluster 내에서 각 기능을 가진다. (이것은 Cluster 형태의 데이터 구조의 공통점이기도 하다.) 

Elasticseach과 Lucene

• Elasticsearch는 Lucene을 기반으로 개발된 엔진이다.
• Elasticsearch를 아주 간단히 정의하면 Lucene의 기능을 추상화하고 사용하기 편하도록 구성해 놓은 검색엔진이라고도 할 수 있을 정도로 Lucene은 Elasticsearch의 핵심 라이브러리이다. 
• Elasticsearch에서 Lucence을 사용하는 방식은 다음과 같다.

[Lucene 동작]

1. Indexing

• 사용자가 Document를 JSON 형식으로 Elasticsearch에 요청하면, Elasticsearch는 이를 Analyze 하여 Token을 생성한다. 
• 이 과정에서 Elasticsearch는 Lucene의 Analyzer를 사용하여 텍스트를 분할하고, 이를 기반으로 Inverted Index를 생성한다. 

2. Flush 

• Elasticsearch는 Lucence에서 만들어낸 Inverted Index를 바로바로 디스크에 저장하는 것이 아닌, memory 상에 저장하고 있다가 주기적으로 디스크에 Flush 하는 방식을 사용하여 Indexing 속도를 향상한다.
• Flush는 RAM 버퍼 크기가 설정된 한도를 초과하였을 때나 특정 조건(document 수 초과)이 충족되었을 때, 명시적으로 호출(indexWriter.flush())했을 때 수행된다. 
• Flush까지 수행된 데이터에 대해 검색이 가능하다. 
• 여기서 용어를 주의해야 할 것은 Lucene의 Flush는 Elasticsearch에서 Refresh에 해당한다. (정확히 말하면 Elasticsearch Refresh 과정에서 Lucene의 Flush를 호출하는 것이다. Elasticsearch에서 Flush는 Lucene의 commit 과정을 포함한다.)

3. Commit

• Flush가 디스크 상에 데이터를 기록하지만, 데이터 저장을 완전하게 보장하지 않는다. 이는 Flush가 디스크에 데이터를 임시로 기록했기 때문이다. 
• Lucene은 주기적으로 fsync 시스템 콜을 통해, 페이지 캐시 내용과 디스크에 기록된 내용의 sync를 맞추는 작업을 수행한다.
• Commit까지 완료되면, 시스템 종료가 일어나도 데이터가 완전하게 저장되었음을 보장한다. 
• Lucene에서 Flush는 되었고, Commit 되지 않은 경우 시스템이 비정상 종료되거나, 내부 인덱스 구조의 재구성이 일어나는 경우 translog에 의해 복구되는데, translog에 기록이 남지 않는 경우에는 데이터가 유실된다.
• 일반적으로 Commit은 개발자의 명시적 호출(IndexWriter.commit())로 일어난다. 

* Traslog

- 변경사항을 바로 디스크에 반영하면 속도 이슈가 있기 때문에, 각 shard 내에서 변경사항을 기록하는 translog를 기록한다. 강제 종료 시, shard 복구 작업에서 translog에 적힌 내용을 기반으로 데이터를 복구한다. 

4. Segment

• Segment는 Lucenec이 데이터를 저장하는 가장 작은 단위의 Index 파일 묶음이다. 
• Commit까지 완료되어 디스크에 기록된 파일들은 Segment 단위로 검색된다.
• Segment는 불변의 데이터로 구성되어 있기 때문에, 새로운 document가 들어왔을 때는 새 segment가 생성되고, 기존 문서를 삭제하는 경우에는 실제 삭제를 하지 않고, Flag 표시만 해둔다. Update의 경우에는 삭제 Flag 처리를 해놓고, 새로운 Segment를 생성한다.
• Segment 개수는 불변이기 때문에, 계속 쌓이는 상황이 발생한다. Lucene에서는 무한정 늘어나는 현상을 방지하기 위해, 중간중간에 Segment 병합을 수행한다. 이때, GC처럼 삭제 플래그 데이터를 삭제한다.

5. Lucene Index

• 여러 segment들이 모여서 Lucene Index가 된다. 
• Lucene은 이 Index 내에서만 검색이 가능하다.
• Elasticsearch의 Index 개념은 Lucene의 Index 개념과 다른데, Lucene의 Index는 Elasticsearch에 Shard에 대응되고, Index 내에서 검색하였을 때, 각 shard(즉, Lucene의 Index)에서 각각 검색하여 나온 결과를 병합하여 결과를 만드는 구조이다. 이로 인해 분산처리가 가능하다.

ElasticSearch

• Elasticsearch는 2010년 Apache의 Lucene 라이브러리 기반으로 만들어진 분산 검색 엔진이다. 
• Elasticsearch는 JSON 기반의 문서를 저장하고, 색인하여 검색할 수 있도록 한다.  
• 데이터 시각화를 위한 도구인 Kibana와 데이터 수집 변환을 위한 Logstash, 경량 데이터 수집 플랫폼인 Beats와 함께 ELK 스택을 구성한다. 

ElasticSearch 특징

[검색 엔진]

• Inverted Index : 검색엔진이기 때문에 키워드 검색을 위한 Inverted Index를 사용하여 빠른 검색 속도의 이점을 가진다. 이때, Analyzer를 검색 요구사항에 맞게 미리 지정하여 구성할 수 있어, 다양한 검색 조건에서 유용하게 사용될 수 있다.

→ Inverted Indexing이 Elasticsearch을 쓰는 가장 큰 이유인 것 같다. 또한, Analyzer 구성의 자유도가 매우 높기 때문에 최근 LLM model의 feature 등을 저장하는 RAG 모델 구성 등에 vector DB로 많이 사용되는 것 같다. 

[Cluster 구성]

• 분산 처리 : Elasticsearch는 분산 처리를 지원한다. 일반적으로 검색 요청이 많은 시스템에서는 Elasticsearch를 여러 노드에 분산하여 성능 요구 사항을 맞춘다.
• High Availability : Cluster 내 일부 노드의 장애에도 복제본 데이터를 통해 서비스 중단 없이 운영 가능하다. 
• Scale out : Cluster 내 Node 수를 늘리고 싶을 때, Elasticsearch 설치만 하면, 데이터 복제 작업이 자동 수행된다.

→ DB 등에서 수평적 확장 시 H/W 단을 건들거나 Request 단을 바꿔야하는 귀찮음이 있는데 반해, Elasticsearch의 수평적 확장은 매우 간단했다. 

[Data]

• REST API를 통한 작업 요청 : Elasticsearch는 JSON 형태로 문서를 저장한다. Elasticsearch에 작업 요청을 보낼 때도 JSON 기반의 REST API를 사용하기 때문에, Client 단에 별도의 setup이 필요하지 않다. (REST API 호출만 하면 됨)
• Near Real-time Search : Elasticsearch는 데이터 Indexing 요청 후, 준실시간(1초 이내)의 검색이 가능하다. 
• Tracsaction 지원이 안됨 : RBMS와 다르게 Transaction 개념이 없다.

→ Elasticsearch가 RDBMS와 가장 구분되는 특징인 것 같다. RDBMS에서는 데이터 정합성과 테이블 간 관계성이 매우 중요하고 엄격한데 반해, Elasticsearch는 Transaction 개념도 없고, 데이터 Join에 유리하지 않다. 실시간성 보장이 안되면서 Transaction을 지원하지 않기 때문에, 데이터 정합성이 매우 중요한 데이터등에는 적합하지 않다. (데이터 작업 중 연속해서 Request를 여러 번 날리면, Return값이 각기 다를 수 있음)

ElasticSearch 라이선스

• Elasticsearch의 라이선스가 약간 복잡하고, 해석이 글마다 달라서 찾는 과정이 매우 복잡했다.
• Elasticsearch는 최초 Apache 2.0 라이선스를 사용한 오픈소스로 시작했지만, 2021년 Elastic 라이센스와 SSPL을 도입한 현재 라이센스 체계로 변경되었다.
• Elasticsearch의 라이선스는 크게 Elastic 라이센스와 SSPL로 구분된다.
  • Elastic 라이센스 : 개인 또는 기업이 내부적으로 Elasticsearch를 사용하는 것은 무료지만, 호스트형이나 관리형  형태로 상업적 사용은 제한된다. 여기서 상업적 사용 개념이 애매한데, 서비스에 읽기 전용 키바나 대시보드를 제공하거나, 서비스 내에서 검색 엔진으로 Elasticsearch를 제공하는 것은 문제가 되지 않으나, 사용자가 직접 API를 제어하는 형태로의 사용은 불가하다. (경계가 모호하다면 Elasticsearch에 직접 문의하는 것이 좋다.)
  • SSPL : Elasticsearch 소스코드를 이용한 파생 작업물을 서비스 형태로 제공하려면  파생 작업물 또한 SSPL 라이선스로 공개해야 한다. (이 부분은 AWS나 Google 같은 Cloud 업체에서 Elasticsearch에 자신들의 코드를 넣어 변현하여 서비스로 제공하여, Elasticsearch 구독에 악영향을 미치자 도입한 라이선스이다.)
• 정리하자면, 기업단에서 Cloud 형태 등으로 Elasticsearch를 변형하여 서비스로 판매하지 않는 이상 큰 라이선스 이슈는 없다. 하지만, Elasticsearch에서 제공하는 더 폭 넓은 기능을 사용하기 위해서는 유료 구독하는 것이 좋고, 라이센스 이슈가 문제가 될 것 같을 때는 유료 구독하거나, Apache 라이선스를 따르는 7.10 이전 버전을 사용하는 것이 좋다. 

Prefix-Tuning 배경 설명

• Prefix-Tuning은 NLP 모델의 fine-tuning 과정의 비효율을 해결하기 위해 발표된 방법론으로 2021년 ACL에서 발표되었다.
• Pretrained model 전체를 fine-tuning하지 말고, prompting에 착안한 소규모의 parameter 학습만으로 fine-tuning과 비견하는 좋은 성능을 보인다.

Abstract

• Fine-tuning은 대규모 데이터에서 학습한 pre-trained model을 down-stream task에서 활용할 수 있게 하여 좋은 성능을 낸다.
• 하지만, model의 모든 parameter를 바꾸기 때문에, 각 task마다 전체 parameter를 저장해놔야 한다.
• 이 논문에서는 prefix-tuning이라는 자연어 생성 task에서 fine-tuning 없이, model의 parameter를 고정하고도 적은 양의 prefix (continuous task-specific vector)만을 optimize 하여 사용할 수 있는 방법을 제시한다.
• Prefix-tuning에서는 prefix를 virtual token으로 대하여 prompting처럼 활용한다.
• 성능 실험을 위해, GPT-2에서 자연어 생성, BART에서 요약 작업을 테스트해 보았는데, 전체 parameter의 0.1% 만을 학습해도 fine-tuning과 비슷하거나, 일부 상황에서는 더 좋은 성능을 보인다. 

Introduction

[Fine-Tuning 방법]

• 대규모 pretrained model을 활용하여 원하는 각 task에 맞게 fine-tuning 하는 방법이 주류로 자리 잡았다.
• 하지만, fine-tuning 방법은 각 task마다, 전체 model의 parameter를 한 copy씩 저장하고 업데이트해야 한다는 문제가 있다. 특히, 언어모델의 parameter 수가 점점 커지면서, 더 큰 비용을 야기한다.

[Fine-Tuning 문제 해결]

• 이는 자연스럽게 fine-tuning 과정을 경량화하는 방법이 제기되었다. 
• 전체 parameter를 update 하는 것이 아닌, pretrained model을 고정해 놓고, 적은 양의 paramter만을 추가하여 model을 학습하는 방법이 등장하였다. (adapter-tuning)
• 이런 경향이 계속되어, GPT-3에서는 task-specific tuning 없이, user가 요청에 대한 몇 가지 sample을 같이 제공하는 in-context learning & prompting 같은 방법이 제시되었다.

[Prefix-Tuning]

• 이 논문에서는 prefix-tuning이라는 prompting에서 영감을 받은 방법을 제시한다.
• Prefix-tuning에서는 prefix라는 continuous task-specific vector를 input으로 같이 활용하여 "virtual token"의 기능을 할 수 있도록 한다.
• 이 virtual token은 실제 token과는 다른 개념으로 학습 가능한 parameter 만으로 구성되어 있다. 
• Prefix tuning에서는 각 task에 따라, 각기 다른 prefix만을 학습하면 되기 때문에, 적은 양의 parameter만 학습하면 되고, 이에 따른 overhead도 매우 적다.
• 또한, Fine-tuning과 달리 prefix tuning은 user에 따라 각기 다른 prefix를 관리하면 되기 때문에, 다른 user 간의 data가 섞여서 오염되는 현상이 발생하지 않는다. 따라서, 한 batch에서 여러 user와 task를 학습할 수 있어 효율적이다.

[실험]

• Prefix-tuning의 실험을 위해, GPT-2에서 table-to-text 생성과 BART에서 text 요약을 실험했다.
• 용량 관점에서 prefix-tuining은 fine-tuning에 비해 1000배 적은 parameter만을 사용했다.
• 성능 측면에서는 table-to-text에서는 fine-tuning과 거의 비슷한 성능을 보여주었고, text 요약에서는 약간의 성능 하락만 존재하였다. 
• 학습 때 보지 못한 주제들을 다루는 경우들에 대해서는 오히려 좋은 성능을 보이기도 했다. 

Prefix-Tuning

• Prefix Tuning은 prompting에서 영감을 받았기 때문에, prompting에 대한 이해가 필요하다.

[Intuition]

• Prompting은 언어모델에서 model parameter 수정 없이 적절한 context를 제공해 주면, 언어모델이 원하는 결과를 제공하도록 조종할 수 있는 방법이다.
• 예를 들어, "오바마"라는 단어를 생성하고 싶을 때, 언어모델에 "버락"이라는 단어를 input으로 주면, 그 단어 뒤에 나올 가장 확률 높은 단어 "오바마"를 출력하는 것과 같다.
• 이 개념을 확장하면, 자연어 생성 task에서 언어모델에 우리가 원하는 결과를 얻도록 조종할 수 있다. 
• 하지만, prompting에 문제가 있는데, 원하는 결과를 위한 context가 존재하는지에 대해 명확하지 않다. 
• 어떤 context가 결과를 낼 수도 있고, 결과를 못 낼 수 도 있다.
• Data를 활용한 optimization이 도움이 될 수 있지만, discrete optimization(token은 discrete 하기 때문)은 학습이 매우 어렵다.
• Discrete token을 이용한 optimize보다, 논문에서는 continuous word embedding 단에서 instruction을 optimize 하는 방법을 선택하였다.
• 이런 방법이 실제 단어와의 matching을 요하는 token 단에서 생성한 prompt보다 더 명확한 표현이 가능하다. 
• 이렇게 word embedding 단에서 instruction을 주는 방법보다, activation 단의 각 layer에서 guide를 제공하는 방법이 긴 범위의 dependency를 고려할 수 있기 때문에 효과적이다.
• 따라서, prefix-tuning에서는 모든 layer에서 prefix를 optimize 한다.

[Method]

• Prefix-tuning은 1) autoregresive LM에서 input으로 같이 제공, 2) encoder와 결과에 각각 같이 포함할 수 있다.

• Autoregressive model에서 model의 parameter는 아래와 같이 정해진다. 여기서, Pθ는 (prefix 길이) X (hi의 dimension)의 matrix로 초기화된다. 

• 학습의 목표는 fine-tuning과 동일하지만, 학습해야 할 parameter가 달라진다. LM의 ϕ는 고정 후, θ만 학습한다. 
• i가 prefix에 존재하면(prefix index 위치이면), hi는 Pθ의 값을 그대로 copy 하면 된다. 
• 만약, i가 prefix index에 포함되지 않는 경우에도, hi는 Pθ에 의존하게 된다. (prefix는 항상 입력값의 왼쪽에 붙기 때문에 오른쪽에 영향을 미치기 때문이다.→ 왼쪽에서 오른쪽으로 token이 처리되기 때문) 즉, i가 prefix index에 없더라도, prefix가 영향을 미치게 된다. 

[Parameterization of Pθ ]

• 경험적으로 Pθ parameter를 바로 update 하는 것은 불안정한 optimization을 이끌어 성능하락으로 이어진다.
• 따라서, Pθ matrix를 MLP layer들을 거쳐, reparametrize 한다. 이때, reparametrization의 결과로 나온 P'θ는 row 수는 유지하면서 (prefix length) 다른 column dimension을 가지도록 한다. (table-to-text는 512, summarization은 800)

실험 결과

[Table-to-text Generation]

• GPT-2 model 환경에서 E2E, WebNLG, DART dataset에서 실험했다.
• Pretrained model의 0.1%의 task-specific parameter를 사용하였다. 
• Prefix-tuning은 다른 lightweight tuning 방법보다 좋은 performance를 달성했고, fine-tuning에 버금가는 좋은 성능을 보였다.
• 공평한 비교를 위해, 동일 parameter 양(0.1%)을 사용한 adapter tuning과 비교해 봤을 때, dataset 당 평균 4.1 BLEU 성능 향상이 있는 것을 보였다.
• 더 많은 parameter 양(3%)을 사용한 adapter tuning이나 fine-tuning(100%)과 비교해도, prefix tuning은 거의 비슷하거나 좋은 성능을 보였다.
• 이것은 prefix tuning에서 학습한 parameter가 더 효과적으로 정보를 가지고 있음을 의미하는 것이다. 
• 추가적으로, DART에서 prefix-tuning의 좋은 성능ㅇ느 다양한 domain들과 넓은 범위의 관계들에서 prefix tuning의 효과성을 보여준다. 

[Summrization]

• Prefix-tuning은 0.1% parameter 추가만으로 fine tuning에 비해 약간만 낮은 ROUGE-L을 보인다.

Reference

LI, Xiang Lisa; LIANG, Percy. Prefix-tuning: Optimizing continuous prompts for generation. arXiv preprint arXiv:2101.00190, 2021.

GQA 배경 설명

• GQA는 2023년에 발표된 논문이다. 
• GQA는 llama 2에서 도입된 기술로 유명하다. 
• language model에서 transformer의 multi-head attention 구조 때문에,  inference 시간이 너무 오래 걸린다는 문제가 있었고, 이를 해결하기 위한 방법을 제시하였다. (사실, 전에 등장한 multi-query attention과 multi-head attention 방식의 절충안을 제시한 논문이다.)
• 최근에는 당연하게 받아들여져, 대규모 AI 모델에는 당연하게 사용된다고 한다. 

Abstract

• Multi-query attention(MQA)는 하나의 key-value head를 사용하여 decoder의 inference 시간을 줄인다.
• 하지만, MQA는 model 성능 하락이 일어날 수 있다.
• 이 논문에서는 기존의 multi-head 언어 모델의 checkpoint들을 MQA 기능을 갖춘 모델로 변경하는 방법을 제안하여, pre-training 과정의 5% 정도의 계산량만 사용하도록 한다. 
• 또한, grouped-query attention(GQA)라는 multi-query attention을 일반화하여 몇 개의 key-value head로 사용할 수 있는 개념을 소개한다.
• GQA는 multi-head attention의 성능에 필적하면서도, MQA에 비견될 수 있는 빠른 속도를 가진다.

Introduction

[문제]

• Autoregressive decoder의 inference에는 각 decoding step마다, attention key, value와 decoder weights를 memory에 load 해야 하기 때문에 memory bandwidth에 의한 overhead를 겪는다. 

→ Decoder의 문장을 생성할 때는 token 하나 하나를 생성하기 때문에, 그때마다 decoder의 weight와 attention 사이의 연산을 위해, memory 상에 올리는 과정을 겪는데, 이것이 문장 생성등에 속도 저하 요인이라는 것이다.

• 이런 memory bandwidth에 의한 속도 저하는 multi-query attention(MQA)이라는 query를 여러 개 사용하지만, 단일 key와 value head를 사용하는 방법에 의해 개선될 수 있다.
• 하지만, MQA를 사용하게 되면, 성능 저하와 학습 불안정성이 생기게 된다. 또한, 공개된(그 당시) 언어 모델들은 거의 모두 multi-head attention을 사용하여 학습했기 때문에, MQA를 사용하지 못한다.

[Contribution]

• 이 논문에서는 2가지 contribution을 주장한다.
  1. multi head attention(MHA)를 통해 학습된 언어 모델의 checkpoins를 최초 학습에 비해 적은 양의 연산만으로 MQA를 사용할 수 있도록 한다. 이로 인해, MHA의 좋은 성능을 유지하면서, 빠르게 inference 할 수 있도록 한다.
  2. grouped-query attention(GQA)라는 multi-head와 multi-query attention을 아우를 수 있도록 query head 당 key value 여러 개를 할당하는 방식을 소개한다. GQS는 multi head attention과 비슷한 성능을 내면서, multi-query attention처럼 빠른 속도를 가진다. 

Method

[Uptraining]

• multi-head model로 부터 multi-query를 생성하는 것은 2가지 과정을 거친다.
  1. checkpoint를 변경한다.
  2. 새로운 구조에 맞게 추가적인 pre-training을 진행한다.
• 우선, 아래 그림처럼, key, value head들을 mean pooling을 통해, 하나의 vector로 만든다. (단순 여러 개중 하나를 뽑는 당식이나, 처음부터 하나의 key, value를 하는 방식보다 좋은 성능을 가진다고 한다.)

• mean pooling을 진행하는 구조를 추가한 뒤, 전체 모델 중, α 비율만큼을 기존 pre-training과 동일한 방법으로 update 한다.

[Grouped-query attention]

• Grouped-query attention은 query head들을 G개의 group으로 나눈다. 
• 각 group들을 하나의 key head와 value head를 공유한다. 
• 일반화를 위해서 G개의 group으로 나눈 GQA를 GQA-G로 명명하는데, G=1일 때는 MQA와 동일하고, G=Head 수 일 때는 MHA와 동일하다.
•  multi-head attention 구조의 checkpoint를 GQA 방식으로 바꾸자 할 때는 group 내의 head들에 mean pooling 방식을 이용하여 Group 화하여 사용한다.
• 1~Head 개수 사이의 중간 값의 Group을 가지는 GQA는 MQA보다는 좋은 성능을 보이면서, MHA보다 빠르다.
• 이때, Group의 수를 적절히 설정하면, memory bandwidth를 넘지 않는 값을 선택할 수 있어, 속도도 MQA와 거의 비슷할 정도의 좋은 값을 가진다.

Experiments

[메인 실험]

• multi-head 구조인 T5 Large, T5 XXL로 실험하였다. uptraining을 위한 checkpoint는 공개된 T5의 checkpoint들을 사용했다.
• α 는 0.05를 사용했다. (parameter의 5%만 재 학습)
• 아래 그래프에서 볼 수 있듯, GQA를 사용한 모델은 MHA 방식에 비해 성능의 약간 하락이 있었지만, 속도가 매우 빠르고, 좋은 성능을 유지한다.  

[Sub 실험]

• multi-head 구조에서 group화 방식에 따른 성능 비교 : Mean pooling 방식이 group 내에서 첫 번째 head를 사용하거나, 초기화하여 재학습하는 방식보다 더 좋은 성능을 보인다.

• α에 따른 성능 비교 : 전체의 5% 정도만 재학습해도 좋은 성능을 유지한다.

• Group 개수에 따른 속도 비교 : group 수를 적게 하면 MQA 정도의 속도가 나온다(다만, 성능은 떨어질 것이다.)

Reference

Ainslie, Joshua, et al. "Gqa: Training generalized multi-query transformer models from multi-head checkpoints." arXiv preprint arXiv:2305.13245 (2023).

LoRA 배경 설명

• LoRA는 2021년 ICLR에 발표된 논문이다. 
• 당시에는 GPT2, GPT3 등 LLM을 혁신하는 모델들이 등장하고 있던 시기이지만, 새로운 downstream task 학습을 위해서는 pretrained model에 대한 fine-tuning이 필요하다는 고정관념(?)이 자리 잡고 있던 시기이다.
• 이 논문에서는 fine-tuning 과정에서 전체 parameter를 학습하는 것이 연산 cost가 매우 크다는 점을 지적하면서, 적은 양의 parameter 학습만으로 fine-tuning을 진행할 수 있는 방법을 제시한다.
• LLM들의 parameter가 비대해지면서 소규모 computing 자원에서는 거의 학습이 불가능했는데, 이 부분을 가능하게 만든 논문이기도 하다.
• 또한, 단순 LLM 뿐아니라, 모든 neural network에 적용되기 때문에, 다양한 분야에서 많이 사용되고 있는 논문이기도 하다. 

Abstract

• NLP 분야의 패러다임은 많은 양의 데이터에서 pretraining 한 후, 특정 task나 domain 처리를 위해 fine-tuning 하는 것이다.
• 하지만, Fine Tuning 과정에서 전체 모델을 다시 학습하는 것은 매우 비효율적이다. 
• 이 논문에서는 LoRA(Low-Rank Adaptaion)라는 pretrained model의 weight를 고정해 놓고, Transformer의 각 층에 학습 가능한 rank decomposition matrices를 추가하는 방법을 제시한다. 
• LoRA의 도입으로 인해, downstream task 학습 시, 학습 parameter 수를 매우 크게 줄일 수 있다. (GPT-3 기준 10000배) 
• LoRA는 매우 적은 학습 parameter와 추가적인 inference latency 없이도, 최신 LLM 모델과 비슷하거나 그 이상의 performance를 낸다. 

Introduction

[Fine-Tuning 방법의 문제]

• NLP 분야에서 많은 양의 데이터로 학습한 pre-trained model을 활용해, 다양한 task에서 fine-tuning하여 사용하는 방법이 많이 주로 사용된다.
• 하지만, Fine-tuning에는 단점이 존재하는데, task 별 학습을 위해, 매우 많은 양의 parameter를 학습해야한다는 것이다. (일반적으로 pre-trained model 전체를 활용하여 학습하기 때문에)
• 이 같은 문제는 LLM의 model parameter 수가 점점 많아지면서 더 크게 부각된다.

[parameter 일부를 학습하는 모델]

• 많은 연구들이 이를 완화하기 위해, downstream task 학습을 위해, 일부 parameter만 학습하거나, 추가적인 module을 달아서 학습하는 방법을 사용하기도 한다.
• 이런 방법들은 학습해야하는 parameter의 수를 크게 줄여, 학습의 속도 측면에서는 유리하지만, inference latency가 생기거나, model이 처리 가능한 sequence length를 줄이기도 한다.
• 특히, 이런 방법들은 model의 성능을 악화하는 단점이 존재한다.

[소개]

• 앞선 연구들에 영향을 받아, 논문에서는 model adaptation 과정에서 weight의 변화가 낮은 intrinsic rank를 가진다고 가정한다.(즉, fine-tuning  과정에서 weight 변화가 크게 복잡하지 않은 저 차원에서 변화이다.)
• LoRA는 pre-trained weight를 고정해놓고, weight 변화의 rank decomposition matrics를 최적화하여, 모델을 간접적으로 습한다. (즉, fine-tuning 과정에서 pretrained model의 weight를 직접적으로 건드리지 않고, rank decomposition matrics를 최적화하기 위한 학습을 진행하여, 간접 학습 효과를 내는 것)
• GPT-3의 경우 1~2 정도의 매우 낮은 rank를 통해서도 충분히 효과적이다. 

• LoRA는 몇가지 강점을 가진다.
  
  1. pre-traned model을 공유하면서 각기 다른 task를 위한 LoRA module을 만들 수 있다. 이로 인해, storage를 크게 절감할 수 있고, task 변경에 따른 overhead를 줄일 수 있다.
  2. LoRA는 효율적이고, 낮은 Hardware 환경에서도 동작한다. 전체 parameter의 gradient를 구할 필요 없이, 추가된 매우 적은 양의 low-rank matrices만 학습하면 되기 때문이다. 
  3. LoRA의 단순한 선형 디자인이 추가적인 inference latency 없이 동작가능하게 한다.
  4. LoRA는 기존 연구들과 연관성이 없어, prefix-tuning과 같은 기존 연구들과 쉽게 결합 가능하다.

기존 연구들

• Fine-tuning 과정에서 parameter 수를 절감하거나, 연산을 효율화하는 등, 학습 효율성을 향상하기 위한 연구는 기존에도 존재했었다. 
• 기존 연구들은 2가지 방향성으로 나눌수 있다. 1) adapter layer를 추가하거나,  2) input layer activations를 최적화하는 것이다. 
• 하지만, 두 방법 모두 한계가 존재한다. 

Adapter Layers Inference Latency

• Adapte를 구성하기 위한 다양한 방법이 존재했다.
• Transformer block 마다, 2개의 adapter layer들을 추가하는 방법, LayerNorm을 추가한 하나의 layer만 추가하는 방법들이 존재했다.(이러한 방법들은 추가 layer들이 들어, inference latency가 생긴다.)
• 한편, Layer를 pruning하여 연산을 줄여, adapter layer의 추가 연산을 우회하는 방법들이 존재했다. 이 방법들은 adaptation 과정에서 학습해야 하는 parameter의 수를 크게 줄였지만, 순차적으로 진행되어야 하기 때문에, 병렬을 활용하지 못해, 오히려 전체 처리 시간은 증가하게 된다.

Directly Optimizing the Prompt is Hard

• 다른 방향으로는 prefix tuning과 같은 방법이 있다. 
• prefixtuning은 optimize가 쉽지 않고, 학습에 따라 성능이 단조롭게 증가하지 않는다. (즉, 예측 or 컨트롤 불가능하다.)
• 보다 근본적으로, adaptation을 위한 sequence length로 인해, downstream task에서 사용 가능한 sequence length가 줄게된다. 이는 오히려 성능 하락으로 이어지기도 한다.

LoRA

Low-Rank Parametrized Update Matrices

• Neural Network는 matrix multiplication을 진행하는 많은 dense layer들을 포함한다.
• 이 layer들의 weight matrices는 일반적으로 full-rank를 가진다. 
• 특정 task에 adapting 할때, pre-trained language model들은 매우 낮은 "instrinsic dimension"을 가지고, 이로 인해, 작은 subsapce로 random projection을 하는 경우에도 효과적으로 학습 가능하다. (기존 논문 내용)
• 이에 영감을 받아, 논문에서는 adaptation 과정에서 weights를 학습하는 것도 낮은 "intrinsic rank"를 가진다고 가정한다.
• pre-trained weight matrix (W0, size : d X k)에 대해, low-rank decomposition을 통해 update를 제한한다. (rank는 min(d,k))
• 학습 과정에서 pretrained weight W0는 고정해 놓고, 학습 가능한 A(r X k), B(d X r) matrix의 곱을 더해준다. (weight의 변화를 저 차원의 B, A matric으로 표현하겠다.) 

• A와 B를 random Gaussian initialization, Zero initialization으로 초기화하여, 학습 초반에는 weight의 변화 값을 0으로 출발한다.  
• △Wx를 채 constant 값을 이용하여 scale 한다.
• optimizing에는 Adam을 이용한다. 

[A Generalization of Full Fine-tuning]

• Fine-tuning의 일반화된 버전은 pre-trained parameters의 일부를 학습하는 것을 포함한다. 
• LoRA는 adaptation 과정에서 weight matrices의 full-rank를 필요로 하지 않는다. LoRA를 모든 weight 행렬에 적용하고 biases를 훈련하면, LoRA의 rank를 미리 훈련된 가중치 rank와 맞춰 설정함으로써, 전체 fine-tuning의 표현력을 회복할 수 있다.
• 즉, LoRA의 학습 parameter의 수를 늘리면, fine-tuning 성능과 거의 수렴한다.

[No Additional Inference Latency]

• LoRA를 사용하면 연산 및 저장을 W= W0+BA를 통해 진행하고, inference는 평소처럼 진행할 수 있다. 
• 다른 task에 적용할 때는 weight에 BA를 빼서, pretrained model의. weight를 복구할 수 있다. 
• 매우 적은 memory overhead로 매우 빠른 연산을 통해 진행 가능하여, inference 과정에서 추가 latency가 거의 없다고 봐도 된다.

Applying LoRA to Transformers

• 이론적으로 LoRA는 neural network의 어느 weight subset에든 적용 가능하다.
• Transformer에는 self-attention module에 4개의 weight matrices(query, key, vector, output), MLP 단에 2개가 있다. 
• 간단하게 query, key, vector를 d X d의 single matrix로 처리한다.(실제로는 attention head로 나뉘어 있지만), 또한 단순화를 위해, downstream 작업에서 attention weight만 조정하고, MLP attention은 고정한다.

[Practical Benefits and Limitatiosn]

• 가장 큰 장점은 memory와 storage 사용을 절감한 것이다.
• large Transformer를 Adam으로 학습할 때, VRAM의 사용을 2/3까지 줄일 수 있었다. (GPT 3 기준 1.2TB → 350GB)
• 또한, r=4로 정하고, query와 value projection matrices만 adapt 했을 때, checkpoint size가 350GB에서 35MB로 10000배가량 줄었다. 
• 이는 학습 과정에서 적은 GPU를 사용하게 하고, I/O bottleneck을 줄이게 한다. 
• 또한, 다른 downstream task로 바꿀 때도, 단순 적은 양의 LoRA weights만 교체하면 되기 때문에 매우 효과적이다. 
• LoRA도 한계가 있는데, 다른 A와 B를 사용하는 입력을 단일 forward pass에서 처리하는 것이 간단하지 않다는 것이다. 하지만, 이것은 동적으로 LoRA 모듈을 선택해서 해결할 수 있다. 

실험 결과

[Model 성능]

• GLUE에서 RoBERTa와 DeBERT에 LoRA를 적용해 보았을 때, 적은 학습 parameter만으로 기존 adaptation 방법을 넘어 finetuning에 필적하거나 더 좋은 성능을 내는 것을 확인할 수 있다. (AdptH: transformer layer당 2개 layer 추가, AdptL : 1 MLP + Layernorm, AdptP: AdptL과 비슷, AdptD: AdapterDrop 방법, BitFit : Bias만 학습, LoRA는 query와 value weight에만 적용)

• GPT 기반 모델에서 Prefix-layer tuning(PreLayer)보다도 좋은 성능을 보인다. 

[학습 parameter ]

• accuracy와 학습해야 하는 parameter 수 관계를 보면, LoRA가 가장 효과적으로 적은 parameter 학습만으로 좋은 성능을 보임을 알 수 있다.

추가 실험

transformers에 어떤 weights에 LoRA를 적용해야 하는가?

• query와 key 중 하나만 LoRA를 적용했을 때는 낮은 성능을 보인다. query와 value 둘다에 적용했을 때가 좋은 성능을 보인다. 
• 아래 실험을 통해, query와 vector를 4 rank 정도만 사용해도 충분한 정보를 담고 있음을 보여준다. 

이상적인 r은 몇인가?

• r이 매우 작더라도 좋은 성능을 보인다. 이것은 adaptation 과정에서 weight matrix의 변화가 매우 저 차원에서도 표현 가능한 정도라는 것을 의미한다. 

Reference 

Hu, Edward J., et al. "Lora: Low-rank adaptation of large language models." arXiv preprint arXiv:2106.09685 (2021).

현재 fast api를 통해 개발 중인 코드가 있는데, 폐쇄망 내에서 빠른 적용 및 테스트를 위해, github action으로 배포를 자동화해 놓았다. 개발 환경은 nginx를 이용해 2개의 서버를 load balacing으로 묶어놓았고, 각각 서버에 github action runner를 돌려놓았다.

문제

• 아주 바보 같은 실수를 해버렸다. nginx restart를 한다는 것이 모르고 서버를 reboot 시켜버렸다.
• 하필이면, nginx가 구동 중인 서버를 종료시켰다. 서버가 reboot 된 후, nginx를 켜고, runner 동작을 위한 run.sh를 수행하였는데, 아래와 같은 문구가 뜨면서 runner가 동작하지 않았다.

The SSL connection could not be established, see inner exception.

해결 시도

• 우선 SSL 문구를 보고, 바로 인증서 or 방화벽을 의심했다. 하지만, git pull이 정상적으로 진행되었다. → 방화벽 문제 아님
• 그다음엔 인증서를 인식시키려 했다. 하지만, 동일 역할을 하는 다른 서버에는 인증서 관련해서 별도의 작업을 진행한 것이 없기 때문에, 인증서 문제도 아닌 것으로 생각되었다.
• 구글링 중, openssl의 버전 문제라는 글을 보았다. openssl 버전을 업그레이드했지만, 문제는 계속 발생했다.
• 그러다, github actions에서 사용을 위한 port를 찾아보게 되었다.

해결 방법

• 문제는 github actions가 사용할 port를 다른 서비스가 점유 중이어서 발생하는 문제였다. 나 같은 경우에는 nginx의 접근 port를 80으로 두었기 때문에, 충돌이 발생하여 꺼지는 문제였다.
• 이 문제는 nginx를 stop한 뒤, github actions runner를 돌리고, 다시 nginx를 start하니 해결되었다. (동일 port 사용)
• github actions config.sh나 run.sh 수행 당시에 해당 port가 점유되지 않으면 해결되는 문제이다. 만약, 사용 중인 port를 모른다면 netstat 명령어나, lsof 명령어를 이용하여 사용 중인 port를 확인 가능하다. 

netstat -tuln
sudo lsof -i -P -n | grep LISTEN

• 라고 생각했으나, 다음날 동일 현상이 발생하였다. 구글링 결과, github action 홈페이지에서 해답을 찾게 되었다. 보안상에는 TLS 인증을 남겨놓는게 좋지만, 불가피한 상황에서 이슈가 발생한다면 아래 명령어로 TLS 인증을 꺼놓으면 해결된다. 

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1

• 더 자세한 내용은 https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners?learn=hosting_your_own_runners&learnProduct=actions 을 참고 바란다.
• 당연히, 해당 명령어는 해당 터미널 세션에서만 유효하다. 추후 이슈 방지를 위해. bashrc(다른 shell을 사용한다면, shell 초기화 파일에)에 추가해 주는 것이 좋다.

echo 'export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1' >> ~/.bashrc
source ~/.bashrc

Layer Normalization 배경 설명

• Layer Normalization은 토론토 대학에서 2016년 발표한 논문이다.  Geoffrey E. Hinton이 저자로 포함되어 있다.
• CNN에서 BN이 주목을 받게 되면서, RNN에 적용 가능한 LN을 소개하였다.
• BN의 단점을 극복하는 것(RNN에 적용이 안된다는 점)이 논문의 시작이기 때문에 BN에 대해 먼저 알아야 한다.

2023.11.10 - [머신러닝] - Batch Normalization (Accelerating DeepNetwork Training by Reducing Internal Covariate Shift) 논문 리뷰

• 최근 유행하는 Transformer에 normalization 방법으로 거의 무조건 사용되기 때문에, 매우 중요한 논문이다. 

Abstract

• 딥러닝 학습을 위한 연산은 비용이 크다. 
• 이러한, 학습 시간을 줄이기 위한 방법으로 중간 layer의 결과들을 normalize 하는 방법이 있다.
• 최근에는 mini batch 내에서 mean과 variance를 이용하여 normalization 방법인 Batch Normalization(BN)이 널리 사용되고 있다. 이 방법은 학습 시간을 크게 줄여준다.
• 하지만, BN은 mini-batch 크기에 의존적이고, recurrent neural network에 적용 방법이 명확하지 않다. 
• 이 논문에서는 하나의 training 데이터 내에서 한 layer의 mean과 variance를 이용하여 normalization 하는 "Layer Normalization(LN)"을 소개한다. 
• BN처럼 normalization 후, activation 적용 전에 적용되는 bias와 gain을 이용한다. 
• BN과 다르게 LN은 training과 test time의 normalization 방법이 같다.
• 또한, LN은 각 time step에 따른 dependency가 없기 때문에, recurrent model에도 적용 가능하다. 

Introduction

[배경 - Batch Normalization]

• 딥러닝 학습이 점점 발전하고 있지만, 학습에 매우 긴 시간이 소요된다.
• 딥러닝 학습 속도를 향상하기 위해, 여러 머신을 사용한 병렬처리 등 여러 방법이 등장하고 있다.
• 그중 BN은 training data에 mean과 standard deviation을 이용한 normalization 방법을 적용하여, 학습 속도를 향상했다.

[BN의 문제]

• BN은 고정된 depth의 network에서 직관적이고 효과적이다. 하지만, RNN과 같은 길이가 달라지는 network에서는 time step마다 statistics가 달라지기 때문에 BN을 적용하기 어렵다. 
• 또한, BN은 batch size가 작은 경우에는 효과적이지 않았다.

[LN]

• 이 논문에서는 layer normalization이라는 간단하게 학습속도를 향상할 수 있는 normalization 방법을 소개한다. 
• BN과 다르게 summed input(residual connection이 더해진 값들 or RNN처럼 누적된 값들) 내에서 normalization을 진행하기 때문에, training set 들간의 의존성을 가지지 않는다. 
• LN을 사용하여 RNN에서 속도와 성능이 빨라진 것을 보인다. 

Layer Normalization

• BN의 단점을 극복하기 위한, LN을 소개한다.
• "covariate shift" 문제를 해결하기 위해, 각 layer의 mean과 variance를 이용한 normalization을 진행한다. 이를 위해, mean과 standart deviation을 아래와 같이 정의한다.  (H : hidden unit 수)

• 이렇게, mean과 shift를 정의하여 BN과 달라진 점은 LN에서는 동일 layer들이 동일 통계값을 보고, training set 들 간에는 서로 의존성이 존재하지 않는 것이다. 
• LN은 training set 간 의존성이 없기 때문에, batch size에 영향을 받지 않는다. (1도 가능하다.)

Layer normalized recurrent neural networks

• NLP에서는 training set마다 다른 길이를 가지는 경우가 흔하다. 이것은 RNN이 각 time-step마다 동일 weight를 공유하기 때문이다. 
• 하지만, BN을 RNN에 적용하려 할 때, 문제가 발생한다. 각 time step마다 별개의 statistics를 저장해 놔야 하기 때문이다. 특히, test set의 sequence 길이가 training set보다 길 때는 문제가 생긴다. (통계값이 없기 때문에)
• LN은 현재 time-step의 input에서만 normalization을 진행하기 때문에, 이러한 문제가 발생하지 않는다. 또한, 모든 time step에서 공유 가능한 하나의 셋의 gain과 bias를 가진다.
• RNN에서 LN을 위한 statistics는 다음과 같이 구해진다. (⊙: element-wise multiplication, b: bias, g: gain)

• RNN이 LN을 적용하면, 일반적 RNN에서 time-step 진행에 따라 값이 점점 커지거나, 점점 작아져서 발생하는 exploding or vanishing gradient 문제가 해결되어 안정적 학습이 가능하다.

(이 이미지는 group normalization 논문에서 가져온 이미지이다. group normalization 관련된 내용은 아래 글 참조 바란다.)

2024.03.28 - [머신러닝] - Group Normalization 논문 리뷰

Analysis

Invariance under weights and data transformations

• LN은 BN이나 WN(weight normalization)과 연관이 있다. 

[Weight re-scaling and re-centering]

• BN과 WN은 weight vector가 a만큼 scaling 되었을 때, mean과 standard deviation은 a만큼 scaling 된다. 
• scaling 전후의 normalization 값은 같기 때문에, BN과 WN은 weights의 re-scaling에 대해 불변하다.
• 하지만, LN은 single weight vector의 scaling에 따라 변한다. 
• LN은 전체 weight matrix의 scaling이니나, weight matrix 모든 원소들의 shift에 대해서 불변이다.

[Data re-scaling and re-centering]

• 모든 normalization 방법들은 데이터셋의 re-scaling에 대해 불변하다. 

Geometry of parameter space during learning

• 학습은 function이 같더라도 parameter에 따라 달라질 수 있다.
• 이 section에서 분석을 통해, normalization scalar σ가 implicit 하게 learning rate를 감소시키고, 학습을 더 안정적으로 만들 수 있다는 것을 확인한다.

Experimental results

• LN을 6개 RNN task에 적용해 보았다. (image-sentence ranking, QA, contextual language modeling, generative modeling, handwriting sequence generation, MNIST classification)
• LN의 기본 gain은 1, biases는 0으로 설정하였다. 

Order embeddings of images and language

• validation curve를 보았 을때, LN의 학습속도가 매우 빠른 것을 볼 수 있다. 
• 성능도 제일 좋다.

Skip-thoghts vectors

• skip-thoghts는 sentence representstions를 unsupervised로 학습하는 방법이다. 
• LN을 이용하였을 때, 속도 향상뿐 아니라, 성능면에서도 이점을 주는 것을 확인할 수 있다.(표에서 십자가 표시는 한 달 학습시킨 모델이다. - 오래 학습시켰을 때)

ETC

• RNN Model에서 효과를 보았다. 
• 하지만, CNN에서는 BN이 좋은 성능을 보였다. (input의 분포가 계속 바뀌기 때문에)

Reference

BA, Jimmy Lei; KIROS, Jamie Ryan; HINTON, Geoffrey E. Layer normalization. arXiv preprint arXiv:1607.06450, 2016.

총평

• 정말 간단하고, 직관적이고, 그다음 논문(Group Normalization)을 먼저 읽은 터라 쉽게 읽혔다. 
• 이런 기본적인 논문들은 아이디어가 너무 유명해져서, 논문 발표 당시 풀고자 했던 문제와 상황을 알지 못하는 경우가 많은데(논문으로 인해 이미 풀렸으므로), 당시 저자들이 어떤 생각과 문제에 집중했는지를 알게 되어, 꼭 읽어야겠다.

Group Normalization 배경 설명

• Group Normalization은 Kaming He가 저자로 포함된 ECCV 2018년 논문이다. 
• Computer vision 분야의 필수 component인 Batch Normalization의 한계와 그를 해결하기 위한 Group Normalization을 제시하고 있다.
• Batch Normalization 관련 내용은 아래를 참고 바란다!

2023.11.10 - [머신러닝] - Batch Normalization (Accelerating DeepNetwork Training by Reducing Internal Covariate Shift) 논문 리뷰

Abstract

• Batch Normalization(BN)은 딥러닝의 milestone 기술이 됐다. 
• 하지만, Batch 방향의 normalization은 batch size가 작아질수록 error가 커진다. 
• 이 논문에서는 BN을 대체할 수 있는 "Group Normalization(GN)"을 제안한다.
• GN은 channel 방향으로 그룹을 나눠, 각 그룹에 대해 normalization을 위한 mean과 variance를 구한다. 
• GN의 연산은 batch size에 독립적이어서, batch size가 변해도 accuracy가 안정적으로 유지된다. 
• ResNet-50을 이용한 ImageNet 학습에서 GN은 2 batch size의 BN에 비해 10.6%의 낮은 error율을 보였다. 
• 추가적으로 GN은 pre-training에서 fine-tuning으로 쉽게 전환 가능하다.
• COCO 데이터셋에서의 object detection과 segment 등에서 GN은 BN을 대체할 수 있음을 보였다.

Introduction

[배경 - BN의 한계]

• Batch Normalization은 딥러닝 분야에서 매우 중요한 component이다. 
• BN은 feature를 batch 단위로 mean과 variance를 이용한 normalize를 진행하여, optimize와 네트워크의 converge를 빠르게 해 준다. 
• BN의 이런 장점에도 불구하고, batch 방향의 normalize로 인한 특징이 존재한다. 예를 들어, batch size가 충분히 많아야 한다는 것이다.  적은 양의 batch는 batch statistics에 대한 부정확한 추정이 된다. 
• 따라서, BN의 사이즈가 작아지면, model error가 급격하게 증가한다. 
• 특히, model의 용량이 커서, 큰 batch를 가져가지 못하는, detection, segmentation, video recognition 등의 task들은 이 error에 더 치명적이다. 

 
[소개]

• 이 논문에서는 Group Normalization(GN) 이라는 BN의 간단한 대체 방법을 소개한다. 
• GN은 channel을 몇개의 group으로 나누고, 각 group에서 feature들을 normalize 한다. 
• GN은 batch dimension을 이용하지 않기 때문에, batch size 변화에 무관하다. 

 
[BN과 비교 실험]

• GN은 batch size에 매우 안정적이여서 , ImageNet 학습 ResNet-50 model의 2 batch size에서 BN을 적용한 것보다 10.6% 낮은 error를 보였다. 
• 일반적인 batch size에서도 GN은 BN과 error 0.5% 이내의 적은 차이를  보이며, 다른 normalize 방법을 압도할 정도로 좋은 성능을 보인다. 
• batch size가 변하더라도 GN은 pre-training, fine-tuning task에서도 자연스럽게 적용된다. 
• GN은 OD, segmentation, video classification 등에서 BN의 좋은 대체가 될 수 있음을 보인다. 

 
[다른 BN 대체들과 비교 실험]

• Layer Normalization, Instance Normalization과 같은 방법들은 논문과 비슷하게 batch dimension의 normalization을 피했다. 
• 이런 방법들은 RNN/LSTM 같은 sequential model이나, GAN과 같은 generative model에는 효과적이나, visual recognition에서는 한계가 있음을 보였다. 
• 반면에 GN은 visual recognition 성능도 좋으면서, sequential model과 generative model에 사용 가능하다. 

Group Normalization

• visual feature에서 channel은 각기 독립적이다. 
• SIFT, HOG, GIST 같은 전통적 feature들은 group 단위의 histogram 등을 통해 만들어지고, 이러한 feature들은 group 단위의 normalization 등에 사용된다. VLAD나 Fisher Vector도 group을 cluser에 대해 계산된 sub-vector로 생각될 수 있다.
• 높은 차원의 layer는 더 추상적이고, 직관적이지 않지만, 빈도, 모양, 조명, 질감과 같은 많은 정보들이 전통적 방법처럼 group화로 이어질 수 있다. 
• 이러한 특성과 인간의 시각 지각 시스템에서 영감을 받아, 딥러닝 네트워크를 위한 group-wise normalization을 제안한다.

Formulation

• 일반적인 feature normalization은 다음 식으로 정의된다. (x: feature, i: index) 

• 많은 종류의 feature normalization 방법들은 set(위의 식에서 S)를 어떻게 정의하느냐에 따라 달라진다. 
• Batch Norm(BN)은 set을 아래와 같이 정의한다. (C: channel)

• Layer Norm(LN)은 set을 아래와 같이 정의한다. (N : batch axis)

• Instant Norm(IN)은 set을 아래와 같이 정의한다.

• BN, LN, IN은 normalization 단계에서 소실된 표현력 복구를 위해, 아래와 같은 선형 변환을 진행한다.  (gamma: trainable scale param, beta: trainable shift param)

• Group Norm은 mean과 variance를 구하기 위한, set을 아래와 같이 정의한다. (G: group number - default 32)

• GN에서는 C(Channel) 방향의 C/G개의 Group 들에 대한 H, W 방향의 mean과 shift를 구한다. 

 
Relation to Prior Work

• LN, IN, GN은 모두 batch axis에 대해 independent하다. 
• GN의 극단적인 케이스를 각기 LN과 IN으로 볼 수 있다. 
• 우선 LN과의 관계를 보면, GN에서 group number를 1로 설정하였을때, LN이 된다. LN은 모든 channel을 동일한 역할을 한다고 본다. 
• 하지만, 이러한 가정은 FC에선 맞는데, convolution 연산에서는 틀릴 수 있다. GN은 LN보다 유연하여, 각 group에 각기 다른 distribution을 학습할 수 있다. 이것은 GN의 표현력이 LN보다 좋은 이유가 된다. 
• group number를 channel size로 설정하였을 때, GN은 IN이 된다. IN은 spatial dimension에만 의존하기 때문에, channel 간 관계를 사용할 수 있는 여지를 사용하지 못한다. 

 
Implementation

• GN은 pytorch나 tensorflow로 몇 개의 line만으로 쉽게 구현 가능하다.  (아래 Tensor flow 코드)

Experiments

• 실험 환경 : ImageNet 학습을 RseNet model로 비교하였다. GN의 group number는 32로 설정하였다. 

 
comparison of feature normalization methods

• 우선 일반적인 상황에서 실험을 위해 32개 batch size에서 실험하였다. 
• 이런 환경에서 알려진 것처럼 BN은 좋은 성능을 보였다. 
• LN과 IN등이 BN 방법보다 높은 validation set error율을 보이지만, GN은 0.5% 정도의 작은 error율 차이만 있다. 
• GN과 BN의 error율 차이는 GN이 BN의 regularization 역할을 조금 상실하기 때문이다. 이것은 GN에 적당한 regularizer를 달면 완화될 것이다. 

• Training set error율을 보면, GN이 더 작은 error율을 보임을 확인할 수 있는데, GN이 optimization이 더 쉽게 된다는 것을 의미한다. 

 
 
Small batch sizes

• BN이 stochasticity를 통한 장점을 갖지만, batch size가 작아지면 uncertainty가 높아지면서, error가 늘어난다. 
• batch size를 각각 32, 16, 8, 4,2 image로 학습을 진행했다. 
• GN은 batch size 변화에 대해 안정적인 분포를 보인다. GN은 batch size에 상관없이 거의 비슷한 curve를 보이는 것을 확인할 수 있다. 

• batch size가 2일 때는 GN은 24.1%의 error율로 34.7%의 BN보다 10.6%가량 낮은 error율을 보인다. 
• 이것은 batch mean, variance의 추정이 부정확하였다는 것이다. 

 
OD and Segmentation

• fine-tuning task에서도 비교해 보았다. 
• COCO에서 OD, segmentation 성능(Mask R-CNN, ResNet-50)은 다음과 같다. 

• COCO에서 OD, segmentation 성능(Mask R-CNN, ResNet-50 FPN)은 다음과 같다. 

Reference

WU, Yuxin; HE, Kaiming. Group normalization. In: Proceedings of the European conference on computer vision (ECCV). 2018. p. 3-19.
 
 

총평

• 사실 BN을 기계적으로 사용하다가, 최근 연구에서 다른 Normalization 기법들(LN, GN)을 사용하는 것을 보고, 이유를 찾아보기 시작했다.
• 그동안 이용에만 관심있었지, 왜 이런  normalization을 사용하는지 제대로 이해하고 가지 않은 것 같다. 
• Kaiming He가 저자로 들어간 논문은 아이디어가 매우 간단하고 직관적인데 임팩트가 큰 것 같다. 다시 한번 대단하다고 생각한다.