Azure의 AI 워크로드를 위한 애플리케이션 디자인

AI 함수가 있는 애플리케이션을 만들 때 고려해야 할 많은 옵션이 있습니다. 사용 사례가 기존 기계 학습, 생성적, 결정적 또는 AI 유형의 조합인지 여부와 같은 고유한 기능 및 비기능적 요구 사항은 디자인에 대한 높은 수준의 의사 결정을 좁히는 데 도움이 됩니다. 상위 수준 디자인 영역에서 하위 수준 디자인 영역으로 이동할 때 이러한 선택을 고려합니다.

시작 문서에서 설명한 대로 고유한 모델을 빌드할지 또는 미리 빌드된 모델을 사용할지 여부는 가장 먼저 결정해야 하는 중요한 결정 중 하나입니다. 미리 빌드된 모델을 사용하는 경우 다음 사항을 고려합니다.

• 카탈로그 원본. Hugging Face Model Hub, TensorFlow Hub 및 Azure AI Foundry 포털 모델 카탈로그와 같은 리포지토리를 탐색하여 미리 학습된 모델을 찾습니다. 이러한 플랫폼은 다양한 작업에 대한 광범위한 모델 카탈로그를 제공합니다.

• 라이런싱. 특히 애플리케이션을 배포하거나 다른 서비스와 통합하려는 경우 모델의 라이선스 조건이 보안, 규정 준수 및 애플리케이션 목표에 적합한지 확인합니다.

• 주요 구성 요소입니다. 모델의 아키텍처, 학습 데이터, 성능 및 라이선스를 확인하여 작업 또는 도메인에 맞게 미세 조정되었는지 확인합니다.

호스팅 플랫폼 선택에 대한 지침은 모델 호스팅 및 유추 플랫폼 대한고려 사항을 참조하세요.

이 문서에서는 기술 및 접근 방식에 대한 결정을 내릴 때 고려해야 할 일반적인 디자인 영역 및 요인에 대해 설명합니다.

권장 사항

다음 표에는 이 문서에 제공된 권장 사항이 요약되어 있습니다.

구성 요소 컨테이너화

독립적으로 배포 가능한 구성 요소가 완전히 자체 포함되도록 하고 배포를 간소화하려면 컨테이너화를 디자인 전략의 일부로 고려합니다. 다음 구성 요소는 컨테이너화되어야 합니다.

• 마이크로서비스. 데이터 처리, 모델 유추 및 사용자 인증과 같은 애플리케이션의 특정 기능을 처리하는 개별 마이크로 서비스를 컨테이너화해야 합니다. 이 방법은 독립적인 배포 및 크기 조정을 가능하게 하고 보다 효율적인 업데이트 및 유지 관리를 용이하게 합니다.

• AI 모델은. AI 모델을 컨테이너화하여 모든 종속성, 라이브러리 및 구성이 함께 번들로 묶이도록 합니다. 이 방법은 모델 환경을 호스트 시스템에서 격리하여 버전 충돌을 방지하고 여러 배포 환경에서 일관된 동작을 보장하는 데 도움이 됩니다.

• 데이터 처리 파이프라인. 데이터 정리, 변환 및 기능 추출과 같이 모델 유추를 선행하거나 따르는 모든 데이터 처리 작업은 컨테이너화되어야 합니다. 이 방법은 재현성을 향상시키고 종속성 관리를 간소화합니다.

• 인프라 서비스. 데이터베이스 및 캐싱 계층과 같은 인프라 지원을 제공하는 서비스도 컨테이너화의 이점을 누릴 수 있습니다. 이러한 서비스를 컨테이너화하면 버전 일관성을 유지하고 이러한 구성 요소의 크기 조정 및 관리를 용이하게 합니다.

AI 구성 요소를 다른 워크로드 구성 요소와 함께 배치하십시오.

AI 구성 요소를 다른 워크로드 구성 요소와 공동 배치해야 하는 몇 가지 좋은 이유가 있지만 이러한 구성 요소와 관련된 절충이 있습니다. 다음과 같은 이유로 구성 요소를 한 장소에 함께 배치하도록 선택할 수 있습니다.

• 대기 시간 민감도. 짧은 대기 시간이 중요한 경우 API 호스팅과 같은 다른 서비스와 AI 구성 요소를 공동 배치합니다. 예를 들어 사용자 환경을 향상시키기 위해 실시간 유추가 필요한 경우 AI 모델을 API에 가깝게 배치하면 결과를 검색하는 데 걸리는 시간을 최소화할 수 있습니다.

