Problems
- 체크포인트를 만들고 그걸 불러와서 다른 데이터를 파인튜닝 시킨다고 해서 성능이 잘 나오는 건 아니었다. 체크포인트를 만들었으면 그를 맞게 사용하기 위해 여러 조작을 했어야 했는데, 마치 체크포인트가 능사인 듯 이를 사용했다. 이건 내가 제대로 알지 못했고, 어줍잖게 알면서 적용해보고 찾아보지 않은 나의 잘못이 맞다.
- 데이터가 부족했는데 그걸 120 으로 절삭해서 사용하면서도, 120 토큰 이후의 텍스트를 사용 할 생각을 안 했다. 데이터 증강을 ner에서 어떻게 적용해야 하는지, 역translation 을 많이 사용한다고 했지만서도, 다른 방법이 있었다.
- 내가 스스로 해보려고 계속 붙잡고 있다가 시간이 지체됐다. 일찍 물어봤어야 했다. 난 후배들한테 모르면 물어보라고 염불을 외는데, 정작 나는 물어보질 않았다.
알게된 점
- 성능 비교할 게 아니라면 체크포인트로 불러와서 단계 별 데이터를 학습시키기 보다는 그냥 짬뽕쓰까 해서 해보는 게 더 잘 나온다고 한다. probs 1.과 이어지는 말이긴 한데, 이건 좀 더 찾아보아야겠다.
- 문제 해결을 위한 관점은 어떻게 키워야 하는가? 졸업생 선배님이랑 코드 리뷰 했을 때, 교수님이 내가 만든 코드를 다른 방식으로 풀었을 때 느꼈다.
내가 짠 코드가 일부 데이터에서 한 글자씩 밀리는 버그가 있었는데, 원인을 못 찾겠어서 교수님께 도와달라고 요청드렸다.
교수님도 원인은 못찾으셨는데 나랑 다른 방식으로 진행하셨다.
나는 정규표현식 finditer 로 원하는 글자와 인덱스를 뽑고 그걸 원문에서 해당 인덱스로 찾게끔 짰는데, 교수님께서는 인덱싱을 좀 널널히 하고 그 안에서 매칭시켜 찾으셨다.
사실 결과만 놓고 보면 별 거 아니다. 근데 중요한 건 이 아이디어를 얼마나 빨리 생각했냐는 것, 그리고 그걸 코드로 빠르게 구현했다는 거다.
생각을 코드로 구현하는 건 개발자에게 있어 필수 덕목인데, 그 생각이 기존 문제를 크게 변경하지 않고 작은 아이디어 하나로 바로 적용가능 하게 만들 수 있는 능력이 더 중요한 덕목이라 느낀다.
그러니까... 예를 들자면
어떤 공장에서 상자 안에 물건을 넣는 공정이 있는데, 가끔 빈 상자가 나올 때가 있다고 한다. 이때 빈 상자를 골라내는 방법이 뭐가있을까? 상자의 무게를 잴 수도 있겠지만 컨베이어 벨트에 당장 적용하기는 힘들다.
이럴 때 그냥 강풍기를 틀면 된다. 그럼 빈 상자는 날아간다.
나는 내 코드에 저울을 설치하면 된다고 생각했지만, 강풍기를 생각하는 사람이 됐으면 좋겠다... 이말이지
따봉 박고갑니다