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

Đáp án

B — Việc tích hợp AI sinh xuyên suốt các sản phẩm và dịch vụ sẵn có của Google, tạo thành một hệ sinh thái toàn diện.

Vì sao đúng

Doanh nghiệp này đã đầu tư vào Workspace, Google Cloud và BigQuery. Giá trị lớn nhất với họ là AI hoạt động xuyên suốt những thứ đó chứ không phải một công cụ AI rời rạc.

⚠ Kịch bản mà đề mô tả:

⚠ Dữ liệu trong BigQuery
        ↓
    ⚠ Gemini trong Google Docs
      dùng được dữ liệu đó để
      soạn nội dung
        ↓
    ⚠ Sự kiện trên Google Cloud
      kích hoạt tác vụ tự động
        ↓
    → ⚠ MỘT hệ sinh thái, không
      phải nhiều công cụ rời rạc

⚠ Vì sao tích hợp quan trọng hơn tính năng lẻ:

Công cụ AI rời rạc
        ↓
    ⚠ phải tự nối dữ liệu
    ⚠ danh tính và quyền quản riêng
    ⚠ dữ liệu bị sao chép ra ngoài
    ⚠ mỗi công cụ một hợp đồng
        ↓
    ⚠ Tích hợp sẵn
        ↓
    ⚠ dùng chung IAM và quyền
    ⚠ dữ liệu KHÔNG phải di chuyển
    ⚠ một mô hình quản trị

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

"Chi phí thấp cho từng lời gọi API"
    → ⚠ có ích, nhưng không phải
      lợi thế cho tình huống này

"Có sẵn các giải pháp AI ĐỘC LẬP,
 chuyên biệt"
    → ⚠ NGƯỢC với ý "gắn kết"

"Google dẫn đầu về công bố mô hình
 mã nguồn mở"
    → ⚠ liên quan tới chống khoá
      chân, không phải tích hợp

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

• D (dẫn đầu về mã nguồn mở) — phương án gần nhất vì đúng là một điểm mạnh thật của Google, nhưng nó trả lời cho mối lo khoá chân, không phải nhu cầu gắn kết hệ sinh thái.

• A (chi phí API thấp) và C (giải pháp độc lập) — không khớp với điều đề nhấn mạnh.

Ghi nhớ

⚠ AI sinh trong hệ sinh thái Google — bảng nên thuộc: | Nơi | Khả năng | |---|---| | ⚠ Gemini trong Workspace | ⚠ Docs, Gmail, Sheets, Slides, Meet | | ⚠ BigQuery + Gemini | ⚠ sinh SQL, phân tích bằng ngôn ngữ tự nhiên | | Looker + Gemini | ⚠ hỏi dữ liệu bằng lời | | Gemini Code Assist | ⚠ hỗ trợ viết mã | | Gemini trong Console | ⚠ hỗ trợ vận hành | | Vertex AI | ⚠ nền tảng xây ứng dụng riêng | | Agent Builder, AI Search | ⚠ agent và tìm kiếm doanh nghiệp |

Từ khoá nhận diện:

"gắn kết, xuyên suốt sản phẩm sẵn có" → ⚠ hệ sinh thái tích hợp "chống khoá chân" → công nghệ mở "quản trị rủi ro AI" → SAIF "bảo mật, riêng tư, co giãn" → tính năng doanh nghiệp

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Quyền truy cập tài liệu có chặt không | ⚠ rà TRƯỚC khi bật AI | | Dữ liệu có phải rời khỏi hệ thống không | ⚠ tích hợp thì không | | Ai được bật tính năng nào | ⚠ triển khai theo nhóm, không bật đồng loạt |

Và tác dụng phụ ít được nói tới khi bật AI trên toàn bộ kho tài liệu nội bộ: nó phơi bày chất lượng phân quyền hiện có của tổ chức. Những tài liệu chia sẻ quá rộng vốn nằm im nhiều năm bỗng trở nên dễ tìm và dễ tổng hợp — nên rà soát quyền là việc nên làm trước, không phải sau.

Đáp án

C — Few-shot prompting.

Vì sao đúng

Prompt đưa ba ví dụ đã có đáp án trước khi hỏi câu thứ tư. Cung cấp một vài ví dụ mẫu ngay trong prompt chính là few-shot prompting.

