Azure AI 검색의 벡터 스토리지

아티클
04/15/2024

Azure AI 검색은 벡터 검색 및 하이브리드 검색을 위한 벡터 스토리지 및 구성을 제공합니다. 지원은 필드 수준에서 구현됩니다. 즉, 동일한 검색 모음에서 벡터 필드와 비벡터 필드를 결합할 수 있습니다.

벡터는 검색 인덱스에 저장됩니다. 인덱스 만들기 REST API 또는 그에 상응하는 Azure SDK 메서드를 사용하여 벡터 저장소를 만듭니다.

벡터 스토리지에 대한 고려 사항은 다음과 같습니다.

의도한 벡터 검색 패턴에 따라 사용 사례에 맞게 스키마를 디자인합니다.
인덱스 크기를 예측하고 검색 서비스 용량을 확인합니다.
벡터 저장소 관리
벡터 저장소 보안

벡터 검색 패턴

Azure AI 검색에는 검색 결과를 사용하기 위한 두 가지 패턴이 있습니다.

생성형 검색. 언어 모델이 Azure AI 검색의 데이터를 사용하여 사용자의 쿼리에 대한 응답을 작성합니다. 이 패턴에는 프롬프트를 조정하고 컨텍스트를 유지 관리하는 오케스트레이션 계층이 포함됩니다. 이 패턴에서는 검색 결과가 GPT 및 Text-Davinci와 같은 채팅 모델에서 수신하는 프롬프트 흐름으로 제공됩니다. 이 방법은 검색 인덱스가 접지 데이터를 제공하는 RAG(검색 보강 생성) 아키텍처를 기반으로 합니다.
검색창, 쿼리 입력 문자열 및 렌더링된 결과를 사용한 클래식 검색. 검색 엔진은 벡터 쿼리를 수락하고 실행하고, 응답을 작성하며, 이러한 결과를 클라이언트 앱에 렌더링합니다. Azure AI 검색에서 결과는 평면화된 행 집합으로 반환되며 검색 결과를 포함할 필드를 선택할 수 있습니다. 채팅 모델이 없으므로 응답에 사람이 읽을 수 있는 비 벡터 콘텐츠로 벡터 저장소(검색 인덱스)를 채울 것으로 예상됩니다. 검색 엔진은 벡터를 기준으로 검색하지만, 검색 결과를 채우려면 비 벡터 값을 사용해야 합니다. 벡터 쿼리 및 하이브리드 쿼리는 클래식 검색 시나리오에 대해 공식화할 수 있는 쿼리 요청 유형을 다룰 있습니다.

인덱스 스키마는 기본 사용 사례를 반영해야 합니다. 다음 섹션에서는 생성형 AI 또는 클래식 검색을 위해 빌드된 솔루션의 필드 구성의 차이점을 강조합니다.

벡터 저장소의 스키마

벡터 저장소의 인덱스 스키마에는 이름, 키 필드(문자열), 하나 이상의 벡터 필드 및 벡터 구성이 필요합니다. 비 벡터 필드는 하이브리드 쿼리 또는 언어 모델을 거칠 필요가 없는 문자 그대로 사람이 읽을 수 있는 콘텐츠를 반환하는 데 권장됩니다. 벡터 구성에 대한 지침은 벡터 저장소 만들기를 참조하세요.

기본 벡터 필드 구성

벡터 필드는 데이터 형식 및 벡터별 속성으로 구분됩니다. 필드 컬렉션에서 벡터 필드의 모양은 다음과 같습니다.

{
    "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, 청크, 제목 및 벡터 필드가 있습니다. chunkID 및 부모 ID는 Blob 메타데이터(경로)의 기본 64 인코딩을 사용하여 마법사에 의해 채워집니다. 청크 및 제목은 Blob 콘텐츠 및 Blob 이름에서 파생됩니다. 벡터 필드만 완전히 생성됩니다. 청크 필드의 벡터화된 버전입니다. 포함은 제공하는 Azure OpenAI 포함 모델을 호출하여 생성됩니다.

"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-with-your-data-solution-accelerator 액셀러레이터에서 만들어집니다.

생성형 검색 환경을 지원하는 채팅 인덱스 필드:

"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 }
]

오케스트레이션 및 채팅 기록을 지원하는 대화 인덱스의 필드:

"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 }
]

