By ML Platform TeamIntroductionIn the last couple of years, Coupang has been using machine learning [ML/AI] heavily to improve customer experiences in areas like search, ads, catalog and recommendations. ML drives important decision making in pricing, transportation and logistics.Coupang’s ML engineer’s toolkit has also grown significantly from simple classical ML techniques to deep learning and now, large language models (LLMs) for generative AI in this short time frame. Coupang’s ML platform has been at the forefront of this journey focused on enabling ML engineers to train and serve models in a resource efficient way. In this blog we write about LLM explorations at Coupang and the technical challenges it poses on the ML platform.ML at CoupangThere are three main types of ML models trained with Coupang’s ML infrastructure:Recommendation system models: This is primarily used in personalization and recommendation surfaces such as main home feed, search and ads across Coupang apps for shopping, eats and play. These are trained on large datasets of user interactions (clicks, views, purchases, add to cart) and human labeled relevance judgements.Content understanding models: Coupang has a huge dataset of product catalog data (text, image), user generated content (text — reviews, queries), user and merchant data (text, image). Various ML teams across product groups use deep learning techniques to understand product, customer and merchant representation and then use it to improve s

배달시간예측서비스팀은 배달의민족 앱 내의 각종 서비스(배민배달, 비마트, 배민스토어 등)에서 볼 수 있는 배달 예상 시간과 주문 후 고객에게 전달되기까지의 시간을 데이터와 AI를 활용하여 예측하는 시스템을 개발합니다. 고객, 라이더, 사장님의 만족을 위해 앱 사용자에게 보이지 않는 다양한 시간과 리소스도 함께 예측합니다. 팀 내에서 데이터를 더 효율적이고 빠르게 처리하기 위해 고민했던 내용과 이를 해결하기 위해 Polars라는 라이브러리를 적용하고 성능을 개선한 경험담을 공유하려고 합니다.• Pandas보다 메모리 효율적이고 빠른 DataFrame 라이브러리를 원하시는 분들• TB, PB 단위도 아니고 GB 단위의 데이터를 처리하는 데에 Spark를 써야 할지 고민이신 분들• 편의성, 비용, 학습 곡선, 복잡성(인프라, 관리 등)을 고려하니 Spark는 과한 것 같아서 대체제를 찾고 계신 분들(주로 데이터 처리 작업을 하는 DS나 MLE 분들)• Pandas의 가독성, 표현식에 아쉬움을 느끼고 계신 분들1.1. Pandas나 Spark를 대체하기 위한 도구를 탐색한 이유?배달시간예측서비스팀에서는 학습 데이터 가공, 피처 엔지니어링, 추론 결과 처리 및 적재, 마트 생성 등의 데이터 처리 작업을 수행하고 있습니다. 이러한 작업을 할 때는 주로 아래와 같은 구조로 작업을 수행합니다.대용량 분산 처리가 필요한 부분은 Trino나 Spark 기반의 SQL을 사용하여 1차 전처리를 하고, 이를 테이블 형태 또는 S3 내에 파일 형태로 저장합니다. 데이터 처리의 중간 산출물을 저장해두는 이유는 파이프라인의 개발 및 운영 용이성을 향상하고 이슈 추적이나 데이터 드리프트 판단, 시뮬레이션 및 오프라인 섀도우 테스트에 사용하기 때문입니다. 이러한 작업을 거치고 나면 수 MB에서 수 십 GB 정도의 데이터로 줄어들게 되고, 이를 가지고 데이터 과학자와 데이터 엔지니어가 SQL로 처리하기 어려운 작업(예: UDF 적용 등)이나 피처 엔지니어링 등의 후속 작업을 수행하게 됩니다. 이 과정에서 본격적으로 제시하고자 하는 문제점과 기술 탐색의 동기가 드러나게 됩니다.• Pandas의 문제점:• 느리고 리소스(CPU, Memory)가 많이 소모된다.• 멀티 코어를 제대로 지원하지 않고 병렬처리가 미흡하다.• 가독성이 떨어진다.• Spark의 문제점:• 모든 데이터 과학자가 Spark로 데이터 처리 로직을 구현하고 튜닝하는 것에 익숙지 않다. (러닝 커브 존재)• 비용 효율성이 낮다. (비싼 리소스, driver & executor 리소스 고려)• 대용량 데이터가 아닐 때는 오히려 오버헤드 발생, slow start 문제즉, 데이터를 분석하고 처리하는 데에 있어 Pandas는 너무 느리고 무겁고, Spark는 과하고 비싼데, 뭔가 이들을 대체할 라이브러리 또는 프레임워크가 없을까라는 고민에서 시작됐습니다.그래서 요구사항을 정리하면 아래와 같았습니다.• 로컬 환경에서도 편하게 개발 및 테스트가 가능해야 하고,• 별다른 인프라가 필요 없고,• Airflow 환경 또는

