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

Tìm thấy 316 câu.

Câu 61
Your organization is developing a customer service chatbot and needs to select an appropriate language model from Azure AI Foundry. The development team wants to compare different models' capabilities, view their performance benchmarks, and understand their licensing terms before deployment. Which feature of Azure AI Foundry should they use?
  1. A Azure AI Foundry model catalog to browse and compare available models
  2. B Azure Machine Learning designer to build a custom model from scratch
  3. C Azure OpenAI Service playground to test prompts only
  4. D Azure Cognitive Services APIs to access pre-configured models
Xem giải thích

Đáp án

A — Azure AI Foundry model catalog để duyệt và so sánh các mô hình có sẵn.

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

⚠ Câu này GẦN TRÙNG với #17916 ở lô trước — gần như y nguyên.

Câu Diễn đạt
⚠ #17916 (lô 161) ⚠ "so sánh năng lực, xem điều khoản giấy phép, thử với prompt mẫu"
⚠ #17975 (câu này) ⚠ "so sánh năng lực, xem benchmark hiệu năng, hiểu điều khoản giấy phép"
⚠ Cùng khoá ⚠ model catalog
⚠ MD5 không bắt được ⚠ vì vài từ khác

Vì sao đúng

⚠ Model catalog là nơi DUY NHẤT làm được cả ba việc: | Việc | Model catalog | |---|---| | ⚠ Duyệt mô hình từ nhiều nhà cung cấp | ⚠ OpenAI, Meta, Mistral, Cohere, Microsoft… | | ⚠ Xem benchmark hiệu năng | ⚠ bảng so sánh chỉ số | | ⚠ Xem điều khoản giấy phép | ⚠ hiển thị cho từng mô hình |

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

  • C (Azure OpenAI playground chỉ để thử prompt) — ⚠ chỉ mô hình OpenAI: ⚠ không so sánh được với mô hình của hãng khác; ⚠ không có thông tin giấy phép đa nhà cung cấp.

  • B (Azure ML designer để xây mô hình từ đầu) — ⚠ không liên quan tới chọn mô hình ngôn ngữ có sẵn.

  • D (Cognitive Services API truy cập mô hình cấu hình sẵn) — ⚠ API dựng sẵn cho tác vụ cụ thể: ⚠ không phải nơi so sánh mô hình ngôn ngữ.

Ghi nhớ

⚠ Tiêu chí so sánh mô hình — bảng phải thuộc: | Tiêu chí | Nội dung | |---|---| | ⚠ Năng lực | ⚠ chất lượng cho tác vụ CỦA BẠN, không phải benchmark chung | | ⚠ Chi phí | ⚠ giá theo token đầu vào và đầu ra | | ⚠ Độ trễ | ⚠ mô hình nhỏ nhanh hơn nhiều | | ⚠ Cửa sổ ngữ cảnh | ⚠ xử lý được bao nhiêu token | | ⚠ Giấy phép | ⚠ được dùng thương mại không | | ⚠ Cách triển khai | ⚠ serverless API hay managed compute |

Từ khoá nhận diện:

"so sánh nhiều mô hình, xem giấy phép" → ⚠ model catalog "thử prompt tương tác" → ⚠ playground "dựng luồng RAG" → ⚠ prompt flow "đánh giá có hệ thống" → ⚠ evaluation

⚠ Cảnh giác với benchmark công khai Cảnh giác
⚠ Benchmark đo tác vụ CHUNG, không phải tác vụ của bạn
⚠ Mô hình có thể đã "thấy" dữ liệu benchmark khi huấn luyện
⚠ Điểm cao không đảm bảo phù hợp với ca dùng cụ thể
⚠ Cách đúng ⚠ tự lập bộ kiểm thử từ dữ liệu THẬT của mình
⚠ Quy trình chọn mô hình có kỷ luật Quy trình
⚠ 1. Lập bộ 50-100 câu hỏi thật kèm đáp án mong đợi
⚠ 2. Chọn 3-4 mô hình ứng viên từ catalog
⚠ 3. Chạy cùng bộ kiểm thử cho tất cả
⚠ 4. So sánh chất lượng, chi phí, độ trễ
⚠ 5. Chọn mô hình NHỎ NHẤT đạt yêu cầu
⚠ Bỏ bước 1 ⚠ mọi so sánh chỉ là cảm tính
⚠ Vì sao nên bắt đầu từ mô hình nhỏ Lý do
⚠ Rẻ hơn hàng chục lần
⚠ Nhanh hơn nhiều
⚠ Rất nhiều tác vụ không cần mô hình lớn
⚠ Nâng cấp khi ⚠ ĐO được rằng mô hình nhỏ không đủ, không phải vì cảm giác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bộ kiểm thử từ dữ liệu thật không | | | Đã thử mô hình nhỏ chưa | | | Giấy phép có cho dùng thương mại không | |

Và sai lầm tốn kém nhất khi chọn mô hình ngôn ngữ: chọn theo bảng xếp hạng công khai thay vì theo dữ liệu của chính mình. Mô hình đứng đầu benchmark chưa chắc là mô hình tốt nhất cho tài liệu và câu hỏi của bạn.

Câu 62
A retail company wants to develop a solution that can automatically identify and classify products in images uploaded by customers to their mobile app. The solution needs to distinguish between thousands of different product types without requiring manual feature engineering. Which characteristic of deep learning makes it most suitable for this scenario?
  1. A Deep learning models require small amounts of training data to achieve accurate results.
  2. B Deep learning models can only process structured tabular data effectively.
  3. C Deep learning models can automatically learn hierarchical features from raw image data through multiple layers of processing.
  4. D Deep learning models use simple linear algorithms that are easy to interpret.
Xem giải thích

Đáp án

C — Mô hình học sâu có thể TỰ ĐỘNG học các đặc trưng phân cấp từ dữ liệu ảnh thô thông qua nhiều lớp xử lý.

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

⚠ Câu này GẦN TRÙNG với #17915 ở lô trước.

