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

Đáp án

C — Temperature (nhiệt độ).

Vì sao đúng

Temperature điều khiển mức độ ngẫu nhiên khi mô hình chọn từ tiếp theo. Đặt thấp thì đầu ra xác định hơn, tập trung hơn, bám sát nguồn hơn — đúng yêu cầu tóm tắt văn bản pháp lý.

⚠ Temperature làm gì:

Mô hình tính xác suất cho
từ tiếp theo
        ↓
⚠ TEMPERATURE THẤP (gần 0)
    → ⚠ luôn chọn từ có xác suất
      CAO NHẤT
    → ⚠ xác định, nhất quán,
      ít sáng tạo
    → ⚠ ĐÚNG cho tóm tắt pháp lý,
      trích xuất dữ liệu, phân loại

⚠ TEMPERATURE CAO
    → ⚠ cho phép chọn từ ít khả
      năng hơn
    → ⚠ đa dạng, sáng tạo,
      ⚠ và dễ lệch khỏi nguồn
    → hợp cho brainstorm, viết
      quảng cáo

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

"Output length"
    → ⚠ giới hạn ĐỘ DÀI, không
      ảnh hưởng tính xác định

"Token count for input"
    → ⚠ độ dài đầu vào

"Number of beams"
    → ⚠ tham số của beam search,
      không phải tham số lấy mẫu
      chính được hỏi ở đây

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

• D (số beam) — phương án gần nhất vì cũng là một tham số ảnh hưởng tới cách sinh văn bản, nhưng tham số chuẩn để điều chỉnh tính ngẫu nhiên trong các mô hình sinh hiện nay là temperature.

• A (độ dài đầu ra) và B (số token đầu vào) — kiểm soát kích thước, không kiểm soát tính xác định.

Ghi nhớ

⚠ Tham số sinh văn bản — bảng phải thuộc: | Tham số | Điều khiển gì | |---|---| | ⚠ Temperature | ⚠ mức NGẪU NHIÊN — thấp = xác định | | ⚠ Top-K | ⚠ chỉ chọn trong K từ khả năng nhất | | ⚠ Top-P (nucleus) | ⚠ chọn trong nhóm từ có tổng xác suất P | | Max output tokens | ⚠ độ dài tối đa | | Stop sequences | ⚠ dừng khi gặp chuỗi này |

Từ khoá nhận diện:

"chính xác, bám sát nguồn, nhất quán" → ⚠ temperature THẤP "sáng tạo, đa dạng, nhiều phương án" → ⚠ temperature CAO "giới hạn độ dài" → max output tokens "chỉ dùng thông tin trong tài liệu" → ⚠ grounding + chỉ dẫn rõ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cùng đầu vào có ra kết quả ổn định không | ⚠ chạy vài lần rồi so | | Tóm tắt có bịa chi tiết nào không | ⚠ đối chiếu với văn bản gốc | | Có trích dẫn được nguồn không | ⚠ bắt buộc với tài liệu pháp lý |

Và điều dễ hiểu nhầm nhất về tham số này: hạ temperature làm mô hình bớt sáng tạo, chứ không làm nó chính xác hơn. Một mô hình không có tài liệu nguồn vẫn sẽ bịa ở nhiệt độ bằng không — chỉ là lần nào nó cũng bịa giống nhau.

Đáp án

A — Speech-to-Text API, Natural Language API và Text-to-Speech API.

Vì sao đúng

Đề nêu ba chức năng lõi, và mỗi chức năng ứng với đúng một API trong bộ ba này.

⚠ Chuỗi xử lý đầy đủ:

🎤 Khách NÓI
        ↓
    ⚠ SPEECH-TO-TEXT
    → âm thanh thành văn bản
        ↓
    ⚠ NATURAL LANGUAGE
    → ⚠ phân tích CẢM XÚC
    → hiểu ý định, thực thể
        ↓
    Xử lý yêu cầu, soạn câu trả lời
    (⚠ điều chỉnh giọng điệu theo
     cảm xúc đo được)
        ↓
    ⚠ TEXT-TO-SPEECH
    → văn bản thành giọng nói
        ↓
🔊 Agent TRẢ LỜI bằng giọng

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

