RAG 시스템

RAG(Retrieval-Augmented Generation)

이번 공약21 프로젝트를 하면서 LLM을 사용해서 사용자에게 더 정확한 후보자의 공약정보를 제공하기 위해 RAG 시스템을 담당하게 됐다. 그렇다면 이 RAG 시스템은 무엇일까?

 

Why RAG?

LLM이 등장한 이후로 많은 사람들이 적극적으로 LLM을 이용해 학습하거나 일을 처리하거나 등의 다양한 작업을 처리한다. 이런 일이 가능한 이유는 LLM을 개발하는 개발사에서 대량의 학습 데이터를 활용해 AI를 학습시켜놓았기 때문이다. 하지만 이러한 학습은 실시간으로 이루어지는 과정이 아니다. 즉, 어제 새로운 정보가 등장했다면 AI는 이 정보에 대한 데이터를 학습하지 못했다는 의미로 사용자의 질문에 답하기 위해서는 외부 검색 등을 통해 그럴듯한 답을 내놓게 된다. 따라서, 그 정보가 정확하지 않지만 사용자에게는 그럴듯한 말로 응답할 수 있게 된다. 이렇게 LLM의 응답에 그럴듯한 거짓말이 포함될 수 있는데 이러한 문제를 할루시네이션(Hallucination) 문제이다.

할루시네이션에 대한 ChatGPT의 설명은 다음과 같다.

 

 

이 글을 작성하고 있는 날(2025-06-16)을 기준으로 봤을 때, 위 답변 또한 할루시네이션 문제가 발생했다는 것을 알 수 있다. 현재 이재명이 대한민국 대통령이기 때문이다.

 

이러한 문제가 일어나지 않으려면 LLM 모델이 당일까지 나온 모든 데이터를 학습해야 하지만 현실적으로 쉽지 않은 일이다. 이것보다 현실적이고 쉬운 방법은 우리가 LLM에게 질문할 때 최신 정보를 함께 제공해서 그 정보를 바탕으로 답변을 생성하도록 만들면 된다. 예를들어, 질문이 "대한민국 대통령이 누구야?" 일 때, "2025년 6월 3일에 대한민국 대통령으로 이재명 후보 당선" 이라는 정보를 함께 제공한다면 LLM은 사용자가 제공한 정보를 바탕으로 정확한 답변을 생성할 수 있게 될 것이다. 이것이 RAG이다.

 

 

RAG 과정

앞서 이야기했듯 쉽게 요약하면 LLM에게 질문할 때 질문과 유사한 정보들을 함께 제공해 LLM이 해당 정보를 바탕으로 정확도 높은 답변을 생성하도록 하는 방법이다. 전체적인 개념은 쉬워보일 수 있지만 이를 위해서는 많은 과정을 거쳐야 한다.

• 일단 질문과 유사한 많은 정보들을 확보해야 한다.
• PDF, 이미지 등과 같은 많은 정보를 읽을 수 있는 텍스트로 바꿔 저장해야 한다.
• 이때, 많은 정보들 사이에서 유사한 정보를 검색할 수 있도록 정보를 저장해야 한다.
• 정보를 저장한 데이터베이스에서 질문과 유사한 정보를 검색해 LLM에게 질문할 프롬프트를 만든다.
• 프롬프트를 사용해 LLM에게 질문하여 정확도 높은 응답을 생성한다.

공약21 서비스를 예로 들어 설명하자면,

• 각 후보자가 제공하는 사이트 이미지 혹은 정당에서 제공하는 PDF 정책공약집 등의 정책 공약 데이터를 확보한다.
• 이미지와 PDF 공약집을 다양한 방법으로 텍스트로 바꾼다.
• 유사한 정보를 검색할 수 있도록 위에서 바꾼 텍스트를 벡터화해 벡터저장소에 저장한다.
• 사용자의 질문이 들어오면, 사용자의 질문을 벡터화한 후 벡터 저장소에서 유사도가 높은 정보를 검색한다.
• 검색된 정보들을 사용해 프롬프트를 만들어 LLM에 질문해 응답을 생성한다.

전처리

