질문

• 새로운 Dense Retrieval를 고민하다가 DPR 오픈소스를 사용해보려고 합니다.
• 그런데, training 시에 기존에 학습된 데이터셋 형태로 맞춰달라는 요구사항이 있었습니다.

{
        "dataset": str,
        "question": str,
        "answers": list of str
        "positive_ctxs": list of dictionaries of format {'title': str, 'text': str, 'score': int, 'title_score': int, 'passage_id': str}
        "negative_ctxs": list of dictionaries of format {'title': str, 'text': str, 'score': int, 'title_score': int, 'passage_id': str}
        "hard_negative_ctxs": list of dictionaries of format {'title': str, 'text': str, 'score': int, 'title_score': int, 'passage_id': str}
    }

출처

negative_ctxs은 저희가 논의한 negative sample을 넣는 컬럼 같습니다! 조교님 추천에 계속 등장하는 논문의 구현체들이라, 꼭 사용해보고 싶은데 늘 데이터셋 형식을 맞추는 것에서 발목을 잡히네요.

혹시 이 오픈소스를 사용할 수 있는 방법 (haystack은 DPR 오픈소스를 쉽게 사용할 수 있도록 도와주는 오픈소스입니다) 떠오르시는 분들은 알려주시면 좋겠습니다. ㅠㅠ

• Corrected typos in README.md
• Adjusted hyper-parameters in BM25 and TFIDF
  • TFIDF: max_features 50000 -> None
  • BM25: max_features 50000 -> None, b 0.75 -> 0.01, k1 1.2 -> 0.1

📸 코드

• 학습을 시작하기 전에 연결 끊기는 현상

• 학습 중에 갑자기 연결 끊기는 현상

정말.... 제가.... 뭘 잘못하고 있는 걸까요????? 왜 제가 학습을 돌리기만 하면 이렇게 이슈들이 있을까요. run_retrieval, run 모두에 해당하는 이슈들입니다 ㅠㅠ

• run_mrc.py에서 args.retriever.topk=1로 강제.

기존의 run.py에서는 retrieve 과정에서 args.retriever.topk를 이용해 example을 k배하였으나, run_mrc.py에는 retrieve과정이 존재하지 않아 topk=1로 강제하였습니다.

• utils_qa.py의 postprocess_qa_predictions함수에서 다음 두줄은 eval,prediction시 reader가 어느 document에서 예측했는지 분석용으로 넣어두었습니다.

pred["context_id"] = example['context_id']
pred["context"] = example['context']

🐞 버그 제보

• 메인 브랜치 기준
• 현재 run_mrc를 debug 모드로 돌리면 evaluation 과정에서 'context_id'로 key error 발생합니다.
• 다른 분들도 동일 에러 발생하시는지 궁금합니다. 제 브랜치가 방금 좀 꼬였어서 제 로컬 코드 문제인지도 봐야할 것 같습니다.

👣 버그 발견 과정

• python -m run_mrc --strategies ST01 --debug True --report False --run_cnt 1로 실행
• README의 config와 동일 전략 사용

🤔 원래 예상했던 결과

📸 스크린샷 첨부

🌏 환경 세팅

• OS, 라이브러리 버젼 등을 명시해주세요.

요약

효과가 크게 없어서 지금까지 PR을 안날렸는데, 계속 commit 충돌이 나서 먼저 PR 해둡니다. PR이전에 기존 DPR모델도 이전과 동일하게 돌아가는 것 확인했습니다!

계속 말씀드렸던 custom head 모델 코드입니다.

• LSTM/CNN/FC head를 추가하였습니다.
• 학습중에 토큰 masking을 할 수 있도록 추가하였습니다.
• config 사용 형식이 바뀌었습니다. README 참고해주세요.
• (5/16추가)
  • training 중 evaluation 할 수 있도록 기능 추가하였습니다.
  • Complex CNN head 추가하였습니다.

세부 설명