"Translation API và Document AI"
    → ⚠ dịch và trích trường tài liệu

"Vertex AI Search và Cloud Functions"
    → ⚠ hữu ích để tra dữ liệu và
      chạy logic, nhưng ⚠ KHÔNG xử lý
      giọng nói

"Vision API và Video Intelligence"
    → ⚠ xử lý ẢNH và VIDEO

Nhất quán với #13541 (lô 144) — cùng nguyên tắc Speech-to-Text là bước đầu tiên cho đầu vào âm thanh. Đề này hỏi cả chuỗi ba API.

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

• C (Vertex AI Search và Cloud Functions) — phương án gần nhất vì cả hai thật sự cần trong một agent hoàn chỉnh: tra thông tin và chạy logic. Nhưng chúng không giải quyết được ba chức năng lõi mà đề nêu, vốn đều liên quan tới giọng nói.

• B và D — sai loại dữ liệu đầu vào.

Ghi nhớ

⚠ Chọn API theo LOẠI DỮ LIỆU — bảng phải thuộc: | Đầu vào → đầu ra | API | |---|---| | ⚠ Âm thanh → chữ | ⚠ Speech-to-Text | | ⚠ Chữ → âm thanh | ⚠ Text-to-Speech | | ⚠ Chữ → cảm xúc, thực thể | ⚠ Natural Language | | Chữ → ngôn ngữ khác | Translation | | Ảnh → nhãn, chữ | Vision | | Tài liệu → trường dữ liệu | ⚠ Document AI |

Từ khoá nhận diện:

"agent nghe và nói" → ⚠ bộ ba STT + NL + TTS "phân tích cảm xúc VĂN BẢN" → Natural Language "cảm xúc trên KHUÔN MẶT" → ⚠ Vision API — khác hẳn "tổng đài hoàn chỉnh" → ⚠ CCAI / Customer Engagement Suite

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ toàn chuỗi bao lâu | ⚠ đo từ lúc khách dứt lời tới lúc nghe trả lời | | Nhận dạng đúng bao nhiêu phần trăm | ⚠ thử bằng bản ghi thật có tiếng ồn | | Agent có xác nhận trước hành động quan trọng không | ⚠ bắt buộc |

Và yếu tố quyết định trải nghiệm của một agent giọng nói thường không phải chất lượng câu trả lời mà là độ trễ. Một câu trả lời hoàn hảo đến sau bốn giây im lặng vẫn khiến người gọi nghĩ rằng cuộc gọi đã rớt.

Đáp án

C — Application (ứng dụng).

Vì sao đúng

Ứng dụng di động này là thứ người dùng cuối trực tiếp tương tác — nó sử dụng mô hình và nền tảng bên dưới chứ không phải là chúng.

⚠ Bốn tầng của bối cảnh AI sinh:

⚠ INFRASTRUCTURE (hạ tầng)
    → ⚠ TPU, GPU, trung tâm dữ liệu,
      mạng

⚠ MODEL (mô hình)
    → ⚠ Gemini, Imagen, Veo, Gemma
    → bản thân mô hình nền

⚠ PLATFORM (nền tảng)
    → ⚠ Vertex AI, Agent Builder
    → ⚠ công cụ để XÂY và VẬN HÀNH

⚠ APPLICATION (ứng dụng)
    → ⚠ thứ NGƯỜI DÙNG CUỐI dùng
    → ⚠ ứng dụng thiết kế nội thất
      trong đề này
    → ⚠ ĐÁP ÁN

⚠ Cách phân biệt nhanh:

Hỏi: "AI DÙNG cái này để làm gì?"
        ↓
    Chạy phép tính → HẠ TẦNG
    Sinh nội dung  → MÔ HÌNH
    Xây và quản    → NỀN TẢNG
    ⚠ Người dùng cuối bấm vào
      → ⚠ ỨNG DỤNG

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

• A (Model) — phương án gần nhất vì ứng dụng này có dùng một mô hình sinh ảnh bên trong. Nhưng mô hình là thành phần, còn ứng dụng là sản phẩm mà người dùng trải nghiệm.

• B (Platform) — là công cụ để lập trình viên xây ứng dụng.

• D (Infrastructure) — phần cứng bên dưới.

Ghi nhớ

