MATCH 및 TO_TEXT가 모든 ES|QL 표현식에 대한 풀텍스트 검색을 가능하게 하는 방법

먼저 Elasticsearch 9.4에서 불가능했던 쿼리부터 시작하겠습니다. 이 쿼리는 EVAL 명령을 사용합니다.

이 예시에서 요약에는 매핑이나 분석기 구성이 없습니다. 또한 어떤 역 인덱스와도 연관이 없습니다. 이 쿼리의 수명 동안에만 존재하지만, 이제는 검색할 수 있습니다. 두 가지 추가 요소가 이를 가능하게 합니다.

첫째, MATCH는 이제 첫 번째 인수로 매핑된 필드뿐만 아니라 모든 표현식을 지원합니다. 여기에는 EVAL에서 생성된 열과 인라인에서 사용되는 함수 결과도 포함됩니다. 또한 원본 문서에서 직접 불러온 매핑되지 않은 필드도 포함됩니다. 뿐만 아니라, MATCH에서 일반적으로 허용되는 모든 데이터 타입이 이 새로운 사용 사례에서 지원됩니다.

두 번째 부분은 새로운 TO_TEXT 함수로, 텍스트 형식의 출력을 생성하는 최초의 ES|QL 변환 함수입니다. 지금까지 텍스트 열은 인덱스에 매핑된 필드에서만 나올 수 있었으며, ES|QL 표현식에서 생성된 모든 스트링은 텍스트가 아닌 키워드 값이었습니다. MATCH는 두 값을 다르게 처리하기 때문에 이 구분이 중요합니다. 텍스트 값은 분석되며, 키워드 값은 정확히 비교되는데, 이는 인덱싱된 키워드 필드에 대한 MATCH 쿼리가 검색어 쿼리로 다시 작성되는 방식을 반영합니다. TO_TEXT(x)는 ES|QL에 이 스트링을 풀텍스트로 처리하도록 지시하는 방법입니다.

이 기능은 Elasticsearch 9.5의 기술 미리보기 버전으로 제공되므로 몇 가지 제한 사항이 있습니다.

• 현재는 필터링만 지원합니다. 표현식에 대한 MATCH는 아직 관련성 점수에 반영되지 않으며, 점수에는 인덱싱된 필드에서의 매치만 영향을 미칩니다.

• 표현식을 매칭할 때 퍼지와 같은 쿼리 옵션은 아직 지원되지 않습니다.

• 런타임 텍스트는 표준 분석기를 사용하여 분석됩니다. 아직 구성할 수 없습니다.

이러한 한계를 해결하기 위한 작업이 진행 중입니다.

ES|QL에서 LIKE 또는 RLIKE 대신 풀텍스트 검색을 사용하는 이유

ES|QL에는 이미 인덱스 없이 스트링을 검색하는 두 가지 방법이 있습니다. LIKE(와일드카드 패턴)와 RLIKE(정규 표현식)입니다. 두 함수 모두 모든 스트링 표현식에서 작동하므로 MATCH 함수가 추가로 제공하는 기능에 당연히 궁금증을 갖게 됩니다. 정답은 분석입니다. 분석은 어간 추출이나 동의어 검색과 같은 기법을 사용하는 고급 검색 방식입니다. 또한 불용어 처리 기능도 사용합니다.

LIKE는 스트링을 구성하는 단어에 대한 이해 없이 단순히 부분 스트링을 매칭하는 연산입니다. 예를 들어, 여우(fox)에 관한 로그 메시지를 찾고 있다고 가정합시다.

대문자 표기로 인해 "Fox spotted near the henhouse"는 놓치게 되고, "Outfoxed by the competition"은 여우와 관련이 없습니다. 대문자 입력에 거짓 음성이 발생하고, 다른 단어들 안에 숨겨진 부분 스트링에 거짓 양성이 나타나 실패합니다.

정규 표현식은 대소문자 문제를 해결할 수 있으나, 단어 경계 문제는 빠르게 복잡해집니다. 예를 들면 다음과 같습니다.

하지만 이조차 아직 완벽하지 않습니다. 문장 끝에 있는 fox 다음에 ! 또는 ?가 뒤따르는 경우 놓치게 되고 탭, 따옴표 또는 괄호에 대해서는 언급이 없습니다. 수정할 때마다 패턴이 길어지고, 다음에 쿼리를 읽는 사람은 실제로 무슨 작업을 하는지 역으로 파악해야 합니다.

MATCH 문을 사용하면 쿼리와 값 모두를 분석기를 통해 처리하여 텍스트를 소문자로 토큰화한 다음 각 검색어를 서로 비교하기 때문에 문제가 해결됩니다.