1. custom head를 추가하였습니다.
   • LSTM/CNN 모델은 임의로 추가한 모델입니다. 구조는 코드가 쉽게 쓰여있어 보시면 바로 아실 수 있습니다.
   • FC 모델은 head 모양 자체는 일반 DPR 모델과 동일합니다. ~다만 원래 모델은 768 x 2 linear layer 1개를 사용했었는데, 여기서는 클래스 상속을 위해 768 x 1 linear layer 2개 사용하고 있습니다. 별 문제는 없을 것 같습니다. 쓸지도 모르겠구요, 기존 모델과 비교를 위해 만들어두었습니다.~ head에서 output 차원이 2가 되도록 코드 수정하였습니다.
2. custom head를 사용할 수 있도록 MRC reader 모델 코드를 추가하였습니다.
   • 현재 custom model의 경우 checkpoint를 바로 불러오기 어려운 상태라, model_path 인자가 추가되었는데 custom model 사용 안하시면 신경 안쓰셔도 됩니다!
   • custom model 사용하실경우 model은 model 이름 주시고, model_path에 checkpoint의 pytorch_model.bin 경로 주시면 됩니다.
3. masking을 추가하였습니다.
   • SpanBERT에서 영감을 받아, 연속된 2개 토큰을 마스킹하도록 세팅되어있으나, 추후 어떻게 해볼지 아직 고민중입니다.
   • args에서 masking ratio를 줄 수 있습니다. custom에서만 동작하고, DPR모델에서는 동작하지 않습니다.
4. prepare.py에서 custom model 작동을 위해 일부 내용 수정하였으나, 마찬가지로 DPR 모델 돌리는데에는 지장 없습니다.
5. strategy에 인자 몇 개를 추가하였습니다. README 참고해주세요! 다만 custom model 돌리실거 아니면 신경 안쓰셔도 됩니다.
6. (추가) pororo reader부분도 커밋되었는데, git에서 인식을 못해서 commit한거고 제가 뭐 수정한건 아니라서 이전과 코드 완전히 동일합니다.
7. (5/16추가)
   • training 중 evaluation 할 수 있도록 기능 추가하였습니다.
     • README에 업데이트해뒀는데, do_eval_during_training 옵션을 true로 주시고 validation을 하고 싶은 step을 eval_step으로 주시면 매 eval_step마다 trainer.evaluate()을 실행합니다.

그 외

수정 예정

1. predict.py에서 model_name_or_path로 바로 run/predict에서 checkpoint 불러올 수 있도록 수정

제가 근 1~2주간 Reader 모델만 맡았음에도 성능 향상이 거의 없어 너무 아쉽고 또 정말 죄송스럽습니다 다음주에는 정말 집중해서 성능 최대한 끌어올려보겠습니다

기존 모델의 nbest predictions 중 Pororo MRC의 예측과 같은 예측이 있을때 score를 추가하여 1등으로 올려버리는 ensemble입니다.

pretrained Pororo 모델(Roberta 모델)을 조사제거 없이 그대로 MRC 모델로 사용했을 경우 valid score는 EM 기준 32.5%입니다(evaluation식으로 따옴표나 brace 등 제거 시 더 오를여지는 있습니다.)

그런데 예측 뒤쪽에 조사가 붙는 경우가 많아 여기에 mecab 형태소 분석으로 뒤쪽 조사를 제거하여 EM 기준 55%가 나왔습니다(마찬가지로 evaluation 하지않고 string이 완전히 일치하는지 기준입니다).

다만 답변을 분석해보니 기존의 저희 모델들이 못맞추는 부분들은 어느정도 잘맞추는데에 비하여, 저희 모델이 맞춘 답변을 터무니없게 예측하는 경우가 있어, 두 모델의 score를 그대로 합치지 않고 pororo가 가장 확신하는 답이 nbest prediction에 있으면 이에 가중치를 주어 (사실상 1등으로) 올리는 방식을 취했습니다. 이 때, 터무니 없는 답을 Pororo가 꼽았는데 이 답이 nbest에 있을 확률을 줄이기 위하여 nbest_size 인자를 20->5로 조정했습니다.

run_mrc를 돌렸을 때 EM 기준 validation이 53.75 -> 57.083으로 상승했고, F1은 63.45 -> 64.945로 소폭 상승하여 기존에 exact match로 못잡아내던 유사정답들을 정답으로 보정하는 효과가 있었습니다.

