RAG 구현에 필요한 공통 기반 기술
모든 RAG에 공통으로 적용되는 핵심 기반 기술을 설명합니다.
A. 청킹(Chunking) 전략
왜 청킹이 중요한가?
RAG 성능의 30~40%는 청킹에서 결정됩니다. 이 말이 과장이 아닙니다.
청킹이란 긴 문서를 작은 조각으로 나누는 것입니다. 이 조각들이 벡터 데이터베이스에 저장되고, 검색의 단위가 됩니다. 청킹을 어떻게 하느냐에 따라:
- 검색에서 관련 정보가 잘 찾아지는지
- 찾아진 정보가 충분한 맥락을 담고 있는지
- LLM이 정보를 이해하기 쉬운지
가 결정됩니다.
청킹 전략의 종류
1. 고정 길이 청킹 (Fixed-size Chunking)
가장 단순한 방법입니다. 문서를 일정한 길이(예: 500자, 1000자)로 자릅니다.
장점: 구현이 매우 쉽습니다. 단점: 문장이나 의미 단위가 중간에 잘릴 수 있습니다. “연차 휴가는”에서 잘리고 다음 청크가 “15일입니다”로 시작하면 두 청크 모두 불완전합니다.
2. 의미 기반 청킹 (Semantic Chunking)
문단, 섹션, 주제 등 의미 단위로 나눕니다.
방법:
- 빈 줄이나 제목을 기준으로 분할
- 문장 임베딩을 비교해서 의미가 크게 바뀌는 지점에서 분할
- LLM에게 “이 문서를 의미 단위로 나눠줘”라고 요청
장점: 각 청크가 완결된 의미를 담습니다. 단점: 청크 크기가 불균일해질 수 있습니다. 어떤 섹션은 너무 길고 어떤 섹션은 너무 짧을 수 있습니다.
3. Overlap(중첩) 사용
청크를 나눌 때 앞뒤로 일부 내용을 겹치게 합니다. 예를 들어 500자씩 나누되, 앞뒤 50자는 겹치게 합니다.
장점: 청크 경계에서 정보가 끊기는 문제를 완화합니다. 단점: 저장 공간이 늘어나고, 검색 시 중복 결과가 나올 수 있습니다.
특수 콘텐츠 처리
표(Table) 처리: 표는 일반 텍스트로 변환하면 의미가 손실됩니다. “삼성전자 | 10조 | 79조”처럼 변환하면 뭐가 뭔지 알 수 없죠. 표는 따로 추출해서 구조를 보존하거나, “삼성전자의 영업이익은 10조원이고 매출은 79조원입니다”처럼 자연어로 변환하는 것이 좋습니다.
코드 처리: 코드는 함수/클래스 단위로 청킹하는 것이 좋습니다. 함수 중간에서 잘리면 의미가 없습니다. 또한 코드와 주석을 함께 포함시켜야 맥락을 이해할 수 있습니다.
FAQ 처리: FAQ는 질문-답변 쌍을 하나의 청크로 유지해야 합니다. 질문만 있는 청크, 답변만 있는 청크로 분리되면 검색 품질이 떨어집니다.
청킹 크기 가이드
- 너무 작으면 (100자 이하): 맥락이 부족해서 LLM이 이해하기 어렵습니다.
- 너무 크면 (2000자 이상): 관련 없는 내용이 섞여 들어오고, 컨텍스트 윈도우를 낭비합니다.
- 일반적 권장: 300~1000자 (영어 기준 200~500 토큰)
하지만 이는 일반적인 가이드일 뿐, 도메인과 문서 특성에 따라 실험으로 최적값을 찾아야 합니다.
B. 임베딩(Embedding) 선택 & 업데이트 전략
일반 모델 vs 도메인 특화 모델
일반 임베딩 모델은 다양한 텍스트에 대해 학습되어 범용적으로 사용할 수 있습니다. OpenAI의 text-embedding-ada, Sentence Transformers의 all-MiniLM 등이 있습니다.
도메인 특화 모델은 특정 분야의 텍스트로 추가 학습되어 해당 분야에서 더 좋은 성능을 냅니다. 의학, 법률, 금융 등 전문 분야에서는 일반 모델보다 도메인 특화 모델이 훨씬 좋은 결과를 낼 수 있습니다.
선택 기준:
- 범용 서비스라면 일반 모델로 충분합니다.
- 전문 도메인이고 성능이 중요하다면 도메인 특화 모델을 고려하세요.
- 한국어 서비스라면 한국어 특화 모델(예: KoSentence-BERT)이 더 나을 수 있습니다.
재임베딩 시점
임베딩 모델을 바꾸거나 업그레이드하면, 기존에 저장된 모든 문서를 다시 임베딩해야 합니다. 이를 “재임베딩”이라고 합니다.
재임베딩이 필요한 경우:
- 더 좋은 임베딩 모델로 교체할 때
- 도메인 특화 모델로 전환할 때
- 임베딩 모델을 파인튜닝했을 때
재임베딩은 시간과 비용이 많이 듭니다. 문서가 수백만 개라면 며칠이 걸릴 수도 있습니다. 따라서:
- 처음부터 충분히 좋은 모델을 선택하세요.
- 재임베딩 파이프라인을 자동화해두세요.
- 점진적 재임베딩(일부씩 교체)을 고려하세요.
문서 버전 관리
문서가 업데이트되면 해당 청크의 임베딩도 업데이트해야 합니다. 이때 고려할 점:
- 어떤 문서가 변경되었는지 추적
- 변경된 청크만 재임베딩 (전체 재임베딩은 낭비)
- 이전 버전의 임베딩은 삭제할지, 보관할지
실무에서는 문서 관리 시스템과 RAG 시스템을 연동해서, 문서가 업데이트되면 자동으로 재임베딩이 트리거되도록 구성하는 경우가 많습니다.
C. 평가(Evaluation)
RAG 시스템을 만들었는데, “잘 동작하는지” 어떻게 알 수 있을까요? 체계적인 평가가 필요합니다.
주요 평가 지표
Recall@k (재현율)
“정답 문서가 상위 k개 검색 결과에 포함되어 있는 비율”입니다.
예: 100개의 질문이 있고, 각 질문마다 정답 문서가 정해져 있습니다. 검색 결과 상위 5개 안에 정답 문서가 들어있는 질문이 80개라면, Recall@5 = 80%입니다.
이 지표는 검색 품질을 측정합니다. 아무리 LLM이 좋아도 검색에서 정답 문서를 못 찾으면 답변할 수 없습니다.
Faithfulness (충실도)
“생성된 답변이 검색된 문서의 내용에 충실한지”를 측정합니다. LLM이 문서에 없는 내용을 지어내면(할루시네이션) Faithfulness가 낮아집니다.
측정 방법:
- 답변에서 각 문장을 추출
- 각 문장이 검색된 문서에서 뒷받침되는지 확인
- 뒷받침되는 문장의 비율 계산
Answer Relevancy (답변 관련성)
“생성된 답변이 질문에 얼마나 관련 있는지”를 측정합니다. 질문에 대해 관련 없는 내용을 장황하게 답하면 Answer Relevancy가 낮아집니다.
LLM-as-a-Judge의 한계
최근에는 LLM을 사용해서 답변의 품질을 평가하는 방법이 많이 사용됩니다. “GPT-4에게 이 답변이 얼마나 좋은지 1~5점으로 평가해달라고 하자”는 식입니다.
이 방법은 편리하지만 한계가 있습니다:
일관성 문제: 같은 답변을 여러 번 평가하면 다른 점수가 나올 수 있습니다.
편향 문제: LLM은 길고 자세한 답변을 선호하는 경향이 있습니다. 짧지만 정확한 답변보다 길지만 약간 부정확한 답변에 높은 점수를 줄 수 있습니다.
자기 선호 문제: GPT-4로 평가하면 GPT-4가 생성한 답변에 더 높은 점수를 줄 수 있습니다.
따라서 LLM-as-a-Judge는 빠른 피드백을 얻는 데는 유용하지만, 최종적인 품질 평가는 사람이 하는 것이 좋습니다. 특히 중요한 의사결정(모델 교체, 프로덕션 배포 등)에는 사람 평가를 병행하세요.
D. 비용 & 지연 관리
RAG 시스템을 운영하면서 비용과 응답 시간 관리는 매우 중요합니다. 특히 Agentic RAG처럼 반복적으로 LLM을 호출하는 경우 비용이 급격히 증가할 수 있습니다.
검색 횟수 관리
매번 검색하면 비용과 시간이 듭니다. 관리 방법:
- 캐싱: 같은 질문이 들어오면 이전 검색 결과를 재사용
- 검색 필요성 판단: Self-RAG처럼 검색이 필요한 경우에만 검색
- 쿼리 통합: 여러 쿼리를 하나로 합쳐서 검색 횟수 줄이기
컨텍스트 토큰 수 관리
LLM API는 보통 토큰 수에 따라 과금됩니다. 컨텍스트에 문서를 많이 넣을수록 비용이 올라갑니다.
관리 방법:
- Top-k 제한: 검색 결과 중 상위 k개만 사용 (예: 상위 3개)
- 문서 압축: 긴 문서에서 핵심 문장만 추출
- 동적 조절: 질문의 복잡도에 따라 컨텍스트 크기 조절
Agent Loop 제한
Agentic RAG에서 에이전트가 무한히 반복하면 비용이 폭발합니다. 반드시 제한을 두세요:
- 최대 반복 횟수: “10번 넘으면 중단”
- 최대 LLM 호출: “총 20회 넘으면 중단”
- 최대 시간: “2분 넘으면 중단”
- 최대 비용: “API 비용 $1 넘으면 중단”
비용 최적화 전략
모델 티어링: 모든 작업에 GPT-4를 쓸 필요 없습니다. 간단한 작업은 저렴한 모델(GPT-3.5)로, 복잡한 작업만 고급 모델(GPT-4)로.
프롬프트 최적화: 불필요하게 긴 프롬프트는 줄이세요. 시스템 프롬프트가 너무 길면 매 호출마다 토큰이 낭비됩니다.
배치 처리: 실시간이 아닌 작업은 배치로 모아서 처리하면 효율적입니다.