기업은 고객 지원 티켓, 법률 문서, 뉴스 피드, 연구 논문 등 방대한 양의 문서를 축적하며, 올바른 질문을 던지기 위해서는 먼저 그 문서에 어떤 내용이 담겨 있는지 정확히 파악해야 합니다 레이블이나 학습 데이터가 없는 상태에서 수천 건의 문서를 수동으로 검토하는 것은 현실적으로 불가능합니다. 무엇을 검색해야 할지 모를 때는 기존 검색 방식이 도움이 되지 않습니다.

이 게시물에서는 이러한 탐색 문제를 해결하는 Elasticsearch 기반의 비지도형 문서 클러스터링 및 시간적 스토리 추적 방식을 안내합니다. 이 과정을 마치고 나면, 여러 날에 걸쳐 전개되는 스토리의 흐름을 다음과 같이 추적할 수 있습니다.

다룰 내용:

• 쿼리 없이 주제를 탐색할 때, (검색용 임베딩이 아닌) 클러스터링 임베딩을 사용하는 것이 왜 중요한가요?

• Elasticsearch의 k-최근접 이웃(kNN)과 배치(Batched) msearch을(를) 활용하여, 밀도 조사 중심 분류 방식이 문서를 주제별로 그룹화하는 방법.

• 모델 학습 없이도 주제를 파악할 수 있도록, significant_text이(가) 클러스터에 자동 레이블 지정을 수행하는 방법.

• 시간적 스토리 체인이 일별 클러스터를 연결하여, 주제가 매일 어떻게 진화하는지를 보여 줍니다.

이 파이프라인은 BBC 뉴스 및 The Guardian에서 제공하는 2025년 2월 기사 약 8,500개를 테스트 코퍼스로 사용합니다. 뉴스는 시간적 흐름이 명확하기 때문에 활용하기 편리하지만, 이러한 패턴은 법률 검토, 규정 준수 모니터링, 연구 종합, 고객 지원 분류 등 문서 탐색이 중요한 모든 곳에 적용될 수 있습니다.

스택:

• Jina v5 클러스터링 임베딩: 주제 그룹화를 위한 작업별 LoRA(Low-Rank Adaptation) 어댑터. Jina가 Elastic과 함께하게 되었습니다. Elastic Inference Service(EIS)에서 Jina 모델을 네이티브로 사용할 수 있습니다.

• Elasticsearch: 확장 가능한 kNN, significant_text 레이블 지정, 및 벡터 스토리지.

• DiskBBQ: 근사 최근접 이웃(ANN) 검색 가속화를 위해 더 나은 이진 양자화(BBQ)와 계층적 K-평균 분할을 결합한 디스크 기반 벡터 인덱스 포맷입니다. 이 인덱스 분할은 벡터 검색 내부에서 이루어지며, 이 게시물에서 사용된 밀도 조사 클러스터링 알고리즘과는 별개입니다. bbq_disk은(는) 양자화된 벡터를 디스크에 저장하고 힙(Heap)에는 분할 메타데이터만 유지합니다. 덕분에 bbq_hnsw과(와) 비교했을 때 높은 재현율을 유지하면서도 리소스 요구 사양을 획기적으로 낮출 수 있습니다.

• 전역 클러스터링 + 일별 시간적 연결: 탐색 및 스토리 진화.

준비 사항:

• Elasticsearch 배포(Elastic Cloud, Elasticsearch Serverless 또는 Elastic Self-Managed 8.18+/9.0+) bbq_disk 을(를) 사용하려면 8.18 이상이 필요합니다. 선택 사항인 다양성 기반 검색기 섹션은 9.3 이상 또는 서버리스가 필요합니다.

• Jina API 키Jina API 키: 무료 티어에는 1,000만 토큰이 포함되어 있으며, 이는 핵심 클러스터링 파이프라인(약 425만 토큰)을 감당할 수 있습니다. 선택 사항인 검색과 클러스터링 비교에는 두 번째 임베딩 패스를 사용합니다.

• Guardian API 키 (무료).

설정

필요한 패키지 설치:

선택 사항(이 리포지토리에서 스크래핑 도우미를 실행하는 경우에만):

그런 다음 프로젝트 루트에 있는 .env 파일에 API 키를 구성하세요.

이 노트북은 load_dotenv(override=True)을(를) 호출하므로, 로컬 .env 값이 우선적으로 적용됩니다.

1부: 탐색 클러스터링 - 왜 임베딩을 클러스터링해야 할까요?

대부분의 벡터 검색은 쿼리와 관련 문서 간의 일치 여부를 판단하도록 학습된 검색용 임베딩을 사용합니다. 검색에는 완벽하지만, 탐색에는 적합하지 않습니다. 쿼리 없이도 코퍼스에 어떤 주제가 존재하는지 찾으려면 유사한 문서를 함께 그룹화하는 임베딩이 필요합니다.

Jina v5는 작업별 LoRA(Low-Rank Adaptation) 어댑터를 통해 이 문제를 해결합니다. LoRA는 모델의 기본 가중치 대부분을 고정한 채, 대상 내부 레이어에 소규모의 저순위 업데이트를 추가합니다. 이를 통해 모델 전체를 재학습시키지 않고도 특정 작업에 맞춰 모델의 동작을 변화시킬 수 있습니다. 동일한 기본 모델이라도 task 매개변수 설정에 따라 서로 다른 임베딩을 생성합니다.

작업

학습 용도

사용 사례

retrieval.passage

쿼리-문서 일치

검색, Retrieval-Augmented Generation(RAG)

클러스터링

주제 그룹화(긴밀한 클러스터에 최적화됨)

탐색, 분류

클러스터링 어댑터는 동일한 주제의 문서들은 임베딩 공간에서 더 가깝게, 서로 다른 주제의 문서들은 더 멀리 배치되도록 학습되었습니다. 아래의 시각적 비교 자료를 통해 그 차이를 명확히 확인할 수 있습니다.

검색과 클러스터링: 시각적 비교

그 차이를 확인하기 위해, 두 가지 작업 유형을 각각 모두 적용하여 문서 샘플을 임베딩했습니다. 클러스터링은 원본 데이터인 1024차원의 임베딩 공간에서 수행됩니다. UMAP(Uniform Manifold Approximation and Projection)은 시각화를 위해 이러한 임베딩을 2차원으로 투영하는 용도로만 사용됩니다. UMAP은 데이터의 지역적 이웃 구조를 보존하므로, 클러스터 간의 분리를 비교하는 데 유용합니다.

아래는 동일한 480개의 문서 샘플에 두 가지 작업 유형을 각각 모두 적용하여 임베딩한 후, UMAP을 통해 2차원으로 투영한 결과입니다. 클러스터링 패널에서 더 긴밀하고, 더 명확히 분리된 색상 그룹을 찾습니다.

검색용 임베딩(왼쪽)은 주제를 넓게 퍼뜨리는 반면, 클러스터링용 임베딩(오른쪽)은 동일한 문서에서도 더 긴밀하고 명확하게 구분된 그룹을 형성합니다.

클러스터링 임베딩은 더 긴밀하고 시각적으로도 훨씬 뚜렷하게 구별되는 그룹을 생성합니다. 검색 임베딩은 주제를 더 고르게 분산시켜 검색(세밀한 유사도)에 이상적이지만, 탐색의 경우 긴밀한 주제별 클러스터가 중요합니다.

이것이 바로 본 단계별 안내 나머지 과정에서 task="clustering"을(를) 사용하는 이유입니다.

데이터셋 로딩

코퍼스는 2025년 2월의 두 뉴스 소스를 결합합니다.

• BBC 뉴스: RealTimeData/bbc_news_alltime HuggingFace 데이터셋 활용.

• The Guardian: Guardian Open Platform API활용.

여러 소스의 데이터를 사용하면, 클러스터링이 소스만의 특정 스타일이 아닌 주제를 제대로 찾아내는지 검증하는 데 도움이 됩니다.

클러스터링 작업을 통한 임베딩

모든 문서에 대해 Jina v5 API는 task="clustering" (으)로 호출됩니다. 임베딩은 디스크에 캐시되므로 이후 실행에서는 API를 완전히 건너뜁니다.

API 호출은 간단합니다. task 매개변수는 일반적인 임베딩 사용 방식과 구분되는 가장 핵심적인 차이점입니다.

아래 실행 시간은 캐시 적중이 적용되었습니다. API를 처음 실행할 때 걸리는 시간은 코퍼스 크기에 따라 달라집니다.

단일 Elasticsearch 인덱스로 색인

탐색 클러스터링을 위해, 한 달 전체 데이터를 하나의 인덱스(docs-clustering-all)에 저장합니다. 일일 분할은 시간적 스토리 연결을 위해 나중에 이루어집니다.

인덱스 매핑 시 벡터 필드에 bbq_disk (을)를 사용합니다.

1024차원의 float32 벡터는 용량이 4KB입니다. bbq_disk(은)는 계층적 K-평균을 사용하여 벡터를 작은 클러스터로 나누고, 이를 이진 양자화하여 저장한 뒤, 재계산을 위해 전체 정밀도 벡터를 디스크에 보관합니다. 오직 분할 메타데이터만 힙에 상주하므로, 방대한 코퍼스를 처리할 때도 메모리 사용량을 낮게 유지할 수 있습니다. 더 많은 힙을 감당할 수 있는 워크로드의 경우, bbq_hnsw(은)는 리소스 비용이 더 높지만 더 빠른 검색이 가능한 계층적으로 탐색 가능 작은 세계(HNSW) 그래프를 생성합니다.

dense_vector 필드 타입은 다양한 양자화 전략을 지원합니다. 여기서 사용된 1024차원 벡터와 같은 고차원 임베딩에는 bbq_disk 및 bbq_hnsw 방식이 가장 적합합니다.

클러스터링: 밀도 조사 중심 분류

HDBSCAN과 같은 전통적인 클러스터링 알고리즘은 N×d 크기의 전체 벡터 행렬을 메모리에 올려 둘 수 있고, 전체 데이터를 반복적으로 훑으며 업데이트를 수행할 수 있다는 가정하에 작동합니다. 1,024차원의 문서 8,495개라면 충분히 감당할 수 있는 크기(35MB 수준)입니다. 하지만 추가적인 인프라 없이는 수백만 건의 문서로 확장하기 어려운 접근 방식입니다.

이 알고리즘은 개념적으로 Voronoi 할당과 노이즈 플로어를 사용하는 KMeans++ 초기화 방식과 유사하지만, Elasticsearch kNN 검색을 연산 프리미티브로 사용하여 거의 모든 작업을 서버 측에서 처리합니다.

1. 전체 문서의 5%를 밀도 조사용으로 샘플링합니다(무작위 샘플, 최소 50개).

2. 배치 처리된msearch kNN을 통해 밀도를 조사합니다. 각 조사 지점에서 kNN 쿼리를 실행해 주변의 평균 유사도를 기록합니다. 높은 평균 유사도는 임베딩 공간의 밀집 영역을 의미합니다. msearch(은)는 단일 HTTP 호출로 여러 검색 요청을 보낼 수 있는데, 이 기능이 여기서 매우 중요합니다. 밀도 조사 과정에서 수백 개의 kNN 쿼리가 생성되는데, 이를 배치로 처리함으로써 요청당 발생하는 오버헤드를 방지할 수 있기 때문입니다.

3. 다양성을 갖춘 고밀도 시드 선택: 밀도 중앙값 이상의 후보들을 밀도 내림차순으로 정렬한 뒤, 모든 기존 시드와의 코사인 유사도가 분리 임계값보다 낮은 경우에만 탐욕적으로 채택합니다. 이것이 유일한 클라이언트 측 연산입니다.(문서 8,000개 기준 약 0.01초 소요)

4. msearch  kNN을 통해 모든 문서를 중심 기준으로 분류: 각 시드가 중심 역할을 수행하며, kNN 검색을 통해 유사도 임계값 이상의 인접 문서를 찾아냅니다. 각 문서는 가장 높은 점수를 반환한 중심에 할당됩니다. 규모가 작은 클러스터들은 해체되어 노이즈로 처리됩니다.