⚠ Cấu trúc của prompt trong đề:

Ví dụ 1: "sản phẩm tuyệt vời" → Positive
Ví dụ 2: "rất thất vọng"      → Negative
Ví dụ 3: "giao hàng tạm được" → Neutral
        ↓
    ⚠ BA ví dụ = "few shots"
        ↓
Câu hỏi thật: "..." → ?
        ↓
    ⚠ Mô hình học ĐỊNH DẠNG và
      TIÊU CHÍ từ ví dụ

⚠ Phân biệt các kỹ thuật:

⚠ ZERO-SHOT
    → ⚠ KHÔNG ví dụ nào
    → "Phân loại cảm xúc câu sau:"

⚠ ONE-SHOT
    → ⚠ MỘT ví dụ

⚠ FEW-SHOT
    → ⚠ VÀI ví dụ — ĐỀ NÀY

⚠ ROLE PROMPTING
    → ⚠ gán VAI: "bạn là chuyên gia..."

⚠ PROMPT CHAINING
    → ⚠ chia thành NHIỀU LỜI GỌI
      nối tiếp, đầu ra cái này là
      đầu vào cái kia

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

• B (zero-shot) — phương án gần nhất và là bẫy chính: cùng là kỹ thuật prompt cho bài toán phân loại, nhưng zero-shot là khi không có ví dụ nào, còn ở đây có ba.

• D (role prompting) — prompt không gán vai nào cho mô hình.

• A (prompt chaining) — chỉ có một lời gọi, không phải chuỗi.

Ghi nhớ

⚠ Kỹ thuật prompt — bảng phải thuộc: | Kỹ thuật | Đặc điểm | |---|---| | ⚠ Zero-shot | ⚠ không ví dụ | | ⚠ Few-shot | ⚠ vài ví dụ mẫu — đề này | | ⚠ Chain-of-thought | ⚠ "suy luận từng bước" | | Role prompting | ⚠ gán vai cho mô hình | | ⚠ Prompt chaining | ⚠ nhiều lời gọi nối tiếp nhau |

Từ khoá nhận diện:

"đưa vài ví dụ mẫu" → ⚠ few-shot "hỏi thẳng, không ví dụ" → zero-shot "giải thích từng bước" → ⚠ chain-of-thought "bạn là chuyên gia..." → role prompting "chia thành nhiều bước gọi" → ⚠ prompt chaining

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ví dụ có phủ đủ nhãn không | ⚠ thiếu nhãn nào thì mô hình ít chọn nhãn đó | | Định dạng có nhất quán không | ⚠ rất quan trọng | | Prompt mới có tốt hơn thật không | ⚠ đo trên bộ test cố định |

Và thói quen đáng hình thành sớm khi làm việc với prompt: coi prompt như mã nguồn — đặt phiên bản, có bộ test, đo trước khi đổi. Nếu không, việc "cải thiện" prompt chỉ là thay đổi cảm tính, và rất dễ làm hỏng những trường hợp vốn đang chạy tốt.

Đáp án

B — Tensor Processing Unit (TPU) do Google tự thiết kế.

Vì sao đúng

TPU là chip do chính Google thiết kế, tối ưu cho khối lượng công việc học máy — đặc biệt là phép nhân ma trận quy mô lớn chiếm phần lớn thời gian huấn luyện mô hình sinh cỡ lớn.

⚠ Vì sao TPU tăng tốc được:

Huấn luyện mô hình lớn
        ↓
    ⚠ phần lớn thời gian là
      NHÂN MA TRẬN
        ↓
    ⚠ TPU thiết kế riêng cho
      đúng phép tính đó
        ↓
    ⚠ nhanh hơn và tiết kiệm
      năng lượng hơn cho tác vụ này
        ↓
    → ⚠ rút thời gian huấn luyện,
      và do đó GIẢM CHI PHÍ tổng

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

"Cloud Storage"
    → ⚠ LƯU dữ liệu và mô hình —
      cần thiết, nhưng không TĂNG TỐC
      phép tính

"CPU thường trong Compute Engine"
    → ⚠ đa năng, ⚠ quá chậm cho
      mô hình cỡ này

"Mạng lưới trung tâm dữ liệu
 toàn cầu"
    → ⚠ hạ tầng nền, không phải
      bộ tăng tốc chuyên dụng

