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

이 문서에서는 AI 기능이 있는 애플리케이션을 만들 때 기술과 접근 방식을 결정할 때 고려해야 할 일반적인 디자인 영역 및 요인에 대해 설명합니다. 이 지침은 기존의 기계 학습 및 생성 AI 워크로드 모두에 적용됩니다. TensorFlow, Keras 및 PyTorch와 같은 프레임워크와 일괄 처리, 스트림 및 온라인 처리를 포함하는 다양한 서비스 및 호스팅 옵션을 다룹니다.

워크로드에 지능형 기능을 디자인할 때 고려해야 할 많은 옵션이 있습니다. 고유한 기능 및 비기능적 요구 사항은 기본 추론 기능 또는 보다 동적 문제 해결 기능이 필요한지 여부를 결정하는 데 도움이 됩니다. 이러한 요구 사항은 높은 수준의 디자인 결정을 안내합니다. 상위 수준 디자인 영역에서 하위 수준 디자인 영역으로 이동할 때 이러한 선택을 고려합니다.

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

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

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

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

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

애플리케이션 계층 아키텍처

지능형 기능을 디자인할 때 다음 5가지 주요 계층에서 디자인에 명확한 경계를 설정합니다.

• 클라이언트 계층: 사용자 또는 프로세스에서 워크로드의 지능형 기능을 경험하는 사용자 인터페이스 및 클라이언트 애플리케이션입니다. 이 계층을 가늘게 유지하고 대부분의 기능을 다른 레이어에 위임합니다.

• 인텔리전스 계층: AI 작업을 조정하는 라우팅, 오케스트레이션 및 에이전트 기능 이 계층에는 모델 라우팅, 대화 관리 및 지능형 의사 결정이 포함됩니다.

• 추론 계층: 학습된 모델을 실행하여 데이터를 기반으로 예측 또는 의사 결정을 생성합니다. 이 계층은 API 또는 포함된 시스템을 통한 예측 제공과 함께 모델 로드 및 런타임 호출, 입력 전처리 및 출력 후처리를 처리합니다.

• 지식 계층: 인텔리전스 계층에 관련된 컨텍스트와 정보를 제공하기 위해 데이터를 기반으로 하며, 지식 그래프와 검색 및 조회 서비스를 포함합니다. 이 계층은 데이터 액세스 정책 및 권한 부여를 적용합니다.

• 도구 계층: 인텔리전스 계층이 호출할 수 있는 비즈니스 API, 외부 서비스 및 작업 기능입니다. 이 계층은 표준화된 인터페이스를 사용하고 자체 보안 정책을 적용해야 합니다.

각 계층은 고유한 정책, ID 및 캐싱 전략을 적용하여 자체 지역화된 안정성, 보안 및 성능 요구 사항을 달성합니다. 또한 계층을 통해 집중적인 개발, 테스트 및 문제 해결을 수행할 수 있습니다.

권장 사항

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

추론 및 지능형 애플리케이션 구분

애플리케이션 아키텍처를 디자인할 때 먼저 추론 중심 애플리케이션을 빌드하는지 또는 인텔리전스 중심 애플리케이션을 빌드하는지 결정합니다. 이러한 구분으로 인해 디자인 결정이 결정됩니다.

유추 애플리케이션

추론 애플리케이션은 분류, 번역 또는 요약과 같은 단일 단계 작업을 수행합니다. 이러한 애플리케이션에는 더 간단한 아키텍처가 있습니다.

일반적인 아키텍처: 클라이언트는 인증, 할당량, 안전성 및 라우팅을 제공하는 AI 게이트웨이와 통신합니다. 해당 게이트웨이는 Azure AI Foundry, AKS(Azure Kubernetes Service) 또는 관리되는 온라인 엔드포인트와 같은 계층을 제공하는 모델을 호출합니다. 실제적인 경우 클라이언트로 반환되기 전에 향후 추론 호출을 위해 결과가 캐시될 수 있습니다.

