1. 개론

• 입사지원서류는 크게 세 가지다.
  • 이력서 : 주요 이력과 성과
  • 자기소개서 : 이력서에 쓰지 못한 내용 스토리
  • 포트폴리오 : 자세한 내용을 적을 수 있는 프로젝트

2. 직무경험 및 강점 도출

• NCS 기반 KSA (Knowledge Skill Attitude) 강점을 확인
• AI 과정이니까, 그 과정에 맞게 AI 서비스 기획, 모델 기획, 데이터 기획, 그에 따른 강점 목록을 확인하는 시간을 가졌다.

3. 직무 경험 도출 과정

• 그 동안 살아오면서 겪었던 했던 일들을 앞에서 살펴보았던 내 분야별 직무역량에 맞추어서 목록을 만들기. 이런 이런 과정을 겪으면서 이런 역량을 갖추게 되었다 등

4. 프로젝트 구조화

• STARC(T) / SOARA 기법으로 정리
• Situation 상황이 어땠냐
• Task가 뭐였냐 Object가 뭐였냐
• Act 어떻게 대처했냐
• Result 결과가 어땠냐 몇프로 올랐냐 / A
• Contribution 그걸로 회사에 어떻게 기여할 수 있겠냐 / Takeaway 뭘 배웠냐 / Aftermath 이 경험을 통해 어떤 변화가 있었느냐

어떤 상황에서 어떻게 행동해서 어떤 결과가 났고 어떤 걸 배웠고 어떻게 바뀌어서 어떻게 기여할 수 있느냐

5. Master 자기소개서

• STARC 중심으로 지원동기 / 입사 후 포부 / 성장과정 / 협업경험 / 직무 역량 / 성공경험 등 기본을 하나 만들어두고
• 회사마다 자기소개서 요청하는 항목에 맞게 커스터마이즈한다
• 회사의 최신뉴스, 3C (Company: 자사, Customer: 고객, Competitor: 경쟁사), SWOT(Strength, Weakkness, Opportunity, Threat)을 분석하여 회사와 관련있는 내용으로, 내가 입사하면 회사에 어떻게 기여하겠다는 내용을 적어야 함 ★

6. 회사 분석

• 스타트업에서 여러가지 경험하는 건 좋으나 너무 이른 시기에 시장성 검증 안 되고 시장에 안찾 안 된 회사에 가면 회사가 망해서 나올 수도, 월급이 밀려서 스스로 나올 수도 있다.
• 초기 스타트업을 안정화까지 올리는 것도 좋은 이력이 될 수도 있지만
• 회사 자체가 내려앉는 경우도 있기에 본인의 선택이며
• 일반적으로 시리즈 A 투자 받은 회사에 가기를 권고

[어려웠던 점]

• 이미지 넣으면 바로 나올 거 같았는데 그게 아니었다. 최상의 모델이라고 하는 것들도 완벽하지 않았고 이 완벽하지 않은 것을 보완하는 게 어려웠다
• 특히 한번에 글자가 튀어나오지 않고, 먼저 글자가 있는 영역을 bounding box라는 것으로 추출하고, 이후에 추출된 영역에서 글자만 가지고 번역(?)이라고 할까 인식하는 단계가 이어진다

[실제로 했던 점]

• 이미지 라벨링

1. 라벨링 툴은 많다. 오픈소스. 상용.
2. 대부분 이미지 넣고 GUI에서 그리는 것이 기본이다.
3. Label Studio를 했는데, 기존 이미지와 라벨을 함께 넣고, 기존 라벨이 형식이 다른 bbox일 경우 형식을 맞춰주는 부분이 생소해서 어려웠다. 결국 못했다. 나중에는 1) 새 이미지 라벨해서 라벨 저장하고 2) 저장한 라벨과 이미지 같이 불러와서 확인하고 3) 수정된 라벨 저장하고 4) 외부 이미지와 라벨 가져와서, 라벨을 Label Studio에서 원하는 형식으로 json을 변환하고, 이미지랑 같이 올리고, 수정해서 저장하는 일을 해봐야겠다.
4. 서버처럼 만들면 다른 사람들도 작업할 수 있게 할 수 있다던거 같은데 그것도 탐구해볼 예정이다.
5. 형식으로 label studio UI 지정하는 부분이 이해하기 어려웠다.
6. 멘토님이 이미지 하나씩 넘겨가면서 pass non-pass로 분류하는 프로그램 만들어주셨다.
7. bbox별 txt를 수정하는 소스도 만들어주셨다.
8. bbox가 잘 되었는지 확인할 때 파이썬으로 소스를 만들었는데 8개 점으로 이루어진 bbox를 만들었는데 polygon으로 된 좌표는 32개가 나온 경우가 있었는데 이 때 시각화가 잘 되지 않았다. quad box나 polygon이랑 bbox를 img에 그리는 소스는 달라야 한다

• 오픈소스 OCR 툴

  1. PaddleOCR 중국산인데 안정적인 성능
  2. EasyOCR 일반적인 성능
  3. Tesseract 구글이 인수했다고 하는데 그저그런 성능
  4. CRAFT 네이버에서 만든거 몇년 전 모델인데 bbox detecion 잘 잡았다.
  5. 그 외에 이렇게 패키지된 툴이 아닌, 실제로 추가학습을 시키거나, 학습이 필요한 경우는 여러가지 파라미터들이 조홥되서 운영되어서, 하나라도 맞지 않으면 도중에 에러가 나서 어려웠다. PyTorch 훈련로직을 잘 깨우치고, 모델별 특성까지 알아야 하여 짧은 시간에 할 수 없었다. 기본기가 정말 필요한 부분이라고 생각되었다. 특히 CV는 처음하는 것이라, 전통적 CV와 DL의 CV를 다 파악하게 되면 이 분야에 쓸 분야들이 많을 것 같았다. 영상처리 등.

• 각각 검출기별 또 성능평가 metrix에서 수용하는 결과 json형식이 다 달라서, 외부 데이터를 다른 툴에 집어넣을 때는 결과 GT labeling bbox가 포함된 json 구조를 수정해 줄 필요가 있지만 json 구조를 생각하며 LLM들과 함께하니 어렵지 않고 코드를 작성할 수 있었다.

  • vibe 코딩
  1. VSC에 open chat을 연다
  2. 참조할 파일을 @경로로 알려준다
  3. 하위 사원에게 지시하듯이 업무메뉴얼로 쫙 알려준다
  4. 혹은 기존에 비슷한 참조할 코드를 붙여서 이렇게 만들어줘하면 기똥차게 에러없이 바로 돌아가는 코드를 생성해 줍니다만
  5. 서버라던지 하나가 여러개와 연계된 코드같은 경우 제대로 해결하지 못하는 경우가 많았다.
  6. gemini code assistant VSC extension이 괜찮을 성능이고 구글에서 완전 무료로 풀어줘서 감사하게 쓰고 있고
  7. 향후 Cursor가 더 많은 격차를 낸다면 그리로 가야겠다
  8. Claude Code가 Research Preview에서 풀려진다면, 프로젝트 단위로 참조도 해주고 직접 실행까지 해 주기에, 내가 잠깐씩 필요한 코드를 따로 .py로 저장하고 실행하지 않고 바로 Claude가 실행하면 되서 참 편리할 것 같다.
  • 평가 metrix
  1. mAP 가 이미지 평가에서 가장 잘 쓰인다던데 bbox검출 단위가 띄어쓰기별로 다를 경우 (위대한 사람, 위대한, 사람) 점수가 반으로 떨어지는 것을 보면서 과연 이게 맞나 하는 생각이 들었고
  2. 기업 담당자분께서 훈련을 잘 시키면 GT랑 비슷한 범위로 bbox를 도출하는 model이 나온다는 점에 약간 수긍이 되었지만
  3. CLEval이라는 형식은 bbox 검출단위가 다르지만 의미상에 문제없는 경우에도 점수를 확 깎지 않고, 검출+인식 뿐 아니라 검출에서만도 가능하다고 해서 이걸로 썼다.
  • 이미지 정제
  1. Upstage Document OCR로 전체 이미지를 다 라벨링 다시 하고 모델 훈련시키는 아이디어가 있었다.
  2. 다만 아무리 제일 성능이 괜찮은 모델이라도 100%는 아니고 사람이 검수할 자원은 없기에 2-3개 모델이 비교해가며 검증하는 로직도 고려되었다.

