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

Đáp án

D — Rò rỉ thông tin định danh cá nhân (PII).

Vì sao đúng

Bác sĩ dán nguyên bản ghi buổi khám — gồm tên, ngày sinh và chẩn đoán — vào dịch vụ AI của bên thứ ba. Đó là rủi ro rò rỉ dữ liệu cá nhân nghiêm trọng.

⚠ Vì sao đây là rủi ro số một:

Dán hồ sơ bệnh nhân vào dịch vụ
BÊN THỨ BA
        ↓
    ⚠ Dữ liệu RỜI KHỎI tổ chức
        ↓
    ⚠ Có thể bị ghi vào LOG
    ⚠ Có thể được dùng huấn luyện
      (tuỳ điều khoản dịch vụ)
    ⚠ Nằm ngoài kiểm soát tuân thủ
        ↓
    ⚠ Vi phạm quy định bảo vệ dữ
      liệu y tế
    ⚠ Xảy ra NGAY LÚC DÁN, không
      cần ai tấn công

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

"Model hallucination"
    → ⚠ rủi ro CHẤT LƯỢNG của bản
      tóm tắt; nghiêm trọng nhưng
      không phải rủi ro RIÊNG TƯ

"Knowledge cutoff"
    → ⚠ không liên quan tới tóm tắt
      văn bản được cung cấp

"Algorithmic bias"
    → ⚠ vấn đề công bằng

Nhất quán với #13872 (lô 145), #13929 (lô 146), #13961 (lô 147) — cả nhóm về bảo vệ dữ liệu nhạy cảm trong AI y tế. Bổ sung nhau.

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

• A (hallucination) — phương án gần nhất và là bẫy hợp lý: tóm tắt sai hồ sơ y tế thật sự nguy hiểm. Nhưng câu hỏi hỏi rõ về rủi ro RIÊNG TƯ, và đó là việc dữ liệu bệnh nhân rời khỏi tổ chức.

• B và C — không phải rủi ro riêng tư trong tình huống này.

Ghi nhớ

⚠ Rủi ro của AI — phân theo loại, bảng phải thuộc: | Loại rủi ro | Ví dụ | |---|---| | ⚠ RIÊNG TƯ | ⚠ PII rời khỏi tổ chức — đề này | | Chất lượng | ⚠ ảo giác, tóm tắt sai | | Công bằng | ⚠ thiên vị giữa các nhóm | | Bảo mật | ⚠ prompt injection, đánh cắp mô hình | | Tuân thủ | ⚠ vi phạm quy định ngành |

Từ khoá nhận diện:

"dán dữ liệu cá nhân vào công cụ ngoài" → ⚠ rò rỉ PII "bịa thông tin" → hallucination "lệch giữa các nhóm" → bias "không biết chuyện mới" → knowledge cutoff

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhân viên đang dùng công cụ AI nào | ⚠ kiểm kê thực tế | | Có công cụ nội bộ được duyệt chưa | ⚠ nếu chưa thì cấm cũng vô ích | | Nhân viên có biết vì sao đây là rủi ro không | ⚠ đào tạo |

Và cách hiệu quả nhất để giảm rủi ro loại này không phải là một chính sách cấm đoán chặt hơn: hãy cung cấp một công cụ nội bộ tiện tới mức không ai cần đi đường vòng. Nhân viên dán dữ liệu vào công cụ ngoài vì họ đang cố làm tốt công việc — và đó là nhu cầu nên được đáp ứng thay vì chỉ bị chặn.

Đáp án

B — Cloud Run functions.

Vì sao đúng

Agent cần kích hoạt logic backend nhẹ, theo sự kiện: gọi API của đơn vị vận chuyển và trả về trạng thái theo thời gian thực. Đó là bài toán của Cloud Run functions.

⚠ Ba dữ kiện khớp:

"logic NHẸ, theo SỰ KIỆN"
    → ⚠ chạy khi có yêu cầu, xong
      thì thôi

"gọi API bên vận chuyển"
    → ⚠ một hàm nhỏ, ít mã

"trong LUỒNG AGENT"
    → ⚠ agent gọi hàm này như một
      TOOL
        ↓
    → ⚠ serverless, trả tiền theo
      lần chạy

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

"Vertex AI Search"
    → ⚠ TÌM trong tài liệu; ⚠ không
      gọi được API bên ngoài

"Cloud Storage"
    → ⚠ lưu tệp

"Prompt Engineering"
    → ⚠ kỹ thuật viết câu lệnh,
      không phải dịch vụ chạy mã

