Practice Test #2

integer index를 할당한 뒤 이를 연속적인 numeric 입력으로 넣는 것은 일반적으로 뉴럴 네트워크에 부적절한데, 인위적인 ordinality와 거리(예: 범주 10이 1000보다 11에 “가깝다”)를 도입하기 때문입니다. 이는(선택지에 언급되지 않은) embedding lookup을 사용하지 않는 한 모델을 오도할 수 있습니다. 메모리 효율적이긴 하지만 ordinality를 피해야 한다는 요구사항을 위반합니다.

고유 범주마다 차원을 두는 명시적 one-hot encoding은 ordinality를 피하는 가장 직접적인 방법이지만, 여기서는 확장되지 않습니다. 여러 컬럼에 걸쳐 수십만 개 범주가 있으면 결과 벡터 폭이 극단적으로 커져 GPU 메모리를 초과하고 연산 비용도 증가할 수 있습니다. 또한 evolving categories 환경에서 vocabulary를 구축·유지해야 하므로 운영 부담이 큽니다.

Run-length encoding은 시퀀스/문자열을 위한 압축 기법이지, 범주형 변수를 위한 표준 ML 인코딩이 아닙니다. 뉴럴 네트워크 입력에 적합한 안정적인 numeric 피처 표현을 만들지 못하고, ordinality 문제를 해결하지도 않으며, sparse categorical indicator 구조도 제공하지 않습니다. 핵심 모델링 및 확장성 요구사항을 해결하지 못한 채 복잡성만 추가합니다.

BigQuery ML은 tabular data에 대해 boosted tree model을 학습할 수 있지만, tree split rule을 수동으로 확인하는 것은 각 online prediction에 대한 instance별 feature attribution 값을 얻는 것과는 다릅니다. 문제는 개별 prediction에 대한 feature contribution을 구체적으로 요구하므로, model 구조를 사람이 해석하는 방식이 아니라 explanation 메커니즘이 필요합니다. 또한 이 옵션은 explain method와 함께 model을 Vertex AI endpoint에 배포하는 내용을 설명하지 않으며, 이는 요구 사항을 직접 충족하는 관리형 패턴입니다.

Logistic regression coefficient는 model 전반에서 feature와 target 간의 전체적인 관계를 설명하므로, instance별 explanation이 아니라 전역적인 interpretability의 한 형태입니다. coefficient가 크다고 해서 그 feature가 특정 prediction 하나에 얼마나 기여했는지를 직접 알려주지는 않으며, 특히 feature 값이 example마다 다르고 preprocessing이 해석에 영향을 줄 수 있는 경우에는 더욱 그렇습니다. 또한 이 옵션은 us-central1에서 request별 explanation을 제공하는 배포된 online endpoint도 제공하지 않습니다.

L1 regularization은 sparsity를 유도하고 덜 유용한 feature의 영향을 줄이기 위해 학습 중에 적용되지만, prediction 시점에 결과를 설명하기 위해 활성화하는 기능은 아닙니다. model이 L1 regularization으로 학습되었다고 해도, 그것이 각 online prediction에 대한 instance별 feature attribution 값을 생성해 주지는 않습니다. 이 옵션은 Vertex AI 배포 관련 표현을 사용하고 있지만 Explainable AI 또는 explain method를 포함하지 않으므로, 명시된 interpretability 요구 사항을 충족하지 않습니다.

수동 실행은 자동화와 재현성을 깨뜨리며, Vertex AI Pipelines 오케스트레이션과 깔끔하게 통합되지 않습니다. 운영 리스크(실행 누락, 파라미터 불일치)를 유발하고, 파이프라인 내부의 workflow task 요구사항을 충족하지 못합니다. 시험에서는 자동화된 파이프라인 솔루션이 요구될 때 수동 단계를 일반적으로 감점합니다.

BigQuery API를 호출하는 커스텀 Python container는 동작할 수 있지만, 가장 단순한 접근은 아닙니다. 코드를 작성하고, dependencies(google-cloud-bigquery)를 관리하며, container image를 빌드하고 저장하고, auth(Workload Identity/service account)를 처리하고, artifact outputs를 정의해야 합니다. 이는 사전 구축 component를 사용하는 것보다 노력과 유지보수가 더 큽니다.

