왜 여러 개의 그래프를 사용해야 하나요? 이는 불변 세그먼트라는 루씬의 아키텍처 선택에 따른 부작용입니다. 대부분의 아키텍처 선택과 마찬가지로 장단점이 있습니다. 예를 들어, 저희는 최근에 서버리스 Elasticsearch를 정식 버전으로 출시했습니다. 이러한 맥락에서 우리는 효율적인 인덱스 복제, 인덱스와 쿼리 계산을 분리하고 독립적으로 자동 확장하는 기능 등 불변 세그먼트를 통해 매우 중요한 이점을 얻었습니다. 벡터 양자화의 경우 세그먼트 병합을 통해 데이터 특성에 맞게 파라미터를 업데이트할 수 있습니다. 이러한 맥락에서 데이터 특성을 측정하고 인덱싱 선택을 재검토할 수 있는 기회를 갖는다는 것은 다른 장점도 있다고 생각합니다.

이 글에서는 여러 개의 HNSW 그래프를 작성하는 데 드는 오버헤드를 크게 줄이고 특히 그래프를 병합하는 데 드는 비용을 줄이기 위해 수행한 작업에 대해 설명합니다.

배경

관리 가능한 세그먼트 수를 유지하기 위해 Lucene은 주기적으로 세그먼트를 병합해야 하는지 여부를 확인합니다. 이는 현재 세그먼트 수가 기본 세그먼트 크기와 병합 정책에 따라 결정되는 목표 세그먼트 수를 초과하는지 확인하는 것과 같습니다. 개수를 초과하면 제약 조건을 위반하는 동안 Lucene은 세그먼트 그룹을 병합합니다. 이 프로세스는 다른 곳에 자세히 설명되어 있습니다.

Lucene은 쓰기 증폭에서 대수적 증가를 달성하기 때문에 비슷한 크기의 세그먼트를 병합하는 방법을 선택합니다. 벡터 인덱스의 경우 쓰기 증폭은 벡터가 그래프에 삽입되는 횟수입니다. Lucene은 약 10개의 그룹으로 세그먼트를 병합하려고 시도합니다. 결과적으로 벡터는 대략 {10}\left (\frac{n}{n_0}\right )번 그래프에 삽입되며, 여기서 인덱스 벡터 수이고 예상되는 기본 세그먼트 벡터 수입니다. 대수적 증가로 인해 쓰기 증폭은 거대한 인덱스의 경우에도 한 자릿수입니다. 그러나 그래프를 병합하는 데 소요되는 총 시간은 쓰기 증폭에 선형적으로 비례합니다.

HNSW 그래프를 병합할 때 가장 큰 세그먼트의 그래프를 유지하고 다른 세그먼트의 벡터를 삽입하는 작은 최적화를 이미 수행했습니다. 이것이 위의 9/10 요소의 이유입니다. 아래에서는 병합하는 모든 그래프의 정보를 사용하여 훨씬 더 나은 결과를 얻을 수 있는 방법을 보여줍니다.

HNSW 그래프 병합

이전에는 가장 큰 그래프를 유지하고 벡터가 포함된 그래프를 무시하고 다른 그래프에서 벡터를 삽입했습니다. 아래에서 사용하는 핵심 인사이트는 우리가 폐기하는 각 HNSW 그래프에 포함된 벡터에 대한 중요한 근접성 정보가 포함되어 있다는 것입니다. 이 정보를 사용하여 적어도 일부 벡터의 삽입을 가속화하고자 합니다.

병합 정책을 구축하는 데 사용할 수 있는 원자 연산이므로 작은 그래프 )를 큰 그래프 )에 삽입하는 문제에 중점을 둡니다.

전략은 큰 그래프에 삽입할 정점 하위 집합을 찾는 것입니다. 그런 다음 작은 그래프에서 이러한 정점의 연결성을 사용하여 나머지 정점 삽입하는 속도를 높입니다. 아래에서는 작은 그래프와 큰 그래프에서 각각 및 를 사용하여 정점 이웃을 나타냅니다. 프로세스를 개략적으로 설명하면 다음과 같습니다.

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

