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

Tìm thấy 556 câu.

Câu 171 Google Cloud's gen AI offerings

A marketing team wants to build an AI model to predict which customers are most likely to respond to specific campaign types, but they lack data science expertise. They have clean customer data and historical campaign results but need a solution that can automatically handle the technical aspects of model creation.

What approach would best serve this marketing team's needs and capabilities?

  1. A

    Leverage automated machine learning tools that require minimal technical expertise
  2. B

    Use pre-trained models designed for generic marketing predictions
  3. C

    Purchase third-party marketing prediction software with fixed algorithms
  4. D

    Hire a team of data scientists to build custom models from scratch
Xem giải thích

Đáp án

A — Tận dụng các công cụ học máy tự động, đòi hỏi rất ít chuyên môn kỹ thuật.

Vì sao đúng

Đội marketing có dữ liệu sạch và kết quả chiến dịch lịch sử nhưng thiếu chuyên môn khoa học dữ liệu, và cần giải pháp tự động hoá phần kỹ thuật của việc dựng mô hình. Đó là AutoML.

⚠ Ba dữ kiện khớp:

"có dữ liệu SẠCH và kết quả
 chiến dịch lịch sử"
    → ⚠ có dữ liệu ĐÃ GÁN NHÃN
    → ⚠ đúng thứ AutoML cần

"THIẾU chuyên môn khoa học dữ liệu"
    → ⚠ loại bỏ tự viết mã

"tự động hoá PHẦN KỸ THUẬT"
    → ⚠ đúng định nghĩa AutoML

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

"Dùng mô hình huấn luyện sẵn cho
 dự đoán marketing CHUNG CHUNG"
    → ⚠ không học từ dữ liệu RIÊNG
      của công ty

"Mua phần mềm bên thứ ba với
 thuật toán CỐ ĐỊNH"
    → ⚠ không tuỳ biến theo dữ liệu
      của họ

"Tuyển đội khoa học dữ liệu để xây
 mô hình TỪ ĐẦU"
    → ⚠ tốn kém và chậm; họ đã có
      dữ liệu sẵn sàng

⚠ Gần trùng với #13896 (lô 145) — đề đó là bán lẻ dự đoán sản phẩm mua tiếp theo, đội thiếu kinh nghiệm ML, cùng khoá AutoML. Hoàn toàn nhất quán. Và #13549 (lô 144).

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

  • D (tuyển đội khoa học dữ liệu) — phương án gần nhất vì chắc chắn làm được, nhưng tốn kém và mất nhiều tháng trong khi AutoML giải quyết được ngay.

  • B và C — không tận dụng dữ liệu riêng của công ty.

Ghi nhớ

⚠ Chọn cách dựng mô hình theo NĂNG LỰC ĐỘI: | Đội có gì | Cách | |---|---| | ⚠ Dữ liệu có nhãn, KHÔNG có kỹ sư ML | ⚠ AutoML — đề này | | Biết SQL, dữ liệu ở BigQuery | ⚠ BigQuery ML | | Có kỹ sư ML | ⚠ Vertex AI custom training | | Không có dữ liệu, tác vụ phổ quát | ⚠ API dựng sẵn |

Từ khoá nhận diện:

"có dữ liệu nhãn, thiếu chuyên môn ML" → ⚠ AutoML "biết SQL" → BigQuery ML "tự chọn framework, viết mã" → custom training "tác vụ phổ quát" → API dựng sẵn

⚠ AutoML tự làm gì cho đội marketing Việc
⚠ Tự chọn kiến trúc mô hình
⚠ Tự xử lý đặc trưng ⚠ mã hoá, chuẩn hoá, giá trị thiếu
⚠ Tự dò siêu tham số
Tự chia train/test
⚠ Trả về chỉ số và TẦM QUAN TRỌNG đặc trưng ⚠ rất hữu ích cho marketing
Đội chỉ cần ⚠ dữ liệu sạch và chọn cột mục tiêu
⚠ Riêng bài toán dự đoán phản hồi chiến dịch Lưu ý
⚠ Định nghĩa "phản hồi" cho rõ ⚠ mở email? click? mua?
⚠ Dữ liệu MẤT CÂN BẰNG ⚠ tỉ lệ phản hồi thường thấp
⚠ Accuracy VÔ NGHĨA ⚠ dùng precision, recall, AUC
⚠ DATA LEAKAGE ⚠ cột chỉ có sau khi đã phản hồi
Chỉ dùng dữ liệu có TRƯỚC chiến dịch
Hành vi đổi theo mùa ⚠ huấn luyện lại định kỳ
⚠ Dự đoán rồi làm gì Điểm
⚠ Dự đoán KHÔNG có giá trị nếu không hành động
⚠ Nhắm đúng người có khả năng phản hồi ⚠ tiết kiệm ngân sách
Cá nhân hoá nội dung theo nhóm
⚠ Đo bằng A/B test ⚠ so với nhóm không dùng mô hình
Cạm bẫy ⚠ nhắm người vốn đã sẽ phản hồi = không tạo giá trị thêm
⚠ Việc đội marketing VẪN phải làm Việc
⚠ Định nghĩa bài toán và cột mục tiêu
⚠ ĐỌC chỉ số đánh giá ⚠ hiểu mô hình tốt tới đâu
⚠ Kiểm cột nào lộ đáp án
Thiết kế thử nghiệm để đo giá trị
Theo dõi và huấn luyện lại

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | "Phản hồi" định nghĩa thế nào | ⚠ quyết định cả bài toán | | Có cột nào lộ đáp án không | ⚠ leakage là lỗi phổ biến nhất | | Có A/B test để đo giá trị không | ⚠ cách duy nhất chứng minh hiệu quả |

Và cạm bẫy tinh tế của mọi mô hình nhắm mục tiêu chiến dịch: nó có thể chỉ đơn giản chỉ ra những khách hàng vốn đã định phản hồi. Nhắm vào họ cho ra chỉ số đẹp mà không tạo thêm doanh thu nào — nên phép đo đúng vẫn là so với một nhóm đối chứng không nhận chiến dịch.

Câu 172 Google Cloud's gen AI offerings

A financial services company needs to help its internal support team quickly find answers from thousands of policy documents, FAQs, and support transcripts. The ideal solution should use AI to understand user intent, return accurate results, and continuously improve with user feedback.

Which Google Cloud offering aligns best with these business needs?

  1. A

    Prompt Tuning
  2. B

    Vertex AI Search
  3. C

    Google Search
  4. D

    Vertex AI Agent Builder
Xem giải thích

Đáp án

B — Vertex AI Search.

Vì sao đúng

Đội hỗ trợ nội bộ cần tìm nhanh câu trả lời trong hàng nghìn tài liệu chính sách, FAQ và bản ghi hỗ trợ, với AI hiểu ý định người dùng, trả kết quả chính xác và cải thiện dần theo phản hồi. Đó là tìm kiếm doanh nghiệp.

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

"hàng nghìn tài liệu NỘI BỘ"
    → ⚠ tìm kiếm doanh nghiệp,
      không phải web

"HIỂU Ý ĐỊNH người dùng"
    → ⚠ tìm kiếm ngữ nghĩa

"CẢI THIỆN theo phản hồi"
    → ⚠ Vertex AI Search học từ
      tương tác người dùng

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

