신규 사용자에게 이는 고품질 벡터 검색을 실행할 수 있는 가장 빠른 방법입니다. 이미 Elasticsearch를 사용 중인 경우, 별도의 시스템을 도입하지 않아도 새로운 기능을 통해 데이터가 이미 존재하는 플랫폼에서 바로 벡터 검색을 이용할 수 있습니다. Elasticsearch 벡터 데이터베이스는 대규모 언어 모델(LLM)의 기반 구축부터 AI 에이전트에 검색 및 메모리 기능 제공, 수천억 개의 벡터 처리에 이르기까지 다양한 시나리오를 지원합니다. 새 프로젝트를 생성하고 몇 분 안에 시작해 보세요.

하나의 엔진, 모든 벡터 사용 사례

Elasticsearch 벡터 데이터베이스는 벡터를 사용하여 애플리케이션을 구축하는 모든 사용자를 위해 구축되었습니다.

• RAG: 밀집 및 희소 벡터 검색으로 LLM에 적합한 컨텍스트를 검색하거나, 벡터 검색과 어휘 검색을 모두 결합한 하이브리드 검색을 사용하십시오. 생성 품질은 검색 품질에 따라 향상됩니다.

• AI 에이전트: 다단계 에이전트 루프에서 요구하는 짧은 지연 시간으로 문서 및 대화 메모리에 대한 빠르고 필터링된 검색 기능을 에이전트에 제공하세요.

• 시맨틱 검색: 파이프라인 코드 없이 단 하나의 필드 유형으로 키워드가 아닌 의미를 기반으로 매칭합니다.

• 추천 및 유사성: 제품, 이미지 또는 보유한 모든 콘텐츠 전반에서 대규모로 최근접 이웃을 찾습니다.

벡터 워크로드에 필요한 모든 것을 기본 최적화 상태로 제공

벡터 기반 애플리케이션을 구축하려면 여러 개의 개별 요소를 연결해야 합니다. 즉, 임베딩 모델을 설정하고 호스팅하며, 이를 통해 문서를 색인하고, 벡터를 효율적으로 저장하고, 각 쿼리에 임베딩 모델을 적용하고, 벡터 저장소와 일치시키고, 마지막으로 일치 항목에 해당하는 문서를 검색해야 합니다. Elasticsearch 벡터 데이터베이스는 추가 구성이나 설정 없이 이 모든 작업을 처리합니다.

vectordb_document 인덱스 모드를 사용한 벡터 색인

vectordb_document 인덱스 모드는 벡터 우선 워크로드를 위해 특별히 설계된 새로운 인덱스 구성으로, 기본적으로 활성화되어 있으므로 전문가가 선택할 설정을 사용할 수 있습니다. 활성화되는 기능은 다음과 같습니다.

• 기본적으로 bfloat16 적용: 벡터는 재현율에 거의 영향을 주지 않으면서 float32의 절반 크기로 저장되므로, 양자화를 적용하기 전부터 디스크 사용 공간을 대략 절반으로 줄여 줍니다.

• 소스 벡터 제외: Elasticsearch에서는 임베딩이 이미 검색에 사용되는 인덱스 구조에 존재하므로, _source에 두 번째 원시 사본을 보관하는 것은 저장 공간을 늘리고 결과를 가져오는 속도를 늦출 뿐입니다. 중복을 제외하여 응답이 더 빠르게 반환되며 저장하는 양도 줄어듭니다.

• 적절한 파일을 캐시에 미리 로드: 벡터 쿼리가 가장 먼저 사용하는 데이터 구조를 미리 메모리에 워밍업하므로 첫 번째 쿼리부터 천 번째 쿼리까지도 번개처럼 빠르게 실행됩니다.

• 병렬 병합: 병합을 통해 세그먼트가 더 체계적인 벡터 구조로 통합되므로 재현율과 지연 시간이 모두 개선되며, 이러한 병합을 멀티스레드로 실행하면 더 빠르게 도달할 수 있습니다.

벡터 저장 공간, 압축 및 자동 튜닝

• 벡터가 자동으로 압축됩니다. 더 나은 이진 양자화(BBQ)는 재현율을 유지하면서 벡터 메모리 공간을 최대 32배까지 줄이고, DiskBBQ는 대규모 워크로드의 메모리 요구 사항을 더욱 줄여줍니다. 

• 자동 보정을 선택하면 각 세그먼트의 양자화가 데이터에 맞게 조정되고, 데이터가 변화함에 따라 병합할 때마다 다시 조정됩니다. 18개 데이터 세트에서 테스트한 결과, 초당 쿼리 수(QPS)는 평균 16.7% 향상되었으며 대부분의 데이터 세트에서 재현율도 개선되었습니다.

관리형 GPU 추론 기반 임베딩

• 기본 Jina AI 임베딩 및 순위 재지정 모델로 임베딩을 생성하거나, 모델 서버를 운영할 필요 없이 Elastic Inference Service(EIS)를 통해 관리형 GPU에서 타사 모델을 가져오세요. 자체 모델을 선호하신다면 자체 호스팅도 가능합니다.

• semantic_text 필드 유형은 청킹 및 임베딩과 함께 쿼리를 자동으로 처리하므로, 시장에서 시맨틱 검색으로 가는 가장 간단한 경로입니다. 

하이브리드 검색 및 필터링된 벡터 검색

• 하이브리드 검색이 기본 제공되어 단일 쿼리에서 전체 텍스트 검색과 벡터 검색을 결합할 수 있습니다. 상호 순위 결합(RRF) 또는 원하는 다른 결합 메커니즘을 사용하여 결과를 혼합할 수 있습니다. 벡터 검색은 일반적으로 하이브리드 검색에서 제대로 구성하기 가장 까다로운 부분입니다. Elasticsearch 벡터 데이터베이스를 사용하면 이 문제를 쉽게 해결할 수 있으며 전체 하이브리드 스택이 더욱 향상됩니다. 

• 필터링된 벡터 검색을 사용하면 재현율을 저하시키는 사후 처리가 아니라 벡터 검색 자체의 일부로 메타데이터 필터를 적용할 수 있습니다.

첫날부터 엔터프라이즈

또한 역할 기반 액세스 제어(RBAC), 감사 로깅, 순수 벡터 데이터베이스에는 일반적으로 부족한 규정 준수 인증도 이용할 수 있습니다.

확장 시에도 경제적이고 예측 가능

Elasticsearch 벡터 데이터베이스는 규모가 확장되어도 경제적인 비용을 유지하도록 구축되었습니다. 저장 공간을 선형적으로 유지하고 메모리 사용량을 낮게 유지하는 BBQ 및 DiskBBQ 압축 기술 덕분에 수천억 개의 벡터로 확장하더라도 비용이 급증하지 않습니다. 또한 실제로 지불하는 비용은 여러분이 이미 알고 있는 수치, 즉 저장하는 데이터 양, 인덱싱하는 데이터 양, 필요한 검색 용량을 기반으로 산정됩니다. 문서 수, 벡터 차원 및 쿼리 부하를 예측하면 프로젝트를 생성하기 전에 지불할 비용을 산출할 수 있습니다. 또한 월말에 청구서의 항목을 한 줄 한 줄 명확하게 파악할 수 있습니다. 불투명한 컴퓨팅 단위가 없으며 백그라운드 작업에 예상치 못한 요금도 청구되지 않습니다.

Elasticsearch 벡터 데이터베이스 시작하기

서버리스 벡터 데이터베이스 프로젝트 만들기

Elastic Cloud에서 새로운 서버리스 벡터 데이터베이스 프로젝트를 생성하세요. 데이터를 엔드포인트로 지정하면 인덱싱 준비가 완료됩니다.

semantic_text를 사용한 인덱스 생성

벡터 인덱스 모드는 벡터 구성을 처리합니다. semantic_text를 사용하면 관리형 GPU 추론에서 임베딩 및 청킹 설정과 인덱스 설정이 관리되므로 구축할 임베딩 파이프라인이 필요하지 않습니다.

문서 수집

텍스트를 색인하면 임베딩이 자동으로 생성됩니다.

시맨틱 검색 쿼리 실행

방금 생성한 동일한 시맨틱 필드에 대해 쿼리 작업을 수행합니다.

그리고 결과가 반환됩니다.

시맨틱 검색은 시작에 불과합니다. 완전한 텍스트 기반 쿼리를 실행하거나 두 가지를 결합하여 하이브리드 쿼리로 만들 수 있습니다. 완전한 제어를 위해 자체 벡터 쿼리를 작성할 수도 있습니다. 전체 지침은 문서의 시맨틱 검색 빠른 시작을 참조하세요.

Elasticsearch 벡터 검색의 다음 단계

이미 다음 개선 사항을 진행 중입니다.

• 향상된 멀티테넌트 처리: 테넌트별로 데이터를 분리하여 유지해야 하는 경우, 더 적은 코드로 더 빠르게 처리할 수 있는 방법을 제공해 드립니다.

• 자동 인덱스 최적화: '새 인덱스'부터 '완전히 최적화된 인덱스'까지, 가능한 한 적은 조정으로 가능합니다.

• 지속적인 인프라 개선: 항상 최고의 처리량과 가장 빠른 응답을 얻을 수 있도록 벡터 데이터베이스의 설정 및 인프라를 지속적으로 튜닝합니다.

Elastic Cloud Serverless에서 Elasticsearch 벡터 데이터베이스 써보기

프로덕션급 기본 설정이 튜닝을 대신 처리하여, 빈 프로젝트에서 단 몇 분 만에 하이브리드 필터링 벡터 쿼리를 구축해 보세요. 인프라가 아닌 신속하고 확장 가능한 AI 앱을 구축하세요.

Elastic Cloud Serverless에서 시작하거나 전체 설명서 및 API 참조를 살펴보십시오.

리콜이란 무엇입니까?

리콜 척도는 사용자가 실제로 원하는 문서가 검색 결과 어딘가에 나타나는 정도를 0에서 1까지의 범위로 측정합니다. 만약 쿼리에 3개의 제품이 표시되어야 하는데 검색 결과 상위 10개 제품 중 2개만 표시되는 경우, 해당 쿼리에 대해 recall@10 = 0.67을 입력합니다. 이는 집합 기반 메트릭이므로 k 결과 내에서 관련 문서의 위치는 중요하지 않습니다. 10번 위치에 있는 관련 문서는 1번 위치에 있는 문서와 동일하게 계산됩니다. 리콜률이 높다는 것은 관련성 있는 결과를 놓치지 않고 있다는 뜻입니다.

다이어그램은 모든 관련 문서(왼쪽)와 BM25가 실제로 검색한 문서(상위 10개, 오른쪽)의 두 가지 세트를 보여줍니다. 오직 교차점만이 리콜에 포함되며, prod_1과 prod_2는 발견되었지만, prod_3, prod_4, prod_6은 완전히 누락되었습니다. 결과: Recall@10 = 2/5 = 0.40.

필수 구성 요소

리콜이 어떻게 작동하는지에 대해 자세히 알아보겠습니다. 이 데모에서는 Python을 사용합니다. 제공된 노트북(notebook.ipynb)을 통해 따라 해보실 수 있습니다. 모든 코드 블록은 실행할 준비가 된 셀입니다.

제공된 코드는 다음을 사용합니다.

• Elasticsearch 9.3+

• Python 3.10+

• Elasticsearch 자격 증명이 포함된 .env 파일

데이터 세트

신발, 전자제품, 공구 등의 카테고리를 아우르는 1,000개의 제품 카탈로그.

각 문서에는 네 개의 필드가 있습니다.

필드

유형

`title`

텍스트

`설명`

텍스트

`브랜드`

키워드

'카테고리`

키워드

데이터 세트는 dataset.csv에서 로드되었습니다.

어휘 검색의 힘과 한계

BM25는 Elasticsearch 및 대부분의 검색 엔진에서 기본 순위 알고리즘으로 사용됩니다. 쿼리 용어가 문서에 나타나는 빈도에 따라 점수를 매기며, 이는 문서 길이와 전체 인덱스에서 이러한 용어의 빈도에 따라 조정됩니다. 소문자 정규화, 어간 제거, 중단어 제거 등의 분석 기능을 상단에서 사용할 수 있습니다. '러닝화'를 검색하면 '러닝화'와 '실행'이 모두 검색 결과에 나타날 가능성이 높습니다.

이는 대규모 쿼리 클래스에 적합합니다.

• '러닝화'를 입력하면 제목에 토큰이 정확히 일치하는 제품이 즉시 검색됩니다.

• '블루투스 스피커'는 토큰이 문자 그대로 나타나기 때문에 휴대용 오디오 제품을 표시합니다.

결과는 결정론적이고 설명 가능합니다. 문서가 높은 순위를 차지한 이유는 쿼리 용어가 문서에 포함되어 있기 때문입니다. 디버깅 관련성은 간단합니다.

부족한 부분

이제 동일한 카탈로그에 대해 다음 쿼리를 실행해 보겠습니다.

• '스킨케어 루틴': '루틴'이라는 단어는 제품 제목에 나타나지 않습니다. BM25는 '스킨케어'와 부분적으로 일치시킬 수 있지만, 페이스 세럼, 바디 오일, 보습제 등은 '비타민 C', '레티놀', 또는 '브라이트닝' 등 검색어와 겹치지 않는 용어를 사용하여 설명됩니다. 완전한 스킨케어 루틴을 구성하는 제품들은 인덱스에 흩어져 있으며, 이를 연결할 공유 토큰이 없습니다.

• '반려동물 여행용 액세서리': 이는 제품 카테고리가 아닌 사용 사례 그룹입니다. 반려견 슬링 캐리어, 반려동물 카시트, 여행용 케이지는 모두 관련성이 있지만 '여행용 액세서리'보다는 휴대성, 안전성, 편안함에 대한 설명이 더 많습니다. BM25는 '반려동물'을 광범위하게 매칭하지만, 여행 관련 제품을 나머지 반려동물 카탈로그와 구분하는 신호가 없습니다.

이것은 리콜 문제입니다. 관련 문서가 인덱스에 존재합니다. 그러나 사용자의 입력 내용과 문서의 내용이 충분히 일치하지 않기 때문에 BM25가 해당 내용을 찾지 못합니다.

동의어를 추가하면 알려진 경우에 도움이 됩니다. 하지만 사용자가 의사를 표현하는 모든 방법을 열거할 수는 없습니다. 이것이 벡터가 중요한 이유입니다.

리콜을 측정해야 하는 이유

문제를 해결하기 전에 그것을 정량화해야 합니다.

Recall@k는 사용자가 실제로 원하는 문서가 검색 결과 위치에 관계없이 얼마나 많이 나타나는지를 측정합니다. 공식적으로

Precision@k는 상위 k개의 결과와 실제 연관성이 있는 결과의 수를 측정합니다.

정확도가 높다는 것은 반환되는 결과가 좋다는 것을 의미합니다. 전자상거래에서 관련 제품을 놓치는 것(낮은 리콜)은 약간 불완전한 결과(낮은 정확도)를 보여주는 것보다 더 나쁠 수 있습니다. 제품이 드러나지 않으면 판매 손실로 연결되기 때문입니다.

Elasticsearch의 rank_eval API를 사용하면 두 가지를 체계적으로 측정할 수 있습니다. 사용자가 각각 등급이 매겨진 문서 세트가 포함된 쿼리 목록을 제공하면 Elasticsearch가 모든 쿼리에 대해 메트릭을 계산합니다.

평가 설정

rank_eval API에는 관련성 등급(0 = 관련성 없음, 1 = 관련성 있음, 2 = 매우 관련성 있음)과 함께 각 쿼리에 대한 관련 문서 매핑인 평가 데이터 세트가 필요합니다.

노트북에서 이것은 심사 목록입니다:

이 조합은 의도적으로 구성된 것입니다.q1은 BM25가 잘 처리하는 쿼리(제품 제목의 정확한 토큰 포함)이고, q2, q3, q4는 사용자의 의도를 특정 제품 키워드가 아닌 개념으로 표현하는 의도 기반 쿼리입니다.

BM25 기준 리콜 측정

먼저, Elasticsearch 클라이언트를 설정하고 원시 텍스트 데이터를 색인합니다.

이제 BM25에 대한 rank_eval 요청을 생성합니다. 목록의 각 요청은 쿼리와 그 등급을 결합합니다.

결과:

0.43 이는 네 개의 쿼리 모두에서 BM25가 찾아야 하는 문서 중 43%만을 찾았다는 의미입니다. 부족한 부분은 의도 기반 쿼리에 집중되어 있습니다. '스킨케어 루틴'은 제품 제목에 '루틴'이 포함되지 않는 페이스 세럼과 바디 오일을 놓치고, '여행용 반려동물 액세서리'는 주제와 다른 반려동물 제품을 검색하는 반면, 휴대성과 안전성 측면을 강조해서 설명하는 캐리어와 케이지는 정작 빠져 있습니다.

여기가 기준이 됩니다. 이제 넘어야 할 목표가 생겼습니다.

Jina 임베딩으로 벡터 검색 추가

Vector search 문서와 쿼리를 고차원 벡터로 인코딩합니다. 고차원 벡터는 수백에서 수천 개의 수치 값으로 구성되며, 각 값은 해당 데이터의 특정한 특징을 인코딩합니다. 비슷한 의미를 가진 문서들은 단어가 공유되지 않더라도 벡터 공간에서 서로 가깝게 배치됩니다. '헬스 기구'와 '덤벨 세트'는 개념이 관련되어 있기 때문에 가까이에 배치될 것입니다. 하이브리드 검색을 지원하여 의미론적 이해와 키워드 정확도를 모두 제공하는 Elasticsearch를 벡터 데이터베이스로 선택했습니다.

EIS는 추론 API를 통해 모델 임베딩을 즉시 지원하는 기능을 포함하고 있습니다.

1단계: Jina 임베딩 v5를 추론 엔드포인트로 사용

클러스터에 GPU 리소스가 있는 경우(Elastic Cloud 및 Elasticsearch 9.3 이상에서 사용 가능), 임베딩이 GPU에서 생성되어 CPU 추론보다 훨씬 빠르며, 과거에 대규모 벡터 처리를 비용 부담으로 만들었던 성능 트레이드오프 문제를 해소합니다.

왜 Jina 임베딩을 사용할까요? jina-embeddings-v5-text는 32,000개 이상의 토큰 컨텍스트 창을 가진 다국어 모델(119개 이상의 언어)로, 작업별 LoRA(Low-Rank Adaptation) 어댑터를 지원합니다. 바로 사용할 수 있는 짧은 제품 설명에 적합합니다. jina-embeddings-v5-text 모델에 대한 자세한 내용은 여기에서 확인하실 수 있습니다.

2단계: 시맨틱 필드로 인덱스 생성

여기서는 semantic_text 필드 유형이 핵심입니다. dense_vector보다 더 높은 수준의 추상화입니다. 추론 엔드포인트를 가리키면 Elasticsearch가 자동으로 임베딩 생성을 처리합니다.

title과 description의 copy_to 속성은 두 필드의 콘텐츠가 semantic_field로 흘러들어가 임베딩되므로, 단일 벡터가 전체 제품 표현을 캡처합니다.

3단계: 제품 인덱스 생성

색인 시점에 Elasticsearch는 각 문서에 대해 추론 엔드포인트를 호출하고, 결과 임베딩을 semantic_field에 저장합니다. 사용자 측에서 추가 코드를 작성할 필요가 없습니다.

하이브리드 검색: BM25 및 벡터와 RRF의 결합

벡터를 추가하면 리콜이 향상되지만, 벡터만 사용하면 정확한 일치 쿼리에서 정확도를 잃을 위험이 있습니다. '러닝화'와 같은 용어는 여전히 문자 자체가 일치하는 결과가 우선 순위에 표시되어야 합니다. 하이브리드 검색은 정확성을 보장하기 위해 어휘 기반 검색 요소를 유지합니다.

상호 순위 결합(RRF)을 사용한 하이브리드 검색은 두 가지 장점을 모두 유지합니다.

• BM25는 정확하거나 거의 정확한 쿼리를 높은 정확도로 처리합니다.

• 의미 검색은 의도 기반 및 다국어 쿼리를 높은 리콜로 처리합니다.