우리는 대통령 탄핵과 헌법재판소의 전원 일치 탄핵 판결을 인정할 수 없습니다.

비상계엄을 선포한 실제 주제인 선거관리위원회에 대해서는 전혀 언급하지 않고 민주당의 주장만 읽었다고 볼 수밖에 없습니다.

민주당이 내란 혐의를 뺐다면 헌재는 즉시 이것은 재판사항이 아니므로 각하 했어야 합니다.

헌법 제84조에는 대통령은 내란 또는 외환의 죄를 범한 혐의 외는 형사상의 소추를 받지 않기 때문입니다.

이에 대해 범국민 저항운동을 전개 하기위해

☎07045056869 ☎07045055868 ☎07076108683 ☎07045015868 ☎07045053868

위의 다섯개의 번호중 하나로 전화해주시고

오는 토요일(2025.04.12.) 오후 1시

국민저항대회 광화문 광장으로 총집결해 주시기를 간곡히 부탁드립니다.

국민혁명의장/자유통일당 고문 전광훈목사드림

https://www.youtube.com/live/Fnbp4jcwkN0?si=6YqV0IkmneUJ4pez

꼭 보시고 광화문에 나오세요

1. Models에 모델을 무료로 올릴 수 있어서 호스팅 할 수 있다.
2. 허깅페이스 Spaces
   • Streamlit Cloud처럼 허깅페이스 내에 Spaces라는 공간에서 Streamlit/Gradio로 제작한 프론트를 호스팅해준다.
   • Models에서 쓰기 전에 Spaces에서 미리 Playground처럼 써볼 수 있다.
3. AutoTrain을 통해서 코드 없이 내가 원하는 모델을 (예:10개) 미리 사용해 볼 수 있다. 하나하나 다운받아서 테스트 하려면 시간이 걸리니 미리 고를 수 있다. 다만 유료이다.
4. 내가 원하는 데이터셋을 허깅페이스에 Datasets 항목에서 쓸 수 있다.
5. 내가 눈여겨 보는 기업(예: Meta)의 허깅페이스 Organization 페이지 따로 볼 수 있다.

먼저 Spaces에서 써 볼 수 있나 보고 AutoTrain으로 해보고 Inference API로 써보고 필요하면 다운받고 파인튜닝할 수도 있다.

• 격파르타에 참여한 이유
  • 혼자 공부하기에는 왠지 부담스러운 정보처리기사 시험
  • 범위가 너무 넓어 정직하게 공부만 해서는 2년 넘게 걸릴 것 같았다
  • 영어를 잘하더라도 토익시험을 보려면 시험에 익숙해지는 10%가 필요하다고 생각한다
  • 나도 컴퓨터에 관심이 많았지만 시험에 최적화되는 계기가 필요했다
  • 그러기 위해서는 먼저 선배들의 가이드가 필요했다
  • 합격하면 수강료를 돌려준다고 하기에 몇십만원씩하는 수강비 부담도 덜었다
• 격파르타에서 좋았던 점
  • 책이 깔끔했다 (거의 보지 못했지만 ...)
  • 5회분 정도 제공된 모의고사를 3회 정도 풀었던 것 같다
  • 온라인으로 모의고사를 볼 수 있어서 실전 감각을 느낄 수 있어서 좋았습니다
  • 강의가 핵심만 짤막짤막하게 시험에 최적화되면서도 원리를 설명해 주셔서 좋았습니다
• 격파르타에서 아쉬웠던 점
  • 모의고사에서, 답이 틀리거나, 같은 보기가 두개가 있거나, 문제가 좀 이상하게 모니터에 출력되거나 하는 문제가 있었다.
  • 그래서 풀고나서도 이게 맞았는지 틀렸는지 가물가물했고, 복잡해서 이해에 너무 시간이 걸릴것 같은 문제는 그냥 접어두고 넘어가야 했다... 시험에서 제공한 정답이 맞았다는 가정을 할 수가 없었기에
• 격파르타는 이런 분들께 추천하고 싶어요!
  • 중반정도 IT 지식을 공부하신 분들께서 시험 막바지에 정리하는 샘치고 보면 좋을 것 같습니다
  • 시험 감각을 익힐 수 있고
  • 수강료도 제세공과금 (22%) 제외하고 돌려준다고 하니까요
  • 강의도 전체 범위를 핵심만 추려가며 문제와 함께 설명해주셔서 어느정도 부분이 어디에서 나온다는 감을 잡기에 아주 좋았습니다
• 2025년 정보처리기사 필기 경험담
  • 2022년에도 필기를 봤었지만(실기를 못 붙었음) 그 때는 손으로 쓰는 거였는데, 지금은 컴퓨터로 보는 거라서 (CBT Computer Based Test)컴퓨터용 싸인펜이 필요하지 않아요.
  • 결과도 끝나고 바로 볼 수 있어요.
  • 다만 실기는 아직 종이에다 한다고 해요 (PBT Paper Based Test)

220개의 질문을 벡터화해서 4000여개의 지식문서에서 관련있는 것들만 뽑아오는 숙제

초기 설계도

처음에 강의 들을 때는 야심차게 시작을 했으나

막상 종결했을 때는 intent 분석 하나 해결하기도 벅찼다.

프로그램에게 단순히 어떤 일을 하는 건 너무 쉽고, 어찌보면 LLM이 필요없고,

여러번의 생각과 자기성찰을 거쳐서 정갈한 답변을 내놓지 못하고 엉성한 답변을 내놓는 것이 LLM의 약점이었다 Hallucination이라는 이상한 말로 마케팅으로 커버하려 하지만, 결국 내용을 파악하지 못하고, 이 단어 앞에 나올 다음 단어를 확률적으로 넣는다는 것이 약점이었다. 결국, LLM은 무슨말인지도 모르고 그냥 내뱉는다는 것이다.

그래서 우리에게 필요한 것은 생각할 수 있는 reasoning model이었다!!!

OpenAI에서 GPT-4o같은 일반 모델을 Workhorse모델, o1, o3-mini 같은 모델을 reasoning 모델, 다시 말해서 "Planner"모델로 부른다는 것도 알았다.

intent를 분석하는 것은 ambiguous한 상황을 분석하여 결론을 도출하는 것으로 reasoning모델이 제일 잘하는 영역이라는 것이다.

결국 o1-preview 모델로 정확히 intent를 분석하게 되었다.

이후 쿼리 생성에서 약간의 성능향상 후에,

임베딩 모델 테스트, LLM as a judge 기능으로 결과 검증을 해보고 싶었지만 4일의 시간으로 할 수 없었다.

• 작성 내용(필수):
  • 나는 내 학습목표를 달성하기 위해 무엇을 어떻게 했는가?
    • 처음 리더보드에 제출하면서 경험한 intent 분석의 어려움을 해결하려고 노력했고, o1-preview라는 reasoning model을 사용하여 100% 가까운 수준으로 해결하였다
  • 전과 비교해서, 내가 새롭게 시도한 변화는 무엇이고, 어떤 효과가 있었는가? (2번째 경진대회부터 해당)
    • 이전 경진대회와는 달리 상업용 API 사용이 되어서, 현재 트렌드를 파악하며 가장 가성비가 최선이면서 본 문제해결에 적합한 모델을 찾아내었다.
  • 마주한 한계는 무엇이며, 아쉬웠던 점은 무엇인가?
    • 전체 성능향상 구간을 3개로 보았을 때 가장 핵심이 되는 RAG부분에 발을 들여놓지 못했다. Upstage, OpenAI 등 여러 임베딩 모델을 시도해보고 성능이 좋다는 ColBERT도 해보고 여러번 말을 들었던 Elasticsearch도 익혀보고 싶었지만, intent분석, LLM 분석에 깊이 빠져들어서 RAG까지 가보지 못했다.
  • 한계/교훈을 바탕으로 다음 경진대회에서 시도해보고 싶은 점은 무엇인가?
    • RAG, Embedding, 멀티모달 Embedding, LLM Cookbook을 사용하여 좀 더 풍성한 서비스 개발을 해보고 싶다.

