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

Đáp án

A — AutoML.

Vì sao đúng

Đề nêu ba dữ kiện: có dữ liệu riêng (lịch sử mua hàng, thông tin sản phẩm), đội ít kinh nghiệm xây mô hình phức tạp, và cần giải pháp tự động hoá phần lớn quá trình để có mô hình tuỳ biến chất lượng cao.

⚠ Ba dữ kiện khớp:

"có dữ liệu riêng, muốn mô hình
 TUỲ BIẾN"
    → ⚠ loại API dựng sẵn

"đội ÍT kinh nghiệm phát triển
 mô hình phức tạp"
    → ⚠ loại custom training

"TỰ ĐỘNG HOÁ phần lớn quá trình"
    → ⚠ đúng định nghĩa AutoML
        ↓
    ⚠ AutoML tự chọn kiến trúc,
      tự tinh chỉnh tham số,
      tự đánh giá

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

"Model Garden"
    → ⚠ DANH MỤC mô hình CÓ SẴN
      để chọn, không huấn luyện
      trên dữ liệu riêng của bạn

"Vertex AI Search"
    → ⚠ tìm kiếm và gợi ý dạng
      dịch vụ, không phải huấn
      luyện mô hình tuỳ biến

"Vertex AI Vizier"
    → ⚠ CHỈ tối ưu siêu tham số —
      một PHẦN việc, và vẫn đòi
      bạn tự viết mã mô hình

Nhất quán với #13549 (lô 144) và #13497 (lô 143) — cùng khoá AutoML cho tình huống "dữ liệu riêng + đội thiếu chuyên môn ML". Đối chiếu #13892 (cùng lô) khoá Model Garden vì ở đó là chọn mô hình có sẵn, không phải huấn luyện. Không mâu thuẫn.

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

• D (Vizier) — phương án gần nhất và là bẫy tinh tế: nó thật sự tự động hoá một phần việc dựng mô hình. Nhưng nó chỉ lo khâu tìm siêu tham số, còn mã mô hình vẫn phải do bạn viết.

• B (Model Garden) và C (Vertex AI Search) — không huấn luyện mô hình trên dữ liệu riêng theo cách đề mô tả.

Ghi nhớ

⚠ Bốn nấc theo mức tự động hoá — bảng phải thuộc: | Nấc | Bạn làm gì | |---|---| | API dựng sẵn | ⚠ chỉ gọi | | ⚠ AutoML | ⚠ cung cấp DỮ LIỆU — đề này | | AutoML + Vizier | ⚠ viết mã, để Vizier dò tham số | | Custom training | ⚠ viết toàn bộ mã mô hình |

Từ khoá nhận diện:

"tự động hoá dựng mô hình, đội ít kinh nghiệm" → ⚠ AutoML "chọn mô hình có sẵn" → Model Garden "chỉ dò siêu tham số" → ⚠ Vizier "biết SQL, dữ liệu ở BigQuery" → BigQuery ML

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có cột nào lộ đáp án không | ⚠ kiểm từng cột đầu vào | | Chỉ số đánh giá bao nhiêu | ⚠ đừng chỉ nhìn accuracy | | Đã thử giải pháp đóng gói sẵn chưa | ⚠ có khi rẻ và nhanh hơn |

Và cái bẫy đắt giá nhất với mọi mô hình dự đoán hành vi mua hàng: một cột trong dữ liệu vô tình chứa thông tin chỉ tồn tại sau khi việc mua đã xảy ra. Mô hình sẽ đạt điểm gần như hoàn hảo lúc kiểm thử, rồi vô dụng khi chạy thật — và AutoML không phát hiện giúp bạn điều đó.

Đáp án

D — Mức cải thiện tỉ lệ nhấp chuột (CTR) mong muốn cho các chiến dịch email.

Vì sao đúng

Câu hỏi hỏi về yêu cầu NGHIỆP VỤ. CTR là mục tiêu kinh doanh đo được; ba phương án kia đều là ràng buộc kỹ thuật.

⚠ Phân biệt hai loại yêu cầu:

⚠ YÊU CẦU NGHIỆP VỤ
    → ⚠ "muốn ĐẠT ĐƯỢC gì"
    → ⚠ CTR tăng bao nhiêu %
    → doanh thu, chi phí tiết kiệm,
      thời gian rút ngắn
    → ⚠ ĐỀ NÀY