아래에서 설명하는 절차를 사용하여 집합 계산합니다(1줄). 그런 다음 표준 HNSW 삽입 절차(2줄)를 사용하여 모든 정점을 큰 그래프에 삽입합니다. 삽입하지 않은 각 정점에 대해 삽입한 이웃 정점과 그 이웃 정점을 큰 그래프(4줄과 5줄)에서 찾습니다. 이 집합으로 시드된 FAST-SEARCH-LAYER 절차(6줄)를 사용하여 HNSW 논문 (7줄)에서 SELECT-NEIGHBORS-HEURISTIC 후보를 찾습니다. 사실상 SEARCH-LAYER 을 INSERT 방법(논문의 알고리즘 1)의 후보 집합을 찾는 것으로 대체하는 것이며, 그 외에는 변경 사항이 없습니다. 마지막으로 방금 삽입한 버텍스를 추가합니다(8행).

이 기능이 작동하려면 모든 버텍스에 이웃이 하나 이상 있어야 합니다. 실제로, 우리는 버텍스에 대해 최대 레이어 연결성인 일부 실제 HNSW 그래프에서는 정점 각도가 상당히 분산되어 있는 것을 관찰할 수 있습니다. 아래 그림은 Lucene HNSW 그래프의 최하위 레이어에 대한 일반적인 버텍스 도의 누적 밀도 함수를 보여줍니다.

고정값을 사용하는 방법과 버텍스 차수의 함수로 만드는 방법을 살펴봤습니다. 두 번째 선택은 그래프 품질에 미치는 영향을 최소화하면서 속도를 크게 향상시킬 수 있으므로 다음과 같이 선택했습니다.

정의상 |는 작은 그래프에서 정점 차수와 같다는 점에 유의하세요. 하한이 2라는 것은 차수가 2보다 작은 모든 정점을 삽입한다는 의미입니다.

간단한 계산 인수를 통해 신중하게 선택하면 직접 삽입하기만 하면 된다는 것을 알 수 있습니다. 구체적으로 그래프의 끝 꼭지점 중 하나를 정확히 삽입하면 그래프의 가장자리에 색을 입힙니다. 최소 이웃을 가지려면 에지를 채색해야 한다는 것을 알 수 있습니다. 또한 다음을 기대합니다.

여기서 _U\left [N_s(U)|\right] 는 작은 그래프에서 평균 버텍스 차수입니다. 각 정점 u에 대해 최대 의 가장자리를 색칠합니다. 따라서 채색할 에지의 총 개수는 최대 _U\left [|N_s(U)|\right]입니다. 신중하게 선택하면 이 수의 가장자리에 가깝게 색을 칠할 수 있으므로 모든 정점을 포함하려면 다음을 만족해야 합니다.

이는 {1}{4}|V_s|=\frac{1}{5}|V_s|를 의미합니다.

SEARCH-LAYER 이 런타임을 지배한다면 병합 시간을 최대 단축할 수 있음을 시사합니다. 쓰기 증폭의 대수적 증가를 감안할 때, 이는 매우 큰 인덱스의 경우에도 일반적으로 하나의 그래프를 작성할 때보다 빌드 시간이 두 배밖에 걸리지 않는다는 것을 의미합니다.

이 전략의 위험은 그래프 품질이 손상된다는 점입니다. 처음에는 노옵으로 시도했습니다 FAST-SEARCH-LAYER. 특히 단일 세그먼트로 병합할 때 지연 시간에 따른 리콜이 영향을 받을 정도로 그래프 품질이 저하되는 것으로 나타났습니다. 그런 다음 그래프를 제한적으로 검색하여 다양한 대안을 탐색했습니다. 결국 가장 효과적인 선택은 가장 단순한 것이었습니다. SEARCH-LAYER 을 사용하되 ef_construction. 이 매개변수화를 통해 우수한 품질의 그래프를 얻으면서도 병합 시간을 평균 30% 조금 넘게 줄일 수 있었습니다.