추론 애플리케이션은 일반적으로 직접 모델 호출을 특징으로 하고, 최소한의 오케스트레이션이 필요하며, 성능 및 처리량에 중점을 두고, 복잡한 상태 관리가 필요하지 않습니다.

지능형 애플리케이션

지능형 애플리케이션은 계획, 조정 및 다단계 추론을 수행하며 일반적으로 에이전트 및 에이전트 오케스트레이션을 통해 처리됩니다. 아키텍처에서 더 많은 개념을 다루어야 합니다.

일반적인 아키텍처: 클라이언트는 에이전트 또는 에이전트 오케스트레이터를 호출합니다. 디자인 또는 자율 기능에 따라 이 계층은 MCP(모델 컨텍스트 프로토콜) 서버 또는 사용자 지정 API와 같은 도구 계층을 호출합니다. 에이전트는 검색 인덱스, 데이터베이스 또는 그래프와 같은 기반 지식 서비스를 호출해야 할 수 있습니다. 이 프로세스 중에 여러 지점에서 모델을 호출할 수 있습니다. 캐싱은 프로세스를 최적화하기 위해 여러 수준에서 발생할 수도 있습니다.

지능형 애플리케이션은 일반적으로 복잡한 워크플로 조정을 사용하여 에이전트 패턴 및 모델 라우팅을 특징으로 하며, 여러 데이터 원본 및 도구와 통합되며, 대화 및 컨텍스트 관리가 필요합니다.

기본 AI 애플리케이션 디자인 지침

AI 애플리케이션을 디자인할 때 다음 기본 지침을 적용하여 복원력 있고 유지 관리 가능한 시스템을 만듭니다.

비즈니스 결과로 시작하세요

기술을 선택하기 전에 해결 중인 비즈니스 문제를 명확하게 정의합니다. 이 정의는 기술 선택 사항 및 아키텍처 디자인을 안내합니다. 다음 사항을 고려합니다.

• 성공 메트릭: 정확도 향상, 비용 절감 또는 사용자 만족도 점수와 같은 가치를 보여 주는 측정 가능한 결과를 정의합니다.

• 사용자 환경 요구 사항: 사용자와 프로세스가 AI 기능과 상호 작용하는 방법과 예상되는 응답 시간을 이해합니다.

• 규제 제약 조건: 데이터 보존 또는 설명 가능성 요구 사항과 같이 디자인 선택에 영향을 줄 수 있는 규정 준수 요구 사항을 식별합니다.

첫날부터 보안을 위한 디자인

AI 워크로드는 처음부터 보안 우선 접근 방식을 요구합니다. ID 전파 및 감사 가능 컨트롤을 사용하여 모든 구성 요소에 계층화된 보안을 구현합니다. 자세한 내용은 보안 디자인 전략을 참조하세요.

첫날부터 관찰을 위한 디자인

AI 애플리케이션에는 기존 애플리케이션 메트릭 이외의 모니터링이 필요합니다. 처음부터 디자인에 가시성을 구축합니다.

• 모델 성능 추적: 정확도 드리프트, 유추 대기 시간 및 예측 신뢰도 점수를 모니터링합니다.

• 데이터 품질 모니터링: 모델 성능에 영향을 줄 수 있는 입력 데이터 배포 변경 내용을 추적합니다.

• 사용자 상호 작용 분석: 사용자가 AI 기능과 상호 작용하여 개선 기회를 식별하는 방법을 이해합니다.

추상화 및 향후 유연성 계획

AI 기술이 발전함에 따라 적응할 수 있는 추상화 계층으로 시스템을 디자인합니다.

• 모델 추상화: 애플리케이션 변경 없이 교환하거나 업그레이드할 수 있도록 일관된 인터페이스 뒤에 있는 추상 모델입니다.

