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

Đáp án

C — Artificial Intelligence (Trí tuệ nhân tạo).

Vì sao đúng

CEO cần một từ bao trùm cho bốn hệ thống rất khác nhau. Chỉ AI đủ rộng để chứa cả bốn.

⚠ Soi từng hệ thống:

1. Dự đoán khách rời bỏ
    → ⚠ Machine Learning (dự báo)

2. Chatbot viết email marketing
    → ⚠ Generative AI

3. Robot tối ưu xếp kho
    → ⚠ Robotics + tối ưu hoá
    → ⚠ có thể KHÔNG dùng ML

4. Phát hiện giao dịch gian lận
    → ⚠ ML, đôi khi chỉ là LUẬT

⚠ Vòng tròn lồng nhau — phải thuộc:

┌─────────── AI ────────────┐
│  ⚠ RỘNG NHẤT — kể cả hệ  │
│    chuyên gia dựa LUẬT    │
│  ┌────── ML ───────────┐  │
│  │ ⚠ học từ dữ liệu    │  │
│  │ ┌─ Deep Learning ─┐ │  │
│  │ │ ⚠ mạng nơ-ron   │ │  │
│  │ │ ┌─ Gen AI ────┐ │ │  │
│  │ │ │ ⚠ SINH nội  │ │ │  │
│  │ │ │   dung mới  │ │ │  │
│  │ │ └─────────────┘ │ │  │
│  │ └─────────────────┘ │  │
│  └─────────────────────┘  │
└───────────────────────────┘

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

• D (Machine Learning) — phương án gần nhất và là bẫy mạnh nhất: ba trong bốn hệ thống có thể là ML. Nhưng ⚠ robot tối ưu xếp kho có thể chạy bằng thuật toán tối ưu hoặc luật, không học từ dữ liệu — khi đó nó là AI mà không phải ML. Từ "comprehensive" trong đề đòi cái rộng hơn.

• B (Generative AI) — ⚠ hẹp nhất, chỉ đúng với một trong bốn (chatbot viết email). Dự đoán rời bỏ và phát hiện gian lận không sinh nội dung.

• A (Deep Learning) — một kỹ thuật cụ thể, hẹp hơn ML. Dùng nó làm từ bao trùm là sai cả về logic lẫn về cách nói trước hội đồng quản trị.

Ghi nhớ

⚠ Bốn tầng lồng nhau — bảng phải thuộc: | Tầng | Định nghĩa | Ví dụ | |---|---|---| | ⚠ AI | ⚠ máy làm việc cần trí tuệ | ⚠ kể cả hệ dựa luật, robot | | ML | ⚠ HỌC từ dữ liệu, không lập trình luật | dự báo, phân loại | | Deep Learning | ⚠ ML dùng mạng nơ-ron nhiều lớp | thị giác, ngôn ngữ | | ⚠ Gen AI | ⚠ SINH nội dung mới | ⚠ hẹp nhất |

Từ khoá nhận diện:

"overarching", "comprehensive", "bao trùm tất cả" → ⚠ AI "học từ dữ liệu lịch sử" → ML "mạng nơ-ron sâu" → Deep Learning "tạo văn bản/ảnh/mã mới" → Gen AI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ thống này có học từ dữ liệu không | ⚠ không thì là AI chứ không phải ML | | Nó có sinh nội dung mới không | ⚠ không thì không phải Gen AI | | Nói với ai | ⚠ hội đồng cần từ bao trùm, kỹ sư cần từ chính xác |

Và điều dễ sai nhất ở nhóm câu này: ML là bẫy tốt hơn Gen AI, vì nó gần đúng. Chốt được là nhờ nhận ra có ít nhất một ví dụ không nhất thiết phải học từ dữ liệu — đó là lý do câu trả lời phải lùi ra vòng ngoài cùng.

Đáp án

D — Google's AI Principles (Các nguyên tắc AI của Google).

Vì sao đúng

Đề hỏi "foundational commitment" — cam kết nền tảng dẫn đường cho phát triển và triển khai có đạo đức. Ba mối lo được nêu đều là mối lo đạo đức, không phải kỹ thuật:

⚠ Ghép từng mối lo:

"khuyến nghị THIÊN LỆCH"
    → ⚠ nguyên tắc CÔNG BẰNG

"phân biệt đối xử NHÓM ĐƯỢC
 BẢO VỆ"
    → ⚠ nguyên tắc tránh tạo/củng cố
      định kiến bất công

"không CHỊU TRÁCH NHIỆM
 cho đầu ra"
    → ⚠ nguyên tắc CHỊU TRÁCH NHIỆM
      TRƯỚC CON NGƯỜI

