50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
HOTSPOT - 문장을 완성하려면 답안 영역에서 적절한 옵션을 선택하세요. 핫 영역:
대출이 상환될지 여부를 예측하는 은행 시스템은 기계 학습의 ______ 유형의 예입니다.
정답: A (classification). 대출이 상환될지 여부를 예측하는 것은 지도 학습 문제이며, 목표는 “상환됨” vs “상환되지 않음”(default)과 같은 이산적인 레이블입니다. 이것이 classification의 정의입니다. 즉, 과거의 레이블이 있는 예시(결과가 알려진 과거 대출)로부터 학습하여 새로운 사례에 대해 범주를 예측합니다. 왜 regression (B)가 아닌가: Regression은 출력이 연속적인 수치 값일 때 사용됩니다. 예를 들어 정확한 대출 손실 금액, 이자율, 또는 고객 생애 가치(customer lifetime value)를 예측하는 경우입니다. 신용 모델이 확률(숫자)을 출력할 수도 있지만, 설명된 핵심 과제—“대출이 상환될지 여부”—는 범주형 판단입니다. 왜 clustering (C)가 아닌가: Clustering은 비지도 학습으로, 알려진 레이블 없이 유사성에 따라 데이터 포인트를 그룹화합니다(예: 상환 결과가 없을 때 고객을 위험 그룹으로 세분화). 여기서는 은행이 명확한 결과 예측을 원하므로, 레이블이 있는 학습 데이터와 classification이 필요합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Computer Vision 서비스를 사용하여 수행할 수 있는 두 가지 작업은 무엇입니까? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택은 1점입니다.
오답입니다. 사용자 지정 이미지 분류 모델을 학습시키는 작업은 일반적으로 Azure AI Custom Vision에서 수행하며, 이는 레이블이 지정된 이미지를 사용해 사용자 지정 분류기와 객체 감지기를 구축하고 학습하도록 설계되었습니다. Computer Vision 서비스는 자체 분류 모델을 학습시키기보다는 사전 구축 분석(태그, 캡션, OCR 등)에 초점을 둡니다. AI-900에서는 “사용자 지정 학습”이라는 단서가 Custom Vision을 가리키는 핵심 힌트입니다.
정답입니다. Computer Vision은 이미지에서 얼굴을 찾아 위치를 지정하고 bounding box를 반환하여 얼굴을 감지할 수 있습니다(그리고 API/버전 및 정책 제약에 따라 때로는 관련 특성도 포함). 이는 신원 인식이 아닌 얼굴 감지입니다. AI-900에서는 “얼굴 감지”를 Computer Vision 기능으로 보고, 사람 식별/검증은 Face 서비스와 연관되며 추가 거버넌스 요구 사항이 있다고 이해하면 됩니다.
정답입니다. 손글씨 텍스트 인식은 Computer Vision OCR(종종 Read 기능으로 지칭됨)을 통해 지원됩니다. 이미지와 문서에서 인쇄 및 손글씨 텍스트를 모두 추출할 수 있으며, 텍스트와 함께 위치 정보를 반환합니다. 이는 메모, 양식, 스캔 서류를 디지털화하는 일반적인 워크로드이며, AI-900에서 Computer Vision 기능의 표준 예시입니다.
오답입니다. 언어 간 텍스트 번역은 Azure AI Translator(NLP 서비스)가 수행합니다. Computer Vision은 OCR을 사용해 이미지에서 텍스트를 추출할 수는 있지만, 이를 번역하지는 않습니다. 일반적인 솔루션은 2단계 파이프라인입니다: Computer Vision(OCR)로 텍스트를 읽고, 그다음 Translator로 추출된 텍스트를 대상 언어로 번역합니다.
핵심 개념: 이 문제는 Azure AI Vision(AI-900에서 일반적으로 Computer Vision 서비스로 지칭됨)으로 무엇을 할 수 있는지 평가합니다. Computer Vision은 이미지 분석 및 객체, 태그, 캡션, OCR 텍스트, 얼굴 관련 감지(기능 가용성과 Responsible AI 제약에 따라 다름)와 같은 정보를 추출하기 위한 사전 구축 모델을 제공합니다. 정답이 맞는 이유: B(이미지에서 얼굴을 감지)는 Computer Vision에서 지원하는 기능입니다. 이 서비스는 얼굴의 존재와 위치를 감지할 수 있으며(예: bounding box 반환), 시험 맥락에서 “얼굴 감지”는 “사람을 식별/검증”하는 것과 구분되며, 후자는 더 엄격한 액세스 요구 사항이 있는 Azure Face(별도의 기능/서비스 영역)에서 처리됩니다. C(손글씨 텍스트 인식) 또한 Optical Character Recognition(OCR)을 통한 Computer Vision의 핵심 기능입니다. Azure AI Vision Read/OCR은 이미지와 문서에서 인쇄 및 손글씨 텍스트를 추출하여 인식된 텍스트와 레이아웃/좌표를 반환할 수 있습니다. 주요 기능 및 모범 사례: - OCR/Read는 인쇄 및 손글씨 텍스트를 모두 지원하며, 양식, 영수증, 메모, 스캔 문서의 디지털화에 흔히 사용됩니다. - 얼굴 감지는 기하학적 정보(bounding box/landmark)를 반환하지만, 본질적으로 신원 인식을 수행하지는 않습니다. - Azure Well-Architected 관점에서, 관리형 AI 서비스를 사용하면 운영 부담을 줄일 수 있으며(Operational Excellence), Responsible AI 및 개인정보 보호 요구 사항(Security)을 준수할 수 있습니다. 흔한 오해: A는 “이미지 분류”가 비전 작업이므로 그럴듯해 보이지만, 사용자 지정 이미지 분류 모델 학습은 사전 구축 Computer Vision 서비스가 아니라 Azure AI Custom Vision(별도 서비스)에서 수행합니다. D는 OCR이 텍스트를 추출하므로 그럴듯해 보이지만, 언어 간 텍스트 번역은 Azure AI Translator가 수행하는 NLP 작업입니다. 일반적인 패턴은 Computer Vision OCR로 텍스트를 추출한 다음 Translator로 번역하는 것입니다. 시험 팁: - 구분을 기억하세요: 사전 구축 이미지 분석/OCR/얼굴 감지 = Computer Vision; 분류/감지를 위한 사용자 지정 학습 = Custom Vision. - 번역은 비전 기능이 아니라 Translator에서 처리합니다. - 표현에 주의하세요: “얼굴 감지”(가능) vs “사람 인식/식별”(AI-900 관점에서 Computer Vision 아님).
귀사는 병 재활용 기계를 구축하려고 합니다. 재활용 기계는 올바른 형태의 병을 자동으로 식별하고 다른 모든 물품은 거부해야 합니다. 회사는 어떤 유형의 AI 워크로드를 사용해야 합니까?
anomaly detection은 기준선과 비교해 드물거나 비정상적인 패턴을 식별하는 데 초점을 맞추며, 일반적으로 센서 telemetry, 로그 또는 트랜잭션과 같은 수치 데이터에서 사용됩니다. 제조에서 “정상”이 무엇인지 대부분 알고 있을 때 defect detection에 사용할 수도 있습니다. 그러나 이 문제의 핵심 요구사항은 이미지에서 병 형태를 시각적으로 식별하는 것이므로, computer vision 분류/감지가 더 적합합니다.
conversational AI는 자연어를 사용한 상호작용 경험(예: 챗봇, 음성 봇)을 위해 설계되었습니다. 여기에는 의도 인식, 대화 관리, 응답 생성(예: Azure Bot Service)이 포함됩니다. 재활용 기계가 병 형태를 식별하는 것은 대화 또는 대화형 문제(dialog)가 아니므로, conversational AI는 설명된 워크로드에 적합하지 않습니다.
computer vision이 정답인 이유는 기계가 물품이 올바른 병 형태와 일치하는지 시각적으로 인식하고 다른 물품을 거부해야 하기 때문입니다. 이는 image classification 및/또는 object detection에 해당합니다. Azure에서는 사전 구축 기능을 위해 Azure AI Vision을 사용하거나, 다양한 조명과 방향에서의 특정 병 형태로 모델을 학습시키기 위해 Custom Vision을 사용하여 정확한 자동 수락/거부를 구현할 수 있습니다.
natural language processing (NLP)은 텍스트 또는 speech-to-text 시나리오에서 인간 언어를 이해하고 생성하는 작업(감성 분석, 엔터티 추출, 번역, 요약 등)을 다룹니다. 재활용 기계의 입력은 텍스트나 음성 언어가 아니라 물품의 물리적 외형(형태)이므로, NLP는 적절한 AI 워크로드가 아닙니다.
핵심 개념: 이 시나리오는 computer vision 워크로드입니다. 즉, 이미지/비디오를 사용하여 시각적 특성(형태, 크기, 윤곽선)에 기반해 물리적 객체를 감지, 분류 또는 검증하는 것입니다. Azure AI 용어로는 Azure AI Vision(이미지 분석) 및 Custom Vision(항목을 분류하거나 객체를 감지하도록 모델 학습)과 같은 서비스에 해당합니다. 정답인 이유: “올바른 형태의 병을 식별하고 다른 모든 물품은 거부”해야 하는 재활용 기계는 물품을 시각적으로 검사해야 합니다. 핵심 요구사항은 객체의 형태를 인식하고 허용된 클래스(올바른 병)와 일치하는지 여부를 판단하는 것입니다. 이는 전형적인 image classification(이것이 허용된 병 유형인가?) 및/또는 object detection(병이 어디에 있으며 어떤 유형인가?)에 해당하며, 둘 다 computer vision 작업입니다. 주요 기능 / 일반적인 구현 방식: - Image classification: 허용되는 병 vs. 병이 아닌/기타 물품의 라벨링된 이미지로 모델을 학습합니다. 모델은 각 클래스에 대한 확률을 출력합니다. - Object detection: 물품이 서로 다른 위치/방향으로 나타나는 경우, detection이 객체를 찾고 분류할 수 있습니다. - Custom Vision: 일반적인 라벨이 아니라 도메인 특화 인식(귀사의 병 형태)이 필요할 때 자주 사용됩니다. - 운영 고려사항: 조명, 각도, 가림(occlusions), 병 변형을 아우르는 충분한 학습 데이터를 사용하고, 테스트 세트로 검증하며, drift(새로운 병 디자인)를 모니터링합니다. edge/실시간 요구가 있으면 지연 시간을 줄이기 위해 edge 디바이스(예: Azure IoT Edge)에 배포합니다. 흔한 오해: “다른 모든 물품을 거부”가 “이상치(outliers) 탐지”처럼 보일 수 있어 anomaly detection이 그럴듯하게 들릴 수 있습니다. 그러나 anomaly detection은 일반적으로 수치/시계열 데이터(센서 판독값, 트랜잭션)에서 비정상 패턴을 찾거나, 정상 예시는 많고 비정상 예시는 적은 경우의 “defect detection”에 사용됩니다. 여기서 주요 신호는 시각적 형태 인식이므로 computer vision이 적합합니다. 시험 팁: 입력이 이미지/비디오(카메라)이고 목표가 객체, 형태, 이미지 내 텍스트, 장면을 인식하는 것이라면 computer vision을 선택하십시오. NLP는 텍스트/언어, conversational AI는 챗봇/음성 비서, anomaly detection은 메트릭 또는 센서/telemetry 스트림의 이상치 탐지에 사용합니다. (Well-Architected 연계: reliability와 performance를 위해 낮은 지연 시간과 복원력을 고려한 edge inference를 검토하고, security를 위해 카메라 피드와 모델 엔드포인트를 보호하며, cost optimization을 위해 컴퓨팅을 적정 규모로 맞추고 필요할 때만 재학습을 수행하십시오.)
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Labeling은 학습 데이터를 알려진 값으로 태깅하는 과정입니다.
예. Labeling은 각 학습 예제를 올바른 알려진 값(“ground truth”)과 연관시키는 과정입니다. Supervised learning에서 이러한 label은 모델이 예측하도록 학습하는 대상입니다. 예를 들어, 이미지를 “cat” 또는 “dog”로 태깅하거나, 이메일을 “spam” 또는 “not spam”으로 표시하거나, “house price”와 같은 regression을 위한 숫자 target 값을 할당하는 것입니다. Labeling은 사람이 수동으로 수행할 수도 있고, 규칙이나 기존 시스템이 ground truth를 제공하는 경우 programmatically 수행할 수도 있으며, assisted labeling tools를 통해 수행할 수도 있습니다. Label이 없으면 일반적으로 unsupervised learning(clustering, dimensionality reduction) 또는 self-supervised 접근으로 넘어가며, 이는 다른 문제 유형입니다. 따라서 이 문장은 labeling을 학습 데이터를 알려진 값으로 태깅하는 것으로 올바르게 설명합니다.
모델을 학습하는 데 사용한 동일한 데이터를 사용하여 모델을 평가해야 합니다.
아니요. 모델을 학습하는 데 사용한 동일한 데이터를 사용하여 모델을 평가해서는 안 됩니다. 이는 일반화 성능을 측정하지 못하기 때문입니다. 학습 성능은 실제 환경 성능보다 더 좋아 보이는 경우가 많으며, 특히 모델이 과적합(노이즈를 학습하거나 예시를 암기)하는 경우 그렇습니다. 올바른 평가는 학습 중에 모델이 보지 못한 별도의 test dataset(또는 validation dataset)을 사용합니다. 일반적인 접근 방식에는 train/test split, train/validation/test split, 그리고 cross-validation이 포함됩니다. 이는 모델이 새로운 데이터에서 어떻게 동작할지 추정하는 데 도움이 되며, 모델 선택과 hyperparameter tuning에 대해 더 나은 의사결정을 지원합니다. 학습 데이터를 평가에 사용하면 개발 단계에서는 정확해 보이지만 production에서는 실패하는 모델을 배포하게 될 수 있습니다.
Accuracy는 항상 모델의 성능을 측정하는 데 사용되는 주요 지표이다.
아니오. Accuracy가 항상 주요 지표인 것은 아니다. 최적의 지표는 작업의 특성과 서로 다른 오류 유형이 초래하는 결과에 따라 달라진다. 불균형 분류(예: 사기 탐지)에서는, 모델이 다수 클래스를 항상 예측하기만 해도 높은 Accuracy를 달성할 수 있지만 소수 클래스를 완전히 놓칠 수 있다. 이런 경우 recall(sensitivity), precision, F1-score, PR-AUC가 더 유용한 경우가 많다. false positive의 비용이 큰 경우(정상 거래를 사기로 표시)에는 precision이 더 중요할 수 있고, false negative의 비용이 큰 경우(사기를 놓침)에는 recall이 우선될 수 있다. 회귀 문제에서는 Accuracy가 표준 지표가 아니며, MAE나 RMSE 같은 지표를 사용한다. 따라서 Accuracy는 모델 성능의 보편적인 주요 측정값이 아니다.
분류 모델을 평가하는 데 사용할 수 있는 metric은 무엇입니까?
True positive rate (TPR)는 confusion matrix에서 도출되는 분류 metric입니다. 이는 실제 positive 중에서 positive로 올바르게 예측된 비율을 측정합니다: TP/(TP+FN). TPR은 recall 또는 sensitivity로도 알려져 있으며, medical screening이나 fraud detection처럼 positive 사례를 놓치는 것(false negative)의 비용이 큰 경우에 특히 유용합니다.
Mean absolute error (MAE)는 주로 회귀 metric입니다. 이는 예측된 숫자 값과 실제 숫자 값 간의 평균 절대 차이를 측정합니다. 분류 출력은 이산 label(또는 일반적으로 threshold를 적용해 label로 변환되는 class probability)이므로, MAE는 AI-900 맥락에서 분류 성능을 평가하는 표준적인 방법이 아닙니다.
Coefficient of determination (R2)는 연속 target variable의 분산을 모델이 얼마나 잘 설명하는지 나타내는 회귀 metric입니다. 값이 1에 가까울수록 일반적으로 회귀 문제에서 더 좋은 적합을 의미합니다. 이는 이산 class 예측을 평가하는 데 사용되지 않으며 confusion matrix에서 나오지도 않으므로, 분류 평가에 적절하지 않습니다.
Root mean squared error (RMSE)는 예측된 숫자 값과 실제 숫자 값 간의 제곱 차이의 평균에 대한 제곱근을 측정하는 회귀 metric입니다. RMSE는 MAE보다 큰 오차에 더 큰 penalty를 부여하므로 연속 예측 작업에 유용합니다. 이는 분류 모델의 표준 metric이 아니며, 분류는 precision과 recall 같은 confusion matrix metric으로 평가합니다.
핵심 개념: 이 문제는 서로 다른 머신 러닝 문제 유형에 대해 적절한 평가 metric을 선택할 수 있는 능력을 테스트합니다. AI-900에서는 분류(이산적인 class/label 예측)와 회귀(연속적인 숫자 값 예측)를 구분해야 합니다. 분류 모델은 일반적으로 accuracy, precision, recall, F1-score, true/false positive/negative rate와 같은 confusion matrix 기반 metric으로 평가합니다. 정답이 맞는 이유: True positive rate (TPR)(recall 또는 sensitivity라고도 함)은 분류 모델이 실제 positive 사례를 얼마나 잘 식별하는지 측정합니다: TPR = TP / (TP + FN). 이는 confusion matrix에서 도출되며(특히 positive class에 대해) 분류 성능을 직접적으로 반영하므로, 분류 모델을 평가하는 데 유효한 metric입니다. TPR은 positive를 놓치는 것이 비용이 큰 경우(예: fraud detection, disease screening, safety alerts)에 특히 중요합니다. 주요 특징 / Best Practices: 실제 분류에서는 종종 결정 threshold(예: probability cutoff)를 조정하여 TPR(recall)과 false positive rate (FPR) 간의 trade-off를 맞춥니다. 이는 ROC curve로 시각화되며 AUC로 요약됩니다. Imbalanced dataset에서는 accuracy가 오해를 불러일으킬 수 있으므로, TPR/recall, precision, F1-score, PR-AUC 같은 metric이 더 유용한 경우가 많습니다. Azure ML 또는 Azure AI services에서는 분류 평가 시 이러한 confusion matrix metric을 일반적으로 보고합니다. 흔한 오해: MAE와 RMSE는 널리 쓰이는 metric이어서 학습자가 이를 보편적으로 적용하려고 하는 경우가 있습니다. 하지만 이들은 평균적인 숫자 오차 크기를 측정하며 회귀를 위해 설계되었습니다. R2(coefficient of determination) 또한 회귀에 적용되며, 연속 target에서 모델이 설명하는 분산의 정도를 나타냅니다. 이들은 이산 class 예측의 정답 여부를 직접 측정하지 않습니다. 시험 팁: 먼저 workload를 식별하세요: 분류 vs 회귀. 선택지에 MAE/RMSE/R2가 있으면 회귀입니다. precision/recall/TPR/F1/ROC-AUC가 보이면 분류입니다. 또한 “true positive rate”는 본질적으로 positive class에 대한 “recall”이며, false negative가 중요할 때 핵심 metric이라는 점을 기억하세요.
자동화된 machine learning 사용자 인터페이스(UI)를 사용하여 machine learning 모델을 빌드합니다. Responsible AI를 위한 Microsoft 투명성 원칙을 모델이 충족하도록 보장해야 합니다. 무엇을 해야 합니까?
Validation type을 Auto로 설정하면 AutoML이 일반화 성능을 추정하기 위해 학습/검증 데이터 분할(또는 cross-validation 사용) 방식을 제어합니다. 이는 평가 품질을 개선하고 overfitting 위험을 줄일 수 있지만, 모델 의사결정에 대한 해석 가능성이나 설명을 제공하지는 않습니다. 따라서 Responsible AI 투명성 원칙을 직접적으로 해결하지 않습니다.
“Explain best model”을 활성화하면 AutoML이 찾은 최적 모델에 대해 feature importance 및 explanation 아티팩트와 같은 해석 가능성 출력이 생성됩니다. 이는 어떤 입력이 예측을 주도하는지 사용자가 이해하도록 돕고, 이해관계자에게 모델 동작을 전달하는 것을 지원합니다. 이러한 설명은 Azure ML AutoML에서 Responsible AI 투명성 원칙을 충족하기 위한 직접적인 메커니즘입니다.
Primary metric을 accuracy로 설정하는 것은 AutoML에서 최적 모델을 선택할 때 사용하는 최적화 대상(예: accuracy vs. AUC vs. F1)만 변경합니다. 적절한 metric 선택은 모델 품질에 중요하지만, 모델을 더 이해하기 쉽게 만들거나 예측이 어떻게 생성되는지에 대한 통찰을 제공하지는 않습니다. 투명성에는 성능 metric이 아니라 설명이 필요합니다.
Max concurrent iterations는 병렬로 실행되는 AutoML 학습 iteration 수를 제어하여 학습 속도 및 잠재적으로 비용/리소스 사용량에 영향을 줍니다. 값 0은 투명성 기능이 아니며 compute 스케줄링 및 처리량과 관련됩니다. Concurrency 설정은 해석 가능성 아티팩트를 생성하거나 이해관계자의 모델 동작 이해를 향상시키지 않습니다.
핵심 개념: 이 문제는 Responsible AI의 투명성 원칙과 Azure Machine Learning Automated ML(AutoML)이 이를 어떻게 지원하는지를 평가합니다. 투명성은 이해관계자가 모델이 예측을 수행하는 방식과 이유를 이해할 수 있어야 함을 의미하며, 어떤 feature가 결과에 가장 큰 영향을 미치는지와 모델이 학습한 패턴을 포함합니다. 정답이 맞는 이유: Automated ML UI에서 “Explain best model”을 활성화하면 선택된/최고 성능 모델에 대한 모델 설명(해석 가능성 아티팩트)이 생성됩니다. 이는 feature importance 및 관련 해석 가능성 출력물을 제공하여 사용자가 모델의 동작을 이해하는 데 도움이 됩니다. 설명을 제공하는 것은 투명성의 직접적인 구현으로, 모델을 “black box”가 덜 되게 하고, 문서화를 지원하며, 비즈니스 사용자, 감사자, 영향을 받는 개인에게 의사결정 로직을 전달하는 데 도움이 됩니다. 주요 기능 및 모범 사례: “Explain best model”이 활성화되면 Azure ML은 global feature importance(예측의 전반적 주요 요인)를 계산할 수 있으며, 구성/모델 유형에 따라 개별 예측에 대한 local explanation도 제공할 수 있습니다. 이러한 아티팩트는 studio UI에서 검토할 수 있고 보고서에 사용할 수 있습니다. Azure Well-Architected Framework 관점에서 투명성은 Operational Excellence(시스템 동작에 대한 더 나은 모니터링 및 이해)와 Reliability/Security(예상치 못하거나 위험한 모델 동작을 더 쉽게 탐지)에 기여합니다. 일반적인 오해: “더 나은 평가”를 “투명성”과 혼동하기 쉽습니다. Validation type과 primary metric은 성능을 측정하는 방식에 영향을 주지만, 의사결정을 설명하는 방식에는 영향을 주지 않습니다. 마찬가지로 concurrency 설정은 속도/비용에 영향을 주지만 해석 가능성에는 영향을 주지 않습니다. accuracy가 매우 높은 모델이라도 투명하지 않을 수 있습니다. 시험 팁: AI-900에서는 Responsible AI 원칙을 구체적인 Azure 기능에 매핑하세요: - Transparency/Interpretability: 모델 설명(예: AutoML의 “Explain best model”). - Fairness: fairness 평가/metrics. - Privacy & security: 데이터 보호 제어. - Reliability & safety: 견고한 평가/모니터링. “transparency”가 보이면 “explain”, “interpretability”, “feature importance”를 찾으세요.
HOTSPOT - 문장을 완성하려면 답안 영역에서 적절한 옵션을 선택하세요. 핫 영역:
배달원이 받은 주문 수를 기반으로 몇 시간의 초과근무를 할지 예측하는 것은 ______의 예입니다.
정답: C (regression). “몇 시간의 초과근무”를 예측하는 것은 숫자 값(예: 0, 2.5, 6)을 산출합니다. 목표/출력 변수가 연속적인 숫자일 때 ML 작업은 regression입니다. 여기서 입력 feature는 받은 주문 수이며, 모델은 라벨이 있는 과거 데이터(지도 학습)를 사용해 주문 수와 초과근무 시간 간의 관계를 학습합니다. 왜 A (classification)가 아닌가? classification은 “초과근무 여부: yes/no” 또는 “초과근무 구간: low/medium/high”처럼 이산적인 라벨이나 범주를 예측합니다. 만약 질문이 초과근무를 할지 여부를 물었다면 classification이 맞습니다. 하지만 이 문제는 시간(숫자)을 묻고 있습니다. 왜 B (clustering)가 아닌가? clustering은 비지도 학습으로, 알려진 목표 라벨 없이 유사한 레코드를 그룹화합니다(예: 배달원을 행동 세그먼트로 묶기). 이 시나리오는 알려진 숫자 목표를 명시적으로 예측하므로 clustering은 적절하지 않습니다.
HOTSPOT - 다음 각 문장에 대해 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure Machine Learning designer는 machine learning 모델을 구축, 테스트 및 배포하기 위한 드래그 앤 드롭 방식의 시각적 캔버스를 제공합니다.
예. Azure Machine Learning designer는 machine learning 워크플로를 구축하기 위한 드래그 앤 드롭 방식의 시각적 캔버스입니다. 모듈을 추가하고 연결하여 데이터 가져오기, 데이터 정리/변환, 모델 학습(예: classification/regression 모듈), scoring, 결과 평가와 같은 작업을 수행할 수 있습니다. 워크플로를 검증한 후에는 pipeline으로 게시하고 배포하여 운영화할 수 있습니다(일반적으로 워크플로에 따라 real-time endpoint 또는 batch pipeline으로 배포). 이는 Azure에서 no-code/low-code ML 도구를 식별하는 AI-900의 강조점과 일치합니다. “아니요” 옵션은 부정확한데, designer의 핵심 가치 제안이 바로 학습 코드를 처음부터 작성하지 않고도 ML 모델을 구축, 테스트 및 배포할 수 있는 이러한 시각적 접근 방식이기 때문입니다(물론 Azure ML에는 코드 기반 접근 방식도 존재합니다).
Azure Machine Learning designer를 사용하면 진행 상황을 pipeline draft로 저장할 수 있습니다.
예. Azure ML designer는 진행 중인 작업을 저장하는 것을 포함하여 반복적 개발을 지원합니다. designer 환경에서는 pipeline graph를 구축하는 동안 변경 사항을 저장할 수 있으며, 실행 가능한 pipeline로 게시/제출하기 전에 draft 상태로 pipeline에서 작업할 수 있습니다. 이는 실험과 협업에 중요합니다. module, parameter, connection을 점진적으로 조정한 다음 pipeline을 실행하여 결과를 비교할 수 있습니다. “아니요” 옵션은 진행 상황 저장이 designer 작성 환경의 표준 기능이므로 틀립니다. 시험 관점에서 designer는 빠른 프로토타이핑과 반복 가능한 workflow(pipeline)를 지원하도록 설계되었으며, 이는 대규모로 게시 및 실행하기 전에 draft/편집 내용을 저장할 수 있는 기능을 자연스럽게 포함한다는 점을 기억하세요.
Azure Machine Learning designer를 사용하면 사용자 지정 JavaScript 함수를 포함할 수 있습니다.
아니요. Azure Machine Learning designer는 ML 워크플로의 일부로 사용자 지정 JavaScript 함수를 포함할 수 있는 메커니즘을 제공하지 않습니다. Designer는 기본 제공 모듈과 ML 중심의 확장성을 사용하여 ML 파이프라인을 구성하는 데 초점을 둡니다. 사용자 지정 로직이 필요할 때 일반적으로 지원되는 접근 방식은 Python 기반 사용자 지정(예: Execute Python Script 같은 모듈) 또는 Azure ML 실행 환경에서 코드를 실행하는 사용자 지정 구성 요소를 만드는 것입니다. “예”를 선택하면 Azure ML designer를 웹 개발 또는 클라이언트 측 확장성 패턴과 혼동하게 됩니다. JavaScript는 Azure ML 파이프라인 내부에서 학습/채점 로직을 확장하는 표준 방식이 아닙니다. AI-900의 핵심 요점은 다음과 같습니다. designer는 ML 모듈을 사용하는 로우코드이며, 사용자 지정 코드 통합은 일반적으로 JavaScript 함수가 아니라 Python(또는 패키징된 구성 요소)을 통해 수행됩니다.
자동차 간의 거리를 추정할 수 있도록 이미지에서 자동차의 위치를 결정해야 합니다. 어떤 유형의 computer vision을 사용해야 합니까?
OCR은 이미지(인쇄 또는 필기)에서 텍스트를 추출하여 인식된 문자와 종종 텍스트 레이아웃 내 위치를 반환합니다. 표지판, 청구서, 양식 또는 번호판 텍스트를 읽는 시나리오에 사용됩니다. 자동차와 같은 비텍스트 객체를 감지하거나 위치를 특정하지 않으므로, 거리 추정을 위한 자동차 위치 결정에는 도움이 되지 않습니다.
Object detection이 올바른 선택인 이유는 이미지에서 각 자동차를 식별하고 일반적으로 bounding box 형태로 그 위치를 반환하기 때문입니다. 그 위치 데이터는 자동차 사이의 거리를 추정하려는 경우 필요하며, 초기 추정이 이미지 또는 pixel 공간에서만 이루어지더라도 마찬가지입니다. Classification과 달리 object detection은 같은 이미지에 있는 여러 자동차를 처리하고 각각이 어디에 나타나는지 구분할 수 있습니다. AI-900 기준으로 이것은 객체의 유형과 위치를 모두 판단하는 표준 workload입니다.
image classification은 전체 이미지에 label(또는 tags 집합)을 부여합니다(예: “자동차 포함”). 하지만 각 자동차의 좌표를 제공하지 않습니다. 자동차 간의 거리를 추정하려면 이미지에서 각 자동차가 어디에 있는지 알아야 하므로, 자동차의 존재를 올바르게 인식하더라도 classification만으로는 충분하지 않습니다.
face detection은 사람 얼굴의 위치를 찾고 때로는 얼굴 속성을 분석하는 데 초점을 둔 특수한 computer vision 작업입니다. 위치(bounding boxes)를 반환하긴 하지만, 얼굴에 대해 학습되고 최적화되어 있으며 차량에는 적합하지 않습니다. 자동차의 위치를 찾고 자동차 간 거리를 측정하려면 자동차를 감지하도록 학습된 일반 object detection을 사용해야 합니다.
핵심 개념: 이 문제는 이미지에서 객체가 무엇인지와 어디에 나타나는지를 모두 식별하기 위한 올바른 computer vision workload를 선택하는 것에 관한 것입니다. AI-900에서 자동차의 위치를 찾는 올바른 workload는 object detection이며, 이는 일반적으로 bounding box 형태로 감지된 각 객체의 위치를 반환하기 때문입니다. 정답인 이유: 자동차 사이의 거리를 추정하려면 먼저 이미지에서 각 자동차의 위치를 알아야 합니다. Object detection은 감지된 각 자동차의 좌표를 제공하므로 상대적인 위치를 비교할 수 있게 해줍니다. 실제 물리적 거리를 추정하려면 추가적인 calibration 또는 depth 정보가 필요할 수 있지만, 객체 위치를 제공하는 vision task는 여전히 object detection입니다. 주요 특징: Object detection은 하나의 이미지에서 동일한 object class의 여러 인스턴스를 찾고 각각에 대해 bounding box를 제공할 수 있습니다. 따라서 자동차 수 세기, 보행자 위치 찾기, 장면에서 항목 추적과 같은 시나리오에 적합합니다. 시험에서는 object detection을 “무엇인가?”와 “어디에 있는가?”에 모두 답하는 workload로 기억하세요. 흔한 오해: Image classification은 이미지에 무엇이 포함되어 있는지만 알려주며, 객체가 어디에 있는지는 알려주지 않습니다. OCR은 텍스트를 읽는 용도에만 해당하고, face detection은 차량과 같은 일반 객체가 아니라 사람 얼굴 감지에만 제한됩니다. 흔한 함정은 자동차가 존재하므로 classification을 선택하는 것이지만, classification은 좌표를 제공하지 않습니다. 시험 팁: 문제에서 위치, 좌표, bounding box, 개별 객체 수 세기, 또는 이미지에서 항목 간 거리 측정을 언급하면 보통 object detection이 정답입니다. 이미지의 전체 주제만 묻는다면 classification을 떠올리세요. 단어를 읽는 것을 묻는다면 OCR을 떠올리세요.
자주 묻는 질문(FAQ) PDF 파일이 있습니다. FAQ를 기반으로 하는 대화형 지원 시스템을 만들어야 합니다. 어떤 서비스를 사용해야 합니까?
QnA Maker는 FAQ 스타일의 소스(PDF 포함)로부터 질문-답변 지식 베이스를 만들고, 대화형 경험을 위한 엔드포인트로 게시하도록 구축되었습니다. 답변 랭킹, 신뢰도 점수, 다중 턴 후속 질문, active learning을 지원합니다. 일반적으로 Azure Bot Service와 통합하여 최소한의 사용자 지정 모델 학습으로 FAQ 콘텐츠를 사용해 응답하는 chatbot을 제공합니다.
Text Analytics(Azure AI Language의 일부)는 감정, 핵심 구, 명명된 엔터티, 언어 감지와 같은 텍스트 인사이트를 추출합니다. 사용자 질문을 가장 잘 매칭되는 FAQ 답변에 매핑하는 지식 베이스를 기본적으로 구축하지는 않습니다. 지원 시스템을 보완(예: 고객 메시지 분석)할 수는 있지만, FAQ 기반 대화형 Q&A를 위한 주 서비스는 아닙니다.
Computer Vision은 이미지와 비디오(OCR, 이미지 분류, 객체 감지 등)를 분석합니다. FAQ PDF를 기반으로 한 대화형 지원 시스템은 주로 자연어 질문-답변 문제이며, 이미지 이해 워크로드가 아닙니다. OCR로 스캔 문서에서 텍스트를 추출할 수는 있지만, chatbot에 필요한 Q&A 매칭 및 지식 베이스 기능을 제공하지는 못합니다.
Language Understanding (LUIS)는 사용자 의도를 식별하고 엔터티를 추출하여 애플리케이션에서 동작을 수행하도록(예: “book a flight”, “reset password”) 구동하는 데 사용됩니다. FAQ 지식 베이스에서 답변을 검색하는 데 최적화되어 있지 않습니다. LUIS는 “질문에 답하기” vs. “동작 수행”을 라우팅하기 위해 QnA Maker와 함께 사용될 수는 있지만, 단독으로는 FAQ 기반 대화형 지원 요구사항을 충족하지 못합니다.
핵심 개념: 이 문제는 기존 FAQ 문서로부터 대화형 지원 경험을 구축하기 위해 적절한 Azure Natural Language Processing 서비스를 선택하는지를 평가합니다. 핵심 요구사항은 “FAQ PDF를 기반으로 한 대화형 지원 시스템”이며, 이는 지식 베이스 + 질문 답변(Question Answering)에 해당합니다. 정답이 맞는 이유: QnA Maker(및 후속 기능인 Azure AI Language의 Question Answering)는 FAQ 페이지, 문서, PDF와 같은 반정형 콘텐츠로부터 지식 베이스를 만들고 이를 채팅 형태의 인터페이스로 노출하도록 설계되었습니다. FAQ PDF를 수집하여 질문/답변 쌍을 추출(또는 제목과 섹션으로부터 학습)하고, 신뢰도 점수와 함께 최적의 답변을 반환하는 엔드포인트를 게시할 수 있습니다. 이는 사용자 지정 NLP 모델을 구축하고 학습할 필요 없이 요구사항을 직접 충족합니다. 주요 기능, 구성, 모범 사례: QnA Maker는 URL, 파일(PDF 포함), 수동 Q&A 입력으로부터 가져오기를 지원합니다. 다중 턴 프롬프트(후속 질문), 사용자 피드백을 기반으로 답변 품질을 개선하는 active learning, 그리고 Azure Bot Service와의 통합 패턴을 제공하여 완전한 대화형 경험을 구현할 수 있습니다. 프로덕션 준비(Azure Well-Architected Framework)를 위해서는 신뢰성(지원되는 region에 배포, Application Insights로 모니터링), 보안(managed identity/keys 사용, 접근 제한), 운영 우수성(지식 베이스 반복 개선, active learning, 버전 관리, 테스트)을 고려합니다. 또한 시험 시기별 명칭도 유의하세요: AI-900 콘텐츠는 종종 “QnA Maker”를 언급하지만, 최신 구현은 “Azure AI Language – Question Answering”를 사용합니다. 개념은 동일합니다: FAQ를 채팅용 지식 베이스로 전환. 흔한 오해: Text Analytics는 NLP라서 관련 있어 보이지만, 질문에 답하기보다는 인사이트(감정, 핵심 구, 엔터티) 추출에 초점이 있습니다. LUIS는 의도 분류와 엔터티 추출을 통해 동작을 라우팅(예: “reset password”)하는 용도이지, FAQ 지식 베이스에서 답을 검색하는 용도가 아닙니다. Computer Vision은 입력이 이미지가 아니라 텍스트 콘텐츠이므로 관련이 없습니다. 시험 팁: “FAQ”, “knowledge base”, “문서에서 답하는 chatbot”, “question answering”이 보이면 QnA Maker/Question Answering를 선택하세요. “detect intent” 또는 “동작을 트리거하기 위한 엔터티 추출”이 보이면 LUIS를 선택하세요. “sentiment/key phrases/entities”가 보이면 Text Analytics를 선택하세요. “이미지 분석”이 보이면 Computer Vision을 선택하세요.