조인 집합 계산

좋은 조인 집합을 찾는 것은 HNSW 그래프 커버링 문제로 공식화할 수 있습니다. 욕심 휴리스틱은 최적의 그래프 커버를 근사화하기 위한 간단하고 효과적인 휴리스틱입니다. 우리가 취하는 접근 방식은 한 번에 하나씩 정점을 골라 이득이 감소하는 순서로 추가하는 방식입니다. 이득은 다음과 같이 정의됩니다:

여기서 는 벡터 개수를 나타내고 은 표시 함수입니다. 이득에는 추가한 버텍스 수의 변화, 즉 이 포함되는데, 이는 덜 커버되는 버텍스를 추가함으로써 목표에 더 가까워지기 때문입니다. 이득 계산은 아래 그림에서 중앙 주황색 버텍스에 대해 설명합니다.

각 버텍스 대해 다음과 같은 상태를 유지합니다:

1. 오래되었는지 여부,

2. 그 이득 ),

3. 인접한 정점의 개수를 로 표시합니다,

4. 타이 브레이킹에 사용되는 [0,1] 범위의 난수입니다.

조인 집합을 계산하는 의사 코드는 다음과 같습니다.

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

먼저 1~5줄에서 상태를 초기화합니다.

메인 루프의 각 반복에서 처음에는 최대 이득 버텍스(8번째 줄)를 추출하여 무작위로 동점을 끊습니다. 변경하기 전에 버텍스의 게인이 오래되었는지 확인해야 합니다. 특히, 버텍스를 추가할 때마다 다른 버텍스의 이득에 영향을 미칩니다:

1. 모든 이웃이 추가 이웃을 가지고 있기 때문에 이득이 바뀔 수 있습니다 (14행).

2. 이제 이웃이 완전히 커버되면 모든 이웃의 이득이 바뀔 수 있습니다(14~16줄).

게인을 지연 방식으로 다시 계산하므로 버텍스의 게인을 삽입하려는 경우에만 다시 계산합니다(18~20행). 이득은 항상 감소하기 때문에 삽입해야 하는 버텍스를 놓칠 수 없습니다.

종료 시점을 결정하기 위해 추가한 버텍스의 총 이득을 추적하기만 하면 됩니다. 또한, {exit}적어도 하나의 버텍스는 0이 아닌 이득을 가지므로 항상 진전이 있습니다.

결과

지원되는 세 가지 거리 메트릭(유클리드, 코사인, 내적 곱)을 모두 포함하는 네 가지 데이터 세트에 대해 실험을 진행했습니다:

1. 쿼라-E5-small: 522931개 문서, 384개 차원, 코사인 유사도를 사용합니다,

2. 코히어-위키백과-v2: 1백만 개의 문서, 768개의 차원, 코사인 유사도를 사용합니다,

3. 요점 1백만 문서, 960개 차원, 유클리드 거리 사용, 그리고

4. 코히어-위키백과-v3: 1M 문서, 1024 크기, 최대 내부 제품 사용.

각 데이터 세트에 대해 두 가지 양자화 수준을 평가합니다:

1. int8 - 차원당 1바이트 정수를 사용하고

2. BBQ - 차원당 단일 비트를 사용합니다.

마지막으로, 각 실험에서 두 가지 검색 깊이에서 검색 품질을 평가하고 인덱스를 구축한 후와 단일 세그먼트로 강제 병합한 후를 조사했습니다.

요약하면, 모든 경우에서 그래프 품질을 유지하면서 인덱싱 및 병합 속도를 일관되게 크게 향상시켜 검색 성능을 향상시켰습니다.

실험 1: int8 정량화

