Ngân hàng đề — AWS Certified Generative AI Developer Pro

Đáp án

C và E.

• C — Dùng Titan Text model có sẵn trong AWS GovCloud cùng với Bedrock asynchronous model invocation để chạy job sinh nội dung dài theo lô
• E — Dùng Bedrock Knowledge Bases để grounding đầu ra vào luật và văn bản nội bộ, đảm bảo truy vết được và đúng ngữ cảnh

Vì sao đúng

Đề nêu năm ràng buộc, và cặp C+E là lựa chọn duy nhất thoả hết: | Ràng buộc | Cơ chế | |---|---| | Chạy hoàn toàn trong GovCloud | C — Titan có mặt ở GovCloud | | Workload bất đồng bộ, sinh nội dung dài | C — asynchronous invocation | | Truy vết được, lập luận có căn cứ | E — Knowledge Bases với citation | | Gánh nặng vận hành tối thiểu | cả hai đều là dịch vụ được quản lý | | Hiệu quả chi phí | không có hạ tầng chạy liên tục |

C — bất đồng bộ là đúng hình dạng workload. Đề nói rõ nhà phân tích không chờ phản hồi tương tác:

bedrock.create_model_invocation_job(
    jobName='soan-thao-chinh-sach-q3',
    modelId='amazon.titan-text-premier-v1:0',
    inputDataConfig={'s3InputDataConfig': {'s3Uri': 's3://.../yeu-cau.jsonl'}},
    outputDataConfig={'s3OutputDataConfig': {'s3Uri': 's3://.../ket-qua/'}})

Hai lợi ích: vượt được giới hạn thời gian của lời gọi đồng bộ (bản thảo chính sách rất dài), và giá thấp hơn đáng kể so với on-demand tương tác.

E — grounding cho vế truy vết. Đây là yêu cầu cứng của cơ quan nhà nước: người duyệt phải kiểm chứng được nguồn của từng nhận định:

bedrock_agent_runtime.retrieve_and_generate(...)
# phản hồi kèm citations: đoạn nào lấy từ điều luật nào

Không có Knowledge Bases, bạn phải tự dựng chunking, embedding, vector store và cơ chế trích dẫn — trái yêu cầu vận hành tối thiểu.

Vì sao các phương án khác sai

• B. Step Functions điều phối workflow tự truy xuất thủ công từ S3, dựng prompt trong Lambda, gọi InvokeModel; chia workload dài thành nhiều state để sinh bản thảo theo đoạn — đây là phương án gần nhất và nó hoạt động được, nhưng "manual retrieval from S3" nghĩa là tự dựng lại toàn bộ tầng RAG: không có embedding, không có tìm kiếm ngữ nghĩa, không có citation. Và chia bản thảo thành nhiều đoạn rồi ghép lại thường cho văn bản thiếu mạch lạc.
• D. Host LLM lớn đã fine-tune trên SageMaker GPU trong GovCloud, xử lý theo lô bằng SageMaker Processing; logic grounding tự viết trong container tìm tài liệu tĩnh trên S3 — vi phạm cả hai ràng buộc vận hành và chi phí: fine-tune và tự host model lớn là công sức và chi phí GPU đáng kể, và tự viết grounding trong container là mã phải bảo trì.
• A. Cụm ECS chạy container tự dựng với LLM mã nguồn mở, gắn volume EFS mã hoá chứa tài liệu pháp lý; API Gateway nội bộ nhận request lô và stream đầu ra qua handler tự viết — tốn công nhất trong bốn, và stream lại mâu thuẫn với yêu cầu bất đồng bộ theo lô mà đề nêu.

Ghi nhớ

Ba chế độ gọi model của Bedrock — chọn theo hình dạng workload: | Chế độ | Đặc điểm | Dùng khi | |---|---|---| | InvokeModel / Converse | đồng bộ, chờ kết quả | tương tác thời gian thực | | ConverseStream | stream token | chat, cần TTFT thấp | | Batch inference (async) | gửi JSONL lên S3, nhận kết quả sau | khối lượng lớn, không cần ngay — rẻ hơn ~50% |

Dòng cuối là điểm mấu chốt của câu này: với ngân sách hạn chế và không cần phản hồi tương tác, batch là lựa chọn kinh tế rõ ràng.

Ba đặc điểm của AWS GovCloud cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Region tách biệt | tài khoản riêng, không liên thông với Region thương mại | | Danh sách dịch vụ hạn chế hơn | phải kiểm tra dịch vụ và model có sẵn không | | Chỉ công dân Mỹ vận hành | yêu cầu ITAR và tương đương |

Dòng giữa là lý do đáp án C nói rõ "Titan Text models available in AWS GovCloud": không phải model nào trên Bedrock cũng có ở GovCloud. Kiểm tra danh sách model khả dụng là bước bắt buộc trước khi thiết kế.

Và ba yếu tố của "traceability" mà cơ quan quản lý thường đòi: | Yếu tố | Cơ chế | |---|---| | Nguồn của từng nhận định | citation của Knowledge Bases | | Bản ghi lời gọi model | model invocation logging → S3 Object Lock | | Phiên bản prompt đã dùng | Prompt Management với version |

Cả ba nên bật cùng nhau: citation cho người đọc kiểm chứng, invocation log cho kiểm toán về sau, và version prompt để biết bản thảo này được sinh bằng chỉ dẫn nào.

Đáp án

A — Bật Bedrock cross-Region inference để request tự động chuyển sang Region khác khi Region chính bị throttle.

Vì sao đúng

Đề nêu ba ràng buộc, và chúng loại dần các phương án: | Ràng buộc | Hệ quả | |---|---| | Không sửa logic sinh nội dung của ứng dụng | chỉ đổi cấu hình, không đổi mã | | Không đổi sang họ model khác | giữ nguyên tính nhất quán đầu ra | | Đỉnh tải theo vùng không được gây lỗi cho người dùng | cần năng lực dự phòng thật |

Cross-Region inference thoả cả ba chỉ bằng cách đổi modelId:

bedrock.converse(
    modelId='us.anthropic.claude-3-5-sonnet-20241022-v2:0',   # tiền tố "us."
    messages=[...])

Tiền tố Region (us., eu., apac.) biến modelId thành inference profile, và Bedrock tự phân phối request qua nhiều Region trong nhóm.

Vế cuối bảng khớp đúng tình huống trong đề: công ty truyền thông hoạt động nhiều vùng địa lý, và đỉnh tải của các vùng lệch nhau theo múi giờ — đúng thứ cross-Region inference tận dụng.

Vì sao các phương án khác sai

