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

Đáp án

C — Generative AI (AI sinh).

Vì sao đúng

Điểm mấu chốt nằm trong chính đề: đầu ra không phải một dự đoán từ đầu vào mà là một sáng tạo MỚI — bài báo mới, bản nhạc gốc, tác phẩm số mới.

⚠ Phân biệt AI sinh với AI dự đoán:

⚠ AI DỰ ĐOÁN (predictive)
    → ⚠ đầu ra là NHÃN hoặc SỐ
    → "email này là spam"
    → "doanh thu tháng tới là X"
    → ⚠ chọn từ tập kết quả có sẵn

⚠ AI SINH (generative)
    → ⚠ đầu ra là NỘI DUNG MỚI
    → bài báo, nhạc, ảnh, mã
    → ⚠ chưa từng tồn tại
    → ⚠ ĐỀ NÀY

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

"Predictive Analytics"
    → ⚠ dự báo con số, xu hướng —
      không TẠO RA nội dung

"NLU"
    → ⚠ HIỂU ngôn ngữ, không sinh

"Expert Systems"
    → ⚠ hệ chuyên gia dựa trên LUẬT
      do người viết — công nghệ AI
      thế hệ cũ, không học từ dữ liệu

⚠ Đối chiếu #13910 (cùng lô) — đề đó khoá NLP cho việc HIỂU và rút nghĩa từ ngôn ngữ. Đề này khoá Generative AI cho việc TẠO RA nội dung mới. KHÔNG mâu thuẫn — hiểu và tạo là hai năng lực khác nhau, và đó chính là dấu hiệu phân biệt hai đề.

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

• D (Predictive Analytics) — phương án gần nhất và là bẫy chính: đề nêu thẳng sự đối lập "không phải dự đoán mà là sáng tạo mới".

• B (NLU) — chỉ về hiểu ngôn ngữ, và không bao gồm nhạc hay nghệ thuật số.

• A (Expert Systems) — hệ dựa trên luật, không sinh nội dung mới.

Ghi nhớ

⚠ AI sinh và AI dự đoán — bảng phải thuộc: | | ⚠ AI dự đoán | ⚠ AI sinh | |---|---|---| | Đầu ra | ⚠ nhãn, số, xác suất | ⚠ nội dung MỚI | | Ví dụ | ⚠ spam hay không, giá nhà | ⚠ bài viết, ảnh, nhạc, mã | | Huấn luyện | ⚠ thường CÓ giám sát | ⚠ tự giám sát trên dữ liệu lớn | | Đánh giá | ⚠ so với nhãn đúng | ⚠ KHÓ — không có đáp án duy nhất | | Rủi ro | sai dự đoán | ⚠ ảo giác, bản quyền, nội dung có hại |

Từ khoá nhận diện:

"tạo ra nội dung mới, chưa từng có" → ⚠ Generative AI "dự báo con số, xu hướng" → predictive analytics "hiểu và rút nghĩa từ ngôn ngữ" → ⚠ NLP / NLU "luật if-then do người viết" → ⚠ expert system

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Đầu ra là nhãn/số hay nội dung mới | ⚠ phân biệt hai loại AI | | Đánh giá chất lượng bằng gì | ⚠ cần tiêu chí rõ từ đầu | | Ai duyệt trước khi công bố | ⚠ luôn cần với nội dung ra ngoài |

Và ranh giới cần giữ rõ khi nói về hai loại AI này: AI dự đoán trả lời câu hỏi có đáp án đúng, AI sinh tạo ra thứ chưa từng có. Sự khác biệt đó kéo theo mọi thứ khác — từ cách huấn luyện, cách đánh giá, cho tới loại rủi ro phải phòng.

Đáp án

D — Code generation (sinh mã) — tự động hoá phần việc lặp lại.

Vì sao đúng

Đội cần công cụ sinh ra đoạn mã khuôn mẫu lặp lại dựa trên mô tả ở mức cao hoặc mẫu có sẵn. Đầu ra là mã nguồn — đó là sinh mã.

⚠ Xác định bằng đầu ra:

"viết boilerplate code cho các
 tính năng phổ biến"
        ↓
    ⚠ đầu ra là MÃ NGUỒN
        ↓
    → ⚠ code generation

⚠ Vì sao boilerplate là ứng viên lý tưởng:

⚠ LẶP LẠI và có KHUÔN MẪU rõ
⚠ Ít sáng tạo, nhiều gõ phím
⚠ ⚠ DỄ KIỂM CHỨNG
    → chạy được hay không
    → test có qua không
        ↓
    ⚠ Đó là lý do sinh mã là một
      trong những ứng dụng AI sinh
      THÀNH CÔNG nhất

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

"Data analysis"   → ⚠ phân tích dữ liệu
"Image generation" → ⚠ sinh ảnh
"Personalized user experience"
    → ⚠ cá nhân hoá cho người dùng
      cuối

Nhất quán với #13870 (lô 145) — đề đó về Gemini Code Assist trong IDE. Đề này hỏi tên năng lực. Bổ sung nhau.

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

• C (data analysis) — phương án gần nhất về mặt "cũng là công việc kỹ thuật mà AI hỗ trợ được", nhưng đầu ra ở đây là mã nguồn, không phải kết luận từ dữ liệu.

• B và A — sai modality và sai đối tượng.

Ghi nhớ

⚠ Trợ lý lập trình làm được gì — bảng nên thuộc: | Việc | Mức hữu ích | |---|---| | ⚠ Sinh boilerplate | ⚠ rất cao — đề này | | ⚠ Sinh unit test | ⚠ rất cao, hay bị đánh giá thấp | | ⚠ Giải thích mã lạ | ⚠ rất giá trị với mã kế thừa | | Chuyển đổi ngôn ngữ, refactor | cao | | Viết tài liệu, docstring | cao | | Gợi ý hoàn thiện khi gõ | ⚠ tiết kiệm liên tục | | Thiết kế kiến trúc | ⚠ thấp — cần người |

Từ khoá nhận diện:

"sinh mã lặp lại, boilerplate" → ⚠ code generation "giải thích đoạn mã" → ⚠ cũng là trợ lý lập trình "trong IDE" → ⚠ Gemini Code Assist "phân tích dữ liệu" → data analysis

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Test có qua không | ⚠ điều kiện tối thiểu | | Thư viện gợi ý có tồn tại không | ⚠ kiểm tên gói | | Chất lượng có giảm không | ⚠ đo song song với tốc độ |

Và mối rủi ro cụ thể đáng nhớ nhất khi dùng AI sinh mã: thư viện được gợi ý có thể không tồn tại. Điều tệ hơn là đã có người đăng những gói mang đúng tên mà AI hay bịa ra — nên kiểm tra tên gói trước khi cài không phải là sự cẩn thận thừa.

Đáp án

D — Role prompting (gán vai).

Vì sao đúng

Câu lệnh mở đầu bằng "Bạn là một lập trình viên Python chuyên về thư viện Pandas" — đó là việc gán một vai trò hoặc chuyên môn cho mô hình, tức role prompting.

⚠ Vì sao gán vai có tác dụng:

Không gán vai
    → ⚠ mô hình trả lời chung chung
    → có thể dùng thư viện bất kỳ

⚠ GÁN VAI
    → "bạn là chuyên gia Pandas"
        ↓
    ⚠ Định hướng phong cách và
      thuật ngữ
    ⚠ Ưu tiên cách làm đúng chuẩn
      của lĩnh vực đó
    ⚠ Mức chi tiết phù hợp

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

"Few-shot"
    → ⚠ đưa VÍ DỤ MẪU — prompt này
      KHÔNG có ví dụ nào

"Chain-of-Thought"
    → ⚠ yêu cầu trình bày CÁC BƯỚC
      suy luận — không có ở đây

"Zero-shot"
    → ⚠ đúng là không có ví dụ,
      nhưng ⚠ đặc điểm NỔI BẬT của
      prompt này là GÁN VAI

⚠ Đối chiếu #13867 (lô 145, few-shot) và #13905 (cùng lô, CoT) — ba đề cùng họ kỹ thuật prompt, mỗi đề một kỹ thuật, phân biệt bằng dấu hiệu trong chính prompt. Hoàn toàn nhất quán.

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

• C (zero-shot) — phương án gần nhất và là bẫy tinh tế: prompt này cũng không có ví dụ, nên về mặt kỹ thuật nó là zero-shot. Nhưng câu hỏi hỏi về cách tiếp cận gán vai, và tên của kỹ thuật đó là role prompting.

• A và B — không có dấu hiệu tương ứng trong prompt.

Ghi nhớ

