Azure의 AI 워크로드용 데이터 플랫폼

데이터 플랫폼을 선택하려면 이러한 솔루션이 가져오는 고유한 데이터 문제를 이해해야 합니다. GenAI 솔루션, 특히 기본 모델을 사용하여 빌드된 솔루션은 벡터 검색을 지원하는 확장 가능한 데이터 저장소에 빠르게 액세스하는 다양한 고품질 데이터에 따라 달라집니다. 목표는 아키텍처에 불필요한 복잡성을 추가하지 않고 이러한 요구를 충족하는 것입니다. 플랫폼 옵션을 평가하기 전에 효과적인 데이터 파이프라인 디자인의 원칙을 이해해야 합니다.

플랫폼 선택을 평가할 때는 먼저 추가 구성 요소가 필요한지 물어봅니다. 더 간단한 아키텍처는 배포 속도가 빨라지고 관리가 쉽고 비용 효율적인 경우가 많습니다. 스스로에게 물어보세요:

• 모델이 단일 원본의 데이터를 사용하여 예상 성능을 달성할 수 있나요?
• 원본 데이터 저장소가 이미 필요한 분석 또는 검색 기능을 제공하나요?
• 원본 데이터가 AI 또는 벡터 검색을 위해 이미 구조화되고 인덱싱되었나요?

대부분의 질문에 대한 답변이 '예'이면 복잡한 아키텍처가 필요하지 않을 수 있습니다. 예를 들어 Azure Cosmos DB 및 Azure SQL Database와 같은 데이터베이스는 이미 기본적으로 벡터 데이터 형식 및 벡터 검색을 지원하지만 사용하도록 설정하고 구성해야 합니다. 이러한 기능은 별도의 인덱싱 또는 특수 벡터 데이터베이스의 필요성을 줄여 데이터 이동을 최소화하면서 성능을 향상시킬 수 있습니다.

워크로드가 증가하고 데이터가 여러 원본에서 제공됨에 따라 플랫폼 결정이 더 복잡해집니다. ETL 또는 ELT 파이프라인, 특수 검색 인덱스 및 대규모 데이터 세트에 대한 확장 가능한 스토리지를 지원하는 솔루션을 고려해야 할 수 있습니다. 추가된 각 기능은 단순히 기술 스택을 확장하는 것이 아니라 명확한 목적을 제공해야 합니다.

이 문서에서는 데이터를 저장, 처리 또는 분석해야 하는 워크로드용 데이터 플랫폼을 선택하는 방법에 대한 지침을 제공합니다. GenAI(생성 AI)를 지원하는 솔루션에 초점을 맞춥니다. 이 문서에서 설명하는 기술 기능을 살펴보기 전에 좋은 데이터 파이프라인 디자인의 원칙을 이해하는 것이 좋습니다. 자세한 내용은 기반 데이터 설계를 참조하세요.

차별적인 모델 학습 및 미세 조정과 관련된 권장 사항은 학습 데이터 플랫폼 고려 사항을 참조하세요.

데이터 스토리지 플랫폼에 대한 고려 사항

AI 워크로드에서 데이터는 일반적으로 각 단계를 연결하는 파이프라인에 의해 안내되는 여러 스토리지 및 처리 단계를 통해 이동합니다. 한 가지 중요한 단계는 여러 원본에서 수집 및 결합된 정보를 보유하는 데이터 저장소입니다. 이 저장소를 사용하면 다음 단계가 준비될 때까지 데이터를 처리하고 구체화할 수 있습니다.

이 저장소에 대한 플랫폼을 선택할 때 원본 시스템과 동일한 보안 표준을 따르고, 비용 효율적이며, ETL, ELT 또는 EL 처리 작업에서 잘 작동하는지 확인합니다. 옵션은 데이터 볼륨 및 성능 요구 사항에 따라 간단한 스토리지 솔루션에서 대규모 데이터 플랫폼에 이르기까지 다양할 수 있습니다. 안정적이고 확장 가능하며 워크로드에 적합한 가치를 제공하는 스토리지 옵션을 찾습니다.

다음은 데이터 저장소 기술 선택을 안내하는 데 도움이 되는 몇 가지 질문입니다.

플랫폼이 다른 데이터 형식을 처리할 수 있나요?

데이터 저장소는 다양한 데이터 형식을 저장하고 필요한 경우 데이터 간에 데이터를 변환할 수 있어야 합니다.

