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

Đáp án

B — Gemma.

Vì sao đúng

Ba dữ kiện chỉ thẳng vào Gemma: mô hình MỞ, nhẹ, chạy được trên máy tính cá nhân, và cùng công nghệ nền với các mô hình lớn của Google.

⚠ Ba dữ kiện khớp:

"mô hình MỞ, tương đối NHẸ"
    → ⚠ Gemma là dòng mô hình mở
      với nhiều kích thước nhỏ

"chạy trên LAPTOP cá nhân"
    → ⚠ Gemma chạy được tại chỗ,
      không cần gọi API

"cùng CÔNG NGHỆ với mô hình lớn
 của Google"
    → ⚠ Gemma xây trên cùng nền
      nghiên cứu với Gemini

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

"Gemini Pro"
    → ⚠ mạnh hơn nhiều, nhưng
      ⚠ dùng QUA API, không chạy
      trên laptop

"Imagen" → ⚠ sinh ẢNH
"Veo"    → ⚠ sinh VIDEO

Nhất quán với #13870 (lô 145) — ở đề đó Gemma là phương án SAI vì yêu cầu là năng lực cao và đa phương thức. Ở đây yêu cầu là nhẹ, mở, chạy tại chỗ nên Gemma đúng. Không mâu thuẫn — mỗi đề có tiêu chí khác nhau, và đó chính là cặp minh hoạ tốt cho ranh giới Gemini/Gemma.

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

• D (Gemini Pro) — phương án gần nhất và là bẫy chính: mạnh hơn và cũng dùng cho dự án lập trình được. Nhưng nó là dịch vụ gọi qua API, không phải mô hình tải về chạy trên laptop.

• A (Imagen) và C (Veo) — sai modality.

Ghi nhớ

⚠ Gemini và Gemma — bảng phải thuộc: | | ⚠ Gemini | ⚠ Gemma | |---|---|---| | Loại | ⚠ mô hình độc quyền, qua API | ⚠ mô hình MỞ, tải về được | | Năng lực | ⚠ cao nhất | ⚠ vừa phải | | Đa phương thức | ⚠ có | ⚠ hạn chế hơn | | ⚠ Chạy tại chỗ | ⚠ KHÔNG | ⚠ CÓ — điểm mạnh chính | | Dùng khi | ⚠ cần năng lực tối đa | ⚠ cần riêng tư, offline, chi phí thấp |

Từ khoá nhận diện:

"mô hình mở, nhẹ, chạy tại chỗ" → ⚠ Gemma "năng lực cao, đa phương thức" → Gemini "sinh ảnh" → Imagen "sinh video" → Veo

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Dữ liệu có được ra khỏi máy không | không → ⚠ mô hình mở tại chỗ | | Máy có đủ RAM/GPU không | ⚠ kiểm cấu hình tối thiểu của từng kích thước | | Tác vụ có cần suy luận phức tạp không | ⚠ có → cân nhắc mô hình lớn |

Và điều nhiều người bất ngờ khi thử mô hình mở lần đầu: với những tác vụ hẹp và lặp lại, một mô hình nhỏ chạy ngay trên máy thường đã đủ tốt. Khoảng cách năng lực chỉ lộ rõ ở những bài toán đòi suy luận nhiều bước — vốn không phải phần lớn công việc hằng ngày.

Đáp án

D — Diffusion Model (mô hình khuếch tán).

Vì sao đúng

Đề mô tả chính xác cơ chế của mô hình khuếch tán: bắt đầu từ nhiễu ngẫu nhiên, khử nhiễu dần từng bước, quá trình được dẫn hướng bởi câu lệnh văn bản.

⚠ Cơ chế khuếch tán:

HUẤN LUYỆN — chiều thuận
    → lấy ảnh thật
    → ⚠ thêm nhiễu DẦN qua nhiều bước
    → cho tới khi thành nhiễu thuần
    → ⚠ mô hình học cách ĐẢO NGƯỢC
      từng bước đó

SINH ẢNH — chiều nghịch
    → ⚠ bắt đầu từ NHIỄU ngẫu nhiên
    → ⚠ khử nhiễu từng bước trong
      không gian tiềm ẩn
    → ⚠ mỗi bước ĐƯỢC DẪN HƯỚNG
      bởi prompt
        ↓
    → ảnh MỚI, chưa từng tồn tại

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