Câu Bối cảnh
⚠ #17915 (lô 161) ⚠ phân tích ảnh X-quang tìm bất thường
⚠ #17976 (câu này) ⚠ phân loại hàng nghìn loại sản phẩm từ ảnh khách tải lên
⚠ Cùng khoá ⚠ tự học đặc trưng phân cấp từ dữ liệu thô

Vì sao đúng

⚠ Đề nhấn "KHÔNG cần kỹ thuật đặc trưng thủ công":

⚠ Học máy truyền thống
   ⚠ người phải nghĩ ra: "đo màu chủ đạo",
     "đếm cạnh", "tính tỉ lệ khung"
        ↓ ⚠ với HÀNG NGHÌN loại sản phẩm
   ⚠ bất khả thi

⚠ HỌC SÂU
   ⚠ Lớp đầu: cạnh, màu
   ⚠ Lớp giữa: hình dạng, hoạ tiết
   ⚠ Lớp sâu: bộ phận sản phẩm
   ⚠ Lớp cuối: loại sản phẩm
        ↓
⚠ TỰ HỌC toàn bộ từ ảnh thô

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

  • A (học sâu cần ÍT dữ liệu huấn luyện) — ⚠ NGƯỢC LẠI: ⚠ học sâu đòi rất nhiều dữ liệu.

  • B (học sâu chỉ xử lý hiệu quả dữ liệu bảng) — ⚠ NGƯỢC: ⚠ với dữ liệu BẢNG, ⚠ gradient boosting thường thắng học sâu; ⚠ học sâu vượt trội ở ảnh, âm thanh, văn bản.

  • D (học sâu dùng thuật toán tuyến tính đơn giản, dễ diễn giải) — ⚠ hoàn toàn sai: ⚠ mạng nơ-ron sâu phi tuyến và nổi tiếng khó diễn giải.

Ghi nhớ

⚠ Học sâu — bốn đặc điểm phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Tự trích đặc trưng | ⚠ ưu điểm lớn nhất | | ⚠ Cần NHIỀU dữ liệu | | | ⚠ Cần GPU/TPU | | | ⚠ Khó diễn giải | ⚠ hộp đen |

Từ khoá nhận diện:

"tự học đặc trưng từ dữ liệu thô" → ⚠ học sâu "cần ít dữ liệu" → ⚠ học máy truyền thống hoặc transfer learning "dễ giải thích" → ⚠ cây quyết định, hồi quy tuyến tính "dữ liệu bảng" → ⚠ gradient boosting thường tốt hơn

⚠ Transfer learning — giải bài toán thiếu dữ liệu Kỹ thuật
⚠ Dùng mô hình đã huấn luyện trên tập ảnh khổng lồ ⚠ ImageNet
⚠ Huấn luyện tiếp trên dữ liệu ít của mình
⚠ Giảm nhu cầu từ hàng triệu xuống hàng nghìn ảnh
⚠ Custom Vision ⚠ dùng chính kỹ thuật này — chỉ cần 15-50 ảnh mỗi nhãn
⚠ Hàng nghìn loại sản phẩm — thách thức riêng Thách thức
⚠ Cần dữ liệu cho MỖI loại
⚠ Nhiều loại trông rất giống nhau
⚠ Sản phẩm mới liên tục xuất hiện ⚠ phải huấn luyện lại
⚠ Cách tiếp cận thực tế ⚠ phân cấp: phân loại nhóm lớn trước, rồi phân loại chi tiết trong nhóm
⚠ Hoặc ⚠ dùng embedding và tìm kiếm ảnh tương tự thay vì phân loại cứng
⚠ Tìm kiếm bằng embedding — lựa chọn khác Cách
⚠ Biến ảnh thành vector
⚠ So sánh với vector của catalog
⚠ Sản phẩm MỚI chỉ cần thêm vector, KHÔNG cần huấn luyện lại
⚠ Ưu điểm lớn ⚠ với catalog thay đổi liên tục, cách này linh hoạt hơn nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu ảnh cho mỗi loại sản phẩm | | | Sản phẩm mới xuất hiện với tần suất nào | ⚠ quyết định chọn phân loại hay embedding | | Đã cân nhắc transfer learning chưa | |

Và giới hạn thực tế của cách tiếp cận phân loại cứng khi catalog có hàng nghìn mặt hàng: mỗi lần thêm sản phẩm mới là một lần huấn luyện lại. Với một cửa hàng thương mại điện tử thay đổi hàng tuần, tìm kiếm bằng embedding thường là lựa chọn bền vững hơn.

Câu 63
A logistics company receives thousands of delivery receipts daily as scanned images and photographs. The company needs to extract customer signatures, printed delivery addresses, and handwritten notes from these documents to store in a database for tracking purposes. Which Azure AI service feature would be most appropriate for this scenario?
  1. A Azure AI Document Intelligence's Read API to extract printed and handwritten text from the delivery receipts
  2. B Azure AI Speech's speech-to-text service to transcribe spoken delivery information
  3. C Azure AI Vision's Image Analysis API to detect and classify objects in the delivery receipts
  4. D Azure AI Custom Vision to identify different types of delivery receipt formats
Xem giải thích

Đáp án

A — Read API của Azure AI Document Intelligence để trích xuất cả chữ in lẫn chữ viết tay từ biên nhận giao hàng.

Vì sao đúng

⚠ Đề cần trích BA loại nội dung, tất cả đều là chữ trên ảnh: | Nội dung | Read API | |---|---| | ⚠ Chữ ký khách hàng | ⚠ nhận diện được vùng chữ viết tay | | ⚠ Địa chỉ giao hàng IN | ⚠ chữ in — độ chính xác cao | | ⚠ Ghi chú VIẾT TAY | ⚠ Read hỗ trợ chữ viết tay |

⚠ Ảnh biên nhận (quét hoặc chụp)
        ↓ ⚠ Read API
⚠ Trích mọi dòng chữ
   ⚠ kèm vị trí và độ tin cậy
   ⚠ phân biệt in và viết tay
        ↓
⚠ Lưu vào CSDL theo dõi

⚠ Read API là mô hình OCR mạnh nhất — ⚠ xử lý được ảnh chất lượng thấp, nghiêng, nhiều trang.

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

  • C (Image Analysis phát hiện và phân loại đối tượng) — ⚠ nhận diện VẬT THỂ, không trích chữ: ⚠ Image Analysis có OCR nhưng ⚠ Read API mạnh hơn cho tài liệu.

  • D (Custom Vision nhận diện các định dạng biên nhận khác nhau) — ⚠ chỉ PHÂN LOẠI ảnh: ⚠ không trích nội dung.

  • B (Speech-to-text) — ⚠ xử lý âm thanh, hoàn toàn lạc đề.

Ghi nhớ

⚠ Các mô hình của Document Intelligence — chọn cái nào: | Mô hình | Đầu ra | |---|---| | ⚠ Read | ⚠ CHỮ (in và viết tay) + vị trí — đề này | | ⚠ Layout | ⚠ chữ + BẢNG + cấu trúc đoạn + ô chọn | | ⚠ Prebuilt (invoice, receipt…) | ⚠ cặp TRƯỜNG-GIÁ TRỊ có nghĩa | | ⚠ Custom | ⚠ trường riêng của biểu mẫu công ty |

Từ khoá nhận diện:

"trích CHỮ, cả viết tay" → ⚠ Read API "trích TRƯỜNG có nghĩa từ hoá đơn" → ⚠ prebuilt-invoice "biểu mẫu riêng" → ⚠ custom model "nhận diện vật thể trong ảnh" → ⚠ Image Analysis

⚠ Chữ viết tay — điều cần biết Điều
⚠ Read API CÓ hỗ trợ chữ viết tay
⚠ Độ chính xác THẤP HƠN chữ in nhiều
⚠ Trả về confidence cho từng dòng
⚠ Hỗ trợ chữ viết tay tốt nhất với tiếng Anh
⚠ Thiết kế quy trình ⚠ confidence thấp → người kiểm tra
⚠ Chữ ký — lưu ý riêng Lưu ý
⚠ Read API nhận ra VÙNG có chữ viết tay
⚠ KHÔNG xác thực chữ ký có đúng người không
⚠ Custom model có trường signature để đánh dấu có/không ký
⚠ Xác thực chữ ký thật ⚠ là bài toán khác, cần giải pháp chuyên biệt
⚠ Xử lý ảnh chụp bằng điện thoại Thách thức
⚠ Nghiêng, méo, bóng, loá
⚠ Read API xử lý khá tốt nhưng không hoàn hảo
⚠ Nên hướng dẫn tài xế cách chụp ⚠ khung hình, ánh sáng
⚠ Cải thiện rẻ nhất ⚠ hướng dẫn người chụp, không phải nâng cấp mô hình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ chính xác với chữ viết tay là bao nhiêu | ⚠ đo trên biên nhận thật | | Ngưỡng confidence đặt bao nhiêu | | | Có hướng dẫn cách chụp cho tài xế không | |

Và cách cải thiện độ chính xác OCR rẻ và hiệu quả nhất, thường bị bỏ qua: hướng dẫn người chụp ảnh cho đúng. Một khung ngắm trong ứng dụng cải thiện kết quả nhiều hơn bất kỳ lần nâng cấp mô hình nào.

Câu 64
A financial services company is developing an AI system to automatically process loan applications. During testing, the data science team discovers that the model approves loans for applicants from urban areas at a significantly higher rate than equally qualified applicants from rural areas. What should be the FIRST step to address this fairness concern?
  1. A Manually override the AI system's decisions to approve an equal number of urban and rural applicants regardless of their qualifications.
  2. B Examine the training data to identify whether rural applicants are underrepresented or if there are biases in the historical lending decisions used to train the model.
  3. C Deploy the model immediately since it meets the overall accuracy requirements, then monitor for complaints from rural applicants.
  4. D Remove all location-related features from the model to ensure geographic data cannot influence the decision.
Xem giải thích

Đáp án

B — Xem xét dữ liệu huấn luyện để xác định liệu ứng viên nông thôn có bị thiếu đại diện, hoặc có thiên lệch trong các quyết định cho vay LỊCH SỬ hay không.

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

⚠ Câu này GẦN TRÙNG với #17935 ở lô trước.

Câu Diễn đạt
⚠ #17935 (lô 161) ⚠ 75% đô thị và 45% nông thôn, hỏi nên làm gì
⚠ #17978 (câu này) ⚠ tỉ lệ đô thị cao hơn hẳn, hỏi bước ĐẦU TIÊN
⚠ Cùng khoá về bản chất ⚠ điều tra dữ liệu huấn luyện để tìm thiên lệch

Vì sao đúng

⚠ Bước đầu tiên phải là CHẨN ĐOÁN, không phải chữa vội:

⚠ Phát hiện chênh lệch
        ↓ ⚠ hỏi VÌ SAO
⚠ Nông thôn có bị thiếu dữ liệu không?
⚠ Dữ liệu lịch sử có phản ánh
   phân biệt đối xử trong quá khứ không?
        ↓
⚠ Biết nguyên nhân → ⚠ mới chữa đúng

⚠ Dữ liệu lịch sử về cho vay thường CHỨA SẴN thiên lệch của con người — ⚠ mô hình học và khuếch đại nó.

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

  • D (loại bỏ mọi đặc trưng liên quan tới vị trí) — ⚠ nghe hợp lý nhưng KHÔNG hiệu quả: ⚠ mô hình vẫn học được vị trí qua proxy — mã bưu chính, tên ngân hàng, loại nghề nghiệp.

  • A (can thiệp tay để duyệt số lượng bằng nhau bất kể năng lực) — ⚠ tạo ra sự bất công MỚI: ⚠ và ⚠ vi phạm quy định tín dụng.

  • C (triển khai ngay vì đạt yêu cầu độ chính xác tổng thể, rồi theo dõi khiếu nại) — ⚠ biết mà vẫn dùng: ⚠ về pháp lý còn nặng hơn không biết.

Ghi nhớ

