Azure AI 검색 서버리스 가격 책정 모델에 대한 비용 최적화

Azure AI 검색 각각 다른 워크로드 패턴을 위해 설계된 두 가지 가격 책정 모델을 지원합니다.

• 전용:SU(검색 단위)로 측정된 고정 가격 책정입니다. 서비스 계층을 선택하면 프로비전된 단위에 따라 매시간 요금이 청구됩니다.

• 서버리스(미리 보기): 시간당 컴퓨팅 단위(CU/hr) 및 인덱싱된 스토리지의 경우 GB/월 단위로 측정된 소비 기반 가격 책정입니다.

가격 책정 모델 및 서비스 계층 차이에 대한 자세한 내용은 가격 책정 모델 및 서비스 계층 선택을 참조하세요.

서버리스 모델에서 비용을 결정하는 방법

전용 및 서버리스 가격 책정 모델은 검색 서비스 내의 작업을 다르게 고려합니다. 전용 서비스는 이미 구매한 프로비전된 용량에서 쿼리, 인덱싱 및 결과 처리를 실행합니다. 서버리스 서비스는 이러한 작업에서 사용하는 컴퓨팅, 메모리 및 디스크 I/O를 측정하고 해당 사용량을 CPU(컴퓨팅 단위)로 변환합니다. 따라서 성능 최적화는 서버리스 비용에 직접적인 영향을 줍니다.

서버리스 비용은 워크로드 실행과 관련이 있습니다.

• 쿼리 및 인덱싱은 시간당 컴퓨팅 단위(CU/h)로 측정된 컴퓨팅을 사용합니다.
• 활성 인덱스는 리소스 사용량 및 활성 상태를 유지하는 기간에 따라 컴퓨팅을 사용합니다.
• 인덱스는 비활성 상태가 되기 전에 마지막 쿼리 또는 인덱싱 요청 후 10분 동안 활성 상태로 유지됩니다.
• 비활성 인덱스에는 최소 또는 예약된 컴퓨팅 요금이 없습니다. 비활성 인덱스에 대한 컴퓨팅 사용량은 0으로 확장됩니다. 인덱스가 비활성 상태인 경우 최소 컴퓨팅 요금은 없습니다.
• 스토리지는 디스크에 저장된 인덱스 크기를 기준으로 별도로 청구되며, 인덱스 사용 여부와 관계없이 계속 청구됩니다.
• 에이전트 검색은 검색 서비스 내에서 수행되는 검색 쿼리 및 오케스트레이션에 컴퓨팅을 사용합니다.

스토리지 요금은 인덱스 삭제 경우에만 중지됩니다.

현재 청구 주기의 비용 분석 및 사용률을 보려면 Azure 포털에서 크기 조정 + 비용 탭을 봅니다.

인덱스 크기가 컴퓨팅 사용량에 미치는 영향

인덱스가 활성화된 동안 Azure AI 검색 두 개의 유한 리소스를 평가하여 컴퓨팅 사용량을 확인합니다.

• 총 인덱스 크기: 텍스트, 메타데이터 및 벡터를 포함하여 인덱스가 디스크에서 차지하는 총 공간입니다.
• 벡터 인덱스 크기: 벡터 인덱스가 사용하는 메모리입니다. 메모리는 디스크보다 리소스를 많이 사용하므로 CPU로 변환할 때 벡터 인덱스 크기는 더 높은 가중치를 가집니다.

Azure AI 검색 두 개의 결과 CU 양을 함께 추가하지 않습니다. 컴퓨팅 사용량은 어느 양보다 높은지 기준으로 합니다. 예를 들어 벡터 인덱스 크기는 디스크의 총 인덱스 크기가 상대적으로 작은 경우에도 컴퓨팅 사용량을 결정할 수 있습니다.

활성 인덱스 컴퓨팅 사용량을 줄이려면 더 높은 CU 양을 생성하는 리소스를 식별합니다. 그런 다음 총 인덱스 크기, 벡터 인덱스 크기 또는 둘 다를 줄입니다. 인덱싱된 스토리지는 GB/월 요금에 따라 별도로 유지됩니다.

