DevHwi

Mapping

• Elasticsearch에서는 index에 document 형태로 데이터들을 정의한다. 
• 이때, index(DB의 테이블에 해당)에 저장될 document(DB의 각 row에 해당)의 구조와 document 내의 field(DB의 테이블 칼럼에 해당)의 속성을 정의하는 설정을 mapping이라고 한다. 
• DB의 DDL의 개념과 유사하다.
• Mapping은 기본적으로 JSON 형식을 띤다. 
• GET [index 이름]/_setting의 결과 중 mappings 부분을 통해 mapping 정보를 확인할 수 있다. 

동적 Mapping, 명시적 Mapping

• Elasticsearch에서는 사용자가 정의하지 않은 mapping에 대해서 정보를 추론하여 자동으로 mapping해주는 동적 Mapping을 제공한다.
• 예를 들어, DB에서는 정의되지 않은 칼럼에 Insert를 하는 경우 에러가 뜨지만, Elasticsearch에서는 데이터 값을 토대로 형추론을 하여, 새로운 Field가 만들어진다. 
• 동적 mapping은 자동으로 지정해 줘서 편리하다는 장점이 있지만, mapping 정보 중 대다수가 처음 정의된 이후 변경이 불가능하기 때문에, 사용자가 직접 mapping 정보를 정의하는 명시적 mapping 방법을 사용하는 게 좋다.

Field

• Elasticsearch에서 각 Field에 지정할 수 있는 타입은 아래와 같다. 

※ object 타입과 nested 타입 비교

• object 타입과 nested 타입은 기본적으로 Field 안에 하위 Field를 저장할 수 있다는 점에서 비슷하지만, 요소 간의 관계를 유지하느냐 유지하지 않느냐에 따라 각각 nested 타입과 object 타입으로 분류된다. 
• 예를 들어, "person" : [{"name" : "minsu" , "age": 30}, {"name" : "bora" , "age": 29}]라는 데이터가 각각 object 타입과 nested 타입으로 저장되었을 때, elasticseach 검색 조건을 "name":"bora"면서, "age":30으로 찾았을 때, nested 타입에서는 실제 저장의도와 같게 검색이 되지 않지만, object 타입으로 저장하였을 때는 검색이 된다.
• 이것은 object 타입이 하위 Field 간 관계를 유지하지 않고, 각 하위 Field의 원소들을 List 형태로 평탄화 시켜 저장하기 때문이다.
• 따라서, 하위 Field에 대한 복수 조건이 많이 존재할 경우에는 nested 타입으로 저장해야한다. (상대적으로 무겁기 때문에 남용해서는 안된다.)

※ text 타입과 keyword 타입 비교

• 예를 들어, "나는 밥을 먹었다"라는 문장을 각각 text 타입과 keyword 타입에 넣으면, text 타입은 "나는", "밥을", "먹었다"로 역색인되어 저장될 것이고(analyzer마다 다르겠지만), keyword 타입은 "나는 밥을 먹었다"로 문장 그대로 저장될 것이다. 

_source Field

• 문서를 Elasticsearch에 저장하는 요청이 왔을 때, Elasticsearch에서는 문서의 원본 JSON 문서를 저장하는 데, 이 메타데이터 필드를 _source Filed라고 한다. 
• _source는 indexing 후에도 원본 상태(JSON 형태)를 유지하고, 쿼리 결과로 반환될 데이터를 제공한다.  예를 들어, "BaKe"라는 단어를 text 타입으로 저장하였을 때, "BAKE"로 anlyzer 처리 후 저장되겠지만, 실제 문서를 검색하면, "BaKe"라는 원본 상태로 조회된다.
• _source Field가 없으면, 데이터 자체를 조회하는 것이 불가하다.
• 만약, Indexing된 결과는 저장해야 하지만, 원본 문서를 디스크 용량상이나, 보안상(ex : 비밀번호 복호화된 것만 저장) 검색되지 원치 않는다면, _source에 저장되지 않도록 할 수 있다. (mapping - _source - enabled를 false로 PUT 호출)

EfficientViT 배경 설명

• EfficientViT는 2023년 발표된 논문이다. 
• ViT의 memory 효율성을 개선하기 위해, 샌드위치 구조의 레이아웃과 cascaded group attention을 도입한 EfficientViT model을 제안하였다.
• model 속도와 accuracy가 매우 좋다. 

Abstract

• ViT는 성능이 좋지만, 연산 비용이 너무 커서, 실사용에 문제가 있다.
• 이 논문에서는 EfficientViT라는 빠른 속도의 ViT 모델을 소개한다. 
• 기존 transformer 구조의 모델들이 memory를 효과적으로 사용하지 못하는 MHSA(Multi-Head Self-Attention)의 tensor reshaping이나 element-wise function으로 인해 제약이 있음을 발견했고, FFN 층들 사이에 MHSA를 배치하는 샌드위치 구조를 구성하여 memory 사용량을 줄였다. 
• 또한, head들의 attention map들 간에 비슷한 부분을 공유하여, 연산적으로 불필요한 부분이 많다는 것을 발견하였다. 이를 해결하기 위해, cascadede group attention module이라는 feature를 각기 다른 split들로 attention head를 통과시키는 구조를 제안했다. 이로 인해, 단순 연산의 단순함뿐 아니라, attention의 다양성도 향상했다. 
• 실험을 통해, EfficientVit는 기존 efficient model들에 비해 더 빠른 속도에서 좋은 성능을 보임을 증명했다.