• RRF는 두 개의 순위 목록을 단일 순위로 결합합니다.

RRF 공식은 각 문서의 결과 목록 순위에 따라 점수를 부여합니다.

두 목록 모두에서 높은 순위를 차지한 문서가 더 높은 합산 점수를 받습니다. rank_constant는 하위 등급의 문서가 받는 가중치를 조절합니다.

결과:

하이브리드는 BM25(0.43)에 비해 성능이 크게 향상되었으며, '러닝화'와 같은 정확한 일치 쿼리에 대한 정확확도를 유지합니다.

결과: 전후 비교

세 가지 접근 방식을 모두 비교한 전체 내용은 다음과 같습니다.

결과:

메서드

Recall@10

BM25(어휘 검색)

0.43

하이브리드(BM25 + 벡터)

0.75

쿼리별로 분석해 보겠습니다.

결론

이 포스팅에서는 사용자가 정확한 쿼리를 입력할 때 BM25 어휘 검색이 신뢰할 수 있지만, 키워드보다는 의도에 따라 검색할 때 리콜이 떨어진다는 것을 보았습니다. rank_eval을 사용하여 재현 가능한 기준선을 설정하고 실제 숫자로 그 차이를 측정했습니다. 그 후, Jina 임베딩을 기반으로 하는 semantic_text 필드를 추가하고 평가를 다시 실행했습니다. 결과적으로, 하이브리드 검색은 리콜을 0.43에서 0.75로 높이면서도 정확한 일치 쿼리의 정확도를 유지했지만, 실제 마진은 쿼리 구성에 따라 달라집니다.

이 패턴은 이 예제 이상으로 확장됩니다. 사용자의 실제 쿼리에서 판단을 수집하고 rank_eval을 기준선으로 실행한 다음 semantic_text를 추가하고 다시 측정하세요. 어떤 부분이 얼마나 개선되었는지 정확히 알 수 있습니다.

다음 단계

• 리콜과 벡터 검색에 대해 자세히 알아보기: Jeff Vestal의 리콜 및 벡터 검색 양자화

• 상위 결과의 정확도를 높이기 위해 재순위 추가

• Elasticsearch 하이브리드 검색 문서 살펴보기

• rank_evalAPI에 대해 자세히 알아보기

이전 게시물에서 앞서 보았듯이, 함수 호출이 제공하는 일관성은 단순한 최적화가 아닌 필수 사항입니다. 평가 루프에서 구조적 오류를 제거하자 표준 시나리오(예: 티어 4 데이터 세트)의 결과가 크게 향상되었습니다.

하지만 아직 답변이 필요한 질문도 분명히 남아 있습니다.

상황이 아주 복잡해질 때도 이 접근 방식이 여전히 효과가 있을까요?

실제 엔티티 해석은 단순한 경우로 인해 실패하는 일이 거의 없습니다. 이름이 언어, 문화, 문자 체계, 시대, 조직 경계를 넘나들 때 실패하게 됩니다. 사람들이 이름 대신 직함으로 언급되거나, 회사가 이름을 바꾸거나, 음역이 일관되지 않거나, 철자가 아니라 컨텍스트만이 실제 세계의 엔티티와 연결되는 유일한 요소일 때 실패하게 됩니다.

그래서 이 시리즈의 마지막 포스팅에서 시스템에 '궁극의 도전'이라는 과정을 진행했습니다.

이것이 궁극적인 도전인 이유는 무엇입니까?

이전 평가에서는 점점 더 복잡한 데이터 세트를 사용하여 시스템을 테스트했습니다. 이전 게시물에서 논의된 티어 4에 도달했을 때는 이미 별명, 직함, 다국어 이름 및 의미 참조의 혼합을 다루고 있었습니다. 해당 테스트 결과, 아키텍처 자체는 견고했음에도 특히 잘못된 JSON 형식과 같은 신뢰성 문제로 인해 재현율이 저해되는 것으로 나타났습니다.

함수 호출이 구현됨에 따라 마침내 안정적인 기반을 마련할 수 있었습니다. 덕분에 더 흥미로운 질문을 할 기회가 생겼습니다.

하나의 통합 파이프라인이 여러 종류의 엔티티 해석 문제를 동시에 처리할 수 있을까요?

궁극의 과제 데이터 세트는 바로 그러한 차원을 시험하기 위해 설계되었습니다.

별명이나 음역과 같은 단일한 문제에 집중하는 대신, 이 데이터 세트는 다음과 같은 50개 이상의 다양한 과제 유형을 결합합니다.

• 문화적 지명 관습

• 직함 기반 참조

• 비즈니스 관계와 역사적 이름 변경 사항.

• 다국어 및 교차 스크립트 언급

• 위의 여러 가지가 혼합된 복합 과제입니다.

무엇보다 중요한 것은 이것이 단 하나의 제한적인 사용 사례에 대한 최적화가 아니라는 것입니다. 엔티티 간에 규칙이 변경될 때 설계 패턴이 유지되는지 테스트하는 것이 중요한 부분입니다.

데이터 세트 개요

궁극의 과제 데이터 세트는 다음과 같이 구성됩니다.

• 사람, 조직, 기관이 포함된 50개 엔티티.

• 다양한 구조와 언어적 복잡성을 지닌 약 60개의 기사.

• 51개의 뚜렷한 과제 카테고리가 다음과 같이 넓게 그룹화됩니다.

  • 문화적 지명 관습

  • 직함 및 전문적 맥락.

  • 비즈니스 및 조직적 관계

  • 다국어 및 음역 문제.

  • 결합 및 극단 시나리오

이 시리즈의 초반부에서 생성형 AI(GenAI)를 사용하여 데이터 세트를 생성하는 것에 장단점이 있다는 것을 확인했습니다. 생성형 AI가 없으면 충분히 크고 다양한 테스트 데이터를 구성하는 것이 매우 어려워집니다. 그러나 제어하지 않으면 모델이 작업을 지나치게 쉽게 만드는 경향이 있습니다.

초기 세대 합격 예시를 보면 모델이 블라디미르 푸틴의 명시적 별칭으로 '러시아 대통령'과 같은 구문을 포함시켰다는 사실이 발견되었습니다. 현재로서는 합리적으로 보일 수 있지만, 이는 상황별 해결 테스트의 목적을 무효화합니다. 기사가 1990년대 러시아에 대해 논의하고 있다면 어떻게 될까요? 시스템은 하드코딩된 별칭에 의존하지 않고 컨텍스트에서 올바른 엔티티를 추론해야 합니다.

그러한 이유로, 이 데이터 세트는 지름길이 통하지 않도록 의도적으로 설계되었습니다. 별칭은 시스템이 의미를 유추해야 할 때 명시적으로 나열되지 않습니다. 설명적 구문이 엔티티에 사전 연결되어 있지 않습니다. 정확한 일치는 단순한 로컬 텍스트가 아닌 문서 수준의 컨텍스트에 의존하기도 합니다.

중요 사항: 다양한 시나리오에서 시스템의 기능을 시연하는 것이지만 이는 교육용 프로토타입임을 알려드립니다. 실제 제재 대상 엔티티 모니터링을 처리하는 프로덕션 시스템에는 추가적인 검증, 규정 준수 점검, 감사 추적 및 민감한 사용 사례에 대한 전문적인 처리가 필요합니다.

이러한 시나리오가 어려운 이유

이 시리즈의 첫 번째 게시물에서 “새로운 Swift 업데이트가 도착했습니다!”라는 간단하지만 모호한 예를 소개했습니다. 문제는 'Swift'가 상황에 따라 실제 세계의 여러 엔티티로 해석될 수 있다는 것입니다. 이 예시는 더 큰 진실을 드러냅니다. 자연어가 본질적으로 모호하다는 것이죠.

따라서 엔티티 해석은 단순히 스트링 일치 문제가 아닙니다. 인간은 일상적으로 공유된 지식, 문화적 규범, 상황적 맥락에 의존하여 참조를 해결하며, 그렇게 하고 있다는 사실을 거의 인지하지 못합니다.

고려해야 할 일반적인 케이스:

• 지정학 및 시대적 컨텍스트가 없다면 '대통령'과 같은 직함은 의미가 없습니다.

• 회사 이름은 기사 작성 시기에 따라 모회사, 자회사 또는 이전 브랜드를 가리킬 수 있습니다.

• 사람의 이름은 언어와 문화에 따라 다른 순서, 문자 체계 또는 음역으로 표현될 수 있습니다.

• 동일한 문구가 다른 컨텍스트에서 다른 엔티티를 정당하게 참조할 수 있으며, 시스템은 일치 항목을 수락하는 것만큼 자신 있게 거부할 수 있어야 합니다.

이러한 모든 상황을 깔끔하게 처리할 수 있는 단일 규칙 세트는 없습니다. 그래서 이 프로토타입은 우려 사항을 매우 철저하게 분리합니다.

• Elasticsearch는 후보 공간을 효율적이고 투명하게 좁힙니다.

• LLM은 판단이 필요하고 스스로 설명해야 하는 경우에만 사용됩니다.

• 검색과 추론은 여전히 뚜렷하게 구분됩니다.

과제 유형이 다양해질수록 이러한 분리가 더욱 중요해집니다.

시스템이 특별 사례 없이 다양성을 처리하는 방식

이 평가에서 가장 흥미로운 결과 중 하나는 변하지 않은 부분입니다.

• 일본어 이름에 대한 특별한 로직을 추가하지 않았습니다.

• 아랍어 부칭에 대한 사용자 지정 규칙을 추가하지 않았습니다.

• 과거 회사 이름에 하드코딩된 매핑을 추가하지 않았습니다 .

대신 이 시스템은 이 시리즈에서 앞서 소개된 것과 동일한 핵심 요소에 의존했습니다.

• 시맨틱 검색을 위해 인덱싱된 컨텍스트가 풍부한 엔티티

• Elasticsearch 내 하이브리드 검색(정확성, 별칭, 의미론적 검색)

• 잘 정의된 소규모 후보 일치 집합

• 함수 호출 및 최소 스키마에 의해 제한되는 LLM 판단

이는 시스템의 유연성이 점점 늘어나는 규칙 집합이 아니라 표현과 구조에서 온다는 것을 시사합니다.

시스템이 성공하는 경우는 올바른 후보가 검색되고, LLM이 참조가 특정 엔티티에 매핑되거나 매핑되지 않는 이유를 설명할 충분한 맥락을 제공하기 때문입니다.

결과: 성능은 어떠했습니까?

궁극의 과제 데이터 세트에서 시스템은 다음과 같은 종합적인 결과를 도출했습니다.

• 정밀도: ~91%

• 재현율: ~86%

• F1 점수: ~89%

• LLM 합격률: ~72%

도전 과제 유형 전반에 걸친 성과

과제 유형별로 결과를 분석하면 강점과 한계가 드러납니다.

가장 강한 성능(100% F1 점수)은 다음과 같은 영역에서 관찰되었습니다.

• 스크립트 간 매칭(키릴 문자, 한국어, 중국어 사업체)

• 히브리어 시나리오(부칭, 전문 직함, 종교 직함, 음역)

• 비즈니스 계층(항공우주, 다각적인 제조, 다사업부 기업)

• 전문직 칭호(학문적, 군사적, 정치적, 종교적).

• 여러 문자 체계를 포함하는 결합된 일본어 시나리오입니다.

강력한 성능(80–99% F1 점수) 포함 사항:

• 국제 정치인(98%)

• 과거 이름 변경 내역(90%)

• 복잡한 비즈니스 계층(89%)

• 일본 회사 이름(93%)

• 교차 문자 체계 음역(86%)

• 아랍어 애칭(86%)

더 까다로운 영역 포함:

• 고급 음역(중국어, 한국어): 0% F1.

• 특정 일본어 시나리오(경어법, 이름 순서, 쓰기 체계 변형): ~67% F1.

• 일부 아랍어 시나리오(회사명, 기관 참조): ~40% F1.

여기서 중요한 것은 이 사례에서 시스템이 어려움을 겪은 이유입니다. 이러한 실패는 전반적인 접근 방식이 고장났기 때문이 아니라 특정 구성 요소, 특히 특정 다국어 시나리오에서 시맨틱 검색에 사용되는 고밀도 벡터 모델의 한계로 인한 것이었습니다.

검색과 판단이 명확하게 분리되어 있기 때문에, 성능 향상을 위해 시스템을 다시 작성할 필요가 없습니다. 보다 뛰어난 다국어 임베딩 모델로 교체하거나, 엔티티 컨텍스트를 강화하거나, 검색 전략을 개선하면 핵심 아키텍처를 변경하지 않고도 이러한 카테고리 전반에 걸쳐 결과를 향상시킬 수 있습니다.

아키텍처 관점에서는 그것이 진정한 성공 지표입니다.

디자인에 대해 알 수 있는 내용

시리즈를 되돌아보면, 몇 가지 패턴이 눈에 띕니다.

• 영리한 매칭보다 준비가 더 중요합니다. 사전에 컨텍스트로 엔티티를 보강하면 이후 모호성을 크게 줄일 수 있습니다.

• LLM은 검색자가 아니라 심사 위원으로서의 가치가 가장 뛰어납니다.검색하라고 요청하는 것보다 일치하는 이유를 설명해달라고 요청하는 것이 훨씬 효과적입니다.

• 신뢰성이 정확성을 뒷받침합니다. 함수 호출은 JSON을 정리하는 것뿐만 아니라, 검색 단계에서 이미 잠재되어 있던 기억력을 끌어내는 역할을 했습니다.

• 일반화가 전문화보다 우수합니다.잘 선택한 소규모 추상화를 통해 사용자 정의 로직 없이 수십 가지 과제 유형을 처리할 수 있었습니다.

이것이 바로 프로토타입이 의도적으로 Elasticsearch 네이티브 방식으로 설계되었고, LLM 사용 방식에 있어서도 의도적으로 보수적인 접근 방식을 취한 이유입니다. 목표는 검색을 대체하는 것이 아니라, 의미가 중요한 상황에서 검색을 설명 가능하게 만드는 것입니다.

결론

궁극의 과제는 완벽한 지표를 추구하기 위한 것이 아니라, 더 근본적인 질문에 답하기 위한 것입니다.

투명한 검색 우선의 LLM 기반 아키텍처가 규칙이나 블랙박스로 전락하지 않고 실제 세계의 엔티티 모호성을 처리할 수 있을까요?

이 교육용 프로토타입의 경우 프로덕션 강화, 규정 준수, 모니터링 및 데이터 품질과 관련된 명확한 주의사항이 있지만 그 답은 '예'입니다. 엔티티 일치가 이루어진 이유를 정당화해야 하는 시스템을 구축하는 경우, 이 패턴을 진지하게 고려할 가치가 있습니다. 이 시리즈를 통해 엔티티 해결이 불가사의하지 할 이유가 없다는 것을 알게 되셨기를 바랍니다. 문제를 제대로 분리하면 엔티티 해결을 이해하고, 측정하고, 개선할 수 있습니다.

이 작업은 또한 더 광범위한 아키텍처 패턴을 제안합니다. 이를 통해 고전적인 Retrieval-Augmented Generation(RAG) 방식의 미미하지만 중요한 진화가 드러납니다. 검색이 생성에 직접 정보를 제공하게 하는 대신, 명시적인 평가 단계를 도입했습니다. LLM이 먼저 사용되어 검색된 후보를 심사하고 무결성을 확인하며 승인된 결과만 생성을 보강하는 것이 허용됩니다. 이를 Generation-Augmented Retrieval-Augmented Generation with Evaluation, 즉 GARAGE라고 생각하시면 됩니다. 이렇게 좋은 약어를 마다할 사람은 없겠죠?

이 패턴이 다른 어떤 사용 사례에 도움이 될 수 있을까요? 신뢰, 투명성 및 변호 가능한 추론이 필요한 시스템이 당연히 후보가 될 것입니다. 이 분야의 향후 작업은 여기서 본 결과만큼이나 매력적일 것입니다. 커뮤니티가 다음에 어떤 방향으로 나아갈지 정말 기대됩니다.

다음 단계: 직접 사용해 보기

궁극의 과제가 실제로 작동하는 모습을 확인하고 싶으세요? 실제 구현, 자세한 설명 및 실습 예제가 포함된 궁극의 과제 노트북을 확인해 보세요.

완전한 엔티티 해석 파이프라인은 프로덕션 환경에 필요한 핵심 개념과 아키텍처를 보여줍니다. 이를 기반으로 모든 과정에서 투명성과 설명 가능성을 유지하는 동시에 뉴스 기사를 모니터링하고, 엔티티 언급을 추적하며, 어떤 엔티티가 어떤 기사에 등장하는지에 대한 질문에 답하는 시스템을 구축할 수 있습니다.

1. Swift 업데이트 도착! 개발자들은 새로운 기능을 사용해 보고 싶어 합니다.

2. Swift 업데이트 도착! 새 앨범이 다음 달에 발매될 예정입니다.

이 추가 맥락을 통해 "Swift"라는 이름을 올바른 엔터티로 해석할 수 있습니다.

이전 게시물에서는 감시 목록을 설정하고 엔터티를 추가 맥락으로 보강했습니다. 위의 예시를 보면, 목록에 최소한 다음 두 개의 엔터티, "Taylor Swift"와 "Swift 프로그래밍 언어"가 있어야 합니다. 텍스트에서 엔터티 언급을 추출하는 방법도 다뤘습니다. 이 두 예시 모두 "Swift"를 추출합니다. 보강된 감시 목록과 추출된 엔터티라는 재료가 갖추어졌으니, 이제 주요 주제인 엔터티 매칭을 다룰 준비가 되었습니다.

유의 사항: 이것은 엔터티 매칭 개념을 교육하기 위해 설계된 교육용 프로토타입입니다. 프로덕션 시스템에서는 다양한 대규모 언어 모델(LLM), 사용자 지정 매칭 규칙, 특수 판단 파이프라인 또는 여러 매칭 전략을 결합한 앙상블 접근 방식을 사용할 수 있습니다.

문제: 매칭이 어려운 이유

인간의 언어는 놀라운 것입니다. 가장 흥미로운 속성 중 하나는 끝없는 창의성입니다. 우리는 무한하게 많은 수의 새로운 문장을 생성하고 이해할 수 있습니다. 그렇다면 엔터티 해석에서 정확한 일치가 드문 것이 과연 놀라운 일일까요? 작성자들은 가능한 한 창의적으로 되려고 노력합니다. 엔터티가 언급될 때마다 전체 이름을 쓰고 읽어야 한다면 매우 지루할 것입니다. 정확한 일치는 간편하지만, 실제로는 엔터티 해석을 위해 더 정교한 접근 방식이 필요합니다. 인간 작성자의 무한한 창의성을 최소한 어느 정도는 처리할 수 있을 만큼 강력한 접근 방식이 필요합니다. 그래서 우리는 문제를 두 단계로 분리합니다. Elasticsearch를 사용하여 가능성 있는 후보를 대규모로 검색하고, 그런 다음 LLM을 사용하여 이러한 후보가 실제로 동일한 실제 엔터티를 참조하는지 판단하는 것입니다.

해결책: 투명한 LLM 판단을 사용한 3단계 매칭

우리는 컴퓨터 사용 방식에서 패러다임 전환의 중심에 있습니다. 인터넷의 등장으로 로컬 컴퓨팅에서 글로벌 연결 네트워크로 전환된 것처럼, 생성형 AI는 콘텐츠, 코드 및 정보 생성 방식을 근본적으로 변화시키고 있습니다. 실제로, 이 시리즈에 포함된 교육용 프로토타입에서는 작성자의 세심한 프롬프트에 따라 거의 전적으로 LLM을 통한 "바이브 코딩" 방식을 사용했습니다. LLM이 인간 언어에 내재한 생산성에 도달했거나 도달할 것이라는 의미는 아니지만, 이제 엔터티 해석에 도움이 되는 강력한 리소스를 갖게 되었다는 것은 명백합니다.

