1 RAG의 개념

1.1 RAG란?

1.1.1 RAG란 무엇인가?

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 외부 데이터베이스에서 정보를 검색(Retrieval)한 후, LLM이 이를 활용하여 답변을 생성(Generation) 하는 것 입니다.

기존 LLM은 학습된 데이터만을 기반으로 답변을 생성하는 반면, RAG를 활용하면 최신 데이터나 내부 문서를 추가적으로 검색하여 활용할 수 있기 때문에 보다 정확하고 문맥에 맞는 답변을 제공할 수 있습니다. 이는 특히 기업 내부 문서 검색, 최신 뉴스 기반의 챗봇, 기술 지원 시스템 등에서 중요한 역할을 할 수 있습니다.

1.1.2 기존 LLM의 한계를 보완하는 RAG

LLM은 강력한 자연어 생성 능력을 가지고 있지만, 몇 가지 한계가 있습니다. RAG는 이러한 한계를 보완하여 보다 실용적인 AI 시스템을 구축하는 데 도움을 줄 수 있습니다.

LLM은 최신 정보를 반영하기 어렵습니다.

기존 LLM은 학습이 완료된 시점의 데이터까지만 알고 있음. 이후 발생한 새로운 정보는 모델이 알지 못하기 때문에 최신 데이터를 기반으로 한 답변이 어려움 RAG는 외부데이터 검색을 통해 최신정보를 반영하여 이를 해결할 수 있음 LLM은 특정 도메인의 세부 정보를 잘 모를 수 있습니다.

일반적인 LLM은 광범위한 데이터를 학습하지만, 특정 기업 내부 문서나 전문적인 기술 문서 등의 세부 정보를 학습하는 것은 어려움 RAG를 활용하면 기업 내부 데이터베이스, 논문, 기술 문서 등의 정보를 검색하여 보다 정확한 답변을 생성할 수 있음 LLM은hallucination(환각)이 발생할 수 있습니다.

LLM은 때때로 학습된 데이터에 없는 내용을 창작하여 사실과 다른 정보를 생성할 수 있음 RAG는 검색된 실제 문서를 바탕으로 답변을 생성하기 때문에 환각 문제를 줄이는 데 도움이 됨

2 핵심 구성 요소

RAG를 효과적으로 수행하기 위해서는 데이터를 검색하고 처리하는 과정이 최적화되어야 하며, 이 과정에서 여러 가지 핵심 기술이 사용됩니다. 아래에서 RAG가 원활하게 동작하기 위해 필요한 주요 구성 요소를 단계별로 살펴보겠습니다.

2.1 데이터 전처리

2.1.1 데이터 전처리의 중요성

RAG의 성능을 높이기 위해서는 검색할 문서가 구조적으로 정리되어 있어야 하며, 불필요한 정보가 제거된 상태여야 합니다. 데이터가 정제되지 않은 상태에서는 검색 성능이 저하될 수 있으며, 정확하지 않은 정보가 검색될 가능성이 높아집니다. 데이터 전처리는 문서의 일관성을 유지하고, 검색 및 임베딩 과정에서 불필요한 정보를 배제하는 것을 목표로 합니다. 데이터의 품질이 낮으면 RAG의 검색 과정에서 불필요한 문서가 반환되거나, 필요한 정보가 검색되지 않을 가능성이 커지므로, 데이터 전처리는 필수적인 과정입니다.

데이터 전처리의 과정을 살펴보겠습니다.

2.1.1 텍스트 정제

문서의 텍스트를 정제하는 과정에서는 데이터의 일관성을 유지하고 불필요한 요소를 제거하는 작업이 포함됩니다. 대표적인 텍스트 정제 작업은 다음과 같습니다.

불필요한 기호 및 특수 문자 제거

텍스트 내의 HTML 태그, 이모지, 기호 등의 불필요한 요소를 제거하여 가독성을 높입니다. 불필요한 공백 정리

여러 개의 연속된 공백, 줄바꿈 등을 하나로 정리하여 문장의 일관성을 유지합니다. 대소문자 통일

검색 시 대소문자가 일치하지 않아 검색 성능이 저하될 수 있으므로, 소문자로 변환하여 일관성을 유지합니다.

2.1.2 중복 데이터 제거

완전히 동일한 문서 제거