pororo의 mrc prediction score가 정성평가로 보았을 때 top-1이 평균적으로 13-16정도 나오는 감이 있어 alpha를 처음에는 0.1~0.3정도로 두었으나, 보정효과가 거의 없다고 판단해 1.0과 2.0으로 올려보았고 더 효과가 좋아서 지금은 2.0으로 올려두었습니다. 추후에 필요하면 argument의 하이퍼파라미터로 빼던가 해야할 것 같습니다.

valid set이 240개라 사실 큰 의미가 있는 결과인지 모르겠습니다. 다만 기존 저희 모델이 전혀 다른 답을 예측하던 경우 pororo가 이를 보완하여 답을 내주고 있다고 생각할수는 있을것 같습니다. 또 사실 벌써부터 ensemble이라는 카드를 쓴 셈이라...

구현 방향

1. evaluation.py에서 요구하는 ground_truth json 파일 생성

   • validation이 240개라 만드는데 오래 걸리지는 않지만 그래도 일단 dump해두는 방향으로 했습니다.

   • 파일 생성 경로는 ../input/data/eval_gt.json입니다.

   • eval_gt.json

   [
       {
           "id": "mrc-0-003264",
           "answer": [
               "한보철강"
           ]
       },
       {
           "id": "mrc-0-004762",
           ...
       }
       ...
   ]    
   

2. evaluation.evaluation()에서 get_gt_json()메소드로 ground truth 정보 로딩

   • evaluation.py에 get_gt_json()을 추가하였으며 해당 메소드는 gt_json 파일 생성 및 로드하는 역할을 합니다.

3. evaluation.evaluation()을 run_mrc.py, run.py에서 evaluation시에 실행

4. 결과를 checkpoint/ST_{alias}_{seed}/valid_results.json에 저장

동작은 가능한 상태이며 정확한 테스트를 해보진 못했지만 기존 metric print에서 {'exact_match': 0.0, 'f1': 0.8412189662189662}으로 나오는 ST에 대하여 evaluation 후처리 이후에는 {'exact_match': 0.0, 'f1': 5.63..}으로 나오는 것을 확인했습니다.

지금 저장되는 파일 경로들을 제가 임의로 정한거라 이 부분 더 좋은 아이디어 있으시면 말씀 부탁드립니다! 기타 최적화 방향 및 버그 수정도 말씀 부탁드립니다 : )

• 지영님 branch에서 추가된 retrieval argument
• run.py에서 누락된 top-k 관련 파라미터 추가
  • config의 ST.json에서 retriever 추가 필요

종헌님이 이미 고치시고 commit만 남겨두고 있으신것 같지만 저도 돌려보느라 고쳐놓은 부분들 올렸습니다. 아직 지영님 브랜치 파일 정리가 다 안된것같아 merge해도 무리 없어 보이는 부분들만 제 브랜치에 적용시키고 종헌님 브랜치로 pull request 보냅니다!

BM 25 이슈는 아직 top-k개를 뽑아오지 못해서 정확도가 많이 낮은 문제도 있던것 같습니다.

위의 그래프는 기존 run 코드에서 건모님과 지영님이 구현해두신 top-k 샘플링 적용하여 query당 5개 지문 뽑아왔을 때의 EM입니다. top-1 sampling에서는 BM25가 EM 6% 가량으로 더 낮게 나왔지만, 샘플링 수를 늘리자 13%가량으로 비슷해졌습니다. F-1은 오히려 근소하게 역전했습니다.

주요 수정 사항

[Dense] Dataset 추가

• make_dataset
  • negative_ctxs_dataset : Dense Retriever 오픈소스 학습을 위한 데이터 셋 생성
  • triplet_dataset : ColBERT 모델 학습을 위한 데이터 셋 생성

[Hybrid] 모델 추가

모곧내

• ATIREBM25_DPRBERT
• LOG_BM25_DPRBERT
• LOG_ATIREBM25_DPRBERT

자잘한 수정

자동 정렬로 수정된 파일들 .. ++

• predict.py : 사실 자잘한 수정이라 하기엔 너무 Critical한... 오류였다
  • args.model_path 인자를 args.model.model_name_or_path에 덮어씌움으로써 오류 해결