Nhất quán với #13530 (lô 144) — đề đó khoá Cloud Functions cho script nhẹ chạy theo lịch. Và #13938 (lô 146) về tool của agent. Đề này kết hợp cả hai: hàm serverless làm tool cho agent. Bổ sung nhau.

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

• D (Vertex AI Search) — phương án gần nhất và là bẫy chính: nó cũng là thành phần trong agent. Nhưng nó tra tài liệu tĩnh, còn đây cần gọi API lấy dữ liệu thời gian thực.

• C và A — không phải dịch vụ chạy logic.

Ghi nhớ

⚠ Thành phần trong luồng agent — bảng phải thuộc: | Thành phần | Việc | |---|---| | ⚠ Cloud Run functions | ⚠ chạy logic, gọi API ngoài | | Vertex AI Search / data store | ⚠ ĐỌC tài liệu | | Agent Builder | ⚠ điều phối agent | | Gemini API | ⚠ suy luận, sinh câu trả lời | | Cloud Storage | ⚠ lưu tệp |

Từ khoá nhận diện:

"logic nhẹ, theo sự kiện, gọi API" → ⚠ Cloud Run functions "tra tài liệu nội bộ" → Vertex AI Search "container, tự co giãn, trả theo request" → ⚠ Cloud Run "cần kiểm soát cụm" → GKE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có xác thực khách trước khi tra không | ⚠ bắt buộc | | API vận chuyển lỗi thì agent nói gì | ⚠ thử ngắt API | | Hàm có quyền tối thiểu không | ⚠ chỉ đọc, chỉ đơn của khách đó |

Và ranh giới hữu ích khi thiết kế agent: dữ liệu tĩnh thì dùng grounding, dữ liệu động thì dùng tool. Chính sách đổi trả nằm trong tài liệu và hiếm khi đổi; còn vị trí gói hàng thì thay đổi từng giờ và chỉ hệ thống vận chuyển mới biết.

Đáp án

B — Nền tảng thống nhất cho phép tích hợp liền mạch và chia sẻ dữ liệu trên mọi điểm chạm với khách hàng.

Vì sao đúng

Công ty cần ba năng lực hoạt động ĂN KHỚP với nhau, chứ không phải như những công cụ rời rạc. Lợi thế của cách tiếp cận tích hợp chính là nền tảng thống nhất và dữ liệu chảy xuyên suốt.

⚠ Vì sao tích hợp tạo khác biệt:

Ba công cụ RỜI RẠC
        ↓
    ⚠ Bot không biết khách đã gọi
      hôm qua
    ⚠ Nhân viên không thấy khách
      đã nói gì với bot
    ⚠ Phân tích không gộp được
      dữ liệu từ hai kênh
        ↓
⚠ NỀN TẢNG THỐNG NHẤT
        ↓
    ⚠ Ngữ cảnh chuyển liền mạch
      bot → người
    ⚠ Phân tích trên TOÀN BỘ
      hành trình khách hàng
    ⚠ Cải thiện ở một chỗ, cả hệ
      cùng tốt lên

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

"Chi phí mỗi giao dịch thấp hơn
 nhờ chiết khấu theo lượng"
    → ⚠ có thể có, nhưng KHÔNG phải
      lợi thế CHÍNH

"Triển khai nhanh hơn nhờ template
 dựng sẵn"
    → ⚠ tiện, nhưng không phải điều
      đề nhấn mạnh

"Tiếp cận mô hình AI tiên tiến hơn"
    → ⚠ mô hình giống nhau dù dùng
      riêng lẻ hay tích hợp

⚠ Gần trùng với #13871 (lô 145) — đề đó khoá Customer Engagement Suite khi liệt kê ba năng lực. Đề này hỏi LỢI THẾ của việc tích hợp. Bổ sung nhau, hoàn toàn nhất quán.

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

• C (triển khai nhanh nhờ template) — phương án gần nhất về mặt "cũng là lợi ích thật của giải pháp đóng gói", nhưng đề nhấn mạnh rõ "hoạt động ăn khớp thay vì rời rạc".

• A và D — không phải lợi thế của tích hợp.

Ghi nhớ

