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

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

시작 문서에서 설명한 대로 사용자 고유의 모델을 빌드할지 또는 미리 빌드된 모델을 사용할지 선택하는 것은 가장 먼저 내려야 할 중요한 결정 중 하나입니다. 미리 빌드된 모델을 선택할 때 다음 사항을 고려합니다.

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

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

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

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

이 문서에서는 기술과 접근 방식에 대한 중요한 결정을 내릴 때 고려해야 할 많은 일반적인 디자인 영역과 요소를 살펴봅니다.

권장 사항

다음은 이 문서에 제공된 권장 사항의 요약입니다.

구성 요소 컨테이너화

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

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

• 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 애플리케이션에 대해 업계에서 확립된 몇 가지 일반적인 디자인 패턴이 있습니다. 이러한 디자인 패턴은 다음과 같습니다.

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

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

• 이벤트 기반 아키텍처: 이벤트를 활용하여 작업을 트리거하면 구성 요소가 분리되고 실시간 처리가 가능하므로 시스템이 변경 데이터에 더 응답하고 적응할 수 있습니다.

RAG 패턴 및 청크 전략

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

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

• 미리 계산(캐시): 이 메서드는 검색 결과를 캐싱하여 미리 계산된 데이터를 제공하여 응답 시간을 줄입니다. 일관된 데이터를 저장할 수 있지만 최신 정보를 반영하지 않을 수 있는 수요가 많은 시나리오에 적합하므로 잠재적인 관련성 문제가 발생할 수 있습니다.

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

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

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

• 접지 원본으로 다시 연결되는 메타데이터 및 고유 식별자를 유지 관리하여 청크의 데이터 계보를 유지합니다. 계보 설명서를 지우면 사용자가 데이터 원본, 해당 변환 및 출력에 기여하는 방법을 이해할 수 있습니다.

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

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

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

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

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

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

프레임워크 및 라이브러리 선택은 애플리케이션 디자인과 밀접하게 연관되어 아키텍처뿐만 아니라 성능, 확장성 및 유지 관리 효율성에도 영향을 줍니다. 반대로 디자인 요구 사항은 프레임워크 선택을 제한하여 둘 사이의 동적 상호 작용을 만들 수 있습니다. 예를 들어 Semantic Kernel SDK(SK)를 사용하면 각 에이전트 또는 기능이 자체 서비스 내에서 캡슐화되는 마이크로 서비스 기반 디자인이 권장되는 경우가 많습니다. 프레임워크 및 라이브러리를 선택할 때 고려해야 할 요소는 다음과 같습니다.

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

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

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

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

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

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

비기능적 요구 사항 고려

AI 기술에 내재된 요인으로 인해 워크로드에 대한 비기능적 요구 사항이 있을 수 있습니다. 일반적인 비기능적 요구 사항 및 해당 과제는 다음과 같습니다.

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

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

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

다음 단계