RAG를 그대로 해석해보자면 검색 증강 생성이다. 그 말 그대로 생각을 해보자면 검색을 하여 증강된 생성을 한다. 라는 의미를 가진다. RAG는 LLM을 활용한 응답에 미리 별도로 학습을 시켜놓은 데이터 베이스를 참조하도록 하는 프로세스이다.
LLM(Large Language Model) 즉 대규모 언어 모델은 이름과 동일하게 방대한 양의 데이터를 기반으로 학습되고, 수십억 개의 매개 변수를 활용하여 질문에 답변하여 문맥의 파악을 통해 번역, 문장 생성 등의 작업을 진행한다.
하지만 LLM에서도 명확한 한계는 존재한다.
위의 2가지의 한계를 해결해주기 위한 해결책 중 하나가 RAG이다.
외부 데이터는 LLM의 원래 학습 데이터 세트에 포함되어 있지 않은 외부에 있는 새 데이터를 말한다. 예로 LLM이 발표된 뒤에 발표된 새로운 핸드폰 모델의 사용 설명서, 영화 줄거리, 보안 문제로 LLM에 학습시키지 못한 회사 내부 규정 등을 들 수 있다.
외부 데이터들은 다양한 형태로 존재할 수 있으며, 임베딩 언어 모델을 통해 데이터들을 일련의 수치로 변환을 하는 과정을 거쳐 유사도를 판단하기 위한 벡터 데이터베이스로 저장한다. 저장된 벡터 데이터베이스를 통해 LLM이 답변할 때 사용하는 문맥을 생성한다.
벡터 데이터베이스
벡터 데이터 베이스는 텍스트, 이미지, 오디오 등 모든 데이터들을 일련의 수치로 변환(임베딩)하여 벡터값을 가지도록 변환해 가지고 있는 데이터 베이스이다.
해당 벡터들은 일종의 의미적 유사도를 나타내어, 새로운 데이터(텍스트, 이미지, 오디오 등)를 동일한 벡터 형식으로 변환하여 기존에 저장된 데이터와 유사도를 판단할 수 있다.데이터를 수치로 변환하기 전 데이터는 보통 청킹(Chunking)이라는 과정을 거친다.
청킹(Chunking)
청킹은 문서나 데이터를 작은 단위(청크)로 나누는 과정이다. 청킹을 진행하는 이유는 다음과 같다.
- 효율적 검색
질문, 쿼리들은 특정한 주제나 문맥에 대한 정보를 요구하는데, 큰 데이터 전체를 검색하면 쿼리에 맞지 않는 불필요한 부분이 포함되어 정확도가 낮아질 수 있다. 이때 청킹을 진행하여 정확도를 높이고 검색 시간을 낮춰 효율성을 높일 수 있다.
- 임베딩 모델 한계
데이터를 벡터값으로 변경시켜주는 임베딩 모델들은 대부분 8000Token까지만 임베딩 기능을 지원하기 때문에 청킹을 진행하여 Token 수를 줄여줘야 임베딩을 진행할 수 있는 경우가 많다.
- 메모리 및 성능 최적화
벡터 데이터 베이스에 큰 문서를 그대로 저장하면 검색 속도가 현저히 낮아질 수 있다. 이를 작은 청크 단위로 저장한다면 한번에 검색하는 양이 낮아 메모리 사용량도 줄고 검색 속도도 높일 수 있다.청킹의 종류
청킹의 방식에는 다양한 방식이 존재한다. 어떻게 청킹을 진행하느냐에 따라서 RAG의 성능이 크게 차이날 수 있다.
문장 단위
단순하게 문장 단위로 쪼개는 방식이다.
- 장점
간단하고 직관적이다.
문장 단위는 특정 문맥을 포함하고 있기 때문에 사용자가 원하는 정보를 명확하게 제공할 수 있다.
문맥단위로 끊기기 때문에 앞의 내용이 중복되어 저장될 필요가 없다.- 단점
단일 문장으로는 전체적인 문맥을 파악하기 어렵다.
전체적인 문맥을 파악해야 하는 질문에 연결되기 어렵다.문단 단위
단순히 문서를 단락 단위로 나누는 방식이다. 각 단락은 하나의 주제를 다루는 경우가 많기 때문에 문맥 유지에 유리하다.
- 장점
단락은 일반적으로 하나의 주제를 다루므로, 문맥적으로 완결된 정보를 제공한다.
질문에 대해 더 구체적이고 풍부한 정보를 제공할 가능성이 높다.
대부분의 단락은 적절한 크기로 구성되어 있어 추가 조정이 필요하지 않다.- 단점
단락의 길이가 문서마다 다를 수 있어, 벡터화 과정에서 크기 불균형 문제가 발생할 수 있다.
긴 단락은 일부 모델의 입력 토큰 제한을 초과할 가능성이 있다.고정 길이 단위
특정 Token 단위 기준으로 나누어 LLM과의 호환성을 높이는 방식이다.
- 장점
LLM의 토큰 제한을 명확히 고려할 수 있다.
모든 청크가 모델 입력 크기에 적합하게 나뉘므로 안정적인 벡터화 가능하다.
청킹 기준이 명확하고 일관적이며, 모든 데이터에 동일한 방식으로 적용 가능하다.
크기가 균일하므로 검색 속도가 일정하게 유지된다.- 단점
길이 기준으로 자르다 보면 문장이나 단락이 잘려 문맥이 끊길 수 있다. (때문에 Overlap을 통해 앞의 내용을 추가해놓는 방법을 사용한다.)
청크 내 정보가 완전하지 않을 경우, 추가 청크를 검색해야 하는 번거로움이 있다.의미 기반 단위
의미적으로 연관된 문장, 문단을 하나의 청크로 묶어 문맥을 유지하는 방식이다.
장점
청크 단위가 의미적으로 완결되어 있어, 질의와 관련된 정보를 정확히 검색한다.
동일 주제를 가진 문장들을 묶어 문맥적으로 완전한 청크를 생성한다.
검색 결과가 의미적으로 완결된 응답을 제공하므로 사용자 만족도가 높다.단점
임베딩 모델, 클러스터링 알고리즘 등 추가적인 기술이 필요하다.
의미 분석 및 군집화를 수행하기 위해 더 많은 계산 자원이 필요하다.
의미적으로 묶이는 기준이 완전히 일관되지 않을 수 있어, 예기치 않은 결과를 초래할 가능성이 있다.
완벽하게 의미 기반으로 나누기 위해선 도메인 지식이 필요한 경우가 있다.
벡터 데이터베이스로 저장된 외부 데이터는 LLM의 답변을 강화하는데 사용된다. 서비스 사용자가 남긴 질문은 다시 벡터 표현으로 변환되어, 벡터 데이터베이스와 매칭된다. 예를 들어 "2024년 삼성의 마지막 출시 핸드폰 기종이 뭐야?" 라고 검색한다면 벡터의 유사도를 활용하여 유사도가 높은 내용을 검색한다.
RAG 모델이 벡터 데이터베이스를 거쳐 나온 강화된 문맥을 다시 LLM으로 물어보기 전에, 서비스 사용자가 원할만한 형식으로 답변할 수 있도록 쿼리에 프롬프팅을 적용하여 생성한다. 예를 들어 벡터 데이터베이스에서 찾지 못한 정보는 없다고 설명하라고 한다면, Hallucination을 없앨 수 있다.

