today-i-learned

BFG Repo-Cleaner는 오픈소스 커뮤니티에서 개발된 Git 저장소 관리도구입니다. 설치해서 한 줄의 커맨드라인에서 실행하기만 하면 쉽고 빠르게 원치 않는 데이터를 삭제할 수 있습니다. 예를 들어 민감한 파일에 대한 모든 커밋내역과 파일을 삭제하고 여태까지의 커밋내역을 유지하려면 이렇게 하시면 됩니다.

민감정보가 삭제됐다면 force-push를 통해 GitHub 등 원격 저장소에 변경사항을 반영합니다.

BFG 설치 방법: Mac의 경우

출처

한국어 자연어처리를 위한 데이터셋이나 도구가 부족하던 일도 이젠 옛일이 되어버렸다. 형태소 분석을 위해서 사용되던 라이브러리도 이젠 KoNLPy로 끝나지 않는 시대가 되었고, 2018년 12월 카카오에서 만들어낸 딥러닝 기반의 형태소 분석기 khaii는 굉장히 준수한 성능을 보여주고 있는 상황에서, 카카오가 다시 한 번 자연어 처리와 관련된 파이썬 패키지를 오픈소스로 공개했다.

Pororo는 자연어 처리를 위한 뉴럴 모델 플랫폼이다. 굉장히 넓은 범위의 자연어 처리 Task를 모두 준수한 성능으로 수행할 수 있으며, 다국어를 지원한다.

또한 기존의 범용 자연어 처리 도구에 사용되던 몇몇 머신러닝 모델들을 정확도 측면에서 압도할 수 있는 최신 기술인 Transformer 모델 기반의 모델들 등을 포함하고 있다. 물론 여타 머신러닝 기반 모델들은 연산량 측면에서의 확실한 우위를 가진 경우도 있기에, 벤치마크등은 고려해봐야 할 것 같다.

아래는 기술문서에서 확인할 수 있는 기능들이다.

Text Classification

Automated Essay Scoring (영어)

Age Suitability Prediction (영어)

Natural Language Inference (영어, 한국어, 일본어, 중국어)

Paraphrase Identification (한국어)

Review Scoring (영어 일본어, 중국어, 한국어)

Semantic Textual Similarity (한국어, 영어, 일본어, 중국어)

Sentence Embedding (영어, 한국어, 일본어, 중국어)

Sentiment Analysis (한국어, 일본어)

Zero-shot Topic Classification (한국어, 영어, 일본어, 중국어)

Sequence Tagging

Batch Normalization이 되려 안 좋은 효과를 불러일으킬 수 있는 상황이 있는걸까? 그렇다면 어떻게 그 상황을 확인하고 해결할 수 있을까?

Batch Normalization이 어떤 건지 복습하기

마지막 레이어에서는 안 쓰는 게 좋겠다고?

BatchNormalization is not a norm! 게시글에서 발췌. Do we need a BN layer at all in a network? Yes. Without BN, the model accuracy drops by a huge margin. So we do need to have some normalization techniques. Does adding a BN blindly after each convolution is the right way to build a CNN architecture? Probably Not! Is there a better way? Definitely Yes! How to decide if there is a need to add BN or not? Grid Search can be one way, but I can’t think of any other optimal way to decide whether to add BN after a convolution or not. Though intuitively, we might need to avoid adding BN layers towards the end of the model so that the prediction layer gets to see a wider range of values.

글쓴이는 Batch Normalization을 모델의 끝부분에서는 피하는 게 좋을 수 있다고 말한다. 그렇게 하면 더 넓은 범위의 값들을 예측에 활용할 수 있기 때문이라고 한다.

Understanding Batch Normalization이라는 논문에서는 Batch Normalization이 포함된 모델은 그렇지 않은 모델보다 입력에 대해 의존적이며, Batch Normalization이 없는 네트워크는 입력과 독립적으로 상대적으로 더 확신을 가지고 class에 대한 출력을 내놓는다고 이야기한다.

Batch Normalization의 이와같은 효과는 regularization 성능을 증가시킬 여지도 있지만, class를 확연하게 나누기 힘들어져 되레 성능을 낮출 수도 있지 않을까 의문을 느낀다.

Heatmap regression에서의 batch normalization

사람의 이미지 입력에서 특정 관절의 좌표를 찾는 task인 pose estimation에서는 좌표를 추정하기 위해서 heatmap이라는 도구를 사용한다.

Learning rate decay

