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

Đáp án

B — Gemini Code Assist.

Vì sao đúng

Lập trình viên cần công cụ tích hợp vào trình soạn thảo mã, cung cấp gợi ý theo thời gian thực, sinh mã khuôn mẫu, và giải thích đoạn mã phức tạp. Đó chính là Gemini Code Assist.

⚠ Bốn dữ kiện khớp:

"tích hợp vào TRÌNH SOẠN THẢO MÃ"
    → ⚠ plugin cho IDE

"gợi ý mã THỜI GIAN THỰC"
    → ⚠ hoàn thiện khi đang gõ

"sinh mã KHUÔN MẪU"
    → ⚠ boilerplate

"GIẢI THÍCH đoạn mã phức tạp"
    → ⚠ rất giá trị với mã kế thừa

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

"Gemini for Google Workspace"
    → ⚠ Gmail, Docs, Sheets —
      không phải IDE

"Google AI Pro trong ứng dụng
 Gemini tiêu dùng"
    → ⚠ trợ lý cá nhân, không tích
      hợp vào IDE
    → ⚠ và không nên dán mã nội bộ vào

"Vertex AI Search"
    → ⚠ tìm kiếm doanh nghiệp

Nhất quán với #13870 (lô 145) — đề đó về mô hình nền cho trợ lý lập trình đa phương thức, khoá Gemini. Và #13927 (lô 146) về năng lực sinh mã. Đề này hỏi sản phẩm cụ thể. Ba đề bổ sung nhau.

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

• C (Google AI Pro trong app Gemini) — phương án gần nhất và là bẫy chính: nó cũng trả lời được câu hỏi về mã. Nhưng nó không tích hợp vào IDE, và dán mã nội bộ vào công cụ tiêu dùng là rủi ro dữ liệu.

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

Ghi nhớ

⚠ Gemini theo NƠI LÀM VIỆC — bảng phải thuộc: | Nơi | Sản phẩm | |---|---| | ⚠ IDE | ⚠ Gemini Code Assist | | Gmail, Docs, Sheets, Meet | ⚠ Gemini for Workspace | | Cloud Console | ⚠ Gemini Cloud Assist | | ⚠ Bảo mật | ⚠ Gemini in Security | | BigQuery | ⚠ Gemini in BigQuery | | Cá nhân | ⚠ ứng dụng Gemini + Gems | | Xây ứng dụng | ⚠ Vertex AI / Gemini API |

Từ khoá nhận diện:

"trong IDE, gợi ý mã" → ⚠ Gemini Code Assist "trong Gmail, Docs" → Gemini for Workspace "phân tích cảnh báo bảo mật" → ⚠ Gemini in Security "viết SQL, phân tích dữ liệu" → ⚠ Gemini in BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mã nội bộ có bị gửi ra ngoài không | ⚠ kiểm chính sách dữ liệu của công cụ | | Mã sinh ra có được review không | ⚠ bắt buộc | | Thư viện gợi ý có tồn tại không | ⚠ kiểm tên gói |

Và rủi ro thực tế lớn nhất khi một tổ chức chưa cung cấp công cụ AI cho lập trình viên: họ sẽ tự dùng công cụ bên ngoài và dán mã nội bộ vào đó. Cách kiểm soát hiệu quả hơn mọi chính sách cấm đoán vẫn là đưa ra một lựa chọn nội bộ đủ tốt để không ai cần đi đường vòng.

Đáp án

A — AppSheet.

Vì sao đúng

Người dùng không biết lập trình, muốn mô tả yêu cầu bằng ngôn ngữ tự nhiên và có ngay cấu trúc ứng dụng ban đầu để chỉnh sửa tiếp. AppSheet là nền tảng no-code của Google, và khi có Gemini thì dựng được ứng dụng từ mô tả bằng lời.

⚠ Ba dữ kiện khớp:

"KHÔNG có kinh nghiệm lập trình"
    → ⚠ cần NO-CODE

"mô tả yêu cầu bằng NGÔN NGỮ
 TỰ NHIÊN"
    → ⚠ Gemini trong AppSheet

"sinh CẤU TRÚC ứng dụng ban đầu,
 rồi tinh chỉnh"
    → ⚠ đúng quy trình AppSheet

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

"Vertex AI Agent Builder"
    → ⚠ dựng AGENT AI, không phải
      ứng dụng theo dõi công việc

