Ngân hàng đề — Google Cloud Generative AI Leader
Tìm thấy 556 câu.
A company implements a wide range of technologies, including systems that can recognize images, understand human speech, make predictions based on data, and generate novel text summaries. The overarching field of computer science that aims to create machines capable of performing tasks that typically require human intelligence is known as:
-
A
Cloud Computing
-
B
Artificial Intelligence (AI)
-
C
Database Management
-
D
Data Science
Xem giải thích
Đáp án
B — Artificial Intelligence (AI) — trí tuệ nhân tạo.
Vì sao đúng
Đề mô tả lĩnh vực khoa học máy tính bao trùm, nhằm tạo ra máy móc thực hiện được những việc thường đòi hỏi trí tuệ con người — nhận diện ảnh, hiểu tiếng nói, dự đoán, sinh văn bản.
⚠ Bản đồ khái niệm — quan hệ bao hàm:
⚠ AI — rộng nhất
⚠ mọi kỹ thuật làm máy "thông minh"
│
├─ ⚠ MACHINE LEARNING
│ ⚠ học từ DỮ LIỆU
│ │
│ ├─ ⚠ DEEP LEARNING
│ │ ⚠ mạng nơ-ron nhiều lớp
│ │ │
│ │ └─ ⚠ GENERATIVE AI
│ │ ⚠ TẠO nội dung mới
│ │
│ └─ ML truyền thống
│
└─ ⚠ Hệ chuyên gia dựa trên LUẬT
⚠ AI nhưng KHÔNG học từ dữ liệu
⚠ Vì sao ba phương án kia sai:
"Data Science"
→ ⚠ rút hiểu biết từ dữ liệu;
⚠ GIAO NHAU với AI nhưng không
phải cùng một thứ
"Cloud Computing"
→ ⚠ mô hình cung cấp tài nguyên
tính toán
"Database Management"
→ ⚠ quản lý lưu trữ dữ liệu
Nhất quán với #13910 (lô 146) về NLP và #13926 (lô 146) về Generative AI. Ba đề cùng vẽ bản đồ khái niệm, mỗi đề một vị trí. Hoàn toàn nhất quán.
Vì sao các phương án khác sai
-
D (Data Science) — phương án gần nhất và là bẫy chính: hai lĩnh vực giao nhau và cùng làm việc với dữ liệu. Nhưng khoa học dữ liệu hướng tới rút hiểu biết, còn AI hướng tới tạo máy có năng lực như trí tuệ.
-
A và C — thuộc hạ tầng và quản trị dữ liệu.
Ghi nhớ
⚠ Bản đồ khái niệm — bảng phải thuộc: | Khái niệm | Định nghĩa | |---|---| | ⚠ AI | ⚠ máy làm việc đòi hỏi trí tuệ — RỘNG NHẤT | | ⚠ Machine Learning | ⚠ tập con — HỌC TỪ DỮ LIỆU | | ⚠ Deep Learning | ⚠ tập con của ML — mạng nơ-ron sâu | | ⚠ Generative AI | ⚠ TẠO nội dung mới | | NLP | ⚠ lĩnh vực về ngôn ngữ | | Data Science | ⚠ rút hiểu biết từ dữ liệu — GIAO với AI | | AGI | ⚠ giả thuyết, CHƯA tồn tại |
Từ khoá nhận diện:
"lĩnh vực bao trùm, như trí tuệ con người" → ⚠ AI "học từ dữ liệu" → Machine Learning "tạo nội dung mới" → Generative AI "rút hiểu biết, phân tích, thống kê" → ⚠ Data Science
| ⚠ Bốn ví dụ trong đề thuộc đâu | Ví dụ |
|---|---|
| Nhận diện ảnh | ⚠ deep learning, computer vision |
| Hiểu tiếng nói | ⚠ speech recognition + NLP |
| Dự đoán từ dữ liệu | ⚠ ML truyền thống |
| ⚠ Sinh tóm tắt mới | ⚠ generative AI |
| Điểm chung | ⚠ tất cả đều thuộc AI |
| ⚠ AI không nhất thiết phải học từ dữ liệu | Điểm |
|---|---|
| ⚠ Hệ chuyên gia dựa trên LUẬT | ⚠ là AI, nhưng KHÔNG phải ML |
| Thuật toán tìm kiếm, lập kế hoạch | ⚠ AI cổ điển |
| Vì vậy | ⚠ AI ⊃ ML, không phải AI = ML |
| Đề thi | ⚠ hay kiểm tra đúng quan hệ bao hàm này |
| ⚠ AI hẹp và AGI | Phân biệt |
|---|---|
| ⚠ AI hẹp (narrow AI) | ⚠ giỏi MỘT loại việc — mọi AI hiện nay |
| ⚠ AGI | ⚠ năng lực tổng quát như người — CHƯA CÓ |
| LLM rất mạnh | ⚠ nhưng vẫn là AI hẹp |
| Trong đề thi | ⚠ phương án nhắc AGI gần như luôn SAI |
Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Hệ thống có học từ dữ liệu không | có → ML | | Nó tạo nội dung mới hay dự đoán | ⚠ tạo → generative AI | | Có phải mạng nơ-ron nhiều lớp không | → deep learning |
Và quan hệ đáng nhớ nhất trong bản đồ này là quan hệ bao hàm: AI chứa machine learning, machine learning chứa deep learning, và AI sinh nằm bên trong cùng. Nhiều câu hỏi chỉ đơn giản kiểm tra xem thí sinh có nhớ đúng thứ tự lồng nhau đó hay không.
A company wants to leverage generative AI but is cautious about being locked into a single vendor's proprietary models. They prefer a cloud platform that supports and integrates with popular open-source AI frameworks and allows them to use a variety of open models.
This preference aligns with which benefit of Google Cloud's gen AI offerings?
-
A
Its highly optimized custom hardware (TPUs).
-
B
Its open approach, supporting flexibility and choice in models and tools.
-
C
Its comprehensive security and compliance certifications.
-
D
Its fully managed, turnkey AI solutions.
Xem giải thích
Đáp án
B — Cách tiếp cận mở, hỗ trợ tính linh hoạt và quyền lựa chọn về mô hình và công cụ.
Vì sao đúng
Công ty lo bị khoá chân vào mô hình độc quyền của một hãng, muốn nền tảng hỗ trợ framework AI mã nguồn mở và dùng được nhiều mô hình mở. Đó chính là trụ cột "mở".
⚠ Tính mở thể hiện ở đâu:
⚠ MÔ HÌNH MỞ
→ Gemma
→ ⚠ Model Garden có mô hình mở
của bên thứ ba
⚠ FRAMEWORK MỞ
→ ⚠ TensorFlow, PyTorch, JAX
đều chạy trên Vertex AI
⚠ HẠ TẦNG MỞ
→ Kubernetes, container
⚠ QUYỀN LỰA CHỌN
→ ⚠ không bị buộc dùng một
mô hình duy nhất
⚠ Vì sao ba phương án kia sai:
"TPU tối ưu riêng"
→ ⚠ về HIỆU NĂNG, và nghe
hướng tới độc quyền
"Chứng nhận bảo mật và tuân thủ"
→ ⚠ về mối lo DỮ LIỆU
"Giải pháp AI trọn gói, có quản lý
hoàn toàn"
→ ⚠ tiện nhưng ÍT linh hoạt —
ngược với điều họ ưu tiên
⚠ Gần trùng với #13933 (lô 146) — đề đó là viện nghiên cứu muốn dùng công cụ mã nguồn mở cùng dịch vụ độc quyền, cùng khoá. Và #13557/#13566 (lô 144). Hoàn toàn nhất quán.
Vì sao các phương án khác sai
-
D (giải pháp trọn gói) — phương án gần nhất về mặt "cũng là điểm mạnh thật", nhưng giải pháp đóng gói sẵn thường tăng mức phụ thuộc chứ không giảm.
-
A và C — trả lời cho mối lo hiệu năng và tuân thủ.
Ghi nhớ
⚠ Sáu điểm mạnh nền tảng — ghép đúng mối lo: | Mối lo | Điểm mạnh | |---|---| | ⚠ Khoá chân, muốn chọn mô hình | ⚠ cách tiếp cận MỞ | | Dữ liệu nhạy cảm | bảo mật, quyền riêng tư | | Tải lớn, uptime | scalability, reliability | | Muốn công nghệ mới nhất | AI-first | | Gắn với đầu tư sẵn có | hệ sinh thái tích hợp | | Quản trị rủi ro AI | SAIF |
Từ khoá nhận diện:
"mã nguồn mở, linh hoạt, quyền chọn" → ⚠ cách tiếp cận mở "chip do Google thiết kế" → TPU "chứng nhận tuân thủ" → bảo mật doanh nghiệp "dùng ngay, không phải xây" → ⚠ giải pháp trọn gói
| ⚠ Model Garden thể hiện tính mở thế nào | Điểm |
|---|---|
| ⚠ Có mô hình của Google | Gemini, Imagen, Veo |
| ⚠ Có mô hình MỞ | ⚠ Gemma và mô hình cộng đồng |
| Có mô hình bên thứ ba | |
| ⚠ Cùng một nơi để so sánh và triển khai | |
| Lợi ích | ⚠ đổi mô hình mà không đổi hạ tầng |
| ⚠ Thiết kế để đổi mô hình dễ dàng | Cách |
|---|---|
| ⚠ Tách lớp gọi mô hình khỏi logic nghiệp vụ | ⚠ quan trọng nhất |
| ⚠ Có bộ test cố định | ⚠ để so mô hình mới với mô hình cũ |
| Ghi lại prompt và tham số theo phiên bản | |
| ⚠ Đừng nhét logic vào prompt quá sâu | |
| Kết quả | ⚠ đổi mô hình là việc vài ngày, không phải vài tháng |
| ⚠ Đánh đổi thực tế | Đánh đổi |
|---|---|
| ⚠ Mô hình mở: kiểm soát cao, tự vận hành nhiều | |
| Mô hình độc quyền qua API: tiện, năng lực cao | |
| ⚠ Cách thực dụng | ⚠ lõi mở, ngoại vi dùng dịch vụ có quản lý |
| Ví dụ | ⚠ container + Terraform + định dạng dữ liệu mở |
Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đổi mô hình tốn bao lâu | ⚠ phép thử thật cho tính linh hoạt | | Có bộ test để so mô hình không | ⚠ thiếu thì không dám đổi | | Phần nào đang phụ thuộc sâu | ⚠ biết để cân nhắc |
Và phép thử thực chất cho mọi tuyên bố về tính linh hoạt: thử đổi sang một mô hình khác và đo xem mất bao lâu. Một kiến trúc tách lớp tốt sẽ trả lời bằng vài ngày; nếu câu trả lời là vài tháng, thì mức khoá chân đã cao hơn những gì sơ đồ hệ thống thể hiện.
A data scientist builds a system that analyzes historical sales data to predict future sales figures for different products. Another team in the same company builds a system that writes entirely new, unique marketing slogans for those products.
Which statement best describes the relationship between Machine Learning (ML) and Generative AI in the context of these two systems?
-
A
Both systems are examples of Generative AI, but only the slogan writer uses Machine Learning.
-
B
Machine Learning is a subset of Generative AI; the sales predictor is ML, and the slogan writer is Generative AI.
-
C
Machine Learning and Generative AI are entirely separate fields with no overlap.
-
D
Generative AI is a specific application or subfield of Machine Learning; the sales predictor uses ML for prediction, and the slogan writer uses a generative form of ML to create new content.
Xem giải thích
Đáp án
D — Generative AI là một ứng dụng hoặc nhánh cụ thể của Machine Learning; hệ dự báo doanh số dùng ML để dự đoán, còn hệ viết khẩu hiệu dùng một dạng ML mang tính sinh để tạo ra nội dung mới.
Vì sao đúng
Quan hệ đúng là bao hàm: AI sinh nằm bên trong machine learning, không phải ngược lại và cũng không tách rời.
⚠ Hai hệ thống trong đề:
⚠ HỆ DỰ BÁO DOANH SỐ
→ ⚠ ML dự đoán (predictive)
→ đầu ra là một CON SỐ
→ hồi quy
⚠ HỆ VIẾT KHẨU HIỆU
→ ⚠ ML dạng SINH (generative)
→ đầu ra là NỘI DUNG MỚI
↓
⚠ CẢ HAI đều là machine learning
⚠ chỉ khác LOẠI ĐẦU RA
⚠ Quan hệ bao hàm đúng:
⚠ AI
⊃ ⚠ MACHINE LEARNING
⊃ ⚠ DEEP LEARNING
⊃ ⚠ GENERATIVE AI
⚠ Vì sao ba phương án kia sai:
"ML là tập con của Generative AI"
→ ⚠ ĐẢO NGƯỢC quan hệ
"Hai lĩnh vực HOÀN TOÀN TÁCH RỜI"
→ ⚠ sai: AI sinh chính là ML
"CẢ HAI đều là Generative AI, nhưng
chỉ hệ viết khẩu hiệu dùng ML"
→ ⚠ sai cả hai vế
Nhất quán với #13956 (cùng lô) về bản đồ khái niệm và #13926 (lô 146) phân biệt AI sinh với AI dự đoán. Hoàn toàn nhất quán.
Vì sao các phương án khác sai
-
B (ML là tập con của Generative AI) — phương án gần nhất và là bẫy chính: nó có phân loại đúng hai hệ thống, nhưng đảo ngược quan hệ bao hàm.
-
C và A — sai về bản chất.
Ghi nhớ
⚠ Quan hệ bao hàm — bảng phải thuộc: | Cấp | Khái niệm | Ghi nhớ | |---|---|---| | 1 | ⚠ AI | ⚠ rộng nhất | | 2 | ⚠ Machine Learning | ⚠ học từ dữ liệu | | 3 | Deep Learning | ⚠ mạng nơ-ron sâu | | 4 | ⚠ Generative AI | ⚠ hẹp nhất — TẠO nội dung |
Từ khoá nhận diện:
"dự đoán con số, phân loại" → ⚠ ML dự đoán "tạo nội dung mới" → ⚠ generative AI (vẫn là ML) "quan hệ bao hàm" → ⚠ AI ⊃ ML ⊃ DL ⊃ GenAI "lĩnh vực bao trùm nhất" → AI
⚠ AI dự đoán và AI sinh — bảng phải thuộc: | | ⚠ Dự đoán | ⚠ Sinh | |---|---|---| | Đầu ra | ⚠ nhãn, con số | ⚠ nội dung mới | | Ví dụ trong đề | ⚠ doanh số tháng tới | ⚠ khẩu hiệu mới | | Huấn luyện | ⚠ thường có giám sát | ⚠ tự giám sát, dữ liệu lớn | | Đánh giá | ⚠ so với đáp án đúng | ⚠ KHÓ — không có đáp án duy nhất | | Điểm chung | ⚠ CẢ HAI đều là machine learning | |
| ⚠ Vì sao hay bị hiểu nhầm | Lý do |
|---|---|
| ⚠ AI sinh nổi tiếng gần đây | ⚠ nhiều người tưởng nó là "AI" nói chung |
| Truyền thông dùng "AI" thay cho "AI sinh" | |
| ⚠ Nhưng ML dự đoán vẫn tạo giá trị rất lớn | ⚠ và thường rẻ hơn nhiều |
| Trong doanh nghiệp | ⚠ hai loại thường dùng CÙNG nhau |
| ⚠ Hai loại dùng chung trong thực tế | Ví dụ |
|---|---|
| ⚠ ML dự đoán phân khúc khách | ⚠ rồi AI sinh viết nội dung riêng cho từng phân khúc |
| AI sinh trích đặc trưng từ văn bản | ⚠ rồi mô hình bảng dự đoán |
| ⚠ ML lọc trước, LLM xử lý ca khó | ⚠ tiết kiệm chi phí |
| LLM gán nhãn, mô hình nhỏ phục vụ | ⚠ rẻ ở quy mô lớn |
| ⚠ Khi nào KHÔNG nên dùng AI sinh | Khi |
|---|---|
| ⚠ Bài toán dự đoán con số | ⚠ hồi quy rẻ và chính xác hơn nhiều |
| ⚠ Cần kết quả xác định, lặp lại được | |
| Cần giải thích được quyết định | ⚠ mô hình đơn giản dễ giải thích hơn |
| Khối lượng cực lớn, ngân sách hẹp |
Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Đầu ra là số/nhãn hay nội dung | ⚠ quyết định loại mô hình | | Có cần lặp lại chính xác không | ⚠ có → tránh mô hình sinh | | Bài toán này có cần AI sinh thật không | ⚠ nhiều khi ML truyền thống tốt hơn |
Và câu hỏi đáng đặt trong mọi dự án được đề xuất dưới nhãn "AI sinh": bài toán này có thật sự cần tạo ra nội dung mới không, hay chỉ cần một dự đoán? Nếu là vế sau, một mô hình hồi quy thông thường thường cho kết quả chính xác hơn, rẻ hơn và giải thích được rõ ràng hơn.
An AI application allows users to upload an image of a meal and receive a detailed text recipe for it, including ingredients and cooking instructions.
This AI's ability to process visual input (the image) and generate textual output (the recipe) is a characteristic of:
-
A
A multimodal model
-
B
A unimodal text-only model
-
C
A clustering algorithm
-
D
A time-series forecasting model
Xem giải thích
Đáp án
A — Một mô hình đa phương thức (multimodal model).
Vì sao đúng
Ứng dụng nhận ẢNH món ăn và sinh ra VĂN BẢN công thức. Xử lý một modality ở đầu vào và sinh ra một modality khác ở đầu ra là đặc trưng của mô hình đa phương thức.
⚠ Xác định bằng đầu vào và đầu ra:
ĐẦU VÀO: ⚠ ẢNH món ăn
↓
ĐẦU RA: ⚠ VĂN BẢN công thức
↓
⚠ HAI modality khác nhau
↓
→ ⚠ mô hình đa phương thức
⚠ Việc mô hình phải làm:
⚠ Nhận diện món ăn trong ảnh
⚠ Suy ra nguyên liệu có thể có
⚠ Suy ra cách chế biến
⚠ Viết ra thành công thức mạch lạc
↓
⚠ Không chỉ "nhận diện" —
còn phải SUY LUẬN và SINH
⚠ Vì sao ba phương án kia sai:
"Mô hình chỉ văn bản (unimodal)"
→ ⚠ không đọc được ảnh
"Thuật toán phân cụm"
→ ⚠ gom nhóm, không sinh gì
"Mô hình dự báo chuỗi thời gian"
→ ⚠ dự đoán giá trị theo thời gian
⚠ Gần trùng với #13950 (lô 146) — đề đó là công cụ nhận text + audio + ảnh sinh video, cùng khoá multimodal. Đề này đơn giản hơn: ảnh vào, chữ ra. Hoàn toàn nhất quán. Và #13870 (lô 145) về Gemini đa phương thức.
Vì sao các phương án khác sai
-
B (mô hình chỉ văn bản) — phương án gần nhất và là bẫy chính: đầu ra đúng là văn bản. Nhưng đầu vào là ảnh, mà mô hình đơn phương thức văn bản không đọc được ảnh.
-
C và D — không phải mô hình sinh.
Ghi nhớ
⚠ Đơn và đa phương thức — bảng phải thuộc: | Loại | Đầu vào → đầu ra | Ví dụ | |---|---|---| | Unimodal văn bản | ⚠ chữ → chữ | LLM thuần | | Text-to-image | ⚠ chữ → ảnh | Imagen | | Text-to-video | ⚠ chữ → video | Veo | | ⚠ Multimodal | ⚠ nhiều loại vào, có thể nhiều loại ra | ⚠ Gemini |
Từ khoá nhận diện:
"ảnh vào, chữ ra" → ⚠ multimodal "chữ vào, ảnh ra" → Imagen (cũng là sinh đa modality) "chỉ xử lý chữ" → unimodal LLM "gom nhóm không nhãn" → clustering
| ⚠ Ứng dụng của mô hình đa phương thức | Ứng dụng |
|---|---|
| ⚠ Hỏi đáp trên ảnh | ⚠ đề này |
| Đọc biểu đồ, bảng biểu trong ảnh | |
| ⚠ Mô tả ảnh cho người khiếm thị | ⚠ ứng dụng rất giá trị |
| Phân tích video | ⚠ tóm tắt, tìm khoảnh khắc |
| Trợ lý lập trình đọc bản phác giao diện | |
| Kiểm duyệt nội dung đa dạng |
| ⚠ Giới hạn cần nói rõ với người dùng | Giới hạn |
|---|---|
| ⚠ Công thức là SUY ĐOÁN từ hình ảnh | ⚠ không phải công thức gốc |
| ⚠ Không biết gia vị, tỉ lệ chính xác | |
| ⚠ Không biết dị ứng thực phẩm | ⚠ rủi ro an toàn thật |
| Món địa phương ít phổ biến | ⚠ dễ nhận nhầm |
| Vì vậy | ⚠ ghi rõ đây là gợi ý, không phải công thức chuẩn |
| ⚠ Rủi ro với ứng dụng liên quan tới ăn uống | Rủi ro |
|---|---|
| ⚠ Bỏ sót nguyên liệu gây dị ứng | ⚠ hậu quả sức khoẻ nghiêm trọng |
| Hướng dẫn nấu không an toàn | ⚠ nhiệt độ, thời gian |
| Thông tin dinh dưỡng sai | |
| Giảm bằng | ⚠ cảnh báo rõ ràng + không đưa ra khẳng định y tế |
| ⚠ Kỹ thuật để kết quả tốt hơn | Kỹ thuật |
|---|---|
| ⚠ Prompt nêu rõ định dạng mong muốn | ⚠ nguyên liệu, các bước, thời gian |
| ⚠ Yêu cầu nêu độ chắc chắn | ⚠ "có thể là..." khi không rõ |
| Grounding vào CSDL công thức thật | ⚠ thay vì để mô hình bịa |
| Cho người dùng sửa và xác nhận món |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhận đúng món bao nhiêu phần trăm | ⚠ thử với ảnh thật, món địa phương | | Có cảnh báo về dị ứng chưa | ⚠ bắt buộc | | Mô hình có nói "không chắc" không | ⚠ thử ảnh mờ, món lạ |
Và với những ứng dụng nghe vô hại như nhận diện món ăn, rủi ro thật vẫn nằm ở chỗ ít ai nghĩ tới: một nguyên liệu gây dị ứng bị bỏ sót trong danh sách suy đoán. Vì vậy phần cảnh báo trên giao diện quan trọng không kém phần nhận diện.
A company wants its new internal chatbot to answer employee questions about HR policies by directly referencing information from the company's official HR document repository, ensuring answers are accurate and based on the latest policies. They are looking for a Google Cloud solution that simplifies this process of connecting a generative AI model to their specific document data.
Which approach best utilizes Google Cloud's offerings for this RAG-based solution?
-
A
Manually building a vector database and retrieval pipeline from scratch.
-
B
Using only Google's public search to find general HR information.
-
C
Fine-tuning a foundation model solely on the HR documents without a retrieval step.
-
D
Using prebuilt RAG capabilities within Vertex AI Search to connect to their document data.
Xem giải thích
Đáp án
D — Dùng năng lực RAG dựng sẵn trong Vertex AI Search để kết nối tới dữ liệu tài liệu của họ.
Vì sao đúng
Công ty muốn chatbot tham chiếu trực tiếp kho tài liệu HR chính thức, đảm bảo câu trả lời chính xác theo chính sách mới nhất, và cần giải pháp đơn giản hoá quá trình. Vertex AI Search đóng gói sẵn toàn bộ chuỗi RAG.
⚠ Vertex AI Search làm sẵn những gì:
Tự làm RAG phải lo:
⚠ chia đoạn tài liệu
⚠ sinh embedding
⚠ dựng và vận hành vector DB
⚠ tìm kiếm và xếp hạng
⚠ ghép prompt, trích dẫn
↓
⚠ Vertex AI Search
→ ⚠ trỏ vào kho tài liệu
→ ⚠ tất cả ở trên CÓ SẴN
⚠ Vì sao ba phương án kia sai:
"Tự dựng vector DB và pipeline
từ đầu"
→ ⚠ làm được, nhưng ĐÚNG THỨ
đề nói muốn đơn giản hoá
"Chỉ dùng Google public search
để tìm thông tin HR chung chung"
→ ⚠ SAI NGUỒN: chính sách của
công ty không nằm trên web
"FINE-TUNE mô hình chỉ trên tài
liệu HR, KHÔNG có bước tra cứu"
→ ⚠ chính sách thay đổi thì
phải huấn luyện lại
→ ⚠ và KHÔNG trích dẫn được nguồn
⚠ Gần trùng với #13902 (lô 145) — đề đó gần như cùng tình huống chatbot chính sách HR, cùng khoá. Hoàn toàn nhất quán. Và #13913/#13951 về cơ chế RAG.
Vì sao các phương án khác sai
-
C (fine-tune không có tra cứu) — phương án gần nhất và là bẫy chính: cũng dùng tài liệu HR. Nhưng nhúng kiến thức vào trọng số nghĩa là mỗi lần chính sách đổi phải huấn luyện lại, và không trích dẫn được nguồn.
-
A — đúng kỹ thuật nhưng ngược với yêu cầu đơn giản.
-
B — sai nguồn dữ liệu.
Ghi nhớ
⚠ RAG hay fine-tuning cho tài liệu chính sách — bảng phải thuộc: | | ⚠ RAG | ⚠ Fine-tuning | |---|---|---| | Chính sách đổi | ⚠ sửa tài liệu là xong | ⚠ huấn luyện lại | | Trích dẫn | ⚠ CÓ | ⚠ KHÔNG | | Lọc theo quyền | ⚠ được | ⚠ không | | Chi phí | thấp | cao | | Kết luận | ⚠ RAG cho tài liệu chính sách | ⚠ fine-tune cho PHONG CÁCH |
Từ khoá nhận diện:
"tài liệu nội bộ, RAG, ít cấu hình" → ⚠ Vertex AI Search "agent dùng công cụ" → Agent Builder "cho nhân viên, dạng cổng thông tin" → ⚠ Gemini Enterprise "tin tức web công khai" → Grounding with Google Search
| ⚠ Chatbot HR — yêu cầu bắt buộc | Yêu cầu |
|---|---|
| ⚠ TRÍCH DẪN tài liệu và điều khoản | ⚠ nhân viên kiểm chứng được |
| ⚠ Lọc theo QUYỀN của người hỏi | ⚠ không phải ai cũng xem được mọi chính sách |
| ⚠ Nói KHÔNG BIẾT khi không có thông tin | ⚠ đừng đoán về lương, phép |
| Đường chuyển sang người | ⚠ câu hỏi nhạy cảm |
| ⚠ Gỡ tài liệu HẾT HIỆU LỰC | ⚠ nguồn sai phổ biến nhất |
| ⚠ Rủi ro của chatbot HR | Rủi ro |
|---|---|
| ⚠ Trả lời sai về lương, phép, bảo hiểm | ⚠ có thể thành tranh chấp lao động |
| Lộ chính sách chỉ dành cho một nhóm | |
| ⚠ Câu hỏi khiếu nại, quấy rối | ⚠ PHẢI chuyển người ngay |
| Ghi log câu hỏi của nhân viên | ⚠ cân nhắc quyền riêng tư |
| ⚠ Việc vận hành liên tục | Việc |
|---|---|
| ⚠ CÓ NGƯỜI chịu trách nhiệm cập nhật tài liệu | ⚠ phần khó nhất, không phải công nghệ |
| Đồng bộ chỉ mục khi tài liệu đổi | |
| ⚠ Theo dõi câu hỏi không trả lời được | ⚠ chỉ ra chính sách còn thiếu văn bản |
| Rà soát câu trả lời định kỳ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trích dẫn tài liệu không | ⚠ bắt buộc | | Bản chính sách cũ đã gỡ chưa | ⚠ nguồn trả lời sai số một | | Nhân viên thường hỏi gì mà bot không trả lời được | ⚠ danh sách cải thiện |
Và phần khó nhất của một chatbot chính sách nội bộ không nằm ở khâu dựng: nó nằm ở việc có ai đó chịu trách nhiệm gỡ bản quy định cũ mỗi khi chính sách thay đổi. Một bot trả lời tự tin dựa trên văn bản đã hết hiệu lực gây rắc rối nhiều hơn là không có bot nào.
A company wants to train a generative AI model on a large dataset of customer support chat logs to improve its customer service responses. These chat logs contain Personally Identifiable Information (PII) such as names, email addresses, and phone numbers.
To protect customer privacy and comply with data protection regulations before using this data for training, what data processing technique should the company apply to remove or obscure this PII?
-
A
Data augmentation
-
B
Data encryption at rest
-
C
Data validation
-
D
Data anonymization (or de-identification)
Xem giải thích
Đáp án
D — Data anonymization (khử định danh dữ liệu).
Vì sao đúng
Mục tiêu là gỡ bỏ hoặc che PII — tên, email, số điện thoại — trước khi dùng dữ liệu để huấn luyện. Đó chính là khử định danh.
⚠ Vì sao bước này bắt buộc:
Chat log chứa PII
↓
⚠ Huấn luyện trực tiếp trên đó
↓
⚠ Mô hình có thể GHI NHỚ và
NHẮC LẠI thông tin khách hàng
⚠ Vi phạm quy định bảo vệ dữ liệu
↓
→ ⚠ khử định danh TRƯỚC KHI
huấn luyện, không phải sau
⚠ Vì sao ba phương án kia sai:
"Data augmentation"
→ ⚠ TĂNG CƯỜNG dữ liệu bằng
biến thể — không liên quan riêng tư
"Data encryption at rest"
→ ⚠ mã hoá KHI LƯU; ⚠ giải mã ra
để huấn luyện thì PII vẫn còn
"Data validation"
→ ⚠ kiểm tính hợp lệ của dữ liệu
⚠ Đối chiếu #13929 (lô 146) — đề đó khoá pseudonymization vì nói rõ ràng là "thay định danh trực tiếp bằng định danh nhân tạo". Đề này nói "gỡ bỏ HOẶC che", tức khái niệm rộng hơn: khử định danh. KHÔNG mâu thuẫn — dữ kiện trong đề quyết định thuật ngữ nào chính xác hơn.
Vì sao các phương án khác sai
-
B (mã hoá khi lưu) — phương án gần nhất và là bẫy chính: cũng là biện pháp bảo vệ dữ liệu thật. Nhưng mã hoá có thể giải ngược, và lúc huấn luyện dữ liệu phải ở dạng rõ — PII vẫn đi vào mô hình.
-
A và C — thuộc khâu xử lý dữ liệu, không phải bảo vệ riêng tư.
Ghi nhớ
⚠ Các kỹ thuật bảo vệ dữ liệu — bảng phải thuộc: | Kỹ thuật | Nội dung | Truy ngược | |---|---|---| | ⚠ Anonymization | ⚠ loại bỏ khả năng nhận dạng | ⚠ KHÔNG | | ⚠ Pseudonymization | ⚠ thay bằng định danh nhân tạo | ⚠ CÓ, nếu có bảng ánh xạ | | Redaction | ⚠ xoá hẳn trường | không | | Masking | ⚠ che một phần | tuỳ | | Tokenization | thay bằng token | ⚠ có, với kho khoá | | ⚠ Encryption | ⚠ mã hoá | ⚠ CÓ, với khoá |
Từ khoá nhận diện:
"gỡ bỏ hoặc che PII" → ⚠ anonymization / de-identification "thay bằng ĐỊNH DANH NHÂN TẠO" → ⚠ pseudonymization "mã hoá khi lưu" → encryption at rest "chỉ thu thập những gì cần" → data minimization
| ⚠ Rủi ro riêng khi huấn luyện trên PII | Rủi ro |
|---|---|
| ⚠ Mô hình GHI NHỚ dữ liệu huấn luyện | ⚠ có thể nhắc lại nguyên văn |
| ⚠ Trích xuất qua truy vấn khéo léo | ⚠ training data extraction attack |
| Membership inference | ⚠ suy ra một người có trong tập không |
| Không thể "gỡ" dữ liệu khỏi mô hình đã huấn luyện | ⚠ phải huấn luyện lại |
| Vì vậy | ⚠ khử định danh TRƯỚC là bắt buộc, không phải tuỳ chọn |
| ⚠ Chat log có gì cần che | Trường |
|---|---|
| Tên, email, số điện thoại | ⚠ đề nêu |
| ⚠ Số thẻ, số tài khoản | ⚠ rủi ro tài chính |
| Địa chỉ, mã đơn hàng | |
| ⚠ Thông tin sức khoẻ vô tình nhắc tới | ⚠ khách hay kể lý do |
| Tên nhân viên hỗ trợ | ⚠ cũng là dữ liệu cá nhân |
| Công cụ | ⚠ Sensitive Data Protection quét và biến đổi tự động |
| ⚠ Cẩn thận: khử định danh chưa chắc đủ | Điểm |
|---|---|
| ⚠ Ghép nhiều trường vẫn nhận ra người | ⚠ rủi ro tái nhận dạng |
| ⚠ Nội dung hội thoại tự do khó che hết | ⚠ khách viết thông tin ở chỗ bất ngờ |
| Trường hợp hiếm dễ lộ danh tính | |
| Vì vậy | ⚠ kiểm mẫu bằng người sau khi chạy công cụ tự động |
| ⚠ Lựa chọn thay thế | Lựa chọn |
|---|---|
| ⚠ Dùng RAG thay vì huấn luyện | ⚠ dữ liệu không đi vào trọng số |
| Tổng hợp dữ liệu giả từ thống kê | ⚠ synthetic data |
| Chỉ dùng phần dữ liệu đã sạch | |
| ⚠ Riêng tư vi phân | ⚠ kỹ thuật nâng cao |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã quét PII trong nội dung tự do chưa | ⚠ không chỉ các trường cấu trúc | | Kiểm mẫu bằng người | ⚠ công cụ tự động bỏ sót được | | Có thật sự cần huấn luyện không | ⚠ RAG có khi đủ và an toàn hơn |
Và điểm khiến việc huấn luyện trên dữ liệu cá nhân khác hẳn mọi khâu xử lý dữ liệu khác: không có cách nào gỡ một bản ghi ra khỏi mô hình đã huấn luyện. Khi phát hiện PII đã lọt vào, lựa chọn duy nhất là huấn luyện lại từ đầu — nên khâu làm sạch phải xong trước, không thể sửa sau.
A product manager with some technical understanding, but not a full-stack developer, wants to quickly create a proof-of-concept demo using Gemini to showcase a potential new AI feature to stakeholders. They need an easy-to-use, web-based environment for prompt iteration and sharing simple interactive demos, without complex setup.
Which environment is better suited for this user and goal?
-
A
Google AI Studio, for its accessible interface and quick prototyping.
-
B
Using pre-built solutions from Google Cloud Marketplace.
-
C
Vertex AI Studio, for its full MLOps pipeline integration.
-
D
Developing directly against the Gemini API using a command-line interface.
Xem giải thích
Đáp án
A — Google AI Studio, nhờ giao diện dễ tiếp cận và khả năng làm mẫu nhanh.
Vì sao đúng
Người dùng là quản lý sản phẩm, có hiểu biết kỹ thuật nhưng không phải lập trình viên, cần môi trường web dễ dùng để lặp prompt và chia sẻ bản demo đơn giản, không cấu hình phức tạp.
⚠ Bốn dữ kiện khớp:
"không phải lập trình viên đầy đủ"
→ ⚠ cần giao diện, không cần SDK
"môi trường TRÊN WEB, dễ dùng"
→ ⚠ AI Studio mở trình duyệt là dùng
"lặp PROMPT và chia sẻ demo"
→ ⚠ đúng chức năng chính
"KHÔNG cấu hình phức tạp"
→ ⚠ không cần project, IAM
⚠ Vì sao ba phương án kia sai:
"Vertex AI Studio, vì tích hợp
MLOps đầy đủ"
→ ⚠ MLOps là thứ NGƯỜI NÀY
KHÔNG cần cho một demo
"Phát triển thẳng với Gemini API
qua dòng lệnh"
→ ⚠ đòi kỹ năng lập trình
"Giải pháp dựng sẵn từ Marketplace"
→ ⚠ không phải nơi thử prompt
cho tính năng mới
⚠ Gần trùng với #13891 (lô 145) — đề đó cũng là thử nhanh, chi phí thấp, không dựng môi trường, cùng khoá Google AI Studio. Đối chiếu #13923 (lô 146) khoá Vertex AI Studio vì ở đó yêu cầu là sản xuất, MLOps, dữ liệu độc quyền. Hoàn toàn nhất quán.
Vì sao các phương án khác sai
-
C (Vertex AI Studio) — phương án gần nhất và là bẫy chính: tên gần giống và cũng thử prompt được. Nhưng lý do nêu trong phương án — tích hợp MLOps đầy đủ — chính là thứ dư thừa với nhu cầu làm demo.
-
D và B — đòi kỹ năng lập trình hoặc sai mục đích.
Ghi nhớ
⚠ AI Studio và Vertex AI Studio — bảng phải thuộc: | | Google AI Studio | Vertex AI Studio | |---|---|---| | Người dùng | ⚠ ai cũng dùng được | ⚠ đội kỹ thuật | | Mục đích | ⚠ làm mẫu, thử prompt | ⚠ sản xuất | | Thiết lập | ⚠ gần như không | ⚠ project, IAM | | MLOps | ⚠ không | ⚠ có | | ⚠ Dữ liệu thật của công ty | ⚠ KHÔNG nên | ⚠ có kiểm soát |
Từ khoá nhận diện:
"làm mẫu nhanh, không dựng gì, chia sẻ demo" → ⚠ Google AI Studio "sản xuất, MLOps, dữ liệu độc quyền" → Vertex AI Studio "danh mục mô hình" → Model Garden "agent dùng công cụ" → Agent Builder
| ⚠ AI Studio hợp với việc gì | Việc |
|---|---|
| ⚠ Thử ý tưởng trước khi đầu tư | ⚠ đề này |
| So sánh vài prompt khác nhau | |
| ⚠ Chỉnh temperature, top-p và thấy ngay tác dụng | |
| Thử đa phương thức | ⚠ tải ảnh lên hỏi |
| ⚠ Lấy mã sinh sẵn | ⚠ giao cho lập trình viên làm tiếp |
| Chia sẻ prompt cho đồng nghiệp xem |
| ⚠ Ranh giới PHẢI nhớ | Ranh giới |
|---|---|
| ⚠ ĐỪNG dán dữ liệu khách hàng thật vào | ⚠ sai lầm phổ biến nhất |
| Dùng dữ liệu giả hoặc đã che | |
| ⚠ Chuyển sang Vertex AI khi lên sản xuất | |
| Điều khoản dữ liệu khác nhau giữa hai nơi | ⚠ đọc kỹ |
| ⚠ Làm demo thuyết phục cho lãnh đạo | Mẹo |
|---|---|
| ⚠ Dùng ví dụ THẬT của công ty | ⚠ đã che dữ liệu nhạy cảm |
| ⚠ Cho thấy cả ca THẤT BẠI | ⚠ tăng độ tin cậy, tránh kỳ vọng ảo |
| Nêu rõ giới hạn | ⚠ đây là bản mẫu, không phải sản phẩm |
| ⚠ Ước tính chi phí ở quy mô thật | ⚠ câu hỏi lãnh đạo chắc chắn hỏi |
| Nêu bước tiếp theo cụ thể |
| ⚠ Từ demo tới sản phẩm — khoảng cách thật | Khoảng cách |
|---|---|
| ⚠ Demo chạy vài ví dụ, sản phẩm chạy hàng nghìn | |
| ⚠ Cần grounding vào dữ liệu thật | |
| Cần xử lý ca lỗi, ca biên | |
| ⚠ Cần đánh giá có bộ test | |
| Cần quản trị, bảo mật, giám sát | |
| Ghi nhớ | ⚠ demo tốt không đảm bảo sản phẩm khả thi |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dữ liệu thật trong demo không | ⚠ phải che trước | | Đã thử ca khó chưa | ⚠ demo chỉ toàn ca dễ gây kỳ vọng sai | | Chi phí ở quy mô thật là bao nhiêu | ⚠ chuẩn bị trước khi trình bày |
Và điều đáng đưa vào mọi bản demo AI trình bày cho lãnh đạo: một vài ví dụ mà mô hình làm chưa tốt. Nó khiến buổi trình bày đáng tin hơn, và quan trọng hơn, nó đặt kỳ vọng đúng cho phần ngân sách và thời gian sẽ được duyệt sau đó.
A generative AI agent is tasked with planning a complex event. It first gathers initial requirements, then formulates a preliminary plan, then seeks feedback or additional information (perhaps using a tool), refines the plan based on this new input, and continues this cycle until a satisfactory plan is achieved or a constraint is met.
This cyclical process of information gathering, internal processing, decision-making, and action, which repeats until a goal is met, is a key characteristic of what component in a generative AI agent?
-
A
The agent's data ingestion module
-
B
The safety filter settings
-
C
The reasoning loop
-
D
The foundation model's core architecture
Xem giải thích
Đáp án
C — The reasoning loop (vòng lặp suy luận).
Vì sao đúng
Đề mô tả đúng vòng lặp suy luận của agent: thu thập thông tin, xử lý nội bộ, ra quyết định, hành động — rồi lặp lại cho tới khi đạt mục tiêu hoặc chạm ràng buộc.
⚠ Vòng lặp suy luận:
⚠ THU THẬP yêu cầu ban đầu
↓
⚠ LẬP kế hoạch sơ bộ
↓
⚠ TÌM thêm thông tin
(⚠ dùng công cụ)
↓
⚠ TINH CHỈNH kế hoạch
↓
⚠ LẶP LẠI cho tới khi
đạt mục tiêu
hoặc chạm giới hạn
⚠ Vì sao đây là thứ phân biệt agent với chatbot:
CHATBOT thường
→ ⚠ MỘT lượt: hỏi → trả lời
→ không có vòng lặp
⚠ AGENT
→ ⚠ NHIỀU bước tự quyết
→ ⚠ tự đánh giá đã đủ chưa
→ ⚠ tự chọn công cụ tiếp theo
↓
⚠ vòng lặp suy luận chính là
"bộ não điều phối" của agent
⚠ Vì sao ba phương án kia sai:
"Module nạp dữ liệu"
→ ⚠ đưa dữ liệu vào, không
điều phối quyết định
"Cài đặt bộ lọc an toàn"
→ ⚠ chặn nội dung có hại
"Kiến trúc lõi của mô hình nền"
→ ⚠ transformer — là NỀN, không
phải cơ chế lặp của agent
Nhất quán với #13944 (lô 146) — đề đó khoá ReAct, là kỹ thuật prompt hiện thực chính vòng lặp này. Đề này hỏi tên THÀNH PHẦN trong kiến trúc agent. Bổ sung nhau, không mâu thuẫn.
Vì sao các phương án khác sai
-
D (kiến trúc lõi của mô hình nền) — phương án gần nhất vì mô hình thật sự thực hiện phần suy luận. Nhưng kiến trúc mô hình là năng lực nền, còn vòng lặp là cơ chế điều phối ở tầng agent.
-
A và B — là các thành phần khác.
Ghi nhớ
⚠ Kiến trúc agent — thành phần, bảng phải thuộc: | Thành phần | Vai trò | |---|---| | ⚠ Reasoning loop | ⚠ điều phối: nghĩ → hành động → quan sát → lặp | | Mô hình nền | ⚠ năng lực suy luận và sinh | | Tools | ⚠ API, hàm để lấy dữ liệu hoặc hành động | | Data store / grounding | ⚠ tài liệu để đọc | | Bộ nhớ | lịch sử hội thoại | | ⚠ Chỉ dẫn và ràng buộc | ⚠ agent được và không được làm gì | | Bộ lọc an toàn | ⚠ chặn đầu vào/ra có hại |
Từ khoá nhận diện:
"lặp lại tới khi đạt mục tiêu" → ⚠ reasoning loop "suy luận xen kẽ gọi công cụ" → ⚠ ReAct — kỹ thuật hiện thực "trình bày từng bước, không gọi công cụ" → Chain-of-Thought "nhiều lời gọi do người thiết kế sẵn" → ⚠ prompt chaining
| ⚠ Ràng buộc PHẢI đặt cho vòng lặp | Ràng buộc |
|---|---|
| ⚠ Số bước TỐI ĐA | ⚠ chống vòng lặp vô hạn |
| ⚠ Ngân sách token hoặc chi phí | ⚠ mỗi vòng là một lời gọi mô hình |
| Thời gian tối đa | |
| ⚠ Tiêu chí DỪNG rõ ràng | ⚠ thế nào là "đủ tốt" |
| Xác nhận của người ở bước quan trọng |
| ⚠ Vì sao vòng lặp dễ gây tốn kém | Lý do |
|---|---|
| ⚠ Mỗi vòng gọi mô hình một lần | ⚠ 10 vòng = 10 lần tính tiền |
| ⚠ Ngữ cảnh dài dần sau mỗi vòng | ⚠ token tăng theo cấp số |
| Agent có thể lặp vô ích | ⚠ không biết dừng |
| Giảm bằng | ⚠ giới hạn bước + tóm tắt ngữ cảnh giữa các vòng |
| ⚠ Gỡ lỗi agent — nhờ đâu | Nhờ |
|---|---|
| ⚠ GHI LẠI toàn bộ vết suy luận | ⚠ thought, action, observation |
| Thấy được agent đã nghĩ gì ở bước nào | |
| ⚠ Thấy công cụ nào trả về gì | |
| Nếu không ghi | ⚠ agent sai mà không biết vì sao |
| ⚠ Khi nào KHÔNG cần agent có vòng lặp | Khi |
|---|---|
| ⚠ Bài toán một bước | ⚠ phân loại, tóm tắt → một lời gọi là đủ |
| Quy trình cố định | ⚠ prompt chaining dự đoán được hơn |
| Cần độ trễ thấp | ⚠ vòng lặp chậm |
| Nguyên tắc | ⚠ agent mạnh nhưng đắt và khó đoán — chỉ dùng khi cần |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có giới hạn số vòng chưa | ⚠ thiếu là chi phí có thể bùng | | Vết suy luận có được ghi không | ⚠ cần để gỡ lỗi | | Tiêu chí dừng có rõ không | ⚠ agent phải biết khi nào là đủ |
Và ràng buộc cần đặt ngay khi dựng agent đầu tiên: số bước tối đa cho vòng lặp. Một agent không biết dừng sẽ tiếp tục suy luận và gọi công cụ cho tới khi hết ngân sách — và hoá đơn là nơi người ta thường phát hiện ra điều đó.
A company has invested heavily in developing a proprietary, high-performance generative AI model. An attacker gains unauthorized access to the company's cloud environment and manages to exfiltrate the trained model's weights and architecture. This allows the attacker to replicate the model for their own use or to analyze it for vulnerabilities.
This type of security breach is best described as:
-
A
Data poisoning
-
B
Model theft (or model hijacking)
-
C
Denial of service
-
D
Prompt injection
Xem giải thích
Đáp án
B — Model theft (đánh cắp mô hình).
Vì sao đúng
Kẻ tấn công truy cập trái phép và lấy đi trọng số cùng kiến trúc của mô hình đã huấn luyện, để sao chép dùng riêng hoặc phân tích tìm lỗ hổng. Đó là đánh cắp mô hình.
⚠ Vì sao mô hình là tài sản đáng bị nhắm tới:
⚠ Huấn luyện tốn RẤT NHIỀU tiền
⚠ Dữ liệu huấn luyện là tài sản riêng
⚠ Là lợi thế cạnh tranh
↓
⚠ Lấy được trọng số = có luôn
kết quả của toàn bộ đầu tư đó
↓
⚠ Và phân tích được để tìm
cách lách mô hình
⚠ Hai con đường đánh cắp:
⚠ TRỰC TIẾP — đề này
→ xâm nhập hạ tầng
→ lấy tệp trọng số
→ ⚠ phòng bằng IAM, mã hoá,
phân đoạn mạng
⚠ GIÁN TIẾP — model extraction
→ ⚠ gọi API rất nhiều lần
→ dùng cặp đầu vào–đầu ra để
huấn luyện mô hình sao chép
→ ⚠ phòng bằng giới hạn tần suất,
không lộ điểm số chi tiết
⚠ Vì sao ba phương án kia sai:
"Data poisoning"
→ ⚠ ĐẦU ĐỘC dữ liệu huấn luyện
"Prompt injection"
→ ⚠ lừa mô hình bỏ qua chỉ dẫn
qua đầu vào
"Denial of service"
→ ⚠ làm dịch vụ không phục vụ được
Nhất quán với #13925 (lô 146) — đề đó về tấn công đối kháng và liệt kê cả họ tấn công vào hệ thống ML. Đề này hỏi riêng một loại. Bổ sung nhau.
Vì sao các phương án khác sai
-
A (data poisoning) — phương án gần nhất và là bẫy chính: cũng là tấn công nhắm vào mô hình. Nhưng đầu độc dữ liệu là làm hỏng mô hình từ khâu huấn luyện, còn đây là lấy đi mô hình đã hoàn chỉnh.
-
D và C — thuộc loại tấn công khác.
Ghi nhớ
⚠ Các tấn công vào hệ thống ML — bảng phải thuộc: | Tấn công | Nội dung | Phòng bằng | |---|---|---| | ⚠ Model theft | ⚠ lấy trọng số, kiến trúc | ⚠ IAM, mã hoá, phân đoạn mạng | | ⚠ Model extraction | ⚠ dò ngược qua nhiều truy vấn | ⚠ rate limit, không lộ điểm chi tiết | | ⚠ Data poisoning | ⚠ đầu độc dữ liệu huấn luyện | ⚠ kiểm soát nguồn dữ liệu | | ⚠ Adversarial input | ⚠ sửa nhẹ đầu vào để đánh lừa | ⚠ adversarial training | | ⚠ Prompt injection | ⚠ lừa bỏ qua chỉ dẫn | ⚠ lọc, quyền tối thiểu | | Membership inference | ⚠ suy ra mẫu có trong tập huấn luyện | riêng tư vi phân |
Từ khoá nhận diện:
"lấy trọng số và kiến trúc" → ⚠ model theft "dò ngược qua nhiều lời gọi API" → ⚠ model extraction "đầu độc dữ liệu huấn luyện" → data poisoning "lừa mô hình qua đầu vào" → ⚠ prompt injection
| ⚠ Bảo vệ mô hình như tài sản quý | Biện pháp |
|---|---|
| ⚠ IAM quyền tối thiểu cho kho mô hình | ⚠ rất ít người cần quyền tải trọng số |
| ⚠ Mã hoá khi lưu và khi truyền | |
| ⚠ VPC Service Controls | ⚠ ngăn dữ liệu và mô hình rời ranh giới |
| Audit log mọi thao tác trên Model Registry | ⚠ ai tải mô hình xuống |
| ⚠ Không để trọng số trong image hoặc repo mã | ⚠ sai lầm hay gặp |
| Phát hiện tải xuống bất thường | ⚠ Security Command Center |
| ⚠ Chống model extraction qua API | Cách |
|---|---|
| ⚠ Giới hạn tần suất truy vấn | ⚠ theo tài khoản và theo IP |
| ⚠ Chỉ trả KẾT QUẢ, không trả điểm số chi tiết | ⚠ điểm số giúp dò ngược nhanh hơn |
| Phát hiện mẫu truy vấn bất thường | ⚠ truy vấn có hệ thống, phủ đều không gian |
| Xác thực và ghi log mọi lời gọi | |
| Watermark mô hình | ⚠ để chứng minh khi bị sao chép |
| ⚠ Điểm khác của bảo mật ML | Điểm |
|---|---|
| ⚠ Mô hình bị lộ thì KHÔNG "vá" được | ⚠ phải huấn luyện lại |
| ⚠ Kẻ có mô hình dò được điểm yếu offline | ⚠ rồi tấn công hệ thống thật |
| Trọng số là tệp — dễ sao chép, khó truy vết | |
| Vì vậy | ⚠ phòng ngừa quan trọng hơn phát hiện |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền tải trọng số mô hình | ⚠ danh sách phải rất ngắn | | Có trọng số nằm trong repo mã không | ⚠ kiểm ngay | | API có giới hạn tần suất chưa | ⚠ chống dò ngược |
Và điều làm việc mất mô hình khác với mọi sự cố bảo mật khác: không có bản vá nào cả. Trọng số đã bị sao chép thì vĩnh viễn nằm ngoài tầm kiểm soát, và cách duy nhất để lấy lại lợi thế là huấn luyện một mô hình mới — với toàn bộ chi phí ban đầu.
A company needs an AI tool specifically for its research department to perform deep analysis, ask questions, and generate summaries strictly based on a curated set of uploaded research papers and internal technical documents. Another department needs a broader AI assistant that can connect to various company-wide business systems (like CRM, ERP) to find information and automate tasks.
Which statement best describes the primary difference in how Gemini Enterprise and NotebookLM would serve these two departments?
-
A
Gemini Enterprise focuses on specific uploaded documents, while NotebookLM connects to broader business systems
-
B
NotebookLM is designed for deep, source-grounded reasoning on user-specified documents, while Agentspace is a comprehensive AI assistant for finding information and automating tasks across all connected business systems.
-
C
Both tools serve identical purposes and are interchangeable.
-
D
NotebookLM is for text generation, while Agentspace is only for search.
Xem giải thích
Đáp án
B — NotebookLM được thiết kế cho việc suy luận sâu, có căn cứ trên NGUỒN do người dùng chỉ định; còn Agentspace là trợ lý AI toàn diện để tìm thông tin và tự động hoá công việc.
Vì sao đúng
Hai bộ phận có hai nhu cầu khác hẳn nhau, và mỗi sản phẩm phục vụ đúng một nhu cầu.
⚠ Ánh xạ hai nhu cầu:
⚠ PHÒNG NGHIÊN CỨU
→ ⚠ bộ tài liệu ĐÃ TUYỂN CHỌN,
tự tải lên
→ ⚠ phân tích sâu, hỏi đáp,
tóm tắt CHỈ trong nguồn đó
→ ⚠ NOTEBOOKLM
⚠ PHÒNG KIA
→ ⚠ nối với NHIỀU HỆ THỐNG
toàn công ty (CRM, ERP)
→ ⚠ tìm thông tin và TỰ ĐỘNG HOÁ
công việc
→ ⚠ AGENTSPACE / GEMINI ENTERPRISE
⚠ Điểm phân biệt then chốt:
⚠ NotebookLM
→ ⚠ NGUỒN HẸP, do người dùng chọn
→ ⚠ suy luận SÂU, trích dẫn chặt
⚠ Agentspace
→ ⚠ NGUỒN RỘNG, nối hệ thống
doanh nghiệp
→ ⚠ có HÀNH ĐỘNG, tự động hoá
⚠ Vì sao ba phương án kia sai:
"Gemini Enterprise tập trung vào
tài liệu tải lên, NotebookLM nối
hệ thống rộng"
→ ⚠ ĐẢO NGƯỢC hoàn toàn
"Cả hai giống nhau, thay thế được"
→ ⚠ sai
"NotebookLM để SINH văn bản,
Agentspace CHỈ để tìm kiếm"
→ ⚠ mô tả sai cả hai
Nhất quán với #13893 (lô 145) về NotebookLM và #13936 (lô 146) về Gemini Enterprise / Agentspace. Đề này đặt hai sản phẩm cạnh nhau. Hoàn toàn nhất quán.
Ghi nhớ về chất lượng câu hỏi
⚠ Phương án đúng trong bộ đề bị CẮT CỤT chữ: đoạn cuối hiện thành "automating tas" thay vì "automating tasks", và phần mô tả NotebookLM có dấu cách thừa trước dấu phẩy. Đây là lỗi cắt chuỗi khi nhập dữ liệu, không ảnh hưởng tới nghĩa. Khoá đáp án B vẫn ĐÚNG và được giữ nguyên.
⚠ Ngoài ra, thân đề nhắc "Gemini Enterprise" trong khi các phương án dùng tên cũ "Agentspace" — đây là hai tên của cùng một sản phẩm (Agentspace được đổi tên thành Gemini Enterprise). Người học nên nhớ theo chức năng, không chỉ theo tên.
Vì sao các phương án khác sai
-
A — phương án gần nhất và là bẫy trực tiếp: nó nêu đúng hai vai trò nhưng gán ngược cho hai sản phẩm.
-
C và D — mô tả sai bản chất.
Ghi nhớ
⚠ Hai sản phẩm — bảng phải thuộc: | | ⚠ NotebookLM | ⚠ Gemini Enterprise / Agentspace | |---|---|---| | Nguồn | ⚠ tài liệu NGƯỜI DÙNG nạp | ⚠ hệ thống toàn công ty | | Phạm vi | ⚠ HẸP, có chủ đích | ⚠ RỘNG | | Điểm mạnh | ⚠ suy luận sâu, trích dẫn chặt | ⚠ tìm kiếm + TỰ ĐỘNG HOÁ | | Hành động | ⚠ không | ⚠ có — agent gọi hệ thống | | Dùng cho | ⚠ nghiên cứu, phân tích tài liệu | ⚠ năng suất nhân viên hằng ngày |
Từ khoá nhận diện:
"bộ tài liệu tự nạp, phân tích sâu, trích dẫn" → ⚠ NotebookLM "nối CRM, ERP, tự động hoá việc" → ⚠ Gemini Enterprise / Agentspace "xây agent cho sản phẩm" → Agent Builder "tìm kiếm doanh nghiệp" → Vertex AI Search
| ⚠ Vì sao "nguồn hẹp" lại là ĐIỂM MẠNH | Lý do |
|---|---|
| ⚠ Câu trả lời chỉ dựa trên tài liệu bạn chọn | ⚠ không lẫn kiến thức chung sai |
| ⚠ Trích dẫn về đúng đoạn | ⚠ kiểm chứng được từng câu |
| Biết rõ phạm vi | ⚠ ngoài nguồn thì nói không có |
| ⚠ Ít ảo giác hơn hẳn | |
| Phù hợp với | ⚠ nghiên cứu, nơi mọi khẳng định phải truy được nguồn |
| ⚠ Vì sao "nguồn rộng + hành động" hợp với nhân viên | Lý do |
|---|---|
| ⚠ Thông tin nằm rải rác nhiều hệ thống | |
| ⚠ Một nơi để hỏi thay vì mở mười công cụ | |
| Tự động hoá việc lặp lại | ⚠ tạo ticket, cập nhật CRM |
| ⚠ Tôn trọng quyền truy cập sẵn có | ⚠ mỗi người thấy phần của mình |
| ⚠ Cùng tồn tại, không thay thế nhau | Điểm |
|---|---|
| ⚠ Hai công cụ giải hai bài toán khác nhau | |
| Doanh nghiệp lớn thường dùng CẢ HAI | |
| Chọn theo | ⚠ nguồn dữ liệu và có cần HÀNH ĐỘNG hay không |
Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Nguồn là tài liệu tự chọn hay hệ thống công ty | ⚠ quyết định chọn sản phẩm nào | | Có cần AI HÀNH ĐỘNG không | ⚠ có → Agentspace | | Quyền tài liệu đã rà chưa | ⚠ làm trước khi bật diện rộng |
Và cách trả lời nhanh mọi câu hỏi so sánh sản phẩm AI: xác định NGUỒN dữ liệu và xem AI có được HÀNH ĐỘNG hay không. Hai trục đó phân biệt được gần như toàn bộ danh mục, và ổn định hơn tên gọi vốn thay đổi khá thường xuyên.