LLM을 위한 RAG 파이프라인 구현 (RAG Pipeline Implementation for LLMs)¶

개요¶

LLM 기반 시스템을 구축할 때 직면하는 주요 과제들:

도메인 지식 격차: 일반 LLM의 특정 분야 지식 부족
사실성 문제: 최신 정보에 대한 정확한 답변 불가
환각 현상: 존재하지 않는 정보를 그럴듯하게 생성
신뢰성 부족: 답변의 출처를 추적할 수 없음

RAG는 이러한 문제들을 체계적으로 해결하는 실용적인 솔루션입니다. 이 페이지에서는 RAG 파이프라인의 각 구성 요소를 상세히 설명하고 실제 구현 방법을 다룹니다.

RAG 파이프라인의 구조¶

RAG 시스템은 네 가지 핵심 단계로 구성됩니다:

1. 문서 전처리 (Preprocessing)
   ├─ 문서 수집
   ├─ 텍스트 정제
   └─ 청킹 (Chunking)
        ↓
2. 인덱싱 (Indexing)
   ├─ 임베딩 생성
   ├─ 벡터 정규화
   └─ 벡터 저장소 저장
        ↓
3. 검색 (Retrieval)
   ├─ 쿼리 임베딩
   ├─ 유사도 계산
   └─ 관련 문서 추출
        ↓
4. 생성 (Generation)
   ├─ 프롬프트 구성
   ├─ LLM 호출
   └─ 최종 답변 생성

1단계: 문서 청킹 (Document Chunking)¶

문제: 문서의 크기와 구조¶

원본 문서들은 다양한 형식과 크기를 가집니다: - PDF 논문: 수십~수백 페이지 - 웹 페이지: 수백~수천 단어 - 사내 정책: 불규칙한 구조

LLM의 컨텍스트 윈도우에 맞추려면 문서를 작은 단위로 분할해야 합니다.

청킹 전략¶

1. 고정 크기 청킹 (Fixed-Size Chunking)¶

가장 간단한 방법이지만 문맥을 무시할 수 있습니다.

# 예시: 512 토큰 단위로 청킹
chunk_size = 512
overlap = 128  # 인접 청크 간 중복

chunks = []
for i in range(0, len(text), chunk_size - overlap):
    chunk = text[i:i + chunk_size]
    chunks.append(chunk)

장점: 구현 간단, 계산 효율적 단점: 문장 중간에 자를 수 있음

2. 의미 기반 청킹 (Semantic Chunking)¶

문장, 단락, 섹션 단위로 문서를 분할합니다.

원본 문서:
┌─────────────────────────────────────────┐
│ 제목: 법인세법 개정안                  │
├─────────────────────────────────────────┤
│ 제1장. 기본원칙                        │
│ 제1조. 정의                            │
│ 제2조. 적용 범위                       │
├─────────────────────────────────────────┤
│ 제2장. 세율                            │
│ 제3조. 법인세 세율                     │
└─────────────────────────────────────────┘

↓ 의미 기반 청킹

청크1: 제1장 (정의, 적용 범위)
청크2: 제2장 (세율)
청크3: 부칙

