프로덕션급 RAG: 벡터 검색만으로는 부족한 이유 (그리고 하이브리드 검색이 그 간극을 메우는 방법)

당신의 팀이 개발 중인 SaaS 플랫폼을 위해 세련된 RAG 기반 문서 어시스턴트를 막 배포했다고 상상해 보십시오. 테스트 단계에서는 완벽하게 작동했습니다. 기능도 잘 알고 있으며, 환각 (hallucination) 없이 완벽하게 작성된 세 개의 문단으로 질문에 답변합니다. 하지만 출시 이틀 후, 시니어 개발자가 Slack으로 당신에게 말을 겁니다. "이봐, AI 봇이 PX-9000-v2 구성 오류에 대해 아무것도 찾지 못해."

로그를 확인합니다. 사용자는 정확한 오류 코드를 쿼리했습니다. 의미론적 의미 (semantic meaning)에 최적화된 벡터 검색 (Vector search)은 일반적인 오류 처리 및 구성 모범 사례에 관한 문서를 반환했지만, PX-9000-v2에 대한 구체적인 기술 설명은 리트리버 (retriever)의 결과(또는 청크 (chunks)) 중 50번째 위치에 묻혀 있었습니다. 그 이유는 해당 키워드의 "의미론적 (semantic)" 거리가 "오류 (error)"라는 일반적인 개념과 너무 멀었기 때문입니다.

production RAG에서 의미론적 유사성 (semantic similarity)은 강력한 도구이지만, 완전한 도구는 아닙니다. ID, 약어, 전문 용어와 같은 실제 세계의 쿼리를 견뎌낼 수 있는 검색 시스템을 구축하려면 하이브리드 검색 (hybrid search)이 필요합니다.

정보 검색의 이중성

하이브리드 검색이 왜 필요한지 이해하려면, 데이터를 검색하는 두 가지 뚜렷한 방식인 의미론적 의도 (semantic intent)와 어휘적 정밀도 (lexical precision)를 살펴보아야 합니다.

벡터 검색 (Vector Search, Semantic)

벡터 검색 (Vector search)은 "벡터 임베딩 (vector embeddings)"라고 불리는 텍스트의 밀집된 수치 표현인 임베딩 (embeddings)에 의존합니다. 이는 쿼리의 _의미_를 포착합니다. 만약 제가 "가장 빠른 정찰기"를 검색한다면, 벡터 검색 엔진은 단어가 일치하지 않더라도 "SR-71 Blackbird"와의 관계를 이해합니다. 이는 자연어, 유의어, 그리고 모호한 사용자 의도를 처리하는 데 탁월합니다.

키워드 검색 (Keyword Search, Lexical)

키워드 검색 (Keyword Search, 전통적인 Full-Text Search)은 정확성에 관한 것입니다. 이는 출현 빈도를 계산하고, 문서 길이를 고려하며, 희귀한 용어의 일치에 가중치를 둡니다. 사용자가 "PX-9000-v2"를 입력했을 때, 그들은 해당 문자열과 유사한 것을 원하는 것이 아니라, 바로 그 정확한 문자열을 원합니다.

벡터 임베딩 (Vector embeddings)은 광범위한 의미론적 관계를 기반으로 학습되기 때문에 이 지점에서 실패하는 경우가 많습니다. 고차원 벡터 공간 (High-dimensional vector space)에서 "PX-9000-v1"과 "PX-9000-v2"는 서로 이웃할 수도 있고, 더 나쁜 경우에는 "PX-9000"이 관련 없는 "9000" 시리즈 제품 클러스터로 끌려갈 수도 있습니다. 키워드 검색은 이러한 특정 기술 식별자, 버전 번호, 그리고 임베딩이 일반적인 범주로 뭉뚱그려버리기 쉬운 전문 용어의 "롱테일 (long tail)"을 걸러내는 하이패스 필터 (High-pass filter) 역할을 합니다.

하이브리드 검색 (Hybrid search)은 이러한 검색 방식들의 강점을 하나의 순위가 매겨진 결과 집합으로 병합하는 것입니다.

결과 병합: 상호 순위 결합 (Reciprocal Rank Fusion, RRF)

