Final 기업 연계 프로젝트
프로젝트 진행 기간 (01월 13일 - 02월 07일)
프로젝트 주제
주제 : 숫자 텍스트 변환 (Text - Normalization)
목표 :
숫자가 포함된 텍스트를 한글로 바꾸기 (For TTS)
학습과 평가시 사용한 데이터
- https://aihub.or.kr/aihubdata/data/view.do?currMenu=115&topMenu=100&aihubDataSe=data&dataSetSn=484
팀 개발 문화
팀장으로 프로젝트를 진행했다.
팀원 수는 총 3명이었다. (원래 한 분 더 계셨었는데 어떤 이유인지는 몰라도... bye bye)
이번 프로젝트에도 어김없이 휴일이 함께 있었는데... (쉬지 않았다... 악덕 팀장 ...?)
1월 13일 - 17일 : 프로젝트 기획안 및 팀 개발 일정 조율
1월 20일 - 2월 4일 : 주 개발 진행
- 1월 20일 - 25일 : baseline code 생성 | 24일 기업 미팅 진행
- 1월 27일 - 2월 4일 : 모델 고도화, 여러 실험 진행 | 31일 기업 미팅 진행
2월 5일 - 6일 : 최종 마무리
2월 7일 : 최종 발표 진행
진행 과정
Raw data
scriptID : 각 데이터의 고유한 아이디
scriptITN : 숫자와 한글이 같이 있는 원본 문장
scriptTN : 숫자를 문맥에 맞춰서 변환한 문장
scriptNumberWord : 바꿔야 하는 단어
patternTheme : 바뀌는 단어의 테마
접근 방식
데이터를 보고 든 생각은 '숫자를 글자로 바꿔야 하는 일부분을 바꾸면 어떨까...?'라는 생각이었다.
그렇게 코드를 설계를 시작했다. 하지만 시작한지 얼마 되지 않아 알게된 사실은 절망적이었다...🥲🥲🥲
프로젝트를 시작하며 기업과 소통을 할 때 기업측에서는 Rule-base 코딩으로 해당 작업을 진행하고 있다고 들었다.
즉, 발생가능한 모든 case를 예측하고 그거에 맞춰서 변환을 시도하는 것이다.
그런데 이렇게 하면 발생하는 문제는 모든 case를 예측할 수 없고, 예측을 시도한다고 해도 시간이 많이 걸리고,
예측이 되는 case중에서는 문맥에 따라 변환 규칙이 달라지는 것이 있어서
Rule-base 접근 방식으로 해당 방법을 해결하는 것이 어려웠다고 전달받았다.
이 사실을 알고 일부 부분만 AI모델을 이용해서 변환하는 것을 시도했는데
기업측에서 사전에 시도했던 Rule-base 방법과 비슷한 문제들이 발생했다.
훈련을 시킬때 AI가 어떤 상황인지 이해할 수 있도록 태깅을 해야 하는데 여기서 문제가 발생했다.
테깅을 직접하는 것은 기존 회사에서 진행했던 Rule-base 방법과 큰 차이가 없었다.
그래서 좀 고민하다가 '문장 일부 변환하는 방법을 포기하면 어떨까?'라는 생각이 들었다.
다른말로, 문장 전체 생성 방식으로 개발 방향성을 선회한다는 의미였다.
이렇게되면 목표는 변환되지 말아야 할 부분은 그대로 유지하고 변환이 되어야 할 부분은 변환을 잘 시키는 것이 목적이 된다.
여기서 문제가 하나 더 생겼다.
보통 AI를 학습할 때는 목적함수가 필요하다.
다른 말로도 손실함수가 필요한데 손실함수는 특정 TASK마다 특화가 되어 있는 것을 가져와서 쓰는 것이 보통이다.
근데 이번 Text Normalization에 적합한 손실함수는 이리저리 찾아봐도 쓸만한게 없었다.
그래서 손실함수를 직접 개발했다.
모델이 학습할 때 쓰는 것 하나랑 사람이 평가할 수 있는 지표를 만들었다.
모델이 학습할 때는 보통 loss 값을 사용하는데 이 숫자가 직관적이지 않아서
loss값이 특정값 이상 작아지면 잘 학습이 진행되고 있는지 파악하기가 어렵다.
아래 사진과 같은 구조다.
여기에서 사용한 평가지표는 다른 곳에서 보편적으로 적용이 될 수 있을지는 모르겠다.
기업측에서 모델 학습을 위해 제공한 학습 데이터 셋에 특화된 평가지표다. 그걸 참고하고 글을 보면 좋겠다.
Bracket Accuracy : 대괄호 안의 숫자 변환 정확도 (변환이 필요한 부분)
Text Preservation : 대괄호 외 텍스트 보존 정확도 (변환되면 안되는 부분)
- 평가 지표 생성 뒷 이야기
- 모델이 사용하는 loss function에서 평균을 내는 방식이 아니라 변환되지 말아야 할 부분이 변환된 경우 가중치값을 크게 줘서(곱하기 방식) 모델 학습을 도우려고 했다. 여기에서 NCE Loss를 추천받기도 했는데 실험을 몇번 진행해보니 성능이 떨어졌다. 성능을 높이려면 변인 통제하고 실험을 많이 진행해봐야 하는데 epoch 5 기준으로 학습하는데 15-18시간이 걸렸다. NCE Loss를 추천받은 때는 대회 마감 일주일을 앞둔 상황이라 무리하게 모험을 할 수는 없어서 이 방법은 깔끔하게 포기하고 위 방식을 선택했다.
모델 선정
처음에는 문장의 일부분만 다시 생성하는 방법을 고민했기 때문에 BERT를 이용하려고 했다.
하지만 개발 방향성을 바꾸면서 문장의 생성을 빈칸 채우기 수준이 아니라 한 문장 전체를 생성해야 했기 때문에
encoder - decoder 모델과 decoder only모델 중에서 어떤 것을 사용할지 고민했다.
또한 text normalization은 문맥 이해도 중요하다고 생각이 되어서 encoder - decoder 모델을 먼저 선택하고 실험했다.
이전에 BERT를 사용했으니 자연스럽게 BART로 넘어가서 실험을 진행했다. 첫 성능이 나쁘지 않게 나왔다.
(gogamza/kobart-base-v2로 실험을 진행했다)
bracket_accuracy : 0.856 정도 나오고 text_perservation : 0.96 정도 나왔다.
bracket_accuracy가 상대적으로 적게 나왔다.
그래서 다른 모델을 탐색하다가 '다국어 모델로 실험하면 어떨까?'라는 생각을 했다.
다국어 모델이 encoder로 A언어를 이해하고 그 문맥에 맞춰서 B언어로 문장을 번역하는 과정이 이번 TASK와 비슷해보였다.
facebook/mbart-large-50모델을 사용해서 실험을 진행했다.
bracket_accuracy : 0.796 정도 나오고 text_perservation : 0.818 정도 나왔다.
이 실험은 epoch을 5까지 돌리지 않았다. 3정도까지 돌리다가 성능이 처음 baseline보다 낮아서 중단하고 다른 실험을 진행했다.
오히려 다국어 모델이 여러 언어에 대해 가지고 있는 임베딩이 같은 언어로 변환을 해야하는 이번 TASK에서는 방해가 되는 듯 했다.
그리고 gogamza모델에 대해 조금더 조사해보니까 한국어 특화 fine-tuning 모델이었다.
BART계열 모델 말고 다른 모델도 실험해보면 좋을 것 같아서 한국어 특화 fine-tuning 모델을 찾다가 paust/pko-t5-large을 찾았다.
bracket_accuracy : 0.89 정도 나오고 text_perservation : 0.968 정도 나왔다.
지금까지 시도해본 모델중에서 기본 성능이 메우 좋아서 최종적으로는 paust/pko-t5-large 모델을 선택했다.
전처리
이미지 관련 실험도 그렇고 NLP관련 실험 모두 모델의 성능이 떨어지면 성능을 높이기 위한 가장 좋은 방법이 눈으로 보는거다.
오류가 난 부분을 눈으로보고 고치기가 ㄹㅇ 다른 것보다 성능 향상이 좋다.
(투박하지만 좋구만...)
이번에 모델 성능이 올라가도 bracket_accuracy 결과가 text_perservation보다 항상 낮게 나와서 오류가 어디서 발생하는지 파악했다.
주로 오류가 발생하는 포인트가 전화번호, 차량 번호, 도로 주소명 이런 곳에서 오류가 발생했다.
사람들이 전화번호를 말할 때 01012344321을 [공 일 공 일 이 삼 사 사 삼 이 일] 이렇게 말하기도 하지만
누구는 [공 일 공 하나 둘 삼 사 사 삼 둘 하나] 이렇게 말할 수도 있다.
간단하게 말하면 우리가 발화할 때 전화번호, 차량 번호, 도로 주소명 이런 것들은 부를 때
고유어, 한자어 변환에 대한 일반적인 규칙을 찾아보기가 어려운 경우가 많다.
이런 case들에 대해서 변환 오류가 발생이 되어서 이런 것들을 일관성 있게 데이터를 고쳐주시 성능이 올라갔다.
bracket_accuracy : 0.968 정도 나오고 text_perservation : 0.969 정도 나왔다.
증강
최종 결과
bracket_accuracy : 0.971 정도 나오고 text_perservation : 0.969
프로젝트를 진행하며 얻은 인사이트
우리 팀과 같은 프로젝트를 진행한 다른 팀이 있다.
이 팀은 decoder 기반의 대형 LLM을 끌고 와서 이번 TASK를 수행했다.
API를 받아와서 진행하기도하고 7B크기의 모델을 가져와서 LoRA를 이용해서
3090에서 실행하기 쉽지 않은 모델을 가져와서 실험을 진행했다.
우리팀 모델 paust/pko-t5-large 크기는 820M
결과물은 우리팀과 비슷하거나 우리팀이 더 좋았다.
같은 결과물을 생성하는데 사용하는 모델 크기가 적다면 그건 효율성이 더 좋다는 거니까 베뤼굿!
왜 그럴까 나름대로 이유를 분석해봤는데 이번 TASK는 문맥 이해가 핵심이어서
decoder - only 모델보다 encoder - decoder 모델이 더 좋다고 생각했다.
상대 팀이 사용한 모델들은 decoder - only 모델이었고,
우리 팀에서 다른 한 분은 다양한 모델로 실험을 해보셨는데 주로 decoder모델로 실험을 해보셨다.
하지만 paust/pko-t5-large모델의 성능을 뛰어넘지는 못했다. (증강, 전처리 적용X 기준)
그래서 프로젝트가 끝나고 용담 강사님께 피드벡 받을 때 encoder - decoder 모델이라서 성능이 더 좋은 것 같다고 말씀드렸는데
그렇다고 보기에는 아직 무리가 있고 운이 좋았다고 말씀해주셨다.
설계한 Loss function, 그에 맞는 모델을 잘 찾은거라고 하셨다.
또 데이터 전처리 관련 피드벡도 받았는데 전화번호를 일관되게
전처리하면 Text Normalization이라는 목적에는 부합할지 모르나
STT/TTS 서비스에 적용될 것을 확장해서 생각해보면 실제 환경이랑 조금 떨어진 측면도 있다고 하셨다.
기업연계 프로젝트를 마무리하며 (feat. 석사 디펜스)
프로젝트를 마무리하며 발표를 마치고 강사님께 피드벡을 받고 궁금한 것은 질문하고 강사님이 제시한 의견에 반론을 제기하고,
다시 피드벡 받고 그런 과정을 진행했다.
다 마치고 나서 석사 디펜스 체험하셨다고 말씀해주셨다.
생각보다 재미있었다.
이번 기업연계 프로젝트 진행이 전반적으로 재미있었던 것도 있고 그런 내용가지고 서로 토론하고 이야기하는게 재미있었다.
특히 평가 지표를 설계하고 실험해보고 그런 과정이 재미가 있었던 것 같다.
개발하는 과정에서 클로드 프로젝트 기능 도움을 정말 많이 받았다.
아직 코딩 실력은 많이 부족하다.
그런데 앞으로 인공지능의 코딩 실력은 날이 갈 수록 빠르게 발전하고,
사람이 학습하는 속도에 비해서 인공지능 발전 속도가 압도적으로 빠른데
나중에 가면 결국 코딩만하는 기술자는 AI에 밀려서 없어질 것 같다는 생각을 한다.
지금 알기로는 AI가 코딩에 있어서 약한 부분이 대규모 트레픽을 처리하는
엔지니어링 기술을 구현하는 것에 있어서 약하다는 것으로 알고 있는데
이것도 정복되는데 시간 문제이지 않을까 싶다.
다른 말로하면 코딩 기술자의 종말의 시대가 찾아온다는 말이다.
대신 앞으로는 인공지능과 대화를 주고 받으며 코딩을 더 효율적으로 하는 사람들의 퍼포먼스가 더 뛰어나지 않을까 싶다.
그리고 그런 퍼포먼스를 통해 어떤 컨텐츠를 가지고 사람들에게 다가갈까 고민하는게 내가 지금 있는 곳의 미래 방향성이지 않나 싶다.
한 줄로 정리하면, 코드 깎는 노인은 도태된다... 코드를 들고 예술을 하는 사람이 살아남는다...
(뭐가 되었든 코딩을 할 줄 알면 이득)
잠깐 다른 이야기 해봤고, 기업과 같이 프로젝트하면서 느낀건 회사와 협업하는 문화를 배울 수 있어서 좋았다.
우리 팀이 이해하고 있는 것과 회사가 바라는 것은 다르다.
주기적인 미팅을 통해 그것을 확인하고 바른 방향성을 향해 가는 것이 재미있었고
새로운 평가 지표를 만들고, 그 환경안에서 실험해보는 것은 더더욱 재미있었다.
(컴퓨터 환경이 더 좋아서 짧은 시간안에 실험을 돌릴 수 있었더라면 얼마다 더 좋았을까... 한 번 실험에 15-18시간🥲)
부트 캠프를 마무리하며
정말 좋은 경험이었다.
앞으로 무엇을 할지는 잘 모르겠지만 확실한 것은 25년은 어떻게 살아야 할지 알겠다는 것이고,
25년 열심히 살고 이후에 고민해보자!
그리고 개인적으로 바람은 논문도 써보고 싶다.
AI 분야 특성상 실험할 수 있는 컴퓨터 있으면 내가 이리저리 실험해보고
좋은 인사이트가 나오면 논문 형식으로 공유해서 학계에 논문 등록이 되는 것 같던데
졸업하기 전에 논문 써보고 싶다는 생각도 한다.
그럴려면 좋은 그래픽 카드 사서 허깅페이스에 있는 용량이 큰 모델들 로컬에서 돌려볼 수 있는 컴퓨팅 파워정도를 확보를 해야 하지 않을까..! 열심히 살자.
이걸로 부트캠프를 마무리한다.