예를 들어 수집 파이프라인이 관계형 데이터베이스와 JSON 파일 모두에서 데이터를 가져오는 경우 구조화된 데이터와 반구조화된 데이터를 지원해야 합니다. Delta Lake 기술이 제공하는 다양한 기능을 사용하도록 데이터를 델타 형식으로 변환할 수 있습니다. 플랫폼은 사용자 지정 코드를 작성할 필요가 없도록 이러한 종류의 변환을 위한 기본 제공 도구를 제공해야 합니다.

여러 버전의 데이터를 저장해야 합니까?

시간이 지남에 따라 값과 구조 모두에서 데이터가 변경되고 원본 시스템은 일반적으로 현재 상태만 저장합니다. 기록 컨텍스트가 필요한 경우 버전 관리가 지원되는 데이터 플랫폼을 선택합니다. 데이터 세트가 없으면 데이터 세트를 복제해야 하므로 복잡성이 더해집니다.

버전 관리에는 다른 이점이 있습니다. 경우에 따라 다른 사용 사례에 대해 별도의 데이터 복사본이 필요할 수 있습니다. 각 복사본은 독립적으로 발전할 수 있으며, 플랫폼은 AI 모델의 컨텍스트를 유지하기 위해 모든 복사본에서 버전 관리를 관리해야 합니다.

플랫폼에 기본 제공 데이터 수명 주기 관리 기능이 있나요?

DLM(데이터 수명 주기 관리)은 생성에서 삭제로의 증가를 제어하는 데 도움이 됩니다. 플랫폼은 중간 복사본을 자동으로 제거하고, 보관된 데이터를 관리하고, 필요한 경우 규정 보존을 지원해야 합니다. 이렇게 하지 않으면 데이터가 제어할 수 없게 증가할 수 있으며 불필요한 볼륨으로 인해 처리가 어려워질 수 있습니다. 예를 들어 데이터 품질을 개선하기 위해 전처리 단계를 여러 번 다시 실행해야 할 수 있습니다. 플랫폼은 더 이상 필요하지 않은 경우 중간 복사본을 자동으로 제거해야 합니다.

다른 경우에는 규정 준수 또는 감사를 위해 데이터를 보존해야 할 수 있습니다. 저렴한 비용으로 거의 액세스되지 않는 데이터에 대해 콜드 또는 보관 계층을 지원하는 스토리지 옵션을 찾습니다.

플랫폼이 데이터 거버넌스 기능을 지원하나요?

감사 가능성은 AI 워크로드의 중요한 측면입니다. 플랫폼은 데이터 액세스를 추적하고, 개인 정보를 확인하고, 데이터 원본을 문서화하기 위해 감사 내역을 유지해야 합니다. 또한 메타데이터, 데이터 형식, 용도 및 계보를 관리하는 데이터 사전 또는 카탈로그를 지원해야 하며, 특히 데이터가 여러 원본에서 제공되는 경우에도 지원됩니다.

얼마나 많은 데이터를 저장할 것으로 예상합니까?

AI 워크로드는 대량의 데이터를 생성하므로 여러 버전 및 추가 메타데이터를 통해 더 확장할 수 있습니다. 데이터 플랫폼은 스토리지 및 처리량 모두에 대해 효율적으로 확장되어야 하며, 높은 수집 속도, 동시 쓰기 및 성능 저하 없이 집중적인 처리를 처리해야 합니다.

플랫폼을 선택할 때 수집 및 처리가 동시에 발생하는 경우가 많으므로 전체 워크플로를 고려합니다. 시스템은 병렬 처리 및 빈번한 데이터 이동을 지원하고 원격 분석을 제공하여 읽기 및 쓰기 성능에 대한 명확한 인사이트를 제공해야 합니다.

이 데이터 저장소는 워크로드의 안정성에 중요합니까?

복제 또는 여러 인스턴스를 통해 안정성과 확장성을 지원하는 플랫폼을 선택합니다. 많은 빅 데이터 저장소는 처리를 자동으로 배포하는 컨트롤러를 사용하고 인스턴스를 사용할 수 없게 되면 장애 조치(failover)를 제공합니다.

또한 데이터는 내구성이 뛰어나고 액세스할 수 있어야 합니다. 처음부터 데이터를 다시 빌드하는 데 비용이 많이 드는 경우 플랫폼이 데이터 무결성을 보장하고, 액세스 가능한 API를 제공하고, 백업 또는 복원 기능을 지원하는지 확인합니다.

비용 제약 조건이 있나요?