"Vertex AI Agent Builder"
    → ⚠ dựng AGENT hội thoại có
      công cụ và hành động
    → ⚠ ở đây chỉ cần TÌM câu trả lời

"Google Search"
    → ⚠ tìm WEB công khai

"Prompt Tuning"
    → ⚠ kỹ thuật tuỳ biến mô hình,
      không phải giải pháp tìm kiếm

⚠ Gần trùng với #13954 (lô 146) và #13902 (lô 145) — cả ba đều là tìm kiếm/hỏi đáp trên tài liệu nội bộ, 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 (Agent Builder) — phương án gần nhất và là bẫy chính: nó cũng grounding vào dữ liệu doanh nghiệp và cũng trả lời được. Nhưng nó dành cho agent có hội thoại và HÀNH ĐỘNG, còn nhu cầu ở đây là tìm câu trả lời trong tài liệu.

  • C và A — sai nguồn hoặc sai loại giải pháp.

Ghi nhớ

⚠ Chọn giải pháp theo nhu cầu — bảng phải thuộc: | Nhu cầu | Giải pháp | |---|---| | ⚠ Tìm câu trả lời trong tài liệu nội bộ | ⚠ Vertex AI Search | | Agent hội thoại có công cụ, hành động | ⚠ Agent Builder | | Không gian làm việc AI cho nhân viên | ⚠ Gemini Enterprise | | Nghiên cứu trên bộ tài liệu tự nạp | ⚠ NotebookLM | | Tin tức công khai | ⚠ Grounding with Search |

Từ khoá nhận diện:

"tìm trong tài liệu nội bộ, hiểu ý định" → ⚠ Vertex AI Search "agent gọi API, thực hiện việc" → Agent Builder "cổng thông tin cho nhân viên" → Gemini Enterprise "kỹ thuật tuỳ biến mô hình" → ⚠ prompt tuning

⚠ "Cải thiện theo phản hồi" nghĩa là gì Nghĩa
⚠ Học từ kết quả nào được CLICK
⚠ Học từ đánh giá hữu ích/không hữu ích
Điều chỉnh xếp hạng theo hành vi
⚠ Chỉ ra truy vấn KHÔNG có kết quả tốt ⚠ danh sách cải thiện tài liệu
Ghi nhớ ⚠ vòng phản hồi cần được THIẾT KẾ, không tự có
⚠ Nguồn tài liệu trong đề — mỗi loại một đặc thù Nguồn
⚠ Tài liệu chính sách ⚠ có phiên bản, phải gỡ bản cũ
FAQ ⚠ ngắn, dễ tra
⚠ Bản ghi hỗ trợ ⚠ dài, lộn xộn, có thể chứa PII
Vì vậy ⚠ che PII trong bản ghi trước khi đưa vào chỉ mục
⚠ Với ngành tài chính — yêu cầu thêm Yêu cầu
⚠ Lọc theo QUYỀN ⚠ không phải ai cũng xem được mọi chính sách
⚠ TRÍCH DẪN tài liệu và điều khoản ⚠ nhân viên phải kiểm chứng được
Audit log truy vấn ⚠ cho kiểm toán
⚠ Gỡ chính sách hết hiệu lực ⚠ rủi ro lớn nhất
Nói không biết khi ngoài phạm vi
⚠ Đo hiệu quả Chỉ số
⚠ Thời gian tìm ra câu trả lời ⚠ so trước và sau
⚠ Tỉ lệ truy vấn không có kết quả tốt
Tỉ lệ nhân viên dùng hằng ngày
⚠ Thời gian đào tạo nhân viên hỗ trợ mới ⚠ cải thiện rõ nhất
Tỉ lệ leo thang lên chuyên gia

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách cũ đã gỡ chưa | ⚠ nguồn trả lời sai số một | | Có lọc theo quyền không | ⚠ thử bằng tài khoản nhân viên thường | | Truy vấn nào hay không ra kết quả | ⚠ danh sách cải thiện tài liệu |

Và nguồn cải thiện dễ khai thác nhất của mọi hệ thống tìm kiếm nội bộ: danh sách những câu hỏi mà nhân viên tra nhưng không tìm thấy câu trả lời. Đó vừa là chỗ cần bổ sung tài liệu, vừa là bằng chứng rõ ràng nhất cho việc hệ thống đang thiếu gì.

Câu 173 Fundamentals of gen AI

A marketing director is evaluating two approaches for improving AI content creation: training her team to write better prompts, versus investing in a solution that automatically optimizes the AI model for their specific content needs.

Which statement best describes these approaches?

  1. A

    The first is prompt tuning, the second is prompt engineering - both require equal technical expertise
  2. B

    Both are prompt engineering and require the same investment
  3. C

    The first is prompt engineering, the second is prompt tuning - prompt tuning requires less ongoing team effort but higher initial investment
  4. D

    The first is prompt tuning, the second is prompt engineering - prompt engineering requires less ongoing effort
Xem giải thích

Đáp án

C — Cách thứ nhất là prompt engineering, cách thứ hai là prompt tuning; prompt tuning đòi ít công sức duy trì hơn nhưng đầu tư ban đầu cao hơn.

Vì sao đúng

Đào tạo đội viết prompt tốt hơn = prompt engineering. Đầu tư giải pháp tự động tối ưu mô hình cho nhu cầu nội dung riêng = prompt tuning. Và đánh đổi giữa hai cách đúng như phương án mô tả.

⚠ Hai cách, hai đặc điểm:

⚠ PROMPT ENGINEERING
    → ⚠ CON NGƯỜI viết câu lệnh
    → ⚠ đầu tư ban đầu THẤP
    → ⚠ nhưng công sức LIÊN TỤC
    → phụ thuộc kỹ năng từng người
    → ⚠ chất lượng KHÔNG đồng đều

⚠ PROMPT TUNING
    → ⚠ HỌC ra prefix tối ưu
      từ dữ liệu
    → ⚠ đầu tư ban đầu CAO hơn
    → ⚠ sau đó ÍT công sức duy trì
    → ⚠ chất lượng NHẤT QUÁN hơn

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

"Cả hai đều là prompt engineering,
 đầu tư như nhau"
    → ⚠ sai: hai kỹ thuật khác nhau

"Đảo ngược tên hai kỹ thuật"
    → ⚠ hai phương án còn lại đều
      gán nhầm tên

Nhất quán với #13935 (lô 146) — đề đó định nghĩa prompt tuning là học prefix mà không đổi trọng số. Đề này so sánh nó với prompt engineering. Bổ sung nhau.

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

  • D (đảo ngược) — phương án gần nhất và là bẫy trực tiếp: nêu đúng hai kỹ thuật nhưng gán ngược tên, và kết luận về công sức cũng ngược.

  • A và B — sai về bản chất hai kỹ thuật.

Ghi nhớ

⚠ Prompt engineering và prompt tuning — bảng phải thuộc: | | ⚠ Prompt engineering | ⚠ Prompt tuning | |---|---|---| | Ai làm | ⚠ CON NGƯỜI viết | ⚠ HỌC từ dữ liệu | | Đầu tư ban đầu | ⚠ thấp | ⚠ cao hơn | | Công sức duy trì | ⚠ liên tục | ⚠ ít hơn | | Nhất quán | ⚠ tuỳ người | ⚠ cao hơn | | Cần dữ liệu | ⚠ không | ⚠ CÓ — ví dụ mẫu | | Trọng số mô hình | ⚠ không đổi | ⚠ KHÔNG đổi |

