RAG

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

개념

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

동작 구조

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

왜 RAG가 필요한가

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

RAG의 장점

예시

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

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

RAG 사용

1. 벡터 DB 검색: "2024 노벨 물리학상"
2. 관련 문서 검색됨: 뉴스 기사, 위키피디아
3. LLM에 문서와 함께 질문 전달
4. 답변: "2024년 노벨 물리학상은 존 홉필드와 제프리 힌턴이 수상했습니다."

벡터 검색 원리

임베딩 생성

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

유사도 검색

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

RAG 파이프라인

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

청킹 전략

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

구현 예시

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

# 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)는 설계를 네 패턴으로 정리합니다.

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

한계

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

관련 개념

• LLM Agent Survey: 메모리 메커니즘
• ReAct: 도구 사용 (검색 포함)
• MADKE: 지식 풀 기반 토론

정리

RAG는 외부 검색으로 얻은 근거 문서를 LLM에 함께 넘겨, 지식 단절과 할루시네이션을 보완하는 기법입니다. 문서만 갱신하면 최신 정보를 반영하고 출처를 확인할 수 있어, 재학습이 필요한 Fine-tuning보다 비용이 낮습니다. 대신 답의 품질이 검색 품질에 크게 의존하고, 컨텍스트 한계와 다중 문서 추론이라는 약점이 남습니다.

청킹·Hybrid Search·Re-ranking은 검색 품질을 끌어올리는 보정 장치입니다. 단발 검색으로 풀기 어려운 복잡한 질문은 에이전트가 검색을 능동적으로 제어하는 Agentic RAG로 확장합니다.