안정성 및 성능 요구 사항이 충족되면 비용을 최적화하는 방법을 고려합니다. 많은 AI 워크로드의 경우 한 번 쓰고 여러 번 읽는 패턴으로 충분하며 비용 관리를 돕습니다. 접지 데이터는 프로덕션 데이터베이스와 동일한 수준의 응답성이 필요하지 않더라도 저장하고 검색하는 데 비용 효율적이어야 합니다. 목표는 비용, 효율성 및 성능의 균형을 맞추는 것입니다.

데이터 주권 또는 지역 규정 준수 요구 사항을 지원해야 합니까?

규제되거나 중요한 데이터를 처리하는 워크로드의 경우 Azure Government, 21Vianet에서 운영하는 Microsoft Azure 또는 기타 국가별 파트너 클라우드와 같은 소버린 클라우드에 배포하는 것이 좋습니다. 이러한 환경은 데이터 스토리지, 처리 및 액세스가 특정 관할권 내에 유지되도록 하여 엄격한 데이터 보존, 개인 정보 보호 및 규정 준수 요구 사항을 충족하도록 설계되었습니다.

소버린 클라우드는 데이터에 대한 더 큰 제어와 독립성을 제공하며, 이는 종종 정부, 국방 또는 은행과 같은 부문에 대한 요구 사항입니다. 그러나 이러한 지역에서는 일부 고급 AI 및 데이터 플랫폼 기능을 아직 사용할 수 없습니다. 아키텍처를 디자인하기 전에 서비스 가용성을 검토합니다.

Microsoft Purview를 사용하여 이러한 환경에서 데이터 카탈로그, 분류 및 계보 추적을 유지 관리합니다. 기밀 워크로드의 경우 기밀 컴퓨팅 및 고객 관리형 키를 사용하여 데이터 보호를 강화하는 것이 좋습니다. 배포가 지역 규정과 일치하는지 확인해야 합니다.

기술 옵션

데이터 처리 플랫폼에 대한 고려 사항

데이터 처리 플랫폼은 RAG 인덱싱, 분석 또는 기타 사용 사례에 관계없이 다운스트림 사용을 준비할 수 있도록 데이터를 준비하고 변환하는 데 중요한 역할을 합니다.

처리가 발생할 수 있는 두 가지 위치가 있습니다.

• 인제션 레이어 수집 파이프라인은 다양한 원본에서 데이터를 수집하여 집계 데이터 저장소로 이동합니다. 그 과정에서 데이터를 쿼리할 수 있도록 기본 전처리 또는 서식 지정을 수행하는 경우가 많습니다. 사용자 지정 코드의 필요성을 줄이려면 이 작업을 최대한 많이 처리하는 데이터 플랫폼을 사용하는 것이 가장 좋습니다. 도구를 평가할 때 데이터 확대와 같은 AI 워크로드를 지원하는 데 필요한 ETL 또는 ELT 기능을 고려합니다.

• 처리 계층입니다. 집계 저장소에 데이터가 배치된 후에는 일반적으로 AI 모델에서 인덱싱하거나 사용할 준비가 되기 전에 더 심층적인 처리가 필요합니다. 이러한 파이프라인은 수집 계층과 비슷한 수준의 안정성과 확장성을 제공해야 하지만 포커스는 데이터 변환 및 재구성으로 이동합니다.

일반적인 작업은 다음과 같습니다.

• 엔터티 인식 및 확장
• 추가 데이터 원본 통합
• 조회 및 변환 수행
• 관련 없는 데이터 정리 또는 삭제

강력한 데이터 플랫폼은 이러한 작업을 효율적으로 자동화하고 오케스트레이션하는 데 도움이 됩니다.

데이터 원본에 연결하기 위한 지원은 무엇인가요?

플랫폼은 관계형 데이터베이스, 빅 데이터 원본 또는 Blob Storage 등에서 수집해야 하는 데이터 원본에 쉽게 연결해야 합니다.

미리 빌드된 커넥터 및 낮은 코드 통합을 찾습니다. 이상적으로는 조회, 데이터 복사 및 거버넌스를 지원하는 끌어서 놓기 또는 구성 기반 커넥터를 사용하는 것이 좋습니다.

플랫폼이 다양한 데이터 형식을 처리할 수 있나요?

데이터는 구조화된(SQL, 관계형 테이블), 반구조적(JSON, XML, Parquet), 구조화되지 않은(문서, 이미지) 및 스트리밍(IoT 데이터)과 같은 다양한 모양으로 제공됩니다. 사용 사례에서 즉각적이고 장기적인 요구 사항을 고려하는 데 필요한 형식을 처리할 수 있는 플랫폼을 선택합니다.