서버리스 가격 책정 모델은 프로비전된 용량이 저용되는 가변, 간헐적 또는 예측할 수 없는 트래픽이 있는 워크로드에 가장 비용 효율적입니다.

CPU(컴퓨팅 단위) 이해

CU(컴퓨팅 단위)는 서버리스 모델에서 검색 및 인덱싱 작업을 수행하는 데 필요한 측정된 시스템 리소스를 나타냅니다. CU 비용은 주로 CPU, 메모리 및 IO 사용률에 따라 구동되며, 인덱스 크기 및 문서 페이로드 크기에 따라 보조적으로 사용량이 시간당 컴퓨팅 단위(CU/h)로 청구됩니다.

다음을 사용하여 비용 규모를 계산합니다.

• 쿼리 복잡성
• 인덱스 크기(GB) 및 구조체
• 문서 페이로드 크기(KB)
• 필드 수 및 검색된 결과

작업별로 비용 프로필이 다릅니다.

• 조회: 저렴한 비용. ID로 단일 문서를 검색하는 것이 가장 효율적인 작업입니다.
• 키워드 검색: 저렴한 비용. 텍스트 검색은 속도 및 낮은 컴퓨팅 사용량에 최적화된 반전된 인덱스를 사용합니다.
• 벡터 검색: 높은 비용. 벡터 쿼리는 높은 차원 포함에서 유사성 계산이 필요하기 때문에 계산 비용이 많이 듭니다. 키워드 검색에 비해 훨씬 더 많은 컴퓨팅을 사용합니다.
• 하이브리드 검색: 각 쿼리마다 두 파이프라인이 모두 실행되므로 키워드 검색과 벡터 검색의 비용이 모두 들며, 여기에 결과를 병합하기 위한 RRF(상호 순위 융합)의 소규모 추가 오버헤드가 더해집니다.

컴퓨팅 사용량 모니터링

컴퓨팅 사용량을 모니터링하면 비용이 많이 드는 작업을 식별하고 쿼리 패턴을 최적화하며 비용을 예측할 수 있습니다. 모든 요청의 CU(컴퓨팅 단위) 비용은 HTTP 응답 헤더에 x-ms-azs-compute-units-consumed 부동 소수점 숫자로 반환됩니다. 이 헤더를 사용하여 비용이 많이 드는 작업을 식별하고 쿼리 패턴을 최적화합니다. Azure Monitor HTTP 응답 헤더 및 작업 이벤트를 검사하여 모든 요청의 CU 비용을 추적할 수 있습니다. 사용 가능한 모니터링 데이터 유형 및 해당 데이터를 분석하는 방법에 대한 자세한 지침은 Azure AI 검색 모니터링을 참조하세요.

• 머리글:x-ms-azs-compute-units-consumed: <value>
• 값: 사용된 CPU를 나타내는 부동 소수점 숫자입니다.

Example:

Status: 200 OK
Content-Type: application/json
x-ms-azs-compute-units-consumed: 12.45

이 예제에서 요청은 12.45 컴퓨팅 단위를 사용했습니다. 이 값을 사용하여 고비용 작업을 식별하고 다양한 쿼리 패턴의 상대적 비용을 비교할 수 있습니다.

서버리스 검색 서비스에 대한 기록 컴퓨팅 사용량을 검토하려면 Azure 포털에서 Azure Monitor 메트릭을 사용합니다.

1. 검색 서비스로 이동합니다.
2. 메트릭을 선택합니다.
3. +메트릭 추가를 선택합니다.
4. 메트릭 목록에서 컴퓨팅 단위 사용량을 선택합니다.
5. 차트를 사용하여 사용량 추세를 분석하고 컴퓨팅 사용량 증가 기간을 식별합니다.

