Y Tech Blog search

Field-aware Factorization Machines (FFM) 설명 및 xlearn 실습

|

본 글의 전반부에서는 먼저 Field-aware Factorization Machines for CTR prediction 논문을 리뷰하면서 본 모델에 대해 설명할 것이다. 후반부에서는 간단한 xlearn코드 역시 소개할 예정이다. 논문의 전문은 이곳에서 확인할 수 있다.


1. Field-aware Factorization Machines for CTR prediction 논문 리뷰

1.0.Abstract

CTR 예측과 같은 크고 희소한 데이터셋에 대해 FFM은 효과적인 방법이다. 본 논문에서는 우리는 FFM을 학습시키는 효과적인 구현 방법을 제시할 것이다. 그리고 우리는 이 모델을 전체적으로 분석한 뒤 다른 경쟁 모델과 비교를 진행할 것이다. 실험에 따르면 FFM이 특정 분류 모델에 있어서 굉장히 뛰어난 접근 방법이라는 것을 알려준다. 마지막으로, 우리는 FFM 패키지를 공개한다.

1.1. Introduction

CTR 예측에 있어서 굉장히 중요한 것은, feature 간의 conjunction(결합, 연결)을 이해하는 것이다. Simple Logistic Regression과 같은 간단한 모델은 이러한 결합을 잘 이해하지 못한다. FM 모델은 2개의 Latent Vector의 곱으로 factorize하여 feature conjunction을 이해하게 된다.

개인화된 태그 추천을 위해 pairwise interaction tensor factorization (PITF)라는 FM의 변형 모델이 제안되었다. 이후 KDD Cup 2020에서, Team Opera Solutions라는 팀이 이 모델의 일반화된 버전을 제안하였다. 그러나 이 용어는 다소 일반적이고 혼동을 줄 수 있는 이름이므로, 본 논문에서는 이를 FFM이라고 부르도록 하겠다.

FFM의 중요 특징은 아래와 같다.

  1. 최적화 문제를 해결하기 위해 Stochastic Gradient를 사용한다. 과적합을 막기 위해 오직 1 epoch만 학습한다.
  2. FFM은 위 팀에서 비교한 모델 6개 중 가장 뛰어난 성적을 보여주었다.

1.2. POLY2 and FM

(중략)


1.3. FFM

FFM의 중요한 아이디어는 PITF로 부터 파생되었는데, 이는 바로 개인화된 태그에 관한 것이다. PIFT에서 그들은 User, Item, Tag를 포함한 3개의 가용 필드를 가정했고, 이를 분리된 latent space에서 (User, Item), (User, Tag), (Item,Tag)로 factorize하였다. 이러한 정의는 추천 시스템에 적합한 정의이고 CTR 예측에 있어서는 자세한 설명이 부족한 편이므로, 좀 더 포괄적인 논의를 진행해보도록 하겠다.

아래와 같은 데이터 테이블이 있을 때, featuresfields로 그룹화할 수 있다.

예를 들어, Espn, Vogue, NBC는 Publisher라는 field에 속할 수 있겠다. FFM은 이러한 정보를 활용하는 FM의 변형된 버전이다. FFM의 원리를 설명하기 위해, 다음 새로운 예시에 대해 생각해보자.

FM의 상호작용 항인 $\phi_{FM}(w, x)$는 아래와 같이 표현될 수 있다.

FM에서는 다른 feature들과의 latent effect를 학습하기 위해 모든 feature는 오직 하나의 latent vector를 가진다. Espn을 예로 들어보면, $w_{Espn}$은 Nike와 Male과의 latent effect를 학습하기 위해 이용되었다. 그러나 Nike와 Male은 다른 Field에 속하기 때문에 사실 (Espn, Nike)의 관계와 (Espn, Male)의 관계에서 사용되었던 $w_{Espn}$의 값은 다를 가능성이 높다. 즉, 하나의 벡터로 2개의 관계를 모두 표현하기에는 무리가 있다는 점이다.

FFM에서는 각각의 feature는 여러 latent vector를 갖게 된다. FFM의 상호작용 항인 $\phi_{FFM}(w, x)$은 아래와 같이 표현된다.

수학적으로 재표현하면 아래와 같이 표현할 수 있겠다.

여기서 $f_1$과 $f_2$는 $j_1$과 $j_2$의 field를 의미한다. $j$들은 Espn, Nike 등을 의미한다. $f$를 field의 개수라고 할 때, FFM의 변수의 개수는 $nfk$이며, FFM의 계산 복잡성은 $O(\overline{n}^2 k)$이다.

여기서 n, f, k는 각각 feature의 개수(often called p), field의 개수, latent 변수의 개수를 의미한다.

FFM의 경우 각각의 latent vector아 오직 특정 field와 관련한 효과에 대해서는 학습을 진행하기 때문에 잠재 변수의 수은 $k$는 FM의 경우보다 작은 경우가 많다.

[k_{FFM} < k_{FM}]


1.3.1. Solving the Optimization Problem

사실 FFM의 최적화 문제를 푸는 것은 Simple Logistic Regression의 최적화 문제를 푸는 식에서 $\phi_{LM}(w, x)$를 $\phi_{FFM}(w, x)$로 바꾸는 것을 제외하면 동일하다.

실험 결과에 그 이유가 나오지만, Stochastic Gradient 알고리즘으로 행렬 분해에 있어 효과적인 AdaGrad를 적용하였다. 각 SG 스텝마다 data point $(y, x)$는 $\phi_{FFM}(w, x)$ 식에서 $w_{j1, f2}, w_{j2f1}$를 업데이트하기 위해 추출된다. CTR prediction과 같은 문제를 푸는 데에 있어 $x$는 굉장히 희소한 벡터임을 기억하자. 따라서 실제로는 0이 아닌 값들에 대해서만 업데이트가 진행될 것이다.

sub-gradient는 아래와 같다.

d=1…k에 대해 gradient의 제곱합은 아래와 같이 합산된다.

최종적으로 $(w_{j1, f2})d$과 $(w{j2, f1})_d$ 는 아래와 같이 업데이트 된다.

여기서 $\eta$는 직접 정한 learning rate를 의미한다. $w$의 초깃값은 $[0, 1/\sqrt{k}]$ 사이의 Uniform Distribution 에서의 랜덤한 값으로 초기화된다. $G$는 $(G_{j1, f2})_d^{-\frac{1}{2}}$의 값이 매우 커지는 것을 막기 위해 모두 1로 세팅된다. 전체적인 과정은 아래와 같으며, 각 instance를 normalize해주는 것이 성능 향상에 도움이 되었다는 말을 남긴다.


1.3.2. Parallelization on Shared-memory Systems

