Uber는 어떻게 Data로 좋은 지도를 만드는가
Tech Review of Uber #4
Applying Customer Feedback: How NLP & Deep Learning Improve Uber's Maps
고품질의 지도 데이터는 Uber trip experience에 많은 영향을 준다. 검색, 길 찾기, 도착 시간 예측 등의 서비스는 모두 정확한 지도 데이터를 기반으로 한다. 이것은 안전하고, 편리하며, 효율적인 경험을 드라이버, 라이더, 배달 이용자, 그리고 배달 파트너 모두에게 제공한다. 하지만 지도 데이터는 시간에 지남에 따라 오래되어 그 품질이 하락한다.
고객의 집중하는 회사로서, Uber 플랫폼에 탑승자, 운전자-파트너, 배달 이용자, 배달-파트너가 제출한 고객 피드백을 복기하고 이해하려 한다. 몇몇 피드백은 위치 문제를 가르쳐주며, 이를 통해 지도 데이터에서 오류를 식별하고 수정할 수 있는 방법을 제시하기도 한다.
우리는 하루에 1500만 번 이상의 trip을 제공하기 때문에, trip의 아주 작은 비율에서라도 customer support ticket을 발생된다면, 이것은 많은 양일 것이다. 우리는 부정확한 지도 데이터를 찾아내는 일을 수동으로 하지 않을 것이다. 왜냐하면 그것은 확장 가능성이 없기 때문이다. 따라서 이 워크플로우를 자동화하기 위해 머신러닝(ML)과 빅데이터 프로세싱을 위해 사용한다.
Large-scale ticket 분석을 위해, 우리는 Natural Language Processing(NLP) 플랫폼을 구축하였다. 이 플랫폼은 ticket을 유발하는 지도 데이터의 타입을 특정할 수 있고, 그렇기 때문에 이로 인해 발생되는 issue를 평가하고 분석하여 해결책을 만들 수 있다.
Leveraging our customer support platform
Uber의 in-house customer 플랫폼은 in-app support, self-service flow 등을 포함하여 사용자들이 맞닥뜨리고 있는 문제들을 빠르게 해결할 수 있도록 도와줌으로써 더 나은 서비스를 제공한다. Customer support 플랫폼에서 발생되는 몇 가지 이슈들은 지도 데이터에 의해 발생한다. 만약 우리 지도가 부정확한 데이터를 가지고 있다면, 탑승자는 예정된 목적지로부터 수 마일 떨어진 위치 혹은 최적이 아닌 경로를 따라 이동하게 될 것이다. 이로 인해, 추가적으로 걸어야 하거나 비용을 지불해야 할 수 있다. 이러한 경우, 탐승자는 customer support ticket을 제출한다.
Customer support 플랫폼은 그들의 ticket의 카테고리를 고를 수 있게 한다. 하지만, 카테고리들은 high level이며, 고객의 목적에 맞게 설계되었다. (예를 들어, "사고에 연루되었다.", "요금 및 수수료를 검토 요청한다.", "품목을 잃어버렸다.", 등). 카테고리를 너무 세분화하는 것은 고객 및 고객 지원 담당자 모두에게 그리 좋지 않다.
초기에 분류 데이터가 부족하게 때문에, 우리는 free-form text를 다루어야 하고, 그것으로부터 지도와 관련된 신호를 탐지해야 한다. 사람들은 서면으로 ticket을 제출할 때, 다양한 방식으로 이슈를 표현한다. 예를 들어, "wrong"한 위치에 대하여, "incorrect"나 "off"라는 단어를 사용할 수 있다. 사람들이 같은 상황에 대해 서로 다른 표현을 하는 것을 이해하는 것은 NLP로 도전해볼 만한 일이다.
NLP and ML algorithms
지도 데이터에서 에러를 검출하는 문제는 ML에서 classification 문제로 분류할 수 있다. 이 문제는 Ticket이 어떠한 지도 데이터의 error로부터 야기됐는지 확률을 예측하여 분류하는 문제로 볼 수 있다. 우리는 Logistic Regression을 첫 번째 모델의 algorithm으로 선정하였다.
Logistic Regression은 numerical vector를 인풋으로 사용한다. 그래서 우리는 ticket을 free-form text와 contact type을 포함하여, encode 하였다. Free-form text에 대하여, 사전에 정의된 어휘의 빈도를 활용하여 쉽게 encode 할 수 있다. 하지만 이러한 접근 방식은 vector를 너무 sparse 하게 하며, 더 많은 학습 데이터를 필요로 하게 한다. 그래서 우리는 ticket의 text를 유사한 ticket들끼리는 가까이 있는 dense vector로 만들고자 한다.
첫 번째 모델에서, 우리는 Word2Vec 모델을 사용하였다. 이 알고리즘을 통해, 의미적으로 유사한 단어들이 embedding space에서 가까이 위치하게 된다. Word들을 vector화 한 이후에, ticket vector는 ticket에 있는 word들의 word vector들의 평균으로 계산되었다. Contact type은 type별로 각각 UUID를 가지고 있으며, ticket의 contact type을 encoding 하는 데는 one-hot encoding을 사용한다. Ticket에 대한 최종 vector는 Ticket의 word vector들로 유추된 vector와 contact type에 대한 one-hot encoding의 concat이다.
Logistic Regression의 결과를 확률 값으로 변환할 수 있고, threshold를 설정함으로써 Precision-recall의 trade off를 조절할 수 있다.
Machine Learning 알고리즘의 주요 과제는 학습 데이터를 만드는 것이다. 각 지도 데이터 타입에 contact 타입이 없는 것을 감안하여, 우리는 sample ticket들에 대해 수동으로 labeling 하였다.
다행히도 word embedding을 학습하는 것은 unsupervised이고, 우리는 Word2Vec embedding을 100만 개의 random sample ticket에 대해 학습한다. 우리는 위키피디아를 통해 미리 학습된 GloVe embedding들 사용해 보았다. 하지만 Customer ticket들로부터 학습된 word embedding이 더 좋은 성능을 보이는 것을 확인할 수 있었다. 이것은 특정 domain의 언어 특성이 모델에 반영되기 때문일 것이다.
첫 번째 모델의 알고리즘은 한계가 있다.
1. Ticket의 word vector를 결합하는 데 있어, 평균을 사용하였다. 모든 word는 평등하게 취급되었으며, 주요 단어에 관심을 가지지 않았다.
2. Word embedding은 unsupervised 방법으로 학습된 후 고정되어 변하지 않으며, 이것은 classification 문제에 적합하지 않다.
이와 같은 한계 때문에 우리는 WordCNN과 LSTM과 같은 deep learning 모델을 적용하여 실험하였다.
지도 데이터의 Binary Classification 문제에 대한 모델 성능 요약은 아래의 표에서 볼 수 있다. 각 결과는 data set을 training/evaluation/test로 분리한 결과의 영향을 최소로 줄이기 위하여, 10번 시뮬레이션한 것의 평균값을 사용하였다.
(각 지표에 대한 자세한 내용 및 모델에 대한 이해는 원문 혹은 별도로 찾아보시면 좋을 것 같습니다.)
Customer ticket으로 학습한 Word2Vec의 word embedding을 하용한 WordCNN 모델이 가장 좋은 성능을 보였다. 우리의 application은 Language model이나 sequence generation보다 keyword spotting이라 activation에 가깝다. 그렇기에 당연히, WordCNN이 LSTM보다 더 좋은 성능을 보였다. 우리의 application은 단어의 순서나 특정 구절의 유무가 더 중요하다. 그렇기 때문에 WordCNN의 두 번째 알고리즘을 사용하기로 하였다.
Word embedding visualization
각 단어들은 300차원으로 embedding 되었다. 우리는 t-SNE와 PCA와 같은 차원 축소 기술을 활용하여, word vector를 3차원으로 시각화하여 보았다. 우리는 의미적으로 유사한 단어가 서로 가까이 위치해 있는 것을 확인할 수 있다. 또한 각 단어의 동의어도 cosine similarity와 euclidean distance를 사용하여 가장 가까운 단어를 찾았을 때, 찾아낼 수 있었다. 이러한 시각화는 TensorBoard를 활용하였다.
(시각화한 결과를 담은 영상은 원문에서 보실 수 있습니다.)
Word embedding이 제대로 학습되었는지 확인하는 방법으로서, word vector가 synonym을 잘 학습하였는지 확인하는 방법이 있다. Cosine distance 혹은 Euclidean distance로 가장 가까운 word를 N개 뽑아서, 상식에 입각하여 의미론적으로 유사한 단어가 있는지를 통해, 학습이 잘 되었는지 검증할 수 있다.
System design and architecture
Large scale의 predition을 제공하기 위해, 우리는 distributed/parallel computing에 강하고 big data partition을 제공하는 Spark를 사용하였다. 두 버전의 System architecture는 아래와 같다.
Uber는 Spark와 Hive를 활용한다. Hive 테이블에서 데이터를 저장하고 Querying 하며, Uber 클러스터에서 Spark 파이프라인을 통해 실행할 수 있는 Big Data Ecosystem을 갖추었다. 우리는 End-to-end Spark pipeline으로 Machine Learning Algorithm을 구현하였다. Pipeline의 첫 번째 단계에서 Spark SQL이 Ticket Hive Table에 Querying을 하여, ticket_id, ticket_content, trip_id를 포함한 데이터를 가져온다. 그 이후, 두 데이터 프레임을 join 하고, 그 결과를 preprocessing 단계로 전달한다.
Preprocessing 단계 이후, 우리는 NLP 모델을 사용하였다. 이 NLP 모델은 contact type indexer, contact type one-hot encoder, Word2Vec model, Logistic Regression model, 학습되어 저장된 Spart pipeline 모델을 포함한다. Spark ML pipeline을 사용하여 우리는 깔끔하고 유지보수에 용이한 코드를 만들 수 있었다. 두 번째 알고리즘에 대하여 TensorFlow를 사용하여 WordCNN모델을 오프라인으로 학습하였다. 우리는 학습된 모델을 TensorFlow의 SavedModelBuilder를 통해 서빙하였다. 실제로 우리는 Uber의 Michelangelo 팀과 함께 모델을 wrapping 하여 end-to-end Spark pipeline으로 서빙할 수 있도록 하였다.
원문의 마지막 부분은 설명이 충분치 않아, 오히려 오해가 생길 듯하여 생략하였습니다.
이 글은 아래의 원문을 번역/의역 및 요약하였습니다. 중간중간 파란색으로 표시된 글씨는 번역자의 견해입니다.
https://eng.uber.com/nlp-deep-learning-uber-maps/
지난 리뷰 보기
https://brunch.co.kr/@andrewhwan/55
https://brunch.co.kr/@sonjoosik/7
