하이브리드 검색이란? 제품 번호와 자연어 질문을 함께 찾는 법

서로 다른 색의 자갈 두 줄이 한 그릇으로 모이는 모습. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

문서 검색에서 제품 번호는 잘 못 찾는데 비슷한 뜻의 설명은 잘 찾는 경우가 있습니다. 반대로 단어가 일치하지 않으면 관련 문서를 놓치기도 합니다. 하이브리드 검색은 이 두 종류의 검색 결과를 함께 다루는 방식입니다.

정확한 이름을 찾는 질문과 뜻이 비슷한 문장을 찾는 질문을 나눠 검색 결과를 비교하세요.

서로 다른 실패를 보완하려고 두 검색을 합칩니다

Azure AI Search의 하이브리드 검색 설명은 전체 텍스트 검색과 벡터 검색을 함께 실행하고 결과를 합치는 구조를 제시합니다. 제품 코드나 고유명사는 정확한 단어 대응이 중요하고, 사용자가 풀어 쓴 증상은 의미상 가까운 문서를 찾는 데 유리할 수 있습니다.

가상의 부품 설명서에 “ZX-41 교체 주기”와 “소음이 커질 때 점검할 부품”이라는 질문이 들어온다고 합시다. 앞 질문은 모델 번호를 틀리면 다른 제품의 문서가 섞입니다. 뒤 질문은 사용자가 설명서의 정확한 용어를 모르기 때문에 단어만 맞추면 놓칠 수 있습니다. 두 질문을 같은 평균 점수로 묶으면 어느 쪽이 나빠졌는지 보기 어렵습니다.

Azure AI Search에서 이 구조는 텍스트 search와 임베딩을 담은 vectorQueries를 한 요청에 넣는 방식으로 표현됩니다.

{
  "search": "ZX-41 소음 점검",
  "vectorQueries": [{
    "kind": "vector",
    "vector": [0.12, -0.03, 0.44],
    "fields": "contentVector",
    "k": 50
  }],
  "filter": "product eq 'ZX-41'",
  "top": 10
}

실제 벡터는 인덱스의 차원 수와 맞는 숫자 배열이어야 하며, 위 숫자는 구조만 보이는 축약 예시입니다. k는 벡터 쪽 후보 수이고 top은 결합된 결과에서 반환할 수입니다. Azure 문서에서 두 검색은 병렬 실행되고 RRF로 하나의 결과 집합이 됩니다. 이 예시는 Azure 요청 구조를 보여 주는 것이지, 다른 검색 엔진의 파라미터 이름이 같다는 뜻은 아닙니다.

점수를 바로 더하지 않고 순위를 합치는 이유

키워드 검색 점수와 벡터 유사도는 같은 단위가 아닙니다. 예를 들어 한쪽의 12점과 다른 쪽의 0.8을 단순히 더하면 숫자 크기가 큰 검색기가 유리해질 수 있습니다. Azure 문서의 하이브리드 결과는 RRF의 @search.score를 사용하며, 선택적으로 semantic ranker를 적용하면 최종 의미 재정렬 점수인 @search.rerankerScore가 별도로 생깁니다. 하이브리드 결합 점수와 의미 재정렬 점수를 한 숫자로 오해하지 마세요.

RRF 설명은 여러 결과 목록에서 문서의 순위를 이용해 점수를 만들고 합산하는 방법을 설명합니다. 대표 형태는 1 / (순위 + k)입니다. 여기서 상수 k와 검색 후보 개수를 뜻하는 top-k는 다른 값입니다.

상수를 60으로 둔 산술 예시를 보겠습니다. 이것은 품질 측정이 아닙니다.

ID	키워드	벡터	RRF 합
A	1	4	약 0.03202
B	2	1	약 0.03252

B는 한 목록에서 2위지만 다른 목록에서 1위여서 합산 점수가 조금 높습니다. 이 계산은 왜 두 검색에서 고르게 찾은 문서가 올라오는지 보여줍니다. 그 문서가 사실상 정답이라는 증명은 아닙니다.

합치기 전에 검색 단위를 맞춥니다

같은 문서가 한쪽에서는 페이지 단위, 다른 쪽에서는 문단 단위로 잡히면 무엇을 같은 결과로 합칠지 정해야 합니다. 문서 식별자와 청크 식별자를 구분하고, 중복 조각이 결과를 차지하지 않는지도 보세요.

접근 권한과 날짜 조건은 순위와 바꿀 수 없는 제약입니다. 검색 결과가 적다고 필터를 없애면 관련성은 높아 보이더라도 읽으면 안 되는 문서를 가져올 수 있습니다. 권한은 후보 생성부터 최종 전달까지 유지해야 한다는 것이 이 글의 설계 제안입니다.

한 요청이 결과가 되기까지의 경로

사용자 질문
  ├─ 텍스트 검색 → 키워드 후보 목록
  ├─ 질문 임베딩 → 벡터 후보 목록
  └─ 두 목록 결합 → 필터·중복 제거 → 최종 후보