다음은 대화 인덱스의 검색 탐색기 검색 결과를 보여 주는 스크린샷입니다. 검색이 부적격으로 검색 점수가 1.00입니다. 오케스트레이션 및 프롬프트 흐름을 지원하기 위해 존재하는 필드를 확인합니다. 대화 ID는 특정 채팅을 식별합니다. "type"은(는) 콘텐츠가 사용자 또는 도우미의 콘텐츠인지 여부를 나타냅니다. 날짜는 기록에서 채팅을 삭제하는 데 사용됩니다.

실제 구조 및 크기

Azure AI 검색에서 인덱스의 실제 구조는 대체로 내부 구현입니다. 스키마에 액세스하고 콘텐츠를 로드 및 쿼리하고 크기를 모니터링하며 용량을 관리할 수 있지만 Microsoft에서 내부적으로 클러스터 자체(반전 및 벡터 인덱스 및 기타 파일 및 폴더)를 관리합니다.

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

문서의 수량 및 구성
개별 필드의 특성입니다. 예를 들어 필터링 가능한 필드에는 더 많은 스토리지가 필요합니다.
유사도 검색을 위해 HNSW를 선택할지, 아니면 완전한 KNN을 선택할지에 따라 내부 탐색 구조체가 생성되는 방식을 지정하는 벡터 구성을 포함한 인덱스 구성입니다.

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

다음 스크린샷은 하나의 파티션과 하나의 복제본으로 구성된 S1 서비스를 보여줍니다. 이 특정 서비스에는 24개의 작은 인덱스가 있으며, 평균 1개의 벡터 필드가 있으며 각 필드는 1536개의 포함으로 구성됩니다. 두 번째 타일은 벡터 인덱스의 할당량 및 사용량을 보여 줍니다. 벡터 인덱스는 각 벡터 필드에 대해 만들어진 내부 데이터 구조입니다. 따라서 벡터 인덱스의 스토리지는 항상 전체 인덱스가 사용하는 스토리지의 일부에 불과합니다. 다른 비 벡터 필드 및 데이터 구조는 남은 스토리지를 사용합니다.

벡터 인덱스 제한 및 예측은 다른 문서에서 다루지만, 미리 강조하고 싶은 두 가지 사항은 서비스 계층에 따라 최대 스토리지가 다르며 검색 서비스가 생성된 시점에 따라 다르다는 것입니다. 최신 동일 계층 서비스에는 벡터 인덱스 용량이 훨씬 더 많습니다. 이러한 이유로 다음 작업을 수행합니다.

검색 서비스의 배포 날짜를 확인합니다. 2024년 4월 3일 이전에 만들어진 경우 용량을 높이기 위해 새 검색 서비스를 만드는 것이 좋습니다.
벡터 스토리지 요구 사항의 변동이 예상되는 경우 확장 가능한 계층을 선택합니다. 기본 계층은 이전 검색 서비스의 한 파티션에 고정됩니다. 더 높은 유연성과 빠른 성능을 원한다면 표준 1(S1) 이상을 고려하거나, 가능한 모든 nillable 계층에서 더 높은 제한과 더 많은 파티션을 사용하는 새로운 검색 서비스를 만드세요.

기본 작업 및 상호 작용

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

참고 항목

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

지속적으로 사용 가능

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

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

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

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

엔드포인트 연결

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

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

Azure AI Search에 연결하는 방법

사용 권한 또는 API 액세스 키가 있는지 확인합니다. 기존 인덱스 쿼리를 수행하지 않는 한 검색 서비스의 콘텐츠를 관리하고 보려면 관리자 권한 또는 기여자 역할 할당이 필요합니다.
Azure Portal을 시작합니다. 검색 서비스를 만든 사용자는 액세스 제어(IAM) 페이지를 통해 다른 사용자에게 액세스 권한을 부여하는 등 검색 서비스를 보고 관리할 수 있습니다.
프로그래매틱 액세스를 위해 다른 클라이언트로 이동합니다. 첫 단계로 빠른 시작과 샘플을 권장합니다.
- 빠른 시작: REST
- 벡터 샘플

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

Azure AI Search는 데이터 암호화, 인터넷이 없는 시나리오를 위한 비공개 연결, Microsoft Entra ID를 통한 보안 액세스를 위한 역할 할당을 구현합니다. 엔터프라이즈 보안 기능의 전체 범위는 Azure AI Search 보안에 설명되어 있습니다.

벡터 저장소 관리

Azure는 진단 로깅 및 경고를 포함하는 모니터링 플랫폼을 제공합니다. 다음과 같은 최선의 구현 방법을 권장합니다.

다음을 통해 공유