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

Đáp án

A — Gán cho lập trình viên một vai IAM KHÔNG bao gồm quyền xoá cơ sở dữ liệu.

Vì sao đúng

Chính sách bảo mật được thực thi bằng IAM, không bằng lời dặn hay bằng công cụ giám sát.

⚠ IAM hoạt động ở mức QUYỀN:

Mỗi vai = một TẬP HỢP quyền
        ↓
    `cloudsql.instances.create`
    `cloudsql.instances.update`
    ⚠ `cloudsql.instances.delete`
        ↓
    ⚠ Chọn vai KHÔNG chứa
      quyền `delete`
        ↓
    → chính sách được thực thi
      ở TẦNG NỀN TẢNG

⚠ Quy trình chọn vai đúng:

1. Liệt kê việc lập trình viên
   cần làm trên production
        ↓
2. ⚠ Tìm VAI DỰNG SẴN gần nhất
   (ví dụ `cloudsql.editor` —
    kiểm xem có `delete` không)
        ↓
3. Nếu vẫn quá rộng
        ↓
4. ⚠ Tạo VAI TUỲ BIẾN với đúng
   danh sách quyền cần

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

"Dùng CLOUD MONITORING để theo dõi
 hiệu năng CSDL"
    → ⚠ giám sát HIỆU NĂNG,
      không kiểm soát QUYỀN
    → biết sau khi đã xoá thì muộn

"Cấp máy ảo MẠNH cho lập trình viên"
    → ⚠ không liên quan gì

"TIN rằng lập trình viên không
 mắc lỗi"
    → ⚠ không phải cơ chế thực thi
    → ⚠ và lỗi con người là điều
      chắc chắn xảy ra

⚠ Gần trùng với #13487 (cùng lô này) — đề đó cũng là cho phép tạo nhưng cấm xoá, và cùng khoá "chọn vai không có quyền xoá". Hoàn toàn nhất quán.

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

• B (dùng Cloud Monitoring để theo dõi hiệu năng CSDL) — phương án gần nhất về mặt "cũng là một công cụ quản trị", nhưng giám sát phát hiện SAU khi việc đã xảy ra; nó không ngăn được thao tác xoá.

• D (tin rằng lập trình viên không mắc lỗi) — không phải cơ chế thực thi chính sách.

• C (cấp máy ảo mạnh) — hoàn toàn không liên quan.

Ghi nhớ

⚠ Bốn cơ chế thực thi chính sách — bảng phải thuộc: | Cơ chế | Tác dụng | |---|---| | ⚠ IAM | ⚠ AI được làm gì — thực thi ở tầng nền tảng | | ⚠ IAM Deny policy | ⚠ chặn tường minh dù có vai | | Organization Policy | cấm loại hành vi, kể cả Owner | | Deletion protection | ⚠ cờ ngay trên tài nguyên | | Audit log | ghi lại, phát hiện sau |

Từ khoá nhận diện:

"cấm một thao tác cụ thể" → ⚠ vai không có quyền đó, hoặc Deny policy "cấm hành vi ở mọi project" → Organization Policy "chặn số lượng tài nguyên" → quota "ghi lại ai đã làm gì" → audit log

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vai đó có quyền xoá không | ⚠ đọc danh sách quyền trong tài liệu | | Thử xoá có bị chặn không | ⚠ thử bằng chính tài khoản đó ở môi trường thử | | Deletion protection đã bật chưa | gcloud sql instances describe |

Và một lớp bảo vệ đơn giản mà nhiều đội quên bật: cờ deletion protection trên chính instance cơ sở dữ liệu. Nó độc lập với IAM, chặn được cả người thật sự có quyền xoá, và chỉ mất một lệnh để bật — nhưng lại là thứ đứng giữa một lần gõ nhầm và một buổi tối khôi phục dữ liệu.

Đáp án

A — Cơ sở dữ liệu thường dùng để VẬN HÀNH doanh nghiệp (OLTP), còn kho dữ liệu dùng để PHÂN TÍCH doanh nghiệp (OLAP).

Vì sao đúng

Đây là ranh giới kinh điển, và cách diễn đạt "run the business" vs "analyze the business" là cách nhớ tốt nhất.

⚠ Hai vai trò:

⚠ DATABASE — VẬN HÀNH (OLTP)
    → đặt hàng, thanh toán,
      cập nhật hồ sơ
    → ⚠ nhiều thao tác NHỎ, rất nhanh
    → độ trễ MILI-GIÂY
    → dữ liệu HIỆN HÀNH
    → Cloud SQL, Spanner, Firestore

