DEVIEW 2018
Deview 2018의 2일차에 다녀왔습니다. Pycon에 이어 두 번째 참석해 본 개발 컨퍼런스였는데 재미있었습니다. 부스 사은품은 파이콘에 비해 살짝 아쉬웠지만 (참석이 무료니까..) 세션들은 모두 유익했던 시간들이었습니다. 원래 이런 행사들 오면 하루 강의를 다 들을 인내심이 없어서 탈주하고 돌아다니고 하는데 마크다운에 메모하면서 들으니까 집중하기 좋았습니다. 처음으로 모든 세션 풀로 다 듣고 왔네요.
Deview 1일차는 피켓팅 실패로 못 갔습니다. 수업시간에 핸드폰으로 예약하려고 하다 이메일을 입력하라고 해서 실패. 2일차 예약은 이메일 주소 복사해두고 로그인하고 대기 타면서 10초만에 성공. 다행히 듣고 싶었던 세션들이 2일차에 많이 있었고 1일차는 학교 수업이 있었어서, 겸사 겸사 잘 다녀왔네요.
제가 듣고 온 세션들은 다음과 같습니다.
- 인공지능이 인공지능 챗봇을 만든다 by 이재원님 (NAVER | Company AI)
- 누구나 만드는 내 목소리 합성기 by 이봉준 (NAVER | Voice)
- 기계독해 QA : 검색인가, NLP인가? by 서민준 (NAVER | Clova ML)
- Ai Serving Platform : 하루 수 억 건의 인퍼런스를 처리하기 위한 고군 분투기 by 현동석 양은숙 (NAVER | System & Solution)
- Papago Internals : 모델 분석과 응용기술 개발 by 신중휘, 정권우, 김재명 (NAVER | Papago)
- QANet : Towards Efficient and Human-Level Reading Comprehension on SQuAD by Adams Wei Yu (Carnegie Mellon University)
아래 메모는 제가 정리하려고 적은 용도라 친절하지 않을 수 있습니다.
Session 1 : 인공지능이 인공지능 챗봇을 만든다
이재원님 (NAVER | Company AI)
- 인공지능이 언어를 배우는 과정
- Vector Representation
- 주어진 vector space에 문장의 embedding vector를 배치
- 각 문장별 embedding vec이 가까우면 같은 의미, 멀면 다른의미
- n차원의 공간에 n개의 원소 : 문장의 특징 표현
- 각 도메인별 말뭉치로 학습된 n-hot embedding vector
- Glove(Stanford), fastText(FB), Global Embedding Vector(네이버 내부용)
- 특정 도메인에서 작동하지 않을 수 도 있다
- 인간의 뇌
- 인공지능의 뇌는 벡터로 표현되어 있음
- Vector Representation
- 인공지능 스스로 배울 수 있지 않을까?
- 학습, 평가, 말뭉치를 분류하고 하는 과정을 원클릭으로 진행할 수 있을까?
- Auto ML
- 진화된 인공지능 프로그램
- Data Corpus -> Data Cleaning전처리 -> feature selection/preprocessing/construction -> model selection -> parameter optimization -> model validation
- model selection에서 validation 반복하며 챗봇 최적화
- 말뭉치만 있으면 챗봇이 만들어지는 과정
- 좋은 말뭉치는 좋은 선생님. 챗봇의 품질이 달라진다.
- 인공지능이 배울 언어의 영역이자 한계
- 주어진 말뭉치로 학습하고 AutoML을 통해 변화, 발전
- 범용성이 높다.
- 직관에 의존하는 모델링을 개선 가능
- 코드를 가져다 쓰는데 논문만큼 성능이 안나오고, 코드는 돌고. 이유는 모르고.
- 그 번거로운 과정이 AutoML로 해결이 된다.
- Clustering
- Hyper-parameter Tuning
- 모델이 도메인을 학습하기 위해 입을 옷과 같다.
- Ensemble Weights
- baseline이 되는 여러가지 모델들. 여러 모델들을 앙상블해 더 좋게 만든다.
- 한계점들
- 말뭉치만으로 스스로 언어의 특징을 파악하고 모델을 만들기는 부족.
- Q-A 말뭉치를 학습에 필요한 시나리오로 바꾸기 위한 리소스 부족
- 도메인 키워드만으로 아무 도움 없이 스스로 챗봇 만들기 부족
- 파라미터 조합에 대한 확신 및 검증 부족
- AutoML을 적용하기 위해 필요한것
- 방대한 말뭉치 효율적 관리 방법
- hyperparameter
- AutoML을 도와줄 Framework. Chatbot Module
- Clustering, Model Hyperparameter tuning : 시간만 있으면 다 가능.
- Feature Extraction
- 형태소 분석
- Query Pre-processing
- 학습에 필요한 모든 쿼리 전처리
- Seq2Seq 기반 tf모델. cell, architecture, attention 사용해서 한국어 및 대화형 데이터에 최적인 모델 만든다.
- 형태소 분석된 질의 시퀀스로 답변 시퀀스 생성
- 사람이 대화 배우는 과정과 비슷하게 모델을 설계했다.
- (p29 내용 추가)
- 답변이나오는데 걸리는 시간 0.3ms도 안걸린다. 답답하지 않게 사용할 수 있다.
- N-hot input model
- token 정보 이외에 문장 이해할 수 있는 정보를 같이 활용
- POS정보
- EOMI정보 : 어미변형이 담고있는 정보를 손실시키지 않게 하기 위해 별도의 feature로 사용.
- Multi-platform
- 쿼리에 대한 여러 모델의 답변을 앙상블해서 여러 플랫폼에 서비스한다.
- Hadoop 사용해서 데이터 수집 및 정제
- GPU사용해서 말뭉치 구성
- 인공지능 챗봇의 말하기 실력?
- 스스로 말하기 실력을 평가할 수 있게 만든다
- 좋은 챗봇은? 성능평가기준
- 적절/친근/명확/자연스러운/정확한의도파악/노이즈에강건/재사용가능/직관적인터페이스
- Query 평가 4점 척도 모델 평가 예시
- 사람이 하고있다. 이것을 한명이 할 수 없다.
- 자동 평가를 만든다.
- 시나리오에 포함된 쿼리 중 1~2개를 제외하고 오직 평가에만 사용한다.
- 해당 평가 쿼리는 정답/오답 양쪽 모두 자동평가를 진행한다.
- Clustering 자동평가 방법
- 군집간 분산 최대화 / 분산 최소화
- MSE사용해서 모델 스스로 만족하는 시나리오 생성 (Dunn Index, Silhouette Score등도 가능)
- Validation set제작
- 자동학습점수가 최대가 되는 cluster k 선정
- 왜 MSE가 최대가 되는 k? : 수식 설계하기 나름
- Hyperparameter 자동평가방법
- 그룹 내 객체들이 정확하게 분류되었다는 가정이 있다.
- Cosine-Similarity, MSE로 평가 진행
- 기본적인 것들이 가장 좋은 성능을 냈다.
- Cosine Similarity와 MSE가 정확했던 이유
- 자동평가점수는 모델이 쿼리를 주어진 벡터공간에 제대로 표현했는지를 나타내는것
- MSE
- 시나리오에 얼마나 벗어났는지 regression으로 접근
- CS : 쿼리를 학습중에 배치할 공간
- 길이를 정규화해 비교하는것과 유사. 벡터 크기보다는 벡터간 거리를 측정하기 떄문에 좋다.
- Clustering
- EM algorithm확장 및 응용
- ?
- 밀도방식의 클러스터링
- LSH 해싱 알고리즘. 고차원 데이터 차원 확률을 기반으로 차원축소하여 유사도 계산
- 쿼리와 쿼리 간의 유사도는 빠르게 진행이 되나 A와 B, B와 C가 코사인 유사도가 높을때 A와 C가 높지 않을수 있음
- K-means Clustering
- 답변보다 질문이 많으므로 고유한 갑변 갯수를 초기 k를 설정
- 결국 K-means Clustering을 사용했다.
- 같은 문장임에도 속한 말뭉치마다 다르게 생성되는 emb vector 특징을 잘 반영했다.
- 사람들이 직접 분류했던 것과 거의 비슷한 성능의 시나리오를 만들었다.
- Able to cluster lexical queries
- Hyperparameter
- RNN, Self- Attention, Continuous BOW, 등 여러가지 모델이 있었지만 seq2seq based retrieval model이 좋았다.
- 말뭉치 사이즈별 model hyper-arameters
- 작은 시나리오일수록 작은 hidden size에 매핑
- 시나리오수 52 -> hidden size 24
- 더 많아지면 더 큰 hidden size
- 작은 시나리오일수록 작은 hidden size에 매핑
최종모델 성능 및 상용서비스 현황
- Deview문의 챗봇 보여주심.
- 사용자는 이게 학습이 되는건지 알 수 없다. AutoML로 자동학습을 진행하고 있기떄문.
- seq2seq이 아니어도 다른 모델 가능하다. 챗봇 빌더 framework에서 사용가능.
- 서비스현황
- 한국어대화 등 클로바 도메인
- 블로그 카페 고객센터
- 네이버 비즈니스 플랫폼
- 쇼핑, 의료 등
마무리
- 기본모델, 기본 아키텍쳐로도 우수한 성능 챗봇 제작 가능하다.
- 단일모델보다 다수의 baseline모델들을 ensemble
- 열심히 노력하면 좋은 챗봇을 만들 수 있다.
Session 2 : 누구나 만드는 내 목소리 합성기
이봉준 (NAVER | Voice)
음성 합성이란?
- Speech Synthesis : 인공적으로 사람의 음성을 만드는 것
- Text-to-Speech(TTS)
- 텍스트는 다른 사람이 써도 같지만 음성은 같은 문장을 읽어도 사람마다 다르다. 음 높낮이, 강조, 발음 등. 음성은 텍스트가 가지고 있지 않은 정보를 가진다.
- 발음, 속도, 호흡, 운율의 정보를 추정해 녹음한 화자와 가장 비슷하게 만든다.
- nVoice
- Concatenation방식으로 만들어졌다.
- 화자가 발생한 음원들을 잘게 잘라서 데이터베이스를 가지고 있다. 새롭게 텍스트가 들어왔을 때 가장 적합한 음성을 추정하고 만들어서 소리를 만든다.
- target cost와 join이라는 것을 고려해 가장 자연스러운 음성을 만든다.
- target cost : 얼마나 비슷한지.
- 화자 선정
- 호감가는 목소리
- 정확한 발음
- 일관된 목소리. 사람은 목소리가 계속 바뀌기 때문에.
- 발성 스크립트 선정
- 서비스 도메인에 따라 내용과 분량 선정
- 읽기 쉬운 스크립트
- 모호한 발음은 미리 알려준다 (01:07은 1대 7로 읽어주세요/ 1시 7분으로 읽어주세요)
- 보강어휘
- 녹음
- 녹음을 아무데서나 하면 안 된다.
- 녹음실의 품질이 좋지 않아서 꽤 많이 녹음했다가 전량 폐기 한 적도 있다.
- 고려할 점들
- 높은 볼륨 vs 숨소리(흡~, 습~)
- 노이즈 제거
- 좋은 녹음실과 훌륭한 사운드 엔지니어
- 전사 (transcription)
- 받아쓰기. 실제 어떻게 발음했는지.
- 각 음소별 음성 분할 (5ms. 200분의 1 초 단위)
- 장르 (책처럼 딱딱하게 읽었는지, 친구에게 말하듯 했는지)
- 감성 (기쁘게, 슬프게)
- 언어처리 모듈 구현
- 여러 단계를 거친다. preprocess, sentence split, tokenization, text normalization, Grapheme-to-Phoneme Conversion (텍스트를 실제 발음 어떻게 해야하는지), break Index Classification(끊어읽기), Genre Classification, Emotion Classification등.
- 운율 모델링
- 개인의 특성을 가장 잘 나타낸다.
- Pitch (톤 같은것)
- Energy (강세. 특정 음소를 얼마나 강하게 읽는지)
- Duration (얼마나 길고 짧게 읽는지)
- 개인의 특성을 가장 잘 나타낸다.
- 음소 접합
- 가장 자연스러운 합성 단위 찾기
- 각 음소별로 꼭 붙어야 하는것 / 떨어져도 상관없는
- 연결성 vs 추정값
- 자연스러운 접합(PSOLA))스무딩.
- 몇 가지 예시
- 10대 : 열 대/ 십 대/ 십때
- 3M : 삼미터/ 삼메가/ 쓰리엠
- 이 모든 과정을 거쳐 한 화자의 합성기가 만들어진다.
- Concatenation방식으로 만들어졌다.
- Custom TTS 있는가?
- 여자친구 목소리로 깨우는 알람/ 부모님 목소리로 읽어주는 동화책 등
- 한계점 : 짧은 시간 쉽게 녹음하여 개인의 특성을 살리는 자연스러운 음성 생성을 해야 하는데?
- 돈
- 일정한 톤 유지
- 깨끗한 발성
- 정확한 발음
- 녹음
- 개인화 음성합성, 어떻게 풀었는가?
- 근본적인 합성 방식을 바꿨다. Statisticall Parametric 방식으로 바꿈.
- 무슨 Parameter 사용?
- Voice, Unvoice (성대가 울리는지 안 울리는지 차이)
- F0 (Fundamental Frequency)
- LSF (line spectral frequency from spectral envelope)
- 에러에 강건하고 차원을 줄이면서
- BAP
- 비 주기성
- 무슨 Parameter 사용?
- End2 End 사용
- 추가적인 작업(전사) 없이 Wave와 Text만으로 음성 생성
- 어떤 네트워크?
- 기본적으로 attention기반의 seq2seq
- 무엇을 추정?
- mel spectrogram, vocoder parameter
- 어떻게 소리를 만드는가?
- Griffin-Lim, Vocoder, WaveNet
- Character2Wave
- Tacotron2
- 원음만큼 좋다.
- 단점 : 모든 문장에서 잘 나오진 않음
- Vocoder로 음성합성
- 품질은 Wavenet이 좋지만 합성속도는 Vocoder가 월등히 좋다. 학습 속도도 좋다. Wavenet은 한문장 합성에 10분 넘게..
- Griffin0Lim은 품질은 별로 좋지 않다.
- 단점 : parameter가 잘못 추정되었을 때 품질 저하가 크다.
- Unvoice구간을 Voice로 추정하였을 때 큰 잡음.
- 최대한 넓게 Unvoice구간을 확정했다.
- 짧은 unv/vo는 잘못 추정되었을 수 있기 때문에 무시
- 잘못 추정된 경우 전구간에 F0사용
- interpolation할 수 있겠지만 그냥 쌩으로 사용했다.
- Speaker Adaptation
- 대량의 음성 데이터로 소량의 데이터를 만드는 것
- Explicit Adaptation : 스피커 정보를 실제로 받아들인다. 128차원.
- Implicit Adaptation
- 근본적인 합성 방식을 바꿨다. Statisticall Parametric 방식으로 바꿈.
- 시연
- 100문장 8분 데이터
- 90문장 학습, 10문장 검증
- 성우 vs 일반인
- 개선사항
- 품질 향상
- 전처리 기술 고도화
- 더 적은 데이터 사용
- 새로운 end-to-end
- 새로운 adaptation 방법
- voice conversion
Session 3 : 기계독해 QA : 검색인가, NLP인가?
서민준 (NAVER | Clova ML)
검색
- TF-IDF
- 각 단어마다 똑같은 가중치를 주지 않고 흔하지 않은 단어가 나왔을 때 더 큰 가중치를 준다
- Okapi BM25
- LSA
- bag of words (sparse) -> dense vector via SVD
- 각 단어에 추상적인 태그를 달아준다(태그 갯수는 400개라던지, 크지 않게)
- 유사한 단어로 검색 되게
- 폐업 ~ 망하다 ~ 몰락
- 검색의 한계
- lexical 수준의 QA는 가능하나
- NLP가 필요
- TF-IDF
NLP로 읽는 QA
- 생성모델은 매력적이지만 서비스 퀄리티가 안 나온다.
- 엉뚱한 답을 내는 경우가 많음
- Evaluation도 어렵다. 추출 모델이면 localize가 되는데.
- 결국 Extractive
- Neural Extractive QA Trend
- 문서와 질문이 주어지고 답이 문서 안에 존재한다고 가정할 때 그 답을 가져오는 모델을 만드는 것.
- 7 Milestones in extractive QA
- 1. Sentence Level QA
- 깔끔하고 좋긴 하지만 답이 너무 길다. 그렇다고 단어 level로 가기에는 나타낼 수 있는 형태가 제한적이기 때문에, 답을 구문으로 보여줄 수 있을지 생각을 함.
- 2. Phrase-level QA
- SQuAD라는 데이터셋 : 10만개 이상의 질문들이 있다.
- QA에서 처음으로 엄청 많은 양의 sample을 모음.
- 2년동안 100개 이상의 모델이 제시됨.
- SQuAD라는 데이터셋 : 10만개 이상의 질문들이 있다.
- 3. Cross-attention
- 질문을 다 읽고 문서를 보는게 아니라 문서를 읽으면서 질문을 참고하고, 질문을 읽으면서 문서를 참고하게 만듦.
- 예 : Paul을 보면서 질문 Who와 비슷한지비교
- 2016년 11월 쯔음에 이런 모델이 주를 이루었다.
- Attention : 다른걸 보는 것
- 4. Self Attention
- 문서를 읽으면서 문서의 다른 부분을 참조
- this epistle -> second epistle to the corinthians
- Unlabeled Corpus를 볼 수 없을까?
- 문서를 읽으면서 문서의 다른 부분을 참조
- 5. Transfer Learning
- 위키피디아: 3 billion words, unlabeled
- SQuAD : 2 million words, labeled
- 6. 컴퓨터가 사람을 이길 수 있을까? Superhuman level
- 5%정도 차이 난다.
- Ensemble
- NLP tools(sparse feature)
- Data Augmentation
- A lot of layers
- 5%정도 차이 난다.
- 7. What’s next?
- QA를 위의 질문과 관련해서 계속 물어볼 수 있는 것.
- 문서 읽을 때 0.1초 정도 걸리고.
- 그러나 model들은 linear-time의 굴레에서 벗어날 수 있다. 문서의 길이가 길어지면 오래 걸림.
- 한 문서 0.1초 -> 총 6일 정도. 질문 하나에 ! (Titan XP를 사용해서)
- 그래서 다시 검색 이 필요해진다.
- Solution 1 : 찾고 나서 읽자.
- 이 방법의 문제점? : 검색엔진이 잘 안되면?
- Error Propagation
- 엘레강스가 부족하다. End-to-End 가 필요.
- Search engine 을 거치지 않고 답을 낼 수 있을까?
- 이 방법의 문제점? : 검색엔진이 잘 안되면?
- Solution 2 :
- 벡터를 정리. vector space에서 document를 먼저 정리해둔다.
- This is called Locality-Sensitive Hashing
- 비슷한것끼리의 충돌을 막는 것.
- 벡터를 정리. vector space에서 document를 먼저 정리해둔다.
- $O(kN^{\rho}log(N)))$
- 가능한 문서들을 먼저 enumerate하고 각 phrase들을 vector로 mapping 할 수 있는 NN을 학습한다. (질문이 바뀌는거지 문서는 자주 안 바뀌니까.)
- 질문이 들어오면 똑같은 vector space에 mapping하고 MIPS를 사용해서 가져온다.
- 문서 d와 쿼리 q가 주어졌을 때:
- 기존 : 매 새로운 질문마다 F를 다시 계산한다.
- 제안 : H는 미리 계산 될 수 있고 index될 수 있다.
- 큰 문제가 있다. Decomposition이 안됨.. decompose를 ensure하기가 쉽지 않다.
- 새로운 연구 문제 : Phrase - Indexed QA (PIQA)
- 이걸로 1년간 삽질.
- Baseline : LSTM사용. 이것은 어렵지 않았다.
- Self-Attention
- 그러나 문제. Duality와 Multimodality
- Barak Obama라는 사람에 대해 나올 수 있는 질문들.
- 두 개 다른 질문에 대해 같은 답이 나오는 것. (Duality)
- Question 하나에 대해 Multimodality가 생기면 기댓값을 찾을 때 좋지 않다.
- Latent Variable을 사용하면 된다? 잘 안된다.
- Dense Vector
- Scalibility 고려사항 1
- SQuAD는 문서 하나만 보는 것 -> 벤치마크 성격이 강함
- 실제 QA 시나리오가 아님.
- End-to-End가 Pipeline보다 더 나을거라는 보장? 추가실험 필요.
- 고려사항 2
- 90TB 정도 필요
- NLP와 검색의 조화가 필요하다.
- 1. Sentence Level QA
Session 4 : Ai Serving Platform : 하루 수 억 건의 인퍼런스를 처리하기 위한 고군 분투기
현동석 양은숙 (NAVER | System & Solution)
모델 개발 등 다 끝난 후 상용화하는 과정에서 인퍼런스를 처리하기 위한 AiSP를 어떻게 설계하고 만들었는지.
다른사람들은 어떻게 하는가
- 커스텀 서버 만들기 (학습하던 코드에 서버 코드를 추가해서 서빙하는 방식)
- 장점
- 있던 코드에 서버코드를 추가하면 되니까 편함
- 데이터 전/후처리도 기존 코드를 쓰면 되서 편함
- 인퍼런스 병목인 경우 서버 성능은 덜 중요
- 단점
- 비지니스 로직과 인퍼런스가 커플링
- 물리 자원이 성능에 최적화 안됨 (GPU 놀고있고)
- 분업이 어렵다
- 서버 자원과 인퍼런스 자원 개별 스케일링 불가
- 오픈소스 웹서버 기능을 필요에 따라 직접 만듦
- 장점
- 서빙용 서버 쓰기
- e.g. Tensorflow Serving
- TF 모델이어야 한다. Pytorch나 Caffe 등은 사용 불가. 이 것만 빼면 custom server에서의 단점을 모두 보완할 수 있다.
- 분업도 가능. (researcher/ engineer)
- inference부분만 떼어서 CPU/ GPU 옵션 제공 가능.
- 자기들이 받았던 비즈니스 요구사항 : 초당 18000개의 인퍼런스를 적절한 수의 장비로 해결해달라.
- 인퍼런스 요청 모듈화
- 상황 : 인퍼런스 전에 데이터 전처리 로직 필요하고, Researcher가 전달한 모델은 TF. 응답 포맷이나 데이터를 자주 변경해야 함.
- 플랫폼 선정은 딥러닝 모델 포맷에 종속적
- 모델 크기가 작을수록 서빙 아키텍쳐가 성능에 미치는 영향이 큼
- 인퍼런스 시스템 라이프사이클
- 커스텀 서버 만들기 (학습하던 코드에 서버 코드를 추가해서 서빙하는 방식)
- AiSP만들기
- 인퍼런스 서버 만들기 - 인퍼런스 서버
- 사용자가 서빙 모델, 포트번호 들만 만들어주면 로컬로 모델을 받아 서빙 서버를 띄우게 된다.
- 도커 파일은 여기서 만들었고 사람들은 도커파일을 통해 만든 이미지 만을 사용하는 것.
- 프론트엔드 서버가 함께 변환이 되어야 함.
- 런타임이 자동으로 업데이트 되게 되면 장애 상황이 벌어질 수 있음
- gpu도 TF serving 에서 제공하는 Dockerfile.devel-gpu라고 있는데 실제 돌리면 에러가 남.
- BAZEL_VERSION을 0.13.1로 지정해주면 빌드됨
- 인퍼런스 서버 한번 만들어두면 모든 모델에 대해 사용이 가능해서 편하다.
- 인퍼런스 서버 만들기 - 인퍼런스 서버
- 인퍼런스 프론트엔드 서버 만들기
- 프론트엔드는 받는 요구가 많다.
- 삽질1 : httpd + wsgi + django
- 요청 받을 떄 마다 hang 걸린다
- TFS API의 stub부분의 리소스 해제 시점 문제로 wsgi와 간섭이 걸려 있어서 프로세스가 그냥 멈춘다.
- 해결했다고 하고 이슈가 close됐는데 해결 안 됐다.
- 이조합은 비추. 안된다
- c++ 아파치 모듈로 한다
- c++ client로 만들려면 TF, TF Serving라이브러리가 있어야 함
- 대부분 전체를 Bazel로 컴파일하는 예제만 있지 라이브러리 컴파일은 없다.
- C API는 있는데 C++는 없다. Bazel build 조사.
- 삽질 2 : 응답 데이터 접근하기
- 인퍼런스 요청은 샘플 코드를 보면 되는데 데이터 접근은 샘플이 없음
- TF의 tensor는 EigenTensor의 수정본이고 거기로 접근한다.
- 삽질 3 : ArgMax (삽질은 아니고 성능개선)
- 가장 높은 p를 가지는 애들을 return하는것
- TF의 연산은 텐서그래프 안에서 사용하는것
- 프론트엔드 서버 APS에서 ArgMax를 사용하려고 Tensorflow의 session을 돌릴 수는 없음.
- c++에서 직접 만듦.
- 처음에 받은 데이터는 양이 작았는데 다른데서 병목이 생김
- output.length = m, argMax value = n이면 n이 작으면 O(m*n), 크면 기존 sort를 사용.
- 3000micro second -> 600micro second 대로 바뀜
- 딥러닝 모델 배포 플로우 - SignatureDef
- 딥러닝 모델의 시그니춰(입출력)을 정의하는 부분
- DL researcher가 정의해 주어야 한다.
- 내가 훈련할 때는 뭐가 인풋이고 뭐가 아웃풋인지 아니까 지정할 필요가 없는데, tensorflow serving server가 model을 load할때는 그걸 알아야 할 수 있다. (signature definition 이라고 한다. )
- Tip. Dropout probability 같은 상수 값을 hyperparameter tuning시 session입력으로 사용하다가 signatureDef에서 누락하는 실수를 하기 쉽다.
- 컨테이너로 스케일 아웃 하기
- Scale-out시 고려사항
- HAProxy
- Service discovery : Refresh every 2 min
- Retry count : 3. Blocked for 2 min
- Timeout : 100ms (99percentile)
- 인퍼런스 서버가 몇 초 동안 처리를 못 하는 동안 IQE의 busy worker가 많아지면서 일을 못 하는 시간이 생기기 때문에 평균적인 시간을 잡아서 그걸 넘어가면 죽은걸로 보고 요청을 끊음.
- Failover : In-house platform supports
- Round-robin : code level implementation
- 인퍼런스 클러스터는 CPU와 GPU별로 클러스터링 한다. (섞어놓으면 모니터링 자체가 잘 안된다. )
- 모델 관리 및 데이터 관리
- 학습에 사용된 데이터도 주기적인 업데이트가 필요하다.
- 모델 업데이트 외의 변경으로는 겉보기에는 정상이지만 인퍼런스 값이 바뀔 수 있으므로 validation하는 코드를 만들어 놓고, 배포 전에 테스트해본다.
- Scale-out시 고려사항
예외처리
- 프론트엔드에서 한다.
만들어진 AiSP 구현하기
- 개발용 컨테이너 띄우기 - 인퍼런스 서버
성능 측정
- 입력에 상관없이 거의 같은 성능
- batch 옵션의 성능 향상이 크다
모니터링
- Front-end에 해당하는 APS가 웹서버이므로 초당 요청수나 응답시간은 쉽게 볼 수 있다.
- 어떤 질의어에 대해 어떤 inference를 했고 score는 뭐였고 등을 확인가능
- CPU : 사용량 임계치를 정하고 모니터링한다.
- GPU : 알기가 쉽지않다. tip. GPU사용량은 사용전력량과 비례함
Session 5 : Papago Internals : 모델 분석과 응용기술 개발
신중휘, 정권우, 김재명 (NAVER | Papago)
- 기계 번역 Engine팀 역할 소개
- AI연구/개발
- 모델 연구/개발. 기계번역 & OCR연구
- 응용기술 연구/개발도 같이 하고 있음. 웹문서 번역, 오프라인 번역(임베디드 사용), 서비스 최적화 번역 등
- 앱/웹 서비스
- 서버개발 (GPU)
- 집중하는것
- 품질(번역품질 등) / 편의성(웹문서 번역) / 최적화(품질 안정성 최적화, Real-time이기 때문에 속도 최적화)
- AI연구/개발
- 학습과 수렴
- 실제 연구 사례 (외부에 논문 형태로 공개 안되었음. 과정을 공개)
- 모델 소개, 학습과 수렴 관련 연구, 앞으로의 연구방향
- 기계번역 모델 소개
- Transformer
- 전체 문맥에서의 의미.
- 나는 엄마가 좋아 라는 문장이 있으면 ‘나는’의 전체문장에서의 의미, ‘엄마가’ 의 의미, 등
- 그 의미들의 정보를 encoder를 통해 뽑고 decoder를 통해 번역
- 작년에 구글에서 발표한 Transformer의 기본 구조.
- 좋은 성능이지만 학습이 불안정하다.
- 파파고 내부에서 더 안정적으로 학습하려고 함
- 연구 목표
- 수렴 안정성
- 기계번역 논문에서의 수렴 기준
- Transformer 논문 : 수렴 지점 선별 기준을 명시하지 않음. 30만번 정도 했다고 함.
- ConvSec2Sec by FB : learning rate 기준의 수렴 지점 선별
- 논문마다 수렴을 선택하는 방법이 조금씩다르다.
- 원인 : 모델 학습 자체가 어려움
- 일반화된 모델 평가 방법은 있다. BLEU (0~100점)
- 연구중인 것 1
- 일반화된 모델 수렴 지점 선택 방법이 없다
- 다양한 학습 방법론 실험. 이 모델이 어떤 파라미터에 더 예민하게 반응하는지. 모델마다 초기 learning rate에 예민하기도 하고, 모델마다 다름.
- 똑같은 학습 조건에도 불구하고 BLEU점수 뿐만 아니라 얼마나 학습과정에서 예민하게 반응하는지 달라서 추이를 확인해 보았다.
- 기계번역 논문에서는 BLEU 1점 혹은 2점 차이도 새로운 논문을 낼 수 있을 만하다.
- 일반화된 모델 수렴 지점 선택 방법이 없다
- 기계번역 최신 평가 점수
- 영어<=> 독일어는 48점정도
- 모델을 학습해서 testBLEU가 가장 높은 모델을 선정해 사용자에게 배포하면 우리는 가장 좋은 모델을 제공하는 것인가?
- NO.
- BLEU가 올라간다고 품질이 올라가는것이 아니다.
- 기계번역 특성상. 단순한 메트릭 하나로 번역기의 품질을 표현할 수 없다.
- 좋은 품질의 번역 이란?
- 원문과 번역문의 동일한 의미 (Adequacy)
- 자연스러운 문장(Fluency)
- 번역 모델의 품질 측정
- 전문가측정
- 2개국어 가능자들 활용
- 원문과 번역문 기반 평가
- 전문가측정
- 연구중인 것 2
- 평가 척도의 개선이 품질 개선을 보장하지 않는 문제
- 우리는 BLEU 점수를 얼마나 신뢰할 수 잇을까? 언제?
- BLEU vs 전문가 평가 추이를 실험으로 검증했다.
- 어떠한 방법론으로 어떻게 평가해야 전문가평가를 얻을 수 있을까?
- 결과는 논문을 통해 공개
- 이런 식으로 서비스와 품질에 밀접한 관련이 있는 연구를 진행한다.
- 평가 척도의 개선이 품질 개선을 보장하지 않는 문제
- Transformer
- 앞으로의 연구 방향
- 주요 연구 주제
- 서비스 품질 개선
- 신뢰할 수 있는 모델 학습 및 수렴지점 탐색 방법
- 장문번역, 저빈도단어, 고유명사 번역 품질 개선
- 서비스 속도 개선
- 동일한 품질에서 더욱 빠른 inference
- Quantization, Model Compression, Lower-bit Calculation등 여러가지 연구중
- 서비스 품질 개선
- 주요 연구 주제
- 인공 신경망을 활용한 웹사이트 번역
- 웹사이트 번역
- 웹사이트를 통째로 번역하는 경우.
- 한 문장 안에 다양한 html 태그가 있는 경우.
- 태그를 떼었다가 번역을 하면 품질이 많이 떨어진다.
- 최소한의 문장 단위를 유지한 채 번역을 한다.
- 목표 : 신경망 기반 번역을 통해 번역 품질 확보 후 번역문의 적당한 위치에 원문 태그를 다는 것.
- 적당한 위치는 어떻게 아는가?
- 입출력 단어 사이의 attention 값을 보고 해당 출력 토크을 생성하는데 가장 영향력이 컸던 입력 토큰의 태그를 넣어준다.
- 원문 단어의 태그를 그대로 적용할 수 있다. word alignment를 찾는 것으로 생각 할 수 있음
- 예시로 잘 되는것 같지만 encoder decoder간의 attention이 이론적으로 word alignment라는 보장이 없다.
- 기계 번역기가 번역을 잘못하면 태그 복원의 성능도 급락한다. 원문의 내용이 번역문에서 생략이 되거나 고유명사가 생략될 경우
- 전처리, 언어별 휴리스틱, 병렬처리(문장 번역과 달리 페이지 번역은 쿼리가 많다) 등의 문제도 있다.
- 개발 시 겪게 되는 실질적인 어려움들
- 지저분한 웹상의문서
- 유니코드의 50가지 그림자
- 공백 종류만 20가지다.
- 처음 보는 vocab에 대해 unicode가 번역을 잘 못한다.
- 웹표준을 지키지 않고 과도하게 태그가 중첩되거나, block level 태그를 inline태그가 감싸거나.
- 번역한 부분을 뽑아내는 것도 challenge
- 번역기로 보낼 태그와 보내지 않을 태그.
- 태그는 번역 x
- 시간이나 약어 등은 번역기로 보내되 그대로 유지해야함.
- 번역기는 inline tag만 고려한다.
- 번역 원문에 적절한html태그 달기
- 한국어의 경우 POS tagger를 활용해 조사를 분리.
- 빠르게 처리하기
- Frontend : 번역할 사이트 쪼개기
- Website Translator : 택스트 태그 추출, ㅂ문장분리 및 태그위치 기록
- GPU cluser
- Bottleneck
- 사진찍어둠)
- 지저분한 웹상의문서
- 앞으로의 연구 방향
- 서비스를 하면서 관찰된 이슈들
- 입력문의 내용 일부가 번역문에서 생략된 경우 (문장 일부가 그냥 날아간)
- 입력문의 내용 일부가 번역문에서 녹아있는 경우. (March for our lives 예시)
- 향후 연구 방향
- 기계 번역기 자체의 성능을 높인다
- 원문 coverage 높인다. 생략ㅇㄹ 줄임
- 외부 지식을 활용한 명사 번역
- Alignment와 태그 복원 품질을 높이는 연구
- 기존의 statistical translation에서 phrase table을 이용해 supervised attention을 한다.
- 기계 번역기 자체의 성능을 높인다
- 서비스를 하면서 관찰된 이슈들
- 웹사이트 번역
Session 6 QANet : Towards Efficient and Human-Level Reading Comprehension on SQuAD
Adams Wei Yu (Carnegie Mellon University)
QANet
Question Answering :
- NLP에서 어렵고 중요한 task
- Bing, Baidu, Google 도 QA system을 다 사용
- 대부분의 NLP tasks들이 QA문제로 formulate될 수 있다.
- Fact를 보여줄 수 있지만 Fact에서 Answer를 logical하게 찾아내는것이 어려움
- Watson
- This talk : end-to-end QA systems
SQuAD dataset
- Stanford Question Answer Dataset
- Wikipedia Article을 가지고 Question (class가 있음)을 주면 걸맞는 answer prediction이 몇 개 있다.
- 최근 2년간 가장 popular
- 이 데이터에 focus해서 설명
- EM 과 F1 metric을 maximize하는걸 찾는게 목표
Neural architectures for QA
- Recurrent Neural Networks (RNN)
- 문장이 들어오면 단어 sequence를 vector로 해서 hidden layer를 거쳐서 output을 뽑는다.
- Attention : interaction of two sequences with weighted average
- 2개의 concept를 가지고 general answer model framework를 만듦
- BiDAF (Base model)
- embedding layer : query- > word embedding, character embedding
- GLOVE와 Char-CNN사용
- representation을 찾아서 concat해서 다음 레이어로 넘겨줌
- Attention layer
- Query2Context를 먼저 하고 Context2Query를 한다
- RNN의 2 challenges
- RNN hard to capture long dependency
- Hard to compute in parallel 병렬처리가 힘듦
- 해결하기 위해 Substitution을 할 수 있을까?
- What do RNNs capture ?
- Local context : 현재 일어나고있는 부분
- Global Interaction : 오래된 정보를 잊음
- Temporal info : ordering of the sequence
- Convolution : Capturing local context
- 우리가 문장의 word vector들을 합치면 matrix가 되고, image도 matrix의 형태. image에 convolution을 적용할 수 있듯 문장도 그렇게 처리 가능해짐.
- k-gram feature of NLP domain -> 병렬처리가 가능해진다.
- Global Interaction
- 레이어가 많이 필요
- Self attention technique를 사용해 global interaction을 capture한다.
- Self attention : attention은 두개의 다른문장을 사용하는데 self attention은 같은 문장에 적용
- Self attention도 병렬처리가 가능하고 all-to-all이다.
- Graphical components
- RNN : chain
- Conv : bipartite graph
- Self attention : full bipartite
- What do RNNs capture ?
- Explicitly Encode Temporal info
- Position embedding
- QANet Encoder [Yu et al., ICLR’18]
- Position embedding
- Convolution
- Self Attention
- Feedforward
- 그리고 이 구조를 Residual connection으로 반복한다.
비교
- QANet :
- 130+ layers Deepest NLP NN
- First QA system with no recurrence
- L2 Regularization, Stochastic depth, Sqeeze and Excitation, Residual Connections 등 computer vision에서 사용하던 기법들을 들고올 수 있었다.
- QANet :
Data Augmentation
- Popular in computer vision and speech
- enlarge your dataset. dataset이 크면 성능이더 좋아진다.
- 그러나 그게 NLP에 그대로 적용되지는 않는다. each word is a vector.
- word vector에 noise를 더하는게 meaningless
More data with Back Translation
- 영어에서 불어로 번역하고, 불어에서 영어로 다시 번역한다.
- Applicable to virtually any NLP Tasks (not only QA)
- Improvement : 1.1 F1
- Used 2 language pairs : English - French, English - German data
- 한국어, 중국어 등을 추가해 데이터셋을 키울 수 도 있다.
Transfer Learning from unsupervised tasks
- ELMo
- 우리의 QA dataset이 작다.
- Language modelling on daaset
- Pretrained Language Model ELMO : 4.0F1
- Pretrained machine translation model CoVe: 0.3F1
- ELMo
- Recurrent Neural Networks (RNN)
Summary
- QANet - 3 key ideas
- Deep architecture without RNN
- 130-layer (Deepest in NLP)
- Transfer Learning
- leverage unlabeled data
- Data augmentation
- with back-translation
- SQuAD에서 1등한 BERT (오늘paper released) : human performance 넘었음
- QANet 오늘아침까지 1등
- Deep architecture without RNN
- QANet - 3 key ideas
Speed up
QA is not solved !!
- The question and answer is still simple
- Pattern matching
- How can we develop logical reasoning?
- How can we define QA in proper way?
Tips for tuning QA model? computational resources