베이스라인에서 제안된 변경 사항인 후보까지의 평균 속도 향상은 다음과 같습니다:

색인 시간 속도 향상: 1.

강제 병합 속도 향상: 1.

이는 다음과 같은 실행 시간 분석에 해당합니다.

정확성을 위해 정확한 시간은 다음과 같습니다.

색인

병합

데이터 세트

기준선

후보

구축

후보

쿼라-E5-small

112.41s

81.55s

113.81s

70.87s

위키-코히어-v2

158.1s

122.95s

425.20s

239.28s

요점

141.82s

119.26s

536.07s

279.05s

위키-코히어-v3

211.86s

168.22s

654.97s

414.12s

아래에는 여러 세그먼트가 있는 인덱스(모든 벡터를 인덱싱한 후 기본 병합 전략의 최종 결과)와 단일 세그먼트로 강제 병합한 후의 두 가지 검색 깊이인 recall@10과 recall@100에서 후보(점선)와 기준선을 비교한 리콜 대 지연 시간 그래프가 나와 있습니다. 곡선이 더 높고 왼쪽으로 갈수록 더 좋은데, 이는 더 낮은 지연 시간에서 더 높은 회상률을 의미합니다.

보시다시피, 여러 세그먼트 인덱스의 경우 Cohere v3 데이터 세트의 후보가 더 우수하고 다른 모든 데이터 세트의 경우 약간 떨어지지만 거의 비슷합니다. 단일 세그먼트로 병합한 후 리콜 곡선은 모든 경우에 대해 거의 동일합니다.

실험 2: BBQ 정량화

기준선에서 후보까지의 평균 속도 향상은 다음과 같습니다:

색인 시간 속도 향상: 1.

강제 병합 속도 향상: 1.

이는 다음과 같은 실행 시간 분석에 해당합니다.

정확성을 위해 정확한 시간은 다음과 같습니다.

색인

병합

데이터 세트

기준선

후보

구축

후보

쿼라-E5-small

70.71s

58.25s

59.38s

40.15s

위키-코히어-v2

203.08s

142.27s

107.27s

85.68s

요점

110.35s

105.52s

323.66s

202.2s

위키-코히어-v3

313.43s

190.63s

165.98s

159.95s

여러 세그먼트 인덱스의 경우, 기준선이 약간 더 나은 코히어 v2를 제외한 거의 모든 데이터 세트에서 후보가 더 우수합니다. 단일 세그먼트 인덱스의 경우 리콜 곡선은 모든 경우에 대해 거의 동일합니다.

결론

이 블로그에서 설명한 알고리즘은 곧 출시될 Lucene 10.2와 이를 기반으로 하는 Elasticsearch 릴리즈에서 사용할 수 있습니다. 사용자는 이 새 버전에서 병합 성능이 향상되고 인덱스 빌드 시간이 단축되는 이점을 누릴 수 있습니다. 이 변경은 벡터 및 하이브리드 검색을 위한 빠르고 효율적인 Lucene과 Elasticsearch를 만들기 위한 지속적인 노력의 일환입니다.

검색 관련성 평가에서 BEIR 벤치마크 이해하기

어떤 시스템이든, 개선하려면 현재 성능을 얼마나 잘 내고 있는지를 측정할 수 있어야 합니다. 검색의 맥락에서 BEIR(또는 동등하게 MTEB 리더보드의 검색 섹션)은 정보 검색 커뮤니티에서 "성배"로 여겨지며, 이는 전혀 놀라운 일이 아닙니다. 서로 다른 작업 전반에 걸쳐 다양한 데이터 세트를 포함한, 매우 잘 구조화된 벤치마크입니다. 더 구체적으로 말하자면, 다음과 같은 영역을 다룹니다.

• 논증 검색(ArguAna, Touche2020)

• 오픈 도메인 QA(HotpotQA, Natural Questions, FiQA)

• 구절 검색(MSMARCO)

