ufw 상태확인

sudo ufw status verbose

ufw 활성화/비활성화

sudo ufw enable sudo ufw disable

ufw 포트 5050번 허용

sudo ufw allow 5050

ufw 포트 5050번 tcp 허용

sudo ufw allow 5050/tcp

ufw 포트 5050번 udp 허용

sudo ufw allow 5050/udp

ufw 포트 5050번 거부

sudo ufw deny 5050

ufw SSH(22) 허용

sudo ufw allow ssh

ufw HTTP(80) 허용

sudo ufw allow http

FCI 알고리즘을 설명하기에 앞서 앞장에서 먼저 PC 알고리즘에 대해 정리하였습니다.

FCI 알고리즘과 PC 알고리즘의 가장 큰 차이는 노드 사이에 Unmeasured confounder가 있을 가능성의 유무라고 할 수 있습니다.

지난 장의 마지막 부분에서 PC 알고리즘의 한계 중에 관찰하지 못한 Confounder가 존재한다면, 실제 인과 그래프와 PC 알고리즘이 도출하는 인과 그래프의 모양이 다를 수 있다고 하였습니다.

이런 한계를 해결하려고 한 알고리즘이 바로 FCI 알고리즘이라고 할 수 있겠습니다.

PC 알고리즘의 시작은 위 표의 2처럼 아무것도 없는 Undirected Graph였습니다. 그렇기에 PC 알고리즘의 경우 위 표처럼 A와 B가 존재할 때, A가 B의 cause가 되거나 B가 A의 cause가 되는 2개의 가능성을 가질 수 있습니다. 왜냐하면, Unmeasured confounder가 없다고 가정하기 때문입니다.

반면에 FCI 알고리즘의 시작은 5처럼 A와 B 사이에 구멍이 뚫린 원이 Edge 끝에 달린 형태의 Undirected Graph로 시작합니다.

이것은 다음과 같은 5가지의 가능성을 내포합니다.

• A가 B의 원인이다.
• B가 A의 원인이다.
• A와 B에 원인이 되는 Unmeasured Confounder가 존재한다.
• A가 B의 원인임과 동시에 A와 B에 원인이 되는 Unmeasured Confounder가 존재한다.
• B가 A의 원인임과 동시에 A와 B에 원인이 되는 Unmeasured Confounder가 존재한다.

FCI 알고리즘으로 도출된 그래프를 보면 위 표의 3처럼 양쪽으로 화살표가 그려진 경우가 있는데, 이것의 의미는 서로가 서로의 원인이라는 의미가 아닌, A와 B에 원인이 되는 Unmeasured Confounder가 존재한다는 의미이다. 기존의 PC 알고리즘이었다면, 이 경우에 A와 B의 관계를 규명할 수 없었을 것이다.

위와 같은 Ground Truth가 있다고 가정하고 FCI 알고리즘의 과정을 간단하게 설명하겠습니다.

위 그래프는 모든 노드끼리 Edge를 연결한 후, 노드 간에 Conditionally independence가 존재하는 경우의 Edge들을 제거한 후의 결과입니다.

Ground Truth 그래프를 보면, X와 Z는 독립이지만 만약 Y를 conditioning 하면 Unmeasured Confounder로 인해, X에서 Z로 가는 path가 뚫리게 됩니다. 이 경우에 Y를 X와 Z의 Collider로 보고, Edge의 방향을 그려주게 됩니다. Y와 W와의 관계도 위 예시와 동일하게 적용되어 Z가 Y와 W의 Collider로 볼 수 있어, Edge 방향을 정해 주어 위 그래프처럼 결과가 나오게 됩니다.

현재 학교에서 계절학기로 Causal discovery에 관해 연구를 진행중이다.

4명의 인원이 각각 PC, FCI, NO TEARS, DAG-GNN 알고리즘을 분담하여 해당 알고리즘을 공부하고 Sachs 데이터의 Causal Graph를 도출하여 서로 공유하는 것을 목표로 하고 있다.

