Azure AI Search에서 인덱스 검색

Azure AI Search 에서 검색 인덱 스는 검색 엔진에서 인덱싱, 전체 텍스트 검색, 벡터 검색, 하이브리드 검색 및 필터링된 쿼리에 사용할 수 있는 검색 가능한 콘텐츠입니다. 인덱스는 스키마에 의해 정의되고 검색 서비스에 저장되며, 데이터 가져오기는 두 번째 단계로 수행됩니다. 이 콘텐츠는 기본 데이터 저장소를 제외하고 검색 서비스 내에 존재하며, 최신 검색 애플리케이션에서 예상되는 응답 시간(밀리초)에 필요합니다. 인덱서 기반 인덱싱 시나리오를 제외하고 검색 서비스는 원본 데이터에 연결하거나 쿼리하지 않습니다.

검색 인덱스 만들기 및 관리하려는 경우 이 문서에서는 다음 사항을 이해하는 데 도움이 됩니다.

  • 콘텐츠(문서 및 스키마)
  • 물리적 데이터 구조
  • 기본 작업

바로 실습을 원하나요? 대신 검색 인덱스 만들기를 참조하세요.

검색 인덱스의 스키마

Azure AI Search에서 인덱스에는 검색 문서가 포함됩니다. 개념적으로 문서는 인덱스의 검색 가능한 데이터의 단일 단위입니다. 예를 들어, 소매점에는 각 제품에 대한 문서가 있고, 뉴스 조직에는 각 아티클에 대한 문서가 있으며, 여행 사이트에는 각 호텔 및 대상에 대한 문서가 있을 수 있습니다. 검색 인덱스는 테이블과 동일하며 문서는 테이블거의 동일합니다.

문서의 구조는 다음 예제와 같이 인덱스 스키마에 의해 결정됩니다. "fields" 컬렉션은 일반적으로 인덱스의 가장 큰 부분으로, 각 필드의 이름을 지정하고, 데이터 형식할당하고, 사용 방법을 결정하는 허용 가능한 동작으로 특성이 지정됩니다.

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

다른 요소는 간결하게 축소되지만 다음 링크는 세부 정보를 제공합니다.

  • 제안기는 자동 완성과 같은 미리 입력 쿼리를 지원합니다.
  • scoringProfiles 는 관련성 튜닝에 사용됩니다.
  • 분석기는 분석기 에서 지원하는 언어 규칙 또는 기타 특성에 따라 문자열을 토큰으로 처리하는 데 사용됩니다.
  • corsOptions 또는 CORS(원본 간 원격 스크립팅)는 서로 다른 do기본 요청을 발급하는 앱에 사용됩니다.
  • encryptionKey 는 인덱스의 중요한 콘텐츠에 대한 이중 암호화를 구성합니다.
  • 의미 체계 는 전체 텍스트 및 하이브리드 검색에서 의미 체계 재전송을 구성합니다.
  • vectorSearch 는 벡터 필드 및 쿼리를 구성합니다.

필드 정의

검색 문서는 인덱스 만들기 요청의 본문에 있는 "fields" 컬렉션에 의해 정의됩니다. 문서 식별(키), 검색 가능한 텍스트 저장, 필터, 패싯 및 정렬을 지원하기 위한 필드가 필요합니다. 사용자가 전혀 볼 수 없는 데이터에 대한 필드가 필요할 수도 있습니다. 예를 들어 점수 매기기 프로필에서 검색 점수를 높이기 위해 사용할 수 있는 수익 마진 또는 마케팅 프로모션에 대한 필드를 원할 수 있습니다.

들어오는 데이터가 본질적으로 계층적이면 인덱스 내에서 중첩된 구조에 사용되는 복합 형식으로 나타낼 수 있습니다. 기본 제공 샘플 데이터 집합인 Hotels는 각 호텔과 일대일 관계가 있는 주소(여러 하위 필드 포함)와 여러 객실이 각 호텔과 연결된 룸 복합 컬렉션을 사용하는 복잡한 형식을 보여 줍니다.

필드 특성

필드 특성은 필드가 전체 텍스트 검색, 패싯 탐색, 정렬 작업 등에 사용되는지 여부와 같이 필드가 사용되는 방식을 결정합니다.

