왜 RAG가 필요할까?

LLM은 확률 모델로서 다음에 올 가장 적절한 단어를 내밷는 모델이다. 그러나 우리는 LLM을 사용하면서 아래와 같은 문제를 문제를 겪는다.

  1. LLM의 지식은 학습 시점 이후로 업데이트 되지 않는다.
    • 지식 최신성 부족 (knowledge cutoff)
    • 그래서 학습 이후의 변경된 법이나 최근 이슈는 반영되지 않음. knowledge_cutoff
  2. 추론 시, 외부 정보를 직접 조회하지 않는다.
    • 검색 엔진이 아니며, 입력된 정보만을 기반으로 응답한다.
  3. 근거 없는 답변 생성 (hallucination)
    • 확실한 정보가 없을 경우에도 그럴듯한 답변을 생성할 수 있음.
    • 이로인한 사실과 다른 응답(hallucination)이 발생
  4. 도메인 특화 지식에 접근할 수 없음.
    • 사내 문서, 내부 정책, 비공개 데이터 등은 학습 대상이 아님
    • 그래서 “우리 회사 내부 결재 규정에 맞춰 설명해줘” 라고 해도 모델은 “그럴듯한 일반 회사 규정”을 말할 뿐이다.

위의 언급된 LLM의 한계를 보완하기 위해 RAG를 사용한다.

RAG (Retrieval-Augmented Generation)

RAG는 질의 시점에 데이터 베이스나 검색 결과를 조회하고, 해당 내용을 LLM 입력으로 함께 제공해 응답을 생성하는 구조를 말한다. 모든 기술이 시간에 따라 변화하듯, RAG 또한 패러다임이 변하고 있다.

rag

Naive RAG

가장 기본적은 RAG로 주요 구성 요소는 인덱싱(Indexing), 검색(Retrieval), 생성(Generation)이 있다.

  1. 인덱싱 (Indexing)
    검색에 사용할 데이터를 미리 준비하는 단계이다.
    • 문서 로딩 및 정제
      • PDF / HTML / Word 등의 파일을 텍스트로 변환한다.
      • 불필요한 메타데이터나 노이즈를 제거한다.
    • 청크 분할(Chunking)
      • 변환된 텍스트를 일정 길이의 작은 조각으로 나눈다.
      • LLM이 한 번에 처리할 수 있는 문맥 길이에 제한이 있기 때문이다.
    • 임베딩 및 인덱스 생성
      • 각 텍스트 청크를 벡터로 변환한다.
      • 생성된 벡터는 이후 검색 단계에서 질문 벡터와의 유사도 계산에 사용된다.
  2. 검색 (Retrieval)
    사용자 질문과 가장 관련 있는 문서를 찾는 단계이다.
    • 사용자 질문을 벡터로 변환한다.
    • 벡터 DB에서 질문 벡터와 유사한 문서 벡터를 검색한다.
    • 가장 관련도가 높은 텍스트 청크를 선택한다.
  3. 생성 (Generation)
    검색된 문서를 활용해 최종 답변을 생성하는 단계이다.
    • 사용자 질문과 검색된 문서를 함께 프롬프트에 포함한다.
    • LLM은 주어진 문맥을 바탕으로 답변을 생성한다.


하지만 이 구조에도 몇 가지 한계가 존재한다. 😮!


  1. 청킹(Chunking)
    • 초기 RAG에서는 파일 유형의 특성을 고려하지 않고 동일한 청킹 사이즈를 적용했다.
    • 이로 인해 PDF와 같은 비정형 문서에 포함된 이미지, 표, 레이아웃 정보가 손실되는 문제가 발생했다.
    • 특히 표나 이미지에 포함된 핵심 정보는 텍스트 변환 과정에서 제대로 반영되지 않는 경우가 많았다.
  2. 검색 결과 중복
    • 검색 단계에서 유사한 내용을 가진 청크가 중복으로 선택되는 경우가 발생했다.
    • 이로 인해 프롬프트에 동일하거나 유사한 정보가 반복적으로 포함되었고, 결과적으로 LLM이 새로운 정보를 생성하지 못하고 검색 내용을 단순히 반복하는 문제가 나타났다.
  3. 벡터 유사도 기반 검색
    • 벡터 유사도에만 의존할 경우, 의미는 같지만 표현이 다른 문서를 놓칠 수 있다.
    • 반대로 키워드만 유사한 문서가 실제 의도와 무관하게 검색되는 경우도 발생한다.
      • 질문: “RAG 시스템의 문서 검색 방식은?”
      • 문서 A: “RAG에서 문서 검색(retrieval)은 임베딩 기반으로 수행된다.”
      • 문서 B: “회사 내부 문서 검색 기능을 추가했다.”
      • 문서 B는 키워드 유사성 때문에 검색될 수 있지만, 실제 질문과는 무관하다.


Advanced RAG

이러한 Naive RAG의 한계를 보완하기 위한 방법으로 Advanced RAG가 등장했고, RAG 파이프라인을 검색 전 절차(Pre-Retrieval) 와 검색 후 절차(Post-Retrieval) 로 나누어 개선했다.

검색 전 절차 (Pre-Retrieval Process)

