[AI 에이전트] 4주차 RAG #2

들어가며

RAG(Retrieval-Augmented Generation)를 구현할 때 처음에는 문서를 임베딩하고, 사용자의 질문과 유사한 문서를 벡터 검색으로 가져오면 충분하다고 생각하기 쉽습니다. 하지만 실제 데이터를 대상으로 검색을 구성해 보면, 의미가 비슷한 문서를 찾는 것만으로는 정확한 답변을 생성하기 어렵다는 것을 알 수 있습니다.

제품명이나 문서 번호처럼 정확한 일치가 필요한 정보가 누락되기도 하고, 질문과 의미는 비슷하지만 실제 조건에는 맞지 않는 문서가 검색되기도 합니다. 또한 검색된 문서가 많거나 내용이 길어지면, 정작 중요한 정보가 LLM의 컨텍스트 안에서 제대로 활용되지 못하는 문제도 발생합니다.

결국 RAG의 답변 품질을 높이기 위해서는 단순히 벡터 검색의 성능만 살펴보는 것이 아니라, 검색 결과를 어떻게 보강하고 정제하여 LLM에 전달할 것인지 함께 고민해야 합니다.

이번 글에서는 RAG의 검색 정확도를 개선하기 위해 알아본 다음 방법들을 정리합니다.

• 벡터 검색과 키워드 검색을 결합하는 Hybrid Search
• 1차 검색 결과의 순위를 다시 조정하는 Re-ranking
• 검색 범위를 제한하는 메타데이터 필터링
• 불필요한 내용을 제거하는 컨텍스트 압축

각 방법이 필요한 이유와 동작 방식, 그리고 RAG 파이프라인에서 어떤 역할을 담당하는지를 중심으로 살펴보겠습니다.

Hybrid Search란?

• 하이브리드 검색은 단어의 정확한 일치를 찾는 키워드 검색(Sparse)과 문맥의 의미를 파악하는 벡터 검색(Dense)을 하나로 결합한 방식입니다.
• 키워드 검색의 ‘정교함’과 벡터 검색의 ‘유연함’을 동시에 활용하여, 고유 명사 입력이나 모호한 질문 상황 모두에서 검색 정확도를 극대화합니다.
• 각 검색 결과의 순위를 RRF(Reciprocal Rank Fusion) 등의 알고리즘으로 통합하고 가중치($\alpha$)를 조절함으로써, 사용자 의도에 가장 부합하는 최적의 답변 후보를 도출합니다.

왜 벡터 검색만으로 부족한가?

: 벡터 검색은 문장의 전체적인 ‘맥락’을 파악하는 데 뛰어나지만, 수치화된 유사도에 의존하기 때문에 다음과 같은 치명적인 데이터 누수(Data Leakage) 현상이 발생합니다.

: 벡터 검색은 충분한 검색 기능을 제공하지만, 모델이 사전에 학습하지 않은 ‘새로운 도메인’의 데이터를 다룰 때 한계를 보입니다.

(1) 도메인 특화 용어 및 미학습 단어 처리의 한계(Out-of-Distribution 문제)

• 임베딩 모델은 사전에 대규모 데이터셋으로 학습됩니다. 따라서 모델이 학습 과정에서 본 적 없는 전문 용어나 사내 약어는 벡터 공간에서 적절한 위치를 찾지 못합니다.
• 의미 왜곡: 의료, 법률, 반도체 공정 등 특수 분야에서 사용하는 전문 용어를 임베딩 모델이 일반적인 단어와 유사하게 처리할 경우, 검색 결과가 완전히 엉뚱한 방향으로 흐르게 됩니다.
• 미세 조정(Fine-tuning)의 비용: 이를 해결하기 위해 매번 모델을 미세 조정하는 것은 막대한 시간과 고성능 컴퓨팅 리소스가 소모되는 비효율적인 작업입니다.

(2) 희소 데이터(Sparse Data) 및 고유 식별자 검색 실패

