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

Đáp án

B — Bật Amazon Macie trên các bucket S3 liên quan và cấu hình job phát hiện dữ liệu nhạy cảm quét TOÀN BỘ object tìm PII và mẫu chịu quản lý; dùng kết quả phân loại để gắn thẻ, cách ly hoặc hạn chế truy cập object rủi ro cao trước khi cho chúng vào luồng fine-tuning hoặc RAG.

Vì sao đúng

Đề mô tả đúng tình trạng: hàng trăm nơi lưu trữ, không có bản kiểm kê nào về file nào chứa dữ liệu nhạy cảm. Và yêu cầu là có tầm nhìn tự động TRƯỚC KHI dữ liệu đi vào quy trình GenAI.

Macie là dịch vụ dựng riêng cho việc này: nó dùng máy học và so khớp mẫu để phát hiện PII và dữ liệu chịu quản lý trong S3, ở quy mô hàng trăm bucket:

aws macie2 create-classification-job   --job-type ONE_TIME   --s3-job-definition '{"bucketDefinitions": [{"accountId":"123456789012",
                        "buckets":["kho-phan-hoi-khach-hang"]}]}'   --name "quet-truoc-genai"

Và hai chữ "full discovery" trong đáp án là điểm phân biệt then chốt so với phương án C. Macie có hai chế độ: | Chế độ | Phạm vi | |---|---| | Automated sensitive data discovery | LẤY MẪU object đại diện — cho cái nhìn tổng quan, chi phí thấp | | Classification job | QUÉT ĐẦY ĐỦ mọi object trong phạm vi khai báo |

Với yêu cầu "comprehensive method" và "before any dataset is used", lấy mẫu là không đủ: những object không được lấy mẫu vẫn có thể chứa dữ liệu nhạy cảm, và bạn đưa chúng vào fine-tuning mà không biết.

Vế cuối — gắn thẻ, cách ly, hạn chế — biến kết quả quét thành hành động:

Macie finding (nghiêm trọng cao)
    ↓ EventBridge
Lambda: gắn tag do_nhay_cam=cao + chuyển sang bucket cách ly
    ↓
Pipeline GenAI chỉ đọc object có tag do_nhay_cam=thap

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

• C. Bật Macie với giám sát mặc định, dựa vào lấy mẫu object tự động; chỉ gắn nhãn cho object đã phát hiện và CHO PHẦN CÒN LẠI CHƯA QUÉT chảy vào fine-tuning và RAG — đây là phương án gần nhất và bị loại bởi chính vế cuối: cho dữ liệu chưa quét đi vào là bỏ qua toàn bộ mục đích. Yêu cầu của đội bảo mật là chỉ dataset đã được duyệt mới được dùng.
• A. Dùng Athena truy vấn mẫu object và so khớp mẫu để ƯỚC LƯỢNG file nào có thể chứa trường chịu quản lý; đẩy toàn bộ ứng viên sang bucket tạm — "ước lượng" không phải phát hiện: bạn tự viết regex, tự bảo trì, và độ phủ phụ thuộc vào việc bạn nghĩ ra đủ mẫu. Athena cũng không đọc được nhiều định dạng file mà Macie xử lý được.
• D. Dùng Guardrails chặn danh mục nhạy cảm và dựa vào luật guardrail để ngăn PII vào dataset fine-tuning và RAG; cho pipeline nạp mọi object rồi lọc ở tầng guardrail — hai lỗi: Guardrails hoạt động lúc gọi model, nó không quét được dữ liệu đang nằm trong S3; và với fine-tuning thì dữ liệu đã đi vào trọng số model từ trước — không có guardrail nào gỡ ra được.

Ghi nhớ

Ba dịch vụ hay bị lẫn khi nói về dữ liệu nhạy cảm: | Dịch vụ | Việc | Thời điểm | |---|---|---| | Amazon Macie | phát hiện dữ liệu nhạy cảm TRONG S3 | trước khi dùng dữ liệu | | Comprehend PII | phát hiện và che PII trong VĂN BẢN | trong pipeline xử lý | | Bedrock Guardrails | chặn PII trong prompt và phản hồi | lúc gọi model |

Cả ba đều cần, ở ba vị trí khác nhau — không cái nào thay được cái nào.

Hai chế độ của Macie: | Chế độ | Chi phí | Độ phủ | Dùng khi | |---|---|---|---| | Automated discovery | thấp | lấy mẫu | giám sát liên tục, cái nhìn tổng quan | | Classification job | cao hơn | đầy đủ | kiểm kê trước một quyết định quan trọng ← câu này |

Nguyên tắc riêng cho fine-tuning cần nhớ:

Dữ liệu đã đi vào fine-tuning thì không rút ra được.

Khác với RAG (gỡ tài liệu khỏi index là xong), fine-tuning ghi thông tin vào trọng số model. Nếu PII lọt vào tập huấn luyện, cách chữa duy nhất là huấn luyện lại từ đầu bằng dữ liệu sạch. Đó là lý do việc quét đầy đủ trước khi huấn luyện đáng giá hơn nhiều so với chi phí quét.

Và ba loại dữ liệu Macie phát hiện được: | Loại | Ví dụ | |---|---| | PII | tên, địa chỉ, email, số điện thoại, số định danh | | Tài chính | số thẻ, số tài khoản ngân hàng | | Thông tin xác thực | AWS access key, private key, chuỗi kết nối |

Loại thứ ba đáng chú ý riêng: kho dữ liệu cũ tích tụ nhiều năm thường có lẫn khoá bí mật trong file cấu hình hay log — và nếu chúng đi vào tập huấn luyện thì model có thể sinh ra chúng.

Đáp án

A — Chuyển PDF sang định dạng có cấu trúc như HTML, trích ra tiêu đề, tiêu đề phụ và ranh giới bảng TRƯỚC KHI nạp; rồi cấu hình Bedrock Knowledge Bases với luật hierarchical chunking và ánh xạ metadata để tạo các đoạn khớp với cấu trúc tài liệu.

Vì sao đúng

Đề nêu triệu chứng cụ thể: hệ thống truy xuất được điều khoản một phần, thiếu định nghĩa quan trọng và văn bản ngữ cảnh lân cận.

Nguyên nhân: PDF không mang thông tin cấu trúc ở dạng máy đọc được. Với trình đọc, một tiêu đề chỉ là "chữ to hơn ở dòng này" — không có gì nói rằng nó mở đầu một mục và các đoạn phía dưới thuộc về nó.

Nên phải làm hai việc theo thứ tự, và đó chính là hai vế của đáp án A:

① Khôi phục cấu trúc trước khi nạp. Chuyển sang HTML biến cấu trúc ngầm thành cấu trúc tường minh:

<h1>Điều 5 — Nghĩa vụ báo cáo</h1>
  <h2>5.1 Định nghĩa</h2>
    <p>"Giao dịch trọng yếu" nghĩa là...</p>
  <h2>5.2 Thời hạn</h2>
    <table>...</table>
  <div class="footnote">[1] Xem thêm Điều 12</div>

② Hierarchical chunking dựa trên cấu trúc đó. Giờ Knowledge Bases mới có cái để bám vào:

[Cha: Điều 5]
   ├── [Con: 5.1 Định nghĩa]
   └── [Con: 5.2 Thời hạn]

Tìm bằng chunk con (chính xác), đưa vào model bằng chunk cha (kèm định nghĩa và ngữ cảnh lân cận) — đúng thứ đang bị thiếu.

Và ánh xạ metadata cho phép lọc theo điều khoản, theo văn bản pháp lý, theo ngày hiệu lực.

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

• C. Chuyển PDF sang HTML rồi tải thẳng lên Knowledge Bases, dựa vào pipeline nạp mặc định tự suy ra ranh giới phân cấp — đây là phương án gần nhất và sai ở đúng một điểm: phải BẬT hierarchical chunking, nó không phải mặc định. Mặc định của Knowledge Bases là chia cố định 300 token. Chuyển sang HTML là bước đúng nhưng chưa đủ — không cấu hình thì cấu trúc vừa khôi phục lại bị bỏ qua.
• D. Tải nguyên tài liệu không tiền xử lý, dựa vào pipeline mặc định nhận ranh giới và tự khôi phục quan hệ logic — gán cho dịch vụ khả năng nó không có: không có bộ nạp nào "tự khôi phục quan hệ logic" từ PDF thô. Đây là mô tả một tính năng tưởng tượng.
• B. Lambda cắt PDF thành chunk cố định, để Titan lo phần ngữ nghĩa, rồi dựa vào foundation model tự dựng lại định nghĩa và cấu trúc bị thiếu lúc suy luận — giữ nguyên vấn đề gốc, và vế cuối rất nguy hiểm: bảo model "tự bù phần thiếu" với văn bản pháp quy nghĩa là mời nó bịa ra định nghĩa. Với tài liệu tuân thủ, đó là rủi ro nghiêm trọng.

Ghi nhớ

Hai bước bắt buộc cho tài liệu có cấu trúc phức tạp:

① Khôi phục cấu trúc  → HTML, Markdown, hoặc JSON có phân cấp
② Chunking theo cấu trúc → hierarchical, có overlap

Bỏ bước ① thì bước ② không có gì để bám. Bỏ bước ② thì công của bước ① bị vứt đi.

Công cụ cho bước ①: | Công cụ | Mạnh ở | |---|---| | Amazon Textract | PDF scan, bảng, form — trả về cấu trúc có toạ độ | | Textract Layout | nhận diện tiêu đề, đoạn, danh sách, bảng | | Thư viện parser (pdfplumber…) | PDF gốc số, nhanh và rẻ hơn | | BDA (Bedrock Data Automation) | trích xuất có cấu trúc từ tài liệu đa dạng |

Với PDF quy định dài có bảng và chú thích như đề mô tả, Textract Layout là lựa chọn phù hợp vì nó phân biệt được tiêu đề với đoạn văn thường.

Ba loại nội dung PDF hay bị mất khi chunking ngây thơ: | Nội dung | Hậu quả | |---|---| | Bảng | bị cắt ngang, mất tiêu đề cột ⇒ các con số vô nghĩa | | Chú thích cuối trang | tách khỏi câu nó giải thích | | Định nghĩa ở đầu chương | không đi kèm điều khoản dùng nó ← triệu chứng trong đề |

Cách xử lý bảng đáng nói riêng: giữ nguyên bảng trong MỘT chunk và lặp lại tiêu đề cột nếu buộc phải chia. Một bảng bị cắt đôi là dữ liệu sai chứ không chỉ là ngữ cảnh thiếu.

Và mẹo cho chú thích: khi chuyển sang HTML, nội tuyến chú thích vào ngay vị trí tham chiếu thay vì để nó cuối tài liệu — cách này đảm bảo nó luôn đi cùng câu cần nó.

Đáp án

A — Dựng Amazon SageMaker Pipeline định nghĩa các bước cần thiết; cấu hình pipeline kích hoạt theo sự kiện và quay về phiên bản model đã duyệt khi chỉ số đánh giá xấu đi.

Vì sao đúng

Đề liệt kê sáu việc, và SageMaker Pipelines có step dựng sẵn cho tất cả: | Việc | Step | |---|---| | Chuẩn bị dữ liệu | ProcessingStep | | Huấn luyện | TrainingStep | | Đánh giá | ProcessingStep | | Đề bạt có điều kiện | ConditionStep | | Đăng ký vào registry | RegisterModel | | Triển khai lên endpoint | ModelStep |

ConditionStep là mảnh quan trọng nhất — nó là chỗ diễn đạt "chỉ đề bạt nếu chỉ số đủ tốt":

dieu_kien = ConditionGreaterThanOrEqualTo(
    left=JsonGet(step_name=buoc_danh_gia.name,
                 property_file=bao_cao, json_path="metrics.f1"),
    right=0.85)

ConditionStep(name="KiemTraChatLuong", conditions=[dieu_kien],
              if_steps=[buoc_dang_ky, buoc_trien_khai],
              else_steps=[])          # không đạt ⇒ dừng, giữ model cũ

Và rollback đến từ Model Registry: mỗi model được đăng ký kèm trạng thái phê duyệt, nên quay lại chỉ là triển khai lại package version đã duyệt trước đó — không phải huấn luyện lại:

sm.update_model_package(ModelPackageArn=arn_ban_cu,
                        ModelApprovalStatus='Approved')

Vế "easily triggered on new training data or configuration changes" cũng có sẵn: EventBridge rule kích hoạt pipeline khi có dữ liệu mới trên S3, hoặc khi mã thay đổi.

Điểm quyết định so với các phương án khác: mọi thứ nằm trong MỘT dịch vụ, có lineage tracking tự động (biết model này sinh ra từ dữ liệu nào, tham số nào) — thứ mà các phương án tự ghép không có.

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

• B. Step Functions điều phối Lambda gửi training job, chạy script đánh giá, cập nhật endpoint; lưu version model trong DynamoDB; EventBridge kích hoạt khi có dữ liệu mới — đây là phương án gần nhất và hoạt động được. Nhưng nó tự dựng lại Model Registry bằng DynamoDB, mất lineage tracking tự động, và phải tự viết logic rollback. Với một quy trình ML thuần tuý, SageMaker Pipelines là công cụ đúng chuyên môn hơn.
• C. CodePipeline phát hiện thay đổi mã, CodeBuild gọi API SageMaker; đánh giá, so sánh chỉ số và rollback viết hoàn toàn bằng shell script trong build stage — logic ML quan trọng nhất nằm trong shell script: khó test, khó bảo trì, không có lineage. CodePipeline hợp cho triển khai mã, không cho vòng đời model.
• **D. Lên lịch chạy một Jupyter notebook trên notebook instance đọc dữ liệu, huấn luyện, tính chỉ số và cập nhật thẳng endpoint production; lưu thông tin model trong một tệp JSON trên S3 và GHI ĐÈ mỗi lần huấn luyện — không thể rollback: ghi đè tệp JSON là xoá mất thông tin phiên bản cũ. Và cập nhật thẳng production không qua bước kiểm tra là chống chỉ định.

Ghi nhớ

So sánh hai công cụ điều phối cho ML: | | SageMaker Pipelines | Step Functions | |---|---|---| | Chuyên cho ML | ✅ step dựng sẵn | công cụ tổng quát | | Lineage tracking | ✅ tự động | phải tự làm | | Tích hợp Model Registry | ✅ dựng sẵn | gọi API thủ công | | Ghép dịch vụ ngoài ML | hạn chế | ✅ rất mạnh | | Dùng khi | quy trình huấn luyện và triển khai model | quy trình nghiệp vụ nhiều dịch vụ |

Nguyên tắc chọn: nếu mọi bước đều là ML thì dùng SageMaker Pipelines; nếu có nhiều dịch vụ ngoài ML thì dùng Step Functions — hoặc ghép cả hai (Step Functions gọi SageMaker Pipeline như một bước).

Bốn trạng thái phê duyệt trong SageMaker Model Registry: | Trạng thái | Nghĩa | |---|---| | PendingManualApproval | chờ người duyệt | | Approved | được phép triển khai | | Rejected | không đạt |

Mẫu triển khai an toàn thường dùng: pipeline đăng ký với trạng thái PendingManualApproval, một người xem báo cáo đánh giá rồi duyệt, và việc duyệt phát ra sự kiện EventBridge kích hoạt triển khai. Cách này giữ được tự động hoá mà vẫn có cửa kiểm soát của con người.

Và ba thứ nên lưu cùng mỗi model version để rollback có ý nghĩa:

1. Chỉ số đánh giá — biết vì sao nó được duyệt.
2. Con trỏ tới dữ liệu huấn luyện — biết nó học từ đâu.
3. Siêu tham số và phiên bản mã — tái lập được.

Thiếu ba thứ này thì "quay về bản trước" chỉ là quay về một hộp đen khác.

Đáp án

B — Tích hợp SageMaker Model Card API vào CI/CD sao cho các stage triển khai tự động gọi create_model_card và update_model_card với metadata trích từ job huấn luyện và đánh giá; cấu hình pipeline CHẶN việc đề bạt model cho tới khi model card được kiểm tra hợp lệ và lưu vào registry.

Vì sao đúng

Đề nêu ba yêu cầu, và cụm khoá là "mandatory step":

1. Mỗi lần đề bạt model tự động sinh model card cập nhật
2. Ghi được mục đích sử dụng, giới hạn, chỉ số chính, xếp hạng rủi ro
3. KHÔNG chỉnh sửa thủ công

Đáp án B là lựa chọn duy nhất biến việc lập tài liệu thành một cửa chặn thật sự:

sm.create_model_card(
    ModelCardName=f'model-rui-ro-{version}',
    Content=json.dumps({
        'model_overview': {'model_id': model_id, 'model_version': version},
        'intended_uses': {'purpose_of_model': 'Chấm điểm rủi ro tín dụng',
                          'intended_uses': 'Chỉ dùng hỗ trợ, không tự quyết',
                          'factors_affecting_model_efficiency': '...'},
        'evaluation_details': [{'metric_groups': chi_so_tu_job_danh_gia}],
        'risk_rating': 'High'
    }),
    ModelCardStatus='PendingReview')

Metadata trích tự động từ job huấn luyện và đánh giá là điểm khiến nó "không cần chỉnh tay": chỉ số không được gõ lại, chúng đọc thẳng từ nguồn — nên không thể lệch với thực tế.

Và "block model promotion until validated" là điều phân biệt B với C:

Stage đánh giá → Stage sinh model card → Stage kiểm tra hợp lệ
                                              ├─ đạt   → đề bạt
                                              └─ hỏng  → DỪNG pipeline

Với yêu cầu của bộ phận quản lý rủi ro trong ngành tài chính, đây là khác biệt giữa "có tài liệu" và "chắc chắn có tài liệu".

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

• **C. Thêm một stage KHÔNG CHẶN gọi Model Card API với template mặc định không kiểm tra metadata; cho pipeline tiếp tục đề bạt kể cả khi bước tạo model card HỎNG hoặc tài liệu thiếu — đây là phương án gần nhất và bị loại bởi đúng chữ "non-blocking": một bước không chặn thì không phải bắt buộc. Model sẽ lên production với model card rỗng, và không ai biết cho tới kỳ kiểm toán.
• A. Lambda chạy sau mỗi lần triển khai đọc chỉ số từ S3 và gửi tóm tắt cho đội tuân thủ, họ tự tạo model card trong Console — thủ công, trái yêu cầu "without manual edits". Và nó chạy SAU khi triển khai — model đã ở production trước khi có tài liệu.
• D. CI/CD chạy Processing job xuất chỉ số ra S3, rồi kích hoạt việc tạo model card THỦ CÔNG từ Console; CloudWatch Events báo cho người xem xét — cùng vấn đề: "manually trigger" là chính thứ đề muốn loại bỏ.

Ghi nhớ

Nội dung một SageMaker Model Card: | Mục | Nội dung | |---|---| | Model overview | id, version, chủ sở hữu, ngày tạo | | Intended uses | mục đích, phạm vi được phép, phạm vi CẤM | | Training details | dữ liệu, siêu tham số, môi trường | | Evaluation details | chỉ số, tập đánh giá, kết quả theo phân khúc | | Ethical considerations | thiên lệch đã biết, nhóm bị ảnh hưởng | | Risk rating | Low / Medium / High |

Dòng "phạm vi CẤM" đáng nhớ: với model chấm điểm rủi ro tài chính, nói rõ model này KHÔNG được dùng để làm gì thường quan trọng hơn nói nó được dùng để làm gì.

Nguyên tắc thiết kế rút ra từ câu này:

Nếu một bước tuân thủ không chặn được pipeline, nó không phải là bắt buộc — nó là gợi ý.

Điều này áp cho mọi cửa kiểm soát: quét bảo mật, kiểm thử, phê duyệt. Một stage "chạy nhưng bỏ qua lỗi" cho cảm giác an toàn mà không có an toàn.

Ba trạng thái của model card: | Trạng thái | Nghĩa | |---|---| | Draft | đang soạn | | PendingReview | chờ người xem xét | | Approved | đã duyệt | | Archived | không còn dùng |

Và ba điểm cần lưu ý khi tự động hoá:

1. Một số trường không tự sinh được — "intended uses" và "ethical considerations" cần con người viết. Giải pháp: template có sẵn phần mô tả, tự động điền phần số liệu, và validation kiểm tra các trường bắt buộc không rỗng.
2. Gắn model card với đúng model package version — không phải với tên model, vì tên thì nhiều version chung nhau.
3. Xuất ra PDF hoặc lưu bất biến cho hồ sơ kiểm toán — Model Card API cho phép xuất, và S3 Object Lock giữ bản không sửa được.

Đáp án

C — Dùng Bedrock model evaluation job chạy CẢ prompt cũ lẫn prompt mới trên một tập dữ liệu kiểm chứng đầy đủ và thu chỉ số chất lượng có cấu trúc; lưu phiên bản prompt và kết quả đánh giá vào DynamoDB để tự động so sánh định kỳ và phát hiện hồi quy một cách nhất quán.

Vì sao đúng

Đề mô tả đúng vấn đề: prompt mới cải thiện một số dòng sản phẩm nhưng làm xấu đi những dòng khác, và đội không có cách so sánh có cấu trúc trên một tập test rộng.

Ba yếu tố cần có, và chỉ C đủ cả ba: | Yếu tố | Vì sao cần | |---|---| | Chạy CẢ HAI phiên bản | không có đường cơ sở thì không biết là cải thiện hay hồi quy | | Tập dữ liệu kiểm chứng ĐẦY ĐỦ | kết quả khác nhau theo dòng sản phẩm — mẫu nhỏ sẽ bỏ sót | | Chỉ số có cấu trúc, lưu lại được | so sánh tự động, phát hiện hồi quy về sau |

Yếu tố thứ hai là thứ trực tiếp giải thích triệu chứng trong đề: prompt mới được chỉnh tay ở môi trường staging, tức là trên một số ít ví dụ. Nó tốt lên ở những ví dụ đó và xấu đi ở chỗ không ai nhìn tới.

bedrock.create_evaluation_job(
    jobName='so-sanh-prompt-thuong-hieu-v2',
    evaluationConfig={'automated': {'datasetMetricConfigs': [{
        'taskType': 'Generation',
        'dataset': {'name': 'bo-kiem-chung-day-du',
                    'datasetLocation': {'s3Uri': 's3://.../validation.jsonl'}},
        'metricNames': ['Toxicity', 'Robustness', 'Accuracy']}]}},
    inferenceConfig={'models': [{'bedrockModel': {...}}]})

Và lưu vào DynamoDB phục vụ vế cuối — "automate periodic comparisons": bạn giữ được lịch sử điểm số theo từng phiên bản prompt, nên lần thay đổi sau có đường cơ sở để so.

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

• **D. Dùng evaluation job CHỈ kiểm prompt MỚI trên tập dữ liệu chọn lọc, giữ prompt cũ làm đường cơ sở lưu trong DynamoDB; xem xét định kỳ và điều chỉnh theo xu hướng điểm ở mức cao, không chạy so sánh song song — đây là phương án gần nhất và sai ở đúng chỗ: lưu prompt cũ không phải là chạy nó. Không có điểm số của prompt cũ trên cùng tập dữ liệu, cùng thời điểm thì không so được. Và "high level scoring trends" quá thô để thấy hồi quy ở một dòng sản phẩm cụ thể.
• **A. Chạy hai phiên bản trên một tập nhỏ mẫu, so sánh THỦ CÔNG; lưu S3 và xem xét thỉnh thoảng khi có ai phàn nàn — chính là tình trạng hiện tại: chỉnh tay trên mẫu nhỏ là nguyên nhân gây ra vấn đề. Và "khi product team nêu quan ngại" nghĩa là phát hiện sau khi khách hàng đã thấy.
• B. Chỉ áp prompt mới cho sản phẩm mới rồi mở rộng dần; dùng S3 versioning theo dõi template và giả định rằng chất lượng được giữ nguyên ở các phân khúc mà không kiểm thử có cấu trúc — "assume the new configuration maintains quality" là điểm loại: giả định chính là thứ đã sai. Phát hành dần là kỹ thuật tốt nhưng không thay thế được việc đo.

Ghi nhớ

Ba yếu tố của một khung kiểm thử prompt đáng tin: | Yếu tố | Chi tiết | |---|---| | Tập dữ liệu vàng | phủ MỌI phân khúc, kể cả ca hiếm | | So sánh song song | hai phiên bản, cùng dữ liệu, cùng lúc | | Chỉ số lưu lại được | so được với lần sau, phát hiện trôi dần |

Sai lầm phổ biến nhất, và cũng là sai lầm trong đề: đánh giá trên dữ liệu dùng để chỉnh prompt. Điểm số sẽ đẹp vì prompt đã được tối ưu cho đúng những ví dụ đó. Tập kiểm chứng phải tách riêng và không được nhìn trong lúc chỉnh.

Ba loại chỉ số đánh giá đầu ra sinh ngữ: | Loại | Ví dụ | Đặc điểm | |---|---|---| | Tự động, có tham chiếu | BLEU, ROUGE, so với đáp án chuẩn | rẻ, nhưng kém với văn bản sáng tạo | | LLM-as-a-judge | model chấm theo rubric | linh hoạt, hợp với "tone and brand" | | Người chấm | mẫu nhỏ, chuẩn để hiệu chỉnh | đắt nhưng là neo |

Với tiêu chí "tone and brand alignment" như đề nêu, chỉ số tự động có tham chiếu gần như vô dụng — không có "đáp án đúng" cho một đoạn quảng cáo. LLM-as-a-judge với rubric rõ ràng là lựa chọn phù hợp, và nên hiệu chỉnh định kỳ bằng mẫu do người chấm.

Và một điểm quan trọng về cách đọc kết quả: luôn tách điểm theo phân khúc, đừng chỉ nhìn con số tổng. Đề đã cho thấy vì sao — điểm trung bình có thể tăng trong khi một dòng sản phẩm hồi quy nặng, và con số tổng che mất chuyện đó.

Đáp án

C — Dùng Step Functions điều phối workflow kiểm thử chạy cả hai phiên bản prompt trên cùng kho hợp đồng, lưu mọi đầu ra vào S3, dùng Lambda so sánh kết quả và sinh chỉ số hồi quy; đẩy dữ liệu so sánh lên CloudWatch Metrics để theo dõi cải thiện hay suy giảm theo thời gian.

Vì sao đúng

Đề nêu bốn yêu cầu, và C khớp từng cái: | Yêu cầu | Cơ chế | |---|---| | Lặp lại được | Step Functions — định nghĩa cố định, chạy lại giống hệt | | Cả hai phiên bản trên cùng bộ tài liệu lớn | Map state chạy song song | | Đầu ra có cấu trúc | lưu S3 theo phiên bản | | Chỉ số so sánh trước khi đề bạt | Lambda so sánh + CloudWatch Metrics |

Kiến trúc:

Step Functions
  ├─ Map state qua N hợp đồng
  │    ├─ chạy prompt CŨ  → s3://ket-qua/v1/{id}.json
  │    └─ chạy prompt MỚI → s3://ket-qua/v2/{id}.json
  ├─ Lambda so sánh: điều khoản nào v1 bắt được mà v2 bỏ sót
  └─ CloudWatch Metrics: tỷ lệ phát hiện, số hồi quy

Mối lo cụ thể của đội là "bỏ sót điều khoản nhạy cảm mà phiên bản cũ luôn phát hiện" — và đó là một phép so sánh theo từng tài liệu, không phải theo điểm trung bình:

bo_sot = ket_qua_cu['dieu_khoan'] - ket_qua_moi['dieu_khoan']
if bo_sot:
    ghi_hoi_quy(doc_id, bo_sot)        # đây mới là thứ chặn việc đề bạt

Một prompt có thể cải thiện điểm tổng trong khi bỏ sót đúng những điều khoản quan trọng nhất — nên phải so từng cặp, không so tổng.

Map state là công cụ đúng cho quy mô "large set of historical contracts": nó chạy song song với mức đồng thời điều chỉnh được, và một tài liệu hỏng không làm hỏng cả lần chạy.

Và CloudWatch Metrics cho vế theo dõi dài hạn — bạn thấy được xu hướng qua nhiều phiên bản prompt, kèm alarm khi tỷ lệ hồi quy vượt ngưỡng.

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

• **D. Step Functions chạy cả hai phiên bản, lưu đầu ra vào DynamoDB; Lambda TỰ ĐỘNG kích hoạt cập nhật phiên bản prompt khi chỉ số cho thấy cải thiện — đây là phương án gần nhất và sai ở vế cuối: tự động đề bạt là bỏ qua cửa kiểm soát của con người. Đề nói rõ chỉ số dùng để cân nhắc "before a prompt version is promoted" — người quyết định, không phải máy. Với hợp đồng pháp lý, một chỉ số tổng đẹp không đủ để tự động phát hành. (DynamoDB cũng kém hợp hơn S3 cho việc lưu đầu ra văn bản dài.)
• **A. Dùng Comprehend đo độ tương đồng ngữ nghĩa giữa đầu ra cũ và mới, lưu điểm vào S3; chạy qua Lambda không điều phối nhiều bước — đo sai thứ: hai đầu ra có thể rất giống nhau về ngữ nghĩa mà vẫn khác nhau ở đúng chỗ quan trọng (một điều khoản bị bỏ sót). Và Comprehend không có API đo tương đồng ngữ nghĩa theo nghĩa này.
• B. Dùng Prompt Management tự chạy cả hai phiên bản trên toàn bộ kho và tự cập nhật version theo so sánh đầu ra; hiển thị qua "Guardrails analytics" — gán cho dịch vụ những khả năng nó không có: Prompt Management không chạy đánh giá hàng loạt, và không có thứ gọi là "Guardrails analytics" để trực quan hoá kết quả kiểm thử hồi quy.

Ghi nhớ

Bốn bước của một khung kiểm thử hồi quy cho prompt:

① Kho test cố định     — cùng tài liệu ở mọi lần chạy
② Chạy song song       — cả phiên bản cũ và mới
③ So sánh TỪNG CẶP     — không so điểm tổng
④ Chặn đề bạt          — có hồi quy nghiêm trọng thì dừng

Bước ③ là điểm dễ làm sai nhất. Hai cách so sánh cho hai kết luận khác nhau: | Cách so | Cho biết | |---|---| | Điểm trung bình | xu hướng chung — che mất ca hồi quy | | So từng cặp tài liệu | chính xác cái gì mất, ở đâu |

Với việc trích xuất điều khoản rủi ro, chỉ số quan trọng nhất là recall (bắt được bao nhiêu điều khoản thật), không phải precision — bỏ sót một điều khoản rủi ro tốn kém hơn nhiều so với gắn cờ nhầm một điều khoản vô hại.

Tinh chỉnh Map state cho khối lượng lớn:

{"Type": "Map", "MaxConcurrency": 20,
 "ToleratedFailurePercentage": 5,
 "ItemProcessor": {"ProcessorConfig": {"Mode": "DISTRIBUTED"}}}

Và một lưu ý về chi phí: chạy hai phiên bản prompt trên toàn bộ kho hợp đồng là gấp đôi chi phí suy luận cho mỗi lần kiểm thử. Với kho rất lớn, cân nhắc một tập con phân tầng (lấy mẫu có kiểm soát theo loại hợp đồng) thay vì toàn bộ — miễn là mẫu phủ đủ mọi loại điều khoản nhạy cảm mà bạn không muốn bỏ sót.

Đáp án

A và D.

• A — Pipeline tiền xử lý bằng Lambda áp tokenization cho định danh trực tiếp, khái quát hoá cho quasi-identifier (ngày tháng, địa điểm), và nhiễu differential privacy cho chỉ số tổng hợp trước khi gọi model
• D — Chỉ lưu dữ liệu đã biến đổi hoàn toàn trên S3, và bắt buộc mọi prompt và luồng RAG đọc từ các vị trí S3 đã ẩn danh qua IAM role kiểm soát chặt

Vì sao đúng

Đề nêu hai vế, và mỗi đáp án lo một vế: | Vế | Đáp án | |---|---| | Che và ẩn danh có hệ thống trước khi tới model | A — kỹ thuật xử lý | | Đảm bảo model KHÔNG BAO GIỜ chạm dữ liệu thô | D — ranh giới lưu trữ |

A — ba kỹ thuật cho ba loại dữ liệu. Điểm hay là mỗi loại cần một cách khác nhau: | Loại dữ liệu | Kỹ thuật | Vì sao | |---|---|---| | Định danh trực tiếp (tên, mã BN) | tokenization | thay bằng token nhất quán — vẫn nối được các bản ghi cùng người | | Quasi-identifier (ngày sinh, quận) | khái quát hoá | "1985" thay vì "12/03/1985", "miền Bắc" thay vì phường | | Chỉ số tổng hợp | nhiễu differential privacy | chặn suy luận ngược từ các phép đếm |

Dòng giữa là thứ hay bị bỏ sót và cũng là chỗ nguy hiểm nhất: xoá tên là chưa đủ. Kết hợp ngày sinh chính xác, mã bưu chính và ngày khám thường đủ để xác định một người trong tập dữ liệu — đây là tấn công tái định danh kinh điển.

Dòng cuối cũng đáng chú ý: kể cả khi mọi bản ghi đã ẩn danh, một chuỗi truy vấn tổng hợp có thể lộ thông tin cá nhân ("có bao nhiêu bệnh nhân nam sinh 1985 ở quận X mắc bệnh Y" — nếu đáp án là 1). Nhiễu differential privacy chặn đúng kiểu suy luận này.

D — ranh giới ở tầng lưu trữ. Đây là thứ biến quy trình thành đảm bảo: nếu chỉ dữ liệu đã biến đổi tồn tại ở nơi model đọc được, thì không có đường nào để dữ liệu thô lọt qua — kể cả khi ai đó viết sai một prompt.

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

• E. Tokenize định danh trực tiếp và làm mờ nhẹ quasi-identifier, lưu CẢ hai phiên bản che và che một phần, để model tự chọn phiên bản phù hợp; nghiên cứu viên truy cập cả hai — đây là phương án gần nhất và sai ở chỗ nghiêm trọng: để dữ liệu ít được bảo vệ hơn tồn tại trong tầm với là phá bỏ ranh giới. "Light obfuscation" cũng không đủ chống tái định danh, và "để model chọn" nghĩa là không ai kiểm soát nó chọn gì.
• B. Sao chép bản ghi bệnh nhân THÔ sang một bucket riêng có mã hoá và bucket policy chặt, rồi để model đọc thẳng từ đó — mã hoá và kiểm soát truy cập không phải ẩn danh: khi model đọc được thì dữ liệu đã ở dạng rõ. Đề nói rõ cấm chia sẻ định danh trực tiếp với hệ thống phân tích bên ngoài, và model chính là hệ thống đó.
• C. Dùng Guardrails chặn danh mục y tế nhạy cảm, cho Lambda truyền dữ liệu bệnh nhân THÔ tới model và dựa vào guardrail thực thi trước khi model xử lý — hiểu sai thứ tự: guardrail lọc nội dung trong prompt và phản hồi, nhưng dữ liệu vẫn đi vào hệ thống trước khi được lọc. Và guardrail được thiết kế để bắt PII theo mẫu chung, không bắt được quasi-identifier theo ngữ cảnh.

Ghi nhớ

Bốn kỹ thuật bảo vệ quyền riêng tư, theo mức độ: | Kỹ thuật | Cách làm | Giữ được tính hữu dụng | |---|---|---| | Redaction | xoá hẳn | thấp | | Tokenization | thay bằng token nhất quán | cao — vẫn nối bản ghi được | | Generalization | giảm độ chi tiết | vừa | | Differential privacy | thêm nhiễu có kiểm soát | cao ở mức tổng hợp |

Ba loại định danh cần phân biệt: | Loại | Ví dụ | Xử lý | |---|---|---| | Trực tiếp | tên, số CMND, mã bệnh nhân | tokenize hoặc xoá | | Quasi-identifier | ngày sinh, mã bưu chính, giới tính, ngày khám | khái quát hoá | | Nhạy cảm | chẩn đoán, kết quả xét nghiệm | giữ lại (đây là thứ cần nghiên cứu) |

Loại thứ hai là chỗ mà hầu hết các vụ tái định danh xảy ra — và cũng là chỗ mà công cụ tự động hay bỏ sót, vì từng trường riêng lẻ trông vô hại.

Hai khái niệm định lượng đáng biết: | Khái niệm | Nghĩa | |---|---| | k-anonymity | mỗi bản ghi không phân biệt được với ít nhất k−1 bản ghi khác | | ε (epsilon) trong DP | ngân sách riêng tư — càng nhỏ càng riêng tư, càng nhiễu |

Và nguyên tắc kiến trúc quan trọng nhất rút ra từ cặp đáp án này:

Đừng dựa vào quy trình để giữ dữ liệu thô tránh xa model — hãy làm cho nó không tồn tại ở nơi model đọc được.

Quy trình có thể bị bỏ qua; ranh giới lưu trữ thì không.

Đáp án

A và B.

• B — Dùng Amazon Comprehend sàng lọc và phân loại đầu vào có hại TRƯỚC KHI tới model; áp Bedrock Guardrails LÚC gọi model để lọc theo chính sách
• A — Dùng Lambda kiểm tra ĐẦU RA của model về mức độ an toàn; cấu hình API Gateway thực thi bước lọc cuối để chỉ phản hồi đã kiểm chứng mới tới người dùng

Vì sao đúng

Đề mô tả rất rõ ba tầng cần có, và hai đáp án cùng nhau phủ đủ:

① Lọc đầu vào TRƯỚC khi tới model      → B (Comprehend)
② Guardrail LÚC sinh nội dung           → B (Bedrock Guardrails)
③ Kiểm tra lại đầu ra TRƯỚC khi trả về  → A (Lambda + API Gateway)

Vì sao cần cả ba, không thể bớt tầng nào: | Tầng | Bắt được gì mà tầng khác không bắt | |---|---| | Đầu vào | chặn sớm, tiết kiệm chi phí gọi model; bắt nội dung độc hại do người dùng gửi | | Lúc gọi model | bắt jailbreak vượt qua tầng một; kiểm soát nội dung model sinh ra | | Đầu ra | bắt nội dung có hại phát sinh dù đầu vào sạch; áp luật riêng của ứng dụng |

Tầng ba đáng nói riêng: đầu vào vô hại vẫn có thể cho đầu ra có hại. Một câu hỏi học thuật bình thường có thể dẫn model tới nội dung không phù hợp với học sinh — và không tầng đầu vào nào dự đoán được chuyện đó.

# Tầng ③: kiểm tra đầu ra
def kiem_tra_dau_ra(phan_hoi):
    if comprehend_phat_hien_doc_hai(phan_hoi): return CHAN
    if vi_pham_luat_hoc_duong(phan_hoi):        return CHAN
    return CHO_QUA

Và API Gateway thực thi bước cuối nghĩa là không có đường vòng: mọi phản hồi đều đi qua đúng một cửa ra.

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

• E. Dùng Guardrails lọc đầu vào và đầu ra, CloudWatch alarm phát hiện tương tác có hại, Lambda ghi log sự kiện không an toàn để phân tích SAU — đây là phương án gần nhất và hoạt động một phần: Guardrails thật sự lọc cả hai chiều. Nhưng nó thiếu tầng sàng lọc trước mà đề nêu rõ, và ghi log để phân tích sau không phải một lớp bảo vệ — nó là quan sát. Đề yêu cầu "end to end safety pipeline" với ba tầng cụ thể.
• C. Dùng Comprehend phân loại nội dung có hại, chỉ gửi đầu vào sạch tới model, rồi gọi model KHÔNG có guardrail và dùng log S3 để theo dõi mẫu đầu ra — bỏ hẳn tầng hai và tầng ba: cụm "invoke the model without guardrails" là điểm loại. Và xem lại log định kỳ là phát hiện sau khi học sinh đã thấy nội dung.
• D. Dùng Knowledge Bases truy xuất tài liệu tham khảo an toàn và bảo model dựa trên nội dung tin cậy, dùng API Gateway kiểm tra schema đơn giản; dựa vào prompt và hướng dẫn truy xuất để giảm rủi ro — RAG giải quyết vấn đề khác: nó chống ảo giác, không chống nội dung độc hại hay thao túng. Và "schema validation" chỉ kiểm hình thức JSON, không kiểm nội dung.

Ghi nhớ

Kiến trúc an toàn ba tầng cho ứng dụng GenAI:

Người dùng
   ↓ ① Sàng lọc đầu vào    Comprehend, classifier riêng, WAF
   ↓ ② Guardrails          content filter, denied topics, prompt attack
  Model
   ↓ ③ Kiểm tra đầu ra     Comprehend, luật nghiệp vụ, grounding check
Người dùng

Nguyên tắc: mỗi tầng bắt được thứ tầng khác bỏ sót, và chặn càng sớm càng rẻ — nhưng không tầng nào là đủ một mình.

Vai trò của từng công cụ: | Công cụ | Mạnh ở | Yếu ở | |---|---|---| | Comprehend | phân loại văn bản, phát hiện PII, sentiment | không hiểu ý định tấn công tinh vi | | Bedrock Guardrails | chính sách nhiều chiều, áp tự động, tập trung | không biết luật riêng của ứng dụng | | Lambda tuỳ chỉnh | luật nghiệp vụ riêng, ngữ cảnh ứng dụng | phải tự viết và bảo trì |

Ba lưu ý riêng cho nền tảng giáo dục như đề mô tả:

1. Ngưỡng phải chặt hơn ứng dụng thường — người dùng là học sinh, và tiêu chuẩn "phù hợp" khác hẳn.
2. Ghi lại và báo cáo sự cố — nhiều quy định về an toàn trẻ em yêu cầu lưu vết các tương tác bị chặn.
3. Cẩn thận với chặn nhầm — chặn quá tay làm trợ lý vô dụng cho việc học thật (một câu hỏi sinh học có thể trúng bộ lọc nội dung nhạy cảm). Nên hiệu chỉnh ngưỡng theo từng danh mục, không đặt HIGH cho tất cả.

Điểm thứ ba là đánh đổi thật và hay bị bỏ qua: một hệ thống an toàn tới mức không trả lời được gì cũng là một hệ thống hỏng.

Đáp án

A — Cho S3 gửi sự kiện tải lên vào SQS, dùng EventBridge schedule khởi động Step Functions Standard workflow mỗi đêm tiêu thụ hàng đợi bằng Map state trên danh sách tài liệu; mỗi item gọi Lambda lấy PDF, gọi Bedrock tóm tắt, ghi kết quả về S3, và áp chính sách retry cho từng item để chỉ tài liệu hỏng mới chạy lại.

Vì sao đúng

Đề nêu ba yêu cầu, và cụm quan trọng nhất là ở cuối: "automatically retry only failed items without reprocessing the whole batch".

Map state là chìa khoá, và nó khác hẳn một vòng lặp trong mã:

{
  "XuLyTaiLieu": {
    "Type": "Map",
    "MaxConcurrency": 20,
    "ToleratedFailurePercentage": 10,
    "ItemProcessor": {
      "ProcessorConfig": {"Mode": "DISTRIBUTED"},
      "StartAt": "TomTat",
      "States": {"TomTat": {
        "Type": "Task",
        "Resource": "arn:aws:states:::lambda:invoke",
        "Retry": [{"ErrorEquals": ["States.TaskFailed"],
                   "MaxAttempts": 3, "BackoffRate": 2.0}],
        "End": true}}}
  }
}

Ba tham số làm nên khác biệt: | Tham số | Tác dụng | |---|---| | Retry trong ItemProcessor | thử lại ĐÚNG item hỏng, item khác không bị ảnh hưởng | | ToleratedFailurePercentage | vài tài liệu hỏng không huỷ cả lần chạy | | MaxConcurrency | giới hạn song song để không throttle Bedrock |

SQS ở giữa phục vụ hai việc: gom sự kiện tải lên rải rác cả ngày thành một danh sách, và làm đệm chống mất việc nếu workflow ban đêm gặp sự cố.

Và Standard (không phải Express) là đúng vì việc chạy hàng chục nghìn tài liệu vượt xa giới hạn 5 phút của Express, và bạn cần lịch sử thực thi để biết tài liệu nào hỏng.

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

• **D. Step Functions Express hằng đêm với MỘT Lambda task quét S3, gọi Bedrock theo lô lớn, ghi kết quả; retry ở task đó nên mọi lỗi khiến CẢ LÔ chạy lại từ đầu — đây là phương án gần nhất và bị loại bởi chính vế cuối: retry ở mức job là đúng thứ đề cấm. Ngoài ra Express giới hạn 5 phút, và một Lambda giới hạn 15 phút — không đủ cho hàng chục nghìn tài liệu.
• B. S3 event kích hoạt Lambda cho MỖI PDF, gọi Bedrock đồng bộ rồi lưu S3 — trái yêu cầu "avoid long synchronous API calls", và không có kiểm soát tập trung: bạn không biết đêm nay có bao nhiêu tài liệu đã xong, bao nhiêu hỏng. Với hàng chục nghìn file tới rải rác, việc gọi Bedrock đồng thời không giới hạn cũng gây throttling.
• **C. Glue job hằng đêm crawl S3, gọi Bedrock trong một script Spark lặp qua tất cả tài liệu, chạy lại CẢ job nếu log có lỗi — cùng lỗi như D và tệ hơn: Spark thiết kế cho biến đổi dữ liệu song song, không cho điều phối lời gọi API có trạng thái, và một driver script lặp tuần tự thì không tận dụng được gì.

Ghi nhớ

Ba mức xử lý lỗi trong workflow theo lô — quan trọng là biết mình đang ở mức nào: | Mức | Hậu quả khi lỗi | |---|---| | Mức job | chạy lại TẤT CẢ — lãng phí và chậm | | Mức lô con | chạy lại một phần | | Mức item | chỉ item đó chạy lại ← đúng cho câu này |

Distributed Map — tính năng đáng biết cho quy mô lớn: | Đặc điểm | Standard Map | Distributed Map | |---|---|---| | Số item tối đa | ~40 (giới hạn payload) | tới 100 triệu | | Đọc trực tiếp từ S3 | ❌ | ✅ liệt kê object hoặc đọc CSV/JSON | | Số lần chạy con song song | giới hạn | tới 10.000 | | Báo cáo kết quả | trong output | ghi ra S3 |

Với "tens of thousands of PDF reports", Distributed Map là chế độ đúng — nó đọc thẳng danh sách object từ S3 và không bị giới hạn payload.

Ba mẫu tổ chức việc xử lý theo lô ban đêm:

① S3 event → SQS → EventBridge schedule → Step Functions Map    ← câu này
② S3 event → EventBridge → Step Functions ngay (xử lý liên tục)
③ Bedrock Batch Inference (JSONL trên S3, rẻ hơn ~50%)

Mẫu ③ đáng cân nhắc riêng cho tình huống này: nếu việc tóm tắt không cần logic phức tạp giữa các bước, gửi một tệp JSONL cho Bedrock Batch Inference cho ra kết quả tương tự với chi phí thấp hơn khoảng một nửa. Đánh đổi là ít kiểm soát hơn về retry từng item — nên nếu yêu cầu "retry only failed items" là bắt buộc như trong đề, Map state vẫn là lựa chọn đúng.

Đáp án

B — Phơi API Gateway REST API đứng trước một Lambda nhận dữ liệu, che PHI ngay trong Lambda, rồi gọi một Bedrock Flow điều phối prompt theo từng persona, các bước truy xuất tuỳ chọn, và tóm tắt có stream qua Converse API.

Vì sao đúng

Đề nêu năm yêu cầu, và B là lựa chọn duy nhất thoả hết: | Yêu cầu | Cơ chế | |---|---| | Nhiều persona với mức chi tiết khác nhau | Bedrock Flow — nhánh riêng cho từng persona | | Che PHI TRƯỚC khi AI xử lý | Lambda che ngay khi nhận | | Stream phản hồi, độ trễ thấp | Converse API streaming | | Tránh hạ tầng nặng | serverless toàn bộ | | Tiến hoá được khi thêm persona | sửa Flow, không sửa mã |

Thứ tự trong đáp án rất quan trọng: che PHI diễn ra trong Lambda, TRƯỚC khi gọi Flow — nên dữ liệu nhạy cảm không bao giờ tới model:

def handler(event, context):
    ghi_chu = event['ghiChu']
    ghi_chu_sach = che_phi(ghi_chu)          # ① che trước
    return bedrock_agent.invoke_flow(         # ② rồi mới gọi model
        flowIdentifier=FLOW_ID,
        inputs=[{'content': {'document': {'noiDung': ghi_chu_sach,
                                          'persona': event['persona']}},
                 'nodeName': 'FlowInput'}])

Bedrock Flows cho vế persona và khả năng tiến hoá: mỗi persona là một nhánh trong flow, với prompt và bước truy xuất riêng. Thêm persona mới (ví dụ kỹ thuật viên xét nghiệm) là thêm một nhánh trong flow, không phải sửa và triển khai lại mã.

FlowInput
   ↓ Condition node: persona
   ├─ bác sĩ      → prompt chi tiết + truy xuất hướng dẫn lâm sàng
   ├─ điều dưỡng  → prompt tập trung vào chăm sóc
   └─ dược sĩ     → prompt tập trung vào tương tác thuốc
   ↓
FlowOutput (stream)

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

• D. Step Functions làm bộ điều phối trung tâm gọi Lambda che dữ liệu, Lambda dựng prompt, rồi InvokeModel; API Gateway kích hoạt workflow và trả kết quả cuối — đây là phương án gần nhất và sai ở hai chỗ: InvokeModel không stream (đề yêu cầu stream với bác sĩ đang khám bệnh), và Step Functions đứng giữa thêm độ trễ không cần thiết cho một luồng yêu cầu–phản hồi đơn giản.
• A. Microservice container trên ECS làm che PHI, định tuyến persona và gọi Bedrock, đứng sau ALB; tự viết WebSocket server trong container để stream — vi phạm yêu cầu "avoid heavy infrastructure": bạn phải quản lý cluster, task definition, auto scaling, và một WebSocket server tự viết với toàn bộ việc quản lý kết nối đi kèm.
• C. Kết nối frontend THẲNG tới Converse API, gửi ghi chú lâm sàng thô không tiền xử lý phía máy chủ, dựa vào system prompt bảo model bỏ qua trường PHI; dùng JavaScript giả lập streaming — vi phạm nghiêm trọng: gửi PHI thô tới model là đúng thứ đề cấm, system prompt không phải cơ chế bảo vệ, và frontend gọi thẳng Bedrock nghĩa là để lộ thông tin xác thực AWS ở phía client.

Ghi nhớ

Ba lựa chọn điều phối trên AWS — cách chọn: | Công cụ | Dùng khi | |---|---| | Bedrock Flows | luồng lấy GenAI làm trung tâm: prompt, điều kiện, KB, agent | | Step Functions | quy trình nghiệp vụ nhiều dịch vụ, cần vết kiểm toán chi tiết | | Lambda thuần | luồng đơn giản, ít bước |

Với ứng dụng mà phần lớn logic là chọn prompt và gọi model, Flows gọn hơn hẳn — và nó là cấu hình chứ không phải mã, nên thêm persona không cần triển khai lại.

Ba API gọi model của Bedrock: | API | Đặc điểm | |---|---| | InvokeModel | định dạng riêng từng model, không stream | | Converse | giao diện thống nhất mọi model, hỗ trợ tool use | | ConverseStream | như trên, có stream token ← cần cho câu này |

Ba lựa chọn che PHI: | Cách | Đặc điểm | |---|---| | Comprehend Medical | chuyên cho văn bản y tế — nhận diện được thuật ngữ lâm sàng | | Comprehend PII | PII chung | | Guardrails sensitive info | áp lúc gọi model — lớp phòng thủ thứ hai |

Với ghi chú lâm sàng, Comprehend Medical DetectPHI là công cụ đúng: nó nhận diện được các loại PHI riêng của y tế (mã bệnh án, tên cơ sở khám, số bảo hiểm y tế) mà bộ nhận diện PII thông thường bỏ sót.

Và nguyên tắc kiến trúc quan trọng nhất từ câu này:

Che dữ liệu nhạy cảm ở tầng gần nguồn nhất, trước khi nó đi vào bất kỳ hệ thống nào khác.

Che sau khi model đã đọc là quá muộn — và bảo model "đừng nhìn" thì không phải là cơ chế.