하이브리드 검색과 Rank Fusion(시맨틱 + 키워드)

개요

Fess의 하이브리드 검색은 기존 키워드 검색(BM25)과 시맨틱(벡터) 검색을 결합하고, 두 결과 집합을 Rank Fusion으로 병합하여 더 정확하고 관련성 높은 랭킹을 제공합니다. Rank Fusion은 여러 검색기의 결과를 하나의 최적화된 랭킹으로 통합합니다.

Fess 15.9에서는 시맨틱 검색(콘텐츠 청킹 + 벡터 검색)이 코어 기능으로 제공됩니다. 이를 활성화하면 시맨틱 서처가 자동으로 Rank Fusion에 등록됩니다. 설정 방법은 시맨틱 검색(콘텐츠 청킹 + 벡터 검색) 을 참조하세요.

Fess 의 Rank Fusion 기능은 여러 검색 결과를 통합하여 보다 정확한 검색 결과를 제공합니다.

Rank Fusion이란

Rank Fusion은 여러 검색 알고리즘이나 스코어링 방법(예: 키워드/BM25 검색과 시맨틱/벡터 검색)의 결과를 결합하여 단일 최적화된 랭킹을 생성하는 기술입니다.

주요 장점:

  • 서로 다른 알고리즘의 장점을 결합

  • 검색 정확도 향상

  • 다양한 검색 결과 제공

지원 알고리즘

Fess 에서는 RRF (Reciprocal Rank Fusion) 알고리즘을 지원합니다.

RRF (Reciprocal Rank Fusion)

RRF는 각 검색 결과에서 문서의 순위 역수를 합산하여 스코어를 계산합니다. 여러 검색기(searcher)에서 가져온 문서는 각각의 스코어가 더해집니다.

계산식:

score(d) = Σ 1 / (k + rank(d))
  • k: 순위의 영향도를 조정하는 상수 파라미터 (기본값: 20)

  • rank(d): 각 검색 결과에서 문서 d의 순위 (0부터 시작)

  • Σ: 문서 d가 등장한 모든 검색기에 걸친 합계

참고

Fess 측에서 융합하는 경우(기본값), 융합 알고리즘은 RRF로 고정되어 있으며 검색기별 가중치도 지원하지 않습니다. 각 검색기의 기여도는 동일한 가중치로 합산되며, 랭킹 경향을 조정할 수 있는 것은 rank.fusion.rank_constant 뿐입니다. 검색 엔진 측에서 융합하는 경우에는 다른 결합 방식이나 검색기별 가중치를 지정할 수 있습니다(검색 엔진 측에서의 Rank Fusion 참조).

설정

fess_config.properties

기본 설정:

# 윈도우 사이즈 (융합 대상 결과 수)
# 주의: paging.search.page.max.size × 2 이상이어야 합니다.
# 설정값이 이 최소값보다 작으면 최소값이 자동으로 사용됩니다.
rank.fusion.window_size=200

# RRF의 rank_constant (k 파라미터)
rank.fusion.rank_constant=20

# 병렬 처리 스레드 수 (0 이하인 경우 availableProcessors × 3 ÷ 2 + 1 이 사용됩니다)
rank.fusion.threads=-1

# 스코어 필드명 (융합 후 스코어를 저장하는 필드)
rank.fusion.score_field=rf_score
프로퍼티 기본값 설명
rank.fusion.window_size 200 융합 대상으로 각 검색기에서 가져오는 결과의 최대 건수. paging.search.page.max.size × 2 (기본값은 200) 이상이어야 하며, 작은 값이 설정된 경우 자동으로 최소값으로 올려집니다(시작 시 WARN 로그가 출력됩니다).
rank.fusion.rank_constant 20 RRF 계산식의 상수 k. 값을 크게 할수록 상위 순위와 하위 순위 간의 스코어 차이가 작아집니다.
rank.fusion.threads -1 여러 검색기를 병렬 실행하는 고정 스레드 풀의 스레드 수. 0 이하를 지정하면 availableProcessors × 3 ÷ 2 + 1 이 자동으로 사용됩니다(정수 연산이므로 소수점 이하는 버림. 예: 4코어 → 7, 5코어 → 8).
rank.fusion.score_field rf_score 융합 후 스코어를 저장하는 결과 문서의 필드명.

