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

Tìm thấy 556 câu.

Câu 271 Google Cloud's gen AI offerings

A healthcare startup needs to build an AI agent for retrieving patient data and answering clinical questions. Their Python developers have limited AI agent experience. They need a working proof-of-concept within three weeks to show hospital partners. Building from scratch would take months.

Which approach best accelerates development while helping the team learn agent patterns?

  1. A

    Starting with Agent Garden sample agents and customizing them.

  2. B

    Building custom agents from scratch using ADK documentation.

  3. C

    Using Agent Designer for visual prototyping.

  4. D

    Deploying pre-built agents from Gemini Enterprise without modification.

Xem giải thích

Đáp án

A — Bắt đầu từ các agent mẫu trong Agent Garden rồi tuỳ biến lại.

Vì sao đúng

Đề nêu ba ràng buộc, và phương án A giải được cả ba cùng lúc:

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

"lập trình viên Python nhưng ÍT
 kinh nghiệm về agent"
    → ⚠ mẫu cho thấy MẪU HÌNH đúng
    → ⚠ vừa làm vừa học

"cần bản chạy được trong BA TUẦN"
    → ⚠ mẫu rút ngắn thời gian

"xây từ đầu mất hàng THÁNG"
    → ⚠ đề tự loại phương án B

⚠ Vì sao đây là cách học tốt nhất:

⚠ Đọc tài liệu → biết cú pháp
⚠ Đọc CODE MẪU CHẠY ĐƯỢC
   → ⚠ biết cách GHÉP các phần
   → ⚠ biết mẫu hình thực tế
   → ⚠ sửa dần từ thứ đang chạy

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

  • B (xây từ đầu theo tài liệu ADK) — ⚠ đề nói thẳng là mất hàng tháng. Chọn nó là bỏ qua chính ràng buộc đề đưa ra.

  • D (triển khai agent dựng sẵn từ Gemini Enterprise, không sửa gì) — ⚠ nhanh nhất nhưng KHÔNG đáp ứng nhu cầu: agent dựng sẵn không biết truy vấn hệ thống hồ sơ bệnh nhân của họ. Và ⚠ "không sửa gì" thì đội KHÔNG HỌC được gì, trong khi đề nêu rõ mục tiêu học.

  • C (Agent Designer để tạo mẫu trực quan) — ⚠ bẫy hợp lý: tạo mẫu nhanh được. Nhưng đề nói họ là lập trình viên Python và cần bản chạy được để trình bày với đối tác bệnh viện — họ cần code tuỳ biến sâu với hệ thống y tế, không chỉ bản phác thảo trực quan.

Ghi nhớ

⚠ Bốn cách bắt đầu với agent — bảng phải thuộc: | Cách | Tốc độ | Học được | Tuỳ biến | |---|---|---|---| | ⚠ Agent Garden (mẫu) | ⚠ nhanh | ⚠ CAO | ⚠ cao — đề này | | Xây từ đầu bằng ADK | ⚠ chậm | cao | cao nhất | | Agent Designer | ⚠ rất nhanh | thấp | ⚠ hạn chế | | Agent dựng sẵn không sửa | ⚠ tức thì | ⚠ không | ⚠ không |

Từ khoá nhận diện:

"gấp + đội chưa có kinh nghiệm + cần học" → ⚠ bắt đầu từ mẫu "cần kiểm soát tối đa, có thời gian" → xây từ đầu "chỉ cần bản phác thảo cho bên nghiệp vụ" → công cụ trực quan "nhu cầu chuẩn, không cần tuỳ biến" → agent dựng sẵn

⚠ Vì sao mẫu là cách học nhanh nhất Lý do
⚠ Thấy được cấu trúc dự án thật
⚠ Thấy cách định nghĩa công cụ ⚠ phần khó nhất với người mới
⚠ Thấy cách xử lý lỗi và trạng thái
Chạy được ngay rồi sửa dần ⚠ luôn có thứ đang hoạt động để so sánh
Cảnh báo ⚠ mẫu là để học, không phải để bê thẳng lên sản xuất
⚠ Riêng agent y tế — không được bỏ qua Yêu cầu
⚠ PoC cũng KHÔNG được dùng dữ liệu bệnh nhân thật ⚠ dùng dữ liệu giả
⚠ Không được đưa ra kết luận lâm sàng ⚠ chỉ truy xuất và tóm tắt
⚠ Phân quyền theo vai trò y tế
Lưu vết mọi truy vấn hồ sơ
⚠ Bác sĩ là người quyết định cuối
⚠ Bẫy của bản trình diễn ba tuần Bẫy
⚠ Bệnh viện tưởng đây là sản phẩm hoàn chỉnh ⚠ phải nói rõ đây là PoC
⚠ PoC chạy trên dữ liệu đẹp ⚠ dữ liệu y tế thật rất bẩn
Khoảng cách PoC – sản xuất còn rất xa ⚠ tuân thủ, bảo mật, độ tin cậy
⚠ Đừng hứa thời hạn sản xuất dựa trên tốc độ PoC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu trong PoC có phải dữ liệu giả không | ⚠ bắt buộc ở giai đoạn này | | Agent có nói rõ giới hạn của mình không | ⚠ không được tỏ ra là công cụ chẩn đoán | | Mẫu có phần nào không phù hợp sản xuất | ⚠ rà lại xác thực, xử lý lỗi, ghi log |

Và nguyên tắc chung khi bị ép tiến độ: bắt đầu từ thứ đang chạy được, rồi sửa dần về phía nhu cầu của mình. Xây từ trang giấy trắng chỉ đúng khi không có mẫu nào gần với bài toán — và với agent thì gần như luôn có.

Câu 272 Google Cloud's gen AI offerings

A bank uses an AI model to assist with loan application decisions. To comply with financial regulations, the bank must document the model's performance characteristics and be able to evaluate it for potential biases across different demographic groups.

Which built-in Google Cloud feature directly supports these specific responsible AI governance requirements?

  1. A

    The use of Vertex AI Model Cards to document model metadata and Fairness Indicators to measure potential biases.

  2. B

    The integration of Gemini into Google Workspace for improved employee productivity.

  3. C

    The ability to run open-source models like Gemma on Google Kubernetes Engine.

  4. D

    The availability of custom-designed TPUs for high-speed model training.

Xem giải thích

Đáp án

A — Dùng Vertex AI Model Cards để ghi lại siêu dữ liệu mô hình, và Fairness Indicators để đo thiên lệch tiềm ẩn.

Vì sao đúng

Đề nêu hai yêu cầu tuân thủ riêng biệt, và phương án A khớp đúng từng cái:

⚠ Ghép hai yêu cầu:

"phải GHI HỒ SƠ đặc tính hiệu năng
 của mô hình"
    → ⚠ MODEL CARDS
    → ⚠ mục đích, dữ liệu, chỉ số,
      giới hạn, cách dùng đúng

"đánh giá THIÊN LỆCH giữa các
 NHÓM NHÂN KHẨU"
    → ⚠ FAIRNESS INDICATORS
    → ⚠ đo chỉ số TÁCH RIÊNG
      từng nhóm

⚠ Vì sao phải đo tách nhóm:

Độ chính xác TỔNG: 92%
    ⚠ nghe rất tốt
        ↓
⚠ Tách theo nhóm:
   nhóm A: 96%
   nhóm B: 71%
        ↓
⚠ Chỉ số tổng GIẤU MẤT bất công
⚠ Luật cho vay quan tâm ĐÚNG cái này

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

Cả ba đều là năng lực có thật của Google Cloud nhưng không liên quan tới quản trị AI có trách nhiệm:

  • D (TPU tự thiết kế để huấn luyện tốc độ cao) — ⚠ hiệu năng phần cứng, không phải công cụ tuân thủ.

  • C (chạy mô hình mở như Gemma trên GKE) — ⚠ lựa chọn triển khai, không giúp ghi hồ sơ hay đo công bằng.

  • B (tích hợp Gemini vào Workspace) — ⚠ năng suất nhân viên, hoàn toàn khác chủ đề.

⚠ Cách chấm nhanh: đề hỏi "responsible AI GOVERNANCE", nên chỉ phương án nói về tài liệu hoá và đo lường công bằng mới đúng phạm trù.

Ghi nhớ

⚠ Công cụ quản trị AI có trách nhiệm — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Model Cards | ⚠ HỒ SƠ mô hình: mục đích, dữ liệu, chỉ số, GIỚI HẠN | | ⚠ Fairness Indicators | ⚠ ĐO chênh lệch giữa các nhóm | | Model Evaluation | ⚠ đo chất lượng tổng thể | | Model Monitoring | ⚠ phát hiện trôi dạt sau khi triển khai | | Explainable AI | ⚠ đặc trưng nào ảnh hưởng quyết định | | Audit Logs | ⚠ ai làm gì, khi nào |

Từ khoá nhận diện:

"ghi hồ sơ, tài liệu hoá mô hình" → ⚠ Model Cards "thiên lệch theo nhóm nhân khẩu" → ⚠ Fairness Indicators "vì sao mô hình quyết định vậy" → ⚠ Explainable AI "chất lượng giảm dần theo thời gian" → Model Monitoring

⚠ Một Model Card ghi gì Nội dung
⚠ Mục đích sử dụng ⚠ và cả mục đích KHÔNG được dùng
⚠ Dữ liệu huấn luyện ⚠ nguồn, thời gian, phạm vi
⚠ Chỉ số hiệu năng ⚠ tổng thể VÀ theo từng nhóm
⚠ Giới hạn đã biết ⚠ phần quan trọng nhất
Cân nhắc đạo đức
Người chịu trách nhiệm
⚠ Riêng mô hình cho vay Yêu cầu
⚠ Luật cấm phân biệt theo nhóm bảo vệ ⚠ ở hầu hết quốc gia
⚠ Phải GIẢI THÍCH được lý do từ chối ⚠ quyền của người vay
⚠ Cẩn thận BIẾN THAY THẾ ⚠ mã vùng có thể đại diện cho sắc tộc
Người ra quyết định cuối
⚠ Kiểm toán định kỳ, không chỉ một lần
⚠ Vì sao "bỏ trường nhạy cảm" là chưa đủ Lý do
⚠ Mô hình học từ biến thay thế ⚠ mã vùng, trường học, tên
⚠ Phải ĐO kết quả theo nhóm ⚠ dù không dùng trường đó làm đầu vào
Cần giữ nhãn nhóm ĐỂ ĐO ⚠ nghịch lý: phải biết mới kiểm được
Cách làm ⚠ tách dữ liệu đo công bằng khỏi dữ liệu huấn luyện

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ duyệt vay chênh giữa nhóm bao nhiêu | ⚠ đo trên dữ liệu thật, định kỳ | | Model Card có ghi giới hạn thật không | ⚠ phần này hay bị viết qua loa | | Người bị từ chối có được giải thích không | ⚠ yêu cầu pháp lý ở nhiều nơi |

Và điều quan trọng nhất về công bằng thuật toán: một chỉ số tổng đẹp không chứng minh được gì. Chỉ khi tách theo từng nhóm mới thấy mô hình đang phục vụ ai tốt và ai kém — và đó chính xác là thứ cơ quan quản lý sẽ hỏi.

Câu 273 Google Cloud's gen AI offerings

A startup wants to begin developing a powerful generative AI application that requires significant computational resources, including high-end GPUs. They have limited funding and do not want to invest in purchasing and maintaining expensive physical servers in their office.

How does the fundamental model of cloud computing solve this critical business challenge?

  1. A

    It eliminates the need for the startup to have its own data.

  2. B

    It allows the startup to rent access to powerful, managed infrastructure on a pay-as-you-go basis, avoiding large upfront hardware costs.

  3. C

    It provides free access to all generative AI models.

  4. D

    It is a type of software that automatically writes the code for the AI application.

Xem giải thích

Đáp án

B — Cho phép startup thuê quyền dùng hạ tầng mạnh, được quản lý, theo hình thức trả tiền theo mức dùng, tránh khoản đầu tư phần cứng lớn ban đầu.

Vì sao đúng

Đề nêu đúng bài toán tài chính của một startup ít vốn:

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

"cần GPU cao cấp"
    → ⚠ phần cứng RẤT đắt

"vốn hạn chế"
    → ⚠ không có tiền mua

"không muốn mua và BẢO TRÌ
 máy chủ ở văn phòng"
    → ⚠ không muốn gánh vận hành

⚠ Chuyển đổi tài chính cốt lõi:

⚠ CapEx — chi phí đầu tư
   → mua máy, trả trước, khấu hao
        ↓ trở thành ↓
⚠ OpEx — chi phí vận hành
   → trả theo giờ dùng
   → ⚠ dùng bao nhiêu trả bấy nhiêu
   → ⚠ dừng dùng là dừng trả

⚠ Vì sao đặc biệt quan trọng với AI:

⚠ GPU cao cấp cực đắt
⚠ Nhu cầu KHÔNG ĐỀU
   → huấn luyện: cần nhiều máy vài ngày
   → còn lại: gần như không dùng
        ↓
⚠ Mua thì máy nằm không phần lớn
  thời gian

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

  • A (loại bỏ nhu cầu startup phải có dữ liệu riêng) — ⚠ sai hoàn toàn: đám mây cung cấp hạ tầng, không cung cấp dữ liệu của bạn. Và dữ liệu riêng chính là lợi thế cạnh tranh.

  • C (truy cập miễn phí mọi mô hình sinh) — ⚠ sai sự thật: dùng mô hình là có tính phí. Có bậc dùng thử miễn phí, nhưng đó không phải bản chất của điện toán đám mây.

  • D (một loại phần mềm tự viết code cho ứng dụng AI) — ⚠ định nghĩa sai hẳn: đó là mô tả công cụ sinh mã, không phải mô hình điện toán đám mây.

Ghi nhớ

⚠ Bốn lợi ích cốt lõi của đám mây — bảng phải thuộc: | Lợi ích | Nội dung | |---|---| | ⚠ Không đầu tư trước | ⚠ CapEx → OpEx — đề này | | ⚠ Co giãn | ⚠ tăng giảm theo nhu cầu | | ⚠ Truy cập công nghệ mới nhất | ⚠ GPU/TPU đời mới không phải mua | | Phủ toàn cầu | ⚠ triển khai nhiều vùng | | Được quản lý | ⚠ nhà cung cấp lo vận hành |