새 component를 처음부터 만드는 것은 옵션 B보다도 더 많은 작업입니다. 이미 공식 component에 존재하는 기능을 중복 구현하면서 component specs(inputs/outputs), containerization, versioning, testing을 정의해야 합니다. 이는 최소 커스텀 코드 및 최저 노력 요구사항에 반합니다.

오답입니다. 세 번째 pool과 reductionserver image를 사용해 training workers와 reduction 서비스를 분리한 점은 맞지만, reduction server pool에 불필요하게 GPUs를 프로비저닝합니다. reduction server는 주로 tensor aggregation/transfer를 위한 CPU, memory, 빠른 networking이 필요합니다. A100s를 추가하면 이점은 거의 없거나 전혀 없는 반면 비용이 크게 증가하여 cost-optimization best practices를 위반합니다.

오답입니다. 시나리오는 PyTorch DDP를 A100 GPUs에서 사용한다고 명시합니다. TPUs로 전환하면 하드웨어가 바뀌고 일반적으로 distributed training stack도 변경됩니다(예: XLA, 다른 parallelism 패턴). 설명된 reduction server 전략은 GPU 기반 multi-node training을 위한 것이므로, 여기서 TPUs를 사용하는 것은 명시된 구성과 맞지 않으며 training job을 재설계해야 합니다.

오답입니다. TPU 불일치를 더 강화할 뿐 아니라 reduction server pool에 TPUs를 할당하는 것도 잘못입니다. reduction server는 compute accelerator 워크로드가 아니라 communication/aggregation 서비스입니다. 이를 위해 TPUs(또는 GPUs)를 프로비저닝하는 것은 낭비이며, 실제 병목인 node 간 gradient reduction을 처리하는 network 및 CPU 문제를 해결하지 못합니다.

이 선택지는 필요한 규모로 데이터를 학습하고 scoring할 수 있지만, 가장 강력한 기본 제공 end-to-end lineage를 제공하지는 않습니다. 명시된 요구 사항에 대해 데이터를 BigQuery로 옮기는 것은 필요하지 않으며, SDK를 통해 호출되는 custom prediction routine은 training과 prediction metadata를 함께 연결하는 오케스트레이션된 pipeline과 동일하지 않습니다. 감사 목적을 위해 정확한 training input snapshot, model version, prediction output location을 연관시키려면 추가적인 custom logic이 필요합니다. 따라서 두 단계를 모두 포함하는 단일 Vertex AI Pipeline보다 약합니다.

Vertex AI Experiments는 run과 metric을 추적하는 데 유용하고, Model Registry는 model version을 관리하는 데 유용하지만, 어느 서비스도 단독으로는 전체 workflow orchestration을 제공하지 않습니다. 또한 이 선택지는 training process 자체가 충분히 구체적으로 설명되지 않아, 정확한 data snapshot과 training execution에서 등록된 model까지의 lineage가 불완전합니다. Vertex AI batch prediction이 대규모 output을 생성할 수는 있지만, 두 단계가 모두 pipeline 내부에서 실행될 때만큼 data에서 model, prediction으로 이어지는 end-to-end chain이 강하게 포착되지는 않습니다. 따라서 전체 월별 프로세스 전반에 걸친 기본 제공 lineage 요구 사항을 가장 잘 충족하지는 못합니다.

training pipeline은 workflow의 training 부분에 대한 lineage를 포착할 수 있으므로 좋은 시작점입니다. 그러나 이 선택지는 batch prediction이 pipeline 외부의 Vertex AI에서 직접 생성된다고 명시하고 있어, 단일 오케스트레이션 lineage chain이 끊어집니다. 이는 prediction output이 training artifact 및 model production 단계와 동일한 pipeline execution context에 본질적으로 연결되지 않음을 의미합니다. 규정 준수와 auditability 측면에서는 prediction을 pipeline 내부에 유지하는 것이 더 강력하고 완전한 설계입니다.