RAG: LLM의 지식 한계를 넘어서

문제: LLM이 모든 것을 알 수는 없다

GPT-4나 Claude 같은 대형 언어 모델(large language model, LLM)은 놀라운 성능을 보여주지만, 근본적인 한계가 있다. 대표적으로 학습 데이터의 시간적 제약으로 인한 지식 cutoff, 특정 도메인이나 기업 내부 정보에 대한 접근 불가, 그리고 사실이 아닌 내용을 그럴듯하게 생성하는 환각(hallucination) 현상 등이 문제다.

 

이 문제를 해결하기 위해 떠오른 방법 중 하나가 파인튜닝(fine-tuning)이지만, 이 방식은 새로운 정보를 반영하기엔 비효율적이다. 파인튜닝은 모델의 전반적인 지식을 확장하기보다는 특정 도메인이나 스타일에 맞추는 용도로 적합하며, 새로운 지식이 생길 때마다 모델을 다시 학습시켜야 하므로 비용과 시간이 막대하게 소모된다.

 

챗GPT에게 'RAG' 이미지 생성을 요청했더니 이렇게 만들었다.

 

이런 한계를 극복하기 위해 등장한 것이 바로 RAG(Retrieval-Augmented Generation, 검색 증강 생성)다. RAG는 모델 자체를 변경하지 않고, 외부 지식을 동적으로 주입하여 LLM의 답변 품질을 개선하는 아키텍처 패턴이다.

 

RAG의 작동 원리: Retrieve, Augment, Generate

RAG는 이름 그대로 세 단계로 작동한다.

 

RAG는 3단계

Retrieval

먼저, 사용자 쿼리를 임베딩 벡터로 변환하고, 미리 임베딩해 둔 문서 벡터들과의 유사도를 계산하여 관련성이 높은 문서 청크(chunk)를 검색한다. 이 과정에서 cosine similarity나 ANN(Approximate Nearest Neighbor) 알고리즘이 사용된다. Pinecone, Weaviate, ChromaDB 같은 벡터 데이터베이스가 이 역할을 담당한다.

Augmentation

검색된 문서를 LLM의 컨텍스트로 구성하는 단계다. 여기서 핵심은 chunk size와 overlap 설정이다. 너무 작으면 문맥이 끊기고, 너무 크면 노이즈가 증가한다. 일반적으로 (임베딩 모델에 따라 다르지만) 512~1024 토큰 단위로 청킹하고0, 10-20% 정도의 overlap을 두어 경계에서의 정보 손실을 방지한다. 이렇게 구성된 컨텍스트는 프롬프트에 주입되어 "다음 문서를 참고하여 답변하라"는 형태로 LLM에 전달된다.

Generation

마지막으로 LLM이 주입된 컨텍스트를 활용해 답변을 생성한다. 이때 모델은 자신의 파라메트릭 지식(기존 학습 내용)과 외부에서 주입된 지식을 결합하여 보다 정확하고 최신의 정보를 제공할 수 있다.

 

실무 구현 시 마주하는 선택지들

Chunking 전략

가장 먼저 결정할 것은 문서를 어떻게 나눌지다. Fixed-size chunking은 구현이 간단하지만 문맥 단위를 무시하고 자를 수 있다. Semantic chunking은 문장이나 단락 경계를 고려하지만 크기가 불균등해질 수 있다. 최근에는 LLM을 활용해 의미적으로 응집된 단위로 분할하는 방법도 등장했다.

임베딩 모델 선택

OpenAI의 text-embedding-3나 Cohere의 embed-v3는 높은 품질을 제공하지만 API 비용이 발생한다. BGE, E5 같은 오픈소스 모델은 자체 호스팅이 가능하지만 성능에서 다소 차이가 있다. 다국어 지원이 필요하다면 multilingual 모델을 고려해야 한다.

Retrieval 품질 향상

단순 벡터 검색을 넘어서야 높은 품질을 얻을 수 있다. 예를 들어, BM25 같은 키워드 기반 검색(주로 Elasticsearch나 OpenSearch에서 수행)을 벡터 검색과 결합한 hybrid search가 효과적이다. 또한 Cohere rerank, Cross-encoder와 같은 재정렬(reranking) 모델을 활용하거나, 쿼리를 변환해 검색 효율을 높이는 HyDE(Hypothetical Document Embeddings) 기법도 유용하다.

 

어디에 활용할 수 있는가

RAG의 가장 명확한 활용처는 기업 내부 문서 검색 및 QA 시스템이다. Confluence, Notion, Google Docs 등 여러 문서 저장소에 흩어진 정보를 통합하여 "우리 회사의 휴가 정책은?" 또는 "프로젝트 X의 아키텍처 결정 배경은?" 같은 질문에 즉시 답할 수 있는 시스템을 만들 수 있다.

또한 코드베이스 이해와 생성에도 강력하다. GitHub 저장소를 벡터화하면, "이 프로젝트에서 인증은 어떻게 처리하나?" 같은 질문에 관련 코드 스니펫과 함께 설명을 제공할 수 있다. Cursor나 Copilot의 codebase indexing이 바로 이 원리다.

실시간 정보가 필요한 챗봇도 RAG의 좋은 사례다. 제품 카탈로그, 재고 정보, 가격 데이터를 벡터 DB에 저장하고 주기적으로 업데이트하면, LLM의 학습 시점과 무관하게 최신 정보를 제공할 수 있다. 또한 금융, 의료, 법률 같은 규제 산업에서는 컴플라이언스 문서를 관리하고 정책 준수 여부를 검증하는 데에도 RAG가 활용된다.

 

한계와 발전 방향

물론 RAG도 만능은 아니다. Retrieval 단계에서 관련 문서를 찾지 못하면 답변 품질이 떨어지고, 컨텍스트 길이 제한으로 많은 문서를 주입할 수 없다. 다만 최근에는 Claude 3.5 Sonnet(200K 토큰), Gemini 1.5 Pro(최대 2M 토큰) 등 대형 모델들의 컨텍스트 윈도우가 대폭 확장되면서 이 한계가 완화되고 있다.

또한 검색된 문서 자체가 잘못되었거나 모순되는 경우 LLM이 혼란스러운 답변을 생성할 수 있다. 이런 한계를 극복하기 위해 Advanced RAG 기법들이 연구되고 있다.

• Self-RAG: LLM이 스스로 검색 필요성을 판단하고, 결과를 평가하며 답변을 조정한다.
• CRAG(Corrective RAG): 검색된 문서가 부정확하거나 부족할 때, LLM이 자체적으로 교정하거나 웹 검색을 추가로 수행한다.
• Agentic RAG: 쿼리 재작성, 멀티홉 검색, 외부 도구 사용을 결합하여 복잡한 질문에 답한다.

 

마무리

RAG는 LLM을 더 똑똑하게 활용하기 위한 실용적이고 확장 가능한 패턴으로 자리잡았다. 완벽하지는 않지만, 적절한 설계와 구현으로 지식 업데이트, 내부 문서 검색, 코드 분석 등 다양한 영역에서 LLM의 한계를 효과적으로 보완할 수 있다.

이제 당신의 서비스에 RAG를 어떻게 적용할지 고민할 차례다.

 

---

관련 도서

라마인덱스로 배우는 데이터 기반 AI 애플리케이션