!!! 💡 실전 팁 - 한국 문서: 장, 절, 항 같은 법령 체계를 활용한 청킹이 효과적 - 마크다운: 제목(#, ##, ###)을 기준으로 청킹 - 겹침 설정: 5-10% 정도의 중복으로 문맥 연속성 유지

3. 하이브리드 청킹 (Hybrid Chunking)¶

문서 구조를 인식하면서 크기 제약을 고려합니다.

의미 단위 (문단/섹션)
        ↓
크기 체크 (512 토큰 이상?)
        ├─ YES → 그 단위로 청킹
        └─ NO → 다음 단위와 병합

청킹 파라미터 선택¶

파라미터	권장 범위	설명
청크 크기	256-1024 토큰	LLM 컨텍스트의 10-20%
겹침	0-20%	인접 청크 간 중복 비율
분할 기준	문장/단락	의미 단위 우선

2단계: 임베딩과 벡터 저장소 (Embedding and Vector Database)¶

임베딩이란?¶

텍스트를 수치 벡터로 변환하여 의미적 유사성을 계산할 수 있게 합니다.

"법인세 세율은 23%입니다"
    ↓ 임베딩
[0.12, -0.45, 0.78, ..., 0.23]  (1536 차원)

"법인세율이 몇 퍼센트인가요?"
    ↓ 임베딩
[0.13, -0.44, 0.79, ..., 0.24]  (1536 차원)

↓ 코사인 유사도 = 0.98 (매우 유사!)

2026년 주요 임베딩 모델¶

모델	제공사	차원	특징
text-embedding-3-large	OpenAI	3,072	매우 높은 정확도, 한국어 우수
Claude Embeddings	Anthropic	1,024	컨텍스트 인식, 빠른 속도
Gemini Embedding 001	Google	768	멀티모달 지원, 비용 효율
multilingual-e5-large-ko	한국 오픈소스	1,024	한국어 최적화

!!! 💡 한국 기업을 위한 팁 - 한국어 문서: multilingual-e5-large-ko 또는 OpenAI의 한국어 지원 모델 사용 - 혼합 언어: Gemini Embedding으로 영한 문서 동시 처리 - 비용 최적화: 작은 모델로 시작 후 필요시 업그레이드

벡터 저장소¶

임베딩된 청크들을 저장하고 빠르게 검색하는 데이터베이스입니다.

벡터 저장소의 구조:

청크 ID | 텍스트 | 임베딩 벡터 | 메타데이터
--------|--------|-----------|----------
001 | "법인세율..." | [0.12, ...] | {"출처": "법인세법", "장": 2}
002 | "부가가치세..." | [0.45, ...] | {"출처": "부가가치세법", "장": 1}
003 | "근로소득..." | [0.67, ...] | {"출처": "소득세법", "장": 3}

주요 벡터 저장소¶

저장소	특징	규모
Pinecone	관리형, 높은 성능	대규모 (수억 벡터)
Weaviate	오픈소스, 유연함	중규모 (수천만 벡터)
Milvus	오픈소스, 빠름	대규모
Qdrant	최신 기술, 신속	중규모

3단계: 검색 전략 (Retrieval Strategies)¶

의미적 검색 (Semantic Search)¶

벡터 유사도를 기반으로 관련 문서를 찾습니다.

사용자 쿼리: "법인세 세율이 얼마인가?"
    ↓
쿼리 임베딩: [0.13, -0.44, 0.79, ...]
    ↓
벡터 저장소에서 코사인 유사도 계산
    ↓
결과:
1. "법인세 세율은 23%입니다" (유사도: 0.98)
2. "법인세 신고 기한은 3월입니다" (유사도: 0.75)
3. "법인세 면제 대상은..." (유사도: 0.68)

하이브리드 검색 (Hybrid Search)¶

의미적 검색과 키워드 검색을 결합합니다.

쿼리: "법인세"

의미적 검색 결과:
→ 법인세, 소득세, 부가가치세 등 조세 관련 문서

키워드 검색 결과:
→ 정확히 "법인세"라는 단어가 포함된 문서

결합된 결과:
→ 둘 다 만족하는 문서 우선

!!! 💡 실전 팁 - 정확도 중시: 하이브리드 검색 사용 (의미 50% + 키워드 50%) - 속도 중시: 의미적 검색만 사용 - 법령/정책: 정확한 조항 번호를 찾아야 하므로 하이브리드 필수

검색 결과 순위 최적화¶

# 재순위 지정 (Re-ranking)
# 1차: 벡터 유사도로 상위 100개 추출
# 2차: 더 정교한 모델로 재순위 지정

initial_results = vector_search(query, top_k=100)
final_results = rerank_model.rank(query, initial_results, top_k=5)

4단계: 프롬프트 설계 (Prompt Design for RAG)¶

기본 프롬프트 구조¶

당신은 법률 전문가입니다. 주어진 문서를 바탕으로만 답변하세요.

[검색 문서]
{retrieved_documents}

[사용자 질문]
{user_question}

[지시사항]
- 문서에 없는 정보는 "정보 없음"이라고 답변하세요.
- 관련 조항 번호를 인용하세요.
- 최대 500자 이내로 답변하세요.

답변:

효과적인 RAG 프롬프트 기법¶

1. 역할 지정 (Role Assignment)¶

"당신은 삼성전자 HR 담당자입니다.
회사 정책에 따라 직원의 질문에 답변합니다."

2. 출처 강조¶

"다음 회사 문서들을 참고하여 답변하세요:

문서1: 휴가 정책 (2024년 개정)
문서2: 보수 규정 (2024년 적용)
문서3: 근로시간 기준 (2024년)

이 문서들의 내용에만 기반하여 답변하세요."

3. 아웃풋 포맷 명시¶

"다음 JSON 형식으로 답변하세요:
{
  "답변": "...",
  "관련_조항": ["조항1", "조항2"],
  "신뢰도": "높음/중간/낮음",
  "추가_정보": "..."
}

4. 한국 기업을 위한 예시¶

# LangChain/LlamaIndex 스타일 프롬프트

rag_prompt = """
당신은 {company_name} 정책 자문 AI입니다.

아래의 사내 정책 문서를 바탕으로만 답변하세요:
{context}

직원 질문: {question}

답변 시 주의사항:
1. 문서에 명시된 정보만 사용하세요
2. 정책 변경 날짜를 명시하세요
3. 불확실한 경우 "미결정"이라고 표시하세요
4. 관련 부서를 안내하세요

답변:
"""

한국 실무 예시: 법률 문서 검색 시스템¶

상황: 법무팀이 법규 해석을 위한 RAG 시스템 구축

1. 문서 준비¶

법률 문서:
├─ 법인세법 (장/절/조 단위로 청킹)
├─ 부가가치세법
├─ 소득세법
├─ 판례집 (판례별로 청킹)
└─ 국세청 예규 (유형별로 청킹)

2. 임베딩 및 인덱싱¶

각 청크마다:
- text-embedding-3-large로 임베딩
- 메타데이터: 법령명, 조항, 시행일, 최신개정일
- Pinecone 벡터 저장소에 저장

3. 검색 로직¶

법무팀 변호사: "개인사업자의 소득세율이 어떻게 되나?"

검색 단계:
1. 의미적 검색 → "소득세", "세율", "개인사업자" 관련 청크
2. 키워드 검색 → "소득세율" 정확히 포함된 청크
3. 메타데이터 필터링 → 최신 개정본만 선택

결과:
- 소득세법 제13조 (종합소득세 세율)
- 국세청 유권해석 (개인사업자 적용 사례)

4. 생성 단계¶

Claude 4.6으로 처리:

입력:
- 검색된 법조문 3개
- 관련 판례 2개
- 사용자 질문

출력:
"개인사업자의 종합소득세율은 소득세법 제13조에 따라
6% ~ 49%의 누진세율이 적용됩니다.

[관련 조항]
- 소득세법 제13조 1항 (종합소득세 세율)
- 동법 시행령 제48조 (세율 적용 기준)

[판례]
- 대법원 2021-세-12345호 (개인사업자 소득 인정 사례)"

!!! 💡 실전 팁 - 법률 RAG의 핵심: 정확한 조항 인용이 필수 - 버전 관리: 법령 개정에 따라 청크 버전 기록 - 신뢰도 표시: 최신 법령 기반 vs 판례 기반 구분 - 정기 검토: 월 1회 이상 법령 업데이트 확인

평가 및 최적화¶

RAG 성능 지표¶

지표	설명	목표
검색 정확도 (Precision)	상위 K개 중 관련 문서 비율	> 80%
검색 재현율 (Recall)	전체 관련 문서 중 검색된 비율	> 75%
MRR (Mean Reciprocal Rank)	첫 관련 문서의 순위	> 0.8
생성 품질 (BLEU/ROUGE)	생성 답변의 품질	모델별 상이

📝 핵심 정리¶

RAG 파이프라인 구성¶

문서 청킹: 의미 기반 청킹 추천 (512 토큰, 10% 겹침)
임베딩: 한국어 최적화 모델 사용 (text-embedding-3-large 또는 multilingual-e5-large-ko)
벡터 저장소: 규모와 성능에 맞는 저장소 선택
검색: 하이브리드 검색으로 정확도 향상
프롬프트: 역할 정의, 출처 강조, 형식 명시

최적화 포인트¶

검색 품질: 임베딩 모델 선택, 하이브리드 검색
생성 품질: 프롬프트 엔지니어링, 아웃풋 포맷
비용: 청크 크기, 저장소 선택, 배치 처리

한국 기업 구현 팁¶

법률/정책 문서는 정확한 조항 인용 필수
정기적인 문서 업데이트 프로세스 구축
메타데이터를 최대한 활용한 필터링

다음 단계¶

다음 페이지에서 RAG의 신뢰성 평가와 인용 관리 방법을 배우겠습니다.