고난도 작업은 Elasticsearch가 처리합니다. 즉, msearch(은)는 밀도 조사에, msearch(은)는 분류에, 그리고 significant_text(은)는 레이블 지정에 활용됩니다. 이 코퍼스(총 8,495개 문서)의 경우, 5%의 밀도 조사용 샘플을 통해 425개의 kNN 조사 쿼리가 실행됩니다. msearch(은)는 이를 9개의 HTTP 호출(배치 크기 50)로 배치 처리함으로써, 개별 조사마다 발생할 수 있는 요청 오버헤드를 방지합니다. 여기에 bbq_disk의 ANN 조회가 결합되어, 클러스터링 단계를 빠르고 확장 가능하게 유지해 줍니다. 클러스터링 단계에서는 속도를 위해 num_candidates 값을 최소화하여 kNN 쿼리를 실행합니다. 반면, 프로덕션 검색 쿼리에서는 지연 시간이 늘어나더라도 재현율을 높이기 위해 더 큰 num_candidates 값을 사용해야 합니다.

클러스터의 크기는 엄격한 k 제한이 아니라, 각 중심 주변의 임베딩 공간 밀도에 따라 자연스럽게 결정됩니다. 밀집된 주제 영역은 더 큰 클러스터를 형성하며, 지엽적인 주제 영역은 더 작은 클러스터를 형성합니다.

KMeans나 HDBSCAN을 사용하지 않는 이유는 무엇일까요?

KMeans는 구형 클러스터를 가정하며 전체 N×d 행렬을 메모리에 저장해야 합니다. 반면, 메모리에 수용 가능한 크기의 코퍼스라면 HDBSCAN이 강력한 대안이 됩니다. 이는 클러스터의 모양에 구애받지 않으며, 밀도 시맨틱이 잘 정립되어 있습니다.

밀도 조사 중심 접근 방식은 다른 지엽적인 영역을 공략합니다. 바로 저장 공간, 검색, 클러스터링을 하나의 시스템 내에서 통합 처리하려 하거나, 데이터 규모 때문에 클라이언트 측에서의 행렬 연산이 실용적이지 못한 경우입니다. Elasticsearch kNN을 컴퓨팅 기본 요소로 사용하고, 임의의 클러스터 크기를 처리하며, 거의 모든 계산을 서버 측에서 수행합니다.

노이즈 비율에 대한 이해

약 28%의 노이즈 발생률은 의도적으로 설계된 것이며, 오류 모드가 아닙니다. 구성된 similarity_threshold 기준에 따라 어떤 밀집 클러스터에도 적합하지 않은 문서는, 어설픈 매칭을 강행하는 대신 미할당 상태로 남겨 둡니다. 이는 일종의 품질 검사기 역할을 합니다. 사설 칼럼, 단신, 혹은 일회성 기사들은 응집력 있는 그룹을 형성할 만큼의 주제적 밀도가 낮기 때문에 자연스럽게 클러스터링을 거부하게 됩니다.

이 임계값은 조정이 가능합니다. similarity_threshold(을)를 낮추면 더 공격적인 클러스터링이 이루어지며 (더 많은 문서가 할당되지만 군집의 결속력은 느슨해짐) 반대로 높이면 클러스터가 더 긴밀해지는 대신 노이즈 비율이 증가합니다. 다양한 뉴스 콘텐츠가 섞인 이번 코퍼스의 경우, 약 30%의 노이즈 비율은 운용상 적절한 수치입니다. 실제 배포 환경에서는 도메인별 품질 기준에 맞춰 임계값을 조정해야 합니다.

significant_text를 활용한 자동 레이블

이제 각 클러스터에 사람이 읽을 수 있는 레이블을 지정해야 합니다. Elasticsearch의 significant_text 집계는 백그라운드 세트(전체 코퍼스)와 비교했을 때, 포그라운드 세트(클러스터) 내에서 유독 자주 등장하는 용어들을 찾아냅니다.

내부적으로는 머신 러닝이나 거대 언어 모델(LLM) 호출 없이, 절대 빈도와 상대 빈도의 변화를 균형 있게 고려하는 통계적 휴리스틱(기본값으로 JLH 점수 사용)을 활용합니다 영국 정치에 관한 클러스터라면 starmer, labour, downing 같은 용어들이 등장할 것입니다. 이 용어들이 전체 뉴스 코퍼스에 비해 해당 클러스터 내에서 압도적으로 높은 비중을 차지하기 때문입니다.

이번 전체 프로세스에서 레이블은 docs-clustering-all을(를) 기준으로 직접 계산됩니다. 따라서 포그라운드와 백그라운드 모두 한 달 전체 분량에서 추출됩니다. 2부의 레이블링 작업에는 일별 인덱스 패턴(docs-clustering-*)이 사용됩니다. 이 와일드카드 패턴은 쿼리가 모든 일치 인덱스를 동시에 쿼리할 수 있게 하여, significant_text이(가) 더 넓은 백그라운드 바탕으로 더 명확한 대비 효과를 얻을 수 있도록 합니다.

최소한의 쿼리 형태는 다음과 같습니다.

significant_text 또한 품질 검사기 역할도 합니다. 유미의한 용어를 생성하지 않는 클러스터는 구별되는 어휘가 없습니다. 이는 일관성 없는 그룹으로, 오해의 소지가 있는 레이블을 지정하기보다는 다시 노이즈로 해체되어야 합니다.

가벼운 결정론적 정제 단계를 거쳐 노이즈가 섞인 레이블 용어(숫자 토큰, 일반 단어 등)를 제거하며, 필요한 경우 대표적인 헤드라인을 대신 사용합니다. 이를 통해 레이블의 가독성을 높이면서도 Elasticsearch 레이블을 네이티브로 유지할 수 있습니다.

클러스터 시각화

아래 시각화는 전체 클러스터링 과정에서 발견된 결과물입니다. 클러스터링된 문서와 노이즈 문서의 날짜별 구성 현황, 한 달 전체 데이터의 UMAP 투영도, 그리고 클러스터가이 소스가 아닌 주제를 기준으로 형성되었음을 보여 주는 소스 혼합 차트를 확인할 수 있습니다.

2025년 2월 전체 기간에 걸친 클러스터링된 문서와 노이즈 문서의 일일 분포.

UMAP 상의 각 색상별 섬은 클러스터를 나타냅니다. 이는 오직 임베딩 유사도만을 기반으로 발견된, 동일한 주제에 관한 기사 그룹입니다. 회색으로 표시된 노이즈 지점은 어떤 클러스터에도 명확히 속하지 않는 기사들입니다.(주로 짧은 사설, 또는 단발성 뉴스인 경우가 많음)

소스 분류 차트를 통해 각 클러스터에 BBC News와 The Guardian의 기사가 모두 포함되어 있음을 확인할 수 있습니다. 이 클러스터링 시스템은 소스가 아닌 주제를 찾아내고 있으며, 이는 비지도형 탐색이 생성해야 하는 가장 이상적인 결과입니다.

다양성 기반 검색기(diversify retriever)를 사용하여 클러스터 범위를 탐색

일반 kNN은 클러스터의 중심(밀집된 핵심)과 가장 유사한 문서를 반환합니다. 그러나 실제 클러스터는 하위 주제를 다룹니다. 다양성 기반 검색기는 최대 한계 관련성(MMR)을 사용하여, 클러스터 중심과 관련성이 높으면서도 서로 다른 문서들을 찾아냅니다.

핵심 매개변수는 λ(람다)입니다.

• λ = 1.0 → 순수한 관련성(일반 kNN과 동일)입니다.

• λ = 0.0 → 순수한 다양성 (최대한 분산된 결과).

• λ=0.5 → 균형: 주제와 관련이 있지만 다른 관점을 다룹니다.

최소한의 검색기 요청 형태는 다음과 같습니다.

다양성 수준에서 type, field, query_vector 매개변수는 필수입니다. field(은)는 결과 간 유사도를 측정할 때 어떤 dense_vector 필드를 사용할지 MMR에 지시하며, query_vector(은)는 정확도 점수 산정의 기준점을 제공합니다.

이를 통해 단순히 '이 클러스터의 중심 내용이 무엇인가?'를 파악하는 수준을 넘어, '이 클러스터가 실제로 무엇을 다루고 있는가?' 라는 질문에 답할 수 있습니다.

일반 kNN 결과는 주제의 한 가지 관점에 대해서만 클러스터를 이룹니다. 즉, 중심 및 서로 간의 유사도가 가장 높은 문서들만 한데 모이게 됩니다. 다양성 기반 검색기는 동일한 클러스터의 서로 다른 패싯, 즉 하위 주제, 서로 다른 소스, 다양한 관점을 보여 줍니다.

다양성 지표가 이를 수치적으로 증명합니다. 다양성 기반 검색기 결과의 평균 쌍별 유사성이 더 낮게 나타나는데, 이는 검색된 문서가 더 넓은 범위를 다룬다는 것을 의미합니다.

이는 다음과 같은 경우에 유용합니다.

• 클러스터가 실제로 포괄하는 범위가 어디까지인지 이해하려면, 단순히 중심부뿐만 아니라 그 외곽 경계까지 살펴봐야 합니다.

• 요약 생성. 다양한 대표 문서가 LLM에 더 나은 자료를 제공합니다.

• 사람이 직접 검토하거나 후속 레이블 지정에 사용할 대표 사례들을 찾아냅니다.

• 품질 검사. 다양한 결과가 일관성이 없어 보이면 클러스터를 분할해야 할 수도 있습니다.

2부: 시간적 스토리 체인

일자별 스토리 추적

1부에서는 주제 탐색을 위해 한달 전체를 전역으로 클러스터링했습니다. 시간적 흐름을 파악하기 위해, 동일한 밀도 조사 중심 분류를 일별 인덱스에 대해 매일 독립적으로 실행하면, 인접한 날짜 간에 클러스터가 서로 연결됩니다. 참고로 일별 클러스터는 1부의 전역 클러스터와는 별개입니다. 각 날짜마다 그날의 콘텐츠에 맞게 조정된 자체 클러스터 할당과 레이블이 생성됩니다.

연결 방식: 샘플링 후 쿼리

A일의 각 클러스터에 대하여:

1. 몇 개의 대표 문서들을 샘플링합니다.

2. B일의 인덱스를 대상으로 kNN 검색을 실행합니다.

3. B일의 각 클러스터에 검색 결과가 몇 건이나 도달하는지 계산합니다.

4. 검색 결과의 비율이 임계값(kNN fraction ≥ 0.4)을 초과하면, 두 클러스터 사이의 링크를 기록합니다.

이 과정은 빠르며(전체 문서가 아닌 클러스터당 몇 개의 문서만 쿼리하기 때문) Elasticsearch의 네이티브 kNN을 사용하므로 외부 도구가 필요하지 않습니다.

kNN 비율이 100%라는 것은 소스 클러스터에서 샘플링된 모든 문서가 동일한 타겟 클러스터에 도달했음을 의미하며, 이는 일자 간에 형성될 수 있는 가장 강력한 링크입니다. 위에서 확인된 대부분의 링크는 축구 관련 내용입니다. 이는 타당한 결과인데, 프리미어 리그 보도는 매일 발생하며 주제의 일관성 또한 매우 높기 때문입니다.

score | operator | gedling → league | striker | season(으)로 이어지는 링크는 지엽적인 로컬 축구 클러스터(Gedling은 비리그 구단임)가 다음 날 더 광범위한 프리미어 리그 클러스터로 흡수되는 과정을 보여 주는 사례입니다. 이는 매일 다른 세부 단위로 다시 클러스터링이 이루어질 때 나타나는 자연스러운 현상입니다.

스토리 체인 구축

스토리 체인은 연속된 날짜에 걸쳐 서로 연결된 클러스터들의 시퀀스입니다.

각각의 쌍별 링크를 통해 월요일의 '영국 정치' 클러스터가 화요일의 클러스터와 연결된다는 사실을 알 수 있습니다. 월요일에 시작된 이야기가 한 주 동안 어떻게 전개되고, 금요일에 이르러 어떻게 잦아드는지, 체인을 통해 스토리의 전체 흐름을 파악할 수 있습니다.

체인은 kNN 비율 0.4 이상의 링크를 바탕으로 탐욕적 방식으로 구축됩니다. 이는 소스 클러스터에서 샘플링된 문서 중 최소 40%가 단일 타겟 클러스터에 매칭되었음을 의미합니다. 가장 이른 시점의 클러스터부터 시작하여, 알고리즘은 항상 가장 강력한 출력 링크를 따라갑니다.

가장 긴 스토리 체인은 우크라이나-러시아 관련 보도를 19일 연속으로 추적했는데, 2025년 2월의 지속적인 지정학적 긴장 수위를 고려하면 당연한 결과라 할 수 있습니다. 두 번째로 긴 체인은 한 달 중 19일 동안 이어지는 프리미어 리그 축구 소식을 추적합니다. 더 짧은 체인으로는 시상식 시즌(영화/시상식, 6일), 식스 네이션스 럭비(10일), 그리고 영국 정치 리더십 관련 보도(7일) 등이 포착되었습니다. 각 체인은 알고리즘이 일자별 인덱스 간의 임베딩 유사도만을 바탕으로 순수하게 찾아낸 스토리의 흐름을 나타냅니다.

