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

Đáp án

C — Vertex AI Model Registry.

Vì sao đúng

Đề nêu ba nhu cầu, và cả ba đều là việc của Model Registry:

⚠ Ghép ba nhu cầu:

"theo dõi thử nghiệm"
    → ⚠ liên kết mô hình với lần chạy

"quản lý các PHIÊN BẢN mô hình"
    → ⚠ chức năng cốt lõi của Registry

"lưu hồ sơ thay đổi"
    → ⚠ ai đăng ký, khi nào, từ đâu

⚠ Registry là kho trung tâm cho mô hình:

⚠ Đăng ký mô hình đã huấn luyện
⚠ Đánh phiên bản
⚠ Gắn nhãn: staging, production
⚠ Từ đây TRIỂN KHAI ra endpoint
⚠ Quay lui phiên bản khi cần

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

• D (Git) — ⚠ bẫy mạnh nhất: Git đúng là công cụ quản lý phiên bản, nhưng cho MÃ NGUỒN. ⚠ Mô hình đã huấn luyện là tệp nhị phân hàng trăm MB tới hàng GB kèm siêu dữ liệu, chỉ số đánh giá, nguồn gốc dữ liệu — Git không thiết kế cho thứ đó.

• A (Model Monitoring) — theo dõi mô hình SAU KHI triển khai: phát hiện trôi dạt dữ liệu, suy giảm chất lượng. ⚠ Là bước sau, không phải quản lý phiên bản.

• B (Workflow orchestrations) — điều phối các bước của quy trình (Pipelines). ⚠ Nó gọi Registry chứ không thay thế.

Ghi nhớ

⚠ Vertex AI theo vòng đời — bảng phải thuộc: | Giai đoạn | Công cụ | |---|---| | Phát triển | ⚠ Workbench | | Tinh chỉnh tham số | ⚠ Vizier | | Theo dõi thử nghiệm | ⚠ Experiments | | ⚠ Quản lý phiên bản mô hình | ⚠ MODEL REGISTRY — đề này | | Tự động hoá | ⚠ Pipelines | | Phục vụ | ⚠ Prediction / Endpoints | | Theo dõi sau triển khai | ⚠ Model Monitoring |

Từ khoá nhận diện:

"phiên bản mô hình, đăng ký, quay lui" → ⚠ Model Registry "trôi dạt, chất lượng giảm sau khi chạy" → Model Monitoring "chạy các bước theo thứ tự, tự động" → Pipelines "phiên bản MÃ NGUỒN" → ⚠ Git — khác với phiên bản MÔ HÌNH

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Biết chính xác phiên bản nào đang chạy không | ⚠ câu hỏi cơ bản mà nhiều đội không trả lời được | | Quay lui mất bao lâu | ⚠ thử một lần trước khi cần thật | | Mô hình có kèm hồ sơ nguồn gốc không | ⚠ dữ liệu nào, ai huấn luyện, chỉ số bao nhiêu |

Và câu hỏi kiểm tra mức trưởng thành MLOps của một đội: "mô hình đang phục vụ khách hàng lúc này được huấn luyện từ dữ liệu nào?" Đội có Registry trả lời trong một phút; đội không có thường không trả lời được.

Đáp án

B — Vòng lặp suy luận (reasoning loop) và công cụ (tools).

Vì sao đúng

Đây là định nghĩa cốt lõi phân biệt agent với một mô hình đứng riêng.

⚠ Hai yếu tố:

⚠ VÒNG LẶP SUY LUẬN
   → ⚠ suy nghĩ → hành động → quan sát
   → ⚠ lặp lại tới khi xong
   → ⚠ mô hình đơn lẻ chỉ chạy MỘT LƯỢT

⚠ CÔNG CỤ
   → ⚠ gọi API, truy vấn CSDL, chạy code
   → ⚠ mô hình đơn lẻ chỉ SINH CHỮ

⚠ So sánh trực tiếp:

Mô hình đơn lẻ:
   prompt → ⚠ MỘT câu trả lời → hết

⚠ Agent:
   mục tiêu
     → ⚠ nghĩ xem cần làm gì
     → ⚠ gọi công cụ
     → ⚠ xem kết quả
     → ⚠ nghĩ tiếp
     → ... → ⚠ hoàn thành VIỆC

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