⚠ Nguồn thiên lệch — bảng phải thuộc: | Nguồn | Nội dung | |---|---| | ⚠ Thiên lệch lịch sử | ⚠ dữ liệu phản ánh phân biệt đối xử trong quá khứ | | ⚠ Thiếu đại diện | ⚠ nhóm thiểu số có quá ít dữ liệu | | ⚠ Đặc trưng proxy | ⚠ mã bưu chính thay cho vùng miền | | ⚠ Thiên lệch trong nhãn | ⚠ người gán nhãn có định kiến | | ⚠ Khó nhất | ⚠ thiên lệch lịch sử — dữ liệu "đúng" nhưng thế giới đã bất công |

Từ khoá nhận diện:

"chênh lệch giữa các nhóm" → ⚠ Fairness "bỏ cột nhạy cảm là xong" → ⚠ KHÔNG đủ vì proxy "cộng bù điểm cho một nhóm" → ⚠ thường là phương án sai "triển khai rồi theo dõi khiếu nại" → ⚠ luôn sai

⚠ Vì sao bỏ cột vị trí không giải quyết được Lý do
⚠ Mã bưu chính vẫn còn
⚠ Tên chi nhánh ngân hàng gợi ý vùng
⚠ Loại nghề nghiệp tương quan với vùng
⚠ Thậm chí khoảng cách tới chi nhánh
⚠ Cách duy nhất biết ⚠ ĐO kết quả theo nhóm, dù nhóm đó không phải đặc trưng đầu vào
⚠ Quy trình xử lý thiên lệch Quy trình
⚠ 1. ĐO — phân tách chỉ số theo nhóm
⚠ 2. CHẨN ĐOÁN — tìm nguồn thiên lệch ⚠ đề này
⚠ 3. CHỮA — cân bằng dữ liệu, bỏ proxy, ràng buộc công bằng
⚠ 4. ĐO LẠI
⚠ 5. GIÁM SÁT liên tục
⚠ Công cụ hỗ trợ Công cụ
⚠ Fairlearn ⚠ thư viện đánh giá và giảm thiểu thiên lệch
⚠ Responsible AI dashboard ⚠ trong Azure ML
⚠ Phân tách chỉ số theo nhóm ⚠ việc cơ bản nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhóm nông thôn có bao nhiêu mẫu trong dữ liệu | | | Tỉ lệ chấp thuận LỊCH SỬ giữa hai nhóm thế nào | ⚠ nếu đã lệch thì mô hình chỉ học lại | | Có đặc trưng nào là proxy cho vùng miền không | |

Và câu hỏi khó nhất trong công bằng thuật toán, mà kỹ thuật một mình không trả lời được: nếu dữ liệu lịch sử phản ánh một thế giới bất công, mô hình học đúng từ dữ liệu đó là "đúng" hay "sai"?. Câu trả lời thuộc về chính sách, không thuộc về mã nguồn.

Câu 65
Your company is developing a healthcare chatbot using Azure AI services that will interact with patients to collect their medical symptoms and history. The chatbot will store conversation logs for quality improvement purposes. What should be your PRIMARY privacy consideration when implementing this solution?
  1. A Deploy the chatbot on a high-availability infrastructure to ensure 99.9% uptime for patient access.
  2. B Ensure the chatbot uses the latest natural language processing models to provide accurate responses to patient queries.
  3. C Configure the chatbot to respond in multiple languages to serve a diverse patient population.
  4. D Implement data encryption both in transit and at rest, and ensure compliance with healthcare regulations such as HIPAA when handling patient health information.
Xem giải thích

Đáp án

D — Triển khai mã hoá dữ liệu cả khi truyền lẫn khi lưu, và bảo đảm tuân thủ các quy định y tế như HIPAA khi xử lý dữ liệu bệnh nhân.

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

⚠ Câu này GẦN TRÙNG với #17927 ở lô trước.

Câu Bối cảnh
⚠ #17927 (lô 161) ⚠ chatbot đặt lịch, xử lý tên, liên hệ, triệu chứng
⚠ #17979 (câu này) ⚠ chatbot thu thập triệu chứng và tiền sử, lưu log hội thoại
⚠ Cùng nguyên tắc ⚠ Privacy & Security

Vì sao đúng

⚠ Dữ liệu trong đề thuộc loại nhạy cảm nhất: | Dữ liệu | Phân loại | |---|---| | ⚠ Triệu chứng | ⚠ PHI — thông tin sức khoẻ được bảo vệ | | ⚠ Tiền sử bệnh | ⚠ PHI | | ⚠ Log hội thoại | ⚠ chứa cả hai, thường bị quên bảo vệ |

⚠ Ba lớp bắt buộc
   ⚠ Mã hoá khi TRUYỀN (TLS)
   ⚠ Mã hoá khi LƯU
   ⚠ Tuân thủ HIPAA (ký BAA với nhà cung cấp)

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

  • A (hạ tầng sẵn sàng cao 99,9%) — ⚠ thuộc Reliability, không phải privacy.

  • B (dùng mô hình NLP mới nhất cho câu trả lời chính xác) — ⚠ thuộc chất lượng dịch vụ.

  • C (hỗ trợ nhiều ngôn ngữ) — ⚠ thuộc Inclusiveness.

Ghi nhớ

⚠ Bảo vệ dữ liệu y tế trong ứng dụng AI — checklist: | Việc | Nội dung | |---|---| | ⚠ Mã hoá at rest và in transit | | | ⚠ Ký BAA với nhà cung cấp đám mây | ⚠ bắt buộc với HIPAA | | ⚠ RBAC — ai đọc được log | | | ⚠ Thời hạn lưu và xoá tự động | | | ⚠ Che PII trong log nếu được | | | ⚠ Tắt logging phía nhà cung cấp mô hình | ⚠ Azure OpenAI có tuỳ chọn này | | ⚠ Audit log ai truy cập dữ liệu | |

Từ khoá nhận diện:

"bảo vệ dữ liệu bệnh nhân" → ⚠ Privacy & Security "độ sẵn sàng, không gián đoạn" → ⚠ Reliability "nhiều ngôn ngữ, mọi người dùng được" → ⚠ Inclusiveness "bịa thông tin" → ⚠ Reliability & Safety