• 벡터 검색은 단어들을 압축하여 추상적인 공간에 배치합니다. 이 과정에서 ‘정확한 일치’가 필요한 정보들이 소실될 수 있습니다.
• 고유 명사 및 식별자: 제품 모델명(예: A-1234-X), 부품 번호, 특정 날짜, 사람 이름 등은 의미적 유사성보다 글자 그대로의 일치가 훨씬 중요합니다. 벡터 검색은 A-1234-X를 비슷한 모델명인 A-1234-Y와 가깝게 인식하여 잘못된 정보를 가져올 확률이 높습니다.
• 오타 및 신조어: 검색어에 오타가 있거나 아주 최근에 생겨난 신조어의 경우, 벡터 공간 내에 기준점이 없어 검색 성능이 급격히 저하됩니다.

BM25 알고리즘의 핵심 원리

: BM25는 전통적인 키워드 검색의 한계를 수학적으로 보완한 알고리즘으로, 현대 검색 엔진(Elasticsearch, Solr 등)의 기본 랭킹 알고리즘으로 채택될 만큼 강력합니다.

(1) TF-IDF 기반

: 단순 TF-IDF는 특정 단어가 문서에 많이 나올수록 점수가 무한히 상승합니다. 하지만 BM25는 ‘단어 빈도 포화’ 개념을 도입하여 효율성을 높였습니다.

• 사용자의 질문에 포함된 키워드가 문서에 얼마나 자주 등장하는지(Term Frequency), 그리고 해당 단어가 전체 문서군에서 얼마나 희귀한지(Inverse Document Frequency, IDF)를 계산합니다.
• 핵심 논리: 특정 키워드(예: ‘아이폰’)가 문서에 10번 나오는 것과 20번 나오는 것은 큰 차이가 있지만, 1,000번 나오는 것과 1,010번 나오는 것은 문서의 주제를 결정짓는 데 큰 차이가 없다고 판단합니다.
• 수학적 제어: $k_1$이라는 파라미터를 사용하여 단어 빈도가 일정 수준을 넘어서면 점수가 수렴하도록 설계되었습니다.

(2) 정확한 토큰 매칭

: 질문에 포함된 키워드와 본문의 키워드를 ‘토큰(Token)’ 단위로 정확히 대조하는 방식을 취합니다.

• 의미를 유추하는 것이 아니라, 키워드의 ‘정확한 일치(Exact Match)’ 여부와 문서의 길이를 고려한 수식을 통해 문서와 질문 간의 연관성 점수를 산출합니다.
• Bag-of-Words 기반: 문법이나 어순보다는 어떤 ‘단어’가 포함되어 있는지를 중시합니다.
• 고유 명사 처리: “삼성전자 갤럭시 S24”와 같이 벡터 검색이 혼동하기 쉬운 고유 명사나 모델 번호 검색에서, 오로지 정확한 일치(Exact Match)만을 기준으로 점수를 매기기 때문에 검색 결과의 신뢰도가 매우 높습니다.

검색 엔진 상세 비교: Vector vs BM25

구분	의미론적 검색(Vector Search)	키워드 검색(BM25)
핵심 가치	맥락과 의도(Context)	정확성과 희소성(Precision)
매칭 방식	유사한 의미를 가진 공간적 근접도 매칭	텍스트 토큰의 물리적 일치 여부 매칭
주요 장점	• 유의어·동의어 처리 능력이 탁월함 • 다국어 검색 및 문장형 질문에 강함 • “혈당 조절 방법” 검색 시 “인슐린 요법” 탐색 가능	• 특정 고유 명사, 제품 번호 검색 시 오차가 없음 • 도메인 특화 용어에 대해 즉각적인 반응성 보유 • 계산 비용이 저렴하고 인덱싱 속도가 빠름
치명적 단점	• 할루시네이션: 단어는 달라도 벡터가 가깝다는 이유로 전혀 다른 사실을 가진 문서를 가져올 수 있음 • 전문 용어(OOD) 매칭 실패	• 어휘 불일치(Vocabulary Gap): 사용자가 “노트북”이라고 검색했을 때 본문에 “휴대용 컴퓨터”만 있다면 검색 실패 • 문맥 이해 불가

방식별 강점과 약점

