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

Đáp án

A — Summarization, Creation, Discovery (Tóm tắt, Sáng tạo, Khám phá).

Vì sao đúng

Đề nêu ba việc theo thứ tự, và mỗi việc khớp đúng một năng lực lõi:

⚠ Ghép từng cặp:

1. "Rút gọn báo cáo nghiên cứu dài
    thành bản tóm tắt một trang"
    → ⚠ SUMMARIZATION
    → ⚠ nén thông tin đã có

2. "Tạo lời quảng cáo MỚI và
    hình ảnh cho sản phẩm"
    → ⚠ CREATION
    → ⚠ sinh nội dung chưa từng có

3. "Phân tích đánh giá khách hàng
    để tìm PHÀN NÀN ẨN và
    yêu cầu tính năng"
    → ⚠ DISCOVERY
    → ⚠ tìm ra thứ chưa ai biết
      trong khối dữ liệu lớn

⚠ Chìa khoá phân biệt Discovery và Summarization:

Summarization
    → ⚠ NÉN cái đã biết
    → "báo cáo này nói gì"

⚠ Discovery
    → ⚠ TÌM RA cái chưa biết
    → "có mẫu hình gì tôi chưa
       nhận ra"
    → ⚠ từ khoá: "HIDDEN", "insight",
      "pattern", "trend"

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

• B (Automation, Discovery, Creation) — sai thứ tự hoàn toàn. Tóm tắt báo cáo không phải "tự động hoá", và "tạo lời quảng cáo mới" rõ ràng là Creation chứ không phải Discovery.

• C (Creation, Summarization, Automation) — đảo ngược hai cái đầu. "Rút gọn" là Summarization, không phải Creation.

• D (Discovery, Automation, Summarization) — sai cả ba vị trí.

⚠ Nhận xét về cách ra đề: kiểu câu ghép theo thứ tự này chỉ cần xác định chắc chắn MỘT cặp là loại được hầu hết phương án. Ở đây "tạo lời quảng cáo mới" = Creation chỉ có ở A và B ở hai vị trí khác nhau; xác định thêm việc đầu là Summarization là ra ngay A.

Ghi nhớ

⚠ Bốn năng lực lõi của gen-AI — bảng phải thuộc: | Năng lực | Nghĩa | Từ khoá | |---|---|---| | ⚠ Creation | ⚠ sinh nội dung MỚI | ⚠ "generate", "novel", "draft", "design" | | ⚠ Summarization | ⚠ NÉN nội dung dài | ⚠ "condense", "summarize", "TL;DR" | | ⚠ Discovery | ⚠ TÌM insight ẩn | ⚠ "hidden", "pattern", "analyze", "uncover" | | ⚠ Automation | ⚠ thay công việc lặp lại | ⚠ "routing", "classify", "workflow" |

Từ khoá nhận diện:

"novel", "brainstorm", "viết mới" → ⚠ Creation "condense", "one-page", "rút gọn" → ⚠ Summarization "hidden", "insight", "xu hướng" → ⚠ Discovery "tự động phân loại, định tuyến" → ⚠ Automation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản tóm tắt có sai số liệu không | ⚠ đối chiếu với báo cáo gốc | | Insight có thật hay mô hình bịa | ⚠ yêu cầu trích dẫn đánh giá cụ thể | | Nội dung quảng cáo có ai duyệt chưa | ⚠ HITL bắt buộc |

Và điều dễ nhầm nhất trong bốn năng lực: Discovery và Summarization đều làm việc trên dữ liệu có sẵn. Khác nhau ở chỗ tóm tắt trả lại thứ đã có trong văn bản, còn khám phá rút ra mẫu hình mà không ai viết ra trong bất kỳ đánh giá đơn lẻ nào.

Đáp án

C — Dùng Google Vids như trợ lý tạo video ngay trong Workspace.

Vì sao đúng

Đề nêu năm ràng buộc, và Google Vids khớp cả năm:

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

"kịch bản thô trong Google Docs"
    → ⚠ Vids ĐỌC THẲNG từ Docs

"ảnh sản phẩm trong Google Drive"
    → ⚠ Vids lấy THẲNG từ Drive

"không có kinh nghiệm dựng phim"
    → ⚠ Vids tự dựng storyboard

"ngân sách BẰNG KHÔNG"
    → ⚠ ĐÃ CÓ trong Workspace

"lồng tiếng chuyên nghiệp tự động"
    → ⚠ Vids sinh voiceover sẵn

⚠ Gần trùng với #14056 (chính lô này) — cùng khoá Google Vids, cùng dấu hiệu "đội không chuyên + tài sản trong Workspace + không ngân sách".

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

