Ngân hàng đề — Google Cloud Generative AI Leader

Đáp án

B — Vertex AI Model Registry.

Vì sao đúng

Đội cần lưu hồ sơ rõ ràng về các phiên bản mô hình, theo dõi nguồn gốc (lineage), và dễ triển khai hoặc quay lui về một phiên bản cụ thể. Đó chính là chức năng của Model Registry.

⚠ Model Registry giữ những gì:

⚠ Danh mục các mô hình
⚠ Nhiều PHIÊN BẢN của mỗi mô hình
⚠ LINEAGE
    → ⚠ dữ liệu nào, tham số nào,
      pipeline nào tạo ra nó
⚠ Chỉ số đánh giá của từng phiên bản
⚠ Nhãn trạng thái
    → ⚠ đang thử nghiệm, đang chạy
⚠ Liên kết tới endpoint đang phục vụ
        ↓
    ⚠ Nhờ đó QUAY LUI được

⚠ Vì sao ba phương án kia sai:

"Vertex AI Pipelines"
    → ⚠ TỰ ĐỘNG HOÁ quy trình;
      ⚠ tạo ra mô hình nhưng không
      phải nơi quản phiên bản

"Feature Store"
    → ⚠ quản ĐẶC TRƯNG, không quản
      mô hình

"TensorBoard"
    → ⚠ trực quan hoá quá trình
      HUẤN LUYỆN — biểu đồ loss,
      không phải quản phiên bản

Nhất quán với #13911 (lô 146) — đề đó về Model Management, và Model Registry là công cụ chính của giai đoạn đó. Bổ sung nhau.

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

• C (Pipelines) — phương án gần nhất vì cũng thuộc bộ MLOps và ghi lại metadata mỗi lần chạy. Nhưng nó tự động hoá quy trình, còn nơi lưu và quản phiên bản mô hình là Registry.

• D (TensorBoard) và A (Feature Store) — phục vụ khâu khác.

Ghi nhớ

⚠ Công cụ MLOps của Vertex AI — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Model Registry | ⚠ quản PHIÊN BẢN và lineage mô hình | | ⚠ Pipelines | ⚠ tự động hoá quy trình, ghi metadata | | ⚠ Feature Store | ⚠ đặc trưng dùng chung, chống skew | | TensorBoard | ⚠ biểu đồ quá trình huấn luyện | | Experiments | ⚠ so sánh các lần thử nghiệm | | Model Monitoring | ⚠ phát hiện drift sau triển khai | | Model Garden | ⚠ danh mục mô hình CÓ SẴN |

Từ khoá nhận diện:

"quản phiên bản, lineage, quay lui" → ⚠ Model Registry "tự động hoá các bước" → Pipelines "đặc trưng dùng chung" → Feature Store "chọn mô hình có sẵn" → ⚠ Model Garden

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Phiên bản nào đang chạy ở sản xuất | ⚠ trả lời không được là chưa có Registry | | Quay lui mất bao lâu | ⚠ thử thật một lần | | Có tái lập được mô hình cũ không | ⚠ cần đủ lineage |

Và câu hỏi đơn giản nhất để biết một đội đã có quy trình MLOps hay chưa: hỏi phiên bản mô hình nào đang phục vụ ở sản xuất và nó được huấn luyện trên dữ liệu nào. Nếu câu trả lời cần vài giờ tra cứu, thì Model Registry là thứ nên có trước mọi cải tiến khác.

Đáp án

C — Prompt chaining (nối chuỗi prompt).

Vì sao đúng

Người dùng lấy kết quả của prompt thứ nhất (hồ sơ nhân vật) làm ngữ cảnh cho prompt thứ hai (viết truyện về nhân vật đó). Nối đầu ra vào đầu vào chính là prompt chaining.

⚠ Chuỗi trong đề:

PROMPT 1
    "Tạo ba hồ sơ nhân vật cho
     tiểu thuyết giả tưởng"
        ↓
    ⚠ ĐẦU RA: ba hồ sơ
        ↓
    ⚠ Người dùng XEM và CHỌN
        ↓
PROMPT 2
    "Dùng nhân vật Elara ở trên,
     viết truyện 500 chữ"
        ↓
    ⚠ đầu ra prompt 1 = ngữ cảnh
      cho prompt 2

⚠ Vì sao chia nhỏ lại tốt hơn:

Một prompt khổng lồ
    "Tạo nhân vật rồi viết truyện"
        ↓
    ⚠ mô hình làm cả hai qua loa
    ⚠ không kiểm soát được bước giữa
        ↓
⚠ CHIA THÀNH CHUỖI
        ↓
    ⚠ Mỗi bước một nhiệm vụ rõ
    ⚠ ⚠ NGƯỜI xem và chỉnh giữa chừng
    ⚠ Dễ gỡ lỗi khi kết quả tệ

⚠ Vì sao ba phương án kia sai:

"Role prompting"
    → ⚠ gán vai; không có ở đây

"Zero-shot"
    → ⚠ nói về việc có ví dụ hay không,
      không nói về chuỗi nhiều bước

"Metaprompting"
    → ⚠ dùng mô hình để SINH hoặc
      CẢI THIỆN prompt

⚠ Đối chiếu #13944 (lô 146, ReAct) — ở đó MÔ HÌNH tự quyết bước tiếp theo và gọi công cụ. Ở đây NGƯỜI DÙNG thiết kế và điều khiển từng bước. Không mâu thuẫn — đó chính là ranh giới giữa hai kỹ thuật.

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

• B (zero-shot) — phương án gần nhất và là bẫy tinh tế: từng prompt trong chuỗi đúng là zero-shot. Nhưng câu hỏi hỏi về cách nối hai prompt, và tên của cách đó là prompt chaining.

• A và D — không có dấu hiệu tương ứng.

Ghi nhớ

⚠ Kỹ thuật prompt — nhận diện bằng dấu hiệu: | Dấu hiệu | Kỹ thuật | |---|---| | ⚠ Đầu ra bước này là đầu vào bước sau | ⚠ prompt chaining | | ⚠ Mô hình TỰ quyết bước và gọi công cụ | ⚠ ReAct | | Ví dụ có bước suy luận | Chain-of-Thought | | Có ví dụ mẫu | few-shot | | "Bạn là..." | role prompting | | Dùng AI để viết prompt | ⚠ metaprompting |

Từ khoá nhận diện:

"nối đầu ra vào prompt sau" → ⚠ prompt chaining "agent tự quyết trình tự" → ⚠ ReAct / reasoning loop "suy luận từng bước" → CoT "gán vai chuyên gia" → role prompting

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào hay hỏng nhất | ⚠ kiểm từng bước riêng | | Chi phí toàn chuỗi bao nhiêu | ⚠ cộng tất cả các bước | | Có cần người xem giữa chừng không | ⚠ có thì thiết kế điểm dừng |

Và ưu điểm ít được nói tới của việc chia một nhiệm vụ thành chuỗi prompt: nó tạo ra những điểm dừng để con người can thiệp. Trong đề này, việc người dùng chọn nhân vật giữa hai bước chính là thứ khiến kết quả cuối cùng đúng ý — điều mà một prompt duy nhất không cho phép.

Đáp án

B — Workflow Automation Agent (agent tự động hoá quy trình).

Vì sao đúng

Agent này thực thi một chuỗi thao tác ĐỊNH TRƯỚC, có cấu trúc: thu thập thông tin từ biểu mẫu, gọi API tạo tài khoản, gán quyền mặc định, gửi email chào mừng — lặp lại cho mỗi nhân viên mới.

⚠ Vì sao là workflow automation:

"chuỗi thao tác ĐỊNH TRƯỚC"
    → ⚠ trình tự CỐ ĐỊNH, biết trước

"thực thi CÓ HỆ THỐNG"
    → ⚠ giống nhau mỗi lần

"cho MỖI nhân viên mới"
    → ⚠ lặp lại, có thể tự động hoá
        ↓
    ⚠ Đây là TỰ ĐỘNG HOÁ QUY TRÌNH,
      không phải hội thoại hay
      sáng tạo nội dung

⚠ Vì sao ba phương án kia sai:

"Information Retrieval Agent"
    → ⚠ TÌM và trả về thông tin;
      ở đây agent THỰC HIỆN hành động

"Generative Conversational Agent"
    → ⚠ trò chuyện với người dùng

"Creative Content Generation Agent"
    → ⚠ sinh nội dung sáng tạo

Đối chiếu #13952 (lô 146) — đề đó là agent du lịch tương tác, hỏi lại, tự quyết. Đề này là quy trình cố định. Không mâu thuẫn — hai loại agent khác nhau.

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

• A (Information Retrieval Agent) — phương án gần nhất vì agent này cũng thu thập thông tin từ biểu mẫu. Nhưng phần chính của nó là thực hiện hành động trên nhiều hệ thống, không phải tra cứu.