Introduction

[배경]

• 기존 ViT model들은 computer vision 분야에서 좋은 성능을 보여주었지만, 성능 증가에 다라 model size 증가와 연산 overhead 증가로 인해, 실시간을 요하는 상황에서 사용하기 불안정하다. 
• 이를 해결하기 위해, 다양한 ViT 경량화 model들이  나왔지만,  model parameter와 Flop을 줄이는 방식을 사용했기에 속도에 대한 객관적 측정이 될 수 없고, 실제 inference throunput을 반영하지 못한다. (속도 향상이 model size 줄이는 것에 기인했는지, 방법에 기인했는지 객관적 판단 불가)

[논문-Analysis]

• 이를 해결하기 위해, 논문에서는 ViT를 빠르게 하기 위해 근본적으로 ViT를 어떻게 설계해야할지를 연구하였다.
• ViT inference speed에 영향을 미치는 3가지 요인인, memory access, computation redundancy, parameter usage 측면에서 살펴봤고, 그중, memory bound의 영향이 큰 것을 발견했다. 
• 즉, memory 접근이 GPU/CPU의 연산 활용을 막고, 속도에 부정적 영향을 미침을 발견했다. 
• memory가 비효율적으로 활용되는 연산들은 주로 multi-head self attention(MHSA)의 tensor reshaping과 element-wise function 연산에서 나타났다. 
• 논문에서는 MHSA와 FFN의 비율을 적절히 조정하여 성능을 유지하면서 memory 접근을 크게 줄였다. 
• 또한, 몇개의 attention head들이 서로 선형 관계를 갖기 때문에 attetion map에 불필요하다는 것을 발견하였다. 
• 이 현상을 각 head에 다양한 feature를 제공하는 방식을 활용하여, 완화시키고 연산 효율성도 가져갈 수 있다.
• 추가적으로 parameter 효율성을 향상하기 위해, structured pruning을 이용하여, 불필요한 parameter를 줄였다.

[EfficientViT]

• 논문에서는 앞선 연구를 바탕으로 "EfficientViT"를 제안한다.
• 특히, 샌드위치 구조의 레이아웃으로 모델을 만들어, MHSA와 FFN 사이에 하나의 memory bound만 두게 하여, 연산 속도를 향상했다.
• 또한, 새로운 cascaded group atention(CGA) 모듈을 제안하여, 연산 효율성을 향상했다. 
• CGA의 핵심 아이디어는 head에 각기 다른 feature를 input으로 준다는 것이다. (즉, Head 들간의 선형적 관계 등의 중복된 feature들이 연산에 비효율적이기 때문에 각기 다른 feature를 보도록 조정하겠다.)
• 마지막으로, network의 중요한 부분에 channel을 늘리는 등 parameter를 재조정하여, parameter 효율성을 향상한다. 

[실험]

• 기존 CNN과 ViT 기반의 lightweight 모델에 비해 빠르면서 성능이 좋다.

ViT 속도 연구

• ViT 효율성을 향상하기 위해, 3가지 측면(1.memory access 2.computation redundancy 3.parameter usage)에서 관찰하였다. 

Memory Efficiency

• Memory 접근으로 인한 ovehead는 model 속도에 매우 주요한 요인이다. 
• transformer의 연산 중, tensor reshaping, element-wise addition, normalization 등이 memory unit 사이들의 접근을 요해서, 시간이 오래 걸리게 된다. 
• 이 연산들을 조금 더 간단하게 바꾸기 위한 연구들이 있었으나, (softmax self-attention 간략화, sparse attention, low-rank approximation) 대게 성능 하락이 존재하고, 속도 향상에 한계가 있었다.
• 이 논문에서는 memory access를 줄이기 위해, memory-inefficient layer를 줄이는 방법을 사용한다. 
• 최근 연구들에서 memory에 비효율적인 부분은 FFN보다 MSHA에 주로 존재한다고 하였다. 하지만, 기존 ViT 구조에서는 두 layer들이 동일한 수를 유지하고 있다. 
• 논문에서 Swin-T, DeiT-T로 실험해 보았을 때, MSHA의 비율을 20~40%로 줄였을 때, 좋은 성능이 나오고, 속도로 각각 1.25배, 1.5배로 빨라졌음을 확인했다. (아래 그래프 참고)
• 즉, MSHA의 비율을 줄이는 것이 모델 성능과 속도 측면에서 모두 유리했다.

Computation Efficiency

