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

Câu 141 Business strategies for a successful gen AI solution

To prevent unauthorized modifications or tampering of a deployed generative AI model that provides financial advice, a company implements measures to verify the model's integrity before each use and protect its stored artifacts.

This focus on protecting the model itself from corruption or malicious alteration is a key aspect of:

A
Securing the AI model and its assets
B
Ensuring model fairness and mitigating bias
C
Data privacy for training inputs
D
Optimizing model inference latency

Xem giải thích

Đáp án

A — Bảo vệ chính mô hình AI và các tài sản của nó (securing the AI model and its assets).

Vì sao đúng

Công ty xác minh tính toàn vẹn của mô hình trước mỗi lần dùng và bảo vệ các artifact đã lưu, nhằm chống sửa đổi trái phép hoặc phá hoại. Đó là bảo vệ chính mô hình.

⚠ Bảo vệ mô hình gồm gì:

⚠ TOÀN VẸN (integrity)
    → ⚠ mô hình có bị sửa không
    → ⚠ băm và ký số artifact
    → ⚠ xác minh trước khi nạp

⚠ BẢO MẬT LƯU TRỮ
    → mã hoá artifact
    → IAM chặt cho kho mô hình

⚠ CHUỖI CUNG ỨNG
    → ⚠ mô hình đến từ nguồn tin cậy
    → ⚠ Binary Authorization

⚠ TRUY VẾT
    → audit log ai sửa, ai tải

⚠ Vì sao mô hình bị sửa lại nguy hiểm:

Mô hình tư vấn tài chính bị
sửa trái phép
        ↓
    ⚠ Đưa lời khuyên có lợi cho
      kẻ tấn công
    ⚠ Hoặc gây thiệt hại cho khách
        ↓
    ⚠ RẤT KHÓ PHÁT HIỆN
    → ⚠ mô hình vẫn "chạy bình thường"
    → không có lỗi, không có cảnh báo
        ↓
    → ⚠ vì vậy phải XÁC MINH TRƯỚC
      MỖI LẦN DÙNG

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

"Đảm bảo công bằng, giảm thiên vị"
    → ⚠ về FAIRNESS

"Quyền riêng tư dữ liệu huấn luyện"
    → ⚠ về bảo vệ DỮ LIỆU, không
      phải bảo vệ MÔ HÌNH

"Tối ưu độ trễ suy luận"
    → ⚠ về hiệu năng

Nhất quán với #13964 (cùng lô) — đề đó về model theft (lấy mô hình đi). Đề này về bảo vệ toàn vẹn (sửa mô hình). Hai mặt của cùng chủ đề bảo vệ tài sản mô hình.

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

C (quyền riêng tư dữ liệu huấn luyện) — phương án gần nhất và là bẫy chính: cũng thuộc nhóm bảo mật AI. Nhưng nó bảo vệ DỮ LIỆU, còn đề nói rõ về bảo vệ MÔ HÌNH khỏi bị sửa đổi.
B và D — thuộc lĩnh vực khác.

Ghi nhớ

⚠ Bảo mật AI — bốn nhóm tài sản, bảng nên thuộc: | Tài sản | Bảo vệ khỏi | |---|---| | ⚠ Dữ liệu huấn luyện | ⚠ lộ, đầu độc | | ⚠ Mô hình (trọng số, kiến trúc) | ⚠ đánh cắp, SỬA ĐỔI — đề này | | Đầu vào lúc suy luận | ⚠ prompt injection, adversarial | | Đầu ra | ⚠ rò rỉ thông tin, nội dung có hại |

Từ khoá nhận diện:

"toàn vẹn mô hình, chống sửa đổi" → ⚠ bảo vệ mô hình và tài sản "lấy trọng số mang đi" → ⚠ model theft "đầu độc dữ liệu huấn luyện" → data poisoning "lừa qua đầu vào" → prompt injection

⚠ Biện pháp bảo vệ toàn vẹn mô hình	Biện pháp
⚠ Băm và KÝ SỐ artifact	⚠ xác minh trước khi nạp
⚠ Binary Authorization	⚠ chỉ cho triển khai artifact đã duyệt
IAM quyền tối thiểu cho Model Registry	⚠ rất ít người được ghi
⚠ Audit log mọi thao tác	⚠ ai sửa, ai tải, khi nào
Mã hoá khi lưu
⚠ Môi trường triển khai bất biến	⚠ không sửa tại chỗ
Giám sát hành vi bất thường của mô hình	⚠ đầu ra lệch hẳn

⚠ Chuỗi cung ứng ML — rủi ro mới	Rủi ro
⚠ Tải mô hình từ nguồn không tin cậy	⚠ có thể chứa mã độc
⚠ Thư viện phụ thuộc bị chiếm
Dữ liệu huấn luyện từ nguồn công khai	⚠ có thể bị đầu độc
Image container bị sửa
Phòng bằng	⚠ quét, ký số, và chỉ dùng nguồn đã duyệt

⚠ Vì sao tư vấn tài chính là mục tiêu hấp dẫn	Lý do
⚠ Sửa mô hình để hướng khách vào sản phẩm có lợi cho kẻ tấn công
⚠ Rất khó phát hiện	⚠ lời khuyên vẫn "nghe hợp lý"
Hậu quả tài chính trực tiếp
Trách nhiệm pháp lý của công ty
Vì vậy	⚠ xác minh toàn vẹn TRƯỚC MỖI LẦN dùng là hợp lý

⚠ Ba câu hỏi của SAIF áp cho tình huống này	Câu hỏi
⚠ Ai được sửa mô hình	⚠ danh sách phải rất ngắn
⚠ Làm sao biết mô hình chưa bị sửa	⚠ ký số và xác minh
Nếu bị sửa thì phát hiện bằng cách nào	⚠ audit log + giám sát đầu ra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Artifact có được ký số không | ⚠ và có xác minh trước khi nạp không | | Ai có quyền ghi vào Model Registry | ⚠ siết tối đa | | Có phát hiện được nếu mô hình bị đổi không | ⚠ thử tình huống giả định |

Và điều làm việc mô hình bị sửa đổi nguy hiểm hơn nhiều so với một hệ thống bị tấn công thông thường: nó vẫn chạy bình thường. Không có lỗi, không có cảnh báo, không có dịch vụ nào ngừng — chỉ có những lời khuyên hơi khác đi, theo hướng có lợi cho ai đó khác.

Câu 142 Techniques to improve gen AI model output

A startup with limited funding is developing a generative AI feature. While they desire high performance, the ongoing operational expense of using a very large, state-of-the-art foundation model is a major concern.

When selecting a model, this budgetary constraint will primarily drive them to carefully evaluate the model's:

A
Availability for fine-tuning.
B
Training data cutoff date.
C
Cost-performance trade-off.
D
Multimodal capabilities.

Xem giải thích

Đáp án

C — Cost-performance trade-off (đánh đổi giữa chi phí và hiệu năng).

Vì sao đúng

Startup muốn hiệu năng cao nhưng lo chi phí vận hành liên tục của mô hình lớn nhất. Ràng buộc ngân sách buộc họ cân nhắc đánh đổi giữa chất lượng và chi phí.

⚠ Vì sao đây là đánh đổi thật:

Mô hình LỚN NHẤT
    → ⚠ chất lượng cao nhất
    → ⚠ ĐẮT nhất, CHẬM nhất