동일한 내용이 여러 번 포함된 경우, 하나의 문서만 유지하고 나머지는 삭제합니다. 의미적으로 유사한 문서 필터링

문서가 완전히 동일하지 않더라도, 90% 이상 동일한 내용을 포함하는 경우 하나만 유지할 수 있습니다.

2.1.3 데이터 형식 변환

문서의 원본 데이터가 PDF, Word 파일, 스캔된 이미지 등 다양한 형식으로 존재할 수 있습니다. 이러한 데이터를 RAG에서 활용하려면 텍스트 기반으로 변환하는 과정이 필요합니다.

OCR(Optical Character Recognition) 활용

이미지 기반 문서를 텍스트로 변환하는 과정입니다. 스캔된 문서나 사진에 포함된 텍스트를 추출할 때 유용합니다. PDF 및 Word 문서 변환

PDF나 Word 문서를 직접 처리할 수 있도록 텍스트로 변환하는 과정이 필요합니다. JSON, CSV 등의 구조화된 데이터 활용

데이터가 테이블 형식으로 저장된 경우, 이를 적절한 문장 형식으로 변환하여 검색할 수 있도록 처리합니다.

2.1.4 메타데이터 추가

검색 성능을 더욱 향상시키기 위해, 각 문서에 메타데이터(Metadata)를 추가하는 방식이 사용될 수 있습니다. 메타데이터는 문서의 분류, 날짜, 작성자 등과 같은 추가 정보를 포함하며, 보다 정교한 검색 필터링이 가능하도록 도와줍니다.

문서의 출처 (Source)

문서가 어디에서 온 것인지(내부 문서, 위키, 논문 등)를 저장합니다. 날짜 (Date)

최신 문서를 우선적으로 검색할 수 있도록 타임스탬프 정보를 추가합니다. 주제 태그 (Tags)

문서의 주요 주제를 태그로 저장하여 검색 시 활용할 수 있습니다.

2.2 청킹 (Chunking)

청킹(Chunking)은 문서를 작은 단위로 나누어 검색 성능을 향상시키는 과정입니다. 문서 전체를 검색 대상으로 삼을 경우 불필요한 정보가 함께 검색될 가능성이 높고, 연산 비용이 증가할 수 있습니다. 따라서 문서를 적절한 크기로 나누어 검색 성능을 최적화하는 것이 중요합니다.

2.2.1 청킹이 필요한 이유

검색의 정확도 향상

문서 전체를 검색하는 대신, 더 적절한 문서 청크만 검색할 수 있음 검색된 청크가 작을수록, 필요한 정보를 더 적절하게 찾을 가능성이 높아짐. 청크가 너무 작은 경우 청크 내의 문맥을 파악하기 힘들기 때문에 적절한 크기로 청킹해야함 연산 비용 절감

검색할 데이터가 작아지면, 벡터 검색 및 인덱싱에 필요한 연산량이 감소 검색 속도가 빨라지고, 모델이 처리해야 하는 데이터의 양이 줄어듦 LLM의 응답 품질 개선

문장이 적절한 크기로 나누어지면, 검색된 정보가 LLM의 답변 생성에 더 적절하게 활용될 수 있음 너무 긴 문서는 검색 후에도 LLM이 중요한 내용을 추출하는 데 어려움을 겪을 수 있음

2.2.2 청킹 기법

문서의 내용과 검색 목적에 맞게 적절한 방식으로 청킹해야합니다. 다양한 청킹 기법 중 가장 기본적인 기법들에 대해 알아보겠습니다. 아래 문장을 예시로 각각의 청킹 기법을 비교하겠습니다.

고정 길이 청킹 (Fixed-size Chunking) 일정한 문자 수 또는 토큰 수를 기준으로 문서를 나누는 방식

예를 들어, 500자 또는 256개 토큰 단위로 문서를 청킹할 수 있음

"RAG는 검색과 생성을 결합한 모델입니다. 이를 통해 "

"LLM은 외부 데이터를 활용하여 보다 정확한 답변을 생"

"성할 수 있습니다. RAG는 여러 산업에서 사용되고 "

"있습니다."

구현이 쉽고 빠름, 검색 성능이 비교적 안정적 문장이 중간에서 끊길 위험이 있어 문맥이 손실될 가능성 있음 대량의 문서를 빠르게 처리해야 하는 경우 문장 단위 청킹 (Sentence-based Chunking) 문장을 기준으로 나누는 방식

