Improving Language Understanding by Generative Pre-Training (GPT)

Author

  • 저자:Alec Radford, Karthik Narasimhan, Tim Salimans, Ilya Sutskever (Open AI, Open AI다! 부럽(?)다)

Who is an Author?

Alec Radford라는 친군데, GPT논문 인용수가 젤 많겠지 했는데 오히려 Vision쪽에서 한 Generative model 인용수가 넘사임.. 원래 유명한 친구였음

{: height=”50%” width=”50%”}

느낀점

  • 작은 변화가 큰 성능의 변화를 가져다줌
    • Add auxiliary objective
    • pre-training LM
자세히 보기

Research to Production

Research

  • 개발 기간이 필요함
  • 어떤 데이터를 쓸지 어떤 데이터를 모을 수 있을지 어디까지 라벨링 할 수 있을지, 어떤 데이터로 원하는 데이터를 비슷하게 대체할 수 있을지 등을 생각해야함
  • 대략적인 시간을 산정해서 보고해야함
  • 논문을 많이 읽으면 읽을수록 좋긴함
  • 갖다 쓸수있는건 빠르게 갖다 써야함
    • 케글이나 이런데서 빠르게 참조할 필요가 있음
  • 프로토 타이핑은 매우 빠르게~!
  • 개인적으로는 처음부터 좋은 모델보단 baseline부터 서서히 올려가는게 결과를 확인하고 model capacity를 조정하면서 추후 모델 선택할 때 좋음
  • Speed한 프로토타이핑이 생명 (빠르게 짜는게 중요함, gpu로 학습한다고 노는것도 별로 안좋음)
  • Hyper Params 에 대한 실험 관리 + feature에 대한 실험 관리 도구가 좀 필요함
  • git 관리를 잘해야함
  • 안해본 것에 대한 두려움이 없어야함
  • DL Framework
    • Prototyping: PyTorch
    • Service: TensorFlow or PyTorch
      • eager mode로 logit + loss 까지 tensor format & shape 확인
      • graph mode로 학습시켜서 pb 추출
  • AutoML: 어떤 오픈소스 쓸지 TBD
  • 앙상블까지 고려해야함
    • Model 관리하는 configuration 부분이 매우 귀찮아질 수 있음 (여러개의 모델을 사용하기 때문에)
    • Data driven Software 될 수 있게 코드단이 아니라 configuration으로 모델의 구조를 변경 할 수 있어야함 (caffe나 claf 처럼)
  • 처음 모델 짤때는 파이프라인+간단한 구조부터해서 구조를 업데이트하는 쪽으로 방향을 잡고 짜야함
  • 모델평가를 쉽게 돌리고 비교할 수 있는 파이프라인..!이 필요함
  • feature store를 어떻게 구성할지, 실시간 학습 어떻게 구성할지 고민

