RAG란 무엇인가
📍 In One Sentence
RAG는 지식 베이스에서 관련 문서를 검색하고 질문과 함께 LLM에 제공함으로써 모델이 추측하는 대신 사용자의 데이터를 기반으로 답변하게 합니다.
💬 In Plain Terms
RAG 없음 = 폐쇄형 시험(모델이 기억에서 답변하며 세부 사항을 꾸며낼 수 있음). RAG 있음 = 공개형(모델이 먼저 메모를 찾아봄). 여전히 메모를 잘못 읽을 수 있지만, 적어도 사실을 꾸며내지는 않습니다.
RAG는 관련 정보를 찾는 검색기와 해당 정보를 사용하여 최종 답변을 작성하는 생성기를 결합합니다. 검색기는 사용자의 쿼리를 기반으로 지식 베이스(인덱싱된 PDF, 웹 페이지, 내부 문서 등)를 검색합니다. 생성기는 검색된 단락을 읽고 해당 콘텐츠를 인용하거나 반영하는 응답을 생성합니다.
이것은 모델이 내부 파라미터만으로 답변하는 일반적인 언어 모델 호출과 다릅니다. RAG에서 모델은 질문할 때마다 새로운 문맥을 "읽습니다". 2026년 4월 기준으로, RAG는 독점 문서, 최신 데이터, 또는 비공개 지식 베이스를 기반으로 답변해야 하는 기업용 AI 시스템의 표준 아키텍처입니다.
RAG가 중요한 이유
**RAG가 중요한 이유는 환각을 줄이고 답변을 최신 상태로 유지하기 때문입니다.** 순수 언어 모델은 특히 전문적이거나 최신 주제에서 자신 있게 세부 사항을 꾸며낼 수 있습니다. RAG를 사용하면 답변이 사용자가 제어하는 검색된 문서에 고정됩니다.
RAG는 또한 개인정보 보호 및 거버넌스 측면에서 중요합니다. 민감한 데이터로 모델을 파인튜닝하는 대신, 해당 데이터를 사용자 자신의 스토어에 유지하고 쿼리 시점에 관련 스니펫만 모델에 제공할 수 있습니다. 이렇게 하면 모델이 사용자의 콘텐츠를 영구적으로 흡수하지 않으면서도 추론할 수 있습니다.
검색하려는 문서가 인프라를 벗어날 수 없는 경우, 전체 RAG 파이프라인을 사용자 자신의 하드웨어에서 실행할 수 있습니다. GDPR 준수 아키텍처, 감사 로깅, 배포 패턴은 비즈니스 데이터를 위한 로컬 RAG를 참조하십시오.
RAG 시스템 단계별 작동 원리
일반적인 RAG 시스템은 수집, 인덱싱, 검색, 생성의 네 가지 주요 단계를 거칩니다. 각 단계는 독립적으로 조정할 수 있습니다.
로컬 모델로 PDF에서 이 파이프라인을 실행하는 단계별 안내는 PDF에서 로컬 RAG 단계별 실행을 참조하십시오.
- 1수집(Ingestion): 문서(예: PDF, 지식 베이스 문서, 티켓, 코드)를 로드하고 각각 200~1,000개 토큰 단위의 청크로 분할합니다. 제목, 날짜, 작성자, 태그 같은 메타데이터를 첨부할 수 있습니다.
- 2인덱싱(Indexing): 각 청크는 임베딩 모델을 사용하여 벡터 표현으로 변환된 후 벡터 데이터베이스 또는 검색 인덱스에 저장됩니다. 이를 통해 시스템이 새로운 쿼리에 대해 시맨틱으로 유사한 콘텐츠를 찾을 수 있습니다.
- 3검색(Retrieval): 사용자가 질문하면 시스템이 쿼리를 임베딩하고 인덱스에서 가장 관련성 높은 청크를 검색합니다. 이 단계에서 날짜 범위, 문서 유형, 사용자 권한 같은 필터를 적용할 수 있습니다.
- 4생성(Generation): 시스템이 사용자의 질문과 검색된 청크를 포함하는 프롬프트를 구성한 다음 언어 모델에 전송합니다. 모델은 제공된 문맥과 일관된 답변을 생성합니다.
🔍 검색이 병목 지점
대부분의 RAG 실패는 검색 실패입니다 — 잘못된 문서가 반환되거나 임계값을 통과하는 문서가 없습니다. 전체 파이프라인을 평가하기 전에 20개의 대표 쿼리로 검색기를 독립적으로 테스트하십시오. 검색이 제대로 작동하지 않으면 생성기를 개선해도 도움이 되지 않습니다.
검색과 생성이 분리되어 있으므로, 같은 모델을 유지하면서 더 나은 검색기로 교체하는 것처럼 하나를 개선해도 다른 하나를 변경할 필요가 없습니다.
RAG 대 파인튜닝: 각각을 언제 사용해야 하는가
**RAG와 파인튜닝은 서로 다른 문제를 해결하며, 대안으로 취급하기보다 결합했을 때 가장 잘 작동합니다.** RAG를 먼저 사용하십시오. 파인튜닝은 RAG가 프롬프팅을 통해 제공할 수 없는 일관된 행동 변화가 필요한 경우에만 추가하십시오.
| 요소 | RAG | 파인튜닝 |
|---|---|---|
| 지식 소스 | 쿼리 시점에 문서에서 검색 | 학습 중 모델 파라미터에 내장 |
| 데이터 최신성 | 실시간 — 문서 업데이트 시 즉시 답변 변경 | 정적 — 업데이트 시 재학습 필요 |
| 민감한 데이터 | 인프라에 유지 — 모델에 흡수되지 않음 | 모델 가중치에 영구적으로 흡수 |
| 추적 가능성 | 모든 답변을 소스 문서까지 추적 가능 | 생성된 텍스트의 명확한 출처 없음 |
| 업데이트 비용 | 낮음 — 인덱스에서 문서 추가 또는 제거 | 높음 — 새로운 학습 실행 필요 |
| 스타일/행동 변경 | 모델 행동 변경 불가 | 일관된 스타일, 톤, 도메인 행동 학습 가능 |
| 최적 사용처 | 정책, 제품 문서, 최신 데이터, 비공개 데이터 | 고정된 도메인 행동, 좁고 안정적인 작업 |
| 일반적 사용 | 기업 Q&A, 지원 봇, 연구 보조 | 법률 문서 처리, 의료 코딩 |
🔍 RAG 먼저, 파인튜닝은 나중에
RAG는 되돌릴 수 있습니다 — 문서 스토어를 업데이트하면 답변이 즉시 변경되며, 재학습 비용이 없습니다. 파인튜닝은 영구적입니다 — 모델 파라미터를 수정하며 되돌리려면 새로운 학습 실행이 필요합니다. RAG로 시작하십시오. 파인튜닝은 RAG가 프롬프팅만으로 일관된 행동 변화를 만들어낼 수 없을 때만 추가하십시오.
벡터 데이터베이스 비교
적합한 벡터 데이터베이스 선택은 규모, 데이터 거주 요구사항, 운영 모델에 따라 달라집니다. 아래 표는 2026년 기준으로 가장 널리 배포된 6가지 옵션을 다룹니다.
| 데이터베이스 | 유형 | 최적 사용처 | EU 데이터 거주 | 자체 호스팅 | 대략적 비용 |
|---|---|---|---|---|---|
| Pinecone | 관리형 클라우드 | 최소 운영 오버헤드로 빠른 시작 및 프로덕션 규모 | EU 리전 제공 | 아니요 | 무료 티어; 시작 가격 ~$70/월 |
| Weaviate | 오픈소스 / 관리형 | 유연한 스키마, 하이브리드 검색, EU 규정 준수 | 자체 호스팅 또는 EU 클라우드 | 예 | 무료(자체 호스팅); 관리형 $25/월부터 |
| Chroma | 오픈소스, 로컬 | 로컬 개발, 프로토타이핑, 소규모 문서 세트 | 온프레미스(완전 제어) | 예 | 무료 |
| Milvus | 오픈소스 / 관리형 | 수십억 규모 엔터프라이즈 워크로드 | 자체 호스팅 또는 EU 클라우드(Zilliz) | 예 | 무료(자체 호스팅); 관리형 $65/월부터 |
| Qdrant | 오픈소스 / 관리형 | 고성능 필터링 벡터 검색 | EU 리전 제공; 자체 호스팅 | 예 | 무료(자체 호스팅); 관리형 $25/월부터 |
| pgvector | PostgreSQL 확장 | 이미 PostgreSQL을 사용 중인 팀, 새로운 인프라 불필요 | PostgreSQL이 실행되는 곳 어디든 | 예 | 무료(PostgreSQL 확장) |
예시: RAG 없음 대 RAG 있음
RAG의 이점은 기억만으로 답변하는 것과 검색된 문서를 사용하여 답변하는 것을 비교했을 때 명확해집니다. 다음은 내부 정책 질문에 대한 개념적 예시입니다.
나쁜 프롬프트 – RAG 없음
"우리 회사의 출장 비용 환급 정책은 무엇입니까?"
모델은 일반적인 패턴을 기반으로 추측하는데, 이는 사용자의 조직에 맞지 않을 수 있습니다.
좋은 프롬프트 – RAG 있음
"당신은 우리 내부 회사 정책에 관한 질문에 답변하는 보조자입니다. 관련 정책 발췌문이 있습니다:
...검색된 정책 텍스트 청크 삽입...
이 발췌문의 정보만 사용하여 다음 질문에 답하십시오: '우리 회사의 출장 비용 환급 정책은 무엇입니까?' 발췌문에서 다루지 않는 내용이 있으면 명시하십시오."
두 번째 경우에서 모델은 실제 정책 문서를 기반으로 하며, 정보가 없을 때 어떻게 해야 하는지가 명확합니다.
멀티모델 워크플로에서의 RAG
RAG는 여러 모델과 구조화된 프롬프팅과 결합할 때 더욱 강력해집니다. 다음과 같이 활용할 수 있습니다:
- 하나의 모델 또는 서비스로 문서를 임베딩 및 검색하고, 다른 것으로 답변을 생성하십시오.
- 검색된 문맥에 추론 중심 프롬프트(예: chain-of-thought 또는 TRACE 스타일 구조)를 적용하십시오.
- 여러 모델에서 동일한 RAG 프롬프트를 실행하여 각각이 동일한 문서를 얼마나 잘 활용하는지 비교하십시오.
🔍 같은 문서, 다른 답변
서로 다른 모델은 검색된 문맥을 다르게 사용합니다. 지시 조정된 모델은 검색된 텍스트를 넘어 추론하는 경향이 있습니다. 근거화에 최적화된 모델은 "제공된 문서에 없습니다"를 더 쉽게 말합니다. PromptQuorum으로 여러 모델에서 RAG 파이프라인을 테스트하여 어느 것이 사용자의 도메인을 가장 잘 처리하는지 확인하십시오.
이러한 모듈성은 RAG의 가장 큰 강점 중 하나입니다. 전체 시스템을 재구축하지 않고도 검색기, 인덱스, 생성기, 프롬프트 등 개별 구성 요소를 업그레이드할 수 있습니다.
규제 환경에서의 RAG: EU, 일본, 중국
RAG는 민감한 데이터가 모델 파라미터에 절대 들어가지 않기 때문에 데이터 보호 규정 하에서 운영되는 조직에 선호되는 아키텍처입니다.
EU / GDPR: RAG는 개인 데이터를 처리하는 EU 조직에 선호되는 아키텍처입니다. 문서가 사용자 자신의 인프라에 유지되고 쿼리 시점에 관련 스니펫만 LLM에 전달되므로, 생성 단계에서 개인 데이터가 외부 모델 제공업체에 전송되지 않습니다. GDPR 제46조에 따라, 이는 검색 단계에 대한 표준 계약 조항의 필요성을 제거합니다. EU AI Act 제11조는 고위험 AI 시스템이 지식 소스를 문서화하도록 요구하는데 — 버전 관리된 문서 스토어를 갖춘 RAG 시스템이 이 요건을 직접 충족합니다. 독일 BSI 지침은 민감한 데이터 처리에 로컬 또는 온프레미스 벡터 데이터베이스를 권장합니다.
일본 (METI): METI AI 거버넌스 가이드라인은 AI 지원 결정에 사용된 데이터 소스를 조직이 문서화하도록 요구합니다. 관리되고 버전 관리된 문서 스토어를 갖춘 RAG 시스템은 정확히 이 감사 추적을 생성합니다 — 각 답변은 쿼리 시점에 검색된 특정 문서까지 추적 가능합니다. 일본 기업 배포는 일반적으로 RAG와 로컬 추론(Ollama를 통한 LLaMA)을 결합하여 데이터가 조직 인프라를 벗어나지 않도록 합니다.
중국 (CAC): CAC 생성 AI 서비스 조치(2023)는 프로덕션 AI 시스템에 사용하기 전에 검색 데이터 소스를 문서화하고 검토하도록 요구합니다. 승인된 국내 소스를 사용하는 RAG 아키텍처는 중국 기업 AI의 표준 준수 아키텍처입니다. 조직은 벡터 데이터베이스 제공업체가 중국의 데이터 보안법(数据安全法) 데이터 현지화 요건을 준수하는지 확인해야 합니다.
일반적인 실수
❌ 모델이 이미 잘 알고 있는 지식에 RAG 사용
Why it hurts: 모델이 이미 정확하게 알고 있는 문맥(예: 일반적인 Python 문법)을 검색하면 품질을 개선하지 않으면서 토큰과 지연 시간이 추가됩니다.
Fix: RAG는 도메인별, 독점적, 또는 최신 정보에만 사용하십시오. 먼저 RAG 없이 모델이 올바르게 답변하는지 테스트하십시오 — 그렇다면 RAG는 가치 없이 비용만 추가합니다.
❌ 청크 크기가 너무 작음 (100단어 미만)
Why it hurts: 100단어 미만의 청크는 종종 사실을 이해하는 데 필요한 주변 문맥을 놓칩니다. 주변 단락 없이 정책 문장은 자주 모호합니다.
Fix: 기준선으로 200~500단어 청크를 사용하십시오. 청크 경계 전반에 걸쳐 문맥을 보존하기 위해 인접 청크 간 10~20% 중복을 추가하십시오.
❌ 관련성 임계값 없음
Why it hurts: 유사도 점수와 관계없이 검색된 모든 문서를 LLM에 전달하면 모델이 관련 없는 문맥으로 작업해야 하여 환각 위험이 증가합니다.
Fix: 최소 유사도 점수(코사인 유사도 >0.7)를 설정하십시오. 임계값을 통과하는 청크가 없으면 "지식 베이스에서 찾을 수 없습니다"를 반환하십시오 — 모델이 관련 없는 콘텐츠에서 억지로 답변하게 하지 마십시오.
❌ 생성 품질과 별도로 검색 품질을 테스트하지 않음
Why it hurts: 답변이 잘못된 경우 잘못은 생성(모델 추론)이 아닌 검색(잘못된 문서 반환)에 있을 수 있습니다. 별도 테스트 없이는 문제를 격리할 수 없습니다.
Fix: 전체 파이프라인을 평가하기 전에 20개의 대표 쿼리로 검색기를 테스트하십시오. 확인할 사항: 올바른 문서가 반환됩니까? 답변이 포함되어 있습니까? 그런 다음 프롬프트 품질 평가 기술을 사용하여 생성 정확도를 별도로 측정하십시오.
❌ 메타데이터 필터 무시
Why it hurts: 날짜, 부서, 권한 필터 없는 대규모 문서 스토어는 오래되거나 관련 없는 콘텐츠를 반환합니다 — 특히 서로 다른 기간이나 부서의 문서가 충돌할 때 그렇습니다.
Fix: 수집 시점에 메타데이터(날짜, 작성자, 부서, 권한)를 첨부하십시오. 검색 시점에 필터를 적용하여 관련성 있고, 권한이 있으며, 최신 문서만 반환하십시오.
RAG 구현 방법
- 1AI에 필요한 지식 소스(문서, PDF, 데이터베이스, API)를 파악하십시오. 2026년 4월 기준으로 가장 일반적으로 사용되는 소스는 내부 PDF, 지식 베이스 문서, 제품 문서입니다. 고객 지원용이라면 FAQ, 제품 문서, 과거 티켓 해결 내역이 해당됩니다. 연구 목적이라면 논문 저장소와 외부 데이터베이스가 해당됩니다.
- 2벡터 데이터베이스(Pinecone, Weaviate, Chroma, Milvus)를 사용하여 정적 문서를 검색 가능한 임베딩으로 변환하십시오. 이 과정은 문서를 청크(단락 또는 문장)로 분할하고, 각각을 벡터(의미의 수치 표현)로 변환하여 빠른 시맨틱 검색을 위해 저장합니다.
- 3쿼리 시점에: (1) 사용자의 질문을 벡터로 변환, (2) 가장 유사한 문서 검색, (3) 검색된 문서와 질문을 LLM에 전달. 예시: 사용자가 "비밀번호를 어떻게 재설정합니까?"라고 물으면 → 시스템이 관련 FAQ 또는 문서를 찾음 → LLM이 학습 데이터가 아닌 해당 문서를 기반으로 답변 생성.
- 4대규모 문서 세트(100페이지 이상)의 경우 청킹 전략을 구현하십시오: 중복을 포함한 200~500단어 청크로 문서를 분할하십시오. 이는 문맥 이해도와 검색 정밀도의 균형을 맞춥니다. 대표적인 쿼리로 청크 크기를 테스트하십시오.
- 5LLM이 출력을 생성하기 전에 검색된 문서가 실제로 답변을 포함하는지 확인하십시오. 검색이 관련 없는 문서를 반환하면 좋은 LLM도 어려움을 겪습니다. 관련성 임계값을 사용하십시오: 유사도 점수를 초과하는 경우에만 검색된 문서를 LLM에 전달하십시오(예: 코사인 유사도 >0.7).
🔍 하이브리드 검색의 장점
BM25 키워드 검색과 벡터 유사도 검색은 상호 보완적인 강점을 가지고 있습니다. 하이브리드 검색(재정렬을 통해 둘 다 결합)은 종종 단독보다 우수합니다 — 특히 정확한 용어와 시맨틱 의미를 혼합한 쿼리에서 그렇습니다. 대부분의 벡터 데이터베이스(Weaviate, Milvus, Qdrant)는 하이브리드 검색을 기본 지원합니다.
관련 읽기
- 프롬프트 엔지니어링이란? — RAG 검색 문맥으로 작동하는 프롬프트 설계를 위한 기본 개념
- Chain-of-Thought 프롬프팅 — 검색된 문서에서 복잡한 다단계 추론을 위해 chain-of-thought와 RAG를 결합
- 프롬프트 인젝션 및 보안 — 검색된 문서를 통한 간접 프롬프트 인젝션이 주요 RAG 보안 위험
- 오픈소스 대 독점 LLM — RAG 파이프라인의 생성 단계를 위한 클라우드 대 로컬 LLM 선택
- 2026년 최고의 프롬프트 엔지니어링 도구 — Braintrust, Arize, LangSmith를 포함한 RAG 파이프라인 테스트 및 평가 도구
- AI 한계 — LLM이 할 수 없는 것 — LLM 지식 차단 및 환각 한계를 극복하기 위해 RAG가 필요한 이유 이해
- 빌드 품질 검사 — 환각 감지 및 소스 검증을 포함한 RAG 출력 검증 패턴
- RAG Explicado (Português) — 이 가이드의 포르투갈어 버전
- AI 지식 차단 날짜, 실시간 검색 및 GEO: 완전한 가이드 — 로컬 LLM이 SEO로 도달할 수 없는 이유와 클라우드 및 로컬 AI를 위한 GEO 전략
자주 묻는 질문
RAG(Retrieval-Augmented Generation)란 무엇입니까?
RAG는 AI 시스템이 답변을 생성하기 전에 지식 베이스에서 관련 문서를 검색하는 기술입니다. 모델이 학습 중에 기억한 내용에 의존하는 대신, 사용자가 제공하고 관리하는 문서를 기반으로 답변이 이루어집니다.
RAG는 어떻게 환각을 줄입니까?
RAG는 모델의 답변을 검색된 텍스트에 고정시킵니다. 프롬프트는 모델에게 제공된 발췌문에서만 답변하고 정보가 없을 경우 표시하도록 명시적으로 지시합니다. 이는 모델이 특정 주제에 대한 학습 지식이 부족할 때 그럴듯하게 들리는 세부 사항을 꾸며내는 경향을 제거합니다.
RAG와 파인튜닝의 차이점은 무엇입니까?
RAG는 쿼리 시점에 외부 지식을 검색하여 프롬프트에 추가합니다. 파인튜닝은 추가 학습을 통해 모델의 파라미터를 영구적으로 수정합니다. RAG는 자주 변경되는 데이터에 더 적합하고, 파인튜닝은 일관된 행동이나 스타일을 모델에 가르치는 데 더 적합합니다.
2026년 RAG에 가장 적합한 벡터 데이터베이스는 무엇입니까?
가장 널리 사용되는 옵션은 Pinecone(관리형, 시작이 용이), Weaviate(오픈소스, 유연함), Chroma(경량, 로컬), Milvus(엔터프라이즈 규모)입니다. EU 데이터 거주를 위해서는 자체 호스팅 Weaviate 또는 Chroma가 선호됩니다.
RAG의 최적 청크 크기는 얼마입니까?
인접 청크 간 10~20% 중복을 포함한 청크당 200~500단어가 대부분의 사용 사례에서 잘 작동합니다. 더 작은 청크(100단어 미만)는 문맥을 잃고, 더 큰 청크(1,000단어 초과)는 검색 정밀도를 낮춥니다. 특정 도메인의 대표적인 쿼리로 테스트하십시오.
Ollama 같은 로컬 LLM과 RAG를 사용할 수 있습니까?
예. RAG는 모델 무관입니다. 임베딩 모델을 사용하여 문서를 검색한 다음, Ollama 또는 LM Studio를 통해 로컬에서 실행되는 LLaMA 3.1이나 Mistral을 포함하여 모든 LLM에 검색된 문맥을 전달할 수 있습니다. 로컬 하드웨어에 배포하기 전에 로컬 LLM VRAM 계산기로 GPU 용량을 확인하십시오. 이렇게 하면 모든 데이터가 사용자 자신의 하드웨어에 유지됩니다.
RAG는 GPT-5.5, Claude, Gemini와 작동합니까?
예. 세 가지 모두 프롬프트에서 검색된 문맥을 받아들입니다. Claude Opus 4.8은 검색된 문맥에 답변이 없을 때 환각하는 대신 이를 표시하는 데 특히 효과적입니다. GPT-5.5는 밀도 높은 문맥에서 더 간결한 답변을 생성합니다.
RAG에서 관련성 임계값이란 무엇입니까?
검색된 문서가 이 값 미만이면 LLM에 전달되지 않는 유사도 점수 임계값입니다. 코사인 유사도 임계값 0.7은 쿼리와 70% 이상 시맨틱 매칭되는 문서만 포함됨을 의미합니다. 이 임계값 미만의 문서는 환각된 답변 대신 "지식 베이스에서 찾을 수 없습니다" 응답을 유발합니다.
RAG가 큰 컨텍스트 창보다 낫습니까?
대규모 문서 세트의 경우 그렇습니다. RAG는 시맨틱 유사도를 통해 수백만 개의 문서를 밀리초 단위로 검색하며, 전체 지식 베이스가 아닌 관련 청크만 전달하므로 쿼리당 비용이 적게 듭니다.
RAG를 통한 프롬프트 인젝션을 어떻게 방지합니까?
검색된 콘텐츠를 절대 지시사항으로 신뢰하지 마십시오. 프롬프트에서 지시사항과 검색된 텍스트 사이에 명확한 구분자를 사용하십시오. 검색된 콘텐츠가 포함되기 전에 예상 형식 및 소스와 일치하는지 확인하십시오. 전체 방어 패턴은 프롬프트 인젝션 및 보안 가이드를 참조하십시오.
프로덕션 시스템의 RAG 파이프라인은 무엇입니까?
수집, 청킹, 임베딩, 벡터 스토어, 쿼리 임베딩, 시맨틱 검색, 관련성 필터링, 프롬프트 구성, LLM 생성, 소스 인용 포함 응답. 각 단계는 독립적으로 테스트하고 업그레이드할 수 있습니다.
벡터 데이터베이스 없이 RAG를 사용할 수 있습니까?
소규모 문서 세트의 경우 가능합니다. BM25 키워드 검색은 벡터 인프라 없이 10,000개 미만의 청크에서 작동합니다. 더 큰 컬렉션의 시맨틱 유사도를 위해서는 벡터 데이터베이스가 필요합니다. 하이브리드 검색(키워드 + 벡터)은 종종 단독보다 우수합니다.
참고 자료
- Lewis, P., et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020. https://arxiv.org/abs/2005.11401 — 검색 후 생성 아키텍처를 소개한 원본 RAG 논문.
- Gao, Y., et al. (2023). "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv:2312.10997. https://arxiv.org/abs/2312.10997 — 2023년까지의 RAG 아키텍처 및 변형에 대한 종합 조사.
- Guu, K., et al. (2020). "REALM: Retrieval-Augmented Language Model Pre-Training." ICML 2020. arXiv:2002.08909. https://arxiv.org/abs/2002.08909 — 언어 모델 학습에 검색을 통합하는 사전 학습 접근법.
- OpenAI. (2024). "Retrieval and Augmentation in Language Models." Platform documentation. https://platform.openai.com/docs/guides/prompt-engineering
자주 묻는 질문
RAG는 무엇을 뜻합니까?
RAG는 Retrieval-Augmented Generation(검색 증강 생성)의 약자입니다. 두 단계 프로세스입니다: 첫째, 지식 베이스에서 관련 문서를 검색하고, 둘째, 사용자의 질문과 함께 해당 문서를 LLM에 제공합니다. LLM은 학습 데이터만이 아닌 검색된 콘텐츠를 기반으로 답변합니다.
RAG는 어떻게 환각을 줄입니까?
RAG는 모든 답변을 사용자가 제어하는 문서에 고정시킵니다. 모델은 학습된 패턴만에 의존하는 대신 실제 소스 자료를 읽습니다. 소스에 답변이 없으면 모델은 꾸며내는 대신 "찾을 수 없습니다"라고 말할 수 있습니다.
RAG와 파인튜닝의 차이점은 무엇입니까?
RAG는 쿼리 시점에 지식을 검색합니다(동적이고 업데이트 가능). 파인튜닝은 학습 시점에 지식을 모델 파라미터에 내장합니다(정적이고 영구적). RAG는 업데이트가 빠르고, 파인튜닝은 스타일과 행동을 내장할 수 있습니다. 최신 정보를 위해서는 RAG가 우수합니다.
모든 언어 모델과 RAG를 사용할 수 있습니까?
예. RAG는 모델 무관입니다. 문맥이 포함된 프롬프트를 받아들이는 모든 LLM은 검색된 문서를 사용할 수 있습니다. GPT-5.5, Claude Opus, Gemini, Llama 같은 오픈소스 모델, Ollama를 통한 로컬 모델이 여기에 포함됩니다.
RAG의 최적 청크 크기는 얼마입니까?
대부분의 사용 사례: 인접 청크 간 10~20% 중복을 포함한 청크당 200~500단어. 더 작은 청크(50~100단어)는 정밀도를 높이고, 더 큰 청크(500단어 이상)는 문맥을 높이지만 관련 없는 단락이 포함될 위험이 있습니다.
RAG에서 관련성 임계값이란 무엇입니까?
유사도 점수 임계값입니다. 검색된 문서의 유사도가 임계값(예: 코사인 유사도 0.7) 미만이면 LLM에 전달되지 않습니다. 이는 낮은 품질이나 관련 없는 문맥이 모델을 혼란스럽게 하는 것을 방지합니다.
RAG가 큰 컨텍스트 창보다 낫습니까?
대규모 문서 컬렉션의 경우 그렇습니다. RAG는 시맨틱 유사도를 사용하여 수백만 개의 문서를 밀리초 단위로 효율적으로 검색합니다. 큰 컨텍스트 창은 더 비싸고 미리 어떤 문서를 포함할지 알아야 합니다.
RAG와 파인튜닝을 결합할 수 있습니까?
예. 스타일, 톤, 도메인 행동을 개선하기 위해 모델을 파인튜닝하십시오. 그런 다음 RAG를 사용하여 최신 사실에 근거를 두십시오. 이렇게 하면 일관된 행동 + 사실적 근거라는 두 가지 장점을 모두 누릴 수 있습니다.
RAG에서 프롬프트 인젝션 공격을 어떻게 방지합니까?
프롬프트에 포함하기 전에 검색된 콘텐츠를 검증하십시오. 시스템 지시사항과 검색된 텍스트 사이에 명확한 구분자를 사용하십시오. 검색된 콘텐츠를 절대 실행 가능한 지시사항으로 취급하지 마십시오. 검색된 문서에서 의심스러운 패턴을 모니터링하십시오.
RAG에 벡터 데이터베이스가 필요합니까?
소규모 컬렉션에는 불필요합니다. BM25 키워드 검색은 벡터 없이 10,000개 미만의 문서에서 작동합니다. 더 큰 컬렉션의 시맨틱 유사도를 위해서는 벡터 데이터베이스(Weaviate, Pinecone, Chroma, Milvus)가 필수적입니다.