안녕하세요, 카카오페이 채널 FE파트 디온입니다. 이번 2편에서는 특정 물체에 눈이 쌓이는 애니메이션을 다루겠습니다.트리 곡선에 눈이 쌓이는 애니메이션을 이해하기 위해서 API 없이 웹 애니메이션 구현: 인터랙티브 웹 개발 1편을 먼저 보는 것을 추천합니다. 지난 1편에서는 눈 내리는 애니메이션, 트리 철사 모루 그리기(곡선 그리기), 전구 움직이기 애니메이션을 다뤘습니다. 2편에서는 ray casting, 정사영을 이용해 트리 상단의 별과 철사 모루에 눈이 쌓이는 애니메이션을 얘기해 보겠습니다. 눈이 쌓이는 애니메이션 결과는 동일하지만, 별과 트리 철사 모루에는 다른 알고리즘을 적용했습니다. 그럼 별부터 딥다이브해 보겠습니다.먼저, 현실 세계와 같이 눈이 트리 위에 떨어져서 쌓이게 하려면 어떤 식으로 구현해야 할까요? 제일 처음 떠오른 건 ‘공 튀기기’ 애니메이션인데요.위 영상은 공이 제일 바닥에 닿는 순간, 바닥의 반대 방향으로 공을 움직여 튀는 애니메이션을 구현한 모습입니다. 여기서 바닥 부분을 별의 한쪽면이라고 가정해 봅시다. 그러면 별의 모든 면을 체크해 그중 하나라도 닿는다면 눈의 속도를 0으로 만들어 주면 되지 않을까라고 생각했습니다.그래서 그 바닥면을 체크하기 위해 적용했던 기법이 ray casting1입니다. Ray casting은 보통 게임 개발할 때 원근감을 주기 위해서 사용하는 기법인데요, 광선과 벽의 교차점을 찾아서 무엇을 보여줄지 말지를 결정하는 것입니다. 여기서 핵심은 교차점을 찾다입니다. 이 교차점을 이용해 눈이 쌓이게 할 것입니다. 그러기 위해서 2단계로 나누었습니다.첫째, 눈이 내리다가 별과의 교차점을 찾습니다. 둘째, 눈의 속도를 0으로 만들어 그 자리에 눈을 멈추게 합니다.이런 단계로 마치 별 위에 눈이 쌓이는 것처럼 효과를 낼 수 있습니다. 그럼 첫 번째로 ray casting을 이용해 눈과 별의 교차 과정을 자세히 살펴보겠습니다.눈이 진폭과 주기로 움직이다가 별의 한쪽 면과 교차했을 때의 모습입니다.2차원 그래프 공간으로 이동눈과 별의 교차 감지를 위한 식을 세우기 위해 2차원 좌표 공간에 표현해 보겠습니다. 그리고 눈과 선분 각각에 미지수를 설정하였습니다.눈이 움직이다가 별과 교차하면 Figure 1-4와 같은 상태가 됩니다. 여기서 눈의 yp에 한번 집중해 보겠습니다. 위 그래프에서 눈의 yp 좌표가 항상 빨간색 선분을 교차하려면 yp는 y2보다 작아야 하고, y1보다는 커야 한다는 것을 알 수 있습니다. 만약 yp가 y2보다 크거나 y1보다 작을 경우, Figure 1-4 영상에서 노란색과 빨간색 선분이 교차하지 않습니다. 노란색 선분 위에 yp가 있기 때문에, 노란색 선분이 교차하지 않으면 yp 역시 교차하지 않습니다. 그래서 항상 교차하려면 yp(눈의 y좌표)는 입니다.선분을 미지수로 설정했기 때문에 y2가 y1보다 항상 크지는 않습니다. 그래서 그 반대의 경우(y2 < y1)도 교차가 되려면, yp는 y1보다 작아야 하고 y2보다는 커야 빨간색 선분을 교차할 수 있습니다. 이것의 비교식은