⚠ Bốn tầng và ví dụ — bảng phải thuộc: | Tầng | Ví dụ Google | Ai dùng | |---|---|---| | Infrastructure | ⚠ TPU, GPU | vận hành nền tảng | | ⚠ Model | ⚠ Gemini, Imagen, Veo, Gemma | lập trình viên gọi API | | ⚠ Platform | ⚠ Vertex AI, Agent Builder, AI Studio | ⚠ đội xây sản phẩm | | ⚠ Application | ⚠ ứng dụng Gemini, Workspace có AI, app của bạn | ⚠ NGƯỜI DÙNG CUỐI |

Từ khoá nhận diện:

"người dùng cuối tương tác trực tiếp" → ⚠ application "công cụ để xây và triển khai" → ⚠ platform "bản thân mô hình nền" → model "TPU, GPU, trung tâm dữ liệu" → infrastructure

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Chi phí mỗi lượt dùng là bao nhiêu | ⚠ so với doanh thu mỗi người dùng | | Kết quả tệ thì người dùng làm gì | ⚠ phải có đường thử lại | | Ảnh người dùng tải lên lưu ở đâu | ⚠ và lưu bao lâu |

Và điều phân biệt các ứng dụng AI sinh với nhau ngày càng ít nằm ở mô hình đứng sau: cùng một mô hình đó ai cũng gọi được. Thứ không sao chép được là dữ liệu riêng mà bạn dùng để grounding, và mức độ hiểu bài toán của người dùng thể hiện trong thiết kế trải nghiệm.

Đáp án

B — Accountability và Explainability (trách nhiệm giải trình và khả năng giải thích).

Vì sao đúng

Khách hàng bị từ chối yêu cầu một lý do rõ ràng. Điều đó đòi hai thứ: hệ thống giải thích được cơ sở của quyết định, và ngân hàng chịu trách nhiệm về quyết định đó.

⚠ Hai nguyên tắc khớp:

⚠ EXPLAINABILITY
    → ⚠ hiểu được VÌ SAO mô hình
      ra quyết định đó
    → yếu tố nào đóng góp bao nhiêu

⚠ ACCOUNTABILITY
    → ⚠ CÓ NGƯỜI chịu trách nhiệm
      về quyết định
    → ⚠ "hệ thống quyết vậy" KHÔNG
      phải câu trả lời chấp nhận được

⚠ Vì sao ngành tài chính đặc biệt khắt khe:

Từ chối cho vay
        ↓
    ⚠ Nhiều nơi LUẬT buộc nêu lý do
    ⚠ Khách có quyền khiếu nại
    ⚠ Cơ quan quản lý có thể kiểm tra
        ↓
    ⚠ Mô hình "hộp đen" KHÔNG
      dùng được ở đây

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

"Privacy and Security"
    → ⚠ quan trọng, nhưng đề hỏi về
      GIẢI THÍCH quyết định

"Reliability and Scalability"
    → ⚠ thuộc vận hành kỹ thuật

"Bias and Fairness"
    → ⚠ RẤT liên quan tới cho vay,
      nhưng đề hỏi về việc GIẢI THÍCH
      một quyết định cụ thể

⚠ Gần trùng với #13884 (cùng lô) — đề đó khoá "Transparency (and Explainability)". Hai đề có bộ phương án khác nhau và cả hai đều xoay quanh explainability. Không mâu thuẫn — chỉ khác cách ghép cặp nguyên tắc trong từng bộ đáp án.

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

• D (Bias and Fairness) — phương án gần nhất và là bẫy mạnh: cho vay đúng là lĩnh vực có rủi ro thiên vị cao. Nhưng đề hỏi về việc giải thích được một quyết định, không phải về việc đối xử công bằng giữa các nhóm.

• A và C — thuộc nhóm nguyên tắc khác.

Ghi nhớ

⚠ Nguyên tắc AI có trách nhiệm — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Explainability | ⚠ hiểu được VÌ SAO ra kết quả đó | | ⚠ Accountability | ⚠ CÓ NGƯỜI chịu trách nhiệm | | ⚠ Transparency | ⚠ công khai cách hệ thống hoạt động | | ⚠ Fairness | ⚠ không thiên vị giữa các nhóm | | Privacy | bảo vệ dữ liệu cá nhân | | Safety / Security | an toàn, chống lạm dụng | | Reliability | hoạt động ổn định |

