초기 OpenAI 엔드 투 엔드 채팅 참조 아키텍처

엔터프라이즈 채팅 애플리케이션은 대화형 상호 작용을 통해 직원에게 권한을 부여할 수 있습니다. 특히 OpenAI의 GPT 모델 및 Meta의 LLaMA 모델과 같은 대규모 언어 모델의 지속적인 발전으로 인해 특히 그렇습니다. 이러한 채팅 애플리케이션은 채팅을 위한 사용자 인터페이스, 사용자의 쿼리와 관련된 do기본 관련 정보를 포함하는 데이터 리포지토리, 관련 응답을 생성하기 위한 do기본 특정 데이터에 대한 이유인 LLM(대규모 언어 모델) 및 이러한 구성 요소 간의 상호 작용을 감독하는 오케스트레이터로 구성됩니다.

이 문서에서는 Azure OpenAI 대규모 언어 모델을 사용하는 엔터프라이즈 채팅 애플리케이션을 빌드하고 배포하기 위한 기준 아키텍처를 제공합니다. 이 아키텍처는 AML(Azure Machine Learning) 프롬프트 흐름을 사용하여 들어오는 프롬프트에서 데이터 저장소로 워크플로를 오케스트레이션하여 필요한 다른 Python 논리와 함께 LLM에 대한 접지 데이터를 가져오는 실행 가능한 흐름을 만듭니다. 실행 파일 흐름은 관리되는 온라인 엔드포인트 뒤에 있는 Azure Machine Learning 컴퓨팅 클러스터에 배포됩니다.

사용자 지정 UI(채팅 사용자 인터페이스)의 호스팅은 Azure 앱 Services에서 보안, 영역 중복 및 고가용성 웹 애플리케이션을 배포하기 위한 기준 앱 서비스 웹 애플리케이션 지침을 따릅니다. 해당 아키텍처에서 App Service는 프라이빗 엔드포인트를 통해 가상 네트워크 통합을 통해 Azure PaaS 서비스와 통신합니다. 마찬가지로 채팅 UI App Service는 프라이빗 엔드포인트를 통해 흐름에 대한 관리되는 온라인 엔드포인트와 통신하고 Azure Machine Learning 작업 영역에 대한 공용 액세스는 사용하지 않도록 설정됩니다.

Machine Learning 작업 영역은 모든 아웃바운드 연결을 승인해야 하는 관리형 가상 네트워크 격리로 구성됩니다. 이 구성을 사용하면 관리형 가상 네트워크가 회사 Azure Storage, Azure Container Registry 및 Azure OpenAI와 같은 프라이빗 리소스에 연결할 수 있는 관리형 프라이빗 엔드포인트와 함께 만들어집니다. 이러한 프라이빗 연결은 흐름 작성 및 테스트 중과 Azure Machine Learning 컴퓨팅에 배포된 흐름에 의해 사용됩니다.

아키텍처

그림 1: OpenAI를 사용하여 기준 엔드 투 엔드 채팅 아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

구성 요소

이 아키텍처의 채팅 UI 호스팅이 기준 App Service 웹 애플리케이션의 아키텍처를 따르기 때문에 이 아키텍처의 많은 구성 요소는 기준 앱 서비스 웹 애플리케이션의 리소스와 동일합니다. 이 섹션에서 강조 표시된 구성 요소는 채팅 흐름을 빌드 및 오케스트레이션하는 데 사용되는 구성 요소와 LLM을 노출하는 데이터 서비스 및 서비스에 초점을 맞춥니다.

• Azure Machine Learning 은 기계 학습 모델을 학습, 배포 및 관리하는 데 사용되는 관리형 클라우드 서비스입니다. 이 아키텍처는 대규모 언어 모델에서 제공하는 AI 애플리케이션에 대한 실행 흐름을 개발하고 배포하는 데 사용되는 Azure Machine Learning의 다른 여러 기능을 사용합니다.
  • Azure Machine Learning 프롬프트 흐름 은 사용자 프롬프트, Python 코드를 통한 작업 및 LLM 호출을 연결하는 흐름을 빌드, 평가 및 배포할 수 있는 개발 도구입니다. 프롬프트 흐름은 프롬프트, 다른 데이터 저장소 및 LLM 간의 흐름을 오케스트레이션하는 계층으로 이 아키텍처에서 사용됩니다.
  • 관리형 온라인 엔드포인트를 사용하면 실시간 유추를 위해 흐름을 배포할 수 있습니다. 이 아키텍처에서는 Azure Machine Learning에서 호스트하는 프롬프트 흐름을 호출하기 위해 채팅 UI의 PaaS 엔드포인트로 사용됩니다.
• Azure Storage 는 프롬프트 흐름 개발을 위해 프롬프트 흐름 원본 파일을 유지하는 데 사용됩니다.
• Azure Container Registry를 사용하면 모든 유형의 컨테이너 배포를 위해 이미지와 아티팩트를 프라이빗 레지스트리에 빌드, 저장 및 관리할 수 있습니다. 이 아키텍처에서 흐름은 컨테이너 이미지로 패키지되고 Azure Container Registry에 저장됩니다.
• Azure OpenAI 는 GPT-4, GPT-3.5-Turbo 및 모델 포함 세트를 포함하여 Azure OpenAI의 대규모 언어 모델에 REST API 액세스를 제공하는 완전 관리형 서비스입니다. 이 아키텍처에서는 모델 액세스 외에도 가상 네트워크 및 프라이빗 링크, 관리 ID 지원 및 콘텐츠 필터링과 같은 일반적인 엔터프라이즈 기능을 추가하는 데 사용됩니다.
• Azure AI Search는 전체 텍스트 검색, 의미 체계 검색, 벡터 검색 및 하이브리드 검색을 지원하는 클라우드 검색 서비스입니다. Azure AI Search는 채팅 애플리케이션 뒤의 흐름에서 사용되는 일반적인 서비스이므로 아키텍처에 포함됩니다. Azure AI Search를 사용하여 사용자 쿼리와 관련된 데이터를 검색하고 인덱싱할 수 있습니다. 프롬프트 흐름은 RAG 패턴 검색 증강 생성 을 구현하여 프롬프트에서 적절한 쿼리를 추출하고, AI Search를 쿼리하고, 결과를 Azure OpenAI 모델의 접지 데이터로 사용합니다.