• B. Tăng số provisioned inference unit ở một Region và dựa vào autoscaling xử lý tải đỉnh từ các Region khác — đây là phương án gần nhất và có hai vấn đề: Provisioned Throughput không tự autoscale (bạn phải chủ động đổi số unit), và cấp năng lực cho đỉnh tải ở một Region nghĩa là trả tiền cho năng lực đó 24/7 kể cả lúc rảnh. Nó giải quyết được throttling nhưng với chi phí cao nhất.
• C. Step Functions thử lại với exponential backoff và phát lại request cho tới khi hết throttle — thử lại không tạo ra năng lực: nếu Region đang quá tải thì mọi lần thử đều gặp cùng hàng đợi. Kết quả là người dùng chờ lâu hơn thay vì nhận lỗi — vẫn là trải nghiệm hỏng. Và nó yêu cầu sửa ứng dụng, trái ràng buộc đầu.
• D. Dùng CloudFront định tuyến lưu lượng suy luận qua tầng edge trước khi tới Bedrock — CloudFront là CDN cho nội dung, không phải bộ cân bằng tải cho API suy luận. Nó có thể cache phản hồi giống hệt nhau, nhưng nội dung sinh ra hầu như không lặp lại, nên tỷ lệ trúng cache gần bằng không. Nó không giải quyết throttling chút nào.

Ghi nhớ

Ba chế độ năng lực của Bedrock — và câu hỏi để chọn: | Đề nói | Chọn | |---|---| | "không sửa ứng dụng", "chịu được đỉnh tải theo vùng" | cross-Region inference | | "chi tiêu đoán trước được", "độ trễ ổn định tuyệt đối" | Provisioned Throughput | | Tải thấp, thất thường | on-demand |

