[Fastcampus Upstage AI Lab 3기]과학 질의 응답 시스템 구축 대회 후기(with RAG)

1. 요약

 인터넷의 등장으로 많은 정보들의 네트워크 상에서 떠돌고 있습니다. 우리는 이러한 정보를 얻기위해 검색하여 정보들을 직접 열람하여 내가 원하는 정보가 맞는지 확인하는 작업을 거쳤야만 했습니다. 하지만 이러한 작업은 정보가 과도하게 증가할 수록 정보를 찾는 이용자들에게 피로감 증가로 이어졌습니다. 이러한 문제를 인공지능을 도입하여 해결하려는 시도들이 많이 있었습니다.
 우리도 Upstage AI Lab에서 주최한 '과학 질의 응답 시스템 구축' 대회를 통해 과학 정보에 대한 검색을 인공지능, 특히 Advanced RAG를 사용하여 해결하는 방법을 제시했습니다. 저희의 모델은 public에서 MAP 0.9561, MRR 0.9591을 기록하며 우수한 성능을 보였고 정성 평가에서도 우수한 성능을 다시 한번 확인 했습니다. 최종 private에서 MAP 0.9189, MRR 0.9197로 대회 2등으로 마무리를 하였습니다. 큰 폭으로 성능하락이 있어 오버피팅으로 결론 지을 수도 있으나, 대회 제공 데이터의 노이즈와 번역체 등의 문제 또한 관가할 수없습니다. 
 우리는 대회에서 요구한 모델의 성능을 넘어 모델의 서비스를 구축하면서 MLOps에 대한 경험도 쌓았습니다. 구축한 RAG 시스템을 바탕으로 Chat-bot구현과 Chrom Extention구현을 하였습니다. 서비스화에서는 단순히 모델의 성능만 고려하는 것이 아닌 모델의 반응 속도, 리소스의 제한에 알맞은 모델의 경량화, 서비스에서 필요한 부가적인 파이프라인 구축 등을 경험하였습니다.
 이러한 과정을 대회 소개, RAG시스템 고도화 과정 순으로 소개하고 마지막으로 서비스 구축한 경험을 정리하며 이 글을 마무리 하도록 하겠습니다.

2. 대회 소개

 과학 질의 응답 시스템 구축 대회는 머신러닝 모델을 학습하는 것 보다는 임베딩 생성 모델, 검색엔진, LLM 등을 활용하여 레퍼런스를 잘 추출하는지를 판단하는 대회 입니다. 대회에서는 4200개의 과학 관련 문서가 주어집니다. 

4200개 문서들의 단어 갯수 분포

4200개 문서는 모두 350단어 이하로 구성되어 있으며 60~70단어로 구성된 문서들이 대부분입니다. 또한 100개의 데이터에 대해 무작위 샘플링하여 직접 읽어본 결과 문서는 모두 하나의 공통된 주제에 대해서만 서술되어있는 깔끔한 데이터였습니다. 하지만 원본 데이터가 영어데이터로 구성되어 있던것을 한국어로 바꾸었기에 번역체가 남아있었습니다. 또한 번역과정에서 오역이 발생하였는지 몇몇개의 데이터에서는 과학적 사실과 다른 내용을 서술하고 있거나 논리적이지 않은 글들도 존재하였습니다.

논리적인 글을 가지고 있지 않은 데이터 예시

이러한 점들을 감안했을 때, 문서를 chunk로 나눌 필요가 없다고 생각했고, 논리적이지 않은 글들을 어떻게 처리해야 할지에 대한 고려와 함께 RAG시스템을 구축해야한다고 생각했습니다. 
대회의 평가 방법은 Query를 주면 해당 Query와 유사한 문서를 추출하는 것이 이번 대회의 목표입니다. 잘 추출 했는지에 대한 기준은 MAP와 MRR 지표를 활용하여 평가합니다.