생성형 AI에서 흔히 사용하는 패턴은 Retrieval-Augmented Generation(RAG)입니다. 여기서 검색(Retrieval)은 엔터티 후보를 검색하는 것(답변 생성이 아님)을 의미하며, LLM은 매칭 평가와 설명에만 엄격히 사용됩니다. LLM에 엔드 투 엔드 엔터티 해석을 요청할 수도 있지만, 시간과 비용 면에서 비용이 많이 듭니다. RAG는 LLM에 더 효율적으로 맥락을 제공하는 방식을 사용함으로써 LLM이 엔터티 해석을 효율적으로 지원하도록 돕습니다.

RAG의 검색 부분에서는 다시 Elasticsearch를 사용합니다. 먼저 정확한 매칭, 별칭 매칭, 그리고 키워드와 시맨틱 검색을 결합한 하이브리드 검색을 조합하여 잠재적 매칭을 찾습니다. 이 잠재적 매칭을 찾으면 LLM에 보내 판단을 받습니다. LLM은 최종 매칭 평가자 역할을 합니다. 또한 LLM은 그 추론을 설명하게 하는데, 이는 다른 엔터티 해석 시스템과의 중요한 차별점입니다. 이러한 설명이 없으면 엔터티 해석은 블랙박스와도 같습니다. 설명이 있어야 매칭이 타당한 이유를 알 수 있습니다.

핵심 개념: 3단계 매칭, 하이브리드 검색, 투명한 LLM 판단

3단계 매칭이란? 이 프로젝트의 시작 시점에 우리는 시맨틱 검색이 시스템의 중요한 부분이 될 것이라고 가정했지만, 모든 매칭이 그러한 정교한 검색을 요구하지는 않습니다. 일치하는 항목을 효율적으로 찾기 위해서, 문제에 대해 점진적인 접근 방식을 취합니다. 먼저 키워드 검색을 사용하여 정확히 일치하는 항목을 확인합니다. 정확히 일치하는 항목을 찾으면 작업이 완료되고 다음 단계로 넘어갈 수 있습니다. 정확히 일치하는 항목이 없으면, 별칭 매칭으로 전환합니다. 프로토타입에서는 간편함을 위해 별칭 매칭에서도 키워드를 사용한 정확한 일치 방식을 사용합니다. 프로덕션 환경에서는 이 단계를 정규화, 음역 규칙, 퍼지 매칭 또는 큐레이션된 별칭 테이블로 확장할 수 있습니다. 처음 두 단계에서 잠재적인 일치 항목을 찾지 못하면, Elasticsearch의 하이브리드 검색과 상호 순위 결합(RRF)을 통해 시맨틱 검색을 사용할 차례입니다.

하이브리드 검색이란? Elasticsearch에서는 시맨틱 검색을 사용하여 맥락을 고려한 의미 있는 일치 항목을 찾을 수 있습니다. Elasticsearch는 벡터 검색 및 하이브리드 검색에 널리 사용됩니다. 시맨틱 유사성은 의미 파악에 효과적이지만, 구조화된 필터링(예: 시간 범위, 위치 또는 식별자 기준)을 대체할 수 없으며 정확한 일치 항목이 있을 경우에는 불필요한 경우가 많습니다. Elasticsearch는 시맨틱 검색이 맞지 않는 작업에 뛰어난 어휘 검색으로 두각을 나타냈습니다. 두 접근법을 모두 활용하기 위해 단일 하이브리드 쿼리에서 어휘 검색과 시맨틱 검색을 사용합니다. 그런 다음 결과를 병합해서 RRF로 일치 가능성이 가장 높은 항목을 찾습니다. 프로토타입에서는 상위 두 결과가 LLM 판단을 위해 보낼 수 있는 잠재적 일치 항목이 됩니다.

LLM 판단이 필요한 이유? LLM의 판단과 설명을 통해 시스템은 모호성과 맥락을 투명하게 처리할 수 있습니다. 이는 맥락에 따라 여러 개체를 지칭할 수도 있는 "The President" 같은 사례에 매우 중요할 뿐 아니라, 별명이나 문화적 변형 같은 항목도 시스템에서 잘 작동하도록 해줍니다. 마지막으로, 제재 목록에서 엔터티를 식별할 때와 같이 중대한 작업을 고려할 때 시스템을 신뢰하기 위해서는 일치 항목이 수락된 이유를 알아야 합니다. 결정적으로, LLM은 전체 말뭉치를 검색하는 것이 아니라 Elasticsearch가 반환한 작은 후보 집합만 평가합니다.

실제 결과: LLM 추론을 사용한 매칭

자연어 처리 작업에서 가장 큰 과제 중 하나는 기대 결과를 알려주는 문서, 즉 "정답지"를 만드는 것입니다. 이것 없이는 작업에서 시스템의 성능을 판단하기가 거의 불가능하지만, 이러한 문서를 작성하는 과정은 어려울 수 있습니다. 엔터티 해석 프로토타입 개발을 위해, 테스트에 사용할 데이터를 설정하는 데 다시 한번 생성형 AI의 도움을 받았습니다.

먼저 별명과 음역법 같은 여러 과제 유형을 정의한 후, 시스템에 점차 더 커지고 어려워지는 티어형 데이터 세트 모음을 만들도록 LLM에 요청했습니다. 데이터 세트 생성은 기대만큼 간단하지 않았습니다. LLM은 정답을 너무 쉽게 찾도록 만들어서 "속임수"를 쓰는 경향이 강했습니다. 예를 들어, 과제 유형 중 하나는 의미론적 맥락에 초점을 맞췄습니다. 이 유형에는 "러시아 작가(Russian author)"를 "레프 톨스토이(Leo Tolstoy)"로 해석하는 것과 같은 것들이 포함되었습니다. LLM은 "러시아 작가(Russian author)"를 "레프 톨스토이(Leo Tolstoy)"의 별칭으로 잘못 표기했으며, 이로 인해 일치 항목을 찾기 위한 하이브리드 검색의 필요성이 없어졌습니다.

이와 같은 문제를 해결하기 위해 여러 차례 리팩토링을 거친 후, 5개의 데이터 세트 티어를 사용하게 되었습니다. 티어 1~4는 점점 더 커지고 더 많은 유형의 과제를 포함했습니다. 티어 5는 모든 과제 유형 중에서 가장 까다로운 예제들로 구성된 "궁극의 도전 과제" 데이터 세트였습니다. 모든 테스트 데이터는 종합 평가 디렉터리에서 확인할 수 있습니다.

프롬프트 기반 엔터티 해석 접근 방식을 평가하기 위해 티어 4 데이터 세트에 집중했습니다. 중요한 점은 이 평가가 통제된 실험으로 수행되어 엔터티 매칭 품질에 집중할 수 있었다는 것입니다. 감시 목록 데이터는 맥락 정보로 사전 보강되었으며, 엔터티는 문서에서 미리 추출되었습니다. 이를 통해 추출 정확도보다는 매칭에 초점을 맞춰 평가할 수 있었습니다. 이를 통해 매칭 품질에 집중합니다. 엔드 투 엔드 성능은 추가적으로 추출 재현율 및 보강 품질에 따라 달라질 수 있습니다.

평가 데이터 세트

티어 4 평가 데이터 세트는 시스템의 기능을 종합적으로 테스트합니다.[1]

• 감시 목록 엔터티: 다양한 유형의 엔터티 66개(사람, 조직, 위치).

• 테스트 문서: 실제 엔터티 해석 시나리오를 다룬 문서 69개.

• 예상 일치 항목: 모든 문서에서 예상 엔터티 일치 항목 206개.

• 과제 유형: 엔터티 해석의 다양한 측면을 테스트하는 과제 유형 15가지.

데이터 세트에 포함된 과제 유형은 다음과 같습니다.

• 별명: "Bob Smith" → "Robert Smith"(7개 문서).

• 직함 및 경칭: "Dr. Sarah Williams" → "Sarah Williams"(5개 문서).

• 의미론적 맥락: "Russian author" → "Leo Tolstoy"(8개 문서).

• 다국어 이름: 여러 스크립트로 이름 처리(6개 문서).

• 비즈니스 엔터티: 법인명 변형(7개 문서).

• 임원 참조: "Microsoft CEO" → "Satya Nadella"(5개 문서).

• 정치 지도자: 직함 기반 참조(5개 문서).

• 이니셜: "J. Smith" → "John Smith"(3개 문서).

• 이름 순서 변형: 다양한 이름 순서 규칙(3개 문서).

• 잘린 이름: 부분 이름 일치(3개 문서).

• 이름 분할: 텍스트에 걸쳐 이름 분할(3개 문서).

• 누락된 공백/하이픈: 서식 변형(2개 문서).

• 음역: 교차 스크립트 이름 매칭(2개 문서).

• 결합된 과제: 하나의 문서에 여러 과제(6개 문서).

• 복잡한 비즈니스: 계층적 비즈니스 관계(5개 문서).

프롬프트 기반 엔터티 해석이 어떻게 수행되었는지 살펴보겠습니다.

전반적인 성능

결과는 LLM 기반 매치 평가에 많은 가능성이 있음을 보여주지만, 동시에 심각한 신뢰성 문제도 드러났습니다. 각 후보 쌍은 LLM에 의해 평가되어야 하므로, 검색이 잘 작동하더라도 구조화된 출력에 오류가 있으면 허용률과 재현율을 억제할 수 있습니다.

메트릭

값

정밀도

83.8%

재현율

62.6%

F1 점수

71.7%

검색된 총 일치 항목 수

344

LLM 합격률

44.8%

오류율

30.2%

오류율 문제

앞에서 설명한 대로, 프로토타입에서 가장 먼저 한 일은 Elasticsearch를 사용하여 잠재적인 일치 쌍을 생성하는 것입니다. 이러한 잠재적 일치 항목 각각은 LLM에 의해 평가되어야 합니다. 모든 일치 항목을 효율적으로 처리하기 위해 LLM 호출을 배치 처리합니다. 이렇게 하면 API 비용과 지연 시간이 줄어들지만, 출력에 잘못된 형식의 JSON이 포함될 위험도 높아집니다. 배치 크기가 증가함에 따라 JSON은 더 길고 복잡해지므로 LLM이 유효하지 않은 JSON을 생성할 가능성이 높아집니다. 여기에서 30% 오류율이 발생합니다. 평가에서는 요청당 5개의 일치 항목을 배치 크기로 사용했습니다. 이처럼 보수적인 배치 크기를 사용했음에도 불구하고 여전히 JSON 구문 분석 오류가 발생하여 평가 결과가 크게 왜곡됩니다.

다음 단계: LLM 통합 최적화

이제 시맨틱 검색과 LLM 판단을 사용하여 엔터티를 매칭했으므로 완전한 엔터티 해석 파이프라인을 갖추게 되었습니다. 하지만 이 접근 방식은 모델의 판단은 정확하지만 출력 결과가 사용 불가능할 때 새로운 오류 모드를 불러옵니다. 안정성과 비용 효율성을 높이기 위해 LLM 통합을 최적화할 수 있습니다. 다음 게시물에서는 구조화된 출력을 위해 함수 호출을 사용하는 방법을 탐구할 것입니다. 이는 구조와 유형 안전성을 보장하면서 오류와 비용을 줄여줍니다.

직접 사용해 보기

엔터티 매칭을 직접 확인해 보고 싶으신가요? 실제 구현, 자세한 설명 및 실제 예제가 포함된 엔터티 매칭 노트북을 확인해 보세요. 이 노트북은 3단계 검색, RRF를 사용한 하이브리드 검색, 그리고 추론을 포함한 LLM 기반 판단을 통해 엔터티를 매칭하는 방법을 정확하게 보여줍니다.

유의 사항: 이것은 개념을 교육하기 위해 설계된 교육용 프로토타입입니다. 프로덕션 시스템을 구축할 때는 이 학습 중심 프로토타입에서 다루지 않는 모델 선택, 비용 최적화, 지연 시간 요구 사항, 품질 검증, 오류 처리 및 모니터링과 같은 추가 요소를 고려하세요.

참고

1. 이 데이터 세트는 교육용으로 설계된 합성 데이터 세트입니다. 실제 문제를 어느 정도 반영하지만 특정 프로덕션 환경을 대표하는 것은 아닙니다.

이 글에서는 최소 점수 매개변수를 사용하여 시맨틱 검색 결과의 정밀도를 높이는 방법을 알아봅니다. 이 블로그 게시물에 제공된 예시를 테스트해 보고 싶다면 관련 Jupyter 노트북으로 이동하세요.

배경: 정밀도와 재현율

검색 정확도에서 정밀도와 재현율은 핵심 개념입니다. 아직 익숙하지 않은 독자라면 관련 내용을 알아보기를 강력히 권장합니다. 다음은 간략한 내용입니다.

• 정밀도: 사용자와 관련된 반환된 검색 결과의 비율.

• 재현율: 검색 결과 집합에 포함된 코퍼스 내 모든 관련 문서의 비율.

다시 말해 정밀도는 오직 관련성 있는 결과만 반환하는 것이고, 재현율은 관련성 있는 모든 결과를 반환하는 것입니다. 짐작하시겠지만, 이 두 가지는 종종 상충되는 요구 사항입니다. 시맨틱 검색은 재현율은 매우 높지만, 정밀도는 떨어지는 경향이 있습니다. 이 속성을 해결하는 방법을 알아보려면 계속 읽어보세요.

최소 점수 매개변수 소개

'min_score' 매개변수를 사용하면 최소 점수를 설정하여 정밀도를 향상할 수 있으며, 이 매개변수는 정의된 임계값보다 낮은 점수를 가진 일치 항목을 제거하여 결과 집합을 잘라냅니다. 다음은 간단한 예시입니다.

점수 정규화

최소 점수를 설정하는 것도 좋지만, 모든 시맨틱 모델이 정적 임계값에 적합한 점수를 반환하는 것은 아닙니다. 예를 들어 ELSER는 제한이 없는 점수를 반환합니다. 일부 밀집 모델 점수는 밀집도가 높으며 특정 쿼리의 컨텍스트에서만 의미가 있습니다.

대부분의 시맨틱 검색 사례의 경우 'min_score'를 적용하기 전에 정규화 접근 방식을 사용하는 것이 좋습니다. 정규화는 문서 점수가 정의된 간격 내에 있도록 보장합니다. Elasticsearch 검색기는 'l2_norm'과 'minmax'라는 두 가지 정규화 도구를 제공합니다. 가장 일반적으로 사용되는 것은 'minmax'입니다. 이해하기 쉽고 많은 시나리오에서 잘 작동하기 때문입니다. 'minmax'의 주요 속성은 다음과 같습니다.

• 문서 점수는 0–1점 사이로 분포됩니다.

• 가장 높은 점수를 받은 문서는 항상 1점으로 처리됩니다.

• 가장 낮은 점수를 받은 문서는 항상 0점으로 처리됩니다.

  • 이로 인해 키워드 검색에 적합하지 않을 수 있습니다. 자세한 내용은 '하이브리드 검색' 섹션을 참조하세요.

다음은 min_score 을(를) 사용하여 정규화된 시맨틱 쿼리의 예입니다. 검색 결과 목록을 100개부터 시작하는 더 긴 목록으로 반환할 수 있도록 순위 창 크기를 500으로 늘렸습니다.

이 크기는 실제 프로덕션 환경에서 일반적으로 사용되는 값보다 크게 설정되었습니다. 이는 검색 결과의 품질을 검사하고 결과를 조정하기 위한 것입니다.

선형 검색기를 사용한 하이브리드 검색

하이브리드 검색의 경우 가장 간단한 접근 방식은 모든 점수를 정규화하고 가중치를 부여한 다음 최소 점수를 적용하는 것입니다. 합이 1인 가중치를 선택하면 총점이 0–1 범위 내에 유지됩니다. 이렇게 하면 최종 점수를 쉽게 파악하고 min_score 을(를) 조정할 수 있습니다. 다음은 그 예입니다.

RRF를 사용한 하이브리드 검색

BM25에서는 종종 AND 연산자나 minimum_should_match 와(과) 같은 다른 수단을 통해 정밀도를 제어하기도 합니다. 또한 단일하고 정확하며 희귀한 용어로 구성된 쿼리는 자연스럽게 검색 결과 수가 적고, 그 결과가 모두 관련성이 높은 경우가 많습니다. 이는 다음과 같은 결과로 이어질 수 있습니다.

• BM25 검색기에서 결과 뒷부분에 있는 결과는 절대 BM25 점수가 최고 점수에 근접하더라도 낮은 정규화 점수를 받게 됩니다.

• 매우 낮은 BM25 점수를 시맨틱 점수에 더하면 총점이 시맨틱 점수와 거의 같아집니다.

• BM25 점수 기여도가 부족하면 min_score threshold 에 의해 문서가 폐기될 수 있습니다.

이에 대한 해결책으로 상호 순위 융합(RRF)을 사용하여 BM25와 시맨틱 결과를 결합할 수 있습니다. RRF는 서로 다른 검색 알고리즘의 점수를 비교하는 문제를 해결하기 위해 각 결과 집합에서의 위치에 초점을 맞춥니다. 이 시나리오에서는 min_score 이(가) 시맨틱 검색기에만 적용됩니다.

결론

min_score을(를) 사용하여 시맨틱 검색 알고리즘의 높은 재현율로 인해 발생하는 결과 집합의 오탐 수를 줄이는 방법을 보여주었습니다. 검색기에 대해 자세히 알아보려면 이 블로그 게시물과 Elasticsearch 설명서를 참조하세요.

맞춤형 커넥터를 사용하면 기존 ChatGPT 커넥터를 Elasticsearch와 같은 추가 데이터 소스와 결합하여 포괄적인 답변을 얻을 수 있습니다.

이문서에서는 내부 GitHub 문제와 풀 요청에 대한 정보를 포함하는 Elasticsearch 인덱스에 ChatGPT를 연결하는 MCP 서버를 구축합니다. 이 기능을 통해 Elasticsearch 데이터를 사용하여 자연어 쿼리에 응답할 수 있습니다.

Google Colab에서 FastMCP를 사용하여 MCP 서버를 배포하고, ngrok을 통해 ChatGPT가 연결할 수 있는 공개 URL을 얻어 복잡한 인프라 설정을 간소화합니다.

MCP와 에코시스템에 대한 종합적인 개요는 MCP의 현재 상태를 참조하세요.

필수 구성 요소

시작하려면 다음이 필요합니다.

• Elasticsearch 클러스터 (8.X 이상)

• 인덱스에 대한 읽기 권한이 있는 Elasticsearch API 키

• Google 계정 (Google Colab용)

• Ngrok 계정 (무료 요금제 사용 가능)

• 프로/엔터프라이즈/비즈니스 또는 에듀 요금제로 등록된 ChatGPT 계정

ChatGPT MCP 커넥터 요구사항 이해하기

ChatGPT MCP 커넥터를 사용하려면 search 와 fetch, 두 가지를 구현해야 합니다. 자세한 내용은 OpenAI 문서를 참조하세요.

검색 툴

사용자 쿼리를 기반으로 Elasticsearch 인덱스에서 관련 결과 목록을 반환합니다.

수신 내용:

• 사용자의 자연어 쿼리가 포함된 단일 스트링입니다.

• 예: 'Elasticsearch 마이그레이션과 관련된 문제 찾기'

반환값: 

• 결과 객체 배열을 포함하는 result 키를 가진 객체입니다. 각 결과에는 다음이 포함됩니다.

  • id - 고유 문서 식별자

  • title - 이슈 또는 PR 제목

  • url - 문제/PR에 대한 링크

구현에서:

가져오기 도구

특정 문서의 전체 내용을 가져옵니다.

수신 내용:

• 검색 결과에서 Elasticsearch 문서 ID를 포함하는 단일 스트링

• 예: 'PR-578의 세부 정보를 가져와'

반환값:

• 다음 항목을 포함한 완전한 문서 객체입니다.

  • id - 고유 문서 식별자

  • title - 이슈 또는 PR 제목

  • text - 전체 문제/PR 설명 및 세부 정보

  • url - 문제/PR에 대한 링크

  • type - 문서 유형(문제, pull_request)

  • status - 현재 상태(오픈, 진행 중, 해결 완료)

  • priority - 우선순위 수준(낮음, 중간, 높음, 긴급)

  • assignee - 문제/PR 담당자

  • created_date - 생성된 시점

  • resolved_date - 해결된 시점(해당되는 경우)

  • labels - 문서에 연결된 태그

  • related_pr - 관련 풀 요청 ID