"Transformer"
    → ⚠ kiến trúc chủ đạo cho
      NGÔN NGỮ; đề chú thích rõ
      "primarily for language"

"RNN"
    → ⚠ mạng hồi tiếp cho dữ liệu
      tuần tự, thế hệ trước
      transformer

"SVM"
    → ⚠ thuật toán PHÂN LOẠI cổ điển,
      ⚠ hoàn toàn KHÔNG sinh ra gì

Nhất quán với #13864 (lô 145) — cùng khoá diffusion model cho bài toán sinh ảnh từ văn bản. Đề này mô tả cơ chế chi tiết hơn. Và #13880 (lô 145) về Imagen — sản phẩm cụ thể dùng kiến trúc này.

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

• A (Transformer) — phương án gần nhất vì đó là kiến trúc nổi tiếng nhất trong AI sinh hiện nay và có tham gia vào phần hiểu prompt. Nhưng quá trình khử nhiễu lặp mà đề mô tả là đặc trưng của diffusion.

• C (RNN) và B (SVM) — không phải kiến trúc sinh ảnh.

Ghi nhớ

⚠ Kiến trúc theo modality — bảng phải thuộc: | Modality | Kiến trúc | Sản phẩm Google | |---|---|---| | Văn bản | ⚠ Transformer | ⚠ Gemini, Gemma | | ⚠ Ảnh | ⚠ DIFFUSION | ⚠ Imagen | | Video | ⚠ diffusion + transformer | Veo | | Âm thanh, nhạc | diffusion, transformer | Chirp, Lyria |

Từ khoá nhận diện:

"khử nhiễu dần, từ nhiễu ngẫu nhiên" → ⚠ diffusion "attention, sinh token tiếp theo" → ⚠ transformer "phân loại, siêu phẳng" → SVM — không sinh gì "dữ liệu tuần tự, thế hệ cũ" → RNN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần lặp lại đúng một ảnh | ⚠ ghi lại seed và mọi tham số | | Ảnh chưa đủ chi tiết | ⚠ tăng số bước, làm rõ prompt | | Chi phí | ⚠ tính theo số ảnh, số bước |

Và chi tiết đáng nhớ khi làm việc với công cụ sinh ảnh trong quy trình sản xuất: ghi lại seed cùng với prompt. Đó là cách duy nhất để quay lại đúng bức ảnh đã được duyệt, thay vì phải tạo lại và chấp nhận một kết quả gần giống.

Đáp án

D — Audio generation (sinh âm thanh) — cụ thể là sinh nhạc.

Vì sao đúng

Ứng dụng sáng tác nhạc nền cho video. Đầu ra là âm thanh, nên đây là bài toán sinh âm thanh / sinh nhạc.

⚠ Xác định bằng ĐẦU RA:

"tạo bản NHẠC NỀN độc đáo"
        ↓
    ⚠ đầu ra là ÂM THANH
        ↓
    → ⚠ audio / music generation

⚠ Lưu ý: hệ thống này cũng phân tích video để nắm tâm trạng và nhịp — nhưng đó là đầu vào, còn năng lực sinh mới là thứ đề hỏi.

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

"Image generation"  → ⚠ sinh ẢNH
"Text generation"   → ⚠ sinh VĂN BẢN
"Code generation"   → ⚠ sinh MÃ

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

• C (image generation) — phương án gần nhất về mặt "cũng là sinh nội dung đa phương tiện cho video", nhưng đầu ra ở đây là nhạc, không phải hình ảnh.

• B và A — sai modality.

Ghi nhớ

⚠ Năng lực sinh theo ĐẦU RA — bảng phải thuộc: | Đầu ra | Tên năng lực | Mô hình Google | |---|---|---| | Văn bản | text generation | ⚠ Gemini, Gemma | | Mã | code generation | ⚠ Gemini Code Assist | | Ảnh | image generation | ⚠ Imagen | | Video | video generation | ⚠ Veo | | ⚠ Nhạc, âm thanh | ⚠ audio generation | ⚠ Lyria, Chirp | | Giọng đọc | text-to-speech | ⚠ Text-to-Speech / Chirp |

Từ khoá nhận diện:

"sáng tác nhạc, tạo âm thanh" → ⚠ audio / music generation "đọc văn bản thành giọng nói" → ⚠ text-to-speech "chuyển giọng nói thành chữ" → speech-to-text "sinh video từ mô tả" → video generation

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Được dùng thương mại không | ⚠ đọc kỹ giấy phép | | Nhạc có khớp đúng độ dài video không | ⚠ vấn đề kỹ thuật thật | | Chi phí mỗi bản nhạc là bao nhiêu | ⚠ so với mua nhạc có sẵn |

Và cách đọc nhanh mọi câu hỏi về "loại AI sinh nào": nhìn vào thứ hệ thống TẠO RA, không nhìn thứ nó đọc vào. Một hệ thống xem video để viết nhạc vẫn là sinh âm thanh, dù đầu vào của nó thuộc về một modality khác hẳn.

Đáp án

D — Khả năng mở rộng và độ tin cậy (scalability và reliability).

Vì sao đúng

Đề nêu ba yêu cầu: khối lượng dữ liệu và yêu cầu KHỔNG LỒ, BIẾN ĐỘNG, đến từ khắp thế giới, cần thời gian hoạt động và hiệu năng ỔN ĐỊNH. Cả ba đều thuộc về khả năng mở rộng và độ tin cậy.

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

"khối lượng KHỔNG LỒ, BIẾN ĐỘNG"
    → ⚠ SCALABILITY — co giãn
      theo nhu cầu

"từ khắp THẾ GIỚI"
    → ⚠ hạ tầng toàn cầu, độ trễ thấp

"uptime và hiệu năng NHẤT QUÁN"
    → ⚠ RELIABILITY

⚠ Vì sao chuỗi cung ứng đòi hỏi cao:

Chuỗi cung ứng chạy 24/7
        ↓
    ⚠ Đỉnh theo mùa rất lớn
    ⚠ Sự cố ở một vùng không được
      làm dừng toàn hệ thống
    ⚠ Quyết định điều phối cần
      độ trễ thấp
        ↓
    → ⚠ co giãn tự động + đa vùng

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

"Giao diện low-code thân thiện"
    → ⚠ về tốc độ phát triển

"Thư viện mô hình mã nguồn mở phong phú"
    → ⚠ về lựa chọn mô hình

"Tập trung vào nguyên tắc AI có
 trách nhiệm"
    → ⚠ rất quan trọng, nhưng
      không giải quyết bài toán
      TẢI và UPTIME

Đối chiếu #13861 và #13895 (lô 145) — cùng nhóm "tính năng sẵn sàng doanh nghiệp" nhưng hai đề đó nhấn bảo mật và quyền riêng tư, đề này nhấn co giãn và độ tin cậy. Không mâu thuẫn — đọc kỹ mối lo mà đề nêu.

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

• C (AI có trách nhiệm) — phương án gần nhất vì đó là đặc điểm thật và quan trọng của nền tảng, nhưng nó không trả lời cho yêu cầu về khối lượng và thời gian hoạt động.

• A và B — nói về trải nghiệm phát triển và phạm vi mô hình.

Ghi nhớ

⚠ Điểm mạnh nền tảng — ghép với đúng mối lo: | Mối lo trong đề | Điểm mạnh | |---|---| | ⚠ Tải lớn, biến động, uptime | ⚠ scalability và reliability | | Dữ liệu nhạy cảm, tuân thủ | ⚠ bảo mật và quyền riêng tư | | Chống khoá chân | công nghệ mở | | Gắn với đầu tư sẵn có | hệ sinh thái tích hợp | | Rủi ro AI, quản trị | ⚠ SAIF | | Muốn công nghệ mới nhất | AI-first |

Từ khoá nhận diện:

"tải biến động, toàn cầu, uptime" → ⚠ scalability + reliability "dữ liệu bệnh nhân, tuân thủ" → bảo mật, riêng tư "đội ít kỹ thuật" → low-code "đối xử công bằng, giải thích được" → AI có trách nhiệm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quota hiện tại là bao nhiêu | ⚠ xin nâng trước mùa cao điểm | | Mô hình lỗi thì ứng dụng làm gì | ⚠ phải có phương án dự phòng | | Chi phí ở đỉnh tải | ⚠ nhân khối lượng thật rồi tính |