• A (nhờ Gemini App viết kế hoạch quay) — cho ra một văn bản, không cho ra video. Đội vẫn phải tự dựng, mà họ không biết dựng.

• B (Vertex AI Studio dựng pipeline riêng) — công cụ cho kỹ sư. Startup nhỏ không có người làm, không có tiền, và pipeline tuỳ biến là quá mức cần thiết.

• D (Imagen trên Vertex AI) — ⚠ Imagen sinh ẢNH TĨNH, không sinh video. Sản phẩm sinh video của Google là Veo. Nhưng kể cả Veo cũng chỉ cho ra đoạn clip, không lắp ráp cả video từ tài sản có sẵn kèm lồng tiếng — đó là việc của Vids.

Ghi nhớ

⚠ Bốn công cụ liên quan video/ảnh — bảng phải thuộc: | Công cụ | Cho ra | Người dùng | |---|---|---| | ⚠ Google Vids | ⚠ VIDEO HOÀN CHỈNH từ tài sản có sẵn | ⚠ nhân viên văn phòng — đề này | | ⚠ Veo | ⚠ đoạn clip sinh từ prompt | lập trình viên, sáng tạo | | ⚠ Imagen | ⚠ ẢNH TĨNH | ⚠ KHÔNG sinh video | | Vertex AI Studio | ⚠ môi trường xây pipeline | kỹ sư |

Từ khoá nhận diện:

"tài sản trong Docs/Drive, không biết dựng" → ⚠ Google Vids "sinh clip từ mô tả bằng lời" → ⚠ Veo "tạo ảnh" → ⚠ Imagen "tự xây pipeline" → Vertex AI Studio

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh sản phẩm có quyền dùng không | ⚠ kể cả ảnh trong Drive công ty | | Lời thoại có nói sai tính năng không | ⚠ người duyệt trước khi đăng | | Nhạc nền có bản quyền không | ⚠ dùng kho có sẵn của công cụ |

Và điều hay bị nhầm nhất ở nhóm câu này: Imagen không làm video. Đề rất hay đặt Imagen vào phương án của một câu hỏi về video, vì nó là cái tên quen thuộc nhất trong nhóm sinh ảnh — nhớ đúng đầu ra của từng sản phẩm là loại được ngay.

Đáp án

B — Áp dụng RAG trên cơ sở dữ liệu tồn kho trực tiếp và một nguồn phân tích xu hướng.

Vì sao đúng

Đề nêu hai lo ngại và đề bài tự nói ra chìa khoá: "connecting the model to live, external data" — nối mô hình với dữ liệu sống bên ngoài. Đó chính là định nghĩa của RAG.

⚠ Ghép từng lo ngại:

1. "gợi ý sản phẩm HẾT HÀNG"
    → ⚠ cần TỒN KHO THỜI GIAN THỰC
    → ⚠ RAG truy vấn CSDL kho ngay
      lúc trả lời

2. "không phản ánh XU HƯỚNG
    thời trang đang đổi nhanh"
    → ⚠ cần NGUỒN XU HƯỚNG MỚI
    → ⚠ RAG lấy từ feed phân tích
      xu hướng

⚠ Vì sao chỉ RAG giải được CẢ HAI:

Vấn đề gốc của mô hình nền:
    ⚠ tri thức ĐÓNG BĂNG tại thời
      điểm huấn luyện

⚠ RAG phá đúng chỗ đó:
    lấy dữ liệu MỚI NHẤT lúc chạy
    → không cần huấn luyện lại
    → ⚠ đổi dữ liệu là đổi câu trả lời
      NGAY LẬP TỨC

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

• A (fine-tune trên dữ liệu bán hàng lịch sử + tăng temperature) — sai cả hai vế. ⚠ Fine-tuning đóng băng dữ liệu ngay lúc huấn luyện, nên hôm sau kho thay đổi là lại sai; huấn luyện lại mỗi ngày thì không khả thi. Còn tăng temperature làm gợi ý NGẪU NHIÊN HƠN, tức là tệ hơn cho bài toán cần chính xác — đây là vế sai rõ ràng nhất trong cả bốn phương án.

• C (cửa sổ ngữ cảnh lớn + "knowledge cutoff thấp hơn") — ⚠ vô nghĩa: cửa sổ lớn chỉ cho phép nhét nhiều chữ hơn, nó không tự đi lấy dữ liệu; và "cutoff thấp hơn" nghĩa là tri thức CŨ HƠN — ngược hẳn điều cần. ⚠ Cụm "lower knowledge cutoff date" là bẫy chữ nghĩa đánh vào người đọc lướt.