Từ khoá nhận diện:

"vốn hạn chế, không mua phần cứng" → ⚠ pay-as-you-go, OpEx "tải thay đổi thất thường" → ⚠ co giãn "cần GPU đời mới" → ⚠ không phải mua, thuê là có "miễn phí mọi thứ" → ⚠ luôn là phương án SAI

⚠ Vì sao AI hợp với đám mây đặc biệt Lý do
⚠ Nhu cầu tính toán RẤT không đều ⚠ huấn luyện đỉnh cao, suy luận đều đều
⚠ Phần cứng lỗi thời nhanh ⚠ GPU thế hệ mới ra liên tục
⚠ Thử nghiệm cần thất bại rẻ ⚠ thử rồi tắt, không mất gì
Dữ liệu đã nằm trên đám mây ⚠ tính toán nên ở cạnh dữ liệu
⚠ Mặt trái phải biết Mặt trái
⚠ Chi phí có thể vượt kiểm soát ⚠ quên tắt GPU là mất tiền thật
⚠ Dài hạn có thể đắt hơn mua ⚠ nếu tải ổn định và rất lớn
Phụ thuộc nhà cung cấp ⚠ chi phí chuyển đổi cao
⚠ Chủ quyền dữ liệu ⚠ phải chọn vùng cho đúng
Cách giảm ⚠ đặt ngân sách, cảnh báo chi phí, tự tắt máy nhàn rỗi
⚠ Việc startup nên làm ngay Việc
⚠ Đặt cảnh báo ngân sách ⚠ trước khi chạy job đầu tiên
⚠ Bật tự tắt máy nhàn rỗi ⚠ GPU quên tắt là khoản đau nhất
Xem xét tín dụng khởi nghiệp ⚠ các nhà cung cấp đều có chương trình
⚠ Dùng máy giá rẻ có thể bị thu hồi cho huấn luyện thử
Gắn nhãn tài nguyên theo dự án ⚠ để biết tiền đi đâu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã đặt cảnh báo chi phí chưa | ⚠ việc đầu tiên phải làm | | Có máy GPU nào đang chạy không mà không ai dùng | ⚠ kiểm hằng ngày lúc đầu | | Chi phí mỗi lần huấn luyện là bao nhiêu | ⚠ biết con số trước khi chạy lại |

Và cạm bẫy quen thuộc nhất với startup mới lên đám mây: trả theo mức dùng không có nghĩa là rẻ, nó có nghĩa là không có trần. Lợi thế thật nằm ở chỗ bắt đầu được với chi phí gần bằng không — nhưng kỷ luật chi phí phải dựng ngay từ ngày đầu, không phải sau hoá đơn đầu tiên.

Câu 274 Techniques to improve gen AI model output

A company deploys a generative AI agent to help customers resolve issues on their own, with the goal of reducing the number of calls to their human support center.

After deployment, what is the most important business KPI to monitor to determine if the agent is successfully meeting its primary goal?

  1. A

    The model's ROUGE score for summarization tasks.

  2. B

    The percentage decrease in call volume to the human support center.

  3. C

    The average latency of the agent's responses.

  4. D

    The number of tokens generated by the agent per day.

Xem giải thích

Đáp án

B — Tỷ lệ phần trăm giảm số cuộc gọi tới tổng đài hỗ trợ có người thật.

Vì sao đúng

Đề hỏi rõ "business KPI" và nêu thẳng mục tiêu: giảm số cuộc gọi tới tổng đài. KPI đúng phải đo trực tiếp chính mục tiêu đó.

⚠ Nguyên tắc chọn KPI:

Mục tiêu nghiệp vụ:
   ⚠ "giảm số cuộc gọi"
        ↓
⚠ KPI = ĐO CHÍNH ĐIỀU ĐÓ
   → tỷ lệ giảm cuộc gọi
        ↓
⚠ Không đo thứ gián tiếp

⚠ Ba phương án kia là chỉ số gì:

ROUGE score
    → ⚠ chỉ số KỸ THUẬT của mô hình
    → ⚠ và còn sai loại việc —
      ROUGE đo TÓM TẮT

Độ trễ trung bình
    → ⚠ chỉ số VẬN HÀNH
    → quan trọng, nhưng không
      phải mục tiêu

Số token sinh ra mỗi ngày
    → ⚠ chỉ số CHI PHÍ
    → ⚠ tăng hay giảm đều không
      nói lên thành công

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

  • C (độ trễ trung bình) — chỉ số vận hành đáng theo dõi, nhưng ⚠ agent nhanh mà không ai dùng thì cuộc gọi vẫn không giảm.

  • A (điểm ROUGE) — ⚠ sai kép: vừa là chỉ số kỹ thuật chứ không phải nghiệp vụ, vừa là chỉ số dành cho tóm tắt văn bản, không phải cho hỗ trợ khách hàng.

  • D (số token mỗi ngày) — ⚠ chỉ số hoàn toàn không có hướng: nhiều token có thể là nhiều người dùng (tốt) hoặc câu trả lời dài dòng (xấu). Nó là chỉ số chi phí, không phải chỉ số thành công.

Ghi nhớ

⚠ Ba tầng chỉ số — bảng phải thuộc: | Tầng | Ví dụ | Ai quan tâm | |---|---|---| | ⚠ Nghiệp vụ (KPI) | ⚠ giảm cuộc gọi, tiết kiệm chi phí, hài lòng | ⚠ lãnh đạo — đề này | | Vận hành | ⚠ độ trễ, tỷ lệ lỗi, uptime | đội vận hành | | Mô hình | ⚠ ROUGE, BLEU, độ chính xác | đội ML |

Từ khoá nhận diện:

"business KPI, mục tiêu chính" → ⚠ đo trực tiếp mục tiêu nghiệp vụ "ROUGE, BLEU, perplexity" → ⚠ chỉ số MÔ HÌNH, không phải KPI "độ trễ, uptime" → ⚠ chỉ số VẬN HÀNH "số token" → ⚠ chỉ số CHI PHÍ

⚠ KPI nên đi kèm cho chatbot tự phục vụ KPI
⚠ Tỷ lệ giảm cuộc gọi ⚠ KPI chính — đề này
⚠ Tỷ lệ giải quyết ngay lần đầu ⚠ không cần chuyển người
⚠ Hài lòng của khách (CSAT) ⚠ KPI ĐỐI TRỌNG bắt buộc
Chi phí mỗi lượt hỗ trợ
⚠ Tỷ lệ chuyển sang người thật
⚠ Vì sao PHẢI có KPI đối trọng Lý do
⚠ Giảm cuộc gọi có thể đạt được bằng cách XẤU ⚠ giấu số điện thoại tổng đài
⚠ Khách bỏ cuộc cũng làm giảm cuộc gọi ⚠ và họ bỏ luôn thương hiệu
⚠ Phải đo CSAT song song
Nguyên tắc ⚠ mọi KPI hiệu quả cần một KPI chất lượng đi kèm
⚠ Cách đo cho đúng Cách
⚠ Có đường nền TRƯỚC khi triển khai ⚠ không có thì không so được
⚠ Loại yếu tố mùa vụ ⚠ cuộc gọi vốn dao động theo mùa
⚠ So sánh có nhóm đối chứng nếu được
Theo dõi đủ dài ⚠ hiệu ứng mới lạ ban đầu sẽ nhạt đi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cuộc gọi giảm hay chỉ chuyển sang email | ⚠ đo TỔNG lượt hỗ trợ, không chỉ cuộc gọi | | Khách có hài lòng hơn không | ⚠ CSAT song song | | Có ai đang giấu đường tới người thật không | ⚠ kiểm trải nghiệm thật |

