다음을 통해 공유

게이트웨이를 통해 Azure OpenAI에 대한 고급 모니터링 구현

Azure AI 서비스
Azure OpenAI Service
Azure API Management
Microsoft Entra ID
Azure Monitor

Azure OpenAI 서비스를 포함하는 워크로드 모니터링은 Azure OpenAI에 대한 진단을 사용하도록 설정하고 미리 구성된 대시보드를 사용하는 것만큼 간단할 수 있습니다. 그러나 이 전략은 다음과 같은 생성형 AI 워크로드에 대한 몇 가지 일반적이고 복잡한 조직 모니터링 요구 사항을 충족하지 않습니다.

비고

Azure OpenAI를 직접 모니터링하는 방법에 대한 자세한 내용은 Azure OpenAI 모니터링을 참조하세요.

다음 다이어그램에서는 게이트웨이가 없는 Azure OpenAI 인스턴스의 모니터링을 보여 줍니다. 이 토폴로지에는 게이트웨이가 필요하지 않습니다. 게이트웨이를 포함할지 여부는 설명된 모니터링 시나리오가 요구 사항의 일부인지 여부에 따라 달라집니다. 이 문서에서는 각 모니터링 시나리오에서 해결할 수 있는 과제와 함께 각 시나리오에 대한 게이트웨이를 통합할 경우의 이점 및 비용을 살펴봅니다.

Azure OpenAI의 여러 인스턴스에서 둘 이상의 모델 배포에 직접 연결하는 여러 클라이언트가 있는 시나리오의 아키텍처 다이어그램입니다.

모델 사용 추적

많은 워크로드 또는 조직은 모든 Azure OpenAI 인스턴스에서 클라이언트와 모델 모두에서 Azure OpenAI 모델의 사용을 추적해야 합니다. 이 정보를 사용하여 다음을 수행합니다.

  • 사용 비용을 적절한 조직 또는 응용 프로그램 소유자에게 할당하는 차지백 시스템을 구현합니다.

  • 향후 사용량에 대한 예산 및 예측.

  • 모달 비용 및 사용량을 모델 성능에 연결합니다.

네이티브 Azure OpenAI 모니터링 기능을 사용하여 서비스의 원격 분석을 추적할 수 있지만 문제가 있습니다.

  • 차지백 모델의 경우 Azure OpenAI 토큰 사용 메트릭을 애플리케이션 또는 사업부와 연결할 수 있어야 합니다. Azure OpenAI 원격 분석에는 마지막 옥텟이 마스킹된 호출 IP 주소가 포함됩니다. 이 마스킹으로 인해 애플리케이션 또는 사업부에 대한 이 연결을 설정하는 것이 어려울 수 있습니다.

  • 다양한 지역의 Azure OpenAI 인스턴스는 해당 로컬 지역 내의 Azure Monitor 인스턴스에 로그를 기록할 수 있습니다. 이 프로세스를 수행하려면 모든 Azure OpenAI 인스턴스에서 사용량을 추적하기 위해 여러 Azure Monitor 인스턴스의 로그를 집계해야 합니다.

모델 사용량을 추적하는 게이트웨이 소개

게이트웨이를 통해 Azure OpenAI의 여러 인스턴스에서 둘 이상의 모델 배포에 연결하는 여러 클라이언트가 있는 시나리오의 아키텍처 다이어그램입니다.

이 토폴로지에 게이트웨이를 도입하여 전체 클라이언트 IP 주소, 클라이언트의 Microsoft Entra ID(또는 대체 ID) 또는 사업부, 테넌트 또는 애플리케이션에 대한 사용자 지정 식별자를 한 곳에서 캡처합니다. 그런 다음 이 데이터를 사용하여 예산 책정 및 예측을 위한 차지백 솔루션을 구현하고 모델의 비용 편익 분석을 수행할 수 있습니다.

다음 예제에서는 Azure API Management를 게이트웨이로 사용할 때 가능한 사용 쿼리를 보여 줍니다.

사용량 모니터링에 대한 예제 쿼리

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
    sum(todecimal(prompttokens)),
    sum(todecimal(completiontokens)),
    sum(todecimal(totaltokens)),
    avg(todecimal(totaltokens))
    by ip, model