• C (truy cập dữ liệu và giao diện người dùng) — ⚠ bẫy hợp lý: agent thường có cả hai. Nhưng ⚠ một chatbot RAG thường cũng có cả hai mà không phải agent. Đây là đặc điểm đi kèm, không phải yếu tố phân biệt.

• A (phần cứng TPU chạy tại chỗ và khả năng huấn luyện bằng machine learning) — ⚠ lạc đề hoàn toàn: nói về hạ tầng và huấn luyện, không nói gì về agent.

• D (RPA và cá nhân hoá grounding) — ⚠ ghép hai khái niệm không liên quan. RPA là tự động hoá quy trình theo luật cứng — thực ra là thứ agent thay thế, không phải thành phần của agent.

Ghi nhớ

⚠ Bốn thành phần của agent — bảng phải thuộc: | Thành phần | Vai trò | |---|---| | ⚠ Mô hình | ⚠ bộ não suy luận | | ⚠ Vòng lặp suy luận | ⚠ lập kế hoạch, lặp lại — đề này | | ⚠ Công cụ | ⚠ tay chân — API, CSDL, code — đề này | | Bộ nhớ | ⚠ ngữ cảnh trong và giữa các phiên |

Từ khoá nhận diện:

"reasoning loop, tools, thực hiện hành động" → ⚠ agent "chỉ trả lời câu hỏi" → ⚠ mô hình hoặc chatbot RAG "luật cứng, kịch bản cố định" → ⚠ RPA, không phải agent

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent gọi công cụ nào, thứ tự nào | ⚠ đọc log vòng lặp | | Có giới hạn số bước chưa | ⚠ tránh vòng lặp vô hạn | | Công cụ có quyền tối thiểu chưa | ⚠ giới hạn thiệt hại khi agent quyết sai |

Và cách nhận ra một hệ thống có thật sự là agent hay không: nó có làm được VIỆC gì ngoài đời thật không. Trả lời hay tới đâu mà không đặt được đơn, không tạo được vé, không gửi được email thì vẫn là mô hình, chưa phải agent.

Đáp án

B — Zero-shot prompting.

Vì sao đúng

"Zero-shot" nghĩa đen là KHÔNG có ví dụ nào, hoàn toàn dựa vào tri thức mô hình đã học sẵn.

⚠ Bậc thang số ví dụ:

⚠ Zero-shot  → 0 ví dụ
⚠ One-shot   → 1 ví dụ
⚠ Few-shot   → vài ví dụ

⚠ Ví dụ zero-shot:

"Phân loại cảm xúc câu sau:
 'Dịch vụ tuyệt vời!'"
        ↓
⚠ Không cho mẫu nào
⚠ Mô hình tự biết phân loại
  cảm xúc là gì

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

• A (One-shot) — ⚠ có một ví dụ. Sai vì đề nói "without ANY provided examples".

• C (Few-shot) — ⚠ có vài ví dụ.

• D (Multi-shot) — ⚠ cách gọi khác của few-shot, cũng có nhiều ví dụ. ⚠ Đây là phương án gây nhiễu bằng một thuật ngữ nghe lạ hơn.

Ghi nhớ

⚠ Ba bậc và khi nào dùng — bảng phải thuộc: | Bậc | Số ví dụ | Dùng khi | |---|---|---| | ⚠ Zero-shot | ⚠ 0 | ⚠ việc phổ thông, mô hình đã biết — đề này | | One-shot | ⚠ 1 | ⚠ cần chỉ rõ ĐỊNH DẠNG | | ⚠ Few-shot | ⚠ vài | ⚠ việc đặc thù, cần bắt chước phong cách |

Từ khoá nhận diện:

"không ví dụ, dựa hoàn toàn tri thức sẵn có" → ⚠ zero-shot "đây là một mẫu" → one-shot "đây là vài mẫu" → ⚠ few-shot = multi-shot "suy nghĩ từng bước" → ⚠ chain-of-thought — khác nhóm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Zero-shot đã đủ chưa | ⚠ thử trước khi thêm ví dụ | | Ví dụ few-shot có đại diện không | ⚠ kể cả ca khó, không chỉ ca dễ | | Prompt dài thêm tốn bao nhiêu | ⚠ nhân với số lượt gọi |