Mô hình NHỎ HƠN
    → ⚠ chất lượng thấp hơn ít
    → ⚠ RẺ hơn NHIỀU LẦN
        ↓
    ⚠ Câu hỏi: chênh lệch chất lượng
      có ĐÁNG với chênh lệch chi phí
      cho ĐÚNG bài toán này không?

⚠ Chi phí VẬN HÀNH nhân theo khối lượng:

Chi phí mỗi lượt gọi
    × số lượt mỗi ngày
    × 365 ngày
        ↓
    ⚠ Chênh lệch nhỏ ở mức đơn vị
      thành con số RẤT LỚN ở quy mô
        ↓
    ⚠ Với startup, đây có thể là
      khác biệt giữa sống và chết

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

"Khả năng tinh chỉnh"
    → ⚠ tính năng, không phải ràng
      buộc ngân sách

"Ngày cutoff dữ liệu huấn luyện"
    → ⚠ liên quan tính cập nhật

"Khả năng đa phương thức"
    → ⚠ tính năng, không phải chi phí

Nhất quán với #13992 (cùng lô) — đề đó về tổ chức phi lợi nhuận, khoá chi phí là ràng buộc chính. Đề này hỏi cụ thể hơn: đánh đổi chi phí–hiệu năng. Bổ sung nhau. Và #13932 (lô 146) về ràng buộc tài nguyên.

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

A (khả năng tinh chỉnh) — phương án gần nhất vì tinh chỉnh có thể giảm chi phí dài hạn (dùng mô hình nhỏ đã tinh chỉnh). Nhưng đó là một giải pháp, không phải tiêu chí đánh giá mà ràng buộc ngân sách trực tiếp dẫn tới.
B và D — không liên quan tới chi phí.

Ghi nhớ

⚠ Tiêu chí chọn mô hình — theo thứ tự: | Bước | Tiêu chí | |---|---| | 1 | ⚠ modality — làm được việc này không | | 2 | ⚠ cửa sổ ngữ cảnh — nhận được đầu vào không | | 3 | ⚠ chất lượng trên ví dụ THẬT | | ⚠ 4 | ⚠ CHI PHÍ và ĐỘ TRỄ — đề này | | 5 | ⚠ tuỳ biến: tinh chỉnh, grounding |

Từ khoá nhận diện:

"ngân sách hạn chế, hiệu năng cao" → ⚠ cost-performance trade-off "tài liệu rất dài" → cửa sổ ngữ cảnh "loại dữ liệu vào ra" → modality "không biết chuyện mới" → knowledge cutoff

⚠ Giảm chi phí mà giữ chất lượng	Cách
⚠ Dùng mô hình NHỎ NHẤT đạt yêu cầu	⚠ thử từ nhỏ lên, không từ lớn xuống
⚠ Định tuyến theo độ khó	⚠ mô hình nhỏ cho câu dễ, lớn cho câu khó
⚠ CACHE câu trả lời lặp lại	⚠ hiệu quả bất ngờ
Prompt ngắn gọn	⚠ tính tiền theo token
⚠ Batch thay vì thời gian thực	⚠ rẻ hơn đáng kể
Tinh chỉnh mô hình nhỏ	⚠ cho tác vụ hẹp, thường vượt mô hình lớn zero-shot
Giới hạn độ dài đầu ra

⚠ Đo chi phí cho đúng	Cách
⚠ Chi phí mỗi LƯỢT DÙNG, không phải mỗi token	⚠ dễ so với doanh thu hơn
⚠ Nhân với khối lượng DỰ KIẾN	⚠ không phải khối lượng hiện tại
Tính cả token đầu vào	⚠ prompt dài, grounding tốn nhiều
⚠ So với doanh thu mỗi người dùng	⚠ con số quyết định
Đặt hạn mức	⚠ tránh bất ngờ

⚠ Cạm bẫy về chi phí của startup	Cạm bẫy
⚠ Thử nghiệm rẻ, sản xuất đắt gấp trăm lần
⚠ Không tính chi phí khi người dùng tăng
Prompt phình dần theo thời gian	⚠ thêm ví dụ, thêm chỉ dẫn
⚠ Vòng lặp agent gọi nhiều lần
Không có hạn mức	⚠ một lỗi có thể rất tốn

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Chi phí mỗi lượt dùng là bao nhiêu | ⚠ so với doanh thu mỗi người dùng | | Mô hình nhỏ hơn có đủ tốt không | ⚠ đo trên bộ test thật | | Có cache được không | ⚠ thường giảm đáng kể |

Và cách tiếp cận đáng theo với startup có ngân sách hạn chế: bắt đầu từ mô hình nhỏ nhất và chỉ nâng cấp khi đo được rằng chất lượng chưa đạt. Trình tự ngược lại — dùng mô hình mạnh nhất rồi mới tìm cách cắt giảm — thường dẫn tới việc phát hiện vấn đề chi phí quá muộn.

Câu 143 Fundamentals of gen AI

A startup is developing a generative AI application. They decide to build and manage their own physical servers and GPU clusters in their office instead of using a cloud provider's AI infrastructure.

What is a primary business implication of this on-premise infrastructure choice compared to using the cloud?

A
Higher initial capital expenditure and ongoing operational overhead.
B
Reduced need for in-house IT and hardware expertise.
C
Automatic scalability of resources based on demand.
D
Guaranteed access to the latest AI model innovations from cloud vendors.

Xem giải thích

Đáp án

A — Chi phí vốn ban đầu cao hơn và gánh nặng vận hành liên tục.

Vì sao đúng

Tự xây và vận hành máy chủ cùng cụm GPU nghĩa là bỏ vốn lớn trả trước (CapEx) và gánh toàn bộ công việc vận hành — điều mà đám mây bỏ đi.

⚠ Startup tự xây phải gánh gì:

⚠ CHI PHÍ VỐN
    → ⚠ mua GPU, máy chủ, mạng
    → ⚠ trả TRƯỚC khi biết sản phẩm
      có ai dùng không

⚠ GÁNH NẶNG VẬN HÀNH
    → điện, làm mát, mặt bằng
    → ⚠ NGƯỜI vận hành 24/7
    → thay thế phần cứng hỏng
    → nâng cấp, vá lỗi
        ↓
    ⚠ Với startup, đây là nguồn
      lực lẽ ra dành cho SẢN PHẨM

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

"GIẢM nhu cầu chuyên môn IT và
 phần cứng nội bộ"
    → ⚠ NGƯỢC: tự xây thì cần
      NHIỀU HƠN

"Tự động co giãn theo nhu cầu"
    → ⚠ NGƯỢC: đó là ưu điểm của
      ĐÁM MÂY

"Đảm bảo tiếp cận đổi mới mô hình
 mới nhất từ nhà cung cấp đám mây"
    → ⚠ NGƯỢC: tự xây thì KHÔNG có

⚠ Đối chiếu #13970 (cùng lô) — đề đó hỏi lợi ích của đám mây và khoá cấp phát nhanh, co giãn. Đề này hỏi hệ quả của việc tự xây. Hai mặt của cùng một so sánh. Hoàn toàn nhất quán.

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

C (tự động co giãn) — phương án gần nhất về mặt "cũng nói tới đặc tính hạ tầng", nhưng đó là đặc tính của đám mây, không phải của hạ tầng tự xây.
B và D — cũng đảo ngược thực tế.

Ghi nhớ

