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

Đáp án

B — Cách tiếp cận "AI-first" đã ăn sâu của Google và bề dày đổi mới AI nền tảng.

Vì sao đúng

Công ty tìm đối tác có thành tích tiên phong trong nghiên cứu AI, và nghiên cứu đó chuyển hoá đều đặn thành dịch vụ và hạ tầng AI tích hợp. Đó chính là đặc điểm AI-first.

⚠ Chuỗi nghiên cứu → sản phẩm:

⚠ NGHIÊN CỨU NỀN TẢNG
    → ⚠ Transformer — kiến trúc nền
      của gần như mọi LLM hiện nay
    → TensorFlow, JAX
        ↓
⚠ PHẦN CỨNG
    → TPU qua nhiều thế hệ
        ↓
⚠ MÔ HÌNH
    → Gemini, Imagen, Veo, Gemma
        ↓
⚠ DỊCH VỤ TÍCH HỢP
    → Vertex AI, Workspace,
      Search, Cloud
        ↓
    ⚠ Kiểm chứng ở quy mô tỉ
      người dùng trong sản phẩm
      của chính Google

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

"Giá cạnh tranh cho máy ảo thường"
    → ⚠ về chi phí hạ tầng cơ bản

"Nhiều lựa chọn lưu trữ dữ liệu"
    → ⚠ về hạ tầng dữ liệu

"Marketplace phần mềm bên thứ ba"
    → ⚠ về hệ sinh thái đối tác

⚠ Gần trùng với #13886 (lô 145) — đề đó cũng là công ty ưu tiên đối tác đầu tư vào nghiên cứu, cùng khoá AI-first. Hoàn toàn nhất quán.

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

• D (marketplace bên thứ ba) — phương án gần nhất về mặt "cũng nói tới phạm vi năng lực có sẵn", nhưng đó là hệ sinh thái đối tác, không phải năng lực nghiên cứu nội tại.

• A và C — về giá và lưu trữ.

Ghi nhớ

⚠ Sáu điểm mạnh nền tảng — ghép đúng mối lo: | Mối lo trong đề | Điểm mạnh | |---|---| | ⚠ Đổi mới, nghiên cứu tiên phong | ⚠ AI-first | | Bảo mật, riêng tư, tuân thủ | tính năng doanh nghiệp | | Tải lớn, uptime | scalability, reliability | | Khoá chân, linh hoạt | cách tiếp cận mở | | Gắn với đầu tư sẵn có | hệ sinh thái tích hợp | | Rủi ro và quản trị AI | SAIF |

Từ khoá nhận diện:

"tiên phong nghiên cứu, công nghệ mới nhất" → ⚠ AI-first "mã nguồn mở, tương tác" → cách tiếp cận mở "tải toàn cầu biến động" → scalability, reliability "dữ liệu nhạy cảm" → bảo mật doanh nghiệp

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đổi mới hay ổn định là ưu tiên thật | ⚠ hai thứ đôi khi đối lập | | Đã ghim phiên bản mô hình chưa | ⚠ để đầu ra không đổi bất ngờ | | Đội cập nhật kiến thức bằng cách nào | ⚠ lĩnh vực này đổi rất nhanh |

Và cái giá đi kèm với việc chọn một nền tảng đổi mới nhanh: những gì hoạt động tốt hôm nay có thể cần điều chỉnh sau vài tháng. Đó là lý do việc ghim phiên bản mô hình và có bộ kiểm thử ổn định là phần không thể thiếu của một chiến lược AI dài hạn.

Đáp án

B — 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

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

• C và D — 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ế.

Đáp án

A — Infrastructure (hạ tầng).

Vì sao đúng

Đề nói về phần cứng tính toán chuyên dụng (TPU, GPU), mạng tốc độ cao và lưu trữ — tất cả do nhà cung cấp đám mây vận hành. Đó là tầng hạ tầng.

⚠ Ánh xạ vào bốn tầng:

⚠ INFRASTRUCTURE
    → ⚠ TPU, GPU, mạng, lưu trữ
    → ⚠ ĐỀ NÀY

MODELS
    → bản thân mô hình nền

PLATFORMS
    → công cụ xây và vận hành

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

⚠ Cách hỏi để phân tầng:

"Thứ được nhắc tới LÀ GÌ?"
        ↓
    ⚠ Chip, mạng, lưu trữ
      → ⚠ HẠ TẦNG
    Mô hình → MÔ HÌNH
    Công cụ xây → NỀN TẢNG
    Người dùng bấm → ỨNG DỤNG

⚠ Đối chiếu #13878 (lô 145) khoá Application và #13899 (lô 145) khoá Models. Ba đề cùng khung bốn tầng, hỏi ba tầng khác nhau. Không mâu thuẫn — luôn đọc kỹ câu hỏi hỏi về thành phần nào.

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

• C (Platforms) — phương án gần nhất vì Vertex AI chạy trên hạ tầng này và cũng do nhà cung cấp quản lý. Nhưng đề liệt kê rõ phần cứng, mạng, lưu trữ, tức tầng dưới cùng.

• D (Models) và B (Applications) — nằm ở tầng trên.

Ghi nhớ

⚠ Bốn tầng — bảng phải thuộc: | Tầng | Nội dung | Ví dụ | |---|---|---| | ⚠ Infrastructure | ⚠ phần cứng, mạng, lưu trữ | ⚠ TPU, GPU, AI Hypercomputer | | Models | ⚠ mô hình nền | Gemini, Imagen, Gemma | | Platforms | ⚠ công cụ xây và vận hành | ⚠ Vertex AI, Agent Builder | | Applications | ⚠ người dùng cuối dùng | ⚠ ứng dụng Gemini, app của bạn |

Từ khoá nhận diện:

"chip, mạng, lưu trữ, phần cứng" → ⚠ Infrastructure "mô hình huấn luyện sẵn" → Models "công cụ để xây và triển khai" → Platforms "người dùng tương tác trực tiếp" → Applications

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có cần huấn luyện mô hình nền thật không | ⚠ gần như luôn là không | | Mức sử dụng bộ tăng tốc bao nhiêu | ⚠ thấp thì tối ưu trước khi mua thêm | | Đã dùng Spot chưa | ⚠ giảm chi phí đáng kể |

Và cách phân biệt bốn tầng nhanh nhất khi làm bài: hỏi xem thứ được nhắc tới có thể "cầm nắm" hay không. Chip, mạng và ổ đĩa thuộc tầng dưới cùng; mọi thứ còn lại phân biệt bằng việc ai là người sử dụng nó.

Đáp án

C — Structured Data (dữ liệu có cấu trúc).

Vì sao đúng

Cơ sở dữ liệu quan hệ với các trường xác định rõ (CustomerID, Name, Address, Email, LastPurchaseDate) tổ chức thành bảng có hàng và cột — đó là định nghĩa của dữ liệu có cấu trúc.

⚠ Dấu hiệu của dữ liệu có cấu trúc:

⚠ Có SCHEMA định trước
⚠ Mỗi trường có KIỂU dữ liệu rõ
⚠ Tổ chức thành HÀNG và CỘT
⚠ Truy vấn được bằng SQL
        ↓
    ⚠ Đề nêu đủ cả bốn dấu hiệu

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

"Semi-structured"
    → ⚠ JSON, XML: có thẻ nhưng
      KHÔNG có schema cứng

"Unstructured"
    → ⚠ ảnh, video, văn bản tự do

"Qualitative Data"
    → ⚠ thuật ngữ về dữ liệu ĐỊNH TÍNH
      (mô tả, không đo được bằng số)
    → ⚠ không phải cách phân loại
      theo CẤU TRÚC

Nhất quán với #13525 và #13553 (lô 144) về ba loại dữ liệu, và #13888 (lô 145) về ghi chú y khoa phi cấu trúc. Hoàn toàn nhất quán — đây là mặt đối lập.

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