참고: 이 예에서는 모든 필드가 루트 레벨에 있는 플랫 구조를 사용합니다. OpenAI 요구 사항은 유연하며 중첩된 메타데이터 개체도 지원합니다.

GitHub 이슈 및 PR 데이터 세트

이 튜토리얼에서는 문제와 풀 요청이 포함된 내부 GitHub 데이터 집합을 사용합니다. 이는 ChatGPT를 통해 비공개 내부 데이터를 쿼리하는 시나리오입니다.

데이터 세트는 여기에서 찾을 수 있습니다. 그리고 벌크 API를 사용해 데이터의 색인을 업데이트할 것입니다.

이 데이터 세트에는 다음이 포함되어 있습니다.

• 설명, 상태, 우선순위 및 담당자와 관련된 문제

• 코드 변경, 리뷰, 배포 정보가 포함된 풀 요청

• 문제와 PR 간의 관계 (예: PR-578이 ISSUE-1889를 수정함)

• 라벨, 날짜 및 기타 메타데이터

인덱스 매핑

인덱스는 매핑을 사용해 ELSER와의 하이브리드 검색을 지원합니다. text_semantic은 시맨틱 검색에 사용되며, 다른 필드는 키워드 검색을 지원합니다.

MCP 서버 구축

저희 MCP 서버는 더 나은 결과를 위해 하이브리드 검색을 사용하여 시맨틱과 텍스트 매칭을 결합하는 OpenAI 사양을 따르는 두 가지 도구를 구현합니다.

검색 툴

RRF(상호 순위 융합)을 사용하여 의미론적 검색과 텍스트 매칭을 결합한 하이브리드 검색을 사용합니다.

주요 사항:

• RRF를 사용한 하이브리드 검색: 시맨틱 검색(ELSER)과 텍스트 검색(BM25)을 결합하여 더 나은 결과를 제공합니다.

• 다중 일치 쿼리: 부스팅(title^3, text^2, assignee^2)을 사용하여 여러 필드에 걸쳐 검색합니다. 캐럿 기호(^)는 관련성 점수를 곱하여 콘텐츠보다 제목의 일치 항목에 우선순위를 부여합니다.

• 퍼지 매칭: fuzziness: AUTO는 대략적인 매칭을 허용함으로써 오타와 맞춤법 오류를 처리합니다.

• 상호 순위 결합(RRF) 파라미터 튜닝:

  • rank_window_size: 50 - 병합하기 전에 각 검색기(시맨틱 및 텍스트)에서 고려할 상위 결과의 수를 지정합니다.

  • rank_constant: 60 - 이 값은 개별 결과 집합의 문서가 최종 순위 결과에 미치는 영향을 결정합니다.

• 필수 필드만 반환: OpenAI 사양에 따라 id, title, url 만 반환되며, 불필요한 추가 필드를 노출하지 않습니다.

가져오기 도구

문서가 있는 경우 문서 ID로 문서 세부 정보를 검색합니다.

주요 사항:

• 문서 ID 필드로 검색: 사용자 정의 id 필드에서 용어 쿼리를 사용합니다.

• 전체 문서 반환: 모든 콘텐츠가 포함된 전체 text 필드를 포함합니다.

• 플랫 구조: 모든 필드가 루트 수준에 있으며, Elasticsearch의 문서 구조와 일치합니다.

Google Colab에 배포

Google Colab을 사용하여 MCP 서버를 실행하고 ngrok을 사용해 외부에 공개함으로써 ChatGPT가 연결할 수 있도록 합니다.

1단계: Google Colab 노트북 열기

사전 구성된 Elasticsearch MCP for ChatGPT 노트북에 액세스합니다.

2단계: 자격 증명을 구성하세요

세 가지 정보를 준비해야 합니다.

• Elasticsearch URL: Elasticsearch 클러스터 URL입니다.

• Elasticsearch API 키: API 키로 인덱스에 대한 읽기 액세스 권한을 부여합니다.

• Ngrok 인증 토큰: ngrok에서 무료로 제공하는 토큰입니다. ngrok을 사용하여 MCP URL을 인터넷에 노출하여 ChatGPT가 연결할 수 있도록 합니다.

ngrok 토큰 받기

1. ngrok에서 무료 계정 가입

2. ngrok 대시보드로 이동

3. 인증 토큰을 복사하세요

Google Colab에 시크릿 추가

Google Colab 노트북에서:

1. 왼쪽 사이드바에서 키 아이콘을 클릭하여 시크릿을 엽니다.

2. 이 세 가지 시크릿을 추가합니다.

3. 각 시크릿에 대한 노트북 접근 활성화

3단계: 노트북 실행

1. 런타임을 클릭한 다음 모두 실행을 클릭하여 모든 셀을 실행합니다.

2. 서버가 시작될 때까지 기다립니다(약 30초).

3. 공개 ngrok URL을 표시하는 출력을 찾습니다.

4. 출력은 다음과 같이 표시됩니다.

ChatGPT에 연결

이제 MCP 서버를 ChatGPT 계정에 연결합니다.

1. ChatGPT를 열고 설정으로 이동합니다.

2. 커넥터로 이동합니다.프로 계정을 사용하는 경우 커넥터에서 개발자 모드를 사용 설정해야 합니다.

ChatGPT 엔터프라이즈 또는 비즈니스 버전을 사용하는 경우, 커넥터를 작업 환경에 게시해야 합니다.

3. 만들기를 클릭합니다.

참고: 비즈니스, 엔터프라이즈, 에듀 작업 공간에서는 작업 공간 소유자, 관리자 및 해당 설정이 활성화된 사용자(엔터프라이즈/에듀)만 사용자 정의 커넥터를 추가할 수 있습니다. 일반 회원 역할을 가진 사용자는 사용자 정의 커넥터를 직접 추가할 수 없습니다.

소유자 또는 관리자 사용자가 커넥터를 추가하고 활성화하면 작업 공간의 모든 구성원이 이를 사용할 수 있습니다.

4. 필요한 정보를 입력하고 /sse/로 끝나는 ngrok URL을 입력합니다. 'sse"' 뒤의 '/'에 주의하세요. 이것 없이는 작동하지 않습니다.

• 이름: Elasticsearch MCP

• 설명: GitHub 내부 정보를 검색하고 가져오기 위한 사용자 정의 MCP입니다.

5. 생성 을 눌러 사용자 정의 MCP를 저장하세요.

서버가 실행 중이면 즉시 연결됩니다. Elasticsearch API 키가 서버에 구성되어 있으므로 추가 인증이 필요하지 않습니다.

MCP 서버 테스트

질문을 하기 전에 ChatGPT가 사용할 커넥터를 선택해야 합니다.

프롬프트 1: 문제 검색

질문: 'Elasticsearch 마이그레이션과 관련된 문제를 찾아'라고 요청하고 작업 도구 호출을 확인하세요.

ChatGPT가 사용자의 쿼리를 사용하여 search 도구를 호출합니다. 사용 가능한 도구를 찾고 Elasticsearch 도구를 호출할 준비를 하며, 도구에 대해 조치를 취하기 전에 사용자에게 확인하는 것을 볼 수 있습니다.

도구 호출 요청:

도구 응답:

ChatGPT는 결과를 처리하여 자연스러운 대화 형식으로 표시합니다.

비하인드 스토리

프롬프트: 'Elasticsearch 마이그레이션 관련 문제를 찾아'

1. ChatGPT 호출 search(“Elasticsearch migration”)

2. Elasticsearch가 하이브리드 검색 수행

• 시맨틱 검색은 '업그레이드' 및 '버전 호환성'과 같은 개념을 이해합니다.

• 텍스트 검색은 'Elasticsearch' 및 '마이그레이션'과 정확히 일치하는 결과를 찾습니다.

• RRF는 두 가지 접근 방식의 결과를 결합하고 순위를 매깁니다.

3. id, title와 일치하는 상위 10개의 이벤트를 반환합니다, url

4. ChatGPT는 'ISSUE-1712: Elasticsearch 7.x에서 8.x로 마이그레이션'을 가장 관련성 있는 결과로 식별합니다

프롬프트 2: 전체 세부 정보 확인

문의: 'ISSUE-1889의 세부 정보를 보여줘'

ChatGPT는 사용자가 특정 문제에 대한 자세한 정보를 원한다는 것을 인식하고 fetch 도구를 호출한 후, 도구에 대해 조치를 취하기 전에 사용자에게 확인합니다.

도구 호출 요청:

도구 응답:

ChatGPT는 정보를 종합하여 명확하게 제시합니다.

비하인드 스토리

프롬프트: 'ISSUE-1889의 세부 정보를 가져와'

1. ChatGPT 호출 fetch(“ISSUE-1889”)

2. Elasticsearch가 전체 문서를 검색합니다.

3. 모든 필드가 루트 수준에 포함된 전체 문서를 반환합니다.

4. ChatGPT는 정보를 종합하고 적절한 출처를 제시하며 응답합니다.

결론

이 문서에서는 전용 검색 및 가져오기 MCP 도구를 사용하여 ChatGPT를 Elasticsearch에 연결하고, 비공개 데이터에 대한 자연어 쿼리를 가능하게 하는 사용자 정의 MCP 서버를 구축했습니다.

이 MCP 패턴은 자연어로 쿼리하려는 모든 Elasticsearch 인덱스, 문서, 제품, 로그 또는 기타 데이터에 적용할 수 있습니다.

점수 범위 문제

하이브리드 검색이 어려운 주요 이유 중 하나인 다양한 점수 범위를 살펴보기 위해 무대를 설정해 보겠습니다. 우리의 오랜 친구 BM25는 무한한 점수를 만들어냅니다. 즉, BM25는 0에 가까운 점수부터 (이론적으로) 무한대까지 다양한 점수를 생성할 수 있습니다. 반대로 dense_vector 필드에 대한 쿼리는 0과 1 사이의 점수를 생성합니다. 이 문제를 더욱 악화시키는 semantic_text 은 임베딩을 색인하는 데 사용되는 필드 유형을 난독화하므로 색인 및 추론 엔드포인트 구성에 대한 자세한 지식이 없으면 쿼리의 점수 범위를 알기 어려울 수 있습니다. 이는 어휘 검색 결과와 의미 검색 결과를 통합하려고 할 때 문제가 되는데, 의미 검색 결과가 더 관련성이 높더라도 어휘 검색 결과가 의미 검색 결과보다 우선할 수 있기 때문입니다. 이 문제에 대한 일반적인 해결책은 결과를 인터리빙하기 전에 점수를 정규화하는 것입니다. 이를 위한 두 가지 도구, 선형 검색기와 RRF 검색기가 있습니다.

RRF 검색기는 문서 순위를 관련성 측정값으로 사용하고 점수를 버리는 RRF 알고리즘을 적용합니다. 점수는 고려되지 않으므로 점수 범위 불일치는 문제가 되지 않습니다.

리니어 리트리버는 선형 조합을 사용하여 문서의 최종 점수를 결정합니다. 여기에는 문서에 대한 각 구성 요소 쿼리의 점수를 가져와서 정규화한 다음 합산하여 총 점수를 생성하는 작업이 포함됩니다. 수학적으로 이 연산은 다음과 같이 표현할 수 있습니다:

여기서 N 은 정규화 함수이고 SX 는 쿼리 X 의 점수입니다. 정규화 함수는 각 쿼리의 점수를 동일한 범위를 사용하도록 변환하기 때문에 여기서 핵심적인 역할을 합니다. 리니어 리트리버에 대해 자세히 알아보려면 여기를 참조하세요.

분석하기

사용자는 이러한 도구를 사용하여 효과적인 하이브리드 검색을 구현할 수 있지만 색인에 대한 약간의 지식이 필요합니다. 두 개의 필드가 있는 인덱스를 쿼리하는 리니어 리트리버의 예를 살펴보겠습니다:

1. semantic_text_field 는 텍스트 임베딩 모델인 E5를 사용하는 semantic_text 필드입니다.

text_field 는 표준 text 필드입니다.

1. semantic_text 필드에서 match 쿼리를 사용하며, Elasticsearch 8.18/9.0에서 지원이 추가되었습니다.

쿼리를 구성할 때 semantic_text_field 은 텍스트 임베딩 모델을 사용하므로 이 쿼리에 대한 모든 쿼리는 0에서 1 사이의 점수를 생성한다는 점을 염두에 두어야 합니다. 또한 text_field 은 표준 text 필드이므로 이 필드로 쿼리하면 무제한 점수가 생성된다는 점도 알아야 합니다. 적절한 연관성을 가진 결과 집합을 만들려면 쿼리 점수를 결합하기 전에 정규화하는 리트리버를 사용해야 합니다. 이 예에서는 각 쿼리의 점수를 0과 1 사이의 값으로 정규화하는 minmax 정규화와 함께 선형 검색기를 사용합니다.

이 예제의 쿼리 구성은 두 개의 필드만 관련되어 있기 때문에 매우 간단합니다. 그러나 더 많은 필드와 다양한 유형이 추가되면 매우 빠르게 복잡해질 수 있습니다. 이는 효과적인 하이브리드 검색 쿼리를 작성하려면 쿼리 대상 인덱스에 대한 심층적인 지식이 필요한 경우가 많으므로 구성 요소 쿼리 점수를 조합하기 전에 적절하게 정규화해야 한다는 것을 보여줍니다. 이는 하이브리드 검색의 광범위한 채택을 가로막는 장벽이 됩니다.

쿼리 그룹화

예제를 확장해 보겠습니다: 하나의 text 필드와 두 개의 semantic_text 필드를 쿼리하려면 어떻게 해야 할까요? 다음과 같이 쿼리를 작성할 수 있습니다:

겉으로 보기에는 좋아 보이지만 잠재적인 문제가 있습니다. 이제 semantic_text 필드 매치가 전체 점수의 ⅔를 차지합니다:

이는 불균형한 점수를 만들기 때문에 원하지 않을 수도 있습니다. 필드가 3개만 있는 이 예제에서는 그 영향이 눈에 띄지 않을 수 있지만, 더 많은 필드가 쿼리되면 문제가 됩니다. 예를 들어, 대부분의 인덱스에는 시맨틱 필드보다 훨씬 더 많은 어휘 필드가 포함되어 있습니다(예 dense_vector, sparse_vector, 또는 semantic_text). 위의 패턴을 사용하여 어휘 필드 9개와 의미 필드 1개가 있는 인덱스를 쿼리한다면 어떨까요? 어휘 일치 항목이 점수의 90% 을 차지하여 의미론적 검색의 효과를 무색하게 만들었습니다.

이 문제를 해결하는 일반적인 방법은 쿼리를 어휘 및 의미 범주로 그룹화하고 두 범주에 균등하게 가중치를 부여하는 것입니다. 이렇게 하면 어느 한 카테고리가 총점을 지배하는 것을 방지할 수 있습니다.

이를 실천에 옮겨 보겠습니다. 이 예제에서 리니어 리트리버를 사용할 때 그룹화된 쿼리 접근 방식은 어떤 모습일까요?

와, 점점 장황해지네요! 전체 쿼리를 살펴보기 위해 위아래로 여러 번 스크롤해야 했을 수도 있습니다! 여기서는 두 가지 수준의 정규화를 사용하여 쿼리 그룹을 생성합니다. 수학적으로는 다음과 같이 표현할 수 있습니다:

이 두 번째 정규화 수준은 semantic_text 필드와 text 필드에 대한 쿼리의 가중치가 균등하게 적용되도록 합니다. 이 예제에서는 어휘 필드가 하나뿐이므로 text_field 에 대한 두 번째 수준 정규화를 생략하여 더 자세한 설명을 생략했습니다.

이 쿼리 구조는 이미 다루기 힘든데다 세 개의 필드만 쿼리하고 있습니다. 더 많은 필드를 쿼리할수록 숙련된 검색 실무자라도 관리하기가 점점 더 어려워집니다.

다중 필드 쿼리 형식

이 모든 것을 간소화하기 위해 Elasticsearch 8.19, 9.1 및 서버리스에서 선형 및 RRF 검색기에 대한 다중 필드 쿼리 형식을 추가했습니다. 이제 위와 동일한 쿼리를 수행할 수 있습니다:

쿼리가 55줄에서 단 9줄로 줄어듭니다! Elasticsearch는 인덱스 매핑을 자동으로 사용합니다:

• 쿼리되는 각 필드의 유형을 결정합니다.

• 각 필드를 어휘 또는 의미론적 범주로 그룹화합니다.

• 최종 점수에서 각 카테고리에 균등하게 가중치를 부여합니다.

이를 통해 누구나 인덱스나 사용된 추론 엔드포인트에 대한 세부 정보를 몰라도 효과적인 하이브리드 검색 쿼리를 실행할 수 있습니다.

RRF를 사용하는 경우 순위가 관련성의 프록시로 사용되므로 normalizer 을 생략할 수 있습니다:

필드별 부스팅

리니어 리트리버를 사용할 때 필드별 부스트를 적용하여 특정 필드에서 경기의 중요도를 조정할 수 있습니다. 예를 들어 semantic_text 필드 2개와 text 필드 2개 등 4개의 필드를 쿼리한다고 가정해 보겠습니다:

기본적으로 각 필드는 해당 그룹(어휘 또는 의미)에서 동일하게 가중치가 부여됩니다. 점수 분석은 다음과 같습니다:

즉, 각 필드는 총 점수의 25% %입니다.

field^boost 구문을 사용하여 모든 필드에 필드별 부스트를 추가할 수 있습니다. semantic_text_field_1 와 text_field_1 에 2의 부스트를 적용해 보겠습니다:

이제 점수 분석은 다음과 같습니다:

각 쿼리 그룹은 여전히 동일하게 가중치가 적용되지만 이제 그룹 내 필드 가중치가 변경되었습니다:

• semantic_text_field_1 시맨틱 쿼리 그룹 점수는 66%, 총 점수는 33% 입니다.

• text_field_1 는 어휘 쿼리 그룹 점수 66%, 총 점수 33% 입니다.

ℹ️ 필드별 부스트가 적용되어도 총 점수 범위는 변경되지 않습니다. 이는 점수 정규화의 의도된 부작용으로, 어휘 및 의미론적 쿼리 점수가 서로 직접 비교 가능한 상태로 유지되도록 합니다.

ℹ️ 필드별 부스팅은 Elasticsearch 9.2+의 RRF 리트리버와 함께 사용할 수도 있습니다.

와일드카드 해상도

fields 매개변수에 * 와일드카드를 사용하여 여러 필드를 일치시킬 수 있습니다. 위의 예를 계속 이어서, 이 쿼리는 기능적으로emantic_text_field_1, semantic_text_field_2, text_field_1 을 명시적으로 쿼리하는 것과 동일합니다:

*_field_1 패턴이 text_field_1 및 semantic_text_field_1 와 모두 일치한다는 점이 흥미롭습니다. 이는 자동으로 처리되며, 각 필드가 명시적으로 쿼리된 것처럼 쿼리가 실행됩니다. semantic_text_field_1 이 두 패턴과 모두 일치해도 괜찮습니다. 모든 필드 이름 일치 항목은 쿼리 실행 전에 중복이 제거됩니다.

와일드카드는 다양한 방법으로 사용할 수 있습니다:

• 접두사 일치(예: *_text_field)

• 인라인 매칭(예: semantic_*_field)

• 접미사 일치(예: semantic_text_field_*)

*_text_field_* 와 같이 여러 와일드카드를 사용하여 위의 조합을 적용할 수도 있습니다.

기본 쿼리 필드

다중 필드 쿼리 형식을 사용하면 전혀 모르는 인덱스를 쿼리할 수도 있습니다. fields 매개변수를 생략하면 index.query.default_field 인덱스 설정으로 지정된 모든 필드를 쿼리합니다:

기본적으로 index.query.default_field 은 * 으로 설정되어 있습니다. 이 와일드카드는 용어 쿼리를 지원하는 인덱스의 모든 필드 유형(대부분)으로 확인합니다. 예외는 있습니다:

• dense_vector 필드

• rank_vector 필드

• 지오메트리 필드: geo_point, shape