Từ khoá nhận diện:

"viết câu lệnh, đào tạo người" → ⚠ prompt engineering "học prefix tự động, không đổi trọng số" → ⚠ prompt tuning "huấn luyện lại, đổi trọng số" → fine-tuning "nối với tài liệu" → grounding

⚠ Bốn mức — nhắc lại theo công sức Mức
⚠ Prompt engineering ⚠ thấp nhất, thử đầu tiên
⚠ Prompt tuning / LoRA ⚠ học ít tham số, không đổi trọng số gốc
⚠ Fine-tuning ⚠ đổi trọng số, cao nhất
Grounding ⚠ giải quyết KIẾN THỨC, khác trục
⚠ Khi nào chọn prompt engineering Khi
⚠ Mới bắt đầu, chưa rõ nhu cầu ⚠ luôn thử trước
⚠ Ít dữ liệu ví dụ
Nhu cầu thay đổi nhanh ⚠ sửa prompt là xong
Đội nhỏ, khối lượng vừa
⚠ Cần MINH BẠCH ⚠ prompt đọc được, giải thích được
⚠ Khi nào chọn prompt tuning Khi
⚠ Đã có nhiều ví dụ CHẤT LƯỢNG
⚠ Nhu cầu ỔN ĐỊNH, lặp lại nhiều
Prompt thủ công quá dài mà vẫn không nhất quán
⚠ Khối lượng lớn ⚠ prompt ngắn hơn → rẻ hơn ở quy mô
Cần chất lượng đồng đều trong cả đội
⚠ Nhưng đừng bỏ qua bước một Điểm
⚠ Prompt engineering VẪN cần dù có tuning
⚠ Đội phải hiểu prompt để dùng đúng công cụ
Prompt tốt là dữ liệu đầu vào cho tuning
Nguyên tắc ⚠ đi từ nhẹ tới nặng, đừng nhảy thẳng

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đã thử prompt kỹ chưa | ⚠ thường giải quyết được nhiều hơn dự kiến | | Có đủ ví dụ chất lượng không | ⚠ điều kiện cho tuning | | Khối lượng có đủ lớn không | ⚠ để đầu tư ban đầu đáng giá |

Và lựa chọn giữa hai cách này thực chất là bài toán về quy mô: đào tạo con người rẻ khi đội nhỏ và nhu cầu còn thay đổi; tự động hoá đáng giá khi công việc đã ổn định và lặp lại đủ nhiều. Với một đội marketing vừa bắt đầu, bước thứ nhất gần như luôn là câu trả lời đúng.

Câu 174 Fundamentals of gen AI

An enterprise wants to streamline the development, deployment, and management of generative AI applications, including fine-tuned models. They seek a layer of the generative AI landscape that offers APIs, data management, and model deployment tools, simplifying infrastructure complexities and providing a unified environment.

Which core layer are they leveraging, and what is its main business implication?

  1. A

    Applications; its main implication is providing user-facing solutions that leverage AI capabilities.
  2. B

    Platforms; its main implication is simplifying AI development, deployment, and management, fostering scalability and agility.
  3. C

    Infrastructure; its main implication is providing raw computing power for model training.
  4. D

    Models; its main implication is offering access to pre-trained algorithms that can be adapted for tasks.
Xem giải thích

Đáp án

B — Platforms; ý nghĩa nghiệp vụ chính là đơn giản hoá việc phát triển, triển khai và quản lý AI, thúc đẩy khả năng mở rộng và tính linh hoạt.

Vì sao đúng

Doanh nghiệp cần lớp cung cấp API, quản lý dữ liệu và công cụ triển khai mô hình, che đi độ phức tạp hạ tầng và cho môi trường thống nhất. Đó chính là tầng Platforms.

⚠ Ánh xạ mô tả vào tầng:

"API, quản lý dữ liệu, công cụ
 triển khai mô hình"
    → ⚠ bộ công cụ để XÂY

"che đi độ phức tạp HẠ TẦNG"
    → ⚠ nằm TRÊN tầng hạ tầng

"môi trường THỐNG NHẤT"
    → ⚠ một nơi cho cả vòng đời
        ↓
    → ⚠ PLATFORMS

⚠ Bốn tầng — nhắc lại:

⚠ INFRASTRUCTURE
    → TPU, GPU, mạng, lưu trữ

⚠ MODELS
    → Gemini, Imagen, Gemma

⚠ PLATFORMS
    → ⚠ Vertex AI — ĐỀ NÀY

⚠ APPLICATIONS
    → thứ người dùng cuối dùng

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

"Infrastructure — cung cấp sức
 mạnh tính toán thô"
    → ⚠ đó là tầng DƯỚI mà platform
      đang che đi

"Models — cho truy cập thuật toán
 huấn luyện sẵn"
    → ⚠ bản thân mô hình, không phải
      công cụ quản lý

"Applications — giải pháp cho
 người dùng cuối"
    → ⚠ tầng TRÊN

⚠ Đối chiếu #13878 (Application, lô 145), #13899 (Models, lô 145), #13948 (Infrastructure, lô 146). Bốn đề cùng khung bốn tầng, mỗi đề một tầng. KHÔNG mâu thuẫn — luôn đọc kỹ đề hỏi về thành phần nào.

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

  • C (Infrastructure) — phương án gần nhất và là bẫy chính: đề có nhắc tới hạ tầng. Nhưng nhắc để nói rằng platform che đi độ phức tạp đó — tức platform nằm ở trên.

  • D và A — nằm ở tầng khác.

Ghi nhớ

⚠ Bốn tầng và ý nghĩa nghiệp vụ — bảng phải thuộc: | Tầng | Ví dụ | Ý nghĩa nghiệp vụ | |---|---|---| | Infrastructure | ⚠ TPU, GPU | ⚠ sức mạnh tính toán | | Models | ⚠ Gemini, Imagen | ⚠ năng lực AI dùng được ngay | | ⚠ Platforms | ⚠ Vertex AI | ⚠ đơn giản hoá phát triển và vận hành | | Applications | ⚠ app của bạn | ⚠ giá trị tới người dùng cuối |

Từ khoá nhận diện:

"API, công cụ, môi trường thống nhất" → ⚠ Platforms "chip, mạng, lưu trữ" → Infrastructure "mô hình huấn luyện sẵn" → Models "người dùng cuối tương tác" → Applications

