RAG 개요

  • RAG(Retrieval-Augmented Generation, 검색 증강 생성)는
    • 거대 언어 모델(LLM)이 가진 고질적인 문제인 ‘할루시네이션(환각)’을 해결하고,
    • 모델이 학습하지 않은 최신 정보나 내부 데이터를 활용할 수 있도록 돕는 기술적 프레임워크
  • 쉽게 비유하자면,
    • LLM이 자신의 기억(학습 데이터)에만 의존해 시험을 치르는 방식이라면,
    • RAG는 오픈북 테스트를 치르는 방식임

1. RAG의 핵심 등장 배경

  • LLM은 학습 시점(Cut-off) 이후의 정보는 알지 못하며, 사실 관계가 틀린 내용을 자신 있게 말하는 경향이 있음

  • 이를 해결하기 위해 매번 모델을 재학습(Fine-tuning)하는 것은 막대한 비용과 시간이 소요됨

  • RAG는 외부 지식 베이스에서 관련 정보를 먼저 찾아낸 뒤, 그 정보를 바탕으로 답변을 생성하게 함으로써 다음과 같은 이점을 제공함
    • 최신성 유지: 실시간 뉴스나 최신 데이터 반영 가능
    • 신뢰성 향상: 답변의 근거(출처)를 제시할 수 있음
    • 보안성: 기업 내부의 기밀 데이터를 모델 외부의 벡터 데이터베이스에 저장하여 안전하게 활용

2. RAG의 동작 프로세스 (5단계)

2.1 데이터 전처리 및 인덱싱 (Indexing)

  • 가장 먼저 수행해야 할 단계
  • 비정형 데이터를 기계가 검색 가능한 형태로 변환하는 과정
  1. 문서 분할(Chunking)
    • 방대한 문서를 한꺼번에 처리할 수 없으므로 의미 있는 단위(문단, 페이지 등)로 자름
      • Overlap(중복 구간)을 두어 문맥이 끊기지 않게 하는 것이 노하우
  2. 임베딩(Embedding)
    • 각 텍스트 조각을 고차원 벡터(\(Vector\))로 변환
    • \(n\)차원의 공간상에 텍스트의 의미를 좌표로 찍는 과정
  3. 벡터 DB 저장
    • 변환된 벡터 데이터를 Vector DB(예: Milvus, Pinecone, FAISS)에 인덱싱하여 저장

2.2 사용자 질의 (Querying)

  • 사용자가 던진 자연어 질문을 시스템이 이해할 수 있는 형태로 변환하는 과정
  1. 질의 벡터화
    • 사용자의 질문을 1단계에서 사용한 것과 동일한 Embedding Model에 통과시켜 벡터화
  2. 질의 최적화(선택 사항)
    • 성능을 높이기 위해 질문을 더 검색하기 쉬운 형태로 재작성(Rewrite)
    • 다국어 질문일 경우 번역 과정을 거침

2.3 검색 (Retrieval)

  • 벡터 DB 내에서 질문의 벡터와 가장 유사한 위치에 있는 데이터를 찾아내는 단계
  1. 유사도 계산
    • 질문의 벡터와 벡터 DB에 저장된 문서 조각들의 벡터를 비교
    • 주로 코사인 유사도(Cosine Similarity)나 L2 Distance를 사용
  2. 의미적 매칭
    • 거리상 가장 가까운 상위 \(k\)개의 문서 조각을 추출
    • 단순 키워드 일치가 아니라, 단어의 의미적 맥락이 일치하는 정보를 가져오는 것이 RAG 검색의 강점

2.4 리랭킹(Re-ranking)

  • 선택사항
  • 실제 시스템 구축 시에는 3단계와 4단계 사이에 리랭킹(Re-ranking) 단계를 추가하는 것이 일반적
  • 검색 단계에서 가져온 10~20개의 문서 중, 실제 정답 확률이 가장 높은 순서로 다시 정렬
  • 생성 모델의 정확도를 비약적으로 높일 수 있음

2.5 증강 (Augmentation)

  • 검색된 데이터와 원래의 질문을 결합하여 모델이 이해하기 쉬운 ‘맥락(Context)’을 구성
  1. 프롬프트 엔지니어링
    • 원래의 사용자 질문에, 방금 검색된 관련 문서 조각들을 결합
    • 단순히 정보를 나열하는 것이 아니라, 다음과 같은 구조로 프롬프트를 재구성
      • “다음 제공된 문서를 바탕으로 질문에 답해줘: [검색된 문서 내용] / 질문: [사용자의 질문]”
        • 예시 “시스템: 당신은 신뢰할 수 있는 도우미입니다. 아래 제공된 [참고 자료]를 바탕으로만 [질문]에 답하세요. 만약 자료에 답이 없다면 모른다고 답하세요.”
  2. 컨텍스트 통합
    • 검색된 \(k\)개의 조각들을 우선순위에 따라 배치
    • LLM의 입력 제한(Token Limit) 내에 최적화하여 채워 넣기