이 기능은 타사에서 제공하는 색인에 대해 하이브리드 검색 쿼리를 수행하려는 경우에 특히 유용합니다. 다중 필드 쿼리 형식을 사용하면 간단한 방법으로 적절한 쿼리를 실행할 수 있습니다. fields 매개변수만 제외하면 해당되는 모든 필드가 쿼리됩니다.

결론

점수 범위 문제로 인해 효과적인 하이브리드 검색을 구현하기가 어려울 수 있으며, 특히 쿼리되는 인덱스나 사용 중인 추론 엔드포인트에 대한 인사이트가 제한적인 경우 더욱 그렇습니다. 선형 및 RRF 검색기를 위한 다중 필드 쿼리 형식은 자동화된 쿼리 그룹화 기반의 하이브리드 검색 방식을 간단하고 접근하기 쉬운 API로 패키징하여 이러한 어려움을 덜어줍니다. 필드별 부스팅, 와일드카드 해상도 및 기본 쿼리 필드와 같은 추가 기능을 통해 다양한 사용 사례를 포괄하는 기능을 확장할 수 있습니다.

지금 바로 다중 필드 쿼리 형식을 사용해 보세요.

무료 체험 판으로 완전 관리형 Elasticsearch 서버리스 프로젝트에서 다중 필드 쿼리 형식의 선형 및 RRF 검색기를 확인해 보세요. 8.19 & 9.1부터 스택 버전으로도 사용할 수 있습니다.

명령 한 번으로 로컬 환경에서 몇 분 안에 시작할 수 있습니다:

검색은 죽지 않았고, 단지 이동했을 뿐입니다.

따라서 주로 텍스트 상자를 통해 문맥을 검색하고 반환된 정보(문맥)를 사용하여 직접 답변을 구성하는 방식에서 이제는 자연어를 사용하여 상담원에게 원하는 것을 말하면 자동으로 검색하여 답변을 작성하는 방식으로 전환했습니다. 기술 업계의 많은 사람들이 이러한 변화를 지적하며 "검색은 죽었다"고 선언하고 있지만(물론 SEO와 애드워즈 세계는 확실히 변화하고 있습니다 . 누구세요?) 검색은 여전히 에이전트 운영에 절대적으로 중요하며, 지금은 대부분 도구를 통해 보이지 않는 곳에서 수행될 뿐입니다.

이전에는 사용자가 주관적인 관련성의 주요 중재자였습니다. 사용자마다 검색을 실행하는 이유가 다르고, 개인적인 경험에 따라 결과의 상대적 정확도가 달라집니다. 에이전트가 우리와 동일한(또는 더 나은) 결론에 도달할 수 있다고 믿으려면 에이전트가 액세스할 수 있는 컨텍스트 정보가 우리의 주관적인 의도에 최대한 가깝도록 보장해야 합니다. 우리는 그 목표를 향해 LLM을 제공하는 맥락을 설계해야 합니다!

하이브리드 검색 검색을 통한 컨텍스트 생성

1부에서 다시 한 번 말씀드리지만, Elastic의 하이브리드 검색은 기존 키워드 기반 검색의 강점(구문 유연성, 키워드 정밀도, 관련성 점수)과 벡터 유사성 검색의 의미론적 이해를 결합하고 다양한 재순위 지정 기술을 제공합니다. 이 시너지 효과(이 단어의 진정한 용도는 찾아볼 수 없습니다!) 를 사용하면 콘텐츠를 타겟팅하는 방식에 훨씬 더 미묘한 차이가 있는 쿼리를 통해 연관성이 높은 결과를 얻을 수 있습니다. 검색 단계 중 하나로 주관적 연관성을 적용할 수 있다는 것뿐만 아니라, 실제로는 1단계 검색에 다른 모든 모드와 함께 연관성 점수를 한 번에 포함할 수 있다는 것입니다.

뛰어난 정확도 & 효율성

분산 검색, 검색 및 순위 재지정을 제공할 수 있는 데이터 플랫폼을 기본 컨텍스트 검색 엔진으로 사용하는 것은 매우 합리적입니다. 고급 쿼리 구문을 사용하여 주관적 의도의 누락된 구성 요소를 추가하고, 반환된 문맥 정보의 가치를 흐리게 하거나 방해할 수 있는 콘텐츠를 필터링할 수 있습니다. 사용 가능한 개별 구문 옵션 중에서 선택하거나 각 유형의 데이터를 가장 잘 이해하는 방식으로 타겟팅하는 단일 검색으로 모달리티를 결합한 다음 순위를 재조정하여 결합/재배열할 수 있습니다. 원하는 필드/값만 포함하도록 응답을 필터링하여 불필요한 데이터를 차단할 수 있습니다. 상담원 서비스에서는 이러한 타겟팅 유연성을 통해 컨텍스트를 검색하는 방식이 매우 정확한 툴을 구축할 수 있습니다.

컨텍스트 세분화(집계 및 비콘텐츠 신호)

집계는 도구가 컨텍스트 창에 제공하는 콘텐츠를 구성하는 데 특히 유용할 수 있습니다. 집계는 자연스럽게 반환된 컨텍스트 데이터의 형태에 대한 수치 기반 사실을 제공하므로, LLM이 더 쉽고 정확하게 추론할 수 있습니다. 집계는 계층적으로 중첩될 수 있기 때문에 LLM에 다단계 세부 정보를 쉽게 추가하여 보다 미묘한 차이를 파악할 수 있습니다. 집계는 컨텍스트 창 크기를 관리하는 데도 도움이 됩니다. 10만 개의 문서에 대한 쿼리 결과를 수백 개의 집계된 인사이트 토큰으로 쉽게 줄일 수 있습니다.

비콘텐츠 신호는 인기도, 신선도, 지리적 위치, 카테고리, 호스트 다양성, 가격대 등 결과의 추가적인 특성을 나타내는 데이터의 내재적 지표로, 현재 보고 있는 내용에 대한 더 큰 그림을 알려줍니다. 이러한 정보는 상담원이 수신한 컨텍스트의 중요도를 평가하는 데 유용할 수 있습니다. 몇 가지 간단한 예시를 통해 이를 가장 잘 설명할 수 있습니다:

• 최근에 게시된 인기 콘텐츠 강화하기 - 문서에 대한 지식창고가 있다고 가정해 보세요. 사용자의 검색어와 관련된 문서를 찾고 싶지만, 최근 문서이면서 다른 사용자가 도움이 되었다고 판단한 문서(예: "좋아요" 수가 많은 문서)도 부스팅하고 싶을 수 있습니다. 이 시나리오에서는 하이브리드 검색을 사용하여 관련성 있는 문서를 찾은 다음 게시 날짜와 인기도를 조합하여 순위를 재조정할 수 있습니다.

• 판매 및 재고 조정 기능이 있는 전자상거래 검색 - 전자상거래 환경에서는 고객에게 검색어와 일치하는 제품을 표시하는 동시에 잘 팔리고 재고가 있는 제품을 홍보하고 싶을 수 있습니다. 또한 재고가 적은 제품의 순위를 낮춰 고객의 불만을 피할 수도 있습니다.

• 버그 트래커에서 심각도가 높은 이슈 우선 순위 지정하기 - 소프트웨어 개발팀의 경우 이슈를 검색할 때 심각도가 높고 우선 순위가 높으며 최근에 업데이트된 이슈를 먼저 표시하는 것이 중요합니다. '중요도' 및 '가장 많이 논의된' 등의 비신호를 사용하여 다양한 요소를 독립적으로 평가하여 가장 중요하고 활발하게 논의된 이슈가 맨 위에 표시되도록 할 수 있습니다.

이러한 예제 쿼리 등은 함께 제공되는 Elasticsearch Labs 콘텐츠 페이지에서 확인할 수 있습니다.

보안 시행

컨텍스트 엔지니어링을 위해 Elastic과 같은 검색 기반 속도 계층을 활용할 때의 중요한 장점은 기본 제공 보안 프레임워크입니다. Elastic의 플랫폼은 세분화된 역할 기반 액세스 제어(RBAC)와 속성 기반 액세스 제어(ABAC)를 통해 에이전트 및 생성 AI 작업에 제공되는 컨텍스트가 민감한 개인 보유 정보를 존중하고 보호하도록 보장합니다. 즉, 쿼리가 효율적으로 처리될 뿐만 아니라 요청을 시작한 상담원이나 사용자의 특정 권한에 따라 결과가 필터링됩니다.

에이전트는 인증된 사용자로 실행되므로 플랫폼에 내장된 보안 기능을 통해 보안이 암시적으로 적용됩니다:

• 세분화된 권한: 문서, 필드 또는 용어 수준에서 액세스 권한을 정의하여 AI 에이전트가 볼 권한이 있는 데이터만 받도록 하세요.

• 역할 기반 액세스 제어(RBAC): 에이전트 또는 사용자에게 역할을 할당하여 정의된 책임에 따라 특정 데이터 세트 또는 기능에 대한 액세스 권한을 부여합니다.

• 속성 기반 액세스 제어(ABAC): 데이터, 사용자 또는 환경의 속성을 기반으로 동적 액세스 정책을 구현하여 고도로 적응력이 뛰어나고 상황에 맞는 보안을 구현할 수 있습니다.

• 문서 수준 보안(DLS) 및 필드 수준 보안(FLS): 이러한 기능은 검색된 문서 내에서도 승인된 부분만 볼 수 있도록 하여 민감한 정보가 노출되는 것을 방지합니다.

• 엔터프라이즈 보안과 통합: 기존 ID 관리 시스템(예: LDAP, SAML, OIDC)과 원활하게 통합하여 조직 전체에 일관된 보안 정책을 적용할 수 있습니다.

이러한 보안 조치를 컨텍스트 검색 메커니즘에 직접 통합함으로써 Elastic은 보안 게이트키퍼 역할을 수행하여 AI 에이전트가 정의된 데이터 경계 내에서 작동하도록 보장하고 무단 데이터 노출을 방지하며 데이터 개인 정보 보호 규정을 준수하도록 유지합니다. 이는 기밀 또는 독점 정보를 처리하는 에이전트 AI 시스템에 대한 신뢰를 구축하는 데 가장 중요한 요소입니다.

추가로, 엔터프라이즈 데이터 소스에서 통합 데이터 속도 계층을 사용하면 에이전트 도구가 생성하는 리포지토리의 예기치 않은 임시 쿼리 부하를 완화할 수 있습니다. 한 곳에서 모든 것을 거의 실시간으로 검색하고 보안 및 거버넌스 제어를 적용할 수 있습니다.

하이브리드 검색 기반 도구

컨텍스트 엔지니어링의 추구를 가속화하는 Elastic 플랫폼의 몇 가지 핵심 기능( 계속 추가될 예정)이 있습니다. 여기서 가장 중요한 것은 플랫폼이 AI 생태계가 발전함에 따라 유연하게 적응, 변경, 확장할 수 있는 다양한 방법을 제공한다는 점입니다.

에이전트 빌더 소개

Elastic 에이전트 빌더는 Elastic에 이미 저장되어 있는 데이터와 채팅할 수 있도록 구축된 에이전트 AI 도구 영역에 처음으로 진출한 제품입니다. 에이전트 빌더는 사용자가 Kibana 내에서 자신만의 에이전트와 도구를 생성하고 관리할 수 있는 채팅 인터페이스를 제공합니다. 기본 제공 MCP 및 A2A 서버, 프로그래밍 방식의 API, Elasticsearch 인덱스를 쿼리 및 탐색하고 자연어로부터 ES|QL 쿼리를 생성하기 위한 사전 구축된 시스템 도구 세트가 함께 제공됩니다. 에이전트 빌더를 사용하면 표현식 ES|QL 쿼리 구문을 통해 에이전트에게 반환되는 컨텍스트 데이터를 타겟팅하고 조각하는 사용자 지정 도구를 만들 수 있습니다.

ES|QL은 하이브리드 검색을 어떻게 수행하나요? 핵심 기능은 semantic_text 필드 유형과 FORK/FUSE 명령의 조합을 통해 수행됩니다(FUSE는 기본적으로 각 포크의 결과를 병합하는 데 RRF를 사용합니다). 다음은 가상의 제품 검색에 대한 간단한 예제입니다:

위의 예제에서 각 FORK 브랜치에 포함된 EVAL 절은 반드시 필요한 것은 아니며, 특정 검색 결과가 어떤 검색 방식에서 반환되었는지 추적하는 방법을 보여주기 위해 포함되었을 뿐입니다.

템플릿 검색

자체 외부 에이전트 도구를 Elastic 배포로 가리키고 싶다고 가정해 보겠습니다. 또한 ES|QL 대신 다단계 검색기를 사용하거나 개발한 기존 DSL 구문을 재사용하고 쿼리가 허용하는 입력, 검색 실행에 사용되는 구문 및 출력에 반환되는 필드를 제어할 수 있기를 원합니다. 검색 템플릿을 사용하면 일반적인 검색 패턴에 대해 미리 정의된 구조를 정의하여 데이터 검색의 효율성과 일관성을 개선할 수 있습니다. 이는 상용구 코드를 표준화하고 검색 로직의 빠른 반복을 가능하게 하므로 검색 API와 상호 작용하는 에이전트 도구에 특히 유용합니다. 이러한 요소 중 하나를 조정해야 하는 경우 검색 템플릿을 업데이트하기만 하면 변경 사항이 바로 적용됩니다. 에이전트 도구에서 작동하는 검색 템플릿의 예를 찾고 계신다면, 외부 MCP 서버에서 도구 호출 뒤에 검색 템플릿을 활용하는 Elasticsearch Labs 블로그 '지능형 검색을 위한 MCP'를 살펴보시기 바랍니다.

통합 워크플로(FTW!)

새로운 에이전트 AI 세계에서 가장 어려운 점 중 하나는 반자율적이고 자기 주도적인 '추론' 에이전트의 비결정적 특성입니다. 컨텍스트 엔지니어링은 에이전트 AI의 중요한 분야로, 에이전트가 생성할 수 있는 결론의 범위를 우리가 알고 있는 사실에 근거하여 좁히는 데 도움이 되는 기술입니다. 매우 정확하고 관련성이 높은 컨텍스트 창이 있더라도 (수치적 사실의 영역을 벗어나면) 상담원의 응답이 완전히 반복 가능하고 신뢰할 수 있다는 확신을 줄 수 있는 부분이 여전히 부족합니다.

상담원에게 동일한 요청을 여러 번 실행하면 응답에 약간의 차이가 있을 뿐 본질적으로 동일한 답변이 나올 수 있습니다. 이는 보통 눈에 띄지 않을 정도로 단순한 쿼리의 경우 괜찮으며 컨텍스트 엔지니어링 기법을 사용하여 결과물을 구체화할 수 있습니다. 하지만 상담원에게 요청하는 작업이 복잡해짐에 따라 하나 이상의 하위 작업으로 인해 최종 결과가 약간 달라질 수 있는 변수가 발생할 가능성이 커지고 있습니다. 상담원 간 커뮤니케이션에 더 많이 의존하기 시작하면 이러한 차이는 더욱 심해질 것이며, 이러한 차이는 누적될 것입니다. 이는 상담원이 상호작용하는 툴이 컨텍스트 데이터를 정확하게 타겟팅할 수 있도록 매우 유연하고 조정이 가능해야 하며, 예상 출력 형식으로 응답해야 한다는 점을 다시 한 번 강조합니다. 또한 많은 사용 사례에서 에이전트와 툴의 상호 작용을 지시해야 할 필요가 있음을 나타내며, 바로 여기에서 워크플로우가 등장합니다!

Elastic은 곧 플랫폼의 핵심에 완전히 사용자 정의 가능한 워크플로우를 내장할 예정입니다. 이러한 워크플로는 상담원 및 툴과 양방향으로 작동할 수 있으므로 워크플로는 상담원 및 툴을 호출할 수 있고, 상담원 및 툴은 워크플로를 호출할 수 있게 됩니다. 이러한 기능이 모든 데이터가 있는 동일한 검색 AI 플랫폼에 완전히 통합되어 워크플로우를 혁신적으로 변화시킬 수 있는 잠재력은 매우 흥미롭습니다! 곧 출시됩니다!

통합 메모리 뱅크로서의 Elastic

실시간에 가까운 검색을 위해 만들어진 분산 데이터 플랫폼이기 때문에, Elastic은 에이전트 AI 시스템을 위한 장기 메모리 기능을 자연스럽게 수행합니다. 기본 제공되는 상담원 빌더 채팅 환경을 통해 단기 기억 및 채팅 기록을 추적하고 관리할 수도 있습니다. 그리고 전체 플랫폼이 API 우선이기 때문에, 에이전트의 컨텍스트 창을 압도할 수 있는 도구의 컨텍스트 출력을 유지(그리고 나중에 참조할 수 있도록)하기 위한 플랫폼으로 Elastic을 매우 쉽게 활용할 수 있습니다. 이 기술은 컨텍스트 엔지니어링 업계에서 "메모 작성"이라고도 불립니다.

동일한 검색 플랫폼에서 단기 메모리와 장기 메모리를 모두 사용하면 많은 본질적인 이점을 얻을 수 있습니다. 채팅 기록과 지속적 문맥 반응을 향후 채팅 상호작용에 시맨틱 영향력의 일부로 사용하거나 위협 분석을 수행하거나 자주 반복되는 도구 호출에서 자동으로 생성되는 지속적 데이터 제품을 만들 수 있다고 상상해 보세요... 가능성은 무궁무진합니다!

결론

대규모 언어 모델의 등장으로 콘텐츠를 매칭하는 방식과 데이터를 조사하는 방법이 바뀌었습니다. 사람이 직접 조사하고, 맥락을 고려하고, 논리적 추론을 통해 질문에 답하는 현재의 세상에서 에이전트 AI를 통해 이러한 단계가 대부분 자동화되는 세상으로 빠르게 전환되고 있습니다. 생성된 답변을 신뢰할 수 있으려면 상담원이 답변을 생성할 때 가장 관련성이 높은 모든 정보(주관적 관련성 요소 포함)를 고려했다는 확신이 있어야 합니다. 에이전트 AI를 신뢰할 수 있게 만드는 기본 방법은 RAG 및 컨텍스트 엔지니어링 기술을 통해 추가 컨텍스트를 검색하는 도구를 기반으로 하는 것이지만, 이러한 도구가 초기 검색을 수행하는 방식은 응답의 정확성에 매우 중요할 수 있습니다.

Elastic Search AI 플랫폼은 정확성, 성능, 확장성 측면에서 에이전트 AI를 지원하는 여러 기본 제공 기능과 함께 하이브리드 검색의 유연성과 이점을 제공합니다. 즉, Elastic은 컨텍스트 엔지니어링의 여러 측면을 위한 환상적인 플랫폼입니다! 검색 플랫폼을 통해 컨텍스트 검색을 표준화함으로써 여러 측면에서 에이전트 도구 운영을 간소화하며, '느려야 빨리 간다'는 모순처럼 컨텍스트 생성 계층에서의 간소화는 더 빠르고 더 신뢰할 수 있는 에이전트 AI를 의미합니다.

다른 많은 사람들과 마찬가지로 저도 AI 기능이 발전하는 속도에 아찔함과 놀라움을 동시에 느낍니다. 대규모 언어 모델(LLM)과 벡터 검색을 통해 우리는 더 이상 키워드를 찾아 헤매지 않아도 되는 시맨틱 혁명을 맞이하게 되었습니다. 그런 다음 LLM은 채팅 인터페이스를 사용하여 자연어 요청을 방대한 지식 기반을 쉽게 사용할 수 있는 요약으로 변환하는 응답으로 변환하는 새로운 데이터 상호 작용 방법을 보여주었습니다. 우리는 지금 (이미!) 수신 요청을 의미론적으로 이해하고, 수행해야 할 단계를 추론한 다음, 해당 목표를 달성하기 위해 반복적으로 작업을 실행할 수 있는 도구를 선택할 수 있는 '에이전트 AI' 워크플로우의 형태로 자동화된 LLM 기반 로직의 시작을 알 수 있습니다.