데이터 클렌징

• 사람이 직접 (공수가 심함)
• 규칙 기반으로 사이클을 돌린다 (일관성과 정확도를 늘린다)
  • 규칙적인 라벨링 에러가 별로 없음
  • 코딩하는데 많은 시간 소요
• 공수가 적게 드는 LLM이 한다 (LLM as Judge)
  • 데이터는 학습 데이터 뿐만 아니라, 모델이 추론한 값도 클렌징이 가능하다. 인간이 하던 판단기능을 LLM이 대신 한다.

• 작성 내용(필수):

  • 나는 내 학습목표를 달성하기 위해 무엇을 어떻게 했는가?
    • Agent에 대해서 개념과 여러가지 도구들을 살펴보았다.
    • 그 중의 하나인 OpenAI의 Function Call을 활용한 Agent 구축을 하였다.

• 

  • 전과 비교해서, 내가 새롭게 시도한 변화는 무엇이고, 어떤 효과가 있었는가?
    • 새롭게 시도한 점은 없었고, 예전처럼 문제의 핵심을 보려고 노력했고, Agent라는 우리 팀의 주제에 맞게 Agent가 무엇이며 Agent로 무엇을 할 수 있고 어떻게 구현해야 하는지 이론을 많이 공부했다.
  • 마주한 한계는 무엇이며, 아쉬웠던 점은 무엇인가?
    • Function Call 학습을 통해서 Agent의 원리나 구조를 익혔다.
    • LangChain 기반한 좀 더 체계적인 Multi-agent 구축을 하여 실생활에 쓰일 수 있도록 하고 싶다.
  • 한계/교훈을 바탕으로 다음 경진대회에서 시도해보고 싶은 점은 무엇인가?
    • HuggingFace 강의(Agent, NLP, Transformer)를 통하여 상용화 할 수 있는 Agent 시스템을 구축하고 나만의 라이브러리로 만들고 싶다. 충분히 강력한 제품으로 만들 수 있을 것 같다.

• 작성 내용(선택/참고):

  • 나는 어떤 방식으로 모델을 개선했는가?

    • Agent가 활용할 수 있는 도구인 툴을 4개(네이버 검색API, 사용자 정보 CRUD) 정도 만들었다.

    • 

    • 만든 툴을 LLM이 자동 호출하는 흐름을 구축하여 동작해 보았다.

  • 내가 해본 시도 중 어떠한 실패를 경험했는가? 실패의 과정에서 어떠한 교훈을 얻었는가?

    • 아무래도 LangChain같은 Library를 사용하는 것에 비해 좀 체계적이지 못해서 이미 다른 사람들이 겪었던 실수를 다시 하지 않았나 싶다. 다음에는 제대로 차근차근 진행해야겠다.
      • 한 예로 사용자 id를 모르면 질문해서 받으라고 LLM에게 얘기했는데, 얘가 계속 자기 맘대로 id를 지어내고, 그에 딸린 정보들까지 지어내는 것을 보고 (hallucination) 참담함을 느꼈다.

  • 협업 과정에서 잘된 점/ 아쉬웠던 점은 어떤 점이 있는가?

    • 각자 자기가 관심있는 분야에서 호기심과 열정과 책임감을 갖고 임했던 점이 좋았고
      • 매번 아쉬운 점은 새로운 개념을 하나씩 익혀가면서 작업(프로젝트)을 해야하다보니 각자 자기가 맡은 단위테스트 끝내기도 급급해 통합테스트를 충분히 거치지 못한 점이다.
      • 하지만 매번 다른 프로젝트여도 같은 IT, AI, 깃헙 기반 프로젝트이기에 이전 프로젝트에서 미진했던 부분을 다음 프로젝트에서는 더 유창하게 구현해내는 것을 보고 전체 과정을 얕게 여러번 깊이를 늘려가는 방식이 훌륭한 설계라고 생각한다.

1. 서비스 계정 생성 (GCP Console)
2. json key 파일 다운받기 (GCP Console)

• 구글 클라우드 콘솔에서 console.cloud.google
• 서비스 계정 -> 이메일 클릭 -> 키 -> 키추가(json)

3. IAM에 위 1.에서 발급한 서비스 계정 등록 (GCP Console)
4. IAM에 역할 등록 (GCP Console)
5. 로컬 코드에 json key 파일 경로 참조시키기(Local)

   from google.oauth2 import service_account
   SERVICE_ACCOUNT_FILE = "GCP 콘솔에서 다운받은 json 파일 경로"
   credentials = service_account.Credentials.from_service_account_file(SERVICE_ACCOUNT_FILE)
   db=firestore.Client(credentials=credentials)

• 아래처럼 환경변수에 json 파일 경로 등록하면 터미널 나갔다 오면 다시 등록해야 해서 아주 불편함 export GOOGLE_APPLICATION_CREDENTIALS="/data/ephemeral/home/upstageailab-llm-pjt-chatbot-1/Daun/upstageailab5-llm-pjt-8a83e65dcb7a.json

6. 구글 GCP API 콜 실행 (Local)

• 앱에서 동작하게 하려는 거면 개인 이메일 계정 등록할 필요 없음
• 발급한 서비스 계정 하나면 됨
• .gitignore에 추가 안 해서 github에 올라가 있으면 구글에서 자동 탐지해 json파일이 자동 막히게 되 있는 거 같다. Google이 공개 저장소에서 감지된 서비스 계정 키를 자동으로 사용 중지합니다. 'iam.serviceAccountKeyExposureResponse' 조직 정책을 사용하여 이러한 동작을 맞춤설정할 수 있습니다.
• 잘 되다가 다시 금방 json JWT 오류가 나면서 막히던게 github에 유출됐기 때문인지 아니면 환경파일에 등록하고 소스코드에 넣지 않았기 때문인지는 더 살펴봐야 할 것 같다.

• 나는 내 학습목표를 달성하기 위해 무엇을 어떻게 했는가?

  • 전부터 궁금했었던 LLM API를 써보았다. (solar-mini)
  • 프롬프트부터 다양하게 시도해서 요약성능을 높히려 했다.
  • 업스테이지에서 제공하는 다양한 서비스를 살펴보았고, 프로젝트와 연관있는 것은 다 시험해보려고 하였다.

• *전과 비교해서, 내가 새롭게 시도한 변화는 무엇이고, 어떤 효과가 있었는가? *

  • 시작부터 팀원분들과 github 세팅부터 하고 시작하여서, 이후 코드 및 데이터 공유가 훨씬 수월했었다.

• 마주한 한계는 무엇이며, 아쉬웠던 점은 무엇인가?

  • 허깅페이스에서 모델을 받아서 파인튜닝을 하고 싶었지만, 그래서 결국 여러 모델을 써보며 fine-tuning하고 LoRA 등 경량화 기법으로 더 큰 모델을 사용해보려는 시도는 하지 못하였다.
  • 처음에는 solar API를 보고 너무 반가워서 계속 여러가지 시도를 해봤고
  • 이후에는 데이터에 관심이 생겨서 solar-groundness-check 등으로 데이터 정제를 하게되었고, 외부데이터를 가져와 train.csv와 비슷하게 만들어 데이터확장을 하였다.
  • solar gronudness API로 이상 데이터 197개를 임시로 삭제해서 성능향상을 보았는데, 그것보다는 하나씩 살펴보며 데이터를 보정하여 197개의 소중한 훈련 데이터를 그대로 최대한 살리는 것이 더 나을 것 같았다는 생각이 든다.

