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

Đáp án

D — Gemini Enterprise (trước đây là Google Agentspace).

Vì sao đúng

Đề mô tả một nhu cầu rộng hơn một agent đơn lẻ: cung cấp cho NHÂN VIÊN các agent tuỳ biến, tra cứu và suy luận trên nhiều nguồn dữ liệu nội bộ, và trình bày qua bảng điều khiển hoặc trang nội bộ tích hợp. Đó là định vị của sản phẩm dành cho không gian làm việc AI của doanh nghiệp.

⚠ Điểm phân biệt then chốt:

"agent cho NHÂN VIÊN"
    → ⚠ nội bộ, không phải khách hàng

"nhiều nguồn dữ liệu nội bộ"
    → ⚠ wiki, kho tài liệu, CSDL

"⚠ trình bày qua DASHBOARD hoặc
 TRANG NỘI BỘ tích hợp"
    → ⚠ đây là điểm quyết định:
      một KHÔNG GIAN LÀM VIỆC,
      không chỉ một agent

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

"Vertex AI Agent Builder"
    → ⚠ công cụ để XÂY agent —
      thiên về lập trình viên
    → ⚠ không phải không gian làm
      việc sẵn có cho nhân viên

"Vertex AI Search and Conversation"
    → ⚠ năng lực tìm kiếm và hội thoại
      — là THÀNH PHẦN bên dưới

"Public Google Search API"
    → ⚠ tìm web CÔNG KHAI, không
      phải dữ liệu nội bộ

⚠ Đối chiếu #13858 (lô 145) — đề đó khoá Vertex AI Agent Builder cho agent phục vụ KHÁCH HÀNG trên website, và trong bộ phương án đó không có lựa chọn nào ở tầng không gian làm việc. Đề này có, và mô tả rõ dashboard nội bộ cho nhân viên. Không mâu thuẫn — đọc kỹ đối tượng phục vụ và bộ phương án.

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

• B (Agent Builder) — phương án gần nhất và là bẫy mạnh nhất: nó thật sự dùng để dựng agent có grounding. Nhưng đề nhấn mạnh một giải pháp cho nhân viên với giao diện tích hợp sẵn, không phải bộ công cụ để đội kỹ thuật tự xây.

• C — là năng lực nền bên dưới.

• A — sai nguồn dữ liệu.

Ghi nhớ

⚠ Phân tầng các sản phẩm agent — bảng nên thuộc: | Tầng | Sản phẩm | Cho ai | |---|---|---| | ⚠ Không gian làm việc AI | ⚠ Gemini Enterprise / Agentspace | ⚠ NHÂN VIÊN dùng ngay | | ⚠ Công cụ xây agent | ⚠ Vertex AI Agent Builder | ⚠ đội kỹ thuật | | Năng lực nền | ⚠ Vertex AI Search and Conversation | ⚠ thành phần bên dưới | | Mô hình | Gemini | qua API |

Từ khoá nhận diện:

"agent cho nhân viên, dashboard nội bộ" → ⚠ Gemini Enterprise / Agentspace "xây agent tuỳ biến cho sản phẩm" → ⚠ Agent Builder "tìm kiếm doanh nghiệp" → Vertex AI Search "trong Gmail và Docs" → Gemini for Workspace

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Người dùng là nhân viên hay khách hàng | ⚠ quyết định chọn sản phẩm nào | | Quyền tài liệu đã rà chưa | ⚠ làm TRƯỚC khi bật | | Đội có tự xây hay dùng sẵn | ⚠ xây → Agent Builder; dùng sẵn → không gian làm việc |

Và với những câu hỏi về danh mục sản phẩm AI vốn đổi tên nhanh, cách làm bài an toàn nhất là đọc kỹ đối tượng phục vụ và mức độ "dùng sẵn hay tự xây". Hai dữ kiện đó ổn định hơn tên gọi, và thường đủ để loại ba phương án còn lại.

Đáp án

A — Cloud Vision API.

Vì sao đúng

Nhiệm vụ là phân tích ẢNH xe hư hỏng để nhận ra bộ phận nào bị hỏng. Đầu vào là ảnh, nên API phù hợp là Vision.

⚠ Chọn API theo loại dữ liệu:

"phân tích ẢNH xe gửi qua ứng dụng"
        ↓
    ⚠ đầu vào là ẢNH
        ↓
    → ⚠ Cloud Vision API

⚠ Vision API giúp được gì ở đây:

⚠ OBJECT LOCALIZATION
    → ⚠ xác định VỊ TRÍ các bộ phận
      trong ảnh

⚠ LABEL DETECTION
    → nhãn chung: xe, cản trước,
      kính chắn gió

⚠ TEXT DETECTION
    → ⚠ đọc biển số, số VIN

⚠ SAFE SEARCH
    → lọc ảnh không phù hợp

⚠ Nhưng chú ý ranh giới:

⚠ Vision API nhận nhãn PHỔ QUÁT
        ↓
    ⚠ "cản trước MÓP", "kính NỨT"
      là nhãn CHUYÊN NGÀNH
        ↓
    → ⚠ thực tế thường cần
      AutoML Vision huấn luyện
      trên ảnh hư hỏng đã gán nhãn
        ↓
    ⚠ Nhưng trong bộ phương án này,
      Vision API là API DỰNG SẴN
      duy nhất xử lý ảnh

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

"Natural Language API" → ⚠ VĂN BẢN
"Speech-to-Text API"   → ⚠ ÂM THANH
"Translation API"      → ⚠ DỊCH

Nhất quán với #13504 và #13498 (lô 143) — cùng nguyên tắc chọn API theo loại dữ liệu đầu vào. Đối chiếu #13549 (lô 144) khoá AutoML Vision khi cần nhãn riêng của ngành.

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

• B (Natural Language API) — phương án gần nhất về mặt "cũng có thể tham gia hệ thống" nếu cần phân tích mô tả bằng chữ của người dùng, nhưng nó không đọc được ảnh.

• C và D — sai loại dữ liệu.

Ghi nhớ

⚠ API theo loại dữ liệu — bảng phải thuộc: | Đầu vào | API | |---|---| | ⚠ Ảnh | ⚠ Vision API | | Video | Video Intelligence | | Âm thanh | Speech-to-Text | | Văn bản | Natural Language | | Tài liệu, biểu mẫu | ⚠ Document AI | | ⚠ Nhãn RIÊNG của ngành | ⚠ AutoML Vision |

Từ khoá nhận diện:

"phân tích ảnh, nhận diện vật thể" → ⚠ Vision API "nhãn riêng ngành, có ảnh gán nhãn" → ⚠ AutoML Vision "hoá đơn, biểu mẫu, trích trường" → Document AI "mô tả bằng chữ của người dùng" → Natural Language

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ chính xác trên ảnh THẬT của khách | ⚠ không phải ảnh studio | | Nhãn phổ quát có đủ không | ⚠ thiếu thì cần AutoML Vision | | Ai quyết định cuối cùng | ⚠ phải là người |

Và khoảng cách lớn nhất giữa bản trình diễn và hệ thống thật trong bài toán này: ảnh do khách hàng chụp bằng điện thoại trong bãi đỗ xe không giống ảnh trong tập dữ liệu mẫu. Thử nghiệm nên bắt đầu từ chính những bức ảnh đó.

Đáp án

A — Nó là một CÔNG CỤ (tool) mà agent sử dụng để truy cập thông tin bên ngoài.

Vì sao đúng

Agent gọi ra một API bên ngoài để lấy dữ liệu thật rồi trình bày lại. Trong kiến trúc agent, thành phần được gọi ra như vậy chính là tool.

⚠ Vai trò của tool trong agent:

Người dùng hỏi công thức
        ↓
    ⚠ Agent nhận ra cần dữ liệu
      mà nó KHÔNG CÓ
        ↓
    ⚠ Gọi TOOL: API cơ sở dữ liệu
      công thức
        ↓
    ⚠ Nhận kết quả THẬT
        ↓
    Diễn đạt thành câu trả lời
        ↓
    → ⚠ dữ liệu chính xác, cập nhật,
      không phải mô hình bịa

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

"Kho dữ liệu cho LỊCH SỬ HỘI THOẠI"
    → ⚠ đó là bộ nhớ của agent,
      chuyện khác hẳn

"Một kỹ thuật prompt engineering"
    → ⚠ API không phải kỹ thuật viết
      câu lệnh