Và nguyên tắc thực dụng khi viết prompt: bắt đầu từ zero-shot và chỉ leo lên khi ĐO được là chưa đủ. Rất nhiều đội dán ngay năm ví dụ vào prompt cho mọi lời gọi, trả tiền token cho chúng suốt cả năm, mà chưa từng thử xem không có chúng thì kết quả có kém đi thật không.

Đáp án

B — Gemini Code Assist.

Vì sao đúng

Đề nói rõ đối tượng là đội lập trình viên, mục tiêu là hiệu suất viết mã và cộng tác. Chỉ Code Assist nhắm đúng vào việc đó.

⚠ Code Assist làm gì:

⚠ Gợi ý và hoàn thành mã trong IDE
⚠ Sinh hàm từ mô tả bằng lời
⚠ Giải thích đoạn mã lạ
⚠ Sinh test
⚠ Rà soát và gợi ý sửa
⚠ Chuyển đổi giữa ngôn ngữ

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

Cả ba đều là Gemini cho Google Cloud nhưng phục vụ vai trò khác:

• A (Gemini Cloud Assist) — ⚠ bẫy mạnh nhất vì tên rất giống. Nó hỗ trợ vận hành hạ tầng đám mây: thiết kế kiến trúc, chẩn đoán sự cố, tối ưu chi phí. ⚠ Dành cho kỹ sư hạ tầng/SRE, không phải cho việc viết mã ứng dụng.

• C (Gemini in Databases) — hỗ trợ quản trị viên CSDL: viết SQL, tối ưu truy vấn, di trú.

• D (Gemini in Security Command Center) — hỗ trợ đội bảo mật: tóm tắt cảnh báo, giải thích lỗ hổng.

Ghi nhớ

⚠ Gemini cho từng vai trò — bảng phải thuộc: | Công cụ | Ai dùng | |---|---| | ⚠ Code Assist | ⚠ lập trình viên — đề này | | ⚠ Cloud Assist | ⚠ kỹ sư hạ tầng, vận hành | | Gemini in Databases | ⚠ quản trị CSDL | | Gemini in SCC | ⚠ đội bảo mật | | Gemini for Workspace | ⚠ nhân viên văn phòng |

Từ khoá nhận diện:

"viết mã, IDE, hiệu suất lập trình" → ⚠ Code Assist "kiến trúc, chi phí, sự cố hạ tầng" → ⚠ Cloud Assist "SQL, tối ưu truy vấn" → Gemini in Databases "cảnh báo bảo mật" → Gemini in SCC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mã sinh ra có được rà soát như mã người viết không | ⚠ cùng một tiêu chuẩn | | Có quét bảo mật tự động không | ⚠ AI hay bỏ sót kiểm tra đầu vào | | Dữ liệu mã nguồn có bị gửi ra ngoài không | ⚠ dùng bản doanh nghiệp |

Và điều thực tế nhất về AI hỗ trợ lập trình: nó tăng tốc phần GÕ, không thay phần HIỂU. Lập trình viên hiểu bài toán sẽ nhanh hơn nhiều nhờ nó; người chưa hiểu thì chỉ tạo ra mã hỏng nhanh hơn.

Đáp án

C — Nó ảnh hưởng tới phong cách, giọng điệu và trọng tâm câu trả lời bằng cách gán cho mô hình một vai cụ thể.

Vì sao đúng

Role prompting (gán vai) hoạt động bằng cách đặt mô hình vào một góc nhìn, từ đó thu hẹp cách nó diễn đạt.

⚠ Cùng một câu hỏi, ba vai:

"Giải thích lạm phát"

⚠ "Đóng vai giáo viên tiểu học"
   → ⚠ ví von đơn giản, câu ngắn

⚠ "Đóng vai nhà kinh tế học"
   → ⚠ thuật ngữ chuyên ngành,
     dẫn lý thuyết

⚠ "Đóng vai cố vấn tài chính"
   → ⚠ hướng vào tác động lên
     tiền của người nghe

⚠ Nội dung sự thật không đổi — cách trình bày và trọng tâm mới đổi.

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

• B (cải thiện khả năng hiểu câu hỏi phức tạp) — ⚠ bẫy tinh vi: gán vai giúp câu trả lời phù hợp hơn, nhưng không làm mô hình hiểu sâu hơn. Muốn xử lý câu hỏi phức tạp thì dùng chain-of-thought.

