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

Đáp án

C — Mức rủi ro nghiệp vụ chấp nhận được, đặt cạnh ngân sách của dự án.

Vì sao đúng

Đề dựng một đánh đổi kinh doanh thuần tuý, và câu hỏi dành cho lãnh đạo doanh nghiệp chứ không phải kỹ sư.

⚠ Bản chất đánh đổi:

Mô hình A
   ⚠ chính xác nhất
   ⚠ đắt nhất

Mô hình B
   ⚠ rẻ hơn nhiều
   ⚠ ⚠ "lời khuyên chung chung,
      kém tối ưu hơn" ⚠

⚠ Câu hỏi thật:
   "Lời khuyên đầu tư kém tối ưu
    gây thiệt hại bao nhiêu?"

⚠ Vì sao lĩnh vực này làm câu trả lời rõ ràng:

⚠ Tư vấn ĐẦU TƯ
   → ⚠ khách mất tiền thật
   → ⚠ rủi ro pháp lý và quản lý
   → ⚠ mất uy tín rất khó phục hồi
        ↓
⚠ Chi phí của MỘT lời khuyên tồi
  có thể vượt xa phần tiết kiệm
  cả năm

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

Cả ba đều là yếu tố kỹ thuật, trong khi đề hỏi điều quan trọng nhất với LÃNH ĐẠO:

• A (kích thước cửa sổ ngữ cảnh) — yếu tố kỹ thuật quan trọng ở nhiều bài toán, nhưng ⚠ đề không nêu ràng buộc nào về độ dài đầu vào.

• B (có tuỳ chọn fine-tuning hay không) — ⚠ chi tiết triển khai; và fine-tune không xoá được khoảng cách năng lực căn bản giữa hai mô hình.

• D (ngôn ngữ lập trình đội quen dùng) — ⚠ hoàn toàn không liên quan tới quyết định kinh doanh; cả hai mô hình đều gọi được từ mọi ngôn ngữ phổ biến.

Ghi nhớ

⚠ Khung quyết định chọn mô hình theo rủi ro — bảng phải thuộc: | Mức rủi ro | Ví dụ | Chọn | |---|---|---| | ⚠ Cao — tiền, sức khoẻ, pháp lý | ⚠ tư vấn đầu tư, y tế, cho vay | ⚠ mô hình tốt nhất + HITL | | Trung bình | ⚠ hỗ trợ khách hàng | cân bằng | | Thấp | ⚠ gợi ý nội dung nội bộ | ⚠ mô hình rẻ |

Từ khoá nhận diện:

"business leaders, most critical" → ⚠ yếu tố KINH DOANH, không phải kỹ thuật "tài chính, y tế, pháp lý" → ⚠ rủi ro cao, đừng tiết kiệm sai chỗ "context window, fine-tuning, ngôn ngữ" → ⚠ yếu tố kỹ thuật, thường là bẫy ở câu hỏi cho lãnh đạo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Một lời khuyên tồi tốn bao nhiêu | ⚠ ước lượng trước khi so giá mô hình | | Cơ quan quản lý yêu cầu gì | ⚠ hỏi pháp chế trước, không phải sau | | Có ai duyệt trước khi gửi khách không | ⚠ với tư vấn đầu tư thì bắt buộc |

Và điều hay bị bỏ qua khi so sánh chi phí mô hình: phần tiết kiệm được tính theo mỗi truy vấn, còn thiệt hại tính theo mỗi vụ việc. Vài xu nhân với hàng triệu lượt nghe rất nhiều, cho tới khi đặt cạnh một vụ kiện hoặc một án phạt của cơ quan quản lý.

Đáp án

B — Retrieval-Augmented Generation (RAG) và Human-in-the-Loop (HITL).

Vì sao đúng

Đề nêu hai thách thức tách bạch, và mỗi thách thức có đúng một kỹ thuật tương ứng:

⚠ Ghép từng thách thức:

Thách thức 1:
   ⚠ "phân tích thị trường ĐỘC QUYỀN,
      CẬP NHẬT TỪNG PHÚT"
   ⚠ "không dùng tri thức chung
      đã lỗi thời"
        ↓
   ⚠ RAG — lấy dữ liệu mới nhất
     lúc chạy

Thách thức 2:
   ⚠ "tuân thủ nghiêm ngặt"
   ⚠ "tiền đặt cược lớn"
   ⚠ "bản cuối gửi khách phải
      HOÀN HẢO và ĐƯỢC KIỂM CHỨNG"
        ↓
   ⚠ HITL — người có chuyên môn
     duyệt trước khi gửi