그 중, Constraint-based method인 FCI(Fast Causal Inference) 알고리즘을 맡게 되어 학습한 내용 및 결과들을 블로그에 정리해보려 한다.

바로 FCI 알고리즘을 설명하는 것보단, 굉장히 비슷하고 base가 되는 PC 알고리즘을 먼저 설명하고, 그 다음 PC와 FCI의 차이를 비교하는 것이 좋을 듯 하다.

알고리즘의 설명에 앞서, 개인적으로 인과관계와 상관관계의 차이가 굉장히 헷갈려서 그 개념을 명확히 잡고 가고자 했다.

몇 개의 논문과 강의 영상 등을 보고 나서도 애매함이 해소되지 않았을 때, 그 차이를 잘 정리해 놓은 이 블로그 글을 발견했다.

인과관계와 상관관계가 헷갈리는 것은 인과관계 속에 상관관계가 존재하기 때문이다. 둘 모두 A가 이렇게 변하면 B는 이렇게 변한다라고 주장한다. 하지만, 인과관계는 그 속에 올바른 논리가 필요하고, 상관관계는 그렇지 않다는 차이가 있다.

상관관계가 인과관계로 인정받지 못하는 이유

1. 누락 변수에 의한 영향

• 누락 변수란 다른 변수에 의한 영향을 고려하지 않는 것을 의미함. 즉, 결과가 다른 원인에 의해 발생했을 가능성이 높은데, 해당 가능성을 배제하는 것

2. 시간우선성 존재

• 시간우선성의 존재란 원인이 결과보다 앞서야 한다는 것을 의미. 즉, '역의 인과관계가' 성립하지 않아야 한다. 어떤 것이 시간적으로 우선적인지 알 수 없는 역의 인과관계가 성립하면 이것을 확실하게 인과관계로 규정짓기 어려워진다.
  

결국엔, 상관관계와 인과관계의 가장 큰 차이는 논리적으로 명확히 증명할 수 있느냐로 보인다. 우연적으로 결과가 발생한 것이 아닌, 앞에 발생한 사건이 명확하게 이 결과에 대한 원인인 것을 논리적으로 설명할 수 있어야 한다.

우리가 살면서 많은 사람들을 경험하다 보면, "사람 보는 눈이 생긴다"라는 말을 들어본 적이 있을 것이다. 살면서 경험한 다양한 상관관계들을 통해 직감이 발달했다고 할 수 있을 거 같은데, 정확히 파고 들어가면 그 상관관계들 속에 명확한 인과관계들이 존재한다고 생각한다. HR 쪽에서도 이것을 활용해 새로운 팀원을 뽑을 때, 빅데이터를 기반으로 하여 인재채용에 활용한다고 들은 적이 있다. 내가 이해한 Causal discovery란, 어떠한 한 사건이 일어나기 위해 필요했던 다양한 우연들 속에서 서로간의 관계를 발견하는 것이다.

Causal Discovery

기존의 많은 연구들은 위 그림처럼 잘 정의된 Causal Graph Model을 통해 Joint Distribution(여러 사건이 동시에 일어날 확률)을 구하고, 이 Joint Distribution을 따르는 데이터를 활용하여 인과관계의 효과를 추정했다. 이것이 바로 Structural Causal Model이다.

기존에는 Causal Graph를 연구자가 도메인 지식에 의거하여 설계하였기에, 연구자마다 설계한 다이어그램이 다를 수 있고 실제 Causal Graph와 일치하지 않을 수 있다는 문제점이 존재한다. 만약 완벽한 그래프가 주어진다면, 이론적으로 완벽한 인과 효과를 계산할 수 있지만, 현실세계에서 완벽한 그래프 자체가 구축되기 어려우며, 상당한 도메인 지식 역시 요구될 것이다.