Đây là câu thứ ba trong cùng bộ đề bàn về chủ đề này (cùng #6358 và #6424), và ba câu chọn ba đáp án khác nhau vì ràng buộc khác nhau. Cách phân biệt luôn nằm ở vế chi phí: | Câu | Ràng buộc quyết định | Đáp án | |---|---|---| | #6358 | "không cấp thừa, không giữ sẵn năng lực" | cross-Region | | #6424 | "chi tiêu hằng tháng đoán trước được" | Provisioned | | #6433 | "không sửa ứng dụng, không đổi model" | cross-Region |

Bốn điểm về cross-Region inference: | Điểm | Chi tiết | |---|---| | Nhóm Region | us.*, eu.*, apac.* — dữ liệu ở lại trong nhóm địa lý | | Cùng model | không đổi họ model, nên đầu ra nhất quán | | Không phải model nào cũng hỗ trợ | kiểm tra danh sách inference profile | | Tuân thủ dữ liệu | request có thể được xử lý ở Region khác trong nhóm |

Dòng cuối là điều duy nhất cần cân nhắc kỹ trước khi bật: nếu có ràng buộc chủ quyền dữ liệu, xác nhận mọi Region trong nhóm đều được phép.

Và hai metric nên đặt alarm: InvocationClientErrors (bao gồm throttling) và InvocationLatency p99 — cả hai trong namespace AWS/Bedrock, tách theo ModelId.

Đáp án

D — Triển khai AWS Outposts rack ở mỗi quốc gia để chạy suy luận cục bộ, dùng Direct Connect với Transit Gateway tích hợp mạng tại chỗ với Region trung tâm; cấu hình Local Zones ở các đô thị cần độ trễ thấp và thực thi kiểm soát chủ quyền dữ liệu bằng routing domain theo vùng.

Vì sao đúng

Đề nêu ba nhu cầu khác nhau, và D là đáp án duy nhất dùng đúng công cụ cho từng cái: | Nhu cầu | Công cụ | |---|---| | Xử lý cục bộ gần dữ liệu tại chỗ vì tuân thủ | Outposts — hạ tầng AWS ĐẶT TẠI trung tâm dữ liệu của bạn | | Độ trễ thấp cho người dùng ở đô thị lớn | Local Zones — hạ tầng AWS ở gần thành phố | | Kết nối thống nhất và an toàn | Direct Connect + Transit Gateway |

Phân biệt Outposts với Local Zones là điểm mấu chốt, và đây là chỗ dễ nhầm nhất: | | Outposts | Local Zones | |---|---|---| | Đặt ở đâu | TRUNG TÂM DỮ LIỆU CỦA BẠN | hạ tầng AWS ở thành phố lớn | | Ai sở hữu vị trí | bạn | AWS | | Giải quyết | chủ quyền dữ liệu, dữ liệu không rời cơ sở | độ trễ tới người dùng cuối |

Đề yêu cầu "local processing of sensitive customer data" vì lý do tuân thủ — điều đó cần dữ liệu ở lại trong cơ sở của ngân hàng, và chỉ Outposts làm được. Local Zones tuy gần về địa lý nhưng vẫn là hạ tầng AWS công cộng.

Và Transit Gateway là mảnh cho vế "unified routing and security design":

Outposts (nước A) ─┐
Outposts (nước B) ─┼─ Direct Connect ─ Transit Gateway ─ Region trung tâm
Local Zones (đô thị)┘                        ↓
                            routing domain riêng cho từng vùng

Routing domain (route table riêng trên Transit Gateway) là cách thực thi chủ quyền dữ liệu ở tầng mạng: lưu lượng của nước A không có đường tới nước B.

Vì sao các phương án khác sai

• C. Dùng Local Zones ở tất cả các nước cho suy luận và nối hệ thống tại chỗ qua site-to-site VPN; thêm Global Accelerator và dựa vào routing policy để thực thi chủ quyền dữ liệu — đây là phương án gần nhất và sai ở hai chỗ: Local Zones không có ở mọi quốc gia và không đặt trong cơ sở của bạn nên không thoả yêu cầu xử lý cục bộ vì tuân thủ. Và "routing policy" là kiểm soát mềm — chủ quyền dữ liệu cần ranh giới cứng.
• B. Đặt toàn bộ suy luận ở MỘT Region trung tâm và dùng Wavelength Zones phục vụ người dùng đô thị; backhaul toàn bộ dữ liệu tại chỗ về Region để xử lý và lưu trữ tập trung — vi phạm thẳng yêu cầu chủ quyền: "backhaul all on-premises data to the Region" là chính thứ luật của các nước đó cấm. (Wavelength Zones cũng nhắm vào ứng dụng trên mạng 5G, không phải người dùng doanh nghiệp nói chung.)
• A. Snowball Edge ở mỗi nước chạy suy luận và đồng bộ định kỳ về Region; VPN qua Internet nối người dùng đô thị với Snowball gần nhất — Snowball Edge là thiết bị di trú dữ liệu và tính toán biên tạm thời, không phải nền tảng chạy dịch vụ production lâu dài. Và VPN qua Internet công cộng cho một ngân hàng là lựa chọn kém về cả độ trễ lẫn bảo mật so với Direct Connect.

Ghi nhớ

Bốn tuỳ chọn hạ tầng lai của AWS — nhớ đúng vị trí vật lý: | Tuỳ chọn | Đặt ở đâu | Giải quyết | |---|---|---| | Outposts | cơ sở của KHÁCH HÀNG | chủ quyền dữ liệu, độ trễ tới hệ thống nội bộ | | Local Zones | hạ tầng AWS ở thành phố lớn | độ trễ tới người dùng cuối | | Wavelength Zones | trong mạng của nhà mạng 5G | độ trễ cực thấp cho ứng dụng di động | | Snowball Edge | tạm thời, nơi nào cần | di trú dữ liệu, tính toán biên tạm |

Câu hỏi để phân biệt hai cái đầu:

"Dữ liệu có được phép rời khỏi toà nhà của tôi không?" Không → Outposts. Được nhưng cần nhanh → Local Zones.

Ba thành phần của kết nối lai an toàn: | Thành phần | Việc | |---|---| | Direct Connect | đường riêng, băng thông ổn định, không qua Internet | | Transit Gateway | hub định tuyến trung tâm, thay cho mạng lưới VPN chằng chịt | | Route table riêng trên TGW | phân vùng lưu lượng — thực thi chủ quyền ở tầng mạng |

Dòng cuối là kỹ thuật đáng nhớ: Transit Gateway cho phép nhiều route table, và bạn gắn mỗi attachment vào một route table. Nước A và nước B không có route tới nhau — nên dữ liệu không thể chảy chéo, kể cả khi ứng dụng cấu hình sai.

Và một lưu ý thực tế về Outposts với workload GenAI: Outposts có sẵn cấu hình GPU, nhưng năng lực bị giới hạn bởi phần cứng bạn đặt. Nên mẫu thường dùng là suy luận nhạy cảm chạy trên Outposts, còn huấn luyện và phân tích tổng hợp chạy ở Region — miễn là dữ liệu gửi về Region đã được khử định danh đúng cách.

Đáp án

A — Tạo tầng đo token ghi lại token đầu vào và đầu ra cho mọi request qua API Gateway, lưu vào CloudWatch và DynamoDB để báo cáo theo từng tenant; dùng Lambda thực thi ngân sách token bằng cách đánh giá mức dùng TRƯỚC KHI gọi Bedrock, và cho phép hạn mức cao hơn cho workload quan trọng qua luật chính sách cấu hình được.

Vì sao đúng

Đề nêu ba yêu cầu, và cụm quyết định là "enforces per tenant token budgets" — tức là thực thi, không phải theo dõi: | Yêu cầu | Cơ chế | |---|---| | Chargeback chính xác theo đội, dự án, môi trường | ghi token theo dimension, lưu DynamoDB | | Ngân sách NGHIÊM NGẶT cho workload thử nghiệm | kiểm tra TRƯỚC khi gọi Bedrock, chặn nếu vượt | | Hạn mức cao hơn cho workload quan trọng | luật chính sách cấu hình được |

Điểm mấu chốt: kiểm tra phải xảy ra TRƯỚC lời gọi model. Đó là khác biệt giữa ngân sách và báo cáo:

def lambda_handler(event, context):
    tenant = event['requestContext']['authorizer']['tenantId']
    ngan_sach = lay_chinh_sach(tenant)          # từ DynamoDB hoặc AppConfig
    da_dung = lay_muc_dung_thang(tenant)

    uoc_luong = uoc_tinh_token(event['prompt'], event.get('maxTokens', 1000))

    if da_dung + uoc_luong > ngan_sach['tran']:
        if not ngan_sach['duoc_vuot_tran']:      # ← workload quan trọng thì cho qua
            return {'statusCode': 429, 'body': 'Vượt ngân sách token'}

    ket_qua = bedrock.converse(...)
    ghi_muc_dung(tenant, ket_qua['usage'])       # ghi số THẬT sau khi gọi
    return ket_qua

Hai chi tiết đáng chú ý trong đoạn trên: ước lượng trước để quyết định, và ghi số thật sau khi gọi (usage.inputTokens và usage.outputTokens từ phản hồi Bedrock) — ước lượng dùng để chặn, số thật dùng để tính tiền.

Và duoc_vuot_tran là luật cấu hình được, đáp ứng vế "prioritized workloads" mà không cho phép ai tự khai mình quan trọng.

Vì sao các phương án khác sai

• B. Ghi ước lượng token vào DynamoDB, gửi tóm tắt định kỳ lên CloudWatch Logs; Lambda thực thi MỀM bằng cách CHO MỌI REQUEST ĐI QUA và chỉ gắn cờ các lần vượt để xem xét sau — đây là phương án gần nhất và sai ở đúng chỗ: "soft enforce" không phải thực thi. Đề nói lãnh đạo muốn "strict token budgets" cho workload thử nghiệm — một đội chạy sai vòng lặp có thể đốt hết ngân sách trước khi ai đọc báo cáo.
• D. Ghi ước lượng vào DynamoDB nhưng cho các đội tự BỎ QUA kiểm tra bằng cách gửi cờ ưu tiên trong request; Lambda chỉ gửi cảnh báo thay vì chặn — để người dùng tự khai mình được ưu tiên là không có kiểm soát nào: mọi đội sẽ đặt cờ đó. Ưu tiên phải do chính sách phía máy chủ quyết định, không do request khai.
• C. Gộp dữ liệu chi phí từ Billing and Cost Management và dựa vào cost allocation tag để XẤP XỈ mức tiêu thụ token; EventBridge báo khi xu hướng chi tiêu tháng vượt ngưỡng — quá thô và quá muộn: dữ liệu billing trễ nhiều giờ tới một ngày, và cost allocation tag không phân giải xuống mức từng request. Không thể dùng để chặn.

Ghi nhớ

Ba mức kiểm soát ngân sách — biết mình đang ở mức nào: | Mức | Hành vi | Phù hợp với | |---|---|---| | Chỉ theo dõi | ghi lại, không can thiệp | báo cáo | | Thực thi mềm | cảnh báo nhưng cho qua | môi trường tin cậy | | Thực thi cứng | chặn khi vượt | ngân sách thật |

Hai loại số liệu token, và mỗi loại dùng cho việc gì: | Số liệu | Nguồn | Dùng cho | |---|---|---| | Ước lượng trước | đếm ký tự chia 4, hoặc tokenizer | quyết định chặn hay cho qua | | Số thật sau khi gọi | usage trong phản hồi Bedrock | tính tiền và chargeback |

Không thể dùng số thật để chặn (vì khi có nó thì đã tốn tiền rồi), và không nên dùng ước lượng để tính tiền (vì nó lệch).

Ba dimension cần gắn cho mỗi bản ghi: | Dimension | Vì sao | |---|---| | Tenant / đội | chargeback | | Dự án | phân bổ trong đội | | Môi trường | tách dev khỏi production — hai mức ngân sách khác nhau |

Và ba lưu ý khi triển khai ở quy mô:

1. Đếm mức dùng bằng atomic counter của DynamoDB (UpdateExpression: ADD), không phải đọc-rồi-ghi — nếu không, hai request đồng thời sẽ ghi đè nhau và ngân sách bị đếm thiếu.
2. Đặt TTL cho bản ghi chi tiết, giữ bản tổng hợp theo tháng — nếu không bảng sẽ phình vô hạn.
3. Lưu chính sách ngân sách trong AppConfig, không hard-code — đổi hạn mức cho một đội không nên cần triển khai lại.

Điểm đầu là lỗi kinh điển và im lặng: ngân sách trông như đang hoạt động, chỉ là con số luôn thấp hơn thực tế.

Đáp án

D — Cấu hình SageMaker Clarify với job giám sát bias drift theo lịch tính các chỉ số công bằng và giải thích được, rồi đẩy vi phạm lên EventBridge; dùng EventBridge rule kích hoạt workflow khắc phục TỰ ĐỘNG trong Step Functions để quay về phiên bản model cũ hoặc chuyển trọng số lưu lượng khi vượt ngưỡng.

Vì sao đúng

Đề nêu ba yêu cầu, và chữ quan trọng nhất là "remediation" — tức là hành động, không chỉ cảnh báo: | Yêu cầu | Cơ chế | |---|---| | Phát hiện tự động | Clarify monitoring schedule | | Cảnh báo | EventBridge | | Khắc phục TỰ ĐỘNG khi vượt ngưỡng | Step Functions workflow |

Vòng lặp khép kín:

Clarify job (theo lịch)
    ↓ tính chỉ số công bằng trên dữ liệu suy luận đã bắt
    ↓ so với đường cơ sở
Vi phạm ngưỡng → EventBridge event
    ↓ rule
Step Functions:
    ① Xác nhận vi phạm (tránh báo động giả)
    ② Chuyển trọng số lưu lượng về phiên bản trước
    ③ Thông báo đội chịu trách nhiệm
    ④ Ghi vết cho hồ sơ tuân thủ

Bước ② là điểm phân biệt với phương án B: nó xảy ra ngay lập tức, không chờ người. Với hệ thống tóm tắt điều kiện hưởng trợ cấp cho công dân, mỗi giờ chạy với model thiên lệch là những quyết định bị ảnh hưởng — và chúng không rút lại được.

Clarify cung cấp cả hai loại chỉ số mà đề nhắc tới: | Loại | Ví dụ | |---|---| | Bias metrics | DPPL, DI, RD — chênh lệch kết quả giữa các nhóm | | Explainability | SHAP — đặc trưng nào đang chi phối dự đoán |

Loại thứ hai đáng giá riêng: khi bias tăng, SHAP cho biết đặc trưng nào gây ra — nên việc khắc phục có hướng thay vì mò mẫm.

Vì sao các phương án khác sai

• B. Clarify monitoring schedule tính chỉ số và đẩy lên EventBridge; rule gửi thông báo cho quản trị viên; để đội vận hành TỰ khởi động khắc phục bằng cách cập nhật phiên bản model hoặc chỉnh trọng số lưu lượng khi nhận cảnh báo — đây là phương án gần nhất và thiếu đúng một mắt xích: con người trong vòng lặp khắc phục. Đề nói rõ cần "triggers automated actions when violations occur". Thông báo là phát hiện, không phải phản ứng.
• A. Clarify cho phân tích bias TRƯỚC HUẤN LUYỆN và job hằng tuần kiểm tra chỉ số bias ban đầu, ghi vào DynamoDB; Lambda gắn cờ thay đổi đáng kể — sai giai đoạn: pre-training bias phân tích dữ liệu huấn luyện, còn đề lo về bias drift trong lúc vận hành. Kiểm tra lại "chỉ số ban đầu" không cho biết gì về hành vi hiện tại của model.
• C. Job SageMaker Processing hằng ngày sinh báo cáo bias lưu S3, chuyên viên tuân thủ đọc và tự cập nhật model nếu thấy trôi; SNS báo khi có báo cáo mới — hoàn toàn thủ công, và "đọc báo cáo hằng ngày" là quy trình sẽ bị bỏ qua sau vài tuần.

Ghi nhớ

Bốn loại giám sát của SageMaker Model Monitor: | Loại | Phát hiện | |---|---| | Data quality | phân bố đặc trưng đầu vào thay đổi | | Model quality | độ chính xác giảm (cần nhãn thật) | | Bias drift | chênh lệch kết quả giữa các nhóm tăng ← câu này | | Feature attribution drift | đặc trưng nào đang chi phối dự đoán thay đổi |

Loại cuối là chỉ báo sớm hữu ích: nếu tầm quan trọng của một đặc trưng nhạy cảm tăng dần, bias thường sẽ theo sau.

Ba chỉ số bias hay dùng của Clarify: | Chỉ số | Đo | |---|---| | DPPL (Difference in Positive Proportions in Predicted Labels) | chênh lệch tỷ lệ kết quả tích cực giữa hai nhóm | | DI (Disparate Impact) | tỷ số của hai tỷ lệ đó — quy tắc 80% thường dùng | | RD (Recall Difference) | chênh lệch recall giữa các nhóm |

Ba biện pháp khắc phục tự động, theo mức độ: | Biện pháp | Khi nào | |---|---| | Chuyển trọng số lưu lượng | giảm dần ảnh hưởng, giữ khả năng quan sát | | Rollback về phiên bản trước | vi phạm nghiêm trọng | | Chuyển sang xử lý thủ công | hệ thống có hậu quả cao — như xét trợ cấp |

Biện pháp thứ ba đáng cân nhắc cho trường hợp trong đề: với quyết định ảnh hưởng tới quyền lợi công dân, dừng tự động hoá và chuyển sang người xét thường an toàn hơn là quay về một phiên bản model cũ chưa biết có tốt hơn không.

Và hai điều bắt buộc phải có trước khi bật giám sát bias:

1. Đường cơ sở — không có baseline thì không có gì để so.
2. Data capture bật trên endpoint — Clarify phân tích dữ liệu suy luận đã bắt; không bật thì job không có gì để đọc.

Điểm thứ hai hay bị quên và triệu chứng là job chạy xong nhưng báo cáo trống.

Đáp án

C — Cài đặt router có LLM hỗ trợ: dùng một classifier nhẹ kiểm tra prompt, nhận diện loại tác vụ, rồi chuyển tới LLM phù hợp nhất ở phía sau.

Vì sao đúng

Đề nêu ba yêu cầu:

1. Mỗi tác vụ có đánh đổi chất lượng–độ trễ–chi phí khác nhau
2. Người dùng KHÔNG phải tự chọn model
3. Giữ MỘT giao diện thống nhất cho mọi trường hợp

Và bốn loại tác vụ trong đề thật sự cần model khác nhau: | Tác vụ | Nhu cầu | |---|---| | Tóm tắt hợp đồng | suy luận sâu, chính xác — model mạnh | | Viết nội dung marketing | sáng tạo, model trung bình là đủ | | Viết lại chính sách | chính xác về ngữ nghĩa | | Hỗ trợ xử lý sự cố | nhanh, khối lượng lớn — model nhẹ |

Router dùng classifier nhẹ là cách cân bằng đúng: nó thêm một lời gọi model rẻ để tiết kiệm một lời gọi model đắt:

loai = classifier_nhe.phan_loai(prompt)      # model nhỏ, vài chục mili giây
model = BANG_DINH_TUYEN[loai]                 # tra bảng
return bedrock.converse(modelId=model, messages=[...])

Vì sao phân loại bằng model hơn phân loại bằng từ khoá: một prompt tóm tắt hợp đồng có thể không chứa từ "hợp đồng" nào, và một prompt marketing có thể nhắc tới "hợp đồng" trong ngữ cảnh khác. Classifier hiểu ý định, không chỉ đếm từ.

Và giao diện thống nhất được giữ vì router nằm phía sau một endpoint duy nhất — người dùng gửi prompt như bình thường, không biết gì về việc định tuyến.

Vì sao các phương án khác sai

• B. Classifier dựa trên LUẬT đánh giá từ khoá trong prompt và định tuyến tới các LLM định sẵn, không có bước phân loại bằng model — đây là phương án gần nhất và sai ở đúng chỗ đề nhấn mạnh: đề nói cần "intelligently inspect the prompt, classify the task category". Từ khoá mong manh: một prompt nhắc nhiều loại từ khoá sẽ được định tuyến theo thứ tự tình cờ, và cách diễn đạt mới đòi thêm luật mới liên tục.
• A. Dùng model sinh nhỏ VIẾT LẠI prompt thành định dạng tác vụ chuẩn rồi chuyển tất cả tới MỘT LLM duy nhất — chuẩn hoá prompt không phải định tuyến: mọi request vẫn tới cùng một model, nên không có đánh đổi chất lượng–độ trễ–chi phí nào được tối ưu. Đó là mục tiêu chính của đề.
• D. Dùng MỘT LLM đa dụng cho mọi tác vụ và dựa vào prompt template để điều chỉnh hành vi — cùng vấn đề: một model cho mọi việc nghĩa là hoặc trả tiền model mạnh cho việc đơn giản, hoặc nhận chất lượng kém cho việc khó. Prompt template đổi được cách trả lời, không đổi được năng lực model.

Ghi nhớ

Ba cách định tuyến giữa nhiều model: | Cách | Cơ chế | Đặc điểm | |---|---|---| | Rules-based | từ khoá, regex | rẻ nhất, mong manh nhất | | Classifier nhẹ | model nhỏ phân loại ý định | cân bằng tốt nhất | | LLM router đầy đủ | model lớn tự quyết định | chính xác nhất, đắt nhất |

Cách thứ hai thường đúng vì chi phí phân loại thấp hơn nhiều lần chi phí tiết kiệm được:

Không router:  100% request × giá model mạnh
Có router:     100% × giá classifier (rất rẻ)
             +  30% × giá model mạnh
             +  70% × giá model nhẹ

Hai lựa chọn triển khai trên AWS: | Lựa chọn | Đặc điểm | |---|---| | Bedrock Prompt Router | được quản lý — tự chọn model theo độ phức tạp | | Comprehend custom classification | phân loại theo danh mục BẠN định nghĩa | | Model nhẹ tự gọi | linh hoạt nhất |

Với đề này, cả ba đều dùng được. Comprehend phù hợp khi bốn loại tác vụ là cố định và có dữ liệu gán nhãn; Prompt Router phù hợp khi tiêu chí là độ phức tạp chứ không phải danh mục.

Ba lưu ý khi vận hành router:

1. Luôn có nhánh mặc định — prompt không khớp loại nào phải đi đâu đó, thường là model đa dụng.
2. Ghi lại quyết định định tuyến như một dimension trong metric — để biết phân bố thực tế và phát hiện khi classifier lệch.
3. Đặt ngưỡng tin cậy — phân loại điểm thấp nên đi model mạnh hơn thay vì đoán bừa.

Điểm thứ ba đáng nhớ: chi phí của một lần định tuyến sai xuống model quá yếu (câu trả lời kém, người dùng phải hỏi lại) thường lớn hơn khoản tiết kiệm được. Nên khi không chắc, nghiêng về model mạnh hơn.

Đáp án

A — Dùng Amazon AppFlow kéo tập con đã lọc của dữ liệu SaaS với ánh xạ ở mức trường và mã hoá cả khi truyền lẫn khi lưu; cấu hình Glue incremental job với job bookmark để chỉ xử lý dữ liệu mới và đã đổi, ngăn nạp trùng vào knowledge base.

Vì sao đúng

Đề nêu bốn yêu cầu, và A đáp ứng từng cái bằng đúng một cơ chế: | Yêu cầu | Cơ chế | |---|---| | Chỉ đồng bộ tập con cần thiết | AppFlow filter + field mapping | | Xử lý cập nhật và xoá liên tục, không reload toàn bộ | AppFlow incremental pull | | Mã hoá khi truyền và khi lưu | AppFlow hỗ trợ sẵn cả hai | | Ngăn nạp trùng | Glue job bookmark |

AppFlow là dịch vụ tích hợp SaaS được quản lý — nó có connector dựng sẵn cho Salesforce, ServiceNow, Zendesk và nhiều hệ thống khác, nên bạn không phải viết mã gọi API, xử lý phân trang, hay quản lý token OAuth:

AppFlow flow:
  Nguồn:  Salesforce → object "Case"
  Bộ lọc: LastModifiedDate > {thời điểm chạy trước}
          AND Status IN ('Open', 'Escalated')
  Ánh xạ: chỉ 8 trường cần thiết trong số 200
  Đích:   S3 (mã hoá KMS)
  Lịch:   mỗi 15 phút, chế độ incremental

Job bookmark của Glue là mảnh cho vế chống trùng lặp: nó nhớ vị trí đã xử lý tới giữa các lần chạy, nên lần sau chỉ đọc phần mới:

glueContext.create_dynamic_frame.from_catalog(
    database='saas_data', table_name='cases',
    transformation_ctx='doc_case')     # ← khoá của bookmark
job.commit()                            # ← chốt vị trí

Không có transformation_ctx thì bookmark không hoạt động — đây là lỗi hay gặp.

Vì sao các phương án khác sai

• D. AppFlow chuyển hàng loạt theo lịch, lưu S3 có mã hoá phía máy chủ; Glue crawler quét toàn bộ dataset và job biến đổi GHI ĐÈ knowledge base ở mỗi lần nạp — đây là phương án gần nhất và sai ở đúng chỗ đề cấm: "without performing full reloads". Ghi đè toàn bộ mỗi lần là tốn kém (tính lại embedding cho mọi bản ghi) và gây khoảng gián đoạn khi index đang được dựng lại.
• B. Glue chạy full extract theo lịch cố định, dùng Glue trigger điều phối; mã hoá KMS và DynamoDB theo dõi bản ghi đã xử lý — full extract vi phạm cùng ràng buộc, và tự dựng bảng theo dõi trong DynamoDB là làm lại thứ job bookmark có sẵn. Ngoài ra Glue không có connector SaaS phong phú như AppFlow.
• C. S3 event notification phát hiện khi hệ thống SaaS xuất tệp mới, Lambda ghi thẳng vào knowledge base; dựa vào knowledge base tự khử trùng lặp và bỏ qua bản ghi cũ — gán cho knowledge base khả năng nó không có: nó không tự khử trùng lặp theo nghiệp vụ và không biết bản ghi nào cũ hơn. Kết quả là cùng một case xuất hiện nhiều lần với nội dung khác nhau.

Ghi nhớ

Ba dịch vụ tích hợp dữ liệu — chọn theo nguồn: | Dịch vụ | Nguồn | |---|---| | AppFlow | ứng dụng SaaS (Salesforce, ServiceNow, Zendesk, SAP) | | Glue | S3, JDBC, data lake — kèm biến đổi dữ liệu | | DMS | cơ sở dữ liệu, có CDC (change data capture) |

Bốn khả năng của AppFlow đáng biết: | Khả năng | Chi tiết | |---|---| | Filter ở nguồn | lọc TRƯỚC khi truyền — giảm dữ liệu và chi phí | | Field mapping | chỉ lấy trường cần | | Incremental transfer | chỉ bản ghi đổi từ lần chạy trước | | Mã hoá đầu cuối | in transit + at rest, dùng KMS key của bạn |

Ba chế độ chạy flow: | Chế độ | Dùng khi | |---|---| | On-demand | chạy tay hoặc gọi API | | Scheduled | định kỳ — hợp với đồng bộ liên tục | | Event-driven | khi nguồn phát sự kiện (Salesforce platform event) |

Và một vấn đề đề có nhắc nhưng cần chú ý riêng: xử lý bản ghi bị XOÁ. Incremental pull thường chỉ thấy bản ghi mới và sửa, không thấy bản ghi đã bị xoá ở nguồn. Hai cách xử lý: | Cách | Chi tiết | |---|---| | Soft delete ở nguồn | bản ghi có cờ IsDeleted — incremental pull thấy được | | Đối chiếu định kỳ | thỉnh thoảng lấy danh sách ID đầy đủ và xoá phần thừa trong index |

Không xử lý vế này thì knowledge base sẽ trả lời dựa trên case đã bị xoá — một dạng lỗi im lặng khó phát hiện.

Đáp án

C — Cấu hình interface VPC endpoint cho Bedrock dùng AWS PrivateLink và gắn security group phạm vi hẹp chỉ cho phép các subnet ứng dụng đã duyệt kết nối; triển khai trợ lý qua nhiều Availability Zone để có kết nối riêng tư và co giãn được, không đi ra Internet công cộng.

Vì sao đúng

Đề nêu ba yêu cầu, và C là đáp án duy nhất thoả hết: | Yêu cầu | Cơ chế | |---|---| | Lưu lượng Bedrock ở hoàn toàn trong mạng AWS | interface VPC endpoint (PrivateLink) | | Chỉ subnet ứng dụng cụ thể gọi được | security group phạm vi hẹp | | Co giãn qua nhiều AZ | endpoint ở mỗi AZ |

Interface VPC endpoint tạo một ENI trong subnet của bạn với địa chỉ IP riêng tư, và DNS được ghi đè để trỏ tới đó:

Ứng dụng trong VPC
    ↓ gọi bedrock-runtime.ap-northeast-1.amazonaws.com
    ↓ DNS riêng tư phân giải thành IP nội bộ của ENI
Interface endpoint (ENI trong subnet của bạn)
    ↓ PrivateLink — KHÔNG qua Internet
Amazon Bedrock

Security group trên endpoint là cơ chế thực thi vế thứ hai — nó quyết định subnet nào được nói chuyện với ENI:

Inbound rule: HTTPS (443) từ sg-ung-dung

Chỉ tài nguyên gắn sg-ung-dung mới gọi được — mọi thứ khác trong VPC bị chặn ở tầng mạng.

Và triển khai endpoint ở nhiều AZ là chi tiết cần thiết: mỗi AZ có ENI riêng, nên một AZ mất không làm đứt kết nối cho các AZ còn lại.

Nên bổ sung thêm một lớp nữa cho môi trường tài chính: endpoint policy giới hạn hành động và model được phép:

{"Statement": [{"Effect": "Allow", "Principal": "*",
  "Action": ["bedrock:InvokeModel"],
  "Resource": "arn:aws:bedrock:*::foundation-model/anthropic.claude-*"}]}

Vì sao các phương án khác sai

• B. Interface VPC endpoint cho Bedrock nhưng gắn security group cho phép truy cập từ TẤT CẢ subnet trong VPC để đơn giản hoá quản lý; triển khai nhiều AZ và dựa vào định tuyến VPC mặc định — đây là phương án gần nhất và sai ở đúng chỗ: "all subnets" trái yêu cầu "only specific application subnets". Kết nối riêng tư thì đạt, nhưng đặc quyền tối thiểu thì không — và với dữ liệu tranh chấp giao dịch, đó là khác biệt thật.
• D. Dùng NAT gateway cho mọi lời gọi Bedrock, hạn chế truy cập NAT chỉ cho subnet ứng dụng; thêm route table entry để chuyển đổi giữa các AZ — NAT gateway đi RA INTERNET: lưu lượng rời khỏi mạng AWS của bạn và đi qua Internet công cộng tới endpoint công khai của Bedrock. Vi phạm thẳng yêu cầu "no exposure to the public internet".
• A. Tạo VPC endpoint SERVICE cho ứng dụng và gắn security group hạn chế subnet, định tuyến lưu lượng Bedrock qua service đó; dùng DNS nội bộ — nhầm chiều: VPC endpoint service là thứ bạn tạo để phơi dịch vụ CỦA BẠN cho người khác. Để tiêu thụ một dịch vụ AWS, bạn cần interface endpoint.

Ghi nhớ

Hai loại VPC endpoint: | Loại | Cơ chế | Dùng cho | |---|---|---| | Gateway endpoint | route table entry — MIỄN PHÍ | chỉ S3 và DynamoDB | | Interface endpoint | ENI trong subnet — tính phí theo giờ và GB | hầu hết dịch vụ khác, gồm Bedrock |

Ba lớp kiểm soát cho interface endpoint — nên dùng cả ba: | Lớp | Kiểm soát | |---|---| | Security group trên endpoint | AI (nguồn nào) kết nối được | | Endpoint policy | hành động và tài nguyên nào được phép qua endpoint này | | IAM policy | quyền của principal gọi |

Lớp giữa hay bị bỏ qua nhưng rất mạnh: nó cho phép nói "qua endpoint này chỉ được gọi model X, không được tạo custom model" — một ràng buộc mà IAM policy của từng role khó bao quát hết.

Hai endpoint của Bedrock cần phân biệt: | Endpoint | Việc | |---|---| | com.amazonaws.<region>.bedrock-runtime | gọi model — cái bạn cần cho suy luận | | com.amazonaws.<region>.bedrock | quản lý: tạo custom model, quản guardrail | | com.amazonaws.<region>.bedrock-agent-runtime | gọi agent và knowledge base |

Ứng dụng RAG thường cần cả cái đầu và cái cuối — thiếu cái cuối thì truy xuất từ Knowledge Base sẽ đi ra Internet, một lỗ hổng dễ bỏ sót.

Và ba việc nên làm để xác nhận cách ly thật sự:

1. Bỏ NAT gateway và Internet gateway khỏi subnet ứng dụng — nếu ứng dụng vẫn chạy, bạn biết chắc không có đường ra Internet.
2. Bật enableDnsHostnames và enablePrivateDnsName — nếu không, ứng dụng vẫn phân giải ra IP công khai.
3. Bật VPC Flow Logs — xác nhận không có lưu lượng nào đi tới IP ngoài.

Đáp án

A và E.

• A — Dùng Bedrock Prompt Management định nghĩa system prompt có tham số, áp template đầu ra theo JSON Schema, và cấu hình quy trình phê duyệt
• E — Áp Bedrock Guardrails để thực thi yêu cầu về giọng điệu và chặn nội dung tư vấn pháp lý trên mọi tương tác với model

Vì sao đúng

Đề nêu ba yêu cầu tuân thủ, và chúng cần hai cơ chế khác nhau: | Yêu cầu | Cơ chế | |---|---| | Giọng điệu chuyên nghiệp đã duyệt | A (định nghĩa trong prompt) + E (chặn vi phạm) | | Không đưa lời khuyên pháp lý | E — denied topics | | Đầu ra theo JSON schema nghiêm ngặt | A — template có schema |

Vì sao cần cả hai chứ không chỉ một:

Prompt Management: BẢO model phải làm gì
    → hiệu quả, nhưng model có thể lệch

Guardrails:        CHẶN khi model làm sai
    → thực thi cứng ở tầng dịch vụ

Với "avoid legal advice" — một yêu cầu tuân thủ cứng — chỉ dặn trong prompt là không đủ. Denied topics của Guardrails nhận diện theo ngữ nghĩa, nên nó bắt được cả những câu trả lời lách khéo:

{"topicPolicyConfig": {"topicsConfig": [{
  "name": "TuVanPhapLy",
  "definition": "Bất kỳ diễn giải nào về quyền pháp lý, nghĩa vụ hợp đồng, hoặc khuyến nghị hành động pháp lý",
  "examples": ["Tôi có quyền đòi bồi thường không?",
               "Theo luật thì shop phải hoàn tiền cho tôi đúng không?"],
  "type": "DENY"}]}}

Và A cho vế tập trung: một prompt template dùng chung cho mọi microservice, nên giọng điệu và schema không thể lệch giữa các đội — đúng thứ đề yêu cầu.

Vì sao các phương án khác sai

• B. Prompt Management lưu mọi template nhưng cho microservice TỰ ĐỘNG thăng phiên bản template trong quá trình CI — bỏ mất cửa kiểm soát: mỗi đội tự đẩy version mới nghĩa là không còn quản trị tập trung, và một đội đổi giọng điệu sẽ ảnh hưởng mà không ai duyệt.
• C. DynamoDB lưu JSON schema và Lambda tiêm hướng dẫn giọng điệu, lọc nội dung cấm; Step Functions điều phối việc chọn prompt — tự dựng lại Guardrails và Prompt Management: bạn phải tự viết bộ lọc nội dung (khó và dễ sót), tự quản version, và mỗi microservice phải gọi đúng chuỗi bước.
• D. Lưu template trên S3 với IAM hạn chế ai sửa được; CloudWatch Logs xem lại cách dùng và đảm bảo ứng dụng tuân theo định dạng JSON — "xem lại log" không phải thực thi: nếu một service trả sai định dạng, hệ thống phía sau đã hỏng trước khi ai đọc log. Và S3 không có khái niệm phiên bản prompt gắn với cấu hình model.

Ghi nhớ

Hai tầng kiểm soát hành vi model — dùng cùng nhau: | Tầng | Cơ chế | Đặc điểm | |---|---|---| | Chỉ dẫn (prompt) | system prompt, template | linh hoạt, nhưng model có thể lệch | | Thực thi (guardrail) | denied topics, content filter | cứng, không lệch được |

Quy tắc chọn: yêu cầu tuân thủ cứng thì phải có tầng hai. "Nên dùng giọng trang trọng" có thể để tầng một; "không bao giờ đưa lời khuyên pháp lý" thì bắt buộc tầng hai.

Ba cách ép đầu ra JSON, theo độ tin cậy: | Cách | Đảm bảo | |---|---| | Khai schema trong prompt | cao với model tốt, vẫn có thể lệch | | JSON mode | JSON hợp lệ, không đảm bảo schema | | Tool use (toolConfig) | ép đúng schema và enum ở tầng API |

Với "strict JSON output schema that downstream systems can reliably process" như đề yêu cầu, nên dùng cả template lẫn toolConfig — template để mô tả ý định, toolConfig để đảm bảo.

Ghi chú về chất lượng câu hỏi. Phương án A nhắc "configure approval workflows" trong Prompt Management. Như đã nêu ở #6390, #6402 và #6417 của lô trước, dịch vụ này cung cấp version bất biến và vết kiểm toán qua CloudTrail, còn quy trình phê duyệt nhiều bước phải ghép bằng IAM hoặc pipeline bên ngoài. A vẫn là đáp án đúng — hai vế "parameterized system prompts" và "JSON Schema based output templates" đều chính xác, và nó là lựa chọn tập trung tốt nhất trong bốn — nhưng đừng đọc thành "Bedrock có màn hình duyệt sẵn". Đây là câu thứ tư trong cùng bộ đề lặp lại cách diễn đạt này.

Và một lợi ích của Guardrails hay bị bỏ sót: nó có version, nên cập nhật danh sách chủ đề cấm ở một chỗ là mọi microservice được hưởng ngay — không cần đội nào triển khai lại gì.

Đáp án

A — Cấu hình SageMaker asynchronous inference endpoint đọc payload đầu vào từ S3 và xử lý request kiểm duyệt ở nền, trả kết quả về vị trí đầu ra trên S3; dùng hàng đợi hoặc tiến trình theo lịch tải các lô hằng đêm lên để endpoint co giãn dần dần và tối ưu mức dùng instance cho job chạy lâu.

Vì sao đúng

Đề mô tả đúng sự lệch pha giữa hình dạng workload và kiểu triển khai: | Đặc điểm workload | Kiểu triển khai phù hợp | |---|---| | Không phục vụ người dùng trực tiếp | không cần real-time | | Hoàn thành trong vài giờ là chấp nhận được | bất đồng bộ | | Khối lượng rất lớn, dồn vào một cửa sổ | cần đệm để làm phẳng tải |

Endpoint real-time hiện tại co giãn dựng đứng trong cửa sổ ban đêm — gây chi phí cao và throttling. Đó là hệ quả tự nhiên của việc dùng kiểu triển khai tối ưu cho độ trễ thấp vào một workload không cần độ trễ thấp.

Asynchronous inference giải quyết bằng hàng đợi nội bộ:

Client → InvokeEndpointAsync (trả về ngay, kèm vị trí output)
              ↓
        Hàng đợi nội bộ của SageMaker  ← đệm, làm phẳng đỉnh
              ↓
        Endpoint xử lý theo năng lực thật
              ↓
        Kết quả ghi ra S3 + thông báo qua SNS

Ba lợi ích khớp đúng yêu cầu của đề: | Lợi ích | Chi tiết | |---|---| | Hấp thụ khối lượng rất lớn | hàng đợi giữ request, không từ chối | | Làm phẳng tải | endpoint co giãn DẦN, không dựng đứng | | Co giãn xuống 0 | MinCapacity: 0 — không trả tiền ngoài cửa sổ ban đêm |

Dòng cuối là điểm tiết kiệm lớn nhất: workload chỉ chạy vài giờ mỗi đêm, nên 20 giờ còn lại không tốn gì.

sm.create_endpoint_config(
    AsyncInferenceConfig={
        'OutputConfig': {'S3OutputPath': 's3://.../ket-qua/',
                         'NotificationConfig': {'SuccessTopic': arn_sns}},
        'ClientConfig': {'MaxConcurrentInvocationsPerInstance': 4}})

Vì sao các phương án khác sai

• D. Giữ endpoint real-time và đặt SQS phía trước cho một đội Lambda rút hàng đợi bằng cách gửi request ĐỒNG BỘ tới endpoint; dựa vào Auto Scaling mở rộng nhanh trong cửa sổ ban đêm — đây là phương án gần nhất và nó tự dựng lại hàng đợi mà async inference có sẵn, đồng thời giữ nguyên endpoint real-time với chi phí chạy 24/7. Lambda gọi đồng bộ cũng bị giới hạn 15 phút và vẫn gây đỉnh tải lên endpoint.
• C. Tăng kích thước và số instance tối đa của endpoint real-time hiện tại với chính sách scale-out quyết liệt; dùng reserved instance hoặc savings plan để bù chi phí — giải quyết throttling bằng cách trả nhiều tiền hơn, và reserved instance cam kết trả tiền cả 20 giờ endpoint rảnh. Đi ngược yêu cầu tối ưu chi phí.
• B. Thay bằng Bedrock provisioned throughput để có năng lực riêng và xử lý THỜI GIAN THỰC toàn bộ bài đăng trong cửa sổ; tăng provisioned unit lúc cao điểm — giữ nguyên giả định sai rằng workload cần thời gian thực. Và provisioned throughput là cam kết trả tiền cho năng lực giữ sẵn — đắt nhất trong bốn phương án cho một job chạy vài giờ mỗi đêm.

Ghi nhớ

Bốn kiểu suy luận của SageMaker — chọn theo hình dạng workload: | Kiểu | Độ trễ | Co giãn về 0 | Dùng khi | |---|---|---|---| | Real-time | mili giây | ❌ | người dùng đang chờ | | Serverless | có cold start | ✅ | tải thưa, không cần GPU | | Asynchronous | phút tới giờ | ✅ | payload lớn, xử lý lâu, có hàng đợi ← câu này | | Batch transform | theo job | ✅ (không có endpoint) | xử lý một tệp lớn, không cần endpoint thường trực |

Phân biệt hai kiểu cuối — dễ nhầm nhất: | | Asynchronous inference | Batch transform | |---|---|---| | Có endpoint thường trực | ✅ (co giãn về 0 được) | ❌ job chạy rồi kết thúc | | Gọi theo | từng request | cả tệp dữ liệu | | Hợp với | luồng request rải rác, payload lớn | lô cố định, biết trước dữ liệu |

Với đề này, cả hai đều hợp lý — và batch transform thậm chí có thể rẻ hơn nếu toàn bộ bài đăng đã nằm sẵn trong một tệp. Đáp án A chọn async vì đề nói bài đăng đến trong ngày và được xử lý ban đêm: hàng đợi của async cho phép đẩy dần vào thay vì gom thành một tệp.

Ba tham số cần đặt cho async endpoint: | Tham số | Việc | |---|---| | MaxConcurrentInvocationsPerInstance | số request song song mỗi instance | | MinCapacity: 0 | cho phép co về 0 khi hàng đợi rỗng | | ApproximateBacklogSizePerInstance | metric để auto scaling — co giãn theo ĐỘ SÂU HÀNG ĐỢI |

Dòng cuối là điểm hay: auto scaling theo độ sâu hàng đợi chính xác hơn nhiều so với theo CPU — nó phản ánh trực tiếp lượng việc còn tồn.

Và một lựa chọn nữa đáng cân nhắc nếu model kiểm duyệt có thể thay bằng foundation model: Bedrock Batch Inference cho giá thấp hơn khoảng 50% so với on-demand, và không phải quản lý endpoint nào.