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

Đáp án

D — Google Vids.

Vì sao đúng

Quản lý dự án cần một công cụ có AI NGAY TRONG Workspace để dựng storyboard video từ tài liệu sẵn có, gợi ý cảnh quay và tạo lời đọc từ kịch bản. Đó là Google Vids.

⚠ Ba dữ kiện khớp:

"TRONG workspace của cô ấy"
    → ⚠ tích hợp Docs, Sheets, Slides

"tự động dựng STORYBOARD từ
 tài liệu"
    → ⚠ đọc nội dung sẵn có

"gợi ý cảnh quay, TẠO LỜI ĐỌC
 từ kịch bản"
    → ⚠ text-to-speech tích hợp

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

"Google Slides có nhúng video"
    → ⚠ trình chiếu, không dựng video

"Bản ghi Google Meet"
    → ⚠ ghi lại cuộc họp, không sáng tạo

"Gemini trong Google Drive"
    → ⚠ hỏi đáp và tóm tắt tài liệu,
      không dựng video

Nhất quán với #13883 (lô 145) về Gemini for Workspace — cùng triết lý: AI ngay trong công cụ đang dùng. Google Vids là thành viên của bộ Workspace.

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

• C (Gemini trong Drive) — phương án gần nhất và là bẫy chính: nó thật sự đọc được tài liệu trong Drive. Nhưng nó trả lời bằng văn bản, không tạo ra video.

• A và B — không phải công cụ sáng tạo video.

Ghi nhớ

⚠ Bộ Workspace có AI — bảng nên thuộc: | Công cụ | Việc | |---|---| | ⚠ Google Vids | ⚠ dựng VIDEO có AI hỗ trợ | | Docs, Slides | ⚠ Gemini viết nháp, tóm tắt | | Sheets | ⚠ Gemini tạo bảng, phân loại | | Gmail | ⚠ soạn thư, tóm tắt luồng | | Meet | ⚠ tóm tắt cuộc họp, ghi chú | | Drive | ⚠ hỏi đáp trên tài liệu |

Từ khoá nhận diện:

"dựng video từ tài liệu, có AI" → ⚠ Google Vids "hỏi đáp trên tài liệu Drive" → Gemini in Drive "sinh video từ mô tả văn bản" → ⚠ Veo — mô hình, khác cấp "dựng ứng dụng không viết mã" → AppSheet

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số liệu trong video có đúng không | ⚠ đối chiếu Sheets gốc | | Tên riêng có phát âm đúng không | ⚠ nghe lại toàn bộ | | Ai được xem video này | ⚠ kiểm quyền chia sẻ |

Và ưu điểm thật của việc dựng video ngay trong bộ công cụ đang dùng: số liệu không phải gõ lại. Mỗi lần chép tay một con số từ bảng tính sang bản trình bày là một cơ hội để sai — và với báo cáo gửi lãnh đạo, đó là loại lỗi đắt nhất.

Đáp án

C — AppSheet, nền tảng phát triển ứng dụng no-code có tính năng AI.

Vì sao đúng

Quản lý bộ phận không biết lập trình, cần ứng dụng di động theo dõi cột mốc và phân công, tích hợp với Google Workspace, và tự sinh báo cáo trạng thái. AppSheet đáp ứng đủ.

⚠ Bốn dữ kiện khớp:

"KHÔNG có kinh nghiệm lập trình"
    → ⚠ NO-CODE

"ứng dụng DI ĐỘNG"
    → ⚠ AppSheet sinh app cho cả
      di động và web

"tích hợp với Google Workspace"
    → ⚠ nguồn dữ liệu Sheets, Drive

"tự sinh BÁO CÁO trạng thái"
    → ⚠ AppSheet Automation

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

"Cloud Run functions"
    → ⚠ chạy MÃ — đòi lập trình

"Vertex AI Studio"
    → ⚠ phát triển mô hình cho
      đội kỹ thuật

"Google AI Studio"
    → ⚠ thử PROMPT, không dựng
      ứng dụng có giao diện và CSDL

⚠ Gần trùng với #13987 (lô 147) — đề đó cũng là quản lý không biết lập trình muốn dựng app theo dõi công việc, cùng khoá AppSheet. Hoàn toàn nhất quán. Và #13924/#13869 về low-code/no-code.

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

• B (Google AI Studio) — phương án gần nhất và là bẫy chính: cũng dễ dùng, cũng có giao diện web. Nhưng nó để thử prompt, không tạo ra ứng dụng có dữ liệu và giao diện.

• A và D — đòi kỹ năng lập trình.

Ghi nhớ

⚠ Chọn công cụ theo mức kỹ năng — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | ⚠ Ứng dụng nghiệp vụ, không viết mã | ⚠ AppSheet | | Thử prompt, làm mẫu AI | ⚠ Google AI Studio | | Agent AI cho sản phẩm | ⚠ Agent Builder | | Ứng dụng tuỳ biến | ⚠ Cloud Run, App Engine | | Phát triển mô hình | ⚠ Vertex AI Studio |

Từ khoá nhận diện:

"không lập trình, app nghiệp vụ" → ⚠ AppSheet "thử prompt nhanh" → AI Studio "agent hội thoại" → Agent Builder "viết mã, container" → Cloud Run

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | App dùng dữ liệu gì, ai xem được | ⚠ rà quyền trước khi chia sẻ | | Ai bảo trì khi người dựng nghỉ | ⚠ rủi ro thật của no-code | | Dữ liệu nằm ở Sheets cá nhân hay tài khoản chung | ⚠ quyết định độ bền của app |

Và chi tiết nhỏ nhưng quyết định tuổi thọ của một ứng dụng no-code: dữ liệu nằm ở tài khoản cá nhân hay tài khoản dùng chung của bộ phận. App dựng trên bảng tính cá nhân sẽ biến mất cùng với người tạo ra nó vào ngày họ đổi việc.

Đáp án

D — Tái thiết kế transformer và cơ chế attention của mô hình nền trong MỖI chu kỳ huấn luyện để thử nghiệm lý thuyết AI mới.

Vì sao đúng

⚠ Đây là câu PHỦ ĐỊNH: hỏi việc KHÔNG thuộc quy trình MLOps chuẩn. Ba phương án kia đều là hoạt động MLOps kinh điển; phương án D là nghiên cứu, không phải vận hành.

⚠ Vì sao D không thuộc MLOps:

"Tái thiết kế transformer và
 attention mỗi chu kỳ huấn luyện"
        ↓
    ⚠ Đó là NGHIÊN CỨU cơ bản
    ⚠ Không phải vận hành sản xuất
        ↓
    ⚠ MLOps hướng tới ỔN ĐỊNH,
      LẶP LẠI ĐƯỢC, TỰ ĐỘNG HOÁ
        ↓
    ⚠ Đổi kiến trúc mỗi lần huấn
      luyện thì KHÔNG so sánh được
      giữa các phiên bản

⚠ Ba phương án kia đều LÀ MLOps:

⚠ A — Pipeline tự động huấn luyện
     lại khi phát hiện DRIFT
    → ⚠ MLOps chuẩn mực

⚠ B — Đánh phiên bản mô hình và
     chỉ số trong Model Registry
    → ⚠ nền tảng của MLOps

⚠ C — Triển khai CANARY qua
     Vertex AI Endpoints
    → ⚠ thực hành triển khai an toàn

Nhất quán với #13911 (lô 146), #13976/#13982 (lô 147) về Model Management, Registry và Monitoring. Bổ sung nhau.

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

⚠ Câu PHỦ ĐỊNH — hỏi cái KHÔNG đúng. Mẹo làm:

• ⚠ Đọc kỹ chữ NOT, LEAST, EXCEPT — dễ đọc sót
• ⚠ Xác nhận ba phương án ĐÚNG trước, cái còn lại là đáp án
• ⚠ Cảnh giác phương án nghe "cao siêu" — như nghiên cứu kiến trúc — thường là cái lạc đề

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

⚠ Ba phương án A, B, C đều là hoạt động MLOps chuẩn, nên không phải đáp án cho câu phủ định.

• A — phương án gần nhất bị chọn nhầm vì nghe phức tạp nhất. Nhưng huấn luyện lại tự động khi có drift chính là mục tiêu của MLOps.

Ghi nhớ

⚠ Đường ống MLOps chuẩn — bảng phải thuộc: | Hoạt động | Công cụ | |---|---| | ⚠ Phát hiện drift → kích hoạt huấn luyện lại | ⚠ Model Monitoring + Pipelines | | ⚠ Đánh phiên bản mô hình và chỉ số | ⚠ Model Registry | | ⚠ Triển khai dần (canary) | ⚠ Vertex AI Endpoints chia lưu lượng | | Kiểm thử tự động | ⚠ bộ test cố định | | Quay lui khi bản mới tệ hơn | ⚠ Registry | | Quản đặc trưng dùng chung | ⚠ Feature Store |

Từ khoá nhận diện:

"tự động hoá, phiên bản, canary, drift" → ⚠ MLOps chuẩn "đổi kiến trúc mô hình, thử lý thuyết mới" → ⚠ NGHIÊN CỨU, không phải MLOps "thu thập dữ liệu thô" → Data Ingestion "làm sạch, tạo đặc trưng" → Data Preparation

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có tái lập được mô hình đang chạy không | ⚠ cần Registry và lineage | | Huấn luyện lại có tự động không | ⚠ thủ công thì bị bỏ quên | | Đã thử quay lui chưa | ⚠ thử thật một lần |

Và ranh giới đáng giữ cho đội sản phẩm: MLOps là kỹ thuật vận hành, không phải nghiên cứu. Kiến trúc mô hình nên là thứ được chọn một lần rồi giữ ổn định, còn công sức nên dồn vào chất lượng dữ liệu và độ tin cậy của đường ống.

Đáp án

C — Ngôn ngữ lập trình mà mô hình được viết ra ban đầu.

Vì sao đúng

⚠ Đây là câu PHỦ ĐỊNH: hỏi tiêu chí KHÔNG phải cân nhắc chính khi chọn mô hình. Ba phương án kia đều là tiêu chí thật; ngôn ngữ lập trình gốc thì không liên quan tới người dùng mô hình.

⚠ Vì sao ngôn ngữ gốc không quan trọng:

Mô hình được truy cập qua API
        ↓
    ⚠ Người dùng KHÔNG cần biết
      nó viết bằng gì
    ⚠ Gọi bằng Python, Java, Go,
      REST đều được
        ↓
    ⚠ Đây là chi tiết TRIỂN KHAI
      của bên xây mô hình

⚠ Ba phương án kia đều LÀ tiêu chí thật:

⚠ A — Chất lượng sinh văn bản
     sáng tạo và khả năng bám
     GIỌNG THƯƠNG HIỆU
    → ⚠ đúng nhu cầu nghiệp vụ

⚠ B — ĐIỀU KHOẢN GIẤY PHÉP cho
     dùng THƯƠNG MẠI
    → ⚠ cực kỳ quan trọng, hay bị quên

⚠ D — TÀI LIỆU về dữ liệu huấn
     luyện và GIỚI HẠN
    → ⚠ cần cho đánh giá đạo đức
      và rủi ro

Nhất quán với #13892 (lô 145) về Model Garden và tiêu chí so sánh mô hình. Bổ sung nhau.

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

⚠ Câu PHỦ ĐỊNH — hỏi cái KHÔNG phải. Mẹo:

• ⚠ Xác nhận ba phương án ĐÚNG trước
• ⚠ Cảnh giác phương án nói về CHI TIẾT KỸ THUẬT NỘI BỘ — thường không liên quan tới người dùng
• ⚠ Ví dụ khác cùng kiểu: kiến trúc mạng, số lớp, ngôn ngữ triển khai

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

⚠ Ba phương án A, B, D đều là cân nhắc chính đáng, nên không phải đáp án cho câu phủ định.

• B (điều khoản giấy phép) — phương án dễ bị chọn nhầm vì nghe "không kỹ thuật". Nhưng với dùng thương mại, đây là tiêu chí bắt buộc kiểm.

Ghi nhớ

⚠ Tiêu chí chọn mô hình — bảng phải thuộc: | Tiêu chí | Có quan trọng không | |---|---| | ⚠ Modality | ⚠ CÓ — lọc đầu tiên | | ⚠ Chất lượng trên tác vụ cụ thể | ⚠ CÓ | | ⚠ Cửa sổ ngữ cảnh | ⚠ CÓ | | ⚠ Chi phí và độ trễ | ⚠ CÓ | | ⚠ GIẤY PHÉP thương mại | ⚠ CÓ — hay bị quên | | ⚠ Tài liệu và giới hạn đã công bố | ⚠ CÓ | | ⚠ Ngôn ngữ lập trình gốc | ⚠ KHÔNG — đề này |

Từ khoá nhận diện:

"ngôn ngữ lập trình, kiến trúc nội bộ" → ⚠ KHÔNG phải tiêu chí chọn "giấy phép thương mại" → ⚠ CÓ, rất quan trọng "tài liệu, giới hạn đã công bố" → ⚠ CÓ "loại dữ liệu vào ra" → modality

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giấy phép có cho dùng thương mại không | ⚠ đọc trước khi cam kết | | Model Card nói giới hạn gì | ⚠ đọc phần limitations | | Chất lượng trên brief thật ra sao | ⚠ thử, đừng tin bảng xếp hạng chung |

Và tiêu chí dễ bị bỏ qua nhất khi chọn mô hình mở từ một danh mục: điều khoản giấy phép. Nó không xuất hiện trong các bảng so sánh hiệu năng, nhưng lại là thứ duy nhất trong danh sách có thể khiến cả dự án phải làm lại từ đầu.

Đáp án

B — Vertex AI Search.

Vì sao đúng

Đề cần một công cụ tìm kiếm cấp doanh nghiệp trên dữ liệu của chính công ty: tài liệu kỹ thuật, hướng dẫn xử lý sự cố, đặc tả kỹ thuật nằm rải rác nhiều hệ thống, hiểu được câu hỏi bằng ngôn ngữ tự nhiên.

⚠ Ba dữ kiện khớp:

"kho tri thức NỘI BỘ, nhiều hệ thống"
    → ⚠ tìm kiếm doanh nghiệp,
      không phải web công khai

"hiểu câu hỏi NGÔN NGỮ TỰ NHIÊN"
    → ⚠ tìm kiếm ngữ nghĩa

"tìm THÔNG TIN CHÍNH XÁC trong
 tài liệu phức tạp"
    → ⚠ trích đoạn đúng + trích dẫn

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

"Google Public Search"
    → ⚠ tìm WEB công khai, không
      thấy tài liệu nội bộ

"BigQuery DataFrames API"
    → ⚠ xử lý dữ liệu dạng bảng
      bằng Python

"Cloud Storage"
    → ⚠ LƯU tệp; ⚠ không có năng
      lực tìm kiếm ngữ nghĩa

⚠ Gần trùng với #13863 (lô 145) và #13943 (cùng lô) — cả ba đều là tìm kiếm ngữ nghĩa trên dữ liệu riêng của doanh nghiệp, cùng khoá Vertex AI Search. Hoàn toàn nhất quán — chỉ khác ngành: bán lẻ, thương mại điện tử, sản xuất.

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