그래서 오직 데이터에 기반하여 객관적으로 Causal Graph를 그리는 방법이 필요해졌고, 이렇게 등장한 것이 Causal Discovery이다. Causal Discovery는 Structural Causal Model과 반대로, 데이터가 주어지면, 해당 데이터 안의 Joint Distribution을 파악하고, 이걸 바탕으로 Causal Graph를 도출하는 방식이다.

Causal Discovery는 주어진 데이터에서 변수 간 관계를 파악하는 방법이다.

위의 표는 Causal Discovery의 진행과정을 보여준다. 먼저, 데이터 상에 존재하는 변수들 간의 Joint Distribution을 도출하여 각각의 변수들이 서로 독립인지, 종속인지를 파악한다. 그리고, 몇 개의 Assumption들을 모두 만족하는 경우의 관계를 그래프로 표현하면, Equivalence Class라고 부르는 Causal Graph가 도출된다.

Assumptions for Causal Discovery

Causal Discovery는 3가지 가정이 필요하다.

• Acyclicity (for DAG) Assumption -> 그래프가 Cycle을 이뤄선 안 된다.
• Causal Markov Assumption
• Faithfulness Assumption
  

Causal Markov Assumption

확률 변수 X1, X2, X3의 Joint Distribution은 P(X1, X2, X3) = P(X1)P(X2|X1)P(X3|X1,X2)로 표현할 수 있다. 만약 아래와 같은 그래프가 주어지면 어떨까?

Causal Markov Assumption은 노드는 자신에게 직접적으로 영향을 주는 노드에게만 종속되며, 이외의 모든 노드들과는 독립이라는 가정이다. 이를 수식으로 표현하면, P(X1,X2,X3) = P(X1)P(X2|X1)P(X3|X2)로 표현할 수 있다. 즉, X3는 X2에만 직접적 영향을 받고, X1으로부터는 간접적인 영향을 받기에 X1과 X3는 독립이라고 판단하게 된다.

Faithfulness Assumption

위와 같은 그래프를 가정해보자. A->B->D 경로와 A->C->D 경로가 존재하기에 노드 A와 노드 D는 d-connected 되어 있다고 할 수 있다. 하지만 만약, A->B->D의 경로는 +1의 효과를, A->C->D의 경로는 -1의 효과를 가진다면, 둘의 효과는 상쇄될 것이다. Faithfulness Assumption은 이러한 효과는 존재하지 않으며, 경로 내에 있는 노드들은 반드시 종속적인 관계여야 한다고 가정한다.

Markov Equivalent Class

PC 알고리즘을 이해하기 위해서는 Markov Equivalente Class를 알아야 한다.

Markov Equivalent Class란, 동일한 skeleton과 V-structure를 가지며, 동일한 Conditional Dependency를 가진 그래프들의 집합으로 정의할 수 있다.

위의 세 그래프는 모두 Equivalent 하다고 할 수 있다. 세 그래프 모두 X와 Z 및 X와 Y가 직접적으로 연결되어 있어 서로 Dependent하고, Y와 Z는 X를 통해 연결되어 있어 서로 Dependent하면, X를 Conditioning 했을 때, Y와 Z가 Conditionally Independent 해지는 구조이기 때문이다.

이런 식으로 X, Y, Z로 표현할 수 있는 DAG 그래프는 아래와 같다.

데이터의 Joint Distribution 내에 존재하는 노드들 간의 동일한 관계들로 그려낼 수 있는 Equivalent Graph가 위와 같이 여러 개 존재한다. 문제는, 이와 같이 동일한 관계로 여러 그래프가 도출되면, 이 중에서 어떤 그래프가 옳은 Causal Graph인지 특정할 수 없게 된다.

위 그래프에서 빨간색 부분을 보면, Collider로 V-structure를 이루고 있는 것을 볼 수 있다. Collider 형식으로 이루어진 노드 간 종속 관계는 Equivalent한 그래프가 한 개만 존재하는 것을 볼 수 있다. 즉, Collider 구조는 노드 간에 종속 또는 독립 관계를 확인할 수 있다면, 단 하나의 Causal Graph로 특정할 수 있는 구조라는 것이다. 이러한 이유로 Collider 구조는 Causal Disovery에서 핵심적인 역할을 수행한다.