⚠ DATA WAREHOUSE — PHÂN TÍCH (OLAP)
    → báo cáo, xu hướng, dự báo
    → ⚠ ÍT truy vấn nhưng quét
      RẤT NHIỀU
    → độ trễ GIÂY
    → dữ liệu LỊCH SỬ
    → BigQuery

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

"Database lưu PHI CẤU TRÚC,
 warehouse lưu CÓ CẤU TRÚC"
    → ⚠ SAI: cả hai đều làm việc
      với dữ liệu CÓ CẤU TRÚC
    → phi cấu trúc là DATA LAKE

"Database LUÔN LỚN HƠN warehouse"
    → ⚠ NGƯỢC: kho dữ liệu thường
      lớn hơn nhiều vì chứa lịch sử

"Database dùng cho PHÂN TÍCH,
 warehouse dùng cho GIAO DỊCH"
    → ⚠ ĐẢO NGƯỢC hoàn toàn

⚠ Gần trùng với #13392 (lô 141) — đề đó so Cloud SQL và BigQuery, và cùng ranh giới OLTP/OLAP. Và #13296 (lô 139) — câu phủ định về việc BigQuery không phải cho OLTP. Cả ba nhất quán.

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

• D (database dùng cho phân tích, warehouse dùng cho giao dịch) — phương án gần nhất về mặt "có đúng hai khái niệm", nhưng đảo ngược hoàn toàn vai trò.

• B (database lưu phi cấu trúc) — sai; cả hai đều làm việc với dữ liệu có cấu trúc. Phi cấu trúc là địa hạt của data lake.

• C (database luôn lớn hơn) — ngược lại; kho dữ liệu thường lớn hơn nhiều.

Ghi nhớ

⚠ Database, Warehouse, Lake — bảng phải thuộc: | | Database | Data Warehouse | Data Lake | |---|---|---|---| | Mục đích | ⚠ VẬN HÀNH (OLTP) | ⚠ PHÂN TÍCH (OLAP) | khám phá | | Dữ liệu | hiện hành | lịch sử, đã sạch | ⚠ thô, mọi định dạng | | Schema | on-write | on-write | ⚠ on-read | | Độ trễ | mili-giây | giây | tuỳ | | Sản phẩm | Cloud SQL, Spanner | BigQuery | ⚠ Cloud Storage |

Từ khoá nhận diện:

"vận hành, giao dịch, đặt hàng" → database (OLTP) "phân tích, báo cáo, xu hướng" → warehouse (OLAP) "thô, định dạng gốc, chưa biết dùng làm gì" → data lake "kết hợp cả hồ và kho" → ⚠ lakehouse — BigLake, Dataplex

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Cần trả lời trong mili-giây không | có → database | | Truy vấn quét bao nhiêu dữ liệu | rất nhiều → warehouse | | Có cần giao dịch nhiều bảng không | có → database |

Và một dấu hiệu rất dễ nhận biết rằng ai đó đang dùng sai công cụ: báo cáo cuối tháng làm chậm trang thanh toán. Đó là lúc tải phân tích và tải giao dịch đang tranh nhau cùng một cơ sở dữ liệu — và cách chữa không phải mua máy to hơn mà là tách chúng ra hai hệ thống.

Đáp án

D — Nó tạo ra tính co giãn, cho phép doanh nghiệp tăng hoặc giảm tài nguyên để khớp với nhu cầu.

Vì sao đúng

Elasticity là lợi ích mà hạ tầng tại chỗ không thể có, vì phần cứng vật lý không tự tăng giảm được.

⚠ Tại chỗ và đám mây:

TẠI CHỖ
    → ⚠ phải mua cho MỨC ĐỈNH
    → ⚠ 90% thời gian máy nằm không
    → ⚠ đoán thiếu thì SẬP đúng
      ngày cao điểm
    → mua thêm mất hàng tuần

ĐÁM MÂY
    → ⚠ tăng trong vài phút
    → ⚠ GIẢM khi hết cao điểm
    → trả cho mức dùng thật

⚠ Hai từ đi cùng nhau:

SCALABILITY (khả năng mở rộng)
    → tăng năng lực khi cần

⚠ ELASTICITY (tính co giãn)
    → ⚠ tăng VÀ GIẢM tự động
      theo nhu cầu thật
        ↓
    ⚠ Vế "GIẢM" mới là chỗ
      tiết kiệm tiền

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

"Chuyển chi tiêu từ OpEx dễ đoán
 sang CapEx lớn trả trước"
    → ⚠ ĐẢO NGƯỢC chiều

"BUỘC bị khoá vào MỘT nhà cung cấp
 phần cứng độc quyền"
    → ⚠ NGƯỢC: đám mây giảm phụ thuộc
      phần cứng, và chuẩn mở giảm
      khoá chân

"GIẢM tính linh hoạt bằng cách
 TĂNG thời gian cấp máy chủ"
    → ⚠ NGƯỢC hoàn toàn: đám mây
      cấp máy trong vài phút

⚠ Gần trùng với #13394 (lô 141) và #13278 (lô 138) — cả ba đề đều về co giãn theo nhu cầu, và cả ba cùng khoá. Hoàn toàn nhất quán.

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

• A (chuyển từ OpEx sang CapEx) — phương án gần nhất về mặt thuật ngữ, nhưng đảo ngược chiều: đám mây chuyển CapEx sang OpEx.

• B (bị khoá vào một nhà cung cấp phần cứng) — ngược lại; đám mây và chuẩn mở giảm phụ thuộc.

• C (giảm linh hoạt, tăng thời gian cấp máy) — ngược hoàn toàn.

Ghi nhớ

⚠ Sáu lợi ích cốt lõi của đám mây — bảng nên thuộc: | Lợi ích | Nội dung | |---|---| | ⚠ Elasticity | ⚠ tăng và giảm tự động theo nhu cầu | | Agility | triển khai trong phút thay vì tuần | | Trả theo mức dùng | ⚠ CapEx → OpEx | | Vươn ra toàn cầu | vùng mới trong vài phút | | Độ tin cậy | đa zone, đa vùng | | Dịch vụ có quản lý | đội tập trung vào sản phẩm |

Từ khoá nhận diện:

"tăng giảm theo nhu cầu" → elasticity "ra tính năng nhanh" → agility "trả theo mức dùng" → CapEx → OpEx "chuẩn mở, không khoá chân" → Freedom

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có mở rộng kịp không | ⚠ thử tải mô phỏng đỉnh | | Có thu hẹp lại không | ⚠ xem số instance ban đêm | | Quota có đủ không | xin nâng trước |

Và một chi tiết đáng kiểm tra ngay hôm nay nếu hệ thống của bạn đã có autoscaling: số lượng instance vào lúc 3 giờ sáng. Nếu nó vẫn bằng lúc cao điểm, thì bạn đang có scalability mà chưa có elasticity — và đang trả tiền cho phần chênh lệch đó mỗi đêm.

Đáp án

B — AutoML, vì nó cho sự cân bằng đúng giữa khả năng tuỳ biến và tính dễ dùng.

Vì sao đúng

AutoML nằm chính giữa phổ giải pháp học máy của Google Cloud: dữ liệu riêng của bạn, nhưng không phải viết mã mô hình.

⚠ Ba nấc — thuộc bảng này là làm được mọi câu về AI:

NẤC 1 — API DỰNG SẴN
    → Vision, Speech, Translation
    → ⚠ mô hình của Google,
      KHÔNG huấn luyện gì
    → dùng ngay trong ngày

⚠ NẤC 2 — AutoML (Vertex AI)
    → ⚠ DỮ LIỆU RIÊNG của bạn
    → ⚠ KHÔNG viết mã mô hình
    → giao diện, tự chọn kiến trúc
    → ⚠ CÂN BẰNG — đề này

NẤC 3 — HUẤN LUYỆN TUỲ BIẾN
    → tự viết TensorFlow / PyTorch
    → ⚠ toàn quyền, cần đội ML

⚠ Cách chọn nấc:

Nhu cầu là tác vụ PHỔ QUÁT?
    (đọc chữ, dịch, nhận giọng)
        ↓ có
    → ⚠ API dựng sẵn

Cần nhận diện thứ RIÊNG của
ngành mình, nhưng ĐỘI KHÔNG
CÓ chuyên gia ML?
        ↓ có
    → ⚠ AutoML

Cần kiểm soát kiến trúc mô hình,
có đội khoa học dữ liệu?
        ↓ có
    → huấn luyện tuỳ biến

Nhất quán với #13380 (lô 141), #13273 (lô 139), #13419 (lô 142) — cả bốn đề đều khoá AutoML cho tình huống "dữ liệu riêng + không có chuyên gia ML". Đối chiếu #13453 (lô 142) khoá huấn luyện tuỳ biến vì đề đó nói rõ "toàn quyền kiểm soát kiến trúc". Không mâu thuẫn — khác mức kiểm soát cần có.

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

• A/C (API dựng sẵn) — phương án gần nhất về mặt "dễ dùng nhất", nhưng chúng chỉ nhận diện được những nhãn phổ quát mà Google đã huấn luyện, không học được dữ liệu riêng của bạn.

