RAG | jongkwan.dev

대규모 언어 모델(LLM)이 외부 데이터베이스를 검색해 얻은 근거 문서로 답을 생성하는 기법이다.

개념

Retrieval-Augmented Generation(RAG, 검색 강화 생성)은 LLM의 내부 지식만 사용하는 대신, 외부 데이터베이스에서 관련 정보를 검색하여 응답 생성에 활용하는 기법이다. 여기서 LLM은 대규모 언어 모델이고, 할루시네이션은 모델이 사실이 아닌 내용을 그럴듯하게 생성하는 현상을 뜻한다.

동작 구조

질문 입력: 사용자가 질문을 제출한다.
문서 검색: 벡터 DB에서 관련 문서를 검색한다.
컨텍스트 결합: 검색 결과와 질문을 함께 LLM에 전달한다.
답변 생성: LLM이 검색된 문서를 참고하여 답변을 생성한다.

왜 RAG가 필요한가

LLM은 학습 시점 이후 지식을 알 수 없고, 모르는 내용을 지어내며, 근거를 제시하지 못한다. 이 세 한계를 정리하면 다음과 같다.

한계	설명
지식 단절	학습 이후 정보를 알 수 없음
할루시네이션	모르는 것을 지어냄
출처 불명	정보의 근거 확인 어려움

RAG의 장점

장점	설명
최신 정보	학습 데이터 이후 정보 접근
할루시네이션 감소	실제 문서 기반 응답
투명성	출처 확인 가능
도메인 특화	특정 분야 문서로 전문성 확보

예시

질문: "2024년 노벨 물리학상 수상자는?"

LLM만 사용 "2024년 노벨 물리학상 수상자에 대한 정보가 학습 데이터에 포함되어 있지 않다." (또는 할루시네이션)

RAG 사용

벡터 DB 검색: "2024 노벨 물리학상"

관련 문서 검색됨: 뉴스 기사, 위키피디아

LLM에 문서와 함께 질문 전달

답변: "2024년 노벨 물리학상은 존 홉필드와 제프리 힌턴이 수상했다."

벡터 검색 원리

임베딩 생성

문서: "한국의 수도는 서울이다" 임베딩 모델을 통해 변환한다. 벡터: [0.23, -0.45, 0.12, ...]

유사도 검색

질문: "한국의 수도는?" 질문 임베딩: [0.21, -0.43, 0.15, ...] 벡터 DB에서 가장 유사한 문서를 검색한다. 결과: "한국의 수도는 서울이다" (유사도: 0.95)

RAG 파이프라인

인덱싱 단계: 문서를 청크로 분할하고, 임베딩을 생성하여 벡터 DB에 저장한다.
쿼리 단계: 질문을 임베딩하고, 유사 문서를 검색한 뒤 LLM에 전달하여 답변을 생성한다.

청킹 전략

전략	설명	적합한 경우
고정 크기	500자씩 분할	일반적
문장 기반	문장 단위 분할	짧은 QA
의미 기반	단락/섹션 단위	긴 문서
겹침 사용	청크 간 중복 포함	문맥 보존

GraphRAG: 구조화된 지식

기본 RAG는 텍스트 덩어리를 검색한다. GraphRAG는 지식 그래프를 활용한다.

질문: "페니실린은 누가 발견했는가?" 지식 그래프에서 경로를 추적한다: Alexander Fleming → discovered → Penicillin Alexander Fleming → year → 1928 답변: "알렉산더 플레밍이 1928년에 발견"

지식 그래프 예시

Alexander Fleming

discovered → Penicillin

nationality → Scottish

profession → Bacteriologist

Penicillin

type → Antibiotic

discovered_year → 1928

RAG vs Fine-tuning

	RAG	Fine-tuning
지식 업데이트	문서만 추가	재학습 필요
비용	낮음	높음
출처 확인	가능	어려움
도메인 적용	빠름	느림
정확도	검색 품질 의존	모델 품질 의존

구현 예시

아래는 실제 라이브러리 시그니처가 아니라 흐름을 보여주는 의사코드다. k는 검색할 상위 문서 수, embedding_model은 문서를 벡터로 바꾸는 모델, context는 검색 문서를 이어 붙여 프롬프트에 넣는 단계를 가리킨다.