⚠ Vì sao phải có CẢ HAI:

⚠ Chỉ RAG
   → dữ liệu đúng, nhưng vẫn có thể
     diễn giải sai
   → ⚠ không ai chịu trách nhiệm

⚠ Chỉ HITL
   → có người duyệt, nhưng phải
     duyệt trên nội dung dựa vào
     tri thức lỗi thời
   → ⚠ tốn công sửa lại từ đầu

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

• D (prompt engineering và fine-tuning) — ⚠ bẫy mạnh nhất. Cả hai đều hữu ích nhưng không giải được thách thức nào trong hai: ⚠ fine-tuning ĐÓNG BĂNG tri thức nên không thể "cập nhật từng phút", còn prompt engineering không kiểm chứng được bản cuối.

• A (caching và rate limiting) — ⚠ kỹ thuật hiệu năng và chi phí, không liên quan tới độ chính xác hay tuân thủ.

• C (ẩn danh dữ liệu và phát hiện thiên lệch) — ⚠ hai biện pháp quan trọng và có thể cũng cần, nhưng chúng lo riêng tư và công bằng, không lo độ tươi của dữ liệu hay kiểm chứng bản cuối.

Ghi nhớ

⚠ Ghép thách thức với kỹ thuật — bảng phải thuộc: | Thách thức | Kỹ thuật | |---|---| | ⚠ Dữ liệu mới, dữ liệu riêng | ⚠ RAG | | ⚠ Bản cuối phải chuẩn, rủi ro cao | ⚠ HITL | | Riêng tư | ⚠ ẩn danh, che dữ liệu | | Công bằng | ⚠ phát hiện thiên lệch | | Chi phí, tải | ⚠ caching, rate limit | | Phong cách | ⚠ fine-tuning |

Từ khoá nhận diện:

"up-to-the-minute, proprietary" → ⚠ RAG "flawless, verified, regulatory" → ⚠ HITL "fine-tune cho dữ liệu mới" → ⚠ SAI — fine-tune đóng băng tri thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu phân tích trong RAG mới tới đâu | ⚠ kiểm dấu thời gian | | Tỷ lệ người duyệt sửa lại là bao nhiêu | ⚠ bằng 0 là đáng ngờ | | Có lưu bản nháp gốc không | ⚠ bằng chứng tuân thủ |

Và cặp RAG + HITL đáng nhớ như một mẫu hình chuẩn cho mọi lĩnh vực rủi ro cao: RAG lo cho câu trả lời dựa trên dữ liệu đúng, HITL lo cho việc có người chịu trách nhiệm. Thiếu vế đầu thì nội dung sai; thiếu vế sau thì không ai gánh hậu quả.

Đáp án

C — Khả năng đổi mới và tạo khác biệt cho Ứng dụng của họ trong tương lai sẽ bị chính giới hạn của nền tảng ràng buộc.

Vì sao đúng

Đề hỏi rủi ro ở tầng Platform, và mô tả rất rõ hai giới hạn của nền tảng đó:

⚠ Hai giới hạn được nêu:

"chỉ truy cập được MỘT mô hình
 ngôn ngữ ĐA DỤNG"
    → ⚠ không đổi mô hình được
    → ⚠ không tinh chỉnh cho văn
      chương sáng tạo

"thành phần giao diện HẠN CHẾ"
    → ⚠ trải nghiệm giống mọi
      ứng dụng khác trên nền tảng

⚠ Vì sao đó là rủi ro CHIẾN LƯỢC:

Sản phẩm là ⚠ TRUYỆN SÁNG TẠO
        ↓
⚠ Khác biệt nằm ở CHẤT LƯỢNG
  văn chương và TRẢI NGHIỆM
        ↓
⚠ Cả hai đều bị nền tảng khoá
        ↓
⚠ Đối thủ dùng cùng nền tảng
  → sản phẩm giống hệt
⚠ Đối thủ kiểm soát mô hình
  → vượt lên được

⚠ Đánh đổi ra thị trường sớm là hợp lý — nhưng phải biết mình đang trả giá bằng cái gì.

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

• A (không dùng được mô hình nền của Google như Gemini hay Imagen) — ⚠ quá cụ thể và không chắc đúng: nhiều nền tảng no-code vẫn dùng mô hình của Google bên dưới. Đây là triệu chứng có thể có, không phải rủi ro chiến lược.

