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

Đáp án

A — Dùng request validation và mapping template của API Gateway để ép giới hạn kích thước đầu vào và ước lượng số token TRƯỚC KHI gọi backend; từ chối request vượt ngưỡng với thông báo lỗi rõ ràng; chỉ chuyển tiếp request đã hợp lệ.

Vì sao đúng

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

1. Bảo vệ dịch vụ downstream
2. Hành vi có thể đoán trước cho client
3. Không nhúng logic phức tạp vào mã ứng dụng

Nguyên tắc thiết kế đằng sau: chặn ở cửa ngõ, không để request hỏng đi sâu vào hệ thống.

// Request validator ở API Gateway
{
  "validateRequestBody": true,
  "validateRequestParameters": true
}

// Model ràng buộc kích thước
{
  "type": "object",
  "required": ["prompt"],
  "properties": {
    "prompt": {"type": "string", "maxLength": 20000},
    "maxTokens": {"type": "integer", "minimum": 1, "maximum": 4096}
  }
}

Request vượt ngưỡng nhận 400 ngay lập tức, kèm thông báo rõ ràng — không tốn một lời gọi model nào, và không có Lambda nào phải chạy.

Ba lợi ích cụ thể: | Lợi ích | Chi tiết | |---|---| | Bảo vệ downstream | model và Lambda không bao giờ thấy request quá lớn | | Hành vi đoán trước được | client luôn nhận cùng một mã lỗi cho cùng một vi phạm | | Không có logic trong mã | khai báo bằng JSON Schema, không phải viết hàm |

Và điều này giải quyết đúng vấn đề đề nêu: "failures cause retries at the client layer and increase overall latency" — vì client nhận lỗi rõ ràng và dứt khoát, nó không thử lại vô ích.

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

• B. API Gateway ép giới hạn payload, cộng thêm Lambda đếm token, viết lại prompt, cắt bớt nội dung, và TỰ ĐỘNG THỬ LẠI cho tới khi thành công — vi phạm thẳng yêu cầu "avoid embedding complex logic". Tệ hơn: tự động cắt bớt prompt của người dùng là hành vi không đoán trước được — người dùng nhận câu trả lời dựa trên nội dung đã bị sửa mà không biết. Và "retry until they succeed" có thể thành vòng lặp tốn kém.
• C. Chuyển mọi request xuống backend, để model trả lỗi giới hạn token, bắt lỗi ở Lambda rồi thử lại với tham số giảm — phát hiện muộn nhất có thể: mỗi request hỏng vẫn tốn một lời gọi model. Và nó giữ nguyên vấn đề độ trễ do thử lại mà đề đang than phiền.
• D. Lambda tính token sau khi request đã qua tầng API, cắt bớt động, API chấp nhận mọi request không kiểm tra — cùng vấn đề với C, cộng thêm việc cắt bớt im lặng. Cụm "without validation to maximize flexibility" đi ngược hoàn toàn mục tiêu bảo vệ.

Ghi nhớ

Các cơ chế bảo vệ của API Gateway — nên dùng theo tầng: | Cơ chế | Chặn gì | |---|---| | Request validation | body sai schema, thiếu tham số bắt buộc | | Payload size limit | request quá lớn (tối đa 10 MB) | | Throttling | request/giây và burst | | Usage plan + API key | hạn ngạch theo từng khách hàng | | WAF | request độc hại, giới hạn tần suất theo IP | | Authorizer | xác thực và uỷ quyền |

Nguyên tắc fail fast at the edge: mỗi tầng phòng thủ đặt càng gần cửa ngõ càng rẻ.

WAF          → chặn IP xấu, tấn công
Throttling   → chặn quá tải
Validation   → chặn request sai định dạng   ← câu này
Authorizer   → chặn người không có quyền
    ↓
Backend chỉ thấy request hợp lệ

Ba giới hạn của API Gateway cần biết: | Giới hạn | Giá trị | |---|---| | Payload tối đa | 10 MB (REST API) | | Timeout tích hợp | 29 giây (REST API) | | Header size | 10 KB |

Dòng timeout đáng chú ý với ứng dụng GenAI: 29 giây có thể không đủ cho câu trả lời dài — đó là một lý do nữa để dùng streaming, như đã bàn ở câu về InvokeModelWithResponseStream.

Và về ước lượng token: một quy tắc thô hữu ích là 1 token ≈ 4 ký tự tiếng Anh (tiếng Việt tốn nhiều token hơn do bảng mã). Nên maxLength: 20000 ký tự tương đương khoảng 5.000 token — đủ để đặt ngưỡng an toàn trong JSON Schema mà không cần đếm token chính xác.

Với yêu cầu chặt chẽ hơn, đặt thêm maxTokens trong request và ràng buộc nó bằng schema — vừa bảo vệ backend, vừa cho client biết rõ giới hạn.

Đáp án

A — Dùng AppConfig feature flag lưu quy tắc định tuyến ánh xạ phân khúc người dùng tới model Bedrock cụ thể, đọc cấu hình lúc chạy; dùng deployment strategy với rollout dần và CloudWatch alarm để product manager chuyển traffic an toàn không cần triển khai lại mã.

Vì sao đúng

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

1. Đổi model cho từng phân khúc người dùng, KHÔNG triển khai lại mã
2. Rollout dần — ví dụ chỉ bật cho người dùng premium trước
3. Cập nhật nhanh và an toàn
4. Điều khiển từ bên ngoài quy trình triển khai ứng dụng

Feature flag của AppConfig được thiết kế riêng cho kịch bản này:

{
  "flags": {
    "dinh_tuyen_model": {
      "name": "Định tuyến model theo phân khúc",
      "attributes": {
        "premium": {"constraints": {"type": "string"}},
        "tieu_chuan": {"constraints": {"type": "string"}}
      }
    }
  },
  "values": {
    "dinh_tuyen_model": {
      "enabled": true,
      "premium": "anthropic.claude-3-5-sonnet-20241022-v2:0",
      "tieu_chuan": "anthropic.claude-3-5-haiku-20241022-v1:0"
    }
  }
}

Ứng dụng đọc lúc chạy, không có model ID nào nằm trong mã:

co = lay_feature_flag('dinh_tuyen_model')
model_id = co[nguoi_dung.phan_khuc]
return bedrock.converse(modelId=model_id, messages=[...])

Và hai tính năng còn lại là điểm phân biệt với các phương án khác: | Tính năng | Đáp ứng yêu cầu | |---|---| | Deployment strategy | rollout dần: 10% → 50% → 100%, có bake time | | CloudWatch alarm làm điều kiện rollback | tự quay lại khi chất lượng hoặc độ trễ xấu đi |

aws appconfig start-deployment \
  --application-id abc --environment-id def \
  --configuration-profile-id ghi --configuration-version 5 \
  --deployment-strategy-id AppConfig.Canary10Percent20Minutes

Với Canary10Percent20Minutes, cấu hình mới chỉ tới 10% instance trong 20 phút — nếu alarm kêu, AppConfig tự rollback mà không cần ai can thiệp.

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

• B. Parameter Store lưu JSON quy tắc, đọc lúc chạy, nhưng cập nhật thủ công không có deployment strategy hay rollout control; ứng dụng áp dụng ngay mọi thay đổi mà không có guardrail, validation hay giám sát — đây là phương án gần nhất về cơ chế nhưng thiếu hết các lớp an toàn: một lần gõ sai model ID là 100% người dùng bị ảnh hưởng ngay lập tức, không có rollout dần và không có rollback tự động.
• C. DynamoDB lưu quy tắc, cập nhật trực tiếp, đọc ở MỖI request, bỏ qua rollout theo giai đoạn và validation — cùng vấn đề thiếu guardrail, cộng thêm việc đọc DynamoDB ở mọi request làm tăng độ trễ và chi phí.
• D. Lưu flag trong object S3, ứng dụng poll định kỳ, không dùng versioning, deployment guard hay giám sát thời gian thực — thiếu mọi lớp an toàn, và polling S3 kém hiệu quả hơn hẳn so với AppConfig extension vốn có cache thông minh.

Ba phương án sai này có điểm chung: chúng đều lưu được cấu hình bên ngoài mã (giải quyết yêu cầu 1 và 4), nhưng không có cơ chế rollout dần và rollback — tức là bỏ qua yêu cầu 2 và 3.

Ghi nhớ

So sánh khả năng của các nơi lưu cấu hình: | | AppConfig | Parameter Store | DynamoDB | S3 | |---|---|---|---|---| | Đọc lúc chạy | ✅ | ✅ | ✅ | ✅ | | Gradual rollout | ✅ | ❌ | ❌ | ❌ | | Validation | ✅ | ❌ | ❌ | ❌ | | Auto rollback theo alarm | ✅ | ❌ | ❌ | ❌ | | Feature flag dựng sẵn | ✅ | ❌ | ❌ | ❌ |

Bốn deployment strategy dựng sẵn của AppConfig: | Strategy | Hành vi | |---|---| | AppConfig.AllAtOnce | 100% ngay — chỉ dùng cho dev | | AppConfig.Linear50PercentEvery30Seconds | tăng đều, nhanh | | AppConfig.Canary10Percent20Minutes | 10% trước, theo dõi 20 phút, rồi phần còn lại | | AppConfig.Linear20PercentEvery6Minutes | chậm và thận trọng |

Ba thành phần của một feature flag an toàn: | Thành phần | Việc | |---|---| | Validator | chặn giá trị sai trước khi phát hành | | Deployment strategy | giới hạn phạm vi ảnh hưởng khi có lỗi | | CloudWatch alarm + auto rollback | tự phục hồi |

Thiếu bất kỳ thành phần nào là feature flag trở thành một cách nhanh để làm hỏng production — đó chính là điểm phân biệt giữa đáp án A và ba phương án còn lại.

Và một mẹo thực dụng: dùng AppConfig Lambda Extension hoặc Agent thay vì gọi API trực tiếp — nó cache cấu hình cục bộ và tự làm mới theo chu kỳ, nên không tốn lời gọi API ở mỗi request mà vẫn nhận được thay đổi trong vài chục giây.

Đáp án

C — Bật agent tracing trong InvokeAgent API của Bedrock và ghi toàn bộ bước suy luận, metadata truy xuất, và chi tiết gọi công cụ vào CloudWatch Logs có cấu trúc; lưu theo schema nhất quán và tích hợp với Logs Insights để kiểm toán viên tái dựng lại toàn bộ chuỗi suy luận.

Vì sao đúng

Đề yêu cầu rất cụ thể: kiểm toán viên phải thấy được mọi bước suy luận — bao gồm lời gọi truy xuất, lời gọi công cụ, điểm quyết định, và kết luận trung gian — để tái dựng lại cách một khuyến nghị được đưa ra.

Bedrock agent tracing cung cấp đúng dữ liệu đó:

response = bedrock_agent_runtime.invoke_agent(
    agentId='ABC123',
    agentAliasId='PROD',
    sessionId=session_id,
    inputText=cau_hoi,
    enableTrace=True          # ← bật tracing
)

for su_kien in response['completion']:
    if 'trace' in su_kien:
        ghi_log_co_cau_truc(su_kien['trace'])

Trace chứa các loại bước sau: | Loại trace | Nội dung | |---|---| | preProcessingTrace | agent phân tích và diễn giải câu hỏi | | orchestrationTrace | lập luận, quyết định gọi công cụ nào, kết quả nhận về | | knowledgeBaseLookupInput/Output | truy vấn gì, lấy được tài liệu nào | | invocationInput / observation | gọi API nào, tham số gì, trả về gì | | postProcessingTrace | định dạng câu trả lời cuối |

Và hai chi tiết trong đáp án làm nên khác biệt so với phương án B:

"Structured logs với schema nhất quán" — thay vì ghi văn bản tự do, ghi JSON có cấu trúc để truy vấn được:

{"sessionId": "abc", "traceType": "orchestration", "step": 3,
 "action": "knowledgeBaseLookup", "query": "điều kiện rút vốn",
 "documentsRetrieved": ["doc-123", "doc-456"], "timestamp": "..."}

Tích hợp Logs Insights — cho phép tái dựng chuỗi suy luận của một phiên cụ thể:

fields @timestamp, step, action, query
| filter sessionId = "abc-123"
| sort step asc

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

• B. Bật agent tracing nhưng chỉ ghi bản TÓM TẮT của kết quả suy luận; dùng dashboard để xem hoạt động ở mức cao — đây là phương án gần nhất và sai ở đúng chỗ quan trọng: đề yêu cầu "every reasoning step" và "reconstruct the full agent reasoning path". Tóm tắt không tái dựng được — và dashboard mức cao lại càng không.
• A. Pipeline Lambda chỉ ghi input và output của model, KHÔNG bật agent tracing; suy đoán cách agent đi tới kết luận từ log ứng dụng — thiếu chính thứ cần thiết: input và output là hai đầu, còn toàn bộ quá trình ở giữa (truy xuất, gọi công cụ, quyết định) hoàn toàn không được ghi. Cụm "infer how the agent reached its conclusions" thừa nhận điều đó.
• D. Dùng Guardrails để "ép hiển thị suy luận", gửi bản tóm tắt đã lọc sang Lambda; dùng metric đếm khi nội dung suy luận vượt ngưỡng guardrail — sai công cụ hoàn toàn: Guardrails là cơ chế AN TOÀN NỘI DUNG (chặn ngôn ngữ độc hại, chủ đề cấm, PII), nó không có tính năng nào về hiển thị suy luận. Và bản tóm tắt đã lọc lại càng ít thông tin hơn.

Ghi nhớ

Ba tầng quan sát cho Bedrock agent: | Tầng | Công cụ | Trả lời | |---|---|---| | Chi tiết suy luận | agent tracing | agent đã nghĩ gì, gọi gì, theo thứ tự nào | | Hiệu năng qua nhiều dịch vụ | X-Ray | chặng nào chậm | | Số liệu tổng hợp | CloudWatch metrics | bao nhiêu lời gọi, bao nhiêu lỗi |

Ba nguyên tắc khi thiết kế log cho mục đích kiểm toán: | Nguyên tắc | Chi tiết | |---|---| | Ghi đầy đủ, không tóm tắt | tóm tắt là mất thông tin không khôi phục được | | Schema nhất quán | truy vấn được bằng Logs Insights hoặc Athena | | Có định danh phiên | sessionId để nối các bước thành một chuỗi |

Và với ngành tài chính như đề mô tả, bổ sung ba điều:

1. Đặt retention dài cho log group — thường vài năm theo yêu cầu quản lý.
2. Mã hoá log bằng KMS và hạn chế quyền đọc — trace chứa nội dung tư vấn đầu tư.
3. Xuất log sang S3 với Object Lock — đảm bảo log không sửa được, điều mà kiểm toán viên thường yêu cầu.

Một lưu ý về chi phí và bảo mật: agent trace rất chi tiết, nên khối lượng log lớn. Cân nhắc lấy mẫu ở môi trường không quan trọng và chỉ bật đầy đủ ở production nơi cần kiểm toán — nhưng với ngành chịu quản lý, thường phải bật đầy đủ cho mọi request.

Đáp án

A — Dùng SageMaker áp dụng LoRA (low-rank adaptation) lên base model, lưu adapter weight thành artifact riêng; đăng ký từng version adapter vào SageMaker Model Registry và triển khai độc lập qua pipeline tự động; rollback bằng cách đổi version adapter mà không triển khai lại base model.

Vì sao đúng

Đề nêu năm yêu cầu, và LoRA đáp ứng cả năm:

1. Học được mẫu riêng (không chỉ nhồi ngữ cảnh)
2. Triển khai thường xuyên, rollback an toàn, có version
3. Chi phí tính toán tối thiểu
4. Nhiều biến thể tuỳ chỉnh cùng tồn tại giữa các môi trường
5. Tích hợp vào pipeline tự động có quản lý vòng đời

LoRA là kỹ thuật fine-tuning hiệu quả tham số: thay vì cập nhật hàng tỷ trọng số của model, nó huấn luyện một tập ma trận nhỏ (adapter) rồi cộng vào trọng số gốc:

Base model:  7 tỷ tham số, ~14 GB     ← KHÔNG ĐỔI
LoRA adapter: ~10 triệu tham số, ~20 MB  ← chỉ huấn luyện và triển khai phần này

Đó là lý do nó đáp ứng được cả năm yêu cầu: | Yêu cầu | Cách LoRA đáp ứng | |---|---| | Chi phí tính toán thấp | huấn luyện ~0,1% số tham số | | Triển khai thường xuyên | artifact 20 MB, không phải 14 GB | | Rollback nhanh | đổi adapter, base model giữ nguyên | | Nhiều biến thể cùng tồn tại | một base model + nhiều adapter | | Quản lý vòng đời | Model Registry đánh version từng adapter |

Dòng thứ tư đặc biệt đáng chú ý: nhiều adapter dùng chung một base model đã nạp sẵn trong GPU memory — nên chi phí hạ tầng gần như không tăng khi thêm biến thể.

from peft import LoraConfig, get_peft_model
cau_hinh = LoraConfig(r=16, lora_alpha=32, target_modules=["q_proj", "v_proj"],
                      lora_dropout=0.05, task_type="CAUSAL_LM")
model = get_peft_model(base_model, cau_hinh)
model.save_pretrained("./adapter-v3")     # chỉ lưu adapter

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

• B. Full fine-tuning model, triển khai mỗi version thành endpoint riêng, rollback bằng cách triển khai lại model đầy đủ trước đó — vi phạm yêu cầu "minimize compute cost": huấn luyện toàn bộ tham số tốn gấp hàng chục lần. Và mỗi biến thể là một endpoint riêng với model đầy đủ — trái yêu cầu "multiple variants coexist" một cách hiệu quả.
• C. Continued pre-training trên dữ liệu chưa gán nhãn rồi fine-tune tiếp — tốn kém nhất trong mọi lựa chọn: continued pre-training cần khối lượng dữ liệu và tính toán rất lớn. Nó chỉ đáng làm khi ngôn ngữ chuyên ngành khác biệt căn bản so với dữ liệu huấn luyện gốc — không phải cho việc "định dạng và thuật ngữ riêng".
• D. Dùng RAG với vector store, cập nhật embedding và tinh chỉnh tham số truy xuất — đây là phương án đáng bàn: RAG rất tốt cho việc cung cấp KIẾN THỨC, nhưng đề nói rõ vấn đề là "requires learned patterns rather than simple context injection" — tức là model cần học cách hành xử và định dạng, không phải cần thêm thông tin. RAG không thay đổi hành vi của model.

Ghi nhớ

Bậc thang tuỳ biến model — chọn theo bản chất vấn đề: | Mức | Kỹ thuật | Chi phí | Giải quyết vấn đề gì | |---|---|---|---| | 1 | Prompt engineering | rất thấp | hướng dẫn cách trả lời | | 2 | RAG | thấp | thiếu KIẾN THỨC riêng | | 3 | LoRA / PEFT | vừa | cần học HÀNH VI, định dạng, giọng điệu riêng | | 4 | Full fine-tuning | cao | như trên nhưng cần thay đổi sâu hơn | | 5 | Continued pre-training | rất cao | ngôn ngữ chuyên ngành khác biệt căn bản |

Cách phân biệt mức 2 và mức 3 — điểm mấu chốt của câu này: | Triệu chứng | Giải pháp | |---|---| | "Model không biết thông tin của công ty tôi" | RAG | | "Model biết thông tin nhưng trả lời sai định dạng, sai giọng điệu, sai cách lập luận" | fine-tuning (LoRA) |

So sánh LoRA với full fine-tuning: | | LoRA | Full fine-tuning | |---|---|---| | Tham số huấn luyện | ~0,1–1% | 100% | | Bộ nhớ GPU cần | thấp hơn nhiều | rất cao | | Kích thước artifact | vài chục MB | vài GB tới vài chục GB | | Nhiều biến thể | ✅ dùng chung base model | mỗi biến thể một model đầy đủ | | Chất lượng | gần bằng full FT cho hầu hết tác vụ | cao nhất |

Và ba công cụ AWS hỗ trợ vòng đời adapter: | Công cụ | Việc | |---|---| | SageMaker Model Registry | đánh version, phê duyệt, theo dõi dòng dõi (lineage) | | SageMaker Pipelines | tự động hoá huấn luyện, đánh giá, đăng ký | | Bedrock Custom Model Import | nạp model đã tuỳ biến vào Bedrock để dùng như model quản lý |

Dòng cuối đáng biết: sau khi huấn luyện adapter trên SageMaker, bạn nhập model đã merge vào Bedrock để hưởng hạ tầng serverless — kết hợp được ưu điểm của cả hai.

Đáp án

B — Dùng Bedrock Prompt Flows định nghĩa workflow nhiều bước áp dụng tiền xử lý chuẩn hoá cho đầu vào và hậu xử lý cho đầu ra; chạy A/B evaluation bằng cách so sánh các biến thể flow và thu thập metric tự động; dùng cấu trúc flow để đảm bảo xử lý nhất quán qua mọi lần đánh giá.

Vì sao đúng

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

1. Chuẩn hoá đầu vào trước khi suy luận, điều chỉnh đầu ra trước khi dùng
2. Tự động hoá so sánh, KHÔNG nhúng logic phức tạp vào mã ứng dụng
3. Hỗ trợ thử nghiệm có kiểm soát, so sánh các chiến lược xử lý prompt
4. Đảm bảo tiền xử lý và hậu xử lý nhất quán

Prompt Flows là công cụ điều phối trực quan trong Bedrock, cho phép ghép nhiều bước thành một workflow được quản lý:

Đầu vào
   ↓
[Node: Chuẩn hoá]     ← bỏ từ ngữ dẫn dắt, chuẩn hoá cách diễn đạt
   ↓
[Node: Prompt]        ← gọi model với prompt đã quản lý version
   ↓
[Node: Hậu xử lý]     ← chuẩn hoá giọng điệu, định dạng đầu ra
   ↓
Đầu ra

Vì sao nó khớp với yêu cầu "without embedding complex logic directly into application code": các bước tiền và hậu xử lý nằm TRONG flow, không nằm trong ứng dụng. Ứng dụng chỉ gọi flow:

bedrock_agent_runtime.invoke_flow(
    flowIdentifier='flow-abc',
    flowAliasIdentifier='production',
    inputs=[{'content': {'document': du_lieu_vao}, 'nodeName': 'FlowInput'}]
)

Và vế thử nghiệm có kiểm soát được đáp ứng bằng flow version và alias:

Flow version 1 (chiến lược A) ─┐
                               ├─ so sánh metric tự động
Flow version 2 (chiến lược B) ─┘

Vì toàn bộ chuỗi xử lý được đóng gói trong flow, hai biến thể khác nhau đúng ở điều bạn muốn thử — không có sai lệch do mã ứng dụng xử lý khác nhau. Đó chính là nghĩa của "ensure consistent handling across all evaluations".

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

• D. Dùng Prompt Flows nhưng nhúng toàn bộ logic tiền và hậu xử lý vào MÃ ỨNG DỤNG trước khi gọi flow; so sánh bằng cách bật tắt nhánh mã — vi phạm thẳng yêu cầu "without embedding complex logic directly into application code". Và "toggling code paths" nghĩa là mỗi lần thử nghiệm đều phải sửa và triển khai lại mã.
• A. Dùng Prompt Management giữ nhiều version prompt, gắn metadata, để hệ thống downstream diễn giải và điều chỉnh đầu ra; so sánh THỦ CÔNG qua các lần chạy — Prompt Management chỉ quản lý prompt, nó không có tiền/hậu xử lý và không điều phối nhiều bước. Và "correlating results manually" trái yêu cầu tự động hoá.
• C. Prompt Management đánh version prompt, tự viết chuẩn hoá và viết lại đầu ra TRONG NỘI DUNG PROMPT; ghi log ra ngoài để phân tích sau — nhét logic xử lý vào text của prompt là cách mong manh và khó kiểm chứng: model có thể không tuân thủ, và bạn không có bước hậu xử lý thực sự nào. Ghi log ra ngoài rồi phân tích sau cũng không phải "capture metrics automatically".

Ghi nhớ

Ba công cụ prompt của Bedrock — phân biệt cho rõ: | Công cụ | Việc | |---|---| | Prompt Management | lưu, đánh version, chia sẻ PROMPT | | Prompt Flows | điều phối NHIỀU BƯỚC: prompt, Lambda, điều kiện, knowledge base | | Model Evaluation | chấm điểm và so sánh, tự động hoặc có người tham gia |

Chúng bổ sung cho nhau: Prompt Management giữ các prompt, Prompt Flows ghép chúng thành quy trình, Model Evaluation chấm điểm kết quả.

Các loại node trong Prompt Flows: | Node | Việc | |---|---| | Prompt | gọi model với prompt (inline hoặc từ Prompt Management) | | Lambda | logic tuỳ ý — tiền xử lý, hậu xử lý | | Condition | rẽ nhánh theo điều kiện | | Knowledge Base | truy xuất tài liệu | | Agent | gọi Bedrock agent | | Iterator / Collector | xử lý danh sách |

Ba lợi ích của việc đặt logic trong flow thay vì trong mã: | Lợi ích | Chi tiết | |---|---| | Nhất quán | mọi lần gọi đều đi qua cùng chuỗi bước | | Có version và rollback | flow đánh version như prompt | | So sánh công bằng | hai biến thể chỉ khác ở điều bạn muốn thử |

Điểm cuối rất quan trọng với thử nghiệm về công bằng như đề mô tả: nếu tiền xử lý nằm trong mã và khác nhau giữa hai nhánh thử nghiệm, bạn không biết chênh lệch kết quả đến từ prompt hay từ mã — thử nghiệm mất giá trị.

Và với mục tiêu giảm ảnh hưởng của cách diễn đạt lên kết quả, hai kỹ thuật đáng đưa vào node tiền xử lý: chuẩn hoá cấu trúc câu hỏi (đưa về một khuôn mẫu) và loại bỏ tín hiệu ngữ cảnh không liên quan — cả hai đều làm giảm biến động không mong muốn trong đầu ra.

Đáp án

B — Phơi các vector index của từng đơn vị kinh doanh qua quyền IAM chéo tài khoản (OpenSearch Serverless hoặc Aurora pgvector hỗ trợ) và kết nối tài khoản AI platform bằng AWS PrivateLink; trợ lý Bedrock truy vấn vector theo yêu cầu trong khi dữ liệu vẫn ở tài khoản chủ sở hữu.

Vì sao đúng

Đề nêu bốn ràng buộc, và đáp án B là lựa chọn duy nhất thoả hết:

1. Truy xuất trực tiếp từ vector index ở tài khoản khác
2. KHÔNG nhân bản embedding, KHÔNG di chuyển dữ liệu
3. Giữ nghiêm ngặt ranh giới bảo mật giữa các tài khoản
4. Giảm thiểu gánh nặng vận hành

Kiến trúc gồm hai lớp bổ sung cho nhau:

Lớp quyền — IAM chéo tài khoản:

// Data access policy của OpenSearch Serverless ở tài khoản đơn vị kinh doanh
{
  "Rules": [{
    "ResourceType": "index",
    "Resource": ["index/bo-suu-tap-a/*"],
    "Permission": ["aoss:ReadDocument", "aoss:DescribeIndex"]
  }],
  "Principal": ["arn:aws:iam::<ID-tai-khoan-AI>:role/RoleTroLy"]
}

Lớp mạng — PrivateLink:

Tài khoản AI Platform          Tài khoản Đơn vị kinh doanh
┌──────────────────┐           ┌──────────────────────────┐
│ Bedrock assistant│           │ OpenSearch Serverless    │
│       ↓          │           │ Aurora pgvector          │
│ VPC endpoint ────┼──PrivateLink──→ VPC endpoint service │
└──────────────────┘           └──────────────────────────┘
       traffic KHÔNG ra Internet, dữ liệu KHÔNG rời tài khoản chủ

Ba lợi ích khớp đúng bốn ràng buộc: | Lợi ích | Chi tiết | |---|---| | Dữ liệu ở nguyên chỗ | không có bản sao nào, không có job đồng bộ | | Ranh giới bảo mật rõ ràng | mỗi đơn vị tự kiểm soát ai đọc được index của mình | | Vận hành tối thiểu | không có pipeline sao chép nào phải bảo trì |

Và truy vấn theo yêu cầu nghĩa là dữ liệu luôn mới nhất — không có độ trễ đồng bộ.

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

• C. Xuất toàn bộ embedding sang S3 ở tài khoản AI platform, dựng lại collection tập trung, đồng bộ định kỳ bằng Lambda — vi phạm hai ràng buộc cùng lúc: nó nhân bản dữ liệu và di chuyển dữ liệu khỏi tài khoản chủ, phá vỡ ranh giới bảo mật. Cộng thêm gánh nặng vận hành của job đồng bộ và độ trễ dữ liệu.
• A. Nạp toàn bộ tài liệu vào một Bedrock Knowledge Base tập trung, để Bedrock sinh embedding mới — cùng vấn đề, và tệ hơn: tính lại embedding cho toàn bộ dữ liệu của mọi đơn vị là tốn kém, và "remove the need for cross account connectivity" chính là bỏ qua yêu cầu bảo mật của đề.
• D. Dựng một API Gateway endpoint ở tài khoản AI platform proxy tới mọi index, mỗi ứng dụng truyền index identifier — tự dựng lại thứ PrivateLink làm sẵn, và tạo ra một điểm hỏng đơn lẻ cùng một nút thắt hiệu năng. Ngoài ra API Gateway có timeout 29 giây và giới hạn payload 10 MB — đều là ràng buộc không cần thiết cho truy vấn vector.

Ghi nhớ

Ba cách chia sẻ dữ liệu giữa các tài khoản AWS: | Cách | Dữ liệu di chuyển? | Vận hành | |---|---|---| | PrivateLink + IAM chéo tài khoản | ❌ ở nguyên chỗ | thấp nhất | | Sao chép định kỳ (S3, DMS) | ✅ nhân bản | cao — phải bảo trì pipeline | | Lake Formation cross-account sharing | ❌ (với dữ liệu trong data lake) | thấp | | VPC peering | ❌ | vừa — quản lý route table |

PrivateLink so với VPC peering — khác biệt đáng nhớ: | | PrivateLink | VPC peering | |---|---|---| | Phạm vi | một dịch vụ cụ thể | toàn bộ VPC | | Trùng dải IP | không sao | không được trùng | | Bảo mật | hẹp, đúng nguyên tắc đặc quyền tối thiểu | rộng hơn | | Số kết nối | mở rộng tốt | không transitive |

Với kiến trúc nhiều tài khoản như đề mô tả, PrivateLink là lựa chọn đúng vì nó chỉ mở đúng một dịch vụ, không mở cả mạng.

Hai lựa chọn vector store trong đề và cách chia sẻ: | Vector store | Cách chia sẻ chéo tài khoản | |---|---| | OpenSearch Serverless | data access policy khai principal chéo tài khoản | | Aurora PostgreSQL + pgvector | RDS Proxy hoặc PrivateLink + quyền IAM database authentication |

Và ba lưu ý khi triển khai kiến trúc này:

1. Độ trễ mạng chéo tài khoản — cùng Region thì rất thấp, nhưng vẫn cao hơn truy vấn cục bộ; cân nhắc khi có yêu cầu độ trễ chặt.
2. Ghi vết kiểm toán ở cả hai phía — CloudTrail ở tài khoản chủ ghi ai đã truy vấn.
3. Thoả thuận về schema embedding — mọi bên phải dùng cùng một embedding model, nếu không vector không so sánh được với nhau.

Điểm thứ ba là ràng buộc kỹ thuật hay bị bỏ sót trong kiến trúc phân tán như thế này.

Đáp án

D — Dùng SageMaker batch transform hoặc asynchronous inference, gửi lô lớn gộp nhiều bản ghi mỗi request, và dùng auto scaling khớp với khối lượng đỉnh để GPU luôn được dùng hết công suất.

Vì sao đúng

Đề nêu đúng vấn đề: hệ thống đang gửi MỘT request cho MỖI item, dẫn tới GPU không được dùng hết, chi phí cao, và không kịp cửa sổ hoàn thành.

Nguyên nhân nằm ở bản chất của GPU: nó xử lý song song rất hiệu quả, nhưng chỉ khi có đủ dữ liệu để lấp đầy:

Một item mỗi request:  GPU xử lý 1 item → chờ request tiếp → xử lý 1 item
                       ⇒ phần lớn thời gian GPU nhàn rỗi

Lô 64 item mỗi request: GPU xử lý 64 item cùng lúc
                       ⇒ tận dụng gần hết năng lực song song

Batching là cách duy nhất giải quyết vấn đề gốc — mọi cách khác chỉ thêm phần cứng để bù cho việc dùng sai.

Hai lựa chọn trong đáp án phù hợp với hai kịch bản: | Cách | Đặc điểm | |---|---| | Batch transform | job chạy rồi kết thúc, không cần endpoint thường trực — hợp với job theo giờ | | Asynchronous inference | có hàng đợi nội bộ, tự co giãn xuống 0 khi rảnh |

aws sagemaker create-transform-job \
  --transform-job-name kiem-duyet-noi-dung \
  --model-name model-kiem-duyet \
  --transform-input '{"DataSource": {"S3DataSource": {"S3Uri": "s3://kho/dau-vao/"}},
                      "SplitType": "Line"}' \
  --transform-output '{"S3OutputPath": "s3://kho/ket-qua/"}' \
  --transform-resources '{"InstanceType": "ml.g5.2xlarge", "InstanceCount": 4}' \
  --batch-strategy MultiRecord \
  --max-payload-in-mb 6

BatchStrategy: MultiRecord là tham số cốt lõi — nó gộp nhiều bản ghi vào một lời gọi thay vì gửi từng cái.

Và với batch transform, bạn không trả tiền cho endpoint nhàn rỗi giữa các lần chạy theo giờ — đúng với mô hình workload trong đề.

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

• A. Endpoint real-time với instance lớn hơn, gửi nhiều mini-batch đồng thời qua nhiều luồng, dựa vào concurrency để mô phỏng thông lượng cao, không áp dụng batch transform hay async inference — đây là phương án gần nhất và có cải thiện một phần (mini-batch có gộp bản ghi). Nhưng nó giữ endpoint real-time chạy liên tục cho một workload chạy theo giờ — nghĩa là trả tiền cho GPU nhàn rỗi phần lớn thời gian. Trái yêu cầu tối ưu chi phí.
• C. SageMaker Processing job phân tán trên nhiều node, mỗi node gọi endpoint song song, giữ nguyên mẫu gọi từng item — cụm "without changing the per item invocation pattern" là điểm loại: vấn đề gốc không được sửa, chỉ có nhiều máy cùng gọi sai cách nhanh hơn.
• B. Tăng số GPU instance lên mức tối đa, không đổi mẫu request — giải pháp tốn kém nhất và kém hiệu quả nhất: thêm GPU nhàn rỗi để bù cho việc dùng sai. Chi phí tăng tuyến tính mà hiệu suất mỗi GPU vẫn thấp.

Ghi nhớ

Bốn kiểu suy luận của SageMaker — chọn theo dạng workload: | Kiểu | Dùng khi | Trả tiền | |---|---|---| | Real-time | độ trễ thấp, tải liên tục | endpoint chạy 24/7 | | Serverless | tải thưa, chấp nhận cold start | theo request; không có GPU | | Asynchronous | payload lớn, xử lý lâu, có hàng đợi | co giãn xuống 0 khi rảnh | | Batch transform | xử lý theo lô, không cần endpoint | chỉ thời gian job chạy |

Với workload chạy theo giờ, khối lượng lớn, không cần trả lời tức thì như đề mô tả, hai kiểu cuối là lựa chọn đúng.

Ba tham số quyết định hiệu suất batch transform: | Tham số | Việc | |---|---| | BatchStrategy: MultiRecord | gộp nhiều bản ghi mỗi lời gọi | | MaxPayloadInMB | kích thước tối đa mỗi lô | | MaxConcurrentTransforms | số lời gọi song song mỗi instance |

Và InstanceCount phân tán dữ liệu qua nhiều máy — kết hợp với SplitType: Line để chia tệp đầu vào tự động.

Ba chỉ số cần theo dõi khi tối ưu: | Chỉ số | Ý nghĩa | |---|---| | GPUUtilization | thấp nghĩa là batch size chưa đủ | | GPUMemoryUtilization | gần 100% nghĩa là đã chạm trần batch size | | Thời gian hoàn thành job | so với cửa sổ cho phép |

Quy trình tinh chỉnh: tăng batch size cho tới khi GPUMemoryUtilization gần đầy — đó là điểm tận dụng tốt nhất. Vượt quá là lỗi hết bộ nhớ.

Và một lựa chọn khác đáng biết cho Bedrock: Batch Inference — gửi một tệp JSONL lên S3, Bedrock xử lý theo lô và trả kết quả, với giá thấp hơn 50% so với on-demand. Nếu model kiểm duyệt có thể dùng foundation model thay vì model tự host, đây là lựa chọn rẻ hơn nữa.

Đáp án

A — Dùng OpenSearch index cả text field lẫn vector embedding, và thực hiện MỘT truy vấn duy nhất đánh giá đồng thời độ tương đồng ngữ nghĩa và thuộc tính có cấu trúc; kết hợp điểm vector với khớp từ khoá và metadata filter bên trong search engine; điều chỉnh trọng số để cân bằng.

Vì sao đúng

Đề mô tả hai kiểu thất bại đối lập, và cả hai đều cần được giải quyết cùng lúc: | Thất bại | Nguyên nhân | |---|---| | Trả về tài liệu liên quan về khái niệm nhưng KHÔNG phù hợp về nghiệp vụ | thiếu metadata filter | | Không tìm được gì khi người dùng không dùng đúng thuật ngữ | thiếu vector search |

Hybrid search trong một truy vấn giải quyết cả hai:

{
  "query": {
    "hybrid": {
      "queries": [
        {"match": {"noi_dung": {"query": "quy trình phê duyệt", "boost": 0.3}}},
        {"knn": {"embedding": {"vector": [...], "k": 50, "boost": 0.7}}}
      ]
    }
  },
  "post_filter": {
    "bool": {"must": [
      {"term": {"phan_loai": "noi-bo"}},
      {"term": {"don_vi_so_huu": "phong-van-hanh"}}
    ]}
  }
}

Ba tín hiệu được đánh giá cùng lúc trong một lần gọi: | Tín hiệu | Bắt được gì | |---|---| | Vector similarity | câu hỏi diễn đạt khác nhưng cùng nghĩa | | Keyword matching | thuật ngữ chính xác, mã số, tên riêng | | Metadata filter | loại bỏ tài liệu sai phân loại hoặc sai chủ sở hữu |

Và "adjust scoring weights" là điểm quan trọng: bạn điều chỉnh tỷ trọng giữa ngữ nghĩa và khớp chính xác tuỳ theo dạng câu hỏi — điều mà chỉ làm được khi cả hai nằm trong cùng một truy vấn.

Đó cũng là lý do A hơn B: kết hợp điểm số bên trong engine cho ra một bảng xếp hạng thống nhất và có ý nghĩa, thay vì hai danh sách rời rạc phải ghép lại thủ công.

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

• B. Chạy vector query và keyword search thành hai thao tác RIÊNG, rồi gộp và khử trùng lặp ở TẦNG ỨNG DỤNG — đây là phương án gần nhất và hoạt động được, nhưng nó có ba nhược điểm: hai lần gọi thay vì một (độ trễ cao hơn), điểm số của hai phương pháp không cùng thang đo nên ghép lại rất khó, và logic ghép nằm trong mã ứng dụng — khó điều chỉnh và khó nhất quán.
• C. Ưu tiên keyword và metadata cho MỌI truy vấn, chỉ dùng vector khi không có kết quả; tránh trộn tín hiệu để đơn giản hoá xếp hạng — fallback không phải hybrid: câu hỏi diễn đạt khác vẫn trả về kết quả keyword kém liên quan (chứ không phải rỗng), nên vector search không bao giờ được kích hoạt. Và cụm "avoid blending relevance signals" chính là bỏ qua giải pháp.
• D. Chỉ dùng vector similarity cho mọi truy vấn, tăng số kết quả để bù cho biến động cách diễn đạt, lọc ở tầng ứng dụng sau khi truy xuất — giữ nguyên điểm yếu thứ nhất: tài liệu "liên quan khái niệm nhưng sai nghiệp vụ" vẫn được xếp hạng cao. Tăng k chỉ lấy về nhiều nhiễu hơn, và lọc sau khi truy xuất là lãng phí băng thông và tính toán.

Ghi nhớ

Ba tín hiệu xếp hạng trong tìm kiếm hiện đại: | Tín hiệu | Mạnh ở | Yếu ở | |---|---|---| | Vector (dense) | ngữ nghĩa, diễn đạt khác nhau | thuật ngữ hiếm, mã số, tên riêng | | Keyword (BM25) | khớp chính xác, thuật ngữ chuyên ngành | từ đồng nghĩa, cách diễn đạt khác | | Metadata filter | ràng buộc có cấu trúc | không đo được mức liên quan |

Chúng bù trừ cho nhau — đó là lý do hybrid search hiệu quả hơn hẳn từng cái riêng lẻ.

Hai cách kết hợp điểm số: | Cách | Đặc điểm | |---|---| | Weighted sum | cộng có trọng số — cần chuẩn hoá thang điểm | | Reciprocal Rank Fusion (RRF) | kết hợp theo THỨ HẠNG, không cần chuẩn hoá — bền hơn |

RRF thường được ưa dùng vì nó không nhạy cảm với việc hai phương pháp có thang điểm khác nhau:

score = Σ  1 / (k + rank_i)

Bốn tầng của một pipeline truy xuất chất lượng cao:

① Query understanding  → phân rã, mở rộng, viết lại
② Hybrid retrieval     → vector + keyword + metadata filter  ← câu này
③ Reranking            → cross-encoder sắp xếp lại top-K
④ Generation           → FM tổng hợp từ ngữ cảnh

Và một lưu ý về thứ tự lọc: đặt metadata filter TRONG truy vấn (dạng filter clause) thay vì post_filter khi có thể — nó thu hẹp không gian tìm kiếm trước, nên nhanh hơn và không làm hụt số kết quả trả về.

Với dữ liệu có thuật ngữ khác nhau giữa các đội như đề mô tả, một kỹ thuật bổ sung đáng cân nhắc: synonym mapping trong OpenSearch — khai các cặp từ tương đương ở tầng analyzer, giúp keyword search bắt được biến thể thuật ngữ mà không cần dựa hết vào vector.

Đáp án

A — Dùng Bedrock Knowledge Bases nạp embedding đa phương thức (văn bản, transcript, ảnh) vào các knowledge base RIÊNG cho nội dung công khai và nội dung chưa phát hành; dùng Bedrock Flows điều phối định tuyến model theo đơn vị kinh doanh; và stream phản hồi qua Converse API.

Vì sao đúng

Đề đưa ra năm yêu cầu, và đáp án A là lựa chọn duy nhất thoả hết: | Yêu cầu | Cách A đáp ứng | |---|---| | Truy xuất đa phương thức | Knowledge Bases hỗ trợ văn bản, transcript, embedding từ ảnh | | Phản hồi hội thoại có stream, kèm trích dẫn | Converse API + citation dựng sẵn của KB | | Định tuyến model theo đơn vị kinh doanh | Bedrock Flows với node điều kiện | | Tách nghiêm ngặt nội dung chưa phát hành và công khai | HAI knowledge base riêng biệt | | Không tự dựng pipeline ingest, không tự host model | cả hai đều là dịch vụ được quản lý |

Yêu cầu thứ tư là điểm đáng chú ý nhất về mặt thiết kế: tách bằng HAI knowledge base riêng, không phải bằng metadata filter trên một KB chung.

KB "cong-khai"     ← tài liệu đã phát hành, mọi đơn vị đọc được
KB "chua-phat-hanh" ← tài liệu tiền phát hành, chỉ đội kỹ thuật

Lý do: ranh giới ở tầng tài nguyên mạnh hơn ranh giới ở tầng truy vấn. Với hai KB riêng, quyền IAM quyết định ai truy cập được cái nào — một lỗi trong logic filter không thể làm lộ nội dung chưa phát hành.

Và citation là tính năng dựng sẵn của Knowledge Bases, đáp ứng vế "grounded citations":

for su_kien in bedrock_agent_runtime.retrieve_and_generate_stream(...):
    if 'citation' in su_kien:
        print(su_kien['citation']['retrievedReferences'])   # nguồn của từng đoạn

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

• B. Một model Claude duy nhất, Lambda phân loại đơn vị kinh doanh, đưa mọi nội dung đa phương thức vào dưới dạng văn bản đã tiền xử lý, lưu metadata trong DynamoDB — trượt hai yêu cầu: "một model duy nhất" trái yêu cầu định tuyến model theo đơn vị, và "pre-processed text" nghĩa là bạn TỰ DỰNG pipeline ingest đa phương thức — đúng thứ đề nói muốn tránh.
• C. Tự host model đa phương thức trên SageMaker, Step Functions xử lý text/ảnh/video, nhánh điều kiện cho từng đơn vị — vi phạm thẳng yêu cầu "avoid the operational burden of building custom multimodal ingestion pipelines or hosting models directly". Nó làm được về mặt kỹ thuật nhưng với gánh nặng vận hành cao nhất.
• D. ALB với ECS host model adapter, tự viết retrieval engine bằng OpenSearch, router bằng API Gateway và Lambda, cô lập bằng IAM condition key — tự dựng lại toàn bộ mọi thứ: model hosting, retrieval engine, router. Đây là phương án tốn công nhất và xa yêu cầu nhất.

Ghi nhớ

Ba dịch vụ được quản lý của Bedrock cho ứng dụng RAG: | Dịch vụ | Việc | |---|---| | Knowledge Bases | ingest, chunking, embedding, vector store, retrieval, citation | | Flows | điều phối nhiều bước: prompt, điều kiện, KB, Lambda, agent | | Agents | tự lập kế hoạch, gọi công cụ, lặp cho tới khi xong |

Knowledge Bases lo trọn các bước mà nếu tự dựng sẽ rất tốn công:

Tài liệu trên S3
    ↓ tự động: chunking (fixed, semantic, hierarchical)
    ↓ tự động: sinh embedding
    ↓ tự động: nạp vào vector store (OpenSearch Serverless, Aurora, Pinecone…)
    ↓ khi truy vấn: retrieve + rerank + citation

Hai cách tách nội dung theo mức nhạy cảm: | Cách | Mức bảo vệ | |---|---| | Knowledge base riêng biệt | cao — ranh giới ở tầng tài nguyên và IAM | | Metadata filter trên KB chung | vừa — phụ thuộc logic truy vấn đúng |

Với nội dung tiền phát hành của một hãng ô tô, cách thứ nhất là bắt buộc — rò rỉ thông tin sản phẩm chưa ra mắt là thiệt hại thương mại nghiêm trọng.

Và ba API để truy xuất từ Knowledge Bases: | API | Việc | |---|---| | Retrieve | chỉ lấy đoạn liên quan, bạn tự gọi model | | RetrieveAndGenerate | lấy + sinh câu trả lời kèm citation, một lời gọi | | RetrieveAndGenerateStream | như trên nhưng stream token |

API thứ ba là thứ đáp ứng yêu cầu "streaming conversational responses" trong đề — nó cho cả độ trễ thấp tới token đầu tiên lẫn trích dẫn nguồn.

Đáp án

A — Dùng Bedrock Knowledge Bases truy xuất dữ liệu sản phẩm có thẩm quyền để grounding câu trả lời, rồi áp dụng chấm điểm tin cậy và kiểm tra tương đồng ngữ nghĩa để xác minh câu trả lời khớp với nguồn trước khi trả về; chỉ trả về câu trả lời có bằng chứng khi độ tin cậy grounding đủ cao.

Vì sao đúng

Đề nêu vấn đề rõ ràng: model bịa ra chi tiết không có trong tài liệu được phép, và lãnh đạo muốn mọi câu trả lời đều dựa trên tài liệu đã xác minh, với một cơ chế KIỂM TRA sự phù hợp trước khi trả về.

Hai vế đó cần hai lớp riêng biệt, và chỉ A có cả hai:

Lớp 1 — grounding bằng RAG: Knowledge Bases truy xuất tài liệu thật và đưa vào ngữ cảnh, nên model có nguồn để dựa vào thay vì phải bịa.

Lớp 2 — xác minh sau khi sinh: đây là điểm phân biệt quan trọng nhất. RAG giảm ảo giác nhưng không loại bỏ — model vẫn có thể thêm chi tiết không có trong tài liệu được truy xuất. Nên cần một bước kiểm tra câu trả lời có thật sự khớp với nguồn không:

tra_loi = bedrock_agent_runtime.retrieve_and_generate(...)

# Lớp 2: kiểm tra grounding
diem_grounding = kiem_tra_tuong_dong(
    cau_tra_loi=tra_loi['output']['text'],
    tai_lieu_nguon=tra_loi['citations']
)

if diem_grounding < NGUONG:
    return "Tôi không tìm thấy thông tin này trong tài liệu chính thức."
return tra_loi

Và AWS có tính năng dựng sẵn cho lớp này — Contextual Grounding Check của Guardrails:

{
  "contextualGroundingPolicyConfig": {
    "filtersConfig": [
      {"type": "GROUNDING", "threshold": 0.75},
      {"type": "RELEVANCE", "threshold": 0.75}
    ]
  }
}

Vượt ngưỡng thì Guardrails chặn câu trả lời — đúng nghĩa "return only evidence backed responses".

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

• C. Dùng Knowledge Bases index tài liệu nhưng cho model trả lời TRỰC TIẾP không qua grounding; Lambda hậu xử lý ghi log những câu bịa để xem xét sau — bỏ qua chính cơ chế cần dùng: index mà không truy xuất thì không có grounding nào. Và "log for later review" là phát hiện sau khi khách hàng đã thấy câu trả lời sai.
• D. Dùng Kendra làm tầng truy xuất, cho LLM đưa đoạn văn vào câu trả lời tự do không ép sự phù hợp; dựa vào CloudWatch alert để phát hiện ảo giác — Kendra là công cụ truy xuất hợp lệ, nhưng "without enforcing alignment" bỏ mất lớp xác minh. Và CloudWatch không phát hiện được ảo giác — nó không biết câu trả lời đúng hay sai.
• B. Dùng Amazon Translate rồi model tóm tắt để tạo bản rút gọn của tài liệu, chỉ cho model trả lời từ các bản tóm tắt đó; dựa vào hướng dẫn trong prompt để giảm ảo giác — sai nhiều tầng: Translate là dịch thuật, không liên quan; tóm tắt làm MẤT chi tiết (thông số kỹ thuật, điều khoản bảo hành — đúng thứ cần chính xác); và "depend on prompt instructions" là biện pháp yếu nhất.

Ghi nhớ

Bốn lớp chống ảo giác, theo thứ tự nên áp dụng: | Lớp | Cơ chế | Hiệu quả | |---|---|---| | 1 | RAG grounding | giảm mạnh, nhưng không triệt để | | 2 | Contextual grounding check | chặn câu trả lời không dựa trên nguồn | | 3 | Trích dẫn nguồn hiển thị cho người dùng | cho phép người đọc tự kiểm | | 4 | Prompt yêu cầu nói "không biết" | yếu nhất, nhưng nên có |

Điểm quan trọng nhất: RAG một mình không đủ. Ba nguyên nhân ảo giác vẫn xảy ra dù đã có RAG: | Nguyên nhân | Chi tiết | |---|---| | Truy xuất không tìm được tài liệu đúng | model tự lấp khoảng trống | | Model thêm chi tiết ngoài ngữ cảnh | trộn kiến thức huấn luyện với tài liệu | | Tài liệu mâu thuẫn nhau | model chọn hoặc tổng hợp sai |

Lớp 2 bắt được cả ba — đó là lý do nó không thể thiếu với ứng dụng hiển thị thông tin cho khách hàng.

Các thành phần của Bedrock Guardrails liên quan: | Thành phần | Việc | |---|---| | Contextual grounding | chống ảo giác — grounding và relevance | | Content filters | ngôn ngữ độc hại | | Denied topics | chủ đề bị cấm | | Sensitive information | che PII |

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

1. Hiệu chỉnh ngưỡng bằng dữ liệu thật — quá cao thì từ chối cả câu trả lời đúng, quá thấp thì lọt ảo giác.
2. Thông điệp từ chối phải hữu ích — "Tôi không tìm thấy thông tin này, bạn có thể liên hệ bộ phận hỗ trợ" tốt hơn một câu từ chối cụt lủn.
3. Ghi lại tỷ lệ bị chặn như một metric — nếu tăng dần, có thể tài liệu nguồn đang thiếu hoặc truy xuất đang kém.