참고

설정 반영 시점

위 4개 설정은 모두 변경 사항을 반영하려면 Fess를 재시작해야 합니다. fess_config.properties 에서 읽어들인 값은 JVM 내에 캐시되므로, 가동 중에 파일을 수정해도 반영되지 않습니다.

참고로 rank.fusion.window_size 는 시작 시 한 번만, rank.fusion.threads 는 스레드 풀을 생성하는 시점에 읽힙니다. 스레드 풀은 default 이외의 검색기(시맨틱 서처 등)가 등록될 때 생성되므로, 시맨틱 검색이 비활성화되어 있으면 스레드 풀 자체가 생성되지 않습니다.

JVM 시스템 프로퍼티

사용할 검색기는 JVM 시스템 프로퍼티로 지정합니다. fess.in.sh 에 다음과 같이 작성합니다:

FESS_JAVA_OPTS="$FESS_JAVA_OPTS -Drank.fusion.searchers=default,semantic_chunk"

fess.in.bat 의 경우에는 다음과 같이 작성합니다:

set FESS_JAVA_OPTS=%FESS_JAVA_OPTS% -Drank.fusion.searchers=default,semantic_chunk

이 프로퍼티의 동작은 다음과 같습니다:

  • fess_config.properties 가 아닌 JVM 옵션으로 설정합니다. 키 이름은 rank.fusion.searchers 그 자체를 지정하세요. 다른 설정에서 흔히 사용되는 -Dfess.config. 나 -Dfess.system. 을 붙인 형식(-Dfess.config.rank.fusion.searchers 등)은 인식되지 않습니다.

  • JVM 옵션 대신 관리 화면의 “시스템 > 일반”에 있는 “시스템 속성” 칸에 rank.fusion.searchers=default,semantic_chunk 와 같이 한 줄로 기술할 수도 있습니다. 다만 이 칸의 값은 같은 이름의 시스템 프로퍼티가 아직 설정되어 있지 않은 경우에만 적용됩니다. 따라서 -D 로 이미 지정되어 있으면 JVM 옵션이 우선하며, 한 번 적용된 값을 변경하려면 Fess를 재시작해야 합니다.

  • default 는 표준 키워드 검색을 수행하는 검색기로 항상 사용할 수 있습니다.

  • 검색기 이름은 구현 클래스명에서 끝의 Searcher 를 제거한 뒤 스네이크 케이스 소문자로 변환한 형태입니다(SemanticChunkSearcher → semantic_chunk). 코어에 통합된 시맨틱 서처(시맨틱 검색(콘텐츠 청킹 + 벡터 검색))는 semantic_chunk 라는 이름으로 등록됩니다.

  • 이 프로퍼티를 지정하지 않으면 등록된 모든 검색기가 사용됩니다. 지정한 이름 중 어느 것도 등록된 검색기와 일치하지 않으면 default 검색기만 사용됩니다. 코어에 통합된 시맨틱 서처(시맨틱 검색(콘텐츠 청킹 + 벡터 검색))를 사용하는 경우, 일반적으로는 이 프로퍼티 자체를 설정할 필요가 없습니다.

  • Rank Fusion에 의한 결과 융합은 사용 가능한 검색기가 2개 이상인 경우에 실행됩니다. 검색기가 1개뿐인 경우에는 융합이 수행되지 않고 일반 검색 결과가 반환됩니다.

경고

