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

Đáp án

A — Tính sẵn sàng cao và cam kết mức dịch vụ (SLA) mạnh.

Vì sao đúng

Hệ thống chạy trên dây chuyền sản xuất theo thời gian thực, và thời gian dừng gây thiệt hại hàng triệu. Với ca sử dụng tối quan trọng như vậy, độ sẵn sàng và SLA là yếu tố quyết định.

⚠ Vì sao độ tin cậy quan trọng hơn tất cả ở đây:

Hệ thống dừng
        ↓
    ⚠ Dây chuyền sản xuất DỪNG
    ⚠ Thiệt hại hàng triệu
        ↓
    ⚠ Một mô hình mạnh hơn 5%
      KHÔNG bù được một giờ dừng máy
        ↓
    → ⚠ độ tin cậy là ràng buộc
      CỨNG, không phải tiêu chí
      "càng cao càng tốt"

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

"Tính năng MỚI NHẤT, THỬ NGHIỆM"
    → ⚠ NGƯỢC HẲN: hệ thống tối
      quan trọng cần thứ ỔN ĐỊNH,
      đã kiểm chứng

"Sinh văn bản hội thoại như người"
    → ⚠ không liên quan tới dự đoán
      hỏng hóc thiết bị

"Chi phí mỗi lời gọi THẤP NHẤT"
    → ⚠ tiết kiệm vài đồng không
      đáng so với thiệt hại dừng máy

Nhất quán với #13909 (lô 146) — đề đó cũng khoá scalability và reliability cho hệ thống chuỗi cung ứng toàn cầu cần uptime. Cùng nguyên tắc.

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

• D (chi phí thấp nhất) — phương án gần nhất vì chi phí luôn là mối quan tâm thật. Nhưng khi một giờ dừng máy tốn hàng triệu, tối ưu chi phí API là ưu tiên sai chỗ.

• B và C — không phù hợp với ca sử dụng.

Ghi nhớ

⚠ Tiêu chí quyết định theo LOẠI ỨNG DỤNG — bảng nên thuộc: | Loại ứng dụng | Tiêu chí hàng đầu | |---|---| | ⚠ Tối quan trọng, sản xuất | ⚠ độ tin cậy, SLA | | Thử nghiệm, làm mẫu | ⚠ tốc độ, chi phí thấp | | Khối lượng rất lớn | ⚠ chi phí mỗi lượt | | Ngành có quản lý | ⚠ giải thích được, tuân thủ | | Dữ liệu nhạy cảm | ⚠ bảo mật, quyền riêng tư | | Đội nhỏ, ít kỹ thuật | ⚠ dễ dùng, low-code |

Từ khoá nhận diện:

"dừng máy tốn hàng triệu" → ⚠ độ tin cậy, SLA "tải biến động toàn cầu" → scalability + reliability "ngân sách hạn hẹp" → chi phí "phải giải thích quyết định" → explainability

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | AI lỗi thì dây chuyền làm gì | ⚠ phải có phương án, không được dừng | | Mất mạng thì sao | ⚠ cân nhắc xử lý tại biên | | Đã diễn tập sự cố chưa | ⚠ đừng chỉ giả định |

Và nguyên tắc thiết kế quan trọng nhất cho AI trong môi trường sản xuất: hệ thống phải hoạt động được cả khi AI không hoạt động. Một luật ngưỡng đơn giản chạy song song, sẵn sàng tiếp quản, đáng giá hơn nhiều so với vài phần trăm độ chính xác tăng thêm.

Đáp án

B — Conversational Agents (agent hội thoại / bot ảo).

Vì sao đúng

Công ty viễn thông cần bot tương tác bằng ngôn ngữ tự nhiên, trả lời câu hỏi về tài khoản, và chuyển ca phức tạp cho nhân viên. Đó là bot ảo phục vụ khách hàng.

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

"tương tác NGÔN NGỮ TỰ NHIÊN"
    → ⚠ hiểu câu hỏi đa dạng

"trả lời câu hỏi VỀ TÀI KHOẢN"
    → ⚠ cần tra hệ thống thật
    → ⚠ grounding + tool

"LEO THANG cho nhân viên"
    → ⚠ biết giới hạn của mình

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