⚠ Tại chỗ và đám mây — bảng phải thuộc: | | ⚠ Tự xây (tại chỗ) | ⚠ Đám mây | |---|---|---| | Chi phí | ⚠ CapEx lớn trả trước | ⚠ OpEx theo mức dùng | | Cấp phát | ⚠ hàng tháng | ⚠ vài phút | | Co giãn | ⚠ rất hạn chế | ⚠ tự động | | Vận hành | ⚠ BẠN lo tất cả | ⚠ nhà cung cấp lo hạ tầng | | Phần cứng mới | ⚠ phải mua lại | ⚠ có ngay khi ra | | Kiểm soát | ⚠ tối đa | ⚠ theo dịch vụ |

Từ khoá nhận diện:

"vốn lớn trả trước, tự vận hành" → ⚠ tại chỗ / CapEx "cấp phát nhanh, co giãn" → đám mây "trả theo mức dùng" → OpEx "giấy phép đòi máy vật lý" → ⚠ Bare Metal Solution

⚠ Khi nào tự xây LẠI hợp lý	Khi
⚠ Tải RẤT ỔN ĐỊNH, chạy nhiều năm	⚠ cụm GPU chạy 24/7 quanh năm
⚠ Ràng buộc pháp lý buộc dữ liệu tại chỗ
Đã có trung tâm dữ liệu và đội vận hành
Quy mô rất lớn, đàm phán được giá thiết bị
Nhưng với STARTUP	⚠ gần như luôn là lựa chọn SAI

⚠ Chi phí ẩn của tự xây mà startup hay quên	Chi phí
⚠ NGƯỜI vận hành	⚠ thường lớn hơn chi phí phần cứng
Điện và làm mát	⚠ GPU tiêu thụ rất lớn
Mặt bằng phù hợp	⚠ văn phòng thường không đủ điều kiện
⚠ Dự phòng khi hỏng	⚠ phải mua thừa
⚠ Lỗi thời sau 2–3 năm	⚠ GPU thế hệ mới ra liên tục
Thời gian chờ mua sắm	⚠ cơ hội bị bỏ lỡ

⚠ Điều startup thật sự đánh mất	Mất
⚠ TỐC ĐỘ thử nghiệm	⚠ quan trọng nhất với startup
⚠ Vốn lẽ ra dùng cho sản phẩm và con người
Sự linh hoạt khi hướng đi thay đổi
Tiếp cận phần cứng và mô hình mới

⚠ Cách tối ưu chi phí trên đám mây thay vì tự xây	Cách
⚠ Spot / preemptible + checkpoint	⚠ giảm mạnh nhất
Cam kết sử dụng khi tải đã ổn định
⚠ Tắt ngay khi xong
Dùng API mô hình thay vì tự chạy	⚠ thường rẻ hơn nhiều cho startup
Đo mức sử dụng bộ tăng tốc

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ai sẽ vận hành cụm lúc 3 giờ sáng | ⚠ câu hỏi thực tế nhất | | Nhu cầu có ổn định không | ⚠ startup thì hiếm khi ổn định | | Đã so TCO đầy đủ chưa | ⚠ cộng cả điện, người, mặt bằng |

Và với một startup, cái giá đắt nhất của việc tự xây hạ tầng không phải là tiền mua thiết bị: đó là thời gian và sự chú ý của đội ngũ bị chuyển từ sản phẩm sang việc vận hành phòng máy. Với một tổ chức mà tốc độ là lợi thế cạnh tranh chính, đó là khoản chi phí khó thu hồi nhất.

Câu 144 Fundamentals of gen AI

A large, pre-trained AI model that can be adapted for a wide variety of downstream tasks like text generation, translation, and question answering, serving as a base for many different applications, is best described as a:

A
Foundation Model
B
Reinforcement learning agent
C
Task-specific model
D
Supervised classification model

Xem giải thích

Đáp án

A — Foundation Model (mô hình nền).

Vì sao đúng

Đề mô tả đúng định nghĩa: mô hình lớn, huấn luyện sẵn, thích ứng được cho RẤT NHIỀU tác vụ phía sau — sinh văn bản, dịch, hỏi đáp — và làm NỀN cho nhiều ứng dụng khác nhau.

⚠ Vì sao gọi là "nền":

Trước đây
    → ⚠ MỖI tác vụ MỘT mô hình riêng
    → mô hình dịch, mô hình tóm tắt,
      mô hình phân loại
    → ⚠ mỗi cái cần dữ liệu gán nhãn
      riêng

⚠ MÔ HÌNH NỀN
    → ⚠ MỘT mô hình, NHIỀU tác vụ
    → ⚠ thích ứng bằng prompt,
      few-shot, tinh chỉnh
        ↓
    ⚠ đóng vai trò NỀN TẢNG cho
      nhiều ứng dụng

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

"Task-specific model"
    → ⚠ NGƯỢC: mô hình cho MỘT
      nhiệm vụ cụ thể

"Supervised classification model"
    → ⚠ mô hình phân loại — MỘT
      nhiệm vụ

"Reinforcement learning agent"
    → ⚠ agent học qua thưởng/phạt

Nhất quán với #13979 (cùng lô) — LLM là một dạng mô hình nền, dành cho ngôn ngữ. Mô hình nền là khái niệm rộng hơn, gồm cả Imagen, Veo. Bổ sung nhau.

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

C (task-specific model) — phương án gần nhất và là bẫy trực tiếp: nó mô tả đúng thứ đối lập với mô hình nền.
D và B — mô tả loại mô hình khác.

Ghi nhớ

⚠ Mô hình nền — đặc điểm, bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Huấn luyện trên dữ liệu RẤT LỚN | ⚠ thường tự giám sát, không cần nhãn | | ⚠ ĐA NHIỆM | ⚠ một mô hình, nhiều việc | | ⚠ Thích ứng được | ⚠ prompt, few-shot, tinh chỉnh | | Rất tốn kém để huấn luyện | ⚠ ít tổ chức làm được | | Làm NỀN cho ứng dụng | ⚠ đó là tên gọi |

Từ khoá nhận diện:

"lớn, huấn luyện sẵn, nhiều tác vụ" → ⚠ foundation model "chuyên cho ngôn ngữ" → ⚠ LLM — một dạng mô hình nền "chỉ làm một việc" → ⚠ task-specific model "nhận nhiều loại dữ liệu" → multimodal

⚠ Các mô hình nền của Google	Mô hình
⚠ Gemini	⚠ ngôn ngữ, đa phương thức
Gemma	⚠ mở, nhẹ
Imagen	ảnh
Veo	video
Chirp, Lyria	giọng nói, nhạc
MedLM, SecLM	⚠ chuyên ngành
Nơi truy cập	⚠ Model Garden

⚠ Bốn cách thích ứng mô hình nền	Cách
⚠ Prompt engineering	⚠ rẻ nhất, thử đầu tiên
⚠ Few-shot trong prompt
⚠ Grounding / RAG	⚠ thêm KIẾN THỨC
⚠ Fine-tuning / prompt tuning	⚠ thêm PHONG CÁCH
Thứ tự	⚠ đi từ nhẹ tới nặng

⚠ Vì sao mô hình nền đổi cách làm AI	Lý do
⚠ Không cần dữ liệu gán nhãn cho mỗi tác vụ	⚠ rào cản lớn nhất trước đây
⚠ Từ ý tưởng tới bản mẫu: vài giờ	⚠ thay vì vài tháng
Một nền tảng phục vụ nhiều ứng dụng
⚠ Tổ chức nhỏ cũng dùng được AI mạnh	⚠ dân chủ hoá
Đổi lại	⚠ ít kiểm soát hơn, phụ thuộc nhà cung cấp

