Ngân hàng đề — Microsoft Azure AI Fundamentals

Tìm thấy 316 câu.

Câu 31
A healthcare organization is developing an application to process patient intake forms. The application needs to automatically extract and categorize information such as patient names, appointment dates, medical conditions, and hospital locations from unstructured text submitted through an online form. Which Azure AI service feature would be most appropriate for this scenario?
  1. A Entity recognition
  2. B Sentiment analysis
  3. C Language detection
  4. D Key phrase extraction
Xem giải thích

Đáp án

A — Entity recognition (nhận diện thực thể).

Vì sao đúng

⚠ Đề cần TRÍCH XUẤT và PHÂN LOẠI các mẩu thông tin cụ thể: | Thông tin | Loại thực thể | |---|---| | ⚠ Tên bệnh nhân | ⚠ Person | | ⚠ Ngày hẹn | ⚠ DateTime | | ⚠ Tình trạng bệnh | ⚠ thực thể y tế | | ⚠ Địa điểm bệnh viện | ⚠ Location |

⚠ "Nguyễn Văn A hẹn khám ngày 15/3
   tại Bệnh viện Bạch Mai, chẩn đoán viêm phổi"
        ↓ ⚠ NER
⚠ Person: Nguyễn Văn A
⚠ DateTime: 15/3
⚠ Location: Bệnh viện Bạch Mai
⚠ Diagnosis: viêm phổi

⚠ Chữ "phân loại" (categorize) trong đề là dấu hiệu của NER — ⚠ mỗi thực thể có NHÃN LOẠI.

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

  • D (key phrase extraction) — ⚠ bẫy gần nhất: ⚠ cũng trích cụm từ, ⚠ nhưng ⚠ KHÔNG PHÂN LOẠI; ⚠ không biết cụm nào là tên, cụm nào là ngày.

  • B (sentiment analysis) — ⚠ đánh giá thái độ, không trích thông tin.

  • C (language detection) — ⚠ chỉ nhận diện ngôn ngữ.

Ghi nhớ

⚠ NER so với key phrase extraction — bảng phải thuộc: | Tiêu chí | ⚠ NER | ⚠ Key phrase | |---|---|---| | ⚠ Có nhãn loại | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Đầu ra | ⚠ thực thể + loại + vị trí | ⚠ cụm từ quan trọng | | ⚠ Ca dùng | ⚠ điền vào biểu mẫu, CSDL | ⚠ hiểu chủ đề chung |

Từ khoá nhận diện:

"trích và PHÂN LOẠI thông tin" → ⚠ NER "chủ đề chính là gì" → ⚠ key phrase extraction "trích từ BIỂU MẪU có cấu trúc" → ⚠ Document Intelligence "trích từ VĂN BẢN TỰ DO" → ⚠ NER

⚠ Các loại thực thể NER dựng sẵn Loại
⚠ Person, PersonType
⚠ Location, Address
⚠ Organization
⚠ DateTime ⚠ có phân biệt Date, Time, Duration
⚠ Quantity, Number, Percentage
⚠ Email, PhoneNumber, URL, IP
⚠ Product, Event, Skill
⚠ Text Analytics for Health — cho ngành y Đặc điểm
⚠ Thực thể chuyên biệt: triệu chứng, chẩn đoán, thuốc, liều lượng
⚠ Nhận diện QUAN HỆ giữa thực thể ⚠ "thuốc X liều Y cho bệnh Z"
⚠ Phát hiện phủ định ⚠ "KHÔNG sốt" — rất quan trọng trong y tế
⚠ Liên kết tới bộ mã y tế chuẩn ⚠ UMLS, ICD
⚠ Với ca dùng trong đề ⚠ nên dùng Text Analytics for Health thay NER thường
⚠ Custom NER — khi nào cần Khi nào
⚠ Thực thể ĐẶC THÙ của tổ chức ⚠ mã hồ sơ, tên khoa, mã bảo hiểm nội bộ
⚠ Loại dựng sẵn không có
⚠ Cần huấn luyện với dữ liệu gán nhãn của mình
⚠ Kết hợp ⚠ NER dựng sẵn cho loại chung + custom cho loại riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có phát hiện phủ định không | ⚠ "không sốt" khác "sốt" hoàn toàn | | Có loại thực thể nào đặc thù cần custom không | | | Độ chính xác với tiếng Việt là bao nhiêu | |

Và tính năng bắt buộc phải có khi trích xuất thông tin y tế: phát hiện phủ định. Một hệ thống ghi nhận "sốt" từ câu "bệnh nhân không sốt" không chỉ vô dụng — nó nguy hiểm.

Câu 32
Your company is developing a generative AI application that will answer customer questions about product documentation. You need to use Azure AI Foundry to build this solution. The application must retrieve relevant information from your company's product manuals before generating responses. Which Azure AI Foundry capability should you use to implement this pattern?
  1. A Use the prompt flow feature to create a retrieval-augmented generation (RAG) pattern that combines document search with a large language model.
  2. B Use the model catalog to deploy a pre-trained large language model and send all product documentation as part of each user prompt.
  3. C Use the fine-tuning capability to retrain a foundation model with all of your company's product documentation embedded in the model weights.
  4. D Use the evaluation feature to test different models against your product documentation and select the highest-scoring model.
Xem giải thích

Đáp án

A — Dùng tính năng prompt flow để tạo mẫu RAG kết hợp tìm kiếm tài liệu với mô hình ngôn ngữ lớn.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với #17933 trong cùng lô.

Câu Ngữ cảnh
⚠ #17933 ⚠ tính năng Azure OpenAI nào → RAG
⚠ #17946 (câu này) ⚠ tính năng AI Foundry nào → prompt flow tạo RAG
⚠ Cùng kết luận ⚠ RAG là câu trả lời cho "trả lời dựa trên tài liệu riêng"

Vì sao đúng

⚠ Prompt flow là công cụ dựng luồng xử lý trong AI Foundry:

⚠ Prompt flow
   ├── ⚠ Nhận câu hỏi người dùng
   ├── ⚠ Tạo embedding
   ├── ⚠ Tìm trong Azure AI Search
   ├── ⚠ Ghép ngữ cảnh vào prompt
   ├── ⚠ Gọi mô hình ngôn ngữ
   └── ⚠ Trả câu trả lời kèm nguồn
        ↓
⚠ Đó chính là mẫu RAG

⚠ Prompt flow còn cho phép ĐÁNH GIÁ và THEO DÕI từng bước — ⚠ quan trọng để gỡ lỗi.

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

  • B (dùng model catalog, gửi TOÀN BỘ tài liệu trong mỗi prompt) — ⚠ không khả thi: ⚠ vượt giới hạn cửa sổ ngữ cảnh; ⚠ và ⚠ cực kỳ tốn kém — trả tiền cho toàn bộ tài liệu ở MỖI lời gọi.

  • C (fine-tune để nhúng tài liệu vào trọng số mô hình) — ⚠ hiểu sai về fine-tuning: ⚠ fine-tune dạy PHONG CÁCH, ⚠ không nhồi được kiến thức đáng tin; ⚠ và tài liệu đổi là phải huấn luyện lại.

  • D (dùng evaluation để chọn mô hình điểm cao nhất) — ⚠ đánh giá là bước hữu ích nhưng không giải bài toán: ⚠ mô hình tốt tới đâu cũng không biết nội dung tài liệu riêng của bạn.

Ghi nhớ

⚠ Prompt flow — thành phần: | Thành phần | Việc | |---|---| | ⚠ Input / Output | ⚠ định nghĩa đầu vào và ra của luồng | | ⚠ LLM node | ⚠ gọi mô hình ngôn ngữ | | ⚠ Python node | ⚠ mã tuỳ chỉnh | | ⚠ Prompt node | ⚠ mẫu prompt có biến | | ⚠ Vector search / Index lookup | ⚠ tìm tài liệu liên quan | | ⚠ Evaluation flow | ⚠ chấm điểm chất lượng đầu ra |

Từ khoá nhận diện:

"tìm tài liệu rồi mới sinh câu trả lời" → ⚠ RAG qua prompt flow "dạy mô hình phong cách" → ⚠ fine-tuning "so sánh nhiều mô hình" → ⚠ model catalog và evaluation "nhồi cả tài liệu vào prompt" → ⚠ không khả thi ở quy mô thật

⚠ Vì sao nhồi toàn bộ tài liệu vào prompt không được Lý do
⚠ Cửa sổ ngữ cảnh có GIỚI HẠN
⚠ Trả tiền theo TOKEN — mỗi lời gọi tính cả tài liệu
⚠ Độ trễ tăng theo độ dài prompt
⚠ Mô hình khó tập trung khi ngữ cảnh quá dài ⚠ "lost in the middle"
⚠ RAG giải quyết ⚠ chỉ đưa vào phần LIÊN QUAN
⚠ Đánh giá chất lượng RAG Chỉ số
⚠ Groundedness ⚠ câu trả lời có dựa trên tài liệu không
⚠ Relevance ⚠ có trả lời đúng câu hỏi không
⚠ Retrieval quality ⚠ đoạn lấy ra có liên quan không
⚠ Coherence, Fluency
⚠ AI Foundry có sẵn ⚠ evaluation flow cho các chỉ số này
⚠ Từ nguyên mẫu tới sản xuất Bước
⚠ Dựng prompt flow trong AI Foundry
⚠ Đánh giá bằng bộ câu hỏi mẫu
⚠ Triển khai thành endpoint
⚠ Theo dõi chất lượng và chi phí
⚠ Cải thiện chunking và tìm kiếm ⚠ nơi cải thiện nhiều nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đoạn tài liệu lấy ra có đúng không | ⚠ kiểm tra riêng khâu tìm kiếm | | Có đo groundedness không | | | Chi phí mỗi câu hỏi là bao nhiêu | |

Và hiểu lầm phổ biến nhất về fine-tuning mà câu hỏi này chỉ ra: nó không phải cách để dạy kiến thức cho mô hình. Fine-tune dạy mô hình NÓI THẾ NÀO; RAG mới cho mô hình biết NÓI GÌ.

Câu 33
A customer service team wants to implement an AI solution that can analyze incoming support emails and automatically predict the next few words as agents type their responses, helping them compose replies more quickly. Which Azure AI Language feature would best support this requirement?
  1. A Key phrase extraction
  2. B Text analytics for sentiment analysis
  3. C Named Entity Recognition (NER)
  4. D Language modeling with text completion
Xem giải thích

Đáp án

D — Language modeling với text completion (mô hình ngôn ngữ hoàn thành văn bản).

Vì sao đúng

⚠ Đề mô tả chính xác cơ chế của mô hình ngôn ngữ:

⚠ Nhân viên đang gõ:
   "Cảm ơn quý khách đã liên hệ. Chúng tôi..."
        ↓ ⚠ mô hình ngôn ngữ
⚠ Dự đoán từ tiếp theo:
   "...đã tiếp nhận yêu cầu và sẽ..."

⚠ Đây chính là bản chất của mô hình ngôn ngữ: ⚠ dự đoán token tiếp theo dựa trên ngữ cảnh phía trước.

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

  • A (key phrase extraction) — ⚠ PHÂN TÍCH văn bản đã có: ⚠ không sinh ra chữ mới.

  • B (sentiment analysis) — ⚠ đánh giá thái độ: ⚠ không gợi ý gì.

  • C (NER) — ⚠ trích thực thể: ⚠ cũng chỉ phân tích.

Ghi nhớ

⚠ Phân tích so với sinh ngữ — bảng phải thuộc: | Nhóm | Tính năng | Đầu ra | |---|---|---| | ⚠ PHÂN TÍCH | ⚠ sentiment, NER, key phrase, language detection | ⚠ thông tin VỀ văn bản | | ⚠ SINH NGỮ | ⚠ text completion, tóm tắt, dịch, trả lời | ⚠ văn bản MỚI | | ⚠ Đề hỏi "gợi ý từ tiếp theo" | ⚠ rõ ràng thuộc nhóm sinh ngữ |