출력:

사용량 모니터링의 출력을 보여 주는 스크린샷입니다.

프롬프트 사용 모니터링에 대한 예제 쿼리

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)

출력:

프롬프트 사용 모니터링의 출력을 보여주는 스크린샷입니다.

모델 입력 및 출력 감사Audit model inputs and outputs

생성 AI 워크로드에 대한 많은 감사 요구 사항의 핵심은 모델의 입력 및 출력을 모니터링하는 것입니다. 응답이 모델에서 온 것인지 캐시에서 가져온 것인지 알아야 할 수 있습니다. 모델의 입력과 출력을 모두 모니터링하기 위한 여러 사용 사례가 있습니다. 대부분의 시나리오에서는 감사 규칙이 입력과 출력 모두에 대해 모든 모델에 균일하게 적용되어야 합니다.

다음 사용 사례는 모델에 대한 입력을 모니터링하기 위한 것입니다.

  • 위협 감지: 입력을 분석하여 잠재적인 보안 위험을 식별하고 완화합니다.

  • 사용 지침 위반 감지: 불쾌감을 주는 언어 또는 기타 사용 표준에 대한 입력을 분석하여 시스템이 전문적이고 안전하며 편향되지 않았는지 확인합니다.

  • 모델 성능: 모델 출력과 결합하여 근거성 및 관련성과 같은 메트릭에 대한 성능을 평가합니다. 이 정보를 사용하여 모델 또는 프롬프트의 성능 문제를 해결할 수 있습니다.

다음은 모델에 대한 출력을 모니터링하기 위한 몇 가지 사용 사례입니다.

  • 데이터 유출 감지: 출력을 분석하여 민감한 정보의 무단 전송을 방지합니다.

  • 상태 저장 규정 준수: 동일한 대화 내의 여러 상호 작용에 대한 출력을 모니터링하여 민감한 정보의 은밀한 유출을 감지합니다.

  • 컴플라이언스: 출력이 기업 지침 및 규정 요구 사항을 준수하는지 확인합니다. 두 가지 예는 모델이 법률 자문을 제공하거나 재정적 약속을 하지 않는다는 것입니다.

  • 모델 성능: 모델 입력과 결합하여 근거성 및 관련성과 같은 메트릭에 대한 성능을 평가합니다. 이 정보를 사용하여 모델 또는 프롬프트의 성능 문제를 해결할 수 있습니다.

모델에서 직접 모델 입력 및 출력 감사에 대한 과제

  • 모델 로깅 제약 조건: Azure OpenAI와 같은 일부 서비스는 모델 입력 및 출력을 기록하지 않습니다.

  • 캐시: 더 복잡한 아키텍처는 캐시에서 응답을 제공할 수 있습니다. 이러한 시나리오에서는 모델이 호출되지 않으며 입력 또는 출력을 기록하지 않습니다.

  • 상태 저장 대화: 다중 상호 작용 대화의 상태는 모델 외부에 저장될 수 있습니다. 모델은 대화로 상관 관계를 지정해야 하는 상호 작용을 모릅니다.

  • 다중 모델 아키텍처: 오케스트레이션 계층은 최종 응답을 생성하기 위해 여러 모델을 동적으로 호출할 수 있습니다.

모델 입력 및 출력을 감사하기 위한 게이트웨이 소개

게이트웨이를 통해 Azure OpenAI의 여러 인스턴스에서 둘 이상의 모델 배포에 연결하는 여러 클라이언트가 있는 시나리오의 아키텍처 다이어그램입니다. 게이트웨이는 입력 및 출력을 기록합니다.

이 토폴로지에 게이트웨이를 도입하여 클라이언트에서 직접 원래 입력과 클라이언트로 반환되는 최종 출력을 모두 캡처합니다. 게이트웨이는 클라이언트와 모델 간의 추상화이며 클라이언트로부터 요청을 직접 수신하므로 게이트웨이는 처리되지 않은 원시 요청을 기록할 수 있는 위치에 있습니다. 마찬가지로 게이트웨이는 클라이언트에 최종 응답을 반환하는 리소스이기 때문에 해당 응답을 기록할 수도 있습니다.

