Practice Test #2

Few-shot prompting은 원하는 패턴을 모델에 가르치기 위해 소수의 예시(input-output 쌍)를 제공합니다. 인시던트 분석 형식을 일관되게 만들고 delta/ratio 계산 방법을 시연함으로써 정확도를 높일 수는 있습니다. 그러나 요구 사항은 중간 계산을 포함한 명시적 단계별 추론 트레이스를 생성하는 것이며, 이는 단순히 예시를 제공하는 것보다 chain-of-thought prompting이 더 직접적으로 해결합니다.

Zero-shot prompting은 예시 없이 지시만에 의존합니다. 번호가 매겨진 단계와 계산을 요청할 수는 있지만, 연속 로그와 메트릭 전반의 복잡한 다중 증거 추론에서는 zero-shot이 일반적으로 신뢰성이 떨어집니다. 구조와 완전성의 변동성이 커지는 경우가 많아, 중간 계산과 정당화된 근본 원인/개선 조치 트레이스를 일관되게 포함해야 할 때는 더 약한 선택입니다.

Directional stimulus prompting은 특정 신호, 제약, 힌트(예: “deployment 이후 latency spike에 집중하라”, “5xx error를 우선하라”)를 강조하여 모델을 유도합니다. 이는 관련성을 높이고 노이즈가 많은 로그에서 산만함을 줄일 수 있지만, 중간 계산을 포함한 전체 추론 체인을 드러내도록 본질적으로 만들지는 않습니다. 이는 명시적 단계별 추론을 끌어내기보다는 주의(attention)를 안내하는 데 더 가깝습니다.

Amazon S3와의 네이티브 통합은 스냅샷, 백업, 데이터 라이프사이클 패턴(예: 인덱스 스냅샷을 S3에 저장)에 유용합니다. 그러나 S3는 객체 스토리지이며 RAG에 필요한 저지연 고차원 유사도 검색을 제공하지 않습니다. S3 통합은 내구성과 비용 관리를 돕지만, 100 ms 이내에 임베딩의 k-NN 검색을 가능하게 하지는 않습니다.

지리공간 인덱싱 및 쿼리는 반경 내 포인트 찾기, 바운딩 박스 검색, geo-distance 정렬과 같은 위치 기반 사용 사례를 지원합니다. 이는 특화된 인덱싱 기능이지만 768차원 임베딩 벡터에 대한 시맨틱 유사도와는 관련이 없습니다. 지리공간 기능은 RAG 워크로드에서 상위 20개 최근접 임베딩을 검색하는 데 도움이 되지 않습니다.

스트리밍 데이터에 대한 실시간 분석은 지속적으로 유입되는 이벤트(로그, 메트릭, 클릭스트림)를 낮은 인덱싱 지연으로 수집하고 쿼리하는 것을 의미합니다. OpenSearch가 준실시간 분석에 흔히 사용되기는 하지만, 스트리밍 지원은 여기의 핵심 요구사항인 고차원 임베딩에 대한 빠른 유사도 검색을 해결하지 못합니다. 벡터 검색 성능은 스트리밍 분석이 아니라 k-NN/ANN 인덱싱에 달려 있습니다.

오답. Temperature는 생성의 무작위성/창의성을 제어하여 결정성에 영향을 주고 때로는 간접적으로 응답 길이에 영향을 줄 수 있다. 그러나 Bedrock은 “temperature 설정값”으로 과금하지 않는다. 과금은 사용량(주로 tokens)으로 측정된다. Temperature가 출력 스타일을 바꾸더라도, 요금은 생성 및 처리된 tokens 수에 의해 좌우된다.

오답. 시나리오에서 custom training 또는 fine-tuning을 수행하지 않는다고 명시한다. Training 데이터 볼륨은 모델 customization(fine-tuning) 또는 별도의 training 워크플로가 포함될 때만 중요하다. Bedrock에서 managed FM inference의 경우, provider의 원래 pre-training 데이터가 아니라 inference 사용량(tokens)에 대해 비용을 지불한다.

오답. 여기서는 고객이 모델을 training하지 않으므로 training 시간은 관련이 없다. Bedrock은 고객이 보통 inference API를 소비하는 managed foundation models를 제공한다. Training duration 기반 요금은 Amazon SageMaker training 같은 서비스의 training jobs 또는 특정 customization 워크플로에 적용되며, 표준 Bedrock inference에는 해당되지 않는다.