⚠ Platform cung cấp gì trong thực tế Thành phần
⚠ API gọi mô hình
⚠ Quản lý dữ liệu và đặc trưng ⚠ Feature Store
⚠ Huấn luyện và tinh chỉnh có quản lý
⚠ Triển khai và phục vụ ⚠ endpoint, batch
Quản phiên bản ⚠ Model Registry
⚠ Giám sát ⚠ Model Monitoring
Tự động hoá ⚠ Pipelines
Bảo mật và quản trị ⚠ IAM, audit, VPC-SC
⚠ Vì sao doanh nghiệp chọn tầng platform Lý do
⚠ Không phải tự dựng hạ tầng
⚠ Không phải tự huấn luyện mô hình nền
⚠ Nhưng VẪN kiểm soát được ⚠ dữ liệu, quy trình, quản trị
Một môi trường cho cả đội ⚠ thay vì mỗi người một cách
⚠ Từ thí nghiệm tới sản xuất không phải viết lại
⚠ Ranh giới giữa platform và application Ranh giới
⚠ Platform: công cụ để XÂY ⚠ đội kỹ thuật dùng
⚠ Application: thứ ĐƯỢC XÂY ⚠ người dùng cuối dùng
Ví dụ ⚠ Vertex AI là platform, chatbot bạn dựng trên đó là application
Lưu ý ⚠ ứng dụng Gemini là APPLICATION, dù do Google làm

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Ai là người dùng: đội kỹ thuật hay người dùng cuối | ⚠ platform vs application | | Nó là công cụ hay bản thân mô hình | ⚠ platform vs model | | Có nhắc tới chip, mạng không | ⚠ infrastructure |

Và cách phân tầng này hữu ích khi lập ngân sách: giá trị nghiệp vụ luôn xuất hiện ở tầng ứng dụng, còn chi phí thường tập trung ở tầng hạ tầng và mô hình. Tầng platform là nơi quyết định khoảng cách giữa hai đầu đó ngắn hay dài.

Câu 175 Google Cloud's gen AI offerings

A customer service director is implementing an AI agent that needs to:

  • connect to their CRM system to retrieve customer history, access their knowledge base for product information,

  • execute specific actions like creating support tickets, and

  • add new capabilities like language translation.

Which agent tooling capabilities correspond to these four business needs?

  1. A

    All four needs require the same type of agent tooling
  2. B

    Tools provide different capabilities - extensions connect to external systems like CRM, data stores access knowledge bases, functions execute specific actions like ticket creation, and custom integrations add capabilities like translation.
  3. C

    Functions for everything, since all involve executing tasks
  4. D

    Data stores for all information access, extensions for all external connections
Xem giải thích

Đáp án

B — Các công cụ cung cấp năng lực khác nhau: extensions kết nối hệ thống ngoài như CRM, data stores truy cập kho tri thức, functions thực thi hành động cụ thể như tạo phiếu hỗ trợ...

Vì sao đúng

Bốn nhu cầu của đề cần bốn loại năng lực khác nhau, không phải một loại công cụ duy nhất.

⚠ Bốn nhu cầu, bốn năng lực:

"kết nối CRM lấy lịch sử khách"
    → ⚠ EXTENSION / kết nối hệ
      thống ngoài

"truy cập kho tri thức sản phẩm"
    → ⚠ DATA STORE / grounding

"tạo phiếu hỗ trợ"
    → ⚠ FUNCTION — thực thi HÀNH ĐỘNG

"thêm năng lực dịch ngôn ngữ"
    → ⚠ mở rộng bằng công cụ/API mới

⚠ Phân biệt ĐỌC và LÀM:

⚠ DATA STORE — chỉ ĐỌC
    → tra tài liệu, chính sách
    → ⚠ agent dùng tự do được

⚠ EXTENSION / FUNCTION — có thể LÀM
    → gọi API hệ thống ngoài
    → ⚠ có thể GÂY THAY ĐỔI
    → ⚠ cần kiểm soát chặt

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

"Cả bốn cần CÙNG một loại công cụ"
    → ⚠ sai: bốn nhu cầu khác nhau

"Functions cho tất cả"
    → ⚠ tra tài liệu không cần function

"Data stores cho mọi truy cập thông
 tin, extensions cho mọi kết nối"
    → ⚠ bỏ sót phần THỰC THI hành động

Nhất quán với #13881 (lô 145) và #13938 (lô 146) về tool và function calling của agent. Đề này phân loại chi tiết hơn. Bổ sung nhau.

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

⚠ Phương án đúng trong bộ đề bị CẮT CỤT: kết thúc bằng dấu phẩy sau "functions execute specific actions like ticket creation," — phần nói về nhu cầu thứ tư (mở rộng năng lực dịch) đã bị mất. Đây là lỗi cắt chuỗi khi nhập dữ liệu. Ý của phương án vẫn đủ rõ để phân biệt với ba phương án còn lại. Khoá đáp án B vẫn ĐÚNG và được giữ nguyên.

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

  • D — phương án gần nhất và là bẫy tinh tế: nó phân biệt được data store và extension, nhưng gộp mọi thứ vào hai nhóm và bỏ sót phần thực thi hành động.

  • A và C — gộp tất cả vào một loại.

Ghi nhớ

⚠ Bộ công cụ của agent — bảng phải thuộc: | Loại | Việc | Rủi ro | |---|---|---| | ⚠ Data store / grounding | ⚠ ĐỌC tài liệu, kho tri thức | ⚠ thấp | | ⚠ Extension | ⚠ kết nối hệ thống ngoài | ⚠ tuỳ hệ thống | | ⚠ Function | ⚠ THỰC THI hành động cụ thể | ⚠ CAO — gây thay đổi | | Bộ nhớ | ⚠ lịch sử hội thoại | |

Từ khoá nhận diện:

"tra tài liệu, kho tri thức" → ⚠ data store / grounding "kết nối CRM, ERP, hệ thống ngoài" → ⚠ extension "tạo phiếu, đặt đơn, gửi email" → ⚠ function — HÀNH ĐỘNG "nhớ đã nói gì" → bộ nhớ hội thoại

⚠ Kiểm soát theo loại công cụ Kiểm soát
⚠ Chỉ ĐỌC → agent dùng tự do
⚠ GÂY THAY ĐỔI → cần xác nhận ⚠ tạo phiếu, đổi dữ liệu khách
⚠ Quyền TỐI THIỂU cho từng công cụ ⚠ đọc CRM ≠ sửa CRM
Ghi log mọi lời gọi
⚠ Giới hạn tần suất ⚠ chống vòng lặp
⚠ Agent chăm sóc khách — thiết kế theo mức rủi ro Mức
⚠ Tra lịch sử khách (đọc) ⚠ agent tự làm, sau khi xác thực
⚠ Tra thông tin sản phẩm (đọc) ⚠ agent tự làm
⚠ Tạo phiếu hỗ trợ (ghi) ⚠ rủi ro thấp, có thể tự làm
⚠ Hoàn tiền, huỷ dịch vụ (ghi) ⚠ PHẢI có người duyệt
Nguyên tắc ⚠ phân loại theo mức đảo ngược được hay không
⚠ Xác thực trước khi tra CRM Điểm
⚠ BẮT BUỘC xác thực khách hàng ⚠ dữ liệu cá nhân
⚠ Chỉ tra dữ liệu của CHÍNH khách đó
Không đọc thông tin nhạy cảm ra ⚠ số thẻ, mật khẩu
Ghi log truy cập ⚠ cho kiểm toán
⚠ "Thêm năng lực mới" — vì sao dễ Lý do
⚠ Agent thiết kế tốt cho phép THÊM công cụ ⚠ không phải xây lại
Khai báo công cụ mới, mô tả khi nào dùng
⚠ Mô hình tự quyết khi nào gọi
Đó là ⚠ ưu điểm lớn của kiến trúc agent

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Công cụ nào chỉ đọc, công cụ nào ghi | ⚠ phân loại và siết quyền riêng | | Có xác thực trước khi tra CRM không | ⚠ bắt buộc | | Hành động nào cần người duyệt | ⚠ quyết định trước khi triển khai |

