[일일리포트] Day 84 (프로토타입_3/ FinalProject_4)

해당 일일리포트에서는 네이버 커넥트에서 진행하는 '부스트캠프 AI Tech 3기'에서 배운 내용을 다루고 있습니다. 저작권 이슈 때문에 관련 자료를 올릴 수는 없기에 핵심 이론과 코드를 요약해서 올리고 있기에 내용이 부족할 수 있습니다.

▶ Today I Learned (핵심 요약 정리)

MLOps_3 (과제1)

어제까지 하던 Streamlit코드를 개선하기 위해 오전 중에는 과제를 진행했다. 이해가 잘 안 갔던 부분의 경우 정리해서 이해하고자 했고, 조금 더 깊게 이해해봄으로써 문제를 해결하고자 했지만 크게 개선할 수 있는 방법을 못 찾고 제출을 해버렸다. 그래도 이번에 조금 더 코드를 파보면서 @st.cache(hash_funcs)에 대해서도 어느정도 알게 된 것 같아서 정리하고자 한다.

질문내용

부캠에 다음과 같은 질문을 올렸고, 이에 대해 다른 캠퍼분과 마스터님께서 이에 대해 설명을 해주셨다. 다음은 해당 질문에 대한 마스터님의 답변이다 (문맥 조금 수정)

캐싱은 보통 이 값이 기존 캐싱 DB에 저장되어 있는가?를 확인하게 됩니다. Streamlit은 모델을 객체로 저장하고, 그걸 활용하는 방식으로 캐싱을 하고 있습니다.

• 캐싱 데코레이터를 설정하면 캐시 키를 계산
• 캐시 키가 캐시 메모리에서 발견이 된다면 이전에 캐시되었던 튜플 출력
• 캐시 키가 캐시 메모리에 없다면 해싱 후 결과를 저장

이와 같은 방식으로 캐싱이 진행됩니다. 이 과정에서 해싱(Hashing)을 사용해야 하는데, 일반적으로 (Stremalit에서) 지원하는 객체는 바로 해싱할 수 있지만, Streamlit에서 익숙하지 않은 경우엔 hash_func에 지정해주는 것이 필요합니다. ('익숙하지 않은'이 사용자의 입장에서 익숙하지 않은 것?) 현재는 '토크나이저란 것을 어떻게 해싱할지 모르겠다 (내 질문 내용)'라는 맥락이 있어서 해시 함수를 지정해줘야 하는 상황이지요. 저는 streamlit에서 해싱할 때는 lambda _: None을 자주 사용했습니다. 해싱을 하지 않고 쓰겠다인데, 객체가 변하지 않는다면 이렇게 사용하셔도 무방합니다..!혹시 아래 문서 보셨나요~?https://docs.streamlit.io/library/advanced-features/caching 이 문서인데 여기에 캐싱과 해싱이 어떤 과정으로 실행되는지 자세히 나와있어요. 이 글을 읽으시면 조금 더 이해가 되실거에요-!

Streamlit Docs

그리고 해싱을 하다보면, 해싱 과정이 오래 소요되어서 오히려 병목이 되기도 합니다. 저는 이런 경우엔 lambda _: None으로 처리해주곤 해요

구체적으로 이렇게 사용해라란 가이드가 부족한 문서도 있을 수 있을 수 있는데, 이런 경우는 코드를 보시면 이해하시는게 더 빠릅니다 Steramlit내부 코드의 to_bytes란 함수가 제공된 객체를 해싱합니다. 이 과정에서 “torch.nn.modules.module.Module” 인지 아닌지 체크하는 isinstance 등이 존재합니다. 여기에 나오지 않는 모듈이라면 파이썬 내장 함수에서 해싱이 어려운 것이고, 이런 경우라면 해시 함수를 명시해주어야죠. 만약에 해싱하지 않고 싶다하면 lambda _: None 쓰시는거구요..!