"Vertex AI Search"
    → ⚠ TÌM KIẾM tài liệu; không
      phải hội thoại nhiều lượt
      và tra tài khoản

"Gemini for Google Workspace"
    → ⚠ năng suất NỘI BỘ

"Cloud Translation API"
    → ⚠ dịch ngôn ngữ

Nhất quán với #13971 và #13993 (lô 147) — cùng bộ ba thành phần: Conversational Agents cho KHÁCH HÀNG, Agent Assist cho NHÂN VIÊN, CX Insights cho QUẢN LÝ. Đề này hỏi thành phần thứ nhất. Hoàn toàn nhất quán.

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

• C (Vertex AI Search) — phương án gần nhất vì cũng hiểu ngôn ngữ tự nhiên và tra được dữ liệu doanh nghiệp. Nhưng nó là tìm kiếm, không phải hội thoại nhiều lượt có khả năng tra tài khoản và leo thang.

• D và A — phục vụ mục đích khác.

Ghi nhớ

⚠ Ba thành phần chăm sóc khách hàng — bảng phải thuộc: | Thành phần | Phục vụ ai | Khi nào | |---|---|---| | ⚠ Conversational Agents | ⚠ KHÁCH HÀNG | ⚠ tự phục vụ 24/7 — đề này | | Agent Assist | ⚠ nhân viên | ⚠ thời gian thực trong cuộc gọi | | CX Insights | ⚠ quản lý | ⚠ sau cuộc gọi | | CCaaS | ⚠ nền tảng | ⚠ hạ tầng tổng đài |

Từ khoá nhận diện:

"bot nói chuyện với khách, leo thang" → ⚠ Conversational Agents "gợi ý cho nhân viên đang gọi" → Agent Assist "phân tích bản ghi" → CX Insights "nền tảng tổng đài" → CCaaS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bot có tra đúng tài khoản của khách không | ⚠ kiểm quyền, thử ca chéo | | Leo thang có mượt không | ⚠ gọi thử thật | | Khách bỏ cuộc bao nhiêu phần trăm | ⚠ chỉ số hay bị bỏ qua |

Và chỉ số dễ bị dùng để tự trấn an nhất khi báo cáo về bot chăm sóc khách hàng: tỉ lệ cuộc gọi không đến tay nhân viên. Con số đó tăng có thể vì bot giải quyết tốt, mà cũng có thể vì khách hàng đã bỏ cuộc — và hai điều đó dẫn tới hai kết luận hoàn toàn trái ngược.

Đáp án

B — Security Command Center.

Vì sao đúng

Ban quản lý cần bảng điều khiển TẬP TRUNG để phát hiện lỗ hổng tiềm ẩn trên nhiều dự án: bucket chứa dữ liệu huấn luyện bị mở công khai, vai IAM quá rộng trên dự án Vertex AI. Đó là Security Command Center.

⚠ SCC làm gì:

⚠ QUÉT toàn bộ tổ chức
        ↓
    ⚠ Phát hiện CẤU HÌNH SAI
    → bucket công khai
    → vai IAM quá rộng
    → VM có IP công khai
    → khoá không xoay vòng
        ↓
    ⚠ Phát hiện MỐI ĐE DOẠ
    ⚠ Đánh giá tuân thủ
        ↓
    ⚠ MỘT bảng điều khiển cho
      MỌI dự án

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

"IAM"
    → ⚠ CẤP và THỰC THI quyền;
      ⚠ KHÔNG phát hiện vai nào
      quá rộng trên toàn tổ chức

"Cloud Logging"
    → ⚠ GHI LẠI sự kiện; phải tự
      biết tìm gì

"Cloud Armor"
    → ⚠ WAF, chống DDoS ở tầng mạng

⚠ Đối chiếu #13945 (lô 147) — đề đó khoá IAM cho việc quản lý và thực thi quyền truy cập. Đề này khoá SCC cho việc PHÁT HIỆN cấu hình sai. KHÔNG mâu thuẫn — IAM là công cụ kiểm soát, SCC là công cụ phát hiện.

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

• C (IAM) — phương án gần nhất và là bẫy chính: vấn đề nêu ra có liên quan tới IAM. Nhưng IAM cấp quyền, còn việc rà soát và cảnh báo rằng một vai quá rộng thì cần SCC.

• A và D — phục vụ mục đích khác.

Ghi nhớ

⚠ Công cụ bảo mật — kiểm soát hay phát hiện, bảng phải thuộc: | Công cụ | Vai trò | |---|---| | ⚠ IAM | ⚠ KIỂM SOÁT — ai được làm gì | | Organization Policy | ⚠ KIỂM SOÁT — cấm hành vi | | VPC Service Controls | ⚠ KIỂM SOÁT — ngăn dữ liệu ra ngoài | | ⚠ Security Command Center | ⚠ PHÁT HIỆN — cấu hình sai, mối đe doạ | | Cloud Audit Logs | ⚠ GHI LẠI — ai đã làm gì | | Cloud Armor | ⚠ CHẶN — tấn công web |

Từ khoá nhận diện:

"bảng điều khiển tập trung, phát hiện lỗ hổng" → ⚠ Security Command Center "cấp và thực thi quyền" → IAM "cấm hành vi trên toàn tổ chức" → ⚠ Organization Policy "khung quản trị rủi ro AI" → ⚠ SAIF

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bucket nào công khai không | ⚠ SCC trả lời ngay | | Ai đang có vai quá rộng | ⚠ SCC + IAM Recommender | | Ai xử lý cảnh báo của SCC | ⚠ có bảng mà không ai đọc thì vô ích |

Và điều quyết định giá trị của một công cụ phát hiện như SCC không phải số lượng cảnh báo nó tạo ra, mà là có người thật sự xử lý chúng hay không. Một bảng điều khiển đầy cảnh báo đỏ mà không ai mở còn nguy hiểm hơn không có bảng nào, vì nó tạo ra cảm giác đã được bảo vệ.

Đáp án

D — Secure AI Framework (SAIF) của Google.

Vì sao đúng

CISO cần bộ thực hành tốt CÓ CẤU TRÚC, vượt ra ngoài bảo mật hạ tầng cơ bản, bao trùm toàn bộ vòng đời AI: bảo vệ dữ liệu huấn luyện, chống đánh cắp mô hình, triển khai có trách nhiệm. Đó chính là SAIF.

⚠ Vì sao SAIF chứ không phải công cụ:

"bộ THỰC HÀNH TỐT có cấu trúc"
    → ⚠ đây là KHUNG, không phải
      sản phẩm

"VƯỢT RA NGOÀI bảo mật hạ tầng"
    → ⚠ rủi ro ĐẶC THÙ của AI

"TOÀN BỘ vòng đời AI"
    → ⚠ dữ liệu → mô hình →
      triển khai → vận hành

"chính sách bảo mật AI toàn diện"
    → ⚠ tài liệu định hướng

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

"Chính sách IAM"
    → ⚠ CÔNG CỤ kiểm soát truy cập —
      một phần, không phải khung

"Vertex AI Model Monitoring"
    → ⚠ CÔNG CỤ phát hiện drift

"Cách tiếp cận mở của Google Cloud"
    → ⚠ triết lý về công nghệ mở,
      không phải khung bảo mật

⚠ Gần trùng với #13857 (lô 145) — đề đó cũng là doanh nghiệp cần mô hình quản trị nhất quán cho bảo mật AI, cùng khoá SAIF. Hoàn toàn nhất quán.

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

• A (chính sách IAM) — phương án gần nhất và là bẫy chính: IAM thật sự là một phần của bảo mật AI. Nhưng đề đòi khung bao trùm toàn vòng đời, còn IAM chỉ giải quyết kiểm soát truy cập.

• B và C — là công cụ hoặc triết lý, không phải khung quản trị.

Ghi nhớ

⚠ Khung và công cụ — đừng lẫn, bảng phải thuộc: | Loại | Ví dụ | |---|---| | ⚠ KHUNG / hướng dẫn | ⚠ SAIF, 7 nguyên tắc AI của Google | | ⚠ CÔNG CỤ kiểm soát | ⚠ IAM, Org Policy, VPC-SC, CMEK | | ⚠ CÔNG CỤ phát hiện | ⚠ SCC, audit log, Model Monitoring | | Quy trình | ⚠ HITL, red team, rà soát định kỳ |

