RAG (Retrieval-Augmented Generation, 검색 증강 생성)

[!tldr] 한줄 요약 LLM이 응답을 생성하기 전에 외부 지식 베이스에서 관련 정보를 검색해서 컨텍스트로 제공하는 아키텍처. 학습 데이터에 없는 최신/도메인 정보도 정확하게 답변할 수 있게 한다.

핵심 내용

왜 필요한가?

LLM의 근본적 한계:

RAG는 이 문제를 "모델을 재학습시키지 않고" 해결한다.

핵심 파이프라인 (3단계)

flowchart LR
    subgraph 오프라인["오프라인 (데이터 수집)"]
        D[문서] --> C[청킹] --> E[임베딩] --> V[(벡터 DB)]
    end
    subgraph 온라인["온라인 (질의 응답)"]
        Q[사용자 질문] --> QE[질문 임베딩]
        QE --> R["① Retrieval"]
        V --> R
        R --> A["② Augmentation"]
        A --> G["③ Generation"]
        G --> Ans[답변]
    end

① Retrieval (검색)

② Augmentation (증강)

③ Generation (생성)

데이터 수집 파이프라인 (오프라인)

검색이 가능하려면 사전에 지식 베이스를 구축해야 한다 (위 다이어그램의 오프라인 영역):

RAG의 진화 단계

세대특징적합한 경우
Naive RAG단순 검색 → 생성. 구현이 쉽지만 정확도 한계소규모 정적 문서, PoC
Advanced RAGRe-ranking, 하이브리드 검색, 피드백 루프 추가프로덕션 서비스
Modular RAG검색/메모리/라우팅/퓨전 등을 독립 모듈로 분리, 교체 가능엔터프라이즈 시스템
Agentic RAGAI 에이전트가 질문을 분해하고 도구를 선택하며 반복 추론복잡한 멀티스텝 워크플로

Advanced RAG의 주요 기법

한계점

검색 품질에 전적으로 의존

RAG의 답변 품질은 검색이 올바른 문서를 가져오는지에 달려 있다. 의미적 불일치(Semantic Gap)로 질문과 답이 담긴 문서의 표현이 다르면 검색이 실패한다.

청킹의 딜레마

환각을 완전히 제거하지 못함

검색된 문서가 있어도 LLM이 문서에 없는 내용을 추론해서 덧붙이거나, 여러 청크의 정보를 잘못 조합하거나, 검색 결과를 무시하고 학습된 지식으로 답변할 수 있다.

멀티홉 추론의 어려움

"A팀의 매니저가 담당하는 프로젝트의 예산은?"처럼 여러 문서를 순차적으로 검색해야 답할 수 있는 질문에 Naive RAG는 단일 검색만 수행한다. Agentic RAG가 해결하려 하지만 복잡도와 비용이 크게 증가한다.

평가의 어려움

세 지표가 모두 높아야 하지만, 자동 평가가 어려워 사람이 직접 검증해야 하는 경우가 많다.

[!tip] RAG vs 파인튜닝 RAG는 외부 지식 접근에, 파인튜닝은 모델 행동 변경에 적합하다. "최신 제품 정보로 답변하라" → RAG, "특정 톤과 형식으로 답변하라" → 파인튜닝. 둘을 결합하는 것이 가장 효과적이다.

참고 자료

관련 노트