Và sai lầm phổ biến nhất khi báo cáo dự án AI: trình bày chỉ số mô hình cho lãnh đạo. Điểm ROUGE 0,42 không trả lời được câu hỏi duy nhất mà người phê duyệt ngân sách quan tâm — dự án này tiết kiệm được bao nhiêu, hay mang về thêm bao nhiêu.

Câu 275 Google Cloud's gen AI offerings

A legal firm uses AI to analyze case files and contracts for clients. Each case involves uploading 10-15 lengthy documents (contracts, depositions, legal briefs) totaling approximately 50,000 tokens, then attorneys ask 20-30 follow-up questions about specific clauses, precedents, and compliance issues throughout the day. Currently, the firm sends all documents with every single question, resulting in high token costs since the same 50,000 tokens are processed repeatedly. The CFO wants to reduce AI operational costs without compromising the quality of legal analysis.

Which cost optimization approach would provide the most significant savings for this repetitive query pattern?

  1. A

    Implementing RAG with vector search to retrieve only relevant document sections.

  2. B

    Switching to Gemini 3 Flash to reduce per-token costs.

  3. C

    Context caching to store case documents and reuse them across multiple queries.

  4. D

    Summarizing documents once and querying summaries instead of full documents.

Xem giải thích

Đáp án

C — Context caching để lưu tài liệu vụ việc và dùng lại cho nhiều truy vấn.

Vì sao đúng

Đề mô tả chính xác mẫu sử dụng mà context caching sinh ra để giải:

⚠ Mẫu sử dụng trong đề:

⚠ CÙNG 50.000 token tài liệu
⚠ 20–30 câu hỏi khác nhau
⚠ Trong cùng một ngày
        ↓
⚠ Hiện tại: gửi lại 50.000 token
  cho MỖI câu hỏi
        ↓
⚠ 25 câu × 50.000 = 1.250.000 token
  chỉ riêng phần tài liệu

⚠ Context caching làm gì:

⚠ Nạp tài liệu MỘT LẦN
⚠ Lưu trạng thái đã xử lý
⚠ Các câu hỏi sau chỉ gửi CÂU HỎI
        ↓
⚠ Token đầu vào được cache tính
  giá RẺ HƠN NHIỀU
⚠ Còn nhanh hơn vì không xử lý lại

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

  • A (RAG với tìm kiếm vector, chỉ lấy đoạn liên quan) — ⚠ bẫy mạnh nhất vì RAG là câu trả lời đúng cho rất nhiều câu hỏi khác. Nhưng ở đây ⚠ phân tích pháp lý cần TOÀN BỘ ngữ cảnh: điều khoản tham chiếu chéo nhau, định nghĩa ở đầu dùng ở cuối. Lấy vài đoạn có nguy cơ bỏ sót điều khoản loại trừ — đề nói rõ "without compromising the quality".

  • D (tóm tắt một lần rồi hỏi trên bản tóm tắt) — ⚠ rẻ nhất nhưng MẤT CHI TIẾT. Luật sư hỏi về điều khoản cụ thể — bản tóm tắt không giữ nguyên văn từng câu chữ, mà trong pháp lý thì câu chữ là tất cả.

  • B (chuyển sang Gemini 3 Flash cho rẻ hơn mỗi token) — ⚠ giảm đơn giá nhưng KHÔNG giảm SỐ LƯỢNG token lặp lại. Và hạ cỡ mô hình cho phân tích pháp lý phức tạp là đánh đổi chất lượng — đúng thứ đề cấm.

Ghi nhớ

⚠ Bốn cách giảm chi phí và khi nào dùng — bảng phải thuộc: | Cách | Dùng khi | |---|---| | ⚠ Context caching | ⚠ CÙNG ngữ cảnh lớn, NHIỀU câu hỏi — đề này | | RAG | ⚠ kho tài liệu RẤT LỚN, mỗi câu chỉ cần vài đoạn | | Mô hình nhỏ hơn | ⚠ việc đơn giản | | Tóm tắt trước | ⚠ chấp nhận mất chi tiết |

Từ khoá nhận diện:

"cùng tài liệu, nhiều câu hỏi liên tiếp" → ⚠ context caching "kho hàng nghìn tài liệu, mỗi câu một chủ đề" → ⚠ RAG "câu hỏi đơn giản, khối lượng lớn" → mô hình nhỏ "không được giảm chất lượng" → ⚠ loại tóm tắt và hạ cỡ mô hình

⚠ Caching khác RAG thế nào Khác
⚠ Caching ⚠ giữ NGUYÊN toàn bộ ngữ cảnh, tiết kiệm việc xử lý lại
⚠ RAG ⚠ CHỌN LỌC phần liên quan, giảm lượng đưa vào
⚠ Pháp lý hợp caching ⚠ vì cần đọc trọn vẹn
Hỏi đáp trên kho lớn hợp RAG
⚠ Có thể kết hợp ⚠ RAG chọn hồ sơ, caching giữ hồ sơ đó
⚠ Lưu ý khi dùng context caching Lưu ý
⚠ Cache có THỜI HẠN ⚠ hết hạn thì phải nạp lại
⚠ Có phí LƯU cache theo thời gian ⚠ cân giữa phí lưu và phí nạp lại
⚠ Hợp với phiên làm việc tập trung ⚠ hỏi dồn trong ngày như đề này
Tài liệu đổi thì phải làm mới cache
⚠ Cache chứa dữ liệu nhạy cảm ⚠ hồ sơ vụ việc — phải kiểm soát truy cập
⚠ Riêng phân tích pháp lý Lưu ý
⚠ Điều khoản tham chiếu chéo nhau ⚠ cắt đoạn dễ hiểu sai
⚠ Điều khoản loại trừ đảo ngược nghĩa ⚠ bỏ sót là sai hoàn toàn
⚠ Luật sư PHẢI rà soát ⚠ AI không đưa ra ý kiến pháp lý
Yêu cầu trích dẫn điều khoản
⚠ Bảo mật hồ sơ khách hàng ⚠ nghĩa vụ nghề nghiệp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache tiết kiệm bao nhiêu thật sự | ⚠ đo hoá đơn trước và sau | | Thời hạn cache có khớp nhịp làm việc không | ⚠ luật sư hỏi rải cả ngày | | Ai truy cập được cache | ⚠ hồ sơ vụ việc là dữ liệu đặc quyền |