2.6 생성 (Generation)

  • 최종적으로 LLM이 보강된 프롬프트를 읽고 사용자에게 자연스러운 답변을 내놓는 단계
  1. 할루시네이션 억제
    • 모델은 자신의 내부 지식보다 프롬프트에 제공된 외부 데이터를 우선시하여 답변 생성
  2. 근거 제시(Citation)
    • 답변의 마지막에 “위 답변은 문서 A의 3페이지를 참고했습니다”와 같은 출처를 명시하여 신뢰도 확보


  • Python 기반의 LangChain이나 LlamaIndex 프레임워크를 활용하면 위 5단계 프로세스를 매우 효율적으로 파이프라인화하여 구현할 수 있음

3. RAG vs 파인튜닝(Fine-tuning) 비교

  • RAG와 파인튜닝은 AI 모델의 지능을 높이는 서로 다른 ‘접근 방식’을 취하고 있음
  • 기술적 호기심 때문이 아니라, 비즈니스와 개발 현장에서 직면하는 현실적인 제약 조건(비용, 시간, 정확도) 때문에
  • 프로젝트의 성격에 맞춰 자원을 어디에 집중할지를 결정하기 위하여 반드시 비교가 필요함

3.1 비교의 이유

  • 지식 습득 방식의 근본적 차이 (공부법의 차이)
    • 파인튜닝 (암기형):
      • 교과서의 내용을 통째로 외우는 방식
        • 시험을 볼 때 머릿속 기억에만 의존하므로 답변 속도가 빠르지만,
        • 새로운 내용이 나오면 다시 외워야(재학습) 함
    • RAG (참조형):
      • 시험장에 교과서와 백과사전을 들고 들어가서 모르는 문제가 나오면 찾아보고 답하는 방식
        • 암기량은 적어도 되지만,
        • 책에서 정보를 찾는 기술(검색 성능)이 중요함
  • 데이터 휘발성과 업데이트 주기 (최신성)
    • 데이터가 얼마나 자주 변하느냐에 따라 선택지가 갈림
      • 주가 데이터처럼 매일 변하는 정보를 파인튜닝으로 처리하려면 매일 엄청난 비용을 들여 모델을 학습시켜야 함 🡲 현실적으로 불가능
      • 업데이트가 잦은 데이터일수록 RAG가 압도적으로 유리함
  • 할루시네이션(Hallucination) 통제 능력
    • AI가 거짓말을 하면 안 되는 미션 크리티컬한 분야(의료, 법률, 보안 시스템 등)에서는 이 선택이 생존의 문제임
      • 파인튜닝된 모델: 틀린 정보를 말해도 왜 그렇게 말했는지 추적할 수 없음
      • RAG: “이 문서의 이 구절 때문에 이렇게 답했다”는 근거(Source)를 남길 수 있음
    • 시스템의 신뢰도와 책임 소재를 분명히 하기 위해 두 방식을 대조
  • 경제적 효율성 (ROI)
    • 기업 운영과 개인 사업체 운영 관점에서 가장 중요한 포인트
    • 한정된 예산으로 최대의 성능을 뽑아내기 위한 경제적 타당성 검토를 위해 비교
      • 파인튜닝
        • 대량의 GPU 자원, 정제된 데이터셋, 전문 인력이 필요함
        • 한 번 학습에 수천만 원에서 수억 원이 들 수 있음
      • RAG
        • 기존 모델을 그대로 쓰면서 데이터베이스(Vector DB)만 관리하면 됨
        • 비용이 훨씬 저렴함
  • 역할 분담을 통한 시너지 (하이브리드 전략)
    • 최근에는 “둘 중 무엇이 더 좋은가?”를 넘어 “어떻게 섞을 것인가?”를 고민하기 위해 비교함

3.2 비교 내용

비교 항목RAG (검색 증강 생성)파인튜닝 (미세 조정)
주요 목적새로운 지식/정보의 주입 및 활용모델의 말투, 형식, 도메인 특화 학습
업데이트 비용낮음 (DB만 업데이트)높음 (GPU 자원 및 재학습 필요)
할루시네이션눈에 띄게 감소 (근거 기반)여전히 발생 가능함
투명성답변의 출처 확인 가능답변의 근거 확인 어려움


  • 비교를 통한 결론:
    • 말투, 전문 용어, 특수한 문장 구조는 파인튜닝으로 모델의 ‘체질’을 개선
    • 방대한 지식, 최신 정보, 정확한 팩트는 RAG로 ‘외부 저장소’를 연결
  • 이 접점을 찾기 위해 두 기술의 한계를 명확히 이해해야 함
  • 개발자이자 사업가 입장에서는 “이 서비스에 수억 원을 들여 모델을 새로 학습시킬 가치가 있는가(Fine-tuning),
    아니면 똑똑한 검색 엔진을 붙이는 것이 효율적인가(RAG)”    를 결정하는 최적화 로드맵을 그리기 위해 이 비교가 반드시 필요함

