Azure AI Search 개요 및 구성

1 Azure AI Search 개요

1.1 정의 및 용도

• Azure AI Search는 완전 관리형 클라우드 호스팅 서비스이다
• 엔터프라이즈 및 웹 콘텐츠를 AI에 연결하여 에이전트와 LLM이 신뢰할 수 있는 답변을 생성할 수 있도록 한다
• Classic Search와 RAG(Retrieval-Augmented Generation) 방식의 Agentic Retrieval을 모두 지원한다

1.2 주요 사용 사례

• 에이전트 및 챗봇 Grounding: 독점적인 엔터프라이즈 또는 웹 데이터를 기반으로 정확하고 맥락 인식 응답 생성
• 다양한 데이터 소스 접근: Azure Blob Storage, Azure Cosmos DB, Microsoft SharePoint, Microsoft OneLake 등
• 콘텐츠 강화: 인덱싱 또는 쿼리 시점에 청킹, 임베딩, LLM 지원 변환을 통한 구조화
• Hybrid Search: Full-text Search와 Vector Search 결합으로 정밀도와 재현율 균형 확보
• 멀티모달 검색: 텍스트와 이미지를 포함한 콘텐츠를 단일 파이프라인에서 쿼리

1.3 핵심 역량

검색 서비스 생성 시 다음 기능을 사용할 수 있다:

• 두 가지 검색 엔진
  • Classic Search: 단일 요청 처리
  • Agentic Retrieval: 병렬, 반복, LLM 지원 검색
• 다양한 쿼리 유형
  • Full-text, Vector, Hybrid, Multimodal 쿼리 지원
  • 로컬(인덱싱된) 및 원격 콘텐츠 모두 검색
• AI Enrichment
  • 청킹, 벡터화 등을 통해 원시 콘텐츠를 검색 가능하게 만듦
• 관련성 튜닝: 의도 매칭 및 결과 품질 향상
• Azure 통합
  • 지원되는 데이터 플랫폼, Azure OpenAI, Microsoft Foundry와 통합

2 검색 아키텍처 비교

2.1 Classic Search

2.1.1 개념

• 인덱스 우선 검색 모델이다
• 예측 가능하고 낮은 지연 시간의 쿼리를 제공한다
• 각 쿼리는 단일 사전 정의된 검색 인덱스를 대상으로 하며 한 번의 요청-응답 사이클로 순위가 매겨진 문서를 반환한다
• 검색 중 LLM 지원 계획, 반복, 합성이 발생하지 않는다

2.1.2 아키텍처

데이터 소스 → 인덱싱 → 검색 인덱스 → 쿼리 엔진 → 클라이언트 앱

• 검색 서비스 위치: 처리되지 않은 콘텐츠를 포함하는 데이터 저장소와 클라이언트 앱 사이에 위치
• 클라이언트 앱 역할: 검색 서비스에 쿼리 요청을 보내고 응답을 처리

2.1.3 워크로드

1. 인덱싱(Indexing)
   • 콘텐츠를 인덱스에 로드하여 검색 가능하게 만듦
   • 인바운드 텍스트는 토큰화되어 역 인덱스에 저장됨
   • 인바운드 벡터는 벡터 인덱스에 저장됨
   • JSON 문서만 인덱싱 가능
   • Push 방식: JSON 문서 직접 업로드
   • Pull 방식: 인덱서 또는 Logic App 워크플로를 통해 데이터 검색 및 JSON으로 직렬화
   • AI Enrichment를 통해 텍스트 청킹, 벡터 생성, 기타 변환 적용 가능
2. 쿼리(Querying)
   • 인덱스에서 문서 검색
   • Full-text, Vector, Hybrid, Multimodal 쿼리 지원

2.2 Agentic Retrieval

2.2.1 개념

• 멀티 쿼리 파이프라인이다
• 복잡한 에이전트 간 워크플로우를 위해 설계되었다
• 각 쿼리는 완전한 지식 도메인을 나타내는 Knowledge Base를 대상으로 한다
• 에이전트는 Knowledge Base를 참조하여 무엇을 Grounding할지 결정하고, Knowledge Base는 Grounding 수행 방법을 처리한다

2.2.2 Knowledge Base 구성

• 하나 이상의 Knowledge Source로 구성된다
• 선택적 LLM을 통한 쿼리 계획 및 답변 합성
• 검색 동작을 제어하는 매개변수

2.2.3 쿼리 프로세스

각 쿼리는 다음 단계를 거친다:

1. 계획(Planning): LLM이 쿼리 계획 수립
2. 분해(Decomposition): 집중된 하위 쿼리로 분해
3. 병렬 검색(Parallel Retrieval): Knowledge Source에서 병렬 검색
4. 의미론적 재순위(Semantic Reranking): 결과의 의미론적 관련성 기반 재정렬
5. 결과 병합(Results Merging): 세 가지 형태의 응답 생성 (에이전트 소비에 최적화)

2.2.4 아키텍처 특징

• Classic Search 아키텍처 위에 컨텍스트 레이어(Knowledge Base)를 추가한다
• 멀티 소스 검색을 오케스트레이션한다
• Knowledge Source 유형
  • Indexed Source: Classic Search와 동일한 인덱싱 및 쿼리 엔진 사용
  • Remote Source: 인덱싱을 건너뛰고 실시간 쿼리

2.3 Classic Search vs Agentic Retrieval 비교

구분	Classic Search	Agentic Retrieval
검색 대상	스키마로 정의된 단일 인덱스	하나 이상의 Knowledge Source를 가리키는 Knowledge Base
쿼리 계획	계획 없음, 단순 요청	LLM 지원 또는 사용자 제공 계획
쿼리 요청	인덱스에서 문서 검색	Knowledge Source에서 검색
응답 형태	스키마 기반 평면화된 검색 결과	LLM이 생성한 답변 또는 원시 소스 데이터, 활동 로그, 참조
지역 제약	없음	있음 (특정 지역만 지원)
상태	일반 공급(GA)	공개 프리뷰

2.4 공통 지원 기능

두 방식 모두 다음을 지원한다:

• Full-text Search
• Vector Search
• Hybrid Search
• Multimodal Search

3 주요 기능

3.1 인덱싱 및 데이터 추출

• 데이터 소스: JSON 형식의 모든 소스에서 텍스트 수용 가능
• 인덱서(Indexers): 지원되는 데이터 소스에서 자동 데이터 가져오기
  • JSON 직렬화 자동 처리
  • 변경 및 삭제 감지 지원
  • 지원 데이터 소스: Microsoft OneLake, Azure SQL Database, Azure Cosmos DB, Azure Blob Storage
  • Logic Apps 커넥터(프리뷰): 다른 클라우드 플랫폼 데이터 포함 더 넓은 범위의 데이터 소스 접근
• 계층적 및 중첩 데이터 구조: Complex Types 및 Collections를 통해 모든 JSON 구조 모델링 가능
• 언어 분석(Linguistic Analysis)
  • 기본: Standard Lucene Analyzer
  • 언어별 분석기: 동사 시제, 성별, 불규칙 복수형, 단어 분해 등 언어별 언어학 지능형 처리
  • 사용자 정의 분석기: 음성 매칭, 정규 표현식 등 복잡한 쿼리 형식

3.2 AI 통합

3.2.1 인덱싱 중 AI 처리

• GenAI Prompt Skill (프리뷰)
  • 인덱싱 중 대형 언어 모델 호출
  • 프롬프트로 작업 결정 (이미지 설명, 콘텐츠 요약/조작 등)
  • 출력은 검색 가능한 인덱스의 새 필드로 추가됨

3.2.2 쿼리 시 AI 처리

• Agentic Retrieval (프리뷰)
  • 쿼리 계획을 위한 대형 언어 모델 사용
  • 복잡한 쿼리를 분해 및 패러프레이징하여 인덱스에 대한 쿼리 커버리지 향상
  • 에이전트 간 워크플로우를 위한 응답 설계
  • 검색 결과를 단일 대형 문자열로 전달하여 에이전트의 독점 콘텐츠 소비 간소화
  • 응답에 인용 및 쿼리 실행 정보 포함

3.2.3 AI Enrichment

• AI 처리: 인덱서 파이프라인에 임베디드 이미지 및 자연어 처리
• Skillset: 기술을 추가 및 결합하여 AI 처리 달성
  • Microsoft 내장 기술: 텍스트 번역, OCR 등
  • 사용자 정의 기술: 직접 제공 가능
• 통합 데이터 청킹 및 벡터화
  • Text Split Skill을 통한 데이터 청킹
  • 벡터화를 통해 더 큰 구절을 작은 청크로 분할하고 벡터화
  • 벡터는 Vector 및 Hybrid Search를 위한 인덱스의 전용 필드로 라우팅됨
• Knowledge Store: 비검색 시나리오(지식 마이닝, 데이터 과학)를 위한 AI 강화 콘텐츠의 영구 저장소
• Enrichment Caching (프리뷰): Skillset 실행 중 재사용 가능한 캐시된 강화 (OCR 및 이미지 분석 등 비용이 많이 드는 처리에 유용)

