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

Đáp án

C — Dùng ứng dụng Gemini để tạo tagline và bản nháp bài đăng mạng xã hội phù hợp mục tiêu chiến dịch và đối tượng.

Vì sao đúng

Đề nêu ba ràng buộc, và ứng dụng Gemini khớp cả ba:

⚠ Ba ràng buộc:

"động não ý tưởng, nhiều tagline,
 nhiều bản nháp"
    → ⚠ cần SINH nội dung nhanh,
      số lượng lớn

"khám phá nhiều góc độ"
    → ⚠ cần đa dạng, lặp nhanh

"công cụ DỰNG SẴN, KHÔNG cần
 cài đặt thêm"
    → ⚠ mở ra là dùng

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

• D (tạo một Gem tuỳ chỉnh với hướng dẫn thương hiệu và hồ sơ đối tượng) — ⚠ bẫy mạnh nhất và rất gần đúng: Gem tuyệt vời cho việc lặp lại lâu dài. Nhưng ⚠ đề nói "without additional setup" — tạo Gem chính là một bước thiết lập. Ở giai đoạn động não ban đầu thì chưa cần.

• A (dùng NotebookLM phân tích các chiến dịch thành công trước đây) — ⚠ đó là phân tích, không phải sinh ý tưởng mới. Hữu ích ở bước nghiên cứu, không phải bước động não.

• B (dùng Gemini for Workspace trong Slides để làm bài trình bày chiến lược) — ⚠ đó là trình bày kế hoạch, không phải tạo nội dung chiến dịch.

Ghi nhớ

⚠ Chọn công cụ theo giai đoạn — bảng phải thuộc: | Giai đoạn | Công cụ | |---|---| | Nghiên cứu tài liệu cũ | ⚠ NotebookLM | | ⚠ Động não nhanh, nhiều phương án | ⚠ Gemini app — đề này | | ⚠ Lặp lại có chuẩn thương hiệu | ⚠ Gem tuỳ chỉnh | | Soạn trong tài liệu | ⚠ Gemini for Workspace |

Từ khoá nhận diện:

"động não, nhanh, không cần cài đặt" → ⚠ Gemini app "làm nhiều lần, cần chuẩn cố định" → ⚠ Gem "phân tích tài liệu có sẵn" → NotebookLM "viết trong Docs/Slides" → Gemini for Workspace

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tagline có trùng thương hiệu khác không | ⚠ tra cứu trước khi dùng | | Có nói sai về sản phẩm không | ⚠ đối chiếu tài liệu sản phẩm | | Prompt tốt đã lưu lại chưa | ⚠ để chuyển thành Gem sau |

Và cách đọc đề chính xác ở câu này nằm ở đúng ba chữ "without additional setup". Nếu bỏ ba chữ đó thì Gem mới là câu trả lời tốt hơn — đề thi thường quyết định bằng một mệnh đề ngắn như vậy.

Đáp án

C — Data Ingestion and Preparation (nạp và chuẩn bị dữ liệu).

Vì sao đúng

Đề liệt kê ba việc, cả ba đều thuộc giai đoạn chuẩn bị dữ liệu:

⚠ Ba việc trong đề:

⚠ "thu thập dữ liệu khách hàng
   LỊCH SỬ"
   → ⚠ INGESTION — nạp dữ liệu

⚠ "LÀM SẠCH"
   → ⚠ xử lý giá trị thiếu, trùng,
     sai định dạng

⚠ "CHUYỂN ĐỔI sang định dạng
   phù hợp cho mô hình"
   → ⚠ TRANSFORMATION —
     tạo đặc trưng, mã hoá, chuẩn hoá

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

Cả ba đều là giai đoạn KHÁC trong vòng đời:

• B (Model Training) — ⚠ bẫy gần nhất: là bước NGAY SAU. Nhưng huấn luyện là lúc mô hình học từ dữ liệu đã chuẩn bị xong.

• A (Model Deployment) — ⚠ đưa mô hình ra phục vụ, ở cuối vòng đời.

• D (Model Management) — ⚠ quản lý phiên bản, theo dõi, quản trị mô hình sau khi đã có mô hình.

Ghi nhớ

