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

Đáp án

D — Dùng một BigQuery remote function gọi tới Natural Language API.

Vì sao đúng

Đề đòi xử lý văn bản tự do NGAY TRONG BigQuery, và remote function là cơ chế cho phép SQL gọi ra dịch vụ bên ngoài.

⚠ Remote function hoạt động thế nào:

Truy vấn SQL trong BigQuery
        ↓
    ⚠ Gọi remote function
        ↓
    Cloud Run / Cloud Run Functions
        ↓
    Gọi Natural Language API
        ↓
    Trả kết quả về
        ↓
    ⚠ Kết quả nằm ngay trong
      bảng kết quả truy vấn

⚠ Vì sao "ngay trong BigQuery" quan trọng:

Cách thủ công
    → xuất dữ liệu ra
    → chạy script bên ngoài
    → nạp kết quả về
        ↓
    ⚠ Ba bước, ba chỗ có thể hỏng
    ⚠ Dữ liệu rời khỏi kho

Remote function
    → ⚠ MỘT câu SQL
    ⚠ Dữ liệu không rời BigQuery
      (ngoài lời gọi API)
    ⚠ Kết hợp được với JOIN,
      GROUP BY như cột bình thường

⚠ Lựa chọn hiện đại hơn — gọi Gemini bằng SQL:

SELECT
  comment,
  ml_generate_text_result
FROM ML.GENERATE_TEXT(
  MODEL `du_an.gemini_model`,
  (SELECT comment,
     CONCAT('Trích xuất chủ đề chính: ',
            comment) AS prompt
   FROM `du_an.binh_luan`)
);

        ↓
    ⚠ `ML.GENERATE_TEXT` gọi Gemini
      NGAY TRONG SQL
    ⚠ Không cần dựng remote function
    → cách làm được ưa dùng hiện nay

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

XUẤT SANG CLOUD SQL rồi xử lý
    → ⚠ Cloud SQL KHÔNG có khả năng
      phân tích ngôn ngữ tự nhiên
    → và đưa dữ liệu ra ngoài kho

DÙNG VISION AI API
    → ⚠ xử lý ẢNH, không phải
      văn bản

ĐỌC TAY từng bình luận
    → ⚠ không mở rộng được với
      "tập dữ liệu LỚN"

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

• A (xuất sang Cloud SQL để xử lý) — phương án gần nhất về mặt "cũng là một quy trình kỹ thuật", nhưng Cloud SQL là CSDL quan hệ, không có khả năng phân tích ngôn ngữ tự nhiên; và nó đưa dữ liệu ra khỏi kho, trái yêu cầu "ngay trong BigQuery".

• B (dùng Vision AI API) — xử lý ảnh, sai loại dữ liệu.

• C (đọc tay từng bình luận) — không khả thi với tập dữ liệu lớn.

Ghi nhớ

⚠ Các cách mở rộng BigQuery bằng AI — bảng nên thuộc: | Cách | Nội dung | |---|---| | ⚠ Remote function | ⚠ SQL gọi Cloud Run → API bất kỳ | | ⚠ ML.GENERATE_TEXT | ⚠ gọi Gemini ngay trong SQL | | ML.PREDICT | mô hình BigQuery ML | | REMOTE MODEL | gọi endpoint Vertex AI | | UDF (JavaScript) | logic đơn giản, chạy trong BigQuery | | Dataflow | xử lý ngoài rồi ghi về |

Từ khoá nhận diện:

"phân tích văn bản ngay trong BigQuery" → remote function hoặc ML.GENERATE_TEXT "trích xuất thực thể, cảm xúc" → Natural Language API "xử lý ngoài rồi ghi về" → Dataflow "dữ liệu bảng biểu" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí mỗi lần chạy | ⚠ số dòng × giá API + Cloud Run | | Có gọi lại dòng cũ không | chỉ xử lý dòng mới | | Kết quả có đúng không | ⚠ đối chiếu 50 mẫu với người đọc |

Và một mẫu thiết kế quan trọng khi kết hợp SQL với AI: lưu kết quả phân tích vào một bảng, đừng gọi API mỗi lần truy vấn. Một dashboard được mở hàng trăm lần mỗi ngày mà mỗi lần lại gọi lại Natural Language API cho cùng những bình luận cũ là cách nhanh nhất biến một tính năng hữu ích thành một khoản chi bất ngờ.

Đáp án

B — Triển khai các instance máy ảo trên NHIỀU ZONE trong CÙNG MỘT vùng.

Vì sao đúng

Đề nói rõ mục tiêu là chịu được sự cố mất hoàn toàn MỘT ZONE — và đa zone là biện pháp đúng tầm cho mức sự cố đó.

⚠ Zone là gì:

    REGION (ví dụ asia-southeast1)
       ├── zone a   ⚠ điện riêng
       ├── zone b   ⚠ mạng riêng
       └── zone c   ⚠ làm mát riêng
        ↓
    ⚠ Mỗi zone là hạ tầng ĐỘC LẬP
        ↓
    Một zone chết → hai zone kia
    vẫn phục vụ

⚠ Cách triển khai đúng:

REGIONAL MANAGED INSTANCE GROUP
    → ⚠ tự trải VM đều qua các zone
        ↓
LOAD BALANCER
    → ⚠ tự ngừng gửi lưu lượng
      vào zone hỏng
        ↓
CLOUD SQL với cấu hình HA
    → ⚠ primary và standby ở
      hai zone khác nhau
        ↓
    → cả tầng ứng dụng lẫn tầng
      dữ liệu đều chịu được

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

"MỘT máy ảo RẤT MẠNH trong MỘT zone"
    → ⚠ vẫn là MỘT điểm hỏng
    → máy to hơn không bất tử hơn

"PREEMPTIBLE VM cho thành phần
 QUAN TRỌNG NHẤT"
    → ⚠ bị THU HỒI bất cứ lúc nào
    → làm GIẢM độ tin cậy

"Tất cả ở MỘT trung tâm dữ liệu
 TẠI CHỖ"
    → ⚠ ngược hoàn toàn mục tiêu

⚠ Gần trùng với #13282 (lô 139) — đề đó cũng hỏi cách chịu được mất một trung tâm dữ liệu mà tiết kiệm nhất, và cùng khoá đa zone. Nhất quán.

⚠ Đối chiếu #13247 (lô 138) — đề đó khoá ĐA VÙNG vì yêu cầu là sống sót khi mất CẢ MỘT REGION. Không mâu thuẫn — khác nhau ở cấp độ sự cố cần chống.

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

• A (một máy ảo rất mạnh trong một zone) — phương án gần nhất về mặt "cũng là một cách tăng năng lực", nhưng hiểu sai về độ tin cậy: dư thừa mới chống được lỗi, không phải kích thước.

• C (dùng preemptible VM cho thành phần quan trọng nhất) — Spot/preemptible bị thu hồi bất cứ lúc nào; dùng cho tải chịu được gián đoạn, không phải cho thành phần quan trọng.

• D (tất cả ở một trung tâm dữ liệu tại chỗ) — ngược hoàn toàn mục tiêu.

Ghi nhớ

⚠ Ba cấp triển khai — bảng phải thuộc: | Cấp | Chống được | Chi phí | |---|---|---| | Zonal | ⚠ không gì cả | thấp nhất | | ⚠ Regional (đa zone) | ⚠ mất MỘT ZONE | trung bình | | Multi-region | mất CẢ MỘT REGION | cao nhất |

Từ khoá nhận diện:

"mất một zone / một trung tâm dữ liệu" → đa zone trong một vùng "mất cả vùng, thảm hoạ khu vực" → đa vùng "tiết kiệm nhất mà vẫn chịu lỗi" → ⚠ thường là đa zone "lỗi con người, xoá nhầm" → ⚠ backup và PITR — đa zone KHÔNG cứu được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thành phần nào chỉ ở một zone không | ⚠ rà từng tài nguyên | | MIG là regional hay zonal | gcloud compute instance-groups list | | Có chịu được thật không | ⚠ diễn tập tắt một zone |

Và một điều luôn đúng với mọi kiến trúc dự phòng: nó chỉ có giá trị nếu đã được diễn tập. Một cụm đa zone chưa bao giờ bị thử tắt một zone chỉ là một giả thiết — và ngày sự cố thật là ngày tệ nhất để phát hiện ra rằng cơ sở dữ liệu vẫn đang nằm gọn trong một zone duy nhất.

Đáp án

B — Cloud Logging và Cloud Monitoring.

Vì sao đúng

Đề đòi hai việc, và mỗi việc thuộc về một dịch vụ trong bộ Cloud Operations.

⚠ Hai việc, hai dịch vụ:

1. "tìm THỜI ĐIỂM CHÍNH XÁC
    của lần triển khai"
     → ⚠ CLOUD LOGGING
     → Audit Logs ghi lại mọi
       thay đổi tài nguyên
     → biết ai triển khai, lúc nào

2. "xem LOG LỖI do ứng dụng sinh ra
    tại đúng thời điểm đó"
     → ⚠ CLOUD LOGGING cho nội dung lỗi
     → ⚠ CLOUD MONITORING cho biểu đồ
       chỉ số quanh thời điểm đó

⚠ Ranh giới giữa hai dịch vụ:

CLOUD MONITORING
    → ⚠ SỐ theo thời gian
    → biểu đồ, dashboard, cảnh báo
    → ⚠ "CÓ CHUYỆN GÌ đang xảy ra?"
    → thấy tỉ lệ lỗi TĂNG VỌT lúc 14:32

CLOUD LOGGING
    → ⚠ SỰ KIỆN dạng văn bản
    → tra cứu, lọc, phân tích
    → ⚠ "VÌ SAO nó xảy ra?"
    → thấy dòng lỗi cụ thể lúc 14:32

⚠ Cuộc điều tra thực tế:

Monitoring: tỉ lệ lỗi tăng từ 14:32
        ↓
Audit Log: phiên bản mới được
           triển khai lúc 14:31
        ↓
    ⚠ Tương quan thời gian rất rõ
        ↓
Application Log: lọc `severity>=ERROR`
                 quanh 14:32
        ↓
    Thấy `NullPointerException`
    trong mã mới
        ↓
    → quay lui và sửa

Nhất quán với #13150 (lô 138) — câu đó cũng khoá Monitoring để phát hiện, Logging để điều tra. Và với #13409 (lô 141) về giá trị của giám sát. Cả ba nhất quán.

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

• C (Cloud Deployment Manager và Cloud DNS) — phương án gần nhất về mặt "có nhắc tới triển khai": Deployment Manager là công cụ hạ tầng dưới dạng mã (nay chủ yếu dùng Terraform), không phải nơi tra cứu log. Cloud DNS thì không liên quan.

• A (Cloud Billing và Cloud Storage) — chi phí và lưu trữ tệp; không liên quan tới điều tra sự cố.

• D (Cloud Armor và Cloud IAM) — bảo mật vành đai và phân quyền; không phải công cụ quan sát.

Ghi nhớ

⚠ Bộ Cloud Operations — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | ⚠ Cloud Monitoring | ⚠ metric, dashboard, cảnh báo, SLO | | ⚠ Cloud Logging | ⚠ thu thập và TRA CỨU log | | Cloud Trace | ⚠ theo dấu độ trễ qua nhiều dịch vụ | | Cloud Profiler | CPU và bộ nhớ trong ứng dụng | | Error Reporting | ⚠ gom lỗi giống nhau thành nhóm |

Từ khoá nhận diện:

"tìm thông báo lỗi cụ thể" → Cloud Logging "biểu đồ, cảnh báo vượt ngưỡng" → Cloud Monitoring "ai đã thay đổi cái gì" → ⚠ Cloud Audit Logs "request chậm ở dịch vụ nào" → Cloud Trace

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sự cố bắt đầu lúc nào | Monitoring — kéo khung thời gian rộng | | Có thay đổi gì trước đó không | ⚠ Audit Logs — nguyên nhân phổ biến nhất | | Lỗi cụ thể là gì | Logs Explorer, severity>=ERROR |

Và một câu hỏi nên đặt đầu tiên trong mọi cuộc điều tra sự cố: "gần đây có ai thay đổi gì không?". Phần lớn sự cố sản xuất bắt nguồn từ một thay đổi vừa được triển khai, và Audit Logs trả lời câu đó nhanh hơn nhiều so với việc đọc mã.

Đáp án

C — Quản trị viên và những người liên quan được chỉ định sẽ nhận email thông báo.

Vì sao đúng

Đây là hiểu lầm phổ biến nhất về ngân sách Cloud Billing: nó chỉ cảnh báo, không hành động.

⚠ Điều gì THỰC SỰ xảy ra:

Chi tiêu chạm 5.000 USD
        ↓
    ⚠ Email gửi tới người quản lý
      thanh toán và những người
      được chỉ định
        ↓
    ⚠ Dịch vụ VẪN CHẠY BÌNH THƯỜNG
    ⚠ Tiền VẪN tiếp tục phát sinh
        ↓
    → ngân sách là ĐÈN BÁO,
      không phải CẦU DAO

⚠ Vì sao Google thiết kế như vậy:

Tự động tắt tài nguyên khi
chạm ngân sách
        ↓
    ⚠ Sẽ làm SẬP hệ thống sản xuất
    ⚠ Có thể MẤT dữ liệu
    ⚠ Thiệt hại lớn hơn nhiều
      so với vượt ngân sách
        ↓
    → mặc định an toàn là
      BÁO cho con người quyết định

⚠ Muốn thật sự chặn thì phải tự dựng:

Budget alert → Pub/Sub
        ↓
    Cloud Function
        ↓
    ⚠ Gỡ liên kết tài khoản thanh toán
      hoặc tắt tài nguyên cụ thể
        ↓
    ⚠ CỰC KỲ RỦI RO:
      gỡ billing = MỌI dịch vụ DỪNG
    ⚠ Chỉ dùng cho môi trường
      học tập hoặc thử nghiệm
    ⚠ KHÔNG dùng cho production

Nhất quán với #13345 (lô 140) và #13255 (lô 138) — cả hai đều nhấn mạnh ngân sách chỉ cảnh báo. Và đối chiếu #13294 (lô 139) — nơi yêu cầu CHẶN CỨNG thì đáp án là quota, không phải ngân sách. Cả bốn nhất quán.

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

• A (mọi tài nguyên tự động tắt để ngăn chi tiêu) — phương án gần nhất và là hiểu lầm phổ biến nhất. Nếu đúng vậy thì một ngân sách đặt sai sẽ làm sập hệ thống sản xuất của bạn.

• D (tự động cộng tín dụng 5.000 USD vào hoá đơn sau) — không có cơ chế nào như vậy.

• B (Google Cloud tự liên hệ để đề nghị giảm giá) — không phải cách hoạt động của ngân sách.

Ghi nhớ

⚠ Bốn cơ chế kiểm soát — bảng phải thuộc: | Cơ chế | Tác dụng | |---|---| | ⚠ Budget alert | ⚠ CHỈ CẢNH BÁO — không chặn gì | | ⚠ Quota | ⚠ CHẶN CỨNG số lượng tài nguyên | | Organization Policy | cấm loại hành vi, kể cả Owner | | IAM | ai được làm gì |

Từ khoá nhận diện:

"báo cho tôi khi tới X%" → budget alert "không cho tạo quá N máy" → ⚠ quota "cấm dùng dịch vụ nào đó" → Organization Policy "tự động dừng chi tiêu" → ⚠ KHÔNG có sẵn — phải tự dựng, rất rủi ro

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cảnh báo có tới đúng người không | ⚠ thử hạ ngưỡng xuống rất thấp | | Có ai đang trông chừng hoá đơn không | | | Có rào chắn cứng nào chưa | ⚠ quota, max-instances |

Và điều quan trọng nhất phải nhớ về ngân sách Cloud Billing: nó cho bạn biết, không giữ giúp bạn. Muốn thật sự chặn thì công cụ là quota và max-instances — còn ngân sách chỉ hữu ích khi có người thật sự đọc email cảnh báo và hành động.

Đáp án

D — TensorFlow.

Vì sao đúng

Đề mô tả ba đặc điểm, và cả ba đều chỉ TensorFlow:

⚠ Ba đặc điểm ↔ TensorFlow:

1. "NỀN TẢNG MÃ NGUỒN MỞ đầu-cuối
    để xây và huấn luyện mô hình ML"
     → ⚠ Google tạo ra rồi mở mã

2. "công cụ, thư viện và cộng đồng lớn"
     → hệ sinh thái rất rộng

3. ⚠ "PHẦN CỨNG TỐI ƯU đi kèm là
    Cloud TPU"
     → ⚠ TPU được thiết kế RIÊNG
       cho TensorFlow

⚠ TensorFlow và TPU — cặp đôi:

TENSORFLOW
    → khung phần mềm mô tả
      mạng nơ-ron
        ↓
    Phép tính chủ yếu:
    ⚠ NHÂN MA TRẬN khổng lồ
        ↓
CLOUD TPU
    → ⚠ ASIC do Google thiết kế
      CHUYÊN cho nhân ma trận
    → systolic array
        ↓
    ⚠ Phần mềm và phần cứng
      được thiết kế CÙNG NHAU

⚠ Hệ sinh thái TensorFlow:

Keras          → API cấp cao, dễ dùng
TF Lite        → ⚠ chạy trên di động
                 và thiết bị nhúng
TF.js          → chạy trong trình duyệt
TFX            → ⚠ đường ống ML sản xuất
TensorBoard    → trực quan hoá huấn luyện
TF Hub         → mô hình dùng lại
        ↓
    ⚠ Chạy được ở mọi nơi, không
      chỉ trên Google Cloud

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

APIGEE
    → ⚠ quản lý API, không liên
      quan tới ML

BIGQUERY
    → kho dữ liệu; ⚠ có BigQuery ML
      nhưng KHÔNG phải nền tảng
      mã nguồn mở, không đi với TPU

LOOKER
    → ⚠ công cụ BI

Nhất quán với #13302 (lô 139) — câu đó về TPU là phần cứng độc quyền tối ưu cho TensorFlow. Câu này hỏi phần mềm trong cặp đôi đó. Hai câu bổ sung nhau.

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

• B (BigQuery) — phương án gần nhất về mặt "cũng liên quan tới ML" nhờ BigQuery ML. Nhưng BigQuery không phải nền tảng mã nguồn mở, và không phải thứ TPU được thiết kế cho.

• A (Apigee) — quản lý API.

• C (Looker) — nền tảng BI.

Ghi nhớ

⚠ Công nghệ mở do Google khởi xướng — bảng nên thuộc: | Công nghệ | Việc | |---|---| | ⚠ TensorFlow | ⚠ học máy — đi cùng TPU | | Kubernetes | điều phối container | | Apache Beam | ⚠ mô hình của Dataflow | | Knative | nền tảng của Cloud Run | | Istio | service mesh | | JAX | ⚠ khung ML mới hơn, cũng chạy trên TPU |

Từ khoá nhận diện:

"mã nguồn mở, xây và huấn luyện mô hình, TPU" → TensorFlow "phần cứng độc quyền của Google cho ML" → TPU "nền tảng MLOps hợp nhất" → Vertex AI "ML bằng SQL trong kho" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần viết mô hình riêng không | ⚠ thử API sẵn và AutoML trước | | Nút thắt nằm ở đâu | profiler — thường là nạp dữ liệu, không phải chip | | Chi phí huấn luyện bao nhiêu | so GPU và TPU trên cùng bài toán |

Và một điều đáng nhớ về cặp TensorFlow – TPU: đó là ví dụ điển hình của việc thiết kế phần mềm và phần cứng cùng nhau. Google viết khung phần mềm, rồi thiết kế con chip riêng cho đúng phép tính mà khung đó thực hiện nhiều nhất — và đó là lý do TPU nhanh hơn nhiều so với phần cứng đa dụng cho cùng khối lượng công việc.

Đáp án

A — Một API (Application Programming Interface).

Vì sao đúng

Đề nêu ba yêu cầu, và API là cơ chế tích hợp duy nhất đáp ứng cả ba:

⚠ Ba yêu cầu ↔ API:

1. ⚠ "KHÔNG cho đối tác truy cập
    TRỰC TIẾP vào CSDL"
     → cần lớp trung gian

2. "AN TOÀN, ỔN ĐỊNH"
     → xác thực, hạn ngạch,
       hợp đồng không đổi

3. "CÓ TÀI LIỆU TỐT"
     → đặc tả OpenAPI, cổng
       lập trình viên

⚠ Vì sao không cho truy cập CSDL trực tiếp:

Đối tác kết nối thẳng vào CSDL
        ↓
    ⚠ Thấy TOÀN BỘ schema,
      kể cả bảng không liên quan
    ⚠ Đổi schema là làm GÃY
      tích hợp của mọi đối tác
    ⚠ Không giới hạn được tốc độ
      truy vấn → một đối tác có thể
      làm chậm cả hệ thống
    ⚠ Rất khó phân quyền chi tiết
        ↓
API ở giữa
        ↓
    ⚠ Che kiến trúc bên trong
    ⚠ Hợp đồng ỔN ĐỊNH hơn CSDL
    ⚠ Xác thực và hạn ngạch
      theo từng đối tác

⚠ Vì sao ba phương án kia kém hơn:

XUẤT DỮ LIỆU HẰNG ĐÊM RA
CLOUD STORAGE
    → ⚠ dữ liệu CŨ tới một ngày
    → tồn kho thay đổi liên tục
      → thông tin sai

ĐƯỜNG KẾT NỐI MẠNG RIÊNG
tới trung tâm dữ liệu
    → ⚠ chỉ là đường truyền
    → ⚠ KHÔNG giải quyết chuyện
      phân quyền và hợp đồng dữ liệu

MÁY ẢO CÓ QUYỀN TRUY CẬP CSDL
    → ⚠ vẫn là truy cập trực tiếp,
      chỉ thêm một chặng

Liên quan #13269, #13304 (lô 139) và #13348 (lô 140) — các câu đó về Apigee để quản lý API cho đối tác. Câu này ở mức khái niệm: xây API là đúng cách tích hợp; Apigee là công cụ quản lý nó.

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

• C (xuất dữ liệu hằng đêm ra Cloud Storage) — phương án gần nhất và dùng được cho dữ liệu ít thay đổi. Nhưng tồn kho thay đổi liên tục, nên dữ liệu cũ một ngày là thông tin sai — đối tác sẽ bán hàng đã hết.

• B (đường kết nối mạng riêng) — chỉ là đường truyền, không giải quyết phân quyền, hạn ngạch hay hợp đồng dữ liệu.

• D (máy ảo có quyền truy cập CSDL) — vẫn là truy cập trực tiếp, chỉ thêm một chặng trung gian.

Ghi nhớ

⚠ Vì sao API là cách tích hợp đúng — bảng nên thuộc: | Lợi ích | Nội dung | |---|---| | ⚠ Che kiến trúc bên trong | đổi CSDL không ảnh hưởng đối tác | | Hợp đồng ổn định | ⚠ API version bền hơn schema | | Xác thực theo đối tác | API key, OAuth | | Hạn ngạch và rate limit | ⚠ bảo vệ backend | | Ghi log và phân tích | ai gọi gì, bao nhiêu | | Tài liệu và sandbox | đối tác tự tích hợp |

Từ khoá nhận diện:

"đối tác tích hợp, không cho vào CSDL" → xây API "quản lý API trọn vòng đời, đối tác, kiếm tiền" → Apigee "API serverless nhẹ" → API Gateway "chia sẻ dữ liệu phân tích cho tổ chức khác" → ⚠ Analytics Hub

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tác mất bao lâu để gọi thành công lần đầu | ⚠ thước đo trải nghiệm | | Backend chịu nổi không | đặt rate limit TRƯỚC khi mở | | Đổi schema CSDL có làm gãy API không | ⚠ nếu có thì lớp trung gian chưa đủ dày |

Và một nguyên tắc thiết kế đáng nhớ khi mở API cho bên ngoài: hợp đồng API phải ổn định hơn hệ thống phía sau nó. Bạn sẽ đổi cơ sở dữ liệu, đổi ngôn ngữ, đổi kiến trúc nhiều lần trong vài năm tới — và mỗi lần như vậy, đối tác không được phép biết.

Đáp án

C — Classification (phân loại).

Vì sao đúng

Đầu ra của bài toán là một NHÃN RỜI RẠC — khách hàng sẽ huỷ hay sẽ ở lại — nên đây là bài toán phân loại.

⚠ Ba manh mối ↔ classification:

1. ⚠ "NHÃN cho biết mỗi khách hàng
    CUỐI CÙNG ĐÃ HUỶ hay VẪN ĐĂNG KÝ"
     → ⚠ có NHÃN → học có giám sát
     → ⚠ nhãn là NHỊ PHÂN

2. "xác định khách có NGUY CƠ CAO
    huỷ trong 30 ngày tới"
     → dự đoán thuộc nhóm nào

3. Đầu ra dùng để làm gì
     → ⚠ chọn ra nhóm cần chăm sóc

⚠ Phân biệt bốn loại bài toán:

CLASSIFICATION
    → ⚠ đầu ra là NHÃN RỜI RẠC
    → huỷ / không huỷ
    → ⚠ đề này

REGRESSION
    → ⚠ đầu ra là SỐ LIÊN TỤC
    → giá nhà, doanh thu

CLUSTERING
    → ⚠ KHÔNG có nhãn
    → tự tìm nhóm tự nhiên

ANOMALY DETECTION
    → tìm điểm bất thường

⚠ Phép thử nhanh:

Câu hỏi: "Đầu ra là gì?"
        ↓
    Một trong vài LỰA CHỌN cho sẵn
        → ⚠ CLASSIFICATION

    Một SỐ bất kỳ trong một khoảng
        → ⚠ REGRESSION

    Không có nhãn, chỉ muốn tìm nhóm
        → ⚠ CLUSTERING

⚠ Thực tế mô hình trả về gì:

Không chỉ "huỷ" hay "không"
        ↓
    ⚠ Trả về XÁC SUẤT: 0,87
        ↓
    Đội nghiệp vụ đặt NGƯỠNG
        ↓
    ⚠ > 0,8 → gửi ưu đãi lớn
    ⚠ 0,5–0,8 → gửi ưu đãi nhỏ
    ⚠ < 0,5 → không làm gì
        ↓
    → ngưỡng là quyết định
      NGHIỆP VỤ, không phải kỹ thuật

⚠ Đối chiếu #13406 (lô 141) — đề đó khoá REGRESSION vì đầu ra là giá nhà, một số liên tục. Câu này khoá CLASSIFICATION vì đầu ra là nhãn huỷ/không huỷ. Không mâu thuẫn — khác nhau ở kiểu đầu ra.

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

• B (Clustering) — phương án gần nhất nếu bài toán là phân khúc khách hàng, nhưng clustering không có nhãn. Ở đây có sẵn nhãn "đã huỷ / vẫn đăng ký", nên đây là học có giám sát.

• A (Regression) — đầu ra là số liên tục; ở đây là nhãn.

• D (Anomaly detection) — tìm điểm bất thường hiếm gặp; khách rời bỏ không phải hiện tượng bất thường mà là hành vi có quy luật.

Ghi nhớ

⚠ Bốn loại bài toán ML — bảng phải thuộc: | Loại | Đầu ra | Ví dụ | |---|---|---| | ⚠ Classification | ⚠ NHÃN rời rạc | ⚠ khách rời bỏ, spam, loại sản phẩm | | Regression | SỐ liên tục | giá nhà, doanh thu | | Clustering | nhóm tự tìm | phân khúc khách hàng | | Anomaly detection | bình thường / bất thường | gian lận | | Recommendation | danh sách gợi ý | sản phẩm nên mua |

Từ khoá nhận diện:

"có huỷ hay không, thuộc nhóm nào" → classification "dự đoán một con số" → regression "tự tìm nhóm, không có nhãn" → clustering "có nhãn sẵn" → ⚠ học CÓ GIÁM SÁT

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có rò rỉ nhãn không | ⚠ rà mốc thời gian của từng đặc trưng | | Mô hình có tốt hơn quy tắc đơn giản không | so với "khách không xem 30 ngày" | | Ngưỡng đặt bao nhiêu | ⚠ theo chi phí nghiệp vụ, không theo F1 |

Và một câu hỏi phải trả lời trước khi triển khai mô hình dự đoán khách rời bỏ: ưu đãi sẽ tốn bao nhiêu, và một khách hàng đáng giá bao nhiêu? Hai con số đó quyết định ngưỡng — và không có chỉ số kỹ thuật nào thay thế được chúng.

Đáp án

A — Cloud Audit Logs.

Vì sao đúng

Cloud Audit Logs là dịch vụ tự động ghi lại ai đã làm gì, ở đâu, khi nào trên Google Cloud — bao gồm cả việc truy cập dữ liệu trong BigQuery.

⚠ Bốn loại audit log:

ADMIN ACTIVITY
    → ⚠ LUÔN bật, MIỄN PHÍ,
      KHÔNG tắt được
    → ghi mọi thay đổi cấu hình:
      tạo dataset, đổi quyền

⚠ DATA ACCESS
    → ⚠ phải BẬT, CÓ PHÍ
    → ⚠ ghi lượt ĐỌC và GHI DỮ LIỆU
    → ⚠ chính là thứ đề cần

SYSTEM EVENT
    → hành động do hệ thống thực hiện

POLICY DENIED
    → truy cập bị chính sách từ chối

⚠ Điểm mấu chốt cho yêu cầu quản trị dữ liệu:

"MỌI truy cập tới dataset nhạy cảm
 phải được GHI LẠI"
        ↓
    ⚠ Admin Activity KHÔNG đủ —
      nó chỉ ghi thay đổi cấu hình
        ↓
    ⚠ Phải BẬT Data Access log
        ↓
    Khi đó mỗi câu `SELECT` trên
    dataset đó đều được ghi lại:
      ai chạy, lúc nào, truy vấn gì

⚠ Vì sao ba phương án kia không phải:

CLOUD ARMOR
    → ⚠ chống DDoS và WAF ở biên
    → không ghi truy cập dữ liệu

CLOUD STORAGE
    → ⚠ nơi LƯU tệp
    → (có thể là ĐÍCH của log sink,
       nhưng không phải nơi TẠO log)

CLOUD DEPLOYMENT MANAGER
    → công cụ hạ tầng dưới dạng mã
    → không liên quan

Nhất quán với #13426 (cùng lô này) về Cloud Logging để điều tra, và #13276 (lô 139) — nơi auditing được nêu là cơ chế thứ ba bên cạnh xác thực và phân quyền. Cả ba nhất quán.

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

• C (Cloud Storage) — phương án gần nhất nếu hiểu nhầm "lưu log" là "tạo log": Cloud Storage có thể là đích của log sink, nhưng nó không tự ghi lại việc ai truy cập BigQuery.

• B (Cloud Armor) — bảo vệ vành đai khỏi DDoS và tấn công web.

• D (Cloud Deployment Manager) — công cụ triển khai hạ tầng.

Ghi nhớ

⚠ Bốn loại audit log — bảng phải thuộc: | Loại | Bật sẵn? | Ghi gì | |---|---|---| | Admin Activity | ⚠ LUÔN bật, miễn phí | thay đổi cấu hình và quyền | | ⚠ Data Access | ⚠ PHẢI bật, có phí | ⚠ đọc và ghi DỮ LIỆU | | System Event | luôn bật | hành động của hệ thống | | Policy Denied | luôn bật | truy cập bị từ chối |

Từ khoá nhận diện:

"ai đã truy cập dữ liệu" → ⚠ Data Access audit log "ai đã đổi cấu hình" → Admin Activity log "tìm lỗi ứng dụng" → Cloud Logging (application log) "biểu đồ và cảnh báo" → Cloud Monitoring

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Data Access log đã bật chưa | ⚠ IAM & Admin → Audit Logs | | Ai đã đọc dataset nhạy cảm | truy vấn log trong BigQuery | | Log có bị xoá được không | ⚠ kiểm quyền trên project chứa log |

Và một thiết kế nên có ngay khi bật audit log cho dữ liệu nhạy cảm: đẩy log sang một project riêng mà đội vận hành thường ngày không có quyền xoá. Nhật ký kiểm toán chỉ có giá trị khi người bị ghi lại không thể can thiệp vào chính bản ghi đó.

Đáp án

D — Speech-to-Text API.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều là năng lực chuẩn của Speech-to-Text:

⚠ Ba yêu cầu ↔ Speech-to-Text:

1. ⚠ "CHUYỂN ghi âm cuộc gọi
    thành VĂN BẢN"
     → ⚠ đúng định nghĩa
       speech-to-text

2. "nhiều ĐỊNH DẠNG: WAV, MP3, FLAC"
     → API hỗ trợ nhiều codec

3. "nhiều NGÔN NGỮ: Anh, Tây Ban Nha,
    Quan Thoại"
     → ⚠ hỗ trợ hơn 125 ngôn ngữ

⚠ Tính năng đặc biệt hữu ích cho tổng đài:

⚠ SPEAKER DIARIZATION
    → ⚠ TÁCH ai đang nói:
      nhân viên hay khách hàng
    → thiết yếu để phân tích riêng

⚠ AUTOMATIC PUNCTUATION
    → thêm dấu câu, dễ đọc

⚠ WORD-LEVEL TIMESTAMP
    → ⚠ biết mỗi từ nói ở giây nào
    → nhảy tới đúng đoạn trong file

⚠ MODEL riêng cho điện thoại
    → `phone_call` model — tối ưu
      cho chất lượng âm thanh tổng đài

⚠ SPEECH ADAPTATION
    → ⚠ tăng độ chính xác cho
      tên sản phẩm, thuật ngữ riêng

⚠ Vì sao ba API kia sai hướng:

TEXT-TO-SPEECH API
    → ⚠ chữ → GIỌNG NÓI
    → ⚠ NGƯỢC hướng hoàn toàn
    → bẫy dễ nhầm nhất

NATURAL LANGUAGE API
    → ⚠ phân tích VĂN BẢN
    → là bước SAU, không phải
      bước chuyển âm thanh

VISION AI API
    → xử lý ẢNH

Liên quan #13323 (lô 140) — câu đó về giá trị của ML với dữ liệu ghi âm cuộc gọi. Speech-to-Text là bước đầu tiên của đường ống đó. Hai câu bổ sung nhau.

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

• C (Text-to-Speech API) — phương án gần nhất và là bẫy dễ nhầm nhất vì tên gần giống, nhưng nó ngược hướng: chuyển chữ thành giọng nói.

• B (Natural Language API) — phân tích văn bản; đó là bước tiếp theo sau khi đã có bản chép lời, không phải bước chuyển âm thanh.

• A (Vision AI API) — xử lý ảnh.

Ghi nhớ

⚠ Các API AI dựng sẵn — bảng phải thuộc: | API | Việc | |---|---| | ⚠ Speech-to-Text | ⚠ giọng nói → CHỮ | | Text-to-Speech | ⚠ chữ → GIỌNG NÓI | | Natural Language | thực thể, cảm xúc, phân loại VĂN BẢN | | Translation | dịch | | Vision | ảnh | | Video Intelligence | video | | Document AI | trích xuất từ tài liệu |

Từ khoá nhận diện:

"ghi âm → văn bản, phiên âm" → Speech-to-Text "đọc văn bản thành giọng nói" → Text-to-Speech "phân tích cảm xúc bản chép lời" → Natural Language "giải pháp trọn gói cho tổng đài" → ⚠ Contact Center AI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ chính xác bản chép | ⚠ nghe lại 20 cuộc và đối chiếu | | Có tách được người nói không | bật diarization và kiểm | | Đã che PII chưa | quét bằng Sensitive Data Protection |

Và một tuỳ chọn nên bật ngay từ đầu khi xử lý ghi âm tổng đài: speaker diarization. Không có nó, bản chép là một khối văn bản không phân biệt được ai nói câu gì — và phần lớn giá trị phân tích, từ đánh giá nhân viên tới đo cảm xúc khách hàng, đều phụ thuộc vào việc tách được hai giọng nói đó.

Đáp án

A — Mô hình có thể duy trì và KHUẾCH ĐẠI những thiên lệch bất công, dẫn tới thực hành tuyển dụng phân biệt đối xử.

Vì sao đúng

Đề nêu chính xác cơ chế gây hại: mô hình được huấn luyện trên dữ liệu tuyển dụng lịch sử vốn phản ánh định kiến quá khứ.

⚠ Cơ chế khuếch đại thiên lệch:

Dữ liệu tuyển dụng quá khứ
        ↓
    ⚠ Phản ánh định kiến của
      người tuyển dụng ngày trước
        ↓
    Mô hình học: "hồ sơ như thế này
    thường được nhận"
        ↓
    ⚠ Nó học luôn cả ĐỊNH KIẾN
      và coi đó là quy luật
        ↓
    ⚠ Áp dụng ở QUY MÔ LỚN,
      NHẤT QUÁN, TỰ ĐỘNG
        ↓
    → thiên lệch không chỉ được
      duy trì mà còn ⚠ KHUẾCH ĐẠI

⚠ Vì sao "bỏ cột giới tính" KHÔNG đủ:

Xoá cột giới tính khỏi dữ liệu
        ↓
    ⚠ Mô hình vẫn suy ra được
      từ các ĐẶC TRƯNG ĐẠI DIỆN:
      - tên riêng
      - trường học
      - câu lạc bộ, sở thích
      - khoảng trống trong lý lịch
      - mã bưu chính
        ↓
    ⚠ Đây gọi là PROXY VARIABLE
        ↓
    → phải KIỂM TRA KẾT QUẢ theo
      từng nhóm, không chỉ xoá cột

⚠ Vì sao ba phương án kia không phải rủi ro nghiêm trọng:

"Dự đoán chính xác LƯƠNG CŨ
 của ứng viên"
    → ⚠ nghe như vấn đề nhưng
      không phải rủi ro chính
    → (và ở nhiều nơi, hỏi lương cũ
       đã bị cấm)

"Phải thuê thêm nhà khoa học dữ liệu"
    → ⚠ đó là chi phí, không
      phải rủi ro đạo đức

"Gợi ý ứng viên QUÁ GIỎI so với vị trí"
    → ⚠ vấn đề nhỏ, dễ sửa

Nhất quán với #13306 (lô 139) về explainability trong ngành bị quản lý chặt, và #13250 (lô 138) về dữ liệu bẩn dẫn tới mô hình sai. Cả ba cùng chủ đề AI có trách nhiệm.

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

• D (gợi ý ứng viên quá giỏi so với vị trí) — phương án gần nhất về mặt "cũng là kết quả không mong muốn", nhưng đó là vấn đề nhỏ về hiệu chỉnh mô hình, không phải rủi ro pháp lý và đạo đức.

• B (dự đoán chính xác lương cũ) — không phải rủi ro chính; và ở nhiều nơi việc hỏi lương cũ đã bị cấm.

• C (phải thuê thêm nhà khoa học dữ liệu) — là chi phí vận hành, không phải rủi ro của "AI thiếu trách nhiệm".

Ghi nhớ

⚠ Bảy nguyên tắc AI của Google — bảng nên thuộc: | Nguyên tắc | Nội dung | |---|---| | Có lợi cho xã hội | | | ⚠ Tránh tạo hoặc củng cố THIÊN LỆCH bất công | ⚠ đề này | | Được xây và kiểm thử an toàn | | | Chịu trách nhiệm trước con người | ⚠ có người giám sát | | 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:

"dữ liệu lịch sử có định kiến" → rủi ro thiên lệch "phải nêu lý do cho quyết định" → explainability "dữ liệu bẩn" → dự đoán không đáng tin "có người xem lại trước khi áp dụng" → human oversight

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số theo từng nhóm ra sao | ⚠ không chỉ nhìn accuracy tổng | | Có đặc trưng đại diện nào không | rà tên trường, mã bưu chính, sở thích | | Ai chịu trách nhiệm cho quyết định | ⚠ phải là con người |

Và một nguyên tắc đáng giữ với mọi ứng dụng AI ảnh hưởng tới cơ hội của con người: mô hình học từ quá khứ, còn công bằng là điều bạn phải chủ động thiết kế vào hiện tại. Không có thuật toán nào tự sửa được một tập dữ liệu ghi lại những quyết định thiếu công bằng của mười năm trước.