⚠ Nhưng mô hình nền không thay thế mọi thứ	Điểm
⚠ Dữ liệu bảng	⚠ mô hình chuyên biệt vẫn tốt hơn
⚠ Cần kết quả xác định, lặp lại
⚠ Khối lượng cực lớn, chi phí thấp	⚠ mô hình nhỏ chuyên biệt rẻ hơn
Cần giải thích được	⚠ mô hình đơn giản dễ giải thích hơn

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Bài toán có phổ quát không | ⚠ có → mô hình nền qua API | | Có cần độ chính xác xác định không | ⚠ có → cân nhắc mô hình chuyên biệt | | Khối lượng bao nhiêu | ⚠ rất lớn → mô hình nhỏ rẻ hơn |

Và điều mô hình nền thay đổi nhiều nhất không phải chất lượng kết quả mà là chi phí để bắt đầu. Trước đây mỗi bài toán mới cần một tập dữ liệu gán nhãn và vài tháng; giờ nó bắt đầu bằng một câu lệnh và vài phút — và đó là lý do số lượng thử nghiệm AI tăng vọt.

Câu 145 Techniques to improve gen AI model output

A student asks a foundation model about the winner of a major sports championship that concluded just last week. The model provides information about the previous year's winner or states it doesn't have information on the most recent event.

This is most likely due to which common limitation of foundation models?

A
Computational cost
B
Knowledge cutoff
C
Bias
D
Hallucination

Xem giải thích

Đáp án

B — Knowledge cutoff (giới hạn kiến thức theo thời điểm huấn luyện).

Vì sao đúng

Mô hình không biết kết quả giải đấu vừa kết thúc tuần trước, hoặc đưa thông tin của năm trước. Nguyên nhân là dữ liệu huấn luyện dừng lại ở một thời điểm trong quá khứ.

⚠ Hai biểu hiện trong đề:

"đưa thông tin của NĂM TRƯỚC"
    → ⚠ dùng kiến thức CŨ nhất
      mà nó có

"nói rằng KHÔNG CÓ thông tin"
    → ⚠ hành vi ĐÚNG và MONG MUỐN
        ↓
    ⚠ Cả hai đều do knowledge cutoff
    ⚠ nhưng biểu hiện thứ hai
      TỐT hơn nhiều

⚠ Vì sao phân biệt với hallucination:

⚠ KNOWLEDGE CUTOFF
    → ⚠ NGUYÊN NHÂN GỐC: không có
      dữ liệu về sự kiện mới

⚠ HALLUCINATION
    → ⚠ BỊA ra chi tiết không tồn tại
        ↓
    ⚠ Cutoff CÓ THỂ DẪN TỚI ảo giác
      nếu mô hình bịa thay vì thừa
      nhận không biết
        ↓
    ⚠ Ở đây đề mô tả rõ nguyên nhân
      là dữ liệu cũ → cutoff

⚠ Vì sao hai phương án còn lại sai:

"Bias"  → ⚠ thiên vị giữa các nhóm
"Computational cost" → ⚠ chi phí tính toán

⚠ Gần trùng với #13874 (lô 145) — đề đó về tóm tắt tin tức thiếu diễn biến mới, cùng khoá knowledge cutoff. Hoàn toàn nhất quán. Và #13917/#13953 (lô 146) phân biệt với bias và hallucination.

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

D (hallucination) — phương án gần nhất và là bẫy chính: hai hạn chế này liên quan chặt. Nhưng đề nêu rõ mô hình đưa thông tin CŨ hoặc thừa nhận không biết — đó là biểu hiện của cutoff, không phải bịa ra thứ không tồn tại.
C và A — mô tả hạn chế khác.

Ghi nhớ

⚠ Hạn chế mô hình nền — bảng phải thuộc: | Hạn chế | Dấu hiệu | Chữa bằng | |---|---|---| | ⚠ Knowledge cutoff | ⚠ không biết chuyện MỚI | ⚠ grounding | | ⚠ Hallucination | ⚠ BỊA chi tiết | ⚠ grounding + trích dẫn + HITL | | Bias | ⚠ lệch giữa các nhóm | ⚠ dữ liệu cân bằng, đo theo nhóm | | Context window | ⚠ tài liệu quá dài | chia đoạn, RAG | | Không tính toán chính xác | sai số học | ⚠ gọi công cụ |

Từ khoá nhận diện:

"không biết sự kiện gần đây" → ⚠ knowledge cutoff "bịa chi tiết trôi chảy" → hallucination "lệch giữa các nhóm" → bias "nối với nguồn tin cậy" → grounding

⚠ Hai phản ứng khi gặp câu hỏi ngoài cutoff	Phản ứng
⚠ TỐT: "tôi không có thông tin về việc đó"	⚠ trung thực, dùng được
⚠ XẤU: đưa thông tin CŨ mà không nói là cũ	⚠ người dùng tưởng là mới
⚠ RẤT XẤU: BỊA kết quả nghe hợp lý	⚠ đã sang địa hạt ảo giác
Thiết kế tốt	⚠ khuyến khích mô hình nói không biết

⚠ Chữa bằng grounding	Cách
⚠ Grounding with Google Search	⚠ cho thông tin công khai mới
RAG vào nguồn cập nhật	⚠ cho dữ liệu doanh nghiệp
⚠ Function calling	⚠ gọi API thể thao lấy kết quả thật
Hiển thị NGÀY của nguồn	⚠ để người dùng tự đánh giá
Đừng	⚠ fine-tune để cập nhật sự kiện — không khả thi

⚠ Vì sao huấn luyện lại KHÔNG phải giải pháp	Lý do
⚠ Cực kỳ tốn kém
⚠ Vẫn lạc hậu ngay sau khi xong
Sự kiện xảy ra hằng ngày
Vì vậy	⚠ kiến trúc đúng là TRA CỨU lúc trả lời, không phải NHỚ

⚠ Phép thử nên làm với mọi ứng dụng AI	Phép thử
⚠ Hỏi về một sự kiện tuần trước
Câu trả lời đúng duy nhất	⚠ thừa nhận không biết, hoặc tra cứu được
Câu trả lời đáng lo	⚠ một câu nghe hợp lý nhưng sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình có nói được "không biết" không | ⚠ thử hỏi chuyện mới | | Có hiển thị ngày của nguồn không | ⚠ để người dùng đánh giá | | Bài toán có cần thông tin mới không | ⚠ có → bắt buộc grounding |

Và với mọi ứng dụng có người dùng thật, hành vi đáng mong muốn nhất khi gặp câu hỏi ngoài phạm vi kiến thức là thừa nhận không biết. Một câu trả lời trung thực về giới hạn của mình đáng tin hơn nhiều so với một câu trả lời trôi chảy dựa trên thông tin đã lỗi thời.

Câu 146 Fundamentals of gen AI

Before a newly trained generative AI model for content creation is deployed to production, it undergoes rigorous testing where its outputs are assessed for quality, coherence, and alignment with business requirements using predefined metrics.

This crucial step is known as:

A
Model deployment
B
Data ingestion
C
Model evaluation
D
Model training

Xem giải thích

Đáp án

C — Model evaluation (đánh giá mô hình).

Vì sao đúng

Trước khi triển khai, đầu ra của mô hình được kiểm thử nghiêm ngặt về chất lượng, tính mạch lạc và mức phù hợp với yêu cầu nghiệp vụ, dựa trên các chỉ số đã định trước. Đó là đánh giá mô hình.