에이전트 AI의 잠재력으로 인해 우리는 주로 '프롬프트 엔지니어링'을 사용하여 생성형 AI 상호작용을 형성하는 것에서 벗어나 에이전트 도구가 응답을 생성할 때 고려해야 하는 가장 관련성이 높고 효율적인 추가 정보를 얻을 수 있도록 돕는 방법, 즉 '맥락 엔지니어링'이 다음 개척 분야로 진화해야 합니다. 하이브리드 검색은 관련 컨텍스트를 표시하는 가장 강력하고 유연한 수단이며, Elastic의 검색 AI 플랫폼은 서비스 중인 데이터를 컨텍스트 엔지니어링에 활용할 수 있는 완전히 새로운 방법을 열어줍니다. 이 글에서는 LLM이 정보 검색의 세계를 어떻게 변화시켰는지 두 가지 각도에서 살펴본 다음, 더 나은 결과를 위해 어떻게 협력할 수 있는지에 대해 논의해 보겠습니다. 다뤄야 할 내용이 꽤 많습니다...

1부: LLM이 검색을 바꾼 방법

LLM이 정보에 액세스하고 검색하는 방식을 어떻게 변화시켰는지에 대한 관점에서 시작하겠습니다.

어휘 유산

우리는 모두 오랫동안 다소 제한적인 어휘 검색의 세계에서 (최선을 다해) 살아왔습니다. 검색은 새로운 프로젝트를 조사하거나 시작할 때마다 가장 먼저 찾는 도구로, 최근까지만 해도 어휘 검색 엔진이 이해할 수 있는 방식으로 쿼리를 표현하는 것은 전적으로 사용자의 몫이었습니다. 어휘 검색은 콘텐츠가 비정형인지 정형인지에 관계없이 문서 말뭉치에서 찾은 키워드에 어떤 형태의 쿼리 용어를 일치시키는 데 의존합니다. 어휘 검색이 문서를 히트로 반환하려면 해당 키워드와 일치하거나 동의어 목록이나 사전과 같이 개념적 연결을 위해 제어된 어휘가 있어야 합니다.

어휘 다중 일치 쿼리예제

적어도 검색 엔진은 관련성 점수가 있는 히트를 반환하는 기능이 있습니다. 검색 엔진은 색인된 데이터를 효과적으로 타겟팅할 수 있는 다양한 쿼리 구문 옵션과 사용자의 쿼리 구문 의도에 따라 결과를 점수화하는 기본 제공 관련성 알고리즘을 제공합니다. 검색 엔진은 수십 년간 발전해 온 관련성 순위 알고리즘의 이점을 활용하여 검색어와의 관련성에 따라 점수를 매기고 정렬된 결과를 제공할 수 있는 효율적인 데이터 검색 플랫폼이 되었습니다. SQL을 데이터 검색의 주요 방법으로 사용하는 데이터베이스 및 기타 시스템은 여기서 불리한 점이 있습니다. 데이터베이스 쿼리에는 관련성 개념이 없기 때문에 결과를 알파벳순 또는 숫자순으로 정렬하는 것이 최선입니다. 좋은 소식은 이러한 키워드로 모든 히트(리콜)를 얻을 수 있지만, 검색한 이유 (정확도)에 비해 반드시 유용한 순서로 검색되는 것은 아니라는 점입니다. 이는 곧 살펴보겠지만 중요한 포인트입니다...

(시맨틱) 용을 입력합니다.

키워드 검색의 대안으로 정보를 벡터로 표현할 수 있는 가능성은 꽤 오래전부터 연구되어 왔습니다. 벡터는 용어와 가중치를 숫자로 표현하기 때문에 학습 도메인에서 용어가 서로 어떻게 연관되는지에 대한 언어 모델의 이해를 바탕으로 개념을 수학적으로 가깝게 만들 수 있기 때문에 키워드만 사용하는 콘텐츠 매칭 모드에서 벗어날 수 있다는 점에서 많은 가능성을 가지고 있습니다. 범용 벡터 검색이 오래 지연된 것은 모델이 대부분 특정 도메인에 국한되어 있고, 용어가 다양한 맥락에서 나타낼 수 있는 다양한 개념을 충분히 이해하기에 충분히 크지 않았기 때문이었습니다.

벡터 검색이 실용화되기 시작한 것은 몇 년 전, 훨씬 더 많은 양의 데이터를 학습할 수 있는 대규모 언어 모델(LLM)이 등장하면서( 트랜스포머와 주의력을 사용해) LLM의 크기와 깊이 덕분에 벡터가 의미론적 의미를 실제로 포착할 수 있는 충분한 뉘앙스를 저장할 수 있게 되었을 때였습니다. 이해의 깊이가 갑자기 증가함에 따라 LLM은 이전에는 잠겨 있던 수많은 자연어 처리(NLP) 기능을 제공할 수 있게 되었으며, 가장 영향력 있는 기능은 아마도 지금까지의 시퀀스 내용을 바탕으로 시퀀스에서 가장 가능성이 높은 다음 용어를 추론하는 기능일 것입니다. 추론은 제너레이티브 AI에 인간에 가까운 텍스트 생성 능력을 부여하는 과정입니다. AI가 생성한 텍스트는 학습 데이터 내에서 용어가 어떻게 연관되어 있는지에 대한 LLM의 이해를 기반으로 하며, 요청의 문구를 사용하여 용어가 나타날 수 있는 다양한 문맥을 명확히 구분합니다.

생성형 AI는 마법과도 같지만, 품질과 정확성에서 오류를 일으키는 LLM에는 흔히 환각이라고 불리는 한계가 있습니다. 환각은 LLM이 사실에 근거한 답변을 할 수 있는 정보에 접근할 수 없거나 올바른 맥락으로 안내되지 않을 때 발생하므로, 도움이 되는 대신 자신감 있고 그럴듯하게 들리는 답변을 지어내게 됩니다. 그 원인 중 하나는 LLM이 다양한 정보의 넓은 도메인 내에서 언어 사용법을 학습하지만, 특정 시점에 학습을 중단해야 하므로 이해에 적시성 요소가 있어 모델이 학습을 중단한 시점까지만 정확한 정보를 알 수 있다는 점입니다. 환각의 또 다른 요인은 모델이 일반적으로 비공개 데이터(공개 인터넷에서 사용할 수 없는 데이터)에 대해 알지 못한다는 점이며, 이러한 데이터에 특정 용어와 명명법이 포함되어 있는 경우 특히 중요합니다.

벡터 데이터베이스

LLM은 텍스트 임베딩이라는 기술을 사용하여 콘텐츠를 모델 공간에 벡터화하는데, 이는 학습을 기반으로 모델의 세계관 내에 콘텐츠의 의미적 의미를 임베딩하거나 매핑하는 것을 말합니다. 임베드할 콘텐츠를 준비하고 처리하는 데에는 청킹과 토큰화(및 하위 단어 토큰화) 등 몇 가지 단계가 있습니다. 그 결과 일반적으로 벡터 공간 내에서 해당 콘텐츠의 의미에 대한 모델의 이해를 나타내는 고밀도 벡터 집합이 생성됩니다. 청킹은 임베딩을 생성하기 위한 모델의 처리 제약 조건에 콘텐츠를 맞추는 동시에 문장 및 단락 표시기와 같은 의미적 구성을 사용하여 관련 텍스트를 청크로 그룹화하기 위한 정확하지 않은 프로세스입니다.

청킹이 필요하면 개별 청크가 같은 문서의 다른 청크와 완전히 연결되지 않기 때문에 임베디드 문서에서 약간의 의미 손실이 발생할 수 있습니다. 신경망의 고유한 불투명성은 이러한 손실을 더욱 악화시킬 수 있습니다. LLM은 학습 중에 만들어진 용어와 개념 간의 연결이 비결정적이며 인간이 해석할 수 없는 진정한 '블랙박스'입니다. 이는 설명 가능성, 반복성, 무의식적 편견, 잠재적으로 신뢰와 정확성 상실 등의 문제로 이어집니다. 하지만 쿼리할 때 특정 키워드에 얽매이지 않고 아이디어를 의미적으로 연결할 수 있는 기능은 매우 강력합니다:

시맨틱 쿼리 예시

벡터 데이터베이스는 검색 엔진이 아니라 데이터베이스라는 점에서 고려해야 할 문제가 하나 더 있습니다! 벡터 유사성 검색이 수행되면 쿼리 용어가 인코딩되어 모델의 벡터 공간 내에서 일련의 (임베딩) 좌표 집합을 찾습니다. 그런 다음 이러한 좌표를 과녁으로 사용하여 과녁에 '가장 가까운 이웃'인 문서를 찾습니다. 즉, 문서의 순위(또는 결과 내 배치)는 쿼리 좌표에서 해당 문서 좌표의 계산된 유사성 거리에 따라 결정됩니다. 어떤 방향으로 랭킹을 우선시해야 하며, 가능한 컨텍스트 중 사용자의 의도에 가장 가까운 컨텍스트는 무엇인가요? 제가 비유한 이미지는 영화 스타게이트의 한 장면으로, 교차하는 6개의 좌표점이 목적지(과녁)를 알려주지만 사용자의 주관적인 의도를 나타내는 출발점의 좌표인 '7번째 기호'를 모르면 목적지에 도달할 수 없는 상황입니다. 따라서 벡터의 상대적 순위가 계속 확장되고 차별화되지 않은 유사성 영역에 기반하는 대신, 표현 구문과 관련성 점수를 통해 쿼리의 주관적 의도를 고려하면 눈금이 매겨진 주관적 관련성의 원통형과 유사한 결과를 얻을 수 있습니다.

LLM의 추론 기능은 쿼리에 대해 가장 가능성이 높은 컨텍스트를 식별하는 데 도움이 될 수 있지만, 문제는 도움이 없으면 수신 쿼리의 좌표는 모델이 원래 학습된 방식에 의해서만 결정될 수 있다는 점입니다.

어떤 면에서 벡터 유사도는 엄격한 키워드 검색과는 정반대의 극단이라고 할 수 있는데, 용어 불일치 문제를 극복할 수 있다는 것이 강점이지만 거의 결함에 가깝다고 할 수 있습니다: LLM은 관련 개념을 구분하기보다는 통합하는 경향이 있습니다. 벡터 유사도는 콘텐츠를 의미론적으로 일치시키는 능력을 향상시키지만, 모델에서 충분히 명확하지 않은 정확한 키워드와 특정 세부 사항을 간과할 수 있기 때문에 정확성을 보장하지는 않습니다. 벡터 유사도 검색은 그 자체로도 강력하지만, 벡터 데이터베이스에서 검색한 결과를 다른 검색 방법의 결과와 연관시킬 수 있는 방법이 필요합니다.

순위 재조정 기술

이제 결과 집합의 점수를 다시 매기거나 통합된 순위 순서로 정규화하는 리랭킹이라는 일반적인 기법을 언급할 때입니다. 재랭크가 필요한 이유는 여러 소스의 결과 또는 순위/채점 메커니즘이 다른 검색 방법(또는 전혀 없는 SQL!) 때문일 수도 있고, 의미론적이지 않은 소스의 결과를 사용자의 쿼리에 의미론적으로 맞추기 위해 재랭크가 사용될 수도 있습니다. 재랭크는 2단계 작업으로, 어떤 초기 검색 방법(예를 들어 SQL, 어휘 검색, 벡터 검색)의 순서를 다른 채점 방법으로 다시 지정합니다.

학습을 통한 순위 지정(LTR) 및 상호 순위 융합(RRF ) 등 여러 가지 접근 방식을 사용할 수 있습니다. LTR은 검색 결과 기능(좋아요, 평점, 클릭 등)을 캡처하고 이를 사용하여 결과를 점수화하고 부스트 또는 편향시키는 데 유용합니다. RRF는 다양한 쿼리 양식에서 반환된 결과를 병합하는 데 적합합니다(예 어휘 및 벡터 데이터베이스 검색)을 하나의 결과 목록으로 통합합니다. Elastic은 또한 선형 재순위화 방법을 사용하여 점수를 조정할 수 있는 유연성도 제공합니다.

그러나 가장 효과적인 재순위 조정 기법 중 하나는 시맨틱 재순위 조정으로, LLM의 시맨틱 이해를 사용하여 쿼리와 결과의 벡터 임베딩을 함께 분석한 다음 관련성 점수/채점을 적용하여 최종 순위를 결정합니다. 물론 시맨틱 재랭크에는 재랭크 모델에 대한 연결이 필요하며, Elasticsearch는 기본 제공 모델(Elastic Rerank), 가져온 타사 모델 또는 Cohere나 Google Vertex AI 같은 외부 호스팅 서비스를 활용하는 재랭크 엔드포인트를 생성할 수 있는 추론 API를 제공합니다. 그런 다음 검색 쿼리 추상화 구문을 통해 다시 순위를 매길 수 있습니다:

다단계 리트리버 순위 재조정 작업 예시

멋지지 않나요? 서로 다른 소스의 결과에 대해 재랭킹을 수행하여 모든 유형의 콘텐츠에 대한 의미론적 이해에 근접할 수 있습니다... 의미론적 재랭킹은 처리 시간뿐만 아니라 계산 비용이 많이 들 수 있으므로 제한된 수의 결과에 대해서만 실현 가능하게 수행할 수 있으므로 초기 결과를 검색하는 방법이 중요합니다.

컨텍스트 검색 방법의 중요성

주관적 의도는 결과의 정확성을 결정하고 관련성을 점수화할 때 중요한 요소입니다. 쿼리 수행에 대한 사용자의 의도를 고려할 수 있는 기능(유연한 구문 또는 2단계 재랭킹을 통해 표현됨)이 없으면 모델 공간 내에 이미 인코딩된 기존 컨텍스트 중에서 선택할 수 밖에 없습니다. 일반적으로 이러한 컨텍스트 부족 문제를 해결하는 방법은 검색 증강 생성(RAG)과 같은 기술을 사용하는 것입니다. RAG가 작동하는 방식은 상황에 맞는 데이터에 대한 사전 쿼리에서 반환된 추가 관련 용어를 포함하여 쿼리의 좌표를 효과적으로 이동하는 것입니다. 따라서 추가 컨텍스트를 제공하는 엔진과 검색을 수행하는 초기 방법이 컨텍스트의 정확성에 더욱 중요해집니다!

다양한 컨텍스트 검색 방법과 이러한 방법이 RAG 작업에 어떤 도움이 되거나 해가 되는지 살펴보겠습니다:

• 검색 엔진이 없는 하이브리드 검색 검색은 여전히 주관적인 연관성이 부족합니다. RAG를 제공하는 플랫폼이 주로 SQL 기반인 경우(대부분의 '데이터 레이크' 플랫폼 포함), 초기 검색 단계에서 정확도 점수가 부족합니다. 많은 데이터 레이크 플랫폼이 자체 버전의 하이브리드 검색(검색이 아닌)을 제공하며, 일반적으로 SQL 기반 검색과 벡터 데이터베이스 결과에 시맨틱 리랭크 및 RRF와 같은 리랭크 기법을 결합합니다. 단순 정렬은 주관적 순위를 매기기에는 분명히 불충분하지만, 2단계 시맨틱 재랭크 작업의 기초로 사용하더라도 1단계 검색으로서의 SQL은 검색 시 결과를 점수화하는 방법 없이 '상위 k' 히트에 대해서만 시맨틱 재랭크가 수행될 때 문제가 됩니다 - 실제로 최상의 결과가 상위 결과라고 보장할 수 있는 방법은 무엇일까요?

• 벡터 유사성만으로는 RAG에 충분하지 않습니다. 이는 임베딩의 손실, 순진한 청킹 방법, 유사성 계산 방식, 주관적 의도라는 중요한 요소가 누락된 문제 등 복합적인 문제 때문이었습니다. RAG의 주요 목표 중 하나는 생성 AI의 상호작용을 객관적인 진실에 근거하여 환각을 방지하고 학습 중에 알지 못했던 개인 정보를 LLM에 알려주는 것입니다. RAG를 통해 제공되는 추가 컨텍스트를 사용하여 당면한 질문에 답하는 데 가장 중요한 연결과 세부 사항을 고려하도록 LLM을 제한하고 지시할 수 있습니다. 이를 위해서는 의미론적 접근 방식과 어휘적 접근 방식을 모두 사용해야 합니다.

• 파일 기반 grep/레거시 RAG. 에이전트 AI 세계에서는 외부 검색 플랫폼이 아닌 RAG용 grep 및 정규식을 통해 로컬 파일에 액세스하는 크게 확대된 컨텍스트 창을 사용하는 것을 지적하는 의견도 있습니다. 훨씬 더 큰 컨텍스트 창을 사용할 수 있게 되면 LLM은 관련 정보를 수집하기 위해 단편적인 정보와 여러 검색 방법/플랫폼에 의존하지 않고 자신의 사고 공간 내에서 개념을 연결할 수 있게 될 것입니다. 이론적으로는 전체 문서가 문서 세그먼트보다 더 완전한 그림을 제공하지만, 이는 소규모 데이터 도메인(예: 바이브코딩을 위해 파일을 제공할 때)에서만 작동할 수 있으며, 그 경우에도 초기 검색 방식은 키워드만 일치하는 모든 문서를 스캔하는 것입니다.

검색은 검색 그 이상입니다

검색 엔진은 가능한 한 빠르고 유연하게 쿼리를 수행하도록 특별히 설계되었습니다. 내부적으로는 다양한 종류의 데이터를 해당 데이터 유형에 맞는 방식으로 저장하고 검색하기 위해 특수 데이터 구조를 활용합니다. Elasticsearch는 비정형/전체 텍스트 어휘 검색(일치, 구문, 근접, 다중 일치), 빠른 키워드(정확히 일치) 검색 및 필터링, 숫자 범위, 날짜, IP 주소 등 거의 모든 유형의 데이터에 대해 최적화된 저장과 쿼리를 제공하며, 문서 구조를 저장하는 방식이 매우 유연합니다(예. 중첩되거나 평평해진 문서). Elasticsearch는 또한 희소 벡터 유형과 고밀도 벡터 유형을 모두 저장하고 쿼리할 수 있는 기본 벡터 데이터베이스이며, 검색 충실도를 유지하면서 벡터화된 콘텐츠와 관련된 속도, 확장성 및 비용을 개선하는 혁신적인 방법(예: Better Binary Quantization(BBQ) & DiskBBQ)을 계속 모색하고 있습니다. 또한 Elasticsearch 플랫폼은 기본으로 데이터 복원력과 고가용성을 제공하며, 검색 가능한 스냅샷과 같은 데이터 수명 주기 관리 기능을 통해 자주 액세스하지 않거나 장기 보존 데이터를 비용 효율적인 개체 스토리지에 보관하면서도 여전히 완벽하게 검색할 수 있습니다.

하이브리드 검색은 모든 면에서 최고입니다.

하이브리드 검색 (하이브리드 검색뿐만 아니라!) 는 기존 어휘 검색의 강점과 LLM의 의미론적 이해 및 벡터 유사도 검색을 결합합니다. 이러한 시너지를 통해 검색 엔진이 제공하는 유연한 쿼리 구문 옵션, 의도 중심 구문 옵션 및 관련성 점수, 멀티모달 데이터 검색, 필터링, 집계, 편향성 등 검색 엔진이 제공하는 모든 기능을 통해 검색 단계에서 관련성이 높은 결과를 타겟팅할 수 있습니다. ES|QL 및 다단계 검색기와 같은 검색 구문을 사용하면 기존 검색과 시맨틱 검색, 필터, 여러 순위 재조정 기술을 하나의 요청에 유연하게 결합할 수 있습니다.

하이브리드 검색의 가장 큰 장점 중 하나는 쿼리가 여러 가지 데이터 유형에 대해 동시에 특수 구문을 사용할 수 있다는 점입니다. 이러한 다양한 쿼리 구문은 결과를 찾는 데만 사용할 수 있을 뿐만 아니라 결과에 대한 필터나 집계로도 사용할 수 있습니다. 예를 들어, 다른 구문과 자주 결합되는 가장 일반적인 쿼리 유형 중 하나는 지리공간 분석입니다. 특정 지점에서 지정된 거리 내의 지리적 좌표가 있는 결과를 쿼리하거나, 지역별 결과 집계 또는 구역 내/외의 이동을 추적하고 경고하기 위한 집계를 요청하는 등의 작업을 수행할 수 있습니다. 하이브리드 검색을 사용하면 구문을 유연하게 조합하여 가장 정확한 방식으로 결과를 타겟팅하고 컨텍스트에 가장 가까운 콘텐츠를 검색할 수 있습니다.