"Một phần kiến thức đã huấn luyện
 sẵn của mô hình nền"
    → ⚠ NGƯỢC LẠI: agent gọi ra
      NGOÀI chính vì mô hình KHÔNG
      có dữ liệu đó

Nhất quán với #13881 (lô 145) — đề đó khoá extensions / functions cho việc agent gọi API hãng bay và khách sạn. Đề này hỏi vai trò của API trong kiến trúc, và câu trả lời là tool. Bổ sung nhau.

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

• D (kiến thức huấn luyện sẵn) — phương án gần nhất và là bẫy chính: mô hình có biết chung chung về bánh sô cô la. Nhưng đề mô tả rõ việc tra CSDL bên ngoài, tức là dữ liệu không nằm trong mô hình.

• B và C — mô tả các thành phần khác.

Ghi nhớ

⚠ Kiến trúc một agent — thành phần, bảng phải thuộc: | Thành phần | Vai trò | |---|---| | ⚠ Mô hình nền | ⚠ suy luận, quyết định làm gì tiếp | | ⚠ Chỉ dẫn (instructions) | ⚠ agent được và không được làm gì | | ⚠ TOOLS | ⚠ API, hàm để LẤY dữ liệu hoặc HÀNH ĐỘNG | | ⚠ Data store / grounding | ⚠ tài liệu để ĐỌC | | Bộ nhớ | ⚠ lịch sử hội thoại | | Orchestration | ⚠ điều phối trình tự các bước |

Từ khoá nhận diện:

"gọi API bên ngoài để lấy dữ liệu" → ⚠ tool / function calling "tra tài liệu nội bộ" → ⚠ data store / grounding "nhớ những gì đã nói" → ⚠ bộ nhớ hội thoại "quyết định trình tự các bước" → orchestration

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent gọi được tool nào | ⚠ liệt kê và phân loại đọc/ghi | | API lỗi thì agent phản ứng ra sao | ⚠ thử ngắt API | | Có bị lừa gọi sai tool không | ⚠ thử prompt injection |

Và điều biến một mô hình ngôn ngữ thành một agent thực sự hữu ích chính là bộ công cụ của nó: khả năng lấy dữ liệu thật thay vì dựa vào trí nhớ. Nhưng đó cũng là nơi rủi ro bắt đầu — nên danh sách công cụ và quyền của từng công cụ đáng được xem xét kỹ như một bản thiết kế bảo mật.

Đáp án

C — Relevance (tính liên quan).

Vì sao đúng

Dữ liệu huấn luyện là văn bản chung trên internet; tài liệu marketing của chính công ty — thứ định nghĩa giọng thương hiệu — KHÔNG có trong đó. Dữ liệu không liên quan tới kết quả mong muốn.

⚠ Vì sao là relevance:

Kết quả mong muốn:
    ⚠ nội dung mang GIỌNG THƯƠNG HIỆU
      riêng của công ty
        ↓
Dữ liệu huấn luyện:
    ⚠ văn bản chung trên internet
    ⚠ ⚠ KHÔNG có tài liệu của công ty
        ↓
    ⚠ Dữ liệu RẤT LỚN và ĐẦY ĐỦ
    ⚠ nhưng KHÔNG LIÊN QUAN tới
      mục tiêu cụ thể này
        ↓
    → ⚠ đầu ra chung chung

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

"Completeness"
    → ⚠ thiếu GIÁ TRỊ, thiếu TRƯỜNG
      trong bản ghi; ở đây dữ liệu
      đầy đủ, chỉ sai chủ đề

"Consistency"
    → ⚠ mâu thuẫn giữa các nguồn

"Format"
    → ⚠ định dạng dữ liệu

⚠ Gần trùng với #13862 (lô 145) — đề đó là chatbot trả lời sai về dòng sản phẩm mới vì dữ liệu huấn luyện không có thông tin đó, cùng khoá Relevance. Hoàn toàn nhất quán — hai tình huống, cùng một chiều chất lượng dữ liệu.

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

• D (completeness) — phương án gần nhất và là bẫy chính: nghe như "thiếu dữ liệu marketing của công ty". Nhưng completeness nói về thiếu giá trị trong bản ghi, còn đây là dữ liệu đầy đủ nhưng về chủ đề khác.

• A và B — mô tả các chiều khác.

Ghi nhớ

⚠ Các chiều chất lượng dữ liệu — bảng phải thuộc: | Chiều | Câu hỏi | |---|---| | ⚠ Relevance | ⚠ có LIÊN QUAN tới mục tiêu không | | Completeness | ⚠ có thiếu giá trị/trường không | | Consistency | ⚠ các nguồn có mâu thuẫn không | | Accuracy | có đúng không | | Timeliness | ⚠ có mới không | | Representativeness | ⚠ có đại diện không |

Từ khoá nhận diện:

"dữ liệu về chủ đề khác, kết quả chung chung" → ⚠ relevance "thiếu trường, thiếu giá trị" → completeness "hai hệ thống ghi khác nhau" → consistency "dữ liệu cũ" → timeliness

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đã thử đưa ví dụ vào prompt chưa | ⚠ thường cải thiện đáng kể, gần như miễn phí | | Có mô tả được giọng thương hiệu bằng lời không | ⚠ không mô tả nổi thì mô hình cũng khó học | | Tài liệu mẫu có nhất quán không | ⚠ quyết định chất lượng fine-tune |

Và bước đáng làm trước khi tính tới fine-tuning cho giọng thương hiệu: đưa năm bài viết mẫu tốt nhất vào prompt. Nếu kết quả đã sát hơn hẳn, thì vấn đề vốn không nằm ở mô hình mà nằm ở chỗ chưa ai cho nó xem thương hiệu này nói như thế nào.

Đáp án

D — Chính sách của Google Cloud về cô lập dữ liệu và không dùng dữ liệu khách hàng doanh nghiệp để huấn luyện mô hình dùng chung.

Vì sao đúng

Mối lo của công ty tài chính là dữ liệu độc quyền của khách hàng phải được giữ kín và không bị dùng để huấn luyện mô hình nền của Google. Chỉ chính sách dữ liệu trả lời được điều đó.

⚠ Ba yêu cầu khớp:

"dữ liệu tài chính ĐỘC QUYỀN"
    → ⚠ dùng cho huấn luyện và
      suy luận

"giữ BẢO MẬT"
    → ⚠ cô lập dữ liệu, IAM, mã hoá

"KHÔNG dùng để huấn luyện mô hình
 dùng chung của Google"
    → ⚠ đây là CAM KẾT trong điều
      khoản dịch vụ doanh nghiệp

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

"Tính mã nguồn mở của một số công cụ"
    → ⚠ về tính linh hoạt và
      chống khoá chân

"TPU giúp huấn luyện nhanh hơn"
    → ⚠ về hiệu năng

"Khả năng tự co giãn"
    → ⚠ về khả năng mở rộng

⚠ Cả ba đều là điểm mạnh thật nhưng không giải quyết mối lo về kiểm soát dữ liệu.

⚠ Gần trùng với #13895 (lô 145) — đề đó là tổ chức y tế với cùng mối lo, cùng khoá. Hoàn toàn nhất quán. Và #13861 (lô 145) về tính năng doanh nghiệp nói chung.

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

• A (mã nguồn mở) — phương án gần nhất vì cũng liên quan tới quyền kiểm soát của khách hàng, nhưng nó nói về khả năng mang khối lượng công việc đi nơi khác, không phải về việc dữ liệu có bị dùng huấn luyện hay không.

• B và C — về hiệu năng và quy mô.

Ghi nhớ

⚠ Kiểm soát dữ liệu trên nền tảng doanh nghiệp — bảng phải thuộc: | Kiểm soát | Nội dung | |---|---| | ⚠ Cam kết dữ liệu | ⚠ dữ liệu doanh nghiệp KHÔNG dùng huấn luyện mô hình chung | | ⚠ Cô lập dữ liệu | ⚠ dữ liệu khách này không lẫn khách khác | | Data residency | ⚠ chọn vùng lưu và xử lý | | VPC Service Controls | ⚠ ngăn dữ liệu rời ranh giới | | CMEK | ⚠ khoá mã hoá do khách quản | | IAM | ai truy cập được gì | | Audit log | ⚠ truy vết mọi thao tác |