⚠ Vị trí trong vòng đời:

Data preparation
        ↓
Model training
        ↓
⚠ MODEL EVALUATION
    → ⚠ đo trên tập test
    → ⚠ so với tiêu chí đã đặt
    → ⚠ QUYẾT ĐỊNH có triển khai không
    → ⚠ ĐỀ NÀY
        ↓
Model deployment
        ↓
Model management / monitoring

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

"Model training"
    → ⚠ đã XONG trước đó

"Model deployment"
    → ⚠ SAU khi đánh giá đạt

"Data ingestion"
    → ⚠ ở đầu vòng đời

Nhất quán với #13903 (lô 145) về deployment và #13911 (lô 146) về model management. Ba đề hỏi ba giai đoạn liền kề. Hoàn toàn nhất quán.

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

A (model deployment) — phương án gần nhất và là bẫy chính: đề có nhắc tới "trước khi triển khai". Nhưng bản thân việc kiểm thử là đánh giá, còn triển khai là bước sau đó.
D và B — nằm trước trong vòng đời.

Ghi nhớ

⚠ Vòng đời ML — bảng phải thuộc: | Giai đoạn | Việc | |---|---| | Data ingestion | đưa dữ liệu vào | | Data preparation | ⚠ làm sạch, tạo đặc trưng | | Model training | huấn luyện | | ⚠ Model evaluation | ⚠ đo chất lượng, QUYẾT ĐỊNH — đề này | | Model deployment | ⚠ đưa ra phục vụ | | Model management | ⚠ giám sát, huấn luyện lại |

Từ khoá nhận diện:

"kiểm thử trước khi triển khai, theo chỉ số" → ⚠ model evaluation "đưa ra phục vụ qua API" → deployment "giám sát, huấn luyện lại" → model management "làm sạch dữ liệu" → data preparation

⚠ Đánh giá AI SINH khó hơn ML truyền thống	Lý do
⚠ KHÔNG có MỘT đáp án đúng	⚠ nhiều bản viết đều tốt
⚠ Chất lượng phần nào chủ quan
Chỉ số tự động chỉ đo được một phần
⚠ Cùng đầu vào cho đầu ra khác nhau	⚠ tính ngẫu nhiên
Vì vậy	⚠ cần kết hợp nhiều cách đánh giá

⚠ Cách đánh giá mô hình sinh	Cách
⚠ Bộ ví dụ thử CỐ ĐỊNH	⚠ gồm cả ca khó và ca biên
⚠ Tiêu chí RÕ RÀNG	⚠ chất lượng, mạch lạc, đúng yêu cầu
⚠ Người chấm theo thang điểm	⚠ nhiều người để giảm chủ quan
So sánh cặp	⚠ A hay B tốt hơn — dễ chấm hơn cho điểm
⚠ LLM-as-judge	⚠ rẻ, nhanh, nhưng phải kiểm chứng lại
Chỉ số tự động	⚠ chỉ là một phần
⚠ Thử nghiệm với người dùng thật	⚠ bằng chứng cuối cùng

⚠ Phải kiểm gì trước khi triển khai	Kiểm
⚠ Chất lượng trên ca ĐIỂN HÌNH
⚠ Hành vi trên ca BIÊN	⚠ đầu vào lạ, rỗng, rất dài
⚠ An toàn	⚠ thử tấn công, prompt injection
⚠ Công bằng	⚠ kết quả theo từng nhóm
Độ trễ và chi phí ở tải thật
⚠ Hành vi khi KHÔNG BIẾT	⚠ có thừa nhận không, hay bịa

⚠ Tiêu chí phải định TRƯỚC	Vì sao
⚠ Định sau thì dễ hạ chuẩn cho vừa kết quả	⚠ thiên lệch xác nhận
Có ngưỡng rõ để quyết đi hay dừng
So sánh công bằng giữa các phiên bản
⚠ Ai là người quyết định cuối	⚠ phải rõ trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiêu chí đã định trước chưa | ⚠ không thì dễ tự thuyết phục | | Bộ test có ca khó không | ⚠ chỉ ca dễ thì đánh giá vô nghĩa | | Đã thử tấn công chưa | ⚠ với ứng dụng công khai là bắt buộc |

Và điều quyết định chất lượng của khâu đánh giá không phải công cụ đo, mà là bộ ví dụ thử có phản ánh đúng thực tế hay không. Một bộ test toàn ca dễ sẽ cho điểm cao và không nói lên điều gì về cách mô hình cư xử vào ngày nó gặp người dùng thật.

Câu 147 Business strategies for a successful gen AI solution

During the training phase of a generative AI model intended to identify hate speech, a malicious actor deliberately introduces mislabeled examples into the training dataset, where harmful content is labeled as benign. As a result, the trained model fails to correctly identify certain types of hate speech.

This attack, which corrupts the training data to compromise the model's behavior, is called:

A
Prompt injection
B
Model inversion
C
Adversarial example attack (at inference)
D
Data poisoning

Xem giải thích

Đáp án

D — Data poisoning (đầu độc dữ liệu).

Vì sao đúng

Kẻ tấn công cố ý đưa ví dụ gán nhãn SAI vào TẬP DỮ LIỆU HUẤN LUYỆN, khiến mô hình học sai và không nhận ra được một số loại nội dung thù ghét. Làm hỏng mô hình bằng cách làm hỏng dữ liệu huấn luyện chính là data poisoning.

⚠ Cơ chế:

Kẻ tấn công đưa mẫu độc vào
tập huấn luyện
        ↓
    ⚠ nội dung THÙ GHÉT được gán
      nhãn là VÔ HẠI
        ↓
    ⚠ Mô hình học rằng loại nội
      dung đó là bình thường
        ↓
    ⚠ Sau khi triển khai: bỏ lọt
      đúng loại nội dung đó
        ↓
    → ⚠ "cửa hậu" trong mô hình

⚠ Vì sao đặc biệt nguy hiểm:

⚠ Xảy ra TRƯỚC khi mô hình tồn tại
⚠ Không có "lỗi" nào để phát hiện
⚠ Mô hình hoạt động BÌNH THƯỜNG
  với mọi đầu vào khác
⚠ ⚠ CHỈ hỏng ở đúng loại mà kẻ
  tấn công nhắm tới
        ↓
    ⚠ Cực kỳ khó phát hiện bằng
      kiểm thử thông thường

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

"Prompt injection"
    → ⚠ xảy ra LÚC SUY LUẬN, qua
      đầu vào người dùng

"Adversarial example attack
 (at inference)"
    → ⚠ đề ghi RÕ "at inference" —
      sửa đầu vào lúc dùng, không
      phải lúc huấn luyện

"Model inversion"
    → ⚠ suy ngược dữ liệu huấn luyện
      từ mô hình

⚠ Đối chiếu #13968 (cùng lô) khoá prompt injection — xảy ra lúc suy luận. Đề này là lúc huấn luyện. Không mâu thuẫn — dấu hiệu phân biệt là giai đoạn nào của vòng đời.

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

C (adversarial example at inference) — phương án gần nhất và là bẫy được thiết kế kỹ: cũng là tấn công làm mô hình phân loại sai. Nhưng nó xảy ra lúc suy luận, còn đề nói rõ trong giai đoạn huấn luyện.
A và B — thuộc giai đoạn và cơ chế khác.