⚠ Log hội thoại — rủi ro thường bị bỏ qua Rủi ro
⚠ Chứa PHI mà không ai phân loại
⚠ Đội phát triển thường có quyền đọc để gỡ lỗi
⚠ Lưu vô thời hạn "để cải thiện mô hình"
⚠ Có thể bị gửi cho nhà cung cấp mô hình
⚠ Xử lý ⚠ che PII trước khi lưu, giới hạn quyền, đặt thời hạn xoá
⚠ Nguyên tắc giới hạn dữ liệu Nguyên tắc
⚠ Chỉ thu thập điều CẦN THIẾT
⚠ Chỉ giữ trong thời gian cần
⚠ Chỉ dùng cho mục đích đã thông báo
⚠ "Giữ hết để sau này dùng" ⚠ vi phạm cả GDPR lẫn HIPAA
⚠ Kiểm tra nhà cung cấp mô hình Kiểm tra
⚠ Dữ liệu gửi lên có bị LƯU không
⚠ Có dùng để huấn luyện mô hình của họ không
⚠ Có ký BAA không
⚠ Dữ liệu xử lý ở vùng địa lý nào
⚠ Azure OpenAI ⚠ cam kết không dùng dữ liệu khách để huấn luyện, có tuỳ chọn tắt lưu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log hội thoại lưu ở đâu, ai đọc được | | | Có che PII trước khi lưu không | | | Nhà cung cấp mô hình có lưu dữ liệu không | |

Và nơi dữ liệu y tế hay bị rò rỉ nhất trong các dự án AI, không phải cơ sở dữ liệu chính: log hội thoại và log gỡ lỗi. Chúng thường được lưu vô thời hạn, ít ai phân quyền, và gần như không bao giờ được mã hoá riêng.

Câu 66
A healthcare company wants to develop an application that allows doctors to dictate medical notes verbally, which are then converted into text and stored in patient records. The application should also be able to read aloud appointment reminders to patients over the phone. Which Azure AI services should the company use to implement these features?
  1. A Speech-to-text for converting dictation to text, and text-to-speech for reading appointment reminders aloud
  2. B Speech-to-text for converting dictation to text, and Computer Vision for reading appointment reminders
  3. C Text-to-speech for converting dictation to text, and speech-to-text for reading appointment reminders aloud
  4. D Language Understanding (LUIS) for converting dictation to text, and Translator for reading appointment reminders aloud
Xem giải thích

Đáp án

A — Speech-to-text để chuyển lời đọc thành văn bản, và text-to-speech để đọc to lời nhắc lịch hẹn.

Vì sao đúng

⚠ Đề cần HAI chiều chuyển đổi NGƯỢC NHAU: | Việc | Chiều | Dịch vụ | |---|---|---| | ⚠ Bác sĩ đọc, hệ thống ghi thành chữ | ⚠ giọng nói → chữ | ⚠ Speech-to-text | | ⚠ Đọc lời nhắc cho bệnh nhân qua điện thoại | ⚠ chữ → giọng nói | ⚠ Text-to-speech |

⚠ Bác sĩ NÓI
        ↓ ⚠ Speech-to-text
⚠ Ghi chú bệnh án dạng CHỮ

⚠ Lời nhắc lịch hẹn dạng CHỮ
        ↓ ⚠ Text-to-speech
⚠ Bệnh nhân NGHE qua điện thoại

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

  • C (text-to-speech để chuyển lời đọc thành chữ, speech-to-text để đọc to) — ⚠ ĐẢO NGƯỢC hai dịch vụ: ⚠ bẫy kinh điển.

  • B (speech-to-text đúng, nhưng Computer Vision để đọc lời nhắc) — ⚠ Computer Vision xử lý ẢNH: ⚠ không đọc thành tiếng được.

  • D (LUIS để chuyển lời đọc thành chữ, Translator để đọc to) — ⚠ sai cả hai: ⚠ LUIS hiểu ý định từ VĂN BẢN; ⚠ Translator dịch, không đọc.

Ghi nhớ

⚠ Bốn chiều của Azure AI Speech — bảng phải thuộc: | 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 | ⚠ 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ả, phiên âm" → ⚠ Speech-to-Text "đọc to, trợ lý ảo nói, IVR" → ⚠ Text-to-Speech "phiên dịch" → ⚠ Speech Translation "xác thực bằng giọng" → ⚠ Speaker Recognition

⚠ Text-to-speech qua điện thoại — lưu ý Lưu ý
⚠ Chọn ĐỊNH DẠNG âm thanh phù hợp điện thoại ⚠ 8kHz mono cho hệ thống thoại
⚠ Dùng giọng NEURAL, không dùng giọng chuẩn cũ
⚠ SSML để đọc chậm rõ số điện thoại, ngày giờ
⚠ Kiểm tra cách đọc tên riêng và địa chỉ
⚠ Với người cao tuổi ⚠ giảm tốc độ đọc, tăng khoảng nghỉ
⚠ SSML — công cụ quan trọng nhất cho TTS Điều khiển
⚠ Tốc độ đọc (rate)
⚠ Cao độ (pitch)
⚠ Ngắt nghỉ (break)
⚠ Cách đọc số, ngày, tiền (say-as) ⚠ rất quan trọng cho lịch hẹn
⚠ Ví dụ ⚠ "15/3" đọc là "mười lăm tháng ba", không phải "mười lăm chia ba"
⚠ Với ứng dụng y tế — cần thêm Cần thêm
⚠ Custom Speech cho thuật ngữ y khoa ⚠ phía nhận diện
⚠ Kiểm tra cách đọc tên thuốc ⚠ phía tổng hợp
⚠ Ghi âm và log phải được bảo vệ ⚠ là dữ liệu y tế
⚠ Xác nhận danh tính trước khi đọc thông tin nhạy cảm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngày giờ có được đọc đúng không | ⚠ thử với SSML say-as | | Định dạng âm thanh có phù hợp hệ thống thoại không | | | Có xác nhận danh tính trước khi đọc thông tin bệnh nhân không | |

Và chi tiết nhỏ quyết định trải nghiệm của một hệ thống nhắc lịch tự động: cách nó đọc ngày giờ và số điện thoại. Không dùng SSML thì "15/3 lúc 9h30" có thể biến thành một chuỗi âm thanh mà không ai hiểu.

