Skip to content
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

Closed
ympaik87 opened this issue Mar 29, 2022 · 6 comments
Closed

Needs for post-processing #75

ympaik87 opened this issue Mar 29, 2022 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@ympaik87
Copy link
Contributor

ympaik87 commented Mar 29, 2022

Token을 조사하면서 얼마나 우리 데이터셋에 오타가 많다는걸 깨달았습니다.
오타는 단순히 학습을 저해하는 요인이 될 뿐만 아니라, 예측에서도 문제를 야기합니다.

한 오타의 예를 들자면 Adderall 관련 2번 이상 반복된 오타의 종류만 다음과 같이 8개입니다.

adderal
adderol
adderoll
adderral
adderrall
aderall
aderol
aderral

물론 이 오타를 수정해서 학습시킨다면 학습이 균일하게 되겠지만 두가지 문제가 발생합니다.

  1. test set 오타에 대한 대응: test set에도 train set과 비슷한 빈도의 오타가 있을 것으로 예상 되고, 신종 오타에는 여전히 대응하기 어려울 것 입니다.
  2. 위치 재변환의 문제: prediction은 원본의 문자열 location기준입니다. 만약 오타를 변환한다면 8자인 Adderall은 7자 혹은 6자 오타 들의 위치를 바꾸게 될 것이고 이는 전체 문자열의 위치 변형이 일어날 것입니다. 따라서 재변환 코드를 예측 뒤에 또 수행하는 코드가 필요합니다.

오타를 수정하지 않는다면 토큰이 쪼개져서 학습하게 됩니다. 이에 따라 adderol -> add, er, ol 혹은 adderrall -> add, err, all이런 식으로, 오타마다 token의 생성이 제각각일 것 입니다. 모델이 오타들의 공통 부분만 가지고 예측을 할 수도 있고, 이를 활용 할 수도 있습니다. 하지만 이는 단어의 일부이기에 False negative가 생성될 것 입니다. 혹은 오타들을 Token에 추가하는 방식으로 쪼개지지 않게 할 수 있지만, Test set과 같이 어떤 오타가 등장할 지 모르는 경우에 대응할 수 없습니다.

그래서 Post-processing에 대한 논의가 Feedback prize 대회에 많았던 이유였던거 같습니다.
여기 Post Process 단계를 보면,

image

위의 코멘트를 우리 대회에 맞게 적용할 방안은:

  1. 토큰 레벨로 예측한 단어들은 broken span을 생성하기에 고치기.
  2. 예측 location의 평균 길이 등을 조사해 예측된 부분이 너무 짧거나 단어가 군대군대 이루어 지면 이를 연결하는 휴리스틱한 룰을 적용.

2번에 대한 논의는 예측 값을 더 스터디 한 후 진행하면 될거 같고, 적어도 1번은 예측 char값이 단어의 부분이면 그 단어 전체를 예측하는 코드를 infer 부분에 추가할 수 있을거 같습니다.

피드백 환영입니다.

@ympaik87 ympaik87 added the enhancement New feature or request label Mar 29, 2022
@ympaik87 ympaik87 self-assigned this Mar 29, 2022
@Kingthegarden
Copy link
Contributor

Kingthegarden commented Mar 29, 2022

좋은 인사이트 공유해 주셔서 감사합니다.
제 개인적인 의견으로는

문제2의 경우에, 영민님 말씀대로 Out-of-vocabulary(OOV)에 대한 고찰이 필요할 것 같습니다. train, test 두 데이터셋에 오타를 정정할 수 있는 전처리를 진행한다면 우려하시는 토큰의 위치 문제는 지장이 없다고 생각합니다. 그 이유는 학습과 추론 과정에서 모델의 토크나이저가 같은 전처리 과정을 진행하기 때문에 같은 위치를 반환함으로 전체적인 문자열의 길이는 같다고 생각합니다. 따라서 학습과정에서부터 전처리는 적용한다면 예측 후에 다시 변환해주는 과정은 고려하지 않아도 된다고 생각합니다.
하지만, 문제는 영민님 말씀대로 저희가 나머지 66%의 데이터셋에 어떤 "오타"들이 존재할지 예측할 수 없다는데 있습니다. 따라서 이를 중점으로 전처리 과정을 설계하는 것이 좋아보입니다.
따라서, 제 개인적인 생각으로는 오타들도 vacab에 추가하여 모델이 예측할 수 있도록 하는 방법은 어떨까 싶습니다.

해결방안1에 대해서는 분명 필요할 것 같습니다. 다만 문제가 'heart beating, heart pounding'을 예측해야하는데 앞에 예측한 부분이 heart beating이라는 점입니다. 여기서 'heart' 뽑아서 뒤에 'pounding'과 연결해야하는데, 이 부분을 어떻게 처리해야할지 아직까지 감이오지 않습니다...
해결방안2에 대해서는 제가 분석한 코드에 의하면 평균 길이로 예측하는 것이 어려움이 있습니다. 예를 들어서 episodes의 경우 채점자에 따라 episodes를 정답으로 하는 사람이 있고, episode를 정답으로 하는 사람이 있습니다. 또한 앞에 전치사, 수식어와 같은 부분을 포함하여 정답처리하는 경우도 있어 평균 길이를 적용하는데 어려움이 있지 않을까? 싶습니다.