학습의 phase (epoch, training steps)가 증가할 때 optimization의 파라미터인 learning rate를 점차 감소시켜 높은 learning rate에서는 찾을 수 없는 global optima를 찾고자 하는 전략

staircasing

learning rate를 특정 epoch 혹은 step에 계단처럼 뚝뚝 끊어 떨어뜨리는 기법

staircase가 적용되지 않는다면, learning rate은 매 step마다 일정량 decay되면서 완만한 곡선의 형태로 내려가게 됨

staircase=True인 경우, 완만하게 하강하는 learning rate보다도 이론적으로 더 많은 gradient를 이동하게 됨

staircase=True인 경우, objective function이 위아래로 요동치는 현상(oscillation)이 더 눈에 띄게 발생함

Pose Estimation, staircase decay vs linear decay

staircase decay와 linear decay간에 큰 loss / accuracy 차이는 알아보기 힘듦,

예상과는 달리 staircase learning rate decay 뿐만 아니라 linear decay에도 validation 시 fluctuation이 있음

사람의 전신에 연결되어 있는 신경들이 척수를 통해 뇌까지 연결되는 것에서 고안

Hidden layer의 Neuron들이 모두 concatentation되어 output layer로 입력됨

Neuron의 정보를 완전하게 이용하므로 vanishing gradient의 염려가 없음.

기존 Image Classification 데이터셋의 bottleneck layer에서 fully connected layer만을 대체하는 방식으로 이식하여 결과를 확인할 수 있음

ImageNet 데이터셋의 Subset이라고 볼 수 있는 10개 class를 가진 13만장의 이미지 데이터셋 STL-10의 벤치마크에서 1위를 기록함

하지만, 일부 operation, control flow 등은 구현체에 따라 성능이 천차만별이기에, Python + CUDA + TensorFlow의 속도에 WebGL + tensorflow.js의 속도가 한참 못미치는 경우도 존재한다.

for-loop, if문, 일부 사용자가 많지 않은 operation들이 사용되고 있는 경우 해당 구문을 제거하거나 대체하는 것이 성능 향상에 도움이 될 수 있다.

clean and simple python package initializer without any dependency and hidden magic

Instruction

Install your package skeleton

Edit setup.py's PKG_NAME - python script for package installation

Edit PKG_NAME/__init__.py's from package_name - python module for package initialization

Edit PKG_NAME/about.py - python module for package metadata

Edit README.md - basic repository document written in markdown format

Now you can write your own package 🤣

Why is it useful

about.py module keeps package metadata in single source which is referenced by setup.py and package namespace.

I'm tired of writing down setup.py script for every python package. It includes essentials but also minimal so it's highly re-usable

It's compatible from the last release of Python 2.7 to latest release of Python 3.8

요즘에는 개발자들에게 왜 Mac을 쓰냐는 흔한 질문에 "Windows가 Shell 지원이 약하기 때문" 이라는 대답을 하는 것이 굉장히 어려워졌다. Windows의 Shell 지원 기능이 그 어떤 운영체제보다 강력해지고 있기 때문이다. Linux Subsystem을 통해 네이티브 환경과 점점 더 유사한 리눅스를 함께 설치하여 사용할 수 있고, 강력한 윈도우 기반 GUI 어플리케이션들도 여전히 사용할 수 있어 Mac과는 서로 다른 분야에서 크게 발전하였다. 심미적인 부분에서 나는 Mac을 정말 좋아하지만, 업무 생산성에 있어서 최근엔 Windows쪽에 마음이 더 가는 편인 것 같다.

생각보다 많은 사람들이 이용하지 않고 있는 기능이긴 하지만, Powershell은 그래도 마이크로소프트에서 유지보수해주는 나름대로 괜찮은 커맨드라인 인터프리터이다. 일반적으로 Windows 10에 설치되는 Powershell의 버젼은 주로 LTS버젼이기 때문에, Microsoft 공식 GitHub에서 관리되고 있는 Stable 버젼을 설치하면 더 많은 기능들을 이용할 수 있다.

최근 버젼에서는 리눅스처럼 && 연산자를 사용할 수 있고, ssh 등 유틸리티들이 내장되어 있어 putty 등의 애매한 솔루션에 기대지 않아도 된다. 정말로 편리하다.

Windows Terminal은 Split Screen이 가능한 터미널 멀티플렉서이다. 정말 좋다. Customization도 많이 할 수 있고 무엇보다도 GPU 가속까지 활용한 아크릴 투명 UI 까지 지원한다. Windows의 특권이라고 생각하고 꼭 사용하자. Mac의 iTerm2보다 좋은 것 같다.