문자열 필드는 종종 "검색 가능" 및 "검색 가능"으로 표시됩니다. 검색 결과의 범위를 좁히는 데 사용되는 필드에는 "sortable", "filterable" 및 "facetable"이 포함됩니다.

attribute 설명
"검색 가능" 전체 텍스트 또는 벡터 검색 가능 텍스트 필드는 인덱싱 중에 단어 분리와 같은 어휘 분석의 대상이 됩니다. 검색 가능한 필드를 "sunny day"와 같은 값으로 설정하면 내부적으로 개별 토큰 "sunny" 및 "day"로 분할됩니다. 자세한 내용은 전체 텍스트 검색 작동 방식을 참조하세요.
"필터링 가능" $filter 쿼리에서 참조됩니다. 필터링 가능한 형식 Edm.String 필드이거나 Collection(Edm.String) 단어 분리를 거치지 않으므로 비교는 정확한 일치에만 해당합니다. 예를 들어 이러한 필드 f를 "맑은 날" $filter=f eq 'sunny' 로 설정하면 일치하는 항목을 찾지 못하지만 $filter=f eq 'sunny day'
“정렬 가능” 기본적으로 시스템은 점수에 따라 결과를 정렬하지만 문서에 있는 필드를 기반으로 정렬하도록 구성할 수 있습니다. 형식 Collection(Edm.String) 의 필드는 "정렬 가능"할 수 없습니다.
"패싯 가능" 일반적으로 범주별 적중 횟수를 포함하는 검색 결과 프레젠테이션에 사용됩니다(예: 특정 도시의 호텔). 이 옵션은 형식 Edm.GeographyPoint필드와 함께 사용할 수 없습니다. 필터링 가능, "정렬 가능" 또는 "패싯 가능" 형식 Edm.String 의 필드는 길이가 최대 32킬로바이트일 수 있습니다. 자세한 내용은 인덱스 만들기(REST API)를 참조하세요.
“키” 인덱스 내의 문서에 대한 고유 식별자입니다. 정확히 하나의 필드를 키 필드로 선택해야 하며 형식 Edm.String이어야 합니다.
"검색 가능" 검색 결과에서 필드를 반환할 수 있는지 여부를 결정합니다. 이 기능은 필드(예: 이익률)를 필터, 정렬 또는 채점 메커니즘으로 사용하지만 최종 사용자에게 필드를 표시하지 않으려는 경우에 유용합니다. 이 특성은 필드의 특성 key 이어야 true 합니다.

언제든지 새 필드를 추가할 수 있지만 기존 필드 정의는 인덱스의 수명 동안 잠깁니다. 이러한 이유로 개발자는 일반적으로 포털을 사용하여 간단한 인덱스를 만들거나, 아이디어를 테스트하거나, 포털 페이지를 사용하여 설정을 조회합니다. 인덱스 디자인을 자주 반복하면 인덱스가 쉽게 다시 작성되도록 코드 기반 접근 방식을 따르는 것이 더 효율적입니다.

참고 항목

인덱스를 빌드하는 데 사용하는 API에는 다양한 기본 동작이 있습니다. REST API경우 대부분의 특성은 기본적으로 사용하도록 설정되며(예: 문자열 필드에 대해 "검색 가능" 및 "검색 가능"은 true임) 특성을 해제하려는 경우에만 설정해야 하는 경우가 많습니다. .NET SDK의 경우 반대의 경우도 마찬가지입니다. 명시적으로 설정하지 않은 속성에서 기본값은 특별히 사용하도록 설정하지 않는 한 해당 검색 동작을 사용하지 않도록 설정하는 것입니다.

실제 구조 및 크기

Azure AI Search에서 인덱스의 물리적 구조는 주로 내부 구현입니다. 해당 스키마에 액세스하고, 콘텐츠를 쿼리하고, 크기를 모니터링하고, 용량을 관리할 수 있지만 클러스터 자체(인덱스, 분할된 데이터베이스 및 기타 파일 및 폴더)는 Microsoft에서 내부적으로 관리합니다.

Azure Portal의 인덱스 탭에서 또는 검색 서비스에 대해 GET INDEX 요청을 실행하여 인덱스 크기를 모니터링할 수 있습니다. 서비스 통계 요청을 발급하고 스토리지 크기 값을 확인할 수도 있습니다.