Và cách phân loại công cụ hữu ích nhất khi thiết kế agent không phải theo tên kỹ thuật, mà theo câu hỏi: công cụ này chỉ đọc hay có thể thay đổi thứ gì đó? Nhóm thứ nhất càng nhiều càng tốt; nhóm thứ hai nên ít, được liệt kê rõ và đi qua kiểm soát.

Câu 176 Techniques to improve gen AI model output

A contact center manager wants to understand the primary reasons for customer dissatisfaction without manually listening to thousands of call recordings. They need a tool to automatically analyze call transcripts at scale to identify key topics, detect negative sentiment, and find emerging trends in customer complaints.

Which Google Cloud offering is specifically designed for this post-call analysis?

  1. A

    Agent Assist
  2. B

    Customer Experience Insights (CX Insights)
  3. C

    Conversational Agents
  4. D

    Vertex AI Pipelines
Xem giải thích

Đáp án

B — Customer Experience Insights (CX Insights).

Vì sao đúng

Quản lý tổng đài muốn phân tích tự động hàng nghìn bản ghi cuộc gọi ở quy mô lớn để tìm chủ đề chính, phát hiện cảm xúc tiêu cực và xu hướng khiếu nại mới nổi — mà không phải nghe từng cuộc. Đó là phân tích sau cuộc gọi.

⚠ Ba nhu cầu đều là phân tích tổng hợp:

"tìm CHỦ ĐỀ chính"
    → ⚠ gom nhóm qua nhiều cuộc gọi

"phát hiện CẢM XÚC tiêu cực"
    → ⚠ sentiment ở quy mô

"XU HƯỚNG khiếu nại MỚI NỔI"
    → ⚠ so sánh theo thời gian
        ↓
    ⚠ Tất cả diễn ra SAU cuộc gọi,
      phục vụ QUẢN LÝ

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

"Agent Assist"
    → ⚠ hỗ trợ nhân viên TRONG
      cuộc gọi, thời gian thực

"Conversational Agents"
    → ⚠ bot nói chuyện với khách

"Vertex AI Pipelines"
    → ⚠ tự động hoá quy trình MLOps

⚠ Gần trùng với #13993 (lô 147) — đề đó gần như cùng tình huống và cùng khoá CX Insights. Hoàn toàn nhất quán. Và #13971 (lô 147) khoá Agent Assist cho thời gian thực, #14007 (cùng lô) khoá Conversational Agents cho bot khách hàng.

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

  • A (Agent Assist) — phương án gần nhất và là bẫy chính: cùng bộ giải pháp, cùng làm việc với dữ liệu hội thoại. Nhưng nó chạy thời gian thực cho nhân viên, còn đây là phân tích tổng hợp cho quản lý.

  • C và D — sai đối tượng hoặc sai lĩnh vực.

Ghi nhớ

⚠ Bộ ba chăm sóc khách hàng — bảng phải thuộc: | Thành phần | Ai dùng | Khi nào | |---|---|---| | Conversational Agents | ⚠ khách hàng | trong cuộc gọi | | Agent Assist | ⚠ nhân viên | ⚠ thời gian thực | | ⚠ CX Insights | ⚠ QUẢN LÝ | ⚠ SAU cuộc gọi — đề này | | CCaaS | ⚠ nền tảng | hạ tầng |

Từ khoá nhận diện:

"phân tích bản ghi ở quy mô, tìm xu hướng" → ⚠ CX Insights "gợi ý cho nhân viên đang nghe máy" → Agent Assist "bot trả lời khách" → Conversational Agents "tự động hoá quy trình ML" → Pipelines

⚠ CX Insights hoạt động ra sao Bước
⚠ Chuyển giọng nói thành văn bản ⚠ Speech-to-Text
⚠ Phân tích cảm xúc và chủ đề
⚠ Gom nhóm cuộc gọi theo chủ đề
Theo dõi theo thời gian ⚠ phát hiện xu hướng mới nổi
⚠ Kiểm tra tuân thủ kịch bản
Đưa lên dashboard
⚠ "Xu hướng MỚI NỔI" — giá trị lớn nhất Điểm
⚠ Phát hiện vấn đề TRƯỚC khi nó lan rộng
Ví dụ ⚠ khiếu nại về một tính năng vừa cập nhật
⚠ Cảnh báo sớm cho đội sản phẩm
Nhanh hơn nhiều so với báo cáo hằng tháng
Nên ⚠ đặt cảnh báo khi một chủ đề tăng đột biến
⚠ Danh sách chủ đề = danh sách việc cần sửa Điểm
⚠ Khách gọi vì SẢN PHẨM gây khó
⚠ Sửa ở sản phẩm làm GIẢM cuộc gọi ⚠ hiệu quả hơn cải tiến khâu trả lời
Gửi báo cáo cho đội sản phẩm ⚠ không chỉ cho tổng đài
Đây là ⚠ giá trị bị bỏ lỡ nhiều nhất
⚠ Quyền riêng tư khi phân tích bản ghi Điểm
⚠ Thông báo về việc ghi âm ⚠ quy định pháp luật
⚠ Che PII trong bản ghi ⚠ Sensitive Data Protection
Kiểm soát ai xem được
⚠ Dùng để ĐÀO TẠO, không phải để phạt ⚠ khi đo tuân thủ kịch bản
Chính sách lưu giữ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chủ đề nào tăng mạnh nhất | ⚠ gửi cả cho đội sản phẩm | | PII đã che chưa | ⚠ trước khi chia sẻ báo cáo | | Có cảnh báo khi chủ đề tăng đột biến chưa | ⚠ giá trị lớn nhất |

Và cách khai thác kết quả phân tích hội thoại hiệu quả nhất: gửi danh sách chủ đề khiếu nại hàng đầu cho đội sản phẩm, không chỉ cho quản lý tổng đài. Cuộc gọi giảm bền vững nhất khi nguyên nhân được sửa ở nơi nó phát sinh.

Câu 177 Google Cloud's gen AI offerings

A media company wants to make its large video archive easily searchable. Their goal is to automatically generate metadata by identifying objects, text, and spoken words within the video files, enabling content creators to quickly find relevant clips.

Which pre-built AI API is designed for this video analysis task?

  1. A

    Video Intelligence API
  2. B

    Speech-to-Text API
  3. C

    Cloud Vision API
  4. D

    Vertex AI Search
Xem giải thích

Đáp án

A — Video Intelligence API.

Vì sao đúng

Công ty muốn tự động sinh metadata cho kho video bằng cách nhận diện vật thể, chữ và lời nói trong tệp video, để người sáng tạo nội dung tìm nhanh đoạn cần. Đó là Video Intelligence API.

⚠ Ba loại nhận diện, một API:

"nhận diện VẬT THỂ"
    → ⚠ label detection, object tracking

"nhận diện CHỮ"
    → ⚠ OCR trong video

"nhận diện LỜI NÓI"
    → ⚠ speech transcription
        ↓
    ⚠ Video Intelligence API làm
      được CẢ BA
    ⚠ và gắn MỐC THỜI GIAN