글꼴

Windows의 가장 아쉬운 점이라면 Mac보다 어찌하여도 글꼴이 예쁘게 보이지 않는다는 사실이다. (OTF의 렌더링 방식과 ClearType 렌더링 방식이 다른 어떤 복잡한 이유로 인하여) 그렇지만 고정폭 글꼴과 IDE상에서 그 지점은 크게 두드러지지 않는 편이라서 Mac과 Windows에서 모두 D2Coding을 사용하여 통일된 UI를 경험하고 있다.

원문 Stackoverflow: Tradeoff batch size vs. number of iterations to train a neural entwork](https://stats.stackexchange.com/questions/164876/tradeoff-batch-size-vs-number-of-iterations-to-train-a-neural-network)를 번역하고 정리한 글입니다.

batch size가 𝑎일 때 학습에 필요한 step 수 𝑏

vs. batch size가 𝑐일 때 학습에 필요한 step 수 𝑑

𝑎𝑏 = 𝑐𝑑 를 만족하는 batch size와 step수를 찾을 수 있을까? 어떻게 하면 가장 적절한 batch size와 steps수를 구할 수 있을까?

Insights

실제 학습 과정에 있어서 더 큰 batch size를 골랐을 때 다양한 데이터에 "일반화"함에 있어서 모델의 성능이 눈에 띄게 하락하는 것이 확인되었다.

우리는 이 현상에 대한 이유를 큰 batch size 일수록 함수가 sharp minimizer에 수렴하기 쉽기 때문이라고 설명한다.

TL;DR: 너무 큰 batch size는 모델의 정확도를 낮춘다

학습의 과정에는 두 가지 "속도"가 있다. 하나는 연산 속도이고, 하나는 알고리즘의 수렴 속도이다. 연산속도는 쉽게 말해 하드웨어에서 산술적인 연산을 실행하는 데에 드는 속도이다. 이 속도는 대게 batch size가 크면 클수록 빠르다. 선형대수 library들이 vector와 matrix 연산에 vectorization 방법을 통해 memory를 더 사용하는 비용을 치루는 대신 필요한 연산의 수를 효과적으로 줄이기 때문이다.

하지만 또 다른 "속도" 였던 알고리즘의 수렴 속도를 살펴본다면, 결과는 조금 다르다. 우선 알고리즘이 수렴하는 게 무슨 뜻일까? 예를 들자면 우리가 알고리즘에게 기대하는 검증 데이터셋에서의 (높은) 정확도를 달성하거나, (낮은) 에러율을 달성하면 된다. 만약에 우리가 전체 데이터를 학습에 사용한다면 매 epoch이 끝날 때 알고리즘은 데이터에 대해 지역적이거나 전체적인 최솟값을 찾아낼 것이다. 하지만 우리가 사용하는 stochastic한 경사하강법은 절대로 minimum에 머무르지 않는다. 계속해서 어떤 지점의 위 아래로 요동친다. 하지만 요동친다는 점은 별로 유효하지 않다. 어찌됐건 최저점과 가깝기 때문이다. 그렇게 골라진 파라미터들을 우리는 "괜찮다"고 본다.

여기서 주목해야 할 점이 있다. 작은 batch size를 사용할수록 큰 batch size를 사용할 때보다 error에 있어서 더 많은 noise(oscillation)가 발생하는데, 직관적으로는 이 noise가 나쁜 것처럼 보일 수 있지만, 알고리즘은 이 noise를 겪음으로서 피하고자 하는 지역적인 minimum을 뛰어넘을 기회를 끊임없이 만들어내기 때문에 그 끝에는 사실 더 좋은 결과를 보여주게 된다.

그렇기 때문에 만약 우리가 작은 batch size를 사용했을 때 큰 batch size를 사용했을 때보다 더 나은 결과를 얻을 수 있다면, 그것이 우리가 "원하지 않았던" error의 noise 덕분이라고 하면, 우리는 "만족할 수 있는" 모델의 학습에 사용하는 전체적인 소요시간을 직접 설정할 수 있게된다.

GPUtil을 통해 자동으로 NVIDIA GPU 하나 고르기

GPUtil 설치

GPU 선택 자동화

./train.py

실험 병렬화

pylint는 python으로 작성된 모듈, 패키지 등을 손쉽게 PEP8 스타일 가이드 및 구문에러 등을 통해 분석해 채점하고 꾸짖어주는 도구이다. 요즘에는 좋은 IDE (Visual Studio Code, PyCharm)를 쓰면 으레 자동으로 따라다니곤 하지만 그렇지 않다면 꼭 찾아서 활성화 해주도록하자. IDE에서는 편집중인 파일이나 폴더에 대한 구문의 이상을 실시간으로, 전반적으로 편리하게 분석할 수 있으며, commandline에서 패키지 단위로 pylint를 실행하면 내가 작성하고 있는 Python 패키지가 10점 만점에 몇 점인지 손쉽게 알 수 있다.

가장 유명한 것은 pylint이지만 이 외에도 훌륭한 linter로 여러 도구를 모은 인터페이스인 flake8, 보안 이슈를 체크해주는 bandit등이 있다. 특히나 flake8의 경우 굉장히 많은 Extension들을 지원해 flake8 명령으로 pylint를 실행할 수도 있고 그 외 import-order, 추후 formatting에서 설명할 black 등을 한꺼번에 실행하도록 할 수도 있다.

코드 스타일이라는 개념 자체가 굉장히 주관적일 수 있어 다양한 입맛의 linting 도구들이 우후죽순 생겨났다. 비교적 최근에 생긴 wemake-python-styleguide라는 한 linting 종파 (…)에서는 다음과 같은 주장을 하기도 한다. pylint 등의 rule이 너무 시시하다면 wemake-python-styleguide를 사용해보는 것도 나쁘지 않을 것 같다.

linter들을 열심히 사용하고 있자니 손으로 수정해야할 코드가 너무나 많을 것이다. 그럴 땐 black과 isort를 설치하고 IDE와 연동해 파일을 저장할 때마다 실행될 수 있도록 설정하면 정말 좋다. isort는 패키지들의 import 순서를 빌트인 패키지에서 서드파티, 자체 패키지까지의 흐름으로 적절히 바꾸어주고 사용되지 않는 패키지 import를 없애주는 도구이다. python 표준 라이브러리를 import하는 경우 import의 순서는 상관 없지만, import 하는 데에만 1초 이상 걸리는 TensorFlow 같은 서드파티 라이브러리 등을 함께 사용하는 실무 환경에서 순환참조등을 줄여 도움이 될 수 있다. black은 그 외의 모든 구문들을 ‘타협하지 않는’ black만의 강력한 rule을 기반으로 reformatting해주는 도구이다. 자기주장이 굉장히 강한 formatting 도구이지만 그만큼 굉장히 formatting을 잘 수행해주기 때문에 그에게 코드를 믿고 맡기고 싶다. 특별히 설정에 필요한 노고도 별로 없기에 정말 추천하는 편이다.

pytest는 python에서 가장 많이 사용되는 유닛 테스트 패키지이다. 다양한 확장 플러그인을 지원하며 규격화된 unittest를 진행하도록 도와준다. 이는 IDE 등에서도 통합하여 사용할 수 있지만, 가장 좋은 것은 GitHub Action, Travis-CI 등 Continuous Integration 혹은 pipeline 도구를 통해 pull-request, push 단위로 unittest를 진행하는 것이다. 그러면 패키지의 배포 환경에서도 무사히 동작이 수행되는 지 확인할 수 있어 좋다. 다만, Data scientist나 ML engineer의 경우에는 조금 다른 점이 있다면 Python 패키지 수준의 종속성이 아닌 시스템 종속성 (NVIDIA 그래픽 드라이버 등)이 굉장히 많이 포함되어 있어 파이프라인 자동화가 어렵고, 으레 unittest를 실행해주는 CI 서비스등의 인스턴스의 성능은 처참한 수준이므로 학습이나 추론 코드의 unittest는 다소 우회적인 방법으로 실행해야 하거나, 실행하지 않게 된다. Google의 TensorFlow의 경우 자체 구축된 아주 복잡한 Jenkins CI 파이프라인을 통해 유지보수를 진행하고 있다.

Jupyter Notebook, Jupyter Lab, VSCode Jupyter 플러그인 등을 활용하자. 인터프리터 환경에서 실행하기 쉬운 실험적인 코드를 시각적으로 확인하고, 저장하고, 버젼관리하고, 문서화하게 해준다. 하다못해 IPython을 사용하자. 반복적으로 함수 등을 테스트하며 구현하려고 한다면, 여러번 같은 코드를 작성하지 않도록 하자.