인덱스의 크기는 다음에 의해 결정됩니다.

  • 문서의 수량 및 구성
  • 개별 필드의 특성
  • 인덱스 구성(구체적으로 제안기 포함 여부)

문서 컴퍼지션 및 수량은 가져오도록 선택한 항목에 따라 결정됩니다. 검색 인덱스에는 검색 가능한 콘텐츠만 포함되어야 합니다. 원본 데이터에 이진 필드가 포함된 경우 AI 보강을 사용하여 콘텐츠를 해독하고 분석하여 텍스트 검색 가능한 정보를 만들지 않는 한 해당 필드를 생략합니다.

필드 특성은 동작을 결정합니다. 이러한 동작을 지원하기 위해 인덱싱 프로세스는 필요한 데이터 구조를 만듭니다. 예를 들어 형식 Edm.String필드의 경우 "searchable"은 토큰화된 용어에 대해 반전된 인덱스를 검색하는 전체 텍스트 검색을 호출합니다. 반대로 "필터 가능" 또는 "정렬 가능" 특성은 수정되지 않은 문자열에 대한 반복을 지원합니다. 다음 섹션의 예는 선택한 특성에 따라 인덱스 크기의 변화를 보여 줍니다.

제안기는 자동 완성 쿼리를 지원하는 구문입니다. 따라서 제안기를 포함할 때 인덱싱 프로세스는 축자 일치에 필요한 데이터 구조를 만듭니다. 제안기는 필드 수준에서 구현되므로 자동 완성에 적합한 필드만 선택합니다.

특성 및 제안기의 스토리지 영향을 보여 주는 예

다음 스크린샷은 다양한 특성 조합으로 인한 인덱스 스토리지 패턴을 보여 줍니다. 이 인덱스는 부동산 샘플 인덱스를 기반으로 하며 데이터 가져오기 마법사와 기본 제공된 샘플 데이터를 사용하여 쉽게 만들 수 있습니다. 인덱스 스키마는 표시되지 않지만 인덱스 이름을 기반으로 특성을 유추할 수 있습니다. 예를 들어 realestate-searchable 인덱스는 "searchable" 특성을 선택했고 그 외에는 아무것도 선택하지 않으며, realestate-retrievable 인덱스는 "검색 가능한" 특성이 선택되어 있으며 그 외에는 아무것도 선택되지 않습니다.

Index size based on attribute selection

이러한 인덱스 변형은 다소 인위적이지만 특성이 스토리지에 미치는 영향을 광범위하게 비교하기 위해 참조할 수 있습니다.

  • "검색 가능"은 인덱스 크기에 영향을 주지 않습니다.
  • "filterable", "sortable", "facetable"은 더 많은 스토리지를 사용합니다.
  • 제안기는 인덱스 크기를 늘릴 가능성이 크지만 스크린샷이 나타내는 만큼은 아닙니다(제안기를 인식할 수 있는 모든 필드가 선택되었으며 이는 대부분의 인덱스에서 가능한 시나리오가 아닙니다).

또한 이전 표에 반영되지 않은 것은 분석기의 효과입니다. edgeNgram tokenizer를 사용하여 축자 시퀀스()a, ab, abc, abcd를 저장하는 경우 인덱스는 표준 분석기를 사용하는 경우보다 큽니다.

기본 작업 및 상호 작용

인덱스가 무엇인지 더 잘 이해했으므로 이 섹션에서는 단일 인덱스에 대한 연결 및 보안을 포함하여 인덱스 런타임 작업을 소개합니다.

참고 항목

인덱스를 관리할 때 인덱스를 이동하거나 복사하기 위한 포털 또는 API 지원이 없다는 점에 유의합니다. 대신 고객은 일반적으로 애플리케이션 배포 솔루션을 다른 검색 서비스(동일한 인덱스 이름을 사용하는 경우)에 지정하거나 이름을 수정하여 현재 검색 서비스에 복사본을 만든 다음 빌드합니다.

인덱스 격리

Azure AI Search에서는 한 번에 하나의 인덱스로 작업하며 모든 인덱스 관련 작업은 단일 인덱스를 대상으로 합니다. 인덱싱 또는 쿼리에 대한 관련 인덱스 또는 독립 인덱스의 조인에 대한 개념은 없습니다.