Sankey: 스토리 흐름 시각화

Sankey 다이어그램은 링크의 폭으로 연결 강도를 표현하는 흐름 시각화 도구입니다. 여기에서 각 수직 밴드는 하루를, 각 노드는 일별 클러스터(문서 수에 따른 크기)를 나타내며, 각각의 색상 경로는 시간을 따라 이어지는 하나의 스토리 체인을 추적합니다. 링크의 폭은 kNN 중첩 강도를 나타냅니다. 링크가 굵을수록 샘플링된 더 많은 문서가 타겟 클러스터에 도달했음을 의미합니다. 체인마다 색상이 일치하므로, 왼쪽에서 오른쪽으로 이어지는 하나의 색상 경로는 하나의 이야기 진행을 나타냅니다.

예를 들어, (가장 긴 경로 중 하나로 시각화된) 우크라이나-러시아 체인은 2월 초부터 셋째 주까지 계속해서 이어지며, 링크의 폭이 지속적으로 굵게 유지되는 것은 일자별로 강력한 주제적 연속성이 있었음을 보여 줍니다.

2025년 2월 한 달간 전개되는 시간적 스토리 체인. 각 색상별 경로는 며칠 동안 지속되는 스토리를 나타내며, 링크 폭은 k-NN 중첩 강도를 보여 줍니다.

이 접근 방식이 제공하는 이점

이 단계별 안내에서는 Elasticsearch를 활용하여 비지도형 문서 클러스터링 파이프라인의 전 과정을 살펴보았습니다.

1. 임베딩 클러스터링: Jina v5의 작업별 어댑터는 단순한 쿼리-문서 매칭을 넘어, 주제별 그룹화에 최적화된 임베딩을 생성합니다.

2. 전역 탐색 클러스터링: 한 달 전체를 하나의 인덱스에 클러스터링하면 일별 주제 탐색을 극대화할 수 있습니다.

3. 밀도 조사 중심 분류: 5%를 샘플링하고, msearch kNN을 통해 밀도를 조사하며, 밀도가 높은 다양한 시드를 선택하고, 모든 문서를 이 중심에 맞춰 분류합니다. 연산량이 많아 무거운 작업은 Elasticsearch가 처리하며, 시드 선택 과정만 클라이언트 측에서 실행됩니다.(약 0.01초 소요)

4. significant_text 레이블 지정: 유의성 검정을 통해 ML 모델이나 수동 주석 없이도 의미 있는 클러스터 레이블을 생성합니다. 유의미한 용어를 생성하지 않는 클러스터는 일관성이 없으며 노이즈로 강등됩니다. 이는 시스템에 내장된 품질 검사기입니다.

5. 시간적 스토리 연결: 일일 인덱스와 샘플 및 쿼리 교차 인덱스 kNN은 시간이 지남에 따라 스토리가 어떻게 진화하는지 추적합니다.

핵심 사항:

• 임베딩 작업 유형 설정이 핵심입니다. 클러스터링 임베딩을 사용하면 주제별 그룹이 훨씬 더 긴밀하게 형성됩니다.

• Elasticsearch는 kNN 검색을 통해 저장 계층 및 클러스터링 엔진 역할을 수행할 수 있습니다.

• 밀도 조사 중심 분류는 거의 모든 연산을 서버 측에서 처리하며, 임베딩 공간의 밀도에 따라 자연스러운 크기의 클러스터를 생성합니다.

• significant_text 빠르고 해석 가능하며 자동 레이블링과 품질 검사 모두에 효과적입니다.

이 방식이 유용한 경우:

• 타임스탬프가 찍힌 텍스트는 있지만, 레이블이 지정된 학습 데이터 없이 주제를 탐색하고 싶을 때 유용합니다.

• 저장 공간, 벡터 검색, 레이블 지정 및 시간적 연결을 하나의 스택으로 해결하고 싶을 때 적합합니다.

탐색할 확장 기능:

• 다중 기간 클러스터링(주간, 월간 단위 집계)

• 클러스터 할당을 점진적으로 수행하여 실시간 데이터 수집이 가능합니다.

• significant_text 용어를 시드로 활용해 LLM이 클러스터 요약문을 생성합니다.

• 규모가 커지면, 샘플링된 KMeans 중심은 밀도 기반 클러스터링을 위한 웜 스타트 시드로 사용될 수 있어, 조사 단계 비용을 줄여 줍니다.

직접 사용해 보기

자신만의 타임스탬프 기반의 문서 코퍼스를 넣어 보세요. 날짜 정보가 포함된 텍스트 모음이라면 무엇이든 이 파이프라인에서 바로 작동합니다. 전체 노트북과 지원 코드는 제공된 리포지토리에서 확인할 수 있습니다.

• 무료 Elastic Cloud 체험판 시작하기: 단 몇 분 만에 bbq_disk 기능이 지원되는 관리형 클러스터를 실행할 수 있습니다.

• Elasticsearch Serverless 사용해 보기: 클러스터 관리가 필요 없으며, 자동으로 확장하고, 이 단계별 안내의 모든 기능을 지원합니다.

목표는 로그 구문 분석(필드 추출)과 로그 분할(소스 식별)을 모두 처리할 수 있는 자동화되고 적응형 접근 방식으로 전환하는 것이었습니다. 대규모 언어 모델(LLM)이 코드 구문과 의미론적 패턴에 대한 내재된 이해를 통해 이러한 작업을 최소한의 인간 개입으로 자동화할 수 있다고 가정했습니다.

Streams에서 이미 이 기능을 사용 가능하다는 기쁜 소식을 전해 드립니다!

데이터 세트 설명

PoC 목적으로 Loghub로그 컬렉션을 선택했습니다. 조사를 위해 다음 주요 분야에서 대표적인 샘플을 선정했습니다.

• 분산 시스템: HDFS(Hadoop 분산 파일 시스템)와 Spark 데이터 세트를 사용했습니다. 여기에는 빅데이터 플랫폼에서 흔히 볼 수 있는 정보, 디버그, 오류 메시지가 섞여 있습니다.

• 서버 및 웹 애플리케이션: Apache 웹 서버 및 OpenSSH의 로그는 액세스, 오류 및 보안 관련 이벤트의 귀중한 소스를 제공했습니다. 이는 웹 트래픽을 모니터링하고 잠재적 위협을 탐지하는 데 매우 중요합니다.

• 운영 체제: Linux 및 Windows의 로그를 포함했습니다. 이러한 데이터 세트는 운영팀이 매일 접하는 일반적인 반정형 시스템 수준 이벤트를 나타냅니다.

• 모바일 시스템: 모바일 환경에서 발생하는 로그를 모델이 처리할 수 있는지 확인하기 위해 안드로이드 데이터 세트를 포함했습니다. 이러한 로그는 종종 상세한 내용을 담고 있으며 모바일 디바에스에서 발생하는 다양한 애플리케이션 및 시스템 수준의 활동을 기록합니다.

• 슈퍼컴퓨터: 고성능 컴퓨팅(HPC) 환경에서 성능을 테스트하기 위해 고도로 구조화된 로그와 특정 도메인 용어를 특징으로 하는 BGL (Blue Gene/L) 데이터 세트를 통합했습니다.

Loghub 컬렉션의 주요 장점은 로그가 대부분 정제되지 않고 레이블이 지정되지 않아 노이즈가 많은 실시간 프로덕션 환경을 마이크로서비스 아키텍처로 미러링한다는 점입니다.

로그 예:

또한 가장 일반적인 도메인에서 추가 로그를 수집하기 위해 일반적인 웹 애플리케이션과 데이터베이스 설정으로 Kubernetes 클러스터를 생성했습니다.

일반적인 로그 필드의 예: 타임스탬프, 로그 레벨(정보, 경고, 오류), 소스, 메시지.

LLM을 이용한 퓨샷 로그 구문 분석

첫 번째 실험은 근본적인 질문에 초점을 맞췄습니다: LLM이 핵심 필드를 안정적으로 식별하고 이를 추출하기 위한 일관된 구문 분석 규칙을 생성할 수 있는가?

모델에 원시 로그 샘플을 분석하고 정규식(Regex) 및 Grok 형식의 로그 구문 분석 규칙을 생성하도록 요청했습니다. 그 결과, 이 접근 방식은 잠재력이 많지만 구현에 상당한 어려움이 있음을 파악했습니다.

높은 신뢰도 및 상황 인식

초기 결과는 고무적이었습니다. LLM은 제공된 퓨샷 예시와 일치하는 구문 분석 규칙을 높은 신뢰도로 생성하는 뛰어난 능력을 보여주었습니다. 이 모델은 단순한 패턴 매칭 외에도 로그 소스를 정확하게 식별하고 이름을 지정할 수 있는 로그 이해 능력도 보여주었습니다(예: 상태 추적 앱, Nginx 웹 앱, Mongo 데이터베이스).

입력 샘플의 '골디락스' 딜레마

실험 결과, 입력 샘플에 대한 극도의 민감성 때문에 모델의 견고성이 상당히 부족하다는 점이 금방 드러났습니다. 모델의 성능은 프롬프트에 포함된 특정 로그 예시에 따라 크게 변동했습니다. 로그 샘플에는 충분히 다양한 로그가 포함되어야 하는 로그 유사성 문제가 있음을 확인했습니다.

• 너무 동질적인 경우(과적합): 입력 로그가 너무 유사하면 LLM은 과도하게 세부화하는 경향이 있습니다. 스택 추적의 특정 Java 클래스 이름과 같은 가변 데이터를 템플릿의 정적 부분으로 처리합니다. 이로 인해 극히 일부 로그만 다루고 사용할 수 없는 필드를 추출하는 취약한 규칙이 생성됩니다.

• 너무 이질적인 경우(혼란): 반대로 샘플에 형식상의 편차가 심하거나, 더 심각하게는 진행률 표시줄, 메모리 테이블 또는 ASCII 아트와 같은 '엉터리 로그'가 포함되면 모델은 공통분모를 찾는 데 어려움을 겪습니다. 이 경우 복잡하고 불완전한 정규식을 생성하거나 전체 줄을 단일 메시지 블롭 필드로 과도하게 일반화하는 경우가 많습니다.

컨텍스트 윈도우 제약 조건

또한 컨텍스트 윈도우 병목 현상에 직면했습니다. 입력 로그가 길거나, 이질적이거나, 추출 가능한 필드가 많을 경우, 모델의 출력 결과가 종종 저하되어 "정리되지 않은" 상태가 되거나 출력 컨텍스트 윈도우에 맞지 않을 정도로 길어졌습니다. 당연히 청킹이 이러한 문제를 해결하는 데 도움이 됩니다. 문자 기반 및 엔티티 기반 구분자를 사용하여 로그를 분할함으로써, 모델이 노이즈에 압도되지 않고 주요 필드를 추출하는 데 집중할 수 있도록 도울 수 있었습니다.

일관성 및 표준화 격차

모델이 규칙을 성공적으로 생성한 경우에도 다음과 같이 약간의 불일치가 발견되었습니다.

• 서비스 이름 지정 변형: 모델은 동일한 엔티티에 대해 서로 다른 이름을 제안합니다(예: 실행마다 소스를 'Spark', 'Apache Spark' 및 'Spark Log Analytics'로 레이블 지정).

• 필드 이름 지정의 변형: 필드 이름이 표준화되지 않았습니다(예: id , service.id , device.id). 표준화된 Elastic 필드 이름 지정을 사용하여 이름을 정규화했습니다.

• 해상도 편차: 필드 추출의 해상도는 입력 로그가 서로 얼마나 유사한지에 따라 달라집니다.

로그 형식 지문

로그 유사성 문제를 해결하기 위해 고성능 휴리스틱인 로그 형식 지문(LFF)을 도입합니다.

원시적이고 노이즈가 많은 로그를 LLM에 직접 입력하는 대신, 먼저 결정론적 변환을 적용하여 각 메시지의 기본 구조를 드러냅니다. 이 전처리 단계는 가변 데이터를 추상화하여 관련 로그를 그룹화할 수 있는 단순화된 '지문'을 생성합니다.

매핑 로직은 속도와 일관성을 보장하기 위해 다음과 같이 간단합니다.

1. 숫자 추상화: 모든 숫자 시퀀스(0-9)는 단일 '0'으로 대체됩니다.