Từ khoá nhận diện:

"gợi ý, hoàn thành, tiếp tục câu" → ⚠ text completion "phân tích, trích, đánh giá" → ⚠ nhóm phân tích "tóm tắt văn bản dài" → ⚠ summarization "trả lời câu hỏi từ tài liệu" → ⚠ RAG

⚠ Ứng dụng gợi ý văn bản trong hỗ trợ khách hàng Ứng dụng
⚠ Gợi ý câu trả lời hoàn chỉnh ⚠ dựa trên câu hỏi của khách
⚠ Hoàn thành câu đang gõ ⚠ đề này
⚠ Tóm tắt hội thoại dài
⚠ Đề xuất bài viết trợ giúp liên quan
⚠ Lợi ích ⚠ giảm thời gian xử lý mỗi ca, tăng tính nhất quán
⚠ Thiết kế tính năng gợi ý tốt Thiết kế
⚠ Gợi ý phải NHANH ⚠ chậm hơn tốc độ gõ là vô dụng
⚠ Dễ chấp nhận hoặc bỏ qua ⚠ phím Tab hoặc Esc
⚠ Không cản trở khi nhân viên muốn tự viết
⚠ Học từ cách nhân viên sửa gợi ý
⚠ Sai lầm ⚠ gợi ý quá dài, quá xâm lấn — nhân viên tắt đi
⚠ Rủi ro cần kiểm soát Rủi ro
⚠ Gợi ý sai thông tin ⚠ nhân viên vội bấm chấp nhận
⚠ Giọng điệu không phù hợp ngữ cảnh
⚠ Rò rỉ thông tin từ ca khác ⚠ nếu mô hình học từ dữ liệu chung
⚠ Bắt buộc ⚠ nhân viên VẪN chịu trách nhiệm nội dung gửi đi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ gợi ý là bao nhiêu | ⚠ trên 300ms là khó chịu | | Tỉ lệ nhân viên chấp nhận gợi ý | ⚠ quá thấp nghĩa là gợi ý kém | | Có kiểm soát rò rỉ thông tin giữa các ca không | |

Và chỉ số duy nhất cho biết một tính năng gợi ý văn bản có thật sự hữu ích: tỉ lệ người dùng chấp nhận gợi ý. Nếu nó thấp, tính năng đang gây phiền hơn là giúp đỡ.

Câu 34
A healthcare company wants to develop an application that allows doctors to dictate patient notes verbally during examinations, with the notes automatically converted to text and stored in the electronic health records system. Which Azure AI service feature should they implement?
  1. A Speech recognition using Speech-to-Text API
  2. B Speech synthesis using Text-to-Speech API
  3. C Translator Speech API
  4. D Language Understanding (LUIS) service
Xem giải thích

Đáp án

A — Speech recognition dùng Speech-to-Text API.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với #17919 trong cùng lô — gần như y nguyên kịch bản.

Câu Diễn đạt
⚠ #17919 ⚠ "bác sĩ đọc ghi chú, chuyển thành chữ, lưu vào hệ thống quản lý bệnh nhân"
⚠ #17948 (câu này) ⚠ "bác sĩ đọc ghi chú trong lúc khám, chuyển thành chữ, lưu vào hồ sơ điện tử"
⚠ Cùng khoá ⚠ Speech-to-Text
⚠ MD5 không bắt được ⚠ vì cách diễn đạt khác

Vì sao đúng

⚠ Chiều chuyển đổi quyết định đáp án:

⚠ Bác sĩ NÓI (âm thanh)
        ↓
⚠ Hệ thống ghi thành CHỮ
        ↓
⚠ Speech-to-Text

⚠ Nhớ một câu: ⚠ "nói ra chữ" là Speech-to-Text; "chữ đọc thành tiếng" là Text-to-Speech.

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

  • B (Text-to-Speech) — ⚠ NGƯỢC CHIỀU: ⚠ đọc văn bản thành giọng nói.

  • C (Translator Speech API) — ⚠ vừa phiên âm vừa DỊCH: ⚠ đề không cần dịch.

  • D (LUIS) — ⚠ hiểu Ý ĐỊNH từ văn bản: ⚠ không phiên âm âm thanh; ⚠ và ⚠ LUIS đang được thay bằng CLU.

Ghi nhớ

⚠ Bốn chiều của Azure AI Speech: | Từ | Sang | Dịch vụ | |---|---|---| | ⚠ Giọng nói | ⚠ chữ | ⚠ Speech-to-Text | | ⚠ Chữ | ⚠ giọng nói | ⚠ Text-to-Speech | | ⚠ Giọng nói | ⚠ chữ/giọng nói ngôn ngữ khác | ⚠ Speech Translation | | ⚠ Giọng nói | ⚠ danh tính người nói | ⚠ Speaker Recognition |

Từ khoá nhận diện:

"đọc chính tả, ghi biên bản, phiên âm" → ⚠ Speech-to-Text "đọc văn bản ra loa, trợ lý ảo nói" → ⚠ Text-to-Speech "phiên dịch trực tiếp" → ⚠ Speech Translation "xác thực bằng giọng nói" → ⚠ Speaker Recognition

⚠ Với ứng dụng y tế — cần thêm gì Cần thêm
⚠ Custom Speech model ⚠ học thuật ngữ y khoa
⚠ Phrase list ⚠ danh sách tên thuốc, tên bệnh
⚠ Dấu câu tự động
⚠ Xử lý tại chỗ nếu cần ⚠ container Speech
⚠ Không có Custom Speech ⚠ tỉ lệ lỗi với thuật ngữ chuyên môn rất cao
⚠ Ba chế độ Speech-to-Text Chế độ
⚠ Real-time ⚠ phiên âm ngay khi nói — đề này
⚠ Batch ⚠ xử lý file ghi sẵn hàng loạt
⚠ Fast transcription ⚠ file ngắn, trả nhanh
⚠ Đọc chính tả trong lúc khám ⚠ real-time
⚠ Lưu ý riêng tư với ghi âm y tế Lưu ý
⚠ Giọng nói bệnh nhân là dữ liệu nhạy cảm
⚠ Cần ký BAA nếu chịu HIPAA
⚠ Cân nhắc container tại chỗ ⚠ âm thanh không rời khỏi bệnh viện
⚠ Tắt logging phía dịch vụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ lỗi từ với thuật ngữ y khoa là bao nhiêu | ⚠ đo trên bản ghi thật | | Có dùng Custom Speech không | | | Âm thanh được xử lý ở đâu | |