• C và D — mô tả loại agent khác.

Ghi nhớ

⚠ Phân loại agent theo NHIỆM VỤ — bảng nên thuộc: | Loại | Việc chính | |---|---| | ⚠ Workflow automation | ⚠ thực thi chuỗi bước ĐỊNH TRƯỚC | | Information retrieval | ⚠ tìm và trả về thông tin | | Conversational | ⚠ trò chuyện, hỏi đáp | | Creative generation | ⚠ sinh nội dung | | Ghi nhớ | ⚠ một agent thật thường KẾT HỢP nhiều vai |

Từ khoá nhận diện:

"chuỗi bước định trước, lặp lại" → ⚠ workflow automation "tìm thông tin trong tài liệu" → retrieval "hỏi lại, tự quyết trình tự" → ⚠ agent có reasoning loop "viết nội dung mới" → creative generation

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Quy trình có thật sự cần AI không | ⚠ cố định hoàn toàn → script rẻ hơn | | Hỏng giữa chừng thì sao | ⚠ phải có phương án | | Agent có quyền gì trên hệ thống tài khoản | ⚠ quyền rất mạnh, phải siết |

Và câu hỏi đáng đặt trước khi gắn nhãn "AI agent" cho một quy trình tự động hoá: nếu mọi bước đều cố định và biết trước, thì phần thông minh nằm ở đâu? Với những quy trình như vậy, một công cụ điều phối workflow thông thường thường rẻ hơn, ổn định hơn và dễ kiểm toán hơn nhiều.

Đáp án

A — Large Language Model (LLM) — mô hình ngôn ngữ lớn.

Vì sao đúng

Đề mô tả đúng định nghĩa: mô hình huấn luyện trên khối văn bản khổng lồ, để hiểu, sinh và xử lý ngôn ngữ con người cho nhiều loại nhiệm vụ — dịch, tóm tắt, hỏi đáp.

⚠ Đặc điểm của LLM:

⚠ HUẤN LUYỆN trên dữ liệu văn bản
  RẤT LỚN
    → ⚠ tự giám sát, không cần nhãn

⚠ ĐA NHIỆM
    → ⚠ MỘT mô hình làm nhiều việc
    → dịch, tóm tắt, hỏi đáp, viết mã

⚠ KIẾN TRÚC transformer

⚠ Đó là lý do gọi là MÔ HÌNH NỀN
    → ⚠ nền cho nhiều ứng dụng

⚠ Vì sao ba phương án kia sai:

"CNN"
    → ⚠ mạng tích chập, chủ yếu cho
      ẢNH — thế mạnh là thị giác máy

"Decision Tree"
    → ⚠ mô hình dự đoán trên dữ liệu
      BẢNG, không sinh văn bản

"Clustering Algorithm"
    → ⚠ gom nhóm không giám sát,
      không sinh gì

Nhất quán với #13956 và #13958 (cùng lô) về bản đồ khái niệm. LLM là một dạng mô hình nền thuộc AI sinh, nằm trong deep learning.

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

• D (CNN) — phương án gần nhất và là bẫy chính: cũng là mạng nơ-ron sâu và cũng nổi tiếng. Nhưng thế mạnh của CNN là xử lý ảnh, không phải ngôn ngữ đa nhiệm.

• C và B — mô hình học máy cổ điển, không sinh văn bản.

Ghi nhớ

⚠ Các kiến trúc mô hình — bảng nên thuộc: | Kiến trúc | Mạnh ở | Ví dụ | |---|---|---| | ⚠ Transformer / LLM | ⚠ NGÔN NGỮ, đa nhiệm | ⚠ Gemini, Gemma | | ⚠ CNN | ⚠ ẢNH, thị giác | phân loại ảnh | | ⚠ Diffusion | ⚠ SINH ảnh, video | Imagen, Veo | | RNN / LSTM | ⚠ dữ liệu tuần tự — thế hệ trước | | | Decision tree / boosting | ⚠ dữ liệu BẢNG | XGBoost | | K-means | phân cụm | |

Từ khoá nhận diện:

"văn bản lớn, đa nhiệm ngôn ngữ" → ⚠ LLM "xử lý ảnh, tích chập" → ⚠ CNN "khử nhiễu sinh ảnh" → diffusion "dữ liệu bảng, dự đoán" → ⚠ cây quyết định, boosting

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Dữ liệu là văn bản hay bảng | ⚠ bảng → mô hình cổ điển thường tốt hơn | | Có cần độ chính xác tuyệt đối không | ⚠ có → gọi công cụ, đừng để LLM tự làm | | Có cần kiến thức mới không | ⚠ có → grounding |

Và điều đáng nhớ giữa lúc mọi bài toán đều được đề xuất giải bằng mô hình ngôn ngữ: LLM giỏi ở ngôn ngữ, không giỏi ở mọi thứ. Với dữ liệu bảng và bài toán dự đoán số, những mô hình ra đời từ trước vẫn cho kết quả chính xác hơn với chi phí thấp hơn nhiều.

Đáp án

C — Giảm chi phí hoặc tăng hiệu quả vận hành (cost reduction / efficiency gains).

Vì sao đúng

Công ty đo thời gian trung bình nhân viên xử lý một vấn đề, so trước và sau khi có chatbot. Đó là đo hiệu quả vận hành, quy đổi trực tiếp ra chi phí.

⚠ Vì sao là hiệu quả chứ không phải doanh thu:

"thời gian nhân viên xử lý"
        ↓
    ⚠ ít thời gian hơn
    = ⚠ ít giờ công hơn
    = ⚠ CHI PHÍ THẤP HƠN
    hoặc phục vụ được nhiều khách hơn
      với cùng số nhân viên
        ↓
    → ⚠ tiết kiệm chi phí / tăng
      hiệu quả

⚠ Vì sao ba phương án kia sai:

"Tạo doanh thu trực tiếp"
    → ⚠ chatbot hỗ trợ không BÁN hàng

"Cải thiện cảm nhận thương hiệu"
    → ⚠ đo bằng khảo sát thương hiệu

"Điểm hài lòng của khách"
    → ⚠ đo bằng CSAT, NPS —
      chỉ số KHÁC

Nhất quán với #13894 (lô 145) — đề đó về việc chọn chỉ số TRỰC TIẾP để đo tác động của tính năng AI. Cùng nguyên tắc. Bổ sung nhau.

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

• D (điểm hài lòng khách hàng) — phương án gần nhất và là bẫy chính: chatbot hỗ trợ cũng ảnh hưởng tới hài lòng. Nhưng chỉ số đề nêu là thời gian xử lý của nhân viên, một thước đo hiệu quả nội bộ.

• A và B — đo bằng chỉ số khác hẳn.

Ghi nhớ

⚠ Bốn nhóm tác động của dự án AI — bảng nên thuộc: | Nhóm | Chỉ số | |---|---| | ⚠ Giảm chi phí / tăng hiệu quả | ⚠ thời gian xử lý, số việc/người, chi phí mỗi giao dịch | | Tăng doanh thu | ⚠ chuyển đổi, giá trị đơn, khách mới | | Trải nghiệm khách hàng | ⚠ CSAT, NPS, tỉ lệ giải quyết lần đầu | | Giảm rủi ro | ⚠ lỗi, sự cố tuân thủ | | Nhân viên | ⚠ thời gian đào tạo, tỉ lệ nghỉ việc |

Từ khoá nhận diện:

"thời gian xử lý, giờ công tiết kiệm" → ⚠ hiệu quả / chi phí "tỉ lệ chuyển đổi, doanh thu" → tăng doanh thu "CSAT, NPS" → ⚠ hài lòng khách hàng "số sự cố tuân thủ" → giảm rủi ro

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có đường cơ sở trước không | ⚠ thiếu thì mọi so sánh đều tranh cãi được | | Chất lượng có giảm không | ⚠ đo song song với tốc độ | | Đã trừ chi phí vận hành AI chưa | ⚠ để ra con số ròng |

Và cạm bẫy tinh vi nhất khi đo hiệu quả của một chatbot hỗ trợ: bot xử lý hết ca dễ và chỉ đẩy ca khó lên cho nhân viên, khiến thời gian trung bình của con người tăng lên dù hệ thống tổng thể đã tốt hơn nhiều. Vì vậy con số cần nhìn là tổng chi phí phục vụ, không phải thời gian của riêng một khâu.

Đáp án

D — Accountability và explainability trong AI (trách nhiệm giải trình và khả năng giải thích).

Vì sao đúng

Đề nêu hai yêu cầu song song: cơ chế rõ ràng để xác định TRÁCH NHIỆM về đầu ra của hệ thống, và lập luận của nó PHẢI HIỂU ĐƯỢC. Đó chính là hai nguyên tắc này.