⚠ Thứ bậc — phải thuộc:

⚠ AI Principles
    → ⚠ TẦNG CAM KẾT, giá trị
    → "chúng ta TIN vào điều gì"
        ↓
Khung và công cụ
    → ⚠ SAIF (bảo mật)
    → ⚠ Model Evaluation (đo lường)
    → ⚠ RLHF (kỹ thuật căn chỉnh)
    → "chúng ta LÀM THẾ NÀO"

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

• B (SAIF — Secure AI Framework) — ⚠ bẫy mạnh nhất vì cũng là khung nền tảng của Google. Nhưng SAIF nói về BẢO MẬT: chống đầu độc dữ liệu, tiêm prompt, trộm mô hình, tấn công chuỗi cung ứng. ⚠ Nó không nói về công bằng hay phân biệt đối xử — mà đó mới là mối lo của đề.

• A (Vertex AI Model Evaluation) — công cụ ĐO, giúp phát hiện thiên lệch. Nhưng công cụ không phải "cam kết nền tảng"; ⚠ phải có nguyên tắc trước thì mới biết đo cái gì và ngưỡng nào là không chấp nhận được.

• C (RLHF) — kỹ thuật huấn luyện để căn chỉnh mô hình theo sở thích con người. Cũng là phương tiện, không phải cam kết; và bản thân RLHF ⚠ có thể mang chính thiên lệch của người đánh giá vào mô hình.

⚠ Cách phân biệt chung: đề hỏi "commitment/principle" → chọn tuyên bố giá trị. Đề hỏi "tool/framework/technique" → chọn công cụ.

Ghi nhớ

⚠ Bốn thứ hay bị nhầm lẫn — bảng phải thuộc: | Thứ | Là gì | Trả lời câu hỏi | |---|---|---| | ⚠ AI Principles | ⚠ cam kết giá trị | ⚠ "nên hay không nên làm" — đề này | | ⚠ SAIF | ⚠ khung BẢO MẬT | ⚠ "chống tấn công thế nào" | | Model Evaluation | ⚠ công cụ đo | ⚠ "mô hình tốt cỡ nào" | | RLHF | ⚠ kỹ thuật huấn luyện | ⚠ "căn chỉnh ra sao" |

Từ khoá nhận diện:

"ethical", "foundational commitment", "công bằng" → ⚠ AI Principles "tấn công, đầu độc dữ liệu, tiêm prompt" → ⚠ SAIF "đo, so sánh mô hình" → Model Evaluation "căn chỉnh theo phản hồi người" → RLHF

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguyên tắc đã thành checklist chưa | ⚠ văn bản suông không đủ | | Ai có quyền chặn phát hành | ⚠ phải là người độc lập với đội sản phẩm | | Chênh lệch kết quả theo nhóm | ⚠ đo định kỳ, không chỉ trước khi ra mắt |

Và điều quan trọng nhất để không nhầm ở nhóm câu này: SAIF trả lời "ai đó tấn công hệ thống thì sao", AI Principles trả lời "hệ thống chạy đúng như thiết kế thì có gây hại cho ai không". Đề này thuộc vế thứ hai — không có kẻ tấn công nào cả, chỉ có mô hình làm đúng việc nó học được và gây hại.

Đáp án

D — Tối đa hoá mức độ tương tác và thời gian phiên bằng cách làm tính cách chatbot thuyết phục nhất có thể.

Ghi nhớ về dạng câu hỏi

⚠ Câu hỏi PHỦ ĐỊNH — hỏi cái KHÔNG phải mục tiêu. Ba phương án còn lại đều đúng.

⚠ Mẹo: gạch ba việc rõ ràng là "có trách nhiệm" trước; cái còn lại — thường là cái nói về chỉ số kinh doanh — là đáp án.

Vì sao đúng

⚠ Vì sao phương án D đi ngược nguyên tắc:

"Maximizing ENGAGEMENT and
 SESSION TIME"
    → ⚠ mục tiêu KINH DOANH,
      không phải mục tiêu đạo đức

"as PERSUASIVE as possible"
    → ⚠ THAO TÚNG người dùng
    → ⚠ đi ngược "có lợi cho xã hội"

⚠ Vì sao nó nguy hiểm thật, không chỉ sai trên giấy:

⚠ Chatbot CSKH tốt = giải quyết
  vấn đề NHANH
        ↓
⚠ Tối ưu thời gian phiên = giữ
  khách ở lại LÂU
        ↓
⚠ HAI MỤC TIÊU NGƯỢC NHAU
        ↓
