20220111수-최종3, 지표 만들기

생각해보면 이번주가 실질적으로 최종 프로젝트의 시작 주간이기는 하구나. 나중에 볼 때 있어서는 이때부터가 3일차인 게 차라리 보기 편하리라. 

컨디션이 악화되니 정말 고역이다. 무슨 감기가 이리 오래 가는지. 그냥 계속 머리가 띵한 상태의 연속이다. 월요일에는 그냥 몸져 누웠는데 이래도 되나 싶다.

지표 만들기1

간밤에 만들고 잔 추천 지표들이다. 막상 만져보니까 그렇게 어렵지는 않았다. 조금 생각할 거리들이 있기는 했다. 일단 내가 논문을 가장 많이 봤고, 잘 이해하고 있는 이상 내가 최대한 지표들을 개발하는 것이 맞다고 생각한다. 자잘한 변수 명이나 인자들은 추후 더 결정되면 수정할 수 있을 듯하다.

일단은 얼추 원하는 대로 나오는 듯. 계산에 시간이 꽤나 소모된다.

하다보니 알게 된 건데, 학습 데이터를 계속 들고 다녀야 한다는 것은 매우 귀찮은 일이다. 학습 데이터에서 필요한 정보들을 담은 클래스를 하나 만들어서 운영하는 게 좋을 것 같다. 그런데 PMI 계산할 때는 결국 학습 데이터가 또 필요하다. 흠. 
안 그래도 계산에 시간이 꽤나 소모되는 것도 문제 중 하나이다. PMI에 필요한 값들을 미리 계산해두는 것은? 모든 아이템에 대해서 해당 아이템과 상호작용한 유저의 집합을 따로 구해두는 것이다. 아이템이 3000개니까 3000개의 집합이 생길 것이다.

자카드를 통해서 하는 것은, 생각보다 어렵지 않았다. 처음에는 무조건 멀티핫 인코딩이 필요할 것이라고 생각했는데 생각해보니까 집합 구조만 만들면 그냥 쓸 수 있는 값이다.

그대로 이용해서 diversity를 계산할 수도 있다.

지라를 한다

팀 내 진행상황을 상세히 하라는 요구가 있었고, 깃헙 위키는 유료로 사용해야 하기에 관련한 툴인 지라를 사용하기로 했다. 아직 완벽하게 사용법을 익히지는 못했는데, 지라에서 이슈를 만들고 그것을 바로 브랜치로 팔 수도 있는 것 같길래 시도했다가 봉변을 당하는 중이다. 한글 명으로 브랜치 이름이 되어있으니 원..

이름을 바꿔서 브랜치를 만들고 올리는 과정..

근데 뭐가 문제인지 원격 브랜치와 로컬 브랜치가 계속 연결이 되지 않았다. 이리저리 방법을 찾다가, 포기! 어차피 커밋 메시지에 이슈를 표기해줌으로써 해당 커밋이 어떤 이슈와 연관되는지 쓸 수 있으니까

포트폴리오 특강

채용자 입장에서 포트폴리오가 어떠한지.

포트폴리오 내용 외에도 많은 것들로부터 채용자는 지원자의 많은 면모를 파악한다.
파일 이름만 해도 그로부터 정보를 파악할 수 있다..
날짜와 버전이 이름에 드러나면 살짝 좋게.. 보인다. 김동건_포폴_날짜_출력본.pdf 이런 느낌.
맞춤법이나, 개인이 운영하는 블로그가 있을 경우 업데이트 주기 같은 것도 그 사람을 평가하는 요소가 된다.
문서는 요약을 잘해야 한다. 적정한 정보량을 담고, 문서를 요약하는 게 중요하다.

어느 곳에 정리를 하든 상관은 없다. 대신 자신의 툴에 익숙한 느낌을 주면 플러스 요소는 될 수 있다.

지원동기를 쓸 수 있다면 꼭 써라. 내가 왜 필요한지, 왜 들어가고 싶은지. 
회사에 특정되도록 써주면 깊은 인상을 남긴다. 회사의 상품에 집중한다던가, 회사의 이념을 걸고 넘어진다던가.