Ghi nhớ

⚠ Tấn công theo GIAI ĐOẠN — bảng phải thuộc: | Giai đoạn | Tấn công | |---|---| | ⚠ Thu thập dữ liệu / huấn luyện | ⚠ DATA POISONING — đề này | | Lưu trữ mô hình | ⚠ model theft, sửa đổi mô hình | | ⚠ Suy luận | ⚠ prompt injection, adversarial input | | Suy luận (nhiều truy vấn) | ⚠ model extraction, model inversion | | Đầu ra | ⚠ rò rỉ dữ liệu huấn luyện |

Từ khoá nhận diện:

"đầu độc dữ liệu huấn luyện" → ⚠ data poisoning "chỉ dẫn ẩn trong prompt" → prompt injection "sửa nhẹ đầu vào lúc dùng" → ⚠ adversarial example "suy ngược dữ liệu từ mô hình" → ⚠ model inversion

⚠ Vì sao mô hình kiểm duyệt là mục tiêu hấp dẫn	Lý do
⚠ Kẻ xấu muốn nội dung của họ LỌT
⚠ Chỉ cần bỏ lọt MỘT loại là đủ	⚠ không cần phá cả mô hình
Dữ liệu huấn luyện thường lấy từ nguồn mở	⚠ dễ chèn vào
Gán nhãn thuê ngoài	⚠ có thể bị mua chuộc
⚠ Rất khó phát hiện	⚠ mô hình vẫn tốt trên ca chung

⚠ Phòng chống data poisoning	Cách
⚠ Kiểm soát NGUỒN dữ liệu	⚠ chỉ dùng nguồn tin cậy
⚠ Kiểm tra chất lượng nhãn	⚠ gán chéo, đo mức đồng thuận
⚠ Phát hiện bất thường trong dữ liệu	⚠ mẫu lạ, nhãn lệch cụm
Ghi lineage đầy đủ	⚠ biết mẫu nào từ đâu
⚠ Bộ test ĐỘC LẬP, giữ bí mật	⚠ kẻ tấn công không đầu độc được nó
Kiểm tra định kỳ trên ca nhạy cảm
⚠ Nhiều lớp phòng thủ	⚠ không chỉ dựa vào một mô hình

⚠ Vì sao khó phát hiện bằng chỉ số tổng thể	Lý do
⚠ Độ chính xác TỔNG THỂ vẫn cao
⚠ Chỉ hỏng ở một nhóm ca hẹp
Nếu bộ test không có ca đó	⚠ không bao giờ phát hiện
Vì vậy	⚠ bộ test phải phủ đủ các loại nội dung cần chặn

⚠ Liên hệ với SAIF	Liên hệ
⚠ Bảo mật chuỗi cung ứng dữ liệu	⚠ một trụ cột của SAIF
Kiểm soát nguồn và lineage
Giám sát liên tục sau triển khai
Red team định kỳ	⚠ thử chính loại nội dung nhạy cảm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu huấn luyện đến từ đâu | ⚠ nguồn có kiểm soát không | | Bộ test có phủ đủ loại nội dung không | ⚠ thiếu loại nào thì mù ở đó | | Bộ test có được giữ độc lập không | ⚠ để không bị đầu độc theo |

Và điều làm đầu độc dữ liệu khó đối phó hơn mọi tấn công khác: nó tạo ra một mô hình trông hoàn toàn bình thường. Mọi chỉ số tổng thể đều đẹp, mọi bài kiểm thử thông thường đều qua — và lỗ hổng chỉ lộ ra khi đúng người biết cách kích hoạt nó sử dụng hệ thống.

Câu 148 Google Cloud's gen AI offerings

A sales representative uses the Gemini app. They want Gemini to always remember their role as a "Sales Rep for Acme Corp" and consistently use their company's standard product list for all general interactions, without having to repeat this information in every chat. Separately, for a specific task of drafting outreach emails to new leads, they want a specialized version of Gemini pre-loaded with their preferred email templates, a specific persuasive tone, and knowledge of their current marketing campaign.

Which Gemini features best address these two distinct needs respectively: one for general, persistent context and another for task-specific, customized AI assistants?

A
Both needs are addressed solely by Instructions for Gemini / Saved Info
B
Instructions for Gemini / Saved Info for remembering the general sales rep context and product list, and Gems for the specialized, task-specific email drafting assistant
C
Instructions for Gemini / Saved Info for the task-specific email drafting, and Gems for the general sales rep context
D
Both needs are addressed solely by Gems

Xem giải thích

Đáp án

B — "Instructions for Gemini / Saved Info" cho ngữ cảnh chung về vai trò nhân viên bán hàng và danh mục sản phẩm; còn Gems cho trợ lý chuyên biệt soạn email tiếp cận khách hàng.

Vì sao đúng

Hai nhu cầu khác nhau về phạm vi, và mỗi tính năng phục vụ đúng một phạm vi.

⚠ Hai nhu cầu, hai tính năng:

⚠ NHU CẦU 1 — NGỮ CẢNH CHUNG
    "luôn nhớ tôi là nhân viên bán
     hàng của Acme, dùng danh mục
     sản phẩm chuẩn"
        ↓
    ⚠ áp cho MỌI cuộc trò chuyện
        ↓
    → ⚠ SAVED INFO / INSTRUCTIONS

⚠ NHU CẦU 2 — TÁC VỤ CHUYÊN BIỆT
    "soạn email tiếp cận, có mẫu
     riêng, giọng thuyết phục,
     biết chiến dịch hiện tại"
        ↓
    ⚠ chỉ áp cho MỘT loại việc
        ↓
    → ⚠ GEMS

⚠ Cách phân biệt:

Hỏi: "Ngữ cảnh này áp cho
      MỌI việc hay MỘT việc?"
        ↓
    ⚠ Mọi việc → Saved Info
    ⚠ Một việc cụ thể → Gem riêng

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

"Chỉ Saved Info cho cả hai"
    → ⚠ nhồi mọi thứ vào ngữ cảnh
      chung làm loãng

"Chỉ Gems cho cả hai"
    → ⚠ phải lặp lại ngữ cảnh chung
      trong từng Gem

"Đảo ngược hai vai trò"
    → ⚠ sai

Nhất quán với #13865 (lô 145) — đề đó khoá ứng dụng Gemini và Gems cho việc tuỳ biến tác vụ lặp lại. Đề này phân biệt Gems với Saved Info. Bổ sung nhau.

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

⚠ Thân đề trong bộ đề bị CẮT CỤT ở cuối: kết thúc bằng "...respectively: one for genera" thay vì "one for general context and one for a specific task". Đây là lỗi cắt chuỗi khi nhập dữ liệu. Ý của câu hỏi vẫn đủ rõ từ phần còn lại và từ các phương án. Khoá đáp án B vẫn ĐÚNG và được giữ nguyên.

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

C (đảo ngược) — phương án gần nhất và là bẫy trực tiếp: nêu đúng hai tính năng nhưng gán ngược vai trò.
A và D — dồn cả hai nhu cầu vào một tính năng.

Ghi nhớ

⚠ Saved Info và Gems — bảng phải thuộc: | | ⚠ Saved Info / Instructions | ⚠ Gems | |---|---|---| | Phạm vi | ⚠ MỌI cuộc trò chuyện | ⚠ MỘT loại tác vụ | | Nội dung | ⚠ vai trò, bối cảnh chung | ⚠ chỉ dẫn, mẫu, giọng riêng | | Ví dụ | ⚠ "tôi là nhân viên bán hàng Acme" | ⚠ "Gem soạn email tiếp cận" | | Số lượng | ⚠ một bộ chung | ⚠ nhiều Gem khác nhau |