집계 사용량을 모니터링하면 전체 서비스 비용을 이해하고 가장 많은 컴퓨팅 리소스를 사용하는 워크로드를 식별할 수 있습니다. 사용 가능한 모니터링 메트릭에 대한 설명은 모니터링 데이터 참조를 참조하세요. Azure Monitor 로그를 사용하여 시간이 지남에 따라 집계 CU 사용량을 추적하고 쿼리 볼륨 및 워크로드 변경 내용과 상호 연결할 수 있습니다.

컴퓨팅 사용에 대한 경고 구성

컴퓨팅 사용량이 Azure 포털에서 지정된 임계값에 도달하면 알림을 받을 경고 규칙을 만들 수 있습니다.

1. 검색 서비스의 경고 로 이동합니다.
2. + 경고 규칙 만들기를 선택합니다.
3. 조건 아래에서컴퓨팅 단위 사용을 신호로 선택합니다.
4. 경고 논리를 정의합니다. 예를 들어 총 사용량이 지정된 값보다 큰 경우 트리거합니다.
5. 이메일, SMS 또는 웹후크 알림과 같은 작업을 구성합니다.
6. 나머지 단계를 완료하고 검토 + 만들기를 선택합니다.

경고는 예기치 않은 사용량 급증에 사전에 대응하고 비용을 관리하는 데 도움이 됩니다.

서버리스 비용 예측

Azure 가격 계산기 및 SU(검색 단위) 기반 용량 계획 지침은 서버리스 가격 책정 모델을 사용하는 서비스에는 적용되지 않습니다.

서버리스 비용을 예측하려면 다음을 수행합니다.

1. 대표적인 샘플 데이터를 인덱싱합니다.
2. 일반적인 인덱싱 및 쿼리 워크로드를 실행합니다.
3. 각 작업에 대해 반환된 x-ms-azs-compute-units-consumed 값을 기록합니다.
4. Azure Monitor 메트릭을 사용하여 시간에 따른 집계 사용량을 측정합니다.
5. 예상 프로덕션 트래픽에 따라 비용을 추정합니다.

Azure 포털의 크기 조정 + 비용 탭을 사용하여 현재 사용량을 확인하고 비용을 예측합니다.

동일한 데이터에 대해 실행되는 동일한 요청은 일반적으로 비슷한 컴퓨팅 소비를 생성하므로 대표 워크로드는 비용 예측에 대한 신뢰할 수 있는 기반을 제공할 수 있습니다.

서버리스 사용량은 지속적으로 측정되고 청구를 위해 집계됩니다. 컴퓨팅 사용량은 1분마다 추적되며 컴퓨팅 리소스를 사용하는 경우에만 내보내집니다.

비용을 추정할 때는 요청 요금 값을 사용하여 개별 작업의 비용을 파악하고, Azure Monitor 메트릭을 사용하여 전반적인 서비스 사용 패턴을 이해합니다.

두 데이터 원본을 함께 사용하여 비용을 이해합니다. 요청당 요금 데이터는 개별 작업을 평가하는 데 도움이 되며, Azure Monitor 메트릭은 시간에 따른 집계 서비스 소비를 이해하는 데 도움이 됩니다. 전체 비용 그림의 경우 컴퓨팅 단위와 별도로 청구되는 기능도 고려합니다.

청구는 개별 요청이 아닌 집계 컴퓨팅 사용량을 기반으로 합니다. 사용량은 1분 간격으로 측정되고 분당 가장 가까운 0.25 CU로 반올림됩니다. 이러한 1분 사용 간격은 청구 가능한 CU/시간 금액을 결정하기 위해 1시간 동안 누적됩니다. 내부적으로 사용량은 mCU(밀리 컴퓨팅 단위)에서 CU(컴퓨팅 단위)로 집계되며 청구에 대해 보고된 시간당 사용량으로 변환됩니다.

여러 작업에서 다양한 양의 컴퓨팅을 사용합니다. 일반적으로 다음과 같이 작동합니다.

