-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Needs for post-processing #75
Comments
좋은 인사이트 공유해 주셔서 감사합니다. 문제2의 경우에, 영민님 말씀대로 Out-of-vocabulary(OOV)에 대한 고찰이 필요할 것 같습니다. train, test 두 데이터셋에 오타를 정정할 수 있는 전처리를 진행한다면 우려하시는 토큰의 위치 문제는 지장이 없다고 생각합니다. 그 이유는 학습과 추론 과정에서 모델의 토크나이저가 같은 전처리 과정을 진행하기 때문에 같은 위치를 반환함으로 전체적인 문자열의 길이는 같다고 생각합니다. 따라서 학습과정에서부터 전처리는 적용한다면 예측 후에 다시 변환해주는 과정은 고려하지 않아도 된다고 생각합니다. 해결방안1에 대해서는 분명 필요할 것 같습니다. 다만 문제가 'heart beating, heart pounding'을 예측해야하는데 앞에 예측한 부분이 heart beating이라는 점입니다. 여기서 'heart' 뽑아서 뒤에 'pounding'과 연결해야하는데, 이 부분을 어떻게 처리해야할지 아직까지 감이오지 않습니다... 영민님이 정말 중요한 부분을 말씀해주신 것 같습니다. 혹시 제가 잘못 이해하고 있는 부분도 있을 것 같습니다 ㅎㅎ..이 부분에 대해서는 이번주 회의에서 다시한번 서로 분석과정을 공유하고 논의해보는 것이 좋아보입니다!! 좋은 자료 공유해주셔서 다시한번 감사드립니다 ! |
정원님 코멘트 감사합니다. 코멘트 하신부분 대체로 공감하는데 한가지 부연설명 드리고자 합니다.
이부분에서 왜 재변환이 필요 하다고 말씀 드렸냐면, 결국 답지가 오타 포함한 원본 문자열 위치 기준으로 되있기 때문입니다. 문자열 위치 1-2 차이로도 전체적인 location 변경으로 인한 대량 오답이 발생할 수 있다고 생각했습니다. 관련해서 미팅때 더 자세히 논의해 보시죠. 의견 감사합니다! ㅎ |
저도 이번에 데이터를 확인하면서 영민님과 유사한 결론데 도달한 것 같습니다.
혹시 이부분은 pre-processing 시 발생하는 labeling 오류에 대한 방안일을 말씀하시는걸까요?? |
영민님 말씀이 맞네요! 어쨋든 test 데이터의 라벨은 원본 데이터를 기준으로 작성한 것이니 전처리를 통해서 추론을 해도 결국 달라질 수 밖에 없군요,,, 그럼 제가 그 아래 제안드린 오타까지 학습할 수 있는 혹은 예측할 수 있는 방법이 필요하겠네요 ! 코멘트 감사합니다 ! |
아뇨, 예측 후 Post-processing 방안을 말씀드린겁니다. 정원님이 언급하신 OOV랑 같은 맥락이라 생각하시면 이해가 쉬우실거 같습니다. |
여기 실험 결과 학습 단계에서 typo token들을 추가한 실험에서 성능이 더 떨어졌네요. 각 오타별로 별개의 vocab으로 인식해 학습의 균일성을 떨어뜨린게 아닌가 추측됩니다. 오히려 typo들의 공통된 span 부분이라도 예측해서 맞추는게 확률상 더 높지 않나 생각합니다. |
Token을 조사하면서 얼마나 우리 데이터셋에 오타가 많다는걸 깨달았습니다.
오타는 단순히 학습을 저해하는 요인이 될 뿐만 아니라, 예측에서도 문제를 야기합니다.
한 오타의 예를 들자면 Adderall 관련 2번 이상 반복된 오타의 종류만 다음과 같이 8개입니다.
물론 이 오타를 수정해서 학습시킨다면 학습이 균일하게 되겠지만 두가지 문제가 발생합니다.
오타를 수정하지 않는다면 토큰이 쪼개져서 학습하게 됩니다. 이에 따라
adderol -> add, er, ol
혹은adderrall -> add, err, all
이런 식으로, 오타마다 token의 생성이 제각각일 것 입니다. 모델이 오타들의 공통 부분만 가지고 예측을 할 수도 있고, 이를 활용 할 수도 있습니다. 하지만 이는 단어의 일부이기에 False negative가 생성될 것 입니다. 혹은 오타들을 Token에 추가하는 방식으로 쪼개지지 않게 할 수 있지만, Test set과 같이 어떤 오타가 등장할 지 모르는 경우에 대응할 수 없습니다.그래서 Post-processing에 대한 논의가 Feedback prize 대회에 많았던 이유였던거 같습니다.
여기 Post Process 단계를 보면,
위의 코멘트를 우리 대회에 맞게 적용할 방안은:
2번에 대한 논의는 예측 값을 더 스터디 한 후 진행하면 될거 같고, 적어도 1번은 예측 char값이 단어의 부분이면 그 단어 전체를 예측하는 코드를 infer 부분에 추가할 수 있을거 같습니다.
피드백 환영입니다.
The text was updated successfully, but these errors were encountered: