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

Đáp án

A — Đo đạc workflow bằng X-Ray để theo dấu từng lần gọi prompt và biến đổi dữ liệu, kèm JSON schema validation TRƯỚC MỖI GIAI ĐOẠN; ghi lỗi validation vào CloudWatch Logs và cảnh báo qua SNS.

Vì sao đúng

Đề nêu hai vấn đề, và đáp án phải giải quyết cả hai:

1. Bước sau thất bại vì trường bị thiếu, sai tên, hoặc sai định dạng
2. Không lần ra được giai đoạn nào gây lỗi

Điểm mấu chốt là hai chữ "detected early" — nghĩa là phòng ngừa, không phải phát hiện sau khi hỏng.

Schema validation trước mỗi giai đoạn biến một lỗi mơ hồ ở cuối chuỗi thành một lỗi rõ ràng ngay tại chỗ phát sinh:

from jsonschema import validate, ValidationError

SCHEMA_GIAI_DOAN_2 = {
    "type": "object",
    "required": ["maDon", "danhSachSanPham", "tongTien"],
    "properties": {
        "maDon": {"type": "string", "pattern": "^DH-[0-9]{6}$"},
        "danhSachSanPham": {"type": "array", "minItems": 1},
        "tongTien": {"type": "number", "minimum": 0}
    }
}

def lambda_handler(event, context):
    try:
        validate(instance=event, schema=SCHEMA_GIAI_DOAN_2)
    except ValidationError as e:
        logger.error(f"Schema sai ở giai đoạn 2: {e.message}, đường dẫn: {list(e.path)}")
        sns.publish(TopicArn=CANH_BAO, Message=f"Vi phạm schema: {e.message}")
        raise

Thay vì "giai đoạn 4 lỗi vì KeyError: tongTien", bạn nhận được "đầu vào giai đoạn 2 thiếu trường tongTien" — tức là biết ngay giai đoạn 1 mới là thủ phạm.

X-Ray bổ sung chiều thứ hai: nó cho thấy toàn bộ đường đi của một request qua các giai đoạn, kèm thời gian và lỗi ở từng chặng:

from aws_xray_sdk.core import xray_recorder

with xray_recorder.in_subsegment('giai-doan-2-trich-xuat') as sub:
    sub.put_annotation('ma_don', event['maDon'])     # lọc trace theo đơn hàng
    sub.put_metadata('payload_vao', event)           # xem chi tiết khi cần

Và SNS cảnh báo ngay khi có vi phạm — thay vì phát hiện khi người dùng báo lỗi.

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

• B. X-Ray tracing, xem CloudWatch Logs thủ công khi có lỗi, bắt lỗi lúc chạy thay vì kiểm tra trước — thiếu vế phòng ngừa: cụm "rather than pre-validation" trái thẳng yêu cầu "detected early". Và "manually inspect" không phải quan sát tự động.
• C. X-Ray, ghi mọi payload trung gian vào CloudWatch Logs, xử lý trường sai ở Lambda phía sau, chỉ cảnh báo khi kết quả CUỐI CÙNG hỏng — phát hiện muộn nhất có thể: lỗi từ giai đoạn 1 chỉ lộ ra ở giai đoạn cuối, đúng vấn đề đề đang than phiền. Và ghi toàn bộ payload ở mọi giai đoạn còn tốn kém và có thể lộ dữ liệu nhạy cảm.
• D. Bỏ hẳn schema validation, chỉ ghi log rồi phân tích sau; dùng CloudWatch Metrics đếm số lần lỗi — không có cơ chế phòng ngừa nào, và "post-hoc analysis" là đúng thứ đang gây khó khăn hiện tại.

Ghi nhớ

Hai trụ cột của khả năng gỡ lỗi trong pipeline nhiều bước: | Trụ cột | Công cụ | Trả lời câu hỏi | |---|---|---| | Validation | JSON Schema ở ranh giới mỗi giai đoạn | "dữ liệu này có hợp lệ không?" | | Tracing | X-Ray | "request này đã đi qua đâu, hỏng ở chặng nào?" |

Nguyên tắc thiết kế đằng sau: fail fast at the boundary — kiểm tra hợp đồng dữ liệu ngay tại ranh giới giữa các thành phần, thay vì để dữ liệu hỏng lan truyền rồi nổ ở nơi khác.

Ba nơi đặt validation trong workflow GenAI: | Nơi | Kiểm gì | |---|---| | Đầu vào mỗi giai đoạn | trường bắt buộc, kiểu dữ liệu, định dạng | | Đầu ra của model | model có trả đúng JSON schema không | | Đầu ra cuối cùng | hợp đồng với hệ thống tiêu thụ |

Dòng thứ hai đặc biệt quan trọng với GenAI: model có thể trả về JSON sai cấu trúc dù bạn đã yêu cầu. Hai cách giảm rủi ro: | Cách | Chi tiết | |---|---| | Structured output / tool use | ép model trả đúng schema ở tầng API | | Validation + retry | bắt lỗi rồi gọi lại kèm thông báo lỗi |

Với Bedrock, cách thứ nhất dùng toolConfig trong Converse API — model buộc phải điền đúng các trường bạn khai.

Hai khái niệm của X-Ray cần phân biệt: | | Annotation | Metadata | |---|---|---| | Tìm kiếm được | ✅ | ❌ | | Dùng cho | ma_don, giai_doan, model_id | payload đầy đủ để đọc |

Muốn lọc trace theo một đơn hàng cụ thể thì phải ghi nó làm annotation.

Và với Step Functions, có một lựa chọn thay thế gọn hơn: ItemSelector và ResultSelector kiểm soát hình dạng dữ liệu giữa các state ngay trong định nghĩa máy trạng thái — giảm bớt mã validation phải viết.

Đáp án

C — Dùng zero-shot chain-of-thought prompting: yêu cầu model suy luận từng bước và trả về định dạng có cấu trúc; ghi phản hồi trung gian vào CloudWatch để đánh giá, và dùng prompt versioning để cải tiến dần mà không cần huấn luyện lại.

Vì sao đúng

Đề nêu bốn yêu cầu, và tất cả đều chỉ về kỹ thuật prompt, không phải huấn luyện:

1. Cải thiện độ rõ ràng của lập luận
2. Ép định dạng đầu ra ổn định
3. Cải tiến dần bằng phản hồi và tín hiệu đánh giá
4. KHÔNG fine-tune model

Chain-of-thought (CoT) là kỹ thuật giải quyết đúng vấn đề "lập luận nông và không nhất quán":

