Azure AI 검색에서 인덱스 만들기

이 문서에서는 검색 인덱스에 대한 스키마를 정의하고 이를 검색 서비스에 푸시하는 단계를 알아봅니다. 인덱스를 만들면 검색 서비스에 물리적 데이터 구조가 설정됩니다. 인덱스가 존재하면 별도의 작업으로 인덱스를 로드합니다.

필수 조건

• 키 기반 인증을 위해 Search Service 기여자 또는 관리 API 키로 권한을 작성합니다.

• 인덱싱하려는 데이터 이해. 검색 인덱스는 검색 가능하게 만들려는 외부 콘텐츠를 기반으로 합니다. 검색 가능한 콘텐츠는 인덱스의 필드로 저장됩니다. Azure AI Search에서 검색 가능하고, 검색 가능하고, 필터링 가능하고, 패싯 가능하고, 정렬 가능한 원본 필드를 명확하게 파악해야 합니다. 지침은 스키마 검사 목록을 참조하세요.

• 또한 인덱스에서 문서 키(또는 ID)로 사용할 수 있는 원본 데이터의 고유 필드도 있어야 합니다.

• 안정적인 인덱스 위치. 기본적으로 기존 인덱스를 다른 검색 서비스로 이동할 수 없습니다. 애플리케이션 요구 사항을 다시 검토하고 기존 검색 서비스(용량 및 지역)가 요구 사항에 충분한지 확인합니다. Azure AI 서비스 또는 Azure OpenAI 에 대한 종속성을 사용하는 경우 필요한 모든 리소스를 제공하는 지역을 선택합니다.

• 마지막으로, 모든 서비스 계층에는 만들 수 있는 개체 수에 대한 인덱스 한도가 있습니다. 예를 들어 무료 계층을 실험하는 경우 지정된 시간에 인덱스 3개만 있을 수 있습니다. 인덱스 자체에는 벡터 제한과 단순 필드 수와 복잡한 필드 수에 대한 인덱스 제한이 있습니다.

문서 키

검색 인덱스 만들기에는 두 가지 요구 사항이 있습니다. 인덱스는 검색 서비스에 고유한 이름이 있어야 하며 문서 키가 있어야 합니다. 필드의 부울 key 특성을 true로 설정하여 문서 키를 제공하는 필드를 나타낼 수 있습니다.

문서 키는 검색 문서의 고유 식별자이고, 검색 문서는 무언가를 완벽하게 설명하는 필드 컬렉션입니다. 예를 들어, 영화 데이터 세트의 인덱스를 생성하는 경우 검색 문서에는 단일 영화의 제목, 장르 및 기간이 포함됩니다. 동영상 이름은 이 데이터 세트에서 고유하므로 영화 이름을 문서 키로 사용할 수 있습니다.

Azure AI Search에서 문서 키는 문자열이며 인덱싱할 콘텐츠를 제공하는 데이터 원본의 고유 값에서 시작되어야 합니다. 일반적으로 검색 서비스는 키 값을 생성하지 않지만 일부 시나리오(예: Azure 테이블 인덱서)에서는 기존 값을 합성하여 인덱싱되는 문서에 대한 고유 키를 만듭니다. 또 다른 시나리오는 청크 또는 분할된 데이터에 대한 일대다 인덱싱이며, 이 경우 각 청크에 대해 문서 키가 생성됩니다.

신규 및 업데이트된 콘텐츠를 인덱싱하는 증분 인덱싱 중에는 새 키가 있는 들어오는 문서가 추가되지만 기존 키가 있는 들어오는 문서는 인덱스 필드가 null인지 또는 채워져 있는지 여부에 따라 병합되거나 덮어쓰기됩니다.

문서 키에 대한 중요한 사항은 다음과 같습니다.

• 키 필드의 최대 값 길이는 1,024자입니다.
• 각 인덱스의 최상위 필드 하나만 키 필드로 선택해야 하며 형식 Edm.String이어야 합니다.
• 특성의 key 기본값은 단순 필드에는 false이고 복합 필드에는 null입니다.

키 필드를 사용하여 문서를 직접 조회하고 특정 문서를 업데이트하거나 삭제할 수 있습니다. 키 필드의 값은 문서를 조회하거나 인덱싱할 때 대/소문자를 구분하는 방식으로 처리됩니다. 자세한 내용은 GET 문서(REST) 및 인덱스 문서(REST)를 참조하세요.

스키마 검사 목록

이 검사 목록을 사용하여 검색 인덱스의 디자인 결정에 도움을 받으세요.