⚠ Nhận diện kỹ thuật prompt qua dấu hiệu — bảng phải thuộc: | Dấu hiệu trong prompt | Kỹ thuật | |---|---| | ⚠ "Bạn là một..." | ⚠ role prompting | | ⚠ Có ví dụ: đề → đáp án | ⚠ few-shot | | ⚠ Ví dụ CÓ bước suy luận | ⚠ chain-of-thought | | ⚠ "Hãy suy luận từng bước" | ⚠ zero-shot CoT | | Không ví dụ, không vai | zero-shot | | ⚠ Nhiều lời gọi nối tiếp | ⚠ prompt chaining | | Suy luận xen kẽ gọi công cụ | ⚠ ReAct |

Từ khoá nhận diện:

"gán vai, gán chuyên môn" → ⚠ role prompting "đưa vài ví dụ" → few-shot "trình bày từng bước" → chain-of-thought "hỏi thẳng không gì thêm" → zero-shot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gán vai có cải thiện thật không | ⚠ so có và không trên cùng bộ test | | Vai có đủ cụ thể chưa | ⚠ "chuyên gia X" thường tốt hơn "chuyên gia" | | Nội dung có đúng không | ⚠ giọng chuyên gia không bảo đảm đúng |

Và giới hạn quan trọng nhất cần nhớ về kỹ thuật này: gán vai làm đổi cách mô hình nói, không làm đổi những gì nó biết. Một câu trả lời sai được trình bày bằng giọng chuyên gia vẫn là câu trả lời sai — và thậm chí còn khó nghi ngờ hơn.

Đáp án

B — Pseudonymization (giả danh hoá).

Vì sao đúng

Kỹ thuật thay định danh trực tiếp (tên, số bảo hiểm xã hội) bằng định danh nhân tạo chính là pseudonymization.

⚠ Pseudonymization hoạt động ra sao:

Nguyễn Văn A, SSN 123-45-6789
        ↓
    ⚠ thay bằng: BN-000472
        ↓
    ⚠ Dữ liệu vẫn PHÂN TÍCH ĐƯỢC
    ⚠ Vẫn nối được các bản ghi
      của cùng một người
        ↓
    ⚠ NHƯNG: có bảng ánh xạ thì
      vẫn truy ngược được
        ↓
    → ⚠ đó là điểm khác với
      ẩn danh hoá HOÀN TOÀN

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

"Mã hoá khi truyền"
    → ⚠ bảo vệ dữ liệu TRÊN ĐƯỜNG
      đi; giải mã ra vẫn là dữ liệu gốc

"Data minimization"
    → ⚠ nguyên tắc CHỈ THU THẬP
      những gì cần — đúng và quan
      trọng, nhưng không phải kỹ thuật
      thay định danh

"Data replication"
    → ⚠ nhân bản dữ liệu, không
      liên quan tới riêng tư

Nhất quán với #13872 (lô 145) — đề đó về khử định danh xuyên suốt vòng đời ML cho dữ liệu bệnh nhân. Đề này hỏi tên kỹ thuật cụ thể. Bổ sung nhau.

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

• C (data minimization) — phương án gần nhất vì cũng là biện pháp bảo vệ quyền riêng tư được các quy định nhắc tới, nhưng nó nói về thu thập ít nhất có thể, không phải thay định danh.

• A và D — thuộc lĩnh vực bảo mật truyền tải và hạ tầng.

Ghi nhớ

⚠ Các kỹ thuật bảo vệ dữ liệu — bảng phải thuộc: | Kỹ thuật | Nội dung | Truy ngược | |---|---|---| | ⚠ Pseudonymization | ⚠ thay bằng định danh nhân tạo | ⚠ CÓ, nếu có bảng ánh xạ | | ⚠ Anonymization | ⚠ loại bỏ hẳn khả năng nhận dạng | ⚠ KHÔNG | | Masking | ⚠ che một phần: ***-**-6789 | tuỳ | | Tokenization | ⚠ thay bằng token, có kho khoá | có | | Generalization | ⚠ tuổi 37 → nhóm 30–40 | không | | ⚠ Encryption | ⚠ mã hoá — giải ra là dữ liệu gốc | ⚠ có, với khoá |

Từ khoá nhận diện:

"thay tên bằng mã nhân tạo" → ⚠ pseudonymization "không thể nhận dạng lại được" → ⚠ anonymization "chỉ thu thập những gì cần" → ⚠ data minimization "che một phần ký tự" → masking

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ai giữ bảng ánh xạ | ⚠ danh sách phải rất ngắn | | Ghép các trường còn lại có nhận ra người không | ⚠ thử thật | | Log có chứa PHI không | ⚠ chỗ hay bị bỏ quên nhất |