이 쿼리는 "The quick brown fox"와 "FOX spotted near the henhouse" 같은 값과 일치하지만, "Outfoxed by the competition"이나 "FOXTROT protocol enabled"와는 단어 주변의 구두점과 상관없이 일치하지 않습니다. 물론 이 모든 것은 MATCH(TO_TEXT(message), "brown fox")와 같은 다중 검색어 쿼리에서도 예상대로 작동합니다.

36개의 전용 언어 분석기를 활용할 수 있도록 하는 작업이 진행 중이며, 이 분석기들은 이전에 인덱싱되거나 매핑된 적이 없는 데이터에 대한 자연어 지원을 제공합니다.

인덱싱되지 않고 매핑되지 않은 데이터에 대한 풀텍스트 검색 사용 사례

위의 예시들은 매핑된 필드에서 계산된 값을 검색한 것입니다. 표현식에 ES|QL MATCH를 사용하는 더욱 흥미로운 사용 사례는 이전에는 전혀 검색할 수 없었던 데이터와 관련된 경우입니다. 몇 가지 예를 살펴보겠습니다.

ES|QL에서 매핑을 추가하지 않고 매핑되지 않은 필드를 검색하는 방법

때로는 상세한 스택 추적이나 원시 요청 페이로드와 같은 필드를 매핑에서 의도적으로 제외하는 경우가 있습니다. 디버그 블롭을 생략할 수도 있습니다. 이러한 필드 중 하나를 인덱싱하면 모든 문서에 디스크 및 힙 공간이 소모되므로 분기별로 한 번 정도만 조회할 필드에 대해서는 그럴 만한 가치가 없습니다.

매핑되지 않은 필드는 쿼리에서 전혀 보이지 않았기 때문에 이 결정은 항상 최종적이었습니다. Elasticsearch 9.5에서는 SET unmapped_fields="load"를 사용하여 ES|QL이 원본 문서에서 매핑되지 않은 필드를 키워드로 직접 불러오도록 할 수 있습니다. 그런 다음 TO_TEXT로 감싸면 이제 풀텍스트 검색을 실행할 수 있습니다.

이 예제에서는 stack_trace가 매핑되지 않았습니다. 모든 값은 원본 문서에서 가져와 실시간으로 분석됩니다. 각 행별로 짝이 맞춰져 있습니다. 실제 작업이며, 역 인덱스 조회만큼 빠르지는 않을 것입니다. 하지만 이제 인덱싱하지 않은 필드는 더 이상 검색 불가능하지 않습니다. 일상적인 경우에는 매핑 규모를 작게 유지하면서도, 중요한 시점에는 분기별로 필요한 질문에 답할 수 있습니다.

재인덱싱 없이 키워드 필드에서 풀텍스트 검색 가능

키워드 필드는 많은 기능을 수행할 수 있습니다. 정확한 매칭, 빠른 집계 및 정렬 기능을 제공하므로 많은 필드가 이 방식으로 매핑됩니다. 하지만 매핑은 데이터가 도착할 때 결정되기 때문에, 원래 의도했던 것과 다르게 데이터를 처리하고 싶은 상황이 발생하기 쉽습니다. 대시보드가 product_name을 기준으로 집계하므로 이를 키워드로 매핑되었는데, 1년 치 제품 데이터를 받은 후 누군가가 product_name 값 내에서 검색할 수 있기를 원할 수도 있습니다.

기존 해결책은 매핑을 텍스트로 변경하거나(또는 다중 필드 추가) 모든 것을 다시 인덱싱하는 것입니다. 이는 시간과 비용이 많이 소요될 뿐만 아니라, 많은 경우 사용자가 번거롭게 이 과정을 거치고 싶어 하지 않습니다. 새로운 해결책은 하나의 함수 호출입니다.

TO_TEXT는 키워드 값을 즉석에서 텍스트로 변환합니다. 따라서 MATCH는 키워드 값을 정확히 비교하지 않고 분석합니다. 이렇게 하면 매핑을 만들거나 소스 문서를 다시 인덱싱하지 않고도 키워드 필드를 쿼리할 수 있습니다. 검색이 일상적인 쿼리가 된다면 장기적으로는 필드를 텍스트로 인덱싱하는 것이 여전히 올바른 방법이지만, TO_TEXT를 사용하면 추가 작업 없이 지금 바로 답을 얻을 수 있습니다.

서로 다른 매핑을 가진 인덱스 전반에서 동일한 필드 검색

ES|QL은 여러 인덱스에 걸쳐 사용될 수 있으며, 동일한 필드가 모든 인덱스에서 항상 동일한 형태를 가질 필요는 없습니다. 같은 필드가 서로 다른 인덱스에서 서로 다른 타입을 가질 때, ES|QL은 이를 유니언 타입으로 처리하며, 변환 함수가 충돌을 해결합니다. 올해 인덱싱 템플릿에서는 메시지 필드의 타입이 텍스트이지만 작년에는 키워드였던 경우를 예로 들어 보겠습니다.

