[네부캠 AI Tech] 9주차 학습 정리 🤓

학습 정리 & 배운점

# 240103

학습 정리 및 배운점 📚

 

1월 일정 파악 및 학습 계획

- 1월, 4주 기간 동안 DKT 태스크 관련 대회 프로젝트를 level2,3 멤버들과 함께 진행할 것. 지난 프로젝트에서 깨달은 것을 바탕으로, 이번 플젝의 관리 방향을 조정해볼 예정

- 지난 프로젝트에서 강의를 모두 수강하지 못한 것이 아쉬워, 차주까지 모든 강의를 수강하는 것을 목표로 둠. 하지만 이는 절대적인 것이 아니며, 나의 판단하에 학습 진행

- 지난 주 수강하지 못한 강의들은 추가 학습을 통해 수강하자

 

DKT 이해하기

- 교육과 관련한 추천 활용 분야. 학생의 지식 상태를 시간에 따라 예측하는 작업

- DKT: Deep Knowledge Tracing의 약자로 지식 상태를 추적하는 딥러닝 방법론. 수학 시험을 통해 점수뿐만 아니라 수학 과목을 얼마나 이해하고 있는지 측정하고, 나아가 풀지 않은 미래 문제에 대해 맞을지 틀릴지 예측할 수 있음. 그러면 취약한 부분 극복을 위해 어떤 문제를 풀면 좋을지 추천해줄 수 있음. DKT는 교육 AI의 추천이라고도 할 수 있음.

- Iscream 데이터셋을 이용해 DKT 모델을 구축할 것. 다만 이해도를 가리키는 지식 상태를 예측하는 것보다는 주어진 문제를 맞출지 틀릴지 예측하는 것에 집중. -> 지식 상태를 모델링하여 문제를 맞출지 틀릴지 예측. 더 좋은 모델은 학습 데이터가 아닌 새로운 문제나 학생에 대해서도 예측을 잘 수행해야 하며, 그러려면 모델이 지식 상태를 잘 모델링해야 할 것.

- 지식상태에 대한 정보는 사용자의 문제 풀이 내역에서 찾아야 함. output은 테스트 데이터 사용자들의 마지막 문제 정답 여부 -> time-series classification

 

1강 느낀점
- DKT라는 분야는 처음 들어 매우 생소하였는데, 직전 직장의 업무에서 알고 있었다면, 매우 도움이 되었을 것 같다는 생각이 들었다.
- 만약 Knowledge의 각 구성 요소가 명확하게 정의되어 있는 문제이고, labeling이 가능한 문제를 푸는 게 일반적이라면 별로 도움이 안되겠지만, KT 분야에서도 disentangling 시도가 있었을 것 같고 그 연구 결과가 있다면 유용할 것.
- 하지만 이번 대회는 지식 상태에 대한 예측이 주가 아니며, 지식 상태를 모델링하여 주어진 문제에 대한 정답 여부를 이진 분류하는 것이 해결해야 할 문제이다. 하지만 여전히 지식 상태 모델링을 잘 하는 것이 test case에 대해 일반화 성능이 잘 나올 수 있는 방향일거라 생각하고, 어떻게 모델링하고 나아가 설명가능할지에 초점을 두고 프로젝트를 진행해보아야겠다.

 

피어세션
- 우팀소 자료 만들기
- 발표는 내가 내일 14:00
- 내일은 앞으로 프로젝트를 어떻게 해나갈지 얘기하기로 함

# 240104

학습 정리 및 배운점 📚

 

2강 정리
- DKT에서 하나의 행은 interaction이라고 부름. 250만 건, 6개의 특성을 가짐.
- userID는 7442명 고유한 사용자 존재
- assessmentItemID는 문항의 일련 번호. 9454개 존재
- 10자리 수, A와 6자리 시험지 번호, 3자리 시험지 내 문항 번호
- testId는 문항을 포함하는 시험지 일련번호. 1537개 존재
- 10자리 수, A와 앞 3자리 뒤 3자리가 시험지 번호
- 앞 3자리 중 가운데 자리만 1~9 값을 가지며, 이를 대분류 피처로 활용해볼 수 있음. 실제로 정답률 차이가 꽤 남.
- answerCode 문항을 맞았는지 여부를 담은 이진 데이터. 전체 인터렉션 중 65.45%가 정답을 맞춤. 일반적으로 필드에서 마주하는 문제와는 다르게 1이 더 많음
- Timestamp 사용자가 인터렉션을 시작한 시간 정보. 소요시간을 추출할 수 있지만 너무 큰 값은 이상치가 될 수 있으므로 처리해주어야 함 (온라인 플랫폼 특성 상 발생할 수 있는 문제)
- KnowledgeTag 문항 당 하나씩 배정되는 태그. 중분류 역할. 912개 고유 태그 존재