4. RAG 성능 향상을 위한 주요 기술

  • RAG 시스템을 실제 서비스 수준으로 끌어올리기 위해서는 단순히 ‘질문-검색-생성’의 기본 단계를 넘어,
    검색의 정밀도(Precision)와 재현율(Recall)을 높이는 고도화 기술이 필수
  • 단순한 RAG를 넘어 성능을 극대화하기 위해 다음과 같은 전략들이 사용됨
  • 전통적인 키워드 기반 검색과 최신 의미 기반 벡터 검색의 장점만을 결합한 방식
  • BM25 (키워드 검색)
    • 문서 내 단어의 빈도와 희귀성을 계산하여 매칭
    • 특정 고유명사, 제품명, 코드 함수명 등 정확한 단어 일치가 중요한 검색에 강력함
  • Vector Search (의미 검색)
    • 단어의 맥락적 의미를 수치화하여 유사도를 계산
    • 문맥적 연관성이 중요한 검색에 탁월함
      • 예: “노트북이 안 켜져요”라는 질문에 “전원 공급 문제 해결”이라는 문서를 찾아내기
  • 결합의 의의
    • 벡터 검색은 때로 엉뚱한 맥락을 가져오기도 하고, 키워드 검색은 유의어를 놓치기도 함
    • 하이브리드 검색은 두 방식의 점수를 RRF(Reciprocal Rank Fusion) 같은 알고리즘으로 합산하여, 어떤 유형의 질문에도 유연하게 대응함

4.2 리랭킹(Re-ranking)

  • 검색 단계(Retrieval)에서 가져온 문서 후보들을 다시 한번 정밀하게 검토하여 순서를 재정렬하는 과정
  • 필요성
    • 벡터 DB에서 검색된 상위 \(k\)개의 문서가 항상 최적의 정답을 포함하고 있지는 않음
    • 초기 검색은 속도를 위해 대략적인 유사도만 따지기 때문
  • 작동 방식
    • 1차 검색에서 50~100개의 후보 문서를 빠르게 뽑아낸 뒤,
    • Cross-Encoder 기반의 정밀 모델(Re-ranker)을 사용하여
    • 질문과 각 문서의 연관성을 심층 분석함
    • 이 모델은 계산량은 많지만 훨씬 정확함
  • 결과
    • 질문과 가장 밀접한 관련이 있는 핵심 문서가 1~3위 안에 배치되도록 보장
      • LLM이 쓸데없는 정보(Noise)에 현혹되지 않고 정답을 생성하도록 돕는 결정적인 역할 수행

4.3 쿼리 변형(Query Transformation)

  • 사용자가 입력한 초기 질문을 검색 시스템이 이해하기 가장 좋은 형태로 가공하거나 확장하는 기술
  • 모호성 해소
    • 사용자는 종종 “그거 어떻게 해?”와 같이 대명사가 섞이거나 맥락이 부족한 질문을 던짐
    • 이를 “A 제품의 설정 기능을 활성화하는 방법”처럼 구체적인 쿼리로 다시 작성(Rewrite)
  • 다중 질의 생성 (Multi-Query)
    • 하나의 질문을 의미가 같은 여러 개의 다른 질문으로 변환하여 검색
    • 여러 각도에서 검색을 수행하여 누락되는 정보가 없도록 재현율을 극대화
  • 가상 문서 임베딩 (HyDE, Hypothetical Document Embeddings)
    • 질문에 대한 가상의 답변을 먼저 생성한 후, 그 답변과 유사한 실제 문서를 검색
    • 질문(의문문)과 문서(평서문) 사이의 문체 차이로 발생하는 검색 오류를 줄여줌

5. 결론

  • RAG는 현대 AI 서비스 구축에서 필수적인 요소가 되었음
  • 특히 컴퓨터 공학적 관점에서 볼 때,
    • 모델의 파라미터 업데이트 없이도
    • 외부 지식 그래프나 벡터 DB를 연동하여
    • 시스템의 확장성을 확보할 수 있다는 점이 가장 큰 장점
  • 활용 예시
    • 스마트팩토리나 AI/SW 개발 프로젝트에서도
      • 내부 기술 문서나 운영 매뉴얼을 RAG 시스템으로 구축하면,
      • 실시간으로 정확한 가이드를 제공하는 지능형 에이전트를 효율적으로 운영할 수 있음
  • AI 에이전트를 설계한다면, 특히 리랭킹 단계에 주목할 것을 권장
  • 실무에서는 검색 모델 자체를 튜닝하는 것보다 준수한 성능의 오픈소스 리랭커(예: BGE-Reranker)를 도입하는 것이
  • 시스템 성능 향상에 훨씬 즉각적이고 가성비 좋은 결과를 가져다 줌

© 2020. AiDALab Co. All rights reserved.

Powered by Hydejack v9.2.1