Fess 15.7 이전 버전에서 fess-webapp-semantic-search 플러그인을 사용하고 있었다면, 이 프로퍼티를 -Drank.fusion.searchers=default,semantic 으로 설정하라는 안내를 받았을 수 있습니다. 그 플러그인은 자신의 검색기를 semantic 이라는 이름으로 등록했는데, 이는 15.9에서 도입된 코어 통합 검색기의 이름인 semantic_chunk 와는 다른 검색기입니다. 이 15.7 시절의 설정을 그대로 15.9로 가져오면 허용 목록에 semantic_chunk 가 결코 포함되지 않으므로, 코어에 통합된 시맨틱 검색(콘텐츠 청킹 + 벡터 검색)은 전혀 동작하지 않습니다 — Fess는 아무런 표시 없이 일반 키워드 검색 결과만 계속 반환합니다(시작 시에는 경고 로그가 남지만, 요청별 제외 자체는 DEBUG 레벨로만 로그에 남습니다). 설정에 default,semantic 이 지정되어 있다면 이 설정을 제거하거나 semantic_chunk 를 추가하세요. 자세한 내용은 시맨틱 검색(콘텐츠 청킹 + 벡터 검색) 의 “15.7 이전 버전에서 업그레이드하는 경우의 마이그레이션”을 참조하세요.

검색 엔진 측에서의 Rank Fusion

rank.fusion.engine.enabled=true 를 설정하면 융합을 Fess가 아닌 OpenSearch가 수행합니다. 각 검색기의 쿼리를 하나의 검색 요청(hybrid 쿼리)으로 묶고, OpenSearch의 검색 파이프라인에서 스코어를 정규화·결합합니다. 한 번의 요청으로 융합하므로 총 히트 건수와 패싯 건수도 융합 후의 결과 집합을 나타냅니다.

이 기능에는 OpenSearch의 neural-search 플러그인이 필요합니다. 표준 배포판 OpenSearch와 ghcr.io/codelibs/fess-opensearch 이미지에는 포함되어 있지만, minimal 배포판에는 포함되어 있지 않습니다.

설정은 fess_config.properties 에 작성합니다(변경 사항을 반영하려면 Fess를 재시작해야 합니다):

rank.fusion.engine.enabled=true
rank.fusion.combination.technique=rrf
rank.fusion.normalization.technique=min_max
rank.fusion.combination.weights=
rank.fusion.pagination_depth=1000
프로퍼티 기본값 설명
rank.fusion.engine.enabled false true 로 설정하면 검색 엔진 측에서 융합합니다.
rank.fusion.combination.technique rrf 스코어 결합 방식. rrf, arithmetic_mean, geometric_mean, harmonic_mean 중 하나. rrf 의 상수 k 에는 rank.fusion.rank_constant 가 사용되며, Fess 측에서 융합하는 경우와 동일한 계산식이 됩니다.
rank.fusion.normalization.technique min_max 결합 전 스코어의 정규화 방식. min_max, l2, z_score 중 하나. rrf 에서는 사용되지 않습니다.
rank.fusion.combination.weights (비어 있음) 검색기별 가중치를 이름:가중치 의 쉼표 구분 형식으로 지정합니다(예: default:0.7,semantic_chunk:0.3). 각 가중치는 0.0~1.0 이어야 하고 합계가 1.0 이 되어야 하며, 융합에 참여하는 모든 검색기를 지정해야 합니다. 비어 있으면 균등하게 취급됩니다. 조건을 충족하지 않는 경우에는 ERROR 로그를 출력하고, 해당 검색은 Fess 측에서 융합됩니다.
rank.fusion.pagination_depth 1000 각 검색기가 샤드별로 융합에 제공하는 결과 건수. 페이징할 수 있는 깊이와 융합 대상이 되는 문서의 범위를 결정합니다. 검색 엔진 측에서 융합한 검색은 최대 이 건수까지 페이징할 수 있습니다. 검색 엔진에 보내는 값은 indexer.max.result.window.size 를 넘지 않습니다.

참고

z_score 정규화는 arithmetic_mean 과만 조합할 수 있습니다(neural-search 플러그인의 제약입니다). geometric_mean 또는 harmonic_mean 과 조합한 경우 Fess는 이 조합을 사용하지 않고, 두 설정 이름을 나타내는 ERROR 로그를 출력한 뒤 해당 검색을 Fess 측에서 융합합니다.

