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

Đáp án

A — Dùng công cụ dựng agent tuỳ biến được để thiết kế một trợ lý chuyên biệt, tích hợp với hệ thống của công ty.

Vì sao đúng

Đội đã thử mô hình Gemini đa dụng và thấy thiếu kiểm soát luồng công việc và khả năng tích hợp hệ thống. Ba nhu cầu — lấy dữ liệu từ nhiều hệ thống nội bộ, áp luật nghiệp vụ, giữ giọng thương hiệu nhất quán — đòi một công cụ dựng agent.

⚠ Ba nhu cầu, ba năng lực của agent:

"lấy dữ liệu từ NHIỀU hệ thống
 nội bộ"
    → ⚠ tools / extensions

"áp LUẬT NGHIỆP VỤ"
    → ⚠ kiểm soát luồng công việc

"giọng thương hiệu NHẤT QUÁN"
    → ⚠ chỉ dẫn hệ thống cố định
        ↓
    ⚠ Mô hình thuần KHÔNG có sẵn
      ba thứ này

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

"Dùng mô hình Gemini đa dụng"
    → ⚠ ĐÚNG THỨ đã thử và THẤT BẠI

"Bật multimodal search"
    → ⚠ tìm kiếm đa phương thức;
      không giải quyết tích hợp
      hệ thống và luật nghiệp vụ

"Fine-tune mô hình trên thuật ngữ
 logistics qua Model Garden"
    → ⚠ giúp THUẬT NGỮ, ⚠ KHÔNG
      giúp tích hợp hệ thống hay
      kiểm soát luồng

⚠ Gần trùng với #13952 (lô 146) — đề đó là agent du lịch cần gọi API và có môi trường phát triển, cùng khoá Agent Builder. Hoàn toàn nhất quán. Và #13858 (lô 145).

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

• D (fine-tune trên thuật ngữ) — phương án gần nhất và là bẫy chính: nó giải quyết được một phần (giọng và thuật ngữ). Nhưng nó không cho agent lấy dữ liệu từ hệ thống nội bộ hay áp luật nghiệp vụ.

• B — chính là cách đã thất bại.

• C — không đúng nhu cầu.

Ghi nhớ

⚠ Mô hình thuần và agent — bảng phải thuộc: | | ⚠ Mô hình thuần | ⚠ Agent | |---|---|---| | Sinh văn bản | ✅ | ✅ | | ⚠ Gọi hệ thống ngoài | ❌ | ⚠ CÓ — tools | | ⚠ Kiểm soát luồng | ❌ | ⚠ CÓ | | Nhiều bước, tự quyết | ❌ | ⚠ CÓ | | Grounding có sẵn | ❌ | ⚠ CÓ | | Chỉ dẫn nhất quán | ⚠ qua prompt | ⚠ cấu hình sẵn |

Từ khoá nhận diện:

"tích hợp hệ thống, luật nghiệp vụ, luồng" → ⚠ Agent Builder "chỉ sinh văn bản" → mô hình thuần "thuật ngữ, giọng văn" → fine-tuning "tìm bằng ảnh và chữ" → multimodal search

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có cần lấy dữ liệu từ hệ thống không | ⚠ có → cần agent có tool | | Có nhiều bước với ràng buộc thứ tự không | ⚠ có → cần kiểm soát luồng | | Một lời gọi có giải quyết được không | ⚠ được → đừng dựng agent |

Và dấu hiệu rõ nhất cho thấy một bài toán đã vượt quá khả năng của mô hình thuần: câu trả lời đúng đòi hỏi dữ liệu mà mô hình không có cách nào biết. Khi đó vấn đề không phải là prompt chưa đủ tốt, mà là hệ thống thiếu công cụ để đi lấy thông tin.

Đáp án

B — Safety settings (cài đặt an toàn).

Vì sao đúng

Ưu tiên cao nhất là ngăn mô hình sinh nội dung có hại, phản cảm hoặc không phù hợp, chấp nhận đánh đổi bằng việc câu trả lời đôi khi kém sáng tạo hơn. Đó chính là cấu hình an toàn.

⚠ Đề đã nêu rõ đánh đổi:

"ưu tiên CAO NHẤT là ngăn nội
 dung có hại"
    → ⚠ an toàn là ràng buộc CỨNG

"kể cả khi câu trả lời đôi khi
 KÉM SÁNG TẠO hơn"
    → ⚠ chấp nhận đánh đổi
        ↓
    ⚠ Đây là quyết định đặt NGƯỠNG
      lọc CHẶT

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

"Temperature"
    → ⚠ điều chỉnh ĐỘ SÁNG TẠO;
      ⚠ hạ temperature làm nội dung
      an toàn hơn về PHONG CÁCH nhưng
      KHÔNG chặn nội dung có hại

"Top-k"
    → ⚠ cũng là tham số lấy mẫu

"Output length"
    → ⚠ kiểm soát độ dài

⚠ Gần trùng với #13972 (lô 147) — đề đó cũng là chatbot công khai cần chặn nội dung có hại, cùng khoá safety settings. Hoàn toàn nhất quán. Đối chiếu #14035 (cùng lô) khoá max output length cho vấn đề độ dài.

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

• A (temperature) — phương án gần nhất và là bẫy chính: đề có nhắc tới sáng tạo, và hạ temperature làm đầu ra dự đoán được hơn. Nhưng nó không chặn nội dung có hại; một mô hình ở nhiệt độ thấp vẫn có thể sinh ra thứ không phù hợp.

• C và D — kiểm soát khía cạnh khác.

Ghi nhớ

⚠ Ba nhóm tham số — bảng phải thuộc: | Nhóm | Tham số | Kiểm soát | |---|---|---| | ⚠ AN TOÀN | ⚠ safety settings | ⚠ nội dung CÓ HẠI — đề này | | Phong cách | ⚠ temperature, top-p, top-k | ⚠ độ sáng tạo | | Kích thước | ⚠ max output tokens | ⚠ độ dài |

Từ khoá nhận diện:

"chặn nội dung có hại, phản cảm" → ⚠ safety settings "sáng tạo hay xác định" → temperature "vượt giới hạn ký tự" → max output length "lừa mô hình bỏ qua chỉ dẫn" → ⚠ prompt injection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã red team chưa | ⚠ bắt buộc trước khi mở công khai | | Bot có chặn nhầm câu hỏi bình thường không | ⚠ thử với câu hỏi thật của khách | | Tắt bot khẩn cấp bằng cách nào | ⚠ phải có và phải thử trước |

Và điều đáng chuẩn bị song song với bộ lọc trước khi mở một chatbot ra công chúng: cách tắt nó thật nhanh. Người dùng sẽ tìm cách phá, và điều quyết định mức thiệt hại không phải bộ lọc hoàn hảo tới đâu mà là tổ chức phản ứng nhanh tới mức nào.

Đáp án

C — Khả năng thu được hiểu biết PHONG PHÚ hơn, đa phương thức — như giọng điệu và cảm xúc — nhưng đi kèm CHI PHÍ CAO HƠN.

Vì sao đúng

Video mang nhiều tầng thông tin hơn văn bản: nét mặt, giọng điệu, ngập ngừng, ngôn ngữ cơ thể. Nhưng nó cũng tốn kém hơn ở mọi khâu.

⚠ Video cho thêm gì so với văn bản:

⚠ NÉT MẶT và ngôn ngữ cơ thể
⚠ GIỌNG ĐIỆU, ngập ngừng
⚠ Cảm xúc thật đằng sau câu trả lời
⚠ Phản ứng tự nhiên chưa qua
  chỉnh sửa
        ↓
    ⚠ Người trả lời khảo sát chữ
      có thể viết cho "đẹp"
    ⚠ Video khó che giấu hơn

⚠ Nhưng cái giá:

⚠ Chi phí THU THẬP cao hơn nhiều
    → phỏng vấn tốn thời gian
⚠ Chi phí LƯU TRỮ lớn hơn
⚠ Chi phí XỬ LÝ AI cao hơn
    → tính theo phút video
⚠ ⚠ Quyền riêng tư PHỨC TẠP hơn
    → khuôn mặt, giọng nói là
      dữ liệu sinh trắc học
⚠ Khó ẩn danh hoá

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

"Ẩn danh hoá và tuân thủ ĐƠN GIẢN HƠN"
    → ⚠ NGƯỢC HẲN: video KHÓ ẩn
      danh hơn nhiều

"Huấn luyện NHANH HƠN nhờ mật độ
 thông tin"
    → ⚠ NGƯỢC: video nặng hơn,
      xử lý CHẬM hơn

"Chi phí lưu trữ và xử lý THẤP
 HƠN đáng kể"
    → ⚠ NGƯỢC hoàn toàn

Nhất quán với #14014 và #14032 (cùng lô) về phân tích video — đều nhắc chi phí theo phút. Bổ sung nhau.

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

• A (ẩn danh hoá đơn giản hơn) — phương án gần nhất và là bẫy nguy hiểm nhất: nó nói ngược với thực tế. Khuôn mặt và giọng nói là dữ liệu sinh trắc học, khó che và bị quản lý chặt hơn văn bản.

• B và D — cũng đảo ngược thực tế.

Ghi nhớ

⚠ Văn bản và video cho nghiên cứu thị trường — bảng nên thuộc: | | Khảo sát văn bản | ⚠ Phỏng vấn video | |---|---|---| | Chiều sâu | ⚠ hạn chế | ⚠ giọng, cảm xúc, cơ thể | | Chi phí thu thập | ⚠ thấp | ⚠ cao | | Quy mô mẫu | ⚠ lớn dễ dàng | ⚠ khó mở rộng | | ⚠ Quyền riêng tư | ⚠ dễ ẩn danh | ⚠ RẤT khó — sinh trắc học | | Xử lý AI | ⚠ rẻ, nhanh | ⚠ đắt, chậm | | Lưu trữ | ⚠ nhỏ | ⚠ lớn |

Từ khoá nhận diện:

"giọng điệu, cảm xúc, chi phí cao" → ⚠ đánh đổi của video "ẩn danh hoá dễ" → ⚠ văn bản, KHÔNG phải video "nhãn theo mốc thời gian" → Video Intelligence "kết hợp nhiều loại dữ liệu" → multimodal

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có đồng ý rõ ràng của người tham gia không | ⚠ bắt buộc với video | | Chi phí cho toàn bộ mẫu là bao nhiêu | ⚠ số phút × đơn giá | | Kết luận về cảm xúc có được kiểm chứng không | ⚠ đừng tin máy tuyệt đối |

Và điều cần cân nhắc nghiêm túc trước khi chọn video cho nghiên cứu thị trường: nó biến một cuộc khảo sát thành một hoạt động xử lý dữ liệu sinh trắc học. Khuôn mặt và giọng nói của người tham gia chịu những quy định chặt hơn hẳn một bảng trả lời bằng chữ.

Đáp án

A — Google Cloud Contact Center as a Service (CCaaS).

Vì sao đúng

Công ty bảo hiểm muốn thay TOÀN BỘ hạ tầng tổng đài cũ bằng một nền tảng đám mây đầu-cuối gồm tổng đài điện thoại, IVR, bot ảo và công cụ hỗ trợ nhân viên trong một gói có khả năng mở rộng. Đó là CCaaS.

⚠ Bốn thành phần đề liệt kê:

"TELEPHONY"
    → ⚠ hạ tầng điện thoại — chỉ
      nền tảng tổng đài mới có

"IVR"
    → ⚠ điều hướng cuộc gọi

"VIRTUAL AGENTS"
    → bot ảo

"AGENT ASSISTANCE"
    → hỗ trợ nhân viên
        ↓
    ⚠ Bốn thứ trong MỘT nền tảng
    → ⚠ CCaaS

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

"Vertex AI Agent Builder"
    → ⚠ dựng AGENT; ⚠ KHÔNG có
      telephony, IVR, quản ca trực

"Tập hợp các API AI riêng lẻ"
    → ⚠ phải TỰ ghép; ⚠ ngược với
      "một gói toàn diện"

"Google Meet"
    → ⚠ họp trực tuyến, không phải
      tổng đài

⚠ Gần trùng với #13990 (lô 147) — đề đó cũng là hiện đại hoá tổng đài với nền tảng native cloud, cùng khoá CCaaS. Hoàn toàn nhất quán. Đối chiếu #14031/#13993 khoá CX Insights và #13971 khoá Agent Assist khi đề hỏi thành phần lẻ.

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