Azure Machine Learning 프롬프트 흐름

엔터프라이즈 채팅 애플리케이션의 백 엔드는 일반적으로 다음 흐름과 유사한 패턴을 따릅니다.

• 사용자가 UI(사용자 지정 채팅 사용자 인터페이스)에 프롬프트를 입력합니다.
• 해당 프롬프트는 인터페이스 코드에 의해 백 엔드로 전송됩니다.
• 백 엔드에 의해 프롬프트에서 사용자 의도(질문 또는 지시문)가 추출됩니다.
• (선택 사항) 백 엔드는 사용자 프롬프트와 관련된 데이터를 보유하는 데이터 저장소를 결정합니다.
• 백 엔드는 관련 데이터 저장소를 쿼리합니다.
• 백 엔드는 의도, 관련 접지 데이터 및 프롬프트에 제공된 모든 기록을 LLM에 보냅니다.
• 백 엔드는 결과를 반환하여 사용자 인터페이스에 표시할 수 있도록 합니다.

백 엔드는 다양한 언어로 구현되고 다양한 Azure 서비스에 배포될 수 있습니다. 이 아키텍처에서 Azure Machine Learning 프롬프트 흐름은 프롬프트, 백 엔드 데이터 저장소 및 LLM 간에 오케스트레이션되는 흐름을 빌드, 테스트 및 배포하는 간소화된 환경을 제공하기 때문에 선택되었습니다.

네트워킹

ID 기반 액세스와 함께 네트워크 보안은 OpenAI를 사용하는 기본 엔드 투 엔드 채팅 아키텍처의 핵심입니다. 높은 수준에서 네트워크 아키텍처는 다음을 보장합니다.

• 채팅 UI 트래픽에 대한 단일 보안 진입점
• 네트워크 트래픽이 필터링됨
• 전송 중인 데이터는 TLS를 사용하여 엔드투엔드로 암호화됩니다.
• Private Link를 사용하여 Azure에서 트래픽을 유지하여 데이터 반출을 최소화합니다.
• 네트워크 리소스는 네트워크 분할을 통해 논리적으로 그룹화되고 서로 격리됩니다.

네트워크 흐름

그림 2: OpenAI를 사용하는 기본 엔드 투 엔드 채팅 아키텍처에 대한 네트워크 흐름

이 다이어그램의 두 흐름은 기준 앱 서비스 웹 애플리케이션에서 다룹니다. 1. 최종 사용자에서 채팅 UI 및 2로의 인바운드 흐름입니다. App Service에서 Azure PaaS 서비스로의 흐름입니다. 해당 흐름에 대한 자세한 내용은 해당 문서를 참조하세요. 이 섹션에서는 Azure Machine Learning 온라인 엔드포인트 흐름에 중점을 둡니다. 다음은 기준 App Service 웹 애플리케이션에서 실행되는 채팅 UI에서 Azure Machine Learning 컴퓨팅에 배포된 흐름으로의 흐름을 자세히 설명합니다.

1. App Service 호스팅 채팅 UI의 호출은 프라이빗 엔드포인트를 통해 Azure Machine Learning 온라인 엔드포인트로 라우팅됩니다.
2. 온라인 엔드포인트는 배포된 흐름을 실행하는 서버로 호출을 라우팅합니다. 온라인 엔드포인트는 부하 분산 장치 및 라우터의 역할을 모두합니다.
3. 배포된 흐름에 필요한 Azure PaaS 서비스에 대한 호출은 관리형 프라이빗 엔드포인트를 통해 라우팅됩니다.

Azure Machine Learning으로 수신

이 아키텍처에서는 Azure Machine Learning 작업 영역에 대한 공용 액세스가 사용되지 않으며 Azure Machine Learning 작업 영역 구성에 대한 프라이빗 엔드포인트를 따르는 프라이빗 액세스를 통해 액세스가 발생할 수 있습니다. 실제로 프라이빗 엔드포인트는 ID 기반 보안을 보완하기 위해 이 아키텍처 전체에서 사용됩니다. 예를 들어 App Service에서 호스트되는 채팅 UI가 Azure Machine Learning 엔드포인트를 포함하여 공용 인터넷에 노출되지 않는 PaaS 서비스에 연결할 수 있도록 허용합니다.

흐름 작성을 위해 Azure Machine Learning 작업 영역에 연결하는 데도 프라이빗 엔드포인트 액세스가 필요합니다.

그림 3: Azure Machine Learning 프롬프트 흐름 작성자를 위한 네트워크 흐름

다이어그램은 Azure Bastion을 통해 가상 머신 점프 상자에 연결하는 프롬프트 흐름 작성자를 보여줍니다. 이 점프 상자에서 작성자가 점프 상자와 동일한 네트워크의 프라이빗 엔드포인트를 통해 Machine Learning 작업 영역에 연결할 수 있습니다. 가상 네트워크에 대한 커넥트 작업은 ExpressRoute 또는 VPN 게이트웨이 및 가상 네트워크 피어링을 통해 수행할 수도 있습니다.

Azure Machine Learning 관리형 가상 네트워크에서 Azure PaaS 서비스로 흐름

모든 아웃바운드 연결을 승인해야 하는 구성을 사용하여 관리형 가상 네트워크 격리를 위해 Azure Machine Learning 작업 영역을 구성하는 것이 좋습니다. 이 아키텍처는 해당 권장 사항을 따릅니다. 승인된 아웃바운드 규칙에는 두 가지 유형이 있습니다. 필요한 아웃바운드 규칙은 솔루션이 작동하는 데 필요한 리소스(예: Azure Container Registry 및 Azure Storage)에 대한 것입니다. 사용자 정의 아웃바운드 규칙은 워크플로에서 사용할 Azure OpenAI 또는 Azure AI Search와 같은 사용자 지정 리소스에 대한 것입니다. 관리형 가상 네트워크를 만들 때 필요한 아웃바운드 규칙이 구성되는 동안 사용자 정의 아웃바운드 규칙을 구성하는 것은 사용자의 책임입니다.