3.3 Vector 및 Hybrid Retrieval

• Vector 인덱싱: 검색 인덱스 내 Vector Field 추가로 Vector Search 시나리오 지원
• Vector 쿼리: 단일 및 다중 Vector 쿼리 작성
• Vector 검색 알고리즘
  • HNSW (Hierarchical Navigable Small World)
  • 완전 탐색 KNN (K-Nearest Neighbors)
• Vector 필터: 쿼리 실행 전후에 필터 적용으로 정보 검색 정밀도 향상
• Hybrid 정보 검색
  • 단일 Hybrid 쿼리 요청에서 개념 및 키워드 검색
  • Vector 및 텍스트 검색 통합
  • 선택적 Semantic Ranking 및 관련성 튜닝으로 최상의 결과 제공
• 통합 데이터 청킹 및 벡터화
  • Azure OpenAI Embedding, Azure Vision Multimodal, AML을 통한 벡터화
  • Microsoft Foundry 모델 카탈로그의 엔드포인트 연결
  • 소스 파일에서 쿼리까지 엔드 투 엔드 인덱싱 파이프라인 제공
• 통합 Vector 압축 및 양자화
  • 내장 Scalar 및 Binary Quantization으로 메모리 및 디스크의 Vector 인덱스 크기 축소
  • 불필요한 벡터 저장 생략 또는 좁은 데이터 유형 할당으로 스토리지 요구 사항 감소

3.4 Full-text 및 기타 쿼리 형식

• 자유 형식 텍스트 검색
  • Simple Query Syntax: 논리 연산자, 구문 검색, 접미사 연산자, 우선순위 연산자
  • Full Lucene Query Syntax: Simple Syntax의 모든 작업 + Fuzzy Search, Proximity Search, Term Boosting, 정규 표현식
• 관련성(Relevance)
  • Simple Scoring: 문서 값의 함수로 관련성 모델링
  • Scoring Profiles: 사용자 지정 점수 매기기 (예: 최신 제품, 할인 제품 우선)
  • Semantic Ranker: 쿼리에 대한 의미론적 관련성 기반 결과 재순위 (프리미엄 기능)
• 지리공간 검색(Geospatial Search): 지리적 좌표 기반 필터링 및 매칭
• 필터 및 패싯(Filters and Facets)
  • 패싯 탐색: 단일 쿼리 매개변수로 활성화
  • 사용자 또는 개발자 지정 기준으로 필터링
  • OData 구문 사용
• 사용자 경험 기능
  • Autocomplete: 검색 바에서 자동 완성 쿼리
  • Search Suggestions: 부분 텍스트 입력 기반 실제 문서 제안
  • Synonyms: 쿼리 범위를 암시적으로 확장하는 동등 용어 연결
  • Hit Highlighting: 검색 결과의 일치 키워드에 텍스트 서식 적용
  • Sorting: 인덱스 스키마를 통한 다중 필드 정렬, 쿼리 시 단일 검색 매개변수로 전환
  • Paging and Throttling: 검색 결과에 대한 세밀한 제어

3.5 보안 기능

• 네트워크 보안
  • IP 규칙: 인바운드 방화벽 지원으로 검색 서비스가 요청을 수락하는 IP 범위 설정
  • Private Endpoint: Azure Private Link를 사용한 VNet을 통한 모든 요청 강제
  • Network Security Perimeter: 다른 Azure 리소스와 함께 Azure AI Search를 네트워크 보안 경계에 가입하여 네트워크 액세스를 전체적으로 관리
• 데이터 암호화
  • Microsoft 관리 암호화: 내부 스토리지 레이어에 내장되어 있으며 취소 불가
  • 고객 관리 암호화 키(CMK): Azure Key Vault에서 생성 및 관리하는 키로 인덱스 및 동의어 맵에 대한 보완 암호화
  • 2020년 8월 1일 이후 생성된 서비스: CMK 암호화가 임시 디스크로 확장되어 인덱싱된 콘텐츠의 완전한 이중 암호화 제공
• 인바운드 액세스
  • Role-based Access Control (RBAC): Microsoft Entra ID의 사용자 및 그룹에 역할 할당하여 검색 콘텐츠 및 작업에 대한 제어된 액세스
  • Key-based Authentication: 역할 할당을 원하지 않는 경우 사용
  • Document-level Access Control (프리뷰): 사용자가 볼 수 없는 검색 결과 필터링. 여러 데이터 소스에 대해 액세스 제어 모델이 있는 경우 사용자 권한 메타데이터를 상속하도록 인덱스 구성 가능
