Ngân hàng đề — Google Cloud Generative AI Leader
Tìm thấy 556 câu.
A company's chatbot uses a foundation model for customer support. When asked about the warranty policy for a newly released product, the chatbot sometimes gives outdated information based on its general pre-training.
How does implementing Retrieval-Augmented Generation (RAG) with an up-to-date product knowledge base primarily address this issue?
-
A
It makes the chatbot's responses more creative and diverse.
-
B
It reduces the computational cost of running the foundation model.
-
C
It provides the foundation model with current, specific information from the knowledge base to generate more accurate and relevant answers.
-
D
It automatically fine-tunes the foundation model with new product data daily.
Xem giải thích
Đáp án
C — Nó cung cấp cho mô hình nền thông tin HIỆN HÀNH và CỤ THỂ từ kho tri thức, để sinh ra câu trả lời chính xác và liên quan hơn.
Vì sao đúng
Vấn đề là chatbot đưa thông tin lỗi thời từ kiến thức huấn luyện chung. RAG chữa đúng chỗ đó: tra kho tri thức cập nhật trước khi trả lời.
⚠ Vấn đề và cách RAG chữa:
Sản phẩm MỚI ra mắt
↓
⚠ Mô hình huấn luyện TRƯỚC đó
⚠ → knowledge cutoff
↓
⚠ Nó trả lời bằng chính sách CŨ
mà không biết là đã cũ
↓
⚠ RAG
→ ⚠ tra kho tri thức CẬP NHẬT
→ ⚠ đưa chính sách HIỆN HÀNH
vào ngữ cảnh
→ ⚠ mô hình trả lời dựa trên đó
↓
→ chính xác và có trích dẫn
⚠ Vì sao ba phương án kia sai:
"Làm câu trả lời SÁNG TẠO và
ĐA DẠNG hơn"
→ ⚠ NGƯỢC với mục tiêu: chính
sách bảo hành cần CHÍNH XÁC
"GIẢM chi phí tính toán"
→ ⚠ RAG THÊM bước tra cứu,
thường TĂNG chi phí một chút
"TỰ ĐỘNG fine-tune mô hình với
dữ liệu sản phẩm mới HẰNG NGÀY"
→ ⚠ RAG KHÔNG huấn luyện lại
mô hình — đó là điểm mạnh của nó
⚠ Gần trùng với #13900 và #13913 (lô 145) — cả ba đều là RAG chữa vấn đề thiếu thông tin riêng và cập nhật, cùng khoá. Hoàn toàn nhất quán. Và #13874 (lô 145) về knowledge cutoff.
Vì sao các phương án khác sai
-
D (tự động fine-tune hằng ngày) — phương án gần nhất và là bẫy chính: cũng nhắm tới việc cập nhật kiến thức. Nhưng RAG không huấn luyện lại; nó tra cứu tại thời điểm trả lời — và đó chính là ưu điểm của nó.
-
A và B — mô tả sai tác dụng.
Ghi nhớ
⚠ RAG chữa được gì và không chữa được gì: | Chữa được | Không chữa được | |---|---| | ⚠ Knowledge cutoff | ⚠ thiên vị của mô hình | | ⚠ Thiếu kiến thức riêng | ⚠ lỗi trong chính tài liệu nguồn | | ⚠ Ảo giác về sự kiện | ⚠ phong cách, giọng văn | | Không trích dẫn được nguồn | ⚠ năng lực suy luận của mô hình |
Từ khoá nhận diện:
"thông tin lỗi thời, sản phẩm mới" → ⚠ RAG "giọng văn chưa đúng thương hiệu" → fine-tuning "muốn sáng tạo hơn" → ⚠ tăng temperature "giảm chi phí" → ⚠ mô hình nhỏ hơn, cache, batch
| ⚠ Vì sao RAG hơn fine-tuning ở tình huống này | Lý do |
|---|---|
| ⚠ Sản phẩm ra liên tục | ⚠ huấn luyện lại mỗi lần là không khả thi |
| ⚠ Cập nhật tài liệu là có hiệu lực NGAY | |
| ⚠ Trích dẫn được nguồn | ⚠ khách kiểm chứng được |
| Rẻ hơn nhiều | |
| Lọc theo quyền truy cập được |
| ⚠ Chi phí của RAG — nói cho đúng | Chi phí |
|---|---|
| ⚠ Prompt DÀI HƠN | ⚠ có thêm đoạn tài liệu → nhiều token hơn |
| Thêm bước tra cứu | ⚠ độ trễ tăng nhẹ |
| Chi phí lưu và cập nhật chỉ mục | |
| Nhưng | ⚠ RẺ HƠN NHIỀU so với fine-tune định kỳ |
| ⚠ Việc vận hành mà RAG đòi hỏi | Việc |
|---|---|
| ⚠ CÓ NGƯỜI giữ kho tri thức cập nhật | ⚠ quan trọng nhất, hay bị quên |
| Đồng bộ khi tài liệu thay đổi | ⚠ cập nhật chỉ mục |
| ⚠ Theo dõi câu hỏi không trả lời được | ⚠ chỉ ra tài liệu còn thiếu |
| Kiểm chất lượng đoạn tìm được | |
| Xử lý tài liệu mâu thuẫn nhau | ⚠ bản cũ và bản mới cùng tồn tại |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu bảo hành có phải bản mới nhất không | ⚠ kiểm ngày cập nhật | | Có bản cũ nào còn trong chỉ mục không | ⚠ nguồn gây trả lời sai | | Hỏi về sản phẩm chưa có tài liệu thì sao | ⚠ phải nói không biết |
Và nguyên nhân phổ biến khiến một hệ thống RAG vẫn trả lời sai dù đã được dựng đúng: phiên bản tài liệu cũ chưa được gỡ khỏi chỉ mục. Mô hình tra được cả hai bản và không có cách nào biết bản nào còn hiệu lực — nên việc dọn tài liệu lỗi thời quan trọng ngang việc thêm tài liệu mới.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này TRÙNG ĐỀ BÀI với #13951 đã xuất hiện ở lô trước. Bộ đề XÁO THỨ TỰ PHƯƠNG ÁN, nên chữ cái đáp án ĐÃ ĐỔI so với lần trước — nội dung đáp án thì không đổi.
⚠ Bài học khi ôn: nhớ theo NỘI DUNG phương án, đừng nhớ theo chữ cái. Cùng một câu hỏi có thể xuất hiện với thứ tự phương án khác nhau trong các đề khác nhau.
A financial services company uses Google Cloud's AI platform to build a model for credit risk assessment. It is critical that their proprietary customer financial data, used for training and inference, remains confidential and is NOT used by Google to train its general-purpose foundation models.
Which Google Cloud principle or feature gives them assurance regarding this data control?
-
A
The auto-scaling capabilities of the platform.
-
B
Google Cloud's policy of data isolation and not using enterprise customer data to train general models.
-
C
The availability of TPUs for faster model training.
-
D
The open-source nature of some Google AI tools.
Xem giải thích
Đáp án
B — Chính sách của Google Cloud về cô lập dữ liệu và không dùng dữ liệu khách hàng doanh nghiệp để huấn luyện mô hình dùng chung.
Vì sao đúng
Mối lo của công ty tài chính là dữ liệu tài chính độc quyền của khách hàng phải giữ bí mật và KHÔNG bị Google dùng để huấn luyện mô hình nền dùng chung. Chỉ chính sách dữ liệu trả lời được điều đó.
⚠ Hai yêu cầu khớp:
"dữ liệu ĐỘC QUYỀN giữ BÍ MẬT"
→ ⚠ cô lập dữ liệu, mã hoá, IAM
"KHÔNG dùng để huấn luyện mô hình
dùng chung"
→ ⚠ CAM KẾT trong điều khoản
dịch vụ doanh nghiệp
⚠ Vì sao ba phương án kia sai:
"Khả năng tự co giãn"
→ ⚠ về quy mô
"TPU giúp huấn luyện nhanh hơn"
→ ⚠ về hiệu năng
"Tính mã nguồn mở của một số công cụ"
→ ⚠ về chống khoá chân
⚠ Gần trùng với #13940 (lô 146) — gần như cùng đề bài, cùng khoá. ⚠ Bộ đề đã XÁO THỨ TỰ: lần trước đáp án ở chữ D, lần này ở chữ B. Nội dung không đổi. Và #13895 (lô 145) cùng hướng.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này gần như trùng #13940 (lô 146) nhưng chữ cái đáp án đã đổi. Đây là minh hoạ rõ cho việc bộ đề xáo thứ tự phương án: nhớ theo nội dung, đừng nhớ theo chữ cái.
Vì sao các phương án khác sai
-
D (mã nguồn mở) — phương án gần nhất vì cũng liên quan tới quyền kiểm soát của khách hàng, nhưng nó nói về mang khối lượng công việc đi nơi khác, không phải về việc dữ liệu có bị dùng huấn luyện hay không.
-
A và C — về quy mô và hiệu năng.
Ghi nhớ
⚠ Kiểm soát dữ liệu doanh nghiệp — bảng phải thuộc: | Kiểm soát | Nội dung | |---|---| | ⚠ Cam kết dữ liệu | ⚠ dữ liệu doanh nghiệp KHÔNG dùng huấn luyện mô hình chung | | ⚠ Cô lập dữ liệu | ⚠ khách này không lẫn khách khác | | Data residency | ⚠ chọn vùng lưu và xử lý | | VPC Service Controls | ⚠ ngăn dữ liệu rời ranh giới | | CMEK | ⚠ khoá mã hoá do khách quản | | IAM, audit log | |
Từ khoá nhận diện:
"có bị dùng huấn luyện không" → ⚠ cam kết dữ liệu doanh nghiệp "dữ liệu phải ở trong vùng nào" → ⚠ data residency "chống khoá chân" → mã nguồn mở "tải lớn, uptime" → scalability, reliability
| ⚠ Ba câu hỏi mọi ngành có quản lý đều hỏi | Câu hỏi |
|---|---|
| ⚠ Dữ liệu của tôi có được dùng huấn luyện không | ⚠ câu hỏi số một |
| Dữ liệu lưu và xử lý ở đâu | |
| Ai truy cập được, có ghi lại không | |
| Lưu ý | ⚠ đọc điều khoản của ĐÚNG dịch vụ đang dùng |
| ⚠ Tiêu dùng và doanh nghiệp — điều khoản KHÁC NHAU | Khác |
|---|---|
| ⚠ Đừng suy từ sản phẩm này sang sản phẩm khác | |
| Bản doanh nghiệp có IAM, audit, VPC-SC | |
| ⚠ Dữ liệu nhạy cảm → luôn dùng bản doanh nghiệp | |
| Rủi ro thực tế | ⚠ nhân viên dùng bản tiêu dùng cho việc công ty |
| ⚠ Riêng chấm điểm tín dụng | Lưu ý |
|---|---|
| ⚠ Phải GIẢI THÍCH ĐƯỢC quyết định | ⚠ luật yêu cầu ở nhiều nơi |
| ⚠ Cân nhắc mô hình giải thích được | ⚠ thay vì mô hình sinh hộp đen |
| Đo chênh lệch theo nhóm | ⚠ rủi ro phân biệt đối xử |
| ⚠ Người ra quyết định cuối | |
| Lưu vết đầy đủ | ⚠ để giải trình khi kiểm toán |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã đọc điều khoản của đúng dịch vụ chưa | ⚠ đừng suy đoán | | Dữ liệu lưu ở vùng nào | ⚠ yêu cầu chủ quyền dữ liệu | | Nhân viên có dùng công cụ ngoài không | ⚠ rủi ro thực tế lớn nhất |
Và bài học từ việc câu hỏi này xuất hiện lại với chữ cái khác: đừng bao giờ ghi nhớ đáp án theo vị trí chữ cái. Bộ đề xáo thứ tự phương án, nên chỉ có việc hiểu nội dung mới giúp trả lời đúng ở mọi phiên bản.
An employee at a large consulting firm spends a significant amount of time summarizing long meeting transcripts from Google Meet and drafting follow-up emails in Gmail. They are looking for a way to automate these tasks directly within their existing Google Workspace tools to improve productivity.
Which Google Cloud prebuilt gen AI offering would directly address this need?
-
A
Vertex AI Search
-
B
Gemini for Google Workspace
-
C
The standalone Gemini app
-
D
NotebookLM
Xem giải thích
Đáp án
B — Gemini for Google Workspace.
Vì sao đúng
Nhân viên muốn tự động hoá việc NGAY TRONG công cụ đang dùng — tóm tắt bản ghi Google Meet và soạn thư trong Gmail. Đó là định vị của Gemini for Workspace.
⚠ Vì sao "ngay trong công cụ" là dữ kiện quyết định:
Dùng ứng dụng AI riêng
↓
⚠ phải COPY bản ghi ra
⚠ dán vào chỗ khác
⚠ copy kết quả quay lại
⚠ và ⚠ dữ liệu công ty đi ra ngoài
↓
⚠ GEMINI FOR WORKSPACE
→ ⚠ ngay trong Gmail, Docs, Meet
→ ⚠ đã có ngữ cảnh của tài liệu
→ ⚠ tôn trọng quyền truy cập sẵn có
→ ⚠ dữ liệu KHÔNG rời khỏi
ranh giới Workspace
⚠ Vì sao ba phương án kia sai:
"Ứng dụng Gemini độc lập"
→ ⚠ trợ lý tốt, nhưng NGOÀI
luồng làm việc; phải copy-paste
"NotebookLM"
→ ⚠ nghiên cứu và tổng hợp trên
bộ tài liệu bạn nạp vào —
không tích hợp Gmail/Meet
"Vertex AI Search"
→ ⚠ tìm kiếm doanh nghiệp
Đối chiếu #13865 (cùng lô) — đề đó khoá ứng dụng Gemini và Gems cho trợ lý cá nhân tuỳ biến. Đề này khoá Gemini for Workspace vì yêu cầu là ngay trong Gmail và Meet. Không mâu thuẫn — khác nơi công việc diễn ra.
Vì sao các phương án khác sai
-
C (ứng dụng Gemini độc lập) — phương án gần nhất và là bẫy chính: nó làm được cả hai việc về mặt kỹ thuật. Nhưng đề nhấn mạnh "trực tiếp trong công cụ Workspace sẵn có".
-
D (NotebookLM) và B (Vertex AI Search) — phục vụ mục đích khác.
Ghi nhớ
⚠ Gemini xuất hiện ở đâu — bảng phải thuộc: | Nơi | Dùng khi | |---|---| | ⚠ Gemini for Workspace | ⚠ ngay trong Gmail, Docs, Meet, Sheets | | ⚠ Ứng dụng Gemini (+ Gems) | ⚠ trợ lý cá nhân, tuỳ biến việc lặp lại | | ⚠ NotebookLM | ⚠ nghiên cứu trên bộ tài liệu bạn nạp | | Gemini Code Assist | lập trình viên | | Vertex AI / Gemini API | ⚠ xây ứng dụng riêng |
Từ khoá nhận diện:
"ngay trong Gmail, Docs, Meet" → ⚠ Gemini for Workspace "trợ lý cá nhân, tuỳ biến" → ứng dụng Gemini + Gems "nạp tài liệu để nghiên cứu sâu" → ⚠ NotebookLM "tìm kiếm doanh nghiệp" → Vertex AI Search
| ⚠ Gemini for Workspace làm được gì | Việc |
|---|---|
| ⚠ Meet: tóm tắt cuộc họp, ghi chú | ⚠ đề này |
| ⚠ Gmail: soạn thư, tóm tắt luồng thư | |
| Docs: viết nháp, viết lại, tóm tắt | |
| Sheets: tạo bảng, phân loại dữ liệu | |
| Slides: sinh hình minh hoạ | |
| Drive: hỏi đáp trên tài liệu |
| ⚠ Vì sao tích hợp quan trọng | Lý do |
|---|---|
| ⚠ Không phải copy-paste dữ liệu ra ngoài | ⚠ giảm rủi ro rò rỉ |
| ⚠ Tôn trọng quyền truy cập sẵn có | ⚠ AI chỉ thấy thứ bạn được thấy |
| Có sẵn ngữ cảnh của tài liệu | ⚠ kết quả sát hơn |
| Quản trị và audit tập trung | |
| Ít ma sát → người ta thật sự dùng |
| ⚠ Lưu ý khi bật cho cả tổ chức | Lưu ý |
|---|---|
| ⚠ RÀ SOÁT quyền tài liệu TRƯỚC | ⚠ AI làm tài liệu chia sẻ rộng dễ tìm hơn nhiều |
| Triển khai theo nhóm | ⚠ đừng bật đồng loạt |
| ⚠ Tóm tắt cuộc họp là dữ liệu nhạy cảm | ⚠ quy định về ghi âm và lưu giữ |
| Đào tạo cách dùng | ⚠ và cách kiểm chứng kết quả |
| ⚠ Luôn đọc lại trước khi gửi | ⚠ bản nháp không phải bản gửi |
| ⚠ Việc AI làm tốt và chưa tốt trong tóm tắt họp | Điểm |
|---|---|
| ⚠ Tốt: tóm nội dung, liệt kê việc cần làm | |
| ⚠ Chưa tốt: hiểu sắc thái, chuyện chưa nói ra | |
| Chưa tốt: tên riêng, thuật ngữ nội bộ | ⚠ hay ghi sai |
| Vì vậy | ⚠ người chủ trì vẫn nên đọc lại bản tóm tắt |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyền tài liệu đã rà chưa | ⚠ làm TRƯỚC khi bật | | Tóm tắt có ghi đúng việc cần làm không | ⚠ kiểm vài cuộc họp thật | | Có chính sách về lưu bản ghi không | ⚠ dữ liệu nhạy cảm |
Và giá trị thật của việc tích hợp AI ngay trong công cụ làm việc thường không nằm ở năng lực mô hình, mà ở chỗ nó xoá bỏ bước copy-paste. Bước đó nhỏ nhưng đủ để phần lớn người dùng bỏ cuộc — và nó cũng chính là bước đưa dữ liệu công ty ra khỏi ranh giới kiểm soát.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này TRÙNG ĐỀ BÀI với #13883 đã xuất hiện ở lô trước. Bộ đề XÁO THỨ TỰ PHƯƠNG ÁN, nên chữ cái đáp án ĐÃ ĐỔI so với lần trước — nội dung đáp án thì không đổi.
⚠ Bài học khi ôn: nhớ theo NỘI DUNG phương án, đừng nhớ theo chữ cái. Cùng một câu hỏi có thể xuất hiện với thứ tự phương án khác nhau trong các đề khác nhau.
A legal firm wants to use generative AI to analyze and summarize entire merger contracts that are typically 50-100 pages long. The firm's IT consultant explains that some AI models can only process a few pages at a time, while others can handle the full document length, but cost significantly more per analysis.
From a business perspective, what model characteristic is most critical for ensuring a complete and coherent analysis of these documents?
-
A
A large context window to handle the full document length.
-
B
Temperature settings for creative vs. precise outputs.
-
C
Multimodal features for processing different file types.
-
D
Fine-tuning capabilities for legal terminology.
Xem giải thích
Đáp án
A — Cửa sổ ngữ cảnh lớn để xử lý được toàn bộ độ dài tài liệu.
Vì sao đúng
Đề nêu thẳng ràng buộc: một số mô hình chỉ xử lý được vài trang một lần, số khác xử lý được cả tài liệu nhưng đắt hơn nhiều. Đó chính là khác biệt về cửa sổ ngữ cảnh.
⚠ Vì sao là ràng buộc quyết định:
Hợp đồng sáp nhập 50–100 trang
↓
⚠ vài chục nghìn token
↓
⚠ Cửa sổ nhỏ hơn → phải CHIA ĐOẠN
↓
⚠ Mất liên hệ giữa các điều khoản
⚠ Điều khoản trang 10 tham chiếu
định nghĩa trang 3
↓
→ ⚠ phân tích KHÔNG mạch lạc
⚠ Vì sao ba phương án kia sai:
"Temperature cho sáng tạo hay
chính xác"
→ ⚠ nên đặt THẤP, nhưng không
giải quyết ĐỘ DÀI
"Multimodal cho nhiều loại tệp"
→ ⚠ hợp đồng là văn bản
"Fine-tuning cho thuật ngữ pháp lý"
→ ⚠ giúp PHONG CÁCH; mô hình vẫn
không đọc nổi tài liệu vượt
cửa sổ ngữ cảnh
⚠ Gần trùng với #14015 (lô 148) — gần như cùng đề bài, cùng khoá cửa sổ ngữ cảnh. ⚠ Bộ đề đã XÁO THỨ TỰ: lần trước đáp án ở chữ D, lần này ở chữ A. Nội dung không đổi. Và #13931 (lô 146).
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này gần như trùng #14015 (lô 148), chỉ khác vài chữ ở phần kết ("từ góc độ nghiệp vụ"), nên hash MD5 không bắt được. ⚠ Chữ cái đáp án đã đổi từ D sang A.
⚠ Bài học: hai câu gần trùng có thể xuất hiện ở các lô khác nhau với thứ tự phương án khác nhau — luôn đọc nội dung phương án, đừng dựa vào vị trí.
Vì sao các phương án khác sai
-
D (fine-tuning cho thuật ngữ) — phương án gần nhất và là bẫy mạnh trong bối cảnh pháp lý. Nhưng dù mô hình hiểu thuật ngữ tốt tới đâu, nó vẫn không đọc nổi tài liệu vượt quá cửa sổ ngữ cảnh.
-
B và C — không phải ràng buộc đề nêu.
Ghi nhớ
⚠ Tiêu chí chọn mô hình theo thứ tự — bảng phải thuộc: | Bước | Tiêu chí | |---|---| | 1 | ⚠ modality | | ⚠ 2 | ⚠ CỬA SỔ NGỮ CẢNH — đề này | | 3 | chất lượng trên ví dụ thật | | 4 | ⚠ chi phí và độ trễ | | 5 | tuỳ biến |
Từ khoá nhận diện:
"tài liệu rất dài, xử lý toàn bộ" → ⚠ context window "thuật ngữ, văn phong ngành" → fine-tuning "chính xác, bám nguồn" → ⚠ temperature thấp "nhiều loại tệp" → multimodal
| ⚠ Ba cách xử lý tài liệu dài | Cách |
|---|---|
| ⚠ Cửa sổ lớn — nhét cả tài liệu | ⚠ đơn giản, đắt |
| ⚠ Chia đoạn + tóm tắt phân cấp | ⚠ rẻ hơn, có thể mất liên hệ |
| ⚠ RAG — lấy đoạn liên quan | ⚠ tốt cho HỎI ĐÁP, không cho tóm tắt toàn bộ |
| Với hợp đồng | ⚠ cửa sổ lớn đáng tiền vì tham chiếu chéo nhiều |
| ⚠ Vì sao hợp đồng khó chia đoạn | Lý do |
|---|---|
| ⚠ Định nghĩa ở đầu, dùng khắp nơi | |
| ⚠ Điều khoản tham chiếu chéo | |
| ⚠ Điều khoản LOẠI TRỪ đảo ngược nghĩa | ⚠ bỏ sót là hiểu sai hoàn toàn |
| Phụ lục bổ sung cho điều chính |
| ⚠ Đánh đổi của cửa sổ lớn | Đánh đổi |
|---|---|
| ⚠ Đắt hơn — trả theo token đầu vào | |
| ⚠ Chậm hơn | |
| ⚠ "Lost in the middle" | ⚠ có thể bỏ sót phần giữa |
| Giảm bằng | ⚠ đặt phần quan trọng ở đầu/cuối, hỏi kiểm tra phần giữa |
| ⚠ Việc bắt buộc với AI xử lý hợp đồng | Việc |
|---|---|
| ⚠ Temperature THẤP | |
| ⚠ Yêu cầu TRÍCH DẪN điều khoản | |
| ⚠ Luật sư rà soát | ⚠ HITL bắt buộc |
| Ghi rõ là bản hỗ trợ, không phải tư vấn | |
| ⚠ Bảo mật tài liệu | ⚠ hợp đồng sáp nhập cực nhạy cảm |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu dài bao nhiêu token | ⚠ ước lượng trước khi chọn mô hình | | Có bỏ sót điều khoản ở giữa không | ⚠ thử hỏi về nội dung giữa tài liệu | | Chi phí mỗi lần phân tích | ⚠ nhân với số hợp đồng mỗi tháng |
Và điều đáng kiểm nhất khi dùng cửa sổ ngữ cảnh lớn cho hợp đồng: hỏi thử về một điều khoản nằm ở giữa tài liệu. Mô hình chú ý tới phần đầu và cuối tốt hơn phần giữa, và với hợp đồng thì một điều khoản bị bỏ sót có thể là điều khoản quan trọng nhất.
A company's sales department maintains customer information in a relational database. Each customer record has well-defined fields such as CustomerID, Name, Address, Email, and LastPurchaseDate, organized in tables with rows and columns.
What type of data is primarily stored in this relational database?
-
A
Structured Data
-
B
Unstructured Data
-
C
Qualitative Data
-
D
Semi-structured Data
Xem giải thích
Đáp án
A — Structured Data (dữ liệu có cấu trúc).
Vì sao đúng
Cơ sở dữ liệu quan hệ với các trường xác định rõ (CustomerID, Name, Address, Email, LastPurchaseDate) tổ chức thành bảng có hàng và cột — đó là định nghĩa của dữ liệu có cấu trúc.
⚠ Dấu hiệu của dữ liệu có cấu trúc:
⚠ Có SCHEMA định trước
⚠ Mỗi trường có KIỂU dữ liệu rõ
⚠ Tổ chức thành HÀNG và CỘT
⚠ Truy vấn được bằng SQL
↓
⚠ Đề nêu đủ cả bốn dấu hiệu
⚠ Vì sao ba phương án kia sai:
"Semi-structured"
→ ⚠ JSON, XML: có thẻ nhưng
KHÔNG có schema cứng
"Unstructured"
→ ⚠ ảnh, video, văn bản tự do
"Qualitative Data"
→ ⚠ thuật ngữ về dữ liệu ĐỊNH TÍNH
(mô tả, không đo được bằng số)
→ ⚠ không phải cách phân loại
theo CẤU TRÚC
Nhất quán với #13525 và #13553 (lô 144) về ba loại dữ liệu, và #13888 (lô 145) về ghi chú y khoa phi cấu trúc. Hoàn toàn nhất quán — đây là mặt đối lập.
Vì sao các phương án khác sai
-
D (semi-structured) — phương án gần nhất và là bẫy chính: cũng có tổ chức nhất định. Nhưng bán cấu trúc không có schema cứng, còn đây là bảng quan hệ với trường xác định rõ.
-
B (unstructured) — trái hẳn.
-
C (định tính) — thuộc cách phân loại khác.
Ghi nhớ
⚠ Ba loại dữ liệu theo cấu trúc — bảng phải thuộc: | Loại | Ví dụ | Lưu ở | |---|---|---| | ⚠ Có cấu trúc | ⚠ bảng CSDL, CSV, bảng tính | ⚠ Cloud SQL, BigQuery | | ⚠ Bán cấu trúc | ⚠ JSON, XML, log, YAML | ⚠ Firestore, BigQuery | | ⚠ Phi cấu trúc | ⚠ ảnh, video, âm thanh, văn bản tự do | ⚠ Cloud Storage |
Từ khoá nhận diện:
"hàng, cột, trường xác định rõ" → ⚠ có cấu trúc "JSON, XML, có thẻ nhưng linh hoạt" → bán cấu trúc "ảnh, video, văn bản tự do" → phi cấu trúc "đã được gán nhãn" → ⚠ labeled — chiều KHÁC
| ⚠ Hai chiều phân loại ĐỘC LẬP | Chiều |
|---|---|
| ⚠ Theo CẤU TRÚC | ⚠ có / bán / phi cấu trúc |
| ⚠ Theo NHÃN | ⚠ đã gán nhãn / chưa gán nhãn |
| Ví dụ | ⚠ ảnh ĐÃ GÁN NHÃN vừa phi cấu trúc vừa labeled |
| Đề thi | ⚠ hay trộn hai chiều vào cùng bộ đáp án |
| ⚠ Dữ liệu có cấu trúc dùng làm gì với AI sinh | Cách dùng |
|---|---|
| ⚠ Grounding cho chatbot | ⚠ tra đơn hàng, thông tin khách |
| ⚠ Tool cho agent | ⚠ truy vấn CSDL rồi trả lời |
| Huấn luyện mô hình dự đoán | ⚠ AutoML Tables, BigQuery ML |
| ⚠ Sinh SQL từ câu hỏi tự nhiên | ⚠ text-to-SQL |
| Cá nhân hoá nội dung | ⚠ dựa trên hồ sơ khách |
| ⚠ Lưu ý về dữ liệu khách hàng | Lưu ý |
|---|---|
| ⚠ Chứa PII: tên, email, địa chỉ | |
| ⚠ Che trước khi đưa vào prompt | ⚠ Sensitive Data Protection |
| Kiểm cơ sở pháp lý để dùng | ⚠ cá nhân hoá đụng quyền riêng tư |
| Không ghi PII vào log | |
| ⚠ Quyền truy cập theo vai trò |
Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có schema cố định không | có → ⚠ có cấu trúc | | Truy vấn được bằng SQL không | ⚠ dấu hiệu rõ nhất | | Có PII trong đó không | ⚠ gần như chắc chắn có với dữ liệu khách hàng |
Và điều đáng nhớ khi hai cách phân loại dữ liệu cùng xuất hiện trong một bộ đáp án: "có cấu trúc" và "đã gán nhãn" trả lời hai câu hỏi khác nhau. Câu đầu hỏi dữ liệu được TỔ CHỨC ra sao, câu sau hỏi nó có kèm ĐÁP ÁN cho việc huấn luyện hay không.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này TRÙNG ĐỀ BÀI với #13949 đã xuất hiện ở lô trước. Bộ đề XÁO THỨ TỰ PHƯƠNG ÁN, nên chữ cái đáp án ĐÃ ĐỔI so với lần trước — nội dung đáp án thì không đổi.
⚠ Bài học khi ôn: nhớ theo NỘI DUNG phương án, đừng nhớ theo chữ cái. Cùng một câu hỏi có thể xuất hiện với thứ tự phương án khác nhau trong các đề khác nhau.
A financial advisory firm uses a generative AI model to draft initial investment recommendations for clients. To ensure accuracy and compliance, all AI-generated drafts must be reviewed and approved by a certified financial advisor before being sent to clients.
This process of incorporating expert human oversight into the AI workflow is an example of which recommended practice?
-
A
Human in the Loop (HITL)
-
B
Grounding
-
C
Prompt Engineering
-
D
Fine-tuning
Xem giải thích
Đáp án
A — Human in the Loop (HITL) — con người trong vòng lặp.
Vì sao đúng
Bản nháp do AI sinh ra phải được chuyên gia có chứng chỉ xem xét và phê duyệt trước khi gửi cho khách hàng. Đó đúng là mô hình Human in the Loop.
⚠ Vì sao HITL cần thiết ở đây:
Khuyến nghị đầu tư
↓
⚠ Hậu quả TÀI CHÍNH thật
⚠ Ràng buộc PHÁP LÝ và tuân thủ
⚠ Mô hình có thể ẢO GIÁC
↓
⚠ AI làm phần SOẠN THẢO
⚠ Người làm phần CHỊU TRÁCH NHIỆM
↓
→ ⚠ nhanh hơn, mà vẫn có
người chịu trách nhiệm cuối
⚠ Vì sao ba phương án kia sai:
"Fine-tuning"
→ ⚠ huấn luyện thêm mô hình
trên dữ liệu riêng
"Prompt Engineering"
→ ⚠ viết câu lệnh cho tốt
"Grounding"
→ ⚠ nối câu trả lời với nguồn
dữ liệu tin cậy
⚠ Cả ba đều cải thiện chất lượng đầu ra, nhưng không phải cơ chế giám sát của con người.
Vì sao các phương án khác sai
-
B (Grounding) — phương án gần nhất vì cũng nhằm đảm bảo tính chính xác, nhưng nó làm điều đó bằng cách cung cấp nguồn dữ liệu cho mô hình, không phải bằng người duyệt.
-
D (fine-tuning) và C (prompt engineering) — kỹ thuật cải thiện mô hình, không phải quy trình duyệt.
Ghi nhớ
⚠ Bốn kỹ thuật — phân biệt cho rõ: | Kỹ thuật | Làm gì | |---|---| | ⚠ Human in the Loop | ⚠ NGƯỜI duyệt trước khi dùng | | Grounding / RAG | ⚠ nối với nguồn dữ liệu tin cậy | | Fine-tuning | ⚠ huấn luyện thêm trên dữ liệu riêng | | Prompt engineering | ⚠ viết câu lệnh tốt hơn |
Từ khoá nhận diện:
"người duyệt trước khi gửi" → ⚠ HITL "nối với dữ liệu công ty" → grounding "dạy mô hình phong cách riêng" → fine-tuning "viết lại câu lệnh cho rõ" → prompt engineering
| ⚠ Khi nào BẮT BUỘC có HITL | Khi |
|---|---|
| ⚠ Hậu quả tài chính hoặc pháp lý | ⚠ đề này |
| Y tế, chẩn đoán | |
| Tuyển dụng, tín dụng | ⚠ rủi ro phân biệt đối xử |
| ⚠ Nội dung công bố ra ngoài | ⚠ rủi ro thương hiệu |
| Hành động không đảo ngược được | ⚠ xoá dữ liệu, chuyển tiền |
| ⚠ Ba mức giám sát của con người | Mức |
|---|---|
| ⚠ Human IN the loop | ⚠ người duyệt TỪNG kết quả — chặt nhất |
| ⚠ Human ON the loop | ⚠ người GIÁM SÁT, can thiệp khi cần |
| Human OUT of the loop | ⚠ hoàn toàn tự động — chỉ cho việc rủi ro thấp |
| Chọn theo | ⚠ mức độ hậu quả nếu sai |
| ⚠ Thiết kế HITL cho hiệu quả | Nguyên tắc |
|---|---|
| ⚠ Đừng biến người thành con dấu | ⚠ duyệt hàng trăm bản/giờ là duyệt hình thức |
| ⚠ Làm nổi bật chỗ mô hình KHÔNG CHẮC | ⚠ để người tập trung đúng chỗ |
| ⚠ Hiện nguồn trích dẫn | ⚠ kiểm nhanh hơn |
| ⚠ Ghi lại điều chỉnh của người | ⚠ dữ liệu quý để cải thiện mô hình |
| Đo tỉ lệ sửa | ⚠ cho biết mô hình đang tốt tới đâu |
| ⚠ HITL liên quan tới nguyên tắc AI có trách nhiệm | Liên quan |
|---|---|
| ⚠ Accountability | ⚠ AI chịu trách nhiệm trước con người |
| Explainability | ⚠ người duyệt phải hiểu được |
| An toàn | ⚠ giảm rủi ro đầu ra có hại |
| Tuân thủ | ⚠ nhiều ngành BẮT BUỘC có người quyết |
Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Người duyệt có đủ thời gian không | ⚠ quá tải thì HITL chỉ còn hình thức | | Tỉ lệ sửa là bao nhiêu | ⚠ rất thấp có thể nghĩa là không ai đọc thật | | Ai chịu trách nhiệm khi sai | ⚠ phải rõ ràng trước khi triển khai |
Và cái bẫy phổ biến nhất khi triển khai HITL: giao cho một người khối lượng duyệt lớn tới mức việc duyệt trở thành hình thức. Khi đó tổ chức có đủ giấy tờ về quy trình giám sát, nhưng không thực sự có sự giám sát nào — và đó là tình huống rủi ro hơn cả việc không có HITL, vì nó tạo cảm giác an toàn giả.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này TRÙNG ĐỀ BÀI với #13860 đã xuất hiện ở lô trước. Bộ đề XÁO THỨ TỰ PHƯƠNG ÁN, nên chữ cái đáp án ĐÃ ĐỔI so với lần trước — nội dung đáp án thì không đổi.
⚠ Bài học khi ôn: nhớ theo NỘI DUNG phương án, đừng nhớ theo chữ cái. Cùng một câu hỏi có thể xuất hiện với thứ tự phương án khác nhau trong các đề khác nhau.
A research lab is training a complex generative AI model that benefits significantly from massively parallel processing capabilities offered by specialized hardware accelerators. They need to choose between different types of accelerators available on Google Cloud for their training workloads.
Which of the following are key examples of such specialized AI accelerators offered by Google Cloud?
-
A
Tensor Processing Units (TPUs) and Graphics Processing Units (GPUs)
-
B
Cloud Spanner and Bigtable
-
C
Virtual Private Cloud (VPC) and Cloud Load Balancing
-
D
Cloud CPUs and Persistent Disks
Xem giải thích
Đáp án
A — Tensor Processing Units (TPU) và Graphics Processing Units (GPU).
Vì sao đúng
Hai loại bộ tăng tốc AI chuyên dụng trên Google Cloud, đều mạnh ở xử lý song song quy mô lớn cho khối lượng công việc huấn luyện.
⚠ Hai bộ tăng tốc:
⚠ TPU
→ ⚠ chip do GOOGLE thiết kế
riêng cho ML
→ ⚠ tối ưu cho phép NHÂN MA TRẬN
→ mạnh nhất với mô hình rất lớn,
TensorFlow/JAX
⚠ GPU
→ ⚠ hàng nghìn lõi song song
→ ⚠ LINH HOẠT hơn
→ hệ sinh thái rộng, hợp
hầu hết khối lượng ML
⚠ Vì sao ba phương án kia sai:
"Cloud Spanner và Bigtable"
→ ⚠ CƠ SỞ DỮ LIỆU
"Cloud CPUs và Persistent Disks"
→ ⚠ CPU đa năng và ĐĨA —
không phải bộ tăng tốc AI
"VPC và Cloud Load Balancing"
→ ⚠ MẠNG
Nhất quán với #13868 (lô 145) và #13540 (lô 144) — hai đề đó khoá riêng TPU khi đề nhấn "chip do Google thiết kế". Đối chiếu #13921 (cùng lô) khoá AI Hypercomputer khi đề hỏi kiến trúc mức HỆ THỐNG. Không mâu thuẫn — ba mức: chip, hai loại chip, cả hệ thống.
Vì sao các phương án khác sai
-
D (CPU và Persistent Disk) — phương án gần nhất vì đó là tài nguyên tính toán và lưu trữ thật, nhưng CPU không phải bộ tăng tốc chuyên dụng cho AI.
-
B và C — thuộc lĩnh vực dữ liệu và mạng.
Ghi nhớ
⚠ Ba loại bộ xử lý — bảng phải thuộc: | Loại | Mạnh ở | Dùng khi | |---|---|---| | CPU | ⚠ đa năng, tuần tự | ⚠ tiền xử lý, mô hình nhỏ | | ⚠ GPU | ⚠ song song, LINH HOẠT | ⚠ hầu hết bài toán ML | | ⚠ TPU | ⚠ nhân ma trận, Google thiết kế | ⚠ mô hình RẤT lớn |
Từ khoá nhận diện:
"bộ tăng tốc AI chuyên dụng" → ⚠ TPU và GPU "chip do Google thiết kế" → ⚠ TPU "kiến trúc mức hệ thống, quy mô cực lớn" → ⚠ AI Hypercomputer "nền tảng quản vòng đời ML" → Vertex AI
| ⚠ Chọn TPU hay GPU | Tiêu chí |
|---|---|
| ⚠ Mô hình rất lớn, lô lớn, TensorFlow/JAX | ⚠ TPU |
| ⚠ Cần linh hoạt, dùng PyTorch, thư viện đa dạng | ⚠ GPU |
| Phép tính tuỳ biến nhiều | ⚠ GPU |
| Khối lượng rất lớn, cần hiệu suất năng lượng | ⚠ TPU |
| Thực tế | ⚠ thử cả hai trên khối lượng thật rồi so |
| ⚠ Đo hiệu quả cho đúng | Cách |
|---|---|
| ⚠ Đừng so GIÁ MỖI GIỜ | ⚠ so CHI PHÍ cho MỘT LẦN huấn luyện |
| ⚠ Đo mức sử dụng bộ tăng tốc | ⚠ thấp = nghẽn ở dữ liệu, không ở chip |
| Tính cả thời gian chờ có tài nguyên | ⚠ quota, khả dụng |
| Spot / preemptible | ⚠ giảm mạnh, nhớ checkpoint |
| ⚠ Nút thắt thật khi huấn luyện | Nút thắt |
|---|---|
| ⚠ Đường ống dữ liệu không theo kịp | ⚠ phổ biến nhất |
| Mạng giữa các chip | ⚠ khi huấn luyện phân tán |
| Bộ nhớ trên chip | ⚠ giới hạn kích thước mô hình |
| Quota | ⚠ xin nâng trước |
| Kiểm bằng | ⚠ mức sử dụng bộ tăng tốc — con số quan trọng nhất |
| ⚠ Đừng quên phần suy luận | Điểm |
|---|---|
| ⚠ Huấn luyện là việc MỘT LẦN | |
| ⚠ Suy luận chạy MÃI MÃI | ⚠ tổng chi phí thường lớn hơn |
| Suy luận có thể dùng chip nhỏ hơn | |
| ⚠ Batch prediction rẻ hơn endpoint nhiều |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mức sử dụng bộ tăng tốc bao nhiêu | ⚠ thấp thì đừng mua thêm chip | | Chi phí một lần huấn luyện | ⚠ so cả hai loại chip | | Có checkpoint chưa | ⚠ bắt buộc với Spot |
Và con số đáng nhìn trước khi quyết định nâng cấp phần cứng huấn luyện: mức sử dụng bộ tăng tốc hiện tại. Nếu nó đang ở mức thấp, thì nút thắt nằm ở đường ống dữ liệu — và mua chip mạnh hơn chỉ làm phần đang nhàn rỗi trở nên đắt hơn.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này TRÙNG ĐỀ BÀI với #13942 đã xuất hiện ở lô trước. Bộ đề XÁO THỨ TỰ PHƯƠNG ÁN, nên chữ cái đáp án ĐÃ ĐỔI so với lần trước — nội dung đáp án thì không đổi.
⚠ Bài học khi ôn: nhớ theo NỘI DUNG phương án, đừng nhớ theo chữ cái. Cùng một câu hỏi có thể xuất hiện với thứ tự phương án khác nhau trong các đề khác nhau.
A developer is writing a custom tool in Python for a generative AI agent. The tool needs to programmatically interact with several Google Cloud services, such as retrieving data from BigQuery and storing results in Cloud Storage. The developer wants to use pre-built, language-specific modules to simplify this process without crafting raw HTTP requests.
What provides these language-idiomatic client modules for interacting with Google Cloud APIs?
-
A
Cloud SDK
-
B
Google Cloud Console
-
C
REST APIs
-
D
Cloud Client Libraries
Xem giải thích
Đáp án
D — Cloud Client Libraries.
Vì sao đúng
Đề nêu đúng ba yêu cầu: module dựng sẵn, theo từng ngôn ngữ, và không phải tự viết HTTP thô. Đó chính là định nghĩa của Cloud Client Libraries.
⚠ Bốn cách gọi Google Cloud — bảng phải thuộc:
⚠ Cloud Client Libraries
→ THƯ VIỆN theo ngôn ngữ
→ ⚠ pip install google-cloud-bigquery
→ ⚠ viết code Python tự nhiên
→ ⚠ ĐỀ NÀY
Cloud SDK (gcloud CLI)
→ ⚠ công cụ DÒNG LỆNH
→ gõ trong terminal, không nhúng
vào code Python
Google Cloud Console
→ ⚠ giao diện WEB, bấm chuột
REST API
→ ⚠ HTTP thô — đúng thứ đề bảo
MUỐN TRÁNH
⚠ Code minh hoạ khác biệt:
Client Library:
client = bigquery.Client()
rows = client.query(sql).result()
REST API thô:
⚠ tự lấy token, tự ký, tự đóng gói
JSON, tự xử lý retry, tự phân trang
Vì sao các phương án khác sai
-
A (Cloud SDK) — phương án gây nhầm mạnh nhất vì tên nghe rất giống "bộ công cụ phát triển". Nhưng Cloud SDK là bộ công cụ dòng lệnh (
gcloud,gsutil,bq). Nó không phải thư viện đểimportvào chương trình Python. ⚠ Trong tài liệu Google, hai khái niệm này cố ý tách bạch. -
B (Console) — giao diện web bấm tay, không lập trình được. Đề nói "programmatically" — loại ngay.
-
C (REST API) — có tồn tại và dùng được, nhưng chính là thứ đề nói muốn tránh: "without crafting raw HTTP requests". Client Libraries được xây DỰA TRÊN REST API và bọc nó lại cho tiện.
Ghi nhớ
⚠ Bốn cửa vào Google Cloud — bảng phải thuộc: | Cửa | Dạng | Dùng khi | |---|---|---| | ⚠ Cloud Client Libraries | ⚠ thư viện theo ngôn ngữ | ⚠ viết ứng dụng, viết công cụ cho tác nhân | | Cloud SDK / gcloud | ⚠ dòng lệnh | script shell, CI/CD, thao tác tay | | Console | ⚠ web | khám phá, cấu hình một lần | | REST / gRPC API | ⚠ HTTP thô | ⚠ ngôn ngữ chưa có thư viện |
Từ khoá nhận diện:
"pre-built, language-specific modules" → ⚠ Client Libraries "idiomatic", "import vào code" → ⚠ Client Libraries "gõ lệnh trong terminal" → Cloud SDK "raw HTTP", "tự ký request" → REST API "bấm trong giao diện" → Console
| ⚠ Vì sao Client Libraries đáng dùng | Lợi ích |
|---|---|
| ⚠ Tự lo xác thực | ⚠ ADC — Application Default Credentials |
| ⚠ Tự retry khi lỗi tạm | ⚠ backoff luỹ thừa sẵn |
| Tự phân trang | ⚠ duyệt kết quả như iterator |
| ⚠ Gợi ý trong IDE | ⚠ có kiểu dữ liệu |
| Ít code hơn nhiều |
| ⚠ Trong bối cảnh tác nhân gen-AI | Ý nghĩa |
|---|---|
| ⚠ "Công cụ" của tác nhân là HÀM Python | |
| ⚠ Hàm đó gọi Client Library | ⚠ để lấy dữ liệu thật |
| Mô tả hàm cho mô hình | ⚠ docstring quyết định mô hình có gọi đúng không |
| ⚠ Giới hạn quyền của service account | ⚠ tác nhân chỉ được làm việc cần thiết |
| Rủi ro | ⚠ tác nhân gọi công cụ sai lúc → phải có quyền tối thiểu |
| ⚠ Bẫy thường gặp trong đề thi | Bẫy |
|---|---|
| ⚠ "Cloud SDK" nghe như thư viện | ⚠ thực ra là CLI |
| ⚠ "API" nghe như câu trả lời an toàn | ⚠ nhưng đề nói tránh HTTP thô |
| Console luôn sai khi đề nói "programmatically" |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã cài đúng gói cho dịch vụ chưa | ⚠ mỗi dịch vụ một gói riêng | | Xác thực đang dùng danh tính nào | ⚠ ADC lấy từ môi trường | | Service account có quyền tối thiểu chưa | ⚠ đừng gán Editor cho tiện |
Và điều đáng nhớ nhất: Cloud SDK và Cloud Client Libraries là hai thứ khác nhau dù tên nghe giống nhau. Một cái để gõ trong terminal, một cái để import vào chương trình — đề thi rất hay đặt cả hai cạnh nhau.
A travel agency wants to create a highly interactive and personalized AI agent that can understand complex travel requests, ask clarifying questions, access real-time flight and hotel data through APIs, and help users plan and book entire itineraries.
Which Google Cloud offering is best suited for developing this sophisticated, tool-using generative AI agent?
-
A
Dialogflow ES
-
B
Vertex AI Agent Builder
-
C
Google AI Studio for quick prototyping
-
D
Using the Gemini API with custom Python code and no specific agent framework
Xem giải thích
Đáp án
B — Vertex AI Agent Builder.
Vì sao đúng
Đề liệt kê đúng bộ tính năng của một tác nhân biết dùng công cụ: hiểu yêu cầu phức tạp, hỏi lại để làm rõ, gọi API lấy dữ liệu thời gian thực, và thực hiện chuỗi hành động để đặt chỗ.
⚠ Bốn yêu cầu khớp:
"hiểu yêu cầu phức tạp"
→ ⚠ mô hình Gemini làm bộ não
"HỎI LẠI để làm rõ"
→ ⚠ quản lý HỘI THOẠI nhiều lượt
"gọi API chuyến bay, khách sạn
THỜI GIAN THỰC"
→ ⚠ TOOL CALLING — cốt lõi
"lên lịch trình và ĐẶT CHỖ"
→ ⚠ HÀNH ĐỘNG, không chỉ trả lời
⚠ Gần trùng với #13952 (lô 146) và #14063 (chính lô này) — cùng khoá Agent Builder cho tác nhân biết dùng công cụ. Ba câu, ba bối cảnh khác nhau, cùng một dấu hiệu.
Vì sao các phương án khác sai
-
A (Dialogflow ES) — thế hệ cũ, dựa trên intent khai báo sẵn. Với "yêu cầu du lịch phức tạp" thì phải liệt kê trước mọi ý định người dùng có thể nói — không khả thi. ⚠ Thấy "ES" trong đề gen-AI thì gần như luôn là phương án cũ, sai.
-
C (Google AI Studio) — công cụ thử nghiệm nhanh, không phải nền tảng chạy thật. Không có quản lý phiên, không có tích hợp doanh nghiệp, không SLA.
-
D (Gemini API + code Python, không dùng khung tác nhân) — phương án gần đúng nhất và là bẫy mạnh nhất: về lý thuyết làm được. Nhưng đề nhấn "sophisticated" và câu hỏi là "best suited". Tự viết thì phải tự làm lấy vòng lặp gọi công cụ, quản lý trạng thái hội thoại, xử lý lỗi, ghi vết, đánh giá — chính là những thứ Agent Builder cung cấp sẵn.
Ghi nhớ
⚠ Bốn mức xây trợ lý — bảng phải thuộc: | Mức | Công cụ | Dùng khi | |---|---|---| | ⚠ Thử nghiệm | ⚠ Google AI Studio | ⚠ thử prompt, chưa sản xuất | | Tự viết | ⚠ Gemini API + code | ⚠ luồng đơn giản, cần kiểm soát tối đa | | ⚠ Khung tác nhân | ⚠ Vertex AI Agent Builder | ⚠ tác nhân dùng CÔNG CỤ — đề này | | Chatbot luật cũ | ⚠ Dialogflow ES | ⚠ hệ thống cũ, ý định cố định |
Từ khoá nhận diện:
"gọi API, dùng công cụ, thực hiện hành động" → ⚠ Agent Builder "nhiều lượt, hỏi lại làm rõ" → ⚠ Agent Builder "chỉ tìm và trả lời từ tài liệu" → Vertex AI Search "thử nhanh prompt" → AI Studio "ES", "intent khai báo" → ⚠ phương án CŨ, thường sai
| ⚠ Chatbot khác Agent thế nào | Khác |
|---|---|
| Chatbot | ⚠ TRẢ LỜI |
| ⚠ Agent | ⚠ LẬP KẾ HOẠCH → GỌI CÔNG CỤ → HÀNH ĐỘNG |
| ⚠ Dấu hiệu nhận ra agent | ⚠ có VIỆC được làm ngoài đời thật |
| Đề này | ⚠ "book entire itineraries" — đặt chỗ thật |
| ⚠ Bốn thành phần của một agent | Thành phần |
|---|---|
| ⚠ Mô hình | ⚠ bộ não suy luận |
| ⚠ Công cụ | ⚠ tay chân — API chuyến bay, khách sạn |
| ⚠ Điều phối | ⚠ vòng lặp suy nghĩ – hành động – quan sát |
| Bộ nhớ | ⚠ ngữ cảnh trong phiên và giữa các phiên |
| ⚠ Riêng agent ĐẶT CHỖ — rủi ro | Rủi ro |
|---|---|
| ⚠ Hành động KHÔNG HOÀN TÁC ĐƯỢC | ⚠ vé đã đặt, tiền đã trừ |
| ⚠ BẮT BUỘC xác nhận trước khi đặt | ⚠ HITL ở bước cuối |
| Idempotency key | ⚠ tránh đặt trùng khi retry |
| ⚠ Giới hạn số tiền mỗi giao dịch | |
| Ghi vết mọi lời gọi công cụ | ⚠ để giải trình khi khiếu nại |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có gọi đúng công cụ không | ⚠ xem log lời gọi, không chỉ xem câu trả lời | | Bước đặt chỗ có xác nhận chưa | ⚠ không được tự đặt | | Xử lý sao khi API bên thứ ba lỗi | ⚠ phải báo, không được bịa kết quả |
Và điều quan trọng nhất khi chấm câu kiểu này: "tự viết bằng API" hầu như luôn là phương án làm được nhưng không phải phương án tốt nhất. Đề hỏi "best suited" thì chọn nền tảng có sẵn phần khó — trừ khi đề nói rõ là cần kiểm soát tối đa hoặc yêu cầu quá đơn giản.
A media company is using a generative AI model on Vertex AI to create illustrations and artwork for its online content. A primary concern for the company is deploying this technology responsibly, which includes being transparent about the use of AI and preventing the generation of harmful content.
To support the responsible deployment of this image generation model, which of the following is NOT a recommended practice or feature within the Google Cloud ecosystem?
-
A
Applying built-in safety filters to the Vertex AI model to block prompts and filter outputs that relate to unsafe or harmful content categories.
-
B
Keeping detailed audit logs of the prompts submitted by internal users to help investigate any potential misuse of the image generation service.
-
C
Publicly releasing the company's entire proprietary dataset that was used for fine-tuning the model to demonstrate full transparency.
-
D
Using a tool like SynthID to add an imperceptible digital watermark to each generated image, making it identifiable as AI-generated.
Xem giải thích
Đáp án
C — Công khai toàn bộ tập dữ liệu độc quyền dùng để tinh chỉnh mô hình, để "chứng minh minh bạch hoàn toàn".
Ghi nhớ về dạng câu hỏi
⚠ Đây là câu hỏi PHỦ ĐỊNH — đề hỏi cái KHÔNG được khuyến nghị. Ba phương án còn lại đều ĐÚNG, chỉ một phương án sai và đó mới là đáp án.
⚠ Mẹo làm: đọc kỹ từ "NOT", rồi gạch ra ba việc tốt trước — cái còn lại là đáp án.
Vì sao đúng
⚠ Vì sao công khai tập dữ liệu là sai:
⚠ Nhầm lẫn cốt lõi:
"minh bạch" ≠ "công khai mọi thứ"
⚠ Ba tác hại thật:
1. Lộ dữ liệu cá nhân trong tập
→ ⚠ vi phạm GDPR và quyền riêng tư
2. Lộ tài sản trí tuệ
→ ⚠ dữ liệu độc quyền là lợi thế
3. ⚠ Có thể vi phạm bản quyền
của chính tác giả hình ảnh
trong tập dữ liệu
⚠ Minh bạch ĐÚNG nghĩa là gì:
✅ Nói RÕ nội dung do AI tạo
✅ ⚠ Đóng dấu SynthID
✅ Công bố Model Card — mô tả
⚠ mục đích, giới hạn, dữ liệu
⚠ ở mức MÔ TẢ, không phải bản thô
✅ Có kênh báo cáo lạm dụng
❌ ⚠ KHÔNG phải là đăng nguyên
tập dữ liệu lên mạng
Vì sao các phương án khác sai
Cả ba đều là thực hành đúng, nên không phải đáp án của câu phủ định:
-
A (bộ lọc an toàn sẵn của Vertex AI) — đúng. Vertex AI có safety filter chặn cả prompt đầu vào lẫn ảnh đầu ra theo các nhóm nội dung có hại.
-
B (lưu nhật ký kiểm toán các prompt) — đúng. Ghi vết để điều tra khi có người dùng nội bộ lạm dụng dịch vụ.
-
D (SynthID đóng dấu ẩn) — đúng, và là công nghệ đặc trưng của Google cho việc này: dấu vân số không nhìn thấy được, tồn tại qua cắt/nén/đổi màu, giúp nhận ra ảnh do AI tạo.
Ghi nhớ
⚠ Bốn trụ triển khai sinh ảnh có trách nhiệm — bảng phải thuộc: | Trụ | Việc | |---|---| | ⚠ Chặn đầu vào | ⚠ safety filter lọc prompt độc hại | | ⚠ Chặn đầu ra | ⚠ filter ảnh không an toàn | | ⚠ Đánh dấu nguồn gốc | ⚠ SynthID watermark | | ⚠ Ghi vết | ⚠ audit log prompt để điều tra |
Từ khoá nhận diện:
"ảnh này có phải AI tạo không" → ⚠ SynthID "chặn nội dung có hại" → ⚠ safety filters "ai đã dùng để làm gì" → ⚠ audit logs "công khai dữ liệu huấn luyện" → ⚠ SAI — không phải minh bạch
| ⚠ SynthID — phải nhớ | Nội dung |
|---|---|
| ⚠ Dấu vân số KHÔNG nhìn thấy | ⚠ nhúng vào chính điểm ảnh |
| ⚠ Sống sót qua cắt, nén, đổi màu | ⚠ khác metadata — bị xoá dễ dàng |
| Có công cụ kiểm tra | ⚠ xác minh ảnh có dấu hay không |
| ⚠ Mở rộng sang văn bản, âm thanh, video | |
| Mục đích | ⚠ chống deepfake và thông tin sai |
| ⚠ Minh bạch khác Công khai | Khác |
|---|---|
| ⚠ Minh bạch | ⚠ nói rõ hệ thống LÀM GÌ, giới hạn ở đâu |
| ⚠ Công khai dữ liệu thô | ⚠ rủi ro riêng tư, IP, bản quyền |
| Model Card | ⚠ cách minh bạch ĐÚNG chuẩn |
| Sai lầm hay gặp | ⚠ tưởng càng công khai càng có trách nhiệm |
| ⚠ Rủi ro riêng của SINH ẢNH | Rủi ro |
|---|---|
| ⚠ Deepfake người thật | ⚠ chặn prompt tên người nổi tiếng |
| ⚠ Vi phạm bản quyền phong cách | |
| Định kiến trong hình ảnh | ⚠ nghề nghiệp, giới tính, sắc tộc |
| ⚠ Nội dung nhạy cảm | ⚠ safety filter là bắt buộc |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ lọc có bật đủ nhóm không | ⚠ kiểm cả đầu vào và đầu ra | | Ảnh xuất ra có dấu SynthID không | ⚠ thử kiểm tra một ảnh | | Log có đủ để truy ai làm gì không | ⚠ giữ bao lâu, ai đọc được |
Và bài học chung của mọi câu phủ định dạng này: phương án sai thường là phương án cực đoan hoá một nguyên tắc đúng. "Minh bạch" là đúng, nhưng đẩy tới "công khai mọi thứ" thì thành sai — cách viết đó là dấu hiệu nhận ra đáp án.