• A (cho phép mô hình học từ vài ví dụ) — ⚠ đó là few-shot prompting, kỹ thuật khác.

• D (cho phép làm việc phức tạp như lên lịch trình chuyến công tác) — ⚠ đó là việc của agent với công cụ, không phải của một câu gán vai.

Ghi nhớ

⚠ Bốn kỹ thuật và tác dụng — bảng phải thuộc: | Kỹ thuật | Tác dụng | |---|---| | ⚠ Role prompting | ⚠ phong cách, giọng điệu, trọng tâm — đề này | | Few-shot | ⚠ định dạng và cách làm | | Chain-of-thought | ⚠ chất lượng SUY LUẬN | | Ràng buộc | ⚠ cái phải TRÁNH | | ReAct + công cụ | ⚠ thực hiện việc nhiều bước |

Từ khoá nhận diện:

"Act as…, You are a…, đóng vai" → ⚠ role prompting "đây là ví dụ" → few-shot "suy nghĩ từng bước" → chain-of-thought "gọi API, đặt vé" → agent

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vai có làm đổi nội dung sự thật không | ⚠ so hai đầu ra cùng câu hỏi | | Có tạo cảm giác chuyên môn giả không | ⚠ với lĩnh vực y tế, pháp lý phải rất cẩn trọng | | Vai có bền qua nhiều lượt không | ⚠ thường phải nhắc lại |

Và điều đáng nhớ về giới hạn của kỹ thuật này: gán vai đổi cách nói, không đổi cái biết. Bảo mô hình đóng vai chuyên gia không làm nó chính xác hơn — chỉ làm nó nghe có vẻ chắc chắn hơn, mà đó đôi khi lại là điều nguy hiểm.

Đáp án

B — Temperature.

Vì sao đúng

Temperature là tham số điều khiển độ ngẫu nhiên khi mô hình chọn từ tiếp theo.

⚠ Cơ chế:

Mô hình tính xác suất cho từ kế tiếp
        ↓
⚠ Temperature THẤP (0–0,3)
   → ⚠ luôn chọn từ xác suất cao nhất
   → ⚠ đầu ra ỔN ĐỊNH, lặp lại được
   → ⚠ dùng cho: trích xuất, phân loại,
     hỏi đáp có nguồn

⚠ Temperature CAO (0,8–1,0+)
   → ⚠ cho từ xác suất thấp cơ hội
   → ⚠ đầu ra ĐA DẠNG, sáng tạo
   → ⚠ dùng cho: động não, viết
     quảng cáo, truyện

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

• D (Output length) — ⚠ bẫy hợp lý: giới hạn ĐỘ DÀI câu trả lời, không ảnh hưởng tới việc chọn từ nào.

• A (Token count) — ⚠ đếm token, dùng để tính chi phí và giới hạn, không điều khiển tính sáng tạo.

• C (Safety settings) — ⚠ chặn nội dung có hại, hoàn toàn khác chức năng.

Ghi nhớ

⚠ Các tham số sinh — bảng phải thuộc: | Tham số | Điều khiển | |---|---| | ⚠ Temperature | ⚠ độ ngẫu nhiên / sáng tạo — đề này | | Top-k | ⚠ chỉ xét k từ có xác suất cao nhất | | Top-p | ⚠ xét đủ từ để đạt xác suất tích luỹ p | | Max output tokens | ⚠ ĐỘ DÀI câu trả lời | | Safety settings | ⚠ chặn nội dung có hại | | Stop sequences | ⚠ dừng khi gặp chuỗi nhất định |

Từ khoá nhận diện:

"ngẫu nhiên, sáng tạo, đa dạng" → ⚠ temperature "độ dài, cắt bớt, chi phí token" → ⚠ max output tokens "chặn nội dung có hại" → safety settings "chính xác, nhất quán, lặp lại được" → ⚠ temperature THẤP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy cùng prompt 5 lần có ra giống nhau không | ⚠ kiểm mức biến động | | Việc này cần ổn định hay cần đa dạng | ⚠ quyết định trước khi chỉnh | | Hạ temperature có làm câu trả lời cứng nhắc quá không | ⚠ cân bằng bằng thử nghiệm |

Và ngộ nhận phổ biến nhất: temperature = 0 không có nghĩa là câu trả lời đúng. Nó chỉ có nghĩa là mô hình sẽ đưa ra cùng một câu trả lời mỗi lần — kể cả khi câu đó sai. Độ chính xác đến từ grounding, không đến từ tham số sinh.