prompt = '''Bạn là trợ lý phân tích chính sách bảo hiểm.

Hãy suy luận TỪNG BƯỚC theo trình tự sau trước khi kết luận:
1. Xác định các điều kiện áp dụng trong hồ sơ
2. Đối chiếu từng điều kiện với quy định
3. Nêu rõ điều kiện nào thoả, điều kiện nào không
4. Kết luận về tính đủ điều kiện

Trả về JSON theo cấu trúc:
{
  "cac_buoc_suy_luan": [{"buoc": 1, "noi_dung": "..."}],
  "dieu_kien_thoa": [...],
  "dieu_kien_khong_thoa": [...],
  "ket_luan": "...",
  "do_tin_cay": 0.0
}

Hồ sơ: {ho_so}'''

"Zero-shot" CoT nghĩa là không cần ví dụ mẫu — chỉ cần chỉ thị "reason step by step". Đây là điểm khiến nó rẻ và dễ triển khai hơn few-shot.

Và ba yêu cầu còn lại được đáp ứng bởi phần sau của đáp án: | Yêu cầu | Cơ chế | |---|---| | Định dạng ổn định | khai schema JSON trong prompt (hoặc dùng tool use để ép cứng) | | Cải tiến dần | ghi phản hồi trung gian vào CloudWatch để đánh giá | | Quản lý phiên bản | prompt versioning — so sánh và rollback được |

Điểm hay của việc ghi lại các bước suy luận trung gian: bạn thấy được model sai ở bước nào, chứ không chỉ biết "câu trả lời cuối sai" — đó là dữ liệu để sửa prompt.

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

• A. Zero-shot prompt yêu cầu câu trả lời NGẮN GỌN, ép JSON schema, ưu tiên validation hơn lập luận — đi ngược vấn đề: đề nói lập luận "nông và khó theo dõi", mà phương án này lại yêu cầu model bỏ qua phần lập luận. Validation kiểm tra hình thức, không cải thiện chất lượng suy nghĩ.
• B. Fine-tune model bằng tập dữ liệu suy luận, dựng pipeline huấn luyện lại bằng Step Functions — vi phạm thẳng ràng buộc "without fine tuning the foundation model". Ngoài ra nó tốn kém, chậm, và cần tập dữ liệu chất lượng cao mà đề không nhắc tới.
• D. Few-shot với ví dụ chỉ cho kết quả cuối, giấu các bước trung gian; gọi lặp nhiều lần để tăng nhất quán — dạy model đúng thứ cần tránh: ví dụ không có bước suy luận sẽ khiến model bắt chước lối trả lời tắt. Và gọi lặp nhiều lần tốn chi phí gấp bội mà không giải quyết gốc rễ.

Ghi nhớ

Bốn kỹ thuật prompt để cải thiện lập luận: | Kỹ thuật | Cách làm | Chi phí | |---|---|---| | Zero-shot CoT | "Hãy suy luận từng bước" | thấp nhất | | Few-shot CoT | kèm ví dụ CÓ các bước suy luận | vừa (tốn token) | | Self-consistency | chạy nhiều lần, lấy đáp án đa số | cao | | Tree of Thoughts | khám phá nhiều nhánh suy luận | cao nhất |

Bậc thang tuỳ biến model — chọn theo mức độ cần thiết: | Mức | Kỹ thuật | Chi phí | Khi nào | |---|---|---|---| | 1 | Prompt engineering | rất thấp | luôn thử trước | | 2 | RAG | thấp | cần kiến thức riêng | | 3 | Fine-tuning (LoRA) | vừa | cần học hành vi và định dạng riêng | | 4 | Full fine-tuning | cao | hiếm khi cần | | 5 | Continued pre-training | rất cao | ngôn ngữ chuyên ngành rất khác biệt |

Nguyên tắc: luôn leo thang từ bậc 1 — rất nhiều vấn đề tưởng cần fine-tune thực ra giải được bằng prompt tốt hơn.

Ba công cụ của Bedrock hỗ trợ quy trình cải tiến prompt: | Công cụ | Việc | |---|---| | Prompt Management | lưu, đánh version, chia sẻ prompt | | Prompt Flows | ghép nhiều bước prompt thành workflow trực quan | | Model Evaluation | chấm điểm tự động hoặc bằng người, so sánh các phiên bản |

Và một mẹo quan trọng khi dùng CoT với đầu ra JSON: để phần suy luận ra một trường riêng (như cac_buoc_suy_luan ở trên) thay vì trộn vào văn xuôi. Cách này vừa giữ được lợi ích của CoT, vừa cho phép hệ thống downstream chỉ đọc trường ket_luan mà không phải phân tích văn bản tự do.

Đáp án

B — Dùng semantic chunking: chia tài liệu theo ranh giới ý nghĩa và chủ đề trước khi tạo embedding, đưa các chunk mạch lạc về ngữ nghĩa vào model sao cho mỗi request nằm gọn trong context window, và chọn chunk động lúc truy vấn.

Vì sao đúng

Đề mô tả ba triệu chứng, và cả ba đều xuất phát từ cách chia tài liệu: | Triệu chứng | Nguyên nhân | |---|---| | Câu trả lời thiếu hoặc bỏ sót phần quan trọng | ngữ cảnh bị cắt | | "Một phần đầu vào không tới được model" | truncation do vượt context window | | Tệ hơn khi tài liệu lớn | chia tài liệu không theo cấu trúc nội dung |

Semantic chunking giải quyết bằng cách chia theo ranh giới ý nghĩa thay vì đếm token máy móc:

Chia theo token cố định:
  "...quy trình bảo trì gồm ba bước. Bước một là kiểm tra áp | suất dầu ở van số 4..."
                                                              ↑ CẮT GIỮA CÂU

Semantic chunking:
  [Chunk 1: toàn bộ mục "Quy trình bảo trì" — 3 bước đầy đủ]
  [Chunk 2: toàn bộ mục "Xử lý sự cố" ]

Ba lợi ích khớp đúng với đề: | Lợi ích | Chi tiết | |---|---| | Mỗi chunk tự đủ nghĩa | model không nhận nửa câu hay nửa quy trình | | Mỗi request nằm gọn trong context window | không có truncation | | Chọn chunk động lúc truy vấn | chỉ đưa vào phần LIÊN QUAN, không nhồi cả tài liệu |

Vế cuối là điểm quan trọng nhất về mặt kiến trúc: thay vì cố nhét cả tài liệu vào prompt (và bị cắt), hệ thống truy xuất đúng vài chunk liên quan cho từng câu hỏi.

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