• 표준화된 프로토콜: 도구용 OpenAPI, 모델 이식성을 위한 ONNX 및 원격 분석용 OpenTelemetry와 같은 개방형 문서화된 인터페이스 및 형식을 선호합니다.

• 기능 기반 디자인: 유연성을 유지하기 위해 특정 기술이 아닌 기능을 중심으로 디자인합니다.

프롬프트 및 구성 외부화

프롬프트를 Twelve-Factor 앱 디자인 원칙에 따라 외부화해야 하는 구성으로 처리합니다.

• 버전 제어: 명확한 배포 추적을 사용하여 버전 제어에 프롬프트를 유지하여 원격 분석 및 안전 결과를 특정 프롬프트 버전과 상호 연결합니다.

• 역할 분리: 비즈니스 분석가 및 도메인 전문가가 코드를 변경하지 않고 프롬프트를 조정할 수 있습니다.

• 안전한 배포: 프롬프트 변경을 위해 제어된 롤아웃 프로세스를 구현하고 중요한 구성 업데이트로 처리합니다.

모델 사용 중단 계획

파운데이션 모델은 결국 수명이 다하고 모델 호스팅 플랫폼에서 사용 중지됩니다. 모델은 더 나은 성능을 발휘하고, 비용 효율적이며, 학습 지식을 업데이트하고, 새로운 기능을 지원하는 모델로 대체됩니다. 워크로드의 향후 모델 전환에 미치는 영향을 최소화하는 추상화 설계

• 공급자 추상화: 애플리케이션을 변경하지 않고 모델 공급자 간에 전환할 수 있는 추상화 계층을 사용합니다.

• 버전 관리: 모델 버전 간의 점진적 마이그레이션을 지원하는 버전 관리 전략을 구현합니다.

• 대체 전략: 기본 모델을 사용할 수 없게 되는 경우에 대한 대체 메커니즘을 디자인합니다.

모델 수명 주기 문제를 해결하는 아키텍처 디자인 기술은 기본 모델 수명 주기를 지원하는 디자인을 참조하세요.

구성 요소 컨테이너화

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

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

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

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

• 인프라 서비스: 데이터베이스 및 캐싱 계층과 같은 인프라 지원을 제공하는 서비스를 컨테이너화합니다. 이 방법은 버전 일관성을 유지하는 데 도움이 되며 이러한 구성 요소의 크기 조정 및 관리를 용이하게 합니다.

다중 계층 캐싱 전략 구현

다중 계층 캐싱 접근 방식은 AI 애플리케이션의 성능을 개선하고 비용을 절감하는 데 도움이 될 수 있습니다. 애플리케이션 스택의 여러 수준에서 캐싱을 구현하는 것이 좋습니다.

• 결과 및 답변 캐싱: 상황에 적합한 경우 동일하거나 의미상 유사한 쿼리에 응답을 다시 사용하려면 이 방법을 사용합니다. 응답을 캐시할 수 있는 워크로드에서 이 방법은 모델에 대한 호출을 크게 줄여 성능을 향상시키고 모델 호출 비용을 줄일 수 있습니다.

• 검색 및 기반 설정 코드 조각 캐싱: 반복되는 데이터베이스 및 검색 쿼리 또는 데이터 API 작업을 방지하기 위해 자주 검색되는 지식 조각 및 기반 데이터를 캐시합니다.

• 모델 출력 캐싱: 요청 간에 재사용할 수 있는 중간 모델 출력을 캐시합니다.

각 계층에서 캐싱 방법을 디자인할 때 자주 액세스하는 데이터와 애플리케이션의 사용자 역할 및 권한이 액세스할 수 있는 데이터에 어떤 영향을 줄 수 있는지 이해해야 합니다. 캐싱이 유효하려면 정상 캐시 적중률을 예상해야 합니다. 캐시 제거를 모니터링하는 동시에 제품 카탈로그 검색과 같은 트래픽이 많은 경로에 대한 캐싱에 집중합니다.

