RAG 비용 최적화는 단순히 API 호출 수를 줄이는 문제가 아닙니다. 검색 품질을 유지하면서 어떤 단계에서 토큰이 쓰이고, 어떤 단계에서 지연이 생기고, 어떤 단계에서 저장 비용이 커지는지 분해해서 봐야 합니다.
개요 #
RAG 파이프라인의 비용은 보통 네 곳에서 발생합니다.
- 문서 수집과 정제 비용
- 임베딩과 벡터 저장 비용
- 검색과 reranking 비용
- 최종 답변 생성에서의 토큰 비용
문제는 이 비용들이 서로 연결되어 있다는 점입니다. chunk를 너무 작게 나누면 검색 정확도는 좋아질 수 있지만 임베딩 수와 저장 비용이 늘어납니다. reranking을 과하게 넣으면 품질은 좋아질 수 있지만 지연과 호출 비용이 올라갑니다.
왜 중요한가 #
RAG 시스템은 PoC 단계에서는 저렴해 보여도, 문서 수와 사용자 질의가 늘면 비용 구조가 빠르게 변합니다.
- 검색 품질이 조금만 낮아져도 답변 재시도율이 올라갑니다
- reranking과 LLM 컨텍스트가 커질수록 토큰 비용이 커집니다
- 오래 보관하는 벡터 인덱스와 메타데이터가 저장 비용을 만듭니다
- evaluation을 안 하면 비용을 줄이다가 품질을 잃기 쉽습니다
Qdrant나 pgvector 같은 저장소를 쓰더라도, 비용은 DB 비용만이 아니라 전체 호출 경로에서 누적됩니다. 그래서 RAG Ops 관점으로 봐야 합니다.
비용 구조 #
| 구간 | 비용이 커지는 이유 |
|---|---|
| Ingestion | 문서 변환, OCR, 정제, 중복 제거 |
| Chunking | chunk 수 증가, overlap 증가 |
| Embedding | 전체 문서 벡터화와 재색인 |
| Retrieval | 후보군이 너무 많을 때 |
| Reranking | 상위 후보 재평가 호출 |
| Generation | 긴 컨텍스트와 긴 답변 |
| Evaluation | 실험 반복과 측정 데이터 |
핵심은 “싼 단계에서 문제를 잡고, 비싼 단계는 마지막에만 쓰는 것"입니다. 이 원칙이 비용을 가장 많이 줄입니다.
아키텍처 도식 #
RAG 비용 최적화는 보통 아래 순서로 설계합니다.
- ingestion에서 문서 품질을 정리합니다
- chunking 기준을 도메인별로 맞춥니다
- 1차 retrieval로 후보를 줄입니다
- reranking은 필요한 경우에만 켭니다
- answer generation에는 최소한의 근거만 넣습니다
- evaluation으로 비용 대비 품질을 점검합니다
Firecrawl, Tavily, Qdrant, pgvector, Hybrid Search 같은 기존 글의 주제들이 이 흐름에 각각 대응됩니다.
체크리스트 #
- chunk 크기와 overlap이 쿼리 유형에 맞는지 확인합니다
- top-k와 rerank-k를 분리해서 설계합니다
- 자주 반복되는 query는 캐시합니다
- 긴 원문 전체를 매번 LLM에 넣지 않습니다
- retrieval 실패 시 fallback 경로를 둡니다
- 비용 지표와 품질 지표를 함께 봅니다
- 샘플 질의셋으로 정기 평가합니다
결론 #
RAG 비용 최적화는 “더 적게 쓰는 것"이 아니라 “비싼 단계를 늦게, 좁게, 덜 자주 쓰는 것"입니다. 검색 품질을 먼저 유지하고, 그 다음에 retrieval과 generation의 토큰 구조를 줄여야 합니다.