基础模型集成、数据管理与合规性 I

Answer: C

Why:

Amazon Bedrock Knowledge Bases is a fully managed capability that handles the entire RAG workflow and supports incremental ingestion from S3, manages embedding lifecycle automatically, and integrates natively with OpenSearch for low-latency semantic search and metadata filtering. This minimizes operational burden while meeting latency and update requirements. When backed by Amazon OpenSearch Service, it can achieve the high-performance sub-300 ms p95 latency required for enterprise-scale retrieval.

Why not:

Option A: Aurora pgvector requires careful tuning at this scale, and frequent batch re-indexing increases latency and operational overhead.

Option B: While OpenSearch works, managing ingestion pipelines and index coordination manually increases overhead compared to Bedrock Knowledge Bases.

Option D: DynamoDB is not optimized for large-scale vector similarity search and would not meet latency requirements. PartiQL lacks the specialized k-Nearest Neighbor (k-NN) search algorithms required to meet strict p95 latency targets for high-dimensional embeddings.

Answer: C

Why:

Amazon Bedrock Knowledge Bases is a fully managed capability that handles the entire RAG workflow and supports incremental ingestion from S3, manages embedding lifecycle automatically, and integrates natively with OpenSearch for low-latency semantic search and metadata filtering. This minimizes operational burden while meeting latency and update requirements. When backed by Amazon OpenSearch Service, it can achieve the high-performance sub-300 ms p95 latency required for enterprise-scale retrieval.

Why not:

Option A: Aurora pgvector requires careful tuning at this scale, and frequent batch re-indexing increases latency and operational overhead.

Option B: While OpenSearch works, managing ingestion pipelines and index coordination manually increases overhead compared to Bedrock Knowledge Bases.

Option D: DynamoDB is not optimized for large-scale vector similarity search and would not meet latency requirements. PartiQL lacks the specialized k-Nearest Neighbor (k-NN) search algorithms required to meet strict p95 latency targets for high-dimensional embeddings.

Answer: B

Why:

Decomposing the query and retrieving from each knowledge source independently, prevents one corpus from swamping the others. Parallel retrieval keeps latency low, and reranking focuses the final context on high relevance to improve Precision@5 without inflating the token budget. This also reduces contradiction-driven hallucinations because the selected context is tighter and more topically aligned per hop.

Why not:

Option A: Top-200 explodes tokens and often reduces precision by injecting more distractors, lowering temperature doesn’t fix wrong-context grounding. It also raises latency (more retrieval and more rerank-by-model in the FM’s head) and pushes you beyond the 6,000-token cap. “Let the FM reason” is not a retrieval strategy and fails in production under contradictory sources.

Option C: Pure keyword for guidelines tends to miss paraphrased clinical concepts, lowering recall and causing brittle behavior across synonyms. You also lose the ability to do consistent scoring/merging across sources, harming Precision@5 when terminology varies. The contradiction issue remains because you haven’t enforced balanced retrieval and reranking.

Option D: Larger chunks reduce count but typically reduce precision because each chunk contains more irrelevant text, consuming tokens with low signal. It can also worsen contradiction handling by bundling multiple guideline statements together, making it harder to cite the correct one.

Answer: B

Why:

Decomposing the query and retrieving from each knowledge source independently, prevents one corpus from swamping the others. Parallel retrieval keeps latency low, and reranking focuses the final context on high relevance to improve Precision@5 without inflating the token budget. This also reduces contradiction-driven hallucinations because the selected context is tighter and more topically aligned per hop.

Why not:

Option A: Top-200 explodes tokens and often reduces precision by injecting more distractors, lowering temperature doesn’t fix wrong-context grounding. It also raises latency (more retrieval and more rerank-by-model in the FM’s head) and pushes you beyond the 6,000-token cap. “Let the FM reason” is not a retrieval strategy and fails in production under contradictory sources.

Option C: Pure keyword for guidelines tends to miss paraphrased clinical concepts, lowering recall and causing brittle behavior across synonyms. You also lose the ability to do consistent scoring/merging across sources, harming Precision@5 when terminology varies. The contradiction issue remains because you haven’t enforced balanced retrieval and reranking.

Option D: Larger chunks reduce count but typically reduce precision because each chunk contains more irrelevant text, consuming tokens with low signal. It can also worsen contradiction handling by bundling multiple guideline statements together, making it harder to cite the correct one.

Answer: A and B

Why:

Option A: It directly addresses Regional availability failures for supported Amazon Bedrock foundation models. Amazon Bedrock Cross-Region inference provides AWS-managed, transparent failover by automatically routing inference requests to another Region if the primary Region becomes unavailable or experiences capacity issues. This requires minimal or no application code changes, preserves the same model API contract, and avoids the need for custom traffic routing logic. Because the routing is handled by Bedrock itself, it delivers the lowest-operational-overhead solution for Region-level resilience.

Option B: It complements Cross-Region inference by handling model-level or repeated inference failures that Cross-Region inference alone cannot resolve. AWS Step Functions enables a circuit breaker pattern that detects consecutive failures, halts traffic to the unhealthy model, and routes requests to a secondary foundation model. This is critical when failures are due to model-specific issues (for example, throttling, service degradation, or vendor-specific outages) rather than Region-wide events. Step Functions also centralizes retry, backoff, and fallback logic, ensuring deterministic behavior without embedding complex control flow in application code.

Together, these two options provide defense-in-depth availability: Cross-Region inference protects against Region failures for the same model, while Step Functions enables controlled fallback across different models, achieving high availability with minimal application changes.

Why not:

Option C: Manually deploying duplicate Lambda functions across Regions and routing traffic introduces unnecessary operational complexity. This approach requires custom routing mechanisms (such as DNS failover or load balancer health checks), ongoing maintenance, and careful synchronization of deployments. It duplicates functionality already provided by Amazon Bedrock Cross-Region Inference and directly contradicts the requirement for minimal application changes.

Option D: API Gateway caching improves performance by serving previously generated responses, but does not address live inference availability. It cannot generate new summaries during an outage, does not detect model or Region failures, and risks returning stale or irrelevant responses. Caching is a latency optimization, not a resilience or failover strategy.

Option E: SageMaker Batch Transform is designed for asynchronous inference workloads. It requires job submission and completion cycles and cannot satisfy the low-latency, real-time requirements of an interactive summarization service. As a result, it is unsuitable for backup or failover inference in production GenAI applications.

Answer: A and B

Why:

Option A: It directly addresses Regional availability failures for supported Amazon Bedrock foundation models. Amazon Bedrock Cross-Region inference provides AWS-managed, transparent failover by automatically routing inference requests to another Region if the primary Region becomes unavailable or experiences capacity issues. This requires minimal or no application code changes, preserves the same model API contract, and avoids the need for custom traffic routing logic. Because the routing is handled by Bedrock itself, it delivers the lowest-operational-overhead solution for Region-level resilience.

Option B: It complements Cross-Region inference by handling model-level or repeated inference failures that Cross-Region inference alone cannot resolve. AWS Step Functions enables a circuit breaker pattern that detects consecutive failures, halts traffic to the unhealthy model, and routes requests to a secondary foundation model. This is critical when failures are due to model-specific issues (for example, throttling, service degradation, or vendor-specific outages) rather than Region-wide events. Step Functions also centralizes retry, backoff, and fallback logic, ensuring deterministic behavior without embedding complex control flow in application code.

Together, these two options provide defense-in-depth availability: Cross-Region inference protects against Region failures for the same model, while Step Functions enables controlled fallback across different models, achieving high availability with minimal application changes.

Why not:

Option C: Manually deploying duplicate Lambda functions across Regions and routing traffic introduces unnecessary operational complexity. This approach requires custom routing mechanisms (such as DNS failover or load balancer health checks), ongoing maintenance, and careful synchronization of deployments. It duplicates functionality already provided by Amazon Bedrock Cross-Region Inference and directly contradicts the requirement for minimal application changes.

Option D: API Gateway caching improves performance by serving previously generated responses, but does not address live inference availability. It cannot generate new summaries during an outage, does not detect model or Region failures, and risks returning stale or irrelevant responses. Caching is a latency optimization, not a resilience or failover strategy.

Option E: SageMaker Batch Transform is designed for asynchronous inference workloads. It requires job submission and completion cycles and cannot satisfy the low-latency, real-time requirements of an interactive summarization service. As a result, it is unsuitable for backup or failover inference in production GenAI applications.

Permutation Visualization

Why:

The workflow follows the standard MLOps lifecycle for generative AI:

• LoRA adapters are first applied during fine-tuning. The resulting model is registered for versioning, reviewed and approved, and only then deployed to a production endpoint, enabling controlled lifecycle management and rollback.

Why:

The workflow follows the standard MLOps lifecycle for generative AI:

• LoRA adapters are first applied during fine-tuning. The resulting model is registered for versioning, reviewed and approved, and only then deployed to a production endpoint, enabling controlled lifecycle management and rollback.

Answer: B

Why:

AWS AppConfig allows the company to store the active Amazon Bedrock model identifier (for example, Titan or Claude), update configuration values independently of application code, roll out changes safely using validators, deployment strategies, and monitoring, and instantly influence runtime behavior across all Lambda invocations. By reading the active model ID from AppConfig at invocation time, the Lambda function remains unchanged while the underlying foundation model can be switched in response to cost fluctuations, availability constraints, or operational decisions. This pattern aligns with AWS best practices for configuration decoupling, safe rollout, and runtime flexibility.

Why not:

Option A: Hardcoding model ARNs or IDs directly into the Lambda function tightly couples configuration with code. Any model change requires a code update and redeployment, increasing operational risk, slowing response to availability events, and violating the requirement for runtime flexibility.

Option C: Creating separate Lambda functions for each model increases architectural complexity and maintenance overhead. It introduces duplication of logic, complicates traffic routing, and still requires deployment changes to switch models, making it unsuitable for rapid or automated model selection.

Option D: Amazon CloudWatch alarms are designed to detect and signal operational conditions, not to manage or persist configuration state. While alarms can trigger actions or notifications, they cannot store the active model configuration or enforce consistent runtime behavior across invocations.

Answer: B

Why:

AWS AppConfig allows the company to store the active Amazon Bedrock model identifier (for example, Titan or Claude), update configuration values independently of application code, roll out changes safely using validators, deployment strategies, and monitoring, and instantly influence runtime behavior across all Lambda invocations. By reading the active model ID from AppConfig at invocation time, the Lambda function remains unchanged while the underlying foundation model can be switched in response to cost fluctuations, availability constraints, or operational decisions. This pattern aligns with AWS best practices for configuration decoupling, safe rollout, and runtime flexibility.

Why not:

Option A: Hardcoding model ARNs or IDs directly into the Lambda function tightly couples configuration with code. Any model change requires a code update and redeployment, increasing operational risk, slowing response to availability events, and violating the requirement for runtime flexibility.

Option C: Creating separate Lambda functions for each model increases architectural complexity and maintenance overhead. It introduces duplication of logic, complicates traffic routing, and still requires deployment changes to switch models, making it unsuitable for rapid or automated model selection.

Option D: Amazon CloudWatch alarms are designed to detect and signal operational conditions, not to manage or persist configuration state. While alarms can trigger actions or notifications, they cannot store the active model configuration or enforce consistent runtime behavior across invocations.