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

Đáp án

D — Dùng Bedrock Prompt Management tạo template có tham số, cấu hình quy trình phê duyệt theo vai trò, bật theo dõi phiên bản cho mọi thay đổi; lưu template đã duyệt vào S3 cho ứng dụng tiêu thụ.

Vì sao đúng

Đề nêu ba vấn đề đang có và ba yêu cầu tương ứng: | Vấn đề | Yêu cầu | Cơ chế | |---|---|---| | Giọng điệu không nhất quán | catalog tập trung | Prompt Management | | Trùng lặp công sức | template có tham số dùng lại được | biến trong template | | Thay đổi không kiểm soát vào production | phê duyệt theo vai trò + vết kiểm toán | version + IAM + CloudTrail |

Template có tham số là thứ giải quyết trực tiếp vấn đề trùng lặp: ba đội đang viết ba prompt gần giống nhau cho ba việc, trong khi chúng chia sẻ phần lớn cấu trúc:

Bạn là chuyên gia nhân sự của {{ten_cong_ty}}.
Giọng văn: {{giong_dieu}}.
Nhiệm vụ: {{nhiem_vu}}
Dữ liệu đầu vào: {{du_lieu}}
Trả về theo định dạng: {{dinh_dang}}

Một template, ba cách dùng — và sửa giọng điệu chung ở một chỗ thay vì ba chỗ.

Version bất biến cho vế kiểm toán: mỗi version tạo ra là không sửa được, nên bạn luôn biết chính xác production đang chạy prompt nào:

bedrock_runtime.converse(
    modelId='arn:aws:bedrock:...:prompt/PROMPT_ID:7',   # khoá vào version 7
    promptVariables={'giong_dieu': {'text': 'trang trọng'}})

Và vế lưu template đã duyệt vào S3 là chi tiết thực dụng: nó cho ứng dụng một nơi đọc ổn định, tách khỏi việc đội nào đang soạn thảo bản nháp nào.

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

• C. Prompt Management lưu template và để các đội tự động cập nhật version khi phát hiện thay đổi; dùng CloudWatch ghi lại version nào đang chạy production — đây là phương án gần nhất và sai ở chỗ quan trọng: "tự động cập nhật khi có thay đổi" là bỏ mất cửa phê duyệt — đúng thứ đề nói đang gây ra vấn đề ("uncontrolled changes moving into production").
• A. Lưu template trên S3, dùng IAM kiểm soát ai được sửa, CloudTrail theo dõi truy cập, Lambda kiểm tra cấu trúc — tự dựng lại mọi thứ: không có khái niệm version của prompt (chỉ có object version của S3), không có tham số, và bạn phải tự viết logic phê duyệt.
• B. DynamoDB lưu template, Step Functions duyệt hoặc từ chối cập nhật, CloudWatch Logs làm lịch sử — cùng vấn đề, và CloudWatch Logs là nơi tệ để lưu lịch sử phiên bản: nó có retention, khó truy vấn theo version, và không phải nguồn sự thật.

Ghi nhớ

Bốn tính năng của Bedrock Prompt Management: | Tính năng | Chi tiết | |---|---| | Template có biến | {{ten_bien}} — tái dùng cho nhiều ngữ cảnh | | Version bất biến | tạo rồi không sửa được | | Gắn cấu hình model | version lưu cả modelId, temperature, maxTokens | | Tích hợp Flows và Agents | prompt dùng lại trong workflow |

Dòng thứ ba đáng nhớ: một version prompt không chỉ là văn bản — đổi temperature cũng là đổi hành vi, và nó được ghi lại cùng.

Ba lớp kiểm soát cần ghép để có quản trị đầy đủ: | Lớp | Công cụ | |---|---| | Ai được tạo version | IAM — chỉ role được phép gọi create_prompt_version | | Ai đã đổi gì, khi nào | CloudTrail | | Production đang dùng version nào | ARN có số version trong cấu hình ứng dụng |

Ghi chú về chất lượng câu hỏi. Đáp án nói Prompt Management dùng để "configure role based approval workflows". Trên thực tế, dịch vụ này cung cấp version bất biến, bản nháp và vết kiểm toán — nhưng không có màn hình quy trình phê duyệt nhiều bước dựng sẵn. Quy trình phê duyệt theo vai trò thường được ghép bằng IAM (tách quyền tạo bản nháp và quyền tạo version) cộng với một bước xét duyệt bên ngoài. D vẫn đúng nhất trong bốn phương án — nó đúng về nền tảng và là lựa chọn ít công sức nhất — nhưng đừng hiểu thành "bật một công tắc là có workflow duyệt". Cùng cách hiểu này áp cho #6390 và #6417 trong bộ đề.

Và một mẹo thực dụng: đặt quy ước đặt tên cho prompt ngay từ đầu (hr-mo-ta-cong-viec, hr-cau-hoi-phong-van). Với vài chục prompt dùng chung giữa nhiều đội, việc tìm lại đúng cái mình cần là vấn đề thật — và Prompt Management không có thư mục.

Đáp án

B — Cấp phát một agent bằng Bedrock Agents và khai action group gọi các Lambda bọc API đơn hàng và CRM nội bộ; phơi agent qua API Gateway để trợ lý giữ được ngữ cảnh hội thoại và phản hồi thời gian thực.

Vì sao đúng

Đề nêu bốn yêu cầu, và Bedrock Agents đáp ứng cả bốn mà không phải tự viết: | Yêu cầu | Cơ chế | |---|---| | Trả lời câu hỏi tự nhiên | foundation model | | Gọi API nội bộ lấy trạng thái đơn, điều kiện hoàn tiền | action group → Lambda | | Kích hoạt workflow cập nhật CRM | action group khác | | Giữ ngữ cảnh hội thoại | session memory dựng sẵn | | Phản hồi trong vài giây | đồng bộ, không qua tầng điều phối thừa |

Action group là cách khai công cụ cho agent — bạn mô tả API bằng OpenAPI schema, agent tự quyết định khi nào gọi cái nào:

paths:
  /don-hang/{maDon}:
    get:
      description: Lấy trạng thái đơn hàng theo mã đơn
      parameters:
        - name: maDon
          in: path
          required: true

Agent đọc mô tả này và tự suy ra rằng câu "đơn DH-123456 của tôi tới đâu rồi?" cần gọi endpoint đó với maDon=DH-123456. Bạn không viết logic ánh xạ nào.

Session memory dựng sẵn là điểm phân biệt quan trọng: agent nhớ được ngữ cảnh trong một phiên, nên câu tiếp theo "thế còn đơn kia?" vẫn hiểu được — mà bạn không phải tự quản lý lịch sử hội thoại.

Và ReAct loop bên trong agent cho phép nhiều bước: hỏi trạng thái đơn → thấy đã giao → kiểm tra điều kiện hoàn tiền → trả lời. Mỗi bước phụ thuộc kết quả bước trước, và agent tự điều phối.

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

• C. Step Functions Express cho mỗi request, kích hoạt từ API Gateway; nạp lịch sử hội thoại trong workflow và gọi Bedrock cùng API nội bộ qua Lambda; trả kết quả khi state machine xong — đây là phương án gần nhất và hoạt động được, nhưng nó tự dựng lại thứ Agents làm sẵn: bạn phải tự viết logic quyết định gọi API nào, tự quản lý bộ nhớ hội thoại, tự xử lý vòng lặp nhiều bước. Thêm độ trễ mà không thêm khả năng.
• A. Gọi Bedrock thẳng từ Lambda, tự nhét dữ liệu đơn hàng và CRM vào prompt, tự lưu và nạp lịch sử từ DynamoDB, không dùng agent hay tool orchestration nào — không có tool use: bạn phải đoán trước cần dữ liệu gì rồi nhét hết vào prompt. Với câu hỏi mở, bạn không biết trước — nên hoặc nhét quá nhiều (tốn token), hoặc thiếu.
• D. Đẩy mỗi tin nhắn vào EventBridge và khởi động Step Functions Standard fan-out; client POLL một API khác để lấy kết quả tổng hợp — kiến trúc bất đồng bộ cho một cuộc trò chuyện thời gian thực: polling phá vỡ yêu cầu "respond within a few seconds" và cho trải nghiệm rất kém trong giao diện chat.

Ghi nhớ

Bốn thành phần của một Bedrock Agent: | Thành phần | Việc | |---|---| | Foundation model | suy luận và sinh ngôn ngữ | | Instructions | vai trò và ranh giới của agent | | Action groups | công cụ agent gọi được (Lambda hoặc API) | | Knowledge bases | nguồn tri thức để trả lời có căn cứ |

Khi nào chọn Agents, khi nào chọn Step Functions: | Đặc điểm bài toán | Chọn | |---|---| | Không biết trước thứ tự các bước | Bedrock Agents | | Quy trình cố định, biết trước | Step Functions | | Cần vết kiểm toán từng bước rất chặt | Step Functions | | Hội thoại nhiều lượt, giữ ngữ cảnh | Bedrock Agents | | Cần ghép nhiều dịch vụ ngoài AI | Step Functions |

Ba tính năng của Agents đáng biết cho ứng dụng thật:

1. Agent alias và version — trỏ production vào một version cố định, thử nghiệm trên alias khác.
2. Agent trace (enableTrace=True) — xem toàn bộ chuỗi suy luận và lời gọi công cụ, cần cho gỡ lỗi và kiểm toán.
3. Session timeout điều chỉnh được — cân bằng giữa giữ ngữ cảnh và giải phóng tài nguyên.

Và hai biện pháp an toàn nên có với agent gọi API nghiệp vụ: | Biện pháp | Vì sao | |---|---| | Lambda kiểm tra quyền của người dùng thật | agent không được tự quyết ai xem được đơn nào | | Giới hạn số vòng lặp | tránh agent gọi API vô tận |

Điểm đầu quan trọng nhất và hay bị bỏ: agent chạy bằng role của nó, không bằng danh tính người dùng. Lambda trong action group phải tự kiểm tra rằng người đang chat có quyền xem đơn hàng đó — nếu không, một câu hỏi khéo léo có thể moi được đơn hàng của người khác.

Đáp án

B — Dùng Bedrock streaming API với backend WebSocket đệm 5–20 đoạn, đẩy dữ liệu khi đầy đệm hoặc hết 300 mili giây, hiển thị dần cho client; ping keep-alive mỗi 30–60 giây và logic thử lại giữa chừng tự kết nối lại, quay về chế độ trả về đầy đủ nếu stream hỏng nhiều lần.

Vì sao đúng

Đề nêu bốn yêu cầu, và B là đáp án duy nhất xử lý cả bốn — đặc biệt là vế "mạng di động không ổn định": | Yêu cầu | Cơ chế | |---|---| | Stream thời gian thực | Bedrock streaming + WebSocket | | Hiển thị mượt, có chỉ báo đang gõ | đệm có kiểm soát | | Chịu được mạng chập chờn | keep-alive ping + kết nối lại giữa chừng | | Xử lý lỗi khi đang sinh nội dung | fallback về chế độ đầy đủ |

Ba quyết định kỹ thuật đáng phân tích, và mỗi cái đều là điểm phân biệt với phương án D:

① Đệm 5–20 đoạn với timer 300 mili giây. Đẩy từng token một nghe có vẻ "thời gian thực nhất", nhưng thực tế nó tệ hơn:

Không đệm:  1 token = 1 frame WebSocket
            → hàng nghìn frame nhỏ, tốn overhead, giật trên mạng yếu

Có đệm:     gom 5–20 token hoặc chờ tối đa 300 ms rồi đẩy
            → ít frame hơn, hiển thị vẫn mượt (mắt người không phân biệt được)

Timer 300 mili giây là cái chốt: nó đảm bảo dù model sinh chậm thì cũng không đợi quá lâu.

② Keep-alive ping mỗi 30–60 giây. Thiết bị NAT và proxy di động đóng kết nối im lặng sau khoảng 60 giây không có lưu lượng. Ping định kỳ giữ đường ống mở.

③ Fallback về chế độ đầy đủ. Đây là chi tiết trưởng thành nhất của đáp án: khi stream hỏng lặp lại, hệ thống chuyển sang gọi không stream và trả về một lần — người dùng vẫn nhận được câu trả lời, chỉ là không thấy nó hiện dần. Tệ hơn một chút còn hơn không có gì.

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

• D. Bedrock streaming với WebSocket đẩy từng token NGAY không đệm, dựa vào client tự thử lại; phiên WebSocket dài với timeout tĩnh và TẮT logic fallback để tránh luồng phản hồi không nhất quán — đây là phương án gần nhất và sai ở cả ba điểm trên: không đệm gây giật trên mạng yếu, timeout tĩnh không có ping khiến kết nối chết âm thầm, và tắt fallback nghĩa là stream hỏng thì người dùng không nhận được gì cả.
• A. Gọi Bedrock đồng bộ sau API Gateway với chunked transfer encoding để GIẢ LẬP stream, dựa vào client polling phát hiện đầu ra một phần; dùng HTTP keep-alive thay cho WebSocket keep-alive — gọi đồng bộ nghĩa là chờ toàn bộ câu trả lời trước khi có gì để gửi; chunked encoding không tạo ra dữ liệu chưa tồn tại. Và polling thì trái ngược với streaming.
• **C. Dùng SQS stream từng token, client long polling để lấy; khi mất kết nối thì khởi động lại toàn bộ lời gọi model và vứt bỏ token đã stream — SQS không phải kênh streaming: nó không đảm bảo thứ tự (trừ FIFO, vốn giới hạn thông lượng), và độ trễ mỗi message quá cao cho từng token. Và vứt bỏ rồi chạy lại từ đầu là lãng phí cả token lẫn thời gian người dùng.

Ghi nhớ

Ba lựa chọn kênh streaming — cách chọn: | Kênh | Ưu | Nhược | |---|---|---| | WebSocket | hai chiều, giữ kết nối, hợp mạng di động | phải quản lý trạng thái kết nối | | Server-Sent Events / HTTP streaming | đơn giản, một chiều là đủ | kém chịu đựng mất kết nối | | Lambda Function URL (RESPONSE_STREAM) | rẻ và gọn nhất | không có tính năng của API Gateway |

Với web và mobile trên mạng chập chờn như đề mô tả, WebSocket là lựa chọn đúng dù phức tạp hơn — vì nó có cơ chế phát hiện và phục hồi kết nối.

Ba tham số cần tinh chỉnh cho streaming: | Tham số | Đánh đổi | |---|---| | Kích thước đệm | nhỏ ⇒ mượt hơn nhưng nhiều frame; lớn ⇒ giật | | Timer flush | đảm bảo không chờ quá lâu khi model chậm | | Chu kỳ ping | ngắn hơn thời gian NAT timeout (thường 60 giây) |

Và bốn tình huống lỗi cần xử lý riêng trong ứng dụng streaming: | Tình huống | Xử lý | |---|---| | Mất kết nối giữa chừng | kết nối lại, tiếp tục từ vị trí đã nhận | | Model lỗi giữa chừng | trả phần đã sinh + thông báo rõ | | Stream hỏng lặp lại | fallback sang chế độ không stream | | Client đóng ứng dụng | huỷ lời gọi model để không tốn token |

Tình huống cuối hay bị bỏ qua nhưng có ý nghĩa về chi phí: nếu người dùng đóng chat mà backend vẫn sinh nốt câu trả lời dài, bạn trả tiền cho token không ai đọc.

Đáp án

C — Huấn luyện model phân loại tuỳ chỉnh trên Amazon Comprehend cho ba ý định thẻ, khoản vay và tiết kiệm; gọi nó qua Lambda cho mỗi tin nhắn mới; dùng kết quả phân loại định tuyến sang các workflow riêng gọi đúng model Bedrock và prompt cho từng lĩnh vực sản phẩm.

Vì sao đúng

Đề nêu rõ hai điều: đội đang chuyển từ định tuyến theo từ khoá sang phân loại ý định bằng máy học, và mỗi ý định phải đi tới workflow riêng gọi model Bedrock và prompt khác nhau.

Comprehend custom classification là công cụ đúng: bạn huấn luyện bằng ví dụ có nhãn, không phải viết luật:

"thẻ của tôi bị trừ tiền hai lần",              tranh-chap-the
"tôi muốn khiếu nại một giao dịch lạ",           tranh-chap-the
"lãi suất vay mua nhà hiện tại bao nhiêu",       vay-von
"kiểm tra số dư tài khoản tiết kiệm giúp tôi",   tiet-kiem

ket_qua = comprehend.classify_document(
    EndpointArn=ENDPOINT_ARN, Text=tin_nhan)
y_dinh = ket_qua['Classes'][0]['Name']
diem  = ket_qua['Classes'][0]['Score']

Nó bắt được thứ mà từ khoá không bắt được: câu "tại sao tài khoản của tôi bị trừ mà tôi không mua gì" không có từ "thẻ" nhưng rõ ràng là tranh chấp thẻ.

Và luồng đồng bộ trong đáp án là điểm phân biệt với B:

Tin nhắn → Lambda → Comprehend (phân loại) → định tuyến ngay
                                              ├─ workflow thẻ    → model + prompt A
                                              ├─ workflow vay    → model + prompt B
                                              └─ workflow tiết kiệm → model + prompt C

Một đường thẳng, không có bước trung gian nào làm chậm.

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

• B. Huấn luyện model Comprehend, nhưng Lambda ghi kết quả phân loại vào một bảng DynamoDB dùng chung; các microservice thẻ, vay, tiết kiệm POLL bảng đó và tự gọi model của mình khi thấy ý định khớp — đây là phương án gần nhất và sai ở kiến trúc: polling thêm độ trễ cho một luồng cần trả lời ngay, và ba service cùng poll một bảng là mẫu kém hiệu quả (tốn read capacity, và cần cơ chế tránh xử lý trùng). Đề nói rõ mục tiêu là "detect intent as early as possible" rồi định tuyến.
• A. Lưu ánh xạ từ khoá → ý định trong DynamoDB, Lambda quét tin nhắn tìm từ khớp, định tuyến theo từ khoá khớp đầu tiên — chính là thứ đề nói muốn bỏ: "move away from simple keyword based routing". Và "first keyword match" rất mong manh — một tin nhắn nhắc cả "thẻ" lẫn "vay" sẽ được định tuyến theo thứ tự tình cờ.
• D. Dùng Amazon Lex với ba bot riêng và bắt người dùng tự chọn bot đầu cuộc trò chuyện — đẩy việc phân loại cho người dùng, trái hẳn mục tiêu tự động nhận diện ý định. Và nó cho trải nghiệm kém: khách hàng thường không biết vấn đề của mình thuộc nhóm nào. (Lex có thể phân loại ý định tốt, nhưng phương án này dùng nó sai cách.)

Ghi nhớ

Ba cách phân loại ý định, theo độ mạnh tăng dần: | Cách | Ưu | Nhược | |---|---|---| | Từ khoá | đơn giản, rẻ | không hiểu diễn đạt khác, không xử lý mơ hồ | | Comprehend custom classification | học từ ví dụ, chính xác, rẻ | cần dữ liệu có nhãn, phải huấn luyện lại khi thêm ý định | | LLM phân loại | không cần huấn luyện, linh hoạt nhất | đắt hơn và chậm hơn cho mỗi tin nhắn |

Cách chọn giữa hai cách sau: | Tình huống | Chọn | |---|---| | Số ý định cố định, khối lượng lớn | Comprehend — rẻ hơn nhiều ở quy mô | | Ý định thay đổi thường xuyên, khối lượng nhỏ | LLM | | Cần độ trễ rất thấp | Comprehend |

Với ngân hàng xử lý hàng nghìn tin nhắn mỗi giờ và ba danh mục ổn định, Comprehend là lựa chọn đúng về cả chi phí lẫn độ trễ.

Ba lưu ý khi triển khai custom classification:

1. Cần ít nhất 10 ví dụ mỗi nhãn (thực tế nên vài trăm để có chất lượng tốt).
2. Endpoint tính tiền theo thời gian chạy, không theo lời gọi — nên hợp với lưu lượng liên tục, không hợp với dùng thưa.
3. Luôn xử lý trường hợp điểm tin cậy thấp — dưới ngưỡng thì chuyển sang luồng chung hoặc hỏi lại người dùng, thay vì đoán bừa.

Điểm thứ ba quan trọng nhất trong nghiệp vụ ngân hàng: định tuyến sai một tranh chấp thẻ sang luồng tiết kiệm khiến khách hàng phải kể lại từ đầu — và với một khiếu nại về giao dịch lạ, sự chậm trễ đó có hậu quả thật.

Đáp án

B — Cấu hình Bedrock Knowledge Base tự động chia đoạn tài liệu nguồn, sinh embedding và lưu vector vào vector index được quản lý hoàn toàn; dùng metadata phân cấp và cấu hình source table để tổ chức tài liệu theo ngành và ngành con.

Vì sao đúng

Đề nêu năm yêu cầu, và cụm quyết định nằm ở cuối: "without requiring the team to manage vector indexes, clusters, or infrastructure".

Knowledge Bases lo trọn chuỗi mà nếu tự dựng sẽ tốn rất nhiều công:

Tài liệu trên S3
    ↓ tự động: chia đoạn theo chiến lược đã cấu hình
    ↓ tự động: sinh embedding
    ↓ tự động: nạp vào vector store được quản lý
    ↓ tự động: đồng bộ khi tài liệu thay đổi
Truy vấn → retrieve → (tuỳ chọn) rerank → citation

Và metadata phân cấp đáp ứng vế tổ chức theo ngành và ngành con:

{"metadataAttributes": {
  "nganh": "cong-nghe",
  "nganh_con": "ban-dan",
  "ngay_bao_cao": "2026-07-15"}}

Rồi lọc lúc truy vấn:

retrievalConfiguration={'vectorSearchConfiguration': {
    'filter': {'andAll': [
        {'equals': {'key': 'nganh', 'value': 'cong-nghe'}},
        {'greaterThan': {'key': 'ngay_bao_cao', 'value': '2026-01-01'}}]}}}

Vế "frequently updated as market conditions change" cũng được lo: Knowledge Bases có job đồng bộ gia tăng — chỉ xử lý tài liệu mới và tài liệu đã đổi.

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

• A. OpenSearch Service với Neural Search plugin, cấu hình lưu embedding và bật hybrid search; tự dựng pipeline chia đoạn và tự bảo trì vector index khi nội dung tăng — đây là phương án gần nhất về mặt năng lực (Neural Search rất mạnh và cho hybrid search), nhưng nó vi phạm thẳng yêu cầu "fully managed": cụm "build custom pipelines" và "maintain vector indexes" là chính thứ đề muốn tránh.
• **C. Glue tiền xử lý và chia đoạn, lưu S3, chạy Athena lọc theo metadata; workflow sinh embedding riêng và vector index bên ngoài do đội tự quản lý — tự dựng toàn bộ, còn xa yêu cầu hơn cả A.
• D. RDS PostgreSQL với pgvector lưu metadata, báo cáo đầy đủ trên S3; tự viết ETL chia đoạn và bảo trì embedding trong RDS — cùng vấn đề, cộng thêm việc phải quản lý cả instance RDS (scaling, backup, vá lỗi).

Ghi nhớ

Bốn chiến lược chunking của Bedrock Knowledge Bases: | Chiến lược | Hợp với | |---|---| | Fixed-size | tài liệu ngắn, đồng nhất | | Semantic | văn bản tự do | | Hierarchical | tài liệu dài có cấu trúc chương mục | | None | tài liệu đã được chia sẵn ở bên ngoài |

Các vector store Knowledge Bases hỗ trợ: | Vector store | Ghi chú | |---|---| | OpenSearch Serverless | mặc định, không phải quản lý gì | | Aurora PostgreSQL (pgvector) | hợp khi đã có Aurora | | Neptune Analytics | hỗ trợ GraphRAG | | Pinecone, MongoDB Atlas, Redis | bên thứ ba |

Dòng đầu quan trọng cho câu này: chọn "Quick create a new vector store" thì Knowledge Bases tự tạo và quản lý collection OpenSearch Serverless — đó là nghĩa của "fully managed".

Khi nào KHÔNG dùng Knowledge Bases mà tự dựng: | Tình huống | Lý do | |---|---| | Cần kiểm soát chi tiết thuật toán ANN | KB không cho chỉnh ef_search, m | | Logic truy xuất rất đặc thù | ví dụ nhiều tầng lọc phức tạp riêng | | Đã có OpenSearch với hybrid search tinh chỉnh sâu | không muốn làm lại |

Với đề này, không có yêu cầu nào thuộc ba loại trên — nên KB là lựa chọn đúng.

Và ba tính năng của Knowledge Bases đáng biết thêm:

1. Managed reranking — cải thiện thứ hạng top-K mà không tự dựng.
2. Citation tự động — mỗi đoạn câu trả lời kèm nguồn, quan trọng với báo cáo tài chính.
3. numberOfResults và overrideSearchType — chỉnh được HYBRID hay SEMANTIC ngay trong lời gọi truy vấn.

Điểm thứ ba hữu ích cho tìm kiếm báo cáo tài chính: hybrid search bắt được mã chứng khoán và tên công ty — thứ mà embedding thuần hay bỏ sót vì chúng là từ hiếm.

Đáp án

D — Dùng Amazon Bedrock Model Evaluation tự động chấm điểm nhiều model ứng viên trên một tập dữ liệu đánh giá đã được tuyển chọn.

Vì sao đúng

Đề nêu ba yêu cầu, và tất cả đều chỉ về một cơ chế đánh giá tự động, nhất quán, lặp lại được:

1. Áp chỉ số có kiểm soát
2. So sánh nhiều ứng viên cạnh nhau
3. Cho ra điểm số định lượng để ra quyết định

Bedrock Model Evaluation là dịch vụ dựng riêng cho việc này:

bedrock.create_evaluation_job(
    jobName='danh-gia-model-phap-ly-q3',
    evaluationConfig={'automated': {'datasetMetricConfigs': [{
        'taskType': 'QuestionAndAnswer',
        'dataset': {'name': 'bo-danh-gia-hop-dong',
                    'datasetLocation': {'s3Uri': 's3://.../eval.jsonl'}},
        'metricNames': ['Accuracy', 'Robustness', 'Toxicity']}]}},
    inferenceConfig={'models': [{'bedrockModel': {'modelIdentifier': MODEL_A}}]})

Ba chỉ số trong ví dụ khớp đúng ba tiêu chí đề nêu: | Đề yêu cầu | Chỉ số | |---|---| | Accuracy | Accuracy — độ đúng so với đáp án chuẩn | | Robustness | Robustness — kết quả có ổn định khi diễn đạt đầu vào thay đổi không | | Reasoning quality | đánh giá bằng LLM-as-a-judge hoặc người chấm |

Chỉ số Robustness đáng nói riêng vì nó ít được biết tới: nó đo xem model có cho kết quả nhất quán khi câu hỏi được viết lại theo cách khác — chính là "robustness" mà đề nêu, và là thứ rất quan trọng khi model phục vụ người dùng thật vốn không hỏi theo một khuôn.

Và vế "consistent and repeatable evaluation cycle" được đáp ứng vì cùng một tập dữ liệu, cùng bộ chỉ số áp cho mọi ứng viên — nên điểm số so sánh được với nhau và với các lần đánh giá trước.

(Đáp án D viết rất ngắn so với ba phương án còn lại. Đây không phải dấu hiệu nó sai — trong đề thi AWS, phương án đúng đôi khi ngắn vì nó gọi tên đúng dịch vụ được thiết kế cho bài toán, trong khi các phương án sai phải mô tả dài dòng một giải pháp tự dựng.)

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

• A. Quy trình người xem xét nội bộ với chuyên gia lĩnh vực chấm điểm đầu ra; lưu phản hồi có cấu trúc và tính điểm tổng hợp trước khi duyệt — đây là phương án đáng bàn vì người chấm cho chất lượng cao nhất, nhưng nó không đáp ứng "automated mechanism" mà đề yêu cầu, và không lặp lại được ở quy mô: mỗi lần có model mới lại phải huy động chuyên gia. (Cách đúng là dùng người chấm để hiệu chỉnh hệ thống tự động, không thay thế nó — và Bedrock Model Evaluation có sẵn chế độ human evaluation cho việc này.)
• B. Dùng CloudWatch Logs, nhúng metadata đánh giá vào log suy luận để kỹ sư so sánh THỦ CÔNG; sinh báo cáo hằng đêm từ log tổng hợp — không có chỉ số có kiểm soát nào: log ghi lại những gì đã xảy ra trong sản xuất, không phải kết quả trên một tập đánh giá chuẩn. Và "manually compare" trái yêu cầu tự động.
• C. A/B test chạy bằng Lambda chia traffic giữa các ứng viên và thu phản hồi người dùng lúc chạy để tính chỉ số — A/B test là công cụ tốt nhưng sai giai đoạn: đề nói model chỉ được duyệt SAU KHI qua chu trình đánh giá — tức là trước khi cho tiếp xúc người dùng thật. Đưa model chưa đánh giá vào phục vụ khách hàng của một nền tảng pháp lý là rủi ro không cần thiết.

Ghi nhớ

Hai chế độ của Bedrock Model Evaluation: | Chế độ | Cách chấm | Dùng khi | |---|---|---| | Automatic | chỉ số dựng sẵn trên tập dữ liệu | so sánh nhanh, lặp lại được | | Human | người chấm theo rubric bạn khai | tiêu chí chủ quan, làm chuẩn hiệu chỉnh | | LLM-as-a-judge | model chấm theo rubric | cân bằng giữa hai cái trên |

Bốn chỉ số tự động chính: | Chỉ số | Đo gì | |---|---| | Accuracy | đúng so với đáp án chuẩn | | Robustness | ổn định khi đầu vào được viết lại | | Toxicity | nội dung độc hại | | Semantic robustness | tương tự robustness, ở mức ngữ nghĩa |

Ba nguyên tắc khi xây tập dữ liệu đánh giá: | Nguyên tắc | Chi tiết | |---|---| | Đại diện cho dữ liệu thật | không chỉ ca dễ | | Có ca biên và ca hiếm | đó là chỗ model khác nhau nhiều nhất | | Tách khỏi dữ liệu dùng để chỉnh prompt | nếu không, điểm số bị thổi phồng |

Và một điểm quan trọng về quy trình: đánh giá tự động không thay thế được người, nhưng nó thay đổi vai trò của người — thay vì chấm hàng nghìn đầu ra, chuyên gia chỉ chấm một mẫu nhỏ để hiệu chỉnh hệ thống tự động, rồi hệ thống lo phần còn lại. Đó là cách kết hợp đúng của phương án A và D, và cũng là lý do Bedrock Model Evaluation có sẵn cả hai chế độ.

Đáp án

C — Gom chỉ số quản trị từ SageMaker Model Monitor, Clarify, lineage API và Bedrock Guardrails vào CloudWatch, đẩy về một tài khoản trung tâm bằng cross-account metrics; dùng Glue ETL theo lịch chuẩn bị dữ liệu trên S3 và trực quan hoá báo cáo tuân thủ hằng tháng bằng QuickSight.

Vì sao đúng

Đề nêu ba yêu cầu, và cụm quyết định là "without assembling data manually from many teams": | Yêu cầu | Cơ chế | |---|---| | Gom dữ liệu từ nhiều Region và nhiều đơn vị | cross-account metrics về tài khoản trung tâm | | Nhiều loại chỉ số quản trị | bốn nguồn: Model Monitor, Clarify, lineage, Guardrails | | Báo cáo tự động, tiêu thụ được | Glue ETL + QuickSight |

Kiến trúc bốn tầng, mỗi tầng có lý do tồn tại:

① Thu thập  — Model Monitor (drift), Clarify (bias),
              lineage API (dòng dõi), Guardrails (số lần chặn)
        ↓
② Tập trung — CloudWatch cross-account metrics
        ↓
③ Chuẩn hoá — Glue ETL theo lịch → S3 (định dạng phân tích được)
        ↓
④ Trình bày — QuickSight dashboard, làm mới tự động

Tầng ③ là điểm phân biệt quan trọng nhất so với phương án B. CloudWatch là kho chuỗi thời gian, không phải kho phân tích. Muốn trả lời "tỷ lệ phủ model card theo đơn vị kinh doanh, so với quý trước" thì cần dữ liệu đã chuẩn hoá thành bảng — và đó là việc của Glue:

CloudWatch (chuỗi thời gian, theo Region)
    ↓ Glue ETL: gộp, chuẩn hoá đơn vị, gắn nhãn đơn vị kinh doanh
S3 (Parquet, phân vùng theo tháng và đơn vị)
    ↓ QuickSight đọc trực tiếp, nhanh và rẻ

Và cross-account metrics giải quyết đúng vấn đề "nhiều Region và nhiều đơn vị kinh doanh": mỗi đơn vị chạy ở tài khoản riêng, chỉ số được đẩy về một chỗ mà không ai phải gửi bảng tính đi.

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

• B. Gom chỉ số vào CloudWatch, nhưng giữ RAW LOG thẳng trên S3 không ETL, không chuẩn hoá; QuickSight truy vấn log thô và người xem tự làm mới mỗi tháng — đây là phương án gần nhất và sai ở đúng tầng ③: log thô từ nhiều nguồn có định dạng khác nhau, QuickSight sẽ rất chậm và các chỉ số không so sánh được với nhau. Và "refresh manually each month" trái yêu cầu tự động.
• A. Xuất log giám sát từ mỗi Region ra S3 và bắt chuyên viên tuân thủ tự chạy truy vấn Athena để dựng dashboard; CloudWatch Alarm báo khi có file log mới — hoàn toàn thủ công: "run Athena queries on demand" và "so they know when to refresh" đều là công việc tay. Đây là mô tả tình trạng hiện tại, không phải giải pháp.
• D. Lưu lineage, model card và chỉ số bias vào DynamoDB riêng cho từng đơn vị kinh doanh, Lambda hằng tuần đẩy snapshot sang bucket báo cáo; kiểm toán viên tự tải về và tự tổng hợp — giữ nguyên sự phân mảnh (mỗi đơn vị một bảng), và "download and compile manually" là chính thứ đề muốn loại bỏ.

Ghi nhớ

Bốn nguồn chỉ số quản trị AI trên AWS: | Nguồn | Cung cấp | |---|---| | SageMaker Model Monitor | data drift, model quality drift | | SageMaker Clarify | chỉ số thiên lệch, giải thích được (explainability) | | SageMaker lineage API | dòng dõi: model này từ dữ liệu nào, tham số nào | | Bedrock Guardrails metrics | số lần chặn theo từng chính sách |

Kiến trúc báo cáo tuân thủ chuẩn — bốn tầng, đừng bỏ tầng nào:

Thu thập → Tập trung → Chuẩn hoá (ETL) → Trình bày

Bỏ tầng chuẩn hoá là lỗi phổ biến nhất, và triệu chứng luôn giống nhau: dashboard chạy chậm, số liệu giữa các nguồn không khớp, và không ai tin vào báo cáo.

Hai cách tập trung chỉ số qua nhiều tài khoản: | Cách | Đặc điểm | |---|---| | CloudWatch cross-account observability | cấu hình một lần, xem chỉ số và log của nhiều tài khoản | | Metric stream → Kinesis Firehose → S3 | luồng liên tục, hợp với khối lượng lớn |

Cách thứ hai đáng cân nhắc khi số lượng chỉ số rất lớn — nó đẩy thẳng ra S3 mà không qua giới hạn API của CloudWatch.

Và ba chỉ số quản trị mà uỷ ban thường hỏi tới, nên chuẩn bị sẵn: | Chỉ số | Ý nghĩa | |---|---| | Tỷ lệ phủ model card | bao nhiêu % model đang chạy có tài liệu đầy đủ | | Số sự cố drift chưa xử lý | có bao nhiêu cảnh báo còn treo | | Tỷ lệ guardrail chặn theo loại | tăng đột biến ở một loại là dấu hiệu có vấn đề |

Dòng cuối hữu ích bất ngờ: nếu tỷ lệ chặn "denied topics" tăng vọt ở một đơn vị, thường là ai đó vừa đổi prompt hoặc vừa mở một tính năng mới — và uỷ ban muốn biết chuyện đó trước khi nó thành sự cố.

Đáp án

A — Dùng API Gateway và Lambda định tuyến ngẫu nhiên khoảng 5–10% request sang model ứng viên, phần còn lại sang model hiện tại, theo cấu hình chia traffic lưu trong AppConfig; gắn nhãn model cho từng request và ghi chỉ số chuyển đổi, độ trễ, chất lượng theo từng model vào CloudWatch và DynamoDB; logic ensemble chạy trong Lambda, bật tắt được mà không triển khai lại.

Vì sao đúng

Đề nêu ba yêu cầu, và A là đáp án duy nhất có đủ: | Yêu cầu | Cơ chế | |---|---| | Gửi một phần nhỏ traffic sang model ứng viên | chia traffic theo cấu hình AppConfig | | Theo dõi chỉ số CHI TIẾT cho TỪNG model | gắn nhãn model ID vào mọi bản ghi | | Tuỳ chọn kết hợp đầu ra bằng ensemble | logic ensemble trong Lambda, bật tắt được |

Gắn nhãn model ID là điểm phân biệt then chốt so với phương án C. Không có nhãn thì chỉ số hoàn toàn vô dụng:

cloudwatch.put_metric_data(
    Namespace='GenAI/ThuNghiem',
    MetricData=[{'MetricName': 'TyLeChuyenDoi', 'Value': gia_tri,
                 'Dimensions': [{'Name': 'ModelId', 'Value': model_da_chon}]}])

Với dimension ModelId, bạn so được hai model. Không có nó, bạn chỉ có một con số trộn lẫn — và không thể tách ra sau này.

AppConfig cho vế điều chỉnh không cần triển khai lại: đổi từ 5% sang 20% là sửa cấu hình, không phải sửa mã. Và AppConfig có rollout dần cùng auto rollback theo alarm — nên nếu model ứng viên làm tỷ lệ chuyển đổi tụt, hệ thống tự quay lại.

Chia traffic ở tầng ứng dụng (chứ không ở DNS) cho hai lợi ích quan trọng: | Lợi ích | Chi tiết | |---|---| | Chia chính xác theo % request | DNS chỉ chia theo phân giải, không theo request | | Gắn được ngữ cảnh người dùng | có thể giữ một người dùng luôn ở cùng nhánh (sticky) |

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

• **C. API Gateway với Lambda authorizer đọc feature flag từ AppConfig và GỌI CẢ HAI model ở MỌI request, trả đầu ra của model ứng viên cho client, lưu đầu ra model chính chỉ để phân tích offline; gộp mọi chỉ số vào MỘT namespace KHÔNG kèm model ID để đơn giản hoá báo cáo — đây là phương án gần nhất và sai ở hai chỗ nghiêm trọng: bỏ model ID khỏi chỉ số là làm cho việc so sánh trở thành bất khả thi, và gọi cả hai model ở mọi request là trả gấp đôi tiền trong khi chỉ dùng một kết quả. Cộng thêm: nó gửi 100% người dùng sang model ứng viên, không phải 5–10%.
• B. Route 53 weighted routing gửi 10% sang endpoint riêng của model ứng viên, không có logic định tuyến trong ứng dụng; dựa vào chỉ số tổng hợp ở mức endpoint và so sánh thủ công — DNS weighted routing không chia chính xác theo request (nó chia theo lượt phân giải DNS, và client cache kết quả), nên tỷ lệ thực tế lệch khỏi 10%. Và chỉ số ở mức endpoint không gắn được với hành vi từng người dùng.
• D. Chuyển TOÀN BỘ traffic sang model ứng viên trong kỳ thử nghiệm, gọi model cũ theo lô offline để so sánh — không phải A/B test: không có nhóm đối chứng chạy đồng thời, nên mọi khác biệt có thể do thời điểm (mùa vụ, khuyến mãi) chứ không do model. Và đưa 100% khách hàng sang model chưa kiểm chứng là rủi ro không cần thiết.

Ghi nhớ

Ba tầng có thể chia traffic — và vì sao tầng ứng dụng thường đúng nhất: | Tầng | Độ chính xác | Gắn ngữ cảnh người dùng | |---|---|---| | DNS (Route 53 weighted) | thấp — cache DNS làm lệch | ❌ | | Load balancer | vừa | hạn chế | | Ứng dụng (Lambda) | chính xác theo request | ✅ đầy đủ |

Ba nguyên tắc bắt buộc của một A/B test đáng tin: | Nguyên tắc | Vì sao | |---|---| | Chạy đồng thời | loại bỏ ảnh hưởng của thời điểm | | Gắn nhãn mọi quan sát | không gắn thì không tách được, và không sửa được sau | | Chạy đủ lâu để có ý nghĩa thống kê | kết luận sớm từ mẫu nhỏ thường sai |

Nguyên tắc thứ hai đáng nhấn mạnh vì phương án C vi phạm nó một cách "hợp lý nghe được": bỏ dimension để "đơn giản hoá báo cáo" nghe như tối ưu, nhưng nó phá huỷ dữ liệu không khôi phục được.

Ba chỉ số nên thu cho mỗi nhánh: | Chỉ số | Loại | |---|---| | Tỷ lệ chuyển đổi | chỉ số nghiệp vụ — quan trọng nhất | | Độ trễ p50/p99 | trải nghiệm | | Chi phí mỗi request | vận hành |

Và một mẹo thiết kế: giữ người dùng ở cùng một nhánh trong suốt phiên (sticky assignment theo hash của user ID). Nếu một người lúc thấy model A lúc thấy model B, trải nghiệm không nhất quán và chỉ số chuyển đổi bị nhiễu.

Cuối cùng, CloudWatch Evidently đáng biết như một lựa chọn thay thế: nó quản lý việc chia nhóm, tính ý nghĩa thống kê, và tự dừng thử nghiệm khi có kết luận — bớt được phần lớn mã tự viết.

Đáp án

C — Dùng Bedrock Prompt Management dựng template có tham số ép đầu vào có cấu trúc, khai đầu ra theo JSON Schema, và kèm chỉ dẫn suy luận từng bước; thu điểm phản hồi người dùng vào DynamoDB và dùng quy trình xem xét có kiểm soát để tinh chỉnh prompt dựa trên số liệu sử dụng.

Vì sao đúng

Đề liệt kê bốn việc muốn làm, và C là đáp án duy nhất làm đủ: | Việc | Cơ chế | |---|---| | Ép trường đầu vào có cấu trúc | template có tham số | | Ép JSON schema cho đầu ra | khai schema trong template | | Chain-of-thought | chỉ dẫn suy luận trong prompt | | Thu điểm phản hồi để tinh chỉnh | DynamoDB + quy trình xem xét |

Ba việc đầu nằm gọn trong một template:

Bạn là chuyên gia phân tích dữ liệu kinh doanh.

Câu hỏi: {{cau_hoi}}
Phạm vi dữ liệu: {{pham_vi}}
Mức chi tiết: {{muc_chi_tiet}}

Hãy suy luận TỪNG BƯỚC trước khi kết luận.

Trả về JSON:
{
  "cac_buoc_suy_luan": [{"buoc": 1, "noi_dung": "..."}],
  "phat_hien_chinh": [...],
  "khuyen_nghi": "...",
  "do_tin_cay": 0.0
}

Ba trường đầu vào thay cho "free form query" — đó chính là "enforcing structured input fields" mà đề nêu, và nó là thứ trực tiếp làm giảm biến động chất lượng.

Vế thứ tư là điểm phân biệt với phương án B: đáp án C dùng quy trình xem xét có kiểm soát để quyết định có sửa prompt hay không, dựa trên số liệu sử dụng — chứ không tự động đẩy phiên bản mới.

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

• B. Prompt Management lưu template và áp định nghĩa vai trò, DynamoDB lưu đầu vào đầu ra; thu điểm phản hồi và TỰ ĐỘNG cập nhật template qua workflow hướng sự kiện, tạo version mới KHÔNG cần phê duyệt — đây là phương án gần nhất và sai ở đúng vế cuối: tự động đổi prompt theo điểm phản hồi là rất nguy hiểm. Điểm phản hồi nhiễu, thiên lệch theo nhóm người dùng, và có thể bị thao túng — để nó điều khiển trực tiếp prompt production là mở cửa cho vòng lặp phản hồi xấu. Và nó thiếu hẳn vế JSON schema và chain-of-thought mà đề nêu rõ.
• A. Dùng Comprehend phân loại câu hỏi thành trường có cấu trúc, CloudWatch Logs lưu phản hồi; đặt chỉ dẫn chain-of-thought TRONG MÃ ỨNG DỤNG thay vì trong template — để logic prompt trong mã là mất khả năng đánh version và tinh chỉnh mà đề đang muốn xây. Và Comprehend phân loại được ý định nhưng không ép được cấu trúc đầu vào như template có tham số.
• D. Dùng Guardrails ép định dạng JSON và chain-of-thought; lưu trường đầu vào trong SQS và xử lý điểm phản hồi qua Step Functions — Guardrails không làm việc đó: nó là cơ chế an toàn nội dung (chặn độc hại, PII, chủ đề cấm), không ép được định dạng đầu ra hay cách suy luận. Và SQS là hàng đợi, không phải nơi lưu dữ liệu để phân tích.

Ghi nhớ

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

Với hệ thống production, nên kết hợp: khai schema trong template và dùng toolConfig để ép cứng.

Ba tầng của một vòng lặp cải tiến prompt đúng cách:

① Thu tín hiệu   → điểm phản hồi, chỉ số sử dụng, tỷ lệ sửa lại
② Phân tích      → prompt nào kém, ở dạng câu hỏi nào
③ Xem xét & sửa  → CON NGƯỜI quyết định, tạo version mới

Bước ③ không nên tự động, vì hai lý do: | Lý do | Chi tiết | |---|---| | Tín hiệu phản hồi nhiễu | người dùng chấm thấp vì nhiều lý do không liên quan tới prompt | | Không có cơ chế hoàn tác an toàn | prompt tự đổi có thể xấu đi mà không ai biết ngay |

Nếu vẫn muốn tự động hoá một phần, mẫu an toàn là: hệ thống tự sinh ĐỀ XUẤT prompt mới và chạy đánh giá tự động, rồi người duyệt trước khi phát hành — kết hợp tốc độ của máy với phán đoán của người.

Và một lưu ý về việc thu điểm phản hồi: lưu kèm ngữ cảnh (loại câu hỏi, phân khúc người dùng, version prompt). Một điểm 2/5 không nói lên gì; "điểm 2/5 với câu hỏi phân tích chuỗi thời gian, version prompt 4" thì có thể hành động được.

Đáp án

B — Tích hợp Comprehend PII detection làm bước TIỀN XỬ LÝ và dùng Lambda tự động che hoặc thay thế thực thể PII phát hiện được trước khi đưa văn bản đã làm sạch tới foundation model; cấu hình sao cho chỉ bản đã che mới được chuyển tiếp, đồng thời ghi metadata phát hiện phục vụ kiểm toán.

Vì sao đúng

Đề nêu hai yêu cầu bắt buộc, và cả hai đều nằm trong đáp án B: | Yêu cầu | Cơ chế | |---|---| | PII phải được xử lý TRƯỚC bước tóm tắt | Comprehend chạy tiền xử lý, chỉ bản sạch đi tiếp | | Đội phía sau kiểm toán được cách xử lý dữ liệu | ghi metadata phát hiện |

def handler(event, context):
    van_ban = event['noiDungTicket']

    phat_hien = comprehend.detect_pii_entities(Text=van_ban, LanguageCode='en')

    van_ban_sach = che_thuc_the(van_ban, phat_hien['Entities'])
    ghi_metadata_kiem_toan({                       # ← vết kiểm toán
        'ticketId': event['maTicket'],
        'so_thuc_the': len(phat_hien['Entities']),
        'loai_phat_hien': [e['Type'] for e in phat_hien['Entities']],
        'thoi_diem': thoi_gian_hien_tai
    })

    return bedrock.converse(messages=[{'role': 'user',
        'content': [{'text': f'Tóm tắt: {van_ban_sach}'}]}])

Chi tiết đáng chú ý trong đoạn trên: metadata kiểm toán ghi LOẠI và SỐ LƯỢNG thực thể, không ghi giá trị của chúng. Ghi lại chính số điện thoại vào log kiểm toán là tạo ra một bản sao dữ liệu nhạy cảm mới — đúng thứ đang cố tránh.

Và "chỉ bản đã che mới được chuyển tiếp" là điều biến quy trình thành đảm bảo: không có nhánh nào để văn bản thô đi tới model.

Một lưu ý về chất lượng đầu ra: che PII làm giảm ngữ cảnh nhưng thường không ảnh hưởng tóm tắt — bản tóm tắt cần biết "khách hàng báo lỗi thanh toán", không cần biết số thẻ. Dùng nhãn giữ chỗ có kiểu ({SO_DIEN_THOAI} thay vì [XXX]) giữ được cấu trúc câu tốt hơn.

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

• A. Comprehend phát hiện PII và gắn thẻ thực thể, nhưng GIỮ NGUYÊN văn bản gốc để model có đủ ngữ cảnh; lưu metadata che riêng và dựa vào hệ thống phía sau che sau khi model xong — đây là phương án gần nhất và vi phạm thẳng yêu cầu của lãnh đạo: "sensitive elements must be identified, transformed, or removed BEFORE the summarization step". Che sau khi model đã đọc là quá muộn — dữ liệu đã rời khỏi ranh giới.
• C. Comprehend phát hiện PII rồi gửi CẢ bản đã che lẫn bản gốc tới model để nó tự chọn bản phù hợp — vẫn gửi dữ liệu thô tới model, chỉ là kèm thêm một bản sạch. Và "để model tự chọn" nghĩa là không ai kiểm soát nó chọn gì.
• D. Dùng CloudWatch Logs Insights quét ticket đã lưu và thay giá trị nhạy cảm SAU KHI nội dung đã được model xử lý; chuyển tóm tắt đi tiếp không lọc thêm — muộn nhất trong bốn phương án, và Logs Insights là công cụ truy vấn, không phải công cụ biến đổi dữ liệu.

Ghi nhớ

Ba dịch vụ xử lý PII trên AWS — mỗi cái ở một vị trí: | Dịch vụ | Vị trí | Việc | |---|---|---| | Amazon Macie | dữ liệu nằm trong S3 | phát hiện trước khi dùng | | Comprehend PII | trong pipeline xử lý văn bản | phát hiện và che ← câu này | | Bedrock Guardrails | lúc gọi model | lớp phòng thủ thứ hai |

Cả ba nên dùng cùng nhau: Macie kiểm kê kho dữ liệu, Comprehend che trong pipeline, Guardrails bắt những gì lọt qua.

Hai API của Comprehend cho PII: | API | Trả về | |---|---| | DetectPiiEntities | vị trí và loại thực thể — bạn tự che | | ContainsPiiEntities | chỉ cho biết có hay không, rẻ hơn |

Và với dữ liệu y tế thì dùng Comprehend Medical DetectPHI — nó nhận diện được PHI đặc thù (mã bệnh án, tên cơ sở khám) mà bộ nhận diện chung bỏ sót.

Ba chiến lược che, và tác động tới chất lượng tóm tắt: | Chiến lược | Ví dụ | Giữ ngữ cảnh | |---|---|---| | Xoá hẳn | "" | thấp — câu bị gãy | | Nhãn có kiểu | {SO_DIEN_THOAI} | cao — model hiểu đó là gì | | Token nhất quán | KH_A1B2 | cao nhất — nối được các lần nhắc cùng một người |

Chiến lược thứ ba đáng dùng khi tóm tắt cần phân biệt "khách hàng" với "kỹ thuật viên" trong cùng một ticket — token nhất quán giữ được quan hệ đó mà không lộ danh tính.

Và một điểm về vết kiểm toán: nên ghi cả trường hợp KHÔNG phát hiện PII nào. Một log trống có thể nghĩa là "ticket sạch" hoặc "bước che không chạy" — và hai điều đó rất khác nhau.