• 한계/교훈을 바탕으로 다음 경진대회에서 시도해보고 싶은 점은 무엇인가?

  • 주어진 데이터를 무작정 신뢰하지 말고, 하나하나 주의깊게 살펴보아야 하고, 이 일을 팀원이 함께 하는 팀 스케쥴로 잡아서 철저히 진행해야 된다.
  • 데이터는 개발자가 모델의 파라미터를 간접적으로 조종할 수 있는 유일한 방법이다.
  • 아직 익히지 못한 허깅페이스에서 transformers 모델을 받아서 파인튜닝 해보는 것을 별도로 하고 싶다.
  • 모델을 훈련했으면 S3에 올리고, streamlit에서 S3에 호출해서 서버리스로 배포하는 일도 해봤으면 한다.

• 경진대회를 통해 드러난 나의 성향과 약점

  • 그 동안 세번의 경진대회(집값예측ML,이미지분류DL,NLP요약)를 하면서 내가 성능 개선을 시도했고 향상효과를 이뤄냈고 천착해서 계속 노력했던 분야는 모델이 아닌 데이터였다. 이유를 생각해보니
  • 항상 모델을 훈련시키기 위해 어떤 데이터를 주입해야 모델이 내가 원하는 정답을 쏟아낼 수 있을지 생각했었고, 그러다보니 정확한 데이터가 무엇일까를 계속 고민하였다. 자연히 훈련/검증/평가셋 구성도 고민했었다.
  • 또한, 아직 프로그래밍 실력이 완숙되지 못했고, 새로운 코드들을 보면서(Dataloader 등) 왜 이 코드가 필요한지에 대해서 깊이 생각해보다보니 진도가 쉽게 나가지 못했다.

Upstage solar-mini API 쓰면서 느낀 점

단일 task는 할 수 있을지 모르겠지만, 복합 단계 task는 못한다. 특히 이어지는 task는. 특히 요약문 길이 줄이라고 했는데 왜 이렇게 못 줄이는지.

1. API의 rate limit 에러 (too many requests)

   • sleep으로 하드코딩 지연
   • 멘토님 ratelimite 라이브러리 추천

2. 그래도 나오는 API 서버 에러

   • try except 구문에서 에러 메세지 찍고
   • while문 받아서 5회 반복하고
   • 그래도 안 되면 fname 리스트에 담아두고 그 행 넘어가고, 마지막에 모아서 별도 처리

3. rate limit으로 인한 throughput 제한 (12457건 수행 시간 몇 시간)

   • 서버측 제한이기에, API키를 계정당 여러개나 여러계정별 API를 받고
   • 멀티스레딩/멀티프로세싱으로 동시실행하기

4. 정확도 제한

   • fine-tune 없이, 퓨샷과 프롬프트 엔지니어링 만으로 최적화를 시킬 수 없다
     • solar-mini로는 처음 41점 이상으로 올리지 못했고,
     • solar pro로 했을 때 1점 향상이 있었다. 42점.
   • 파인튜닝 필요
     • HuggingFace 다운로드 후 파인튜닝
     • Predibase 파인튜닝