Và điểm phân biệt quan trọng nhất của câu này: RAG giảm lượng ngữ cảnh, caching giữ nguyên ngữ cảnh mà không trả tiền lại. Khi đề nói không được giảm chất lượng phân tích, mọi phương án cắt bớt thông tin đều bị loại — kể cả phương án thường đúng nhất.

Câu 276 Google Cloud's gen AI offerings

A financial services company wants to explore AI agent capabilities but faces a collaboration challenge. Their business analysts understand customer workflows and can design the agent logic, but they lack coding expertise. Meanwhile, their development team has Python skills but limited time to start projects from scratch. The company needs an approach where analysts can prototype agent behavior quickly, test it with stakeholders, then hand off a working foundation to developers for production refinement and deployment.

Which Vertex AI Agent Builder capability best supports this collaborative workflow between business and technical teams?

  1. A

    Agent Designer with code export to Agent Development Kit (ADK).

  2. B

    Agent Development Kit (ADK) for direct Python coding.

  3. C

    NotebookLM Enterprise for research and analysis.

  4. D

    Agent Garden for deploying pre-built agent templates.

Xem giải thích

Đáp án

A — Agent Designer kèm khả năng xuất code sang Agent Development Kit (ADK).

Vì sao đúng

Đề mô tả một quy trình BÀN GIAO hai chiều, và chỉ phương án A phục vụ được cả hai phía:

⚠ Ghép từng phía:

Chuyên viên nghiệp vụ
   ⚠ hiểu quy trình khách hàng
   ⚠ KHÔNG biết lập trình
   → ⚠ Agent Designer — dựng
     trực quan

Lập trình viên
   ⚠ biết Python
   ⚠ KHÔNG có thời gian bắt đầu
     từ đầu
   → ⚠ nhận CODE XUẤT RA từ
     bản dựng, tinh chỉnh tiếp

⚠ Điểm mấu chốt là chữ "hand off":

⚠ Nếu chỉ có công cụ trực quan
   → ⚠ lập trình viên phải VIẾT LẠI
     từ đầu

⚠ Nếu chỉ có ADK
   → ⚠ chuyên viên nghiệp vụ
     không tham gia được

⚠ Xuất code = CẦU NỐI
   → ⚠ bản dựng trở thành nền móng
     thật, không phải bản vẽ vứt đi

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

  • B (ADK để lập trình Python trực tiếp) — ⚠ bỏ hẳn chuyên viên nghiệp vụ ra ngoài, mà họ mới là người hiểu quy trình khách hàng. Cũng vi phạm ràng buộc "lập trình viên không có thời gian bắt đầu từ đầu".

  • D (Agent Garden để triển khai mẫu dựng sẵn) — ⚠ bẫy hợp lý: mẫu tiết kiệm thời gian thật. Nhưng nó ⚠ không giải bài toán CỘNG TÁC — chuyên viên nghiệp vụ vẫn không tự dựng và thử nghiệm được logic của mình.

  • C (NotebookLM Enterprise cho nghiên cứu và phân tích) — ⚠ sai hẳn loại công cụ: đó là công cụ đọc hiểu tài liệu, không phải công cụ xây agent.

Ghi nhớ

⚠ Công cụ theo vai trò trong Agent Builder — bảng phải thuộc: | Công cụ | Ai dùng | Cho ra | |---|---|---| | ⚠ Agent Designer | ⚠ người không lập trình | ⚠ bản dựng + CODE XUẤT ĐƯỢC — đề này | | ADK | ⚠ lập trình viên | ⚠ code hoàn toàn tuỳ biến | | Agent Garden | lập trình viên | ⚠ mẫu để bắt đầu | | NotebookLM | mọi người | ⚠ đọc hiểu tài liệu, không xây agent |

Từ khoá nhận diện:

"nghiệp vụ dựng, lập trình viên hoàn thiện, bàn giao" → ⚠ Designer + xuất ADK "đội chưa có kinh nghiệm, cần mẫu" → ⚠ Agent Garden "kiểm soát tối đa bằng code" → ⚠ ADK "nghiên cứu tài liệu" → NotebookLM

⚠ Vì sao xuất code quan trọng hơn nó nghe Lý do
⚠ Công cụ trực quan thường là NGÕ CỤT ⚠ dựng xong rồi phải làm lại bằng code
⚠ Xuất code giữ được công sức của bên nghiệp vụ
⚠ Code là thứ đưa được vào quản lý phiên bản, CI/CD
Lập trình viên đọc code hiểu ngay ý định ⚠ hơn là đọc mô tả bằng lời
Bài học chung ⚠ hỏi "công cụ này xuất ra được gì" trước khi chọn
⚠ Ranh giới trách nhiệm nên chia thế nào Chia
⚠ Nghiệp vụ ⚠ luồng hội thoại, quy tắc, tiêu chí thành công
⚠ Kỹ thuật ⚠ tích hợp hệ thống, bảo mật, xử lý lỗi, hiệu năng
Cùng nhau ⚠ thử nghiệm với người dùng thật
Rủi ro nếu tách rời ⚠ agent chạy tốt nhưng giải sai bài toán
⚠ Bản dựng nào cũng cần làm lại phần này Phần
⚠ Xác thực và phân quyền
⚠ Xử lý lỗi khi API ngoài hỏng
⚠ Giới hạn và kiểm soát chi phí
Ghi log và giám sát
⚠ Kiểm thử tự động ⚠ bản dựng không có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Code xuất ra có đọc và sửa được không | ⚠ thử trước khi cam kết quy trình | | Bên nghiệp vụ có thử với người dùng thật chưa | ⚠ trước khi bàn giao | | Ai chịu trách nhiệm sau khi bàn giao | ⚠ rõ ràng ngay từ đầu |

Và câu hỏi nên đặt cho mọi công cụ no-code: "nó xuất ra cái gì khi tôi cần đi xa hơn nó?" Công cụ nào chỉ giữ được kết quả trong chính nó thì sớm muộn cũng trở thành công sức phải làm lại từ đầu.

Câu 277 Techniques to improve gen AI model output

A generative AI-powered chatbot on an e-commerce website occasionally "hallucinates" and invents a 50% discount policy that does not exist. This creates a direct business cost due to lost revenue from honoring the fake policy and customer dissatisfaction.

What is the most effective technical strategy to mitigate this specific financial risk?

  1. A

    Fine-tuning the model with more general customer service chat logs.

  2. B

    Using prompt chaining to break the user's query into smaller steps.

  3. C

    Adding a disclaimer that the AI's answers may be inaccurate.

  4. D

    Implementing grounding to force the model to base its answers only on a trusted data source of official company policies.

Xem giải thích

Đáp án

D — Áp dụng grounding để buộc mô hình chỉ trả lời dựa trên nguồn dữ liệu tin cậy chứa chính sách chính thức của công ty.

Vì sao đúng

Đề mô tả một ca ảo giác gây thiệt hại tài chính trực tiếp: bot bịa ra chính sách giảm giá 50% không tồn tại.

⚠ Vì sao grounding chữa đúng nguyên nhân:

Nguyên nhân gốc:
   ⚠ mô hình SINH ra câu trả lời
     nghe hợp lý từ mẫu hình chung
   ⚠ "giảm 50%" là câu rất phổ biến
     trong dữ liệu huấn luyện
        ↓
⚠ Grounding buộc trả lời từ
  NGUỒN CHÍNH THỨC
        ↓
⚠ Không có trong tài liệu chính sách
  → ⚠ không được nói ra

⚠ Rủi ro tài chính rất cụ thể:

⚠ Bot hứa → công ty phải giữ lời
   (hoặc mất uy tín)
⚠ Khách chụp màn hình chia sẻ
   → ⚠ nhiều người cùng đòi
⚠ Có thể thành nghĩa vụ pháp lý

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

  • C (thêm cảnh báo rằng câu trả lời của AI có thể không chính xác) — ⚠ không sửa gì cả. Bot vẫn bịa, khách vẫn tin, và ⚠ ở nhiều nơi một dòng chữ nhỏ không miễn trừ được trách nhiệm với thông tin công ty tự phát ra.

  • A (fine-tune bằng thêm log chat CSKH chung) — ⚠ dạy PHONG CÁCH, không dạy SỰ THẬT. Mô hình sẽ nói giống nhân viên hơn nhưng vẫn bịa số. ⚠ Tệ hơn: nếu log cũ có nhân viên từng nhắc khuyến mãi thật trong quá khứ, mô hình còn học đúng cái sai đó.

  • B (prompt chaining chia nhỏ câu hỏi) — ⚠ giúp suy luận nhiều bước, không giúp độ chính xác sự thật. ⚠ Chia nhỏ một câu hỏi bịa vẫn ra câu trả lời bịa.

Ghi nhớ

⚠ Bốn cách xử lý ảo giác — bảng phải thuộc: | Cách | Hiệu quả | |---|---| | ⚠ Grounding / RAG | ⚠ MẠNH NHẤT — buộc bám nguồn — đề này | | Yêu cầu trích dẫn | ⚠ kiểm chứng được | | ⚠ Temperature thấp | ⚠ giảm sáng tạo, hỗ trợ thêm | | Người duyệt | ⚠ không mở rộng được cho chatbot thời gian thực | | ⚠ Không hiệu quả | ⚠ cảnh báo, fine-tune phong cách, prompt chaining |

Từ khoá nhận diện:

"bịa thông tin, sai sự thật về công ty" → ⚠ grounding "cần suy luận nhiều bước" → chain-of-thought / chaining "cần giọng văn đúng thương hiệu" → fine-tuning "thêm disclaimer" → ⚠ gần như luôn là phương án SAI

⚠ Vì sao ảo giác về chính sách đặc biệt nguy hiểm Lý do
⚠ Nghe rất hợp lý ⚠ "giảm 50%" là con số rất đời thường
⚠ Khách KHÔNG có cách kiểm chứng ⚠ họ tin bot là kênh chính thức
⚠ Lan truyền nhanh ⚠ ảnh chụp màn hình
Có thể ràng buộc pháp lý ⚠ tuyên bố từ kênh chính thức của công ty
⚠ Kiến trúc chatbot bán hàng an toàn Lớp
⚠ Grounding trên tài liệu chính sách chính thức
⚠ Temperature thấp
⚠ Yêu cầu trích dẫn điều khoản chính sách
⚠ Danh sách chủ đề CẤM tự trả lời ⚠ giá, khuyến mãi, hoàn tiền → chuyển người
Lọc đầu ra bắt con số và tỷ lệ phần trăm ⚠ lớp chặn cuối
Ghi vết mọi hội thoại
⚠ Grounding vẫn có giới hạn Giới hạn
⚠ Tài liệu chính sách phải ĐÚNG và MỚI ⚠ chính sách cũ chưa gỡ là vẫn sai
⚠ Truy hồi nhầm đoạn vẫn ra câu sai
Mô hình có thể diễn giải lệch ⚠ nên yêu cầu trích nguyên văn
Vì thế ⚠ grounding GIẢM chứ không TRIỆT TIÊU ảo giác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hỏi về khuyến mãi không tồn tại thì bot nói gì | ⚠ phải nói không có, không được bịa | | Chính sách hết hiệu lực đã gỡ chưa | ⚠ rà chỉ mục định kỳ | | Có chặn bot tự nói về giá không | ⚠ chủ đề rủi ro cao nên chuyển người |

Và điều đáng nhớ nhất: thêm dòng cảnh báo là phản ứng của bộ phận pháp lý, không phải giải pháp kỹ thuật. Nó không làm giảm số lần bot bịa, không làm khách bớt tin, và trong nhiều trường hợp cũng không cứu được công ty khỏi phải giữ lời hứa mà chính hệ thống của họ đưa ra.

Câu 278 Google Cloud's gen AI offerings

A company is deploying a business-critical, generative AI-powered chatbot for its customers, who are primarily located in Germany. The two most important business requirements are:

  1. Low latency for the German users.

  2. High availability to ensure the service remains online even if an entire data center fails.

What is the correct Google Cloud deployment strategy to meet both of these requirements?

  1. A

    Deploy the chatbot's resources across multiple zones within a single German region.

  2. B

    Deploy the chatbot's resources to a single zone within a German region.

  3. C

    Deploy the chatbot's resources across multiple regions, one in Germany and one in Asia.

  4. D

    Deploy the chatbot's resources to a single zone in a US-based region.

Xem giải thích

Đáp án

A — Triển khai tài nguyên trên NHIỀU ZONE trong MỘT region ở Đức.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi yêu cầu quyết định một chiều của kiến trúc:

⚠ Ghép hai yêu cầu:

"độ trễ THẤP cho người dùng Đức"
    → ⚠ chọn REGION ở Đức
    → ⚠ gần người dùng về địa lý

"sẵn sàng CAO — sống sót khi
 CẢ MỘT trung tâm dữ liệu hỏng"
    → ⚠ trải trên NHIỀU ZONE
    → ⚠ mỗi zone là một trung tâm
      dữ liệu độc lập

⚠ Zone và Region — phải phân biệt:

⚠ REGION = một vùng địa lý
   → ⚠ quyết định ĐỘ TRỄ

⚠ ZONE = một trung tâm dữ liệu
   trong region
   → ⚠ quyết định KHẢ NĂNG
     CHỊU LỖI

⚠ Nhiều zone trong một region
   = ĐỘ TRỄ THẤP + CHỊU ĐƯỢC
     LỖI HẠ TẦNG

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

  • C (nhiều region: một ở Đức, một ở châu Á) — ⚠ bẫy mạnh nhất vì "nhiều region" nghe như mức sẵn sàng cao nhất. Nhưng ⚠ region châu Á không giúp người dùng Đức: nếu định tuyến sang đó thì độ trễ rất cao, còn nếu chỉ để dự phòng thì tốn kém mà không cần. ⚠ Ngoài ra còn phát sinh vấn đề chủ quyền dữ liệu — dữ liệu người dùng EU sang châu Á là vấn đề tuân thủ thật.

  • B (một zone duy nhất ở region Đức) — độ trễ tốt nhưng ⚠ một zone hỏng là dịch vụ chết. Vi phạm yêu cầu thứ hai.

  • D (một zone ở region Mỹ) — ⚠ sai cả hai: độ trễ cao cho người dùng Đức và không chịu được lỗi.

Ghi nhớ