Từ khoá nhận diện:

"khung, thực hành tốt, toàn vòng đời AI" → ⚠ SAIF "bảng điều khiển phát hiện lỗ hổng" → Security Command Center "cấp và thực thi quyền" → IAM "nguyên tắc đạo đức AI" → ⚠ 7 nguyên tắc AI

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có bao nhiêu ứng dụng AI trong tổ chức | ⚠ kiểm kê trước tiên | | Nhân viên đang dùng công cụ ngoài nào | ⚠ shadow AI | | Ai chịu trách nhiệm khi AI gây sự cố | ⚠ phải rõ trước |

Và bước đầu tiên của mọi chính sách bảo mật AI, trước cả việc chọn công cụ: kiểm kê xem tổ chức đang thực sự dùng những gì. Danh sách đó gần như luôn dài hơn dự kiến, và những mục không ai biết mới là phần đáng lo nhất.

Đáp án

D — Edge cases: những tình huống bất thường vượt quá kinh nghiệm huấn luyện điển hình của mô hình.

Vì sao đúng

Hệ thống chạy tốt với hồ sơ tiêu chuẩn nhưng thỉnh thoảng hỏng với tình huống bất thường: đồng vay có hồ sơ tín dụng chênh lệch lớn, thu nhập từ nước ngoài, tài sản bảo đảm đặc biệt. Đó là edge case.

⚠ Dấu hiệu nhận diện edge case:

"chạy TỐT với hồ sơ TIÊU CHUẨN"
    → ⚠ mô hình ổn ở ca thường

"THỈNH THOẢNG hỏng"
    → ⚠ không phải hỏng hệ thống

"tình huống BẤT THƯỜNG, ĐẶC BIỆT"
    → ⚠ hiếm gặp trong dữ liệu
      huấn luyện
        ↓
    ⚠ Mô hình không có đủ ví dụ
      để học những ca này

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

"Bias ảnh hưởng nhóm nhân khẩu"
    → ⚠ thiên vị theo NHÓM NGƯỜI;
      ở đây là theo LOẠI HỒ SƠ
      bất thường

"Knowledge cutoff về quy định
 cho vay mới"
    → ⚠ vấn đề THỜI GIAN; đề không
      nói tới quy định mới

"Hallucination sinh thông tin
 tài chính sai"
    → ⚠ BỊA thông tin; ở đây mô hình
      XỬ LÝ SAI, không bịa

⚠ Đối chiếu #13953 (lô 146) — ở đề đó "edge cases" là phương án SAI và khoá đúng là hallucination, vì mô hình bịa tiểu sử nhân vật. Ở đây mô hình xử lý sai ca hiếm. KHÔNG mâu thuẫn — hai hiện tượng khác nhau, và đây là cặp minh hoạ tốt để phân biệt.

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

• A (bias) — phương án gần nhất và là bẫy mạnh trong bối cảnh cho vay, nơi thiên vị là rủi ro nổi tiếng. Nhưng đề mô tả khó khăn theo loại hồ sơ phức tạp, không theo nhóm nhân khẩu.

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

Ghi nhớ

⚠ Hạn chế của mô hình — phân biệt cho rõ, bảng phải thuộc: | Hạn chế | Dấu hiệu | |---|---| | ⚠ Edge case | ⚠ ca HIẾM, bất thường — ít dữ liệu huấn luyện | | Bias | ⚠ lệch theo NHÓM NGƯỜI | | Hallucination | ⚠ BỊA thông tin không có thật | | Knowledge cutoff | ⚠ không biết chuyện MỚI | | Context window | ⚠ đầu vào quá dài |

Từ khoá nhận diện:

"tình huống hiếm, bất thường, phức tạp" → ⚠ edge case "chênh lệch giữa các nhóm người" → bias "bịa chi tiết trôi chảy" → hallucination "không biết sự kiện gần đây" → knowledge cutoff

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình có nhận ra ca lạ không | ⚠ thử với hồ sơ bất thường | | Ca lạ có được chuyển người không | ⚠ thay vì đoán bừa | | Ca thất bại có được ghi lại không | ⚠ nguồn cải thiện chính |

