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

Đáp án

A — Dựng Step Functions workflow gọi nhiều biến thể model SONG SONG, ghi điểm chất lượng và tín hiệu tương tác vào metrics store, và cập nhật trọng số định tuyến dựa trên kết quả đánh giá; dùng CloudWatch metric và alarm theo dõi hiệu năng từng biến thể và chuyển dần traffic sang cấu hình tốt nhất.

Vì sao đúng

Đề nêu bốn yêu cầu, và đáp án A đáp ứng cả bốn:

1. Chạy model A đối đầu model B
2. Ghi lại metric
3. Cập nhật cấu hình thử nghiệm
4. Phát hành dần biến thể tốt nhất

Đáp án A khép kín thành một vòng lặp tự động:

Step Functions
    ↓ Parallel state: gọi biến thể A và B cùng lúc
    ↓ Lambda: chấm điểm chất lượng
    ↓ Ghi vào metrics store (DynamoDB) + CloudWatch
    ↓ Lambda: tính lại trọng số định tuyến
    ↓ Cập nhật cấu hình → biến thể tốt hơn nhận nhiều traffic hơn
    └──────────── lặp lại ────────────┘

Parallel state là công cụ đúng cho việc so sánh:

{
  "SoSanhBienThe": {
    "Type": "Parallel",
    "Branches": [
      {"StartAt": "BienTheA", "States": {"BienTheA": {
        "Type": "Task", "Resource": "arn:aws:states:::bedrock:invokeModel",
        "Parameters": {"ModelId": "anthropic.claude-3-5-haiku-20241022-v1:0"}, "End": true}}},
      {"StartAt": "BienTheB", "States": {"BienTheB": {
        "Type": "Task", "Resource": "arn:aws:states:::bedrock:invokeModel",
        "Parameters": {"ModelId": "amazon.nova-pro-v1:0"}, "End": true}}}
    ],
    "Next": "ChamDiem"
  }
}

Điểm mấu chốt phân biệt A với B: "updates routing weights based on evaluation results" — trọng số được cập nhật tự động từ dữ liệu, không phải chờ người đọc log rồi sửa tay.

Và "gradually shift traffic" đáp ứng yêu cầu phát hành có kiểm soát — không chuyển 100% ngay khi thấy một biến thể nhỉnh hơn.

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

• B. Step Functions gọi song song nhiều biến thể nhưng trọng số định tuyến TĨNH trong biến môi trường; một bước đọc log rồi thông báo cho product manager tự cập nhật cấu hình thủ công — đây là phương án gần nhất và chỉ sai ở vòng lặp cuối: con người là mắt xích trong vòng phản hồi, nên nó không tự động và trọng số trong biến môi trường đòi triển khai lại. Đề yêu cầu "automated evaluation and controlled rollout".
• C. SageMaker Pipeline chỉ huấn luyện và đăng ký MỘT model mỗi lần, triển khai thẳng vào production không chia traffic; thử nghiệm offline trong notebook, chọn thủ công — không có A/B testing nào: một model mỗi lần, không chia traffic, và thử nghiệm offline không đo được tương tác người dùng thật mà đề yêu cầu.
• D. SQS đẩy vào một fleet EC2, mỗi instance CHỌN NGẪU NHIÊN model và prompt, ghi log; product manager tải log về tính toán trong bảng tính — thô sơ nhất: chọn ngẫu nhiên không phải thử nghiệm có kiểm soát (không đảm bảo phân bổ đều), và "spreadsheets" là quy trình thủ công hoàn toàn.

Ghi nhớ

Bốn thành phần của một hệ thống thử nghiệm model tự động: | Thành phần | Việc | |---|---| | Chạy song song | Parallel state — cùng đầu vào, nhiều biến thể | | Chấm điểm | tự động (LLM-as-judge, metric) + tín hiệu người dùng | | Metrics store | DynamoDB hoặc CloudWatch — lưu để so sánh theo thời gian | | Vòng phản hồi | cập nhật trọng số tự động ← điểm phân biệt |

Ba loại tín hiệu chất lượng cho ứng dụng GenAI: | Loại | Ví dụ | |---|---| | Tự động | độ dài, tuân thủ schema, LLM-as-judge chấm điểm | | Tương tác người dùng | tỷ lệ bấm, thời gian đọc, tỷ lệ sửa lại | | Con người chấm | mẫu nhỏ, làm chuẩn để hiệu chỉnh hai loại trên |

Đề nhắc tới cả "automatic quality scores" và "user engagement metrics" — nên hệ thống phải thu thập cả hai.

Hai chiến lược phân bổ traffic trong thử nghiệm: | Chiến lược | Đặc điểm | |---|---| | A/B test cố định | chia đều, chạy đủ lâu để có ý nghĩa thống kê | | Multi-armed bandit | tự chuyển dần traffic sang biến thể tốt hơn TRONG lúc thử |

Đáp án A mô tả chiến lược thứ hai — nó giảm chi phí cơ hội (ít người dùng phải chịu biến thể kém hơn) nhưng cần cẩn thận để không kết luận sớm khi dữ liệu còn ít.

Và hai công cụ AWS bổ trợ đáng biết: | Công cụ | Việc | |---|---| | Bedrock Model Evaluation | đánh giá theo lô, có bộ metric dựng sẵn và tuỳ chọn người chấm | | CloudWatch Evidently | quản lý feature launch và A/B test, có phân tích thống kê |

Evidently đặc biệt hợp với vế "gradually roll out" — nó tính sẵn ý nghĩa thống kê và tự động dừng thử nghiệm khi có kết luận.

Đáp án

D — Tạo tầng định tuyến kiểm tra từng request và chuyển hướng tới Bedrock hoặc SageMaker endpoint dựa trên loại tác vụ, yêu cầu độ trễ, và ràng buộc chi phí; tích hợp IAM, kết nối VPC, và CloudWatch logging để mọi lời gọi model đều được bảo mật và giám sát trên cả hai backend.

Vì sao đúng

Đề nêu bốn yêu cầu, và đáp án D là lựa chọn duy nhất thoả hết:

1. MỘT tầng API duy nhất cho cả hai loại backend
2. Định tuyến theo loại tác vụ, độ trễ, chi phí
3. Bảo mật — dữ liệu tài chính, có ràng buộc tuân thủ
4. Quan sát được — giám sát thống nhất

Router pattern là kiến trúc chuẩn cho triển khai lai:

Client → API Gateway → Lambda (router)
                          ├─ tóm tắt, sinh mã     → Bedrock (managed FM)
                          └─ phân loại tài liệu   → SageMaker (model fine-tuned,
                                                     yêu cầu tuân thủ)

def dinh_tuyen(request):
    loai = request['loaiTacVu']
    if loai in ('tom-tat', 'sinh-ma'):
        return bedrock.converse(modelId=CAU_HINH[loai], messages=request['messages'])
    else:
        return sagemaker_runtime.invoke_endpoint(
            EndpointName=CAU_HINH[loai], Body=json.dumps(request))

Và ba yếu tố ở vế sau của đáp án là điểm phân biệt quan trọng: | Yếu tố | Vì sao cần | |---|---| | IAM | quyền riêng cho từng backend, đặc quyền tối thiểu | | VPC connectivity | SageMaker endpoint riêng tư; Bedrock qua VPC endpoint — dữ liệu tài chính không ra Internet | | CloudWatch logging thống nhất | một chỗ để giám sát cả hai backend |

Vế cuối đặc biệt quan trọng với ngành tài chính: nếu mỗi backend có hệ thống log riêng, bạn không dựng được bức tranh đầy đủ cho kiểm toán.

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

• A. Phơi API RIÊNG cho Bedrock và SageMaker, để các đội ứng dụng tự chọn backend; dùng VPC networking chuẩn không có giám sát thống nhất — vi phạm yêu cầu "a single API layer", và "without unified monitoring" trái thẳng yêu cầu quan sát được. Nó cũng đẩy quyết định định tuyến sang từng đội — mỗi đội làm một kiểu.
• B. Dùng Bedrock làm giao diện chính, chỉ gọi SageMaker khi Bedrock thất bại hoặc trả kết quả kém; dựa vào retry của ứng dụng để định tuyến — sai bản chất vấn đề: đề nói một số workload BẮT BUỘC chạy trên SageMaker vì lý do tuân thủ, không phải vì Bedrock hỏng. Dùng Bedrock trước cho những workload đó là vi phạm tuân thủ ngay từ lần gọi đầu.
• C. Host tất cả model — kể cả model bên thứ ba — trên SageMaker multi-model endpoint; ứng dụng tự khai tên model — không khả thi: model của Anthropic, Meta, Cohere trên Bedrock không tải về tự host được. Và multi-model endpoint dành cho nhiều model nhỏ dùng chung tài nguyên, không hợp với foundation model lớn.

Ghi nhớ

So sánh hai nền tảng suy luận của AWS: | | Amazon Bedrock | SageMaker AI | |---|---|---| | Model | foundation model được quản lý | model của bạn, tự tuỳ biến | | Hạ tầng | serverless, không quản lý gì | endpoint, instance, auto scaling | | Tính tiền | theo token | theo instance-giờ | | Tuỳ biến | fine-tune có giới hạn | toàn quyền | | Dùng khi | tác vụ chung, muốn nhanh | cần kiểm soát, tuân thủ, model riêng |

Chúng bổ sung cho nhau, và kiến trúc lai là lựa chọn phổ biến trong doanh nghiệp — đúng như đề mô tả.

Bốn tiêu chí định tuyến thường dùng: | Tiêu chí | Ví dụ | |---|---| | Loại tác vụ | tóm tắt → Bedrock; phân loại chuyên ngành → SageMaker | | Yêu cầu độ trễ | cần dưới 200 ms → endpoint đã ấm | | Ràng buộc chi phí | tác vụ khối lượng lớn → model rẻ | | Tuân thủ | dữ liệu nhạy cảm → model tự host trong VPC |

Ba lớp bảo mật cho kiến trúc lai: | Lớp | Cấu hình | |---|---| | Danh tính | IAM role riêng cho router, quyền tối thiểu cho từng backend | | Mạng | VPC endpoint cho Bedrock; SageMaker endpoint trong private subnet | | Dữ liệu | mã hoá KMS, không ghi prompt chứa dữ liệu nhạy cảm vào log |

Và ba chỉ số nên giám sát chung cho cả hai backend: | Chỉ số | Ý nghĩa | |---|---| | Độ trễ theo backend và theo loại tác vụ | phát hiện định tuyến sai | | Chi phí theo loại tác vụ | kiểm chứng giả định về chi phí | | Tỷ lệ lỗi theo backend | biết khi nào cần fallback |

Nơi lưu quy tắc định tuyến nên là AppConfig — như đã bàn ở các câu khác, nó cho phép đổi quy tắc không cần triển khai lại, kèm rollout dần và rollback tự động.

Đáp án

B — Thiết kế Step Functions workflow luân phiên giữa một state SUY LUẬN (dùng foundation model) và một state HÀNH ĐỘNG (gọi API downstream), tức là cài đặt mẫu ReAct; cấu hình workflow LẶP chu kỳ suy luận–hành động cho tới khi model đưa ra quyết định cuối (duyệt hoặc chuyển chuyên viên).

Vì sao đúng

Đề mô tả chính xác mẫu ReAct (Reasoning + Acting):

"suy nghĩ qua logic chính sách TỪNG BƯỚC,
 gọi hệ thống đơn hàng nội bộ KHI CẦN,
 và LẶP LẠI chu kỳ này cho tới khi có quyết định rõ ràng"

Ba yếu tố đó — suy luận, hành động, lặp — là định nghĩa của ReAct.

Vì sao cần lặp: quyết định hoàn tiền không thể ra trong một bước vì thông tin cần thiết chỉ lộ dần:

Vòng 1: Suy luận → "Cần biết đơn hàng này giao khi nào"
        Hành động → gọi API đơn hàng
        Quan sát  → "Giao ngày 15/07, tức 45 ngày trước"

Vòng 2: Suy luận → "Quá 30 ngày. Cần kiểm tra có ngoại lệ cho hàng lỗi không"
        Hành động → gọi API khiếu nại
        Quan sát  → "Có khiếu nại hàng lỗi ngày 20/07"

Vòng 3: Suy luận → "Ngoại lệ áp dụng được, nhưng giá trị vượt hạn mức tự động"
        Kết luận  → chuyển chuyên viên

Không thể biết trước cần gọi API nào ở vòng 2 — nó phụ thuộc kết quả vòng 1. Đó là lý do một bước duy nhất không đủ.

Step Functions cài đặt vòng lặp này bằng Choice state quay ngược:

{
  "SuyLuan": {
    "Type": "Task",
    "Resource": "arn:aws:states:::bedrock:invokeModel",
    "Next": "KiemTraQuyetDinh"
  },
  "KiemTraQuyetDinh": {
    "Type": "Choice",
    "Choices": [
      {"Variable": "$.hanhDong", "StringEquals": "goi_api", "Next": "HanhDong"},
      {"Variable": "$.hanhDong", "StringEquals": "ket_luan", "Next": "HoanTat"}
    ],
    "Default": "ChuyenChuyenVien"
  },
  "HanhDong": {
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Next": "SuyLuan"                    ← QUAY LẠI, tạo vòng lặp
  }
}

Và Step Functions cho thêm hai thứ quan trọng với nghiệp vụ tài chính: vết thực thi đầy đủ cho kiểm toán, và giới hạn số vòng lặp để tránh chạy vô tận.

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

• **A. Một Bedrock Agent với nhiều action group xử lý cả suy luận lẫn gọi API trong một bước, dựa vào lập luận nội bộ không có vòng lặp suy luận–hành động được điều phối — đây là phương án đáng bàn nhất, vì Bedrock Agents THỰC SỰ cài đặt ReAct bên trong. Nhưng phương án tự loại mình bằng cụm "without an orchestrated reasoning action loop" — tức là mô tả một agent chạy một lượt. (Nếu phương án nói "Bedrock Agent với vòng lặp orchestration", nó sẽ là câu trả lời rất mạnh — và trong thực tế thường là lựa chọn ít công sức hơn Step Functions.)
• D. Step Functions với MỘT state duy nhất làm cả suy luận lẫn gọi API, chạy đúng một lần mỗi request không lặp — vi phạm thẳng yêu cầu "repeat this cycle until it reaches a clear decision".
• C. Dùng AWS Glue workflow điều phối, lưu kết quả trung gian vào S3, trigger từng giai đoạn tuần tự — sai công cụ hoàn toàn: Glue là dịch vụ ETL theo lô, thiết kế cho biến đổi dữ liệu. Nó không có state machine, không có rẽ nhánh theo điều kiện, không lặp được, và độ trễ tính bằng phút.

Ghi nhớ

Mẫu ReAct — vòng lặp ba bước:

Thought      → model suy luận: cần biết gì tiếp theo?
Action       → gọi công cụ hoặc API
Observation  → nhận kết quả
     └──────── lặp cho tới khi đủ thông tin ────────┘
Final Answer

Hai cách cài đặt ReAct trên AWS: | Cách | Đặc điểm | |---|---| | Bedrock Agents | ReAct dựng sẵn, ít công sức nhất, có tracing | | Step Functions | kiểm soát hoàn toàn, dễ kiểm toán, ghép được logic không phải LLM |

Cách chọn: | Nhu cầu | Chọn | |---|---| | Nhanh, ít mã, agent tự lập kế hoạch | Bedrock Agents | | Kiểm soát chặt từng bước, tuân thủ, ghép nhiều dịch vụ | Step Functions |

Với nghiệp vụ chịu quản lý như hoàn tiền tài chính, Step Functions thường được ưa chuộng vì mọi lần chuyển trạng thái đều được ghi lại — kiểm toán viên tái dựng được toàn bộ quyết định.

Ba biện pháp an toàn bắt buộc cho vòng lặp agent: | Biện pháp | Vì sao | |---|---| | Giới hạn số vòng lặp | tránh chạy vô tận và tốn token không kiểm soát | | Timeout tổng | giới hạn thời gian mỗi request | | Đường thoát ra người | khi vượt giới hạn thì chuyển chuyên viên, không tự quyết |

Đề đã nêu sẵn đường thoát đó: "escalated to a specialist" — và đó là thiết kế đúng cho mọi hệ thống tự động ra quyết định có hậu quả tài chính.

Và một mẫu liên quan đáng biết: human-in-the-loop với Step Functions dùng task token — workflow tạm dừng chờ người duyệt, rồi tiếp tục khi có phản hồi:

{"Type": "Task",
 "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
 "Parameters": {"Payload": {"taskToken.$": "$$.Task.Token"}}}

Đáp án

B — Dựng LLM-as-a-judge với rubric công bằng có cấu trúc, chấm qua Bedrock Prompt Flows, dùng ensemble nhiều model Bedrock, và hiệu chỉnh định kỳ với tập dữ liệu do người gán nhãn.

Vì sao đúng

Đề nêu ba yêu cầu, và đây là câu hỏi hiếm hoi mà cả ba đều nằm gọn trong một đáp án: | Yêu cầu | Cơ chế trong B | |---|---| | Đánh giá công bằng có hệ thống | rubric có cấu trúc + Prompt Flows | | Giảm thiên lệch của chính model chấm | ensemble nhiều model | | Giữ đồng thuận với người đánh giá | hiệu chỉnh với dữ liệu người gán nhãn |

Hai cơ chế cuối là điểm phân biệt, và cả hai đều xử lý một vấn đề thật:

Ensemble chống thiên lệch của judge. Một model chấm điểm cũng là một model — nó mang theo thiên lệch riêng từ dữ liệu huấn luyện. Dùng nhiều model khác nhau chấm cùng một đầu ra rồi lấy đồng thuận sẽ giảm ảnh hưởng của thiên lệch riêng lẻ:

diem = []
for model in ['anthropic.claude-3-5-sonnet-20241022-v2:0',
              'amazon.nova-pro-v1:0',
              'meta.llama3-1-70b-instruct-v1:0']:
    diem.append(cham_diem(model, dau_ra, rubric))
diem_cuoi = thong_ke_dong_thuan(diem)     # trung vị hoặc bỏ giá trị lệch

Hiệu chỉnh với nhãn của người. Đây là điều không thể bỏ: nếu không có neo là đánh giá của con người, bạn không biết judge đang chấm đúng hay chỉ chấm nhất quán. Đề nói rõ "periodic human spot checks" — chúng là dữ liệu hiệu chỉnh, không phải thủ tục hình thức.

Mẫu ngẫu nhiên → người gán nhãn → so với điểm của judge
     ↓
Lệch quá ngưỡng → sửa rubric, đổi model, hoặc chỉnh thang điểm

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

• D. LLM-as-a-judge với rubric và Prompt Flows nhưng MỘT model duy nhất, so với ngưỡng lịch sử thay vì hiệu chỉnh bằng nhãn người — đây là phương án gần nhất và thiếu đúng hai cơ chế then chốt. So với ngưỡng lịch sử chỉ đo được judge có nhất quán với chính nó không, và nếu judge lệch ngay từ đầu thì nó sẽ lệch một cách rất ổn định mà không ai biết.
• A. Một model duy nhất, dùng CloudWatch metric để kiểm chứng tính nhất quán của judge thay cho hiệu chỉnh bằng nhãn người — cùng lỗi như D và nói ra rõ hơn: nhất quán không phải là đúng.
• C. Dùng Guardrails chặn đầu ra có nhắc tới nhân khẩu học, coi số lần bị chặn là bằng chứng tuân thủ công bằng — nhầm hai khái niệm: Guardrails chặn ngôn ngữ nhạy cảm, còn thiên lệch là sự đối xử KHÁC NHAU giữa các nhóm — hoàn toàn có thể xảy ra mà không có từ nhạy cảm nào. Tệ hơn, chặn mọi nhắc tới nhân khẩu học sẽ cản trở cả nội dung hợp lệ.

Ghi nhớ

Bốn thành phần của một hệ thống LLM-as-a-judge đáng tin: | Thành phần | Vì sao cần | |---|---| | Rubric có cấu trúc | điểm số có nghĩa và tái lập được | | Ensemble nhiều model | giảm thiên lệch riêng của từng judge | | Hiệu chỉnh bằng nhãn người | neo vào chuẩn thật, không tự trôi | | Đầu ra có cấu trúc (JSON) | phân tích tự động được |

Ba thiên lệch đã biết của model chấm điểm: | Thiên lệch | Biểu hiện | |---|---| | Position bias | ưu ái đáp án xuất hiện trước | | Verbosity bias | chấm cao câu trả lời dài hơn | | Self-preference bias | ưu ái đầu ra của chính họ model đó |

Thiên lệch thứ ba là lý do trực tiếp để dùng ensemble nhiều nhà cung cấp model khác nhau, không chỉ nhiều phiên bản của cùng một họ.

Và ba cách giảm thiên lệch ở tầng thiết kế:

1. Đảo thứ tự khi so sánh hai đầu ra, chấm hai lần rồi lấy trung bình.
2. Che nguồn gốc — không cho judge biết đầu ra đến từ model nào.
3. Chấm theo từng tiêu chí riêng thay vì một điểm tổng — cụ thể hơn thì ít trôi hơn.

Đáp án

A — Step Functions điều phối việc sinh điều khoản và đưa sang Amazon Augmented AI (A2I) để luật sư xem xét; A2I gửi phản hồi có cấu trúc sang EventBridge bus; consumer phía sau ghi vào DynamoDB có secondary index để phân tích dài hạn; event pattern riêng cho duyệt, từ chối và yêu cầu sửa.

Vì sao đúng

Đề nêu bốn nhu cầu, và A là đáp án duy nhất phủ hết: | Nhu cầu | Cơ chế | |---|---| | Điều phối các bước soạn thảo tự động | Step Functions | | Định tuyến việc xem xét cho người | A2I — dịch vụ chuyên cho human review | | Kích hoạt xử lý phía sau | EventBridge | | Lưu dữ liệu có cấu trúc để phân tích dài hạn | DynamoDB + secondary index |

A2I là dịch vụ dựng riêng cho vòng lặp human-in-the-loop: nó quản lý hàng đợi công việc, giao diện cho người xem xét, và thu thập phản hồi có cấu trúc — thứ mà nếu tự dựng sẽ tốn rất nhiều công.

EventBridge ở giữa là quyết định kiến trúc quan trọng nhất. Nó tách người sinh sự kiện khỏi người tiêu thụ, nên bạn thêm hệ thống phía sau mà không đụng gì tới luồng chính:

{
  "source": ["a2i.review"],
  "detail-type": ["Ket qua xem xet dieu khoan"],
  "detail": {"ketQua": ["yeu-cau-sua"]}
}

Ba event pattern riêng cho ba loại kết quả nghĩa là mỗi loại có đường xử lý riêng — yêu cầu sửa quay lại vòng soạn thảo, còn duyệt thì đi tiếp.

Secondary index của DynamoDB đáp ứng vế phân tích: đề muốn tra theo loại sửa đổi, theo người xem xét, và theo xu hướng thời gian — mỗi chiều là một GSI:

PK: clauseId          GSI1: reviewerId + timestamp
                      GSI2: revisionCategory + timestamp

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

• B. Step Functions soạn thảo rồi gửi thẳng cho luật sư qua SNS, không dùng A2I; lưu phản hồi vào một prefix S3 rồi chạy Athena định kỳ — SNS chỉ gửi thông báo một chiều, nó không có cơ chế thu phản hồi. Bạn sẽ phải tự dựng toàn bộ giao diện xem xét, hàng đợi công việc và cách nhận kết quả.
• C. Bedrock Agents quản lý cả soạn thảo lẫn xem xét, A2I chỉ dùng để gửi email; mỗi bình luận là một object S3 riêng — dùng sai A2I (nó là hệ thống xem xét, không phải bộ gửi mail), và mỗi bình luận một object là cấu trúc tệ nhất cho phân tích xu hướng.
• D. A2I quản lý cả việc AI soạn thảo lẫn người xem xét, lưu phản hồi chỉ trong bucket đầu ra của A2I, xuất thủ công từ Console — A2I không sinh nội dung, nó chỉ lo phần con người. Và "manual exports from the console" trái yêu cầu phân tích dài hạn tự động.

Ghi nhớ

Amazon A2I — ba loại workflow: | Loại | Dùng khi | |---|---| | Tích hợp sẵn (Textract, Rekognition) | dịch vụ AWS có ngưỡng tin cậy thấp | | Tuỳ chỉnh | bất kỳ model nào, kể cả Bedrock ← câu này | | Lấy mẫu ngẫu nhiên | kiểm tra chất lượng định kỳ |

Ba lựa chọn lực lượng xem xét: | Lực lượng | Dùng khi | |---|---| | Private workforce | nhân viên nội bộ — bắt buộc với dữ liệu bảo mật ← luật sư của hãng | | Vendor workforce | nhà cung cấp đã kiểm định | | Mechanical Turk | dữ liệu công khai, khối lượng lớn |

Mẫu kiến trúc chuẩn cho human-in-the-loop:

Step Functions (điều phối)
    ↓ .waitForTaskToken
A2I (hàng đợi + giao diện xem xét)
    ↓ kết quả
EventBridge (định tuyến theo loại kết quả)
    ↓
DynamoDB (phân tích) + quay lại workflow (nếu cần sửa)

Điểm đáng nhớ: .waitForTaskToken cho phép Step Functions tạm dừng chờ người, có thể hàng giờ hoặc hàng ngày, rồi tiếp tục khi có phản hồi — đúng nhịp làm việc của luật sư.

(Ghi chú: đề gốc viết nhầm "Amazon Amazon Augmented AI" ở hai phương án — lỗi đánh máy của nguồn, không ảnh hưởng nội dung.)

Đáp án

B — Step Functions với điều kiện dừng tường minh và timeout ở từng state, timeout chặt cho Lambda, IAM đặc quyền tối thiểu, và circuit breaker bằng CloudWatch alarm dừng workflow khi vượt ngưỡng lỗi; dừng ngay lập tức nếu hệ thống phía sau hỏng hoặc phản hồi không đáng tin.

Vì sao đúng

Đề nêu ba nỗi lo, và mỗi cái cần một cơ chế riêng: | Nỗi lo | Cơ chế trong B | |---|---| | Vòng suy luận lặp lại vô tận | điều kiện dừng tường minh | | Chạy lâu hơn dự kiến | timeout ở state và ở Lambda | | Hỏng dây chuyền khi hệ thống phụ trợ mất | circuit breaker + dừng ngay |

Circuit breaker là điểm phân biệt quan trọng nhất. Không có nó, mọi request đều thử gọi hệ thống đang hỏng, chờ hết timeout, rồi thử lại — làm cạn tài nguyên và kéo sập cả những phần đang khoẻ:

Không có circuit breaker:
  1000 request × 3 lần thử × 30 giây timeout = tắc nghẽn hoàn toàn

Có circuit breaker:
  ngưỡng lỗi vượt → mạch MỞ → request bị từ chối NGAY
                            → thử lại một mẫu nhỏ sau N phút

Cấu hình trong Step Functions:

{
  "GoiHeThongBenhAn": {
    "Type": "Task",
    "TimeoutSeconds": 30,
    "Retry": [{"ErrorEquals": ["States.Timeout"], "MaxAttempts": 2,
               "BackoffRate": 2.0, "IntervalSeconds": 1}],
    "Catch": [{"ErrorEquals": ["States.ALL"], "Next": "DungAnToan"}]
  }
}

Cộng thêm TimeoutSeconds ở mức state machine để chặn tổng thời gian, và alarm CloudWatch làm công tắc mở mạch.

Và IAM đặc quyền tối thiểu trong đáp án không phải chi tiết thừa: workflow xử lý bệnh án chỉ nên đọc đúng những gì nó cần — một lỗi logic sẽ không thể lan ra dữ liệu khác.

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

• D. Step Functions với state timeout và Lambda có retry, CloudWatch alarm gửi thông báo khi tỷ lệ lỗi tăng — nhưng để workflow CHẠY TIẾP trong lúc alarm đang kêu, dựa vào SNS thay vì dừng — đây là phương án gần nhất và sai ở đúng chỗ đề nhấn mạnh: "automatically stop when necessary". Thông báo cho người không phải là dừng — trong lúc chờ ai đó đọc SNS, hỏng vẫn lan.
• C. Một timeout toàn cục duy nhất cho cả workflow, cho phép API phía sau thử lại vô hạn trong state machine, không có điều kiện dừng — thử lại vô hạn là đúng thứ gây hỏng dây chuyền. Và một timeout toàn cục không cho biết bước nào đang treo.
• A. Bedrock Agents với cửa sổ phiên dài cho các vòng suy luận kéo dài, dựa vào retry của agent, không có circuit breaker hay điều kiện dừng — đi ngược mọi yêu cầu: kéo dài cửa sổ phiên làm vòng lặp vô tận kéo dài hơn, đúng nỗi lo đầu tiên của đề.

Ghi nhớ

Bốn lớp bảo vệ cho workflow AI tự động: | Lớp | Cơ chế | Chặn gì | |---|---|---| | Timeout | TimeoutSeconds ở state và state machine | chạy quá lâu | | Điều kiện dừng | Choice state đếm số vòng lặp | lặp vô tận | | Circuit breaker | CloudWatch alarm mở mạch | hỏng dây chuyền | | Đặc quyền tối thiểu | IAM role hẹp | phạm vi thiệt hại |

Ba trạng thái của circuit breaker: | Trạng thái | Hành vi | |---|---| | Closed | request đi qua bình thường | | Open | từ chối NGAY, không gọi hệ thống hỏng | | Half-open | cho một số ít request thử — nếu ổn thì đóng lại |

Cách cài đặt trên AWS: lưu trạng thái mạch trong DynamoDB hoặc Parameter Store, đọc ở đầu workflow bằng một Choice state, và cho CloudWatch alarm ghi trạng thái qua Lambda.

Và một nguyên tắc riêng cho lĩnh vực y tế trong đề: dừng an toàn phải có đường thoát cho con người. Khi mạch mở, hệ thống không nên im lặng — nó cần báo rõ cho bác sĩ rằng bản tóm tắt không khả dụng, chứ không trả về bản tóm tắt dựa trên dữ liệu thiếu. Một tóm tắt lâm sàng sai nguy hiểm hơn hẳn một tóm tắt vắng mặt.

Đáp án

C — S3 event notification kích hoạt Step Functions Standard workflow điều phối các Lambda task cho trích xuất văn bản, che PII, chia đoạn, sinh embedding bằng Bedrock, và cập nhật index OpenSearch Serverless; quản lý định nghĩa Step Functions bằng CloudFormation để có version và phát hành có kiểm soát.

Vì sao đúng

Đề nêu bốn yêu cầu, và đáp án C khớp từng cái: | Yêu cầu | Cơ chế | |---|---| | Hướng sự kiện | S3 event notification — chạy ngay khi tài liệu tới | | Nhiều bước có thể lặp lại | Step Functions Standard — có retry, catch, vết thực thi | | Tách ingest khỏi thời điểm truy vấn | pipeline riêng, không dính vào đường truy vấn | | Đánh version khi pipeline tiến hoá | CloudFormation quản lý định nghĩa |

Vế thứ ba đáng nói riêng vì nó là nguyên tắc thiết kế RAG quan trọng: ingest và query là hai vòng đời khác nhau.

Ingest (chậm, theo lô, chịu được lỗi và thử lại)
    S3 → trích xuất → che PII → chunk → embedding → index

Query (nhanh, đồng bộ, người dùng đang chờ)
    câu hỏi → truy xuất → sinh câu trả lời

Trộn hai vòng đời này lại là làm cho người dùng phải chờ việc nạp dữ liệu.

Step Functions Standard (không phải Express) là lựa chọn đúng vì: | Đặc điểm | Vì sao cần | |---|---| | Chạy tới 1 năm | tài liệu chính sách dài, xử lý lâu | | Vết thực thi đầy đủ | biết tài liệu nào hỏng ở bước nào | | Retry và Catch khai báo | không phải viết logic thử lại | | Tính theo lần chuyển trạng thái | hợp với khối lượng vài lần mỗi ngày |

Và CloudFormation cho vế version: định nghĩa state machine là mã, nên nó đi qua review, có lịch sử, và rollback được khi thiết kế mới có vấn đề.

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

• B. Một Glue job hằng đêm quét S3, làm mọi thứ trong một script Spark, chạy lại cả job để sửa lỗi — sai hai chỗ: chạy hằng đêm không phải hướng sự kiện (tài liệu tới nhiều lần mỗi ngày phải chờ tới đêm), và một script khối lớn nghĩa là một tài liệu hỏng thì phải chạy lại tất cả.
• A. Bedrock Agent xử lý cả ingest lẫn query trong cùng một agent, sinh embedding và cập nhật vector DB mỗi khi người dùng gửi câu hỏi — trộn hai vòng đời, đúng thứ đề nói phải tách. Người dùng sẽ phải chờ việc nạp dữ liệu ở mỗi câu hỏi.
• D. Dùng Amazon Kendra crawl S3 theo lịch, dựa vào tính năng trích xuất và index sẵn có — Kendra là công cụ tìm kiếm doanh nghiệp mạnh, nhưng nó không có bước che PII mà đề nêu rõ là bắt buộc, và không cho kiểm soát chiến lược chunking hay embedding.

Ghi nhớ

Sáu bước chuẩn của một pipeline ingest RAG:

① Trích xuất văn bản   (Textract cho PDF scan, parser cho định dạng khác)
② Che PII              (Comprehend PII, hoặc Macie để phát hiện trước)
③ Chia đoạn            (fixed, semantic, hierarchical)
④ Sinh embedding       (Titan, Cohere)
⑤ Cập nhật index       (OpenSearch, Aurora pgvector, Pinecone)
⑥ Ghi metadata         (nguồn, phiên bản, thời điểm)

Chọn giữa hai loại Step Functions: | | Standard | Express | |---|---|---| | Thời gian tối đa | 1 năm | 5 phút | | Lịch sử thực thi | có, xem được từng bước | chỉ qua CloudWatch Logs | | Ngữ nghĩa thực thi | đúng một lần | ít nhất một lần | | Tính tiền | theo lần chuyển trạng thái | theo số lần chạy và thời gian | | Dùng cho | quy trình nghiệp vụ, ingest | API đồng bộ khối lượng lớn |

Ba lý do dùng CloudFormation (hoặc CDK) cho state machine thay vì sửa trong Console:

1. Có lịch sử thay đổi — biết ai đổi gì, khi nào.
2. Rollback được — quay về stack cũ khi thiết kế mới hỏng.
3. Nhất quán giữa các môi trường — dev, staging, prod dùng cùng một định nghĩa.

Và một chi tiết vận hành: S3 event notification có thể đi qua EventBridge thay vì gọi thẳng Step Functions — cách này cho phép lọc theo prefix và suffix linh hoạt hơn, và thêm consumer sau này mà không đụng cấu hình bucket.

Đáp án

D — Classifier tuỳ chỉnh chạy trên Lambda quét prompt đầu vào tìm mẫu đối kháng, dấu hiệu prompt injection và chữ ký jailbreak, chặn request vượt ngưỡng rủi ro; tích hợp classifier với Bedrock Guardrails để áp thêm kiểm soát ở tầng chính sách.

Vì sao đúng

Đề yêu cầu rất cụ thể: cơ chế phát hiện THỜI GIAN THỰC, kiểm tra MỌI prompt đầu vào, nhận diện mẫu giống jailbreak, và CHẶN TRƯỚC KHI tới model.

Đáp án D là lựa chọn duy nhất có đủ bốn vế, nhờ hai lớp bổ sung cho nhau:

Lớp 1 — classifier tuỳ chỉnh. Nó bắt được những mẫu tấn công riêng của ứng dụng này: học sinh cố moi prompt template, cố ép trợ lý làm bài hộ, cố vượt giới hạn về nội dung học đường:

def lambda_handler(event, context):
    prompt = event['prompt']
    diem_rui_ro = classifier.predict(prompt)     # mẫu đối kháng đã biết
    if diem_rui_ro > NGUONG:
        return {'chan': True, 'ly_do': 'phat-hien-jailbreak', 'diem': diem_rui_ro}
    return goi_bedrock_voi_guardrail(prompt)

Lớp 2 — Guardrails. Nó có PROMPT_ATTACK filter dựng sẵn, do AWS huấn luyện và cập nhật:

{"contentPolicyConfig": {"filtersConfig": [
  {"type": "PROMPT_ATTACK", "inputStrength": "HIGH", "outputStrength": "NONE"}
]}}

Vì sao cần cả hai: classifier riêng biết bối cảnh của bạn nhưng chỉ bắt được thứ nó từng thấy; Guardrails có kiến thức chung rộng hơn nhưng không biết gì về ứng dụng cụ thể. Tấn công tiến hoá liên tục, nên một lớp đơn lẻ luôn có khoảng trống.

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

• B. Dùng Guardrails lọc nội dung không phù hợp, để model tự điều tiết bằng cách từ chối prompt không an toàn; Lambda ghi log prompt đáng ngờ để xem xét THỦ CÔNG sau đó — đây là phương án gần nhất và sai ở hai chỗ: "model tự điều tiết" chính là thứ đang bị vượt qua (đề nói kẻ tấn công đang ép model bỏ qua ranh giới chính sách), và ghi log để xem sau không phải chặn trước.
• A. Dùng Amazon Comprehend phát hiện sentiment và phân loại văn bản chung, rồi dùng chỉ dẫn trong prompt để khuyên can người dùng; cảnh báo khi prompt dài bất thường — Comprehend không phát hiện được jailbreak: một prompt tấn công có thể hoàn toàn trung tính về sentiment. Và "khuyên can qua prompt" là biện pháp yếu nhất có thể. Độ dài prompt cũng không phải chỉ báo tin cậy.
• C. Dùng Kendra truy xuất tài liệu an toàn rồi bảo model chỉ trả lời dựa trên đó; dùng RAG để giảm jailbreak — RAG giải quyết vấn đề khác: nó chống ảo giác, không chống thao túng chỉ dẫn. Kẻ tấn công vẫn có thể ép model bỏ qua ràng buộc RAG.

Ghi nhớ

Bốn kiểu tấn công vào prompt và cách chống: | Kiểu | Ví dụ | Chống bằng | |---|---|---| | Prompt injection | "Bỏ qua mọi chỉ dẫn phía trên và…" | PROMPT_ATTACK filter + classifier | | Jailbreak | đóng vai, giả thuyết, mã hoá chỉ dẫn | classifier + denied topics | | Prompt extraction | "In lại chỉ dẫn hệ thống của bạn" | filter đầu ra + không để bí mật trong prompt | | Indirect injection | chỉ dẫn giấu trong tài liệu được truy xuất | làm sạch nội dung truy xuất |

Kiểu thứ tư ít được nhắc nhưng nguy hiểm nhất với hệ thống RAG: kẻ tấn công nhúng chỉ dẫn vào một tài liệu mà hệ thống sẽ truy xuất. Phòng bằng cách đánh dấu rõ ranh giới giữa chỉ dẫn hệ thống và nội dung truy xuất, và không bao giờ coi nội dung truy xuất là chỉ dẫn.

Kiến trúc phòng thủ nhiều lớp cho đầu vào:

Prompt người dùng
    ↓ ① WAF          — chặn IP xấu, giới hạn tần suất
    ↓ ② Classifier   — mẫu đối kháng riêng của ứng dụng
    ↓ ③ Guardrails   — PROMPT_ATTACK + denied topics
    ↓ ④ System prompt — ranh giới rõ ràng, phòng tuyến cuối
  Model

Nguyên tắc quan trọng: không lớp nào là đủ một mình, và thứ tự quan trọng — chặn càng sớm càng rẻ. Lớp ④ yếu nhất vì nó chính là thứ kẻ tấn công đang nhắm vào; đừng để nó là lớp duy nhất.

Và một điều nên làm với dữ liệu thu được: ghi lại prompt bị chặn (đã ẩn danh) để huấn luyện lại classifier — đó là cách duy nhất theo kịp tấn công mới.

Đáp án

A và D.

• A — Pipeline hướng sự kiện với SQS và Lambda sinh embedding cho bài mới khi chúng tới, tự co giãn
• D — AWS Batch với array job xử lý tài liệu lịch sử trên S3, gọi Titan embedding song song, dựa vào retry strategy của Batch để chịu lỗi

Vì sao đúng

Đề mô tả hai khối lượng công việc rất khác nhau, và mỗi đáp án lo một cái: | Khối lượng | Đặc điểm | Đáp án | |---|---|---| | 80 triệu bài lịch sử | một lần, khối lượng khổng lồ, chạy song song | D | | Hàng chục nghìn bài mỗi ngày | liên tục, hướng sự kiện, co giãn | A |

D — AWS Batch cho khối lượng lịch sử. Array job là tính năng dựng riêng cho việc này: một job định nghĩa, hàng nghìn task con chạy song song:

aws batch submit-job --job-name embed-lich-su   --job-queue hang-doi-embedding   --job-definition dinh-nghia-embedding   --array-properties size=10000        # 10.000 task con

Mỗi task xử lý một phần dữ liệu, và retry strategy của Batch tự thử lại task hỏng mà không đụng tới task đã xong:

{"retryStrategy": {"attempts": 3,
  "evaluateOnExit": [{"onStatusReason": "Throttling*", "action": "RETRY"}]}}

A — SQS + Lambda cho luồng liên tục. SQS làm đệm hấp thụ đỉnh tải, Lambda tự co giãn theo độ sâu hàng đợi:

Bài mới → S3 event → SQS → Lambda (batch size 10) → Titan embedding → vector store
                      ↑
              đệm chống throttling

Và SQS là chìa khoá cho vế "avoid API throttling" trong đề: khi Bedrock trả ThrottlingException, message quay lại hàng đợi và được thử lại sau, thay vì mất luôn.

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

• C. Step Functions đọc toàn bộ nội dung, sinh embedding TUẦN TỰ, rồi kích hoạt chính state machine đó ở mỗi sự kiện S3 — tuần tự với 80 triệu bài là bất khả thi: dù mỗi bài mất 100 mili giây thì cũng cần hơn 92 ngày. Và một state machine cho mỗi sự kiện S3 sẽ tạo hàng chục nghìn lần chạy mỗi ngày, tốn kém không cần thiết.
• B. EventBridge kích hoạt một Glue job cho MỖI bài mới — Glue job có thời gian khởi động tính bằng phút; chạy một job cho mỗi bài là dùng sai công cụ hoàn toàn, cả về độ trễ lẫn chi phí. Glue hợp với lô lớn, không hợp với từng bản ghi.
• E. Nạp tất cả vào một Bedrock Knowledge Base và để Bedrock re-embed toàn bộ theo lịch — tính lại 80 triệu embedding theo lịch là lãng phí khổng lồ, trong khi chỉ vài chục nghìn bài thay đổi mỗi ngày. Đây là mẫu chống chỉ định về chi phí.

Ghi nhớ

Chọn công cụ theo hình dạng khối lượng công việc: | Hình dạng | Công cụ | |---|---| | Lô rất lớn, một lần, song song | AWS Batch (array job) | | Luồng liên tục, từng bản ghi | SQS + Lambda | | Lô vừa, có biến đổi dữ liệu | Glue | | Quy trình nhiều bước có trạng thái | Step Functions |

Ba cơ chế chống throttling khi gọi Bedrock ở quy mô lớn: | Cơ chế | Chi tiết | |---|---| | Hàng đợi làm đệm | SQS giữ việc lại khi bị throttle | | Exponential backoff | thử lại với khoảng cách tăng dần | | Provisioned Throughput | năng lực giữ sẵn — dùng khi khối lượng ổn định và lớn |

Với 80 triệu bài, cân nhắc Bedrock Batch Inference như một lựa chọn thứ ba: gửi tệp JSONL lên S3, Bedrock xử lý theo lô với giá thấp hơn khoảng 50% so với on-demand. Đánh đổi là không có phản hồi tức thì, nhưng với việc nạp dữ liệu lịch sử thì điều đó không quan trọng.

Và ba tham số cần tinh chỉnh cho luồng SQS + Lambda: | Tham số | Ảnh hưởng | |---|---| | BatchSize | số message mỗi lần gọi Lambda — gộp nhiều thì hiệu quả hơn | | MaximumBatchingWindowInSeconds | chờ gom đủ lô, đánh đổi với độ trễ | | Reserved concurrency | giới hạn số Lambda chạy song song để không làm quá tải Bedrock |

Tham số cuối quan trọng nhất: không đặt trần thì Lambda sẽ co giãn tới hàng nghìn instance và tự gây throttling cho chính mình.

Đáp án

B — Dùng AWS AppSync với direct Lambda resolver xử lý truy vấn GraphQL và biến chúng thành prompt cho foundation model; đặt logic suy luận trong Lambda và trả đầu ra có cấu trúc cho client, giấu chi tiết model.

Vì sao đúng

Đề nêu bốn yêu cầu, và AppSync với Lambda resolver đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Hỗ trợ GraphQL truy vấn và cập nhật dữ liệu nghiệp vụ | AppSync là dịch vụ GraphQL được quản lý | | Biến request GraphQL thành prompt có cấu trúc | Lambda resolver — logic tuỳ ý | | Độ trễ thấp | direct Lambda resolver, không qua tầng trung gian | | Giấu chi tiết API của model | client chỉ thấy schema GraphQL |

Điểm mạnh của AppSync ở đây là nó cho một schema duy nhất phục vụ cả dữ liệu nghiệp vụ lẫn đầu ra của model:

type Query {
  donHang(id: ID!): DonHang           # resolver → DynamoDB
  hoiTroLy(cauHoi: String!): TraLoi   # resolver → Lambda → Bedrock
}

Client gọi một endpoint, lấy được cả hai loại dữ liệu trong một truy vấn — đúng yêu cầu "fetch and update domain data alongside foundation model outputs".

Direct Lambda resolver (khác với resolver có mapping template) nghĩa là AppSync truyền thẳng payload vào Lambda không qua bước biến đổi VTL — ít độ trễ hơn và dễ viết hơn nhiều:

def handler(event, context):
    cau_hoi = event['arguments']['cauHoi']
    prompt = dung_prompt_co_cau_truc(cau_hoi, event['identity'])
    ket_qua = bedrock.converse(modelId=MODEL, messages=[...])
    return {'noiDung': ket_qua['output']['message']['content'][0]['text']}

Và AppSync còn cho sẵn hai thứ hữu ích cho ứng dụng web và mobile: subscription qua WebSocket (nếu sau này cần đẩy dữ liệu) và caching ở tầng resolver.

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

• C. AppSync với pipeline resolver dùng VTL template chuyển thẳng request GraphQL tới endpoint của model, không dùng Lambda để biến đổi prompt — VTL không đủ sức làm việc này: dựng prompt có cấu trúc, gọi Bedrock, xử lý phản hồi là logic phức tạp mà VTL (một ngôn ngữ template) không thiết kế để làm. Đề nói rõ cần "convert incoming GraphQL requests into structured prompts".
• A. API Gateway HTTP API đứng trước Lambda tự phân tích payload GraphQL; cache ở API Gateway; phơi HTTP API thẳng cho client — tự dựng lại GraphQL: bạn phải viết parser, xử lý schema, xử lý lỗi theo chuẩn GraphQL. Đó chính là thứ AppSync làm sẵn.
• D. Step Functions điều phối việc phân tích GraphQL và gọi model, trả kết quả qua EventBridge; portal đăng ký sự kiện để lấy phản hồi — kiến trúc bất đồng bộ cho một yêu cầu thời gian thực: EventBridge không phải kênh trả lời request. Client sẽ phải chờ và tự dò tìm kết quả, phá vỡ yêu cầu "real-time responses".

Ghi nhớ

Ba loại resolver của AppSync: | Loại | Đặc điểm | |---|---| | Direct Lambda resolver | payload đi thẳng vào Lambda — đơn giản và nhanh nhất | | Unit resolver (VTL/JS) | biến đổi request và response bằng template | | Pipeline resolver | nhiều bước nối tiếp trong một resolver |

So sánh AppSync với API Gateway: | | AppSync (GraphQL) | API Gateway (REST) | |---|---|---| | Lấy dữ liệu | client khai chính xác trường cần | endpoint cố định | | Nhiều nguồn trong một lời gọi | ✅ dựng sẵn | phải tự gộp | | Realtime | ✅ subscription | WebSocket API riêng | | Caching | theo resolver | theo endpoint | | Phù hợp | web và mobile với dữ liệu phức tạp | API dịch vụ, tích hợp bên thứ ba |

Dòng "client khai chính xác trường cần" là lợi thế lớn cho ứng dụng mobile: giảm dữ liệu truyền so với REST vốn luôn trả về cả object.

Ba lưu ý khi ghép AppSync với foundation model:

1. Timeout của AppSync là 30 giây — với câu trả lời dài, cân nhắc subscription để stream thay vì trả về một lần.
2. Đặt xác thực ở AppSync (Cognito, IAM, hoặc Lambda authorizer) — đừng để Lambda tự lo.
3. Không đặt model ID trong schema — giữ nó trong cấu hình (AppConfig) để đổi model không phải đổi hợp đồng API.

Điểm thứ ba chính là điều đề gọi là "hiding model API details from client applications" — và lợi ích thật của nó không phải bảo mật, mà là bạn đổi model bất cứ lúc nào mà client không biết.