Và điều dễ đánh giá thấp nhất về việc khử định danh: xoá tên không đồng nghĩa với không nhận dạng được. Sự kết hợp của vài trường tưởng chừng vô hại thường đủ để chỉ ra một người duy nhất trong tập dữ liệu — nên phép thử tái nhận dạng đáng làm trước khi tuyên bố dữ liệu đã an toàn.

Đáp án

B — Fine-tuning mô hình trên một tập dữ liệu gồm các văn bản pháp lý.

Vì sao đúng

Mục tiêu là chuyên biệt hoá phong cách và thuật ngữ cho lĩnh vực pháp lý — dùng đúng từ ngữ chuyên ngành và văn phong. Đó chính là bài toán mà fine-tuning giải.

⚠ Khi nào fine-tuning là câu trả lời đúng:

⚠ Cần đổi PHONG CÁCH, GIỌNG VĂN
⚠ Cần dùng THUẬT NGỮ chuyên ngành
  một cách tự nhiên
⚠ Cần ĐỊNH DẠNG đầu ra rất riêng
⚠ Prompt dài mà vẫn không ổn định
        ↓
    → ⚠ FINE-TUNING

⚠ Khi nào KHÔNG nên fine-tune:

⚠ Cần KIẾN THỨC cụ thể, cập nhật
    → ⚠ dùng GROUNDING / RAG

⚠ Chỉ cần thử nghiệm nhanh
    → ⚠ prompt engineering

⚠ Không có đủ dữ liệu chất lượng
    → ⚠ fine-tune sẽ làm mô hình
      TỆ HƠN

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

"HITL cho MỌI đầu ra"
    → ⚠ biện pháp KIỂM SOÁT, không
      chuyên biệt hoá mô hình

"TĂNG temperature"
    → ⚠ làm đầu ra SÁNG TẠO hơn —
      ⚠ ngược hẳn với nhu cầu chính xác
      của văn bản pháp lý

"Grounding bằng tìm kiếm web CÔNG KHAI"
    → ⚠ cung cấp THÔNG TIN, không
      dạy PHONG CÁCH

⚠ Đối chiếu #13913 và #13900 (grounding/RAG) — những đề đó giải quyết thiếu KIẾN THỨC, đề này giải quyết thiếu PHONG CÁCH. Không mâu thuẫn — đó chính là ranh giới phân biệt hai kỹ thuật.

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

• D (grounding bằng web công khai) — phương án gần nhất vì cũng là cách làm mô hình phù hợp hơn với lĩnh vực. Nhưng grounding cung cấp nội dung, không dạy mô hình cách viết.

• A và C — không chuyên biệt hoá mô hình.

Ghi nhớ

⚠ Fine-tuning và grounding — bảng phải thuộc: | | ⚠ Fine-tuning | ⚠ Grounding / RAG | |---|---|---| | Giải quyết | ⚠ PHONG CÁCH, định dạng, thuật ngữ | ⚠ KIẾN THỨC | | Cập nhật | ⚠ huấn luyện lại | ⚠ sửa tài liệu | | Trích dẫn | ⚠ không | ⚠ CÓ | | Chi phí | ⚠ cao | thấp hơn | | Dữ liệu cần | ⚠ nhiều ví dụ chất lượng | ⚠ kho tài liệu | | ⚠ Thường dùng | ⚠ KẾT HỢP CẢ HAI | |

Từ khoá nhận diện:

"văn phong, thuật ngữ chuyên ngành" → ⚠ fine-tuning "thông tin cụ thể, cập nhật" → grounding / RAG "viết lại câu lệnh" → prompt engineering "người duyệt trước khi dùng" → HITL

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Vấn đề là phong cách hay kiến thức | ⚠ quyết định chọn kỹ thuật nào | | Có đủ dữ liệu ví dụ chất lượng không | ⚠ thiếu thì đừng fine-tune | | Đã thử prompt kỹ chưa | ⚠ thường giải quyết được nhiều hơn dự kiến |

Và cách phân biệt gọn nhất giữa hai kỹ thuật hay bị nhầm này: fine-tuning dạy mô hình NÓI NHƯ THẾ NÀO, grounding cho mô hình biết NÓI GÌ. Một hệ thống pháp lý nghiêm túc thường cần cả hai — và luôn cần một luật sư đọc lại trước khi kết quả được dùng.