"RAG는 검색과 생성을 결합한 모델입니다."

"이를 통해 LLM은 외부 데이터를 활용하여 보다 정확한 답변을 생성할 수 있습니다."

"RAG는 여러 산업에서 사용되고 있습니다."

문맥이 유지되며, 청크가 의미 단위로 구성됨 문장 길이가 일정하지 않아 검색 효율이 일정하지 않을 수 있음 문서의 문장 구조가 중요한 경우 의미 기반 청킹 (Semantic Chunking) AI 모델을 활용하여 의미적으로 연관된 문장들을 하나의 청크로 묶는 방식

유사한 개념이나 주제를 다루는 문장들을 같은 청크로 분류

"RAG는 검색과 생성을 결합한 모델입니다. 이를 통해 LLM은 외부 데이터를 활용하여 보다 정확한 답변을 생성할 수 있습니다."

"RAG는 여러 산업에서 사용되고 있습니다."

문맥이 완벽하게 유지되며, 검색 결과가 더욱 정확함 AI 모델을 활용해야 하므로 연산 비용이 증가함 문맥이 중요한 문서 (논문, 기술 문서 등) 실제 시스템에서는 고정 길이 청킹과 문장 단위 청킹을 함께 사용하는 방식도 가능합니다. 예를 들어, 문장을 기준으로 나눈 후, 일정 크기(예: 300자) 이하의 청크를 병합하여 최적의 검색 성능을 도출할 수 있습니다.

2.3 임베딩 (Embedding) & 벡터 DB (Vector DB)

RAG는 보다 정확한 정보를 제공하기 위해 임베딩(Embedding)과 벡터 데이터베이스(Vector DB) 를 활용합니다. 위에서 청킹한 결과들을 각각 임베딩을 통해 텍스트를 의미 기반의 벡터로 변환하고, 벡터 데이터베이스를 사용하여 가장 관련성이 높은 문서를 빠르게 검색합니다.

2.3.1 임베딩 (Embedding)

임베딩이란 텍스트(문장이나 단어)를 숫자로 변환하는 기술입니다.

컴퓨터는 문자나 단어를 직접 이해할 수 없습니다. 대신, 숫자(벡터)로 변환하면 컴퓨터가 이를 분석하고 비교할 수 있습니다. 따라서 자연어를 숫자로 변환하여 문맥을 이해할 수 있도록 하는 과정이 필요하고, 이것이 임베딩입니다. 임베딩을 활용하면 의미적으로 유사한 단어와 문장이 비슷한 숫자로 표현됩니다.

위의 왼쪽 숫자(벡터)들은 각각의 단어를 의미하는 임베딩 값이고, 비슷한 단어일수록 숫자가 비슷하게 표현됩니다. 이처럼, 텍스트 간의 의미적 관계를 수치적으로 표현하는 것이 임베딩의 핵심입니다.

임베딩 모델이란? 임베딩을 만들기 위해서는 "임베딩 모델" 이 필요합니다. 이 모델은 텍스트를 숫자로 바꿔주는 역할을 합니다.

대표적인 임베딩 모델 2가지 (1) OpenAI text-embedding-3

OpenAI에서 제공하는 최신 임베딩 모델

의미 기반 검색, 유사 문서 찾기 등에 최적화됨

다국어 지원 및 비용 대비 높은 성능 제공

(2) Cohere Embed v3

Cohere에서 제공하는 최신 임베딩 모델

영어 및 100개 이상의 언어를 지원하며, 검색(RAG), 분류, 클러스터링에 강점

유사한 문서 및 의미 기반 검색에 최적화됨

(*수정) (3) BGE-M3 (BAAI)

BAAI(Beijing Academy of AI)에서 개발한 다국어 임베딩 모델

한국어 지원이 우수하며, 다국어 검색에 최적화됨

Dense, Sparse, Multi-vector 세 가지 검색 방식을 동시에 지원

(4) Voyage AI Embeddings

Voyage AI에서 제공하는 고성능 임베딩 모델

코드 검색 및 법률/금융 등 전문 도메인에 특화된 모델 제공

(5) Jina Embeddings v3

Jina AI에서 개발한 최신 임베딩 모델