• D (Cloud Storage) — phương án gần nhất vì tài liệu thường nằm ở đó, nhưng nó là lớp lưu trữ; muốn tìm kiếm ngữ nghĩa thì cần lớp bên trên.

• C và A — sai nguồn và sai loại dữ liệu.

Ghi nhớ

⚠ Chọn giải pháp tìm kiếm theo NGUỒN — bảng phải thuộc: | Nguồn | Giải pháp | |---|---| | ⚠ Tài liệu nội bộ công ty | ⚠ Vertex AI Search | | Web công khai | ⚠ Grounding with Google Search | | Catalogue sản phẩm | ⚠ Vertex AI Search — Retail | | Tài liệu người dùng tự nạp | ⚠ NotebookLM | | Cho nhân viên, dạng cổng thông tin | ⚠ Gemini Enterprise |

Từ khoá nhận diện:

"tài liệu nội bộ, tìm kiếm doanh nghiệp" → ⚠ Vertex AI Search "tin tức, web công khai" → Grounding with Google Search "agent dùng công cụ" → Agent Builder "lưu tệp" → Cloud Storage

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trích dẫn tới trang cụ thể không | ⚠ bắt buộc với tài liệu kỹ thuật | | Tài liệu phiên bản cũ đã gỡ chưa | ⚠ rủi ro an toàn | | Thông tin trong bảng biểu có tìm được không | ⚠ thử với câu hỏi về thông số |

Và yêu cầu không được nhân nhượng với công cụ tra cứu kỹ thuật: mọi câu trả lời phải dẫn tới đúng trang tài liệu gốc. Kỹ thuật viên cần xác nhận thông số trước khi thao tác trên thiết bị, và một câu trả lời không kiểm chứng được thì không dùng được trong bối cảnh đó.

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

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

A — Vertex AI Feature Store.

Vì sao đúng

Công ty cần công cụ quản lý, PHỤC VỤ và GIÁM SÁT các đặc trưng ML mà mô hình dùng, để theo dõi thay đổi trong hành vi khách hàng và cập nhật đầu vào của mô hình theo đó. Đó là Feature Store.

⚠ Ba động từ trong đề khớp đúng ba chức năng:

"QUẢN LÝ đặc trưng"
    → ⚠ định nghĩa một lần, dùng chung

"PHỤC VỤ đặc trưng"
    → ⚠ online cho dự đoán thời gian thực
    → ⚠ offline cho huấn luyện

"GIÁM SÁT đặc trưng"
    → ⚠ phát hiện thay đổi trong
      phân phối

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

"Model Registry"
    → ⚠ quản phiên bản MÔ HÌNH,
      không phải đặc trưng

"Human in the Loop"
    → ⚠ quy trình người duyệt

"Prompt Engineering"
    → ⚠ kỹ thuật viết câu lệnh

⚠ Gần trùng với #14012 (lô 148) và #13995 (lô 147) — cả ba về Feature Store, cùng khoá. Đề này nhấn thêm phần giám sát thay đổi. Hoàn toàn nhất quán.

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

• C (Model Registry) — phương án gần nhất và là bẫy chính: cùng bộ MLOps, cùng làm việc quản lý và phiên bản. Nhưng nó quản mô hình, còn đề nói rõ về đặc trưng (features).

• B và D — không phải công cụ quản đặc trưng.

Ghi nhớ

⚠ Công cụ MLOps — quản cái gì, bảng phải thuộc: | Công cụ | Quản | |---|---| | ⚠ Feature Store | ⚠ ĐẶC TRƯNG — quản, phục vụ, giám sát | | Model Registry | ⚠ MÔ HÌNH — phiên bản, lineage | | Model Monitoring | ⚠ phát hiện drift của mô hình đang chạy | | Pipelines | ⚠ quy trình tự động | | Experiments | ⚠ các lần thử nghiệm |