1. 인덱스 및 필드 이름이 명명 규칙을 준수하도록 명명 규칙을 검토합니다.

2. 지원되는 데이터 형식을 검토합니다. 데이터 형식은 필드 사용 방식에 영향을 줍니다. 예를 들어 숫자 콘텐츠는 필터링할 수 있지만 전체 텍스트를 검색할 수는 없습니다. 가장 일반적인 데이터 형식은 전체 텍스트 검색 엔진을 사용하여 토큰화되고 쿼리되는 검색 가능한 텍스트에 대한 Edm.String입니다. 벡터 필드의 가장 일반적인 데이터 형식은 Edm.Single이지만 다른 형식도 사용할 수 있습니다.

3. 문서 키를 식별합니다. 문서 키는 인덱스 요구 사항입니다. 고유한 값을 포함하는 원본 데이터 필드에서 채워진 단일 문자열 필드입니다. 예를 들어 Blob Storage에서 인덱싱하는 경우 메타데이터 스토리지 경로가 컨테이너의 각 Blob을 고유하게 식별하기 때문에 문서 키로 사용되는 경우가 많습니다.

4. 인덱스에서 검색 가능한 콘텐츠를 제공하는 데이터 원본의 필드를 식별합니다.

   검색 가능한 벡터가 아닌 콘텐츠에는 전체 텍스트 검색 엔진을 사용하여 쿼리되는 짧거나 긴 문자열이 포함됩니다. 콘텐츠가 자세한 정보(작은 구 또는 더 큰 청크)인 경우 다양한 분석기로 실험하여 텍스트 토큰화 방법을 확인합니다.

   검색 가능한 벡터 콘텐츠는 수학적 표현으로 존재하는 이미지나 텍스트(모든 언어)일 수 있습니다. 좁은 데이터 형식이나 벡터 압축을 사용하여 벡터 필드를 더 작게 만들 수 있습니다.

   필드(예: retrievable 또는 filterable)에 설정된 특성은 검색 동작과 검색 서비스에서 인덱스의 실제 표현을 모두 결정합니다. 필드를 특성화해야 하는 방법을 결정하는 것은 많은 개발자에게 반복적인 프로세스입니다. 반복 속도를 높이려면 쉽게 삭제하고 다시 빌드할 수 있도록 샘플 데이터로 시작합니다.

5. 필터로 사용할 수 있는 원본 필드를 식별합니다. 숫자 콘텐츠와 짧은 텍스트 필드, 특히 반복 값이 있는 필드가 좋은 옵션입니다. 필터로 작업할 때는 다음을 기억하세요.

   • 필터는 벡터 및 비벡터 쿼리에서 사용할 수 있지만 필터 자체는 인덱스의 사람이 읽을 수 있는(비벡터) 필드에 적용됩니다.

   • 필터링 가능한 필드는 패싯 탐색에 선택적으로 사용할 수 있습니다.

   • 필터링 가능한 필드는 임의의 순서로 반환되며 관련성 점수 매기기를 거치지 않으므로 정렬 가능하도록 만드는 것이 좋습니다.

6. 벡터 필드의 경우 벡터 검색 구성과 탐색 경로 만들기 및 포함 공간 채우기에 사용되는 알고리즘을 지정합니다. 자세한 내용은 벡터 필드 추가를 참조하세요.

   벡터 필드에는 사용할 알고리즘 및 벡터 압축과 같이 벡터가 아닌 필드에는 없는 추가 속성이 있습니다.

   벡터 필드는 정렬, 필터링, 패싯 등 벡터 데이터에 유용하지 않은 특성을 생략합니다.

7. 벡터가 아닌 필드의 경우 기본 분석기("analyzer": null)를 사용할지 아니면 다른 분석기를 사용할지 결정합니다. 분석기는 인덱싱 및 쿼리 실행 중에 텍스트 필드를 토큰화하는 데 사용됩니다.

   다국어 문자열의 경우 언어 분석기를 사용하는 것이 좋습니다.

   하이픈이 추가된 문자열이나 특수 문자의 경우 특수 분석기를 사용하는 것이 좋습니다. 일례로 필드의 전체 내용을 단일 토큰으로 취급하는 키워드를 들 수 있습니다. 이 동작은 우편 번호, ID 및 일부 제품 이름과 같은 데이터에 유용합니다. 자세한 내용은 특수 문자를 사용하는 부분 용어 검색 및 패턴을 참조하세요.

필드 정의 구성

필드 컬렉션은 검색 문서의 구조를 정의합니다. 모든 필드에는 이름, 데이터 형식 및 특성이 있습니다.