여기에 추가하여 대화 메시지가 과학 상식에 대한 질문일 수도 있고 아닐수도 있기 때문에 과학 상식 질문이 아닌 경우는 문서를 추출할 필요가 없습니다. 그래서 검색이 필요없는 ground truth 항목에 대해서는 검색 결과가 없는 경우를 1점으로 주고 그렇지 않는 경우는 0점으로 계산하게 로직을 추가했습니다.

3. RAG시스템 고도화 과정

3-1. RAG 시스템 초기 구조

처음 RAG시스템 구조 설계

1. 입력으로 들어오는 query는 Single hop 형태일 수도 있고 Multi hop 형태일 수도 있습니다. Multi hop의 경우 적절한 Instruction과 함께 Prompt에 넣어 GPT-4o에게 전달합니다. 이후 GPT-4o가 단순한 query(standalone query)를 생성합니다.

2. 다시 GPT-4o에 해당 데이터를 Instruction과 함께 넣어 과학적 질문 유무를 판단합니다.

3-1. 과학적 질문일 경우, query를 검색에 용의한 query로 변경하여 RAG system에 전달하여 query와 연관된 5개의 관련 문서를 반환 받습니다.

3-2. 과학적 질문이 아닐 경우, GPT-4o를 사용하여 답변을 생성하고 과정을 끝냅니다.

4. 5개의 관련 문서를 다시 GPT-4o에 전달하여 논리적으로 오류가 없는지 검증하여 검증된 문서들만 GPT-4o에 전달하여 답변을 생성하고 과정을 끝냅니다.

RAG System 구조 설계

1. 검색에 용이한 query를 Faiss란 임베딩 DB를 통해 임베딩 된 문서들 중 cosine 유사도가 가장 높은 200개 문서를 반환 받습니다.

- Faiss를 통해 KNN검색을 합니다(ANN보다 KNN이 검색의 질은 높지만 검색 속도가 느립니다. 그러나 해당 대회에서는 데이터 량이 적으므로 KNN이 유리할 것이라 생각했습니다.)

- Embedding은 한국어 검색에서 가장 성능이 높다고 평가되는 Solar Embedding을 사용하였습니다.

2. 200개의 문서는 cross-encoder기반이며 한국어로 fine tuning된 검색 모델인 'Dongjin-kr/ko-reranker'를 사용하여 5개의 관련 문서를 반환 받았습니다.

리더보드 결과

MAP와 MRR이 Base모델과 비교하면 MAP는 0.0834, MRR은 0.0803의 상승이 있었습니다.
정성적 평가 결과 대부분의 데이터들이 옳게 매칭되고 있었으나 과학적 질문을 하였음에도 불구하고 관련된 문서가 없다는 결과를 받거나 질문과 연관은 되어 있으나 대답을 생성하기에 정보가 부족한 문서들과 매칭되어 있는 query들이 있었습니다.

3-2. 논리적 문서 판단 부분 제거 & Fusion적용

논리적 문서 판단 GPT 제거

 초기 RAG시스템의 모델 성능 결과 소폭의 성능 향상은 있었으나 기대한 성능향상에 미치지 못하는 아쉬운 결과 였습니다. 이러한 결과의 원인으로 논리적 오류 문서를 체크하는 부분을 꼬집었습니다. 리더보드의 Ground Trouth자체가 문서에 논리적 오류가 있던 말던 query에 관련만 있으면 연관된 문서라고 설정했을 가능성 높다고 생각했습니다. 이는 정성적 평가를 통해 과학 지식 질문임에도 관련 문서가 없다는 결과를 가진 데이터를 보며 확신을 가질 수 있었습니다. 따라서 논리적 오류 문서를 체크하는 부분을 제거하였습니다.

  또한 너무 간단한 RAG 시스템 구조 또한 성능을 크게 올리지 못한 것에 기여하였다고 생각합니다. 특히, Faiss를 통한 dense 방식의 유사도 측정은 sementic한 정보의 유사도를 측저하는 것에는 좋으나 광범위한 일반 지식 영역이 아닌 특정 도메인에 대한 정보 검색 일수록 sparse한 방식이 효과적이라는 연구 결과도 있었습니다. 따라서 elastic search를 활용하여 BM25기반 역색인 방식의 검색 방식 또한 사용하였습니다. 각각의 방식으로 200개 씩의 문서를 검색해 오고 중복을 뺀 400개이하의 문서를 reranker에 전달하여 cross-encoder기반의 점수를 부여받습니다. dense방식의 cosine 유사도 점수기반 200개 문서, sparse방식의 BM25 점수 기반 200개 문서, reranker점수 기반 400개 이하문서들 각각을 z-정규화를 취한 후 아래 공식을 사용하여 최종 점수를 환산하여 3개의 문서를 도출 했습니다.