compute cost와 runtime은 운영 metric(효율성)이지, 예측 성능 metric(효과성)이 아니다. 이는 예산 수립, scaling, latency/throughput 계획에는 도움이 되지만, 모델이 요구된 92% top-1 accuracy를 충족하는지 확인할 수는 없다. 모델은 저렴하고 빠르지만 부정확할 수도 있고, 비싸고 느리지만 정확할 수도 있다. 이 선택지는 라벨이 있는 ground truth 대비 정답 여부를 평가하지 않는다.

layer 또는 parameter 수를 세는 것은 모델의 capacity/complexity를 설명할 뿐, 해당 작업에서의 실제 정확도를 의미하지 않는다. parameter 수가 때로는 성능과 상관이 있을 수 있지만, 대표적인 라벨링된 benchmark에서의 경험적 평가를 대체할 수는 없다. 비슷한 크기의 두 모델도 학습 데이터, fine-tuning, preprocessing, domain shift에 따라 정확도가 크게 달라질 수 있다. 이 선택지는 92% 요구사항을 검증하지 못한다.

color fidelity 검사는 image preprocessing pipeline을 검증하는 데(예: 의도치 않은 변환이 없는지 확인) 유용할 수 있지만, 라벨링된 카테고리 대비 분류 정확도를 측정하지는 않는다. 모델은 color-accurate한 이미지를 받아도 여전히 오분류할 수 있다. 요구사항은 라벨링된 benchmark에서의 top-1 accuracy이며, 이는 prediction과 ground truth label을 비교하여 계산해야 한다.

AWS CloudTrail은 auditing, governance, 보안 조사(예: 누가 instance를 시작했는지 또는 IAM policy를 변경했는지)를 위해 AWS API calls 및 events를 기록합니다. P95 latency, HTTP 5xx rates, GPU/CPU utilization 같은 성능 모니터링을 위한 것이 아니며, application SLO에 대한 metric 기반 alarming을 제공하지 않습니다.

AWS Trusted Advisor는 cost optimization, performance, security, fault tolerance, service limits 전반에 걸쳐 주기적인 checks와 권고를 제공합니다. quotas에 근접하거나 리소스가 underutilized된 것 같은 이슈를 표시할 수는 있지만, 실시간 per-request latency percentiles, 5xx error monitoring, 또는 alerting을 포함한 container-level GPU/CPU telemetry를 제공하지 않습니다.

AWS Config는 AWS 리소스의 configuration state 및 changes를 추적하고 compliance rules(예: S3 buckets가 public인지, security groups가 0.0.0.0/0을 허용하는지)에 대해 평가합니다. metrics/observability 서비스가 아니며, P95 latency를 네이티브로 계산하거나 5xx error rates를 모니터링하거나 containers의 runtime GPU/CPU utilization을 추적할 수 없습니다.

오답. Agents for Amazon Bedrock는 추론 시점에서 다단계 작업(tool 사용, function calling, retrieval, workflow 실행)을 오케스트레이션하는 데 사용됩니다. 이는 “모델의 학습 프로세스를 감독”하지 않으며, foundation model이 학습된 방식을 바꿔 hallucination을 직접 줄이지도 않습니다. agents가 도구나 knowledge bases로 응답을 grounding하여 사실성을 개선할 수는 있지만, 이 선택지의 전제인 학습 감독은 틀렸습니다.

오답. hallucination을 유발하는 학습 예제를 제거하기 위한 데이터 사전 처리는 모델의 학습 데이터셋에 접근하여 수정한 뒤 재학습 또는 fine-tuning을 수행할 수 있음을 전제합니다. 문제는 재학습을 명시적으로 금지하고 24시간 내 개선을 요구합니다. Bedrock의 managed foundation models에서는 고객이 원본 학습 코퍼스를 편집할 수 없는 경우가 일반적입니다. 이 접근은 제시된 제약에서 실행 불가능합니다.

오답. 다른 foundation model로 전환하면 hallucination이 줄어들 수 있지만, 문제는 팀이 foundation model을 변경할 수 없다고 명시합니다. 설령 허용되더라도 모델 전환은 재검증, 프롬프트 조정, 회귀 테스트가 필요한 경우가 많아 24시간 내 가장 빠른 준수 해결책이 되기 어렵습니다. 최선의 답은 제약을 준수하면서 추론 시점 제어를 사용하는 것입니다.