Từ khoá nhận diện:

"quản, phục vụ, giám sát ĐẶC TRƯNG" → ⚠ Feature Store "quản phiên bản mô hình" → Model Registry "phân phối đầu vào đổi" → ⚠ Model Monitoring "người duyệt kết quả" → HITL

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đặc trưng tính ở mấy nơi | ⚠ hơn một là nguy cơ skew | | Đặc trưng có còn cập nhật không | ⚠ job hỏng âm thầm là chuyện thường | | Có dùng dữ liệu tương lai không | ⚠ point-in-time correctness |

Và tín hiệu cảnh báo sớm nhất mà một hệ thống cá nhân hoá có thể có: một đặc trưng bỗng ngừng cập nhật. Mô hình vẫn chạy, vẫn trả kết quả, chỉ là dựa trên số liệu đứng yên từ tuần trước — và không có gì báo lỗi nếu không ai giám sát chính các đặc trưng.

Đáp án

B — Hệ thống AI tự động đổi lộ trình cho tài xế.

Vì sao đúng

Trong bốn thành phần, chỉ hệ thống này TỰ RA QUYẾT ĐỊNH và HÀNH ĐỘNG dựa trên dữ liệu giao thông thời gian thực. Đó là đặc trưng của tầng Agents.

⚠ Ánh xạ bốn thành phần:

"máy chủ đám mây và GPU"
    → ⚠ INFRASTRUCTURE

"mô hình nền tối ưu lộ trình"
    → ⚠ MODELS

"cổng web tài xế xem lộ trình"
    → ⚠ APPLICATIONS

"hệ thống AI TỰ ĐỘNG đổi lộ trình
 theo giao thông trực tiếp"
    → ⚠ AGENTS — đề hỏi cái này

⚠ Điều làm nên agent ở đây:

⚠ TỰ QUYẾT — không chờ người bấm
⚠ PHẢN ỨNG với dữ liệu THỜI GIAN THỰC
⚠ HÀNH ĐỘNG — đổi lộ trình thật
⚠ Có MỤC TIÊU — giao hàng đúng giờ
        ↓
    ⚠ Mô hình chỉ TÍNH lộ trình
    ⚠ Agent QUYẾT ĐỊNH và ÁP DỤNG

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

"Mô hình nền tối ưu lộ trình"
    → ⚠ năng lực TÍNH TOÁN;
      không tự quyết khi nào dùng

"Cổng web cho tài xế"
    → ⚠ giao diện người dùng cuối

"Máy chủ và GPU"
    → ⚠ hạ tầng

⚠ Gần trùng với #14042 (lô 148) — đề đó cũng liệt kê bốn thành phần và hỏi tầng Agents, cùng khoá. Hoàn toàn nhất quán. Và #13878/#13899/#13948/#14029 về các tầng còn lại.

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

• A (mô hình nền tối ưu lộ trình) — phương án gần nhất và là bẫy chính: agent dùng chính mô hình này. Nhưng mô hình là năng lực, còn agent là thứ quyết định khi nào và làm gì với năng lực đó.

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

Ghi nhớ

⚠ Năm thành phần trong bối cảnh AI sinh — bảng phải thuộc: | Tầng | Vai trò | Ví dụ trong đề | |---|---|---| | Infrastructure | ⚠ phần cứng | máy chủ, GPU | | Models | ⚠ năng lực AI | mô hình tối ưu lộ trình | | Platforms | ⚠ công cụ xây và vận hành | Vertex AI | | ⚠ Agents | ⚠ TỰ QUYẾT và HÀNH ĐỘNG | ⚠ hệ đổi lộ trình | | Applications | ⚠ giao diện người dùng | cổng web tài xế |

Từ khoá nhận diện:

"tự động ra quyết định và hành động" → ⚠ Agents "mô hình huấn luyện sẵn" → Models "giao diện người dùng bấm vào" → Applications "máy chủ, GPU" → Infrastructure

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Tài xế có quyền từ chối không | ⚠ họ biết đường thực tế | | Tỉ lệ chấp nhận gợi ý bao nhiêu | ⚠ chỉ số quan trọng nhất | | Dữ liệu giao thông lỗi thì sao | ⚠ phải có phương án |

Và chỉ số cho biết một hệ thống điều phối tự động có thật sự hoạt động hay không: tỉ lệ tài xế làm theo gợi ý. Nếu con số đó thấp, hệ thống đang chạy nhưng không tạo ra giá trị nào — và nguyên nhân thường là nó chưa biết những gì người lái xe biết.

Đáp án

C — Dùng Vertex AI Agent Builder để neo mô hình vào dữ liệu của ngân hàng và kết nối API qua công cụ (tools).

Vì sao đúng

Ngân hàng cần agent dùng kho tri thức riêng và gọi API lãi suất trực tiếp, với cân bằng giữa tốc độ, bảo mật và năng lực. Agent Builder cho cả ba.

⚠ Hai nhu cầu, hai cơ chế:

"dùng KHO TRI THỨC RIÊNG"
    → ⚠ GROUNDING vào tài liệu ngân hàng

"kết nối API lãi suất TRỰC TIẾP"
    → ⚠ TOOL / function calling
        ↓
    ⚠ Agent Builder có SẴN cả hai
    ⚠ cùng bảo mật doanh nghiệp

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

"Huấn luyện mô hình nền TỪ ĐẦU"
    → ⚠ cực kỳ tốn kém và chậm
    → ⚠ hoàn toàn không cần thiết

"Fine-tune LLM mã nguồn mở trên
 bản ghi hội thoại"
    → ⚠ dạy PHONG CÁCH, ⚠ KHÔNG
      cho phép tra kho tri thức hay
      gọi API lãi suất

"Mua chatbot SaaS chung chung
 của bên thứ ba"
    → ⚠ không tích hợp được dữ liệu
      riêng và hệ thống nội bộ
    → ⚠ rủi ro dữ liệu ngân hàng

⚠ Gần trùng với #13952 (lô 146) và #14046 (lô 148) — cả ba đều là agent cần grounding và gọi API, cùng khoá Agent Builder. Hoàn toàn nhất quán.

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

• B (fine-tune LLM mở) — phương án gần nhất và là bẫy chính: nghe như tuỳ biến sâu cho ngân hàng. Nhưng fine-tuning không cho mô hình tra tài liệu hay gọi API — hai thứ chính đề yêu cầu.

• A và D — quá tốn kém hoặc không đáp ứng yêu cầu.

Ghi nhớ

⚠ Chọn cách theo NHU CẦU — bảng phải thuộc: | Nhu cầu | Cách | |---|---| | ⚠ Tra tài liệu riêng | ⚠ grounding / RAG | | ⚠ Gọi API, lấy dữ liệu động | ⚠ tool / function calling | | Đổi phong cách, thuật ngữ | ⚠ fine-tuning | | ⚠ Cả grounding + tool + quản trị | ⚠ Agent Builder — đề này |

Từ khoá nhận diện:

"kho tri thức riêng + gọi API" → ⚠ Agent Builder "chỉ cần tra tài liệu" → Vertex AI Search "giọng văn, thuật ngữ" → fine-tuning "chỉ sinh văn bản" → mô hình thuần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lãi suất lấy từ đâu | ⚠ phải từ API, không từ trí nhớ mô hình | | Agent có phê duyệt không | ⚠ không được — chỉ sơ tuyển | | Có xác thực trước khi tra hồ sơ không | ⚠ bắt buộc |

Và ranh giới cần khoá chặt trong mọi ứng dụng AI cho ngân hàng: agent thu thập thông tin và ước tính, con người ra quyết định cho vay. Một con số ước tính sai có thể sửa bằng lời giải thích; một quyết định tín dụng sai thì không.