본 논문에서는 Hog-WILD!라는 병렬처리 기법을 사용하였다.


1.3.3. Adding Field Information

널리 사용되는 LIBSVM의 데이터 포맷은 다음과 같다.

label feat1:val1 feat2:val2 …

여기서 각 (feat, val) 쌍은 feature index와 value를 의미한다. FFM을 위해 우리는 위 포맷을 아래와 같이 확장할 수 있다.

label field1:feat1:val1 field2:feat2:val2 …

이는 적합한 field를 각 feature 마다 지정해주어야 함을 의미한다. 특정 feature에 대해서는 이 지정 작업이 쉽지만, 나머지들에 대해서는 그렇지 않을 수도 있다. 이 부분에 대해서는 feature의 3가지 종류의 관점에서 논의해보도록 하자.

Categorical Features
선형 모델에서 categorical feature는 여러 개의 binary feature로 변환하는 것이 일반적이다. 우리는 다음과 같이 데이터 instance를 변형할 수 있다.

LIBSVM 포맷에서는 0의 값은 저장되지 않기 때문에 이렇게 모든 categorical feature들을 binary feature로 변형할 수 있는 것이다. 이제 위 데이터는 최종적으로 아래와 같은 형상을 갖게 된다.

Numerical Features
conference에서 논문이 통과될지에 대한 데이터가 있다고 하자. 칼럼의 의미는 아래와 같다.

  • AR: accept rate of the conference
  • Hidx: h-index of the author
  • Cite: # citations of the author

각 feature를 dummy field로 취급하여 아래와 같은 데이터 형상을 만들 수도 있지만, 이는 딱히 도움이 되지 않는 방법 같다.

Yes AR:AR:45.73 Hidx:Hidx:2 Cite:Cite:3

또 하나의 방법은, feature는 field에 넣고, 기존의 실수 값을 이산화하여 feature로 만든 후, binary하게 1과 0의 값을 넣어주는 방식이다.

Yes AR:45:1 Hidx:2:1 Cite:3:1

이산화 방법에 대해서는 여러가지 방식이 존재할 수 있다. 어떠한 방법이든 일정 수준의 정보 손실은 감수해야 한다.

Single-field Features
일부 데이터 셋에 대해서 모든 feature가 단일 field에 속하여 각 feature에 대해 field를 지정해주는 것이 무의미한 경우도 있다. 특히 NLP와 같은 분야에서는 이러한 현상이 두드러진다.

위 경우에서 유일한 field는 “sentence”가 될 것이다. 일부 사람들은 numerical features의 경우처럼 dummy field를 만들면 어떨까 하고 의문을 가지지만, 사실 그렇게 되면 n(feature의 수)이 너무 커지기 때문에 굉장히 비효율적이다.

(FFM의 모델 크기가 $O(nfk)$임을 기억해보자. 이 경우에는 $f=n$이 될 것이다. (field의 수 = feature의 수))


1.4. Experiments

(후략)


2. xlearn

2.1. 설치

여러 가지 방법으로 설치를 진행할 수 있지만, 여기에서 whl파일을 통해 설치하는 것이 가장 간단하다.

2.2. 코드

def _convert_to_ffm(path, df, type, target, numerics, categories, features, encoder):
    # Flagging categorical and numerical fields
    print('convert_to_ffm - START')
    for x in numerics:
        if(x not in encoder['catdict']):
            print(f'UPDATING CATDICT: numeric field - {x}')
            encoder['catdict'][x] = 0
    for x in categories:
        if(x not in encoder['catdict']):
            print(f'UPDATING CATDICT: categorical field - {x}')
            encoder['catdict'][x] = 1

    nrows = df.shape[0]
    with open(path + str(type) + "_ffm.txt", "w") as text_file:

        # Looping over rows to convert each row to libffm format
        for n, r in enumerate(range(nrows)):
            datastring = ""
            datarow = df.iloc[r].to_dict()
            datastring += str(int(datarow[target]))  # Set Target Variable here

            # For numerical fields, we are creating a dummy field here
            for i, x in enumerate(encoder['catdict'].keys()):
                if(encoder['catdict'][x] == 0):
                    # Not adding numerical values that are nan
                    if math.isnan(datarow[x]) is not True:
                        datastring = datastring + " "+str(i)+":" + str(i)+":" + str(datarow[x])
                else:

                    # For a new field appearing in a training example
                    if(x not in encoder['catcodes']):
                        print(f'UPDATING CATCODES: categorical field - {x}')
                        encoder['catcodes'][x] = {}
                        encoder['currentcode'] += 1
                        print(f'UPDATING CATCODES: categorical value for field {x} - {datarow[x]}')
                        encoder['catcodes'][x][datarow[x]] = encoder['currentcode']  # encoding the feature

                    # For already encoded fields
                    elif(datarow[x] not in encoder['catcodes'][x]):
                        encoder['currentcode'] += 1
                        print(f'UPDATING CATCODES: categorical value for field {x} - {datarow[x]}')
                        encoder['catcodes'][x][datarow[x]] = encoder['currentcode']  # encoding the feature

                    code = encoder['catcodes'][x][datarow[x]]
                    datastring = datastring + " "+str(i)+":" + str(int(code))+":1"

            datastring += '\n'
            text_file.write(datastring)

    # print('Encoder Summary:')
    # print(json.dumps(encoder, indent=4))
    return encoder

위와 같이 LIBSVM 데이터 포맷으로 데이터를 변경한 후에,

import xlearn as xl

model = xl.create_ffm()

# 학습/테스트 데이터 path 연결
model.setTrain("data/train_ffm.txt")
model.setValidate("data/test_ffm.txt")

# Early Stopping 불가
model.disableEarlyStop()

# param 선언
param = {'task': 'binary', 'lr': 0.2, 'lambda': 0.00002,
         'k': 3, 'epoch': 100, 'metric': 'auc', 'opt': 'adagrad',
         'num_threads': 4}

# 학습
# model.fit(param=param, model_path="model/model.out")

# Cross-Validation 학습
model.cv(param)

# Predict
model.setTest("data/test_ffm.txt")
model.setSigmoid()
model.predict("model/model.out", "output/predictions.txt")

위와 같이 학습을 진행하면 된다. 간단하다.


Reference

https://wngaw.github.io/field-aware-factorization-machines-with-xlearn/

Comment  Read more

Explain Yourself! Leveraging Language Models for Commonsense Reasoning

|

이 글에서는 2019년 6월 Nazneen Fatema Fajani 등이 발표한 Explain Yourself! Leveraging Language Models for Commonsense Reasoning 논문을 살펴보도록 한다.