Đáp án

A — LLM truy vấn kho dữ liệu để lấy thông tin liên quan tới yêu cầu của người dùng, làm giàu cho câu trả lời.

Vì sao đúng

Đây là mô tả đúng luồng RAG: truy hồi trước, sinh sau.

⚠ Luồng RAG:

Câu hỏi người dùng
        ↓
⚠ TRUY HỒI — tìm đoạn liên quan
  trong kho dữ liệu
        ↓
⚠ GHÉP đoạn đó vào prompt
        ↓
⚠ LLM sinh câu trả lời DỰA TRÊN
  đoạn được đưa vào
        ↓
⚠ Kèm trích dẫn nguồn

⚠ Điểm mấu chốt:

⚠ Kiến thức nằm NGOÀI mô hình
⚠ Đưa vào lúc CHẠY, qua prompt
⚠ KHÔNG đụng tới trọng số

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

• B (LLM dùng kho dữ liệu để MỞ RỘNG VĨNH VIỄN tri thức nền và tham số) — ⚠ bẫy mạnh nhất và là hiểu lầm phổ biến nhất về RAG. ⚠ RAG KHÔNG thay đổi trọng số mô hình; thay đổi trọng số là fine-tuning, chuyện hoàn toàn khác.

• C (LLM CHỈ dựa vào kho dữ liệu, BỎ QUA tri thức nội tại) — ⚠ quá tuyệt đối: mô hình vẫn dùng khả năng ngôn ngữ và suy luận của nó để hiểu và diễn đạt; kho dữ liệu cung cấp sự thật, không cung cấp khả năng viết.

• D (LLM thụ động nhận thông tin được đẩy tới) — ⚠ sai chiều: RAG là kéo theo yêu cầu, không phải đẩy định kỳ.

Ghi nhớ

⚠ RAG khác Fine-tuning — bảng phải thuộc: | Tiêu chí | RAG | Fine-tuning | |---|---|---| | ⚠ Trọng số | ⚠ KHÔNG đổi | ⚠ có đổi | | ⚠ Kiến thức nằm ở | ⚠ kho ngoài | ⚠ trong trọng số | | ⚠ Cập nhật | ⚠ sửa tài liệu là xong | ⚠ phải huấn luyện lại | | Trích dẫn | ⚠ có | ⚠ không | | Dạy gì | ⚠ BIẾT GÌ | ⚠ NÓI THẾ NÀO |

Từ khoá nhận diện:

"truy hồi rồi mới sinh, kèm nguồn" → ⚠ RAG "mở rộng tham số vĩnh viễn" → ⚠ mô tả SAI về RAG "bỏ qua hoàn toàn tri thức mô hình" → ⚠ quá tuyệt đối, sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đoạn truy hồi có thật sự liên quan không | ⚠ xem đoạn được lấy, không chỉ xem câu trả lời | | Hỏi câu không có trong kho thì sao | ⚠ phải nói không biết | | Tài liệu lỗi thời đã gỡ chưa | ⚠ rà chỉ mục định kỳ |

Và cách nhớ bản chất RAG chính xác nhất: nó là một hình thức đưa tài liệu vào prompt, chỉ khác là việc chọn tài liệu được tự động hoá. Hiểu vậy thì không bao giờ nhầm nó với việc huấn luyện lại mô hình.

Đáp án

C — Tạo hình ảnh chân thực về nguyên mẫu sản phẩm mới từ mô tả bằng chữ.

Vì sao đúng

CEO nghĩ gen AI chỉ để làm chatbot. Phương án thuyết phục nhất phải là việc rõ ràng không phải chatbot mà vẫn mang giá trị kinh doanh trực tiếp.

⚠ Vì sao ví dụ này phá được định kiến:

⚠ Không phải hội thoại
⚠ Đầu ra là HÌNH ẢNH
⚠ Giá trị nghiệp vụ rõ ràng:
   → ⚠ thử nhiều phương án thiết kế
     trước khi làm mẫu thật
   → ⚠ tiết kiệm chi phí tạo mẫu
   → ⚠ rút ngắn thời gian ra thị trường

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

• A (đếm số khách truy cập website và vị trí của họ) — ⚠ phân tích web thông thường, không cần AI, càng không cần gen AI.