2. 텍스트 추상화: 공백이 있는 알파벳 문자 시퀀스는 단일 ‘a’로 대체됩니다.

3. 공백 정규화: 모든 공백 시퀀스(공백, 탭, 줄바꿈)는 하나의 공백으로 축소됩니다.

4. 기호 보존: 구두점 및 특수 문자(예: :, [, ], /)는 로그 구조를 나타내는 가장 강력한 지표인 경우가 많으므로 보존됩니다.

로그 매핑 접근 방식을 소개합니다. 기본 매핑 패턴은 다음과 같습니다.

• 길이에 상관없이 0-9자리 숫자 ->'0'으로 대체.

• 모든 길이의 텍스트(공백이 있는 알파벳 문자) -> 'a'로 대체.

• 공백, 탭, 줄바꿈 -> 하나의 공간으로 축소.

이 매핑을 통해 로그를 어떻게 변환하는지에 대한 예를 살펴보겠습니다.

그 결과, 다음과 같은 로그 마스크를 얻습니다.

처음 두 로그의 지문을 주목하세요. 타임스탬프, 소스 클래스, 메시지 내용이 다르더라도 접두사(0/0/0 0:0:0 a a.a:)는 동일합니다. 이러한 구조적 정렬을 통해 이러한 로그를 동일한 클러스터에 자동으로 버킷화할 수 있습니다.

하지만 세 번째 로그는 완전히 다른 지문을 생성합니다(0-0-0...). 이를 통해 LLM을 호출하기 전에 첫 번째 그룹과 알고리즘적으로 분리할 수 있습니다.

보너스: ES|QL을 이용한 즉시 구현

Discover에서 이 쿼리를 전달하기만 하면 됩니다.

쿼리 분석:

FROM loghub: 원시 로그 데이터를 포함하는 인덱스를 대상으로 합니다.

EVAL 패턴 = …: 핵심 매핑 로직. REPLACE 함수를 연결하여 추상화(예: 숫자를 '0'으로, 텍스트를 'a'로 등)를 수행하고 결과를 '패턴' 필드에 저장합니다.

STATS [column1 =] expression1, … BY SUBSTRING(pattern, 0, 15):

이는 클러스터링 단계입니다. 패턴의 처음 15자를 공유하는 로그를 그룹화하고 그룹당 총 로그 수, 로그 데이터 소스 목록, 패턴 접두사, 3개의 로그 예시와 같은 집계 필드를 만듭니다.

SORT total_count DESC | LIMIT 100 : 가장 빈번한 상위 100개의 로그 패턴을 표시합니다

LogHub의 쿼리 결과는 아래와 같습니다.

시각화 자료에서 볼 수 있듯이, 이 'LLM 없는' 접근 방식은 높은 정확도로 로그를 분할합니다. LogHub 레이블을 기준으로 16개 데이터 소스 중 10개를 완벽하게(>90%) 클러스터링했고, 13개 소스에서는 과반수 클러스터링을 달성했습니다(>60%). 이 모든 결과는 추가적인 데이터 정제, 전처리 또는 미세 조정 없이 얻어졌습니다.

로그 형식 지문은 로그 패턴 분석과 같은 정교한 ML 솔루션에 더해 실용적이고 영향력이 큰 대안을 제공합니다. 로그 관계에 대한 즉각적인 인사이트를 제공하고 대규모 로그 클러스터를 효과적으로 관리할 수 있습니다.

• 원시적인 요소로서의 높은 활용도

ES|QL 구현 덕분에 LFF는 빠른 데이터 진단/시각화를 위한 독립형 도구로, 그리고 대용량 사용 사례를 위한 로그 분석 파이프라인의 구성 요소로 모두 사용할 수 있습니다.

• 유연성

LFF는 쉽게 사용자 정의하고 확장하여 특정 패턴(예: 16진수 및 IP 주소)을 캡처할 수 있습니다.

• 결정론적 안정성

ML 기반 클러스터링 알고리즘과 달리, LFF 로직은 간단하고 결정론적입니다. 새로 들어오는 로그는 기존 로그 클러스터에 소급하여 영향을 미치지 않습니다.

• 성능 및 mMemory

최소한의 메모리만 필요하고, 학습이나 GPU도 필요 없으므로 실시간 고처리량 환경에 적합합니다.

로그 형식 지문과 LLM 결합하기

제안된 하이브리드 아키텍처를 검증하기 위해 각 실험에는 각 데이터 소스에서 무작위로 선택한 20%의 로그 하위 집합이 포함되었습니다. 이러한 제약 조건은 로그가 배치 처리되는 실제 프로덕션 환경을 시뮬레이션한 것으로, 로그가 하나의 거대한 과거 데이터 더미로 처리되는 환경과는 다릅니다.

목표는 LFF가 효과적인 압축 레이어로 작용함을 입증하는 것이었습니다. 또한 엄선된 소규모 샘플로부터 높은 커버리지를 갖는 구문 분석 규칙을 생성하고 이를 전체 데이터 세트에 성공적으로 일반화할 수 있음을 증명하고자 했습니다.

실행 파이프라인

데이터가 LLM에 도달하기 전에 필터링, 클러스터링, 계층화된 샘플링을 적용하는 다단계 파이프라인을 구현했습니다.

1. 2단계 계층적 클러스터링

• 하위 클래스(정확히 일치): 로그는 동일한 지문을 기준으로 집계됩니다. 하나의 하위 클래스에 있는 모든 로그는 정확히 동일한 형식 구조를 공유합니다.

• 이상값 정리. 전체 로그 볼륨의 5% 미만을 차지하는 하위 클래스는 모두 삭제합니다. 이렇게 하면 LLM이 주요 신호에 집중할 수 있고 노이즈나 잘못된 로그에 의해 방해받지 않게 됩니다.

• 메타클래스(접두사 일치): 나머지 하위 클래스는 형식 지문 일치의 첫 N 문자에 의해 메타클래스로 그룹화됩니다. 이 그룹화 전략은 어휘적으로 유사한 형식을 하나의 범주로 효과적으로 분할합니다. 데이터 소스를 알 수 없는 경우 로그 구문 분석에는 N=5를, 로그 분할에는 N=15를 선택했습니다.

2. 계층화된 샘플링. 계층 구조 트리가 구축되면 LLM에 대한 로그 샘플을 구성합니다. 전략적 목표는 분산 범위를 최대화하고 토큰 사용량을 최소화하는 것입니다.

• 더 넓은 메타클래스 내의 각 유효한 하위 클래스에서 대표적인 로그를 선택합니다.

• 너무 많은 하위 클래스의 예외적인 경우를 관리하기 위해 대상 윈도우 크기에 맞게 무작위 다운샘플링을 적용합니다.

3. 규칙 생성 마지막으로, LLM에 각 메타클래스에 대해 제공된 샘플의 모든 로그에 맞는 정규식 구문 분석 규칙을 생성하도록 지시합니다. 본 PoC에서는 GPT-4o 미니 모델을 사용했습니다.

실험 결과 및 관찰

Loghub 데이터 세트에서 구문 분석 정확도 94%, 분할 정확도 91%를 달성했습니다.

위의 혼동 행렬은 로그 분할 결과를 보여줍니다. 세로축은 실제 데이터 소스를 나타내고 가로축은 예측된 데이터 소스를 나타냅니다. 히트맵 강도는 로그 볼륨에 대응하며, 밝은 타일은 더 많은 수를 나타냅니다. 대각선 정렬은 산포가 최소화된 상태에서 모델이 소스 귀속을 매우 정확하게 수행함을 보여줍니다.

성과 벤치마크 인사이트:

• 최적의 기준선: 카테고리당 30–40개 로그 샘플의 컨텍스트 윈도우가 '최적의 지점'으로 입증되었으며, 정규식과 Grok 패턴에서 모두 일관되게 강력한 구문 분을 생성했습니다.

• 입력 최소화: 정규식 패턴에 대해 카테고리당 입력 크기를 10개의 로그로 늘렸을 때 구문 분석 성능이 2%만 저하하는 것을 확인했으며, 이는 다양성 기반 샘플링이 원시 볼륨보다 더 중요하다는 점을 입증합니다.

필터와 패싯 비교

시작하기 전에 필터와 패싯이 무엇인지 정의해 보겠습니다. 필터는 결과 집합을 제한하는 데 사용되는 미리 정의된 속성입니다. 예를 들어 마켓플레이스에서는 검색이 수행되기 전에도 필터를 사용할 수 있습니다. 사용자는 "비디오 게임" 과 같은 카테고리를 선택한 다음 "PS5" 과 같이 전체 데이터베이스가 아닌 보다 구체적인 하위 집합으로 검색을 구체화할 수 있습니다. 이렇게 하면 보다 관련성 높은 결과를 얻을 가능성이 크게 높아집니다.

패싯은 필터와 유사하게 작동하지만 검색을 수행한 후에만 사용할 수 있습니다. 즉, 검색이 결과를 반환하고 이를 기반으로 새로운 세분화 옵션 목록이 생성됩니다. 예를 들어 PS5 콘솔을 검색할 때 저장 용량, 배송비, 색상 등의 측면이 표시되어 사용자가 이상적인 제품을 선택하는 데 도움이 될 수 있습니다.

이제 필터와 패싯을 정의했으니, 기존 방식과 머신 러닝(ML) 기반 방식이 구현과 사용에 미치는 영향에 대해 논의해 보겠습니다. 각 방법에는 검색 효율성에 영향을 미치는 장점과 과제가 있습니다.

필터 및 패싯에 대한 전통적인 접근 방식

이 접근 방식에서는 필터와 패싯이 미리 정의된 규칙에 따라 수동으로 정의됩니다. 즉, 카탈로그 구조와 사용자 요구를 고려하여 검색을 구체화하는 데 사용할 수 있는 속성이 미리 정해지고 계획되어 있습니다.

예를 들어 마켓플레이스에서 "전자제품" 또는 "패션" 같은 카테고리에는 브랜드, 형식, 가격대 등의 특정 필터가 있을 수 있습니다. 이러한 규칙은 정적으로 생성되므로 검색 환경의 일관성을 보장하지만 새로운 제품이나 카테고리가 등장할 때마다 수동으로 조정해야 합니다.

이 접근 방식은 표시되는 필터와 패싯에 대한 예측 가능성과 제어 기능을 제공하지만, 동적으로 세분화해야 하는 새로운 트렌드가 발생할 경우 제한적일 수 있습니다.

장점:

• 예측 가능성 및 제어: 필터와 패싯을 수동으로 정의할 수 있으므로 관리가 더 쉬워집니다.

• 낮은 복잡성: 모델을 훈련할 필요가 없습니다.

• 유지 관리의 용이성: 규칙이 미리 정의되어 있으므로 신속하게 조정 및 수정할 수 있습니다.

단점:

• 새 필터에는 재색인 작업이 필요합니다: 새 속성을 필터로 사용해야 할 때마다 문서에 이 정보가 포함되어 있는지 확인하기 위해 전체 데이터 집합을 다시 색인해야 합니다.

• 동적 적응이 부족합니다: 필터는 정적이며 사용자 행동의 변화에 따라 자동으로 조정되지 않습니다.

필터/패싯 구현 - 고전적인 접근 방식

개발 도구인 Kibana에서는 고전적인 접근 방식을 사용하여 필터/패싯 데모를 만들어 보겠습니다.

먼저 인덱스를 구성하기 위한 매핑을 정의합니다:

브랜드 및 저장 필드는 키워드로 설정되어 집계(패싯)에서 바로 사용할 수 있습니다. 가격 필드는 플로트 유형으로 가격 범위를 생성할 수 있습니다.

다음 단계에서는 제품 데이터가 색인화됩니다:

이제 브랜드, 스토리지 및 가격대별로 결과를 그룹화하여 클래식 패싯을 검색해 보겠습니다. 쿼리에서 size:0이 정의되었습니다. 이 시나리오에서는 쿼리에 해당하는 문서를 포함하지 않고 집계 결과만 검색하는 것이 목표입니다.

응답에는 브랜드, 스토리지, 가격에 대한 카운트가 포함되어 필터와 패싯을 만드는 데 도움이 됩니다.

필터 및 패싯에 대한 머신 러닝/AI 기반 접근 방식

이 접근 방식에서는 인공 지능(AI) 기술을 포함한 머신 러닝(ML) 모델이 데이터 속성을 분석하여 관련 필터와 패싯을 생성합니다. ML/AI는 미리 정의된 규칙에 의존하는 대신 인덱싱된 데이터 특성을 활용합니다. 이를 통해 새로운 패싯과 필터를 동적으로 검색할 수 있습니다.