"Cloud Run functions"
    → ⚠ chạy mã — đòi lập trình

"Google AI Studio"
    → ⚠ thử PROMPT, không dựng
      ứng dụng có giao diện và
      cơ sở dữ liệu

Nhất quán với #13924 (lô 146) và #13869 (lô 145) về low-code/no-code cho người không kỹ thuật. Đề này hỏi sản phẩm cụ thể. Bổ sung nhau.

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

• D (Google AI Studio) — phương án gần nhất và là bẫy chính: cũng dễ dùng, cũng có giao diện web, cũng dùng Gemini. Nhưng nó để thử prompt, không dựng ra một ứng dụng di động có dữ liệu và giao diện.

• B và C — phục vụ mục đích khác hoặc đòi lập trình.

Ghi nhớ

⚠ Công cụ theo mức kỹ năng — bảng nên thuộc: | Nhu cầu | Công cụ | |---|---| | ⚠ Ứng dụng nghiệp vụ, không viết mã | ⚠ AppSheet | | Thử prompt, làm mẫu AI | ⚠ Google AI Studio | | Agent AI cho sản phẩm | ⚠ Agent Builder | | Ứng dụng tuỳ biến | ⚠ Cloud Run, App Engine | | Tự động hoá luồng công việc | ⚠ Workflows, AppSheet Automation |

Từ khoá nhận diện:

"không lập trình, dựng app nghiệp vụ" → ⚠ AppSheet "thử prompt nhanh" → AI Studio "agent hội thoại" → Agent Builder "viết mã, triển khai container" → Cloud Run

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | App dùng dữ liệu gì, ai xem được | ⚠ rà quyền trước khi chia sẻ | | Ai bảo trì khi người dựng nghỉ | ⚠ rủi ro thật của no-code | | Đã có app tương tự chưa | ⚠ tránh trùng lặp |

Và mặt trái của việc ai cũng dựng được ứng dụng: tổ chức sớm có hàng chục ứng dụng nhỏ mà không ai nắm được chúng đang chứa dữ liệu gì. Vì vậy một danh mục ứng dụng nội bộ và vài quy tắc về dữ liệu nên có từ sớm, chứ không phải sau khi con số đã lên tới hàng trăm.

Đáp án

C — Gemini in Security.

Vì sao đúng

Đội vận hành bảo mật cần phân tích cảnh báo nhanh hơn, hiểu đường tấn công tiềm năng, và tóm tắt chiến thuật của các nhóm tấn công. Đó là phạm vi của Gemini trong lĩnh vực bảo mật.

⚠ Gemini in Security giúp gì:

⚠ TÓM TẮT cảnh báo phức tạp
    → ⚠ bằng ngôn ngữ dễ hiểu

⚠ GIẢI THÍCH đường tấn công
    → ⚠ kẻ tấn công có thể đi tiếp
      tới đâu

⚠ TÓM TẮT thông tin tình báo
  mối đe doạ
    → ⚠ chiến thuật của nhóm tấn công

⚠ HỖ TRỢ viết truy vấn tìm kiếm
    → ⚠ bằng ngôn ngữ tự nhiên

⚠ ĐỀ XUẤT bước xử lý

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

"Gemini Code Assist cho viết mã
 an toàn"
    → ⚠ hỗ trợ LẬP TRÌNH VIÊN,
      không phải đội vận hành bảo mật

"Gemini for Workspace"
    → ⚠ năng suất văn phòng

"Gemini in BigQuery"
    → ⚠ phân tích dữ liệu

Nhất quán với #13986 (cùng lô) — cùng họ Gemini theo nơi làm việc, mỗi phiên bản phục vụ một nhóm người dùng. Bổ sung nhau.

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

• B (Code Assist cho viết mã an toàn) — phương án gần nhất và là bẫy chính: cũng liên quan tới bảo mật. Nhưng nó giúp lập trình viên viết mã ít lỗ hổng, còn đề nói về đội vận hành phân tích cảnh báo.

• A và D — phục vụ nhóm khác.

Ghi nhớ

⚠ Gemini theo nhóm người dùng — bảng phải thuộc: | Nhóm | Sản phẩm | |---|---| | ⚠ Đội bảo mật (SOC) | ⚠ Gemini in Security | | Lập trình viên | ⚠ Gemini Code Assist | | Nhân viên văn phòng | ⚠ Gemini for Workspace | | Nhà phân tích dữ liệu | ⚠ Gemini in BigQuery | | Kỹ sư vận hành đám mây | ⚠ Gemini Cloud Assist | | Cá nhân | ⚠ ứng dụng Gemini |