Production

  • 환경셋팅 문서화 (한번에 뜨고 설치할 수 있게 도커가 그립다)
  • 클래스, 플로우 다이어그램: PlantUML (https://meetup.toast.com/posts/117)
  • 다이어그램 & 마인드맵 그리고 개발하면 좋음
  • L4 (Load Balancer)
    • L4에서는 1초간 계속 health check를 해서 서버 하나가 꺼지면 떼버리고 다시 살아있으면 붙임
    • 반응못하면 아마 500에러 낼듯
  • 네트워크 프로토콜
  • healthcheck
    • 프로세스 관리
    • JandiAlert
  • 부하테스트
    • 실서버와 동일한 환경인 Sandbox가 필요함
    • nGrinder
  • 프로파일링
    • Network Distillation
  • TC 작성 (testcase)
  • DB 연결 부분은 local에서도 테스트 할 수 있게끔 default value를 하나 만들어줘서 debug할 수 있게 해야함
  • pylint등으로 개발스타일 통일
  • 로그 관리
  • 안해본 것에 대한 두려움이 없어야함
  • Jandi Alert Code
  • 상용에서는 로그를 남기기 때문에, 모듈별로 테스트할때 로그가 남을 수 있는데 그러면 안됨! 왜냐하면, 로그를 모듈별로 일치시켜줘야하기 때문에~!(ex, 채팅 클라이언트/채팅API/챗봇엔진) 그러므로 로그를 안남기기 위한 API 테스트를 고려해서 인터페이스를 설계해야함 (로그를 안남기거나, 테스트를 위한 로그를 따로 남겨야함)
  • 디펜던시 없는 테스트(DB, API 서버등..과 분리)를 위해 테스트 케이스와 모듈을 만들어놔야함. 그래야 배포때 편함.
  • 서버 실행시 자원 얼마나 소모하는지 모니터링, 체크
  • 패치 프로세스 기록 필요함, 연동 테스트용 코드도.
  • Script화 해놔서 다른 사람이 언제든지 사용할 수 있게 해야함.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
import json
import requests
import linecache
import sys
import os

def jandi_alert(body, server, webhook_url, api="name of API"):
"""
ref: https://drive.google.com/file/d/0B2qOhquiLKk0TVBqc2JkQmRCMGM/view

ERROR_COLOR = "#FF0000";
INFO_COLOR = "#0000FF";
WARNING_COLOR = "#FFFF00";
DEFAULT_COLOR = "#FAC11B;
"""

# ref: https://stackoverflow.com/questions/14519177/python-exception-handling-line-number
exc_type, exc_obj, tb = sys.exc_info()
f = tb.tb_frame
lineno = tb.tb_lineno
file_name = f.f_code.co_filename
linecache.checkcache(file_name)
line = linecache.getline(file_name, lineno, f.f_globals)
# print 'EXCEPTION IN ({}, LINE {} "{}"): {}'.format(filename, lineno, line.strip(), exc_obj)
file_name = os.path.basename(file_name)

payload = {
"body": body,
"connectColor": "#FF0000",
"connectInfo": [{
"title": "___ 서버 이상",
"description": "server: {}\napi: {}\nfile_name: {}\nLINE {} '{}': {}".format(server, api, file_name, lineno, line.strip(), exc_obj)
}]
}

requests.post(
webhook_url, data=json.dumps(payload),
headers={'Accept': 'application/vnd.tosslab.jandi-v2+json',
'Content-Type': 'application/json'}
)


자세히 보기

gPRC + Healthcheck 뽀개기

gRPC 개념 설명

gRPC 사용할 때 주의할점

  • retry 이슈
    • gRPC는 HTTP2 기반인데, 양방향 통신이라 커넥션을 계속 붙잡고 있는데, 이게 가끔 30분에 한번씩 끊길때가 있다 (뭐가 헤더 크기를 넘어가면서..어쩌구저쩌구 들었던거 같은데 다시 찾아봐야함)
    • 그럴땐 클라이언트 쪽에서 보낸 요청이 fail되고 서버가 못듣게 되는데 단순히 클라가 한번 더 retry해주면 된다.
    • 보통 http2를 쓰는 프로토콜은 retry 로직이 필수라한다
  • 헬스체크 이슈 (ulimit, channel close, Too many open files)
    • grpc는 status 를 제공하고 health check 프로토콜도 제공한다. 어찌다가 try except으로 에러날때 status 코드를 꺼내는 방식으로 꼼수로 구성한적이 있었다..(이럼 안되지.. 이것 때문에 연차썼다가 출근해서 반차처리한 적이..흑흑)
    • 이때 grpc connect을 따로 close해주지 않으면 소켓연결이 쌓이게 되고 리눅스 운영체제에서 file open개수에 대한 ulimit을 초과하면 Too many open files 에러가 뜬다
    • 보통 이런경우 ulimit을 올려주면 되지만, 근본적인 에러원인인 소켓 증가 이유를 찾아야했고 찾다보니 health check때 retry 이슈로 except뜬게 쌓이고 있었다는 결론을 내렸다
    • 결과적으로 connect close를 잘해주자 안그러면 too many file opens 에러뜨니까

gRPC.proto 살펴보기

  • filename: projectname.proto
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// Copyright 2015 The gRPC Authors
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.eagle705.demogrpc.proto.projectname";
option objc_class_prefix = "projectname_prefix";

package projectname;

// Interface exported by the server.
service Chatbot {
// A simple RPC.
//
// Obtains the feature at a given position.
//
// A feature with an empty name is returned if there's no feature at the given
// position.

rpc 호출할함수명(input자료구조명) returns (stream output자료구조명) {}

// A server-to-client streaming RPC.
//
// Obtains the Features available within the given Rectangle. Results are
// streamed rather than returned at once (e.g. in a response message with a
// repeated field), as the rectangle may cover a large area and contain a
// huge number of features.
// rpc ListFeatures(Rectangle) returns (stream Feature) {}

// A client-to-server streaming RPC.
//
// Accepts a stream of Points on a route being traversed, returning a
// RouteSummary when traversal is completed.
// rpc RecordRoute(stream Point) returns (RouteSummary) {}

// A Bidirectional streaming RPC.
//
// Accepts a stream of RouteNotes sent while a route is being traversed,
// while receiving other RouteNotes (e.g. from other users).
// rpc RouteChat(stream RouteNote) returns (stream RouteNote) {}
}

// 프로퍼티에 입력되는 값을 순서를 의미하는 듯?!(TBD: 확인필요)
message input자료구조명 {
string 프로퍼티1 = 1;
int32 프로퍼티2 = 2;
repeated int32 프로퍼티3 = 3; // repeadted는 리스트를 뜻하는 듯
string 프로퍼티4 = 4;
}

message output자료구조명 {
int32 프로퍼티1 = 1;
double 프로퍼티2 = 2;
}
자세히 보기

SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing

Author

Who is an Author?

{: height=”50%” width=”50%”}

장점

  • 언어에 상관없이 적용 가능
  • OOV 대처 가능
  • 적은 vocab size로 높은 성능기록
  • 빠름

Note

자세히 보기

BERT- Pre-training of Deep Bidirectional Transformers for Language Understanding

Author

  • 저자:Jacob Devlin, Ming-Wei Chang, Kenton Lee, Kristina Toutanova (Google AI Language, Google AI니 말다했지)

Who is an Author?

Jacob Devlin is a Senior Research Scientist at Google. At Google, his primary research interest is developing fast, powerful, and scalable deep learning models for information retrieval, question answering, and other language understanding tasks. From 2014 to 2017, he worked as a Principle Research Scientist at Microsoft Research, where he led Microsoft Translate’s transition from phrase-based translation to neural machine translation (NMT). He also developed state-of-the-art on-device models for mobile NMT. Mr. Devlin was the recipient of the ACL 2014 Best Long Paper award and the NAACL 2012 Best Short Paper award. He received his Master’s in Computer Science from the University of Maryland in 2009, advised by Dr. Bonnie Dorr.

{: height=”50%” width=”50%”}

느낀점

  • Masking 기반의 Language Model과 context 추출을 위한 문장 연관성 (NSP) Task를 동시에 학습시켜서 Rich representation을 얻는다는 아이디어가 참신했음. 두마리 토끼를 한번에..!
  • Bidirectional feature가 상당히 중요함
  • pre-train 중요함
  • NSP도 매우 중요함
  • 여기서도 Loss Masking이 중요함
  • CLS Loss와 LM Loss를 따로 떼서 계산해야함
  • gelu, masking scheme 썼을때와 안썼을때 성능차이가 꽤 남
  • segment embedding 처리하는게 은근 귀찮음, 전처리 할때 아예 생성해버리는게 편하긴함
  • CLS acc 올리기보다 LM acc 올리는게 더 쉬움
자세히 보기

Attention Is All You Need

이번엔 오늘날의 NLP계의 표준이 된 Transformer를 제안한 논문인 Attenion Is All You Need에 대해서 리뷰해보고자 한다. 대략적인 내용은 이미 알고 있었지만, 디테일한 부분도 살펴보고자 한다.

Author

  • 저자: Ashish Vaswani, 외 7명 (Google Brain)
  • 구글브레인..wow
  • NIPS 2017 accepted

Who is an Author?

{: height=”50%” width=”50%”}

느낀점

  • Multi-Head-Attention을 빠르게 구현하기 위해 Matrix 연산으로 처리하되, Embedding Tensor를 쪼갠 후 합치는게 아닌 reshape & transpose operator로 shape을 변경 후 한꺼번에 행렬곱으로 계산해서 다시 reshape 함으로써 병렬처리가 가능하게끔 구현하는게 인상적이었음
  • 행렬곱할 때 weight 와 곱하는건 weight variable 생성 후 MatMul 하는게 아니라 그냥 다 Dense로 처리하는게 구현 팁이구나 느꼈음
  • 요약: 쪼갠다음에 weight 선언 후 매트릭스 곱? No! -> 쪼갠 다음에 Dense! -> 쪼개면 for loop 때문에 병렬처리 안되잖아! -> 다 계산후에 쪼개자!
  • Attention만 구현하면 얼추 끝날 줄 알았는데 Masking 지분이 70~80%였음
    • Masking은 logical 연산 (boolean)으로 padding 체크해서 하는게 일반적임
    • Masking은 input에도 해주고 loss에도 해줌
    • 마스킹 적용할땐 broadcasting 기법을 써서 하는게 일반적임
    • 아래의 두 경우 모두 가능함
      • ex) (40, 5, 10, 10) + (40, 1, 1, 10) == (batch, head, seq, seq)
      • ex) (40, 5, 10, 10) + (40, 1, 10, 10) == (batch, head, seq, seq)
자세히 보기

Neural Machine Translation in Linear Time

Author

  • 저자:Nal Kalchbrenner, Lasse Espeholt, Karen Simonyan, Aaron van den Oord, Alex Graves, Koray Kavukcuoglu (Google Deepmind, London UK)
  • 딥마인드 (말 다했다)

Who is an Author?

{: height=”50%” width=”50%”}

Abstract

  • 이 당시엔 Novel architecture였다 (2016년, 후에 Attention is all you need 논문에서도 인용함)
  • ByteNet이라고 부름

{: height=”50%” width=”50%”}

자세히 보기

광교호수공원 드론 촬영

[190413] 광교호수공원에서 드론 촬영한거 몇가지 기록 남겨보고자한다. 개인적으로는 너무 만족스러웠다:)

자세히 보기

Deep contextualized word representations(ELMo)

요즘 Transformer가 나오면서 NLP관련 모델의 성능이 크게 증가했다.요즘 시대에 그냥 CNN이나 LSTM쓰면 옛날 사람 취급받을 것만 같은.. 또 하나의 breakthrough라고도 할 수 있을 것 같다. Word Representation쪽에서도 비슷한 도약이 있었는데, 그 시작이 ELMo다. 처음엔 그냥 성능을 약간 올려주는 모델인가보다 하고 넘어갔지만, 다양한 연구에서 활용되는 것을 보면서 이를 기반으로 현재는 Bert와 같은 모델도 나오게 되었다. 이젠 안볼수없는 개념이 되었기에, 논문을 통해 다시 한번 정리해보고자 한다.

Author

  • 저자:Matthew E. Peters, Mark Neumann, Mohit Iyyer, Matt Gardner,Christopher Clark, Kenton Lee∗, Luke Zettlemoyer

Abstract

  • Syntax & semantics 정보를 잡아냄
  • 언어적 문맥(linguistic contexts)도 고려함
  • word vectors는 internal states에 대한 deep bidirectional language model(biLM)를 통해 유도됨
  • 이러한 representation은 기존 모델에도 잘 붙여서 쓸수 있고 성능도 많이 올랐음(6개의 도전적인 NLP task에서 SOTA!! 기록; QA, SA 등등)

Introduction

  • word2vec등이 NLP에서 Key component였지만 양질의 표현을 얻기는 도전적인 문제가 있었음
  • syntax & semantics와 linguistic contexts를 모델링해주는게 이상적이라 할 수 있음
  • 이 관점으로 새로운 representation을 제안 하겠음
  • Vector를 LM과 함께 학습된 BiLSTM으로부터 얻어낼 것임
  • 이러한 이유로, ELMo(Embeddings from Language Models) representation이라 칭할 것임
  • internal states를 조합해주는건 매우 풍부한 word representation을 줌
  • higher-level LSTM states는 context-dependent aspects of word meaning을 잘 캡쳐함
  • lower-level states는 aspects of syntax(e.g. POS)를 잘함
자세히 보기

XGBoost 정리

본 문서는 XGBoost에 대한 기본적인 설명과 설치 가이드에 대해서 다룬 문서입니다.

A. 소개

  • 오픈소스 명: XGBoost
  • Github URL: https://github.com/dmlc/xgboost
  • Ref: Tianqi Chen and Carlos Guestrin. XGBoost: A Scalable Tree Boosting System. In 22nd SIGKDD Conference on Knowledge Discovery and Data Mining, 2016

B. 설치

XGBoost는 CPU전용 설치와 GPU전용 설치 두개로 나뉜다.
CPU 전용으로 설치한다면,

install xgboost``` 를 해버리면 끝이나
1
2
3
4
5
6
7
실제로 사용하려고 하면, Decision Tree보다 느린 속도를 체감하게 되므로 자연스럽게 GPU를 쓰게 된다.   
GPU 전용으로 설치하려면, 소스로부터 직접 컴파일 해야한다.
XGBoost에서는 install guide를 제공해주고 있는데, 현재까지 나온 install guide에는 약간의 문제가 있는데 바로 multi-gpu 관련 문제다. multi-gpu를 사용하기 위해선 GPU간의 communication을 담당해주는 **NCLL**(pronounced "Nickel") 이라는걸 셋팅해줘야하는데 기본 가이드에선 본 셋팅이 빠져있기 때문이다.
설치 가이드: http://xgboost.readthedocs.io/en/latest/build.html#building-with-gpu-support
교정된 내용 출처: https://github.com/dmlc/xgboost/issues/2915

Ubuntu기준 전체적인 설치 프로세스는 다음과 같다.

git clone –recursive https://github.com/dmlc/xgboost
git submodule init
git submodule update

자세히 보기