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

Đáp án

C — Diffusion Models (mô hình khuếch tán).

Vì sao đúng

Đề đã nói ra manh mối quyết định: "generate high-quality images from random NOISE" — sinh ảnh từ nhiễu ngẫu nhiên. Đó chính là cách mô hình khuếch tán hoạt động.

⚠ Cách diffusion model làm việc:

Lúc HUẤN LUYỆN (xuôi):
    ảnh thật
        ↓ ⚠ thêm nhiễu từng bước
    ảnh mờ hơn
        ↓
    ⚠ nhiễu hoàn toàn
    → ⚠ mô hình học CÁCH NHIỄU
      ĐƯỢC THÊM VÀO

Lúc SINH ẢNH (ngược):
    ⚠ nhiễu ngẫu nhiên
        ↓ ⚠ khử nhiễu từng bước
        ↓ ⚠ có prompt dẫn đường
    ⚠ ảnh hoàn chỉnh

⚠ Ví von dễ nhớ:

⚠ Như nhà điêu khắc
   bắt đầu từ khối đá thô (nhiễu)
   gọt dần từng nhát
   → ⚠ prompt là bản phác thảo
     chỉ đường

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

• A (GAN) — ⚠ bẫy mạnh nhất: GAN cũng sinh ảnh và từng là kiến trúc chủ đạo. Nhưng cơ chế khác hẳn: ⚠ hai mạng ĐẤU nhau (bộ sinh và bộ phân biệt), không phải khử nhiễu dần. GAN khó huấn luyện ổn định và đã bị diffusion vượt qua về chất lượng — Imagen dùng diffusion.

• B (Transformer) — kiến trúc của mô hình NGÔN NGỮ (Gemini, GPT), dựa trên cơ chế chú ý. ⚠ Transformer có xuất hiện trong phần hiểu prompt của các mô hình sinh ảnh, nhưng phần tạo ảnh từ nhiễu là diffusion.

• D (RLHF) — ⚠ không phải kiến trúc, mà là kỹ thuật huấn luyện thêm để căn chỉnh mô hình theo sở thích con người. Nhầm lẫn giữa "kiến trúc" và "phương pháp huấn luyện" là bẫy hay gặp.

Ghi nhớ

⚠ Bốn khái niệm — bảng phải thuộc: | Khái niệm | Là gì | Dùng ở đâu | |---|---|---| | ⚠ Diffusion | ⚠ kiến trúc — khử nhiễu dần | ⚠ Imagen, sinh ảnh | | ⚠ Transformer | ⚠ kiến trúc — cơ chế chú ý | ⚠ Gemini, mô hình ngôn ngữ | | GAN | ⚠ kiến trúc — hai mạng đối kháng | ⚠ thế hệ sinh ảnh CŨ hơn | | ⚠ RLHF | ⚠ PHƯƠNG PHÁP huấn luyện | ⚠ căn chỉnh, không phải kiến trúc |

Từ khoá nhận diện:

"từ nhiễu ngẫu nhiên", "khử nhiễu", "sinh ảnh" → ⚠ Diffusion "attention", "văn bản, chuỗi token" → ⚠ Transformer "hai mạng đối đầu nhau" → ⚠ GAN "phản hồi con người, căn chỉnh" → ⚠ RLHF

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh có dấu SynthID không | ⚠ kiểm bằng công cụ xác minh | | Chi tiết sản phẩm có đúng thật không | ⚠ người duyệt trước khi đăng | | Chi phí mỗi ảnh và số lần thử lại | ⚠ thường phải sinh nhiều bản mới chọn được |

Và điểm dễ mất điểm nhất ở nhóm câu này: RLHF nằm lẫn trong danh sách kiến trúc. Nó là cách huấn luyện, không phải cách mô hình được xây — nhận ra sự khác biệt giữa "kiến trúc" và "phương pháp huấn luyện" là loại được ngay một phương án.

Đáp án

B — Google Vids.

Vì sao đúng

Đề nêu năm ràng buộc và Google Vids khớp cả năm:

⚠ Ghép từng ràng buộc:

"kế hoạch dự án trong Google Doc"
    → ⚠ Vids đọc thẳng từ Docs

"ảnh trong Google Drive"
    → ⚠ Vids lấy thẳng từ Drive

"ngân sách BẰNG KHÔNG"
    → ⚠ đã có sẵn trong Workspace

"không biết dùng phần mềm dựng"
    → ⚠ Vids tự dựng storyboard

"lồng tiếng + nhận diện
 thương hiệu nhất quán"
    → ⚠ Vids có voiceover AI
      và mẫu thương hiệu

⚠ Gần trùng với #14056 và #14087 (lô 149) — ba câu, ba bối cảnh (marketing, quảng bá sản phẩm, cập nhật dự án), cùng một khoá. Dấu hiệu chung: tài sản nằm trong Workspace + người dùng không chuyên + không ngân sách.

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

• D (Veo) — ⚠ bẫy mạnh nhất vì Veo đúng là mô hình sinh video của Google. Nhưng Veo sinh CLIP từ mô tả bằng lời, nó không lắp ráp tài sản có sẵn thành video hoàn chỉnh, không tự lồng tiếng, không áp mẫu thương hiệu. ⚠ Veo là mô hình, Vids là công cụ hoàn chỉnh cho người dùng cuối.

• A (Imagen) — ⚠ sinh ẢNH TĨNH, không sinh video. Nhớ chắc điểm này vì Imagen xuất hiện rất thường xuyên trong phương án của câu hỏi về video.

• C (Gemini) — trợ lý đa năng, viết được kịch bản và gợi ý bố cục, nhưng cho ra văn bản, không cho ra tệp video đã dựng có lồng tiếng.

Ghi nhớ

⚠ Bốn sản phẩm — bảng phải thuộc: | Sản phẩm | Cho ra | Người dùng | |---|---|---| | ⚠ Google Vids | ⚠ VIDEO hoàn chỉnh từ tài sản có sẵn | ⚠ nhân viên văn phòng — đề này | | Veo | ⚠ clip sinh từ prompt | sáng tạo, lập trình viên | | Imagen | ⚠ ẢNH TĨNH | ⚠ không làm video | | Gemini | ⚠ văn bản, ý tưởng | mọi người |

Từ khoá nhận diện:

"Docs/Drive, không biết dựng, không ngân sách" → ⚠ Google Vids "sinh cảnh quay từ mô tả" → ⚠ Veo "tạo hình ảnh" → ⚠ Imagen "viết kịch bản, tóm tắt" → Gemini

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số liệu tiến độ có khớp kế hoạch gốc không | ⚠ đối chiếu Doc | | Ảnh có lộ thông tin nội bộ không | ⚠ xem từng khung | | Giọng lồng tiếng đọc đúng tên riêng chưa | ⚠ tên dự án, tên người hay bị đọc sai |

Và điều đáng nhớ nhất từ nhóm ba câu Vids liên tiếp: bộ đề rất thích dạng "người không chuyên + tài sản trong Workspace + không tiền". Thấy đủ ba dấu hiệu đó thì không cần đọc kỹ phương án cũng biết đáp án là Vids.

Đáp án

B — Vertex AI Vizier.

Vì sao đúng

Đề mô tả đúng bài toán tối ưu siêu tham số: chỉnh tay learning rate và batch size thì chậm và kết quả kém, cần thử hàng trăm tổ hợp một cách tự động.

⚠ Vizier làm gì:

⚠ Dịch vụ TỐI ƯU HOÁ HỘP ĐEN
        ↓
⚠ Đề xuất tổ hợp tham số tiếp theo
  DỰA TRÊN kết quả các lần trước
        ↓
⚠ Không thử mù như grid search
        ↓
⚠ Tìm được tổ hợp tốt với ÍT lần
  chạy hơn nhiều

⚠ Vì sao khác grid search thủ công:

Grid search
    → ⚠ thử MỌI tổ hợp
    → ⚠ tốn kém theo cấp số nhân

Random search
    → ⚠ thử ngẫu nhiên

⚠ Vizier (tối ưu Bayes)
    → ⚠ HỌC từ lần thử trước
    → ⚠ tập trung vào vùng hứa hẹn

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

• A (Vertex AI Feature Store) — kho quản lý ĐẶC TRƯNG dùng chung giữa huấn luyện và phục vụ, giải bài toán lệch training–serving. ⚠ Không liên quan tới việc chọn tham số.

• C (Vertex AI Model Garden) — nơi duyệt và chọn mô hình có sẵn (Gemini, Llama, mô hình mở). Là bước trước, không phải tối ưu tham số.

• D (Vertex AI Prediction) — dịch vụ phục vụ suy luận sau khi mô hình đã xong. Là bước sau.

⚠ Mẹo: ba phương án sai đều là các giai đoạn KHÁC trong vòng đời ML — nhớ vòng đời là loại được chúng ngay.

Ghi nhớ

⚠ Các thành phần Vertex AI theo vòng đời — bảng phải thuộc: | Giai đoạn | Thành phần | |---|---| | Chọn mô hình | ⚠ Model Garden | | Chuẩn bị dữ liệu | ⚠ Feature Store | | Phát triển | ⚠ Workbench, Colab Enterprise | | ⚠ Tinh chỉnh tham số | ⚠ VIZIER — đề này | | Tự động hoá quy trình | ⚠ Pipelines | | Quản lý phiên bản | ⚠ Model Registry | | Phục vụ | ⚠ Prediction, Endpoints | | Theo dõi | ⚠ Model Monitoring |

Từ khoá nhận diện:

"hyperparameter, learning rate, batch size, thử hàng trăm tổ hợp" → ⚠ Vizier "đặc trưng dùng chung, tránh lệch train–serve" → Feature Store "duyệt và chọn mô hình có sẵn" → Model Garden "phục vụ dự đoán" → Prediction

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số mục tiêu có phản ánh nghiệp vụ không | ⚠ accuracy chưa chắc là thứ cần | | Đã đặt trần chi phí chưa | ⚠ hàng trăm lần chạy là tiền thật | | Kết quả có ổn định trên dữ liệu mới không | ⚠ kiểm trên tập test một lần cuối |

Và cách chắc nhất để trả lời đúng nhóm câu về Vertex AI: định vị câu hỏi vào một giai đoạn của vòng đời ML. Mỗi thành phần thuộc đúng một giai đoạn, nên xác định được giai đoạn là gần như xác định được đáp án.

Đáp án

D — Vertex AI Workbench.

Vì sao đúng

Đề nêu bốn nhu cầu, và Workbench khớp cả bốn:

⚠ Ghép từng nhu cầu:

"môi trường phát triển, cộng tác
 dễ dàng"
    → ⚠ notebook được quản lý,
      chia sẻ được

"thử nghiệm nhanh với nhiều
 thư viện"
    → ⚠ khung ML CÀI SẴN

"truy cập BigQuery không cần
 cấu hình phức tạp"
    → ⚠ tích hợp sẵn, xác thực sẵn

"tối đa thời gian phát triển,
 tối thiểu thời gian cấu hình"
    → ⚠ dịch vụ ĐƯỢC QUẢN LÝ

⚠ Đề còn nói thẳng "managed, collaborative Jupyter notebook environment with pre-installed ML frameworks" — đó gần như là định nghĩa nguyên văn của Workbench.

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

• A (Cloud Shell Editor) — môi trường dòng lệnh + trình soạn thảo nhẹ trên trình duyệt. ⚠ Không phải notebook, tài nguyên hạn chế, không cài sẵn khung ML nặng, không có GPU, và ⚠ phiên bị xoá sau thời gian không dùng.

• B (Vertex AI Pipelines) — công cụ tự động hoá quy trình ML đã định hình. Là bước sau khi đã phát triển xong, không phải môi trường để thử nghiệm.

• C (Vertex AI Model Garden) — nơi duyệt và chọn mô hình có sẵn. Là danh mục, không phải môi trường phát triển.

Ghi nhớ

⚠ Môi trường phát triển trên Google Cloud — bảng phải thuộc: | Công cụ | Là gì | Dùng khi | |---|---|---| | ⚠ Vertex AI Workbench | ⚠ Jupyter được quản lý, có GPU | ⚠ phát triển mô hình — đề này | | Colab Enterprise | ⚠ notebook cộng tác, nhẹ hơn | thử nghiệm nhanh, chia sẻ | | Cloud Shell Editor | ⚠ terminal + editor nhẹ | ⚠ thao tác hạ tầng, không phải ML | | Vertex AI Pipelines | ⚠ tự động hoá quy trình | ⚠ sau khi đã ổn định |

Từ khoá nhận diện:

"notebook, Jupyter, thử nghiệm, cộng tác" → ⚠ Workbench "tự động hoá, chạy lặp lại, có lịch" → Pipelines "duyệt mô hình có sẵn" → Model Garden "gõ lệnh gcloud" → Cloud Shell

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy notebook có tự tắt khi không dùng chưa | ⚠ khoản tiền hay bị quên nhất | | Notebook chạy lại từ đầu có ra kết quả cũ không | ⚠ Restart & Run All | | Quyền truy cập dữ liệu có đúng phạm vi không | ⚠ notebook thường có quyền rộng |

Và điều thực tế nhất phải nhớ: notebook là nơi để KHÁM PHÁ, không phải nơi để chạy sản xuất. Đội nào để mô hình quan trọng chạy bằng cách mở notebook bấm tay thì sớm muộn cũng gặp sự cố không tái hiện được.

Đáp án

B — Standard hoặc Plus cho nhân sự khối văn phòng, Frontline edition cho quản lý kho/cửa hàng và nhân viên bán hàng.

Vì sao đúng

Đề chia rõ ba nhóm với ba nhu cầu khác nhau, và CIO muốn cân bằng năng lực với chi phí.

⚠ Ghép nhu cầu với phiên bản:

200 nhân sự văn phòng
    ⚠ "TẠO agent tuỳ chỉnh"
    ⚠ "tính năng nâng cao"
    → ⚠ Standard/Plus

800 quản lý + 4.000 nhân viên bán
    ⚠ "DÙNG agent đã được duyệt"
    ⚠ "hỗ trợ cơ bản, trên di động"
    → ⚠ FRONTLINE

⚠ Vì sao con số quyết định:

⚠ 4.800 / 5.000 người = 96%
   chỉ cần dùng, không cần tạo
        ↓
⚠ Cấp Plus cho tất cả = trả tiền
  cho năng lực 96% không dùng tới
        ↓
⚠ Frontline sinh ra ĐÚNG cho
  nhóm này

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

• A (Plus cho cả 5.000 người) — ⚠ bẫy "đồng nhất cho đơn giản". Nghe hợp lý về trải nghiệm nhưng ⚠ lãng phí lớn: trả giá cao nhất cho 4.800 người chỉ cần chức năng cơ bản. Đề nói rõ mục tiêu là "balance capabilities with cost".

• D (Business cho tất cả) — cùng lỗi đồng nhất, và ⚠ thiếu năng lực tạo agent tuỳ chỉnh cho nhóm văn phòng — tức là vừa thiếu vừa thừa.

• C (Standard cho văn phòng, Business cho tuyến đầu) — ⚠ sai phiên bản cho tuyến đầu. Nhóm dành riêng cho nhân viên tuyến đầu, dùng di động, chỉ dùng agent có sẵn là Frontline, không phải Business.

Ghi nhớ

⚠ Nguyên tắc phân bổ giấy phép — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Phân theo VAI TRÒ, không đồng nhất | ⚠ nguyên tắc số một | | ⚠ Người TẠO cần bản cao | ⚠ thiểu số | | ⚠ Người DÙNG cần bản tuyến đầu | ⚠ đa số | | Đồng nhất = vừa thừa vừa thiếu | |

Từ khoá nhận diện:

"tạo agent tuỳ chỉnh, tính năng nâng cao" → ⚠ bản cao (Standard/Plus) "dùng agent đã duyệt, cơ bản, di động" → ⚠ Frontline "cho tất cả cho đồng nhất" → ⚠ thường là phương án SAI khi đề nói tới chi phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ người thực sự dùng giấy phép cao | ⚠ đo mức dùng, không đo số cấp | | Nhóm tuyến đầu có bị thiếu chức năng không | ⚠ hỏi trực tiếp, không suy đoán | | Agent phát cho tuyến đầu đã duyệt chưa | ⚠ rủi ro dữ liệu |

Và sai lầm phổ biến nhất khi mua giấy phép AI doanh nghiệp: mua bản cao nhất cho tất cả để tránh phải phân loại. Nó đơn giản cho bộ phận mua sắm nhưng là khoản lãng phí lớn nhất, và thường bị phát hiện khi rà soát chi phí năm sau.

Đáp án

B — Nâng cấp ngay mô hình đang tự vận hành lên phiên bản đã được vá lỗ hổng.

Vì sao đúng

Đề nói rõ: lỗ hổng nằm trong CHÍNH PHIÊN BẢN mô hình đó, và cho phép vượt qua bộ lọc an toàn. Khi lỗi nằm ở phần mềm, cách chữa là vá phần mềm.

⚠ Vì sao là hành động cấp bách nhất:

Lỗ hổng ĐÃ CÔNG BỐ
    ⚠ kẻ tấn công biết cách khai thác
        ↓
Chatbot ĐỐI MẶT CÔNG CHÚNG
    ⚠ ai cũng thử được
        ↓