아웃바운드 규칙은 외부 퍼블릭 엔드포인트에 대한 프라이빗 엔드포인트, 서비스 태그 또는 FQDN일 수 있습니다. 이 아키텍처에서는 Azure Container Registry, Azure Storage, Azure Key Vault, Azure OpenAI 서비스 및 Azure AI Search와 같은 Azure 서비스에 대한 연결이 프라이빗 링크를 통해 연결됩니다. 이 아키텍처에는 없지만 FQDN 아웃바운드 규칙을 구성해야 하는 몇 가지 일반적인 작업은 pip 패키지를 다운로드하고 GitHub 리포지토리를 복제하며 외부 리포지토리에서 기본 컨테이너 이미지를 다운로드하는 것입니다.

가상 네트워크 세분화 및 보안

이 아키텍처의 네트워크에는 다음과 같은 별도의 서브넷이 있습니다.

• Application Gateway
• App Service 통합 구성 요소
• 프라이빗 엔드포인트
• Azure Bastion
• 점프 상자 가상 머신
• 학습 - 이 아키텍처에서 모델 학습에 사용되지 않음
• 점수 매기기

각 서브넷에는 해당 서브넷의 인바운드 및 아웃바운드 트래픽을 모두 필요한 것으로 제한하는 네트워크 보안 그룹이 있습니다. 다음 표에서는 기준이 각 서브넷에 추가하는 NSG 규칙의 간소화된 보기를 보여 줍니다. 테이블은 규칙 이름과 함수를 제공합니다.

다른 모든 트래픽은 명시적으로 거부됩니다.

가상 네트워크 세분화 및 보안을 구현할 때 다음 사항을 고려합니다.

• 공용 IP를 사용하는 애플리케이션 게이트웨이의 일부인 서브넷을 사용하여 가상 네트워크에 대해 DDoS 보호를 사용하도록 설정합니다.
• 가능한 경우 모든 서브넷에 NSG 를 추가합니다. 전체 솔루션 기능을 사용하도록 설정하는 가장 엄격한 규칙을 사용해야 합니다.
• 애플리케이션 보안 그룹을 사용합니다. 애플리케이션 보안 그룹을 사용하면 NSG를 그룹화하여 복잡한 환경에서 규칙을 더 쉽게 만들 수 있습니다.

콘텐츠 필터링 및 남용 모니터링

Azure OpenAI 서비스에는 분류 모델의 앙상블을 사용하여 입력 프롬프트와 출력 완성 모두에서 잠재적으로 유해한 콘텐츠의 특정 범주를 감지하고 방지하는 콘텐츠 필터링 시스템이 포함되어 있습니다. 이 잠재적으로 유해한 콘텐츠의 범주에는 증오, 성적, 자해, 폭력, 욕설 및 탈옥(LLM의 제약을 우회하도록 설계된 콘텐츠)이 포함됩니다. 낮음, 중간 또는 높음 옵션을 사용하여 각 범주에 대한 콘텐츠를 필터링하려는 항목의 엄격성을 구성할 수 있습니다. 이 참조 아키텍처는 엄격한 접근 방식을 채택합니다. 요구 사항에 따라 설정을 조정해야 합니다.

Azure OpenAI 서비스는 콘텐츠 필터링 외에도 남용 모니터링 기능을 구현합니다. 남용 모니터링은 Azure OpenAI 행동 강령을 위반할 수 있는 방식으로 서비스 사용을 제안하는 반복 콘텐츠 및/또는 동작의 인스턴스를 감지하고 완화하도록 설계된 비동기 작업입니다. 데이터가 매우 민감하거나 내부 정책 또는 남용 탐지를 위한 데이터 처리를 방지하는 관련 법적 규정이 있는 경우와 같이 남용 모니터링 및 사용자 검토의 예외를 요청할 수 있습니다.

안정성

기준 App Service 웹 애플리케이션 아키텍처는 주요 지역 서비스에 대한 영역 중복성에 중점을 둡니다. 가용성 영역은 지역 내에서 물리적으로 분리된 위치입니다. 둘 이상의 인스턴스가 배포될 때 서비스를 지원하기 위해 지역 내에서 중복성을 제공합니다. 한 영역이 가동 중지 시간을 경험하는 경우 지역 내의 다른 영역은 여전히 영향을 받지 않을 수 있습니다. 또한 아키텍처를 통해 Azure 서비스의 인스턴스를 충분히 확보하고 해당 서비스의 구성을 가용성 영역에 분산할 수 있습니다. 해당 지침을 검토하려면 기준을 참조하세요.

이 섹션에서는 Azure Machine Learning, Azure OpenAI 및 Azure AI Search를 포함하여 App Service 기준에서 다루지 않는 이 아키텍처의 구성 요소 관점에서 안정성을 다룹니다.

흐름 배포에 대한 영역 중복성

엔터프라이즈 배포에는 일반적으로 최소한 영역 중복이 필요합니다. Azure에서 이를 달성하려면 리소스가 가용성 영역을 지원해야 하며, 인스턴스 제어를 사용할 수 없는 경우 리소스 인스턴스 이상을 배포하거나 플랫폼 지원을 사용하도록 설정해야 합니다. 현재 Azure Machine Learning 컴퓨팅은 가용성 영역에 대한 지원을 제공하지 않습니다. AML 구성 요소에 대한 데이터 센터 수준 재해의 잠재적 영향을 완화하려면 부하 분산 장치를 배포하여 이러한 클러스터 간에 호출을 분산하는 작업과 함께 다양한 지역에 클러스터를 설정해야 합니다. 상태 검사 사용하여 호출이 제대로 작동하는 클러스터로만 라우팅되도록 합니다.

프롬프트 흐름 배포는 Azure Machine Learning 컴퓨팅 클러스터로 제한되지 않습니다. 컨테이너화된 애플리케이션인 실행 흐름은 컨테이너와 호환되는 모든 Azure 서비스에 배포할 수 있습니다. 이러한 옵션에는 AKS(Azure Kubernetes Service), Azure Functions, ACA(Azure Container Apps) 및 Azure 앱 Service와 같은 서비스가 포함됩니다. 이러한 각 서비스는 가용성 영역을 지원합니다. 다중 지역 배포의 복잡성을 추가하지 않고 프롬프트 흐름 실행을 위한 영역 중복성을 달성하려면 해당 서비스 중 하나에 흐름을 배포해야 합니다.