Và nút thắt đầu tiên mà hầu hết ứng dụng AI sinh chạm phải khi mở rộng không phải là máy chủ, mà là hạn mức lời gọi mô hình. Đó là con số nên kiểm tra và xin nâng trước, chứ không phải thứ để phát hiện vào đúng ngày lượng truy cập tăng vọt.

Đáp án

D — Natural Language Processing (NLP) — xử lý ngôn ngữ tự nhiên.

Vì sao đúng

NLP là lĩnh vực giúp máy tính hiểu, diễn giải và rút ra ý nghĩa từ ngôn ngữ của con người — đúng định nghĩa đề đưa ra, và đúng việc hệ thống đang làm.

⚠ Hai việc trong đề đều là NLP:

"tự động xác định CHỦ ĐỀ"
    → ⚠ topic extraction / phân loại

"xác định CẢM XÚC"
    → ⚠ sentiment analysis
        ↓
    ⚠ Cả hai đều là tác vụ NLP
      kinh điển

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

"Generative AI"
    → ⚠ TẠO RA nội dung mới;
      ở đây hệ thống PHÂN TÍCH và
      PHÂN LOẠI, không sinh gì
    (⚠ dù ngày nay LLM làm được
     việc này, KHÁI NIỆM đúng vẫn
     là NLP)

"Reinforcement Learning"
    → ⚠ phương pháp học qua
      thưởng/phạt

"AGI"
    → ⚠ trí tuệ nhân tạo tổng quát —
      ⚠ CHƯA TỒN TẠI

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

• B (Generative AI) — phương án gần nhất và là bẫy chính trong bối cảnh đề thi về AI sinh: ngày nay người ta hay dùng LLM cho việc này. Nhưng câu hỏi hỏi khái niệm mô tả năng lực hiểu ngôn ngữ, và đó là NLP.

• A (học tăng cường) — là phương pháp học, không phải lĩnh vực này.

• C (AGI) — khái niệm về AI có năng lực tổng quát như người, hiện chưa tồn tại.

Ghi nhớ

⚠ Quan hệ giữa các khái niệm — bảng phải thuộc: | Khái niệm | Quan hệ | |---|---| | ⚠ AI | ⚠ rộng nhất | | ⚠ Machine Learning | ⚠ tập con của AI — học từ dữ liệu | | ⚠ Deep Learning | ⚠ tập con của ML — mạng nơ-ron nhiều lớp | | ⚠ NLP | ⚠ LĨNH VỰC về ngôn ngữ, cắt ngang các tầng trên | | ⚠ Generative AI | ⚠ AI TẠO RA nội dung mới | | AGI | ⚠ giả thuyết — chưa tồn tại |

Từ khoá nhận diện:

"máy hiểu ngôn ngữ người" → ⚠ NLP "tạo ra nội dung mới" → ⚠ Generative AI "học từ thưởng/phạt" → học tăng cường "AI thông minh mọi mặt như người" → ⚠ AGI — chưa có

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Nhãn có phải tuỳ biến không | ⚠ có → LLM; chuẩn → NL API | | Khối lượng bao nhiêu | ⚠ lớn → API chuyên biệt rẻ hơn nhiều | | Có cần giải thích vì sao không | ⚠ LLM nêu được lý do |

Và với bài toán phân tích đánh giá khách hàng, lựa chọn thực dụng thường là kết hợp: dùng API chuyên biệt cho phần chấm cảm xúc ở quy mô lớn với chi phí thấp, và dùng mô hình ngôn ngữ cho phần trích chủ đề vốn cần hiểu ngữ cảnh và danh mục riêng của doanh nghiệp.

Đáp án

A — Model Management (quản lý mô hình).

Vì sao đúng

Các hoạt động sau khi mô hình đã chạy — giám sát liên tục, huấn luyện lại định kỳ, cập nhật tham số — thuộc về giai đoạn quản lý mô hình, không phải triển khai.

⚠ Ranh giới giữa Deployment và Management:

⚠ MODEL DEPLOYMENT
    → ⚠ HÀNH ĐỘNG đưa mô hình
      ra phục vụ
    → tạo endpoint, cấu hình,
      mở API
    → ⚠ diễn ra MỘT LẦN cho
      mỗi phiên bản