인터미션

이 첫 번째 파트에서는 벡터 검색이 데이터를 검색하는 방식을 어떻게 변화시켰는지 이야기하고, 데이터와 상호 작용하는 데 사용하는 쿼리 메커니즘에 LLM이 가져온 변화의 무대를 마련합니다. LLM이 맥락을 잃지 않고 이해할 수 있도록 여러 부분으로 나눠서 설명해야 한다고 가정해 보겠습니다... ;-) 2부: 에이전트 AI와 컨텍스트 엔지니어링의 필요성에서 이것이 중요한 이유에 대해 자세히 알아보고, 3부에서는 하이브리드 검색에 대한 논의로 돌아가겠습니다.

이를 위해 Google의 SigLIP-2를 사용해 이미지와 텍스트 모두에 대한 벡터 임베딩을 생성하고 이를 Elasticsearch 벡터 데이터베이스에 저장합니다. 쿼리 시 텍스트 또는 이미지와 같은 검색 입력을 임베딩으로 변환하고 빠른 kNN 벡터 검색을 실행하여 결과를 검색합니다. 이 설정을 통해 텍스트 대 이미지 및 이미지 대 이미지 검색을 효율적으로 수행할 수 있습니다. 스트림릿 UI는 텍스트 기반 검색을 통해 앨범에서 일치하는 사진을 찾아서 볼 수 있을 뿐만 아니라 업로드된 이미지에서 산봉우리를 식별하고 사진 앨범에서 해당 산의 다른 사진을 볼 수 있는 프론트엔드를 제공함으로써 이 프로젝트에 활기를 불어넣었습니다. 또한 검색 정확도를 개선하기 위해 취한 조치와 실용적인 팁과 요령에 대해서도 설명합니다. 더 자세히 살펴볼 수 있도록 GitHub 리포지토리와 Colab 노트북을 제공합니다.

시작 방법

이 블로그 게시물은 에베레스트 베이스캠프 트레킹에서 찍은 아마 다블람 산의 모든 사진을 보여 달라는 10살짜리 아이의 요청에 영감을 받아 작성했습니다. 사진첩을 훑어보면서 이름을 알 수 없는 다른 산봉우리도 몇 개 더 찾아달라는 요청을 받았습니다.

이를 통해 재미있는 컴퓨터 비전 프로젝트가 될 수 있겠다는 생각이 들었습니다. 우리가 달성하고자 했던 목표:

• 이름으로 산봉우리 사진 찾기

• 이미지에서 산봉우리 이름을 맞추고 사진 앨범에서 비슷한 봉우리를 찾습니다.

• 컨셉 쿼리가 작동하도록 하기(사람, 강, 기도 깃발 등)

드림팀 구성: SigLIP-2, Elasticsearch & Streamlit

이 작업을 수행하려면 텍스트('Ama Dablam')와 이미지(내 앨범의 사진)를 모두 의미 있게 비교할 수 있는 벡터, 즉 동일한 벡터 공간으로 변환해야 한다는 것이 금방 분명해졌습니다. 이렇게 하면 검색은 "가장 가까운 이웃을 찾는 것"에 불과합니다.

이미지 임베딩을 생성하기 위해 다국어 비전 언어 인코더를 사용하므로 산 사진과 "Ama Dablam"과 같은 문구가 동일한 벡터 공간에 배치됩니다.

최근 Google에서 출시한 SigLIP-2가 여기에 잘 맞습니다. 작업별 교육( 제로 샷 설정) 없이 임베딩을 생성할 수 있으며, 라벨이 없는 사진과 이름과 언어가 다른 봉우리라는 사용 사례에 적합하게 작동합니다. 텍스트 ↔ 이미지 매칭을 위해 학습되었기 때문에 쿼리 언어나 철자가 다르더라도 트레킹에서 찍은 산 사진과 짧은 텍스트 프롬프트가 임베딩으로 비슷하게 표시됩니다.

SigLIP-2는 강력한 속도 대비 품질 균형을 제공하고, 다양한 입력 해상도를 지원하며, CPU와 GPU 모두에서 실행됩니다. SigLIP-2는 기존 CLIP과 같은 이전 모델에 비해 야외 촬영에 더욱 견고하게 설계되었습니다. 테스트하는 동안 SigLIP-2는 일관되게 신뢰할 수 있는 결과를 생성했습니다. 또한 지원도 매우 잘 되어 있어 이 프로젝트의 확실한 선택이 될 것입니다.

다음으로 임베딩과 파워 검색을 저장할 벡터 데이터베이스가 필요합니다. 이미지 임베딩에 대한 코사인 kNN 검색을 지원할 뿐만 아니라 단일 쿼리에서 지오펜스 및 텍스트 필터를 적용할 수 있어야 합니다. Elasticsearch는 벡터(dense_vector 필드의 HNSW kNN)를 매우 잘 처리하고 텍스트, 벡터, 위치 기반 쿼리를 결합하는 하이브리드 검색을 지원하며 필터링과 정렬 기능을 기본으로 제공합니다. 또한 수평으로 확장할 수 있어 몇 장의 사진에서 수천 장으로 쉽게 늘릴 수 있습니다. 공식 Elasticsearch Python 클라이언트는 배관을 단순하게 유지하며 프로젝트와 깔끔하게 통합됩니다. 마지막으로 검색 쿼리를 입력하고 결과를 볼 수 있는 경량 프론트엔드가 필요합니다. 파이썬 기반의 빠른 데모를 원한다면 Streamlit이 적합합니다. 파일 업로드, 반응형 이미지 그리드, 정렬 및 지오펜싱을 위한 드롭다운 메뉴 등 우리에게 필요한 기본 요소를 제공합니다. 로컬에서 쉽게 복제하고 실행할 수 있으며 Colab 노트북에서도 작동합니다.

구현

Elasticsearch 인덱싱 설계 및 인덱싱 전략

이 프로젝트에는 peaks_catalog 와 photos 의 두 가지 인덱스를 사용할 것입니다.

Peaks_catalog 인덱스

이 색인은 에베레스트 베이스캠프 트레킹 중에 볼 수 있는 주요 산봉우리를 간결하게 정리한 카탈로그 역할을 합니다. 이 색인에 포함된 각 문서는 에베레스트 산과 같은 하나의 산봉우리에 해당합니다. 각 산봉우리 문서에는 이름/별칭, 위도-경도 좌표(선택 사항), SigLIP-2 텍스트 프롬프트(+ 참조 이미지 옵션)를 혼합하여 구축한 단일 프로토타입 벡터가 저장됩니다.

인덱스 매핑:

필드

유형

예

목적/참고 사항

벡터/인덱싱

id

키워드

아마다블람

안정적인 슬러그/ID

-

이름

텍스트 + 키워드 하위 필드

["아마다블람","아마다블람"]

별칭/다국어 이름; 정확한 필터를 위한 names.raw

-

latlon

geo_point

{"lat":27.8617,"lon":86.8614}

위도/경도 조합의 피크 GPS 좌표(선택 사항)

-

elev_m

정수

6812

고도(선택 사항)

-

text_embed

dense_vector

768

이 피크에 대한 혼합 프로토타입(프롬프트 및 선택적으로 1~3개의 참조 이미지)

index:true, 유사성:"코사인", index_옵션:{type:"hnsw", m:16, ef_construction:128}

이 색인은 주로 이미지에서 산봉우리를 식별하는 등 이미지 대 이미지 검색에 사용됩니다. 또한 이 인덱스를 사용하여 텍스트-이미지 검색 결과를 개선합니다.

peaks_catalog 요약하면, "어떤 산입니까?" 라는 질문을 가장 가까운 이웃에 초점을 맞춘 문제로 변환하여 이미지 데이터의 복잡성에서 개념적 이해를 효과적으로 분리하는 것입니다.

peaks_catalog 인덱스의 인덱싱 전략: EBC 트레킹 중 가장 눈에 띄는 봉우리 목록을 만드는 것부터 시작합니다. 각 봉우리에 대해 지리적 위치, 이름, 동의어, 고도를 yaml 파일에 저장합니다. 다음 단계는 각 피크에 대한 임베딩을 생성하여 text_embed 필드에 저장하는 것입니다. 강력한 임베딩을 생성하기 위해 다음 기술을 사용합니다:

• 다음을 사용하여 텍스트 프로토타입을 만듭니다:

  • 봉우리 이름

  • 프롬프트 앙상블 (여러 개의 다른 프롬프트를 사용하여 동일한 질문에 답하기) 등을 예로 들 수 있습니다:

    • "네팔 히말라야의 산봉우리 {name} 의 자연 사진"

    • "{name} 쿰부 지역의 랜드마크 봉우리, 고산 풍경"

    • "{name} 산 정상, 눈, 바위 능선"

  • 선택적 안티 콘셉트 (SigLIP-2에 일치하지 않을 대상을 알려줌): '그림, 일러스트, 포스터, 지도, 로고'에 대해 작은 벡터를 빼서 실제 사진에 편향되도록 합니다.

• 피크의 참조 이미지가 제공된 경우 선택적으로 이미지 프로토타입을 생성합니다.

그런 다음 텍스트와 이미지 프로토타입을 혼합하여 최종 임베딩을 생성합니다. 마지막으로 모든 필수 필드가 포함된 문서가 색인됩니다:

peaks_catalog 색인의 샘플 문서입니다:

사진 색인

이 기본 색인은 앨범의 모든 사진에 대한 자세한 정보를 저장합니다. 각 문서는 다음 정보를 포함하는 단일 사진을 나타냅니다:

• 사진 앨범에서 사진의 상대 경로입니다. 검색 UI에서 일치하는 이미지를 보거나 이미지를 로드하는 데 사용할 수 있습니다.

• 사진의 GPS 및 시간 정보.

• SigLIP-2에서 생성된 이미지 인코딩을 위한 고밀도 벡터입니다.

• predicted_peaks 를 사용하면 피크 이름을 기준으로 필터링할 수 있습니다. 인덱스 매핑

필드

유형

예

목적/참고 사항

벡터 / 인덱싱

경로

키워드

데이터/이미지/IMG_1234.HEIC

UI에서 썸네일/전체 이미지를 여는 방법

-

clip_image

dense_vector

768

SigLIP-2 이미지 임베딩

index:true, 유사성:"코사인", index_옵션:{type:"hnsw", m:16, ef_construction:128}

예측된 피크

키워드

["아마다블람","푸모리"]

인덱스 시점의 Top-K 추측(저렴한 UX 필터/패싯)

-

gps

geo_point

{"lat":27.96,"lon":86.83}

지리적 필터 사용

-

shot_time

date

2023-10-18T09:41:00Z

캡처 시간: 정렬/필터링

-

사진 색인 색인 전략: 앨범의 각 사진에 대해 다음을 수행합니다: 이미지 메타데이터에서 이미지 shot_time 및 gps 정보를 추출합니다.

• SigLIP-2 이미지 임베딩: 이미지를 모델에 전달하고 벡터를 L2 정규화합니다. clip_image 필드에 임베딩을 저장합니다.

• 피크를 예측하여 predicted_peaks 필드에 저장합니다. 이를 위해 먼저 이전 단계에서 생성된 사진의 이미지 벡터를 가져온 다음 peaks_catalog 인덱스의 text_embed 필드에 대해 빠른 kNN 검색을 실행합니다. 상위 3~4개 봉우리는 유지하고 나머지는 무시합니다.

• 이미지 이름과 경로에 해시를 수행하여 _id 필드를 계산합니다. 이렇게 하면 여러 번 실행한 후에도 중복이 발생하지 않습니다.

사진의 모든 필드를 결정한 후에는 일괄 색인을 사용하여 사진 문서를 일괄 색인합니다:

사진 색인의 샘플 문서입니다:

요약하자면, 사진 인덱스는 앨범에 있는 모든 사진을 빠르고 필터링이 가능하며 kNN으로 저장할 수 있는 저장소입니다. 매핑은 일부러 최소화하여 빠르게 검색하고, 깔끔하게 표시하고, 공간과 시간별로 결과를 분류할 수 있는 구조로만 구성했습니다. 이 인덱스는 두 가지 검색 사용 사례를 모두 지원합니다. 두 인덱스를 생성하는 Python 스크립트는 여기에서 찾을 수 있습니다.

아래의 Kibana 지도 시각화에서는 사진 앨범의 문서를 녹색 점으로, peaks_catalog 인덱스의 산봉우리를 빨간색 삼각형으로 표시하며, 녹색 점이 에베레스트 베이스캠프 트레킹 코스와 잘 정렬되어 있습니다.

검색 사용 사례

이름으로 검색(텍스트-이미지): 이 기능을 사용하면 텍스트 검색을 통해 산봉우리 사진(및 '기도 깃발'과 같은 추상적인 개념까지)을 찾을 수 있습니다. 이를 위해 텍스트 입력은 SigLIP-2를 사용하여 텍스트 벡터로 변환됩니다. 강력한 텍스트 벡터 생성을 위해 인덱스에서 텍스트 임베딩을 생성할 때와 동일한 전략을 peaks_catalog 사용합니다. 즉, 텍스트 입력을 작은 프롬프트 앙상블과 결합하고, 작은 반개념 벡터를 뺀 다음 L2 정규화를 적용하여 최종 쿼리 벡터를 생성하는 것입니다. 그런 다음 photos.clip_image 필드에서 kNN 쿼리를 실행하여 가장 가까운 이미지를 찾기 위해 코사인 유사성을 기반으로 가장 일치하는 상위 피크를 검색합니다. 선택적으로 지역 및 날짜 필터를 적용하거나 photos.predicted_peaks 용어 필터를 쿼리의 일부로 적용하여 검색 결과의 연관성을 높일 수 있습니다(아래 쿼리 예시 참조). 이렇게 하면 트레킹에서 실제로 보이지 않는 유사 봉우리를 제외하는 데 도움이 됩니다.

지리적 필터를 사용한 Elasticsearch 쿼리:

이미지로 검색(이미지 대 이미지): 이 기능을 사용하면 사진에서 산을 식별하고 사진 앨범 내에서 같은 산의 다른 이미지를 찾을 수 있습니다. 이미지가 업로드되면 SigLIP-2 이미지 인코더가 이미지를 처리하여 이미지 벡터를 생성합니다. 그런 다음 peaks_catalog.text_embed 필드에서 kNN 검색을 수행하여 가장 일치하는 피크 이름을 식별합니다. 그 후, 일치하는 피크 이름에서 텍스트 벡터를 생성하고 사진 인덱스에서 또 다른 kNN 검색을 수행하여 해당 사진을 찾습니다.

Elasticsearch 쿼리:

1단계: 일치하는 피크 이름 찾기

2단계: photos 색인에서 검색을 수행하여 일치하는 사진을 찾습니다(텍스트-이미지 검색 사용 사례에 표시된 것과 동일한 쿼리):

스트림라이트 UI

모든 것을 하나로 모으기 위해 두 가지 검색 사용 사례를 모두 수행할 수 있는 간단한 Streamlit UI를 만들었습니다. 왼쪽 레일에는 스크롤 가능한 피크 목록( photos.predicted_peaks 에서 집계됨)이 체크박스와 미니맵/지리 필터와 함께 표시됩니다. 상단에는 이름으로 검색하기 상자와 사진 업로드에서 식별하기 버튼이 있습니다. 가운데 창에는 반응형 썸네일 그리드가 있어 kNN 점수, 예상 피크 배지, 캡처 시간을 보여줍니다. 각 이미지에는 전체 해상도 미리 보기를 위한 이미지 보기 버튼이 포함되어 있습니다.

이미지를 업로드하여 검색합니다: 피크를 예측하고 사진 앨범에서 일치하는 피크를 찾습니다.

텍스트로 검색: 텍스트에서 앨범에서 일치하는 피크 찾기

결론

아마 다블람 사진만 볼 수 있나요? 를 작고 작동하는 멀티모달 검색 시스템으로 전환했습니다. 우리는 원시 트레킹 사진을 찍어 SigLIP-2 임베딩으로 변환하고, Elasticsearch를 사용해 벡터를 통한 빠른 kNN과 간단한 지리적/시간 필터를 통해 의미별로 적합한 이미지를 표시했습니다. 그 과정에서 저희는 혼합된 프로토타입의 작은 peaks_catalog 인덱스(식별용)와 이미지 벡터 및 EXIF의 확장 가능한 photos 인덱스(검색용) 등 두 가지 인덱스를 사용하여 문제를 분리했습니다. 실용적이고 재현 가능하며 쉽게 확장할 수 있습니다.

튜닝을 원한다면 몇 가지 설정으로 조정할 수 있습니다:

• 쿼리 시간 설정: k (반환할 이웃 수) 및 num_candidates (최종 점수 산출 전 검색 범위). 이러한 설정은 여기 블로그에서 설명합니다.

• 인덱스 시간 설정: m (그래프 연결성) 및 ef_construction (빌드 시간 정확도 대 메모리). 쿼리의 경우 ef_search 을 너무 높게 설정하면 일반적으로 약간의 지연 시간 절충을 통해 더 나은 리콜을 얻을 수 있습니다. 이러한 설정에 대한 자세한 내용은 이 블로그를 참조하세요.

앞으로 멀티모달 및 다국어 검색을 위한 기본 모델/랭커가 곧 Elastic 생태계에 출시될 예정이므로 이미지/텍스트 검색과 하이브리드 랭킹이 더욱 강력해질 것입니다. ir.elastic.co+1

직접 체험해보고 싶으신가요?

• GitHub 리포지토리: https://github.com/navneet83/multimodal-mountain-peak-search

• Colab 빠른 시작: https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

이것으로 우리의 여정은 끝났고 이제 돌아올 시간입니다. 도움이 되었기를 바라며, 이 기능을 중단(또는 개선)하신다면 어떤 점이 달라졌는지 알려주시기 바랍니다.

이러한 노력의 '큰 그림'에 대해 자세히 알아보려면 Elasticsearch로 AI 에이전트 워크플로우 구축 블로그 또는 첫 번째 Elastic 에이전트를 읽어보세요: 단일 쿼리에서 AI 기반 채팅까지에서 보다 실용적인 입문서를 읽어보세요.

하지만 이 블로그에서는 채팅을 시작할 때 가장 먼저 일어나는 일 중 하나를 조금 더 자세히 살펴보고 최근 개선된 몇 가지 사항을 안내해드리려고 합니다.

여기서 무슨 일이 일어나고 있나요?

Elasticsearch 데이터와 채팅할 때 기본 AI 에이전트가 이 표준 플로우를 안내합니다:

1. 프롬프트를 확인합니다.

2. 해당 프롬프트에 대한 답변이 포함되어 있을 가능성이 높은 인덱스를 식별합니다.

3. 프롬프트에 따라 해당 인덱스에 대한 쿼리를 생성합니다.

4. 해당 쿼리로 해당 인덱스를 검색합니다.

5. 결과를 종합합니다.

6. 결과가 프롬프트를 해결할 수 있나요? 그렇다면 응답하세요. 그렇지 않다면 반복하되 다른 것을 시도하세요.

검색 증강 세대(RAG)에 불과하기 때문에 너무 새롭지 않을 것입니다. 예상대로 응답의 품질은 초기 검색 결과의 관련성에 따라 크게 달라집니다. 따라서 응답 품질을 개선하기 위해 노력하면서 3단계에서 생성하고 4단계에서 실행하는 쿼리에 매우 세심한 주의를 기울이고 있습니다. 그리고 흥미로운 패턴을 발견했습니다.

첫 번째 응답이 '나쁨'인 경우가 종종 있었는데, 이는 쿼리를 잘못 실행했기 때문이 아니었습니다. 쿼리할 인덱스를 잘못 선택했기 때문입니다. 3단계와 4단계는 보통 2단계가 문제가 되지 않았습니다.

우리가 뭘 하고 있었나요?