• D (huấn luyện tuỳ biến) — cho tuỳ biến cao nhất nhưng đánh mất vế "dễ dùng"; cần đội biết viết mã học máy.

Ghi nhớ

⚠ Ba nấc AI trên Google Cloud — bảng phải thuộc: | Nấc | Dữ liệu | Kỹ năng cần | Thời gian | |---|---|---|---| | API dựng sẵn | ⚠ của Google | gọi API | giờ | | ⚠ AutoML | ⚠ CỦA BẠN | ⚠ gán nhãn, không viết mã | ngày | | Huấn luyện tuỳ biến | của bạn | ⚠ kỹ sư ML | tuần–tháng |

Từ khoá nhận diện:

"nhãn riêng, không có chuyên gia ML" → ⚠ AutoML "tác vụ phổ quát, cần ngay" → API dựng sẵn "toàn quyền kiến trúc" → huấn luyện tuỳ biến "dữ liệu đã ở BigQuery, đội biết SQL" → ⚠ BigQuery ML

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Nhãn có phải riêng của ngành không | có → AutoML trở lên | | Đội có kỹ sư ML không | không → ⚠ AutoML | | Có bao nhiêu dữ liệu đã gán nhãn | ít → ⚠ cân nhắc API dựng sẵn trước |

Và một thứ hay bị đánh giá thấp khi lập kế hoạch cho dự án AutoML: công sức gán nhãn dữ liệu. Việc huấn luyện có thể chỉ mất vài giờ máy, nhưng chuẩn bị vài nghìn mẫu có nhãn sạch và nhất quán mới là phần chiếm phần lớn lịch trình — và cũng là phần quyết định mô hình tốt tới đâu.

Đáp án

D — Vision AI API, để nhận diện các địa danh trong ảnh.

Vì sao đúng

Nhận diện địa danh (landmark detection) là một tính năng có tên chính thức của Cloud Vision API — đúng loại tác vụ phổ quát mà mô hình dựng sẵn của Google đã học.

⚠ Vision API làm được gì:

⚠ LANDMARK DETECTION
    → nhận ra Tháp Eiffel, Vạn Lý
      Trường Thành, Nhà hát Opera
      Sydney — kèm toạ độ

LABEL DETECTION
    → "biển", "hoàng hôn", "chó"

TEXT DETECTION / OCR
    → đọc chữ trong ảnh, cả chữ viết tay

⚠ SAFE SEARCH
    → lọc nội dung phản cảm

FACE / OBJECT / LOGO DETECTION

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

"Natural Language API"
    → ⚠ xử lý VĂN BẢN, không đọc ảnh

"Speech-to-Text API"
    → ⚠ chuyển ÂM THANH thành chữ

"Translation API"
    → ⚠ DỊCH văn bản

Đề nói ảnh du lịch và địa danh — chỉ có một dịch vụ về thị giác máy tính trong danh sách.

Nhất quán với #13325 và #13357 (lô 140) — cả ba đều khoá Vision API cho tác vụ trên ảnh. Đề này chỉ khác ở chỗ dùng đúng tên tính năng landmark detection.

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

• A/B/C (Natural Language, Speech-to-Text, Translation) — đều là API AI dựng sẵn của Google Cloud, nhưng không xử lý ảnh: chúng làm việc với văn bản và âm thanh.

Ghi nhớ

⚠ Bản đồ API AI dựng sẵn theo LOẠI DỮ LIỆU — bảng phải thuộc: | Đầu vào | API | Ra gì | |---|---|---| | ⚠ Ảnh | ⚠ Vision API | nhãn, chữ, mặt, ⚠ địa danh, logo | | Video | Video Intelligence | ⚠ nhãn theo MỐC THỜI GIAN | | Âm thanh | Speech-to-Text | văn bản | | Văn bản → âm thanh | Text-to-Speech | giọng đọc | | Văn bản | Natural Language | ⚠ cảm xúc, thực thể, cú pháp | | Văn bản → ngôn ngữ khác | Translation | bản dịch | | Tài liệu | Document AI | ⚠ trích trường từ hoá đơn, hợp đồng |

Từ khoá nhận diện:

"ảnh, nhận diện, địa danh, vật thể" → Vision API "video, cảnh nào ở phút mấy" → Video Intelligence "hoá đơn, biểu mẫu, trích trường" → ⚠ Document AI "nhãn RIÊNG mà Google không biết" → AutoML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | API có nhận ra địa danh của bạn không | ⚠ thử ngay trên trang Vision API demo | | Chi phí bao nhiêu | ⚠ số ảnh × số tính năng bật | | Có cần nhãn riêng không | có → AutoML Vision |

