10:00 ~ 13:00

오늘 19:00가 리더보드 마감일이지만, 모델 학습이 20시간 넘게 걸리기 때문에 할 수 있는게 별로 없었다. 우선 프로젝트를 진행하면서 쌓아온 실험과 문제 해결 과정을 정리하기로 했다. 나는 주피터 노트북으로 실험을 진행했는데, 실험 결과와 발전 과정은 노션에 기록했다.

실험 기록

실험 모듈 파이프라인 설계

13:00 ~ 16:00

모델 학습이 드디어 끝났다. 다같이 제출 결과를 공유하면서 이야기를 나눴다. 생각보다 프롬프트 적용한 모델이 성능이 나오지 않았다. validation과 실제 리더보드 accuracy가 많이 차이가 났다. 어떻게하면 더 유효한 검증을 할 수 있었을까?

실험 모듈화는 생각보다 복잡했다. 위 기록처럼 실험 내용이 많기도 했고, 주피터 노트북으로 작성되었기 때문이었다. 실험 파일 별로 코드 중복이 매우 많았는데 이를 어떻게 재사용성을 높이면서 모듈화할지 고민을 많이했다. 그 결과, BaseProcessor를 추상 클래스로 만들어 각 실험 모듈에게 상속받게 한 뒤, 세부 파라미터를 설정하는 방식으로 진행하기로 했다. 현재 내 청사진은 다음과 같다.

# 위 모듈화 계획의 pseudo code
reasoning = Reasoning()
reasoning_result = reasoning.process()

classifying = Classifying(reasoning_result)
classifying_result = classifying.process()

keyword_extracting = KeywordExtracting(classifying_result)
keyword_extracting_result = keyword_extracting.process()

summarizing = Summarizing(keyword_extracting_result)
summarizing_result = summarizing.process()

paragraph_merging = ParagraphMerge(summarizing_result)
paragraph_merging_result = paragraph_merging.process()	# 증강 완료

langchain의 RunnableSeriable 객체처럼 reasoning | classifying | keyword_extracting | ...으로 묶고 싶다... 우선 깔끔한 코드도 좋지만, 저렇게 해놓고 생각해야 겠다.

피어세션 때는 앙상블 전략을 주로 이야기했다. 선다형 문제를 푸는 테스크였기 때문에 지금 회고를 작성하는 시점에는 앙상블이 의미 없게 느껴진다. 문제의 정답 여부를 투표로 정하기에는 상호 보완적이거나 압도적인 성능이 있어야 했는데, 둘 다 해당이 안 되기 때문이다. 그리고 최종 학습 결과가 좋지 않았다. 우선 제언을 미뤄두기로 하고, 어떤 결과를 취합할지 논의했다. 가장 성능이 좋은 결과 5개를 하드/소프트 보팅을 했는데, 제출 결과가 조금 올랐다.

멘토링을 했다. 첫 번째로 멘토님이 바라본 현재 상황을 간단하게 리뷰받았다. 우리 팀이 진행한 실험의 이론적 배경이 부실하다는 지적이 있었다. 뼈가 되는 조언이었다. 실제로 프롬프트 위주의 작업이었고, 프롬프트 엔지니어링 논문은 근본적인 원인을 규명하지 못하기 때문에 판단 근거가 되기 아쉽다고 말씀해주셨다.
두 번째로 OpenAI 정형원 박사님의 특강 내용을 공유해주셨다. Emergent Ability 논문 리뷰와 이를 바탕으로 한 인사이트였다. 멘토링 내용에 따르면, 점점 LLM이 해결하는 문제 종류는 많아지고, 현재도 이미 학습에 효율적인 구조가 완성됐기 때문에 사람 손이 가는 작업은 없어진다. 멘토님은 이렇게 말하셨다.

이 아이디어는 쓸모 없는 아이디어야. → 이 아이디어는 아직 동작하지 않는 아이디어야.

