RAG의 검색 설계: Dense Retrieval · Sparse Retrieval의 활용 구분

RAG 시스템에서는 많은 경우, 청크(chunk)를 embedding vector(임베딩 벡터)로 변환하여 Vector Database에 저장한 후, 검색 가능한 레코드가 생성됩니다.

청크 본문
+ embedding vector (임베딩 벡터)
+ metadata

사용자가 무언가를 질문했을 때, RAG 시스템은 다음을 판단해야 합니다.

저장된 청크 중 이 질문에 도움이 될 만한 정보를 포함하고 있을 법한 것은 무엇인가?

이것이 **retrieval strategy(검색 전략)**의 역할입니다. Retrieval(검색)이란, 후보 검색 단계를 의미합니다. 사용자의 질문이 주어지면, 시스템은 저장된 레코드를 검색하여 도움이 될 만한 근거를 포함하고 있을 가능성이 있는 청크를 반환합니다.

사용자의 질문
↓
검색 전략
...

주의: 검색된 청크는 아직 후보일 뿐입니다. 자동으로 LLM에 전달되는 최종적인 Context(문맥)가 되는 것은 아닙니다.

가장 단순한 RAG의 retriever(리트리버)는 다음과 같이 동작합니다.

사용자의 질문
↓
질문을 embedding vector로 변환한다
...

Top-K란 검색 점수가 높은 상위 K개의 후보를 반환하는 것을 말합니다.

이것은 통상적으로 **dense retrieval(밀집 검색)**이라고 불립니다. 질문과 청크가 dense vector, 즉 많은 차원이 정보를 가질 수 있는 수치 벡터로 표현되기 때문입니다.

**vector retrieval(벡터 검색)**이나 **vector search(벡터 탐색)**라는 표현을 접할 수도 있습니다. 이는 dense retrieval이 통상적으로 어떻게 구현되는지, 즉 embedding vector를 검색하는 형태로 구현된다는 것을 나타냅니다.

Dense retrieval은 질문과 유용한 문서가 서로 다른 단어를 사용하더라도 유사한 의미를 나타낼 때 효과적으로 작동합니다.

예시:

Question:
"Can a new employee take paid leave?"
Useful chunk:
...

표현은 다릅니다.

take paid leave
vs
annual vacation days are granted

하지만 의미는 연관되어 있습니다. Dense retrieval은 이러한 의미적 대응 관계를 완전 일치 키워드 검색보다 더 쉽게 찾아낼 수 있습니다.

Dense retrieval이 잘 작동하는 것은 embedding model이 검색 태스크에 적합할 때뿐입니다.

RAG에서는 질문이 짧은 문장인 경우가 많고, 저장된 청크는 더 긴 문장인 경우가 많습니다. 따라서 embedding model은 이 두 종류의 텍스트를 잘 비교할 수 있어야 합니다.

이것은 흔히 **query-document retrieval(질의-문서 검색)**이라고 불립니다. 질문은 다른 짧은 문장과 비교되는 것이 아니라, 문서의 passage(구절)나 청크와 비교됩니다.

Sentence Transformers semantic search(의미론적 검색)에서는 이러한 구성을 구현 관점에서 설명하고 있습니다. 문서 집합의 텍스트를 vector space(벡터 공간)에 embedding하고, 질문 또한 동일한 vector space에 embedding한 뒤, 가까운 corpus embedding을 취득합니다. 또한, 길이가 비슷한 텍스트끼리 비교하는 경우와 짧은 질문으로 긴 passage를 취득하는 경우의 차이점도 설명되어 있습니다.

구현상 알아둘 가치가 있는 점이 하나 더 있습니다.

"Nearest-neighbor search(최근접 이웃 탐색)"란 질문의 벡터와 가장 가까운 저장된 벡터를 찾는 것입니다. 소규모 데이터셋이라면 질문의 벡터와 모든 저장된 벡터를 비교할 수도 있습니다. 하지만 대규모 데이터셋에서는 그것이 느려질 수 있습니다.

따라서 대규모 vector search에서는 엄밀한 검색이 아닌 근사 검색이 자주 사용됩니다. 이것은 **approximate nearest-neighbor search(ANN, 근사 최근접 이웃 탐색)**라고 불립니다. 시스템은 모든 저장된 벡터와 일일이 비교하지 않음으로써 더 빠르게 검색합니다.

그 트레이드오프(trade-off)는 다음과 같습니다.