⚠ Hai yêu cầu khớp:

"cơ chế xác định TRÁCH NHIỆM
 về đầu ra"
    → ⚠ ACCOUNTABILITY
    → ⚠ ai chịu trách nhiệm khi
      gợi ý chẩn đoán sai

"lập luận PHẢI HIỂU ĐƯỢC"
    → ⚠ EXPLAINABILITY
    → bác sĩ phải biết mô hình
      dựa vào đâu

⚠ Vì sao y tế đặc biệt khắt khe:

Gợi ý chẩn đoán sai
        ↓
    ⚠ Hậu quả SỨC KHOẺ trực tiếp
    ⚠ Trách nhiệm pháp lý
    ⚠ Cơ quan quản lý kiểm tra
        ↓
    ⚠ "Mô hình gợi ý vậy" KHÔNG
      phải câu trả lời chấp nhận được
        ↓
    → ⚠ phải có NGƯỜI chịu trách
      nhiệm và lập luận giải thích được

⚠ Vì sao ba phương án kia sai:

"Tốc độ suy luận và độ trễ"
    → ⚠ mối quan tâm kỹ thuật

"Chi phí lưu trữ dữ liệu"
    → ⚠ chi phí hạ tầng

"Sự đa dạng của mô hình có sẵn"
    → ⚠ về lựa chọn kỹ thuật

⚠ Gần trùng với #13983 (cùng lô) khoá Transparency + Explainability, và với #13879/#13884 (lô 145). Bốn đề có BỘ PHƯƠNG ÁN KHÁC NHAU, mỗi bộ ghép explainability với một nguyên tắc khác. KHÔNG mâu thuẫn — cách làm bài là chọn cặp phù hợp nhất trong bộ đáp án đang có.

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

• B (tốc độ suy luận và độ trễ) — phương án gần nhất về mặt "cũng là yêu cầu thật với hệ thống y tế cần trả lời nhanh", nhưng nó không liên quan tới trách nhiệm và khả năng giải thích.

• A và C — thuộc mối quan tâm kỹ thuật và chi phí.

Ghi nhớ

⚠ Nguyên tắc AI có trách nhiệm — bảng phải thuộc: | Nguyên tắc | Câu hỏi | |---|---| | ⚠ Accountability | ⚠ AI CHỊU TRÁCH NHIỆM về kết quả? | | ⚠ Explainability | ⚠ vì sao ra kết quả NÀY? | | ⚠ Transparency | ⚠ hệ thống hoạt động THẾ NÀO? | | Fairness | ⚠ có công bằng giữa các nhóm? | | Privacy | dữ liệu có được bảo vệ? | | Safety | có gây hại? |

Từ khoá nhận diện:

"ai chịu trách nhiệm" → ⚠ accountability "vì sao ra kết quả này" → ⚠ explainability "công khai cách hoạt động" → ⚠ transparency "chênh lệch giữa các nhóm" → fairness

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ai ký vào quyết định cuối | ⚠ phải là người, và phải rõ | | Giải thích được cho bác sĩ không | ⚠ thử viết ra một câu | | Có ghi lại đủ để giải trình không | ⚠ cơ quan quản lý có thể hỏi |

Và ranh giới an toàn nhất khi đưa AI vào lĩnh vực y tế: để nó tóm tắt và sắp xếp thông tin, không để nó đưa ra kết luận. Bác sĩ vẫn là người quyết định và chịu trách nhiệm — và điều đó chỉ khả thi nếu họ hiểu được hệ thống đã dựa vào đâu.

Đáp án

C — Vertex AI Model Monitoring.

Vì sao đúng

Đội MLOps phát hiện phân phối đặc trưng đầu vào ở các yêu cầu dự đoán thực tế khác hẳn dữ liệu huấn luyện. Phát hiện skew và drift của dữ liệu đầu vào là chức năng của Model Monitoring.

⚠ Model Monitoring theo dõi gì:

⚠ TRAINING-SERVING SKEW
    → ⚠ dữ liệu phục vụ khác dữ liệu
      huấn luyện NGAY TỪ ĐẦU

⚠ PREDICTION DRIFT
    → ⚠ phân phối đầu vào TRÔI DẦN
      theo thời gian
    → ⚠ ĐỀ NÀY

⚠ Phân phối ĐẦU RA
    → mô hình bỗng dự đoán lệch

