#RAG (Retrieval-Augmented Generation)

RAG는 질문과 관련된 외부 문서를 검색해 프롬프트에 붙인 뒤 LLM이 그 근거로 답하게 하는 구조입니다. 모델 가중치는 그대로 두고 "무엇을 보여줄지"만 바꾸기 때문에, 사내 문서·최신 정보처럼 모델이 학습하지 않은 지식을 싸고 빠르게 연결할 수 있습니다.

한 줄로 줄이면 검색 기술 + LLM 프롬프트입니다. 이 문서는 전체 그림과 선택 기준을 요약하고, 깊은 설계 논점은 RAG 심화 시리즈로 연결합니다.

#왜 필요한가

⚠️ 함정: RAG는 환각을 없애지 않고 줄일 뿐입니다. 검색이 엉뚱한 문서를 가져오면 모델은 그 문서를 근거로 더 자신 있게 틀립니다. 특히 "비슷하지만 적용되지 않는" 문서(구버전 규정, 다른 제품군 정책)가 가장 발견하기 어려운 실패입니다. → 쿼리 재작성의 경계

장점: 실시간 갱신, 파인튜닝 대비 낮은 비용, 출처 제시로 신뢰성 확보, 참조 범위를 제어할 수 있어 안전함. 단점: 답변 품질의 상한이 검색 품질에 묶임, 파이프라인 구성 요소가 늘어 복잡도 증가, 컨텍스트 길이·비용 부담, 원본 문서 품질에 크게 좌우됨.

#전체 파이프라인

RAG는 미리 해두는 인덱싱과 요청마다 도는 질의 처리 두 흐름으로 나뉩니다.

운영 관점(데이터 거버넌스 → 검색 품질 → 생성 제약 → 평가 → 피드백)의 전체 설계는 RAG 전체 설계 — 5환 클로즈드 루프에서 다룹니다.

#청킹 전략

청크는 검색의 최소 단위이자 LLM이 읽는 근거의 단위입니다. 너무 크면 임베딩이 여러 주제로 흐려지고, 너무 작으면 답에 필요한 맥락이 잘립니다.

마지막 방식은 Anthropic이 Contextual Retrieval로 공개한 기법으로, 자사 실험에서 컨텍스트 임베딩 + 컨텍스트 BM25 조합이 top-20 검색 실패율을 49%, 리랭크까지 더하면 67% 줄였다고 보고했습니다.

⚠️ 함정: 청킹은 "한 번 정하고 잊는" 설정이 아닙니다. 청크 크기나 임베딩 모델을 바꾸면 전체 재인덱싱이 필요하고, 쿼리 쪽과 문서 쪽 임베딩 모델 버전이 어긋나면 에러 없이 검색 결과가 0건이 됩니다. → 제로 리콜 트러블슈팅, 증분 색인

#하이브리드 검색

벡터 검색과 키워드 검색은 서로 다른 실패를 합니다. 그래서 프로덕션에서는 둘을 함께 돌리고 결과를 합치는 게 기본값입니다.

결과 합치기: 두 검색의 점수는 척도가 달라 그대로 더할 수 없습니다. 가장 흔한 방법은 순위만 쓰는 RRF(Reciprocal Rank Fusion) 로, 문서마다 Σ 1 / (k + rank) 를 더합니다(k는 보통 60). Elasticsearch·OpenSearch·여러 벡터 DB가 RRF를 내장하고 있습니다. 구현 예시는 Multi-Query에 있습니다.

더 깊이: BM25와 벡터 검색, Top K와 2단계 검색

#리랭크 (Rerank)

1단계 검색은 빠르지만 거칠게 많이 가져오고(예: 50~100개), 리랭커가 질문과 문서를 함께 읽어 정밀하게 다시 줄 세운 뒤 상위 몇 개만 LLM에 넘깁니다.

필요한 상황

• 후보가 많아 전부 프롬프트에 넣을 수 없을 때
• 정답 문서가 검색은 되는데 Top 3 안에 안 올라올 때
• 비슷한 문서(버전 차이, 유사 제품)가 많아 순서가 답을 좌우할 때
• 최신성·신뢰도 같은 비즈니스 기준을 순서에 반영해야 할 때

모델 예시 (2026-09 기준)

⚠️ 함정: 리랭커는 검색에 없는 문서를 찾아주지 못합니다. "못 찾는 문제"는 청킹·쿼리 변환·하이브리드 검색으로 풀고, 리랭커는 "찾았는데 순위가 낮은 문제"에만 씁니다. 단순 FAQ처럼 후보가 명확한 경우엔 지연과 비용만 늘립니다. 또한 오픈 웨이트라도 라이선스가 상업 이용을 막는 모델이 있으니 확인하세요.

#검색 후처리 (Post-Retrieval)

리랭크 외에도 "무엇을, 얼마나, 어떤 순서로" 넣을지 다듬는 단계가 있습니다.

순서가 중요한 이유는 모델이 긴 컨텍스트의 중간에 놓인 정보를 덜 활용하는 경향(Lost in the Middle) 때문입니다.

#쿼리 변환 기법

사용자의 질문은 짧고, 구어체이고, 대명사와 생략이 많습니다. 반면 문서는 정식 용어로 쓰여 있습니다. 이 간극을 검색 전에 메우는 기법들입니다.

⚠️ 함정: 모든 쿼리 변환의 공통 규칙은 원래 질문을 버리지 않는 것입니다. 변환된 쿼리는 검색 경로를 추가하는 용도로 쓰고, 원 질문 경로를 백스톱으로 항상 함께 돌리세요. 주문번호·법규 번호 같은 하드 엔티티는 변환 대상에서 제외합니다. → 쿼리 재작성의 경계