검색이 빨라진다
→ 엄밀 검색이었다면 찾았을 벡터를 일부 놓칠 가능성이 있다

Sentence Transformers semantic search의 approximate-nearest-neighbor 섹션에서는 이것이 recall (재현율)과 speed (속도) 사이의 트레이드오프(trade-off)로 설명됩니다.

Dense retrieval (밀집 검색)은 version, date, permission 조건과 같은 정확한 문자열이 중요한 단서인 경우 실패할 수 있습니다.

예를 들어:

Question:
"Does API v2.1 support ERR_AUTH_403?"

이 질문에는 다음과 같은 몇 가지 정확한 문자열이 포함되어 있습니다.

API
v2.1
ERR_AUTH_403

"authentication errors"에 관한 청크(chunk)는 의미적으로는 관련이 있을 수 있습니다. 하지만 정확한 API version이나 error code를 포함하고 있지 않을 가능성이 있습니다.

Dense retrieval은 다음과 같은 구분을 혼동하기도 합니다.

supported vs not supported
before 2024 vs after 2024
employee vs contractor
...

Retrieval score (검색 점수)가 높다는 것은 retriever (검색기)가 해당 청크의 순위를 높게 매겼다는 의미입니다.

그것이 해당 청크가 다음 조건들을 충족한다는 의미는 아닙니다.

• 사실로서 정확함
• 최신 정보임
• 이 사용자가 열람해도 됨
• 충분히 구체적임
• 근거로서 충분함

즉, semantic similarity (의미적 유사도) ≠ correctness (정확성) ≠ validity (유효성) ≠ enough evidence (충분한 근거)입니다.

일부 질문은 정확한 단어, identifier (식별자), 기호에 의존합니다.

예:

ERR_AUTH_403
getUserProfile()
invoice_status
...

이러한 경우에는 **sparse retrieval (희소 검색, lexical retrieval (어휘 검색)이라고도 함)**이 효과적입니다. Sparse retrieval은 텍스트를 단어, term (용어), 기호로 표현하기 때문입니다.

BM25는 고전적인 sparse retrieval 기법입니다.

BM25는 Okapi의 정보 검색 연구 흐름에서 유래되었습니다. Okapi at TREC-3에서는 TREC 검색 실험의 맥락에서 BM25를 보여줍니다.

BM25에서는 질문에 포함된 중요한 term을 포함하는 문서에 높은 점수를 부여합니다.

BM25가 유용한 이유는 질문과 문서 사이의 어휘적 중첩(lexical overlap)을 평가할 수 있기 때문입니다.

예:

Question:
"What does ERR_AUTH_403 mean?"
BM25는 다음을 포함하는 청크에 더 높은 점수를 줄 수 있습니다:
...

기술적으로 BM25는 단순한 "완전 일치"가 아닙니다. 특정 term이 문서 내에 얼마나 자주 등장하는지, 그리고 문서 집합 전체에서 얼마나 희귀한지에 따라 term에 서로 다른 가중치를 부여합니다.

Elasticsearch BM25 similarity에서는 구현 측면에서의 scoring (점수 산정)을 설명합니다. BM25는 term matching (용어 매칭)에 기반한 lexical similarity (어휘적 유사도) 기법이며, term frequency (용어 빈도)와 document length normalization (문서 길이 정규화)을 사용합니다.

여기서 중요한 주의 사항이 있습니다.

BM25가 도움이 되는 경우는 identifier가 검색 가능한 term으로 유지되어 있을 때뿐입니다. Error code, API name, version, product ID는 검색 시스템이 이를 직접 match (매칭)할 수 있는 형태로 저장되어 있어야 합니다.

Tokenizer (토크나이저) 또는 analyzer (분석기)는 문자열을 어떤 검색 가능한 term으로 만들지 결정하는 text-processing step (텍스트 처리 단계)입니다. 만약 ERR_AUTH_403을 부적절한 방식으로 분할해 버린다면, BM25는 해당 identifier를 안정적으로 match 하지 못할 가능성이 있습니다.

검색 엔진에서는 정확한 identifier(식별자)를 위해 값 전체를 유지하는 field(필드)가 필요한 경우가 많습니다. Elasticsearch의 keyword field type에서는 이러한 exact identifier(정확한 식별자)의 처리에 대해 설명하고 있습니다. ID, tag, status code, version string 등의 값은 analyzed text field가 아닌 keyword field에 저장되는 경우가 많습니다.

BM25는 고전적인 sparse retrieval (희소 검색) 기법이지만, sparse retrieval은 BM25에만 국한되지 않습니다.