Từ khoá nhận diện:

"dữ liệu có bị dùng huấn luyện không" → ⚠ chính sách dữ liệu doanh nghiệp "chống khoá chân" → mã nguồn mở "tải lớn, uptime" → scalability, reliability "khung quản trị rủi ro AI" → SAIF

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Dữ liệu có được dùng huấn luyện không | ⚠ đọc điều khoản, đừng suy đoán | | Dữ liệu lưu ở vùng nào | ⚠ yêu cầu chủ quyền dữ liệu | | Có ai đang dùng công cụ AI ngoài luồng không | ⚠ kiểm kê thực tế |

Và điều đáng lưu ý về câu hỏi "dữ liệu của tôi có bị dùng để huấn luyện không": câu trả lời khác nhau giữa dịch vụ tiêu dùng và dịch vụ doanh nghiệp của cùng một hãng. Vì vậy nó phải được xác nhận trong điều khoản của đúng sản phẩm đang dùng, chứ không suy ra từ một sản phẩm khác.

Đáp án

C — Veo.

Vì sao đúng

Nhu cầu là sinh VIDEO chất lượng cao, mạch lạc, từ mô tả văn bản. Trong họ mô hình nền của Google, đó là Veo.

⚠ Chọn theo modality đầu ra:

"tạo VIDEO từ mô tả cảnh và
 phong cách hình ảnh"
        ↓
    ⚠ text-to-video
        ↓
    → ⚠ VEO

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

"Imagen"
    → ⚠ sinh ẢNH TĨNH

"Gemini"
    → ⚠ đa phương thức nhưng
      nhiệm vụ chính là VĂN BẢN
    → ⚠ HIỂU được video, không
      phải mô hình sinh video

"Gemma"
    → ⚠ mô hình mở, nhẹ, cho văn bản

Nhất quán với #13856 (lô 145) — đề đó khoá modality là tiêu chí đầu tiên cho đúng nhu cầu sinh video. Đề này hỏi mô hình cụ thể. Bổ sung nhau. Cùng nhóm với #13880 (Imagen) và #13908 (audio).

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

• A (Imagen) — phương án gần nhất vì cũng sinh nội dung hình ảnh và cùng họ mô hình, nhưng nó tạo ảnh tĩnh, không phải chuỗi video.

• B (Gemini) và D (Gemma) — mô hình ngôn ngữ.

Ghi nhớ

⚠ Mô hình nền của Google theo modality — bảng phải thuộc: | Mô hình | Sinh ra | |---|---| | Gemini | ⚠ văn bản; HIỂU đa phương thức | | Gemma | ⚠ văn bản; mô hình MỞ, nhẹ | | Imagen | ⚠ ẢNH | | ⚠ Veo | ⚠ VIDEO — đề này | | Chirp | giọng nói | | Lyria | nhạc |

Từ khoá nhận diện:

"sinh video từ mô tả" → ⚠ Veo "sinh ảnh từ mô tả" → Imagen "hiểu video và trả lời bằng chữ" → ⚠ Gemini "chạy tại chỗ, mô hình mở" → Gemma

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Chi phí cho một phút video là bao nhiêu | ⚠ tính trước, con số lớn | | Chất lượng đủ chuẩn phát hành chưa | ⚠ thử với brief thật | | Đã thoả thuận về việc dùng AI chưa | ⚠ với khách hàng và các bên liên quan |

Và điều thực tế nhất về sinh video hiện nay: nó tạo ra tư liệu, không tạo ra bản dựng cuối. Quy trình hiệu quả vẫn là dùng AI để có nhanh nhiều phương án hình ảnh, rồi để đội hậu kỳ ghép nối và hoàn thiện như với mọi nguồn tư liệu khác.

Đáp án

D — Tensor Processing Units (TPU) và Graphics Processing Units (GPU).

Vì sao đúng

Hai loại bộ tăng tốc AI chuyên dụng trên Google Cloud, đều mạnh ở xử lý song song quy mô lớn cho khối lượng công việc huấn luyện.

⚠ Hai bộ tăng tốc:

⚠ TPU
    → ⚠ chip do GOOGLE thiết kế
      riêng cho ML
    → ⚠ tối ưu cho phép NHÂN MA TRẬN
    → mạnh nhất với mô hình rất lớn,
      TensorFlow/JAX