이 논문에서는 CoS-E라는 상식 설명문(Common Sense Explanations)에 관한 데이터셋을 만들어 공개했다. 여기에서 찾아볼 수 있다(논문의 링크로 들어가보면 저장 위치가 바뀌었다고 한다).

중요한 부분만 적을 예정이므로 전체가 궁금하면 원 논문을 찾아 읽어보면 된다.


Explain Yourself! Leveraging Language Models for Commonsense Reasoning

논문 링크: Explain Yourself! Leveraging Language Models for Commonsense Reasoning

Dataset: CoS-E

초록(Abstract)

딥러닝 모델들은 상식추론(Commonsense Reasoning)이 필요한 task에서는 낮은 성능을 보여, 입력에는 당장 나타나지 않는 어떤 정보에 대한 지식이나 추론이 필요하게 하였다. 우리(이 논문의 저자)는 CoS-E(Common Sense Explanations)라 부르는, 1) 일련의 자연어와 2) 강조된 구문 두 가지 형태로 구성된 새로운 데이터셋을 수집했다. CAGE(Commonsense Auto-Generated Explanation) Framework에서 학습 및 추론 단계에서 사용될 수 있는 설명문(explanations)을 자동으로 생성하도록 언어모델을 학습시켰다. CAGE는 상식질답(CommonsenseQA) task에서 10%만큼 State-of-the-art를 뛰어넘었다. 우리는 또한 out-of-domain으로의 전이학습을 포함하여 사람이 그리고 기계가 자동생성한 설명문을 전부 사용하여 DNN에서 상식추론 문제를 연구할 것이라 하였다. 실험결과는 상식추론에 관해 언어모델을 효과적으로 조정(Leverage)할 수 있음을 시사한다.


1. 서론(Introduction)

상식추론(Commonsense Reasoning)은 현대 기계학습 방법에서 도전적인 과제이다. 설명문(Explanations)은 모델이 학습하는 추론을 말로 표현하는 방법이다. 상식질답(Commonsense QA, CQA)는 상식추론 능력을 가진 자연어처리(NLP) 모델을 개발하기 위한 다지선다형 질답 데이터셋이다. 이와 관련해 많은 노력이 있었지만 뚜렷한 발전이 없었다.
이 논문의 저자들은 CQA에 더해 상식추론을 위한 사람의 설명문을 수집했고 이를 CoS-E라 하였다. CoS-E는

  1. 자유형식의 일련의 자연어(보통 문장)
  2. 정답을 추론하는 데 중요하다고 사람이 판단한 문장의 일부를 강조한 부분

두 가지 형태로 존재한다. 아래 그림에서 Question과 Choicse(3개)는 CQA dataset의 일부이며, CoS-E는 1) CoS-E 부분의 문장과 2) Question에서 노란색으로 강조된 부분을 포함한다.

Examples

Talmor et al. (2019)에서는 Google search를 활용하여 각 질답 당 100개의 snippet으로부터 문맥정보를 추출해내는 것은 ELMo 표현에 self-attention layer를 쓴 모델이자 현재 SOTA(state-of-the-art) 모델인 BiDAF++를 사용해도 CQA에서 정답률을 향상시키지 못한다고 하였다.

이에 반해, 우리는 상식추론에 유용한 설명문(explanations)을 생성하는 사전학습된 모델을 조정하였다. CQA를 위한 설명문을 생성하는 framework로 CAGE(Commonsense Auto-Generated Explanations)를 제안한다. 우리는 상식추론 문제를 두 단계로 나누었다:

  1. CQA sample과 그에 맞는 CoS-E 설명문을 언어모델에 입력으로 준다. 언어모델은 CQA 질답에 기초하여 CoS-E 설명문을 생성하도록 학습된다.
  2. 언어모델은 CQA의 학습(training)과 검증(validation) 세트 안에 있는 각 sample에 대해 설명문을 생성하도록 한다. 이 CAGE 설명문은 원래의 질문, 선택지, 언어모델의 출력값에 이어붙여 두 번째 상식추론 모델의 입력으로 들어간다.

이 2단계의 CAGE framework는 기존 최고의 baseline보다 10% 초과 달성한 결과를 얻었으며 그 예측값을 정당화(justify)하는 설명문을 생성하였다. 아래 그림은 이 접근법을 개략적으로 보여준다.

Examples

요약하면, 이 논문은 상식추론을 위한 새로운 CoS-E 데이터셋을 소개하였고, CQA v1.0에서 65%의 정답률을 보인 ‘설명문을 자동 생성하는’ CAGE framework를 제안하였다.

참고로, 이 논문이 제출되기 직전 CQA는 v1.11를 공개하였는데, 질문에 대한 선택지가 3개에서 5개로 늘어났다. 더 도전적인(challenging) 과제로 바뀌었다.


논문에 2.1. section이라 소개하진 않았지만 목차를 위해 넣었다.

2.1. Commonsense Reasoning

자연어에 포함된 상황이나 사건의 관계를 예측하도록 요구하는 데이터셋이 최근 몇 개가 소개되어 왔다.

  • 여러 타당한 결말 중 가장 올바른 스토리 결말을 선택하는 Story Cloze(혹은 ROC Stories)
  • 초기 상황에 기초하여 다음 장면을 예측하는 SWAG(Situations with Adversarial Generations)

이러한 데이터셋에 대해서는 GPTBERT이 이미 사람 수준의 성능을 내지만, 대명사가 어떻게 다른 부분과 연관이 되어 있으며 어떻게 세상의 지식과 상호작용을 하는지 등에 관해서는 별로 성공적이지 못했다.

CQA는 9500개의, 질문 + 1개의 정답 + 2개의 헷갈리는 오답으로 구성되어 있는 데이터셋으로 단지 분포상의 편향(biases)에서 정보를 얻기보다는 질문에서 추론하도록 하는 것을 요구하지만, 언어적인 면에서 좋지 않은 쪽으로 편향되어 있음이 발견되었다. 이를테면, 여자와 관련된 부분에서는 부정적인 의미의 문맥이 있다거나 하는.

SOTA 언어모델은 사람에 비해 CQA 데이터셋에서 굉장히 낮은 성능을 보인다. CQA는 모델의 상식추론 능력을 측정하는 benchmark를 제공함에도 정확히 어떤 부분이 모델이 추론을 행하는지는 여전히 불확실하다. CoS-E는 이 benchmark에 더해, 다른 한편으로 모델의 추론능력을 연구, 평가 및 분석할 수 있도록 하는 설명문을 제공한다.

2.2. Natural language explanations