• C (tập hợp các API riêng lẻ) — phương án gần nhất và là bẫy chính: về kỹ thuật có thể ghép được. Nhưng đề nói rõ cần nền tảng toàn diện trong MỘT gói, và tự ghép thì thiếu telephony, quản ca trực, báo cáo.

• B và D — không phải nền tảng tổng đài.

Ghi nhớ

⚠ Ba cấp giải pháp tổng đài — bảng phải thuộc: | Cấp | Nội dung | |---|---| | ⚠ CCaaS | ⚠ NỀN TẢNG: telephony, IVR, định tuyến, báo cáo | | Customer Engagement Suite | ⚠ bộ năng lực AI trên nền đó | | ⚠ Thành phần | ⚠ Conversational Agents, Agent Assist, CX Insights | | Agent Builder | ⚠ công cụ dựng agent — khác mục đích |

Từ khoá nhận diện:

"telephony, IVR, nền tảng đầu-cuối" → ⚠ CCaaS "ba năng lực AI chăm sóc khách" → Customer Engagement Suite "hỗ trợ nhân viên thời gian thực" → Agent Assist "xây agent cho sản phẩm riêng" → Agent Builder

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Chịu được đỉnh tải thảm hoạ không | ⚠ thử tải mô phỏng | | Có phương án quay lui không | ⚠ chuyển đổi tổng đài rủi ro cao | | Nhân viên đã được đào tạo chưa | ⚠ trước khi chuyển, không phải sau |

Và rủi ro lớn nhất của một dự án thay thế toàn bộ hạ tầng tổng đài không nằm ở công nghệ: nó nằm ở việc chuyển đổi khi hệ thống cũ vẫn đang phục vụ khách hàng thật. Vì vậy chạy song song và chuyển dần từng nhóm gần như luôn là cách an toàn hơn một lần cắt chuyển.

Đáp án

D — Availability (khả năng tiếp cận dữ liệu) — vì việc truy cập dữ liệu đòi hỏi nhiều công sức và chi phí.

Vì sao đúng

Vấn đề cốt lõi mà đội IT nêu ra là truy cập dữ liệu đòi hỏi công sức tích hợp và ngân sách đáng kể. Dữ liệu tồn tại nhưng không dễ lấy ra dùng.

⚠ Phân biệt bốn chiều trong đề:

"nhiều hệ thống, ĐỊNH DẠNG khác nhau"
    → ⚠ có yếu tố CONSISTENCY

"hợp đồng chỉ có dưới dạng PDF QUÉT"
    → ⚠ có yếu tố khó xử lý

⚠ "truy cập đòi hỏi CÔNG SỨC TÍCH
   HỢP và NGÂN SÁCH đáng kể"
    → ⚠ đây là điểm đề NHẤN MẠNH
    → ⚠ AVAILABILITY / ACCESSIBILITY

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

"Consistency — định dạng khác nhau"
    → ⚠ CÓ tồn tại, nhưng đề nhấn
      vào CÔNG SỨC TRUY CẬP

"Completeness — thiếu thông tin
 nhà cung cấp"
    → ⚠ đề KHÔNG nói dữ liệu thiếu,
      chỉ nói khó lấy

"Relevance — không phải dữ liệu
 nào cũng liên quan tồn kho"
    → ⚠ đề không nêu vấn đề này

⚠ Đối chiếu #13967 (lô 147, completeness) — ở đó thiếu GIÁ TRỊ trong trường. #13939 (lô 146, relevance) — ở đó dữ liệu về chủ đề khác. Đề này là dữ liệu có nhưng KHÓ LẤY. Ba chiều khác nhau, không mâu thuẫn.

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

• B (consistency) — phương án gần nhất và là bẫy mạnh: đề thật sự nhắc tới định dạng khác nhau. Nhưng câu kết luận của đội IT là về công sức và chi phí TRUY CẬP, tức khả năng tiếp cận.

• C và A — không phải vấn đề đề nêu.

Ghi nhớ

