RAG 아키텍처란 무엇인가? 상세한 실제 예시와 함께 보는 완벽한 정의

RAG(검색 증강 생성, retrieval augmented generation)는 LLM이 외부 정보를 활용해 출력을 확장하고 개선하는 프로세스입니다. RAG 아키텍처는 RAG를 가능하게 하는 구성 요소와 그 연결의 집합입니다.

RAG에는 여러 범주가 있으며, 각각 고유한 아키텍처를 기반으로 작동합니다. 본질적으로 RAG 시스템의 아키텍처는 정보가 저장되고, 검색되고, LLM에 전달되는 고유한 방식을 결정합니다.

RAG 아키텍처란 무엇인가요?

RAG 아키텍처는 특정 RAG 시스템을 구동하는 구성 요소(및 관련 기능)의 기본 구성입니다. 이러한 아키텍처는 모두 흔히 ‘단순(simple)’ RAG 또는 ‘나이브(naive)’ RAG라고 불리는 기본 템플릿을 토대로 합니다.

기본 RAG 아키텍처의 개요는 다음과 같습니다.

• 정보 소스: 외부 정보가 저장되는 곳입니다. 검색 인덱스일 수도 있고, 대량의 정보를 표현하는 벡터 데이터베이스나 원시 문서 저장소일 수도 있습니다.
• 검색 구성 요소: 정보 소스에 쿼리를 보내는 메커니즘입니다. 예를 들어 RAG 시스템은 간단한 키워드 검색으로 관련 텍스트 청크를 찾거나, 보다 복잡한 벡터 쿼리로 유사도 검색을 수행할 수 있습니다.
• 오케스트레이션 구성 요소: 이 계층은 LLM 기반 애플리케이션에서 사용자 프롬프트에 대해 RAG 파이프라인을 시작하는 부분으로, LLM과 함께 또는 독립적으로 작동합니다. 또한 검색된 정보를 취합해 확장된 프롬프트로 구성합니다.

RAG 아키텍처의 구성 요소는 보통 두 가지 경로로 구성됩니다. 수집 경로는 데이터를 받아 검색 가능한 정보 소스로 정리합니다. 대량의 텍스트를 검색 가능한 벡터 임베딩 저장소로 변환하는 벡터 데이터베이스는 가장 널리 쓰이는 애플리케이션 중 하나입니다.

검색 경로는 사용자의 프롬프트를 받아 정보 소스를 검색할 쿼리를 생성합니다. 그런 다음 오케스트레이터가 검색된 정보를 LLM의 컨텍스트 입력에 추가합니다. 에이전틱 RAG 및 하이브리드 RAG 아키텍처에는 여러 검색 경로가 있을 수 있습니다.

RAG 아키텍처의 유형

RAG를 완전히 별개의 아키텍처로 구분해 생각하는 것은 오해의 소지가 있습니다. 대부분의 엔지니어는 모듈식 접근 방식을 택해 특정 사용 사례에 맞게 개별 구성 요소를 구현합니다. 대략적인 경계를 그을 수는 있지만, 아키텍처 모델 간에 상당한 중복이 있다는 점에 유의해야 합니다.

1. 기본 RAG

‘나이브’ RAG 또는 ‘단순’ RAG라고도 불리는 기본 RAG는 다른 유형의 RAG를 위한 아키텍처 템플릿입니다.

기본 프로세스는 비교적 간단합니다. 사용자가 프롬프트를 입력하면, 오케스트레이터가 (독립적으로 또는 LLM과 함께) 외부 정보가 필요한지 판단하고, 그에 따라 검색 쿼리를 작성해 전송합니다.

외부 정보 소스는 일반적으로 벡터 데이터베이스이지만, SQL 데이터베이스, 웹 API, 지식 그래프, 심지어 ‘원시’ 문서 저장소일 수도 있습니다. 이렇게 확보한 추가 정보는 LLM의 입력 컨텍스트에 더해집니다.

SQL 쿼리와 API 외에, 검색 방식은 크게 두 가지 유형으로 나뉩니다.

• 어휘 검색(키워드 검색): 사용자 쿼리에서 키워드를 추출하고, 해당 키워드가 포함된 텍스트 구절과 매칭하는 단순한 형태의 RAG입니다. 최신 파이프라인에서는 오케스트레이터가 이를 위해 의미를 포착하지 않는 이른바 희소 벡터 쿼리를 수행하기도 합니다.
• 밀집 벡터 검색(시맨틱 검색): 밀집 벡터 임베딩은 의미를 포착합니다. 오케스트레이터는 사용자 프롬프트와 소스 정보 양쪽의 의미를 모두 포착할 수 있는 방식으로 밀집 벡터 데이터베이스에 쿼리할 수 있습니다.

