RAG 시스템 강화하기 - Multi-Query, Self-Query, Reranker 알아보기

1. Multi Query

1.1 배경

• 전통적인 RAG 파이프라인에서는 사용자의 쿼리(Query)가 임베딩되어, 가장 유사한 문서를 검색(Retrieval)한 뒤 LLM이 답변을 생성한다.
• 하지만 사용자의 쿼리가 애매하거나 범위가 넓은 경우, 단일 문장만으로는 문서 검색에서 정보 유실(Information Loss)이 생길 수 있다.
  • Google의 Multi-Vector Retrieval, OpenAI 등이 제안한 쿼리 재작성 기법을 통해 질문을 여러 형태로 재생성하여 더 풍부한 검색을 유도하는 시도를 해왔다.

1.2 사용하는 이유

1. 쿼리 다양성 확보
   • 사용자 입력 한 줄이 모호하거나, 특정 키워드를 놓쳤을 때, 다양한 표현의 쿼리를 생성하면 그만큼 다른 각도에서 문서를 검색할 수 있다.
2. 정확도(Recall) 향상
   • 단일 쿼리가 놓치는 문서가 있을 수 있는데, 유사하지만 조금 다른 각도로 표현한 쿼리가 그 문서를 찾을 수도 있다. 결과적으로 Retrieve 단계에서 더 폭넓은 후보 문서를 확보한다.

1.3 사용 효과

• 문서 커버리지 확대: 여러 쿼리를 통해 후보가 더 다양해짐에 따라, RAG가 놓칠 수 있었던 정보가 줄어든다.
• 최종 답변 품질 향상: 더욱 관련성이 높은 문서 청크(Chunk)들을 LLM이 참고하게 되므로, 답변 정합성이 높아지고 근거 기반 응답이 강화된다.

1.4 기존 RAG 구조에 적용

1. 쿼리 재작성 단계 추가
   • 사용자가 입력한 쿼리를 LLM 또는 다른 모델로부터 여러 paraphrase로 생성한다.
2. 병렬적 Retrieval
   • 각 쿼리에 대해 임베딩 & 검색을 수행하고, Top-K 결과를 합산하거나 union하여 최종 후보 집합을 만든다.
3. 문서 스코어링 및 통합
   • 문서 스코어(유사도 등)를 바탕으로 중복 문서를 제거하고, 상위 문서를 취합한다.
4. LLM에 입력
   • 통합된 문서들을 LLM 프롬프트에 넣어 답변을 생성한다(혹은 Late Fusion 기법으로 문서별 점수를 종합).

---

2. Self-Query

2.1 배경

• 많은 RAG 시스템은 사용자의 자연어 쿼리를 직접 임베딩하여 유사 문서를 검색한다. 그러나 종종 더 구조화된 질의(Structured Query)가 필요할 때가 있다.
• 예: 특정 날짜 범위, 특정 엔티티, 또는 주제별 필터 등. 일반적인 임베딩 방식만으로는 세부 필터 조건을 반영하기 어렵다.
• Self-Query 기법은 LLM 자체가 사용자의 질의를 분석하여, 필요한 “검색 조건”이나 “필터 필드”를 구조화해주는 접근이다.

2.2 사용하는 이유

1. 복잡 질의 처리
   • “2021년 이후 발행된 논문 중, 저자가 ‘Smith’인 문서만 찾아줘”처럼 구체적인 조건이 포함된 질의에 대응.
2. 데이터베이스/검색 엔진 최적화
   • 구조화된 질의를 통해 Vector DB뿐 아니라, 키워드 기반 검색(ElasticSearch 등)이나 관계형 쿼리(SQL)와도 연계 가능.
3. 직관적 UX
   • 사용자는 자연어로 의도를 표현하고, 내부적으로 LLM이 그 의도를 분석해서 시스템에 맞는 질의 포맷으로 변환한다.

2.3 사용 효과

• 검색 정확도(Precision) 향상: 단순 임베딩 검색이 아니라, 특정 필터(메타데이터, 날짜, 키워드)를 적용한 정교한 검색이 가능해진다.
• 작업 자동화: 사용자가 복잡한 검색 문법을 배울 필요 없이 자연어만 입력하면, LLM이 적합한 질의를 생성(“Self-Query Prompting”)해준다.

2.4 기존 RAG 구조에 적용

1. Self-Query Node 추가
   • RAG 파이프라인에 “질의 변환 단계”를 둔다. LLM이 “사용자 쿼리 → (필터: 필드=..., 날짜=..., 카테고리=...)” 형태로 변환한다.