⚠ Tối ưu sai chỉ số → chatbot
  cố tình vòng vo

⚠ Thêm nữa: "persuasive" trong ngữ cảnh gợi ý sản phẩm rất gần với thao túng để bán hàng — đúng thứ nguyên tắc AI có trách nhiệm cảnh báo.

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

Cả ba đều là mục tiêu đúng, nên không phải đáp án:

• A (công bằng, không tạo hay củng cố thiên lệch) — đúng, là một trong những nguyên tắc được nêu tên rõ nhất.

• B (cơ chế chuyển sang người thật khi bot hỏng) — đúng, thuộc chịu trách nhiệm trước con người và là thực hành CSKH bắt buộc.

• C (kiểm thử nghiêm ngặt để tránh nội dung không phù hợp) — đúng, thuộc an toàn.

Ghi nhớ

⚠ Sáu nguyên tắc AI — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | Có lợi cho xã hội | ⚠ lợi ích vượt rủi ro | | ⚠ Tránh thiên lệch bất công | ⚠ phương án A | | ⚠ An toàn | ⚠ phương án C | | ⚠ Chịu trách nhiệm trước con người | ⚠ phương án B — có đường thoát tới người thật | | Tôn trọng quyền riêng tư | | | Chuẩn khoa học cao | |

Từ khoá nhận diện đáp án của câu phủ định:

"maximize engagement/session time" → ⚠ chỉ số kinh doanh, KHÔNG phải mục tiêu đạo đức "persuasive", "addictive", "hard to leave" → ⚠ dấu hiệu THAO TÚNG "fair", "safe", "escalate to human" → ⚠ đều là mục tiêu ĐÚNG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội đang đo chỉ số nào | ⚠ chỉ số quyết định hành vi bot | | Chuyển sang người thật mất mấy bước | ⚠ thử từ phía khách | | Bot có tự nhận là AI không | ⚠ hỏi thẳng "bạn là người hay máy" |

Và điều đáng nhớ nhất: phương án sai trong câu phủ định về đạo đức thường là câu duy nhất nói về lợi ích doanh nghiệp thay vì lợi ích người dùng. Nhận ra được điểm đó là trả lời được cả họ câu hỏi cùng dạng.

Đáp án

D — Chỉ chọn endpoint mô hình ở vùng địa lý có chi phí tính toán thấp nhất, dù người dùng phải chịu độ trễ cao hơn.

Ghi nhớ về dạng câu hỏi

⚠ Câu hỏi PHỦ ĐỊNH — hỏi chiến lược KHÔNG hợp lệ. Ba phương án còn lại đều là thực hành đúng và đáng thuộc.

Vì sao đúng

⚠ Vì sao phương án D hỏng:

Đề yêu cầu:
    ⚠ "both HIGH-PERFORMING
       AND cost-effective"
        ↓
⚠ Phương án D hy sinh HOÀN TOÀN
  vế hiệu năng
        ↓
⚠ Chữ "EXCLUSIVELY" và
  "EVEN IF it means higher latency"
  tự tố cáo phương án

⚠ Ba lý do thực tế:

1. ⚠ Độ trễ là trải nghiệm người dùng
   → ⚠ chờ lâu thì bỏ đi, mất tiền
     nhiều hơn phần tiết kiệm

2. ⚠ Có yêu cầu CHỦ QUYỀN DỮ LIỆU
   → ⚠ nhiều ngành BẮT BUỘC xử lý
     trong vùng nhất định
   → ⚠ chọn vùng chỉ theo giá là
     vi phạm

3. Chênh lệch giá giữa vùng thường nhỏ
   → ⚠ không bù nổi thiệt hại trải nghiệm

⚠ Lưu ý: chọn vùng theo chi phí không phải luôn sai — nó sai vì chữ "exclusively" và vì chấp nhận đánh đổi độ trễ của người dùng cuối. Với xử lý theo lô, không ai chờ, thì đó lại là lựa chọn hợp lý.

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

Cả ba đều là chiến lược đúng:

• A (mô hình nhỏ cho việc đơn giản, mô hình mạnh cho việc phức tạp) — ⚠ kỹ thuật tối ưu chi phí quan trọng nhất. Phân loại phản hồi khách hàng không cần mô hình mạnh nhất; động não ý tưởng marketing thì cần.

• B (giới hạn max output tokens) — đúng. ⚠ Trả tiền theo token, nên chặn câu trả lời dài lê thê cho việc cần ngắn gọn là tiết kiệm trực tiếp.

• C (cache câu trả lời cho prompt trùng lặp) — đúng, và hiệu quả cao khi nhiều người hỏi những câu giống nhau.