⚠ Lợi ích của nền tảng thống nhất — bảng nên thuộc: | Lợi ích | Nội dung | |---|---| | ⚠ Ngữ cảnh liền mạch | ⚠ bot → nhân viên không phải kể lại | | ⚠ Dữ liệu chung | ⚠ phân tích trên toàn hành trình | | ⚠ Vòng cải thiện khép kín | ⚠ insight từ phân tích quay lại cải thiện bot | | Quản trị và bảo mật tập trung | | | Một nhà cung cấp, một hợp đồng | | | Đánh đổi | ⚠ phụ thuộc một nền tảng nhiều hơn |

Từ khoá nhận diện:

"ăn khớp, chia sẻ dữ liệu, thống nhất" → ⚠ lợi thế nền tảng tích hợp "ba năng lực chăm sóc khách hàng" → Customer Engagement Suite "hạ tầng tổng đài" → CCaaS "hỗ trợ nhân viên thời gian thực" → Agent Assist

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khách chuyển sang người có phải kể lại không | ⚠ gọi thử thật | | Phân tích có gộp được dữ liệu bot và người không | ⚠ kiểm dashboard | | Insight có quay lại cải thiện bot không | ⚠ vòng khép kín có thật hay không |

Và phép thử đơn giản nhất cho mức độ tích hợp thật của một hệ thống chăm sóc khách hàng: gọi thử, nói chuyện với bot, rồi yêu cầu chuyển sang người. Nếu phải kể lại từ đầu, thì dù kiến trúc trên giấy có liền mạch tới đâu, trải nghiệm thực tế vẫn là ba công cụ rời rạc.

Đáp án

D — Data Ingestion (nạp dữ liệu).

Vì sao đúng

Hoạt động là thu thập dữ liệu cảm biến THÔ từ thiết bị IoT và đưa thẳng vào kho lưu trữ đám mây, đảm bảo mọi điểm dữ liệu được ghi nhận TRƯỚC KHI bất kỳ việc làm sạch hay biến đổi nào bắt đầu. Đó là nạp dữ liệu.

⚠ Từ khoá quyết định:

"dữ liệu THÔ"
    → ⚠ chưa xử lý gì

"đưa THẲNG vào kho lưu trữ"
    → ⚠ chưa biến đổi

"TRƯỚC KHI làm sạch hay biến đổi
 bắt đầu"
    → ⚠ đề nói RÕ là trước
      Data Preparation
        ↓
    → ⚠ DATA INGESTION

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

"Data Preparation"
    → ⚠ làm sạch, biến đổi — đề nói
      RÕ là CHƯA tới bước này

"Model Training"
    → ⚠ huấn luyện, ở sau nữa

"Model Deployment"
    → ⚠ tận cuối vòng đời

⚠ Đối chiếu #13898 (lô 145) — đề đó khoá Data Preparation vì đã có dữ liệu thô và đang làm sạch, xử lý giá trị thiếu. Đề này là bước TRƯỚC ĐÓ. KHÔNG mâu thuẫn — hai giai đoạn liền kề, phân biệt bằng đã bắt đầu xử lý hay chưa.

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

• C (Data Preparation) — phương án gần nhất và là bẫy chính: hai giai đoạn nằm sát nhau. Nhưng đề nêu tường minh rằng việc làm sạch chưa bắt đầu.

• A và B — nằm xa hơn trong vòng đời.

Ghi nhớ

⚠ Vòng đời ML — bảng phải thuộc: | Giai đoạn | Việc | |---|---| | ⚠ Data Ingestion | ⚠ thu thập, đưa dữ liệu THÔ vào — đề này | | ⚠ Data Preparation | ⚠ làm sạch, biến đổi, tạo đặc trưng | | Model Training | huấn luyện | | Model Evaluation | ⚠ đo chất lượng | | Model Deployment | đưa ra phục vụ | | Model Management | ⚠ giám sát, huấn luyện lại |

Từ khoá nhận diện:

"thu thập dữ liệu thô, chưa xử lý" → ⚠ Data Ingestion "làm sạch, xử lý giá trị thiếu" → Data Preparation "đo chỉ số trên tập test" → Evaluation "đưa ra dùng qua API" → Deployment

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu thô có được giữ nguyên không | ⚠ để chạy lại được | | Bản ghi hỏng đi đâu | ⚠ phải có dead-letter | | Chi phí lưu trữ tăng thế nào | ⚠ đặt lifecycle policy sớm |

Và nguyên tắc đáng giữ ở khâu nạp dữ liệu, đặc biệt với cảm biến: lưu bản thô trước, xử lý sau. Logic làm sạch có thể viết lại bất cứ lúc nào, nhưng một chuỗi số liệu cảm biến đã bị lọc bỏ ngay lúc nạp thì không có cách nào lấy lại.