• 데이터 근접. AI 모델에서 검색 인덱스와 같은 특정 데이터 세트에 자주 액세스해야 하는 경우 이러한 구성 요소를 공동 배치하면 성능이 향상되고 데이터 전송 오버헤드를 줄여 처리 및 유추 속도를 높일 수 있습니다.

• 리소스 사용률. 특정 구성 요소에 CPU 및 메모리와 같은 보완적인 리소스 요구 사항이 있는 경우 공동 배치하면 리소스 사용량을 최적화할 수 있습니다. 예를 들어 상당한 계산이 필요한 모델은 요구 사항이 낮은 서비스와 리소스를 동시에 공유할 수 있습니다.

타협점. 구성 요소를 공동 배치할지 여부를 결정할 때 고려할 장단점이 있습니다. 구성 요소를 독립적으로 배포하거나 크기를 조정하는 기능이 손실될 수 있습니다. 또한 사고의 잠재적인 폭발 반경을 늘려 오작동 위험을 높일 수도 있습니다.

생성 AI 솔루션에서 오케스트레이터 사용 평가

오케스트레이터는 복잡한 워크로드에서 관리하기 어려운 AI 솔루션의 여러 구성 요소 간의 통신을 조정하여 워크플로를 관리합니다. 워크로드에 다음 특성이 있는 경우 디자인에 오케스트레이터를 빌드하는 것이 좋습니다.

• 복잡한 워크플로. 워크플로에는 전처리, 모델 체인 또는 후처리와 같은 여러 단계가 포함됩니다.

• 조건부 논리 . 결과를 다른 모델로 라우팅하는 것과 같은 결정은 모델 출력에 따라 동적으로 내려야 합니다.

• 크기 조정 및 리소스 관리 . 수요에 따라 모델 크기 조정을 사용하여 대용량 애플리케이션에 대한 리소스 할당을 관리해야 합니다.

• 상태 관리. 사용자 상호 작용의 상태 및 메모리를 관리해야 합니다.

• 데이터 검색. 인덱스에서 확대 데이터를 검색할 수 있어야 합니다.

여러 모델 사용에 대한 고려 사항

워크로드에서 여러 모델을 사용하는 경우 오케스트레이터가 필수적입니다. 오케스트레이터는 사용 사례에 따라 데이터 및 요청을 적절한 모델로 라우팅합니다. 모델 간의 데이터 흐름을 계획하여 한 모델의 출력이 다른 모델의 입력으로 사용될 수 있도록 합니다. 계획에는 데이터 변환 또는 보강 프로세스가 포함될 수 있습니다.

오케스트레이션 및 에이전트

생성적 AI 작업 부하의 경우, 종종 에이전틱이라고도 불리는 에이전트 기반 접근 방식을 디자인에 채택하여 오케스트레이션에 확장성을 추가하는 것이 좋습니다. 에이전트는 컨텍스트에 바인딩된 기능을 제공합니다. 마이크로 서비스와 많은 특성을 공유하고 오케스트레이터와 함께 작업을 수행합니다. 오케스트레이터는 작업을 에이전트 풀에 보급하거나 에이전트가 오케스트레이터에 기능을 등록할 수 있습니다. 두 방법을 모두 사용하면 오케스트레이터가 에이전트 간에 쿼리를 분할하고 라우팅하는 방법을 동적으로 결정할 수 있습니다.

에이전트 접근 방식은 시간에 따라 흐름에 더 많은 기술과 접지 데이터를 추가하기 위해 환경에 연결할 수 있는 여러 가지 진화하는 기능이 있는 공통 UI 표면이 있는 경우에 이상적입니다.

에이전트가 많은 복잡한 워크로드의 경우 오케스트레이터를 사용하여 작업을 분리하고 할당하는 대신 에이전트가 동적으로 공동 작업할 수 있도록 하는 것이 더 효율적입니다.

오케스트레이터와 에이전트 간의 통신은 토픽 큐 패턴을 따라야 합니다. 여기서 에이전트는 토픽의 구독자이며 오케스트레이터는 큐를 통해 작업을 보냅니다.

에이전트 접근 방식을 사용하는 것은 안무 패턴이 아닌 오케스트레이션 패턴에서 가장 잘 작동합니다.

자세한 내용은 오케스트레이션 플랫폼에 대한 고려 사항을 참조하세요.

API 게이트웨이 사용 평가

Azure API Management와 같은 API 게이트웨이는 API에서 멀리 떨어진 추상 함수를, 이는 요청 서비스와 API 간의 종속성을 분리합니다. API 게이트웨이는 AI 워크로드에 다음과 같은 이점을 제공합니다.