• D (HITL + prompt engineering) — HITL là kiểm soát tốt nhưng không mở rộng được cho gợi ý thời gian thực ở quy mô bán lẻ; prompt engineering không tạo ra dữ liệu tồn kho mà mô hình không có.

Ghi nhớ

⚠ Bốn cách đưa tri thức mới vào mô hình — bảng phải thuộc: | Cách | Độ tươi | Chi phí | |---|---|---| | ⚠ RAG | ⚠ THỜI GIAN THỰC | ⚠ thấp — đề này | | Fine-tuning | ⚠ đóng băng lúc huấn luyện | ⚠ cao, phải làm lại | | Nhét vào prompt | ⚠ tươi nhưng giới hạn kích thước | thấp | | Huấn luyện lại từ đầu | tươi | ⚠ cực cao |

Từ khoá nhận diện:

"live", "real-time", "up-to-date", "tồn kho" → ⚠ RAG "phong cách, định dạng, thuật ngữ ngành" → fine-tuning "tài liệu rất dài" → context window "tăng temperature" → ⚠ gần như LUÔN SAI khi cần chính xác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gợi ý có kiểm tra tồn kho không | ⚠ thử với sản phẩm vừa hết hàng | | Độ trễ của feed xu hướng | ⚠ cập nhật mấy phút một lần | | Temperature đang đặt bao nhiêu | ⚠ gợi ý sản phẩm nên đặt thấp |

Và cách nhanh nhất để chấm câu này: đề đã tự nói ra đáp án trong chính câu hỏi — "by connecting the model to live, external data". Chỉ có RAG là kỹ thuật nối mô hình với dữ liệu sống bên ngoài; ba phương án còn lại không cái nào lấy thêm dữ liệu từ đâu cả.

Đáp án

A — Luồng liên tục dữ liệu tương tác ở mức sự kiện: nhấp chuột, lượt xem, thêm vào giỏ, truy vấn tìm kiếm.

Vì sao đúng

Đề nhấn hai chữ then chốt: "truly personalized" và "real-time intent" — cá nhân hoá thật và ý định ngay lúc này. Chỉ có hành vi mức sự kiện mang được thông tin đó.

⚠ Vì sao hành vi thắng mọi loại dữ liệu khác:

"most popular" hiện tại
    → ⚠ mọi người thấy GIỐNG NHAU

Nhân khẩu học
    → ⚠ "nữ, 30 tuổi, Hà Nội"
    → ⚠ vẫn là NHÓM, chưa phải cá nhân
    → ⚠ và KHÔNG đổi theo phút

⚠ Hành vi mức sự kiện
    → ⚠ "vừa xem 3 đôi giày chạy bộ,
       tìm 'size 42', bỏ giỏ 1 lần"
    → ⚠ Ý ĐỊNH NGAY LÚC NÀY
    → ⚠ đổi từng phút

⚠ Vì sao "real-time intent" chốt đáp án:

Ý định thay đổi trong một phiên:
   sáng mua quà cho con
   chiều mua đồ cho mình
        ↓
⚠ Hồ sơ nhân khẩu KHÔNG đổi
⚠ Chỉ CHUỖI SỰ KIỆN bắt được

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

• C (hồ sơ nhân khẩu học) — phương án gây nhầm mạnh nhất vì nghe rất "cá nhân". Nhưng nó chỉ cho cá nhân hoá theo nhóm, tĩnh, và ⚠ gợi ý theo tuổi/giới tính là rủi ro công bằng và quyền riêng tư ở nhiều nơi.

• D (dữ liệu danh mục sản phẩm chất lượng cao) — cần thiết nhưng không đủ. Mô tả sản phẩm tốt giúp hệ thống hiểu món hàng là gì, nhưng không cho biết người này muốn gì. Nó là điều kiện nền, không phải "tài sản quý nhất" cho cá nhân hoá.

• B (báo cáo market basket mua từ bên thứ ba) — dữ liệu tổng hợp của thị trường chung, không phải của khách hàng cụ thể. Đây là bước lùi so với chính hệ thống "phổ biến nhất" họ đang có.

Ghi nhớ

⚠ Bốn loại dữ liệu cho gợi ý — bảng phải thuộc: | Loại | Cho biết | Vai trò | |---|---|---| | ⚠ Sự kiện hành vi | ⚠ ý định NGAY LÚC NÀY | ⚠ quý nhất — đề này | | Danh mục sản phẩm | ⚠ món hàng là gì | ⚠ nền tảng bắt buộc | | Nhân khẩu học | nhóm người | ⚠ bổ trợ, có rủi ro công bằng | | Dữ liệu mua ngoài | ⚠ thị trường chung | ⚠ ít giá trị cá nhân hoá |