• A (semi-structured) — phương án gần nhất và là bẫy chính: cũng có tổ chức nhất định. Nhưng bán cấu trúc không có schema cứng, còn đây là bảng quan hệ với trường xác định rõ.

• D (unstructured) — trái hẳn.

• B (định tính) — thuộc cách phân loại khác.

Ghi nhớ

⚠ Ba loại dữ liệu theo cấu trúc — bảng phải thuộc: | Loại | Ví dụ | Lưu ở | |---|---|---| | ⚠ Có cấu trúc | ⚠ bảng CSDL, CSV, bảng tính | ⚠ Cloud SQL, BigQuery | | ⚠ Bán cấu trúc | ⚠ JSON, XML, log, YAML | ⚠ Firestore, BigQuery | | ⚠ Phi cấu trúc | ⚠ ảnh, video, âm thanh, văn bản tự do | ⚠ Cloud Storage |

Từ khoá nhận diện:

"hàng, cột, trường xác định rõ" → ⚠ có cấu trúc "JSON, XML, có thẻ nhưng linh hoạt" → bán cấu trúc "ảnh, video, văn bản tự do" → phi cấu trúc "đã được gán nhãn" → ⚠ labeled — chiều KHÁC

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có schema cố định không | có → ⚠ có cấu trúc | | Truy vấn được bằng SQL không | ⚠ dấu hiệu rõ nhất | | Có PII trong đó không | ⚠ gần như chắc chắn có với dữ liệu khách hàng |

Và điều đáng nhớ khi hai cách phân loại dữ liệu cùng xuất hiện trong một bộ đáp án: "có cấu trúc" và "đã gán nhãn" trả lời hai câu hỏi khác nhau. Câu đầu hỏi dữ liệu được TỔ CHỨC ra sao, câu sau hỏi nó có kèm ĐÁP ÁN cho việc huấn luyện hay không.

Đáp án

C — Multimodal Foundation Model (mô hình nền đa phương thức).

Vì sao đúng

Công cụ phải nhận VĂN BẢN, ÂM THANH và ẢNH làm đầu vào rồi sinh ra VIDEO. Xử lý nhiều loại dữ liệu cùng lúc là định nghĩa của mô hình đa phương thức.

⚠ Đếm số modality trong đề:

ĐẦU VÀO:
    ⚠ kịch bản — VĂN BẢN
    ⚠ lời thoại — ÂM THANH
    ⚠ mood board — ẢNH

ĐẦU RA:
    ⚠ quảng cáo — VIDEO
        ↓
    ⚠ BỐN modality trong một
      quy trình
        ↓
    → ⚠ bắt buộc phải đa phương thức

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

"LLM đơn phương thức"
    → ⚠ chỉ xử lý VĂN BẢN

"Diffusion chuyên cho ẢNH"
    → ⚠ chỉ sinh ảnh tĩnh, không
      nhận âm thanh

"Mô hình học không giám sát
 cho phân cụm"
    → ⚠ không phải mô hình SINH

Nhất quán với #13870 (lô 145) — đề đó về Gemini đa phương thức cho trợ lý lập trình có tham chiếu sơ đồ. Cùng khái niệm. Đối chiếu #13941 (cùng lô) khoá Veo khi đầu vào chỉ là văn bản. Không mâu thuẫn — số modality đầu vào khác nhau.

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

• B (diffusion chỉ cho ảnh) — phương án gần nhất vì diffusion có tham gia vào việc sinh hình ảnh và video. Nhưng một mô hình chỉ xử lý ảnh không nhận được kịch bản và lời thoại.

• A và D — không đáp ứng yêu cầu đa phương thức hoặc không phải mô hình sinh.

Ghi nhớ

⚠ Đơn phương thức và đa phương thức — bảng phải thuộc: | Loại | Đầu vào | Ví dụ | |---|---|---| | Unimodal LLM | ⚠ chỉ văn bản | mô hình ngôn ngữ thuần | | Diffusion ảnh | ⚠ văn bản → ảnh | Imagen | | ⚠ Multimodal | ⚠ văn bản + ảnh + âm thanh + video | ⚠ Gemini |