결국 LLM이 할 수 없는 일을 찾아야 한다. 멘토님은 on-premise 환경에서 작업이 LLM이 나설 수 없는 영역이라고 하셨다. 많은 기업에서 그 효율성 때문에 LLM을 도입한다. 하지만 보안도 그만큼 중요해진다. 이 상황에서 OpenAI API 호출을 사용할 수 있을까? 기업의 입장에서는 아무리 네트워크가 안전하다고 해도, 보안이 뚫린다면 손실이 어마어마하기 때문에 외부 API 호출로 동작하는 클라우드 기반 환경은 꺼려진다. 이를 다시 이야기한다면, 성능이 좀 낮더라도 회사 내부에서 사용할 수 있는 LLM 테스크가 더 전략적인 선택일 수 있다는 말이다. 제한된 리소스/모델 환경에서 추론 속도와 성능을 어떻게 끌어올릴 수 있는가, 데이터 정제와 정규화를 어떻게 하는가 등이 있다.
세번째로 질문 세션이었다. 프로젝트를 진행하면서 답답함을 많이 느껴 다들 질문이 많았다. 특히 RAG 관련 질문은 RAG에 보낼 쿼리를 평가하는 방법이었다. 이는 내 질문과 연결됐다. 내 질문은 다음과 같았다.

외부 지식을 끌어오기 위해서 reasoning 기반으로 위키피디아 검색용 키워드를 추출했습니다. 역설적으로 reasoning 과정에서 외부 지식이 필요했습니다. 멘토님께서는 이런 순환 논리 문제를 어떻게 접근하실지 궁금합니다.

데이터 증강 시에도 RAG를 도입할 것 같다고 하셨다. 정답보다는 키워드 뽑는게 쉬울 것 같다고도 하셨다. 나는 그래서 일반적인 키워드가 추출되는 경향이 있다고 말씀드렸고, 멘토님은 프롬프팅으로 해결해야 할 것 같다고 말씀하셨다. 프롬프팅을 열심히 했지만, 허술한 점이 있었나보다. 혹시나 이 글을 읽게 될 고수분의 답변을 기다리겠습니다. 이를 위해서 좀 더 내용을 구체화하겠습니다. 예시는 데이터 유출 금지 관련 규정 때문에 간략화한다는 점 양해 부탁드립니다.

상황 예시)
지문: 조선 시대 상소문
질문은 해당 상소문을 올린 인물의 해당 사항을 묻는 질문.
모델의 reasoning은 해당 인물 정보보다는 다소 빈약한 추론 결과를 보여줌. 서술형 채점에서 감점을 많이 당할 정도.
지문 + 문제 + reasoning으로 위키피디아 검색어 키워드 추출 시 조선, 상소 등 다소 범위가 넓은 키워드가 추출됨. 해당 문서를 paragraph 단위로 훑기가 애매한 상황(애초에 문서에 필요한 정보가 있는지도 불확실하므로)

16:00 ~ 19:00

본격적으로 앙상블을 했다. 나는 앙상블을 하더라도 그나마 촘촘한 근거에 기반해서 진행했으면 좋겠다고 생각했다. 다들 시간이 급하고, 앙상블은 다소 치팅에 가깝다보니 그렇게 생각하지는 않은 것처럼 보였다. 우선 제출 기회는 별로 없지만 시간이 충분하니 앙상블할 데이터에 사용된 pre-trained 모델을 찾아보기로 했다. Qwen, Llama, gemma, Solar 등 다양한 모델이 앙상블 대상이었다.
우선 Qwen이 제출 결과 성능이 제일 좋으니, Qwen에 높은 가중치를 주어서 앙상블을 진행했다. 제출 결과로 성능을 측정해 다시 제출하는 것은 내가 생각하기에 그다지 바람직한 모습이 아니라고 생각했다. 모델이 어떤 데이터셋으로 학습되고, 어떤 벤치마크에서 강점을 보이는지 분석하고 앙상블을 하고 싶었다. 간단하게 15분 정도 모델 인사이트를 공유했지만 아무래도 시간이 촉박하다보니 충분한 전략을 세우지 못했던 것 같다. 면밀한 조사, 그리고 기록은 언제나 중요하다는 걸 느꼈다.

이번 프로젝트에서 내 갈증을 어떻게 해결할 지 실마리가 보였다. 간단하지만 명확한 커뮤니케이션이 내가 가장 부족한 영역이라고 생각했다. 아이디어가 많지만 이를 어떻게 구조화해야 하는지, 다른 사람이 충분히 이해할 수 있는지 제대로 확인이 안 됐었다. 기술적으로 부족한 팀장으로서 어떻게 팀을 이끌어야하는지도 이제 좀 보이는 것 같다. 무엇보다 좋은 팀원들과 치열하게 고민한 경험은 이제까지 인생에서 가장 뜻 깊은 경험이었다.