⚠ Vá là cách DUY NHẤT xử lý
  NGUYÊN NHÂN GỐC

⚠ Điểm quan trọng — công ty TỰ VẬN HÀNH:

"hosted on ITS OWN servers"
        ↓
⚠ KHÔNG có ai vá hộ
⚠ Trách nhiệm vá là của CÔNG TY
        ↓
⚠ Khác với dùng mô hình quản lý:
  nhà cung cấp vá cho

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

• D (dùng prompt engineering dặn chatbot đừng trả lời prompt độc hại) — ⚠ bẫy hấp dẫn nhất vì làm được ngay và không tốn gì. Nhưng ⚠ chính lỗ hổng là VƯỢT QUA được chỉ dẫn an toàn — dùng chỉ dẫn để chặn thứ chuyên phá chỉ dẫn là vô nghĩa. Đây là lớp phòng thủ bổ sung, không phải cách chữa.

• C (fine-tune bằng tập prompt lành tính) — ⚠ sai hướng: fine-tune trên ví dụ không độc hại không dạy mô hình chống lại ví dụ độc hại. Ngoài ra fine-tune mất nhiều ngày, còn lỗ hổng thì đang bị khai thác ngay bây giờ.

• A (theo dõi KPI xem mức tương tác có giảm không) — ⚠ hoàn toàn lạc đề: đây là chỉ số kinh doanh, không phải biện pháp bảo mật. Chờ KPI giảm mới biết thì thiệt hại đã xảy ra rồi.

Ghi nhớ

⚠ Thứ tự ưu tiên khi có lỗ hổng — bảng phải thuộc: | Thứ tự | Việc | |---|---| | ⚠ 1 | ⚠ VÁ — sửa nguyên nhân gốc | | 2 | ⚠ giảm thiểu tạm nếu chưa vá được | | 3 | ⚠ thêm lớp phòng thủ (Model Armor, lọc đầu vào) | | 4 | ⚠ theo dõi và ghi vết | | ⚠ Không bao giờ | ⚠ chỉ dặn mô hình đừng làm |

Từ khoá nhận diện:

"lỗ hổng trong phiên bản mô hình" → ⚠ nâng cấp/vá "tự vận hành trên máy chủ mình" → ⚠ TRÁCH NHIỆM VÁ là của mình "dặn mô hình đừng…" → ⚠ không phải biện pháp bảo mật "theo dõi KPI" → ⚠ không phải hành động khắc phục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang chạy phiên bản mô hình nào | ⚠ ghi rõ, theo dõi thông báo bảo mật | | Có quy trình vá khẩn cấp chưa | ⚠ bao lâu từ lúc biết tới lúc vá xong | | Vượt được filter thì làm được gì | ⚠ giới hạn thiệt hại bằng quyền tối thiểu |

Và bài học lớn nhất của ca này: chọn mô hình mở tự vận hành là nhận luôn nghĩa vụ theo dõi và vá lỗ hổng. Nhiều đội chỉ nghĩ tới phần tiết kiệm chi phí suy luận mà quên phần vận hành bảo mật — chính là phần tốn công nhất.

Đáp án

D — 1: Compute Engine (IaaS), 2: Vertex AI (PaaS), 3: Gemini for Workspace (SaaS).

Vì sao đúng

Đề cho ba đội với ba mức kiểm soát khác nhau, và mỗi mức khớp đúng một mô hình dịch vụ:

⚠ Ghép từng đội:

1. Đội nghiên cứu
   ⚠ "toàn quyền với HỆ ĐIỀU HÀNH"
   ⚠ "phiên bản driver NVIDIA cụ thể"
   → ⚠ cần MÁY ẢO trần
   → ⚠ IaaS — Compute Engine

2. Đội ứng dụng
   ⚠ "chỉ tập trung vào CODE Python"
   ⚠ "Google lo OS, co giãn, hạ tầng"
   → ⚠ PaaS — Vertex AI

3. Đội marketing
   ⚠ "công cụ DÙNG NGAY"
   ⚠ "trong ứng dụng email sẵn có"
   ⚠ "không cần lập trình"
   → ⚠ SaaS — Gemini for Workspace

⚠ Mẹo nhớ ba tầng:

⚠ IaaS  → bạn quản lý HỆ ĐIỀU HÀNH
⚠ PaaS  → bạn chỉ quản lý MÃ NGUỒN
⚠ SaaS  → bạn chỉ DÙNG

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

Cả ba phương án còn lại đều ghép lệch vị trí:

• A — cho đội nghiên cứu dùng SaaS, tức là không có quyền chạm vào driver; và đẩy đội marketing sang IaaS, bắt người không lập trình đi quản trị máy ảo.

• B — cho đội nghiên cứu PaaS (không kiểm soát được OS) và đội ứng dụng IaaS (đúng thứ họ nói muốn tránh).

• C — đội nghiên cứu đúng, nhưng hoán đổi hai đội còn lại: đội ứng dụng viết code Python lại nhận công cụ soạn email, còn marketing nhận nền tảng ML.

⚠ Chiến thuật: với câu ghép ba, chỉ cần chốt một cặp chắc chắn nhất — ở đây "driver NVIDIA cụ thể → IaaS" là cặp rõ nhất, loại ngay A và B; rồi phân biệt C với D bằng cặp thứ hai.

Ghi nhớ

⚠ Ba mô hình dịch vụ — bảng phải thuộc: | Mô hình | Bạn quản lý | Ví dụ AI | |---|---|---| | ⚠ IaaS | ⚠ OS, driver, runtime, ứng dụng | ⚠ Compute Engine + GPU | | ⚠ PaaS | ⚠ chỉ CODE và DỮ LIỆU | ⚠ Vertex AI | | ⚠ SaaS | ⚠ chỉ dữ liệu và cấu hình | ⚠ Gemini for Workspace |

Từ khoá nhận diện:

"OS, driver, phiên bản CUDA cụ thể" → ⚠ IaaS "chỉ lo code, Google lo phần còn lại" → ⚠ PaaS "dùng ngay, không cần lập trình" → ⚠ SaaS "toàn quyền kiểm soát" → ⚠ luôn nghiêng về IaaS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội có thật sự cần kiểm soát OS không | ⚠ thường là không — chọn PaaS rẻ hơn | | Ai vá bảo mật cho máy ảo | ⚠ IaaS là việc của bạn | | Máy GPU có tắt khi không dùng không | ⚠ khoản chi phí lớn nhất và hay bị quên |

Và nguyên tắc thực dụng rút ra: chọn tầng cao nhất mà vẫn làm được việc. Mỗi bậc xuống thấp là thêm một khối lượng vận hành — vá hệ điều hành, quản lý driver, lo bảo mật — mà đội nào cũng đánh giá thấp cho tới khi phải làm thật.

Đáp án

D — Model Armor với bộ lọc chống tiêm prompt và bảo vệ dữ liệu nhạy cảm.

Vì sao đúng

Đề nêu hai rủi ro rất cụ thể, và Model Armor là sản phẩm được thiết kế cho đúng cả hai:

⚠ Ghép hai rủi ro:

"prompt injection — thao túng bot
 để lộ system prompt hoặc thực hiện
 hành động trái phép"
    → ⚠ Model Armor: bộ lọc
      CHỐNG TIÊM PROMPT

"vô tình lộ thông tin bệnh nhân:
 số thẻ tín dụng, mã hồ sơ y tế"
    → ⚠ Model Armor: bộ lọc
      DỮ LIỆU NHẠY CẢM

⚠ Vị trí của Model Armor:

Người dùng
    ↓
⚠ MODEL ARMOR — kiểm đầu vào
    ↓
Mô hình Gemini
    ↓
⚠ MODEL ARMOR — kiểm đầu ra
    ↓
Người dùng

⚠ Lớp bảo vệ NẰM NGOÀI mô hình
   → không bị prompt thao túng

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

• A (bộ lọc an toàn sẵn của Gemini) — ⚠ bẫy mạnh nhất vì đây là biện pháp đúng nhưng chặn NHẦM LOẠI rủi ro. Safety filter lo nội dung có hại (bạo lực, thù ghét, khiêu dâm). ⚠ Nó không phát hiện tiêm prompt và không nhận diện số thẻ tín dụng hay mã y tế.

• B (fine-tune bằng ví dụ hội thoại an toàn) — ⚠ không phải kiểm soát bảo mật. Fine-tune tác động lên xu hướng của mô hình, không tạo ra rào chắn kiểm chứng được; kẻ tấn công vẫn tìm được cách viết prompt lách qua.

• C (Agent Engine Sessions lưu lịch sử hội thoại) — ⚠ quản lý trạng thái, không phải bảo mật. Thậm chí ⚠ lưu hội thoại chứa dữ liệu bệnh nhân còn LÀM TĂNG rủi ro nếu không có lớp lọc.