Từ khoá nhận diện:

"nhiều loại đầu vào cùng lúc" → ⚠ multimodal "chỉ văn bản" → unimodal LLM "văn bản → video" → ⚠ Veo "văn bản → ảnh" → Imagen

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có bao nhiêu loại dữ liệu vào và ra | ⚠ quyết định cần đa phương thức hay không | | Chi phí cho một quảng cáo là bao nhiêu | ⚠ video rất đắt | | Ai duyệt trước khi phát sóng | ⚠ nội dung quảng cáo có ràng buộc pháp lý |

Và cách đọc nhanh mọi câu hỏi kiểu này: đếm số loại dữ liệu xuất hiện ở đầu vào. Chỉ cần nhiều hơn một là câu trả lời gần như chắc chắn nằm ở nhóm mô hình đa phương thức.

Đáp án

B — Nó cung cấp cho mô hình nền thông tin HIỆN HÀNH và CỤ THỂ từ kho tri thức, để sinh ra câu trả lời chính xác và liên quan hơn.

Vì sao đúng

Vấn đề là chatbot đưa thông tin lỗi thời từ kiến thức huấn luyện chung. RAG chữa đúng chỗ đó: tra kho tri thức cập nhật trước khi trả lời.

⚠ Vấn đề và cách RAG chữa:

Sản phẩm MỚI ra mắt
        ↓
    ⚠ Mô hình huấn luyện TRƯỚC đó
    ⚠ → knowledge cutoff
        ↓
    ⚠ Nó trả lời bằng chính sách CŨ
      mà không biết là đã cũ
        ↓
⚠ RAG
    → ⚠ tra kho tri thức CẬP NHẬT
    → ⚠ đưa chính sách HIỆN HÀNH
      vào ngữ cảnh
    → ⚠ mô hình trả lời dựa trên đó
        ↓
    → chính xác và có trích dẫn

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

"Làm câu trả lời SÁNG TẠO và
 ĐA DẠNG hơn"
    → ⚠ NGƯỢC với mục tiêu: chính
      sách bảo hành cần CHÍNH XÁC

"GIẢM chi phí tính toán"
    → ⚠ RAG THÊM bước tra cứu,
      thường TĂNG chi phí một chút

"TỰ ĐỘNG fine-tune mô hình với
 dữ liệu sản phẩm mới HẰNG NGÀY"
    → ⚠ RAG KHÔNG huấn luyện lại
      mô hình — đó là điểm mạnh của nó

⚠ Gần trùng với #13900 và #13913 (lô 145) — cả ba đều là RAG chữa vấn đề thiếu thông tin riêng và cập nhật, cùng khoá. Hoàn toàn nhất quán. Và #13874 (lô 145) về knowledge cutoff.

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

• D (tự động fine-tune hằng ngày) — phương án gần nhất và là bẫy chính: cũng nhắm tới việc cập nhật kiến thức. Nhưng RAG không huấn luyện lại; nó tra cứu tại thời điểm trả lời — và đó chính là ưu điểm của nó.

• A và C — mô tả sai tác dụng.

Ghi nhớ

⚠ RAG chữa được gì và không chữa được gì: | Chữa được | Không chữa được | |---|---| | ⚠ Knowledge cutoff | ⚠ thiên vị của mô hình | | ⚠ Thiếu kiến thức riêng | ⚠ lỗi trong chính tài liệu nguồn | | ⚠ Ảo giác về sự kiện | ⚠ phong cách, giọng văn | | Không trích dẫn được nguồn | ⚠ năng lực suy luận của mô hình |

Từ khoá nhận diện:

"thông tin lỗi thời, sản phẩm mới" → ⚠ RAG "giọng văn chưa đúng thương hiệu" → fine-tuning "muốn sáng tạo hơn" → ⚠ tăng temperature "giảm chi phí" → ⚠ mô hình nhỏ hơn, cache, batch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu bảo hành có phải bản mới nhất không | ⚠ kiểm ngày cập nhật | | Có bản cũ nào còn trong chỉ mục không | ⚠ nguồn gây trả lời sai | | Hỏi về sản phẩm chưa có tài liệu thì sao | ⚠ phải nói không biết |

Và nguyên nhân phổ biến khiến một hệ thống RAG vẫn trả lời sai dù đã được dựng đúng: phiên bản tài liệu cũ chưa được gỡ khỏi chỉ mục. Mô hình tra được cả hai bản và không có cách nào biết bản nào còn hiệu lực — nên việc dọn tài liệu lỗi thời quan trọng ngang việc thêm tài liệu mới.

Đáp án

A — Vertex AI Agent Builder.

Vì sao đúng

Đề cần môi trường vững chắc để PHÁT TRIỂN, KIỂM THỬ và TRIỂN KHAI một agent dùng công cụ: hiểu yêu cầu phức tạp, hỏi lại để làm rõ, gọi API chuyến bay và khách sạn theo thời gian thực, và giúp đặt trọn hành trình.

⚠ Bốn năng lực đề nêu:

"hiểu yêu cầu PHỨC TẠP"
    → ⚠ mô hình nền mạnh

"HỎI LẠI để làm rõ"
    → ⚠ quản lý hội thoại nhiều lượt

"gọi API THỜI GIAN THỰC"
    → ⚠ tool / function calling

"môi trường phát triển, kiểm thử,
 triển khai"
    → ⚠ đây là điểm quyết định:
      cần NỀN TẢNG, không phải
      công cụ rời

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

"Dùng Gemini API với mã Python tự
 viết, KHÔNG có framework agent"
    → ⚠ làm được, nhưng phải TỰ dựng
      điều phối, quản trạng thái,
      kiểm thử — đúng thứ đề muốn tránh

"Dialogflow ES"
    → ⚠ thế hệ CŨ, luồng hội thoại
      cứng; ⚠ không hợp agent AI sinh
      dùng công cụ

"Google AI Studio để làm mẫu nhanh"
    → ⚠ THỬ prompt, không phải nơi
      triển khai agent sản xuất

⚠ Gần trùng với #13858 (lô 145) — đề đó cũng là agent doanh nghiệp có tích hợp hệ thống, cùng khoá Agent Builder. Đối chiếu #13936 (cùng lô) khoá Gemini Enterprise vì ở đó là không gian làm việc cho NHÂN VIÊN, còn đây là agent phục vụ khách hàng do đội tự xây. Không mâu thuẫn.

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

• B (Gemini API + mã tự viết) — phương án gần nhất và hoàn toàn khả thi, nhưng đề nói rõ cần môi trường vững chắc cho cả vòng phát triển–kiểm thử–triển khai.

• C (Dialogflow ES) và D (AI Studio) — thế hệ cũ và công cụ thử nghiệm.

Ghi nhớ

⚠ Chọn công cụ agent — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | ⚠ Agent tuỳ biến dùng công cụ, cho sản phẩm | ⚠ Vertex AI Agent Builder | | ⚠ Không gian làm việc AI cho nhân viên | ⚠ Gemini Enterprise / Agentspace | | Hội thoại luồng cứng, IVR | ⚠ Dialogflow CX | | Thử prompt nhanh | ⚠ AI Studio | | Toàn quyền, đội mạnh | ⚠ Gemini API + framework tự chọn |

Từ khoá nhận diện:

"agent dùng công cụ, môi trường phát triển đầy đủ" → ⚠ Agent Builder "nhân viên nội bộ, dashboard" → Gemini Enterprise "luồng hội thoại định trước" → Dialogflow CX "thử prompt" → AI Studio

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent gọi được API nào | ⚠ phân loại đọc/ghi, siết quyền | | Hành động quan trọng có xác nhận không | ⚠ bắt buộc | | Có thử prompt injection chưa | ⚠ trước khi ra sản xuất |

