어제 Ko-Llama3로 노이즈 데이터 필터링을 시도했다가 실패했다. 답변 컨트롤이 너무 어려웠다. 낮은 정확도는 덤. seed랑 temperature를 컨트롤할 생각 조차 하지 못했다. 항상 균일한 동작! 우연에 기대지 말자.
그와 별개로 오늘은 다른 팀원들이 한 노이즈 필터를 기반으로 클러스터링을 했다. 데이터는 총 2800개인데, 노이즈 낀 텍스트 1600개, 잘못 라벨링된 데이터 1000개, 정상 데이터 200개이다. 노이즈 낀 텍스트는 잘 걸러지고 있어서 라벨링 오류를 바로잡는 작업에 들어갔다.
sparse embedding + PCA + K-Means/DBSCAN을 사용해 클래식한 방법으로 우선 접근했다. sparse의 경우 TF-IDF와 BM25를 사용했다. 임베딩 벡터 차원이 너무 커져 PCA로 차원을 축소했다. 그리고 K-Means와 DBSCAN을 사용했는데, 정확도가 너무 낮았다. 처음에는 1020개를 잡았다고 해서 좋았는데, 막상 데이터를 까보니깐 맞게 라벨링된 데이터가 하나도 없었다...
생각해보면 당연한 이야기였다. scatter plot을 그려보니 데이터가 무작위로 흩뿌려저 있었고, 파라미터를 바꿔가면서 열심히 조종했지만 역부족이었다. 물론 의미 없는 시도는 없지만, 시간 낭비라는 생각은 지울 수 없다.
클러스터링 결과가 안 좋아서 우선 다른 작업에 들어갔다. 노이즈 필터링이 성공적으로 작동했기 때문에 이를 모듈화해 사용하기 좋도록 포장했다. 현재 프로젝트는 주피터 노트북으로 진행하고 있다. 주피터 노트북은 쓰면 쓸 수록 단점이 명확한데, 우선 코드 리뷰가 어렵고(깃허브는 주피터 노트북 UI 좀 고쳐줬으면 좋겠다.), 코드가 꼬일 가능성이 매우 높다. 그럼에도 주피터 노트북으로 프로젝트를 진행하는 이유는 데이터 시각화가 용이하기 때문이다.
나는 다른 팀원의 코드에서 시각화를 전부 걷어내고 동작 중심으로 모듈을 새로 만들었다. 주피터 노트북을 .py로 뽑아내고 GPT에게 리팩토링을 맡겼다. 코드를 살펴보니 생략된 동작이 너무 많았다. SOLID 원칙에 맞게 캡슐화하라고 했지만, 너무 많은 것을 분리한 듯 싶다.
우선 1차적으로 모듈화를 끝내고 실험 결과를 정리했다. 주피터 노트북의 또 다른 장점으로 문서와 코드가 혼재돼 있다는 점이 있다. 코드 실행 결과를 간략하게 정리하기 좋다. 다시 곱씹어보니 내가 아예 잘못 생각하고 있다는 걸 깨달았다. 텍스트가 짧지만, 이를 판별하는 로직은 엄청 복잡할 것인데 왜 Sparse와 ML 기반 클러스터링을 사용했지? 업무에 너무 매몰되면 안 되겠다고 또 느꼈다. 왜 이걸 하는지 매번 생각하면서 진행하는 건 어렵다.
다른 팀원의 노이즈 필터 모듈화를 1차적으로 끝냈다. 코드 리뷰를 부탁했는데, 우리 팀이 활발하게 코드 리뷰가 진행됐으면 좋겠다! 다음 팀에서는 어떻게 코드 리뷰 중심의 문화를 만들까?