• 중복 질문 검색(Quora, CQADupstack)

• 사실 확인(FEVER, Climate-FEVER, Scifact)

• 생의학 정보 검색(TREC-COVID, NFCorpus, BioASQ)

• 엔티티 검색(DBPedia)

• 인용 예측(SCIDOCS)

단일 통계치인 nDCG@10을 제공하며, 이는 각 작업 예시에 대해 시스템이 반환한 상위 결과에서 가장 관련성 높은 문서들을 얼마나 잘 매칭하는지를 나타냅니다. 사용자가 상위 결과의 정확도와 직접 상호작용하는 검색 시스템에서는 이러한 지표가 매우 중요합니다. 하지만 검색을 평가할 때는 단일 요약 통계로는 포착하기 어려운 미묘한 차이가 많습니다.

BEIR 데이터 세트의 구조

각 벤치마크는 세 가지 구성 요소로 이루어져 있습니다.

• 검색 대상이 될 코퍼스 또는 문서

• 쿼리

• 쿼리에 대한 관련성 판단 값(일명 qrels)

정확도 판단 값은 0점 이상의 점수로 제공됩니다. 점수가 0이 아니라면 문서가 쿼리와 어느 정도 관련이 있음을 나타냅니다.

데이터 세트

코퍼스 크기

테스트 세트의 쿼리 수

#qrels에 긍정적으로 레이블이 지정됨

정확도 판단 값이 0인 항목 수

코퍼스 내 중복 항목 수

Arguana

8,674

1,406

1,406

0

96

Climate-FEVER

5,416,593

1,535

4,681

0

0

DBPedia

4,635,922

400

15,286

28,229

0

FEVER

5,416,568

6,666

7,937

0

0

FiQA-2018

57,638

648

1,706

0

0

HotpotQA

5,233,329

7,405

14,810

0

0

Natural Questions

2,681,468

3,452

4,021

0

16,781

NFCorpus

3,633

323

12,334

0

80

Quora

522,931

10,000

15,675

0

1,092

SCIDOCS

25,657

1,000

4,928

25,000

2

Scifact

5,183

300

339

0

0

Touche2020

382,545

49

932

1,982

5,357

TREC-COVID

171,332

50

24,763

41,663

0

MSMARCO

8,841,823

6,980

7,437

0

324

CQADupstack(합계)

457,199

13,145

23,703

0

0

표 1: 데이터 세트 통계 수치는 각 데이터 세트의 구간을 기준으로 산출되었습니다(dev 대상: MSMARCO).

표 1은 코퍼스의 문서 수, 테스트 데이터 세트의 쿼리 수, qrels 파일의 긍정/부정(쿼리, 문서) 쌍의 수와 같은, BEIR 벤치마크를 구성하는 데이터 세트에 대한 몇 가지 통계를 제시합니다. 데이터를 간단히 살펴보면 다음과 같은 사실을 즉시 추론할 수 있습니다.

• 대부분의 데이터 세트는 qrels 파일에 부정 관계가 포함되어 있지 않습니다. 즉, 주어진 쿼리와 무관함을 명시적으로 나타내는 0점 항목이 없다는 의미입니다.