⚠ Các chiều chất lượng dữ liệu — bảng phải thuộc: | Chiều | Câu hỏi | |---|---| | ⚠ Availability / Accessibility | ⚠ có LẤY RA ĐƯỢC không | | Completeness | ⚠ có THIẾU giá trị không | | Consistency | ⚠ các nguồn có MÂU THUẪN không | | Relevance | ⚠ có LIÊN QUAN bài toán không | | Accuracy | có đúng không | | Timeliness | có mới không |

Từ khoá nhận diện:

"khó truy cập, tốn công tích hợp" → ⚠ availability "trường trống, thiếu giá trị" → completeness "định dạng khác nhau, mâu thuẫn" → consistency "dữ liệu về chủ đề khác" → relevance

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Nguồn nào lấy được ngay | ⚠ bắt đầu từ đó | | Rào cản là kỹ thuật hay tổ chức | ⚠ cách giải khác nhau | | Có thể chứng minh giá trị với dữ liệu hiện có không | ⚠ để xin ngân sách tích hợp |

Và lý do phổ biến nhất khiến các dự án AI dừng lại trước khi bắt đầu: dữ liệu tồn tại nhưng không ai lấy ra được trong phạm vi ngân sách hiện có. Vì vậy câu hỏi "lấy dữ liệu này mất bao lâu và tốn bao nhiêu" nên được đặt ngay ở giai đoạn đánh giá ca sử dụng, chứ không phải sau khi đã cam kết.

Đáp án

D — Low latency (thời gian phản hồi nhanh).

Vì sao đúng

Ứng dụng dịch văn bản trên biển hiệu và thực đơn qua camera theo thời gian thực, và trải nghiệm mượt đòi hỏi bản dịch hiện ra gần như tức thì. Đó là yêu cầu về độ trễ thấp.

⚠ Vì sao độ trễ là ràng buộc quyết định:

Người dùng giơ điện thoại lên
biển hiệu
        ↓
    ⚠ Chờ 3 giây = trải nghiệm HỎNG
    ⚠ Camera đang di chuyển
    ⚠ Bản dịch phải bám theo
        ↓
    ⚠ Mô hình chính xác hơn 5%
      KHÔNG bù được độ trễ
        ↓
    → ⚠ độ trễ là ràng buộc CỨNG

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

"Khả năng viết luận dài"
    → ⚠ hoàn toàn không liên quan

"High throughput (nhiều yêu cầu
 cùng lúc)"
    → ⚠ quan trọng khi ĐÔNG người
      dùng, nhưng ⚠ trải nghiệm của
      MỘT người phụ thuộc ĐỘ TRỄ

"Ngày cutoff dữ liệu huấn luyện"
    → ⚠ dịch biển hiệu không cần
      thông tin mới

⚠ Đối chiếu #13931 và #14015 khoá cửa sổ ngữ cảnh cho tài liệu dài, #14006 (cùng lô) khoá SLA cho hệ thống sản xuất. Không mâu thuẫn — mỗi bài toán có một tiêu chí quyết định riêng.

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

• B (high throughput) — phương án gần nhất và là bẫy tinh tế: cả hai đều là chỉ số hiệu năng. Nhưng throughput đo hệ thống phục vụ được bao nhiêu người cùng lúc, còn trải nghiệm của một người dùng phụ thuộc vào độ trễ.

• A và C — không liên quan tới bài toán.

Ghi nhớ

⚠ Latency và throughput — bảng phải thuộc: | | ⚠ Latency | ⚠ Throughput | |---|---|---| | Đo gì | ⚠ MỘT yêu cầu mất bao lâu | ⚠ bao nhiêu yêu cầu/giây | | Ảnh hưởng | ⚠ trải nghiệm CÁ NHÂN | ⚠ năng lực hệ thống | | Quan trọng khi | ⚠ tương tác thời gian thực | ⚠ xử lý khối lượng lớn | | Cải thiện bằng | ⚠ mô hình nhỏ, cache, edge | ⚠ thêm máy, batch |

Từ khoá nhận diện:

"thời gian thực, hiện ra tức thì" → ⚠ low latency "nhiều người dùng cùng lúc" → throughput "tài liệu rất dài" → context window "dừng máy tốn tiền" → SLA, độ tin cậy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ p99 trên mạng thật là bao nhiêu | ⚠ không đo trên wifi văn phòng | | Mất mạng thì ứng dụng làm gì | ⚠ cân nhắc mô hình trên thiết bị | | Mô hình nhỏ có đủ chính xác không | ⚠ thử với biển hiệu thật |