쿼리 시점에 텍스트 인덱스든 키워드 인덱스든 모든 값이 분석됩니다. 이전 인덱스의 키워드 값은 다른 모든 것과 마찬가지로 토큰화되고 소문자로 변환되어 있어 “connection reset”은 어떤 인덱스에 있든 “Connection RESET by peer”를 찾습니다.

또 다른 흥미로운 경우는 필드가 한 인덱스에만 매핑되어 있지만 다른 인덱스에도 존재하는(또는 다른 인덱스에는 매핑되지 않은) 경우입니다.

여기서 주목할 만한 미묘한 차이가 있습니다. error_details가 logs-2026에 매핑되어 있고 logs-2025에는 매핑되지 않았다면, Elasticsearch는 이 쿼리를 Lucene으로 푸시할 수 없습니다. 필드가 매핑되지 않은 인덱스에서는 오류나 경고 없이 일치하는 항목이 없다고 표시되기 때문입니다. 대신, 플래너는 해당 필드가 매핑되지 않았을 가능성이 있음을 감지하고 행의 출처와 관계없이 전체 MATCH 행을 하나씩 평가합니다. 어떤 인덱스에 필드가 매핑되었는지 알 필요가 없습니다. 쿼리가 그 질문에 대한 답을 제공합니다.

ES|QL이 쿼리 시점에 역 인덱스 없이 텍스트를 분석하는 방법

ES|QL은 표현식에 대해 MATCH를 계획할 때 쿼리 스트링을 먼저 검색어 집합으로 한 번 분석합니다. 각 행이 어떻게 평가되는지는 표현식의 유형에 따라 다릅니다.

표현식 유형

처리

매칭 동작

텍스트(TO_TEXT 사용)

분석기가 값을 소문자 검색어로 토큰화합니다.

토큰 간 비교. 토큰 중 하나라도 쿼리 검색어와 일치하면 해당 행이 일치하는 것으로 간주합니다(OR 의미론).

키워드, ip, 날짜, 숫자

분석 없이, 쿼리 상수를 네이티브 타입으로 한 번 변환합니다.

행별로 정확하게 비교합니다.

두 경로 모두 Lucene을 완전히 우회하고 값을 행 단위로 평가합니다. 비텍스트 경로는 해당 필드 타입에 대해 Lucene으로 매치 쿼리가 전달될 때 수행하는 작업을 정확히 반영하므로, 쿼리가 인덱스에 도달하든 상관없이 의미가 일관됩니다.

역 인덱스 조회는 인제스트 시점에 작업을 수행하며, 쿼리 시점에는 일치하지 않는 문서에 접근하지 않습니다. 런타임 MATCH는 쿼리 시점에 도달하는 모든 행에 대해 해당 분석을 수행합니다. 전자는 이미 작업이 이루어졌기 때문에 빠르며, 후자는 데이터가 전혀 인덱싱될 필요가 없어서 유연합니다.

ES|QL 풀텍스트 검색의 다음 단계

이 게시물의 모든 내용은 ES|QL에서의 검색이 미리 인덱싱한 항목뿐만 아니라 모든 항목에서 작동하도록 하려는 대규모 노력의 첫 번째 단계를 나타냅니다. 앞서 언급된 제한 사항들은 현재 적극적으로 개선 작업이 진행 중이며, 향후 로드맵은 더욱 발전할 것입니다.

• 점수. 런타임 매치는 _score에 기여하므로, 데이터가 인덱싱되지 않았더라도 관련성에 따라 정렬할 수 있습니다.

• MATCH_PHRASE 표현식 사용. 이미 Elastic Cloud Serverless에서 이용할 수 있으며, Elastic Stack 9.6에 도입됩니다.

• 구성 가능한 분석기. 표현식에 대한 MATCH 및 MATCH_PHRASE 사용 시 분석기 지원을 통해 쿼리 시점의 언어 분석기, 어간 추출, 동의어 기능을 가능하게 합니다.

• 매치 옵션. 런타임 매치를 위한 퍼지와 연산자 옵션이 있습니다.

• 벡터 검색. 행별 임베딩을 생성하고 런타임 dense_vector 표현식에 대해 k-최근접 이웃(kNN)을 실행하여 인덱싱되지 않은 데이터에도 의미 검색 기능을 제공합니다.

지금 표현식에 대한 ES|QL 풀텍스트 검색을 사용해 보세요

