이 문서는 AI 에이전트 섹션의 일부입니다.
RAG 파이프라인의 전체 구조
RAG 파이프라인은 크게 오프라인(데이터 준비) 과 온라인(질의 처리) 두 단계로 나뉩니다.
온라인: 질의 처리
Step 1: 문서 수집 및 파싱
문서 소스
Databricks에서 PDF 파싱
Step 2: 청킹 (Chunking)
💡 청킹(Chunking) 이란 긴 문서를 LLM이 처리할 수 있는 적절한 크기의 조각 으로 나누는 것입니다. RAG의 품질에 가장 큰 영향을 미치는 단계 중 하나입니다.
청킹 전략
최적의 청크 크기
청킹 구현
💡 chunk_overlap: 청크 간에 일부 텍스트를 겹치게 하면, 문장이 잘리는 것을 방지하고 맥락의 연속성을 유지할 수 있습니다. 일반적으로 chunk_size의 10~20% 정도를 권장합니다.
Step 3: 벡터 인덱스 생성
Step 4: 검색 및 답변 생성
RAG 품질 개선 전략
실전 인사이트: RAG 파이프라인의 90%는 청킹에 달려 있습니다
20년간 데이터 파이프라인을 설계해오면서, RAG만큼 “데이터 전처리가 결과 품질을 좌우하는” 시스템은 처음이었습니다. LLM이 아무리 좋아도, 검색되는 청크가 엉망이면 답변도 엉망입니다.청킹 실험에서 배운 것들
실제 프로덕션 RAG를 구축하면서 청킹 전략별로 A/B 테스트를 진행한 경험을 공유합니다.
💡 핵심 교훈: 청크에 제목, 문서명, 날짜 같은 메타데이터를 함께 포함시키세요. LLM이 “이 청크가 어떤 맥락의 내용인지” 이해하는 데 결정적인 차이를 만듭니다. 청크 본문 앞에 [제목: XXX | 작성일: 2025-01-15]를 붙이는 것만으로도 정확도가 5~10% 올라갑니다.
청크 경계 문제 — 가장 흔한 실패 원인
실전 인사이트: 임베딩 모델과 한국어 품질
한국어 임베딩 모델 선택 시 주의사항
임베딩 모델 선택에서 한국어 품질 차이는 극심합니다. 영어로는 잘 되는 모델이 한국어에서는 처참한 성능을 보이는 경우가 많습니다.⚠️ 실전 팁: 한국어 문서 RAG를 구축한다면, 반드시 한국어 테스트 쿼리 세트(최소 50개) 를 만들어서 임베딩 모델별 검색 품질을 비교하세요. “databricks-gte-large-en”은 영어에서는 탁월하지만, 한국어에서는 의미적 유사도가 떨어져서 “환불 정책”을 검색했는데 “배송 정보”가 나오는 경우가 있었습니다.
한국어 RAG에서의 하이브리드 검색 필수성
한국어는 조사(은/는/이/가) 와 어미 변환 이 다양해서, 순수 벡터 검색만으로는 한계가 있습니다. 예를 들어 “클러스터 생성 방법”과 “클러스터를 어떻게 만드나요”는 의미가 같지만, 임베딩 공간에서 거리가 있을 수 있습니다. 키워드 검색(BM25)과 벡터 검색을 결합한 하이브리드 검색 이 한국어 RAG에서는 거의 필수입니다.Kiwi 형태소 분석기를 활용한 BM25 검색, 한국어 임베딩 모델 선택, Re-ranking 전략 등 상세 가이드는 한국어 RAG 최적화 를 참고하세요.
프로덕션 RAG에서 가장 흔한 실패 패턴
패턴 1: Hallucination (환각)
프롬프트에 “문서에 없으면 모른다고 답하라”고 써도, LLM은 종종 자체 학습 데이터로 답변을 “지어냅니다”. 특히 위험한 상황은 다음과 같습니다.💡 실전 방어책:temperature=0.0~0.1로 설정하고, 시스템 프롬프트에 **“반드시 아래 문서에서 근거를 찾아 인용하며 답변하세요. 근거를 찾을 수 없으면 ‘해당 정보를 찾을 수 없습니다’라고 답하세요”**를 명시하세요. 그래도 100% 방지는 불가능하므로, Agent Evaluation의 faithfulness 메트릭으로 지속 모니터링해야 합니다.
패턴 2: 오래된 문서 문제
RAG에서 가장 교묘한 실패입니다. 사용자가 “현재 반품 정책이 뭔가요?”라고 물었는데, 2년 전 정책 문서가 검색되어 잘못된 답변을 하는 경우입니다.⚠️ 프로덕션 필수 사항: 문서에updated_at,version,status(active/archived)메타데이터를 반드시 포함시키세요.status=archived인 문서는 인덱스에서 아예 제외하거나, 검색 시 필터링해야 합니다. Delta Sync의TRIGGERED파이프라인을 사용하면, 원본 Delta 테이블에서 문서를 삭제하거나 상태를 변경했을 때 인덱스에 자동 반영됩니다.