Đáp án

D — Chain-of-thought prompting.

Vì sao đúng

Nhà phân tích thêm chỉ dẫn "trình bày cách làm và giải thích từng bước trước khi đưa ra đáp án cuối". Yêu cầu mô hình trình bày quá trình lập luận chính là chain-of-thought.

⚠ Vì sao CoT giúp bài toán nhiều bước:

Hỏi thẳng đáp án
    → ⚠ mô hình nhảy tới kết quả
    → ⚠ bài nhiều bước dễ sai

⚠ Yêu cầu TRÌNH BÀY TỪNG BƯỚC
    → ⚠ mỗi bước ĐƠN GIẢN hơn
    → ⚠ mô hình dùng chính kết quả
      bước trước cho bước sau
    → ⚠ và NGƯỜI kiểm được sai ở đâu

⚠ Đây là zero-shot CoT:

⚠ FEW-SHOT CoT
    → đưa VÍ DỤ có lời giải từng bước

⚠ ZERO-SHOT CoT
    → ⚠ chỉ THÊM MỘT CÂU chỉ dẫn
    → ⚠ "hãy suy luận từng bước"
    → ⚠ ĐỀ NÀY
        ↓
    ⚠ Đơn giản đến bất ngờ mà
      hiệu quả rõ rệt

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

"Few-shot prompting"
    → ⚠ cần VÍ DỤ MẪU — không có

"ReAct prompting"
    → ⚠ suy luận XEN KẼ GỌI CÔNG CỤ
    → ⚠ ở đây không có công cụ nào

"Prompt chaining"
    → ⚠ NHIỀU lời gọi nối tiếp;
      ở đây chỉ MỘT lời gọi

⚠ Gần trùng với #13905 (lô 146) — đề đó là few-shot CoT (có ví dụ kèm lời giải), đề này là zero-shot CoT (chỉ thêm chỉ dẫn). Cùng khoá chain-of-thought, hoàn toàn nhất quán. Đối chiếu #13944/#14004 về ReAct.

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

• A (ReAct) — phương án gần nhất và là bẫy chính: ReAct có bao gồm phần suy luận. Nhưng nó đòi gọi công cụ bên ngoài, mà ở đây mô hình chỉ tự suy luận.

• B và C — không khớp dấu hiệu trong prompt.

Ghi nhớ

⚠ Kỹ thuật prompt — nhận diện qua dấu hiệu, bảng phải thuộc: | Dấu hiệu | Kỹ thuật | |---|---| | ⚠ "Suy luận từng bước" | ⚠ zero-shot CoT — đề này | | ⚠ Ví dụ CÓ lời giải từng bước | ⚠ few-shot CoT | | Ví dụ chỉ có đáp án | ⚠ few-shot | | ⚠ Suy luận + GỌI CÔNG CỤ | ⚠ ReAct | | Nhiều lời gọi nối tiếp | ⚠ prompt chaining | | "Bạn là..." | role prompting |

Từ khoá nhận diện:

"trình bày từng bước, giải thích cách làm" → ⚠ chain-of-thought "gọi công cụ giữa các bước suy luận" → ReAct "đầu ra bước này là đầu vào bước sau" → prompt chaining "đưa ví dụ mẫu" → few-shot

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

Và điều bất ngờ nhất về kỹ thuật này: thêm đúng một câu vào prompt có thể cải thiện đáng kể độ chính xác trên bài toán nhiều bước. Nó gần như miễn phí để thử — và nên là việc đầu tiên làm khi mô hình trả lời sai những câu hỏi cần tính toán.

Đáp án

B, C và F — ⚠ câu chọn BA đáp án:

• B — Giảm ảo giác bằng cách neo câu trả lời vào dữ liệu doanh nghiệp đã được xác minh.
• C — Cho phép dùng dữ liệu độc quyền mà KHÔNG cần huấn luyện lại hay tinh chỉnh mô hình.
• F — Cho phép truy cập thông tin HIỆN HÀNH, vượt qua mốc cắt kiến thức của mô hình.

Vì sao đúng

Ba lợi ích này là ba lý do cốt lõi khiến doanh nghiệp dùng RAG.

⚠ Ba lợi ích, ba vấn đề được giải:

⚠ B — GIẢM ẢO GIÁC
    → mô hình trả lời DỰA TRÊN
      tài liệu, không tự bịa
    → ⚠ và TRÍCH DẪN được nguồn