지금 바로 런타임 검색을 사용해 보세요. 현재 새로운 ES|QL 기능이 먼저 도입되는 Elastic Cloud Serverless에서 이용 가능하며, Elasticsearch 9.5에서 기술 미리보기로 출시됩니다. 검색 함수 참조부터 시작하고, 현재 한계에 대한 ES|QL 제한 사항 페이지를 확인하시기 바랍니다. 이번 버전은 기술 미리보기 버전이므로 여러분의 피드백을 기다리고 있습니다. 이전에 인덱싱되지 않은 내용을 검색하여 예상치 못한 결과가 나타난다면(긍정적이든 부정적이든) 언제든지 알려주시기 바랍니다.

1. _mapping API를 사용하여 필드 정보 검색하기

2. _search API를 사용하여 필드 값 표시

3. 하위 필드 표시

4. Synthetic _source

5. 런타임 필드

1. 맵핑 API를 사용하여 필드 정보 검색하기

_mapping API를 사용하면 인덱스 또는 여러 인덱스에 대한 매핑 정의를 검색할 수 있습니다. 여기에는 필드, 데이터 유형 및 기타 속성에 대한 정보가 포함됩니다. 특정 인덱스에 대한 매핑을 검색하려면 다음 요청을 사용하세요:

예를 들어 my_index 이라는 인덱스가 있는 경우 다음 요청으로 해당 인덱스의 매핑을 검색할 수 있습니다:

응답에는 필드 및 해당 속성에 대한 정보가 포함된 인덱스에 대한 매핑 정의가 포함됩니다.

특정 필드에 대한 매핑을 검색할 수도 있습니다. 매핑이 상당히 크고 특정 필드에만 집중하려는 경우 유용할 수 있습니다. 특정 필드의 매핑을 검색하려면 다음 요청을 사용하세요:

다음 요청에서와 같이 쉼표로 이름을 구분하여 여러 필드의 매핑을 검색할 수도 있습니다:

2. search API를 사용하여 필드 값 표시하기

Elasticsearch 인덱스의 필드 값을 표시하려면 _search API를 사용하면 됩니다. _search API는 반환되는 필드를 제어할 수 있는 다양한 방법을 제공하며, 두 가지 주요 방법은 다음과 같습니다:

1. _source: _source 필드에는 수집 파이프라인이나 전처리 단계에 의해 변경된 사항을 포함하여 색인된 그대로의 원본 JSON 문서 본문이 포함되어 있습니다. 소스 문서의 특정 필드를 표시하려면 아래에서 설명하는 대로 소스 필터링을 구현합니다.

2. fields: fields 매개변수를 사용하면 색인 매핑을 기반으로 검색을 수행할 때 문서에서 특정 필드를 검색할 수 있습니다. _source 과 달리 fields 은 _source 을 참조하지 않고 저장된 필드, 문서 값 또는 런타임 필드의 값을 반환할 수도 있지만 문서 값이나 저장된 설정이 없는 표준 필드의 경우 _source 으로 되돌아갑니다. 이는 아래에서 살펴보겠지만 성능 등 많은 이점을 가져올 수 있습니다.

소스필드 사용

기본적으로 _search API는 색인된 원본 JSON 문서가 포함된 _source 필드를 반환합니다. 특정 필드를 표시하려면 검색 요청의 _source 매개변수에 필터를 추가할 수 있으며, 이를 소스 필터링이라고 합니다.

다음은 my_index 인덱스에 있는 문서에 대한 title 및 author 필드 값을 반환하는 검색 요청의 예입니다:

이 예제에서 _source 매개변수는 반환할 필드를 지정합니다.

더 많은 제어가 필요한 경우 _source 객체의 includes 및 excludes 속성을 사용할 수 있습니다. 예를 들어 아래 쿼리는 최상위 수준 title 필드와 author 의 author.description 을 제외한 모든 하위 필드를 반환합니다.

이 예제에서는 author.* 패턴을 사용하여 author 객체의 모든 직접 하위 필드를 검색합니다. 그런 다음 author.description 을 명시적으로 제외하여 다른 작성자 필드만 반환되도록 합니다. 이 경우에도 여전히 소스 JSON을 로드하고 구문 분석해야 하므로 성능이 향상되지는 않지만 네트워크를 통해 전송되는 응답의 크기를 줄일 수 있다는 점에 유의하세요.

필드 매개변수 사용

fields 매개변수를 사용하여 검색 응답에 반환되는 필드를 필터링할 수 있습니다. _source 대신 fields 을 사용하면 다음과 같은 여러 가지 이점이 있습니다:

• 성능 개선: fields 은 전체 _source 을 로드할 필요 없이 저장된 필드 또는 문서 값에서 직접 값을 반환할 수 있으므로 응답 페이로드 크기가 더 작아집니다.

• 형식화된 출력: 표준 필드의 경우 fields 은 _source 으로 되돌아가 값을 가져올 수 있지만, 인덱스 매핑을 확인하여 형식이 지정된 날짜와 같은 출력의 형식을 적절히 지정하여 집계 및 정렬에 사용되는 것과 일관성을 유지합니다.