⚠ Vì sao mốc thời gian là điểm mấu chốt:

Kho video lớn
        ↓
    ⚠ Cần biết cảnh nào Ở PHÚT MẤY
        ↓
    ⚠ Video Intelligence trả về
      nhãn KÈM khoảng thời gian
        ↓
    → tìm được ĐÚNG ĐOẠN, không
      phải cả video

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

"Cloud Vision API"
    → ⚠ ẢNH TĨNH; xử lý video phải
      tự tách khung — tốn công và
      mất thông tin thời gian

"Speech-to-Text API"
    → ⚠ CHỈ lời nói, bỏ qua hình ảnh

"Vertex AI Search"
    → ⚠ TÌM KIẾM; cần metadata
      trước đã — đó là việc phải
      làm ở bước này

⚠ Gần trùng với #14014 (cùng lô) — đề đó hỏi LOẠI năng lực cần cho phân tích video, đề này hỏi API cụ thể. Bổ sung nhau, hoàn toàn nhất quán.

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

  • D (Vertex AI Search) — phương án gần nhất và là bẫy tinh tế: mục tiêu cuối cùng đúng là tìm kiếm được. Nhưng phải sinh metadata trước, và đó là việc của Video Intelligence.

  • C và B — chỉ xử lý một phần.

Ghi nhớ

⚠ API theo loại dữ liệu — bảng phải thuộc: | Đầu vào | API | |---|---| | Ảnh tĩnh | ⚠ Vision API | | ⚠ Video | ⚠ Video Intelligence API | | Âm thanh | Speech-to-Text | | Văn bản | Natural Language | | Tài liệu | Document AI | | ⚠ Tìm kiếm sau khi có metadata | ⚠ Vertex AI Search |

Từ khoá nhận diện:

"nhận diện trong video, sinh metadata" → ⚠ Video Intelligence "ảnh tĩnh" → Vision API "tìm kiếm sau khi đã có metadata" → ⚠ Vertex AI Search "nhãn riêng của ngành" → ⚠ AutoML Video

⚠ Video Intelligence trả về gì Kết quả
⚠ Nhãn KÈM mốc thời gian ⚠ điểm quan trọng nhất
Phát hiện chuyển cảnh ⚠ chia video thành phân đoạn
Theo dõi vật thể qua khung hình
⚠ OCR chữ trong video ⚠ biển hiệu, phụ đề cháy
⚠ Phiên âm lời nói
Nhận diện logo, người, hành động
Kiểm duyệt nội dung
⚠ Kiến trúc đầy đủ cho kho video tìm kiếm được Bước
⚠ 1. Video Intelligence sinh metadata ⚠ nhãn, chữ, lời nói + mốc thời gian
2. Lưu metadata vào BigQuery
⚠ 3. Vertex AI Search trên metadata đó ⚠ tìm kiếm ngữ nghĩa
4. Giao diện trả về đúng đoạn ⚠ nhảy tới phút cần xem
Kết quả ⚠ kho video từ "không tìm nổi" thành tra cứu được
⚠ Chi phí và quy mô Điểm
⚠ Tính theo PHÚT video và theo tính năng
⚠ Kho lớn thì chi phí ban đầu đáng kể ⚠ tính trước
Chỉ bật tính năng thật sự cần ⚠ mỗi tính năng tính riêng
⚠ Xử lý theo LÔ ⚠ rẻ hơn và hợp với kho lưu trữ
Sau lần đầu ⚠ chỉ xử lý video mới
⚠ Nhãn phổ quát và nhãn riêng Phân biệt
⚠ Nhãn CHUNG ⚠ Video Intelligence đủ
⚠ Nhãn RIÊNG của ngành ⚠ cần AutoML Video
Ví dụ ⚠ "xe hơi" là chung; "mẫu xe X của hãng Y" là riêng
Với kho tin tức, giải trí ⚠ nhãn chung thường đủ để bắt đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhãn có đủ chi tiết không | ⚠ thử với video thật của kho | | Chi phí xử lý toàn kho | ⚠ số phút × tính năng bật | | Metadata có tìm kiếm được không | ⚠ cần lớp tìm kiếm bên trên |

Và điều biến một kho video từ chỗ không ai dùng được thành tài sản thật sự: metadata có gắn mốc thời gian. Biết một cảnh tồn tại trong kho vẫn chưa đủ — người dựng cần nhảy thẳng tới đúng giây thứ bao nhiêu của tệp nào.

Câu 178 Google Cloud's gen AI offerings

A legal tech company wants to build a custom e-discovery application that integrates grounded reasoning over legal documents. They want their application to programmatically create and manage spaces, upload source documents, and run queries against them without using the standard web interface.

Which Google Cloud offering would provide the necessary API for this programmatic control?

  1. A

    The Gemini API
  2. B

    Cloud NotebookLM API
  3. C

    Vertex AI Search API
  4. D

    Document AI API
Xem giải thích

Đáp án

C — Vertex AI Search API.

Vì sao đúng

Công ty muốn điều khiển BẰNG CHƯƠNG TRÌNH: tạo và quản lý không gian dữ liệu, tải tài liệu nguồn lên, chạy truy vấn — không qua giao diện web. Đó là API của Vertex AI Search.

⚠ Ba dữ kiện khớp:

"tích hợp SUY LUẬN CÓ CĂN CỨ
 trên tài liệu pháp lý"
    → ⚠ grounding vào kho tài liệu

"tạo và quản lý không gian, tải
 tài liệu, chạy truy vấn"
    → ⚠ các thao tác của Vertex AI Search

"KHÔNG dùng giao diện web tiêu chuẩn"
    → ⚠ cần API để nhúng vào
      ứng dụng riêng

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

"Gemini API"
    → ⚠ gọi MÔ HÌNH; ⚠ KHÔNG có
      sẵn quản lý kho tài liệu và
      truy xuất — phải tự dựng RAG

"Document AI API"
    → ⚠ TRÍCH TRƯỜNG từ tài liệu
      (hoá đơn, biểu mẫu), không
      phải hỏi đáp có căn cứ

"Cloud NotebookLM API"
    → ⚠ NotebookLM là sản phẩm
      GIAO DIỆN WEB; không có API
      mang tên này trong danh mục
      Google Cloud

Nhất quán với #13954 (lô 146), #14027 (cùng lô) về Vertex AI Search. Đề này nhấn điều khiển bằng chương trình. Bổ sung nhau.

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

⚠ Phương án nhiễu "Cloud NotebookLM API" đặt ra một sản phẩm không tồn tại trong danh mục Google Cloud dưới tên đó. NotebookLM là công cụ có giao diện web cho nghiên cứu trên tài liệu người dùng nạp. Đây là phương án nhiễu được bịa ra, một kỹ thuật ra đề hợp lệ — nhưng người học nên biết để không đi tìm sản phẩm đó. Khoá đáp án C giữ nguyên.

⚠ Ghi nhớ chung: phương án nhắc tới một sản phẩm nghe hợp lý nhưng bạn chưa từng thấy trong tài liệu chính thức thường là phương án bịa.

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

  • A (Gemini API) — phương án gần nhất và là bẫy mạnh: nó làm được nếu tự dựng toàn bộ chuỗi RAG. Nhưng đề nêu rõ các thao tác quản lý kho tài liệu và truy vấn, vốn là dịch vụ có sẵn của Vertex AI Search.

  • D và B — sai chức năng hoặc không tồn tại.

