20230119목-최종9, 수내 오프라인

오프라인

오늘은 부캠에서 제공한 수내에 있는 오프라인 강의장에서 팀원들과 함께 했다. 원래 목적은 다른 팀들과의 교류도 하면서 진행 상황도 공유하고 각 팀의 독특한 접근법을 들으며 네트워킹을 하는 것이 주됐는데, 공교롭게도 이 날은 우리 팀만 신청을 했더라고. 그래도 당직 멘토님이 멘토링을 해주시면서 알찬 시간을 보냈다. 우리에게 자신이 가진 것들을 충분히 공유해주고자 하시는 마음이 느껴져서 정말 좋았던 것 같다. 
다만 17시 쯤부터 꾸역꾸역 머리에 배울 것들을 우겨넣으려다보니 그런가 머리가 아파오기 시작해서 조금 해이해진 감이 없잖아 있네.

오늘 나는 무엇을 했는가? 성훈이 형이 행렬곱을 할 때 csr_matrix를 활용하면 훨씬 더 시간을 단축시킬 수 있다는 사실을 알려주어 그것에 맞춰서 코드를 수정했다.

방법은 간단하다. 일단 csr 행렬을 만들고 이걸 정직하게 전치하고 행렬곱하면 끝. 기본적인 구조는 아무래도 넘파이의 구조를 가지고 있는 듯한데, 그덕에 이러한 연산이 쉽게 이뤄지는 모양이다. 덕분에 1분 30초 걸리던 행렬곱 시간이 대충 3~5초 정도로 줄어들게 되었다. 원래는 데이터프레임을 행렬곱 취하는 방식이었는데 그게 이렇게까지 차이가 날 것이라곤 생각을 못 했다.

그 다음에는 serendipity 지표 계산 때 30초가 걸리는 것을 개선할 수 없을까 하여 유저 프로필에 해당하는 아이템을 제한하는 방식을 시도해봤다. 이러한 방식은 실제로 시간을 절반정도로 줄여주었다. 그러나 단순 지표 계산인데 시간이 14초 걸리는 것도 사실 꽤나 불편한 일이라고 생각이 든다. 이를 더 줄일 방법은 없는 것일까? 행렬 형태로 저장하는 것을 완전히 포기하고 numba.jit을 활용하는 방안도 생각해볼 필요가 있다. 사실 굳이 데이터 프레임을 통해서 행렬을 만들 필요는 절대 없다. 물론 데이터 프레임을 사용하는 쪽이 정말 편리하기는 하다. 인코딩, 디코딩 과정이 일절 필요없기 때문이다. 인코딩 디코딩이 들어가게 되면 일단 처음 짤 때 고려할 때 조금 머리를 써야 하기도 하고, 무엇보다 나중에 코드를 다시 볼 때 빠른 파악이 힘들어서 웬만해서는 피하고 싶은데, 시간을 위해서는 조금 고려해볼 만한 사항이기도 하다.

더 줄이는 것에 관한 것 말고도 이렇게 분포가 달라지는 문제도 있다. 유저 전체 프로필과 끝에서 20개의 프로필의 분포는 명백히 다르다. serendipity는 최소값을 취하는 형태이기 때문에 프로필 수가 적은 쪽이 상대적으로 높은 분포를 보이는 것은 사실 당연하다. 그런데 이게 용납 가능한가도 조금은 물어볼 필요가 있다.
이에 대해서는 수헌이 형이나 성훈이 형은 이러한 차이 자체도 유의미한 시각화나 접근 방법일 수 있겠다고 이야기했다. 아예 이것도 고객이 조절할 수 있도록 하는 것도 생각해보면 좋을 것 같다. 

아직 해야 하는 것. 리랭킹 코드 수정(재정렬되어 상위 k개의 아이템을 그대로 반환하도록, 후보리스트의 수도 정할 수 있도록). diversity 리랭킹 부분 구현. serendipity 최대 프로필 수를 직접 컨트롤 가능하게 변경하기. 

해야 할 일 추가