python

# pseudo: 실제 API가 아니라 RAG 흐름을 단순화한 의사코드
class RAGSystem:
    def __init__(self, documents):
        # 문서 임베딩 및 저장
        self.vector_store = VectorStore.from_documents(
            documents,
            embedding_model="text-embedding-ada-002"
        )
        self.llm = LLM(model="gpt-4")
 
    def query(self, question):
        # 1. 관련 문서 검색
        relevant_docs = self.vector_store.similarity_search(
            question,
            k=3  # 상위 3개 문서
        )
 
        # 2. 프롬프트 구성
        context = "\n".join([doc.content for doc in relevant_docs])
        prompt = f"""다음 문서를 참고하여 질문에 답하세요.
 
문서:
{context}
 
질문: {question}
 
답변:"""
 
        # 3. LLM 응답 생성
        answer = self.llm.generate(prompt)
 
        return {
            "answer": answer,
            "sources": [doc.source for doc in relevant_docs]
        }

고급 기법

Hybrid Search

벡터 검색 + 키워드 검색 결합:

질문: "Python GIL이란?"

벡터 검색: 의미적으로 유사한 문서를 검색한다. 키워드 검색: "GIL"이 포함된 문서를 검색한다.

두 결과를 결합하여 더 정확한 검색 결과를 얻는다.

Re-ranking

검색 결과를 LLM으로 재정렬:

검색 결과 10개를 가져온 뒤, LLM이 질문과 가장 관련 있는 순서로 재정렬한다. 최종적으로 재정렬된 결과를 활용한다.

Query Expansion

질문 확장:

원래 질문: "파이썬 속도 개선" 확장된 질문: "파이썬 성능 최적화", "Python performance", "파이썬 프로파일링"

확장된 질문들로 더 많은 관련 문서를 검색한다.

Agentic RAG

기본 RAG는 "검색 → 생성" 한 번으로 끝난다. Agentic RAG는 에이전트가 검색 자체를 능동적으로 제어한다. 언제 검색할지, 무엇을 다시 검색할지, 결과가 충분한지를 스스로 판단한다.

Agentic RAG Survey(arXiv 2501.09136)는 설계를 네 패턴으로 정리한다.

패턴	역할
반추(Reflection)	검색 결과가 충분한지 평가하고 재검색 여부를 결정
계획(Planning)	복잡한 질문을 하위 질문으로 분해해 단계별 검색
도구 사용(Tool use)	키워드·의미 검색, 계산기 등 여러 도구를 선택 호출
다중 에이전트 협업	검색·검증·종합을 역할별 에이전트로 분담

예컨대 A-RAG(arXiv 2602.03442)는 에이전트에 키워드 검색, 의미 검색, 청크 읽기 세 도구를 직접 노출해, 같거나 더 적은 검색 토큰으로 기존 방법을 앞선다. 단발 검색이 약한 복잡한 추론·다중 문서 조합을 검색 루프로 푸는 방향이다.

한계

검색 품질 의존: 관련 문서를 못 찾으면 실패
컨텍스트 한계: 너무 많은 문서는 처리 불가
실시간 정보: DB 업데이트 지연
복잡한 추론: 여러 문서 조합이 어렵다. Agentic RAG가 하위 질문 분해와 재검색 루프로 부분 완화한다.

정리

RAG는 외부 검색으로 얻은 근거 문서를 LLM에 함께 넘겨, 지식 단절과 할루시네이션을 보완하는 기법이다. 문서만 갱신하면 최신 정보를 반영하고 출처를 확인할 수 있어, 재학습이 필요한 Fine-tuning보다 비용이 낮다. 대신 답의 품질이 검색 품질에 크게 의존하고, 컨텍스트 한계와 다중 문서 추론이라는 약점이 남는다. 청킹·Hybrid Search·Re-ranking은 검색 품질을 끌어올리는 보정 장치다. 단발 검색으로 풀기 어려운 복잡한 질문은 에이전트가 검색을 능동적으로 제어하는 Agentic RAG로 확장한다.

개념