⚠ Vòng đời ML — bảng phải thuộc: | Giai đoạn | Việc | |---|---| | ⚠ 1. Xác định bài toán | ⚠ thành công là gì | | ⚠ 2. Nạp và chuẩn bị dữ liệu | ⚠ thu thập, làm sạch, biến đổi — đề này | | 3. Huấn luyện | ⚠ mô hình học | | 4. Đánh giá | ⚠ đo chất lượng | | 5. Triển khai | ⚠ đưa ra phục vụ | | 6. Giám sát | ⚠ theo dõi trôi dạt |

Từ khoá nhận diện:

"thu thập, làm sạch, biến đổi, ETL" → ⚠ chuẩn bị dữ liệu "mô hình học từ dữ liệu" → huấn luyện "đưa ra endpoint" → triển khai "phiên bản, giám sát" → quản lý mô hình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đặc trưng nào chứa thông tin tương lai không | ⚠ lỗi nguy hiểm và khó phát hiện nhất | | Tỷ lệ giá trị thiếu bao nhiêu | ⚠ quyết định cách xử lý | | Chia tập trước hay sau khi biến đổi | ⚠ phải là trước |

Và điều mọi người làm ML đều học được sau vài dự án: phần lớn thời gian không dành cho mô hình, mà dành cho dữ liệu. Đội nào tưởng ngược lại thường vỡ kế hoạch ngay ở tuần thứ hai.

Đáp án

C — Data Consistency (tính nhất quán của dữ liệu).

Vì sao đúng

Đề mô tả cùng một giá trị được viết theo nhiều cách khác nhau — đó chính là vi phạm tính nhất quán.

⚠ Vấn đề trong đề:

"electronics"
"electroniks"   ← ⚠ lỗi chính tả
"ELEC"          ← ⚠ viết tắt
        ↓
⚠ CÙNG một danh mục
⚠ BA cách biểu diễn khác nhau
        ↓
⚠ Mô hình coi chúng là BA danh mục
  RIÊNG BIỆT
        ↓
⚠ Dữ liệu mỗi nhóm ít đi
⚠ Mô hình học kém

⚠ Gần trùng với #14150 (lô 150) — cùng khoá consistency, nhưng biểu hiện khác: câu kia là hai hệ thống dùng mã khác nhau, câu này là cùng một trường có nhiều biến thể. Cùng một đặc tính, hai dạng lỗi.

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

• B (Data Relevance — tính liên quan) — ⚠ hỏi dữ liệu có phục vụ đúng mục đích không. ⚠ Ở đây trường "product category" hoàn toàn liên quan, chỉ là viết lộn xộn.

• A (Data Availability — tính sẵn có) — ⚠ hỏi có truy cập được không. ⚠ Dữ liệu ở đây có đủ.

• D (Data Cost — chi phí dữ liệu) — ⚠ không phải đặc tính chất lượng dữ liệu trong khung tiêu chuẩn. Đây là phương án gây nhiễu.

Ghi nhớ

⚠ Sáu đặc tính chất lượng dữ liệu — bảng phải thuộc: | Đặc tính | Câu hỏi | |---|---| | ⚠ Consistency | ⚠ cùng thứ có viết giống nhau không — đề này | | Accuracy | ⚠ có đúng thực tế không | | Completeness | ⚠ có thiếu trường không | | Timeliness | ⚠ có mới không | | Relevance | ⚠ có phục vụ mục đích không | | Availability | ⚠ có lấy được không |

Từ khoá nhận diện:

"nhiều cách viết cho cùng một giá trị" → ⚠ consistency "ô trống" → completeness "số liệu sai thực tế" → accuracy "dữ liệu cũ" → timeliness

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đếm số giá trị duy nhất của trường phân loại | ⚠ nhiều bất thường là dấu hiệu ngay | | Có danh sách giá trị chuẩn chưa | ⚠ không có thì lỗi sẽ tái diễn | | Nhập liệu có chặn giá trị tự do không | ⚠ chữa từ gốc |