⚠ C — DÙNG DỮ LIỆU RIÊNG mà
     KHÔNG huấn luyện lại
    → ⚠ cập nhật tài liệu là xong
    → ⚠ rẻ hơn fine-tuning rất nhiều

⚠ F — VƯỢT KNOWLEDGE CUTOFF
    → thông tin mới thêm vào kho
      là dùng được ngay

⚠ Vì sao ba phương án còn lại sai:

"GIẢM chi phí tính toán so với
 suy luận thường"
    → ⚠ NGƯỢC: RAG THÊM bước tra
      cứu và prompt DÀI hơn
    → ⚠ thường TỐN HƠN một chút

"TỰ ĐỘNG kiểm chứng và SỬA mọi
 đầu ra cho chính xác"
    → ⚠ RAG KHÔNG kiểm chứng gì cả
    → ⚠ nó chỉ CUNG CẤP tài liệu
    → ⚠ vẫn cần người kiểm

"LOẠI BỎ nhu cầu prompt engineering"
    → ⚠ NGƯỢC: RAG vẫn CẦN prompt tốt
    → ⚠ đặc biệt là chỉ dẫn "chỉ
      dùng thông tin được cung cấp"

Nhất quán với #13900 và #13951 (lô 145, 146) về cơ chế RAG, và #14018 (cùng lô) về giới hạn của RAG. Bổ sung nhau.

Ghi nhớ về dạng câu hỏi

⚠ Đây là câu chọn NHIỀU đáp án (chọn 3 trong 6). Với dạng này:

• ⚠ Đọc kỹ số lượng cần chọn — chọn thiếu hoặc thừa đều sai
• ⚠ Loại phương án SAI RÕ trước — thường có 1–2 phương án nói ngược
• ⚠ Cảnh giác từ tuyệt đối — "tự động MỌI", "LOẠI BỎ hoàn toàn" thường sai

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

• D (tự động kiểm chứng mọi đầu ra) — phương án gần nhất bị chọn nhầm vì nghe như hệ quả của RAG. Nhưng RAG cung cấp ngữ cảnh, không kiểm chứng gì.

• A và E — đều nói ngược thực tế.

Ghi nhớ

⚠ RAG — được gì và KHÔNG được gì: | ĐƯỢC | KHÔNG ĐƯỢC | |---|---| | ⚠ Giảm ảo giác về SỰ KIỆN | ⚠ không giảm chi phí — thường tăng | | ⚠ Dùng dữ liệu riêng, không huấn luyện lại | ⚠ không tự kiểm chứng đầu ra | | ⚠ Vượt knowledge cutoff | ⚠ không thay thế prompt engineering | | ⚠ Trích dẫn được nguồn | ⚠ không sửa được thiên vị | | Lọc theo quyền truy cập | ⚠ không sửa được lỗi trong tài liệu nguồn |

Từ khoá nhận diện:

"giảm ảo giác, dùng dữ liệu riêng, thông tin mới" → ⚠ ba lợi ích RAG "giảm chi phí" → ⚠ KHÔNG phải lợi ích của RAG "phong cách, giọng văn" → fine-tuning "brainstorm sáng tạo" → ⚠ RAG ít giá trị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trích dẫn nguồn không | ⚠ lợi ích chính, phải có | | Tài liệu cũ đã gỡ chưa | ⚠ nguồn trả lời sai số một | | Chi phí tăng bao nhiêu | ⚠ prompt dài hơn |

Và điều dễ bị hiểu nhầm nhất về RAG: nó không kiểm chứng gì cả. Nó chỉ đặt tài liệu vào trước mặt mô hình — còn việc mô hình dùng tài liệu đó đúng hay không thì vẫn cần trích dẫn để người đọc tự kiểm.

Đáp án

A — Agents: phần AI học hỏi và ra quyết định để giúp khách hàng.

Vì sao đúng

Đề hỏi thành phần HỌC HỎI và TỰ RA QUYẾT ĐỊNH để đạt mục tiêu chăm sóc khách hàng. Trong bốn thứ được liệt kê, đó là chatbot AI có khả năng học và quyết định — tức agent.

⚠ Ánh xạ bốn thứ trong đề:

"chatbot AI HỌC và RA QUYẾT ĐỊNH"
    → ⚠ AGENTS — đề hỏi cái này

"mô hình huấn luyện sẵn cho phân
 tích văn bản"
    → ⚠ MODELS

"hạ tầng đám mây chạy hệ thống AI"
    → ⚠ INFRASTRUCTURE

"giao diện ứng dụng di động"
    → ⚠ APPLICATIONS