Và điều nguy hiểm nhất về edge case không phải là mô hình xử lý sai, mà là nó xử lý sai với cùng mức tự tin như khi xử lý đúng. Vì vậy khả năng nhận ra "đây là tình huống tôi chưa gặp" quan trọng không kém khả năng trả lời — và đó thường là phần phải do hệ thống xung quanh mô hình đảm nhiệm.

Đáp án

D — Prompt Engineering.

Vì sao đúng

Nhà phân tích không đổi mô hình, không huấn luyện gì — chỉ cấu trúc lại và làm rõ câu lệnh: nêu độ dài, số đoạn, và những gì cần nhấn mạnh. Đó là prompt engineering.

⚠ Vì sao prompt thứ hai tốt hơn:

"Tóm tắt biên bản họp"
    → ⚠ mô hình không biết cần
      dài bao nhiêu, nhấn gì
    → ⚠ trả về quá ngắn

"Đưa ra bản tóm tắt CHI TIẾT,
 NĂM ĐOẠN, làm nổi bật VIỆC CẦN
 LÀM và QUYẾT ĐỊNH quan trọng"
        ↓
    ⚠ ĐỘ DÀI: chi tiết, năm đoạn
    ⚠ NỘI DUNG: việc cần làm,
      quyết định
        ↓
    → ⚠ mô hình có đủ ràng buộc

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

"Fine-tuning"
    → ⚠ HUẤN LUYỆN THÊM mô hình —
      không xảy ra ở đây

"RAG"
    → ⚠ nối với nguồn dữ liệu ngoài

"Model Deployment"
    → ⚠ đưa mô hình ra phục vụ

⚠ Gần trùng với #13873 (lô 145) — đề đó là viết khẩu hiệu marketing, cũng chỉ đổi câu lệnh, cùng khoá prompt engineering. Hoàn toàn nhất quán.

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

• A (fine-tuning) — phương án gần nhất và là bẫy chính: cũng là cách làm mô hình cho kết quả tốt hơn. Nhưng nó đòi dữ liệu và huấn luyện, còn đây chỉ là viết lại yêu cầu.

• C và B — thuộc khâu khác.

Ghi nhớ

⚠ Bốn cách cải thiện đầu ra — theo công sức: | Cách | Công sức | Giải quyết | |---|---|---| | ⚠ Prompt engineering | ⚠ thấp nhất | ⚠ định dạng, độ dài, trọng tâm | | Few-shot | thấp | ⚠ định dạng nhất quán | | Grounding / RAG | trung bình | ⚠ thiếu KIẾN THỨC | | Fine-tuning | ⚠ cao nhất | ⚠ PHONG CÁCH ổn định |

Từ khoá nhận diện:

"viết lại câu lệnh cho rõ" → ⚠ prompt engineering "nối với tài liệu công ty" → RAG "huấn luyện thêm trên dữ liệu riêng" → fine-tuning "đưa mô hình ra phục vụ" → deployment

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Prompt đã nêu độ dài và trọng tâm chưa | ⚠ hai thứ hay thiếu nhất | | Bản tóm tắt có bỏ sót gì quan trọng không | ⚠ đối chiếu biên bản gốc vài lần | | Việc cần làm gán đúng người chưa | ⚠ kiểm kỹ phần này |

Và cải thiện đơn giản nhất cho mọi prompt tóm tắt: nói rõ bản tóm tắt phải chứa những gì. Mô hình không đoán được rằng bạn quan tâm tới việc cần làm và quyết định — và khi được nói ra, kết quả thường tốt hơn ngay lập tức mà không cần đụng tới bất cứ thứ gì khác.

Đáp án

B — Vertex AI Feature Store.

Vì sao đúng

Hai mô hình khác nhau cùng dùng một đặc trưng (customer_purchase_frequency), và công ty cần hệ thống tập trung để lưu, quản và PHỤC VỤ đặc trưng đó theo cùng một cách — nhằm chống training-serving skew. Đó chính là Feature Store.

⚠ Vấn đề nếu không có Feature Store:

Đội gợi ý tính
  "tần suất mua" = số đơn / 12 tháng