플랫폼은 데이터 준비 및 범위 조정을 위한 기능을 제공하나요?

데이터가 인덱싱 또는 모델 사용을 위해 준비되기 전에 데이터를 정리, 보강 및 재구성해야 합니다. 데이터 디자인 전략은 요구 사항을 명시적으로 간략하게 설명해야 합니다. 좋은 플랫폼은 다음을 수행해야 합니다.

• 중복 항목 제거 및 누락 값 채우기
• 키워드 또는 하이브리드(키워드+벡터) 검색을 지원하려는 경우 형태소 분석, 정규화 및 기타 기본 정리 작업 처리
• 청크, 보강 및 문서 분석과 같은 고급 변환 지원

데이터 저장소에서 이러한 작업을 기본적으로 지원하는 경우 데이터를 이동하지 않고도 데이터를 처리할 수 있습니다. 그렇지 않으면 Azure Databricks 또는 Azure Data Factory와 같은 외부 도구를 사용하여 대규모 변환을 합니다.

경우에 따라 이 책임의 일부를 다음 단계를 지원하는 플랫폼으로 외부화하도록 선택할 수 있습니다. 이 방법의 일반적인 예는 RAG 구현입니다. 처리하는 동안 문서는 더 작은 청크로 나뉘며 각 청크는 인덱스에 별도의 행으로 저장됩니다. 그런 다음 이러한 청크는 임베딩과 쌍을 이루며 주로 OpenAI 서비스를 통해 생성됩니다. Azure AI Search에서 이 프로세스는 인덱싱 중에 보강 파이프라인의 일부로 오케스트레이션됩니다. 여기서 문서는 포함 모델(예: OpenAI 포함 모델)에 의해 처리되어 인덱스에 저장된 벡터 표현을 생성합니다.

워크플로를 관리하기 위한 기본 제공 오케스트레이터가 있나요?

데이터 처리는 일반적으로 복잡한 조정이 필요한 모듈식 작업으로 발생합니다. 플랫폼에는 이러한 워크플로를 정의, 예약 및 모니터링하는 오케스트레이터가 포함되어야 합니다. 살펴볼 항목:

• 작업 종속성 지원 및 실행 시퀀스의 유효성을 검사하는 검사
• 많은 양의 코드를 다시 작성하지 않고도 쉽게 조정할 수 있는 워크플로를 유연하게 수정할 수 있습니다.
• 모니터링 및 로깅 기능

인기 있는 도구에는 워크플로 관리를 위한 풍부한 기능 집합을 위한 Azure Data Factory 또는 더 복잡한 오케스트레이션을 위한 Azure Databricks가 포함됩니다. 비용이 우려되는 경우 Apache NiFi 또는 Airflow는 보다 경제적인 대안이 될 수 있습니다.

얼마나 많은 데이터를 수집할 것으로 예상합니까?

수집할 데이터의 양과 수집 빈도를 예측합니다. 예를 들어 매일 10테라바이트의 데이터를 인덱스로 로드해야 하는 경우 플랫폼은 강력한 병렬 처리 및 분산 실행을 지원해야 합니다. 더 작은 워크로드의 경우 Logic Apps와 같은 더 간단한 도구가 작동할 수 있지만 더 많은 볼륨의 경우 Data Factory 또는 Databricks가 더 적합합니다. 확장성 및 처리량의 경우 다음을 고려합니다.

• 데이터 볼륨 및 빈도
• 허용 가능한 대기 시간 요구 사항
• 작업 복잡성

예를 들어 데이터 정리에는 잘못된 필드의 유효성을 검사하고 대체하거나 중요한 정보를 마스킹하는 작업이 포함됩니다. 이러한 작업은 기본적으로는 각 행이 개별적으로 처리되므로 상당한 리소스가 필요하며, 이로 인해 전체 시간이 늘어나게 됩니다.

필요한 모니터링 기능은 무엇인가요?

데이터 처리 파이프라인에는 모니터링 기능이 있어야 하며 파이프라인의 성능 및 작업 상태에 대한 인사이트를 제공해야 합니다. 플랫폼은 다음을 제공해야 합니다.

• 작업 진행률 추적
• 파이프라인 동작을 이해하기 위한 로그, 메트릭 및 경고
• 광범위한 모니터링 스택과 통합

기본 제공 원격 분석의 간격을 식별하고 구현해야 하는 추가 모니터링을 결정합니다. 이 모니터링에는 사용자 지정 로깅 또는 메트릭을 추가하여 작업 단계에 대한 특정 세부 정보를 캡처하는 작업이 포함될 수 있습니다.