Từ khoá nhận diện:

"real-time intent", "adapt to each user" → ⚠ dữ liệu sự kiện "hiểu sản phẩm, tìm món tương tự" → dữ liệu danh mục "phân khúc khách hàng" → nhân khẩu học "xu hướng ngành" → dữ liệu bên thứ ba

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ghi đủ loại sự kiện chưa | ⚠ xem, tìm, thêm giỏ, bỏ giỏ, mua | | Gợi ý có đa dạng không | ⚠ đo tỷ lệ món mới xuất hiện | | Khách có biết dữ liệu bị thu không | ⚠ thông báo và cho phép tắt |

Và điều đáng nhớ nhất: dữ liệu hành vi là thứ duy nhất trong bốn phương án mà công ty phải tự tạo ra và không ai bán cho họ được. Đó chính là lý do đề gọi nó là "tài sản quý giá nhất".

Đáp án

A — Thiên lệch trong dữ liệu huấn luyện dẫn tới mô hình AI không công bằng.

Vì sao đúng

Đề mô tả nguyên nhân rất rõ ràng ở câu cuối: dữ liệu huấn luyện chủ yếu là lịch sử tuyển dụng của một ngành vốn có tỷ lệ tham gia thấp của chính các nhóm đó.

⚠ Chuỗi nhân quả:

Ngành lịch sử ít tuyển nhóm A
        ↓
⚠ Dữ liệu lịch sử phản ánh điều đó
        ↓
⚠ Mô hình HỌC mẫu hình đó như
  "cách tuyển đúng"
        ↓
⚠ Gắn cờ ứng viên nhóm A là
  "kém phù hợp" DÙ trình độ tương đương
        ↓
⚠ AI TỰ ĐỘNG HOÁ và KHUẾCH ĐẠI
  bất công có sẵn

⚠ Nguyên tắc phải thuộc:

⚠ Mô hình học TỪ QUÁ KHỨ
⚠ Quá khứ bất công
    → tương lai bất công
⚠ Nhưng NHANH HƠN và
  Ở QUY MÔ LỚN HƠN

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

• C (thiếu minh bạch mô hình) — phương án gần nhất và là bẫy tinh vi: thiếu minh bạch khiến khó PHÁT HIỆN vấn đề, nhưng nó không phải NGUYÊN NHÂN gây ra kết quả thiên lệch. ⚠ Ở đây họ đã phát hiện được qua kiểm toán, nên minh bạch không phải chỗ hỏng.

• D (thiếu biện pháp trách nhiệm giải trình) — cũng vậy: trách nhiệm giải trình là cơ chế quản trị để xử lý hậu quả, không phải nguyên nhân kỹ thuật.

• B (khả năng truy cập dữ liệu kém) — không liên quan. Vấn đề không phải không lấy được dữ liệu, mà là dữ liệu lấy được mang sẵn thiên lệch.

⚠ Cách phân biệt: câu hỏi là "most likely issue CAUSING" — hỏi nguyên nhân, không hỏi cái gì đáng lẽ đã ngăn được.

Ghi nhớ

⚠ Bốn nguồn thiên lệch — bảng phải thuộc: | Nguồn | Nghĩa | |---|---| | ⚠ Thiên lệch lịch sử | ⚠ thế giới thật vốn bất công — ĐỀ NÀY | | Thiên lệch mẫu | ⚠ nhóm bị thu thập thiếu | | Thiên lệch gán nhãn | ⚠ người gán nhãn mang định kiến | | ⚠ Thiên lệch triển khai | ⚠ dùng sai bối cảnh so với lúc huấn luyện |

Từ khoá nhận diện:

"dữ liệu lịch sử của ngành thiếu đại diện" → ⚠ bias dữ liệu huấn luyện "không hiểu vì sao mô hình quyết vậy" → thiếu minh bạch/giải thích được "không ai chịu trách nhiệm" → accountability "không lấy được dữ liệu" → data accessibility

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ qua vòng theo nhóm chênh bao nhiêu | ⚠ đo trên dữ liệu thật | | Mô hình dựa vào đặc trưng nào | ⚠ feature importance | | Ai chịu trách nhiệm cuối cùng | ⚠ phải là người, có tên |

Và điều quan trọng nhất phải nhớ về loại câu này: AI không tạo ra thiên lệch, nó KẾ THỪA và KHUẾCH ĐẠI thiên lệch có sẵn trong dữ liệu. Vì thế mọi biện pháp bắt đầu ở khâu dữ liệu, không phải ở khâu chỉnh mô hình.

Đáp án

B — Việc chọn mô hình nền và kích thước / độ phức tạp của nó.