• retrieval/dense/dpr_base : gradient_accumulation_steps 기능 추가

기존에는 post processing하는 utils_qa에서 token_type_ids를 사용해 query sequence length를 구하고, 이를 이용하여 docs offset을 찾아 같은 context 여부를 판별하도록 되어있었습니다.

...
    for i, feature in enumerate(features):
        # token_type_ids로 query sequence 구한 뒤, 거기서부터 뒤로 일정부분 슬라이싱해 docs 구분하기
        tti = feature['token_type_ids']
        query_sequence_length = len(tti) - sum(tti)  # query sequence length
        doc_offset = feature['offset_mapping'][query_sequence_length][0]  # 해당 context sequence의 첫번째 offset
...

그러나 roberta같은 최근 모델에서는 tokenizing 과정에서 token_type_ids를 사용하지 않아, huggingface에서 auto tokenizer를 불러왔을 때 post_processing 쪽에서 오류가 뜨는 문제가 있었는데, token_type_ids 대신 offset mapping만으로 query length를 측정하도록 하여 해결했습니다.

...
    for i, feature in enumerate(features):

        # query sequence를 지나 document의 첫번째 offset을 가리키는 doc_pointer
        doc_pointer = 0
        while feature['offset_mapping'][doc_pointer] == None:
            doc_pointer += 1
        doc_offset = feature['offset_mapping'][doc_pointer][0]  # 해당 context sequence의 첫번째 offset
...

Hi, your project odqa_baseline_code(commit id: 45954be766e5f987bef18e5b8a2e47f1508742cd) requires "fuzzywuzzy==0.18.0" in its dependency. After analyzing the source code, we found that the following versions of fuzzywuzzy can also be suitable, i.e., fuzzywuzzy 0.7.0, 0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.10.0, 0.11.0, 0.11.1, 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.15.1, 0.16.0, 0.17.0, since all functions that you directly (1 APIs: fuzzywuzzy.fuzz.ratio) or indirectly (propagate to 5 fuzzywuzzy's internal APIs and 3 outsider APIs) used from the package have not been changed in these versions, thus not affecting your usage.

Therefore, we believe that it is quite safe to loose your dependency on fuzzywuzzy from "fuzzywuzzy==0.18.0" to "fuzzywuzzy>=0.7.0,<=0.18.0". This will improve the applicability of odqa_baseline_code and reduce the possibility of any further dependency conflict with other projects.

May I pull a request to further loosen the dependency on fuzzywuzzy?

By the way, could you please tell us whether such an automatic tool for dependency analysis may be potentially helpful for maintaining dependencies easier during your development?

🐞 버그 제보

• pororo 설치 후 run_mrc 학습이 느려지는 버그

==========

• pororo에서 사용하는 torch 버전으로 torch를 재설치함에 따라서 GPU를 사용하지 않게 되고 속도가 느려지게 된다.

pip install torch==1.7.1+cu101 torchvision==0.8.2+cu101 torchaudio==0.7.2 -f https://download.pytorch.org/whl/torch_stable.html

저는 위 명령어로 torch를 재설치 하니 속도가 다시 빨라졌습니다! GPU 사용이 가능해졌어요 :smile:

🐞 버그 제보

• 버그가 어떻게 발생했는지 간략하게 요약하여 적어주세요.

==========

pororo branch merge 이후 python-mecab-ko가 설치되어 있음에도 불구하고 python 인식하지 못하는 문제

==========

👣 버그 발견 과정

• 어떤 식으로 코드를 작동했을때 버그가 발생했는지 기록해주세요. ex)

1. run_mrc, run, predict 등 모델 inference, eval 등을 수행
2. pororo가 설치되어 있지 않거나, python-mecab-ko를 찾을 수 없다는 오류

해결 방법

1. pororo 및 fairseq 라이브러리 설치

pip install pororo
pip install fairseq

2. python-mecab-ko 심볼릭 링크 설정