• 여러 마이크로 서비스 . 게이트웨이는 속도 제한 및 인증과 같은 일관된 정책을 적용해야 하는 경우 여러 AI 모델 엔드포인트를 관리하는 데 도움이 됩니다.

• 트래픽 관리. 게이트웨이를 사용하면 요청을 관리하고, 응답을 캐싱하고, 부하를 분산하여 트래픽이 많은 앱을 효율적으로 관리할 수 있습니다.

• 보안. 게이트웨이는 게이트웨이 뒤에 있는 API에 대한 중앙 집중식 액세스 제어, 로깅 및 위협 방지 기능을 제공합니다.

AI 애플리케이션 디자인 패턴 사용

AI 애플리케이션에 대한 업계에서 몇 가지 일반적인 디자인 패턴이 설정되었습니다. 이를 사용하여 디자인 및 구현을 간소화할 수 있습니다. 이러한 디자인 패턴은 다음과 같습니다.

• 모델 앙상블링. 이 디자인 패턴에는 개별 모델의 약점을 완화하여 정확도와 견고성을 향상시키기 위해 여러 모델의 예측을 결합하는 작업이 포함됩니다.

• 마이크로 서비스 아키텍처. 구성 요소를 독립적으로 배포 가능한 서비스로 분리하면 확장성 및 유지 관리 효율성이 향상됩니다. 이를 통해 팀은 애플리케이션의 여러 부분에서 동시에 작업할 수 있습니다.

• 이벤트 기반 아키텍처. 이벤트를 사용하여 작업을 트리거하면 분리된 구성 요소와 실시간 처리를 통해 시스템의 응답성이 향상되고 변경 데이터에 적응할 수 있습니다.

RAG 패턴 및 청크 전략

RAG(Retrieval-Augmented 생성) 패턴은 생성 모델을 검색 시스템과 결합하여 모델이 향상된 컨텍스트 및 정확도를 위해 외부 지식 원본에 액세스할 수 있도록 합니다. 이 패턴에 대한 자세한 지침은 디자인 및 RAG 솔루션 일련의 문서를 참조하세요. 다음 두 가지 RAG 방법이 있습니다.

• 적시 생산. 이 방법은 요청 시 관련 정보를 동적으로 검색하여 최신 데이터가 항상 사용되는지 확인합니다. 실시간 컨텍스트가 필요한 시나리오에서는 유용하지만 대기 시간이 발생할 수 있습니다.

• 미리 계산된(캐시된). 이 메서드에는 사전 계산된 데이터를 제공하여 응답 시간을 줄이기 위해 검색 결과를 캐싱하는 작업이 포함됩니다. 일관된 데이터를 저장할 수 있는 수요가 많은 시나리오에 적합합니다. 데이터에 최신 정보가 반영되지 않아 관련성 문제가 발생할 수 있습니다.

RAG 패턴을 사용하는 경우 워크로드의 성능 효율성을 최적화하는 데 잘 정의된 청크링 전략이 중요합니다. 디자인에 제공된 지침 시작하고 RAG 솔루션 시리즈를 개발합니다. 고려해야 할 몇 가지 추가 권장 사항은 다음과 같습니다.

• 데이터 형식, 쿼리 복잡성 및 사용자 요구 사항에 따라 청크 크기를 조정하는 동적 청크 전략을 구현합니다. 이렇게 하면 검색 효율성 및 컨텍스트 보존이 향상됩니다.

• 피드백 루프를 통합하여 성능 데이터를 기반으로 청크 분할 전략을 구체화합니다.

• 메타데이터와 고유 식별자를 유지 관리하여 기초 원본으로 다시 연결하고 청크의 데이터 계보를 보존합니다. 계통 문서가 명확하면 사용자가 데이터의 출처, 변환, 그리고 출력에 어떻게 기여하는지를 이해하는 데 도움이 됩니다.

디자인 패턴을 사용하는 경우

사용 사례가 설명된 조건을 충족하는 경우 이러한 디자인 패턴을 사용하는 것이 좋습니다.

• 복잡한 워크플로. 여러 AI 모델 간에 복잡한 워크플로 또는 상호 작용이 있는 경우 RAG 또는 마이크로 서비스와 같은 패턴은 복잡성을 관리하고 구성 요소 간의 명확한 통신을 보장하는 데 도움이 될 수 있습니다.

• 확장성 요구 사항. 애플리케이션에 대한 수요가 변동하는 경우 마이크로 서비스와 같은 패턴을 사용하면 개별 구성 요소가 전체 시스템 성능에 영향을 주지 않고 다양한 부하를 수용하도록 독립적으로 확장할 수 있습니다.