Từ khoá nhận diện:

"phân tích cảnh báo, đường tấn công" → ⚠ Gemini in Security "gợi ý mã trong IDE" → Code Assist "viết SQL, phân tích dữ liệu" → Gemini in BigQuery "khung quản trị rủi ro AI" → ⚠ SAIF — khác hẳn

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Phân tích viên có kiểm chứng tóm tắt không | ⚠ bắt buộc | | AI có được tự thực hiện hành động không | ⚠ nên là không, hoặc rất hạn chế | | MTTR có cải thiện thật không | ⚠ đo trước và sau |

Và ranh giới nên giữ khi đưa AI vào trung tâm vận hành bảo mật: để nó rút ngắn thời gian hiểu tình huống, không để nó tự bấm nút ứng phó. Một hành động ngăn chặn sai có thể gây gián đoạn dịch vụ nghiêm trọng hơn chính mối đe doạ mà nó định chặn.

Đáp án

D — Vertex Explainable AI.

Vì sao đúng

Ngân hàng cần biết đặc trưng đầu vào nào ảnh hưởng nhiều nhất tới MỘT quyết định từ chối cụ thể. Đó chính là feature attribution mà Vertex Explainable AI cung cấp.

⚠ Explainable AI trả lời câu hỏi gì:

"Vì sao hồ sơ NÀY bị từ chối?"
        ↓
    ⚠ Feature attribution
        ↓
    ⚠ điểm tín dụng: đóng góp −0,4
    ⚠ tỉ lệ nợ/thu nhập: −0,3
    ⚠ thời gian làm việc: +0,1
        ↓
    → ⚠ biết yếu tố nào đẩy quyết
      định về phía từ chối

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

"Vertex AI Model Monitoring"
    → ⚠ phát hiện DRIFT, không giải
      thích một quyết định cụ thể

"Vertex AI Vizier"
    → ⚠ tối ưu SIÊU THAM SỐ

"Security Command Center"
    → ⚠ công cụ BẢO MẬT

Nhất quán với #13879 (lô 145) — đề đó cũng là từ chối hồ sơ vay và cần giải thích, khoá accountability + explainability (nguyên tắc). Đề này hỏi CÔNG CỤ. Bổ sung nhau, không mâu thuẫn.

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

• A (Model Monitoring) — phương án gần nhất và là bẫy chính: cùng bộ MLOps và cũng phân tích mô hình đang chạy. Nhưng nó theo dõi phân phối dữ liệu theo thời gian, không giải thích một dự đoán cụ thể.

• C và B — phục vụ mục đích khác.

Ghi nhớ

⚠ Công cụ Vertex AI — mỗi cái một việc, bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Explainable AI | ⚠ vì sao ra kết quả NÀY — feature attribution | | Model Monitoring | ⚠ phát hiện drift theo thời gian | | Model Registry | quản phiên bản | | ⚠ Vizier | ⚠ tối ưu siêu tham số | | Model Evaluation | ⚠ chỉ số tổng thể, theo nhóm | | Feature Store | đặc trưng dùng chung |

Từ khoá nhận diện:

"đặc trưng nào ảnh hưởng tới quyết định này" → ⚠ Explainable AI "dữ liệu đầu vào đã đổi" → Model Monitoring "tìm siêu tham số tốt nhất" → ⚠ Vizier "phiên bản nào đang chạy" → Model Registry

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nêu được lý do bằng một câu không | ⚠ thử viết cho khách hàng | | Mô hình dựa vào yếu tố nào nhiều nhất | ⚠ chạy attribution, có thể lộ ra thứ vô lý | | Có chênh lệch giữa các nhóm không | ⚠ đo riêng từng nhóm |

Và việc nên làm trước khi đưa một mô hình tín dụng vào vận hành, chứ không phải sau khi có khiếu nại: chạy phân tích đóng góp đặc trưng và đọc kỹ danh sách. Nó thường phơi bày ra rằng mô hình đang dựa vào một yếu tố mà không ai muốn giải thích trước cơ quan quản lý.

Đáp án

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

Vì sao đúng