• 캐시 키 구성 요소: 캐시된 값은 워크로드 내의 특정 런타임 요소에 연결되어야 합니다. 캐시된 값이 요청에 적합한 경우에만 반환되도록 캐시 키에 테넌트 또는 사용자 ID, 정책 컨텍스트, 모델 버전 및 프롬프트 버전과 같은 값을 포함합니다.

• TTL(Time to Live) 정책: 데이터 새로 고침 요구 사항 및 콘텐츠 민감도에 따라 적절한 만료 시간을 설정합니다.

• 무효화 후크: 데이터 업데이트, 모델 변경 및 프롬프트 수정에 대한 캐시 무효화 트리거를 구현합니다.

• 사용자 개인 정보 보호: 키 및 정책에 따라 적절하게 범위를 지정하지 않는 한 사용자-프라이빗 콘텐츠를 캐시하지 마세요. 일반적으로 캐싱은 여러 사용자에게 적용되는 데이터에 가장 적합합니다. 대부분의 경우 단일 사용자에 대해 캐시하지 마세요. 모든 사용자에게 유효한 응답으로 사용자별 응답을 캐싱하지 않습니다. 예를 들어 다른 사용자가 동일한 쿼리를 제공하는 경우에도 데이터를 요청하는 사용자에게만 "몇 시간의 유급 휴가를 남겼습니까?"에 대한 캐시된 응답이 적합합니다.

위험: 캐싱은 성능을 향상시키고 비용을 줄이지만 보안 및 데이터 새로 고침 위험을 초래합니다. 이러한 위험에는 데이터 유출, 부실 데이터 및 개인 정보 침해가 포함됩니다.

생성 AI 솔루션에서 오케스트레이션 및 에이전트의 사용을 평가합니다

결정 및 예비 기능에 대한 애플리케이션의 요구 사항에 따라 적절한 조정 방법을 선택합니다.

오케스트레이션을 사용하는 경우

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

• 예측 가능한 워크플로: 잘 정의된 시퀀스 및 의사 결정 지점이 있는 다단계 프로세스입니다.

• 규정 준수 요구 사항: 규정 준수를 위해 특정 단계를 수행해야 하는 시나리오입니다.

• 성능에 중요한 경로: 대기 시간 및 리소스 사용을 엄격하게 제어해야 하는 워크플로입니다.

• 간단한 조정: 동적 추론이 필요하지 않은 간단한 작업 위임입니다.

에이전트 공동 작업을 사용하는 경우

에이전트는 애플리케이션에서 지능형 동작을 래핑, 추출 및 정의하는 방법입니다. 에이전트는 컨텍스트에 바인딩된 기능을 제공하며 의미 체계 커널, Autogen 또는 Microsoft 에이전트 프레임워크와 같은 오케스트레이션 프레임워크를 사용할 수 있습니다.

예비 또는 구성 작업에 에이전트 라우팅 공동 작업 방법을 사용합니다.

• 다단계 추론: 여러 단계에서 계획 및 의사 결정이 필요한 작업

• 도구 조정: 여러 특수 도구 및 서비스를 조정하는 복잡한 워크플로

• 적응 동작: 중간 결과 또는 변경 조건에 따라 시스템이 접근 방식을 조정해야 하는 시나리오

• 컨텍스트 관리: 상호 작용 간에 대화 상태 및 사용자 컨텍스트를 유지해야 하는 애플리케이션

에이전트 디자인 고려 사항

에이전트 기반 시스템을 디자인할 때 격리 및 경계, 통신 패턴 및 도구 추상화 전략을 고려합니다. 서로 다른 에이전트 기능 간에 명확한 경계를 설계하여 폭발 반경을 줄이고 테스트 가능성을 개선합니다. 에이전트 통신에 토픽 큐 시스템과 같은 설정된 패턴을 사용합니다. 표준화된 인터페이스를 사용하여 에이전트 유연성을 가능하게 하는 추상 도구 기능