Và cách phát hiện vấn đề này nhanh nhất trong bất kỳ tập dữ liệu nào: đếm số giá trị duy nhất của mỗi trường phân loại. Một trường lẽ ra có 12 ngành hàng mà đếm ra 47 giá trị thì gần như chắc chắn đang có vấn đề nhất quán.

Đáp án

C — Lịch sử giao dịch là dữ liệu CÓ CẤU TRÚC; log chat là dữ liệu PHI CẤU TRÚC.

Vì sao đúng

Đề mô tả rất rõ đặc điểm của từng nguồn:

⚠ Ghép từng nguồn:

Lịch sử giao dịch từ CRM
   ⚠ "được tổ chức gọn gàng"
   ⚠ "TRƯỜNG XÁC ĐỊNH: mã khách,
     số tiền, ngày"
        ↓
   ⚠ CÓ CẤU TRÚC — bảng, hàng cột

Log chat hỗ trợ
   ⚠ "văn bản TỰ DO"
   ⚠ không có trường cố định
        ↓
   ⚠ PHI CẤU TRÚC

⚠ Bổ sung cho #14208 (chính lô này) — câu kia hỏi trục có nhãn / không nhãn, câu này hỏi trục có cấu trúc / phi cấu trúc. ⚠ Hai trục ĐỘC LẬP — bộ đề kiểm tra cả hai trong cùng một lô.

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

• B — ⚠ đảo ngược hoàn toàn: gán "phi cấu trúc" cho bảng giao dịch và "có cấu trúc" cho văn bản tự do.

• A (giao dịch là có nhãn, chat log là không nhãn) — ⚠ bẫy tinh vi nhất: nhầm sang trục khác. ⚠ "Có nhãn" nói về việc có đáp án đúng kèm theo hay không, không nói về hình dạng dữ liệu. Cả hai nguồn ở đây đều chưa có nhãn cho bài toán phân tích phản hồi.

• D (cả hai đều là dữ liệu thô cho tới khi AI xử lý) — ⚠ không trả lời câu hỏi: đề hỏi phân loại theo hình dạng, và "thô hay không" là trục khác nữa.

Ghi nhớ

⚠ Ba trục phân loại dữ liệu — bảng phải thuộc: | Trục | Giá trị | |---|---| | ⚠ Hình dạng | ⚠ structured / semi-structured / unstructured | | ⚠ Có nhãn hay không | ⚠ labeled / unlabeled | | Mức xử lý | ⚠ raw / processed | | ⚠ Lưu ý | ⚠ ba trục ĐỘC LẬP, một tập dữ liệu có cả ba thuộc tính |

Từ khoá nhận diện:

"trường xác định, bảng, cột" → ⚠ có cấu trúc "văn bản tự do, ảnh, âm thanh, video" → ⚠ phi cấu trúc "JSON, XML, log có định dạng" → ⚠ bán cấu trúc "đã gắn thẻ, có đáp án đúng" → ⚠ có nhãn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log chat có chứa PII không | ⚠ quét trước khi đưa vào mô hình | | Hai nguồn có nối được với nhau không | ⚠ cần mã khách chung | | Dữ liệu chat lưu từ bao giờ | ⚠ quyết định phạm vi phân tích |

Và điều đáng nhớ nhất về ba trục này: chúng độc lập với nhau, và đề thi rất thích trộn chúng vào cùng một bộ phương án. Đọc kỹ xem đề hỏi trục nào là tránh được toàn bộ nhóm bẫy này.

Đáp án

C — Gemma.

Vì sao đúng

Đề nêu bốn ràng buộc, và Gemma khớp cả bốn:

⚠ Bốn ràng buộc:

"tài nguyên tính toán HẠN CHẾ"
    → ⚠ cần mô hình NHẸ

"mô hình nền MỞ"
    → ⚠ tải trọng số về được

"chạy trên MÁY CỤC BỘ"
    → ⚠ không gọi API đám mây

"TINH CHỈNH với dữ liệu riêng"
    → ⚠ cần quyền truy cập trọng số

⚠ Gemma là gì:

⚠ Họ mô hình MỞ, NHẸ của Google
⚠ Cùng nghiên cứu nền với Gemini
⚠ Nhiều cỡ — chạy được trên laptop,
  máy trạm có GPU tầm trung
