Azure에서 AI 워크로드 테스트 및 평가
AI 워크로드에서 테스트하는 목적은 시스템에 변경 사항이 도입될 때 품질을 보장하는 데 도움이 되는 것입니다. 테스트는 워크로드가 식별된 대상을 충족하고 사용자 기대치를 충족하는지 여부를 확인할 수 있습니다. 또한 품질 회귀를 방지합니다. 이 프로세스에는 다양한 기능 영역에서 테스트를 수행하고 워크로드 요구 사항에 따라 기능의 품질, 부하 처리, 예측 가능성 및 기타 기준을 평가하는 것이 포함됩니다.
테스트 결과는 AI 구성 요소를 릴리스할 준비가 되었는지 여부 및 적절한 SKU 또는 기능과 같은 의사 결정에 중요한 데이터 요소를 제공합니다. 또한 테스트는 오류에 대한 알림 시스템 역할을 하며 일상적인 테스트 또는 합성 테스트를 통해 프로덕션의 문제를 감지하는 데 도움이 될 수 있습니다.
Azure Well-Architected Framework는 포괄적인 테스트 방법론을 간략하게 설명합니다. 개발 수명 주기의 여러 단계와 다양한 시스템 구성 요소 및 흐름에서 다양한 유형의 테스트를 사용해야 합니다. 이러한 테스트가 없으면 롤아웃 변경으로 시스템 품질이 저하될 수 있습니다. 예를 들어 사소한 코드 오류는 큰 시스템 오류가 될 수 있습니다. AI 시스템의 비결정적 특성으로 인해 시스템 동작이 예측할 수 없거나 편향된 결과를 생성할 수 있습니다. 또한 리소스 할당은 비효율적일 수 있으며 이러한 시스템이 남용에 취약하기 때문에 실제 사용자 데이터 또는 시스템 리소스를 악용할 수 있습니다.
테스트를 염두에 두고 워크로드 자산을 디자인하고 개발해야 합니다. 예를 들어 기능 엔지니어링을 위해 데이터 조작을 수행하고 원본 데이터를 재구성하는 경우 좋은 코딩 방법을 준수하고 테스트를 지원하도록 코드를 구성해야 합니다. 이 전략에는 효과적인 단위 테스트를 용이하게 하기 위해 코드를 디자인하고 코드의 기능 및 종속성으로부터 테스트를 격리하는 것이 포함됩니다. 이 예제에서는 볼륨 및 유사도 측면에서 충분히 대표적인 테스트 데이터를 사용하여 테스트 환경에서 수행할 수 있는 시스템을 디자인해야 합니다.
워크로드 구성 요소를 프로덕션에 안전하게 배포해야 합니다. 워크로드의 안전한 배포 사례 중 일부는 사용자 또는 데이터가 시스템을 소비하기 전에 올바른 동작을 보장하는 데 도움이 되는 전략적 테스트입니다. 전략적 테스트는 초기 배포 중에 중요하며 시스템이 진화하고 코드 또는 인프라 변경을 거치면서 필요합니다. 프로덕션에 변경 내용을 배포하기 전에 AI 관련 코드 및 인프라에 대해 제안된 모든 변경 내용을 테스트합니다.
이 문서에서는 아키텍처의 AI 측면에 해당 방법론을 적용하는 데 중점을 둡니다. 이러한 테스트를 수행하는 방법은 범위에 없습니다.
권장 사항
다음은 이 문서에 제공된 권장 사항의 요약입니다.
| 추천 | 설명 |
|---|---|
| 테스트 전략에 대한 성공 메트릭을 정의합니다. | 다른 유형의 워크로드 테스트와 마찬가지로 지정된 테스트에 대한 적절한 메트릭을 캡처하고 분석하여 테스트가 AI 워크로드에 대한 유용한 인사이트를 제공하는지 확인해야 합니다. ▪ 성공 메트릭 정의 |
| 개발 수명 주기 동안 데이터 수집 및 처리 파이프라인에 대한 엔드 투 엔드 테스트를 수행합니다. | 테스트는 데이터의 유효성을 검사하고 데이터 조작 프로세스가 의도한 대로 작동하는지 확인하는 데 도움이 될 수 있습니다. 디자인 단계 초기에 테스트를 통합하여 데이터 품질과 적절한 기술 및 크기 조정 선택을 보장합니다. 개발 중에 사용자 지정 코드에 대한 단위 테스트를 개발하고 실시간 프로덕션 테스트를 수행하여 문제를 파악하고 기능의 유효성을 검사합니다. ▪ 데이터 수집 테스트 |
| 학습 작업에 대한 테스트를 실행하여 스크립트가 호출되고 예상대로 작동하는지 확인합니다. | 부하 및 성능 테스트는 작업을 실행하는 데 적합한 컴퓨팅의 선택 및 크기 조정에 대한 인사이트를 제공할 수 있습니다. 단위 테스트는 종속성이 업데이트되면 코드 유틸리티의 유효성을 검사하고 회귀를 catch할 수 있습니다. ▪ 학습 워크플로 테스트 |
| 모델을 평가하고 테스트하여 학습, 평가 및 테스트 데이터의 중복을 방지합니다. | 원본 데이터가 학습에 완전히 사용되지 않도록 하려면 모델 평가 및 최종 테스트를 위해 고유한 데이터를 예약해야 합니다. 이러한 하위 집합은 실제 학습 프로세스에 포함되지 않습니다. ▪ 모델 평가 및 테스트 |
| 유추 엔드포인트를 테스트합니다. | 유추 서버가 호스트하는 엔드포인트에서 부하 테스트를 수행하고 해당 테스트 결과에 따라 GPU SKU를 선택합니다. PaaS(Platform as a Service) 호스팅 엔드포인트의 경우 처리량 및 잠재적인 오류를 테스트합니다. 이러한 엔드포인트에 연결할 수 있으므로 탈옥 상황을 방지하기 위해 적절한 보안 테스트를 수행합니다. ▪ 유추 엔드포인트 테스트 |
| 쿼리가 관련 결과를 생성할 수 있도록 인덱스 디자인의 정확성을 테스트합니다. | 기능 및 통합 테스트는 데이터가 정확한지 확인하고 인덱스 스키마 테스트가 이전 버전과의 호환성을 확인하는 데 도움이 됩니다. 품질에 대한 전처리 단계를 테스트해야 합니다. 부하 테스트는 리소스에 적합한 SKU를 결정하고 보안 제어는 데이터 기밀성을 보호합니다. ▪ 접지 데이터 테스트 |
| 오케스트레이터를 테스트하여 해당 기능 및 보안의 유효성을 검사합니다. | 부하 및 오류 모드 테스트를 포함하여 단위, 기능, 통합 및 런타임 테스트를 수행하여 성능과 안정성을 보장합니다. 보안 및 콘텐츠 안전 테스트는 시스템과 데이터를 보호하는 데도 중요합니다. ▪ 오케스트레이터 테스트 |
| 모델 감쇠를 테스트합니다. | 모델 감쇠는 대부분의 AI 워크로드에 영향을 주는 불가피한 문제입니다. 데이터 및 개념 드리프트 테스트는 모델 붕괴를 조기에 포착하고 워크로드에 부정적인 영향을 미치기 전에 문제를 완화하는 데 도움이 될 수 있습니다. ▪ 모델 감쇠 방지 |
성공 메트릭 정의
잘 정의된 메트릭을 사용하여 기준선을 사용하고 모델의 예측 능력을 측정하는 것이 좋습니다. 다음은 몇 가지 일반적인 메트릭입니다.
정확 도는 테스트 데이터 세트의 총 인스턴스에 대해 올바르게 예측된 인스턴스의 비율을 나타냅니다. 이는 전체 모델 성능에 대한 일반적인 측정값입니다.
정밀도 는 참 긍정 예측과 진양성 및 가양성의 합계에 대한 비율입니다. 예를 들어 의료 진단과 같이 가양성을 최소화하는 것이 중요할 때 유용합니다.
민감 도는 참 긍정과 거짓 부정의 합계에 대한 참 긍정의 비율을 측정합니다. 거짓 부정을 피하거나 관련 사례가 누락되는 경우 매우 중요합니다.
특이성은 참 부정과 가양성의 합계에 대한 참 부정의 비율을 계산합니다. 정확한 부정 예측을 최적화할 때 관련됩니다.
참고 항목
회귀 모델에 대한 성공 메트릭을 정의할 때 다음 메트릭을 추가하는 것이 좋습니다.
MAE(평균 절대 오차) 는 예측 값과 실제 값 간의 평균 절대 차이를 측정합니다. 각 실제 값과 해당 예측 값 간의 절대 차이의 평균을 사용하여 계산합니다. MAE는 MSE 및 RMSE에 비해 이상값에 덜 민감합니다.
평균 제곱 오차(MSE) 는 실제 값과 예측 값 간의 평균 제곱 차이를 측정합니다. 각 실제 값과 해당 예측 값 사이의 제곱 차이의 평균을 사용하여 계산합니다. MSE는 오류가 제곱되므로 MAE보다 큰 오류를 더 많이 처벌합니다.
RMSE(Root Mean Squared Error) 는 MSE의 제곱근입니다. 실제 값과 예측된 값 간의 평균 절대 오차를 원래 데이터와 동일한 단위로 측정합니다. RMSE는 평균을 계산하기 전에 오류를 제곱하기 때문에 MAE에 비해 이상값에 더 민감합니다.
데이터 수집 테스트
ETL(추출, 변환 및 로드) 프로세스와 같은 데이터 파이프라인은 데이터를 이동하고 조작합니다. 워크로드의 ETL 부분을 테스트하여 데이터를 안정적으로 수집하고 데이터가 높은 품질이며 분석 및 기능 엔지니어링에 허용되는지 확인합니다. 데이터 정리 및 처리에 테스트가 포함되어 있는지 확인하여 데이터 조작이 의도한 대로 작동하는지 확인합니다.
테스트는 설계, 개발 및 프로덕션 단계를 포함하여 수명 주기 전반에 걸쳐 통합되어야 합니다.
디자인 선택을 용이하게 하기 위한 테스트
워크로드에 대한 요구 사항을 수집할 때 주요 의사 결정 단계는 디자인에 적합한 특정 기술 옵션을 선택하는 것입니다.
ETL 요구 사항 및 수용 기준에 따라 예비 기능 테스트를 수행하여 가장 적합한 제품, SKU 및 의도한 작업을 수행하는 기능을 선택합니다. 개념 증명, 기술 증명 및 기능 증명 테스트는 적합한 기술을 선택하는지 여부와 적절한 크기인지 여부를 평가하는 데 필수적입니다.
AI를 기존 아키텍처에 통합하는 시나리오의 경우 새 기술이 현재 시스템과 얼마나 잘 통합되는지 테스트합니다.
초기 워크로드 요구 사항은 변경 될 수 있습니다. 비즈니스에서 성장을 예상하고 시스템에서 일반 사용자 쿼리를 두 배로 처리해야 한다고 가정합니다. 이러한 기대에는 적절한 용량 계획이 필요합니다. 시스템이 추가 데이터에 응답하는 방식을 이해하고 기존 크기 조정을 데이터 기반으로 조정하거나 새 제품을 선택하는 사전 테스트를 권장합니다. 용량 테스트의 경우 기능 테스트를 부하 및 성능 테스트와 결합하고 가상을 사용하여 현실적인 조건을 시뮬레이션하는 것이 좋습니다.
테스트하여 코드 품질 확인
코드가 포함되면 단위 테스트를 거치며 실패할 경우 릴리스되지 않는지 확인합니다. 예를 들어 수집의 일부로 실행되는 사용자 지정 코드를 사용하는 것이 일반적입니다. 데이터 정리 및 처리에 사용되는 코드도 있습니다. 단위 테스트를 실행하여 코드가 디자인에 따라 동작하고 데이터 조작이 예상대로 작동하는지 확인합니다.
연속 통합 및 지속적인 업데이트 파이프라인의 일부로 테스트를 실행합니다.
라이브 시스템에서 테스트
기능 테스트는 라이브 시스템으로 확장되어야 합니다. 이러한 테스트가 실패하는 경우 필요한 경우 경고를 트리거하여 즉각적인 조사를 시작하는 것이 좋습니다. 다음 몇 가지 예를 참조하세요.
예약된 테스트를 실행하여 데이터가 예상된 양으로 설정된 일정에 따라 수집되는 경우 올바른 데이터 볼륨이 수집되었는지 확인합니다.
누락된 값 또는 중복 데이터와 같은 데이터 문제를 감지하는 테스트를 실행하고 기본 데이터 무결성 검사를 수행합니다. 데이터에 새로 고침을 나타내는 임시 정보가 포함된 경우 이러한 테스트는 해당 정보를 확인하고 잠재적으로 다운스트림 프로세스에서 부실 데이터를 사용하지 못하게 할 수 있습니다.
외부 종속성의 가용성을 확인합니다. 예를 들어 데이터 정리 작업은 테이블 추출 또는 전처리를 위해 다른 서비스를 호출할 수 있습니다. 테스트를 실행하여 사용할 수 없는 경우 ETL 프로세스에 영향을 줄 수 있으므로 테스트를 사용할 수 있는지 확인합니다.
프로덕션 환경에서 ETL 시스템의 정확성을 테스트하는 또 다른 방법은 합성 테스트를 통해서입니다. 프로덕션 환경에서 알려진 테스트 데이터를 사용할 수 있는 것은 매우 효과적입니다. 알려진 시작 상태를 해당 데이터의 예상 엔드 상태와 비교하여 엔드 투 엔드 처리의 유효성을 검사하는 데 사용할 수 있습니다. 예를 들어 문서 인텔리전스를 통과하려면 문서가 필요하며 개인 데이터가 포함됩니다. 합성 문서를 삽입하면 워크로드가 의도한 대로 데이터 조작 작업을 수행하는지 테스트할 수 있습니다.
또한 A/B 테스트라고도 하는 다양한 환경을 릴리스하여 완전히 커밋하기 전에 사용자 상호 작용에서 학습하도록 실험합니다. A/B 테스트를 통해 품질 회귀를 방지할 수 있습니다.
수집 중에 수집되는 테스트 데이터
다양한 데이터 원본에서 수집 프로세스의 일부로 학습 데이터가 예상과 일치하는지 확인하는 테스트를 포함합니다.
불완전하거나 손상된 데이터를 사용하여 기계 학습 모델을 학습하는 것은 비생산적일 수 있습니다. 이로 인해 노력이 낭비되고 의미 있는 예측을 하지 못하는 모델이 발생할 수 있습니다. 데이터 수집 및 전처리 파이프라인에는 품질 테스트가 검사점으로 포함됩니다. 이러한 테스트를 통해 데이터가 데이터 분석 및 기능 엔지니어링 중에 설정한 기대와 일치하는지 확인할 수 있습니다.
다음 목록에는 몇 가지 예제 테스트 사례가 포함되어 있습니다.
완전성을 테스트합니다. 학습 데이터의 예상 수량을 테스트하여 데이터 세트의 완전성을 확인합니다. 이 테스트를 통해 모델을 학습시킬 수 있는 충분한 데이터를 제공할 수 있습니다.
중요한 정보를 테스트합니다. 학습이 특정 레코드 또는 식별자와 같은 알려진 엔터티를 기반으로 하는 경우 데이터 세트를 테스트하여 해당 엔터티가 있는지 확인합니다. 이 유효성 검사를 통해 중요한 정보가 누락되지 않습니다.
관련 없는 데이터를 테스트합니다. 수집된 데이터에는 관련이 없거나 잘못된 항목이 포함되어서는 안 됩니다. 데이터 수집 프로세스는 해당 데이터를 필터링해야 합니다.
새로 고침을 테스트합니다. 수집된 데이터의 새로 고침은 모델의 예측 성능에 영향을 주지 않아야 합니다. 데이터가 합리적으로 현재 정보를 반영하고 이전 실행에서 오래되지 않은지 확인합니다. 예를 들어 데이터가 지난 주의 레코드를 포함할 것으로 예상하지만 데이터를 가져온 후 이러한 레코드가 없는 경우 원본 시스템에서 가져오기 실패 또는 데이터 새로 고침 문제를 나타낼 수 있습니다.
일상적인 테스트 수행
데이터 수집의 중요한 관심사는 데이터 및 처리량의 양입니다. 성능 병목 상태를 방지하려면 작업 중에 지속적인 평가가 필요합니다. 이 지속적인 평가는 일회성 테스트가 아닌 운영 프로세스의 일부여야 합니다. 목표는 워크로드 팀이 서비스 수준 목표를 놓치지 않도록 하는 것입니다.
모니터링이 성능 저하를 나타내는 상황을 고려합니다. 이러한 조건을 완화하려면 ETL 프로세스를 다시 평가하고 최적화합니다. 변경한 후 성능 테스트를 통해 수정이 필요한 처리량을 충족하는지 확인할 수 있습니다.
참고 항목
테스트 및 모니터링은 다양한 용도로 사용됩니다. 일반적으로 변경 내용을 구현하기 전에 테스트를 수행하여 시스템에 대한 잠재적인 변경 내용을 평가합니다. 지속적으로 모니터링을 수행하여 시스템의 전반적인 상태를 평가합니다.
학습 워크플로 테스트
실제 학습 작업을 수행하는 PyTorch 스크립트와 같은 사용자 지정 코드를 사용하여 모델을 학습시킵니다. 이러한 스크립트는 메모리 및 네트워킹 리소스가 필요한 Notebook 또는 Azure Machine Learning 작업과 같은 컴퓨팅에서 실행됩니다. 설계 단계에서 부하 테스트를 수행하여 컴퓨팅 요구 사항을 평가하고 제안된 SKU가 적합한지 확인하는 것이 좋습니다. 시간 제한 내에서 워크로드를 효율적으로 실행하려면 최적의 구성을 결정하기 위해 수동 테스트가 필요한 경우가 많습니다.
대부분의 작업을 처리하는 특수한 SDK를 사용하여 스크립트를 작성합니다. 그러나 스크립트는 여전히 코드이므로 개발의 일부로 단위 테스트를 통합해야 합니다. 이러한 테스트를 통해 종속성을 업데이트할 때 회귀가 발생하지 않도록 할 수 있습니다. 단위 테스트가 불가능한 경우 품질 회귀를 방지하기 위해 새 코드를 배포하기 전에 수동 테스트가 필요합니다.
이러한 스크립트는 Azure Machine Learning 스튜디오 같은 워크플로의 일부로 실행되며 스크립트 실행 시기 및 여부에 대한 인사이트를 제공할 수 있습니다. 그러나 통합 테스트를 실행하여 이러한 스크립트가 안정적으로 호출되도록 하는 것이 좋습니다.
모델 평가 및 테스트
참고 항목
모델 평가 및 테스트는 종종 서로 다른 용도로 사용되지만 고유한 데이터 세트를 사용하는 별도의 프로세스로 간주되어야 합니다. 평가는 개발 단계에서 수행하는 반복 작업입니다. 적절한 수준의 튜닝으로 최상의 모델을 찾기 위한 실험에 중점을 둡니다. 여기에는 하이퍼 매개 변수, 구성 또는 기능을 조정한 다음 다양한 메트릭에 따라 모델을 평가하는 것이 포함됩니다. 최상의 모델을 식별한 후 배포하는 동안 테스트를 수행합니다.
테스트에는 튜닝된 모델 및 비 AI 구성 요소를 포함한 전체 시스템을 확인하여 올바르게 작동하는지 확인하고, 잘 통합하고, 품질 표준에 따라 예상 결과를 제공하는 것이 포함됩니다. 워크로드의 다른 구성 요소와 함께 현장에서 모델을 평가합니다. 이 프로세스에는 모델에 요청을 보내고, 응답을 평가하고, 테스트 데이터를 기반으로 이동 또는 이동 없이 결정을 내리는 작업이 포함됩니다. 프로덕션 전에는 테스트를 수행할 수 없지만 실제 데이터와 합성 데이터를 사용하여 프로덕션 환경에서도 테스트를 수행하는 것이 좋습니다.
데이터를 사용하여 평가 및 테스트
일반적으로 원본 데이터에서 분할된 세 가지 주요 데이터 세트( 학습, 평가 및 테스트)가 있습니다.
일반적으로 가장 큰 하위 집합인 학습 데이터 세트를 사용하여 모델을 학습시킵니다. 다른 순열을 평가하여 반복 프로세스를 통해 모델을 구체화하려면 다른 데이터 세트를 평가에 사용합니다. 만족스러운 순열을 찾은 후 테스트 데이터 세트에 대해 테스트합니다.
모든 데이터 세트는 노이즈를 최소화하기 위해 고품질 데이터를 포함해야 합니다. 데이터 수집 및 전처리 파이프라인에 대한 테스트 사례는 품질 검사점 역할을 할 수 있습니다. 샘플이 부족하면 품질이 낮은 데이터에 기인할 수도 있습니다. 가상 데이터를 사용하여 데이터 세트의 균형을 맞추고 균일성을 달성합니다. 이 방법은 실제 사기 인스턴스가 드물기 때문에 신뢰할 수 있는 예측에 충분한 통계 능력을 얻기 어려운 사기 감지 모델과 같은 모델을 학습하는 데 유용합니다.
예측의 편향을 방지하려면 모든 데이터 세트를 고유하게 유지합니다. 평가에 학습 데이터를 사용하면 안 되며 테스트에 평가 데이터를 사용하면 안 됩니다. 모델 평가 및 최종 테스트를 위해 고유 데이터를 예약합니다.
평가 메트릭 사용
모델을 학습시키고 프로덕션에 적합한 모델을 선택하는 것은 상호 종속적인 프로세스입니다. 처음에는 모델을 선택해야 하지만 실험 및 평가 후에 변경될 수 있습니다.
모델 평가는 메트릭을 사용하여 모델, 매개 변수 및 기능의 수많은 순열을 평가하는 실험 루프로 따릅니다. 이러한 메트릭은 과학적 등급을 제공하며, 최상의 모델을 결정하기 위해 여러 버전 및 구성에서 반복적으로 비교해야 합니다. 자세한 내용은 평가 메트릭을 참조 하세요.
유사한 접근 방식이 생성 AI 모델에 적용됩니다. 모델의 성능에 따라 사용자 환경의 결과를 평가하고 정량화하는 프로세스가 있습니다. 예를 들어 접지성은 모델이 원본 데이터와 얼마나 잘 일치하는지 정량화하는 주요 메트릭 중 하나입니다. 관련성은 쿼리에 대한 응답의 관련성을 나타내는 또 다른 중요한 메트릭입니다. 예를 들어 메트릭은 생성 AI에 대한 평가 및 모니터링 메트릭을 참조하세요.
다양한 메트릭을 사용하여 다양한 유형의 모델을 평가합니다. 각 메트릭의 중요성은 시나리오에 따라 달라질 수 있습니다. 사용 사례에 따라 메트릭의 우선 순위를 지정합니다. 예를 들어 공정성은 책임 있는 AI에서 매우 중요합니다. 좋은 테스트에도 불구하고 모델은 편향된 원본 데이터로 인해 여전히 불공정한 편견을 나타낼 수 있습니다. 결과는 관련성이 높지만 공정성은 낮을 수 있습니다. 공정성 평가를 프로세스에 통합하여 편견 없는 결과를 보장합니다.
생성 AI는 오케스트레이션 코드, 라우팅 논리 및 RAG(검색 보강 생성)를 위한 인덱스와 통합되어 평가를 복잡하게 만듭니다. 메트릭을 사용하여 모델을 개별적으로 평가해야 하지만 다른 시스템 구성 요소를 평가하는 것도 중요합니다.
모델 테스트
미세 조정은 기본적으로 사전 학습된 모델을 수정하여 동작을 변경하기 때문에 테스트합니다. 모델의 초기 성능을 이해하려면 기준부터 시작해야 합니다. 미세 조정 후 모델의 성능을 다시 평가하여 품질 표준을 충족하는지 확인합니다. 다음과 같은 일반적인 평가 메트릭을 고려합니다.
접지성은 원본 데이터와 모델의 맞춤을 나타냅니다. 접지된 모델은 현실과 일치하는 답변을 생성합니다.
관련성은 응답이 지정된 질문과 얼마나 관련이 있는지를 나타냅니다. 질문을 직접 해결하지 않는 경우 고도로 근거가 있는 답변은 관련성이 부족할 수 있습니다.
유사성 은 원본 데이터 텍스트와 생성된 응답 간의 유사성을 측정합니다. 모델이 정확한 표현을 사용했나요? 편집 거버넌스가 부족하면 유사성 점수를 낮출 수 있습니다.
검색은 인덱스 쿼리의 효과를 나타냅니다. 검색된 인덱스 데이터가 질문과 얼마나 잘 일치하는지 평가합니다. 인덱스 검색의 관련 없는 데이터는 이 점수를 낮춥니다. 검색 점수가 높을수록 인덱스 쿼리에만 의존하므로 가변성이 낮음을 나타냅니다.
유창성은 어휘 사용과 관련이 있습니다. 모델이 스타일 가이드를 준수하고 적절한 형식으로 콘텐츠를 표시하는 경우 접지 또는 관련성이 부족하더라도 유창할 수 있습니다.
일관성 은 모델의 음성이 자연스럽고 일관되게 흐르는지 여부를 평가합니다. 대화가 진정한 교환처럼 느껴지는지 여부를 평가합니다.
하이퍼 매개 변수 테스트
모델 매개 변수는 애플리케이션별 디자인 결정에 따라 달라집니다. 애플리케이션 디자인의 일부로 워크로드의 사용 사례에 따라 모델 및 매개 변수를 선택합니다. 테스트 프로세스에는 학습 데이터를 테스트 데이터와 비교하여 모델이 의도한 데이터 세트에 대해 학습하고 있는지 확인하는 반복적인 내부 루프가 있습니다. 또한 모델이 허용 가능한 수준의 정확도로 예측을 수행할 수 있도록 매개 변수가 조정됩니다.
트레이드 오프. 내부 루프에는 모델을 학습시키는 계산 비용과 테스트를 통해 평가하는 비용이 포함됩니다. 모델 학습 및 테스트에 필요한 시간을 이 루프로 고려해야 합니다. 테스트 프로세스가 학습 프로세스보다 오래 걸릴 것으로 예상합니다. 학습 데이터의 하위 집합에 대한 초기 테스트를 수행하여 모델이 적절한 결과를 생성하는지 여부를 평가할 수 있습니다. 해당 테스트 집합을 전체 데이터 세트로 점진적으로 확장할 수 있습니다.
유추 엔드포인트 테스트
유추 엔드포인트는 예측을 위해 모델에 액세스할 수 있는 REST API입니다. 요청의 일부로 데이터를 보내고 모델의 결과가 포함된 응답을 가져오는 인터페이스입니다. 엔드포인트는 Azure OpenAI Service와 같은 PaaS 또는 NVIDIA Triton 유추 서버, TorchServe 및 BentoML과 같은 비 Microsoft 추론 서버일 수 있는 컴퓨팅에서 호스트됩니다. PaaS 시나리오에서 서비스 공급자는 테스트를 어느 정도 처리합니다. 그러나 엔드포인트를 호스트하는 경우 다른 API처럼 처리하고 철저히 테스트합니다.
학습 및 평가 중에 모델을 테스트하지만 유추 엔드포인트를 테스트하려면 요청 처리, 응답 생성, 크기 조정 및 인스턴스 간 조정과 같은 해당 모델 관련 메커니즘이 올바르게 작동하는지 확인해야 합니다. 요구 사항에 따라 사용 사례를 다루는 포괄적인 테스트 계획을 만듭니다. 이 섹션에서는 고려해야 할 몇 가지 테스트 사례 및 테스트 유형에 대해 설명합니다.
유추 호스팅 서버에 대한 테스트 고려 사항
컴퓨팅의 부하 특성을 이해하고 부하 테스트를 통해 성능의 유효성을 검사하는 것이 중요합니다. 이러한 작업은 아키텍처를 설계하거나 최적화할 때 기술을 선택하는 데 도움이 됩니다. 예를 들어 추론 서버마다 성능 특성이 다릅니다. 이 코드는 동시 연결 수가 증가함에 따라 CPU 주기 및 메모리를 사용합니다. 표준 및 최대 부하 조건에서 코드 및 컴퓨팅 리소스가 수행하는 방식을 이해합니다. Azure Load Testing은 부하 테스트에 적합한 옵션이며 대용량 부하를 생성할 수 있습니다. Apache JMeter와 같은 다른 오픈 소스 옵션도 인기가 있습니다. 사용자 환경에서 직접 이러한 테스트를 호출하는 것이 좋습니다. 예를 들어 Machine Learning은 부하 테스트와 잘 통합됩니다.
또 다른 주요 결정은 GPU 기능 선택입니다. 많은 모델은 설계로 인해 효과적인 추론을 위해 GPU가 필요합니다. 부하 테스트를 사용하면 GPU SKU의 성능 제한을 이해하고 재정상의 중요한 고려 사항인 과잉 프로비전을 방지할 수 있습니다.
PaaS가 아닌 호스팅 플랫폼의 경우 API가 공개적으로 노출되기 때문에 보안이 중요합니다. 엔드포인트가 악용되거나 손상되지 않도록 하여 전체 시스템을 위태롭게 할 수 있도록 하는 것이 중요합니다. 이 엔드포인트를 다른 공용 엔드포인트와 함께 일상적인 보안 테스트의 일부로 포함합니다. 라이브 시스템에서 침투 테스트와 같은 테스트를 수행하는 것이 좋습니다. 보안의 또 다른 측면은 콘텐츠 안전입니다. 코드는 요청 및 응답 페이로드에서 유해한 콘텐츠를 감지하는 특수 API를 호출할 수 있습니다. 콘텐츠 안전 테스트를 용이하게 하기 위해 테스트에서 Azure AI Content Safety를 호출할 수 있습니다.
주요 전략은 보안 테스트에 대한 권장 사항을 참조하세요.
PaaS 유추 엔드포인트에 대한 테스트 고려 사항
클라이언트는 PaaS 서비스의 유추 엔드포인트에 요청을 보낼 때 오류를 예상해야 합니다. 시스템 오버로드, 응답하지 않는 백 엔드 및 기타 오류 조건으로 인해 오류가 발생할 수 있습니다. 서비스에 대한 오류 모드 분석을 수행하고 잠재적인 오류를 테스트합니다. 클라이언트 코드에서 완화 전략을 설계하고 구현하려면 실패 모드 분석이 필요합니다. 예를 들어 Azure OpenAI API는 HTTP 429 오류 응답 코드를 반환하여 요청을 제한합니다. 클라이언트는 재시도 메커니즘 및 회로 차단기를 사용하여 해당 오류를 처리해야 합니다. 자세한 내용은 실패 모드 분석을 수행하기 위한 권장 사항을 참조하세요.
PaaS 서비스를 테스트하면 종량제 또는 미리 프로비전된 컴퓨팅과 같은 관련 비용을 이해하기 때문에 서비스 SKU를 선택하는 데 도움이 될 수 있습니다. Azure 가격 계산기를 사용하여 워크로드, 빈도 및 토큰 사용량을 평가하여 최상의 청구 및 컴퓨팅 옵션을 결정합니다. 저비용 SKU를 사용하여 워크로드를 시뮬레이션하고 Azure OpenAI에 프로비전된 처리량 단위(PTU)와 같은 고급 옵션을 정당화합니다.
부하 테스트는 용량이 무한하기 때문에 종량제 컴퓨팅과 관련이 없습니다. 테스트는 한도 및 할당량의 유효성을 검사합니다. 종량제 컴퓨팅은 상당한 재정적 비용이므로 부하 테스트를 권장하지 않습니다. 그러나 분당 토큰 또는 분당 요청으로 측정되는 처리량을 확인하기 위해 테스트를 로드해야 합니다. 요청 크기와 같은 메트릭을 고려하는 표준 API와 달리 이 방법은 토큰을 기반으로 워크로드를 평가하여 사용량을 결정합니다. 핵심은 활성 사용자 수를 이해하고 그에 따라 처리량을 측정하는 것입니다. 자세한 내용은 처리량 측정을 참조하세요.
보안 컨트롤 사용
유추 서버 또는 PaaS 옵션을 사용하는지 여부에 관계없이 보안은 사용자의 책임입니다. API 엔드포인트를 사용하는 경우 탈옥 및 콘텐츠 안전 제어를 테스트하는 것이 중요합니다. 이러한 컨트롤을 무시할 수 없고 예상대로 작동하는지 확인합니다. 예를 들어 알려진 차단된 항목을 보내면 배포 전에 보안 컨트롤이 제대로 작동하고 있는지 확인하는 데 도움이 될 수 있습니다. 필요에 따라 이러한 테스트를 실행하거나 릴리스 프로세스에 통합하는 것이 좋습니다.
시스템에서 실수로 노출해서는 안 되는 정보를 노출할 수 있는지 테스트하는 것이 중요합니다. 예를 들어 시스템은 응답 페이로드에 개인 정보를 노출해서는 안 됩니다. 또한 클라이언트가 다른 ID를 위한 엔드포인트에 액세스할 수 없는지 테스트합니다. 보안 테스트를 수행하여 인증 및 권한 부여 메커니즘을 사용하는 API가 기밀 정보를 유출하지 않고 적절한 사용자 구분을 유지 관리하는지 확인합니다.
접지 데이터 테스트
데이터 디자인은 생성 모델의 효율성에 영향을 줍니다. 접지 데이터는 중요한 구성 요소입니다. 접지 데이터는 응답의 관련성을 높이기 위해 더 많은 컨텍스트를 제공합니다. 모델에 도달하기 전에 인덱싱됩니다. 이 인덱스는 사용자가 답변을 기다리는 동안 실시간으로 액세스됩니다.
엔드 투 엔드 테스트를 수행하고 해당 프로세스를 데이터 디자인의 일부로 통합합니다. 모델의 성능, 오케스트레이션, 인덱스, 전처리 및 원본 데이터를 기반으로 고객 환경의 결과를 평가하고 수량화하는 테스트 프로세스를 구현합니다. 품질 메트릭을 반복적으로 모니터링하고 측정합니다. 다음은 몇 가지 고려 사항입니다.
기능 및 통합 테스트를 사용하여 데이터 처리를 철저히 테스트합니다. 데이터가 예상대로 로드되고 모든 데이터가 있는지 확인합니다.
이전 버전과의 호환성을 위해 인덱스 스키마를 테스트합니다. 문서 또는 필드의 변경 내용을 테스트하여 새 버전이 이전 버전의 데이터를 계속 수용할 수 있는지 확인해야 합니다.
데이터가 인덱싱되기 전에 노이즈 및 바이어스를 줄이고 효율적인 쿼리를 가능하게 하기 위한 준비를 거칩니다. 이 프로세스에는 포함 전처리, 청크 및 계산이 포함되며, 각 단계에서는 데이터를 인덱스의 컨텍스트 또는 파일에 저장합니다. Azure AI Search에서 제공하는 기술 집합과 같은 오케스트레이션 파이프라인은 이러한 단계를 수행합니다. 오케스트레이션 코드를 테스트하여 누락된 단계가 없고 처리된 데이터가 고품질인지 확인해야 합니다.
테스트는 최신 버전에서 이전 데이터, 가상 값, 빈 테이블, 데이터 새로 고침 및 처리를 확인해야 합니다. 테스트 실패가 발생하는 경우 검색 쿼리 및 인덱스를 조정해야 할 수 있습니다. 이 프로세스에는 이전에 설명한 필터 및 기타 요소 조정이 포함됩니다. 테스트를 반복 작업으로 생각해야 합니다.
인덱스는 복잡하며 쿼리 성능은 인덱스 구조에 따라 달라질 수 있으며 부하 예측이 필요합니다. 적절한 부하 테스트는 요구 사항을 지원하는 데 사용할 수 있는 스토리지, 컴퓨팅 및 기타 리소스에 대한 다양한 SKU를 결정하는 데 도움이 될 수 있습니다.
모든 보안 컨트롤을 테스트해야 합니다. 예를 들어 데이터는 별도의 문서로 분할될 수 있습니다. 각 파티션에는 액세스 제어가 있습니다. 기밀성을 보호하기 위해 해당 컨트롤을 제대로 테스트해야 합니다.
오케스트레이터 테스트
RAG 애플리케이션의 핵심 구성 요소는 중앙 오케스트레이터입니다. 이 코드는 초기 사용자 질문과 관련된 다양한 작업을 조정합니다. 오케스트레이터 작업에는 일반적으로 사용자 의도, 접지 데이터를 조회하기 위한 인덱스에 대한 연결 및 유추 엔드포인트 호출에 대한 이해가 필요합니다. 에이전트가 REST API 호출과 같은 작업을 수행해야 하는 경우 이 코드는 컨텍스트 내에서 해당 작업을 처리합니다.
모든 언어로 오케스트레이션 코드를 개발하거나 처음부터 작성할 수 있습니다. 그러나 Azure AI Foundry 포털 또는 Apache Airflow의 DAG(Directed Acyclic Graphs)에서 프롬프트 흐름과 같은 기술을 사용하여 개발 프로세스를 가속화하고 간소화하는 것이 좋습니다. 프롬프트 흐름은 디자인 타임 환경을 제공합니다. 작업을 단위로 모듈화하고 각 단위의 입력 및 출력을 연결하여 궁극적으로 전체 프로세스를 나타내는 오케스트레이션 코드를 구성합니다.
오케스트레이션 코드를 격리합니다. 별도로 개발하고 액세스를 위해 온라인 엔드포인트 및 REST API를 사용하여 마이크로 서비스 로 배포합니다. 이 방법은 모듈화 및 배포의 용이성을 보장합니다.
테스트 관점에서 이 코드를 다른 코드와 같이 처리하고 단위 테스트를 수행합니다. 그러나 더 중요한 측면은 기능 및 통합 테스트를 통해 유효성을 검사할 수 있는 라우팅 논리와 같은 기능입니다. 프롬프트 엔지니어링을 테스트하여 코드가 사용자 의도를 감지하고 호출을 적절하게 라우팅할 수 있는지 확인합니다. 테스트용 프레임워크 및 라이브러리(예: Scikit-learn, PyTorch의 torch.testing 모듈, 바이어스 및 공정성 테스트를 위한 FairML, 모델 평가를 위한 TensorFlow 모델 분석)가 있습니다.
또한 오류 모드 테스트와 같은 런타임 테스트를 수행합니다. 예를 들어 토큰 제한과 관련된 잠재적인 오류를 테스트합니다.
특정 런타임 테스트는 결정을 내리는 데 도움이 될 수 있습니다. 부하 테스트를 실행하여 이 코드가 스트레스에서 어떻게 동작하는지 이해하고 용량 계획에 결과를 사용합니다. 이 코드는 다른 서비스에 도달해야 하는 아키텍처의 중요한 지점에 위치하므로 모든 호출에서 원격 분석을 수집하는 데 도움이 될 수 있습니다. 이 데이터는 로컬 처리 및 네트워크 호출에 소요되는 시간을 파악하고 잠재적 대기 시간과 같은 다른 구성 요소의 동작을 결정할 수 있습니다. 프롬프트 흐름과 같은 기술에는 이 프로세스를 용이하게 하는 기본 제공 원격 분석 기능이 있습니다. 그렇지 않으면 사용자 지정 코드에 원격 분석을 통합합니다.
참고 항목
이 코드를 테스트하는 것은 비용에 영향을 줍니다. 예를 들어 Azure OpenAI를 사용하여 유추 엔드포인트를 호스트하는 경우 스트레스 테스트는 시스템의 제한을 결정하는 데 도움이 되는 일반적인 방법입니다. 그러나 Azure OpenAI는 모든 호출에 대해 요금을 부과하므로 광범위한 스트레스 테스트 비용이 많이 들 수 있습니다. 요금을 최적화하는 한 가지 방법은 테스트 환경에서 사용되지 않는 Azure OpenAI의PTU를 사용하는 것입니다. 또는 유추 엔드포인트를 시뮬레이션할 수 있습니다.
보안 문제는 오케스트레이션 코드와 모델 모두에 적용됩니다. 모델의 보안을 깨뜨리는 것이 목표인 탈옥 테스트를 포함합니다. 공격자는 모델과 직접 상호 작용하지 않습니다. 먼저 오케스트레이션 코드와 상호 작용합니다. 오케스트레이션 코드는 사용자 요청을 수신하고 구문 분석합니다. 오케스트레이션 코드가 악의적인 요청을 수신하는 경우 해당 요청을 모델에 전달하고 잠재적으로 모델을 손상시킬 수 있습니다.
콘텐츠 안전은 또 다른 중요한 측면입니다. 챗봇 애플리케이션에서 오케스트레이션 코드는 채팅 텍스트를 받습니다. 코드 에서 콘텐츠 안전 서비스를 호출하는 것이 좋습니다. 분석을 위해 사용자 프롬프트와 접지 컨텍스트를 모두 보내고 위험에 대한 평가를 받습니다. 프롬프트 쉴즈는 대규모 언어 모델 입력을 분석하고 사용자 프롬프트 공격 및 문서 공격을 검색하는 통합 API로, 일반적인 두 가지 유형의 악의적 입력입니다.
보안 제어 및 인증은 RESTful 엔드포인트에 매우 중요 합니다. 인증을 관리하고 철저한 테스트를 확인해야 합니다.
모델 감쇠 방지
모든 모델에 대한 일반적인 문제는 시간에 따른 어느 정도의 성능 저하입니다. 워크로드의 내부 및 외부 변경으로 인해 결국 모델 및 해당 출력의 품질이 저하됩니다. 모델 감쇠는 다음 두 가지 방법으로 발생합니다.
입력 데이터가 변경되면 데이터 드리프트 가 발생합니다. 새 데이터 입력은 학습된 모델을 최신 상태로 만듭니다. 예를 들어 지구와 같은 특정 지리적 영역의 투표 패턴을 예측하는 모델이 있을 수 있습니다. 지구가 다시 그려지고 해당 지구 인구의 인구 통계가 변경되는 경우 변경 내용을 고려하여 모델을 업데이트해야 합니다.
개념 드리프트 는 모델 출력이 더 이상 현실과 일치하지 않는 방식으로 워크로드 및 모델 외부의 조건이 변경될 때 발생합니다. 예를 들어 기술 제품에 대한 판매 예측 모델이 있을 수 있습니다. 경쟁업체가 예기치 않게 대중의 관심을 끄는 고급 경쟁 제품을 도입하는 경우 소비자 추세가 어떻게 변하는지에 따라 모델을 업데이트해야 합니다.
가능하면 자동화된 테스트를 사용하여 모델의 수명 주기 동안 모델 감쇠를 감지하고 평가합니다. 모델이 불연속 값을 예측하는 경우 시간이 지남에 따라 해당 값에 대한 예측을 평가하고 예상 결과와 실제 결과 간의 편차를 측정하는 테스트를 만들 수 있습니다. 요약 통계 및 거리 메트릭을 비교하여 시간이 지남에 따라 드리프트를 감지하도록 모니터링으로 이 테스트를 보완합니다.
모델 붕괴를 식별하는 또 다른 일반적인 방법은 사용자 피드백입니다. 사용자 피드백의 예로는 엄지 손가락 또는 엄지 손가락 아래로 응답 메커니즘이 있습니다. 시간에 따른 긍정적 피드백과 부정적인 피드백을 추적하고 부정적인 피드백 임계값을 충족할 때 경고를 만들면 모델의 품질을 조사할 시기를 파악하는 데 도움이 될 수 있습니다.
모델 감쇠를 식별하는 데 사용하는 신호에 관계없이 잠재적인 부패에 대해 경고하는 운영 팀은 데이터 과학자와 협력하여 신호를 연구하고 부패가 일어나고 있는지 여부와 근본 원인을 확인해야 합니다.
도구 구현
Azure Machine Learning 데이터 수집기를 사용하여 관리되는 온라인 엔드포인트 또는 Kubernetes 온라인 엔드포인트에 배포된 모델에서 입력 및 출력 데이터의 실시간 로깅을 가져옵니다. Machine Learning은 기록된 유추 데이터를 Azure Blob Storage에 저장합니다. 그런 다음 이 데이터를 모델 모니터링, 디버깅 또는 감사에 사용할 수 있으며, 이를 통해 배포된 모델의 성능에 대한 가시성을 제공합니다. Machine Learning 외부 또는 Machine Learning 일괄 처리 엔드포인트에 모델을 배포하는 경우 데이터 수집기를 활용할 수 없으며 다른 데이터 수집 프로세스를 운영할 필요가 없습니다.
Machine Learning 모델 모니터링을 사용하여 모니터링을 구현합니다. Machine Learning은 스트리밍된 프로덕션 유추 데이터 및 참조 데이터에 대한 통계 계산을 수행하여 모니터링 신호를 획득합니다. 참조 데이터는 과거 학습 데이터, 유효성 검사 데이터 또는 실측 데이터일 수 있습니다. 반면, 프로덕션 유추 데이터는 프로덕션에서 수집된 모델의 입력 및 출력 데이터를 나타냅니다.
- Machine Learning의 모니터링 기능 및 이를 캡처하고 분석하는 메트릭에 대해 알아보려면 Machine Learning 모델 모니터링을 참조하세요.
- 모니터링에 대한 추가 권장 사항은 모범 사례를 참조하세요.