Và một cách rút ngắn cuộc tranh luận "API dựng sẵn có đủ không": kéo thả vài chục ảnh thật vào trang demo của Vision API. Chỉ mất mười phút, và câu trả lời nhận được đáng tin hơn nhiều so với việc bàn luận trên lý thuyết xem mô hình của Google có biết những gì.

Đáp án

C — Cloud Marketplace.

Vì sao đúng

Cloud Marketplace là danh mục giải pháp dựng sẵn, triển khai được bằng một cú bấm — đúng yêu cầu "stack quen thuộc, đã được duyệt, không cấu hình tay".

⚠ Marketplace giải quyết gì:

Mỗi lập trình viên tự dựng
LAMP stack bằng tay
        ↓
    ⚠ mỗi người một phiên bản
    ⚠ mất hàng giờ
    ⚠ cấu hình lệch nhau
        ↓
    → ⚠ Cloud Marketplace:
      giải pháp đã đóng gói,
      ⚠ NHẤT QUÁN và NHANH

⚠ Marketplace có gì:

GIẢI PHÁP MÃ NGUỒN MỞ
    → LAMP, WordPress, GitLab,
      Jenkins, PostgreSQL
    → ⚠ thường MIỄN PHÍ phần mềm,
      chỉ trả tiền hạ tầng

PHẦN MỀM THƯƠNG MẠI
    → ⚠ tính tiền QUA HOÁ ĐƠN
      Google Cloud

⚠ SAAS và API bên thứ ba
DỊCH VỤ KUBERNETES

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

"Cloud Billing Reports"
    → ⚠ xem CHI PHÍ, không triển khai gì

"Cloud Monitoring Dashboards"
    → ⚠ xem TÌNH TRẠNG hệ thống

"IAM Policies"
    → ⚠ quyết định AI ĐƯỢC LÀM GÌ,
      không dựng ứng dụng

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

• B (Cloud Monitoring Dashboards) — phương án gần nhất về mặt "cũng là công cụ trong Console", nhưng nó theo dõi hệ thống đang chạy chứ không tạo ra hệ thống.

• A (Billing Reports) — công cụ tài chính.

• D (IAM Policies) — kiểm soát quyền, không triển khai hạ tầng.

Ghi nhớ

⚠ Bốn cách dựng hạ tầng nhất quán — bảng nên thuộc: | Cách | Khi nào | |---|---| | ⚠ Cloud Marketplace | ⚠ stack phổ biến, một cú bấm | | Infrastructure as Code (Terraform) | ⚠ hạ tầng riêng, quản bằng Git | | Instance template + MIG | nhiều VM giống hệt nhau | | Custom image | ⚠ máy đã cài sẵn, khởi động nhanh | | Điểm chung | ⚠ loại bỏ cấu hình THỦ CÔNG |

Từ khoá nhận diện:

"một cú bấm, giải pháp dựng sẵn" → Cloud Marketplace "hạ tầng khai báo, quản bằng mã" → ⚠ Terraform / IaC "nhiều máy giống nhau tự co giãn" → instance template + MIG "đóng gói ứng dụng chạy mọi nơi" → container

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giải pháp này tính tiền thế nào | ⚠ đọc trang chi tiết trước khi bấm | | Cỡ máy mặc định có hợp không | sửa trước khi triển khai | | Ai được phép triển khai | ⚠ IAM + Private Marketplace |

Và điểm mà "một cú bấm" hay khiến người ta quên: cụm máy vừa dựng lên vẫn là tài nguyên tính tiền theo giờ. Sự tiện lợi của Marketplace nằm ở khâu dựng, không ở khâu vận hành — phần vá lỗi, sao lưu và tắt khi không dùng vẫn thuộc về đội của bạn.

Đáp án

B — Để con người có thể HIỂU, TIN TƯỞNG và quản lý hiệu quả các quyết định của mô hình.

Vì sao đúng

Explainability (khả năng giải thích) là một trong những trụ cột của Responsible AI — và lý do tồn tại của nó hoàn toàn nằm ở phía con người.

⚠ Vì sao cần giải thích được:

Mô hình từ chối hồ sơ vay
        ↓
    ⚠ Khách hàng hỏi "vì sao?"
    ⚠ Cơ quan quản lý yêu cầu
      lý do
    ⚠ Nhân viên tín dụng cần
      biết có nên tin không
        ↓
    "Mạng nơ-ron nói vậy"
    ⚠ KHÔNG phải câu trả lời
      chấp nhận được
        ↓
    → cần biết YẾU TỐ NÀO
      đã dẫn tới quyết định