Và với ứng dụng dịch qua camera dành cho khách du lịch, ràng buộc thực tế nhất có khi không phải độ trễ mà là kết nối. Người dùng cần nó nhất ở nơi họ vừa đặt chân tới và chưa có mạng — nên khả năng chạy trên thiết bị đáng cân nhắc ngay từ đầu.

Đáp án

A — Data Dependency (sự phụ thuộc vào dữ liệu).

Vì sao đúng

Mô hình được tinh chỉnh trên kho tri thức nội bộ về sản phẩm bán từ 2018 đến 2022. Khi hỏi về dòng sản phẩm mới ra năm nay, nó không có thông tin — vì chất lượng và phạm vi đầu ra hoàn toàn phụ thuộc vào dữ liệu đã được huấn luyện.

⚠ Vì sao là data dependency:

Mô hình tinh chỉnh trên dữ liệu
2018–2022
        ↓
    ⚠ Nó CHỈ biết những gì có
      trong dữ liệu đó
        ↓
    ⚠ Sản phẩm mới KHÔNG có trong
      tập huấn luyện
        ↓
    ⚠ Mô hình BỊ GIỚI HẠN bởi
      chính dữ liệu của nó
        ↓
    → ⚠ DATA DEPENDENCY

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

"Hallucinations"
    → ⚠ BỊA thông tin; đề nói mô
      hình trả lời SAI hoặc THỪA NHẬN
      không biết — vế sau là hành vi
      ĐÚNG

"Unfair Bias"
    → ⚠ thiên vị giữa các nhóm

"Edge Cases"
    → ⚠ ca HIẾM, bất thường; ở đây
      là cả một DÒNG SẢN PHẨM MỚI,
      không phải ca hiếm

⚠ Đối chiếu #14000 (cùng lô) và #13874 (lô 145) — hai đề đó khoá knowledge cutoff vì nói về mô hình nền và sự kiện công khai. Đề này nói về mô hình ĐÃ TINH CHỈNH trên dữ liệu nội bộ có giới hạn thời gian, và bộ phương án không có knowledge cutoff. KHÔNG mâu thuẫn — cùng một hiện tượng nhìn từ hai góc, và phải chọn trong bộ đáp án hiện có.

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

• C (hallucinations) — phương án gần nhất và là bẫy chính: mô hình có đưa ra câu trả lời không chính xác. Nhưng nguyên nhân GỐC mà đề mô tả là phạm vi dữ liệu huấn luyện, và mô hình cũng thừa nhận không biết — hành vi trái ngược với ảo giác.

• B và D — mô tả hạn chế khác.

Ghi nhớ

⚠ Hạn chế của mô hình — bảng phải thuộc: | Hạn chế | Nguyên nhân | |---|---| | ⚠ Data dependency | ⚠ chỉ biết những gì trong dữ liệu huấn luyện | | Knowledge cutoff | ⚠ dạng cụ thể: giới hạn THỜI GIAN | | Hallucination | ⚠ bịa khi thiếu thông tin | | Bias | ⚠ dữ liệu huấn luyện thiên lệch | | Edge case | ⚠ ca hiếm, ít ví dụ |

Từ khoá nhận diện:

"chỉ biết dữ liệu đã huấn luyện" → ⚠ data dependency "không biết sự kiện sau ngày X" → ⚠ knowledge cutoff "bịa thông tin trôi chảy" → hallucination "ca hiếm, bất thường" → edge case

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Dữ liệu huấn luyện đến thời điểm nào | ⚠ biết giới hạn của mô hình | | Kiến thức có thay đổi thường xuyên không | ⚠ có → dùng RAG, không fine-tune | | Mô hình có nói được không biết không | ⚠ thử hỏi về sản phẩm mới |

Và sai lầm kiến trúc mà tình huống này minh hoạ: dùng fine-tuning để dạy mô hình những kiến thức sẽ thay đổi. Kiến thức đóng băng vào trọng số không thể cập nhật bằng cách sửa một tài liệu — và với danh mục sản phẩm thay đổi hằng năm, đó là một cuộc đua không bao giờ thắng được.