데이터 처리 플랫폼의 안정성은 얼마나 기대되나요?

단일 실패 지점을 최소화하고 실패한 작업에 대한 재시도를 지원하는 플랫폼을 선택합니다. 예를 들어 AKS(Azure Kubernetes Service)의 Data Factory에서 호출된 사용자 지정 처리 논리를 호스팅하면 일반적으로 Azure Logic Apps에서 호스팅하는 것보다 더 강력한 안정성을 제공합니다.

데이터가 자주 업데이트되지 않으며 매주 일괄 처리를 통해 처리를 처리하는 경우 가끔 오류가 발생할 수 있습니다. 하지만 실시간 AI 시나리오의 경우 더 높은 안정성이 필요합니다.

비용 제약 조건이 있나요?

목표는 오버 엔지니어링을 방지하고 스케일링할 공간을 유지하면서 현재 요구 사항에 맞는 플랫폼을 선택하는 것입니다. 예를 들어 Databricks의 고급 기능이 필요하지 않은 경우 Data Factory는 더 저렴한 옵션을 제공할 수 있습니다. Airflow 또는 NiFi와 같은 오픈 소스 도구는 비용을 더 줄일 수 있습니다.

워크플로 및 처리하는 데이터에 대한 보안 요구 사항은 무엇인가요?

보안, 개인 정보 보호 및 데이터 상주 요구 사항은 사용자의 선택을 안내해야 합니다. 이상적으로 플랫폼은 효율적이고 안전한 데이터 관리를 가능하게 하는 격리를 기본적으로 지원해야 합니다. 최소한 플랫폼이 다음을 수행해야 합니다.

• 지역 데이터 거주법을 준수합니다. 지역 규정 준수 규정을 충족하기 위해 유럽 및 미국용 파이프라인과 같은 다른 지역에 대해 별도의 파이프라인을 실행해야 할 수 있습니다.
• IAM(ID 및 액세스 관리)을 지원하여 권한 있는 ID만 워크플로 내의 특정 작업 또는 단계에 액세스할 수 있도록 합니다.
• 워크플로 또는 단계 수준에서 세분화된 액세스 제어를 허용합니다.

기술 옵션

검색 인덱스에 대한 고려 사항

검색 인덱스는 프롬프트와 함께 모델의 유추 엔드포인트로 전송되는 컨텍스트 또는 접지 데이터를 저장합니다. 인덱스 쿼리는 유추 요청에서 모델로 전송되는 데이터를 준비하는 데 중요한 구성 요소이며 대기 시간이 짧은 성능을 제공해야 합니다.

일괄 처리 지향 ETL 파이프라인과 달리 이 인덱스는 실시간 추론을 지원해야 합니다. 즉, 고성능 및 안정성은 협상할 수 없습니다. AI 워크로드용으로 특별히 제작되었으며 키워드 인덱싱, 필터링 및 벡터 기반 검색과 같은 기능을 지원합니다. 이 기능은 기존 데이터 저장소에서 제공하는 것 이상의 기능을 제공합니다.

이상적인 디자인은 읽기에 최적화된 고성능 데이터 저장소로, 정확하지 않거나 유사하지 않은 쿼리를 처리하면서 관련 결과를 반환할 수 있습니다. 이러한 점을 염두에 두고 인덱스 기술을 선택합니다.

검색 인덱스가 지원하는 검색 유형은 무엇인가요?

시스템에 대한 모든 요청은 인덱스에 대한 하나 이상의 쿼리가 발생할 수 있습니다. RAG(검색 보강 세대) 및 기타 AI 기반 워크로드의 경우 벡터 검색은 필수 항목입니다. 벡터 검색을 사용하면 시스템에서 정확한 키워드 일치가 아닌 포함을 사용하여 의미상 유사한 데이터 요소를 찾을 수 있습니다.

그러나 벡터 검색을 전체 텍스트 검색, 필터링 및 특수 데이터 형식(예: 지리적 위치)과 결합하면 인덱스가 훨씬 더 강력해집니다.

데이터 디자인은 필요한 검색 형식과 함께 작동하는 방법을 명확하게 지정해야 합니다. 자세한 내용은 데이터 디자인의 효율적인 쿼리를 참조 하세요.

인덱스가 멀티모달 데이터를 어떻게 처리하나요?

