업스테이지 NLP 요약 경진대회 회고

팀 깃헙 링크

• 나는 내 학습목표를 달성하기 위해 무엇을 어떻게 했는가?
  • 전부터 궁금했었던 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. 그 외 느낀 점
   • 모델선택, 하이퍼파라미터튜닝, 보다 제일 중요한 게 모델이 생각하는 방식, 즉 가중치와 편차, 다시 말해서 모델의 파라미터를 조절하는 것이다. 이것은 모델이 주어진 데이터를 가지고 경사하강법을 통해 스스로 조절한다. 개발자는 모델에게 어떤 데이터를 줄지를 결정하면 모델의 파라미터를 간접 조정할 수 있다.