By 김완수김완수 님은 Riiid의 ML Engineer로 AIOps Squad에서 AI infrastructure(GPU Cluster) 업무를 담당하고 있습니다.확장가능한 애플리케이션과 시스템은 현대 소프트웨어 엔지니어링에서 중요한 과제이며, 그것은 머신러닝 엔지니어링에도 당연히 적용되는 말입니다. 또한, 모델이 커지고 확장 가능한 애플리케이션을 클라우드 서비스를 통해서 구현 가능하게 되면서, 하나의 거대한 모델을 다수의 노드에 분산시켜 단일 노드의 리소스 한계를 극복하려고 하거나, 병렬적인 실행으로 빠른 연구 주기를 만들어야하는 필요는 머신러닝 엔지니어링 분야에서 중요한 이슈로 자리잡고 있습니다.Ray는 머신러닝 엔지니어링에서 필요한 확장가능한 시스템을 축할 수 있도록 하며, 효과적이고 단순하게 분산/병렬 컴퓨팅을 수행할 수 있도록 만든 매우 강력한 프레임워크입니다. 이러한 강점으로 아직 정확한 체계가 잡히지 못한 머신러닝 엔지니어링이라는 분야의 초석이 되기에 부족함이 없는 강력한 도구입니다.Riiid!의 AIOps Squad에서는 Ray를 Research GPU Cluster, Scalable AutoML System과 같은 크고 넓은 영역에 적극적으로 활용하고 있습니다.Introduction기본적으로 Ray는 분산/병렬 애플리케이션을 쉽게 구축하기 위한 프레임워크로 설계 되었습니다. Ray를 사용하는 개발자들은 기존의 코드 변경을 거의 하지 않고 코드를 쉽게 분산/병렬화 시킬 수 있습니다.기존에 여러분들은 특정한 작업을 병렬 컴퓨팅을 이용하여 최적화를 시도할 때 Python STL인 multiprocessing 라이브러리를 사용해본 경험이 있을겁니다. 기존의 순차적인 코드를 multiprocessing으로 바꾸기 위해서는 병렬 컴퓨팅에 익숙하지 않으신 분이라면 생소할만한 Pool과 같은 개념들로 기존의 코드를 변경해야 했습니다.Ray는 이런 분산/병렬 처리를 위한 특정한 코드 형태로 기존의 순차적 코드를 바꿀 필요가 없으며, 기존의 순차 코드 베이스에서 몇줄의 코드만 추가하여 병렬 처리를 정말 쉽게 수행할 수 있습니다. 간단한 예시를 살펴보겠습니다. 아래 코드는 간단히 List 데이터의 요소들에 10을 곱하는 간단한 예시입니다. 순차적인 코드를 multiprocessing의 Pool을 사용했을 때는 기존 반복 구조를 map을 이용하는 형태로 변경해야합니다. 즉, 기존의 코드의 구조를 변경하는 것이 불가피합니다. 반면, Ray를 사용했을 경우에는 처리할 함수에 @ray.remote라는 Decorator를 추가하고 함수를 호출할 때 .remote()라는 메소드를 통해 호출하는 부분이 추가되었습니다.즉, Ray를 사용하면 순차적인 코드를 짜듯이 병렬 컴퓨팅을 쉽게 수행할 수 있습니다.Ray는 위 예시와 같은 Syntax Sugar 뿐 아니라 벤치마크를 보면, 대부분의 경우에서 Core 수가 증가함에 따라서 압도적으로 성능이 향상하는 것을 볼 수 있습니다. 이 성능 차이는 프로세스간의 객체 전달을 위한 과정에서 발생합니다. multip