다음 경우에는 검색 엔진 측에서의 융합이 수행되지 않고 Fess 측에서의 융합으로 처리됩니다.

  • 상세 검색 파라미터(as.*)를 포함하는 검색

  • 정렬, 위치 정보 검색, 유사 문서 검색을 지정한 검색. 이들에서는 시맨틱 검색 자체가 건너뛰어지므로 키워드 검색만의 결과가 됩니다(시맨틱 검색(콘텐츠 청킹 + 벡터 검색) 참조).

  • rank.fusion.combination.weights 가 조건을 충족하지 않는 경우

  • z_score 정규화를 geometric_mean 또는 harmonic_mean 과 조합한 경우(두 설정 이름을 나타내는 ERROR 로그를 출력합니다)

  • OpenSearch가 융합 요청을 전혀 실행할 수 없는 경우(hybrid 쿼리나 검색 파이프라인의 프로세서를 인식하지 못하는 경우. neural-search 플러그인이 없거나 오래된 경우 등). 해당 검색마다 WARN 로그를 출력합니다. 다음 검색에서는 다시 OpenSearch에 융합을 요청하므로, 플러그인을 설치하거나 업데이트하면 Fess를 재시작하지 않아도 OpenSearch 측 융합으로 돌아갑니다.

그 밖의 이유로 융합 요청이 실패한 경우(잘못된 쿼리, 닫힌 인덱스, 샤드 장애 등)는 검색 엔진 측에서 융합하지 않는 경우와 마찬가지로 해당 검색에 한해 보고되며, 다음 검색은 다시 검색 엔진 측에서 융합됩니다.

검색 엔진 측에서 융합하는 경우의 주의 사항은 다음과 같습니다.

  • rank.fusion.timeout 은 적용되지 않습니다. 쿼리 임베딩은 검색 요청을 보내기 전에 동기적으로 계산되므로, 임베딩 프로바이더의 응답이 느리거나 응답하지 않는 경우에는 검색이 프로바이더 측의 타임아웃(예: content_chunker.embedding.ollama.timeout)까지 대기하게 됩니다. 프로바이더가 재시도하는 경우에는 그 횟수만큼도 더해집니다. 예를 들어 내장 opensearch 프로바이더는 content_chunker.embedding.opensearch.timeout(기본값 60000 밀리초)만큼의 대기를 content_chunker.embedding.opensearch.retry.max(기본값 3)회까지 반복하므로, 응답하지 않는 경우 기본값으로 180초에 재시도 사이의 대기 시간을 더한 시간이 걸릴 수 있습니다.

  • rank.fusion.window_size 와 rank.fusion.threads 는 Fess 측에서 융합하는 경우에만 사용됩니다.

  • 검색 엔진 측에서 융합한 검색은 최대 rank.fusion.pagination_depth 건까지 페이징할 수 있습니다. 검색 엔진은 각 검색기의 샤드별 상위 rank.fusion.pagination_depth 건만 융합하기 때문입니다. 페이지 수, 다음 페이지 여부, 페이지 번호는 이 건수에서 끝나며, 시작 위치 (start)가 rank.fusion.pagination_depth 이상인 페이지를 요청하면 다른 검색에서 index.max_result_window 를 넘는 페이지를 요청한 경우와 같은 오류(검색 API v2에서는 HTTP 400의 invalid_request)가 됩니다. 이 범위 안이라도 융합 결과의 마지막 건 이후에서 시작하는 페이지(오래된 링크 등)는 빈 페이지가 됩니다. 검색 엔진 측에서 융합하지 않는 검색은 지금까지와 마찬가지로 index.max_result_window 까지 페이징할 수 있습니다.

  • 총 히트 건수는 rank.fusion.pagination_depth 미만이면 정확합니다. 이 값 이상이 되면 검색 엔진이 실제로 일치하는 건수보다 적게 셀 수 있으므로 하한값으로 취급됩니다(검색 API의 record_count_relation 은 GREATER_THAN_OR_EQUAL_TO 가 됩니다).

  • rank.fusion.pagination_depth 를 크게 하면 더 깊은 페이지까지 볼 수 있지만, 융합하는 모든 검색이 검색기별·샤드별로 그 건수를 수집하므로 깊은 페이지뿐 아니라 모든 검색이 느려집니다.

  • 시맨틱 서처의 knn 쿼리의 k(샤드별 이웃 수)는 content_chunker.search.knn.k 입니다. 벡터 검색은 유사도가 낮은 문서도 이웃으로 반환하므로, content_chunker.search.min_score 를 설정하지 않은 경우 총 히트 건수에는 그만큼의 벡터 검색 히트가 더해지며, 소규모 인덱스에서는 열람할 수 있는 문서의 대부분이 건수에 포함될 수 있습니다. 건수를 줄이려면 content_chunker.search.min_score 를 설정하세요 (시맨틱 검색(콘텐츠 청킹 + 벡터 검색) 참조).

  • 검색 결과의 searcher 필드는 동일하게 부여되지만, rf_score 는 부여되지 않습니다.