이력서는 포트폴리오의 요약본이 될 것이다. 그럼에도 포트폴리오에 요약본이 있어주면 정말 좋다. 아예 첫 페이지를 요약본으로 만든다던가.
대회가 경험에 들어간다면, 그 대회에 대한 상세 정보를 남겨라.

차별화 요소는 꼭 필요하다.

지표 만들기2

대충 이런 식으로 한 클래스에서 지표를 계산하도록 만들었다. 이유는 각 지표가 공유하는 변수가 많기 때문이다. 직접 손 본 것은 serendipity, diversity의 자카드. diversity 거리 정의 중 내가 완벽히 이해하지 못한 부분은 상준이와 승렬이가 맡았다.

그래서 novelty를 짜려는데 문득 막힌 부분. 참신성을 1 - 인기도로 보는데, 인기도는 사실 1번을 말하는 게 더 잘 와닿는다. 인기있다 하면 사람들이 얼마나 좋아하는지 정도의 정보도 같이 담겨있다 보는 게 맞지 않나 싶다. 그런데 논문에서는 이제 보니까 2번으로 식을 계산하고 있었던 것이다. 2번은 전체 유저 중 해당 아이템을 아는 사람의 정도를 말하는데, 나는 처음에 이게 틀렸다고 생각했다. 그런데 사실 인기도의 반대로 novelty를 보는 것은 참신함이란 것을 표현하기 힘드니 그 정도의 의미로 근사시킨다는 것을 뜻한다. 그렇다면 이 근사는 유저에게 알려진 정도의 정보만을 사용하는 게 더 합리적이지 않나 하는 생각이 든 것이다.

결과적으로는 원래 만든 코드는 살려두기만 하고 새로 코드를 짰다.

할 일

이후 추천 관련 지표들이 얼추 완성된 것 같아서 정확도 관련, 정량 지표들을 고민했다. 일단 학습 데이터에 정답 데이터가 포함되어 있는데, 이걸 어떻게 분리해내야 잘 분리했다고 소문이 날까?

이 고민을 하던 차에 회의를 한번 가지게 됐다. 원래는 승렬이와 나의 짦은 미팅이었는데 졸지에 다 들어와서 이야기를 하게 됐다.

streamlit은 강력하지만 그 자체만으로는 불완전하다. 결국 fastapi를 써야한다. 그렇지만 이쪽 관련 지식이 부족한 사람들이 있어 한번 내일은 다들 공부하는 시간을 가지고 금요일에 만나서 다시 분업 계획을 세우자. 
우리가 해야 할 것들은 1. 정량 지표 2. reranking 코드, 3. 시각화 아이디어. 1과 2는 내일 공부하면서 병행해도 되고 조금 뒤로 미뤄도 된다. 아니면 강의를 안 듣는 것도 방향. 아무튼 정보 수집을 하던, 성과를 내던 알아서 해오자!

회고 및 다짐

streamlit은 저번에 조금 만져봐서 어떤 느낌인지 감은 있지만 당장 하라고 하면 하나도 기억이 안 나고, fastapi는 유투브로 간혹 소개하는 영상만 본 정도. 내일 강의를 들으면서 더 감을 잡을 필요가 있을 것 같다. 
지라도 사용법을 완전히 모르겠고.. 뭔가 배워야 할 것이 굉장히 많은 것 같다. 

처음에는 이걸 어떻게 일을 나눌지 조금도 감이 잡히지 않았는데 점차 가닥이 잡혀나가고 있는 것 같다. 지표 개발은 아무래도 많이 공부하고 많이 파봤던 내가 많이 하는 게 좋다고 판단해서 기본적인 것들에 대해서는 내가 코드를 작성했다. 이전이었으면 다른 사람이 더 잘 코드를 잘 짜겠거니 하면서 밍기적거렸을지도 모른다. 근데, 역시 일단 해보는 게 낫다. 다른사람의 코드와 비교를 하면서 성장하는 게 그냥 옆에서 구경만 하는 것보다는 훨씬 낫다.