Câu 67
A retail company has collected thousands of customer product reviews and wants to quickly understand what topics customers are discussing most frequently across all reviews. The company needs to identify the main subjects and concepts mentioned in the feedback without reading every review manually. Which Azure AI Language feature would be most appropriate for this requirement?
  1. A Key phrase extraction
  2. B Language detection
  3. C Named entity recognition
  4. D Sentiment analysis
Xem giải thích

Đáp án

A — Key phrase extraction (trích xuất cụm từ khoá).

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

⚠ Câu này GẦN TRÙNG với #17944 ở lô trước.

Câu Diễn đạt
⚠ #17944 (lô 161) ⚠ "xác định chủ đề chính khách hàng đang bàn"
⚠ #17981 (câu này) ⚠ "hiểu khách bàn về chủ đề gì nhiều nhất, không đọc thủ công"
⚠ Cùng khoá ⚠ key phrase extraction

Vì sao đúng

⚠ Đề cần biết khách NÓI VỀ CÁI GÌ, không phải họ cảm thấy thế nào:

⚠ Hàng nghìn đánh giá
        ↓ ⚠ Key phrase extraction
⚠ Trích cụm từ quan trọng từng đánh giá
        ↓ ⚠ tổng hợp
⚠ "giao hàng" xuất hiện 1.200 lần
⚠ "chất lượng vải" 890 lần
⚠ "đóng gói" 650 lần
        ↓
⚠ Biết chủ đề nào được bàn nhiều nhất

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

  • D (sentiment analysis) — ⚠ cho biết THÁI ĐỘ: ⚠ không cho biết chủ đề.

  • C (named entity recognition) — ⚠ trích TÊN RIÊNG có phân loại: ⚠ hẹp hơn "chủ đề chung"; ⚠ bỏ sót cụm như "thời gian giao hàng".

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

Ghi nhớ

⚠ Bốn tính năng — phân biệt bằng câu hỏi chúng trả lời: | Tính năng | Trả lời | |---|---| | ⚠ Key phrase extraction | ⚠ NÓI VỀ GÌ | | ⚠ Sentiment analysis | ⚠ CẢM THẤY THẾ NÀO | | ⚠ NER | ⚠ NHẮC TỚI AI, CÁI GÌ cụ thể | | ⚠ Language detection | ⚠ VIẾT BẰNG TIẾNG GÌ |

Từ khoá nhận diện:

"chủ đề chính, bàn về gì" → ⚠ key phrase extraction "hài lòng hay không" → ⚠ sentiment "tên sản phẩm, người, nơi" → ⚠ NER "khen cái gì, chê cái gì" → ⚠ opinion mining

⚠ HẠN CHẾ lớn nhất — nhắc lại Hạn chế
⚠ Không gom nhóm từ ĐỒNG NGHĨA
⚠ "giao hàng", "vận chuyển", "ship" thành ba mục riêng
⚠ Báo cáo thô sẽ rất rời rạc
⚠ Cần bước hậu xử lý ⚠ gom nhóm bằng embedding hoặc từ điển đồng nghĩa
⚠ Quy trình phân tích chủ đề hoàn chỉnh Quy trình
⚠ 1. Key phrase extraction cho từng đánh giá
⚠ 2. Gom nhóm cụm đồng nghĩa ⚠ bằng embedding
⚠ 3. Đếm tần suất theo nhóm chủ đề
⚠ 4. Ghép với sentiment của từng đánh giá
⚠ 5. Báo cáo: chủ đề nào bàn nhiều, thái độ ra sao
⚠ Lựa chọn hiện đại hơn Lựa chọn
⚠ Dùng mô hình ngôn ngữ để PHÂN LOẠI chủ đề ⚠ định nghĩa sẵn danh sách chủ đề
⚠ Topic modeling bằng embedding và clustering
⚠ Custom text classification
⚠ Ưu điểm ⚠ chủ đề gọn gàng, không bị phân mảnh như key phrase thô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bước gom nhóm đồng nghĩa không | | | Danh sách chủ đề có gọn để đọc không | | | Có ghép với sentiment không | |

Và điều biến một danh sách cụm từ thành một báo cáo có ích: gom chúng thành một số ít chủ đề mà người quản lý thật sự quan tâm. Một bảng ba trăm cụm từ khoá không giúp ai ra quyết định.

Câu 68
A marketing team wants to use AI to create unique product descriptions for their e-commerce website. They need the AI system to generate original text content based on brief product specifications they provide. Which type of AI workload best describes this scenario?
  1. A Generative AI
  2. B Computer Vision
  3. C Anomaly Detection
  4. D Classification
Xem giải thích

Đáp án

A — Generative AI.

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

⚠ Đây là câu THỨ TƯ về cùng kịch bản "tạo mô tả sản phẩm" trong hai lô.

Câu Hỏi gì
⚠ #17928 (lô 161) ⚠ loại workload nào
⚠ #17937 (lô 161) ⚠ đặc điểm nào của mô hình sinh ngữ
⚠ #17965 (lô 162) ⚠ đặc điểm nào — trùng #17937
⚠ #17982 (câu này) ⚠ loại workload nào — trùng #17928
⚠ Cùng khoá ⚠ Generative AI

⚠ Bộ đề rõ ràng dùng lại một kịch bản gốc với bốn biến thể diễn đạt.

Vì sao đúng

⚠ Dấu hiệu nhận biết Generative AI: | Dấu hiệu | Nội dung | |---|---| | ⚠ "tạo ra" (create/generate) | ⚠ sinh nội dung | | ⚠ "độc đáo, nguyên bản" (unique/original) | ⚠ chưa từng tồn tại | | ⚠ "dựa trên thông số cung cấp" | ⚠ prompt là đầu vào |

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

  • D (classification) — ⚠ gán nhãn cho thứ có sẵn.

  • B (computer vision) — ⚠ xử lý ảnh.

  • C (anomaly detection) — ⚠ phát hiện bất thường trong số liệu.

Ghi nhớ