에이전트 상태 지속성

다중 턴 대화와 장기 실행 작업의 경우, 요청, 세션 또는 배포 주기 간에 컨텍스트를 유지할 수 있도록 내구성이 있는 상태 지속성을 갖춘 에이전트를 설계하세요. Azure Cosmos DB, Azure Managed Redis 또는 Azure Table Storage와 같은 안전한 공유 스토리지를 사용하여 관련 메타데이터, 대화 기록 및 작업 진행 상황을 저장합니다. 필요한 최소 정보로 영구 상태의 범위를 제한하여 개인 정보 보호 위험과 토큰 오버헤드를 줄이고, TTL 정책을 구현하여 만료된 데이터를 삭제합니다. 에이전트가 완료된 단계를 반복하지 않고 워크플로를 계속하기 위해 다시 시작 시 상태를 리하일 수 있는지 확인합니다.

하이브리드 접근 방식

오케스트레이터가 에이전트에 특정 하위 작업을 위임하는 하이브리드 디자인을 고려합니다.

• 유연한 단계가 있는 구조화된 워크플로: 에이전트가 복잡한 개별 단계를 처리할 수 있도록 하면서 전체 워크플로에 오케스트레이션을 사용합니다.

• 에스컬레이션 패턴: 결정적 오케스트레이션으로 시작하고 미리 결정된 논리가 부족한 경우 에이전트 기반 추론으로 에스컬레이션합니다.

• 도메인별 추론: 도메인별 작업에 특수 에이전트를 사용하는 동안 도메인 간 조정을 위해 오케스트레이션을 사용합니다.

트레이드오프: 오케스트레이션은 예측 가능성과 제어를 제공하지만 적응성을 제한합니다. 에이전트 협업은 동적 문제 해결을 가능하게 하지만 가변성 및 복잡성을 도입합니다.

정책 적용을 위한 AI 게이트웨이 구현

디자인에서 AI 게이트웨이를 사용하여 워크로드 내에서 게이트웨이 오프로드, 게이트웨이 라우팅 및 게이트웨이 집계 기능을 제공합니다. 게이트웨이는 일반적으로 Azure API Management와 같은 플랫폼을 사용하거나 Envoy 또는 NGINX 구현과 같은 사용자 지정 코드 솔루션을 통해 구현됩니다. 게이트웨이를 사용하여 모델 공급자, 에이전트 엔드포인트, 도구 및 지식 저장소에 대한 요청을 프록시할 수 있습니다.

핵심 AI 게이트웨이 기능

AI 게이트웨이는 횡단 관심사를 해결하고 대상 시스템의 추상화 및 간접성 계층 역할을 할 수 있습니다. AI 게이트웨이 전략을 설계할 때 다음 기능을 고려합니다.

• 프로토콜 정규화: 공급자 간 공유 AI 기능의 경우 게이트웨이를 통해 공통 프로토콜로 인터페이스를 정규화하여 유지 관리 가능성을 개선합니다. 공급자별 기능의 경우 정규화 없이 게이트웨이를 역방향 프록시로 사용합니다.

• 인증 및 권한 부여: ID 기반 액세스 제어를 적용하고 사용자 컨텍스트를 다운스트림 서비스에 전파합니다.

• 속도 제한 및 할당량: 사용자별, 애플리케이션별 또는 테넌트당 속도 제한 및 토큰 할당량을 구현하여 남용을 방지하고 비용을 관리합니다.

• 요청 및 응답 필터링: 게이트웨이 수준에서 입력 유효성 검사, 프롬프트 필터링 및 출력 안전 검사를 적용합니다.

• 토큰 및 프롬프트 대문자: 시스템에서 원하는 것보다 많은 수요를 나타내는 요청을 선제적으로 거부하여 리소스 소모를 방지하기 위해 최대 토큰 제한 및 프롬프트 크기 제한을 적용합니다.