⚠ Ba việc mà giải thích được mở ra:

⚠ HIỂU
    → yếu tố nào ảnh hưởng nhiều nhất

⚠ TIN
    → mô hình dựa vào lý do HỢP LÝ
      hay dựa vào tương quan giả

⚠ QUẢN LÝ
    → phát hiện thiên vị, sửa dữ liệu,
      biết khi nào KHÔNG nên dùng

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

"Bán mô hình được GIÁ CAO hơn"
    → ⚠ không phải mục đích

"Chạy NHANH hơn trên phần cứng yếu"
    → ⚠ đó là tối ưu hoá / lượng tử hoá

"Mô hình TỰ SỬA lỗi trong mã của nó"
    → ⚠ không có chuyện đó

Nhất quán với #13480 và #13488 (cùng lô) về Responsible AI — cả ba cùng đặt con người ở trung tâm.

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

• C (chạy nhanh hơn trên phần cứng yếu) — phương án gần nhất vì cũng là một thuộc tính đáng mong muốn của mô hình, nhưng đó là hiệu năng, không liên quan tới khả năng giải thích.

• A (bán được giá cao) — không phải mục đích của explainability.

• D (tự sửa lỗi mã) — không phải điều mô hình học máy làm được.

Ghi nhớ

⚠ Bảy nguyên tắc AI của Google — nên nhớ: | Nguyên tắc | Nội dung | |---|---| | Có ích cho xã hội | | | ⚠ Tránh tạo hoặc củng cố THIÊN VỊ | ⚠ fairness | | Xây dựng và kiểm thử về an toàn | | | ⚠ CHỊU TRÁCH NHIỆM trước con người | ⚠ accountability | | Tôn trọng quyền riêng tư | | | Giữ chuẩn mực khoa học cao | | | Chỉ dùng cho mục đích phù hợp | |

Từ khoá nhận diện:

"hiểu vì sao mô hình quyết định thế" → ⚠ explainability "đối xử công bằng giữa các nhóm" → fairness / bias "con người vẫn quyết định cuối cùng" → ⚠ human-in-the-loop "biết dữ liệu nào đã huấn luyện" → transparency, model card

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có giải thích được cho khách hàng không | ⚠ thử viết ra một câu | | Mô hình dựa vào yếu tố nào nhiều nhất | ⚠ feature attribution có thể lộ ra thứ vô lý | | Có nhóm nào bị đối xử khác không | ⚠ đo chỉ số theo từng nhóm |

Và một điều mà feature attribution hay phơi bày ra một cách khó chịu: mô hình đang dựa vào một yếu tố chẳng liên quan gì tới bài toán — mã bưu chính thay cho khả năng trả nợ, hay một dấu vết kỹ thuật trong dữ liệu huấn luyện. Nếu không mở ra xem, mô hình vẫn cho ra con số chính xác trên tập kiểm thử và không ai biết nó sai vì lý do gì.

Đáp án

B — Bằng cách tích hợp năng lực học máy thẳng vào các công cụ như BigQuery và cung cấp các API đã huấn luyện sẵn.

Vì sao đúng

"Trí tuệ nhúng sẵn" nghĩa là không cần trở thành chuyên gia AI để dùng được AI — Google đặt sẵn nó bên trong sản phẩm bạn đang dùng.

⚠ Hai đường nhúng trí tuệ:

⚠ ML NGAY TRONG CÔNG CỤ SẴN CÓ
    → BigQuery ML: `CREATE MODEL`
      ⚠ bằng SQL, dữ liệu ở nguyên chỗ
    → Looker: phân tích tăng cường
    → Google Workspace: gợi ý viết

⚠ API ĐÃ HUẤN LUYỆN SẴN
    → Vision, Speech, Translation,
      Natural Language, Document AI
    → ⚠ gọi một lời gọi là có kết quả
    → không cần dữ liệu huấn luyện

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

"Chỉ cung cấp MÁY ẢO cơ bản,
 không có dịch vụ nào thêm"
    → ⚠ đó là IaaS thuần, ngược
      hoàn toàn với ý "nhúng trí tuệ"

"Làm MỌI dịch vụ THỦ CÔNG để
 người dùng học hỏi"
    → ⚠ vô lý

"BẮT mọi người dùng phải là
 nhà khoa học dữ liệu có chứng chỉ"
    → ⚠ ngược hẳn với mục tiêu
      DÂN CHỦ HOÁ AI

Nhất quán với #13497 (cùng lô) về ba nấc AI, và #13284 (lô 139) về BigQuery ML.

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