• MHSA에서 attention map은 연산이 비싸지만, 그중 일부들은 꼭 필요 없다는 것이 알려져 있다.
• attention 간의 similarity를 재보았을 때, 매우 높은 similarity를 보였다. 
• 이것은 각 head들이 동일 feature에 대해서 비슷한 projection을 하기 때문에, 불필요한 연산들이 존재한다는 것을 의미한다. 
• 각 head들이 다른 pattern을 보이게 하기 위해, 각 head에 feature의 부분 부분을 쪼개어 각기 다른 feauture를 처리하도록 하는 방법을 사용했다. 이것은 group convolution과 비슷한 개념이다. 

Parameter Efficiency

• ViT는 NLP의 Transformer 구조를 그대로 가져왔기 때문에, Q, K, V의 구조를 따르고, FFN의 확장 비율을 4로 설정해 놓았다.
• Lightweight model에서는 이러한 구조를 재설계하는 방식을 따르는데, 이 논문에서도 Talylor structured pruning을 사용하여 중요 parameter만 남기도록 하였다. 
• 이 방법은 gradient와 weight의 곱을 channel 중요도로 정의하여, 중요하지 않은 channel을 제거하고, 가장 중요한 channel을 유지하는 방법을 사용한다. 
• 연구를 통해, 2가지 사실을 알 수 있는데, 첫 번째로, 첫 2 stage에서는 더 많은 dimension을 유지하지만, 마지막 단계에서는 훨씬 적은 dimension이 유진 된다. 두 번째로, Q, K 및 FFN dimension은 크게 축소되지만, V dimension은 거의 유지되고, 마지막 몇 개의 block에서만 감소한다.
• 이를 통해, 1) 기존 channel 구성 방식(FFN 확장 비율 :4)은 마지막 몇 개의 block에서 많은 중복을 초래한다. 2) Q, K는 V에 비해, 훨씬 많은 중복이 존재하고, V는 상대적으로 더 큰 dimension을 선호한다. 는 점을 유추할 수 있다.

EfficinetViT

EfficinetViT Building Block

• 아래 그림처럼 EfficientViT는 memory 효율적인 샌드위치 구조의 layout과 cascaded group attention을 사용했다. 

[Sandwich Layout]

• spatial mixing을 위해 self-attention layer를 중간에 두고, 이를 FFN layer가 양쪽에서 감싸는 형태로 구성하는 구조이다. 
• 이 설계로 인해, model 내, self-attention layer로 인한 memory 사용 및 처리 시간을 줄이고, FFN layer를 더 많이 활용하여 , 다양한 channel 간 연결을 효과적으로 수행되도록 한다.

[Cascaded Group Attention]

• MHSA에서 attention head의 중복성은 연산 효율성을 떨어뜨린다. 
• 이를 해결하기 위해, group convolution에서 영감 받아, ViT용 Cascaded Group  Attentin을 제안한다.
• 이는 각 head에 full feature를 나눈 서로 다른 부분을 입력으로 사용하여, attention 연산을 각 head에 분산시킨다.
• CGA는 각 head의 입력에 더 풍부한 정볼르 포함하도록, Q, K, V layer를 개선한다. 
• 각 head의 출력이 다음 head의 입력에 추가되어, feaure의 representation이 점점 향상된다. 
• 추가적으로 Q projection 이후에 새로운 token interaction layer를 추가하여, self-attention이 local과 global 관계를 동시에 잡을 수 있도록 한다.
• 이런 cascaded 방식은 2가지의 장점이 있다. 1) attention map의 다양성 향상 2) network 깊이 증가

[Parameter Reallocation]

• parameter 효율성 증가를 위해, network의 parameter를 중요한 부분의 channel은 더 넓게, 안 중요한 부분은 더 좁게 만드는 재배치를 진행하였다.
• Q, K는 앞선 연구를 바탕으로 작은 channel만 할당하였고, V에 대해선 느 input embedding과 동일 dimension을 유지하도록 하였다. 
• 또한, FFN의 parameter 중복성을 고려해 기존 확장비율 4에서 2로 조정하였다.
• 이로 인해, 중요 정보는 유지하면서 불필요 parameter를 줄여 model 효율성을 향상했다.

EfficinetViT Network Architecture

• model은 크게 3가지 단계로 구성되었다. 각 단계는 앞선 EfficientViT Block들로 구성되어 있고, 각 subsampling layer에서 token 개수가 4배 감소한다.
• 효과적인 subsampling을 위해, sandwich 구조의 subsampling block을 제안하였다. 정보 손실을 최소화하기 위해, ㄴself-attention layer를 inverted residual block으로 대체하였다. 
• EfficientViT는 Layer Normalization 대신, Batch Normalization을 사용했다. (실행 시간 측면에서 유리)
• 속도를 위해, GELU, HardSwish 대신 RELU를 사용했다.

Experiments

• ImageNet-1K classification에서 기존 lightweight model들에 비해, 빠른 속도에서 더 좋은 성능을 보였다. 

Reference

Liu, X., Peng, H., Zheng, N., Yang, Y., Hu, H., & Yuan, Y. (2023). Efficientvit: Memory efficient vision transformer with cascaded group attention. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (pp. 14420-14430).

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