Và yếu tố quyết định một hệ thống đọc chính tả y khoa có được chấp nhận: nó có nhận đúng tên thuốc và tên bệnh không. Bác sĩ sẽ ngừng dùng ngay sau vài lần phải sửa tay những từ quan trọng nhất trong câu.

Câu 35
A retail company wants to predict customer purchase amounts based on historical transaction data. They have a dataset with 50,000 records containing customer demographics, browsing history, and past purchase amounts. The data science team has limited machine learning expertise. Which capability of automated machine learning (AutoML) in Azure Machine Learning would be MOST beneficial for this scenario?
  1. A AutoML can automatically convert the regression problem into a classification problem for better accuracy.
  2. B AutoML can automatically create synthetic data to increase the dataset size beyond 50,000 records.
  3. C AutoML can automatically test multiple algorithms and hyperparameters to find the best performing model for the regression task.
  4. D AutoML can automatically generate and deploy REST API endpoints without any configuration.
Xem giải thích

Đáp án

C — AutoML có thể tự động thử nhiều thuật toán và siêu tham số để tìm mô hình tốt nhất cho bài toán hồi quy.

Vì sao đúng

⚠ Đây chính là định nghĩa của AutoML:

⚠ Bạn đưa: dữ liệu + cột mục tiêu + loại bài toán
        ↓ ⚠ AutoML tự làm
⚠ Thử nhiều thuật toán
   ⚠ linear, random forest, gradient boosting...
⚠ Thử nhiều bộ siêu tham số
⚠ Tự chuẩn hoá và mã hoá đặc trưng
        ↓
⚠ Xếp hạng và trả về mô hình TỐT NHẤT

⚠ Rất hợp với đề: ⚠ đội có ⚠ ít kinh nghiệm học máy.

⚠ Bài toán là HỒI QUY vì dự đoán ⚠ số tiền mua hàng.

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

  • A (tự chuyển bài toán hồi quy thành phân loại cho chính xác hơn) — ⚠ AutoML KHÔNG đổi loại bài toán: ⚠ bạn khai loại, nó tuân theo.

  • B (tự tạo dữ liệu tổng hợp để tăng số bản ghi) — ⚠ AutoML không sinh dữ liệu giả.

  • D (tự sinh và triển khai endpoint REST mà không cần cấu hình) — ⚠ triển khai vẫn cần bước cấu hình: ⚠ AutoML giúp triển khai dễ, ⚠ nhưng không phải "không cần cấu hình gì".

Ghi nhớ

⚠ AutoML làm gì và KHÔNG làm gì: | Làm | Không làm | |---|---| | ⚠ Thử nhiều thuật toán | ⚠ đổi loại bài toán | | ⚠ Dò siêu tham số | ⚠ tạo dữ liệu giả | | ⚠ Featurization tự động | ⚠ hiểu nghiệp vụ của bạn | | ⚠ Xếp hạng mô hình | ⚠ chọn đặc trưng nào có ý nghĩa | | ⚠ Sinh mã của mô hình tốt nhất | ⚠ thay thế hiểu biết chuyên môn |

Từ khoá nhận diện:

"ít kinh nghiệm ML, muốn nhanh" → ⚠ AutoML "cần toàn quyền kiểm soát" → ⚠ custom training "kéo thả không viết mã" → ⚠ Designer "chỉ biết SQL" → ⚠ BigQuery ML (Google) hoặc tương đương

⚠ Ba loại bài toán AutoML hỗ trợ Loại
⚠ Classification ⚠ phân loại
⚠ Regression ⚠ dự đoán số — đề này
⚠ Time series forecasting ⚠ dự báo chuỗi thời gian
⚠ Computer vision và NLP ⚠ có hỗ trợ ở mức nhất định
⚠ Bạn phải khai ⚠ loại bài toán và cột mục tiêu
⚠ Giá trị thật của AutoML Giá trị
⚠ Cho một BASELINE nhanh ⚠ biết mức tốt nhất có thể đạt được
⚠ Tiết kiệm hàng tuần thử nghiệm
⚠ Sinh mã để học và tuỳ biến tiếp
⚠ Giải thích tầm quan trọng đặc trưng
⚠ Dùng đúng cách ⚠ là điểm KHỞI ĐẦU, không phải điểm kết thúc
⚠ Việc AutoML KHÔNG thay được Việc
⚠ Hiểu bài toán nghiệp vụ
⚠ Chuẩn bị dữ liệu sạch
⚠ Phát hiện rò rỉ dữ liệu ⚠ AutoML sẽ vui vẻ dùng cột rò rỉ và cho kết quả đẹp giả
⚠ Quyết định ngưỡng và cách triển khai
⚠ Cảnh báo ⚠ AutoML cho kết quả quá đẹp thường là dấu hiệu rò rỉ dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả có đẹp bất thường không | ⚠ kiểm tra rò rỉ dữ liệu | | Đặc trưng nào quan trọng nhất | ⚠ có hợp lý về nghiệp vụ không | | Đã bỏ cột định danh khỏi đặc trưng chưa | ⚠ CustomerID không nên là đầu vào |

Và điều AutoML không bao giờ làm thay bạn: nhận ra rằng một cột trong dữ liệu chứa thông tin từ tương lai. Nó sẽ dùng cột đó, cho ra độ chính xác 99%, và bạn chỉ phát hiện ra khi mô hình sụp đổ trong sản xuất.

Câu 36
A healthcare organization is deploying an AI system that helps doctors diagnose patient conditions based on medical imaging. The project manager wants to ensure the solution meets transparency requirements. Which action would BEST demonstrate transparency in this AI solution?
  1. A Encrypt all patient data and medical images before processing them through the AI system.
  2. B Implement role-based access control to ensure only authorized medical staff can use the AI system.
  3. C Schedule regular system backups and maintain redundant servers to ensure high availability.
  4. D Provide doctors with clear documentation explaining how the AI model makes diagnostic suggestions and what data it was trained on.
Xem giải thích

Đáp án

D — Cung cấp cho bác sĩ tài liệu rõ ràng giải thích mô hình đưa ra gợi ý chẩn đoán như thế nào và được huấn luyện trên dữ liệu gì.

Vì sao đúng

⚠ Minh bạch (transparency) nghĩa là người dùng HIỂU hệ thống: | Cần minh bạch về | Nội dung | |---|---| | ⚠ Cách hoạt động | ⚠ mô hình dựa trên gì để đưa gợi ý | | ⚠ Dữ liệu huấn luyện | ⚠ từ đâu, đại diện cho nhóm nào | | ⚠ Giới hạn | ⚠ hoạt động kém trong trường hợp nào | | ⚠ Mức độ tin cậy | ⚠ điểm confidence nghĩa là gì |

⚠ Bác sĩ biết mô hình học từ đâu
        ↓
⚠ Biết khi nào NÊN tin, khi nào cần thận trọng
        ↓
⚠ Sử dụng công cụ đúng cách

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

  • A (mã hoá dữ liệu và ảnh y tế) — ⚠ thuộc Privacy & Security: ⚠ quan trọng nhưng không phải minh bạch.

  • B (kiểm soát truy cập theo vai trò) — ⚠ cũng thuộc Privacy & Security.

  • C (sao lưu định kỳ và máy chủ dự phòng) — ⚠ thuộc Reliability & Safety: ⚠ về độ sẵn sàng.

Ghi nhớ

⚠ Sáu nguyên tắc — ánh xạ với hành động: | Hành động | Nguyên tắc | |---|---| | ⚠ Tài liệu giải thích cách hoạt động | ⚠ Transparency | | ⚠ Mã hoá, phân quyền | ⚠ Privacy & Security | | ⚠ Sao lưu, dự phòng, giám sát hiệu năng | ⚠ Reliability & Safety | | ⚠ Đo kết quả theo nhóm | ⚠ Fairness | | ⚠ Ghi log, truy vết | ⚠ Accountability | | ⚠ Hỗ trợ người khuyết tật | ⚠ Inclusiveness |

Từ khoá nhận diện:

"người dùng hiểu hệ thống làm gì" → ⚠ Transparency "bảo vệ dữ liệu" → ⚠ Privacy & Security "hoạt động ổn định, đúng" → ⚠ Reliability & Safety "ai chịu trách nhiệm" → ⚠ Accountability

⚠ Transparency gồm những gì Gồm
⚠ Cho biết đang tương tác với AI ⚠ không giả làm người
⚠ Giải thích cách hệ thống ra quyết định
⚠ Công bố giới hạn và trường hợp không nên dùng
⚠ Nêu rõ dữ liệu huấn luyện
⚠ Công cụ Microsoft ⚠ Transparency Note cho từng dịch vụ AI
⚠ Giải thích được (explainability) — kỹ thuật Kỹ thuật
⚠ Feature importance ⚠ đặc trưng nào ảnh hưởng nhiều
⚠ SHAP values ⚠ đóng góp của từng đặc trưng cho MỘT dự đoán
⚠ Grad-CAM / saliency map ⚠ tô sáng vùng ảnh mô hình chú ý
⚠ Counterfactual ⚠ "nếu chỉ số này khác đi thì kết quả sẽ ra sao"
⚠ Với ảnh y tế ⚠ saliency map rất hữu ích cho bác sĩ
⚠ Vì sao minh bạch đặc biệt quan trọng trong y tế Lý do
⚠ Bác sĩ phải chịu trách nhiệm cuối cùng ⚠ cần hiểu để quyết định
⚠ Quy định y tế thường bắt buộc
⚠ Xây dựng niềm tin để công cụ được dùng
⚠ Phát hiện khi mô hình lý luận sai ⚠ dù kết quả đúng
⚠ Không minh bạch ⚠ bác sĩ hoặc từ chối dùng, hoặc tin mù quáng — cả hai đều tệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có tài liệu về giới hạn của hệ thống không | | | Có công cụ giải thích từng dự đoán không | | | Người dùng có biết đang dùng AI không | |

Và hậu quả của việc thiếu minh bạch trong công cụ AI y tế: bác sĩ sẽ rơi vào một trong hai thái cực. Hoặc họ không tin và bỏ qua hoàn toàn, hoặc họ tin mù quáng mà không kiểm tra — và cả hai đều nguy hiểm hơn là không có công cụ.

Câu 37
A retail company wants to automatically analyze customer-uploaded product photos on their website to detect if the images contain inappropriate content before displaying them publicly. The solution should identify adult content, violent imagery, and other potentially offensive material. Which Azure AI Vision capability should the company implement?
  1. A Content Moderation
  2. B Optical Character Recognition (OCR)
  3. C Face Detection
  4. D Object Detection
Xem giải thích

Đáp án

A — Content Moderation (kiểm duyệt nội dung).

Ghi nhớ về chất lượng câu hỏi

⚠ Tên dịch vụ trong đề đã thay đổi.

Thời điểm Dịch vụ
⚠ Khi đề được soạn ⚠ Azure Content Moderator
⚠ Hiện nay ⚠ Azure AI Content Safety
⚠ Content Moderator ⚠ ngừng nhận khách mới

⚠ KHÔNG sửa khoá — ⚠ khái niệm kiểm duyệt nội dung vẫn đúng, ⚠ chỉ tên sản phẩm đổi.

Vì sao đúng