• 모델 라우팅 정책: 사용자 권한, 요청 특성 또는 비용 최적화 목표에 따라 요청을 적절한 모델로 라우팅합니다. 게이트웨이는 용량 또는 가격이 한 모델에서 사용되지만 다른 모델 배포에서 사용할 수 있는 경우 여러 모델 간에 분산을 구현하는 데 자주 사용됩니다.

• 헤더 삽입 및 변환: 다운스트림 서비스에 필요한 헤더, 사용자 컨텍스트 및 보안 토큰을 추가합니다.

• 차지백 관리: 단일 Azure OpenAI 인스턴스와 같이 AI 워크로드 구성 요소를 공유하는 부서에 요금을 할당합니다.

다중 공급자 시나리오

AI 게이트웨이는 여러 모델 공급자 또는 공유 모델 호스팅 플랫폼을 사용하는 경우에 특히 유용합니다. 이러한 게이트웨이는 워크로드를 권장하거나 의존해야 하는 조직 내의 중앙 집중식 리소스인 경우가 많습니다. 충분히 복잡한 워크로드는 자체 디자인 내에서 이 추상화 계층을 빌드하면 도움이 될 수 있습니다.

• 통합 인터페이스: 여러 백 엔드 공급자를 추상화하는 단일 API 표면을 제공합니다.

• 장애 조치 및 중복성: 기본 서비스를 사용할 수 없으면 요청을 대체 공급자로 라우팅합니다.

• 비용 최적화: 요청 특성에 따라 가장 비용 효율적인 공급자로 요청을 라우팅합니다.

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

업계는 AI 애플리케이션에 대한 몇 가지 일반적인 디자인 패턴을 정의합니다. 이를 사용하여 디자인 및 구현을 간소화할 수 있습니다. 이러한 디자인 패턴에는 다음 유형이 포함됩니다.

• 모델 ensembling: 이 디자인 패턴은 여러 모델의 예측을 결합하여 개별 모델의 제한을 완화하여 정확도와 견고성을 향상시킵니다.

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

• 이벤트 기반 아키텍처: 이 디자인 패턴은 이벤트를 사용하여 작업을 트리거하여 분리된 구성 요소와 실시간 처리를 통해 시스템의 응답성과 변경 데이터에 적응할 수 있도록 합니다.

접지 및 지식 통합 패턴

많은 AI 애플리케이션이 외부 지식 원본에 액세스하여 정확하고 최신 정보를 제공합니다. 권한 부여를 적용하는 서비스 뒤에서 검색을 에이전트 도구나 지식 호출로 처리합니다.

• 지식 라우팅: 쿼리 유형, 도메인 또는 사용자 컨텍스트에 따라 적절한 기술 원본으로 쿼리를 전달합니다.

• 컨텍스트 계층화: 여러 지식 원본 및 컨텍스트 유형을 결합하여 포괄적인 응답을 제공할 수 있는 시스템을 빌드합니다.

• 동적 접지: 변화하는 요구 사항 또는 데이터 가용성에 따라 기술 자료 및 접지 전략을 조정할 수 있는 시스템을 구현합니다.

• 권한 부여 인식 검색: 정보를 검색할 때 접지 서비스가 사용자 권한 및 테넌트 컨텍스트를 적용하는지 확인합니다.

의미 체계 검색을 위해 워크로드별 접지 데이터를 지원하는 용도로 작성된 벡터 인덱스를 디자인하는 방법에 대한 자세한 내용은 RAG(검색 보강 세대) 솔루션 설계 및 개발을 참조하세요.

다중 모델 라우팅 패턴

모델 라우터를 사용하면 다른 모델이 비정상 상태일 때 요청을 정상 모델로 라우팅하여 워크로드의 가용성을 향상시키거나 특정 작업에 가장 적합한 모델을 실시간으로 선택하여 응답 품질을 향상시킬 수 있습니다. 모델 라우터는 유연성을 더하지만 추가 가변성을 도입합니다. 선택적으로 사용합니다.