⚠ Tinh chỉnh được với dữ liệu riêng

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

• A (Gemini Ultra) — ⚠ bẫy mạnh nhất: mạnh nhất nhưng ⚠ chỉ dùng qua API, không tải về được, và ⚠ không thể chạy trên máy cục bộ có tài nguyên hạn chế.

• D (Imagen) — ⚠ sinh ẢNH, không tóm tắt bài báo.

• B (Veo) — ⚠ sinh VIDEO.

Ghi nhớ

⚠ Gemma khác Gemini — bảng phải thuộc: | Tiêu chí | Gemini | ⚠ Gemma | |---|---|---| | Dạng | ⚠ đóng, qua API | ⚠ MỞ, tải trọng số | | Nơi chạy | ⚠ đám mây Google | ⚠ bất kỳ đâu | | Cỡ | ⚠ lớn nhất, mạnh nhất | ⚠ nhẹ, nhiều cỡ nhỏ | | ⚠ Tinh chỉnh sâu | ⚠ hạn chế | ⚠ toàn quyền | | Chi phí | ⚠ trả theo lượt gọi | ⚠ trả cho phần cứng của mình |

Từ khoá nhận diện:

"mở, nhẹ, chạy cục bộ, tinh chỉnh" → ⚠ Gemma "cần năng lực mạnh nhất" → Gemini "sinh ảnh / video" → Imagen / Veo "dữ liệu không rời máy" → ⚠ Gemma

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phần cứng có chạy nổi cỡ mô hình đó không | ⚠ đo trên máy thật | | Bản tóm tắt có sai kết luận không | ⚠ đối chiếu bài gốc | | Có đủ dữ liệu để tinh chỉnh không | ⚠ cần lượng ví dụ nhất định |

Và điểm khiến Gemma đáng chú ý với giới nghiên cứu không phải là nó mạnh nhất, mà là kết quả tái hiện được. Một bài báo dựa trên mô hình đóng có thể không lặp lại được sau khi nhà cung cấp nâng cấp phiên bản — với mô hình mở thì trọng số vẫn nằm đó.

Đáp án

B — Tensor Processing Units (TPU) do Google tự thiết kế.

Vì sao đúng

Đề hỏi thành phần do Google tự thiết kế riêng để tăng tốc khối lượng công việc machine learning. Đó chính là TPU.

⚠ TPU là gì:

⚠ Chip do Google tự thiết kế
⚠ Chuyên cho phép toán TENSOR
   → ⚠ nhân ma trận quy mô lớn
   → ⚠ phép toán cốt lõi của mạng nơ-ron
⚠ Tối ưu cho huấn luyện và suy luận
  mô hình lớn
⚠ Ghép thành cụm rất lớn

⚠ So với CPU và GPU:

CPU
   → ⚠ đa năng, ít lõi mạnh
   → ⚠ kém cho ma trận lớn

GPU
   → ⚠ nhiều lõi song song
   → ⚠ tốt cho ML

⚠ TPU
   → ⚠ thiết kế RIÊNG cho ML
   → ⚠ hiệu năng trên watt cao

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

• A (CPU tiêu chuẩn xung nhịp cao) — ⚠ bẫy hợp lý vì "nhanh hơn" nghe như giải pháp. Nhưng ⚠ xung nhịp cao không giúp cho phép toán song song quy mô lớn; huấn luyện mô hình lớn cần thông lượng song song, không cần lõi đơn nhanh.

• C (NAS tối ưu cho truy cập tệp lớn) — ⚠ lưu trữ, không phải tính toán.

• D (Cloud Functions cho tiền xử lý serverless) — ⚠ dịch vụ chạy mã, không phải phần cứng tăng tốc.

⚠ Từ khoá quyết định: "specifically designed BY GOOGLE" — chỉ TPU khớp.

Ghi nhớ

⚠ Ba loại phần cứng — bảng phải thuộc: | Phần cứng | Phù hợp | |---|---| | CPU | ⚠ logic đa năng, tiền xử lý | | GPU | ⚠ ML nói chung, linh hoạt | | ⚠ TPU | ⚠ mô hình lớn, quy mô rất lớn — đề này |

Từ khoá nhận diện:

"Google tự thiết kế, tăng tốc ML" → ⚠ TPU "linh hoạt, nhiều khung khác nhau" → GPU "lưu trữ tệp" → NAS/GCS "chạy hàm theo sự kiện" → Cloud Functions

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần huấn luyện không | ⚠ phần lớn bài toán chỉ cần gọi API | | Đã đặt cảnh báo chi phí chưa | ⚠ việc đầu tiên | | Máy có tự tắt khi nhàn rỗi không | ⚠ khoản hay bị quên nhất |

Và câu nên hỏi trước khi bàn tới TPU hay GPU: dự án này có huấn luyện mô hình không? Rất nhiều đội bàn rất lâu về phần cứng cho một bài toán mà cuối cùng chỉ cần gọi API mô hình có sẵn.

Đáp án

B — Gemini for Google Workspace.

Vì sao đúng

Đề nêu ba ràng buộc và cả ba đều chỉ về Workspace:

⚠ Ba ràng buộc:

"tóm tắt thông số sản phẩm từ
 TÀI LIỆU"
    → ⚠ tài liệu nằm trong Docs/Drive

"soạn nội dung SLIDE"
    → ⚠ Google Slides

"trong BỘ CÔNG CỤ NĂNG SUẤT
 QUEN THUỘC"
    → ⚠ đề nói thẳng: ngay trong
      Workspace

⚠ Đề còn thêm "prebuilt" — dựng sẵn, không phải tự xây.

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

• D (ứng dụng Gemini độc lập) — ⚠ bẫy mạnh nhất và rất gần: nó làm được việc tóm tắt và viết nội dung. Nhưng ⚠ đề nhấn "within their familiar productivity suite" — ứng dụng độc lập nằm ngoài Docs/Slides, phải copy dán qua lại.

• C (huấn luyện agent tuỳ chỉnh phục vụ qua Agentspace) — ⚠ đề nói "prebuilt", tức là không tự xây.

• A (Vertex AI Search) — ⚠ để TÌM tài liệu, không phải để soạn slide.

Ghi nhớ

⚠ Bốn công cụ và nơi chúng sống — bảng phải thuộc: | Công cụ | Sống ở đâu | |---|---| | ⚠ Gemini for Workspace | ⚠ TRONG Docs, Slides, Gmail — đề này | | Gemini app | ⚠ ứng dụng riêng, ngoài luồng làm việc | | Agentspace | ⚠ cổng AI doanh nghiệp | | Vertex AI Search | ⚠ hạ tầng tìm kiếm |

Từ khoá nhận diện:

"trong Docs/Slides/Gmail, bộ công cụ quen thuộc" → ⚠ Gemini for Workspace "động não nhanh, không cần cài đặt" → ⚠ Gemini app "tự xây agent" → ⚠ loại khi đề nói prebuilt "tìm tài liệu" → Vertex AI Search

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thông số trên slide có khớp tài liệu gốc không | ⚠ kiểm từng con số | | Slide có chứa thông tin nội bộ không | ⚠ trước khi chia sẻ ra ngoài | | Có ai duyệt trước khi ra mắt không | ⚠ bắt buộc với tài liệu sản phẩm |

Và điểm phân biệt hai lựa chọn gần nhau ở câu này nằm ở đúng một cụm: "within their familiar productivity suite". Bỏ cụm đó đi thì ứng dụng Gemini cũng trả lời được — đề thi thường quyết định bằng một mệnh đề như vậy.

Đáp án

C — Vertex AI Agent Builder.

Vì sao đúng

Đề nêu ba việc đội phát triển cần làm, và cả ba đều là chức năng của Agent Builder:

⚠ Ba việc:

"định nghĩa MỤC TIÊU của agent"
    → ⚠ agent làm gì

"cấu hình QUYỀN TRUY CẬP CÔNG CỤ
 như API tồn kho"
    → ⚠ TOOL CALLING — cốt lõi

"quản lý LUỒNG HỘI THOẠI"
    → ⚠ nhiều lượt, giữ ngữ cảnh