Đáp án

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

Vì sao đúng

Dữ liệu rải rác ở nhiều hệ thống cũ, có nhiều điểm không nhất quán, và thiếu nhiều trường. Biến đống đó thành dữ liệu dùng được để huấn luyện là công việc của giai đoạn chuẩn bị dữ liệu — và đó là nơi tốn công nhất.

⚠ Ba vấn đề đề nêu đều thuộc khâu chuẩn bị:

"rải rác nhiều hệ thống CŨ"
    → ⚠ phải hợp nhất

"nhiều điểm KHÔNG NHẤT QUÁN"
    → ⚠ phải chuẩn hoá

"THIẾU nhiều trường"
    → ⚠ phải xử lý giá trị thiếu
        ↓
    ⚠ Cả ba đều là DATA PREPARATION

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

"Model Training"
    → ⚠ chỉ chạy được SAU khi dữ
      liệu đã sạch

"Model Deployment"
    → ⚠ ở cuối vòng đời

"Model Management"
    → ⚠ sau khi đã triển khai

⚠ Gần trùng với #13875 (lô 145) — đề đó cũng là dữ liệu khách hàng rải rác, không nhất quán, thiếu trường, và khoá chất lượng và khả năng truy cập dữ liệu. Cùng thông điệp, 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à bẫy chính: người ta thường nghĩ huấn luyện là phần chính của dự án AI. Nhưng nó chỉ chạy được sau khi dữ liệu sẵn sàng, và với công cụ hiện nay, huấn luyện thường nhanh hơn nhiều so với chuẩn bị dữ liệu.

• C và A — nằm sau trong vòng đời.

Ghi nhớ

⚠ Phân bổ công sức thực tế trong dự án ML — bảng nên thuộc: | Giai đoạn | Công sức thực tế | |---|---| | ⚠ Data preparation | ⚠ PHẦN LỚN — thường bị đánh giá thấp nhất | | Model training | ⚠ ít hơn nhiều với công cụ hiện đại | | Evaluation | vừa phải | | Deployment | ⚠ vừa phải | | ⚠ Management | ⚠ liên tục, kéo dài nhất |

Từ khoá nhận diện:

"dữ liệu bẩn, rải rác, thiếu trường" → ⚠ data preparation "thu thập dữ liệu thô vào kho" → data ingestion "đo chỉ số trên tập test" → evaluation "khó truy cập, tốn ngân sách" → ⚠ availability

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Một khách có mấy mã định danh | ⚠ việc khó nhất | | Có quyền dùng dữ liệu này không | ⚠ hỏi trước khi xây | | Bước làm sạch có lặp lại được không | ⚠ phải là mã, không phải thao tác tay |

Và tỉ lệ công sức trong một dự án AI thực tế hiếm khi giống như kỳ vọng ban đầu: phần lớn thời gian nằm ở việc làm cho dữ liệu dùng được. Đội nào lập kế hoạch với giả định ngược lại thường phát hiện ra điều đó vào khoảng giữa dự án, khi lịch trình đã cam kết xong.

Đáp án

A — Áp dụng quy trình Human-in-the-Loop BẮT BUỘC cho hệ thống bồi thường rủi ro cao, trong khi để hệ thống tóm tắt HR rủi ro thấp hoạt động tự chủ hơn...

Vì sao đúng

Hai hệ thống có mức rủi ro rất khác nhau, nên chiến lược vận hành cũng phải khác nhau. Áp dụng cùng một mức kiểm soát cho cả hai là lãng phí hoặc nguy hiểm.

⚠ So sánh rủi ro hai hệ thống:

⚠ HỆ 1 — ĐÁNH GIÁ THIỆT HẠI và
       KHUYẾN NGHỊ TRÁCH NHIỆM
    → ⚠ hậu quả TÀI CHÍNH trực tiếp
    → ⚠ ràng buộc PHÁP LÝ
    → ⚠ ảnh hưởng quyền lợi khách
    → ⚠ RỦI RO CAO → HITL BẮT BUỘC