• A. Semantic chunking kèm giới hạn token cố định, tính sẵn tóm tắt cho mọi chunk, nối tất cả tóm tắt vào MỘT prompt và dựa vào truncation khi vượt giới hạn — vẫn giữ nguyên vấn đề: cụm "rely on truncation to discard excess tokens" chính là nguyên nhân mất nội dung mà đề đang than phiền. Nửa đầu đúng, nửa sau phá hỏng tất cả.
• C. Hierarchical chunking chia theo chương, mục, đoạn; gộp chunk con thành tóm tắt cha và chỉ đưa tóm tắt cấp cao vào model — đây là phương án đáng bàn: hierarchical chunking là kỹ thuật hợp lệ và hữu ích. Nhưng chỉ đưa tóm tắt cấp cao vào model nghĩa là mất chi tiết — và đề nói rõ câu trả lời đang thiếu "critical sections", tức là cần chi tiết chứ không phải tóm tắt. (Mẫu đúng của hierarchical chunking là tìm bằng tóm tắt, đưa vào model bằng chunk con — phương án này làm ngược.)
• D. Chia theo token cố định, dùng prompt compression, cắt bỏ chunk ưu tiên thấp khi chạm giới hạn — chấp nhận mất dữ liệu như một thiết kế. Và "chunk ưu tiên thấp" được quyết định trước khi biết câu hỏi là gì — nên phần bị cắt có thể chính là phần cần thiết.

Ghi nhớ

Bốn chiến lược chia tài liệu: | Chiến lược | Cách chia | Ưu điểm | Nhược điểm | |---|---|---|---| | Fixed-size | đếm token/ký tự | đơn giản nhất | cắt giữa câu, mất ngữ cảnh | | Semantic | theo ranh giới ý nghĩa | chunk tự đủ nghĩa | tốn tính toán hơn | | Hierarchical | cha–con: chương → mục → đoạn | giữ được cấu trúc | phức tạp hơn | | Fixed-size + overlap | cố định nhưng chồng lấn | giảm mất ngữ cảnh ở biên | trùng lặp dữ liệu |

Bedrock Knowledge Bases hỗ trợ sẵn cả bốn:

{
  "chunkingConfiguration": {
    "chunkingStrategy": "SEMANTIC",
    "semanticChunkingConfiguration": {
      "maxTokens": 300,
      "bufferSize": 1,
      "breakpointPercentileThreshold": 95
    }
  }
}

Tham số breakpointPercentileThreshold quyết định độ nhạy: giá trị cao thì chia ít chỗ hơn (chunk lớn hơn), thấp thì chia nhiều hơn.

Ba nguyên tắc chọn kích thước chunk: | Nguyên tắc | Chi tiết | |---|---| | Đủ lớn để tự đủ nghĩa | một quy trình, một khái niệm trọn vẹn | | Đủ nhỏ để đưa nhiều chunk vào prompt | thường 200–500 token | | Khớp với dạng câu hỏi | câu hỏi chi tiết ⇒ chunk nhỏ; câu hỏi tổng quan ⇒ chunk lớn |

Và mẫu parent–child retrieval đáng biết cho tài liệu kỹ thuật lớn — nó kết hợp ưu điểm của hai chiến lược:

Tìm kiếm bằng: chunk NHỎ (chính xác về ngữ nghĩa)
Đưa vào model:  chunk CHA của nó (đầy đủ ngữ cảnh)

Cách này cho độ chính xác của chunk nhỏ và ngữ cảnh của chunk lớn — thường là lựa chọn tốt nhất cho báo cáo kỹ thuật dài như đề mô tả.

Đáp án

B — Dùng Titan Text Lite cấu hình JSON mode hoặc function calling để đầu ra theo schema định sẵn, và stream phản hồi qua Bedrock Converse API để giảm thời gian tới token đầu tiên.

Vì sao đúng

Đề đưa ra năm ràng buộc cùng lúc, và đáp án phải thoả hết: | Ràng buộc | Cách B đáp ứng | |---|---| | Hạ tầng tối thiểu | Bedrock — serverless, không quản lý gì | | Dưới 400 mili giây | model nhẹ + streaming | | Hàng triệu request/ngày | Bedrock tự co giãn | | Chi phí suy luận rất thấp | Titan Text Lite là model rẻ nhất | | JSON theo schema nghiêm ngặt | JSON mode / function calling ép cứng ở tầng API |

Hai lựa chọn kỹ thuật đáng phân tích:

Model nhẹ cho tác vụ hẹp. Dữ liệu đầu vào là telemetry có cấu trúc (tốc độ, gia tốc, phanh, xếp hạng), và đầu ra là nhận định ngắn. Đây không phải tác vụ cần suy luận sâu — nên model lớn là lãng phí cả tiền lẫn độ trễ.

Function calling để ép schema. Đây là điểm quan trọng nhất cho yêu cầu "minimize hallucinations" và "strict JSON schema":

response = bedrock.converse(
    modelId='amazon.titan-text-lite-v1',
    messages=[{"role": "user", "content": [{"text": mo_ta_telemetry}]}],
    toolConfig={
        "tools": [{"toolSpec": {
            "name": "ghi_nhan_dinh_rui_ro",
            "inputSchema": {"json": {
                "type": "object",
                "required": ["mucDoRuiRo", "yeuToChinh", "diemSo"],
                "properties": {
                    "mucDoRuiRo": {"type": "string", "enum": ["thap", "trung-binh", "cao"]},
                    "yeuToChinh": {"type": "array", "items": {"type": "string"}},
                    "diemSo": {"type": "number", "minimum": 0, "maximum": 100}
                }}}}}],
        "toolChoice": {"tool": {"name": "ghi_nhan_dinh_rui_ro"}}
    }
)

Khác biệt với việc "nhắc model trả JSON" trong prompt: ở đây schema được thực thi ở tầng API, và enum giới hạn giá trị hợp lệ — nên hệ thống downstream luôn parse được, và model không bịa ra mức rủi ro không tồn tại.

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

• C. Dùng Claude 3 Sonnet, dựa vào prompt engineering để ép schema, chỉnh temperature và top-p — sai hai chỗ. Thứ nhất, Sonnet là model mạnh và đắt hơn nhiều — trái yêu cầu "very low inference cost" và khó đạt 400 mili giây. Thứ hai, prompt engineering KHÔNG đảm bảo schema — model vẫn có thể trả về JSON sai cấu trúc, mà đề nói downstream cần parse tin cậy. (Chỉnh temperature giảm được độ ngẫu nhiên nhưng không phải cơ chế ép cứng.)
• A. Fine-tune transformer lớn trên SageMaker GPU, tự co giãn số instance, ép schema bằng mã hậu xử lý — trái yêu cầu "minimum infrastructure management": bạn phải quản lý endpoint, instance, auto scaling. Và GPU instance chạy liên tục rất đắt — trái yêu cầu chi phí thấp.
• D. Dùng Bedrock Knowledge Base embed sự kiện telemetry, tìm kiếm ngữ nghĩa các mẫu lái xe tương tự, rồi sinh tóm tắt — sai công cụ cho loại dữ liệu: telemetry là dữ liệu số có cấu trúc, không phải văn bản cần tìm kiếm ngữ nghĩa. Và thêm một bước truy xuất vector làm tăng độ trễ — khó đạt 400 mili giây.