⚠ Gần trùng với #14105 (lô 150), #14084 và #14063 (lô 149) — bốn câu, bốn bối cảnh (onboarding, du lịch, doanh nghiệp, tồn kho), cùng một khoá Agent Builder. Dấu hiệu chung: gọi API riêng + hội thoại + hành động.

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

• A (Google AI Studio) — ⚠ bẫy hợp lý: nơi thử prompt rất tốt. Nhưng ⚠ không có khung agent, không cấu hình được công cụ, không quản lý luồng hội thoại nhiều lượt cho sản xuất.

• B (Vertex AI Model Garden) — ⚠ danh mục mô hình để chọn, không phải công cụ xây agent.

• D (BigQuery ML) — ⚠ huấn luyện mô hình ML bằng SQL trong kho dữ liệu, hoàn toàn khác việc.

Ghi nhớ

⚠ Bốn công cụ — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Agent Builder | ⚠ xây agent có công cụ và hội thoại — đề này | | AI Studio | ⚠ thử prompt nhanh | | Model Garden | ⚠ chọn mô hình có sẵn | | BigQuery ML | ⚠ ML bằng SQL trên kho dữ liệu |

Từ khoá nhận diện:

"gọi API riêng, quản lý hội thoại, mục tiêu agent" → ⚠ Agent Builder "thử prompt" → AI Studio "duyệt mô hình" → Model Garden "SQL, dự báo trên bảng" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có gọi API thật không | ⚠ xem log, không xem câu trả lời | | Quyền của service account có tối thiểu chưa | ⚠ chỉ đọc, không ghi | | API lỗi thì agent nói gì | ⚠ thử tắt API |

Và dấu hiệu chắc chắn nhất để nhận ra câu hỏi về Agent Builder: có một API RIÊNG của công ty cần được gọi. Mô hình nền không biết gì về nó, nên phải có ai đó khai báo — và đó là việc của Agent Builder.

Đáp án

B — Lập trình viên: Google AI Studio; đội MLOps: Vertex AI Platform.

Vì sao đúng

Đề mô tả hai nhu cầu rất khác nhau và mỗi nhu cầu có công cụ riêng:

⚠ Ghép từng bên:

Lập trình viên cá nhân
   ⚠ "giao diện web ĐƠN GIẢN"
   ⚠ "thử prompt NHANH"
   ⚠ "KHÔNG viết code"
   → ⚠ Google AI Studio

Đội MLOps
   ⚠ "nền tảng TOÀN DIỆN"
   ⚠ "tiền xử lý, huấn luyện,
     triển khai, giám sát"
   ⚠ "ứng dụng cấp SẢN XUẤT"
   → ⚠ Vertex AI Platform

⚠ Gần trùng với #14175 (lô 151) — cùng phân biệt AI Studio và Vertex AI, cùng hướng khoá: một bên thử nghiệm, một bên sản xuất.

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

• A — ⚠ đảo ngược hoàn toàn: đưa Agent Builder cho người chỉ muốn thử prompt, và đưa AI Studio cho đội MLOps sản xuất.

• C (NotebookLM cho lập trình viên; Model Garden cho MLOps) — ⚠ sai cả hai: NotebookLM là công cụ nghiên cứu tài liệu, Model Garden chỉ là danh mục mô hình, không quản lý được vòng đời MLOps.

• D (BigQuery cho lập trình viên; Cloud Functions cho MLOps) — ⚠ sai hoàn toàn: một cái là kho dữ liệu, một cái là dịch vụ chạy hàm.

Ghi nhớ

⚠ Bốn tầng công cụ — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | ⚠ Thử prompt nhanh, không code | ⚠ Google AI Studio | | ⚠ Cả vòng đời MLOps sản xuất | ⚠ Vertex AI Platform | | Xây agent | ⚠ Agent Builder | | Nghiên cứu tài liệu | ⚠ NotebookLM |

Từ khoá nhận diện:

"thử nhanh, web đơn giản, không code" → ⚠ AI Studio "MLOps, triển khai, giám sát, sản xuất" → ⚠ Vertex AI "agent gọi công cụ" → Agent Builder "đọc hiểu tài liệu" → NotebookLM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu đang thử có nhạy cảm không | ⚠ quyết định chọn công cụ nào | | Khi lên sản xuất cần thêm gì | ⚠ IAM, log, giám sát, kiểm thử | | Hai đội có dùng chung phiên bản mô hình không | ⚠ tránh lệch giữa thử nghiệm và thật |