기술통계량 분석
- 사용자 분석. 한 사용자가 몇 개의 문항을 풀었으며, 정답률이 어떻게 되는지 파악. 사용자 당 풀이한 문항 수는 적게 푼 경우가 가장 많고, 많이 풀이한 학생이 적음. 정답률은 평균, 중앙값이 62,65로 약간 우측으로 치우친 분포를 가짐. 분포를 볼 때는 histogram(bin 개수 분포 영향), distplot(kde로 인해 없는 데이터도 있어보임), boxplot(분포 자체보다는 사분위수와 이상치 파악에 적절) 사용 가능. 장단점 보완하여 사용. 일반적으로 중앙<평균 우측으로 치우치고, 중앙>평균 왼쪽으로 치우침
- 문항 별/시험지별 정답률 분석. 둘 모두 분포가 오른쪽으로 약간 쏠린 것을 확인 가능. 정답률 분류를 위한 EDA를 해야 함.

EDA
- 기술통계량을 넘어, 특성과 정답률 사이의 관계 분석
- 문항을 더 많이 푼 학생들이 문제를 더 잘 맞추는가? 공부를 더 많이하면 시험을 더 잘 볼 것으로 기대함. scatterplot과, histogram 비교분포를 통해 풀이 문항수와 정답률 사이에 양의 상관성이 있는 것 확인
- 더 많이 노출된 태그가 정답률이 더 높은가? 태그의 정보는 모르나, 많이 노출된 태그를 갖는 문항이 더 쉬울 수도.. 등의 추론을 시작으로 확인해보기. 마찬가지로 scatterplot과, histogram 비교분포를 통해 양의 상관성이 있음이 확인됨.
- 문항을 풀수록 실력이 늘어나는가? n명의 학생을 추출하여 정답률/풀이문항수로 line plot을 그려보면 알 수 있음. 이 때 무작위 n명이 아닌, 정답률과 푼문항수가 중앙값 부근에 있는 학생을 10명 뽑아 확인함. 초반에 문제를 잘 푼 학생은 항상 감소하고, 반대의 경우 항상 증가함. 처음부터의 정답률이 아니라 최근 n개 문항에 대한 정답률을 봐야 실력의 향상을 알 수 있을 듯. window를 적용해보니 without window일때는 향상되는 것처럼 보였지만, window를 적용하니 무언가 주기적인 패턴이 있는 것으로 보여짐 --> 학생이 어떤 시험지에는 강하고 어떤 시험지에는 약해서 그럴수도 있고, 시험지 자체가 어려운 문제로만 구성되거나 쉬운 문제로만 구성될 수 있기 때문. --> 이전 n개의 문제 특성과 점수를 잘 모델링하면 다음 문제의 정답률을 예측하는 게 쉬울 수 있을 것.
- 문항을 푸는 데 걸린 시간과 정답률 사이의 관계는? 쉬운 문항이라면 정답률이 높고, 시간이 적게 걸릴 거라고 생각. 반대로 어려운 문항이라면 푸는 데 시간이 오래 걸리고 정답률이 낮을 것으로 기대. 다만 너무 빨리 푼 문항의 경우 정답률이 오히려 낮은 편, 특정 시간 22초에서 정점을 찍고 시간이 더 걸릴수록 정답률이 떨어지는 추세
- 그 외 생각해볼 수 있는 것들
- 더 많이 노출된 시험지는 정답률이 높을까?
- 같은 시험지의 내용이나 같은 태그의 내용을 연달아 풀면 정답률이 오를까? (비슷한 문항을 연달아 풀면 성취도가 올라가는?)
- 정답을 특별히 잘 맞추는 시간대가 있을까?

 