⚠ Zone – Region – Multi-region — bảng phải thuộc: | Mức | Chống được | Cái giá | |---|---|---| | Một zone | ⚠ không gì cả | rẻ nhất | | ⚠ Nhiều zone, một region | ⚠ hỏng một trung tâm dữ liệu | ⚠ cân bằng tốt nhất — đề này | | Nhiều region | ⚠ thảm hoạ cả vùng | ⚠ đắt, phức tạp, có thể vướng tuân thủ |

Từ khoá nhận diện:

"độ trễ thấp cho người dùng ở X" → ⚠ chọn REGION gần X "sống sót khi một trung tâm dữ liệu hỏng" → ⚠ nhiều ZONE "sống sót khi cả vùng gặp thảm hoạ" → ⚠ nhiều REGION "dữ liệu phải ở lại EU" → ⚠ ràng buộc region bắt buộc

⚠ Khi nào mới cần nhiều region Khi nào
⚠ Người dùng ở nhiều châu lục ⚠ phục vụ gần từng nhóm
⚠ Yêu cầu khôi phục sau thảm hoạ cấp vùng
Yêu cầu pháp lý về dự phòng
⚠ Không cần khi ⚠ người dùng tập trung một nước — như đề này
⚠ Riêng người dùng ở Đức/EU Lưu ý
⚠ GDPR áp dụng
⚠ Dữ liệu nên ở lại EU ⚠ chuyển ra ngoài EU cần cơ sở pháp lý
⚠ Đức có yêu cầu chặt hơn mức chung
Chọn region europe-west3 (Frankfurt) ⚠ hoặc region EU khác
⚠ Kiểm cả nơi MÔ HÌNH chạy ⚠ không chỉ nơi lưu dữ liệu
⚠ Sẵn sàng cao còn cần gì ngoài nhiều zone Cần
⚠ Cân bằng tải giữa các zone
⚠ Kiểm tra sức khoẻ và tự chuyển hướng
⚠ CSDL cũng phải nhiều zone ⚠ hay bị quên — ứng dụng dự phòng mà CSDL một zone
Kiểm thử chuyển đổi thật ⚠ tắt thử một zone
⚠ Đủ dung lượng dự phòng ⚠ zone còn lại phải gánh nổi toàn bộ tải

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CSDL có nhiều zone không | ⚠ điểm hỏng đơn hay bị bỏ sót nhất | | Đã thử tắt một zone chưa | ⚠ diễn tập sự cố | | Dữ liệu có ở lại EU không | ⚠ kiểm cả sao lưu và log |

Và điều dễ nhầm nhất ở nhóm câu này: "nhiều hơn" không phải lúc nào cũng "tốt hơn". Thêm một region ở châu lục khác không cải thiện gì cho người dùng Đức, mà lại thêm chi phí, thêm độ phức tạp và thêm một vấn đề tuân thủ.

Câu 279 Google Cloud's gen AI offerings

A large retail chain with both an online store and physical locations wants to create a highly efficient marketing strategy. Their goal is to use data from online ad campaigns (Google Ads) and website traffic (Google Analytics) to generate personalized promotional offers that drive customers to their physical stores, tracking the results via store visit conversions.

Which of Google's strengths is best demonstrated by this end-to-end business scenario?

  1. A

    The comprehensive AI ecosystem that allows combining first-party data from services like Ads and Analytics with Cloud's powerful gen AI models in a unified workflow.

  2. B

    Google's open approach, which allows the company to use any open-source model for the task.

  3. C

    The AI-optimized infrastructure, such as TPUs, that can train a new foundation model from scratch at high speed.

  4. D

    The secure-by-design infrastructure that ensures customer data privacy throughout the process.

Xem giải thích

Đáp án

A — Hệ sinh thái AI toàn diện, cho phép kết hợp dữ liệu bên thứ nhất từ các dịch vụ như Ads và Analytics với mô hình gen AI mạnh của Cloud trong một luồng công việc thống nhất.

Vì sao đúng

Đề mô tả một luồng đầu-cuối đi qua nhiều sản phẩm Google khác nhau, và chính sự liền mạch đó là điểm được hỏi:

⚠ Luồng trong đề:

Google Ads
   ⚠ dữ liệu chiến dịch quảng cáo
        ↓
Google Analytics
   ⚠ hành vi trên website
        ↓
⚠ Mô hình gen AI trên Cloud
   ⚠ sinh ưu đãi CÁ NHÂN HOÁ
        ↓
Cửa hàng vật lý
        ↓
⚠ Store visit conversions
   ⚠ ĐO ngược lại kết quả
        ↓
⚠ VÒNG KHÉP KÍN

⚠ Vì sao đây là thế mạnh riêng:

⚠ Ít nhà cung cấp nào có ĐỦ
   quảng cáo + phân tích + đám mây
   + mô hình AI + dữ liệu bản đồ
        ↓
⚠ Ghép được mà không phải
  dựng tích hợp thủ công

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

Cả ba đều là thế mạnh có thật của Google nhưng không phải thứ kịch bản này minh hoạ:

  • D (hạ tầng an toàn từ thiết kế, đảm bảo riêng tư) — ⚠ bẫy hợp lý vì kịch bản có dùng dữ liệu khách hàng. Nhưng bảo mật là điều kiện nền cho mọi kịch bản, không phải thứ kịch bản NÀY thể hiện. Đề hỏi "best demonstrated by this scenario".

  • C (TPU huấn luyện mô hình nền từ đầu) — ⚠ công ty bán lẻ này ⚠ không huấn luyện mô hình nền nào cả, họ dùng mô hình có sẵn.

  • B (cách tiếp cận mở, dùng được mô hình mã nguồn mở bất kỳ) — ⚠ không liên quan: kịch bản không nói gì về mô hình mở hay việc tránh khoá chân.

⚠ Mẹo chấm: câu hỏi dạng "thế mạnh nào được thể hiện RÕ NHẤT" đòi tìm phương án khớp với chi tiết cụ thể trong đề, không phải phương án đúng chung chung.

Ghi nhớ

⚠ Bốn thế mạnh Google hay được hỏi — bảng phải thuộc: | Thế mạnh | Dấu hiệu trong đề | |---|---| | ⚠ Hệ sinh thái toàn diện | ⚠ nhiều sản phẩm Google ghép thành một luồng — đề này | | Hạ tầng tối ưu cho AI | ⚠ TPU, huấn luyện quy mô lớn | | Cách tiếp cận mở | ⚠ mô hình mở, tránh khoá chân, chạy đa đám mây | | An toàn từ thiết kế | ⚠ Titan, mã hoá, SAIF |

Từ khoá nhận diện:

"kết hợp Ads + Analytics + Cloud + AI" → ⚠ hệ sinh thái "huấn luyện mô hình khổng lồ nhanh" → TPU / hạ tầng "dùng Llama, Gemma, chạy nơi khác" → cách tiếp cận mở "chống tấn công phần cứng, mã hoá" → an toàn từ thiết kế