fusion score = (dense score * 0.7 + spares score * 0.3) * 0.525 + reranker score * 0.475

각 스코어에 곱해진 상수는 여러번의 실험을 통해 얻어진 하이퍼파라미터이다.

그 결과 MAP는 0.7879에서 0.9015로 약 0.1136 향상 하였고 MRR은 0.7894에서 0.9030으로 약 0.1136 향상된 결과를 얻을수 있었습니다.

3-3. LLM Re-Ranker

Fusion RAG의 ouput결과들을 살펴보면 대부분 상위 15개 문서 안에 정답 문서들이 존재했습니다. 하지만 가장 관련도 높은 문서가 1위에 위치한 것들이 적었습니다. 이를 해결하고자 LLM re-ranker 방식을 사용했습니다.

LLM Reranker

Fusion의 15개 문서 output 중에 1등 문서 유사도의 10%보다 유사도가 작은 문서가 존재한다면 그러한 문서는 Fusion에서 이미 query와 너무 연관 없다고 판별된 문서라 여기고 제외했습니다. 그러한 것들을 제외한 15개 이하의 문서를 GPT-4o에 instruction과 함께 전달합니다. 그 결과 query와 가장 유사한 문서라고 판단되는 문서 3개를 반환 받습니다.

LLM reranker 결과

그 결과 MAP 지표에서 0.9015에서 0.9288로 약 0.0273 상승하였고 MRR 지표에서 0.9030에서 0.9333으로 약 0.0303 상승하였습니다. 정성평가에서도 적절한 연관 문서를 찾고, 만족 할 만한 답변들을 생성하였습니다.

3-4. RAW Query 

데이터를 분석해보면 주어진 query의 형태가 single hop인지 muti hop인지의 차이는 있지만 모든 query들이 단순하고 간단 명료한 형태로 질문을 하고 있었습니다. 따라서 검색에 용의하게 바꾸는 과정이 오히려 노이즈를 생성하는 과정일 수도 있겠다는 생각이 들었습니다.

Original Query 사용

따라서 과학적 질문 인지를 판별하는 GPT-4o의 프롬프트에서 검색에 용이한 tranformed query로 변환하는 Instruction부분을 제거하였습니다. 이로 인해 RAG system에 원본 데이터 형태를 유지한채 입력으로 들어가게 됩니다.

Raw Query 결과

그 결과 MAP 지표에서 약 0.027 상승했고 MRR 지표에서 0.0258의 상승이 있었습니다.

3-5 최종 결과 분석

private 리더보드 결과

최종 MAP 지표 0.9136점, MRR 지표 0.9167점을 기록하며 2위로 대회를 마무리 하였습니다.
public에 비해서 큰 폭으로 점수가 하락한 것을 확인 할 수 있습니다. 이러한 원인으로 세가지를 꼽았습니다.

첫 번째로, Fusion에서 상수값을 여러번의 실험에 의해 public 점수가 가장 잘 나오는 것을 fitting한 것이라 이 부분에서 오버피팅이 발생했을 것이라고 추측합니다.

두 번째로, LLM reranker의 과적합 입니다. LLM reranker를 적용하지 않은 모델이 MAP지표 0.9258과 MRR 지표 0.9288로 성능이 더 좋은 것을 확인했습니다. 이러한 결과를 보아 LLM reranker가 오히려 과적합을 일으키는데 영향을 미쳤다고 여겨집니다.