⚠ GPU
    → ⚠ hàng nghìn lõi song song
    → ⚠ LINH HOẠT hơn
    → hệ sinh thái rộng, hợp
      hầu hết khối lượng ML

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

"Cloud Spanner và Bigtable"
    → ⚠ CƠ SỞ DỮ LIỆU

"Cloud CPUs và Persistent Disks"
    → ⚠ CPU đa năng và ĐĨA —
      không phải bộ tăng tốc AI

"VPC và Cloud Load Balancing"
    → ⚠ MẠNG

Nhất quán với #13868 (lô 145) và #13540 (lô 144) — hai đề đó khoá riêng TPU khi đề nhấn "chip do Google thiết kế". Đối chiếu #13921 (cùng lô) khoá AI Hypercomputer khi đề hỏi kiến trúc mức HỆ THỐNG. Không mâu thuẫn — ba mức: chip, hai loại chip, cả hệ thống.

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

• B (CPU và Persistent Disk) — phương án gần nhất vì đó là tài nguyên tính toán và lưu trữ thật, nhưng CPU không phải bộ tăng tốc chuyên dụng cho AI.

• A và C — thuộc lĩnh vực dữ liệu và mạng.

Ghi nhớ

⚠ Ba loại bộ xử lý — bảng phải thuộc: | Loại | Mạnh ở | Dùng khi | |---|---|---| | CPU | ⚠ đa năng, tuần tự | ⚠ tiền xử lý, mô hình nhỏ | | ⚠ GPU | ⚠ song song, LINH HOẠT | ⚠ hầu hết bài toán ML | | ⚠ TPU | ⚠ nhân ma trận, Google thiết kế | ⚠ mô hình RẤT lớn |

Từ khoá nhận diện:

"bộ tăng tốc AI chuyên dụng" → ⚠ TPU và GPU "chip do Google thiết kế" → ⚠ TPU "kiến trúc mức hệ thống, quy mô cực lớn" → ⚠ AI Hypercomputer "nền tảng quản vòng đời ML" → Vertex AI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mức sử dụng bộ tăng tốc bao nhiêu | ⚠ thấp thì đừng mua thêm chip | | Chi phí một lần huấn luyện | ⚠ so cả hai loại chip | | Có checkpoint chưa | ⚠ bắt buộc với Spot |

Và con số đáng nhìn trước khi quyết định nâng cấp phần cứng huấn luyện: mức sử dụng bộ tăng tốc hiện tại. Nếu nó đang ở mức thấp, thì nút thắt nằm ở đường ống dữ liệu — và mua chip mạnh hơn chỉ làm phần đang nhàn rỗi trở nên đắt hơn.

Đáp án

C — Vertex AI Search (với năng lực Retail Search).

Vì sao đúng

Đề cần tìm kiếm hiểu Ý ĐỊNH từ câu mô tả tự nhiên, trên danh mục sản phẩm của chính công ty, cho kết quả liên quan và đa dạng. Đó là Vertex AI Search cho bán lẻ.

⚠ Vì sao tìm theo từ khoá không đủ:

Khách gõ: "áo khoác ấm, chống nước,
đi leo núi trời lạnh, không quá cồng kềnh"
        ↓
    ⚠ Tìm theo TỪ KHOÁ
    → ⚠ không sản phẩm nào chứa
      đúng cụm từ đó
    → ⚠ kết quả rỗng
        ↓
    ⚠ Tìm theo NGỮ NGHĨA
    → ⚠ hiểu: áo khoác + giữ nhiệt
      + chống thấm + trọng lượng nhẹ
      + dùng ngoài trời
    → ⚠ ra đúng sản phẩm phù hợp

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

"Google Search công khai"
    → ⚠ tìm trên WEB, không phải
      trên catalogue của bạn

"Cloud Translation API"
    → ⚠ dịch ngôn ngữ

"BigQuery"
    → ⚠ lưu và truy vấn SQL;
      ⚠ `LIKE` không phải tìm kiếm
      ngữ nghĩa

⚠ Gần trùng với #13863 (lô 145) — đề đó cũng là thương mại điện tử cần tìm kiếm và gợi ý nâng cao, cùng khoá Vertex AI Search. Hoàn toàn nhất quán.

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