AI 워크로드는 텍스트뿐만 아니라 이미지, 오디오 또는 비디오도 포함하는 데이터를 처리하는 경우가 많습니다. 인덱스 자체는 이미지를 직접 이해할 수 없습니다. 따라서 인덱스에 이미지를 추가하기 전에 포함이 생성되는 텍스트 기반 표현(OCR 또는 이미지 캡션 사용)으로 변환하거나 비전 모델을 사용하여 이미지에서 직접 벡터 포함을 생성할 수 있어야 합니다. 그러면 인덱스가 벡터 검색을 수행하여 의미 체계 쿼리를 허용할 수 있습니다.

이 사용 사례에서 검색 인덱스가 있어야 합니다.

• 벡터 검색은 이미지에서 파생된 포함(숫자 벡터)을 저장하고 쿼리하도록 지원합니다.
• 인덱싱 프로세스 중에 데이터를 추출하거나 보강하기 위해 외부 API 및 AI 서비스와 통합합니다.
• 추출된 필드(텍스트, 태그, 캡션, 포함)를 검색 및 필터링을 위한 메타데이터로 적절한 스키마 필드에 저장하는 기능입니다.

데이터 원본의 데이터가 변경되면 인덱스가 자동 업데이트 기능을 지원하나요?

자동화는 데이터 새로 고침을 유지하기 위한 핵심입니다. 기본 데이터가 변경되면 자동 업데이트 또는 증분 새로 고침을 지원하는 인덱스를 선택합니다.

플랫폼이 이를 기본적으로 제공하지 않는 경우 업데이트를 검색하고 푸시하는 사용자 지정 프로세스를 구현해야 합니다. 이러한 책임을 플랫폼에 오프로드하면 특히 데이터 볼륨이 증가함에 따라 운영 오버헤드를 줄이고 유지 관리를 간소화할 수 있습니다.

인덱스가 대량의 데이터를 사용하여 수행할 수 있나요?

데이터 볼륨이 증가함에 따라 인덱스가 효율적으로 확장되어야 합니다. RAG를 구현하는 워크로드의 경우 각 문서는 종종 여러 청크로 분할되어 저장된 데이터의 양이 크게 증가합니다.

선택한 플랫폼은 다음을 수행할 수 있어야 합니다.

• 데이터가 증가함에 따라 수평으로 크기 조정
• 부하가 많은 상태에서 쿼리 성능 유지 관리
• 원시 데이터와 관련 메타데이터, 보강 및 엔터티 모두 저장

인덱스가 기본 제공 안정성 기능을 가지고 있나요?

검색 인덱스의 안정성은 둘 다 동일한 실시간 처리 경로의 일부이므로 유추 엔드포인트의 안정성을 미러링해야 합니다.

각 단계는 유사한 작동 시간 및 성능 기대치를 충족해야 합니다. 이를 위해 데이터 플랫폼을 선택할 때 다음 요소들을 확인하십시오.

• 영역 및 지역 중단에서 살아남을 수 있는 고가용성 및 영역 중복 기능
• 추론에 손상된 인덱스가 사용되지 않도록 자동 복구 및 간편한 인덱스 다시 작성
• 인덱스의 별칭 사용이나 전환 기능을 통해 무중단 업데이트를 활성화합니다.

또한 시스템의 오류 모드나 스로틀링과 같은 스트레스 지표를 이해합니다. 예를 들어 백그라운드 다시 인덱싱 중에 처리량이 떨어질 수 있습니다. 시스템은 일반적으로 50명의 동시 사용자를 처리할 수 있지만 해당 작업 중에는 30명만 처리할 수 있습니다. 프런트 엔드 쿼리와 백 엔드 유지 관리 작업을 모두 고려하여 그에 따라 작업 타이밍 및 용량을 계획합니다.

이 기술의 주요 비용 동인은 무엇입니까?

검색 인덱스 비용은 일반적으로 사용량 기반이므로 예상 데이터 볼륨, 쿼리 속도 및 처리량을 모델링하는 것이 중요합니다.

Azure AI Search와 같은 대부분의 인덱스 플랫폼은 PaaS(Platform as a Service) 제품으로, 가격 책정이 추상화되고 용량, 스토리지 및 기능 사용 단위로 제공됩니다.

다음 사항을 염두에 두어야 합니다.

• 계층 가격 책정 및 크기 조정 제한
• 고급 기능의 추가 비용(예: 이미지 추출 또는 기술 세트 보강)
• 과도하게 프로비전된 계층에서 사용되지 않는 용량
• 인덱스 복잡성(인덱스 수 및 동시 쿼리 제한)