8K 토큰 길이의 긴 문서 임베딩 지원, 다국어 지원 우수

[출처: MTEB Leaderboard (huggingface.co/spaces/mteb/leaderboard)]

임베딩 모델을 선택할 때 고려할 점 정확도: 단어, 문장, 문서 간의 의미적 유사성을 얼마나 정확하게 반영하는가?

속도: 임베딩을 생성하고 유사도를 비교하는 속도가 얼마나 빠른가?

비용: 모델을 운영하는 데 필요한 컴퓨팅 자원과 API 호출 비용이 많이 드는가?

2.3.2 벡터DB (Vector DB)

벡터 DB(Vector DB)란? 벡터 데이터베이스(Vector DB)는 임베딩된 데이터를 벡터 공간에 저장하는 데이터베이스입니다. RAG에서는 문서나 질문을 벡터로 변환한 후, 벡터 DB를 이용해 가장 관련성이 높은(의미 기반) 문서를 검색하여 AI 모델이 활용할 수 있도록 합니다.

벡터 DB의 주요 역할 임베딩된 문서 저장 → 미리 변환된 벡터 데이터를 데이터베이스에 저장

유사 벡터 검색 → 사용자의 질문을 벡터로 변환하고, 가장 유사한 벡터(문서)를 빠르게 찾아 제공

문맥 기반 검색 지원 → 키워드 검색보다 의미적으로 가까운 문서를 찾을 수 있음

기존 데이터베이스와의 차이 벡터 DB는 기존 데이터베이스와 달리, 문서 간 의미적 유사성을 고려한 검색을 수행하여 RAG의 검색 성능을 극대화하는 핵심 기술입니다

데이터 유형 정형 데이터 (텍스트, 숫자) 벡터 (고차원 수치 데이터) 검색 방식 키워드, 필터 기반 검색 의미적 유사도를 기반으로 검색 사용 사례 전통적인 웹 서비스, CRUD 애플리케이션 의미 기반 검색, 추천 시스템, RAG 대표적인 벡터DB 구분 설명 벡터 DB 특징 전용 벡터 데이터베이스 벡터 데이터를 저장, 관리, 검색하는 완전한 DB 시스템 Pinecone 클라우드 기반, 대규모 벡터 데이터를 빠르게 검색 가능 Weaviate AI 기능 내장, 의미 기반 검색 및 데이터 필터링 기능 제공 ChromaDB 오픈소스 벡터 DB, 간편한 로컬 실행 지원 (*수정) Qdrant Rust 기반 고성능 벡터 DB, 필터링과 벡터 검색을 동시 지원, 대규모 프로덕션 환경에 적합 [출처: qdrant.tech] Milvus 대규모 벡터 데이터를 위한 오픈소스 벡터 DB, 분산 아키텍처 지원, 수십억 개의 벡터 처리 가능 [출처: milvus.io] 기존 DB + 벡터 검색 기능

AI 및 벡터 검색 수요가 증가하면서 기존DB에서 벡터 검색 기능을 추가 지원함 AWS OpenSearch (Elasticsearch 기반) (*수정) 기존 텍스트 검색 엔진에서 벡터 검색을 기본 지원하는 통합 검색 플랫폼으로 발전, k-NN(근접 이웃 검색) 기반의 벡터 검색을 네이티브 지원, 대규모 로그, 문서, AI 검색 시스템에서 많이 사용 Redis 빠른 인메모리 데이터베이스로 벡터 검색 기능 추가됨. 초고속 벡터 검색이 필요할 때 적합 PostgreSQL pgvector 확장 기능을 통해 벡터 검색을 지원, SQL 기반의 벡터 검색을 수행할 수 있어 기존 RDB와 AI 시스템을 함께 운영할 때 유용.

2.4 인덱싱 (Indexing)

인덱싱(Indexing)은 검색 속도를 높이기 위해 청킹된 문서를 빠르게 검색할 수 있도록 정리하는 과정입니다. 문서의 양이 많아질수록 원하는 정보를 신속하게 찾기 어려워지므로, 적절한 인덱싱 기법을 활용하여 검색 속도를 최적화해야 합니다. RAG에서는 검색을 수행하기 전에, 문서를 적절한 방식으로 인덱싱하여 검색 속도를 높이고 검색 성능을 최적화합니다.

