먼저 대회를 열심히 준비해주시고 끝까지 완주해주셔서 감사합니다. 최선을 다한 만큼 피로도가 높았을텐데, 아주 높은 퀄리티의 리포트를 작성해주셔서 놀랐습니다. 몇몇 마이너한 이슈를 제외하면 손볼 곳이 없는 좋은 리포트입니다. 제 개인적인 생각이나 궁금증(더 생각하면 좋은 것들)을 언급하겠습니다.
[DKT wrapup report]
1.1. 프로젝트소개 KT는 유저의 지식 상태 추이를 파악하여 ... 의미한다. 물론 많은 사람들이 KT를 이렇게 설명합니다. 저는 여러분들이 겪어본 DKT에서 유저의 지식 수준을 파악한다는 생각이 드셨는지 질문을 던지고 싶습니다. 이 대답은 멘토링 시간에 들려주세요!
3-1-2. Baseline Refactoring Refactoring을 해야하는 이유(기존 코드의 아쉬운 점), Refactoring 개요를 간단히 요약하면 가독성이 높은 글이 될 것 같습니다.
3-1-4 > 그래프 모델: Higher-order connectivity를 NCF에서 말하는 higher-order connectivity(MLP 파트)와 비교하면 어떤 차이가 있나요?
3-2-1. 지연된 부분이 있었다. -> 지연되었다. 로 줄일 수 있습니다. 보고서에선 최대한 깔끔하게 글을 쓰면 좋아요!
3-2-2 Riiid 캐글 대회의 예시코드를 참고하였다. <- 삭제해도 좋은 문장 같습니다!
3-2-3 > 2. 시간 정보를 활용한 평균 정답률 (요일, 월) <- 직관적으로 맥락을 파악하기 어렵습니다. (요일, 월) 설명이 좀 더 구체적이면 좋을 것 같아요.
3-2-3 > Data Augmentation에서 ablation study를 해보셨는지 궁금합니다. -> 보고서 후반부[4. 자체 평가 의견 > 잘한 점들]에 끝 문항을 모두 예측하는 것으로 바꿨다는 글을 읽었습니다. 강화학습 알고리즘 중 HER라는 알고리즘이 있습니다. 강화학습은 loss대신 reward를 이용해서 알고리즘을 업데이트 합니다. HER에서 재미있는 아이디어는 pseudo reward를 만드는 것인데요. 마지막 action을 예측하기 위해서 seq[0:-2] 를 인풋 마지막 seq[-1]이 output인 형태로 가짜 path를 만드는 과정을 거쳤습니다. 이 방식을 Data Augmentation에 활용해봐도 좋을 것 같다는 생각이 들었습니다. 구체적으로 길이가 긴 유저의 응답에 대해서 고정된 길이의 순서를 유지한 채 sub-sequence를 뽑는 것 입니다. 물론 너무 많이 뽑으면 특정 학생의 bias가 너무 커질 것 같지만 적당히 뽑아보면 어떻까하는 생각이 들었습니다.
3-2-4. Modeling 전체 성능을 비교한 그림을 넣으면 어땠을까하는 생각이 들었습니다. 그리고 ensemble score가 없는 점이 아쉬웠습니다.
3-2-4. Modeling > 2. 그래프 모델 > UltraGCN 문장 중간에 Adjacency matrix의 A를 소문자 a로 고치면 좋겠습니다. 중간 중간 다른 곳의 영단어도 규약을 통일시키면 좋을 것 같아요.
[개인회고]
OOP(Object-Oriented Programming)에 대한 이야기를 적어주셨습니다. 다만 함수가 많아지면 당연히 관리가 어려워지는데요, 일일이 docs를 만드는 것이 어렵다면 이름을 아주 명시적으로 적어보는 것이 도움이 될 때가 많습니다. 그리고 변수도 명시적으로 적는 방법이 있는데 한 번 소개드리겠습니다. def example(data: np.array, param1: int) -> np.array: 파이썬은 자료형을 자동으로 찾아주지만 사람은 그렇지 못하기 때문에 인자의 자료형을 같이 적어주면 나중에 코드를 다시 읽거나 협업할 때 편한점이 있습니다.
커뮤니케이션 능력 함양 > [상대방과 다른 의견을 낼 때, 내 말이 어떻게 들릴지 먼저 생각해보기]라는 문장이 있는데, 어떤 이벤트가 있었나요? 의견이 다를 때 조율하는 것은 optimal한 정답이 없는 어려운 문제라고 생각합니다. 개인적으로 몇 가지 체크포인트를 두고 있는데요,
kfold에서 각 fold별 차이를 줄였을 때, 실제 성능에 어떤 변화가 있었는지 적어주시면 더 좋았을 것 같습니다. 의도는 [fold별 차이가 적다 -> validation set의 선택에 안정적이다 -> 실제 test set도 비슷한 결과를 낼 것이다.] 로 추정됩니다. 실제로도 그러했는지 궁금합니다.
sequential model에 대한 이야기가 많아서 그런지 dropout이 나왔을 때 설명이 조금 자세했으면 좋겠다는 생각이 들었습니다. 왜냐하면 RNN모델에서 dropout은 MLP의 dropout과 달리 여러 디테일이 있기 때문입니다.
PM은 모든 것을 잘하는 사람이 맡으면 물론 좋겠지만 그런 경우는 아주 드물기 때문에 제한된 상황에서 어떻게 행동하는게 전체 profit을 향상시키는지 고민하는 시간이 되길 바랐습니다. 잘못된 오더가 나갔을 때 어떻게 바로 잡을 것인지, 회의 중 팀원 사이의 의견차이가 났을 때 어떻게 중재할 것인지, 전체적은 프로젝트의 시간 관리를 어떻게 할 것인지 아주 많은 관점에서 pm의 장점을 어필할 수 있다고 생각합니다. 당연히 수헌님이 생각하신 pm도 아주 훌륭하기 때문에 그런 사람이 되도록 노력하는 것도 아주 좋은 방향이라고 생각합니다. 다만 거기 도달하기 전에 차선책으로서의 pm에 자질도 한번 고려해주세요!
동건님의 대회는 진짜 타이트한 시간이었을 것 같습니다. 이론과 실습을 병행하시느라 정말 고생 많으셨어요! 저는 동건님께 Top-down 방식과 Bottom-up 방식의 연구방법(일하는 방법)에 대해서 소개를 드리려고 합니다. 이번에 동건님께서 하신 방법은 Bottom-up 방법으로 보입니다. 보다 견고하고 순서가 자연스럽다는 장점을 가지지만 반대로 학습 속도가 느리고, 막상 공부했는데 사용을 안하는 일이 발생한다는 문제점이 있습니다. 반대로 Top-down은 문제 정의를 먼저하고 이 문제에 필요한 이전스텝, 그 이전 스텝의 이전 스템을 타고들어가는 학습방법입니다. root가 가장 위에 있다면 약간 DFS같은 공부 방법이라고 할 수 있겠습니다. 당연히 장점은 빠른 학습이 가능하다는 점과, 내용을 제한적으로 공부했다는 단점이 있습니다. 많은 CS 배경을 가진 친구들이 Top-down방식을 선호하는 것 같습니다. 소수의 친구들은 Top-down 방식에 조금 변형해서 Bottom-up의 장점을 가져가는 것 같습니다. 그 방법은 Top-down을 지향하되 대회가 끝난 뒤 공부할 키워드를 한곳에 적어두고 대회가 끝난 이후에 넓은 배경을 채워나가는 것입니다. 이런 방법이 부캠이 끝난 뒤에도 가져가면 좋은 공부방법이라고 생각합니다. 물론 취향에 맞아야겠지만 한번 시도는 해봐도 좋을 것 같아서 소개드립니다!
위의 이유로 todo list를 만들기를 추천드립니다.
태블릿은 어떤 것을 사용하시나요? 아이패드를 사용하신다면 liquidtext 를 추천드립니다. 꽤 좋은 기능을 많이 가지고 있는데요, 애플펜슬을 연동하는데 3만원을 받지만 꽤나 강력한 기능을 제공합니다. 필요하시면 다음 멘토링 시간에 요청해주세요!
먼저 다른 분들도 한번 승렬님의 회고를 읽어보시길 권하고 싶을 정도로 잘 정돈된 글입니다. 조금 구체적으로 적으면 좋겠는 부분이 있는데요, 나는 어떤 방식으로 모델을 개선했는가? 에서 [성능 향상] 이라고 적힌 부분은 [정확한 숫자 변화]를 적어주시면 더 좋을 것 같습니다.
수헌 캠퍼님에게 드린 피드백과 동일한 내용을 소개드리고 싶습니다. 저는 주석을 많이 다는 것보단 코드가 주석처럼 적히는 것을 선호합니다. 변수의 이름을 최대한 명시적으로 적고, 줄임말을 사용하지 않습니다. 왜냐하면 IDE가 자동완성을 지원하고 있고 글을 두배로 읽고 싶지 않다는 저의 욕심이 있기 때문입니다. 함수는 아래와 같이 선언하면 좋습니다. def compute_loss(predicted: torch.Tensor, real_label: torch.Tensor, loss_option: str) -> float: 이 줄로 알수 있는 것은 compute_loss라는 함수가 로스를 계산한다는 것이고, 두개의 torch.Tensor를 받아서 float을 뱉어낸다는 것 입니다. 쓰기도 좋고 따로 docs가 없어도 어느정도 이해하기 좋은 방식의 글쓰기라 한번 소개드립니다.
config 파일은 어떻게 만들어보셨나요? json, yaml, py 다양한 방법이 있는데, py로 만드신다면 class를 한번 활용해보세요! 상속을 활용하면 config를 꽤나 유연하게 사용할 수 있습니다.
전처리, 메인 모델 구현, validation set 등 프로젝트 전체적으로 기여가 참 많았군요. 4주라는 짧은 시간동안 많은 경험을 쌓으신 것 같습니다. 전처리 코드를 사용자 친화적으로 바꾼 점, sota모델을 직접 구축한 것이 특히 성훈님께 좋은 자산이 될 것 같습니다.
하신 일이 많은 만큼 문장이 긴 느낌을 받아서 제 스타일대로 몇 문장을 수정해보았습니다. [결과적으로 팀원들의 EDA 를 합칠 때 ... 발전시켜야 함] -> [각 팀원이 수행한 FE 결과를 통합할 때 발생하는 비효율을 줄이기 위해서, 컬럼을 추가하는 방식으로 데이터 파일을 동기화 하였음.]
공유하는 코드를 잘 작성하는 것에 니즈는 팀 전체의 의견인 것 같습니다. 승렬, 수헌 캠퍼님의 피드백에 함수정의하는 방식이나 변수명을 작성하는 방법을 하나 소개했는데, 한번 읽어보셔도 좋을 것 같습니다.
Test set이나 validation set 모두 전체 data distribution을 대표할 수 없기 때문에, 말씀하신 한계점을 현실적으로 피하기 어려운 점이 있습니다. 당연히 각 프로젝트 상황에 맞는 아이디어를 내는 것이 중요한데, 11조의 전체적인 아이디어는 1. validation set과 test set의 사이즈를 일치시키고, 2. folds의 성능편차를 줄이는 것 두 가지 였던 것 같습니다. 다음 과제를 수행하실 떄, 혹시 validation set의 갯수를 test set과 동일하게 가져갔음에도 문제가 발생했다면, 한번 바꾸는 안도 지우지는 말아주세요!
자신의 목표와 성취 수준을 도형으로 표시한 것이 아주 인상적입니다. 특히 자신이 기여한 부분을 아주 상세히 작성해주셔서 상준님이 어떤 기여를 했고, 어떤 고민을 했는지 알 수 있어서 좋았습니다. wandb 캡쳐를 해주신 캠퍼님은 상준님이 최초에요! 상준님의 글도 다른 캠퍼분들이 한번 정독해보면 좋겠다는 생각이 듭니다!
Feature 별 label분포를 바탕으로 feature를 선정하는 방식이 아주 인상적입니다. 의료데이터를 다룰 때 데이터의 숫자보다 feature column의 숫자가 많아서 feature selection을 아주 빈번하게 사용하는데요, 이 때 상준님께서 사용하신 방식과 아주 유사한 아이디어를 사용합니다. 이에 대해서 한번 멘토링 시간에 소개드리도록 하겠습니다.
구현에 관해서 두려움이 생기는건 현업에서 일하다 오신 분들을 제외하면 대부분의 캠퍼분들이 공통적으로 느끼는 감정일 거에요. 이때 알면 쉽고 모르면 어렵다는 생각을 마음에 품는다면 질문하실 때 부담이 덜하실거에요. 왜냐하면 아는 사람이 듣기에 나의 어려운 질문은 쉬운 질문이 될 것이기 때문이에요. 상준님에겐 자신의 생각이 local minima에 빠지더라도 탈출할 수 있는 gradient를 줄 팀 동료분들이 최소한 4명이나 있다고 생각합니다. 당연히 다른 동료분들이 그런 어려움에 처해힜을 때 편하게 답변해주고 먼저 물어보는 문화가 있다면 금방 익숙해지실 수 있을거에요! 동건캠퍼님의 피드백에 top-down과 bottom-up에 대한 내용을 작성했는데, 한 번 읽어보시면 도움이 될 것 같습니다!