Lei et al.에서는 감정분석 접근법의 타당성을 입증할 수 있는, 어떤 추론 결과를 내기 위해 필요한 구문을 입력에서 강조(선택)하는 방식을 제안했다. 분류데이터를 위한 사람이 만든 자연어 설명문은 의미분석을 학습하기 위해 사용되어왔고 분류기를 학습시키는 데 사용할 수 있는, noisy한 분류 데이터를 생성하였다. 그러나 전이성(interpretability)은 SNLI(Stanford Natural Language Inference)에서 성능저하를 보인다고 한다.
그러나, e-SNLI와는 다르게, CQA를 위한 설명문은 설명-예측 단계로 성능을 향상시킬 수 있다. 또한 VQA에도 사용 가능하며, 자동생성된 것과 사람이 만든 설명문을 함께 사용하는 것이 따로 사용하는 것보다 더 좋은 결과를 내었다.

2.3. Knowledge Transfer in NLP

자연어처리는 Word2Vec이나 GloVe와 같은 사전학습된 단어벡터를 통한 지식의 이전(transfer)에 의존한다. 맥락과 관련된(contextualized) 단어벡터의 사용은 여러 task에서 획기적인 성공을 이뤘다. 이러한 모델들은 적은 수의 parameter만 학습시킬 필요가 있고 따라서 적은 데이터만 갖고 있어도 학습이 가능하다는 장점이 있다. 잘 fine-tuned 된 언어모델은 설명문 생성과 함께 조정될 때 더 효과적이며 언어적으로 상식 정보를 얻어낸다는 점도 실험적으로 증명되었다.


3. Common Sense Explanations(CoS-E)

이 CoS-E 데이터셋은 아마존의 MTurk(Amazon Mechanical Turk)를 통해 수집되었다. CQA 데이터셋은 question token splitrandom split 두 개로 이루어져 있다. CoS-E 데이터셋과 이 논문의 모든 실험은 더 어려운 random split 을 사용하여 진행되었다. CQA v1.11에 대한 CoS-E도 만들었다.

사람들은 질문, 선택지, 정답이 주어지면 “왜 이것이 가장 적절한 답으로 예측되었는가?”라는 질문을 받는다. 그리고

  • 주어진 정답이 왜 정답일지를 알려줄 수 있는 부분을 질문에서 선택하며,
  • 또한 이 질문 뒤에 숨어 있을 상식적인 내용을 설명하는 자연어 문구를 작성하도록

지시받았다. (참고: 이는 CoS-E 데이터셋의 설명과 일치함.)

그래서 CQA v1.0에 대해 7610(train random split) + 950(dev random split)개의 설명문을, v1.11에 대해 9741 + 1221개의 설명문을 수집하였다. 또한 여기서부터는 질문에서 선택된 부분을 CoS-E-selected, 작성한 자연어 문구(open-ended)는 CoS-E-open-ended 라 한다.

MTurk에서는 사람들의 답변의 품질이 좋다는 것을 보장할 수 없기 때문에, 다음과 같은 처리를 거쳤다:

  • 질문에서 아무 것도 선택하지 않거나
  • 작성한 설명문이 4단어 이하이면 답변하지 않은 것으로 처리되며
  • ‘이 정답은 답이 되는 유일한 것이다’와 같은 답변은 모두 제거하였다.
Examples

위 그림은 CoS-E v1.0 데이터셋의 분포를 보여준다.
이 논문의 실험에서는 CoS-E를 오직 학습(training) 과정에만 사용하여 SOTA 결과를 얻었으며, CoS-E 데이터셋을 사용한 경우가 그렇지 않은 경우보다 성능이 더 좋다는 것을 실험적으로 보였다.

CoS-E는 crowd-sourcing으로 얻어진 것이기 때문에 noisy할 수는 있지만 그만큼 다양성이 확보되었으며 충분한 품질을 갖고 있는 것으로 보인다고 한다.


4. 알고리즘(Algorithm)

CAGE(Commonsense Auto-Generated Explanations)를 제안하고 이를 CQA task에 적용한다. CAGE는 언어모델에 의해 생성되었으며 분류모델의 보조 입력으로 사용된다. CQA 데이터셋의 각 샘플은 질문 $q$, 선택지 $c0, c1, c2$, 정답 레이블 $a$로 구성된다. CoS-E 데이터셋은 왜 $a$가 가장 적절한지를 말해주는, 사람이 만든 설명문 $e_h$가 추가된다. CAGE의 출력은 생성한 설명문 $e$가 $e_h$에 가까워지도록 학습하는 언어모델이다.

4.1. Commonsense Auto-Generated Explanations(CAGE)

CAGE를 분류모델에 적용하기 위해, 언어모델(LM)을 CoS-E 데이터셋으로부터 설명문을 생성하도록 fine-tune했다. 이 언어모델은 여러 transformer 레이어로 이루어진, 사전학습된 OpenAI GPT이다.
여기서, 설명문 생성과 관련하여 두 가지 설정:

  1. 설명 후 예측(explain-and-then-predict(reasoning))
  2. 예측 후 설명(predict-and-then-explain(rationalization))

으로 진행하였다.

Reasoning

이 방법이 이 논문의 주된 접근법이다. 언어모델은 질문, 선택지, 사람의 설명문으로 fine-tuned 되었으며 실제 정답 label로는 학습되지 않았다. 그래서, 학습하는 동안 입력 문맥(context)은 다음과 같이 정의된다:

$ C_{RE} = “q, c0, c1 \ or\ c2? $ commonsense says

모델은 조건부 언어모델링 목적함수에 따라 설명문 $e$를 생성한다:

[\sum_i log P (e_i \vert e_{i-k}, …, e_{i-1}, C_{RE} ; \Theta )]

$k$는 문맥범위(context window)의 크기(이 논문에서는 항상 $ k \ge \vert e \vert $로 전체 설명문이 문맥에 포함됨)이다.
이 방식은 상식 질답 문제의 추론 단계에서 추가 문맥정보를 전달하기 위해 설명문을 자동생성하므로 reasoning 이라 부르기로 하였다.

또한 실험의 완전성을 위해, 추론과 설명의 단계를 바꿔보았는데, 그것이 다음에 설명할 rationalization이다.

Rationalization

언어모델은 post-hoc rationalization을 생성하기 위해 입력과 더불어 예측된 label을 조건으로 한다. 그래서 fine-tuning 단계에서 입력 문맥은 다음과 같다.

$ C_{RE} = “q, c0, c1 \ or\ c2?\ a$ because

목적함수는 reasoning의 것과 유사하지만 모델은 학습 중에도 입력 질문에 대한 실제 정답을 볼 수 있다. 언어모델은 예측 label에 조건을 갖기 때문에 설명문은 상식추론으로 고려될 수 없다. 대신 설명문은 모델이 더 이해 및 해석하기 쉽도록 만드는 rationalization 을 제공한다. 이 접근법은 현 최고의 모델보다 6% 더 높은 성능을 가지며 품질 좋은 설명문을 생성해 낸다.