메모리 활용 역시 RAG 아키텍처의 중요한 부분입니다. 이는 LLM이 이전 채팅의 컨텍스트를 사용해 검색 쿼리를 작성함으로써, 해당 쿼리를 대화(또는 여러 대화)의 더 넓은 맥락에 기반하게 하는 방식을 말합니다. 대부분의 챗봇에서는 대화형 RAG가 일반적이지만, 지원 티켓 응답과 같은 일부 사용 사례에서는 단일 질문 RAG를 사용하기도 합니다.

2. 하이브리드

하이브리드 RAG는 서로 다른 두 가지 유형의 검색, 주로 키워드 검색과 시맨틱 검색을 결합합니다. 키워드 검색은 일치하는 용어를 찾고, 벡터 기반 검색은 관련된 의미를 지닌 구절을 찾습니다.

지식 그래프 탐색이나 SQL 데이터베이스 쿼리 같은 다른 형태의 검색이 사용될 수도 있습니다. 이 프로세스는 프로그래밍된 규칙이나 모델의 질문 분류 같은 라우팅 로직에 따라 진행되는 경우가 많습니다(여러 파이프라인을 동시에 실행할 수도 있습니다).

오케스트레이터는 결과를 병합하고, LLM에 전달하기 전에 재순위화(reranking)를 수행할 수 있습니다. 재순위화는 검색된 청크에 관련성 점수를 부여해 LLM이 가장 적합한 정보를 우선적으로 고려하도록 하는 프로세스입니다.

3. 적응형 RAG

적응형 RAG에서는 라우팅 구성 요소가 사용자 프롬프트의 요구 사항에 따라 검색 전략을 선택하고, 오케스트레이터가 선택된 워크플로우를 실행합니다.

원래 프레임워크(Adaptive-RAG)에서는 더 작은 모델이 분류기 역할을 하여 검색 없음, 단일 단계 검색, 다단계 검색 중 하나를 선택했습니다. 현재 일부 아키텍처는 그 대신 생성형 모델이나 규칙 기반 휴리스틱을 사용합니다.

이 아키텍처는 프롬프트의 복잡성과 요구 사항에 따라 처리 능력을 할당해 단순한 프롬프트에 대한 불필요한 검색 단계를 줄여 주기 때문에 널리 사용됩니다. 다양한 유형의 질문을 처리하는 어시스턴트에서 흔히 볼 수 있습니다.

4. 교정형 RAG(CRAG)

교정형 RAG는 검색된 정보를 LLM의 컨텍스트 입력에 추가하기 전에 평가합니다. 검색 평가기가 검색된 정보가 관련성이 있고 유용한지 판단합니다. 이 아키텍처의 고유한 특징은 답변 생성 전에 명시적인 평가 및 교정 단계가 있다는 점입니다.

정보가 불완전하거나 프롬프트에 적합하지 않은 것으로 판단되면 추가 요청이 실행됩니다. 이러한 요청에는 웹 검색이나 지식 그래프 탐색처럼 원래 요청에 사용된 것과 다른 검색 방식이 포함될 수 있습니다.

교정형 RAG는 의학이나 법률처럼 정확성이 중요한 분야에서 흔히 사용됩니다. 다만 원래 검색된 구절을 보완할 수 있는 추가 정보 소스가 필요합니다.

5. Self-RAG

Self-RAG에서는 모델이 초기 컨텍스트 입력을 받은 후 직접 요청을 시작할 수 있습니다. 생성된 답변은 리플렉션 토큰을 사용해 검색된 근거와 대조하여 평가되며, 필요에 따라 오케스트레이터를 통해 추가 요청이 전송됩니다. 반대로 LLM이 검색이 전혀 필요하지 않다고 판단할 수도 있습니다.

교정형 RAG와 다른 점은 LLM이 자체 출력을 판단하고, 검색이 필요한지와 검색된 텍스트가 유용한지를 결정하며, 자신의 답변을 모니터링하고 필요에 따라 수정한다는 것입니다. 반면 교정형 RAG는 생성 전에 검색된 정보의 품질을 평가합니다.

이 아키텍처는 복잡한 심층 리서치 스타일의 프롬프트에 특히 유용합니다. (검색된 정보의) 관련성 평가를 답변 생성에 통합하기 때문에, 근거 기반 응답이 필요한 프롬프트에 적합한 선택지입니다.

6. 에이전틱 RAG

에이전틱 RAG는 에이전틱 플랫폼의 맥락에서 실행되는 모든 형태의 RAG를 의미합니다. 모델은 추론 능력을 활용해 필요한 정보 유형을 판단하고, 사용 가능한 검색 옵션 중에서 선택합니다.