Ghi nhớ

⚠ Năm cách giảm chi phí Vertex AI — bảng phải thuộc: | Cách | Nội dung | |---|---| | ⚠ Chọn đúng cỡ mô hình | ⚠ Flash cho việc đơn giản, Pro cho suy luận — mạnh nhất | | ⚠ Giới hạn max output tokens | ⚠ trả tiền theo token | | ⚠ Cache prompt trùng | ⚠ và context caching cho phần ngữ cảnh dùng lại | | Rút gọn prompt | ⚠ đừng nhét ngữ cảnh thừa | | ⚠ Gộp theo lô khi không cần tức thì | ⚠ batch rẻ hơn |

Từ khoá nhận diện:

"exclusively", "at all costs", "even if" → ⚠ dấu hiệu phương án CỰC ĐOAN, thường sai "việc đơn giản dùng mô hình nhỏ" → ⚠ luôn đúng "cache", "giới hạn token" → ⚠ luôn đúng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc nào đang dùng mô hình quá mạnh | ⚠ thử hạ xuống Flash và đo chất lượng | | Tỷ lệ prompt trùng lặp | ⚠ quyết định cache có đáng không | | Độ trễ p95 người dùng thấy | ⚠ không phải độ trễ trung bình |

Và mẹo chấm nhanh nhất cho câu phủ định về tối ưu: phương án chứa "exclusively", "always", "at any cost" gần như luôn là đáp án, vì tối ưu hệ thống về bản chất là cân bằng nhiều yếu tố, không bao giờ là tối đa hoá một yếu tố duy nhất.

Đáp án

B — Nó làm mô hình về cơ bản sáng tạo hơn khi giải quyết những vấn đề không có trong tài liệu.

Ghi nhớ về dạng câu hỏi

⚠ Câu hỏi PHỦ ĐỊNH — hỏi cái KHÔNG phải lợi ích. Ba phương án còn lại là ba lợi ích cốt lõi của RAG, đáng thuộc nguyên văn.

Vì sao đúng

⚠ RAG làm điều NGƯỢC LẠI với sáng tạo:

Mục đích của RAG:
    ⚠ RÀNG BUỘC mô hình vào tài liệu
    ⚠ BỚT tự do bịa ra
    ⚠ Trả lời "tôi không có thông tin"
       khi tài liệu không nói

⚠ Đó là TÍNH NĂNG, không phải khiếm khuyết

⚠ Nghịch lý phải hiểu:

⚠ RAG đánh đổi SÁNG TẠO lấy CHÍNH XÁC

Help desk IT cần gì?
    ⚠ Cần ĐÚNG, không cần sáng tạo
    ⚠ Bot bịa cách sửa lỗi mạng
      "sáng tạo" = tai hoạ

⚠ Thậm chí với vấn đề không có trong tài liệu, hệ thống RAG tốt phải nói là không tìm thấy chứ không được tự nghĩ ra giải pháp.

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

Cả ba đều là lợi ích thật của RAG:

• A (trích dẫn nguồn để người dùng tự kiểm chứng) — đúng, và là lợi ích phân biệt RAG với fine-tuning rõ nhất.

• C (giảm ảo giác, tăng độ chính xác) — đúng, là lý do tồn tại của RAG.

• D (cập nhật tri thức chỉ bằng cách sửa tài liệu nguồn) — đúng, và là lợi ích vận hành lớn nhất: không phải huấn luyện lại gì cả.

Ghi nhớ

⚠ Bốn lợi ích của RAG — bảng phải thuộc: | Lợi ích | Nội dung | |---|---| | ⚠ Giảm ảo giác | ⚠ buộc bám vào tài liệu | | ⚠ Trích dẫn được nguồn | ⚠ kiểm chứng được | | ⚠ Cập nhật dễ | ⚠ sửa tài liệu là xong | | Phân quyền theo người hỏi | ⚠ lọc tài liệu trước khi truy hồi | | ⚠ KHÔNG phải lợi ích | ⚠ sáng tạo — RAG làm giảm |

Từ khoá nhận diện:

"citation, verify, accurate, up-to-date" → ⚠ lợi ích THẬT của RAG "creative, novel, imaginative" → ⚠ KHÔNG phải RAG "cần ý tưởng mới" → ⚠ temperature cao, KHÔNG dùng RAG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hỏi câu không có trong tài liệu thì bot nói gì | ⚠ phải nói không biết, không được bịa | | Trích dẫn có trỏ đúng tài liệu không | ⚠ mở ra đối chiếu thật | | Tài liệu hết hiệu lực còn trong chỉ mục không | ⚠ rà định kỳ |