⚠ Dữ liệu bên thứ nhất — vì sao quý Lý do
⚠ Là dữ liệu của CHÍNH khách hàng bạn ⚠ đối thủ không có
⚠ Cookie bên thứ ba đang biến mất ⚠ dữ liệu bên thứ nhất càng quan trọng
⚠ Chính xác hơn dữ liệu mua ngoài
Ghép được với hành vi thật ⚠ online và tại cửa hàng
⚠ Vòng khép kín online – offline Bước
⚠ Quảng cáo online
⚠ Hành vi trên website
⚠ Ưu đãi cá nhân hoá do AI sinh
⚠ Lượt ghé cửa hàng vật lý ⚠ store visit conversions
Phản hồi lại chiến dịch ⚠ biết quảng cáo nào thật sự hiệu quả
Giá trị ⚠ đo được ảnh hưởng online tới doanh thu offline
⚠ Nghĩa vụ riêng tư trong kịch bản này Nghĩa vụ
⚠ Đo lượt ghé cửa hàng dùng dữ liệu VỊ TRÍ ⚠ cần đồng ý rõ ràng
⚠ Ghép dữ liệu nhiều nguồn làm hồ sơ chi tiết hơn ⚠ rủi ro riêng tư tăng theo
Phải cho phép từ chối
⚠ Đừng suy đoán thuộc tính nhạy cảm ⚠ sức khoẻ, tôn giáo, tài chính
Tuân thủ GDPR nếu có khách EU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khách có đồng ý cho ghép dữ liệu không | ⚠ kiểm chính sách đồng ý | | Ưu đãi cá nhân hoá có công bằng giữa các nhóm không | ⚠ giá khác nhau theo nhóm là rủi ro pháp lý | | Đo lượt ghé cửa hàng có chính xác không | ⚠ dữ liệu vị trí có sai số |

Và cách phân biệt bốn thế mạnh trong đề thi: đọc xem kịch bản NHẮC TỚI những sản phẩm nào. Kịch bản nhắc nhiều sản phẩm Google khác dòng ghép lại với nhau thì đang nói về hệ sinh thái; nhắc phần cứng thì nói về hạ tầng; nhắc mô hình mở thì nói về tính mở.

Câu 280 Fundamentals of gen AI

A marketing team has a large dataset of campaign results in a spreadsheet. They need to quickly understand key trends and performance metrics but lack the expertise to write complex database queries.

How can generative AI be best applied to solve this problem?

  1. A

    By allowing users to ask questions in natural language to get summaries and visualizations of the data.

  2. B

    By generating a new dataset of synthetic customer profiles.

  3. C

    By translating the campaign report into five different languages.

  4. D

    By creating custom code to deploy a new campaign website.

Xem giải thích

Đáp án

A — Cho phép người dùng đặt câu hỏi bằng ngôn ngữ tự nhiên để nhận về tóm tắt và biểu đồ của dữ liệu.

Vì sao đúng

Đề nêu một vấn đề duy nhất: đội marketing có dữ liệu nhưng không biết viết truy vấn.

⚠ Ghép vấn đề với giải pháp:

"cần hiểu nhanh xu hướng và
 chỉ số hiệu quả"
    → ⚠ cần TÓM TẮT và TRỰC QUAN

"không có chuyên môn viết
 truy vấn CSDL phức tạp"
    → ⚠ cần giao diện NGÔN NGỮ
      TỰ NHIÊN

⚠ Gen AI phá bỏ rào cản gì:

Trước đây:
   ⚠ muốn hỏi dữ liệu → phải biết SQL
   ⚠ phải nhờ đội phân tích
   ⚠ chờ vài ngày mới có câu trả lời

⚠ Bây giờ:
   ⚠ hỏi bằng tiếng người
   ⚠ mô hình sinh truy vấn
   ⚠ trả về tóm tắt và biểu đồ
   → ⚠ dân chủ hoá việc phân tích
     dữ liệu

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

Cả ba đều là năng lực có thật của gen AI nhưng giải bài toán khác:

  • B (sinh tập hồ sơ khách hàng tổng hợp) — ⚠ tạo dữ liệu mới, trong khi họ đã có dữ liệu và cần hiểu nó.

  • C (dịch báo cáo ra năm ngôn ngữ) — ⚠ giải bài toán ngôn ngữ, không phải bài toán phân tích.

  • D (sinh code triển khai website chiến dịch mới) — ⚠ hoàn toàn khác việc, và đội marketing cũng không cần website.

Ghi nhớ

⚠ Bốn năng lực gen AI trên dữ liệu — bảng phải thuộc: | Năng lực | Việc | |---|---| | ⚠ Hỏi bằng ngôn ngữ tự nhiên | ⚠ người không kỹ thuật tự truy vấn — đề này | | Tóm tắt | ⚠ nén báo cáo dài | | Khám phá insight | ⚠ tìm mẫu hình ẩn | | Sinh dữ liệu tổng hợp | ⚠ khi không được dùng dữ liệu thật |

Từ khoá nhận diện:

"không biết SQL, muốn tự hỏi dữ liệu" → ⚠ giao diện ngôn ngữ tự nhiên "tìm mẫu hình chưa ai thấy" → discovery "không được dùng dữ liệu thật" → dữ liệu tổng hợp "nhiều ngôn ngữ" → dịch

⚠ Công cụ thực tế cho việc này Công cụ
⚠ Gemini trong BigQuery ⚠ sinh SQL từ câu hỏi
⚠ Gemini trong Google Sheets ⚠ đúng với "spreadsheet" trong đề
Looker + AI ⚠ hỏi trên mô hình dữ liệu
NotebookLM ⚠ hỏi trên tài liệu
⚠ Rủi ro của hỏi dữ liệu bằng ngôn ngữ tự nhiên Rủi ro
⚠ Câu hỏi mơ hồ → truy vấn sai ⚠ "khách hàng tốt nhất" nghĩa là gì
⚠ Kết quả TRÔNG có thẩm quyền dù sai ⚠ nguy hiểm nhất
⚠ Không thấy phần dữ liệu bị lọc mất ⚠ giá trị rỗng, bản ghi trùng
Tương quan bị hiểu thành nhân quả
Cách giảm ⚠ yêu cầu HIỆN truy vấn đã sinh ra
⚠ Việc nên làm để dùng an toàn Việc
⚠ Luôn xem truy vấn được sinh ⚠ học dần và kiểm được
⚠ Kiểm chéo vài con số bằng cách thủ công
Định nghĩa chỉ số thống nhất ⚠ "doanh thu" phải có một cách tính
⚠ Dữ liệu bẩn thì kết quả bẩn ⚠ AI không sửa được dữ liệu sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn sinh ra có đúng ý không | ⚠ đọc truy vấn, không chỉ đọc kết quả | | Tổng cộng có khớp với báo cáo gốc không | ⚠ kiểm một con số đã biết | | Có bản ghi nào bị loại âm thầm không | ⚠ đếm số dòng đầu vào và đầu ra |

Và giá trị lớn nhất của năng lực này không nằm ở việc trả lời nhanh hơn, mà ở chỗ đội marketing hỏi được nhiều câu hơn. Khi mỗi câu hỏi không còn phải xếp hàng chờ đội phân tích, người ta bắt đầu hỏi cả những câu trước đây không đáng công để hỏi — và đó thường là nơi tìm ra điều bất ngờ.