Ghi nhớ

Ba cách ép đầu ra theo cấu trúc, theo độ tin cậy tăng dần: | Cách | Đảm bảo | Ghi chú | |---|---|---| | Nhắc trong prompt | thấp — model có thể lệch | dễ nhất | | JSON mode | cao — đảm bảo JSON hợp lệ | không ép được schema cụ thể | | Function calling / tool use | cao nhất — ép đúng schema và enum | khuyến nghị cho hệ thống production |

Chọn model theo tác vụ — nguyên tắc quan trọng nhất về chi phí GenAI: | Tác vụ | Model | |---|---| | Phân loại, trích xuất, tóm tắt ngắn | model nhẹ (Titan Lite, Nova Micro, Claude Haiku) | | Suy luận nhiều bước, phân tích phức tạp | model mạnh (Claude Sonnet, Nova Pro) | | Tác vụ hỗn hợp | cascading — nhẹ trước, leo thang khi cần |

Bốn cách giảm độ trễ trong ứng dụng GenAI: | Cách | Hiệu quả | |---|---| | Chọn model nhẹ hơn | lớn nhất | | Streaming | giảm TTFT (cảm nhận), không giảm tổng | | Rút gọn prompt | ít token đầu vào ⇒ nhanh hơn | | Prompt caching | với phần prefix cố định |

Và với yêu cầu "minimize hallucinations" cho dữ liệu đi vào báo cáo pháp lý, nên bổ sung thêm hai lớp:

1. Bedrock Guardrails với contextual grounding check — chặn câu trả lời không dựa trên dữ liệu đầu vào.
2. Validation ở tầng ứng dụng — kiểm tra diemSo có nằm trong khoảng hợp lý so với telemetry thô hay không.

Vì đầu ra đi vào tính toán bảo hiểm và báo cáo cho cơ quan quản lý, hai lớp này đáng giá hơn nhiều so với chi phí thêm.

Đáp án

C — Dùng SageMaker real-time inference với GPU instance lớn (ml.p4d hoặc ml.g5), kéo dài timeout khởi động container và health check, tăng hạn mức nạp model, và cấu hình health check sao cho endpoint chỉ sẵn sàng khi model đã tải xong hoàn toàn.

Vì sao đúng

Đề mô tả đúng vấn đề: model vài trăm gigabyte mất rất lâu để tải và nạp vào GPU, khiến container khởi động thất bại và hệ thống không bao giờ sẵn sàng.

Nguyên nhân là timeout mặc định quá ngắn so với thời gian nạp thực tế:

Mặc định: container phải phản hồi health check trong vài phút
Thực tế:  tải 300 GB từ S3 + nạp vào GPU memory = 30–60 phút
       ⇒ SageMaker coi là hỏng, khởi động lại, và lặp vô tận

Đáp án C sửa đúng nguyên nhân bằng ba thay đổi:

aws sagemaker create-model --model-name model-lon \
  --primary-container '{
    "Image": "...",
    "ModelDataSource": {"S3DataSource": {"S3Uri": "s3://kho/model/", "S3DataType": "S3Prefix",
                                          "CompressionType": "None"}},
    "ContainerStartupHealthCheckTimeoutInSeconds": 3600,
    "ModelDataDownloadTimeoutInSeconds": 3600
  }'

Và vế "deployments do not roll back during long initialization" được đáp ứng vì health check chỉ báo sẵn sàng sau khi model nạp xong — SageMaker không hiểu nhầm quá trình nạp là lỗi.

Một chi tiết đáng biết: dùng CompressionType: None với S3DataSource kiểu prefix cho phép SageMaker tải song song nhiều tệp, nhanh hơn hẳn so với giải nén một tệp model.tar.gz khổng lồ.

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

• A. Instance GPU lớn nhưng giữ nguyên timeout mặc định, dựa vào tự động thử lại — không sửa nguyên nhân: thử lại bao nhiêu lần cũng vẫn vượt timeout, vì thời gian nạp không đổi. Vòng lặp khởi động–thất bại lặp vô tận.
• B. Instance GPU trung bình và RÚT NGẮN timeout để container hỏng khởi động lại nhanh — làm tình hình tệ hơn về mọi mặt: timeout ngắn hơn nghĩa là chắc chắn thất bại sớm hơn, và instance nhỏ hơn có thể không đủ GPU memory. Câu "rely on repeated restarts to eventually complete" là vô lý — mỗi lần khởi động lại đều bắt đầu từ đầu.
• D. Dùng multi-model endpoint để nạp model theo yêu cầu — sai kịch bản sử dụng: MME thiết kế cho nhiều model NHỎ chia sẻ một endpoint, nạp và loại bỏ (evict) động. Với một model vài trăm GB, việc evict rồi nạp lại là thảm hoạ về độ trễ — và MME cũng không đủ chỗ cho nhiều model cỡ đó.

Ghi nhớ

Các tham số timeout khi triển khai model lớn trên SageMaker: | Tham số | Mặc định | Tối đa | Việc | |---|---|---|---| | ContainerStartupHealthCheckTimeoutInSeconds | ~300 giây | 3600 giây | chờ container sẵn sàng | | ModelDataDownloadTimeoutInSeconds | ~1800 giây | 3600 giây | tải model từ S3 | | InvocationsTimeoutInSeconds | 60 giây | 3600 giây | timeout mỗi lần suy luận |

Bốn kiểu triển khai của SageMaker: | Kiểu | Dùng khi | |---|---| | Real-time | độ trễ thấp, tải liên tục ← câu này | | Serverless | tải thưa, chấp nhận cold start; không hỗ trợ GPU | | Asynchronous | payload lớn, thời gian xử lý dài, có hàng đợi | | Batch transform | xử lý theo lô, không cần endpoint | | Multi-model endpoint | nhiều model NHỎ dùng chung endpoint |

Ba kỹ thuật tăng tốc nạp model rất lớn: | Kỹ thuật | Hiệu quả | |---|---| | CompressionType: None + S3 prefix | tải song song nhiều tệp thay vì giải nén một tệp lớn | | SageMaker fast model loader | stream trọng số thẳng vào GPU, giảm mạnh thời gian khởi động | | Uncompressed model artifacts | bỏ hẳn bước giải nén |

Và với vế "inference happens entirely within its private network boundary" trong đề, nhớ hai cấu hình đi kèm:

1. VpcConfig cho endpoint — đặt nó vào subnet riêng của bạn.
2. VPC endpoint cho SageMaker Runtime và S3 — để traffic không đi ra Internet.

Hai bước này là yêu cầu bắt buộc của nhiều tổ chức khi tự host model, và chúng cũng ảnh hưởng tới thời gian tải: Gateway endpoint cho S3 miễn phí và nhanh, nên đáng bật trước khi triển khai model lớn.

Đáp án

A — Định nghĩa custom fairness metric trong CloudWatch theo dõi chỉ báo thiên lệch giữa các nhóm, Lambda tính metric cho mỗi đầu ra, và CloudWatch alarm cùng dashboard cảnh báo khi vượt ngưỡng, kèm workflow phân tích hồi quy tự động.

Vì sao đúng

Đề nêu ba yêu cầu, và chúng cùng chỉ về một kiến trúc đo lường liên tục:

1. Chỉ số công bằng ĐO ĐƯỢC
2. Cảnh báo TỰ ĐỘNG khi vượt ngưỡng thoả thuận
3. Đánh giá liên tục giữa các nhóm được bảo vệ, phát hiện hồi quy

Đáp án A dựng đúng vòng lặp đó:

Model sinh đầu ra
      ↓
Lambda tính chỉ số công bằng cho từng nhóm
      ↓
CloudWatch custom metric (có dimension theo nhóm)
      ↓
CloudWatch alarm khi vượt ngưỡng
      ↓
Workflow phân tích hồi quy tự động

Điểm mấu chốt là dùng dimension để tách metric theo từng nhóm — nhờ đó bạn so sánh được giữa các nhóm, chứ không chỉ nhìn con số tổng:

cloudwatch.put_metric_data(
    Namespace='GenAI/CongBang',
    MetricData=[
        {'MetricName': 'DoDaiPhanHoi', 'Value': do_dai,
         'Dimensions': [{'Name': 'NhomNgonNgu', 'Value': nhom}]},
        {'MetricName': 'DiemTichCuc', 'Value': diem_tone,
         'Dimensions': [{'Name': 'NhomNgonNgu', 'Value': nhom}]},
        {'MetricName': 'TyLeTuChoi', 'Value': ty_le,
         'Dimensions': [{'Name': 'NhomNgonNgu', 'Value': nhom}]}
    ])

Và metric math cho phép đặt alarm trực tiếp lên khoảng cách giữa các nhóm — đúng định nghĩa của thiên lệch:

{
  "Id": "chenh_lech",
  "Expression": "ABS(nhom_a - nhom_b) / ((nhom_a + nhom_b) / 2) * 100",
  "Label": "Chênh lệch giữa hai nhóm (%)"
}

Vế "trigger automated workflows for regression analysis" cũng quan trọng: nó biến cảnh báo thành hành động — thu thập mẫu, so sánh với đường cơ sở, xác định thay đổi nào (prompt mới, model mới) gây ra hồi quy.

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

• B. CloudWatch metric lưu điểm sentiment và tone TỔNG HỢP, alarm khi xu hướng chung thay đổi — mất chính thông tin cần thiết: thiên lệch là sự KHÁC BIỆT giữa các nhóm, nhưng số liệu tổng hợp che giấu khác biệt đó. Một nhóm bị đối xử tệ và một nhóm được ưu ái có thể cho trung bình hoàn toàn bình thường.
• C. Dùng Guardrails chặn nội dung có ngôn ngữ nhạy cảm về nhân khẩu, đếm số lần bị chặn làm chỉ báo công bằng — nhầm hai khái niệm: Guardrails chặn ngôn ngữ độc hại, còn thiên lệch ở đây là sự khác biệt về tông giọng, nội dung và ví dụ giữa các nhóm — thứ hoàn toàn có thể xảy ra mà không có từ ngữ nhạy cảm nào. Số lần bị chặn không đo được điều đó.
• D. Step Functions lấy mẫu định kỳ, lưu vào CloudWatch Logs cho người xem thủ công; alarm dựa trên thay đổi khối lượng log — không có chỉ số công bằng nào: alarm trên khối lượng log chỉ cho biết hệ thống bận hơn hay rảnh hơn. Và "depend on manual inspection" trái yêu cầu tự động.

Ghi nhớ

Các chỉ số công bằng thường dùng cho đầu ra sinh ngữ: | Chỉ số | Đo gì | |---|---| | Chênh lệch tông giọng | điểm sentiment khác nhau giữa các nhóm | | Chênh lệch độ dài phản hồi | nhóm nào được trả lời chi tiết hơn | | Tỷ lệ từ chối | nhóm nào bị từ chối trả lời nhiều hơn | | Đa dạng ví dụ | ví dụ đưa ra có thiên về một nhóm không | | Demographic parity | tỷ lệ kết quả tích cực giữa các nhóm |

Nguyên tắc quan trọng nhất rút ra từ câu này: thiên lệch là chỉ số SO SÁNH, không phải chỉ số tuyệt đối. Mọi cách đo gộp các nhóm lại đều mất khả năng phát hiện.

Ba công cụ AWS liên quan tới đánh giá model: | Công cụ | Việc | |---|---| | CloudWatch custom metric + alarm | giám sát liên tục lúc chạy ← câu này | | Bedrock Model Evaluation | đánh giá theo lô: tự động hoặc bằng người | | SageMaker Clarify | phát hiện thiên lệch trong dữ liệu và model ML truyền thống |

Bedrock Model Evaluation đáng dùng bổ sung: nó chạy bộ dữ liệu đánh giá và chấm điểm theo nhiều chiều, kể cả có người tham gia chấm — hợp cho việc kiểm tra trước khi phát hành, trong khi CloudWatch lo giám sát sau khi phát hành.

Và ba lưu ý khi triển khai:

1. Xác định "nhóm được bảo vệ" cẩn thận — với ứng dụng đa ngôn ngữ như đề mô tả, ngôn ngữ là một chiều; nhưng đừng suy đoán nhân khẩu học từ dữ liệu không được phép dùng.
2. Đặt đường cơ sở trước — không có baseline thì không biết thế nào là "hồi quy".
3. Cẩn thận với chi phí dimension: mỗi tổ hợp dimension là một custom metric riêng và một khoản phí riêng — nên giới hạn số nhóm ở mức có ý nghĩa thống kê.

Đáp án

A — Cấu hình Bedrock cross-Region inference để request tự động định tuyến sang Region khác khi Region chính không khả dụng hoặc quá tải; gọi model qua regional endpoint và để Bedrock tự lo failover lúc chạy.

Vì sao đúng

Đề đưa ra một ràng buộc rất rõ ràng: giải pháp không được dựa vào cấp thừa hoặc giữ sẵn năng lực dư.

Điều đó loại ngay mọi phương án dựa trên provisioned throughput, và chỉ để lại cross-Region inference — tính năng dựng sẵn của Bedrock cho đúng bài toán này:

# Chỉ cần đổi modelId sang inference profile ID
bedrock.converse(
    modelId='us.anthropic.claude-3-5-sonnet-20241022-v2:0',   # tiền tố "us." = cross-Region
    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 khớp đúng với đề: đỉnh tải theo giờ ở các khu vực khác nhau — khi châu Á cao điểm thì châu Âu đang rảnh, và cross-Region inference tận dụng được điều đó.

Và giám sát bằng CloudWatch trong đáp án cũng cần thiết: bạn theo dõi độ trễ và tỷ lệ lỗi để xác nhận cơ chế thật sự hoạt động trong các cửa sổ cao điểm.

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

• B. Tăng provisioned throughput ở Region chính để hấp thụ đỉnh, kèm alarm và auto scaling — vi phạm thẳng ràng buộc "should not rely on overprovisioning or permanently reserving excess capacity". Provisioned Throughput chính là cam kết trả tiền cho năng lực giữ sẵn, kể cả lúc không dùng.
• C. Dùng cross-Region inference nhưng khai cứng Region dự phòng trong mã, tự viết logic thử lại bằng Lambda — tự dựng lại thứ Bedrock làm sẵn: bạn phải bảo trì cấu hình cho từng khu vực, tự xử lý thử lại, và mỗi lần chuyển Region đều tốn một lần gọi thất bại trước đó. Trái tinh thần "handle failover transparently".
• D. Triển khai model ở nhiều Region, dùng Route 53 latency-based routing, và scale provisioned throughput đều ở mỗi Region — vi phạm ràng buộc chi phí (provisioned ở mọi Region là cấp thừa nhân lên nhiều lần), và Route 53 failover phụ thuộc DNS TTL nên chậm hơn nhiều so với failover ở tầng dịch vụ.

Ghi nhớ

Ba chế độ tính năng lực của Bedrock: | Chế độ | Đặc điểm | |---|---| | On-demand | trả theo token, không cam kết — mặc định | | Cross-Region inference | on-demand + tự phân phối qua nhiều Region | | Provisioned Throughput | giữ sẵn năng lực, cam kết theo giờ hoặc tháng |

Cách chọn: | Đề nói | Chọn | |---|---| | "không cấp thừa", "chi phí dự đoán được và thấp", "chịu được sự cố Region" | cross-Region inference | | "đảm bảo thông lượng tối thiểu", "độ trễ ổn định tuyệt đối" | Provisioned Throughput | | Tải thấp, thất thường | on-demand thường |

Vài đặc điểm của cross-Region inference cần biết: | Điểm | Chi tiết | |---|---| | Nhóm Region | us.*, eu.*, apac.* — dữ liệu ở lại trong nhóm địa lý đó | | Không thêm phí | tính theo giá của Region nguồn | | Không phải mọi model đều hỗ trợ | kiểm tra danh sách inference profile | | Tuân thủ dữ liệu | cần cân nhắc: 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ỹ: với dữ liệu chịu ràng buộc chủ quyền, hãy xác nhận rằng mọi Region trong nhóm đều được phép trước khi bật.

Và hai chỉ số nên đặt alarm khi vận hành: | Metric | Ý nghĩa | |---|---| | InvocationClientErrors / InvocationServerErrors | tỷ lệ lỗi theo Region | | InvocationLatency | độ trễ p99 — tăng đột ngột có thể là dấu hiệu đang failover |

Cả hai đều có sẵn trong namespace AWS/Bedrock, tách theo ModelId.

Đáp án

D và E.

• D — Điều chỉnh và cân bằng lại shard của OpenSearch để dữ liệu vector và tải truy vấn phân bố đều; dùng dashboard theo dõi hot shard và reindex khi cần
• E — Tinh chỉnh tham số HNSW (efSearch, efConstruction, M) để cân bằng recall và độ trễ; kiểm chứng bằng Trace Analytics và metric ở mức truy vấn

Vì sao đúng

Đề nêu hai vấn đề riêng biệt, và mỗi đáp án giải quyết một cái: | Vấn đề trong đề | Nguyên nhân | Đáp án | |---|---|---| | Một số shard nhận tải truy vấn nặng bất thường | phân bố shard không đều | D | | Kết quả không liên quan cho truy vấn giàu ngữ nghĩa | tham số ANN chưa tinh chỉnh | E |

D — hot shard là vấn đề phân bố. Khi dữ liệu hoặc tải dồn vào vài shard, chúng trở thành nút thắt trong khi các shard khác nhàn rỗi:

shard 0: 8 triệu vector, 70% truy vấn  ← nghẽn
shard 1: 1 triệu vector, 15% truy vấn
shard 2: 1 triệu vector, 15% truy vấn

Cách chữa là reindex với số shard phù hợp và định tuyến đều:

PUT /bai-viet-v2
{
  "settings": {
    "index.number_of_shards": 12,
    "index.number_of_replicas": 2,
    "index.knn": true
  }
}

E — tham số HNSW quyết định đánh đổi giữa độ chính xác và tốc độ. Đây là chỗ giải thích vì sao kết quả "không liên quan": | Tham số | Ảnh hưởng | |---|---| | ef_search | số ứng viên xét lúc TRUY VẤN — cao thì recall tốt hơn, chậm hơn | | ef_construction | chất lượng đồ thị lúc XÂY INDEX — cao thì index tốt hơn, xây lâu hơn | | m | số kết nối mỗi node — cao thì recall tốt hơn, tốn bộ nhớ hơn |

"method": {
  "name": "hnsw", "engine": "faiss", "space_type": "cosinesimil",
  "parameters": {"ef_construction": 512, "m": 32}
}

Điểm mấu chốt: HNSW là thuật toán XẤP XỈ (ANN) — nó cố ý không tìm kiếm toàn bộ để đổi lấy tốc độ. ef_search quá thấp nghĩa là nó bỏ sót láng giềng gần thật sự và trả về kết quả kém liên quan — chính xác triệu chứng đề mô tả.

Và Trace Analytics cùng metric ở mức truy vấn là cách kiểm chứng đúng: nó cho thấy độ trễ của từng truy vấn, không phải con số trung bình của cả cụm.

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

• A. Chuyển sang HNSW nhưng giữ nguyên số shard và tham số ANN mặc định; chỉ xem metric ở mức cụm — không sửa cả hai vấn đề: giữ nguyên shard thì hot shard vẫn còn, giữ tham số mặc định thì recall vẫn kém. Và metric ở mức cụm che giấu hot shard — đó là lý do đề nói phải "examine query level latencies".
• B. Tăng top_k cho mọi truy vấn rồi đưa danh sách lớn hơn sang Bedrock rerank; auto scaling chỉ dựa trên CPU — reranking hữu ích, nhưng tăng top_k làm tải nặng thêm trên các shard vốn đã quá tải. Và auto scaling theo CPU không phát hiện được hot shard — cụm có thể có CPU trung bình thấp trong khi một shard đang nghẽn.
• C. Gộp index vào MỘT node bộ nhớ lớn; dùng S3 snapshot làm cách đảm bảo hành vi truy xuất nhất quán — đi ngược hoàn toàn: một node là điểm hỏng đơn lẻ và không mở rộng được với hàng chục triệu vector. Và snapshot là cơ chế SAO LƯU, không liên quan gì tới tính nhất quán của kết quả truy xuất.

Ghi nhớ

Ba thuật toán tìm kiếm vector trong OpenSearch: | Thuật toán | Đặc điểm | |---|---| | HNSW | nhanh, recall cao, tốn bộ nhớ — phổ biến nhất | | IVF | tốn ít bộ nhớ hơn, cần huấn luyện trước | | Exact k-NN (script score) | chính xác 100% nhưng rất chậm — chỉ dùng với tập nhỏ |

Bảng tinh chỉnh HNSW — đánh đổi cần nhớ: | Muốn | Điều chỉnh | |---|---| | Recall cao hơn | tăng ef_search, ef_construction, m | | Độ trễ thấp hơn | giảm ef_search | | Tốn ít bộ nhớ hơn | giảm m, hoặc chuyển sang IVF, hoặc dùng quantization |

ef_search là tham số điều chỉnh được lúc truy vấn mà không cần reindex — nên nó là chỗ nên thử đầu tiên.

Danh sách kiểm khi vector search chậm dần theo quy mô: | Bước | Kiểm tra | |---|---| | 1 | Có hot shard không? — dashboard, metric theo shard | | 2 | ef_search có đủ cao không? — thử tăng rồi đo recall | | 3 | Dữ liệu có vượt bộ nhớ node không? — HNSW cần index nằm trong RAM | | 4 | top_k có quá lớn không? | | | 5 | Có cần quantization không (giảm bộ nhớ 4–32 lần)? |

Bước 3 đáng chú ý ở quy mô hàng chục triệu vector: HNSW yêu cầu toàn bộ đồ thị nằm trong bộ nhớ. Vượt quá là hiệu năng sụp đổ — và khi đó product quantization hoặc disk-based vector engine là hướng đi tiếp theo.

Và với chất lượng kết quả, nhớ rằng tinh chỉnh ANN chỉ giải quyết recall của tầng truy xuất — muốn precision ở trang đầu thì cần thêm reranking, như đã bàn ở các câu khác.

Đáp án

A — Lưu thuộc tính tài liệu (ngày tạo, tác giả, lĩnh vực) làm S3 object metadata và object tag lúc tải lên; dùng S3 Metadata với bảng inventory truy vấn được bằng SQL để lọc trước, rồi mới lấy nội dung đưa vào ngữ cảnh cho model.

Vì sao đúng

Đề mô tả câu hỏi có ràng buộc theo thuộc tính, không phải theo ngữ nghĩa:

"Chính sách mới nhất do đội X viết"          → lọc theo tác giả + sắp xếp theo ngày
"Tài liệu được duyệt trong quý II"           → lọc theo khoảng thời gian

Đây là truy vấn có cấu trúc, và vector search không phải công cụ đúng cho nó — embedding mã hoá ý nghĩa văn bản, không mã hoá được "mới nhất" hay "thuộc đội nào".

S3 Metadata là tính năng cho phép truy vấn thuộc tính object bằng SQL, ở quy mô hàng triệu object:

SELECT bucket, key, last_modified_date
FROM s3_metadata_table
WHERE object_tags['tac_gia'] = 'doi-phap-che'
  AND object_tags['linh_vuc'] = 'chinh-sach'
  AND last_modified_date >= '2026-04-01'
ORDER BY last_modified_date DESC
LIMIT 10;

Quy trình hai bước:

① Lọc bằng SQL trên metadata  → thu hẹp từ hàng triệu xuống vài chục object
② Lấy nội dung của những object đó → đưa vào ngữ cảnh cho model

Và điều này giải quyết đúng cả hai vấn đề đề nêu: | Vấn đề | Cách giải quyết | |---|---| | "scans content extensively" | lọc bằng metadata, không quét nội dung | | "struggles as dataset grows" | SQL trên bảng inventory mở rộng tới hàng triệu object |

Gắn thuộc tính lúc tải lên:

aws s3api put-object --bucket kho-tai-lieu --key chinh-sach/2026-q2.pdf \
  --body chinh-sach.pdf \
  --metadata 'tac-gia=doi-phap-che,ngay-duyet=2026-04-15' \
  --tagging 'linh_vuc=chinh-sach&trang_thai=hieu-luc'

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

• C. Lưu metadata và tag, đồng thời tạo embedding, index cả hai vào OpenSearch, rerank, và duy trì workflow reindex định kỳ — đây là phương án gần nhất và hoàn toàn hợp lệ về kỹ thuật. Nhưng nó phức tạp hơn nhiều cho bài toán đề nêu: câu hỏi trong đề là lọc theo thuộc tính, không phải tìm kiếm ngữ nghĩa. Thêm tầng embedding, index và reindex định kỳ là chi phí và độ phức tạp không cần thiết — trái yêu cầu ngầm về hiệu quả vận hành.
• B. Mã hoá timestamp và tác giả vào chính đầu vào của embedding, chỉ dùng similarity search — không hoạt động: embedding không biểu diễn được quan hệ thứ tự. Hai tài liệu cách nhau một ngày và cách nhau một năm cho vector gần như nhau. Không lọc được khoảng thời gian.
• D. Nhét thuộc tính vào nội dung tài liệu rồi dùng full-text search quét toàn bộ; tăng shard và replica — chính là vấn đề hiện tại: "scans content extensively". Tăng shard chỉ làm việc quét nhanh hơn một chút, không loại bỏ việc quét.

Ghi nhớ

Ba cách lưu thuộc tính cho object S3: | Cách | Đặc điểm | |---|---| | Object metadata (x-amz-meta-*) | đặt lúc tải lên, bất biến (đổi phải copy lại) | | Object tag | sửa được sau, dùng cho IAM condition và lifecycle rule | | S3 Metadata table | bảng inventory truy vấn bằng SQL, tự cập nhật |

Dòng thứ hai đáng chú ý: object tag dùng được trong IAM policy condition — nên bạn phân quyền theo thuộc tính được:

"Condition": {"StringEquals": {"s3:ExistingObjectTag/linh_vuc": "cong-khai"}}

Nguyên tắc thiết kế quan trọng nhất rút ra từ câu này: dùng đúng công cụ cho đúng loại truy vấn. | Loại câu hỏi | Công cụ | |---|---| | "Tài liệu nào nói về X?" (ngữ nghĩa) | vector search | | "Tài liệu nào của đội Y, sau ngày Z?" (thuộc tính) | metadata filter / SQL | | Cả hai | hybrid: lọc metadata TRƯỚC, rồi vector search trong tập đã lọc |

Dòng cuối là mẫu tốt nhất cho hệ thống RAG lớn — và thứ tự rất quan trọng: lọc trước rồi mới tìm ngữ nghĩa giúp giảm không gian tìm kiếm và tăng cả tốc độ lẫn độ chính xác.

Ba giới hạn của S3 metadata cần biết: | Giới hạn | Giá trị | |---|---| | Kích thước metadata | 2 KB tổng | | Số object tag | 10 tag mỗi object | | Object metadata sau khi tạo | bất biến — phải copy object để đổi |

Và với dữ liệu cần đổi thuộc tính thường xuyên, object tag là lựa chọn đúng vì nó sửa được mà không phải ghi lại object.

Đáp án

C — Dùng AWS AppConfig lưu lựa chọn model và provider thành configuration profile theo từng môi trường; triển khai qua MỘT CodePipeline duy nhất đẩy cùng một artifact qua các môi trường, trong khi AppConfig phân giải giá trị theo môi trường lúc chạy; áp dụng validation và deployment strategy để kiểm soát rollout và rollback.

Vì sao đúng

Đề nêu bốn yêu cầu, và AppConfig kết hợp với một pipeline duy nhất đáp ứng cả bốn:

1. Đổi model và provider an toàn, nhất quán giữa các môi trường
2. Giữ nguyên mã ứng dụng
3. Giá trị theo môi trường nạp tự động, KHÔNG cần logic rẽ nhánh
4. Một quy trình duy nhất để đề bạt, kiểm toán và rollback

Cấu trúc phân cấp của AppConfig khớp đúng nhu cầu này:

Application: "tro-ly-genai"
├── Environment: "dev"        → profile trả về: {"model": "nova-micro"}
├── Environment: "staging"    → profile trả về: {"model": "claude-haiku"}
└── Environment: "production" → profile trả về: {"model": "claude-sonnet"}

Ứng dụng chỉ hỏi AppConfig "cấu hình của môi trường tôi đang chạy là gì" — không có if môi_trường == "prod" nào trong mã:

cau_hinh = json.loads(lay_cau_hinh(
    application='tro-ly-genai',
    environment=os.environ['MOI_TRUONG'],      # do hạ tầng đặt
    profile='lua-chon-model'
))
model_id = cau_hinh['model']

Đó chính là nghĩa của "without branching logic" trong đề.

Và vế thứ tư — một pipeline duy nhất — là điểm phân biệt quan trọng:

CodePipeline: build MỘT artifact
    ↓ deploy vào dev      → AppConfig trả giá trị dev
    ↓ deploy vào staging  → AppConfig trả giá trị staging
    ↓ deploy vào prod     → AppConfig trả giá trị prod

Cùng một artifact đi qua mọi môi trường — nên thứ bạn kiểm thử ở staging chính xác là thứ chạy ở production, chỉ khác cấu hình.

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

• D. AppConfig với application và environment riêng cho từng giai đoạn, cùng pipeline độc lập cho mỗi môi trường, đề bạt thủ công — đây là phương án gần nhất, và nó sai ở vế cuối của đề: "streamline how configuration changes are promoted using a SINGLE delivery workflow". Nhiều pipeline độc lập kèm điều phối thủ công là đúng thứ đề muốn tránh, và nó dễ gây lệch giữa các môi trường.
• A. Parameter Store, nạp lúc khởi động, cần khởi động lại dịch vụ để áp dụng thay đổi, phân biệt môi trường bằng quy ước đặt tên — hai vấn đề. Thứ nhất, "require service restarts" trái yêu cầu thay đổi an toàn và nhanh. Thứ hai, Parameter Store không có deployment strategy, validation, hay automatic rollback.
• B. Pipeline riêng cho dev và production, mỗi pipeline nướng tệp cấu hình khác nhau vào artifact — artifact khác nhau giữa các môi trường, nên thứ kiểm thử không phải thứ triển khai. Và mỗi lần đổi model đều phải sửa định nghĩa pipeline — trái yêu cầu "keeping application code unchanged" theo tinh thần.

Ghi nhớ

So sánh các dịch vụ lưu cấu hình: | | AppConfig | Parameter Store | Secrets Manager | |---|---|---|---| | Đổi không cần restart | ✅ (poll hoặc extension) | ✅ nếu ứng dụng tự đọc lại | ✅ | | Gradual rollout | ✅ | ❌ | ❌ | | Validation trước khi phát hành | ✅ JSON Schema hoặc Lambda | ❌ | ❌ | | Automatic rollback | ✅ theo CloudWatch alarm | ❌ | ❌ | | Môi trường riêng biệt | ✅ dựng sẵn | quy ước đặt tên | quy ước đặt tên | | Chi phí | thấp | standard miễn phí | ~0,40 USD/secret |

Cách chọn: | Nhu cầu | Chọn | |---|---| | Cấu hình động, nhiều môi trường, cần rollout an toàn | AppConfig | | Cấu hình tĩnh, đơn giản | Parameter Store | | Bí mật cần xoay vòng | Secrets Manager |

Bốn thành phần của AppConfig: | Thành phần | Việc | |---|---| | Application | nhóm logic (một ứng dụng) | | Environment | dev, staging, production | | Configuration profile | nguồn cấu hình + validator | | Deployment strategy | tỷ lệ rollout, bake time |

Và validator là tính năng đáng dùng nhất cho tình huống này — nó chặn cấu hình sai trước khi phát hành:

{
  "type": "object",
  "required": ["model", "provider"],
  "properties": {
    "model": {"type": "string", "enum": ["nova-micro", "claude-haiku", "claude-sonnet"]},
    "temperature": {"type": "number", "minimum": 0, "maximum": 1}
  }
}

Với enum, một model ID gõ sai không bao giờ tới được production.

Ba lưu ý khi triển khai:

1. Dùng AppConfig Lambda Extension — nó cache cấu hình cục bộ, nên không tốn một lời gọi API ở mỗi lần chạy hàm.
2. Đặt CloudWatch alarm làm điều kiện rollback — ví dụ tỷ lệ lỗi hoặc độ trễ p99 của model mới.
3. Bake time đủ dài để alarm kịp phát hiện vấn đề trước khi rollout hoàn tất.