장점:

• 자동 업데이트: 수동으로 조정할 필요 없이 새로운 필터와 패싯이 자동으로 생성됩니다.

• 새로운 속성 발견: 이전에는 고려하지 않았던 데이터 특성을 필터로 식별하여 검색 환경을 더욱 풍부하게 만들 수 있습니다.

• 수동 작업 감소: AI가 사용 가능한 데이터에서 학습하므로 팀에서 필터링 규칙을 지속적으로 정의하고 업데이트할 필요가 없습니다.

단점:

• 유지 관리의 복잡성: 모델을 사용하려면 생성된 필터의 일관성을 보장하기 위해 사전 검증이 필요할 수 있습니다.

• ML 및 AI 전문 지식이 필요합니다: 이 솔루션은 모델 성능을 미세 조정하고 모니터링할 수 있는 자격을 갖춘 전문가가 필요합니다.

• 관련 없는 필터의 위험: 모델이 제대로 보정되지 않은 경우 사용자에게 유용하지 않은 패싯을 생성할 수 있습니다.

• 비용: ML 및 AI를 사용하려면 타사 서비스가 필요할 수 있으므로 운영 비용이 증가할 수 있습니다.

잘 보정된 모델과 잘 만들어진 프롬프트가 있더라도 생성된 패싯은 검토 단계를 거쳐야 한다는 점에 유의할 필요가 있습니다. 이 검증은 수동 또는 모더레이션 규칙에 따라 이루어질 수 있으며, 콘텐츠가 적절하고 안전한지 확인합니다. 반드시 단점이 있는 것은 아니지만, 사용자에게 제공하기 전에 패싯의 품질과 적합성을 확인하는 것은 중요한 고려 사항입니다.

필터/패싯 구현 - AI 접근 방식

이 데모에서는 AI 모델을 사용하여 자동으로 제품 특성을 분석하고 관련 속성을 제안합니다. 잘 구조화된 프롬프트를 통해 카탈로그에서 정보를 추출하고 이를 필터와 패싯으로 변환합니다. 아래에서 프로세스의 각 단계를 설명합니다.

처음에는 추론 API를 사용하여 ML 서비스와의 통합을 위해 엔드포인트를 등록할 것입니다. 아래는 OpenAI 서비스와의 통합 예시입니다.

이제 프롬프트를 실행하고 모델에서 생성된 새 필터를 가져오는 파이프라인을 정의합니다.

"PlayStation 5" 제품에 대한 이 파이프라인의 시뮬레이션을 다음 설명과 함께 실행합니다:

놀라운 게임: 놀라운 그래픽에 감탄하고 새로운 PS5의 기능을 경험해 보세요.

놀라운 몰입감: 햅틱 피드백, 적응형 트리거, 3D 오디오 기술을 지원하여 더욱 깊이 있는 게임 환경을 경험하세요.

슬림한 디자인: PS5 디지털 에디션으로 게이머는 세련되고 컴팩트한 디자인에 강력한 게임 기술을 즐길 수 있습니다.

1TB의 저장 공간: 1TB의 내장 SSD 스토리지로 좋아하는 게임을 준비해 두고 플레이하세요.

이전 버전과의 호환성 및 게임 부스트: PS5 콘솔은 4,000개 이상의 PS4 게임을 플레이할 수 있습니다. 게임 부스트를 사용하면 최고의 PS4 콘솔 게임에서 더욱 빠르고 부드러운 프레임 속도를 즐길 수 있습니다.

이 시뮬레이션에서 생성된 프롬프트 출력을 관찰해 보겠습니다.

이제 새 인덱스에 새 필드인 dynamic_facets가 추가되어 AI가 생성한 패싯을 저장합니다.

재색인 API를 사용하여 비디오게임 인덱스를 비디오게임_1로 재색인하고, 이 과정에서 생성_필터_ai 파이프라인을 적용합니다. 이 파이프라인은 인덱싱 중에 동적 패싯을 자동으로 생성합니다.

이제 검색을 실행하여 새 필터를 가져옵니다:

결과:

패싯의 구현을 상징하기 위해 아래는 간단한 프런트엔드입니다:

제시된 UI 코드는 여기에 있습니다.

결론

필터와 패싯을 만드는 두 가지 접근 방식 모두 장점과 우려되는 점이 있습니다. 수동 규칙을 기반으로 하는 고전적인 접근 방식은 제어와 비용 절감 효과를 제공하지만 지속적인 업데이트가 필요하고 새로운 제품이나 기능에 동적으로 적응하지 못합니다.

반면, AI 및 머신러닝 기반 접근 방식은 패싯 추출을 자동화하여 검색을 더욱 유연하게 만들고 수동 개입 없이 새로운 속성을 발견할 수 있게 해줍니다. 그러나 이 접근 방식은 구현 및 유지 관리가 더 복잡할 수 있으며 일관된 결과를 보장하기 위해 보정이 필요할 수 있습니다.

기존 방식과 AI 기반 방식 중 어떤 방식을 선택할지는 비즈니스의 요구와 복잡성에 따라 달라집니다. 데이터 속성이 안정적이고 예측 가능한 간단한 시나리오의 경우, 기존 접근 방식이 더 효율적이고 유지 관리가 쉬우며 인프라 및 AI 모델을 통해 불필요한 비용을 피할 수 있습니다. 반면에 ML/AI를 사용하여 패싯을 추출하면 검색 환경을 개선하고 필터링을 더욱 지능적으로 만들어 상당한 가치를 더할 수 있습니다.

중요한 것은 자동화가 투자를 정당화하는지, 아니면 기존 솔루션이 이미 비즈니스 요구 사항을 효과적으로 충족하는지 평가하는 것입니다.

검색 관련성 평가에서 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 판정자로 사용하는 방법과, 관련성을 예측하도록 이를 튜닝해 나간 과정을 보다 깊이 있게 다룹니다.

HNSW는 벡터를 저장하고 검색하는 강력하고 유연한 방법이지만, 빠르게 실행하려면 상당한 양의 메모리를 필요로 합니다. 예를 들어, 768차원의 1MM float32 벡터를 쿼리하려면 약 램이 필요합니다. 상당한 수의 벡터를 검색하기 시작하면 비용이 많이 듭니다. 약 적은 메모리를 사용하는 한 가지 방법은 바이트 정량화를 사용하는 것입니다. Lucene과 그에 따른 Elasticsearch는 한동안 벡터 인덱싱을 지원했지만 이러한 벡터를 구축하는 것은 사용자의 책임이었습니다. 이제 곧 Lucene에 스칼라 양자화가 도입될 예정입니다.

스칼라 양자화 101

모든 양자화 기술은 원시 데이터의 손실 변환으로 간주됩니다. 즉, 공간 확보를 위해 일부 정보가 손실된다는 의미입니다. 스칼라 양자화에 대한 자세한 설명은 다음을 참조하세요: 스칼라 양자화 101을 참조하세요. 높은 수준에서 스칼라 양자화는 손실 압축 기술입니다. 간단한 계산을 통해 리콜에 거의 영향을 미치지 않으면서도 공간을 크게 절약할 수 있습니다.

아키텍처 살펴보기

Elasticsearch 작업에 익숙하신 분들은 이러한 개념에 이미 익숙하실 수도 있지만, 검색을 위한 문서 배포에 대한 간략한 개요는 다음과 같습니다.

각 Elasticsearch 인덱스는 여러 개의 샤드로 구성됩니다. 각 샤드는 단일 노드에만 할당할 수 있지만, 인덱스당 여러 개의 샤드를 사용하면 노드 간에 컴퓨팅 병렬 처리를 할 수 있습니다.

각 샤드는 하나의 루씬 인덱스로 구성됩니다. Lucene 인덱스는 여러 개의 읽기 전용 세그먼트로 구성됩니다. 색인하는 동안 문서가 버퍼링되고 주기적으로 읽기 전용 세그먼트로 플러시됩니다. 특정 조건이 충족되면 이러한 세그먼트는 백그라운드에서 더 큰 세그먼트로 병합될 수 있습니다. 이 모든 것은 구성할 수 있으며 나름의 복잡성을 가지고 있습니다. 그러나 세그먼트와 병합에 대해 이야기할 때는 읽기 전용 Lucene 세그먼트와 이러한 세그먼트의 자동 주기적 병합에 대해 이야기하고 있습니다. 세그먼트 병합 및 디자인 결정에 대해 자세히 알아보세요.

루씬의 세그먼트별 정량화

Lucene의 모든 세그먼트에는 개별 벡터, HNSW 그래프 인덱스, 양자화된 벡터, 계산된 사분위수 등이 저장됩니다. 간결성을 위해 여기서는 Lucene이 정량화된 벡터와 원시 벡터를 저장하는 방식에 초점을 맞추겠습니다. 모든 세그먼트에 대해 파일의 원시 벡터, 양자화된 벡터 및 단일 보정 승수 플로트( ), 그리고 파일 내의 양자화 관련 메타데이터를 추적합니다.

그림 1: 원시 벡터 스토리지 파일의 단순화된 레이아웃. 값은 4바이트이므로 디스크 공간을 차지합니다. 정량화 중이므로 HNSW 검색 중에는 로드되지 않습니다. 특별히 요청된 경우에만 사용됩니다(예 재점수를 통한 무차별 대입) 또는 세그먼트 병합 중 재정량화를 위해 사용합니다.

그림 2: 단순화된 레이아웃 파일을 만듭니다. 공간을 차지하며 검색 중에 메모리에 로드됩니다. 정확도와 기억력을 높이기 위해 점수를 조정하는 데 사용되는 보정 승수 플로트를 설명하는 값입니다.

그림 3: 메타데이터 파일의 단순화된 레이아웃. 여기에서 이 세그먼트에 대해 계산된 사분위수와 함께 양자화 및 벡터 구성을 추적합니다.

따라서 각 세그먼트에 대해 양자화된 벡터뿐만 아니라 이러한 양자화된 벡터를 만드는 데 사용된 분위수와 원래의 원시 벡터를 저장합니다. 그렇다면 왜 원시 벡터를 보관하는 것일까요?

사용자와 함께 성장하는 정량화

Lucene은 주기적으로 읽기 전용 세그먼트를 플러시하기 때문에 각 세그먼트는 모든 데이터의 일부만 볼 수 있습니다. 즉, 전체 데이터의 해당 샘플 세트에 대해서만 계산된 사분위수가 직접 적용됩니다. 샘플이 전체 말뭉치를 적절히 대표한다면 큰 문제가 되지 않습니다. 하지만 Lucene을 사용하면 다양한 방식으로 인덱스를 정렬할 수 있습니다. 따라서 세그먼트별 사분위수 계산에 편향을 추가하는 방식으로 정렬된 데이터를 인덱싱할 수 있습니다. 또한 원할 때마다 데이터를 플러시할 수 있습니다! 샘플 세트는 하나의 벡터일 정도로 작을 수 있습니다. 또 다른 장점은 병합이 발생하는 시기를 제어할 수 있다는 점입니다. 기본값과 주기적 병합이 설정되어 있지만, _force_merge API를 통해 원할 때마다 병합을 요청할 수 있습니다. 그렇다면 어떻게 하면 이 모든 유연성을 허용하면서도 좋은 리콜을 제공하는 우수한 정량화를 제공할 수 있을까요?

루씬의 벡터 양자화는 시간이 지남에 따라 자동으로 조정됩니다. Lucene은 읽기 전용 세그먼트 아키텍처로 설계되었기 때문에 각 세그먼트의 데이터가 변경되지 않았음을 보장하고 업데이트가 가능한 시점을 코드에 명확하게 구분합니다. 즉, 세그먼트 병합 중에 필요에 따라 사분위수를 조정하고 벡터를 다시 정량화할 수 있습니다.

그림 4: 서로 다른 사분위수를 가진 세 가지 예시 세그먼트.

하지만 재정량화에는 비용이 많이 들지 않을까요? 약간의 오버헤드가 있긴 하지만, Lucene은 지능적으로 사분위수를 처리하고 필요한 경우에만 완전히 정량화합니다. 그림 4의 세그먼트를 예로 들어 보겠습니다. 세그먼트 각각 문서를, 세그먼트 문서만 제공한다고 가정해 보겠습니다. Lucene은 사분위수의 가중 평균을 취하고 그 결과 병합된 사분위수가 세그먼트의 원래 사분위수에 충분히 근접하면 해당 세그먼트를 다시 정량화할 필요가 없으며 새로 병합된 사분위수를 활용합니다.