하이브리드 검색과의 연계

Rank Fusion은 키워드 검색과 시맨틱 검색을 결합한 하이브리드 검색에서 특히 효과적입니다. 시맨틱 검색을 사용하려면 콘텐츠 청킹 기능을 설정한 뒤 content_chunker.search.enabled=true 를 설정하세요.

경고

content_chunker.enabled 나 content_chunker.search.enabled 등 content_chunker.* 설정은 fess_config.properties 가 아니라 시스템 프로퍼티입니다. conf/system.properties 에 작성하거나 -Dfess.system.content_chunker.search.enabled=true 와 같이 JVM 옵션으로 지정하세요. fess_config.properties 에 작성해도 반영되지 않습니다. 또한 content_chunker.search.enabled 는 시작 시에만 평가되므로 활성화한 뒤에는 Fess를 재시작해야 합니다.

자세한 내용은 시맨틱 검색(콘텐츠 청킹 + 벡터 검색) 을 참조하세요.

융합 결과 확인

Rank Fusion이 실제로 동작하고 있는지는 검색 결과에 부여되는 다음 두 가지 필드로 확인할 수 있습니다.

필드 내용
searcher 해당 문서를 가져온 검색기 이름의 배열(예: ["default", "semantic_chunk"]). 양쪽이 모두 포함되어 있으면 키워드 검색과 시맨틱 검색 양쪽에서 히트했다는 의미입니다.
rf_score RRF로 산출한 융합 후 스코어. 필드명은 rank.fusion.score_field 로 변경할 수 있습니다.

둘 다 검색 시 동적으로 부여되는 값이며 인덱스에는 저장되지 않습니다. 또한 기본적으로는 /api/v2/search 응답에 포함되지 않으므로, 확인하려면 fess_config.properties 에 다음을 설정하고 Fess를 재시작하세요:

query.additional.api.response.fields=rf_score,searcher

참고

query.additional.api.response.fields 는 v2 검색 API 응답에 포함해도 되는 필드의 허용 목록에 항목을 추가하는 설정입니다. role 이나 virtual_host 등 접근 제어용 필드를 추가하면 접근 제어 정보가 검색 API 응답에 노출되므로 추가하지 마세요.

히트 건수에 대한 영향

Fess 측에서 Rank Fusion이 실행되면 반환되는 총 히트 건수는 메인 검색기(맨 앞에 등록된 default 검색기)의 건수 그대로가 아니라 다음과 같이 보정됩니다:

총 히트 건수 = 메인 검색기의 총 히트 건수 + 보정값

보정값은 융합 후 상위 window_size ÷ 2 건 중에서 메인 검색기의 상위 window_size ÷ 2 건에 포함되어 있지 않았던 문서의 건수입니다. 즉, 시맨틱 검색만 찾아낸 문서의 수만큼 건수가 늘어납니다. 그래서 같은 쿼리라도 하이브리드 검색의 활성화 여부에 따라 히트 건수가 달라질 수 있습니다.