⚠ Điều làm nên một AGENT:

⚠ Có MỤC TIÊU
⚠ TỰ QUYẾT trình tự hành động
⚠ Dùng CÔNG CỤ để lấy dữ liệu
  hoặc hành động
⚠ LẶP cho tới khi đạt mục tiêu
⚠ Học từ tương tác
        ↓
    ⚠ Khác chatbot một lượt và
      khác mô hình thuần

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

"Models"
    → ⚠ năng lực NỀN; mô hình
      KHÔNG tự quyết trình tự

"Applications"
    → ⚠ giao diện người dùng cuối

"Infrastructure"
    → ⚠ phần cứng bên dưới

⚠ Đối chiếu #13878 (Application), #13899 (Models), #13948 (Infrastructure), #14029 (Platforms) — bốn đề về khung bốn tầng cổ điển. Đề này bổ sung AGENTS như một thành phần riêng. Không mâu thuẫn — agent nằm ở tầng ứng dụng nhưng có đặc trưng riêng đáng gọi tên.

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

• C (Applications) — phương án gần nhất và là bẫy tinh tế: agent thật sự chạy trong một ứng dụng. Nhưng phương án C mô tả giao diện di động, còn đề hỏi phần học và ra quyết định.

• B và D — nằm ở tầng khác.

Ghi nhớ

⚠ Các thành phần trong bối cảnh AI sinh — bảng phải thuộc: | Thành phần | Vai trò | |---|---| | Infrastructure | ⚠ phần cứng: TPU, GPU | | Models | ⚠ năng lực AI nền | | Platforms | ⚠ công cụ xây và vận hành | | ⚠ Agents | ⚠ HỌC, QUYẾT ĐỊNH, HÀNH ĐỘNG | | Applications | ⚠ giao diện người dùng cuối |

Từ khoá nhận diện:

"học, tự quyết định, đạt mục tiêu" → ⚠ agent "mô hình huấn luyện sẵn" → model "giao diện người dùng bấm vào" → application "chip, máy chủ" → infrastructure

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Nó có tự quyết trình tự không | ⚠ có → agent | | Nó có gọi công cụ không | ⚠ có → agent | | Nó có mục tiêu nhiều bước không | ⚠ có → agent; không → chatbot đơn giản |

Và điều phân biệt một agent thật với một chatbot được gọi là agent: khả năng tự quyết định bước tiếp theo và dùng công cụ để thực hiện nó. Nếu hệ thống chỉ nhận câu hỏi và trả câu trả lời trong một lượt, thì dù giao diện có giống tới đâu, đó vẫn chưa phải agent.

Đáp án

C — Giảm phụ thuộc vào kết nối internet cho hoạt động vận hành.

Vì sao đúng

Chuỗi bán lẻ có cửa hàng ở nhiều nơi. Xử lý tại chỗ (edge) nghĩa là hệ thống vẫn chạy khi mất mạng — lợi thế nghiệp vụ then chốt cho hoạt động cửa hàng.

⚠ Vì sao độc lập với mạng quan trọng với bán lẻ:

Cửa hàng mất kết nối
        ↓
    ⚠ Với AI trên đám mây:
      hệ thống kiểm kê NGỪNG
        ↓
    ⚠ Với AI tại biên:
      VẪN CHẠY bình thường
        ↓
    → ⚠ cửa hàng không phụ thuộc
      vào chất lượng đường truyền

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

"Tiếp cận mô hình MẠNH HƠN"
    → ⚠ NGƯỢC: thiết bị biên có
      tài nguyên HẠN CHẾ, thường
      chạy mô hình NHỎ hơn

"TỔNG chi phí sở hữu THẤP HƠN
 theo thời gian"
    → ⚠ đề nói RÕ chi phí ban đầu
      CAO HƠN; TCO thì tuỳ, không
      chắc chắn

"Dễ tích hợp với hệ thống đám mây
 sẵn có"
    → ⚠ NGƯỢC: xử lý tại biên
      thường PHỨC TẠP hơn khi tích hợp

Nhất quán với #13906 (lô 146) — đề đó khoá Gemma cho nhu cầu chạy mô hình tại chỗ. Cùng nguyên tắc: xử lý cục bộ khi không muốn phụ thuộc kết nối.

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

• B (TCO thấp hơn) — phương án gần nhất và là bẫy chính: đề có nhắc tới giảm chi phí kết nối liên tục. Nhưng nó cũng nói chi phí ban đầu cao hơn, nên TCO thấp hơn không chắc chắn — còn tính độc lập với mạng thì chắc chắn.

