Azure AI Search의 벡터 인덱스

벡터는 텍스트, 이미지 및 기타 콘텐츠를 수학적으로 나타내는 고차원 포함입니다. Azure AI Search는 필드 수준에서 벡터를 저장하므로 벡터 및 비벡터 콘텐츠가 동일한 검색 인덱스 내에서 공존할 수 있습니다.

검색 인덱스는 벡터 필드 및 벡터 구성을 정의할 때 벡터 인덱 스가 됩니다. 벡터 필드를 채우려면 미리 계산된 임베딩을 푸시하거나 인덱싱 중에 포함을 생성하는 기본 제공 Azure AI Search 기능인 통합 벡터화를 사용할 수 있습니다.

쿼리 시 인덱스의 벡터 필드는 유사성 검색을 사용하도록 설정합니다. 여기서 시스템은 벡터가 벡터 쿼리와 가장 유사한 문서를 검색합니다. 유사성 일치에 대한 벡터 검색 을 단독으로 사용하거나 하이브리드 검색 을 사용하여 유사성과 키워드 일치의 조합을 사용할 수 있습니다.

이 문서에서는 다음을 포함하여 벡터 인덱스를 만들고 관리하기 위한 주요 개념을 다룹니다.

• 벡터 검색 패턴
• 콘텐츠(벡터 필드 및 구성)
• 실제 데이터 구조
• 기본 작업

벡터 검색 패턴

Azure AI Search는 벡터 검색을 위한 두 가지 패턴을 지원합니다.

• 클래식 검색. 이 패턴은 검색 창, 쿼리 입력 및 렌더링된 결과를 사용합니다. 쿼리를 실행하는 동안 검색 엔진 또는 애플리케이션 코드는 사용자 입력을 벡터화합니다. 그런 다음 검색 엔진은 인덱스의 벡터 필드에 대해 벡터 검색을 수행하고 클라이언트 앱에서 렌더링하는 응답을 작성합니다.

  Azure AI Search에서 결과는 평면화된 행 집합으로 반환되며 응답에 포함할 필드를 선택할 수 있습니다. 검색 엔진이 벡터와 일치하더라도, 인덱스에는 검색 결과를 채우기 위한 사람이 읽을 수 있는 비벡터 콘텐츠가 포함되어야 합니다. 클래식 검색은 벡터 쿼리 와 하이브리드 쿼리를 모두 지원합니다.

• 생성 검색. 언어 모델은 Azure AI Search의 데이터를 사용하여 사용자 쿼리에 응답합니다. 오케스트레이션 계층은 일반적으로 프롬프트를 조정하고 컨텍스트를 유지 관리하여 검색 결과를 GPT와 같은 채팅 모델에 공급합니다. 이 패턴은 검색 인덱스가 접지 데이터를 제공하는 RAG(검색 보강 생성) 아키텍처를 기반으로 합니다.

벡터 인덱스의 스키마

벡터 인덱스의 스키마에는 다음이 필요합니다.

• 이름
• 키 필드(문자열)
• 하나 이상의 벡터 필드
• 벡터 구성

비벡터 필드는 필요하지 않지만 하이브리드 쿼리에 포함하거나 언어 모델을 거치지 않는 축자 콘텐츠를 반환하는 것이 좋습니다. 자세한 내용은 벡터 인덱스 만들기를 참조하세요.

인덱스 스키마는 벡터 검색 패턴을 반영해야 합니다. 이 섹션에서는 주로 클래식 검색에 대한 필드 컴퍼지션을 다루지만 생성 검색에 대한 스키마 지침도 제공합니다.

기본 벡터 필드 구성

벡터 필드에는 고유한 데이터 형식과 속성이 있습니다. 필드 컬렉션에서 벡터 필드의 모양은 다음과 같습니다.

{
    "name": "content_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "retrievable": true,
    "dimensions": 1536,
    "vectorSearchProfile": "my-vector-profile"
}

특정 데이터 형식만 벡터 필드에 대해 지원됩니다. 가장 일반적인 형식은 Collection(Edm.Single)좁은 형식을 사용하면 스토리지에 저장할 수 있습니다.

벡터 필드는 검색 가능하고 검색 가능해야 하지만 필터링 가능하거나 분류 가능하거나 정렬할 수 없습니다. 또한 분석기, 정규화기 또는 동의어 맵 할당을 가질 수 없습니다.

이 속성은 dimensions 포함 모델에서 생성된 포함 횟수로 설정해야 합니다. 예를 들어 text-embedding-ada-002는 각 텍스트 청크에 대해 1,536개의 포함을 생성합니다.

벡터 필드는 벡터 검색 프로필에 지정된 알고리즘을 사용하여 인덱싱됩니다. 이 알고리즘은 인덱스의 다른 위치에서 정의되며 이 예제에는 표시되지 않습니다. 자세한 내용은 벡터 검색 구성 추가를 참조하세요.