검색은 필요에 따라 여러 번 실행될 수 있으며, 모델은 더 복잡한 쿼리에 에이전트를 할당할 수도 있습니다. 예를 들어 LLM은 데이터베이스 조회를 요청해 공급업체를 식별하고, 문서 검색을 실행해 관련 계약서를 찾은 다음, 마지막으로 웹 검색을 통해 공개 소스로 연락처 정보를 확인할 수 있습니다.

에이전틱 RAG는 Perplexity, ChatGPT, Claude 등 주요 챗봇에서 사용되는 대표적인 아키텍처 구현 방식입니다. 이러한 플랫폼은 핵심 모델이 여러 도구와 RAG 파이프라인에 접근할 수 있도록 하므로, 모델은 프롬프트에 가장 적합한 검색 형태를 선택할 수 있습니다.

7. 멀티모달 RAG

멀티모달 RAG는 다양한 유형의 미디어에서 컨텍스트를 검색합니다. 차트나 오디오 녹음처럼 다른 방법으로는 접근할 수 없는 정보를 LLM이 활용할 수 있게 해 주기 때문에 중요한 형태의 RAG입니다.

기본 아키텍처는 다른 시스템과 동일합니다. 예를 들어 인덱싱 파이프라인은 이미지 자체를 임베딩으로 직접 변환해 검색할 수 있도록 준비할 수 있습니다. 그러면 에이전틱 RAG 시스템이 이러한 이미지를 의미상 관련된 텍스트와 함께 검색하고, 이를 비전-언어 모델에 전달해 이미지와 텍스트를 함께 처리할 수 있습니다.

8. GraphRAG

GraphRAG는 벡터 검색과 함께 지식 그래프를 사용해 엔티티에 관한 정보를 검색합니다. 일반적으로 오케스트레이터는 키워드 추출 또는 경우에 따라 사전 벡터 검색을 통해 노드라고도 하는 관련 시작 엔티티를 찾습니다. 그런 다음 그래프 검색기가 지식 그래프를 탐색해 더 넓은 컨텍스트를 구축합니다.

예를 들어 특정 제품 카테고리에 대한 상세 분석을 요청받으면, LLM은 벡터 검색을 실행해 특정 엔티티(제품)를 식별할 수 있습니다. 그런 다음 오케스트레이터가 지식 그래프 검색을 실행해 공급업체, 소매 매장, 리뷰 등 관련 엔티티를 찾습니다.

9. 분기형 RAG

하이브리드 RAG 아키텍처가 서로 다른 검색 방식을 사용할 수 있는 것이라면, 분기형 RAG는 브랜치라고 하는 여러 쿼리를 동시에 실행하는 프로세스를 말합니다. 각 브랜치가 별도의 정보 소스에 쿼리하거나, 여러 브랜치가 서로 다른 쿼리나 필터로 동일한 소스에 함께 쿼리할 수 있습니다. 에이전틱 RAG 아키텍처는 분기형 RAG를 자주 사용합니다.

10. HyDE(Hypothetical Document Embeddings, 가상 문서 임베딩)

HyDE는 LLM이 최적의 답변이 어떤 모습일지를 담은 가상의 텍스트 문서를 생성하는 혁신적인 형태의 RAG입니다. 이 ‘가상 문서’는 이후 보다 정확한 검색을 위한 쿼리를 만드는 데 사용됩니다. 관련 지식이 LLM 파라미터에 담겨 있지 않더라도, 답변과 유사한 구절이 짧은 질문이나 모호한 프롬프트보다 관련 문서와 더 잘 매칭될 수 있다는 것이 그 근거입니다.

단순 RAG 아키텍처 예시: 벡터 데이터베이스

기본 RAG는 더 복잡한 유형의 아키텍처의 토대 역할을 합니다. 벡터 데이터베이스를 사용하는 단순 RAG 시스템의 경우, 소스 문서는 더 작은 조각(청크)으로 분할되어 밀집 임베딩으로 변환됩니다. 사용자가 프롬프트를 입력하면 오케스트레이터가 쿼리를 생성하고 인코딩한 뒤, 데이터베이스에 쿼리해 관련 구절을 찾습니다.

프로세스를 단계별로 살펴보면 다음과 같습니다.