2.4.1 인덱싱이 필요한 이유

검색 속도 향상

문서의 양이 많아질수록, 모든 문서를 하나씩 비교하면 시간이 너무 오래 걸릴 수 있음 인덱싱을 수행하면, 검색해야 할 문서의 범위를 좁혀 검색 속도를 크게 향상시킬 수 있음 검색 성능 최적화

키워드 검색이 필요한 경우, 미리 단어별 색인을 생성하여 빠르게 검색 가능 의미 기반 검색이 필요한 경우, 벡터 검색을 최적화하여 가장 유사한 문서를 빠르게 찾을 수 있음 효율적인 문서 관리

새로운 문서가 추가되거나 수정될 때, 기존 인덱스에 반영하여 최신 정보를 검색할 수 있도록 유지 가능

2.4.2 인덱싱 방식

(1) 역색인 (Inverted Index) 역색인은 전통적인 검색 엔진에서 사용하는 방식으로, 문서 내의 단어(토큰)를 색인화합니다. 이 방식은 벡터 DB가 아닌 일반적인 DB나 검색엔진 전용 데이터베이스(ex.Elasticsearch)에 저장되어 키워드 기반 검색에 사용됩니다. (2.3의 Keyword Search)

예를 들어, 다음과 같은 두 개의 문서가 있다고 가정합니다.

문서 1: "RAG는 검색과 생성을 결합한 모델입니다." 문서 2: "검색 엔진은 키워드 기반으로 동작합니다."

이를 역색인으로 저장하면 다음과 같이 정리됩니다.

RAG 문서 1 검색 문서 1, 문서2 생성 문서 1 키워드 문서 2 이렇게 색인을 구축하면, 사용자가 "검색"이라는 키워드를 입력했을 때 사전에 색인된 정보를 바탕으로 문서 1과 문서 2를 빠르게 찾아낼 수 있습니다.

(2) 벡터 인덱싱 (Vector Indexing) 벡터 인덱싱은 문서를 벡터(수치화된 데이터)로 변환하여 저장하는 방식입니다. 앞서 배운 임베딩 → 벡터DB 저장 과정이 이 벡터 인덱싱을 위한 과정입니다. 이 방식은 의미 기반의 검색에 사용됩니다. (3.2의 Vector search) 벡터 인덱싱의 아래와 같은 순서로 동작합니다.

문서를 임베딩(Embedding) 모델을 사용하여 벡터로 변환 변환된 벡터를 벡터 데이터베이스(Vector DB)에 저장 사용자가 질문을 입력하면, 해당 질문도 벡터로 변환 후 가장 유사한 벡터를 검색하여 관련 문서를 반환 예를 들어, 사용자가 "RAG의 개념이 무엇인가?"라는 질문을 입력하면, 이 질문도 벡터로 변환된 후 가장 유사한 벡터를 가진 문서를 검색하여 반환합니다.

3 RAG의 동작 방식

앞서 설명한 데이터 전처리, 임베딩, 인덱싱은 문서를 검색하기 위한 사전 준비 과정입니다. 이제 RAG가 실제로 어떻게 검색을 수행하고, 검색된 정보를 활용하여 응답을 생성하는지에 대해 설명하겠습니다.

3.1 RAG의 핵심 동작 단계

RAG는 크게 Retrieval → Augmentation → Generation의 3단계로 동작합니다.

3.1.1 Retrieval (문서 검색)

사용자의 질문(Query)에 대해 가장 관련성이 높은 문서를 검색하는 과정 앞서 설명한 인덱싱된 문서 데이터에서 검색을 수행 Vector Search(의미 기반 검색), Keyword Search(키워드 검색), Hybrid Search(결합 검색) 중 하나를 활용하여 검색 검색된 문서가 정확할수록 최종 응답의 품질도 향상됨

3.1.2 Augmentation (정보 보강)

검색된 문서를 LLM이 활용할 수 있도록 가공하는 과정 불필요한 정보를 제거하고, LLM이 사용할 수 있도록 텍스트를 정리 프롬프트에 정리한 텍스트를 제공하여 모델이 보다 정확한 응답을 생성할 수 있도록 지원

3.1.3 Generation (응답 생성)

Augmentation 단계에서 제공된 정보를 바탕으로 LLM이 최종 응답을 생성