다음은 프롬프트 흐름이 Azure 앱 Service에 배포되는 대체 아키텍처입니다. App Service는 워크로드가 이미 채팅 UI에 사용하고 있으며 워크로드에 새로운 기술을 도입하는 이점을 활용하지 못하기 때문에 이 아키텍처에서 사용됩니다. AKS 경험이 있는 워크로드 팀은 특히 AKS가 워크로드의 다른 구성 요소에 사용되는 경우 해당 환경에 배포하는 것을 고려해야 합니다.

그림 4: Azure 앱 Services에 프롬프트 흐름을 배포하는 OpenAI를 사용하는 대체 엔드 투 엔드 채팅 아키텍처

다이어그램은 이 아키텍처에서 주목할 만한 영역에 대해 번호가 매겨집니다.

1. 흐름은 여전히 Azure Machine Learning 프롬프트 흐름에서 작성되며 Azure Machine Learning 네트워크 아키텍처는 변경되지 않습니다. 흐름 작성자는 여전히 프라이빗 엔드포인트를 통해 작업 영역 작성 환경에 연결하며, 관리형 프라이빗 엔드포인트는 흐름을 테스트할 때 Azure 서비스에 연결하는 데 사용됩니다.
2. 이 점선은 컨테이너화된 실행 파일 흐름이 ACR(Azure Container Registry)에 푸시됨을 나타냅니다. 다이어그램에 표시되지 않는 파이프라인은 흐름을 컨테이너화하고 ACR로 푸시합니다.
3. 이미 채팅 UI를 호스팅하는 동일한 App Service 계획에 배포된 다른 웹앱이 있습니다. 새 웹앱은 컨테이너화된 프롬프트 흐름을 호스트하며, 이미 최소 3개의 인스턴스에서 실행되는 동일한 App Service 계획에 배치되어 가용성 영역에 분산되어 있습니다. 이러한 App Service 인스턴스는 프롬프트 흐름 컨테이너 이미지를 로드할 때 프라이빗 엔드포인트를 통해 ACR에 연결됩니다.
4. 프롬프트 흐름 컨테이너는 흐름 실행을 위해 모든 종속 서비스에 연결해야 합니다. 이 아키텍처에서는 Azure AI Search 및 Azure OpenAI 서비스에 적용됩니다. AML 관리형 프라이빗 엔드포인트 서브넷에만 노출된 PaaS 서비스도 이제 가상 네트워크에 노출되어야 App Service에서 시야를 설정할 수 있습니다.

Azure OpenAI - 안정성

Azure OpenAI는 현재 가용성 영역을 지원하지 않습니다. Azure OpenAI의 모델 배포에 대한 데이터 센터 수준 재해의 잠재적 영향을 완화하려면 Azure OpenAI를 다양한 지역에 배포하고 부하 분산 장치를 배포하여 지역 간에 호출을 분산해야 합니다. 상태 검사 사용하여 호출이 제대로 작동하는 클러스터로만 라우팅되도록 합니다.

여러 인스턴스를 효과적으로 지원하려면 지역 중복 Azure Storage 계정과 같은 미세 조정 파일을 외부화하는 것이 좋습니다. 이렇게 하면 지역당 Azure OpenAI 서비스에 저장된 상태가 최소화됩니다. 모델 배포를 호스트하려면 인스턴스별로 미세 조정을 수행해야 합니다.

TPM(분당 토큰) 및 RPM(분당 요청) 측면에서 필요한 처리량을 모니터링하여 배포 수요를 충족하고 배포된 모델에 대한 호출이 제한되지 않도록 할당량에서 충분한 TPM을 할당했는지 확인해야 합니다. APIM(Azure API Management)과 같은 게이트웨이는 OpenAI 서비스 앞에 배포할 수 있으며 일시적인 오류 및 제한 시 다시 시도하도록 구성할 수 있습니다. APIM을 회로 차단기로 사용하여 서비스가 호출에 과부하가 걸리는 것을 방지하여 할당량을 초과할 수도 있습니다.

Azure AI Search - 안정성

가용성 영역을 지원하는 지역에 표준 가격 책정 계층 이상을 사용하여 Azure AI Search를 배포하고 3개 이상의 복제본(replica) 배포합니다. 복제본(replica) 가용성 영역에 균등하게 자동으로 분산됩니다.

적절한 수의 복제본(replica) 및 파티션을 결정하기 위한 다음 지침을 고려합니다.

• 지침에 따라 Azure AI Search를 모니터링합니다.
• 모니터링 메트릭 및 로그 및 성능 분석을 사용하여 적절한 수의 복제본(replica) 확인하여 인덱스 기반 제한을 방지하기 위해 쿼리 기반 제한 및 파티션을 방지합니다.

Azure Machine Learning - 안정성

Azure Machine Learning 관리형 온라인 엔드포인트 뒤에 있는 컴퓨팅 클러스터에 배포하는 경우 크기 조정에 대한 다음 지침을 고려합니다.

• 지침에 따라 온라인 엔드포인트의 크기를 자동으로 조정하여 수요를 충족하기에 충분한 용량을 사용할 수 있는지 확인합니다. 버스트 사용으로 인해 사용 신호가 적시에 충분하지 않은 경우 너무 적은 수의 인스턴스에서 안정성 영향을 방지하기 위해 과잉 프로비전을 고려합니다.
• CPU 로드 및 요청 대기 시간과 같은 엔드포인트 메트릭과 같은 배포 메트릭을 기반으로 크기 조정 규칙을 만드는 것이 좋습니다.
• 활성 프로덕션 배포를 위해 3개 이하의 인스턴스를 배포해야 합니다.
• 사용 중인 인스턴스에 대한 배포를 방지합니다. 대신 새 배포에 배포하고 배포가 트래픽을 수신할 준비가 된 후 트래픽을 전환합니다.

보안