1. 자동화된 수집 파이프라인과 BERT 같은 임베딩 모델을 사용해 대량의 텍스트를 벡터로 변환합니다.
2. 데이터베이스 애플리케이션이 빠른 검색을 위해 벡터를 정리하고, 인덱싱하고, 저장합니다.
3. 사용자가 챗봇(예: Perplexity)에 프롬프트를 입력합니다.
4. 애플리케이션 오케스트레이터가 벡터 데이터베이스에서 관련 정보를 검색하기 위해 (임베딩 모델을 사용해) 프롬프트를 인코딩합니다.
5. 벡터 데이터베이스가 관련 청크를 반환하면, 오케스트레이터가 이를 입력 컨텍스트(‘대형 프롬프트’)에 추가해 LLM에 전달합니다.
6. LLM은 추가된 컨텍스트와 (파라미터 가중치에 저장된) 내부 지식을 활용해 답변을 생성합니다.

확대

고급 RAG 아키텍처 예시: 에이전틱 RAG

에이전틱 RAG는 에이전틱 플랫폼 내 RAG 시스템의 기본 아키텍처를 의미합니다. AI 에이전트는 프롬프트의 성격에 따라 다양한 도구와 파이프라인을 호출하고 필요하면 여러 에이전트를 배치할 수 있기 때문에, 에이전틱 RAG 흐름은 복잡해지는 경향이 있습니다.

다음은 이 프로세스의 실제 예시입니다.

1. 사용자가 특정 주제에 대한 심층 리서치가 필요한 복잡한 질문을 입력합니다. 이 예시에서는 프롬프트가 “주요 지정학적 상황을 고려해 향후 6개월간의 기업 실적 전망을 제시해 줘.”라고 가정해 보겠습니다.
2. LLM은 다양한 콘텐츠 유형에 걸쳐 여러 RAG 쿼리를 조합해야 한다고 추론합니다.
3. (a) 벡터 검색, (b) 웹 그라운딩, (c) 이미지(멀티모달) 검색을 위해 세 개의 에이전트가 각각 배치됩니다.
4. 에이전트는 사용 가능한 검색 도구를 사용해 오케스트레이터를 통해 뉴스 기사, 내부 재무 데이터 등 관련 정보를 검색합니다.
5. LLM은 검색된 결과를 각 에이전트의 리서치 질문과 비교하고 관련성에 따라 순위를 매깁니다.
6. LLM은 정보를 평가하고, 정보가 부족한 부분에 대해서는 개별 에이전트를 통해 추가 검색을 실행합니다.
7. 충분한 정보가 검색되면, LLM은 (내부 문서에서 검색한) 기존 재무 수치를 바탕으로 시나리오별 전망을 생성하고, 계산기 도구를 호출해 각 시나리오의 실적을 예측합니다.
8. LLM은 검색된 정보와 계산 결과를 활용해 최종 답변을 생성하고, 필요에 따라 출처를 인용합니다.

확대

RAG의 다음 단계는?

현재의 혁신은 기존 RAG 아키텍처에 깊이와 속도를 더하고, 멀티미디어 검색의 정확도를 높이며, 실시간으로 변하는 최신 정보를 처리하도록 설계된 시스템을 구축하는 데 초점을 맞추고 있습니다.

현재 연구 방향을 이끄는 세 가지 트렌드는 다음과 같습니다.

• 여러 소스에 걸친 심층 리서치: 검색을 계획하고, 서로 다른 여러 소스에 걸쳐 다수의 브랜치를 실행하며, 검색된 근거를 평가하고, 생성된 답변을 스스로 최적화할 수 있는 RAG 아키텍처입니다. 이 모든 작업을 수행할 수 있는 에이전틱 RAG는 계속해서 더 빠르고 비용 효율적으로 발전하고 있습니다.
• 멀티모달 애플리케이션: 검색 파이프라인은 이미지와 동영상을 처리하는 능력이 점점 향상되고 있습니다. 긴 동영상이나 고급 다이어그램처럼 복잡한 멀티모달 데이터에서 특정 유형의 정보를 점점 더 정확하게 찾아낼 수 있습니다.
• 지속적으로 변화하는 정보에 기반한 답변: LLM 기반 애플리케이션은 (동영상 피드, 센서 등) 실시간 정보 소스를 활용해 입력 컨텍스트를 제공할 수 있습니다. 또한 시스템은 GraphRAG처럼 다면적인 정보 네트워크를 생성해 이러한 데이터를 해석할 수도 있습니다.

RAG는 LLM 기반 애플리케이션이 작동하는 방식의 근간입니다. RAG 덕분에 일반 소비자부터 전문 분야의 기업에 이르기까지 다양한 사용자가 할루시네이션, 불완전한 학습 데이터, 전문적인 내부 지식에 대한 접근 부족과 관련된 문제를 극복할 수 있습니다.

그렇기 때문에 RAG 시스템과 그 기반 아키텍처는 AI 연구에서 가장 빠르게 발전하고 가장 흥미로운 분야 중 하나로 꼽힙니다.