Và điều đáng nhớ nhất: mọi lợi ích của RAG đều xoay quanh SỰ THẬT, không cái nào xoay quanh sự sáng tạo. Nhớ được nguyên tắc đó thì mọi câu phủ định về RAG đều trả lời được ngay mà không cần thuộc từng phương án.

Đáp án

B — Giảm chi phí hoặc tăng hiệu quả vận hành (cost reduction / efficiency gains).

Vì sao đúng

Công ty đo thời gian trung bình nhân viên xử lý một vấn đề, so trước và sau khi có chatbot. Đó là đo hiệu quả vận hành, quy đổi trực tiếp ra chi phí.

⚠ Vì sao là hiệu quả chứ không phải doanh thu:

"thời gian nhân viên xử lý"
        ↓
    ⚠ ít thời gian hơn
    = ⚠ ít giờ công hơn
    = ⚠ CHI PHÍ THẤP HƠN
    hoặc phục vụ được nhiều khách hơn
      với cùng số nhân viên
        ↓
    → ⚠ tiết kiệm chi phí / tăng
      hiệu quả

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

"Tạo doanh thu trực tiếp"
    → ⚠ chatbot hỗ trợ không BÁN hàng

"Cải thiện cảm nhận thương hiệu"
    → ⚠ đo bằng khảo sát thương hiệu

"Điểm hài lòng của khách"
    → ⚠ đo bằng CSAT, NPS —
      chỉ số KHÁC

Nhất quán với #13894 (lô 145) — đề đó về việc chọn chỉ số TRỰC TIẾP để đo tác động của tính năng AI. Cùng nguyên tắc. Bổ sung nhau.

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

• D (điểm hài lòng khách hàng) — phương án gần nhất và là bẫy chính: chatbot hỗ trợ cũng ảnh hưởng tới hài lòng. Nhưng chỉ số đề nêu là thời gian xử lý của nhân viên, một thước đo hiệu quả nội bộ.

• C và A — đo bằng chỉ số khác hẳn.

Ghi nhớ

⚠ Bốn nhóm tác động của dự án AI — bảng nên thuộc: | Nhóm | Chỉ số | |---|---| | ⚠ Giảm chi phí / tăng hiệu quả | ⚠ thời gian xử lý, số việc/người, chi phí mỗi giao dịch | | Tăng doanh thu | ⚠ chuyển đổi, giá trị đơn, khách mới | | Trải nghiệm khách hàng | ⚠ CSAT, NPS, tỉ lệ giải quyết lần đầu | | Giảm rủi ro | ⚠ lỗi, sự cố tuân thủ | | Nhân viên | ⚠ thời gian đào tạo, tỉ lệ nghỉ việc |

Từ khoá nhận diện:

"thời gian xử lý, giờ công tiết kiệm" → ⚠ hiệu quả / chi phí "tỉ lệ chuyển đổi, doanh thu" → tăng doanh thu "CSAT, NPS" → ⚠ hài lòng khách hàng "số sự cố tuân thủ" → giảm rủi ro

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có đường cơ sở trước không | ⚠ thiếu thì mọi so sánh đều tranh cãi được | | Chất lượng có giảm không | ⚠ đo song song với tốc độ | | Đã trừ chi phí vận hành AI chưa | ⚠ để ra con số ròng |

Và cạm bẫy tinh vi nhất khi đo hiệu quả của một chatbot hỗ trợ: bot xử lý hết ca dễ và chỉ đẩy ca khó lên cho nhân viên, khiến thời gian trung bình của con người tăng lên dù hệ thống tổng thể đã tốt hơn nhiều. Vì vậy con số cần nhìn là tổng chi phí phục vụ, không phải thời gian của riêng một khâu.

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

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

B — Cloud Video Intelligence API.

Vì sao đúng

Đề nêu ba loại nội dung cần nhận ra trong video, và chỉ một API làm được cả ba trong một lần gọi trên chính tệp video:

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

"nhận diện ĐỐI TƯỢNG"
    → ⚠ label detection, object tracking

"nhận diện CHỮ trong hình"
    → ⚠ text detection (OCR trên khung hình)

"nhận diện LỜI NÓI"
    → ⚠ speech transcription

⚠ CẢ BA đều nằm trong
   Video Intelligence API

⚠ Điểm mấu chốt — có TRỤC THỜI GIAN:

Video Intelligence trả về
    ⚠ NHÃN kèm MỐC THỜI GIAN
        ↓
⚠ "logo hãng xuất hiện ở giây 0:47"
        ↓