• 아웃바운드 보안(인덱서)
  • Private Endpoint를 통한 데이터 연결: Azure Private Link를 통해 보호되는 Azure 리소스에 인덱서 연결
  • Managed Identity를 통한 데이터 연결: Microsoft Entra 보안 주체를 사용한 Azure 리소스 연결 인증 (하드코딩된 API 키 저장 및 전달 제거)
  • Trusted Identity를 사용한 데이터 액세스: 외부 데이터 소스에 대한 연결 문자열에서 사용자 이름 및 비밀번호 생략 가능 (Azure Storage 전용 신뢰할 수 있는 서비스 적용)

3.6 Portal 기능

• 프로토타이핑 및 검사 도구
  • Add Index: Azure Portal의 인덱스 디자이너로 기본 스키마 생성
  • Import Data Wizard: 인덱스, 인덱서, Skillset, 데이터 소스 정의 생성
  • Import Data (New) Wizard: 데이터 청킹 및 벡터화를 포함한 전체 인덱싱 파이프라인 생성
  • Search Explorer: 쿼리 테스트 및 Scoring Profile 개선
  • Create Demo App: 검색 경험 테스트용 HTML 페이지 생성
  • Debug Sessions: Skillset을 대화식으로 디버그하는 시각적 편집기 (종속성, 출력, 변환 표시)
• 모니터링 및 진단
  • 모니터링 기능 활성화하여 포털에서 항상 표시되는 기본 메트릭 외 추가 정보 확인
  • 추가 구성 없이 쿼리/초, 지연 시간, 조절에 대한 메트릭 자동 캡처 및 보고

3.7 프로그래밍 가능성

• REST API
  • Service REST API: 인덱싱, 쿼리, AI Enrichment를 포함한 데이터 평면 작업
  • Management REST API: Azure Resource Manager를 통한 서비스 생성 및 프로비저닝, 키 및 용량 관리
• Azure SDK for .NET
  • Azure.Search.Documents: 데이터 평면 작업
  • Microsoft.Azure.Management.Search: 서비스 관리
• Azure SDK for Java
  • com.azure.search.documents: 데이터 평면 작업
  • com.microsoft.azure.management.search: 서비스 관리
• Azure SDK for Python
  • azure-search-documents: 데이터 평면 작업
  • azure-mgmt-search: 서비스 관리
• Azure SDK for JavaScript/TypeScript
  • azure/search-documents: 데이터 평면 작업
  • azure/arm-search: 서비스 관리

4 서비스 생성 및 구성

4.1 서비스 생성 전 고려사항

4.1.1 고정 속성

서비스 생성 전 다음 속성을 결정해야 한다 (서비스 수명 동안 고정):

속성	설명
Name	URL 엔드포인트의 일부가 되며 고유해야 함. 명명 규칙을 따라야 함
Region	데이터 거주 및 특정 기능의 가용성 결정. 예: Semantic Ranker, Azure AI 통합은 지역 요구사항 있음
Tier	인프라, 서비스 제한, 청구 결정. 일부 기능은 하위 또는 특수 계층에서 사용 불가. 생성 후 Basic과 Standard(S1, S2, S3) 간 전환 가능
Compute Type	가상화 및 보안 모델 결정. Standard VM(권장) 또는 Confidential VM 선택 가능

4.1.2 Azure 구독

• 무료 평가판: Azure 평가판으로 시작
• 무료 계층: 각 Azure 구독당 하나의 무료 검색 서비스 보유 가능
  • 단기, 비프로덕션 제품 평가용
  • 모든 퀵스타트 및 대부분의 튜토리얼 완료 가능
• 중요: Microsoft는 장기간 비활성 상태인 무료 서비스를 삭제할 수 있음

4.2 지역 선택

4.2.1 지역 선택 체크리스트

1. Azure AI Search 가용성: 지원되는 지역 목록 확인
2. 계층별 지역 가용성: 계층별 지역 가용성 확인
3. BCDR 요구사항: 비즈니스 연속성 및 재해 복구가 필요한 경우
   • 서로 다른 Azure 지역에 2개 이상의 검색 서비스 생성
   • 각 서비스에 2개 이상의 복제본 구성하여 여러 가용성 영역에 분산
   • 예: 북미 운영 시 East US + West US 또는 North Central US + South Central US