⚠ MODEL MANAGEMENT
    → ⚠ mọi việc DIỄN RA LIÊN TỤC
      sau đó
    → giám sát, phát hiện drift
    → ⚠ huấn luyện lại, đánh phiên bản
    → quay lui khi cần
    → ⚠ ĐỀ NÀY

⚠ Vòng lặp quản lý mô hình:

Giám sát hiệu năng
        ↓
    ⚠ Phát hiện suy giảm / drift
        ↓
    ⚠ Huấn luyện lại trên dữ liệu mới
        ↓
    Đánh giá bản mới so bản cũ
        ↓
    ⚠ Triển khai dần (canary)
        ↓
    quay lại giám sát

⚠ Đối chiếu #13903 (lô 145) — đề đó khoá Model Deployment cho việc đưa mô hình ra phục vụ qua API. Đề này khoá Model Management cho các hoạt động duy trì sau đó. Không mâu thuẫn — hai giai đoạn liền kề, phân biệt bằng một lần hay liên tục. Nhất quán với #13882 (lô 145) về drift.

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

• B (Model Deployment) — phương án gần nhất và là bẫy chính: nó là giai đoạn ngay trước. Nhưng triển khai là đưa lên, còn đề mô tả việc duy trì lâu dài.

• D (Model Training) — huấn luyện lại là một phần của quản lý, nhưng đề liệt kê cả giám sát và cập nhật.

• C (Data Ingestion) — ở đầu vòng đời.

Ghi nhớ

⚠ Vòng đời ML đầy đủ — bảng phải thuộc: | Giai đoạn | Đặc điểm | |---|---| | Data Ingestion | đưa dữ liệu vào | | Data Preparation | ⚠ làm sạch, tạo đặc trưng | | Model Training | huấn luyện | | Model Evaluation | đo chỉ số | | Model Deployment | ⚠ đưa ra phục vụ — MỘT LẦN | | ⚠ Model Management | ⚠ giám sát, huấn luyện lại, cập nhật — LIÊN TỤC |

Từ khoá nhận diện:

"giám sát, huấn luyện lại, cập nhật liên tục" → ⚠ Model Management "đưa mô hình ra dùng qua API" → Model Deployment "chất lượng giảm dần" → ⚠ drift "tự động hoá cả quy trình" → ⚠ Vertex AI Pipelines

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ai biết khi mô hình xuống cấp | ⚠ không ai → chưa có management | | Huấn luyện lại có tự động không | ⚠ thủ công thì sẽ bị bỏ quên | | Quay lui mất bao lâu | ⚠ thử thật một lần |

Và khác biệt căn bản khiến việc vận hành mô hình khó hơn vận hành phần mềm thông thường: mã không đổi mà chất lượng vẫn giảm. Không có sự cố nào để cảnh báo, không có lỗi nào trong log — chỉ có một đường cong đi xuống mà nếu không ai chủ động theo dõi thì sẽ không ai nhìn thấy.

Đáp án

D — Unlabeled Data (dữ liệu chưa gán nhãn).

Vì sao đúng

Hàng triệu ảnh mèo không có thẻ hay chú thích nào. Mô hình học mẫu hình và đặc trưng trực tiếp từ dữ liệu thô. Đó là dữ liệu chưa gán nhãn.

⚠ Vì sao là unlabeled:

"KHÔNG có thẻ hay chú thích"
    → ⚠ không có "Siamese", "tabby",
      "đang ngồi"
        ↓
    ⚠ Mô hình không được dạy
      "đây là gì"
        ↓
    ⚠ Nó tự học CẤU TRÚC của
      ảnh mèo nói chung
        ↓
    → sinh ra ảnh mèo mới

⚠ Đây chính là cách mô hình sinh được huấn luyện:

⚠ Mô hình sinh học từ khối lượng
  RẤT LỚN dữ liệu KHÔNG NHÃN
        ↓
    ⚠ LLM học từ văn bản trên
      internet — không ai gán nhãn
    ⚠ Mô hình ảnh học từ ảnh
        ↓
    ⚠ Gọi là học TỰ GIÁM SÁT
      (self-supervised)
        ↓
    ⚠ Đó là lý do có thể huấn luyện
      ở quy mô khổng lồ

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