• A và D — nói ngược đặc điểm của edge.

Ghi nhớ

⚠ Edge AI và Cloud AI — bảng phải thuộc: | | ⚠ Edge AI | ⚠ Cloud AI | |---|---|---| | ⚠ Phụ thuộc mạng | ⚠ THẤP — điểm mạnh chính | ⚠ cao | | Độ trễ | ⚠ rất thấp | phụ thuộc mạng | | Sức mạnh mô hình | ⚠ hạn chế | ⚠ cao nhất | | ⚠ Quyền riêng tư | ⚠ dữ liệu KHÔNG rời cửa hàng | dữ liệu gửi đi | | Chi phí ban đầu | ⚠ cao | thấp | | Cập nhật mô hình | ⚠ phức tạp — nhiều thiết bị | ⚠ dễ, một chỗ |

Từ khoá nhận diện:

"không phụ thuộc mạng, xử lý tại chỗ" → ⚠ edge AI "mô hình mạnh nhất, co giãn" → cloud AI "dữ liệu không được rời khỏi nơi phát sinh" → ⚠ edge "mô hình mở chạy tại chỗ" → Gemma

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Mất mạng thì cửa hàng có chạy được không | ⚠ lợi ích chính của edge | | Cập nhật mô hình cho hàng trăm cửa hàng thế nào | ⚠ thách thức lớn nhất | | Mô hình nhỏ có đủ chính xác không | ⚠ thử trước ở vài cửa hàng |

Và thách thức vận hành thật của edge AI không nằm ở lúc triển khai mà ở về sau: cập nhật mô hình cho hàng trăm thiết bị nằm rải rác. Đó là bài toán quản lý phiên bản ở quy mô vật lý, và nên được thiết kế trước khi thiết bị đầu tiên được lắp đặt.

Đáp án

C — Vertex AI RAG Engine.

Vì sao đúng

Hãng tư vấn cần câu trả lời chính xác, cập nhật, dựa trên báo cáo nghiên cứu và tài liệu độc quyền lưu trong cơ sở dữ liệu riêng, nhằm giảm ảo giác bằng cách neo vào nội dung tin cậy. Đó chính là RAG.

⚠ Ba dữ kiện chỉ thẳng vào RAG:

"tài liệu ĐỘC QUYỀN trong CSDL riêng"
    → ⚠ dữ liệu first-party

"GIẢM ẢO GIÁC"
    → ⚠ mục tiêu chính của RAG

"NEO câu trả lời vào nội dung
 tin cậy"
    → ⚠ đúng định nghĩa grounding

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

"Pre-training mô hình nền TỪ ĐẦU"
    → ⚠ cực kỳ tốn kém, hoàn toàn
      không cần thiết

"Chain-of-thought prompting"
    → ⚠ giúp SUY LUẬN từng bước,
      ⚠ KHÔNG cung cấp kiến thức mới

"Prompt Tuning"
    → ⚠ tuỳ biến PHONG CÁCH, không
      giải quyết thiếu kiến thức

⚠ Gần trùng với #14023 (cùng lô) — đề đó cũng là hãng tư vấn muốn AI chỉ dùng tài liệu nội bộ, cùng hướng khoá RAG. Và #13902 (lô 145), #13913 (lô 146). Hoàn toàn nhất quán.

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

• D (prompt tuning) — phương án gần nhất và là bẫy tinh tế: cũng là cách tuỳ biến mô hình cho nhu cầu riêng. Nhưng nó dạy PHONG CÁCH, còn vấn đề ở đây là thiếu KIẾN THỨC.

• B và A — không giải quyết vấn đề hoặc quá tốn kém.

Ghi nhớ

⚠ Chọn kỹ thuật theo VẤN ĐỀ — bảng phải thuộc: | Vấn đề | Kỹ thuật | |---|---| | ⚠ Thiếu KIẾN THỨC riêng, cập nhật | ⚠ RAG / grounding | | Thiếu PHONG CÁCH, định dạng | ⚠ fine-tuning, prompt tuning | | Suy luận nhiều bước sai | ⚠ chain-of-thought | | Cần gọi hệ thống ngoài | ⚠ function calling | | Định dạng đầu ra chưa đúng | ⚠ prompt engineering, few-shot |

Từ khoá nhận diện:

"giảm ảo giác, neo vào tài liệu tin cậy" → ⚠ RAG "giọng văn, thuật ngữ riêng" → fine-tuning / prompt tuning "suy luận từng bước" → chain-of-thought "gọi API lấy dữ liệu động" → function calling

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trích dẫn nguồn không | ⚠ bắt buộc với tư vấn | | Tài liệu khách A có lộ sang khách B không | ⚠ kiểm phân vùng | | Hỏi ngoài kho tài liệu thì sao | ⚠ phải nói không biết |

Và câu hỏi phân biệt nhanh giữa RAG và các kỹ thuật tuỳ biến khác: vấn đề là mô hình KHÔNG BIẾT hay NÓI KHÔNG ĐÚNG GIỌNG? Vế đầu cần grounding, vế sau cần tinh chỉnh — và nhầm lẫn giữa hai vế này dẫn tới những dự án tốn kém mà không giải quyết được vấn đề thật.

Đáp án

D — Theo dõi các chỉ số hiệu quả chính (KPI) như thời gian xử lý trung bình và tỉ lệ giải quyết ngay lần đầu.

Vì sao đúng

Để chứng minh giá trị nghiệp vụ cho ban lãnh đạo, cần chỉ số đo KẾT QUẢ, không phải chỉ số đo hoạt động của công cụ.

⚠ Phân biệt chỉ số hoạt động và chỉ số kết quả:

⚠ CHỈ SỐ HOẠT ĐỘNG (vanity)
    → "AI đã soạn 50.000 câu trả lời"
    → "xử lý 2 triệu token/ngày"
    → ⚠ CHỨNG MINH công cụ ĐANG CHẠY
    → ⚠ KHÔNG chứng minh nó CÓ ÍCH

⚠ CHỈ SỐ KẾT QUẢ (KPI)
    → ⚠ thời gian xử lý trung bình
    → ⚠ tỉ lệ giải quyết ngay lần đầu
    → ⚠ quy đổi ra TIỀN và CHẤT LƯỢNG

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

"Tổng số câu trả lời AI đã soạn"
    → ⚠ chỉ số hoạt động; nhiều
      không có nghĩa là tốt

"Số TOKEN xử lý mỗi ngày"
    → ⚠ chỉ số KỸ THUẬT, còn là
      chỉ số CHI PHÍ

"Khảo sát đội phát triển về độ
 khó triển khai"
    → ⚠ nói về quá trình làm, không
      nói về giá trị tạo ra

⚠ Gần trùng với #13894 (lô 145) và #13980 (lô 147) — cả ba đều về chọn chỉ số trực tiếp đo tác động. Hoàn toàn nhất quán.

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

• A (tổng số câu trả lời đã soạn) — phương án gần nhất và là bẫy chính: nó dễ đo và nghe ấn tượng. Nhưng nó chỉ cho biết công cụ được dùng, không cho biết nó có giúp gì.

• B và C — đo chi phí và quá trình, không đo giá trị.

Ghi nhớ

⚠ Chỉ số cho trợ lý soạn thảo trong tổng đài — bảng nên thuộc: | Chỉ số | Loại | |---|---| | ⚠ Thời gian xử lý trung bình | ⚠ KPI kết quả | | ⚠ Tỉ lệ giải quyết ngay lần đầu | ⚠ KPI kết quả — quan trọng nhất | | CSAT | ⚠ KPI trải nghiệm | | Tỉ lệ nhân viên dùng gợi ý | ⚠ chỉ số áp dụng | | Số câu trả lời đã soạn | ⚠ chỉ số hoạt động — yếu | | Số token/ngày | ⚠ chỉ số CHI PHÍ |

Từ khoá nhận diện:

"chứng minh giá trị nghiệp vụ" → ⚠ KPI kết quả "số lượt dùng, số token" → ⚠ chỉ số hoạt động — không đủ "đường cơ sở trước và sau" → ⚠ điều kiện để so sánh "nhóm đối chứng" → ⚠ cách chứng minh nhân quả

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có đường cơ sở trước không | ⚠ thiếu thì mọi so sánh đều tranh cãi được | | Chất lượng có giảm không | ⚠ đo cùng lúc với tốc độ | | Đã trừ chi phí AI chưa | ⚠ để ra giá trị ròng |

Và câu hỏi mà ban lãnh đạo sẽ hỏi sau mọi con số ấn tượng về số lượng: "vậy điều đó tiết kiệm được bao nhiêu?". Chỉ những chỉ số quy đổi được ra thời gian hoặc tiền mới trả lời được câu đó — và chúng cần được đo từ trước ngày triển khai.