모델 라우터를 사용하는 경우: 워크로드가 추가된 가변성 및 대기 시간을 허용할 수 있거나, 사용자 환경이 모델 유형에 걸쳐 폭을 기대하거나, 여러 모델에서 비용과 기능의 균형을 유지해야 하는 경우 모델 라우터를 사용합니다.

모델 라우터를 피해야 하는 경우: 워크로드에 특정 작업에 최적화된 정확한 답변이 필요하거나, SLO(서비스 수준 목표)가 좁은 미세 조정된 모델을 사용하거나, 일관된 성능을 비롯한 결정적 동작이 사용 사례에 중요한 경우 모델 라우터를 사용하지 마세요.

애플리케이션에 모델 라우터를 추가하는 경우 사용 가능한 경우 공급자 네이티브 라우팅을 선호하고 성능 영향 및 사용자 만족도를 모니터링합니다.

트레이드오프: 모델 라우터는 유연성과 비용 최적화를 제공하지만 비결정적인 동작과 복잡성이 테스트에서 문제 해결로 이어집니다.

워크로드가 다중 테넌트 애플리케이션인 경우 테넌트별 접지 데이터 액세스에 대한 권장 사항에 대한 보안 다중 테넌트 RAG 추론 솔루션 설계 가이드 를 참조하세요.

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

다음 시나리오에 대해 이러한 디자인 패턴을 사용하는 것이 좋습니다.

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

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

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

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

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

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

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

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

• 커뮤니티 및 지원: 프레임워크의 완성도 및 지원 에코시스템을 고려합니다. 활성 커뮤니티 및 포괄적인 설명서는 구현 위험을 줄입니다.

• 성능 특성: 메모리 사용량, 시작 시간 및 유추 속도를 포함하여 특정 사용 사례에 대한 프레임워크 성능을 평가합니다.

거버넌스를 개선하고 유연성을 사용하도록 표준화된 도구 프로토콜을 채택합니다.

• MCP 스타일 서버 사용: MCP 또는 다른 적합한 표준을 사용하여 비즈니스 기능을 검색 가능한 도구 서버로 래핑합니다.

• 광범위한 SDK 지원이 있는 사양을 사용합니다. 예를 들어 일관된 인터페이스 설명서 및 유효성 검사를 위해 OpenAPI 사양을 사용하여 도구를 정의합니다.

• 보급 기능: 오케스트레이터가 요청을 적절하게 검색하고 라우팅할 수 있도록 해당 기능을 보급하는 도구를 디자인합니다. 예를 들어, 기업 자원 관리(ERP) 읽기 및 쓰기 작업을 기능을 노출하는 도구 서버로 구성합니다. 이 방법을 사용하면 에이전트 논리를 변경하지 않고도 ERP 상호 작용을 조정할 수 있습니다.

프로토콜 기본 설정

프로토콜 및 표준을 선택하는 경우 독점 형식보다 개방형 문서화된 인터페이스를 선호합니다. 업계에는 새로운 프로토콜이 많이 있습니다. 에이전트 간 및 제어 사용 사례를 고려할 때, 빠르게 진화하거나 사용 중지될 수 있는 프로토콜로 인해 발생할 수 있는 기술 부채를 고려하십시오. 추상화 계층은 다양한 AI 프레임워크 및 공급자 간에 디자인을 상호 운용 가능하게 유지하는 데 도움이 될 수 있습니다.

워크로드의 AI 구성 요소에 대한 보안 전략 설계

AI 구성 요소에는 기존 애플리케이션 보안 이외의 보안 고려 사항이 필요합니다. 기본 인증 및 권한 부여를 위해 Microsoft Entra ID와 같은 표준 ID 공급자를 사용하는 동안 모든 애플리케이션 계층에서 보안 조치를 구현합니다.

핵심 보안 원칙

다음과 같은 기본 보안 사례를 구현합니다.