그림 5: 세그먼트 문서가 있고 문서만 있는 병합된 사분위수의 예입니다.

그림 5에서 시각화된 상황을 보면 병합된 결과 사분위수가 원래 사분위수와 매우 유사하므로 벡터를 정량화하는 것이 정당화되지 않음을 알 수 있습니다. 세그먼트 , 너무 많이 벗어난 것 같습니다. 결과적으로 벡터는 새로 병합된 사분위수 값으로 다시 정량화됩니다.

실제로 병합된 사분위수가 원래의 사분위수와 극적으로 다른 극단적인 경우가 있습니다. 이 경우 각 세그먼트에서 샘플을 가져와서 사분위수를 완전히 다시 계산합니다.

정량화 성능 & 숫자

그렇다면 속도가 빠르며 여전히 좋은 기억력을 제공하나요? c3-standard-8 GCP 인스턴스에서 실험을 실행하여 수집한 수치는 다음과 같습니다. 공정한 비교를 위해 메모리에 원시 벡터를 저장할 수 있을 만큼 큰 인스턴스를 사용했습니다. 최대 내부 제품을 사용하여 Cohere Wiki 벡터를 색인화했습니다.

그림 6: 양자화된 벡터와 원시 벡터의 Recall@10. 양자화된 벡터의 검색 성능은 원시 벡터보다 훨씬 빠르며, 5개만 더 수집해도 리콜을 빠르게 복구할 수 있습니다( 표시).

그림 6은 그 이야기를 보여줍니다. 예상대로 리콜 차이가 있긴 하지만, 그 차이는 크지 않습니다. 그리고 벡터를 5개만 더 수집하면 리콜 차이가 사라집니다. 이 모든 것이 빠른 세그먼트 병합과 벡터의 1/4 메모리로 가능합니다.

결론

Lucene은 어려운 문제에 대한 고유한 솔루션을 제공합니다. 정량화에는 '훈련' 또는 '최적화' 단계가 필요하지 않습니다. Lucene에서는 그냥 작동합니다. 데이터가 바뀌어도 벡터 인덱스를 '다시 학습'해야 할 염려가 없습니다. Lucene은 중요한 변경 사항을 감지하고 데이터의 수명 기간 동안 이를 자동으로 처리합니다. 이 기능을 Elasticsearch에 언제 도입할지 기대해 주세요!

시스그로크의 기능은 무엇인가요?

시스그로크는 다음과 같은 작업을 수행할 수 있습니다:

• 프로파일러가 식별한 가장 비용이 많이 드는 상위 함수 및 프로세스를 가져와서 각각이 제공하는 기능을 설명하고 최적화를 제안합니다.

• 호스트와 호스트가 겪고 있는 문제에 대한 설명을 입력하면 자동으로 문제를 디버그하고 해결 방법 및 추가 조치를 제안합니다.

• 프로파일러가 주석을 단 소스 코드를 가져와서 핫 경로를 설명하고 코드의 성능을 개선할 수 있는 방법을 제안합니다.

시스그로크의 기능은 크게 세 가지 범주의 솔루션을 목표로 합니다:

1. 성능, 안정성 및 기타 시스템 관련 데이터를 위한 분석 엔진입니다. 이 모드에서는 엔지니어가 사용하는 다른 도구(예: Linux 명령줄 도구, 프로파일러 또는 Observability 플랫폼)의 출력이 LLM에 공급됩니다. sysgrok의 목표는 LLM을 사용하여 시스템 상태에 대한 해석, 요약 및 가설을 세우는 것입니다. 그런 다음 최적화 또는 해결 방법을 제안할 수도 있습니다.

2. 특정 성능 및 안정성 관련 작업을 위한 집중적이고 자동화된 솔루션입니다. 성능 엔지니어링 및 SRE 작업에는 반복적으로 발생하는 몇 가지 작업이 있습니다. 이를 위해 엔지니어가 직접 사용하거나 다른 문제를 해결하는 데 시스그로크 자체에서 사용할 수 있는 집중적이고 자동화된 어시스턴트를 구축할 수 있습니다. 예를 들어 성능 엔지니어링에서는 " "동등한 기능을 가진 이 라이브러리의 더 빠른 버전이 있나요?" "라는 질문에 답하는 것이 일반적입니다. sysgrok이 이를 직접 지원합니다.

3. 성능 및 안정성 문제에 대한 자동화된 근본 원인 분석 도구입니다. 앞의 두 가지 범주의 솔루션은 데이터 분석, 해석, 검색, 요약이 혼합된 솔루션입니다. 결정적으로, 엔지니어가 직접 수집한 데이터에 집중적인 방식으로 적용된다는 점이 특징입니다. sysgrok에서는 LLM을 다른 도구와 결합하여 주어진 문제의 근본 원인 분석 및 해결을 자율적으로 수행하는 LLM을 사용한 문제 해결에 대한 세 번째 접근 방식도 연구하고 있습니다. 이 접근 방식에서는 LLM에 문제 설명(예: "웹 서버에 높은 지연 시간이 발생함")과 함께 사용 가능한 기능(예: "호스트에 ssh," " 임의의 Linux 명령줄 도구 실행")을 알려줍니다. 그런 다음 LLM은 사용 가능한 기능을 사용하여 문제를 분류하기 위해 취해야 할 조치를 요청받습니다. 이러한 작업은 sysgrok에서 실행되며 LLM은 결과를 분석하고, 문제를 분류하고, 해결 방법을 제안하고, 다음 단계를 추천하도록 요청받습니다.

아직 초기 단계에 불과하지만 이미 다양한 작업에 유용하게 사용되고 있기 때문에 공개하는 것이며, 다른 사용자들도 비슷한 실험을 할 수 있는 편리한 기반이 되기를 바랍니다. 아이디어가 있으시면 언제든지 GitHub에 PR이나 오픈 이슈를 보내주세요!

LLM의 성능 문제 분석

OpenAI의 GPT 모델과 같은 LLM은 지난 몇 달 동안 폭발적인 인기를 끌며 고객 지원 채팅 봇부터 데이터 조작 지원, 코딩 지원까지 모든 종류의 제품에 자연어 인터페이스와 핵심 엔진을 제공했습니다. 이러한 추세의 흥미로운 측면은 이러한 모든 애플리케이션이 기본적으로 당면한 작업에 맞게 특별히 훈련되거나 미세 조정되지 않은 일반 모델을 사용한다는 점입니다. 대신 인터넷 전체에 대한 광범위한 학습을 거쳤기 때문에 다양한 업무에 적용할 수 있습니다.

그렇다면 이러한 모델을 활용하여 성능 분석, 디버깅 및 최적화에 도움을 받을 수 있을까요? 성능 문제를 조사하고, 근본 원인을 분류하고, 최적화 방안을 마련하는 데는 다양한 방법론이 있습니다. 하지만 모든 성능 분석 작업의 핵심은 Linux 명령줄 도구나 통합 가시성 플랫폼과 같은 다양한 도구의 출력을 살펴보고 그 출력을 해석하여 시스템 상태에 대한 가설을 세우는 것입니다. GPT 모델이 학습한 자료 중에는 소프트웨어 엔지니어링, 디버깅, 인프라 분석, 운영 체제 내부, Kubernetes, Linux 명령 및 그 사용법, 성능 분석 방법론을 다루는 소스가 포함되어 있습니다. 결과적으로 이 모델을 사용하여 성능 엔지니어가 일상적으로 직면하는 데이터와 문제를 요약, 해석, 가설을 세울 수 있으므로 엔지니어가 분석을 진행하는 속도가 빨라질 수 있습니다.

하지만 여기서 더 나아가 엔지니어의 자체 조사 프로세스의 맥락에서 데이터 분석과 질문에 대한 답변에만 LLM을 사용하는 것에서 더 나아갈 수 있습니다. 이 글의 뒷부분에서 설명하겠지만, 일부 시나리오에서는 LLM 자체를 사용하여 프로세스를 구동할 수 있으며, 문제를 디버깅하기 위해 실행할 명령이나 살펴볼 데이터 소스를 결정할 수도 있습니다.

데모

sysgrok이 지원하는 전체 기능 집합은 GitHub 리포지토리에서 확인하세요. 크게 세 가지 문제 해결 방식을 지원합니다:

접근 방식 1: 성능, 안정성 및 기타 시스템 관련 데이터를 위한 분석 엔진으로서

이 모드에서는 Linux 명령줄 도구, 프로파일러 또는 통합 가시성 플랫폼과 같이 엔지니어가 사용 중인 다른 도구의 출력이 LLM에 공급됩니다. 시스그로크의 목표는 해석, 요약 및 해결책을 제시하는 것입니다.

예를 들어, topn 하위 명령은 프로파일러가 보고한 가장 비싼 상위 함수를 가져와서 출력을 설명한 다음 시스템을 최적화하는 방법을 제안합니다.

이 동영상은 sysgrok에서 제공하는 채팅 기능도 보여줍니다. 채팅 인수를 제공하면 sysgrok은 LLM의 각 응답 후에 채팅 세션으로 이동합니다.

이 기능은 Linux 명령줄 도구의 출력에도 일반적으로 적용할 수 있습니다. 예를 들어, 60초 안에 Linux 성능 분석이라는 문서에서 Brendan Gregg는 성능 또는 안정성 문제가 있는 호스트에 처음 연결할 때 SRE가 실행해야 하는 10가지 명령에 대해 설명합니다. analyzecmd 하위 명령은 연결할 호스트와 실행할 명령을 입력으로 받은 다음 사용자를 위해 명령의 출력을 분석하고 요약합니다. 이를 통해 Gregg가 설명한 프로세스를 자동화하고 10개의 명령어로 생성된 모든 데이터를 한 문단으로 요약하여 사용자에게 제공함으로써 사용자가 명령어의 출력을 일일이 확인해야 하는 번거로움을 줄일 수 있습니다.

접근 방식 2: 특정 성능 및 안정성 관련 작업에 대한 집중적이고 자동화된 솔루션으로서

성능 엔지니어링 및 SRE 작업에는 반복적으로 발생하는 몇 가지 작업이 있습니다. 이를 위해 엔지니어가 직접 사용하거나 시스그로크 자체에서 다른 문제를 해결하는 데 사용할 수 있는 집중적이고 자동화된 어시스턴트를 구축할 수 있습니다.

예를 들어 findfaster 하위 명령은 라이브러리 또는 프로그램의 이름을 입력으로 받아 LLM을 사용하여 이를 대체할 수 있는 더 빠르고 동등한 대체물을 찾습니다. 이는 성능 엔지니어링에서 매우 일반적인 작업입니다.

이 접근 방식의 또 다른 예는 sysgrok의 설명 함수 하위 명령입니다. 이 하위 명령은 라이브러리의 이름과 해당 라이브러리 내의 함수를 사용합니다. 라이브러리가 하는 일과 일반적인 사용 사례를 설명한 다음 기능을 설명합니다. 마지막으로 해당 라이브러리와 함수가 상당한 양의 CPU 리소스를 소비하는 경우 가능한 최적화를 제안합니다.

접근 방식 3: 성능 및 안정성 문제에 대한 자동화된 근본 원인 분석 도구로서

LLM의 사용은 집중적인 질문 답변, 요약 및 이와 유사한 작업에만 국한되지 않습니다. 또한 단 한 번의 고립된 질문이 주어지는 원샷 사용으로 제한되지 않습니다. sysgrok debughost 하위 명령은 자동화된 문제 해결을 목표로 에이전트에서 LLM을 "두뇌" 로 사용하는 방법을 보여 줍니다. 이 모드에서는 LLM을 사용하여 특정 문제를 디버깅하는 방법을 결정하고 호스트에 연결하고 명령을 실행하며 다른 데이터 소스에 액세스할 수 있는 기능을 제공하는 프로세스 내에 LLM이 포함됩니다.

디버그 호스트 명령은 아마도 현재 sysgrok에서 가장 실험적인 부분일 것입니다. 이는 성능 분석을 위한 자동화된 에이전트로 가는 길의 한 단계를 보여 주지만, 거기에 도달하기 위해서는 상당한 양의 R&D가 필요합니다.

결론

이 게시물에서는 시스템을 분석, 이해 및 최적화하기 위한 새로운 오픈 소스 AI 어시스턴트인 sysgrok을 소개해 드렸습니다. 또한 시스그로크가 구현하는 세 가지 접근 방식에 대해서도 설명했습니다:

1. 성능, 안정성 및 기타 시스템 관련 데이터를 위한 분석 엔진입니다: topn, stacktrace, analyzecmd 및 code 하위 명령을 참조하세요.