Nhất quán với #13540 (lô 144) — cùng khoá TPU cho mô hình lớn cần phép tính ma trận. Đề đó nói về nhận diện ảnh, đề này về mô hình sinh. Hoàn toàn nhất quán.

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

• C (CPU thường) — phương án gần nhất vì CPU cũng chạy được việc huấn luyện, nhưng chậm tới mức không khả thi với mô hình cỡ này.

• A (Cloud Storage) và D (mạng trung tâm dữ liệu) — là thành phần hạ tầng cần thiết nhưng không phải bộ tăng tốc.

Ghi nhớ

⚠ Ba loại bộ xử lý — bảng phải thuộc: | Loại | Mạnh ở | Dùng khi | |---|---|---| | CPU | ⚠ đa năng, tuần tự | tiền xử lý, mô hình nhỏ | | ⚠ GPU | ⚠ song song, linh hoạt | ⚠ hầu hết bài toán ML | | ⚠ TPU | ⚠ nhân ma trận, do Google thiết kế | ⚠ mô hình RẤT lớn |

Từ khoá nhận diện:

"chip Google tự thiết kế cho ML" → ⚠ TPU "tăng tốc ML nói chung" → GPU "nền tảng quản lý vòng đời ML" → Vertex AI "lưu mô hình và dữ liệu" → Cloud Storage

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ tăng tốc có được dùng hết không | ⚠ mức sử dụng thấp → nghẽn ở dữ liệu | | Đã lưu checkpoint chưa | ⚠ bắt buộc với Spot | | Chi phí một lần huấn luyện | ⚠ tính trước, so cả hai lựa chọn |

Và phép so sánh đúng khi chọn giữa các loại phần cứng tăng tốc không phải là giá mỗi giờ, mà là tổng chi phí để hoàn thành một lần huấn luyện. Một con chip đắt gấp đôi nhưng xong nhanh gấp ba là lựa chọn rẻ hơn — và cũng trả kết quả về cho đội sớm hơn.

Đáp án

A — Công cụ low-code/no-code và các API sẵn có cho mô hình đã huấn luyện trước.

Vì sao đúng

Chủ doanh nghiệp nhỏ ít kiến thức kỹ thuật, muốn không phải viết nhiều mã và tận dụng nhanh năng lực AI có sẵn. Ba yêu cầu đó chỉ thẳng vào low-code/no-code và API dựng sẵn.

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

"ít chuyên môn kỹ thuật"
    → ⚠ cần giao diện, không cần
      viết mã

"không đòi hỏi nhiều kiến thức
 lập trình"
    → ⚠ low-code / no-code

"tận dụng NHANH năng lực AI sẵn có"
    → ⚠ API mô hình đã huấn luyện
      trước — dùng ngay

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

"Công cụ MLOps toàn diện"
    → ⚠ dành cho đội có kỹ sư ML
      quản vòng đời mô hình phức tạp

"Truy cập phần cứng TPU/GPU thô để
 tự huấn luyện"
    → ⚠ đúng thứ doanh nghiệp nhỏ
      KHÔNG cần và không làm nổi

"Các bài báo nghiên cứu của Google AI"
    → ⚠ không phải giải pháp
      triển khai được

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

• C (phần cứng TPU/GPU thô) — phương án gần nhất về mặt "cũng là năng lực AI thật của nền tảng", nhưng nó đòi hỏi đúng thứ chuyên môn mà đề nói là không có.

• B (MLOps toàn diện) và D (bài báo nghiên cứu) — không phù hợp với người dùng trong đề.

Ghi nhớ

⚠ Thang trừu tượng của AI — chọn theo NĂNG LỰC ĐỘI: | Mức | Ai dùng | Ví dụ | |---|---|---| | ⚠ No-code / API dựng sẵn | ⚠ người không kỹ thuật | ⚠ Dialogflow, Vision API | | Low-code | ⚠ người biết chút kỹ thuật | ⚠ Agent Builder, AutoML | | SDK và API | lập trình viên | ⚠ Gemini API | | Nền tảng đầy đủ | ⚠ kỹ sư ML | ⚠ Vertex AI custom | | Phần cứng thô | ⚠ đội nghiên cứu | TPU, GPU |

Từ khoá nhận diện:

"ít kỹ thuật, không viết mã, cần nhanh" → ⚠ no-code + API dựng sẵn "đội có kỹ sư ML, cần toàn quyền" → Vertex AI custom "quản vòng đời mô hình" → ⚠ MLOps "mô hình rất lớn" → TPU

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Bot chỉ trả lời phạm vi nào | ⚠ hẹp và đúng tốt hơn rộng và sai | | Nội dung nguồn đã sẵn sàng chưa | ⚠ đây mới là phần việc chính | | Khách gặp bế tắc thì sao | ⚠ phải có đường sang người thật |

Và điều quyết định một chatbot nhỏ có hữu ích hay không hiếm khi là công nghệ đứng sau nó, mà là chất lượng của bộ câu hỏi thường gặp mà chủ doanh nghiệp viết ra. Công cụ no-code rút ngắn phần dựng, nhưng phần chuẩn bị nội dung thì không ai làm thay được.

Đáp án

C — Gemini.

Vì sao đúng

Đề đòi ba thứ: năng lực cao, hiểu đa phương thức (lập trình viên có thể tham chiếu sơ đồ hoặc bản phác giao diện cùng với mã), và suy luận phức tạp. Gemini là mô hình nền đa phương thức của Google đáp ứng cả ba.

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

"năng lực cao, suy luận phức tạp"
    → ⚠ Gemini là mô hình nền
      mạnh nhất của Google

"ĐA PHƯƠNG THỨC"
    → ⚠ Gemini nhận VĂN BẢN, ẢNH,
      ÂM THANH, VIDEO làm đầu vào
    → ⚠ đúng nhu cầu "tham chiếu
      sơ đồ và bản phác giao diện"

"hỗ trợ lập trình trong IDE"
    → ⚠ Gemini Code Assist xây
      trên Gemini

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

"Gemma"
    → ⚠ họ mô hình MỞ, NHẸ của Google
    → ⚠ chạy được tại chỗ, nhưng
      KHÔNG mạnh bằng Gemini cho
      suy luận phức tạp

"Imagen"
    → ⚠ SINH ẢNH

"Veo"
    → ⚠ SINH VIDEO

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

• B (Gemma) — phương án gần nhất và là bẫy chính: cũng là mô hình của Google, tên rất giống. Nhưng Gemma là dòng mô hình mở, nhẹ, hợp khi cần chạy tại chỗ hoặc trên thiết bị; đề đòi năng lực cao và đa phương thức.

• D (Imagen) và A (Veo) — sinh ảnh và video, không phải trợ lý lập trình.

Ghi nhớ

⚠ Họ mô hình của Google — bảng phải thuộc: | Mô hình | Vai trò | |---|---| | ⚠ Gemini | ⚠ mô hình nền ĐA PHƯƠNG THỨC mạnh nhất | | ⚠ Gemma | ⚠ mô hình MỞ, NHẸ — chạy tại chỗ/trên thiết bị | | ⚠ Imagen | ⚠ sinh và chỉnh ảnh | | ⚠ Veo | ⚠ sinh video | | Chirp | giọng nói | | Lyria | âm nhạc | | MedLM, SecLM | ⚠ mô hình chuyên ngành |

Từ khoá nhận diện:

"đa phương thức, suy luận phức tạp" → ⚠ Gemini "mô hình mở, nhẹ, chạy tại chỗ" → ⚠ Gemma "sinh ảnh" → Imagen "sinh video" → Veo "hỗ trợ viết mã trong IDE" → ⚠ Gemini Code Assist

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Mã sinh ra có được review không | ⚠ bắt buộc | | Có gửi mã nội bộ ra ngoài không | ⚠ kiểm chính sách dữ liệu của công cụ | | Test có chạy qua không | ⚠ mã trông đúng vẫn có thể sai |

Và nguyên tắc không đổi khi đưa trợ lý AI vào quy trình phát triển: mã do AI sinh ra vẫn phải qua đúng quy trình review như mã do người viết. Tốc độ tạo ra mã tăng lên không làm giảm nhu cầu có người hiểu được nó — nếu có, nó làm nhu cầu đó lớn hơn.

Đáp án

A — Customer Engagement Suite với Google AI (gồm CCaaS/CCAI Platform, Agent Assist và CX Insights).