이 아키텍처는 네트워크와 ID 보안 경계를 모두 구현합니다. 네트워크 관점에서 인터넷에서 액세스할 수 있어야 하는 유일한 것은 App Gateway를 통한 채팅 UI입니다. ID 관점에서 채팅 UI는 요청을 인증하고 권한을 부여해야 합니다. 관리 ID는 가능한 경우 Azure 서비스에 애플리케이션을 인증하는 데 사용됩니다.

네트워킹 섹션에서 네트워크 보안에 대해 설명했습니다. 이 섹션에서는 ID 및 액세스 관리, 키 회전 및 Azure OpenAI 모델 미세 조정에 대한 보안 고려 사항에 대해 설명합니다.

ID 및 액세스 관리

다음 지침은 App Service 기준에서 ID 및 액세스 관리 지침을 확장합니다.

• 해당하는 경우 다음 AML 리소스에 대해 별도의 관리 ID를 만듭니다.
  • 작업 영역 - 흐름 작성 및 관리 중에 사용됨
  • 컴퓨팅 인스턴스 - 흐름을 테스트할 때 사용됨
  • 온라인 엔드포인트 - 관리되는 온라인 엔드포인트에 배포된 경우 배포된 흐름에서 사용됩니다.
• Microsoft Entra ID를 사용하여 채팅 UI에 대한 ID 액세스 제어 구현

Azure Machine Learning RBAC 역할

Azure Machine Learning 작업 영역에 대한 액세스를 관리하는 데 사용할 수 있는 기본 역할은 AzureML 데이터 과학자, AzureML Compute 연산자, 읽기 권한자, 기여자 및 소유자입니다. 이러한 기본 역할과 함께 AzureML 작업 영역 커넥트ion 비밀 읽기 권한자 및 작업 영역 비밀 및 레지스트리와 같은 작업 영역 리소스에 대한 액세스 권한을 부여하는 AzureML 레지스트리 사용자가 있습니다.

이 아키텍처는 필요한 위의 ID에만 역할을 할당하여 최소 권한 원칙을 따릅니다. 다음은 역할 할당입니다.

키 순환

이 아키텍처에는 키 기반 인증을 사용하는 두 가지 서비스인 Azure OpenAI와 Azure Machine Learning 관리형 온라인 엔드포인트가 있습니다. 이러한 서비스에 키 기반 인증을 사용하므로 다음을 수행해야 합니다.

• 권한 있는 클라이언트(예: 프롬프트 흐름 컨테이너를 호스팅하는 Azure Web App)의 주문형 액세스를 위해 Azure Key Vault와 같은 보안 저장소에 키를 저장합니다.
• 키 회전 전략을 구현합니다. 키를 수동으로 회전하는 경우 키 만료 정책을 만들고 Azure 정책을 사용하여 키가 회전되었는지 여부를 모니터링해야 합니다.

OpenAI 모델 미세 조정

구현에서 OpenAI 모델을 미세 조정하는 경우 다음 지침을 고려합니다.

• 미세 조정을 위해 학습 데이터를 업로드하는 경우 고객 관리형 키를 사용하여 해당 데이터를 암호화하는 것이 좋습니다.
• Azure Blob Storage와 같은 저장소에 학습 데이터를 저장하는 경우 데이터 암호화에 고객 관리 키를 사용하고, 관리 ID를 사용하여 데이터에 대한 액세스를 제어하고, 프라이빗 엔드포인트를 사용하여 데이터에 연결하는 것이 좋습니다.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.

이 섹션에서는 Azure Search, Azure OpenAI 및 Azure Machine Learning의 관점에서 성능 효율성에 대해 설명합니다.

Azure Search - 성능 효율성

지침 에 따라 Azure AI Search의 성능을 분석합니다.

Azure OpenAI - 성능 효율성

• 애플리케이션에 프로비전된 처리량이 필요한지 또는 공유 호스팅(소비) 모델을 사용할지 여부를 결정합니다. 프로비전된 처리량은 OpenAI 모델 배포를 위한 예약된 처리 용량을 제공하여 모델에 대한 예측 가능한 성능과 처리량을 제공합니다. 이 청구 모델은 공유 호스팅(소비) 모델과는 달리 최선의 노력이며, 플랫폼에서 시끄러운 이웃 또는 기타 스트레스 요인의 영향을 받을 수 있습니다.
• 프로비전된 처리량의 경우 프로비전 관리 사용률을 모니터링 해야 합니다.

Azure Machine Learning - 성능 효율성

Azure Machine Learning 온라인 엔드포인트에 배포하는 경우:

• 특히 사용량이 적은 기간에 과도한 과잉 프로비전 없이 온라인 엔드포인트를 자동 크기 조정하여 수요에 밀접하게 부합하는 방법에 대한 지침을 따릅니다.
• 성능 목표를 충족하기 위해 온라인 엔드포인트에 적합한 가상 머신 SKU를 선택합니다. 최적의 구성을 찾기 위해 더 낮은 인스턴스 수와 더 큰 SKU 및 더 큰 인스턴스 수 및 더 작은 SKU의 성능을 테스트하려고 합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

이 시나리오에 대한 가격 책정 예제를 보려면 Azure 가격 계산기를 사용합니다. 이 예제에서는 아키텍처에 포함된 구성 요소만 포함하므로 사용량과 일치하도록 예제를 사용자 지정해야 합니다. 시나리오에서 가장 비용이 많이 드는 구성 요소는 채팅 UI 및 프롬프트 흐름 컴퓨팅 및 Azure AI Search이므로 가장 많은 비용을 절약하기 위해 해당 리소스에 대한 최적화를 살펴봅니다.

컴퓨팅

Azure Machine Learning 프롬프트 흐름은 실행 파일을 호스트하는 여러 옵션을 지원합니다. 옵션에는 Azure Machine Learning, Azure Kubernetes Service, Azure 앱 Service 및 Azure Container Service의 관리형 온라인 엔드포인트가 포함됩니다. 이러한 각 옵션에는 고유한 청구 모델이 있습니다. 컴퓨팅 선택은 솔루션의 전체 비용에 영향을 줍니다.

Azure OpenAI