• B (phải thuê thêm lập trình viên giỏi quản trị hạ tầng) — ⚠ ngược hẳn: chọn nền tảng được quản lý chính là để khỏi phải làm việc đó.

• D (chi phí hạ tầng khó dự đoán và kiểm soát) — ⚠ cũng ngược: nền tảng no-code thường có giá theo gói dễ dự đoán hơn tự vận hành. Đây là rủi ro của tầng Infrastructure, không phải Platform.

Ghi nhớ

⚠ Bốn tầng của bức tranh gen AI — bảng phải thuộc: | Tầng | Nội dung | Rủi ro đặc trưng | |---|---|---| | Infrastructure | ⚠ GPU/TPU, mạng, lưu trữ | ⚠ chi phí, năng lực | | Models | ⚠ mô hình nền | ⚠ chất lượng, phụ thuộc nhà cung cấp | | ⚠ Platform | ⚠ công cụ xây và triển khai | ⚠ KHOÁ CHÂN, giới hạn khác biệt hoá — đề này | | Applications | ⚠ sản phẩm cuối | ⚠ sản phẩm phù hợp thị trường | | Agents | ⚠ hệ thống tự hành | ⚠ kiểm soát, an toàn |

Từ khoá nhận diện:

"chỉ một mô hình, giao diện hạn chế, no-code" → ⚠ rủi ro tầng Platform "chi phí GPU khó đoán" → tầng Infrastructure "mô hình bị ngừng hỗ trợ" → tầng Models "không ai dùng sản phẩm" → tầng Application

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xuất được dữ liệu người dùng ra không | ⚠ thử thật, đừng tin tài liệu | | Đổi mô hình bên dưới được không | ⚠ hỏi thẳng nhà cung cấp | | Chuyển đi mất bao lâu | ⚠ ước lượng trước khi phụ thuộc sâu |

Và cách đọc đúng câu hỏi dạng này: đề chỉ định rõ TẦNG cần trả lời. Cùng một quyết định có rủi ro ở nhiều tầng khác nhau — chi phí ở tầng hạ tầng, chất lượng ở tầng mô hình, khoá chân ở tầng nền tảng — nên phải trả lời đúng tầng đề hỏi.

Đáp án

C — Việc 1: Dữ liệu bên thứ nhất, Việc 2: Dữ liệu bên thứ ba, Việc 3: Dữ liệu thế giới.

Vì sao đúng

Ba câu hỏi trong đề cần ba nguồn sự thật khác nhau:

⚠ Ghép từng việc:

1. "dựa trên CHUYẾN ĐI TRƯỚC
    CỦA TÔI"
    → ⚠ lịch sử đặt chỗ của
      chính công ty
    → ⚠ FIRST-PARTY DATA

2. "còn ghế trên chuyến 8:00
    thứ Ba tới không"
    → ⚠ hệ thống đặt chỗ của
      HÃNG BAY
    → ⚠ THIRD-PARTY DATA
      (API đối tác)

3. "đi từ sân bay vào trung tâm
    Rome thế nào"
    → ⚠ tri thức chung, công khai
    → ⚠ WORLD DATA

⚠ Nguyên tắc chọn nguồn:

⚠ "CỦA TÔI" → first-party
⚠ "thời gian thực từ đối tác"
   → third-party
⚠ "ai cũng biết được" → world

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

Cả ba phương án còn lại đều ghép lệch:

• A — cho việc 1 dùng world data: lịch sử chuyến đi cá nhân không có trên Internet.

• B — cho việc 1 dùng world data (sai như trên) và việc 3 cũng world data (đúng), nhưng việc 2 gán third-party thì đúng — tổng thể vẫn sai vì việc 1.

• D — đảo lộn hoàn toàn: đặt first-party cho câu hỏi về đường đi ở Rome, tức là cho rằng công ty du lịch có dữ liệu riêng về giao thông Rome.

⚠ Chiến thuật: chốt việc 1 trước — "my past trips" chắc chắn là dữ liệu nội bộ. Chỉ hai phương án cho việc 1 là first-party hoặc third-party, loại ngay A và B.

Ghi nhớ

⚠ Ba loại nguồn grounding — bảng phải thuộc: | Loại | Nguồn | Ví dụ | |---|---|---| | ⚠ First-party | ⚠ dữ liệu CỦA CÔNG TY | ⚠ lịch sử khách, tồn kho, chính sách | | ⚠ Third-party | ⚠ API ĐỐI TÁC | ⚠ ghế trống, giá phòng, thanh toán | | ⚠ World data | ⚠ tri thức công khai | ⚠ địa lý, văn hoá, kiến thức chung |