PC Algorithm

이제 드디어, 다양한 변수들간의 인과관계를 찾기 위해 Constraint-based method와 Score-based method가 있는데 그 중, Conditional independence를 활용하는 Constraint-based method 종류 중 대표적인 PC 알고리즘에 대해 알아보자.

1.PC 알고리즘을 이용하여 도출하고자 하는 Ground Truth 그래프는 아래와 같다고 하자.

2.첫번째로 Complete Undirected Graph로 시작한다. 모든 변수를 노드로 표시하고 해당 변수들 간에 방향이 없는 Edge를 그려준다.

3.두번째로 서로 전혀 관계없는 Independence 관계인 두 노드 사이의 Edge를 제거한다.

4.세번째로 두 노드 간 다른 노드가 있는 경우, 사이에 있는 노드를 Conditioning 해 보았을 때, 두 노드가 Conditional Independent하다면, 두 노드 사이의 Edge를 제거한다. 이 과정을 반복하면 아래와 같이 Skeleton이 만들어진다.

5.네번째로 V-structure를 규명하여 Edge의 방향을 정해준다. 세 변수간 Conditioning Independence check를 하였을 때 V-structure 구조에 부합하는 패턴이 나오는 경우 Edge의 방향을 하나로 규정할 수 있기에 이 과정을 통해 Edge 방향을 정해줄 수 있다.

6.마지막으로 Orientation Propagation이라고 불리는 과정이다. Collider가 만들어 지지 않도록 남아있는 undirected edge의 방향을 정해준다.

PC 알고리즘의 한계

PC 알고리즘은 2가지 한계점을 가지고 있다.

1. Unobserved Confounder를 규명하지 못한다. PC 알고리즘은 관찰하지 못한 Confounder는 존재하지 않느다는 가정 하에 수행된다. 만약 관찰하지 못한 confounder가 존재할 경우, 실제 Causal Graph와 다르게 나타날 수 있다.

2. Edge의 방향을 규명하지 못하는 경우가 존재한다.

참고자료

• 인과추론의 데이터과학
• Simon's Research Center
• https://silvernecklace.tistory.com/443
• https://everyday-tech.tistory.com/45
• Review of Causal Discovery Methods Based on Graphical Models

우선, 맥북 터미널에서 아래 명령어를 입력하여 설치를 진행한다.

$ brew install curl

$ curl -X POST -H "Content-Type: application/json; charset=utf-8" -d '{"message":"hello"}' http://127.0.0.1:port/api/

-X 옵션 : 요청시 사용할 메소드의 종류 지정 (위에서는 POST로 지정)

-H 옵션 : 전송할 헤더를 지정 (보내는 타입을 json으로 지정하고, 문자를 인코딩하기 위해 utf-8 설정을 해 주었다.)

-d 옵션 : HTTP POST 요청 데이터 입력 (위에서는 {"message":"hello"} json 형태 입력)

서버 비용이 부담되니 1년간 무료로 쓸 수 있는 free-tier를 통해 진행하고 있는데, 그 과정이 순탄치 않다.....

최근에 공부하고 있는 도커를 최대한 활용하려고 하고 있다.

도커파일을 이용해 aws 서버 내에서 이미지를 만들려고 했는데, torch를 설치하다가 프로세스가 자꾸 kill 되는 문제가 있었다.

free-tier가 지원하는 램이 1GB이다 보니 torch library를 설치하는 과정에서 메모리 초과가 되지 않았나 하는 가설을 세웠다.

그래서 생각한 해결책이 로컬에서 해당 도커파일을 실행하여 이미지를 만들고, 컨테이너에 올린 뒤, 컨테이너 안에 파일 복사 후, 필요한 모든 라이브러리들을 설치한 뒤, 해당 컨테이너를 이미지 파일로 추출하여 docker hub에 push한다.