Công ty cần một nền tảng tổng đài đám mây cấp doanh nghiệp làm nền cho cả ba năng lực: bot ảo 24/7, hỗ trợ nhân viên thời gian thực, và phân tích hội thoại — tất cả trong một giải pháp có khả năng mở rộng.

⚠ Vì sao là CCaaS chứ không phải thành phần lẻ:

Đề nói:
    ⚠ "nền tảng NATIVE CLOUD"
    ⚠ "cấp doanh nghiệp"
    ⚠ "CÓ KHẢ NĂNG MỞ RỘNG"
    ⚠ cả BA năng lực cùng lúc
        ↓
    ⚠ Đây là hỏi về NỀN TẢNG
      TỔNG ĐÀI, không phải một
      tính năng

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

"Vertex AI tools (Agent Builder)"
    → ⚠ công cụ XÂY agent; ⚠ không
      phải nền tảng tổng đài có định
      tuyến cuộc gọi, quản ca trực,
      báo cáo

"Google Meet với Gemini"
    → ⚠ họp trực tuyến

"Apigee"
    → ⚠ quản lý API

⚠ Đối chiếu #13871 (lô 145) khoá Customer Engagement Suite khi đề liệt kê ba năng lực, và #13971 (cùng lô) khoá Agent Assist khi đề hỏi riêng phần hỗ trợ nhân viên. Đề này nhấn "nền tảng native cloud" nên khoá CCaaS. Không mâu thuẫn — ba đề hỏi ba cấp độ: bộ giải pháp, nền tảng, thành phần.

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

• C (Vertex AI tools) — phương án gần nhất và là bẫy mạnh: Agent Builder thật sự dựng được bot. Nhưng một tổng đài cần nhiều hơn thế: định tuyến cuộc gọi, hàng đợi, quản lý ca trực, tích hợp điện thoại, báo cáo giám sát.

• A và D — thuộc lĩnh vực khác.

Ghi nhớ

⚠ Ba cấp trong giải pháp tổng đài — bảng nên thuộc: | Cấp | Nội dung | |---|---| | ⚠ Bộ giải pháp | ⚠ Customer Engagement Suite with Google AI | | ⚠ Nền tảng | ⚠ CCaaS — hạ tầng tổng đài đám mây | | ⚠ Thành phần | ⚠ Conversational Agents, Agent Assist, CX Insights |

Từ khoá nhận diện:

"nền tảng tổng đài đám mây" → ⚠ CCaaS "bộ giải pháp gồm ba năng lực" → ⚠ Customer Engagement Suite "hỗ trợ nhân viên thời gian thực" → ⚠ Agent Assist "phân tích bản ghi cuộc gọi" → CX Insights "xây agent cho website" → Agent Builder

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chịu được đỉnh tải sự cố không | ⚠ thử tải mô phỏng | | Khách chuyển sang người có phải kể lại không | ⚠ gọi thử thật | | Bot có giải quyết được thật không | ⚠ đo tỉ lệ giải quyết, không phải tỉ lệ chặn |

Và chỉ số dễ bị dùng sai nhất khi báo cáo hiệu quả của một tổng đài có AI: tỉ lệ cuộc gọi được bot xử lý. Con số đó tăng lên không có nghĩa khách hàng được giúp — nó có thể chỉ có nghĩa là họ đã bỏ cuộc giữa chừng.

Đáp án

D — Ideation và xác định ca sử dụng (ideation and use case identification).

Vì sao đúng

Công ty lập nhóm liên phòng ban để nghĩ ý tưởng, đánh giá tính khả thi và ước tính tác động nghiệp vụ cho vài ca sử dụng — tất cả trước khi đầu tư lớn. Đó là giai đoạn ý tưởng và xác định ca sử dụng.

⚠ Ba việc trong đề:

"BRAINSTORM ứng dụng tiềm năng"
    → ⚠ sinh ý tưởng

"đánh giá TÍNH KHẢ THI"
    → ⚠ có dữ liệu không, có làm
      được không

"ước tính TÁC ĐỘNG NGHIỆP VỤ"
    → ⚠ đáng bao nhiêu tiền
        ↓
    ⚠ Tất cả diễn ra TRƯỚC khi
      đầu tư — đây là giai đoạn ĐẦU

⚠ Vì sao nhóm LIÊN PHÒNG BAN quan trọng:

⚠ Chỉ đội kỹ thuật
    → ⚠ nghĩ ra thứ hay về công nghệ
      mà không ai cần

⚠ Chỉ đội nghiệp vụ
    → ⚠ đề xuất thứ không khả thi

⚠ CẢ HAI
    → ⚠ ý tưởng vừa có giá trị
      vừa làm được

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

"Fine-tuning và tối ưu mô hình"
    → ⚠ giai đoạn KỸ THUẬT, sau này

"Triển khai và mở rộng toàn diện"
    → ⚠ giai đoạn CUỐI

"Mua phần cứng chuyên cho AI"
    → ⚠ đầu tư TRƯỚC khi biết dùng
      làm gì

⚠ Gần trùng với #13915 (lô 146) — đề đó khoá xác định bài toán nghiệp vụ và làm thí điểm là bước đầu tiên. Cùng thông điệp, hoàn toàn nhất quán. Và #13897 (lô 145) về yêu cầu nghiệp vụ.

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

• B (triển khai và mở rộng toàn diện) — phương án gần nhất về mặt "cũng là một giai đoạn thật của dự án", nhưng nó ở cuối lộ trình, còn đề mô tả rõ là trước khi đầu tư.

• A và C — thuộc giai đoạn kỹ thuật sau này.

Ghi nhớ

⚠ Lộ trình áp dụng AI sinh — bảng phải thuộc: | Giai đoạn | Nội dung | |---|---| | ⚠ 1. Ideation, xác định ca sử dụng | ⚠ ý tưởng, khả thi, tác động — đề này | | 2. Đánh giá dữ liệu và rủi ro | ⚠ có dữ liệu không, có được dùng không | | ⚠ 3. Thí điểm nhỏ, đo | ⚠ cần đường cơ sở | | 4. Kỹ thuật: prompt, grounding, tinh chỉnh | | | 5. Quản trị và quy trình | ⚠ SAIF, HITL | | 6. Triển khai và mở rộng | | | 7. Vận hành và cải tiến | ⚠ MLOps |

Từ khoá nhận diện:

"brainstorm, khả thi, ước tính tác động" → ⚠ ideation / use case identification "thí điểm nhỏ rồi mở rộng" → pilot "đo thành công bằng gì" → chỉ số nghiệp vụ "đào tạo, truyền thông, phản hồi" → ⚠ change management

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Dữ liệu cần có sẵn chưa | ⚠ rào cản lớn nhất, kiểm sớm | | Thành công đo bằng con số nào | ⚠ và đường cơ sở hiện tại | | Ai ở nghiệp vụ sẽ dùng | ⚠ không có người dùng thật thì dừng |

Và tiêu chí chọn ca sử dụng đầu tiên đáng theo hơn cả "cái nào ấn tượng nhất": cái nào chứng minh được giá trị nhanh nhất với rủi ro thấp nhất. Một thắng lợi nhỏ nhưng đo được sẽ mở đường cho những dự án lớn hơn nhiều so với một tham vọng thất bại ngay từ đầu.

Đáp án

B — Tổng chi phí của giải pháp, bao gồm phí thuê bao hoặc phí sử dụng.

Vì sao đúng

Tổ chức phi lợi nhuận ngân sách rất hạn hẹp. Với ràng buộc đó, chi phí là yếu tố chi phối lựa chọn, không phải năng lực kỹ thuật cao cấp.

⚠ Vì sao chi phí là ràng buộc chính:

Ngân sách RẤT hạn hẹp
        ↓
    ⚠ Loại bỏ giải pháp doanh nghiệp
      đắt tiền
    ⚠ Loại mô hình lớn nhất
        ↓
    ⚠ Nhưng nhiệm vụ — soạn nháp
      đơn xin tài trợ — KHÔNG đòi
      năng lực cao nhất
        ↓
    → ⚠ giải pháp rẻ vẫn làm tốt

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

"Hỗ trợ hàng chục ngôn ngữ LẬP TRÌNH"
    → ⚠ họ soạn văn bản, không lập trình

"Tính năng MLOps cấp doanh nghiệp"
    → ⚠ tổ chức nhỏ không cần

"Suy luận ĐA PHƯƠNG THỨC phức tạp"
    → ⚠ soạn văn bản không cần