• 키워드 검색은 일반적으로 최소 컴퓨팅 리소스를 사용합니다.
• 벡터 검색은 일반적으로 키워드 검색보다 더 많은 컴퓨팅 리소스를 사용합니다.
• 하이브리드 검색은 키워드와 벡터 검색 실행을 결합하므로 일반적으로 두 기술만 사용하는 것보다 더 많은 컴퓨팅 리소스를 사용합니다.

실제 컴퓨팅 사용량은 쿼리 복잡성, 인덱스 크기, 데이터 볼륨, 벡터 구성 및 반환된 결과 수와 같은 요인에 따라 달라집니다. 요청 요금 및 집계 사용량 메트릭을 모니터링하면 최적화 기회를 식별하고 프로덕션 비용을 더 잘 예측할 수 있습니다.

최적화를 통해 컴퓨팅 비용 절감

효율적인 쿼리 및 인덱스 디자인은 컴퓨팅 소비를 줄이고 비용을 절감합니다.

스키마 최적화

인덱스 스키마는 기준 컴퓨팅 및 스토리지 비용을 결정합니다.

• 필드 특성 제한: 필요한 경우에만 특성(검색 가능, 필터링 가능, 패싯 가능, 정렬 가능)을 사용하도록 설정합니다. 각 특성은 인덱스 크기 및 인덱싱 비용을 증가합니다.
• 복합 형식 평면화: 중첩된 JSON 구조를 가능한 경우 단순 필드 또는 컬렉션에 매핑합니다.
• 필터 전용 또는 정렬 전용 필드에 대해 retrievable=false 설정: 필드를 필터링 또는 정렬에 사용하지만 결과에 반환할 필요가 없는 경우 인덱싱된 상태로 유지하고 디스크 스토리지 및 GB/월당 스토리지 비용을 줄이도록 설정합니다 retrievable=false .
• 가능한 경우 검색 가능한 전용 필드를 사용합니다. 예를 들어 표시에만 사용되는 필드(예: 이미지 URL)를 검색할 수 없습니다.
• 벡터 차원 감소: 더 높은 차원 벡터는 스토리지 및 쿼리 비용을 증가시킵니다. 적절한 경우 더 작은 포함 모델 또는 양자화를 사용합니다.
• 인덱싱하기 전에 문서 페이로드 크기를 최소화합니다. 더 큰 문서는 인덱싱에 더 많은 비용이 듭니다. 인덱스로 문서를 보내기 전에 불필요한 필드를 제거하고 긴 텍스트를 잘라내고 HTML을 제거합니다.

인덱싱 요청 최적화

인덱스에 데이터를 보내는 방법은 비용과 처리량 모두에 영향을 줍니다.

• 가능하면 더 큰 배치를 사용하세요: 배치 인덱싱은 더 많은 문서에 걸쳐 네트워크 및 처리 비용을 분산함으로써 요청당 오버헤드를 줄입니다. 일반적으로 최대 1,000개 또는 최대 16MB의 일괄 처리는 많은 작은 요청보다 CU 효율적입니다. 그러나 최적의 일괄 처리 크기는 워크로드에 따라 달라집니다. 처리량, 대기 시간 및 안정성의 균형을 맞추기 위해 테스트합니다.

• 새 데이터 또는 변경된 데이터만 인덱싱: 가능한 경우 전체 다시 인덱싱을 방지합니다. 추가 및 업데이트만 보내면 처리되는 문서 수가 줄어들어 컴퓨팅 비용이 절감되고 수집 속도가 향상됩니다.

• 필요하지 않은 경우 이미지 추출 건너뛰기: 이미지 추출은 추가 처리 작업을 추가하고 별도의 비용 드라이버가 될 수 있습니다. 이미지 콘텐츠가 실제로 필요한 문서나 워크플로에만 활성화하세요.