Từ khoá nhận diện:

"giải thích lý do quyết định" → ⚠ explainability "ai chịu trách nhiệm" → ⚠ accountability "công khai cách hoạt động" → ⚠ transparency "đối xử khác nhau giữa các nhóm" → fairness / bias

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có nêu được lý do bằng một câu không | ⚠ thử viết ra thật | | Ai ký vào quyết định | ⚠ phải rõ trước khi chạy | | Có ghi lại đủ để giải trình sau không | ⚠ cơ quan quản lý có thể hỏi lại |

Và nguyên tắc thực dụng nhất khi đưa AI vào các quyết định ảnh hưởng tới con người: để mô hình hỗ trợ, để người quyết định và chịu trách nhiệm. Một hệ thống không giải thích được thì không nên là thứ nói lời cuối cùng với khách hàng.

Đáp án

C — Imagen.

Vì sao đúng

Imagen là mô hình nền của Google chuyên cho sinh ảnh từ văn bản — cả ảnh chân thực lẫn ảnh nghệ thuật, có kiểm soát về phong cách và bố cục.

⚠ Chọn mô hình theo modality:

"tạo ẢNH từ mô tả văn bản"
        ↓
    ⚠ text-to-image
        ↓
    → ⚠ IMAGEN

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

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

"Veo"
    → ⚠ sinh VIDEO

"Gemma"
    → ⚠ mô hình MỞ, NHẸ, chủ yếu
      cho văn bản

Nhất quán với #13864 (cùng lô) — đề đó hỏi kiến trúc (diffusion model), đề này hỏi sản phẩm cụ thể (Imagen). Bổ sung nhau. Và #13856 (cùng lô) về việc modality là tiêu chí lọc đầu tiên.

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

• A (Gemini) — phương án gần nhất và là bẫy chính: Gemini là mô hình nổi tiếng nhất của Google và hiểu được ảnh. Nhưng hiểu ảnh khác với sinh ảnh chất lượng cao từ mô tả.

• D (Veo) — sinh video.

• B (Gemma) — mô hình mở, nhẹ, cho văn bản.

Ghi nhớ

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

Từ khoá nhận diện:

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

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chất lượng đủ đăng chưa | ⚠ thử với brief thật của khách hàng | | Có được dùng thương mại không | ⚠ kiểm giấy phép trước khi cam kết | | Ai duyệt trước khi phát hành | ⚠ cần quy trình rõ |

Và với chiến dịch quảng cáo, việc đáng làm ngay từ đầu là thoả thuận với khách hàng về việc có dùng ảnh do AI tạo hay không, và có công bố điều đó hay không. Đó là cuộc trò chuyện dễ chịu ở đầu dự án và rất khó chịu nếu để tới sau khi chiến dịch đã chạy.

Đáp án

D — Extensions hoặc Functions (để gọi API bên ngoài).

Vì sao đúng

Bản thân mô hình ngôn ngữ chỉ sinh ra văn bản. Muốn agent tra chuyến bay thật và đặt phòng thật, nó phải gọi được API bên ngoài — đó là vai trò của extensions / function calling.

⚠ Function calling hoạt động ra sao:

Người dùng: "tìm chuyến bay
Hà Nội → Tokyo ngày 20"
        ↓
    ⚠ Mô hình nhận ra cần GỌI
      công cụ tìm chuyến bay
        ↓
    ⚠ Sinh ra LỜI GỌI có cấu trúc:
      {ten: "timChuyenBay",
       diem_di: "HAN", diem_den: "NRT",
       ngay: "2026-09-20"}
        ↓
    ⚠ Ứng dụng THẬT SỰ gọi API
        ↓
    ⚠ Kết quả trả lại cho mô hình
        ↓
    Mô hình diễn đạt thành câu
      trả lời tự nhiên

⚠ Điểm quan trọng: mô hình không tự gọi API — nó đề xuất lời gọi, ứng dụng của bạn mới thực hiện. Đó chính là chỗ bạn đặt kiểm soát.

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