마지막 세번째로 테스터 데이터의 질 입니다. 번역체로 되어있고 논리적인지 않은 글로 구성된 문서들이 있었습니다. 이러한 데이터들이 노이즈를 일으켜 오버피팅이 일어났다고 추측합니다.

아쉽게 1등자리를 빼앗겨 버렸지만 실제 현장에서 많이 원하고 있는 RAG를 깊이 다루어 볼 수 있었던 좋은 대회였습니다.

4. Chat Bot 서비스

Chatbot 서비스

대회에서 구축한 RAG시스템을 활용하여 과학 질의에 응답하는 Chat bot을 구현해 보았습니다. Chatbot에는 이전 대화와 관련된 질의나 이전 대화에 이어서 하는 질의들을 사용자가 보낼 수 있습니다. 이러한 경우 이전 대화를 참고하여 답변을 생성하여야 합니다. 이를 해결하기 위한 간단한 방법으로 이전 대화의 내용을 프롬프트에 담아 현재 사용자의 입력과 함께 보내는 방법이 있습니다. 하지만 이러한 방법을 사용한다면 대화가 길어질 수록 프롬프트가 길어지고 이어서 성능 악화와 비용문제가 발생 할 것입니다. 이를 해결하고자 아래와 같은 시스템을 제안하였습니다.

history manger라는 시스템을 만들었습니다. 이 또한 RAG를 기반 시스템으로, query와 관련도가 높은 이전 대화를 검색하는 역할을 합니다. 자세한 history manager의 구조는 아래와 같습니다.

 단기기억 공간(recent_data)과 장기기억 공간(summary_data)으로 나누어 이전의 대화를 저장합니다. 단기 기억공간에 5개의 대화가 찼을 경우 가장 오래된 대화를 요약하여 장기 기억 공간에 저장합니다. 검색 과정에서는 단기 기억 공간에서는 최근 대화 두개를 가져오고 장기기억 공간에서는 pinecone을 통해 dense기반 cosine 유사도 측정을 통하여 가장 유사한 요약 대화 2개를 가져와 반환합니다. 반환된 대화들은 프롬프트에 넣어 현재 사용자의 query와 함께 담겨 GPT-4o에 전달합니다.

이러한 과정을 쉽게 Lanchain을 통해 구현 할 수 있습니다. 그러나 Lanchain을 이용해 구현한 결과 정말 간단한 코드로 정말 빠르게는 구현이 되지만 우리가 원하는 기능들을 넣기에는 불편함이 있다는 것을 느꼈습니다. 기능면에서는 ReAct Agent의 기능이 대단하였다고 느꼈지만 그 또한 GPT API를 통해 해결 할 수 있겠다는 생각이 들었습니다.

5. Google Extention

 
 두 번째로 개발한 것은 Tavily라는 실시간 웹브라우저 검색 API를 활용한 실시간 브라우저 질문 응답 AI를 구축했습니다. 브라우저 서칭 중 Chat GPT에게 물어보고 싶은 부분이 생기면 해당 부분을 복사-붙여넣기 해서 프롬프트를 만들어야 하는 번거로움이 있었습니다. 이러한 문제를 해결하고자 동영상과 같이 브라우저에서 드래그만하면 바로 GPT에게 물어볼 수 있는 서비스를 구현해 보았습니다.

해당 프로젝트에서 가장 큰 문제점이 서버 리소스의 한계 였습니다. 실제로 AI 모델을 서버에 올려 배포하는 것을 배워보고 싶었었습니다.
그러나 모델이 서버에서 작동하기 위해서는 최소한의 GPU 리소스가 있는 서버를 빌려야 했습니다. 그러나 그런 컴퓨팅 파워를 가진 것들은 너무 비싸다는 문제가 있었습니다. 이를 해결하기 위해서 최대한 API를 사용하여 모델을 서버에서 작동 될 필요 없게 구현을 해보았습니다.