3.2 Retrieval(검색) 방식

앞서 2.4에서 설명한 인덱싱은 검색을 빠르게 수행하기 위한 과정이었습니다. 이제, 인덱싱된 문서에서 실제로 어떤 방식으로 문서를 검색할 것인지에 대해 알아보겠습니다. RAG에서 Retrieval(문서 검색) 단계는 전체 동작 흐름에서 가장 중요한 부분입니다. 검색된 문서의 품질이 낮으면, LLM이 부정확한 정보를 바탕으로 응답을 생성할 가능성이 높아지기 때문입니다.

RAG에서 주로 사용되는 검색 방식은 다음과 같습니다.

Vector Search (벡터 검색, 의미 기반 검색)

문서를 임베딩(Embedding) 모델을 활용하여 벡터로 변환한 후, 가장 유사한 벡터를 검색하는 방식 문맥적인 의미를 기반으로 검색할 수 있기 때문에 키워드가 정확히 일치하지 않아도 유사한 문서를 찾을 수 있음 질문(Query)을 벡터로 변환 데이터베이스에 저장된 벡터들과 비교하여 가장 유사한 벡터를 검색 가장 유사한 문서를 찾아 반환 문맥을 고려한 검색이 가능 → 키워드가 다르더라도 의미가 유사한 문서를 찾을 수 있음 동의어나 문장 구조가 다른 경우에도 검색 성능이 우수함 벡터 연산이 필요하므로 키워드 검색보다 연산 비용이 높음 벡터 검색은 문맥적 의미를 반영하여 유사한 문서를 찾지만, 특정 키워드가 포함된 문서를 정확히 찾는 데는 적합하지 않음 Keyword Search (키워드 검색, 역색인 기반 검색)

문서에서 특정 키워드를 기반으로 검색하는 방식 역색인(Inverted Index)을 활용하여, 특정 단어가 포함된 문서를 빠르게 찾을 수 있음 질문(Query)에서 주요 키워드를 추출 역색인(Inverted Index)에서 해당 키워드가 포함된 문서를 검색 일치하는 문서를 반환 검색 속도가 빠름 → 특정 키워드가 포함된 문서를 빠르게 찾을 수 있음 인덱싱된 데이터가 많을수록 검색 효율성이 증가 문맥을 고려하지 않음 → 동의어나 유사한 표현을 검색할 수 없음 키워드가 정확히 일치해야 검색 가능 → 다른 표현이나 문장 구조가 다르면 검색되지 않을 수 있음 Hybrid Search (하이브리드 검색, 키워드 + 벡터 검색 결합)

Vector Search(벡터 검색)와 Keyword Search(키워드 검색)를 결합하여, 두 방식의 장점을 동시에 활용하는 방식 일반적으로는 키워드 검색→벡터 검색 순으로 진행되나, 도메인과 목적에 따라 반대 순서로 진행하거나 병렬로 진행하는 방법을 고려할 수 있음 Keyword Search로 문서 검색 Vector Search를 적용하여 문서 검색 두 검색 결과를 결합 및 정렬 검색 속도와 정확도를 동시에 개선할 수 있음 키워드 검색의 정확성과 벡터 검색의 문맥 이해 능력을 조합하여 최적의 검색 결과 제공 두 가지 검색 방식이 모두 필요하므로, 설계가 복잡해지고 연산 비용이 증가할 수 있음

4 RAG의 한계

RAG는 검색을 통해 실시간 정보를 활용하여 더 정확하고 최신의 응답을 생성하는 강력한 기술입니다. 그러나, 부정확한 문서 검색, 검색된 정보와 LLM 응답 간의 불일치 등의 한계가 존재할 수 있습니다. 이제 RAG의 주요 한계와 이를 해결하기 위한 보완 전략을 살펴보겠습니다.

(1) 검색 결과의 신뢰성 문제

부정확한 문서가 검색될 가능성이 있음 벡터 검색(Vector Search)이 문맥적으로 유사하지만 정확하지 않은 문서를 반환할 수 있음 키워드 검색(Keyword Search)이 필요한 문서를 놓칠 가능성이 있음 정확한 문서를 검색하지 못하면, LLM이 부정확한 정보를 바탕으로 응답을 생성할 수 있음 보완 방법

검색 결과 재조정 (Re-ranking) 기법