⚠ Đúng thứ người sáng tạo nội dung
  cần để TÌM ĐOẠN CLIP

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

• D (Cloud Vision API) — làm ảnh tĩnh, không làm video. Muốn dùng thì phải tự tách khung hình, tự gộp kết quả, ⚠ và mất hoàn toàn phần lời nói.

• A (Speech-to-Text API) — chỉ lấy được lời nói. Bỏ mất đối tượng và chữ trong hình — hai trong ba yêu cầu.

• C (Vertex AI Search) — công cụ TÌM KIẾM trên metadata đã có. ⚠ Nó là bước SAU, không phải bước tạo ra metadata. Đề hỏi cái "generate metadata".

⚠ Lưu ý kiến trúc: thực tế người ta dùng cả B rồi C — Video Intelligence sinh metadata, rồi Vertex AI Search cho phép tìm. Nhưng câu hỏi hỏi cái phân tích video, nên đáp án là B.

Ghi nhớ

⚠ Bốn API tiền dựng — bảng phải thuộc: | API | Đầu vào | Cho ra | |---|---|---| | ⚠ Video Intelligence | ⚠ VIDEO | ⚠ nhãn + chữ + lời nói, kèm MỐC THỜI GIAN | | Cloud Vision | ⚠ ẢNH TĨNH | nhãn, chữ, khuôn mặt | | Speech-to-Text | ⚠ ÂM THANH | ⚠ chỉ văn bản lời nói | | Natural Language | văn bản | thực thể, cảm xúc |

Từ khoá nhận diện:

"video", "clip", "cảnh", "mốc thời gian" → ⚠ Video Intelligence "ảnh, hình chụp" → Vision "ghi âm, cuộc gọi" → Speech-to-Text "tìm trong kho đã lập chỉ mục" → Vertex AI Search

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ bật tính năng thật sự cần chưa | ⚠ mỗi tính năng một khoản tiền | | Chất lượng nhãn trên video của bạn | ⚠ thử vài video đại diện trước khi chạy cả kho | | Metadata đã lưu lại chưa | ⚠ phân tích lại cả kho là rất đắt |

Và điều dễ nhầm nhất ở nhóm câu này: Vertex AI Search nghe rất hợp với chữ "searchable" trong đề. Nhưng nó tìm trên thứ đã có; câu hỏi hỏi cái tạo ra thứ để tìm — đọc kỹ động từ "generate metadata" là phân biệt được ngay.

Đáp án

D — Cho thấy kỹ năng prompt engineering trao quyền cho người không chuyên kỹ thuật kiểm soát và lấy được đầu ra chất lượng cao, cụ thể từ hệ thống AI phức tạp.

Vì sao đúng

Đề mô tả rất chính xác một chuyên viên không phải kỹ sư đạt kết quả tốt hơn hẳn chỉ bằng cách viết câu lệnh khác đi — không đổi mô hình, không viết code, không tốn thêm tiền.

⚠ Bốn kỹ thuật trong chính câu prompt của cô ấy:

"Act as a senior copywriter"
    → ⚠ ROLE PROMPTING — gán vai

"generate THREE ad slogans"
    → ⚠ nêu SỐ LƯỢNG cụ thể

"for a new product, targeting
 YOUNG ADULTS"
    → ⚠ nêu ĐỐI TƯỢNG

"with a WITTY and INFORMAL tone"
    → ⚠ nêu GIỌNG ĐIỆU

⚠ So với "Make ad slogans":

⚠ Không vai → mô hình trả lời chung chung
⚠ Không đối tượng → không nhắm ai
⚠ Không giọng điệu → giọng trung tính
⚠ Không số lượng → không biết trả mấy cái

⚠ Ý nghĩa kinh doanh:

⚠ Giá trị AI phần lớn mở khoá bằng
  KỸ NĂNG NGƯỜI DÙNG
        ↓
⚠ Đào tạo prompt cho cả phòng
  → rẻ hơn nhiều so với thuê kỹ sư
  → hiệu quả ngay lập tức

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

• A (cần fine-tune để mô hình hiểu thuật ngữ marketing) — ⚠ kết luận sai từ bằng chứng đúng. Chính phát hiện này chứng minh mô hình đã hiểu tốt khi được hướng dẫn rõ — không cần fine-tune gì cả.

• C (cần tuyển thêm data scientist viết code) — ⚠ ngược hẳn. Điểm quan trọng là chuyên viên marketing tự làm được, không cần người viết code.

• B (chỉ mô hình rất lớn và đắt mới hữu ích) — không suy ra được từ đề. Cùng một mô hình, chỉ khác cách hỏi.

Ghi nhớ