Từ khoá nhận diện:

"của tôi, lịch sử của tôi, tài khoản của tôi" → ⚠ first-party "còn chỗ không, giá hôm nay, tồn kho đối tác" → ⚠ third-party "nói chung, thông thường, ở thành phố X" → ⚠ world data

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Câu hỏi đặt chỗ có gọi API thật không | ⚠ xem log, đừng tin câu trả lời | | Có dùng lịch sử khách khi chưa xin phép không | ⚠ kiểm chính sách đồng ý | | Thông tin world data đã cũ tới mức nào | ⚠ giá vé, giờ tàu hay đổi |

Và sai lầm nguy hiểm nhất trong nhóm này: để mô hình trả lời câu hỏi third-party bằng tri thức chung. Nó sẽ trả lời trôi chảy về chuyến bay 8 giờ sáng mà không hề gọi hệ thống nào — và khách chỉ phát hiện ra khi tới sân bay.

Đáp án

D — Tối ưu A cho ĐỘ TRỄ THẤP; tối ưu B cho THÔNG LƯỢNG CAO.

Vì sao đúng

Hai ứng dụng có hình dạng tải hoàn toàn khác nhau:

⚠ Ghép từng ứng dụng:

A. Dịch giọng nói TRỰC TIẾP
   trong cuộc gọi
   ⚠ người đang chờ NGAY LÚC ĐÓ
   ⚠ chậm nửa giây là hỏng
     cuộc hội thoại
   → ⚠ LOW LATENCY

B. Phân loại 10 TRIỆU bình luận
   QUA ĐÊM, một job duy nhất
   ⚠ KHÔNG ai ngồi chờ
   ⚠ chỉ cần xong trước sáng
   → ⚠ HIGH THROUGHPUT

⚠ Hai chỉ số khác nhau ra sao:

⚠ ĐỘ TRỄ
   → ⚠ MỘT yêu cầu mất bao lâu
   → ⚠ đo bằng mili giây

⚠ THÔNG LƯỢNG
   → ⚠ bao nhiêu yêu cầu mỗi giây
   → ⚠ đo bằng số lượng/thời gian

⚠ Chúng THƯỜNG ĐÁNH ĐỔI NHAU
   → gộp nhiều yêu cầu thành lô
     → thông lượng TĂNG
     → độ trễ từng yêu cầu TĂNG

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

• C (đảo ngược hai vế) — ⚠ sai nghiêm trọng nhất: tối ưu thông lượng cho dịch trực tiếp nghĩa là gộp lô và bắt người gọi chờ; tối ưu độ trễ cho job qua đêm là trả tiền cho tốc độ mà không ai cần.

• A (tối ưu cả hai cho độ trễ thấp) — ⚠ lãng phí ở B: hạ tầng độ trễ thấp đắt hơn nhiều, mà job qua đêm không hưởng lợi gì.

• B (tối ưu cả hai cho thông lượng) — ⚠ phá hỏng A: dịch trực tiếp mà gộp lô thì cuộc gọi không dùng được.

Ghi nhớ

⚠ Độ trễ và thông lượng — bảng phải thuộc: | Chỉ số | Đo gì | Tối ưu khi | |---|---|---| | ⚠ Độ trễ | ⚠ thời gian MỘT yêu cầu | ⚠ người đang chờ — A | | ⚠ Thông lượng | ⚠ số yêu cầu mỗi giây | ⚠ xử lý lô lớn — B |

Từ khoá nhận diện:

"real-time, live, trực tiếp, đang gọi điện" → ⚠ độ trễ thấp "batch, qua đêm, hàng triệu bản ghi" → ⚠ thông lượng cao "người dùng đang chờ" → ⚠ luôn là độ trễ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ p99 của A là bao nhiêu | ⚠ trường hợp xấu nhất mới quyết định trải nghiệm | | B có kịp xong trước sáng không | ⚠ đo trên mẫu rồi ngoại suy | | Chi phí B là bao nhiêu | ⚠ thử 1.000 bản rồi nhân lên |

Và nguyên tắc dễ nhớ nhất: hỏi xem có ai đang ngồi chờ câu trả lời không. Có người chờ thì tối ưu độ trễ; không ai chờ thì tối ưu thông lượng và chi phí — hai hướng này gần như luôn đi ngược nhau.