피어세션 4PM

- 이전 프로젝트에서 아쉬웠던 점과 좋았던 점을 공유하고, 해결책을 함께 논의해보았다

- 차주까지는 팀 목표로 어떤 것을 삼을지, 어떤 방식으로 프로젝트를 진행할지 구체화해나가봐야겠다.

 

오피스아워 5PM

# 240105

학습 정리 및 배운점 📚

 

1강 소프트웨어엔지니어링
- 소프트웨어엔지니어링: 체계적이고 효율적으로 소프트웨어의 품질과 유지보수성을 보장하는 분야
- 소프트웨어 개발 라이프사이클: planning, analysis, design, implementation, testing&integration, maintenance
- 좋은 소프트웨어 설계를 위해 알아야 하는 개념
- 모듈: 고유 목적, 기능을 가지는 단위. 소프트웨어 개발의 모듈성은 큰 프로그램을 작고 독립적인 부분으로 나누는 것을 말함
- 응집도(cohension): 하나의 모듈 내에 각각의 함수가 얼마나 엮여있는지. 낮은 응집도-공동의 목적이 없고 관련되지 않은 것. 높은 응집도-각 모듈이 긴밀히 엮이고 각 모듈이 하나의 역할을 담당
- 결합도(coupling): 모듈 간 상호 의존성 정도.
- 소프트웨어 설계에서는 높은 응집도(모듈 내 교류)와 느슨한 결합도(모듈 간 덜 교류)를 가진 소프트웨어를 지향
- 테스팅(테스트): 프로그램이 예상대로 작동하고 문제가 없는지 확인하는 과정. 이탈 유저를 줄임
- 실행이 되는지, 기대 현상이 발생하는지, 안정적으로 동작하는지, 버그가 있는지?
- unit test(개별 단위), integration test(구성 요소 동작 테스트), end to end test, performance test
- 딥러닝에서는 데이터와 관련있어 테스트 잘 발전되지 않은 경우가 있음.
- 문서화: 좋은 소프트웨어 엔지니어는 문서화를 잘한다. README, API문서, ...
- 개인 프로젝트도 문서화를 신경쓰면 좋음
- 서비스에 AI 기술을 적용하기 위해서는 서비스와 서비스를 구성하는 소프트웨어 엔지니어링을 이해해야 함

- further reading: 클린 코드(소프트웨어 설계, 유지보수성 실용적 지침 제공), 디자인 패턴(객체 지향 설계 패턴에 대한 깊은 이해 제공)
- further question: 유지보수가 용이한 소프트웨어를 설계하기 위해 일반적으로 사용되는 원칙(SOLID, KIS, DRY, 보이스카웃 규칙 등)들은 무엇이며, 이 원칙들이 실제 소프트웨어 개발에 어떻게 적용될 수 있는지 탐구해보기

2강. 파이썬 버전 관리
- 버전: 소프트웨어 고유 식별자
- 버저닝: 버전을 명시하는 방법. 출시, 업데이트 시에 새롭게 버저닝함
- 버저닝 방법 1) Calender Versioning (출시년도, 월, 패치bin) 2) Sementic Versioning 주식별자, 하위식별자, 패치숫자. 주식별자는 호환 여부를 담음, 하위 식별자는 버그 수정이나 기능 개선의 차이 3) Hash Versioning 해시 알고리즘에 의해 버저닝. 고유 해시값을 가짐
- 파이썬 버전 관리
- GUI, conda, docker, package manager(brew, apt-get, winget), pyenv
- conda 는 무거워서 회사에서는 많이 사용하지 않음
- docker 는 컨테이너에 매번 진입해야 함
- pyenv 를 표준적인 방법으로 활용하는 편. pyenv 설치, pyenv install 3.11.0, pyenv shell 3.11.0 활성화, pyenv versions 설치 버전 확인, pyenv global 3.11.0 디폴트 버전 설정
- 가상환경 관리: 프로젝트 간 환경 격리를 위해 사용
- venv, pyenv-virtualenv, conda, pipenv
- venv 은 내장 패키지. python -m venv "경로", source "경로"/bin/activate 를 통해 활성화
- 파이썬 패키지 매니저
- pip, poetry, conda(파이썬보다는 아나콘다 자체의 패키지 매니저임)
- pip 파이썬 설치 시 자동으로 설치되어 많이 사용되나, 개발 환경과 배포 환경이 분리되지 않고, 패키지간 의존성 정보를 알 수 없고, 패키지 삭제해도 의존 패키지는 삭제 안됨
- poetry는 pip 의 대안으로 등장한 매니저. PEP 621을 통해 pyproject.toml 이라는 파일이 공식적으로 도입되었는데, 이는 파이썬 프로젝트에 대한 메타 정보를 담는 파일임. 여기서 개발/배포 환경 분리, 파이썬 버전 명시 등 가능함. pip의 세 가지 문제점을 보완 가능함