5. 그 외 Solar API 사용기

   • groundness-check : 팩트 체크
     • 대화와 답변을 주면 답변이 대화에 근거했는지를 grounded, uncertain, NotGrounded로 반환
     • Grounded가 아닌 것만 추출 197개하여 성능향상
   • translation-koen - 번역
     • 역번역
   • solar-pro LLM 활용하여 외부 데이터 정제
     • 외부에서 가져온 요약문에는 스페셜토큰(#Person1#, #Person2#)이 없고, 이를 프로그래밍으로 붙이기는 일정한 규칙이 없기에 불가능해서, solar pro로 예시 대화문과 요약문을 주고 외부데이터 요약문을 변형하라고 지시

6. 결론

   • Solar나 GPT만으로 높은 정밀도를 요하는 작업을 하는 데는 제한이 있다.
   • 다만, 전통적인 프로그래밍방식으로 해결하기 어려우면서도 특정한 작은 작업(팩트체크, 스페셜토큰 붙이기)에 한정해서 활용하는데는 이점이 있다.

7. 자체 언어모델 보유의 필요성

   • LLM (API)의 정확도의 한계 (커스터마이제이션)

     • 퓨샷 / chain of thoughts / Agentic AI

     • 위와 같은 용어들을 들으면서 왜 이렇게 복잡하게 하는 거지? 그냥 한방에 말하면 다 알아서 듣는거 아냐? 라고 생각했는데,

     • 금번 솔라 미니 모델을 쓰면서 느낀점은 아무리 자세히 다양한 방식으로 말해도 말한데로 하지 못한다는 점이다.

     • 그렇다고 버리기에는, 뭔가 잘 말은 하는 것 같으니 아쉬워서 조금만 더 성능을 올려보려는 시도에서 나온 기술(?)들인 것 같다.

     • 하지만 프롬프트만으로는 전통적 프로그래밍처럼 뭔가 속 시원한 해답을 얻을 수 없다는 생각이 들었다.

     • sLLM을 기업들에서 쓰는게 트렌드라고 IT 기업에서 말하여서 혹시 마케팅용으로 말하는 거아냐라고 의심했는데, 막상 상용 LLM을 써보니 그 한계가 너무 명확해 보였다. 일반적인 작업들은 잘하나 정밀한 커스터마이제이션을 요하는 Domain-specific 작업에는 분명히 한계가 있다고 보였다.

       • 기업에서 직접 하기 위해서는 GPU가 모자랄 수 있으니 sLM의 중요성이 커진다고도 한다.

     • 다른 조 발표 자료 중에 프롬프트 엔지니어링으로 3-4점 점수향상을 보인 팀이 있어서 나중에 프롬프트 엔지니어링을 다시 제대로 공부하고 적용하면 성능향상이 있을 것 같다.

   • API (LLM)의 안정성의 한계 (가용성)

     • rate limit(API 제공사에서 API를 호출하는 횟수나 양에 제한을 걸어둔 경우)이 걸려서 API키를 여러개 받지 않으면 안정적으로 쓸 수 없다
       • rate limit 제외한 에러도 생각보다 자주 발생했다
       • 이런 정도의 안정성을 핵심 서비스로 대중에게 공개했다가는 나중에 큰 골치가 아플 것 같았다
       • 자체 모델을 호스팅하면 이런 문제도 해결하면서(안정성), 성능도 내가 원하는 데로 최적화 시킬 수 있다는 데 큰 장점이 있을 것 같다(정확도).

   • 그 외 자체 LLM 모델 보유 필요 시나리오

     • 보안 : 사용자 정보가 LLM 서버로 유출된다.
     • 폐쇄망 : 금융사 등은 인터넷이 안 되는 환경이 있다.
     • 비용 : 쓰려고 하는 상용 LLM 비용이 높은 경우

8. 그 외 느낀 점

   • 모델선택, 하이퍼파라미터튜닝, 보다 제일 중요한 게 모델이 생각하는 방식, 즉 가중치와 편차, 다시 말해서 모델의 파라미터를 조절하는 것이다. 이것은 모델이 주어진 데이터를 가지고 경사하강법을 통해 스스로 조절한다. 개발자는 모델에게 어떤 데이터를 줄지를 결정하면 모델의 파라미터를 간접 조정할 수 있다.

htop # 직관적인 cpu 사용량 확인 sudo apt update sudo apt install htop top # 일반적인 cpu 사용량 확인

• 인공지능 개발은 데이터와 모델이 있다고 생각하였다
• 모델은 모델구조(종류)선정, 하이퍼파라미터튜닝이 있고
• 데이터는 별도의 다른 분야라고 생각하였는데
• 모델이 어떻게 움직이는 걸 결정하는 게 모델최적화라면
• 모델이 어떻게 생각하는 걸 결정하는 게 데이터였다
  • 왜냐하면 결국 데이터가 하는 일이라고는,
  • 모델의 파라미터를 점진적으로 최적화하는 것이기에
  • 파라미터는 가중치와 편차를 말하는데, 그냥 모델이 스스로 생성해내는 알고리즘이다
  • 이걸 인간이 복잡하게 할 수 없으니
  • 모델이 스스로 판단하게 하는데
  • 이 모델의 작업에 간접적으로 인간이 할 수 있는 일이 데이터를 주면서 그에 맞는 파라미터를 업데이트시키는 것이다
  • 결국 인간이 모델에게 할 수 있는 일은 먹이(데이터)를 쥐어주고 그에 맞도록 변화하도록 하는 것이다.
  • 그래서 프로젝트 시작 초반에는 베이스라인 돌려보고, 리더보드 제출도 하면서 전반적으로 친숙해지는 시간을 갖고, 꼭! 반드시 모델의 먹잇감인 데이터를 하나씩 뜯어보면서 어떤 먹이를 모델에게 줄 것인지 다같이 팀으로 모여서 탐구하는 시간이 필요하다. Trash in Trash out

실행 환경

• 원격 리눅스 컴퓨터에, 비쥬얼스튜디오코드(VSC)에서 설치한 Remote Explorer extension으로 접속해서 사용 중

  문제 증상

• 잘 되던 파이썬 라이브러리들이 일시에 갑자기 모두 설치가 안 된 것으로 나온다
• 없다는 모듈들을 다시 설치를 해도 module not found가 나온다
• 이전에는 ctrl+shift+p에서 Python Interpreter에서 여러가지 파이썬 인터프리터들을 선택하다보면 증상이 해결되었다.
• 하지만 이제는 직접 선택을 하여도 계속module이 없다고 나온다.

문제 해결 실마리

• VSC 우측하단에 명시된 버전은 파이썬 인터프리터 버전인데, Python Interpreter를 다른 버전을 선택하여도 우측 하단 버전은 변하지 않는다.
• VSC 우측 하단에 버전이, Terminal에서 python --version 할 때 나오는 버전(실제 실행환경)과 불일치한다
• 확인을 해보니, VSC 우측하단 버전은 원격 컴퓨터 파이썬 경로가 아닌, 로컬 파이썬 환경 경로였다.

원인

• 터미널에서 실제 파이썬 파일들 실행하는 파이썬 실행환경(위치)이 VSC에서 설정된 기본 파이썬 실행환경(위치)하고 일치하지 않는다.
• VSC에 설정된 기본 파이썬 실행환경이 갑자기 원격에서 로컬로 변경되고 변경이 되지 않는다.

대책

1. 컴퓨터를 몇일동안 안 끄고 살았더니 VSC가 정신을 못 차렸다. 작업파일들 저장하고 컴퓨터를 껐다 켰다.
2. settings.json에 기본 파이썬 인터프리터 경로가 로컬경로인 C:~ 되어있어서, 강제로 원격컴퓨터 파이썬 실행환경 경로로 바꿔줬다.
3. 그리고 Python Interpreter를 직접 골라줬다.
   • Ctrl+Shift+P 혹은 VSC 우측 하단에 파이썬 버전명 클릭
4. 그리고 VSC를 껐다 켰다.
5. 드디어 우측 하단 버전이 원격컴퓨터 파이썬 환경으로 변동되었고,
6. 안 불러와지던 모듈들은 문제없이 불러와졌다.

요약

우측 하단의 Python Interpreter는 VSCode가 현재 사용하는 Python 실행 환경을 나타냅니다. 만약 원하는 환경이 선택되지 않았다면, Python Interpreter를 수동으로 설정하여 터미널과 동기화하세요.

VSC 불안정성

• VSC 불안정성 때문인지 갑자기 되었다가 다시 안 되었다가 한다
• 안 될 때는 무슨 방법을 써도 안 된다

작업폴더 변경해서 파일 열었더니

• 같은 파일도 작업 중이던 깃폴더에서 아니고
• 그 외 폴더에 있는 파일 열었더니 다른 파이썬 인터프리터가 되면서 안 되는 것 같다.

• 나는 내 학습목표를 달성하기 위해 무엇을 어떻게 했는가?

  • 최대한 많은 수의 실험제출을 하기 위해 노력하였고, 하고 싶었던 모든 것들을 다 올려서 확인해 보았다.
  • 체계적인 실험을 하기 위해서 Validation Set을 만드는 법에 대해 고민하며 공부하고 실험하였다.

• 전과 비교해서, 내가 새롭게 시도한 변화는 무엇이고, 어떤 효과가 있었는가?

  • 지난 번 ML 경진대회 때는 이론과 강의를 먼저 수강하고 baseline 코드 학습을 시작했지만, 이번에는 대회 관련 강의를 먼저 듣고 코드 학습을 바로 시작했다. 할 수 있는 모든 리더보드 제출을 해 보았다.
  • 빠르게 대회에 적응하고 점수 향상을 위해 가설수립, 실험, 채택의 과정을 겪을 수 있어서 조바심 없이 대회에 임할 수 있었다.

• 마주한 한계는 무엇이며, 아쉬웠던 점은 무엇인가?

  • 급하게 실험하고 리더보드에 점수 제출하는 데에만 치중하다보니, 막상 배워야 할 이론과 기본기들을 적용하지 못해서 아쉬웠다.
  • 대회적응과 기본개념 숙지를 잘 조화하면 좋을 것 같다.

• 한계/교훈을 바탕으로 다음 경진대회에서 시도해보고 싶은 점은 무엇인가?

  1. 초기 검증셋과 평가셋의 차이를 확인하기 위해 리더보드에 최대한 많은 제출을 시도한다
  2. 주먹구구식이 아닌 체계적이고 과학적인 실험을 진행하기 위하여, 검증셋을 평가셋과 동일하게 해 놓고, Epoch별 훈련, 검증셋의 정확도 추이를 그래프로 확인한다.
  3. 검증셋에서 점수가 낮은 부분을 분석을 통해서 재학습 방안을 적용한다.

• 나는 어떤 방식으로 모델을 개선했는가?

  • 프로젝트 초기 다들 많은 진전이 없을 때 다량의 리더보드 제출로 대회에 대한 감을 익히려 노력하였다.

  • 어떤 요인이 긍정적인 효과를 만들어내는지 원리를 알아내고자 노력하였다. A / B 테스트를 통하여 소통 없이 실험으로 답을 알아내는 법을 터특하였다.

    

  • 모델학습의 핵심이 되는 데이터 버저닝에 대한 체험을 할 수 있었다.(Garbage-in Garbage-out)

• 내가 해본 시도 중 어떠한 실패를 경험했는가? 실패의 과정에서 어떠한 교훈을 얻었는가?
  • 프로젝트 여러번 해보는 것도 중요하지만 가장 기본적인 원리를 깨닫고 적용하는 것이 필요하다.
    • 예: 검증셋 정교하게 적용, Early Stopping, 하이퍼파라미터 기록 및 찾기(Optuna, WanDB)
• 개발문화, 협업방식 관련 회고
  • 너무 강하게 압박하는 것과 완전 방치하는 것의 중간단계가 좋다.
  • 지난 번 프로젝트는 하루에 2번씩 만나면서 긴장감을 계속 유지하다보니 힘들었다
  • 이번에는 각자 작업하다가 잠깐씩 만나서 서로 공유하니 개인적 상황에 최적화 할 수 있으면서도, 전체적인 조율을 잊지 않았다
  • 개인적으로는 개인의 능력을 최대한 끌어내면 조직을 위해서도 사용하고 개인의 발전을 위해서도 좋은 접근으로 보인다.
  • 통제와 관리보다는 자율과 존중과 배려가 좋다.
  • 또한 개발자는 생산직이기에 아이디어와 행정보다는 동작하는 제품이 제일이다. 개발(생산)하는데 열과 성을 다해야 한다.

• 열심히 학습데이터를 만들고(데이터 + y값/정답/라벨)
• 모델(학생)을 학습(train)데이터로 훈련을 시켰는데
• 얘가 실제 수능에서 잘할지 못할지 알수 없어
• 왜냐하면 현실세계는 아직 (y값/정답/라벨)을 만들지 못한 불확실한 데이터 이기에 그걸로 시험해서는 결과가 잘 나오는지 안 나오는지 채점할 수가 없어
• 또한 모의고사는 여러번 시험쳐도 피해가 없지만, 수능(실제 현실세계)은 한번 떨어지면 손해가 막심하거든
• 그래서 모의고사를 치르도록 하는 거야 그러기 위하여는
• 학습(훈련)한 내용 외에 한번도 보지 못한 문제를 풀어보게 해서 객관적으로 학생(모델)의 실력을 측정하려는 거지
• 방법은 모아둔 문제(데이터)와 정답(y값/라벨)을 쪼개서 하나는 훈련(학습)에만 사용하고 다른 하나는 모의평가 용지로 사용하여 모델의 역량을 측정할 수 있지
• 그거 없이 풀었던 문제(학습 데이터)만 계속 푸는 걸로 모델을 사전평가해버리면, 아예 문제도 안보고 순서대로 답만 외워버리지 않겠니? 그리고 실제 수능가면 빵점 맞고

2. 검증(validation data)셋이 필요한 이유

• 평가(test)은 정답(y값, label)이 없다는 전제야
• 그 말인 즉은, 문제를 풀어도 총점은 알 수 있지만
• 어떤 과목에서 어떤 문제를 얼마나 틀렸는지 알 수 없고
• 오답노트를 만들 수가 없어
• 다시 말해서, 모델(학생)이 어떤 문제를 어려워하는지 알수 없어서, 학습이 아닌 시험(평가, test data)에서 잘하기 위해서 어떻게 학습계획을 짜야하는지 알 수가 없는거야
• 그래서 검증셋은,
  • 시험(test)문제와 최대한 유사하면서
  • 학생이 학습 기간 중에는 한번도 보지 못한 문제들로 이루어져야 해
• 정답이 없는 평가를 대비해, 정답이 있는 가상의 평가문제를 만든게 검증데이터야
• 만약에 검증셋에 있던 데이터들이 학습셋에 포함되어서 모델이 검증셋을 엄청 잘풀게 된지만(이미 학습했기에) 실제 현실 문제에서는 낮은 성능을 갖게 되는 문제를 데이터 누수(Data Leakage)가 발생했다고 해. 엄격하게 분리되어야 할 시험(평가)문제가 훈련데이터 묶음으로 누수되었다고 하는 거야.

  3. 검증셋 만들어도 평가셋 성능 안 오르던데?

• 검증셋은 말그대로 모의고사야. 모의고사는 사전 준비하는 것일 뿐 실제 수능시험에서 잘 본다는 것과는 전혀 상관없어
• 특히 모의고사(검증셋)을 봐서 86점을 맞았다고 치자
• 내가 틀리는 14점에 연관된 문제를 찾아내서, 그 개념을 익히고, 연습문제를 풀어봐서 내가 취약한 부분을 보완하지 않으면 모의고사 100만번 보아도 너는 영원히 86점이야.
• 그래서 검증셋은 만들어서 모델이 추론해본다고 해도 그거 자체만으로는 아무 쓸모 없는 거야. 그걸 보고 나서 회고를 잘 해야지.

  4. 검증셋 만들어서 그럼 뭘 할 수 있는거야?

  1) 모델의 과적합(학습이 아닌 문제 암기) 방지