2. 특정 성능 및 안정성 관련 작업에 대한 집중적이고 자동화된 솔루션입니다: 설명 프로세스, 설명 기능 및 더 빠른 찾기 하위 명령을 참조하세요.

3. 성능 및 안정성 문제에 대한 자동화된 근본 원인 분석: 디버그 호스트 하위 명령을 참조하세요.

sysgrok 프로젝트는 GitHub에서 찾을 수 있습니다. 홍보 및 이슈를 자유롭게 작성하거나 프로젝트 또는 LLM 전반에 대해 논의하고 싶은 경우 sean.heelan@elastic.co 으로 직접 문의해 주세요.

시작점

Elasticsearch의 첫 번째 버전은 2010년에 사용자가 중요한 인사이트를 빠르게 검색하고 표시할 수 있는 분산 확장형 검색 엔진으로 출시되었습니다. 12년이 지나고 65,000개 이상의 커밋이 이루어진 후에도 Elasticsearch는 사용자에게 다양한 검색 문제에 대한 실전에서 검증된 솔루션을 계속 제공하고 있습니다. 수백 명의 정규직 Elastic 직원을 포함해 1,500명이 넘는 기여자들의 노력 덕분에 Elasticsearch는 검색 분야에서 발생하는 새로운 과제를 해결하기 위해 끊임없이 발전해 왔습니다.

데이터 손실에 대한 우려가 제기된 Elasticsearch 출시 초기에 Elastic 팀은 인정된 데이터가 안전하게 저장되도록 클러스터 조정 시스템을 재작성하기 위해 다년간의 노력을 기울였습니다. 대규모 클러스터에서 인덱스를 관리하는 것이 번거롭다는 것이 분명해지자, 팀은 사용자가 인덱스 패턴과 수명 주기 작업을 미리 정의하여 이 작업을 자동화할 수 있는 광범위한 ILM 솔루션을 구현하기 위해 노력했습니다. 사용자들이 상당한 양의 메트릭 및 시계열 데이터를 저장할 필요성을 느끼면서 데이터 크기를 줄이기 위해 더 나은 압축 등 다양한 기능이 추가되었습니다. 방대한 양의 콜드 데이터를 검색하는 데 드는 스토리지 비용이 증가함에 따라 저비용 개체 저장소에서 사용자 데이터를 직접 검색할 수 있는 방법으로 검색 가능한 스냅샷을 만드는 데 투자했습니다.

이러한 투자는 Elasticsearch의 다음 진화를 위한 토대를 마련합니다. 클라우드 네이티브 서비스와 새로운 오케스트레이션 시스템이 성장함에 따라, 우리는 클라우드 네이티브 시스템으로 작업할 때의 경험을 개선하기 위해 Elasticsearch를 발전시켜야 할 때라고 판단했습니다. 이러한 변화는 Elastic Cloud에서 Elasticsearch를 실행하면서 운영, 성능 및 비용을 개선할 수 있는 기회를 제공한다고 생각합니다.

우리가 나아갈 방향 - 무국적 아키텍처 채택

Elasticsearch를 운영하거나 오케스트레이션할 때의 주요 과제 중 하나는 수많은 영구 상태 조각에 의존하기 때문에 상태 저장 시스템이라는 점입니다. 세 가지 주요 요소는 번역, 인덱스 저장소, 클러스터 메타데이터입니다. 이 상태는 스토리지가 영구적이어야 하며 노드를 다시 시작하거나 교체하는 동안 손실되지 않아야 함을 의미합니다.

Elastic Cloud의 기존 Elasticsearch 아키텍처는 중단 시 중복성을 제공하기 위해 여러 가용성 영역에 걸쳐 인덱싱을 복제해야 합니다. 이 데이터의 지속성을 로컬 디스크에서 AWS S3와 같은 객체 저장소로 옮길 계획입니다. 이 데이터를 저장하기 위해 외부 서비스에 의존함으로써 인덱싱 복제의 필요성을 없애고 수집과 관련된 하드웨어를 크게 줄일 수 있습니다. 또한 이 아키텍처는 AWS S3, GCP 클라우드 스토리지, Azure Blob 스토리지와 같은 클라우드 개체 저장소가 가용 영역 간에 데이터를 복제하는 방식 덕분에 매우 높은 내구성을 보장합니다.

인덱스 저장소를 외부 서비스로 오프로드하면 인덱싱과 검색 책임을 분리하여 Elasticsearch를 다시 설계할 수도 있습니다. 기본 인스턴스와 복제 인스턴스가 두 워크로드를 모두 처리하는 대신, 인덱싱 티어와 검색 티어를 만들려고 합니다. 이러한 워크로드를 분리하면 독립적으로 확장할 수 있고 하드웨어를 각 사용 사례에 맞게 더 세분화하여 선택할 수 있습니다. 또한 검색과 색인 부하가 서로 영향을 미칠 수 있는 오랜 문제를 해결하는 데 도움이 됩니다.

수개월에 걸친 개념 증명과 실험 단계를 거친 결과, 이러한 개체 저장소 서비스가 인덱스 스토리지와 클러스터 메타데이터에 대해 우리가 구상하는 요구 사항을 충족한다고 확신하게 되었습니다. 테스트와 벤치마크 결과, 이러한 스토리지 서비스는 Elastic Cloud에서 본 최대 규모의 클러스터의 높은 인덱싱 요구 사항을 충족할 수 있는 것으로 나타났습니다. 또한 개체 저장소에 데이터를 백업하면 인덱싱 비용이 절감되고 검색 성능을 간단하게 조정할 수 있습니다. 데이터를 검색하기 위해 Elasticsearch는 데이터가 클라우드 네이티브 개체 저장소에 영구적으로 보존되고 로컬 디스크가 자주 액세스하는 데이터의 캐시로 사용되는, 수많은 테스트를 거친 검색 가능한 스냅샷 모델을 사용합니다.

차별화를 위해 기존 모델을 "노드 간" 복제라고 설명합니다. 이 모델의 핫 티어에서는 기본 샤드와 복제 샤드 모두 수집을 처리하고 검색 요청을 제공하기 위해 동일한 작업을 수행합니다. 이러한 노드는 로컬 디스크에 의존하여 호스팅하는 샤드의 데이터를 안전하게 유지한다는 점에서 "stateful" 입니다. 또한 기본 샤드와 복제 샤드는 동기화 상태를 유지하기 위해 지속적으로 통신합니다. 이는 기본 샤드에서 수행된 작업을 복제 샤드로 복제하는 방식으로 이루어지며, 이는 지정된 각 복제본에 대해 해당 작업의 비용(주로 CPU)이 발생한다는 의미입니다. 수집을 위해 이 작업을 수행하는 동일한 샤드와 노드가 검색 요청도 처리하므로 프로비저닝과 확장은 두 가지 워크로드를 모두 염두에 두고 수행해야 합니다.

노드 간 복제 모델의 샤드는 검색 및 수집 외에도 Lucene 세그먼트 병합과 같은 다른 집중적인 작업을 처리합니다. 이러한 설계에도 장점이 있지만, 수년 동안 고객과 함께 배운 점과 광범위한 클라우드 에코시스템의 진화를 바탕으로 많은 기회를 발견했습니다.

새로운 아키텍처를 통해 다음과 같은 많은 즉각적인 개선과 향후 개선이 가능합니다:

1. 동일한 하드웨어에서 수집 처리량을 크게 늘리거나, 다른 방식으로 말하면 동일한 수집 워크로드의 효율성을 크게 개선할 수 있습니다. 이러한 증가는 모든 복제본에 대한 인덱싱 작업의 중복을 제거한 결과입니다. CPU 집약적인 인덱싱 작업은 인덱싱 계층에서 한 번만 수행하면 결과 세그먼트를 오브젝트 저장소로 전송합니다. 이제 검색 계층에서 데이터를 그대로 사용할 수 있습니다.

2. 컴퓨팅과 스토리지를 분리하여 클러스터 토폴로지를 간소화할 수 있습니다. 현재 Elasticsearch는 데이터를 하드웨어 프로필과 일치시키기 위해 여러 데이터 계층(콘텐츠, hot, warm, cold, frozen)을 갖추고 있습니다. 핫 티어는 실시간에 가까운 검색을 위한 것이고, 프로즌은 검색 빈도가 낮은 데이터를 위한 것입니다. 이러한 계층은 가치를 제공하지만 복잡성을 증가시키기도 합니다. 새로운 아키텍처에서는 데이터 계층이 더 이상 필요하지 않으므로 Elasticsearch의 구성과 운영이 간소화됩니다. 또한 인덱싱과 검색을 분리하여 복잡성을 더욱 줄이고 두 워크로드를 독립적으로 확장할 수 있도록 하고 있습니다.

3. 로컬 디스크에 저장해야 하는 데이터의 양을 줄임으로써 인덱싱 계층의 스토리지 비용을 개선할 수 있습니다. 현재 Elasticsearch는 인덱싱을 위해 핫 노드(기본 및 복제본 모두)에 전체 샤드 복사본을 저장해야 합니다. 오브젝트 저장소에 직접 인덱싱하는 상태 비저장 방식에서는 해당 로컬 데이터의 일부만 필요합니다. 추가 전용 사용 사례의 경우 인덱싱을 위해 특정 메타데이터만 저장하면 됩니다. 이렇게 하면 인덱싱에 필요한 로컬 저장 공간을 크게 줄일 수 있습니다.

4. 검색 쿼리와 관련된 스토리지 비용을 절감할 수 있습니다. 검색 가능한 스냅샷 모델을 데이터 검색의 기본 모드로 설정하면 검색 쿼리와 관련된 스토리지 비용이 크게 감소합니다. 사용자의 검색 대기 시간 요구 사항에 따라 Elasticsearch는 자주 요청되는 데이터에 대한 로컬 캐싱을 늘리도록 조정할 수 있습니다.

벤치마킹 - 75% 인덱싱 처리량 개선

이 접근 방식을 검증하기 위해 단일 노드에서만 데이터를 인덱싱하고 클라우드 개체 저장소를 통해 복제를 수행하는 광범위한 개념 증명을 구현했습니다. 인덱싱 복제에 전용 하드웨어를 사용할 필요가 없어짐으로써 인덱싱 처리량을 75%(% ) 향상시킬 수 있다는 사실을 발견했습니다. 또한, 단순히 개체 저장소에서 데이터를 가져오는 것과 관련된 CPU 비용은 오늘날 핫 티어에 필요한 것처럼 데이터를 인덱싱하고 로컬에 쓰는 것보다 훨씬 낮았습니다. 즉, 검색 노드는 CPU를 검색에 전적으로 사용할 수 있게 됩니다.

이러한 성능 테스트는 3대 퍼블릭 클라우드 제공업체(AWS, GCP, Azure) 모두에 대해 2노드 클러스터에서 수행되었습니다. 프로덕션 상태 비저장 구현을 추진하면서 더 큰 규모의 벤치마크를 계속 구축할 계획입니다.

인덱싱 처리량

CPU 사용량

우리는 무국적자, 당신은 절약

Elastic Cloud의 상태 저장소 없는 아키텍처를 사용하면 색인 오버헤드를 줄이고, 수집과 검색을 독립적으로 확장하며, 데이터 계층 관리를 간소화하고, 확장이나 업그레이드와 같은 운영을 가속화할 수 있습니다. 이것은 Elastic Cloud 플랫폼의 실질적인 현대화를 향한 첫 번째 이정표입니다.

Elasticsearch 상태 저장소 없는 비전의 일부가 되세요.

다른 사람들보다 먼저 이 솔루션을 사용해보고 싶으신가요? 토론이나 커뮤니티 슬랙 채널에서 문의하실 수 있습니다. 새로운 아키텍처의 방향을 설정하는 데 도움이 되는 여러분의 피드백을 기다립니다.

배경

Elasticsearch를 개발하는 동안, 우리는 때때로 이를 해결하기 위한 간단하거나 확립된 접근 방식이 없는 중요한 문제에 직면하게 됩니다. "흠, 이 문제를 다룬 학술 논문이 있나요?"라고 묻는 것은 당연한 질문입니다. 때로는 학문적 연구가 영감의 원천이 되기도 합니다. 새로운 알고리즘이나 데이터 구조를 제안하는 논문을 접하고 "정말 유용할 것 같다!"라고 생각하게 됩니다. 다음은 Elasticsearch와 Apache Lucene이 학술 작업을 통합하는 방법의 몇 가지 예입니다:

• 카디널리티 집계를 위한 HyperLogLog++

• 적응형 복제본 선택을 위한 C3 알고리즘