Ghi nhớ

⚠ API cho ứng dụng có grounding — bảng phải thuộc: | Nhu cầu | API | |---|---| | ⚠ Quản kho tài liệu + hỏi đáp có căn cứ | ⚠ Vertex AI Search API | | Gọi mô hình, tự dựng RAG | ⚠ Gemini API | | Trích trường từ tài liệu | ⚠ Document AI API | | Agent có công cụ | ⚠ Agent Builder API | | Nghiên cứu trên tài liệu tự nạp | ⚠ NotebookLM — giao diện web |

Từ khoá nhận diện:

"quản kho tài liệu + truy vấn bằng chương trình" → ⚠ Vertex AI Search API "gọi mô hình sinh" → Gemini API "trích hoá đơn, biểu mẫu" → Document AI "agent gọi công cụ" → Agent Builder

⚠ Tự dựng RAG hay dùng dịch vụ sẵn Cân nhắc
⚠ Dịch vụ sẵn ⚠ nhanh, ít phải bảo trì
⚠ chia đoạn, embedding, tìm kiếm đã có
⚠ Tự dựng với Gemini API ⚠ kiểm soát cao nhất
⚠ nhưng phải tự lo vector DB, chunking, xếp hạng
Với e-discovery ⚠ dịch vụ sẵn thường đủ và nhanh hơn nhiều
⚠ E-discovery — yêu cầu đặc thù Yêu cầu
⚠ TRÍCH DẪN chính xác tới tài liệu và trang ⚠ bắt buộc cho pháp lý
⚠ Phân vùng theo VỤ VIỆC ⚠ không lẫn tài liệu giữa các vụ
⚠ Audit log đầy đủ ⚠ ai truy vấn gì, khi nào
Bảo mật rất cao ⚠ tài liệu tố tụng nhạy cảm
⚠ Không bịa án lệ ⚠ rủi ro đã có tiền lệ chế tài
Xử lý khối lượng lớn ⚠ hàng trăm nghìn tài liệu
⚠ Vì sao cần API chứ không phải giao diện Lý do
⚠ Nhúng vào quy trình sẵn có của hãng luật
⚠ Tự động hoá tạo không gian cho mỗi vụ
Kiểm soát quyền theo hệ thống nội bộ
⚠ Ghi log theo chuẩn riêng
Tích hợp với hệ thống quản lý vụ việc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trích dẫn có chính xác tới trang không | ⚠ bắt buộc với pháp lý | | Tài liệu giữa các vụ có bị lẫn không | ⚠ kiểm phân vùng | | Audit log có đủ để giải trình không | ⚠ cho toà và cho khách hàng |

Và mẹo làm bài đáng nhớ từ câu này: một phương án nhắc tới sản phẩm nghe rất hợp lý nhưng bạn chưa từng gặp trong tài liệu chính thức thường là phương án bịa. Danh mục dịch vụ đám mây có thể đổi tên, nhưng những sản phẩm quan trọng đều xuất hiện trong tài liệu — nếu không nhớ nổi, khả năng cao là nó không tồn tại.

Câu 179 Business strategies for a successful gen AI solution

A generative AI model that provides financial advice has been deployed and is operating normally. Suddenly, the security team is alerted to an abnormally high volume of requests to the model's API endpoint, all originating from a single, unfamiliar IP address. This could indicate a malicious actor attempting a denial-of-service or model inversion attack.

Which type of tool is primarily responsible for detecting such anomalous operational behavior?

  1. A

    A static code analyzer
  2. B

    Model bias detection tools
  3. C

    Data anonymization tools
  4. D

    Workload monitoring and logging tools
Xem giải thích

Đáp án

D — Công cụ giám sát và ghi log khối lượng công việc (workload monitoring and logging tools).

Vì sao đúng

Dấu hiệu là lưu lượng bất thường tới endpoint API, từ một địa chỉ IP lạ. Phát hiện hành vi vận hành bất thường là việc của công cụ giám sát và ghi log.

⚠ Vì sao là giám sát vận hành:

"lượng yêu cầu BẤT THƯỜNG CAO"
    → ⚠ chỉ số vận hành

"từ MỘT địa chỉ IP LẠ"
    → ⚠ thông tin trong LOG

"có thể là DoS hoặc model inversion"
    → ⚠ phát hiện qua MẪU HÌNH
      truy cập, không phải qua
      nội dung mô hình
        ↓
    → ⚠ giám sát + ghi log

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

"Static code analyzer"
    → ⚠ quét MÃ NGUỒN tìm lỗi;
      không thấy hành vi lúc chạy

"Model bias detection tools"
    → ⚠ phát hiện THIÊN VỊ trong
      kết quả; vấn đề khác

"Data anonymization tools"
    → ⚠ che PII trong dữ liệu

Nhất quán với #14008 (cùng lô) về Security Command Center — SCC phát hiện cấu hình sai và mối đe doạ, còn giám sát vận hành phát hiện hành vi bất thường theo thời gian thực. Bổ sung nhau. Và #13964 (lô 147) về model theft/extraction.

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

  • B (công cụ phát hiện thiên vị) — phương án gần nhất về mặt "cũng là công cụ giám sát mô hình", nhưng nó đo chất lượng và công bằng của kết quả, không phát hiện được mẫu hình truy cập bất thường.

  • A và C — thuộc khâu phát triển và xử lý dữ liệu.

Ghi nhớ

⚠ Công cụ theo loại vấn đề — bảng phải thuộc: | Vấn đề | Công cụ | |---|---| | ⚠ Hành vi vận hành bất thường | ⚠ giám sát + log | | Cấu hình sai trên toàn tổ chức | ⚠ Security Command Center | | Thiên vị trong kết quả | ⚠ công cụ đánh giá công bằng | | Lỗ hổng trong mã | ⚠ static analyzer | | PII trong dữ liệu | ⚠ Sensitive Data Protection | | Drift của mô hình | ⚠ Model Monitoring |

Từ khoá nhận diện:

"lưu lượng bất thường, IP lạ" → ⚠ giám sát vận hành + log "bucket công khai, IAM quá rộng" → Security Command Center "kết quả lệch giữa các nhóm" → công cụ đo fairness "phân phối dữ liệu đầu vào đổi" → Model Monitoring