• 기존 베이스라인 코드를 돌릴 때 shell 파일로 python-mecab-ko를 아마 다 설치하셨기 때문에 실제로는 설치가 되어있는 상태입니다.
• 그럼에도 불구하고 python-mecab-ko가 설치되어있지 않다는 오류가 뜨실 수 있습니다. 일단 pip install python-mecab-ko를 수행해보시고, 오류가 안뜨면 그대로 사용하시고 설치 중 오류가 나서 설치가 안된다면 다음을 따라해주세요.
• 먼저 opt/conda/bin 디렉토리 하위에 mecab-config 디렉토리가 있는지 확인해봅니다.
• 없다면, 아마도 /usr/local/bin 디렉토리 하위에 mecab-config 디렉토리가 있을 겁니다.
• 기존에 설치된 mecab-config에 심볼릭 링크를 설정하여 conda activate시 python-mecab-ko를 찾는 경로로 이어줍니다(바로가기를 만든다고 생각하시면 됩니다.)
  • sudo ln -s /usr/local/bin/mecab-config /opt/conda/bin/mecab-config
  • 이후 다시 pip install python-mecab-ko를 수행하시면 됩니다.

3. 정상적으로 심볼릭 링크가 연결되고 설치가 되었다면 그대로 run,run_mrc,predict를 수행하셨을 때 오류가 뜨지 않습니다.

혹시 문제가 있을 경우 noti해주세요!

참고 레퍼런스

• https://www.lesbonscomptes.com/recoll/pages/recoll-korean.ko.html

📸 스크린샷 첨부

• 버그 발생 당시의 스크린샷을 첨부해주세요.

🌏 환경 세팅

• OS, 라이브러리 버젼 등을 명시해주세요.

xlm-roberta-large 등 큰 모델 돌리면 공통적으로 발생하는 문제입니다.

🐞 버그 제보

• 현재 베이스라인 기준 xlm-roberta-large 모델으로 돌리면 struct.error: 'i' format requires -2147483648 <= number <= 2147483647 에러 발생합니다.
• 위 에러 해결하면 현재 README.md의 예시 strategy로 돌렸을때 기준 OSError: [Errno 12] Cannot allocate memory가 추가적으로 뜹니다.

👣 버그 발견 과정

• 돌려보다가 발견했습니다.. :(

🤔 Bug shooting

struct error

• 일단 첫번째 에러는 이 글이랑 연관됩니다.
• 요약하면 Python 자체 버그로 최신 버전에서는 이슈 리포팅이 되어 수정이 되었으나, 저희 베이스라인 및 conda 기본 세팅이 Python==3.6.6혹은 Python==3.7.7이라 해당 버그가 수정되지 않은 버전입니다.
  • 해결방법은 위 글에서 말하는대로 직접 코드를 추가/수정하거나 Python==3.8 설치하면 됩니다.
  • 저는 귀찮아서 그냥 새로 가상환경파서 3.8 설치했는데 세팅이 생각보다 오래 걸려서.. 비추천드립니다.
  • ~근데 글을 제대로 안읽어봐서 직접 코드 수정하는게 더 오래 걸릴지도 모릅니다ㅋㅋ~
  • 3.8로 가상환경 새로 설치하실경우 일단 mecab에러없게 설치 먼저 하시고, wandb 등 필요한 모듈 추가적으로 설치하고 conda install pytorch==1.7.1 torchvision==0.8.2 torchaudio==0.7.2 cudatoolkit=10.1 -c pytorch로 pytorch 설치하시면 됩니다. (저희 서버 cuda 버전 10.1에 맞는 설치 명령어입니다)

OSError

• 두번째 에러는 원인은 잘 모르겠고 ST00.json에서 data의 processing_num_workers를 1로 주면 해결됩니다. 저건 GPU나 디스크 문제가 아니고 RAM 용량 문제인 것 같은데 아무튼 이러면 해결되는 것 같네요

• (추가) xlm-roberta-large는 checkpoint 하나당 6.3GB의 디스크용량을 잡아먹으니 돌릴 때 디스크 용량도 주의해주세요! 제 기준 epoch 3.0에 예상시간 1시간~2시간 뜹니다. 왔다갔다거리네요

📸 스크린샷 첨부

1. 첫번째 에러

2. 두번째 에러

🌏 환경 세팅

• 부캠 서버