"Internal data stores"
    → ⚠ dùng cho GROUNDING vào
      tài liệu nội bộ; không phải
      cách gọi API và THỰC HIỆN
      giao dịch

"Prompt engineering templates"
    → ⚠ mẫu câu lệnh

"Core model fine-tuning"
    → ⚠ huấn luyện thêm mô hình

Nhất quán với #13858 (cùng lô) — Agent Builder là nơi dựng agent, còn extensions/functions là cơ chế cho agent hành động.

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

• C (internal data stores) — phương án gần nhất và là bẫy chính: đó cũng là cách agent lấy thông tin. Nhưng kho dữ liệu phục vụ grounding để ĐỌC, còn đề cần gọi hệ thống ngoài để TRA và ĐẶT — tức là hành động.

• A và B — không phải cơ chế kết nối hệ thống ngoài.

Ghi nhớ

⚠ Ba cách agent lấy/dùng thông tin — bảng phải thuộc: | Cách | Dùng khi | |---|---| | ⚠ Grounding / data store | ⚠ ĐỌC tài liệu, chính sách nội bộ | | ⚠ Function calling / extensions | ⚠ GỌI API, thực hiện HÀNH ĐỘNG | | Kiến thức sẵn của mô hình | ⚠ kiến thức chung, có knowledge cutoff |

Từ khoá nhận diện:

"gọi API bên ngoài, đặt chỗ, giao dịch" → ⚠ function calling / extensions "tra tài liệu nội bộ" → ⚠ grounding / data store "dựng agent doanh nghiệp" → Agent Builder "nhiều bước nối tiếp" → ⚠ prompt chaining / agent orchestration

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent gọi được hàm nào | ⚠ liệt kê và siết quyền từng cái | | Có bị lừa gọi sai hàm không | ⚠ thử tấn công prompt injection | | Hành động quan trọng có xác nhận không | ⚠ bắt buộc |

Và ranh giới thiết kế quan trọng nhất của mọi agent có công cụ: phân biệt hàm chỉ đọc với hàm gây thay đổi. Nhóm thứ nhất có thể để agent tự do dùng; nhóm thứ hai nên luôn đi qua một bước xác nhận, vì một lời gọi sai ở đó không sửa lại được bằng câu xin lỗi.

Đáp án

B — Theo dõi hiệu năng liên tục và giám sát drift.

Vì sao đúng

Chất lượng gợi ý giảm dần theo thời gian vì sở thích khách hàng và danh mục sản phẩm đã thay đổi so với lúc huấn luyện. Đó chính là drift, và cách phát hiện là giám sát liên tục.

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

Mô hình học từ dữ liệu tại
THỜI ĐIỂM T
        ↓
    ⚠ Sở thích khách đổi theo mùa,
      theo xu hướng
    ⚠ Sản phẩm mới ra, sản phẩm cũ
      ngừng bán
        ↓
    ⚠ Dữ liệu THẬT ngày càng KHÁC
      dữ liệu huấn luyện
        ↓
    ⚠ Mô hình không sai đi, nhưng
      THẾ GIỚI đã đổi
        ↓
    → chất lượng giảm DẦN, âm thầm

⚠ Hai loại drift phải phân biệt:

⚠ DATA DRIFT
    → ⚠ phân phối ĐẦU VÀO đổi
    → ví dụ: nhóm khách hàng mới

⚠ CONCEPT DRIFT
    → ⚠ QUAN HỆ giữa đầu vào và
      kết quả đổi
    → ví dụ: hành vi mua thay đổi
      sau đại dịch

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

"Chỉ dựa vào nâng cấp mô hình tự
 động của nhà cung cấp"
    → ⚠ không giải quyết drift của
      DỮ LIỆU RIÊNG của bạn

"Lưu TOÀN BỘ dữ liệu huấn luyện
 vĩnh viễn trong Feature Store"
    → ⚠ lưu trữ không PHÁT HIỆN
      được suy giảm

"Đánh phiên bản nghiêm ngặt cho
 mọi lần triển khai"
    → ⚠ thực hành TỐT, giúp quay lui,
      nhưng KHÔNG phát hiện drift

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

• D (đánh phiên bản nghiêm ngặt) — phương án gần nhất vì đó là một thực hành MLOps thật sự tốt và cần thiết để quay lui. Nhưng nó không phát hiện được việc chất lượng đang giảm.