Đáp án

B — Kích thước cửa sổ ngữ cảnh (context window) của mô hình.

Vì sao đúng

Muốn tóm tắt mạch lạc một bài báo 50–100 trang, mô hình phải nhận được TOÀN BỘ tài liệu cùng lúc. Đó là điều mà cửa sổ ngữ cảnh quyết định.

⚠ Vì sao cửa sổ ngữ cảnh là ràng buộc cứng:

Tài liệu 100 trang
        ↓
    ⚠ khoảng vài chục nghìn token
        ↓
    ⚠ Cửa sổ ngữ cảnh NHỎ HƠN?
        ↓
    ⚠ Không nhét vào được
        ↓
    ⚠ Phải CHIA ĐOẠN rồi tóm tắt
      nhiều tầng
        ↓
    ⚠ Rủi ro: mất mạch, mất liên hệ
      giữa các phần

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

"Tốc độ sinh từng token"
    → ⚠ ảnh hưởng ĐỘ TRỄ, không
      quyết định có xử lý nổi
      tài liệu hay không

"Khả năng đa phương thức"
    → ⚠ đây là văn bản, không cần
      ảnh hay âm thanh

"Ngôn ngữ huấn luyện chính"
    → ⚠ mô hình hiện đại đa ngữ;
      không phải ràng buộc quyết định

Đối chiếu #13856 (lô 145) — đề đó khoá modality là tiêu chí đầu tiên khi chọn mô hình. Ở đây modality đã rõ (văn bản), nên tiêu chí quyết định là cửa sổ ngữ cảnh. Không mâu thuẫn — cùng khung tiêu chí, khác bài toán.

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

• A (tốc độ sinh token) — phương án gần nhất vì hiệu năng là mối quan tâm thật, nhưng chậm vẫn xong được; còn không đủ cửa sổ ngữ cảnh thì không làm được theo cách đề mô tả.

• C và D — không phải ràng buộc ở đây.

Ghi nhớ

⚠ Tiêu chí chọn mô hình — theo thứ tự: | Bước | Tiêu chí | |---|---| | 1 | ⚠ MODALITY — làm được loại việc này không | | ⚠ 2 | ⚠ CỬA SỔ NGỮ CẢNH — nhận được đầu vào không | | 3 | ⚠ chất lượng trên ví dụ thật | | 4 | ⚠ chi phí và độ trễ | | 5 | ⚠ tuỳ biến: tinh chỉnh, grounding |

Từ khoá nhận diện:

"tài liệu rất dài, xử lý toàn bộ" → ⚠ context window "loại dữ liệu vào và ra" → modality "cần trả lời nhanh" → ⚠ độ trễ "kiến thức riêng của công ty" → grounding

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài liệu dài bao nhiêu token | ⚠ ước lượng trước khi chọn mô hình | | Số liệu trong bản tóm tắt có đúng không | ⚠ đối chiếu với bài gốc | | Phần giữa tài liệu có bị bỏ sót không | ⚠ thử hỏi về nội dung ở giữa |

Và hiện tượng đáng biết khi làm việc với tài liệu rất dài: mô hình chú ý tới phần đầu và phần cuối tốt hơn phần giữa. Vì vậy nhồi trọn một trăm trang vào cửa sổ ngữ cảnh không phải lúc nào cũng cho kết quả tốt hơn việc chọn lọc đúng những đoạn cần thiết.

Đáp án

D — Việc chọn mô hình nền và kích thước / độ phức tạp của nó.

Vì sao đúng

Ràng buộc là GPU hạn chế cho sinh nội dung theo thời gian thực. Ràng buộc hạ tầng như vậy ảnh hưởng trực tiếp tới việc chọn mô hình nào và cỡ nào.

⚠ Chuỗi ảnh hưởng:

GPU hạn chế
        ↓
    ⚠ Mô hình lớn chạy CHẬM
      hoặc KHÔNG chạy nổi
        ↓
    ⚠ Trải nghiệm thời gian thực
      bị ảnh hưởng
        ↓
    → ⚠ phải chọn mô hình NHỎ HƠN
    → hoặc mô hình đã tối ưu
    → hoặc gọi API thay vì tự chạy

⚠ Các lựa chọn khi bị giới hạn tài nguyên:

⚠ Mô hình NHỎ hơn
    → Gemma bản nhỏ, Gemini Flash

⚠ Gọi API thay vì tự host
    → ⚠ không cần GPU của mình

⚠ Lượng tử hoá mô hình
    → giảm bộ nhớ và tăng tốc

⚠ Tinh chỉnh mô hình nhỏ
    → ⚠ cho tác vụ hẹp, thường
      ĐỦ TỐT

⚠ Sinh trước và lưu đệm
    → ⚠ không phải mọi thứ đều
      cần thời gian thực

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

"Chiến lược marketing"     → ⚠ không liên quan
"Nguyên tắc đạo đức nội dung" → ⚠ vấn đề khác
"Định dạng lưu hồ sơ người dùng" → ⚠ không liên quan

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

• B (nguyên tắc đạo đức) — phương án gần nhất về mặt "cũng là một cân nhắc quan trọng thật" với ứng dụng cho trẻ em, nhưng nó không phải thứ bị ràng buộc GPU chi phối.

• A và C — hoàn toàn không liên quan tới ràng buộc tính toán.

Ghi nhớ

⚠ Ràng buộc kỹ thuật ảnh hưởng lựa chọn nào — bảng nên thuộc: | Ràng buộc | Ảnh hưởng tới | |---|---| | ⚠ GPU/tài nguyên hạn chế | ⚠ cỡ mô hình, tự host hay API | | Yêu cầu độ trễ thấp | ⚠ mô hình nhỏ, cache, sinh trước | | Ngân sách | ⚠ mô hình rẻ hơn, batch | | Dữ liệu không được ra ngoài | ⚠ mô hình mở chạy tại chỗ | | Tài liệu rất dài | ⚠ cửa sổ ngữ cảnh |

Từ khoá nhận diện:

"GPU hạn chế, thời gian thực" → ⚠ chọn mô hình nhỏ hơn "dữ liệu không ra ngoài" → ⚠ mô hình mở tại chỗ "tài liệu rất dài" → cửa sổ ngữ cảnh "khối lượng rất lớn" → ⚠ batch, mô hình nhỏ

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Mô hình nhỏ đã đủ tốt chưa | ⚠ thử trước khi kết luận cần mô hình lớn | | Có phần nào sinh trước được không | ⚠ giảm tải đáng kể | | Bộ lọc an toàn đã đủ chặt chưa | ⚠ với trẻ em thì không thoả hiệp |

Và cách tiếp cận thực dụng khi bị giới hạn tài nguyên: thử mô hình nhỏ nhất trước, chỉ nâng cấp khi chất lượng thật sự không đạt. Rất nhiều đội mặc định chọn mô hình mạnh nhất rồi mới đi giải bài toán hiệu năng — trong khi trình tự ngược lại thường cho kết quả tốt hơn và rẻ hơn nhiều.

Đáp án

B — Cách tiếp cận mở của Google Cloud: hỗ trợ mô hình, công cụ mã nguồn mở và khả năng tương tác.

Vì sao đúng

Viện nghiên cứu muốn linh hoạt dùng công cụ và mô hình mã nguồn mở song song với dịch vụ độc quyền, tránh khoá chân và tận dụng đổi mới của cộng đồng. Đó chính là trụ cột "mở".

⚠ Cách tiếp cận mở thể hiện ở đâu:

⚠ MÔ HÌNH MỞ
    → Gemma; Model Garden có nhiều
      mô hình mở của bên thứ ba

⚠ FRAMEWORK MỞ
    → ⚠ TensorFlow, JAX, PyTorch
      đều chạy được trên Vertex AI

⚠ HẠ TẦNG MỞ
    → ⚠ Kubernetes, container

⚠ KHẢ NĂNG TƯƠNG TÁC
    → ⚠ dùng công cụ cộng đồng
      cùng với dịch vụ có quản lý

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

"TPU tối ưu cho mô hình Google"
    → ⚠ điểm mạnh về HIỆU NĂNG,
      nhưng nghe hướng tới ĐỘC QUYỀN
    → ngược với điều viện này ưu tiên

"Giải pháp AI đóng gói sẵn theo ngành"
    → ⚠ tiện nhưng ÍT linh hoạt —
      ngược với nhu cầu

"Tính năng bảo mật và tuân thủ
 doanh nghiệp"
    → ⚠ quan trọng, nhưng không
      trả lời cho mối lo khoá chân

