RAG의 짧은 역사 훑어보기(첫 논문부터 최근 동향까지)
해당 글은 필자의 블로그에 이미 발간된 글입니다.
[요약]
- RAG는 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks(2020)에서 처음 등장하였고 모델과 Retriever을 학습시키는데 사용되었다.
- 최근 RAG는 모델의 학습이 아닌 모델의 Inference 성능을 레버리지하기 위해 주로 사용되고 있다.
- RAG는 문서를 어떻게 잘 검색해서 가져오고 LLM에 잘 넘겨주는지 중요하다.
- RAG를 도와주는 구글의 Vertex AI는 문서 검색에 벡터 검색뿐만 아니라 전통적인 Keyword 검색도 이용하고, LLM reasoning로 쿼리를 확장한다.
들어가며
ChatGPT가 등장한 것이 22년 11월이니 대중들에게도 LLM이 친숙한 단어가 된 지 오랜 시간이 지났다. 그 사이 많은 기업들이 좋은 LLM을 만들고 활용하기 위해 노력을 기울였다.
RAG는 LLM을 더 잘 활용하기 위한 기법이다. LLM은 학습한 시점 이후의 데이터가 없기 때문에 outdate된 정보를 줄 수 있고, domain specific한 지식이 부족한 단점이 있다. 주기적으로 LLM을 재학습시키면 되겠지만 이는 무척 비용이 크다. RAG는 LLM에 쿼리를 넘겨줄 때 데이터베이스에서 관련 정보를 찾아 같이 넘겨주면서 이를 극복한다.
이번 글에서는 RAG라는 용어가 처음 등장한 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks(2020)을 살펴볼 것이다. 그리고 Survey 논문(2023)을 참고하여 최근 RAG는 어떻게 발전되고 있는지 알아보고 필자가 인상깊게 본 구글의 Vertex AI를 간략하게 소개하고자 한다.
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks(2020)
RAG 용어가 처음 등장한 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks(2020)를 간단하게 살펴보자.
1) Overview
이 논문에서 제시한 RAG 모델은 크게 Retriever와 Generator로 구성된다.
Retriever은 위키피디아와 같은 데이터셋으로부터 쿼리에 알맞은 문서(latent documents)들을 가져온다(검색한다). 이때 데이터셋은 vector index를 가지고 있어 pretrained retriever가 문서를 가져올 수 있다.
Generator는 쿼리와 Retriever가 구한 문서들을 같이 받아 output을 생성한다. 이 논문에서는 Encoder-Decoder 모델인 BART를 사용하였다.
해당 논문에서는 parametric knowledge와 non parametric knowledge라는 용어가 나온다. Parametric knowledge는 모델이 학습한 정보를 말하고 non parametric knowledge는 문서를 가져오는 외부 정보를 말한다.
이 논문에서 실험한 것은 parametric memory를 가진 학습된 모델을 fine tuning할 때 non parametric memory를 활용한 것이다. RAG를 모델 fine tuning의 방법으로 제시한 것으로 볼 수 있다. 이는 우리가 현재 우리가 흔히 알고 있는 RAG와 약간 다르다. 해당 논문이 LLM이 본격적으로 등장하지 않은 2020년에 나왔기 때문에 language model을 학습시키는 방향으로 연구를 진행한 것 같다.
2) Method
Retriever: pretrained된 BERT의 encoder를 활용한 DPR(2019)을 기반으로 하였다.
Generator: pretrained된 BART(2019)를 사용하였다. Generator는 굳이 BART를 쓰지 않아도 되고, encoder-decoder 모델이면 다 가능하다.
논문에서는 RAG의 모델을 두 가지 제시한다.
RAG-Sequence 모델
- 완성된 sequence를 생성하기 위해 같은 문서만을 사용하는 모델이다.
- 각 문서 z마다 beam search를 실행하여 p(yi|x, z, y1:i-1)을 점수를 매긴다.
RAG-Token 모델
- 각 타겟 토큰마다 다른 문서를 사용할 수 있다. Generator가 각 문서에 대해 다음 아웃풋 토큰 분포를 생성한다.
- Standard beam decoder를 사용해 디코딩한다.
위 모델을 조금 설명해보자면 RAG의 모델은 input sequence x로 문서들 z를 얻고, x와 z를 사용해 target sequence y를 생성한다.
retriever은 쿼리 x에 대한 top K개의 문서들을 가져온다.
generator는 이전 i-1개의 토큰들을 보고 새로운 토큰을 생성한다.
수식을 보면 generator가 다음 토큰의 확률을 계산할 때 retriever가 해당 문서를 검색할 확률을 포함시키는 것을 알 수 있다. 이런 식으로 검색한 문서를 latent variable로 활용한다.
앞서 말했듯이 retriever와 generator는 학습 대상이다. 여기서 document encoder를 학습 대상에서 제외하였는데, 주기적으로 문서 인덱스를 업데이트해야해 비용이 크고 성능에도 큰 영향을 주지 않기 때문이다.
3) Experiment
실험 대상 TASK는 다음 4가지다.
Open-domain Question Answering
- question and answer을 input-output text pair로 사용하여 RAG를 학습
Abstractive Question Answering
- RAG의 NLG(natural language generation)를 측정하기 위해 MSMARCO NLG task v2.1 사용
- 해당 MSMARCO task는 question과 gold passage(검색엔진에서 가져온 질문과 관련된 passage) 10개와 해당 passage로부터 가져온 full sentence answer로 구성되어 있음
- 여기서는 passage를 사용하지 않고 QA task로 MSMARCO를 사용. RAG가 외부 DB를 이용하지 않고 reasonable한 response를 만들 수 있는지를 테스트하기 위함(Wikipedia를 사용해도 대답할 수 없는 질문이 존재).
Jeopardy Question Generation
- non QA에 대한 RAG의 생성 능력을 테스트하기 위해 open domain question generation을 공부해봄
- 예를 들어 “The World Cup”은 “In 1986 Mexico scored as the first country to host this international sports competition twice” 질문에 대한 대답
Fact Verification
- Wikipedia로부터 근거를 검색해 해당 claim이 true, false, unverifiable인지 판단
각 task에 대해 non-parametic knowledge source로 위키피디아 dump를 동일하게 사용했고, 각 문서의 embedding으로 FAISS의 HNSW로 MIPS Index를 만들어 수행하였다.
4) Evaluation
Open-domain QA의 경우 SOTA를 보였고, 그 외의 TASK에 대해서도 준수한 성능을 보였다.
여기서 비교군으로 REALM(2020)이 나오는데 문서를 검색해서 모델을 학습시킨 선행 연구이다. REALM과 비교했을 때, document encoder를 학습시키지 않고 마스킹도 하지 않아 비용이 저렴하면서도 비슷하거나 좋은 성능을 냈다는 것에도 의의가 있다.
최근 RAG 동향
Retrieval-Augmented Generation for Large Language Models: A Survey을 참고하였다.
앞서 살펴본 논문은 RAG를 처음 제시하였고 이를 통해 retriever과 generator을 개선하는 것을 목표로 하였다. 위 그림의 분류에서는 Fine-tuning에 해당된다.
하지만 LLM이 유행하면서 RAG를 LLM의 능력을 레버리지하는 inference 단계에서 적용하는 경우가 늘어났다. LLM의 inference 단계에서 RAG를 적용하면 LLM의 단점인 hallucination 및 outdated knowledge를 생성을 완화할 수 있다.
RAG의 단계는 크게 3가지로 나눌 수 있다.
1) Indexing: 문서들을 청크로 분리 및 벡터로 인코딩하여 벡터 데이터베이스에 저장
2) Retrieval: Query와 관련된 Top K개의 chunk를 가져옴
3) Generation: 원본 Query와 Retrieval로 가져온 chunk들을 LLM에 input으로 넣어 최종 답변 생성
RAG 패러다임
해당 Survey 논문에서는 RAG를 3가지 카테고리로 나누었다.
- Naive RAG
- Advanced RAG
- Modular RAG
RAG 연구 자체가 시작된지 얼마 안되었고 Modular RAG는 특히 초기 단계인 것으로 보인다. 기업에서 적용하고 있는 RAG는 Naive RAG 혹은 Advanced RAG가 주이다.
1) Naive RAG
ChatGPT가 광범위하게 사용되면서 같이 널리 사용된 방법이다. Naive RAG는 indexing, retrieval, generation을 포함한 전통적인 방법을 사용한다.
Indexing — PDF, HTML, Word, Markdown 등의 다양한 포맷으로부터 raw data를 추출하고 일관된 text 포맷으로 저장한다. 먼저 text를 더 작고 이해하기 쉬운 chunk들로 쪼개고 이를 임베딩 모델을 통해 vector로 인코딩해 벡터 데이터베이스에 저장한다.
Retrieval — RAG 시스템은 쿼리도 vector로 변환시킨다. 이때 indexing phase에서 사용한 같은 인코딩 모델을 사용한다. 이를 통해 변환된 query 벡터와 indexing 벡터의 similarity score를 계산하여 top K개의 chunk를 가져온다.
Generation — 쿼리와 Retrieval 단계에서 선택된 문서들을 합쳐 프롬프트로 만들고 language model에서 사용한다.
그러나 Naive RAG는 여러 단점들이 존재한다.
- Retrieval Challenges: Retrieval phase에서 정확도(precision) 및 재현율(recall)이 좋지 않아 중요 정보를 빠뜨리는 경우가 있다.
- Generation Difficulties: 여전히 hallucination 이슈가 생길 수 있다.
- Augmentation Hurdles: 다른 종류의 task에서 가져온 Retrieved 정보를 합치는 것이 어려워 LLM에게 좋은 context를 전달하기 힘들다. 예를 들어 문맥이 일치하지 않거나 아예 일관성이 없는 정보가 나올 수도 있고, 중복이 나올 수 있다. 또한 어떤 정보가 중요한지 선택하거나 서로 연관성이 있는 지, 문체나 톤의 일관성을 보장하는 작업 등 복잡한 작업들이 필요합니다.
2) Advanced RAG
Native RAG에서 Retrieval 질을 향상시키기 위해 pre-retrieval과 post-retrieval을 추가로 사용한다.
Pre-retrieval process
- Indexing Structure 개선: enhancing data granularity, optimizing index structure, adding metadata, alignment optimization, mixed retrieval
- Query 최적화: query rewriting transformation, query expansion 등
Post-Retrieval Process
검색한 context들을 query와 효율적으로 합치는 방법을 개선하는 작업이다. LLM의 부하를 줄이기 위해 필수 정보를 선택, 중요 섹션을 강조, context를 요약 작업 등이 있다.
- rerank chunk, context compressing
- Reranking에는 LlamaIndex, LangChain, HayStack 등을 사용한다.
3) Modular RAG
앞선 두 패러다임을 넘어 발전된 adaptability을 제공한다.
similarity search를 위한 검색 모듈을 추가한다던가 fine tuning을 통해 retreiver을 정제한다던가 등의 작업을 “모듈”의 형태 혹은 “패턴”의 형태로 제공하려는 것을 시도하는 것 같다.
초기 연구 단계이고 자세히 살펴볼 만한 부분은 없어 생략하겠다.
RAG에서 중요한 것: Retrieval
RAG는 비용이나 시간적인 문제로 LLM을 Fine tuning하기 어렵기 때문에 선택하는 경우가 많다. 따라서 같은 LLM을 사용하더라도 inference 성능을 잘 레버리지 해야한다.
따라서 RAG에서 통제할 수 있는 것은 Retrieval로 가져오는 문서 뿐이다. 그렇기에 1) 어떻게 문서를 잘 가져올 것이며 2) 가져온 문서들을 쿼리와 조합하여 LLM에 어떻게 넘길 것인지가 중요하다.
문서를 잘 가져오는 방법은 다음과 같은 것들이 있다.
- Data structure: PDF와 같은 semi-structured data나 Knowledge graph 같은 structured data도 data source로 사용할 수 있는지
- Retrieval Granularity: retrieval 단위를 토큰, Phrase, Sentence, Chunk, Document 등 어떻게 잡을지
- Indexing Optimization
- Query Optimization
- Embedding
가져온 문서들을 쿼리와 조합할 때 시도해볼 것은 크게 두 가지가 있다.
첫번째는 문서들을 다시 랭킹(Reranking)하는 것이다. 랭킹 기준에는 전통적인 Rule based 방법인 Relevance나 MRR 등을 사용할 수도 있고 model based인 BERT 등을 사용할 수도 있다.
두번째는 Context에서 중요한 부분만 선택하거나 압축하는 방법이다. LLM도 사람과 비슷하여 처음과 끝에 집중하는 경향이 있다. 그래서 context가 너무 길어지면 중간 정보를 빠뜨리는 문제가 발생한다.
사실 여기서 얘기한 Retrieval을 잘하는 방법들은 이미 검색 관련 분야에서 이미 연구 및 적용 중이다. 그래서 검색의 패러다임이 생성형 검색으로 넘어가도 현재 검색 엔진을 잘하는 기업이 잘할 가능성이 높다는 생각이 든다.
정리하며
RAG를 처음 제시한 논문은 Language model 및 retriever을 학습하는 방법으로 RAG를 제시하였다. 하지만 LLM의 대중화 이후 사람들이 사용하는 RAG의 의미는 LLM의 inference를 레버리지하는 방법으로 굳어지고 있다.
RAG는 1) 문서를 잘 검색하여 2) 원본 query와 함께 LLM에 잘 넣는 것이 중요합니다. 이를 위한 방법으로 Indexing이나 query 최적화, reranking, context 압축 등의 연구가 진행 중이다.
RAG에서 흔히 쓰이는 DB는 Pinecone이나 Milvus와 같은 벡터 데이터베이스이다. 또 Langchain처럼 Retrieval을 구현하기 쉽게 도와주는 framework들도 존재한다.
벡터 데이터베이스에서 Retrieval은 벡터 간 거리를 바탕으로 검색하는 similarity search입니다. 하지만 이는 한계가 있을 수 있다. 예를 들어 새로운 분야에 대해서는 잘 작동하지 않을 수 있고, 금융이나 헬스케어와 같은 산업에서는 정확한 키워드를 기반한 검색 결과가 중요하다.
개발자들의 RAG 구축을 도와주기 위해 만든 구글의 Vertex AI는 벡터 검색의 한계를 극복하기 위해 키워드 검색까지 포함시켜 제공해준다.
키워드 검색 뿐만 아니라 Vertex AI는 LLM reasoning을 통해 기존 쿼리에서 다른 쿼리들로 확장시킨다. 예를 들어 “warm clothing for winter”라는 쿼리가 들어오면 이를 LLM이 “Warm winter jacket”, “Ski clothing”, “Cashmere sweaters” 등으로 쿼리를 생성해 여러 쿼리를 수행한다.
이러한 제품들의 발전 방향을 보면 초기 사람들이 생각했던 구글의 검색 점유율 하락은 앞으로도 크지 않을 것으로 보인다. 여전히 전통적인 문서 검색 방법도 중요하고 계속 쓰일 것이기 때문이다. 앞으로 구글을 비롯한 최고의 검색 기술을 가지고 있는 회사가 어떻게 RAG를 활용할지 지켜보는 것도 재밌을 것 같다.
Reference
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks(2020)
Retrieval-Augmented Generation for Large Language Models: A Survey(2023)