• 인덱스 크기 증가를 고려합니다. 가능한 경우 더 작은 인덱스를 만듭니다. 인덱스가 증가함에 따라 더 많은 데이터를 저장 및 유지 관리해야 하고 작업에 더 많은 컴퓨팅이 필요하기 때문에 인덱싱 비용이 증가합니다. 매우 큰 데이터 세트의 경우 성능 및 비용을 관리하는 데 도움이 되도록 여러 인덱스에 걸쳐 데이터를 분할하는 것이 좋습니다. 인덱스 크기에 따라 비용이 증가하지만 증가는 하위 선형입니다. 더 큰 인덱스는 작업당 더 많은 비용이 들지만 비례적으로 더 많이 비용이 들지는 않습니다.

자세한 지침은 Azure AI 검색의 성능을 향상시키기 위한 팁을 참조하세요.

인덱서 작업 최적화

서버리스 인덱서 컴퓨팅 사용량은 각 인덱서 실행 중에 수행되는 작업에 따라 달라집니다. 행 지향 원본의 경우 처리된 문서 수를 워크로드 볼륨의 지표로 사용합니다. Azure Blob Storage 및 Azure Data Lake Storage Gen2 같은 파일 기반 원본의 경우 처리된 원본 데이터의 양을 모니터링합니다. 실제 컴퓨팅 사용량은 또한 문서 페이로드, 인덱스 구조, 보강 및 실행 중에 수행된 기타 처리에 따라 달라집니다.

인덱서 컴퓨팅 사용량을 줄이려면 다음을 수행합니다.

• 변경 내용 검색 및 증분 인덱싱 사용: 전체 데이터 원본을 반복적으로 인덱싱하는 대신 새 데이터 또는 변경된 데이터만 처리합니다.

• 적절한 크기의 인덱서 일정: 데이터 새로 고침 요구 사항을 충족하는 일정을 선택합니다. 컴퓨팅 단위 원격 분석을 사용하여 일정 빈도의 효과를 평가합니다.

• 불필요한 문서 콘텐츠 줄이기: 인덱싱할 필요가 없는 콘텐츠를 제거하고 필요하지 않은 파일 또는 파일 형식을 제외합니다.

• 보강 기술을 신중하게 적용: 보강이 필요한 필드와 문서에만 기술을 실행하고 후속 처리에서 사용되지 않는 출력을 생성하지 마세요. 청구 가능한 기술에는 별도의 트랜잭션 요금이 발생할 수 있습니다.

• 실패한 실행 및 재실행 모니터링: 인덱서는 실패하기 전에 완료한 작업에도 컴퓨팅 리소스를 소모할 수 있습니다. 실행 기록 및 컴퓨팅 단위 사용량을 검토하여 되풀이 실패 및 다시 시도 패턴을 식별합니다.

쿼리 최적화

쿼리 디자인은 가변 비용의 기본 동인입니다.

• 반환된 필드를 제한하는 데 사용합니다$select. 이렇게 하면 serialization에 필요한 페이로드 크기 및 컴퓨팅이 줄어듭니다.

  GET /docs?search=test&$select=id,title,url
  

• 텍스트 검색 위치를 제한하는 데 사용합니다searchFields. 쿼리 시간 일치를 시나리오에 중요한 필드로 제한합니다. 검색 가능한 필드가 추가로 추가되어 쿼리 작업이 늘어나고 CU/h가 증가할 수 있습니다.

• 정확히 일치하거나 간단한 키워드 쿼리를 선호합니다. 유사 항목, 와일드카드, 정규식 및 접두사 스타일 쿼리는 광범위한 인덱스 검사를 강제로 적용하고 훨씬 더 많은 CU/h를 사용할 수 있습니다. 부분 일치 동작이 필요한 경우에만 사용하고 가능한 경우 정확한 일치 또는 간단한 키워드 쿼리를 선택합니다.

• 가능하면 검색 대신 조회를 사용합니다. ID로 문서를 검색하는 것이 검색 쿼리를 실행하는 것보다 더 효율적입니다. 문서 ID를 알고 있는 경우 검색 쿼리 대신 조회를 사용합니다. 조회는 키로 문서를 직접 검색하는 반면 검색 쿼리는 전체 쿼리 파이프라인(구문 분석, 인덱스 통과, 점수 매기기 및 순위)을 호출하므로 컴퓨팅 비용이 증가하므로 더 효율적입니다.