⚠ YÊU CẦU KỸ THUẬT
    → ⚠ "làm BẰNG CÁCH NÀO"
    → GPU, ngôn ngữ lập trình,
      dùng mô hình sẵn hay tự xây

⚠ Vì sao thứ tự này quan trọng:

Bắt đầu bằng câu hỏi kỹ thuật
        ↓
    ⚠ "nên dùng mô hình nào?"
    ⚠ mà chưa biết THÀNH CÔNG
      nghĩa là gì
        ↓
    ⚠ dự án chạy xong không ai
      nói được nó có đáng không
        ↓
⚠ Bắt đầu bằng mục tiêu nghiệp vụ
        ↓
    ⚠ CTR hiện tại là bao nhiêu?
    ⚠ Muốn tăng lên bao nhiêu?
    ⚠ Mức đó đáng bao nhiêu tiền?
        ↓
    → ⚠ có tiêu chí để QUYẾT và ĐO

Nhất quán với #13894 (cùng lô) — đề đó về việc chọn chỉ số trực tiếp để đo thành công. Cùng thông điệp: định nghĩa thành công bằng con số nghiệp vụ trước.

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

• C (chọn mô hình sẵn hay tự xây) — phương án gần nhất vì đó thật sự là quyết định quan trọng của dự án, nhưng nó là quyết định kỹ thuật, đi sau mục tiêu nghiệp vụ.

• A (GPU) và B (ngôn ngữ lập trình) — thuần kỹ thuật.

Ghi nhớ

⚠ Câu hỏi nghiệp vụ phải trả lời TRƯỚC — bảng nên thuộc: | Câu hỏi | Vì sao | |---|---| | ⚠ Thành công đo bằng gì | ⚠ CTR, doanh thu, thời gian | | ⚠ Đường cơ sở hiện tại là bao nhiêu | ⚠ không có thì không so được | | ⚠ Cải thiện bao nhiêu thì ĐÁNG đầu tư | | | Ai là người dùng, họ cần gì | | | Ràng buộc pháp lý, thương hiệu | ⚠ email cá nhân hoá đụng quyền riêng tư | | Rủi ro nếu AI làm sai | ⚠ email sai gửi cho khách |

Từ khoá nhận diện:

"CTR, doanh thu, thời gian tiết kiệm" → ⚠ yêu cầu nghiệp vụ "GPU, ngôn ngữ, kiến trúc" → ⚠ yêu cầu kỹ thuật "đo tác động của tính năng" → chỉ số trực tiếp "dữ liệu có sạch không" → ⚠ điều kiện tiên quyết

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | CTR hiện tại là bao nhiêu | ⚠ không biết thì chưa nên bắt đầu | | Tăng bao nhiêu thì đáng tiền | ⚠ có ngưỡng để quyết dừng hay tiếp | | Có A/B test được không | ⚠ cách duy nhất chứng minh nhân quả |

Và câu hỏi nên đặt ra trong cuộc họp đầu tiên của mọi dự án AI, trước mọi thảo luận về mô hình: sáu tháng nữa, chúng ta nhìn vào con số nào để biết việc này có đáng hay không? Nếu chưa ai trả lời được, thì đó là việc cần làm xong trước khi viết dòng mã đầu tiên.

Đáp án

C — Data Preparation (chuẩn bị dữ liệu).

Vì sao đúng

Làm sạch dữ liệu, xử lý giá trị thiếu và chuyển đổi về định dạng phù hợp — cả ba đều là chuẩn bị dữ liệu, diễn ra sau khi nạp và trước khi huấn luyện.

⚠ Vòng đời ML:

⚠ DATA INGESTION
    → ⚠ ĐƯA dữ liệu thô vào hệ thống

⚠ DATA PREPARATION
    → ⚠ làm sạch, xử lý giá trị thiếu,
      chuyển đổi định dạng
    → ⚠ tạo đặc trưng
    → ⚠ ĐỀ NÀY

⚠ MODEL TRAINING
    → huấn luyện trên dữ liệu đã sạch

⚠ MODEL EVALUATION
    → đo chỉ số

⚠ MODEL DEPLOYMENT
    → đưa ra phục vụ

⚠ MONITORING
    → theo dõi drift

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

"Data Ingestion"
    → ⚠ đã XONG: đề nói dữ liệu
      thô ĐÃ thu thập được

"Model Training"
    → ⚠ diễn ra SAU khi dữ liệu
      đã sẵn sàng

"Model Deployment"
    → ⚠ tận cuối

Đối chiếu #13555 (lô 144) — đề đó khoá Transform trong chuỗi giá trị dữ liệu. Cùng bản chất công việc, chỉ khác khung thuật ngữ: chuỗi giá trị dữ liệu gọi là Transform, vòng đời ML gọi là Data Preparation. Không mâu thuẫn.

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

• D (Data Ingestion) — phương án gần nhất vì hai giai đoạn nằm sát nhau, nhưng nạp dữ liệu đã hoàn tất: đề nói công ty đã thu thập được dữ liệu thô.

• A và B — diễn ra sau.

Ghi nhớ

⚠ Hai khung thuật ngữ song song — bảng phải thuộc: | Chuỗi giá trị dữ liệu | Vòng đời ML | |---|---| | Generate | — | | Ingest | ⚠ Data Ingestion | | Store | — | | ⚠ Transform | ⚠ Data Preparation | | Analyze | ⚠ Training + Evaluation | | Activate | ⚠ Deployment + Monitoring |

Từ khoá nhận diện:

"làm sạch, xử lý thiếu, chuyển đổi" → ⚠ Data Preparation / Transform "đưa dữ liệu vào hệ thống" → Ingestion "đưa mô hình ra phục vụ" → Deployment "theo dõi chất lượng sau triển khai" → ⚠ Monitoring

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Giá trị thiếu xử lý thế nào | ⚠ và cách đó có hợp lý về nghiệp vụ không | | Có cột nào lộ đáp án không | ⚠ data leakage | | Bước chuẩn bị có lặp lại được không | ⚠ phải là mã, không phải thao tác tay |

Và nguyên tắc đáng giữ ở khâu này: mọi bước làm sạch phải nằm trong mã chạy lại được, không phải trong một chuỗi thao tác thủ công. Nếu không, đến lúc cần huấn luyện lại vài tháng sau, sẽ không ai dựng lại được đúng tập dữ liệu đã dùng.

Đáp án

B — Models (tầng mô hình).

Vì sao đúng

Mô hình ngôn ngữ huấn luyện sẵn mà startup này thuê từ nhà cung cấp đám mây nằm đúng ở tầng Models trong bốn tầng của bối cảnh AI sinh.

⚠ Ánh xạ toàn bộ tình huống vào bốn tầng:

⚠ INFRASTRUCTURE
    → TPU/GPU chạy mô hình
    → ⚠ startup KHÔNG đụng tới

⚠ MODELS
    → ⚠ mô hình ngôn ngữ huấn
      luyện sẵn họ THUÊ
    → ⚠ ĐÁP ÁN

⚠ PLATFORMS
    → ⚠ Vertex AI / API để gọi
      và quản mô hình

⚠ APPLICATIONS
    → ⚠ ứng dụng di động lập
      lịch trình du lịch

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

"Thứ này LÀ GÌ?"
        ↓
    Chip, máy chủ → HẠ TẦNG
    ⚠ Bản thân mô hình → MÔ HÌNH
    Công cụ để xây → NỀN TẢNG
    Thứ người dùng bấm → ỨNG DỤNG

⚠ Đối chiếu #13878 (cùng lô) — đề đó cũng mô tả một ứng dụng di động và khoá Application. Đề này hỏi riêng về mô hình ngôn ngữ được thuê, nên khoá Models. KHÔNG mâu thuẫn — hai đề hỏi hai tầng khác nhau trong cùng một khung, hãy đọ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 (Applications) — phương án gần nhất và là bẫy chính: tình huống có một ứng dụng di động. Nhưng câu hỏi hỏi riêng về mô hình ngôn ngữ huấn luyện sẵn.

• A (Platforms) — công cụ để xây, không phải bản thân mô hình.

• D (Infrastructure) — phần cứng bên dưới.

Ghi nhớ

⚠ Bốn tầng — bảng phải thuộc: | Tầng | Là gì | Ví dụ | |---|---|---| | Infrastructure | ⚠ phần cứng, trung tâm dữ liệu | ⚠ TPU, GPU | | ⚠ Models | ⚠ bản thân mô hình nền | ⚠ Gemini, Imagen, Gemma | | ⚠ Platforms | ⚠ công cụ xây và vận hành | ⚠ Vertex AI, Agent Builder | | ⚠ Applications | ⚠ thứ người dùng cuối dùng | ⚠ app di động, Gemini app |