• D (BigQuery) — phương án gần nhất vì catalogue thường nằm trong BigQuery và nó có cả vector search. Nhưng nó là lớp dữ liệu, không phải giải pháp tìm kiếm đóng gói cho bán lẻ.

• A và B — sai nguồn và sai mục đích.

Ghi nhớ

⚠ Tìm kiếm — ba mức, bảng nên thuộc: | Mức | Cách hoạt động | |---|---| | Từ khoá | ⚠ khớp chuỗi — chính xác với mã sản phẩm | | ⚠ Ngữ nghĩa | ⚠ embedding + vector search — hiểu ý định | | ⚠ Hybrid | ⚠ kết hợp cả hai — thường tốt nhất | | Đóng gói sẵn | ⚠ Vertex AI Search |

Từ khoá nhận diện:

"câu mô tả tự nhiên, hiểu ý định" → ⚠ tìm kiếm ngữ nghĩa / Vertex AI Search "agent hội thoại có công cụ" → Agent Builder "tài liệu nội bộ cho nhân viên" → ⚠ Gemini Enterprise "tin tức công khai" → Grounding with Google Search

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu % tìm kiếm không ra gì | ⚠ đo trước và sau | | Thử bằng ngôn ngữ khách thật dùng | ⚠ không phải thuật ngữ nội bộ | | Mô tả sản phẩm có đủ chi tiết không | ⚠ quyết định chất lượng nhiều nhất |

Và trước khi đầu tư vào công cụ tìm kiếm thông minh hơn, việc đáng làm là đọc danh sách những truy vấn đang trả về không kết quả. Rất thường xuyên, vấn đề không nằm ở thuật toán mà ở chỗ mô tả sản phẩm chưa hề nhắc tới những từ mà khách hàng thật sự dùng.

Đáp án

B — ReAct (Reason and Act) prompting.

Vì sao đúng

Đề mô tả đúng chu trình ReAct: agent SUY LUẬN để chia nhỏ nhiệm vụ, rồi HÀNH ĐỘNG bằng cách gọi công cụ, lặp lại, rồi tổng hợp câu trả lời.

⚠ Chu trình ReAct:

⚠ THOUGHT (suy luận)
    → "cần tìm thời tiết Paris và
       thủ đô nước Pháp"
        ↓
⚠ ACTION (hành động)
    → gọi API thời tiết
        ↓
⚠ OBSERVATION (quan sát)
    → nhận kết quả
        ↓
⚠ THOUGHT tiếp
    → "còn cần thủ đô"
        ↓
⚠ ACTION
    → tra kho tri thức
        ↓
    ⚠ Lặp cho tới khi đủ
        ↓
    Tổng hợp câu trả lời

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

"Chain-of-Thought"
    → ⚠ CHỈ suy luận trong đầu,
      ⚠ KHÔNG gọi công cụ ra ngoài

"Few-shot"
    → ⚠ đưa ví dụ mẫu

"Metaprompting"
    → ⚠ dùng mô hình để sinh/cải
      thiện prompt — chuyện khác

⚠ Đối chiếu #13905 (cùng lô) — đề đó khoá Chain-of-Thought vì chỉ có các bước suy luận, không có công cụ nào. Đề này có gọi API và tra kho tri thức nên là ReAct. Không mâu thuẫn — dấu hiệu phân biệt là có hành động ra bên ngoài hay không.

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

• A (Chain-of-Thought) — phương án gần nhất và là bẫy chính: ReAct có bao gồm phần suy luận kiểu CoT. Nhưng điểm làm nên ReAct là vòng lặp suy luận ↔ hành động với công cụ bên ngoài.

• C và D — không mô tả cơ chế này.

Ghi nhớ

⚠ Kỹ thuật prompt — phân biệt bằng dấu hiệu: | Kỹ thuật | Dấu hiệu | |---|---| | Zero-shot | ⚠ không ví dụ | | Few-shot | ⚠ có ví dụ mẫu | | ⚠ Chain-of-Thought | ⚠ các bước suy luận, KHÔNG có công cụ | | ⚠ ReAct | ⚠ suy luận + GỌI CÔNG CỤ, lặp lại | | Role prompting | ⚠ "bạn là..." | | Prompt chaining | ⚠ nhiều lời gọi nối tiếp do NGƯỜI thiết kế |