Vì sao đúng

Đề nêu ba nhu cầu, và bộ giải pháp này có đúng ba thành phần tương ứng.

⚠ Ba nhu cầu khớp một-một:

"chatbot hỗ trợ 24/7 xử lý câu
 hỏi thường gặp"
    → ⚠ CCAI PLATFORM / bot ảo

"trợ giúp nhân viên bằng gợi ý
 THỜI GIAN THỰC trong cuộc gọi"
    → ⚠ AGENT ASSIST

"phân tích bản ghi cuộc gọi để
 hiểu điểm đau của khách"
    → ⚠ CX INSIGHTS (Conversational
      Insights)

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

"Workspace và Gemini for Google Cloud"
    → ⚠ năng suất NỘI BỘ, không
      phải tổng đài khách hàng

"Apigee và Cloud Functions"
    → ⚠ quản lý API và tính toán

"Vertex AI Search và Pipelines"
    → ⚠ tìm kiếm và tự động hoá ML;
      ⚠ có thể là THÀNH PHẦN nhưng
      không phải bộ giải pháp
      chăm sóc khách hàng

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

• D (Vertex AI Search và Pipelines) — phương án gần nhất vì đều là sản phẩm AI doanh nghiệp thật và có thể tham gia vào một hệ thống chăm sóc khách hàng, nhưng chúng không phải bộ giải pháp chuyên cho tổng đài với ba năng lực đề nêu.

• B (Workspace + Gemini) và C (Apigee + Functions) — 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 | |---|---| | ⚠ CCAI Platform / bot ảo | ⚠ KHÁCH HÀNG — tự phục vụ 24/7 | | ⚠ Agent Assist | ⚠ NHÂN VIÊN — gợi ý thời gian thực | | ⚠ CX / Conversational Insights | ⚠ QUẢN LÝ — phân tích xu hướng |

Từ khoá nhận diện:

"bot trả lời khách 24/7" → ⚠ CCAI Platform "gợi ý cho nhân viên đang nghe máy" → ⚠ Agent Assist "phân tích bản ghi cuộc gọi" → ⚠ CX Insights "agent doanh nghiệp tuỳ biến" → Agent Builder

Ba việc kiểm chứng: | Việc | Cách | |---|---| | 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 | | Khách chuyển sang người có phải kể lại không | ⚠ thử gọi thật | | Chủ đề nào lặp nhiều nhất | ⚠ thường chỉ ra lỗi ở SẢN PHẨM |

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

Đáp án

A — Xuyên suốt TOÀN BỘ vòng đời ML, bắt đầu ngay từ khâu nạp và chuẩn bị dữ liệu.

Vì sao đúng

Dữ liệu bệnh nhân đi qua mọi giai đoạn. Chỉ bảo vệ ở một khâu là để hở mọi khâu còn lại — và khâu sớm nhất lại thường là nơi rủi ro lớn nhất.

⚠ Dữ liệu nhạy cảm đi qua đâu:

⚠ NẠP DỮ LIỆU
    → ⚠ khử định danh NGAY TỪ ĐÂY
    → mã hoá, kiểm soát truy cập

⚠ CHUẨN BỊ / GÁN NHÃN
    → ⚠ ai nhìn thấy hồ sơ bệnh nhân?
    → đây là khâu hay bị bỏ sót

⚠ HUẤN LUYỆN
    → ⚠ mô hình có thể GHI NHỚ
      dữ liệu huấn luyện

⚠ TRIỂN KHAI
    → prompt và đầu ra cũng chứa
      dữ liệu nhạy cảm

⚠ GIÁM SÁT
    → ⚠ log có thể chứa PII

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

"CHỈ khi triển khai"
    → ⚠ dữ liệu đã bị phơi bày
      từ trước đó rất lâu

"CHỦ YẾU khi giám sát để phát
 hiện rò rỉ"
    → ⚠ phát hiện SAU khi đã rò rỉ
      là quá muộn

"CHỦ YẾU ở khâu huấn luyện, do
 nhà khoa học dữ liệu"
    → ⚠ bỏ qua khâu nạp và chuẩn bị,
      nơi rủi ro thường LỚN NHẤT

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