⚠ Đề cần phát hiện nội dung không phù hợp trong ẢNH người dùng tải lên: | Loại nội dung | Content Safety phát hiện | |---|---| | ⚠ Nội dung người lớn | ⚠ Sexual | | ⚠ Hình ảnh bạo lực | ⚠ Violence | | ⚠ Nội dung gây khó chịu khác | ⚠ Hate, Self-harm |

⚠ Khách tải ảnh lên
        ↓ ⚠ Content Safety - Analyze Image
⚠ Bốn hạng mục, mỗi hạng mục có mức độ
        ↓
⚠ Vượt ngưỡng → ⚠ chặn hoặc đưa người duyệt
⚠ Dưới ngưỡng → ⚠ hiển thị công khai

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

  • D (object detection) — ⚠ tìm ĐỐI TƯỢNG trong ảnh: ⚠ không đánh giá tính phù hợp.

  • C (face detection) — ⚠ tìm khuôn mặt.

  • B (OCR) — ⚠ đọc chữ trong ảnh: ⚠ có thể bổ trợ (chữ trong ảnh cũng có thể phản cảm), ⚠ nhưng không phải công cụ chính.

Ghi nhớ

⚠ Azure AI Content Safety — bốn hạng mục: | Hạng mục | Nội dung | |---|---| | ⚠ Hate | ⚠ thù ghét, phân biệt đối xử | | ⚠ Sexual | ⚠ nội dung tình dục | | ⚠ Violence | ⚠ bạo lực | | ⚠ Self-harm | ⚠ tự làm hại bản thân | | ⚠ Mỗi hạng mục | ⚠ có mức độ nghiêm trọng 0, 2, 4, 6 |

Từ khoá nhận diện:

"kiểm duyệt ảnh hoặc văn bản người dùng tải lên" → ⚠ Content Safety "kiểm duyệt VIDEO" → ⚠ Video Indexer "danh sách từ cấm riêng" → ⚠ blocklist của Content Safety "chống prompt injection" → ⚠ Prompt Shields

⚠ Thiết kế quy trình kiểm duyệt ảnh Quy trình
⚠ Ảnh tải lên → bucket TẠM ⚠ chưa công khai
⚠ Gọi Content Safety
⚠ Mức cao → chặn tự động, thông báo người dùng
⚠ Mức trung bình → hàng chờ người duyệt
⚠ Mức thấp → công khai
⚠ Quan trọng ⚠ KHÔNG công khai trước khi kiểm duyệt xong
⚠ Đặt ngưỡng thế nào Ngưỡng
⚠ Không có con số chuẩn cho mọi nền tảng
⚠ Phụ thuộc đối tượng người dùng và pháp lý
⚠ Nền tảng cho trẻ em → ngưỡng rất chặt
⚠ Cộng đồng người lớn → có thể nới hơn
⚠ Cách làm ⚠ thử trên tập ảnh thật, đo tỉ lệ chặn nhầm
⚠ Đừng quên đường khiếu nại Vì sao
⚠ Máy CHẮC CHẮN sẽ chặn nhầm
⚠ Người dùng bị chặn oan mà không kêu được sẽ rời bỏ
⚠ Cần quy trình người rà soát lại
⚠ Ghi log mọi quyết định ⚠ để giải trình và cải thiện

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh có được công khai trước khi kiểm duyệt không | ⚠ không được | | Tỉ lệ chặn nhầm là bao nhiêu | | | Có đường khiếu nại không | |

Và thiết kế sai lầm khiến mọi hệ thống kiểm duyệt trở nên vô nghĩa: cho hiển thị công khai trước rồi kiểm duyệt sau. Chỉ vài phút nội dung xấu xuất hiện cũng đủ để gây thiệt hại không thu hồi được.

Câu 38
A retail company wants to implement an AI solution that can automatically monitor their store shelves and send alerts to staff when products are running low or out of stock. The solution needs to analyze images from cameras positioned throughout the store to identify which products are present and estimate their quantities. Which type of computer vision workload does this scenario represent?
  1. A Optical Character Recognition (OCR)
  2. B Facial recognition
  3. C Image classification
  4. D Object detection
Xem giải thích

Đáp án

D — Object detection (phát hiện đối tượng).

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với #17930 trong cùng lô.

Câu Bối cảnh
⚠ #17930 ⚠ đếm xe đẩy, phát hiện người trong khu vực hạn chế
⚠ #17952 (câu này) ⚠ nhận diện sản phẩm trên kệ và ước lượng số lượng
⚠ Cùng khoá ⚠ object detection
⚠ Cùng lý do ⚠ cần ĐẾM và biết VỊ TRÍ

Vì sao đúng

⚠ Hai yêu cầu, cả hai đều đòi object detection: | Yêu cầu | Vì sao | |---|---| | ⚠ Nhận ra sản phẩm NÀO có trên kệ | ⚠ nhiều loại trong một ảnh | | ⚠ ƯỚC LƯỢNG SỐ LƯỢNG | ⚠ phải đếm từng món |

⚠ Ảnh kệ hàng
        ↓ ⚠ Object detection
⚠ "12 hộp sữa A tại (x,y)..."
⚠ "3 chai nước B tại (x,y)..."
        ↓
⚠ So với mức tồn kho tối thiểu
        ↓
⚠ Cảnh báo nhân viên bổ sung hàng

⚠ Image classification chỉ nói "ảnh này có sữa" — ⚠ không đếm được.

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

  • C (image classification) — ⚠ một nhãn cho cả ảnh: ⚠ không đếm, không định vị.

  • A (OCR) — ⚠ đọc chữ: ⚠ có thể bổ trợ đọc nhãn sản phẩm, ⚠ nhưng không đếm số lượng.

  • B (facial recognition) — ⚠ nhận diện người: ⚠ hoàn toàn không liên quan tới kệ hàng.

Ghi nhớ

