패스트캠퍼스 환급챌린지 29일차 : 30개 프로젝트로 끝내는 추천시스템 구현 초격차 패키지 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

 

패스트캠퍼스 환급챌린지는 60일간 매일 공부하는 습관을 들이기 동기부여를 위해 진행하지만

제가 이번에 28월 29화 30수에 예비군이 예정되어있어 미리 패스트캠퍼스측에 메일로 문의한 결과

예비군 가기 전 27일요일에 [28월 29화 30수] 분량을 포스팅하고

예비군 참석 관련 서류를 제출하면 예외적으로 인정해준다고 합니다ㅎㅎ

 

 

공부 시작

강의 종료

강의장

학습 인증샷

학습후기

 

 

 

ch02-04. 유튜브 추천 아키텍쳐

모델을 넘어서 시스템을 고려해야 하는 이유

 

주어진 Feature를 사용하는 것이 아니라 필요한 Feature를 찾아야한다.

주어진 데이터셋을 사용하는게 아니라 데이터셋을 직접 정의해야한다.

정해진 모델 메트릭이 아니라 진짜 비즈니스에 도움이 되는 메트릭을 찾아야한다.

=>

실제 서비스 개발하면서 매번 느낀다.

경우의 수는 무한하고 이전에 배웠던 정보들을 공식처럼 적용했을때 한 번에 예상대로 작동한적이 없다.

비슷한 케이스의 방법론을 적용해도 결국 내 서비스는 내가 제일 잘 알고 있고 그래야 한다.

개발자라고 개발만 하는게 아닌 서비스의 KPI를 같이 설계하고 방향을 잡아야 함을 계속해서 느낀다.

---

 

 

ch02-04. 멀티 스테이지 추천 아키텍쳐

 

 

Retrieval Stage

적은 피쳐를 사용하여 서빙이 빠른 알고리즘

수백만개의 아이템에서 연관된 수백여개의 아이템을 뽑아내는 것

 

임베딩 만드는 알고리즘은 모두 사용가능하다.

 

아이템에 대해서 임베딩을 미리 만들어 두기 때문에 추론과정이 가벼워진다.

 

유저의 쿼리를 임베딩 -> 미리 만들어둔 아이템 임베딩을 ANN index에서 후보 생성 -> 추천

 

ANN은 정확도를 조금 포기하고 속도를 빠르게 한다.

왜냐하면 추천 후보에서는 대략 n개의 후보를 필요로 하기 때문에 

대략적으로 가까운 후보를 만들어낸다.

 

Retrieval Stage에서 핵심은 결국 정확도를 조금 포기하고 속도를 극대화하는 것이다.

추천 시스템은 기본적으로 완벽한 정답을 찾는 게 아니라,
충분히 괜찮은 후보를 빠르게 찾아서 다음 스테이지로 넘기는 게 목표다.

 

특히 사용자 요청이 동시에 수천, 수만 건 들어오는 대규모 서비스에서는 모델이 좋다보다 1초 안에 추천해줄 수 있다가 훨씬 중요하다.

그래서 ANN(Approximate Nearest Neighbor) 구조를 사용하고 Embedding도 사전에 계산해서 저장해둬야 한다.

 

모델 구조만 보고 끝나는 게 아니라, 서빙 단계까지 미리 고려해서 설계해야 진짜 추천 시스템을 만들 수 있다는 것.
추천은 결국 속도와 품질의 싸움이고, 이 균형을 잡는 게 진짜 실력이라는 걸 다시 느꼈다.