Vì sao đúng

Ràng buộc là GPU hạn chế cho sinh nội dung theo thời gian thực. Ràng buộc hạ tầng như vậy ảnh hưởng trực tiếp tới việc chọn mô hình nào và cỡ nào.

⚠ Chuỗi ảnh hưởng:

GPU hạn chế
        ↓
    ⚠ Mô hình lớn chạy CHẬM
      hoặc KHÔNG chạy nổi
        ↓
    ⚠ Trải nghiệm thời gian thực
      bị ảnh hưởng
        ↓
    → ⚠ phải chọn mô hình NHỎ HƠN
    → hoặc mô hình đã tối ưu
    → hoặc gọi API thay vì tự chạy

⚠ Các lựa chọn khi bị giới hạn tài nguyên:

⚠ Mô hình NHỎ hơn
    → Gemma bản nhỏ, Gemini Flash

⚠ Gọi API thay vì tự host
    → ⚠ không cần GPU của mình

⚠ Lượng tử hoá mô hình
    → giảm bộ nhớ và tăng tốc

⚠ Tinh chỉnh mô hình nhỏ
    → ⚠ cho tác vụ hẹp, thường
      ĐỦ TỐT

⚠ Sinh trước và lưu đệm
    → ⚠ không phải mọi thứ đều
      cần thời gian thực

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

"Chiến lược marketing"     → ⚠ không liên quan
"Nguyên tắc đạo đức nội dung" → ⚠ vấn đề khác
"Định dạng lưu hồ sơ người dùng" → ⚠ không liên quan

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

• D (nguyên tắc đạo đức) — phương án gần nhất về mặt "cũng là một cân nhắc quan trọng thật" với ứng dụng cho trẻ em, nhưng nó không phải thứ bị ràng buộc GPU chi phối.

• A và C — hoàn toàn không liên quan tới ràng buộc tính toán.

Ghi nhớ

⚠ Ràng buộc kỹ thuật ảnh hưởng lựa chọn nào — bảng nên thuộc: | Ràng buộc | Ảnh hưởng tới | |---|---| | ⚠ GPU/tài nguyên hạn chế | ⚠ cỡ mô hình, tự host hay API | | Yêu cầu độ trễ thấp | ⚠ mô hình nhỏ, cache, sinh trước | | Ngân sách | ⚠ mô hình rẻ hơn, batch | | Dữ liệu không được ra ngoài | ⚠ mô hình mở chạy tại chỗ | | Tài liệu rất dài | ⚠ cửa sổ ngữ cảnh |

Từ khoá nhận diện:

"GPU hạn chế, thời gian thực" → ⚠ chọn mô hình nhỏ hơn "dữ liệu không ra ngoài" → ⚠ mô hình mở tại chỗ "tài liệu rất dài" → cửa sổ ngữ cảnh "khối lượng rất lớn" → ⚠ batch, mô hình nhỏ

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Mô hình nhỏ đã đủ tốt chưa | ⚠ thử trước khi kết luận cần mô hình lớn | | Có phần nào sinh trước được không | ⚠ giảm tải đáng kể | | Bộ lọc an toàn đã đủ chặt chưa | ⚠ với trẻ em thì không thoả hiệp |

Và cách tiếp cận thực dụng khi bị giới hạn tài nguyên: thử mô hình nhỏ nhất trước, chỉ nâng cấp khi chất lượng thật sự không đạt. Rất nhiều đội mặc định chọn mô hình mạnh nhất rồi mới đi giải bài toán hiệu năng — trong khi trình tự ngược lại thường cho kết quả tốt hơn và rẻ hơn nhiều.

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

⚠ Câu này TRÙNG ĐỀ BÀI với #13932 đã 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.

Đáp án

C — Dùng năng lực RAG dựng sẵn trong Vertex AI Search.

Vì sao đúng

Đề nêu bốn ràng buộc, và mỗi ràng buộc đều chỉ về cùng một chỗ:

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

"kho tài liệu HR NỘI BỘ"
    → ⚠ nguồn RIÊNG, không phải web

"chỉ dựa trên chính sách MỚI NHẤT"
    → ⚠ cập nhật tài liệu là đổi
      câu trả lời ngay

"tránh thông tin BỊA"
    → ⚠ GROUNDING

"specifically designed to SIMPLIFY"
    → ⚠ dịch vụ DỰNG SẴN, không
      tự xây

⚠ Vertex AI Search lo sẵn những gì:

⚠ Nạp tài liệu và cắt đoạn
⚠ Sinh embedding và lập chỉ mục
⚠ Truy hồi đoạn liên quan
⚠ Ghép vào prompt
⚠ TRẢ VỀ KÈM TRÍCH DẪN
⚠ Tôn trọng quyền truy cập tài liệu

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