검색 방식	강점(Strengths)	약점(Weaknesses)
벡터 검색(Semantic)	문맥 및 의미 이해: “혈당 수치” 검색 시 “당뇨병 관리”를 찾는 등 동의어·유의어를 자동으로 파악하여 지능적인 검색이 가능합니다.	정밀도 부족: 모델이 학습하지 않은 전문 용어(OOD)나 모델 번호, 사람 이름 같은 고유 명사의 정확한 매칭(Exact Match)에 취약합니다.
BM25(Keyword)	정확한 키워드 매칭: 별도 학습 없이도(Zero-shot) 문서 내 특정 단어의 존재 여부를 파악하며, 새로운 도메인 데이터에 즉각 대응할 수 있습니다.	어휘 불일치 문제: 검색어와 본문의 단어 형태가 조금만 달라도 찾지 못하며, 텍스트의 실제 의미나 맥락을 전혀 유추하지 못합니다.
Hybrid(결합)	최상의 검색 품질: 벡터의 ‘지능’과 BM25의 ‘정확성’을 결합하여, 전문 용어 누락 문제를 해결하고 다양한 검색 시나리오에서 정확도를 극대화합니다.	리소스 및 튜닝: 두 가지 인덱스(밀집·희소 벡터)를 모두 관리해야 하는 비용이 들며, 서비스 성격에 맞는 가중치($\alpha$) 최적화 과정이 필수적입니다.

⇒ 하이브리드 검색은 벡터 검색이 놓치기 쉬운 ‘특정 도메인의 전문 키워드’를 BM25가 보완해 주고, BM25가 찾지 못하는 ‘동의어와 문맥’을 벡터 검색이 찾아주어 환각(Hallucination) 방지와 검색 정확도를 극대화하는 강력한 대안으로 활용됩니다.

벡터 검색과 키워드 검색의 결합 방식

(1) 가중치 기반 병합(Weight-based Merging / Alpha 파라미터)

: alpha 파라미터를 활용한 가중치 조절 방식(Pinecone)

• alpha 값을 0.5로 설정하면 두 검색 방식의 점수가 균등하게 혼합된 기본 하이브리드 검색이 됩니다.
• alpha 값을 1.0으로 설정하면 100% 밀집 벡터(의미론적) 검색만 수행하게 됩니다.
• 문서의 테스트 결과, 전문적인 의료 데이터셋(pubmed_qa)에서는 alpha 값을 0.3으로 설정하여 전통적인 키워드 매칭의 가중치를 조금 더 높였을 때 검색 결과가 가장 크게 향상되었습니다.

(2) 상호 순위 융합(Reciprocal Rank Fusion, RRF)

: LlamaIndex 등에서 강력하게 추천하는 방식인 RRF는 개별 검색 결과의 ‘점수’가 아닌 ‘순위(Rank)’를 활용합니다. 두 검색 엔진의 점수 체계(예: 0~1 vs 10~100)가 서로 달라도 안정적으로 통합할 수 있습니다.

• RRF의 강점: 특정 엔진이 산출하는 점수가 너무 높거나 낮아서 결과가 한쪽으로 쏠리는 현상을 방지합니다. 즉, 두 방식 모두에서 상위권에 랭크된 문서가 최종 상위권으로 올라오게 됩니다.

기타 방식 → LlamaIndex에서 제공

• 상대적 점수 융합(Relative Score Fusion)

  • 각 검색기의 점수를 0~1 사이로 정규화(Min-Max)한 후 합산합니다. 점수의 상대적 차이를 유지하고 싶을 때 사용합니다.

• 분포 기반 점수 융합(Distribution-Based Fusion)

  • 점수의 통계적 분포(평균, 표준편차)를 분석하여 정규화합니다. 점수 차이가 매우 극심한 서로 다른 엔진을 결합할 때 유리합니다.

• 단순 융합(Simple Fusion)

  • 단순히 각 리스트의 상위 $N$개를 중복 제거하고 합칩니다. 연산 속도가 가장 빠르며 정교한 랭킹이 덜 중요할 때 사용합니다.

• 상호 순위 융합(Reciprocal Rank Fusion, RRF)

  • 점수 대신 ‘순위(Rank)’의 역수를 합산하여 최종 순위를 결정합니다. 점수 정규화 과정이 필요 없어 가장 범용적이고 안정적인 성능을 보여주며, 현재 하이브리드 검색에서 가장 널리 쓰이는 표준 방식입니다.

2. Re-ranking

Re-ranking이란

• Re-ranking(재랭킹)은 1차적으로 검색된 문서 후보군을 대상으로 사용자의 질문과의 연관성을 다시 정밀하게 계산하여 가장 적합한 문서가 최상단에 오도록 순위를 재배치하는 과정입니다.

  • RAG 파이프라인에서 Retrieval(검색)이 방대한 서고에서 관련 있을 법한 책들을 한 트럭 가져오는 과정이라면, Re-ranking은 트럭에 실린 책들을 꼼꼼히 읽어 보고 정답에 가까운 페이지를 맨 위로 올리는 과정입니다.