• 심층 페이징 방지($skip): 엔진이 요청된 페이지 앞의 결과를 처리, 점수 매기기 및 순위를 지정해야 하므로 큰 $skip 값은 컴퓨팅을 증가합니다. 예를 들어 $skip=5000 엔진이 반환되지 않는 5,000개 이상의 결과를 처리해야 합니다. 이 선택은 추가 CPU(컴퓨팅 단위)를 사용하고 비용을 증가시킬 수 있습니다. 대신 필터를 사용하여 결과의 set 범위를 좁히고 $top 반환된 결과 수를 제한합니다. 애플리케이션 또는 UI에 맞는 적절한 크기로 $top를 설정하세요. 일치하는 문서의 점수는 변경되지 않지만 $top 값이 작을수록 수집, 정렬 및 serialize해야 하는 결과 수가 줄어듭니다. 애플리케이션에 필요한 만큼의 결과만 요청하고 엔진에서 많은 수의 사용되지 않는 결과를 처리해야 하는 페이징 패턴을 방지합니다.

• 패싯 수 및 패싯 범위 최소화: UI에 표시되는 패싯만 요청하고 각 패싯 count 값을 최대한 낮게 유지합니다. 패싯에는 쿼리별 집계가 필요하며, 개수가 많을수록 컴퓨팅 비용이 증가합니다.

• 필터링에는 search.in 사용: ID 또는 값 목록으로 필터링할 때는 여러 개의 search.in 조건(예: or) 대신 id eq '1' or id eq '2' 함수를 사용합니다. 이 방법은 더 효율적이며 컴퓨팅 오버헤드를 줄입니다. 또한 인덱스 크기와 쿼리 비용이 증가하므로 필요한 경우가 아니면 높은 카디널리티 필드(고유 ID 또는 자유 텍스트 설명과 같은 고유 값이 많은 필드)를 필터링 가능하거나 패싯 가능으로 표시하지 않아야 합니다.

관리 요청을 최적화하세요

쿼리 및 인덱싱 작업 외에도 Azure AI 검색 개체 수준 및 서비스 수준 관리 작업(예: 인덱스 스키마 또는 서비스 통계 검색)을 포함합니다. 이러한 요청에는 요청당 정액 비용이 부과됩니다. 각 요청은 저렴하지만 반복되거나 불필요한 호출은 시간이 지남에 따라 누적되어 전반적인 컴퓨팅 사용량을 증가시킬 수 있습니다.

• 과도한 관리 요청을 방지합니다. 반복적으로 검색하는 대신 클라이언트 쪽에서 인덱스 스키마와 같은 메타데이터를 캐시합니다. 예를 들어 모든 쓰기 작업 전에 인덱스 스키마를 가져오면 불필요한 비용이 발생합니다. 서버리스 모델에서 이 패턴은 컴퓨팅 요금을 직접 증가시키는 반면 Dedicated 서비스에서는 시간당 고정 청구로 영향을 숨기는 경우가 많습니다.

벡터 비용 최적화

벡터 워크로드는 컴퓨팅 단위(쿼리 및 인덱싱) 및 스토리지(디스크의 벡터 크기)에 모두 영향을 주므로 서버리스 가격 책정 모델을 검색할 때 가장 비용이 많이 드는 구성 요소입니다. 비용을 줄이려면 벡터를 저장하는 방법과 쿼리하는 방법을 모두 최적화합니다.

벡터 스토리지 및 스키마 최적화

벡터 필드는 인덱스 크기와 인덱싱 비용을 크게 증가시킬 수 있습니다. 다음 기술을 사용하여 스토리지 오버헤드를 줄입니다.