Streamlit에 대한 정보가 많지는 않았는데, 멘토님 덕분에 hash_funcs에 대해서 이해할 수 있었던 것 같다. 부캠을 하면서 좋은 것은 혼자서는 막혔을 내용들을 질문할 수 있을만한 분들이 많다는 것이다. 혼자서 공부를 하는게 아니라 같이 공부를 하고 있다는 느낌을 받을 수 있다는 게 너무 좋고 감사하다. 

FinalProject_4

오늘 최종 프로젝트에 사용할 데이터셋을 선정했다. 우리가 어제까지 정의한 질문을 기준으로 데이터셋을 찾아보기로 했었다. 하지만 한국어 데이터셋은 많지 않아 영어 회의록 데이터를 번역해서 사용하는 등의 방법을 고려하기도 했다. 하지만 일정대로라면, 이번 주 안에 데이터셋을 만들어야 하는데 시간이 부족할 것 같았다. 왜냐하면 데이터를 받아서 번역 및 가공하고, 가이드라인 작성하고, QA데이터를 추출하는 등의 작업까지 진행하게 된다면 적어도 다음 주 수요일을 넘길 것 같았다. 따라서 구축되어있는 한국어 데이터를 사용하자는 얘기가 나왔다.
그러던 중 한 팀원분께서 Competition에서 사용된 국회 회의 데이터를 찾아와주셨다. 수요일 회의 때는 국회 회의록의 경우 너무 광범위한 내용을 다루고 있어서 한계가 있다고 생각했는데, 해당 데이터의 경우 요약 Task를 위해서 요약이 가능한 Agenda를 기준으로 뽑힌 회의들만 모여있었기 때문에, 어느정도 공통죈 주제에 대한 회의를 진행하고 있어, 이를 사용할 수 있을 것이라 판단했다.
하지만 기존 뽑았던 질문 sample과 기준이 달라져, 내일까지 1차 파일럿 QA를 만들어오기로 했다. 이를 잘 조율해서 가이드라인을 작성하고, 주말 중으로 인당 200~300개씩만 만들면, 월요일까지 1000~1500개의 QA 데이터셋을 생성할 수 있을 것 같다. 그렇게 된다면 다음 주에 바로 모델 구현에 들어갈 수 있을 것 같다.
추가적으로 QA 데이터 셋 생성을 스프레드 시트로 할까 생각했었는데, 팀원분께서 QA Annotation Tool을 찾아주셔서 해당 Tool로 작업할 것 같다.

▶ Review (생각)

요즘 해야할 일들이 많다보니 계속 지치는 느낌이라 오늘 미뤄왔던 일들을 해치웠다. 과제를 제출하고(썩 만족그럽진 않았지만), 데이터셋 선정을 하고, 마일스톤이랑 To-do리스트 작성하고, 저번 대회기간 받았던 이력서 피드백(내일 또 보긴 해야하지만)도 반영해서 새로 작성했다. 확실히 미뤄왔던 일들을 처리하니까 속이 시원하긴 하다. 역시 나는 일이 한 번에 들어오면 지치는 것 같다. 사실 오늘 한 일들이 제대로 각 잡고 하면 하나당 최대 2-3시간이면 끝나는 일들이었는데, 뭐부터 해야하지...라는 생각에 오히려 시작이 더 늦어지는 것 같다. 이럴 때일수록 눈 딱 감고 당장 해야 하는 것과 할 수 있는 것 먼저 해결을 해나가야 한다는 것을 오랜만에 깨달았다. 뭐 이렇게 나를 알아가는 거 아닐까?
내일은 팀원들과 데이터 가이드라인 작성하고, 데이터 어노테이션 작업을 진행해야겠다. 그리고 내일 데이터에 관한 부분을 잘 마치면 분업에 관한 얘기도 한 번 해보면 좋을 것 같다. 그리고 강의 수강 부분에서는 CI/CD와 FastAPI를 빨리 수강해야 할 것 같고, 이번 실습 해설 코드도 읽어보면서 구현해보면 최종 프로젝트 파이프라인 작업할 때 큰 도움이 될 것 같다.