• 루씬에서 가장 가까운 벡터 검색을 위한 계층적 탐색 가능한 작은 세계 그래프(HNSW)

• 머신 러닝 분류를 개선하기위한 MIC 통계

• Lucene에서 더 빠른 인기 검색을 위한블록 최대 WAND

• ... 그리고 더 많은 것

학술 논문은 데이터 집약적인 시스템을 개발하는 엔지니어에게 매우 귀중한 자료입니다. 그러나 알고리즘 설명이 복잡하고 중요한 실용적인 세부 사항이 생략된 경우가 많아 구현하기가 어렵고 오류가 발생하기 쉽습니다. 예를 들어, 데이터 세트에 따라 결과가 크게 달라지는 머신 러닝 알고리즘을 어떻게 철저하게 테스트할 수 있을까요?

소프트웨어 종속성을 평가할 때와 마찬가지로 논문을 평가하세요.

새 소프트웨어 종속성을 추가하려면 신중한 평가가 필요합니다. 다른 패키지가 부정확하거나 느리거나 안전하지 않은 경우 우리 프로젝트도 마찬가지일 수 있기 때문입니다. 개발자는 종속성을 가져오기 전에 종속성의 품질을 평가해야 합니다.

구현을 고려 중인 학술 논문에도 동일하게 적용됩니다. 알고리즘이 논문에 발표되었기 때문에 정확하고 성능이 좋아야 한다고 생각할 수 있습니다. 그러나 검토 과정을 통과했더라도 학술 논문에는 문제가 있을 수 있습니다. 정확성 증명은 현실적이지 않은 가정에 의존하는 것일 수도 있습니다. 또는 '실험' 섹션에서 기준선보다 훨씬 더 나은 성능을 보여 주지만 이는 특정 데이터 세트에만 해당됩니다. 논문 품질이 뛰어나더라도 그 접근 방식이 프로젝트에 적합하지 않을 수 있습니다.

학술 논문에 대한 '의존성' 여부를 고려할 때는 소프트웨어 패키지에 대해 동일한 질문을 하는 것이 도움이 됩니다:

• 라이브러리가 널리 사용되고 '실전 테스트'를 거쳤나요? → 다른 패키지에서 이 문서를 구현한 적이 있으며 잘 작동했나요?

• 성능 벤치마크가 제공되나요? 정확하고 공정해 보이나요? → 논문에 실제 실험이 포함되어 있나요? 디자인이 잘 되어 있나요?

• 성능 개선이 복잡성을 정당화할 만큼 충분히 큰가요? → 논문이 강력한 기준 접근 방식과 비교되나요? 이 기준선을 얼마나 능가하나요?

• 이 접근 방식이 우리 시스템과 잘 통합되나요? → 알고리즘의 가정과 트레이드오프가 우리 사용 사례에 맞는가?

소프트웨어 패키지가 경쟁사와의 성능 비교를 발표할 때 항상 가장 빠르게 나오는 패키지가 있습니다! 제3자가 벤치마크를 설계했다면 더 균형 잡힌 결과를 얻을 수 있습니다. 학술 논문에도 동일한 현상이 적용됩니다. 알고리즘이 원본 논문에서 좋은 성능을 보였을 뿐만 아니라 다른 논문에서도 강력한 기준이 되는 것으로 나타난다면 그 알고리즘은 견고할 가능성이 매우 높습니다.

창의적으로 테스트하기

학술 논문의 알고리즘은 우리가 일상적으로 접하는 알고리즘 유형보다 더 정교한 동작을 하는 경우가 많습니다. 아마도 더 나은 속도를 위해 정확도를 희생하는 근사 알고리즘일 것입니다. 또는 대규모 데이터 세트를 받아 (때로는 예상치 못한) 결과를 생성하는 머신 러닝 방법일 수도 있습니다. 이러한 알고리즘의 동작을 간단한 방법으로 특성화할 수 없다면 어떻게 테스트를 작성할 수 있을까요?

불변값에 집중

단위 테스트를 설계할 때 알고리즘에 이 예제 입력을 제공하면 해당 출력을 가져야 한다는 식으로 예제 측면에서 생각하는 것이 일반적입니다. 안타깝게도 대부분의 수학 알고리즘은 예제 기반 테스트만으로는 그 동작을 충분히 커버할 수 없습니다.

Elasticsearch가 검색 요청을 처리할 노드를 파악하는 데 사용하는 C3 알고리즘을 살펴보겠습니다. 노드의 이전 서비스 및 응답 시간, 대기열 크기를 통합하는 미묘한 공식을 사용하여 각 노드의 순위를 매깁니다. 몇 가지 예를 테스트한다고 해서 공식을 제대로 이해했는지 확인할 수 있는 것은 아닙니다. 서비스 시간이 증가하면 노드의 순위가 감소하는가? 등 한 발 물러서서 불변성 테스트에 대해 생각해 보는 것도 도움이 됩니다. 대기열 크기가 0인 경우, 논문에서 주장한 것처럼 응답 시간에 따라 순위가 결정되나요?

불변값에 집중하면 여러 가지 일반적인 경우에 도움이 될 수 있습니다:

• 이 방법은 순서에 구애받지 않아야 하나요? 그렇다면 입력 데이터를 다른 순서로 전달해도 동일한 출력을 얻을 수 있습니다.

• 알고리즘의 어떤 단계가 클래스 확률을 생성하나요? 그렇다면 이 확률의 합계는 1이 되어야 합니다.

• 함수가 원점을 중심으로 대칭인가요? 그렇다면 입력의 부호를 뒤집으면 출력의 부호도 뒤집히게 됩니다.

C3를 처음 구현할 때 응답 시간 대신 응답 시간의 역수를 실수로 사용하는 공식에 버그가 있었습니다. 이는 느린 노드가 더 높은 순위를 차지할 수 있다는 것을 의미했습니다! 문제를 수정할 때 향후 실수를 방지하기 위해 불변 확인을 추가했습니다.

레퍼런스 구현과 비교

저자들은 논문과 함께 알고리즘의 구현을 공개할 예정입니다. (많은 저널에서 저자가 결과 재현을 위한 코드를 게시하도록 요구하기 때문에 논문에 실험이 포함된 경우 특히 그렇습니다.) 이 참조 구현과 비교하여 접근 방식을 테스트하여 알고리즘의 중요한 세부 사항을 놓치지 않았는지 확인할 수 있습니다.

가장 가까운 이웃 검색을 위한 Lucene의 HNSW 구현을 개발하는 동안, 논문 저자의 참조 라이브러리와 비교하여 테스트했습니다. 동일한 데이터 세트에 대해 Lucene과 라이브러리를 모두 실행하여 결과의 정확도와 수행한 계산 횟수를 비교했습니다. 이 수치가 거의 일치하면 Lucene이 알고리즘을 충실히 구현한다는 것을 알 수 있습니다.

알고리즘을 시스템에 통합할 때는 여러 코어로 확장하거나 휴리스틱을 추가하여 성능을 개선하는 등 수정 또는 확장을 해야 하는 경우가 많습니다. 먼저 "바닐라" 버전을 구현하고 레퍼런스와 비교하여 테스트한 다음 점진적으로 변경하는 것이 가장 좋습니다. 이렇게 하면 사용자 지정하기 전에 모든 핵심 부분을 캡처했다고 확신할 수 있습니다.

기존 알고리즘과의 결투

마지막 섹션에서는 테스트 불변수에 대한 또 다른 아이디어를 제시합니다. 알고리즘의 출력을 더 간단하고 이해하기 쉬운 알고리즘의 출력과 비교하는 것입니다. 예를 들어, 상위 결과에 표시되지 않는 문서를 건너뛰어 문서 검색 속도를 높여주는 Lucene의 블록 최대 WAND 알고리즘을 생각해 보세요. 모든 경우에 블록맥스 WAND가 어떻게 작동해야 하는지 정확히 설명하기는 어렵지만, 적용한다고 해서 상위 결과가 바뀌지는 않는다는 것은 알고 있습니다! 따라서 테스트에서는 여러 개의 무작위 검색 쿼리를 생성한 다음 WAND 최적화를 적용하거나 적용하지 않은 상태에서 실행하여 결과가 항상 일치하는지 확인할 수 있습니다.

이러한 테스트의 중요한 측면은 비교를 실행하기 위해 무작위 입력을 생성한다는 것입니다. 이를 통해 생각하지 못했던 사례를 연습하고 예상치 못한 문제를 발견할 수 있습니다. 예를 들어, BM25F 채점에 대한 Lucene의 무작위 비교 테스트는 미묘한 에지 케이스에서 버그를 발견하는 데 도움이 되었습니다. 알고리즘에 무작위 입력을 공급하는 아이디어는 컴퓨터 보안의 일반적인 테스트 기법인 퍼징 개념과 밀접한 관련이 있습니다.

Elasticsearch와 Lucene은 이 테스트 접근 방식을 자주 사용합니다. 두 알고리즘(TestDuelingAnalyzers, testDuelTermsQuery...) 간에 "결투" 를 언급하는 테스트가 표시되면 이 전략이 실행 중인 것입니다.

논문 용어 사용

다른 개발자가 여러분의 코드를 작업할 때는 해당 문서를 참조하여 세부 사항을 따라야 합니다. Elasticsearch의 HyperLogLog++ 구현에 대한 코멘트가 이를 잘 설명해줍니다: "논문을 읽지 않고 이 클래스가 하는 일을 이해하려고 하는 것은 모험적인 일로 간주됩니다." 이 메서드 주석도 좋은 예가 됩니다. 여기에는 학술 논문 링크가 포함되어 있으며, 원래 설명된 알고리즘에 어떤 수정 사항이 있었는지 강조 표시되어 있습니다.

개발자는 문서를 기반으로 코드를 이해하게 되므로 동일한 용어를 사용하는 것이 도움이 됩니다. 수학적 표기는 간결하기 때문에 일반적으로 '좋은 스타일'로 간주되지 않지만 논문의 맥락에서는 매우 명확한 이름이 될 수 있습니다. 학술 논문의 공식은 rS, muBarSInverse와 같은 암호화된 변수 이름을 Elasticsearch에서 접하게 되는 몇 안 되는 경우 중 하나입니다.

저자가 추천하는 논문 읽기 방법: 큰 커피와 함께.

작성자에게 이메일을 보낼 수 있습니다.

어려운 논문을 작성하다 보면 공식을 잘못 이해한 건지, 오타가 있는 건지 몰라 몇 시간 동안 고민할 때가 있습니다. 오픈 소스 프로젝트인 경우 GitHub 또는 StackOverflow에서 질문할 수 있습니다. 그렇다면 학술 논문은 어디에서 구할 수 있을까요? 작성자는 바빠 보이고 이메일에 짜증이 날 수 있습니다.

오히려 많은 학자들이 자신의 아이디어가 실용화되고 있다는 소식을 듣고 기뻐하며 이메일을 통해 기꺼이 질문에 답변해 줍니다. 그들이 잘 알고 있는 제품이라면 웹사이트에 애플리케이션을 등록할 수도 있습니다!

또한 학계에서 소프트웨어 개발과 동일한 많은 도구를 사용하여 공개적으로 논문을 토론하는 경향이 증가하고 있습니다. 문서에 소프트웨어 패키지가 함께 제공되는 경우 Github에서 일반적인 질문에 대한 답변을 찾을 수 있습니다. "이론적 컴퓨터 과학" 및 "교차 검증"과 같은 Stack Exchange 커뮤니티에는 인기 있는 논문에 대한 자세한 토론도 포함되어 있습니다. 일부 학회에서는 모든 논문 리뷰를 온라인으로 게시하기 시작했습니다. 이 리뷰에는 접근 방식에 대한 유용한 인사이트를 얻을 수 있는 저자와의 주고받는 토론이 포함되어 있습니다.

계속하기

이 게시물에서는 학술 논문 선택의 기본 사항에 중점을 두고 다음과 같이 설명합니다.

를 올바르게 구현하는 방법을 설명하지만 실제로 알고리즘을 배포하는 모든 측면을 다루지는 않습니다. 예를 들어 알고리즘이 복잡한 시스템에서 하나의 구성 요소에 불과한 경우 구성 요소의 변경이 엔드투엔드 개선으로 이어지도록 하려면 어떻게 해야 할까요? 알고리즘을 통합하는 과정에서 원본 논문에서 다루지 않은 상당한 수정이나 확장이 필요하다면 어떻게 해야 할까요? 이러한 주제는 향후 포스팅에서 더 많이 공유하고자 하는 중요한 주제입니다.