⚠ Chất lượng đặc trưng
    → giá trị thiếu, ngoài khoảng

⚠ Cơ chế:

So sánh THỐNG KÊ
    dữ liệu hiện tại  ↔  đường cơ sở
        ↓
    ⚠ Vượt NGƯỠNG đã đặt
        ↓
    ⚠ CẢNH BÁO
        ↓
    → kích hoạt huấn luyện lại

⚠ Vì sao ba phương án kia sai:

"Model Registry"
    → ⚠ quản PHIÊN BẢN mô hình

"Feature Store"
    → ⚠ quản ĐẶC TRƯNG dùng chung;
      ⚠ giúp CHỐNG skew nhưng không
      PHÁT HIỆN drift

"Pipelines"
    → ⚠ TỰ ĐỘNG HOÁ quy trình;
      ⚠ là nơi THỰC HIỆN huấn luyện lại,
      không phải nơi phát hiện

Nhất quán với #13882 (lô 145) và #13922 (lô 146) — hai đề đó về giám sát drift, đề này hỏi công cụ cụ thể trên Vertex AI. Bổ sung nhau.

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

• D (Pipelines) — phương án gần nhất vì nó thường được kích hoạt khi phát hiện drift. Nhưng nó thực hiện việc huấn luyện lại, còn việc phát hiện thuộc Model Monitoring.

• B (Feature Store) và A (Model Registry) — phục vụ khâu khác.

Ghi nhớ

⚠ Công cụ MLOps — mỗi cái một việc, bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Model Monitoring | ⚠ PHÁT HIỆN drift và skew | | Model Registry | ⚠ quản phiên bản, lineage | | Feature Store | ⚠ đặc trưng dùng chung — CHỐNG skew | | Pipelines | ⚠ tự động hoá, THỰC HIỆN huấn luyện lại | | Experiments | so sánh thử nghiệm | | TensorBoard | biểu đồ huấn luyện |

Từ khoá nhận diện:

"phân phối đầu vào khác dữ liệu huấn luyện" → ⚠ Model Monitoring "quản phiên bản, quay lui" → Model Registry "đặc trưng tính giống nhau hai nơi" → ⚠ Feature Store "tự động hoá huấn luyện lại" → Pipelines

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật Model Monitoring chưa | ⚠ không có thì chỉ biết khi đã muộn | | Ngưỡng đặt ở đâu, ai nhận cảnh báo | ⚠ phải có người hành động | | Huấn luyện lại có tự động không | ⚠ thủ công thì dễ bị bỏ quên |

Và với những bài toán mà nhãn thật chỉ xuất hiện sau nhiều tháng — như dự đoán giá nhà — giám sát phân phối đầu vào là tín hiệu cảnh báo sớm duy nhất bạn có. Chờ tới khi đo được sai số thực tế thì mô hình đã đưa ra hàng nghìn dự đoán lệch.

Đáp án

A — AI transparency và explainability (tính minh bạch và khả năng giải thích của AI).

Vì sao đúng

Đề nhấn mạnh: người dân và cơ quan giám sát phải HIỂU ĐƯỢC cách AI đưa ra khuyến nghị. Nhu cầu về khả năng hiểu được đó chính là minh bạch và giải thích được.

⚠ Vì sao phân bổ phúc lợi xã hội cần minh bạch:

Quyết định về phúc lợi
        ↓
    ⚠ Ảnh hưởng trực tiếp tới
      đời sống người dân
    ⚠ Dùng tiền công
    ⚠ Có cơ quan giám sát
        ↓
    ⚠ Người dân có QUYỀN biết
      vì sao bị từ chối
    ⚠ Cơ quan giám sát phải
      kiểm tra được
        ↓
    → ⚠ không minh bạch = không có
      niềm tin công chúng

⚠ Vì sao ba phương án kia sai:

"Data privacy"
    → ⚠ rất quan trọng với dữ liệu
      công dân, nhưng đề hỏi về
      KHẢ NĂNG HIỂU ĐƯỢC

"Model scalability" → ⚠ khả năng mở rộng
"Speed of inference" → ⚠ độ trễ

⚠ Gần trùng với #13981 (cùng lô) khoá Accountability + Explainability cho y tế, và #13884 (lô 145) khoá Transparency + Explainability cho khu vực công. Bộ phương án khác nhau nên khoá khác nhau. KHÔNG mâu thuẫn — cách làm bài là chọn cặp phù hợp nhất trong bộ đáp án hiện có.

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

