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

Azure AI 검색에서 쿼리 요청은 검색 인덱스에서 검색 가능한 텍스트를 대상으로 합니다.

이 문서에서는 검색 인덱스 정의 및 게시 단계를 알아봅니다. 인덱스를 만들면 검색 서비스에 물리적 데이터 구조가 설정됩니다. 인덱스 정의가 있으면 인덱스 로드 작업이 별도의 작업으로 이어서 수행됩니다.

필수 조건

  • 쓰기 권한. 요청에 대한 관리자 API 키를 통해 권한을 부여할 수 있습니다. 또는 역할 기반 액세스 제어를 사용하는 경우 검색 기여자 역할의 구성원으로 요청을 보냅니다.

  • 인덱싱하려는 데이터 이해. 인덱스 만들기는 스키마 정의 연습이므로 검색, 가져오기, 필터링, 패싯 및 정렬이 가능하도록 원본 필드에 대한 명확한 아이디어가 있어야 합니다(참고 자료는 스키마 검사 목록 참조).

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

  • 안정적인 인덱스 위치. 기본적으로 기존 인덱스를 다른 검색 서비스로 이동할 수 없습니다. 애플리케이션 요구 사항을 다시 검토하고 기존 검색 서비스, 해당 용량 및 위치가 요구 사항에 충분한지 확인합니다.

  • 마지막으로, 모든 서비스 계층에는 만들 수 있는 개체 수에 대한 인덱스 한도가 있습니다. 예를 들어 무료 계층을 실험하는 경우 지정된 시간에 인덱스 3개만 있을 수 있습니다. 인덱스 자체 내에는 복합 필드 및 컬렉션 수에 대한 한도가 있습니다.

문서 키

검색 인덱스에는 문서 키라는 필수 필드가 하나 있습니다. 문서 키는 검색 문서의 고유 식별자입니다. Azure AI 검색에서는 문자열이어야 하며 인덱싱할 콘텐츠를 제공하는 데이터 원본의 고유 값에서 비롯되어야 합니다. 검색 서비스는 키 값을 생성하지 않지만 일부 시나리오(예: Azure Table indexer)에서는 기존 값을 합성하여 인덱싱되는 문서의 고유 키를 만듭니다.

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

스키마 검사 목록

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

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

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

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

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

    필드 특성 할당은 검색 서비스에서 검색 동작과 인덱스의 물리적 표현을 모두 결정합니다. 필드를 지정하는 방법을 결정하는 것은 많은 고객에게 반복적인 프로세스입니다. 반복 속도를 높이려면 쉽게 삭제하고 다시 빌드할 수 있도록 샘플 데이터로 시작합니다.

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

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

    • 필터링 가능한 필드는 임의의 순서로 반환되므로 정렬 가능하게 만드는 것이 좋습니다.

  6. 기본 분석기("analyzer": null) 또는 다른 분석기를 사용할지 여부를 결정합니다. 분석기는 인덱싱 및 쿼리 실행 중에 텍스트 필드를 토큰화하는 데 사용됩니다.

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

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

참고 항목

전체 텍스트 검색은 인덱싱 중에 토큰화된 용어에 대해 수행됩니다. 쿼리가 예상한 결과를 반환하지 못하면 토큰화 테스트를 수행하여 문자열이 실제로 존재하는지 확인합니다. 문자열에서 여러 분석기를 시도하여 다양한 분석기에서 토큰이 생성되는 방법을 확인할 수 있습니다.

인덱스 만들기

인덱스를 만들 준비가 되면 요청을 보낼 수 있는 검색 클라이언트를 사용합니다. 초기 개발 및 개념 증명 테스트에는 Azure Portal 또는 REST API를 사용하면 됩니다.

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

포털을 통한 인덱스 디자인은 숫자 필드에서 전체 텍스트 검색 기능을 허용하지 않는 등의 특정 데이터 형식에 대한 요구 사항 및 스키마 규칙을 적용합니다.

  1. Azure Portal에 로그인합니다.

  2. 검색 서비스 개요 페이지에서 검색 인덱스 만들기 옵션을 선택합니다.

    이 마법사는 인덱서, 데이터 원본 및 완성된 인덱스를 만드는 엔드투엔드 워크플로입니다. 데이터도 로드합니다. 기능이 필요 이상으로 많다면 인덱스 추가를 대신 사용하세요.

다음 스크린샷은 명령 모음에서 인덱스 추가데이터 가져오기가 표시되는 위치를 강조 표시합니다. 인덱스가 생성된 후 인덱스 탭에서 인덱스를 다시 확인할 수 있습니다.

인덱스 추가 명령

포털에서 인덱스를 만든 후 JSON 표현을 복사하여 애플리케이션 코드에 추가할 수 있습니다.

원본 간 쿼리에 대해 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분)이 사용됩니다.

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

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

또는 애플리케이션 코드에서 안정적인 참조 역할을 하는 인덱스 별칭을 생성할 수 있습니다. 코드를 업데이트하는 대신 최신 인덱스 버전을 가리키도록 인덱스 별칭을 업데이트할 수 있습니다.

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

요소 업데이트 가능 여부
이름 아니요
아니요
필드 이름 및 형식 아니요
필드 특성(검색 가능, 필터링 가능, 패싯 가능, 정렬 가능) 아니요
필드 특성(가져오기 가능)
분석기 인덱스에서 사용자 지정 분석기를 추가하고 수정할 수 있습니다. 문자열 필드의 분석기 할당과 관련하여 searchAnalyzer만 수정할 수 있습니다. 다른 모든 할당 및 수정에는 다시 빌드가 필요합니다.
점수 매기기 프로필
확인기 아니요
CORS(원본 간 리소스 공유)
암호화

다음 단계

다음 링크를 사용하여 데이터로 인덱스를 로드하거나 동의어 맵을 사용하여 인덱스를 확장하는 방법을 숙지할 수 있습니다.