그리고, aws에서 docker를 설치한 뒤, docker pull 명령으로 이전에 push 했던 이미지를 불러와, 컨테이너에 올리고 실행하는 것이다.

로컬에서 테스트 할 때는 잘 돼서 당연히 aws 서버에서도 잘 되겠거니 했는데, 모델 서버를 실행하는 도중에 프로세스가 죽었다.....ㅠㅠ

free-tier에 올리는 건 불가능한 건가 하고, 포기하려는 찰나에 구글링 도중 이 블로그 글(EC2가 갑자기 멈춘다면?(feat.swap 메모리))을 발견했다.

이 분은 스왑을 이용해 문제를 해결하셨다고 한다.

"스왑이란 쉽게 말하면 내 하드디스크(또는 ssd)의 공간을 빌려서 가상 메모리로 사용하는 것이다."라고 설명하신다.

맞다. 생각해보니 램이 부족할 때, ssd의 메모리를 빌려오는 기술이 있었구나!

$ free -m

위 명령어를 사용하여, 메모리 사용량 및 Swap 메모리를 볼 수 있다. Swap 메모리가 0인 것을 확인했으니, Swap 메모리를 잡아주자.

무작정 높게 잡는 것이 좋은 것이 아니고, AWS 공식 문서에 권장 스왑 메모리 크기가 있다고 한다.

RAM 2GB 이하 -> RAM 용량의 2배(최소 32MB)

RAM 2GB 초과 64GB 미만 -> RAM 용량의 0.5배

RAM 64GB 초과 -> 워크로드 또는 사용 사례에 따라 다름

현재 내가 가진 인스턴스의 RAM은 1GB이므로, 스왑을 2GB로 잡아주기로 했다.
1)

sudo dd if=/dev/zero of=/swapfile bs=128M count=16

dd 명령을 사용하여 루트 파일 시스템에 스왑 파일을 생성한다.

bs는 블록 크기, count는 블록 수로 이 두 수를 곱한 값으로 스왑 파일의 크기를 결정한다.

주의해야 할 것은 지정한 블록 크기는 내 인스턴스에서 사용 가능한 메모리보다 작아야 한다.

스왑 파일은 2GB(128MB x 16)로 해 주었다.
2)

sudo chmod 600 /swapfile

스왑 파일의 읽기 및 쓰기 권한을 업데이트한다.
3)

sudo mkswap /swapfile

스왑 공간에 스왑 파일을 추가하여 스왑 파일을 즉시 사용할 수 있도록 한다.
4)

sudo swapon /swapfile

리눅스 스왑 영역을 설정한다.
5)

sudo swapon -s

위에서 진행한 절차가 성공했는지 확인한다. 현재까지 이상없이 잘 진행된 것을 확인할 수 있다.
6)

sudo vi /etc/fstab

/etc/fstab 파일을 편집하여 부팅 시 스왑 파일을 활성화할 수 있게 한다. 아래 내용을 파일 맨 끝에 새로 추가하고 파일을 저장한다.

/swapfile swap defaults 0 0

파일 저장 시에는 esc -> :wq!를 이용한다.
결과

free -m

스왑 메모리가 잘 할당된 것을 볼 수 있다!

출처 : https://wooogy-egg.tistory.com/83

df['text'] = df['text'].apply(lambda x: re.sub("[^ A-Za-z0-9가-힣]", "", x)) df['text'] = df['text'].apply(lambda x: re.sub("[ +]", " ", x))

conda install nbconvert==5.4.1

제공 데이터 형식은 jsonl 형식으로 구성되어 있고, 문장이 주어지면, 해당 문장에 등장한 개체&속성 쌍들과 그 쌍 각각에 대한 극성(Positive, Neutral, Negative) 값으로 이루어져 있다. 도메인은 화장품, 자동차 부품, 생활용품 등 쇼핑 분야이다.

2. 극성별 분포

• Train set Positive : 3,102개 Negative : 58개 Neutral : 95개
  
• Validation set Positive : 2,997개 Negative : 28개 Neutral : 54개