데이터 증강은 기존 데이터의 변환 또는 합성 변형을 통해 추가 학습 예시를 만드는 것(예: 프롬프트 패러프레이징, 노이즈 추가, 추가 라벨링된 쌍 생성)입니다. 이는 견고성을 높이고 과적합을 줄이는 데 도움이 될 수 있지만, 그 자체가 foundation model이 새로운 용어와 형식을 일관되게 채택하도록 만드는 기법은 아닙니다. 증강은 종종 파인튜닝을 보완하는 요소이지, 이를 대체하지는 않습니다.

모델 양자화는 모델 정밀도(예: FP16에서 INT8/INT4로)를 낮춰 추론 비용, 메모리 사용량, 때로는 지연 시간을 줄입니다. 이는 모델에게 새로운 어휘를 가르치거나, 컴플라이언스 형식 준수도를 개선하거나, 도메인 특화 제약에 맞게 출력을 정렬하지 않습니다. 양자화는 학습/커스터마이징 이후에 적용되는 최적화 기법이지, 범용 모델을 핀테크 용어에 적응시키는 방법이 아닙니다.

지속적 사전학습(continued pre-training)은 대량의 비라벨 도메인 텍스트로 모델을 추가 학습시켜 도메인 지식과 언어 패턴을 개선합니다. 이는 모델이 도메인처럼 “말하게” 만드는 데 도움이 될 수 있지만, 일반적으로 방대한 도메인 코퍼스가 있고 더 광범위한 도메인 적응이 필요할 때 사용됩니다. 12,000개의 라벨링된 프롬프트/출력 쌍이 존재하고 특정 규정 준수 형식이 필요하다는 점을 고려하면, 지도 기반 파인튜닝이 더 직접적이며 시험 관점에서도 더 적절한 선택입니다.

고객 만족도 점수(CSAT)는 성능과 상관관계가 있을 수 있는 비즈니스 KPI이지만, 런타임 효율성의 직접적인 측정치는 아닙니다. CSAT는 많은 비기술적 요인(제품 품질, 가격, UX, 배송 경험)의 영향을 받습니다. latency가 개선되어도 CSAT가 변하지 않을 수 있고 그 반대도 가능합니다. ms 단위의 inference SLO라면 CSAT가 아니라 latency/응답 시간 metric에 집중해야 합니다.

각 epoch의 training 시간은 모델이 얼마나 빠르게 training되는지를 측정하며, 이는 런타임 서빙 라이프사이클이 아니라 ML 개발 라이프사이클의 일부입니다. training 효율성과 비용을 나타낼 수는 있지만, 배포된 API가 inference에 대해 200 ms latency SLO를 충족하는지 여부를 알려주지는 않습니다. training 성능과 inference 성능은 최적화 방식이 다른 경우가 많고, 서로 trade-off가 발생할 수도 있습니다.

training 인스턴스 수는 training 동안 사용된 compute 규모를 나타내며, 이는 training 속도와 비용에 영향을 줍니다. 하지만 inference 런타임 효율성이나 프로덕션 endpoint가 latency SLO를 충족하는지 여부를 직접 측정하지는 않습니다. inference 성능은 training에 사용된 인스턴스 수보다 서빙 인프라(instance type, autoscaling, concurrency, batching)에 더 크게 좌우됩니다.

오답입니다. CSV 형식의 라인이 포함된 일반 .txt 파일은 Bedrock fine-tuning에 기대되는 dataset 구조가 아닙니다. Bedrock 커스터마이징 워크플로는 일반적으로 명확히 정의된 필드(예: prompt/completion)를 가진 structured dataset format(보통 JSON Lines)을 요구합니다. 임의의 텍스트 파일을 사용하면 schema validation 실패 및 학습 데이터로서의 사용 불가 위험이 있습니다.

오답입니다. Amazon Bedrock의 Provisioned Throughput은 inference 용량 기능으로, 일관된 성능과 더 낮은 latency 변동성을 위해 모델 throughput을 예약합니다. 이는 모델 가중치를 수정하지 않으므로 클리닉별 정책에 대한 정확도를 개선하지 않습니다. 이는 스케일링과 예측 가능성을 다루는 것이지 fine-tuning 또는 커스터마이징이 아닙니다.

오답입니다. 저널과 교과서로 학습시키는 것은 클리닉별 정책을 위한 타깃 fine-tuning 전략이 아니며, labeled prompt-response 쌍으로 설명되지도 않습니다. unlabeled 도메인 텍스트는 pretraining 또는 RAG를 위한 retrieval corpus 구축에 더 가깝습니다. 정책 준수를 개선하려면 모델에 원하는 답변의 supervised example이 필요합니다.