09:57분에 일어났다. 어제 에너지를 많이 써서 그런 것 같다. 일어나자마자 앉아서 회의를 하니 제정신이 아니었다. 아침에 여유로워야 효율이 높아지는 나 자신을 다시 발견했다.
feature/reader 브랜치에서 main 브랜치로 합치는 과정에서 충돌이 많이 발생했다. 깃허브 사용에 익숙한 줄 알았지만, PR 충돌이 일어날 때, fast-forward와 rebase의 차이는 아직도 헷갈린다. 익숙해져야 한다. 특히 팀원들 중 pre-commit을 넘기고 통과한 커밋에서 pull로 댕겨올 때 자주 발생한다. 얘들아... 우리 pre-commit 쓰기로 한 것 아니였니...? 그래도 팀원들이 pre-commit 뚫는 여러가지 팁을 공유한다. 예를 들어 # type: ignore[내용]
과 같은 것들이다. 근데 이와 별개로 pre-commit은 생각보다 버그가 많긴 하다. 정적 테스트라서 상속도 못 잡고, from __future__ import annotation
은 훅에서 exclude 걸어놨는데 왜 자꾸 생기는 지 모르겠다.
분업 결과를 합치는 과정에서 나는 뒤로 물러났다. 나까지 참여하면 너무 복잡해질 것 같았다. 안 그래도 가뜩이나 충돌이 증가하고 있다. 심지어는 충돌 해결으로 완전 예전 커밋으로 돌아간 파일도 있었다. 나는 보고서 초안을 작성하고, retriever 팀에 필요한 코드 리뷰를 도와주며 빠졌다.
보고서를 작성하면서 새삼 우리 팀이 잘 기록했다고 느꼈다. 특히 목표 설정과 SMART 분석을 떠올렸을 때, 100%는 아니지만 꽤 많은 내용을 달성하고 있어서 놀라웠다. 이전 프로젝트와 확실히 다르게 느껴졌다. 다들 가라앉고 뭘 할 지 몰랐으며 부산하게 바빠 혼란스러웠는데, 이제는 협업 방식이 자리잡았다. 절대적인 속도가 안 나오지만 말이다. 다들 제출에 초연한 태도가 참 멋지다고 생각했다. 딱 1번만 제출하자는 의견도 있었다.
보고서를 작성하면서 도입할 기술들을 살펴봤는데, reader 측에서는 대부분 적용하지 못했다. PEFT는 꼭 적용해보고 싶었는데 아쉽다. 아직 끝은 아니니 적용해볼 만하다고 생각한다. 모니터링 툴도 적극적으로 꼭 사용해보고 싶다.
팀원 중 디버깅에 힘들어하는 친구를 도와줬다. from src.reader~ import Reader
와 같이 현재 경로를 기준으로 모듈 import 문을 적었으나, 가독성을 이유로 상대 경로로 바꿨다. 하지만 이렇게 되니 vscode 상에서 브레이크 포인트를 찍고 디버깅이 불가능해졌다. 여러 시도를 2시간 동안 해봤으나 디버깅조차 하지 못했다. 차라리 print로 일일이 다 출력하는 게 낫다고 생각했다. 하지만 이렇게 삽질 아닌 삽질을 한 덕택의 vscode 위에서 파이썬 디버거가 어떻게 동작하는지 좀 더 자세히 알 수 있었다. launch.json 파일을 어떻게 건드릴 수 있는지부터 vscode 디버거 커멘드에서 어떤 디버거를 지칭해서 사용하는지 등.
데이터 결함을 보완하기로 했다. 보고서를 작성하다가 아직 실험도 본격적으로 들어가지 못해 적을 내용이 부족했기 때문이다. Ollama 서버를 로컬에 띄우고 llama2를 활용해서 데이터 결함을 분석했다. 특수 문자, 문서/질문/답변의 유효성과 유기성 등을 프롬프트 엔지니어링을 도입해서 해결하고자 했다. Ollama로 llama2 사용은 쉬웠으나, 정확도를 끌어올리기는 정말 어려웠다.