⚠ Bốn thành phần của một prompt tốt — bảng phải thuộc: | Thành phần | Ví dụ trong đề | |---|---| | ⚠ Vai (persona) | ⚠ "senior copywriter" | | ⚠ Nhiệm vụ rõ ràng | ⚠ "generate three ad slogans" | | ⚠ Ngữ cảnh | ⚠ "new product, young adults" | | ⚠ Định dạng/giọng điệu | ⚠ "witty and informal" | | Có thể thêm | ⚠ ví dụ mẫu (few-shot), ràng buộc độ dài |

Từ khoá nhận diện:

"Act as a…", "You are a…" → ⚠ role prompting "kết quả tốt hơn nhờ viết prompt khác" → ⚠ prompt engineering "giọng văn riêng của thương hiệu, hàng nghìn ví dụ" → fine-tuning "dữ liệu nội bộ, sự thật" → RAG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Prompt tốt đã chia sẻ cho cả đội chưa | ⚠ thư viện prompt là tài sản | | Đầu ra có bịa gì về sản phẩm không | ⚠ đối chiếu tài liệu sản phẩm | | Có đang dùng công cụ được phép không | ⚠ rủi ro rò rỉ dữ liệu |

Và điều đáng nhớ nhất từ ca này: khoảng cách giữa "Make ad slogans" và câu prompt đầy đủ không phải là khoảng cách công nghệ, mà là khoảng cách kỹ năng. Đó là lý do đào tạo prompt cho người dùng thường cho lợi tức cao hơn hẳn việc nâng cấp mô hình.

Đáp án

A — Lập một đội dự án chính thức, chuyên trách, gồm cả vai trò nghiệp vụ lẫn kỹ thuật, có mục tiêu rõ ràng và có người bảo trợ ở cấp điều hành.

Vì sao đúng

Đề mô tả một bước chuyển giai đoạn rất cụ thể, và cách tổ chức phải đổi theo:

⚠ Đã đổi những gì:

TRƯỚC:
    ⚠ PoC — thử nghiệm
    ⚠ nội bộ, rủi ro thấp
    ⚠ đội không chính thức là ĐỦ

SAU:
    ⚠ PRODUCTION-GRADE
    ⚠ CUSTOMER-FACING
    ⚠ có phê duyệt CHIẾN LƯỢC
        ↓
⚠ cần độ tin cậy, bảo mật, tuân thủ,
  vận hành, hỗ trợ, trách nhiệm rõ

⚠ Vì sao phải trộn nghiệp vụ và kỹ thuật:

⚠ Chỉ kỹ thuật → giải bài toán sai
⚠ Chỉ nghiệp vụ → không đánh giá
  được khả thi
⚠ Tác nhân đối mặt khách hàng còn cần
  pháp chế, bảo mật, CSKH

⚠ Vì sao cần bảo trợ điều hành:

⚠ Gỡ vướng liên phòng ban
⚠ Bảo đảm ngân sách và nhân sự
⚠ Ra quyết định khi có xung đột
⚠ Không có → dự án chết vì
  không ai ưu tiên

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

• B (giữ nguyên đội không chính thức cho linh hoạt) — ⚠ bẫy hấp dẫn vì chính đội này đã thành công. Nhưng cái làm PoC thành công (nhanh, không thủ tục, rủi ro thấp) chính là cái không đủ cho sản phẩm chạy thật với khách hàng: không ai chịu trách nhiệm khi có sự cố, không có quy trình phát hành, không có trực vận hành.

• D (lập ngay một CoE lớn, tập trung, quản trị mọi dự án AI toàn doanh nghiệp) — ⚠ đúng hướng nhưng SAI THỜI ĐIỂM. CoE là bước sau khi có nhiều dự án; lập lúc mới có một dự án thí điểm là ⚠ nặng nề, tạo quan liêu, và chưa có bài học thực tế nào để chuẩn hoá. Chính dự án thí điểm này sẽ sinh ra bài học để sau đó dựng CoE.

• C (thuê ngoài toàn bộ) — ⚠ với hệ thống chiến lược, đối mặt khách hàng thì đây là bỏ mất năng lực nội bộ, phụ thuộc nhà cung cấp, và mất quyền kiểm soát dữ liệu khách hàng.

Ghi nhớ

⚠ Bốn giai đoạn trưởng thành AI — bảng phải thuộc: | Giai đoạn | Tổ chức phù hợp | |---|---| | Khám phá | ⚠ cá nhân, đội không chính thức | | PoC | ⚠ đội đổi mới nhỏ | | ⚠ Thí điểm sản xuất | ⚠ ĐỘI DỰ ÁN CHÍNH THỨC — đề này | | ⚠ Mở rộng nhiều dự án | ⚠ CoE, nền tảng dùng chung |