Từ khoá nhận diện:

"mô hình huấn luyện sẵn được thuê" → ⚠ Models "công cụ để xây và triển khai" → Platforms "người dùng cuối tương tác" → Applications "chip, máy chủ" → Infrastructure

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Dữ liệu chuyến bay lấy từ đâu | ⚠ phải từ API thật, không để mô hình đoán | | Chi phí mỗi lịch trình là bao nhiêu | ⚠ so với doanh thu mỗi người dùng | | Điều gì khiến app này khác app khác | ⚠ mô hình thì ai cũng thuê được |

Và câu hỏi chiến lược cho mọi startup xây trên mô hình thuê: nếu đối thủ cũng gọi đúng mô hình đó thì điều gì còn lại là của bạn? Câu trả lời thường nằm ở dữ liệu riêng, ở tích hợp với hệ thống thật, và ở việc hiểu người dùng — chứ không nằm ở lời gọi API.

Đáp án

C — Bằng cách cho phép LLM truy cập và đưa thông tin từ kho tri thức riêng của công ty vào trước khi sinh câu trả lời.

Vì sao đúng

Đó chính xác là cơ chế của RAG (Retrieval-Augmented Generation): TÌM đoạn liên quan trong kho tri thức, rồi ĐƯA VÀO prompt để mô hình trả lời dựa trên đó.

⚠ RAG hoạt động ra sao:

Khách hỏi về thông số sản phẩm mới
        ↓
    ⚠ RETRIEVAL — TÌM
    → chuyển câu hỏi thành vector
    → ⚠ tìm đoạn liên quan trong
      kho tri thức
        ↓
    ⚠ AUGMENTATION — BỔ SUNG
    → ⚠ ghép đoạn tìm được VÀO prompt
        ↓
    ⚠ GENERATION — SINH
    → mô hình trả lời DỰA TRÊN
      đoạn được cung cấp
    → ⚠ kèm TRÍCH DẪN

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

"Bộ lọc nội dung chặt hơn"
    → ⚠ chặn nội dung ngoài chủ đề,
      KHÔNG bổ sung kiến thức

"TĂNG temperature cho sáng tạo hơn"
    → ⚠ NGƯỢC HẲN: làm mô hình
      dễ BỊA hơn

"Fine-tune trên tập dữ liệu CHUNG
 lớn hơn"
    → ⚠ vẫn không có thông tin
      RIÊNG của công ty
    → ⚠ và sản phẩm cập nhật liên tục
      thì huấn luyện lại không kịp

Nhất quán với #13859 (cùng lô) — đề đó về grounding bằng dữ liệu first-party. Cùng cơ chế, cùng hướng giải quyết. Và #13874 (cùng lô) về knowledge cutoff — RAG cũng là cách chữa.

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

• D (fine-tune trên tập chung lớn hơn) — phương án gần nhất vì fine-tuning cũng là cách dạy mô hình, nhưng tập chung không chứa thông tin riêng của công ty, và với dữ liệu cập nhật liên tục thì huấn luyện lại là cách sai.

• A và B — không bổ sung kiến thức, B còn làm tình hình tệ hơn.

Ghi nhớ

⚠ RAG và fine-tuning — bảng phải thuộc: | | ⚠ RAG / Grounding | ⚠ Fine-tuning | |---|---|---| | Giải quyết | ⚠ thiếu KIẾN THỨC | ⚠ thiếu PHONG CÁCH, định dạng | | Cập nhật | ⚠ sửa tài liệu là xong | ⚠ phải huấn luyện lại | | ⚠ Trích dẫn nguồn | ⚠ CÓ | ⚠ KHÔNG | | Chi phí | ⚠ thấp hơn nhiều | cao | | Quyền truy cập | ⚠ lọc theo người dùng được | không | | Khi nào dùng | ⚠ dữ liệu thay đổi thường xuyên | ⚠ giọng văn, định dạng cố định |

Từ khoá nhận diện:

"trả lời sai về sản phẩm/chính sách riêng" → ⚠ RAG "không biết sự kiện gần đây" → ⚠ RAG / grounding "giọng văn chưa đúng thương hiệu" → fine-tuning "bịa ra thông tin" → ⚠ RAG + trích dẫn + HITL

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

