Ngân hàng đề — Google Cloud Generative AI Leader
Tìm thấy 556 câu.
A financial services company needs AI to generate client reports that follow specific regulatory formats and use precise industry terminology. Their compliance team emphasizes that the AI must consistently use their exact language and formatting standards.
Which model selection factor is most important for ensuring regulatory compliance?
-
A
Fast processing speed for real-time reporting
-
B
Low cost per transaction to maximize ROI
-
C
Customization capabilities to adapt to regulatory requirements
-
D
Large user community for support and resources
Xem giải thích
Đáp án
C — Khả năng tuỳ biến để thích ứng với các yêu cầu quy định.
Vì sao đúng
Bộ phận tuân thủ đòi AI dùng CHÍNH XÁC ngôn ngữ và chuẩn định dạng của họ, một cách nhất quán. Yêu cầu đó chỉ đáp ứng được bằng khả năng tuỳ biến mô hình.
⚠ Vì sao tuỳ biến là yếu tố quyết định:
"định dạng theo QUY ĐỊNH cụ thể"
→ ⚠ không phải định dạng chung
"thuật ngữ ngành CHÍNH XÁC"
→ ⚠ không được diễn đạt khác đi
"NHẤT QUÁN dùng đúng ngôn ngữ
và chuẩn của họ"
→ ⚠ mỗi lần phải giống nhau
↓
⚠ Mô hình chung không tự biết
chuẩn riêng của công ty
↓
→ ⚠ cần TUỲ BIẾN
⚠ Bốn mức tuỳ biến — chọn mức nào:
⚠ PROMPT với mẫu và ràng buộc
→ ⚠ thử TRƯỚC, rẻ nhất
⚠ FEW-SHOT với báo cáo mẫu
→ ⚠ dạy định dạng rất hiệu quả
⚠ GROUNDING vào tài liệu quy định
→ ⚠ cho nội dung chính xác
⚠ FINE-TUNING
→ ⚠ cho phong cách ổn định
ở quy mô lớn
⚠ Vì sao ba phương án kia sai:
"Tốc độ xử lý nhanh"
→ ⚠ báo cáo định kỳ không đòi
thời gian thực
"Chi phí thấp mỗi giao dịch"
→ ⚠ quan trọng, nhưng tuân thủ
là ràng buộc CỨNG hơn
"Cộng đồng người dùng lớn"
→ ⚠ không giải quyết yêu cầu
định dạng riêng
Nhất quán với #13930 (lô 146) — đề đó khoá fine-tuning cho chuyên biệt hoá lĩnh vực pháp lý. Đề này hỏi tiêu chí chọn mô hình nên khoá khả năng tuỳ biến — khái niệm bao trùm. Không mâu thuẫn.
Vì sao các phương án khác sai
-
B (chi phí thấp) — phương án gần nhất vì luôn là mối quan tâm thật. Nhưng với yêu cầu tuân thủ quy định, đây là ràng buộc bắt buộc phải đáp ứng, không phải thứ để đánh đổi.
-
A và D — không giải quyết yêu cầu cốt lõi.
Ghi nhớ
⚠ Bốn mức tuỳ biến — bảng phải thuộc: | Mức | Giải quyết | Công sức | |---|---|---| | ⚠ Prompt engineering | ⚠ định dạng, ràng buộc cơ bản | ⚠ thấp nhất | | ⚠ Few-shot | ⚠ định dạng nhất quán từ ví dụ | thấp | | ⚠ Grounding / RAG | ⚠ nội dung, quy định chính xác | trung bình | | ⚠ Fine-tuning | ⚠ phong cách sâu và ổn định | cao |
Từ khoá nhận diện:
"đúng chuẩn riêng, nhất quán" → ⚠ khả năng tuỳ biến "tài liệu rất dài" → cửa sổ ngữ cảnh "dừng máy tốn tiền" → độ tin cậy, SLA "ngân sách hạn hẹp" → chi phí
| ⚠ Với báo cáo tuân thủ — cần cả bốn lớp | Lớp |
|---|---|
| ⚠ TEMPLATE cố định cho phần bắt buộc | ⚠ đừng để AI tự sinh phần này |
| ⚠ Few-shot với báo cáo mẫu đã duyệt | |
| ⚠ Grounding vào văn bản quy định | ⚠ và số liệu thật từ hệ thống |
| ⚠ Temperature THẤP | |
| ⚠ Bộ phận tuân thủ DUYỆT | ⚠ HITL bắt buộc |
| Kiểm tra tự động định dạng | ⚠ có đủ mục bắt buộc không |
| ⚠ Nguyên tắc quan trọng cho tài liệu tuân thủ | Nguyên tắc |
|---|---|
| ⚠ Phần BẮT BUỘC theo quy định → dùng TEMPLATE | ⚠ không để mô hình sinh |
| ⚠ AI điền phần NỘI DUNG, không đổi cấu trúc | |
| Số liệu lấy từ HỆ THỐNG, không để AI nhớ | ⚠ chống bịa số |
| Vì sao | ⚠ sai một câu chữ bắt buộc có thể thành vi phạm |
| ⚠ Rủi ro của AI trong báo cáo có quản lý | Rủi ro |
|---|---|
| ⚠ BỊA số liệu | ⚠ nghiêm trọng nhất |
| ⚠ Diễn đạt lại câu chữ bắt buộc | ⚠ thành sai quy định |
| Thiếu mục bắt buộc | |
| ⚠ Không nhất quán giữa các kỳ báo cáo | |
| Phòng bằng | ⚠ template + grounding + kiểm tra tự động + người duyệt |
| ⚠ Đo tính nhất quán | Cách |
|---|---|
| ⚠ Sinh cùng đầu vào nhiều lần, so kết quả | |
| Kiểm có đủ mục bắt buộc không | ⚠ tự động hoá được |
| ⚠ So với báo cáo kỳ trước | ⚠ giọng và cấu trúc có giữ nguyên không |
| Bộ phận tuân thủ chấm mẫu |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sinh lại có ra kết quả nhất quán không | ⚠ chạy vài lần rồi so | | Số liệu lấy từ đâu | ⚠ phải từ hệ thống, không từ trí nhớ mô hình | | Ai duyệt trước khi nộp | ⚠ bộ phận tuân thủ, bắt buộc |
Và nguyên tắc đáng giữ khi dùng AI cho tài liệu chịu quản lý: những câu chữ mà quy định bắt buộc phải xuất hiện nguyên văn thì đừng để mô hình sinh ra. Hãy để chúng nằm trong template cố định, và giao cho AI phần nội dung linh hoạt còn lại.
A CEO is presenting to the board about their AI strategy. She explains that their company uses various technologies: systems that predict customer churn, chatbots that create personalized responses, robots that optimize warehouse operations, and algorithms that detect fraud patterns.
When describing the overarching technology category that encompasses all these capabilities, which term should the CEO use?
-
A
Deep Learning - since complex algorithms are involved
-
B
Generative AI - since the systems create new outputs
-
C
Artificial Intelligence - as the broad field covering all intelligent systems
-
D
Machine Learning - since all systems learn from data
Xem giải thích
Đáp án
C — Artificial Intelligence — vì đây là lĩnh vực rộng bao trùm mọi hệ thống thông minh.
Vì sao đúng
CEO liệt kê bốn loại hệ thống rất khác nhau: dự đoán rời bỏ, chatbot sinh nội dung, robot tối ưu kho, thuật toán phát hiện gian lận. Chỉ AI đủ rộng để bao trùm cả bốn.
⚠ Bốn hệ thống thuộc đâu:
"dự đoán khách rời bỏ"
→ ⚠ ML có giám sát
"chatbot SINH phản hồi cá nhân hoá"
→ ⚠ GENERATIVE AI
"robot tối ưu vận hành kho"
→ ⚠ có thể là học TĂNG CƯỜNG,
tối ưu hoá, robotics
"phát hiện mẫu hình gian lận"
→ ⚠ ML, có thể không giám sát
↓
⚠ CHỈ "AI" bao trùm được cả bốn
⚠ Vì sao ba phương án kia sai:
"Machine Learning — vì mọi hệ
thống đều học từ dữ liệu"
→ ⚠ robot tối ưu kho có thể dùng
thuật toán tối ưu KHÔNG học
từ dữ liệu
"Generative AI — vì hệ thống tạo
đầu ra mới"
→ ⚠ CHỈ chatbot là sinh; dự đoán
rời bỏ KHÔNG sinh gì
"Deep Learning — vì có thuật toán
phức tạp"
→ ⚠ HẸP NHẤT: chỉ mạng nơ-ron
nhiều lớp
⚠ Gần trùng với #13956 (lô 147) — đề đó cũng liệt kê nhiều năng lực và hỏi lĩnh vực bao trùm, cùng khoá AI. Hoàn toàn nhất quán. Và #13958 (lô 147) về quan hệ bao hàm.
Vì sao các phương án khác sai
-
D (Machine Learning) — phương án gần nhất và là bẫy chính: phần lớn các hệ thống nêu thật sự là ML. Nhưng AI rộng hơn, và không phải mọi AI đều học từ dữ liệu.
-
B và A — chỉ đúng cho một phần trong danh sách.
Ghi nhớ
⚠ Quan hệ bao hàm — bảng phải thuộc: | Cấp | Khái niệm | |---|---| | ⚠ 1 | ⚠ AI — RỘNG NHẤT | | 2 | ⚠ Machine Learning — học từ dữ liệu | | 3 | ⚠ Deep Learning — mạng nơ-ron sâu | | 4 | ⚠ Generative AI — HẸP NHẤT, tạo nội dung |
Từ khoá nhận diện:
"lĩnh vực bao trùm, nhiều loại hệ thống" → ⚠ AI "học từ dữ liệu" → Machine Learning "mạng nơ-ron nhiều lớp" → Deep Learning "tạo nội dung mới" → Generative AI
| ⚠ AI KHÔNG chỉ là học máy | Ví dụ |
|---|---|
| ⚠ Hệ chuyên gia dựa trên LUẬT | ⚠ AI nhưng không học từ dữ liệu |
| Thuật toán tìm kiếm, lập kế hoạch | ⚠ AI cổ điển |
| ⚠ Tối ưu hoá vận trù | ⚠ tối ưu kho có thể thuộc nhóm này |
| Robotics điều khiển | |
| Ghi nhớ | ⚠ AI ⊃ ML, KHÔNG phải AI = ML |
| ⚠ Vì sao chọn đúng từ khi trình bày cho ban lãnh đạo lại quan trọng | Lý do |
|---|---|
| ⚠ Dùng "AI sinh" cho mọi thứ gây kỳ vọng sai | |
| ⚠ Ban lãnh đạo có thể tưởng mọi hệ thống đều rủi ro như LLM | |
| Ngân sách và quản trị khác nhau cho từng loại | |
| ⚠ ML dự đoán thường RẺ và ỔN ĐỊNH hơn nhiều | ⚠ đừng gộp chung |
| Nên | ⚠ phân loại rõ để quyết định đúng cho từng nhóm |
| ⚠ Bốn hệ thống — quản trị khác nhau | Hệ thống |
|---|---|
| Dự đoán rời bỏ | ⚠ rủi ro thấp, cần đo hiệu quả |
| ⚠ Chatbot sinh nội dung | ⚠ rủi ro ảo giác, cần HITL |
| Robot kho | ⚠ rủi ro an toàn vật lý |
| ⚠ Phát hiện gian lận | ⚠ rủi ro công bằng, cần giải thích được |
| Kết luận | ⚠ một chính sách chung không phủ hết |
| ⚠ AGI — nhắc lại | Điểm |
|---|---|
| ⚠ AGI CHƯA TỒN TẠI | |
| Mọi AI hiện nay là AI HẸP | ⚠ giỏi một loại việc |
| Trong đề thi | ⚠ phương án nhắc AGI gần như luôn sai |
Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Hệ thống có học từ dữ liệu không | ⚠ không → là AI nhưng không phải ML | | Đầu ra là nội dung mới hay dự đoán | ⚠ phân biệt sinh và dự đoán | | Rủi ro của từng loại có giống nhau không | ⚠ không — cần quản trị riêng |
Và lý do việc dùng đúng thuật ngữ quan trọng trong phòng họp ban lãnh đạo: gộp mọi thứ vào nhãn "AI sinh" khiến những hệ thống dự đoán vốn rẻ và ổn định bị soi xét như thể chúng có cùng rủi ro với một mô hình ngôn ngữ. Phân loại đúng dẫn tới quyết định đầu tư và quản trị đúng cho từng nhóm.
A marketing agency is planning to deploy generative AI for various client projects and wants to understand RAG limitations.
In which scenario would RAG be LEAST appropriate or effective?
-
A
Providing personalized financial advice based on a client's investment portfolio
-
B
Generating 100 creative tagline variations for a product launch brainstorming session
-
C
Summarizing technical specifications from engineering documentation
-
D
Answering customer support questions about recent product updates
Xem giải thích
Đáp án
B — Sinh 100 biến thể khẩu hiệu sáng tạo cho buổi brainstorm ra mắt sản phẩm.
Vì sao đúng
⚠ Đây là câu hỏi PHỦ ĐỊNH: hỏi trường hợp RAG ÍT phù hợp nhất. Brainstorm sáng tạo không cần tra cứu tài liệu — nó cần sự đa dạng và mới mẻ, đúng thứ RAG không tạo ra.
⚠ RAG hợp và không hợp ở đâu:
⚠ RAG RẤT HỢP khi
→ cần THÔNG TIN CHÍNH XÁC
→ cần trích dẫn NGUỒN
→ có tài liệu tin cậy
→ cần thông tin CẬP NHẬT
⚠ RAG KHÔNG THÊM GÌ khi
→ ⚠ nhiệm vụ thuần SÁNG TẠO
→ ⚠ không có "câu trả lời đúng"
→ ⚠ cần ĐA DẠNG, mới mẻ
→ ⚠ ĐỀ NÀY
⚠ Vì sao ba phương án kia RAG hợp:
"Tư vấn tài chính dựa trên DANH MỤC
ĐẦU TƯ của khách"
→ ⚠ cần dữ liệu THẬT của khách
→ ⚠ RAG rất hợp
"Tóm tắt THÔNG SỐ KỸ THUẬT từ
tài liệu kỹ thuật"
→ ⚠ cần bám sát tài liệu
→ ⚠ RAG rất hợp
"Trả lời hỗ trợ về CẬP NHẬT SẢN
PHẨM gần đây"
→ ⚠ vượt knowledge cutoff
→ ⚠ RAG rất hợp
Nhất quán với #13900/#13913/#13951 — các đề đó khoá RAG cho những tình huống cần thông tin chính xác và cập nhật. Đề này chỉ ra giới hạn của RAG. Bổ sung nhau, không mâu thuẫn.
Vì sao các phương án khác sai
⚠ Ba phương án còn lại đều là những trường hợp RAG rất phù hợp, nên không phải đáp án cho câu hỏi phủ định.
- A (tư vấn tài chính theo danh mục khách) — phương án gần nhất bị chọn nhầm vì nghe "cá nhân hoá". Nhưng cá nhân hoá ở đây dựa trên dữ liệu thật của khách, tức đúng chỗ RAG phát huy.
Ghi nhớ
⚠ RAG hợp và không hợp — bảng phải thuộc: | RAG RẤT HỢP | RAG ÍT GIÁ TRỊ | |---|---| | ⚠ Hỏi đáp trên tài liệu | ⚠ brainstorm sáng tạo | | ⚠ Thông tin cập nhật | ⚠ viết văn, thơ tự do | | ⚠ Dữ liệu riêng của khách | ⚠ cần đa dạng, mới mẻ | | ⚠ Cần trích dẫn nguồn | ⚠ không có câu trả lời đúng | | Giảm ảo giác về sự kiện | ⚠ nhiệm vụ thuần suy luận |
Từ khoá nhận diện:
"brainstorm, nhiều biến thể sáng tạo" → ⚠ KHÔNG cần RAG "thông tin chính xác, có nguồn" → RAG "dữ liệu riêng của khách" → RAG "đa dạng, bất ngờ" → ⚠ temperature CAO
| ⚠ Brainstorm khẩu hiệu cần gì thay vì RAG | Cần |
|---|---|
| ⚠ Temperature CAO | ⚠ để đa dạng |
| ⚠ Prompt giàu ngữ cảnh về thương hiệu | ⚠ đối tượng, giọng, điểm bán |
| Sinh NHIỀU phương án cùng lúc | ⚠ rồi chọn |
| ⚠ Few-shot với khẩu hiệu cũ đã thành công | ⚠ dạy phong cách |
| Người chọn và biên tập |
| ⚠ Nhưng RAG vẫn có thể HỖ TRỢ gián tiếp | Cách |
|---|---|
| ⚠ Tra hướng dẫn thương hiệu | ⚠ giọng, từ cấm dùng |
| Tra thông tin sản phẩm chính xác | ⚠ để không bịa tính năng |
| Tra khẩu hiệu đã dùng | ⚠ tránh trùng lặp |
| Nhưng | ⚠ bản thân việc SÁNG TẠO không do RAG tạo ra |
| ⚠ Cái giá nếu dùng RAG sai chỗ | Cái giá |
|---|---|
| ⚠ Prompt dài hơn → tốn token | |
| ⚠ Độ trễ tăng | |
| ⚠ Kết quả có thể KÉM đa dạng hơn | ⚠ bị neo vào tài liệu |
| Thêm hệ thống phải bảo trì | |
| Nguyên tắc | ⚠ RAG là công cụ cho bài toán KIẾN THỨC, không phải mọi bài toán |
| ⚠ Câu hỏi phủ định trong đề thi — mẹo làm | Mẹo |
|---|---|
| ⚠ Đọc kỹ chữ LEAST, NOT, EXCEPT | ⚠ dễ đọc sót |
| ⚠ Xác định ba phương án ĐÚNG trước | ⚠ cái còn lại là đáp án |
| Kiểm lại bằng cách đọc ngược |
Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có "câu trả lời đúng" không | ⚠ không → RAG ít giá trị | | Cần thông tin từ nguồn cụ thể không | ⚠ có → RAG | | Cần đa dạng hay chính xác | ⚠ đa dạng → temperature cao, không phải RAG |
Và cách nhớ giới hạn của RAG cho gọn: nó giúp mô hình biết đúng, không giúp mô hình nghĩ hay. Với một buổi brainstorm cần trăm ý tưởng khác nhau, thứ cần điều chỉnh là nhiệt độ và chất lượng mô tả bối cảnh, không phải thêm một kho tài liệu.
A sales manager is training her team to use AI for generating client proposals. She considers using a single, high-quality example (one-shot prompting) instead of multiple examples (few-shot prompting).
What is the main advantage of using a single example for this business training?
-
A
It gives the AI access to more diverse writing styles and approaches
-
B
It provides comprehensive coverage of all possible client scenarios
-
C
It reduces training time while still providing clear guidance on expectations
-
D
It allows for more creative and varied proposal outputs
Xem giải thích
Đáp án
C — Rút ngắn thời gian đào tạo mà vẫn cung cấp hướng dẫn rõ ràng về kỳ vọng.
Vì sao đúng
One-shot — đưa một ví dụ chất lượng cao — vẫn định hình được định dạng và kỳ vọng, mà nhanh và đơn giản hơn so với chuẩn bị nhiều ví dụ.
⚠ Đánh đổi giữa one-shot và few-shot:
⚠ ONE-SHOT
→ ⚠ MỘT ví dụ tốt
→ ⚠ nhanh chuẩn bị
→ ⚠ prompt ngắn, rẻ hơn
→ ⚠ đủ để dạy ĐỊNH DẠNG
→ ⚠ dễ dạy lại cho cả đội
⚠ FEW-SHOT
→ ⚠ NHIỀU ví dụ
→ ⚠ phủ được nhiều tình huống
→ ⚠ nhất quán hơn ở ca đa dạng
→ tốn công chuẩn bị hơn
⚠ Vì sao ba phương án kia sai:
"Cho AI tiếp cận NHIỀU phong cách
viết đa dạng hơn"
→ ⚠ NGƯỢC: một ví dụ thì ÍT
đa dạng hơn
"Phủ TOÀN DIỆN mọi tình huống
khách hàng"
→ ⚠ NGƯỢC: đó là ưu điểm của
few-shot
"Cho phép đầu ra SÁNG TẠO và
ĐA DẠNG hơn"
→ ⚠ độ đa dạng do TEMPERATURE
quyết định, không phải số ví dụ
Đối chiếu #13867 (lô 145) — đề đó khoá few-shot vì prompt có ba ví dụ. Đề này hỏi ưu điểm của one-shot. Không mâu thuẫn — cùng họ kỹ thuật, khác số lượng ví dụ và khác điều được hỏi.
Vì sao các phương án khác sai
-
B (phủ toàn diện mọi tình huống) — phương án gần nhất và là bẫy trực tiếp: đó là ưu điểm của few-shot, không phải one-shot.
-
A và D — cũng mô tả ngược.
Ghi nhớ
⚠ Zero / one / few-shot — bảng phải thuộc: | Kỹ thuật | Số ví dụ | Ưu điểm | |---|---|---| | ⚠ Zero-shot | ⚠ 0 | ⚠ nhanh nhất, prompt ngắn nhất | | ⚠ One-shot | ⚠ 1 | ⚠ dạy được ĐỊNH DẠNG, vẫn gọn | | ⚠ Few-shot | ⚠ vài | ⚠ nhất quán hơn, phủ nhiều ca |
Từ khoá nhận diện:
"một ví dụ, nhanh, gọn" → ⚠ one-shot "nhiều ví dụ, phủ nhiều tình huống" → few-shot "không ví dụ" → zero-shot "đa dạng, sáng tạo" → ⚠ temperature — không phải số ví dụ
| ⚠ Khi nào một ví dụ là ĐỦ | Khi |
|---|---|
| ⚠ Nhiệm vụ có ĐỊNH DẠNG rõ ràng | ⚠ đề xuất bán hàng có cấu trúc cố định |
| ⚠ Ít biến thể giữa các ca | |
| Người dùng là người không kỹ thuật | ⚠ dễ hiểu, dễ áp dụng |
| ⚠ Cần triển khai nhanh cho cả đội | ⚠ đề này |
| Khi nào cần nhiều hơn | ⚠ ca đa dạng, cần phân biệt tinh tế |
| ⚠ Chọn MỘT ví dụ cho tốt | Nguyên tắc |
|---|---|
| ⚠ Chọn ví dụ ĐIỂN HÌNH nhất | ⚠ không phải ca đặc biệt |
| ⚠ Chất lượng CAO | ⚠ mô hình bắt chước cả điểm yếu |
| Thể hiện rõ cấu trúc mong muốn | |
| ⚠ Độ dài tương đương kết quả muốn có | |
| Mẹo | ⚠ lấy một đề xuất đã thắng thầu làm mẫu |
| ⚠ Cạm bẫy của one-shot | Cạm bẫy |
|---|---|
| ⚠ Mô hình bám QUÁ SÁT ví dụ | ⚠ mọi đề xuất na ná nhau |
| ⚠ Chi tiết riêng của ví dụ bị lặp lại | ⚠ tên khách hàng cũ, con số cũ |
| Không phủ được ca khác biệt | |
| Giảm bằng | ⚠ nêu rõ đâu là cấu trúc cần theo, đâu là nội dung phải thay |
| ⚠ Với đào tạo đội bán hàng | Lưu ý |
|---|---|
| ⚠ Prompt phải ĐƠN GIẢN để ai cũng dùng được | |
| ⚠ Chuẩn hoá thành template dùng chung | ⚠ hoặc một Gem |
| ⚠ Luôn kiểm số liệu và tên khách | ⚠ AI có thể lấy nhầm từ ví dụ |
| Thu phản hồi để cải thiện mẫu |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề xuất sinh ra có bị na ná nhau không | ⚠ dấu hiệu bám quá sát ví dụ | | Có lẫn chi tiết từ ví dụ mẫu không | ⚠ tên, số liệu cũ | | Một ví dụ có đủ không | ⚠ thử, nếu chưa ổn thì thêm ví dụ |
Và cạm bẫy thường gặp khi dùng một ví dụ mẫu duy nhất cho cả đội: những chi tiết riêng của ví dụ đó bắt đầu xuất hiện trong các đề xuất gửi khách hàng khác. Vì vậy phần chỉ dẫn nên nói rõ ví dụ dùng để học cấu trúc, còn mọi con số và tên riêng đều phải thay mới.
A corporate training director needs to create personalized onboarding videos for different departments, convert compliance documents into executive summaries, and analyze employee feedback for training gaps.
For creating personalized departmental onboarding content, which generative AI capability is most valuable?
-
A
Summarization - to condense existing training materials
-
B
Discovery - to find relevant content from existing resources
-
C
Automation - to streamline the video production process
-
D
Creation - to generate new video content tailored to departments
Xem giải thích
Đáp án
D — Creation (sáng tạo) — sinh nội dung video mới, may đo cho từng phòng ban.
Vì sao đúng
Nhu cầu là TẠO RA video onboarding cá nhân hoá cho từng phòng ban — nội dung chưa tồn tại. Đó là năng lực sáng tạo.
⚠ Ba nhu cầu trong đề, ba năng lực khác nhau:
"TẠO video onboarding cá nhân hoá
cho từng phòng ban"
→ ⚠ CREATION — đề hỏi cái này
"chuyển tài liệu tuân thủ thành
BẢN TÓM TẮT cho lãnh đạo"
→ ⚠ SUMMARIZATION
"PHÂN TÍCH phản hồi nhân viên để
tìm khoảng trống đào tạo"
→ ⚠ DISCOVERY
↓
⚠ Đề hỏi riêng nhu cầu THỨ NHẤT
⚠ Vì sao ba phương án kia sai:
"Summarization — cô đọng tài liệu
đào tạo có sẵn"
→ ⚠ đúng cho nhu cầu THỨ HAI,
không phải nhu cầu được hỏi
"Discovery — tìm nội dung liên quan
từ tài nguyên có sẵn"
→ ⚠ đúng cho nhu cầu THỨ BA
"Automation — tinh gọn quy trình
sản xuất video"
→ ⚠ về QUY TRÌNH, không phải
về việc TẠO nội dung
Đối chiếu #13975 (lô 147) khoá Discovery và #13885 (lô 145) khoá Summarization. Ba đề cùng khung bốn năng lực, mỗi đề một năng lực. Hoàn toàn nhất quán.
Vì sao các phương án khác sai
-
A (summarization) — phương án gần nhất và là bẫy chính: nó thật sự cần thiết cho nhu cầu thứ hai trong đề. Nhưng câu hỏi hỏi riêng về việc tạo nội dung onboarding.
-
C và B — đúng cho các nhu cầu khác trong cùng đề bài.
Ghi nhớ
⚠ Bốn năng lực AI sinh — bảng phải thuộc: | Năng lực | Ví dụ | |---|---| | ⚠ Creation | ⚠ tạo video, bài viết, ảnh MỚI | | ⚠ Summarization | ⚠ cô đọng tài liệu đã có | | ⚠ Discovery | ⚠ tìm mẫu hình ẩn trong dữ liệu | | ⚠ Automation | ⚠ làm thay việc lặp lại |
Từ khoá nhận diện:
"tạo nội dung mới, may đo" → ⚠ Creation "cô đọng, rút gọn" → Summarization "tìm mẫu hình, liên hệ bị bỏ sót" → Discovery "tự động hoá quy trình lặp lại" → Automation
| ⚠ Tạo video onboarding — cần gì | Cần |
|---|---|
| ⚠ Kịch bản riêng cho từng phòng | ⚠ LLM sinh |
| ⚠ Giọng đọc | ⚠ Text-to-Speech |
| Hình ảnh, minh hoạ | ⚠ Imagen hoặc thư viện có sẵn |
| ⚠ Video | ⚠ Veo hoặc dựng từ slide |
| Phụ đề, đa ngôn ngữ | ⚠ Translation |
| Ghi nhớ | ⚠ đây là chuỗi nhiều modality |
| ⚠ Cá nhân hoá theo phòng ban — cá nhân hoá cái gì | Cái gì |
|---|---|
| ⚠ Công cụ và hệ thống phòng đó dùng | |
| ⚠ Quy trình đặc thù | |
| Người liên hệ, cơ cấu tổ chức | |
| ⚠ Ví dụ minh hoạ sát công việc thật | ⚠ phần tạo khác biệt lớn nhất |
| Giữ CHUNG | ⚠ giá trị công ty, chính sách bắt buộc |
| ⚠ Thiết kế thực dụng | Thiết kế |
|---|---|
| ⚠ PHẦN CHUNG dùng template cố định | ⚠ chính sách, tuân thủ — không để AI sinh |
| ⚠ PHẦN RIÊNG do AI sinh theo tham số | |
| Grounding vào tài liệu phòng ban | ⚠ để không bịa quy trình |
| ⚠ Trưởng phòng duyệt trước khi dùng | |
| Cập nhật khi quy trình đổi | ⚠ video cũ dễ bị bỏ quên |
| ⚠ Rủi ro của nội dung onboarding sai | Rủi ro |
|---|---|
| ⚠ Nhân viên mới học sai quy trình | |
| ⚠ Thông tin tuân thủ sai | ⚠ rủi ro pháp lý |
| Video lỗi thời vẫn được dùng | ⚠ cần cơ chế rà soát định kỳ |
| Phòng bằng | ⚠ template cho phần bắt buộc + người duyệt + gắn ngày hết hiệu lực |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy trình trong video có đúng không | ⚠ trưởng phòng duyệt | | Phần tuân thủ có bị AI diễn đạt lại không | ⚠ phải dùng nguyên văn | | Có cơ chế cập nhật khi quy trình đổi không | ⚠ video cũ dễ bị quên |
Và rủi ro âm thầm của nội dung đào tạo sinh tự động: nó tồn tại lâu hơn tính chính xác của mình. Một video onboarding được dựng trong nửa ngày có thể còn được chiếu cho nhân viên mới hai năm sau, khi quy trình bên trong đã thay đổi hoàn toàn — nên gắn ngày rà soát ngay khi tạo là việc đáng làm.
A European bank is developing a gen AI application to process sensitive customer financial data. Their top priority is regulatory compliance, which mandates that all customer data must be processed exclusively within European Union data centers.
When selecting a foundation model offering from a cloud provider, which factor is most critical for this bank?
-
A
The model's performance on creative writing tasks.
-
B
The provider's guarantees on data residency and security controls.
-
C
The model's support for the largest number of programming languages.
-
D
The availability of a free tier for initial experimentation.
Xem giải thích
Đáp án
B — Các cam kết của nhà cung cấp về vị trí lưu trữ dữ liệu (data residency) và kiểm soát bảo mật.
Vì sao đúng
Ưu tiên hàng đầu của ngân hàng là tuân thủ quy định, mà quy định bắt buộc dữ liệu khách hàng chỉ được xử lý trong trung tâm dữ liệu ở Liên minh châu Âu. Đó là yêu cầu về data residency.
⚠ Vì sao đây là ràng buộc CỨNG:
Quy định bắt buộc dữ liệu ở EU
↓
⚠ Mô hình mạnh tới đâu cũng
KHÔNG dùng được nếu xử lý
ngoài EU
↓
⚠ Đây là điều kiện LOẠI TRỪ,
không phải tiêu chí xếp hạng
↓
→ ⚠ lọc trước tiên, rồi mới
xét chất lượng và chi phí
⚠ Vì sao ba phương án kia sai:
"Hiệu năng trên tác vụ VIẾT SÁNG TẠO"
→ ⚠ ngân hàng xử lý dữ liệu
tài chính, không viết văn
"Hỗ trợ nhiều NGÔN NGỮ LẬP TRÌNH"
→ ⚠ không liên quan
"Có MỨC MIỄN PHÍ để thử nghiệm"
→ ⚠ tiện, nhưng không phải
ưu tiên hàng đầu khi tuân thủ
là ràng buộc
⚠ Gần trùng với #13895 (lô 145) và #13940 (lô 146) — cùng nhóm kiểm soát dữ liệu doanh nghiệp. Hai đề đó nhấn không dùng dữ liệu để huấn luyện, đề này nhấn VỊ TRÍ xử lý dữ liệu. Bổ sung nhau, không mâu thuẫn.
Vì sao các phương án khác sai
-
D (mức miễn phí) — phương án gần nhất về mặt "cũng là tiêu chí thật khi chọn nhà cung cấp", nhưng nó không giải quyết ràng buộc pháp lý mà đề đặt lên hàng đầu.
-
A và C — không liên quan tới nhu cầu.
Ghi nhớ
⚠ Kiểm soát dữ liệu — bảng phải thuộc: | Kiểm soát | Nội dung | |---|---| | ⚠ Data residency | ⚠ dữ liệu lưu và XỬ LÝ ở vùng nào | | ⚠ Cam kết không huấn luyện | ⚠ dữ liệu doanh nghiệp không vào mô hình nền | | VPC Service Controls | ⚠ ngăn dữ liệu rời ranh giới | | CMEK | ⚠ khoá mã hoá do khách quản | | IAM | ai truy cập được | | Audit log | ⚠ truy vết | | Assured Workloads | ⚠ gói tuân thủ theo khu vực |
Từ khoá nhận diện:
"dữ liệu phải ở trong EU" → ⚠ data residency "có bị dùng huấn luyện không" → cam kết dữ liệu "ngăn dữ liệu ra khỏi phạm vi" → VPC-SC "khung quản trị rủi ro AI" → SAIF
| ⚠ Data residency — ba câu hỏi phải trả lời | Câu hỏi |
|---|---|
| ⚠ Dữ liệu LƯU ở đâu | |
| ⚠ Dữ liệu XỬ LÝ ở đâu | ⚠ hai thứ có thể KHÁC nhau |
| ⚠ Mô hình có sẵn ở vùng đó không | ⚠ không phải mô hình nào cũng có ở mọi vùng |
| Kiểm bằng | ⚠ tài liệu về vùng khả dụng của từng mô hình |
| ⚠ Cạm bẫy hay gặp với data residency | Cạm bẫy |
|---|---|
| ⚠ Lưu ở EU nhưng xử lý ở vùng khác | ⚠ phải kiểm CẢ HAI |
| ⚠ Log và metadata rời khỏi vùng | ⚠ hay bị bỏ sót |
| Sao lưu ở vùng khác | |
| ⚠ Mô hình mới nhất chưa có ở vùng đó | ⚠ phải chấp nhận mô hình cũ hơn |
| Bên thứ ba trong chuỗi | ⚠ công cụ giám sát, phân tích |
| ⚠ Đánh đổi thực tế | Đánh đổi |
|---|---|
| ⚠ Ràng buộc vùng có thể giới hạn mô hình dùng được | |
| ⚠ Có thể đắt hơn | ⚠ giá khác nhau giữa các vùng |
| Có thể chậm hơn | ⚠ nếu người dùng ở xa vùng đó |
| Nhưng | ⚠ tuân thủ là ràng buộc CỨNG, không thương lượng |
| ⚠ Thứ tự chọn khi có ràng buộc tuân thủ | Thứ tự |
|---|---|
| ⚠ 1. LỌC theo tuân thủ | ⚠ vùng, chứng nhận, điều khoản |
| 2. Trong số còn lại, xét modality | |
| 3. Chất lượng trên ví dụ thật | |
| 4. Chi phí và độ trễ | |
| Ghi nhớ | ⚠ ràng buộc cứng lọc trước, tiêu chí mềm xếp hạng sau |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình có sẵn ở vùng EU không | ⚠ tra tài liệu vùng khả dụng | | Log và sao lưu có ở trong vùng không | ⚠ chỗ hay bị bỏ sót | | Có chứng nhận tuân thủ cần thiết không | ⚠ kiểm với bộ phận pháp chế |
Và chi tiết hay bị bỏ sót nhất khi đáp ứng yêu cầu về vị trí dữ liệu: nhật ký hệ thống và siêu dữ liệu. Dữ liệu chính có thể được cấu hình đúng vùng, trong khi log ghi lại nội dung yêu cầu lại đi ra ngoài — và đó chính là thứ mà một cuộc kiểm toán sẽ tìm thấy.
A global consulting firm must translate large, complex reports from DOCX and PDF formats into multiple languages for their clients. It is a critical requirement to preserve the original layout, tables, and formatting of the documents after translation.
Which pre-built AI API should they use for this purpose?
-
A
Cloud Translation - Advanced
-
B
Translation API
-
C
Cloud Vision API
-
D
Natural Language API
Xem giải thích
Đáp án
A — Cloud Translation - Advanced.
Vì sao đúng
Hãng tư vấn cần dịch tệp DOCX và PDF, và bắt buộc giữ nguyên bố cục, bảng biểu và định dạng sau khi dịch. Đó là năng lực Document Translation thuộc bản nâng cao của Cloud Translation.
⚠ Vì sao cần bản nâng cao:
Dịch chuỗi văn bản thuần
→ ⚠ bản cơ bản đủ
⚠ Dịch cả TỆP DOCX, PDF
GIỮ NGUYÊN bố cục
→ ⚠ cần Document Translation
→ ⚠ thuộc bản NÂNG CAO
↓
⚠ Bảng biểu, cột, định dạng
được giữ nguyên vị trí
⚠ Vì sao ba phương án kia sai:
"Cloud Vision API"
→ ⚠ phân tích ẢNH, không dịch
"Natural Language API"
→ ⚠ phân tích cảm xúc, thực thể
"Translation API" (bản cơ bản)
→ ⚠ dịch chuỗi văn bản, ⚠ KHÔNG
có dịch tài liệu giữ định dạng
⚠ Gần trùng với #14013 (cùng lô) — đề đó hỏi LOẠI năng lực cần và khoá "dịch nâng cao giữ cấu trúc". Đề này hỏi API cụ thể. Bổ sung nhau, hoàn toàn nhất quán.
Ghi nhớ về chất lượng câu hỏi
⚠ Hai phương án A "Cloud Translation - Advanced" và B "Translation API" đều thuộc cùng một họ sản phẩm dịch của Google Cloud. Cách đặt phương án này dễ gây bối rối vì tên gọi chồng lấn. Dấu hiệu phân biệt trong đề là yêu cầu dịch TỆP giữ định dạng — năng lực của bản Advanced. Khoá đáp án A giữ nguyên.
Vì sao các phương án khác sai
-
B (Translation API cơ bản) — phương án gần nhất và là bẫy chính: cùng họ sản phẩm, cùng làm việc dịch. Nhưng bản cơ bản dịch chuỗi văn bản, không xử lý tệp có định dạng.
-
C và D — không phải dịch vụ dịch.
Ghi nhớ
⚠ Hai mức của Cloud Translation — bảng phải thuộc: | | Bản cơ bản | ⚠ Bản Advanced | |---|---|---| | Dịch chuỗi văn bản | ✅ | ✅ | | ⚠ Dịch TỆP giữ định dạng | ❌ | ⚠ CÓ — đề này | | ⚠ Glossary tuỳ biến | ❌ | ⚠ CÓ | | Dịch theo lô | ❌ | ⚠ CÓ | | Mô hình tuỳ biến (AutoML) | ❌ | ⚠ CÓ |
Từ khoá nhận diện:
"dịch tệp DOCX/PDF giữ bố cục" → ⚠ Cloud Translation Advanced "dịch chuỗi ngắn trong giao diện" → Translation API cơ bản "trích trường từ tài liệu" → ⚠ Document AI "phân tích cảm xúc văn bản" → Natural Language API
| ⚠ Với báo cáo tư vấn — cần thêm gì | Cần |
|---|---|
| ⚠ GLOSSARY thuật ngữ | ⚠ tên công ty, thuật ngữ ngành nhất quán |
| ⚠ Dịch theo LÔ | ⚠ hàng loạt báo cáo, rẻ hơn |
| Giữ bảng biểu và biểu đồ | ⚠ báo cáo tư vấn nhiều bảng |
| ⚠ Người bản ngữ rà soát | ⚠ báo cáo gửi khách hàng |
| Kiểm số liệu trong bảng | ⚠ định dạng số khác nhau giữa các nước |
| ⚠ Định dạng số và ngày — cạm bẫy quốc tế | Cạm bẫy |
|---|---|
| ⚠ Dấu phân cách hàng nghìn và thập phân | ⚠ 1,000.50 và 1.000,50 |
| ⚠ Định dạng ngày | ⚠ 03/04 là tháng 3 hay tháng 4 |
| Đơn vị tiền tệ | |
| Ghi nhớ | ⚠ dịch không tự đổi các quy ước này — phải kiểm |
| ⚠ Lựa chọn khác cho tài liệu | Lựa chọn |
|---|---|
| ⚠ Document AI + Translation | ⚠ khi cần trích cấu trúc trước |
| Gemini đa phương thức | ⚠ dịch kèm hiểu ngữ cảnh, nhưng khó giữ định dạng gốc |
| AutoML Translation | ⚠ khi có cặp câu song ngữ của riêng mình |
| Chọn thế nào | ⚠ giữ ĐỊNH DẠNG là ưu tiên → Document Translation |
| ⚠ Việc con người vẫn phải làm | Việc |
|---|---|
| ⚠ Rà soát bản dịch trước khi gửi khách | |
| ⚠ Kiểm thuật ngữ chuyên ngành | |
| Kiểm số liệu và bảng | |
| ⚠ Kiểm phần nhạy cảm về văn hoá |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng biểu có giữ nguyên không | ⚠ thử với một báo cáo thật | | Thuật ngữ có nhất quán không | ⚠ dùng glossary | | Số liệu có bị đổi định dạng không | ⚠ kiểm vài bảng |
Và chi tiết nhỏ nhưng gây rắc rối thật khi dịch báo cáo giữa các thị trường: quy ước về dấu thập phân và ngày tháng. Bản dịch giữ nguyên con số, nhưng người đọc ở nước khác có thể hiểu nó thành một giá trị hoàn toàn khác — nên đó là mục nên có trong danh sách rà soát.
A consulting firm wants their AI assistant to answer client questions using only their proprietary research reports and internal case studies, not general internet information.
What grounding approach best meets this business requirement?
-
A
Connecting the AI to live internet search for current information
-
B
Training a completely custom model on public business data
-
C
Implementing retrieval from the company's specific document repository
-
D
Using the AI's pre-trained knowledge without additional sources
Xem giải thích
Đáp án
C — Triển khai truy xuất từ kho tài liệu riêng của công ty.
Vì sao đúng
Hãng tư vấn muốn AI trả lời CHỈ dựa trên báo cáo nghiên cứu độc quyền và tình huống nội bộ, KHÔNG dùng thông tin chung trên internet. Đó là grounding vào kho tài liệu riêng.
⚠ Hai từ khoá quyết định:
"CHỈ dùng báo cáo và tình huống
NỘI BỘ"
→ ⚠ nguồn HẸP, có chủ đích
"KHÔNG dùng thông tin chung trên
internet"
→ ⚠ loại bỏ grounding với Search
↓
→ ⚠ RAG vào kho tài liệu riêng
⚠ Vì sao ba phương án kia sai:
"Nối AI với tìm kiếm internet
trực tiếp"
→ ⚠ đúng thứ đề nói KHÔNG muốn
"Huấn luyện mô hình tuỳ biến hoàn
toàn trên dữ liệu kinh doanh
CÔNG KHAI"
→ ⚠ sai nguồn, và cực kỳ tốn kém
"Dùng kiến thức huấn luyện sẵn,
không thêm nguồn"
→ ⚠ đó chính là vấn đề: kiến
thức chung, không phải nghiên
cứu riêng
⚠ Gần trùng với #13859 (lô 145) và #13913 (lô 146) — cả ba đều là grounding vào dữ liệu first-party, cùng hướng khoá. Hoàn toàn nhất quán. Đối chiếu #13934 (lô 146) khoá Grounding with Google Search vì ở đó cần tin tức công khai.
Vì sao các phương án khác sai
-
A (tìm kiếm internet) — phương án gần nhất và là bẫy trực tiếp: cũng là grounding, cũng cung cấp nguồn. Nhưng đề nói rõ không dùng thông tin chung trên internet.
-
B và D — sai nguồn hoặc không giải quyết vấn đề.
Ghi nhớ
⚠ Chọn nguồn grounding theo yêu cầu — bảng phải thuộc: | Yêu cầu | Nguồn | |---|---| | ⚠ Chỉ tài liệu công ty | ⚠ RAG vào kho nội bộ — đề này | | Tin tức, thông tin công khai mới | ⚠ Grounding with Google Search | | Dữ liệu mua từ bên thứ ba | ⚠ third-party data | | Tài liệu người dùng tự nạp | ⚠ NotebookLM |
Từ khoá nhận diện:
"chỉ dùng tài liệu công ty" → ⚠ RAG vào kho nội bộ "thông tin công khai mới nhất" → Grounding with Search "phong cách, thuật ngữ riêng" → fine-tuning "nạp bộ tài liệu để nghiên cứu" → NotebookLM
| ⚠ Vì sao hãng tư vấn cần nguồn HẸP | Lý do |
|---|---|
| ⚠ Phương pháp luận riêng là TÀI SẢN | |
| ⚠ Thông tin chung trên internet có thể SAI hoặc lỗi thời | |
| Khách trả tiền cho hiểu biết ĐỘC QUYỀN | |
| ⚠ Trả lời sai làm mất uy tín | |
| Có thể phải trích dẫn nguồn cho khách |
| ⚠ Yêu cầu bắt buộc khi grounding vào tài liệu riêng | Yêu cầu |
|---|---|
| ⚠ Chỉ dẫn: CHỈ dùng thông tin được cung cấp | |
| ⚠ TRÍCH DẪN báo cáo và trang cụ thể | |
| ⚠ Nói KHÔNG BIẾT khi ngoài phạm vi | ⚠ đừng để bịa |
| ⚠ Lọc theo QUYỀN của người hỏi | ⚠ không phải ai cũng xem được mọi báo cáo |
| Giữ kho tài liệu cập nhật |
| ⚠ Rủi ro riêng của tư vấn | Rủi ro |
|---|---|
| ⚠ Lộ thông tin của khách hàng KHÁC | ⚠ báo cáo cũ chứa dữ liệu khách trước |
| ⚠ Xung đột lợi ích | ⚠ dùng hiểu biết từ khách A cho khách B |
| Thoả thuận bảo mật với từng khách | |
| Phòng bằng | ⚠ phân vùng tài liệu theo khách + lọc quyền chặt |
| ⚠ Vì sao KHÔNG nên fine-tune thay vì RAG ở đây | Lý do |
|---|---|
| ⚠ Báo cáo nghiên cứu ra liên tục | ⚠ huấn luyện lại không kịp |
| ⚠ Fine-tuning KHÔNG trích dẫn nguồn được | ⚠ tư vấn cần dẫn nguồn |
| Không lọc được theo quyền | ⚠ kiến thức nằm trong trọng số |
| Đắt hơn nhiều |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trích dẫn báo cáo nguồn không | ⚠ bắt buộc với tư vấn | | Hỏi ngoài kho tài liệu thì sao | ⚠ phải nói không biết | | Có lọc theo khách hàng không | ⚠ tránh lộ chéo thông tin |
Và rủi ro đặc thù của một hãng tư vấn khi dựng trợ lý AI trên toàn bộ kho tài liệu: thông tin từ dự án của khách hàng này có thể xuất hiện trong câu trả lời cho khách hàng khác. Vì vậy việc phân vùng tài liệu và lọc theo quyền quan trọng không kém chất lượng của bản thân câu trả lời.
A developer asks a foundation model to perform a task with the following prompt: "Translate the phrase 'good morning' into Spanish." The prompt provides the instruction directly without including any examples of English-to-Spanish translations.
Which prompting technique is being used here?
-
A
Role prompting
-
B
Few-shot prompting
-
C
One-shot prompting
-
D
Zero-shot prompting
Xem giải thích
Đáp án
D — Zero-shot prompting.
Vì sao đúng
Prompt chỉ đưa ra yêu cầu trực tiếp — "dịch cụm từ này sang tiếng Tây Ban Nha" — mà không kèm bất kỳ ví dụ nào về cặp dịch Anh–Tây Ban Nha. Đó là zero-shot.
⚠ Đếm số ví dụ:
Prompt: "Dịch cụm từ 'good morning'
sang tiếng Tây Ban Nha."
↓
⚠ KHÔNG có ví dụ nào
⚠ Không có "hello → hola"
↓
→ ⚠ ZERO-SHOT
⚠ Bộ ba theo số ví dụ:
⚠ ZERO-SHOT — 0 ví dụ
→ ⚠ chỉ có yêu cầu
→ ⚠ ĐỀ NÀY
⚠ ONE-SHOT — 1 ví dụ
→ "hello → hola. Bây giờ:
good morning → ?"
⚠ FEW-SHOT — vài ví dụ
→ nhiều cặp mẫu trước
⚠ Vì sao ba phương án kia sai:
"Few-shot" → ⚠ cần NHIỀU ví dụ
"One-shot" → ⚠ cần MỘT ví dụ
"Role prompting"
→ ⚠ cần gán vai: "bạn là
phiên dịch viên..."
⚠ Đối chiếu #13867 (lô 145) khoá few-shot vì có ba ví dụ, và #14019 (cùng lô) về one-shot. Ba đề tạo thành bộ đầy đủ. Hoàn toàn nhất quán.
Vì sao các phương án khác sai
-
C (one-shot) — phương án gần nhất và là bẫy chính: chỉ khác zero-shot ở một ví dụ. Nhưng prompt trong đề không có ví dụ nào.
-
B và A — không khớp với prompt.
Ghi nhớ
⚠ Bộ ba theo số ví dụ — bảng phải thuộc: | Kỹ thuật | Số ví dụ | Khi nào dùng | |---|---|---| | ⚠ Zero-shot | ⚠ 0 | ⚠ tác vụ phổ quát, mô hình đã biết | | ⚠ One-shot | ⚠ 1 | ⚠ cần dạy ĐỊNH DẠNG | | ⚠ Few-shot | ⚠ vài | ⚠ cần nhất quán ở ca đa dạng |
Từ khoá nhận diện:
"chỉ có yêu cầu, không ví dụ" → ⚠ zero-shot "một ví dụ mẫu" → one-shot "vài ví dụ mẫu" → few-shot "bạn là chuyên gia..." → ⚠ role prompting
| ⚠ Khi nào zero-shot là ĐỦ | Khi |
|---|---|
| ⚠ Tác vụ PHỔ QUÁT | ⚠ dịch, tóm tắt, phân loại cơ bản |
| ⚠ Mô hình đã gặp nhiều trong huấn luyện | |
| Không cần định dạng đặc biệt | |
| ⚠ Cần prompt NGẮN, rẻ | |
| Ví dụ đề này | ⚠ dịch là tác vụ mô hình rất thạo |
| ⚠ Khi nào zero-shot KHÔNG đủ | Khi |
|---|---|
| ⚠ Cần định dạng đầu ra rất riêng | ⚠ thêm ví dụ |
| ⚠ Nhãn phân loại đặc thù của ngành | |
| Ranh giới giữa các nhãn mơ hồ | ⚠ ví dụ dạy được ranh giới |
| ⚠ Cần giọng văn riêng | ⚠ few-shot hoặc fine-tuning |
| Nguyên tắc | ⚠ thử zero-shot TRƯỚC, thêm ví dụ khi cần |
| ⚠ Zero-shot vẫn cần prompt TỐT | Điểm |
|---|---|
| ⚠ Không ví dụ KHÔNG có nghĩa là sơ sài | |
| ⚠ Vẫn cần nêu rõ nhiệm vụ, định dạng, ràng buộc | |
| Ví dụ trong đề rất rõ | ⚠ nêu đúng cụm từ và ngôn ngữ đích |
| Nếu prompt mơ hồ | ⚠ zero-shot cho kết quả kém, không phải lỗi của kỹ thuật |
| ⚠ Riêng với dịch thuật | Lưu ý |
|---|---|
| ⚠ Với chuỗi ngắn: Translation API rẻ và ổn định hơn | |
| LLM hợp khi cần hiểu NGỮ CẢNH | ⚠ dịch có sắc thái, giữ giọng |
| ⚠ Thuật ngữ riêng cần glossary | |
| Cần dịch tệp giữ định dạng | ⚠ Cloud Translation Advanced |
Ba việc kiểm chứng: | Việc | Dẫn tới | |---|---| | Prompt có ví dụ nào không | ⚠ 0 → zero-shot | | Kết quả đã đạt chưa | ⚠ chưa → thêm ví dụ | | Khối lượng lớn không | ⚠ có → cân nhắc API chuyên biệt |
Và trình tự nên theo với mọi bài toán prompt: thử zero-shot trước. Với những tác vụ phổ quát như dịch hay tóm tắt, mô hình thường đã làm tốt ngay từ lần đầu — và mọi ví dụ thêm vào chỉ làm prompt dài hơn mà không cải thiện gì.
An online furniture retailer wants to allow customers to upload a photo of a sofa they like and ask the AI agent, "Find me a similar sofa to this, but in blue." This requires the agent to understand the content of the image and the text of the query simultaneously.
This capability is an example of what?
-
A
Cloud Vision OCR
-
B
Unimodal data retrieval
-
C
Multimodal search
-
D
Text-to-image generation
Xem giải thích
Đáp án
C — Multimodal search (tìm kiếm đa phương thức).
Vì sao đúng
Agent phải hiểu ĐỒNG THỜI nội dung ảnh và nội dung câu hỏi bằng chữ: "tìm ghế sofa giống cái này, nhưng màu xanh". Kết hợp hai modality trong một truy vấn tìm kiếm là tìm kiếm đa phương thức.
⚠ Vì sao cần cả hai cùng lúc:
Chỉ dùng ẢNH
→ ⚠ tìm sofa GIỐNG HỆT
→ ⚠ không biết khách muốn ĐỔI MÀU
Chỉ dùng CHỮ
→ ⚠ "sofa màu xanh" — quá chung
→ ⚠ không biết kiểu dáng nào
↓
⚠ KẾT HỢP CẢ HAI
→ ⚠ kiểu dáng từ ẢNH
→ ⚠ ràng buộc màu từ CHỮ
↓
→ đúng thứ khách muốn
⚠ Vì sao ba phương án kia sai:
"Unimodal data retrieval"
→ ⚠ CHỈ MỘT loại dữ liệu —
ngược với yêu cầu
"Cloud Vision OCR"
→ ⚠ đọc CHỮ trong ảnh, không
phải tìm sản phẩm tương tự
"Text-to-image generation"
→ ⚠ SINH ảnh mới; ở đây là
TÌM sản phẩm CÓ THẬT
Nhất quán với #13959 (lô 147) và #13950 (lô 146) về mô hình đa phương thức. Đề này áp vào bài toán tìm kiếm. Bổ sung nhau.
Vì sao các phương án khác sai
-
D (text-to-image generation) — phương án gần nhất và là bẫy chính: cũng liên quan tới ảnh và chữ. Nhưng nó SINH ảnh mới, còn khách hàng cần TÌM sản phẩm có bán.
-
B và A — không đáp ứng yêu cầu kết hợp.
Ghi nhớ
⚠ Đa phương thức trong các bài toán khác nhau: | Bài toán | Ví dụ | |---|---| | ⚠ Multimodal SEARCH | ⚠ ảnh + chữ → tìm sản phẩm — đề này | | Multimodal UNDERSTANDING | ⚠ ảnh vào → mô tả bằng chữ | | Multimodal GENERATION | ⚠ nhiều đầu vào → sinh video | | Text-to-image | ⚠ chữ → ảnh MỚI |
Từ khoá nhận diện:
"ảnh và chữ cùng lúc để TÌM" → ⚠ multimodal search "ảnh vào, mô tả ra" → multimodal understanding "chữ vào, ảnh mới ra" → text-to-image "đọc chữ trong ảnh" → ⚠ OCR
| ⚠ Multimodal search hoạt động ra sao | Cơ chế |
|---|---|
| ⚠ Ảnh và chữ cùng chuyển thành VECTOR | ⚠ trong CÙNG một không gian |
| ⚠ Ghép hai vector thành truy vấn | |
| Tìm sản phẩm có vector gần nhất | ⚠ vector search |
| Lọc theo thuộc tính | ⚠ màu, giá, tồn kho |
| Trên Google Cloud | ⚠ Vertex AI multimodal embeddings + Vector Search |
| ⚠ Vì sao đây là bước tiến cho bán lẻ | Lý do |
|---|---|
| ⚠ Khách khó DIỄN ĐẠT thứ họ muốn bằng chữ | ⚠ "kiểu sofa hơi cong ở tay vịn" |
| ⚠ Ảnh nói thay được | |
| Kết hợp cho phép ĐIỀU CHỈNH | ⚠ "giống cái này nhưng rẻ hơn" |
| ⚠ Giảm tìm kiếm không ra kết quả | |
| Đo bằng | ⚠ tỉ lệ chuyển đổi từ tìm kiếm bằng ảnh |
| ⚠ Việc cần làm để hoạt động tốt | Việc |
|---|---|
| ⚠ ẢNH SẢN PHẨM chất lượng, nhất quán | ⚠ quyết định nhiều nhất |
| ⚠ Thuộc tính sản phẩm ĐẦY ĐỦ | ⚠ màu, chất liệu, kích thước |
| Đồng bộ tồn kho | ⚠ đừng gợi ý hàng hết |
| ⚠ Xử lý ảnh khách chụp kém | ⚠ mờ, ngược sáng, có nhiều vật |
| Cho khách lọc thêm sau khi tìm |
| ⚠ Rủi ro và cân nhắc | Rủi ro |
|---|---|
| ⚠ Khách tải ảnh sản phẩm ĐỐI THỦ | ⚠ cần chính sách rõ |
| Ảnh có thể chứa người, nhà riêng | ⚠ quyền riêng tư |
| ⚠ Chi phí xử lý ảnh | ⚠ nhân với lượng truy cập |
| Kết quả không sát gây thất vọng | ⚠ nên hiện nhiều lựa chọn |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh khách chụp kém có tìm được không | ⚠ thử với ảnh thật, không phải ảnh studio | | Ràng buộc trong chữ có được áp không | ⚠ thử "nhưng màu xanh" xem có đổi kết quả | | Ảnh khách tải lên lưu bao lâu | ⚠ chính sách quyền riêng tư |
Và điều làm tìm kiếm đa phương thức thật sự hữu ích trong bán lẻ: nó cho phép khách hàng diễn đạt điều họ không gọi tên được. Rất nhiều người biết chính xác kiểu sofa họ thích khi nhìn thấy, nhưng không có từ nào để gõ vào ô tìm kiếm — và đó chính là khoảng trống mà một tấm ảnh lấp được.