• 런타임 필드에 대한 액세스: fields 은 원본 _source 에 없는 런타임 필드를 반환할 수 있습니다.

• 더 많은 혜택은 여기에서 확인할 수 있습니다.

예를 들어 my_index 인덱스에서 title 및 author 필드만 반환하려면 다음 검색 요청을 사용할 수 있습니다:

위의 쿼리에서는 소스 문서를 반환하지 않도록 _source 필드를 false로 설정했습니다. 이렇게 하면 응답의 페이로드 크기를 크게 최소화할 수 있지만 title 및 author 필드가 keyword 필드 유형이고 기본적으로 doc_values 이 활성화되어 있기 때문에 작동한다는 점을 기억하세요. 필드에 doc_values 가 활성화되어 있지 않고 _source 가 false로 설정되어 있으면, Elasticsearch는 이를 검색할 방법이 없으며 응답에서 건너뛰게 됩니다.

fields 응답은 값이 하나만 있는 경우에도 항상 각 필드에 대한 값 배열을 반환한다는 점에 유의하세요. 이는 Elasticsearch에 전용 배열 유형이 없고 모든 필드에 여러 개의 값이 있을 수 있기 때문입니다. Elasticsearch의 배열에 대한 자세한 내용을 보려면 여기를 클릭하세요.

필드를 검색하는 다른 방법

_source 또는 fields 을 사용하여 필드를 검색하는 것이 권장되는 방법이지만, 특정 사용 사례에 따라 다음과 같은 다양한 방법을 사용할 수 있습니다:

문서 값 필드: _source docvalue_fields매개 변수를 사용하여 검색할 수 있습니다. 문서 값은 _source 과 동일한 필드 값을 저장하지만 정렬 및 집계에 최적화된 온디스크 데이터 구조로 저장합니다.

_source 에 저장된 값과는 별개이므로 전체 _source 를 로드하지 않고도 특정 필드를 요청할 수 있습니다. 이 기능은 대규모 문서를 쿼리하지만 문서 값을 지원하는 작은 필드 몇 개만 필요한 경우에 유용합니다. docvalue_fields 사용의 또 다른 사용 사례는 아래 예제에서 볼 수 있듯이 date 및 numeric 필드에 사용자 지정 서식을 사용하려는 경우입니다.

doc_values 을 활성화한 필드 또는 keyword, date, 숫자 유형 및 boolean 과 같이 기본적으로 활성화된 필드 유형에 대해서만 작동하며, text 또는 annotated_text 에는 작동하지 않습니다.

이 예에서는 docvalue_fields 매개변수를 사용하여 전체 _source 문서를 로드하지 않고 title, author, published 필드를 검색합니다:

이 쿼리가 실행되면 Elasticsearch는 각 문서에 대해 _source 을 참조하는 대신 온디스크 컬럼형 저장소에서 직접 값을 가져옵니다. published 필드는 쿼리에 제공된 format 매개변수 덕분에 기본 형식이 아닌 epoch_millis 형식으로 반환됩니다.

저장된 필드: 매핑에서 특정 필드를 저장된 것으로 명시적으로 표시한 경우 stored_fields 매개변수를 사용하여 해당 필드를 필터링할 수 있습니다. 특정 필드에 대해서만 가벼운 응답을 원하거나 나중에 검색할 수 있도록 의도적으로 저장한 필드에 대해 이 기능을 사용하면 유용합니다. _source 과 별도로 저장되므로 이 방법은 _source 을 로드할 필요가 없는 경우에도 유용합니다.

이 옵션은 기본적으로 꺼져 있으며 일반적으로 권장되지 않는다는 점에 유의하세요. 원본 소스 문서의 특정 하위 집합을 반환하려면 대신 소스 필터링을 사용하세요.

아래 예제 쿼리에서는 stored_fields 매개 변수를 사용하여 "store”: true" 인덱스 매핑 구성이 있는 summary 필드를 검색합니다.

이 쿼리가 실행되면 Elasticsearch는 이 필드가 ”store”: true 로 표시되어 있는지 확인하며, 이 필드를 찾지 못하면 필드를 완전히 건너뜁니다.

3. 하위 필드 표시

인덱스에 하위 필드가 포함된 경우 점 표기법을 사용하여 fields 매개변수에서 필드 경로를 지정할 수 있습니다. 하위 필드는 중첩된 필드 유형과 다르다는 점에 유의하세요. 예를 들어 address.city 이라는 이름의 하위 필드가 있는 경우 다음과 같이 검색 응답에 포함할 수 있습니다:

이 예제에서는 검색 응답에 title, author, address.city 필드의 값이 포함됩니다.

4. 합성 _소스