CAGE에 대해서, 최대길이 20, batch size 36, 10 epoch 동안 학습시겨 가장 좋은 BLEU 점수와 perplexit를 갖는 모델은 선택했다. 학습률(learning rate)는 $1e^{-6}$, 초반 0.002까지 선형적으로 증가하다가(warm-up lr) 0.01만큼 decay되는 방식을 채택했다.

4.2. Commonsense Predictions with Explanations

CoS-E의 사람의 설명문이나 언어모델의 추론 중 하나를 갖고 있을 때 CQA task에 대한 예측모델을 학습시킬 수 있다. 모든 BERT 모델의 입력 샘플의 시작 부분에 들어가는 [CLS] token에 해당하는 최종 상태(final state)를 입력으로 받는 이진 분류기를 추가함으로써 다지선다형 질문 task에 fine-tuning 될 수 있는 BERT를 분류기로 사용하였다. 이를 CQA task에도 적용했는데,

  • 데이터셋의 각 샘플에 대해
    • BERT를 fine-tuning하기 위한 일련의 세 입력을 구성하고
    • 각 입력은 (질문, 구분자 [SEP], 선택지 중 하나)로 구성된다.
  • 만약 CoS-E나 CAGE의 설명문을 추가한다면
    • 각 입력은 (질문, 구분자 [SEP], 설명문, 구분자 [SEP], 선택지 중 하나)로 이루어진다.

BERT를 위해 설명문은 한 질문에 대해 같은 입력표현을 공유한다. 선택지에 대해서도 공유하는 것은 약간의 성능저하를 보였다.

4.3. Transfer to out-of-domain datasets

Out-of-domain NLP 데이터셋에 fine-tuning 없이 전이학습을 시키는 것은 낮은 성능을 기록한다고 알려져 있다.
이 논문에서는 CQA에서 SWAG와 Story Cloze Test(둘 모두 CQA같은 다지선다형이다)에 대해서 전이학습을 연구했다. CQA에 fine-tuned된 GPT 언어모델을 SWAG에 대한 설명문을 생성하기 위해 사용하였다. 그리고 이를 통해 BERT 분류기를 학습시켜 두 데이터셋에 평가를 진행했다.


5. 실험 결과(Experimental Results)

모든 모델은 BERT에 기초하며, CoS-E나 CAGE를 쓰지 않을 것이 baseline이 되며, 모든 실험은 CQA dev-random-split에서 수행되었다. 또한 final test split에서도 핵심 모델을 평가하였다.

CoS-E 설명을 사용할수록 성능이 높아짐을 확인할 수 있다.

Examples

아직 사람에 비해서는 모든 모델이 한참 못 미치지만, CoS-E와 CAGE를 사용함으로써 성능이 좋아졌다.

Examples

위의 표의 마지막에 있는 89.8%이라는 수치는 설명문을 제공받은 사람은 실제 정답을 갖고 있었기 때문에 공정한 수치는 아니라고 하지만, CoS-E-open-ended를 사용했을 때 얼마만큼 성능을 향상시킬 수 있을지에 대한 상한선을 보여준 것이라 한다. 또한 질문이 없는 상태에서 진행한 실험도 있는데, 질문 없이 어떤 정답이 가장 정답일 것 같은지를 설명문을 보고 판단하는 실험이다.
그리고 open-ended CoS-E의 경우 질문에 이미 있는 쓸모 있는 정보를 알려주는 것을 넘어 중요한 정보를 제공한다는 것을 보여준다.

Examples

CQA v1.11에 대한 실험도 진행하였고 그 결과는 위 그림에서 볼 수 있다.

전이학습에 대한 결과는 아래 그림에서 볼 수 있는데, CQA에서 SWAG와 Story Cloze로 전이된 설명문을 추가한 경우 약간의 성능저하가 있음을 보였다.

Examples

6. 분석 및 토의(Analysis and Discussion)

CAGE-reasoning은 72%의 성능을 보였는데, CoS-E-open-ended의 모든 정보를 활용한다면 최대 90% 정도까지 성능이 올라갈 수 있음을 보였기 때문에, 추가적인 분석이 더 필요하다.
CAGE-reasoning과 CoS-E-open-ended 간 BLEU 점수는 4.1이며 perplexity는 32를 보였다.

아래 그림은 CQA, CoS-E, CAGE 샘플을 가져온 것인데, CAGE-reason이 일반적으로 CoS-E보다 조금 더 간단한 구성을 보이는데, 이 조금 더 선언적인 부분이 CoS-E-open-ended보다 더 유익한 경우가 있다(실제 단어 차이는 거의 없다). CAGE-reasoning은 43%의 경우에서 선택지 중 적어도 하나를 포함하는데, 모델의 실제 예측 선택지는 21%만이 그러하였다. 이는 답을 직접적으로 가리키는 것보다 더 효과적인 부분이 CAGE-reasoning에 있음을 보여준다.

Examples

CAGE-rationalization이 CAGE-reasoning보다 조금 더 나은 것 같기도 하지만, 실제 질문 없이 정답을 추측하는 부분에서는 별 향상이 없다.

CoS-E나 CAGE가 noisy하다고 해도, 모델의 성능이 낮은 것이 이것 때문이라 볼 수는 없다. 만약 CQA의 세 선택지 중 하나를 호도하는 선택지로 일부러 바꾼 경우 모델의 성능은 60%에서 30%로 떨어졌다. 에러의 70%는 호도하는 설명문에 의해 만들어졌고, 그 중 57%는 대신 CoS-E 설명문으로 학습된 모델에 의해 올바르게 정답을 맞췄다. 이는 유익한 설명문의 효과를 보여준다.

CQA v1.11에서는 BERT를 1.5% 차이로 앞섰는데, CQA v1.11에서 잘못 예측한 예시는 아래에서 볼 수 있다. 잘못 예측한 것 중 많은 부분은 생성된 설명문에 맞는 정답을 포함하는 경우가 있었다(dresser drawer과 cleanness 등). 이러한 경우는 관련 있는 정보에 더 집중하도록 하는 명시적인 방법이 필요로 함을 보여준다. 그리고 “forest”와 “compost pile” 같은 의미적으로 비슷한 다른 선택지를 고르는 경우도 빈번했는데, 이는 새로운 CQA 데이터셋에서 설명문을 단지 덧붙이는 것만으로는 충분하지 않음을 보여준다.

Examples

SWAG와 Story Cloze에 맞춰 생성한 설명문은 유익한 정보를 담고 있는 것을 발견했지만, 전이학습에 대한 실험에서 분류기가 이를 제대로 활용하지는 못했다.