• D (chủ yếu ở khâu huấn luyện) — phương án gần nhất vì huấn luyện thật sự là khâu quan trọng và là nơi mô hình có thể ghi nhớ dữ liệu. Nhưng nó bỏ qua khâu nạp và chuẩn bị, nơi dữ liệu thô chưa được che đã có nhiều người chạm vào.

• B và C — bảo vệ quá muộn.

Ghi nhớ

⚠ Bảo vệ dữ liệu theo từng khâu — bảng nên thuộc: | Khâu | Biện pháp | |---|---| | ⚠ Nạp | ⚠ khử định danh, mã hoá, IAM chặt | | ⚠ Chuẩn bị / gán nhãn | ⚠ người gán nhãn chỉ thấy dữ liệu ĐÃ CHE | | Huấn luyện | ⚠ môi trường cách ly, VPC-SC | | Triển khai | ⚠ che PII trong prompt, lọc đầu ra | | Giám sát | ⚠ đừng ghi PII vào log | | Xoá | ⚠ chính sách lưu giữ, quyền được lãng quên |

Từ khoá nhận diện:

"bảo vệ dữ liệu nhạy cảm trong ML" → ⚠ toàn bộ vòng đời "che số bệnh án, tên, địa chỉ" → ⚠ Sensitive Data Protection / DLP "khoá mã hoá của riêng tôi" → ⚠ CMEK "khoanh vùng dịch vụ, chống rò rỉ" → ⚠ VPC Service Controls

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ai nhìn thấy dữ liệu THÔ | ⚠ danh sách phải rất ngắn | | Log có chứa PII không | ⚠ nơi rò rỉ hay bị bỏ quên nhất | | Dữ liệu có rời khỏi ranh giới không | ⚠ VPC-SC |

Và khâu rò rỉ dữ liệu nhạy cảm hay bị bỏ quên nhất trong các dự án học máy không phải mô hình, mà là những bản sao dữ liệu thô được tạo ra trong lúc chuẩn bị và gán nhãn. Chúng thường nằm ngoài mọi biểu đồ kiến trúc, và cũng thường tồn tại lâu hơn dự án tạo ra chúng.

Đáp án

A — Prompt engineering.

Vì sao đúng

Đội không thay đổi mô hình và không huấn luyện thêm gì cả — họ chỉ viết lại câu lệnh cho cụ thể hơn. Đó chính là prompt engineering.

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

"Viết một khẩu hiệu"
    → ⚠ mô hình không biết cho
      sản phẩm gì, cho ai
    → ⚠ trả về thứ chung chung

"Viết khẩu hiệu bắt tai và dễ nhớ
 cho thương hiệu cà phê thân thiện
 môi trường, nhấn mạnh chứng nhận
 Rainforest Alliance và vị êm,
 hướng tới người trẻ đô thị"
        ↓
    ⚠ SẢN PHẨM: cà phê
    ⚠ ĐIỂM BÁN: chứng nhận, vị êm
    ⚠ ĐỐI TƯỢNG: người trẻ đô thị
    ⚠ GIỌNG: bắt tai, dễ nhớ
        ↓
    → ⚠ mô hình có đủ ràng buộc
      để tạo ra thứ CỤ THỂ

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

"Model fine-tuning"
    → ⚠ HUẤN LUYỆN THÊM mô hình
      trên dữ liệu riêng — không xảy ra

"RLHF"
    → ⚠ kỹ thuật huấn luyện dùng
      phản hồi con người, do bên
      xây mô hình làm

"Data augmentation"
    → ⚠ tăng cường dữ liệu HUẤN LUYỆN

Nhất quán với #13867 (cùng lô) — few-shot là một kỹ thuật cụ thể trong prompt engineering. Đề này hỏi tên chung của thực hành, đề đó hỏi kỹ thuật cụ thể. Không mâu thuẫn.

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

• D (fine-tuning) — phương án gần nhất vì cũng là cách làm mô hình cho kết quả tốt hơn, nhưng nó đòi huấn luyện thêm trên dữ liệu, trong khi đây chỉ là đổi câu lệnh.

• C (RLHF) và B (data augmentation) — thuộc quá trình huấn luyện mô hình.

Ghi nhớ