Azure OpenAI는 소비 기반 서비스이며, 소비 기반 서비스와 마찬가지로 공급에 대한 수요를 제어하는 것이 기본 비용 제어입니다. 특히 Azure OpenAI 서비스에서 이 작업을 수행하려면 다음과 같은 방법을 조합하여 사용해야 합니다.

• 클라이언트를 제어합니다. 클라이언트 요청은 소비 모델의 기본 비용 원본입니다. 따라서 클라이언트 동작을 제어하는 것이 중요합니다. 모든 클라이언트는 다음을 수행해야 합니다.
  • 승인을 받아야 합니다. 무료 액세스를 지원하는 방식으로 서비스를 노출하지 않도록 합니다. 네트워크 및 ID 컨트롤(키 또는 RBAC)을 통해 액세스를 제한합니다.
  • 자체 제어해야 합니다. 클라이언트가 API 호출에서 제공하는 토큰 제한 제약 조건(예: max_tokens 및 max_completions)을 사용하도록 요구합니다.
  • 실용적 일괄 처리를 사용합니다. 클라이언트를 검토하여 프롬프트를 적절하게 일괄 처리하고 있는지 확인합니다.
  • 프롬프트 입력 및 응답 길이를 최적화합니다. 프롬프트가 길어질수록 더 많은 토큰이 사용되어 비용이 발생하지만 충분한 컨텍스트가 누락된 프롬프트는 모델이 좋은 결과를 생성하는 데 도움이 되지 않습니다. 모델이 유용한 응답을 생성할 수 있도록 충분한 컨텍스트를 제공하는 간결한 프롬프트를 만듭니다. 마찬가지로 응답 길이 제한을 최적화해야 합니다.
• Azure OpenAI 플레이그라운드 사용량은 필요에 따라 사전 프로덕션 인스턴스에 있어야 하므로 이러한 활동으로 인해 프로덕션 비용이 발생하지 않습니다.
• 올바른 AI 모델을 선택합니다. 모델 선택은 Azure OpenAI의 전체 비용에서도 큰 역할을 합니다. 모든 모델에는 강점과 약점이 있으며 개별적으로 가격이 책정됩니다. 사용 사례에 올바른 모델을 사용하면 저렴한 모델이 허용 가능한 결과를 생성할 때 더 비싼 모델에 과도하게 지출하지 않도록 할 수 있습니다. 이 채팅 참조 구현에서 GPT 3.5 터보는 충분한 결과를 달성하면서 모델 배포 비용의 크기를 절약하기 위해 GPT-4를 통해 선택되었습니다.
• 청구 중단점 이해 - 미세 조정은 시간당 요금이 청구됩니다. 가장 효율적이려면 시간당 사용 가능한 시간을 최대한 활용하여 다음 청구 기간으로 넘어가지 않도록 하면서 미세 조정 결과를 개선하는 것이 좋습니다. 마찬가지로 이미지 생성에서 이미지 100개에 대한 비용은 이미지 1개에 대한 비용과 동일합니다. 가격 브레이크 포인트를 최대화하여 이점을 얻을 수 있습니다.
• 청구 모델 이해 - Azure OpenAI는 프로비전된 처리량 제품을 통해 약정 기반 청구 모델에서도 사용할 수 있습니다. 예측 가능한 사용 패턴이 있으면 사용량량에서 비용 효율적인 것으로 계산되는 경우 이 사전 청구 모델로의 전환을 평가합니다.
• 프로비저닝 제한 설정 - 모든 프로비저닝 할당량이 모델별로 워크로드의 일부가 될 것으로 예상되는 모델에만 할당되었는지 확인합니다. 동적 할당량을 사용하는 동안 이미 배포된 모델에 대한 처리량은 프로비전된 할당량으로 제한되지 않습니다. 할당량은 비용에 직접 매핑되지 않으며 비용은 다를 수 있습니다.
• 종량제 사용량 모니터링 - 종량제 사용을 사용하는 경우 TPM(분당 토큰) 및 RPM(분당 요청)의 사용량을 모니터링합니다. 이 정보를 사용하여 사용할 모델과 같은 아키텍처 디자인 결정을 알리고 프롬프트 크기를 최적화합니다.
• 프로비저닝된 처리량 사용량 모니터링 - 프로비전된 처리량을 사용하는 경우 프로비전 관리 사용률을 모니터링하여 구입한 프로비전된 처리량을 활용하지 않도록 합니다.
• 비용 관리 - OpenAI에서 비용 관리 기능을 사용하여 비용을 모니터링하고, 예산을 설정하여 비용을 관리하고, 관련자에게 위험 또는 변칙을 알리는 경고를 만드는 방법에 대한 지침을 따릅니다.

대규모 언어 모델 작업(LLMOps)

이 아키텍처와 같은 Azure OpenAI 기반 채팅 솔루션에 대한 배포는 Azure DevOps 및 GitHub를 사용하는 프롬프트 흐름이 있는 LLMOps의 지침을 따라야 합니다. 또한 CI/CD 및 네트워크 보안 아키텍처에 대한 모범 사례를 고려해야 합니다. 다음 지침에서는 LLMOps 권장 사항에 따라 흐름 및 관련 인프라의 구현을 다룹니다. 이 배포 지침에는 사용 가능한 기준 영역 중복 웹 애플리케이션 아키텍처에서 변경되지 않은 프런트 엔드 애플리케이션 요소가 포함되지 않습니다.

개발

Azure Machine Learning 프롬프트 흐름은 Azure Machine Learning 스튜디오 또는 VS Code 확장을 통해 브라우저 기반 제작 환경을 모두 제공합니다. 두 옵션 모두 흐름 코드를 파일로 저장합니다. Azure Machine Learning 스튜디오 사용하는 경우 파일은 Azure Storage 계정에 저장됩니다. VS Code에서 작업할 때 파일은 로컬 파일 시스템에 저장됩니다.

공동 개발 모범 사례를 따르려면 GitHub와 같은 온라인 소스 코드 리포지토리에서 원본 파일을 기본 파악해야 합니다. 이 방법을 사용하면 모든 코드 변경 내용 추적, 흐름 작성자 간의 공동 작업 및 모든 코드 변경 내용을 테스트하고 유효성을 검사하는 배포 흐름과의 통합을 쉽게 추적할 수 있습니다.