• RAG 파이프라인상에서는 Retrieval(검색) 단계와 Generation(생성) 단계 사이에 위치합니다.

  • LLM은 컨텍스트가 너무 길어지면 정보를 놓치는 경향(Lost in the Middle)이 있습니다. 따라서 가장 관련성이 높은 상위 문서 3~5개만을 추려내어 LLM의 답변 품질을 극대화합니다.

Retrieval(1차 검색) → Re-ranking(재정렬) → Generation(답변 생성)

• 코드 블록(블로그용)

  | **구분** | **System Prompt(시스템 프롬프트)** | **RAG(검색 증강 생성)** | **비고** |
  | --- | --- | --- | --- |
  | **데이터 위치** | 프롬프트 상단(컨텍스트 윈도우 내부) | 외부 데이터베이스(Vector DB 등) | 내부 컨텍스트 vs 외부 DB |
  | **용량 제한** | 모델의 토큰 제한에 걸림(**매우 작음**) | 사실상 **무제한**(수백만 개 가능) | 확장성 및 데이터 규모 차이 |
  | **제공 방식** | 사람이 직접 **수동으로 삽입** | 질문에 맞는 문서 **자동 검색·제공** | 자동화된 검색 프로세스 |
  | **비용 효율성** | 매 요청마다 전체 토큰 소모(**고비용**) | 필요한 청크만 사용하여 **비용 절약** | 운영 효율성 및 경제성 |
  | **유지 보수** | 데이터 변경 시 **프롬프트 수동 수정** | DB 갱신 시 **자동으로 최신 지식 반영** | 최신성 유지의 편의성 |

Cross-encoder vs Bi-encoder

→ 문장의 의미를 비교하는 두 가지 방식입니다.

(1) Bi-encoder(바이 인코더)

→ Bi-encoder는 질문과 문서를 각각 독립적으로 숫자(벡터)로 바꾼 뒤, 그 숫자들 사이의 거리를 계산하는 방식입니다.

• 작동 방식: 질문 $A$를 벡터로 만들고, 문서 $B$를 벡터로 만든 뒤, 두 벡터가 얼마나 가까운지(코사인 유사도 등)를 확인합니다.
• 특징(속도): 문서들을 미리 벡터로 만들어 데이터베이스(Vector DB)에 저장해 둘 수 있기 때문에 검색 속도가 매우 빠릅니다. 수백만 개의 문서도 순식간에 훑을 수 있습니다.
• 한계(정확도): 두 문장을 따로 처리하기 때문에 질문과 문서 사이의 미묘한 문맥적 상호작용을 파악하는 데는 한계가 있습니다.

(2) Cross-encoder(크로스 인코더)

→ Cross-encoder는 질문과 문서를 하나의 쌍(Pair)으로 묶어서 동시에 모델에 입력하는 방식입니다.

• 작동 방식: [질문 + 문서]를 한꺼번에 입력받아 모델이 두 문장의 모든 단어를 서로 대조하며 연관성 점수를 직접 계산합니다.
• 특징(정확도): 두 문장의 관계를 직접 보기 때문에 정확도가 압도적으로 높습니다. 문맥을 아주 깊게 이해할 수 있습니다.
• 한계(속도): 질문이 들어올 때마다 문서와 일일이 대조하며 연산해야 하므로 매우 느립니다. 수백만 개의 문서를 이 방식으로 검색하는 것은 사실상 불가능합니다.

구분	Bi-encoder	Cross-encoder
입력 방식	질문과 문서를 각각 독립적으로 인코딩하여 개별 임베딩 벡터를 생성	질문과 문서를 동시에 하나의 네트워크로 통과시켜 0과 1 사이의 유사도 점수를 직접 출력
속도	매우 빠름. 벡터 데이터베이스를 활용하여 수초 내에 대규모 유사도 비교 가능	매우 느림. 임베딩을 미리 만들어 둘 수 없어 모든 (질문, 문서) 쌍에 대해 모델 추론 연산을 새로 해야 함
정확도	상대적으로 낮음	문장 간의 문맥을 깊이 있게 교차 분석하므로 월등히 뛰어난 성능(정확도)을 보임
사용 위치	1차 검색 단계(Retrieval)	2차 재정렬 단계(Re-ranking)
데이터 규모	수백만 건 이상 처리 가능	수십~수백 건으로 제한