"Labeled Data"      → ⚠ ngược lại
"Structured Data"   → ⚠ ảnh không phải bảng
"Time-series Data"  → ⚠ không phải chuỗi thời gian

Nhất quán với #13887 (lô 145) về học không giám sát trên dữ liệu không nhãn. Đối chiếu #13889 (lô 145) khoá labeled data vì ở đó bài báo đã được người gán chủ đề. Không mâu thuẫn.

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

• B (labeled data) — phương án gần nhất và là bẫy trực tiếp: đề nói rõ không có thẻ hay chú thích.

• A (structured) và C (time-series) — không mô tả đúng dữ liệu ảnh.

Ghi nhớ

⚠ Có nhãn hay không — quyết định cách học: | Dữ liệu | Cách học | Bài toán | |---|---|---| | ⚠ CÓ nhãn | ⚠ có giám sát | phân loại, hồi quy | | ⚠ KHÔNG nhãn | ⚠ không giám sát / tự giám sát | ⚠ phân cụm, MÔ HÌNH SINH | | Thưởng/phạt | tăng cường | game, robot |

Từ khoá nhận diện:

"không có thẻ, không chú thích" → ⚠ unlabeled "người đã gán sẵn" → labeled "tự học mẫu hình từ dữ liệu thô" → ⚠ tự giám sát / không giám sát "bảng, hàng, cột" → structured

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Dữ liệu có nhãn không | không → ⚠ không giám sát / tự giám sát | | Có quyền dùng dữ liệu này không | ⚠ bản quyền là vấn đề thật | | Dữ liệu có đại diện không | ⚠ lệch thì mô hình lệch |

Và điều làm nên bước nhảy của các mô hình sinh hiện đại không phải một thuật toán mới, mà là việc bỏ được yêu cầu về dữ liệu gán nhãn. Khi mô hình có thể học từ dữ liệu thô, quy mô huấn luyện không còn bị giới hạn bởi số giờ công của người gán nhãn nữa.

Đáp án

D — Grounding (thường hiện thực bằng RAG).

Vì sao đúng

Cơ chế đề mô tả — tìm trong tài liệu chính thức TRƯỚC, rồi đưa thông tin tìm được vào làm ngữ cảnh cho mô hình — chính là grounding, và cách hiện thực phổ biến nhất là RAG.

⚠ Ba bước trong đề:

1. Người dùng hỏi
        ↓
2. ⚠ Hệ thống TÌM trong sổ tay
   sản phẩm và FAQ
        ↓
3. ⚠ Đưa đoạn tìm được vào
   làm NGỮ CẢNH
        ↓
4. Mô hình trả lời DỰA TRÊN đó
        ↓
    ⚠ Giảm mạnh khả năng "bịa"

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

"Fine-tuning"
    → ⚠ huấn luyện thêm mô hình;
      ⚠ KHÔNG tra cứu lúc trả lời
    → ⚠ và không trích dẫn được nguồn

"Prompt engineering"
    → ⚠ viết câu lệnh tốt hơn;
      ⚠ không bổ sung kiến thức mới

"Bias mitigation"
    → ⚠ giảm thiên vị — vấn đề khác

⚠ Gần trùng với #13900 và #13859 (lô 145) — cả ba đề đều về grounding/RAG, cùng khoá, chỉ khác cách diễn đạt và bộ phương án. Hoàn toàn nhất quán.

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

• A (fine-tuning) — phương án gần nhất và là bẫy chính: cũng là cách làm mô hình "biết" thông tin công ty. Nhưng fine-tuning nhúng kiến thức vào trọng số, không tra cứu lúc trả lời như đề mô tả.

• C (prompt engineering) và B (bias mitigation) — không phải cơ chế nối với nguồn tri thức.

Ghi nhớ

⚠ Grounding và fine-tuning — bảng phải thuộc: | | ⚠ Grounding / RAG | ⚠ Fine-tuning | |---|---|---| | Cơ chế | ⚠ TRA CỨU lúc trả lời | ⚠ nhúng vào trọng số | | Cập nhật | ⚠ sửa tài liệu là xong | ⚠ huấn luyện lại | | ⚠ Trích dẫn nguồn | ⚠ CÓ | ⚠ KHÔNG | | Giải quyết | ⚠ thiếu KIẾN THỨC | ⚠ thiếu PHONG CÁCH | | Chi phí | thấp hơn nhiều | cao |

