처음에 강의를 듣고 [SUB] [OBJ] 같은 special entity marker를 문장 내에 적용을 해보기로 했음 !
처음에는 이렇게 하게 된다면 베이스라인 코드에서 sub_ent [SEP] obj_ent를 나누는 문장이 필요없어질 것이다.. 라는 생각을 했고, 한 문장과 두 문장에 대한 실험을 해보았다. 내 기준으로는 두 문장이 조금이라도 더 성능이 좋았던 것 같다.
두 문장으로 하기로 결정을 했고.. 어떠한 방식으로 한 문장을 추가해줄까에 대한 고민을 많이 했다. 동건님이 제안해주신대로 [SUB] [/SUB] [OBJ] [/OBJ] 형식으로 고쳤음.. 조금 더 나아진 것 같기도..?
오피스 아워를 듣고.. Query 형식으로 문장을 추가하기로 하였다 sub_ent와 obj_ent의 관계 라는 문장을 추가해주었더니 솔직히 많은 성능 향상은 아니었고 조금 안정화된 느낌이 들었다.
성능을 올리려면 모델 구조적인 부분에 대해서 add on module을 하는게 더 좋겠다고 생각했고 동건님이 논문 구현을 통해 성능 향상을 하셨고, 오피스아워 때 나온 LSTM을 보고 추가해보려 했다. → 성능 향상 폭이 컸던 것 같다 !
여기서 이제 나온 LSTM에 input 형식을 계속 변경하였다 Query + [SUB] token을 추가하는 방법을 진행했고.. 성능향상이 잘 되는 것 같지 않았다 ! → 이 때 동건님이 sentence 부터 entity 모두 동일하게 제거한 데이터를 사용함
다인님이 special token 추가를 punctuation으로 변경하여 input으로 넣어주셨더니 성능이 꽤 많이 올랐다 ! → 이 이유로는 special token을 추가하면 초기화하여 우리가 사용하게 되는데 데이터가 그렇게 많지 않아 완전히 학습이 안되었지만 punctuation은 pretrained 때부터 나왔던 token이므로 그 의미를 어느정도 학습하고 있다고 판단을 해서 였다 ! → 여기서 punctuation은 논문에도 나온 #과 @를 사용하였고, train, test set에서 모두 그 기호를 사용하지 않았기 때문에 사용했다고 하셨음 → 다른 것을 사용하는 것은 어떨까에 대한 의문이 살짝 들기는 함.
여기서 type 추가할 때는 ₩과 ^를 사용하셨었는데 내가 확인해본 결과 ₩를 사용하게되면 모델이 [UNK]로 인식을 했음.. 그래서 나는 *로 변경을하고 이 때 type이 쪼개지는 현상을 보았고.. 그게 싫어서 vocab에 단어를 추가해주었다. → 근데 UNK로 나온 결과물이 생각보다 결과가 좋았음.. 왜그럴까..?에 대한 생각을 진행해보자
이건 다영님 실험 결과인데 punctuation에 query 추가하니까 더 오르고, type까지 추가를 하니까 더 많이 올랐다 ! 이 때 기존 논문의 방법론으로는 type을 토큰으로 추가해주지 않아 쪼개지는 것을 더 권장을 하는데.. 그게 더 단어의 의미를 잘 내포하고 있으며 토큰을 추가해주면 초기화해서 다시 학습을 진행하게 되는 거니까.. 스페셜토큰 쓰는거랑 다름이 없을 것이다라는 말을 하셨음..
그래서 punct에 query + add_token을 해준 Input에 lstm을 태운 모델이 지금 10.04 기준 제일 높은 모델이다..
추가적으로 우리는 KFOLD하는 방법론을 각 fold에서 logit submission을 생성한 다음에 그 것들을 다 더해 평균을 낸 다음 softmax를 취하는 방식으로 구현을 하였음 ! → 이게 맞는 방법이라고 생각함..
Klue/roberta 가 mrc 데이터를 통해 학습되었다는 이야기를 들어서 klue/mrc data를 보고 QA 방식이 어떤지에 대해 분석을 해보았다 !
long query [sub]와 [ent]의 관계는 무엇일까? 와 [sub]와 [ent]의 관계 의 성능에 대한 비교.. !
스페셜 토큰, 그냥 토큰으로 추가했을 경우에 대한 논의.. → 잘 모르겠음..
vocab에서 토큰의 길이가 긴 단어부터 찾는 logic이 있다..
조금 조금씩.. 바꾸기 때문에 재현이 안되는 것 같음..
add token을 하지않고 사용하는 것이 보통 논문의 방법이라고 하심.. 이미 잘 학습된 임베딩 벡터를 사용하는게 맞다는..느낌