Nhất quán với #13557, #13566 (lô 144) và #13517 (lô 144) — cùng chủ đề công nghệ mở chống khoá chân, cùng hướng khoá. Hoàn toàn nhất quán.

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

• D (bảo mật và tuân thủ) — phương án gần nhất vì cũng là điểm mạnh thật của nền tảng, nhưng nó trả lời cho mối lo dữ liệu, không phải mối lo linh hoạt và khoá chân.

• A và C — hướng tới hiệu năng và tiện lợi, không phải tính mở.

Ghi nhớ

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

Từ khoá nhận diện:

"mã nguồn mở, tránh khoá chân, tương tác" → ⚠ cách tiếp cận mở "chạy K8s nhiều nơi" → Anthos / GKE Enterprise "mô hình mở chạy tại chỗ" → ⚠ Gemma "nhiều nhà cung cấp đám mây" → multi-cloud

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Kết quả có tái lập ở nơi khác được không | ⚠ phép thử thật cho tính mở | | Phần nào đang phụ thuộc dịch vụ độc quyền | ⚠ biết để cân nhắc | | Chuyển đi tốn bao nhiêu | ⚠ ước tính con số |

Và phép thử thực chất cho mọi tuyên bố về tính mở: thử chạy lại đúng thí nghiệm đó ở một môi trường khác. Nếu làm được trong vài ngày thì tính mở là thật; nếu phải viết lại đáng kể, thì mức phụ thuộc cao hơn những gì bản kiến trúc thể hiện.

Đáp án

D — Grounding with Google Search.

Vì sao đúng

Nhà báo cần câu trả lời về sự kiện đang diễn ra, có trích dẫn nguồn từ các trang tin uy tín, cập nhật, trên internet CÔNG KHAI. Đó là grounding vào world data, và Google Search là nguồn đó.

⚠ Vì sao ba yêu cầu chỉ vào Google Search:

"sự kiện ĐANG DIỄN RA"
    → ⚠ vượt qua knowledge cutoff
    → ⚠ cần nguồn CẬP NHẬT liên tục

"trang tin CÔNG KHAI trên internet"
    → ⚠ world data, không phải
      tài liệu nội bộ

"TRÍCH DẪN nguồn tường minh"
    → ⚠ grounding with Search trả
      về liên kết nguồn

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

"Fine-tune trên tập SÁCH đã tuyển"
    → ⚠ dữ liệu TĨNH, lỗi thời ngay
    → ⚠ và fine-tuning KHÔNG trích
      dẫn nguồn được

"RAG dựng sẵn với Vertex AI Search
 CHỈ dùng tài liệu NỘI BỘ"
    → ⚠ đúng công nghệ, ⚠ SAI NGUỒN:
      tin tức không nằm trong tài
      liệu công ty

"RAG với vector DB của kho LƯU TRỮ
 LỊCH SỬ"
    → ⚠ lịch sử, không phải hiện tại

⚠ Đối chiếu #13859 (lô 145, first-party data) và #13902 (lô 145, tài liệu HR nội bộ) — cả ba đều là grounding, nhưng khác NGUỒN: nội bộ, bên thứ ba, hay thế giới. Không mâu thuẫn — đọc kỹ nguồn dữ liệu mà đề mô tả.

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

• B (Vertex AI Search với tài liệu nội bộ) — phương án gần nhất và là bẫy chính: đúng cơ chế RAG, nhưng nguồn dữ liệu sai hoàn toàn với nhu cầu tin tức.

• A và C — nguồn tĩnh hoặc lịch sử.

Ghi nhớ

⚠ Ba nguồn grounding — bảng phải thuộc: | Nguồn | Dùng khi | Công cụ | |---|---|---| | ⚠ First-party | ⚠ chính sách, sản phẩm của công ty | ⚠ Vertex AI Search | | Third-party | ⚠ dữ liệu mua/cấp phép | RAG tuỳ biến | | ⚠ World data | ⚠ tin tức, thông tin công khai mới | ⚠ Grounding with Google Search |

Từ khoá nhận diện:

"tin tức, sự kiện đang diễn ra, web công khai" → ⚠ Grounding with Google Search "chính sách, tài liệu công ty" → ⚠ Vertex AI Search "phong cách, thuật ngữ chuyên ngành" → fine-tuning "kho lưu trữ lịch sử" → ⚠ RAG với vector DB riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Liên kết trích dẫn có mở được không | ⚠ kiểm — mô hình có thể bịa URL | | Nguồn có uy tín không | ⚠ con người đánh giá | | Ngày của nguồn là bao giờ | ⚠ tin cũ trông giống tin mới |