지속적으로 사용 가능

첫 번째 문서가 인덱싱되는 즉시 쿼리에 인덱스를 사용할 수 있지만 모든 문서가 인덱싱될 때까지는 완전히 작동하지 않습니다. 내부적으로 검색 인덱스는 파티션 간에 분산되고 복제본(replica) 실행됩니다. 물리적 인덱스는 내부적으로 관리됩니다. 논리 인덱스는 사용자가 관리합니다.

인덱스는 계속 사용할 수 있으며 일시 중지하거나 오프라인으로 전환할 수 없습니다. 지속적인 작업을 위해 설계되었기 때문에 콘텐츠에 대한 모든 업데이트 또는 인덱스 자체에 대한 추가가 실시간으로 발생합니다. 결과적으로 요청이 문서 업데이트와 일치하는 경우 쿼리가 일시적으로 불완전한 결과를 반환할 수 있습니다.

문서 작업(새로 고침 또는 삭제)과 현재 인덱스의 기존 구조 및 무결성에 영향을 주지 않는 수정(예: 새 필드 추가)에 대한 쿼리 연속성이 존재합니다. 구조적 업데이트(기존 필드 변경)가 필요한 경우 일반적으로 개발 환경에서 드롭 앤 다시 빌드 워크플로를 사용하거나 프로덕션 서비스에서 인덱스의 새 버전을 만들어 관리합니다.

인덱스 다시 빌드를 방지하기 위해 작은 변경을 수행하는 일부 고객은 이전 버전과 함께 공존하는 새 필드를 만들어 필드의 "버전을 지정"하도록 선택합니다. 시간이 지남에 따라 특히 복제 비용이 많이 드는 프로덕션 인덱스에서 사용되지 않는 필드 또는 사용되지 않는 사용자 지정 분석기 정의의 형태로 분리된 콘텐츠가 생성됩니다. 인덱스 수명 주기 관리의 일부로 계획된 인덱스 업데이트에서 이러한 문제를 해결할 수 있습니다.

엔드포인트 연결 및 보안

모든 인덱싱 및 쿼리 요청은 인덱스를 대상으로 합니다. 엔드포인트는 일반적으로 다음 중 하나입니다.

엔드포인트 연결 및 액세스 제어
<your-service>.search.windows.net/indexes 인덱스 컬렉션을 대상으로 합니다. 인덱스를 만들기, 나열 또는 삭제할 때 사용됩니다. 이러한 작업에는 관리자 권한이 필요하며 관리자 API 키 또는 검색 기여자 역할을 통해 사용할 수 있습니다.
<your-service>.search.windows.net/indexes/<your-index>/docs 단일 인덱스의 문서 컬렉션을 대상으로 합니다. 인덱스 또는 데이터 새로 고침을 쿼리할 때 사용됩니다. 쿼리의 경우 읽기 권한이면 충분하며 쿼리 API 키 또는 데이터 읽기 권한자 역할을 통해 사용할 수 있습니다. 데이터 새로 고침을 위해서는 관리자 권한이 필요합니다.
  1. Azure Portal부터 시작합니다. Azure 구독자 또는 검색 서비스를 만든 사용자는 Azure Portal에서 검색 서비스를 관리할 수 있습니다. Azure 구독에는 서비스를 만들거나 삭제할 수 있는 기여자 이상의 권한이 필요합니다. 이 권한 수준은 Azure Portal에서 검색 서비스를 완전히 관리하기에 충분합니다.

  2. 프로그래밍 방식으로 액세스하기 위해 다른 클라이언트를 사용해 보세요. 첫 번째 단계에 대한 빠른 시작을 권장합니다.

다음 단계

Azure AI Search에 대한 거의 모든 샘플 또는 연습을 사용하여 인덱스 만들기 실습 환경을 얻을 수 있습니다. 우선 목차에서 빠른 시작을 선택할 수 있습니다.

하지만 데이터로 인덱스 로드를 위한 방법론에도 익숙해지려고 합니다. 인덱스 정의 및 데이터 가져오기 전략은 함께 정의됩니다. 다음 문서에서는 인덱스 만들기 및 로드에 대한 자세한 정보를 제공합니다.