검색 전 절차는 데이터 인덱싱과 임베딩 품질을 개선해, 검색 단계에서 관련성 높은 문서를 더 잘 찾는 것에 목적이 있다.

  • 문서 정규화
    • 동일한 개념이라도 표현이 제각각이면 검색 정확도가 떨어진다.
      • 예: LangGraph / Lang Graph / 랭그래프
      • 이러한 용어 모호성(ambiguity)은 벡터 검색의 대표적인 실패 원인이다
    • 이러한 용어 불일치를 줄이기 위해, 검색 전에 문서를 정규화하는 과정이 필요하다.
    • 검색 전에 문서의 오타, 중복 표현, 오래된 정보를 정리한다.
    • 용어집을 정의하거나 메타데이터를 추가해 문서 의미를 명확히 한다.
      • 예: 각 청크에 날짜, 목적, 도메인 정보 등을 포함
  • 하이브리드 검색
    • 정규화된 문서를 단일 벡터 검색에만 의존하면 여전히 한계가 있다.
    • 그래서 단일 벡터 검색에 의존하지 않고 여러 검색 방식을 조합한다.
      • 키워드 기반 검색
      • 의미 기반 검색
      • 벡터 유사도 검색
    • 이를 통해 키워드 매칭 실패나 의미 오탐 문제를 완화할 수 있다.
  • 임베딩 모델
    • 마지막으로, 어떤 임베딩 모델을 사용하는지도 검색 품질에 큰 영향을 준다. 문서 특성과 서비스 요구사항에 따라 적절한 모델을 선택해야 한다.


규모 예시 모델 특징 추천 상황
소형 (100M 이하) bge-small, e5-small, text-embedding-3-small 빠르고 가벼움 실시간 검색, 대량 문서 색인
중형 (300M~1B) bge-base, e5-base, gte-base 속도/성능 균형 대부분의 RAG 서비스
대형 (1B~3B 이상) bge-large, text-embedding-3-large 의미 표현력 우수 복잡한 도메인 문서
초대형 (3B↑) bge-m3, E5-Large-V2 다국어·멀티태스크 연구, 멀티링구얼 시스템

검색 후 절차 (Post-Retrieval Process)

검색 후 절차는 검색된 문서를 그대로 사용하는 대신, LLM 입력에 적합하도록 후처리하는 단계이다.

Re-ranking (재정렬)

  • 벡터 검색(top-k) 결과에는 실제 질문과 관련 없는 문서가 섞일 수 있다.
  • Re-ranker는 질문과 문서 간의 관계를 다시 평가해 순위를 재정렬한다.

예시

  • 질문: “LangGraph에서 Agent node는 어떤 역할을 하나요?”
  • 초기 검색 결과: 설치 방법, RAG 구조, Agent 정의 등

LLM 기반 Re-ranker는 질문과 문서를 함께 비교해 가장 관련성 높은 문서를 선별한다.

Modular RAG

Naive RAG와 Advanced RAG를 거쳐, RAG 파이프라인을 더 유연하게 구성하기 위한 접근으로 Modular RAG가 등장했다. Modular RAG는 RAG를 하나의 고정된 흐름이 아니라, 기능 단위로 분리된 모듈들의 조합으로 구성하는 방식이다. 현재 RAG 설계에서 사실상 표준적인 패러다임으로 사용되고 있으며 다음과 같은 특징이 있다.

  • Modular RAG 핵심
    • RAG 파이프라인을 여러 기능 모듈로 분리
    • 각 모듈은 독립적으로 교체·확장 가능
    • 상황에 따라 필요한 모듈만 선택적으로 사용
    • LLM 또는 Agent가 모듈을 조합해 문제를 해결


  • 주요 모듈 종류
    • 검색 모듈 (Retrieval Module)
      • 단순 벡터 검색뿐 아니라 다양한 검색 방식을 포함
      • LLM이 생성한 SQL, Python 쿼리 등을 사용해 데이터 조회 가능
      • 외부 검색 엔진, 내부 DB, API 등 다양한 데이터 소스를 활용
    • 메모리 모듈 (Memory Module)
      • 이전 대화나 사용자 기록을 저장하고 검색
      • 현재 질문과 가장 유사한 과거 정보를 찾아 문맥으로 제공
      • 개인화된 응답이나 장기 컨텍스트 유지에 활용
    • 태스크 모듈 (Task / Tool Module)
      기본 RAG는 “검색 → 답변 생성”에 초점을 두지만, 실제 서비스에서는 다양한 목적의 작업(task)이 필요하다.
      • 요약
      • 분류
      • 이메일 작성
      • 추천
      • 보고서 생성 등

RAG는 단순히 외부 지식을 붙이는 기법이 아니라, LLM의 한계를 전제로 설계된 하나의 시스템 구조에 가깝다. Naive RAG에서 Advanced RAG, 그리고 Modular RAG로 이어지는 흐름은 정확도를 높이기보다는 실제 서비스에서 발생하는 문제를 어떻게 통제할 것인가에 대한 고민의 결과라고 볼 수 있다.

주의해야 할 것은 RAG는 정답을 만들어주는 만능 도구가 아니다. 오히려 잘못 설계되면 더 확신에 찬 오답을 만들기도 한다.

검색, 재정렬, 검증까지 포함한 구조적 설계 없이는 RAG의 효과를 기대하기도 어렵고 서비스에 적용할 때는 기술 자체보다 어떤 문제를 해결하려는지부터 정의하는 것이 중요하다.