RAG 입문 — 검색 증강 생성

왜 RAG가 필요한가

생성형 모델은 학습 시점에 본 데이터의 범위를 벗어나지 못합니다. RAG는 그 경계 바깥에서 생기는 네 가지 문제를 겨냥합니다.

RAG를 이루는 세 가지 구성 요소

RAG 파이프라인은 결국 “어디서 찾을 것인가 · 어떻게 끼워 넣을 것인가 · 누가 답을 쓸 것인가”의 세 조각으로 나뉩니다.

아래는 컨텍스트 정보입니다.
---------------------
{context}
---------------------
주어진 컨텍스트 정보만 사용하고 사전 지식은 사용하지 말고,
다음 질문에 답하세요.
질문: {query}
답변:

동작 흐름: 인제스천과 추론

RAG는 시점이 다른 두 단계로 나뉩니다. 인제스천(Ingestion)은 질문이 오기 전에 미리 지식 베이스를 만들어 두는 준비 과정이고, 추론(Inference)은 질문이 들어온 순간 실행되는 세 걸음입니다.

[인제스천]  원본 문서 → 청킹 → 임베딩 → 벡터 DB 저장

[추론]      사용자 질문
              ↓ 임베딩
            유사도 검색  ──→  관련 청크 top-k
              ↓
            프롬프트 템플릿에 삽입 (Augmentation)
              ↓
            LLM 생성 (Generation) → 근거가 붙은 답변

RAG와 파인튜닝의 차이

둘은 경쟁 관계라기보다 목적이 다릅니다. 대략적인 기준은 “무엇을 아는가는 RAG, 어떻게 말하는가는 파인튜닝”입니다.

고급 RAG 기법

기본 파이프라인이 잘 동작하지 않을 때는 검색의 앞 · 중간 · 뒤중 어디를 손볼지부터 정합니다. 개선 지점을 단계별로 나눠 보면 원인 추적이 쉬워집니다.

한 걸음 더: Agentic RAG와 Graph RAG

단순 RAG는 “한 번 검색하고 한 번 답한다”는 직선 구조입니다. 질문이 여러 문서를 넘나들거나, 첫 검색이 빗나갔을 때 스스로 회복해야 한다면 구조 자체를 바꿔야 합니다.

RAG 평가하기

RAG가 틀린 답을 냈을 때 원인은 둘 중 하나입니다 — 잘못된 문서를 가져왔거나, 제대로 가져온 문서를 잘못 읽었거나. 그래서 평가도 검색기(retriever)와 생성기(generator)를 나눠 측정한 뒤, 마지막에 전체를 함께 봅니다.

구현에 쓰이는 프레임워크

RAG 파이프라인은 직접 구현해도 되지만, 인제스천 · 검색 · 평가의 반복 작업을 줄여 주는 오픈소스 파이썬 라이브러리들이 있습니다.

활용 사례

핵심 용어 정리