• B (data privacy) — phương án gần nhất và là bẫy mạnh: hệ thống này xử lý dữ liệu công dân nhạy cảm. Nhưng câu hỏi hỏi về khả năng hiểu được quá trình ra quyết định, không phải bảo vệ dữ liệu.

• C và D — thuộc mối quan tâm kỹ thuật.

Ghi nhớ

⚠ Transparency và explainability — phân biệt tinh tế: | | ⚠ Transparency | ⚠ Explainability | |---|---|---| | Trả lời | ⚠ hệ thống hoạt động THẾ NÀO | ⚠ vì sao ra kết quả NÀY | | Phạm vi | ⚠ toàn hệ thống | ⚠ từng quyết định cụ thể | | Ví dụ | ⚠ công bố dùng AI, dữ liệu gì | ⚠ yếu tố nào dẫn tới từ chối | | Thường đi cùng nhau | ⚠ và đề thi hay ghép cặp | |

Từ khoá nhận diện:

"hiểu được cách AI ra quyết định" → ⚠ transparency + explainability "ai chịu trách nhiệm" → ⚠ accountability "chênh lệch giữa các nhóm" → fairness "bảo vệ dữ liệu cá nhân" → privacy

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Giải thích được cho người dân không | ⚠ bằng ngôn ngữ thường, không thuật ngữ | | Có kiểm toán độc lập không | ⚠ tự kiểm hay bỏ sót | | Ai ra quyết định cuối | ⚠ với phúc lợi công, phải là người |

Và phép thử thực tế cho tính minh bạch của một hệ thống AI trong khu vực công: thử viết một đoạn giải thích cho người dân mà không dùng thuật ngữ kỹ thuật. Nếu không viết nổi, thì hệ thống chưa sẵn sàng cho những quyết định ảnh hưởng tới đời sống của họ.

Đáp án

B — Supervised learning (học có giám sát).

Vì sao đúng

Mỗi khách hàng trong dữ liệu đã được gán nhãn rõ ràng là "đã rời bỏ" hoặc "chưa rời bỏ". Học từ dữ liệu có đáp án đúng cho sẵn chính là học có giám sát.

⚠ Vì sao là có giám sát:

"mỗi khách hàng ĐƯỢC GÁN NHÃN
 rõ ràng"
        ↓
    ⚠ Có ĐẦU VÀO: dữ liệu lịch sử
    ⚠ Có ĐẦU RA ĐÚNG: churned /
      not churned
        ↓
    ⚠ Mô hình học ánh xạ giữa hai cái
        ↓
    → ⚠ bài toán PHÂN LOẠI nhị phân

⚠ Vì sao ba phương án kia sai:

"Unsupervised learning"
    → ⚠ KHÔNG có nhãn; mô hình
      tự tìm nhóm

"Reinforcement learning"
    → ⚠ học qua thưởng/phạt

"Generative learning"
    → ⚠ không phải tên chuẩn của
      một nhóm phương pháp học

Nhất quán với #13889 (lô 145) — đề đó là bài báo đã gán chủ đề, cùng khoá labeled/supervised. Đối chiếu #13887 (lô 145) và #13919 (cùng lô) khoá không giám sát vì không có nhãn. Hoàn toàn nhất quán.

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

• A (unsupervised) — phương án gần nhất và là bẫy chính: cũng phân tích dữ liệu khách hàng. Nhưng đề nói rõ đã có nhãn, mà học không giám sát là khi không có nhãn.

• D và C — không đúng với dữ kiện.

Ghi nhớ

⚠ Ba nhóm phương pháp học — bảng phải thuộc: | Nhóm | Tín hiệu học | Bài toán | |---|---|---| | ⚠ Có giám sát | ⚠ NHÃN đúng cho từng mẫu | ⚠ phân loại, hồi quy | | ⚠ Không giám sát | ⚠ KHÔNG có nhãn | ⚠ phân cụm, giảm chiều | | ⚠ Tăng cường | ⚠ thưởng/phạt | game, robot |

Từ khoá nhận diện:

"đã gán nhãn, có đáp án đúng" → ⚠ có giám sát "không nhãn, tự tìm nhóm" → không giám sát "học qua thử và sai" → tăng cường "tạo nội dung mới" → ⚠ AI sinh — thường tự giám sát

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có cột nào lộ đáp án không | ⚠ leakage là lỗi phổ biến nhất | | Tỉ lệ rời bỏ thật là bao nhiêu | ⚠ quyết định cách đánh giá | | Dự đoán xong thì làm gì | ⚠ không có hành động thì mô hình vô ích |

