10:00 ~ 13:00

• 지난 이틀을 쉬었다. 팀플을 하면서 이전부터 느낀 점이지만, 초등학생들이 축구하는 모습처럼 보였다. 목적을 서로 공유했지만, 실제 프로젝트에서 의미가 없어졌다. 무기력해졌다. 이 일을 분배할 필요가 있다고 말했지만, 애초에 테스크 자체가 작아 나눌 필요조차 없다는 반응이 대부분이었다. 뭘 해야하는지 왜 해야하는지 계속 의문이 들었다. 허깅페이스에서 모델을 찾아서 돌리고 다시 하이퍼파라미터를 수정해서 돌리고 무한 반복이었다. 그 과정에서 오버피팅 된 것 같다는 단순한 인사이트로 다시 돌리는 것이 전부였다.
• 2인 1조 총 3조로 서버를 할당했다. 총 서버 4개가 주어지는데, 공용 서버를 둬, Optuna 같이 오래 걸리는 작업을 공용 서버로 돌리고, 각자 조별로 모델을 돌리기로 했다. 나랑 같은 서버를 할당받은 팀원은 RTT로 데이터 증강을 했다. 나도 Solar Pro로 데이터 증강을 했다.
• LLM으로 데이터 증강을 하면서 2가지 문제점이 발생했다. 첫번째로 정확도였다. LLM을 활용해서 프롬프트라는 새로운 변수가 생겼다. 기존에 보고서 생성 모델을 만들때 프롬프트를 살짝 만져봤지만, 그때에 비해 새로운 프롬프트 엔지니어링이 많이 발표됐다. 두번째로 출력 포맷팅이었다. 출력이 텍스트 스트림으로 나오다보니 정확히 증강된 데이터를 뽑아내기 힘들었다. 이런 이유로 langchain을 도입하기로 했다.

13:00 ~ 16:00

• langchain을 처음 사용해봤는데, 생각보다 어려웠다. 전체적인 아이디어는 파이프라인 구성으로 파악이 됐는데, 새로운 프레임워크다보니 문법 자체에 미숙했다. langchain 공식 문서와 유튜브, chatGPT/perplexity를 참고하며 구성했다. 프롬프트 기법을 적용해보려 순차적으로 모델에게 할 일을 부여했다. 최종 프롬프트는 다음과 같았다.

당신은 한국어 문법에 대가이며, 사용자가 입력한 두 문장의 문법적, 실제 의미를 그대로 부사어만 삽입/수정/삭제하며 기존 문장과 같은 의미를 가진 새로운 문장을 생성합니다. 
제공될 텍스트는 문법적으로 올바르지 않을 가능성이 많으므로, 문법이 올바르지 않는 경우, 최대한 원본 텍스트를 살려서 작업을 수행합니다.

당신이 수행할 작업 절차는 다음과 같습니다.
우선, 당신은 입력 받은 두 문장이 문법적으로 올바른지 여부를 판단합니다.
만약, 입력 받은 두 문장이 문법적으로 올바르지 않은 경우, 최소한의 문자 변경 및 삽입을 통해 두 문장을 올바르게 변경합니다.
그 다음, 당신은 두 문장에서 부사어, 조사를 구분합니다.
그 다음, 당신은 부사어, 조사만을 수정하여 새로운 두 문장에 대한 후보 3개를 생성합니다.
그 다음, 당신은 각 원본 문장과 후보 문장을 비교하여 의미가 가장 유사한 문장을 출력합니다.

당신은 위 작업으로 생성한 두 문장만을 각각 'new_sentence_1', 'new_sentence_2'를 키로 갖는 JSON 형태로 출력해야 합니다.

Tree of Thought이라는 프롬프트 엔지니어링 칼럼을 읽고 나름 작성한 프롬프트인데 그다지 좋지 않았다.
그리고 ResponseSchema, StructuredOutputParser로 출력을 JSON 형식으로 맞추려 했다.

# JSON 스키마 정의
response_schemas = [
    ResponseSchema(name='new_sentence_1', description="sentence_1에 대한 증강 작업 결과"),
    ResponseSchema(name='new_sentence_2', description="sentence_2에 대한 증강 작업 결과")
]

# 파서 생성
parser = StructuredOutputParser.from_response_schemas(response_schemas)

하지만 동작 시 생각보다 정확하게 포맷되지 않았다. new_sentence1, new_new_sentence_1 등 키 값이 정확히 파싱되지 않는 경우가 많았다.

• Solar Pro Preview 모델을 사용하는데 TOO_MANY_REQUEST 에러가 많이 발생했다. 멀티 프로세싱으로 빨리 데이터 증강을 하려고 했는데, 한 번에 많은 요청을 보내 저런 에러가 발생한 것 같았다. 에러 응답을 받으면 딜레이를 주었다가 다시 요청하는 방식으로 바꿨다.
  그 결과 1400개 내외 데이터를 3배로 증강하는데 40분 정도 소요됐다. 원래 tqdm을 찍어보니 2시간 정도 소요되는 반면에 많이 줄였다.

16:00 ~ 19:00

• LLM의 temperature을 바꿔보며 실험했다. 0, 0.3, 0.5, 0.7 총 4가지를 실험했는데, 0.3까지도 중복되는 문장이 너무 많았다. 0.7은 왠지 모르겠지만, 일본어 텍스트가 출력되는 경우가 있었다.