위의 과정에서 데이터 확보 과정을 제외한 후 정보를 벡터화해 벡터저장소에 저장하기까지의 과정을 전처리 단계라고 볼 수 있다. 전처리 과정을 좀 더 일반화해 보면 다음과 같다. 전처리 과정은 시스템 개발에서 한 번만 수행해 놓으면 되고 이후에 실제 서비스에서는 실행 단계만 수행하게 된다.

 

위 과정은 유튜브 테디노트님의 [EP01. #RAG의 동작 과정 쉽게 이해하기!] 을 참고했다.

 

1. LOAD

데이터를 저장하기 위해 데이터를 로드하는 단계이다.

1-1. EXTRACT

LOAD되는 데이터의 형식은 이미지, PDF, JSON 파일 등의 다양한 형식이 될 수 있다. 이 때, 이미지나 PDF와 같이 일반적으로 텍스트를 얻을 수 없을 경우 OCR이나 파이썬 패키지 등을 사용해 파일에 포함된 텍스트 데이터를 추출해야 한다.

 

2. SPLIT

스플릿 단계는 데이터를 쪼개는 단계이다. 당연하겠지만 데이터를 쪼개는 이유는 응답의 정확도를 높이기 위함이다. 기본적으로 LLM에게 질문을 할 때, 질문의 길이에 제한이 걸려있다. 제한된 길이 안에 최대한 유사한 정보를 많이 포함시킬 수록 더 정확한 응답을 기대할 수 있게 된다. 이를 위해 전체 데이터를 여러 부분으로 쪼개 저장해 검색을 통해 최대한 많은 유사 정보를 포함시키게 하기 위함이다.

공약21 서비스를 예를 들면, 한 정당에서 내놓은 정책 공약집은 전체 219 페이지의 PDF로 이루어져 있다. 하지만 어떤 사용자는 청년 정책에 대해서만 궁금하다면 219 페이지의 모든 내용을 포함시킬 필요 없이(물론, 제한된 길이로 포함되지 않는다.) 최대한 청년 정책과 관련된 부분만 포함시켜 응답의 정확도를 높일 수 있다.

 

SPLIT을 통해 LLM 사용의 비용도 줄일 수 있다. 만약, LLM의 API를 활용하는 방식으로 사용한다면 사용 요금은 프롬프트에 포함된 전체 텍스트를 토큰으로 계산해 토큰의 수에 따라 요금이 책정된다. SPLIT을 통해 필요한 일부분만 프롬프트에 포함시킨다면 불필요한 토큰이 생기지 않으니 비용을 절감하는 효과도 얻을 수 있다.

 

SPLIT은 지정한 청크(Chunk) 사이즈 별로 쪼갤 수도 있고 이미지별, 페이지별 등 개발자가 원하는 대로 쪼갤 수 있다. 공약21 서비스 같은 경우 데이터의 출처를 이미지로 제공하는 기능이 있어 이미지별로, PDF는 각 페이지별로 쪼개 저장했다.

 

3. EMBED

RAG 시스템의 핵심적인 부분 중 하나로 유사도가 높은 정보를 검색하기 위해 텍스트를 벡터화하는 과정을 말한다. 텍스트 데이터는 사람이 읽을 수 있는 언어이다. 컴퓨터는 두 텍스트를 보고 유사한지 유사하지 않은지 판별하지 못한다. 이를 위해, 기계가 이해할 수 있는 형태로 변환하는 것이 EMBED 과정이다. EMBED를 거치게 되면 텍스트가 수치 배열 형태로 변환된다. 이러한 변환을 위해 다양한 Embedding Model을 활용하게 된다.

before: 경제
after:
[0.013278605416417122,-0.042865071445703506,-0.05450064316391945, ...]

 

이 후에 검색 시 질문의 벡터값과 벡터 저장소에 저장된 벡터값을 사용해 유사도를 계산해 높은 정보를 뽑아내게 된다.

 

4. STORE

전처리의 마지막 단계로 EMBED의 결과를 저장소에 저장하는 단계이다. 이때 저장소는 일반 DB와 다른 임베딩 벡터를 저장하는 방식의 벡터저장소를 사용하게 되며 벡터저장소는 검색 시 유사성을 기반으로 검색하게 된다. 대표적으로 `Faiss`, `Chroma` 등이 있으며 일반 DB이지만 벡터 검색기능을 지원하는 `Redis`를 사용할 수도 있다.

 

실행 단계

실행 단계는 전처리 과정보다 간단하다. 벡터저장소에서 사용자의 질문과 유사한 데이터를 검색해 프롬프트를 만들고 이를 통해 LLM으로 응답을 생성하기만 하면 된다. 유사한 데이터를 검색하는 것도 벡터저장소가 해주기 때문에 구현이 훨씬 간단하다.

 

 

1. QUESTION

사용자가 질문을 단계이다.

 

2. RETRIEVE

사용자의 질문을 기반으로 벡터저장소에서 유사한 정보를 검색한다. 하지만 이때, 주의해야할 것은 사용자의 질문 또한 EMBED 과정을 거쳐야 한다는 것이다. EMBED 과정을 거쳐 변환된 벡터 배열을 사용해 벡터저장소에 저장된 벡터 배열과의 유사도를 계산하기 때문이다. 벡터저장소는 질문 벡터 배열과 저장된 데이터의 벡터 배열들의 유사도를 계산해 가장 높은 K개의 정보를 반환한다.

 

3. LLM

이제 질문과 함께 벡터저장소에서 검색한 질문과 유사도가 높은 정보를 포함해 프롬프트를 만든다. 프롬프트라는 것은 LLM에게 요청할 때 작성하는 질문 부분이라고 생각하면 된다. 예를들어, ChatGPT에 "대한민국 대통령이 누구야?" 라고 질문한다면 "대한민국 대통령이 누구야?"이 프롬프트가 된다. RAG에서는 질문과 유사한 정보가 함께 포함되어 프롬프트가 만들어진다.

 

4. ANSWER

LLM은 사용자의 질문과 함께 제공되어진 데이터를 분석해 정확도가 높은 응답을 생성해주게 된다.

 

RAG의 장단점

장점

• 지식 최신화
• 정확도 향상
• 출처 기반 응답
• 도메인 특화 대응
• 모델 경량화

 

LLM은 모델마다 특정 날짜까지의 데이터만 학습되어 있어 최신 데이터에는 취약할 수 밖에 없다. 하지만 위에서 계속 봐왔듯, RAG는 개발자가 필요한 데이터(외부 데이터)를 프롬프트에 포함시키는 방법이기 때문에 LLM이 최신 데이터를 기반으로 답변을 생성할 수 있게 되고 그만큼 정확도 또한 높아진다.

일반적인 정보를 다루는 것이 아닌 공약21 서비스처럼 후보자 공약뿐만 아니라 법률, 기업 내부 문서 등 특정 도메인에 관련된 LLM 서비스를 만들 수 있게 되며, LLM을 학습시키는 방식이 아니라 검색으로 지식을 확장하기 때문에 LLM 파인튜닝이 불필요해 LLM을 작게 유지할 수 있다.

 

단점

• 구현 복잡도
• 질문-문서 매칭 실패 가능성
• 성능 비용 문제
• 정답 보장이 아님

 

실행 단계는 비교적 구현이 간단하지만 전처리 단계는 생각보다 구현이 복잡해질 수 있다. 공약21 서비스를 개발하면서도 가장 많은 시간을 사용하게 된 것이 전처리 과정이었다. 전처리를 대충하게 되면 임베딩이 부정확하거나 저장소에서 핵심 문서를 검색하지 못할 수 있게 된다. 검색된 문서조차 정확하지 않을 수도 있어 결과적으로 부정확한 응답이 생성될 가능성이 존재한다.

또한, 서버에서 LLM을 직접 사용한다면 검색과 생성이 동시에 일어나기 때문에 응답 처리 시간과 비용이 증가할 수 있으며 이를 위해 충분한 하드웨어 스펙이 필요하다. 공약21은 예산이 없어 저스펙의 서버를 사용했기 때문에 서버 내에서 검색한 후 프롬프트를 만들어 구글 Gemini API를 사용하는 방식으로 진행했다.