• 기존 고정된 학습(train) 데이터가 모델 성능향상에 얼마나 효과적인지 알 수 있어
• 같은 훈련셋만 가지고 모델에 학습시키면 일정한 횟수를 넘어가면 정확도가 100점에 가까와져. 사실 그건 같은 문제를 풀었기 때문이지 모델이 실력이 좋아서가 아니거든.
• 그래서 한번도 안 풀어보면서도 정답이 있는 검증셋을 만든 거야.
• 훈련데이터셋을 만들어놓고, 모델이 100번 학습하게 해. 그리고 매번 학습할 때마다 검증셋(모의고사) 시험을 보게 해서 그 결과를 확인해봐. 어느 순간까지는 검증셋 점수가 계속 오르다가 어느 시점부터는 더 이상 오르지 않고 오히려 떨어지는 순간이 되. 이걸 모델이 과적합(Overfitting)되었다고 해. 이 때 모델의 훈련을 멈춰야 해. 이걸 Early Stopping이라고 해.
• 훈련을 반복했는데 점수가 떨어지니까 이상하지? 모델은 사람이 아니라 확률에 의해 스스로를 발전시키는데, 처음에는 학습데이터의 패턴을 학습하며 진정한 학습을 진행했다면, 나중가면 꾀가 생겨서 이미 풀어본 문제의 답만 제출하는 방식으로 잔꾀만 부리니 실제 시험에서 처음 본 문제를 보게 되면 실력이 없으니까 오히려 점수가 떨어지게 되는 거지. 그래서 적절한 학습데이터 반복횟수에서 중단(Early Stopping)을 하는 거야.
• 가지고 있는 훈련데이터를 1번 반복하는 것을 인공지능에서 EPOCH(에픽,이팍,에폭)이라고 해. 검증셋을 돌려보면 학생에게 훈련셋을 몇번까지 훈련시키는 게 한번도 안 본(unseen) 문제를 잘 푸는데 최적의 훈련횟수(EPOCH)인지를 알 수 있게 되지
• 이렇게 모델(학생)이 공부한 문제 뿐만 아닌 안 본(unseen) 문제도 잘 풀 수 있게 만드는 것을 모델을 강건하게(robust) 만든다, 혹은 모델의 일반화 성능(generalization performance)을 향상시킨다고 해
• 경진대회 같은 곳에서는, 참가자들이 주어진 데이터에만 정답암기 후 찍기 형식으로 모델을 학습시키고 실제 현실 데이터에서는 부실한 모델을 훈련시켜서 우승하는 것을 방지하기 위해 평가데이터를 보여주지 않기도 해.

2) 모델의 취약점 개선 방안 도출

• 또 한가지 중요한 장점은, 학생(모델)이 어떤 부분에 취약한지를 알게 되는 거야.
• 검증셋을 풀었던 결과를 총점이 아닌 개별 문항을 보면서 분석하게 되면 이 아이(모델)가 어떤 부분이 약한지 알 수 있겠지? 분수, 함수, 그래프, 동사, 명사, reading 등
• 그 취약점 목록을 가지고 오답노트도 만들고 다음 번 학습 때 맞은 거는 안 보고 틀린 문제의 패턴들만 주구장창 학습시키는 거야
• 그럼 해당 개념을 숙지하고 학습하면 다음번에는 그 패턴들은 다 맞을 수 있겠지?
• 이렇게 검증셋은 검증셋을 풀어본것만 가지고는 학생의 실력향상과 무관하고, 그 결과를 꼼꼼히 분석해서 오답노트를 만들어 재학습을 완벽히 하였을 때만 의미가 있어.

3) 검증셋 뿐 아니라 훈련셋에 대해서도 시험을 봐