또한 메인 검색기의 총 히트 건수가 개략값(하한값)으로 반환되는 경우에는 이 보정이 수행되지 않습니다. 또한 패싯(레이블 등)의 건수는 메인 검색기의 검색 결과의 것이 그대로 사용됩니다.

검색 엔진 측에서 융합하는 경우(검색 엔진 측에서의 Rank Fusion 참조), 총 히트 건수와 패싯 건수는 키워드 검색과 시맨틱 검색 양쪽 히트의 합집합을 셉니다. 각 검색기가 샤드별로 제공하는 것은 최대 rank.fusion.pagination_depth 건이며, 시맨틱 검색기는 추가로 content_chunker.search.knn.k 건이 상한입니다. 그래서 같은 쿼리라도 rank.fusion.engine.enabled 를 전환하면 히트 건수도 패싯 건수도 달라지며, 소규모 인덱스에서는 시맨틱 검색의 히트가 더해지는 검색 엔진 측 융합 쪽이 더 커지기 쉽습니다.

사용 예

기본 하이브리드 검색

  1. 키워드 검색으로 BM25 스코어 계산

  2. 시맨틱 검색으로 벡터 유사도 계산

  3. RRF로 양쪽 결과를 융합

  4. 최종 랭킹 생성

검색 플로우:

User Query
    ↓
┌──────────────────┬──────────────────┐
│  Keyword Search  │ Semantic Search  │
│    (BM25)        │  (Vector)        │
└────────┬─────────┴────────┬─────────┘
         ↓                  ↓
     Rank List 1        Rank List 2
         └────────┬─────────┘
                  ↓
          Rank Fusion (RRF)
                  ↓
          Final Ranking

성능 고려 사항

메모리 사용량

  • 여러 검색 결과를 보유하므로 메모리 사용량이 증가합니다.

  • rank.fusion.window_size 로 융합 대상 최대 건수를 제한할 수 있습니다. 메인 검색기(맨 앞의 default 검색기)는 최대 window_size 건, 그 외의 검색기는 각각 window_size ÷ 검색기 수 건을 가져옵니다(검색기 수 는 메인 검색기를 포함한 총 개수이며, 나눗셈은 버림입니다).

  • 예를 들어 검색기가 2개(default 와 semantic_chunk)이고 window_size=200 인 경우, 메인 검색기가 200건, 시맨틱 서처가 100건을 가져오므로 보유되는 문서는 최대 300건이 됩니다.

# 융합 대상 윈도우 사이즈
rank.fusion.window_size=200

경고

rank.fusion.window_size 는 paging.search.page.max.size × 2 보다 작을 수 없습니다. paging.search.page.max.size 가 기본값 100 인 경우 하한은 200 이 되며, 이는 rank.fusion.window_size 의 기본값과 동일합니다. 즉 기본 구성에서는 window_size 를 기본값보다 작게 설정할 수 없습니다. 더 작은 값을 설정해도 시작 시 WARN 로그가 출력되고 200 으로 올려집니다. 실제로 더 작게 하려면 paging.search.page.max.size 를 먼저 낮춰야 하지만, 이렇게 하면 검색 화면이나 API에서 한 페이지에 요청할 수 있는 최대 건수도 함께 낮아집니다.

처리 시간

  • 여러 검색을 실행하므로 응답 시간이 증가합니다.

  • rank.fusion.threads 로 병렬 실행 스레드 수를 설정합니다.

# 병렬 실행 스레드 수 (0 이하인 경우 availableProcessors × 3 ÷ 2 + 1)
rank.fusion.threads=-1

참고

Fess 측에서 융합하는 경우, 메인 검색기 이외의 검색기는 rank.fusion.timeout(밀리초, 기본값 10000)까지 대기합니다. 그때까지 응답하지 않는 검색기는 해당 검색에서 제외되고, 검색 결과는 부분 결과(타임아웃)로 취급됩니다. 메인 검색기는 항상 완료될 때까지 대기합니다. 0 이하를 지정하면 무제한으로 대기합니다. 검색 엔진 측에서 융합하는 경우에는 이 설정이 적용되지 않습니다(검색 엔진 측에서의 Rank Fusion 참조).