엔터프라이즈 개발의 경우 VS Code 확장 및 프롬프트 흐름 SDK/CLI 를 개발에 사용해야 합니다. 프롬프트 흐름 작성자는 VS Code에서 흐름을 빌드 및 테스트하고 로컬로 저장된 파일을 온라인 소스 제어 시스템 및 파이프라인과 통합할 수 있습니다. 브라우저 기반 환경은 예비 개발에 적합하지만 일부 작업에서는 소스 제어 시스템과 통합할 수 있습니다. 흐름 폴더는 패널의 흐름 페이지에서 다운로드하고 압축을 Files 풀고 소스 제어 시스템으로 푸시할 수 있습니다.

평가

다른 소프트웨어 아티팩트를 테스트하는 것처럼 채팅 애플리케이션에서 사용되는 흐름을 테스트해야 합니다. LLM 출력에 대해 단일 "올바른" 답변을 지정하고 어설션하는 것은 어려운 일이지만 LLM 자체를 사용하여 응답을 평가할 수 있습니다. LLM 흐름에 대한 다음과 같은 자동화된 평가를 구현하는 것이 좋습니다.

• 분류 정확도: LLM이 "올바른" 또는 "잘못된" 점수를 제공하는지 여부를 평가하고 결과를 집계하여 정확도 등급을 생성합니다.
• 일관성: 모델의 예측 답변에 있는 문장이 얼마나 잘 쓰여지고 서로 일관되게 연결되는지 평가합니다.
• 유창성: 문법 및 언어 정확도에 대한 모델의 예측 답변을 평가합니다.
• 컨텍스트에 대한 근거: 미리 구성된 컨텍스트를 기반으로 모델의 예측 답변이 얼마나 잘 계산되는지 평가합니다. LLM의 응답이 정확하더라도 지정된 컨텍스트에 대해 유효성을 검사할 수 없는 경우 이러한 응답은 접지되지 않습니다.
• 관련성: 모델의 예측 답변이 질문과 얼마나 잘 일치하는지 평가합니다.

자동화된 평가를 구현할 때 다음 지침을 고려합니다.

• 평가에서 점수를 생성하고 미리 정의된 성공 임계값에 대해 측정합니다. 이러한 점수를 사용하여 파이프라인에서 테스트 통과/실패를 보고합니다.
• 이러한 테스트 중 일부는 질문, 컨텍스트 및 지상 진리의 미리 구성된 데이터 입력이 필요합니다.
• 테스트 결과가 신뢰할 수 있도록 충분한 질문-답변 쌍을 포함하며, 최소 100-150쌍이 권장됩니다. 이러한 질문-답변 쌍을 "골든 데이터 세트"라고 합니다. 데이터 세트의 크기와 기본 따라 더 많은 모집단이 필요할 수 있습니다.
• LLM을 사용하여 골든 데이터 세트의 데이터를 생성하지 않도록 합니다.

배포 흐름

그림 5: 프롬프트 흐름 배포

1. 프롬프트 엔지니어/데이터 과학자는 특정 작업 또는 기능에서 작업하는 기능 분기 엽니다. 프롬프트 엔지니어/데이터 과학자는 VS Code용 프롬프트 흐름을 사용하여 흐름을 반복하고 주기적으로 변경 내용을 커밋하고 해당 변경 내용을 기능 분기 푸시합니다.

2. 로컬 개발 및 실험이 완료되면 프롬프트 엔지니어/데이터 과학자가 기능 분기에서 기본 분기로 끌어오기 요청을 엽니다. PR(끌어오기 요청)은 PR 파이프라인을 트리거합니다. 이 파이프라인은 다음을 포함해야 하는 빠른 품질 검사 실행합니다.

   • 실험 흐름 실행
   • 구성된 단위 테스트 실행
   • 코드베이스 컴파일
   • 정적 코드 분석

3. 파이프라인에는 병합하기 전에 하나 이상의 팀 구성원이 PR을 수동으로 승인해야 하는 단계가 포함될 수 있습니다. 승인자는 커밋자가 될 수 없으며 프롬프트 흐름 전문 지식과 프로젝트 요구 사항에 대한 지식이 있습니다. PR이 승인되지 않으면 병합이 차단됩니다. PR이 승인되었거나 승인 단계가 없는 경우 기능 분기 주 분기에 병합됩니다.

4. Main에 병합하면 개발 환경에 대한 빌드 및 릴리스 프로세스가 트리거됩니다. 특히 다음에 대해 주의하세요.

   a. CI 파이프라인은 병합에서 Main으로 트리거됩니다. CI 파이프라인은 PR 파이프라인에서 수행된 모든 단계를 수행하고 다음 단계를 수행합니다.

   • 실험 흐름
   • 평가 흐름
   • 변경 내용이 검색되면 Azure Machine Learning 레지스트리에 흐름을 등록합니다.

   b. CD 파이프라인은 CI 파이프라인이 완료된 후 트리거됩니다. 이 흐름은 다음 단계를 수행합니다.

   • Azure Machine Learning 레지스트리에서 Azure Machine Learning 온라인 엔드포인트로 흐름을 배포합니다.
   • 온라인 엔드포인트를 대상으로 하는 통합 테스트를 실행합니다.
   • 온라인 엔드포인트를 대상으로 하는 스모크 테스트를 실행합니다.

5. 승인 프로세스는 릴리스 승격 프로세스에 기본 제공됩니다. 승인 시 CI 및 CD 프로세스는 4.a단계에서 설명합니다. &4.b.는 테스트 환경을 대상으로 반복됩니다. a. 및 b. 단계는 사용자 승인 테스트가 테스트 환경에서 스모크 테스트 후에 실행된다는 점을 제외하고 동일합니다.

6. 4.a단계에서 설명하는 CI 및 CD 프로세스 &4.b.는 테스트 환경을 확인하고 승인한 후 릴리스를 프로덕션 환경으로 승격하기 위해 실행됩니다.