Cross-encoder를 검색 단계가 아닌 Re-ranking 단계에서 사용하는 이유(속도 vs 정확도 트레이드오프)

이유: ‘비용’과 ‘시간’ 때문입니다. 즉, 속도와 정확도 간의 트레이드오프(Trade-off) 때문입니다.

• Cross-encoder는 텍스트를 고정된 차원의 벡터(임베딩)로 변환하지 않기 때문에 Faiss나 Chroma 같은 벡터 데이터베이스에 인덱싱할 수 없습니다. 따라서 만약 수백만 개의 문서 전체를 대상으로 Cross-encoder를 사용한다면 모든 문서와 질문을 일일이 짝지어 연산해야 하므로 시간이 기하급수적으로 소요됩니다.
• 따라서 검색 속도가 중요한 초기 검색 단계에서는 사용할 수 없고, 범위를 좁힌 후 정확도를 높여야 하는 Re-ranking 단계에만 제한적으로 사용하는 것입니다.

Two-stage Retrieval 패턴: Bi-encoder로 후보 선별 → Cross-encoder로 재정렬

→ 대규모 데이터에서 원하는 정보를 찾을 때 ‘속도’와 ‘정확도’라는 두 마리 토끼를 잡기 위해 사용하는 표준적인 아키텍처입니다.

Step 1) 후보 선별(Candidate Retrieval) - Bi-encoder

→ 빠르고 효율적인 Bi-encoder를 사용하여 전체 문서 데이터베이스에서 질문과 관련된 상위 K개(예: Top-100)의 후보 문서를 신속하게 추출합니다.

• 속도: 문서 벡터들을 미리 계산해서 벡터 DB에 저장해 둘 수 있습니다. 검색 시에는 쿼리 벡터 하나만 만들어서 코사인 유사도(Cosine Similarity) 등 단순 연산만 수행하므로 매우 빠릅니다.
• 한계: 쿼리와 문서 사이의 미묘한 의미적 관계(단어 간의 상호작용)를 포착하는 데는 한계가 있습니다.

Step 2) 재정렬(Re-ranking) - Cross-encoder

→ 1단계에서 뽑힌 소수의 후보군을 대상으로 훨씬 더 정밀하게 순위를 다시 매기는 단계입니다.

• 추출된 100개의 문서와 질문을 Cross-encoder에 각각의 ‘쌍(Pair)’으로 입력하여 정밀하게 유사도 점수를 다시 계산하고, 이 점수를 기반으로 가장 정확한 최상위 결과를 도출해 LLM에 전달합니다.
• 정확도: 모델이 쿼리의 단어와 문서의 단어를 직접 비교(Attention)할 수 있어 질문의 의도와 정답의 맥락을 아주 정확하게 파악합니다.
• 비용: 연산량이 매우 많아 속도가 느립니다. 수백만 개를 대상으로 할 수는 없지만, 1단계에서 걸러진 10~50개 정도를 처리하기에는 충분합니다.

Cohere Rerank(상용 Re-ranking API)

(1) Cohere Rerank의 동작 방식

→ 기존의 검색 시스템(Elasticsearch, Pinecone, LangChain 등) 뒤에 ‘필터’처럼 붙여서 사용합니다.

1. 초기 검색(Retrieval): 사용자의 질문을 기반으로 기존 벡터 DB나 키워드 검색기에서 상위 50~100개의 문서를 먼저 뽑습니다.
2. API 전송: 질문(Query)과 뽑힌 문서 리스트(Documents)를 통째로 Cohere Rerank API에 보냅니다.
3. 정밀 분석(Inference): Cohere의 대규모 Cross-encoder 모델이 질문과 각 문서의 상관관계를 한 쌍씩 대조하며 0~1 사이의 연관성 점수를 매깁니다.
4. 결과 반환: 점수가 높은 순으로 정렬된 리스트를 반환하며, 개발자는 이 중 상위 몇 개만 뽑아 LLM(GPT 등)에 전달합니다.

(2) Cohere Rerank의 장점