• 훈련셋은 모델이 이미 학습한 문제이기는 해서, 그걸 많은 횟수(EPOCH)를 공부하면 자연히 그 문제를 풀게되면(추론, inference) 점수가 잘 나오는 건 불을 보듯 뻔하지. 그렇다면 훈련셋을 공부(훈련)만 하지 다시 추론(문제풀기)할 필요가 있을까?
• 응 있어. 훈련셋을 다 풀 수 있나가 궁금해서 보는게 아니라, 훈련셋 공부를 완성했는지 여부를 알 수 있어. 1번 보고 추론해서는 점수가 낮지만 13번 봐서는 만점에 가까운 점수가 나왔고 14번 이후에는 계속 만점이라면, 더 이상 공부할 필요가 없어지는 거지.
• 모델이 수차례 학습할 동안 매차례 학습 후에 모델보고 풀어보게 하면, 얘가 이미 봤던 문제긴 하지만, 그 문제라도 제대로 풀 수 있는지 아니면 아직 학습이 덜 되었는지 알 수 있기는 하잖아?
• 이렇게 학습이 덜 된 상태를 과소적합(Underfitting)되었다고 해. 즉 주어진 학습데이터를 아직 덜 공부했다 이 말이야. 이 때는 아직 주어진 문제들도 다 공부하지 못해서, 검증셋 평가점수를 비교해 가면서, 얼마나 훈련셋을 모델에게 더 훈련시켜야 할지를 결정하게 돼.
• 이렇게 Overfitting과 Underfitting의 중간에 모델이 훈련셋을 학습하는 최적의 횟수를 결정하는 것이 모델 학습 계획 수립에 있어서 굉장히 중요해

  5. 검증셋 만들 때의 장점

• train만 가지고 열심히 무작위로 공부해도 실력은 오르겠지만
• 미리 검증(val(validation dataset))을 한번 해가면서 학습을 하면 데이터에 기반한 정확한 분석을 통해 체계적으로 학습하여 효과적으로 실력을 올릴 수 있어
• 데이터에서 취조하면 다 나온다는 말이 있데. 데이터를 요리잡고 조리잡고 돌리고 고문하면 문제를 풀 수 있는 통찰력이 나온다는 말이래.
• 그런데 이 모델이 잘 성장(훈련)되었는지 아닌지 알려면 이 모델을 평가를 해야 하잖아? 그런데 test셋은 실제 평가라 정답이나 시험 분석데이터를 받을 수가 없으니, 궁여지책으로 가지고 있던 예를 들면 100문제 중에 20문제를 소중히 따로 꿍쳐놓고 보지 않고 있다가 미리 풀어보고, 정답(사전)과 비교해 보고 모델을 개선시킬 실마리를 찾을 수 있지.

  6. 검증셋 만들 때 고려할 점은?

• 모델을 만드는 최종 목표가 평가셋(test set)에서 잘 하는 모델을 만드는 것이지?
• 하지만, 평가셋은 라벨이 없어서 모델 평가 및 개선작업을 못하니까 검증셋을 만드는 거거든.
• 그래서 검증셋을 만들 때 가장 중요한 점은, 먼저 평가셋을 살펴보고 시험셋과 동일한 데이터 속성을 가지도록 검증셋을 만들어야 해
• 가능하면 시험셋을 평가할 때 사용되는 평가방법도, 검증셋 시험할 때 동일하게 사용하면 좋아
• 단 검증셋과 평가셋이 다른 점은 평가셋은 정답이 없다고 한다면, 검증셋은 내가 기대하는 정답값을 갖고 있는 거야.
• 그래서 검증셋과 평가셋을 동일하게 만들었다면, 이제 이 검증셋과 시험셋을 잘 풀 수 있는 모델을 훈련시키기 위해서 훈련 데이터셋을 역시 검증셋과 시험셋 문제와 동일하게 만들어주는 거야. 그리고 검증셋과 평가셋에서 모델이 만들어주었으면 하는 수준의 결과물, 즉 정답(혹은 y값, 라벨)을 훈련셋에 함께 만들어주어서 이 모델이 검증셋과 평가셋 문제를 보았을 때 동일한 수준의 결과물을 만들어주도록 유도하는 거야.
• 다시 정리하면, 1) 최종목적지인 내가 풀어야 할 문제인 평가셋을 먼저 살펴보고, 2) 그걸 잘 할 수 있을지 측정하기 위해 검증셋과 정답을 준비하고, 3) 그 문제를 모델이 풀 수 있도록 훈련시키기 위해 훈련셋과 정답을 준비하는 거야.

  7. 검증셋 없이 평가셋으로 바로 테스트해도 되잖아?

• 경진대회 같은 특수한 상황만 보면 그렇게 생각할 수 있어
• 경진대회 같은 일반적이지 않은 상황에서는 평가(test)셋에 대한 레이블이 있고, 그 레이블을 참가자 입장에서 볼 수는 없지만 리더보드에 제출하면 점수를 알 수 있지
• 하지만 몇 가지 아쉬운 점이 있어

1. 에러분석 못함
   • 리더보드 제출을 하면 총점을 알 수 있지만, 세부내역에 대한 채점결과는 알지 못해. 예를 들어 내가 어느 부분에서 틀렸는지, 틀린 부분의 패턴은 어떠한지, 틀린 부분만 집중적으로 재교육하려면 어떻게 모델링을 설계해야 할지
2. 최적의 하이퍼파라미터를 추출할 수 없어.
   • 하이퍼파라미터는 epoch, batch size, learning rate 등 실험을 어떻게 할 것인지 정할 때 쓰는 변수들이야. 어떤 값을 써야 최적의 모델이 탄생할 것인지에 영향을 주지.
   • 1부터 100까지라고 하면, 변수가 3개면 100 X 100 X 100번 1,000,000 번의 실험이 필요해.
   • 평가셋 점수를 아무리 리더보드에 제출해서 알 수 있다고 하고 하루에 12번씩 (Upstage AI Lab 기준) 할 수 있다고 해도 충분하지가 않다. 이걸로만 하려면 정말 주먹구구식으로 할 수 밖에 없고, 체계적이고 과학적인 최적의 하이퍼파라미터 값을 추출할 수가 없는 거지.
   • 훈련셋에 대한 성능측정은 정확하지 않아. 이미 본 데이터를 가지고 추론하는 거니까.
   • 그래서 결국 모델이 제대로 잘하고 있나를 보려고 하면 데이터 누수(Data Leakage: 모델이 보지 말아야 할 데이터가 모델에게 노출되어 검증의 유효성이 훼손된 경우)된 훈련셋 제외하고, 확인(제출)횟수가 제한되어있는 평가셋 제외하고는 검증셋만 쓸 수 있는 거지.

8. 어떻게 나누는거지? 손으로 하는 거야?

• 사이킷런(Scikit Learn, sklearn)이라는 라이브러리(library, 미리 만들어 놓은 파이썬 함수 묶음)를 사용하면 저절로 알아서 나눠줘.

• hold-out(따로 떼어두기) 방식은 1회만 validation 검증셋을 따로 떼어놓는 건데 그러면 특정 데이터의 패턴에 대해서만 검증이 되지? 그래서 cross validation(교차검증)은 여러번 validation 검증셋을 떼어놓아서 모든 훈련데이터의 부분에 대해서 다 검증을 하는 거야. 데이터 양이 많으면 그냥 hold-out 방식으로 하기도 하고 데이터가 적거나 편향을 줄이고 싶을 때는 cross-validation을 쓴데. 그래서 여러 시나리오에 대해서 모델을 훈련시키니 훈련시간은 더 오래걸리는 건 감안해야겠지?

  hold-out 방식 (따로 떼어두기) (검증셋을 한번만 분류)

1. train_test_split 라이브러리

   from sklearn.model_selection import train_test_split as tts
   X_train, X_test, y_train, y_test = tts
   (*arrays, test_size=None, train_size=None,
   random_state=None, shuffle=True, stratify=None)

• shuffle은 섞는 다는 건데 default는 True지만 False로 하면 섞지 않는다는 거야
• random_state은 섞을 때 섞는 방식을 결정하는 기계에 어떤 방식으로 섞을지를 결정하는 숫자를 넣는거야 (예:42). 똑같은 숫자를 넣으면 똑같은 결과가 나오겠지? 예: Shuffle=True, random_state=42.
• 그런데 Shuffle=False로 하면 아예 섞지를 않으니 random_state값은 의미가 없으니 쓸 필요가 없어.
• stratify=y로 하면 종류별로 공평하게 나누는 거야. 예를 들어 고양이와 개 사진이 각각 50장씩 합해서 100장이 있는데, 이걸 8:2로 나누는데 고양이 50+ 개30을 80으로 나누고, 나머지 20장을 개 사진으로만 남기면, 고양이에 대해서는 모델이 잘하는지 못하는지 성능평가가 안 되겠지? 그래서 stratify를 적용하면 개 25장, 고양이 25장을 훈련셋으로, 나머지 50장을 검증셋으로 비율을 균등하게 나누는 거야.