_source 사용 기능을 유지하면서 디스크 공간도 절약하려면 인덱스 매핑에 합성 _source 을 사용하는 옵션이 있습니다. 합성 _source 은 _source 이 비활성화되어 있는 경우에도 Elasticsearch가 저장된 필드 및 문서 값과 같은 기존 데이터로부터 _source 을 재구성할 수 있도록 하는 기능입니다. 이렇게 하면 재구성이 즉시 이루어지므로 쿼리 시 속도가 약간 느려지는 대신 저장 공간을 많이 절약할 수 있습니다. 인덱스 설정에서 아래 값을 사용하여 이 기능을 사용하도록 설정합니다:

_search API를 사용할 때 전체 문서 표시, 소스 필터링, _source 를 사용할 수 있을 것으로 기대하는 Kibana와 같은 다른 기능 및 도구와의 호환성, 전체 _source 문서를 저장할 필요가 없는 것 등이 합성 _source 사용의 몇 가지 이점입니다.

5. 런타임 필드

런타임 필드를 사용하면 쿼리 시 또는 런타임 블록 아래의 인덱스 매핑에서 스크립트 필드를 정의할 수 있습니다. 이러한 필드는 색인화되지 않으므로 런타임 필드를 추가해도 색인 크기가 증가하지는 않지만 _source 에 표시되지 않습니다. 매핑에 정의된 런타임 필드는 영구적이며 모든 쿼리에서 사용할 수 있는 반면, 쿼리 시점에 정의된 런타임 필드는 임시적이며 해당 검색 요청에서만 사용할 수 있습니다.

런타임 필드 사용의 주요 이점은 이미 수집한 후 문서에 필드를 추가할 수 있어 매핑 결정을 간소화할 수 있다는 점입니다. 런타임 필드는 문자열 서식 지정이나 점수 계산과 같이 원본 문서에는 없지만 스크립트를 사용하여 생성된 값으로 문서를 보강하는 데도 유용합니다.

또한 런타임 필드는 결과 집합의 모든 문서에 대해 스크립트를 실행해야 하므로 성능이 저하될 수 있다는 점도 유의할 필요가 있습니다. 런타임 필드를 검색하려면 _search API에서 fields 매개 변수를 사용할 수도 있습니다.

결론

Elasticsearch 인덱스의 필드를 표시하는 방법은 인덱스 매핑 또는 _source 을 사용하여 단순히 값을 검색하는 것부터 fields, docvalue_fields 또는 제어 및 효율성을 높이기 위한 런타임 필드를 사용하는 고급 방법까지 다양합니다. 검색 환경을 최적화하려면 다양한 방법 간의 장단점을 이해하는 것이 중요합니다. 페이로드를 최적화하든, 문서를 보강하든, 저장 공간을 절약하기 위해 합성 _source 을 사용하든, Elasticsearch는 필요한 데이터를 필요한 방식으로 찾을 수 있는 여러 가지 도구와 기능을 제공합니다. 이러한 기법은 데이터 구조를 이해하고, 특정 필드를 식별하고, 문제를 해결하는 데 도움이 될 수 있습니다.

이 문서에서는 이러한 필드 유형, 각 필드 유형이 언제 사용되는지, 색인 및 쿼리 중 임베딩 생성 및 사용 전략과 어떻게 연관되는지에 대해 설명합니다.

고밀도 벡터 유형

Elasticsearch의 dense_vector 필드 유형은 거의 모든 차원이 관련된 텍스트, 이미지, 오디오와 같은 데이터의 숫자 표현인 고밀도 벡터를 저장하는 데 사용됩니다. 이러한 벡터는 OpenAI, Cohere 또는 Hugging Face와 같은 플랫폼에서 제공하는 임베딩 모델을 사용하여 생성되며, 다른 문서와 정확한 용어를 공유하지 않더라도 데이터의 전체적인 의미적 의미를 포착하도록 설계되었습니다.

Elasticsearch에서 고밀도 벡터는 사용되는 모델에 따라 최대 4096개의 차원을 가질 수 있습니다. 예를 들어, 모든 MiniLM-L6-v2 모델은 384차원의 벡터를 생성하는 반면, OpenAI의 텍스트 임베딩-ada-002는 1536차원의 벡터를 생성합니다.

dense_vector 필드는 사전 생성된 벡터를 사용하거나 사용자 정의 유사성 함수를 적용하거나 외부 모델과 통합하는 등 보다 강력한 제어가 필요한 경우 이러한 종류의 임베딩을 저장하는 기본 유형으로 일반적으로 채택됩니다.

dense_vector 유형은 언제, 왜 사용하나요?

고밀도 벡터는 문장, 단락 또는 전체 문서 간의 의미적 유사성을 포착하는 데 탁월합니다. 같은 용어가 아니더라도 텍스트의 전체적인 의미를 비교하는 것이 목표일 때 매우 효과적입니다.