• 압도적인 성능(특히 한국어를 포함한 다국어)

  • Cohere는 Rerank-v3 모델을 통해 한국어를 포함한 100개 이상의 언어를 지원합니다. 직접 작은 모델(Cross-encoder)을 학습시켜 사용하는 것보다 훨씬 더 문맥 파악 능력이 뛰어나며, 오타나 의미적 유사성도 잘 파악합니다.

• 개발 및 운영 비용 절감

  • No Infrastructure: Cross-encoder 모델은 연산량이 많아 직접 서빙하려면 고성능 GPU 서버가 필요합니다. Cohere를 사용하면 서버 관리 비용과 엔지니어링 리소스를 아낄 수 있습니다.
  • 간편한 통합: LangChain이나 LlamaIndex 같은 프레임워크와 이미 잘 연동되어 있어 코드 몇 줄만 추가하면 즉시 검색 품질이 비약적으로 상승합니다.

• 문서 구조에 강함(Semi-structured Data)

  • 최신 v3 모델은 단순 텍스트뿐만 아니라 JSON 데이터나 이메일, HTML 같은 구조화된 문서 내의 특정 필드를 이해하고 정렬하는 능력이 매우 탁월합니다.

• 긴 문맥 처리(Long Context)

  • 보통의 임베딩 모델보다 더 긴 문맥을 한 번에 처리할 수 있어 문서가 다소 길더라도 중요한 내용을 놓치지 않고 점수를 매깁니다.

3. 메타데이터 필터링과 컨텍스트 압축

메타데이터 필터링

⇒ ‘메타데이터’ 조건을 만족하는 문서로만 검색 범위를 제한하는 기법입니다.

& 왜 필요할까?

벡터 유사도 기반의 의미론적 검색은 ‘의미’만 비슷하면 조건에 맞지 않는 문서도 관련성이 높다고 판단하여 상위 결과로 가져올 수 있습니다.

ex) ‘2026년 의료 급여 혜택’을 찾아야 하는데, 유사한 ‘2020년 의료 급여 혜택’ 문서를 찾아서 잘못된 정보를 가져올 수 있습니다.

→ 따라서 이러한 할루시네이션 오류의 원인이 되는 현상을 방지하기 위해 필수적입니다.

& 구현 방식

• LangChain

  • 에이전트에게 도구(Tool)를 제공할 때 LLM이 쿼리 문자열뿐만 아니라 추가적인 검색 매개변수(예: 카테고리 등)를 생성하도록 강제할 수 있으며, 보통 search_kwargs={"filter": {"year": "2026"}} 형태로 검색 범위를 좁히는 파라미터를 넘겨 구현합니다.

• LlamaIndex

  • Pinecone, Qdrant, Milvus, Chroma 등 메타데이터 필터링을 지원하는 벡터 저장소와 연동할 때 검색기(Retriever)에 Metadata Filters를 적용하여 특정 키와 값이 일치하거나 날짜 범위에 포함되는 문서만 쿼리하도록 설정할 수 있습니다.

컨텍스트 압축

⇒ 1차로 검색된 긴 문서 청크들 중에서 사용자의 질문에 답하는 데 실제로 필요한 핵심 문장이나 정보만을 추출하거나 요약하여 LLM에 전달될 프롬프트를 압축하는 기법입니다.

& 왜 필요할까?

→ RAG의 고질적인 문제는 “검색된 문서가 너무 길고 노이즈가 많다”는 점입니다.
이를 해결하기 위해 검색된 결과물(Document)을 LLM에 넘기기 전 ‘다이어트’시키는 과정입니다.

• Lost in the Middle(중간 정보 손실 현상): 연구 결과에 따르면 LLM은 입력된 텍스트의 앞부분과 뒷부분은 잘 이해하지만, 중간에 위치한 정보는 무시하는 경향이 있습니다. 압축을 통해 이 현상을 방지합니다.
• 토큰 비용 절감: 1,000자 청크 5개를 그대로 넣는 것보다 핵심 문장 10줄만 추출해 넣는 것이 훨씬 경제적입니다.
• 답변 정확도 향상: 불필요한 부연 설명이 제거되어 LLM이 엉뚱한 정보를 바탕으로 추론하는 것을 막습니다.