Và ranh giới đơn giản để nhớ mãi: AI Studio là bàn thử, Vertex AI là dây chuyền sản xuất. Cùng làm việc với một mô hình, nhưng thứ bao quanh nó — quyền, vết, giám sát, hoá đơn — mới quyết định công cụ nào phù hợp.

Đáp án

B — Triển khai giám sát và đánh giá LIÊN TỤC các chỉ số hiệu năng then chốt của mô hình.

Vì sao đúng

Đề nêu hai mục tiêu, cả hai đều đòi hỏi theo dõi liên tục:

⚠ Hai mục tiêu:

"câu trả lời vẫn CHÍNH XÁC và
 HỮU ÍCH THEO THỜI GIAN"
    → ⚠ phải đo đều đặn

"phát hiện SUY GIẢM CHẤT LƯỢNG
 hoặc TRÔI DẠT KHÁI NIỆM"
    → ⚠ chỉ phát hiện được nếu
      có theo dõi

⚠ Vì sao mô hình xuống cấp:

⚠ Sản phẩm và chính sách thay đổi
⚠ Cách khách hàng hỏi thay đổi
⚠ Chủ đề mới xuất hiện
        ↓
⚠ CONCEPT DRIFT — quan hệ giữa
  đầu vào và câu trả lời đúng đã đổi

⚠ Gần trùng với #14169 (lô 151) — câu kia hỏi công cụ nào (Model Monitoring), câu này hỏi thực hành nào. Cùng một bài học.

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

• A (huấn luyện lại từ đầu thường xuyên với tập dữ liệu hoàn toàn mới) — ⚠ bẫy mạnh nhất: nghe như giải pháp triệt để. Nhưng ⚠ cực kỳ tốn kém, ⚠ không biết KHI NÀO cần nếu không giám sát, và ⚠ có thể làm hỏng thứ đang chạy tốt. Huấn luyện lại là phản ứng, giám sát là cơ chế phát hiện.

• C (giảm temperature để bớt biến động) — ⚠ làm câu trả lời ổn định hơn, nhưng ⚠ không phát hiện được suy giảm — nó vẫn sai một cách nhất quán.

• D (hạn chế truy cập cho nhóm nhỏ) — ⚠ giảm phơi nhiễm chứ không giải quyết vấn đề; và làm mất chính dữ liệu thực tế cần để phát hiện trôi dạt.

Ghi nhớ

⚠ Chỉ số cần giám sát — bảng phải thuộc: | Nhóm | Chỉ số | |---|---| | ⚠ Chất lượng | ⚠ độ chính xác, mức độ hữu ích, tỷ lệ ảo giác | | ⚠ Trôi dạt | ⚠ phân bố câu hỏi đầu vào đổi chưa | | ⚠ Nghiệp vụ | ⚠ tỷ lệ giải quyết, CSAT, tỷ lệ chuyển người | | Vận hành | ⚠ độ trễ, tỷ lệ lỗi, chi phí | | ⚠ An toàn | ⚠ tỷ lệ bị bộ lọc chặn |

Từ khoá nhận diện:

"duy trì chất lượng theo thời gian, phát hiện trôi dạt" → ⚠ giám sát liên tục "huấn luyện lại thường xuyên" → ⚠ phản ứng, không phải phát hiện "giảm temperature" → ⚠ không liên quan tới suy giảm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bộ prompt vàng để đo định kỳ chưa | ⚠ không có thì không so được theo thời gian | | Ai đọc kết quả giám sát | ⚠ báo cáo không ai đọc là vô ích | | Ngưỡng nào thì hành động | ⚠ quyết định trước khi có sự cố |

Và nguyên tắc vận hành đáng nhớ: giám sát cho biết KHI NÀO cần huấn luyện lại, huấn luyện lại không thay được giám sát. Đội chọn huấn luyện lại theo lịch mà không đo gì thì vừa tốn tiền vừa không biết mình có đang cải thiện hay không.