Neural model (신경망 모델)을 사용하는 sparse retrieval 기법도 있습니다. SPLADE가 그 한 예입니다. SPLADE는 sparse retrieval의 개념을 유지하면서, 검색을 위해 term (용어)을 어떻게 확장하고 가중치를 부여할지를 학습합니다.

Retrieval type (검색 유형)	Other names (기타 명칭)	主な手がかり (주요 단서)	得意なもの (강점)	苦手なもの (약점)
Dense retrieval (밀집 검색)	Vector search / vector retrieval	Vector similarity (벡터 유사도)	유의어, 모호한 질문, 개념적 일치	정확한 문자열, 미세한 사실 관계의 차이
Sparse retrieval (희소 검색)	Lexical retrieval / term-based retrieval	Term matching (용어 매칭)	Error code, API name, product ID, version	유의어, 유의어 표현, 모호한 의도

질문이 dense matching (밀집 매칭)과 sparse matching (희소 매칭) 모두를 필요로 하는 경우, hybrid search (하이브리드 검색)가 유용합니다.

**Hybrid search (하이브리드 검색)**는 dense retrieval과 sparse retrieval을 결합합니다.

예시:

Question:
"Does API v2.1 support ERR_AUTH_403 during OAuth login?"

이 질문에는 두 가지 모두가 필요합니다.

meaning-based clue (의미 기반 단서):
OAuth login / authentication support
exact-text clue (정확한 텍스트 단서):
ERR_AUTH_403, v2.1

Dense retrieval은 인증 관련 동작에 관한 청크를 찾는 데 도움이 됩니다. Sparse retrieval (BM25)은 정확한 identifier가 무시되지 않도록 하는 데 도움이 됩니다.

이 통합 단계는 흔히 **fusion (융합)**이라고 불립니다.

Azure AI Search의 hybrid search는 full-text search (전체 텍스트 검색)와 vector query (벡터 쿼리)를 결합한 후, 하나로 통합된 검색 결과 세트를 반환하는 구체적인 retrieval design (검색 설계)을 보여줍니다. 이는 매우 유용합니다. Hybrid search는 단순히 "둘 다 사용한다"는 모호한 개념이 아니라, 순위가 매겨진 검색 결과들을 하나로 합쳐야 하기 때문입니다.

Dense retrieval과 sparse retrieval이 서로 다른 ranked list (순위 목록)를 생성할 경우, 시스템에는 이를 통합할 방법이 필요합니다. 자주 사용되는 방법 중 하나가 **Reciprocal Rank Fusion (RRF)**입니다.

RRF는 raw score (원시 점수)를 직접 비교하는 대신 순위를 사용합니다. 이는 매우 유용합니다. Vector similarity score (벡터 유사도 점수)와 BM25 score (BM25 점수)는 동일한 종류의 수치가 아니기 때문입니다.

Azure AI Search RRF ranking에서는 Reciprocal Rank Fusion이 여러 개의 ranked result list (순위 결과 목록)를 하나의 unified ranking (통합 순위)으로 통합하는 방법을 설명합니다.

일부 청크는 의미적으로는 관련이 있더라도, 답변에 필요한 version, date, language, document type, permission의 범위에서 벗어나 있을 수 있습니다.

metadata filtering (메타데이터 필터링)
= 조건에 맞는 범위 내에서만 관련 청크를 검색함

유용한 metadata (메타데이터)에는 product_version, date, language 등이 있습니다.

document_type,

permission_group

등이 있습니다.

Metadata filtering (메타데이터 필터링)을 기능하게 하려면, 이러한 값들이 청크(chunk) 본문 안에 적혀 있는 것만으로는 불충분합니다. 필터링에 사용할 수 있는 metadata (메타데이터)로서 저장되어 있어야 합니다.

Qdrant에서는 레코드의 metadata를 “payload”라고 부릅니다. Qdrant filtering (필터링)에서는 payload field를 vector search (벡터 검색)의 필터링 조건으로 사용하는 방법이 제시되어 있습니다.

Milvus filtered search (필터링 검색)에서는 metadata filtering (메타데이터 필터링)을 통해 vector search (벡터 검색)에 사용할 검색 범위를 좁히는 방법이 제시되어 있습니다.

Permission (권한)은 relevance (관련성)보다 더 엄격하게 다뤄야 할 제약 조건입니다. 사용자가 특정 문서를 볼 권한이 없는 경우, 해당 제한 대상인 청크는 단순히 순위가 낮게 매겨지는 것이 아니라, retrieval (검색) 단계에서 제외되어야 합니다.