방식	설명	특징
LLM Chain Extractor	LLM이 각 문서를 읽고 질문과 관련된 부분만 다시 작성하거나 추출합니다.	가장 정확하지만 추가적인 LLM 호출 비용과 지연 시간(Latency)이 발생합니다.
Embeddings Filter	질문 벡터와 각 문서 내부의 문장·단락 벡터를 비교해 유사도가 낮은 부분을 제거합니다.	LLM을 사용하지 않아 빠르고 저렴하지만, 문맥 이해도는 다소 낮습니다.
Document Reordering	압축은 아니지만, 가장 중요한 정보를 프롬프트의 최상단이나 최하단으로 재배치합니다.	‘Lost in the Middle’ 해결에 매우 효과적입니다.

& 구현 방식 예시

• LangChain

  • ContextualCompressionRetriever라는 특수 컴포넌트를 사용합니다.
    기본 Retriever 위에 가벼운 LLM 기반의 압축기(Compressor)를 덮어씌우는 방식으로, 1차 검색된 문서들을 압축기가 먼저 읽고 질문과 무관한 내용을 잘라낸 정제된 텍스트만 최종 체인에 전달합니다.

• LlamaIndex

  • Node Postprocessor(노드 후처리기)를 적극 활용합니다.
    검색을 통해 얻은 Node(청크)들을 텍스트 합성을 위한 프롬프트에 넣기 직전에 LLM이나 점수 기반 알고리즘을 활용해 질문과의 연관성이 낮은 문장을 잘라내거나 제거하는 방식으로 컨텍스트를 최적화합니다.

마무리

RAG의 성능은 사용하는 LLM의 성능뿐만 아니라, 질문에 적합한 문서를 얼마나 정확하게 찾아서 전달하느냐에 따라 크게 달라집니다. 관련성이 낮거나 조건에 맞지 않는 문서가 검색되면, 성능이 좋은 LLM을 사용하더라도 정확한 답변을 생성하기 어렵습니다.

이번에 살펴본 검색 보강 방법은 각각 다음과 같은 역할을 담당합니다.

• Hybrid Search는 벡터 검색의 문맥 이해 능력과 BM25의 정확한 키워드 매칭 능력을 결합하여 1차 검색의 재현율과 정확도를 높입니다.
• Re-ranking은 검색된 후보 문서를 질문과 다시 비교하여 실제로 연관성이 높은 문서가 상위에 배치되도록 합니다.
• 메타데이터 필터링은 날짜, 카테고리, 권한 등의 조건을 적용하여 검색 대상 자체를 제한합니다.
• 컨텍스트 압축은 검색된 문서에서 질문과 관련된 핵심 정보만 추려 LLM에 전달되는 노이즈와 토큰 사용량을 줄입니다.

이를 하나의 파이프라인으로 정리하면 다음과 같습니다.

사용자 질문
    ↓
메타데이터 조건 추출
    ↓
Hybrid Search
(Vector Search + BM25)
    ↓
검색 결과 통합
(RRF 또는 가중치 기반 병합)
    ↓
Re-ranking
    ↓
컨텍스트 압축
    ↓
LLM 답변 생성

중요한 점은 모든 서비스에 동일한 검색 구성을 적용하는 것이 아니라, 실제 데이터와 질문 유형에 맞게 각 단계의 비중을 조절해야 한다는 것입니다. 일반적인 문장형 질문이 많다면 벡터 검색의 비중을 높일 수 있고, 제품 번호나 법령명처럼 정확한 키워드가 중요하다면 BM25의 비중을 높이는 방식으로 조정할 수 있습니다.

또한 Re-ranking에 전달할 후보 문서 수, 최종적으로 LLM에 전달할 문서 수, 메타데이터 필터의 조건, 컨텍스트 압축 방식에 따라서도 검색 품질과 응답 속도, 운영 비용이 달라집니다.

따라서 RAG 검색 보강은 특정 기술 하나를 적용하는 작업이라기보다 다음 세 가지 요소 사이의 균형을 찾는 과정이라고 정리할 수 있습니다.

검색 범위는 넓게 확보하고, 문서 순위는 정밀하게 조정하며, LLM에는 필요한 정보만 전달한다.

향후에는 실제 데이터셋을 기준으로 각 검색 방식의 정확도와 응답 시간을 비교하고, Hybrid Search의 가중치와 Re-ranking 후보 개수 등을 조정하면서 서비스에 적합한 검색 파이프라인을 구성해 볼 수 있을 것 같습니다.