4. AI Enrichment 요구사항
   • 청구 목적으로 Azure AI Search 서비스와 Microsoft Foundry 리소스는 동일 지역에 있어야 함
   • Azure AI Search 지역 확인: OCR, 엔터티 인식 등 Azure AI 지원 기술 사용 시 AI Enrichment 열에서 동일 지역 여부 확인
   • Foundry Tools의 Azure Vision 지역 확인: 멀티모달 API는 Foundry 리소스보다 일반적으로 더 적은 지역에서 사용 가능

4.2.2 지역 선택 권장사항

• 대부분의 경우: 가까운 지역 선택
• 다음의 경우 예외:
  • 가장 가까운 지역이 용량 부족 상태인 경우 (Azure Portal은 리소스 설정 중 사용 불가능한 지역 및 계층을 자동으로 숨김)
  • 통합 데이터 청킹 및 벡터화 또는 AI Enrichment용 내장 기술 사용 시 (지역 요구사항 있음)
  • 인덱서 기반 인덱싱 또는 인덱스에 없는 애플리케이션 데이터 저장용 Azure Storage 사용 시
    • 방화벽 설정 시 리소스를 별도 지역에 배치해야 함

4.3 계층 선택

Azure AI Search는 여러 가격 계층으로 제공된다:

• Free: 무료
• Basic: 기본
• Standard: 표준
• Storage Optimized: 스토리지 최적화

4.3.1 계층별 특징

• 각 계층마다 고유한 용량 및 제한이 있다
• 일부 기능은 계층에 종속적이다
• 컴퓨팅 특성, 기능 가용성, 지역 가용성은 서비스 계층 선택 참조
• Basic 및 Standard 계층이 프로덕션 워크로드에 가장 일반적이다
• 많은 고객이 Free 계층으로 시작한다
• 청구 가능 계층은 주로 파티션 크기, 파티션 속도, 생성 가능한 객체 수 제한에서 차이가 난다

참고: 2024년 4월 3일 이후 생성된 서비스는 모든 청구 가능 계층에서 더 큰 파티션과 더 높은 Vector Quota를 제공한다.

4.4 Compute Type 선택

Compute Type은 검색 서비스 배포에 사용되는 가상화 및 보안 모델을 결정한다:

• Default (기본 비용)
  • 표준 Azure 인프라에 검색 서비스 배포
  • 저장 및 전송 중 데이터 암호화 (사용 중 암호화는 아님)
  • 대부분의 검색 워크로드에 권장
• Confidential (10% 할증료)
  • Azure Confidential Computing 사용
  • 하드웨어 기반 신뢰 실행 환경에서 처리 격리
  • 사용 중인 암호화되지 않은 데이터를 무단 액세스로부터 보호
  • 고급 개인정보 보호, 규정 준수 또는 규제 요구사항이 있는 경우에만 권장

참고: Confidential Computing은 제한된 지역 가용성, 특정 기능 비활성화 또는 제한, 검색 서비스 실행 비용 증가를 수반한다.

4.5 서비스 생성 단계

1. Azure Portal에 로그인
2. 대시보드 왼쪽 상단에서 Create a resource 선택
3. 검색 상자를 사용하여 Azure AI Search 찾기
4. 구독 선택: 여러 Azure 구독이 있는 경우 검색 서비스용으로 하나 선택
   • Customer-managed Encryption 또는 Managed Service Identity 사용 시 Azure Key Vault 또는 다른 서비스와 동일한 구독 선택
5. 리소스 그룹 설정: 관련 리소스를 보유하는 컨테이너
   • 동일 솔루션 리소스 통합, 비용 모니터링, 생성 날짜 확인 용도