⚠ Nhận diện loại workload — bảng tra nhanh: | Đề nói | Loại | |---|---| | ⚠ Tạo, viết, sinh, soạn nội dung mới | ⚠ Generative AI | | ⚠ Phân vào nhóm định sẵn | ⚠ Classification | | ⚠ Dự đoán con số | ⚠ Regression | | ⚠ Tự tìm nhóm | ⚠ Clustering | | ⚠ Tìm điểm khác thường | ⚠ Anomaly detection | | ⚠ Nhận diện trong ảnh | ⚠ Computer vision | | ⚠ Hiểu, phân tích văn bản | ⚠ NLP |

Từ khoá nhận diện:

"unique, original, generate, create" → ⚠ Generative AI "categorize, classify, assign to" → ⚠ Classification "predict amount, value, price" → ⚠ Regression "group, segment" → ⚠ Clustering

⚠ Generative AI — các dạng nội dung sinh được Dạng
⚠ Văn bản ⚠ GPT
⚠ Ảnh ⚠ DALL·E
⚠ Mã nguồn ⚠ GitHub Copilot
⚠ Âm thanh và giọng nói
⚠ Video
⚠ Đề thi Fundamentals ⚠ chủ yếu hỏi văn bản và ảnh
⚠ Sinh mô tả sản phẩm ở quy mô lớn — thực tế Thực tế
⚠ Prompt có cấu trúc với thông số sản phẩm
⚠ Few-shot với mô tả mẫu đã duyệt
⚠ Yêu cầu CHỈ dùng thông số được cung cấp
⚠ Sinh hàng loạt rồi rà soát mẫu
⚠ Theo dõi chi phí theo token
⚠ Với hàng nghìn sản phẩm ⚠ chi phí token cộng lại đáng kể — tính trước
⚠ Rủi ro cần kiểm soát Rủi ro
⚠ Bịa tính năng không có
⚠ Mô tả trùng lặp giữa sản phẩm tương tự
⚠ Vi phạm quy định quảng cáo
⚠ Trách nhiệm ⚠ vẫn thuộc về doanh nghiệp, không phải mô hình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có kiểm tra mẫu ngẫu nhiên trước khi đăng không | | | Chi phí cho toàn bộ catalog là bao nhiêu | | | Mô tả có trùng lặp giữa các sản phẩm không | |

Và tính toán nên làm trước khi sinh nội dung ở quy mô lớn: nhân chi phí một lần gọi với số lượng sản phẩm. Một khoản tiền nhỏ cho mỗi mô tả trở thành con số đáng kể khi nhân với năm mươi nghìn mặt hàng.

Câu 69
A healthcare organization is deploying an AI system to assist doctors in diagnosing skin conditions from patient photographs. During testing, the system performs well on images taken in clinical settings with professional lighting, but shows significantly reduced accuracy on photos taken by patients at home using mobile phones. What reliability consideration should the organization address before deploying this solution?
  1. A Add a disclaimer stating that the AI system is for entertainment purposes only and should not be used for medical decisions.
  2. B Deploy the system immediately but only allow it to be used by doctors with more than 10 years of experience.
  3. C Implement a feedback mechanism that allows doctors to report incorrect predictions and continuously retrain the model with diverse image data from various lighting conditions and camera qualities.
  4. D Restrict the system to only accept images from professional medical cameras and reject all mobile phone photographs.
Xem giải thích

Đáp án

C — Triển khai cơ chế phản hồi cho phép bác sĩ báo cáo dự đoán sai, và liên tục huấn luyện lại mô hình với dữ liệu ảnh đa dạng hơn.

Vì sao đúng

⚠ Vấn đề: mô hình tốt với ảnh CHUYÊN NGHIỆP, kém với ảnh BỆNH NHÂN TỰ CHỤP.

⚠ Dữ liệu huấn luyện: ảnh phòng khám
   ⚠ ánh sáng chuẩn, khoảng cách chuẩn
        ↓
⚠ Thực tế: ảnh điện thoại bệnh nhân
   ⚠ ánh sáng kém, góc chụp lệch, nhoè
        ↓
⚠ Mô hình chưa từng thấy loại ảnh này
        ↓ ⚠ cách chữa
⚠ Bổ sung dữ liệu ĐA DẠNG + vòng phản hồi

⚠ Cơ chế phản hồi tạo VÒNG LẶP CẢI TIẾN LIÊN TỤC — ⚠ mỗi lần bác sĩ báo sai là một mẫu học mới.

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

  • D (chỉ nhận ảnh từ máy ảnh y tế chuyên nghiệp, từ chối ảnh điện thoại) — ⚠ loại bỏ chính ca dùng có giá trị nhất: ⚠ sàng lọc từ xa qua ảnh bệnh nhân tự chụp.

  • A (thêm lưu ý hệ thống chỉ để giải trí, không dùng cho quyết định y tế) — ⚠ né trách nhiệm: ⚠ và làm hệ thống vô dụng.

  • B (chỉ cho bác sĩ trên 10 năm kinh nghiệm dùng) — ⚠ không giải quyết vấn đề kỹ thuật: ⚠ mô hình vẫn sai với ảnh chất lượng thấp.

Ghi nhớ

⚠ Vòng lặp cải tiến liên tục cho mô hình AI: | Bước | Nội dung | |---|---| | ⚠ 1. Triển khai với giám sát | | | ⚠ 2. Thu thập PHẢN HỒI từ người dùng | ⚠ nhất là khi mô hình SAI | | ⚠ 3. Phân tích ca sai | ⚠ tìm mẫu chung | | ⚠ 4. Bổ sung dữ liệu cho ca đó | | | ⚠ 5. Huấn luyện lại và đánh giá | | | ⚠ 6. Triển khai dần (canary) | |

Từ khoá nhận diện:

"kém với một loại dữ liệu" → ⚠ bổ sung dữ liệu đa dạng "từ chối loại dữ liệu đó" → ⚠ thường là phương án SAI "thêm lưu ý miễn trừ" → ⚠ né tránh, không giải quyết