Đáp án

D — Sự tích hợp sâu, nguyên bản giữa nền tảng dữ liệu, đám mây và quảng cáo của Google.

Vì sao đúng

Đề mô tả một luồng từ dữ liệu tới kích hoạt đi qua bốn sản phẩm Google khác dòng nhau:

⚠ Luồng trong đề:

Google Analytics
   ⚠ dữ liệu luồng nhấp chuột
        ↓ ghép với
BigQuery
   ⚠ dữ liệu bán hàng
        ↓
Vertex AI
   ⚠ sinh lời quảng cáo riêng cho
     từng phân khúc
        ↓ đẩy tự động sang
Google Ads
   ⚠ chiến dịch chạy thật

⚠ Vì sao tích hợp là điểm được hỏi:

⚠ Bốn sản phẩm, một luồng liền mạch
⚠ Không phải dựng cầu nối thủ công
⚠ Không phải xuất nhập file giữa
  các hệ thống
        ↓
⚠ Đó là thứ kịch bản này thể hiện

⚠ Gần trùng với #14134 (chính lô này) — cùng ý về hệ sinh thái Google (Ads + Analytics + Cloud + AI), cùng hướng khoá. Hai câu, hai bối cảnh bán lẻ, cùng một bài học.

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

Cả ba đều là thế mạnh có thật nhưng không phải thứ kịch bản này minh hoạ:

• A (hạ tầng tối ưu cho AI, TPU, huấn luyện rẻ nhất) — ⚠ công ty này ⚠ không huấn luyện mô hình nào, họ dùng mô hình có sẵn.

• B (hạ tầng an toàn từ thiết kế, ngăn rò rỉ dữ liệu) — ⚠ điều kiện nền cho mọi kịch bản, không phải điểm nổi bật của kịch bản này.

• C (cách tiếp cận mở, dùng mô hình bên thứ ba) — ⚠ kịch bản không nhắc gì tới mô hình mở hay việc tránh khoá chân.

⚠ Mẹo chấm dạng "kịch bản này thể hiện thế mạnh nào": đếm xem kịch bản NHẮC TỚI những sản phẩm nào. Nhắc nhiều sản phẩm khác dòng ghép lại → hệ sinh thái/tích hợp.

Ghi nhớ

⚠ Bốn thế mạnh và dấu hiệu — bảng phải thuộc: | Thế mạnh | Dấu hiệu | |---|---| | ⚠ Tích hợp sâu / hệ sinh thái | ⚠ nhiều sản phẩm Google trong một luồng — đề này | | Hạ tầng tối ưu AI | ⚠ TPU, huấn luyện quy mô lớn | | Cách tiếp cận mở | ⚠ mô hình mở, đa đám mây | | An toàn từ thiết kế | ⚠ Titan, mã hoá, bảo mật |

Từ khoá nhận diện:

"Analytics + BigQuery + Vertex AI + Ads" → ⚠ tích hợp "huấn luyện mô hình nền" → hạ tầng "Llama, Gemma, chạy nơi khác" → mở "chống tấn công, tuân thủ" → bảo mật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai duyệt lời quảng cáo trước khi chạy | ⚠ tự động đẩy thẳng là rủi ro | | Phân khúc có dùng thuộc tính nhạy cảm không | ⚠ kiểm đặc trưng đầu vào | | Ngân sách có trần chưa | ⚠ tự động hoá không trần là nguy hiểm |

Và điều nên nhớ về nhóm câu "thế mạnh nào được thể hiện": đáp án luôn nằm ở chi tiết CỤ THỂ đề đưa ra, không ở phát biểu đúng chung chung. Bảo mật và tính mở đều là thế mạnh thật, nhưng chúng không phải thứ kịch bản này đang kể.

Đáp án

C — Grounding bằng dữ liệu bên thứ ba: nối agent thẳng vào dịch vụ phát tin chính thức, có bản quyền, mà các công ty dùng để công bố báo cáo lợi nhuận.

Vì sao đúng

Đề đặt ưu tiên tuyệt đối là chính xác về số liệu và đúng thời điểm công bố. Chỉ nguồn chính thức đáp ứng được cả hai.

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

"phản ánh CON SỐ CHÍNH THỨC
 của công ty"
    → ⚠ nguồn PHÁT HÀNH GỐC
    → ⚠ không qua trung gian diễn giải