• B (đặt lịch họp và quản lý lịch) — ⚠ tự động hoá lịch biểu, phần mềm thường làm được từ lâu. Không thể hiện năng lực SINH.

• D (đưa ra câu trả lời CHUNG CHUNG cho mọi thắc mắc bất kể vấn đề cụ thể) — ⚠ phản tác dụng hoàn toàn: nó vừa là chatbot, vừa là chatbot kém, càng củng cố định kiến của CEO.

Ghi nhớ

⚠ Gen AI không chỉ là chatbot — bảng phải thuộc: | Ứng dụng | Ví dụ | |---|---| | ⚠ Sinh ảnh, thiết kế | ⚠ nguyên mẫu sản phẩm — đề này | | Sinh nội dung marketing | ⚠ quy mô lớn, cá nhân hoá | | ⚠ Sinh mã | ⚠ tăng tốc kỹ thuật | | Tóm tắt tài liệu | ⚠ hợp đồng, báo cáo | | ⚠ Sinh dữ liệu tổng hợp | ⚠ khi không được dùng dữ liệu thật | | Dịch và bản địa hoá | | | ⚠ Khám phá insight | |

Từ khoá nhận diện:

"tạo ra thứ mới: ảnh, thiết kế, mã, nội dung" → ⚠ gen AI "đếm, thống kê" → ⚠ phân tích thường "đặt lịch, quy trình cố định" → ⚠ tự động hoá thường "trả lời chung chung" → ⚠ chatbot kém, phản ví dụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh nguyên mẫu có khả thi để sản xuất không | ⚠ kỹ sư phải xem | | Có vi phạm thiết kế của đối thủ không | ⚠ kiểm bản quyền kiểu dáng | | Ảnh có ghi rõ là do AI tạo không | ⚠ khi đưa cho khách hàng xem |

Và cách hiệu quả nhất để đổi cách nghĩ "gen AI = chatbot": cho xem một đầu ra không phải chữ. Một loạt ảnh sản phẩm sinh trong mười phút nói được nhiều hơn bất kỳ bài giải thích nào về mô hình nền.

Đáp án

C — Mô hình nền được huấn luyện trên lượng dữ liệu khổng lồ, đa dạng, cho nhiều nhiệm vụ; còn mô hình truyền thống được huấn luyện trên dữ liệu riêng cho một nhiệm vụ duy nhất.

Vì sao đúng

Đây là khác biệt định nghĩa giữa hai thế hệ mô hình.

⚠ So sánh:

Mô hình truyền thống
   ⚠ một mô hình = MỘT việc
   ⚠ dữ liệu riêng cho việc đó
   ⚠ muốn việc khác → mô hình khác
   → ví dụ: mô hình phát hiện spam

⚠ Mô hình nền
   ⚠ huấn luyện trên dữ liệu KHỔNG LỒ,
     ĐA DẠNG
   ⚠ MỘT mô hình làm được NHIỀU việc
   ⚠ thích ứng bằng prompt hoặc
     tinh chỉnh nhẹ

⚠ Vì sao gọi là "nền":

⚠ Nó là NỀN MÓNG
⚠ Xây nhiều ứng dụng lên trên
⚠ Không phải xây lại từ đầu
  cho mỗi việc

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

• B — ⚠ đảo ngược hoàn toàn: gán đặc điểm của mô hình truyền thống cho mô hình nền và ngược lại. ⚠ Đây là dạng bẫy "đúng nội dung, sai vị trí" rất hay gặp — phải đọc kỹ vế nào nói về cái gì.

• A (mô hình nền chỉ huấn luyện trên dữ liệu văn bản, mô hình truyền thống dùng ảnh và mã) — ⚠ sai sự thật: mô hình nền có cả loại đa phương thức, và mô hình truyền thống cũng làm việc với văn bản.

• D (mô hình nền KHÔNG thích ứng được với nhiệm vụ mới) — ⚠ ngược hẳn: khả năng thích ứng chính là điểm mạnh nhất của mô hình nền.

Ghi nhớ