• 압축을 사용하여 벡터 크기를 줄입니다. 관련성 영향을 최소화하면서 스토리지 공간을 줄이기 위해 양자화를 적용합니다. 예를 들어 스칼라 정량화는 검색 품질에 미치는 영향을 최소화하면서 벡터 스토리지를 최대 4× 줄일 수 있습니다.

• 필요하지 않은 경우 벡터에 대한 스토리지 사용 안 함: 검색이 아닌 검색에 벡터만 필요한 경우 벡터 필드에 stored=false를 설정합니다. 이렇게 하면 원래 벡터를 인덱스에 저장하지 않고 쿼리 동작에 영향을 주지 않고 스토리지 비용을 줄일 수 있습니다.

• 가능한 경우 더 작은 포함 차원을 사용합니다. 더 높은 차원 벡터는 스토리지 및 쿼리 비용을 모두 증가합니다. 중요하지 않은 워크로드의 경우 더 작은 포함 모델(예: 1536 대신 384 또는 768차원)을 사용하여 비용을 절감합니다.

벡터 쿼리 실행 최적화

벡터 쿼리는 높은 차원 데이터 구조에 비해 유사성 계산이 필요하기 때문에 계산 집약적입니다.

• 하이브리드 검색을 선택적으로 사용: 하이브리드 쿼리는 키워드와 벡터 검색을 모두 실행합니다. 관련성에 필요한 경우에만 사용합니다.

• 하이브리드 쿼리의 maxTextRecallSize 낮추기: 이 hybridSearch.maxTextRecallSize 설정은 Reciprocal Rank Fusion에 전달되는 BM25 순위 결과 수를 제어합니다. 기본값은 1,000(범위 1~10,000)입니다. 컴퓨팅 사용량은 이 값으로 대략 선형적으로 확장되므로 이를 낮추는 것은 하이브리드 워크로드에 가장 직접적인 비용 레버 중 하나입니다.

• 500 정도의 값은 관련성 저하를 거의 일으키지 않으면서도 계산량을 크게 줄이는 경우가 많습니다.

• 더 낮추면 정확한 용어, ID, 약어처럼 벡터 검색이 놓치는 키워드 일치 항목이 줄어들 수 있습니다.

• 각 벡터 쿼리에서 k를 사용하여 벡터 후보를 개별적으로 제어합니다.

• 값을 정산하기 전에 대표 쿼리를 테스트하고 관련성, 대기 시간 및 x-ms-azs-compute-units-consumed 헤더를 비교합니다.

• 벡터 쿼리 전에 필터 적용: 벡터 검색 전에 후보 집합의 범위를 좁혀 처리되는 데이터의 양을 줄입니다. 벡터 쿼리에서 필터링이 작동하는 방식을 참조하세요.

사용량을 최소화하여 비용 절감

서버리스 모델은 사용된 리소스에 대해서만 요금이 청구됩니다. 요청이 없으면 그에 따라 컴퓨팅 사용량이 감소합니다.

사용 비용을 최소화하려면 다음을 수행합니다.

• 필요한 경우에만 쿼리를 실행합니다.
• 중복 또는 지나치게 빈번한 요청을 방지합니다.
• 사용량을 모니터링하고 수요에 따라 워크로드를 조정합니다.

스토리지 비용 최적화

스토리지는 디스크 인덱스 크기에 따라 GB/월당 요금이 청구되며 원시 데이터 크기를 초과할 수 있습니다. 스토리지 비용을 줄이려면 다음을 수행합니다.

• 사용되지 않는 인덱스를 제거합니다.
• 저장된 필드를 최소화합니다.
• 스토리지 오버헤드를 염두에 두고 스키마를 디자인합니다.
• 저장소 크기를 크게 늘릴 수 있으므로 선택적으로 제안기를 사용합니다.

벡터별 기술(압축, 정리 및 스토리지 설정)은 벡터 스토리지 및 처리에 대한 최적화를 참조하세요.

스토리지와 쿼리 성능 간의 절충 관계에 대한 자세한 지침은 Azure AI 검색에서 성능을 향상시키기 위한 팁을 참고하세요.