Từ khoá nhận diện:

"tra tài liệu trước khi trả lời" → ⚠ grounding / RAG "huấn luyện thêm trên dữ liệu riêng" → fine-tuning "viết câu lệnh cho rõ" → prompt engineering "giảm chênh lệch giữa các nhóm" → bias mitigation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trích dẫn nguồn không | ⚠ bắt buộc | | Hỏi ngoài tài liệu thì sao | ⚠ phải từ chối, không được bịa | | Tài liệu có cập nhật không | ⚠ ai chịu trách nhiệm việc này |

Và cách phân biệt nhanh grounding với fine-tuning trong mọi đề bài: grounding TRA CỨU tại thời điểm trả lời, fine-tuning đã NHỚ từ trước. Chỉ cái đầu tiên nêu được nguồn, và cũng chỉ nó cập nhật được chỉ bằng cách sửa một tài liệu.

Đáp án

A — Vertex AI Model Garden.

Vì sao đúng

Lập trình viên muốn khám phá và truy cập các mô hình huấn luyện sẵn của Google hoặc nhà cung cấp mã nguồn mở uy tín, thay vì tự huấn luyện. Model Garden là đúng nơi đó.

⚠ Model Garden là gì:

⚠ DANH MỤC mô hình trong Vertex AI
        ↓
    ⚠ Mô hình Google: Gemini,
      Imagen, Veo, Gemma
    ⚠ Mô hình mở của bên thứ ba
    ⚠ Mô hình chuyên ngành
        ↓
    ⚠ Xem mô tả và khả năng
    ⚠ Thử ngay
    ⚠ Triển khai hoặc tinh chỉnh

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

"BigQuery ML"
    → ⚠ dựng mô hình BẰNG SQL trên
      dữ liệu của bạn

"AutoML Tables"
    → ⚠ huấn luyện mô hình RIÊNG
      từ dữ liệu BẢNG

"Feature Store"
    → ⚠ quản lý ĐẶC TRƯNG

⚠ Cả ba đều là thành phần thật của nền tảng, nhưng không phải nơi duyệt mô hình có sẵn.

⚠ Gần trùng với #13892 (lô 145) — đề đó cũng hỏi nơi tập trung để khám phá và triển khai mô hình, và cùng khoá Model Garden. Hoàn toàn nhất quán.

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

• C (AutoML Tables) — phương án gần nhất vì cũng cho ra mô hình mà ít công sức, nhưng nó huấn luyện mô hình mới trên dữ liệu bảng của bạn, còn đề muốn dùng mô hình đã có sẵn.

• B và D — phục vụ khâu khác.

Ghi nhớ

⚠ Thành phần Vertex AI — bảng phải thuộc: | Thành phần | Việc | |---|---| | ⚠ Model Garden | ⚠ duyệt, thử, triển khai mô hình CÓ SẴN | | AutoML | ⚠ huấn luyện mô hình RIÊNG, không viết mã | | Custom training | tự viết mã | | Model Registry | ⚠ quản phiên bản mô hình của bạn | | Feature Store | ⚠ đặc trưng dùng chung | | Pipelines | tự động hoá | | Prediction | phục vụ |

Từ khoá nhận diện:

"khám phá và truy cập mô hình có sẵn" → ⚠ Model Garden "huấn luyện mô hình riêng, không viết mã" → AutoML "dựng mô hình bằng SQL" → BigQuery ML "thử prompt siêu nhanh, không dựng gì" → ⚠ Google AI Studio

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đã thử prompt trước khi tính huấn luyện chưa | ⚠ thường là đủ | | Tài liệu dài bao nhiêu | ⚠ quyết định cửa sổ ngữ cảnh cần | | Đã so vài mô hình trên cùng ví dụ chưa | ⚠ cách duy nhất để chọn đúng |

Và trình tự nên theo với mọi bài toán AI sinh: thử mô hình có sẵn với một prompt tốt trước đã. Phần lớn nhu cầu dừng lại ở đó — và biết được điều này sớm giúp tránh một dự án huấn luyện vốn không cần thiết ngay từ đầu.

Đáp án