⚠ Khi nào cần object detection — quy tắc: | Cần gì | Loại | |---|---| | ⚠ ĐẾM số lượng | ⚠ object detection | | ⚠ Biết VỊ TRÍ | ⚠ object detection | | ⚠ Nhiều loại trong một ảnh | ⚠ object detection | | ⚠ Chỉ cần một nhãn cho cả ảnh | ⚠ classification |

Từ khoá nhận diện:

"đếm, bao nhiêu, ở đâu" → ⚠ object detection "ảnh này thuộc loại nào" → ⚠ classification "đọc chữ trên nhãn" → ⚠ OCR "vùng chính xác từng pixel" → ⚠ segmentation

⚠ Giám sát kệ hàng — thách thức thực tế Thách thức
⚠ Sản phẩm xếp CHỒNG, che nhau ⚠ đếm được cái nhìn thấy, không đếm được cái sau
⚠ Nhiều SKU trông rất giống nhau
⚠ Ánh sáng thay đổi trong ngày
⚠ Góc camera cố định, sản phẩm bị lệch
⚠ Vì vậy đề dùng chữ ⚠ "ƯỚC LƯỢNG số lượng" — không phải đếm chính xác
⚠ Dựng giải pháp này thế nào Cách
⚠ Custom Vision object detection ⚠ huấn luyện với sản phẩm của chính cửa hàng
⚠ Cần gán nhãn bounding box ⚠ tốn công nhất
⚠ Xuất domain compact để chạy tại chỗ
⚠ Kết hợp với dữ liệu bán hàng ⚠ tăng độ chính xác ước lượng
⚠ Có giải pháp dựng sẵn ⚠ Azure AI Vision Product Recognition
⚠ Kiến trúc xử lý ảnh cửa hàng Kiến trúc
⚠ Camera chụp theo chu kỳ ⚠ không cần video liên tục
⚠ Xử lý ở BIÊN ⚠ giảm băng thông
⚠ Chỉ gửi kết quả lên đám mây
⚠ Cảnh báo qua ứng dụng của nhân viên
⚠ Tần suất chụp ⚠ vài phút một lần là đủ cho tồn kho

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ chính xác đếm là bao nhiêu | ⚠ so với kiểm kê tay | | Sản phẩm che nhau xử lý thế nào | | | Cảnh báo có đến đúng người đúng lúc không | |

Và giới hạn vật lý mà mọi hệ thống đếm hàng trên kệ bằng camera đều gặp: nó chỉ thấy được lớp sản phẩm phía trước. Vì vậy kết quả luôn là ước lượng, và cần kết hợp với dữ liệu bán hàng để suy ra tồn kho thật.

Câu 39
Your company is developing a speech-to-text AI solution that will be used in a global customer service application. During testing, you discover that the system performs significantly better with North American accents compared to accents from other regions. What should be your PRIMARY concern from an AI inclusiveness perspective?
  1. A The solution may exclude or provide poor service to users from underrepresented demographic groups, creating an inequitable experience.
  2. B The solution will require more computational resources to process non-North American accents, increasing operational costs.
  3. C The solution may need to support multiple languages, which will extend the development timeline.
  4. D The solution should be retrained using only North American accent data to optimize performance for the majority of users.
Xem giải thích

Đáp án

A — Giải pháp có thể LOẠI TRỪ hoặc phục vụ kém người dùng thuộc nhóm ít được đại diện, tạo ra trải nghiệm không công bằng.

Vì sao đúng

⚠ Inclusiveness (tính bao trùm) nghĩa là AI phải phục vụ được MỌI NGƯỜI:

⚠ Hệ thống nhận diện giọng nói
   ⚠ hoạt động tốt với giọng Bắc Mỹ
   ⚠ hoạt động KÉM với giọng vùng khác
        ↓
⚠ Người dùng vùng khác gặp trải nghiệm tệ
        ↓
⚠ Thực chất là bị LOẠI TRỪ khỏi dịch vụ

⚠ Nguyên nhân gốc: ⚠ dữ liệu huấn luyện thiếu đại diện cho các giọng khác.

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

  • D (huấn luyện lại CHỈ bằng giọng Bắc Mỹ để tối ưu cho đa số) — ⚠ làm vấn đề TỆ HƠN: ⚠ chủ động loại trừ nhóm thiểu số.

  • B (tốn thêm tài nguyên tính toán, tăng chi phí) — ⚠ không phải vấn đề thật: ⚠ và ⚠ hoàn toàn không phải mối quan tâm về tính bao trùm.

  • C (cần hỗ trợ nhiều ngôn ngữ, kéo dài thời gian phát triển) — ⚠ nhầm GIỌNG với NGÔN NGỮ: ⚠ vấn đề ở đây là cùng tiếng Anh nhưng khác giọng.

Ghi nhớ

⚠ Inclusiveness — nội dung phải thuộc: | Khía cạnh | Nội dung | |---|---| | ⚠ Đa dạng nhân khẩu | ⚠ chủng tộc, độ tuổi, giới tính, vùng miền | | ⚠ Khả năng tiếp cận | ⚠ người khuyết tật dùng được | | ⚠ Đa dạng ngôn ngữ và giọng | ⚠ đề này | | ⚠ Đa dạng bối cảnh sử dụng | ⚠ thiết bị, mạng, môi trường |

Từ khoá nhận diện:

"nhóm người dùng bị phục vụ kém" → ⚠ Inclusiveness "kết quả chênh lệch giữa các nhóm" → ⚠ Fairness "người khuyết tật dùng được" → ⚠ Inclusiveness / Accessibility ⚠ Fairness và Inclusiveness chồng lấn nhiều — đọc kỹ đề hỏi khía cạnh nào