⚠ Hai thế hệ — bảng phải thuộc: | Tiêu chí | Truyền thống | ⚠ Mô hình nền | |---|---|---| | Dữ liệu | ⚠ riêng cho một việc | ⚠ khổng lồ, đa dạng | | Số việc | ⚠ một | ⚠ nhiều | | ⚠ Thích ứng | ⚠ huấn luyện mô hình mới | ⚠ prompt hoặc tinh chỉnh | | Chi phí bắt đầu | ⚠ thấp mỗi mô hình | ⚠ rất cao để huấn luyện, rẻ để DÙNG | | Dữ liệu gán nhãn | ⚠ cần nhiều | ⚠ cần ít hoặc không |

Từ khoá nhận diện:

"đa dạng, nhiều nhiệm vụ, thích ứng" → ⚠ mô hình nền "một nhiệm vụ, dữ liệu chuyên biệt" → ⚠ mô hình truyền thống "không thích ứng được" → ⚠ luôn SAI khi nói về mô hình nền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc này có cần mô hình nền không | ⚠ phân loại đơn giản thì mô hình nhỏ rẻ hơn nhiều | | Chi phí mỗi lượt gọi | ⚠ nhân với khối lượng | | Có cần giải thích quyết định không | ⚠ ràng buộc pháp lý ở nhiều ngành |

Và điều dễ bị bỏ qua trong cơn sốt mô hình nền: rất nhiều bài toán kinh doanh vẫn được giải tốt nhất bằng một mô hình nhỏ, chuyên dụng. Dùng mô hình nền cho việc phân loại hàng triệu bản ghi mỗi ngày thường là lựa chọn đắt hơn mà không chính xác hơn.

Đáp án

A — Artificial intelligence (Trí tuệ nhân tạo).

Vì sao đúng

Đề định nghĩa gần như nguyên văn: lĩnh vực RỘNG của khoa học máy tính, tạo ra máy làm được việc vốn cần trí tuệ con người. Đó là định nghĩa của AI.

⚠ Vòng tròn lồng nhau:

┌──────── AI ────────┐
│ ⚠ RỘNG NHẤT       │
│ ┌───── ML ──────┐  │
│ │ ⚠ học từ dữ liệu│ │
│ │ ┌─ Deep L. ──┐ │  │
│ │ │ ⚠ mạng nơ-ron│ │
│ │ └────────────┘ │  │
│ └───────────────┘  │
└────────────────────┘

⚠ Gần trùng với #14096 (lô 150) — cùng khoá là AI, cùng bài học "chọn vòng ngoài cùng khi đề nói RỘNG". Lô 150 hỏi qua tình huống CEO, lô này hỏi trực tiếp định nghĩa.

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

• D (Machine learning) — ⚠ bẫy mạnh nhất: là tập con của AI, giới hạn ở các hệ thống học từ dữ liệu. ⚠ AI còn bao gồm hệ chuyên gia dựa luật, tìm kiếm, lập kế hoạch — những thứ không học từ dữ liệu.

• B (Deep learning) — ⚠ tập con của ML, hẹp hơn nữa.

• C (Prompting) — ⚠ một kỹ thuật sử dụng, không phải một lĩnh vực khoa học.

Ghi nhớ

⚠ Bốn tầng — bảng phải thuộc: | Tầng | Định nghĩa | |---|---| | ⚠ AI | ⚠ lĩnh vực RỘNG NHẤT — đề này | | ML | ⚠ học từ dữ liệu | | Deep Learning | ⚠ ML dùng mạng nơ-ron nhiều lớp | | Gen AI | ⚠ sinh nội dung mới — hẹp nhất |

Từ khoá nhận diện:

"lĩnh vực rộng, bao trùm" → ⚠ AI "học từ dữ liệu" → ML "mạng nơ-ron sâu" → Deep Learning "cách viết câu lệnh" → ⚠ prompting — kỹ thuật, không phải lĩnh vực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ thống này có học từ dữ liệu không | ⚠ không thì là AI chứ không phải ML | | Nói với ai | ⚠ thuật ngữ phải khớp người nghe | | Có đang dùng từ rộng để che sự mơ hồ không | ⚠ "chúng tôi dùng AI" nói rất ít |

Và điều đáng nhớ khi trình bày dự án: gọi mọi thứ là "AI" thì đúng nhưng vô nghĩa. Trong tài liệu kỹ thuật hoặc đề xuất ngân sách, gọi đúng tên — hồi quy logistic, mô hình nền, hệ luật — nói được nhiều hơn hẳn.