검색기 장애 시 동작

검색기 중 하나가 예외로 실패한 경우, 해당 검색기의 결과는 비어 있는 것으로 처리되며 WARN 로그를 출력한 뒤 나머지 검색기의 결과만으로 융합이 계속 진행됩니다. 검색 요청 자체는 오류가 되지 않습니다.

다만 쿼리 구문 오류(InvalidQueryException)와 페이징 상한 초과 (ResultOffsetExceededException)는 예외이며, 이들은 그대로 오류로 반환됩니다. 또한 융합이 수행되지 않는 깊은 페이지(시작 위치 × 2 가 rank.fusion.window_size 이상이 되는 위치)에서는 메인 검색기에서 발생한 예외가 그대로 검색 요청의 오류가 됩니다.

시맨틱 서처는 임베딩 프로바이더에 연결할 수 없는 경우나 임베딩 처리에 실패한 경우 결과를 비어 있는 상태로 반환합니다. 이 경우에도 오류가 되지 않고 키워드 검색만의 결과가 됩니다.

문제 해결

검색 결과가 기대와 다름

증상: Rank Fusion 후 결과가 기대와 다름

확인 사항:

  1. searcher 필드를 확인합니다(“융합 결과 확인” 참조). 모든 문서가 ["default"] 만 포함하고 있다면 시맨틱 서처가 결과를 반환하지 않은 것입니다.

  2. 시맨틱 검색이 건너뛰어지지 않았는지 확인합니다. 구문이나 와일드카드 등의 검색 구문을 포함하는 쿼리 외에, 정렬, 위치 정보 검색, 유사 문서 검색에서는 시맨틱 서처가 결과를 반환하지 않고 키워드 검색만의 결과가 됩니다. 건너뛰는 조건에 대한 자세한 내용은 시맨틱 검색(콘텐츠 청킹 + 벡터 검색) 을 참조하세요.

  3. 각 검색 유형의 결과를 개별적으로 확인

  4. rank.fusion.rank_constant 값을 조정

  5. 깊은 페이지(시작 위치 × 2 가 rank.fusion.window_size 이상이 되는 위치. 기본값에서는 101번째 이후)에서는 융합이 수행되지 않고 메인 검색기만으로 검색됩니다. 더 많은 페이지에서 융합 결과를 사용하려면 rank.fusion.window_size 를 크게 늘려 주세요. 검색 엔진 측에서 융합하는 경우에는 이 경계가 없으며, 최대 rank.fusion.pagination_depth 건까지의 모든 페이지가 융합됩니다(검색 엔진 측에서의 Rank Fusion 참조).

검색이 느림

증상: Rank Fusion 활성화 시 검색이 느려짐

해결 방법:

  1. rank.fusion.threads 를 조정:

    rank.fusion.threads=4
    
  2. rank.fusion.window_size 를 줄이기. 다만 하한(paging.search.page.max.size × 2) 보다 작게 할 수 없으므로, 기본 구성에서는 다음 두 가지를 세트로 설정합니다:

    paging.search.page.max.size=50
    rank.fusion.window_size=100
    

    한 페이지에 요청할 수 있는 최대 건수도 함께 낮아진다는 점에 주의하세요. 설정 후에는 재시작이 필요합니다.

  3. 검색 엔진 측에서 융합하는 경우에는 rank.fusion.pagination_depth 를 줄이기. 융합 결과를 페이징할 수 있는 깊이도 함께 얕아진다는 점에 주의하세요. 설정 후에는 재시작이 필요합니다.

메모리 부족

증상: OutOfMemoryError 발생

해결 방법:

  1. “검색이 느림”과 동일한 절차로 rank.fusion.window_size 를 줄이기

  2. JVM 힙 크기 늘리기

참고 정보