Và điều quyết định thành bại của một hệ thống RAG hiếm khi là mô hình hay thuật toán tìm kiếm: nó là việc có ai chịu trách nhiệm giữ cho kho tri thức luôn đúng và luôn mới hay không. Đó là công việc vận hành liên tục, và cũng là phần dễ bị bỏ quên nhất sau ngày ra mắt.

Đáp án

D — Thiên vị trong dữ liệu huấn luyện dẫn tới một mô hình AI không công bằng.

Vì sao đúng

Đề nêu thẳng nguyên nhân: dữ liệu huấn luyện là lịch sử tuyển dụng của một ngành vốn có tình trạng thiếu đại diện của chính những nhóm bị mô hình đánh giá thấp.

⚠ Cơ chế của vấn đề:

Lịch sử tuyển dụng phản ánh
BẤT BÌNH ĐẲNG trong quá khứ
        ↓
    ⚠ Mô hình học từ dữ liệu đó
        ↓
    ⚠ Nó học rằng "người được tuyển
      trước đây trông như thế này"
        ↓
    ⚠ Rồi LẶP LẠI và KHUẾCH ĐẠI
      mẫu hình cũ
        ↓
    → ⚠ ứng viên tương đương về
      năng lực nhưng khác nhóm
      bị đánh giá thấp hơn

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

"Thiếu biện pháp accountability"
    → ⚠ đúng là vấn đề quản trị,
      nhưng KHÔNG phải NGUYÊN NHÂN
      của kết quả lệch

"Thiếu tính minh bạch"
    → ⚠ khiến khó PHÁT HIỆN sớm,
      nhưng không GÂY RA thiên vị

"Khả năng truy cập dữ liệu kém"
    → ⚠ hoàn toàn không liên quan

Đối chiếu #13879 và #13884 (cùng lô) — hai đề đó về explainability và transparency. Đề này về bias/fairness. Cùng họ nguyên tắc AI có trách nhiệm nhưng khác vấn đề. Không mâu thuẫn.

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

• B (thiếu minh bạch) — phương án gần nhất vì minh bạch giúp phát hiện vấn đề này. Nhưng câu hỏi hỏi nguyên nhân gây ra kết quả lệch, và nguyên nhân nằm ở dữ liệu.

• A và C — không phải nguyên nhân.

Ghi nhớ

⚠ Các nguồn thiên vị — bảng phải thuộc: | Nguồn | Nội dung | |---|---| | ⚠ Historical bias | ⚠ dữ liệu phản ánh bất bình đẳng CŨ — đề này | | ⚠ Representation bias | ⚠ nhóm nào đó có quá ít dữ liệu | | Measurement bias | ⚠ cách đo khác nhau giữa các nhóm | | ⚠ Proxy bias | ⚠ biến thay thế: mã bưu chính, tên trường | | Deployment bias | ⚠ dùng mô hình sai bối cảnh |

Từ khoá nhận diện:

"kết quả lệch giữa các nhóm" → ⚠ bias / fairness "không giải thích được quyết định" → explainability "ai chịu trách nhiệm" → accountability "công khai cách hoạt động" → transparency

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đã đo kết quả theo từng nhóm chưa | ⚠ tổng thể che giấu chênh lệch | | Dữ liệu huấn luyện đến từ đâu | ⚠ lịch sử có phản ánh bất bình đẳng không | | Ai kiểm toán độc lập | ⚠ đội tự kiểm thường bỏ sót |

Và bài học chung nhất từ những trường hợp như thế này: một mô hình học từ lịch sử sẽ tái tạo lịch sử. Nếu quá khứ mà nó học có điều gì đó cần thay đổi, thì việc tự động hoá quá khứ ấy sẽ khiến nó lặp lại nhanh hơn và ở quy mô lớn hơn.

Đáp án

D — Dùng năng lực RAG dựng sẵn trong Vertex AI Search.

Vì sao đúng

Đề nêu ba yêu cầu: dựng NHANH, grounding vào tài liệu nội bộ, tối thiểu thiết lập phức tạp và tận dụng năng lực tìm kiếm của Google. Vertex AI Search đóng gói sẵn cả chuỗi RAG.

⚠ Vertex AI Search làm sẵn những gì:

Tự làm RAG thủ công phải lo:
    ⚠ chia đoạn tài liệu
    ⚠ sinh embedding
    ⚠ dựng và vận hành vector DB
    ⚠ logic tìm kiếm và xếp hạng
    ⚠ ghép prompt
    ⚠ trích dẫn nguồn
        ↓