⚠ HỆ 2 — TÓM TẮT CHÍNH SÁCH HR
       cho bản tin nội bộ
    → ⚠ nội bộ, không ràng buộc
      pháp lý trực tiếp
    → ⚠ sai thì sửa được
    → ⚠ RỦI RO THẤP → tự chủ hơn

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

"HITL bắt buộc cho CẢ HAI"
    → ⚠ an toàn nhưng LÃNG PHÍ
    → ⚠ triệt tiêu lợi ích hiệu quả
      ở hệ rủi ro thấp

"Tóm tắt HR tự chủ hoàn toàn, còn
 dùng mô hình MẠNH HƠN cho hệ bồi
 thường để KHỎI cần người duyệt"
    → ⚠ SAI NGUY HIỂM: mô hình mạnh
      hơn KHÔNG thay thế được giám
      sát của con người ở việc có
      hậu quả pháp lý

"CẢ HAI tự chủ hoàn toàn"
    → ⚠ bỏ qua rủi ro của hệ bồi thường

Nhất quán với #13860 (lô 145) về HITL cho khuyến nghị đầu tư. Đề này thêm một tầng: phân bổ mức kiểm soát theo mức rủi ro. Bổ sung nhau.

Ghi nhớ về chất lượng câu hỏi

⚠ Phương án đúng bị CẮT CỤT ở cuối: kết thúc bằng "...with options for use" — phần còn lại (có lẽ là "with options for user review" hoặc tương tự) đã bị mất. Đây là lỗi cắt chuỗi khi nhập dữ liệu. Ý chính vẫn rõ và phân biệt được với ba phương án còn lại. Khoá đáp án A vẫn ĐÚNG và được giữ nguyên.

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

• B (HITL cho cả hai) — phương án gần nhất và là bẫy hấp dẫn: nghe an toàn nhất. Nhưng nó triệt tiêu lợi ích hiệu quả ở hệ rủi ro thấp, và trong thực tế dẫn tới việc người duyệt quá tải rồi duyệt hình thức.

• C và D — bỏ qua rủi ro hoặc hiểu sai vai trò của HITL.

Ghi nhớ

⚠ Ba mức giám sát của con người — bảng phải thuộc: | Mức | Nội dung | Dùng khi | |---|---|---| | ⚠ Human IN the loop | ⚠ người duyệt TỪNG kết quả | ⚠ rủi ro CAO | | ⚠ Human ON the loop | ⚠ người GIÁM SÁT, can thiệp khi cần | ⚠ rủi ro trung bình | | ⚠ Human OUT of the loop | ⚠ tự động hoàn toàn | ⚠ rủi ro THẤP |

Từ khoá nhận diện:

"hậu quả tài chính, pháp lý" → ⚠ HITL bắt buộc "nội bộ, sai thì sửa được" → ⚠ tự chủ hơn "phân bổ theo mức rủi ro" → ⚠ quản trị AI theo rủi ro "mô hình mạnh hơn thay người" → ⚠ SAI — không bao giờ

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Sai thì đảo ngược được không | ⚠ câu hỏi quyết định mức kiểm soát | | Người duyệt có đủ thời gian không | ⚠ quá tải thì HITL chỉ là hình thức | | Tỉ lệ sửa là bao nhiêu | ⚠ quá thấp là dấu hiệu đáng ngờ |

Và nguyên tắc quản trị AI thực dụng nhất mà tình huống này minh hoạ: phân bổ sự giám sát của con người theo mức rủi ro, không rải đều. Yêu cầu duyệt mọi thứ nghe có vẻ an toàn, nhưng kết quả thường là một quy trình mà không ai còn thời gian đọc kỹ ở đúng chỗ cần đọc kỹ nhất.

Đáp án

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

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

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

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này TRÙNG ĐỀ BÀI với #13933 đã xuất hiện ở lô trước. Bộ đề XÁO THỨ TỰ PHƯƠNG ÁN, nên chữ cái đáp án ĐÃ ĐỔI so với lần trước — nội dung đáp án thì không đổi.

⚠ Bài học khi ôn: nhớ theo NỘI DUNG phương án, đừng nhớ theo chữ cái. Cùng một câu hỏi có thể xuất hiện với thứ tự phương án khác nhau trong các đề khác nhau.