첫 번째 검색 결과를 보정하여 더 정확한 문서를 상위에 배치하는 방식 예를 들어, 벡터 검색에서 반환된 문서들을 다시 키워드 검색을 활용해 가중치를 조정하는 방식 적용 가능 인덱싱 최적화 (색인 업데이트 & 필터링 강화)

검색 빈도가 높은 문서에 우선순위를 부여하여 검색 속도 향상 특정 도메인에서는 카테고리 기반 인덱싱 적용 (예: 법률, 의료, 기술 문서 등) (2) 문맥 연결 부족 (검색된 정보와 LLM 응답의 자연스러움 문제)

검색된 정보가 LLM의 응답과 자연스럽게 연결되지 않을 수 있음 검색된 문서가 여러 개일 경우, LLM이 어떤 정보를 중점적으로 반영해야 할지 판단하기 어려울 수 있음 LLM이 제공하는 응답이 검색된 문서의 내용을 왜곡할 가능성도 있음 보완 방법 검색된 문서를 더 효과적으로 Augmentation하는 기법 적용

LLM이 검색된 정보를 더 정확하게 반영할 수 있도록, 검색된 문서를 요약 및 정제하여 컨텍스트로 제공 검색된 문서에서 가장 중요한 정보를 추출하여 LLM이 효율적으로 활용하도록 보조 Retrieval & Generation 단계 조정

검색 결과가 많을 경우, 우선순위를 부여하여 가장 신뢰할 만한 문서를 먼저 반영 문맥 연결성을 높이기 위해 LLM이 여러 검색 결과를 조합하여 하나의 응답을 생성하는 방식 적용

[*추가] 5. Advanced RAG 패턴

기본 RAG를 넘어, 검색과 생성의 품질을 더욱 향상시키기 위한 고급 RAG 패턴들이 발전하고 있습니다.

5.1 GraphRAG (지식 그래프 기반 RAG)

GraphRAG는 문서를 단순히 벡터로 저장하는 대신, **지식 그래프(Knowledge Graph)**를 구축하여 엔티티 간의 관계를 활용하는 RAG 기법입니다.

• 핵심 원리: 문서에서 엔티티(인물, 조직, 개념 등)와 관계를 추출하여 그래프로 구축한 후, 질문에 대해 관련 엔티티와 그 연결 관계를 함께 검색
• 장점: 여러 문서에 걸친 복합적 질문(Multi-hop Reasoning)에 강함
• 예시: "A 회사의 CEO가 참여한 프로젝트에서 사용된 기술은?" → 여러 관계를 추적하여 답변 [출처: Microsoft Research, "GraphRAG: Unlocking LLM Discovery on Narrative Private Data", 2024]

5.2 Agentic RAG (에이전트 기반 RAG)

Agentic RAG는 AI 에이전트가 검색 전략을 자율적으로 계획하고 실행하는 방식의 RAG입니다.

• 핵심 원리: 에이전트가 질문을 분석하고, 어떤 데이터 소스에서 무엇을 검색할지 스스로 판단하여 실행
• 장점: 복잡한 질문에 대해 다단계 검색을 자동으로 수행, 필요시 검색 전략을 수정
• 활용 예시: 여러 데이터베이스(사내 문서, 외부 API, 웹 검색)를 조합한 복합 질의 처리 [출처: LangChain, "Agentic RAG Guide" (python.langchain.com)]

5.3 Corrective RAG (자기 수정 RAG)

Corrective RAG는 검색 결과의 품질을 자동으로 평가하고, 부적절한 경우 재검색을 수행하는 RAG 기법입니다.

• 핵심 원리: 검색된 문서가 질문과 관련이 있는지 LLM이 판단하고, 관련성이 낮으면 검색 쿼리를 수정하여 재검색
• 장점: 잘못된 정보에 기반한 응답 생성을 방지, 답변의 신뢰성 향상
• 구성: 검색 평가기(Retrieval Evaluator) + 쿼리 재작성기(Query Rewriter) + 지식 정제기(Knowledge Refiner)

[*추가] 6. RAG 평가 지표

RAG 시스템의 성능을 객관적으로 평가하기 위한 프레임워크와 지표들이 있습니다.

6.1 주요 평가 지표