• 표준 인증 및 권한 부여: 설정된 ID 공급자 및 RBAC(역할 기반 액세스 제어) 시스템을 사용합니다.

• 사용자 컨텍스트 전파를 사용하여 데이터 계보 보안: 데이터 파이프라인 전체에서 액세스 제어가 유지 관리되는지 확인합니다. 사용자가 볼 수 있는 권한이 있는 데이터를 기반으로 결과에만 액세스할 수 있도록 On-Behalf-Of 흐름을 사용하여 사용자 ID를 전달합니다.

• 감사 내역: 규정 준수 및 보안 모니터링을 위한 AI 상호 작용에 대한 자세한 로깅을 구현합니다.

AI 관련 보안 조치

AI 애플리케이션에 고유한 보안 문제를 해결합니다.

• 프롬프트 필터링 및 주입 방지: AI 동작을 조작하거나 중요한 정보를 추출할 수 있는 프롬프트 삽입 공격으로부터 보호 기능을 구현합니다.

• 안전한 도구 사용 컨트롤: 도구 액세스 권한이 있는 에이전트를 사용하는 경우 호출하기 전에 컨트롤을 구현하여 유해한 작업을 방지하고 도구 사용의 유효성을 검사합니다.

• 에이전트 동작 모니터링: 에이전트 작업 및 의사 결정을 모니터링하여 비정상적이거나 잠재적으로 유해한 동작 패턴을 감지합니다.

• 모델 액세스 제어: AI 시스템 내에서 다양한 모델 및 기능에 대한 세분화된 권한을 구현합니다.

• 응답 필터링 및 안전 검사: AI 출력을 필터링하여 유해하거나 부적절하거나 민감한 콘텐츠가 생성되지 않도록 합니다.

보안 트리밍된 접지

직접 데이터베이스 액세스를 방지하는 것 외에도 보안 인식 지식 검색을 구현합니다.

• 신원 전파: 접지 서비스가 무단 데이터 또는 미디어를 검색하지 않도록 Microsoft Entra 그룹 클레임 또는 동등한 신원 정보를 지식 도구 호출에 전달합니다.

• ACL(그룹 및 액세스 제어 목록) 기반 트리밍: 기술 계층의 보안 그룹 및 ACL을 기반으로 필터링을 구현합니다.

• 감사 가능한 거부: 권한이 부족하여 발생하는 로그 및 감사 로깅 요청 거부입니다.

• 권한 부여 적용: 권한 부여 정책을 적용하려면 해당 코드가 에이전트와 기술 자료 사이에 있어야 합니다.

예를 들어, Microsoft Entra 그룹 클레임을 지식 도구 호출에 전달하여 기반에서 권한 없는 문서를 검색하지 못하도록 보장할 수 있습니다. 이 구성은 캐시된 결과를 보장하고 AI 응답이 사용자 권한을 준수하도록 합니다.

비기능적 요구 사항 고려

워크로드에는 AI 기술에 내재된 요인으로 인해 문제를 야기하는 비기능적 요구 사항이 있을 수 있습니다.

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

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

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

• 모델 정확도 및 드리프트: 데이터 패턴이 변경됨에 따라 AI 모델은 시간이 지남에 따라 저하할 수 있습니다. 정확도 드리프트를 감지하고 필요한 경우 자동화된 재학습 파이프라인을 구현하도록 모니터링 시스템을 디자인합니다.

• 규정 준수 및 설명 가능성: 일부 산업에는 설명 가능한 AI 결정이 필요합니다. 필요할 때 AI 생성 출력에 대한 추론을 캡처하고 제공하도록 시스템을 디자인합니다.

• 데이터 개인 정보 및 상주: 디자인이 사용자 데이터를 삭제하고 지리적 데이터 보존 규칙을 준수하는 기능을 포함하여 데이터 보호 요구 사항을 충족하는지 확인합니다.

다음 단계