• A (chỉ có máy ảo cơ bản) — phương án gần nhất về mặt "cũng mô tả một mô hình đám mây", nhưng đó là IaaS thuần và không có trí tuệ nào được nhúng.

• C (làm mọi thứ thủ công) và D (bắt phải là nhà khoa học dữ liệu) — đều đi ngược mục tiêu đưa AI tới mọi người.

Ghi nhớ

⚠ Trí tuệ nhúng ở đâu — bảng nên thuộc: | Sản phẩm | Trí tuệ nhúng | |---|---| | ⚠ BigQuery ML | ⚠ huấn luyện mô hình BẰNG SQL | | Looker | phân tích tăng cường, tóm tắt | | Vision / Speech / Translation | ⚠ API dựng sẵn, gọi là dùng | | Document AI | trích trường từ hoá đơn, hợp đồng | | Contact Center AI | tổng đài thông minh | | Recommendations AI | gợi ý sản phẩm | | Vertex AI | ⚠ nền tảng đầy đủ cho đội ML |

Từ khoá nhận diện:

"biết SQL, dữ liệu đã ở BigQuery" → ⚠ BigQuery ML "tác vụ phổ quát, cần ngay" → API dựng sẵn "nhãn riêng, không có kỹ sư ML" → AutoML "toàn quyền kiến trúc" → huấn luyện tuỳ biến

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Dữ liệu đang ở đâu | BigQuery → BigQuery ML | | Đội có kỹ năng gì | SQL → BigQuery ML; không gì → API dựng sẵn | | Bài toán có phổ quát không | có → API dựng sẵn |

Và cách nhanh nhất để một đội phân tích thử sức với học máy mà không cần tuyển ai: viết một câu CREATE MODEL trên chính bảng dữ liệu họ đang dùng hằng ngày. Nếu kết quả có ích, lúc đó mới bàn tới việc đầu tư sâu hơn — còn nếu không, chi phí bỏ ra chỉ là vài truy vấn.

Đáp án

B — Retire (loại bỏ).

Vì sao đúng

Ứng dụng không còn ai dùng và không mang lại giá trị nghiệp vụ thì việc đúng là tắt hẳn — không di chuyển gì cả.

⚠ Vì sao đây là chiến lược có lãi nhất:

Di chuyển ứng dụng chết
        ↓
    ⚠ trả tiền hạ tầng
    ⚠ trả công kiểm thử
    ⚠ trả công vận hành và vá lỗi
    ⚠ mang theo rủi ro bảo mật
        ↓
    ⚠ để phục vụ KHÔNG AI
        ↓
    → RETIRE: chi phí về 0,
      ⚠ rủi ro cũng về 0

⚠ Quy trình retire an toàn:

1. Xác nhận THẬT SỰ không ai dùng
   → ⚠ xem log truy cập vài tháng
        ↓
2. Hỏi bên nghiệp vụ, tìm chủ sở hữu
        ↓
3. ⚠ SAO LƯU dữ liệu và ARCHIVE
   → nghĩa vụ lưu trữ theo luật
        ↓
4. TẮT nhưng chưa xoá — chờ vài tuần
   → ⚠ xem có ai kêu không
        ↓
5. Xoá hẳn, ghi lại quyết định

Đối chiếu với #13297/#13385/#13456 (Replatform), #13280/#13370 (Rehost), #13373 (Refactor) — cả nhóm cùng một khung "6 R", mỗi đề khoá một chữ R khác nhau tuỳ mức thay đổi và giá trị của ứng dụng. Hoàn toàn nhất quán.

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

• C (Rehost) — phương án gần nhất về mặt "chi phí thấp nhất trong các cách DI CHUYỂN", nhưng vẫn là di chuyển một thứ không ai cần.

• A (Replatform) — bỏ công tối ưu cho ứng dụng vô giá trị.

• D (Refactor) — tốn kém nhất, hoàn toàn lãng phí ở đây.

Ghi nhớ

⚠ Sáu chữ R của di chuyển — bảng phải thuộc: | Chữ R | Nghĩa | Khi nào | |---|---|---| | ⚠ Retire | ⚠ BỎ HẲN | ⚠ không còn giá trị — đề này | | Retain | giữ lại tại chỗ | ⚠ chưa sẵn sàng, hoặc luật cấm | | Rehost | ⚠ lift and shift | nhanh nhất, ít đổi nhất | | Replatform | ⚠ đổi nhỏ, ví dụ sang CSDL có quản lý | cân bằng | | Refactor | ⚠ viết lại theo kiến trúc đám mây | giá trị cao, đáng đầu tư | | Repurchase | ⚠ bỏ, mua SaaS thay thế | có sẵn sản phẩm thương mại |