기본 벡터 워크로드에 대한 필드 컬렉션

벡터 인덱스에는 벡터 필드 이상이 필요합니다. 예를 들어 모든 인덱스에는 다음 예제와 같은 키 필드가 id 있어야 합니다.

"name": "example-basic-vector-idx",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
  { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]

content 필드와 같은 다른 필드는 content_vector 필드의 사람이 읽을 수 있는 등가물을 제공합니다. 응답 공식화 전용으로 언어 모델을 사용하는 경우에는 비 벡터 콘텐츠 필드를 생략할 수 있지만, 검색 결과를 클라이언트 앱에 직접 푸시하는 솔루션에는 비 벡터 콘텐츠가 있어야 합니다.

메타데이터 필드는 특히 원본 문서에 대한 원본 정보를 포함하는 필터에 유용합니다. 벡터 필드에서 직접 필터링할 수는 없지만 사전 필터, 사후 필터 또는 엄격한 사후 필터(미리 보기) 모드를 설정하여 벡터 쿼리 실행 전이나 후에 필터링할 수 있습니다.

가져오기 마법사에서 생성된 스키마

평가 및 개념 증명 테스트를 위해 데이터 가져오기(새) 마법사 를 사용하는 것이 좋습니다. 이 마법사는 이 섹션에서 예제 스키마를 생성합니다.

마법사는 콘텐츠를 더 작은 검색 문서로 분할하여 언어 모델을 사용하여 응답을 작성하는 RAG 앱에 이점을 제공합니다. 청킹을 사용하면 언어 모델의 입력 제한과 의미 랭킹 시스템의 토큰 제한 내에서 유지할 수 있습니다. 또한 여러 부모 문서에서 가져온 청크에 대해 쿼리를 일치시켜 유사성 검색의 정밀도를 향상시킵니다. 자세한 내용은 벡터 검색 솔루션을 위한 대용량 문서 청크 분할을 참조하세요.

다음 예제의 각 검색 문서에는 청크 ID, 부모 ID, 청크, 제목 및 벡터 필드가 하나 있습니다. 마법사:

• chunk_id 및 parent_id 필드를 base64로 인코딩된 Blob 메타데이터(경로)로 입력합니다.

• Blob 콘텐츠 및 Blob 이름에서 각각 chunk 및 title 필드를 추출합니다.

• vector 필드를 벡터화하기 위해 제공한 Azure OpenAI 포함 모델을 호출하여 chunk 필드를 만듭니다. 이 프로세스 중에는 벡터 필드만 완전히 생성됩니다.