초기 구현은 간단했습니다. 저희는 _cat/indices 을 통해 사용 가능한 모든 인덱스를 나열한 다음, 이 인덱스 중 사용자의 메시지/질문/프롬프트에 가장 적합한 인덱스를 식별하도록 LLM에 요청하는 도구(index_explorer라고 함)를 구축했습니다. 이 원본 구현은 여기에서 확인할 수 있습니다.

얼마나 잘 작동했나요? 확실하지 않았습니다! 잘 작동하지 않는 사례는 분명 있었지만, 현재 상태를 정량화하는 것이 첫 번째 과제였습니다.

기준선 설정

데이터에서 시작됩니다.

우리에게 필요했던 것은 사용자 프롬프트와 기존 인덱스 세트가 주어졌을 때 올바른 인덱스를 선택하는 도구의 효율성을 측정하기 위한 골든 데이터 세트였습니다. 그런 데이터 세트가 없었기 때문에 저희가 직접 생성했습니다.

인정합니다: 이것이 '모범 사례'는 아니라는 것을 알고 있습니다. 하지만 때로는 자전거를 타는 것보다 앞으로 나아가는 것이 더 나을 때도 있습니다. 진행, 심플한 완벽함.

이 프롬프트를 사용하여 여러 다른 도메인에 대한 시드 인덱스를 생성했습니다. 그런 다음 생성된 각 도메인에 대해 이 프롬프트를 사용하여 몇 가지 인덱스를 더 생성했습니다(여기서 목표는 하드 네거티브와 분류하기 어려운 예시로 LLM에 혼란을 심어주는 것입니다). 다음으로, 생성된 각 인덱스와 그 설명을 수동으로 편집했습니다. 마지막으로 이 프롬프트를 사용하여 테스트 쿼리를 생성했는데, 다음과 같은 샘플 데이터가 남았습니다:

와 같은 테스트 사례:

테스트 하네스 제작하기

여기서부터의 과정은 매우 간단했습니다. 가능한 도구를 스크립트로 작성하세요:

1. 대상 Elasticsearch 클러스터로 클린 슬레이트를 설정하세요.

2. 대상 데이터 세트에 정의된 모든 인덱스를 생성합니다.

3. 각 테스트 시나리오에 대해 index_explorer 도구를 실행합니다(편리하게도 도구 실행 API가 있습니다).

4. 결과 인덱스와 예상 인덱스를 비교하고 결과를 캡처합니다.

5. 모든 테스트 시나리오를 완료한 후 결과를 표로 작성합니다.

설문조사에 따르면...

초기 결과는 당연히 평범했습니다.

전반적으로 77.14% 올바른 인덱스를 식별하는 데 정확합니다. 그리고 이것은 모든 인덱스에 의미적으로 의미 있는 좋은 이름이 있는 '최상의 경우'의 시나리오입니다. PUT test2/_doc/foo {...}`를 해본 사람이라면 누구나 인덱스에 항상 의미 있는 이름이 있는 것은 아니라는 것을 알고 있습니다.

따라서 우리는 기준선을 가지고 있으며 개선의 여지가 많이 있음을 보여줍니다. 이제 과학이 필요한 시간입니다! 🧪

실험

가설 1: 매핑이 도움이 될 것입니다.

여기서 목표는 원래 프롬프트와 관련된 데이터를 포함할 인덱스를 식별하는 것입니다. 그리고 인덱스에 포함된 데이터를 가장 잘 설명하는 부분은 인덱스의 매핑입니다. 인덱스 콘텐츠의 샘플을 가져오지 않더라도 인덱스에 double 유형의 가격 필드가 있다는 것은 데이터가 판매할 상품을 나타낸다는 것을 의미합니다. 텍스트 유형의 작성자 필드는 일부 구조화되지 않은 언어 데이터를 의미합니다. 이 두 가지를 합치면 데이터가 책/이야기/시라는 것을 암시할 수 있습니다. 인덱스의 속성을 아는 것만으로도 많은 의미론적 단서를 얻을 수 있습니다. 그래서 로컬 브랜치에서 '.index_explorer`를 조정했습니다. 도구를 사용하여 인덱스의 전체 매핑(이름과 함께)을 LLM에 전송하여 결정을 내릴 수 있습니다.

결과(Kibana 로그에서 가져온):

이 도구의 초기 개발자는 이러한 문제를 예상하고 있었습니다. 인덱스의 매핑은 정보를 얻을 수 있는 금광이지만, 상당히 장황한 JSON 블록이기도 합니다. 그리고 수많은 인덱스(평가 데이터 세트는 20개를 정의함)를 비교하는 현실적인 시나리오에서는 이러한 JSON 블롭이 합쳐집니다. 따라서 모든 옵션에 대한 인덱스 이름뿐만 아니라 각 옵션의 전체 매핑이 아닌 더 많은 컨텍스트를 LLM에 제공하여 결정에 도움을 주고자 합니다.

가설 2: 절충안으로 '플랫화' 매핑(필드 목록) 사용

우리는 인덱스 작성자가 의미론적으로 의미 있는 인덱스 이름을 사용한다는 가정에서 시작했습니다. 이 가정을 필드 이름으로도 확장하면 어떨까요? 이전 실험은 실패했는데, 그 이유는 JSON 매핑에 복잡한 메타데이터와 상용구가 많이 포함되어 있었기 때문입니다.

예를 들어, 위의 블록은 236자이며 Elasticsearch 매핑에서 단 하나의 필드만 정의합니다. 반면 "description_text" 문자열은 16자에 불과합니다. 이는 문자 수가 거의 15배 증가한 것이지만, 해당 필드가 사용 가능한 데이터에 대해 의미하는 바를 설명하는 데 있어 의미 있는 의미 개선은 없습니다. 모든 인덱스에 대한 매핑을 가져오되, LLM으로 보내기 전에 필드 이름 목록으로만 '플랫화'하면 어떨까요?

저희도 사용해 보았습니다.

정말 멋지네요! 전반적으로 개선되었습니다. 하지만 더 잘할 수 있을까요?

가설 3: 매핑 _meta의 설명

추가 컨텍스트 없이 필드 이름만으로 그렇게 많은 점프가 발생했다면, 아마도 상당한 컨텍스트를 추가하는 것이 더 좋을 것입니다! 모든 인덱스에 반드시 설명을 첨부해야 하는 것은 아니지만, 매핑의 _meta 객체에 모든 종류의 인덱스 수준 메타데이터를 추가할 수 있습니다. 생성된 인덱스로 돌아가서 데이터 세트의 모든 인덱스에 대한 설명을 추가했습니다. 설명이 지나치게 길지 않다면 전체 매핑보다 적은 토큰을 사용하고 인덱스에 포함된 데이터에 대한 훨씬 더 나은 인사이트를 제공해야 합니다. 실험을 통해 이 가설을 검증했습니다.

소폭의 개선으로 이제 >90% 전반적으로 정확해졌습니다.

가설 4: 합이 부분보다 큼

필드 이름을 사용하면 결과가 향상되었습니다. 설명을 통해 결과가 향상되었습니다. 따라서 설명과 필드 이름을 모두 활용하면 더 나은 결과를 얻을 수 있겠죠?

데이터는 "아니오"라고 응답했습니다(이전 실험에서 변경 사항 없음). 여기서 유력한 이론은 설명이 처음부터 인덱스 필드/매핑에서 생성되었기 때문에 이 두 컨텍스트 간에 서로 다른 정보가 충분하지 않아 결합할 때 '새로운' 것을 추가하는 데 도움이 되지 않는다는 것입니다. 또한 20개의 테스트 지수에 대해 전송하는 페이로드가 상당히 커지고 있습니다. 지금까지 우리가 따라온 사고방식은 확장할 수 없습니다. 사실, 지금까지의 실험 중 어떤 것도 수백, 수천 개의 인덱스가 있는 Elasticsearch 클러스터에서는 작동하지 않을 것이라고 믿을 만한 충분한 이유가 있습니다. 인덱스의 총 수가 증가함에 따라 LLM으로 전송되는 메시지 크기를 선형적으로 증가시키는 접근 방식은 일반화할 수 있는 전략이 아닐 수 있습니다.

우리에게 정말 필요한 것은 수많은 후보를 가장 관련성이 높은 옵션으로 좁히는 데 도움이 되는 접근 방식입니다....

여기에는 검색 문제가 있습니다.

가설 5: 시맨틱 검색을 통한 선택

인덱스 이름에 의미론적 의미가 있는 경우, 벡터로 저장하여 의미론적으로 검색할 수 있습니다.

인덱스의 필드 이름에 의미론적 의미가 있는 경우, 이를 벡터로 저장하고 의미론적으로 검색할 수 있습니다.

인덱스에 의미론적 의미가 있는 설명이 있는 경우, 이 역시 벡터로 저장하고 의미론적으로 검색할 수 있습니다.

오늘날 Elasticsearch 인덱스는 이러한 정보를 검색할 수 없지만(어쩌면 그렇게 해야 할지도 모릅니다!), 그 차이를 해결할 수 있는 무언가를 함께 해킹하는 것은 꽤나 사소한 일이었습니다. Elastic의 커넥터 프레임워크를 사용해 클러스터의 모든 인덱스에 대한 문서를 출력하는 커넥터를 구축했습니다. 출력 문서는 다음과 같은 형태가 됩니다:

저는 이 문서들을 수동으로 매핑을 정의한 새 인덱스로 보냈습니다:

이렇게 하면 의미론적 의미를 가진 다른 모든 필드가 청크업되어 색인되는 단일 semantic_content 필드가 생성됩니다. 이 인덱스를 검색하는 것은 사소한 일이 됩니다:

수정된 index_explorer 도구는 이제 LLM에 요청할 필요 없이 주어진 쿼리에 대해 단일 임베딩을 요청하고 효율적인 벡터 검색 작업을 수행할 수 있으므로 훨씬 더 빨라졌습니다. 상위 히트를 선택한 지표로 삼은 결과 다음과 같은 결과를 얻었습니다:

이 접근 방식은 확장 가능합니다. 이 접근 방식은 효율적입니다. 하지만 이 접근 방식은 기준선보다 겨우 나은 수준입니다. 하지만 이는 놀라운 일이 아닙니다. 검색 접근 방식이 매우 순진하기 때문입니다. 뉘앙스가 없습니다. 인덱스의 이름과 설명이 인덱스에 포함된 임의의 필드 이름보다 더 많은 가중치를 가져야 한다는 인식이 없습니다. 동의어 일치보다 정확한 어휘 일치에 가중치를 부여하는 어포던스는 없습니다. 그러나 고도로 미묘한 쿼리를 작성하려면 현재 데이터에 대해 많은 것을 가정해야 합니다. 지금까지 인덱스와 필드 이름에 의미론적 의미가 있다는 큰 가정을 해 보았지만, 한 걸음 더 나아가서 얼마나 많은 의미를 가지고 있으며 서로 어떻게 연관되어 있는지 가정해 볼 필요가 있습니다. 이렇게 하지 않으면 최상의 일치 항목을 최고의 결과로 확실하게 식별할 수는 없지만, 상위 N개의 결과 중 어딘가에 최상의 일치 항목이 있다고 말할 수 있습니다. 우리는 의미론적 정보가 존재하는 맥락에서 의미론적 정보를 소비하고, 의미론적으로 구별되는 방식으로 자신을 표현할 수 있는 다른 개체와 비교하여 그 둘을 판단할 수 있는 무언가가 필요합니다. LLM처럼요.

가설 6: 후보 세트 감소

이 외에도 여러 가지 실험이 있었지만, 핵심적인 돌파구는 시맨틱 검색만으로 최적의 일치 항목을 고르려는 욕구를 버리고 대신 시맨틱 검색을 필터로 활용하여 LLM의 고려 대상에서 관련 없는 인덱스를 걸러내는 것이었습니다. 검색을 위해 선형 검색기, 하이브리드 검색과 RRF, semantic_text 를 결합하여 상위 5개 일치하는 인덱스로 결과를 제한했습니다.

그런 다음 각 일치 항목에 대해 인덱스의 이름, 설명 및 필드 이름을 LLM용 메시지에 추가했습니다. 결과는 환상적이었습니다:

역대 실험 중 가장 높은 정확도! 또한 이 접근 방식은 총 인덱스 수에 비례하여 메시지 크기가 증가하지 않기 때문에 훨씬 더 확장성이 뛰어납니다.

결과

첫 번째 분명한 결과는 우리의 기준선을 개선할 수 있다는 것이었습니다. 지금 생각하면 당연해 보이지만 실험을 시작하기 전에는 index_explorer 도구를 완전히 버리고 검색 공간을 제한하기 위해 사용자의 명시적 설정에 의존해야 하는지에 대해 진지한 논의가 있었습니다. 여전히 실행 가능하고 유효한 옵션이지만, 이 연구는 이러한 사용자 입력을 사용할 수 없는 경우 인덱스 선택을 자동화하는 방향으로 나아갈 수 있는 유망한 경로가 있음을 보여줍니다.

다음으로 분명한 결과는 문제에 더 많은 설명 문자를 던지는 것만으로는 수익이 줄어든다는 것이었습니다. 이 연구 이전에는 필드 수준 메타데이터를 저장하기 위해 Elasticsearch의 기능을 확장하는 데 투자해야 할지 고민하고 있었습니다. 현재 meta 값은 50자로 제한되어 있으며, 필드의 의미적 이해를 도출하기 위해서는 이 값을 늘려야 한다는 가정이 있었습니다. 이는 분명히 사실이 아니며, LLM은 필드 이름만으로 상당히 잘 작동하는 것 같습니다. 나중에 더 조사할 수 있지만 더 이상 시급하다고 생각하지 않습니다.

반대로, 이는 '검색 가능한' 인덱스 메타데이터의 중요성에 대한 명확한 증거가 되었습니다. 이 실험을 위해 저희는 인덱스 오브 인덱스를 해킹했습니다. 그러나 이것은 Elasticsearch에 직접 구축하거나, 관리할 API를 구축하거나, 최소한 관련 규칙을 수립하는 것을 검토할 수 있는 부분입니다. 여러 옵션을 검토하고 내부적으로 논의 중이니 계속 지켜봐 주시기 바랍니다.

마지막으로, 이러한 노력을 통해 시간을 들여 실험하고 데이터 기반 의사 결정을 내리는 것이 얼마나 가치 있는 일인지 확인했습니다. 실제로 에이전트 빌더 제품에 강력한 제품 내 평가 기능이 필요하다는 것을 재확인하는 데 도움이 되었습니다. 인덱스를 선택하는 도구만을 위한 전체 테스트 하네스를 구축해야 한다면, 고객은 반복적으로 조정할 때 사용자 지정 도구를 정성적으로 평가할 수 있는 방법이 반드시 필요합니다.

앞으로 무엇을 만들게 될지 기대가 되며, 여러분도 기대가 되시길 바랍니다!

리니어 리트리버를 만나보세요!

이 게시물에서는 하이브리드 검색을 지원하는 최신 기능인 linear 리트리버를 소개합니다! rrf 과 달리 linear 검색기는 문서와 일치하는 모든 쿼리에 대해 가중 합계를 계산합니다. 이 접근 방식은 결과 집합 내에서 각 문서의 상대적 중요도를 유지하면서 각 쿼리가 최종 점수에 미치는 영향을 정밀하게 제어할 수 있습니다. 그 결과, 하이브리드 검색을 보다 직관적이고 유연하게 미세 조정할 수 있는 방법을 제공합니다.

최종 점수가 계산될 리니어 리트리버를 정의합니다:

간단합니다:

얼마나 간단하고 직관적인지 아시나요? (그리고 rrf 와 정말 비슷합니다!) 이 구성을 사용하면 상대 순위에만 의존하는 rrf 과 달리 각 쿼리 유형이 최종 순위에 기여하는 정도를 정밀하게 제어할 수 있습니다.

한 가지 주의할 점은 사용된 유사성 측정지표에 따라 knn 점수가 엄격하게 제한될 수 있다는 점입니다. 예를 들어 코사인 유사도 또는 단위 정규화된 벡터의 도트 곱을 사용하면 점수는 항상 [0, 1] 범위 내에 있습니다. 반면 bm25 점수는 예측 가능성이 낮고 범위가 명확하게 정의되어 있지 않습니다.

점수 확장: kNN 대 BM25

하이브리드 검색의 한 가지 문제점은 검색기마다 다른 척도로 점수를 산출한다는 점입니다. 예를 들어 다음 시나리오를 생각해 보세요:

쿼리 A 점수:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

쿼리 B 점수:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

0.63

0.01

0.3

0.4

kNN 점수는 0에서 1 사이의 범위인 반면 bm25 점수는 매우 다양합니다. 이러한 차이로 인해 결과 결합을 위한 정적 최적 가중치를 설정하기가 까다롭습니다.

구원의 정규화: MinMax 정규화 도구

이 문제를 해결하기 위해 다음 공식을 사용하여 각 쿼리에 대해 독립적으로 점수를 [0, 1] 범위로 확장하는 minmax 정규화기(선택 사항)를 도입했습니다:

이렇게 하면 쿼리 결과 집합 내에서 각 문서의 상대적 중요도가 유지되므로 서로 다른 검색기의 점수를 쉽게 결합할 수 있습니다. 정규화를 사용하면 점수는 다음과 같이 됩니다:

쿼리 A 점수:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.01

0.005

0.000

쿼리 B 점수:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.000

0.465

0.645

이제 모든 점수는 [0, 1] 범위에 속하며, 절대 점수 대신 결과의 (쿼리 대비) 중요도를 파악하고 쿼리 간 일관성을 유지하므로 가중치 합계를 최적화하는 것이 훨씬 더 간단해졌습니다.

리니어 리트리버 예시

이제 예제를 통해 위의 내용이 어떻게 보이는지, linear 리트리버가 rrf 의 몇 가지 단점을 어떻게 해결하는지 살펴보도록 하겠습니다. RRF는 상대적인 순위에만 의존하며 실제 점수 차이는 고려하지 않습니다. 예를 들어 다음과 같은 점수가 주어집니다:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

RRF 점수

0.03226

0.03252

0.03200

0.03125

rrf는 문서의 순위를 매깁니다:

그러나 doc1은 다른 문서보다 bm25 점수가 훨씬 높은데, rrf 은 상대적인 순위만 보기 때문에 이를 포착하지 못합니다. 정규화와 결합된 linear 리트리버는 점수와 그 차이를 모두 정확하게 설명하여 보다 의미 있는 순위를 생성합니다:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1

0.01

0.005

0

위에서 볼 수 있듯이 doc1의 높은 순위와 score 의 bm25 이 적절히 고려되어 최종 점수에 반영되었습니다. 또한 모든 점수는 이제 [0, 1] 범위 내에 있으므로 훨씬 더 직관적인 방식으로 비교하고 결합할 수 있으며 오프라인 최적화 프로세스도 구축할 수 있습니다.

모든 것을 종합하기

정규화를 통해 linear 검색기를 최대한 활용하려면 검색 요청은 다음과 같이 표시되어야 합니다:

이 접근 방식은 linear 리트리버의 유연성과 직관적인 채점 방식을 유지하면서 MinMax 정규화를 통해 일관된 점수 확장을 보장하는 두 가지 장점을 결합한 것입니다.

모든 리트리버와 마찬가지로 linear 리트리버는 설명 기능, 일치 항목 강조 표시, 필드 축소 등을 지원하여 계층적 리트리버 트리의 모든 레벨에 통합할 수 있습니다.

리니어 리트리버를 선택해야 하는 시기 및 리니어 리트리버가 차이를 만드는 이유

linear 리트리버:

• 단순한 순위가 아닌 실제 점수를 활용하여 상대적 중요도를 유지합니다.

• 다양한 쿼리의 가중치 기여도를 사용하여 미세 조정할 수 있습니다.

• 정규화를 사용하여 일관성을 향상시켜 하이브리드 검색을 더욱 강력하고 예측 가능하게 만듭니다.

결론

linear 리트리버는 이미 Elasticsearch 서버리스와 8.18 및 9.0 릴리즈에서 사용할 수 있습니다! 더 많은 예제와 구성 매개변수는 문서에서도 확인할 수 있습니다. 직접 사용해보고 하이브리드 검색 환경을 개선하는 방법을 알아보세요. 여러분의 피드백을 기다리겠습니다. 즐거운 검색 되세요!