Và điều quyết định giá trị của một mô hình dự đoán rời bỏ không phải độ chính xác: có can thiệp nào thật sự giữ được khách hay không. Danh sách khách sắp rời bỏ chỉ có ích khi đi kèm một hành động đã được chứng minh là hiệu quả — và điều đó phải đo bằng thử nghiệm có nhóm đối chứng.

Đáp án

B — Năng lực sinh sáng tạo dựa trên các phong cách đã học.

Vì sao đúng

Mô hình tạo ra bản nhạc MỚI, phù hợp mô tả, mang phong cách Chopin, nhưng không sao chép bản nào có sẵn. Đó là năng lực sinh sáng tạo dựa trên mẫu hình đã học.

⚠ Điểm mấu chốt trong đề:

"tạo ra bản nhạc MỚI"
    → ⚠ chưa từng tồn tại

"PHÙ HỢP mô tả"
    → ⚠ buồn, dương cầm, ngắn

"theo PHONG CÁCH Chopin"
    → ⚠ học được mẫu hình

"KHÔNG phải bản sao"
    → ⚠ không phải ghi nhớ và
      nhắc lại

⚠ Sinh sáng tạo khác ghi nhớ thế nào:

⚠ GHI NHỚ (memorization)
    → ⚠ nhắc lại nguyên văn dữ liệu
      huấn luyện
    → ⚠ RỦI RO bản quyền và riêng tư
    → ⚠ điều cần TRÁNH

⚠ SINH SÁNG TẠO
    → ⚠ học ĐẶC TRƯNG của phong cách
    → ⚠ tổ hợp thành thứ mới
    → ⚠ điều mong muốn

⚠ Vì sao ba phương án kia sai:

"Sao chép hoàn hảo dữ liệu huấn luyện"
    → ⚠ NGƯỢC: đề nói rõ KHÔNG
      phải bản sao
    → ⚠ và nếu thế thì là LỖI

"Dự đoán xu hướng âm nhạc tương lai"
    → ⚠ AI dự đoán, không phải sinh

"Truy xuất thông tin từ CSDL nhạc"
    → ⚠ tìm cái đã có, không tạo mới

Nhất quán với #13926 (lô 146) — đề đó phân biệt AI sinh với AI dự đoán. Và #13908 (lô 146) về sinh âm thanh. Bổ sung nhau.

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

• A (sao chép hoàn hảo) — phương án gần nhất về mặt "cũng nói tới quan hệ với dữ liệu huấn luyện", nhưng nó mô tả điều ngược hẳn với những gì đề nêu, và đó cũng là một lỗi chứ không phải năng lực.

• C và D — mô tả các loại AI khác.

Ghi nhớ

⚠ Sinh sáng tạo và ghi nhớ — bảng phải thuộc: | | ⚠ Sinh sáng tạo | ⚠ Ghi nhớ (memorization) | |---|---|---| | Kết quả | ⚠ nội dung MỚI | ⚠ nhắc lại nguyên văn | | Đánh giá | ⚠ mong muốn | ⚠ LỖI cần tránh | | Rủi ro | ⚠ bản quyền phong cách | ⚠ vi phạm bản quyền, lộ dữ liệu | | Nguyên nhân ghi nhớ | ⚠ dữ liệu lặp nhiều, mô hình quá khớp | |

Từ khoá nhận diện:

"tạo nội dung mới theo phong cách đã học" → ⚠ sinh sáng tạo "nhắc lại nguyên văn dữ liệu huấn luyện" → ⚠ memorization — lỗi "dự đoán xu hướng" → AI dự đoán "tìm bản nhạc có sẵn" → truy xuất thông tin

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Kết quả có trùng tác phẩm nào không | ⚠ kiểm trước khi dùng thương mại | | Được dùng thương mại không | ⚠ đọc giấy phép mô hình | | Có ghi rõ nội dung do AI tạo không | ⚠ nhiều nền tảng yêu cầu |

Và ranh giới quan trọng cần kiểm khi dùng nội dung do AI sinh cho mục đích thương mại: liệu kết quả có vô tình trùng khớp với một tác phẩm có bản quyền hay không. Sinh sáng tạo là điều mong muốn, còn ghi nhớ và nhắc lại là một lỗi có hậu quả pháp lý thật.