• A và C — không giải quyết vấn đề.

Ghi nhớ

⚠ Vòng đời MLOps sau khi triển khai — bảng phải thuộc: | Việc | Nội dung | |---|---| | ⚠ Giám sát hiệu năng | ⚠ chỉ số nghiệp vụ: tỉ lệ click, chuyển đổi | | ⚠ Giám sát drift | ⚠ so phân phối dữ liệu hiện tại với lúc huấn luyện | | ⚠ Giám sát skew | ⚠ dữ liệu phục vụ khác dữ liệu huấn luyện | | Huấn luyện lại | ⚠ theo lịch hoặc khi drift vượt ngưỡng | | Đánh phiên bản, quay lui | ⚠ Model Registry | | A/B test phiên bản mới | ⚠ đừng thay thẳng |

Từ khoá nhận diện:

"chất lượng giảm dần theo thời gian" → ⚠ drift → giám sát liên tục "dữ liệu phục vụ khác dữ liệu huấn luyện" → ⚠ training-serving skew "quản phiên bản mô hình" → Model Registry "tự động hoá huấn luyện lại" → ⚠ Vertex AI Pipelines

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ai biết khi mô hình xuống cấp | ⚠ không ai → chưa có giám sát | | Lần huấn luyện gần nhất là bao giờ | ⚠ hệ gợi ý cũ rất nhanh | | Có quay lui được không | ⚠ cần Model Registry |

Và điểm khác biệt lớn nhất giữa một mô hình học máy và một đoạn mã thông thường: mã không tự hỏng theo thời gian, còn mô hình thì có. Nó không hề thay đổi — chỉ là thế giới quanh nó đã đổi, và đó là lý do giám sát sau triển khai không phải việc tuỳ chọn.

Đáp án

C — Gemini for Google Workspace.

Vì sao đúng

Nhân viên muốn tự động hoá việc NGAY TRONG công cụ đang dùng — tóm tắt bản ghi Google Meet và soạn thư trong Gmail. Đó là định vị của Gemini for Workspace.

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

Dùng ứng dụng AI riêng
        ↓
    ⚠ phải COPY bản ghi ra
    ⚠ dán vào chỗ khác
    ⚠ copy kết quả quay lại
    ⚠ và ⚠ dữ liệu công ty đi ra ngoài
        ↓
⚠ GEMINI FOR WORKSPACE
    → ⚠ ngay trong Gmail, Docs, Meet
    → ⚠ đã có ngữ cảnh của tài liệu
    → ⚠ tôn trọng quyền truy cập sẵn có
    → ⚠ dữ liệu KHÔNG rời khỏi
      ranh giới Workspace

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

"Ứng dụng Gemini độc lập"
    → ⚠ trợ lý tốt, nhưng NGOÀI
      luồng làm việc; phải copy-paste

"NotebookLM"
    → ⚠ nghiên cứu và tổng hợp trên
      bộ tài liệu bạn nạp vào —
      không tích hợp Gmail/Meet

"Vertex AI Search"
    → ⚠ tìm kiếm doanh nghiệp

Đối chiếu #13865 (cùng lô) — đề đó khoá ứng dụng Gemini và Gems cho trợ lý cá nhân tuỳ biến. Đề này khoá Gemini for Workspace vì yêu cầu là ngay trong Gmail và Meet. Không mâu thuẫn — khác nơi công việc diễn ra.

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

• D (ứng dụng Gemini độc lập) — phương án gần nhất và là bẫy chính: nó làm được cả hai việc về mặt kỹ thuật. Nhưng đề nhấn mạnh "trực tiếp trong công cụ Workspace sẵn có".

• A (NotebookLM) và B (Vertex AI Search) — phục vụ mục đích khác.

Ghi nhớ

⚠ Gemini xuất hiện ở đâu — bảng phải thuộc: | Nơi | Dùng khi | |---|---| | ⚠ Gemini for Workspace | ⚠ ngay trong Gmail, Docs, Meet, Sheets | | ⚠ Ứng dụng Gemini (+ Gems) | ⚠ trợ lý cá nhân, tuỳ biến việc lặp lại | | ⚠ NotebookLM | ⚠ nghiên cứu trên bộ tài liệu bạn nạp | | Gemini Code Assist | lập trình viên | | Vertex AI / Gemini API | ⚠ xây ứng dụng riêng |