"công bố công khai vào MỘT
 THỜI ĐIỂM XÁC ĐỊNH"
    → ⚠ dịch vụ tin phát ra
      NGAY GIÂY ĐẦU TIÊN
    → ⚠ web mất thời gian mới
      đăng lại

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

⚠ Sai một con số lợi nhuận
   → ⚠ ảnh hưởng giá cổ phiếu
   → ⚠ trách nhiệm pháp lý
   → ⚠ mất uy tín toà soạn

⚠ Chậm vài phút
   → ⚠ mất giá trị tin tức

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

• D (grounding bằng Google Search — world data) — ⚠ bẫy mạnh nhất vì tìm kiếm web đúng là một hình thức grounding. Nhưng ⚠ web là nguồn ĐÃ QUA TAY người khác: có độ trễ, có thể có bản tin sai, và ⚠ có thể lấy phải phân tích của người khác thay vì số liệu gốc.

• B (first-party data — kho bài cũ của toà soạn) — ⚠ bài cũ giúp về văn phong và bối cảnh, nhưng ⚠ không chứa số liệu quý MỚI — thứ chưa từng tồn tại lúc các bài đó được viết.

• A (không grounding, dựa vào tri thức sẵn có của mô hình) — ⚠ tệ nhất: tri thức mô hình dừng ở mốc huấn luyện, chắc chắn không có số liệu vừa công bố, và mô hình sẽ bịa số rất trôi chảy.

Ghi nhớ

⚠ Chọn nguồn grounding theo tiêu chí — bảng phải thuộc: | Yêu cầu | Nguồn | |---|---| | ⚠ Số liệu chính thức, tức thời | ⚠ third-party — nguồn phát hành gốc | | Dữ liệu nội bộ công ty | ⚠ first-party | | Thông tin công khai, không gấp | ⚠ world data / Search | | Không cần dữ liệu mới | ⚠ tri thức mô hình |

Từ khoá nhận diện:

"official, licensed, press wire, nguồn phát hành" → ⚠ third-party "kho bài của chúng tôi" → first-party "tìm trên các website" → ⚠ world data — có độ trễ và nhiễu "độ chính xác là ưu tiên tuyệt đối" → ⚠ luôn chọn nguồn GẦN GỐC NHẤT

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số trong bài có khớp bản tin gốc không | ⚠ đối chiếu từng con số | | Bài ra sau bản tin gốc bao lâu | ⚠ đo độ trễ thật | | Ai là biên tập viên chịu trách nhiệm | ⚠ phải có tên |

Và nguyên tắc rút ra cho mọi lĩnh vực cần độ chính xác cao: grounding không phải một thứ, mà là một lựa chọn NGUỒN. Grounding vào một nguồn nhiễu vẫn cho ra câu trả lời sai — chỉ khác là bây giờ nó sai một cách có trích dẫn.

Đáp án

B — Agent Engine Memory Bank.

Vì sao đúng

Đề mô tả đúng bài toán bộ nhớ GIỮA CÁC PHIÊN, không phải trong một phiên:

⚠ Ghép từng yêu cầu:

"khách liên hệ NHIỀU LẦN về
 cùng một vấn đề"
    → ⚠ nhiều phiên khác nhau

"agent phải NHỚ hội thoại trước"
    → ⚠ bộ nhớ dài hạn

"nhớ các bước đã thử"
    → ⚠ trạng thái xử lý sự cố

"không bắt khách LẶP LẠI"
    → ⚠ ngữ cảnh phải sống sót
      qua các lần kết nối

⚠ Ba loại bộ nhớ — phải phân biệt:

⚠ Ngữ cảnh trong prompt
   → ⚠ chỉ sống trong MỘT lượt gọi

⚠ Session
   → ⚠ sống trong MỘT phiên hội thoại

⚠ MEMORY BANK
   → ⚠ sống QUA NHIỀU PHIÊN
   → ⚠ theo từng người dùng
   → ⚠ ĐỀ NÀY

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

• D (tăng cửa sổ ngữ cảnh của mô hình) — ⚠ bẫy mạnh nhất: cửa sổ lớn chứa được nhiều hơn trong một lượt gọi, nhưng ⚠ khi khách ngắt kết nối rồi quay lại thì cửa sổ đó không còn gì. Cửa sổ ngữ cảnh không phải bộ nhớ bền.

• A (fine-tune mô hình bằng dữ liệu khách hàng) — ⚠ sai hoàn toàn về kỹ thuật: không thể huấn luyện lại mô hình mỗi khi có một khách gọi điện. Còn là rủi ro riêng tư nghiêm trọng vì dữ liệu khách nằm trong trọng số.