A — Xác định những bài toán nghiệp vụ cụ thể mà AI sinh mang lại giá trị rõ ràng, và bắt đầu bằng các dự án thí điểm.

Vì sao đúng

Bước đầu tiên phải là bài toán, không phải công nghệ. Bắt đầu bằng ca sử dụng có giá trị rõ ràng rồi thí điểm nhỏ là cách tiếp cận có cấu trúc mà lãnh đạo đang tìm.

⚠ Vì sao thứ tự này đúng:

Bắt đầu từ CÔNG NGHỆ
    → ⚠ mua phần cứng, tuyển người,
      triển khai rộng
    → ⚠ rồi mới đi tìm việc cho nó làm
    → ⚠ tốn kém và thường thất bại

⚠ Bắt đầu từ BÀI TOÁN
    → ⚠ vấn đề nào đang tốn tiền
      hoặc tốn thời gian?
    → ⚠ AI sinh có giúp được không?
    → ⚠ THÍ ĐIỂM nhỏ, ĐO kết quả
    → ⚠ thành công thì mở rộng

⚠ Vì sao thí điểm quan trọng:

⚠ Rủi ro thấp, chi phí thấp
⚠ Học được cách vận hành thật
⚠ Có SỐ LIỆU để thuyết phục
⚠ Phát hiện vấn đề dữ liệu sớm
⚠ Xây dựng năng lực nội bộ dần

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

"Mua phần cứng AI tiên tiến nhất"
    → ⚠ đám mây có sẵn, không cần mua
    → ⚠ và mua trước khi biết dùng
      làm gì là lãng phí

"Tuyển đội nghiên cứu AI lớn"
    → ⚠ đắt, và hầu hết doanh nghiệp
      cần người ỨNG DỤNG chứ không
      phải người NGHIÊN CỨU

"Triển khai NGAY LLM cho TOÀN
 công ty"
    → ⚠ rủi ro cao, chưa có quy trình,
      chưa rà quyền dữ liệu

Nhất quán với #13897 (lô 145) — cùng thông điệp: bắt đầu từ mục tiêu nghiệp vụ đo được. Và #13894 (lô 145) về việc chọn chỉ số đo thành công.

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

• D (triển khai ngay cho toàn công ty) — phương án gần nhất vì cũng thể hiện quyết tâm áp dụng, nhưng bỏ qua giai đoạn thí điểm là cách nhanh nhất để gặp sự cố về dữ liệu, chi phí và quyền truy cập ở quy mô lớn.

• B và C — đầu tư vào nguồn lực trước khi biết dùng vào việc gì.

Ghi nhớ

⚠ Lộ trình áp dụng AI sinh — bảng nên thuộc: | Bước | Nội dung | |---|---| | ⚠ 1. Xác định ca sử dụng | ⚠ bài toán cụ thể, giá trị rõ — đề này | | 2. Đánh giá dữ liệu và rủi ro | ⚠ có dữ liệu không, có được dùng không | | ⚠ 3. Thí điểm nhỏ, ĐO | ⚠ có đường cơ sở để so | | 4. Xây quy trình và quản trị | ⚠ SAIF, HITL, chính sách | | 5. Mở rộng dần | | | 6. Xây năng lực nội bộ | ⚠ đào tạo, nhân rộng cách làm |

Từ khoá nhận diện:

"bắt đầu từ đâu, cách tiếp cận có cấu trúc" → ⚠ ca sử dụng + thí điểm "đo thành công bằng gì" → chỉ số nghiệp vụ trực tiếp "quản trị rủi ro AI" → SAIF "ai chịu trách nhiệm khi sai" → ⚠ accountability, HITL

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Bài toán cụ thể là gì | ⚠ không nêu được thì chưa nên bắt đầu | | Thành công đo bằng con số nào | ⚠ và đường cơ sở hiện tại | | Ai trong nghiệp vụ sẽ dùng | ⚠ không có người dùng thật thì dừng |

Và dấu hiệu rõ nhất cho thấy một sáng kiến AI đang đi đúng hướng: có một người trong bộ phận nghiệp vụ thật sự muốn nó tồn tại. Những dự án khởi động từ mong muốn "phải làm gì đó với AI" thường kết thúc bằng một bản trình bày đẹp mà không ai dùng.