AI Search와 관련된 비용을 이해하려면 AI Search 서비스의 비용 계획 및 관리를 참조하세요.

인덱스의 보안 기능이 보안 데이터 디자인을 충족합니까?

데이터 디자인은 보안 및 개인 정보 요구 사항을 명확하게 지정해야 하며 인덱스는 이를 완벽하게 지원해야 합니다. 실제 데이터를 사용하는 개발 또는 테스트 환경에서 작업할 때 인덱스가 액세스 제어 및 추적 가능성 정책을 준수하는지 확인합니다. 다음과 같은 기능을 찾습니다.

• 데이터 마스킹 및 PII 제거
• Microsoft Entra ID를 통한 클라이언트 ID 관리
• 사용자 ID를 기반으로 결과를 필터링하기 위한 문서 수준 액세스 제어

플랫폼이 기본적으로 이러한 필터를 지원하지 않는 경우 쿼리 수준 필터를 대체(fallback)로 구현하는 것이 좋습니다. 자세한 내용은 AI Search에서 결과를 트리밍하기 위한 보안 필터를 참조하세요.

네트워크 보안 관점에서 인덱스가 다음을 수행해야 합니다.

• 출구 제어 및 네트워크 세분화 지원
• 가상 네트워크에서 컴퓨팅이 실행되면 프라이빗 네트워크와 통합
• Microsoft Entra ID를 통해 인증에 관리 ID 사용
• 구성 요소를 공용 인터넷에 직접 노출하지 마세요.

보호가 제대로 이뤄지지 않으면 임베딩은 여전히 민감한 정보를 노출할 수 있습니다. 위험에는 포함 반전(벡터에서 원본 텍스트 재구성), 데이터 중독 공격(악의적인 벡터 삽입), 저장소나 백업에 대한 무단 접근이 포함됩니다. 이러한 위험을 완화하려면 다음과 같은 보안 조치를 적용합니다.

• 휴면 중 및 전송 중 암호화
• 엄격한 액세스 제어
• 위에서 설명한 프라이빗 네트워크 연결
• 비정상 또는 변조를 감지하기 위한 임베딩 엔드포인트 모니터링

다른 유형의 데이터와 마찬가지로 중요한 데이터 또는 개인 데이터를 제거하는 프로세스가 있습니다. 벡터 인덱스를 다른 프로덕션 시스템과 동일한 수준의 보안 및 거버넌스가 필요한 중요한 데이터 저장소로 취급합니다.

기술 옵션

학습 및 미세 조정 고려 사항

기존 ML(기계 학습) 또는 비 GenAI 워크로드용 데이터 플랫폼을 디자인할 때 실시간 유추에서 데이터 품질, 재현성 및 환경 분리로 포커스가 이동합니다. 이러한 워크로드는 잘 구성된 집계 데이터를 사용하며 모델 성능 및 비용 효율성을 최적화하기 위해 기능 저장소 및 일괄 처리 유추 데이터 저장소와 같은 추가 계층을 포함하는 경우가 많습니다.

이 문서에서 설명하는 기술 기능을 살펴보기 전에 좋은 데이터 파이프라인 디자인의 원칙을 이해하는 것이 좋습니다. 자세한 내용은 학습 데이터 디자인을 참조하세요.

프로덕션 데이터를 사용하여 교육을 수행할 계획입니까?

모델을 배포하는 방법은 프로덕션 데이터가 개발 환경과 얼마나 긴밀하게 결합되는지를 결정합니다. 다음과 같은 두 가지 주요 배포 방법이 있습니다.

• 모델 배포. 모델은 개발 중에 프로덕션 데이터를 사용하여 학습되거나 조정됩니다. 이 방법은 모델 관련성을 향상시킬 수 있지만 중요한 데이터가 프로덕션 외부에서 사용되므로 강력한 보안 제어가 필요합니다.

• 코드 배포. 모델은 개발 시 비프로덕션 데이터를 사용하여 학습되며 프로덕션에 배포된 후에만 실제 데이터와 상호 작용합니다. 이 방법은 개발 보안을 간소화하지만 여러 환경에서 학습을 반복해야 할 수 있으므로 컴퓨팅 및 스토리지 비용을 증가시킬 수 있습니다.

접근 방식에 관계없이 데이터 플랫폼은 개발 및 프로덕션 환경을 명확하게 분리하여 적절한 격리 및 액세스 제어를 보장해야 합니다.

기능보다 편의성을 우선시하고 있나요?

ML용 데이터 플랫폼을 선택할 때는 Notebook 지원만을 기반으로 결정을 내리지 마세요.