⚠ Bốn cách cải thiện đầu ra — bảng phải thuộc: | Cách | Công sức | Khi nào | |---|---|---| | ⚠ Prompt engineering | ⚠ thấp nhất | ⚠ thử ĐẦU TIÊN | | Few-shot trong prompt | thấp | ⚠ cần định dạng nhất quán | | ⚠ Grounding / RAG | trung bình | ⚠ cần kiến thức riêng, cập nhật | | ⚠ Fine-tuning | ⚠ cao nhất | ⚠ cần đổi phong cách sâu, ổn định |

Từ khoá nhận diện:

"viết lại câu lệnh cho cụ thể" → ⚠ prompt engineering "đưa vài ví dụ mẫu" → few-shot "nối với dữ liệu công ty" → grounding "huấn luyện thêm trên dữ liệu riêng" → fine-tuning

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Prompt đã nêu đủ ngữ cảnh chưa | ⚠ người lạ đọc có làm được không | | Đã nói rõ định dạng chưa | | | Có bộ test để so sánh không | ⚠ thiếu thì mọi cải thiện là cảm tính |

Và phép thử đơn giản nhất cho một prompt trước khi đổ lỗi cho mô hình: đưa chính prompt đó cho một người chưa biết gì về dự án. Nếu họ cũng không đủ thông tin để làm ra thứ bạn muốn, thì vấn đề nằm ở câu lệnh chứ không nằm ở AI.

Đáp án

B — Knowledge Cutoff (giới hạn kiến thức theo thời điểm huấn luyện).

Vì sao đúng

Mô hình kết thúc huấn luyện nhiều tháng trước, nên nó không thể biết những sự kiện xảy ra trong vài ngày gần đây. Đó là knowledge cutoff.

⚠ Vì sao xảy ra:

Mô hình học từ dữ liệu tới
NGÀY X
        ↓
    ⚠ Mọi thứ SAU ngày X:
      mô hình KHÔNG BIẾT
        ↓
    ⚠ Tệ hơn: nó có thể trả lời
      dựa trên thông tin CŨ
      mà không báo là đã cũ
        ↓
    → ⚠ tóm tắt thiếu diễn biến mới,
      hoặc chứa thông tin lỗi thời

⚠ Cách chữa:

⚠ GROUNDING
    → ⚠ đưa bài báo THẬT vào prompt
    → mô hình tóm tắt DỰA TRÊN
      văn bản được cung cấp
    → ⚠ cách chuẩn cho bài toán này

⚠ Grounding with Google Search
    → cho thông tin thế giới mới nhất

Huấn luyện lại
    → ⚠ tốn kém, và vẫn sẽ lạc hậu

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

"Hallucinations"
    → ⚠ BỊA ra thông tin không có
      thật; ở đây vấn đề là thiếu
      dữ liệu MỚI, một nguyên nhân
      khác

"Bias"
    → ⚠ thiên vị do dữ liệu huấn luyện

"Data Dependency"
    → ⚠ khái niệm chung, không phải
      tên của hạn chế cụ thể này

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: knowledge cutoff có thể DẪN TỚI ảo giác. Nhưng nguyên nhân gốc mà đề mô tả — huấn luyện kết thúc nhiều tháng trước — chính là knowledge cutoff.

• A (bias) và D (data dependency) — không mô tả đúng hiện tượng.

Ghi nhớ

⚠ Hạn chế của mô hình nền — bảng phải thuộc: | Hạn chế | Nghĩa | Chữa bằng | |---|---|---| | ⚠ Knowledge cutoff | ⚠ không biết chuyện sau ngày huấn luyện | ⚠ grounding | | ⚠ Hallucination | ⚠ BỊA với giọng chắc chắn | ⚠ grounding + trích dẫn + HITL | | ⚠ Bias | ⚠ thiên vị từ dữ liệu huấn luyện | ⚠ đánh giá theo nhóm, dữ liệu cân bằng | | Thiếu kiến thức riêng | không biết dữ liệu công ty | ⚠ RAG, fine-tuning | | Cửa sổ ngữ cảnh giới hạn | không nhét được tài liệu quá dài | ⚠ chia đoạn, RAG | | Không tính toán chính xác | ⚠ sai số học | ⚠ gọi công cụ ngoài |

Từ khoá nhận diện:

"không biết sự kiện gần đây" → ⚠ knowledge cutoff "bịa ra thông tin không có thật" → ⚠ hallucination "đối xử khác nhau giữa các nhóm" → bias "nối với nguồn tin cậy" → grounding

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Bài toán có cần thông tin mới không | ⚠ có → bắt buộc grounding | | Mô hình có nói được "tôi không biết" không | ⚠ thử hỏi chuyện mới xảy ra | | Nguồn và ngày có hiển thị cho người dùng không | ⚠ để họ tự đánh giá |

Và cách xử lý đúng cho mọi bài toán tóm tắt tin tức: đừng hỏi mô hình chuyện gì đã xảy ra — đưa cho nó bài báo và yêu cầu tóm tắt. Khi ấy giới hạn kiến thức không còn liên quan, vì mô hình đang làm việc trên văn bản bạn cung cấp chứ không phải trên trí nhớ của nó.

Đáp án

A — Đảm bảo chất lượng dữ liệu cao và khả năng truy cập được dữ liệu.

Vì sao đúng

Đề mô tả ba triệu chứng của dữ liệu tồi: nằm rải rác ở nhiều hệ thống cũ, không nhất quán, thiếu nhiều trường. Không giải quyết chuyện đó thì mọi bước sau đều vô nghĩa.

⚠ Ba vấn đề trong đề:

"nằm ở nhiều hệ thống LEGACY"
    → ⚠ vấn đề TRUY CẬP (accessibility)
    → ⚠ và là data silo

"thường KHÔNG NHẤT QUÁN"
    → ⚠ vấn đề CONSISTENCY

"THIẾU nhiều trường"
    → ⚠ vấn đề COMPLETENESS

⚠ Vì sao phải xử lý TRƯỚC:

Dữ liệu rác
        ↓
    ⚠ Mô hình học từ rác
        ↓
    ⚠ Cá nhân hoá SAI người
    ⚠ Gửi nội dung không liên quan
    ⚠ Có thể vi phạm quyền riêng tư
        ↓
    ⚠ "Rác vào, rác ra" — đổi
      mô hình không cứu được

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

"Prompt engineering"
    → ⚠ quan trọng, nhưng KHÔNG
      sửa được dữ liệu tồi

"Chọn mô hình nền phù hợp"
    → ⚠ bước sau; mô hình tốt nhất
      cũng không cứu dữ liệu rác

"Mở rộng hạ tầng suy luận"
    → ⚠ bài toán khi ĐÃ chạy được,
      chưa phải bây giờ

Nhất quán với #13862 (cùng lô) — đề đó về relevance của dữ liệu huấn luyện. Cùng thông điệp: chất lượng dữ liệu quyết định chất lượng đầu ra.

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

• C (chọn mô hình nền) — phương án gần nhất vì đó thật sự là một quyết định quan trọng trong dự án AI sinh, nhưng nó chỉ có nghĩa sau khi có dữ liệu dùng được.

• B (prompt engineering) và D (mở rộng hạ tầng) — đều là bước sau.

Ghi nhớ

⚠ Thứ tự việc trong dự án AI sinh — bảng nên thuộc: | Bước | Nội dung | |---|---| | ⚠ 1. Dữ liệu | ⚠ chất lượng, truy cập được, có quyền dùng | | 2. Ca sử dụng rõ ràng | ⚠ đo được giá trị | | 3. Chọn mô hình | theo modality và chất lượng | | 4. Prompt / grounding | | | 5. Đánh giá | ⚠ bộ test có đáp án | | 6. Triển khai, giám sát | ⚠ và mở rộng hạ tầng |

Từ khoá nhận diện:

"dữ liệu rải rác, không nhất quán, thiếu trường" → ⚠ chất lượng và truy cập dữ liệu "mỗi phòng một hệ thống" → ⚠ data silo "dữ liệu về chủ đề khác" → relevance "gom về một nơi phân tích" → ⚠ BigQuery / lakehouse

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có bao nhiêu nguồn dữ liệu khách hàng | ⚠ kiểm kê trước đã | | Một khách có mấy mã định danh | ⚠ hợp nhất là việc khó nhất | | Có quyền dùng dữ liệu này không | ⚠ hỏi trước khi xây |

Và tỉ lệ công sức thật của một dự án AI sinh 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, không ở việc chọn hay chỉnh mô hình. Đội nào bỏ qua bước đó thường quay lại làm nó sau, với chi phí cao hơn.