Từ khoá nhận diện:

"production-grade", "customer-facing", "first pilot" → ⚠ đội dự án chính thức "nhiều dự án, chuẩn hoá toàn doanh nghiệp" → ⚠ CoE "thử nhanh xem có khả thi" → đội nhỏ không chính thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có người bảo trợ điều hành có tên chưa | ⚠ không có thì dự án sẽ trượt ưu tiên | | Định nghĩa thành công đã đo được chưa | ⚠ chỉ số nghiệp vụ, không phải chỉ số mô hình | | Ai trực khi có sự cố | ⚠ phải trả lời được trước khi ra mắt |

Và sai lầm tổ chức phổ biến nhất ở bước này: lập CoE quá sớm. CoE tồn tại để chuẩn hoá bài học từ nhiều dự án — khi mới có một dự án thí điểm thì chưa có gì để chuẩn hoá, và bộ máy quản trị dựng trước sẽ làm chậm đúng cái dự án đáng lẽ phải sinh ra những bài học đó.

Đáp án

D — Vertex AI Agent Builder.

Vì sao đúng

Đề mô tả đúng định nghĩa của một tác nhân điều phối: nhận một yêu cầu, rồi tự thực hiện một CHUỖI hành động qua nhiều hệ thống khác nhau.

⚠ Ba dấu hiệu chốt đáp án:

"multi-step workflows"
    → ⚠ nhiều bước, có thứ tự

"using different TOOLS and APIs"
    → ⚠ TOOL CALLING

"a SINGLE agent that can
 ORCHESTRATE"
    → ⚠ MỘT bộ não điều phối,
      không phải nhiều mảnh rời

⚠ Ba bước trong đề là ba công cụ:

1. API cấp máy tính (IT)
2. API tạo hồ sơ (HR)
3. API thêm vào phòng chat

⚠ Agent Builder gói cả ba thành
  công cụ của MỘT tác nhân

⚠ Gần trùng với #13952 (lô 146), #14063 và #14084 (lô 149) — bốn câu, bốn bối cảnh (du lịch, doanh nghiệp, onboarding), cùng một khoá. Dấu hiệu chung: gọi API + nhiều bước + hành động thật.

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

• A (Cloud Run functions) — ⚠ bẫy mạnh nhất: nó chạy được từng bước. Nhưng nó là hạ tầng thực thi, không có khả năng hiểu ngôn ngữ tự nhiên và tự quyết thứ tự gọi công cụ. Thực tế Cloud Run functions thường là nơi chứa công cụ mà tác nhân gọi tới — nó nằm dưới Agent Builder, không thay thế được.

• C (Vertex AI Search) — chỉ TÌM và TRẢ LỜI từ tài liệu. ⚠ Nó không HÀNH ĐỘNG, không gọi API cấp máy tính được.

• B (Gemini for Google Workspace) — trợ lý trong Docs, Gmail, Meet. Nó không tích hợp API tuỳ ý của phòng IT và HR để chạy quy trình nghiệp vụ.

Ghi nhớ

⚠ Bốn thứ hay bị nhầm — bảng phải thuộc: | Thứ | Vai trò | |---|---| | ⚠ Agent Builder | ⚠ BỘ NÃO điều phối, gọi công cụ — đề này | | Cloud Run functions | ⚠ TAY CHÂN — nơi code công cụ chạy | | Vertex AI Search | ⚠ TÌM và trả lời, KHÔNG hành động | | Gemini for Workspace | ⚠ trợ lý trong ứng dụng văn phòng |

Từ khoá nhận diện:

"orchestrate, multi-step, gọi nhiều API" → ⚠ Agent Builder "chỉ trả lời từ tài liệu" → Vertex AI Search "chạy một đoạn code khi có sự kiện" → Cloud Run functions "soạn thảo trong Docs/Gmail" → Gemini for Workspace

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent gọi công cụ nào, thứ tự ra sao | ⚠ đọc log lời gọi, không chỉ kết quả cuối | | Bước giữa chừng lỗi thì sao | ⚠ thử tắt một API và xem | | Quyền của service account | ⚠ tối thiểu cần thiết |

Và dấu hiệu nhận ra câu hỏi về agent một cách chắc chắn: có ít nhất một VIỆC được thực hiện ngoài đời thật. Chỉ trả lời câu hỏi thì là chatbot hoặc RAG; đặt máy tính, tạo tài khoản, thêm người vào nhóm thì là agent.