Đá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

• B (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.

• D 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.

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

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

D — Khả năng mở rộng của giải pháp và tính dễ tuỳ biến cho bối cảnh địa phương.

Vì sao đúng

Đề nêu hai ràng buộc nghiệp vụ song song: hàng trăm cửa hàng nhượng quyền (quy mô) và mỗi nơi cần nội dung riêng theo sự kiện, ngôn ngữ vùng miền, mặt hàng của cửa hàng đó (tuỳ biến).

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

"HÀNG TRĂM địa điểm nhượng quyền"
    → ⚠ SCALABILITY
    → ⚠ chi phí mỗi nội dung nhân
      lên hàng trăm lần

"sự kiện ĐỊA PHƯƠNG, sắc thái
 NGÔN NGỮ vùng, mặt hàng RIÊNG"
    → ⚠ EASE OF CUSTOMIZATION
    → ⚠ mỗi nơi một bối cảnh khác

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

"Mô hình huấn luyện sẵn LỚN NHẤT"
    → ⚠ lớn nhất KHÔNG phải tốt nhất
    → ⚠ nội dung khuyến mãi ngắn
      không cần mô hình lớn nhất
    → ⚠ và nhân với hàng trăm cửa
      hàng thì chi phí rất cao

"Sinh văn bản THƠ CA, NGHỆ THUẬT"
    → ⚠ không phải yêu cầu của
      nội dung khuyến mãi

"Suy luận TOÁN HỌC phức tạp"
    → ⚠ không liên quan

Nhất quán với #13897 (lô 145) và #13915 (cùng lô) — cùng nguyên tắc bắt đầu từ yêu cầu nghiệp vụ thật, không từ đặc tính kỹ thuật ấn tượng.

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

• C (mô hình lớn nhất) — phương án gần nhất và là bẫy chính: nghe như "chọn thứ tốt nhất". Nhưng với tác vụ ngắn lặp lại hàng trăm lần, mô hình lớn nhất là lựa chọn đắt và chậm một cách không cần thiết.

• A và B — không phải yêu cầu của bài toán.

Ghi nhớ

⚠ Ràng buộc nghiệp vụ → tiêu chí chọn giải pháp: | Ràng buộc | Tiêu chí | |---|---| | ⚠ Nhiều địa điểm, khối lượng lớn | ⚠ scalability + chi phí mỗi lượt | | ⚠ Mỗi nơi một bối cảnh | ⚠ dễ tuỳ biến, template hoá | | Nhiều ngôn ngữ, vùng miền | ⚠ năng lực đa ngữ | | Người dùng không kỹ thuật | ⚠ low-code, giao diện | | Nội dung ra công chúng | ⚠ duyệt, bộ lọc an toàn |

Từ khoá nhận diện:

"nhiều địa điểm, mỗi nơi khác nhau" → ⚠ scalability + customization "đo thành công bằng gì" → chỉ số nghiệp vụ "bắt đầu từ đâu" → ⚠ ca sử dụng + thí điểm "dữ liệu nhạy cảm" → kiểm soát doanh nghiệp

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Chi phí mỗi nội dung × số lượng bằng bao nhiêu | ⚠ con số quyết định | | Ai duyệt trước khi đăng | ⚠ quy trình phải khả thi ở quy mô đó | | Mô hình nhỏ đã đủ chưa | ⚠ thử trước khi chọn mô hình lớn |

Và bài toán thật ở quy mô hàng trăm cửa hàng không phải là chất lượng của một nội dung, mà là quy trình duyệt có chạy nổi hay không. Sinh ra năm trăm bản khuyến mãi trong một giờ là chuyện dễ; kiểm được năm trăm bản đó trước khi chúng xuất hiện trước khách hàng mới là phần cần thiết kế.

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

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