Examples

7. 결론 및 향후 연구(Conclusion and Future Work)

CoS-E라는 새로운 데이터셋을 제시하였고, CAGE framework를 제안하였으며, 여기서 생성된 설명문(explanations)은 예측을 위해 분류기에서 효율적으로 사용될 수 있었다. 이로써 단지 SOTA를 달성한 것 뿐만 아니라, 이해할 수 있는(interpretable) 상식추론과 관련해 설명문을 연구하는 새로운 길을 열었다.

CAGE는 답을 예측하기 위한 사전 작업으로 설명문을 생성하는 데 집중했는데, 설명문을 통한 언어모델은 정답 예측에 있어 함께 학습될 수도 있다. 이는 더 많은 task에 적용될 수 있을 것이다. 많은 task에 대해 충분한 설명문 데이터셋(CoS-E)가 있으면 다른 task에 대해서도 유용한 설명문을 생성하는 언어모델을 만들 수도 있다.

그리고, 설명문은 편향이 없어야 할 것이다. 예를 들어 CQA에서는 ‘여성’과 ‘부정적인 문맥’의 연관도가 다른 쪽에 비해 더 높았는데, 이러한 편향이 있음은 모델 학습에 있어 분명 고려되어야 한다.

Acknowledgements

언제나 있는 감사의 인사. 그림과 reviewer 등등


Refenrences

논문 참조. 많은 레퍼런스가 있다.


Comment  Read more

파이썬 Error 처리

|

1. Introduction

파이썬에서 에러를 처리하고 관리하는 데에는 다양한 이유가 있다. 실제 Applicaion 상에서 에러가 발생하지 않도록 개발과 테스트 단계에서 미리 에러를 식별하고 수정하는 것은, 어떤 프로그램을 만들 때 굉장히 중요한 과정이라고 할 수 있다.

기본적으로 파이썬에서는 BaseException이라는 class를 통해 에러를 관리하도록 도와준다. 이 class는 모든 내장 exception들의 base class이다. 만약 사용자가 직접 에러 class를 만들고 싶을 때는 이 에러를 사용하는 것이 아니라 Exception class를 사용해야 한다.

코딩을 하다보면 여러 종류의 에러를 보았을 것이다. 예를 들어 아래와 같은 에러가 대표적일 것이다.

ValueError
AssertionError
FileNotFoundError
SyntaxError

대체 이 에러들은 다 어떻게 만들어지고, 어떻게 구성되는 것일까? 사실 이 에러들은 앞서 설명한 BaseException class의 하위 class로 이루어진다. 그 전체 구조는 아래와 같다.

BaseException
 +-- SystemExit
 +-- KeyboardInterrupt
 +-- GeneratorExit
 +-- Exception
      +-- StopIteration
      +-- StopAsyncIteration
      +-- ArithmeticError
      |    +-- FloatingPointError
      |    +-- OverflowError
      |    +-- ZeroDivisionError
      +-- AssertionError
      +-- AttributeError
      +-- BufferError
      +-- EOFError
      +-- ImportError
      |    +-- ModuleNotFoundError
      +-- LookupError
      |    +-- IndexError
      |    +-- KeyError
      +-- MemoryError
      +-- NameError
      |    +-- UnboundLocalError
      +-- OSError
      |    +-- BlockingIOError
      |    +-- ChildProcessError
      |    +-- ConnectionError
      |    |    +-- BrokenPipeError
      |    |    +-- ConnectionAbortedError
      |    |    +-- ConnectionRefusedError
      |    |    +-- ConnectionResetError
      |    +-- FileExistsError
      |    +-- FileNotFoundError
      |    +-- InterruptedError
      |    +-- IsADirectoryError
      |    +-- NotADirectoryError
      |    +-- PermissionError
      |    +-- ProcessLookupError
      |    +-- TimeoutError
      +-- ReferenceError
      +-- RuntimeError
      |    +-- NotImplementedError
      |    +-- RecursionError
      +-- SyntaxError
      |    +-- IndentationError
      |         +-- TabError
      +-- SystemError
      +-- TypeError
      +-- ValueError
      |    +-- UnicodeError
      |         +-- UnicodeDecodeError
      |         +-- UnicodeEncodeError
      |         +-- UnicodeTranslateError
      +-- Warning
           +-- DeprecationWarning
           +-- PendingDeprecationWarning
           +-- RuntimeWarning
           +-- SyntaxWarning
           +-- UserWarning
           +-- FutureWarning
           +-- ImportWarning
           +-- UnicodeWarning
           +-- BytesWarning
           +-- ResourceWarning

굉장히 많다. 이 에러와 경고(Warning)들을 다 외우고 있을 필요는 없을 것이다. 하지만 인지는 하고 있는 편이 좋다.


2. Exception 처리: try, except, finally

2.1. 일반적인 처리

try 블록을 수행하는 과정에서 에러가 발생하면 except 블록이 수행된다. 만약 에러가 발생하지 않았다면, except 블록은 수행되지 않는다. 만약 에러의 발생 유무와 상관없이 꼭 어떤 과정을 수행하고 싶다면 finally 블록에 이를 담으면 된다.

# 예시 1
try:
    import nothing
except ImportError as error:
    print(error)
finally:
    import numpy as np
    print(np.array([1, 2]))


No module named 'nothing'
[1 2]

# 예시 2
try:
    print(3/0)
except ZeroDivisionError:
    print("Error: You cannot divide integer by zero")

Error: You cannot divide integer by zero

참고로 assert 조건, "에러 메시지"assert 구문을 통해 에러를 관리할 수도 있다.

2.2. 특별한 요청

아래에는 위와는 다르게 조금은 특별한(?) 요청을 하고 싶을 때 사용할 수 있는 기능들이다.

  • 만약 에러를 그냥 회피하고 싶다면 except 블록에 pass를 입력하면 된다.
  • Exception이 발생하였을 때 프로그램을 중단하고 싶으면 raise SystemExit을 except 블록에 입력하면 된다.
  • Exception을 일부러 발생하고 싶을 때에도 raise 구문을 사용하면 된다.

3번 째 경우에 대한 예시를 첨부하겠다. BaseBandit이라는 부모 class가 있고, 사용자는 이 부모 class를 상속받아 TalkativeBandit이라는 자식 class를 만들고 싶다고 하자.

그런데 이 때, 자식 class에 반드시 operate이란 메서드를 구현하도록 미리 설정을 해두고 싶다. 모니터 구석에 메모를 해두는 것 외에 방법이 없을까? 이 때 부모 class인 BaseBandit에 미리 아래와 같은 코드를 구현해 놓으면 원하는 바를 쟁취할 수 있을 것이다.