• B (Gemini API + tự xây hệ thống truy hồi) — phương án gần đúng nhất và là bẫy mạnh: làm được, nhưng đề nói rõ muốn "simplify". Tự xây nghĩa là tự lo cắt đoạn, vector database, xếp hạng, đồng bộ khi tài liệu đổi, phân quyền — nhiều tháng công.

• A (fine-tune chỉ trên tài liệu HR) — ⚠ sai kỹ thuật cơ bản. Fine-tuning dạy phong cách, không đảm bảo chính xác từng câu chữ, ⚠ vẫn ảo giác, và ⚠ chính sách đổi là phải huấn luyện lại. Đề nói "latest internal policies" — fine-tune không đáp ứng nổi.

• D (grounding bằng Google Search) — ⚠ nối vào web công khai. Chính sách HR nội bộ không có trên Google. Đây là công cụ đúng cho câu hỏi thời sự công khai, sai hoàn toàn cho tài liệu riêng.

Ghi nhớ

⚠ Bốn cách "cho mô hình biết tài liệu của bạn" — bảng phải thuộc: | Cách | Khi nào | |---|---| | ⚠ Vertex AI Search (RAG sẵn) | ⚠ kho tài liệu riêng, muốn nhanh — đề này | | RAG tự xây | ⚠ cần kiểm soát sâu, có đội kỹ sư | | Grounding with Google Search | ⚠ thông tin CÔNG KHAI, thời sự | | Fine-tuning | ⚠ phong cách, KHÔNG phải sự thật |

Từ khoá nhận diện:

"tài liệu nội bộ", "chính sách công ty" → ⚠ Vertex AI Search "tin tức, sự kiện mới ngoài đời" → ⚠ Google Search grounding "giọng văn, định dạng riêng" → fine-tuning "simplify", "prebuilt", "managed" → ⚠ chọn dịch vụ có sẵn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trích dẫn tài liệu nguồn không | ⚠ không trích dẫn thì không kiểm được | | Tài liệu hết hiệu lực đã gỡ chưa | ⚠ kiểm chỉ mục định kỳ | | Người hỏi chỉ thấy tài liệu được phép chứ | ⚠ thử với tài khoản quyền thấp |

Và điều đáng nhớ nhất khi chấm nhóm câu này: đề nói "prebuilt" hoặc "simplify" là đang loại phương án tự xây, kể cả khi phương án đó về kỹ thuật hoàn toàn khả thi. Câu hỏi không phải "làm được không" mà "công cụ nào được thiết kế cho đúng việc này".

Đáp án

D — Hiểu biết phong phú, đa phương thức (giọng điệu, cảm xúc) đổi lấy chi phí và độ phức tạp cao hơn.

Vì sao đúng

Đề tự nói ra một nửa đáp án: "despite the higher cost" — họ chấp nhận trả giá cao hơn. Câu hỏi là đổi lấy cái gì.

⚠ Video cho thêm gì so với văn bản:

Khảo sát văn bản chỉ có:
    ⚠ NỘI DUNG chữ

⚠ Phỏng vấn video còn có:
    ⚠ giọng điệu — mỉa mai hay chân thành
    ⚠ nét mặt — do dự, khó chịu
    ⚠ ngôn ngữ cơ thể
    ⚠ khoảng lặng trước khi trả lời
    ⚠ nhấn nhá vào từ nào

⚠ Vì sao khác biệt này quan trọng:

Chữ: "Sản phẩm cũng ổn."
    → ⚠ phân tích văn bản: TRUNG TÍNH

Video cùng câu đó:
    ⚠ ngập ngừng, nhún vai, giọng nhạt
    → ⚠ thực chất là KHÔNG HÀI LÒNG

⚠ Cái giá phải trả:

⚠ Lưu trữ lớn hơn hàng trăm lần
⚠ Xử lý tốn tài nguyên hơn nhiều
⚠ Cần mô hình đa phương thức
⚠ Quyền riêng tư nặng hơn
   → ⚠ khuôn mặt và giọng nói là
     dữ liệu SINH TRẮC HỌC
⚠ Tuyển người tham gia khó hơn

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

• C (chi phí lưu trữ THẤP hơn đổi lấy xử lý phức tạp hơn) — ⚠ sai ngược: video tốn lưu trữ hơn nhiều, không rẻ hơn. Vế sau đúng, vế trước sai — dạng bẫy "nửa đúng" quen thuộc.