⚠ Hai tấn công đề nhắc tới Tấn công
⚠ DoS ⚠ làm dịch vụ quá tải, không phục vụ được
⚠ Model inversion ⚠ gọi rất nhiều lần để suy ngược
⚠ dữ liệu huấn luyện hoặc chính mô hình
Điểm chung ⚠ cả hai đều lộ ra qua MẪU HÌNH truy cập
⚠ Chỉ số cần giám sát cho endpoint mô hình Chỉ số
⚠ Số yêu cầu theo thời gian ⚠ và theo nguồn
⚠ Phân bố theo IP và tài khoản ⚠ một nguồn chiếm đa số là dấu hiệu
Độ trễ và tỉ lệ lỗi ⚠ bốn tín hiệu vàng vẫn áp dụng
⚠ Mẫu hình truy vấn ⚠ truy vấn có hệ thống, phủ đều = dò ngược
Chi phí bất thường ⚠ tín hiệu sớm rất hiệu quả
⚠ Biện pháp phòng thủ Biện pháp
⚠ Giới hạn tần suất theo tài khoản và IP ⚠ quan trọng nhất
⚠ Xác thực bắt buộc mọi lời gọi ⚠ không để endpoint công khai
⚠ Không trả điểm số chi tiết ⚠ chỉ trả kết quả — khó dò ngược hơn
Cloud Armor chặn IP đáng ngờ
⚠ Cảnh báo tự động khi vượt ngưỡng
Quota chi phí ⚠ hàng rào cuối
⚠ Vì sao chi phí là tín hiệu bảo mật tốt Lý do
⚠ Tấn công dò ngược cần RẤT NHIỀU lời gọi
⚠ Chi phí tăng vọt trước khi ai kịp nhận ra
Cảnh báo ngân sách bắt được sớm
Mẹo ⚠ đặt cảnh báo chi phí bất thường cho endpoint mô hình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint có giới hạn tần suất chưa | ⚠ bắt buộc | | Ai nhận cảnh báo lưu lượng bất thường | ⚠ và phản ứng ra sao | | Có cảnh báo chi phí không | ⚠ tín hiệu sớm rất hiệu quả |

Và một cảnh báo rẻ tiền mà hiệu quả bất ngờ cho các endpoint mô hình: cảnh báo khi chi phí trong ngày vượt ngưỡng thông thường. Phần lớn các kiểu lạm dụng — từ dò ngược mô hình tới vòng lặp gọi nhầm — đều lộ ra ở hoá đơn trước khi lộ ra ở bất cứ đâu khác.

Câu 180 Techniques to improve gen AI model output

An e-commerce company uses AI to generate product descriptions. Their brand manager notices that some descriptions are too short for detailed products while others exceed their website's character limits, causing display issues.

Which parameter adjustment would best address this formatting consistency challenge?

  1. A

    Using few-shot prompting with multiple product examples
  2. B

    Implementing stricter safety settings to filter inappropriate content
  3. C

    Setting maximum output length limits to ensure consistent formatting
  4. D

    Increasing temperature to create more varied description styles
Xem giải thích

Đáp án

C — Đặt giới hạn độ dài đầu ra tối đa để đảm bảo định dạng nhất quán.

Vì sao đúng

Vấn đề là độ dài không nhất quán: có mô tả quá ngắn, có mô tả vượt giới hạn ký tự của website gây lỗi hiển thị. Tham số kiểm soát trực tiếp điều đó là max output tokens.

⚠ Vì sao là tham số độ dài:

"vượt GIỚI HẠN KÝ TỰ của website"
    → ⚠ vấn đề KỸ THUẬT về độ dài
    → ⚠ gây lỗi hiển thị
        ↓
    ⚠ Cần HÀNG RÀO CỨNG
    → ⚠ max output tokens
        ↓
    → đảm bảo KHÔNG BAO GIỜ vượt

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

"Few-shot với nhiều ví dụ sản phẩm"
    → ⚠ giúp định hình phong cách,
      nhưng ⚠ KHÔNG đảm bảo cứng
      về độ dài

"Cài đặt an toàn chặt hơn"
    → ⚠ lọc nội dung CÓ HẠI,
      không liên quan độ dài

"TĂNG temperature cho phong cách
 đa dạng hơn"
    → ⚠ NGƯỢC: làm độ dài càng
      KHÔNG nhất quán

⚠ Đối chiếu #13876 và #13890 (lô 145) — hai đề đó về temperature, kiểm soát độ sáng tạo. Đề này về max output tokens, kiểm soát kích thước. Không mâu thuẫn — hai nhóm tham số khác nhau.

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

  • A (few-shot) — phương án gần nhất và là bẫy hợp lý: ví dụ mẫu thật sự giúp mô hình viết độ dài tương tự. Nhưng đó là định hướng mềm, không phải hàng rào cứng; vẫn có thể vượt giới hạn website.

  • B và D — không giải quyết vấn đề, D còn làm tệ hơn.

Ghi nhớ

⚠ Ba nhóm tham số — bảng phải thuộc: | Nhóm | Tham số | Kiểm soát | |---|---|---| | ⚠ Kích thước | ⚠ max output tokens | ⚠ ĐỘ DÀI — đề này | | Phong cách | ⚠ temperature, top-p, top-k | ⚠ độ sáng tạo | | An toàn | ⚠ safety settings | ⚠ nội dung có hại |

Từ khoá nhận diện:

"vượt giới hạn ký tự, độ dài không đều" → ⚠ max output tokens "sáng tạo hay xác định" → temperature "chặn nội dung có hại" → safety settings "định dạng và cấu trúc" → ⚠ prompt + few-shot

⚠ Cách làm đầy đủ cho bài toán này Cách
⚠ Max output tokens ⚠ hàng rào CỨNG
⚠ Nêu rõ độ dài TRONG PROMPT ⚠ "khoảng 80–120 từ"
⚠ Few-shot với mô tả mẫu đúng độ dài ⚠ định hướng mềm
⚠ Kiểm tra độ dài Ở TẦNG ỨNG DỤNG ⚠ hàng rào cuối cùng
Kết hợp cả bốn ⚠ mới đảm bảo chắc chắn
⚠ Cạm bẫy của max output tokens Cạm bẫy
⚠ Cắt GIỮA CHỪNG câu ⚠ đầu ra bị đứt, trông rất tệ
⚠ Token KHÔNG bằng ký tự ⚠ tiếng Việt tốn token hơn tiếng Anh
Đặt quá thấp thì mất nội dung
Cách chữa ⚠ đặt ngưỡng token rộng hơn giới hạn ký tự một chút
Và ⚠ yêu cầu trong prompt kết thúc trọn câu
⚠ Vì sao kiểm tra ở tầng ứng dụng vẫn cần Lý do
⚠ Không tham số nào đảm bảo TUYỆT ĐỐI
⚠ Website có giới hạn cứng ⚠ vượt là lỗi hiển thị
Cần xử lý khi vượt ⚠ cắt gọn, sinh lại, hay báo lỗi
Nguyên tắc ⚠ đừng tin đầu ra của mô hình luôn đúng định dạng
⚠ Sinh mô tả sản phẩm — lưu ý thêm Lưu ý
⚠ Grounding vào THÔNG SỐ THẬT ⚠ để không bịa tính năng
Giữ giọng thương hiệu ⚠ few-shot hoặc fine-tuning
⚠ Người duyệt trước khi đăng
Kiểm trùng lặp giữa các sản phẩm ⚠ mô tả na ná nhau
⚠ Cân nhắc SEO ⚠ độ dài và từ khoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có mô tả nào bị cắt giữa câu không | ⚠ kiểm mẫu | | Độ dài có ổn định không | ⚠ đo phân bố độ dài | | Ứng dụng có kiểm tra độ dài không | ⚠ hàng rào cuối cùng |

Và điều nên nhớ khi dùng giới hạn độ dài cứng: mô hình không biết nó sắp bị cắt. Nó viết bình thường rồi bị dừng giữa chừng — nên phần chỉ dẫn trong prompt về độ dài mong muốn quan trọng không kém tham số kỹ thuật.