7. 라이브 환경으로 릴리스된 후 성능 메트릭을 모니터링하고 배포된 LLM을 평가하는 운영 작업이 수행됩니다. 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.

   • 데이터 드리프트 검색
   • 인프라 관찰
   • 비용 관리
   • 관련자에게 모델의 성능 전달

배포 지침

Azure Machine Learning 엔드포인트를 사용하면 프로덕션에 릴리스할 때 유연성을 가능하게 하는 방식으로 모델을 배포할 수 있습니다. 최상의 모델 성능과 품질을 보장하려면 다음 전략을 고려하세요.

• 파란색/녹색 배포: 이 전략을 사용하면 모든 트래픽을 새 배포로 전달하기 전에 제한된 사용자 또는 요청 그룹에 새 버전의 웹 서비스를 안전하게 배포할 수 있습니다.
• A/B 테스트: Blue/Green 배포는 변경 내용을 안전하게 롤아웃하는 데 효과적일 뿐만 아니라 사용자의 하위 집합이 변경의 영향을 평가할 수 있는 새 동작을 배포하는 데도 사용할 수 있습니다.
• 파이프라인에서 프롬프트 흐름의 일부인 Python 파일의 린팅을 포함합니다. 스타일 표준, 오류, 코드 복잡성, 사용되지 않는 가져오기 및 변수 명명 준수를 위한 linting 검사.
• 네트워크 격리 Azure Machine Learning 작업 영역에 흐름을 배포할 때 자체 호스팅 에이전트를 사용하여 Azure 리소스에 아티팩트를 배포합니다.
• Azure Machine Learning 모델 레지스트리는 모델이 변경된 경우에만 업데이트해야 합니다.
• LLM, 흐름 및 클라이언트 UI를 느슨하게 결합해야 합니다. 흐름 및 클라이언트 UI에 대한 업데이트 모델에 영향을 주지 않고 만들 수 있으며 그 반대의 경우도 마찬가지입니다.
• 여러 흐름을 개발하고 배포할 때 각 흐름에는 자체 수명 주기가 있어야 하며, 이를 통해 실험에서 프로덕션으로 흐름을 승격할 때 느슨하게 결합된 환경을 사용할 수 있습니다.

인프라

기준 Azure OpenAI 엔드 투 엔드 채팅 구성 요소를 배포할 때 프로비전된 서비스 중 일부는 아키텍처 내에서 기본적이고 영구적인 반면, 다른 구성 요소는 본질적으로 더 임시적인 반면, 그 존재는 배포와 관련이 있습니다.

기본 구성 요소

이 아키텍처의 일부 구성 요소는 개별 프롬프트 흐름 또는 모델 배포를 넘어 확장되는 수명 주기와 함께 존재합니다. 이러한 리소스는 일반적으로 워크로드 팀에서 기본 배포의 일부로 한 번 배포되며, 프롬프트 흐름 또는 모델 배포에 대한 새 업데이트, 제거 또는 업데이트와는 별도로 기본.

• Azure Machine Learning 작업 영역
• Azure Machine Learning 작업 영역에 대한 Azure Storage 계정
• Azure Container Registry
• Azure AI 검색
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• 점프 상자용 Azure Virtual Machine

임시 구성 요소

일부 Azure 리소스는 특정 프롬프트 흐름의 디자인과 더 긴밀하게 결합되어 이러한 리소스를 구성 요소의 수명 주기에 바인딩하고 이 아키텍처에서 임시로 사용할 수 있습니다. 흐름이 추가 또는 제거되거나 새 모델이 도입될 때와 같이 워크로드가 진화할 때 영향을 받습니다. 이러한 리소스는 다시 만들어지고 이전 인스턴스는 제거됩니다. 이러한 리소스 중 일부는 직접 Azure 리소스이고 일부는 포함된 서비스 내의 데이터 평면 매니페스트입니다.

• 변경된 경우 Azure Machine Learning 모델 레지스트리의 모델을 CD 파이프라인의 일부로 업데이트해야 합니다.
• 컨테이너 이미지는 CD 파이프라인의 일부로 컨테이너 레지스트리에서 업데이트해야 합니다.
• Azure Machine Learning 엔드포인트는 배포가 존재하지 않는 엔드포인트를 참조하는 경우 프롬프트 흐름이 배포될 때 만들어집니다. 공용 액세스를 끄려면 해당 엔드포인트를 업데이트해야 합니다.
• 흐름이 배포되거나 삭제되면 Azure Machine Learning 엔드포인트의 배포가 업데이트됩니다.
• 새 엔드포인트를 만들 때 클라이언트 UI에 대한 Key Vault를 엔드포인트에 대한 키로 업데이트해야 합니다.

모니터링

진단은 모든 서비스에 대해 구성됩니다. Azure Machine Learning 및 Azure 앱 Service를 제외한 모든 서비스는 모든 로그를 캡처하도록 구성됩니다. Azure Machine Learning 진단 데이터와의 고객 상호 작용 또는 서비스 설정을 기록하는 모든 리소스 로그인 감사 로그를 캡처하도록 구성됩니다. Azure 앱 Service는 AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs 및 AppServicePlatformLogs를 캡처하도록 구성됩니다.

시나리오 배포

참조 구현을 배포하고 실행하려면 OpenAI 엔드 투 엔드 기준 참조 구현의 단계를 따릅니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

• Rob Bagby | 패턴 및 사례 - Microsoft
• 프레디 아얄라 | 클라우드 솔루션 설계자 - Microsoft
• Prabal Deb | 수석 소프트웨어 엔지니어 - Microsoft
• 라우프 알리우아트 | 소프트웨어 엔지니어 II - Microsoft
• Ritesh Modi | 수석 소프트웨어 엔지니어 - Microsoft
• Ryan Pfalz | 선임 솔루션 설계자 - Microsoft

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

Azure OpenAI에 대해 자세히 알아보기

관련 참고 자료

• Azure OpenAI
• Azure OpenAI 대규모 언어 모델
• Azure Machine Learning 프롬프트 흐름
• 작업 영역 관리형 가상 네트워크 격리
• Azure Machine Learning 작업 영역용 프라이빗 엔드포인트 구성
• 콘텐츠 필터링