Từ khoá nhận diện:

"không ai dùng, không giá trị" → ⚠ Retire "chưa sẵn sàng, luật buộc ở lại" → Retain "nhanh nhất, ít rủi ro nhất" → Rehost "đổi sang dịch vụ có quản lý" → Replatform "tận dụng tối đa đám mây" → Refactor "thay bằng SaaS mua sẵn" → ⚠ Repurchase

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thật sự không ai dùng chứ | ⚠ log truy cập 3–6 tháng | | Có hệ thống nào gọi vào không | ⚠ log mạng, không chỉ log người dùng | | Dữ liệu cần giữ bao lâu | ⚠ hỏi bộ phận pháp chế, archive vào Coldline |

Và chiến lược rẻ nhất trong cả sáu chữ R vẫn thường là chữ bị bỏ qua đầu tiên: mỗi ứng dụng gỡ bỏ được là một khoản chi phí, một bề mặt tấn công và một gánh nặng vận hành biến mất vĩnh viễn — thành quả mà không một lần tối ưu hạ tầng nào sánh được.

Đáp án

B — BigQuery ML.

Vì sao đúng

Ba dữ kiện của đề chỉ thẳng vào một đáp án: dữ liệu đã nằm trong BigQuery, người dùng giỏi SQL, không biết Python.

⚠ Ba dữ kiện khớp hoàn hảo:

"Dữ liệu trong MỘT BẢNG BigQuery"
    → ⚠ BigQuery ML huấn luyện
      NGAY TẠI CHỖ, không di chuyển

"Thạo SQL"
    → ⚠ `CREATE MODEL` là SQL

"KHÔNG biết Python"
    → ⚠ loại bỏ Vertex AI custom training

⚠ Trông như thế nào:

CREATE MODEL `ds.mua_hang`
OPTIONS(model_type='logistic_reg',
        input_label_cols=['da_mua'])
AS SELECT * FROM `ds.khach_hang`;

SELECT * FROM ML.PREDICT(
  MODEL `ds.mua_hang`,
  TABLE `ds.khach_moi`);

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

"AutoML Vision"
    → ⚠ dành cho ẢNH, đây là
      dữ liệu BẢNG

"Speech-to-Text API"
    → ⚠ dành cho ÂM THANH

"Vertex AI custom training"
    → ⚠ đòi viết mã Python —
      đúng thứ đề nói là KHÔNG CÓ

Nhất quán với #13284 (lô 139) — cùng tình huống "đội biết SQL, dữ liệu ở BigQuery", cùng khoá BigQuery ML. Đối chiếu #13497 (cùng lô) khoá AutoML vì đề đó không nói tới SQL hay BigQuery. Không mâu thuẫn — dữ kiện khác nhau.

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

• D (Vertex AI custom training) — phương án gần nhất vì cũng dựng được mô hình dự đoán mua hàng, nhưng đòi kỹ năng lập trình mà đề nói rõ là không có.

• A (AutoML Vision) — dành cho ảnh.

• C (Speech-to-Text) — dành cho âm thanh.

Ghi nhớ

⚠ Chọn công cụ ML theo KỸ NĂNG và NƠI CHỨA DỮ LIỆU: | Tình huống | Công cụ | |---|---| | ⚠ Biết SQL, dữ liệu ở BigQuery | ⚠ BigQuery ML | | Không biết lập trình, có dữ liệu gán nhãn | ⚠ AutoML (Vertex AI) | | Tác vụ phổ quát, cần ngay | API dựng sẵn | | Có kỹ sư ML, cần toàn quyền | Vertex AI custom training |

Từ khoá nhận diện:

"thạo SQL, không biết Python" → ⚠ BigQuery ML "dữ liệu đã ở BigQuery" → BigQuery ML "dữ liệu ảnh, nhãn riêng" → AutoML Vision "kiểm soát kiến trúc mô hình" → custom training

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao | |---|---| | Chỉ số đánh giá là bao nhiêu | ⚠ xem AUC / precision / recall, không chỉ accuracy | | Có cột nào lộ đáp án không | ⚠ ví dụ "ngày giao hàng" | | Chi phí huấn luyện | ⚠ tính theo byte quét như truy vấn thường |

Và cái bẫy quen thuộc nhất với bài toán dự đoán mua hàng: một cột trong bảng vô tình chứa sẵn câu trả lời. Mô hình sẽ đạt độ chính xác gần như hoàn hảo khi kiểm thử, rồi dự đoán vô dụng khi chạy thật — vì lúc cần dự đoán, cột đó chưa tồn tại.