캐글에서 살펴본 RAG 트렌드 살펴보기 (1)
1등 솔루션에서 살펴본 Lessons Learned points
AI 직군에서 일하고 계신 분들은 캐글(Kaggle)이라는 플랫폼을 다 들어보셨을 겁니다. Kaggle은 전 세계에 있는 ML/AI 직군 사람들이 최고의 AI 모델을 만들면서 경쟁을 하고, dataset과 code를 공유하는 커뮤니티이자 온라인 플랫폼입니다. 최근 1년 동안 자연어처리 관련 대회가 나오질 않다가 하반기에 LLM 관련 대회가 등장하였습니다. 실제로 이 대회에서 많은 사람들은 RAG(Retrieval Augmented Generation) 방식으로 문제를 정의하고 풀어나갔습니다. 한번 살펴보도록 하겠습니다.
1. 대회 소개 - LLM Science Exam
이번에 오픈된 대회는 "LLM Science Exam"이란 주제로 대회(23.7.11~23.10.10)가 열렸습니다.
이 대회는 wikipedia에 있는 STEM(Science, Tech, Engineering, mathematics) 관련 도메인에 특화된 문서와 article을 바탕으로 Q&A 5지선다형 객관식 문제(Multiple Choice)를 푸는 대회입니다.
제시된 train 데이터이며 대회 사람들은 이를 validation data로 접근하여 문제를 풀었다. prompt가 문제를 의미 A~E까지 답안 문제이며 정답이 찍혀있다.또한 Q&A 데이터는 gpt 3.5가 생성한 데이터이고, 평가 metric으로는 MAP@3(데이터의 순위나 추천 목록에서 상위 3개 항목이 얼마나 정확한지 평가하는 방법)입니다.
3달 동안 2,600여 팀이 참가했고 Kaggle 주최대회 취지는 Quantization와 Knowledge distillation 같은 방법을 사용하여 언어모델을 효과적으로 축소하고 더 작은 스펙의 하드웨어에서 도메인에 특화된 문제를 푸는 대회였습니다. 참고로 gpt 3.5(Davinci003)는 parameter 수가 약 175B로 추정이 되고 있고, 대회 당시 kaggle 내에 존재하는 가장 큰 모델은 10B 모델입니다. 가벼운 모델이면서 task에 특화된 모델 아키텍처를 활용해서 문제를 충분히 풀 수 있음을 알 수 있었습니다.
2. RAG(Retrieval Augmented Generation)는 무엇인가?!
RAG를 말 그대로 직역하면, 검색하고 증강하고 생성한다는 소리입니다. 조금만 풀어쓴다면 외부에서 데이터를 검색해서 context를 구성하고 이해한 후 자연어 형태로 생성한다는 뜻입니다. 아래 그림이 RAG를 가장 표현한 그림입니다. (LLM 기반 챗봇 아키텍처입니다. )
LLM based Chatbot to Query Private Knowledge Base, swirlAI그림을 간단하게 설명하면 다음과 같습니다.
검색해서 참고할 문서들(그림에서 Private Konwlege Base)을 잘게 쪼개어(chunk) 이를 임베딩 및 인덱싱(그림에서 ①~③)을 합니다.
그리고 사용자가 검색할 자연어 형태의 쿼리 또한 마찬가지로 임베딩(⑤)을 수행하고 index 참조(⑥)를 합니다.
여기서 Indexing 알고리즘을 통해 가장 가까운 임베딩 벡터(⑦)를 찾습니다.
그 후 내가 질의한 쿼리와 참조한 Context를 결합하여 LLM을 활용하여 자연어 형태로 생성(⑨)합니다.
내가 궁금한 질문이나 문제에 대해서 큰 오픈북 하나를 참조 & 이해하여 자연어 형태로 응답 결과를 얻는 일련의 과정을 RAG라고 생각하시면 됩니다. 이 방식은 Pretrain을 하지 않고 내가 원하는 대답을 받아 볼 수 있는 강점이 있으며 또한 환각 현상을 줄일 수 있는 하나의 방법입니다.
이번 달에 LLM 모델을 사용하거나 긴 Context를 받아들이는 모델을 사용하는 것보다 RAG를 '잘' 사용하는 것이 좋다는 논문이 나왔습니다. 과격하게 표현해 보자면, 무지성으로 많은 데이터를 넣은 것보다 더 좋은 정보의 knowlege를 구축하고 검색과 생성에 초점을 맞춘다면 LLM을 fine-tuning 하는 것보다 효과적인 옵션이 RAG가 될 수 있습니다. 특히 접근하고자 하는 Task가 범용성이 높지 않고 요건이 정해져 있다면 저는 무조건 RAG를 사용할 것 같습니다.
다양한 벤치마크 데이터 셋에서 gpt 3.5 모델보다 작은 모델을 바탕으로 문제를 푸는 것이 성능과 속도 면에서 이점이 있다는 논문이 나오고 있다. 3. 다수 인원들이 생각한 문제 접근 방식 - Open Book Technique
위 내용까지 제대로 읽으셨다면 RAG에 대해서 감을 잡았을 겁니다. 그렇다면 Domain & Task에 특화되어 있는 이 대회에서 많은 사람들은 문제를 어떻게 접근을 했을까요? 대회 대다수 사람들은 RAG로 문제를 풀지는 않았습니다. 아래 그림은 대회 중반에서 대세로 자리매김한 방법인 "Open Book Technique"입니다. 간단하게 그림을 설명하면 모델이 질문에 대답할 때 질문과 wikipedia에서 추출한 관련 정보를 모두 모델에 넣습니다. 그 후 모델은 모든 정보를 사용해서 객관식 답을 "선택"하여 문제를 풉니다.
Made by Chris Deotte여기서 많은 사람들이 고도화하는 영역은 다양했습니다.
Open Book 역할을 하는 wikipedia를 늘리거나 줄이기
NLU 계열 PLM 모델(DeBERTa, Longformer, RoBERTa 등)을 바꾸기
학습 데이터를 늘리거나 다른 외부 QA 데이터를 결합하거나 생성하기
validation 데이터 셋을 늘리고 다양한 validation strategy 구성하기
임베딩 검색하는 모델 변경하고 실험하기
특히 상대적으로 작은 모델(오픈된 Foundation Model에 비해)인 DeBERTa-Large(0.3B) 모델과 오픈북을 결합한 방식으로 MCQ(Multiple Choice Question) Task를 문제해결하는 방식이 대회 내내 강세로 자리 잡고 있었습니다.
4. 대회 1등 팀(Team H2O LLM Studio)의 문제 접근 방식
하지만 Kaggle에 몰입해 보신 분들은 느껴보셨을 겁니다. 금메달 솔루션은 아이디어가 색다르거나, 어느 특정한 부분에 상상도 못 할 만큼 엄청난 공수를 들인 포인트들이 존재합니다. 저는 Kaggle을 2번밖에 참여하지 않았지만 상위권 솔루션을 볼 때마다 느낀 감정은 큰 "벽" 하나가 있다는 것을 느꼈습니다.
이번 대회 1등은 전부 Kaggle 그랜드마스터로 이뤄진 팀이고 H2O.AI(올해에 LLM Studio로 더더욱 유명해졌음)에 재직 중인 사람들로 구성되어 있었습니다. 이 팀이 제일 놀라웠던 포인트는 대회 시작부터 끝까지 1등을 계속 유지했고, Public LB와 Private LB 등수 변동 없이 1등으로 마감했습니다. 회사 이름과 Product 이름 걸고 1등까지 하니 이게 진짜 swag이라고 생각이 들었습니다.
Public과 Private LB끼리 데이터 차이가 20%, 80%이라서 상위권 안에서도 shake-up이 일어났었다. 1등 솔루션의 핵심을 각 영역별로 정리하고 그에 대한 제 생각(또는 대다수 대회에 참가한 사람들의 방식)을 각각 서술하면 다음과 같습니다.
[데이터]
Wikipedia 데이터를 chunk 하고 RAG로 수행하는 것이 큰 컨셉이고 chunk의 길이보다 모델이 받아들일 수 있는 최대 길이에서 나누어서 활용하였다고 합니다. 총 6천만 개의 chunk wiki 데이터를 사용하였고 입력 데이터의 크기는 "2.5TB" 였다고 하네요... → 저는 faiss index를 생성하는데 Memory가 너무 커져서 4.7백만 개까지 데이터를 사용했었습니다. 1등은 faiss를 이용하지 않고 pytorch에서 cosine 유사도를 측정하는 코드를 커스텀해서 사용했다고 언급했습니다.
[임베딩 모델]
임베딩 모델은 MTEB 리더보드(임베딩 모델 벤치마크 리더보드)에서 제일 높은 모델을 고집한 것이 아니고 e5 모델을 활용 → 저희와 다른 상위권에 있는 사람들은 MTEB 리더보드에 있는 상위 모델만을 고집했었습니다. 체감상 이 대회에서는 임베딩 모델은 크게 중요하지 않았던 것 같습니다.
[Foundation 모델]
7B LLM 5개 모델들을 앙상블 수행하였으며, LLM 마다 전부 다른 wiki데이터를 사용하고 chunk와 임베딩 기법을 결합. hyperparameter tuning은 H2O LLM Studio를 사용하였다고 합니다.
[Context의 길이와 위치]
다양하게 실험을 했을 때 최적의 전략으로는 Chunk를 3개로 나누어 학습을 하고 Chunk를 5개로 나누어 Inference를 했다고 합니다. 학습 때 Chunk를 더 늘리면 Context에 더 많은 노이즈가 생기고 시간도 너무 느려지기 때문입니다. 더욱 재미있는 부분은 LLM Studio 팀은 Context의 순서를 뒤집는 것을 시도했을 때, 점수가 급락하는 경험을 했다고 합니다. 이 부분은 모델이 '가장 좋은' 위치에 있는 Context를 학습했다는 의미입니다. → 여태 다양한 프로젝트를 해보면서 Context 앞부분이 좋았던 경험이 많았었습니다. 하지만 이번 사례를 통해 Task와 Domain에 따라 참고하는 Context 위치 부분도 충분히 중요하다는 것을 깨달았습니다.
[Validation Strategy]
200개의 validation 데이터셋을 활용하는 것이 대부분 사람들의 방식이었는데 1등 솔루션에서는 다른 사람이 공유한 6000개의 STEM 문제를 Validation에 활용해서 모델 검증 → 대다수 사람들은 validation 공개된 데이터 셋 200~1000개 데이터 셋만 고집을 했었던 현상이 강했었습니다.