# 부모 class 구현
class BaseBandit:
    def operate(self):
        raise NotImplementedError

# 자식 class 구현
class TalkativeBandit(BaseBandit):
    def stay(self):
        print("Don't talk")

tb = TalkativeBandit()

# 자식 class에서는 operate 메서드를 구현하지 않았으므로
# 부모 class의 operate 메서드가 호출된다.
tb.operate()

# 에러가 발생한다.
Traceback (most recent call last):
  File "C:\Users\...\interactiveshell.py", line 2961, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-17-fdf0f46c74b7>", line 1, in <module>
    tb.operate()
  File "<ipython-input-12-af85936c9668>", line 3, in operate
    raise NotImplementedError
NotImplementedError

operate 메서드를 제대로 구현한다면, 별 문제 없이 코드를 진행할 수 있을 것이다.


3. Exception 추적

바로 위의 예시를 보자. Traceback (most recent call last)란 문구를 볼 수 있을 것이다. 이는 Exception을 역으로 추적한다는 뜻이다.

사용자가 직접 추적 과정을 만들고 싶을 때 stack trace를 표시하고 출력하는 traceback 모듈과 로그 기록을 관리하는 logging 모듈을 사용하면 편리하다.

가장 기초적인 추적 방법은 아래와 같다.

import traceback

try:
    tuple()[0]
except IndexError:
    print("--- Exception Occured ---")
    traceback.print_exc(limit=1)

# 출력 결과
--- Exception Occured ---
Traceback (most recent call last):
  File "<ipython-input-19-0acccd16d042>", line 2, in <module>
    tuple()[0]
IndexError: tuple index out of range    

빈 튜플에 indexing을 시도했으므로 에러가 발생하는 것은 당연하다.
그 에러는 IndexError 인데, 우리는 traceback.print_exc 메서드를 통해 stack trace 정보를 출력할 수 있다.

limit=None이 기본이며 이 때는 제한 없이 stack trace를 출력한다. 위 예시와 같이 1을 입력하면 단 한 개의 stack trace 정보를 출력한다는 뜻이다. file, chain argument 설정을 통해 파일 출력 위치를 설정하거나 연쇄적인 Exception 출력 설정을 관리할 수 있다.

왜 이런 과정을 거쳐야 할까? 만약 이와 같이 try-except를 통해 Exception을 관리해주지 않는다면, 우리는 모든 에러를 잡기 전까지 프로그램 전체를 돌릴 수 없을 것이다.

이번에는 logging 모듈과 합작하여 Exception을 추적해보자.

import traceback
import logging

logging.basicConfig(filename="example.log", format="%(asctime)s %(levelname)s %(message)s")

try:
    tuple()[0]
except IndexError:
    logging.error(traceback.format_exc())
    raise

# 출력 결과
Traceback (most recent call last):
  File "C:\Users\...\interactiveshell.py", line 2961, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-18-16da8da0daa5>", line 6, in <module>
    tuple()[0]
IndexError: tuple index out of range

logging 모듈을 통해 우리는 example.log라는 파일에 에러에 관한 기록을 해둘 수 있었다.
이 파일에는 다음과 같은 로그 기록이 남아있다.

2020-01-12 18:38:50,633 ERROR Traceback (most recent call last):
  File "<ipython-input-18-16da8da0daa5>", line 6, in <module>
    tuple()[0]
IndexError: tuple index out of range

4. Exception 만들기

Exception class 상속을 통해 Exception을 직접 만들 수 있다.

import numpy as np

class SizeError(Exception):
    # 에러 메시지를 출력하고 싶으면 아래와 같은 특별 메서드를 구현해야 한다.
    def __str__(self):
        return "Size does not fit"
    
# 기준이 되는 base
base = np.eye(3)

# 비교대상인 data
data1 = np.array([[1,2], [3,4]])
data2 = np.ones((3, 3))

# np.array의 shape을 비교하는 함수이다.
def compare(base ,data):
    if base.shape != data.shape:
        raise SizeError()
    else:
        print("All Clear")

# 첫 번째 테스트
compare(base=base, data=data1)

# 첫 번째 결과
Traceback (most recent call last):
  File "C:\Users\...\interactiveshell.py", line 2961, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-36-c1718418c4b8>", line 1, in <module>
    compare(base=base, data=data1)
  File "<ipython-input-35-8ec7197ddfb7>", line 3, in compare
    raise SizeError()
SizeError: Size does not fit

# 두 번째 테스트
compare(base=base, data=data2)

# 두 번째 결과
All Clear

Reference

파이썬 공식문서
참고 블로그1 참고 블로그2

Comment  Read more

파이썬 압축 모듈 간단 예시

|

1. zlib 모듈

import zlib

long_text = b"who are you" * 1000
# 압축하기
compressed = zlib.compress(long_text)

# 압축 풀기
decompressed = zlib.decompress(compressed)

# 동일한지 확인
print(long_text == decompressed)

True

2. gzip 모듈

위에서 사용한 zlib 모듈과 동일하게 compress, decompress 메서드를 사용한다. 파일을 열 때는 open 메서드를 이용하면 된다. 여는 작업에 대한 코드만 첨부한다. bzip2(bz2), lzma(xz) 형식 파일에 대해서도 유사한 메서드를 이용한다.

import gzip

with gzip.open("data.gz", "rt") as file:
    content = file.read()

3. zipfile 모듈

import zipfile

# zip 파일이 맞는지 확인
zipfile.is_zipfile("trasnactions.zip")

# zip 파일 열기
zip = zipfile.ZipFile("trasnactions.zip")

# zip 파일 내 이름 확인 및 추후 사용을 위해 저장
names = []
for name in zip.namelist():
    names.append(name)

print(names)

['transaction1.txt', 'transaction2.txt']

# 첫 번째 파일 압축 해제 과정
# 하나만 압축 해제할 때
# ZipInfo 얻기
zipinfo = zip.getinfo(names[0])
print("Filename: ", zipinfo.filename, "date_time: ", zipinfo.date_time)

Filename:  transaction1.txt date_time:  (2020, 1, 11, 19, 44, 28)

zip.extract(zipinfo)

# 전부 압축 해제할 때
zip.extractall()

# 끝나고 닫아주기
zip.close()

4. tarfile 모듈

위와 유사하다.

import tarfile

# tarfile이 맞는지 확인
tarfile.is_tarfile("transactions.tar")

tar = tarfile.open("transactions.tar")
tar.getnames()

['transaction1.txt', 'transaction2.txt']

# 하나만 압축 해제
tarinfo = tar.getmember(tar.getnames()[0])
print(tarinfo.name, tarinfo.size, tarinfo.mtime, tarinfo.mode)