Nhất quán với #13997 (cùng lô) — đề đó về cost-performance trade-off với startup ngân sách hạn chế. Cùng nguyên tắc. Và #13932 (lô 146) về ràng buộc tài nguyên.

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

• C (tính năng MLOps doanh nghiệp) — phương án gần nhất vì đó là tiêu chí thật khi chọn giải pháp AI, nhưng nó không phải ràng buộc của một tổ chức nhỏ chỉ cần soạn văn bản.

• A và D — không liên quan tới nhiệm vụ.

Ghi nhớ

⚠ Ràng buộc chính theo LOẠI TỔ CHỨC — bảng nên thuộc: | Tổ chức | Ràng buộc chính | |---|---| | ⚠ Phi lợi nhuận, doanh nghiệp nhỏ | ⚠ CHI PHÍ, dễ dùng | | Startup | ⚠ chi phí + tốc độ ra sản phẩm | | Doanh nghiệp lớn | ⚠ bảo mật, tuân thủ, tích hợp | | Ngành có quản lý | ⚠ giải thích được, kiểm toán | | Viện nghiên cứu | ⚠ linh hoạt, mã nguồn mở |

Từ khoá nhận diện:

"ngân sách hạn hẹp" → ⚠ chi phí là ràng buộc chính "dữ liệu nhạy cảm, tuân thủ" → bảo mật doanh nghiệp "muốn công nghệ mới nhất" → AI-first "chống khoá chân" → công nghệ mở

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Mức miễn phí có đủ không | ⚠ thử một tháng trước khi trả tiền | | Mô hình nhỏ có đủ tốt không | ⚠ với soạn văn bản, thường là đủ | | Ai đọc lại trước khi nộp | ⚠ bắt buộc |

Và với tổ chức phi lợi nhuận, cách tiết kiệm hiệu quả nhất thường không phải đổi nhà cung cấp mà là viết prompt tốt hơn cho một mô hình nhỏ. Khoảng cách chất lượng giữa prompt sơ sài và prompt có cấu trúc rõ ràng thường lớn hơn khoảng cách giữa hai hạng mô hình.

Đáp án

B — Customer Experience Insights (CX Insights) — trước đây gọi là Conversational Insights.

Vì sao đúng

Ban quản lý muốn tự động phân tích bản ghi hàng nghìn cuộc gọi để tìm xu hướng khiếu nại, hiểu nguyên nhân bất mãn, và theo dõi mức tuân thủ kịch bản của nhân viên — mà không phải nghe từng cuộc. Đó là CX Insights.

⚠ Ba nhu cầu đều là PHÂN TÍCH SAU:

"tìm XU HƯỚNG khiếu nại"
    → ⚠ tổng hợp qua nhiều cuộc gọi

"hiểu NGUYÊN NHÂN bất mãn"
    → ⚠ phân tích cảm xúc và chủ đề

"theo dõi TUÂN THỦ kịch bản"
    → ⚠ kiểm tra chất lượng
        ↓
    ⚠ Tất cả diễn ra SAU cuộc gọi,
      phục vụ QUẢN LÝ

⚠ Ba thành phần, ba đối tượng — nhắc lại:

⚠ Conversational Agents
    → ⚠ KHÁCH HÀNG, trong lúc gọi

⚠ Agent Assist
    → ⚠ NHÂN VIÊN, thời gian thực

⚠ CX Insights
    → ⚠ QUẢN LÝ, SAU cuộc gọi
    → ⚠ ĐỀ NÀY

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

"Agent Assist"
    → ⚠ hỗ trợ nhân viên TRONG cuộc gọi

"Conversational Agents"
    → ⚠ nói chuyện với khách

"Nền tảng CCaaS"
    → ⚠ hạ tầng tổng đài; phân tích
      là MỘT THÀNH PHẦN trên đó

⚠ Đối chiếu #13971 (cùng lô) khoá Agent Assist cho hỗ trợ thời gian thực, và #13990 (cùng lô) khoá CCaaS cho nền tảng. Ba đề, ba cấp/ba đối tượng. Không mâu thuẫn. Và #13871 (lô 145) khoá cả bộ.

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

⚠ Phương án đúng trong bộ đề có lỗi chính tả: ghi "formarly known as" thay vì "formerly known as". Đây là lỗi gõ trong nguồn, không ảnh hưởng tới nghĩa. Khoá đáp án B vẫn ĐÚNG và được giữ nguyên.

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