게이트웨이에는 클라이언트의 요청과 수신된 최종 응답을 모두 기록하는 고유한 기능이 있습니다. 이 기능은 응답이 모델에서 직접 왔는지, 여러 모델에서 집계되었는지, 캐시에서 검색되었는지에 관계없이 적용됩니다. 또한 클라이언트가 대화 식별자를 전달하는 경우 게이트웨이는 입력 및 출력을 사용하여 해당 식별자를 기록할 수 있습니다. 이 구현을 사용하여 대화의 여러 상호 작용의 상관 관계를 지정할 수 있습니다.

게이트웨이에서 입력 및 출력을 모니터링하면 모든 모델에서 감사 규칙을 균일하게 적용할 수 있습니다.

근 실시간 모니터링

Azure Monitor는 로그 데이터 수집에 내재된 대기 시간으로 인해 거의 실시간 처리에 최적화되어 있지 않습니다. 솔루션에서 트래픽을 거의 실시간으로 처리해야 하는 경우 메시지 버스에 로그를 직접 게시하고 Azure Stream Analytics와 같은 스트림 처리 기술을 사용하여 창이 있는 작업을 수행하는 디자인을 고려할 수 있습니다.

게이트웨이를 통해 Azure OpenAI의 여러 인스턴스에서 둘 이상의 모델 배포에 연결하는 여러 클라이언트가 있는 시나리오의 아키텍처 다이어그램입니다. 게이트웨이는 입력 및 출력을 메시지 버스에 기록합니다.

모니터링을 위한 게이트웨이를 도입할 때 고려 사항

  • 숨어 있음: 아키텍처에 게이트웨이를 도입하면 응답에 대기 시간이 추가됩니다. 관찰 가능성의 이점이 성능에 미치는 영향보다 크도록 해야 합니다.

  • 보안 및 개인 정보 보호: 게이트웨이를 사용하여 수집된 모니터링 데이터가 고객 개인 정보 보호 기대치를 계속 준수하는지 확인합니다. 관찰 가능성 데이터는 워크로드의 설정된 보안 및 개인 정보 보호 기대치를 준수해야 하며 고객 개인 정보 보호 표준을 위반하지 않아야 합니다. 모니터링을 통해 캡처된 모든 민감한 데이터를 민감한 데이터로 계속 처리합니다.

  • 신뢰도: 모니터링 기능이 워크로드의 기능에 중요한지 여부를 확인합니다. 이 경우 모니터링 시스템을 사용할 수 없을 때 전체 응용 프로그램이 다운되어야 합니다. 중요하지 않은 경우 모니터링 시스템이 다운된 경우 애플리케이션은 모니터링되지 않는 상태에서 계속 작동해야 합니다. 게이트웨이에서 서비스 오류 또는 사람이 초래한 구성 문제를 통해 새로운 단일 실패 지점을 추가할 때의 위험을 이해합니다.

  • 이행: 구현은 필요한 모든 구성을 포함하여 API Management와 같은 기본 게이트웨이를 활용할 수 있습니다. 또 다른 일반적인 방법은 코드를 통해 오케스트레이션 계층을 구현하는 것입니다.

모니터링을 위해 게이트웨이를 도입하지 않는 이유

단일 애플리케이션이 단일 모델에 액세스하는 경우 게이트웨이 도입의 추가 복잡성이 모니터링의 이점보다 클 수 있습니다. 클라이언트는 입력 및 출력 로깅의 책임을 처리할 수 있습니다. 또한 사용하는 모델 또는 서비스의 기본 로깅 기능을 활용할 수 있습니다. 게이트웨이는 모니터링해야 하는 여러 클라이언트 또는 여러 모델이 있는 경우에 유용합니다.

다음 단계

워크로드에 대한 게이트웨이 구현은 이 문서에 설명된 전술적 다중 백 엔드 라우팅 이점 이상의 이점을 제공합니다. 자세한 내용은 게이트웨이를 통해 Azure OpenAI 및 기타 언어 모델에 액세스하는 것을 참조하세요.