느낀점
- 약 3년 전쯤부터 써오면서, 배포시에 몇 번 pyenv를 사용했던 것을 제외하면, 습관적으로 conda 로 파이썬 설치, 가상환경 설정, 패키지 설치까지 진행해왔는데 pyenv, venv (or virtualenv), poetry 를 사용하여 표준적이고, 가벼우며, 의존성을 쉽게 확인 가능한 방법으로 프로젝트를 해보고 싶다는 생각이 듬.
- 이번 프로젝트는 이렇게 진행해보기로 하고, 오전 내내 서버 새로 생성, screenrc, bashrc, 각종 패키지 설치 진행함. 두 번째 노가다를 하다보니 이젠 정말 쉘 스크립트를 만들어야겠다는 생각뿐...

 

EDA 집착 타임

- 강의에서 많은 아이디어가 나왔었고, 데이터를 보며 궁금한 것들이 몇 개 생겨, 주피터 하나 열어놓고 몇 시간을 보낸 것 같다. 다루면서 느낀 건데 확실히 시간 정보가 있는 트랜젝션 데이터는 여러 관점에서 aggregation도 해보고, rolling 도 해보면서 살펴볼 수 있고, 성능에 차별화를 줄 포인트를 찾아낼 수도 있을 것 같다.

- 주피터는 매우 자유롭고, 잘 정리를 못하면 으지럽기만 한 친구여서 작성할 때마다 이게 최선이 아닌 것 같아서 자꾸 수정하게 되는데, 여기에만 매몰되어 있으면 안되므로 적당히 정리해두자..!!

 

---

9주차 총평 🤔

- 8주차에 엄청난 리프레쉬를 하고와서인지, 적응이 어려운 3일이었다. 최근 해가 쨍한 날이 없어 더더욱 쳐지는 듯...! 다음주에는 활기차고, 규칙적이고 엄청난 한 주를 보내야지!

- 조금 늦었고, 공개하기는 부끼롭지만, 2023년에 대한 회고를 하고 있다. 돌아봐야 나아갈 수 있으니, 돌아보는 과정이 고통스럽고 탈출하고 싶어도 끝까지 꼭 돌아보자!

- level2에 들어가며, 앞으로 기업과의 매칭 과정도 있고, 이력서 제출 과정도 있고, 포트폴리오도 완성해나가야 하며, 그 와중에 프로젝트 협업, 성장도 놓치지 말아야 한다는... 엄청난 스케줄을 들으며 부담이 많이 됐다..!! 일정에 맞게 잘 해나갈 수 있을까? 있다!!!!!!! 나는 할 수 있다!!!!! 우리 모두 할 수 있다!!!!!! 

- 이번 주 중으로 end-to-end 를 경험해보겠다는 계획을 어제 해봤는데, 오늘 바로 일정을 수정하기로 했다. 다음주까지 해보자. 시퀀스 데이터를 일반 ML 모델에서는 어떻게 처리할 거고, 시퀀셜 DL 모델에서는 어떻게 하는지 하나하나 손으로 경험해보고, 결과 출력까지 어떤 과정을 거치는지 한 번은 꼭 이해하자. 완벽하지 못해도 간단한 설계와 그럴듯한 구현이 되도록 이해하고 익히는 것을 이번 플젝의 목표로 삼고 열심히 달려보쟈!!