2. 메타데이터 필터링
   • Vector DB가 문서 메타데이터(발행일, 카테고리, 저자) 등을 인덱싱하고 있다면, Self-Query 결과를 기반으로 특정 필드를 필터링해 검색한다.
3. 검색 후 생성
   • 필터링된 문서 집합을 LLM에 전달해 최종 요약/답변을 생성한다.

---

3. Reranker

3.1 배경

• 일반 RAG는 “임베딩 → 최근접 검색”만 사용한다. 하지만 임베딩 유사도만으로는 정확한 문서 우선순위를 정하기가 어려울 수 있다(특히 문서 길고 복잡할 때).
• 기존 IR(Information Retrieval) 분야에서는, 1차 검색 결과(Top-N)를 다시 정교하게 재정렬하는 Reranking 기법이 오래전부터 존재했다.
• BERT 계열 모델(예: MonoBERT, Cross-Encoder 등)을 사용해 1차 후보를 세밀하게 재평가하여 가장 관련도 높은 문서 순위를 매기는 방식이 발전해 왔다.

3.2 사용하는 이유

1. 정확성(Precision) 개선
   • 임베딩 검색이 놓칠 수 있는 세부 의미 관계를 Cross-Encoder나 다른 모델이 정밀하게 평가해, 진짜 “최적의 문서”를 상위에 배치한다.
2. 잘못된 문서 제거
   • 1차 검색에 걸린 문서 중 실제로는 쿼리와 무관한 문서가 섞여 있을 수 있는데, Reranker가 이런 후보를 하위로 밀어낸다.

3.3 사용 효과

• 상위 문서의 품질 향상
  • 결과적으로 RAG가 참조하는 문서가 더 정확해지고, LLM이 답변 생성 시 “허위 정보”를 채택할 위험이 줄어든다.
• 성능 유지 vs. 비용 증가
  • Reranking 과정에서 Cross-Encoder 등을 쓰면 추가 추론 비용이 들지만, 상위 N개에 대해서만 Rerank하므로 전체 비용을 관리할 수 있다.

3.4 기존 RAG 구조에 적용

1. 1차 Retrieval
   • 임베딩 검색으로 Top-(N=50) 정도를 뽑는다.
2. Reranker
   • Cross-Encoder 또는 별도 랭킹 모델로 각 문서-쿼리 쌍의 점수를 다시 계산한다.
   • 가장 점수가 높은 Top-K’(예: 5) 문서를 최종 후보로 선정.
3. LLM에 전달
   • 최종 후보 문서만 LLM Prompt에 포함해 답변을 생성한다.
4. Pipeline 예시
   • query -> embed -> vector search -> top 50 docs -> Reranker -> top 5 docs -> LLM -> answer

---

정리

1. Multi Query
   • 배경: 단일 쿼리가 놓치는 부분을 보완하기 위해, 쿼리를 여러 형태로 생성.
   • 이유: 다양성 확보 & Recall 증대.
   • 효과: 더 폭넓은 검색 결과를 얻고, RAG 답변의 완전성을 개선.
   • 적용: “쿼리 재작성 단계” → 여러 쿼리 → 병렬 검색 → 결과 통합.
2. Self-Query
   • 배경: 자연어 질의를 구조화(날짜, 카테고리, 필드 등)해서 정교한 검색.
   • 이유: 복잡 질의 처리 & 사용자가 검색 문법을 몰라도 됨.
   • 효과: 검색 정밀도 향상 & 필터/메타데이터 기반 검색 가능.
   • 적용: “Self-Query Node”로 필터를 추출 → Vector DB/메타 검색에 적용.
3. Reranker
   • 배경: 임베딩만으로는 제한된 1차 검색을 보다 정교히 재정렬.
   • 이유: Top-N 문서 중 진짜로 쿼리와 가장 밀접한 것들을 상위에 배치.
   • 효과: 최종 문서 품질 상승, RAG 답변 정확도 향상.
   • 적용: “Retrieval 후 Reranker” → 상위 결과를 재정렬 → LLM 전달.

결국, RAG 시스템에서 Multi Query, Self-Query, 그리고 Reranker 기법을 적절히 결합하면, 사용자 쿼리가 애매하거나 요구사항이 복잡한 상황에서 더 정확하고 풍부한 정보를 반환할 수 있다. 이는 RAG 답변의 신뢰도를 높이고, 다양한 도메인(뉴스, 법률, 의료 등)에서 사용자 경험을 개선하는 데 크게 기여한다.