하이브리드 검색의 공학적 과제는 "사과와 오렌지" 문제(서로 비교할 수 없는 대상을 비교하는 문제)입니다. 벡터 검색은 거리 점수 (예: 코사인 거리 (Cosine distance))를 제공하며, 이는 보통 0과 1 사이의 값입니다. 반면 키워드 검색은 빈도 점수 (Frequency score)를 제공하며, 이는 어떤 양수든 될 수 있습니다. 이 둘을 단순히 더할 수는 없습니다.

이를 해결하기 위해 **상호 순위 결합 (Reciprocal Rank Fusion, RRF)**을 사용할 수 있습니다. RRF는 원시 점수 (Raw scores)를 완전히 무시하고 _순위 (Rankings)_에 집중하는 알고리즘입니다. 만약 청크 A가 벡터 검색에서 1위이고 키워드 검색에서 5위라면, RRF는 해당 위치를 기반으로 새로운 점수를 계산합니다. 공식은 우아할 정도로 단순합니다:

score = Σ 1 / (k + rank(c, r))

여기서:

c는 청크 (Chunk)입니다.
r은 순위 집합 (예: 벡터 결과 및 키워드 결과)입니다.
k는 단일 최상위 결과가 최종 점수를 완전히 지배하는 것을 방지하기 위한 상수 (보통 60)입니다.

'k=60'의 의미

왜 60일까요? 이것은 마법의 숫자는 아니지만, 매우 안정적인 숫자입니다. RRF에 관한 원문 연구에서 저자들은 다양한 값을 테스트했으며, k=60이 광범위한 데이터셋에 걸쳐 다른 값들보다 일관되게 우수한 성능을 보인다는 것을 발견했습니다.

수학적 직관의 관점에서 볼 때, k는 "감쇠기 (dampener)" 역할을 합니다. 만약 k가 1이라면, 1위 (1/2 = 0.5)와 2위 (1/3 ≈ 0.33) 사이의 차이는 매우 커질 것입니다 (0.17). 이는 오직 벡터 검색 (vector search)에서만 1위에 오른 문서가 키워드 검색 (keyword search)과 벡터 검색 모두에서 2위에 오른 문서를 쉽게 이길 수 있음을 의미합니다.

k=60으로 설정하면, 1위 (1/61 ≈ 0.01639)와 2위 (1/62 ≈ 0.01613)의 영향력 차이가 최소화됩니다 (0.00026). 이는 알고리즘이 단 하나의 검색 방식에서만 정점을 찍는 문서보다 합의 (consensus, 두 검색 방식 모두에서 좋은 성능을 보이는 문서)를 우선시하도록 강제합니다. 따라서 이는 키워드 검색과 벡터 유사도 (vector similarity)의 서로 다른 점수 분포를 결합하는 데 필요한 "평활화 (smoothing)"를 제공합니다.

구현 (Implementation)

일반적으로 하이브리드 검색 (hybrid search)을 구현한다는 것은 두 개의 별도 데이터베이스를 유지하는 것을 의미합니다. 즉, 키워드 검색 (keyword retrieval)을 위한 Elasticsearch 또는 Solr와 같은 키워드 검색 엔진과, 의미론적 검색 (semantic search)을 위한 Pinecone 또는 Weaviate와 같은 전용 벡터 데이터베이스 (vector database)를 운영한 다음, 양쪽에서 결과를 수집하고 RRF 계산을 수행하여 통합된 순위 목록을 반환하는 커스텀 오케스트레이션 계층 (orchestration layer)을 작성하는 것입니다.

전체 텍스트 검색 (full text search)과 벡터 검색을 모두 기본적으로(또는 확장을 통해) 지원하는 관계형 데이터베이스 (relational databases)를 사용하면, 윈도우 함수 (window functions)나 CTE를 통해 단일 SQL 쿼리로 사용할 수 있습니다. 다음은 MariaDB를 사용한 예시입니다:

CREATE OR REPLACE TABLE phrases (
    content VARCHAR(200) UNIQUE,
    embedding VECTOR(1536),
...

이러한 방식들을 확장하는 것 자체가 하나의 도전 과제가 될 수 있으며, 아키텍처 오버헤드 (architectural overhead)를 수반합니다. MariaDB Enterprise Platform에는 내부적으로 오케스트레이션 (orchestration)을 처리하는 즉시 사용 가능한 RAG 서비스를 구현하여 이 모든 과정을 단순화하는 MariaDB AI RAG라는 제품이 포함되어 있습니다. 따라서 별도의 인덱스 (indices)를 관리하고 병합 로직을 구현하는 대신, 검색 전략을 단순히 설정값으로 선택할 수 있는 REST 서비스와 상호작용하면 됩니다.

예를 들어, 응답을 생성하기 위해 오케스트레이션 API를 사용할 때 단일 파라미터만으로 하이브리드 검색 (hybrid search)으로 전환할 수 있습니다:

POST /orchestrate/generation
{
  "query": "How do I resolve PX-9000-v2 configuration errors?",
...

또는, 직접 RAG 로직을 구축하고 있으며 단순히 검색된 원본 문서만 필요한 경우:

POST /hybrid_search
{
  "query": "PX-9000-v2",
...

백그라운드에서 MariaDB AI RAG는 임베딩 (embeddings)에 대한 벡터 유사도 검색 (vector similarity search)과 원본 텍스트에 대한 전문 키워드 검색 (full-text keyword search)을 실행하고, RRF (Reciprocal Rank Fusion) 계산을 적용하여 최적화된 단일 리스트를 반환합니다. MariaDB AI RAG에 대한 자세한 정보는 docs를 확인하세요.

운영상의 영향: 정확도 vs. 지연 시간 (Accuracy vs. Latency)

소프트웨어 엔지니어링에는 항상 트레이드오프 (tradeoffs)가 존재하며, 하이브리드 검색도 예외는 아닙니다. 하나의 검색 알고리즘 대신 두 개의 검색 알고리즘을 실행함으로써 컴퓨팅 오버헤드 (compute overhead)가 추가됩니다.

운영 관점에서 이는 두 가지 지표를 모니터링해야 함을 의미합니다:

Retrieval Latency (p95): 키워드 검색 (keyword search)이 일반적으로 벡터 검색 (vector search)보다 빠르지만, 결합된 실행 및 RRF 병합 (merge)은 항상 벡터 검색 단독 실행보다 느릴 것입니다. 테스트 시, (적절하게 구현되었을 경우) 순수 벡터 검색에 비해 검색 시간이 10%에서 30% 정도 증가할 것을 예상하십시오.
Hit Rate @ K: 이것은 주요 성공 지표 (success metric)입니다. 예를 들어, 하이브리드 검색 (hybrid search)을 통해 Hit Rate @ 5가 70%에서 90%로 상승한다면, 지연 시간 (latency)의 트레이드오프 (trade-off)는 거의 확실히 그만한 가치가 있습니다.

하지만 대부분의 RAG 애플리케이션에서 병목 현상 (bottleneck)은 검색 단계 (retrieval phase)가 아니라 LLM 생성 단계 (generation phase)인 경우가 많습니다. LLM이 정확한 컨텍스트 (context)를 전달받을 수 있도록 검색 쿼리에 20ms를 추가하는 것은 대부분의 아키텍트 (architect)들이 언제나 기꺼이 선택할 트레이드 (trade)입니다. "빠르지만" 부정확한 답변(또는 누락된 컨텍스트로 인한 환각 (hallucination))의 비용은 키워드 인덱스 (keyword index)의 컴퓨팅 비용보다 훨씬 더 높습니다.

결론: 하이브리드로 시작하세요

데모 이상의 복잡한 무언가를 위해 RAG를 구축하고 있다면, 사용자들이 여러분의 벡터 임베딩 (vector embeddings)에서 발생하는 간극을 발견할 때까지 기다리지 마십시오. 벡터 검색은 의도 (intent)를 파악하는 데 환상적이지만, 설계상 "퍼지 (fuzzy)"합니다. 하이브리드 검색은 엔터프라이즈 애플리케이션 (enterprise applications)이 요구하는 어휘적 안전망 (lexical safety net)을 제공합니다. RRF와 같은 알고리즘이나, 더 나아가 MariaDB AI RAG와 같이 즉시 사용 가능한 구현체를 사용하여 고품질 검색 시스템을 사용하는 RAG 애플리케이션을 구축하십시오. 결국, 정확한 컨텍스트를 검색하는 것이 RAG 파이프라인 (pipeline)의 핵심 부분입니다.