영민님이 정말 중요한 부분을 말씀해주신 것 같습니다. 혹시 제가 잘못 이해하고 있는 부분도 있을 것 같습니다 ㅎㅎ..이 부분에 대해서는 이번주 회의에서 다시한번 서로 분석과정을 공유하고 논의해보는 것이 좋아보입니다!! 좋은 자료 공유해주셔서 다시한번 감사드립니다 !

@ympaik87
Copy link
Contributor Author

정원님 코멘트 감사합니다. 코멘트 하신부분 대체로 공감하는데 한가지 부연설명 드리고자 합니다.

train, test 두 데이터셋에 오타를 정정할 수 있는 전처리를 진행한다면 우려하시는 토큰의 위치 문제는 지장이 없다고 생각합니다. 그 이유는 학습과 추론 과정에서 모델의 토크나이저가 같은 전처리 과정을 진행하기 때문에 같은 위치를 반환함으로 전체적인 문자열의 길이는 같다고 생각합니다. 따라서 학습과정에서부터 전처리는 적용한다면 예측 후에 다시 변환해주는 과정은 고려하지 않아도 된다고 생각합니다.

이부분에서 왜 재변환이 필요 하다고 말씀 드렸냐면, 결국 답지가 오타 포함한 원본 문자열 위치 기준으로 되있기 때문입니다. 문자열 위치 1-2 차이로도 전체적인 location 변경으로 인한 대량 오답이 발생할 수 있다고 생각했습니다.

관련해서 미팅때 더 자세히 논의해 보시죠. 의견 감사합니다! ㅎ

@jerife
Copy link
Member

jerife commented Mar 29, 2022

저도 이번에 데이터를 확인하면서 영민님과 유사한 결론데 도달한 것 같습니다.
좋은 인사이트 감사합니다!

  1. 토큰 레벨로 예측한 단어들은 broken span을 생성하기에 고치기.

혹시 이부분은 pre-processing 시 발생하는 labeling 오류에 대한 방안일을 말씀하시는걸까요??

@Kingthegarden
Copy link
Contributor

정원님 코멘트 감사합니다. 코멘트 하신부분 대체로 공감하는데 한가지 부연설명 드리고자 합니다.

train, test 두 데이터셋에 오타를 정정할 수 있는 전처리를 진행한다면 우려하시는 토큰의 위치 문제는 지장이 없다고 생각합니다. 그 이유는 학습과 추론 과정에서 모델의 토크나이저가 같은 전처리 과정을 진행하기 때문에 같은 위치를 반환함으로 전체적인 문자열의 길이는 같다고 생각합니다. 따라서 학습과정에서부터 전처리는 적용한다면 예측 후에 다시 변환해주는 과정은 고려하지 않아도 된다고 생각합니다.

이부분에서 왜 재변환이 필요 하다고 말씀 드렸냐면, 결국 답지가 오타 포함한 원본 문자열 위치 기준으로 되있기 때문입니다. 문자열 위치 1-2 차이로도 전체적인 location 변경으로 인한 대량 오답이 발생할 수 있다고 생각했습니다.

관련해서 미팅때 더 자세히 논의해 보시죠. 의견 감사합니다! ㅎ

영민님 말씀이 맞네요! 어쨋든 test 데이터의 라벨은 원본 데이터를 기준으로 작성한 것이니 전처리를 통해서 추론을 해도 결국 달라질 수 밖에 없군요,,, 그럼 제가 그 아래 제안드린 오타까지 학습할 수 있는 혹은 예측할 수 있는 방법이 필요하겠네요 ! 코멘트 감사합니다 !

@ympaik87
Copy link
Contributor Author

혹시 이부분은 pre-processing 시 발생하는 labeling 오류에 대한 방안일을 말씀하시는걸까요??

아뇨, 예측 후 Post-processing 방안을 말씀드린겁니다. 정원님이 언급하신 OOV랑 같은 맥락이라 생각하시면 이해가 쉬우실거 같습니다.

@ympaik87
Copy link
Contributor Author

ympaik87 commented Mar 30, 2022

따라서, 제 개인적인 생각으로는 오타들도 vacab에 추가하여 모델이 예측할 수 있도록 하는 방법은 어떨까 싶습니다.

여기 실험 결과 학습 단계에서 typo token들을 추가한 실험에서 성능이 더 떨어졌네요. 각 오타별로 별개의 vocab으로 인식해 학습의 균일성을 떨어뜨린게 아닌가 추측됩니다. 오히려 typo들의 공통된 span 부분이라도 예측해서 맞추는게 확률상 더 높지 않나 생각합니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants