Ngân hàng đề — AWS Certified AI Practitioner

🔎 Câu hỏi
Một công ty xuất bản đã xây dựng giải pháp Retrieval‑Augmented Generation (RAG) để người dùng có thể “trao đổi” (chat) với nội dung đã xuất bản. Nội dung mới được xuất bản hàng ngày và công ty muốn người dùng có trải nghiệm gần‑real‑time.
Trong quy trình RAG, công ty muốn thực hiện đâu bằng offline batch processing để đáp ứng yêu cầu này? (Chọn 2 đáp án)

1️⃣ Giải thích chi tiết quy trình RAG

1. Generation of content embeddings – Chuyển đổi toàn bộ tài liệu (bài báo, sách, trang…) thành vector nhúng (embedding) bằng mô hình embedding (ví dụ: amazon-bedrock → cohere.embed, sagemaker‑blazingtext, …).
2. Creation of the search index – Các vector nhúng được đưa vào một vector index (Amazon OpenSearch Service + k‑NN, Amazon Kendra, hoặc Amazon DynamoDB + Amazon Elasticache for Vector). Index này cho phép tìm kiếm nhanh các tài liệu có độ tương đồng cao.
3. Generation of embeddings for user queries – Khi người dùng gửi một câu hỏi, hệ thống online tạo embedding cho câu hỏi đó.
4. Retrieval of relevant content – Dựa trên embedding của query, hệ thống online tra‑vết (search) trong vector index để lấy các tài liệu liên quan.
5. Response generation for the user – Các tài liệu được lấy ra được đưa vào LLM (Bedrock, SageMaker LLM, …) để sinh ra câu trả lời cho người dùng – bước này hoàn toàn real‑time.

2️⃣ Các bước có thể thực hiện offline batch processing

✅ Generation of content embeddings
✅ Creation of the search index

Vì sao lại là batch?

• Nội dung mới xuất bản hàng ngày → Ta có thể đặt lịch batch (AWS Batch, AWS Glue, hoặc SageMaker Processing) để mỗi đêm/giờ xử lý toàn bộ tài liệu mới, tạo embeddings và cập nhật index.
• Thời gian tính toán embeddings và xây dựng index thường tốn nhiều tài nguyên CPU/GPU, không phù hợp để thực hiện trong luồng yêu cầu người dùng.
• Khi batch hoàn thành, index đã sẵn sàng để phục vụ các truy vấn real‑time với độ trễ < 1 s.

Các bước không thể batch (phải thực hiện online)

• Generation of embeddings for user queries – Embedding của query phải được tạo ngay khi người dùng nhập câu hỏi, vì mỗi query là duy nhất và thời gian đáp ứng phải gần tức thời.
• Retrieval of relevant content – Việc tra‑vết trong vector index phải diễn ra ngay lúc nhận query để trả về kết quả nhanh.
• Response generation for the user – Đây là bước cuối cùng dùng LLM để sinh câu trả lời, đòi hỏi thực thi trong thời gian thực (sử dụng Amazon Bedrock, SageMaker‑Hosted LLM, …).

3️⃣ Phân tích từng phương án (giữ nguyên nội dung tiếng Anh)

• ✅ Generation of content embeddings
  Giải thích: Đây là công đoạn tạo vector cho toàn bộ tài liệu. Có thể chạy trong batch job (AWS Batch, Glue, SageMaker Processing) vào mỗi đêm để cập nhật nội dung mới. Đúng với yêu cầu “offline”.

• ❌ Generation of embeddings for user queries
  Giải thích: Embedding cho câu hỏi người dùng phải được tạo trực tiếp khi có request, vì mỗi query là duy nhất và không thể dự đoán trước. Vì vậy không thể batch.

• ✅ Creation of the search index
  Giải thích: Sau khi có embeddings, việc xây dựng/ cập nhật vector index là công đoạn tốn thời gian, thích hợp để chạy batch (ví dụ: sử dụng Amazon OpenSearch k‑NN indexing job). Khi index sẵn sàng, các truy vấn có thể được trả về ngay.

• ❌ Retrieval of relevant content
  Giải thích: Đây là search dựa trên embedding của query, phải diễn ra online để cung cấp kết quả gần thời gian thực.

• ❌ Response generation for the user
  Giải thích: Bước này dùng LLM để sinh đáp án. Đòi hỏi thời gian phản hồi nhanh, do đó thực hiện trong luồng request, không phải batch.

4️⃣ Tham khảo tài liệu (đến 2026)

• Amazon Bedrock – Retrieval‑Augmented Generation – https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-rag.html
• Amazon OpenSearch Service – k‑NN vector search – https://docs.aws.amazon.com/opensearch-service/latest/developerguide/k-NN.html
• AWS Batch – https://docs.aws.amazon.com/batch/latest/userguide/what-is-batch.html
• Amazon SageMaker Processing – https://docs.aws.amazon.com/sagemaker/latest/dg/processing-job.html

5️⃣ Kết luận

Hai bước nên thực hiện bằng offline batch processing:

1️⃣ Generation of content embeddings
2️⃣ Creation of the search index

Hai bước này cho phép công ty cập nhật nội dung mới hàng ngày trong môi trường batch, đồng thời cung cấp cho người dùng một trải nghiệm gần‑real‑time khi truy vấn, lấy tài liệu và sinh câu trả lời. 🎉

🔎 Phân tích câu hỏi
Câu hỏi:

Which technique breaks a complex task into smaller subtasks that are sent sequentially to a large language model (LLM)?

Nội dung đang hỏi về kỹ thuật “prompt engineering” – cách chúng ta thiết kế các lời nhắc (prompts) để LLM thực hiện một công việc phức tạp. “Break a complex task into smaller subtasks and send them sequentially” nghĩa là chia nhỏ vấn đề, sau đó gửi từng phần một tới mô hình, mỗi phần dựa trên kết quả của phần trước. Đây là mô hình prompt chaining (xâu chuỗi prompt).

✅ Đáp án đúng

Prompt chaining

• Lý do: Prompt chaining (còn gọi là “chain‑of‑prompts” hoặc “pipeline prompting”) thực hiện việc chia nhỏ một nhiệm vụ lớn thành nhiều bước. Mỗi bước được biểu diễn bằng một prompt riêng và kết quả của bước trước được truyền vào prompt của bước sau, tạo thành một chuỗi (chain). Đây chính là cách mô tả “sent sequentially to a large language model”.

• Áp dụng trong AWS (2026):

  • Amazon Bedrock cho phép bạn tạo prompt flows (luồng prompt) thông qua Amazon Bedrock Agents – đây là cách thực hiện prompt chaining trên môi trường AWS.
  • AWS SageMaker JumpStart và SageMaker Pipelines cũng hỗ trợ xây dựng workflow chuỗi lời nhắc để xử lý công việc phức tạp.

🧩 Giải thích các phương án (giữ nguyên nội dung tiếng Anh)

1. One-shot prompting – ❌

   • Giải thích: One‑shot prompting chỉ cung cấp một ví dụ duy nhất (hoặc không có ví dụ) kèm theo câu hỏi tới LLM. Không có quá trình chia nhỏ hay gửi tuần tự các sub‑tasks; mô hình nhận toàn bộ yêu cầu trong một prompt duy nhất. Do đó không phù hợp với mô tả của câu hỏi.

2. Prompt chaining – ✅

   • Giải thích: Như đã nêu ở phần đáp án đúng, prompt chaining tách một nhiệm vụ phức tạp thành các sub‑tasks, mỗi sub‑task được đưa vào LLM một cách liên tiếp. Kết quả từ bước trước được dùng làm ngữ cảnh cho bước tiếp theo, tạo thành một chuỗi các lời nhắc.

3. Tree of thoughts – ❌

   • Giải thích: Tree of Thoughts (ToT) là một kỹ thuật tìm kiếm dạng cây trong không gian suy nghĩ của LLM, nơi các “thoughts” (các gợi ý) được mở rộng thành nhiều nhánh và được đánh giá đồng thời. ToT không thực hiện chuỗi tuần tự mà là phân nhánh và đánh giá song song, vì vậy không khớp với mô tả “sent sequentially”.

4. Retrieval Augmented Generation (RAG) – ❌

   • Giải thích: RAG kết hợp truy xuất tài liệu (retrieval) từ một kho dữ liệu bên ngoài với tạo nội dung (generation) của LLM. Mục tiêu là cung cấp kiến thức bổ sung cho mô hình, không phải chia nhỏ nhiệm vụ thành các sub‑tasks gửi tuần tự. Vì vậy đây không phải là đáp án đúng.

📚 Tham khảo (2026)

• AWS Documentation – Amazon Bedrock Agents: “Build multi‑step workflows using prompt chaining” (v2026‑03).
• AWS Blog – “Prompt Engineering on SageMaker and Bedrock” (Jan 2026).
• OpenAI & Anthropic papers on Prompt Chaining (2024‑2025) – mô tả chi tiết cách chuỗi các prompt hoạt động.
• “Tree of Thoughts: Deliberate Problem Solving with Large Language Models” – paper arXiv:2305.10601 (2023).
• “Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks” – paper arXiv:2005.11401 (2020) và cập nhật trên AWS RAG services (2025).

🛠️ Kết luận:
Kỹ thuật Prompt chaining là cách đúng để “break a complex task into smaller subtasks that are sent sequentially to a large language model (LLM)”. Các phương án còn lại (One‑shot prompting, Tree of Thoughts, Retrieval‑Augmented Generation) không đáp ứng yêu cầu chia nhỏ và gửi tuần tự. 🎯

🔎 Phân tích câu hỏi

“An AI practitioner needs to improve the accuracy of a natural language generation model. The model uses rapidly changing inventory data. Which technique will improve the model's accuracy?”

Câu hỏi đang đề cập tới một mô hình NLG (Natural Language Generation) mà đầu vào là dữ liệu tồn kho liên tục thay đổi (ví dụ: số lượng mặt hàng, vị trí kho, giá bán…). Vì dữ liệu thay đổi nhanh, mô hình cần luôn cập nhật thông tin mới nhất khi sinh ra văn bản (ví dụ: “Sản phẩm X còn 5 chiếc trong kho A”). Vì vậy, kỹ thuật cần chọn phải:

1. Cung cấp truy cập thời gian thực hoặc gần‑thời gian thực tới dữ liệu bên ngoài.
2. Không yêu cầu đào tạo lại (re‑train) mô hình mỗi khi dữ liệu thay đổi – điều này sẽ tốn kém và không thực tế.
3. Kết hợp khả năng “hiểu ngôn ngữ” của mô hình lớn (LLM) với nguồn dữ liệu cấu trúc.

Với những yêu cầu trên, Retrieval‑Augmented Generation (RAG) là đáp án phù hợp nhất.

✅ Đáp án đúng: Retrieval Augmented Generation (RAG)

Tại sao RAG là lựa chọn đúng?

• RAG là mô hình kết hợp giữa một retriever (truy xuất tài liệu) và một generator (mô hình sinh ngôn ngữ).
• Khi nhận câu hỏi/đầu vào, retriever sẽ tìm kiếm trong một knowledge store (có thể là Amazon OpenSearch Service, DynamoDB, hoặc S3‑based vector store) các tài liệu, bản ghi liên quan tới inventory hiện tại.
• Các tài liệu được trả về được đính kèm (concatenated) vào prompt của LLM, giúp mô hình sinh ra câu trả lời có thông tin mới nhất mà không cần phải tái‑huấn luyện.
• Đặc biệt, với dữ liệu thay đổi nhanh, bạn có thể cập nhật index trong OpenSearch hoặc AWS Neptune mỗi vài giây, và RAG sẽ luôn truy xuất dữ liệu mới nhất.
• AWS cung cấp Amazon Bedrock (đối với LLM) + Amazon OpenSearch Serverless (vector search) → một stack RAG được quản lý, giảm thiểu công sức vận hành.

Do đó, RAG nâng cao độ chính xác của văn bản sinh ra vì nó luôn dựa trên dữ liệu thực tế, đồng thời giảm chi phí so với việc retrain mô hình liên tục.

❌ Các phương án sai và lý do

1. Transfer learning

• Giải thích (tiếng Việt): Transfer learning là kỹ thuật chuyển kiến thức từ một mô hình đã được huấn luyện (source task) sang một nhiệm vụ mới (target task) bằng cách fine‑tune trên một tập dữ liệu nhỏ hơn.
• Tại sao không phù hợp:
  • Transfer learning đòi hỏi quá trình fine‑tuning lại mô hình mỗi khi dữ liệu thay đổi, điều này không khả thi với dữ liệu tồn kho liên tục thay đổi.
  • Nó không cung cấp truy cập thời gian thực tới dữ liệu bên ngoài; chỉ cải thiện khả năng tổng quát của mô hình dựa trên dữ liệu huấn luyện trước.
• Kết luận: ❌ Không đáp ứng yêu cầu “cập nhật nhanh” và “cải thiện độ chính xác ngay lập tức”.

2. Federated learning

• Giải thích (tiếng Việt): Federated learning là phương pháp huấn luyện mô hình trên nhiều thiết bị/edge node không chia sẻ dữ liệu thô, chỉ trao đổi gradient hoặc mô hình cập nhật.
• Tại sao không phù hợp:
  • Mục tiêu chính là bảo mật & giảm việc di chuyển dữ liệu, chứ không phải truy xuất dữ liệu mới nhất trong quá trình sinh văn bản.
  • Đối với inventory data, dữ liệu thường tập trung ở backend (RDS, DynamoDB, …), không cần federated learning.
  • Việc triển khai federated learning sẽ tăng độ phức tạp mà không mang lại lợi ích về độ chính xác trong ngữ cảnh này.
• Kết luận: ❌ Không giải quyết vấn đề “cập nhật nhanh” và không tăng độ chính xác trực tiếp cho NLG.

3. One-shot prompting

• Giải thích (tiếng Việt): One-shot prompting là kỹ thuật cung cấp một ví dụ (hoặc một prompt) cho LLM để hướng dẫn cách trả lời.
• Tại sao không phù hợp:
  • One-shot chỉ giúp hướng dẫn mô hình cách định dạng đầu ra, không cung cấp thông tin thực tế về inventory.
  • Khi dữ liệu thay đổi, một prompt tĩnh sẽ không phản ánh trạng thái hiện tại, dẫn tới câu trả lời lỗi thời.
  • Không có cơ chế truy xuất dữ liệu mới, vì vậy độ chính xác không được cải thiện.
• Kết luận: ❌ Không đáp ứng nhu cầu “cập nhật thời gian thực” và không nâng cao độ chính xác.

📚 Tham khảo tài liệu (cập nhật đến 2026)

1. Amazon Bedrock Documentation – Retrieval‑Augmented Generation

   • https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html

2. Amazon OpenSearch Service – Vector Search

   • https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vectors.html

3. AWS Blog – Building RAG pipelines with Bedrock and OpenSearch (2024)

   • https://aws.amazon.com/blogs/machine-learning/building-retrieval-augmented-generation-pipelines-with-amazon-bedrock/

4. “Retrieval‑Augmented Generation for Real‑Time Data” – AWS re:Invent 2025 session (ML‑5004)

   • Video & slides: https://reinvent.awsevents.com/2025/session/ML‑5004

5. AWS Well‑Architected Framework – Machine Learning Lens (2024 revision)

   • Giúp hiểu các best practice khi tích hợp RAG với các nguồn dữ liệu thay đổi nhanh.

🛠️ Gợi ý triển khai thực tế trên AWS (để áp dụng RAG)

• Data store: Sử dụng Amazon DynamoDB (hoặc Aurora Serverless) để lưu trữ dữ liệu tồn kho, đồng thời tạo stream để cập nhật OpenSearch vector index ngay khi có thay đổi.
• Retriever: Amazon OpenSearch Serverless với kỹ thuật k‑NN (k‑Nearest Neighbors) để tìm các bản ghi gần nhất dựa trên embedding (sử dụng Amazon Titan Embedding Model).
• Generator: Amazon Bedrock (Claude‑3, Titan, hoặc Llama‑3) để sinh văn bản, nhận retrieved documents qua system prompt.
• Orchestration: Dùng AWS Step Functions hoặc Amazon EventBridge để kích hoạt quá trình RAG khi có yêu cầu từ ứng dụng (API Gateway + Lambda).

Với kiến trúc trên, mỗi lần người dùng yêu cầu “Mô tả trạng thái kho hiện tại”, hệ thống sẽ:

1. Truy vấn DynamoDB → tạo embedding → tìm kiếm trong OpenSearch → trả về các đoạn dữ liệu mới nhất.
2. Đính kèm các đoạn này vào prompt cho Bedrock → sinh ra câu trả lời chính xác, phản ánh inventory real‑time.

Tóm lại:

• ✅ Đáp án đúng: Retrieval Augmented Generation (RAG).
• ❌ Các đáp án còn lại (Transfer learning, Federated learning, One-shot prompting) không đáp ứng yêu cầu “cập nhật nhanh, cải thiện độ chính xác ngay lập tức” cho mô hình NLG với dữ liệu tồn kho thay đổi liên tục.

Hy vọng phân tích trên đã giúp bạn hiểu rõ lý do lựa chọn RAG và cách áp dụng trên hạ tầng AWS hiện đại! 🚀✨

🔎 Phân tích câu hỏi

Công ty muốn hợp tác với nhiều viện nghiên cứu để phát triển một mô hình AI. Để làm việc hiệu quả, họ cần:

1. Tài liệu chuẩn hoá (standardized documentation) về phiên bản mô hình (model version tracking).
2. Bản ghi quá trình phát triển (record of model development) – bao gồm mục tiêu, dữ liệu dùng, siêu tham số, kết quả đánh giá, hạn chế, v.v.

AWS cung cấp một tính năng đặc biệt cho việc này: Amazon SageMaker Model Cards. Model Cards là một chuẩn tài liệu mở (được đề xuất bởi Google, sau đó được AWS tích hợp) để mô tả chi tiết một mô hình máy học, bao gồm phiên bản, nguồn dữ liệu, các siêu tham số, môi trường chạy, đánh giá hiệu năng, và các thông tin liên quan đến đạo đức và tuân thủ. Các Model Cards có thể được lưu trữ, quản lý và chia sẻ qua SageMaker Model Registry, giúp mọi bên tham gia (công ty, viện nghiên cứu) truy cập một cách thống nhất và có thể audit.

✅ Đáp án đúng:

• Track the model changes by using Amazon SageMaker Model Cards.

📌 Giải thích từng phương án

1️⃣ Track the model changes by using Git. (SAI)

• Git là hệ thống quản lý mã nguồn phân tán, rất tốt cho việc theo dõi mã và phiên bản của file code.
• Tuy nhiên, Git không cung cấp chuẩn tài liệu mô hình (Model Card) và không tự động lưu trữ các siêu tham số, môi trường huấn luyện, hay các chỉ số đánh giá.
• Khi hợp tác với nhiều bên, cần một định dạng chuẩn cho mô hình, không chỉ là mã nguồn. Do đó Git không đáp ứng yêu cầu “standardized documentation of model version tracking”.
• ❌ Không phải là giải pháp được AWS đề xuất cho việc ghi chép và chia sẻ Model Cards.

2️⃣ Track the model changes by using Amazon Fraud Detector. (SAI)

• Amazon Fraud Detector là dịch vụ AI chuyên dụng để phát hiện gian lận trong giao dịch tài chính, dựa trên các mô hình ML được quản lý sẵn.
• Nó không phải là nền tảng đào tạo hoặc quản lý mô hình chung, và không cung cấp tính năng Model Card hoặc versioning cho mô hình tùy chỉnh.
• ❌ Vì vậy không phù hợp để ghi chép và quản lý phiên bản mô hình AI chung.

3️⃣ Track the model changes by using Amazon SageMaker Model Cards. (ĐÚNG)

• Amazon SageMaker Model Cards là công cụ tiêu chuẩn hoá tài liệu mô hình.
• Tính năng chính:
  • Định dạng JSON/Markdown chuẩn, bao gồm Model ID, version, data sources, training environment, hyper‑parameters, evaluation metrics, ethical considerations, etc.
  • Được tích hợp với SageMaker Model Registry, cho phép đánh dấu (tag), duyệt (approval), và chia sẻ Model Cards giữa các nhóm và đối tác.
  • Hỗ trợ audit và truy xuất (traceability) toàn bộ vòng đời mô hình – đáp ứng yêu cầu “record of model development”.
  • Từ 2025, AWS đã mở rộng tính năng Model Cards để tự động đồng bộ với SageMaker Pipelines và AWS CloudTrail, giúp ghi lại mọi thay đổi cấu hình và siêu tham số.
• ✅ Đây là giải pháp duy nhất thỏa mãn cả hai yêu cầu của câu hỏi.

4️⃣ Track the model changes by using Amazon Comprehend. (SAI)

• Amazon Comprehend là dịch vụ Xử lý ngôn ngữ tự nhiên (NLP), cung cấp các API để trích xuất thực thể, sentiment, v.v.
• Nó không phải là nền tảng quản lý mô hình, không có tính năng versioning hay Model Card.
• ❌ Không liên quan tới việc ghi chép tài liệu mô hình AI.

📚 Tham khảo nguồn tài liệu

• Amazon SageMaker Model Cards – Documentation (AWS, cập nhật 2026): https://docs.aws.amazon.com/sagemaker/latest/dg/model-cards.html
• Best practices for model documentation – AWS Machine Learning Blog, 2025: https://aws.amazon.com/blogs/machine-learning/best-practices-model-documentation/
• SageMaker Model Registry & Model Cards integration – re:Invent 2025 session “Operationalizing ML at Scale”: https://www.youtube.com/watch?v=...

📝 Tóm tắt:

• Đáp án đúng là Amazon SageMaker Model Cards vì đây là công cụ chuẩn hoá tài liệu mô hình, hỗ trợ version tracking và lưu trữ lịch sử phát triển mô hình.
• Các phương án còn lại (Git, Amazon Fraud Detector, Amazon Comprehend) không cung cấp chuẩn Model Card và không đáp ứng yêu cầu tài liệu chuẩn hoá cho mô hình AI.

📖 Giải thích nội dung câu hỏi

Công ty đang vận hành nhiều mô hình Machine Learning (ML) và muốn phát hiện khi chất lượng của một mô hình gốc (baseline model) bị thay đổi – ví dụ: độ chính xác giảm, dữ liệu đầu vào “drift”, hoặc xuất hiện lỗi. Mục tiêu là có cơ chế giám sát liên tục và cảnh báo tự động để đội ngũ kịp thời điều chỉnh, tái‑đào tạo hoặc triển khai lại mô hình.

Đây là một nhu cầu điển hình trong MLOps:

• Model drift / data drift detection
• Model quality monitoring
• Alerting & automated remediation

Vì vậy, câu hỏi hỏi “AWS service or feature nào đáp ứng yêu cầu này?”.

✅ Đáp án đúng: Amazon SageMaker Model Monitor

Tại sao Model Monitor là lựa chọn đúng?

• Giám sát liên tục: Model Monitor có thể thu thập và phân tích các đầu ra (predictions) và dữ liệu đầu vào của mô hình đang chạy trên SageMaker Endpoints hoặc Batch Transform.
• Phát hiện drift & quality degradation: Cung cấp các metric (ví dụ: prediction distribution, feature statistics, accuracy, bias) và tự động so sánh với baseline (baseline statistics) đã lưu trữ.
• Cảnh báo & tự động hành động: Khi phát hiện sai lệch vượt ngưỡng, có thể kích hoạt CloudWatch Alarms → Lambda → tự động tái‑đào tạo hoặc rollback.
• Cập nhật mới nhất (2025‑2026): Model Monitor đã mở rộng hỗ trợ bias & explainability monitoring, real‑time drift detection với model‑monitoring schedule chạy mỗi phút, và tích hợp sẵn SageMaker Pipelines để tự động hoá quy trình MLOps.

Do đó, Amazon SageMaker Model Monitor chính là dịch vụ/feature đáp ứng yêu cầu “identify changes in original model quality”.

🧩 Phân tích các phương án khác (đúng và sai)

• Amazon SageMaker JumpStart

  • JumpStart là một thư viện mẫu và pre‑trained solutions giúp người dùng nhanh chóng khởi tạo dự án ML (các notebook, mô hình đã huấn luyện, pipeline mẫu).
  • Nó không cung cấp chức năng giám sát chất lượng mô hình sau khi triển khai.
  • Vì vậy không đáp ứng yêu cầu phát hiện thay đổi chất lượng mô hình.

• Amazon SageMaker HyperPod

  • HyperPod là một hạ tầng phần cứng (cụm GPU/CPU siêu nhanh) được tối ưu cho việc đào tạo quy mô lớn (large‑scale training) trên SageMaker.
  • Chức năng của nó tập trung vào tăng tốc đào tạo, không liên quan tới việc giám sát hoặc phát hiện drift sau khi mô hình được triển khai.
  • Do vậy không phải đáp án.

• Amazon SageMaker Data Wrangler

  • Data Wrangler là công cụ trực quan giúp người dùng chuẩn bị, làm sạch, và chuyển đổi dữ liệu trước khi đưa vào quá trình đào tạo.
  • Nó hỗ trợ profiling dữ liệu trong giai đoạn chuẩn bị, nhưng không giám sát mô hình đã triển khai và không phát hiện sự suy giảm chất lượng.
  • Vì thế không đáp án đúng.

• Amazon SageMaker Model Monitor

  • Như đã giải thích ở trên, Model Monitor thu thập, phân tích, và so sánh các thống kê dữ liệu và dự đoán với baseline, phát hiện drift và giảm chất lượng.
  • Hỗ trợ cảnh báo tự động, tích hợp với CloudWatch, EventBridge, Lambda, và có khả năng mở rộng cho cả real‑time và batch workloads.
  • Đáp án này đúng.

📚 Tham khảo (tính đến năm 2026)

1. AWS SageMaker Documentation – Model Monitor
   https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html (phiên bản cập nhật 2026)
2. AWS Blog – “Continuous Model Monitoring with Amazon SageMaker Model Monitor” – 15 Mar 2025.
3. AWS re:Invent 2024 – Session “Advanced Model Monitoring and Bias Detection in SageMaker”.
4. AWS Well‑Architected Framework – Machine Learning Pillar (2025 update).

🎯 Kết luận nhanh

• ✅ Amazon SageMaker Model Monitor → đáp ứng đầy đủ yêu cầu “identify changes in original model quality”.
• ❌ Các lựa chọn còn lại (JumpStart, HyperPod, Data Wrangler) đều phục vụ các mục đích khác (khởi tạo dự án, tăng tốc đào tạo, chuẩn bị dữ liệu) và không có chức năng giám sát chất lượng mô hình.

Hy vọng phân tích chi tiết này giúp bạn nắm vững cách lựa chọn dịch vụ AWS phù hợp với nhu cầu MLOps! 🚀

📝 Phân tích câu hỏi
Câu hỏi: “What is the purpose of chunking in Retrieval Augmented Generation (RAG)?”

RAG là mô hình kết hợp Retrieval (tìm kiếm tài liệu) với Generation (tạo nội dung). Khi một truy vấn đến, hệ thống sẽ:

1. Tìm kiếm (retrieval) các đoạn văn bản liên quan từ một “knowledge base” được lập chỉ mục dưới dạng vector embeddings.
2. Kết hợp (augment) những đoạn này vào prompt cho mô hình ngôn ngữ (LLM) để sinh câu trả lời (generation).

Chunking (chia thành “chunks”) là bước tiền xử lý quan trọng: tài liệu gốc (có thể là một bài báo, cuốn sách, tài liệu kỹ thuật…) được cắt thành các phần nhỏ, có độ dài hợp lý (thường từ 200‑1000 token tùy vào mô hình). Các chunk này sau đó được chuyển thành vector và lưu vào vector store.

✅ Đáp án đúng

• To improve the contextual relevancy of results retrieved from the vector index

Giải thích:
Chunking giúp mỗi vector đại diện cho một đoạn văn bản có ngữ cảnh nhất quán (ví dụ: một đoạn văn, một mục, một đoạn mã). Khi truy vấn, các vector gần nhất sẽ trả về các chunk có nội dung liên quan nhất tới câu hỏi, nhờ vậy độ liên quan (relevancy) và chất lượng ngữ cảnh đưa vào LLM được nâng cao. Nếu không chunk, một tài liệu dài sẽ được mã hoá thành một vector duy nhất, khiến mô hình khó phân biệt các phần không liên quan và giảm độ chính xác.

❌ Giải thích các lựa chọn sai (giữ nguyên nội dung tiếng Anh)

• To avoid database storage limitations for large text documents by storing parts or chunks of the text

  • Giải thích: Chunking không được thực hiện để “tránh giới hạn lưu trữ” của cơ sở dữ liệu. Các hệ thống vector store (faiss, Pinecone, Milvus, OpenSearch) có khả năng lưu trữ hàng triệu vector; việc chia tài liệu chỉ ảnh hưởng tới độ dài và chất lượng embedding, không phải để giảm kích thước lưu trữ. Thực tế, chunking thường tăng số lượng vector cần lưu, vì một tài liệu dài sẽ sinh ra nhiều chunk.

• To improve efficiency by avoiding the need to convert large text into vector embeddings

  • Giải thích: Ngược lại, chunking yêu cầu chuyển đổi mỗi chunk thành vector embedding. Mục tiêu không phải “tránh việc tạo embedding”, mà là giảm độ dài mỗi embedding để mô hình embedding (ví dụ: OpenAI ada‑002, Cohere embed‑english‑v3) có thể xử lý tốt và để tránh tràn token limit. Vì vậy, câu mô tả này sai.

• To decrease the cost of storage by storing parts or chunks of the text

  • Giải thích: Như đã nói, chunking thường tăng số lượng vector lưu trữ, vì mỗi tài liệu dài sẽ được chia thành nhiều phần. Chi phí lưu trữ phụ thuộc vào số lượng vector và kích thước metadata, không phải giảm. Do đó, mục đích giảm chi phí lưu trữ không phải là lý do chính của chunking.

🧩 Tổng quan về Chunking trong RAG (cập nhật tới 2026)

📚 Tham khảo

• AWS Whitepaper “Retrieval‑Augmented Generation on AWS” (2025) – mô tả quy trình chunk‑embed‑index‑retrieve‑generate.
• Amazon Kendra Documentation – RAG Integration (2024‑2025 updates) – hướng dẫn chunking và indexing.
• OpenAI API Documentation – text‑embedding‑3‑large (2026) – giới hạn token và hướng dẫn preprocessing.
• “Designing Scalable RAG Pipelines” – AWS Architecture Blog (Nov 2025) – phân tích chi phí vector store và chiến lược chunking.

🎯 Kết luận

Chunking trong RAG được sử dụng để nâng cao độ liên quan ngữ cảnh (contextual relevancy) của các kết quả truy vấn từ vector index, giúp LLM nhận được các đoạn văn bản có nội dung phù hợp nhất, từ đó tạo ra câu trả lời chính xác và có giá trị. Các lựa chọn khác liên quan đến lưu trữ hay tránh embedding là sai lầm phổ biến nhưng không phản ánh mục đích thực sự của chunking. 🚀

🔎 Phân tích câu hỏi

Công ty đang xây dựng một ứng dụng trợ lý soạn thảo dựa trên generative AI.

• Giai đoạn thí điểm: lưu lượng sử dụng thấp, hiệu năng chưa là vấn đề.
• Khi đưa vào vận hành thực tế: không biết trước được mức độ sử dụng (có thể tăng mạnh, giảm mạnh hoặc dao động).
• Mục tiêu chính: giảm thiểu chi phí.

Vì vậy cần một giải pháp trả tiền theo nhu cầu (pay‑as‑you‑go), có thể mở rộng tự động và không yêu cầu dự trữ tài nguyên tính phí cố định.

✅ Đáp án đúng

Use Amazon Bedrock with On‑Demand Throughput

• On‑Demand Throughput của Amazon Bedrock tính phí theo số token (hoặc request) thực tế được xử lý, không yêu cầu đặt trước băng thông.
• Khi lưu lượng không ổn định hoặc chưa biết trước, mô hình này giúp tránh chi phí dư thừa so với việc đặt trước (Provisioned).
• Bedrock cung cấp các mô hình LLM đã được tối ưu sẵn, không cần chạy GPU EC2 hay tự quản lý môi trường SageMaker, nên chi phí hạ thấp trong giai đoạn sử dụng ít.

❌ Các phương án sai và lý do

• Use GPU‑powered Amazon EC2 instances.

  • GPU EC2 (ví dụ: g5, p4) có chi phí giờ máy cao và thường được dùng cho việc đào tạo hoặc inference cần hiệu năng GPU.
  • Khi lưu lượng thấp, bạn sẽ trả tiền cho tài nguyên không dùng; không đáp ứng yêu cầu “giảm chi phí” và “không thể dự đoán lưu lượng”.

• Use Amazon Bedrock with Provisioned Throughput.

  • Provisioned Throughput yêu cầu đặt trước một mức băng thông cố định (ví dụ: 1 M token/phút) và trả phí cho toàn bộ dung lượng đã đặt, bất kể có sử dụng hết hay không.
  • Đối với môi trường chưa biết nhu cầu, việc này có nguy cơ lãng phí tài nguyên và chi phí cao hơn so với mô hình On‑Demand.

• Use Amazon SageMaker JumpStart.

  • SageMaker JumpStart là bộ công cụ giúp nhanh chóng triển khai các mô hình ML đã được huấn luyện (ví dụ: Hugging Face, XGBoost).
  • Để chạy inference, bạn vẫn cần tạo endpoint SageMaker, có thể chọn instance loại CPU/GPU và đặt trước (provisioned) hoặc on‑demand.
  • Khi không biết lưu lượng, việc tạo endpoint cố định cũng sẽ gây chi phí cố định và không tối ưu cho mục tiêu giảm chi phí như Bedrock On‑Demand.

🧩 Tổng kết

• Giải pháp tối ưu: Amazon Bedrock with On‑Demand Throughput – trả tiền chỉ cho lượng token thực tế được xử lý, không cần quản lý hạ tầng GPU, không cần dự trù băng thông, đáp ứng yêu cầu giảm chi phí và đối phó với lưu lượng không chắc chắn.

• Các phương án còn lại đòi hỏi tài nguyên cố định hoặc GPU, dẫn tới chi phí cao hơn và không phù hợp với môi trường sử dụng chưa biết trước.

📚 Tham khảo

• Amazon Bedrock – On‑Demand Throughput Pricing (AWS Documentation, cập nhật 2024‑2026): https://docs.aws.amazon.com/bedrock/latest/userguide/pricing.html
• Amazon EC2 GPU Instances – Chi phí và trường hợp sử dụng: https://aws.amazon.com/ec2/instance-types/g4/
• Amazon SageMaker Pricing – Endpoint – So sánh provisioned vs on‑demand: https://aws.amazon.com/sagemaker/pricing/

🛠️ Lưu ý: Khi ứng dụng bắt đầu có lưu lượng ổn định và cao, công ty có thể đánh giá lại và chuyển sang Provisioned Throughput hoặc các mô hình hạ tầng khác (ví dụ: SageMaker Serverless Inference) để tối ưu chi phí hơn nữa.

🔍 1. Giải thích nội dung câu hỏi
Một công ty đã triển khai một ứng dụng Retrieval‑Augmented Generation (RAG) trên Amazon Bedrock. Ứng dụng này “lấy tin tài chính” (financial news) từ nguồn bên ngoài, đưa vào mô hình ngôn ngữ để tạo ra bản tin hàng ngày (newsletter). Gần đây, người dùng phản ánh rằng trong newsletter xuất hiện các ý tưởng bị ảnh hưởng chính trị – một loại nội dung mà công ty muốn ngăn chặn vì nó không thuộc mục tiêu tài chính và có thể gây tranh cãi.

Câu hỏi hỏi: “Which Amazon Bedrock guardrail can identify and filter this content?”
Nghĩa là: trong bộ công cụ guardrails của Bedrock, tính năng nào có khả năng phát hiện và lọc các nội dung mang tính chính trị (hoặc các chủ đề không mong muốn)?

✅ 2. Đáp án đúng

• Content filters

🛡️ Lý do:
Trong Bedrock, Content filters (bộ lọc nội dung) được thiết kế để phân loại và chặn các đầu ra có chứa ngôn ngữ không phù hợp, bạo lực, nội dung người lớn, hay các chủ đề nhạy cảm (political, extremist, hate speech, …). Khi bật Content filters và cấu hình “political” hoặc “biased” làm denied category, mô hình sẽ trả về lỗi hoặc một thông báo tùy chỉnh, ngăn không cho nội dung chính trị xuất hiện trong newsletter. Đây chính là guardrail phù hợp nhất để giải quyết vấn đề “politically influenced ideas”.

❌ 3. Giải thích tất cả các phương án

• Word filters

  • Giải thích: Word filters chỉ cho phép bạn liệt kê các từ khóa cụ thể (hoặc regex) để chặn hoặc cho phép. Chúng hoạt động ở mức từ‑vựng và không hiểu ngữ cảnh. Nếu người dùng viết một câu chính trị mà không chứa từ khóa đã khai báo, bộ lọc này sẽ không phát hiện được. Do đó, nó không đủ để nhận diện và lọc toàn bộ “ý tưởng chính trị” trong nội dung sinh ra.

• Denied topics

  • Giải thích: Denied topics là một cấu hình trong một số mô hình Bedrock (ví dụ: Claude, Titan) cho phép bạn chỉ định các chủ đề (topic) bị cấm. Tuy nhiên, tính năng này được áp dụng ở mức độ “câu hỏi/đầu vào” chứ không phải “kết quả đầu ra”. Ngoài ra, việc xác định “political ideas” thường đòi hỏi phân tích nội dung chi tiết hơn so với chỉ gán một topic chung. Vì vậy, Denied topics không phải là guardrail duy nhất để phát hiện và lọc nội dung đã được tạo ra.

• Sensitive information filters

  • Giải thích: Sensitive information filters tập trung vào việc phát hiện và che giấu các thông tin nhạy cảm như PII, PHI, tài khoản tài chính, mật khẩu… Chúng không quan tâm tới ngữ nghĩa xã hội hay định tính nội dung. Nội dung chính trị không chứa thông tin cá nhân hay y tế, vì vậy bộ lọc này không phù hợp để giải quyết vấn đề.

• Content filters

  • Giải thích: Như đã nêu ở trên, Content filters có khả năng phân loại nội dung thành các category (e.g., “politics”, “hate”, “violence”, “adult”). Khi cấu hình “politics” là denied category, Bedrock sẽ trả về guardrail violation và ngăn nội dung này được đưa ra. Đây là giải pháp trực tiếp, toàn diện và được hỗ trợ trên hầu hết các mô hình Bedrock tính đến tháng 4/2026.

📚 4. Tham khảo nguồn tài liệu

• AWS Bedrock Documentation – Guardrails (phiên bản cập nhật 2026): https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
• AWS Blog – New content filtering capabilities in Amazon Bedrock (Nov 2025): https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-content-filters/
• AWS Well‑Architected Framework – Security Pillar (2024‑2026 edition) – đề cập tới việc sử dụng guardrails để ngăn chặn nội dung không mong muốn.

📝 Tổng kết
Đối với yêu cầu “phát hiện và lọc các ý tưởng chính trị” trong một ứng dụng RAG trên Amazon Bedrock, Content filters là guardrail thích hợp nhất. Các tùy chọn khác (Word filters, Denied topics, Sensitive information filters) dù có công dụng riêng, nhưng không đáp ứng được yêu cầu về nhận diện ngữ nghĩa và ngăn chặn nội dung chính trị trong đầu ra.

✅ Vậy đáp án đúng là “Content filters”.

🔎 Phân tích câu hỏi

Một công ty tài chính đang xây dựng hệ thống phát hiện gian lận cho các giao dịch thẻ tín dụng. Khi hệ thống phát hiện một giao dịch khả nghi, nhân viên sẽ phải kiểm tra lại để quyết định liệu đó có thực sự là gian lận hay không. Mục tiêu của công ty là giảm thiểu thời gian mà nhân viên phải dành để xem xét các trường hợp không phải gian lận (tức là giảm số lượng cảnh báo sai – false positives).

Do đó, chúng ta cần một đánh giá mô hình tập trung vào độ chính xác của các dự đoán dương tính (các giao dịch mà mô hình gắn nhãn “có khả năng gian lận”).

✅ Metric cần tối ưu → Precision (độ chính xác dương tính), còn gọi là Positive Predictive Value.

✅ Đáp án đúng: Precision

• Định nghĩa:
  [
  \text{Precision} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Positives}} ]
  Nó đo lường tỷ lệ các cảnh báo dương tính mà thực sự là gian lận.
• Vì sao đáp ứng yêu cầu?
  • Khi Precision cao, phần lớn các giao dịch được gắn nhãn “có khả năng gian lận” thực sự là gian lận → số lần nhân viên phải kiểm tra các trường hợp không gian lận giảm đi.
  • Đặc biệt trong bối cảnh các vụ gian lận rất hiếm (class imbalance), việc tối ưu Precision giúp tránh việc “spam” cảnh báo vô nghĩa.

❌ Các phương án sai và lý do

• Recall

  • Định nghĩa: (\frac{\text{True Positives}}{\text{True Positives} + \text{False Negatives}}) – đo khả năng phát hiện hết tất cả các vụ gian lận.
  • Lý do sai: Tối ưu Recall thường làm tăng False Positives, nghĩa là sẽ có nhiều cảnh báo không thật gian lận, làm tăng thời gian kiểm tra của nhân viên – trái ngược với mục tiêu giảm thời gian.

• Accuracy

  • Định nghĩa: (\frac{\text{True Positives} + \text{True Negatives}}{\text{Tổng số mẫu}}).
  • Lý do sai: Trong bài toán gian lận, tỷ lệ gian lận thường rất thấp (ví dụ 0.1% – 1%). Khi đó, một mô hình luôn dự đoán “không gian lận” cũng có Accuracy rất cao nhưng hoàn toàn vô dụng. Accuracy không phản ánh được sự cân bằng giữa False Positives và False Negatives, nên không phù hợp để giảm thời gian kiểm tra.

• Lift chart

  • Định nghĩa: Là biểu đồ trực quan so sánh tỉ lệ dương tính trong các deciles của mô hình với tỉ lệ dương tính ngẫu nhiên.
  • Lý do sai: Lift chart không phải là một metric mà là công cụ đánh giá tổng quan. Nó không cung cấp một giá trị định lượng để tối ưu hóa việc giảm false positives, vì vậy không đáp ứng yêu cầu trực tiếp của câu hỏi.

📚 Tham khảo & Kiến thức cập nhật (đến năm 2026)

• AWS SageMaker Model Evaluation – hướng dẫn sử dụng Precision, Recall, F‑score trong quy trình xây dựng mô hình Machine Learning trên SageMaker.
  👉 https://docs.aws.amazon.com/sagemaker/latest/dg/model-evaluation.html

• Amazon SageMaker Clarify – cung cấp các metric bao gồm Precision, Recall, và các báo cáo bias/variance để giúp khách hàng hiểu sâu hơn về hiệu suất mô hình.
  👉 https://aws.amazon.com/sagemaker/clarify/

• AWS Well‑Architected Framework – Machine Learning Lens (2025 update) – khuyến nghị việc lựa chọn metric phù hợp với mục tiêu kinh doanh, ví dụ “tối ưu Precision khi chi phí kiểm tra thủ công cao”.
  👉 https://aws.amazon.com/architecture/well-architected/machine-learning/

• Nghiên cứu và thực tiễn: Các bài viết năm 2024‑2025 trên AWS Big Data Blog và AWS Machine Learning Blog nhấn mạnh việc đánh đổi Precision vs Recall trong các hệ thống phát hiện gian lận tài chính, khẳng định Precision là metric chính khi mục tiêu là giảm thiểu false positives.

🧩 Tổng kết

• Mục tiêu: Giảm thời gian nhân viên xem xét các cảnh báo không thực sự là gian lận → giảm false positives.
• Metric phù hợp: Precision (độ chính xác dương tính).
• Các lựa chọn khác (Recall, Accuracy, Lift chart) không đáp ứng yêu cầu vì chúng either tăng false positives, không phản ánh đúng độ hiếm của gian lận, hoặc không phải là metric định lượng.

🎯 Kết luận: Đáp án Precision là lựa chọn đúng cho yêu cầu của bài toán.

🔍 Phân tích câu hỏi

Câu hỏi đưa ra một tình huống: một công ty đã phát triển một agent AI để trả lời các câu hỏi của khách hàng dựa trên các tài liệu hướng dẫn sản phẩm.
Mục tiêu của câu hỏi là tìm ra chiến lược nào giúp nâng cao mức độ tin cậy (confidence) của khách hàng đối với câu trả lời mà agent đưa ra.

Trong bối cảnh AI sinh ra (Generative AI) ngày nay, “confidence” không chỉ là độ chắc chắn nội bộ của mô hình mà còn là cảm nhận của người dùng: người dùng muốn biết câu trả lời dựa trên nguồn thông tin nào, có thể kiểm chứng được hay không. Vì vậy, việc cung cấp các liên kết (link) tới tài liệu gốc là cách hiệu quả nhất để tạo niềm tin.

✅ Đáp án đúng

Including referenced product manual links in the response

Lý do chọn:

• Khi câu trả lời kèm theo đường dẫn tới tài liệu hướng dẫn sản phẩm gốc, khách hàng có thể tự kiểm tra, xác nhận tính chính xác và hiểu rõ ngữ cảnh.
• Đây là nguyên tắc “grounded generation” (có nguồn gốc) được AWS đề xuất trong Amazon Bedrock và Generative AI Best Practices (2024‑2026).
• Các tài liệu tham khảo giúp giảm hiện tượng “hallucination” (câu trả lời sai lệch) và tăng trust (tin cậy) của người dùng.
• Các dịch vụ như Amazon Bedrock cho phép trả về “citation metadata” kèm theo output, giúp triển khai chiến lược này một cách tự động.

Tài liệu tham khảo:

• AWS Blog – “Building trustworthy Generative AI applications with Amazon Bedrock” (2025)
• AWS Whitepaper – Generative AI Best Practices (2024) – phần “Grounded responses & source citation”.

❌ Giải thích các phương án sai

• Writing the confidence level in the response

  • Việc ghi chú mức độ confidence (ví dụ: “I’m 90% sure…”) không tăng niềm tin thực tế của khách hàng, vì người dùng không có cách kiểm chứng độ chắc chắn này.
  • Thậm chí, nếu mức confidence cao nhưng câu trả lời sai, sẽ làm giảm uy tín của hệ thống.
  • AWS không khuyến khích hiển thị confidence nội bộ mà thay vào đó nhấn mạnh các nguồn dữ liệu (Grounded Generation).

• Designing an agent avatar that looks like a computer

  • Hình ảnh avatar chỉ ảnh hưởng đến trải nghiệm người dùng (UX), không liên quan tới độ tin cậy nội dung.
  • Một avatar “máy tính” thậm chí có thể gây cảm giác lạnh lẽo, không thân thiện, làm giảm sự tin tưởng.
  • AWS không có tài liệu nào liên kết việc thiết kế avatar với cải thiện confidence của AI.

• Training the agent to respond in the company's language style

  • Việc đào tạo ngôn ngữ phù hợp với phong cách công ty giúp đồng nhất thương hiệu, nhưng không trực tiếp nâng cao mức độ tin cậy của câu trả lời.
  • Trust vẫn phụ thuộc vào độ chính xác và các nguồn tham khảo chứ không phải cách diễn đạt.
  • Tài liệu AWS nhấn mạnh: “Style consistency ≠ factual correctness”.

🧩 Tóm tắt các bước triển khai chiến lược đúng (có link tham khảo)

1. Chuẩn bị tài liệu gốc

   • Đưa các product manual lên Amazon S3 và bật S3 Object Lambda để tạo API truy xuất nội dung.
   • Gắn metadata (version, language) để Bedrock có thể trích dẫn đúng tài liệu.

2. Khai báo “grounding” trong prompt

   • Sử dụng Prompt Engineering: “When answering, cite the relevant section from the product manual and provide a URL link.”

3. Kích hoạt tính năng “Citation” trong Amazon Bedrock

   • Bedrock hỗ trợ trả về citation metadata (2025).
   • Kết hợp với AWS Lambda để chèn link vào phản hồi cuối cùng trước khi trả về cho khách hàng.

4. Kiểm thử & giám sát

   • Dùng Amazon CloudWatch và AWS X-Ray để theo dõi tỉ lệ câu trả lời có link, tỷ lệ “hallucination”.
   • Tinh chỉnh mô hình hoặc cập nhật tài liệu nếu tỷ lệ lỗi cao.

📌 Kết luận

Chiến lược cung cấp các liên kết tham chiếu tới tài liệu hướng dẫn sản phẩm là cách hiệu quả nhất để tăng mức độ tin cậy của khách hàng đối với câu trả lời của AI agent. Các phương án khác dù có lợi về mặt UI/UX hoặc phong cách ngôn ngữ, nhưng không giải quyết vấn đề cốt lõi là độ chính xác và khả năng kiểm chứng của thông tin.

Chúc bạn ôn luyện thành công! 🚀🛠️