고밀도 벡터 필드는 OpenAI, Cohere 또는 Hugging Face와 같은 플랫폼에서 제공하는 모델을 사용하는 외부 임베딩 생성 파이프라인이 이미 있고 이러한 벡터를 수동으로만 저장하고 쿼리하려는 경우에 이상적입니다. 이 유형의 필드는 임베딩 모델과의 호환성이 높고 생성 및 쿼리에서 완전한 유연성을 제공하므로 검색 중에 벡터를 생성, 색인 및 사용하는 방법을 제어할 수 있습니다.

또한 순위 로직을 조정해야 하는 경우를 위해 k-NN 또는 script_score와 같은 쿼리를 사용하여 다양한 형태의 시맨틱 검색을 지원합니다. 이러한 가능성으로 인해 고밀도 벡터는 검색 증강 세대(RAG), 추천 시스템, 유사도에 기반한 개인화된 검색과 같은 애플리케이션에 이상적입니다.

마지막으로 이 필드에서는 cosineSimilarity, dotProduct 또는 l2norm 와 같은 기능을 사용하여 관련성 로직을 사용자 지정하여 사용 사례의 필요에 따라 순위를 조정할 수 있습니다.

고밀도 벡터는 위에서 언급한 고급 사용 사례와 같은 유연성, 사용자 지정 및 호환성이 필요한 사용자에게 여전히 최고의 옵션입니다.

고밀도 벡터 유형에 쿼리를 사용하는 방법은 무엇인가요?

dense_vector 로 정의된 필드에 대한 검색은 K-최근 이웃 쿼리를 사용합니다. 이 쿼리는 밀도 벡터가 쿼리 벡터에 가장 가까운 문서를 찾는 작업을 담당합니다. 다음은 고밀도 벡터 필드에 k-NN 쿼리를 적용하는 방법의 예시입니다:

k-NN 쿼리 외에도 문서 점수를 사용자 정의할 필요가 있는 경우, 스크립트_스코어 쿼리를 사용하여 코사인 유사도, dotProduct 또는 l2norm과 같은 벡터 비교 함수와 결합하여 보다 제어된 방식으로 관련성을 계산할 수도 있습니다. 예시를 참조하세요:

더 자세히 알아보고 싶으시다면 Elasticsearch에서 벡터 검색을 설정하는 방법문서를 살펴보는 것을 추천합니다.

희소 벡터 유형

sparse_vector 필드 유형은 대부분의 값이 0이고 일부 용어에만 가중치가 있는 숫자 표현인 스파스 벡터를 저장하는 데 사용됩니다. 이 유형의 벡터는 SPLADE 또는 ELSER(Elastic Learned Sparse EncodeR)와 같은 용어 기반 모델에서 흔히 볼 수 있습니다.

희소 벡터 유형을 언제, 왜 사용해야 하나요?

스파스 벡터는 의미론적 지능을 유지하면서 어휘를 보다 정밀하게 검색해야 할 때 이상적입니다. 토큰/값 쌍으로 텍스트를 표시하고 관련 가중치가 있는 가장 관련성이 높은 용어만 강조 표시하여 명확성, 제어 및 효율성을 제공합니다.

이 유형의 필드는 텍스트에서 상대적 중요도에 따라 각 토큰에 다른 가중치를 할당하는 ELSER 또는 SPLADE 모델과 같이 용어를 기반으로 벡터를 생성할 때 특히 유용합니다.

쿼리에서 특정 단어의 영향력을 제어하려는 경우 희소 벡터 유형을 사용하면 용어의 가중치를 수동으로 조정하여 결과의 순위를 최적화할 수 있습니다.

주요 이점으로는 문서가 관련성이 있는 것으로 간주된 이유를 명확하게 이해할 수 있으므로 검색의 투명성과 모든 차원을 저장하는 고밀도 벡터와 달리 0이 아닌 값을 가진 토큰만 저장되므로 저장 효율성이 높다는 점이 있습니다.

또한, 스파스 벡터는 하이브리드 검색 전략에서 이상적인 보완재이며, 밀도 벡터와 결합하여 어휘 정확도와 의미 이해를 결합할 수도 있습니다.

희소 벡터 유형에 쿼리를 사용하는 방법은 무엇인가요?

sparse_vector 쿼리를 사용하면 토큰/값 형식의 쿼리 벡터를 기반으로 문서를 검색할 수 있습니다. 아래 쿼리 예시를 참조하세요:

학습된 모델을 사용하려는 경우 쿼리 텍스트를 스파스 벡터로 자동 변환하는 추론 엔드포인트를 사용할 수 있습니다:

이 주제를 더 자세히 알아보려면 학습된 ML 모델을 사용한 희소 벡터 임베딩 이해를 읽어보시기 바랍니다.

시맨틱 텍스트 유형