Ghi nhớ

⚠ Bốn lớp bảo vệ và việc chúng lo — bảng phải thuộc: | Lớp | Chặn cái gì | |---|---| | ⚠ Model Armor | ⚠ TIÊM PROMPT, jailbreak, DỮ LIỆU NHẠY CẢM, URL độc — đề này | | Safety filters | ⚠ nội dung CÓ HẠI | | DLP / Sensitive Data Protection | ⚠ quét và che dữ liệu trong kho | | IAM + VPC-SC | ⚠ ai truy cập được gì |

Từ khoá nhận diện:

"prompt injection, jailbreak, lộ system prompt" → ⚠ Model Armor "số thẻ, mã bệnh nhân, PII trong hội thoại" → ⚠ Model Armor "nội dung bạo lực, thù ghét" → ⚠ safety filters "lưu lịch sử hội thoại" → Agent Engine Sessions

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử tiêm prompt thật xem có bị chặn không | ⚠ red team trước khi ra mắt | | Log có chứa dữ liệu bệnh nhân không | ⚠ kiểm chính log của mình | | Ca khẩn cấp có chuyển được cho người không | ⚠ thử kịch bản cấp cứu |

Và điều then chốt để phân biệt các lớp bảo vệ: safety filter hỏi "nội dung này có hại không", Model Armor hỏi "có ai đang tấn công hệ thống không và có dữ liệu nhạy cảm nào đang đi qua không". Hai câu hỏi khác nhau, hai công cụ khác nhau.

Đáp án

D — Gemini 3 Flash, nhờ tốc độ và hiệu quả chi phí mà vẫn giữ chất lượng tốt.

Vì sao đúng

Đề nêu bốn ràng buộc, và cả bốn đều chỉ về mô hình nhẹ:

⚠ Ghép từng ràng buộc:

"hàng NGHÌN câu hỏi mỗi ngày"
    → ⚠ khối lượng lớn, chi phí nhân lên

"câu hỏi ĐƠN GIẢN — trạng thái đơn,
 còn hàng không, chính sách đổi trả"
    → ⚠ KHÔNG cần suy luận sâu

"khách chờ phản hồi GẦN NHƯ TỨC THÌ"
    → ⚠ ĐỘ TRỄ là yếu tố sống còn

"tối thiểu chi phí vận hành"
    → ⚠ chi phí mỗi truy vấn quan trọng

⚠ Vì sao Flash là lựa chọn đúng:

⚠ Nhanh hơn nhiều
⚠ Rẻ hơn nhiều
⚠ Vẫn thừa sức cho tra cứu
  đơn giản có RAG hỗ trợ

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

• A (luân phiên Flash và Pro theo độ phức tạp) — ⚠ bẫy tinh vi nhất vì nghe rất "thông minh" và trong nhiều đề khác đây là đáp án đúng. Nhưng ở đây đề nói rõ "the queries are straightforward" — ⚠ mọi câu đều đơn giản, nên bộ định tuyến chỉ thêm độ trễ, thêm chi phí, thêm chỗ hỏng mà không mang lại gì.

• B (Gemini 3 Pro cho độ chính xác tối đa) — ⚠ thừa năng lực: chậm hơn và đắt hơn cho việc tra cứu trạng thái đơn hàng. Vi phạm cả hai yêu cầu chi phí và tốc độ.

• C (Pro với chế độ Deep Think) — ⚠ sai nghiêm trọng nhất: chế độ suy luận sâu cố ý dành THÊM thời gian suy nghĩ, đúng thứ đề nói phải tránh. Dùng nó để trả lời "đơn hàng của tôi tới đâu rồi" là cực kỳ lãng phí.

Ghi nhớ

⚠ Chọn mô hình theo việc — bảng phải thuộc: | Việc | Mô hình | |---|---| | ⚠ Khối lượng lớn, câu đơn giản, cần nhanh | ⚠ FLASH — đề này | | Suy luận phức tạp, phân tích sâu | ⚠ Pro | | ⚠ Bài toán rất khó, chấp nhận chờ | ⚠ Pro + chế độ suy luận sâu | | ⚠ Hỗn hợp thật sự | ⚠ định tuyến theo độ phức tạp |

Từ khoá nhận diện:

"straightforward, near-instant, thousands daily" → ⚠ Flash "phân tích nhiều bước, lập luận phức tạp" → Pro "câu hỏi có loại dễ có loại khó" → ⚠ định tuyến — CHỈ khi đề nói HỖN HỢP "deep think, reasoning mode" → ⚠ chậm có chủ đích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Flash có đủ chất lượng không | ⚠ chạy song song trên tập câu hỏi thật rồi so | | Độ trễ p95 là bao nhiêu | ⚠ không phải trung bình | | Tỷ lệ phải chuyển cho người | ⚠ chỉ số quan trọng hơn điểm mô hình |

Và nguyên tắc thực dụng: bắt đầu bằng mô hình nhỏ nhất, chỉ nâng khi ĐO được là không đủ. Đi ngược lại — bắt đầu bằng mô hình mạnh nhất rồi định tối ưu sau — là cách phổ biến nhất để hoá đơn AI phình ra mà chất lượng không hơn.

Đáp án

A — Dialogflow API.

Vì sao đúng

Đề mô tả đúng thuật ngữ chuyên môn của Dialogflow: nhận diện ý định (intent) và trích xuất thực thể (entity) để điền đủ các khe thông tin (slot filling) trước khi thực hiện hành động.

⚠ Ghép từng khái niệm:

"I want a large pizza with pepperoni"
        ↓
⚠ INTENT: đặt pizza
⚠ ENTITY: size = large
⚠ ENTITY: topping = pepperoni
⚠ ENTITY: address = THIẾU
        ↓
⚠ Bot tự hỏi lại địa chỉ
   → ĐÓ LÀ SLOT FILLING

⚠ Vì sao đây là bài toán "hội thoại có cấu trúc":

⚠ Danh sách thông tin BẮT BUỘC
   là CỐ ĐỊNH
   → size, topping, địa chỉ
⚠ Có trạng thái rõ ràng: đủ / thiếu
⚠ Kết thúc bằng một HÀNH ĐỘNG
   xác định: đặt đơn

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

• B (Gemini API) — ⚠ bẫy hấp dẫn vì Gemini hiểu ngôn ngữ tốt hơn nhiều. Nhưng đề hỏi dịch vụ "specifically designed" cho quản lý hội thoại điền khe. Dùng Gemini thì phải tự viết phần theo dõi khe nào đã đủ, khe nào còn thiếu, và tự xử lý xác thực dữ liệu.

• D (Natural Language API) — chỉ PHÂN TÍCH văn bản (thực thể, cảm xúc, cú pháp). ⚠ Nó không quản lý hội thoại, không nhớ lượt trước, không hỏi lại.

• C (Vertex AI Search) — tìm kiếm trên tài liệu, hoàn toàn khác bài toán đặt hàng.

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

⚠ Lưu ý đối chiếu: ở #14084 (lô 149) và #14105 (lô này), Dialogflow ES là phương án SAI còn Agent Builder mới đúng. Ở đây Dialogflow lại đúng. Không mâu thuẫn — khác nhau ở bài toán:

⚠ Dấu hiệu phân biệt: đề nhắc "intent", "entity", "slot", biểu mẫu cố định → Dialogflow. Đề nhắc "orchestrate", "multi-step", "different tools and APIs" → Agent Builder.

Ghi nhớ

⚠ Bốn dịch vụ ngôn ngữ — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | ⚠ Dialogflow | ⚠ quản lý HỘI THOẠI, intent, entity, slot — đề này | | Natural Language API | ⚠ PHÂN TÍCH văn bản, không hội thoại | | Gemini API | ⚠ hiểu và sinh ngôn ngữ tổng quát | | Vertex AI Search | ⚠ tìm trong tài liệu |

Từ khoá nhận diện:

"intent, entity, slot filling, thu đủ thông tin" → ⚠ Dialogflow "cảm xúc, trích thực thể từ một đoạn văn" → Natural Language API "orchestrate nhiều API" → Agent Builder "tìm trong tài liệu" → Vertex AI Search

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bot có xác nhận đơn trước khi đặt không | ⚠ bắt buộc | | Khách nói lộn xộn nhiều thông tin một lúc thì sao | ⚠ thử câu dài có đủ ba khe | | Khách đổi ý ở lượt cuối thì bot xử lý ra sao | ⚠ kịch bản hay bị bỏ sót |

Và cách nhớ ranh giới giữa hai họ sản phẩm: Dialogflow là biểu mẫu biết nói chuyện, Agent Builder là trợ lý biết tự xoay xở. Đơn hàng pizza là biểu mẫu; lên kế hoạch cả chuyến du lịch thì không.