⚠ Data drift so với vấn đề trong đề Phân biệt
⚠ Data drift ⚠ dữ liệu THAY ĐỔI theo thời gian
⚠ Đề này ⚠ dữ liệu huấn luyện KHÔNG ĐẠI DIỆN ngay từ đầu
⚠ Cả hai đều cần ⚠ giám sát và huấn luyện lại
⚠ Khác nhau ở ⚠ một cái là vấn đề thời gian, một cái là vấn đề thiết kế ban đầu
⚠ Thu thập phản hồi thế nào cho hiệu quả Cách
⚠ Nút báo sai ngay trong giao diện ⚠ càng ít bước càng tốt
⚠ Ghi lại ca bác sĩ KHÔNG đồng ý
⚠ Cho phép ghi chú lý do
⚠ Có người thật sự XEM phản hồi
⚠ Sai lầm ⚠ thu thập phản hồi rồi không ai đọc
⚠ Kỹ thuật bổ trợ cho ảnh chất lượng thấp Kỹ thuật
⚠ Data augmentation ⚠ tạo biến thể: mờ, đổi sáng, xoay
⚠ Kiểm tra chất lượng ảnh trước khi phân tích ⚠ cảnh báo nếu quá mờ
⚠ Hướng dẫn bệnh nhân cách chụp ⚠ khung ngắm trong ứng dụng
⚠ Rẻ nhất và hiệu quả ⚠ hướng dẫn cách chụp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cơ chế báo sai không, và ai đọc | | | Dữ liệu huấn luyện có gồm ảnh điện thoại không | | | Có kiểm tra chất lượng ảnh đầu vào không | |

Và điều phân biệt một mô hình AI được triển khai một lần với một hệ thống AI sống: vòng phản hồi. Không có nó, mô hình chỉ ngày càng lệch xa thực tế mà không ai biết cho tới khi quá muộn.

Câu 70
A real estate company wants to develop a machine learning model to help price properties. They have a dataset containing historical property information including square footage, number of bedrooms, location, age of property, and the actual sale prices. They want to predict the expected sale price for new property listings based on these features. Which type of machine learning model should they use?
  1. A Clustering
  2. B Anomaly detection
  3. C Regression
  4. D Classification
Xem giải thích

Đáp án

C — Regression (hồi quy).

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

⚠ Câu này GẦN TRÙNG với #17939 ở lô trước.

Câu Bối cảnh
⚠ #17939 (lô 161) ⚠ định giá bất động sản, đầu ra là giá trị tiền
⚠ #17984 (câu này) ⚠ dự đoán giá bán bất động sản
⚠ Cùng khoá ⚠ regression

Vì sao đúng

⚠ Đầu ra là một CON SỐ liên tục — giá bán dự kiến.

⚠ Đầu vào: diện tích, số phòng ngủ,
   vị trí, tuổi nhà
        ↓ ⚠ Hồi quy
⚠ Đầu ra: 3.250.000.000 đồng

⚠ Đề nói rõ có actual sale prices trong dữ liệu — ⚠ đó là NHÃN dạng số, ⚠ xác nhận đây là bài toán hồi quy có giám sát.

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

  • D (classification) — ⚠ cho ra NHÃN: ⚠ ví dụ "đắt / trung bình / rẻ"; ⚠ mất thông tin so với con số cụ thể.

  • A (clustering) — ⚠ KHÔNG có nhãn: ⚠ đề đã có giá bán thực tế.

  • B (anomaly detection) — ⚠ tìm bất động sản có giá bất thường: ⚠ là bài toán khác, hữu ích để phát hiện gian lận.

Ghi nhớ

⚠ Nhận biết loại bài toán từ NHÃN — bảng phải thuộc: | Nhãn | Loại | |---|---| | ⚠ Số liên tục | ⚠ Regression | | ⚠ Hai giá trị | ⚠ Binary classification | | ⚠ Nhiều giá trị rời rạc | ⚠ Multiclass classification | | ⚠ Không có nhãn | ⚠ Clustering | | ⚠ Mẹo | ⚠ nhìn cột nhãn là biết ngay |

Từ khoá nhận diện:

"giá, doanh thu, số lượng, nhiệt độ" → ⚠ regression "loại nào, có hay không" → ⚠ classification "nhóm khách hàng" → ⚠ clustering "giá bất thường" → ⚠ anomaly detection

⚠ Chỉ số cho mô hình định giá Chỉ số
⚠ MAE ⚠ sai lệch trung bình bằng tiền — dễ hiểu nhất với người kinh doanh
⚠ RMSE ⚠ phạt nặng sai số lớn
⚠ MAPE ⚠ sai lệch phần trăm — so sánh được giữa các mức giá
⚠ R² ⚠ giải thích được bao nhiêu phần biến thiên
⚠ Trình bày với môi giới ⚠ MAPE dễ hiểu nhất: "sai trung bình 7%"
⚠ Đặc thù của bài toán định giá bất động sản Đặc thù
⚠ VỊ TRÍ là yếu tố mạnh nhất ⚠ và khó mã hoá nhất
⚠ Giá thay đổi theo THỜI GIAN ⚠ phải đưa yếu tố thời gian vào
⚠ Giá trị ngoại lai nhiều ⚠ biệt thự, đất đặc biệt
⚠ Dữ liệu thường thiếu và không đồng nhất
⚠ Mô hình huấn luyện trên dữ liệu cũ ⚠ sẽ lệch khi thị trường biến động
⚠ Mã hoá vị trí thế nào Cách
⚠ Toạ độ kinh vĩ độ
⚠ Khoảng cách tới trung tâm, trường học, bệnh viện
⚠ Mã hành chính (one-hot hoặc target encoding)
⚠ Giá trung bình khu vực trong quá khứ ⚠ cẩn thận rò rỉ dữ liệu
⚠ Đây thường là ⚠ phần quyết định chất lượng mô hình định giá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình có tính tới thời điểm bán không | | | Sai lệch trung bình bằng bao nhiêu phần trăm | | | Có giải thích được dự đoán cho khách không | |

Và yêu cầu mà mọi mô hình định giá bất động sản đều gặp khi triển khai thật: môi giới và khách hàng muốn biết vì sao ra con số đó. Một mô hình chính xác hơn nhưng không giải thích được thường không được ai dùng.