Đội chống gian lận tính
  "tần suất mua" = số đơn / 90 ngày
        ↓
    ⚠ CÙNG TÊN, KHÁC NGHĨA
        ↓
    ⚠ Và tệ hơn: lúc huấn luyện
      tính một kiểu, lúc phục vụ
      tính kiểu khác
        ↓
    ⚠ TRAINING-SERVING SKEW
    → ⚠ mô hình chính xác khi test,
      sai khi chạy thật

⚠ Feature Store giải quyết ra sao:

⚠ ĐỊNH NGHĨA đặc trưng MỘT LẦN
        ↓
    ⚠ Dùng chung cho MỌI mô hình
    ⚠ Dùng chung cho HUẤN LUYỆN
      và PHỤC VỤ
        ↓
    ⚠ Point-in-time correctness
    ⚠ Đánh phiên bản đặc trưng
    ⚠ Chia sẻ giữa các đội

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

"Model Registry"
    → ⚠ quản phiên bản MÔ HÌNH

"Model Monitoring"
    → ⚠ PHÁT HIỆN skew, không
      NGĂN NGỪA nó

"Pipelines"
    → ⚠ tự động hoá quy trình

⚠ Gần trùng với #13995 (lô 147) — đề đó về quản phiên bản dữ liệu và đặc trưng, cùng khoá Feature Store. Đề này nói rõ hơn về skew và dùng chung giữa hai mô hình. Hoàn toàn nhất quán.

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

• D (Model Monitoring) — phương án gần nhất và là bẫy tinh tế: nó phát hiện được skew. Nhưng đề muốn NGĂN NGỪA bằng cách phục vụ đặc trưng nhất quán — đó là việc của Feature Store.

• A và C — phục vụ khâu khác.

Ghi nhớ

⚠ Công cụ MLOps — ngăn ngừa hay phát hiện, bảng phải thuộc: | Công cụ | Vai trò | |---|---| | ⚠ Feature Store | ⚠ NGĂN NGỪA skew — một định nghĩa duy nhất | | ⚠ Model Monitoring | ⚠ PHÁT HIỆN skew và drift | | Model Registry | quản phiên bản mô hình | | Pipelines | tự động hoá |

Từ khoá nhận diện:

"đặc trưng dùng chung, chống skew" → ⚠ Feature Store "phát hiện phân phối đổi" → Model Monitoring "quản phiên bản mô hình" → Model Registry "tự động hoá huấn luyện lại" → Pipelines

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đặc trưng tính ở mấy nơi | ⚠ nhiều hơn một là nguy cơ skew | | Hai đội có định nghĩa giống nhau không | ⚠ hỏi cả hai, so công thức | | Có dùng dữ liệu tương lai không | ⚠ point-in-time correctness |

Và dấu hiệu rõ nhất cho thấy một tổ chức cần Feature Store: hai đội cùng dùng một khái niệm nghiệp vụ nhưng tính ra hai con số khác nhau. Đó không chỉ là vấn đề kỹ thuật của mô hình — nó còn có nghĩa là hai đội đang nói về hai thứ khác nhau dưới cùng một cái tên.

Đáp án

D — Dịch nâng cao có bảo toàn cấu trúc và định dạng tài liệu.

Vì sao đúng

Hãng luật cần bản dịch giữ nguyên định dạng pháp lý, cấu trúc đoạn và bố cục tài liệu — vì luật sư cần đối chiếu theo điều khoản và mục.

⚠ Vì sao định dạng quan trọng với hợp đồng:

Hợp đồng pháp lý
        ↓
    ⚠ Đánh số điều khoản
    ⚠ Mục, tiểu mục lồng nhau
    ⚠ Bảng biểu, phụ lục
    ⚠ Định dạng có Ý NGHĨA PHÁP LÝ
        ↓
    ⚠ Dịch mà mất cấu trúc
        ↓
    ⚠ Không đối chiếu được điều 5.2
      bản gốc với bản dịch
    ⚠ Không dùng để rà soát được

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

"Dịch văn bản CƠ BẢN, chuyển từ
 và cụm từ"
    → ⚠ mất cấu trúc — đúng thứ
      đề nói là KHÔNG chấp nhận được

"Dịch THỜI GIAN THỰC cho hội thoại"
    → ⚠ dành cho nói chuyện, không
      phải tài liệu

