YSU SW2 중간보고서

QA Pipeline 구현 계획

DPR을 Baseline study로 삼아 Huggingface에 facebook이 공유해둔 DPR question encoder1 모델과 DPR reader model2을 활용해서 파이프라인을 구축한다. ReSRer 구조는 Retriever로 선정된 top-k passages를 바로 Reader에 제공하는 게 아니라 요약 이후 제공한다. Summarizer를 Retriever와 Reader 사이에 배치하여 QA에 특화된 End-to-End Summarizer학습이 가능하도록 한다. 제안하는 ReSRer 파이프라인이 작동하는 순서는 아래와 같다

Wikipedia document 데이터셋의 Embedding vector들을 벡터 데이터베이스에 저장하고 있다

QA 파이프라인에 Question이 input으로 들어오면 Text Embedding 모델로 벡터화한다

해당 Vector와 유사성 높은 벡터들을 벡터 데이터베이스에서 top-k 개만큼 선정한다

선정된 벡터들에 해당하는 document들을 concatenate하여 Summairzer에서 요약한다

Reader에 요약된 최종 Context를 제공하여 inference를 통해 최종 answer를 생성한다

선행연구 활용

Facebook은 DPR context encoder model도 제공하지만 그 모델로 처리된 Index data를 같이 제공하여 해당 데이터를 사용한다.


# retrieval indexes
    "indexes.single.nq.full.index": {
        "s3_url": "https://dl.fbaipublicfiles.com/dpr/checkpoint/indexes/single/nq/full.index.dpr",
        "original_ext": ".dpr",
        "compressed": False,
        "desc": "DPR index on NQ-single retriever",
    },
    "indexes.single.nq.full.index_meta": {
        "s3_url": "https://dl.fbaipublicfiles.com/dpr/checkpoint/indexes/single/nq/full.index_meta.dpr",
        "original_ext": ".dpr",
        "compressed": False,
        "desc": "DPR index on NQ-single retriever (metadata)",
    },
    "indexes.single.nq.subset.index": {
        "s3_url": "https://dl.fbaipublicfiles.com/dpr/checkpoint/indexes/single/nq/seen_only.index.dpr",
        "original_ext": ".dpr",
        "compressed": False,
        "desc": "DPR index on NQ-single retriever when only Wikipedia pages seen during training are considered",
    },
    "indexes.single.nq.subset.index_meta": {
        "s3_url": "https://dl.fbaipublicfiles.com/dpr/checkpoint/indexes/single/nq/seen_only.index_meta.dpr",
        "original_ext": ".dpr",
        "compressed": False,
        "desc": "DPR index on NQ-single retriever when only Wikipedia pages seen during training are considered (metadata)",
    },

위와 같이 DPR github repository에서 embedding index와 context data를 제공하는데, index data는 passage embedding vector이고 Wikipedia전체 데이터는 full.index이고 그 중에 개발환경을 위한 subset.index 데이터가 있다.


"data.wikipedia_split.psgs_w100": {
        "s3_url": "https://dl.fbaipublicfiles.com/dpr/wikipedia_split/psgs_w100.tsv.gz",
        "original_ext": ".tsv",
        "compressed": True,
        "desc": "Entire wikipedia passages set obtain by splitting all pages into 100-word segments (no overlap)",
},

위와같이 Wikipedia를 최대 100단어로 쪼갠 psgs_w100 데이터는 csv형태로 DPR에서 제공한다. 제공하는 벡터 index와 csv형태로 제공되는 passsage의 매핑되어 있지 않았기에 ChromaDB라는 공유가능한 Vector Database를 이용하기로 했다. Faiss index와 ChromeDB에서 공통적으로 HNSW algorithm을 사용하지만 Vector similarity 연산으로 가져오는 결과값이 차이가 있는 문제가 있어서, 나중에 evaluate시 데이터베이스를 통일할 예정이다. 특히 Wikipedia subset만으로도 데이터 처리 시간이나 메모리 이슈가 자주 발생하기에 공유 벡터 데이터베이스 서버를 두고 요청을 처리할 예정이다.

파이프라인 개선 계획

Reader 모델은 성능비교를 위해 DPR이외의 baseline study를 선정할 예정이다. DPR Reader가 logits형태로 return하고 index를 만들어내는 형태라서 기존에 계획했던 abstractive reader에 대한 가정과 상충된다. 그리고 DPR구조가 top-k passage들을 한꺼번에 reader에 제공해서 inferece하는 게 아니라 passage하나당 question과 pair해서 총 k번 inference한 후 best answer를 찾는 과정을 거친다. 그래서 우리가 계획하는 top-k passage 들에 summary를 적용한 QA 파이프라인으로 인한 직접적 성능 향상을 추론할 수 없게된다.

또한 DPR을 baseline으로 선정할 필요가 없으니 더 연관성있는 좋은 top-k 선정을 위해 text embedding model 또한 변경할 계획이다. SOTA text embedding인 BGE embedding 모델을 고려중이다. Embedding 모델을 변경하면 벡터 데이터베이스 re-indexing 등 컴퓨팅 리소스가 많이 필요하지만 더 좋은 top-k passage 선정이 Summarizer 효과에 큰 영향을 미치기 때문에 개선에 중요한 영향을 미칠 것으로 예상된다.

추가사항

split text segment vs text document

좋은 baseline 모델 비교군 어떻게 할지

reader를 어떤걸로 하지

Summarizer 데이터 생성할 때 어떻게 제공할지

비교할만한 논문과 스코어 있으면 최대한 다양하게

YSU SW2 중간보고서

QA Pipeline 구현 계획

선행연구 활용

파이프라인 개선 계획

추가사항

Recommendations