• 쿼리당 문서 관계의 평균 수(#qrels / #queries)는 ArguAna의 경우 1.0에서 TREC-COVID의 경우 493.5까지 다양하며, 대부분의 경우 <5 미만의 값을 가집니다.

• 일부 데이터 세트는 코퍼스 내에 중복 문서가 포함되어 있어, 경우에 따라 잘못된 평가로 이어질 수 있습니다. 즉 하나의 문서가 쿼리에 대해 관련성이 있다고 판단되지만, 동일한 중복 문서는 그렇지 않게 처리되는 경우입니다. 예를 들어 ArguAna의 경우, 한 쿼리에 대해 문서 쌍 중 한 문서만 관련성이 있는 것으로 표시된 중복 문서 쌍을 96건 확인했습니다. 초기 qrels 목록을 중복 항목까지 포함하도록 '확장'했을 경우 평균적으로 nDCG@10 점수가 약 1% 상대적으로 증가하는 것을 확인했습니다.

ArguAna에서 중복된 쌍의 예시입니다. qrels 파일에서는 첫 번째 항목만이 쿼리(“test-economy-epiasghbf-pro02a”)에 대해 (반론으로서) 관련성이 있는 것으로 표시되어 있습니다.

MTEB 리더보드에서 모델을 비교할 때는 평균 검색 품질에 집중하고 싶은 유혹이 생기기 쉽습니다. 이는 모델의 전반적인 품질을 나타내는 좋은 지표이지만, 실제로 여러분의 사용 사례에서 어떻게 성능을 낼지는 반드시 알려주지는 않습니다. 결과는 데이터 세트별로 보고되므로, 서로 다른 데이터 세트가 검색 작업과 얼마나 밀접하게 관련되어 있는지 파악하고 가장 관련성이 높은 데이터 세트만 사용하여 모델의 점수를 재조정하는 것이 좋습니다. 더 자세히 살펴보고 싶다면, 다양한 데이터 세트 코퍼스 간의 주제 중복 여부도 추가로 확인해볼 수 있습니다. 품질 측정값을 주제 기준으로 나누어 분석하면, 특정 강점과 약점에 대한 훨씬 더 세밀한 평가가 가능합니다.

여기서 중요한 점은 문서가 qrels 파일에 표시되지 않으면 기본적으로 쿼리와 무관하다고 간주된다는 것입니다. 이 부분을 조금 더 깊이 파고들어, 다음 질문을 보다 명확히 하기 위한 몇 가지 근거를 수집합니다. “평가자가 기준 정답 정보가 없는 (쿼리, 문서) 쌍을 접하는 경우는 얼마나 자주 발생하는가?” 이 점이 중요한 이유는, 얕은 마크업만 존재하는 경우(즉, 모든 관련 문서가 라벨링되어 있지 않은 경우) 정보 검색 시스템이 단지 서로 다른 관련 문서(하지만 표시되지 않은 문서)를 노출한다는 이유만으로 다른 시스템보다 성능이 낮게 평가될 수 있기 때문입니다. 이는 특히 대규모 데이터 세트의 경우, 고품질 평가 세트를 만들 때 흔히 발생하는 문제점입니다. 실행 가능한 수동 라벨링은 일반적으로 현재 시스템에서 반환된 상위 결과에 초점을 맞추므로, 그 시스템의 사각지대에 있는 관련 문서들을 놓칠 가능성이 큽니다. 따라서 광범위하지만 얕은 마크업을 적용하기보다는, 더 적은 수의 쿼리에 대해 보다 충실한 마크업에 리소스를 집중하는 편이 일반적으로 더 바람직합니다.

검색 정확도 평가에 BEIR 벤치마크 활용하기

분석을 시작하기 위해 다음의 시나리오를 구현합니다(노트북 참조).

1. 먼저, 각 데이터 세트의 코퍼스를 Elasticsearch 인덱스에 로드합니다.

2. 테스트 세트의 각 쿼리에 대해 BM25를 사용해 상위 100개의 문서를 검색합니다.

3. 검색된 문서들은 최신 성능의 다양한 순위 재지정 모델을 사용해 다시 정렬합니다.

4. 마지막으로, 2단계(검색 후)와 3단계(재순위화 후)에서 도출된 상위 10개 문서에 대한 '심사 비율'을 보고합니다. 즉, qrels 파일에서 점수가 부여된 상위 10개 문서의 평균 비율을 계산합니다.

이번에 사용한 모델 순위 재지정 목록은 다음과 같습니다.

• Cohere의 rerank-english-v2.0 및 rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

검색

순위 재지정

데이터 세트

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7.54

4.87

7.87

4.52

4.53

6.84

Climate-FEVER

5.75

6.24

8.15

9.36

7.79

7.58

DBPedia

61.18

60.78

64.15

63.9

63.5

67.62

FEVER

8.89

9.97

10.08

10.19

9.88

9.88

FiQA-2018

7.02

11.02

10.77

8.43

9.1

9.44

HotpotQA

12.59

14.5

14.76

15.1

14.02

14.42

Natural Questions

5.94

8.84

8.71

8.37

8.14

8.34

NFCorpus

31.67

32.9

33.91

30.63

32.77

32.45

Quora

12.2

10.46

13.04

11.26

12.58

12.78

SCIDOCS

8.62

9.41

9.71

8.04

8.79

8.52

Scifact

9.07

9.57

9.77

9.3

9.1

9.17

Touche2020

38.78

30.41

32.24

33.06

37.96

33.67

TREC-COVID

92.4

98.4

98.2

93.8

99.6

97.4

MSMARCO

3.97

6.00

6.03

6.07

5.47

6.11

CQADupstack (avg.)

5.47

6.32

6.87

5.89

6.22

6.16

표 2: 검색·재순위화된 상위 10개 문서를 기준으로 (데이터 세트, 재순위화 모델) 조합별 심사 비율 계산

표 2를 보면 TREC-COVID(90% 이상 커버리지), DBPedia(~65%), Touche2020, nfcorpus(~35%)를 제외한 대부분의 데이터 세트는 검색 또는 재순위화 이후의 라벨링 비율이 5%에서 10%를 조금 넘는 수준에 불과함을 알 수 있습니다. 이는 표시되지 않은 문서들이 모두 관련 문서라는 뜻은 아니지만, 그중 일부는 특히 상위 순위에 위치한 경우 긍정적인, 즉 관련성 있는 문서일 가능성이 있다는 점을 시사합니다.

범용 목적의 지시 튜닝 언어 모델의 등장으로, 관련성 판단을 자동화할 잠재력을 지닌 새롭고 강력한 도구를 갖게 되었습니다. 이러한 방법들은 일반적으로 계산 비용이 너무 커서 실제 온라인 검색에 사용하기는 어렵지만, 여기서는 오프라인 평가에 초점을 맞추고 있습니다. 다음에서는 이를 활용해 일부 BEIR 데이터 세트가 얕은 마크업 문제를 겪고 있다는 증거를 살펴봅니다.

이 가설을 더 자세히 검증하기 위해 MSMARCO에 초점을 맞추고, 현재 관련 문서로 표시되지 문서 중 Cohere v2로 재순위화된 상위 5개 문서를 포함해 100개의 쿼리 하위 집합을 선택했습니다. 평가는 두 가지 서로 다른 경로로 진행했습니다. 첫째, 신중하게 조정된 프롬프트(자세한 내용은 나중에 다룰 예정)를 사용해 최근 공개된 Phi-3-mini-4k 모델이 특정 문서가 해당 쿼리와 관련이 있는지(또는 없는지)를 예측하도록 했습니다. 이와 동시에, LLM 출력과 사람의 판단 간의 일치율을 평가하기 위해 이러한 사례들에 대해 수동으로 라벨링을 하는 작업도 진행했습니다. 전반적으로, 다음과 같은 두 가지 결론을 도출할 수 있습니다.

• LLM 응답과 인간의 판단 간의 일치율은 약 80%였으며, 이는 해당 방향으로 나아가기 위한 출발점으로 보기에 충분히 좋은 수치입니다.

• 인간 판단을 기준으로 했을 때, 전체 사례의 57.6%에서 반환된 문서들이 실제로 쿼리와 관련이 있는 것으로 확인되었습니다. 이를 다른 방식으로 표현하면, 100개의 쿼리에 대해 관련 문서로 판단된 문서는 107개였지만, 실제로는 최소 0.576 × 5 × 100 = 288개의 추가 문서가 쿼리와 관련이 있다는 의미입니다!

다음은 MSMARCO/dev 데이터 세트에서 가져온 몇 가지 예시입니다. 여기에는 쿼리, 주석이 달린 긍정 문서(qrels에 포함된 문서), 그리고 마크업이 불완전해 발생한 거짓 음성 문서가 함께 포함되어 있습니다.

예 1:

예 2:

이처럼 특정 쿼리를 수동으로 평가하는 방식은 nDCG@10과 같은 정량적 지표를 보완하면서 검색 품질을 이해하는 데 전반적으로 유용한 기법입니다. 검색 변경 시 항상 실행하는 대표적인 쿼리 집합이 있다면, 통계에서는 보이지 않는 성능 변화에 대한 중요한 정성적 정보를 얻을 수 있습니다. 예를 들어, 검색 결과에 포함된 잘못된 결과들에 대해 훨씬 더 많은 인사이트를 제공합니다. 검색 시스템이 반환한 결과 중 명백한 오류를 찾아내거나, 도메인 특화 용어를 잘못 해석하는 등 서로 연관된 오류 유형을 파악하는 데 도움이 됩니다.

이 결과는 MSMARCO 평가에 관한 관련 연구와 일치합니다. 예를 들어, Arabzadeh 외 연구진은 크라우드소싱 작업자를 활용해 선호도 판단을 수행하는 유사한 절차를 따르며, 여러 결과 중에서도 재순위화 모듈이 반환한 문서가 MSMARCO qrels 파일에 포함된 문서보다 많은 경우 선호된다는 점을 보여줍니다. 또 다른 근거는 RocketQA 재순위화 모델의 저자들이 제시한 결과에서 확인할 수 있는데, 수작업 검토 후 재순위화된 문서의 70% 이상이 관련 문서로 판명되었다고 보고하고 있습니다.

업데이트 - 9월 9일: 데이터 세트를 면밀히 재평가한 결과, 관련 문서가 15건 더 확인되어 총 273건에서 288건으로 증가했습니다.

주요 요점 및 향후 계획

• 더 나은 기준 데이터를 위한 추구는 끝이 없습니다. 이는 벤치마킹과 모델 비교에 매우 중요하기 때문입니다. LLM은 주의 깊게 사용하고 적절한 지시로 튜닝한다면 일부 평가 영역에서 도움을 줄 수 있습니다.

• 더 일반적으로 말하면, 벤치마크가 완벽할 수는 없기 때문에 단순한 점수 비교에서 벗어나, 통계적으로 유의미한 차이를 포착할 수 있는 보다 견고한 기법으로 전환하는 편이 바람직할 수 있습니다. Arabzadeh 외 연구진의 작업은 이러한 접근의 좋은 예를 제공하는데, 이들은 연구 결과를 바탕으로 여러 실험 실행 간의 차이가 유의미한지 여부를 보여주는 95% 신뢰구간을 구축했습니다. 함께 제공된 노트북에서는 부트스트래핑을 사용해 신뢰구간을 계산하는 구현 예시도 제시합니다.

• 최종 사용자 관점에서는, 벤치마크 결과를 해석할 때 작업 정합성을 함께 고려하는 것이 유용합니다. 예를 들어, RAG 파이프라인을 구축하는 AI 엔지니어라면 일반적인 사용 사례가 서로 다른 출처의 여러 정보를 조합하는 것임을 알고 있을 것입니다. 이런 경우에는 BEIR 전체 벤치마크의 전역 평균 성능을 보는 것보다, HotpotQA와 같은 멀티홉 QA 데이터 세트에서 검색 모델의 성능을 평가하는 편이 훨씬 더 의미가 있습니다.

다음 블로그 게시물에서는 Phi-3를 LLM 판정자로 사용하는 방법과, 관련성을 예측하도록 이를 튜닝해 나간 과정을 보다 깊이 있게 다룹니다.