"Tối ưu THUẬT NGỮ pháp lý"
    → ⚠ QUAN TRỌNG thật, nhưng đề
      nhấn mạnh ĐỊNH DẠNG và BỐ CỤC

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

• C (tối ưu thuật ngữ pháp lý) — phương án gần nhất và là bẫy mạnh: với hợp đồng, thuật ngữ chính xác rõ ràng rất quan trọng. Nhưng đề nêu cụ thể ba thứ: định dạng pháp lý, cấu trúc đoạn, bố cục tài liệu — đều thuộc về cấu trúc.

• B và A — không đáp ứng yêu cầu.

Ghi nhớ

⚠ Các dạng dịch — bảng nên thuộc: | Dạng | Dùng khi | |---|---| | Dịch văn bản cơ bản | ⚠ chuỗi ngắn, giao diện | | ⚠ Dịch TÀI LIỆU | ⚠ giữ định dạng, bố cục — đề này | | Dịch thời gian thực | ⚠ hội thoại, phụ đề | | ⚠ Dịch có thuật ngữ tuỳ biến | ⚠ glossary cho ngành | | Dịch tuỳ biến (AutoML) | ⚠ huấn luyện trên cặp câu của bạn |

Từ khoá nhận diện:

"giữ định dạng, bố cục tài liệu" → ⚠ document translation "hội thoại trực tiếp" → real-time translation "thuật ngữ ngành nhất quán" → ⚠ glossary tuỳ biến "trích trường từ tài liệu" → ⚠ Document AI — khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đánh số điều khoản có khớp không | ⚠ đối chiếu bản gốc và bản dịch | | Thuật ngữ có nhất quán không | ⚠ dùng glossary | | Ai rà soát trước khi dùng | ⚠ luật sư biết cả hai thứ tiếng |

Và ranh giới cần nói rõ với mọi bên khi dùng dịch máy cho tài liệu pháp lý: bản dịch phục vụ việc đọc hiểu và rà soát, không phải bản có hiệu lực. Nó rút ngắn rất nhiều thời gian đọc hàng trăm trang, nhưng không thay thế được bản dịch có công chứng khi đến lúc ký.

Đáp án

A — Nhận diện nội dung hình ảnh để xác định vật thể và cảnh trong các khung hình video.

Vì sao đúng

Nhu cầu cốt lõi là phân tích NỘI DUNG HÌNH ẢNH của video: tìm cảnh có sản phẩm được đặt vào, phát hiện vi phạm an toàn, trích khoảnh khắc, phân loại nội dung. Tất cả đều dựa vào việc nhìn thấy gì trong khung hình.

⚠ Ba nhiệm vụ đều là thị giác:

"nhận diện cảnh có SẢN PHẨM
 được đặt vào"
    → ⚠ nhận diện logo, vật thể

"phát hiện VI PHẠM AN TOÀN"
    → ⚠ nhận diện hành vi, thiết bị
      bảo hộ

"phân loại nội dung theo đối tượng"
    → ⚠ nhận diện cảnh và nhãn
        ↓
    → ⚠ tất cả cần THỊ GIÁC MÁY TÍNH
      trên khung hình video

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

"Phân tích ÂM THANH"
    → ⚠ hữu ích BỔ SUNG, nhưng
      sản phẩm xuất hiện trong
      HÌNH, không phải trong tiếng

"Xử lý VĂN BẢN mô tả và metadata"
    → ⚠ metadata thường KHÔNG có
      thông tin này — đó là lý do
      cần phân tích tự động

"Tối ưu LƯU TRỮ"
    → ⚠ vấn đề hạ tầng, không phải
      năng lực AI

Nhất quán với #13937 (lô 146) — đề đó khoá Vision API cho phân tích ảnh. Đề này là video, nên công cụ tương ứng là Video Intelligence. Cùng nguyên tắc: chọn theo loại dữ liệu.

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

• D (phân tích âm thanh) — phương án gần nhất vì video có cả tiếng và phân tích lời thoại thật sự hữu ích. Nhưng ba nhiệm vụ đề nêu đều về những gì NHÌN THẤY.

• C và B — không giải quyết bài toán.

Ghi nhớ