필드를 검색 가능, 필터링 가능, 정렬 가능 또는 패싯 가능으로 설정하면 인덱스 크기 및 쿼리 성능에 영향을 줍니다. 쿼리 식에서 참조할 수 없는 필드에는 이러한 특성을 설정하지 마세요.

필드를 검색 가능, 필터링 가능, 정렬 가능 또는 패싯 가능으로 설정하지 않으면 쿼리 식에서 필드를 참조할 수 없습니다. 이는 쿼리에 사용되지 않지만 검색 결과에 필요한 필드에 적합합니다.

REST API에는 데이터 형식을 기반으로 하는 기본 특성이 있으며, Azure Portal의 가져오기 마법사에서도 사용됩니다. Azure SDK에는 기본값이 없지만 문자열에 대한 SearchableField 및 기본 형식의 SimpleField와 같은 속성과 동작을 통합하는 필드 서브클래스가 있습니다.

REST API에 대한 기본 필드 특성은 다음 표에 요약되어 있습니다.

또한 문자열 필드는 선택적으로 분석기 및 동의어 맵과 연결할 수 있습니다. 필터링 가능, 정렬 가능 또는 패싯 가능 형식 Edm.String 의 필드는 길이가 최대 32킬로바이트일 수 있습니다. 이러한 필드의 값은 단일 검색 용어로 처리되고 Azure AI Search에서 용어의 최대 길이는 32KB이기 때문입니다. 이보다 많은 텍스트를 단일 문자열 필드에 저장해야 하는 경우 인덱스 정의에서 필터링 가능하고 정렬 가능하며 패싯 가능을 false 명시적으로 설정해야 합니다.

벡터 필드는 차원 및 벡터 프로필과 연결되어야 합니다. Azure Portal에서 가져오기 및 벡터화 마법사를 사용하여 벡터 필드를 추가하는 경우 검색 가능한 기본값은 true이고, 그렇지 않으면 REST API를 사용하는 경우 false입니다.

필드 특성은 다음 표에 설명되어 있습니다.

인덱스 만들기

인덱스를 만들 준비가 되면 요청을 보낼 수 있는 검색 클라이언트를 사용합니다. 초기 개발 및 개념 증명 테스트를 위해 Azure Portal 또는 REST API를 사용할 수 있습니다. 그렇지 않으면 Azure SDK를 사용하는 것이 일반적입니다.

개발하는 동안 다시 빌드하는 계획을 자주 세워야 합니다. 물리적 구조는 서비스에서 만들어지므로 대부분 수정하려면 인덱스를 삭제하고 다시 만들어야 합니다. 보다 빠르게 다시 작성할 수 있도록 데이터 하위 집합을 사용하는 방안을 고려해 볼 수 있습니다.