cross-validation 방식 (교차검증) (여러번 나누어서 모든 데이터에 대해서 검증셋으로 적용하기)

1. KFold 라이브러리

   from sklear.model_selection import KFold
   KFold(n_splits=2, random_state=None, shuffle=False)

• 한 데이터를 K개로 나누는 거야. 예를 들어 100개의 데이터를 5(여기서는 K)개로 나눈다면 20, 20, 20, 20, 20개로 나누는 거야. 그리고 다섯개가 번갈아가면서 한 번씩 검증셋 역할을 하는 거고, 나머지 4개의 20개씩 데이터로 훈련(학습)을 하는 거지.

문제는 GPU 리눅스 서버는 / Windows는 \, 또 리눅스 서버는 /부터 시작하는데 Windows 서버는 C:\ 부터

그래서 Windows에서 작업하다가 Linux넘어가면 경로를 수정하는 절차가 필요했다

그런데 가만히 보니 git clone 한거 하위경로는 다 똑같았고, 그 외 깃에 안 올린 폴더가 있었는데 그거는 리눅스와 윈도우즈 모두 git 폴더와 동일 계층에 있었다.

그래서 현재 작업위치 기준으로 git 폴더를 찾아내서, Linux와 Windows에서 위치 수정 하지 않도록 바꿔보았다.

Linux("/")와 Windows("") 경로표시 방식 차이는 from pathlib import Path의 Path 라이브러리를 쓰면 자동 변환해준다.

Windows 작업 위치 C:\Code_test\CV\upstageailab-cv-classification-cv_c5\Daun\dev_py\dev_valid\win_baseline-test_valid2.py

Linux 작업 위치 /cv/upstageailab-cv-classification-cv_c5/Daun/dev_py/dev_valid/win_baseline-test_valid2.py

CV폴더 부터는 동일한데 그 위가 달라서,

script_path = Path(__file__).resolve() 현재 파이썬 파일의 경로를 가져온다 working_directory = script_path.parents[4] 0부터 시작해서 4까지, 5단계 위의 폴더 경로를 저장한다

실제 소스

# 현재 스크립트 파일의 경로
script_path = Path(__file__).resolve()
working_directory = script_path.parents[4]
print(working_directory)
trn_origin_csv = Path(fr"{working_directory}/data/train_v0.7.csv")
print(trn_origin_csv)
trn_origin_csv_read = pd.read_csv(trn_origin_csv)
trn_data = Path(fr"{working_directory}\train")

trn_csv_path = Path(fr"{working_directory}\data\trn.csv")
print(trn_csv_path)
# trn_csv = pd.read_csv(trn_csv_path)

val_csv_path = Path(fr"{working_directory}\data\trn.csv")
print(val_csv_path)

아래는 FiftyOne 엔지니어가 가르쳐준 윈도우와 리눅스 경로 변환 방법

from pathlib import Path

def normalize_path(path_string):
    return str(Path(path_string))

result = normalize_path("C:/Users/Documents/file.txt")
print(type(result))  # This will output: <class 'str'>
print(result)

결과 <class 'str'> C:\Users\Documents\file.txt /이 \로 바뀌어져 있었다.

잘 돌아가던 소스가 갑자기 안 돌아가서 여러가지 권장사항들(배치사이즈 줄이기 등) 찾아보다가 잘 안 되서 현재 램 사용량 찍어보고 nvidia-smi 점유된게 상당한 걸 보고, .py로만 작업하다가, 최근에 동료분이 주신 .ipynb를 작업했던 기억이 나서 GPT에게 문의해서 하란데로 했더니 바로 돌아감

"ipynb (kernel) restart 하라"

GPT께 질문

.py랑 .ipynb에서 번갈아가면서 GPU heavy한 코드 돌리면 .py만 했을 때보다 GPU가 더 점유되니?

ChatGPT의 말씀:

ChatGPT .py와 .ipynb 파일에서 GPU를 사용하는 Heavy 코드(예: 딥러닝 모델 학습)를 번갈아 실행할 경우, GPU 점유율은 더 높아질 수 있습니다. 이는 두 환경이 GPU 메모리와 리소스를 사용하는 방식의 차이 및 리소스 관리 때문입니다. 아래에서 이유와 상황별 차이를 설명하겠습니다.

1. .py와 .ipynb의 GPU 메모리 관리 차이 .py (스크립트 실행): .py 파일은 일반적으로 실행 후 종료되면 GPU 메모리를 해제합니다. 따라서, 실행이 끝나면 GPU 메모리 점유는 대부분 사라집니다. .ipynb (Jupyter Notebook 실행): Jupyter Notebook은 실행 중인 커널(kernel)을 유지합니다. 코드 셀이 실행을 멈춰도 커널이 살아 있는 동안 GPU 메모리 점유가 계속 유지됩니다. 특히, 딥러닝 프레임워크(PyTorch, TensorFlow 등)에서 초기화된 모델, Optimizer, 데이터 로더 등이 GPU 메모리를 점유한 채 남아 있을 수 있습니다. 결과적으로 .ipynb에서 실행 후 커널을 재시작하지 않고 .py를 실행하면, .ipynb에서 점유된 GPU 메모리가 해제되지 않아 GPU 메모리 사용량이 더 많아질 가능성이 큽니다.

2. 동시에 두 환경에서 실행하면? .py와 .ipynb가 동시에 GPU를 사용할 경우, 각 환경이 점유하는 GPU 메모리가 합산됩니다. 특히, Jupyter Notebook에서 점유한 메모리가 해제되지 않은 상태에서 .py 스크립트를 실행하면, 잔여 메모리가 적어지고 OutOfMemory 에러가 발생할 가능성이 커집니다.

3. GPU 메모리 점유 패턴 .py 실행만 하는 경우:

실행 후 종료되면 메모리를 대부분 반환합니다. 단, 일부 딥러닝 프레임워크(PyTorch, TensorFlow)가 캐시 메모리를 점유할 수 있습니다. .ipynb에서 실행하는 경우:

Jupyter 커널이 GPU 메모리를 지속적으로 점유합니다. 코드 실행 중단 또는 셀 정지가 메모리 해제를 보장하지 않습니다. 4. 해결 방안 (1) Jupyter Notebook에서 메모리 점유 해제 Jupyter Notebook에서 실행 후 메모리를 해제하려면, 다음을 활용하세요:

torch.cuda.empty_cache():

PyTorch를 사용 중이라면, GPU 메모리 캐시를 비웁니다. python 코드 복사 import torch torch.cuda.empty_cache() Jupyter 커널 재시작:

커널을 재시작하면 GPU 메모리가 완전히 해제됩니다. 코드 복사 Kernel > Restart Kernel (2) 두 환경을 번갈아 사용하는 경우 .py와 .ipynb 환경에서 GPU 메모리 충돌을 피하려면, 다음을 권장합니다: .ipynb에서 GPU 메모리 점유가 끝난 뒤, 반드시 커널을 재시작하거나 명시적으로 메모리를 비웁니다. .py 실행 시 Python 프로세스를 종료하면 GPU 메모리를 자동으로 해제합니다. 결론 .py와 .ipynb를 번갈아 실행하면, .ipynb의 Jupyter 커널이 GPU 메모리를 해제하지 않아 전체 점유량이 늘어날 가능성이 있습니다. 따라서, .ipynb 사용 후 커널을 재시작하거나 .py 실행 전에 GPU 메모리를 명시적으로 정리해야 안정적으로 사용할 수 있습니다.