RAG (Retrieval-Augmented Generation, 검색 증강 생성)

한 줄 정의

LLM이 답변 생성 시 외부 데이터베이스에서 관련 chunk를 벡터 검색해 컨텍스트에 주입하는 방식. 일명 "오픈북 테스트" — 학습 데이터에 없는 정보·최신 정보를 답할 수 있게. 본 LLMWiki Karpathy LLM Wiki 패턴의 핵심 대조 개념 — "Compilation ≠ RAG".

요약

본 카드는 본 LLMWiki Ch.7 회차의 대조 개념. RAG는 매 질의마다 검색 → 누적 ❌. LLMWiki Compilation은 한 번 컴파일하면 그래프 자체 활용 → 누적 ✓. 사역 도메인에서는 Compilation이 압도적.

본문 상세

1. RAG의 작동 흐름

[사용자 질의]
   ↓
[질의를 벡터로 임베딩]
   ↓
[벡터 DB에서 유사 chunk 검색 (top-k)]
   ↓
[검색된 chunk + 원래 질의 → LLM]
   ↓
[LLM이 chunk 참조해 답변 생성]

2. RAG vs Compilation (★ Ch.7 핵심 대조)

3. RAG의 좋은 점

• 큰 데이터셋도 OK (수만 ~ 수억 문서)
• 새 자료 즉시 검색 가능
• 인프라 표준화 (Pinecone·Weaviate·Milvus·Chroma)
• 기업 환경에 적합

4. RAG의 한계 (사역 도메인)

• 누적 학습 ❌ — 매 질의마다 처음부터
• 종합·재구조화 ❌ — chunk 단편만
• 블랙박스 — 사람이 모든 chunk 검토 ❌
• 신학 가드레일 어려움 — chunk 단위 검증 어려움
• 사역자 진입 장벽 높음 — 인프라 비용·전문성

5. RAG가 적합한 경우

• 우리말성경 66권 RAG (사실 검색 — 본 LLMWiki도 부분 활용)
• 일대일 양육 교재 RAG
• 신학 사전 RAG
• → 사실 검색·인용 정확성에 RAG 적합

6. Compilation이 적합한 경우 (본 LLMWiki)

• 9 Chapter 시리즈 — 누적·재구조화
• wiki 카드 그래프 — wikilink로 의미 연결
• 사역 자료 통합 — 1 source → 10~15 카드

→ 사역 지식의 누적·종합에는 Compilation 우선.

7. 본 LLMWiki의 하이브리드

본 LLMWiki는 RAG + Compilation 병용:

• Compilation: wiki 카드 작성·그래프
• RAG (선택적): 우리말성경 인용 검증, 일대일 교재 검색

→ 어느 한쪽만 ❌, 적합한 곳에.

8. 본 시리즈 인용

한계와 주의사항

• RAG가 모든 답을 보장 ❌ — 검색 실패 시 환각
• Vector DB는 신학적 분별 ❌ — Canon 9 가드레일 별도
• 한국어 임베딩 정확성 ↓ — 검증 필수
• RAG가 사역 자료 누적의 답 ❌ — Compilation 병용

핵심 인용

"Compilation ≠ RAG. RAG는 매 질의 검색, Compilation은 한 번 컴파일." — Karpathy

"사역 도메인에서는 Compilation이 압도적." — 본 LLMWiki Ch.7

관련

• term/vector-embedding — RAG의 기술 토대
• term/knowledge-graph — RAG의 대안 (LLMWiki = 그래프)
• term/llm-large-language-model — RAG의 클라이언트
• concept/karpathy-llm-wiki-pattern — Compilation 모델
• synthesis/ai-seonyong-ch7-llmwiki-knowledge-graph — Ch.7 ★

"RAG는 검색, Compilation은 누적. 사역에는 Compilation."