RAG를 활용한 답변은 위의 과정을 거쳐 작동한다.
그럼 여기서 드는 의문이 있을 것이다. 왜 LLM에 추가적인 Fine-Tuning을 진행하지 않고 별도의 데이터베이스를 만드는 작업을 진행하는가?
LLM의 Fine-Tuning은 새로운 데이터를 모델에 반영하기 위해 모델 전체를 학습시켜야 한다. LLM은 대규모 언어 모델인 만큼 한번에 학습 시킬 때 많은 비용과 시간이 발생한다. 시시각각 변하는 데이터들(새로운 핸드폰 출시, 신규 법령 발효 등)을 모두 적용하려면 지속적인 모델의 학습이 필요해 엄청난 비용이 발생한다.
하지만 RAG는 필요한 최신 정보에 대한 데이터를 별도로 데이터 베이스화 시켜놓고 가져다 사용하기만 하면 되기 때문에 모델을 학습시키는 부담이 덜하다.
위와 비슷한 내용이지만, LLM에 필요한 도메인의 세부 데이터들을 전부 학습시킨다면 모델의 크기가 더 커질 것이다. 이렇게 된다면 LLM은 추론하는 비용이 크게 증가해 성능 저하가 발생한다.
하지만 RAG를 활용한다면 LLM은 언어 처리 능력만 빠르게 구현하면 되기 때문에 좀 더 효율 좋게 활용할 수 있다.
위에서도 언급한 것처럼 AI가 지켜야하는 가장 중요한 요소 중에 하나는 법과 윤리가 존재한다. LLM이 회사의 보안 요소들까지 전부 학습한다면 회사 보안요소가 유출될 가능성이 존재한다.
하지만 RAG를 활용한다면 단순히 LLM은 언어 모델의 역할만 진행하기 때문에 학습된 벡터 데이터 베이스의 관리만 잘 수행한다면 문제가 발생하지 않아, 보안성이 좋다.
RAG를 활용하여 새로운 도메인을 위한 모델을 만든다면 간단하게 학습되었던 외부 데이터만 변경하여 활용하면 된다.
LLM은 새로운 도메인을 위해 학습을 진행한다면 또 막대한 비용과 시간이 발생할 수 있다.
LLM은 학습을 시키는 데 막대한 비용이 들기 때문에 실시간으로 데이터를 학습시키지 못하여 최신 데이터를 활용하지 못한다.
하지만 RAG의 외부 데이터를 실시간으로 업데이트하도록 만든다면 최신 데이터를 바로바로 확인할 수 있다.