⚠ Cách khắc phục vấn đề trong đề Cách
⚠ Thu thập thêm dữ liệu giọng đa dạng ⚠ gốc rễ của vấn đề
⚠ Custom Speech với dữ liệu giọng địa phương
⚠ Đo tỉ lệ lỗi từ RIÊNG cho từng nhóm giọng
⚠ Cho phép người dùng chọn biến thể ngôn ngữ ⚠ en-US, en-GB, en-IN, en-AU
⚠ Đừng chỉ nhìn ⚠ tỉ lệ lỗi trung bình toàn hệ thống
⚠ Fairness so với Inclusiveness Phân biệt
⚠ Fairness ⚠ hệ thống ĐỐI XỬ công bằng — không thiên vị nhóm nào
⚠ Inclusiveness ⚠ mọi người ĐỀU DÙNG ĐƯỢC — không ai bị loại trừ
⚠ Ví dụ Fairness ⚠ mô hình tín dụng duyệt vay khác nhau theo vùng
⚠ Ví dụ Inclusiveness ⚠ hệ thống giọng nói không nhận ra giọng của bạn
⚠ Thực tế ⚠ hai nguyên tắc này thường đi cùng nhau
⚠ Kiểm thử tính bao trùm Kiểm thử
⚠ Đo chỉ số theo TỪNG nhóm người dùng
⚠ Mời người dùng đa dạng thử nghiệm
⚠ Kiểm thử với thiết bị và mạng khác nhau
⚠ Kiểm thử khả năng tiếp cận ⚠ trình đọc màn hình, tương phản
⚠ Nguyên tắc ⚠ không thể phát hiện điều bạn không đo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ lỗi có được đo theo từng nhóm giọng không | | | Dữ liệu huấn luyện có đại diện cho người dùng thật không | | | Nhóm thử nghiệm có đa dạng không | |

Và cách một sản phẩm AI vô tình loại trừ người dùng mà đội phát triển không hề biết: họ chỉ đo chỉ số trung bình. Con số tổng thể trông rất tốt, và một nhóm người dùng vẫn không dùng được sản phẩm.

Câu 40
You are developing a machine learning model to predict whether a customer will purchase a product based on their browsing history. Your dataset contains the following columns: CustomerID, Age, TimeOnSite, PagesViewed, PreviousPurchases, and ProductPurchased. The ProductPurchased column contains values of either "Yes" or "No". Which column should be identified as the label for training your model?
  1. A TimeOnSite
  2. B CustomerID
  3. C PreviousPurchases
  4. D ProductPurchased
Xem giải thích

Đáp án

D — ProductPurchased.

Vì sao đúng

⚠ Đề hỏi cột nào là NHÃN (label / target) — thứ mô hình phải dự đoán. | Cột | Vai trò | |---|---| | ⚠ CustomerID | ⚠ ĐỊNH DANH — nên LOẠI khỏi mô hình | | ⚠ Age, TimeOnSite, PagesViewed, PreviousPurchases | ⚠ ĐẶC TRƯNG (features) | | ⚠ ProductPurchased | ⚠ NHÃN — giá trị "Yes"/"No" cần dự đoán |

⚠ Đề nói rõ: dự đoán KHÁCH CÓ MUA HAY KHÔNG
        ↓
⚠ Cột chứa "Yes"/"No" chính là thứ cần dự đoán
        ↓
⚠ ProductPurchased = NHÃN

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

  • A (TimeOnSite), C (PreviousPurchases) — ⚠ là ĐẶC TRƯNG: ⚠ thông tin đầu vào để dự đoán.

  • B (CustomerID) — ⚠ là ĐỊNH DANH: ⚠ ⚠ phải LOẠI BỎ khỏi mô hình — ⚠ mã khách hàng không mang thông tin dự đoán, ⚠ và có thể gây quá khớp.

Ghi nhớ

⚠ Ba loại cột trong tập dữ liệu — bảng phải thuộc: | Loại | Vai trò | Xử lý | |---|---|---| | ⚠ Nhãn (label/target) | ⚠ thứ cần dự đoán | ⚠ tách ra làm y | | ⚠ Đặc trưng (features) | ⚠ đầu vào cho mô hình | ⚠ giữ, tiền xử lý | | ⚠ Định danh (identifier) | ⚠ mã, ID | ⚠ LOẠI BỎ |

Từ khoá nhận diện:

"cột cần dự đoán" → ⚠ label / target "thông tin dùng để dự đoán" → ⚠ features "mã định danh" → ⚠ loại bỏ "Yes/No" → ⚠ thường là nhãn của bài toán phân loại nhị phân

⚠ Vì sao phải bỏ cột định danh Lý do
⚠ ID không mang thông tin nghiệp vụ
⚠ Mô hình có thể HỌC THUỘC từng ID ⚠ quá khớp nghiêm trọng
⚠ Khách hàng mới có ID mới, mô hình không biết gì
⚠ Ngoại lệ hiếm ⚠ nếu ID mã hoá thông tin thật (ví dụ tiền tố là mã vùng), thì TÁCH thông tin đó ra thành đặc trưng riêng
⚠ Rò rỉ dữ liệu qua đặc trưng — cảnh giác Cảnh giác
⚠ Đặc trưng chỉ có SAU khi biết nhãn ⚠ ví dụ "ngày giao hàng" trong bài toán dự đoán mua
⚠ Đặc trưng tính từ chính nhãn
⚠ Trong đề này ⚠ PreviousPurchases an toàn vì là lịch sử TRƯỚC ĐÓ
⚠ Kiểm tra ⚠ hỏi: tại thời điểm dự đoán, tôi có biết giá trị này không
⚠ Loại bài toán từ nhãn "Yes"/"No" Loại
⚠ Nhãn hai giá trị ⚠ binary classification
⚠ Nhãn nhiều giá trị rời rạc ⚠ multi-class classification
⚠ Nhãn là số liên tục ⚠ regression
⚠ Không có nhãn ⚠ clustering
⚠ Nhìn cột nhãn ⚠ là biết ngay loại bài toán

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã loại cột định danh chưa | | | Có đặc trưng nào chứa thông tin từ tương lai không | | | Nhãn có bị mất cân bằng không | ⚠ 90% "No" thì cần xử lý riêng |

Và câu hỏi đơn giản giúp phát hiện rò rỉ dữ liệu trước khi nó phá hỏng cả dự án: tại thời điểm cần dự đoán, tôi có thật sự biết giá trị của cột này không?. Nếu câu trả lời là không, cột đó phải bị loại.