Và quy tắc không được nhân nhượng khi dùng AI trong báo chí: liên kết nguồn phải được mở ra và đọc, không chỉ được liệt kê. Một trích dẫn trông chuẩn mực nhưng chưa ai kiểm chứng là cách nhanh nhất để một thông tin bịa đi qua toàn bộ quy trình biên tập.

Đáp án

A — Prompt tuning (hay soft prompting).

Vì sao đúng

Dấu hiệu quyết định: thêm một tập dữ liệu "prefix" nhỏ theo tác vụ, hướng dẫn hành vi mô hình tại thời điểm suy luận, KHÔNG thay đổi trọng số của mô hình.

⚠ Ba mức can thiệp vào mô hình:

⚠ PROMPT ENGINEERING
    → ⚠ viết câu lệnh bằng chữ
    → ⚠ không học gì cả

⚠ PROMPT TUNING / SOFT PROMPTING
    → ⚠ HỌC ra một prefix (vector)
      cho tác vụ cụ thể
    → ⚠ trọng số mô hình GIỮ NGUYÊN
    → ⚠ nhẹ, nhanh, rẻ
    → ⚠ ĐỀ NÀY

⚠ FULL FINE-TUNING
    → ⚠ cập nhật TRỌNG SỐ mô hình
    → tốn kém nhất

⚠ Vì sao prompt tuning hấp dẫn:

⚠ Chỉ học vài nghìn tham số
  thay vì hàng tỉ
⚠ Nhanh và rẻ hơn nhiều
⚠ Một mô hình nền phục vụ
  NHIỀU tác vụ, mỗi tác vụ
  một prefix riêng
⚠ Không sợ mô hình quên
  năng lực chung

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

"Full fine-tuning"
    → ⚠ đề nói RÕ là KHÔNG đổi
      trọng số

"Reinforcement learning"
    → ⚠ học qua thưởng/phạt

"Unsupervised pre-training"
    → ⚠ giai đoạn huấn luyện BAN ĐẦU
      của mô hình nền

Đối chiếu #13930 (cùng lô) — đề đó khoá fine-tuning cho chuyên biệt hoá lĩnh vực pháp lý. Đề này khoá prompt tuning vì nói rõ không đổi trọng số. Không mâu thuẫn — khác mức can thiệp, và dấu hiệu nằm ngay trong đề.

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

• C (full fine-tuning) — phương án gần nhất và là bẫy chính: cùng mục đích chuyên biệt hoá. Nhưng đề nhấn mạnh "without changing its underlying weights".

• B và D — thuộc các giai đoạn/phương pháp khác.

Ghi nhớ

⚠ Các mức tuỳ biến mô hình — bảng phải thuộc: | Mức | Đổi trọng số | Chi phí | |---|---|---| | Prompt engineering | ⚠ không | ⚠ thấp nhất | | ⚠ Prompt tuning / soft prompt | ⚠ KHÔNG — học prefix | ⚠ thấp | | ⚠ PEFT / LoRA | ⚠ đổi MỘT PHẦN NHỎ | trung bình | | ⚠ Full fine-tuning | ⚠ đổi TOÀN BỘ | ⚠ cao nhất | | Huấn luyện từ đầu | ⚠ tạo mô hình mới | ⚠ cực cao |

Từ khoá nhận diện:

"prefix học được, không đổi trọng số" → ⚠ prompt tuning "huấn luyện thêm trên dữ liệu riêng" → fine-tuning "viết câu lệnh bằng chữ" → prompt engineering "nối với tài liệu" → grounding

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đã thử prompt kỹ chưa | ⚠ bước rẻ nhất | | Vấn đề là phong cách hay kiến thức | ⚠ kiến thức → grounding, không phải tuning | | Có bao nhiêu ví dụ chất lượng | ⚠ quyết định chọn kỹ thuật nào |

Và điều làm nên sức hấp dẫn của cả họ kỹ thuật tuỳ biến nhẹ này: một mô hình nền duy nhất có thể phục vụ hàng chục tác vụ khác nhau, mỗi tác vụ chỉ cần thêm một phần rất nhỏ được học riêng — thay vì phải nuôi hàng chục bản sao mô hình đầy đủ.