transaction1.txt 74 1578739467 493

tar.extract(tarinfo)

# 전체 압축 해제
tar.extractall()
tar.close()

Reference

파이썬 라이브러리 레시피, 프리렉 https://docs.python.org/3/library/zipfile.html https://docs.python.org/3/library/tarfile.html

Comment  Read more

파이썬 collections, heapq 모듈 설명

|

1. collections 모듈

1.1. collections.Counter 객체

collections 모듈에서 가장 기본을 이루는 class는 collections.Counter이다. 이 class에 argument로 반복 가능한 (iterable) 객체를 지정하거나 dictionary와 같은 mapping 객체를 지정하면 Counter 객체를 생성할 수 있다. 예를 들어보면,

import collections

counter = collections.Counter([1, 2, 3, 2])
# counter = collections.Counter({1: 1, 2: 2, 3: 1})
print(counter)

Counter({1: 1, 2: 2, 3: 1})

주석 처리된 line이 바로 후자의 방법에 해당한다. 이렇게 생성된 객체는 수정될 수 있다.

counter[1] += 1
print(counter)

Counter({1: 2, 2: 2, 3: 1})

이 외에도 여러 계산이 가능한데, 아래를 참고하길 바란다.

연산자 설명
-= 뺀다. 결과가 음수면 그 요소는 삭제된다.
&= 좌변의 Counter 객체 요소 중 우변의 Counter 객체 요소에 미포함되어 있는

key의 요소를 삭제한다. 요소의 값은 둘 중 작은 쪽의 값이 된다.
l= 2개의 Counter 객체 전체의 요소로부터 새롭게 Counter 객체를 생성한다.

key가 같으면 두 값 중 큰 쪽의 값이 된다.

위 누계 연산자에서 =를 빼고 +, -, &, | 만 사용할 경우 이항 연산자로 작용한다.

또한, 이 객체에서 미등록 key를 참조한다 하더라도 KeyError는 발생하지 않는다.

print(counter[4])

0

1.2. collections.ChainMap: 사전 통합

dict1 = {'banana': 1}
dict2 = {'apple': 2}

counter = collections.ChainMap(dict1, dict2)
print(counter['apple'])

2

위와 같이 ChainMap 메서드는 여러 사전 객체를 모아 하나로 통합하는 기능을 갖고 있다. 만약 통합한 객체에 변화를 줄 경우, 원래의 사전들에도 그 변경 사항이 반영된다. clear 메서드를 사용하면 사전을 삭제할 수 있다.

1.3. collections.defaultdict: 기본 값이 있는 사전

일반적으로 사전 객체에 미등록된 key를 참조하면 KeyError가 발생한다. collections.defaultdict는 이러한 문제를 해결하기에 적합한 객체이다.

d = {'orange': 10}

def get_default_value():
    return 'default-value'

# 여기서 get_default_value와 같은 callable 객체나 None을 입력할 수 있다.
# None을 입력할 경우 일반 사전과 마찬가지로 KeyError가 발생한다.
e = collections.defaultdict(get_default_value, orange=10)
print(e['ham'])

'default-value'

만약 기본 값으로 수치 0이나 빈 사전, 리스트를 반환하고 싶다면 int, dict, list형 객체를 지정하면 된다.

e = collections.defaultdict(int)
e = collections.defaultdict(dict)
e = collections.defaultdict(list)

1.4. collections.OrderedDict: 순서가 있는 사전

for loop와 같은 과정 속에서 등록한 순서대로 요소를 추출하고 싶으면 이 class를 이용하면 좋다. 시퀀스를 이용하여 객체를 생성하면 순서대로 등록된 것을 확인할 수 있다.

mydict = collections.OrderedDict([("orange", 10), ("banana", 20)])
print(mydict)

OrderedDict([('orange', 10), ('banana', 20)])

그러나 키워드 인수나 일반 사전으로 초깃값을 등록하면 순서가 무시된다. OrderedDict 객체에는 유용한 기능들이 있는데, 아래를 참조하면 좋을 것이다.

mydict = collections.OrderedDict([("orange", 10), ("banana", 20), ("blueberry", 30), ("mango", 40)])

# popitem 에서 last=True로 하면 마지막 요소를 사전에서 삭제하고 반환하고,
# False로 하면 첫 요소에 효과를 적용한다.
mydict.popitem(last=True)

# move_to_end에서 last=True로 하면 지정한 키를 맨 끝으로 이동시키고, False이면 맨 처음으로 이동시킨다.
mydict.move_to_end(key="banana", last=True)

print(mydict)

OrderedDict([('orange', 10), ('blueberry', 30), ('banana', 20)])

1.5. collections.namedtuple

데이터를 효율적으로 관리하기에 적합한 class가 바로 namedtuple이다. 속성 이름을 지정하여 가독성을 높이고 튜플을 활용하여 원하는 요소를 쉽게 추출하도록 하게 해준다.

point = collections.namedtuple("point", "X, Y, Z")
data = point(-2, 6, 3)
print(data.Y)

6

2. heapq 모듈

데이터를 정렬된 상태로 저장하고, 이를 바탕으로 효율적으로 최솟값을 반환하기 위해서는 이 heapq 모듈을 사용하면 매우 편리하다. 사용하기 위해서는 최소 heap을 먼저 생성해야 한다. 빈 리스트를 생성해서 heapq 모듈의 메서드를 호출할 때마다 이를 heap argument의 인자로 투입해야 한다.

import heapq

heap = []

# heappush(heap, item): heap에 item을 추가함
# 주의점: keyword 인자를 입력하면 Error가 발생함
heaqp.heappush(heap, 2)
heaqp.heappush(heap, 1)

# heappop(heap): heap에서 최솟값을 삭제하고 그 값을 반환함
# 최솟값을 삭제하지 않고 참조하고 싶다면 heap[0]을 쓰자
heapq.heappop(heap)

1

이 외에도 여러 메서드를 사용할 수 있다. 만약 어떤 변화하는 시퀀스에서 최솟값을 얻고 싶다고 하자. 아래와 같은 코딩이 가능하다.

heap = [79, 24, 50, 62]

# heapify(heap): heap의 요소를 정렬함
heapq.heapify(heap)

# heappush(heap, item): heap에 item을 추가한 뒤, 최솟값을 삭제하고 그 값을 반환함
heapq.heappushpop(heap, 10)

10

# heapreplace(heap, item): 최솟값을 삭제한 뒤, heap에 item을 추가하고 삭제한 값을 반환함
# 주의점: 추가한 값 아님
heapq.heapreplace(heap, 10)

24

Reference

파이썬 라이브러리 레시피, 프리렉

Comment  Read more