Và ranh giới thiết kế quan trọng nhất cho một agent có khả năng đặt chỗ: phân tách rõ giữa việc agent được TRA CỨU và việc agent được ĐẶT. Nhóm thứ nhất càng tự do càng hữu ích; nhóm thứ hai nên luôn đi qua một lần xác nhận của con người.

Đáp án

B — Hallucination (ảo giác).

Vì sao đúng

Mô hình sinh ra tiểu sử chi tiết với sự kiện và mối quan hệ chưa từng có trong cuốn sách, văn phong trôi chảy và nghe hợp lý nhưng sai sự thật. Đó chính là ảo giác.

⚠ Đặc điểm nhận diện ảo giác:

⚠ TRÔI CHẢY và NGHE HỢP LÝ
⚠ CHI TIẾT cụ thể
⚠ ⚠ NHƯNG SAI SỰ THẬT
⚠ Mô hình KHÔNG báo là nó không chắc
        ↓
    ⚠ Đó là điều làm ảo giác
      NGUY HIỂM: nó không trông
      giống một lỗi

⚠ Vì sao mô hình bịa:

⚠ Mô hình dự đoán TỪ TIẾP THEO
  có khả năng cao nhất
        ↓
    ⚠ Nó tối ưu cho tính TRÔI CHẢY,
      không phải cho tính ĐÚNG
        ↓
    ⚠ Khi thiếu thông tin, nó vẫn
      sinh ra thứ nghe hợp lý
        ↓
    → ⚠ đây không phải "lỗi" mà là
      hệ quả của cách nó hoạt động

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

"Knowledge cutoff"
    → ⚠ không biết chuyện SAU ngày
      huấn luyện; nhân vật tiểu thuyết
      không liên quan tới thời gian

"Bias"
    → ⚠ đối xử lệch giữa các nhóm

"Edge cases"
    → ⚠ trường hợp biên hiếm gặp;
      ⚠ ảo giác KHÔNG hiếm, nó là
      hạn chế cơ bản

Nhất quán với #13874 (lô 145) — đề đó phân biệt knowledge cutoff với ảo giác. Và #13917 (cùng lô) phân biệt bias với ảo giác. Ba đề vẽ đủ bộ hạn chế của mô hình nền.

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

• A (knowledge cutoff) — phương án gần nhất và là bẫy chính: cả hai đều khiến câu trả lời sai. Nhưng cutoff là không biết chuyện MỚI, còn đây là bịa ra chi tiết chưa từng tồn tại.

• D (bias) và C (edge cases) — không mô tả đúng hiện tượng.

Ghi nhớ

⚠ Hạn chế mô hình nền — phân biệt cho rõ: | Hạn chế | Dấu hiệu | |---|---| | ⚠ Hallucination | ⚠ BỊA chi tiết, trôi chảy nhưng SAI | | Knowledge cutoff | ⚠ không biết chuyện SAU ngày huấn luyện | | Bias | ⚠ lệch giữa các nhóm | | Context window | ⚠ không nhận nổi tài liệu dài | | Không tính toán chính xác | ⚠ sai số học |

Từ khoá nhận diện:

"trôi chảy, hợp lý, nhưng sai sự thật" → ⚠ hallucination "không biết sự kiện gần đây" → knowledge cutoff "lệch giữa các nhóm" → bias "tài liệu quá dài" → context window

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi tiết có trong nguồn gốc không | ⚠ đối chiếu trực tiếp | | Trích dẫn có tồn tại không | ⚠ mở liên kết ra | | Mô hình có nói được "không biết" không | ⚠ thử hỏi thứ không có |

Và điều làm ảo giác nguy hiểm hơn mọi lỗi khác của mô hình: nó không trông giống một lỗi. Một câu trả lời sai được viết vụng về sẽ bị nghi ngờ ngay, còn một tiểu sử bịa được viết mạch lạc và giàu chi tiết thì đi thẳng qua mọi lớp kiểm tra bằng cảm quan.