6. 서비스 이름 지정: URL 엔드포인트의 일부가 됨 (https://your-service-name.search.windows.net)
   • 명명 규칙:
     • search.windows.net 네임스페이스 내에서 고유해야 함
     • 2~60자 사용
     • 소문자, 숫자, 대시(-)만 사용
     • 처음 두 문자 또는 마지막 문자로 대시 사용 금지
     • 연속 대시 사용 금지
   • 팁: 여러 검색 서비스가 있는 경우 서비스 이름에 지역 포함 (예: myservice-westus)
7. 지역 선택: 위의 지역 선택 체크리스트 참조
8. 계층 선택: 위의 계층 선택 참조
9. Compute Type 선택: 위의 Compute Type 선택 참조
10. 서비스 생성: 필요한 입력을 모두 제공한 후 검색 서비스 생성
    • 몇 분 내에 배포됨
    • Azure 알림으로 진행 상황 모니터링 가능
    • 향후 쉬운 액세스를 위해 대시보드에 서비스 고정 권장

4.6 인증 구성

4.6.1 기본 인증

• 서비스 생성 시 Key-based Authentication이 기본값이다
• 가장 안전한 옵션은 아니므로 Role-based Access로 교체 권장

4.6.2 Role-based Access 활성화

1. Azure Portal에서 검색 서비스로 이동
2. 왼쪽 창에서 Settings > Keys 선택
3. 인증 옵션 선택:
   • API Keys: API 키 사용 연결
   • Azure Roles: Azure 역할 사용 연결
   • Both: 역할 할당 완료까지 둘 다 사용, 이후 Role-based Access Control 선택

4.6.3 역할 할당

• 서비스 관리자는 기본적으로 모든 Portal 페이지 및 작업에 액세스 가능
• Key-based에서 Keyless 인증으로 전환 시 서비스 관리자는 객체 및 데이터에 대한 전체 액세스를 위해 데이터 평면 역할을 할당받아야 함
• 권장 역할:
  • Search Service Contributor: 서비스 관리
  • Search Index Data Contributor: 인덱스 데이터 기여
  • Search Index Data Reader: 인덱스 데이터 읽기

참고: 역할 할당이 적용되기까지 몇 분 소요될 수 있음. 적용 전까지 데이터 평면 작업용 Portal 페이지에서 권한 부족 메시지 표시됨.

4.7 Managed Identity 구성

인덱서를 사용한 자동 인덱싱, Applied AI, 통합 벡터화를 사용할 계획이라면 Managed Identity를 사용하도록 검색 서비스 구성해야 한다.

4.7.1 통합 벡터화에 필요한 역할

• Azure Storage: Storage Blob Data Reader
• Microsoft Foundry 리소스: Cognitive Services Data User

참고: 역할 할당이 적용되기까지 몇 분 소요될 수 있음. 네트워크 보안으로 이동하기 전에 Import Wizard를 실행하여 역할 할당을 검증하는 것을 권장.

4.8 네트워크 보안 구성

기본적으로 검색 서비스는 공용 인터넷 연결을 통해 인증 및 권한 부여된 요청을 수락한다.

4.8.1 네트워크 보안 강화 옵션

• 방화벽 규칙 구성: IP 주소로 네트워크 액세스 제한
• Private Endpoint 구성: Azure Private Link를 통해 보호되는 Azure 리소스에서만 트래픽 허용
  • 참고: Public Endpoint를 끄면 Import Wizard가 실행되지 않음

자세한 정보: Azure AI Search의 보안

4.9 용량 확인 및 청구 이해

4.9.1 기본 용량

• 기본적으로 검색 서비스는 1개의 복제본(Replica)과 1개의 파티션(Partition)으로 생성됨
• 용량 추가는 복제본 및 파티션을 추가하여 가능하지만 볼륨이 필요할 때까지 대기 권장
• 많은 고객이 최소 구성으로 프로덕션 워크로드 실행

4.9.2 Semantic Ranker

• Semantic Ranker는 Standard 플랜을 선택하면 서비스 실행 비용을 증가시킬 수 있음
• 이 기능을 사용하지 않으려면 서비스 레벨에서 Semantic Ranker를 비활성화 가능

4.9.3 청구에 영향을 미치는 기타 요소

• Azure AI Search 요금 청구 방식 참조

4.10 진단 로깅 활성화

• 진단 로깅 활성화로 사용자 활동 추적
• 이 단계를 건너뛰어도 Activity Logs 및 Platform Metrics는 자동으로 수집됨
• 인덱스 및 쿼리 사용 정보를 원하면 진단 로깅 활성화하고 로깅된 작업의 대상 선택 필요
• 내구성 있는 저장을 위해 Log Analytics Workspace 권장 (Azure Portal에서 시스템 쿼리 실행 가능)

4.10.1 내부 텔레메트리 데이터

• Microsoft는 서비스 및 플랫폼에 대한 텔레메트리 데이터를 내부적으로 수집
• 데이터 보존: 메트릭 보존 참조
• 데이터 위치 및 개인정보 보호: 데이터 거주 참조

4.11 Semantic Ranker 활성화

• Semantic Ranker는 월 처음 1,000개 요청까지 무료
• 최신 검색 서비스에서 기본적으로 활성화됨
• Portal에서 활성화하려면:
  1. 왼쪽 창에서 Settings > Premium features 선택
  2. Free plan 선택
• 자세한 정보: Semantic Ranker 활성화

4.12 스케일링

서비스 배포 후 필요에 따라 스케일링 가능

4.12.1 스케일링 차원

• Replicas(복제본): 더 높은 검색 쿼리 부하 처리
• Partitions(파티션): 더 많은 문서 저장 및 검색

4.12.2 제약사항

• 스케일링은 청구 가능 계층에서만 사용 가능
• Free 계층에서는 스케일링 불가, 복제본 및 파티션 구성 불가

4.12.3 중요 사항

• 서비스는 읽기 전용 SLA를 위해 2개의 복제본, 읽기/쓰기 SLA를 위해 3개의 복제본이 필요
• 리소스 추가는 월별 청구서를 증가시킴
• 가격 계산기로 청구 영향 파악
• 부하에 따라 리소스 조정 가능 (예: 초기 인덱싱 시 증가, 증분 인덱싱 시 감소)

4.12.4 스케일링 방법

1. Azure Portal에서 검색 서비스로 이동
2. 왼쪽 창에서 Settings > Scale 선택
3. 슬라이더를 사용하여 복제본 및 파티션 추가

4.13 두 번째 서비스 추가 시기

대부분의 고객은 예상 부하에 충분한 계층에서 단일 검색 서비스를 사용한다.

4.13.1 단일 서비스의 장점

• 하나의 서비스가 선택한 계층의 최대 제한 내에서 여러 인덱스를 호스팅 가능
• 각 인덱스는 서로 격리됨
• Azure AI Search에서는 요청을 하나의 인덱스로만 보낼 수 있어 동일 서비스의 다른 인덱스에서 데이터를 검색할 가능성 감소

4.13.2 두 번째 서비스가 필요한 경우

• 지역 중단: 전체 지역 중단의 경우 Azure AI Search는 즉시 장애 조치를 제공하지 않음. 자체 다중 지역 솔루션 및 장애 조치 접근 방식 구현 필요
• 멀티테넌트 아키텍처: 2개 이상의 서비스 필요
• 전역 배포 애플리케이션: 각 지역의 서비스로 지연 시간 최소화

4.13.3 참고 사항

• Azure AI Search에서는 인덱싱 및 쿼리 작업을 분리할 수 없으므로 별도 워크로드를 위한 여러 서비스를 만들지 말 것
• 인덱스는 항상 생성된 서비스에서 쿼리되며 인덱스를 다른 서비스로 복사할 수 없음
• 고가용성을 위해 두 번째 서비스가 필요하지 않음
  • 동일 서비스에서 2개 이상의 복제본을 사용하여 쿼리에 대한 고가용성 달성
  • 복제본이 순차적으로 업데이트되므로 서비스 업데이트가 롤아웃될 때 최소 하나는 작동 상태
• 가동 시간에 대한 자세한 정보: Service Level Agreements

4.14 구독에 더 많은 서비스 추가

Azure AI Search는 구독에서 처음 생성할 수 있는 검색 서비스 수를 제한한다.

4.14.1 Quota 요청 조건

• 구독에 대한 Owner 또는 Contributor 권한 필요
• 지역 및 데이터 센터 용량에 따라 자동으로 Quota를 요청하여 구독에 서비스를 추가할 수 있음
• 요청 실패 시 수량을 줄이거나 지원 티켓 제출
• 대규모 Quota 증가(예: 30개 이상의 추가 서비스)는 약 1개월의 처리 기간 예상

4.14.2 Quota 요청 단계

1. Azure Portal의 대시보드로 이동
2. 검색 상자를 사용하여 Quotas 서비스 찾기
3. Overview 탭에서 Search 타일 선택
4. 필터를 설정하여 현재 구독의 검색 서비스에 대한 기존 Quota 검토 (Usage로 필터링 권장)
5. 더 많은 Quota가 필요한 계층 및 지역 옆의 Request Adjustment 선택
6. New Quota Request에서 구독 Quota에 대한 새 제한 입력 (현재 제한보다 커야 함)
   • 지역 용량이 제한된 경우 요청이 자동으로 승인되지 않으며 조사 및 해결을 위한 인시던트 보고서 생성
7. 요청 제출
8. Azure Portal의 알림에서 새 제한에 대한 업데이트 모니터링 (대부분의 요청은 24시간 내 승인됨)

5 서비스 관리

5.1 Role-based Access 구성

Portal 액세스는 역할 할당을 기반으로 한다.

5.1.1 기본 권한

• 새 검색 서비스에는 기본적으로 최소 1명의 서비스 관리자 또는 소유자가 있음
• 서비스 관리자, 공동 관리자, 소유자는 다음 권한을 가짐:
  • 더 많은 관리자 생성 및 다른 역할 할당 권한
  • 기본 검색 서비스의 모든 Portal 페이지 및 작업에 대한 액세스 권한

5.1.2 리소스 잠금

• 기본적으로 관리자 또는 소유자는 서비스를 만들거나 삭제할 수 있음
• 실수로 인한 삭제를 방지하려면 리소스 잠금 고려

5.1.3 API Keys vs RBAC

• 각 검색 서비스에는 API Keys가 제공되며 기본적으로 Key-based 인증 사용
• 보안 향상을 위해 Microsoft Entra ID 및 RBAC 사용 권장
• RBAC는 API 키를 일반 텍스트로 저장하고 전달할 필요성을 제거함

5.1.4 인증 전환

• Key-based에서 Keyless 인증으로 전환 시:
  • 서비스 관리자는 객체 및 데이터에 대한 전체 액세스를 위해 데이터 평면 역할을 할당받아야 함
  • 필요한 역할: Search Service Contributor, Search Index Data Contributor, Search Index Data Reader

5.2 개발자에게 연결 정보 제공

Azure AI Search에 연결하려면 개발자에게 다음이 필요하다:

• 엔드포인트 또는 URL: Overview 페이지에서 확인
• API 키 또는 역할 할당
  • Keys 페이지에서 API 키 확인
  • 또는 역할 할당 (권장)
  • Search Service Contributor, Search Index Data Contributor, Search Index Data Reader 역할 권장
• Portal 액세스
  • Import Wizard 및 Search Explorer 사용 권장
  • Wizard 실행을 위해서는 Contributor 이상이어야 함

6 시작하기

6.1 학습 경로 선택

6.1.1 경로 결정 체크리스트

1. 검색 엔진 선택
   • 에이전트 또는 챗봇을 사용하지 않는 경우: Classic Search가 대부분의 앱 요구사항 충족 (LLM 통합보다 낮은 비용 및 복잡성)
   • Knowledge Base 및 여러 Knowledge Source의 이점을 원하지만 완전한 LLM 오케스트레이션은 원하지 않는 경우: 최소 추론 노력으로 Agentic Retrieval 고려
2. 지역 선택
   • Agentic Retrieval 사용: 지원되는 지역 선택
   • Classic Search: 필요한 기능 및 용량을 제공하는 지역 선택
3. 인덱스 바운드 콘텐츠용 인제스트 방법 선택
   • 콘텐츠가 지원되는 데이터 소스에 있는 경우: Pull 방식 사용하여 데이터 검색 및 JSON으로 직렬화
   • 지원되는 데이터 소스가 없거나 콘텐츠와 인덱스가 실시간으로 동기화되어야 하는 경우: Push 방식이 유일한 옵션
4. 벡터 필요 여부
   • LLM 및 에이전트는 벡터가 필요하지 않음
   • 유사도 검색이 필요하거나 벡터로 동질화할 수 있는 콘텐츠가 있는 경우에만 사용
   • Azure AI Search는 이 작업을 위한 통합 벡터화 제공
5. 사용자 기반 권한 상속 필요 여부
   • Remote SharePoint가 이 시나리오를 위해 설계됨
   • Azure Blob Storage 또는 ADLS Gen2의 콘텐츠에 첨부된 사용자 권한도 상속 가능
   • 다른 모든 시나리오: 보안 필터 해결 방법 사용

6.1.2 퀵스타트

다양한 엔드 투 엔드 검색 시나리오를 다루는 퀵스타트:

• Agentic Retrieval: Portal | Programmatic
• Full-text Search: Portal | Programmatic
• Vector Search: Portal | Programmatic

팁: 복잡하거나 사용자 정의 솔루션에 대한 도움이 필요한 경우 Azure AI Search에 대한 깊은 전문 지식을 가진 파트너에게 문의

6.2 액세스 방법

다음 방법으로 Azure AI Search에 액세스할 수 있다:

• Azure Portal: 서비스 관리 및 콘텐츠 관리
  • Knowledge Base, Knowledge Source, 인덱스, 인덱서, Skillset, 데이터 소스 프로토타이핑 도구 제공
• REST API: REST API 버전
• Azure SDK
  • .NET
  • Java
  • JavaScript
  • Python

6.2.1 권장 사용

• Portal: 서비스 관리 및 콘텐츠 관리에 유용
• REST API 및 SDK: 프로덕션 자동화에 유용

7 참고 자료

• Azure AI Search 개요
• Azure AI Search 기능
• Portal에서 Azure AI Search 서비스 생성
• Portal에서 Azure AI Search 서비스 구성