⚠ VERTEX AI SEARCH
    → ⚠ trỏ vào nguồn tài liệu
    → ⚠ TẤT CẢ ở trên đã có sẵn
    → ⚠ dựng trong ngày thay vì
      vài tuần

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

"Triển khai LLM chung qua Endpoint
 rồi tự lo phần truy xuất"
    → ⚠ đúng thứ đề nói là muốn TRÁNH

"Tự làm RAG bằng Cloud Storage và
 vector DB tuỳ biến"
    → ⚠ linh hoạt nhất, nhưng
      PHỨC TẠP nhất

"HUẤN LUYỆN mô hình nền TỪ ĐẦU"
    → ⚠ cực kỳ tốn kém, và hoàn
      toàn KHÔNG giải quyết bài toán
      tài liệu HR cập nhật

Nhất quán với #13863 (cùng lô) về Vertex AI Search, và #13900 (cùng lô) về cơ chế RAG. Đề này là cách hiện thực RAG nhanh nhất.

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

• B (tự làm RAG với Cloud Storage và vector DB) — phương án gần nhất và hoàn toàn khả thi về kỹ thuật, cho nhiều quyền kiểm soát hơn. Nhưng đề nói rõ muốn tối thiểu thiết lập phức tạp và dựng nhanh.

• A — cũng phải tự lo phần truy xuất.

• C — huấn luyện mô hình nền từ đầu là lựa chọn sai ở mọi khía cạnh.

Ghi nhớ

⚠ Ba mức làm RAG — bảng phải thuộc: | Mức | Công sức | Kiểm soát | |---|---|---| | ⚠ Vertex AI Search / Agent Builder | ⚠ thấp nhất — đề này | vừa đủ | | Vertex AI + vector search có quản lý | trung bình | cao hơn | | ⚠ Tự dựng toàn bộ | ⚠ cao nhất | ⚠ cao nhất | | Nguyên tắc | ⚠ bắt đầu từ mức thấp nhất đáp ứng được |

Từ khoá nhận diện:

"RAG nhanh, ít thiết lập" → ⚠ Vertex AI Search "agent có công cụ và grounding" → Agent Builder "cần kiểm soát từng bước RAG" → ⚠ tự dựng "nghiên cứu trên tài liệu tự nạp" → NotebookLM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai giữ tài liệu cập nhật | ⚠ phải có người chịu trách nhiệm | | Bot có lọc theo quyền không | ⚠ thử bằng tài khoản nhân viên thường | | Câu hỏi nhạy cảm xử lý ra sao | ⚠ phải chuyển sang người |

Và với một chatbot chính sách nội bộ, phần khó nhất không nằm ở việc dựng nó mà ở việc giữ cho kho tài liệu luôn phản ánh đúng chính sách hiện hành. Một bot trả lời tự tin dựa trên quy định đã hết hiệu lực gây rắc rối nhiều hơn là không có bot nào.

Đáp án

D — Model Deployment (triển khai mô hình).

Vì sao đúng

Mô hình đã huấn luyện xong; việc còn lại là đưa nó ra phục vụ qua API để ứng dụng khác gọi được. Đó chính là giai đoạn triển khai.

⚠ Vị trí trong vòng đời ML:

Data Ingestion
        ↓
Data Preparation
        ↓
Model Training — ⚠ ĐÃ XONG
        ↓
Model Evaluation
        ↓
⚠ MODEL DEPLOYMENT
    → ⚠ đưa lên endpoint
    → ⚠ có API để gọi
    → ⚠ ĐỀ NÀY
        ↓
Monitoring

⚠ Triển khai gồm những việc gì:

⚠ Đưa mô hình vào Model Registry
⚠ Tạo endpoint và chọn cỡ máy
⚠ Cấu hình tự co giãn
⚠ Đặt IAM: ai gọi được
⚠ Kiểm thử độ trễ và thông lượng
⚠ Bật giám sát và log

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

"Model Training" → ⚠ đã hoàn tất
"Data Preparation" → ⚠ ở đầu chuỗi
"Data Ingestion"   → ⚠ ở đầu chuỗi

Nhất quán với #13898 (cùng lô) — đề đó hỏi giai đoạn Data Preparation. Hai đề cùng khung vòng đời ML, hỏi hai giai đoạn khác nhau. Hoàn toàn nhất quán.

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