⚠ API theo loại dữ liệu — bảng phải thuộc: | Đầu vào | API | |---|---| | Ảnh tĩnh | ⚠ Vision API | | ⚠ Video | ⚠ Video Intelligence API | | Âm thanh | Speech-to-Text | | Văn bản | Natural Language | | ⚠ Nhãn RIÊNG của ngành | ⚠ AutoML Video / Vision | | Hiểu video kèm suy luận | ⚠ Gemini đa phương thức |

Từ khoá nhận diện:

"nhận diện cảnh, vật thể trong video" → ⚠ Video Intelligence "ảnh tĩnh" → Vision API "lời thoại trong video" → ⚠ Speech-to-Text "nhãn riêng, có video gán nhãn" → ⚠ AutoML Video

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhãn phổ quát có đủ không | ⚠ thử với video thật trước | | Chi phí cho toàn kho video | ⚠ số phút × đơn giá | | Ai xem lại đoạn được đánh dấu | ⚠ AI thu hẹp, người kết luận |

Và giá trị thực tế của phân tích video tự động không nằm ở việc thay thế người xem: nó nằm ở việc biến hàng nghìn giờ video thành một danh sách vài chục khoảnh khắc đáng xem. Phần kết luận, đặc biệt với vi phạm an toàn, vẫn nên thuộc về con người.

Đáp án

D — Kích thước cửa sổ ngữ cảnh, để xử lý được toàn bộ độ dài tài liệu.

Vì sao đúng

Đề nói thẳng ra ràng buộc: một số mô hình chỉ xử lý được vài trang một lần, số khác xử lý được cả tài liệu nhưng đắt hơn nhiều. Đó chính là sự khác biệt về cửa sổ ngữ cảnh.

⚠ Vì sao cửa sổ ngữ cảnh là ràng buộc quyết định:

Hợp đồng sáp nhập 50–100 trang
        ↓
    ⚠ vài chục nghìn token
        ↓
    ⚠ Cửa sổ NHỎ HƠN?
        ↓
    ⚠ phải CHIA ĐOẠN
    ⚠ mất liên hệ giữa các điều khoản
        ↓
    ⚠ Với HỢP ĐỒNG, điều khoản ở
      trang 10 có thể tham chiếu
      định nghĩa ở trang 3

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

"Fine-tuning cho thuật ngữ pháp lý"
    → ⚠ hữu ích cho PHONG CÁCH,
      không giải quyết ĐỘ DÀI

"Multimodal cho nhiều loại tệp"
    → ⚠ hợp đồng là văn bản

"Temperature cho sáng tạo hay
 chính xác"
    → ⚠ quan trọng (nên đặt THẤP),
      nhưng không phải ràng buộc
      đề mô tả

⚠ Gần trùng với #13931 (lô 146) — đề đó là tóm tắt bài báo khoa học 50–100 trang, cùng khoá cửa sổ ngữ cảnh. Hoàn toàn nhất quán.

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

• A (fine-tuning cho thuật ngữ) — phương án gần nhất và là bẫy mạnh trong bối cảnh pháp lý. Nhưng dù mô hình có hiểu thuật ngữ tốt đến đâu, nó vẫn không đọc nổi tài liệu vượt cửa sổ ngữ cảnh.

• B và C — không phải ràng buộc đề nêu.

Ghi nhớ

⚠ Tiêu chí chọn mô hình — theo thứ tự, bảng phải thuộc: | 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 |

Từ khoá nhận diện:

"tài liệu rất dài, xử lý toàn bộ" → ⚠ context window "thuật ngữ, văn phong ngành" → fine-tuning "chính xác, bám nguồn" → ⚠ temperature thấp "nhiều loại tệp" → multimodal

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 | | Có bỏ sót điều khoản giữa không | ⚠ thử hỏi về nội dung ở giữa tài liệu | | Chi phí mỗi lần phân tích | ⚠ nhân với số hợp đồng mỗi tháng |

Và với hợp đồng sáp nhập, rủi ro lớn nhất của việc chia nhỏ tài liệu là bỏ sót một điều khoản loại trừ nằm ở phần khác. Đó là loại chi tiết có thể đảo ngược ý nghĩa của cả một điều khoản — và cũng là lý do đây là một trong số ít trường hợp mà chi phí của cửa sổ ngữ cảnh lớn thật sự xứng đáng.