Từ khoá nhận diện:

"luôn nhớ, áp cho mọi cuộc trò chuyện" → ⚠ Saved Info / Instructions "trợ lý chuyên cho một việc" → ⚠ Gems "trong Gmail và Docs" → Gemini for Workspace "xây ứng dụng cho công ty" → Vertex AI

⚠ Viết Saved Info cho tốt	Nội dung
⚠ Vai trò và bối cảnh công việc
⚠ Thông tin ổn định, ít thay đổi	⚠ công ty, sản phẩm chính
Ưu tiên về định dạng, độ dài
⚠ NGẮN GỌN	⚠ dài quá làm loãng mọi cuộc trò chuyện
Đừng đưa vào	⚠ thứ chỉ dùng cho một loại việc

⚠ Viết một Gem tốt	Thành phần
⚠ Vai trò cụ thể cho tác vụ đó
⚠ Nhiệm vụ rõ ràng, MỘT việc
⚠ Giọng văn và đối tượng đọc
⚠ ĐỊNH DẠNG đầu ra
⚠ Ví dụ mẫu	⚠ few-shot cải thiện nhiều
Điều cần tránh
Bối cảnh riêng của tác vụ	⚠ chiến dịch hiện tại

⚠ Lưu ý về dữ liệu	Lưu ý
⚠ Đây là công cụ CÁ NHÂN	⚠ kiểm chính sách trước khi đưa dữ liệu công ty
⚠ Danh sách khách hàng là dữ liệu cá nhân	⚠ cân nhắc kỹ
Thông tin chiến dịch có thể là bí mật kinh doanh
Nếu cần	⚠ dùng công cụ doanh nghiệp thay vì bản cá nhân

⚠ Vì sao tách chung và riêng lại tốt hơn	Lý do
⚠ Ngữ cảnh chung KHÔNG bị lặp lại
⚠ Mỗi Gem tập trung, chỉ dẫn ngắn và sắc
Dễ sửa: đổi sản phẩm chỉ sửa một chỗ
⚠ Tránh chỉ dẫn mâu thuẫn nhau

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ngữ cảnh này áp cho mọi việc hay một việc | ⚠ quyết định đặt ở đâu | | Có dữ liệu công ty nhạy cảm không | ⚠ kiểm chính sách | | Việc nào lặp lại nhiều nhất | ⚠ ứng viên tốt nhất cho một Gem |

Và nguyên tắc gọn khi tổ chức trợ lý AI cá nhân: thông tin về BẠN đặt ở ngữ cảnh chung, thông tin về CÔNG VIỆC cụ thể đặt trong từng Gem. Cách tách đó giữ cho mỗi chỉ dẫn ngắn và sắc, thay vì một khối văn bản khổng lồ áp lên mọi cuộc trò chuyện.

Câu 149 Techniques to improve gen AI model output

The ReAct framework enhances the capabilities of Large Language Models by enabling them to not only generate textual reasoning but also to interact with external tools to gather information or perform tasks.

Within the ReAct cycle, after the LLM has generated a "Thought" about the problem and decided on an "Action" (e.g., to use a search engine tool with a specific query), what is the immediate next key component or step in this framework?

A
The LLM "Observes" by receiving the feedback or results from the executed action (e.g., search results).
B
The LLM immediately generates the final response to the user.
C
The LLM prompts the user for explicit permission to execute the action.
D
The LLM internally fine-tunes itself based on the thought.

Xem giải thích

Đáp án

A — LLM "Quan sát" (Observe) — nhận phản hồi hoặc kết quả từ hành động đã thực hiện.

Vì sao đúng

Chu trình ReAct là Thought → Action → Observation, lặp lại. Sau khi mô hình quyết định hành động và hành động được thực hiện, bước tiếp theo là nhận kết quả về.

⚠ Chu trình ReAct đầy đủ:

⚠ THOUGHT
    → "tôi cần tìm thông tin X"
        ↓
⚠ ACTION
    → gọi công cụ tìm kiếm với
      truy vấn cụ thể
        ↓
⚠ OBSERVATION
    → ⚠ NHẬN kết quả trả về
    → ⚠ ĐÁP ÁN
        ↓
⚠ THOUGHT tiếp
    → "đã đủ chưa? cần gì nữa?"
        ↓
    ⚠ LẶP cho tới khi đủ
        ↓
Câu trả lời cuối

⚠ Vì sao Observation là mắt xích bắt buộc:

Không có Observation
    → ⚠ mô hình gọi công cụ rồi
      KHÔNG BIẾT kết quả
    → ⚠ vẫn phải tự bịa câu trả lời
        ↓
    ⚠ Chính bước nhận kết quả mới
      biến hành động thành thông tin
      dùng được

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

"Sinh NGAY câu trả lời cuối"
    → ⚠ bỏ qua kết quả công cụ —
      mất hết ý nghĩa của việc gọi

"Hỏi người dùng CHO PHÉP thực hiện"
    → ⚠ có thể có trong thiết kế
      an toàn, nhưng KHÔNG phải
      bước trong khung ReAct

"Tự TINH CHỈNH dựa trên suy nghĩ"
    → ⚠ mô hình KHÔNG tự huấn luyện
      lại trong lúc chạy

Nhất quán với #13944 (lô 146) về ReAct và #13963 (cùng lô) về reasoning loop. Ba đề mô tả cùng một cơ chế ở ba mức chi tiết. Hoàn toàn nhất quán.

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

C (hỏi người dùng cho phép) — phương án gần nhất và là bẫy hợp lý: đó thật sự là thực hành tốt với hành động quan trọng. Nhưng nó là lựa chọn thiết kế an toàn, không phải bước trong khung ReAct.
B và D — mô tả sai cơ chế.

Ghi nhớ

⚠ Chu trình ReAct — bảng phải thuộc: | Bước | Nội dung | |---|---| | ⚠ Thought | ⚠ suy luận: cần gì tiếp theo | | ⚠ Action | ⚠ gọi công cụ với tham số cụ thể | | ⚠ Observation | ⚠ NHẬN kết quả về | | Lặp lại | ⚠ cho tới khi đủ hoặc chạm giới hạn | | Final answer | ⚠ tổng hợp và trả lời |

Từ khoá nhận diện:

"suy luận + gọi công cụ, lặp lại" → ⚠ ReAct "nhận kết quả từ công cụ" → ⚠ Observation "chỉ suy luận, không gọi công cụ" → Chain-of-Thought "người thiết kế trình tự" → ⚠ prompt chaining

⚠ Vì sao ReAct mạnh hơn CoT thuần	Lý do
⚠ Lấy được dữ liệu THẬT	⚠ thay vì dựa vào trí nhớ
⚠ Vượt qua knowledge cutoff
Giảm ảo giác	⚠ số liệu từ nguồn
⚠ Tự sửa khi công cụ báo lỗi	⚠ thử cách khác
Để lại vết suy luận đọc được	⚠ gỡ lỗi và kiểm toán