Từ khoá nhận diện:

"ngay trong Gmail, Docs, Meet" → ⚠ Gemini for Workspace "trợ lý cá nhân, tuỳ biến" → ứng dụng Gemini + Gems "nạp tài liệu để nghiên cứu sâu" → ⚠ NotebookLM "tìm kiếm doanh nghiệp" → Vertex AI Search

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyền tài liệu đã rà chưa | ⚠ làm TRƯỚC khi bật | | Tóm tắt có ghi đúng việc cần làm không | ⚠ kiểm vài cuộc họp thật | | Có chính sách về lưu bản ghi không | ⚠ dữ liệu nhạy cảm |

Và giá trị thật của việc tích hợp AI ngay trong công cụ làm việc thường không nằm ở năng lực mô hình, mà ở chỗ nó xoá bỏ bước copy-paste. Bước đó nhỏ nhưng đủ để phần lớn người dùng bỏ cuộc — và nó cũng chính là bước đưa dữ liệu công ty ra khỏi ranh giới kiểm soát.

Đáp án

B — Transparency (và Explainability) — tính minh bạch và khả năng giải thích.

Vì sao đúng

Đề nhấn mạnh việc làm cho quá trình lập luận của AI trở nên rõ ràng với các bên liên quan. Đó chính là minh bạch, đi kèm với khả năng giải thích.

⚠ Vì sao khu vực công đặc biệt cần:

Phân bổ nguồn lực công
        ↓
    ⚠ Ảnh hưởng trực tiếp tới
      người dân
    ⚠ Tiền thuế — phải giải trình
    ⚠ Rủi ro thiên vị theo khu vực,
      theo nhóm dân cư
        ↓
    ⚠ Người dân phải HIỂU được
      vì sao quyết định như vậy
        ↓
    ⚠ Không minh bạch = không có
      niềm tin = không áp dụng được

⚠ Minh bạch gồm những gì:

⚠ CÔNG KHAI rằng có dùng AI
⚠ NÓI RÕ AI dùng dữ liệu gì
⚠ GIẢI THÍCH được cơ sở quyết định
⚠ NÊU rõ giới hạn của hệ thống
⚠ CÓ kênh khiếu nại

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

"Privacy"
    → ⚠ rất quan trọng với dữ liệu
      nhân khẩu, nhưng đề hỏi về
      việc LÀM RÕ lập luận

"Security" → ⚠ chống truy cập trái phép
"Reliability" → ⚠ hoạt động ổn định

⚠ Gần trùng với #13879 (cùng lô) — đề đó khoá "Accountability and Explainability" cho tình huống từ chối hồ sơ vay. Hai đề có bộ phương án khác nhau, và cả hai đều xoay quanh explainability. Không mâu thuẫn — mỗi bộ đáp án ghép explainability với một nguyên tắc khác.

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

• A (Privacy) — phương án gần nhất vì đề có nhắc tới dữ liệu nhân khẩu, vốn là dữ liệu nhạy cảm. Nhưng câu hỏi hỏi về việc làm rõ quá trình lập luận, không phải bảo vệ dữ liệu.

• C (Security) và D (Reliability) — thuộc nhóm khác.

Ghi nhớ

⚠ Nguyên tắc AI có trách nhiệm — bảng phải thuộc: | Nguyên tắc | Câu hỏi nó trả lời | |---|---| | ⚠ Transparency | ⚠ "hệ thống hoạt động thế nào?" | | ⚠ Explainability | ⚠ "vì sao ra kết quả NÀY?" | | ⚠ Accountability | ⚠ "ai chịu trách nhiệm?" | | ⚠ Fairness | ⚠ "có đối xử công bằng không?" | | Privacy | "dữ liệu có được bảo vệ không?" | | Safety | "có gây hại không?" |

Từ khoá nhận diện:

"làm rõ cách hệ thống hoạt động" → ⚠ transparency "vì sao quyết định như vậy" → ⚠ explainability "ai ký, ai chịu trách nhiệm" → accountability "chênh lệch giữa các nhóm" → fairness

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Giải thích được cho người dân bằng lời thường không | ⚠ thử viết ra một đoạn | | Có đo kết quả theo từng nhóm chưa | ⚠ tổng thể có thể che giấu chênh lệch | | Ai quyết định cuối cùng | ⚠ với nguồn lực công, phải là người |

Và phép thử thực tế nhất cho tính minh bạch của một hệ thống AI trong khu vực công: có viết được một đoạn giải thích cho người dân mà không dùng thuật ngữ kỹ thuật không? Nếu không, thì hệ thống chưa sẵn sàng cho những quyết định ảnh hưởng tới cộng đồng — bất kể độ chính xác của nó cao đến đâu.

Đáp án

C — Text Summarization (tóm tắt văn bản).

Vì sao đúng

Đội marketing có khối lượng lớn văn bản từ khảo sát, mạng xã hội và phiếu hỗ trợ, và cần bản tổng quan ngắn gọn về vấn đề chung và phản hồi tích cực. Đó chính là tóm tắt văn bản.

⚠ Vì sao tóm tắt là câu trả lời:

Hàng nghìn phản hồi rời rạc
        ↓
    ⚠ Người đọc hết là không khả thi
        ↓
    ⚠ TÓM TẮT: rút gọn thành
      các chủ đề chính
    ⚠ kèm phân tích cảm xúc
        ↓
    → ⚠ đọc trong vài phút thay vì
      vài ngày

⚠ Các dạng tóm tắt hữu ích ở đây:

⚠ TÓM TẮT TỪNG PHẢN HỒI
    → phiếu dài thành một câu

⚠ TÓM TẮT THEO CHỦ ĐỀ
    → ⚠ gom nhóm rồi tóm tắt
      từng nhóm

⚠ TÓM TẮT TỔNG HỢP
    → ⚠ báo cáo tuần: ba vấn đề
      nổi bật nhất

⚠ TRÍCH XUẤT CÓ CẤU TRÚC
    → chủ đề, cảm xúc, mức độ
      khẩn cấp thành BẢNG

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

"Code Generation"    → ⚠ sinh mã
"Image Generation"   → ⚠ sinh ảnh
"Personalized User Experience"
    → ⚠ cá nhân hoá trải nghiệm —
      là ỨNG DỤNG khác, không phải
      việc xử lý khối văn bản này

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

• B (trải nghiệm cá nhân hoá) — phương án gần nhất vì cũng là một năng lực AI sinh hữu ích cho marketing, nhưng nó nói về việc tuỳ biến nội dung cho từng khách, không phải rút gọn khối phản hồi.

• A và D — sai modality.

Ghi nhớ

⚠ Năng lực của AI sinh — bảng nên thuộc: | Năng lực | Ví dụ ứng dụng | |---|---| | ⚠ Tóm tắt | ⚠ phản hồi khách, cuộc họp, tài liệu dài | | Sinh nội dung | bài viết, email, mô tả sản phẩm | | ⚠ Trích xuất có cấu trúc | ⚠ biến văn bản tự do thành bảng | | Phân loại | ⚠ gán chủ đề, cảm xúc | | Dịch | | | Hỏi đáp trên tài liệu | ⚠ cần grounding | | Sinh mã, sinh ảnh, sinh video | |

Từ khoá nhận diện:

"rút gọn khối văn bản lớn" → ⚠ tóm tắt "biến văn bản tự do thành bảng" → ⚠ trích xuất có cấu trúc "gom nhóm không biết trước chủ đề" → ⚠ phân cụm / topic modeling "nội dung riêng cho từng khách" → cá nhân hoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tóm tắt có bỏ sót vấn đề quan trọng không | ⚠ đối chiếu thủ công một mẫu | | Có lần được về phản hồi gốc không | ⚠ bắt buộc | | PII có bị che chưa | ⚠ khách hay để lại thông tin cá nhân |

Và điều đáng giữ lại khi tự động hoá việc đọc phản hồi khách hàng: đường dẫn ngược về những phản hồi gốc. Bản tóm tắt cho biết chuyện gì đang xảy ra ở quy mô lớn, nhưng một câu khách hàng viết nguyên văn mới là thứ thuyết phục được người ra quyết định.