두 검색을 병렬로 실행한다고 결과가 자동으로 좋아지는 것은 아닙니다. 텍스트 검색의 분석기, 벡터를 만든 모델과 전처리, 각 후보 개수, 결합 공식, 필터 적용 시점이 모두 결과에 영향을 줍니다. 문제를 재현하려면 최종 상위 문서만 저장하지 말고 각 검색기의 원래 순위도 함께 남기는 편이 좋습니다.

가상의 로그는 다음 정도면 원인을 좁힐 수 있습니다.

{
  "query_id": "q-17",
  "query": "ZX-41 소음 점검",
  "lexical": [["doc-a", 1], ["doc-c", 2]],
  "vector": [["doc-b", 1], ["doc-a", 4]],
  "fused": [["doc-a", 1], ["doc-b", 2]],
  "filters": {"product": "ZX-41", "access": "public"}
}

점수 원본을 직접 비교하기보다 각 목록의 순위와 결합 결과를 기록하면 “키워드 검색은 찾았는데 결합 후 밀렸다”와 “벡터 검색이 다른 제품을 가져왔다”를 나눌 수 있습니다.

필터를 어디에 적용하는지가 결과 수를 바꿉니다

제품·날짜·권한 필터가 있다면 후보 생성 전후 중 어디에 적용되는지 엔진 문서를 확인해야 합니다. Azure AI Search에는 벡터 필터를 preFilter 또는 postFilter로 적용하는 옵션이 있고, 후보를 10개 찾은 뒤 9개를 필터링하는 구현과 필터를 만족하는 문서 안에서 10개를 찾는 구현은 같은 top=10처럼 보여도 결과가 다릅니다. 문서가 semantic ranker를 사용한다면 어떤 필터 모드가 적합한지 테스트하라는 조건도 함께 확인해야 합니다.

권한 필터는 관련성 튜닝 수단이 아닙니다. Azure의 filter를 넣었다는 사실 자체가 애플리케이션의 전체 권한 모델을 증명하는 것은 아니므로, 문서별 ACL을 인덱스에 어떻게 반영하고 사용자 식별자와 어떻게 결합하는지도 별도로 설계해야 합니다. 결과가 적다고 제거하면 안 됩니다. 권한을 만족하는 후보가 부족하다면 인덱스 범위, 필터 선택도, 후보 개수와 데이터 누락을 조사합니다. 최종 응답 단계에서만 권한을 지우는 방식은 중간 로그나 모델 문맥에 금지 자료가 들어갈 수 있어 충분하지 않습니다.

질문 유형별로 별도 평가합니다

질문 유형	가상 질문	먼저 볼 실패
정확 코드	ZX-41	다른 코드의 의미 유사 문서가 앞섬
동의어	전원이 자꾸 나가요	설명서 용어가 달라 키워드 검색 누락
혼합	ZX-41 전원이 자꾸 나가요	코드·증상 중 하나만 반영
부정	ZX-41이 아닌 모델	부정 조건 손실
최신성	현재 교체 절차	폐기된 설명서가 높은 순위

정답 문서 하나만 표시하기보다 허용 가능한 문서와 명백히 틀린 문서를 함께 라벨링하면 변화의 방향을 보기 쉽습니다. 초기 후보에 정답이 들어왔는지, 최종 상위 k에 들어왔는지, 사용자가 읽으면 안 되는 문서가 섞였는지를 나눠 측정합니다.

튜닝 순서

1. 키워드 검색만 실행해 코드·고유명사 질문을 확인합니다.
2. 벡터 검색만 실행해 자연어·동의어 질문을 확인합니다.
3. 두 목록의 문서 ID와 청크 단위를 맞춥니다.
4. 기본 결합 결과를 저장합니다.
5. 후보 개수와 결합 상수를 한 번에 하나씩 바꿉니다.
6. 정확도뿐 아니라 지연, 빈 결과, 권한 위반을 함께 기록합니다.

한 번에 임베딩 모델, 분석기, 청크 크기, 후보 개수를 모두 바꾸면 무엇이 개선을 만들었는지 알기 어렵습니다. 하이브리드 검색은 검색기 두 개를 켜는 기능이 아니라 서로 다른 실패를 관측하고 결합하는 파이프라인으로 보는 편이 좋습니다.

도입 판단은 질문 묶음별로 합니다

실제 이용자가 할 법한 제품 번호 질문, 증상 질문, 축약어 질문을 따로 모읍니다. 키워드만, 벡터만, 두 결과를 합친 경우를 비교해 정답 근거가 후보에 들어오는지 살펴보세요. 특정 코드에서는 키워드 검색을 더 중시하는 편이 나을 수도 있고, 문장 질문에서는 다른 결과가 나올 수 있습니다.

이 글은 2026년 9월 7일 확인한 Azure 문서로 원리를 설명한 것입니다. RRF의 계산 예시 외에 실제 검색 성능을 측정하지 않았습니다. 엔진마다 필터와 합산 방식이 다르므로 같은 옵션 이름만 보고 설정을 옮기지는 마세요.