• A (tuân thủ riêng tư ĐƠN GIẢN hơn đổi lấy chất lượng thấp hơn) — ⚠ sai cả hai vế. Video làm riêng tư PHỨC TẠP hơn (sinh trắc học) và cho chất lượng CAO hơn.

• B (huấn luyện nhanh hơn đổi lấy insight ít chi tiết hơn) — sai cả hai vế, và họ không huấn luyện mô hình nào cả.

⚠ Mẹo chung: với câu "đánh đổi X lấy Y", kiểm từng vế riêng. Chỉ cần một vế sai là loại cả phương án — thường loại được ba phương án rất nhanh.

Ghi nhớ

⚠ Bốn phương thức dữ liệu — bảng phải thuộc: | Phương thức | Cho thêm | Cái giá | |---|---|---| | Văn bản | ⚠ nội dung | ⚠ rẻ nhất, dễ nhất | | Âm thanh | ⚠ giọng điệu, cảm xúc | ⚠ cần chuyển giọng nói | | Ảnh | bối cảnh trực quan | trung bình | | ⚠ Video | ⚠ TẤT CẢ — đề này | ⚠ đắt nhất, phức tạp nhất |

Từ khoá nhận diện:

"tone, emotion, sắc thái" → ⚠ cần đa phương thức "chi phí thấp, quy mô lớn" → văn bản "despite higher cost" → ⚠ đề đã xác nhận vế chi phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người tham gia có đồng ý cho AI phân tích không | ⚠ nói rõ, không giấu trong điều khoản | | Kết luận cảm xúc có khớp người đọc không | ⚠ đối chiếu mẫu với người phân tích | | Chi phí mỗi cuộc phỏng vấn | ⚠ nhân với quy mô khảo sát |

Và điều đáng cân nhắc nhất trong ca này: giá trị thật của video nằm ở chỗ nó bắt được điều người ta KHÔNG NÓI RA. Nhưng cũng chính vì thế mà suy diễn dễ sai — nên dùng nó để đặt câu hỏi tiếp theo, đừng dùng để kết luận thay người.

Đáp án

A — Google AI Studio.

Vì sao đúng

Ba dữ kiện: thử nghiệm nhanh, không phải dựng cả môi trường đám mây, chi phí ban đầu thấp. Đó chính là định vị của Google AI Studio.

⚠ Ba dữ kiện khớp:

"thử prompt NHANH với Gemini"
    → ⚠ AI Studio mở là dùng ngay
      trên trình duyệt

"KHÔNG phải dựng môi trường đám mây"
    → ⚠ không cần project, không cần
      cấu hình IAM

"chi phí ban đầu THẤP"
    → ⚠ có mức dùng miễn phí
        ↓
    ⚠ Làm mẫu xong thì LẤY MÃ
      sinh sẵn đem sang ứng dụng

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

"Vertex AI Studio"
    → ⚠ cũng để thử nghiệm, nhưng
      TRONG môi trường doanh nghiệp
    → ⚠ cần project, IAM, cấu hình
    → ⚠ nặng hơn nhu cầu "thử nhanh"

"Tự xây ứng dụng dùng Gemini API"
    → ⚠ tốn công hơn nhiều cho
      giai đoạn khám phá

"Vertex AI Pipelines"
    → ⚠ tự động hoá quy trình MLOps,
      hoàn toàn không phải để thử prompt

Đối chiếu #13861 (cùng lô) — đề đó khoá tính năng doanh nghiệp của Vertex AI cho tổ chức tài chính xử lý dữ liệu nhạy cảm. Không mâu thuẫn — AI Studio cho thử nghiệm, Vertex AI cho dữ liệu thật và sản xuất.

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

• B (Vertex AI Studio) — phương án gần nhất và là bẫy chính: tên gần giống, chức năng tương tự. Nhưng nó nằm trong Google Cloud với đầy đủ thiết lập doanh nghiệp, nặng hơn nhu cầu thử nhanh của đề.

• D và C — tốn công hơn hoặc phục vụ mục đích khác.

Ghi nhớ

⚠ AI Studio và Vertex AI — bảng phải thuộc: | | Google AI Studio | Vertex AI | |---|---|---| | Mục đích | ⚠ thử nhanh, làm mẫu | ⚠ sản xuất, doanh nghiệp | | Thiết lập | ⚠ gần như không cần | ⚠ project, IAM, cấu hình | | ⚠ Dữ liệu nhạy cảm | ⚠ KHÔNG nên | ⚠ có kiểm soát đầy đủ | | Bảo mật | cơ bản | ⚠ VPC-SC, CMEK, audit | | Chi phí | ⚠ có mức miễn phí | ⚠ theo mức dùng |

Từ khoá nhận diện:

"thử nhanh, không dựng gì, rẻ" → ⚠ Google AI Studio "dữ liệu công ty, tuân thủ, sản xuất" → ⚠ Vertex AI "khám phá và triển khai mô hình" → ⚠ Model Garden "tự động hoá quy trình ML" → Vertex AI Pipelines

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có dữ liệu thật trong prompt thử không | ⚠ nếu có thì phải chuyển sang Vertex AI | | Prompt hiệu quả có được lưu lại không | ⚠ prompt là tài sản, đừng để mất | | Đã có bộ ví dụ để đo chưa | ⚠ thử cảm tính không đủ để quyết |

Và ranh giới cần nói rõ với cả đội ngay từ ngày đầu thử nghiệm: công cụ để làm mẫu không phải nơi dán dữ liệu khách hàng. Ranh giới đó dễ bị vượt qua một cách vô tình, và rất khó thu hồi sau khi dữ liệu đã được gửi đi.

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

⚠ Câu này TRÙNG ĐỀ BÀI với #13891 đã 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.

Đáp án

D — Secure AI Framework (SAIF) của Google.

Vì sao đúng

SAIF là khung khái niệm do Google công bố, dành riêng cho việc quản trị bảo mật, quản lý rủi ro và tuân thủ khi triển khai AI — đúng ba mối lo của đề.

⚠ SAIF là gì:

⚠ KHUNG (framework), không phải
  một sản phẩm để bấm mua
        ↓
    ⚠ Mở rộng thực hành bảo mật
      phần mềm sang lĩnh vực AI
        ↓
    ⚠ Bao gồm: quản trị dữ liệu
      huấn luyện, bảo vệ mô hình,
      kiểm soát chuỗi cung ứng AI,
      giám sát và phản ứng sự cố
        ↓
    → ⚠ giúp doanh nghiệp có MỘT
      mô hình quản trị NHẤT QUÁN

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

"Hạ tầng tối ưu cho AI (TPU, GPU)"
    → ⚠ phần cứng, không phải
      khung quản trị

"Vertex AI Model Garden"
    → ⚠ DANH MỤC mô hình để chọn
      và triển khai

"Cách tiếp cận mở của Google với AI"
    → ⚠ triết lý về công nghệ mở,
      không phải khung bảo mật

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

• C (Model Garden) — phương án gần nhất vì cũng là một phần của nền tảng AI doanh nghiệp và có yếu tố lựa chọn mô hình được kiểm duyệt, nhưng nó là nơi tìm và triển khai mô hình, không phải khung quản trị rủi ro.

• B (TPU/GPU) và C (cách tiếp cận mở) — không giải quyết bài toán quản trị bảo mật.

Ghi nhớ

⚠ Sáu trụ cột của SAIF — nên nhớ ý: | Trụ cột | Nội dung | |---|---| | ⚠ Mở rộng nền tảng bảo mật sẵn có sang AI | ⚠ không làm lại từ đầu | | ⚠ Mở rộng phát hiện và phản ứng sang AI | ⚠ giám sát đầu vào/đầu ra mô hình | | Tự động hoá phòng thủ | ⚠ theo kịp tốc độ tấn công | | ⚠ Hài hoà kiểm soát trên toàn tổ chức | ⚠ một mô hình quản trị nhất quán | | Điều chỉnh kiểm soát và vòng phản hồi nhanh | ⚠ học từ sự cố | | ⚠ Đặt rủi ro AI trong BỐI CẢNH nghiệp vụ | ⚠ đánh giá rủi ro đầu-cuối |

Từ khoá nhận diện:

"khung quản trị bảo mật AI, rủi ro, tuân thủ" → ⚠ SAIF "danh mục mô hình để chọn" → ⚠ Model Garden "nguyên tắc đạo đức AI" → ⚠ 7 nguyên tắc AI của Google "phát hiện cấu hình sai, mối đe doạ" → ⚠ Security Command Center

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có bao nhiêu ứng dụng AI đang chạy | ⚠ danh sách thường dài hơn dự kiến | | Dữ liệu nào đang đi vào prompt | ⚠ rủi ro rò rỉ lớn nhất | | Ai chịu trách nhiệm khi mô hình trả lời sai | ⚠ phải rõ trước khi triển khai |

Và rủi ro quản trị lớn nhất với AI trong doanh nghiệp thường không phải là mô hình bị tấn công, mà là những công cụ AI mà nhân viên đã tự dùng mà bộ phận bảo mật chưa biết. Vì vậy bước đầu tiên của mọi khung quản trị vẫn là kiểm kê những gì đang thực sự diễn ra.

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

⚠ Câu này TRÙNG ĐỀ BÀI với #13857 đã 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.