• C (kho dữ liệu Vertex AI Search) — ⚠ dùng cho tài liệu tham khảo tĩnh (hướng dẫn khắc phục sự cố), không phải cho trạng thái riêng của từng khách hàng.

Ghi nhớ

⚠ Ba tầng bộ nhớ của agent — bảng phải thuộc: | Tầng | Phạm vi | Dùng cho | |---|---|---| | Ngữ cảnh prompt | ⚠ một lượt gọi | thông tin tức thời | | Session | ⚠ một phiên | ⚠ hội thoại đang diễn ra | | ⚠ Memory Bank | ⚠ NHIỀU PHIÊN, theo người dùng | ⚠ sở thích, lịch sử — đề này |

Từ khoá nhận diện:

"nhớ lần trước, không bắt lặp lại, nhiều lần liên hệ" → ⚠ Memory Bank "tài liệu dài trong một lần hỏi" → ⚠ cửa sổ ngữ cảnh "tài liệu tham khảo chung" → Vertex AI Search "giọng văn, phong cách" → fine-tuning

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ nhớ có gắn đúng danh tính đã xác thực không | ⚠ rủi ro lẫn khách là nghiêm trọng nhất | | Khách có xoá được lịch sử không | ⚠ quyền theo luật ở EU | | Thông tin cũ có được làm mới không | ⚠ đặt thời hạn |

Và ranh giới cần nhớ rõ: cửa sổ ngữ cảnh là trí nhớ ngắn hạn trong một cuộc trò chuyện, Memory Bank là hồ sơ bền qua thời gian. Nhầm hai thứ này dẫn tới thiết kế một agent quên sạch mọi thứ ngay khi khách gác máy.

Đáp án

D — Deep Research, agent dựng sẵn trong Gemini Enterprise.

Vì sao đúng

Đề nêu bốn ràng buộc và phương án D khớp cả bốn:

⚠ Ghép từng ràng buộc:

"6–8 giờ thu thập thủ công từ
 nguồn công khai, báo cáo nội bộ,
 website đối thủ"
    → ⚠ nghiên cứu ĐA NGUỒN

"giảm mạnh thời gian nghiên cứu"
    → ⚠ tự động hoá nhiều bước

"đầu ra CÓ TRÍCH DẪN, nhà phân
 tích KIỂM CHỨNG được"
    → ⚠ Deep Research trả về
      kèm nguồn

"KHÔNG phải tự xây từ đầu,
 có giá trị NGAY"
    → ⚠ agent DỰNG SẴN

⚠ Deep Research làm gì:

⚠ Nhận một câu hỏi nghiên cứu
        ↓
⚠ TỰ LẬP KẾ HOẠCH các hướng tìm
        ↓
⚠ Tìm qua nhiều nguồn, nhiều vòng
        ↓
⚠ Tổng hợp thành báo cáo có cấu trúc
        ↓
⚠ KÈM TRÍCH DẪN từng phần

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

• B (Vertex AI Agent Builder với phát triển agent tuỳ chỉnh) — ⚠ đúng thứ đề nói muốn tránh: "without requiring teams to build custom solutions from scratch".

• A (Gemini for Workspace để phân tích tài liệu) — ⚠ bẫy hợp lý: nó phân tích được tài liệu bạn đưa cho nó. Nhưng ⚠ nó không TỰ ĐI TÌM qua nhiều nguồn và không tự lập kế hoạch nghiên cứu nhiều vòng — mà đó là phần chiếm 6–8 giờ.

• C (Vertex AI Search để truy xuất dữ liệu doanh nghiệp) — ⚠ chỉ giải một phần: tìm trong báo cáo nội bộ. Không lo được nguồn công khai và website đối thủ, và ⚠ không tổng hợp thành báo cáo.

Ghi nhớ

⚠ Bốn công cụ và mức tự động — bảng phải thuộc: | Công cụ | Mức tự động | |---|---| | ⚠ Deep Research | ⚠ TỰ lập kế hoạch, tự tìm, tự tổng hợp — đề này | | Vertex AI Search | ⚠ tìm khi được hỏi | | Gemini for Workspace | ⚠ xử lý tài liệu bạn đưa | | Agent Builder | ⚠ tự xây — mất thời gian |

Từ khoá nhận diện:

"nghiên cứu nhiều nguồn, có trích dẫn, dùng ngay" → ⚠ Deep Research "tự xây agent riêng" → ⚠ Agent Builder — loại khi đề nói không muốn xây "tìm trong tài liệu nội bộ" → Vertex AI Search "soạn thảo trong Docs" → Gemini for Workspace

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trích dẫn có dẫn tới nội dung đúng không | ⚠ mở vài nguồn ra đối chiếu | | Nguồn cũ tới mức nào | ⚠ kiểm ngày xuất bản | | Có bỏ sót nguồn quan trọng không | ⚠ so với danh sách nhà phân tích thường dùng |

Và điều đáng lưu ý về giá trị thật của công cụ này: nó rút ngắn phần THU THẬP, không rút ngắn phần PHÁN ĐOÁN. Sáu tiếng tìm tài liệu có thể xuống còn nửa tiếng, nhưng phần khiến khách hàng trả tiền cho một hãng tư vấn vẫn là kết luận mà nhà phân tích rút ra sau đó.

Đáp án

B — Dịch vụ AI phải cấu hình được để chạy HOÀN TOÀN trong một region của Google Cloud đặt tại Pháp.

Vì sao đúng

Đề nêu ràng buộc pháp lý rất rõ: dữ liệu thô VÀ mọi xử lý AI trên dữ liệu đó đều phải nằm trong biên giới Pháp.

⚠ Điểm mấu chốt — hai vế:

"raw data"
    → ⚠ phải LƯU ở Pháp

"AND any AI PROCESSING of
 that data"
    → ⚠ phải XỬ LÝ ở Pháp
        ↓
⚠ Nhiều người chỉ nhớ vế đầu
⚠ Vế thứ hai mới là chỗ hay sai:
  ⚠ mô hình chạy ở đâu?

⚠ Vì sao phải kiểm cấu hình region của DỊCH VỤ:

⚠ Lưu dữ liệu ở Pháp là dễ
   → chọn region cho bucket

⚠ Nhưng gọi mô hình có thể
   ⚠ đi ra endpoint toàn cầu
   ⚠ xử lý ở nơi khác
        ↓
⚠ Phải chọn ENDPOINT theo region
⚠ Phải kiểm mô hình đó CÓ SẴN
   ở region Pháp không

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

• D (mọi dữ liệu được mã hoá khi lưu và khi truyền) — ⚠ bẫy mạnh nhất: đây là biện pháp bảo mật bắt buộc và mặc định có, nhưng ⚠ mã hoá KHÔNG giải quyết chủ quyền dữ liệu. Dữ liệu mã hoá đặt ở nước khác vẫn nằm ở nước khác về mặt pháp lý.

• A (dùng mô hình từ Model Garden vì được đảm bảo an toàn nhất) — ⚠ phát biểu sai: Model Garden là danh mục mô hình, không có đảm bảo nào như vậy, và nó không nói gì về vị trí xử lý.

• C (mô hình có độ trễ thấp nhất) — ⚠ yếu tố hiệu năng, hoàn toàn không liên quan tới yêu cầu pháp lý.

Ghi nhớ

⚠ Ba khái niệm hay bị lẫn — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | ⚠ Data residency | ⚠ dữ liệu LƯU ở đâu | | ⚠ Data sovereignty | ⚠ LUẬT NƯỚC NÀO áp dụng lên dữ liệu — đề này | | Mã hoá | ⚠ ai ĐỌC được dữ liệu | | ⚠ Lưu ý | ⚠ mã hoá không thay được hai cái đầu |

Từ khoá nhận diện:

"phải ở lại trong biên giới nước X" → ⚠ chọn region ở nước đó "kể cả việc XỬ LÝ" → ⚠ kiểm endpoint của dịch vụ AI, không chỉ nơi lưu "mã hoá là đủ" → ⚠ luôn SAI với yêu cầu chủ quyền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình cần dùng có ở region Pháp không | ⚠ kiểm bảng khả dụng theo region | | Sao lưu và log lưu ở đâu | ⚠ hai chỗ hay lọt ra ngoài nhất | | Có chính sách tổ chức chặn tạo tài nguyên ngoài region không | ⚠ phòng lỗi con người |

Và điều dễ bị bỏ sót nhất trong các dự án AI có yêu cầu chủ quyền: nơi mô hình chạy, chứ không phải nơi dữ liệu nằm yên. Dữ liệu ngoan ngoãn ở Paris nhưng mỗi lời gọi mô hình lại gửi nó đi nơi khác thì yêu cầu pháp lý vẫn bị vi phạm.