Đáp án

A — 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.

• B và C — 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 đó.

Đáp án

A — Top-p (nucleus) sampling.

Vì sao đúng

Dấu hiệu quyết định nằm ngay trong đề: giới hạn lựa chọn vào một nhóm từ mà TỔNG XÁC SUẤT đạt một mức nhất định. Đó chính là cơ chế của top-p.

⚠ Ba tham số, ba cơ chế khác nhau:

⚠ TEMPERATURE
    → ⚠ làm PHẲNG hay NHỌN toàn bộ
      phân phối xác suất
    → không cắt bỏ từ nào

⚠ TOP-K
    → ⚠ chỉ giữ K từ khả năng nhất
    → ⚠ SỐ LƯỢNG cố định

⚠ TOP-P (nucleus)
    → ⚠ giữ nhóm từ có TỔNG XÁC SUẤT
      đạt P
    → ⚠ SỐ LƯỢNG THAY ĐỔI theo
      từng bước
    → ⚠ ĐỀ NÀY

⚠ Vì sao top-p linh hoạt hơn top-k:

Khi mô hình RẤT CHẮC CHẮN
    → một từ chiếm xác suất áp đảo
    → ⚠ top-p chỉ giữ VÀI từ
    → tránh từ vô nghĩa

Khi mô hình KHÔNG chắc
    → xác suất trải đều
    → ⚠ top-p giữ NHIỀU từ
    → giữ được sự đa dạng
        ↓
    ⚠ top-k thì luôn giữ đúng K từ,
      không thích nghi được

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

"Temperature"
    → ⚠ điều chỉnh độ ngẫu nhiên
      TỔNG THỂ, không cắt theo
      xác suất tích luỹ

"Top-k"
    → ⚠ cắt theo SỐ LƯỢNG, không
      theo tổng xác suất

"Output length"
    → ⚠ giới hạn ĐỘ DÀI

⚠ Đối chiếu #13876 và #13890 (lô 145) — hai đề đó khoá temperature cho mục tiêu xác định hơn hoặc sáng tạo hơn. Đề này hỏi riêng tham số hoạt động theo xác suất tích luỹ. Không mâu thuẫn — ba tham số, ba cơ chế, cùng tồn tại.

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

• C (top-k) — phương án gần nhất và là bẫy chính: cũng thu hẹp tập từ được chọn. Nhưng nó cắt theo số lượng cố định, còn đề nói rõ tổng xác suất.

• B (temperature) — làm đổi độ ngẫu nhiên nhưng không loại từ theo ngưỡng tích luỹ.

• D — không liên quan tới việc chọn từ.

Ghi nhớ

⚠ Ba tham số lấy mẫu — bảng phải thuộc: | Tham số | Cơ chế | Tăng thì | |---|---|---| | ⚠ Temperature | ⚠ phẳng/nhọn phân phối | ⚠ đa dạng hơn | | ⚠ Top-K | ⚠ giữ K từ khả năng nhất | ⚠ đa dạng hơn | | ⚠ Top-P | ⚠ giữ nhóm đạt tổng xác suất P | ⚠ đa dạng hơn |

Từ khoá nhận diện:

"tổng xác suất tích luỹ" → ⚠ top-p (nucleus) "K từ khả năng nhất" → ⚠ top-k "độ ngẫu nhiên, sáng tạo hay xác định" → ⚠ temperature "giới hạn độ dài" → max output tokens

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đổi tham số có cải thiện thật không | ⚠ đo trên bộ test cố định | | Có bị lặp từ không | ⚠ top-p quá thấp gây lặp | | Đã ghi lại bộ tham số chưa | ⚠ để tái lập kết quả |

Và nguyên tắc gọn khi tinh chỉnh các tham số này: đổi một thứ mỗi lần, đo trên cùng một bộ ví dụ. Chỉnh đồng thời cả ba rồi thấy kết quả khá hơn là cách chắc chắn nhất để không bao giờ biết được điều gì đã tạo ra khác biệt.