Từ khoá nhận diện:

"suy luận rồi gọi công cụ, lặp lại" → ⚠ ReAct "trình bày từng bước suy luận" → Chain-of-Thought "gán vai" → role prompting "đưa ví dụ" → few-shot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có giới hạn số vòng lặp chưa | ⚠ thiếu là chi phí có thể bùng | | Vết suy luận có được ghi lại không | ⚠ cần để gỡ lỗi | | Công cụ ghi có xác nhận không | ⚠ bắt buộc |

Và giá trị phụ ít được nhắc tới của ReAct: nó để lại một vết suy luận đọc được. Khi agent trả lời sai, bạn nhìn thấy chính xác nó đã nghĩ gì và gọi công cụ nào — điều mà một câu trả lời sinh thẳng không bao giờ cho biết.

Đáp án

D — Identity and Access Management (IAM).

Vì sao đúng

Yêu cầu là chỉ nhân sự và dịch vụ ĐƯỢC PHÉP mới truy cập được mô hình AI, kho dữ liệu và tài nguyên tính toán. Quản lý và thực thi quyền truy cập là việc của IAM.

⚠ IAM kiểm soát gì trong ứng dụng AI:

⚠ AI QUAN gọi được mô hình
    → `aiplatform.endpoints.predict`

⚠ AI đọc được dữ liệu huấn luyện
    → quyền trên bucket, bảng BigQuery

⚠ AI triển khai được mô hình mới
    → quyền trên Model Registry

⚠ SERVICE ACCOUNT nào chạy job
    → ⚠ danh tính cho MÁY

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

"Security Command Center"
    → ⚠ PHÁT HIỆN cấu hình sai và
      mối đe doạ — quan trọng, nhưng
      không CẤP hay THỰC THI quyền

"Cloud Armor"
    → ⚠ chống DDoS và tấn công web
      ở tầng mạng

"Cloud IDS"
    → ⚠ phát hiện xâm nhập trong mạng

⚠ Cả ba đều là công cụ bảo mật thật, nhưng chỉ IAM quyết định AI ĐƯỢC LÀM GÌ.

Nhất quán với #13537 (lô 144) về authorization và #13563 (lô 144) về least privilege. Cùng một hệ khái niệm.

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

• A (Security Command Center) — phương án gần nhất vì cũng là công cụ bảo mật trung tâm và có thể cảnh báo khi quyền bị cấu hình sai. Nhưng nó phát hiện, không cấp và thực thi quyền.

• C và B — bảo vệ ở tầng mạng.

Ghi nhớ

⚠ Công cụ bảo mật — mỗi cái một việc, bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ IAM | ⚠ AI được làm gì — cấp và thực thi quyền | | ⚠ Security Command Center | ⚠ phát hiện cấu hình sai, mối đe doạ | | Cloud Armor | ⚠ WAF, chống DDoS | | VPC Service Controls | ⚠ ngăn dữ liệu rời ranh giới | | Cloud KMS / CMEK | ⚠ quản khoá mã hoá | | Sensitive Data Protection | ⚠ phát hiện và che PII | | Audit Logs | ⚠ ghi lại ai đã làm gì |

Từ khoá nhận diện:

"chỉ người được phép mới truy cập" → ⚠ IAM "phát hiện cấu hình sai" → Security Command Center "chặn tấn công web, DDoS" → Cloud Armor "dữ liệu không được ra khỏi phạm vi" → ⚠ VPC Service Controls

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Service account của ứng dụng có quyền gì | ⚠ liệt kê và siết | | Endpoint có công khai không | ⚠ mặc định nên là không | | Còn khoá tĩnh nào không | ⚠ thay bằng Workload Identity |

Và điểm yếu IAM hay gặp nhất trong các hệ thống AI không nằm ở tài khoản người dùng, mà ở service account mà ứng dụng dùng để gọi mô hình và đọc dữ liệu. Nó thường được cấp rộng để "cho nó chạy" trong giai đoạn thử nghiệm, rồi giữ nguyên quyền đó khi lên sản xuất.