Azure AI 검색의 검색 인덱서
Azure AI 검색에서 검색 인덱스는 인덱싱, 전체 텍스트 검색, 벡터 검색, 하이브리드 검색 및 필터링된 쿼리를 수행하는 검색 엔진에서 사용할 수 있는 검색 가능한 콘텐츠입니다. 인덱스는 스키마에 의해 정의되고 검색 서비스에 저장되며, 데이터 가져오기는 두 번째 단계로 수행됩니다. 이 콘텐츠는 최신 검색 애플리케이션에서 예상되는 밀리초 응답 시간에 필요한 주 데이터 저장소와 별도로 검색 서비스 내에 존재합니다. 인덱서 기반 인덱싱 시나리오를 제외하고 검색 서비스는 원본 데이터에 연결하거나 쿼리하지 않습니다.
검색 인덱스를 만들고 관리하려는 경우 이 문서는 다음 사항을 이해하는 데 도움이 됩니다.
- 콘텐츠(문서 및 스키마)
- 실제 데이터 구조
- 기본 작업
바로 실습을 원하나요? 대신 검색 인덱스 만들기를 참조하세요.
검색 인덱스 스키마
Azure AI 검색에서 인덱스는 검색 문서를 포함합니다. 개념상, 문서는 인덱스에서 검색 가능한 데이터의 단일 단위입니다. 예를 들어, 소매점에는 각 제품에 대한 문서가 있고, 뉴스 조직에는 각 아티클에 대한 문서가 있으며, 여행 사이트에는 각 호텔 및 대상에 대한 문서가 있을 수 있습니다. 이러한 개념을 좀 더 익숙한 데이터베이스 대응 개념과 연관 지어 살펴보면 ‘검색 인덱스’는 ‘테이블’에 해당하고 ‘문서’는 테이블의 ‘행’과 거의 비슷합니다.
문서 구조는 다음 예제와 같이 인덱스 스키마에 의해 결정됩니다. 일반적으로 “field” 컬렉션이 인덱스의 가장 큰 부분이고 필드마다 이름이 지정되고 데이터 형식이 할당되며 사용 방법을 결정하는 허용 가능한 동작으로 특성이 지정됩니다.
{
"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){ }
}
간결함을 위해 다른 요소는 축소되어 있지만 다음 링크를 통해 세부 정보를 확인할 수 있습니다.
- suggesters는 자동 완성과 같은 type-ahead 쿼리를 지원합니다.
- scoringProfiles는 관련성 튜닝에 사용됩니다.
- analyzers는 언어 규칙 또는 분석기에서 지원하는 기타 특성에 따라 문자열을 토큰으로 처리하는 데 사용됩니다.
- corsOptions(CORS(원본 간 원격 스크립팅))는 다른 도메인에서 요청을 발행하는 앱에 사용됩니다.
- encryptionKey는 인덱스에 있는 중요한 콘텐츠의 이중 암호화를 구성합니다.
- semantic은 전체 텍스트 및 하이브리드 검색에서 의미 체계 순위 다시 지정을 구성합니다.
- vectorSearch는 벡터 필드와 쿼리를 구성합니다.
필드 정의
검색 문서는 인덱스 만들기 요청의 본문에 있는 "fields" 컬렉션에 의해 정의됩니다. 문서 식별(키), 검색 가능한 텍스트 저장용 필드와 필터, 패싯 및 정렬 지원용 필드가 필요합니다. 사용자가 전혀 볼 수 없는 데이터에 대한 필드가 필요할 수도 있습니다. 예를 들어 검색 점수를 높이기 위해 채점 프로필에서 사용할 수 있는 이익률이나 마케팅 프로모션에 대한 필드가 필요할 수 있습니다.
수신 데이터가 본질적으로 계층적인 경우 인덱스 내에서 중첩 구조에 사용되는 복합 형식으로 나타낼 수 있습니다. 기본 제공 샘플 데이터 세트인 Hotels는 각 호텔과 일대일 관계를 갖는 Address(여러 하위 필드 포함)를 사용하는 복합 형식을 보여주며 Rooms 복합 컬렉션에서는 여러 객실이 각 호텔과 연결되어 있습니다.
필드 특성
필드 특성에 따라 필드가 사용되는 방식(예: 전체 텍스트 검색, 패싯 탐색, 정렬 작업 등에서 사용되는지 여부)이 결정됩니다.
문자열 필드는 보통 “검색 가능” 및 “조회 가능”으로 표시됩니다. 검색 결과 범위를 좁히는 데 사용되는 필드는 “정렬 가능”, “필터링 가능”, “패싯 가능”이 있습니다.
| attribute | 설명 |
|---|---|
| “검색 가능” | 전체 텍스트 또는 벡터 검색 가능. 텍스트 필드에는 인덱싱 중에 단어 분리와 같은 어휘 분석이 적용됩니다. 검색 가능 필드를 “sunny day”와 같은 값으로 설정하면 내부적으로 해당 필드가 개별 토큰 “sunny” 및 “day”로 분할됩니다. 자세한 내용은 전체 텍스트 검색 작동 방식을 참조하세요. |
| “필터링 가능” | $filter 쿼리에서 참조됩니다. 형식이 Edm.String 또는 Collection(Edm.String)인 필터링 가능 필드에서는 단어 분리가 수행되지 않으므로 정확하게 일치하는 항목만 비교합니다. 예를 들어 필드 f를 “sunny day”로 설정하면 $filter=f eq 'sunny'에서는 일치하는 항목이 발견되지 않지만 $filter=f eq 'sunny day'에서는 일치하는 항목이 발견됩니다. |
| “정렬 가능” | 기본적으로 시스템은 점수에 따라 결과를 정렬하지만 문서에 있는 필드를 기반으로 정렬하도록 구성할 수 있습니다. 형식이 Collection(Edm.String)인 필드는 “sortable”일 수 없습니다. |
| “패싯 가능” | 일반적으로 카테고리별 적중 횟수가 포함된 검색 결과를 표시하는 데 사용됩니다(예: 특정 도시의 호텔). 형식이 Edm.GeographyPoint인 필드에서는 이 옵션을 사용할 수 없습니다. “필터링 가능”, “정렬 가능” 또는 “패싯 가능”하고 형식이 Edm.String인 필드는 길이가 최대 32KB일 수 있습니다. 자세한 내용은 인덱스 만들기(REST API)를 참조하세요. |
| “키” | 인덱스 내의 문서에 대한 고유 식별자입니다. 정확히 하나의 필드를 키 필드로 선택해야 하며 해당 필드의 형식은 Edm.String이어야 합니다. |
| “조회 가능” | 검색 결과에서 필드를 반환할 수 있는지 여부를 결정합니다. 이익률과 같은 필드를 필터, 정렬 또는 채점 메커니즘으로 사용하지만 최종 사용자에게는 필드를 표시하지 않으려는 경우에 유용합니다. true for key 로 설정해야 합니다. |
언제든지 새 필드를 추가할 수 있지만 기존 필드 정의는 인덱스 수명 동안 잠겨 있습니다. 이러한 이유로 개발자는 일반적으로 포털을 사용하여 간단한 인덱스를 만들거나 아이디어를 테스트하거나 포털 페이지를 사용하여 설정을 조회합니다. 인덱스를 쉽게 다시 작성할 수 있도록 코드 기반 접근 방식을 따르는 경우 인덱스 대한 빈번한 반복 디자인이 보다 효율적입니다.
참고 항목
인덱스를 빌드하는 데 사용하는 API에는 다양한 기본 동작이 있습니다. REST API의 경우 대부분의 특성은 기본적으로 사용하도록 설정됩니다. 예를 들어 “검색 가능” 및 “조회 가능”은 문자열 필드에 대해 true이며, 이를 해제하려는 경우에만 설정이 필요한 경우가 많습니다. .NET SDK는 그 반대의 경우가 해당합니다. 명시적으로 설정하지 않은 속성의 경우 사용자가 특별히 사용하도록 설정하지 않는 한 기본적으로 해당 검색 동작을 사용 안 함으로 설정합니다.
실제 구조 및 크기
Azure AI 검색에서 인덱스의 실제 구조는 대체로 내부 구현입니다. 스키마에 액세스하고 콘텐츠를 쿼리하고 크기를 모니터링하며 용량을 관리할 수 있지만 Microsoft에서 내부적으로 클러스터 자체(인덱스, 분할, 기타 파일 및 폴더)를 관리합니다.
Azure Portal의 인덱스 탭에서 또는 검색 서비스에 대해 GET INDEX 요청을 실행하여 인덱스 크기를 모니터링할 수 있습니다. 서비스 통계 요청을 발급하고 스토리지 크기 값을 확인할 수도 있습니다.
인덱스의 크기는 다음에 의해 결정됩니다.
- 문서의 수량 및 구성
- 개별 필드의 특성
- 인덱스 구성(구체적으로 제안기 포함 여부)
문서 구성과 수량은 가져올 항목에 따라 결정됩니다. 검색 인덱스에는 검색 가능한 콘텐츠만 포함되어야 합니다. 원본 데이터에 이진 필드가 포함된 경우 AI 보강을 사용하여 콘텐츠를 분해하고 분석해 텍스트 검색 가능 정보를 만들지 않는 한 해당 필드를 생략합니다.
필드 특성은 동작을 결정합니다. 이러한 동작을 지원하기 위해 인덱싱 프로세스는 필요한 데이터 구조를 만듭니다. 예를 들어 형식이 Edm.String인 필드의 경우 "searchable"은 전체 텍스트 검색을 호출하여 토큰화된 용어의 반전 인덱스를 스캔합니다. 반대로 "필터 가능" 또는 "정렬 가능" 특성은 수정되지 않은 문자열에 대한 반복을 지원합니다. 다음 섹션의 예는 선택한 특성에 따라 인덱스 크기의 변화를 보여 줍니다.
제안기는 자동 완성 쿼리를 지원하는 구문입니다. 따라서 제안기를 포함하면 인덱싱 프로세스에서 약어 문자 일치 항목에 필요한 데이터 구조가 생성됩니다. 제안기는 필드 수준에서 구현되므로 자동 완성에 적합한 필드만 선택합니다.
특성 및 제안기의 스토리지 영향을 보여 주는 예
다음 스크린샷은 다양한 특성을 조합한 인덱스 스토리지 패턴을 보여줍니다. 이 인덱스는 부동산 샘플 인덱스를 기반으로 하며 데이터 가져오기 마법사와 기본 제공된 샘플 데이터를 사용하여 쉽게 만들 수 있습니다. 인덱스 스키마는 표시되지 않지만 인덱스 이름을 기반으로 특성을 유추할 수 있습니다. 예를 들어 realestate-searchable 인덱스에서는 “검색 가능” 특성만 선택되었고 그 외에는 아무것도 선택되지 않았으며, realestate-retrievable 인덱스에서는 “조회 가능” 특성만 선택되었고 그 외에는 아무것도 선택되지 않았습니다.
이러한 인덱스 변형은 다소 인위적이지만 특성이 스토리지에 미치는 영향을 광범위하게 비교하기 위해 참조할 수 있습니다.
- "retrievable"은 인덱스 크기에 영향을 미치지 않습니다.
- "filterable", "sortable", "facetable"은 더 많은 스토리지를 사용합니다.
- 제안기는 인덱스 크기를 늘릴 가능성이 크지만 스크린샷이 나타내는 만큼은 아닙니다(제안기를 인식할 수 있는 모든 필드가 선택되었으며 이는 대부분의 인덱스에서 가능한 시나리오가 아닙니다).
또한 analyzers 영향은 위의 표에 반영되지 않습니다. edgeNgram 토크나이저를 사용하여 문자의 축자 시퀀스(a, ab, abc, abcd)를 저장하면 인덱스는 표준 분석기를 사용한 경우보다 더 커집니다.
기본 작업 및 상호 작용
인덱스가 무엇인지 더 잘 이해했으므로 이 섹션에서는 단일 인덱스에 대한 연결 및 보안을 포함하여 인덱스 런타임 작업을 소개합니다.
참고 항목
인덱스를 관리할 때 인덱스를 이동하거나 복사하기 위한 포털 또는 API 지원이 없다는 점에 유의합니다. 대신 고객은 일반적으로 애플리케이션 배포 솔루션을 다른 검색 서비스(동일한 인덱스 이름을 사용하는 경우)에 지정하거나 이름을 수정하여 현재 검색 서비스에 복사본을 만든 다음 빌드합니다.
인덱스 격리
Azure AI 검색에서는 한 번에 모든 인덱스 관련 작업이 단일 인덱스를 대상으로 하는 인덱스 하나로 작업합니다. 인덱싱 또는 쿼리를 위한 관련 인덱스 또는 독립 인덱스 조인에 대한 개념은 없습니다.
지속적으로 사용 가능
첫 번째 문서가 인덱싱되는 즉시 인덱스를 쿼리에 사용할 수 있지만 모든 문서가 인덱싱될 때까지는 완전히 작동하지 않습니다. 내부적으로 검색 인덱스는 파티션에 분산되어 복제본에서 실행됩니다. 물리적 인덱스는 내부적으로 관리됩니다. 논리 인덱스는 자동으로 관리됩니다.
인덱스는 계속 사용할 수 있으며 일시 중지하거나 오프라인으로 전환할 수 없습니다. 지속적인 작업을 위해 설계되었기 때문에 콘텐츠에 대한 모든 업데이트 또는 인덱스 자체에 대한 추가가 실시간으로 발생합니다. 결과적으로 요청이 문서 업데이트와 일치하는 경우 쿼리가 일시적으로 불완전한 결과를 반환할 수 있습니다.
문서 작업(새로 고침 또는 삭제) 및 현재 인덱스의 기존 구조와 무결성에 영향을 미치지 않는 수정(예: 새 필드 추가)에 대한 쿼리 연속성이 존재합니다. 구조적 업데이트(기존 필드 변경)가 필요한 경우 일반적으로 개발 환경에서 드롭 앤 다시 빌드 워크플로를 사용하거나 프로덕션 서비스에서 인덱스의 새 버전을 만들어 관리합니다.
인덱스 다시 빌드를 방지하기 위해 작은 변경을 수행하는 일부 고객은 이전 버전과 함께 공존하는 새 필드를 만들어 필드의 "버전을 지정"하도록 선택합니다. 시간이 지남에 따라 특히 복제 비용이 많이 드는 프로덕션 인덱스에서 사용되지 않는 필드 또는 사용되지 않는 사용자 지정 분석기 정의의 형태로 분리된 콘텐츠가 생성됩니다. 인덱스 수명 주기 관리의 일부로 계획된 인덱스 업데이트에서 이러한 문제를 해결할 수 있습니다.
엔드포인트 연결 및 보안
모든 인덱싱 및 쿼리 요청은 인덱스를 대상으로 합니다. 엔드포인트는 일반적으로 다음 중 하나입니다.
| 엔드포인트 | 연결 및 액세스 제어 |
|---|---|
<your-service>.search.windows.net/indexes |
인덱스 컬렉션을 대상으로 합니다. 인덱스를 만들기, 나열 또는 삭제할 때 사용됩니다. 이러한 작업에는 관리자 권한이 필요하며 관리자 API 키 또는 검색 기여자 역할을 통해 사용할 수 있습니다. |
<your-service>.search.windows.net/indexes/<your-index>/docs |
단일 인덱스의 문서 컬렉션을 대상으로 합니다. 인덱스 또는 데이터 새로 고침을 쿼리할 때 사용됩니다. 쿼리의 경우 읽기 권한이면 충분하며 쿼리 API 키 또는 데이터 읽기 권한자 역할을 통해 사용할 수 있습니다. 데이터 새로 고침을 위해서는 관리자 권한이 필요합니다. |
Azure AI Search에 연결하는 방법
Azure Portal을 시작합니다. Azure 구독자 또는 검색 서비스를 만든 사용자는 Azure Portal에서 검색 서비스를 관리할 수 있습니다. Azure 구독에는 서비스를 만들거나 삭제할 수 있는 기여자 이상의 권한이 필요합니다. 이 권한 수준은 Azure Portal에서 검색 서비스를 완전히 관리하기에 충분합니다.
프로그래매틱 액세스를 위해 다른 클라이언트를 사용해 보세요. 첫 번째 단계에 다음 빠른 시작을 사용하는 것이 좋습니다.
다음 단계
Azure AI 검색에 대한 거의 모든 샘플이나 연습을 사용하여 인덱스 만들기를 실습할 수 있습니다. 먼저 목차에서 빠른 시작 중 하나를 선택할 수 있습니다.
하지만 데이터로 인덱스를 로드하는 방법론에 대해서도 알고 싶을 것입니다. 인덱스 정의 및 데이터 가져오기 전략은 동시에 정의됩니다. 다음 문서에서는 인덱스 만들기 및 로드에 대한 자세한 정보를 제공합니다.