semantic_text 필드 유형은 Elasticsearch에서 시맨틱 검색을 사용하는 가장 간단하고 직관적인 방법입니다. 추론 엔드포인트를 통해 인덱싱 및 쿼리 시점에 임베딩 생성을 자동으로 처리합니다. 즉, 벡터를 수동으로 생성하거나 저장하는 것에 대해 걱정할 필요가 없습니다.

시맨틱 텍스트는 언제, 왜 사용해야 하나요?

semantic_text 필드는 벡터를 수동으로 처리할 필요 없이 최소한의 기술적 노력으로 시작하고 싶은 분들에게 이상적입니다. 이 필드에서는 임베딩 생성 및 벡터 검색 매핑과 같은 단계를 자동화하여 더 빠르고 편리하게 설정할 수 있습니다.

매핑, 임베딩 생성 및 수집 파이프라인을 수동으로 구성해야 하는 복잡성을 제거하므로 단순성과 추상화를 중시하는 경우 사용을 고려해야 합니다.semantic_text 추론 모델을 선택하기만 하면 나머지는 Elasticsearch가 알아서 처리합니다.

주요 장점으로는 인덱싱과 쿼리 중에 수행되는 자동 임베딩 생성과 선택한 추론 모델을 지원하도록 사전 구성되어 바로 사용할 수 있는 매핑이 있습니다.

또한 이 필드에서는 긴 텍스트의 자동 분할(텍스트 청킹)을 기본적으로 지원하여 큰 텍스트를 각각 임베딩된 작은 구절로 나눌 수 있으므로 검색 정확도가 향상됩니다. 이는 특히 시맨틱 검색의 기본 엔지니어링을 다루지 않고도 빠르게 가치를 제공하고자 하는 팀의 생산성을 크게 향상시킵니다.

하지만 semantic_text 은 속도와 간편함을 제공하지만 이 접근 방식에는 몇 가지 한계가 있습니다. 시장 표준 모델을 사용할 수 있으며, Elasticsearch에서 추론 엔드포인트로 사용할 수 있는 한 사용할 수 있습니다. 그러나 dense_vector 필드에서 가능한 것처럼 외부에서 생성된 임베딩은 지원하지 않습니다.

벡터 생성 방식을 더 잘 제어하고 싶거나, 자체 임베딩을 사용하거나, 고급 전략을 위해 여러 필드를 결합해야 하는 경우 dense_vector 및 sparse_vector 필드는 보다 맞춤화된 또는 도메인별 시나리오에 필요한 유연성을 제공합니다.

시맨틱 텍스트 유형에 쿼리를 사용하는 방법

semantic_text 이전에는 임베딩 유형(밀도형 또는 희소형)에 따라 다른 쿼리를 사용해야 했습니다. 희소 필드에는 sparse_vector 쿼리가 사용되었고, dense_vector 필드에는 KNN 쿼리가 필요했습니다.

시맨틱 텍스트 유형에서는 쿼리 벡터를 자동으로 생성하고 색인된 문서의 임베딩과 비교하는 시맨틱 쿼리를 사용하여 검색을 수행합니다. semantic_text 유형을 사용하면 쿼리를 포함할 추론 엔드포인트를 정의할 수 있지만, 아무것도 지정하지 않으면 인덱싱 중에 사용된 것과 동일한 엔드포인트가 쿼리에 적용됩니다.

자세한 내용은 Elasticsearch의 새로운 semantic_text 매핑 문서를 읽어보시기 바랍니다: 시맨틱 검색 간소화.

결론

Elasticsearch에서 임베딩을 매핑하는 방법을 선택할 때는 벡터를 생성하는 방법과 벡터에 대해 필요한 제어 수준을 이해하는 것이 중요합니다. 시맨틱 텍스트 필드를 사용하면 자동 및 확장 가능한 시맨틱 검색이 가능하므로 많은 초기 사용 사례에 이상적입니다. 더 많은 제어, 미세 조정된 성능 또는 사용자 지정 모델과의 통합이 필요한 경우 고밀도 벡터 및 희소 벡터 필드는 필요한 유연성을 제공합니다.

이상적인 필드 유형은 사용 사례, 사용 가능한 인프라, 머신 러닝 스택의 성숙도에 따라 달라집니다. 가장 중요한 것은 Elastic이 현대적이고 적응력이 뛰어난 검색 시스템을 구축할 수 있는 도구를 제공한다는 점입니다.

참고 자료

• 시맨틱 텍스트 필드 유형

• 희소 벡터 필드 유형

• 고밀도 벡터 필드 유형

• 시맨틱 쿼리

• 희소 벡터 쿼리

• kNN 검색

• Elasticsearch의 새로운 의미론적 텍스트 매핑: 시맨틱 검색 간소화

• 학습된 ML 모델을 사용한 스파스 벡터 임베딩 이해하기