평가 지표	설명	측정 대상
Faithfulness (충실도)	생성된 답변이 검색된 문서에 기반하는 정도	답변의 사실 정확성
Answer Relevance (답변 관련성)	생성된 답변이 질문에 얼마나 적절한지	답변-질문 정합성
Context Relevance (컨텍스트 관련성)	검색된 문서가 질문에 얼마나 관련 있는지	검색 품질
Answer Correctness (답변 정확도)	생성된 답변이 실제 정답과 일치하는 정도	전반적 정확도

6.2 RAGAS 프레임워크

RAGAS(Retrieval Augmented Generation Assessment)는 RAG 시스템의 품질을 자동으로 평가하는 오픈소스 프레임워크입니다.

• LLM을 활용하여 위 평가 지표를 자동으로 측정
• 별도의 정답 데이터 없이도 평가 가능 (Reference-free Evaluation)
• CI/CD 파이프라인에 통합하여 RAG 시스템의 품질을 지속적으로 모니터링 가능 [출처: RAGAS Documentation (docs.ragas.io)]

[*추가] 7. 기업 환경 RAG 구축 고려사항

SI 기업이 고객사에 RAG 시스템을 구축할 때 고려해야 할 핵심 사항입니다.

7.1 데이터 보안

• 사내 문서가 외부 LLM API로 전송되는 것에 대한 보안 정책 수립
• 필요 시 온프레미스(On-premise) LLM 또는 프라이빗 클라우드 환경에서 운영
• 임베딩 데이터에도 민감 정보가 포함될 수 있으므로 벡터 DB의 접근 제어 필수

7.2 데이터 갱신 전략

• 문서가 추가/수정/삭제될 때 임베딩과 인덱스를 자동으로 갱신하는 파이프라인 구축
• 증분 업데이트(Incremental Update): 변경된 문서만 재처리하여 효율성 확보
• 데이터 버전 관리를 통해 특정 시점의 검색 결과를 재현 가능하도록 설계

7.3 멀티 테넌시 (Multi-tenancy)

• 여러 고객사 또는 부서가 하나의 RAG 시스템을 공유하는 경우, 데이터 격리가 필수
• 네임스페이스(Namespace) 또는 메타데이터 필터링을 활용한 논리적 격리 구현
• 테넌트별 접근 권한 관리 및 감사 로그(Audit Log) 기능 구현

7.4 한국어 특화 사항

• 한국어의 교착어 특성을 고려한 토크나이저 및 임베딩 모델 선택이 중요
• 한국어 성능이 우수한 임베딩 모델 활용 권장 (예: BGE-M3, multilingual-e5-large)
• 한국어 형태소 분석기 적용으로 키워드 검색 성능 향상 (예: Nori, Mecab-ko)

한눈에 정리하는 이번 챕터

RAG는 검색 기반 정보를 활용해 LLM의 답변을 보완하는 기술이다. RAG의 핵심 구성 요소는 데이터 전처리, 청킹, 임베딩, 인덱싱으로 이루어지며, 각 단계가 정보 검색과 생성 과정에 영향을 미친다. RAG는 검색 방식을 활용해 외부 데이터를 참조하며 답변을 생성하며, 검색 방식에는 벡터 검색, 키워드 검색, 하이브리드 검색이 있다. RAG의 한계로는 검색된 정보의 품질 등이 있으며, 이를 보완하기 위한 전략이 필요하다.

🚀 마무리

이번 챕터에서는 RAG의 동작 방식과 이를 구성하는 핵심 요소인 검색(Retrieval), 정보 보강(Augmentation), 응답 생성(Generation)에 대해 살펴보았습니다. RAG는 LLM이 외부 정보를 활용할 수 있도록 돕지만, 검색된 문서의 신뢰성 문제나 문맥 연결 부족 등의 한계를 가질 수 있습니다. 이를 보완하기 위해 검색 성능을 개선하고, Retrieval과 Generation 단계를 최적화하는 전략을 사용할 수 있습니다.

다음 챕터에서는 모델을 특정 업무나 도메인에 최적화하는 파인튜닝(Fine-tuning)에 대해 다룰 예정입니다. RAG와 파인튜닝을 함께 활용하면 검색된 정보를 더욱 정확하게 반영하면서도, 모델이 특정 분야의 전문성을 갖출 수 있도록 조정할 수 있습니다.