• 데이터 기반 애플리케이션 . 애플리케이션에 광범위한 데이터 처리가 필요한 경우 이벤트 기반 아키텍처는 실시간 응답성과 효율적인 데이터 처리를 제공할 수 있습니다.

올바른 프레임워크 및 라이브러리 선택

프레임워크 및 라이브러리 선택은 애플리케이션 디자인과 밀접하게 연관되어 있습니다. 성능, 확장성 및 유지 관리에 영향을 줍니다. 그러나 디자인 요구 사항은 프레임워크 선택을 제한할 수 있습니다. 예를 들어 의미 체계 커널 SDK를 사용하면 각 에이전트 또는 함수가 자체 서비스 내에서 캡슐화되는 마이크로 서비스 기반 디자인이 권장되는 경우가 많습니다. 프레임워크 및 라이브러리를 선택할 때 다음 요소를 고려합니다.

• 애플리케이션 요구 사항. 실시간 처리 또는 일괄 처리와 같은 애플리케이션의 요구 사항은 프레임워크 선택을 제한할 수 있습니다. 예를 들어 애플리케이션에 짧은 대기 시간이 필요한 경우 비동기 기능이 있는 프레임워크를 사용해야 할 수 있습니다.

• 통합에는필요합니다. 디자인에는 다른 시스템 또는 서비스와의 특정 통합이 필요할 수 있습니다. 프레임워크가 필요한 프로토콜 또는 데이터 형식을 지원하지 않는 경우 디자인을 재고하거나 다른 프레임워크를 선택해야 할 수 있습니다.

• 팀 전문 지식. 개발 팀의 기술 집합은 프레임워크 선택을 제한할 수 있습니다. 덜 익숙한 프레임워크를 사용하는 디자인은 개발 시간과 복잡성을 증가시킬 수 있으므로 좀 더 친숙한 도구를 사용할 수 있습니다.

ID, 권한 부여 및 액세스에 대한 전략 설계

일반적으로 일반적으로 애플리케이션을 디자인할 때와 동일한 방식으로 ID, 권한 부여 및 액세스에 접근해야 합니다. Microsoft Entra ID와 같은 ID 공급자를 사용하여 이러한 영역을 가능한 한 많이 관리해야 합니다. 그러나 많은 AI 애플리케이션에는 특별한 고려가 필요한 고유한 과제가 있습니다. 새로운 개발 없이 시스템을 통해 ACL(액세스 제어 목록)을 유지하는 것은 때로는 어렵거나 불가능합니다.

보안 다중 테넌트 RAG 유추 솔루션 디자인하려면 가이드를 참조하여 문서 및 청크에 보안 트리밍 메타데이터를 추가하는 방법을 알아봅니다. 이 트리밍은 보안 그룹 또는 유사한 조직 구문을 기반으로 할 수 있습니다.

비기능적 요구 사항 고려

워크로드에는 AI 기술에 내재된 요인으로 인해 문제를 야기하는 비기능적 요구 사항이 있을 수 있습니다. 다음은 몇 가지 일반적인 비기능적 요구 사항 및 해당 과제입니다.

• 모델 추론의 대기 시간/시간 제한 . AI 애플리케이션에는 종종 실시간 또는 거의 실시간 응답이 필요합니다. 짧은 대기 시간을 위해 디자인하는 것이 중요합니다. 여기에는 모델 아키텍처, 데이터 처리 파이프라인 및 하드웨어 리소스 최적화가 포함됩니다. 캐싱 전략을 구현하고 효율적인 모델 로드를 보장하는 것도 시간 제한을 방지하고 적시에 응답을 제공하는 데 필수적입니다.

• 토큰 또는 요청 처리량 제한 . 많은 AI 서비스는 특히 클라우드 기반 모델에서 토큰 수 또는 요청 처리량에 제한을 적용합니다. 이러한 제한 사항에 맞게 설계하려면 입력 크기를 신중하게 관리하고, 필요한 경우 요청을 일괄 처리하고, 잠재적으로 사용자 기대치를 관리하고 서비스 중단을 방지하기 위해 속도 제한 또는 큐 메커니즘을 구현해야 합니다.

• 비용 및 차지백 관련 시나리오입니다.. 비용 투명성을 위한 설계에는 차지백 모델을 용이하게 하는 사용량 추적 및 보고 기능을 구현하는 작업이 포함됩니다. 이러한 기능을 통해 조직은 부서 간에 비용을 정확하게 할당할 수 있습니다. 차지백 관리는 일반적으로 Azure API Management 같은 API 게이트웨이에서 처리됩니다.

다음 단계