• B (Model Training) — phương án gần nhất vì đó là giai đoạn ngay trước, nhưng đề nói rõ đội đã huấn luyện thành công.

• A và C — nằm ở đầu vòng đời.

Ghi nhớ

⚠ Vòng đời ML — bảng phải thuộc: | Giai đoạn | Việc chính | |---|---| | 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ố trên tập test | | ⚠ Model Deployment | ⚠ đưa ra phục vụ — đề này | | ⚠ Monitoring | ⚠ theo dõi drift, hiệu năng |

Từ khoá nhận diện:

"đưa mô hình ra dùng qua API" → ⚠ deployment "làm sạch, xử lý thiếu" → data preparation "đo chỉ số trên tập test" → ⚠ evaluation "chất lượng giảm dần" → monitoring / drift

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có quay lui được không | ⚠ cần Model Registry và quy trình rollback | | Đặc trưng có tính giống lúc huấn luyện không | ⚠ nguồn lỗi số một | | Endpoint nào đang sống mà không dùng | ⚠ rà hằng tháng |

Và khoảng cách khiến nhiều dự án học máy dừng lại trước vạch đích: giữa một mô hình chạy tốt trong notebook và một endpoint phục vụ ổn định cho các hệ thống khác. Phần lớn công việc kỹ thuật thực sự nằm ở khoảng cách đó, chứ không nằm ở việc huấn luyện.

Đáp án

B — Reinforcement Learning (học tăng cường).

Vì sao đúng

AI hành động (đi nước cờ), nhận tín hiệu thưởng hoặc phạt (thắng hay thua), và học chiến lược tối đa hoá phần thưởng theo thời gian. Đó là định nghĩa của học tăng cường.

⚠ Ba yếu tố của học tăng cường:

⚠ AGENT — tác nhân
    → AI chơi cờ

⚠ ENVIRONMENT — môi trường
    → bàn cờ và luật chơi

⚠ ACTION — hành động
    → nước đi

⚠ REWARD — phần thưởng
    → ⚠ thắng = dương, thua = âm

⚠ POLICY — chiến lược
    → ⚠ thứ AI học được:
      ở trạng thái này nên đi gì

⚠ Vì sao KHÔNG phải học có giám sát:

Học có giám sát
    → ⚠ mỗi mẫu có ĐÁP ÁN ĐÚNG
      cho sẵn
    → "ở thế cờ này, nước đúng là X"

⚠ Học tăng cường
    → ⚠ KHÔNG ai nói nước nào đúng
    → ⚠ chỉ biết KẾT QUẢ CUỐI ván
    → ⚠ AI phải TỰ suy ra nước nào
      đã góp phần vào thắng lợi

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

"Supervised Learning"
    → ⚠ cần nhãn đúng cho từng nước

"Unsupervised Learning"
    → ⚠ tìm mẫu hình trong dữ liệu
      không nhãn, không có phần thưởng

"Multimodal Learning"
    → ⚠ về nhiều LOẠI DỮ LIỆU
      (ảnh, chữ, âm thanh), không
      phải cách học

Bộ ba với #13887 (không giám sát) và #13889 (có nhãn) trong cùng lô. Ba đề phủ đủ ba nhóm phương pháp học, hoàn toàn nhất quán.

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

• A (học có giám sát) — phương án gần nhất vì cũng có "tín hiệu" từ bên ngoài. Nhưng tín hiệu ở đây là phần thưởng sau cả ván, không phải nhãn đúng cho từng nước đi.

• D (không giám sát) — không có cơ chế thưởng.

• C (multimodal) — không phải một nhóm phương pháp học.

Ghi nhớ

⚠ Ba nhóm phương pháp học — bảng phải thuộc: | Nhóm | Tín hiệu học | Bài toán | |---|---|---| | Có giám sát | ⚠ NHÃN đúng cho từng mẫu | phân loại, hồi quy | | Không giám sát | ⚠ KHÔNG có tín hiệu | phân cụm, giảm chiều | | ⚠ Tăng cường | ⚠ THƯỞNG/PHẠT sau hành động | ⚠ game, robot, tối ưu |

Từ khoá nhận diện:

"thử và sai, phần thưởng, chiến lược" → ⚠ học tăng cường "đã gán nhãn sẵn" → có giám sát "không nhãn, tự tìm nhóm" → không giám sát "nhiều loại dữ liệu cùng lúc" → ⚠ multimodal — không phải cách học

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có nhãn đúng cho từng bước không | có → có giám sát | | Có tín hiệu thưởng sau hành động không | có → ⚠ tăng cường | | Thử sai có an toàn không | ⚠ không → phải mô phỏng |

Và cạm bẫy nổi tiếng nhất của học tăng cường là reward hacking: hệ thống tìm ra cách đạt điểm cao mà không hề làm điều bạn thật sự mong muốn. Nó là lời nhắc rằng thứ khó nhất trong bài toán này không phải thuật toán, mà là định nghĩa cho đúng thế nào là thành công.

Đáp án

A — Chain-of-Thought (CoT) prompting.

Vì sao đúng

Dấu hiệu quyết định: ví dụ trong prompt cho thấy quá trình suy nghĩ, chia bài toán thành các bước lập luận trung gian trước khi ra đáp án cuối.

⚠ Vì sao CoT hiệu quả với bài toán nhiều bước:

Prompt thường
    → ⚠ mô hình nhảy thẳng tới
      đáp án
    → ⚠ với bài nhiều bước thì
      dễ sai

⚠ CHAIN-OF-THOUGHT
    → ⚠ mô hình được yêu cầu
      TRÌNH BÀY từng bước
        ↓
    ⚠ "Bước 1: có 5 hộp
       Bước 2: mỗi hộp 12 quả
       Bước 3: 5 × 12 = 60
       Bước 4: bán đi 15, còn 45"
        ↓
    ⚠ Mỗi bước ĐƠN GIẢN hơn
    ⚠ Sai ở đâu thì thấy được

⚠ Phân biệt CoT với few-shot:

FEW-SHOT thuần
    → ví dụ chỉ có: ĐỀ → ĐÁP ÁN

⚠ CHAIN-OF-THOUGHT
    → ⚠ ví dụ có: ĐỀ → CÁC BƯỚC
      → ĐÁP ÁN
    → ⚠ chính phần BƯỚC TRUNG GIAN
      là điểm khác biệt

⚠ Đối chiếu #13867 (lô 145) — đề đó khoá few-shot vì ví dụ chỉ ghi "Review → Sentiment", không có bước suy luận. Đề này có quá trình suy nghĩa tường minh nên là CoT. Không mâu thuẫn — dấu hiệu phân biệt nằm ở chỗ ví dụ có trình bày lập luận hay không.

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

• C (few-shot) — phương án gần nhất và là bẫy chính: prompt này cũng có ví dụ. Nhưng điều làm nên kỹ thuật ở đây là ví dụ trình bày các bước lập luận.

• D (ReAct) — kết hợp lập luận với hành động gọi công cụ; ở đây không có công cụ nào.

• B (role prompting) — không gán vai nào.

Ghi nhớ

⚠ Kỹ thuật prompt nâng cao — bảng phải thuộc: | Kỹ thuật | Dấu hiệu nhận biết | |---|---| | Zero-shot | ⚠ không ví dụ | | Few-shot | ⚠ ví dụ: đề → đáp án | | ⚠ Chain-of-Thought | ⚠ ví dụ CÓ BƯỚC SUY LUẬN — đề này | | ⚠ ReAct | ⚠ lập luận + GỌI CÔNG CỤ xen kẽ | | Self-consistency | ⚠ chạy nhiều lần rồi lấy đáp án phổ biến nhất | | Role prompting | gán vai |

Từ khoá nhận diện:

"trình bày từng bước suy luận" → ⚠ Chain-of-Thought "ví dụ chỉ có đáp án" → few-shot "vừa suy luận vừa gọi công cụ" → ⚠ ReAct "chạy nhiều lần rồi bỏ phiếu" → self-consistency

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CoT có thật sự cải thiện không | ⚠ đo trên bộ test có đáp án | | Chi phí tăng bao nhiêu | ⚠ đầu ra dài hơn nhiều lần | | Bước lập luận có đúng không | ⚠ đọc vài mẫu, đừng chỉ nhìn đáp án cuối |

Và cách xử lý đúng nhất cho bài toán tính toán trong ứng dụng thật: để mô hình lập luận và diễn giải, nhưng để một công cụ tính toán thực hiện phép tính. Mô hình ngôn ngữ giỏi việc hiểu đề bài, còn số học chính xác thì nên giao cho thứ được thiết kế cho việc đó.