멘토링을 받으면서 들었던 생각. 논문을 읽을 때 처음 목적은 추천 지표에 대한 전반적인 틀을 머리 속에 넣는 것이었다. 과연 나는 충분히 그러한 틀이 지금 잡혀있다. 그러나 그 이후 뭔가 해야한다는 생각에 또 사로잡혀 당장의 논문의 내용에만 충실해 지표를 설정하고 구현하기 시작했다. 그런데 사실 이 정도로 틀을 잡았다면 넷플릭스, 유튜브, 스포티파이 같이 참신한 추천을 곁들이는 류의 회사들에 대해 조금 알아보면서 어떻게 추천을 하는지 알아봤어야 했다. 또 당장의 기여를 위해 시야가 좁아져버린 것이다. 물론 그 과정에서 리랭킹 같은 나름 참신한 아이디어를 꺼내기는 했지만, 이것만으로 충분하지는 않다. 

그래서 내가 추가적으로 하고자 하는 것은 무엇인가? 넷플릭스, 와챠, 유튜브, 스포티파이 등(당장 더 생각나는 곳이 없다..) 각종 기업들의 테크 블로그나 논문을 찾아가면서 어떻게 추천을 하고 있는지, 어떤 지표와 어떤 것을 고려하는지. 어떤 관점에서 추천에 대해 접근하는지를 알아봐야 한다. 실제 기업이 사용하는 지표라면 굉장히 실무적이라고 볼 수 있을 것이다. 또한 그러한 쪽의 자료 조사를 통해 새로운 지표나, 지표 내에서 새로운 정의를 이끌어낼 수도 있을 것이다. 과연 우리의 아이디어만으로 충분하다고 할 수 있는가? 절대 아니라고 본다. 
이제는 논문을 읽으면서 다양한 방법인 관점을 충분히 생각하며 기반을 다졌으니 확신을 가지고 내가 찾아보자. 내가 잘못 이해할까봐 다른 사람의 도움을 계속 필요로 할 수는 없다. 우리는 분업을 해야 하니 이제 내가 맡은 바라고 생각된다면, 내가 결단을 내려서 결과물을 보여줘야 한다. 나는 분명 틀릴 수 있는 사람이지만, 이제는 맞을 수도 있는 사람이다. 내 관점에는 힘이 붙어있다. 
일단 데드라인 설날 정도로 잡아야할 것 같다.

Analysing Training Data Using RepSys | Blog | Recombee 이런 곳이 있었냐.. 
우리가 해야하는 것의 정답을 보고 있는 것만 같다. 너무 잘돼 있어서 우리가 초라하게 느껴지기도 했는데, 찾아보니 2016년부터 만들어지고 기획되던 서비스인 모양이다. 그럼 우리가 저 정도까지 못 보여주는 건 사실 당연한 것이다. 기업 관계자들도 이 정도 수준을 바라는 것은 절대 아닐 것이다. 다만 여기에서 정말 이건 우리도 꼭 보여주면 좋겠다 싶은 것들을 조금 추출해볼 필요가 있겠다. 
그러니 이 페이지도 열심히 공부할 필요가 있다. 

다시 정리해보자. 

1. 리랭킹 코드 수정(재정렬되어 상위 k개의 아이템을 그대로 반환하도록, 후보리스트의 수도 정할 수 있도록). diversity 리랭킹 부분 구현. serendipity 최대 프로필 수를 직접 컨트롤 가능하게 변경하기. 
2. 각종 기업들의 테크 블로그나 논문을 찾아가면서 어떻게 추천을 하고 있는지, 어떤 지표와 어떤 것을 고려하는지. 어떤 관점에서 추천에 대해 접근하는지
3. Analysing Training Data Using RepSys | Blog | Recombee

추가적으로 내일까지 스페셜 미션 제출이기 때문에 스페셜 미션을 위해서 강의를 조금 더 들어봐야 한다. 당장 내일은 스페셜 미션을 하면서 fastapi에 대한 지식을 더 쌓고자 한다. 아직도 기반이 너무나도 나는 부족하다. 그리고 나는 달변가의 정반대에 가까운지라 잘 모르는 것에 대해서는 놀랍도록 설명할 자신이 없다. 아는 것도 말 잘 못하는데 뭐. 그러니 말할 수 있을 때까지 정진하는 수밖에 없다. 시간은 많지 않지만, 내일 정도는 투자해보는 게 또 도움이 될 것이다. 당장 우리 코드가 어떤 흐름을 타고 움직이는지는 알아야할 것 아니냐?

회고 및 다짐

머리가 아파서 많이 뭔갈 못한 것 같은 기분. 할 일은 또 쌓이기만 하는 것 같냐. 그래도 계속 나아가고는 있다고 생각한다. 많은 회고를 할 여유가 없다. 끝!