Notebook은 예비 데이터 분석에 적합하지만 프로덕션 등급 데이터 플랫폼을 선택하기 위한 결정 요소는 아닙니다. Notebook 컴퓨팅 리소스는 일반적으로 집계 데이터 저장소 외부에 있으며 Azure Machine Learning 또는 Databricks 작업 영역과 같은 외부 도구와 통합됩니다.

편리한 기능보다 데이터 버전 관리, 거버넌스, 확장성 및 보안과 같은 핵심 기능의 우선 순위를 지정합니다.

데이터를 처리하고 준비하려면 어떻게 해야 할까요?

ML 워크로드에서 선택하는 데이터 처리 패턴은 유연성과 성능에 큰 영향을 줍니다.

• ETL(추출, 변환, 로드) – 스키마 제약 조건에 따라 데이터를 대상 시스템에 로드하기 전에 변환해야 하는 기존 데이터 웨어하우징에서 일반적입니다.
• ELT(추출, 로드, 변환) – 원시 데이터가 먼저 로드된 다음 Python 또는 PySpark와 같은 도구를 사용하여 나중에 변환되는 데이터 레이크 또는 레이크하우스 아키텍처에 일반적입니다.
• EL(추출, 로드) – 문서 또는 미디어를 먼저 저장하고 나중에 다운스트림 변환(예: 텍스트 청크 또는 이미지 추출)을 수행하는 GenAI 및 RAG 패턴에서 일반적입니다.

ELT는 원시 데이터를 보존하고 모델 준비 중에 보다 유연한 변환을 허용하기 때문에 선호되는 경우가 많습니다.

기능 저장소가 필요한가요?

집계된 데이터 저장소와 학습 환경 간에 중간 데이터 계층으로 기능 저장소를 도입하는 것이 좋습니다.

기능 저장소는 기능 계보, 생성 시간 및 원본과 같은 메타데이터가 포함된 큐레이팅된 기능의 카탈로그 역할을 합니다. 여러 모델 또는 실험에서 재사용할 수 있는 "골든" 학습 데이터를 유지하기에 완벽한 장소입니다.

Azure Machine Learning의 기능 저장소와 같은 관리되는 기능 저장소는 MLflow 및 기타 ML 수명 주기 도구와 직접 통합됩니다. 기능의 재현성, 거버넌스 및 버전 제어를 사용하도록 설정합니다.

적절한 액세스 제어, 암호화 및 감사를 통해 기능 저장소를 자체적으로 중요한 데이터 저장소로 처리합니다.

일괄 처리 유추 데이터 저장소를 사용해야 하나요?

경우에 따라 추론을 일괄 처리로 수행하여 성능을 향상시키고 비용을 줄일 수 있습니다. 즉, 추론 결과를 미리 계산하고 모델을 실시간으로 호출하는 대신 나중에 사용할 수 있도록 저장합니다.

이 방법은 동일한 쿼리 또는 예측이 반복적으로 요청될 때(예: FAQ 또는 표준 권장 사항 생성) 매우 효과적일 수 있습니다.

주요 이점은 다음과 같습니다.

• 대기 시간이 단축되고 사용자 환경이 개선되어 결과가 즉시 제공됩니다.
• 유추를 오프라인으로 일괄 처리하고 배포할 수 있으므로 확장성이 더 쉽습니다.
• 유추 엔드포인트에 실시간 부하를 두지 않도록 하는 향상된 안정성.
• 일괄 처리로 인한 컴퓨팅 비용을 낮추면 하위 계층 하드웨어를 사용할 수 있습니다.
• 사용자에게 노출되기 전에 정확도를 확인할 수 있는 기본 제공 사전 유효성 검사입니다.

그러나 이 방법은 상당한 비율의 예측이 재사용될 때 가장 적합합니다. 워크로드에 대부분 고유한 쿼리가 포함된 경우 일괄 처리 유추 저장소를 유지 관리하는 것이 복잡하지 않을 수 있습니다.

일괄 처리 유추 데이터 저장소는 읽기 작업에 최적화되고, 큰 데이터 세트를 처리할 수 있을 만큼 확장 가능하며, 집계 데이터 저장소와 통합되어야 합니다.

이 패턴에 맞는 기술에는 빠르고 전역적으로 분산된 액세스를 위한 Azure Cosmos DB 또는 더 간단하고 저렴한 읽기 작업이 많은 워크로드를 위한 Azure Table Storage가 포함됩니다.

기술 옵션

다음 단계