POST https://[servicename].search.windows.net/indexes?api-version=[api-version] 
{
  "name": "hotels",
  "fields": [
    { "name": "HotelId", "type": "Edm.String", "key": true, "retrievable": true, "searchable": true, "filterable": true },
    { "name": "HotelName", "type": "Edm.String", "retrievable": true, "searchable": true, "filterable": false, "sortable": true, "facetable": false },
    { "name": "Description", "type": "Edm.String", "retrievable": true, "searchable": true, "filterable": false, "sortable": false, "facetable": false, "analyzer": "en.microsoft" },
    { "name": "Description_fr", "type": "Edm.String", "retrievable": true, "searchable": true, "filterable": false, "sortable": false, "facetable": false, "analyzer": "fr.microsoft" },
    { "name": "Address", "type": "Edm.ComplexType", 
      "fields": [
          { "name": "StreetAddress", "type": "Edm.String", "retrievable": true, "filterable": false, "sortable": false, "facetable": false, "searchable": true },
          { "name": "City", "type": "Edm.String", "retrievable": true, "searchable": true, "filterable": true, "sortable": true, "facetable": true },
          { "name": "StateProvince", "type": "Edm.String", "retrievable": true, "searchable": true, "filterable": true, "sortable": true, "facetable": true }
        ]
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ]
}

// Create the index
string indexName = "hotels";
SearchIndex index = new SearchIndex(indexName)
{
    Fields =
    {
        new SimpleField("hotelId", SearchFieldDataType.String) { IsKey = true, IsFilterable = true, IsSortable = true },
        new SearchableField("hotelName") { IsFilterable = true, IsSortable = true },
        new SearchableField("description") { AnalyzerName = LexicalAnalyzerName.EnLucene },
        new SearchableField("descriptionFr") { AnalyzerName = LexicalAnalyzerName.FrLucene }
        new ComplexField("address")
        {
            Fields =
            {
                new SearchableField("streetAddress"),
                new SearchableField("city") { IsFilterable = true, IsSortable = true, IsFacetable = true },
                new SearchableField("stateProvince") { IsFilterable = true, IsSortable = true, IsFacetable = true },
                new SearchableField("country") { SynonymMapNames = new[] { synonymMapName }, IsFilterable = true, IsSortable = true, IsFacetable = true },
                new SearchableField("postalCode") { IsFilterable = true, IsSortable = true, IsFacetable = true }
            }
        }
    }
};

await indexClient.CreateIndexAsync(index);

원본 간 쿼리에 대해 corsOptions 설정

인덱스 스키마에는 corsOptions 설정에 대한 섹션이 포함됩니다. 브라우저에서는 모든 원본 간 요청을 차단하므로 기본적으로 클라이언트 쪽 JavaScript에서 API를 호출할 수 없습니다. 인덱스에 대한 원본 간 쿼리를 허용하려면 corsOptions 특성을 설정하여 CORS(원본 간 리소스 공유)를 사용하도록 설정합니다. 보안상의 이유로 쿼리 API에서만 CORS가 지원됩니다.

"corsOptions": {
  "allowedOrigins": [
    "*"
  ],
  "maxAgeInSeconds": 300

CORS에 다음 속성을 지정할 수 있습니다.

• allowedOrigins(필수): 인덱스에 액세스할 수 있는 원본의 목록입니다. 이러한 원본에서 제공되는 JavaScript 코드는 인덱스를 쿼리할 수 있습니다(호출자가 유효한 키를 제공하거나 호출자에 권한이 있다고 가정). 각 원본은 보통 protocol://<fully-qualified-domain-name>:<port> 형식이지만 <port>는 대개 생략됩니다. 자세한 내용은 원본 간 리소스 공유(Wikipedia)를 참조하세요.

  모든 원본에 대한 액세스를 허용하려면 allowedOrigins 배열에서 *를 단일 항목으로 포함합니다. 프로덕션 검색 서비스에는 권장되지 않지만 개발 및 디버깅에 유용한 경우가 많습니다.

• maxAgeInSeconds(선택): 브라우저는 이 값을 사용하여 CORS 실행 전 응답을 캐시할 기간(초)을 결정합니다. 이 값은 음수가 아닌 정수여야 합니다. 캐시 기간이 길수록 성능이 향상되지만 CORS 정책이 적용되는 시간이 연장됩니다. 이 값을 설정하지 않으면 기본 기간(5분)이 사용됩니다.

기존 인덱스에 허용되는 업데이트

인덱스 만들기는 검색 서비스에 물리적 데이터 구조(파일 및 반전된 인덱스)를 만듭니다. 인덱스가 만들어지면 인덱스 만들기 또는 업데이트를 사용하여 변경 내용을 적용할 수 있는 기능은 수정으로 인해 실제 구조가 무효화되는지 여부에 따라 결정됩니다. 인덱스에서 필드를 만든 후에는 대부분의 필드 특성을 변경할 수 없습니다.

애플리케이션 코드에서 변동을 최소화하기 위해 검색 인덱스에 대한 안정적인 참조 역할을 하는 인덱스 별칭을 만들 수 있습니다. 인덱스 이름으로 코드를 업데이트하는 대신 최신 인덱스 버전을 가리키도록 인덱스 별칭을 업데이트할 수 있습니다.

디자인 프로세스의 변동을 최소화하기 위해 다음 표에서는 스키마의 고정 요소와 유연한 요소를 설명합니다. 고정 요소를 변경하려면 인덱스를 다시 빌드해야 하는 반면, 유연한 요소는 물리적 구현에 영향을 주지 않고 언제든지 변경할 수 있습니다. 자세한 내용은 인덱스 업데이트 또는 다시 작성을 참조하세요.

다음 단계

다음 링크를 사용하여 인덱스로 추가할 수 있는 특수한 기능에 대해 알아봅니다.

• 벡터 필드 및 벡터 프로필 추가
• 점수 매기기 프로필 추가
• 의미 체계 순위 추가
• 제안기 추가
• 동의어 맵 추가
• 분석기 추가
• 암호화 추가

인덱스 로드 또는 업데이트에 다음 링크를 사용합니다.

• 데이터 가져오기 개요
• 문서 로드
• 인덱스 업데이트 또는 다시 작성