Ngân hàng đề — Google Cloud Generative AI Leader
Tìm thấy 556 câu.
An organization is building a sophisticated customer support agent. The agent must first accurately identify the user's intent and extract key details (like product name and issue type) from a support query. Then, it needs to generate a detailed, helpful, multi-paragraph response.
Why would a developer choose to use two separate, specialized models for this task?
-
A
Because a single large model cannot perform both understanding and generation.
-
B
Because Google Cloud's IAM policies require separate models for Natural Language Understanding (NLU) and text generation tasks for security reasons.
-
C
To optimize performance by using a fine-tuned, efficient model for understanding intent and a different, more powerful model for generating high-quality responses.
-
D
To reduce the overall amount of training data required for the project.
Xem giải thích
Đáp án
C — Để tối ưu hiệu năng: dùng một mô hình nhỏ đã tinh chỉnh để hiểu ý định, và một mô hình mạnh hơn để sinh câu trả lời chất lượng cao.
Vì sao đúng
Đề mô tả hai công việc có tính chất khác hẳn nhau trong cùng một luồng, nên dùng hai mô hình phù hợp cho từng việc là hợp lý.
⚠ So sánh hai việc:
Việc 1 — HIỂU
⚠ phân loại ý định
⚠ trích tên sản phẩm, loại lỗi
→ ⚠ đầu ra NGẮN, có cấu trúc
→ ⚠ mô hình NHỎ tinh chỉnh
là đủ, nhanh và rẻ
Việc 2 — SINH
⚠ câu trả lời nhiều đoạn
⚠ mạch lạc, hữu ích
→ ⚠ cần mô hình MẠNH
⚠ Vì sao chia đôi lại lợi:
⚠ Việc phân loại chạy cho MỌI truy vấn
→ ⚠ dùng mô hình rẻ tiết kiệm nhiều
⚠ Mô hình nhỏ tinh chỉnh còn CHÍNH XÁC HƠN
ở phân loại chuyên ngành hẹp
⚠ Mỗi phần nâng cấp độc lập được
Vì sao các phương án khác sai
-
A (một mô hình lớn KHÔNG THỂ làm cả hai) — ⚠ sai về sự thật. Mô hình lớn hoàn toàn làm được cả hai; ⚠ đây là lý do "không thể" chứ không phải "tối ưu hơn" — và câu hỏi hỏi vì sao lập trình viên CHỌN cách này.
-
B (chính sách IAM của Google Cloud BẮT BUỘC tách mô hình NLU và sinh văn bản vì lý do bảo mật) — ⚠ hoàn toàn bịa đặt. Không có chính sách IAM nào như vậy. Đây là dạng phương án nghe có vẻ kỹ thuật nhưng vô căn cứ — thấy một quy tắc lạ mà chưa từng nghe thì rất nên nghi ngờ.
-
D (giảm tổng lượng dữ liệu huấn luyện cần) — ⚠ ngược lại: tinh chỉnh một mô hình riêng cho việc hiểu ý định đòi hỏi THÊM dữ liệu gán nhãn, không phải bớt.
Ghi nhớ
⚠ Vì sao dùng nhiều mô hình — bảng phải thuộc: | Lý do | Nội dung | |---|---| | ⚠ Chi phí | ⚠ việc chạy nhiều lần dùng mô hình rẻ | | ⚠ Độ trễ | ⚠ mô hình nhỏ phản hồi nhanh | | ⚠ Độ chính xác chuyên ngành | ⚠ mô hình nhỏ TINH CHỈNH có thể thắng mô hình lớn ở việc hẹp | | Vận hành độc lập | ⚠ nâng cấp từng phần | | ⚠ KHÔNG phải vì | ⚠ mô hình lớn không làm được, hay vì IAM bắt buộc |
Từ khoá nhận diện:
"phân loại, trích xuất, đầu ra ngắn" → ⚠ mô hình nhỏ, tinh chỉnh "viết nhiều đoạn, mạch lạc, hữu ích" → ⚠ mô hình mạnh "IAM bắt buộc…" trong phương án → ⚠ dấu hiệu phương án BỊA
| ⚠ Kiến trúc hai tầng điển hình | Tầng |
|---|---|
| ⚠ Tầng phân loại | ⚠ rẻ, nhanh, chạy cho mọi truy vấn |
| ⚠ Tầng định tuyến | ⚠ quyết định đưa đi đâu |
| ⚠ Tầng sinh | ⚠ mô hình mạnh, chỉ chạy khi cần |
| Lợi ích thêm | ⚠ câu hỏi đơn giản trả lời bằng mẫu, không cần sinh |
| ⚠ Khi nào mô hình nhỏ tinh chỉnh THẮNG mô hình lớn | Khi nào |
|---|---|
| ⚠ Nhiệm vụ HẸP và lặp lại | ⚠ phân loại vào 20 nhóm cố định |
| ⚠ Có nhiều dữ liệu gán nhãn | |
| ⚠ Nhãn mang tính đặc thù nội bộ | ⚠ mô hình chung không biết |
| Cần độ trễ rất thấp | |
| Đổi lại | ⚠ phải duy trì dữ liệu và huấn luyện lại khi nghiệp vụ đổi |
| ⚠ Cái giá của kiến trúc nhiều mô hình | Cái giá |
|---|---|
| ⚠ Phức tạp hơn khi vận hành | ⚠ hai thứ để theo dõi và cập nhật |
| ⚠ Lỗi tầng một lan sang tầng hai | ⚠ phân loại sai → trả lời sai chủ đề |
| Cần dữ liệu gán nhãn | |
| Nguyên tắc | ⚠ bắt đầu bằng MỘT mô hình, tách ra khi đo được lợi ích |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ chính xác của tầng phân loại | ⚠ sai ở đây kéo hỏng cả luồng | | Chi phí thật khi tách so với gộp | ⚠ đo trên lưu lượng thật | | Có xử lý được truy vấn không thuộc nhóm nào không | ⚠ phải có nhánh dự phòng |
Và mẹo nhận ra phương án bịa trong đề thi: một quy tắc bắt buộc mà bạn chưa từng nghe — như "IAM yêu cầu tách mô hình NLU và sinh văn bản" — gần như luôn là phương án sai. Bộ đề hay cài loại này vì nó nghe rất chuyên môn với người mới.
A large financial institution is considering moving its sensitive AI-powered fraud detection workloads to Google Cloud. Their primary concern is not about user access controls (which they can configure) but about sophisticated, low-level threats targeting the physical servers and the boot process in the data center.
Which element of Google Cloud's platform directly addresses this concern by establishing a hardware root of trust?
-
A
The comprehensive logging of all API calls through Cloud Audit Logs for post-incident analysis.
-
B
The ability to configure fine-grained Identity and Access Management (IAM) roles to restrict data access.
-
C
The automatic encryption of all data at rest and in transit across the Google network.
-
D
The use of custom-designed security hardware like the Titan chip to verify the integrity of the system from the hardware up.
Xem giải thích
Đáp án
D — Phần cứng bảo mật tự thiết kế như chip Titan, xác minh tính toàn vẹn của hệ thống từ tầng phần cứng trở lên.
Vì sao đúng
Đề cố ý loại trừ hai hướng trả lời quen thuộc và chỉ thẳng vào một chỗ:
⚠ Đề tự thu hẹp phạm vi:
"NOT about user access controls"
→ ⚠ loại IAM
"low-level threats targeting the
PHYSICAL SERVERS and the
BOOT PROCESS"
→ ⚠ tầng PHẦN CỨNG và
quá trình KHỞI ĐỘNG
"hardware ROOT OF TRUST"
→ ⚠ nói thẳng thuật ngữ
⚠ Titan làm gì:
⚠ Chip bảo mật Google tự thiết kế
↓
⚠ Kiểm chữ ký firmware TRƯỚC KHI
máy khởi động
↓
⚠ Firmware bị sửa → máy KHÔNG BOOT
↓
⚠ Tạo danh tính mã hoá cho từng máy
↓
⚠ GỐC TIN CẬY — mọi lớp trên
dựa vào lớp dưới đã được kiểm
Vì sao các phương án khác sai
Cả ba đều là biện pháp bảo mật thật nhưng ở tầng khác:
-
B (IAM chi tiết) — ⚠ đề loại trừ tường minh: "not about user access controls (which they can configure)".
-
C (mã hoá khi lưu và khi truyền) — bảo vệ DỮ LIỆU, không bảo vệ quá trình khởi động máy. ⚠ Nếu firmware đã bị chiếm, kẻ tấn công đọc được dữ liệu sau khi giải mã — mã hoá không cứu được.
-
A (Cloud Audit Logs) — ⚠ phát hiện SAU sự cố, không ngăn chặn. Và mối đe doạ ở tầng firmware có thể ⚠ giả mạo hoặc vô hiệu hoá chính log.
Ghi nhớ
⚠ Các tầng bảo mật — bảng phải thuộc: | Tầng | Biện pháp | |---|---| | ⚠ Phần cứng | ⚠ TITAN — gốc tin cậy, khởi động đã kiểm chứng | | Hạ tầng | ⚠ cách ly, mã hoá liên máy | | Dữ liệu | ⚠ mã hoá khi lưu và truyền, CMEK | | Danh tính | ⚠ IAM, quyền tối thiểu | | Giám sát | ⚠ Audit Logs, SCC | | ⚠ Riêng AI | ⚠ SAIF, Model Armor |
Từ khoá nhận diện:
"root of trust, boot process, firmware, phần cứng" → ⚠ Titan "ai được truy cập gì" → IAM "dữ liệu bị đọc trộm" → mã hoá "ai đã làm gì, điều tra sau sự cố" → Audit Logs
| ⚠ Vì sao gốc tin cậy phần cứng là NỀN | Lý do |
|---|---|
| ⚠ Mọi lớp trên đều GIẢ ĐỊNH lớp dưới sạch | |
| ⚠ Firmware bị chiếm → HỆ ĐIỀU HÀNH nói dối | ⚠ phần mềm bảo mật chạy trên đó cũng vô nghĩa |
| ⚠ Không phát hiện được từ trong phần mềm | |
| Vì thế | ⚠ phải có thứ KHÔNG THỂ SỬA làm điểm khởi đầu |
| ⚠ Chuỗi khởi động đã kiểm chứng | Bước |
|---|---|
| ⚠ Titan kiểm firmware | ⚠ so chữ ký |
| Firmware kiểm bootloader | |
| Bootloader kiểm nhân hệ điều hành | |
| ⚠ Mỗi lớp kiểm lớp kế tiếp | ⚠ đứt một mắt là dừng |
| Kết quả | ⚠ máy chỉ chạy được phần mềm đã được duyệt |
| ⚠ Vì sao khách hàng tài chính quan tâm | Lý do |
|---|---|
| ⚠ Đe doạ cấp quốc gia nhắm vào chuỗi cung ứng | |
| ⚠ Không tự kiểm được trung tâm dữ liệu của nhà cung cấp | |
| Yêu cầu chứng nhận và kiểm toán | ⚠ cần bằng chứng, không chỉ lời hứa |
| ⚠ Tự vận hành cũng phải tự lo tầng này | ⚠ và rất khó làm tốt bằng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhà cung cấp có gốc tin cậy phần cứng không | ⚠ hỏi cụ thể, xem tài liệu bảo mật | | Có chứng nhận độc lập nào | ⚠ báo cáo kiểm toán bên thứ ba | | Phần nào vẫn là trách nhiệm của mình | ⚠ mô hình trách nhiệm chia sẻ |
Và điều đáng nhớ về cách ra đề: khi đề LOẠI TRỪ tường minh một hướng ("không phải về kiểm soát truy cập"), đó là câu quan trọng nhất của đề bài — nó loại thẳng phương án nghe hợp lý nhất, và phần còn lại thường chỉ có một lựa chọn đúng tầng.
A healthcare organization needs to train a model to categorize patient inquiries but is prohibited by privacy laws from using real patient data. They decide to use generative AI to create a synthetic dataset for this purpose.
While this solves the privacy issue, what is the most significant business risk they must now manage?
-
A
If the original data used to create the synthetic set contains biases, the model can amplify them, leading to an unfair or ineffective AI system.
-
B
The cost of generating the synthetic data will likely exceed the cost of manually labeling a small, real dataset.
-
C
Generative AI models cannot create structured data, only unstructured text, making it unsuitable for this task.
-
D
Storing the synthetic dataset will require significantly more cloud storage than the original data.
Xem giải thích
Đáp án
A — Nếu dữ liệu gốc dùng để tạo tập tổng hợp có sẵn thiên lệch, mô hình có thể khuếch đại chúng, dẫn tới hệ thống AI không công bằng hoặc kém hiệu quả.
Vì sao đúng
Dữ liệu tổng hợp giải quyết được quyền riêng tư, nhưng không giải quyết được chất lượng và tính đại diện.
⚠ Chuỗi rủi ro:
Dữ liệu bệnh nhân THẬT
⚠ có thể thiếu đại diện một số nhóm
↓
⚠ Mô hình sinh HỌC từ phân bố đó
↓
⚠ Dữ liệu tổng hợp TÁI TẠO
chính thiên lệch ấy
↓
⚠ Có thể còn KHUẾCH ĐẠI
— sinh nhiều hơn mẫu phổ biến
↓
⚠ Mô hình phân loại yêu cầu
bệnh nhân hoạt động kém với
nhóm thiểu số
⚠ Điểm nguy hiểm nhất:
⚠ Dữ liệu tổng hợp TRÔNG như thật
⚠ Không có bệnh nhân thật nào
để khiếu nại
⚠ Thiên lệch bị GIẤU sau một lớp
kỹ thuật nghe rất an toàn
Vì sao các phương án khác sai
-
C (mô hình sinh không tạo được dữ liệu có cấu trúc) — ⚠ sai về sự thật: mô hình sinh tạo được bảng, JSON, dữ liệu có nhãn. Và ở đây họ cần văn bản yêu cầu bệnh nhân, vốn là dữ liệu phi cấu trúc.
-
D (dữ liệu tổng hợp tốn nhiều dung lượng hơn nhiều) — ⚠ không có cơ sở; dung lượng phụ thuộc số bản ghi họ sinh ra, và chi phí lưu trữ văn bản là chuyện nhỏ, không phải "rủi ro kinh doanh lớn nhất".
-
B (chi phí sinh dữ liệu vượt chi phí gán nhãn tay một tập nhỏ) — ⚠ bẫy hợp lý nhất vì chi phí là mối lo có thật. Nhưng ⚠ đề nói họ bị luật CẤM dùng dữ liệu bệnh nhân thật — nên "gán nhãn tay một tập thật nhỏ" không phải lựa chọn hợp pháp. So sánh chi phí với một phương án không được phép làm là vô nghĩa.
Ghi nhớ
⚠ Dữ liệu tổng hợp giải và không giải được gì — bảng phải thuộc: | Vấn đề | Có giải được không | |---|---| | ⚠ Quyền riêng tư | ⚠ CÓ — không có người thật | | Thiếu dữ liệu hiếm | ⚠ có — sinh thêm ca hiếm | | Cân bằng lớp | ⚠ có — nếu chủ động cân | | ⚠ THIÊN LỆCH trong dữ liệu gốc | ⚠ KHÔNG — kế thừa nguyên vẹn | | ⚠ Mẫu hình chưa từng có trong gốc | ⚠ KHÔNG — không sinh ra tri thức mới |
Từ khoá nhận diện:
"synthetic data giải quyết riêng tư" → ⚠ đúng, nhưng hỏi rủi ro CÒN LẠI "dữ liệu gốc thiếu đại diện" → ⚠ thiên lệch được kế thừa "mô hình sinh không làm được X" → ⚠ thường là phương án SAI SỰ THẬT
| ⚠ Vì sao thiên lệch bị khuếch đại chứ không giữ nguyên | Lý do |
|---|---|
| ⚠ Mô hình sinh nghiêng về mẫu PHỔ BIẾN | ⚠ đuôi phân bố bị cắt bớt |
| ⚠ Ca hiếm càng hiếm hơn trong bản tổng hợp | |
| ⚠ Huấn luyện trên bản tổng hợp lặp lại nhiều vòng | ⚠ sai lệch cộng dồn |
| Hiện tượng này có tên | ⚠ model collapse khi lặp nhiều thế hệ |
| ⚠ Việc phải làm khi dùng dữ liệu tổng hợp | Việc |
|---|---|
| ⚠ Kiểm phân bố bản tổng hợp so với thực tế | ⚠ theo từng nhóm |
| ⚠ Chủ động cân bằng nhóm thiểu số | ⚠ đừng chỉ sao chép phân bố gốc |
| ⚠ Đánh giá mô hình trên dữ liệu THẬT | ⚠ dù huấn luyện trên tổng hợp |
| Chuyên gia lâm sàng rà soát mẫu | |
| ⚠ Ghi rõ nguồn gốc dữ liệu | ⚠ truy vết được khi có vấn đề |
| ⚠ Riêng y tế | Lưu ý |
|---|---|
| ⚠ Sai với nhóm thiểu số là rủi ro SỨC KHOẺ | ⚠ không chỉ là bất tiện |
| ⚠ Dữ liệu tổng hợp vẫn có thể rò rỉ thông tin gốc | ⚠ nếu mô hình sinh ghi nhớ mẫu |
| Cần kiểm chứng riêng tư khác biệt | ⚠ không mặc định là an toàn tuyệt đối |
| ⚠ Ghi rõ trong hồ sơ tuân thủ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phân bố nhóm trong bản tổng hợp | ⚠ so với dân số thật, không so với dữ liệu gốc | | Mô hình hoạt động ra sao với nhóm hiếm | ⚠ đo riêng từng nhóm | | Bản tổng hợp có lặp lại bản ghi thật không | ⚠ kiểm rò rỉ ghi nhớ |
Và ngộ nhận nguy hiểm nhất về dữ liệu tổng hợp: tưởng rằng vì không có người thật nào trong đó nên nó trung lập. Nó chỉ trung lập về danh tính; về mọi mẫu hình khác, nó là bản sao trung thành của dữ liệu đã sinh ra nó — kể cả những mẫu hình ta muốn loại bỏ.
A national retail chain is building a customer service chatbot to help shoppers find nearby store locations and answer questions like "Which stores near me are open late tonight?" and "Does the location on Main Street have wheelchair access?" The company wants accurate, real-time information about store hours, amenities, and user ratings without manually updating this data across hundreds of locations. The IT director emphasizes that responses must be factual and verifiable since customers make shopping decisions based on this information.
Which grounding approach best ensures accurate, location-based responses with up-to-date business information?
-
A
Grounding with Google Maps for real-time place data and geospatial context.
-
B
Grounding with Google Search for web-based information retrieval.
-
C
Fine-tuning Gemini with the company's historical store data.
-
D
RAG with Vertex AI Search using the company's internal store database.
Xem giải thích
Đáp án
A — Grounding with Google Maps để lấy dữ liệu địa điểm thời gian thực và ngữ cảnh không gian.
Vì sao đúng
Đề nêu ba loại thông tin, và cả ba đều là dữ liệu địa điểm mà Google Maps duy trì sẵn:
⚠ Ghép từng yêu cầu:
"cửa hàng nào GẦN TÔI"
→ ⚠ ngữ cảnh KHÔNG GIAN
"mở khuya tối nay"
→ ⚠ GIỜ MỞ CỬA, kể cả giờ đặc biệt
"có lối vào cho xe lăn không"
→ ⚠ TIỆN ÍCH — Maps có trường này
"đánh giá của người dùng"
→ ⚠ Maps có sẵn
⚠ Câu quyết định của đề:
"WITHOUT MANUALLY UPDATING
this data across hundreds
of locations"
↓
⚠ Google Maps đã duy trì sẵn
→ chủ cửa hàng tự cập nhật
→ người dùng đóng góp
→ ⚠ không cần công ty tự nuôi dữ liệu
Vì sao các phương án khác sai
-
D (RAG với Vertex AI Search trên CSDL cửa hàng nội bộ) — ⚠ bẫy mạnh nhất, và trong hầu hết câu khác thì đây là đáp án đúng. Nhưng ở đây nó ⚠ đòi hỏi đúng thứ đề nói muốn tránh: tự duy trì và cập nhật dữ liệu hàng trăm địa điểm. Ngoài ra ⚠ CSDL nội bộ không có toạ độ người dùng, không có đánh giá, không xử lý được "gần tôi".
-
B (grounding bằng Google Search) — tốt cho thông tin web chung, nhưng ⚠ không có dữ liệu địa điểm CÓ CẤU TRÚC và không xử lý được truy vấn theo vị trí một cách chính xác.
-
C (fine-tune Gemini bằng dữ liệu cửa hàng lịch sử) — ⚠ sai về nguyên tắc: giờ mở cửa thay đổi liên tục, fine-tune thì đóng băng thông tin. Đề đòi "real-time" và "verifiable".
Ghi nhớ
⚠ Bốn cách grounding — bảng phải thuộc: | Cách | Nguồn | Dùng khi | |---|---|---| | ⚠ Google Maps | ⚠ dữ liệu ĐỊA ĐIỂM | ⚠ giờ mở, tiện ích, "gần tôi" — đề này | | Google Search | ⚠ web công khai | tin tức, sự kiện | | Vertex AI Search | ⚠ tài liệu NỘI BỘ | chính sách, tài liệu riêng | | Fine-tuning | ⚠ không phải grounding | phong cách, không phải sự thật |
Từ khoá nhận diện:
"gần tôi, giờ mở cửa, địa chỉ, tiện ích, đánh giá" → ⚠ Google Maps "tin tức, giá cổ phiếu, sự kiện mới" → Google Search "chính sách nội bộ, tài liệu công ty" → Vertex AI Search "không muốn tự cập nhật dữ liệu" → ⚠ dùng nguồn có sẵn được duy trì
| ⚠ Vì sao dữ liệu nội bộ thua ở đây | Lý do |
|---|---|
| ⚠ Phải tự cập nhật hàng trăm địa điểm | ⚠ chính điều đề muốn tránh |
| ⚠ Giờ lễ tết, giờ đặc biệt hay bị quên | |
| ⚠ Không có đánh giá người dùng | |
| Không có xử lý khoảng cách | ⚠ "gần tôi" cần dữ liệu địa lý |
| Khi nào nội bộ vẫn cần | ⚠ tồn kho, giá, chương trình khuyến mãi riêng |
| ⚠ Kiến trúc thực tế nên kết hợp | Nguồn |
|---|---|
| ⚠ Maps | ⚠ vị trí, giờ mở, tiện ích |
| ⚠ Nội bộ | ⚠ tồn kho, giá, khuyến mãi |
| Hồ sơ khách | ⚠ cá nhân hoá |
| Nguyên tắc | ⚠ mỗi loại dữ liệu lấy từ NGUỒN CHÍNH THỨC của nó |
| ⚠ Lưu ý về vị trí người dùng | Lưu ý |
|---|---|
| ⚠ Vị trí là dữ liệu NHẠY CẢM | ⚠ phải xin phép rõ ràng |
| ⚠ Cho phép nhập tay thay vì bật GPS | |
| Đừng lưu lịch sử di chuyển nếu không cần | |
| ⚠ Thông tin tiếp cận phải chính xác | ⚠ người khuyết tật ra quyết định dựa vào nó |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giờ mở cửa trên Maps có đúng không | ⚠ doanh nghiệp phải tự cập nhật hồ sơ Maps | | Thông tin tiếp cận có đầy đủ không | ⚠ thiếu thì bổ sung vào hồ sơ địa điểm | | Bot có nói rõ nguồn không | ⚠ để khách kiểm chứng được |
Và bài học kiến trúc rút ra: chọn nguồn grounding theo việc AI DUY TRÌ dữ liệu đó, không theo việc dữ liệu đó thuộc về ai. Cửa hàng là của công ty, nhưng giờ mở cửa được cập nhật chuẩn hơn ở nơi khách hàng thật sự tra cứu.
A company is launching a project to fine-tune an image generation model. The project requires a central location to store several terabytes of source images. The data science team needs a highly scalable and durable solution to hold these unstructured files, which will be the source for their Vertex AI training jobs.
Which Google Cloud service is designed for this specific purpose of storing large-scale object data like image files?
-
A
Vertex AI Model Registry
-
B
Cloud Storage
-
C
Cloud SQL
-
D
BigQuery
Xem giải thích
Đáp án
B — Cloud Storage.
Vì sao đúng
Đề nêu ba đặc điểm và cả ba đều chỉ về lưu trữ đối tượng:
⚠ Ghép từng đặc điểm:
"vài TERABYTE ảnh nguồn"
→ ⚠ quy mô lớn
"tệp PHI CẤU TRÚC"
→ ⚠ ảnh, video, âm thanh
→ ⚠ object storage
"nguồn cho job huấn luyện
Vertex AI"
→ ⚠ Vertex AI đọc THẲNG
từ Cloud Storage
⚠ Vì sao Cloud Storage là chuẩn:
⚠ Không giới hạn dung lượng thực tế
⚠ Độ bền rất cao — nhiều bản sao
⚠ Nhiều hạng lưu trữ theo tần suất
⚠ Đọc song song từ nhiều máy
→ ⚠ đúng thứ huấn luyện cần
Vì sao các phương án khác sai
-
D (BigQuery) — kho dữ liệu PHÂN TÍCH cho dữ liệu CÓ CẤU TRÚC (bảng, SQL). ⚠ Nó dùng để phân tích siêu dữ liệu về ảnh, không phải để chứa tệp ảnh.
-
C (Cloud SQL) — CSDL quan hệ, ⚠ hoàn toàn sai công cụ cho vài terabyte tệp nhị phân. Nhét ảnh vào cột BLOB là chống chỉ định kinh điển.
-
A (Vertex AI Model Registry) — quản lý PHIÊN BẢN MÔ HÌNH đã huấn luyện, không phải dữ liệu huấn luyện. ⚠ Nhầm giữa "nơi chứa mô hình" và "nơi chứa dữ liệu" là bẫy quen thuộc.
Ghi nhớ
⚠ Chọn kho dữ liệu theo loại — bảng phải thuộc: | Loại dữ liệu | Dịch vụ | |---|---| | ⚠ Tệp phi cấu trúc — ảnh, video, âm thanh | ⚠ Cloud Storage — đề này | | Phân tích có cấu trúc, SQL quy mô lớn | ⚠ BigQuery | | Giao dịch quan hệ | ⚠ Cloud SQL, AlloyDB | | NoSQL độ trễ thấp | ⚠ Firestore, Bigtable | | Mô hình đã huấn luyện | ⚠ Model Registry | | Đặc trưng ML | ⚠ Feature Store |
Từ khoá nhận diện:
"terabyte, ảnh, tệp, phi cấu trúc, object" → ⚠ Cloud Storage "truy vấn SQL, phân tích, báo cáo" → BigQuery "giao dịch, khoá ngoại" → Cloud SQL "phiên bản mô hình" → Model Registry
| ⚠ Hạng lưu trữ Cloud Storage | Hạng |
|---|---|
| ⚠ Standard | ⚠ truy cập thường xuyên — dữ liệu đang huấn luyện |
| Nearline | ⚠ khoảng một lần mỗi tháng |
| Coldline | ⚠ một lần mỗi quý |
| ⚠ Archive | ⚠ lưu trữ lâu dài, lấy ra tốn phí |
| Mẹo | ⚠ đặt quy tắc vòng đời tự chuyển hạng |
| ⚠ Lưu ý khi lưu dữ liệu huấn luyện | Lưu ý |
|---|---|
| ⚠ Đặt bucket CÙNG VÙNG với job huấn luyện | ⚠ khác vùng vừa chậm vừa tốn phí ra mạng |
| ⚠ Tổ chức thư mục theo tập train/val/test | |
| ⚠ Bucket phải RIÊNG TƯ | ⚠ ảnh nguồn có thể có bản quyền hoặc dữ liệu người |
| Ghi phiên bản dữ liệu | ⚠ để tái hiện được kết quả huấn luyện |
| ⚠ Đừng để hàng triệu tệp nhỏ | ⚠ gộp thành shard đọc nhanh hơn nhiều |
| ⚠ Riêng dữ liệu ảnh để fine-tune | Lưu ý |
|---|---|
| ⚠ Kiểm quyền sử dụng từng ảnh | ⚠ rủi ro bản quyền là rủi ro pháp lý thật |
| ⚠ Gỡ ảnh có người nhận diện được | ⚠ hoặc phải có đồng ý |
| Kiểm tính đa dạng của tập ảnh | ⚠ thiên lệch hình ảnh rất dễ lọt |
| ⚠ Lưu siêu dữ liệu nguồn gốc | ⚠ để gỡ được khi có khiếu nại |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket có cùng vùng với job không | ⚠ ảnh hưởng lớn tới tốc độ và chi phí | | Bucket có công khai nhầm không | ⚠ kiểm quyền truy cập | | Quy tắc vòng đời đã đặt chưa | ⚠ vài TB để hạng Standard mãi là tốn tiền |
Và nguyên tắc chọn kho lưu trữ dễ nhớ nhất: dữ liệu có hàng và cột thì vào BigQuery hoặc CSDL; dữ liệu là TỆP thì vào Cloud Storage. Ảnh, video, âm thanh, tài liệu PDF — tất cả đều là tệp.
A company has successfully deployed a new generative AI agent that helps customers book appointments. The business is critically dependent on this agent's reliability. They need an automated way to be notified if the agent starts experiencing a high rate of failures (e.g., errors when calling an external API) or if there is a sudden, abnormal spike in traffic that could indicate a malicious attack or a runaway process.
Which Google Cloud service is used to track these key operational metrics and trigger automated alerts?
-
A
Cloud Logging
-
B
Security Command Center
-
C
Cloud Audit Logs
-
D
Cloud Monitoring
Xem giải thích
Đáp án
D — Cloud Monitoring.
Vì sao đúng
Đề nêu hai nhu cầu, và cả hai là định nghĩa của giám sát chỉ số + cảnh báo:
⚠ Ghép hai nhu cầu:
"tỷ lệ lỗi CAO khi gọi API bên ngoài"
→ ⚠ CHỈ SỐ tỷ lệ lỗi
→ ⚠ vượt NGƯỠNG thì báo
"đột biến bất thường về lưu lượng"
→ ⚠ CHỈ SỐ số request
→ ⚠ tăng đột ngột thì báo
"automated way to be NOTIFIED"
→ ⚠ ALERTING POLICY
⚠ Phân biệt bốn dịch vụ quan sát:
⚠ Cloud Monitoring
→ ⚠ CHỈ SỐ theo thời gian + CẢNH BÁO
→ "tỷ lệ lỗi 5 phút qua là bao nhiêu"
Cloud Logging
→ ⚠ BẢN GHI SỰ KIỆN
→ "lỗi lúc 14:03 nội dung gì"
Cloud Audit Logs
→ ⚠ AI làm gì trên tài nguyên
→ "ai xoá cái này"
Security Command Center
→ ⚠ tư thế bảo mật, lỗ hổng
Vì sao các phương án khác sai
-
A (Cloud Logging) — ⚠ bẫy mạnh nhất vì log chứa thông tin lỗi. Nhưng log là văn bản sự kiện, còn đề cần ⚠ theo dõi TỶ LỆ và bắn cảnh báo tự động. Thực tế hai thứ dùng chung: ⚠ tạo log-based metric rồi Monitoring mới cảnh báo được.
-
C (Cloud Audit Logs) — ghi lại thao tác quản trị (ai tạo, ai xoá, ai đổi quyền). ⚠ Không phải nơi theo dõi sức khoẻ vận hành của ứng dụng.
-
B (Security Command Center) — quản lý rủi ro và lỗ hổng bảo mật ở mức tài nguyên đám mây. ⚠ Không phải công cụ cảnh báo tỷ lệ lỗi ứng dụng. Đề có nhắc "tấn công", nhưng cách phát hiện được mô tả là đột biến lưu lượng — đó là chỉ số vận hành.
Ghi nhớ
⚠ Bốn trụ quan sát — bảng phải thuộc: | Trụ | Trả lời | |---|---| | ⚠ Metrics (Monitoring) | ⚠ "có gì bất thường không" — đề này | | Logs (Logging) | ⚠ "chuyện gì đã xảy ra" | | Traces | ⚠ "chậm ở bước nào" | | ⚠ Audit Logs | ⚠ "ai đã làm gì" |
Từ khoá nhận diện:
"tỷ lệ, ngưỡng, cảnh báo tự động, đột biến" → ⚠ Cloud Monitoring "xem nội dung lỗi cụ thể" → Cloud Logging "ai đã thay đổi cấu hình" → Audit Logs "lỗ hổng, cấu hình sai bảo mật" → Security Command Center
| ⚠ Chỉ số nên theo dõi cho một agent | Chỉ số |
|---|---|
| ⚠ Tỷ lệ lỗi khi gọi công cụ | ⚠ đề này |
| ⚠ Lưu lượng request | ⚠ đột biến = tấn công hoặc vòng lặp vô hạn |
| Độ trễ p50 / p95 / p99 | |
| ⚠ Chi phí token mỗi giờ | ⚠ vòng lặp chạy loạn đốt tiền rất nhanh |
| Tỷ lệ chuyển sang người thật | ⚠ chỉ số chất lượng |
| ⚠ Tỷ lệ bị chặn bởi bộ lọc an toàn |
| ⚠ Vì sao "đột biến lưu lượng" đáng cảnh báo | Lý do |
|---|---|
| ⚠ Có thể là tấn công dò tìm | |
| ⚠ Có thể là vòng lặp vô hạn của chính agent | ⚠ agent gọi công cụ, công cụ gọi lại agent |
| ⚠ Chi phí tăng theo cấp số nhân | |
| Có thể là chiến dịch marketing thành công | ⚠ cũng cần biết để mở rộng kịp |
| ⚠ Đặt cảnh báo cho đúng | Nguyên tắc |
|---|---|
| ⚠ Cảnh báo phải HÀNH ĐỘNG ĐƯỢC | ⚠ không thì chỉ gây nhiễu |
| ⚠ Quá nhiều cảnh báo = không ai đọc | ⚠ mệt mỏi cảnh báo là rủi ro thật |
| Đặt ngưỡng theo đường nền thật | ⚠ quan sát trước rồi mới đặt |
| ⚠ Ghi rõ ai trực và làm gì khi có cảnh báo |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cảnh báo có thật sự tới người trực không | ⚠ thử bắn một cảnh báo giả | | Ngưỡng có hợp lý với lưu lượng thật không | ⚠ quan sát vài tuần rồi chỉnh | | Có cảnh báo cho CHI PHÍ chưa | ⚠ thường bị quên cho tới khi nhận hoá đơn |
Và điều hay bị bỏ sót nhất khi vận hành agent: cảnh báo về chi phí token quan trọng ngang cảnh báo về lỗi. Một agent rơi vào vòng lặp gọi công cụ có thể tiêu hết ngân sách tháng trong vài giờ mà mọi chỉ số kỹ thuật vẫn báo "khoẻ mạnh".
A healthcare technology company is building a mobile application for doctors. The app must allow doctors to record spoken notes and have them instantly summarized. Due to strict patient data privacy regulations and the need for the app to function in hospitals with unreliable Wi-Fi, all audio processing and summarization must happen entirely on the mobile device. The data cannot leave the device.
Which Google foundation model is specifically designed to meet this strict on-device deployment requirement?
-
A
Gemma
-
B
Gemini Pro
-
C
Imagen
-
D
Veo
Xem giải thích
Đáp án
A — Gemma.
Vì sao đúng
Đề nêu hai ràng buộc cứng và cả hai đều đòi mô hình chạy trên thiết bị:
⚠ Hai ràng buộc:
"quy định bảo mật dữ liệu bệnh nhân
nghiêm ngặt"
→ ⚠ dữ liệu KHÔNG được rời máy
"Wi-Fi bệnh viện chập chờn"
→ ⚠ phải chạy được KHI MẤT MẠNG
"entirely ON-DEVICE"
→ ⚠ đề nói thẳng
⚠ Gemma là gì:
⚠ Họ mô hình MỞ, NHẸ của Google
⚠ Cùng nghiên cứu nền với Gemini
⚠ Nhiều cỡ nhỏ — chạy được trên
điện thoại, laptop, máy chủ riêng
⚠ Tải trọng số về, chạy hoàn toàn
cục bộ
Vì sao các phương án khác sai
-
B (Gemini Pro) — ⚠ bẫy mạnh nhất vì đây là mô hình mạnh nhất. Nhưng nó ⚠ chạy trên đám mây, gọi qua API — nghĩa là ⚠ dữ liệu bệnh nhân PHẢI rời khỏi thiết bị, vi phạm thẳng ràng buộc, và mất mạng là không dùng được.
-
C (Imagen) — ⚠ sinh ẢNH, không xử lý âm thanh hay tóm tắt văn bản. Sai hoàn toàn loại việc.
-
D (Veo) — ⚠ sinh VIDEO. Cũng sai loại việc.
⚠ Mẹo: hai phương án C và D bị loại chỉ bằng cách nhớ đầu ra của từng sản phẩm, không cần biết gì về chạy trên thiết bị.
Ghi nhớ
⚠ Gemini khác Gemma — bảng phải thuộc: | Tiêu chí | Gemini | ⚠ Gemma | |---|---|---| | Dạng | ⚠ đóng, gọi qua API | ⚠ MỞ, tải trọng số về | | Nơi chạy | ⚠ đám mây Google | ⚠ BẤT KỲ ĐÂU — thiết bị, máy chủ riêng | | Cỡ | lớn, mạnh nhất | ⚠ nhẹ, nhiều cỡ nhỏ | | Dữ liệu | ⚠ gửi lên đám mây | ⚠ KHÔNG rời thiết bị | | Ngoại tuyến | ⚠ không | ⚠ CÓ |
Từ khoá nhận diện:
"on-device, offline, dữ liệu không rời thiết bị" → ⚠ Gemma "chủ quyền dữ liệu tuyệt đối, tự vận hành" → ⚠ Gemma hoặc mô hình mở "cần năng lực mạnh nhất" → Gemini "sinh ảnh / video" → Imagen / Veo
| ⚠ Vì sao chạy trên thiết bị lại quan trọng | Lý do |
|---|---|
| ⚠ Riêng tư tuyệt đối | ⚠ không có đường rò rỉ qua mạng |
| ⚠ Hoạt động khi mất mạng | |
| ⚠ Độ trễ thấp | ⚠ không có vòng đi về máy chủ |
| Không tốn phí mỗi lần gọi | |
| ⚠ Tuân thủ dễ hơn | ⚠ dữ liệu không rời tổ chức |
| ⚠ Cái giá của chạy trên thiết bị | Cái giá |
|---|---|
| ⚠ Mô hình nhỏ hơn → năng lực kém hơn | |
| ⚠ Tốn pin và bộ nhớ điện thoại | |
| ⚠ Cập nhật mô hình phải phát hành lại ứng dụng | |
| Khác biệt giữa các dòng máy | ⚠ máy yếu chạy chậm |
| ⚠ Trách nhiệm bảo mật mô hình là của bạn |
| ⚠ Riêng ghi chú y tế — bắt buộc | Yêu cầu |
|---|---|
| ⚠ Bác sĩ PHẢI duyệt bản tóm tắt | ⚠ tóm tắt sai là rủi ro lâm sàng |
| ⚠ Giữ bản ghi âm gốc | ⚠ để đối chiếu khi cần |
| Thuật ngữ y khoa và tên thuốc dễ nghe nhầm | ⚠ kiểm kỹ liều lượng |
| ⚠ Mã hoá dữ liệu trên chính thiết bị | ⚠ mất điện thoại vẫn là rủi ro |
| Xoá được từ xa |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có gói tin nào rời thiết bị không | ⚠ kiểm bằng cách bật chế độ máy bay | | Tên thuốc và liều có đúng không | ⚠ đối chiếu bản ghi âm | | Thiết bị mất thì dữ liệu ra sao | ⚠ mã hoá và xoá từ xa |
Và cách chắc nhất để nhận ra nhóm câu này: cụm "dữ liệu không được rời thiết bị" chỉ có một họ đáp án. Mọi mô hình gọi qua API đều bị loại ngay lập tức, bất kể chúng mạnh tới đâu.
A toy company uses a generative AI model to create short, happy stories for its website. The marketing team has found that the model sometimes includes scary monsters or sad endings to make the stories more dramatic. To protect the company's family-friendly brand image, this must be prevented.
Which prompting technique is specifically designed to instruct the model on what themes and elements to avoid?
-
A
Zero-shot prompting
-
B
Few-shot prompting
-
C
Providing explicit constraints or negative instructions
-
D
Chain-of-thought prompting
Xem giải thích
Đáp án
C — Đưa ràng buộc tường minh hoặc chỉ dẫn phủ định.
Vì sao đúng
Đề hỏi kỹ thuật được thiết kế riêng để dặn mô hình TRÁNH điều gì. Đó chính là ràng buộc trong prompt.
⚠ Cách viết trong đề này:
Thay vì:
"Viết một câu chuyện vui
cho trẻ em"
⚠ Thêm ràng buộc:
"Viết một câu chuyện vui
cho trẻ em.
⚠ KHÔNG có quái vật đáng sợ.
⚠ KHÔNG có kết thúc buồn.
⚠ Kết thúc phải có hậu."
⚠ Vì sao cần nói ra:
⚠ Mô hình học từ văn học nói chung
⚠ Kịch tính là mẫu hình PHỔ BIẾN
trong truyện
↓
⚠ Không cấm thì nó theo mẫu chung
⚠ Ràng buộc THU HẸP không gian
đầu ra
Vì sao các phương án khác sai
-
B (few-shot prompting) — ⚠ bẫy mạnh nhất và là kỹ thuật BỔ TRỢ rất tốt: cho vài truyện mẫu đúng phong cách thì mô hình bắt chước. Nhưng few-shot dạy cái NÊN làm, không nêu rõ cái CẤM. Đề hỏi kỹ thuật chuyên cho việc tránh — đó là ràng buộc.
-
A (zero-shot prompting) — chỉ có nghĩa là hỏi thẳng không có ví dụ. Nó nói về có ví dụ hay không, không nói gì về ràng buộc.
-
D (chain-of-thought) — buộc mô hình trình bày các bước suy luận, dùng cho bài toán logic, toán, suy luận nhiều bước. ⚠ Không liên quan tới việc kiểm soát chủ đề nội dung.
Ghi nhớ
⚠ Các kỹ thuật prompt và việc của chúng — bảng phải thuộc: | Kỹ thuật | Dùng để | |---|---| | ⚠ Ràng buộc / chỉ dẫn phủ định | ⚠ nói rõ cái phải TRÁNH — đề này | | Zero-shot | ⚠ hỏi thẳng, không ví dụ | | Few-shot | ⚠ cho ví dụ để bắt chước | | Chain-of-thought | ⚠ suy luận từng bước | | Role prompting | ⚠ gán vai | | ReAct | ⚠ suy nghĩ + dùng công cụ |
Từ khoá nhận diện:
"avoid, do not, không được, tránh" → ⚠ ràng buộc/chỉ dẫn phủ định "đây là vài ví dụ mẫu" → few-shot "hãy suy nghĩ từng bước" → chain-of-thought "đóng vai…" → role prompting
| ⚠ Viết ràng buộc sao cho hiệu quả | Cách |
|---|---|
| ⚠ CỤ THỂ, đừng chung chung | ⚠ "không có quái vật, không kết buồn" hơn "hãy phù hợp trẻ em" |
| ⚠ Nêu cả cái NÊN làm | ⚠ chỉ cấm thì mô hình không biết đi hướng nào |
| Đặt ràng buộc gần cuối prompt | ⚠ phần cuối thường được chú ý hơn |
| ⚠ Kết hợp few-shot | ⚠ ví dụ đúng + ràng buộc rõ = mạnh nhất |
| Giới hạn | ⚠ ràng buộc KHÔNG phải cơ chế an toàn |
| ⚠ Ràng buộc prompt không thay được bộ lọc | Lý do |
|---|---|
| ⚠ Prompt có thể bị bỏ qua | ⚠ nhất là với đầu vào dài hoặc bị tiêm |
| ⚠ Không kiểm chứng được | |
| ⚠ Nội dung cho trẻ em phải có lớp lọc thật | ⚠ safety filter + người duyệt |
| Nguyên tắc | ⚠ prompt là hướng dẫn, filter mới là rào chắn |
| ⚠ Riêng nội dung cho trẻ em | Lưu ý |
|---|---|
| ⚠ NGƯỜI phải duyệt trước khi đăng | ⚠ không có ngoại lệ |
| ⚠ Bật bộ lọc an toàn ở mức chặt | |
| Kiểm cả hình minh hoạ | ⚠ nếu sinh ảnh kèm theo |
| ⚠ Quy định quảng cáo hướng tới trẻ em rất chặt | ⚠ nhiều nước có luật riêng |
| Ghi rõ nội dung do AI tạo |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ràng buộc có được tuân thủ không | ⚠ sinh 50 truyện rồi rà, đừng thử 2 lần rồi kết luận | | Có lớp lọc ngoài prompt chưa | ⚠ prompt một mình là không đủ | | Ai duyệt trước khi lên website | ⚠ phải có tên cụ thể |
Và điều cần nhớ rõ ranh giới: ràng buộc trong prompt cải thiện tỷ lệ đúng, nó không đảm bảo. Với thương hiệu hướng tới gia đình thì tỷ lệ 95% vẫn là 5% số truyện có quái vật đáng sợ trên website — nên vẫn phải có người duyệt.
A large multinational corporation wants to provide all 50,000 employees across different departments (HR, Sales, Finance, IT) with a unified platform where they can:
-
Access pre-built AI agents like Deep Research and NotebookLM
-
Create their own custom AI agents using a no-code interface without IT involvement
-
Search across company data from multiple sources (SharePoint, Salesforce, Google Drive, Jira) with a single search interface
-
Ensure centralized governance, security controls, and audit trails for all AI agent usage
-
Deploy agents built by their developers from Vertex AI into a managed environment
-
The company needs an enterprise-grade solution that serves as the "front door" for AI at work, where employees can discover, share, and run agents while IT maintains full visibility and control.
Which Google Cloud offering provides this comprehensive agentic platform?
-
A
Vertex AI Agent Builder
-
B
Gemini Enterprise
-
C
Agent Development Kit (ADK)
-
D
Vertex AI Search
Xem giải thích
Đáp án
B — Gemini Enterprise.
Vì sao đúng
Đề liệt kê năm nhu cầu và chỉ một sản phẩm gói được cả năm dưới dạng nền tảng cho toàn bộ 50.000 nhân viên:
⚠ Ghép từng nhu cầu:
"agent dựng sẵn — Deep Research,
NotebookLM"
→ ⚠ danh mục có sẵn
"tự tạo agent KHÔNG CẦN CODE,
không cần IT"
→ ⚠ giao diện no-code cho
người dùng nghiệp vụ
"tìm kiếm xuyên SharePoint,
Salesforce, Drive, Jira"
→ ⚠ một cửa tìm kiếm doanh nghiệp
"quản trị tập trung, kiểm soát
bảo mật, lưu vết"
→ ⚠ tầng quản trị
"triển khai agent do lập trình viên
xây trên Vertex AI"
→ ⚠ NHẬN agent từ Vertex AI
⚠ Đề còn dùng đúng chữ "front door" — mặt tiền AI của doanh nghiệp, đó là định vị của Gemini Enterprise.
Vì sao các phương án khác sai
-
A (Vertex AI Agent Builder) — ⚠ bẫy mạnh nhất: nó xây agent rất tốt, nhưng là công cụ cho lập trình viên. ⚠ Nó không phải cổng vào cho 50.000 nhân viên nghiệp vụ, không có danh mục agent dựng sẵn cho người dùng cuối, không phải nơi quản trị tập trung mức doanh nghiệp. Chú ý đề nói agent xây trên Vertex AI được triển khai VÀO nền tảng cần tìm — nghĩa là Vertex AI là nguồn, không phải đáp án.
-
C (Agent Development Kit) — ⚠ bộ thư viện lập trình để viết agent bằng code. Càng kỹ thuật hơn, càng xa nhu cầu no-code.
-
D (Vertex AI Search) — chỉ giải quyết một trong năm nhu cầu (tìm kiếm liên nguồn). ⚠ Không tạo agent, không quản trị agent.
Ghi nhớ
⚠ Bốn sản phẩm và người dùng của chúng — bảng phải thuộc: | Sản phẩm | Ai dùng | |---|---| | ⚠ Gemini Enterprise | ⚠ TOÀN BỘ nhân viên — cổng vào AI — đề này | | Vertex AI Agent Builder | ⚠ lập trình viên XÂY agent | | ADK | ⚠ lập trình viên viết agent bằng CODE | | Vertex AI Search | ⚠ thành phần tìm kiếm |
Từ khoá nhận diện:
"toàn bộ nhân viên, front door, no-code, quản trị tập trung" → ⚠ Gemini Enterprise "xây agent gọi công cụ" → ⚠ Agent Builder "viết agent bằng Python" → ⚠ ADK "chỉ cần tìm trong tài liệu" → Vertex AI Search
| ⚠ Quan hệ giữa chúng — không loại trừ nhau | Quan hệ |
|---|---|
| ⚠ Lập trình viên xây agent bằng ADK / Agent Builder | |
| ⚠ Agent được TRIỂN KHAI vào Gemini Enterprise | |
| ⚠ Nhân viên dùng agent qua Gemini Enterprise | |
| Quản trị viên kiểm soát ở tầng Gemini Enterprise | |
| Vì thế | ⚠ đề hỏi "nền tảng cho toàn công ty" thì là tầng trên cùng |
| ⚠ Vì sao quản trị tập trung là điểm quyết định | Lý do |
|---|---|
| ⚠ 50.000 người tự tạo agent = rủi ro dữ liệu | |
| ⚠ Cần biết agent nào truy cập dữ liệu nào | |
| ⚠ Cần lưu vết để kiểm toán | |
| Cần thu hồi quyền khi nhân viên nghỉ | |
| Không có tầng này | ⚠ là "shadow AI" — AI ngoài tầm kiểm soát |
| ⚠ Rủi ro khi cho người dùng tự tạo agent | Rủi ro |
|---|---|
| ⚠ Agent truy cập dữ liệu vượt quyền người tạo | ⚠ phải kế thừa quyền của người dùng |
| ⚠ Agent trùng lặp, chất lượng kém | ⚠ cần quy trình duyệt và chia sẻ |
| Dữ liệu nhạy cảm bị đưa vào prompt | |
| ⚠ Không ai bảo trì agent do người đã nghỉ tạo |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có kế thừa đúng quyền người dùng không | ⚠ thử với tài khoản quyền thấp | | Có nhật ký ai dùng agent nào không | ⚠ yêu cầu kiểm toán | | Agent nào đang được dùng thật | ⚠ dọn agent bỏ hoang định kỳ |
Và cách phân biệt nhanh cả nhóm câu này: đề nói tới SỐ LƯỢNG NHÂN VIÊN và QUẢN TRỊ thì đang hỏi tầng nền tảng; đề nói tới việc XÂY một agent cụ thể thì đang hỏi tầng công cụ. Con số 50.000 trong đề bài không phải chi tiết trang trí.
A marketing manager needs to quickly rephrase existing advertising copy for different social media platforms. The goal is to create variations with different tones (e.g., professional, witty, urgent). The manager has no technical expertise and needs a solution that is immediately usable within their daily workflow without requiring any setup or knowledge of prompt engineering parameters.
Which generative AI solution best fits this business need?
-
A
An AutoML model trained on custom datasets to classify the sentiment of customer responses to previous ad campaigns.
-
B
Using Gemini's code generation capabilities in Vertex AI to build a custom web application for the marketing team.
-
C
Using Vertex AI Studio to experiment with Gemini models and adjust parameters like temperature and top-p for optimal creativity.
-
D
Gemini for Google Workspace integrated directly into their document or email application.
Xem giải thích
Đáp án
D — Gemini for Google Workspace tích hợp thẳng vào ứng dụng tài liệu hoặc email của họ.
Vì sao đúng
Đề nêu ba ràng buộc về người dùng, không phải về kỹ thuật:
⚠ Ghép từng ràng buộc:
"không có chuyên môn kỹ thuật"
→ ⚠ loại mọi thứ cần code
"dùng được NGAY trong luồng
công việc hằng ngày"
→ ⚠ ngay trong Docs/Gmail
"KHÔNG cần cài đặt, không cần
biết tham số prompt"
→ ⚠ loại Vertex AI Studio
⚠ Việc cần làm cũng rất nhẹ:
"viết lại lời quảng cáo theo
các giọng khác nhau"
→ ⚠ việc SINH VĂN BẢN cơ bản
→ ⚠ không cần mô hình tuỳ chỉnh
→ ⚠ không cần hạ tầng riêng
Vì sao các phương án khác sai
-
C (Vertex AI Studio, chỉnh temperature và top-p) — ⚠ bẫy mạnh nhất vì nó làm được việc và cho kết quả tốt. Nhưng đề nói thẳng người này ⚠ không cần biết tham số prompt — mà Studio chính là nơi để chỉnh những tham số đó. Sai người dùng.
-
B (dùng Gemini sinh code để xây một ứng dụng web riêng) — ⚠ quá mức cần thiết một cách rõ ràng: xây cả ứng dụng chỉ để viết lại vài câu quảng cáo, trong khi đội không có người kỹ thuật.
-
A (mô hình AutoML phân loại cảm xúc phản hồi khách hàng) — ⚠ sai hẳn loại việc: đó là phân loại, còn đề cần sinh văn bản. Phương án này giải một bài toán khác hoàn toàn.
Ghi nhớ
⚠ Chọn công cụ theo NGƯỜI DÙNG — bảng phải thuộc: | Người dùng | Công cụ | |---|---| | ⚠ Nhân viên nghiệp vụ, không kỹ thuật | ⚠ Gemini for Workspace — đề này | | Người có chút kỹ thuật, muốn thử prompt | ⚠ AI Studio / Vertex AI Studio | | Lập trình viên | ⚠ Gemini API, Vertex AI | | Nhà khoa học dữ liệu | ⚠ Workbench, AutoML, huấn luyện tuỳ chỉnh |
Từ khoá nhận diện:
"không kỹ thuật, ngay trong công việc, không cài đặt" → ⚠ Gemini for Workspace "thử prompt, chỉnh temperature" → Vertex AI Studio "tích hợp vào ứng dụng" → API "phân loại, dự đoán" → ⚠ AutoML — KHÔNG phải sinh văn bản
| ⚠ Vì sao "trong luồng công việc" quan trọng | Lý do |
|---|---|
| ⚠ Không phải đổi cửa sổ, đổi công cụ | ⚠ tỷ lệ dùng thật cao hơn hẳn |
| ⚠ Không phải copy dán qua lại | ⚠ giảm rủi ro rò rỉ dữ liệu |
| Không cần đào tạo nhiều | |
| ⚠ Quyền truy cập đã có sẵn | ⚠ không mở thêm bề mặt rủi ro |
| Bài học chung | ⚠ công cụ tốt mà không ai mở ra thì bằng không |
| ⚠ Việc marketing dùng Gemini for Workspace | Việc |
|---|---|
| ⚠ Viết lại theo giọng khác | ⚠ đề này |
| Rút gọn cho từng nền tảng | ⚠ giới hạn ký tự khác nhau |
| Soạn nháp email chiến dịch | |
| ⚠ Tóm tắt phản hồi trong tài liệu | |
| Lưu ý | ⚠ kết quả vẫn phải người duyệt |
| ⚠ Khi nào mới cần lên tầng cao hơn | Khi nào |
|---|---|
| ⚠ Cần tự động hoá hàng nghìn lượt | ⚠ thì mới cần API |
| ⚠ Cần giọng thương hiệu rất riêng, ổn định | ⚠ cân nhắc fine-tune |
| Cần lấy dữ liệu nội bộ vào nội dung | ⚠ cần RAG |
| Nguyên tắc | ⚠ đừng leo tầng khi chưa có nhu cầu thật |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nội dung có nói sai về sản phẩm không | ⚠ người duyệt trước khi đăng | | Giọng có đúng thương hiệu không | ⚠ so với bộ hướng dẫn thương hiệu | | Có dán dữ liệu khách hàng vào không | ⚠ dùng bản doanh nghiệp, không dùng công cụ ngoài |
Và tiêu chí chọn công cụ hay bị bỏ qua nhất: ai sẽ là người thực sự dùng nó hằng ngày. Một giải pháp mạnh hơn nhưng đòi người dùng học thêm và đổi thói quen thường thua một giải pháp vừa đủ nằm sẵn trong công cụ họ đã mở mỗi sáng.