Top-K = 상위 K개의 후보를 반환

Top-K는 일반적인 검색 설정입니다. Retriever (리트리버)가 dense (밀집), sparse (희소), hybrid (하이브리드) 중 무엇이든 간에, 상위 후보를 몇 개 반환할지 결정해야 합니다.

실무상 Top-K는 **candidate budget (후보 예산)**입니다. 즉, 답변 준비에 사용할 수 있는 검색된 청크의 수를 제어합니다.

K의 크기	후보 수	노이즈	유용한 근거를 놓칠 리스크
작은 K	후보가 적음	노이즈가 적음	리스크가 높음
큰 K	후보가 많음	노이즈가 많음	리스크가 낮음

따라서 트레이드오프 (trade-off)는 다음과 같습니다.

유용한 근거를 놓치지 않기
vs
쓸모없는 근거를 너무 많이 포함하지 않기

직관적으로, high recall (높은 재현율)이란 유용한 근거의 대부분을 잘 검색하고 있는 상태를 의미합니다. 즉, 관련 항목을 놓치는 경우가 적다는 것입니다. 반면, high precision (높은 정밀도)이란 검색된 근거의 대부분이 실제로 유용한 상태를 의미합니다. 즉, 무관한 항목이 섞여 들어오는 경우가 적다는 것입니다.

후보 검색은 보통 유용한 근거를 놓치지 않는 방향으로 기울어집니다. 왜냐하면 시스템은 검색된 청크만을 사용할 수 있기 때문입니다.

검색되지 않음
↓
나중에 사용할 수 없음
...

하지만 '더 많이 검색하는 것'이 항상 좋은 것은 아닙니다. 무관한 후보가 너무 많으면 latency (지연 시간), cost (비용), 후속 처리 단계에서의 혼란이 증가할 가능성이 있습니다.

실무적인 규칙은 이렇습니다. Retrieval (검색)은 보통 올바른 근거를 놓치지 않도록 해야 합니다. 하지만 쓸모없는 후보를 대량으로 후속 단계에 넘겨서는 안 됩니다.

후보 검색은 그 자체로 완벽한 최종 Context (컨텍스트)를 만들 필요는 없습니다. 유용한 후보 집합을 만드는 것이 목적입니다.

Stanford IR book의 Evaluation of ranked retrieval results (순위가 매겨진 검색 결과의 평가)에서는 기술적인 평가 측면이 설명되어 있습니다. Ranked retrieval (순위 기반 검색)에서는 상위 K개의 retrieved documents (검색된 문서)에 대해 precision (정밀도)과 recall (재현율)을 고려할 수 있습니다.

검색 전략이 좋지 않다는 것은 RAG 시스템에 부적절한 후보 집합을 전달하게 되는 것을 의미합니다.

흔히 발생하는 실패 사례는 다음과 같습니다.

실패 패턴	발생하는 현상	전형적인 수정 방법
Pure dense retrieval (순수 밀집 검색)이 exact term (정확한 용어)을 놓침	결과는 올바른 토픽과 관련이 있지만, 정확한 API name, error code, product ID를 놓침	Sparse retrieval (희소 검색) 또는 hybrid search (하이브리드 검색)를 추가한다. Indexing (인덱싱) 시 identifier (식별자)를 유지한다
...

이 표는 RAG에서의 중요한 원칙도 보여줍니다.

Retrieval (검색)의 문제는 retrieval (검색) 이전에 발생했을 가능성이 있습니다.

예를 들어, version metadata (버전 메타데이터)가 생성되지 않았거나 올바르게 저장되지 않았다면, version field가 존재하지 않기 때문에 retrieval (검색) 시 version으로 필터링할 수 없습니다.

Error code가 parsing (파싱), tokenization (토큰화), indexing (인덱싱) 과정에서 손상된 경우, BM25는 이를 안정적으로 match (매칭)하지 못할 가능성이 있습니다.

Chunk (청크)가 너무 크거나 너무 작은 경우, dense retrieval (밀집 검색)과 sparse retrieval (희소 검색) 모두 성능이 저하될 수 있습니다.

따라서 검색 전략은 검색 가능한 데이터가 어떻게 준비되었는지에 따라 달라집니다.

text preparation (텍스트 준비)
→ clean searchable text (정제된 검색 가능 텍스트)를 정의한다
chunking (청킹)
...