• C (Agent Assist) — phương án gần nhất và là bẫy chính: cùng bộ giải pháp, cùng làm việc với dữ liệu hội thoại. Nhưng nó hoạt động thời gian thực cho nhân viên, còn đây là phân tích tổng hợp cho quản lý.

• A và D — sai đối tượng hoặc sai cấp.

Ghi nhớ

⚠ Ba thành phần — bảng phải thuộc: | Thành phần | Ai dùng | Khi nào | |---|---|---| | Conversational Agents | ⚠ khách hàng | ⚠ trong cuộc gọi | | Agent Assist | ⚠ nhân viên | ⚠ thời gian thực | | ⚠ CX Insights | ⚠ QUẢN LÝ | ⚠ SAU cuộc gọi |

Từ khoá nhận diện:

"phân tích bản ghi, tìm xu hướng" → ⚠ CX Insights "gợi ý cho nhân viên đang gọi" → Agent Assist "bot trả lời khách" → Conversational Agents "nền tảng tổng đài" → ⚠ CCaaS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chủ đề nào tăng mạnh nhất | ⚠ gửi cho đội sản phẩm, không chỉ tổng đài | | Nhân viên có biết đang bị đo gì không | ⚠ minh bạch | | PII trong bản ghi đã che chưa | ⚠ kiểm trước khi chia sẻ báo cáo |

Và giá trị lớn nhất của việc phân tích hội thoại thường xuất hiện ở bộ phận khác: danh sách những chủ đề khách hàng gọi đến nhiều nhất chính là danh sách những chỗ sản phẩm đang gây khó hiểu. Sửa ở đó làm giảm số cuộc gọi hiệu quả hơn bất kỳ cải tiến nào trong khâu trả lời.

Đáp án

A — Hybrid Agent (agent lai).

Vì sao đúng

Kiến trúc kết hợp luồng hội thoại định trước với câu trả lời cố định cho câu hỏi đơn giản, và mô hình ngôn ngữ lớn cho câu hỏi phức tạp — đó là agent lai.

⚠ Vì sao kết hợp là lựa chọn khôn ngoan:

Câu hỏi ĐƠN GIẢN, lặp lại
    "giờ mở cửa?"
        ↓
    ⚠ LUỒNG ĐỊNH TRƯỚC
    → ⚠ chính xác TUYỆT ĐỐI
    → ⚠ nhất quán 100%
    → ⚠ rẻ, nhanh
    → ⚠ không thể bịa

Câu hỏi PHỨC TẠP, mới lạ
        ↓
    ⚠ LLM
    → ⚠ hiểu ý định linh hoạt
    → trả lời tự nhiên
    → ⚠ xử lý được tình huống
      chưa lường trước

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

"Purely Deterministic Agent"
    → ⚠ CHỈ luồng cứng — không xử lý
      được câu hỏi mới

"Purely Generative Agent"
    → ⚠ CHỈ LLM — rủi ro bịa thông
      tin ngay cả với câu hỏi đơn giản

"Unsupervised Agent"
    → ⚠ không phải kiến trúc agent

Đối chiếu #13978 (cùng lô) khoá Workflow Automation Agent cho quy trình hoàn toàn cố định, và #13952 (lô 146) khoá Agent Builder cho agent linh hoạt. Đề này ở giữa hai thái cực. Không mâu thuẫn.

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

• D (thuần xác định) — phương án gần nhất và là bẫy chính: nó đúng cho nửa đầu của mô tả. Nhưng đề nói rõ có cả phần LLM linh hoạt.

• B (thuần sinh) — bỏ mất phần luồng cố định.

• C — không phải kiến trúc agent.

Ghi nhớ

⚠ Ba kiến trúc agent — bảng phải thuộc: | Kiến trúc | Đặc điểm | Rủi ro | |---|---|---| | ⚠ Thuần xác định | ⚠ luồng cứng, câu trả lời cố định | ⚠ cứng nhắc, không xử lý ca mới | | ⚠ Thuần sinh | ⚠ LLM quyết tất cả | ⚠ có thể bịa, khó đoán | | ⚠ HYBRID | ⚠ kết hợp — đề này | ⚠ phức tạp hơn để xây |

Từ khoá nhận diện:

"kết hợp luồng cố định và LLM" → ⚠ hybrid agent "chuỗi bước định trước" → workflow automation "agent tự quyết trình tự" → ⚠ ReAct / reasoning loop "luồng hội thoại chặt chẽ" → Dialogflow CX

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Câu hỏi nào đang rơi vào LLM | ⚠ xem log — có thể chuyển bớt sang luồng cố định | | Luồng cố định có bị lỗi thời không | ⚠ giá và giờ mở cửa thay đổi | | Khách không được giúp thì sao | ⚠ phải có đường sang người |

Và lý do kiến trúc lai thắng thế trong thực tế: không phải mọi câu hỏi đều đáng để một mô hình ngôn ngữ suy nghĩ. Câu hỏi về giờ mở cửa cần một câu trả lời đúng tuyệt đối và rẻ — còn khả năng linh hoạt nên để dành cho những tình huống thật sự cần tới nó.

Đáp án

D — Feature store (hoặc hệ thống quản phiên bản dữ liệu như DVC).

Vì sao đúng

Đội cần quản lý và đánh phiên bản DỮ LIỆU và ĐẶC TRƯNG, để tái lập được kết quả và biết phiên bản tập dữ liệu nào đã tạo ra phiên bản mô hình nào.

⚠ Ba thứ cần quản phiên bản trong ML:

⚠ MÃ NGUỒN
    → Git

⚠ MÔ HÌNH
    → ⚠ Model Registry

⚠ DỮ LIỆU và ĐẶC TRƯNG
    → ⚠ Feature Store, DVC
    → ⚠ ĐỀ NÀY
        ↓
    ⚠ Phải khớp CẢ BA mới tái
      lập được kết quả

⚠ Feature Store làm gì:

⚠ Lưu định nghĩa đặc trưng MỘT LẦN
    → ⚠ dùng chung cho huấn luyện
      và phục vụ
    → ⚠ chống training-serving skew

⚠ Đánh phiên bản đặc trưng
⚠ Lưu giá trị theo THỜI ĐIỂM
    → ⚠ point-in-time correctness
    → ⚠ tránh dùng dữ liệu tương lai
⚠ Chia sẻ giữa các đội

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

"Model monitoring tools"
    → ⚠ phát hiện drift SAU triển khai

"Data ingestion services"
    → ⚠ ĐƯA dữ liệu vào, không quản
      phiên bản

"API deployment gateways"
    → ⚠ triển khai và quản API

⚠ Đối chiếu #13976 (cùng lô) khoá Model Registry — quản phiên bản MÔ HÌNH. Đề này quản phiên bản DỮ LIỆU. Không mâu thuẫn — hai thứ khác nhau, cùng cần thiết cho tái lập.

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

• B (data ingestion services) — phương án gần nhất vì cũng làm việc với dữ liệu trong đường ống ML. Nhưng nạp dữ liệu là đưa vào, không phải quản phiên bản và lineage.

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

Ghi nhớ

⚠ Quản phiên bản trong MLOps — bảng phải thuộc: | Đối tượng | Công cụ | |---|---| | Mã nguồn | ⚠ Git | | ⚠ Dữ liệu, đặc trưng | ⚠ Feature Store, DVC | | ⚠ Mô hình | ⚠ Model Registry | | Lần chạy pipeline | ⚠ Vertex AI Pipelines metadata | | Thử nghiệm | ⚠ Vertex AI Experiments |

Từ khoá nhận diện:

"quản phiên bản dữ liệu, đặc trưng" → ⚠ Feature Store / DVC "quản phiên bản mô hình, quay lui" → Model Registry "phát hiện drift" → Model Monitoring "tự động hoá các bước" → Pipelines

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Mô hình đang chạy dùng dữ liệu phiên bản nào | ⚠ trả lời không được là chưa có quản phiên bản | | Đặc trưng tính ở đâu | ⚠ hai nơi khác nhau là nguy cơ skew | | Dựng lại mô hình cũ mất bao lâu | ⚠ phép thử cho khả năng tái lập |

Và điều làm cho việc quản phiên bản dữ liệu khó hơn quản mã nguồn: dữ liệu quá lớn để chép lại mỗi lần thay đổi. Vì vậy các công cụ trong lĩnh vực này thường lưu tham chiếu và siêu dữ liệu thay vì bản sao — và đó cũng là lý do chúng cần được thiết lập ngay từ đầu dự án chứ không phải khi đã có hàng chục phiên bản mô hình.