#RAG vs 파인튜닝 vs 긴 컨텍스트

"모델이 우리 데이터를 알게 하고 싶다"는 요구에는 세 가지 선택지가 있고, 대부분은 조합합니다.

선택 가이드

• 자주 바뀌거나, 출처가 필요하거나, 사용자별 권한이 다르면 → RAG
• 답의 내용은 맞는데 형식·톤·판단 기준이 안 맞으면 → 파인튜닝 (파인튜닝)
• 대상 문서가 작고 고정적이며, 전체를 한 번에 봐야 하면 → 긴 컨텍스트
• 코드베이스처럼 정확한 식별자 탐색이 핵심이면 → 벡터 RAG 대신 grep·심볼 검색 같은 도구를 에이전트가 직접 쓰게 하는 편이 나을 수 있음 → Claude Code가 RAG를 쓰지 않는 이유

#RAG 변형

#Modular RAG

Advanced RAG가 "단계를 더 붙인 직선"이라면, Modular RAG는 Orchestration(라우팅·스케줄링) 계층이 질문에 따라 모듈 조합을 바꿉니다. 예: 식별자 질문은 키워드 검색만, 비교 질문은 분해 → 병렬 검색 → 합성.

#Graph RAG

Microsoft GraphRAG는 문서에서 엔티티와 관계를 추출해 그래프를 만들고, 커뮤니티 단위 요약을 미리 생성해 "이 문서들 전체의 주요 주제는?" 같은 전역 질문에 답합니다. 벡터 검색은 "비슷한 문단 찾기"에는 강하지만 이런 질문에는 약합니다. 대신 그래프 구축 비용이 크고 엔티티 정합(같은 대상을 하나로 묶기)이 어렵습니다.

→ 지식 그래프란, 엔티티 추출·링킹, 지식 그래프와 벡터 DB 선택

#Agentic RAG

검색을 파이프라인의 고정 단계가 아니라 에이전트가 호출하는 도구로 둡니다. 검색 결과가 부족하면 쿼리를 바꿔 다시 찾고, 충분하면 멈춥니다. Self-RAG(검색 필요 여부와 생성 결과를 스스로 평가), CRAG(검색 품질을 평가해 나쁘면 교정·웹 검색) 같은 연구가 이 방향입니다. 유연한 만큼 호출 수·지연·비용 상한을 반드시 걸어야 합니다. → 에이전트

#추론 기반 검색 — PageIndex

벡터 유사도 대신 LLM이 문서 목차 구조를 읽고 어디를 볼지 추론하는 방식입니다. PageIndex는 문서를 계층형 트리 인덱스로 바꾸고, LLM이 사람 전문가처럼 목차를 따라 내려가며 관련 구간을 찾습니다. 청킹·임베딩 없이 동작하며 재무 보고서·법률 문서처럼 구조가 뚜렷한 긴 문서에 적합합니다. 대신 탐색 단계마다 LLM 호출이 들어갑니다.

문서 선택 단계에 쓰는 프롬프트 예시입니다.

You are given a list of documents with their IDs, file names, and descriptions. Your task is to select documents that may contain information relevant to answering the user query.

Query: {query}

Documents: [
    {
        "doc_id": "xxx",
        "doc_name": "xxx",
        "doc_description": "xxx"
    }
]

Response Format:
{{
    "thinking": "<Your reasoning for document selection>",
    "answer": <Python list of relevant doc_ids>, e.g. ['doc_id1', 'doc_id2']. Return [] if no documents are relevant.
}}

Return only the JSON structure, with no additional output.

#평가

RAG는 검색과 생성을 따로 측정해야 어디가 문제인지 알 수 있습니다. 최종 답변 만족도만 보면 "검색은 틀렸는데 답이 매끄러운" 실패가 가려집니다.

측정 방법과 도구는 평가, LLM이 채점하는 방식은 LLM-as-a-Judge를 참고하세요.

⚠️ 함정: 평가셋 없이 프롬프트나 청크 크기를 바꾸면 "몇 개 질문에선 좋아졌는데 전체는 나빠진" 변경을 배포하게 됩니다. 실제 사용자 질문 수십~수백 개에 정답 문서를 표시한 골든셋을 먼저 만드세요.

#흔한 실패와 대응

#참고 자료

• Gao et al. — Retrieval-Augmented Generation for Large Language Models: A Survey (2023) — Naive / Advanced / Modular RAG 분류
• Gao et al. — Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks (2024)
• Rabiloo — The 3 types of RAG models: Naive, Modular, Advanced — 본문 다이어그램 출처
• Anthropic — Introducing Contextual Retrieval
• Cormack et al. — Reciprocal Rank Fusion (SIGIR 2009)
• Liu et al. — Lost in the Middle: How Language Models Use Long Contexts
• Edge et al. — From Local to Global: A Graph RAG Approach (Microsoft GraphRAG) · GitHub
• Asai et al. — Self-RAG · Yan et al. — Corrective RAG (CRAG)
• VectifyAI — PageIndex
• Ragas — Available Metrics
• Cohere — Rerank · BAAI/bge-reranker-v2-m3
• LlamaParse — 문서 파싱
• Prompt Engineering Guide — RAG for LLMs
• 추가 읽을거리 (중국어): 知乎 1 · 知乎 2 · 知乎 3 · 知乎 4 · 知乎 5 · 知乎 6 · 知乎 7