Negative, Neutral에 비해 Positive 데이터가 압도적으로 많아 모델 성능이 걱정되었다. 쇼핑 리뷰 특성상, 리뷰 이벤트 등으로 인해 Positive로 치우쳐질 수 밖에 없었던 거 같다. Data Imbalance를 해결하기 위해 여러 논문들을 읽고, loss 함수 측면에서와 Data Augmentation 측면으로 접근해 보았는데 효과가 없었다. 진행한 실험 및 과정들은 따로 정리하겠다.

3. Emoji

데이터 분석을 하면서 되게 재밌는 걸 발견했는데, 아마 이 부분이 이번 대회에서 가장 크게 얻은 게 아닐까 한다. 바로 Emoji를 Unknown 토큰으로 처리한다는 것이다. 물론, 사전학습 모델의 Tokenizer에 따라 Emoji를 잡아낼 수도 있겠지만, 중요한 건 Emoji가 Tokenizer vocab에 존재하지 않는다면, 같이 붙어있는 단어까지도 통째로 Unknown 처리가 되는 것이었다. 만약 Emoji가 문장의 정보를 가장 잘 나타내는 단어 옆에 붙는다면, 모델은 해당 문장의 정보를 제대로 추출하지 못할 것이다. 이 문제를 해결하기 위해 후에 다양한 실험(실험 분석 부분 참고)들을 했고, 실제로 큰 효과가 있었다. NLP에서 전처리가 얼마나 중요한지 느낄 수 있는 순간이었다.

4. 맞춤법, 띄어쓰기

리뷰 데이터라 그런지, 텍스트에 Noise들이 많이 보였다. 띄어쓰기와 맞춤법들이 잘 맞지 않는 경우가 많았다. 학습 전에 데이터 전처리가 필요해 보였다.