"name": "example-index-from-import-wizard",
"fields": [
  { "name": "chunk_id", "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
  { "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
  { "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
  { "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]

생성 검색을 위한 스키마

RAG 및 채팅 스타일 앱용 벡터 스토리지를 디자인하는 경우 다음 두 개의 인덱스를 만들 수 있습니다.

• 인덱싱하고 벡터화한 정적 콘텐츠용입니다.
• 프롬프트 흐름에 사용할 수 있는 대화용.

설명을 위해 이 섹션에서는 채팅-위드-유어-데이터-솔루션-액셀러레이터를 사용하여 chat-index 및 conversations 인덱스를 만듭니다.

chat-index의 다음 필드는 생성 검색 경험을 지원합니다.

"name": "example-index-from-accelerator",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
  { "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true  },
  { "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]

conversations의 다음 필드는 오케스트레이션 및 채팅 기록을 지원합니다.

"fields": [
    { "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
    { "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
    { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
    { "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]

다음 스크린샷은 conversations 결과를 보여줍니다.

이 예제에서는 검색이 적격하지 않아 검색 점수가 1.00입니다. 여러 필드는 오케스트레이션 및 프롬프트 흐름을 지원합니다.

• conversation_id 는 각 채팅 세션을 식별합니다.
• type은(는) 콘텐츠가 사용자 또는 도우미의 콘텐츠인지 여부를 나타냅니다.
• created_at 및 updated_at는 기록에서 채팅을 만료합니다.

실제 구조 및 크기

Azure AI 검색에서 인덱스의 실제 구조는 대체로 내부 구현입니다. 스키마에 액세스하고, 콘텐츠를 로드 및 쿼리하고, 크기를 모니터링하고, 용량을 관리할 수 있습니다. 그러나 Microsoft는 검색 서비스와 함께 저장된 인프라 및 물리적 데이터 구조를 관리합니다.

인덱스의 크기와 실체는 다음을 통해 결정됩니다.

• 문서의 수량 및 구성입니다.

• 개별 필드의 특성입니다. 예를 들어 필터링 가능한 필드에는 더 많은 스토리지가 필요합니다.

• 내부 탐색 구조를 만드는 방법을 지정하는 벡터 구성을 포함한 인덱스 구성입니다. 유사성 검색을 위해 HNSW 또는 철저한 KNN을 선택할 수 있습니다.

Azure AI Search는 모든 워크로드에 대해 균형 있고 안정적인 시스템을 유지하는 데 도움이 되는 벡터 스토리지에 제한을 적용합니다. 제한을 벗어나는 데 도움이 되도록 벡터 사용량은 Azure Portal에서 별도로 추적 및 보고되며 서비스 및 인덱스 통계를 통해 프로그래밍 방식으로 보고됩니다.

다음 스크린샷은 하나의 파티션과 하나의 복제본으로 구성된 S1 서비스를 보여줍니다. 이 서비스에는 각각 평균적으로 1,536개의 임베딩으로 구성된 하나의 벡터 필드를 포함하는 24개의 작은 인덱스가 있습니다. 두 번째 타일은 벡터 인덱스의 할당량 및 사용량을 보여 줍니다. 벡터 인덱스는 각 벡터 필드에 대해 만들어진 내부 데이터 구조이므로 벡터 인덱스에 대한 스토리지는 항상 인덱스에 사용되는 전체 스토리지의 일부입니다. 비벡터 필드 및 기타 데이터 구조는 나머지를 사용합니다.

벡터 인덱스 제한 및 예측은 다른 문서에서 다루지만, 강조해야 할 두 가지 점은 최대 스토리지가 검색 서비스의 생성 날짜 및 가격 책정 계층에 달려 있다는 것입니다. 최신 동일 계층 서비스에는 벡터 인덱스 용량이 훨씬 더 많습니다. 이러한 이유로 다음을 수행해야 합니다.

• 검색 서비스의 생성 날짜를 확인합니다. 2024년 4월 3일 이전에 만들어진 경우 더 큰 용량을 위해 서비스를 업그레이드 할 수 있습니다.

• 벡터 스토리지 요구 사항의 변동이 예상되는 경우 확장 가능한 계층을 선택합니다. 이전 검색 서비스의 경우 기본 계층은 하나의 파티션에서 고정됩니다. 더 많은 유연성과 더 빠른 성능을 위해 표준 1(S1) 이상을 고려합니다. 또한 기본 및 표준(S1, S2, S3) 계층 간에 전환할 수 있습니다.

기본 작업 및 상호 작용

이 섹션에서는 단일 인덱스에 연결 및 보안을 포함하여 벡터 런타임 작업을 소개합니다.

인덱스 격리

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

지속적으로 사용 가능

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

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

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

인덱스 재구축을 피하기 위해, 일부 고객은 필드에 작은 변경을 가하면서 기존 버전과 함께 공존하는 새 필드를 만들어 '버전 제어'를 합니다. 시간이 지남에 따라, 특히 복제 비용이 많이 드는 프로덕션 인덱스에서는, 더 이상 사용되지 않는 필드와 사용자 지정 분석기 정의로 인해 고립된 콘텐츠가 발생할 수 있습니다. 인덱스 수명 주기 관리의 일환으로 인덱스에 대한 계획된 업데이트 중에 이러한 문제를 해결할 수 있습니다.

엔드포인트 연결

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

Azure AI Search에 연결하는 방법

1. 사용 권한 또는 API 액세스 키가 있는지 확인합니다. 기존 인덱스 쿼리를 하지 않는 한 검색 서비스에서 콘텐츠를 관리하고 보려면 관리자 권한 또는 기여자 역할 할당이 필요합니다.

2. Azure Portal을 시작합니다. 검색 서비스를 만든 사용자는 IAM(액세스 제어) 페이지에서 다른 사용자에게 액세스 권한을 부여하는 등 검색 서비스를 보고 관리할 수 있습니다.

3. 프로그래매틱 액세스를 위해 다른 클라이언트로 이동합니다. 첫 번째 단계에서는 REST 및 azure-search-vector-samples 리포지토리를 사용하여 벡터 검색 빠른 시작을 권장합니다.

벡터 저장소 관리

Azure는 진단 로깅 및 경고를 포함하는 모니터링 플랫폼을 제공합니다. 다음을 수행하는 것이 좋습니다.

• 진단 로깅을 사용하도록 설정합니다.
• 경고 설정.
• 쿼리 및 인덱스 성능을 분석합니다.

벡터 데이터에 안전하게 액세스

Azure AI Search는 데이터 암호화, 인터넷이 없는 시나리오를 위한 비공개 연결, Microsoft Entra ID를 통한 보안 액세스를 위한 역할 할당을 구현합니다. 엔터프라이즈 보안 기능에 대한 자세한 내용은 Azure AI Search의 보안을 참조하세요.

관련 콘텐츠

• 빠른 시작: REST를 사용한 벡터 검색
• 벡터 인덱스 생성
• 벡터 인덱스 쿼리