⚠ Xử lý Observation cho tốt	Cách
⚠ Kết quả công cụ có thể RẤT DÀI	⚠ tóm tắt trước khi đưa vào ngữ cảnh
⚠ Công cụ có thể LỖI	⚠ trả thông báo rõ để mô hình biết đường xử lý
Kết quả rỗng	⚠ mô hình phải biết là không tìm thấy
⚠ Cảnh giác nội dung trong kết quả	⚠ prompt injection GIÁN TIẾP
Giới hạn	⚠ số vòng lặp tối đa

⚠ Prompt injection gián tiếp qua Observation	Rủi ro
⚠ Trang web agent đọc có thể chứa chỉ dẫn ẩn
⚠ Agent đọc phải và LÀM THEO
Nạn nhân không hề gõ gì	⚠ nguy hiểm hơn dạng trực tiếp
Phòng bằng	⚠ quyền tối thiểu + tách rõ dữ liệu và chỉ dẫn + lọc

⚠ Thiết kế an toàn quanh chu trình	Thiết kế
⚠ Giới hạn số vòng lặp	⚠ chống lặp vô hạn và bùng chi phí
⚠ Tách công cụ ĐỌC và công cụ GHI
⚠ Xác nhận của người cho hành động quan trọng	⚠ thêm vào, dù không thuộc khung ReAct
Ghi log toàn bộ chu trình
Xử lý lỗi công cụ tường minh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Công cụ lỗi thì agent làm gì | ⚠ thử ngắt API | | Có giới hạn số vòng chưa | ⚠ bắt buộc | | Kết quả công cụ có bị lợi dụng không | ⚠ thử injection gián tiếp |

Và mắt xích Observation cũng chính là nơi mở ra một rủi ro ít người nghĩ tới: nội dung mà agent đọc về có thể chứa chỉ dẫn dành cho chính nó. Vì vậy kết quả trả về từ công cụ nên được đối xử như dữ liệu không đáng tin, chứ không phải như một phần chỉ dẫn của hệ thống.

Câu 150 Google Cloud's gen AI offerings

A data analyst, who is new to writing complex SQL queries, needs to perform data exploration and generate insights from large datasets stored in BigQuery. They are looking for an AI-powered assistant within BigQuery that can help them write SQL code, understand their data schemas, and even suggest potential insights.

Which Google Cloud offering provides this integrated AI assistance directly within the BigQuery environment?

A
Gemini in BigQuery.
B
Google AI Studio for general model prompting.
C
Vertex AI Pipelines for workflow automation.
D
Gemini Code Assist in their local IDE.

Xem giải thích

Đáp án

A — Gemini in BigQuery.

Vì sao đúng

Nhà phân tích cần trợ lý AI NGAY TRONG môi trường BigQuery: viết SQL, hiểu lược đồ dữ liệu, gợi ý hiểu biết. Đó là Gemini tích hợp trong BigQuery.

⚠ Vì sao "ngay trong BigQuery" là dữ kiện quyết định:

Dùng công cụ AI riêng bên ngoài
        ↓
    ⚠ phải copy lược đồ ra
    ⚠ mô tả bảng bằng lời
    ⚠ copy SQL quay lại
        ↓
⚠ GEMINI TRONG BIGQUERY
    → ⚠ đã BIẾT lược đồ và bảng
    → ⚠ sinh SQL chạy được ngay
    → ⚠ giải thích truy vấn có sẵn
    → ⚠ gợi ý phân tích tiếp theo

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

"Gemini Code Assist trong IDE"
    → ⚠ hỗ trợ LẬP TRÌNH, trong
      trình soạn thảo mã — không
      biết lược đồ BigQuery

"Google AI Studio"
    → ⚠ thử prompt chung, không
      có ngữ cảnh dữ liệu

"Vertex AI Pipelines"
    → ⚠ tự động hoá quy trình MLOps

Nhất quán với #13986 và #13988 (lô 147) — cùng họ Gemini theo nơi làm việc, mỗi phiên bản phục vụ một nhóm người dùng trong đúng công cụ của họ. Bổ sung nhau.

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

D (Gemini Code Assist) — phương án gần nhất và là bẫy chính: nó cũng sinh được SQL. Nhưng nó sống trong IDE và không có ngữ cảnh về lược đồ, bảng và dữ liệu trong BigQuery.
B và C — phục vụ mục đích khác.

Ghi nhớ

⚠ Gemini theo nơi làm việc — bảng phải thuộc: | Nơi | Sản phẩm | Phục vụ ai | |---|---|---| | ⚠ BigQuery | ⚠ Gemini in BigQuery | ⚠ nhà phân tích dữ liệu | | IDE | ⚠ Gemini Code Assist | lập trình viên | | Gmail, Docs | Gemini for Workspace | nhân viên | | ⚠ Bảo mật | ⚠ Gemini in Security | đội SOC | | Cloud Console | ⚠ Gemini Cloud Assist | kỹ sư vận hành | | Looker | Gemini in Looker | phân tích nghiệp vụ |

Từ khoá nhận diện:

"viết SQL, hiểu lược đồ, trong BigQuery" → ⚠ Gemini in BigQuery "gợi ý mã trong IDE" → Code Assist "phân tích cảnh báo bảo mật" → Gemini in Security "dựng mô hình bằng SQL" → ⚠ BigQuery ML — khác

⚠ Gemini in BigQuery làm được gì	Việc
⚠ Sinh SQL từ mô tả bằng lời	⚠ text-to-SQL
⚠ GIẢI THÍCH truy vấn phức tạp	⚠ rất hữu ích với SQL kế thừa
Hoàn thiện SQL khi đang gõ
⚠ Gợi ý phân tích tiếp theo
Sinh mô tả cho bảng và cột	⚠ cải thiện danh mục dữ liệu
Hỗ trợ chuẩn bị dữ liệu

⚠ Điều PHẢI làm với SQL do AI sinh	Việc
⚠ ĐỌC truy vấn trước khi chạy	⚠ hiểu nó làm gì
⚠ Xem ƯỚC TÍNH số byte quét	⚠ AI có thể sinh truy vấn quét cả kho
⚠ Kiểm logic ghép bảng	⚠ join sai cho kết quả sai mà vẫn chạy
Đặt maximum bytes billed	⚠ hàng rào chi phí
Đối chiếu kết quả với con số đã biết	⚠ phép thử tỉnh táo

⚠ Vì sao SQL sai nguy hiểm hơn mã sai	Lý do
⚠ SQL sai vẫn CHẠY và trả kết quả	⚠ không có lỗi biên dịch
⚠ Kết quả sai trông y hệt kết quả đúng
Có thể đi thẳng vào báo cáo cho lãnh đạo
Vì vậy	⚠ luôn đối chiếu với một con số đã biết trước

⚠ Lược đồ tốt giúp AI sinh SQL tốt	Điểm
⚠ Tên bảng và cột RÕ NGHĨA
⚠ Có MÔ TẢ cho bảng và cột	⚠ AI đọc được và dùng
Quan hệ khoá rõ ràng
Ghi nhớ	⚠ đầu tư vào metadata cải thiện chất lượng gợi ý rõ rệt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu byte | ⚠ xem ước tính trước khi chạy | | Kết quả có hợp lý không | ⚠ đối chiếu một con số đã biết | | Bảng đã có mô tả chưa | ⚠ cải thiện chất lượng gợi ý |

Và rủi ro đặc thù khi để AI sinh SQL: một câu truy vấn sai vẫn chạy trơn tru và trả về những con số trông rất thuyết phục. Không có thông báo lỗi nào cả — nên thói quen đối chiếu kết quả với một giá trị đã biết trước là hàng rào duy nhất thực sự đáng tin.

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