과제에서 사용하는 말뭉치는 국립국어원이 구축한 '속성 기반 감성 분석' 말뭉치입니다. 속성 기반 감성 분석이란 언어에 나타난 개체의 속성 정보에 대한 극성을 분류하는 과제입니다. 참가팀은 입력 문장에 대해 (1)속성 범주(예: 제품 전체#인지도)와 (2)감성(긍정/부정/중립)의 쌍을 추출하고, 정답 튜플과 예측된 튜플과의 비교를 통해 계산된 F1 점수로 참가팀의 인공 지능 모델의 성능을 평가합니다.

2. 데이터 규모

3. 데이터 속성 범주 (총 25개)

• 제품 전체#일반, 제품 전체#품질, 제품 전체#가격, 제품 전체#디자인, 제품 전체#인지도, 제품 전체#편의성, 제품 전체#다양성
• 본품#일반, 본품#품질, 본품#가격, 본품#디자인, 본품#인지도, 본품#다양성, 본품#편의성,
• 패키지/구성품#일반, 패키지/구성품#품질, 패키지/구성품#가격, 패키지/구성품#디자인, 패키지/구성품#편의성, 패키지/구성품#다양성
• 브랜드#일반, 브랜드#품질, 브랜드#가격, 브랜드#디자인, 브랜드#인지

1. 텍스트 전처리

• 이모지 및 특수문자 제거
• 반복문자 정규화(최대 2개로) (ex. ㅋㅋㅋㅋ - > ㅋㅋ, 우와아아아아-> 우와아아)
• 영어 및 숫자 제거

2. Back-translation

• 구글에서 제공하는 무료 api인 gooletrans api 이용하여 한글 -> 영어 -> 한글 거쳐 데이터 증폭

3. 분류 복잡도 줄이기

• 기존 7가지 감정 (neutral, happiness, sadness, angry, disgust, fear, surprise)을 분류하는 Task를 쪼개서 긍정, 부정, 중립, 놀람 4가지를 먼저 분류한 뒤, 부정일 때만 다시 sadness, angry, disgust, fear를 분류
• 놀람 라벨을 가진 데이터에 긍정과 부정이 섞여 있어서 긍정, 부정, 중립, 놀람 4가지로 나눴다.

4. 품질 우려라벨 문제 보완

• 3번에서 얘기한 것처럼 놀람 라벨에 긍정과 부정 데이터가 섞여 있어서 성능이 잘 안 나오나 싶어서 전체 데이터셋에서 놀람을 제거한 뒤 (1) 중립인지 아닌지 판단하는 모델 (2) 긍정인지 아닌지 판단하는 모델 (3) 부정인지 아닌지 판단하는 모델 -> 부정이면 부정 감정 4중 분류(sadness, angry, disgust, fear) (4) (3)번까지 모두 False이면 해당 문장은 놀람으로 판단

5. K-Fold cross validation

• fold를 5로 하여 모델 학습 후, 5개의 모델 앙상블
• 모델의 성능이 전부 비슷하여 hard-voting

Conclusion

• 텍스트 전처리에서 성능향상이 없었는데, 그 이유로 현재 AI hub 데이터가 Emoji나 noise가 많이 들어가지 않은 데이터라 이런 결과가 나오지 않았나 하는 생각이 든다.

• 개인적으로 Back-translation에서 어느 정도의 성능 향상을 기대했는데 오히려 떨어지는 결과를 보여서 실망스러웠다. Data Imbalance 문제를 해결하기 위해 부족 label에 대해서만 Back-translation을 적용해 보기도 하고, 가장 많은 neutral 데이터를 제외하고 나머지를 증폭시켜보기도 했지만, base 모델의 f1-score를 넘지 못했다. 여러 논문과 다른 사람들의 연구를 살펴보니, Back-translation을 사용했을 때 기존 문장의 의미가 바뀌어 버리는 경우가 있어 주의해야 한다고 한다.

• 분류 복잡도를 줄이면 성능이 오를까 하여 체를 거르는 식으로 실험을 진행하였지만, 역시 base model의 성능을 넘지 못했다.

• Train data를 조금 더 늘리면 성능이 오를까 하여, K-fold Cross Validation 기법을 이용하여 fold를 5로 나누어 hard-voting 방식으로 앙상블이 진행했을 때 미세하게 base보다 성능이 오르는 것을 확인했다.

• 아쉬웠던 건 오픈 데이터 중 그나마 품질이 좋았던 AI hub 데이터를 사용했지만, 동일한 문장을 교묘하게 특수문자를 추가하거나, 글자 하나만 바꾸는 식으로 데이터가 구성되어 있어 조금 더 양질의 데이터를 이용했으면 실험이 조금 더 의미 있지 않았을까 하는 아쉬움이 있다.

향후 연구방향

• Data augmentation 방식 중, Back-translation만을 사용해서 실험을 진행했는데 다른 기법들도 적용하여 성능의 변화가 있는지 확인

• K-Fold Cross Validation에 Soft-voting 방식 적용하여 결과 확인

이를 위해, 기존 BERT의 한국어 성능 한계를 극복하기 위해 SKT -brain에서 공개한 KoBERT를 이용해 Fine-tuning 하는 과정을 기록하려고 한다.

1. 데이터셋

AI hub의 감정 분류를 위한 대화 음성 데이터셋을 이용했다. 해당 데이터셋은 총 7개의 감정(happiness, angry, disgust, fear, neutral, sadness, surprise)으로 레이블링이 되어있다. 4차년도, 5차년도, 5차년도_2차로 나눠서 csv 파일로 제공되는데, 우선 5차년도_2차 데이터만을 사용해서 성능을 확인했다. 단발성 대화 데이터셋을 이용해서 실험을 진행해 봤는데, 데이터셋의 라벨링이 이상하게 된 경우가 많아 성능이 너무 안 나왔다...ㅠ

대화 데이터셋이다 보니 한 문장만을 보는 것이 아닌 대화 문맥에서의 상황을 적어 놓은 것 같다. "상황" 열을 정답 레이블로 사용하기엔 적절하지 않아 보였다. 데이터셋 설명에서 5명이 이 데이터에 대해 라벨링을 진행했다고 적혀 있는 것을 보니 1번5번 감정이라고 적혀 있는 것은 라벨링을 진행하신 분들마다 해당 문장을 보고 판단한 감정 레이블인 것 같다. 내가 필요한 것은 단순히 한 문장을 봤을 때의 감정이 필요한 것이므로 15번까지의 감정을 이용해 정답 레이블을 새로 만들고자 한다. 우선, 중복 데이터들이 있어 중복 제거를 한 뒤, 다음의 기준으로 정답 레이블을 새로 만들고자 한다.

• 1~5번까지의 감정 중 다수결로 많이 나온 감정을 정답으로 채택
• 만약 1~5번까지 감정이 다수결로 나오지 않으면, "상황"열의 감정값까지 이용하여 다수결을 구한다.
  
  

기존 19374개의 데이터에서 중복 제거를 하니, 18,651개로 데이터 갯수가 줄었다.

18,651개의 데이터를 sklearn의 train_test_split 함수를 이용해 8:1:1의 비율로 나눴다.

2. 하이퍼 파라미터 세팅

3. 실험 결과

Conclusion

Test data에 대해 f1 score가 0.71 정도 나왔다. 7개 라벨에 대해 분류하는 거 치고 성능이 꽤 괜찮게 나온 것 같다. 한 문장씩 넣어서 테스트를 진행해 봤을 때도 나쁘지 않은 것 같다. 이 수치를 베이스로 삼아서 성능을 향상시켜봐야겠다. 현재 데이터가 불균형하므로, 그걸 해결하면 성능 향상을 기대해 볼 수 있을 것으로 보인다. Data augmentation을 진행하기 전에, Weighted-loss를 CrossEntropy 함수에 적용하여 학습을 진행하고 결과를 확인해 봐야겠다.

앞으로 시도해 볼 것들

• Weighted-loss 적용 후 결과 확인
• 감정분류를 위한 대화 데이터셋에서 총 3개의 데이터셋 중 1개만 사용했는데 3개를 다 합쳐서 학습 후 결과 확인, 데이터 불균형 해소를 위해 부족 라벨만 보충해서 진행하는 것도 의미가 있어 보임
• 데이터 불균형을 해소하기 위해, 부족 Label에 대해 Data augmentation 적용 후 결과 확인
• Kaggle Emotion Dataset을 번역한 데이터를 추가하여 결과 확인

Insight

한 문장에 여러 감정이 들어간 경우를 판단할 수 있는 모델을 만들고 싶었는데, 위 데이터를 잘 이용하면 가능할 것 같기도 하다. 뭔가 5가지 사람의 판단을 다 넣어버리면 이것도 저것도 안 되는 결과가 나와버릴지도...실험을 해봐야 알 것 같다. 우선 Single-label-classification에 집중하고, 나중에 Multi-label-classification을 시도해 봐야겠다.

정규식을 활용해서 숫자 하나하나를 따로따로 불러와야하나 싶었지만, 구글링 결과 생각보다 해결방법은 간단했다.

파이썬의 내장함수인 eval() 함수를 사용하니 리스트를 덮고 있던 따옴표(')를 드디어 해치울 수 있었다. 데이터 프레임 하나의 열 전체를 바꿔야 하는 상황이었기에 apply 함수를 사용하여, df['embedding'] = df['embedding'].apply(eval)을 이용하여 한 줄로 처리해 주었다.

conclusion

아직도 파이썬을 100% 활용하지 못하고 있는 것 같다. 함수나 다양한 기능들을 발견하면 블로그에 그때그때 정리해 놔야겠다.

delete 연산이 성공했을 경우나 존재하지 않는 속성이라 아무런 연산도 하지 못할 경우 true가 출력되고, 실패할 경우 false가 출력된다.

var student = {
    name : Ryan;
    age : 27;
}

delete student.name;
// true

delete student;
// false

delete not_exist;
// true